The Vera Community forums have moved!

Advanced => Programming => Plugins & Plugin Development => Topic started by: rigpapa on January 16, 2018, 03:22:32 pm

Title: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 16, 2018, 03:22:32 pm
I'm starting a new thread for AutoVirtualThermostat, and as seems to be tradition, in future I'll update this post with the latest information on its ongoing development.

For the benefit of those who haven't been party to the other discussions, I've received permission from the original developer of Smart Virtual Thermostat to continue its support (he's apparently moved on to another platform). During the time I was awaiting his reply, I started working on a new framework for the project, and released that as Auto Virtual Thermostat.

AutoVirtualThermostat (AVT) implements an auto-changeover thermostat that accepts input from a number of temperature sensors (configurable), and drives a heating unit, cooling unit, and fan unit. The driven units are expected to be a device that implements the SwitchPower1 service, so they can be an in-wall switch/receptacle, appliance module, etc. (properly rated for the task, of course). Any of the three units are optional (i.e. if you just need heat, you only need a heating unit and you can omit configuring a fan unit or cooling unit).

Documentation is available on my web site (http://www.toggledbits.com/avt/). The GitHub repository is here (https://github.com/toggledbits/AutoVirtualThermostat).


TROUBLESHOOTING

If AVT isn't behaving as expected, take a look at your log file and make sure AVT hasn't logged something informative that will lead you to a solution. You can see the current log snapshot by requesting this URL in your browser:

http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

You can use your browser's in-page search feature to look for the string "AutoVirtualThermostat" to find AVT's logged messages. If an AVT is going offline because of temperature sensor problems, search through the logs for the word "ineligible," which appears in every message AVT logs when a thermostat is rejected, along with the reason.

If you need to report a problem, it's generally helpful for me to have some information about your configuration. You can email me using the email link in my profile, and please attach or include the output from the small "Status Data" link at the bottom of AVT's settings page. It is not necessary to turn debug on first, and better if you don't, unless I ask you do to it.


REVISION HISTORY
2018-07-24: The stable branch on Github now contains an openLuup-compatible version of AVT. It can be installed via the AltAppStore, or by downloading the plugin files from Github and installing them in your openLuup directory tree.

2018-03-04: Version 1.4 has been submitted to Vera for approval, and is expected to be available tomorrow. This version incorporates the full fixes for prior battery state checks on temperature devices. It also tracks Vera-specific state variables for setpoint better, so external code or apps may work better. Adds some additional debug data to status requests, and puts debug links on the settings page so users can more easily get to those functions when needed.

2018-02-12: Version 1.3/1.3.1. This is a hotfix/bugfix release only and contains the fix for battery-powered sensors causing update failures. This release is available on GitHub (https://github.com/toggledbits/AutoVirtualThermostat/releases/tag/v1.3) for you early-adopters.

2018-02-05: Version 1.2 released. This is a maintenance release to address some feature requests, and contains the following fixes and enhancements:

2018-01-16: Version 1.1, fixes some minor bugs, and adds a requested "Economy/Comfort" feature. Note that the up/down setpoint controls in the device configuration view do not operate as expected--this is the result of a bug in UI7 for which I have received confirmation from Vera will be fixed by 1.7.26. The setpoint controls in the dashboard view function correctly (disparity on their side in the implementation of the slider control between the two views).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 16, 2018, 03:53:41 pm
Good stuff! Keep up the good work.  :)

I've used the AVT for a while, and the only thing i'm missing now from the SVT is that i can't find the thermostat in imperihome?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: sebby on January 16, 2018, 04:00:54 pm
I'm starting a new thread for AutoVirtualThermostat, and as seems to be tradition, in future I'll update this post with the latest information on its ongoing development.


Dude, you are just knocking out all my dream plugins for the Vera.  Keep up the great work!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 16, 2018, 06:09:05 pm
@Forzaalfa, since I don't use ImperiHome, I honestly don't have any idea how to bridge that gap. I haven't done any research into it at all yet. The plug-in implements all the services that are common to thermostats, and in fact, I originally used the old Nest plugin as a model. You'd think that would be enough. I guess I'm going to have to go digging.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 17, 2018, 12:26:25 pm
OK. I figured it out (Imperihome). The change is straightforward to get it showing in Imperihome (and bonus, in the Vera app as well), but in the Vera's web-based UI the Vera supplies its own native interface now instead of mine. While this is good for consistency, it's bad in that proper operation of Vera's native UI requires changes to internals of AVT. AVT is implemented closely to the published UPnP standards for the HVAC_OperatingMode1 service and others, but Vera deviates quite a bit, and their native UI depends on that. I'm not really thrilled about that, because I prefer to follow published standards where they exist. But this is another one of those times with Vera where standing on purity/principal doesn't get the project to the goal, so...

I'm going to hold this week's previously-announced release of AVT to make the necessary changes to make it work the Vera way, and test it well before I let it go.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 17, 2018, 05:29:43 pm
Very good! Let me know if you need help testing it. ☺
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 17, 2018, 05:52:58 pm
No, it's not good. More to follow.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 18, 2018, 01:47:16 pm
OK. It's ugly. Really ugly.

If I change AVT's device type to the generic HVAC_ZoneThermostat1, the web UI, Vera Android app, and Imperihome all seem to recognize the device as a thermostat. That's good. Not good is that all three interfaces show the device as a single-setpoint thermostat. AVT maintains separate heating and cooling setpoints (like Nest). Worse is that the Vera web UI also shows no status information (you can't see if it's running heating or cooling, or not). All of that would be presented by AVT's controls specified in the static JSON file, but UI7 ignores that when it sees the HVAC_ZoneThermostat1 device type.

And it's easy to see why. Looking through the UI7 interface code, Vera makes a ton of hard-coded exceptions for thermostats. It's... a bit of a mess, in that some of functionality is driven by the device category, some by the device type, and some by filename of the static JSON file. For Nest specifically, they hard code exceptions to make Nest's two setpoints available, and they add some status display that doesn't appear in the generic thermostat interfaces (that is, while their generic thermostat UI looks like the Nest-specific UI, they've omitted functionality that is actually generic to all thermostats and useful to the user).

I also noticed that the UI code makes an odd exception for a specific static JSON file by name, coincidentally called HVAC_TwoSetpointsThermostat1.json. I could use it, and it would, in fact, modify the interface to show separate heating and cooling setpoints, but still no status display, and worse, because it's their JSON and not AVTs, there's no definition to link AVT's configuration tab, so it leaves the user with no way to configure what temperature sensors and switches to use. Unacceptable.

I'm going to reach out to Vera about this, but even if they agree to make some enhancements in this area, they won't be coming quickly. That has previously been promised but appears to be undelivered as of yet. I suspect that every change for them in this area has potential to create a lot of side-effects and unintended consequences, and for one little plugin that probably only a handful of people use, it's likely not going to be worth it to them. IMO, this area needs a rethink on their part, and that's a UI8 opportunity.

A side note to this is that both ImperiHome and the Vera app could do better as well. Rather than pinning to the device type as they appear to do now, all of these UIs could recognize the category of thermostats (5), then present a thermostat UI--the basic services/actions an interface would need are well-known, and better still, can be more specifically determined by enumerating the device's actions and variables published in the device (D_.xml), implementation (I_.xml) and service (S_.xml) files. The data is all there. For example, a thermostat that does not publish the SetEnergyModeTarget action in its implementation doesn't support changing energy modes, so that part of the UI can be hidden/omitted.

Anyway, here's the choice for AVT at the moment, as I see it: assuming nothing changes on the Vera side in the short term, I can either leave AVT as it is, which means it can't be seen or manipulated from Imperihome and the Vera Android app (which is as it has been since publication), but everything works as designed; or, I can change the device type to the generic, and let Vera take over the UI, so AVT becomes visible in the Vera Android app and ImperiHome, but loses a chunk of its functionality for all users to the benefit of the few using those apps.

For the moment, then, I'm leaning toward leaving AVT with its current (custom) device type.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 19, 2018, 01:48:05 am
Its never simple, is it!

About the layouts; I think the multiple setpoints dont have to be visible at the front at all. The immediate info i need is: What mode is active, the current active setpoint (changes to the correct setpoint when changing mode), and the current room temperature (and only if one is using more than one sensor, if not its not neccesary either?). Editing beyond that i think is OK to do on the control tab?

If you agreee with this, the standard GUI would suffice right? And if extra functions is needed, keep the in control tab or even in variables?

I Agree that its not the ideal solution..
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 19, 2018, 10:47:40 am
Unfortunately that won't do. It ignores the UI defined by the plugins static JSON both on the dashboard and in the device settings.

Honestly, if ImperiHome is using the device type and not the device category as I suspect it does, it is missing out on an opportunity to support a lot of plugins with no additional effort and great potential advantage to its users. There are many apps that do it that way, it's just unfortunate that ImperiHome and Vera's own Android app don't seem to be among them.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: therealdb on January 20, 2018, 01:55:33 am
What about creating a master and a child devices? You can use the master the way you want and the child as a standard thermostat.

This is the same strategy used by most of the thermostat plug-ins.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on January 20, 2018, 04:57:24 am
Great news ! I can?t wait to try out this instead of SVT. I have been waiting for Eco/Comfort before making the move :-)

Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 21, 2018, 12:10:20 pm
I know the Nest/WWN uses child devices, although not for that reason. I can't think of a thermostat plugin that uses it as a workaround to ImperiHome's display, but I'd be happy to look if you can point one out. In any case, I may try that approach later, but I already know that it's not as simple as creating a child device with the generic device type. The generic interface requires a bunch of Vera-implementation-specific state that is not part of the normal UPnP spec for thermostats. That's deep enough that in my previous attempt to get this working, I had to make fairly widespread changes in how AVT operates internally to deal with where Vera and UPnP conflict. If I write the child device to maintain separate state entirely in the Vera state model, I'm basically duplicating the plugin in a child device of itself. Egad. Sorry guys, but I really have to ask myself, is this worth the trouble in both original work and ongoing support just to get the plugin showing up in an app that I believe should be behaving differently? Maybe somebody that uses ImperiHome should suggest to its author(s) that they broaden their approach to interpreting device category? That would have a widespread benefit by immediately enabling many other plugins to be seen and controlled in the app.

In any case, I don't want to hold up version 1.1 of AVT any longer. I've submitted that to Vera for approval, which will hopefully get in for their Monday (tomorrow) review and approval.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 21, 2018, 12:26:55 pm
I will shoot of an email to the imperihome guys later, refering to this thread.

Thanks! :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 22, 2018, 06:07:18 pm
Well, one finds the most interesting things when one isn't looking for them! In looking at an another thread, I saw reference to an ImperiHome "Standard System API". Lo and behold! That API can provide an elegant(-ish) solution without losing functionality on either end!

I've just pushed the working code (https://github.com/toggledbits/AutoVirtualThermostat/tree/develop) up to the Github repository "develop" branch. The two implementation files were modified (I_AutoVirtualThermostat1.xml and L_AutoVirtualThermostat1.lua). You can download them (go to each, right-click the "Raw" button, choose "Save Link As" or your browser's equivalent), and then upload both to your Vera (Apps > Develop apps > Luup files), if you want to live on the bleeding edge.

To connect ImperiHome:

If anyone is brave enough to try, let me know how it goes for you. It was fits and starts for me, but now it's working smoothly, so hopefully I've flattened all the wrinkles.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 23, 2018, 01:55:06 am
Installed the files, but i don't think i can add the imperihome system from a remote location, so i'll get back to that when i get home.

the github link is wrong, heres the right one (https://github.com/toggledbits/AutoVirtualThermostat/tree/develop).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 23, 2018, 08:24:43 am
Whoops! Thanks for catching that. I fixed the link in the original post as well.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 23, 2018, 10:58:59 am
Ok, something happened here when i installed the files.. RFXtrx433 communication died, and now I can't set port 3481 for it in serial config. that was random! Is it connected, you think?

Lost all communication to my 433's..  :-\
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 23, 2018, 11:29:02 am
..and i had to delete AVT completely to get them back.. ?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 23, 2018, 02:28:50 pm
That seems really random. AVT is an entirely virtual device, with no serial or TCP communications at all. It's hard to imagine it disrupting comms of other devices. If you end up trying again and it repeats, grab your logs and PM me; I'll send you my email address and you can send them to me.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 24, 2018, 01:49:54 am
I know. And even if it helped yesterday I still see some instances of temperatures not updating, so its probably something with the FW release..

How do i pull logs? I have a USB and i've enabled log to USB, but I havent figured out how  to read those logs?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 24, 2018, 08:25:59 am
You can USB and all that, but I think using the built-in CGI log reader is the most straightforward:

http://vera_ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

Notice we don't use the 3840 port number in this URL... it's just straight HTTP to the Vera. This will display the log. You can copy-pasta from there.

EDIT: By the way, on temps not updating, I've already found a UI7 bug and reported to Vera, and they've committed to fix in 1.7.26. I found another bug yesterday working on a separate plug-in where UI also doesn't update when dependent state variables change. Sigh...
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 25, 2018, 02:57:15 pm
Thanks for this app, the french on SVT was killing me!

a few things.

1. For some reason my heater keeps cycling on and off even though it hasn't reached the setpoint. All settings seem to be ok so not sure why that is happening
2. I can't seem to control this from ALTUI
3. Is there an easier way to set the Eco mode setpoint? Seems can only be done by modifying the variables?
4. PLEG doesn't seem to recognize the device well
5. Authomation and Imperihome issues
(all the above were fine in SVT)

Thank you
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on January 27, 2018, 06:46:30 pm
I finally got around to test the AVT but I have some observations below. I did read the instructions on your site but I was unable to find answers there:


Thanks for your
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 27, 2018, 10:07:05 pm
How do the temperature settings work ? Is it high/low temp ? Raising the Left temp will also raise the right and lowering the right temp will also lower the left. In SVT the temps were different, left for Comfort heat and right for Eco. I notice in AVT I have 2 sets of temperature settings, one for Eco and 1 for Comfort.

In AVT the temperature on the left is the heating setpoint (the temperature below which the thermostat will call for heat). The temperature on the right is the cooling setpoint (the temperature above which the thermostat will call for cooling). You cannot set the heating setpoint above the cooling setpoint, nor the cooling setpoint below the heating setpoint (either condition would cause heating and cooling to run simultaneously).  You are correct, the Comfort and Economy setpoints are two different sets; switching energy modes switches between the two.

Quote
I need to be able to add 2 heating devices. I tried adding 2 with a comma inbetween in the advance settings, but then it seems to clear the entry. I have electric heaters which I turn on/off based on the temperature.

AVT supports only one cooling, heating, and fan device each. You can work around this by setting your second heating device on the fan device. There are delays associated with the fan device you may want to remove. Set both FanOnDelayHeating and FanOffDelayHeating to 0 to disable these delays. And you'll want to keep the fan mode in Auto at all times.

Quote
When I try to create a scene with AVT, I cannot change the temperature ?

I will look into this. In the meanwhile, you can add the following Lua to your scene (for heat setpoint):

luup.call_action( "urn:upnp-org:serviceId:TemperatureSetpoint1_Heat", "SetCurrentSetpoint", { NewCurrentSetpoint=value }, AVTDeviceNumber );

Quote
AVT does not show up in Imperihome

Known issue with ImperiHome. There's a workaround that's in test. See reply #14 in this thread.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 27, 2018, 11:36:29 pm
Any way to disable cooling altogether? Only need for heat. Also, what is the best way to change the economy mode setpoint?

M
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 27, 2018, 11:43:19 pm
No way to disable cooling. Just don't set a cooling device. Nothing will happen.

Changing the economy setpoint is done from the UI by switching to Economy mode, setting the setpoints, and returning to Comfort mode (if that's where you want to be).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 28, 2018, 12:19:55 pm
Thank you. Is there any reason why I can't switch modes in all ALTUI?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 28, 2018, 12:39:31 pm
I'll look into it and report back.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 28, 2018, 02:02:15 pm
When I try to create a scene with AVT, I cannot change the temperature ?

I will look into this. In the meanwhile, you can add the following Lua to your scene (for heat setpoint):

luup.call_action( "urn:upnp-org:serviceId:TemperatureSetpoint1_Heat", "SetCurrentSetpoint", { NewCurrentSetpoint=value }, AVTDeviceNumber );


OK. This appears to be a bug in UI7's slider_vertical control implementation. For the moment, the above proposed Lua is the way to get the job done. In the long run, I've planned on switching to the newer and much better looking spinner_horizontal control (like the ones in the Nest implementation). If you're brave enough to try development code, the Github repository has those changes in the develop branch (https://github.com/toggledbits/AutoVirtualThermostat/tree/develop).

Now, on to look at what's going on over on ALTUI...
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 28, 2018, 02:25:56 pm
I'll look into it and report back.

Do you mean operating mode (Off, Heat, Cool, Auto) or energy mode (Comfort, Economy)? Also, are you using ALTUI on Vera, or ALTUI on openLuup?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 28, 2018, 08:51:14 pm
Energy mode. Vera
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 28, 2018, 11:57:44 pm
That's an ALTUI thing. Apparently the implementation of the multi-state button (the sliding on-off control) on ALTUI expects only numeric state values to back it, where Vera allows string or numeric. I've brought this up with amg0 and he's looking at it, and I don't know if he'll decide to bring his version into parity with UI7, or leave it, because nobody else has noticed until now. He's been pretty quick to deal with other things I've thrown at him, though.

In the meanwhile, I can work around that by creating a shadow state variable that follows the sense of the string-based state variables. Code is already up on Github in the develop branch, if you're feeling like an early adopter.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 31, 2018, 11:04:29 am
One of my AVT devices is showing an error symbol and no temp is shown. The underlying devices are ok.

How do I troubleshoot this?

M
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 31, 2018, 12:12:26 pm
That means that there are no valid temperature sensors. For a temperature sensor to be valid, it has to return a numeric temperature, updated within a recent period of time, and if battery powered, have a valid battery status.

A value from the sensor is considered "recent" if the timestamp of its CurrentTemperature is less than MaxSensorDelay seconds ago. The default is 3600, or one hour, which is a pretty long time.

The battery level of the sensor (if it's battery-powered) is considered acceptable if has been provided within the last MaxSensorBattery seconds, and the level itself is greater than zero.

If a sensor is configured but ineligible, that fact will be logged in Vera's log file. Request this URL in your browser:

http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

You can browse through or use CTRL-F to search for "AutoVirtualThermostat" in that page content to find the messages that are relevant. You can more specifically search for the word "ineligible", which is used in the messages AVT logs when a sensor is rejected.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on January 31, 2018, 12:46:04 pm
Got it. Thanks. At that point the device shuts off?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 31, 2018, 12:53:59 pm
Yes, for safety. If there are no valid temperature sensors, AVT goes into idle state. When a sensor updates with a valid value, it will resume operation on its own.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: opel-oleg on January 31, 2018, 03:07:34 pm
Heating is ....
Cooling is ...
Ventilation is ...
And did not you have a desire to add a humidity sensor? :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 31, 2018, 03:20:58 pm
No, I've thought about it. You're the first to ask. My thought was to have it run the cooling device (which could be either an AC unit or dehumidifer). Would that be consistent with your expectation? Or perhaps a separate dehum device, but use the cooling device if no dehumidifier device is specified?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: opel-oleg on January 31, 2018, 03:47:52 pm
hmm, I have a few places in which I would like to control the humidity. Bathroom, cellar ...
If there is a universal device, why not use ...
And in different cases, use only a fan, or together with heating.
Sorry for my English. It's not me, it's Google :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: petertn on February 01, 2018, 04:00:10 am
and outside temperature will be in the future?
I don't understand 2 temperatures options in comfort and economy mode ... 
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on February 02, 2018, 06:25:29 am
Petertn: The two settings is for engaging heating and cooling in the two different modes.

I installed the released app yesterday, and four instances is now running Just fine. I may try the imperihome update later, i just want to see that averything works as it should first.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 02, 2018, 05:31:22 pm
We might have different ideas about what Comfort vs Economy is. For me, it's Home vs Away. So think of Comfort as the setpoints that are in effect when you are home, and Economy as the setpoints when you are away.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 04, 2018, 12:40:21 pm
AVT 1.2 has been released and is pending approval by Vera for the plugin store. See the first post in this thread for release notes.

This release introduces ImperiHome support for local use, which must be done using the ImperiHome ISS API, meaning you add AutoVirtualThermostat as a system in ImperiHome:
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kebob on February 05, 2018, 09:28:10 am
Just trying this out, and it looks good, I may switch from SVT.

Am I mis-remembering that an older version (last year?) had a sensor offset variable?

I'd like to use an average over 3 sensors, but one of them is a radiator control valve so always reads a couple degrees high for the room as its right next to the heat source. There's no offset control on the device itself.

Edit: Hmmm, seems my 'heat' devices arent getting the correct kind of "HeatOn" command?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 09:56:34 am
There's no offset variable. Since multiple sensors are possible, I'll have to come up with a mechanism of gathering and storing the offsets for each individual device. Stay tuned.

With regard to your heating device, what type of device is it? AVT expects devices that implement the SwitchPower1 service.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 05, 2018, 10:12:46 am
AVT 1.2 has been released and is pending approval by Vera for the plugin store. See the first post in this thread for release notes.

This release introduces ImperiHome support for local use, which must be done using the ImperiHome ISS API, meaning you add AutoVirtualThermostat as a system in ImperiHome:
  • From the ImperiHome app, choose My Objects in the menu;
  • Click Add a new object;
  • Select ImperiHome Standard System;
  • Enter the Local API Base URL: http://your-vera-ip/port_3480/data_request?lr_AutoVirtualThermostat&action=ISS
  • Click Next to connect.

Having some trouble today, not sure if related to update

1. I use PLEG to manage on and off off Eco mode on a schedule. This morning, the scene would not work at all, had to manually put AVT into Normal mode
2. One of my devices shows 62F while the underlying thermostat shows 67.5F and polls just fine. I can't seem to get this to change at all and system is stuck in IDLE even though set for heat 71

ty

M
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 10:47:12 am
Request this URL from your Vera and send me the output via email or PM (email is available on my profile):

http://your-vera-local-ip/port_3480/data_request?id=lr_AutoVirtualThermostat&action=status
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 05, 2018, 11:05:27 am
Done. ty
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 11:23:32 am
Your "Adjusted Guest Temp" sensor #237 is reading a current temperature of 62 according to its state variables. It is missing a lot of state that normally accompanies the TemperatureSensor1 service and devices in general. What kind of device is this?

On the energy mode scenes, can you check your scenes using the Advanced Editor and see what your scenes are trying to do? I am able to use scenes to change between Comfort and Economy, no problem. The only thing the scene should be doing is sending the SetEnergyModeTarget action with either Normal (for Comfort mode) or "EnergySavingsMode" (for Economy).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 11:29:41 am
Ah... wait. I see you have a second device.

Check this URL. Search for "AutoVirtualThermstat" in the logged entries, and see what it says about your temp sensors.

http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 05, 2018, 11:33:20 am
That is a virtual temp device that is manually updated via pleg to adjust a real temp sensor, however, that is not the AVT with the issue. It is AVT device #352 which is reading 62 as well while its temp device (#354) is showing 69.5

The Pleg scene seems to be ok now, not sure why it wasn't working before.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 05, 2018, 11:40:09 am
Ah... wait. I see you have a second device.

Check this URL. Search for "AutoVirtualThermstat" in the logged entries, and see what it says about your temp sensors.

http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

Not sure what i am looking for but i don't see any errors
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 11:58:00 am
Everything looks normal, except for one thing. Have you manually edited TempSensors on any device? Or have a PLEG rule or scene that is trying to set it?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 05, 2018, 12:06:38 pm
I may have done that on the offending device when i first set it up (like SVT) i hadn't seen your new dropdown feature. That said, this was a while ago and all was working ok until yesterday
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 12:11:32 pm
OK. Give me a few minutes to get to my desk. I'm going to email you instructions to get a full log.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kebob on February 05, 2018, 01:24:28 pm
There's no offset variable. Since multiple sensors are possible, I'll have to come up with a mechanism of gathering and storing the offsets for each individual device. Stay tuned.

With regard to your heating device, what type of device is it? AVT expects devices that implement the SwitchPower1 service.

I actually have to switch two devices for heat (SVT allows this, though I can use a scene instead with AVT) They're an SSR302 and an ASR-ZW.

I think (am not an expert!) both work with a SetModeTarget = HeatOn/Off, rather than SwitchPower
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 01:33:12 pm
You can also abuse the fan device for your second heating device. No scenes required. Just set the FanOnDelayHeating and FanOffDelayHeating variables to 0 to avoid the default delays associated with fan operation.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2018, 03:34:23 pm
OK. I think I've tracked down resq93's issue. For background (so you don't have to read the relevant parts of this thread), he has one thermostat of two that doesn't update temperature properly, and won't launch heating/cooling (that is, it's dead). It looks like I injected a bug into 1.2 when I added the MinBatteryLevel variable and its related test. This addition was made to allow users with battery-powered sensors to set a minimum level at which the battery is trusted. Version 1.1 assumed all was OK as long as the temperature update was recent (that is, the thermostat is still providing updates, so it's battery must be good enough).

Fortunately, there's a simple workaround, which I've described in the head message of this thread (http://forum.micasaverde.com/index.php/topic,54232.msg340469.html#msg340469).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on February 06, 2018, 10:28:37 am
Came home to 13 ?C in the bathroom today..  :o :)

Same issue as Resq93, easily solved by updating to 1.2.1. :) The happened to 3 of 4 instances, the last one is a powered MS6.. All the battery ones died.

Big 'attaboy to Rigpapa for excellent support! :D
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: opel-oleg on February 07, 2018, 01:48:13 pm
Hi,
There is a problem of reading the temperature from the modules netato. Modules can see, but the temperature can only be taken from the central one.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 07, 2018, 02:59:25 pm
Sorry, I need some clarification. Are you able to select a module as a temperature sensor in AVT's settings, or do the modules not even show up?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: opel-oleg on February 07, 2018, 03:11:59 pm
I can choose. The thermostat sees them. But the testimony takes only from the main.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 07, 2018, 03:23:56 pm
Cool. OK. And have you either set MinBatteryLevel to 0 or applied the hotfix release 1.2.1? If no to either, go the first message in this thread and follow the instructions there under Troubleshooting to do that, and then test again.

If yes, or the problem persists after MinBatteryLevel or hotfix, then please run the status URL documented in the Troubleshooting section of the head post in this thread and PM or email me the output (both are available on my profile).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: opel-oleg on February 07, 2018, 04:46:42 pm
set MinBatteryLevel to 0
Yes! It was done! Thank you!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 14, 2018, 09:08:17 am
I am having some trouble where the AVT goes offline with the error that it hasn't seen the temp device is awhile, however i do confirm that its polling correctly at present yet the AVT is not coming back on line.
M
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 14, 2018, 04:45:26 pm
Can you send me that actual message from the log?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on February 15, 2018, 10:37:58 am
Will have to try next time. What lines am i looking for?

M
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 15, 2018, 07:03:09 pm
If you look through your log file specifically for the word "ineligible", you will find messages that will tell us more about what it thinks. I'm guessing I know, but I want to be sure.

Fast way to get your log is this URL: http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on February 19, 2018, 01:53:50 am
You can USB and all that, but I think using the built-in CGI log reader is the most straightforward:

http://vera_ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

Notice we don't use the 3840 port number in this URL... it's just straight HTTP to the Vera. This will display the log. You can copy-pasta from there.

EDIT: By the way, on temps not updating, I've already found a UI7 bug and reported to Vera, and they've committed to fix in 1.7.26. I found another bug yesterday working on a separate plug-in where UI also doesn't update when dependent state variables change. Sigh...

Rigpapa, can you give me some more info on this bug? I just had a ticket with support on temp sensors not updating, and they couldn't find anything wrong?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 19, 2018, 07:13:01 am
Those were just UI bugs in the handling of the setpoint controls and their (temperature) display.

But there is a known bug in AVT right now related to battery-operated sensor (from Vera's perspective) sensor handling. As I mentioned in an earlier post here, the flag for a *possible* occurrence of the bug is seeing the word "ineligible" in the logs related to the sensor AVT is attempting to use. The bug causes AVT to be overly strict and reject the sensor, which puts the red warning triangle up over AVT's icon if that's the only sensor. If you think you are seeing that bug, you can try setting MaxSensorBattery to 0 and seeing if your AVT stabilizes. If not, it's something else, and I want to take a closer look, but I'll need logs.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on February 19, 2018, 07:27:23 am
Ok, no, ethis seems to be a problem outside AVT.. AVT reports dead sensor, and rightly so.. some of the sensors flatline for 8-10 hours at a time, and this behaviour started with the infamous firmware updates after .3015 i think.. I think i'll revert to that one to see if it helps.. Thanks!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on February 24, 2018, 04:47:55 am
I finally got around to doing some good testing on AVT and I am having some issues and need some clarification.

Overall I like the changes from SVT and I think it may be beneficial to no longer have the co-efficient calculations on the temperature, but rather straight forward set points that just turn on the heater(s) when low temp is reached. The downsides are that I could not really get it to work correctly as it did not turn on my heaters all the time (see below).

First some interface issues:


Then my test findings:


My testing "Room" still contains the SVT, but it is turned off, so I assume it should not interfere with AVT.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 24, 2018, 09:38:57 am
1. What is the difference between the green and red icon ?

The red icon indicates heating, the green "auto" (idle), and the blue cooling.

Quote
2.Changing the set temperature in the dashboard takes too long as it has to reload between clicks. It can take quite some time to move it by a couple of degrees. This works differently in SVT.

I don't know why that control takes so long to respond. I will send a note to Vera, but it's a UI7 thing, not something I have any control over. The good news, however, is that you can click directly on the temperature and just type in the setpoint you want.

Quote
3. I always forget which temp is what. i.e. what is left and what is right. Can you distinguish between them ? Perhaps just text above ?

It's low on the left, high on the right. So the low on the left is the heating setpoint, the minimum temp the thermostat will allow before acting. The high on the right is the cooling setpoint: the max the thermostat will allow before activating cooling. The heating must be lower than the cooling, and the thermostat enforces this. Note, however, that there are update problems with the UI7 control, and these have been reported to Vera. I would love it if UI7 had style capability for controls. I'm going to ask amg0 about this for ALTUI (it may already exist there).

Quote
Then my test findings:

1. If I want to use 2 heaters you recommend to use the Fan for the 2nd heater. In the Variables there are settings called FanOffDelayHeating and FanCycleMinsPerHr. Will these settings have an impact if I run a second heater in the fan slot ? how would I set these if I wanted the 2 heaters to run in parallel ?

If you are going to use the Fan slot for the second heater, you need to set FanOnDelayHeating and FanOffDelayHeating to 0. The fan has start and stop delays associated with its default behavior. Setting these variables to 0 stops those delays.

The FanCycleMinsPerHr only applies when the fan mode is set to PeriodicOn. In that case, this variable set the number of minutes out of every hour that the fan will be run. It does not apply in your use case, as long as you leave the fan mode in Auto (which you should if using a heater on the Fan slot).

Quote
2. When heating, the "Fan" will turn on first and then the main heater about 15 seconds later. Is that by design ?

Yes, that is the effect of the two fan delays described above. Set them both to 0 and this will stop happening.

Quote
3. If I set the temp at 17.5?c the thermostat will turn on the heaters as mentioned above, and the Thermostat will say "heating". A few minutes later the heaters will turn off, but the thermostat will still say heating. I have to set it to off and then Auto for it to heat again for a few minutes (1-2) but then turn off again without reaching the set temperature.

I would need to see either logs or a status dump, maybe both. You can get a status dump by requesting the following URL: http://your-vera-ip/port_3480/data_request?id=lr_AutoVirtualThermostat&action=status

Please send them to me via PM or email (on my profile). Edit: But wait! See below first, before we both go to a bunch of work...

Quote
My testing "Room" still contains the SVT, but it is turned off, so I assume it should not interfere with AVT.

Well, that could be the problem above. SVT has a periodic timer task and watches on configured devices that run in all modes and update its status. When "off", that code explicitly turns off its configured heaters. You should either remove the SVT device, or remove the heater devices from its configuration, and then do a Luup reload and retest. Not saying you haven't found a bug, but this is highly suspect.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on February 25, 2018, 05:14:52 pm
Quote
I don't know why that control takes so long to respond. I will send a note to Vera, but it's a UI7 thing, not something I have any control over. The good news, however, is that you can click directly on the temperature and just type in the setpoint you want.

I didn?t know that. That is nice when doing large changes. I do however sometimes change temp by a few degrees so any fix to that functionality would also be good.

Quote
It's low on the left, high on the right. So the low on the left is the heating setpoint, the minimum temp the thermostat will allow before acting. The high on the right is the cooling setpoint: the max the thermostat will allow before activating cooling. The heating must be lower than the cooling, and the thermostat enforces this. Note, however, that there are update problems with the UI7 control, and these have been reported to Vera. I would love it if UI7 had style capability for controls. I'm going to ask amg0 about this for ALTUI (it may already exist there).

As I don?t use the cooling, until now I have set both to the same temp. Does that matter with regards to how it works ?


Quote
If you are going to use the Fan slot for the second heater, you need to set FanOnDelayHeating and FanOffDelayHeating to 0. The fan has start and stop delays associated with its default behavior. Setting these variables to 0 stops those delays.

The FanCycleMinsPerHr only applies when the fan mode is set to PeriodicOn. In that case, this variable set the number of minutes out of every hour that the fan will be run. It does not apply in your use case, as long as you leave the fan mode in Auto (which you should if using a heater on the Fan slot).

This seems to work well to start the fan (2nd heater) when temp changes, but when I move the slider from Comfort to Eco the "fan" stays on, of course it makes sense since the Eco is lower than the Comfort and if you would have a fan it should help cool the room, but when it is used for a second heater this behavior is not ideal since it will continue to heat and not cool..

Quote
Yes, that is the effect of the two fan delays described above. Set them both to 0 and this will stop happening.

Yes, that works fine.

Quote
I would need to see either logs or a status dump, maybe both. You can get a status dump by requesting the following URL: http://your-vera-ip/port_3480/data_request?id=lr_AutoVirtualThermostat&action=status

Please send them to me via PM or email (on my profile). Edit: But wait! See below first, before we both go to a bunch of work...

Quote
Well, that could be the problem above. SVT has a periodic timer task and watches on configured devices that run in all modes and update its status. When "off", that code explicitly turns off its configured heaters. You should either remove the SVT device, or remove the heater devices from its configuration, and then do a Luup reload and retest. Not saying you haven't found a bug, but this is highly suspect.

I think you are right with your hunch. Once I removed the devices from SVT the AVT seems to work fine, so it seems like a conflict even though SVT is off.

I also tested the AVT in Imperihome and it does indeed work well internally (as I only set that) and shows the same interface as SVT but externally it won?t work as I haven?t filled in the URL. Is there a way to connect externally to AVT so that it can be added in Imperihome ?

If the Fan issue and the Imperihome external "issues" can be fixed I think AVT will be a great replacement for SVT. The main problem today with SVT is the fact that it seems to require a periodic LUUP reload or otherwise it will hang on temp measurement on some of my Rooms. Only time will tell if AVT is as sensitive, but SVT is of course a very old plugin that may not have the newer connections to UI7 that AVT has so I would assume it would work better.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 25, 2018, 10:08:32 pm
I think you are right with your hunch. Once I removed the devices from SVT the AVT seems to work fine, so it seems like a conflict even though SVT is off.

I also tested the AVT in Imperihome and it does indeed work well internally (as I only set that) and shows the same interface as SVT but externally it won?t work as I haven?t filled in the URL. Is there a way to connect externally to AVT so that it can be added in Imperihome ?

If the Fan issue and the Imperihome external "issues" can be fixed I think AVT will be a great replacement for SVT. The main problem today with SVT is the fact that it seems to require a periodic LUUP reload or otherwise it will hang on temp measurement on some of my Rooms. Only time will tell if AVT is as sensitive, but SVT is of course a very old plugin that may not have the newer connections to UI7 that AVT has so I would assume it would work better.

Fan issue? Did my instructions not work?

External Imperihome in this form is unlikely. As it is, ImperiHome support is a bit of a kludge, meant to get everyone's local dashboards working. Remote access for Vera is a whole big can of worms that goes far beyond simply providing a remote URL to ImperiHome. I'm still looking into what can be done long term.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on February 26, 2018, 08:20:46 am

Quote
Fan issue? Did my instructions not work?

I added this my previous quote heavy reply, must have gotten lost: when I move the slider from Comfort to Eco the "fan" stays on, of course it makes sense since the Eco is lower than the Comfort and if you would have a fan it should help cool the room, but when it is used for a second heater this behavior is not ideal since it will continue to heat and not cool.

i.e. moving the slider to Eco will produce the expected results (heater(s) turning off).

Quote
External Imperihome in this form is unlikely.

I use Imperihome almost exclusively outside of the location, so that is a dissapointment, but I assume I could work around it. I hope you are able to add this at a later date.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 26, 2018, 09:05:32 pm
I added this my previous quote heavy reply, must have gotten lost: when I move the slider from Comfort to Eco the "fan" stays on, of course it makes sense since the Eco is lower than the Comfort and if you would have a fan it should help cool the room, but when it is used for a second heater this behavior is not ideal since it will continue to heat and not cool.

Hmmm. It's working properly in all three of my test configurations. Can you request the following URL in your browser, and PM or email (on my profile) me the output:

http://your-vera-ip/port_3480/data_request?id=AutoVirtualThermostat&action=status
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: crazymags on February 26, 2018, 09:44:30 pm
It looks promising but I guess there's more to improve. I just hope that it will work fine.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on February 27, 2018, 08:34:42 am
I was going to record a video of this "problem" but now it seems to work fine. I can only assume that a possible LUUP restart or otherwise leaving it alone "cured" the issue. If I had to guess it may be because of the change from the SVT to AVT.

This is of course really good news. I assume I can work around the inability to use the thermostat in Imperihome outside of the network.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: resq93 on March 29, 2018, 10:48:52 am
If you look through your log file specifically for the word "ineligible", you will find messages that will tell us more about what it thinks. I'm guessing I know, but I want to be sure.

Fast way to get your log is this URL: http://your-vera-ip/cgi-bin/cmh/log.sh?Device=LuaUPnP

50   03/29/18 10:42:55.105   luup_log:352: AutoVirtualThermostat: Sensor "354" ({ mac="", category_num=5, description="Office Thermostat", user="", id="88", pass="", ip="", room_num=22, udn="uuid:4d494342-5342-5645-0162-000002fb2aa7", subcategory_num=1, invisible=false, hidden=false, embedded=false, device_num_parent=1, device_type="urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1" }) ineligible, comm failure status 1 <0x6d447520>
50   03/29/18 10:42:55.116   luup_log:352: AutoVirtualThermostat: No valid sensors. <0x6d447520>

The thermostat is definitely back online - but takes a while AVT to come back online
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on April 18, 2018, 05:18:43 pm
So I have been using AVT now instead of SVT in one of my rooms in my summerhouse, but in that room I have 2 heaters. The second heater is set on the Fan as suggested.

When I am not in the summerhouse I set the thermostat to Eco and on 11 degrees celsius. When I am preparing to go to the summerhouse I change it to Comfort, which is set to 15 degrees celsius and then, theoretically, it should turn on the heaters to reach that temperature. But now I arrived in the summerhouse and the second heater was on full blast and the AVT was set to Cooling. My theory here is that when I changed the AVT to Comfort, the heat was already over 15 degrees and therefore it started the "Fan" to cool the room and then instead it started heating. The temperature was up to 24 degrees when I arrived.

Unfortunately I did not have this logged in Datamine due to some other changes so I can?t really back up my claims, but if beneficial I could potentially test this out as I will be staying here for another 3 days.

Could we have a better way of adding a second heater instead of to the Fan ?

Also I am interested in if you are planning any development with regards to getting the temperature display in Imperihome outside of the internal network ?

I do realize that you are most likely busy with a lot of other development and the rewards for your work on AVT may not be that great. I would be willing to donate towards further development, but I need to be able to trust it to work as expected and be visible in Imperihome. I also realize that only one donor will probably not make a lot of difference either..

Are you still looking at developing this further ?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on April 19, 2018, 07:11:52 am
Short reply while traveling. You must not use Auto or Cool modes in your configuration. You should be set to heat only.

Edit: spelling
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: kulfsson on April 19, 2018, 05:29:27 pm
Of course ! That makes perfect sense.. I think I am comparing it to much to SVT as the Auto mode there is different. Thanks for the travelling reply :-)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on June 18, 2018, 02:08:22 am
Nice-to-have Feature request:
Could one have multiple stage heating? I have two ovens in one room, and it might be neccesary to use both if the outside temperature is low(winter), and only one if its warmer (summer nights)..

Just a cool add-on, the AVT works fine as it is, so thanks for that! :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on June 18, 2018, 09:56:21 am
I've considered this and I think it's a great idea. This is the type of change that would actually make PID useful, and smarts for tuning, but there are many options for control, and supporting a couple of the most popular seems a good direction. Do you have any ideas or wishes for control heuristics in a multi-stage configuration?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on June 19, 2018, 01:35:45 am
I'm not that versed in the options really, its been a long time since i played with PID's. :)

The simple way is probably to have an outside temp setpoint (value in variables), where the AVT applies both ovens in the heat cycle if the outside temp is below this point. This option may be used in a mode where you don't use a "learning" thermostat, which (in my experience with SVT) can get confused by some external factors changing (open doors, etc).

The coolest way may be a proper regulator watching the flanks on the temperature decrease/increase, and apply ovens accordingly? This one could probably be both fun and frustrating to implement. ;)

Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 16, 2018, 03:06:39 am
Is there any plans for releasing this for AltUI? I have an openluup system running without Vera, and would like one of these. :)
I see that the thermostat shows up fine in AltUI on my Vera, so it should be just to release it in AltAppStore? Looks like it from here, i'm sure its more complicated..:D
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 21, 2018, 08:59:59 pm
In the past, openLuup has not set luup.device in the watch and delay callbacks, which AVT likes to have. I'll check the latest version. There are workarounds, as well. So, maybe.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 24, 2018, 09:13:27 pm
Quote from: rigpapa
Is there any plans for releasing this for AltUI? I have an openluup system running without Vera, and would like one of these. :)
I see that the thermostat shows up fine in AltUI on my Vera, so it should be just to release it in AltAppStore? Looks like it from here, i'm sure its more complicated..:D

In the past, openLuup has not set luup.device in the watch and delay callbacks, which AVT likes to have. I'll check the latest version. There are workarounds, as well. So, maybe.

OK. So the short answer is now yes, it's in the AltAppStore with a single "beta" version (from the Github stable branch). It has not been fully tested, but I expect it to work, and will be pleased to address any problems if not. If you're interested in an openLuup version of AVT, please help me out by installing it from the AltAppStore and bashing on it.

Background, in case this helps anyone in future (and yes, I'm simplifying a few points here): there's a key difference between Vera Luup and openLuup that was standing in the way as implemented. Vera Luup loads each module loaded by a plugin's implementation in per-device context, so if you have three or four AVTs on your Vera, you have four separate copies in memory of its implementation and each of the modules required by the implementation. In contrast, openLuup behaves in a more "Lua-natural" way (IMO) and loads a module only once, so all uses of that module by the three or four AVT devices would share the single copy of the module. The effect of this difference is that certain elements of context on openLuup, such as luup.device, are available in the implementation per device, but not the loaded modules (they can't be, it's shared context between multiple devices). For AVT in particular, this meant that the watch callbacks being used to monitor temperature sensors and other devices could not discern which of the three or four AVT instances the callback was intended for (Vera neglected to define their callback functions to receive the handling plugin device; luup.device is the remedy for this, but it's not great style and should have been passed). The workaround was relatively simple once I reassured myself I could get enough context somewhere: rather than having the watch call the module function directly, I have it call a pass-through function in the <functions> section of the implementation file, which simply calls the module's function (hence, pass-through), but also passes luup.device as an additional argument to the module's handler (which is in context and available in the implementation file functions on both Vera and openLuup).

By the way, this difference in module loading probably explains in large part why plugins are so memory-hungry on Vera. It could have all been avoided had they simply added one received argument for each of the callbacks.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 26, 2018, 01:11:12 pm
Awesome! Currently i have no remote login to that system, but i will definately add it when i get back there. I'll let you know how it works. :)

Thanks!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 26, 2018, 01:43:59 pm
Awesome! Currently i have no remote login to that system, but i will definately add it when i get back there. I'll let you know how it works. :)

Thanks!

..Forgot the laptop i set up in the same network with remote login..  ::)

I Installed it now, and according to LuaUPnP.log there is no error messages.
I did however not get the control panel and settings tab up when i enter the thermostat device, and the icon is also missing.
I entered the sensor and oven, and i set ModeTarget to HeatOn, still no errors as i can see, but ModeStatus stays "Off".
I also tried to change EnergyModeTarget to "EnergySavingsMode", but status is unchanged.

Any logs or stuff you need, let me know.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 26, 2018, 02:12:00 pm
Did you do a full cache flush on the browser?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 26, 2018, 06:36:43 pm
I did now.

Now the temperature and "Idle" is shown on the device in the list, but the control panel tabs and icon is still gone.
ModeStatus is "InDeadBand" which is correct, so its running, but EnergyModeStatus is "Normal" while EnergyModeTarget is "EnergySavingsMode"..
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 26, 2018, 08:58:21 pm
I did now.

Now the temperature and "Idle" is shown on the device in the list, but the control panel tabs and icon is still gone.
ModeStatus is "InDeadBand" which is correct, so its running, but EnergyModeStatus is "Normal" while EnergyModeTarget is "EnergySavingsMode"..

All working good for me, of course.  :) Actually, it was working fine on ALTUI 2.26 and the current development branch of openLuup. But to be sure I updated to the more current 2.29.2418 ALTUI and I saw brokenness like you're describing. Weird. It looks like it's not loading/using the ALTUI-specific JavaScript for the dashboard card. That JS hasn't changed in a while (and worked in prior versions of ALTUI), but I ran it through jshint anyway just to be sure, and it came up clean (enough). The only thing I noticed that looked different is that strict mode wasn't being used--it's commented out. I generally turn that on for ALTUI (but off for UI7, which chokes on it). So I uncommented the strict mode literal, refreshed, and behold! the dashboard card came up normal again.

So just try that on your side. In the file J_AutoVirtualThermostat1_ALTUI.js, the second line of the file should currently read:
Code: [Select]
// "use strict";Just remove the slashes and any leading whitespace to uncomment that line, then reload.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 27, 2018, 05:53:10 pm
Ok, so i did that, reloaded luup in Altui, cleared all browser stuff, and reentered the AltUI website. Still no control panel.

Heres how the J_..._AltUI.js looks.

OpenLuup version: 2018.03.23
AltUI Version: 2.29.2418
Running on Beaglebone xM using Debian 9.3
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 27, 2018, 06:29:54 pm
It's working fine on my openLuup/ALTUI installation at this point (my openLuup is newer). Post screen shots of what it does show in the dashboard and settings, so we can all be sure we're on the same page with the problem we're trying to fix. You might also open the Developer console on your browser (e.g. F12 in Chrome and Firefox) and see if the console is logging anything that may be useful.  If that doesn't give us an "ah hah" moment, we'll probably need to page @amg0 for an assist in debugging this on your installation.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 28, 2018, 05:53:01 am
Will this screenshot suffice?

I did an apt-get upgrade, and tried to update openluup as well, but it seems like 18.3.23 is the latest it will update to?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 28, 2018, 08:49:30 am
Well, that helps! Looks like you misspelled the device file name when creating the device. I think you can just go into the Attributes tab and correct it (capitalize the V and double-check the rest of it and the implementation file name). Then reload openLuup.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 28, 2018, 02:51:55 pm
That Worked. Thanks. :)

I don't mind taking the blame here, but i'm pretty sure this is device was auto generated when I installed the plugin?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on July 28, 2018, 03:03:38 pm
Yup, you're right. Good on you for commenting, or I wouldn't have looked until it happened to the next victim person. It was indeed my typo in the AltAppStore config. Now fixed, and thank you!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on July 29, 2018, 06:57:03 am
Hehe.
In any case i now have a functioning thermostat on my OpenLuup system, so thankyou for all your contributions!
I also use Reactor to control how many ovens get turned on based on outside temperature, so double kudos to you!  :D
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on August 13, 2018, 01:46:26 pm
I've gotten a couple of emails from people reporting small UI issues with AVT on newer versions of firmware, specifically 7.0.26 and .27.

1) The temperature setpoint UI buttons are oversized. This issue cropped up between 7.0.23 and 7.0.26 at some point, and is the result of a CSS change Vera made to the UI. It is out of my hands, and as far as I can tell, there is nothing I can do in static JSON to work around it. It manifests both in on the dashboard cards and control panel views. If you hover over the oversized icon, the hover icon that replaces it is correctly sized. I have reported this to Vera, and unless they tell me otherwise, it's their issue and I'm not going to try to do anything about it in AVT. We'll just have to live with it until they fix it (I also reported it for 7.0.26 and they didn't fix it for 7.0.27 or give me any other advice about it, so who knows if/when they'll get around to it).

2) The control panel isn't showing all the buttons. Firmware 7.0.27 UI changes the way a particular variable is handled that changes behavior on the UI, specifically what is displayed on the control panel. This results in AVT on 7.0.27 not displaying all of its fields on its control panel. To fix this issue, request the following URL in your browser, applying your Vera's local IP address and AVT device number where indicated. You need to do this for each AVT device you have. Please do a hard-refresh of your browser after. A Luup reload should not be necessary.

http://your-vera-local-ip/port_3480/data_request?id=variableset&DeviceNum=device-number&Value=&serviceId=urn:micasaverde-com:serviceId:HaDevice1&Variable=Commands
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Sammy2 on August 14, 2018, 04:34:05 pm
I just became aware of this 7 pages later but does it work with 2 Gig CT 100 thermostats and external temperature and humidity sensors?

Thanks.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on August 14, 2018, 05:28:46 pm
I just became aware of this 7 pages later but does it work with 2 Gig CT 100 thermostats and external temperature and humidity sensors?

Hmmm. AVT implements the features of a thermostat. I'm not getting why you would want to do that, if you already have a thermostat... If you mean can it be made to make your CT 100's operate from external sensors, I think no, that's not really its intended function.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: zedrally on August 14, 2018, 08:24:39 pm
Can this PI work in conjunction with a Ventstar T7850/T7900 Thermostat or is another PI needed?

Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on August 14, 2018, 08:53:34 pm
Can this PI work in conjunction with a Ventstar T7850/T7900 Thermostat or is another PI needed?

I would really need to know more about what you are trying to do.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Sammy2 on August 15, 2018, 04:14:27 pm
I just became aware of this 7 pages later but does it work with 2 Gig CT 100 thermostats and external temperature and humidity sensors?

Hmmm. AVT implements the features of a thermostat. I'm not getting why you would want to do that, if you already have a thermostat... If you mean can it be made to make your CT 100's operate from external sensors, I think no, that's not really its intended function.

Okay so maybe your Reactor Plugin is more in line with what I need? I want to have the CT-100's react to temperature and humidity levels inside the house but on a conditional basis of current House Mode(s). I did work with PLEG some on this but ran out of time to fully implement due to the demands of many projects I am working on.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on August 15, 2018, 04:18:26 pm
Okay so maybe your Reactor Plugin is more in line with what I need? I want to have the CT-100's react to temperature and humidity levels inside the house but on a conditional basis of current House Mode(s). I did work with PLEG some on this but ran out of time to fully implement due to the demands of many projects I am working on.

That's possible. Can you tell me a bit about what you're trying to accomplish? Demands... demands? You mean you have other things to do than just work on your Vera?  ;)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Sammy2 on August 15, 2018, 04:30:01 pm
Okay so maybe your Reactor Plugin is more in line with what I need? I want to have the CT-100's react to temperature and humidity levels inside the house but on a conditional basis of current House Mode(s). I did work with PLEG some on this but ran out of time to fully implement due to the demands of many projects I am working on.

That's possible. Can you tell me a bit about what you're trying to accomplish? Demands... demands? You mean you have other things to do than just work on your Vera?  ;)

Let's see


My wife says I need to let some of this go but when you have the bug there's nothing to do but do it. It is my hobby.

As far as the thermostats go, I'd like to have it come on not just on a schedule but say if the temperature or humidity hits a preset value in our Master Bedroom for example, maybe even incorporating ceiling fans at some temperature set point before the one where he AC comes on.

I suppose I should uninstall AutoThermostat and move this discussion over to the Reactor Thread?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Sammy2 on August 15, 2018, 04:42:26 pm
Okay so maybe your Reactor Plugin is more in line with what I need? I want to have the CT-100's react to temperature and humidity levels inside the house but on a conditional basis of current House Mode(s). I did work with PLEG some on this but ran out of time to fully implement due to the demands of many projects I am working on.

That's possible. Can you tell me a bit about what you're trying to accomplish? Demands... demands? You mean you have other things to do than just work on your Vera?  ;)

I sent you a message via your website.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Don Phillips on August 15, 2018, 09:05:43 pm
That is why I bought a condo in 2012 before I got into home automation  ;D
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on August 23, 2018, 05:40:36 pm
Just a comment on controlling thermostats with this thermostat:

I have a ZXT-120 controlling my old and rather simple heat pump (reversable for cooling), and as this heat pump is rather bad at controlling the room temperature I hooked it up to AVT.

I use two virtual switches called "VP Heat" and "VP Cool". These are watched by 4 scenes, "VP Cool On", "VP Cool Off", and same for VP Heat.
The scenes set the heat pump up with a temperature value and a mode (Off, Auto, Heat, Cool).

Using this, I can:
Lower the temperature setpoint at night for power saving (using economy/comfort setting in AVT) - Saves a lot of power in cold Norwegian winters!
Make sure that the cooling function doesn't kick in when I use the fireplace for extra room heating during winter (using a scene condition to control AVT)
Vacation lowering of temperature (using a scene condition to control AVT)
Use other temperature sensors in the room than the one in the heat pump (AVT!)

The ZXT-120 supports a lot of heat pumps/AC's and they will have different functions. Some will probably do most of the above without AVT, but I havent seen the double setpoints for night-lowering on them yet. :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on August 27, 2018, 01:53:58 am
Rigpapa: I noticed that my bathroom thermostat(AVT) said "Heating" without the oven turned on this morning.. Its a Z-wave plug on the oven, an i suspect that it may have had some communication issues..

Is there any check to see that the oven was actually turned on by AVT?

It would be great if it could confirm that status is ON, it seems like 1/30 times this z-wave plug is slow in responding. Mabye I can try to set up another plug in between for relay..
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on August 29, 2018, 08:40:38 am
Rigpapa: I noticed that my bathroom thermostat(AVT) said "Heating" without the oven turned on this morning.. Its a Z-wave plug on the oven, an i suspect that it may have had some communication issues..

Is there any check to see that the oven was actually turned on by AVT?

It would be great if it could confirm that status is ON, it seems like 1/30 times this z-wave plug is slow in responding. Mabye I can try to set up another plug in between for relay..

Sorry for the reply delay. I will look into this. In the context of other things the plugin does, and things that are coming, this becomes a bit... complicated. That's good cause for study to figure out how to make it simple. I agree it would be a useful feature.

EDIT: I've added this as issue #7 on Github, enhancement request.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on September 02, 2018, 03:03:58 pm
Recently i'ts gotten cold enough in Norway to test the AVT i have in the camper. Its running on Openluup, no vera..

For some reason the oven doesn't get the "ON" message? If I manually turn it on, and lowers the set point, AVT succeeds in turning it off..

I didn't have time to extract logs, but i'll see if I can get to it tomorrow. In the meantime the AVT is getting help from reactor, which looks for ModeStatus=HeatOn to engage the oven. :)

Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on September 02, 2018, 03:51:51 pm
Recently i'ts gotten cold enough in Norway to test the AVT i have in the camper. Its running on Openluup, no vera..

For some reason the oven doesn't get the "ON" message? If I manually turn it on, and lowers the set point, AVT succeeds in turning it off..

I didn't have time to extract logs, but i'll see if I can get to it tomorrow. In the meantime the AVT is getting help from reactor, which looks for ModeStatus=HeatOn to engage the oven. :)

LOL. If you could grab a debug log and PM (or email, on my profile) it to me, that would help. You can turn on debug by setting the DebugMode state variable (in service urn:toggledbits-com:serviceId:AutoVirtualThermostat1) to 1, then doing a Luup restart. Try to make the heater come on without help from Reactor, preferably, so I can get a clean view of its work (or not work, as the case may be).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on September 08, 2018, 03:17:22 pm
Mail sent!

New issue, I tried to get the Imperihome up and running. After putting in the link in the 'local' parameter, I get "System found, Unable to connect".

If i run the link in chrome (on a PC) it returns an empty page.. Any ideas?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on September 11, 2018, 08:46:38 am
 On holiday with limited Internet. Check logs after making the request and PM to me. I'll try to look at my next opportunity
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on September 25, 2018, 02:21:01 pm
Mail sent!

New issue, I tried to get the Imperihome up and running. After putting in the link in the 'local' parameter, I get "System found, Unable to connect".

If i run the link in chrome (on a PC) it returns an empty page.. Any ideas?

I got the imperihome integration to work. Not sure if you changed anything, or if it was the change to 5ghz wifi instead of 2.4ghz that did it? Didnt think that would matter, but now it works at least. :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on September 25, 2018, 04:26:06 pm
Mail sent!

New issue, I tried to get the Imperihome up and running. After putting in the link in the 'local' parameter, I get "System found, Unable to connect".

If i run the link in chrome (on a PC) it returns an empty page.. Any ideas?

I got the imperihome integration to work. Not sure if you changed anything, or if it was the change to 5ghz wifi instead of 2.4ghz that did it? Didnt think that would matter, but now it works at least. :)

Nope, no changes. Happy to hear it's working out, if not a bit mysteriously.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: powisquare on December 10, 2018, 09:35:57 am
What is the best way to add a second AVT device in ALTUI please?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: powisquare on December 24, 2018, 07:11:55 am
What is the best way to add a second AVT device in ALTUI please?

+Create device -- use D_AutoVirtualThermostat1.xml and I_AutoVirtualThermostat1.xml
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 17, 2019, 05:27:43 pm
I just set up a Home Assistant controller to  check it out, and to try connecting google home. This worked very well, and i was suprised to see the virtual thermostats going over as well. (well, not the eco/comfort button)

I do however notice that the "current setpoint" passed to HA is the "Cooling Setpoint", not the "current setpoint". Is that something the transfer script is doing, or might it be AVT deciding which one is reported?

I have no idea how the innards work here, just curious. :) I'm considering lightening the load on the Vera by transferring some automation to HA, so this would be cool to get right. :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 17, 2019, 07:01:07 pm
I just set up a Home Assistant controller to  check it out, and to try connecting google home. This worked very well, and i was suprised to see the virtual thermostats going over as well. (well, not the eco/comfort button)

I do however notice that the "current setpoint" passed to HA is the "Cooling Setpoint", not the "current setpoint". Is that something the transfer script is doing, or might it be AVT deciding which one is reported?

I have no idea how the innards work here, just curious. :) I'm considering lightening the load on the Vera by transferring some automation to HA, so this would be cool to get right. :)

Thermostats are, IMO, something Vera didn't think through very well, made some mistakes, and it seems painted themselves into a corner that they're now a bit stuck with. Short version: between Vera/Luup and pyvera, it's broken for all thermostats and not likely to be fixed in the near future. I've been party to some discussions about this on the pyvera side, but I'm not engaging the problem with code at this point because I feel it's part of bigger architectural problem in pyvera, and that makes me shy away from choosing HA as anything much more than a casual UI in a Vera environment. If you want some details with a healthy dose of opinion and sarcasm, you can read on. Otherwise, sum it up this way: both ends of that connection are at fault.

The gory details:

On the Vera side, the TemperatureSetpoint1 service (a UPnP standard service) supports both cooling and heating setpoints, but does so in a two step process. It is first necessary to do a SetApplication action to tell the service what mode to be in ("Heating" or "Cooling"). The SetCurrentSetpoint action then sets the setpoint for that mode. The CurrentSetpoint state variable returns the setpoint of the current mode, whatever it may be, and it changes when you change the Application.

I guess Vera couldn't figure out how to make a two-step process like this work in UIx when a thermostat has both heating and cooling setpoints (the static JSON can pass multiple parameters, but it can't do a multi-action action like this, although it would not have been hard to implement). So they kludged the TemperatureSetpoint1 service into two aliased services called TemperatureSetpoint1_Heat and TemperatureSetpoint1_Cool. Which setpoint gets set is determined by which service you use when doing a SetCurrentSetpoint action.

The problem they create for themselves by doing this is they are not two separate service definitions, they are just two aliases that point to the same service definition (S_TemperatureSetpoint1.xml). The service definition sets the "shortcode" for various state variables, and in this service definition, the CurrentSetpoint state variable receives the shortcode "setpoint". The problem, though, is that while state variables are separated by service Id, shortcodes are not--the shortcode must be unique per device, so you can't set "setpoint" twice in the structure (HA uses lu_sdata) for the same device. But it's trying, because of the way Vera is going it, but the result is what whichever service sets shortcode in the structure second wins. So it's only possible for HA to get ONE of the two setpoints out of sdata, and that's probably why you're getting the cooling value (it could have just as randomly/likely been heating, I suppose).

Apparently Vera worked around this problem by... adding ANOTHER STATE VARIABLE! They added the AllSetpoints state variable to the TemperatureSensor1 service, which contains ALL THREE setpoints (yes, three): heating, cooling, and auto. Without diving into why that seems wrong, they made a more egregious mis-step #3: they didn't modify the service definition to include this new variable--it's undeclared. They just set the variable using the service (Luup allows this freely). And because they didn't declare it in the service, there is no shortcode for it, and it doesn't appear in sdata where HA or anything else that uses sdata could grab it.

Thermostats are a soup sandwich, IMO. When you start looking at the UI code to see how they implement the interfaces, it gets even worse. Couple that with a few bugs like a random change to the CSS for the spinner_horizontal controls (used as setpoint buttons in thermostats, and by other plugins for other types as well, which is why the buttons are currently appearance-broken as of 7.0.23 or so), and it's a frustrating hot mess.

Unfortunately, for HA it means that the underlying subsystem, pyvera, is going to need some wool-pulling. And this gets to where pyvera has what I think is a big problem: the subscription service in pyvera relies entirely on sdata, so the majority of devices see only the data exposed by sdata (shortcodes), and not the full state of the device (which it could get from a status request). Pyvera does use status requests, but not as the subscription notice object target, and apparently HA in turn uses those "lesser" objects almost entirely, so HA probably doesn't even really know what it's missing. Of late, the door lock object in pyvera has been modified to address some of its shortcomings that could not be addressed by sdata alone, and there are rumblings around thermostats as I write this. But IMO, the problem extends to every object and should be approached as a subsystem-wide problem, not a per-object problem, and pyvera needs a big redo to use status requests rather than sdata, so it has a more complete picture of the device state to use in building more comprehensive and correct data representations of the Vera objects. The consequence of that may be breaking for pyvera's clients, including HA, and from what I've seen, HA freely publishes breaking changes for its users, but takes a dim view of its dependent subsystems doing the same thing to it.

So, I view pyvera as a minimalist interface in HA's use, and likely will be for a very long time. For this reason, I don't view Vera+HA as anything more than a better, more convenient UI for the stuff that works, and I ignore the rest. There was a time I moved a lot of my automations there, but I'm now moving them back. Knowing what I now know, I don't see the Vera+HA combination as a serious long-term strategy.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 18, 2019, 03:17:54 am
Seems like there is some points here for both pyvera and ezlo gang to look into. I totally get your frustration here when there is seemingly obvious better ways to do stuff, and they just decided not to.  ::)

Very interesting to read about the Vera/HA issues, I mainly wanted the HA to get the interfaces vera is missing (Home, Xiaomi, Wifi switches, etc.. ), on the automation side Vera is far simpler to set up thanks to your apps (Delaylight, Reactor and AVT).. HA doesnt seem to have any equivalents with a GUI at all..

Going off the AVT topic here, so i'll stop with the conclusion that this is not AVTs fault. :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: Forzaalfa on January 25, 2019, 01:57:22 pm
You're probably mostly busy with Reactor stuff, but if you feel like looking at having multiple stages on heating that would be lovely! :)
This may not be an issue where you live, but in norway we need more ovens when winter sets in hard..;)
Mabye something could look at the heat progression and - say - turn on one more oven if the temperature hasn't risen after 10 minutes? or mabye control it by looking at outside temperature value/difference?

I'm currently using reactor to turn on more ovens if the outside temp is below a certain level, it works fine.. Mabye some way to look at reaction progression over time is something to integrate in reactor?

Just throwing out some ideas.. :)
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on January 25, 2019, 04:33:48 pm
Reactor is settling down, and I'm just getting off a PID project in another world I work in. Stay tuned.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 04, 2019, 10:16:41 pm
I am reading the documentation for this plugin with great interest as it is doing a portion of what I am looking to do. I am thinking about adding a few things to it: control of HVAC vents like the econet zwave vents and the keen zigbee vents, a ventilation only mode (to equilibrate temperature between two floors of a house) and a motion sensor to determine which temperature sensors to take into consideration for the ambient temperature calculation. I was thinking about doing this all through scenes but maybe AVT could be a good base for it...
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 05, 2019, 10:35:57 am
I will think about this as I travel and touch base with you next week.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 06, 2019, 02:58:50 am
Sounds good! No rush... I am also travelling this week.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 11, 2019, 12:03:41 pm
@rigpapa, if you are back, this is the logic I am proposing in an excel file for a thermostat plugin enhancement.
I could pretty much do all of it through scene lua codes but I think a plugin would benefit the community and would be scalable. I am also sure you would write it much better than I would.



Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 12, 2019, 03:02:43 pm
@rigpapa: Any feedback, question, suggestions?

Is this of interest to you to implement as part of AVT? If not I think I will just write some custom device/code and scenes to make it work for my specific setup but I was hoping this could be shared with others.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 12, 2019, 03:14:58 pm
Sorry, I've had a busy few days since getting back from a trip, and I want to give this its proper due diligence before I respond. It seems pretty specialized, but sit tight, I want to make sure I've read it completely and understood it.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 12, 2019, 03:28:47 pm
Thank you for looking into it. It can indeed look pretty involved. What I am trying to get to is to reproduce a combination of what the ecobee thermostat and the keen vent hub do all into one system.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 12, 2019, 03:50:37 pm
By the way, what are "up vents" and "down vents"?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 12, 2019, 04:59:29 pm
Ahh I knew I had some unclear jargon in there.

The idea is for a two story house having a temperature delta issue between the two floors.
The Up vents are the vents for the upper floor. The Down vents are the ones downstairs. This is an optional idea to save energy when some thermostat could just recycle air from up and down the house instead of turning on heat or AC.

By the way the vents are devices which I have implemented with as a window covering but with a custom device.json called D_Vent1.json which I have shared in the Keen vent thread. I have been using the same file for both zigbee and zwave vents.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 13, 2019, 02:16:21 pm
Just so you know I actually started writing the code which could be the basis for a plugin. I am actually almost done. The big task ahead is to be able to setup the device json to input all the different sensors and vents as they are currently hardcoded for my setup. It isn't as difficult as I anticipated.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 13, 2019, 03:17:38 pm
Just so you know I actually started writing the code which could be the basis for a plugin. I am actually almost done. The big task ahead is to be able to setup the device json to input all the different sensors and vents as they are currently hardcoded for my setup. It isn't as difficult as I anticipated.

I think you should continue in this direction. The contents of your spreadsheet points to some very specific configuration for your setup. While I know you can generalize it, even so, it appears to be a bit more than a plugin that advertises itself as a "virtual thermostat" really demands.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 14, 2019, 02:30:19 pm
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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on February 14, 2019, 02:38:43 pm
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.

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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rafale77 on February 15, 2019, 10:27:49 am
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.

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.

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!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 21, 2019, 08:22:38 am
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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 21, 2019, 10:26:47 am
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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 21, 2019, 05:35:25 pm
...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.

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?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 22, 2019, 06:50:19 pm
...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.

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?

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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 22, 2019, 07:10:30 pm
...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.

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?

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.

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 SetCurrentSetpoint action in the urn:upnp-org:serviceId:TemperatureSetpoint1_Heat service with parameter NewCurrentSetpoint.

To set the cooling setpoint, use the SetCurrentSetpoint action in the urn:upnp-org:serviceId:TemperatureSetpoint1_Cool 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).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 23, 2019, 01:53:59 pm
...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.

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?

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.

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 SetCurrentSetpoint action in the urn:upnp-org:serviceId:TemperatureSetpoint1_Heat service with parameter NewCurrentSetpoint.

To set the cooling setpoint, use the SetCurrentSetpoint action in the urn:upnp-org:serviceId:TemperatureSetpoint1_Cool 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).

Perfect, thank you!
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 23, 2019, 04:15:17 pm
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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 23, 2019, 04:23:49 pm
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.

OK. As a first step, can you send me a "Logic Summary" (link on the Tools tab of the ReactorSensor) for both?
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 24, 2019, 02:00:45 am
*************************************************** 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 <grp169a4fd9166> 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] <cond169a4fd9167>
        =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] <cond169a4fddb52>
        =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] <cond169a4feaa49>
        =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] <cond169a6cd4b99>
    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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 24, 2019, 10:33:18 am
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.

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).
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 24, 2019, 07:17:29 pm
*************************************************** 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 <grp169a4fd9166> 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] <cond169a4fd9167>
        =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] <cond169a4fddb52>
        =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] <cond169a4feaa49>
        =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] <cond169a6cd4b99>
    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 <grp169a626d1c2> 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] <cond169a63ab3b9>
        =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] <cond169a626d1c3>
        =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] <cond169a629e10f>
        =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] <cond169a6cdbac8>
    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.

Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 24, 2019, 08:05:01 pm
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.

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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: derekkirsch on March 24, 2019, 09:13:49 pm
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.
Title: Re: Plugin: AutoVirtualThermostat (AVT)
Post by: rigpapa on March 24, 2019, 09:51:12 pm
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.