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

[JabeBRD]

You have wrong address, try control unit 8C, address 2021 instead, response 2029. If i remember correctly, 2015 is engine control unit, and it turns off when ignition is off and stays off when charging. Also response goes to address 2024. It is better to use control units that wake when charging.

[typxxi]

I have no clue about CAN at all (except a tiny bit). But you mean this is the right call? { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] };

My meatpi dongle setup stays the same with 2029 BMS_SOC 4 0 32 8 V/2.55 1000?

For 8c I found this

and here as an excerpt

8C Battery regulation control unit / BMS (J840)

  V_t30_8C=>{cmd=>'22 02 86', cu=>'8C', desc=>'(8C) voltage terminal 30',     unit=>'V',         d=>1,  formula=>'sprintf("%.1f", V1/12.5)'},
   SoC_g40=>{cmd=>'22 02 8C', cu=>'8C', desc=>'SoC gross (.40)',              unit=>'%',         d=>1,  formula=>'sprintf("%.2f", V1/2.5)'},                                                               # verified correct, also eGolf

...

[JabeBRD]

You are on right path, response goes to address 2029 pid 140, as you call hex 22 02 8C, that is dec 34 2 140 Setup for wican address 2029, pid 140, index 3, startbit 32, bit lenght 8

[typxxi]

Thanks JabeBRD,

with this setting I got the same soc response that I had seen in the car scanner app and fits to the digital odometer where it is hard to judge cause the gauge is small and short from maybe 7 to 11 o'clock max.

The overall response time (I mean the speed of mqtt messages and the amount) feels faster and updates more frequent like I am on the right track (just the pure believe and hope) but again still there is the key issue

The mqtt data become only visible in mqtt explorer once I have connected the car scanner app to the car which means ignition on and opening all settings, then filtering for "state" to get all "state of" sensors - or since this evening

cause I now I can choose my own carscanner app dashboard which is demanding for all SOCs. Way faster than before opening all settings and filtering and waiting.

And when the SOC figure appears then i can see in the mqtt explorer the BMS_SOC being updated frequently - till I close the app or press the back button.

EXKURS: ALSO IMPORTANT TO KNOW: If you are connected via app, then leave the car and close it the alarm system is active and turns the horn on seconds later. So close the app fully before you leave the car cause I had several alarms here meanwhile. Those alarms happened so often that it was really nerve racking during these late summer night till I got behind the cause of that just a few minutes ago. I had already before removed the dongle in the past 3 days when I left the car to avoid these alarms.

So for now I can say I get the right reply this way, the reaction is significant faster and I get more messages - or at least it feels so - but it only works with ignition on, car scanner started and SOC sensor is opened or at least visible.

And that does not really work for me at all. I would have to connect the car via app to the dashboard in the seconds of arrival and before some gets out of the car and locks it cause then the alarm device or sirene hell would be fired up again.

There must be something missing and my only guess is that this might have to deal with an older issue here regarding the e-Up when this was not reporting too (for a different reason though that has been fixed, but if you read along a lot of things feel similiar). At the end they used the same approach to arrive with the car, that connects to the WLAN and reports the SOC.

In this long topic marten-lucas mentions this What I found is, that car scanner is able to connect when the car is locked but MQTT need the car to be "drive-ready". @meatpiHQ : Do you have an idea how I could emulate the car scanner behavior to "wake up" the OBD?

And meatpiHQ replied Try this pid request, it should initialize the bus, let me know if it works. {"bus":"0","type":"tx","frame":[{"id":2015,"dlc":8,"rtr":false,"extd":false,"data":[2,1,0,170,170,170,170,170]}]}

But I am unsure if this would fit for the e-golf too or not cause it feels like a bit of myth that e-up and e-golf are pretty much the same after so many issues when I followed the idea that e-golf would follow the e-up for sure.

And 2nd I am also unsure how to achieve that.

Here is my automation "for arrival" or always when the status of the car (dongle) turns to online:

  - repeat:
      sequence:
        - condition: state
          entity_id: sensor.e_up_status
          state: online
        - service: mqtt.publish
          data:
            decription: CALL
            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/12345678901234/can/tx

        - service: mqtt.publish
          data:
            qos: "0"
            retain: true
            topic: export/e-up
            payload_template: "{{ states('sensor.e_up_soc_mqtt') }}"
        - service: mqtt.publish
          data:
            qos: "0"
            retain: true
            topic: export/soc
            payload_template: "{{ states('sensor.e_up_soc_mqtt') }}"

Finally here is the 2 mqtt sensor section from my homeassistant configuration.yaml -

1 for current SOC and #2 a SOC for longtime usage which would survive a power outage

But the 2nd one is not working - WHY ?

    # SOC vom UP aus dem WiCan
    - name: "E-UP SOC MQTT"
      unique_id: "sensor.e_up_soc_mqtt"
      state_topic: "wican/12345678901234/can/rx"
      value_template: "{{ value_json.BMS_SOC|float(0)| round(1) }}"
      icon: mdi:battery
      unit_of_measurement: "%"

    # SOC vom UP mit Retain Flag. Überlebt Neustart
    - name: "E-UP SOC PERM"
      unique_id: "sensor.e_up_soc_perm"
      state_topic: "export/e-up"
      icon: mdi:battery
      unit_of_measurement: "%"

FINAL OBSERVATION: IF ELM LOG is ENABLED the BMS_SOC will no longer be received by mqtt explorer !

[JabeBRD]

Elm logging needs to be disabled, if you send messages from homeassistant, otherwise those will be ignored. I have setup like this

• mqtt binary sensor for wican online/offline
• automation to send messages
• mqtt sensor for soc etc. You need to use template in mqtt sensor, something like {{ value_json.XX | round(0) | int }} where XX is your data name in wican, for BMS_SOC it would be value_json.BMS_SOC

There is usually one response to one message, you need automation to send messages in repeat. For automation, i have

• trigger when wican online
• send message, wait, repeat until wican offline

[typxxi]

ATTENTION: everytime there is "e-Up" mentioned an "e-GOLF" is used (code is coming from an e-Up Owner)

1

mqtt binary sensor for WiCan Online

Is working properly and switching between offline / online over the day. This status is working and shows "online" even if ignition is turned off and car is closed.

2

my genuine "e-Up" Automation seems to work cause the SOC arrives from time to time but only if the car scanner app is connected and the soc sensor shown in the dashboard of the app.

alias: "#  MQTT e-GOLF SOC  REQUEST  #"
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.e_up_status
    to: online
condition: []
action:
  - repeat:
      sequence:
        - condition: state
          entity_id: sensor.e_up_status
          state: online
        - service: mqtt.publish
          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/12345678901234/can/tx
        - service: mqtt.publish
          data:
            qos: 0
            retain: true
            topic: export/e-up
            payload_template: "{{ states('sensor.e_up_soc_mqtt') }}"
        - service: mqtt.publish
          data:
            qos: 0
            retain: true
            topic: export/soc
            payload_template: "{{ states('sensor.e_up_soc_mqtt') }}"
        - delay:
            hours: 0
            minutes: 0
            seconds: 20
            milliseconds: 0
      until:
        - condition: state
          entity_id: sensor.e_up_status
          state: offline

3

mqtt sensor for soc are these 2 where the second one is for permanent and is based on the exported mqtt afaik which means the result of the first json should be "transferred" to the soc_perm and is not directly based on the mqtt message from the WiCan dongle. At least what I had understood from the guy who is using that for his e-Up successfully.

And i have not changed the code at all except the meatpi dongle ip and the "call for the soc".

    # Wican online oder offline
    - name: "E-UP Status"
      state_topic: "wican/12345678901234/can/status"
      value_template: "{{ value_json.status }}"
      icon: mdi:car

    # SOC vom UP aus dem WiCan
    - name: "E-UP SOC MQTT"
      unique_id: "sensor.e_up_soc_mqtt"
      state_topic: "wican/12345678901234/can/rx"
      value_template: "{{ value_json.BMS_SOC|float(0)| round(1) }}"
      icon: mdi:battery
      unit_of_measurement: "%"

    # SOC vom UP mit Retain Flag. Überlebt Neustart
    - name: "E-UP SOC PERM"
      unique_id: "sensor.e_up_soc_perm"
      state_topic: "export/e-up"
      icon: mdi:battery
      unit_of_measurement: "%"

4

trigger when wican online - part of the automation shown above in #1

5

send message, wait, repeat until wican offline - again part of the automation above in #1

Meanwhile I have charged the car fully and it stopped at 94,1%. The range is 259 km , which would mean that the range would have been 275 km at 100% so I assume 5,9% degradation after 4 years and 55.000 km (95% charging at home 2,3 / 3,6 kW and less than 5% DC fast charging).

But that would then result in the question how to deal with that inside EVCC. Maybe a line below the soc might help too which is used for meters to adjust the deviation: scale = 1.0625 which then would mean for a BMS_SOC reported of 94,1% that it would be shown as 100% inside evcc.

But what is wrong that I still need to activate the car scanner app and open the SOC dashboard to receive mqtt messages inside HA mqtt broker / mqtt explorer ?

THANKS

[JabeBRD]

In wican setup do you have elm logging enabled or disabled? Needs to be disabled. Some times it doesnt save that setup, you might have to refresh page and then save it.

Also what is your current setup in wican for BMS_SOC It should be, address 2029, pid 140, index 3, startbit 32, bit lenght 8

[typxxi]

of cause disabled (otherwise nothing would arrive anymore) and what you had written before - and I have also checked that which means I did a reboot and also pulled the dongle out and pushed it back, then I have reloaded the page with CTRL + F5

Meanwhile I did a search in that big file for all possible soc and soc.

Here as a screenshot first with the best overview

and as text

# 01 Engine/motor control unit (J623)
* SoC_n01=>{cmd=>'22 11 64', cu=>'01', desc=>'SoC net (.01)',                
* SoC_std_tgt=>{cmd=>'22 14 8F', cu=>'01', desc=>'SoC standard. target value'
* SoC_g01=>{cmd=>'22 16 18', cu=>'01', desc=>'SoC gross (.01)',              
* SoC_g39=>{cmd=>'22 F4 5B', cu=>'01', desc=>'SoC gross (.39)',              

# 19 CAN Gateway / Data bus diagnostic interface (J533) (e-Golf PIDs)
* HV_SOC_19=>{cmd=>'22 1D D0', cu=>'19', desc=>'HV batt displayed SOC',      

# 8C Battery regulation control unit / BMS (J840)
* SoC_g40=>{cmd=>'22 02 8C', cu=>'8C', desc=>'SoC gross (.40)',              

# BD Charge voltage control unit for high-voltage battery (J966)
* BD_SoC_n50=>{cmd=>'22 1D D0', cu=>'BD', desc=>'SoC net displayed', 

This also solves the mystery of "94,1% SOC = full" as seen in the car scanner app and reported in evcc / ha cause that ID is the gross SOC with a 6% buffer so more or less 6% x 36 kWh = 2,2 kWh

The one that looks the best by description would be the last one "SoC net displayed" (it was displayed in earlier eGOLF versions and then removed by VW during an update. I have that digital cockpit and there is noc SOC figure.

But I guess there is still something wrong cause there is @MrSaiclops struggling with a similiar or same issue here . And there before he jumped into the discussion @marten-lucas also mentioned that "the PID 91 (in Hex 5B) is the SoC (gross)" and "The correct pid would be SoC (,net):" { "bus": "0", "type": "tx", "frame": [{ "id": 2016, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 244, 91, 170, 170, 170, 170] }] } Explaination: 3 b/c the pid is 4 byte long. mode 0x22 (34) is custom. 0xF4 (244) 0x5B (91) is the pid.

https://github.com/meatpiHQ/wican-fw/issues/17#issuecomment-1641850205

Unfortunatelly more questions then answers but at least the replies are coming instantly and more fluent without the hickups i had seen before.

[typxxi]

You are on right path, response goes to address 2029 pid 140, as you call hex 22 02 8C, that is dec 34 2 140 Setup for wican address 2029, pid 140, index 3, startbit 32, bit lenght 8

What I can understand ist the "hex 22 02 8C is dec 34 2 140" part, but how did you get the 2029 ? Pid 140 can be the last value of "34 2 140".

For example what about this control unit 01 Engine/motor control unit (J623) and SoC_n01=>{cmd=>'22 11 64', cu=>'01', desc=>'SoC net (.01)'

hexad = dezimal 22 = 34 11 = 17 64 = 100 and therefore it should be this kind "Payload", but again what is the right ID ? And what Meatpi dongle settings would I need, too?

​            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": ????, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 17, 100, 170, 170,
              170, 170] }] }

Same question for the control unit BD and this "22 1D D0" line from here BD_SoC_n50=>{cmd=>'22 1D D0', cu=>'BD', desc=>'SoC net displayed'​

hexad = dezimal 22 = 34 1D = 29 D0 = 208

and therefore it should be this kind "Payload", but again the ID might be wrong or missing again. And what Meatpi dongle settings would I need, too?

​            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": ????, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 29, 208, 170, 170,
              170, 170] }] }

Tons of questions or at least opportunities to succeed. Better than I would have no more options to test.

thanks

[JabeBRD]

Here https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/ 8C (7E5/7ED) hex 7E5 is dec 2021

[JabeBRD]

Last time i checked with e-Up my soc was about right, with PID 140 from 2029, i have calculation ((value - 24)/2,15) I would suggest to get also RAW value from wican if you want to tweak your soc readout in home assistant and evcc, for that use expression B4, thats how i ended up with my calculation. PID 140 gives value 240 when 100%. What i have found is that e-Up and Passat GTE dont have same PID:s, some work and some dont, so that must be case with e-Golf, but both my cars respond to PID 140 same way.

I have setup like this for wican - HA - evcc setup. Wican sends raw value of SOC -> HA receives that with mqtt sensor -> HA calculates that SOC with helper -> helper is broadcasted with mqtt_statestream -> evcc reads that processed SOC from mqtt. All mqtt_statestream messages are retained as default. I have evcc running "inside" HA.

[typxxi]

Here https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/ 8C (7E5/7ED) hex 7E5 is dec 2021

That is a really good help for all those who are starting cause that is not part of the list here or I might have overlooked that cause that mentions this

8C Battery regulation control unit / BMS (J840) but is J840 hex ? No, j8 was not translated cause hex ends with f I guess.

So any control device 8C can be decoded with your source and I will try that later. Really great help and teaching me to get a bit further.

AND QUESTION: how do I get behind how to set up the meat pi dongle properly ? I mean this CAN ID line on the bottom of the meatpi browser setting page. Thanks

[JabeBRD]

BMS (J840) = BMS is just VAG way to say control units name, abbreviation of some german words, (J840) is identification name for that control unit used in workshops, workshop manuals, its name of that component. I really dont (yet) know how to get that hex or dec address from control unit if its unknown. You can see return address in can messages. Meaby someone can direct to right direction. Currently i use addresses that someone has found, like in that list.

I have no setup currently on Wican dongle, HA makes all in sensor templates. Example:

    - name: "e-Up!_battery_soc"
      unique_id: "eup_battery_soc"
      state_topic: "wican/e-up/can/rx"
      state_class: "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 - 24)/2.15) | round(0) | int }}
        {% endif %}
        {% endif %}

[typxxi]

I am german so easy to understand the german stuff or the VAG slang Volkswagen Audi Gruppe from 1990s or so.

I guess you are not using this option meatpi has called filtering which is "transfering" and ID 2029 and its response to that term BMS_SOC (they call name) and the expression / calculation of the value

And you are doing this jobe with your value template.

I will now try to start using adress by adress I had found in the list and see if I can find the right one which fits to 100% as shown in the instrument cluster as a graph on the lower left in my digital cockpit. Only for drive unit 19 the header is missing (at least in that e-Up list). Thanks

[typxxi]

and I also found more regarding the range displayed / calculated thing in the list too:

17 Header 714 hex = 1812 decimal - Control unit in dash panel insert (J285) = Schalttafeleinsatz

* rng_disp=>{cmd=>'22 22 E0', cu=>'17', desc=>'displayed range',               unit=>'km', d=>2,  formula=>'U16(V1,V2)'},  # verified, also eGolf
* rng_calc=>{cmd=>'22 22 E1', cu=>'17', desc=>'calculated range',              unit=>'km', d=>2,  formula=>'U16(V1,V2)'},  # verified, also eGolf
* rngcons_red=>{cmd=>'22 22 E2', cu=>'17', desc=>'range consumption damping',  unit=>'km', d=>1,  formula=>'V1'},
* kwh_cons=>{cmd=>'22 22 E3', cu=>'17', desc=>'consumption',                   unit=>'kWh/100km', d=>2,  formula=>'sprintf("%.1f", U16(V1,V2)/10)'}
* rng_cap=>{cmd=>'22 22 E4', cu=>'17', desc=>'remaining energy',               unit=>'kWh',       d=>2,  formula=>'sprintf("%.1f", U16(V1,V2)/10)'}

[JabeBRD]

I had it on use, but now as im trying to figure out some messages, i found it easier to delete all. If you want messages from 8C, send to 2021, receive from 2029, so wican has ID 2029.

That 17 is propably not going to work very well, as it is not online when ignition off but charging, for range i just found 19 (CAN Gateway) has that value in hex 22 2A B6, with help of that document from obd amicos that you posted.

[typxxi]

I have tried to call some requests from the other control units and used this as payload for

BD Header 765 hex = 1893 decimal - Charge voltage control unit = SoC net displayed BD_SoC_n50=>{cmd=>'22 1D D0' => decimal 34 29 208

            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 1893, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 29, 208, 170, 170,
              170, 170] }] }

and for 01 Header 7E0 hex = 2016 SoC_n01=>{cmd=>'22 11 64 => decimal 34 17 100 I have used this

            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 2016, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 17, 100, 170, 170,
              170, 170] }] }

I have now 3 different automations using the control units 01 and BC (my old one from yesterday) and BD. Nothing arrives until I open my Carscann App Dashboard with the SOC

I turn all of my automations off and then I turn on one and do my tests, turn that off and start with the next automation.

Nothing arrives until I start car scanner App and my SOC dashboard. And then it feels like I always get the same figures, exactly those from the dashboard.

I believe that meatpi dongle is only responding 1 thing the 2029 BMS_SOC and that is always the same regardless which of the requests above I am using.

And if I do not know that filtering needed here in these boxes

nothing will change. Car Scanner simply acts as an enabler that allows the meatpi mqtt messenger to send the message out, I mean the same from the screenshot here: always 2029 and never something different.

And if CAN and mqtt works the way that I can send a query from my automation like this for the "BD" Charge voltage control unit to show me the SoC net displayed or as it is called in the list BD_SoC_n50=> '22 1D D0' => decimal 34 29 208

            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 1893, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 29, 208, 170, 170,
              170, 170] }] }

then I should only get 1 reply and only from this 1 unit / item back.

If that is true your solution should deliver the reply in this sensor I guess

 - name: "e-Up!_battery_soc"
      unique_id: "eup_battery_soc"
      state_topic: "wican/e-up/can/rx"
      state_class: "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 - 24)/2.15) | round(0) | int }}
        {% endif %}
        {% endif %}

I had thought some how that with changing my automation I would get different results but I can not get that as long as the filter is in space and "limiting" the replies to the filtered messages from 2029 or so.

How do you know about the adress of the reply in advance ?

Let s take the example from above:

asking from my automation for the "BD" Charge voltage control unit to show me the SoC net displayed or as it is called in the list BD_SoC_n50=> '22 1D D0' => decimal 34 29 208

            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 1893, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 29, 208, 170, 170,
              170, 170] }] }

And now while searching for '22 1D D0' in the perl list I saw that his is used by 2 control units: "BD" Charge voltage control unit as BD_SoC_n50 and "19" CAN Gateway / Data bus diagnostic as HV batt displayed SOC

Anyway: you also mentioned control unit "17" would not be usefull but for me it could work out cause I expect to arrive home and that then the stick gets online and the automation will kick in to read SOC and range while I am in the car.

And like seen for the SOC I can use the soc and soc_permanent and similiar range and range_permanent where permanent would save the value and survive a crash this way. If I arrive with 50 km and 20% of charge then I am able to do the range calculation on my own by looking for current state of charge like 60% and do the 60% / 20% x 50 km = 150 km expected range. Therefore I think it is good enough for me to be useable and usefull. The difference between HA calculations and car dashboard might be under 10 km this way. Not more.

So, right now I hope to implement your code for the replies from the obd and I hope that when I ask for this

            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 1893, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 29, 208, 170, 170,
              170, 170] }] }

that I will get just 1 repsonse and nothing more once I have deleted the current filter.

[JabeBRD]

I would suggest to delete all filters from wican, then use different browser to verify that settings are like they should be. Then when no filters, send some of your requests to wican and see if there is any response. And for how i know what response is, i need to get on, check it and then make filter, send request and see how it responds, what is allready known when sending is address and pid. Like 2021 responds to 2029, then i look for my pid in response. See here https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/

Auswertung: Die Antwort erfolgt in der Form <xx yy zz aa bb...>, wobei <xx yy zz> die Wiederholung der Anfrage ist (mit 0x40 addiert bei xx). Wie die eigentlichen Daten ab "aa" auszuwerten sind steht jeweils in der Tabelle.

[typxxi]

I have not checked your last message when I did decide to remove the filters (8 hours ago) and found out this

I removed the filter from the wican dongle and since then I received thousands of messages, each second 1 or 2 or 3 WiCan messages. I have no clue how to log them and read or check one but I was able to watch it over and over again when it starts from 1000 or 2000 onwards up to 55550 or so.

AND: I also saw a 2029 reply from the dongle, but I had not time to copy that or anything else cause the next messages was already there.

I also copied your code but the configuration.yaml is complaing about this Not sure what went wrong but the sensor is also missing.

But also I have found something new that looks helpfull which you can see here and is called autopid and stops the need of an automation. Not sure, but I like it and it might auto fire the soc without any request at all.

Not sure, but if feels and has helped the renault kangoo owner too who could not achieve much before that. That software is the current 3.11 beta - but who cares about beta if I have no results from the stable version.

UPDATE:

I finally flashed that beta version at midnight or so and tried to fill the automation in the dongle, but not sure if only "190" as pid would be enough to get the messages and to what "topic" I should send them. I have tried the wican/12345678901234/soc - no success

I will now read your last message and have a further look into that what you had linked. Car is gone and I usually do all the tests during evening and night to disturb no one.

tHanks a lot

[JabeBRD]

I use MQTT Explorer on windows, send tx message, then press pause and browse rx messages, what i got as answer. Your YAML code seems defect, its missing >- after value_template, also you need correct indentation. Please look under home assistant MQTT sensor, how to setup. https://www.home-assistant.io/integrations/sensor.mqtt/ I use multiple files, i have no sensors are written directly to configuration.yaml, thats why my sensor didnt work as is. I can share my yaml file, later this week. You can also install MQTT Explorer to HA as addon, you just need to keep that browser page open all the time otherwise you need to login again and lose all messages that was received earlier.

[typxxi]

Hi, regarding the code you had thankfully provided here there was a space missing during paste here on github.

The >- is there but the "error message" has killed that for what ever reason. I have changed nothing and still have the same message when I rebooted 1 hour ago.

Here is the screenshot from my yaml

Here is the message I still get (and I have changed nothing since I pasted that code - except adding GOLF)

Here is the code (incl. the 1 space that was missing above)

    - name: "e-UpGolf_battery_soc"
      unique_id: "e_upgolf_battery_soc"
      state_topic: "wican/12345678901234/can/rx"
      #      state_topic: "wican/e-up/can/rx"
      state_class: "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 - 24)/2.15) | round(0) | int }}
        {% endif %}
        {% endif %}

Of cause I have changed the topic for a test run. thanks a lot for supporting my dad cause it his system and golf car that needs to run cause he is 86 years old and has moved to electric vehicel 5 years ago when we build the first solar power system on our own.

[JabeBRD]

I think your just missing

mqtt:
  sensor:

or just sensor:

I have setup in configuration.yaml

homeassistant:
  packages: !include_dir_named packages

Then i have folder named packages inside config folder. Inside packages folder i have file named wican.yaml, this file name can be about anything, its for just your usage, filename doesnt do anything. In wican.yaml i have this:

mqtt:
  sensor:     
    - name: "e-Up!_battery_soc"
      unique_id: "eup_battery_soc"
      state_topic: "wican/e-up/can/rx"
      state_class: "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 - 24)/2.15) | round(0) | int }}
        {% endif %}
        {% endif %}

If you put everything inside configuration.yaml remember to check indentation.

[typxxi]

you were right with I think your just missing ... mqtt: sensor:

I have moved the section below my mqtt sensor section here and I get a value of 91%

and here the result with a soc of 91%

Which is 3% off cause car scanner shows 88,0% now.

[JabeBRD]

Is it now working as expected, or do you still need to connect car scanner to get result?

[typxxi]

I guess, but I am not sure cause for the most of the time during my tests today the app was open. I have to check that later, but I guess it worked. This image shows a non linear behaviour cause during night I had filters turned on and you can see when I disabled those filters.

The sensor is working since around 01 am when I had moved your code under that mqtt section.

Now you can see a SOC of 100,5% which means the car is fully charged and does not charge anymore.

BUT: After all these hours in the car it seems to work even though some points are still open questions.

1. Did you adopt the formula and does that represent the real SOC ? Might sound weird, cause car scanner offers me 2 sensors for SOC (when I filter for "state") One is the gross SOC called "State off charge" at 94,12% the other "NET = USEABLE CAPACITY SOC" is called "HV battery charge state: absolute value" at 96,0% This is the one I am looking for and will talk about

2. When that SOC was at 88% this morning your code was reporting 91% before surplus charging started. And I guess you have adopted your "divider" of 2.15 in the configuration.yaml here to match 100% when fully charged. I have changed this line {{ ((AA - 24)/2.15) | round(0) | int }} to {{ ((AA - 24)/2.15) | round(1) }} cause I need 1 decimal to start and therefore increased round to (1) and removed integer cause I do need the decimal

   • at least in the beginning.

     If you have adjusted the 2.15 to match your 100% I would adjust that too by using this {{ ((AA - 24)/2.405) | round(1) }}

3. I have been driven 1 km to lower the SOC a bit and had hopped that when I do return the meatpi dongle would connect and report the new SOC. Has not worked, mqtt is running, but the sensor says last updated 29 minutes ago. After 10 minutes I had already used the key and turned on the car and afterwards off, but key is still in the car. No luck, no sensor update. Then I did a Home Assistant reboot and nothing has changed, except the SOC sensor is now unknown
4. it needs the CarScanner App which has to be opened and I have to select one of the 3 sensors that match my "filter" criteria "state"

My key question is what do you do in your HA / WiCan setup that the control unit is sending that can id 2029 data / json ?

I have gone back up when we started and you mentioned this

Wican sends raw value of SOC -> HA receives that with mqtt sensor -> HA calculates that SOC with helper -> helper is broadcasted with mqtt_statestream -> evcc reads that processed SOC from mqtt.

Right now my sensor is working, but only if I connect my Car Scanner app to the car and ask for SOC.

But what are you doing that "Wican sends rave value of SOC" or did I overlook a "WiCan" Setup you have done ?

Thanks a lot

[typxxi]

I guess you have meant the WiCan Dongle setup with this remark from the top which I had NO LONGER on my WiCan since I downgraded to firmware 2.98 !

I will set the dongle up that way once the car is back in the garage this evening to look what will happen. I guess the WiCan Dongle then should only send this data

goes to address 2029 pid 140, as you call hex 22 02 8C, that is dec 34 2 140 Wican address 2029, pid 140, index 3, startbit 32, bit lenght 8

and there is no name required cause you are doing the decoding on the sensor side once the message has arrived Home Assistant.

But what are you using as expression cause that is mandatory ?

B1 maybe ?

[typxxi]

Here is my WiCan Dongle Setup

Here is my automation call for

            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/12345678901234/can/tx

And I should get a reply from id 2029 where you would use the 4th data element I guess in your formula to calculate the SOC by (4th Element -24 ) / 2.15

      {% set AA = value_json.frame[0].data[4] %}
        {{ ((AA - 24)/2.15) | round(0) | int }}

[JabeBRD]

If you use this code

    - name: "e-UpGolf_battery_soc"
      unique_id: "e_upgolf_battery_soc"
      state_topic: "wican/12345678901234/can/rx"
      #      state_topic: "wican/e-up/can/rx"
      state_class: "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 - 24)/2.15) | round(0) | int }}
        {% endif %}
        {% endif %}

Then there can be no filters in wican, no expressions. Wican needs to send everything in raw. With this code HA does same job than Wican filters, thats why there can be no filters in wican. You need to check MQTT messages, is there any TX messages in wican mqtt topic, is your automation working. I see you have [**3, 34, 2, 140** in your TX message, please remove **.

[typxxi]

Ok, now I understand. The first part of your comments help for a solution based on wican filters and how to set it up properly.

But since we started talking about the mqtt sensor integration it is a native solution and plain decoding inside HA by the sensor.

Unfortunatelly I can see the calls or requests from my automation in the mqtt explorer page here, but no replies

I have not a single 3, 34, 2, 140 message seen in 5 minutes I observe and search for all incoming "2029" messages and none arrrived in minutes even though every 6 seconds the automation starts the request as seen above.

So something must be wrong or rather I am asking the wrong question ATTENTION: the seen above were github formattings I have removed now, they were and are not part of the automation. I wondered where you had gotten these from till I realized that my formatting had gone wrong.

            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/12345678901234/can/tx

What can I do next ?

thanks for your great support here asking all my questions so easily ! Hats off !

[typxxi]

Here https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/ 8C (7E5/7ED) hex 7E5 is dec 2021

is this last line or in particular the figures (7E5/7ED) the secret behind how to ask and from where to expect the reply ?

as you said 7E5 is decimal 2021 which I am asking for a reply and then the 7ED is decimal 2029 which is the reply you were using for the sensor to get the data.

I started reading again from the beginning how this whole thing works and how I can adress myself objects from the big blackl list of control units

I wanna try to build a simple mqtt question and answer that works to start with or from cause right now I am just copy and pasting lilke hell with not much luck and good results. thank you

[JabeBRD]

I can see you are getting lots of RX messages with this data {""bus"":""0"",""type"":""rx"",""ts"":15839,""frame"":[{""id"":401604624,""dlc"":8,""rtr"":false,""extd"":true,""data"":[32,16,0,0,0,0,0,0]}]} I get those also with Passat GTE. Its realy hard to spot right replys as those messages flood RX topic. What i have, is MQTT sensor that reads all messages from RX topic, then i can read those from HA history page and export as .csv file, makes it easier. Now i added value_template on that sensor to block all those unwanted messages, it becomes much easier to read what messages have been received. Setup sensor like this

    - name: "Passat_GTE_raw_data"
      unique_id: "passat_raw_data"
      state_topic: "wican/passat/can/rx"
      value_template: >-
        {% if not value_json.frame[0].id == 401604624 %}
          {{ value }}
        {% endif %}

Just add that sensor, do not replace SOC sensor, with this you can log mqtt messages, without need of mqtt explorer running. And ofcourse you can make sensor on TX topic, to log what wican receives, then just use "{{ value }}" in value_template for that sensor to allow all messages. BTW have you checked in wican setup that TX topic is configured correctly, no typos?

[typxxi]

Thanks a lot, you meant the mqtt section ?

Factory resetted and nothing changed which means it is right BUT I was able to recognice something too in the mqtt explorer section.

I got every 6 seconds a 2029 reply with different values. Sometime I got 2 of them within a second, but my automation fires those requests also every 6 seconds. And if I use STRG + f on the UI of the history messages it jumps from 1 message to the other like here at 28 seconds

Here is the overview over the 3 requests

and here the replies I have cut together cause the history window is so tiny

Therefore I guess my requests causes these replies.

AND FINALLY:

I will try what you have suggested tomorrow morning regarding another sensor collecting all the replies if I remember that right.

[typxxi]

Just add that sensor, do not replace SOC sensor, with this you can log mqtt messages, without need of mqtt explorer running. And ofcourse you can make sensor on TX topic, to log what wican receives, then just use "{{ value }}" in value_template for that sensor to allow all messages. BTW have you checked in wican setup that TX topic is configured correctly, no typos?

I have added 2 more sensors for RX as you had described it and also for TX

    - name: "GOLF_raw_data_tx"
      unique_id: "golf_raw_data_tx"
      state_topic: "wican/passat/can/tx"
      value_template: >-
          {{ value }}

The if condition has gone cause the "tx" channel is "driven" by automation(s) that usually fire up every 6 seconds, but just 1 automation.

I have to reboot HA now and wait what will arrive in those new sensors.

[JabeBRD]

Yes, just to record all mqtt messages in HA.

But for responds, i can see you are getting value of 179. In address 2029 there is data containing pid 140 (3th byte) and after that in 4th byte is value. Bytes start counting from 0.

So it looks like wican is working. Now you can leave it as is, or make mqtt filter in wican to send only message containing value of pid 140. Then it will send only that nothing else. But if you like to have more data out (like range etc) , i would suggest to leave it as is, untill you get all data figured out.

Sensor in TX topic, should have "no template", just "{{ value }}"

[typxxi]

1. COLLECTOR SENSORS

Those 2 new sensors are collecting calls which I have already exported via "show more" where you can select the time span on the left , but I had used the 3 dot menu on the upper right to export all data and got after a few minutes already 500 or more data, not sure if 250 data points or 500 , but a very easy to read table, where I found only 2 answers

2. COLLECTOR RESULTS

I have cleaned the logs and got this:

TRANSMIT TO GOLF REQUEST [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 0, 170, 170, 170, 170, 170] } [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }

REPLIES SORTED [{"id":2024,"dlc":8,"rtr":false,"extd":false,"data":[6,65,0,152,24,0,17,0]}] [{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,172,170,170,170]}]

Both of these were initiated by 2 of my automations. And regarding 2029 and the 4th value the 172 looks like it must be the soc cause during the hours last 9 pm to 2 am I could see (ignition was on, lights therefore also on) the SOC dropping every hours by about 0,4% or so and the 172 decreased the whole time.

CURRENT ISSUE: FORMATTING OF THE SENSOR

Only issue I have is the conversion or should I rather say formatting of the new sensor cause I have calculated those down to 0,8 format but I do not know how to convert that into unit "%". If I had done it via configuration.yaml and unit of measurement: "%" the values were calculated wrong for what ever reason, instead of 80 or 80% I got a 16000 figure out of nowhere and turned that off again.

I guess it can be fixed here {{ ((AA - 24)/2.15) | round(0) | int }} where I am using so far this for reasons mentioned below {{ ((AA - 24)/2.5) | round(1) }}

I know there is a function %f2 or so that does the trick but I can't remember.

I had accidantly close the issue but wanna wait till everything is working fine. Will take a few days to see those different SOC from 5% to 95% I guess and adjust that 2.15 conversion factor.

4. e-GOLF SOC CONVERSION FORMULAR

Right now Car Scanner showed 65,2% and the 4th bit was 163 I played around with the usual e-golf and e-up formulars like 163 / 2,55 where that SOC had been a bit low.

And then I observed in car scanner the SOC which only increases / decreases by 0,4% So I waited for the moment of the next jump like 65,6% to 66% and then turned wifi of to check the mqtt explorer messages where I could see the last 20 seconds maybe and also the last jump from 174 to 175

5. STEP BY STEP GUIDE FROM REQUEST OVER REPLY TO SOC CALCULATION

REQUEST TRANSMITTED TO GOLF by AUTOMATION EVERY 6 SECOND (TEST PHASE, later 1 min) [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 0, 170, 170, 170, 170, 170] } [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }

REPLIES FROM THE GOLF [{"id":2024,"dlc":8,"rtr":false,"extd":false,"data":[6,65,0,152,24,0,17,0]}] [{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,172,170,170,170]}]

FULL SOC REPLY by 2029 NEEDED LOOKS LIKE {"bus":"0","type":"rx","ts":17647,"frame":[{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,167,170,170,170]}]}

RELEVANT FOR SOC CALCULATION [{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,167,170,170,170]}]

SOC VALUE IS THE 4th ELEMENT / BIT OF THIS EXCERPT [4,98,2,140,167,170,170,170]

SIDENOTE: the SOC is measured in 0,4% steps each representing how man Wh ? 0,4% x 32 kWh BATTERY = 128 Wh per "0,4%" 0,4% = 128 Wh = 0,128 kWh

RESULTS AND POINTS I HAD PROOFED

CAR        mqtt    FORMU-  =   SOC
SCAN-      reply   LAR         calculated 
NER        2029                by
           4th                 HA 
           "bit"
=======================================
65,6 %  =  164     /  2,5  =   65,6%
66,0 %
66,4 %
66,8 % 
67,2 % 
67,6 %
68,0 %  =  170     /  2,5  =   68,0%
68,4 %
68,8 %
69,2 %
69,6 %  =  174     /  2,5  =   69,6%
70,0 %  =  175     /  2,5  =   70,0%

76,0 %  =  190     /  2,5  =   76,0%

next exit Brooklyn Bridge

I have to check the automation when the ignition is turned off. Then I have to check if that SOC transmission works during a usual arrival and departure out of the garage from WLAN to HA, I mean the whole procedure of connecting to the WLAN, the automation has to start and mqtt has to work too and maybe even more.

[JabeBRD]

Trick is to apply filter on RX topic sensor, to filter unwanted data, avoid flooding. Thats why i have in value_template if not command. 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.

Hint. Make template helper in HA ui, or use template editor under develop tools, no need to restart ha to see how calculation worked. Example here https://community.home-assistant.io/t/parse-json-in-helper-gives-error-works-in-sensor/758498

[typxxi]

While you were writing I was editing my comment cause I have already done most of the steps.

Please read my updated and far longer comment above.

In short: I have investigated the SOC developelment along the curve for 10 points from 50% to 80% with Car Scanner and compared those car scanner values with that I got from the 2029 replies and my calculation of SOC 4th bit / 2,5 ... if the first element starts as 0

The figures match perfectly, each 0,4% fitted which means every 0,128 kWh the SOC is updated by 1 in the 2029 reply you had shown me to setup in the configuration.yaml 100 % / 0,4% = 250 steps for 100% - quite nice

It took literally minutes to get behind the formula cause your GTE 2,15 was a bit off and I knew from e-Up the 2,55 and tried that again. A bit too much, so I tried 2,5 as next step. Great, and then I started Car Scanner and waited for the moment the SOC would increase again by 0,4% displayed as a jump in the graph and STOP WLAN. Then I went into mqtt Explorer history with its most recent 99+ replies and pressed CTRL + f to search for 2029 where I usually get 9 to 13 results and checked those for the 4th bit and its change: always +1

I will need such helper later when I have found out again what SOC of the car can be reached fully charged. I had seen already 96% max. in the past days and then the SOC helper should do that SOC REAL = 100% conversion.

OF CAUSE ALWAYS A GREAT TIP the use of template editor to save the time a reboot would require with unknown results while template editor gives an instant report. My biggest challenge now is the conversion of SOC into a % figure.

[JabeBRD]

You dont convert it to %, you just need to figure value, HA just adds % symbol, if it is defined in unit_of_measurement: line, you can put any symbol/text on that line and that will be added after value. But remember that car scanner calculates this value, just like your doing right now, i would compare your calculation to car display only. For evcc use, just make sure your calculation doesnt exceed 100% thats why i use round(0) On pid 140, value 240=100%

[typxxi]

You dont convert it to %, you just need to figure value, HA just adds % symbol, if it is defined in unit_of_measurement: line, you can put any symbol/text on that line and that will be added after value. But remember that car scanner calculates this value, just like your doing right now, i would compare your calculation to car display only. For evcc use, just make sure your calculation doesnt exceed 100% thats why i use round(0) On pid 140, value 240=100%

I had added this line

unit of measurement: "%"

here

      unique_id: "e_golf_soc"
      state_topic: "wican/12345678901234/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) / 2.5) / 100 | round(1) }}
        {% endif %}
        {% endif %}

The result was a huge spike of 16000 or so , but I guess it might be fixable with a helper as you had mentioned. At least just adding the line had not worked out for me, but I will try it again later.

Once again: I have no SOC display in the e-GOLF or e-Up. Those had been removed in the 2010s by VW. There is just a kind of bar on the left gauge which represents 0 - 100% on the clock face from roughly 7to 10 o'clock or 90° which is not a lot and looks like it has a height of maybe 100 pixel.

I want to wait till the car is fully charged and what SOC reply I will get then, the 96% as HV Battery Charge Absolut Value (car scanner term) which I had seen before last week or if I get further. In the end I will try to cross check the major points of 25% / 50% / 75% / 100% = fully charged and then adjust the 2.5 factor.

Still charging from "209" = 83,6% till the charger stops in 40 minutes or so.

And then i am playing with the wake up request cause once I have arrived and the door is closed I get no more 2029 replies and hope to reanimate the flow this way again as Meatpi has recommended. That thing was called bus activator to awake the bus again.

{ "bus": "0", "type": "tx", "frame": [{ "id": 2015, "dlc": 8, "rtr": false, "extd": false, "data": [2, 1, 0, 170, 170, 170, 170, 170] }] }

If I open the (unlocked) door the replies come in again.

My Calculation is quite simple and can not go over the 100% cause I take the reply and divide that by 2,5 I have 250 steps each 0,4% so any figure the car would send should not be greater than 250.

Maybe charging will stop with a sensor value 96% and that would mean 4% less or 10 steps each 0,4% If I have 250 steps max from 0% to 100% then 10 steps less would mean it stops charging around 239 or 241.

I do not use the 24 you had used cause that did not fit. But I have to cross check that later, when the car is empty and I can charge from maybe 2% to full and check if the range marks for 25% / 50% / 75% and 100% fit together.

Btw: You have a Passat GTE we had been looking for too in 2019 or so when they did not accept new orders or told people "sold out" - I mean the pre Corona year. How much range can you get out of the battery and which size is the battery ? I can not remember. Can you get such range driving electric VW had promised when the car was sold ?

Thanks a lot - big step forward today.

FINAL QUESTION: What kind of figure is evcc expecting: 0,66 or 66% or 66 ?

Right now evcc is not happy with my sensor values provided via mqtt. Might be a setup issue cause it feels like evcc is getting lots of the SOC values insted of just the most recent according to this LOG screenshot

UPDATE: FINALLY CAR IS FULLY CHARGED AND STOPPED AT 96%

Same figure I had seen before last week. So I will have to adjust my SOC for display this way:

SOC (from 2029 reply) x 100 / 96

to get 100% shown in HA as SOC. The raw value from the 2029 reply is 240 and therefore I will do my "SoC for display" calculation directly with

SOC (from 2029 reply) / 240

[JabeBRD]

It looks like you have commented out your unit_of_measurement: "%" with # I also had some issue using divider \, it made calculation wrong. Test calculation in template editor first. With e-Up i have had lowest battery value of 48, vw app showed 11%. So 0% would be something else than value 0. Both e-Up and Passat divide battery gauge ("fuel gauge") to 8, so one bar is around 12,5%. My Passat is my20, ~13kWh battery, max range displayed is around 50km, had also my18 with 10kWh battery but it didnt last 30km on highway, battery was empty around 25km, with 13kWh battery it does 35km on highway easily, bigger battery made big differense.

Evcc needs value betwene 0-100, i would suggest to use mqtt_statestream service to broadcast your soc sensor.

[typxxi]

It looks like you have commented out your unit_of_measurement: "%" with #

no, that was after I had recogniced that it did not really work for me that way. I use those # comments to remind me and avoid trying it again.

I also had some issue using divider \, it made calculation wrong. Test calculation in template editor first.

looks like that I had solved it meanwhile by simply dividing the aa figure / 240

With e-Up i have had lowest battery value of 48, vw app showed 11%. So 0% would be something else than value 0.

OK, this is something I have to cross check on thursday cause then the car comes back at a charge of 15 km left which is the easiest way. I have already driven the e-golf 25 km beyond 0 but then gave up to drive 400 circles around the neighbourhood. So there is a life beyond 0 km of range when VW decided to no longer tell you anything cause range disappears at some point below 10 km of range.

Both e-Up and Passat divide battery gauge ("fuel gauge") to 8, so one bar is around 12,5%. My Passat is my20, ~13kWh battery, max range displayed is around 50km, had also my18 with 10kWh battery but it didnt last 30km on highway, battery was empty around 25km, with 13kWh battery it does 35km on highway easily, bigger battery made big differense.

Sorry, but the digital instrument cluster of our eGOLF might be different even though it has deviders but they feel not good - yes, you can identiy a quarter or half but beyond that there is not much.

And what do my18 and my20 mean ? Never heard it before. Sounds funny like you were in your 18s or 20s, my 18th, my 20th but can not imagine what it means regarding a car.

Evcc needs value betwene 0-100, i would suggest to use mqtt_statestream service to broadcast your soc sensor.

Well, thanks a lot but I had evcc already a working before but only with the crazy workaround to jump into the car, ignition on, loggin into the car with car scanner app and a SOC dashboard to trigger or deliver an initial SOC before charging.

To make that happening I used a mqtt sensor inside evcc.yaml which is running under HA as addon (on a pi 4).

Here is the excerpt from the car section of that yaml. The issues were caused not by the value itself, but somehow the mqtt sensor got multiple values in it like 95.0001 95.0001 95.0001 95.0001 95.0001 95.0001 95.0001 95.0001 95.0001 95.0001

maybe cause by a wrong retain in the automation or whatsoever, but now that has gone

  - name: vw
    title: GOLF
    type: custom
    ###       type: template
    ###       template: offline
    icon: car
    capacity: 32.0 # net capacity in kWh
    phases: 2
    ######  depreciated target soc: 80
    ######  depreciated mode: pv # charge mode (off, now, minpv, pv)
    soc:
      source: mqtt
      topic: export/golf

Later this evening I wanna make a testride cause there is also another "issue" of a different kind.

If the car s ignition is turned on already or at least the wican dongle is online then the automation does not work if you reboot HA or that running automation has stopped once for what ever reason.

Therefore I had added a second trigger which I always had to adjust manually, cause it was a time trigger. Unfortunatelly there is no time trigger like "if it is past 1 pm then". Only for a curtain point so I had to edit that value seconds ahead of the current time each time and hurry to save it.

I did not find any way around that so I had waited quite often for mqtt explorer data which never would arrive cause the automation had not asked for that. Lot of stuff to learn each day and so many surprises.

i hope this time it will work for the first time when I will return from the grocery shopping later. Fingers crossed, spent roughly 10 days with the whole 3 phase charger installation as Surplus charger and the move from a dedicated pi for evcc to an installation under HA addon with the 6 inverters we are running right now.

thanks a lot

[JabeBRD]

my18 stands for Model Year 2018, model year is different than when car is produced, example my18 might have left factory 10/17

You can make automation to fire automations when HA is started, just give some time delay for everything to start

trigger:
  - platform: homeassistant
    event: start

Also evcc running/not running state can be used.

[typxxi]

Ah, that automation autofire action sounds good.

The my20 Passat with bigger battery sounds a lot better but even that could have been easily a 16-20 kWh battery to give a good range of 100 km while driving electric. We have here a my21 and my22 I guess.

Also meanwhile I was at the local grocery for a few minutes and when I came back I got this

I have created now new sensors to get rid of the misleading 16000 spikes that killed all my previous attempts cause 1 or 100 is close to nothing when you had a 16.000 peek value before in your graphs.

Then I have started diggin into the range sensor, my last big thing I need to achieve.

CONTROL UNIT / CU HEX: 17 Control unit in dash panel insert (J285) / Schalttafeleinsatz
HEADER HEX:            714 / 77E = 1812 / 1918 dezimal
SEND to / REPLY from:  1812 / 1918 OK

SENSOR:           calculated range / rng_calc
ADRESS HEX:       '22 22 E1' 
ADRESS dez:       '34 34 225' 
FORMULAR:         'U16(V1,V2)'

AUTOMATION
​            payload: >-
              { "bus": "0", "type": "tx", "frame": [{ "id": 1812, "dlc": 8,
              "rtr": false, "extd": false, "data": [3, 34, 34, 225, 170, 170,
              170, 170] }] }

I PUBLISHED THIS manually in mqtt EXPLORER

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

Not sure, what is wrong, but something must be wrong, cause I did not get a reply from the CU with Header 1918 (decimal).

I used the sources mentioned above for all the CU units and adresses.

[JabeBRD]

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.

[typxxi]

I will try that out - I hope it might be easier cause it is just 1 figure only: EV range

HA is starting, I just heard the beeping of the JK BMS which means the BAT MON Add On has started cause then the 14 kWh LFP Battery is monitored (is an EEL V4 Box with JK inverter BMS and Growatt Hybrid Inverter with 16 EVE LFP Cells hence 14 kWh).

[typxxi]

I copied your call and I got this

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

[JabeBRD]

I copied you call and I got this

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

I have found out that when data starts with 16, it has 2 or 3 messages, send that another message if you want the rest of message. With e-Up delay can be more than 100ms, but with Passat it needs to be max 50ms. You have total range of 217km

[typxxi]

Really ? I have to check it now if that is true , but it could be right.

Here is what I got from the second message.

REQUEST 1 {"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[3,34,42,182,170,170,170,170]}]}
REPLY   1 {"bus":"0","type":"rx","ts":15850,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[16,10,98,42,182,0,217,0]}]}

REQUEST 2 {"bus":"0","type":"tx","frame":[{"id":1808,"dlc":8,"rtr":false,"extd":false,"data":[48,0,0,170,170,170,170,170]}]}
REPLY   2 {"bus":"0","type":"rx","ts":30830,"frame":[{"id":1914,"dlc":8,"rtr":false,"extd":false,"data":[33,217,7,253,0,170,170,170]}]}

[typxxi]

217 km is right - it is quite low after 1 day of more or less 14 hours ignition and lights on.

I have now turned ignition off and removed the key, to try that again.

217 is the 7th bit / element - quite good, but I wonder why my adress had not been working. Maybe a e-Up specific adress.

And 1 question: you are asking decimal 1808 which is hex 710. I tried to search for the control unit but did not find one in the e-Up OBD list nor in the black list - wrong: I did search for 710 again in that amigos list and found CU 19

And there you can see the differences between e-Up and e-GOLF where e-GOLF seems to be a lot closer to Passat.

#   '19'=>{hdr=>'200', rhdr=>'1F', tp2=>1,                 desc=>'CAN Gateway'},               # e-up: TP2.0/KWP2000
    '19'=>{hdr=>'710', rhdr=>'77A', fc=>1,                 desc=>'CAN Gateway'},               # e-Golf

When i searched in the ODB list I could not find it cause it would be "200" in the e-Up instead of "710".

AND: 19 CAN GATEWAY is completely missing in the e-Up ODB list.

Also I had learned with this example that the Controul Unit HEX Adress is part of the Amigo List in the beginning. I will save the Amigo file cause it seems to be a treasure even though it looks like a batch or script.

I have used a delay of 250 ms for the second request and it worked from the beginning. But I guess I do not need it cause there is not much mor to get from there in my opinion. But what an achievement: SOC and Range now in HA available

Might be time to check if there is an EVCC function or integration that would report back to HA the estimated time till it would be fully charged. A Bonus so to say.

[typxxi]

Do you know what this means ? It is the formula for calculating odometer U16(V1,V2)

But what the heck does U16 ( V1 , V2 ) mean, I mean 3 variables in that single equation ?

I found that in the amigo list here

# 17 Control unit in dash panel insert (J285) => 
...
mlg_tot=> '22 22 03'   =   'odometer (~10)'    unit: 'km'   formula: 'U16(V1,V2)*10'   #   verified correct

And what does this mean d=>2 ? (was part of the line)