sdata

Plugins & Plugin Development openLuup
1

There are some scripts that use the sdata request (data_request?id=sdata) and are not compatible with openluup due to the difference responses in sdata. I could use user_data but everything would have to be rewritten so I was wondering if it’s possible to add the scene’s name,id,room information (besides active and state) to the sdata request’s response?

json response from regular vera:
“scenes”: [ { “active”: 0, “name”: “Back door is open”, “id”: 12, “room”: 2 },

Response from openluup
“scenes”:[{“active”:1,“state”:-1},

2

Yes, should be straight-forward to do. I haven’t updated sdata since I added scenes (which were not there originally!)

3

Is it wise to have openluup have a different behavior from Vera ?

4

Oh, I thought we were talking about aligning them? Indeed, openLuup should be as much like Vera as possible both from the luup and HTTP APIs point of view.

5

OK, the GitHub master has been fixed to make the sdata scenes table report the same things as Vera…

scenes": [
{
    "name": "RGBW All OFF",
    "id": ​4,
    "room": ​0,
    "active": ​1
},
{
    "active": ​0,
    "name": "RGBW Full ON",
    "id": ​3,
    "room": ​0
}
],

Thanks to @ronluna for pointing that out.

6

Just test your new request.lua and is working great for scenes. Although a new little bug emerged on the device’s structure

Vera has the following structure

devices: [{
name: “Faucet Light”,
altid: “9”,
id: 15,
category: 3,
subcategory: 0,
room: 4,
parent: 1,
status: “0”,
state: -1,
comment: “”
},

openLuup is missing “status, state, comment” I believe “comment” is irrelevant…

devices: [{
altid: “9”,
category: 3,
id: 10015,
name: “Faucet Light”,
parent: 4,
room: 7,
subcategory: 0
},

7

What do you plan to do with those values?

8

There is a little app that I’m working on that checks the status and state of the devices and shows what the engine is doing to prevent floodings or re-attempts of sending the same command and to know if the device is on/off

http://wiki.micasaverde.com/index.php/UI_Simple#State_of_engine.2C_device.2C_or_scene

(NONE, PENDING, ERROR, SUCCESS)

Now That I’m digging deeper I’ve noticed that sdata is missing:

  • For Binary Switches
    status: “0”,
    state: -1,
    comment: “”

  • For Dimmers:
    status: “0”,
    level: “0.0”

  • For Thermostats:
    fanmode: “Auto”,
    hvacstate: “Cooling”,
    mode: “CoolOn”,
    temperature: “73.0”,
    setpoint: “72”,
    heat: “55”,
    cool: “72”,
    batterylevel: “77” (For Battery Operated devices)

  • For Door Locks:
    pincodes:
    locked: “1”,
    batterylevel: “40”,
    commFailure: “0”

  • For Motion Sensors:
    armed: “0”,
    armedtripped: “0”

  • For Energy Meter or devices that can read energy consumption:
    kwh: “8498.4990”,
    watts: “5739.240”,
    batterylevel: “0”

  • For Humidity Sensor:
    humidity: “61”

  • For Temperature sensor:
    temperature: “73.9”

I believe there is more.
Without this sensity data sdata is kinda useless . :frowning:

9

Can I ask WHY you are using sdata, rather than user_data and/or status? sdata is, IMHO, something of a failed experiment by Vera, and few apps actually use it.

Edit:

I ask, because that is a LOT of device-specific coding which is unlike anything else in the HTTP requests that Vera supports.

10

The app I’m working on is one of those few apps. :cry:

Based on your previous response adding this values to the sdata is something you don’t consider necessary…

11

It’s not that it’s not necessary, it would certainly improve Vera compatibility. I’m just pointing out that it’s a lot of work with very little payoff.

The ‘state’ variable is derived from the job state which is more fully described by these values:

local state =  {
    NoJob=-1,
    WaitingToStart=0,         --  If you return this value, 'job' runs again in 'timeout' seconds 
    InProgress=1,
    Error=2,
    Aborted=3,
    Done=4,
    WaitingForCallback=5,     -- This means the job is running and you're waiting for return data
    Requeue=6,
    InProgressPendingData=7,
 }

…but I’m totally unsure of the meaning of ‘status’.

Job states are already used in openLuup (devices and scenes run as jobs), although due to lack of documentation, I struggle to make a complete implementation of the luup API for jobs.

What’s your understanding of ‘status’ vs. ‘state’ ?

12

[quote=“akbooer, post:11, topic:191163”]It’s not that it’s not necessary, it would certainly improve Vera compatibility. I’m just pointing out that it’s a lot of work with very little payoff.

The ‘state’ variable is derived from the job state which is more fully described by these values:

local state =  {
    NoJob=-1,
    WaitingToStart=0,         --  If you return this value, 'job' runs again in 'timeout' seconds 
    InProgress=1,
    Error=2,
    Aborted=3,
    Done=4,
    WaitingForCallback=5,     -- This means the job is running and you're waiting for return data
    Requeue=6,
    InProgressPendingData=7,
 }

…but I’m totally unsure of the meaning of ‘status’.

Job states are already used in openLuup (devices and scenes run as jobs), although due to lack of documentation, I struggle to make a complete implementation of the luup API for jobs.

What’s your understanding of ‘status’ vs. ‘state’ ?[/quote]

State shows what happened to the last command sent to a particular device:
NONE: state value is -1. This means there’s nothing to report to the user.
PENDING: state value is 0, 1, 5 or 6.
ERROR: state value is 2 or 3.
SUCCESS: state value is 4

Status shows the particular properties of the different devices:
SCENE: There is simply a ‘Run’ button for the control. (Active could be conside the status of the scene)
CATEGORY #2 - Dimmable Light: ‘status’ is 0 or 1 for off or on, and if status is 1, ‘level’ is a value from 0-100 to indicate the brightness.
CATEGORY #3 - Switch: Like dimmable light, but it only has ‘status’
CATEGORY #4 - Security Sensor: ‘tripped’ is 0 or 1 to indicate if the sensor is tripped or not (1=tripped). ‘armed’ is 0 or 1 to indicate if it’s in an armed state.
CATEGORY #5 - Thermostat: fanmode: “Auto”, hvacstate: “Cooling”,mode: “CoolOn”,temperature: “73.0”,setpoint: “72”, heat: “55”,cool: “72”,
CATEGORY #6 - Camera: These don’t have a status.
CATEGORY #7 - Door lock: ‘status’ is 1 for locked or 0 for unlocked.
CATEGORY #8 - Window covering: same as Dimmable Light.
CATEGORY #16 - Humidity sensor: ‘humidity’ is the relative humidity from 0-100. Just display the ‘humidity’,
CATEGORY #17 - Temperature sensor: ‘temperature’ same as with a thermostat.
CATEGORY #18 - Light sensor: ‘light’ is a measurement of the ambient light in the room.
CATEGORY #21 - Power meter: ‘watts’ is the current consumption in watts.

13

Actually, it’s both necessary and interesting.

What I found (that I certainly hadn’t appreciated previously) was the these additional variables in sdata are all defined in the service files as variables with a [tt]shortCode[/tt] tag (which is the name as used in sdata.) I always wondered what [tt]shortCode[/tt] was for. So there was no need to do category-specific additions, it just happens automatically. I did, however, have to fix the xml reader and file loader in the process.

Heres a humidity measurement (from a multi-sensor):

{
    "altid": "10373",
    "category": ​16,
    "humidity": "56",
    "id": ​10373,
    "light": "0",
    "name": "Loft Humidity",
    "parent": ​8,
    "room": ​3,
    "state": ​-1,
    "subcategory": ​0,
    "temperature": "22",
    "watts": "0"
},

The development branch openLuup/openLuup at development · akbooer/openLuup · GitHub has changes to three files:

[ul][li]xml.lua[/li]
[li]loader.lua[/li]
[li]requests.lua[/li][/ul]

Would be interested in your testing of this, since I certainly don’t have many of the devices in question. I am pretty sure there is a bug lurking somewhere there, but this is a first attempt.

14

Yes, Of course. I just left town but I can run some test when I get to my final destination tomorrow!!! :smiley:

15

Just got back home and started to test the new sdata format. I’d like to report that is working very well. So far all the data is in the json response .

I’ll continue running some more tests and if I find something weird I will let you know!!! ;D