Serious z-wave problems


#21

When inspecting my ozw_log file, I see that there is some communication from devices that don’t exist! There are Nodes 150, 247, 172. This happens very early in the log file, with entries like:
019-01-08 21:52:14.208 Detail, Node173, Expected reply was received
2019-01-08 21:52:14.208 Detail, Node173, Message transaction complete
At first, I thought they were “ghosts” from before I installed the new stick, since I haven’t reset all the devices yet. But these numbers weren’t there in my previous configuration either.
What’s happening? Is this something to worry about?


#22

Those are high figure nodes. Did you reset the Aeotec stick and clean out HA? (I’m asking just to be sure). Or do you have 150-170 nodes?

I’m thinking if your mesh network is really reset or if they try to associate with neighbouring device that doesn’t exist and then it times out.

Short term, I’d make sure you run the heal network between adding devices, to make sure that they take the fastest route to the controller and back.


#23

No, I don’t have 150 nodes. At the moment I have moved 30 nodes to the new stick.
Maybe, in the old HC2, i had node numbers that high due to many attempts to include some of the devices.
I do, however, have some popp smoke detectors that are still connected to the no-longer-existing HC2. I don’t think they had so high numbers there either.
Is it possible that one or more of these are causing trouble by sending and interfering with the new network? They are set up to send only when there’s smoke detected.
I’ve started moving them to HA now, and the 2 that have been moved work fine, but have long reaction times like everything else. The remaining 5 are harder to get access to, but I’ll move those as well.

The stick was reset to factory settings. I checked that it had no devices before I started adding new devices.
I try to remember to heal the network after each add.

One of the things I find strange is that when I turn on a light from an associated wall controller (aeotec or popp), the light responds immediately. But when I turn it on/off from the web page or iOS app there’s a delay. This might be an indication of a server-related problem, but I don’t know where to look.


#24

If you’ve factory reseted all your nodes and moved 30 of moved them to the new stick, then something is really not right. You said you went through this device by device and removed them from z-wave network. So that seems out of the question.

If you check the Z-wave Panel, what are those Nodes?

Interference
Frequency interference wouldn’t show in your OZW-log. You’d just be getting really slow and faulty responses.

Battery devices
I highly doubt that battery devices will cause your z-wave network to slow down. They are always end nodes (don’t transmit to others) and usually they are in sleep mode.

Slow on server side…
Could be, you’ll have to check the logs. Some devices also work poorly in secure mode with OZW compared to non-secure.

You can also change your z-wave security key if that helps.

Z-wave Graph
Have you tried to setup a z-wave graph in Home Assistant? It will show you node association and RTT (round-trip-time). This info is also available in the z-wave panel if you check Node Information for that device.


#25

The mysterious devices (150, 173 and 227) don’t exist in my network. And they don’t exist in the controller (I’ve checked it with Aeotec’s controller software). They appear early in the log, before 30 seconds after restart.

Battery devices I never though of my smoke detectors as battery operated, since they’re on permanent 230V supply. But of course it’s the battery that runs them. So I guess I don’t have to worry about them.

Delays I looked at the log from switching on a light via a central scene and Node Red from an Aeotec wallmote, to a switch in a qubino flush 2 relays that’s 5 meters from the stick, and has it in it’s neighbours list. I did this twice. The log says the following:

Time from button pressed and to “Queuing (Send) MultiChannel Encapsulated (instance=2)”: < 12ms.
from there to “Sending (Send) message (Callback ID=0x89, Expected Reply=0x13)” it took 9,3s and 7,7s respectively.
Total time from button press to receiving “Value changed” was 9,5s and 7,9s.

Where does all this time go? In the server or in the z-wave stick? Ths server seems to be reacting fast enough on the keypresses. The stick is more difficult (for me) to debug.

Nothing in my new network is added securely.

Interference Is this possible to find without special equipment?


#26

I don’t know where the mystery devices come from. If you’ve re-added them to a new stick, this sounds odd.

I’m not 100% on how OZW works. (HA 0.85 seems broken though. Perhaps HA 0.86 will have a fixed OZW.). But I get the impression that the controller runs sequential. So once you have a hick-up in the command chain (for example waiting for a response) and it doesn’t show-up, it seems the controller waits until it times out until the next command is processed. I have this problem with some wall-plugins. It just sits there until I have a time-out. Then it runs the next command.

I think interference is hard to measure in general. If you have no other devices running there shouldn’t be much though.

My guess is that you have something weird running in your zwave network that stalls the OZW command and makes it slow.


#27

I think someone mentioned it above but have tried to check the entity/core/device registry files in the .storage folder to see if they are lurking around in there somewhere?