Announcement

Collapse
No announcement yet.

Update Intervals - Tweaks for WAF

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Update Intervals - Tweaks for WAF

    The WAF factor just wasn't there for this (which I believe is more an issue with Honeywell's TC servers than this plugin). There are a couple of issues:
    1. If you use the +/- buttons, you can only change the Temp a single degree every 15 seconds.
    2. The Setpoint didn't update in HS instantly (it only updated once the TC servers accepted the change)
    3. If the temperature was changed on the actual thermostat, it takes FOREVER for that to be reflected in HS


    I managed to create a virtual device to fix issues # 1 and 2. Now, to change the temperature we update this virtual device rather than the actual plugin setpoint device. Every time the virtual device is changed it restarts a counter. If that counter ever gets to 5 seconds then a script sends an update command to the real setpoint device. This way we can press the +/- button multiple times in secession and it will INSTANTLY update the virtual device but only after we have stopped pressing +/- for 5 seconds does it actually send the command (so TC is actually only being updated once and goes directly to the new temperature). This works GREAT.

    HOWEVER... I am having major issues with #3. I presume that relates to the "poll interval " setting in the plugin (which has a minimum of 240 seconds)? Is that truly how long we have to wait for a temperature change on the real thermostat to appear in HS ???

    #2
    In general, all of these things are just the way we're forced to work with the Honeywell devices.

    For #1:
    I'm happy to investigate building in some logic like you're using to the plugin; I already put all the commands in a queue so waiting N seconds after the first item arrives in the queue then evaluating the list and determining what to ACTUALLY send seems within reach. However, this is controlled by the "Command Frequency", which I allow every 2 seconds, which is considerably faster than the 15 you referenced (see below) but still not convenient for button mashing. (Personally I use fixed setpoint changes and never use the +/- buttons.)

    For #2:
    I made a conscious choice to NOT show the change immediately in the plugin after sending the request because all I know after submitting it is "we accepted your request". So until I can ask the server what ALL the current values are, I can't be sure that it worked (for example, someone might have made a change at the thermostat itself that would mean the value I showed in the plugin wasn't actually correct).

    If the risk of showing an incorrect value for a few seconds is more acceptable than waiting for a poll to process (which is always requested immediately after the change, but only allowed every 15 seconds at most), I can change that. I'll probably just make it an option so folks can pick their own poison.

    For #3:
    The issue is that for both these TCC-based devices (for which there isn't a public API) and the Lyric devices (which do have one), the paradigm is based on polling. From the Lyric API FAQ:

    Q. What is the Rate Limit for the API?
    A. Our limit is designed to allow you to poll device status every 5 minutes for up to 20 devices per hour, with a little cushion to make changes.

    So if you make a change on the thermostat, it will only notice it the next time a poll happens. If you've reduced yours to 4 minutes (which I set as the minimum before I saw that Lyric API stuff) then, on average, you'll know about it within 2 minutes.

    Unfortunately there's not much I can do about that part...

    Ultimately all of these things are designed to prevent your account from being locked out, which I can assure you has a lower WAF than waiting a few seconds to see a change occur

    The real problem is that unless they radically change their method of operation to use something like websockets or to allow the thermostat, which is local to your network, to make outbound calls to another internal system like your HS server, the polling paradigm is the only thing that will make sense. (Alternatively, HS could use their MyHS system to allow inbound API calls, but that would require both Honeywell to completely change their stuff and would require HS to do similar work as they have for Google & Amazon.)

    At the end of the day, you'll probably need to switch to a locally controlled thermostat instead if you want instant feedback and instant control coordinated with the thermostat itself.

    Comment

    Working...
    X