Send cmd seq: 233, CMD_STATUS failed, ret: -1

deCONZ General Support
1

In one of our installations, the light switches stop/restart working whenever we reload the Phoscon web app (index.html).

I’ve switched on --dbg-prot=1 to investigate. Whenever I reload the page, I start seeing a lot of the following lines:
send cmd seq: 233, CMD_STATUS failed, ret: -1
and the system stops working, i.e. light switches don’t work.

After reloading the page again, the system works again. I.e., reloading the page “toggles” the functioning of the system (at least 9/10 times).

The same also happens when editing the switches of a group (group-switches.html), for example, and then returning to the main page (index.html), presumably because this loads/starts the index.html page again.

Version: 2.21.01 / 9/19/2022
Firmware: 26690700
IP: 192.168.0.3
Device: Raspberry Pi 4, with a RaspBee II attached to the GPIO
OS: Debian 11.6 (bullseye)
DeCONZ source: deb http:/phoscon.de/apt/deconz bullseye-beta main

I’ve uploaded two excerpts of the log here:

Addendum A:
The error first occurs in version 2.20.00. It does not occur in 2.19.03.

Addendum B:
When deCONZ is in error mode (i.e. CMD_STATUS failed being displayed on the command line), it needs to be quit with kill -9. Simple Ctrl-C or kill does not work. When it works in normal mode, it can simply be quit using Ctrl-C or kill.

2

@de_employees can you check?

1 Like
3

Hi,

may I suggest to update Raspbee II firmware to the latest version (Index of /deconz-firmware/)? The one you run is quite old and since then, there were also some improvements in protocol communication and sustainability.

Please let us know if you observe the same with the new version, thanks!

1 Like
4

Thanks for the suggestion. I’ve updated to version 26780700 (sudo GCFFlasher_internal -t 60 -f deCONZ_RaspBeeII_0x26780700.bin.GCF), but the problem remains.

I’ve tested on two different installations: one with just about 10 devices (lights + switches + sensors, almost entirely IKEA), and one with over 50 devices from a variety of vendors. Otherwise, the setup is very similar.

5

That’s a curious thing, normally the page loading doesn’t affect the serial communication at all :thinking:
The only effect the page loading has is that it occupies CPU time to do it’s work, I think this might interfere here with a recently stricter timing in the serial communication (looks to be too tight under load on a slower device like the RPi).

We’ll schedule a test with similar setup to re-produce and fix the issue.

1 Like