Add an Event Revision to the Thermostat Summary Request

Unless I am missing something it does not seem possible to check for a change in events other than requesting the events for a thermostat on a regular interval. This means that after a request summary (/thermostatSummary) is issued a thermostat (/thermostat) call still needs to be made to detect if any events are active resulting in a call for each thermostat even if the revisions have not changed. Granted the call is only includeEvents=true and has probably has low overhead but it still required an API call.

If I am correct, and, if possible, having an event revision in the thermostat summary request would cut down on additional API calls.

Reasoning: A change, such as a temperature hold, in the standard program of the thermostat is held as an event and is usually something that would be considered general information about the status of the thermostat.
1 person likes
this idea
+1
Reply
  • MarkK (API Architect) July 29, 2013 13:43
    Thermostat events are intrinsically tied to the entire thermostat configuration, the thermostat revision is changed as an effect of a thermostat configuration change which includes events. We treat the entire config as a single entity to ensure consistency and reduce config merge problems which get extremely complicated with multiple vectors. Unfortunately what you suggest cannot be done.

    Having said that, polling for a thermostat revision change is appropriate with a get thermostat with events when the revision changes to obtain the events.

    On your side, you have all the events. It is a matter of calculating the thermostat local time and determining whether one of those events is currently active. There is no need to actually poll that much. When the thermostat revision changes you can then obtain the new set of events.

    The thermostat does not notify the server when an event starts or finishes. It only posts when an event is added or removed in regard to events (i.e. user sets a hold). The server calculates whether the event is running currently when it returns the call. This can be done on the client side as well to reduce number of requests.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • Although I agree with the approach of using the event end time to time the update, and have used this approach, I think there is a missed opportunity to update the application if the program is resumed from the thermostat itself before the end time.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • MarkK (API Architect) July 30, 2013 14:24
    If a user makes any configuration change on the thermostat which includes resuming a calendar event, or starting one, the thermostat will immediately post its configuration to the server and increment the thermostat revision. If you keep polling thermostatSummary for the revision at intervals, you will detect this and be able to obtain the new event list.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • I’m happy
    I missed this somehow. I did some testing and you are correct, when an event is created or the program is resumed the settings revision is incremented. This helps a lot, thanks.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned