Thermostat SetPointTarget variable not outputted to SDATA?

Community Playground General Discussions
#1

Hi

Working on something in Home Remote for Bill.

We are looking for the SetPointTarget variable in the SDATA stream, but I cannot see it when I change the setpoint of my Thermostat and I cannot see it by any other name in there either.

Anyone at Vera can confirm this and why this is the case ?

Thanks

#2

I don’t recognize that variable name. What service is it declared in (hover over its name in the Variables list)?

#3

Hi

On my Secure Thermostat it’s this:

urn:upnp-org:serviceId:TemperatureSetpoint1 / SetpointTarget

Anyway sounds like he now has a work around or a different way to handle the issue see here.

Thanks.

#4

OK. I’ll still answer fully for the benefit of all reading…

SetPointTarget is not a variable defined in the urn:upnp-org:serviceId:TemperatureSetpoint1 service. That looks to be an extra variable Vera has added in their implementation of support for that particular device, but it is not a standard variable for thermostats/setpoints for either Vera or UPnP, at least not as yet. So that’s the first challenge: anything you do with this variable may not be supported by other thermostats.

The sdata request/response is formed by using the <shortCode> tags in service definitions named by the enumerated devices. This tag is an extension Vera made to the XML of the standard UPnP service definition; it is particular to Vera. State variables in a service that are given a <shortCode> tag are exported to the sdata response. State variables that do not have this tag do not appear in sdata.

There is no requirement in Luup that every variable that exists be defined by the service. You can create variables in any service, even if the service isn’t declared to be used by the device; you can even make up service IDs out of thin air and use them. All of that will work — they are just data. [Note that this is unlike actions, which will not work unless they are defined formally in a service definition formally associated with the device/type.]

But it should be clear that the because the state variable SetPointTarget is not a standard state variable defined by the service in which it is being used (i.e. it is absent from the service definition of urn:upnp-org:serviceId:TemperatureSetpoint1), it will have no shortcode and not appear in sdata.

All state variables are output by the status request/request, however (and the larger user_data request/response unless you request a no-status format response from it by adding ns=1 to the query parameters). This is why, although sdata may be attractive for its compact size, it is inferior for deep/serious integrations and (IMO) should be avoided.

That said, a workaround for any variable not appearing in sdata might also be to either (a) specifically request the variable using a variableget request/response, or (b) using a status request for the specific device (to keep its size down). My personal preference is to steer away from solutions like this, however, as it tends to breed exceptions for specific devices or types in the code that ultimately make it harder to support.

A further caution: any state variable used that is not defined in the parent service definition should be treated with some suspicion. Treat them as “undocumented features” that could vanish, change values, go unused, etc., at any time.

For further documentation, here are the variables formally declared by the UPnP TemperatureSetpoint1 service:

   <serviceStateTable>
      <stateVariable>
         <name>Application</name>
         <sendEventsAttribute>yes</sendEventsAttribute>
         <dataType>string</dataType>
      </stateVariable>
      <stateVariable>
         <name>CurrentSetpoint</name>
         <sendEventsAttribute>yes</sendEventsAttribute>
         <dataType>i4</dataType>
        <shortCode>setpoint</shortCode>
      </stateVariable>
      <stateVariable>
         <Optional/>
         <name>SetpointAchieved</name>
         <sendEventsAttribute>yes</sendEventsAttribute>
         <dataType>boolean</dataType>
         <defaultValue>0</defaultValue>
      </stateVariable>
      <stateVariable>
         <Optional/>
         <name>Name</name>
         <sendEventsAttribute>yes</sendEventsAttribute>
         <dataType>string</dataType>
         <defaultValue/>
      </stateVariable>
   </serviceStateTable>

Note that only CurrentSetpoint has a shortcode defined, and that is why it is the only variable exported to sdata from this service.

#5

@rigpapa
Thanks for your explanation! I have also started with The Home Remote app to replace Imperihome. I have transferred almost all my devices to THR. It’s a great app by the way.
Now I also see that not all variables of some devices I need are in the sdata output. To be sure: there is no way this sdata output can be changed ? Vera engineers are the only ones that can do this?

#6

You can provide replacements for the Vera service files with <shortCode> tags added for those variables also needed.

It makes me cringe to even say that, but it would likely work (at least until the next firmware update).

1 Like
#7

Thanks, your message is clear. I will be very cautious and only do it when really needed and document it well and save the adapted service files separately

#8

In the newer firmware /etc/cmh-lu, which is where those files come from, is read-only, so you’ll have to put the modified files in /etc/cmh-ludl anyway. Hopefully, it reads ludl first.

#9

Humm… now I’m a bit confused. I thought I have to chang the .xml files starting with “s_” that are amongst the luup files (when going to apps-develop apps-luup files like s_dimming1.xml. Download them, change and upload again ?

#10

That would be correct. The question I don’t know the answer for is, what will happen when you try to upload them? Since they come from a read-only filesystem, my hope is that the upload won’t be too “smart” and try to put them back where they came from (because it can’t). I hope the upload is a bit dumber and just puts everything in cmh-ludl. I know it does for the plugin and other files we routinely upload, but those usually don’t conflict with system files.

You’re just going to have to experiment.

1 Like