EU Zigbee dongle

Add-ons Bindings
181

So, it seems like something goes wrong when trying to initialize additional devices.

I restarted OH with clean tmp and cache directories, and have 2 disable things (shield and stick)

Enable the shield: all good.
Enable the stick: fails.
Disable/re-enable the shield: fails.

All the failures are caused by the same exception, logs here https://pastebin.com/RaG2Gwaq

182

I donā€™t understand what you mean by additional devices?

What i saw in the log above was no communications with the stick. The binding then throws an exception as it didnā€™t get the IEEE address from the stick.

183

Unfortunately the log viewer doesnā€™t process this - I think itā€™s probably as youā€™re using a non-standard logging format?

184

This doesnā€™t happen when thereā€™s only one coordinator Thing, but start happening as soon as a second coordinator is added.
This happens even with a single coordinator, after disabling/re-enabling it.

The log format is the standard one, I havenā€™t changed it (or not intentionally, at least)

185

@giuseppeiannello
Perhaps the Zigbee log viewer can help you.

https://www.cd-jackson.com/index.php/openhab/zigbee-log-viewer

186

https://pastebin.com/tS938K2Y This is a log of a successful initialization followed by disabling/re-enabling the thing.

I tried already loading it in the log parser, and works just fine for me.

187

So here you are disabling and re-enabling the same coordinator? :confounded:. Seems a little strange - the response from the device sometimes is ok, and other times looks invalid. Iā€™ll try and decode the responses manuallyā€¦

188

Correct - oddly enough restarting OH solves the issueā€¦

189

So this is the issue -:

Normally, the response looks like this -:

13:29:35.806 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=5, ackNum=5, reTx=false, data=2D 00 01 53 00 01 FF 00]
13:29:35.813 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=6, reTx=false, data=2D 80 01 53 00 00]

However sometimes it now responds with this -:

13:30:21.424 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=4, ackNum=4, reTx=false, data=B8 00 01 53 00 01 FF 00]
13:30:21.431 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=5, reTx=false, data=B8 80 01 00 00 00]

There are two things wrong here.

Firstly, the incorrect response is received - we receive 00 instead of 53. Packet 00 which is a version response rather than the config request that was sent. Second, this is an incorrect version request as itā€™s too short, and this is probably what is causing the error.

This seems to be caused by invalid response from the stick from what I can tell.

190

I assume youā€™re using the standard Xmodem bootloader? If so, it would be great if you could release the file zipped with the metadata so that it can be booted directly in openHAB?

Yes, Xmodem bootloader.
Sounds great. We will look into it and prepare the zipped metadata.

191

Glad to hear.
Yes. indeed the ELU013 devices are internally marked as ELR023.
They share the same firmware. We mainly use this field to distinguish them from previous generation ELR022, ELU012, which were based on EFR32MG1 and require a different firmware.

192

This seems to be caused by invalid response from the stick from what I can tell.

Thanks for the investigation. I agree with your conclusion as of now.
We will check and try to reproduce the issue on our side.

1 Like
193

quick report: new network, 28 devices paired (2 CC2531 routers, 1 IKEA bulb, Aqara sensors, no OSRAM bulbs).

The network is stable, no delays, and only a few packets go around once the discovery is finished.

The only issues so far:

  1. failure to start the network after the first time (restarting OH is necessary)
  2. error in setting the stick configuration during startup (EZSP_ERROR_INVALID_ID and EZSP_ERROR_OUT_OF_MEMORY, both visible in the log at https://pastebin.com/RaG2Gwaq)

I will finish pairing all the end devices I have around, then let it run for a few days. I want then to re-add my OSRAM bulbs and see if maybe they are the cause of all my headachesā€¦

194

@Elelabs are you able to provide more details on the chipset and configuration so I can compile firmware for your dongle for use with openHAB?

195

@chris Did you get the information from @Elelabs to build the firmware? It may help me (and others Iā€™m sure) to figure out what Zigbee dongle to choose when considering this protocol ecosystem.

196

No - unfortunately I didnā€™t receive a response. I know others are having problems with this under windows so understanding what is inside would help us support and know what drivers are required.