Zigbee binding

[puzzle-star (Pedro Garcia)]

Hi @chris,

@chris

I much prefer to use the standard XML system - it ensures that people can use this without being technical.

But is there (or could be) a way for a user to place these xmls out of the jar, so that a device can be supported even if not part of the official distribution?

@chris

many users of the binding are not using OH even.

Now I am lost. Isn’t the binding specific for openhab? (not speaking of the zsmartsystems part, just about the org.openhab.binding.zigbee part)

@chris

puzzle-star:

• A configuration parameter on the standard device thing to prevent discovery from the binding (something like the zigbee_discovery=“false” )

chris:

What is the purpose of this, and what is it meant to actually stop? The binding really needs to do discovery or it doesn’t add devices into the binding

doNodeInitialization(): (being configStatic below the check on the config parameter)

         // Check if discovery is complete and we know all the services the node supports
-        if (!node.isDiscovered()) {
+        if (!configStatic && !node.isDiscovered()) {

Some devices (I agree, badly implemented ones, but they do exist anyway), do not respond too well (or at all) to discovery. The result of this is that, as the node.isDiscovered() check returns true only when the endpoints and node descriptor have been initialized, if for some reason this does not work (or does not work on a timely manner), such devices get into the system, but never go futher the isDiscovered check in the binding:

• Sleepy devices

• Devices not responding to some commands during discovery. Example: the discovery mecanism puts in a queue the discovery tasks. I have seen in the discovery task list the ROUTE discovery before the NODEDESCRIPTOR one (not sure it should be OK), so for END DEVICES it will stay forever retrying the ROUTE discovery… Maybe the issue is on the discovery process, and I should look at there instead

• Devices not responding at all (or hard to make to respond) to NodeDescriptor or EndPoints request (i.e. Aqara battery powered switches) due to being too “sleepy”

@chris

The binding really needs to do discovery or it doesn’t add devices into the binding

It does. I guarrantee (of course, with the hack above)… Again speaking of the org.openhab.binding.zigbee part, not of the zsmartystems part, and not speaking of disabling the discovery service or something like that: just the check above.

@chris

If we add support for a device, then it’s clearly available for everyone and no further configuration is required.

Probably I did not explain it correctly. What I mean is: yes, if support for a device is added, it will work. But how often will you be able to add new devices? With which frequency there is a new release ? And in three years, how often there will be a new release?

I mean, tying the release of newly supported devices that only need an xml to work, to the release cycle of the binding + OH, may not be sustainable over time, and probably some users would like to be able to add a new supported device by just dropping a xml somewhere, if not possible to configure it on the binding itself, without having to go to snapshot version.

@chris

I’ve created an initial PR to add this support to the XML. Somewhere I have one of these old Xiaomi temperature sensors, but I can’t find it to test with. If you like, please feel free to test it (it needs to discovery information added to the PR for testing

Will give it a try

Pedro

[chris (Chris Jackson)]

@puzzle-star

But is there (or could be) a way for a user to place these xmls out of the jar, so that a device can be supported even if not part of the official distribution?

This isn’t currently possible in ESH.

@puzzle-star

Now I am lost. Isn’t the binding specific for openhab? (not speaking of the zsmartsystems part, just about the org.openhab.binding.zigbee part)

There are many (most) users of OH that do not regularly access the forum, and there are other systems that use OH bindings.

@puzzle-star

But how often will you be able to add new devices?

As often as is needed. In ZWave, it’s normally twice per week, but if someone creates a PR to add a device, it can easily be added.

@puzzle-star

And in three years, how often there will be a new release?

The same - as often as people add the data to the binding. It’s controlled this way - if you’re getting at the fact that in 3 years no-one will be supporting this, then the binding will likely not work with new devices anyway. I simply don’t think this is an issue. If people aren’t working out the device information and publishing it somewhere, then it’s all irrelevant isn’t it?

@puzzle-star

I mean, tying the release of newly supported devices that only need an xml to work, to the release cycle of the binding + OH, may not be sustainable over time

I don’t understand. You’ve said that there will not be many such devices. I would like to think that in future, more devices will be more compliant. In any case, as I said above, for the past 3 years I’ve personally been doing updates to the ZWave binding a few times a week to add devices - it’s exactly the same.

This ensures the data and device support is available for everyone - not just those with the knowledge to work out how to add devices for themselves.

[puzzle-star (Pedro Garcia)]

@chris

This isn’t currently possible in ESH.

Then I understand why you do not like the idea

@chris

You’ve said that there will not be many such devices. I would like to think that in future, more devices will be more compliant. In any case, as I said above, for the past 3 years I’ve personally been doing updates to the ZWave binding a few times a week to add devices - it’s exactly the same.

This ensures the data and device support is available for everyone - not just those with the knowledge to work out how to add devices for themselves.

Fair enough

Will look anyway deeper into the discovery mechanism in the ZigBeeNode, as clicking the Xiami buttons for 3 minutes twice per second while looking at the logs till it goes through discovery is not very “user firendly…”

I think this could be optimized a bit, but will check if I can propose something “clean” and faster for discovery in general

[chris (Chris Jackson)]

@puzzle-star

I think this could be optimized a bit, but will check if I can propose something “clean” and faster for discovery in general

Thanks - I’m certainly open to ideas, and appreciate your input and thoughts .

[nibi79 (NB)]

I try to to start the binding with eclipse smarthome, windows 10 and CC2531 (COM4). When I set the port to ‘COM4’ in PaperUI I get the error message that the port doesn’t exist.
That’s the log when I launch openHAB_Runtime:

2018-09-14 18:12:21.886 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:435  ] - ZigBee network starting
2018-09-14 18:12:21.887 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:331  ] - Initialising ZigBee coordinator
2018-09-14 18:12:21.931 [DEBUG] [b.z.h.ZigBeeCoordinatorHandler:347  ] - Key initialise 5EF585BC0FC6AAB23371C521D6C5F136
2018-09-14 18:12:21.934 [DEBUG] [o.b.z.handler.ZigBeeSerialPort:122  ] - Connecting to serial port [COM4] at 115200 baud, flow control FLOWCONTROL_OUT_RTSCTS.
2018-09-14 18:12:21.961 [ERROR] [o.b.z.handler.ZigBeeSerialPort:151  ] - Serial Error: Port COM4 does not exist.
2018-09-14 18:12:21.962 [ERROR] [z.z.d.c.n.ZigBeeNetworkManager:305  ] - Failed to open the dongle.
2018-09-14 18:12:21.962 [DEBUG] [gBeeNetworkStateSerializerImpl:144  ] - Loading ZigBee network state: Start.
2018-09-14 18:12:21.969 [DEBUG] [gBeeNetworkStateSerializerImpl:182  ] - Loading ZigBee network state: Done.
2018-09-14 18:12:21.979 [INFO ] [ome.event.ThingStatusInfoEvent:53   ] - 'zigbee:coordinator_cc2531:2732c9b9' updated: OFFLINE: Failed to open communications port
2018-09-14 18:12:21.989 [INFO ] [nt.ThingStatusInfoChangedEvent:53   ] - 'zigbee:coordinator_cc2531:2732c9b9' changed from UNKNOWN to OFFLINE: Failed to open communications port

Any ideas what I’m doing wrong?

[tebore (JT)]

The 3rd Party Bluetooth binding found a way to support user provided XMLs outside of the binding.

3rd Party Bluetooth Binding. Beta testers needed

Hello community, I’m pleased to announce that a new binding for Bluetooth devices is available for betta testing. It was a long journey for me to build this binding - 1 year of hard work and 15k+ lines of code. Nevertheless this is just the beginning. Here are the main use cases this binding supports: Presence detection. Bluetooth devices can be monitored whether they are in range of a bluetooth adapter (or multiple bluetooth adapters). This feature makes it possible to detect if an object o…

[chris (Chris Jackson)]

@tebore

The 3rd Party Bluetooth binding found a way to support user provided XMLs outside of the binding.

3rd Party Bluetooth Binding. Beta testers needed 3rd Party

Can you provide a reference or link to how this works? Maybe it’s a different XML - ie not the ESH thing files?

[tebore (JT)]

sputnikdev/eclipse-smarthome-bluetooth-binding

It is a different XML.

Coles notes on how it works:
Create a directory and give the binding(OH) the ability to read it.
Create XML files with definition of how to interpret the raw readouts of the device.

Seems like a good compromise between 0 configuration and an option for those who are willing to do a little bit of legwork outside of standard support.

[chris (Chris Jackson)]

So this is a different system than ESH. We need to stick to standards and IMHO there is no benefit to this and it really makes a nightmare for support…

Let’s just do it properly so that things are supported for everyone.

[riven (Neil Ward)]

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

[chris (Chris Jackson)]

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)

[decoder (Chris)]

Hey @chris 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!

[chris (Chris Jackson)]

@decoder

but my Innr E27 RGBW bulbs are recognized as “unknown” and don’t react to anything.

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.

@decoder

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?

Correct.

@decoder

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

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

[decoder (Chris)]

@chris

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

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.

[chris (Chris Jackson)]

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

[decoder (Chris)]

@chris

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

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

[chris (Chris Jackson)]

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

[decoder (Chris)]

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.

[chris (Chris Jackson)]

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

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.

[Kai (Kai Kreuzer)]

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.