Added info on byte 119

[Rimco]

I decided to see if I could find any correlation between TOP119 and any other temperature reading (like TOP118).
Looking at the data, TOP119 adds 0.5C precision to the zone temperature, like TOP118 does for Inlet/Outlet.

D3 is first 3 LSB from TOP119, only 2 values I've seen are 1 (0.0C) and 3 (0.5C), so no 0.25C steps.
D4 (next 3 LSB) is always reading 2. I assume that is for the second zone, which I don't have.

I hope this PR will be the trigger to also update the decode logic with above information.

[geduxas]

First it's not TOPxx but byte in datastream, so it should not be confused, second what pump model do you have? have you tested your hypotesis? Maybe you could change code also? i have 2 zone system with aditional dallas sensors, so i could test both zones.

[Rimco]

@geduxas I see I got confused with the naming convention due to the fact that the first 2 columns reads like "TOP" "119". At least the content is correct.

This was tested on a 9J, the graph above was created from that data. So yes, for zone 1 this was tested to be matching my hypothesis.

I could implement, but looking at the code duplication in decode.cpp today I would instantly end up refactoring it. Because I don't know when I would have time to do that properly (I have no development environment for Arduino, only esp-idf) I decided to already share my findings in this way, to allow others to use this information already.

[geduxas]

I have checked my H series, it's showing 0x12, while 118byte 0x0A, so 12-1=11 (00010001) I'll try to watch it for a while.. it's possible that H series don't have this..

[Rimco]

@geduxas Not sure why you are subtracting 1 from 0x12?
0x12 is binary 010 010, so both 3 bit elements would have decimal value 2.

Could be that you're actually getting readings that have 0.25C resolution or no readings at all.

I did my diagnostics based on the following 2 values:
D3 = raw[119] & 0b111
D4 = (raw[119]>>3) & 0b111

This is what resulted in the graph from the first post, but I don't expect I will ever get a different D4 value without Zone 2.

[geduxas]

@geduxas Not sure why you are subtracting 1 from 0x12? 0x12 is binary 010 010, so both 3 bit elements would have decimal value 2.

Could be that you're actually getting readings that have 0.25C resolution or no readings at all.

I did my diagnostics based on the following 2 values: D3 = raw[119] & 0b111 D4 = (raw[119]>>3) & 0b111

This is what resulted in the graph from the first post, but I don't expect I will ever get a different D4 value without Zone 2.

Becouse all values from datastream is substracted by 1, i am not sure all of them or not.. but it's have some sort of "checksum" if its 0, then it's not have any value set by hardware, if it's 1 it potentially have been set by MCU.. truly i didn't look how 118 implemented, just made automatic calculations..

I have watched for couple of minutes while pump have been running, it went from ,+26 to +28 on both zones, and keep refreshing data from pump, unfortunately on my pump it was always stable 0x12.. so it's probably something what was done in later pumps :)

[Rimco]

@geduxas I based my logic on existing code for byte 118:

HeishaMon/HeishaMon/decode.cpp

Lines 170 to 172 in a494463

	int fractional = (int)(data[118] & 0b111);
	switch (fractional) {
	case 1: // fractional .00

In a way that indeed starts at 1, so it still matches your logic, but differently.

One important note: Byte 119 is (according to my hypothesis) the fractional part for the Z1_Temp (and Z2_Temp) values. So those are the readings from the remote controller temp sensor, not water temp.

Do you really have the controller in a room with 26 and 28C?

[geduxas]

Hmm room temperature? I thought you are about inlet/outlet zone trmperatures. Ok. It's making difference.. no i have only one remote, and it's attached to pump in basement. Never check it's temperature..

[Rimco]

@geduxas For testing make it warm using any hairdryer and check if at least you get some different values ;)

[Rimco]

@geduxas Have a look if the proposed code changes work out for you, at least it should be 90% of the work.

[geduxas]

Unfortunately, no, it's seam's H series just don't have it, i have monitored that byte for my pump, and all time it was 12, never changed

[Rimco]

@geduxas For the 9J I'm monitoring I now nicely have readings of 22 -> 21.5 (HP starts) -> 22.5 (HP stops). I do that now in my home automation, by processing the raw data from MQTT. But getting it done directly inside Heishamon will help lots of others, because 1C resolution for the room temperature is a bit rough...

[stumbaumr]

My Heishamon rules use the remote control thermostat temperature for automation. I always hated the low resolution of the remote control.
I can test your build tomorrow and I hope it works!
Thanks so much for working on it!

[stumbaumr]

@IgorYbema , there is no available build for this patch under actions - is something broken with the actions?!?

[Rimco]

@stumbaumr I also have no clue if this PR actually compiles or might fail on something simple ;) The good thing is that the offline version I use based on the raw data still nicely behaves correctly:

[stumbaumr]

Last time when I tested HeishaMon any PR that got sent would create a build. This is not the case any more. I believe something is broken with the actions…