deCONZ enhancements for IAS devices

[ebaauw]

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).

I'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.

1. 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.
2. 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?
3. 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.
4. 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.
5. 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?
6. 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?
7. 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...
8. 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.
9. 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?
10. 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 ZHAPowerwith astate.powerattribute? Or would we simply exposestate.poweras additional attribute to the/lightsresource? The OSRAM plug reports value 28000 when no power is drawn instead of 0, so we might need access to thestate.onattribute to map 28000 it to 0 whenstate.on` is false. The plug is rated for over 3000W, so I suspect 28000 could be a valid value as well.
11. 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.
12. 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 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?

[manup]

Wow cool, that's a very helpful detailed list. For some points I'm not sure yet how to handle these cases, but here are some thoughts:

1. 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.

The double usage of config.duration becomes more confusing to me. Maybe we should use something more explicit for the purpose of clearing after inactivity like config.autoclear which accepts integer or 0 (off)?

2. 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?

I think this also falls into the /devices endpoint consideration (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/269 to which I will write some thoughts later soon).

Where possible I would not expose too much ZigBee specifics to the REST-API, devices too often provide 'bad' attributes which are not useful for the API user. Like in this case if we know for specific manufacturername and modelid we can provide a meaningful attribute like gas or more generic measuredvalue and provide a valuetype like 'combustable gas' or 'carbon-monoxide gas'?

3. 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.

Agree, the Climax sensors also provide tamper and battery alarm flags which are currently not exposed. I would prefer the state.alarm, state.tamper, state.battery approach since it's on a higher level and doesn't expose the ZigBee internals.

4. 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.

ACK :)

5. 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?

Yes, general.xml is currently not suitable for that, handles only classic bits and enums.

6. 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?

Related to https://github.com/dresden-elektronik/deconz-rest-plugin/issues/269

9. 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?

To be honest I haven't found a official list for those. I did just google the codes in the past.

10. 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 ZHAPowerwith astate.powerattribute? Or would we simply exposestate.poweras additional attribute to the/lightsresource? The OSRAM plug reports value 28000 when no power is drawn instead of 0, so we might need access to thestate.onattribute to map 28000 it to 0 whenstate.on` is false. The plug is rated for over 3000W, so I suspect 28000 could be a valid value as well.

I like the exposestate.poweras approach to keep it simple.

11. 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:

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?

When I remember correctly it provides both clusters, I need to check it.

[ebaauw]

7. Hacked something into general.xml, see attached general.xml.gz. I can now control the siren from the deCONZ GUI.
   I can set Max duration and issue a Start warning. It doesn't seem to act differently for different values of Siren, Strobe and Squawk level. It only seems to distinguish between Warning Mode 0b0000 (stop) and other values (as in silent vs scaring the shit out of me). It seems to support Strobe, Warning duration, and Strobe duty cycle in full. Also the Sqawk command incl. Strobe and Sound for disarmed seem to work. The IAS WD on the Smoke sensor seems inoperable - I cannot get it to do anything, so even setting Max duration, while poking the reset button to wake the sensor. @rtenklooster, could you see if this works for you as well?

8. While at it, added the multiplier and divisor (as well as the Smart plug device type) to general.xml. Indeed, deciWatts. Interestingly, it doesn't advertise that it supports anything in attribute 0x0000, but 0x050b changes when power is drawn. It doesn't support Reporting on this attribute, though, so it needs to be polled (another reason to keep treating it as a light). Same for the OSRAM plugs and my ubisys dimmer. Haven't yet installed the new general.xml to my production environment, so don't yet know what these report for 0x0605.

[manup]

Nice, I wonder how the sound of this siren is :)

Shall I merge your gerneral.xml into the next release?

Note to myself: move general.xml from core into the rest-plugin git repo.

[ebaauw]

Nice, I wonder how the sound of this siren is :)

It's really loud, you can probably hear it in Dresden when I'm sounding it in Amsterdam.

Shall I merge your gerneral.xml into the next release?

Did some more changes (all the Electrical Measurement attribute that the ubisys dimmer exposes). general.xml.gz

Note to myself: move general.xml from core into the rest-plugin git repo.

Cool! Is there a reason it uses \r\n as newlines? Or is it just the editor you're using? Maybe consider changing it to a json file for easier maintenance?

[rtenklooster]

Okay. Just upgraded to the latest version. Used your general.xml. The Xiami Smart power plug:

So the power consumption is working great. It's changing instantly.

[ebaauw]

Huh? It's reporting power consumption though the Analog Input cluster? Which endpoint? In Watts?

[rtenklooster]

Yes it is. 02 -> 000C And yes, it's in watts. I have double checked the readings from within the mi home app. Exactly the same values. I have double checked my Excel form listed here As you can see on line 57.

The 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. I will keep my notebook connected during the night. Let's see if it's changing during the night.

The Smoke detector however is only reporting the 01-0000 basic cluster. It should report endpoint 01 cluster 0x0500

[AntiHeld889]

is it possible to add the power consumption in homebridge-hue-plugin? to show the consumption in the eve App?

[ebaauw]

Yes, but we need to support it in deCONZ first.

[ebaauw]

Everything should be supported in v2.05.04, see https://github.com/dresden-elektronik/deconz-rest-plugin/pull/420, except for the Siren and for setting the siren duration in the Fire sensor.

Some updates:

7. The Fire sensor allows setting Max Duration through the IAS WD cluster. In theory, this could be exposed as config.maxduration, and set through config.pending, but I see little value and a whole lot of work;
8. The Heiman does support attribute reporting for Active Power. The OSRAMs don't. Also, they don't support the Mulitplier nor Divisor attributes. They report 28000 when they're off and 400 when they're on, regardless of whether power is actually drawn.

For further discussions on state.power, please see #423.

[ebaauw]

is it possible to add the power consumption in homebridge-hue-plugin? to show the consumption in the eve App?

homebridge-hue@0.6.5 in combination with deCONZ 2.05.04. Note that the OSRAM plugs report nothing useful.

[wvuyk]

It seems the xiaomi power plug is not yet forwarded to the REST API? Will this be possible?

[ebaauw]

I think it will be, but, being Xiaomi, they report power consumption in a non-traditional way, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/153.

[wvuyk]

It is not yet visible in the rest api, maybe I was unclear? the power consumption reporting would be a nice to have with it, not major priority on that yet.

[to0b]

I’ve added successfully a heiman smoke sensor to deCONZ. When does the tempered indicator occur? I’ve released the sensor from the base plate but the tempered flag doesn’t change.

[ebaauw]

Same here (and same for the CO sensor). I thought the small button being pressed when the sensor is attached to the base plate would be a tamper detection switch (like for the door and for the water sensor), but it doesn't seem to do anything. It's also held down by the battery, but if you remove the battery the sensor goes dead.

I'm not sure if the lowbattery alarm works for the smoke and for the CO sensor either - I don't have an almost depleted battery of this type to test.

[to0b]

OK thanks for the information. When there are a few smoke sensors connected and one sensor detects smoke, do the others make also noise?

[ebaauw]

I don't know for sure, I only have one on loan. I don't think they can do that, though - I haven't been able to find a way to activate the siren (or flash) remotely.

[Oggymator]

talked today with Heiman, not possible to activate the siren of CO, smoke and Gas sensor by remote.

[ebaauw]

@manup I'm thinking about maybe exposing the Siren as a light, using some new values for state.alert to activate the siren, strobe, or both. You can set these, but the Siren doesn't report the actual status back, so this would seems like the most appropriate match. However, would it be wise (or even possible) to create a light without state.on? I could imagine many applications not liking that. Also, there's a max duration attribute, which would better be exposed through config, which we don't have for lights. Maybe a ZHAAlert with settable state.alert would be more appropriate? The state attribute of CLIP sensors can also be updated through the REST API, so it's not completely unheard of. It wouldn't expose state.lastupdated though.

[manup]

However, would it be wise (or even possible) to create a light without state.on? I could imagine many applications not liking that.

Yes I imagine some applications might even crash assuming the state.on attribute to be there.

I'm still very lean towards to this /devices endpoint thing, here is a example which might reflect the siren:

 GET /devices

    {
        "00:21:2e:ff:ff:00:11:80-07-0500" : {

            "name": "Bob",
            "type": "Warning device",
            "modelid": "SIR-3000",
            "manufacturername": "Lego",
            "state": {
                "alert": "strobe",
                "reachable": true,
                "lastupdated": "2018-02-27T19:42:19"
            },
            "config": {
                "maxduration": 300
            }
        }
    }

To sum it up in C++ it would be:

• RActor (?)
• RAttrUniqueId, RAttrName, RAttrType, RModelId, ...
• RStateAlert, RStateLastUpdated
• RConfigMaxDuration

[ebaauw]

The double usage of config.duration becomes more confusing to me. Maybe we should use something more explicit for the purpose of clearing after inactivity like config.autoclear which accepts integer or 0 (off)?

Yes it's confusing, mea culpa, at least partly. There's different ZigBee mappings for config.duration, see also #317. In historical order:

1. No ZigBee mapping at all (e.g. motion sensors based on IAS Zone, and CLIPPresence sensors);
2. The PIR Occupied to Unoccupied Delay attribute of the Occupancy sensing cluster (e.g. Hue motion sensor);
3. The On Time parameter of the On with timed off command of the OnOff cluster (e.g. Trådfri motion sensor);

The other confusing part is that there's two different types of motion sensors:

• A. Those that only report motion detected (e.g. the Trådfri motion sensor, motion sensors based on IAS Zone, without the Restore reports set in the Zone status);
• B. Those that report both motion detected and motion no longer detected (e.g. the Hue motion sensor, and motion sensors based on IAS Zone, with Restore reports set in the Zone status like Heiman);

Combining these two aspects, we get the following cases:

• A1 (motion sensors from before my time (I assume), CLIPPresence where state.presence isn't reset explicitly, Trådfri motion sensor, when controlling lights through rules): deCONZ should reset state.presence to false automatically, after config.duration seconds;
• A3 (Trådfri motion sensor, when controlling lights directly using config.group): The lights will turn themselves off after On Time seconds (configured through the dial on the sensor). Arguably, deCONZ should turn off state.presence at the same time to match the light states. To enable this, I (ab)used config.duration to reflect On Time, making it read-only;
• B1: (Heiman motion sensor, CLIPPresence where state.presence is reset explicitly): config.duration only exists in the REST API. Arguably, deCONZ should delay setting state.presence to false, config.duration seconds after it receives the report that motion is no longer detected. Alternatively, don't expose config.duration for these type of sensors, set state.presence to false on receiving the report that motion is no longer detected, and tell people to use a rule with a ddx condition instead;
• B2: Hue motion sensor (B2): config.duration is mapped to PIR Occupied to Unoccupied Delay causing the sensor to delay the notification of Occupancy false, after it no longer detects motion. deCONZ should set state.presence to false when it receives the report that Occupancy is 0, irrespective of the value of config.duration.

I think it makes a lot of sense to:

• Use a different config attribute, let's call it delay, for B2 (read-write) and A3 (read-only);
• Reserve config.duration for automatically resetting state.presence to false after receiving the motion detected report;

This would lead to the following:

• Hue motion sensor: only config.delay, no automatic resetting of state.presence to false;
• Trådfri motion sensor: both config.delay and config.duration. If config.duration > 0, reset state.presence to false after config.duration seconds, otherwise reset state.presence to false after config.delay seconds;
• Others (incl. CLIPPresence): only config.duration. If config.duration > 0, reset state.presence to false after config.duration seconds, and ignore any motion no longer detected reports; otherwise honour the motion no longer detected report and no automatic resetting of state.presence to false.

[manup]

• Use a different config attribute, let's call it delay, for B2 (read-write) and A3 (read-only);

B2 includes two more devices working similar as the hue motion sensor by using PIR Occupied to Unoccupied Delay — the FLS-NB1 and FLS-NB2 these are special combined (mains-powered) sensor-lights which also ZCL report the presence state.

If configured via binding to a group they further send On with timed off commands like the IKEA sensor, but here the OnTime parameter is dynamic and contains the remaining time, since the command is send every x seconds, it should be ignored and only state.presence will be set to true, if not already set to true by a prior report. The FLS-NBx devices are already fully implemented it's very important that they keep working when we modify the implementation. :)

The extra config.delay attribute is a good idea we should do that. The recent implementation does reset state.presence only if the ZCL reports aren't received for some time (based on max report interval) so it shouldn't interfere in normal operation mode.

• Trådfri motion sensor: both config.delay and config.duration. If config.duration > 0, reset state.presence to false after config.duration seconds, otherwise reset state.presence to false after config.delay seconds;

Agree, that should work for all uses cases we had seen in the past for the sensor.

• Others (incl. CLIPPresence): only config.duration. If config.duration > 0, reset state.presence to false after config.duration seconds, and ignore any motion no longer detected reports; otherwise honour the motion no longer detected report and no automatic resetting of state.presence to false.

Agree

[jsponz]

Hi,

I have just bought the Siren module. Could you help me with the pairing?

Thanks a lot! Jorge

[ebaauw]

You need to reset the Siren by (I think) pressing and holding the reset hole for 5+ seconds. The SIren should react to indicate it's been reset. Then open the network from the web app or Phoscon, and briefly press the reset hole on the Siren. It should appear in the GUI.

For now, you can only control the Siren from the GUI. The REST API creates a ZHAAlarm and a ZHAWarning resource, but neither of these does anything yet.

[jsponz]

Thanks! Quick answer. Where should it appear? Should I click on "Add new..."

[oleg77s]

@ebaauw , what can you say about Heiman HS1RC Smart Remote Control

and Heiman HS1EB Smart Emergency Button ?

[Oggymator]

I don’t like these remotes, battery life is bad.

Normally it is used for the Heiman Secrurity Gateway to arm and disarm without smartphone.

Don’t think is very useful for HomeKit

[ebaauw]

what can you say about Heiman HS1RC Smart Remote Control and Heiman HS1EB Smart Emergency Button?

I'd expect these to be IAS Zone devices, just like most of the other Heiman sensors. If you can provide me screenshots, adding support shouldn't be too difficult. Probably best to expose them as ZHASwitch and issue appropriate buttonevents for press/release of each/the button.

Where should it [the Siren] appear? Should I click on "Add new..."

Yes, Add new... in the Phoscon app. It will not appear there, though. You need to check the deCONZ GUI and/or the REST API for a new ZHAAlarm and ZHAWarning resource.

[wvuyk]

I have added the Xiaomi smoke sensor today here. Am I right assuming there is no battery information yet on this Xiaomi device?

[ebaauw]

Looking at the code, deCONZ (v2.05.10 or later) should create config.battery for the Xiaomi smoke sensor as well. I think/hope @manup cracked the Xiaomi magic enough to get the battery value for all Xiaomi devices that report it.

[wvuyk]

So maybe it is not reporting it yet here... At least the battery value is not changed from 0, I would doubt it is still 0. Installed it this morning, normally the value gets populated after a while?

{ "ep": 1, "etag": "8f7ee3071feaa4288a5f1bd82b2e538b", "state": { "lastupdated": "2018-03-08T08:47:17", "fire": false, "lowbattery": false, "tampered": false }, "config": { "on": true, "battery": 0, "reachable": false }, "name": "Brand alarm", "type": "ZHAFire", "modelid": "lumi.sensor_smoke", "manufacturername": "LUMI", "uniqueid": "00:15:8d:00:01:d7:05:20-01-0500" }

[ebaauw]

Maybe the smoke sensor works differently. Does config.battery get populated when you press the reset button? Do you see messages in the deCONZ log (I think these are --dbg-info=1):

Mar 08 20:29:40 pi2 deCONZ[22580]: 20:29:38:988 0x00158D0001xxxxxx skip Xiaomi attribute 0x0005
Mar 08 20:29:40 pi2 deCONZ[22580]: 20:29:38:988 0x00158D0001xxxxxx extract Xiaomi special

[wvuyk]

I have reset it several times by now, did a few extra jast now. Battery stays at 0. Honestly, I am a disaster when it comes to Linux... I never found the log yet here!

[ebaauw]

journalctl -au deconz or journalctl -au deconz-gui, depending on which service you're running.

[wvuyk]

There is not much helpfull in there Eric...

Mar 08 19:46:16 raspberrypi systemd[1]: [/etc/systemd/system/deconz-gui.service:12] Unknown lvalue 'AmbientCapabilities' in Mar 08 19:46:16 raspberrypi systemd[1]: Starting deCONZ: ZigBee gateway -- GUI/REST API... Mar 08 19:46:16 raspberrypi systemd[1]: Started deCONZ: ZigBee gateway -- GUI/REST API. Mar 08 19:46:18 raspberrypi deCONZ[1323]: libEGL warning: DRI2: failed to authenticate

[ebaauw]

Looks like you’re running deCONZ without any of the debuging enabled. You need to add --dbg-info=1 to the service definition file, /etc/systemd/system/deconz-gui.service. That would involve some serious Linux interaction...

[ebaauw]

Added support for the Heiman siren. It's exposed as a /lights resource (for the _IASWD cluster 0x0502), and as a /sensors resource (for the _IASZone cluster, 0x0500).

The light is for controlling the siren, using the following values for state.alert:

• "none": turn off the alarm:
• "select": turn on the siren and strobe light for 1 second;
• "lselect": turn on the siren and strobe light for 5 minutes;
• "blink": turn on the strobe light for 5 minutes.

Note that you can limit the maximum alarm time by writing the Max Duration attribute in the IAS WD cluster through the deCONZ GUI. This attribute isn't exposed by the REST API.

The sensor is mainly for reporting the level of the (backup) battery and checking that the siren is reachable. It does send supervision reports after manually enrolling it in the deCONZ GUI, but I haven't seen any alarm (not even a low battery alarm when the siren was disconnected from mains power and backup battery was down to 4%).

For reference, here's the light resource:

{
  "etag": "830aad9771beb8394cad8cd4c63f8624",
  "hascolor": false,
  "manufacturername": "Heiman",
  "modelid": "WarningDevice",
  "name": "Siren",
  "state": {
    "alert": "none",
    "reachable": true
  },
  "swversion": null,
  "type": "Warning device",
  "uniqueid": "00:0d:6f:00:0b:xx:xx:xx-01"
}

And here's the sensor resource:

{
  "config": {
    "battery": 100,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "36b57b448301a606bdd5b80422232b94",
  "manufacturername": "Heiman",
  "modelid": "WarningDevice",
  "name": "Siren",
  "state": {
    "alarm": false,
    "lastupdated": "2018-03-11T14:47:33",
    "lowbattery": false,
    "tampered": false
  },
  "swversion": "2017.9.27",
  "type": "ZHAAlarm",
  "uniqueid": "00:0d:6f:00:0b:xx:xx:xx-01-0500"
}

Some other remarks:

• The swversion for the sensor is actually the Date Code; for the light it's empty (null instead of "", I think that's part of the Daylight changes). @manup, I think the logic to use the Date Code when SW Build ID isn't supported is still missing from lights?
• The siren reports value 0x81 for the Power Source (0x0007) attribute of the Basic cluster. This value is missing from general.xml. @manup, can you please add the following line:

  <value name="Mains (single phase) with battery backup" value="0x81"></value>

• I removed state.on from the light resource, as it's not doing anything. I'm not sure if all REST API clients will handle a light without state.on correctly.

[manup]

The swversion for the sensor is actually the Date Code; for the light it's empty (null instead of "", I think that's part of the Daylight changes). @manup, I think the logic to use the Date Code when SW Build ID isn't supported is still missing from lights?

Yes needs to be added, when I recall correctly ubisys also doesn't support that or returns a empty string.

This value is missing from general.xml. @manup, can you please add the following line:

It's in 2.05.12

I removed state.on from the light resource, as it's not doing anything. I'm not sure if all REST API clients will handle a light without state.on correctly.

Shouldn't be a problem I guess it wasn't used much or at all.

[ebaauw]

when I recall correctly ubisys also doesn't support that

Correct.

It's in 2.05.12

Yeah, saw that. Thanks!

Shouldn't be a problem I guess it wasn't used much or at all.

state.on for a light, not config.on for a sensor. The latter still needs to be implemented, by the way (blocking any update to state attributes). I don't use it myself, but I do expose it to HomeKit. It's being used by quite a few of my users, e.g. to disable a Hue-bridge connected Hue motion sensor sensor at night. I use a CLIPGenericStatus for that, in combination with some gateway rules, so the motion still registers, but the lights don't turn on.

[manup]

Ahh I see thought it was config.on yes this might break some apps since they almost always expect the on attribute. I need to check Phoscon App :) If it causes issues in other apps a dummy state.on should be fine.

[ZacGrose]

I've got a Swann siren (it appears to actually be manufactured by Climax Technology), which can be controlled in deCONZ GUI, similar to ebaauw's earlier comment. However, nothing I do can make it appear is a light or a sensor in the web app. Am I doing something wrong? Or else, would it be possible to get support for the Swann/Climax siren too?

[ebaauw]

Could you please also post screenshots of the node and its clusters and of the Node Info panel? Is it battery powered?

[ZacGrose]

Sure — attached below.

[ebaauw]

Thanks. Sensors need to be whitelisted. As the siren is battery powered, it needs to be whitelisted for the light resource as well. I’ll have a look this weekend.

[ithinkcode]

@ebaauw I recently got my hands on a few conbees and i am in the process of moving my zigbee2mqtt deployment over. Any thoughts on the Heiman Motion sensor performance ? I have been using Xiaomi Mijia sensors and they have a blind spot of about 2 mins during which new motion is undetected ? Do you know if Heiman suffers from this issue as well ? Thanks in advance!

[ebaauw]

Sorry, I don’t know.

[nebukadezza]

Dear ebaauw, all, had any of you paired a Heiman HS1CA-N monoxide sensor with deCONZ succesfully? Meanwhile sensor search is active in Phoscon I enabled network search on the monoxide sensor but it's not visible on the UI nor the sensor indicates any found host. Same results if the sensor is restarted by battery removal, not doing anything with it during the search. Thank you for comments in advance, Cheers

[xhemp]

@ZacGrose Are you still using your SwannOne siren? Is it working as intended? I am having some issues with mine, just wondering if we can chat about it. Thanks!