Author Topic: Plugin: AutoVirtualThermostat (AVT)  (Read 8151 times)

Online rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1046
  • Karma: +167/-1
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #120 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.
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3, Lite. Hassio, Slapdash.

Offline powisquare

  • Full Member
  • ***
  • Posts: 146
  • Karma: +1/-0
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #121 on: December 10, 2018, 09:35:57 am »
What is the best way to add a second AVT device in ALTUI please?

Offline powisquare

  • Full Member
  • ***
  • Posts: 146
  • Karma: +1/-0
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #122 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

Offline Forzaalfa

  • Full Member
  • ***
  • Posts: 215
  • Karma: +5/-0
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #123 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. :)
Vera Plus - RFXtrx433e

Online rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1046
  • Karma: +167/-1
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #124 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.
« Last Edit: January 17, 2019, 07:04:51 pm by rigpapa »
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3, Lite. Hassio, Slapdash.

Offline Forzaalfa

  • Full Member
  • ***
  • Posts: 215
  • Karma: +5/-0
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #125 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. :)
Vera Plus - RFXtrx433e

Offline Forzaalfa

  • Full Member
  • ***
  • Posts: 215
  • Karma: +5/-0
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #126 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.. :)
Vera Plus - RFXtrx433e

Online rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1046
  • Karma: +167/-1
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #127 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.
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3, Lite. Hassio, Slapdash.

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1690
  • Karma: +93/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #128 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...
openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Online rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1046
  • Karma: +167/-1
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #129 on: February 05, 2019, 10:35:57 am »
I will think about this as I travel and touch base with you next week.
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3, Lite. Hassio, Slapdash.

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1690
  • Karma: +93/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #130 on: February 06, 2019, 02:58:50 am »
Sounds good! No rush... I am also travelling this week.
openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1690
  • Karma: +93/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #131 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.



openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1690
  • Karma: +93/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #132 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.
openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Online rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1046
  • Karma: +167/-1
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #133 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.
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3, Lite. Hassio, Slapdash.

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1690
  • Karma: +93/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: Plugin: AutoVirtualThermostat (AVT)
« Reply #134 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.
openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.