Valve_position not updated when its value is overriden via Itho settings about ithowifi HOT 18 CLOSED

Your tearing the device down! ;-)
Hope you can get something out of it!

from ithowifi.

@jasperslits
My intention is to control the summer bypass manually and have a proper status feedback on it.
the automatic bypass behavior hasn't been optimal so far - in summer it tends to by activated even during a hot day and most importantly - I've experienced at least 2 times that it was left activated even when the outside temperature dropped below 14°C in Sept/Oct with some cold days forecast ahead.
This might have been caused by some bug in the original fw.
I have no intention to mess with negative-values position, which is a freeze protection tho.

from ithowifi.

the value is taken from the itho firmware itself. If a refresh of the value does not alter the result, then probably the value is not really stored in the itho firmware.
Could you post the command result of the same command but then posted through the debug page?

from ithowifi.

unfortunately, my Debug page stopped working - can't get it to work even after trying to reset and reflash the firmware. I'll look deeper into this and post the logs if I manage to get some.

from ithowifi.

so, just for the record:
index: 47
Result: 80 82 A4 10 01 13 00 00 00 00 FF FF FC E0 00 00 03 20 00 00 00 01 90 2F 6D 0C
Current: 0
Minimum value: -800
Maximum value: 800

now, setting this to any non-negative integer (incl. 0):

Sent command: 82 80 24 10 06 13 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 2F 00 81
Result: confirmed
Warning!!

querying returns the correct (set) value.

now, with negative integers, the confirmation fails (probably because sets the value to the maximum integer value and decrements from it):
setting to -1

Sent command: 82 80 24 10 06 13 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 2F 00 86
Result: confirmation failed
Warning!!

query:

Result: 80 82 A4 10 01 13 00 00 FF FF FF FF FC E0 00 00 03 20 00 00 00 01 90 2F 6D 0E
Current: 65535
Minimum value: -800
Maximum value: 800

Itho status keeps reporting 0 for both cases

from ithowifi.

looking at: 82 80 24 10 06 13 FF FF FF FF
FF FF FF FF would in 32 bit int be -1 so that is correct

The query result is 00 00 FF FF, which is in 32 bit int indeed 65535

Looking at this it seems that the itho is only accepting a 16 bit wide integers value whereas in other situations it accepts 32 bit wide integers

I'm now wondering if 90 before the 2F at the end determines this. For another int values I see A0, 10, 00, which feels a lot like the scheme which is used for the status format.

from ithowifi.

@arjenhiemstra ,

I'm now wondering if 90 before the 2F at the end determines this. For another int values I see A0, 10, 00, which feels a lot like the scheme which is used for the status format.

I tested this on various values on interval <-800, 800> (see table below) and I see the FF FF FC E0 00 00 03 20 00 00 00 01 90 2F 6D pattern in all of them.
I think it simply boils down to a rule - if req < 0 then res = res_val-65536

from ithowifi.

I'm afraid (quite sure now) it is not that simple. Maybe in this specific case it is but it is more complicated than that to make it work universal:

looking at the last part 90 2F 6D 30
90 in bits = 1001 0000
This falls apart in three sections
1 (or 0) 1 = signed, 0 = unsigned
001 (or 000, 010, 100) 000 = 1 byte wide, 001 = 2 byte wide, 010 = 4 byte wide
0000 (or 0001 etc.) is the divider

This is exact the same as I parse here for the itho status values:

Apparently in the itho firmware this system is also being used for settings values

I manually tested with some other settings on my CVE, and the above describe system works flawless for all those settings.

from ithowifi.

nrgitho-hw2-v2.3-beta4.bin.zip

[edit: removed bin, still found some issues]
[edit2: added new bin to test]
[edit3: added bin for HW rev 2]
Could you test this patch?
It is not fixed completely yet, values larger than int32 (which actually should be uint32) are not handled correctly yet.

from ithowifi.

@rplevka : I have the HRU-350 as well but what is your use-case for (trying to) change the valve position? Like what is supposed to control? I don't dare to change it unless I know what benefits it has of doing this via manual control.

from ithowifi.

fixed with a985ad0

from ithowifi.

@arjenhiemstra, i'm not sure the original problem statement was clear enough as I can't see 2.3-beta4 version addressing the issue at all -
the valve position is still reported as 0 at Itho status page, after enabling the manual operation and setting the valve to any, non-zero position, making the reported status not correct.

from ithowifi.

the valve position is still reported as 0 at Itho status page, after enabling the manual operation and setting the valve to any, non-zero position, making the reported status not correct.

I guess it's difficult to confirm if the valve mechanically moved after changing the values?

from ithowifi.

the valve position is still reported as 0 at Itho status page, after enabling the manual operation and setting the valve to any, non-zero position, making the reported status not correct.

I guess it's difficult to confirm if the valve mechanically moved after changing the values?

It sure is. I'm after the value the Itho unit reports back via I2C on the Itho setting page. But i need it accessible via MQTT

from ithowifi.

"however the value is not reflected in Itho settings."
This was what directed me to the itho settings, not realising that the set value is also not represented on the itho status page. No idea what the issue there could be. Could you share what is visible on the status page?

I've borrowed the itho service tool out to someone, when I have it back I can compare the add-on result with the service tool figures. If there is a difference there will be something to dig into

from ithowifi.

I'm terribly sorry, I confused those two.

Status page:

from ithowifi.

Could you test if this is still relevant?
https://github.com/arjenhiemstra/ithowifi/releases/tag/Version-2.3.0

from ithowifi.

Hi,
tested, and figured out it's not the Valve_position that reflect the position of the bypass/antifreeze protection valve, but Current Position - this metric updates accordingly. I'm not sure if this was working in the older fw versions

from ithowifi.