Help needed with changing parameters in remeha-samples

[bernie-gitmans]

Dear Richard,

I have already managed to use wireshark to gather a full set of data from the communication between the Remeha Tzerra and the Recom software. All the parameters as set in remeha.ini are the same for the Tzerra, however the xml file is different, so the lookup in remora-samples etc is not working correctly.

The model Tzerra uses the PCU-05_P3 as type, and now I would need some help with matching the xml file to the php script. Could you please help me out?

[rjblake]

I have taken a quick look and there are some differences. I do not have the time to rewrite this for the Tzerra (nor can I test it without a Tzerra or data feed handy). A few pointers to help you on your way:

You can compare the different XML files (Calenta is PCU-03_P5.xml) to see where things are different. Use the relevant language-xx.xml file for the text descriptions, etc.. To get you started, a couple of examples as follows: Your file (PCU-05_P3.xml, using the language-en.xml file): Byte=60 refers to description ”2541” and name “2541”, which is name "CH setpoint HMI" [byte 60 not in use for Calenta, CH setpoint is byte 16] Byte=61 refers to description ”2541” and name “2542”, which is name "DHW setpoint HMI" [byte 61 not in use for Calenta, DHW setpoint is byte 18] Byte=22 refers to description “2545” and name “2544”, which is name “Airflow setpoint”. The Calenta is “Fanspeed setpoint” Byte=24 refers to description “2547” and name “2546”, which is name “Airflow”. The Calenta is “Fan speed”

Some worked examples: e.g. in the section of your XML:

<config group="1" type="field">
<present unit.nr="312" description.nr="1824" name.nr="1824"/>
<function format="0.00" expression="sgn(A.0 + B.1) x 0.01" byte="27"/>
<limits max="100" min="0" max.nr="106" min.nr="107"/>

Use the relevant ‘language-xx.xml’ file: present unit.nr=”312” maps to: description.nr=”1824” maps to Byte=”27” is the relevant byte from the response from the boiler (e.g. “A0 0F”, where “A0” = 160 and “0F” = 15 in decimal) Expression is how it is calculated. In this example = sgn(A.0 + B.1) = 0.01 (in this case sgn(15256 + 40) 0.01 = 40.00

Another example:

<config group="2" type="field">
<present unit.nr="346" description.nr="1397" name.nr="1396"/>
<function format="0" expression="A" byte="30"/>
<limits max="100" min="0"/>

present unit.nr="346" maps to: description.nr="1397" maps to: - there is a typo as this should be “Pump speed” name.nr="1396" maps to: expression=”A” is simply the Hex to Decimal value

I also have an Excel with mappings for the Calenta that you can use as the basis for checking your mapping/values, but you'll need to do the value mapping before it is of any use. i.e. there is no shortcut to doing the lookup for your boiler. Of course a better coded solution for this would be to use the Remeha XML files and avoid this entirely, but I did not have the time as it started as a personal project for myself (any didn't want to run any risk of Remeha having issue with distributing their files, etc.)

[bernie-gitmans]

Thanks for the explanation. Wil try with your description, and will give feedback

[bernie-gitmans]

I have started with the mapping of the Tzerra and if you could provide your Excel sheet that would be really nice.

Ps. communicatie kan ook gewoon in het Nederlands.

[rjblake]

Dat kan maar mijn Nederlnds is niet so goed...will need your email

[bernie-gitmans]

Than we will stick to English.

[rjblake]

Bernie - I've added the XLS file to the GitHub repository. Should be fairly self explanatory

[bernie-gitmans]

I just have downloaded the xls file, will try tomorrow to link the Tzerra in a similar way

[bernie-gitmans]

I've finally matched the tzerra values to the xls file, and I'm able to recieve data. However I have to disable the checksum function as this is not working for the tzerra. Even if I disable the checksum I sometimes do not get a response from the ESP unit. It gives an undefined offset in the php script, and actually no data is received at that moment. A second run wil show data again.

Could you point me in the right direction regarding the CRC check?

I will upload the Tzerra xls file.

[rjblake]

I have taken a look at your data you sent in the XLS (Samples tab, Cell:J38) 0201fe06480201380ecd0c80f3d0bc80f30080720bb307bc020c176c070000000000bc020000000000000001c20b0000ffff00000000ffff00c0bc02000000008047033b3b0000ba9403 and the CRC calculates correctly (it is a CRC-16 Modbus). You can use an online calculator (e.g. here) As far as the CRC, you can 'split' the response as follows: Start - 02 Data - 01fe06480201380ecd0c80f3d0bc80f30080720bb307bc020c176c070000000000bc020000000000000001c20b0000ffff00000000ffff00c0bc02000000008047033b3b0000 CRC - ba94 End - 03

The CRC is performed on the 'Data' only - do not use the Start, CRC or End values. Depending on Endian , the CRC is either 'BA94' or '94BA'. There can/will be comms issues that result in data not being correctly received. This will result in a CRC that does not 'add up' unfortunately. The code I wrote could be described as 'blocking code', as it sends the string, then waits for a period of time to try receive data back before it does anything else. This can certainly be improved/changed; but at the time this started as a quick n dirty project. You could try increasing the timeout in the following line: stream_set_timeout($fp, 5); [here is is 5 secs] as well, in case there is some other lag elsewhere

[bernie-gitmans]

Thank you for the information. I had already found that the CRC values are calculated correctly.

I was wondering if I had to change the " $crc code" in the remeha_functions.php to match the tzerra code. For the Calenta it is set to 0xE3D5.

[rjblake]

Sorry - not sure what you are referring to. The Modbus variant of CRC16 calculation differs from a “standard” CRC16 calculation in that the initial value isn’t 0 (zero), but $FFFF (as in the function crc16_modbus($msg) on line 109). Where is the 0xE3D5 in the code? Note that the CRC is a calculated value in each data string you receive from the CV and changes as the data changes (to allow an integrity check once received). The check is simply as follows:

Using your example & what the code does: $hexstrPayload = substr($data_sample, 2, 140); - this extracts the payload (01fe06480201380ecd0c80f3d0bc80f30080720bb307bc020c176c070000000000bc020000000000000001c20b0000ffff00000000ffff00c0bc02000000008047033b3b0000) $hexstrCRC = substr($data_sample, 142, 4); - this extracts the CRC (ba94) $crcCalc = crc16_modbus($hexstrPayload); - this call the crc16_modbus function and calculates the CRC (ba94) ...if all good, the calculated value in $crcCalc should be equal to $hexstrCRC

You can use the following code to run checks on any string: <?php require('remeha_functions.php'); $data_sample = $argv[1]; $hexstrPayload = substr($data_sample, 2, 140); $hexstrCRC = substr($data_sample, 142, 4); $crcCalc = crc16_modbus($hexstrPayload); echo "Payload: $hexstrPayload\n"; echo "CRC (in string) : $hexstrCRC\n"; echo "CRC (calculated): $crcCalc\n"; ?> run using "php test.php hex_string_to_check", where hex_stringto check is the full string. e.g. php test.php 0201fe06480201380ecd0c80f3d0bc80f30080720bb307bc020c176c070000000000bc020000000000000001c20b0000ffff00000000ffff00c0bc02000000008047033b3b0000ba9403

[bernie-gitmans]

I think I have found an error in my code, indeed on line 109. No idea how it got there. But CRC calculations are correct now, and domoticz is updated.

[rjblake]

Good to hear you found the problem. Closing the issue