{"action":"created","issue":{"url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/404","repository_url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin","labels_url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/404/labels{/name}","comments_url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/404/comments","events_url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/404/events","html_url":"https://github.com/dresden-elektronik/deconz-rest-plugin/issues/404","id":295808199,"number":404,"title":"deCONZ enhancements for IAS devices","user":{"login":"ebaauw","id":22179355,"avatar_url":"https://avatars0.githubusercontent.com/u/22179355?v=4","gravatar_id":"","url":"https://api.github.com/users/ebaauw","html_url":"https://github.com/ebaauw","followers_url":"https://api.github.com/users/ebaauw/followers","following_url":"https://api.github.com/users/ebaauw/following{/other_user}","gists_url":"https://api.github.com/users/ebaauw/gists{/gist_id}","starred_url":"https://api.github.com/users/ebaauw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ebaauw/subscriptions","organizations_url":"https://api.github.com/users/ebaauw/orgs","repos_url":"https://api.github.com/users/ebaauw/repos","events_url":"https://api.github.com/users/ebaauw/events{/privacy}","received_events_url":"https://api.github.com/users/ebaauw/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-02-09T09:38:39Z","updated_at":"2018-02-11T21:31:53Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I've got a whole bunch of Heiman sensors on loan from @Oggymator, to integrate into deCONZ and homebridge-hue (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/263#issuecomment-362527633).  They all connect to deCONZ without any issue, and I'm analysing them through the web GUI and ZigBee sniffing.  They're _IAS Zone_ devices, except for the temperature/humidity sensor, which is a _Temperature Sensor_ and the Siren, which is an _IAS Warning Device_).\r\n\r\nI'm trying to figure out the best way to support these in deCONZ, see also earlier discussions in #152, #269, and #352), and would like your views, @manup, @rtenklooster, and, of course, any-one else.\r\n\r\n1. The _IAS Zone_ devices obviously provide an _IAS Zone_ cluster.  They send _Zone Status Change Notification_ commands when an alarm occurs _and_ when it's cleared.  They set the _Restore reports_ bit in the _Zone Status_.  deCONZ could/should take this as a hint not to use `config.duration` to clear the alarm.\r\n2. The sensors provide their type through  _IAS Zone Status_, but this is rather coarse grained.  Both the combustable gas and the carbon-monoxide (CO) sensor report _Gas sensor_.  This means, any REST API client (i.c. homebridge-hue) would still need to check the `manufacturername` and `modelid`, even if deCONZ would provide a `zonetype` attribute.  Would it still make sense to provide `zonetype`?\r\n3. Next to _Alarm 1_, the sensors also set/clear the _Tamper_ and _Battery_ bits in the  _Zone Status_.  The sensors contain a tamper button which gets depressed when you remove them from their base plate, and I had some almost depleted AAA batteries lying around.  I think it makes sense to expose these through deCONZ as well.  deCONZ could introduce a sensor `type` of `ZHAStatus` which provides the _Zone Status_ bitmap as `state.status`.  `CLIPGenericStatus` can be used to simulate a `ZHAStatus` sensor.  Alternatively, deCONZ could introduce a sensor `type` of `ZHAAlarm`, with separate Boolean attributes `state.alarm`, `state.tamper`, `state.battery`.  We'd need a corresponding `CLIPAlarm` to simulate these.\r\n4. It makes sense to map a _Contact switch_ to a `ZHAOpenClose` sensor resource, and a _Motion sensor_ to a `ZHAPresence`, but what about the additional _Zone Status_ bits?  If we go for `ZHAAlarm`, we could expose `state.tamper` and `state.battery` to `ZHAOpenClose` and `ZHAPresence` as well.  `zonetype` wouldn't be needed here, as it's implied by `type`.\r\n5. The Smoke, CO, and Gas sensors, as well as the Siren have an audible alarm.  The Siren and Smoke sensors advertise an _IAS WD_ cluster (0x0502).  The CO sensors seems to have the same firmware as the Smoke sensor, so I suspect it to have this cluster as well.  It's not defined in `general.xml` - I'll try and add it and see what will happen.  The ZCL defines an unnamed map8 attribute, which combines multiple sub-attributes: _Warning Mode_, a 4-bit enum, _Strobe_, a boolean, and _Siren Level_, a 2-bit enum.  I don't suppose `general.xml` will be able to support that?\r\n6. If I follow the principle that `/sensors` provides resources for sensing devices, and `/lights` provides resources for actuators, deCONZ would expose the sirens under `/lights`.  Not only would that be unexplainable, we'd also run into the issue that the Smoke and CO sensors are ZigBee end-devices (the Gas sensor and Siren are mains powered and ZigBee routers).  I think we'd better expose this cluster as a `/sensors` resource?\r\n7. ZCL defines two commands for _IAS WD_, _Start Warning_ and _Sqawk_, and one attribute, _MaxDuration_.  The latter can be exposed through `config.duration` (would introduce `config` to `/lights`).  The commands could be exposed through a combination of `state.alert` (for warnings: `\"stop\"`, `\"burglar\"`, `\"fire\"`, `\"emergency\"`, `\"police panic\"`, `\"fire panic\"`, and `\"emergency panic\"`) and `state.effect` (for strobe effects: `\"strobe\"`).  We could use `state.transitiontime` for _Warning duration_ or provide a new `state.duration`.  For _Siren level_ and _Stobe level_ we would need new `state` attributes (`\"low\"`, `\"medium\"`, `\"high\"`, `\"very high\"`), as for _Strobe Duty Cycle_ (int8).  At the moment this is academic - I still need to figure our what the devices support.  They make a hell of a noise, so this might take some time, as I need to recover my hearing after each test...\r\n8. The temperature/humidity sensor exposes two _Temperature sensor_ endpoints, one with the _Temperature sensing_ cluster, and one with the _Humidity sensing_ cluster.  Both endpoints contain a basic cluster, but with a different value for _Model_: `TH-T_V15` vs `TH-H_V15`.  No big deal, I simply whitelisted both values, but this is the first time I've seen this.\r\n9. The (ZigBee module for the) Siren and the Plug seem to be made by a different manufacturer, using MAC prefix of 0x000d6f (ember) and a _Manufacturer Code_ of 0x120b and 0x1002.  Where can I lookup these codes?\r\n10. The plug provides _Simple Metering_ (0x0702) and _Electrical Measurement_ (0x0B04) clusters.  My OSRAM plugs only provide _Electrical Measurement_ - I think it best to expose only this cluster.  That would mean a new `/sensors` resource `type` ZHAPower` with a `state.power` attribute?  Or would we simply expose `state.power` as additional attribute to the `/lights` resource?  The OSRAM plug reports value 28000 when no power is drawn instead of 0, so we might need access to the `state.on` attribute to map 28000 it to 0 when `state.on` is false.  The plug is rated for over 3000W, so I suspect 28000 could be a valid value as well.\r\n11. The value of the _Active Power_ attribute (0x050B) seems to be in deciWatt, rather than Watt, as specified by the ZCL.  Maybe `general.xml` is just missing the definitions for attributes ACPowerDevisor (0x0605) and ACPowerMultiplier (0x0604) - I need to check.\r\n12. In `de_web_plugin.cpp` IAS_ZONE_CLUSTER_ID and OCCUPANCY_SENSING_CLUSTER_ID are combined in the same `case` block, followed by an `if` to split them: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/475c614a33335e5fb3e8b3b383b42876dd7c2ccc/de_web_plugin.cpp#L2651-L2659\r\n  I want to split these into two `case` blocks, but where should I place the code for the Centralite Motion Sensor-A?  Does it expose an _IAS Zone_ or an _Occupancy Sensing_ cluster?\r\n"},"comment":{"url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/comments/364790836","html_url":"https://github.com/dresden-elektronik/deconz-rest-plugin/issues/404#issuecomment-364790836","issue_url":"https://api.github.com/repos/dresden-elektronik/deconz-rest-plugin/issues/404","id":364790836,"user":{"login":"rtenklooster","id":6507714,"avatar_url":"https://avatars2.githubusercontent.com/u/6507714?v=4","gravatar_id":"","url":"https://api.github.com/users/rtenklooster","html_url":"https://github.com/rtenklooster","followers_url":"https://api.github.com/users/rtenklooster/followers","following_url":"https://api.github.com/users/rtenklooster/following{/other_user}","gists_url":"https://api.github.com/users/rtenklooster/gists{/gist_id}","starred_url":"https://api.github.com/users/rtenklooster/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rtenklooster/subscriptions","organizations_url":"https://api.github.com/users/rtenklooster/orgs","repos_url":"https://api.github.com/users/rtenklooster/repos","events_url":"https://api.github.com/users/rtenklooster/events{/privacy}","received_events_url":"https://api.github.com/users/rtenklooster/received_events","type":"User","site_admin":false},"created_at":"2018-02-11T21:31:53Z","updated_at":"2018-02-11T21:31:53Z","author_association":"NONE","body":"Yes it is.\r\n02 -> 000C\r\nAnd yes, it's in watts. I have double checked the readings from within the mi home app.\r\nExactly the same values.\r\n\r\nThe 03-000C reports zero. This could be the counter for daily consumption, or the grand total. As my mi home app reports those two fields as zero.\r\n"}}
{"actor":{"display_login":"rtenklooster"}}