data request for zwave_status

When you execute the html for getting the status of the zwave devices (e.g. http://192.168.1.50:3451/data_request?id=zwave_status), you get output that looks like this:

[tt]
5 1 1,
11 0 0 1 1 0
12 <WATTS=100> <POWER=ON> <LEVEL=100> 1 0 4 Successful: Node already configured 1 0
15 <WATTS=30> <POWER=ON> <LEVEL=30> 1 0 4 Successful: Node already configured 1 0
16 FAILED 0 0 3 Waiting 1 1
17 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
18 <WATTS=39> <POWER=ON> <LEVEL=39> 1 0 4 Successful: Node already configured 1 0
19 FAILED 0 0 5 Aborted: Unable to get any information on node 1 0
20 <WATTS=40> <POWER=ON> <LEVEL=40> 1 0 4 Successful: Node already configured 1 0
21 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
22 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
23 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
24 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
25 <WATTS=0> <POWER=OFF> <LEVEL=0> 1 0 4 Successful: Node already configured 1 0
26 0 0 3 Waiting 1 1
27 <WATTS=50> <POWER=ON> <LEVEL=50> 1 0 4 Successful: Node already configured 1 0
28 0 0 2 Queued 1 1
29 0 0 2 Queued 1 1
30 0 0 2 Queued 1 1
31 0 0 2 Queued 1 1
32 0 0 2 Queued 1 1 [/tt]

I think it would be great if the lines could begin with the node/device names. Presumably whatever generates the status response has access to this info, and having it in the response would make the list easier to read - and more importantly easier to use if you are parsing the results.

Thanks for reading,
David

drzeller,

I agree it would be easier to read with that extra information directly in the zwave_status but I personally don’t believe there is any need for it as the first value of each lines already represents the PK_Device.

IMO, this file is not meant to be “easy to read”, as most tool/webpage/app that rely on it are going to parse it anyway and since you can figure out what a name/description (and a lot more) is from a PK_Device, this information would be redundant and (aside from making that file easier to read by human) would have the only effect of making that file bigger, which in other words means longer to download and to parse by each tool/webpage/app … hence making all those other interfaces slower.

Also, changing the structure of zwave_status later on would break backward compatibility with all scripts/tool/webpage/app that are already relying on its current format.

Maybe you can convince MCV to create a new data_request id with the name of each devices but my personal opinion is to not change current zwave_status format.

thanks,
-j.

Excellent points. I actually wondered if I could find the code for this somewhere on the router, but it is either not where I looked or it is part of an executable (not a script). If one were to change it, it would create support issues and/or get messed up during future updates. What might be nice would be to leverage an “add-on” or “plug-in” architecture that would enable someone to spit out whatever they wanted. I’m not into the details of this enough to know if that is possible, or perhaps even already supported. I’ve had some stability issues (related to my locks) that need to be locked down before I mess with anything!

D.

You can get the devices names by parsing the json or the xml with configurations:
http://192.168.81.1/port_3451/user_data?output_format=json
http://192.168.81.1/port_3451/user_data?output_format=json