Venstar Thermostat Question

I have a few questions about the Venstar thermostat. I have three of them installed and I have setup some nice rules using Indigo. Here are my questions:

1. Is there a way to implement some kind of HOLD TEMP. I have setup like 5 schedules for one of my thermostats that reset the temp to 77 a few times per day. I would like to make it so if I want to set the temp to 74 to take a nap, it will not change the temp to 77 per the schedule.

2. Is there a way to determine if the unit is ON? I know about the fan status, but I would like to be able to duplicate the green ON light on the Venstar on my control pages.

3. What is the best poll time for the thermostat? The default is 30 minutes but I was wondering if 5 or 10 minutes would be to often.

4. Side question - Does anyone know how to get the backlight to turn on? I know if you push one of the buttons, it turns on but it also adjusts the temp. My old unit would not change the temp on the first button press.

Thanks!

[matt (support)]

1. Are you using the Venstar's scheduling to do this? If so, then the answer it to change the mode out of the Run Program mode and to either Heat, Cool, or Auto.

2. The INSTEON Thermostat adapter does not return information about the operational state of the furnace, compressor, blower motor, etc.

3. Depends. It takes a few seconds for Indigo to poll all of the information out of the thermostat. You can poll every few minutes if you want, but if you start noticing a lag or unresponsiveness when trying to do other INSTEON related actions then you'll want to increase the poll duration.

4. I think there is a Venstar setting to always leave the backlight on. I have mine set to only turn on at night, which the Venstar defines as 6PM to 6AM. Not ideal, but I think there is an option to also have it stay on all the time.

Regards,
Matt

1. Are you using the Venstar's scheduling to do this? If so, then the answer it to change the mode out of the Run Program mode and to either Heat, Cool, or Auto.

No -- I'm using Indigo to manage all temps. I have three of these things and Indigo makes it easy for me to mod my schedules on all of them. I use to do it through my old thermostat and it was a pain.

I am currently using anywhere from 4 to 5 time/date actions per stat to set the cool point. Most of my time/date actions are just to make sure we never leave the temp too low all day.

I oviously could create a variable per stat and create some way to manage it. The only problem is that there is no way for me to have a visible indicator that a HOLD is on other than looking at the variable (IE a control page or the Indigo client).

2. The INSTEON Thermostat adapter does not return information about the operational state of the furnace, compressor, blower motor, etc.

That is not cool. I have noticed at times, that the temp is off a few degrees compared to the current set point and it would be nice to know if the unit was on.

[matt (support)]

Creating a variable for each stat, or creating actions that Disable (and then later re-Enable) all of your Time/Date Actions for a thermostat is the approach I would take.

Are you wanting a visual indicator on the Thermostat itself? I'm not sure how that could be accomplished. You could switch between the modes possible. So reserve the "auto" mode (only use "heat" and "cool) to mean that the temperature is in locked mode.

That is not cool. I have noticed at times, that the temp is off a few degrees compared to the current set point and it would be nice to know if the unit was on.

I believe that is an option configurable on the Venstar. By default it is a couple of degrees but you can reduce it. It'll keep it more accurate but your AC or HEAT will be cycled on and off more often.

Regards,
Matt

Creating a variable for each stat, or creating actions that Disable (and then later re-Enable) all of your Time/Date Actions for a thermostat is the approach I would take.

Are you wanting a visual indicator on the Thermostat itself? I'm not sure how that could be accomplished. You could switch between the modes possible. So reserve the "auto" mode (only use "heat" and "cool) to mean that the temperature is in locked mode.

NOTE: I'm currently polling each stat every 5 minutes.

So tell me what you think of this plan:

1. Use a time date action to check the current mode for each stat.

2. Update a per stat variable to statNameAuto to "true" if the mode is auto and "false" if it is something else.

3. Change my current setpoint scripts to check the specific variable and only change the setpoint if the variable is "true".

Would this be the most efficient way of doing this?

[matt (support)]

This sounds like a reasonable way to hack the auto state for this purpose. You don't need to do #1 though because of the polling. Instead, create a Trigger Action on Device State Changed for Mode Changed to Auto. That Trigger Action will execute whenever the polling updates the mode to/from Auto.

Regards,
Matt

Matt,

Thanks for all your help with this. Rather than use the polling I think it would be better to just pole the current mode using AppleScript. Do you have an example of this?

I know you can do the following:

Code: Select all

status request "Device Name"

Where is all the documentation for device specific coding?

[matt (support)]

Rather than use the polling I think it would be better to just pole the current mode using AppleScript.

Why would you not want to use the built-in polling mechanism? That is what I would recommend. You will likely want Indigo's polling turned on so that the current temperature, setpoint values, etc., are updated periodically, so then all that is left is creating the mode state change Trigger Action.

FYI, there isn't a specific AppleScript verb to send a thermostat mode status request. But you can create an Action Group with the Get Current Mode thermostat action and then execute that via AppleScript.

Regards,
Matt

I had a few date time events fail yesterday. With 3 thermostats polling 6 different values every 5 minutes, it seemed like a lot. Especially when I really only care about the mode. I already went ahead and setup a date time event to poll just the mode data. It seems to be working better.

[matt (support)]

Yeah, that makes sense. Polling just the mode out will be substantially faster than polling all the values.

Matt

there isn't a specific AppleScript verb to send a thermostat mode status request. But you can create an Action Group with the Get Current Mode thermostat action and then execute that via AppleScript.

matt, is this something that will change in a future release?

i'm writing an indigo attachment that extends the indigo thermostat and adds additional functionality. it would be preferable to be able to get the device state under script control.

btw, the added functionality i have so far is:

• named modes, e.g. "occupied", "unoccupied", etc. modes represent setpoints, fan settings, etc. mode can be switched from trigger actions, can be displayed/changed from control pages, etc.
• a "hold" feature (as mentioned above in this thread) that suppresses automated mode changes.
• a "nudge" feature which lets you make ephemeral up/down setpoint adjustments - they go away on the next mode switch.
• notice and log any changes made manually on the thermostat devices.
• humidity compensation (adjustments to setpoint based on humidity).
• fan control (optional fan toggling with duty cycle controlled by mode).

all of the above features are packaged in a way that supports multiple thermostats.

[matt (support)]

You can get and set all of the Thermostat state info via AppleScript on the device model: temperatures, humidities, heat setpoint, cool setpoint, hvac mode, fan mode

Getting the properties above gets the value from what Indigo thinks the current state is for that adapter. So the data may be up to N minutes stale, where N is defined by the polling interval you are using.

Does that address what you need?

I'm looking forward to seeing your script when you are done.

Regards,
Matt

You can get and set all of the Thermostat state info via AppleScript on the device model: temperatures, humidities, heat setpoint, cool setpoint, hvac mode, fan mode

Getting the properties above gets the value from what Indigo thinks the current state is for that adapter. So the data may be up to N minutes stale, where N is defined by the polling interval you are using.

Does that address what you need?

yes, but not as cleanly as i would like.

option 1: i could let indigo poll the thermostat. then i could set up a time/date action to poll the cached state of the device periodically (presumably with the same period that indigo uses to poll the device). this would work, however:

• it requires two time/date actions instead of one, with both unfortunately doing "busy wait" behavior.
• longer latency for my script to notice state changes
• no control over device polling period for different facets of thermostat state

option 2: i could let indigo poll the thermostat. then set up trigger actions that get invoked based on thermostat state changes. this seems like a more attractive option, since it eliminates one level of the "busy waiting". however, there is no way i know of to programmatically (from applescript, i mean) create a trigger action for thermostat state changes, e.g. when type: "device state changed, device: <thermostat>, base on "Operation Mode Changed". although these are very nicely supported via the UI. i can't see in the API how to specify the "operation mode changed" part of this.

to work around this limitation, i could provide the handlers in my script for each type of thermostat state change (mode change, temp change, heat setpoint changed, etc.) and then require that the user manually create trigger actions for these which invoke my handlers. so that's a possible work-around, but rather tedious with six different kinds of state change and it would need to be done separately for each thermostat if there were more than one.

(hypothetical) option 3: i create one or more handlers from which i queries various facets of the thermostat state and i would invoke them from indigo date/time action(s). i might update temp and humidity most often, update setpoints and fan mode somewhat often (since the user can potentially tweak these), and update mode changes less often still (since i'm not expecting any mode changes). this would help keep the insteon traffic down.


so i can and will live with option 1. it feels a bit klugy, but of given the way the thermostat interface was designed w/o state notifications, making it necessary to poll, i suppose its not much worse than the other options.

options 2 or 3 would be slightly preferred to option 1 but each would require minor "gaps" in the applescript interface to be fixed to allow creation of trigger actions like those that can be created manually in the UI.

[matt (support)]

Ah, right. You are trying to do this as an attachment so other folks can use it. I poked around the AppleScript code a bit. I was hoping that you could patch into the AppleScript receive insteon event call, but unfortunately I don't believe that will work. That does get called when remote INSTEON modules broadcast out state changes and button presses, but in this case it is Indigo polling (sending) the command to the Thermostat Adapter so it doesn't get called.

I would go with option #1 right now, and I'll add to my AppleScript ToDo list to further expose some hooks that you need.

Regards,
Matt

Getting the properties above gets the value from what Indigo thinks the current state is for that adapter. So the data may be up to N minutes stale, where N is defined by the polling interval you are using.

Just checking to be sure I understand: Data can be received from the Venstar thermostat only when it is requested at the polling interval, and there's no way in AppleScript (at least, not yet) to "poll now" to get up-to-the-minute data. Is that correct?

I'm wanting to determine when the setpoint has been changed manually at the thermostat, by comparing it with what Indigo set it to, and it's not as easy as I though it would be.