Plugin: AutoVirtualThermostat (AVT)

Plugins & Plugin Development General Plugin Discussion
#141

[quote=“rafale77, post:140, topic:198289”]Thanks, I understand. It is a holistic HVAC control making use of the “room” feature of vera where I make use of several data source within the room:
-windows opened/closed
-vents if they are controlled (only relevant for forced HVAC air setups)
-temperature sensors if they are present
-motion sensors

I am done the lua portion. Will work on the UI device portion next. This might become a different plugin altogether.[/quote]

Even with Reactor, I spend far more time on the JavaScript side than the Lua side of most plugins these days. So much better than the days before jQuery, but still a lot of work.

#142

[quote=“rigpapa, post:141, topic:198289”][quote=“rafale77, post:140, topic:198289”]Thanks, I understand. It is a holistic HVAC control making use of the “room” feature of vera where I make use of several data source within the room:
-windows opened/closed
-vents if they are controlled (only relevant for forced HVAC air setups)
-temperature sensors if they are present
-motion sensors

I am done the lua portion. Will work on the UI device portion next. This might become a different plugin altogether.[/quote]

Even with Reactor, I spend far more time on the JavaScript side than the Lua side of most plugins these days. So much better than the days before jQuery, but still a lot of work.[/quote]

Yeah I am with you. I am not a big JavaScript fan to top it off so this is tedious. I am having to take snippets left and right and modify them. I am taking down my ecobee today and will be testing my new plugin. Thank you for the suggestions!

#143

Patrick,

I recently switched from Zipatile to Vera. I am happy with the decision, but I do miss quite a few of Zipato’s standard features that are only accomplished with plugins through Vera. Two of these happen to be your plugins, Reactor and AVT. Please keep up the good work.

I read here you are working on improving AVT. My hope is you are looking into a more elaborate scheduler. Right now I am using a few AVT devices for daily temperature settings along with some scenes. What I miss with Zipato’s virtual thermostat was the ability to adjust temp set points by the hour on a weekly basis. There was then the option to revert back to programmed settings if the setpoint was manually adjusted through the interface.

#144

I’ve added this request as issue #9 on the Github repository for tracking. I’ve got a number of enhancements working on AVT, and AVT is high on my schedule for a release, but at the moment I don’t have a schedule–I’m focused on a Reactor beta just started, and the upcoming Vera firmware release. Once I clear those hurdles, I’ll have a better idea.

#145

As I ponder this, I’m wondering if this should not be a plugin unto itself. I can put all of this capability into AVT, of course, but wouldn’t it be cool to have ANY thermostat that’s connected to your Vera be programmable? With a uniform user interface for all?

#146

As I ponder this, I’m wondering if this should not be a plugin unto itself. I can put all of this capability into AVT, of course, but wouldn’t it be cool to have ANY thermostat that’s connected to your Vera be programmable? With a uniform user interface for all?[/quote]

I agree, there are a lot of smart thermostats that do not have programming or scheduling ability. I was considering a 2-gig CT-100, but I like the idea of the AVT utilizing my multi sensors for temperature input. I trust you’ll come up with something.

I do have a question related to my Reactor schedule communicating with AVT. I set up RS’ with conditions only related to time of day (and weekend separate). An RS would trip at 5AM, 8AM, 4PM, and 10PM. Each had two trip activities, change both the cooling set point and the heating set point of the AVT. This would have no control over what mode AVT was in, just change setpoints throughout the day. However, it would change both heating and cooling set points to whatever action was last on the list. I read earlier in the thread you had issues with setpoints. I assume this is related.

For now, I just doubled the amount of Reactor Sensors and added a condition for whether it is in heating or cooling.

#147

As I ponder this, I’m wondering if this should not be a plugin unto itself. I can put all of this capability into AVT, of course, but wouldn’t it be cool to have ANY thermostat that’s connected to your Vera be programmable? With a uniform user interface for all?[/quote]

I agree, there are a lot of smart thermostats that do not have programming or scheduling ability. I was considering a 2-gig CT-100, but I like the idea of the AVT utilizing my multi sensors for temperature input. I trust you’ll come up with something.

I do have a question related to my Reactor schedule communicating with AVT. I set up RS’ with conditions only related to time of day (and weekend separate). An RS would trip at 5AM, 8AM, 4PM, and 10PM. Each had two trip activities, change both the cooling set point and the heating set point of the AVT. This would have no control over what mode AVT was in, just change setpoints throughout the day. However, it would change both heating and cooling set points to whatever action was last on the list. I read earlier in the thread you had issues with setpoints. I assume this is related.

For now, I just doubled the amount of Reactor Sensors and added a condition for whether it is in heating or cooling.[/quote]

Vera kinda went afield trying to figure out dual setpoint thermostats, it seems, leaving us with a rather kludged model for setpoints that’s very confusing to sift through, so I’m not surprised you didn’t find what you needed easily.

To set the heating setpoint, use the [tt]SetCurrentSetpoint[/tt] action in the [tt]urn:upnp-org:serviceId:TemperatureSetpoint1_Heat[/tt] service with parameter NewCurrentSetpoint.

To set the cooling setpoint, use the [tt]SetCurrentSetpoint[/tt] action in the [tt]urn:upnp-org:serviceId:TemperatureSetpoint1_Cool[/tt] service with parameter NewCurrentSetpoint.

You can set both in one activity (i.e. one ReactorSensor), you just have to do it in two actions. Setting the setpoint of an inactive mode will not change the mode (i.e. setting the cooling setpoint while in the Heat mode will not change the mode to Cool, it just quietly changes the cooling setpoint).

#148

As I ponder this, I’m wondering if this should not be a plugin unto itself. I can put all of this capability into AVT, of course, but wouldn’t it be cool to have ANY thermostat that’s connected to your Vera be programmable? With a uniform user interface for all?[/quote]

I agree, there are a lot of smart thermostats that do not have programming or scheduling ability. I was considering a 2-gig CT-100, but I like the idea of the AVT utilizing my multi sensors for temperature input. I trust you’ll come up with something.

I do have a question related to my Reactor schedule communicating with AVT. I set up RS’ with conditions only related to time of day (and weekend separate). An RS would trip at 5AM, 8AM, 4PM, and 10PM. Each had two trip activities, change both the cooling set point and the heating set point of the AVT. This would have no control over what mode AVT was in, just change setpoints throughout the day. However, it would change both heating and cooling set points to whatever action was last on the list. I read earlier in the thread you had issues with setpoints. I assume this is related.

For now, I just doubled the amount of Reactor Sensors and added a condition for whether it is in heating or cooling.[/quote]

Vera kinda went afield trying to figure out dual setpoint thermostats, it seems, leaving us with a rather kludged model for setpoints that’s very confusing to sift through, so I’m not surprised you didn’t find what you needed easily.

To set the heating setpoint, use the [tt]SetCurrentSetpoint[/tt] action in the [tt]urn:upnp-org:serviceId:TemperatureSetpoint1_Heat[/tt] service with parameter NewCurrentSetpoint.

To set the cooling setpoint, use the [tt]SetCurrentSetpoint[/tt] action in the [tt]urn:upnp-org:serviceId:TemperatureSetpoint1_Cool[/tt] service with parameter NewCurrentSetpoint.

You can set both in one activity (i.e. one ReactorSensor), you just have to do it in two actions. Setting the setpoint of an inactive mode will not change the mode (i.e. setting the cooling setpoint while in the Heat mode will not change the mode to Cool, it just quietly changes the cooling setpoint).[/quote]

Perfect, thank you!

#149

Sorry, it looks like I thanked you too soon… :-\ I never tested it, at 4PM I had to two trip actions set. One for heating and one for cooling, using the parameters you suggested. FYI, before I was using the different parameters that said SetHeatingSetPoint in the title. Needless to say, it switched both the heating and cooling setpoints to the value of the second trip action.

#150

OK. As a first step, can you send me a “Logic Summary” (link on the Tools tab of the ReactorSensor) for both?

#151

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
Version: 2.3 config 206 pluginDevice 90
Local time: 2019-03-24T01:57:44-0400, DST=1
House mode: 1
Sun data:
Geofence: not running
Power: utility, battery level 92

TEMP SET: 8AM M-F (#118)
Version 19012.1553407041 03/24/19 01:57:21
Message/status: Not tripped
Group #1 false as of 03-22.13:02:34
=f (comment) “MONDAY - FRIDAY AT 8:00AM: 66°F (HEAT) 73°F (COOL)” [false/false as of n/a/n/a; nil at n/a]
=f (weekday) { “id”: “cond169a4fddb52”, “type”: “weekday”, “value”: “2,3,4,5,6”, “operator”: “” } [false/false as of 03-23.00:00:00/03-23.00:00:00; 7 => 1 at 00:00:00]
=f (interval) { “type”: “interval”, “mins”: 0, “id”: “cond169a4feaa49”, “hours”: 0, “days”: 1, “basetime”: “08,00” } [false/false as of 08:00:15/08:00:15; 1553274131 => 1553342400 at 08:00:00]
=T (housemode) in 1,2,3 [true/true as of 03-22.15:07:51/03-22.15:07:51; 1 at 03-22.15:07:51]
Trip Actions
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/SetCurrentSetpoint( NewCurrentSetpoint=66.0 )
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint=73.0 )
Untrip Actions (none)
Events
03/23/19 18:44:47 start:
03/24/19 01:57:20 configchange:

These were the parameters I had set for each time interval, but it was grabbing the value of the second action for both heat and cool.

#152

OK. So far I’m not able to duplicate the behavior you are describing on the current AVT release (1.5 in the Vera app marketplace). Are you just looking at the setpoint temps on the UI (dashboard card in the Devices list)?

Let me have you do this:

  1. Go to the Tools tab of the ReactorSensor and hit the “turn on debug” link.
  2. Go back to the Status tab and hit the “Reset” button (not Restart).
  3. Wait a moment, then hit the “Trip” button.
  4. Wait a moment, then hit the “Reset” button again.
  5. Go back to the Tools menu and create a Logic Summary; copy and paste it here.
  6. Go into the Advanced tab, Variables subtab of the AVT device and look at SetpointHeating and SetpointCooling. I bet they have the correct values.

I just noticed that if I go into “Heat” (only) mode and hard-refresh my browser, UI7 royally screws up the thermostat display. I still can’t duplicate your specific results, but my result is a different kind of broken, but broken nonetheless. if you are running different firmware from me (you appear to be on a Secure, which I don’t have), that may explain your different results, as the UI for thermostats has had subtle shifts over time, some of which have broken UI elements and behaviors (reported, but no fix as yet).

The other thing that looks odd to me is that you are using an Interval condition for determining the time. It would be better to use a “Date/Time” condition with the “after” or “between” operators. If you use “between”, make the period covered the full period between your time bands (e.g. between 0800 and 1600, between 1600 and 2200, and perhaps between 2200 and 0800 to cover the through-midnight period).

#153

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
Version: 2.3 config 206 pluginDevice 90
Local time: 2019-03-24T18:39:28-0400, DST=1
House mode: 1
Sun data:
Geofence: not running
Power: utility, battery level 98

TEMP SET: 8AM M-F (#118)
Version 19012.1553466936 03/24/19 18:35:36
Message/status: Not tripped
Group #1 false as of 03-22.13:02:34
=f (comment) “MONDAY - FRIDAY AT 8:00AM: 66°F (HEAT) 73°F (COOL)” [false/false as of n/a/n/a; nil at n/a]
=f (weekday) { “id”: “cond169a4fddb52”, “type”: “weekday”, “value”: “2,3,4,5,6”, “operator”: “” } [false/false as of 03-23.00:00:00/03-23.00:00:00; 7 => 1 at 00:00:00]
=f (interval) { “type”: “interval”, “mins”: 0, “id”: “cond169a4feaa49”, “hours”: 0, “days”: 1, “basetime”: “08,00” } [false/false as of 08:00:15/08:00:15; 1553342400 => 1553428800 at 08:00:00]
=T (housemode) in 1,2,3 [true/true as of 03-22.15:07:51/03-22.15:07:51; 1 at 03-22.15:07:51]
Trip Actions
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/SetCurrentSetpoint( NewCurrentSetpoint=66.0 )
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint=73.0 )
Untrip Actions (none)
Events
03/24/19 18:28:00 start:
03/24/19 18:35:36 configchange:
03/24/19 18:36:53 action: action=Reset
03/24/19 18:36:53 sensorstate: state=false
03/24/19 18:37:25 action: action=Trip
03/24/19 18:37:25 sensorstate: state=true
03/24/19 18:37:25 startscene: scene=__trip118, sceneName=__trip118
03/24/19 18:37:25 runscene: scene=__trip118, sceneName=__trip118, notice=Starting scene group 1
03/24/19 18:37:25 endscene: scene=__trip118, sceneName=__trip118
03/24/19 18:37:29 action: action=Reset
03/24/19 18:37:29 sensorstate: state=false

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
Version: 2.3 config 206 pluginDevice 90
Local time: 2019-03-24T19:04:58-0400, DST=1
House mode: 1
Sun data:
Geofence: not running
Power: utility, battery level 98

TEMP SET: 4AM DAILY (#119)
Version 19012.1553468468 03/24/19 19:01:08
Message/status: Not tripped
Group #1 false as of 04:00:15
=f (comment) “EVERY DAY AT 4:00 AM: 71.5°F (HEAT) / 69°F (COOL)” [false/false as of n/a/n/a; nil at n/a]
=T (weekday) { “id”: “cond169a626d1c3”, “type”: “weekday”, “value”: “1,2,3,4,5,6,7”, “operator”: “” } [true/true as of 03-22.12:10:43/03-22.12:10:43; 7 => 1 at 00:00:00]
=f (interval) { “type”: “interval”, “mins”: 0, “id”: “cond169a629e10f”, “hours”: 0, “days”: 1, “basetime”: “04,00” } [false/false as of 04:00:15/04:00:15; 1553331600 => 1553414400 at 04:00:00]
=T (housemode) in 1,2,3 [true/true as of 03-22.15:08:19/03-22.15:08:19; 1 at 03-22.15:08:19]
Trip Actions
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/SetCurrentSetpoint( NewCurrentSetpoint=71.5 )
Device 99 (THERMOSTAT) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint=69.0 )
Untrip Actions (none)
Events
03/24/19 18:28:00 start:
03/24/19 18:53:32 action: action=Reset
03/24/19 18:53:32 sensorstate: state=false
03/24/19 18:53:34 action: action=Trip
03/24/19 18:53:34 sensorstate: state=true
03/24/19 18:53:34 startscene: scene=__trip119, sceneName=__trip119
03/24/19 18:53:34 runscene: scene=__trip119, sceneName=__trip119, notice=Starting scene group 1
03/24/19 18:53:34 endscene: scene=__trip119, sceneName=__trip119
03/24/19 18:53:36 action: action=Reset
03/24/19 18:53:36 sensorstate: state=false

I don’t know what changes running the debug option, but after following your steps this executed properly. Both the UI of AVP and the variables updated to 68 for heating, 73 for cooling.

Since I was thinking I am crazy, I double checked the other schedules. The exact same set up (interval is now 4AM). The first trip action is set heat to 71.5, set cool to 69.0. When I tripped the sensor set both heat and cool to 69.0 in UI and in the variables tab.

If I go back and trip the 8AM Mon-Fri, it again executes correctly. I’ve restarted the plugin, tried everything to my little knowledge of this stuff but I cannot get both set points to update. I’m stumped.

Also, my reasoning for choosing the interval condition was to have the ability to adjust the thermostat manually without disabling the “program.” I plan to mount a cheap tablet on the wall where the Zipato was to have the Vera or Imperi app running. This way someone can easily turn up the heat (or cooling) in between the interval.

#154

It’s a pretty common misunderstanding of the way Reactor operates (probably the most common, I think) to think that a “between” (or “after”) time schedule will make the task fire repeatedly or continuously. It does not. The condition being met only triggers the action once. It can’t be “more between” or “more after”. It’s a boolean state, it is or it isn’t, so once the condition is met and the actions are run, they are not run again (without manual intervention) until the condition first resets and is then triggered again.

You cannot set the cooling setpoint below the heating setpoint. That does not make sense. If that were possible, your heater being on would trigger cooling. Your second sensor attempts to set the heating setpoint to 71.5, and then the cooling setpoint to 69. You are asking it to heat your house to 71.5 but keep it down to 69. Can’t do that. The heating setpoint must always be below the cooling setpoint. By setting the cooling setpoint to 69 when heating is at 71.5, AVT is reducing the heatpoint to 69 as well (so with other parameters default, it will call for heat at 68 and cooling at 70–there’s a one degree deadband).

Heating setpoint = the temperature below which heating will be run (goal: bring the temperature up to that point).
Cooling setpoint = the temperature above which cooling will be run (goal: bring the temperature down to that point).
Between heating and cooling setpoints, nothing happens.

#155

That too was my understanding of how the Reactor operates. I will switch my conditions from interval to between.

And wow, I can’t believe that is the reason I thought there was an error… I understand in the physical sense why you couldn’t have a cooling set point lower than a heating. Which is why I was preferring the method of Heat Only or Cool Only versus an Auto Mode. I see now that when you switch to Auto it uses the same set point values, so yes, that built in logic makes complete sense.

I apologize for taking up your time.

#156

It’s no problem, I’m happy to do it. Sometimes it takes a bit of back and forth to get to the “ah ha” moment. Thanks for sticking with it and posting the summaries.

#157

Hi, I’ve just started using a Vera Plus with the intention of running some far infrared heating panels to a temperature sensor and found the AVT app which looks like a great thermostat. I’m using scenes to schedule and just want it to switch between comfort and eco. I can’t find a specific variable for Comfort/Eco mode in the advanced settings to be able to set up Luup code. What code would I use to set this?

#158

I’m having trouble parsing this. Are you saying you are looking for an action to switch you between Normal and EnergySavings?

#159

In the scene I’m configuring, if I select the AVT under “device actions” it says it’s going to set four variables (Setheatingsetpoint, Setcoolingsetpoint, comfort, heat). All I want it to do is change comfort to economy when the scene triggers. (if the AVT mode is set to off I don’t want it to turn it to heat etc.)

#160

Please post a screen grab.