Zigbee binding

Add-ons Bindings
,
1345

Are there any known issues with atmospheric pressure sensors? About once a day I’m seeing it jump to 100x what it should be, then back to normal on the next reading. eg 100040.0 instead of 1000.4 hPa.

This is with the Xiaomi square sensor, so it’s probably just cheap junk :roll_eyes: but even if that’s the case could the binding potentially detect and fix (or drop) these obviously-wrong messages? Maybe a range of acceptable values per-channel as a simple sanity check, although that might be better-handled elsewhere in OH rather than the binding.

1346

If you can capture a debug log I’ll have a look. The pressure sensor cluster is a little complex as there are multiple attributes and scaling is sent separately. These Xiaomi devices do report both sets of attributes and the binding will use the new set if it sees it - maybe there is a problem in there somewhere (although I’ve not seen this here)

1347

Hey @chris :slight_smile: Thanks for working on these bindings!

I just tried them out yesterday with a Qivicon Stick that is recognized via the Telegesis coordinator. Recognizing my OSRAM RGBW Bulb worked fine, but my Innr E27 RGBW bulbs are recognized as “unknown” and don’t react to anything.

In the wiki, there is a note that Innr Bulbs might have trouble with Telegesis, so I guess this is a known problem and I will need another stick?

Also another question: Does this binding somehow allow restoring the state of lamps when they join the network again (e.g. were switched off and back on physically)?

Thanks a lot!

1348

I think I’ve also seen this with the Telegesis dongle. These are ZLL bulbs, and for some reason the Telegesis doesn’t like them.

Correct.

What do you mean by “restoring the state”? They should work once powered on if that’s what you mean?

1349

They work once powered on, but if they were in a dimmed or colored state, they don’t assume that state again, but just go back into “some” white state. Other systems (like the one I am trying to replace right now) have an option per device to make the device go back into the last state (e.g. if it was red when turned off physically, it will be red again when turned on). This is of course visible because it takes a second or so for the system to send the command again.

1350

No, this isn’t something that is supported. The bulbs don’t do this natively, and the binding doesn’t have this feature built in. It’s something that I think should not be in the binding, but I can see why it is something that is desirable.

Normally when devices rejoin the network after being powered off, they send an “announce” message, and I guess that your other system is responding to this. I think at the moment this is not notified to the binding, but maybe I can change this, and the binding could poll the devices state, and you could have a rule to reset it?

Or maybe you can convince me to add the functionality to the binding :slight_smile: . My reasoning for keeping it out of the binding is I prefer to keep the binding as stateless as possible and keep any logic in rules, or in the core. However if other systems do this natively (eg Hue) then maybe there’s a case for also doing it in the binding here…

1351

I am relatively new to OpenHAB so I don’t know how easy the first approach is. Is it easy to make a rule that will set the device back to the last state that was known when they were turned off (instead of sending some “fixed” state)? If so, that sounds like the better solution to me.

If this is not easily possible, then I would suggest to add it to the binding because it is functionality that many existing systems provide and there is good reason to provide it. Some people (including me), use native power switches combined with soft switches. Accidentally switching the lamp off with the native switch and then back on and ending up in glaring white light at night isn’t a great experience :wink: Some people also use the native switches to switch lamps off for a longer time because they consume substantial amounts of power when soft-switched off.

If you could implement it, that would of course be great and I think it would be a great feature on the way to having OpenHAB in a position where it can easily contest existing systems like Homee, DECONZ, etc.

1352

Do you know if systems like Hue, Tradfri, etc provide this in their hub?

1353

Hue is planning to support it I think (but in the bulbs), Tradfri does not support it right now. Some Googling reveals that this is a big issue for many people, mostly for the reasons I outlined already (glaring bright default light, also after power outage. Think about a short power outage, then all the lights turn on by default.). Homee supports it (can be enabled per device) and from what I could find in the FAQ, Phoscon also supports it by default.

1354

Thanks. Clearly the best thing is to support it in the bulbs, but that of course doesn’t help people now :wink:

I wonder if Hue are going to support it in their new bulbs, if they will add some support in the bridge to support older bulbs…

Anyway, I can fully appreciate the utility of this - no question there. My only question is if this is something that should be in the binding, or (somehow!) covered externally. Doing it externally is not necessarily simple I think. If the bulb was offline, then you could trigger a rule based on the thing status change, but if you accidentally turn off a bulb and then immediately power it back on, the binding would not detect that it was offline, so the rule system would not work here.

Please can you open an issue, explaining the problem (cut and paste what you have above) and I will have a think about this - I think it might not be too hard to add.

1355

I agree that this mainly only works if the hardware supports it.
FTR, LIFX does and therefore there’s a configuration parameter on the channel through which the user can define the desired behavior upon an “ON” command.

1356

That was also my thinking, but I definitely see the utility here. For it to be done in rules, there would need to be a trigger that notified the user the device has rejoined the network - I guess we could add such a channel?

1357

Done: Support restoring state of bulbs on reconnect · Issue #261 · openhab/org.openhab.binding.zigbee · GitHub

Thanks for looking into this! Meanwhile, I ordered another stick, I hope it is the right one.

1358

What one did you order?

1359

That’s the hard thing :wink: On the picture it says it is the Bitronvideo one (that should use the Ember coordinator according to the wiki). But I wouldn’t be surprised if they deviated from that and send me another Qivicon. Unfortunately, it is often really hard to find technical specifications (in the German shops here) that say exactly what kind of stick it is. A bit of roulette… maybe I should check eBay afterwards if this doesn’t work out.

1360

I think this has the Ember chip inside - I think I have one somewhere, but it’s another DT branded special, so comes with non-standard USB product codes. If you got the Qivicon stick to work (presumably on Linux?) then you will probably be able to get this to work… I’m not sure what version of the firmware it has, or if it has a bootloader to allow upgrades, so I’d welcome any feedback :slight_smile:

1361

Yes, I use openhabian on my RaspPI. I’ll be glad to provide feedback once I have it and thanks for the support!

1362

Hi,

Have you tested with CC2538 and CC2650 boards ?

If yes, then please provide the steps(with flashing tool, download links, document links) to make it work with openhab.

Thanks.

1363

I was able to capture the pressure issue, along with the previous & next successful updates. Log is on dropbox. I think this is the relevant part:

2018-09-17 16:57:45.867 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 52 58 3A 35 43 42 39 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 34 30 32 2C 30 38 3A 18 F4 0A 00 00 29 57 06 2C 2D 33 30 2C 45 33
2018-09-17 16:57:45.867 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=23737, profileId=260, destinationEp=1, sourceEp=1, clusterId=1026, messageData=18 F4 0A 00 00 29 57 06, rssi=-48, lqi=227]
2018-09-17 16:57:45.868 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=23737/1, destinationAddress=0/1, profile=0104, cluster=1026, addressMode=null, radius=0, sequence=0, payload=18 F4 0A 00 00 29 57 06]
2018-09-17 16:57:45.868 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=244, commandId=10]
2018-09-17 16:57:45.868 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Temperature measurement: 23737/1 -> 0/1, cluster=0402, TID=F4, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=1623]]
2018-09-17 16:57:45.869 [DEBUG] [converter.ZigBeeConverterTemperature] - 00158D000245DCB2: ZigBee attribute reports ZclAttribute [cluster=TEMPERATURE_MEASUREMENT, id=0, name=MeasuredValue, dataType=SIGNED_16_BIT_INTEGER, lastValue=1623, lastReportTime=Mon Sep 17 16:57:45 NDT 2018]
2018-09-17 16:57:45.869 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 23737: NWK Discovery scheduling node discovery
2018-09-17 16:57:45.869 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 52 58 3A 35 43 42 39 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 34 30 35 2C 30 38 3A 18 F5 0A 00 00 21 83 1D 2C 2D 33 30 2C 45 37
2018-09-17 16:57:45.869 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D000245DCB2: Channel zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_temperature updated to 16.23 ℃
2018-09-17 16:57:45.869 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 23737: NWK Discovery starting node discovery
2018-09-17 16:57:45.869 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=23737, profileId=260, destinationEp=1, sourceEp=1, clusterId=1029, messageData=18 F5 0A 00 00 21 83 1D, rssi=-48, lqi=231]
2018-09-17 16:57:45.869 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D000245DCB2: Updating ZigBee channel state zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_temperature to 16.23 ℃
2018-09-17 16:57:45.869 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 23737/0, cluster=0001, TID=CB, nwkAddrOfInterest=23737, requestType=1, startIndex=0]
2018-09-17 16:57:45.869 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=23737/1, destinationAddress=0/1, profile=0104, cluster=1029, addressMode=null, radius=0, sequence=0, payload=18 F5 0A 00 00 21 83 1D]
2018-09-17 16:57:45.869 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=23737/0, profile=0000, cluster=1, addressMode=DEVICE, radius=31, sequence=203, payload=00 B9 5C 01 00]
2018-09-17 16:57:45.869 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=245, commandId=10]
2018-09-17 16:57:45.869 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Relative humidity measurement: 23737/1 -> 0/1, cluster=0405, TID=F5, reports=[Attribute Report: attributeDataType=UNSIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=7555]]
2018-09-17 16:57:45.869 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=23737, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 B9 5C 01 00, messageId=null]
2018-09-17 16:57:45.870 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2018-09-17 16:57:45.870 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisSendUnicastCommand [address=23737, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 B9 5C 01 00, messageId=null]
2018-09-17 16:57:45.872 [DEBUG] [rter.ZigBeeConverterRelativeHumidity] - 00158D000245DCB2: ZigBee attribute reports ZclAttribute [cluster=RELATIVE_HUMIDITY_MEASUREMENT, id=0, name=MeasuredValue, dataType=UNSIGNED_16_BIT_INTEGER, lastValue=7555, lastReportTime=Mon Sep 17 16:57:45 NDT 2018]
2018-09-17 16:57:45.872 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis Data: 41 54 2B 53 45 4E 44 55 43 41 53 54 42 3A 30 35 2C 35 43 42 39 2C 30 30 2C 30 30 2C 30 30 30 30 2C 30 30 30 31 0D 00 B9 5C 01 00 0D 0A
2018-09-17 16:57:45.872 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D000245DCB2: Channel zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_relativehumidity updated to 75.55
2018-09-17 16:57:45.872 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D000245DCB2: Updating ZigBee channel state zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_relativehumidity to 75.55
2018-09-17 16:57:45.872 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 52 58 3A 35 43 42 39 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 34 30 33 2C 31 31 3A 18 F6 0A 00 00 29 E0 03 14 00 28 FF 10 00 29 C2 26 2C 2D 33 30 2C 45 42
2018-09-17 16:57:45.873 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=23737, profileId=260, destinationEp=1, sourceEp=1, clusterId=1027, messageData=18 F6 0A 00 00 29 E0 03 14 00 28 FF 10 00 29 C2 26, rssi=-48, lqi=235]
2018-09-17 16:57:45.873 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=23737/1, destinationAddress=0/1, profile=0104, cluster=1027, addressMode=null, radius=0, sequence=0, payload=18 F6 0A 00 00 29 E0 03 14 00 28 FF 10 00 29 C2 26]
2018-09-17 16:57:45.873 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=246, commandId=10]
2018-09-17 16:57:45.874 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Pressure measurement: 23737/1 -> 0/1, cluster=0403, TID=F6, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=992, Attribute Report: attributeDataType=SIGNED_8_BIT_INTEGER, attributeIdentifier=20, attributeValue=-1, Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=16, attributeValue=9922]]
2018-09-17 16:57:45.874 [DEBUG] [r.ZigBeeConverterAtmosphericPressure] - 00158D000245DCB2: ZigBee attribute reports ZclAttribute [cluster=PRESSURE_MEASUREMENT, id=0, name=MeasuredValue, dataType=SIGNED_16_BIT_INTEGER, lastValue=992, lastReportTime=Mon Sep 17 16:57:45 NDT 2018]
2018-09-17 16:57:45.875 [DEBUG] [r.ZigBeeConverterAtmosphericPressure] - 00158D000245DCB2: ZigBee attribute reports ZclAttribute [cluster=PRESSURE_MEASUREMENT, id=16, name=ScaledValue, dataType=SIGNED_16_BIT_INTEGER, lastValue=9922, lastReportTime=Mon Sep 17 16:57:45 NDT 2018]
2018-09-17 16:57:45.875 [DEBUG] [r.ZigBeeConverterAtmosphericPressure] - 00158D000245DCB2: ZigBee attribute reports ZclAttribute [cluster=PRESSURE_MEASUREMENT, id=20, name=Scale, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=-1, lastReportTime=Mon Sep 17 16:57:45 NDT 2018]
2018-09-17 16:57:45.875 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D000245DCB2: Channel zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_pressure updated to 9.922E+4 hPa
2018-09-17 16:57:45.875 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D000245DCB2: Updating ZigBee channel state zigbee:device:f43788ef:00158d000245dcb2:00158D000245DCB2_1_measurement_pressure to 9.922E+4 hPa
2018-09-17 16:57:46.008 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 53 45 51 3A 36 30
2018-09-17 16:57:46.008 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis Data: 4F 4B
2018-09-17 16:57:46.008 [DEBUG] [gesis.internal.TelegesisFrameHandler] - RX Telegesis: TelegesisSendUnicastCommand [address=23737, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 B9 5C 01 00, messageId=96, status=SUCCESS]
1364

Thanks. Is this happening after the binding has restarted or something? I think I can see what is happening, but I think it only makes sense if the converter got restarted.