Hi there,
i have a very simple thermostat. Simple in that the only thing it can do is one chosen set-point.
The downside is when i use any of the thermostat drivers (generic included) the dashboard comes with heat and fan modes which are redundant. This is not an issue unless you change the set point from the device itself which translates to heat-mode=OFF, therefore when you wish to change the temperature on the dashboard you have to first enable heat-mode (which is effectively a null parameter) in order to access the up/down temperature controls.
The problem comes in as having to engage "heat=ON" (to access the temperature setting) transmits the default heat-on temperature. This value overrides the chosen setpoint. With "no value" in this setting there is a default value of 21 degrees.
So, ideally i need "heatmode=ON" permenantantly engaged so i can have just setpoint up/down controls without the faff or possible keep the device from switching the driver from heat-on to heat off. Its only an issue if the temperature is changed on the device.
Create a virtual thermostat and expose it to HE dashboard.
Make 2 rules :
On virtual thermostat heatingSetpoint change, set the physical thermostat setpoint be the same .
On physical thermostat heatingSetpoint change, set the virtual thermostat setpoint be the same .
I don’t think that the above two rules may create infinite loop, because when the setopoints become equal as result from the first rule execution, the second rule should not actually generate a new event.
So i made a fix- new rule, when temperature changes set mode to heat=ON, simple as that, even though the mode capabiltiy does not exist on that device, which leads to a new problem...
I have a (separate) rule that adjusts the setpoint for another thermostat which if i add the new TRV to the same rule (so i can adjust both setpoints in the same rule) crashes the rule as i think its attempting to configure the mode which is only available to the existing TRV but not the new TRV, as it does not have a mode capability. The solution here is to create separate rule for each device.
I guess this can be a problem when attempting to configure multiple similar devices that dont all the same capabilities, as in this case, two thermostats one having a range of parameters and the other having one or two. I didnt expect it to crash and had it been a complex rule i had no way of recalling what was in the rule.
Any advice for approaching these situations?