ACCESS TO UNNAMED VARIABLES IN DEVICES

Developer's Corner Scene Scripting
1

I have a Vera Edge (U17) and would like to get access to certain variables which do not seem to be enumerated by Vera. Specifically, I would like to get the humidity from the CT100 and on time for the 4 in 1 sensor.

According to a poster the humidity was available from one of the 2 pseudo devices created when the thermostat is paired. Further it was indicated that the standard name could be used to get it. However when I run this:

local CurrHumidity = luup.variable_get("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel", DEVICE)

the CurrHumidity value returned is nil. This works for the 4 in 1 humidity device but not for any of the three thermostat devices. NOTE: My thermostat is device #31 and #32 and #33 show up as “Unnamed devices” in the Advanced Editor. All three devices return nil.

Another poster reported that according to Aeon the on time for the 4 in 1 sensor could be adjusted by modifying variables 100 and 101.

So the question is that if the name is not understood or defined internally by Vera is there a way to get access to it via a lower level index or number? Or maybe some syntax for get where you specify the variable number rather than a name? Or a special serviceID?

2

Did you change the ServiceID ?

3

I was able to access all of the seviceID variables that were defined in the JSON file for HVAC. I was able to for example get to the overall mode so that the humidifier is only active in heating mode.

I was not able to get to the fan state which is defined in some XML files but not in the JSON files. Aka I should not turn on the humidifier if the fan isn’t on.

I am almost ready to give up and go back to the old stupid humidity control which at least knows that the fan is on. Humidity is a strange animal the sensors readings are all over the place and it depends a lot on where the sensor is. For example the 4in 1 is 5 less than the Ct100 and 10 more than the humidistat.

I was never happy with the inconsistent humidity value displayed on my dedicated humidistat but apparently that’s just the nature of the beast.

4

You should be able to access any Variable that it’s the bottom of the Advanced Tab for the device.
If it’s not there … it does not exist!

5

Thanks for the clarification.

Are the variable names listed there downloaded from the device when it is paired?

Since the thermostat ghost devices are not in the device list they remain a mystery.

Is there any way to enumerate the variable list and serviceIDs from LUA?

6
Is there any way to enumerate the variable list and serviceIDs from LUA?

You can get a list of all variables for all devices with the command:

http://<veraip>:3480/data_request?id=status&output_format=xml

If you need this from Lua, you can use this:

err,resp = luup.inet.wget("127.0.0.1:3480/data_request?id=status&output_format=xml") if err == 0 then ... end

If you want to see how to walk through the response and extract the important stuff, look at the code for LuaTest.

7

Thanks the Web page is great reference. The unnamed thermostat devices are not enumerated so I suspect that they don’t do anything except screw up pairing other devices (I reported a U17 bug).

I noticed that the Advanced Editor (U17) has MORE variables listed that are in this XML. My conclusion is that the drop down provides all variables that the device COULD support and the XML reflects the variables that the installed device supports. So my CT100 firmware does NOT support GetFanStatus but some thermostat might support GetFanStatus via this variable. Indeed GetFanStatus returns nil and Mode (same serviceID) returns the expected value.

8
My conclusion is that the drop down provides all variables that the device COULD support and the XML reflects the variables that the installed device supports.

That’s pretty much it in a nutshell. The drop-down is probably listing all the variables that are defined in the service files that are specified in the device definition. These are often common to several types of device so are a super-set of all possibilities. The status report shows only variables that have been created by the device - i.e. they actually exist.