Enumerating sensor ids

Discussions about Z-Way software and Z-Wave technology in general
User avatar
PoltoS
Posts: 5611
Joined: 26 Jan 2011 19:36

Re: Enumerating sensor ids

Post by PoltoS »

This means that the user you access it does not have permission to devices. If you do it locally without logging in, then local user is used and by default it does not have any access.

Go to user preference and grant access to devices you need or log in before doing the request.

erozen
Posts: 13
Joined: 12 Apr 2020 03:21

Re: Enumerating sensor ids

Post by erozen »

Great, that got it thanks. It hadn't clocked the api without authentication still uses an account, and that that account is a separate pre-existing one. Should've poked around in management further though, I would've tried that if I'd found it.

erozen
Posts: 13
Joined: 12 Apr 2020 03:21

Re: Enumerating sensor ids

Post by erozen »

That mostly works, but one device is coming out of the sensor logger as

Code: Select all

3-0-113-8-254
but in ZAutomation it's id is:

Code: Select all

3-0-113-8-8-A
Is that normal? Will it happen for other devices too? I'm hoping to avoid having to code all sorts of weird exceptions here, is there a better way to get the data? Where does the sensor logging app get it's ID string from, can I just use that?

User avatar
PoltoS
Posts: 5611
Joined: 26 Jan 2011 19:36

Re: Enumerating sensor ids

Post by PoltoS »

Those are two different vDevs I suppose. OR where the -254 comes from?

erozen
Posts: 13
Joined: 12 Apr 2020 03:21

Re: Enumerating sensor ids

Post by erozen »

I'd love to know where the -254 comes from! It's the value for one of the events, but otherwise doesn't turn up anywhere in ZWaveApi output. Likewise I can't find an '8' anywhere that might match what I'm seeing in ZAutomation.

Is the 254 it reporting the value? Seems unlikely, doesn't really make sense for a device id, and where would the A be coming from in that case? I'm sure it's a sensible layout, I just haven't been able to work out what it means with what I've been able to learn from the APIs and doc so far.

Is the sensor data logging app open source? I don't see it listed on your github, but if it is I can take a look myself, hopefully figure out what's going on. Maybe add an extra macro to it too, so you can send the device name in the GET request, which would save all of this.

Output below:

Code: Select all

$ grep 3.*0.*113.*8 /var/zwave-data/log/sensors.log* | cut -f 2 -d "," | sort | uniq -c
   4052 ZWayVDev_CEN_3-0-113-8-254-A
$

Code: Select all

$ curl -sgL 'http://127.0.0.1:8083/ZAutomation/api/v1/devices/ZWayVDev_CEN_3-0-113-8-254-A' | json_pp
{
   "data" : null,
   "code" : 404,
   "message" : "404 Not Found",
   "error" : "Device ZWayVDev_CEN_3-0-113-8-254-A doesn't exist"
}
$
$ curl -sgL 'http://127.0.0.1:8083/ZAutomation/api/v1/devices/ZWayVDev_CEN_3-0-113-8-8-A' | json_pp
{
   "data" : {
      "creatorId" : 1,
      "locationName" : "Living",
      "tags" : [],
      "location" : 1,
      "permanently_hidden" : false,
      "updateTime" : 1587258401,
      "id" : "ZWayVDev_CEN_3-0-113-8-8-A",
      "deviceType" : "sensorBinary",
      "probeType" : "alarm_power",
      "order" : {
         "elements" : 0,
         "dashboard" : 0,
         "rooms" : 0,
         "room" : 10
      },
      "h" : -1107333144,
      "visibility" : true,
      "creationTime" : 1586646680,
      "hasHistory" : false,
      "nodeId" : 3,
      "customIcons" : {},
      "metrics" : {
         "title" : "Stairway light: alarm",
         "isFailed" : false,
         "level" : "off",
         "icon" : "alarm"
      }
   },
   "message" : "200 OK",
   "error" : null,
   "code" : 200
}
$

Code: Select all

$ curl -sgL 'http://127.0.0.1:8083/ZWaveAPI/Run/devices[3].instances[0].commandClasses[113].data[8]' | json_pp
{
   "typeString" : {
      "updateTime" : 1587163262,
      "invalidateTime" : 1587163261,
      "value" : "Power Management",
      "type" : "string"
   },
   "event" : {
      "value" : 254,
      "invalidateTime" : 1587163261,
      "updateTime" : 1588662602,
      "type" : "int"
   },
   "eventParameters" : {
      "type" : "binary",
      "value" : [],
      "invalidateTime" : 1587163261,
      "updateTime" : 1588662602
   },
   "status" : {
      "type" : "int",
      "invalidateTime" : 1587163261,
      "updateTime" : 1588662602,
      "value" : 255
   },
   "eventString" : {
      "value" : "unknown",
      "updateTime" : 1588662602,
      "invalidateTime" : 1587163261,
      "type" : "string"
   },
   "eventSequence" : {
      "type" : "empty",
      "invalidateTime" : 1587258899,
      "updateTime" : 1587258900,
      "value" : null
   },
   "type" : "empty",
   "value" : null,
   "eventMask" : {
      "type" : "binary",
      "invalidateTime" : 1587163261,
      "updateTime" : 1587163262,
      "value" : [
         0,
         1
      ]
   },
   "updateTime" : 1588662602,
   "invalidateTime" : 1587163261
}
$

User avatar
PoltoS
Posts: 5611
Joined: 26 Jan 2011 19:36

Re: Enumerating sensor ids

Post by PoltoS »

Yes, this part us opensource : https://github.com/Z-Wave-Me/home-autom ... x.js#L5773

The VDev is created under this if

erozen
Posts: 13
Joined: 12 Apr 2020 03:21

Re: Enumerating sensor ids

Post by erozen »

Yikes, I don't think I'll be able to make sense of that without a lot of work. I was hoping just the sensor values logging app was opensource - that seems like a bite-size piece of code I can figure without learning all the other intricacies of the suite. My plan would be simply to add a macro ${name} to complement ${id} - then it wouldn't matter that the APIs disagree on the ID, because I'd already have the data I need. It doesn't matter which API it comes from, in that case.

I would also probably make it so you can add multiple sensors - right now I have 14 copies of the app, which is a pain to maintain.

erozen
Posts: 13
Joined: 12 Apr 2020 03:21

Re: Enumerating sensor ids

Post by erozen »

Oh, I found it! Pull request raised, though you'll want to rework my translations, I'm sure.

Post Reply