e-GOLF SOC & RANGE reading not working with the settings of a VW e-Up of same model year

[typxxi]

I have an e-GOLF 2020 and wanted to read the e-GOLF SOC and maybe the current range - that is why I bought the dongle

I hope someone had achieved that before but I had no success so far in my search and therefore tried to use the e-Up codes that should be same or similir but the car is not replying at all*. I only get the online state in HA, once the car comes into Wifi range, which means the meatpi WiFi is reaching garage WiFi and gets connected to the router within a second or so.

And then - once it is connected and meatpi status in HomeAssistant hast turned to "online" the automation starts to ask for e-Up SOC but the dongle seems to not react on the codes send cause on mqtt explorer I do not see any reply.

Here is the call send { "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] };

BUT, a long BUT, in case I am in the car, key has turned the ignition on and I do connect with CarScanner to the car then the SOC will arrive once i have chosen in the app "all sensors" from the main Ui (after connection has been established) and filtered for "state" where I then get 3 sensors shown, first and last are SOC sensors. And from the moment - within a few seconds - the % figures of one of these 2 sensors will appear the mqtt explorer also will get the SOC again.

It will only stop working the moment I am going back out of this filtered sensor overview of just 3 sensors. If I leave that screen or go back and do no longer see the sensors being updated then mqtt explorer will no longer show updates of the SOC even though I am still connected on the phone with the car.

My entry on the Meatpi is vaild for e-Up and "should also" work for the "e-Golf" but I guess not really. meatpi settings from can ID onwards 2029 BMS_SOC 4 0 32 8 V/2.55 1000

Any ideas where to look - or did I got a faulty meatpic Adapter from Mouser USA shipped to germany ? I do not think so even though the behaviour is a bit weird but at least I learned to reproduce it and test it over and over again when the transmission reaches mqtt explorer and when not.

Thanks a lot

[typxxi]

I have asked a chatgpt like competition site for an answer about

What does this can bus formular U16(V1,V2)

That result is quite impressive or rather the previous attempts even more cause that looked like a full can bus explanation when i simply asked for "U16(V1,V2)"

I had done that before in google and got nice results from submarine warfare to what so ever . U16 was a submarine, V1 and V2 were german rockets called aka A4 ... but not really close to can bus.

[typxxi]

Solved thanks to the Chat thing

I ASKED FOR 1812 {"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}

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

I asked it several times and always the same reply on 1918 and took these data from it.

data [6,98,34,3,0,226,153,170] = 58.009 km

U16(V1,V2) is explained that it is a hex figure put together from 2 8bit hex figures: left half V1 and right half V2 Out of luck I started with the bigger figures 226 and 153. I did the conversion from decimal to hex first with E2 & 99. So I asked my converter first what decimal E299 would be and then flip it around to ask for 99E2.

But 58.009 km was too good to be true so I started writing these llines down and "painted a picture for the schematics"

           V1     V2
----------------------------------
decimal   226    153   
           ║      ║   
           ▼      ▼   
hex       E2  &  99  =►  E299 
                           ║
                           ▼     
                         58.009 km
                         =========

3 new gauges in HA for the EV. Next stop will be getting the daily consumption figures and km driven I guess sooner or later.

[JabeBRD]

Your correct, tried that also and got hex 1130 -> dec 4400 *10 = 44000km but this must be rounded as it must be multiplied by 10 I use different pid, it is bit more complicated, as it responds in two messages { "bus": "0", "type": "tx", "frame": [ { "id": 402391163, "dlc": 8, "rtr": false, "extd": true, "data": [ 3, 34, 2, 189, 170, 170, 170, 170 ] } ] }

[typxxi]

I have only 1 issue at the final step:

how to convert these bits from HEX, then create the compound string and that final step to convert the hex string into decimal.

I was able to convert to hex using this {{ "%0x" | format(226) }}{{ "%0x" | format(153) }}

That brought me in the template checker a result of E299

But I did not find a way to convert that into decimal. Any ideas ?

58.009 was easier done "on paper".

Do you really mean 1 query and 2 responses or after the first reply a second query as you had described it before ? The formular from that script file says something similiar : U16(V1,V2)*10

But i I take E299 and get already 58.009 then the factor 10 would make the odometer 10 times of the reality: 580.090 km

[JabeBRD]

Here https://github.com/meatpiHQ/wican-fw/issues/108

But with these extented messages, its hard to define right message, as they look allmost same, all start with 33 then there is data bytes, third message would start 34

I think you need to use {% set command, multiple times.

[typxxi]

Thanks, I will have a look and use your sensor for the SoC as template. I have already played with that but I did not get any result for whatever reason.

Here is what I have tried last night so far without luck even though if I asked for the odometer on the mqtt explorer publisher I got a reply like this

REQUEST
{"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}

REPLY FOUND IN THE HISTORY                                                                                 V1  V2
{"bus":"0","type":"rx","ts":15082,"frame":[{"id":1918,"dlc":8,"rtr":false,"extd":false,"data":[6,98,34,3,0,226,165,170]}]}

and data stripped                                               V1  V2
{"id":1918,"dlc":8,"rtr":false,"extd":false,"data":[6,98,34,3,0,226,165,170]}

for now V1 = decimal 226 V2 = decimal 165

Here is the service mqtt.publich part of my automation which had been running (I have checked the traces)

        - service: mqtt.publish
          data:
            qos: "0"
            retain: false
            payload: >-
              {"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}
            topic: wican/12345678901234/can/tx
        - delay:  ...

From my mqtt section in configuration.yaml

    ###   GOLF KM STAND ABFRAGE ANALAOG   ###
    - name: "GOLF KM STAND V1"
      unique_id: "golf_km_stand_v1"
      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 = value_json.frame[0].data[5] %}
            {{ (v1) }}           
          {% endif %}
        {% endif %}

For comparison here the reply from today {"id":**1918**,"dlc":8,"rtr":false,"extd":false,"data":[6,98,34,3,0,226,165,170]}

STEP by STEP ANALYSIS

the following line should be true {% if value_json.frame[0].id == 1918 %}

therefore the PID will be stored and checked (4th element addressed by [3]) {% set PID = value_json.frame[0].data[3] %}

Then the PID will be checked if that is 3 which should also be true {% if PID == 3 %}

and now v1 should aquire the 6th element adressed by [5] which is "226" {% set v1 = value_json.frame[0].data[5] %}

Finally v1 value of "226" should be stored in the sensor {{ (v1) }}

Hence the question: How does the sensor golf_km_stand_v1 look like ?

No value at all or even worser

I do not even have such a golf_km_stand_v1 sensor at all ?!?!

BUT WHY ?

I have tried already a bit with the template evaluation regarding the conversion and some things did work and others did not. {{ "%0x" | format(226) }}{{ "%0x" | format(165) }} with a result of E2A5 which is right.

But now I need to convert that to decimal which then would hopefully return 58.021 km on the odometer which is right.

So far no success in that template evaluation beyond that 1 line (also if I am using V1 and V2 instead of the decimals) {{ "%0x" | format(226) }}{{ "%0x" | format(165) }} => with a result of E2A5

Now I will start digging into your previous comment and hopefully find more answers than questions.

[JabeBRD]

I cant spot anything wrong with that sensor. That value_template is working for me, please check HA log file under config folder. Home Assistant forum has very talented people, they might be able to help better.

[typxxi]

OK, meanwhile I had found out that the syntay provided by chatgpt was wrong

hex to decimal conversion is working with this {{("e2a5" | int(base=16))}} = 58.021

And when I read a comment in the openwallbox forum I was wondering if I could interact via that interface to activate pre climatisation before departure, which back then VW WeConnect service wanted to provide , which rarely or barely worked.

That would be a real benefit, but I am not sure if that is possible cause the key is missing and a "safe" signal source is like WeConnect is missing too in case things go wrong. But at least it would be nice to run the AC or heating before departure while the car is still connected and charging.

[typxxi]

Could you tell me what the 0 means here and if I have to adopt that depending on the reply 1918 I am getting ?

value_json.frame[0].id

I have gotten a "odometer calculator" which is working in the jinja2 template checker. But this code must have a fault even though it is a copy of the range and SoC implementation.

Thanks to your gread advice to build a mqtt tracker sensor for transmit and another for rx I have found those even in the UI by selecting 30 minutes or so . If you hover than the details are shown and the colour of repeated messages stays the same too. At least for my 5 examples I have checked.

Here is the mqtt yam code based on a copy and small changes.

- name: "GOLF KM STAND"
  unique_id: "golf_km_stand"
  state_topic: "wican/123/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) }}
      #         {% set v1 = a[5] %}
      #         {% set v2 = a[6] %}
      #           {{ (v1) }}           
      {% endif %}
    {% endif %}

And here is an odometer converter from decimal - hex - merge - decimal code that is working at least in jinja template checker . Works great and delivers from that 226 153 the right odometer figure

{% 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) }}

Hope you have an idea how to deal with such a mqtt sensor not getting filled up.

thanks a lot - really appreciate your support.

[JabeBRD]

Here is great tool, to help with JSON messages https://jsonpathfinder.com Enter wican mqtt message and you will see .frame[0] and .data[0] what they mean, basicly [0] is order number of that message. Tried that sensor, but couldnt get it to work yet in template editor. But i think you need to remove {{ }}from {% %} lines

[typxxi]

thanks -

10 minutes ago I had built a new sensor to boot and check if it is 1918 or not and then do the raw stuff , that datacollector, just to see if something arrives or not. Yes, I check the mqtt explorer and also that history you had recommended for the 1918 messages and they are there, full length and clearly readible.

If you mean that conversion here is a screenshot that it works

and this is the code from the moment of the screenshot 1 minute ago

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

Works at least there. I will check jsonpathfinder now.

[typxxi]

looks quite good even though I have no clue at all about JSON. At least I can see the "frame - 0 - id - data hierarchy" which should mean that the format should be right too.

{% if value_json.frame[0].id == 1918 %}

[typxxi]

Here in the logs i found a bit

But hard to detect, what is wrong so I will start from scratch with a new copy to be on the safe side.

[JabeBRD]

You have line {% set v1 = {{ "%0x" | format(value_json.frame[0].data[5])}} %} {{ }} cant be inside line{% %} Should be {% set v1 = ( "%0x" | format(value_json.frame[0].data[5]) ) %}

[typxxi]

ahh, that is it.

And yes, I had mqtt issues I had to solve like missing device class and so on.

And then the sensor for the odometer suffered from a different cause I guess: the '#' does not work in such {} lines in yaml.

I had built another dumb mqtt collector sensor to collect 1918 or odometer replies only

      value_template: >-
        {% if value_json.frame[0].id == 1918 %}
          {{ (1918) }}
          # {{ (value) }}
        {% endif %} 

I had thought that I would get 1918 only , but then that was followed by # and the whole mqtt message.

[typxxi]

I just today got my range set up, you might need two messages, atleast for passat gte first response is total km, then if you ask for second response you get petrol and ev. Im using can gateway to read range, here {"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]} Then if you get response looking like { "bus": "0", "type": "rx", "ts": 54465, "frame": [ { "id": 1914, "dlc": 8, "rtr": false, "extd": false, "data": [ 16, 10, 98, 42, 182, 0, 147, 0 ] } ] }, you might want to ask for the another message with this command {"bus":"0","type":"tx","frame":[{"id":1808,"dlc": 8, "rtr": false, "extd": false, "data": [ 48, 0, 0, 170, 170, 170, 170, 170 ] } ] } You need automation if you want to query second message, as delay betwene messages cant be greater than 50ms.

I am trying this one know cause I am not able to get the incoming mqtt message into the sensor with my previous idea. Works on paper only.

So I followed your advice , created an automation that is requesting 2 answers with a delay of 50 ms

{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[48,0,0,170,170,170,170,170]}]}

I got 1 answer only {"bus":"0","type":"rx","ts":54465,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,147,0]}]}

Is that maybe depending on the current odometer reading cause below 67000 km or so the hex could be a 2 digit hex and beyond that a 3 digit hex would be good for 16.000.000 km

You can see it here

first request, then the reply on 1914 2nd request and no response

till 6 seconds later the automation will kick in again and start from the top. I have searched for 1914 replies and found only the same with the "...147,0...." at the end

Finally I have increased the break from 50 to 250 ms but still no 2nd reply and then I went back to 40 ms and again no 2nd reply. I have restarted the automation after the changes cause otherwise those would run with the former configuration until the WiCan goes offline I guess .

And even though you did not mention it: I also opened the lock to activate the car even further, but I did not turn on the ignition so far.

Any ideas ? Thanks Therefore my

UPDATE: I have turned the ignition on and now I got a second and different reply here the 33,171 ..

{"bus":"0","type":"rx","ts":44017,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[33,171,7,253,0,170,170,170]}]}
{"bus":"0","type":"rx","ts":25541,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,171,0]}]}

I have checked the CAN GATEWAY here for odometer but could not find any.

I have found "odometer" 3 times in the list here and in 8C are even multiple ones like odometer, odometer partial and odometer bookmark I had tried this before and couldn't get the sensor to work.

*17 dash panel insert mlg_tot=>{cmd=>'22 22 03', cu=>'17', desc=>'odometer (~10)', unit=>'km', d=>2, formula=>'U16(V1,V2)10'},**

17 Control unit in dash panel insert (J285)

8C Battery regulation control unit / BMS (J840))

C6 Control unit for battery charging unit / OBC (J1050)

[JabeBRD]

For second message, change "extd": true Or use these messages, found in that link https://github.com/meatpiHQ/wican-fw/issues/108 {"bus":"0","type":"tx","frame":[{"id":402391163,"dlc":8,"rtr":false,"extd":true,"data":[48,0,0,170,170,170,170,170]}]} {"bus":"0","type":"tx","frame":[{"id":402391163,"dlc":8,"rtr":false,"extd":true,"data":[3,34,2,189,170,170,170,170]}]} You need to make two sensors for this odometer, one for each message, then use third sensor or helper to sum those values.

And that message was for range not odometer. But message above is for odometer.

For calculating this, your earlier odometer message [6,98,34,3,AA(0) ,BB(226) ,CC(153) ,170] AA(0) 2^16(=65536) + BB(226) 256 + CC(153)

[typxxi]

You have edited the comment while I was writing and therefore most part was written whie still updates arrived in the last 4 lines I guess.

I am writing here cause these 2 lines feel confusing for me.

And i had typo, i mean range not odometer. But message above is for odometer.

until you updated them now and the confusion has vanished due to that twist.

So here is my message I had written before these intro lines above:

1. I will change this option to true "extd": true

I prefer these IDs where I can flip the 1808 back into Hex 710 which I then can look up in the amigo list as CU Gateway CAN for e-GOLF .

If I see any long id beginning with "4*" I always get the memories of a flood of messages you can not really follow unless you start exporting the golf mqtt raw sensor. That works really great, but it takes quite some time to get there while I now prefer to use the mqtt explorer and clicking on rs = and then into the history of those rs messages cause then I can search in those up 99 messages quite easily . I also tend to turn off WLAN once I have found a match.

Just to let you know about my way with these 2 requests 50 ms delay for the 2nd one.

{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":true,"data":[48,0,0,170,170,170,170,170]}]}

So extd: means that this is a flag to identify more easiy a "first" message from 1 or multiple following cause they all will appear under the reply CAN ID "1914". Good to know if that is true.

3. So I need to create 2 sensors in the configuration.yaml in the mqtt section for odometer_1st_half and odometer_2nd_half and a helper (sensor) odometer

and the helper is based on the really nicely formatted calcuation that makes it easy to me to understand but also has caused a question.

I am not sure if I had seen these AA BB CC before and therefore I am asking if that AA BB CC is a usual term used for the 5th, 6th and 7th element in the data[] section ? If so I would make some notes cause I bet I can reuse those. I have seen the v1 and v2, I know what U16 means and have seen also U24 today.

4. I will reuse the working code of the SOC and make the changes to use that for the odometer sensor I would check the ID and PID based on this 1st reply:

{"bus":"0","type":"rx","ts":54465,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,147,0]}]}

1. check: id needs to be 1914
2. check: PID as 4th element adressed by value_json.frame[0].data[3] should equal 42

But now I am struggling cause I had gotten these replies

{"bus":"0","type":"rx","ts":44017,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[33,171,7,253,0,170,170,170]}]}
{"bus":"0","type":"rx","ts":25541,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,171,0]}]}

And you said we would need both of these, but what about your reference in the 2nd last line

What is the "earlier odometer message" cause I have not gotten such message like this today **[6,98,34,3,AA(0) ,BB(226) ,CC(153) ,170]** Or do you mean that first solution I had worked on yesterdays cause I can recognice the 226 and 153 as part of the odometer calculations from yesterday, those 58.009 km and the bigger one was 165 with 12 km more = 58.021 km.

But why am I asking for 2 replies with these 2 requests in the automation if I would not use these ?

{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
{"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":true,"data":[48,0,0,170,170,170,170,170]}]}

and use the results of my previous request even though I never could figure it out how to the

    - name: "GOLF KM Stand (1/2)"
      unique_id: "golf_odometer_1st_half"
      state_topic: "wican/123/can/rx"
      state_class: "measurement"
      unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1914 %} **# I guess I need to use the 3 from the OLD one** 
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 3 %}
            {% set AA = value_json.frame[0].data[4] %}
            {% set BB = value_json.frame[0].data[5] %}
            {% set CC = value_json.frame[0].data[6] %}
            {{ AA * 2 ^16 + BB + CC }}
####                0 + 226 * 256 + 153 = 58009
####                0 - that 0 is the "overhead" used once the odometer has surpassed 255 * 256 + 256 > 65.535 km
####                that is why it needs a third message cause 2x 2digit hex is limited to 65535 (km). 
          {% endif %}
        {% endif %}

Please let me know cause then I do not have to delete the old code that I couldn't get to work with all the issues. And that needed a reboot which took about 10 minutes till HA had fully started. And I tried so often. But hopefully it might work this way.

[typxxi]

Here is my mqtt sensor

    - name: "GOLF KM STAND"
      unique_id: "golf_km_stand"
      state_topic: "wican/123/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 AA = value_json.frame[0].data[4] %}
            {% set BB = value_json.frame[0].data[5] %}
            {% set CC = value_json.frame[0].data[6] %}
            {{ ( AA * 2 ^ 16 + BB * 256 + CC ) }}
          {% endif %}
        {% endif %}

I have to reboot now and check what results I will get. For now only the 1 old request will be running I had been using yesterday, the 1812 and 1914 pair.

REQUEST {"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}

[JabeBRD]

I mean that first solution. Just use your old odometer sensor setup, i just remembered/figured out those values for converting values to real km figure, just multiply with, first value with 65536, second with 256, third as is and sum all together. This is much easier. Your sensor setup looks right, i would use 65536 instead of 2^16, just to be sure. I would do it this way {{ ((AA*65536) + (BB*256) + CC) }}

For that two message respond, use same multiply values.

Below is range message, your range is 171km, it is more helpful with hybrid, as it contains, both ev and petrol and combined. Combined is in first message, invidiual values are in second, but i dont know what those mean in full ev vehicle. {"bus":"0","type":"rx","ts":44017,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[33,171,7,253,0,170,170,170]}]} {"bus":"0","type":"rx","ts":25541,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,171,0]}]}

[typxxi]

No, something seems to be wrong cause I do not get 2 answers, just one on that CAN ID port header - I mean that 1812 asks and gets a 1918 reply. The range has been soved cause I get the right figure I can see in the instrument cluster.

So, right now the current reply for the 1918 request looks like this 4th REPLY ON WEDNESDAY

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

DECODING:                V1     V2
=========  --------------------------------------------------
           1. DECIMAL   227     61
                         ║       ║   
                         ▼       ▼   
           2. HEX        E3  &  3D   ==►  3. E33D = 58.323 km
                                                    =========

That is the figure of the odometer right now.

Here is my yaml mqtt sensor

      value_template: >-
        {% if value_json.frame[0].id == 1918 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 3 %}
            {% set AA = value_json.frame[0].data[4] %}
            {% set BB = value_json.frame[0].data[5] %}
            {% set CC = value_json.frame[0].data[6] %}
            {{ ( ( AA * 2 ^ 16 ) + ( BB * 256 ) + CC ) }}
          {% endif %}
        {% endif %}

That one has not really worked , but better than in the past 24 hours with so, so many awfull HA reboots.

So here is the current state, which I really like and I bet you too at least then, if that would reflect / mirror the reality on the odometer, but that is not working this way - at least not yet.

And the piece that has worked partly is what you wanted to change cause

And based on the reply you can recognice that an odometer count of 276 is looking really nice even though the dashboard wanna fool you with a 58.000 km figure ... while it is so new.

[6,98,34,3,0,227,61,170]
           AA BB CC 

   0 * 65535 =      0   {% set AA = value_json.frame[0].data[4] %}
 227 *   256 = 58.112   % set BB = value_json.frame[0].data[5] %}
  61 *     1 =     61   % set CC = value_json.frame[0].data[6] %}
-------------------------------------------------------------------  
               58.173   {{ ( AA * 2 ^ 16 + BB * 256 + CC ) }}

And this shows what has been working: just the AA figure of 0 and the BB figure but only by factor x 1 , everything else here {{ ( ( AA * 2 ^ 16 ) + ( BB * 256 ) + CC ) }} went wrong.

So I will now change this line {{ ( AA * 2 ^ 16 + BB * 256 + CC ) }} with your line ( I have only added spaces for better readability) {{ ( ( AA * 65536 ) + ( BB * 256 ) + CC ) }}

But there is no way to inpret BB = 227 that way considering that it was and is BB * 256 which is a lot more than just 227.

10 minutes and HA should have rebooted and I should know more.

[typxxi]

So it is working now in both cases. Why ?

Well, with all the trials and errors I had built 2 sensors and had opened 1 view on 1 sensor called kmstand and that got as tonight and yesterday no updates. And I thought that the code is not working.

But after lunch I had cleaned up the code from a lot of mess and then used a sensor quite the same: km_stand

Just _ was the difference. Not more.

Hope it will continue to work this way. THanks a lot for your endurance and great and guiding support through all the obstacles.

[typxxi]

Here the view on the right sensor

and this is the wrong one which had worked till 2 pm with 271 or so

[typxxi]

modern Santa Claas has hopefully delivered - powered by amazon Thanks a lot for your support.

[JabeBRD]

Well thank you very much.

Good that you got everything working.

[typxxi]

got it mail should arrive now.

You can delete your mail adress

[typxxi]

In the upcoming week I will write a tutorial about that GOLF is no up, but rather a Passat GTE adventure that the knowledge can be found and reused easier. And then I also have a documentation cause that was a long and winding journey till it at least seem to work.

[JabeBRD]

Here i have opened discussion some time ago, for this data to be used in evcc, but not much discussion there. https://github.com/evcc-io/evcc/discussions/14551

[typxxi]

I suggest to post that here

That is the spot to show use cases and full systems. For me e-Up and Passat GTE are such use cases considering the amount of things that can be achieved like

• replacing mostly weConnect functionality (here in Germany 100€ p.a.) cause that is rubbish suffering from outages all over the year.
• SoC
• Range
• odometer for even cars that are quite old - I mean designwise cause an e-Up has its roots in drawings from 2009 and much more I guess

And it's the whole VW plattform, not just EV only. In discussion it might go under cause it will not be recogniced as knowledge and guidance based on the "branding" as discussion.

[typxxi]

It may take some time to find correct calculation for soc display. Search google for soc helper, it was some german forum, i remember there was another calculation for e-golf, that might work for you.

IN SHORT: the real formula for the e-GOLF would be based on car scanner measurements for SOC 100% and "0%" (based on fully charged and 0 km range left)

AA / (250 - 10 - 20) x 100

where the -10 represents the upper unuseable buffer (from 240 to 250) and the -20 the lower one from 0 to 20 (those are the 2029 reply values).

And many would mess that up by shortening it to AA / 220 x 100 or even more worse AA / 2,2 It cuts out the full story of the sensor and its root from gross to net capacity, cause the missing 30 points equal 12% which is the difference between net and gross capacity, but the story is quite long and should explain it in detail.

FULL STORY

I am now working on a guideline regarding this eGOLF data acquiring adventure. While reading I found things or remarks from you I have read but never replied to nor talked about the when or why I chose a different way.

This is my explanation why I did not use any of these /2,5 or 2,55 or whatsoever e-Up style looking formulas and went a different route based on what is known about the e-GOLF

The journey to SOC of the e-GOLF start here with this "amigos list" as I call it (reminds me of the commodore amiga) and the control unit used called "8C" HV Battery regulation" aka "BMS" where you can find in the second line this, where I deleted some spaces and details not needed for now

# 8C Battery regulation control unit / BMS (J840)
SoC_g40=>'22 02 8C',desc=>'SoC gross (.40)',unit=>'%',d=>1,  formula=>'sprintf("%.2f", V1/2.5)'}, # verified correct, also eGolf

And the last comment means that this has been verified correct for the e-Up and then got the additional mark "also for eGOLF" Back to the basics: the key name is "SoC_g40" and is explained in the line in desc = description as 'SoC gross (.40)'

When I got the replies for the first time I had a 170 figure and we discussed above somewhere how high that would go. I can remember I had found a document which said 250.
Looks good, but let us not emphasize more on that for now and go back to what Car Scanner would mention.

I had also written down the Car Scanner SoC value next to what replies I got in this table you can find above when I observed steps or jumps of 0,4% which I found astonishing and caused me to maintain the simple table shown in this screenshot

I learned quite quickly that this reporting was happening with jumps of 0,4% and the pattern did not change which meant the car could only report increments of 0,4% and nothing in between.

Then I also saw that from SOC 68% to 76% the value of the SOC replies increased by 20 from 170 to 190 for 8% which made sense due to the step size of 0,4% x 20 = 8%

So I continued charging was keen to see how far it would go like 100% or not. But it came to an end at I guess 96% and with a SOC value of 240 in the reply.

That convinced me that this SoC was reporting values from 0 to 250 and representing a SOC from 0% to 100%. AND NOW look above on the amigos list and the description "SoC gross (.40)" That .40 figure explains the full story cause .4 represents the 0,4% step which leads to 250 steps to reach 1 or 100%.

At that point I was sure I woul need a real Drivers Net SoC and not the cars Control Unit value which would make no sense to any car user watching a 96% SOC in HA which then in the car would be 100% where another charging would not help to increase the 96% HA was showing. It will stop instantly, which I also tried just to make sure that there is no chance.

I tried it 5 times in a row and then again 3 times with 5 minute breaks in the hope to "push the SoC" a bit further. No luck , no magic. SoC stayed at 96%, the display never showed a green binking socket, only white = car is connected.

You warned me to be carefull and to not forget that the lower point when the BMS would stop discharging = stop driving would also not be at value 0 rather somewhere above. If VW stopped 10 points before reaching the top of 250 then obviously they could have drawn another red line around 10 points too, so that the real useable SOC would be from 4% to 96% if that 10 point assumption would be right.

So I changed my formular for the SoC and did no longer use "reply value" / 250 and used from then on "reply value" / 240 = AA / 240 Just a small difference but it starts there with 10 points here and there cause that will have an impact on charging times EVCC is doing in its own calculations. And if the goal is 250 which never can be reached than the charging time calculated is longer than in real life where 240 is the limit.

And with your "warning" in mind I also did check the other side which meant to drive as long as the car would stop driving.

No, sorry, just kidding. I did something similiar on thursday evening when the car had arrived with a 25% SOC and I drove it down as fast as I could and then learned also something new: If the car has reduced everything from power to comfort and what not incl. turtle mode that there is still a "full ahead" you can reach like in a car with automatic transmission: the kick down is still there with a new function

You have to press really hard but then the full power is back even at 10 km range left.

At 0 km range (I mean when I reached 10 km range milestone I looked on the trip meter which showed 66.5 so I should have real 0 km when the trip meter shows 76.5 km as my goal I achieved) and 76.5 km trip meter I arrived in the garage and checked HA SoC which jumped to 8,3% as you can see here from the history thanks to the soc_permanent sensor.

This might sound weird looking at and uneven figure with 0,3% when talking before about the 0,4% steps.

BUT: at that particular moment you could not compare these figures cause I had set the SoC sensor to 100% when the gross sensor would show 96% sensor and the 2029 reply would show a value of 240 instead of 250.

And to get the SoC for HA right and matching the car I had done this table to be sure that the 8,3% I had seen that night and are still stored in the sensor were proper and right.

First column shows the Car Scanner value / reading = cars value 2nd is the value in the 2029 response 3rd shows the calculated SOC with that offset of -4% on the upper limit where 100% was set as 96% but the lower end would still be of cause 0 pt = 0%

and finally the 4th column shows that the assumption is right: car had 0 km of range when the 2029 reply shows a value of 20 or based on the cars SoC 8%

The cars useable SoC based on the internal SOC ranges from 8 % - 96% or from 20 - 240 points based on the 2029 replies I had seen and also the SOC presented in Car Scanner when it was fully charged and also when the golf had 0 km range left

And therefore I am using right now the following formula to always remind me about the offsets on the upper and lower end

The formular once started with something like this: ((AA - 0) / 240) * 100 and then can be found on the web in variations like AA / 2,5 or AA / 2,4

UNFORTUNATELLY the real story behind the SOC has gone lost with these simple dividers like AA / 2,4 which is btw the same like AA / 240 x 100

And the last AA / 240 x 100 tells a complete different and - most importantly - readable story, cause once I had seen the 96% SOC in car scanner app and the 240 value reported by canbus reply I knew that i must have been right.

At least once you had started digging and wrote down a table of SOC reported by car and reply values from HA with a 240 !

Now we can see that someone has missed big time cause he had not spend attention for the lower end, cause the proper formular to reflect the useable SoC would be different which i am using now.

AA / (250 - 10 - 20) x 100

instead of the short one: AA / 2,2

where no one would get behind the upper offset of 4% and 8% as lower offset or protection by VW.

And this 12% x 36 kWh gross capacity would explain the reported / measured net capacity of 31,5 kWh useable energy 36 kWh - 12% x 36 kWh = 88% x 36 kWh = 31,68 kWh compared to the usually found 32 kWh net capacity.

Yes, when I had arrived that night with 0 km range inside the car HA was happily reporting 8,3% which was way of, but I had no time to make screenshots cause if I do such extreme charging and discharging states then I also relieve the battery from the stress by charging instantly or in the other case driving the car. I had seen LFP cells gettin damaged by a too high state of charge during storage cause they bulge significantly about 1 mm per cell or 8 mm in a home storage of 2x 8 cell box.

Now the SOC in HA represents the real useable SoC and real remaining range.

For comparison the digital e-GOLF instrument cluster and its SoC gaugs on the lower left which is even worse just using the clock face from 7:30 to 9:00 am for 100% - and now I found the picture I was thinking of

Just 45° for 220 steps of charge from 20 to 240 is a shame or at least in case when there is no SoC !

[typxxi]

a new kind of issue which has appeared more frequently and not in the beginning.

If I read the range I got the range quite accurate = it matched that in the dashboard.

But most recently I have recogniced that I got the range and it was shown in the HA page but then was replaced by 0 km of range. That does not look good. And I had thought that the retain flag would take care and keep the value which is not the case.

Assuming that there must be a canbus message that arrives via mqtt in HA then this must arrive with a value of 0 cause I can not identify another way how I can get such value of 0 range even at SOC 90%. SOC is good, odometer value too.

From today 3 peeks over the whole day when the range had been updated . Car had been used but not charged at all.

my current solution based on the assumption mentioned above:

    ###   REICHWEITE GOLF ABFRAGE ANALAOG   ###
    ###   {"bus":"0","type":"rx","ts":15850,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,217,0]}]}
    - name: "GOLF REICHWEITE"
      unique_id: "golf_reichweite"
      state_topic: "wican/5432048fde15/can/rx"
      state_class: "measurement"
      unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1914 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 42 %}
            {% set AA = value_json.frame[0].data[6] %}
            {% if AA >= 0 %}
              {{ (AA | round(1)) }}
            {% endif %}
          {% endif %}
        {% endif %}

I have added a kind of another filter or security check cause for the e-GOLF I know for sure that the lowest value of that AA has to be the range bigger than 0 cause in case of zero it must be a false message or reading.

Not sure if that will work but maybe someone else has a suggestion ?

THANKS

[JabeBRD]

Well i can think two cases:

1. another message on control unit 1914 that has value 42 on byte 3
2. range is 256 or more. You get value 1 in byte 5 and value 0 in byte 6 when range 256km

Change your sensor to this, to overcome both

    - name: "GOLF REICHWEITE"
      unique_id: "golf_reichweite"
      state_topic: "wican/5432048fde15/can/rx"
      state_class: "measurement"
      unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1914 %}
          {% set PID = value_json.frame[0].data[0:4] %}
          {% if PID == [16,10,98,42] %}
            {% set AA = value_json.frame[0].data[5] %}
            {% set BB = value_json.frame[0].data[6] %}
              {{ ((AA*256)+BB) | round(1) }}
          {% endif %}
        {% endif %}

[typxxi]

regarding range above 256 km was no issue cause it happened randomly but not the last 24 hours since I had changed the code . And I have had already a range above 256 also without any issues. I had been at 272 km last week, which mean the 272 km appeared in HA and in the car. So no error at all except sometimes later, when 272 like all the other ranges had been replaced with a simple and plain "0 km".

I will be able to check your code on the weekend again. My solution above looks good so far, cause right now the range figure is transmitted and stays the same for over 24 hours (I am not at home therefore no access to the car). Thanks a lot.

[meatpiHQ]

@typxxi @JabeBRD I've created a vehicle profile for e-up, I'm trying to make one for e-golf, this issue is a bit hard to follow, were you able to successfully get e-GOLF SoC?

You can now use the latest release

https://github.com/meatpiHQ/wican-fw/releases https://github.com/meatpiHQ/wican-fw?tab=readme-ov-file#getting-started-guide

[typxxi]

yes, I get from the e-golf

• SOC
• Range
• odometer

It works rock solid, but it has some requirements and drawbacks to be aware of:

1. the car needs to be unlocked That means in case of the e-golf after turning of the ignition and leaving the car to shut the door and then reopen it. If this will be ignored the automatic close after 1 minute will close the door and activate the car theft alarm.

Therefore not a solution for outdoor chargers.

I have not clue how to shut off such theft alarm in a VW e-GOLF Mark 7 which is caused by the dongle, nothing else, no fly, no pet nothing. And unlocked is the only way out - at least for me right now. BTW: the alarm is not kicking of after the car has been locked or locked itself, sometimes later

2. the data are not constantly transmitted and in my experience only while ignition is turned on. I have missed the cars data sometimes and when I got aware of that I reduced the halt time for the automation to 5 seconds. With 12 seconds the car could have arrived and logged in but the canbus request reply has not been successfull in the few remaining moments. That also depends on range of wlan and when driving in. But in 95% of the arrivals and departures the cars data are transmitted successfully to HA.

AUTOMATION be aware that the timer is used for testing purposes and is adjusted to start the automation again cause the trigger requires a "turns online" event which means just turning of the ignition is not enough. You would have to pull out the meatpi dongle and therefore I avoided that and choose the time event. Not used in productive phase, but usefull while testing.

german words Reichweite = range km Stand = odometer

alias: "1 - MQTT GOLF SoC, RANGE & ODOMETER - JabeBRD edition"
description: >-
  'SoC High Voltage Batter charge state - absolute value' from control unit 01 -
  selected in 'Carscanner App' = 1. SoC Sensor after filtering for 'state' - 
  GOLF SoC + RANGE + ODOMETER."
trigger:
  - platform: state
    entity_id:
      - sensor.golf_status
    to: online
    from: null
  - platform: homeassistant
    event: start
  - platform: time
    at: "19:23:35"
condition: []
action:
  - repeat:
      sequence:
        - condition: state
          entity_id: sensor.golf_status
          state: online
        - data:
            qos: "0"
            retain: true
            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }]}
            topic: wican/1234567890/can/tx
          action: mqtt.publish
        - data:
            qos: "0"
            retain: false
            topic: export/golf/soc
            payload: "{{ states('sensor.golf_soc') }}"
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            topic: export/golf/soc_permanent
            payload: "{{ states('sensor.golf_soc') }}"
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            payload: >-
              {"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
            topic: wican/1234567890/can/tx
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            topic: export/golf/reichweite
            payload: "{{ states('sensor.golf_reichweite') }}"
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            topic: export/golf/reichweite_permanent
            payload: "{{ states('sensor.golf_reichweite') }}"
          action: mqtt.publish
        - data:
            qos: "0"
            payload: >-
              {"bus":"0","type":"tx","frame":[{"id":1812,"dlc":8,"rtr":false,"extd":false,"data":[3,34,34,3,170,170,170,170]}]}
            topic: wican/1234567890/can/tx
            retain: false
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            topic: export/golf/odometer
            payload: "{{ states('sensor.golf_km_stand') }}"
          action: mqtt.publish
        - data:
            qos: "0"
            retain: true
            topic: export/golf/km_stand_permanent
            payload: "{{ states('sensor.golf_km_stand') }}"
          action: mqtt.publish
        - delay:
            hours: 0
            minutes: 0
            seconds: 4
            milliseconds: 0
      until:
        - condition: state
          entity_id: sensor.golf_status
          state: offline

yaml SENSORS

I have 2 of each of them to keep the data in case of a reboot. I used the requests I have put on top of the sensors as # comments for copy and paste purpose during testing.

1. I get the last connection date and time with the online status.

2. SoC calculation is based on real world experience which means the value transmitted is between 0 and 250. 1 / 250 means a step of 0,4 % SOC which you can see in the carscanner pro app.

BUT that is gross capacity. Gross capacity means what ?

Fully charged you will get a reply of 240 which means 10 points less than maximum. Car will stop charging at 96%.

And on the lower end it needs a testride till you reach 0 km of range. I went even 1 km further and got a value of 20. 20 means 8% so the useable capacity is 88% .

For our HA SoC sensor I am setting 88% = SoC 100% and 8% = SoC 0% At the end I have 220 steps each 0,4% of gross capacity, so the steps for my HA sensor are a bit bigger than gross 0,4%.

And the whole procedure and testing is also described in the code in german.

    ###   GOLF WiCan Dongle Online / Offline ?   ###
    - name: "GOLF Status"
      unique_id: "sensor.golf_status"
      state_topic: "wican/1234567890/can/status"
      value_template: "{{ value_json.status }}"
      icon: mdi:car

    ###   REICHWEITE GOLF ABFRAGE ANALAOG   ###
    ###   { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }]}

    ###   GOLF SOC ABFRAGE ANALAOG   ###
    - name: "GOLF SoC"
      unique_id: "golf_soc"
      state_topic: "wican/1234567890/can/rx"
      state_class: "measurement"
      unit_of_measurement: "%"
      value_template: >-
        {% if value_json.frame[0].id == 2029 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 140 %}
            {% set AA = value_json.frame[0].data[4] %}
            {{ ( (AA - 0) / (250 -10 -20)) * 100 | round(1) }}
          {% endif %}
        {% endif %}
      # ######################################################################
      # ###                                                                ###
      # ### {{ ( (AA - 0) / (250 -10 -20) ) * 100 | round(1) }}            ###
      # ###                                                                ###
      # ######################################################################
      # ### 2029 REPLY meldet bei "VOLL GELADEN" 240 (statt 250)           ###
      # ### 100% für Fahrer, aber Car Scanner App zeigt 96% an             ###
      # ###                                                                ###
      # ### Wo ist ENTLADUNG nach unten zu Ende ?                          ###
      # ### 2029 REPLY meldet bei "0 km" 20 (statt 0)                      ###
      # ### 8,3% = 0 km Reichweite am 15.8. - 23:32 Q: golf_soc_permanent  ###
      # ### 8,3% da 100% = 96% (= 240 / 250) gesetzt wurden = voll geladen ###
      # ### 8,3% = 8% / 96% (unteres Limit 20 / oberes Limit 240)          ###
      # ### 8% bis 96% = 88% des brutto SoC nutzbar = 100% SoC FAHRER      ###
      # ######################################################################

    ###   SoC vom GOLF aus dem WiCan   ###
    - name: "GOLF SoC [MQTT]"
      unique_id: "sensor.golf_soc_mqtt"
      state_topic: "export/golf/soc"
      state_class: "measurement"
      unit_of_measurement: "%"
      icon: mdi:battery

    ###   SoC vom GOLF mit Retain Flag. Überlebt Neustart   ###
    - name: "GOLF SoC [PERMANENT]"
      unique_id: "sensor.golf_soc_permanent"
      state_topic: "export/golf/soc_permanent"
      state_class: "measurement"
      unit_of_measurement: "%"
      icon: mdi:battery

    ###   REICHWEITE GOLF ABFRAGE ANALAOG   ###
    ###   {"bus":"0","type":"rx","ts":15850,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,217,0]}]}
    - name: "GOLF REICHWEITE"
      unique_id: "golf_reichweite"
      state_topic: "wican/1234567890/can/rx"
      state_class: "measurement"
      unit_of_measurement: "km"
      value_template: >-
        {% if value_json.frame[0].id == 1914 %}
          {% set PID = value_json.frame[0].data[3] %}
          {% if PID == 42 %}
            {% set AA = value_json.frame[0].data[6] %}
            {% if AA >= 1 %}
              {{ (AA | round(1)) }}
            {% endif %}
          {% endif %}
        {% endif %}

    ###   KM STAND GOLF ABFRAGE ANALAOG   ###
    ###   {"bus":"0","type":"rx","ts":51600,"frame":[{"id":1918,"dlc":8,"rtr":false,"extd":false,"data":[6,98,34,3,0,227,21,170]}]}
    - name: "GOLF KM STAND"
      unique_id: "golf_km_stand"
      state_topic: "wican/1234567890/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 AA = 65536 * value_json.frame[0].data[4] %}
            {% set BB = 256 * value_json.frame[0].data[5] %}
            {% set CC = value_json.frame[0].data[6] %}
            {{ ( ( AA ) + ( BB ) + CC ) }}
          {% endif %}
        {% endif %}

    ###   KM STAND GOLF mit Retain Flag. Überlebt Neustart   ###
    - name: "GOLF KM STAND [PERMANENT]"
      unique_id: "sensor.golf_km_stand_permanent"
      state_topic: "export/golf/km_stand_permanent"
      state_class: "measurement"
      unit_of_measurement: "km"
      icon: mdi:battery

The other sensors like range and odometer are the cars dashboard data.

BUT: be aware that your HA will have the real control unit values and if you open the door in the morning and the digital dashboard (PID extra) appears than its values will be those of the last time it had been on like yesterday evening, which can be different than that in your HA

This will change within seconds which means the cars display will be adjusted for example due to losses during the night in the first few seconds which the HA installation will already have.

So, works good, but awareness is needed why things can be a bit delayed or due to the architecture, but the HA connection is working fine.

Not sure how to optimize that with your new firmware but would love to hear your solution for an out of the box setup cause there are many cars in the market that would wanna get rid of the VW we connect online services like I and the JabeBRD.

But that would require a far better setup and guideline than the adventure I went through over 10 long days and full time (of cause due to the missing knowledge and experience, but I have searched the web for over a year till I ordered meatpi dongle in march). I am asking for the easier way and guide line cause right now it is hard to recommand this as a solution, just for nerds even though it is now a copy and paste of 2 design elements and tiny adjustments.

But still hard to recommand cause if you recommand it you would have to support it once someone had bought the dongle. So I am happy to hear that you are working on a "guide" or ready to use setup / profile "e-GOLF".

And JabeBRD can also talk about his e-Up cause mine is not here, just 400 km away to test it. I have mainly the e-GOLF available and could test what you might call "e-GOLF" profile.

[typxxi]

I suggest to start extending the sensors from the beginning to

• SoC
• range
• and if possible odometer

Better you do it right and then just once instead of asking people over and over again cause requests will come quite soon. Maybe also requests for latest consumption figures too.

I will add that later when I have more time, but again it is easier to have a full and nice bunch of flowers than a rotted single one.

[meatpiHQ]

@typxxi I've add a new profile for the e-gold, i only added the SoC for now. Please let me know if it works. You should try to disable your automation first and make sure to set the protocol to autopid.

https://github.com/meatpiHQ/wican-fw/releases https://github.com/meatpiHQ/wican-fw?tab=readme-ov-file#getting-started-guide

[typxxi]

yes and no, cause the car is not here, will take some time - I mean 3 weeks at least.

[e-frog]

Thanks for this project and adding the e-Golf profile! I got it running and see the SOC in Homeassistant. However the calculated SOC is not matching with the VW App and reported to high.

B4	%SOC
20	9.09
30	13.64
40	18.18
50	22.73
60	27.27

... 190 | 86.36 200 | 90.91 210 | 95.45 220 | 100.00 230 | 104.55 240 | 109.09

The raw value 20 should be 0% and 240=100% as mentioned earlier in this issue. This means the expression should be changed as following to consider the offset:

"expression": "(B4*10)/22-9.09",

[meatpiHQ]

@e-frog Have you tested this? Can you create a pull request?

[e-frog]

@meatpiHQ I've verified that the current SOC reported by WiCAN and the VW app has a constant offset of 9.09% (=20/22) on various SOC levels. In the pull request, I'm now substracting the offset directly from the raw value, which looks cleaner to me.