Hey,
I’m using v2.19.1 to connect via ConBee II stick. After acquisition of the authentication token, GET requests work fine. Though, when trying to trigger state changes (turning light on) via PUT, following error message will be returned:
I read that this may be a queuing issue. Though, no further coherent requests are placed.
Setup details:
raspbian, Conbee2, firmware 26780700, App in V2.19.1.
Thanks for help!
Michael
Hu ? 951 is “bridge busy” …
I read that this may be a queuing issue
Yeah not logic.
I m seing you are using “raw” for the body, can you try with other form ?
Can try too with Curl ?
curl -H 'Content-Type: application/json' -X PUT -d '{"on": true}' http://IP:PORT/api/KEY/lights/2/state
Same behavior using above CURL command:
deCONZ services has been restarted, even full system restart without changes.
Would logging with usual parametrization be of help?
Thanks for help!
Michael
I have uploaded the log while placing the request (CURL statement referred above) here:
Do you have a timestamp for when you tried?
@de_employees can you check in?
Hey Dennis,
another log with timed execution of the request. The request was conducted at 08:40.
Hope that helps better.
Thanks, Michael
Don’t exactly know what the problem could be. But perhaps a FW re-install or even downgrade would help?
Firmware won’t work, reinstall might but not sure. Do you see any commands going to the light ?
@MBizm what Deconz version are you on? Can you try 2.19.3?
Your stick is not connected as it seems.
Notice the firmware not connected .
Do you have both Deconz and deconz-gui running?
To check that can use
sudo systemctl status deconz
sudo systemctl status deconz-gui
You need to have one running and not the other
Hey Dennis,
valid point! I tried to reproduce the issue and seems that if a (browser) session with the gateway is started before restarting deconz service, that behavior comes up. In that state switching the lights via the gateway is also not working - most likely due to a outdated handle within that session.
Either starting a new browser session or restarting the machine will resolve the issue. Afterwards the gateway acts all normal (lamps can be turned on/off) and conbee stick information is also properly displayed:
Not sure that this issue is directly related to the original issue but I hope description helps.
Hey Smanar,
see below the output:
pi@ccc:~ $ sudo systemctl status deconz
● deconz.service - deCONZ: ZigBee gateway -- REST API
Loaded: loaded (/lib/systemd/system/deconz.service; enabled; vendor preset: e
Active: active (running) since Wed 2022-12-07 16:45:12 CET; 1 day 17h ago
Main PID: 357 (deCONZ)
Tasks: 5 (limit: 4915)
CGroup: /system.slice/deconz.service
└─357 /usr/bin/deCONZ -platform minimal --http-port=80
Warning: Journal has been rotated since unit was started. Log output is incomple
pi@ccc:~ $ sudo systemctl status deconz-gui
● deconz-gui.service - deCONZ: ZigBee gateway -- GUI/REST API
Loaded: loaded (/lib/systemd/system/deconz-gui.service; enabled; vendor prese
Active: activating (auto-restart) (Result: exit-code) since Fri 2022-12-09 10
Process: 28460 ExecStart=/usr/bin/deCONZ --http-port=80 (code=exited, status=1
Main PID: 28460 (code=exited, status=1/FAILURE)
Not sure whether ‘activating’ state is right. Though, explicitely stopping deconz-gui service will not change errorneous behavior.
You have both enabled, look at the line “Loaded”
Wich one you want ? Disable the other with
$ sudo systemctl disable deconz-gui
$ sudo systemctl stop deconz-gui
or
$ sudo systemctl disable deconz
$ sudo systemctl stop deconz
After I was still facing the same issue with the installation despite applying all hints, I completely purged the installation and re-installed/re-setup deconz. It uses the same versions as before (firmware 26780700, App in V2.19.3) but solved both issues:
All state changes via GW UI and REST call are now working. Not sure what caused the issue with the earlier installation but I hope it is stable for now.
Thanks again for help!