u32 values

[andresp]

Trying to figure out how to retrieve U32 based high/low values such as these datapoints for a heat pump:

I know the data is reported to the displays on the unit, but I don't see them going over the CAN bus. I can only see the GET request data going over the wire:

19:22:57	[I]	[tt:230]	
[GET] Data: 0x01400a0159e1

Could it be that the response neither fit the SENSOR nor TEXTSENSOR format? Has anyone successfully read u32 based datapoints in an actual environment?

[nliaudat]

It's not implemented now as U32 and S32 values are only readable and are a very small part of all Toptronic datapoints.

In fact the canbus communication of hoval devices is a mix of canbus and modbus.

The U32 and S32 values are splited in 2 messages over canbus if my memory is good.
They should be regrouped to get the raw value.

I have no time to support you further for now. Very sorry.

Perhaps @abichinger could help you

Regards

[nliaudat]

You can open a discussion.
I mean is not a real issue but more a feature request.
You can close it if you agree

[andresp]

Happy to change this to a feature request. I could also help with contributing an implementation for the split messages, if you happen to know how to identify the messages that belong together. I’ve been unable to identify these, despite having a few wireshark dumps of the can bus messages. If you could share what to look for, I could probably put this together.

[nliaudat]

Sorry, there is no way to convert issue to feature request actually.
I tranfert it to discussion.
I have an HV (homevent). I'll do some tests on capturing the U32 values if I found time too.

In the meanwhile, perhaps you can find responses in https://github.com/chrishrb/hoval-gateway which have a very good understanding of Hoval canbus protocol.

I'll try to do it asap, but I am very busy actually.

Regards and welcome to that project.

[nliaudat]

I have made some test on my homevent with U32 values by activating :

sensor:
- platform: toptronic
  name: Maint_ctr_value low
  device_type: HV
  device_addr: ${TT_HV_addr}
  function_group: 50
  function_number: 0
  datapoint: 20037
  id: HV_50_0_20037
  type: U32

In the first analysis of code, the U32 value seems handled correctly.

There is no trafic on canbus on that datapoint.
Perhaps the problem is only to make a good request as the request code (0x40) was reversed engineered and perhaps do not fit U32 value.

[nliaudat]

from hoval documentation :
Address of the data point

A data point can have several register addresses depending on the TypeName:
Data points with TypeName S8,U8,S16,U16,List need only one address.
Four-byte or eight-byte data points (TypeName: U32,S32,S64)
are divided to 2 or 4 Modbus data points. These are marked with a
"high" for highbytes and "low" for lowbytes marked."

[nliaudat]

from https://raw.githubusercontent.com/wladwnt/CAN-Gateway/master/Operating_manual.pdf p42

Basis address = (order number-1)*10
Parameters with data types U32 or S32 will get two addresses, meaning will be mapped to two
registers in terms of Modbus. The basis address above will address the two highest bytes (also will
include the most significant bit), the next address (=basis address + 1) will address the two lowest
bytes (also will include the last significant bit). For example, if a parameter number 5 has type U32,
then it will get addresses 40 and 41.

[abichinger]

@andresp do you receive a value with the following sensor?

sensor:
- platform: toptronic
  name: Eletrical energy low
  device_type: WEZ
  device_addr: ${TT_WEZ_addr}
  function_group: 10
  function_number: 1
  datapoint: 23009
  id: WEZ_10_1_23009
  type: U32
  accuracy_decimals: 0
  filters:
  - multiply: 1

[nliaudat]

Do not work with :

  - platform: toptronic
    name: Maint_ctr_value low
    device_type: HV
    device_addr: ${TT_HV_addr}
    function_group: 50
    function_number: 0
    datapoint: 20037
    id: HV_50_0_20037
    type: U32
    accuracy_decimals: 0
    filters:
    - multiply: 1

I've tested with type: U8 and U16 instead of U32 to catch the 1st part only of the registered message with no luck.

[nliaudat]

And with multiply: 0.001 ?

sensor:
- platform: toptronic
  name: Eletrical energy low
  device_type: WEZ
  device_addr: ${TT_WEZ_addr}
  function_group: 10
  function_number: 1
  datapoint: 23009
  id: WEZ_10_1_23009
  type: U32
  filters:
  - multiply: 0.001

[dkarv]

Thanks a lot for your great repository and contributions.
I'm also interested in U32 values, and after analyzing the candump from my heat pump a bit, I think there is additional code needed to handle these values. I found a good implementation and how it works here: https://github.com/zittix/Hoval-GW/blob/master/hoval-gw.py#L132
Basically the first byte is a message identifier to combine future values.

I applied the code by hand to the candump log messages:

# [22:33:55] [I][candump]: 1fe04001 : 1 40 a 1 71 7a fb 3f
# [GET] a 1 71 7a


# [22:33:55] [I][candump]: 1f400fff : 11 48 42 a 1 71 7a 0
msg_len = msg.data[0] >> 3
# = 2
msg_header = msg.data[1]
# = 48
pending_msg[msg_header] = { "data": msg.data[2:], "nb_remaining": msg_len - 1 }
# = { "data": [42 a 1 71 7a 0], "nb_remaining": 1 }


# [22:33:55] [I][candump]: 1e800fff : 48 0 7e 25 9e 46 fb 3f
msg_header = msg.data[0]
# = 48
pending_msg[msg_header]["data"] = pending_msg[msg_header]["data"] + msg.data[1:]
# = [11 48 42 a 1 71 7a 0 0 7e 25 9e 46 fb 3f]
pending_msg[msg_header]["nb_remaining"] -= 1
# = 0
if pending_msg[msg_header]["nb_remaining"] == 0:
    # Done receiving the big message, yeah
    # Remove the CRC bytes (Not sure what type of CRC it is..)
    data = pending_msg[msg_header]["data"][:-2]
    # = [48 42 a 1 71 7a 0 0 7e 25 9e 46]
    del pending_msg[msg_header]

# [RES] a 1 71 7a with hex value [0 0 7e 25] = dec 32,293
# Expected value from the BM: 32,293MWh

So I think the message handling needs to be extended. I never wrote C++ before, but might give it a try. The python code should be a good start and the only downside is additional state, that has to be kept across messages.

[nliaudat]

Could you share your candump ?

My feeling is that the second message needs to be requested with 0x41 instead of 0x40.

[dkarv]

I'm not sure if the second message needs to be requested. I only see one GET request in the logs. Two long values were processed in this snippet:

[19:56:57][I][tt:230]: [GET] Data: 0x0140020003ec
[19:56:57][I][tt:305]: [RES] Can-ID: 0x1FC00FFF, Sensor: Hot water setpoint, Data: 0x42020003ec01c2
[19:56:57][I][candump:023]: 1fc00fff : 1 42 2 0 3 ec 1 c2
[19:56:57][I][tt:322]: Start of message with id: 116 with length 2
[19:56:57][I][candump:023]: 1f400fff : 11 74 56 2 0 3 ec f0
[19:56:57][I][tt:331]: Part of message with id: 116 with remaining length 0
[19:56:57][I][tt:359]: [UNK] Can-ID: 0x1E800FFF, Data: 0x56020003ecf000000000
[19:56:57][I][candump:023]: 1e800fff : 74 0 0 0 0 90 e6 3f
[19:56:57][I][candump:023]: d047ff : 1 2 fd 3f ac 8a fb 3f
[19:56:57][I][candump:023]: c00fff : 1 2 fd 3f ac 8a fb 3f
[19:56:57][I][candump:023]: e00fff : 1 2 fd 3f ac 8a fb 3f
[19:56:57][I][tt:230]: [GET] Data: 0x01400a0159e1
[19:56:58][I][tt:322]: Start of message with id: 118 with length 2
[19:56:58][I][candump:023]: 1f400fff : 11 76 42 a 1 59 e1 0
[19:56:58][I][tt:331]: Part of message with id: 118 with remaining length 0
[19:56:58][I][tt:305]: [RES] Can-ID: 0x1E800FFF, Sensor: Eletrical energy WEZ MWh_low, Data: 0x420a0159e10000147e
[19:56:58][I][candump:023]: 1e800fff : 76 0 14 7e 37 f4 fb 3f

The additional log lines are from my code: dkarv@9814c5f
It actually works to decode the u32 values and I see them in HA:

In case you are interested I can prepare a pull request.

[nliaudat]

It looks not breaking anything.
Feel free to make a PR and I'll merge it.
Many thanks for your work.

[nliaudat]

Hi,
Glad to see it works great for HV.

Need help to add relevant U32 values for other devices as I have HV only.

Regards

[dkarv]

I added the 3 most interesting WEZ datapoints. The electrical energy used (MWh) -> I added it to the energy dashboard to track my energy usage.
And the heating + warm water MWh, it allows to calculate the efficiency of the WEZ (heat / electricity).