rest api not working since update to 2.04.78

[holli73]

hello,

i can not call any light actions anymore - any help would be great because i do not have any control on my lights anymore (complete house - apx. 60 lights,...)

i already restarted the box but it did not help

holli@obelix:~/BUILD/ds/DeConz$ curl --tcp-nodelay --max-time 59 -H 'Content-Type: application/json' -X PUT -d '{ "on" : true, "bri" : 255, "sat" : 0, "sat" : 0, "ct" : 153, "transitiontime" : 6 }' $url

so i do get a success but an error as well and the lights are not turing on/off - same on the webfrontend of deconz - no reaction from any light:

[{"success":{"/groups/8/action/on":true}},{"error":{"address":"/groups/8","description":"Internal error, 951","type":901}},{"success":{"/groups/8/action/sat":0}},{"error":{"address":"/groups/8","description":"Internal error, 951","type":901}}]

so what is error 951 of type 901?

any help would be great.

thanks
holli

[manup]

so what is error 951 of type 901?

These are ERR_INTERNAL_ERROR and ERR_BRIDGE_BUSY.

I guess that it's related to the prevention to fill up queues landed in 2.04.78.
I'll add a option to configure the prevention in 2.04.79, so the prevention can be disabled or relaxed.

The network size might not be the problem, I've this version running stable in larger networks, howver non OSRAM bulbs.

Can you please share the console output of $ deCONZ --dbg-info=1 when the problem occurs?

[holli73]

hello,

i believe the problem starts shortly after starting deconz:

15:15:30:818 HTTP Server listen on port: 8080, root: /usr/share/deCONZ/webapp/
15:15:30:831 ZCLDB init file /home/holli/.local/share/dresden-elektronik/deCONZ/zcldb.txt
15:15:30:895 started websocket server at port 443
15:15:30:899 discovery updated announce interval to 10 minutes
15:15:30:899 parent process bash
15:15:30:900 found node plugin: libde_rest_plugin.so - REST API Plugin
15:15:30:900 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
15:15:30:924 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
15:15:30:956 scan skip host .1
15:15:30:978 Device firmware version 0x26190500
15:15:31:010 unlocked max nodes: 200
15:15:31:330 Device protocol version: 0x0105
15:15:31:346 CTRL restore cached node 0x00212effff00c685
15:15:31:346 new node - ext: 0x00212effff00c685, nwk: 0x0000
15:15:31:570 Current channel 25
...
15:17:15:460 CTRL restore cached node 0x8418260000cb64b9
15:17:15:461 new node - ext: 0x8418260000cb64b9, nwk: 0xAAE8
15:17:15:461 LightNode 30: sh-kugel-eg added
15:17:15:637 level 0 --> 254
15:17:15:764 level 0 --> 254
15:17:16:004 level 0 --> 254
15:17:16:196 level 0 --> 254
15:17:16:260 level 0 --> 254
15:17:16:420 level 0 --> 254
15:17:18:932 CTRL restore cached node 0x7cb03eaa0014c476
15:17:18:932 new node - ext: 0x7cb03eaa0014c476, nwk: 0x5EDB
15:17:18:933 LightNode 33: michi added
15:17:18:933 level 0 --> 254
15:17:22:659 CTRL restore cached node 0x7cb03eaa0014c0be
15:17:22:660 new node - ext: 0x7cb03eaa0014c0be, nwk: 0xFE49
15:17:22:660 LightNode 32: kati added
15:17:23:667 level 0 --> 254
15:17:24:387 level 0 --> 254
15:17:52:583 5 running tasks, wait
15:17:52:633 5 running tasks, wait
15:17:52:733 5 running tasks, wait

dgb.deCONZ.zip

and i did receive

[{"success":{"/groups/2/action/on":true}},{"error":{"address":"/groups/2","description":"Internal error, 951","type":901}},{"success":{"/groups/2/action/sat":0}},{"error":{"address":"/groups/2","description":"Internal error, 951","type":901}}]

once the "5 running tasks, wait" started i can not get any request working anymore - and it is not resolving on its own...

any workaround - downgrading?

thanks
holli

[manup]

During start phase deCONZ does request all nodes for neighbor tables and light state, normally after this is done (may take a few minutes, but normally not more than 20) internal request queues should be nearly empty and application requests should work fine.

So when even after say 30 minutes no request goes through, something is strange.
I'm afraid currently you only can downgrade to 77 or wait for the next version which will be more relaxed to let application requests through.

[holli73]

hello,

i did downgrade to 77 but - still the system is not behaving as expected!
we did have a power outage yesterday and the system did shutdown for apx. 4hours.
maybe there is something corrupt within the status/datastore?
i have a room called kitchen and i can call the group command and do receive ok now - no error with 77:

[{"success":{"/groups/8/action/on":true}},{"success":{"/groups/8/action/bri":255}},{"success":{"/groups/8/action/sat":0}},{"success":{"/groups/8/action/ct":153}}]

but the lights are not on/off - from the deconz - web interface it is the same - this group/room is not reacting - on the xsession all is yellow - no red lights...

on the deconz webinterface the bulbs are reacting on single commands but not on group commands so i took this group and removed all devices and than re-added them - but still the same - the system is not reacting on group commands but on single bulb events it is working - why?

how can i find the root cause for this?

thanks
holli

[holli73]

hello,

i have 25 groups and only 4 of them have this issue (kitchen/bath/floor/bedroom) all other look ok
i did a reset of the bulbs in one room but with no success.

any idea/help would be great.

thanks
holli

[holli73]

hello,

it took almost 2hours with .77 version that all went back to normal - so something must have changed to the previous version's - i used - because with this version's before .77 - it took apx. 20min. to have all 60 light's on and i was able to control them.

thanks
holli

[holli73]

@manup ,

i did upgrade to .79 and all 60 devices were onboarded in less than 1 minute!
i can not remember that any version could do this in the past in less than 20 minutes!

cool and thanks a lot - such a behavior makes it easier for any update in the future and reduces the discussion with my wife (why do we need an update,...)...

best regards
holli

maybe fixes #195 as well

[ebaauw]

.78 ran fine for a couple of days, but this morning most of the green lines had disappeared from the GUI and the lights were unresponsive. Hue motion sensors blinking red on motion, but rules triggering (my speakers continued to work), just any command sent to the lights/groups from deCONZ seemed to be blocked.

No time to analyse - just installed .79. Upon starting deCONZ it takes forever to find my lights, still no lines, and end-devices are discovered before the lights. Reset the RaspBee and restarted deCONZ: works like a charm. Apparently, it's not just the software running on the Raspberry that fills up, but also the RaspBee firmware? Maybe it's an idea to reset the RaspBee when deCONZ starts?

40 lights: 3 OSRAM, 2 IKEA, 5 innr, 1 ubisys, rest Philips.

[manup]

i did upgrade to .79 and all 60 devices were onboarded in less than 1 minute!
i can not remember that any version could do this in the past in less than 20 minutes!

Fingers crossed that it runs stable also :)

Showing the lights is not the challenge, it could be done in less than 5 seconds by loading them just from the database, but probing that they are truly reachable is quite tricky. I tried many approaches in the past especially for larger networks, but it's still ongoing research.

[manup]

.78 ran fine for a couple of days, but this morning most of the green lines had disappeared from the GUI and the lights were unresponsive. Hue motion sensors blinking red on motion, but rules triggering (my speakers continued to work), just any command sent to the lights/groups from deCONZ seemed to be blocked.

2.04.79 addresses exactly this, I observed the very same, looking deeper I found that many tasks and APS requests to sleeping devices piled up (binding, reporting, queries). 79 has an improved approach to send requests from the APS queue in a "fast lane" when an APS indication is received (for example a ZCL attribute report).

No time to analyse - just installed .79. Upon starting deCONZ it takes forever to find my lights, still no lines, and end-devices are discovered before the lights. Reset the RaspBee and restarted deCONZ: works like a charm. Apparently, it's not just the software running on the Raspberry that fills up, but also the RaspBee firmware? Maybe it's an idea to reset the RaspBee when deCONZ starts?

There was once versions which did exactly that but it caused different issues, like routing and neighbor tables needed to be rebuild. I'm planning to introduce better monitoring for the firmware to detect if it is in good state and reset accordingly on startup as well at runtime.