Zigbee binding

[Seaside]

I don’t own an aqara motion detector myself, but to me it sounds more like it is a configuration of the zigbee device to send an off message, at least if you look at the documentation on zigbee2mqtt.

Personally I prefer to send an off message myself using rules in openhab. I can then set a dynamic timeout, for instance a much shorter timeout during the nights.

/S

[chris (Chris Jackson)]

I don’t think there’s a configuration - some devices just don’t do this. I think there is an indicator in the one of the messages the binding receives during the initialisation to indicate if it will send the off, but the binding doesn’t do anything with this and it’s left up to the user to define the off in rules etc.

As you say - the rules approach provides more flexibility anyway…

[autossincool (Ralf)]

Hi all,

I have three questions:

1. I have the same behavior as astylianou.
   When I start a discovery and therefore broadcast a join to the network, the ROUTER devices are showing up neighbors and routes. After some time, the ROUTER devices doesnt show any neighbors or routes.

@chris

The mesh information that you show in these images does not necessarily mean that the network is not working. The coordinator manages the mesh - the binding does not have anything to do with this - it only provides this information periodically for information, but it does not update anything.

I understand the coordinator is managing the mesh and the binding is just displaying this information. What does that mean in this case?

2. How do I know if the END_DEVICE is connected to the COORDINATOR directly or to a ROUTER?
   Is this displayed as route on the END_DEVICE or on the ROUTER/COORDINATOR?

3. When does a device update/change their route?
   When a device joins the network (for the first time), the ROUTER with the best signal is taken, correct?
   Assuming the END_DEVICE is now moved to another room, does it change the route automatically? When does this happen?

[chris (Chris Jackson)]

@autossincool

I have the same behavior as astylianou.

I don’t know what you are referring to here? I can’t find any comments from such a user in an recent messages in this thread so it might pay to quote a message, so we can work out what your issue is - or actually explain your issue. Given I can’t find any recent messages (I looked back over hte past 6 months), it would also be useful to know what configuration you have (eg binding version, dongle type/version, and the device type that you are having problems with). This is all important to understand your issue - for example we know that Aqara devices don’t work well if they move - knowing what your device is will help us (or at least me ) to better help you.

@autossincool

How do I know if the END_DEVICE is connected to the COORDINATOR directly or to a ROUTER?

A ZED will only ever have one parent - it can change it the ZED is mobile, but generally it shouldn’t unless the link is poor. I don’t display the parent directly since in general this is not something someone needs to worry about, but you can look at the child tables of each router to see its children.

@autossincool

When does a device update/change their route?

Routes can change at any time. As I said above, a ZED will always be linked to a single parent since the parent needs to manage a ZED since it is normally sleeping (ie it’s a battery device). The route between the coordinator and the parent is controlled by the coordinator and can change based on link quality.

@autossincool

Assuming the END_DEVICE is now moved to another room, does it change the route automatically?

This gets complex. In such a case, it will likely change parent. What happens is the device will wake up and try and talk to its parent. This will likely fail - it will then leave the network, and try and rejoin by searching for a new parent. Route tables should then get updated as the parent will send out a notification to say that the device has moved. Again, this is managed through the coordinator.

[autossincool (Ralf)]

@chris

I don’t know what you are referring to here?

I was referring to post 2342/2343. I’m sorry I didn’t make myself clear. When I open the Paper-UI and check the neighbors or routes (for the coordinator, a router or end device) all of them are empty . The network is working fine, so no need to investigate in detail! I was just wondering why nothing is displayed here. After I started the Zigbee discovery, the neighbors and routes are displayed.
The Zigbee version I’m using is a snapshot from May 2020

@chris

…I don’t display the parent directly since in general this is not something someone needs to worry about, but you can look at the child tables of each router to see its children.

I guess here you are referring to zigbee_routes.

@chris

In such a case, it will likely change parent. What happens is the device will wake up and try and talk to its parent. This will likely fail - it will then leave the network, and try and rejoin by searching for a new parent. Route tables should then get updated as the parent will send out a notification to say that the device has moved.

Makes sense.Thank you now I understand

@chris

…for example we know that Aqara devices don’t work well if they move

Just for interest (as I have Aqara devices). This means if the Aqara devices wake up, they are not searching for a new parent, but stop reporting. To solve this, the Aqara device needs to be removed from the network and join again. This time the Aqara device would have a new parent - the router.

[curlyel]

Hi @chris ,
I’ve moved some Philips HUE bulbs to my new openHAB3 installation (3.1.0M1).
They joined immediately and I can adjust on/on, brightness via the color channel and colortemp via the ct channel.

But for some reason, a colorpicker is never popping up in standalone and list widgets. I simply can’t control the color of those bulbs via the MainUI.

Yes, the color channel is bound to a color item of course

Are you aware of that?

I’ve found an issue filed for the Deconz-binding which sounds similar to what I notice here:

[deCONZ] Can't control Items connected to Color Channels. Does not display Sliders or Colorpickers.

Is the issue and maybe the solution related to the Zigbee binding too?
Is that a general regression affecting all extended color lights in 3.1.0Milestone1?

I’ve removed the affected lights from the network and let them rejoin a couple of times. Always with the same (above) result: They join nicely and all except the color setting is working…

EDIT:
I’ve raised an issue meanwhile for asking if the issues are related:

[zigbee] Can't control Items connected to Color Channels. Does not display Sliders or Colorpickers

[chris (Chris Jackson)]

@curlyel

But for some reason, a colorpicker is never popping up in standalone and list widgets. I simply can’t control the color of those bulbs via the MainUI.

Strange - to me this sounds like a UI issue, but maybe something got changed in the definition. I don’t think the binding side has changed for a long time.

@curlyel

I’ve raised an issue meanwhile for asking if the issues are related:

I see you raised this in the addons repository? My guess is this is either a core issue, or a UI issue, or possibly a binding issue (but I dont think so as nothing changed there). Either way, this will likely not be the right place to raise the issue I think.

[curlyel]

@chris

sounds like a UI issue

I tended to agree at first.

But considering, what @cweitkamp did to solve the similar issue for the Deconz

[deconz] Use system default channel types for lights

to fix the extended colorlights in the Deconz addon binding, I wonder if we have a similar flaw in the Zigbee binding?

Admittedly, I don’t understand the fix and how that solved the issue for Deconz.

Maybe Christoph can shed some light on it to clarify if both issues might have the same root cause and therefore need a similar fix…

[J-N-K (Jan N. Klug)]

Be careful: [deCONZ] missing Brightness and On Time Channel on all things · Issue #10233 · openhab/openhab-addons · GitHub This might be the result.

[curlyel]

Related to the change of the channel-type. Managed things do not get updated. Known issue in core since years.

Does this mean, that some “change of channel type” has been done in core and some bindings may suffer from that? … and need modification in the bindings code is required and the things need to be rediscovered?

Still the question: Are the color item issues in Zigbee and Deconz binding related (have common cause in the core) somehow or am I chasing ghosts …

[curlyel]

Some additional finding…

I’ve added another Zigbee extended color light (OSRAM RGBW Lightstrip). The appearance in MainUI is the same as for the HUE Bulbs (no control widget shown):

BUT: The color channel works as expected when I send the commands e.g from the console:

openhab> send ZIGRGBWStripBuero_Color ON
Command has been sent successfully.
openhab> send ZIGRGBWStripBuero_Color 120,75,41
Command has been sent successfully.
openhab>

(and the light strip changes the color )

I’m going to open an issue in openhab-webui too to get the visibility there too (as long as the root cause is unclear).

EDIT:
Done [Main UI - Color Widgets] Widgets for Extended Color Lights are not shown · Issue #929 · openhab/openhab-webui · GitHub

EDIT2:
More testing showed me, although the command got accepted (and the color of the actual device changed accordingly), the items state remains UNDEF, notice last line:

openhab> send ZIGRGBWStripBuero_Color 120,75,45
Command has been sent successfully.
openhab> items list ZIGRGBWStripBuero_Color
ZIGRGBWStripBuero_Color (Type=ColorItem, State=UNDEF, Label=Color, Category=ColorLight, Tags=[Point], Groups=[ZIGRGBWStripBuero])

This may indicate, that the reason for the issue is rather on the binding or the core than on the ui side though … or?

[J-N-K (Jan N. Klug)]

I just wanted to point out that changing the channel-type for already existing things can cause problems.

[curlyel]

Ahh - ok. Got it
Thanks for clarifying

[cweitkamp (Christoph Weitkamp)]

Hi,

From my POV the PR for deCONZ which changes the channel types does not fix your - or any other - issue. Afair the UI elements are derived from a combination of item.type and Semantics. Did you try to use Point > Control for the color item?

[GameEnder (Steven)]

I have a Sonoff SNXN-02 that is identified as eWeLink by the binding. It is a temperature and humidity sensor. It seems to pair correctly but no data ever comes in all I ever get is NULL. Based on documentation and people using zigbee2Mqtt there also should be a battery channel that is not showing up.

I am running OpenHAB 3.0.1 and the latest built in version of the binding. What data do you need from me to get this sensor working? Log file or anything else?

[curlyel]

Sorry Chris,

@chris

sounds like a UI issue

… it seems you’re right… see:

Colorpicker in OH3

Looks like a bug then… your item’s state is probably not initialized. Try doing openhab:send Jateklampa_Jateklampacolor "0,0,0" in the console and maybe the color picker will appear.

I’ve been able to work around the issue following Yannicks hint

Again: Sorry for the noise …

[becksen]

Hi,
the thread started with WSDCGQ01LM device. I can discover it and create a thing. Channels are also available. But the device stops after several hours to update the temperature and humidity values.

I’m using OH3 and a telegesis stick to connect directly via zigbee to the sensor. Any recommendation?

Regards.

[Hedda]

FYI, anyone looking for a compatibility list of Zigbee devices for openHAB might want to chime in here:

Supported Zigbee devices list

I’m the maintainer of https://zigbee.blakadder.com which is a list of zigbee devices compatible with various gateways. I’ve received a request to add openHab to the compatiblity list OK to add "OpenHAB" ("openHAB Zigbee Binding") compatibility? · Issue #301 · blakadder/zigbee · GitHub Looking at the official documentation the list of supported devices is incredibly short. Is there an interest in this community for such a list and can I expect involvement by the community to report confirmed wo…

[FranzS]

Hello all,

today I received an error with my Ember coordinator.
Is there a list that shows what code 6 is?

ASH: ERROR received (code 6). Disconnecting.

I’ve tried to increase the MESH Update period and reinitialized the controller.
|-> BTW: is there a way to start a MESH update manually?

BR
/Franz

[chris (Chris Jackson)]

Code 6 is an assert from the NCP and without PTI traces it’s impossible to know what caused this.

@FranzS

|-> BTW: is there a way to start a MESH update manually?

No - I don’t think so.