forum

I am running latest stable version of z-way on an rpi with uzb as controller and from time to time it does take up to 30 seconds before a turn off/on command reaches a device.
One time when I noticed this lag I opened the queue and noticed a lot of ongoing and queued commands that was before the turn off command.

Is it really supposed to work like this, i can't remember that i had this kind of issues when I used a Razberry as controller.

I am adding a screenshot of the queue when it took about 15 seconds before my command was received by the device, the command I sent was to node 13.

Any thoughts about this?

Disable polling!

Is it that simple
I am only using the default apps that is activated from installation, that's the only thing that is polling.

I will disable and see if I get better response in the system.

I have the same problems with lagging and extremely slow response to commands regardless if they originate from the web UI or from a wall switch sending commands ove the network (like e.g Aeotec Wallmote Quad). It takes from 7 to 40 seconds for a lamp to respond to a command.
I don't think I have excessive noise levels as I live far from any disturbing sources - unless the Raspberry Pi/Razberry themselves are causing disturbance.

My background noise and zniffer history is attached. Furthermore, when starting the UI, the status of the different lamps seem random; sometimes the status of the different lamps is updated correctly, sometimes it seems total random.

Btw. how do I disable polling (as mentioned above) and what consequences will that have?

Best /Brus-Per

Hi Brusan,

Node 8 seems to be not reachable. I've had the tham with an aeon plug. a reset of the plug and re-include did stop the flooting with nonce reports. and my network was as quick as on the first day

search in the smarthome ui in the active apps - tab for active polling apps, you could easyly stop or delete.

Hi janjan.

I have already removed all apps that was not mandatory (i.e they are not actice) but I made a new sweep through the list and I can not find any polling apps - at least judging from the descriptions of the remaining apps.

I see from the screen dump provided by Isacsson above that his job queue is at 26. I only rarely see a job queue of less than 130, usually it is of the order 150-180 - maybe that can explain the slow response?

br /Brusan

Hi bruson,

Yes more than 100 Jobs in the queue slow the system, if they all running. I have had 30 running jobs, "nonce reports" of a failed device.

@poltos, you are the specialist, how many running jobs are possible without slowing down the system?

best regards

janjan

a job usually takes about 10-20 ms. and 10 ms between sending jobs. This gives about 20-30 packets per second. But since Get requires an answer, it takes even more to get and answer. This slows down to 10-15 packets per second in a normal environment and less if there is hard routing or dead nodes.

its polling