http://XXX/port_3480/data_request?id=sdata - still maintained?

Plugins & Plugin Development General Plugin Discussion
#1

Hello,

I’m seeing incorrect data in sdata, I’m more concerned about the “setpoint” value that I get back.

http://XXX/port_3480/data_request?id=sdata returns:

{
  "altid": "39",
  "armed": "1",
  "armedtripped": "0",
  "category": 5,
  "commFailure": "0",
  "comment": "",
  "cool": "70.00",
  "fanmode": "Auto",
  "heat": "70.00",
  "hvacstate": "Idle",
  "id": 220,
  "light": "82.0",
  "mode": "CoolOn",
  "name": "UThermostat",
  "parent": 1,
  "room": 1,
  "setpoint": "70.00",
  "state": -1,
  "subcategory": 1,
  "temperature": "77.00",
  "watts": "0"
}

while:

http://XXX/port_3480/data_request?id=status returns:

{
  "Jobs": [],
  "PendingJobs": 0,
  "id": 220,
  "states": [
...
    {
      "id": 386,
      "service": "urn:upnp-org:serviceId:TemperatureSetpoint1",
      "value": "81.00",
      "variable": "CurrentSetpoint"
    },
    {
      "id": 387,
      "service": "urn:upnp-org:serviceId:TemperatureSetpoint1",
      "value": "81.00",
      "variable": "SetpointTarget"
    },
    {
      "id": 388,
      "service": "urn:upnp-org:serviceId:TemperatureSetpoint1_Heat",
      "value": "70.00",
      "variable": "CurrentSetpoint"
    },
    {
      "id": 389,
      "service": "urn:upnp-org:serviceId:TemperatureSetpoint1_Cool",
      "value": "81.00",
      "variable": "CurrentSetpoint"
    },
...
  ],
  "status": -1,
  "tooltip": {
    "display": 0
  }
}

Note that the 2 http calls are made in the same interval of few seconds, and the setpoint was set a few hours ago - setpoint in sdata doesn’t seem to be updated correctly - it seems to read TemperatureSetpoint1_Heat not TemperatureSetpoint1.

I would expect in sdata output:

  "heat": "70.00",
  "cool": "81.00",
  "setpoint": "70.00",

Am I doing something wrong or create a ticket with VERA?

Thank you.

#2

The sdata returns are defined by the shortCode name of the appropriate variable in the service file.

Take a look at the service file which that device is using and see which variable is referenced.

I regard the sdata request as a sort of failed experiment, so it wouldn’t surprise me if there is a problem there too. But I would look first at the service file.

#3

I downloaded all the service, S_*.xml files on my device and the only one I found that it contained setpoint and that was S_TemperatureSetpoint1.xml,

  <stateVariable>
     <name>CurrentSetpoint</name>
     <sendEventsAttribute>yes</sendEventsAttribute>
     <dataType>i4</dataType>
    <shortCode>setpoint</shortCode>
  </stateVariable>

but I didn’t find any that has heat or cool - I guess they are encrypted by Vera - since this a ZWaver Thermostat with device_file D_HVAC_ZoneThermostat1.xml and device_json D_HVAC_ZoneThermostat1.json.

#4

There be monsters around thermostats. Sit down lad, and let me tell you me tales of woe…

For starters, the values you see as attributes in sdata responses are those defined by the shortCode tags in the S_xxx.xml files, known as service files. So your code snippet is showing you that in the S_TemperatureSetpoint1.xml service file, Vera has expanded the UPnP standard definition of this service with a shortcode for the temperature setpoint (with name “setpoint”), so this shortcode and the state variable’s value will be added to any sdata response for a device that names the urn:upnp-org:serviceId:TemperatureSetpoint1 service as part of its device definition (in a D_xxx.xml file). [You seem to know this, so this is largely for the benefit of other readers and to support the conclusion later/below.]

Going further back and deeper, the way that UPnP intended vendors to differentiate between the cooling and heating setpoints was through the separate state variable and action called Application. If you changed the Application to “Heating”, then setting or reading the setpoint would give you the heating setpoint; if you changed it to “Cooling”, it would give you the cooling setpoint. You can also set it to “DualHeatingCooling”, which would set both setpoints at a single value, presumably with a deadband around them.

I guess at the time this was implemented in Vera, they couldn’t quite work out how to handle that within the static data (D_xxx.json) interface descriptions, or perhaps some other reason, but in any case, they didn’t implement the above. What they did is kludge the service ID so that you have to use two new, similarly-named-but-not-the-same service IDs that don’t actually exist in any definition. Using the standard service Id, they simply appended “_Heat” to the service Id for the heating setpoint, and “_Cool” for the cooling setpoint, and they ignore Application altogether.

So for the heating setpoint, you use service urn:upnp-org:serviceId:TemperatureSetpoint1_Heat to call the SetCurrentSetpoint action, or request the value of the CurrentSetpoint variable. For the cooling setpoint, you use service urn:upnp-org:serviceId:TemperatureSetpoint1_Cool to call SetCurrentSetpoint or request the value of CurrentSetpoint.

But in implementation this makes a really big problem for sdata. You see, they didn’t actually redefine new services for the above (make new service definition files), they just changed the name by which the device knows it, and pointed it to the existing standard service definition for urn:upnp-org:serviceId:TemperatureSetpoint1–the file S_TemperatureSetpoint1.xml. So both kludged services point to the same generic service definition. The problem with this is that it means these two different services are now both trying to use the same shortcode for two different values–TemperatureSetpoint1_Heat wants to use it for its heating setpoint, and TemperatureSetpoint1_Cool wants to use it for its cooling setpoint. The result is that sdata can only show you the heating setpoint or the cooling setpoint, whichever happens to be set last (so it’s effectively random for your purposes), before the data is written to the response. Put more succinctly, you cannot get both the heating and cooling setpoints for a dual temperature thermostat from an sdata request. You have to use a full status request.

For you Hass fans reading along, this is why dual-temp thermostats are also broken in Hass. The underlying interface layer, pyvera, principally uses sdata requests for device information.

2 Likes
#5

Hi @rigpapa you really touched and confirmed, with very low details my suspicion, in the end you really touched my painpoint as well Hass and pyvera - this is where I started from.

I guess the only good solution would be to use the lu_status or status calls - but it’s more work in pyvera to get the correct values.

I don’t see any other option than maybe wait for the new firmware, the rewritten one by Ezlo, and see if the issue persists or not.

Thank you @rigpapa for all the details.

2 Likes