Automatic PID requests?

[simg]

It's possible that I'm missing something about the workflow for getting data from the ECU to MQTT but I have the following question.

My understanding is that some CAN frames are automatically broadcast by the ECU and these can be filtered by the CAN to JSON interpreter and published via MQTT.

Also some information needs to be requested from the ECU via a PID request which triggers the ECU to send the requested CAN frame.

It seems as though it's currently necessary to trigger a PID request via MQTT?

So for example if I want Home Assistant to receive say Battery SoC, I have to arrange for HA to periodically send MQTT messages containing PID requests which are picked up by the Wican and forwarded to the ECU.

Assuming this is true, my question is why can't the Wican be configured to do this automatically?

It seems like this would just require an extra field for "PID request frame" in the CAN to JSON configuration and the Wican could automatically poll the ECU using the existing "Cycle ms" period?

[meatpiHQ]

@simg

My understanding is that some CAN frames are automatically broadcast by the ECU and these can be filtered by the CAN to JSON interpreter and published via MQTT.

This will depend on the car, some car don't broadcast any data on the CAN bus. You can only make PID request.

Also some information needs to be requested from the ECU via a PID request which triggers the ECU to send the requested CAN frame.

Almost all cars support PID requests.

So for example if I want Home Assistant to receive say Battery SoC, I have to arrange for HA to periodically send MQTT messages containing PID requests which are picked up by the Wican and forwarded to the ECU.

That's right, have a look at this link: https://github.com/meatpiHQ/wican-fw/wiki/EV-Battery-SoC-in-Home-Assistant-%E2%80%90-Example

Assuming this is true, my question is why can't the Wican be configured to do this automatically?

Well, I tried to avoid automating PID requests, lots of bad stuff can happen if you send the wrong stuff to the ECU. In the future I might enable this feature for advanced users.

It seems like this would just require an extra field for "PID request frame" in the CAN to JSON configuration and the Wican could automatically poll the ECU using the existing "Cycle ms" period?

It's not that simple...

[rostchri]

If meatpi decides to do automatic PID requests in the firmware, it would be important that the firmware supports ssl/tls for mqtt, to deliver the results in a safe way.

[simg]

Thanks for the reply!

I must be missing something then, because I don't see why having the PID request sent via MQTT is any safer for the ECU or as @rostchri suggests, any more secure?

I'm aware of the Home Assistant Battery SoC tutorial but actually I was just using SoC as an example.

What I actually want to achieve in the first instance is to send arbitrary telemetry (for an ICE car) over MQTT. So fuel level, throttle position, mpg, odometer, lambda sensors, etc etc etc.

So that means I need to have HA sending many MQTT PID requests over a mobile connection and I also need HA to only send requests when the Wican is connected otherwise I will queue up a ton of unwanted PID request messages. Aside from wasting bandwidth this adds all kinds of complexities, like handling back pressure which may or may not be possible. These problems only get worse if you have a fleet of vehicles.

You're the expert and I'm completely new to this so no doubt you're right that there are reasons why this is not as easy as it sounds but from my perspective it would be soooo much simpler if the Wican could just send the periodic PID requests and forward the JSON responses.

[simg]

Now that I think about it, there is also the possibility that someone could MITM between the Wican and the MQTT broker, in which case they would be able to send arbitrary PID requests to the ECU.

Or if they were to compromise the MQTT server they have a similar capability. So overall receiving PID requests over MQTT is a significant increase in attack surface.

So it would be nice if the Wican had a setting to disable receiving messages over MQTT altogether and only transmit data.

[MarcosAPMT]

I also second this request. Would be really useful for us.

[meatpiHQ]

@simg

I also need HA to only send requests when the Wican is connected otherwise I will queue up a ton of unwanted PID request messages.

One thing to keep in mind, is that the number PID requests is limited to 10 or 20 request per second.

As I said I'm not totally against automating PID requests. What I meant by it's not that easy in terms of implementation, adding support the standard PID request is easy to do but supporting custom PID is much more complex, especially multi-frame responses and considering that the ESP32-C3 has somewhat limited RAM capacity ..having the AP+station mode and configuration server on all the time comes at a cost. Adding secure MQTT might not be an option, unless I heavily optimize the code even then still might not be feasible.

The easiest answer for these issue, is just wait couple of month, I will be releasing a new adapter that will solve all these issues... A button for configuration, 8MB RAM, full OBD2 protocol support, optional GPS, and optional LTE connection ... and much more :). Of course I will still add as much features to WiCAN as possible, but the new hardware will bring endless possibilities.

[simg]

I still don't see why sending the PID requests over MQTT makes the WiCANs job any easier.

It sends bytes to the ECU and receives some bytes as a response. There is no change other than the PID request bytes don't get sent via MQTT first.

One thing to keep in mind, is that the number PID requests is limited to 10 or 20 request per second.

I don't think I need to send 10 requests per second so that's fine. But let's say I was sending 10 requests a second and for some reason the WiCAN loses network connection with the MQTT server for some reason.

In a 1 minute network outage I have a queue of 600 messages to deal with, 10 minutes and it's 6000 messages. And the WiCAN has no way to know that it can and should discard those messages. This means I need to have the sender check the connection status of the WiCAN before adding each message to the queue, which breaks the purpose of MQTT. This is still an issue, albeit a slower one at one PID request per minute.

The whole approach is fundamentally broken.