Plugin: AutoVirtualThermostat (AVT)

Plugins & Plugin Development General Plugin Discussion
#1

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. The GitHub repository is here.

[hr]
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:

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

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.

[hr]
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 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:

[ul][li]ImperiHome ISS API support, making it possible to see AVT devices in ImperiHome;[/li]
[li]Full UI and Comfort/Economy switching on ALTUI (both fixes and enhancements in this area; thanks to amg0 for his support);[/li]
[li]Uses newer spinner_horizontal controls for setpoints in UI7, which work better and more consistently, and allow the setpoint to be edited directly by clicking on it and simply entering a new setpoint value;[/li]
[li]Tightens checks around battery-operated thermostats and allows the user to set the minimum acceptable battery level to be considered valid (state variable MinBatteryLevel)–previously any battery level was considered valid if the battery report was recent, but some devices are known to “drift” in temperature measurement as their batteries near end of life.[/li][/ul]

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).

#2

Good stuff! Keep up the good work. :slight_smile:

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?

#3

Dude, you are just knocking out all my dream plugins for the Vera. Keep up the great work!

#4

@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.

#5

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.

#6

Very good! Let me know if you need help testing it. :relaxed:

#7

No, it’s not good. More to follow.

#8

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.

#9

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…

#10

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.

#11

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.

#12

Great news ! I can?t wait to try out this instead of SVT. I have been waiting for Eco/Comfort before making the move :slight_smile:

#13

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.

#14

I will shoot of an email to the imperihome guys later, refering to this thread.

Thanks! :slight_smile:

#15

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 up to the Github repository “develop” branch. The two implementation files were modified ([tt]I_AutoVirtualThermostat1.xml[/tt] and [tt]L_AutoVirtualThermostat1.lua[/tt]). 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:

[ol][li]In Imperihome, go into My Objects[/li]
[li]Click Add a new object[/li]
[li]Choose ImperiHome Standard System[/li]
[li]In the Local base API field, enter [tt]http://your-vera-ip:3480/data_request?id=lr_AutoVirtualThermostat&command=ISS&path=[/tt][/li]
[li]Click Next to connect, which it should.[/li][/ol]

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.

#16

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.

#17

Whoops! Thanks for catching that. I fixed the link in the original post as well.

#18

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… :-\

#19

…and i had to delete AVT completely to get them back… ?

#20

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.