Lights are both sensors and lights

[jonatanolofsson]

Currently, when I load the data from the REST/sensors and REST/lights endpoints, my Trådfri bulb shows up (with different properties) in both. In the websocket, events show up on both devices, but differently whether they were triggered from the webapp, gui or by the device.

device: config (battery) messages goes to "r":"sensors" webapp: event ("changed") messages goes to "r":"lights" deconz: event ("changed") messages goes to "r":"sensors"

There doesn't seem to be a way to control lights from the webapp without adding them to a group, so further you also get a groups update as well.

Perhaps this is expected behaviour?

[manup]

Interesting, can you provide the REST API output from this?

There are lights which also happen to be sensors but I don't think IKEA has such lights.

[jonatanolofsson]

api/<>/lights:

{
   "1":{
      "ctmax":454,
      "ctmin":250,
      "etag":"f2bb07a0b9aa5b6fcb95cb196ca578f6",
      "hascolor":true,
      "manufacturername":"IKEA of Sweden",
      "modelid":"TRADFRI bulb E27 WS opal 980lm",
      "name":"Light 1",
      "state":{
         "alert":"none",
         "bri":254,
         "colormode":"xy",
         "ct":370,
         "effect":"none",
         "hue":0,
         "on":true,
         "reachable":true,
         "sat":0,
         "xy":[
            0,
            0
         ]
      },
      "swversion":"1.2.217",
      "type":"Unknown",
      "uniqueid":"00:0b:57:ff:fe:b1:02:e4-01"
   }
}

api/<>/sensors

{
   "1":{
      "config":{
         "alert":"none",
         "battery":100,
         "on":true,
         "reachable":false
      },
      "ep":1,
      "etag":"6681323af3bda9fbb60f3673acb0ec2a",
      "manufacturername":"IKEA of Sweden",
      "mode":1,
      "modelid":"TRADFRI bulb E27 WS�opal 980lm",
      "name":"TRADFRI bulb E27 WS�opal 980lm 1",
      "state":{
         "buttonevent":-1,
         "lastupdated":"2017-11-24T08:01:42"
      },
      "swversion":"1.1.1.1-5.7.2.0",
      "type":"ZHASwitch",
      "uniqueid":"00:0b:57:ff:fe:b1:02:e4-01-1000"
   },
   "2":{
      "config":{
         "on":true,
         "reachable":true
      },
      "ep":1,
      "etag":"3d667410fe5575b7c3599ac62a7fb2f4",
      "manufacturername":"LUMI",
      "modelid":"lumi.sensor_magnet",
      "name":"OpenClose 2",
      "state":{
         "lastupdated":"2017-11-27T11:06:52",
         "open":false
      },
      "type":"ZHAOpenClose",
      "uniqueid":"00:15:8d:00:01:4e:05:8e-01-0006"
   },
   "3":{
      "config":{
         "alert":"none",
         "battery":47,
         "group":"51623",
         "on":true,
         "reachable":true
      },
      "ep":1,
      "etag":"0966bafcf1ec926f113a406dd72884ff",
      "manufacturername":"IKEA of Sweden",
      "mode":3,
      "modelid":"TRADFRI remote control",
      "name":"TRADFRI remote control ",
      "state":{
         "buttonevent":1002,
         "lastupdated":"2017-11-27T12:28:18"
      },
      "swversion":"1.2.214",
      "type":"ZHASwitch",
      "uniqueid":"00:0b:57:ff:fe:b2:0d:a5-01-1000"
   }
}

websocket:

{
   "config":{
      "alert":"none",
      "battery":100,
      "on":true,
      "reachable":false
   },
   "e":"changed",
   "id":"1",
   "r":"sensors",
   "t":"event"
}{
   "e":"changed",
   "id":"1",
   "r":"lights",
   "state":{
      "on":false
   },
   "t":"event"
}

The differing publications on "changed" may have been my mistake, but the config events still seem to come on "sensors". Perhaps as you say it considers the battery (mains, in this case, so it's pretty pointless) a separate sensor..

[manup]

/sensors/1 is indeed very strange, I wonder how this happened. I'll check the code and add some more checks to prevent this.

[ebaauw]

Note that while both the sensor resource and the light resource refer to the same node (check the mac address in the uniqueid), the sensor resource lists the old firmware version (and model with the funny character) whereas the light resource lists the new firmware.

What version of deCONZ are you on? What version where you on when you paired the light still having the old firmware? deCONZ used to create switches for any node with a client OnOff cluster (I saw that for so e of my innr lights), but that was many, many versions ago.

[jonatanolofsson]

Hi,

Interesting observation.

I am on V2.04.92 and I was likely on V2.04.91 when I first paired it (and also did the firmware upgrade). Come to think about it I did shortly install the V2.04.35 from the download page before I realised it wasn't the beta, perhaps it's a remnant in the database? I'll try to check later with a fresh install if it appears.

[ebaauw]

Pairing it in .35 would explain this.

Make sure to delete the database in ~/.local/share/dresden-elektronik/deCONZ/zll.db with the fresh install, or deCONZ might restore the (logically) deleted sensor resource.

[jonatanolofsson]

I can confirm that when paired in a fresh install, it didn't show up as a sensor