OH2 Z-Wave refactoring and testing... and SECURITY

Yes - probably worth a look…

I truly hate these Minimotes. I wish I had never bought them! :angry:

I think this is caused by a synchronisation issue related to the holdoff timer. I’ve given it a bit of a tidy up - please try the latest version to see if it’s any better.

Thanks.

Hopefully this is now resolved…

That worked perfectly… thank you! Didn’t even have to delete the Things!

1 Like

Alright, so I’ve added all of my devices again using Z-Way server after that unfortunate factory reset, transferred the SecurityKey to the Binding (although in small letters instead of capital).

Before shutting down Z-Way server I made sure and helped some devices reach 100% initialization.

What’s the difference between items called:
Z-Wave Node 058
and
Z-Wave Node 053: FGK101 Door Opening Sensor

They are both the same model.
Will the Node 058 change name after the initialization process (and therefore I should wait for it to change in the Inbox?)

Could this be due to the wrong SecurityKey? (Small letters)

Probably nothing. I’ve seen devices discovered both ways. I suspect it has to do with how the inbox entry and/or Thing are updated throughout the initialization process.

It might, and it might not. :roll_eyes:

Yes - if the information is available (ie the initialisation has completed enough) then the name is added to the node. If not, it’s just the node number.

If it’s still in the inbox, it should update the inbox entry. If you have already created a thing before the initialisation completes, then it won’t change the name of the thing…

Which, now that you explain it, makes perfect sense. Helps avoid the case where the binding overwrites a change I made to the name of the Thing. :ok_hand:

Edit: Which also explains why I tend to see this behavior more often with battery devices (due to the time it can take to initialize).

And just to confirm that the new version continues to be much much much more robust.

1 Like

Hey @chris
What happens, if I sends an configuration update to a battery driven zwave device. The device will receive the update, when it wakes up, correct?
What if I reboot the Openhab system in between. Will the update still go through anyway or is it lost and have to be send again?

Correct. The command is stored in a queue until the device wakes.

The queue is not persisted, so it will be lost and you will need to send it again.

Then I found the reason why some of my devices didn´t update the other day… Nice to know :slight_smile:

Anyone with a Kwikset door lock have quick drain of their battery? I can only get about 3 - 4 weeks on my door lock battery when I have zwave enabled on the lock and paired with OH. When I unpair the lock it goes for significantly more time.

I had one of these (the operative word is had). I can’t remember the model number. I was getting a couple weeks of life out of a set of batteries. Was driving me nuts.

Have you checked the polling interval. Maybe set it to something very long – maybe 2 days or 10 days.

I would second this. I have two networks – one with about a dozen nodes and one with almost 70. Both networks are running very, very well.

@chris Notwithstanding the change we discussed last night, from my perspective, this version looks like something that’s about ready to replace the current master version. Again, from my perspective, this version is at least as stable (if not more stable) than the current master, AND it supports security, AND it has a working heal process that runs nightly.

1 Like

I think I have a solution to this…

Thanks Mark.

@5iver - hows your milage looking these days?

Cool. Can I get that version from the link in post #1?

Yep - let me know if you spot any issues…

I’ll give it a try now.