ODOMETER: Conversion of decimals 226 & 153 to hex e2 & a5, combine those to e2a5, convert e2a5 to decimal => 58.009 km

typxxi · August 13, 2024, 1:53pm

I have a VW e-GOLF and I wanna get the odometer figure via mqtt & Meatpi Wican dongle into HA & evcc.

That has to be done in configuration.yaml in the mqtt section.

If have tried the jinja2 template engine but I could not figure it out for hours.
i have found out that the conversion to hex can be achieved this way

{{ "%0x" | format(226) }} => Result: e2
{{ "%0x" | format(153) }} => Result: 99

combined in jinja2 by this with the proper result of hex “e299”

{{ "%0x" | format(226) }}{{ "%0x" | format(153) }} => Result: e299

And that result “e299” can then be converted as a whole to decimal by

{{("e2a5" | int(base=16))}} => Result 58009 km which is right

So far so good,
but how can I achieve that in my configuration.yaml in its mqtt section ?

The WiCAN odb2 dongle sends this reply in canbus format

{"bus":"0","type":"rx","ts":33190,"frame":[{"id":1918,"dlc":8,"rtr":false,"extd":false,"data":[6,98,34,3,0,226,153,170]}]}

Key data are here in the brackets the elements marked as V1 (226 dec) and V2 (153 dec) here below

             V1  V2
[6,98,34,3,0,226,153,170]

I have tried it in ninja2 evaluation template but it didnt work out even with figures 226 and 153 - the right pane went into white and I got an error in the evaluation page.

Here is my mqqt sensor from the configuration.yaml where I am struggling for hours.

    - name: "GOLF KM V"
      unique_id: "golf_km_v"
      state_topic: "wican/12345678901234/can/rx"
      # state_class: "measurement"
      # unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1918 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 3 %}
          {% set v1 = {{ "%0x" | format(value_json.frame[0].data[5])}} %}
          {% set v2 = {{ "%0x" | format(value_json.frame[0].data[6])}} %}           
          {% set tmphex = {{ (v1v2) }} %} 
          {% set v = {{ (tmphex | int(base=16) }} %} 
             {{ (v) }}
          {% endif %}
        {% endif %}

I hope someone could the issue and explain to what went wrong.

The whole thing is triggered by an automation that detects if the Dongle is in the WLAN (online). From then onwards the automation hammers every 10 seconds the request for SOC, RANGE and ODOMETER.

Thanks a lot

BTW: The code is an example of getting VW GOLF Mark VII or e-GOLF data into HomeAssistant and then also into EVCC (charging / wallbox control).
For example SOC and range are already working via mqtt (they do not require any hex decimal conversions cause the values are already proper decimals), but the odometer is a nightmare compared to the extraction

Holdestmade · August 13, 2024, 2:23pm

I can’t 100% try this because I don’t have your data but this seems to work in template editor with substituted values:

    - name: "GOLF KM V"
      unique_id: "golf_km_v"
      state_topic: "wican/12345678901234/can/rx"
      # state_class: "measurement"
      # unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1918 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 3 %}
            {% set v1 = {{ "%0x" | format(value_json.frame[0].data[5])}} %}
            {% set v2 = {{ "%0x" | format(value_json.frame[0].data[6])}} %}           
            {{ (("%0x" | format(v1)) + ("%0x" | format(v2))) | int(base=16)  }}
          {% endif %}
        {% endif %}

typxxi · August 13, 2024, 3:46pm

Thanks a lot for helping me out.

I wonder how the code is working in your template engine cause here I get an error (I have replaced v1 and v2 by x1 and x2 in the first screenshot, but used your pasted code thereafter)

If I remove your code then it is fine again.

And finally I deleted all my stuff and pasted your genuine code from the topic untouched with v1 and v2

And that is caused by the “set” lines cause the last line is working properly showing the odometer of 58.009

I can not find any typos or so and I am no developer so hard to tell what is wrong with the “set” lines.

Any suggestions ?

Holdestmade · August 13, 2024, 3:50pm

v1 and v2 need to be the 226 and 153, not formatted

typxxi · August 13, 2024, 4:13pm

Well,
I have copied the screenshot into google keep and let the ocr recognition do its job.
The code below did the trick and maybe someone wants to reuse that in case he faces the same challenge of mqtt data from a CANBUS system

{% set a = [6,98,34,3,0,226,153,170] %}
{% set v1 = a[5] %}
{% set v2 = a[6] %}
{{ (("%0x" | format (v1)) + ("%0x" | format(v2))) | int(base=16) }}

and that works really nice. Also the integration of my example record is looking really good.

Meanwhile the car has arrived so that I can test it for the e-GOLF.

THANK YOU VERY MUCH - I will let you know about the results, once I was able to start HA again cause I had gotten updates that need a full reboot first which takes quite a long time.

I am really happy that you found it out !

My Pa will love to see the data of his car cause he is already over 85 years old and things get harder each day so every tiny step does help a lot.

I have the SoC of the car battery, then the range and now the odometer too.

Holdestmade · August 13, 2024, 4:14pm

Glad it worked, can you mark the post solved ?

typxxi · August 13, 2024, 4:19pm

Of cause. Done.
And in case I will have any questions I will come back. HA is now rebooting.

But I have a question cause you had written that “format is not needed” or so but you are using format.

Or did I get it wrong ?
I have copied the code from the converted screenshots and that worked without the usual error I have had before.

Holdestmade · August 13, 2024, 4:21pm

You were formatting it twice in the 1st and 3rd screenshots and adding the decimal numbers in the second screenshot

Olivier1974 · August 13, 2024, 5:04pm

I’m coming after the war but is it always expected to be a 2 hexa digits?
If yes than it was so much easier to do

226 * 256 + 153 = 58009
256 is to shift to 3rd positions in hexa

{% set v1 = 226 %}
{% set v2 = 153 %}
{{ v1 * 256 + v2 }}

Type de résultat: string
58009

typxxi · August 13, 2024, 5:40pm

typxxi:

I’m coming after the war but is it always expected to be a 2 hexa digits?
If yes than it was so much easier to do

226 * 256 + 153 = 58009
256 is to shift to 3rd positions in hexa

{
{% set a = [6,98,34,3,0,226,153,170] %}
{% set v1 = a[5] %}
{% set v2 = a[6] %}
{{ (("%0x" | format (v1)) + ("%0x" | format(v2))) | int(base=16) }}

I really appreciate those who reply after the war cause I have learned from that a lot.
And yes, I had seen this formular before in the can bus field in the past days, but I can not remember.

That 256 caught instantly my attention especially due to the fact that the second term is no real calculation just the 2nd bit x 1 maybe

226 * 256 + 153 = 58009

You have asked if it will always be a 2 digit hex which I can not really tell until I know more about that.
A car can last quite long, Mercedes, Golf and so on even up to or over 1 million km.

So digits would mean in hex FF FF I guess.
FFFF translates based on your formular to 256 x 256 + 256 or 256^2 + 256 = 65792 km

So the answer is NO, it will increase to 3 digit hex quite soon in less than 1 year.

Therefore I would love to read your explanation for this case and of cause how far the car can drive before 3 digits might be too small.

But I am assuming that in such case we will see a kind of 256^3 + 256^2 +256^1 and that you meant that with the term “shift to 3rd position”.

Thanks a lot for commenting even if it might be late. I am still working on the code cause it has not worked so far but at least in my mqqt collector sensor I have found the messages that the car has sent, those 1918 can bus messages have been recorded.

Olivier1974 · August 13, 2024, 5:46pm

So it is probably (v1 *256 + v2) * 256 + v3, lol (v1 being 0 until you reach 65535 km) which makes sense looking at your array

With that you can go up to 16777215km

And if they are creazy enough to do that in 4 variables then your car can reach 4.2 billions km but it seems they did not forsaw more than 16.7 millions

typxxi · August 13, 2024, 6:09pm

Well, that can not be so tough to differentiate based on the length of the hex figure.
2 digits the short one and
3 digits the longer formular which in total should be good for

(256 *256 + 256) * 256 + 256 = 16.843.008 km

I did 2 000 000 km but that took quite a while and 30 cars or so cause I had to exchange those every 6 - 12 months.

I will look for this topic later cause I have to solve the basic first or getting the mqtt data in the sensor.

THANKS

Olivier1974 · August 13, 2024, 6:13pm

FF is 255 but you’re right
(255*256+255)*256+255 is 16.777.215km

typxxi · August 13, 2024, 7:00pm

thanks a lot for the explanations.
Rebooting again.
Waiting for mqtt messages.