1.2.1 zigbee shepherd doesn't start

[h4nc]

With the newest version my zigbee2mqtt doesn't work any more.

I get this in the logs:

zigbee2mqtt:info 3/11/2019, 7:53:43 AM Starting zigbee-shepherd
  zigbee2mqtt:error 3/11/2019, 7:53:50 AM Error while starting zigbee-shepherd!
  zigbee2mqtt:error 3/11/2019, 7:53:50 AM Press the reset button on the stick (the one closest to the USB) and start again
  zigbee2mqtt:error 3/11/2019, 7:53:50 AM Failed to start
	{"message":"request timeout","stack":"Error: request timeout\n    at CcZnp.<anonymous> (/zigbee2mqtt-1.2.1/node_modules/cc-znp/lib/ccznp.js:261:22)\n    at Object.onceWrapper (events.js:273:13)\n    at CcZnp.emit (events.js:182:13)\n    at Timeout.<anonymous> (/zigbee2mqtt-1.2.1/node_modules/cc-znp/lib/ccznp.js:240:18)\n    at ontimeout (timers.js:436:11)\n    at tryOnTimeout (timers.js:300:5)\n    at listOnTimeout (timers.js:263:5)\n    at Timer.processTimers (timers.js:223:10)"}
  zigbee2mqtt:error 3/11/2019, 7:53:50 AM Exiting...

I already pressed the reset button several times.
The release notes say that you need node.js 10. I'm using hassio and I don't know which version of node I have, but I'm running the lassted relaease of hassos (2.10).

[h4nc]

@Koenkk I don't know what the issue was here (still interessted if you have a clue).

Things I did in the meanwhile:

• unplug it serveral times, restart ha, restart hassio. Nothing worked. Sidenote: I had Firmware CC2531ZNP-Prod_20190217 from the DEV branch before
• Solution: I reflashed the stick (with ieee retain = true, still don't know if that matters) and it worked again.

Again this brought up the issue where all devices did not show a connection in the zigbee map.
I was able so solve this this way:

• Set permit_join to true

• unplug and plug in your routers.

I did both of those options, so I cant says if both are necessary or only one is ok.

EDIT: I want to add that the only one device that doesn't show I connection in the map now, way the one that I triggered (button on/off) before I did two steps above. I will have to press the pairbutton of the device while permit join is true to make it show it's connection again.

[Koenkk]

somehow the stick crashed, the reason for this varies, one could be the use of the reporting feature (this is already being worked on in a separate issue).

[h4nc]

I did not use the reporting feature yet.

So after a crash like this, the only thing you can do is reflash?

It stopped working when I updated to 1.2.1

[Koenkk]

Unfortunately, this indeed seems to be the case sometimes. If you can reproduce the crash we can try to fix it.

[h4nc]

I don’t think that I can reproduce it. But will keep my eyes open when it happens again.

i had that the first time now. It doesn’t bother me a lot, but it will bother people that buy ready to use sticks online. Those do not have a CC debugger.

I read somewhere that it already possible to flash without the debugger.

Is this possible for normal users that don’t want do use a debugger too?
Or is using the debugger still the easiest method. What would you recommend people that have a crash and no Debugger?

Maybe we can work out an entry in the docs for that people.

[Koenkk]

It's possible (however I've never done this). I don't know if this is still possible with a crashed CC2531, we should try if we have a crashed CC2531.

[h4nc]

Do you know it’s done? Are there already people that use that method or is it only theoretical right now?

So people with a crashed device should ask for help here, so that can find out if you need to have a debugger for that case.

[Koenkk]

@kirovilya has done this AFAIK

[kirovilya]

@h4nc @Koenkk you can to try update firmware without ccdebugger. read this thread #320
but need more checks. I tried it a couple of times, but then I reflash it through ccdebuger anyway (not because of errors).

[h4nc]

@kirovilya there is a hex and a bin file here https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/CC2531/bin

So people that don't have a cc debugger will have to use the bin file from there, right? Than they download the software as described in the link a flash it direclty on the stick (that was flashed with a debugger one time before).

But we don't know if this will also work with a crashed cc2531.

[kirovilya]

So people that don't have a cc debugger will have to use the bin file from there, right?

yes

But we don't know if this will also work with a crashed cc2531.

And I don't know too...

[h4nc]

I guess we have to wait until someone has a crashed stick again and wants or has to (because no debugger) try this.

Another quick question. Will it be possible in a future update to update the firmware directly in zigbee2mqtt. Like just hit a "update button" and done? This would be the most user friendly version.

[Koenkk]

Theoretically this should be possible if the SBL protocol is implemented in zigbee2mqtt.

[h4nc]

Is it a future goal to be able to do this directly in zigbee2mqtt?

[kirovilya]

One of the problem - go chip to bootloader mode.
I think this functionality should not be part of Z2M, but should be described separately.

[h4nc]

So you mean something like a second add-on in hassio.

I know hassio is by far not the only way to use zigbee2mqtt, but I think a lot users that are not able or don't want to flash with debugger or sth else (simple users) use something like hassio.

[h4nc]

@Koenkk already two more people with that issue in that thread

danielwelch/hassio-zigbee2mqtt#118 (comment)

[Koenkk]

Not sure, they could also be using the wrong port (same issue as the OP of that thread has).

[martinrosenauer]

@Koenkk, started getting the request timeout at CcZnp today on startup as well all of a sudden.

Tried resetting the CC2531, and it seems to let z2m restart most of the times, but then I see Error: request timeout towards bulbs for example. Restarting again and the CcZnp timeout shows up.

Tried update.sh to make sure I'm on the latest commit (#661f79c), but that doesn't change anything.

Tried reflashing with CC2531ZNP-Prod_20190223, but that doesn't change anything either.

I have been re-pairing a few Xioami devices (a button and a window sensor) today, but apart from that, no changes. During the restarts to try to trouble shoot I'm seeing
No converter available for 'LED1623G12' with cid 'haDiagnostic', type 'devChange' and data

'{"cid":"haDiagnostic","data":{"averageMacRetryPerApsMessageSent":2,"lastMessageLqi":112,"lastMessageRssi":-72}}'

in the log. Will try to remove and re-pair this specific Trådfri bulb.

[kianusch]

Same problem here - reflashing fixed the problem ...

[martinrosenauer]

@kianusch, how long ago you reflashed ?

[kianusch]

@kianusch, how long ago you reflashed ?

Initially about two weeks ago? (And then an hour ago to fix the problem).

The "only" new change was, that yesterday I soldered an antenna jack connector to the CC2531 - after that it worked fine for a few hours - and than suddenly ...

[martinrosenauer]

@kianusch, ok, fingers crossed that it runs stable now then =) I'm still struggling ..

[Koenkk]

@martinrosenauer Please try with the following firmware: https://drive.google.com/open?id=1-xzI6b8umZFpki-pfaKdLgcPrUUlswe5

Relative to the 20190223 firmware, it has an increased memory heap at the cost of direct connected devices to the coordinator (15 -> 5).

[martinrosenauer]

@Koenkk , thanks a lot for trying to help out - I will give it a shot.

What I did was to turn off everything I could, left it for a while and powered up the entire thing again. So far it has been running for an hour without timeouts or errors, but I notice a few Xiaomi devices are not working. I'll re-pair those after flashing with the 20190315 firmware you send.

I also added another CC2531 with the router firmware between the floors of the house. I believe that could also make a difference.

While looking at the zigbee network map I see the ball-shaped topology which I assume is perfectly fine ? however, some of the routers (Ikea Trådfri bulbs) are marked as offline, but work. Is that behavior normal ?

[Koenkk]

@martinrosenauer the online/offline state is not reliably (known issue).

[martinrosenauer]

@Koenkk, ok, now on 20190315, anything in particular I should try ? :)

[Koenkk]

@kianusch it depends on the zigbee implementation of the device, it is known that e.g. xiaomi sensors are quite stubborn to search for new paths.

[jesperldk]

Hi

I am trying to set up a zigbee2mqtt for the first time.

Right from the beginning I got the ccznp timeout. I have tried to reflash with CC2531ZNP-Prod_20190223 several times and I have also tried with CC2531ZNP-Prod_20190315. I have tried with both report true and false.

I do feel certain that I am using the right port, and I have tried both with /dev/ttyACM0 and with the /dev/serial/by-id that indeed points to ttyACM0.

It is a bit strange, as sometimes it take something like 7 secs before timeout and sometimes it takes like 12 secs.
I am completely at loss, and would appreciate any help to debug. For example, what does it mean that the green led lights when i plug it in, but turns off after a minute or so by it self. If I press the reset (closest to the usb), it turns off right away. Is there some simple test to see if I can talk to the stick?

Not really sure I am having the same issue as the others in this ticket, if not I am sorry for the hijack - I do however get the same timeout :-(

Thanks!
Jesper

[Koenkk]

@jesperldk

It looks like a communication problem:

• What system are you running it on?
• Before starting zigbee2mqtt, can you re-plug the stick and press the reset button (the one close to the usb port, green led should go off) and start zigbee2mqtt?

[jesperldk]

I am on a Pi Zero W that was set up a few weeks ago, and have been running some bluetooth scripts.
The Zero is an Arm 6 so I could not use the guide in https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html to insatall NodeJS, but succesfully installed using the guide in https://www.thepolyglotdeveloper.com/2018/03/install-nodejs-raspberry-pi-zero-w-nodesource/

I have tried what you suggest with no luck.
Is there a simple way to check if I can talk to the stick?

[Koenkk]

@jesperldk can you check if it works on a different linux or mac system?

[jesperldk]

yeah, but not until next week. Thanks for now, I'll be back when I have tried it monday or so...

[jesperldk]

@Koenkk sorry, just one question: I have another zigbee setup, TRAADFRI hub with around 45 devices - do I need to do anything to make sure the two nets do not interfere? I have around 15 Aqara devices that I plan to use with zigbee2mqtt. I have chosen another channel than the default, but am not sure if I should change anything else.

[kianusch]

@jesperldk ... you could try using docker and the zigbee2mqtt docker image on your raspberry zero - would make things much easier.

[jesperldk]

@kianusch good suggestion. I have no experience with docker, but am aware that this ought to change ;-) Am fearing a bit that I'll run into other issues with limited ARM6 support, but I will give it a go. Do however doubt it will help with my problem of talking to the stick.

[kianusch]

Don't worry - simply install the docker-environment on your Zero via apt - although I believe that the latest Version might have a problem on Rasperry Zero (containers won't start) so you have to install an older version (check google for that) - and after that - the documented way to install zigbee2mqtt container (or other containers) is straight forward.

[Koenkk]

@jesperldk changing channel is enough.

[jesperldk]

@Koenkk
Got a little unexpected time today and tried the stick on an Intel machine running Debian Stretch.
Followed the installation guide with no hiccups at all, except I had to add my user to the dialout group to get access to ttyACM0.
The result is exactly like on my Pi Zero:

@influx:/opt/zigbee2mqtt$ DEBUG=zigbee-shepherd* npm start
> zigbee2mqtt@1.2.1 start /opt/zigbee2mqtt
> node index.js
  zigbee2mqtt:info 3/22/2019, 5:59:50 PM Logging to directory: '/opt/zigbee2mqtt/data/log/2019-03-22.17-59-50'
  zigbee2mqtt:debug 3/22/2019, 5:59:50 PM Using zigbee-shepherd with settings: '{"net":{"panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"channelList":[11],"precfgkey":"HIDDEN"},"dbPath":"/opt/zigbee2mqtt/data/database.db","sp":{"baudRate":115200,"rtscts":true}}'
  zigbee2mqtt:debug 3/22/2019, 5:59:50 PM Loaded state from file /opt/zigbee2mqtt/data/state.json
  zigbee2mqtt:debug 3/22/2019, 5:59:50 PM Saving state to file /opt/zigbee2mqtt/data/state.json
  zigbee2mqtt:info 3/22/2019, 5:59:50 PM Starting zigbee2mqtt version 1.2.1 (commit #4048cb8)
  zigbee2mqtt:info 3/22/2019, 5:59:50 PM Starting zigbee-shepherd
  zigbee-shepherd:init zigbee-shepherd booting... +0ms
  zigbee-shepherd:request REQ --> SYS:osalNvRead +0ms
  zigbee-shepherd:request RSP <-- SYS:osalNvRead +2s
  zigbee-shepherd:init Coordinator initialize had an error: Error: request timeout
    at CcZnp.<anonymous> (/opt/zigbee2mqtt/node_modules/cc-znp/lib/ccznp.js:261:22)
    at Object.onceWrapper (events.js:277:13)
    at CcZnp.emit (events.js:189:13)
    at Timeout.<anonymous> (/opt/zigbee2mqtt/node_modules/cc-znp/lib/ccznp.js:240:18)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10) +0ms
  zigbee2mqtt:info 3/22/2019, 5:59:56 PM Error while starting zigbee-shepherd, attempting to fix... (takes 60 seconds)

I also tried the unplug/replug+press-and-led-turns-off-trick with no luck.

[Koenkk]

@jesperldk the last thing that you could try is reflashing, if this doesn't work, my guess is that your CC2531 is broken.

[jesperldk]

@Koenkk
Reflash didn't help.
I then took the CC2530 I had bought for router, flashed it as coordinator and connected it with an old FTDI 1232 I had laying around. Worked at first try :-D
So my CC2531 is considered dead and I have ordered a new one.
Thanks a lot for all the help!! 🥇

[Michaelnorge]

Same here.

Using CC2531 like a coordiniator on an ioBroker with Pi3.
After restart the log is showing "Error while starting Error request timeout" and the light on the usb is turned off.
I need to restart the Raspberry three times to get it in work again.

That´s strange...

[kianusch]

@Koenkk

Overnight my CC2531 firmware crashed (again) - currently the stick is in the crahed state - before I reflash the stick - is there anything I can do to help finding the problem?

I had 13 bulbs (10 Tradfri, 3 Philip Hue) in my network, 2 end-devices and one CC2531 with router-firmware.

The coordinator was running with the latest "standard" firmware.

(I'm using my second CC2531 with MAX-Stability-FW right now).

[Koenkk]

@kianusch probably because it runs out of memory, the max stability firmware has more, please let me know if it also crashes with that one.

[kianusch]

... yes I am aware of the memory problem ... but what I'm wondering ... how come running out of memory can crash the stick so that one has to reflash the stick.

I'll keep you informed about the "max stability firmware".

[Koenkk]

@kianusch my current theory about this is that it writes to wrong memory locations (but it's just a thought)

[kianusch]

@Koenkk This would be my guess too ...

As I still have a stick in "crashed state" ... to confirm this, is there a way, to read out the stick - and compare the dump with a "virgin" firmware, to see if there are memory locations which should not have been overwritten?

[Koenkk]

@kianusch you can use the "Read flash into hex-file" with the TI flash programmer (see http://www.zigbee2mqtt.io/getting_started/flashing_the_cc2531.html)

[kianusch]

I compaired the dump of a currupt firmware - and the original "untouched" firmware (the one in the ZIP download) ... the differences are:

memory localtion: 0x0210000-0x021041F
memory localtion: 0x0744000-0x07704FF

[Koenkk]

Is there also a difference with a firmware that has been started once?

[kianusch]

I just reflashed the stick - startet the stick with zigbee2mqtt - stopped everything after a minute or so (no paring had accured) - dumped the firmware ...

compared to the "currupted" dump - same memory locations as in my last post.
compareed to the "untouched" firmware from the zip - just the location from 0x0744000 ist different ...

So it seems, that whatever get's written to "0x0210000-0x021041F" causes the problem.

[Koenkk]

@kianusch thanks for finding this out, I guess our hypothesis were true.

[kianusch]

... so this seems to be a firmware-problem ... but the firmware is maintained by TI I guess?

What I could do next, is dumping the currently working/running C2531 where devices have been paired and compare - maybe location 0x0210000 is where the firmware keeps information about paired devices? (we are talking about 1050 bytes or so)

[Koenkk]

The firmware is indeed maintained by TI, note that there are also newer version available (Z-Stack 3.0 #211).

But if this is indeed solved by the max stability firmware, I think there is not much to fix here (I even doubt if that is possible).

[jonnycastaway]

Hi,
i had the same crash yesterday but with my cc2530+cc2591 as coordinator.
I have 7 Tradfri bulbs, 3 Osram Smart+ Bulbs, 4 Osram Smart+ Plugs, 4 Xiaomi Sensors and a Tradfri Remote. No extra Stick as Router. Works for 3 Days then crash.
The only way was also reflashing the cc2530. Now i check how long it will work.

[AlanValentine]

I flashed my chinese naked circuit board cc2531 usb dongle without any debugger, using the raspberry pi gpio headers exactly as described in the 'alternative flashing methods' section of the official setup guide. worked perfectly, i made sure to have the right cables to join the raspberry pi gpio headers to the usb dongle (exactly as the guide says i.e. downloader cable + 4x dupont female-to-female, just pennies on ebay) as the usb dongle has miniature pins really close together, and the pi gpio headers are a more standard size pin layout.
flashing was super simple, probably simpler than using debugger box i imagine.
I am also now encountering the problem described above, so I can also try tonight and tell you if reflashing helps at all

My question - when should the green light be on, and when should it be off, and what exactly are the 2x buttons on the usb stick supposed to be for exactly, in relation to this custom firmware that we run? Should I understand from the above that the green light should be off before zigbee2mqtt starts up?

[kianusch]

I'm not sure, if the two buttons have any function on the coordinator firmware.
The green led should be lit when operational. But this does not mean, that the stick is okay :)

The flashing method (via raspberry, arduino or debugger) does not have any impact on the problem.

You should use the firmware label "MAX_STABILITY" ths will probably fix the problem.