Refine updating of setpoint and unnecessary device updates while doing this.

[Odd-Henrik]

Sending the command to the device(s) representing the heater every time the setpoint changes adds unnecessary communication traffic - you only need to send the command if the device isn't already in the correct state. This is particularly noticeable when you need to make significant changes to the setpoint and you click the up/down arrows repeatedly in the Mac client.

I'm painfully aware of this "problem". My challenge evolves around two issues: I have several times experienced that an indigo device is reporting to be on or off when the actual device is not or that for some reasons the actual device does not get updated correctly. This can probably happen for all sorts of reasons but can cause the temperature to rise or fall uncontrollably if not handled, and that is bad! My heater logic works so that it will not send any update to the device if the temperature is within range of the setpoint +/- delta (that means normally when no user changes is done and everything is ok), but in case of wrongly heater device state or missed state change, a safety resend to the device is done if the difference in temperature and setpoint is larger then setpoint + delta + 1 or setpoint - delta - 1. So if the temperature is off by one degree of normal operations it goes into a "persistent safety mode", "nagging" the actuator until things are back to normal. This is whats going on and you notice when changing the setpoint and it is "out of safe range". I do this to make sure the actuator gets updated as soon as possible and repeatedly until everything is back to normal as a safety precaution. A negative side effect of this is what you are describing. In my monitoring graphs I see this scenario from time to time, and that the safety kicks in and fixes the issue, so i believe it is an important feature.

Because of the problem you described, I used to, in the beginning, not to run the heater logic when the setpoint was changed. This works fine, but the user will not get the immediate feedback on the results of the change in the ui (Why does it not turn on and off when I change the set point and believe it should?) but had to wait for something else to trigger the heater logic (e.g. temperature sensor update). I tough this might be confusing for the user and decided to run the heater logic every time, thinking this will more or less be a one timer when initially setting the setpoint and less confusing.

There surly is a solution to this somewhere and lots of ways to refine the safety feature , but I have no simple solution at the moment and opted to make safety and usability priority over efficiency around just this at the moment, thinking this is relay not a big deal and thus have not prioritized this. I have considered setting a default value for the set point, making the problem less prominent, but this is useless because of the F/C reality and I have at the moment decided to keep the thermostat, temperature scale agnostic.

What would be nice in any cases would be the possibility to type in the setpoint directly in the user interfaces "Thermostat Controls" as an option to the arrows. The part showing the setpoint value should be (or optionally could be) a text box so the user could choose to use the arrows or the text box. This would eliminate the need of a default value and the F/C challenge and the annoying repeatedly clicking on the arrows and the whole problem you describe, all at once. ;)

Another thing I'm wondering about. It seems to me that the arrows are hardcoded to send an actionValue of +/-1? Is there a way to change this? I want to have it in 0.5 incriments and have made a hack for this, but it can come in conflict with other functionality using the actionControlThermostat method. Again the solution with the textbox above would make this less of an issue, but it still would be nice to have control over this.

I would very much appreciate any solutions or suggestions for solving the chalenges I have described about this. :)

http://forums.indigodomo.com/viewtopic.php?f=154&t=12896&p=87385#p87385

[Odd-Henrik]

This is implemented and tested.