Zigbee Telegesis stops working

Add-ons Bindings
3

Thanks a lot, I will try to survive until then. So this:

java.lang.NumberFormatException: For input string: "�,-4"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?]
	at java.lang.Integer.parseInt(Integer.java:569) ~[?:?]
	at com.zsmartsystems.zigbee.dongle.telegesis.internal.protocol.TelegesisFrame.deserializeInt16(TelegesisFrame.java:198) ~[219:com.zsmartsystems.zigbee.dongle.telegesis:1.2.1]
	at com.zsmartsystems.zigbee.dongle.telegesis.internal.protocol.TelegesisReceiveMessageEvent.deserialize(TelegesisReceiveMessageEvent.java:177) ~[219:com.zsmartsystems.zigbee.dongle.telegesis:1.2.1]
	at com.zsmartsystems.zigbee.dongle.telegesis.internal.TelegesisEventFactory.getTelegesisFrame(TelegesisEventFactory.java:90) [219:com.zsmartsystems.zigbee.dongle.telegesis:1.2.1]
	at com.zsmartsystems.zigbee.dongle.telegesis.internal.TelegesisFrameHandler$1.run(TelegesisFrameHandler.java:185) [219:com.zsmartsystems.zigbee.dongle.telegesis:1.2.1]

Is not something to be alarmed by?

4

No - probably not. The Telegesis “protocol” used to communicate between the stick and the binding is quite poor. It’s an ASCII based protocol, and there is no error checking. All that the libraries can do is trap errors and hope that the higher level systems will retry the message.

This is likely what led to the problem - these sorts of errors will happen occasionally, and the system should work fine with the occasional error. The problem is with the bug I referenced above, after 3 errors from the point the binding is started, the system will be put offline, and it should be 3 errors one after another.

5

Thanks a lot for the explanation. Is there a USB stick with a better protocol that you would recommend atm? Or is Telegesis still considered as one of the top options (USB Zigbee Stick)? Do you think the low baud rate of 19200 is a problem with lots of devices?

6

@chris is the expert but I am biased toward the Z-Wave Plus protocol. It is designed for long battery life, good range, device compatibility, and low interference. Security is also an option. Devices are region-specific due to various frequencies and more expensive than Zigbee.

7

I’ve migrated from Telegesis to an Ember EM3588-LR. It supports Zigbee 3.0, works with higher baud rates and doesn’t have issues with some devices (eg. Innr bulbs and plugs).

I think that’s also the option @chris recommends:

1 Like
8

As @weakfl stated, the Ember chipsets are best (IMHO), and the have the best support (both by the binding and their manufacturers). The EM35x mentioned by @weakfl is a good option, but there aren’t too many sticks readily available. There is the MeshConnect EM35x series from CEL that are generally easily available, but they have no firmware in them when purchased. There is also the HUSBZB-1 from GoControl (a combined ZigBee/ZWave stick available in the USA) that is also ok, but this has quite an old firmware and no bootloader. There is also a Bitron stick sold by Deutsche Telekom, but this requires custom drivers so is only usable on Linux…

Nearly all of the commercial users of the Z-Smart Systems libraries that perform all the low level ZigBee work are using Ember chipsets of various types, so it gets the most testing, and best support.

I would have no real hesitation recommending any of these if you can live with the relevant constraint. Plus or minus, they all work the same with the “same” firmware. However, this is an old product now, and I don’t think Silabs are still making them. Instead, they have a new range - the MightyGecko, or EFR32 range (same thing - different names). Again, this uses the “same” firmware as the EM35x series, so will work exactly the same with the binding.

I am looking at producing a stick with the EFR32 in it - hopefully at a similar cost to the existing CEL MeshConnect sticks. My goal is to solve a few problems that the existing sticks have - it will have a hardware reset (a potential problem with all current sticks that causes some people issues), and it should also allow me to support the sniffer function at the same time as being used as the coordinator (all current solutions require a second stick to act as a sniffer). It will also come programmed, and will include a bootloader so it can be updated, so it should get around all the issues we currently have with the various Ember sticks mentioned above.

Let’s see how I get on with this - I have some boards arriving in the next few days so there’s still a little work required to get this into a working state :sunglasses:.

Just for completeness - other options out there are the TI CC2531 dongles - these are low cost from China, but the firmware is not so good and I’ve been told by TI that it will not be updated. The Telegesis is still on my “recommended” list as it generally works fine, but it’s not going to be updated, and it’s not ZB3.0 compatible (I should also say that the Telegesis is actually the same as the CEL chips except the firmware, and the firmware can be reprogrammed with the standard Ember firmware). The ConBee is also semi popular, but not fully supported by the binding, and the last option is the XBee series which I believe works well, but again this is the same as the Ember chips with different firmware.

Anyway, I hope that rather long answer helps with your short question :slight_smile: .

3 Likes
9

I didn’t know that’s possible. Does it require a devkit?

10

Good question - I’m not 100% sure to be honest as it’s been a little while since I’ve done this. It has the same connector on the side as the CEL sticks, and can certainly be programmed with the devkit, but it may also have the standard bootloader, so it’s possible that it may be programmable using my console application in the Z-Smart System ZigBee repository.

11

Yay! Sign me up.

12

Ok, I had the same issue with my Telegesis ETRX357 Zigbee USB stick running on my RPI 3b+. All of my Zigbee switches and light bulbs quit responding today.

The log keeps repeating the following message:

“2019-09-13 12:30:07.674 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:coordinator_telegesis:04000B6C’ has been updated.”

All of my items report in paper UI to be “ON LINE” yet are unresponsive.
In Paper UI I tried to disable the Zigbee Coordinator and restart it…to no avail. The same issue repeated the previous repeating message in the log.

As a last ditch effort I disabled the Zigbee controller in Paper UI then unplugged the USB controller from my Raspberry PI. After waiting about a minute I plugged it back in and restarted the Zigbee Coordinator in Paper UI and watched the log. It worked…went into discovery and detected all of my devices and it was all working again! I got lucky I guess.

I don’t know if this will help anyone…best wishes!

Mike Anderson

13

From what you’ve described, the issue looks different since you say everything is ONLINE. Maybe it’s better to start a new discussion.

This is perfectly normal - it means that there are updates still happening. You should look at the debug logs as explained in the binding documentation.

1 Like
14

Looks like :slight_smile:

ETRX357-LRS Serial/OTA Bootloader v01 b02

1. upload ebl
2. run
3. ebl info
BL >

But where can I get the right firmware?

15

I can probably provide it if you want to do this.

1 Like
16

That would be great, I’ll send you a PM…
I don’t use the stick atm, so worst case scenario I’ll have to send it to you for reprogramming, right? :stuck_out_tongue_winking_eye:

17

Yes - that’s fine. It should work fine with the bootloader and I’ve tested this many times in the past.

18

I would be very interested in if / how this works.

19

It definitely works - as above, I’ve done it many times…

I will try and find the firmware and write a short “how-to” at some point soon.

20

Any news? For those having the same problem, here is my ugly in-the-meantime hack for auto-restarts, including another ugly hack for not blocking the internal MQTT server from restarting:

#!/bin/bash

date
echo "started"
tail -F /var/log/openhab2/events.log | \
grep --line-buffered "'zigbee:coordinator_telegesis:04000A30' changed from ONLINE to OFFLINE" | \
while read
do
	date
	echo "trying to restart openhab"
	systemctl stop openhab2.service && \
	rm /var/lib/openhab2/mqttembedded.bin && \
	systemctl start openhab2.service
done
21

Sorry guys - I’ve not had the chance to dig this out and write up the instructions for reprogramming this yet.

This problem with the Telegesis stopping should really be resolved though as per the issue I referenced a couple of weeks back.

22

2.5.0.M4 seems to fix the telegesis stopping problem (at least for the last 12h). Thanks!