kotope / valloxesp

Vallox Digit wifi controller with Home Assistant integration through MQTT
MIT License
22 stars 9 forks source link

esphome: implement setter with retry logic #29

Closed qvr closed 1 year ago

qvr commented 1 year ago

This is a draft PR for discussion, and I can rebase on master if the esphome branch gets merged.

This implements a setter with set-ack-retry logic as in the Vallox specs: if a set message is sent to specific address (ie. mainboard_1) instead of a group address, the receiver will acknowledge receiving it by replying with just the checksum of the received message. If no ack arrives in 10ms, then you are supposed to retry up to 10 times.

I've been using this system for just a couple of days, but I've noticed a couple of random times when changing fan speed the command obviously did not go through, and instead it immediately changes back to previous value in Home Assistant.

My thinking is, and this is the part I'm unsure, is that the bus might've been "busy" just as we were sending the command, the actual panel might be doing some requests of its own or something.

With this PR and the debug logging statements it has, I've been able to catch it a couple of times, once by changing fan speed in the panel and then fairly quick after from home assistant:

[12:19:21][D][climate:010]: 'Vallox Climate' - Setting
[12:19:21][D][climate:018]:  Custom Fan: 4
[12:19:21][D][vallox:962]: RX available: 24
[12:19:21][D][vallox:969]: RX byte was not ack, remaining: 23
[12:19:21][D][vallox:969]: RX byte was not ack, remaining: 22
...
[12:19:21][D][vallox:969]: RX byte was not ack, remaining: 0
[12:19:21][D][vallox:974]: setVariable: no ack received in 10ms, retrying...
[12:19:21][D][vallox:962]: RX available: 3
[12:19:21][D][vallox:982]: setVariable: ack received
[12:19:21][D][climate:392]: 'Vallox Climate' - Sending state:
[12:19:21][D][climate:395]:   Mode: FAN_ONLY
[12:19:21][D][climate:397]:   Action: FAN
[12:19:21][D][climate:403]:   Custom Fan Mode: 4
[12:19:21][D][climate:415]:   Current Temperature: 17.00°C
[12:19:21][D][climate:421]:   Target Temperature: 14.00°C

So 10ms after writing to the bus, it already had 24 bytes in the RX buffer (which would be 4 complete messages), and the acknowledgement byte was not included, only after a retry did the main unit acknowledge the change.

Has anyone else seen set commands not going through? And does the code make sense? :)

kotope commented 1 year ago

So far my fan speed set has been working properly, but sometimes I get some CRC errors while querying variables. Usually that is because the BUS is busy, but I've not seen it as a problem (there's another more high-level retry logic while query parameters in the MQTT version). In theory, fan speed set can fail with the same BUS busy reason as well.

Implementing ack-retry logic, as you've done, could solve the problem. I think I need to look into it more detail as well to get full understanding about the functionality :-)

qvr commented 1 year ago

I cleaned the debug prints and marked this as ready for review now.

I've been running it for the past 4 months or so, and I've seen maybe 2-3 retries per month (there's a handy diagnostic counter for them), with around 4 automated fan speed changes daily, and I haven't seen any more cases of set commands not going through.