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.
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
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
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
Note that only
CurrentSetpoint has a shortcode defined, and that is why it is the only variable exported to
sdata from this service.