Variable set via scene (luup) reverts back after a while.

Developer's Corner Scene Scripting
#1

I want to set thermostat (Qubino ON/OFF, ZMNHID1) mode to Heat (“HeatOn”) from the scene.

Unfortuntaely, after sending variable set command:

luup.variable_set ("urn:upnp-org:serviceId:HVAC_UserOperatingMode1", "ModeStatus", "HeatOn", 77)

The mode is set for a while, then thermostat reverts back to “Off”.

This thermostat has some improper configuration in the system (it shows only “Off” and “Auto” modes in Vera interface, however it works only if set to “Heat” which is possible via party apps like Imperihome). If I set “Auto” via Vera interface, it also gets back to “Off” after couple of minutes.

But if I use 3-rd party app to set mode as “Heat”, everything works properly and setting is kept.

I was hoping that I can steer it via the scene, but seems that it behaves similar as Vera interface. I can’t track the issue - I’ve compared all variables for the device and when I set mode via Imperihome, only “ModeStatus” and “ModeTarget” are changing, every other variable stays as before).

I’ve tried to use “variable set” for both, ModeStatus and ModeTarget, with same result.

I tried to set it via “call action” command (see below) with same result.

luup.call_action( "urn:upnp-org:serviceId:HVAC_UserOperatingMode1", "SetModeStatus", {newModeStatus = "HeatOn"}, 77)

Any ideas why it is not working from the scene and works via 3-rd party app?

#2

Do you not need to use an action call to change mode, rather than just setting the variable?

#3

Akbooer is correct, you need to use call_action to set the thermostat mode…

And you were close with your attempt, but “SetModeStatus” is not a valid action… You want to use “SetModeTarget”… (Quick rule of thumb… a “Target” action set a state, a “Status” action retrieves status)

luup.call_action( "urn:upnp-org:serviceId:HVAC_UserOperatingMode1", "SetModeTarget", {NewModeTarget = "HeatOn"}, 77)
#4

I was really sure that I’ve tried that option, but it seems that not really :frowning:
It works (device keep its setting), later I’ll check if the heater is turning on/off according to the temperature set.

As for “Status” and “Target” - you’re right, but after it didn’t work at first (but I’ve tried “variable set” at the beginning) I decided to try every other option.

Thanks!

#5

I’m having a bit trouble with using the Qubino ZMNHID1 thermostat allso. There is no button on the UI to turn the thermostat On so the mode is allways “Off”.
I manageg to turn it on by seting “HeatOn” using the Luup.call_action above but I bet I can change the UI allso right?
It is now configured using device_json “D_HVAC_ZoneThermostatNoCoolHeat1.json”.
Any clue what I could try using instead?

EDIT:
Tried changeing it to “D_HVAC_ZoneThermostat1.json” but it changes back automatically???

#6

Looking at that static JSON file, there are only two states it will respond to: Off and AutoChangeOver (that’s in the 4903 version of the file). That may not be a complete picture, though, as UI7 has tons of exceptions for specific thermostats in the code, so without digging through that, and not having that thermostat, I can’t know.

Thermostats are a mess. Don’t change the name of the static JSON file–you’ll likely cause more problems than you solve. As I said, the UI7 code is loaded with all kinds of weird hard-coded exceptions for thermostats, in particular, and does strange things like look at the name of the static JSON file rather than other data values or state variables to make determinations about the device’s capabilities.

Edit: to embellish: the button’s appearance is driven by the contents of ModeStatus. That should be set by when SetModeTarget is called, which more directly sets ModeTarget, but ModeStatus is expected to follow. Things get hairy here, though, as UPnP defines ModeStatus as meaning the running state of the air handler, so if it was idle (not heating because temp > setpoint), then ModeStatus would be expected to be InDeadBand, where if active heating was going on, it would show Heating. Note these values are different from ModeTarget. But Vera also has been known to use ModeTarget and ModeStatus more like the way binary lights use Target and Status (target is the goal state, status is the actual state), and use a third variable to indicate what the air handler is actually doing. Because of this inconsistency, you need to figure out the particulars of each device/manufacturer/model… the behavior depends on who implemented it.

#7

Thanks @rigpapa for the heads-up on this one. I’ll just leave it alone and track how it works.
If it does not work as expected I will exclude and reinclude the devcie and see what happens.
As a last resort I will open a support ticket if needed.

#8

After a year of using this thermostat I can add some comments about its behavior.

I still use code to set it on/off via scene, and it still doesn’t show “heat” option in the interface (only OFF or Auto).
But if I go to the house modes settings, to the table where I can set how certain devices should behave after entering specific house mode, I see all options (OFF, Auto, Heat, Cool) available and they work correctly (so if I, for example, choose to set thermostat to Heat when entering Home and OFF when house mode is switched to Away, thermostat acts accordingly to these settings).
I also see all these options when using Imperihome, although native Vera mobile app shows only OFF and Auto.
In my opinion certainly something is wrong with how this device is implemented (it is on the Vera’s implemented devices list) and for me the biggest mystery is why it doesn’t work correctly in the “regular” interface while it works correct in the House modes settings section.

1 Like
#9

The static JSON file you referenced earlier is for thermostats that are basically heat only. I think the fact that it shows only “off” and “auto” as possible modes is a liberal interpretation of the heater’s function that it comes on as-needed, when needed (thus automatically). Unfortunately, that is not the typical use of the concept of “auto” where thermostats are concerned. So whoever made that implementation choice was coloring a little outside the lines, and it should probably be returned to the more normal “off” and “heat” only, if that’s all it supports.

The fact that all modes show in the My Modes page is a weakness of the overall strategy in handling device capabilities (or the absence of capabilities). And that’s doubly strange, because there are state variables defined to express the capabilities of the device and add or remove unsupported functions from the UI (hard-coded as that might be), yet for this device, they aren’t using them, suggesting perhaps that either (a) this device was implemented before those other facilities were put in place and they never went back and “upgraded” the older device UIs to use the new facilities, or (b) the facilities were in place, but the person who did this integration/implementation either didn’t know or decided not to use them.

Imperihome is another matter. It’s a third-party app and its inattention to device capabilities is probably from the long history of Vera not really having it either.

#10

Have you tried D_Heater1.json?

It seems to only support Off and Heat. I’m using it with a virtual device, just doing off/heat to turn on an electrical dehumidifier, and it’s working well for me.

#11

Thanks @kwieto for replying. This confirms that the device is behaving exactly the same for you and for me. Like you I had to send the HeatOn using Luup.call_action as it cannot be done from the UI. Since this it seems like it is doing what it is supposed to so I will not mess with it further.