send queue hanging (z-way-server v2.0.0, v2.0.1rc7)

[Mirar]

Is there anything special with reports that makes them take up extra network space? z-wave should at the lowest speeds handle about 100 packets per second (including retransmissions, naks and acks), if I get it correct?

Is there any way of logging network saturation level?

Network works fine hours at a time, sometimes days.

[PoltoS]

Once it run correctly, look on how many packets are there in the network.

Basically Z-Wave can handle about 50-100 packets per second, but many Serial API is not always so fast to transmit data to the OS. Once you start Z-Way, it have to talk with the dongle a lot (sometimes over 500 packets to get all the info). And unsolicited reports can make it hard to talk to the dongle.

But we have never seen this before in form like you show it. So, may be it is an UART problem,

[Mirar]

But we have never seen this before in form like you show it. So, may be it is an UART problem,

I can try with another raspi. But the other two I have is B+. Is that a problem?

(Assuming the UART is on the side of the raspi.)

[PoltoS]

B+ is fully supported.

[Mirar]

I'm back home now and installed it on the B+ (the new 8GB micro sdcard was about 10M smaller than the old one, so a bit of partition fuzz, sigh).

Seems like the problem persists:

Code: Select all

[0.16881003975868225,[3,0,0,0,1,1,1,1,1,1,0,0],16,"SwitchBinary Set","Could not be delivered to Z-Wave stack\nRemovin
g job due to too much retransmitions",[16,3,37,1,0,37]],
[0.13781015574932098,[1,0,0,0,1,1,1,1,1,1,1,0],6,"Meter Get (v2)","Delivered",[6,3,50,1,0,37]],
[0.17780674993991852,[3,0,0,0,1,1,1,1,1,1,0,0],6,"Meter Get (v2)","Could not be delivered to Z-Wave stack\nCould not 
be delivered to Z-Wave stack\nCould not be delivered to Z-Wave stack\nRemoving job due to too much retransmitions",[6
,3,50,1,16,37]],
[0.17880620062351227,[3,0,0,0,1,1,1,1,1,1,0,0],16,"SwitchBinary Get","Could not be delivered to Z-Wave stack\nCould n
ot be delivered to Z-Wave stack\nCould not be delivered to Z-Wave stack\nRemoving job due to too much retransmitions"
,[16,2,37,2,37]],
[3.7848150730133057,[1,0,0,0,1,1,1,1,1,1,1,0],16,"Meter Get (v2)","Delivered",[16,3,50,1,0,37]],

I have a script rebooting z-way-server on three strikes of either multiple "0.2000" queue entries to nodes that aren't battery powered or "Could not be delivered to Z-wave stack".

What does the "Could not be delivered to Z-wave stack" mean - is that from the the Sigma or something internal in z-way-server?

(If the new Sigma hardware has a chance of behaving better, I might upgrade. Opinions?)

[PoltoS]

It means Z-Wave chip answered that it can not accept it right now

[Mirar]

I will get a gen5 razberry to see if it works better.

[Mirar]

While waiting for the gen5, I've had some more issue but also a suspicion.

I had problems with an Everspring AN158 node. It kept answering on pings, and the first command worked, and then it quit again. Eventually it didn't even answer on commands until I reset it with unplugging. It didn't seem to want to get online much anymore, so I tried to replace it; it didn't work very well, or the alternative AN158 didn't want to play either. I removed both from the network.

One night or two later the z-wave stopped being able to get anything sent. Until I unplugged both of those AN158 devices from power. Then it started to work perfectly.

Is there any way of checking how full the z-wave frequency spectrum is? (Like counting packets aimed at another network/home?)

So right now I suspect that I've had nodes spamming the z-wave frequency spectrum intermittently (but not visible in my network/home). And that the sigma/z-way is a lot more sensitive to this than the TKB switch I've been comparing with. Does that sound plausible?

[Mirar]

I failed to add the gen5, giving up for now. It can't communicate with the gen3, so I can't switch controller. Restoring backup fails because homeId is never set from the backup. If it's vaguely interesting I can post logs.

[PoltoS]

Restore on 5th gen is fixed - will be available in next rc12.

As for network jam, we have seen once a plug jamming network (may be even Everspring, but not sure). Of course controller is more sensitive to it, since it needs to talk to all devices, while plug only with controller