[quote=“Forzaalfa, post:124, topic:198289”]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. :)[/quote]
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.
