Where is SetpointTarget statevariable defined?

Developer's Corner General Dev Discussions
1

According to Luup UPnP Variables and Actions web page http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions.

SetpointTarget should be defined in S_TemperatureSetpoint1.xml file. However it is not defined there. It is not defined in any service or device file that I know. How does Vera know about it?

Do you know where it is defined?

Thanks,

Ercan

2

Don’t believe everything you read :slight_smile:

I do not have a SetpointTarget on my Z-Wave thermostat.

3

Well … I was wrong … I do have two in my thermostat … I guess I scrolled passed them the first time. One for cooling and one for heating.

Variables do not HAVE to be in the S_XXX.xml file for Vera to be able to use them. The S_XXX files are there to define the UPnP interfaces.
The actions must be defined in an S_XXX.xml file. The variable definitions, including the related variables in the action definitions are optional from a Vera Perspective.
So these variables (Like all others in Vera) are created when needed by the Thermostat implementation.

4

Is there any reason for these inconsistencies? Shouldn’t these be treated as bugs that needs to be fixed?

If S_ files and D_ files are updated with proper state variable and shortcodes, it will make it way easier to develop third party apps for Vera.

5

This is not considered to be a bug. If you are developing a 3rd party app, it is suggested that you use user_data and lu_status. I’ve been there and used sdata when first making my app. I converted over about a year ago to using user_data and lu_status to make my life easier.

  • Garrett
6

But user_data is around 445K (xml) for my home with 84 devices. And Status costs around 201K (xml). Although it does not look very big, it may be big for microcontrollers like Netduio for some houses. sdata costs only 18kb even for initial pull. At some countries, it may be an issue with mobile data plans also.

With the current implementation, I am planning to use shortcodes. If I cannot find matching shortcodes for a device, then I am going to pull status for that device only.

If shortcodes are better defined or another format introduced for config and changes, it may be better for microcontrollers and mobile devices.

7

The initial pull of the user_data my be large, but when you pull the lu_status using the loadtime and dateversion of the last retrieval will yield you a smaller data payload. I have much experience with sdata and can tell you, you will be very disappointed when it comes to requiring more data. I have used it for several years with my app until I had enough. Not every plugin / device shows all the data via shortcodes. I had the same mentality of using the sdata due to data usage, but I can assure you if you implement the way it is described, it will not be as bad as polling sdata all of the time. using loadtime and dataversion when calling lu_status will only return changes from the last poll.

You are going down the same path as I was with the limited data in sdata and trying to figure out how to get more data without going the user_data / lu_status route. I suggest you give it a try and see how it works out.

  • Garrett