No, I don’t know what the stability of the binding is. I am sure it is fine. What I said was that
that is, I would be very surprised to say the least if I hit the (virtual) upgrade button within openhabian stable and found that all my z-wave things were now named Node 32 and so on, with no information stored about the device or links to channels remaining. So I was referring to users using stable releases of openHAB and perhaps expecting a smooth transition between openhab versions. Not stability of the z-wave binding as such.
So, there is no way to get the previous names of Things back then?
It sounds like you do not have Items files, or your Links would still be there. If no other Things have been added/removed, you can restore your Thing names and Links by shutting down OH, and restoring the following files in /userdata/jsondb/ from backup:
You will run into issues though if the update changed any Channels in the Thing definitions, so you may want to diff the files to verify this first, and then update the backup files if there were any Channel changes,
Node numbers will not change unless you exclude and re-include devices which is not required. The binding will interrogate all devices and retrieve all data, and items should remain the same. The only exception to this is that if channels have changed, then there may be some changes here, but this is a general issue with database updates and not related to the update of this version at all.
I understand. But it would be nice to have also the names of devices retained when you switch from 2.3 to 2.4. Just a bunch of Things named “Node 69” and something similar, that used to be named “bedroom lights” and so on before the upgrade is almost a reason not to upgrade.
Correct. 99% of Things are set up in the Paper UI gui.
I will try this. And if it does not work then I just have to set up the ~60 things and 180 links again manually. Not a terrible thing if it is a one off event. If everything breaks in 2.4 M6 I will stay on M5 indefinitely :-).
No worries. If it is a one off thing then its just down to sittning down and doing it.
Relaterad to the original topic topic though - it seems that I am still advised to use item files for z-wave devices. Sounds appealing now that I will be doing lots of copy and pasting for identical devices once I have identified which ones they are.
But, how does this work then if you don’t use Paper UI for setting them up? Do you then configure them solely using Habmin? Or, do you make the things in Paper UI and then links to channels in items files?
What is the best procedure for handlings z-wave devices? Mind you, I do use quite a lot of the features of z-wave and the devices themselves. Like associations and settings, autoturnoff and similar (not so much alarm frames though) so I would prefer to have good access to the built in stuff.
Thanks! Please excuse me, but for me it was not obvious that while Paper UI / HABmin are good for setting up things, items are more easily set up and managed in items files - with the VS Code editor properly set up.
I enjoy the ease of making many similar changes easily (like adjusting the name of a group everywhere where it is used). Very nice.
Ok, to be honest I find (sorry) I find the terminology a bit confusing. There is a “heal” concept for a device, which once you get what “network heal” means, then it is not too difficult to figure out the rest.
And then there is “reinitialize”. I guess there is no standard terminology, but what I had assumed is that this is the process where the device is asked about its properties. z-way calls it interview, which seems like a good term for such a process, and it is described as “Device Enquiry” in at least one part of the docs for HABmin
But, the page linked to above actually describes initialization, including inclusion and enquiry, so how should one then understand “reinitialize”? I need to fix the interview /enquire stage for three devices that were not transfered correctly into 2.4 (with data about capabilities intact) but do I then really have to restart the entire initialization process? I would have hoped that there would be a “re-enquire” option somewhere…
The initialization process does not include/involve inclusion. Initialization is the process of the binding interrogating the node. The end result of initialization is the creation of a file in the userdata/zwave directory for the node. The file is commonly referred to here on the forum as the node.xml file
Reinitialize will remove the node.xml, which will cause the binding to run initialization again. It is in fact what you describe as “re-enquire”.
Ok, I understand. So, not so much a reinitialization of the device, but rather the information on the device kept within openhab (based on asking the device about what it does). Got it.
Sorry, I had not noticed this page. Very helpful for someone coming into the system, and find him/herself faced with lots of options (some of them less optimal). Thank you for pointing it out.
I think I’ve got a feel for how I should get the system running now, so i am marking it as done!
Thank you everyone for all the helpful responses.
@Fredrik_Karlsson what are ur results after updating to newest zwave snapshot?
I have an older snapshot release some month ago and I feel similar like you with openhab and zwave. Always trouble with the association sh** of zwave It’s absolutely hard for me to find the guilty… whether it’s openhab, the zwave protocol, zwave binding, fibaro devices, or user error which I dont believe anymore after that time.
So I stick also on the problem that devices working with pushing the current state in habpanel e.g. after pressing the hardware switch… and some days later it won’t work anymore.
looking in habmin on some devices the association config is completely delete (on some devices I use s1/s2 switch association where the configured thing is not configured anymore)… on some devices it is not delete but in both cases I dont get any state changed pushed as event. after reassigning the nodes in habmin again and pressing save, it is working again for some days. and this happens on too many devices (not on all, but on some of them) that I’m pretty sure that it is not a hardware fail. but who knows…
but it’s so frustrating that I’m sometimes thinking about to move away from zwave and/or openhab. a lot of users say they don’t have any trouble, some people also say they have the same trouble like me and all people who dont have any trouble saying it’s a user/config error. I’m not going to believe this anymore. there are too many bugs, not stable working features for me
Hi @chris,
I once again came across the issue with associations not being correctly displayed in habmin after changes… I vaguely recall you said you can’t fix it because something needs to be done on ESH level which you don’t have access/insight to (if memory serves me correct).
Did that change now that ESH is history ? Does that bug still exist at all in snapshots (can’t try; observation wasn’t mine and the guy was on 2.4 i.e. before ESH merge) ?
@mstormi There was a recent change that tried to improve this situation without fixing the broken widget code in HABmin (and Paper UI). I’m running a recent snapshot version of the binding and it’s displaying better in HABmin.
On my production setup I use one of the recent zwave bindings (may not be the latest). The issue with Habmin showing the associations is still there, cause it pulled a trick on me the other day when one of my devices behaved very strange. I thought it had lost the association. It didnt, it just behaved strange due to low battery. (Neo Coolcam motion sensor). But Habmin showed no association.
I am having huge problems with my z-wave setup. I feel pretty much locked in by the problems I am having.
Some background: I am using the Razberry 2 controller card, and have a network consisting of
63 devices that are mains powered
16 devices that are battery powered
7 devices that are FLiRS
none with secure inclusion. With the stable 2.4 binding, I used to have a stable network, but then I start losing mains powered devices, and then associations! Between device associations would not have been such a problem, but when Controller associations are going away too then I don’t any updates and the whole system becomes very unreliable and less useful.
I would strongly suggest to use the latest 2.5M2 binding rather than the 2.4 binding. the 2.5 binding has code that ought to prevent the associations being removed by the UI (even if the UI may show that they are not there).
Thank you @chris. I will do that, but with the issues that I then got into in 2.5
and the need to have a working system for living in, I fired up Z-way and got a working system there. While limited of course. It is a pity that I could not get the Z-wave binding to initialize the Aeon labs heavy duty switch properly, and some other devices, because that wold have been an acceptable solution for me.
It seems that I should create Things in 2.4, because devices are correctly identified there, and then move to 2.5 perhaps to fix associations. I will post results when I completed this move.
I would love to stay in openHAB, but stability in the z-wave network is essential for me since I decided to focus on z-wave when building my system.
I will try to provide some additional information on what I am seeing, once I have completed this process.
As I already commented in the other thread, it is hard to understand how that can happen. Devices really can’t be detected incorrectly - at least not systematically. It’s possible for device data to be received corrupted as the ZWave error detection is fairly poor, but this should be a one off, and not mean that lots of devices are incorrectly detected.
Unfortunately I can’t really comment further without more information. And unfortunately I can’t really comment further on the issues with 2.4 as that is a very old binding (9 months old) and the problems you are asking about here should be addressed already in the newer binding.
The detection of devices will be exactly the same in 2.4 and 2.5.
Thank you @chris. I will try to provide more information by getting everything back into a fresh 2.5-M2 openhab installation and see what I can report then.
It’s absolutely hard for me to find the guilty… whether it’s openhab, the zwave protocol, zwave binding, fibaro devices, or user error which I dont believe anymore after that time.