forum

Hi,

I've been having problems with jobs stuck in queue. After server restart it's about 10-20 minutes and then jobs get stuck in queue. I'm attaching the log that shows everything from the latest restart. I'll attach 2 pngs of screenshots of the job queue. The timestamp for these are 01.png - 18:55 and 04.png - 19:00. I have two more inbetween but the forum just allows 3 attachments.

The set up is, probably already shown in the log, but anyways:
* The current firmware version is v2.1.1
* 2 Aeon Multilevel 6 (gen 5) - id 2 and 4 in the job queue
* 4 Qubino

I've seen some discussions about jobs stuck in queue on the forums but actually no explanation or what to do about them. Would _really_ appreciate if I could get some feedback about this .

Cheers.

I just upgraded to 2.2.0 and thought it would solve my problem, but unfortunately no luck . Same problem. Maybe it has something to do with communication, but shouldn't the server be able to handle this? If I look in "Timing Info" the sensors have a couple of % of failed attempts.

I'd say it looks normal. Don't look at them as stuck, the Aeon multisensor sleeps between the messages it sends; the next time it wakes up it will respond to the messages in the "queue". I get that with my Aeon multisensors.

ok, thanks a lot for your answer. I think they are stuck there even after the wake up, but I'll have to verify that and pay special attention to the logs on wake up.

It is normal for battery devices to stay in the queue for a longer period. Definitely if you poll them more often than their wakeup frequency. If a new command is sent to the queue it does replace the one at the top that has'nt been handled yet.
Do you see the values of of your sensors changing, or ar they stuck as well?

Yes the values of the sensors are updated, but even this feels a bit "shakey". Sometimes the values are not updated until a second wake up. Some other times only some values of the sensor is updated that time. For example if you look at the pic you can see that the last wake up was 18.13 and 18.14 (for the two multi sensors), but NO values were updated. In addition, the values should have been updated at two different times, but the have obviously been updated at even more different times, since they didn't get updated when they should have:

Temperature: 18.08 & 17.59
Luminescence: 17.58 & 17.29
Ultraviolet: 18.08 & 18.09

etc. In other words - total chaos

and the job queue (if of any interest) looked like:

There seems indeed a lot of jobs (10) for Aeon device 4 , and only (2) for device 2 waiting in the queue. I am not very familiar with reading these queues. I do spot for example in the buffer the pattern (4 4 31 4 1 0 5). As far as I understand the same command should not be twice in the queue.
- Does device 4 show up more often in the queue than device 2 ?
- Have you tried to exclude and then re-include device 4? Sometimes that solves a problem

I have had myself a problem with a "hanging queue", but in that case there were no more device updates at all.
I found out that my queue got gradually emptied if in ExpertUI I pushed for example an update button of one my binary switches, or any other sensor of a wired Z-Wave device.
Sorry can't point you to a proper solution

Thanx a lot for your input, much appreciated! Didn't know the catch about the buffer pattern - same command not being twice in the queue, good to know.

I first thought it had something to do about the timing for device 4. Seing the pic above shows longer times and more failed communications. At that point, if I remember correctly, one value was not saved into the device. I fixed that and now at least the statistics in "timing info" is approx the same as for device 2.

Yes, it looks like device 4 shows up more often. For example at this moment the queue length is 27 and there is only 5 device 2 entries.

I'll try your suggestion about excluding and including. "Luckily" it's more easily done than for the in-wall switches.

I just tried pressing "Update from device" for one of my switches, but it did not do anything to the queue .

I am afraid I can't help you much further. Have you tested your setup with both devices near to each other 1-2 meter?
Maybe there is something just wrong with Device nr 4.

I hope the Zwave.me team can have a look at this problem