That’s too bad, ZigBee would be working pretty well in OpenHAB (compared to Home Assistant) if it weren’t for this issue.
What are you using for lighting if ZigBee is only for testing?
The documentation from Silabs is not good regarding rejoins, and it might be misconfigured. I’ve asked Silabs to clarify this, and they agreed that the documentation was not correct, and they needed to check the source to see how it worked. I’ve asked a couple of times for an update, but unfortunately not had a response yet.
If you able to provide a sniffer log (probably not though), then it would be useful
Which part do you need sniffed? There are some cheap ZigBee sniffers on Amazon/eBay, will those work?
Did some more digging. Removing my ZigBee xml will allow new devices to join, copying over an old lamp to the new config will still make it show up as offline. So they indeed “left” the network.
ubuntu 64bit oder 32bit?
I’m running:
pixeldoc@pd-srv:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
pixeldoc@pd-srv:~$ uname -a
Linux pd-srv 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
pixeldoc@pd-srv:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 1: Dev 7, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 1: Dev 7, If 1, Class=CDC Data, Driver=cdc_acm, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 4: Dev 9, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
pixeldoc@pd-srv:~$ find /sys/bus/usb/devices/usb*/ -name dev
/sys/bus/usb/devices/usb1/dev
/sys/bus/usb/devices/usb1/1-1/dev
/sys/bus/usb/devices/usb1/1-1/1-1.4/dev
/sys/bus/usb/devices/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB1/tty/ttyUSB1/dev
/sys/bus/usb/devices/usb2/2-1/dev
/sys/bus/usb/devices/usb2/2-1/2-1.1/2-1.1:1.0/tty/ttyACM1/dev
/sys/bus/usb/devices/usb2/2-1/2-1.1/dev
/sys/bus/usb/devices/usb2/dev
pixeldoc@pd-srv:~$ ls -la /dev/ttyA*
crw-rw---- 1 root dialout 166, 1 Aug 18 04:41 /dev/ttyACM1
pixeldoc@pd-srv:~$ ls -la /dev/ttyU*
crw-rw---- 1 root dialout 188, 1 Aug 18 00:12 /dev/ttyUSB1
lrwxrwxrwx 1 root root 7 Aug 6 02:07 /dev/ttyUSB_cc2531 -> ttyACM1
lrwxrwxrwx 1 root root 7 Jul 23 00:00 /dev/ttyUSB_mysensorsserialgw -> ttyUSB1
Please post your details!
Maybe try other Java version like zulu (Install Java for Openhab2)
Maybe your Java is missing the java rxtx library?
Try: sudo apt-get install librxtx-java
I’d like to see what is happening when the devices leave. ZigBee has a reasonably complex network model, and devices can leave the network, and then rejoin so long as they still have the key, and the key hasn’t changed. I’d like to see if the coordinator is chucking the devices off, or if the key changes, or if the trust centre isn’t allowing the devices back (or something else…).
They should work. They work with Wireshark - I’ve just been spending some time trying to familiarise myself with it again as I don’t tend to use it these days. It looks like it will do what is needed, and I will write a how-to if people want to try and set up a sniffer.
The cheap TI dongles available on the web from China tend to be a bit of a pain to program, but in theory you can buy them with the sniffer firmware already loaded, so it should (!!) be simple to set up. I’m not 100% sure how to pipe this data through to wireshark - I have found a python script on github which will work for Linux / Mac, but probably not for Windoze.
I mostly use Ember sticks, and I’ve spent a few hours this afternoon writing a sniffer to pipe data from the Ember chipset to Wireshark and this seems to work ok. It can use any reasonably new Ember firmware (at least 5.7.3 has these functions available - the Elelabs interface will work fine). Of course, you need 2 of them - one for the coordinator, and one for the sniffer, which is a little more expensive.
I’ll make this sniffer software available on Github soon.
Other options that are available are the CEL sticks from Silabs (a straight USB dongle) which is what I mostly use for development - the problem with them is they don’t come with any firmware and require reasonably expensive hardware to program. If there’s interest, I could probably offer to program some sticks for people to use.
1 Like
Wow! Are you saying that this will turn any Ember dongle running at least 5.7.3 into a Zigbee sniffer?! The HUSBZB-1 (at least the one I have) is running firmware 5.4.1.0… so it looks like it would need a firmware update. Any chance you can suggest a dongle available in the US that has 5.7.3+?
Yes - although I’m not saying that it needs 5.7.3 - just that I can confirm that 5.7.3 will support it. Older versions may also support it - I’ve just not checked back further than this, and I do know it’s not a really old feature. I’ll see if I can find docs for 5.4 to see if it’s supported.
The binding can do this 
. I can probably supply you the latest firmware, and I’d be reasonably sure it will work (but, there’s always that small possibility it won’t - but I think it’s really low).
No - only the CEL MeshConnect stick, but that doesn’t have ANY firmware, so it needs programming with the Silabs programmer. I could get some and program them if there’s interest.
1 Like
I can’t find the full docs for 5.4, but I did find an older one that indicates it might have already been included, so there’s a good possibility that it will work with 5.4.
Note that this does also need an update to the main library to work, and as there are some small breaking changes to the APIs in this version, it will also need a binding update. I’m trying to wrap all these changes into a single release if I can to avoid too much pain…
1 Like
That’s promising… I need some backup hardware anyway, so I’ll pick up a spare and try this out. Worst case, I’ll need to flash it. Hmmm, maybe updated firmware on my coordinator would stop my bulbs from dropping too… 
I am of course talking complete bollocks when I said you need the updated library etc! While this is true for the binding, the sniffer application is a completely separate application and not linked to the binding, so can include the updated library without impact on the binding - I can provide a copy to try if you want to try it.
I’ve created a JAR for the Ember sniffer, and started a document describing how to use it in case anyone wants to try. At the moment it focuses on the Ember sniffer I wrote since that’s what I’m currently using - I’ve added a link for some software to use the cheap TI dongles as well, but I’ve not tried this yet. I have purchased one off the web and document how to get it going once it arrives.
Document explaining the sniffer use is here, and the Ember sniffer software is here.
While I don’t tend to use Wireshark, I will try and make some effort to update the documentation, and provide updates to the analyses as we uncover issues, to try and make it more useful for everyone (which will hopefully allow me to further improve the binding 
).
I’d be interested!
Hi @chris,
I have few CC2538 modules to test as Coordinator, End device and would like to work on ESH.
Does this binding supported on ESH ?
Thanks,
Kiran.
I have not tried the 2538 so I’m not sure. I would expect the protocol to be the same as 2531 as TI don’t have multiple stacks, but there may (quite probably!) be small differences that mean it doesn’t work. You would need to try and see I’m afraid.
1 Like
Hej, did you manage the motion sensor problem? Does it work? I am thinking of buying it.
Thanks.
I don’t think I ever got any information on it, so I don’t know why it doesn’t work. If they are a common device, I’m happy to look at adding support if a few people want to donate the money so I can get one. Alternatively, if someone has one and can find out the information needed - this is always slower and more difficult though.
I believe I did send you an email with the info for the device, Chris…
To answer this
No I did not mange to get it to work, (this is a general matter on all my Zigbee devices).
I´m waiting for Chris to do something with the binding, and I believe he´s waiting to get some information from Silabs and their support according to this:
I´m willing to donate some money, Chris. But would it make an sense, since none of my devices seems to work? I´ll rather donate money getting something to work, or at least to know, how come it doesn´t work. If it´s the 
I thought that it didn’t have the information
No - I’m not doing anything with this, and there’s nothing I’m waiting on from Silabs so I’m not sure what you’re thinking of here 
. Maybe I’ve missed something?
Ah - I think when you mention Silabs, you are talking about devices leaving - this is a different issue. Unfortunately I need more information from people with a packet sniffer for this though 
.
I don’t think that’s correct - I’m sure I’ve seen you say it was working? I think again you are talking about the devices leaving the network after a few days or so and not that no devices work? If so, please don’t get this muddled up with individual devices [edit: the global issue is not a device issue - it’s likely a coordinator issue so will not happen with all dongles]. Hopefully we will get to the bottom of the device leaving issue, but as it’s a low level problem, it’s hard to debug without a packet sniffer to see what is happening.
Regarding the Trust Zigbee motion sensor, (Trust Zigbee motion sensor ZPIR-8000. And it´s name is ADUROLIGHT VMS_ADUROLIGHT). I did NOT manage to get it to work. I managed to get it included allright. But it had no channels. And according to Habmin, the devices has not completed discovery. But it went from unknown to naming. So some part of the discovery did complete.
I gave up after that due to the problems, which I understood was related to the other problems with devices leaving after a few hours. I could have misunderstood though.
If you need anything or want to me test anything, just yell. I was waiting for you/someone to do something, which is why I didn´t go any futher 
EDIT - My Zigbee devices are test devices. So it doesn´t really matter if I ruin something.
I need to know what services the device supports. This is normally saved into an XML file in the {userdata}/zigbee folder for each coordinator. Without this showing the services, I have no way to know what the device does.
That said, a quick search on the web seems to show lots of systems having problems with this (SmartThings and Athom at least). It may be that it’s designed to work directly with lighting and not a home controller.
If I can find one cheaply I’ll see if I can pick one up.