Another question about hold mode.

[electricessence]

I thought I understood this, but I'm very confused now as to how to properly reflect the right state. Previously provided: https://github.com/nebulous/infinitude/wiki/Infinitude-API-calls#set-hold

Very helpful. Now I need to understand how I can get the results I want.

If I want to set the setpoints for manual, it's easy enough, then I can switch to that activity by simply sending the target activity (manual) and the until value. That seems just fine.

But if I want to "resume" to whatever is scheduled, then I see strange behavior where the hold mode. If I set the hold mode to off, it appears to just end up in 'home' even though the schedule should be 'sleep', and that hold mode will be set to 'on' even though I just set it to 'off' (activity not provided).

What am I missing here?

[electricessence]

For anyone else's benefit, I'm including some Q&A with GPT 4o:

Q: Can you crawl the infinitude repo and figure out how the actual hold mode works?

The behavior you're observing with the hold mode in Infinitude seems to be related to how the API interprets and applies the "hold" and "activity" settings. Here's a breakdown based on what I found:

1. Hold Mode Mechanics: The Infinitude API allows you to set a "hold" for a specific activity (like home, away, sleep, or wake) by specifying the activity and an "until" time. The "hold" can be turned "on" or "off" to control whether the specified activity should override the schedule. If you set the hold to "off," the API typically reverts to the default schedule, but it seems there might be some issues with timing or sequence of commands that cause it to default to 'home' instead of the expected activity.

2. Timing of Updates: When you change the hold mode or activity, there can be a delay in the actual state reflecting these changes due to the asynchronous nature of the API. This might explain why you're seeing the hold mode switch back to "on" even after you've set it to "off." The state might not be immediately updated to reflect the schedule.

3. Scheduled vs. Manual: If you set the system to "manual" mode, it directly uses the provided setpoints and holds them until you explicitly change them. When switching back to scheduled modes, the system should follow the defined schedule, but any recent manual adjustments could cause it to temporarily default to the last known manual settings until the next scheduled activity kicks in.

To resolve the inconsistencies, you might need to ensure that the sequence of API calls is correct and perhaps add some delay or verification to ensure that the system fully processes the hold mode change before moving to another action.

If these strategies don't resolve the issue, it might be worth diving into the Infinitude code or logs to see how the API is handling these requests internally.

For further information, you can review the Infinitude code on GitHub and its API documentation.

Q: Well reviewing the infinitude code is what I wanted you to do as i don't understand the language their using.

To understand the hold mode in the Infinitude project, here's a summary of how it works based on the information I found in the repository:

1. Proxy and Cache: Infinitude acts as a proxy between your thermostat and the Carrier servers. It intercepts requests from the thermostat, caches them, and then forwards them to the Carrier servers based on the configuration (like pass_reqs settings). This allows Infinitude to respond with cached data to reduce server traffic and sometimes manipulate responses before they reach the thermostat.

2. Hold Mode Behavior: The hold mode in Infinitude can be tricky, especially when interacting with the thermostat's schedule. When you set the hold mode to "off," the system attempts to return to the scheduled program. However, what you're observing, where it doesn't return to the correct schedule (like reverting to "home" instead of "sleep"), could be due to how the schedule and hold interactions are cached or managed by Infinitude. The thermostat might not immediately recognize the change if the cache doesn't reflect the current schedule, causing unexpected behavior.

3. Interaction with Carrier Servers: If Infinitude isn't connected to the Carrier servers (e.g., if you set pass_reqs=0), it can't update its cache with new data from the servers, which might explain the inconsistencies you see. The correct interaction between the thermostat's current state and its schedule can depend heavily on the configuration of Infinitude and its connection status with the Carrier servers【693†source】【692†source】.

In summary, the odd behavior you're experiencing with hold mode likely stems from how Infinitude manages and caches responses, especially when it's set to minimize communication with the Carrier servers. If your thermostat isn't getting updated responses, or if the cache isn't being refreshed correctly, it might not behave as expected when switching between modes. You may need to experiment with different pass_reqs settings or check how Infinitude is handling the state changes to get the behavior you're looking for.

[github-actions[bot]]

This issue has not been active in a while. It will be automatically closed soon absent further activity.