Closed Jalle19 closed 2 years ago
You just beat me to this as well. I have done some tests - But I didn't decode it fully - so this looks good. But there are cases where it should change state (I assume) where it doesn't. The states I have seen (not with your code - but earlier) is Cooker Hood, and Summernight cooling. Also the Control Steps for heating is interesting. While running the cooker hood for some extended time, I can now see that it starts heating the incoming air - as it's not getting as warm from recycling when it doesn't get as much air out that way. Also the Cascade values starts changing - but I don't know exactly how to interpret these. (Just that larger is more power).
I have done some tests - But I didn't decode it fully - so this looks good. But there are cases where it should change state (I assume) where it doesn't.
This I managed to fix. Was a silly coding error.
Also the Control Steps for heating is interesting. While running the cooker hood for some extended time, I can now see that it starts heating the incoming air - as it's not getting as warm from recycling when it doesn't get as much air out that way.
Indeed, the same thing happens when you enable "overpressure" manually.
Also the Cascade values starts changing - but I don't know exactly how to interpret these. (Just that larger is more power).
Based on my understanding:
0: the heat recovery drum is not rotating at all. Fresh air is "piped" directly to rooms 0-100: the drum spins at tighter and tighter intervals, until the value is at 100, when it is continuously spinning 101-200: the drum spins nominally, but in addition the heating element is doing work. 200 means it's operating at maximum.
As @JohanElmis mentioned in https://github.com/Jalle19/eda-modbus-bridge/issues/43#issuecomment-1037990171, there's a register that holds a bit field describing what state the ventilation unit is in.
Ideally this state should be exposed as a boolean map, both via HTTP and as read-only binary sensors via MQTT.