Best practices for z-wave?

Add-ons Bindings
,
15

The nodes don’t need to be excluded/included again. Just delete the Things and rediscover them. Not painless, but also not too bad.

The need to do this was driven by a major redesign/restructure of the zwave binding in order to implement security. But, in addition to security, there’s also plenty of good stuff in the new version – faster, more reliable, nightly healing, UoM, etc.

I didn’t use @5iver’s script, but those who did use it found it very helpful.

We’ve all be through the transition, so there’s plenty of people who can help out if you run into trouble.

16

Things are new to OH2, and are not the actual zwave devices. As Mark pointed out, this does not mean excluding and reincluding every device. Chances are good that you haven’t even configured any of them, though there is some configuration that could be done… like polling interval. To clarify a little further, these configurations are specific to OH and are not the actual device configuration parameters which are stored in the devices. Those stay where they’re at.

If you haven’t changed any of the Thing configs, then there should be no issue to just delete them and then kick off a Z-Wave discovery to add them to the Inbox, and then approve them to get everything back the way it was. For ~20 devices, just do it manually. It’s a few clicks each. More than that, then you will probably appreciate the script. Worst thing that can happen with the script is that it doesn’t work, and you need to do it manually. Always good to have a good backup though!

Just give a shout if you have questions or run into trouble!

17

Yes, trouble. I don’t know what to say, because I realize of course that sometimes you need to break things in order to make it better. But, if 2.4.0 is to become a stable release, and people that then upgrade from 2.3 thinking it will be safe to upgrade, they will be disappointed I think. If you are a serious user of z-wave for your home.

After switching to M5 and running the script I now have this list of Things:

zwave:serial_zstick:edde6877 (Type=Bridge, Status=ONLINE, Label=Razberry 2, Bridge=null)
zwave:device:edde6877:node52 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 052, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node51 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 051, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node50 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 050, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node13 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 013, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node57 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 057, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node12 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 012, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node56 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 056, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node11 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 011, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node55 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 055, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node10 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 010, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node54 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 054, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node9 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 009, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node49 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 049, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node48 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 048, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node47 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 047, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node6 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 006, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node5 (Type=Thing, Status=UNINITIALIZED (HANDLER_CONFIGURATION_PENDING), Label=Z-Wave Node 5: FGD212 Dimmer 2, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node8 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 008, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node7 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 007, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node2 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 002, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node4 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 004, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node3 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 003, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node20 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 020, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node24 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 024, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node23 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 023, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node67 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 067, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node21 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 021, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node17 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 017, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node16 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 016, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node15 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 015, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node59 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 059, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node14 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 014, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node58 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 058, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node19 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 019, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node18 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 018, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node71 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 071, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node31 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 031, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node30 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 030, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node73 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 073, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node72 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 072, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node35 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 035, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node33 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 033, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node77 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 077, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node76 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 076, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node28 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 028, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node27 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 027, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node26 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 026, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node25 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 025, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node29 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 029, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node42 (Type=Thing, Status=ONLINE: Node initialising: GET_CONFIGURATION, Label=Z-Wave Node 042: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node41 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 041, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node40 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 040, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node44 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 044, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node39 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 039, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node38 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 038, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node37 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 037, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node36 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 036, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node70 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 070: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node46 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 046: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node68 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 068: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node45 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 045: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)
zwave:device:edde6877:node69 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 069: 004001 Smoke Detector and Siren, Bridge=zwave:serial_zstick:edde6877)

So, which one is which? The number of clicks to set up the things again and links is an issue, but knowing which switch is which is a bigger one.

Is there no way to migrate also Thing descriptions (and groups)?

18

Can you expand on why this is? From what I’ve read above, you’ve only just managed to get your system upgraded, and I’m not sure what the problems are that you are having with the binding?

19

I’m not sure what trouble you’re having. If your Things were removed and rediscovered, then everything should be good. Or are you still having trouble with the migration? Devices> Things> Channels> Links> Items. Coming from OH 1.x, you will have Items files, and your Z-Wave items will need to be modified to link to the Channel. You could also create Items in Paper UI, but they would also need to be linked to a Channel. Managed (Paper UI created) and unmanaged (Item files) Items can coexist too, so you can have a mix of each. Here is an example unmanaged Z-Wave Item:

Dimmer    US_DiningRoom_Dimmer    "Dining Room [%d%%]"    <slider>    (gUS_DiningRoom,gUS_DiningRoom_Action,gLight)    ["Lighting"]    {channel="zwave:device:07cb40a2:node36:switch_dimmer"}

In Paper UI> Configuration> Things> select your Thing, you can view the Channels, and there is a control to copy the Channel to your clipboard to paste it back into the Items file. You can also run smarthome:things show zwave:device:07cb40a2:node36, and scroll to the bottom to see the Channels. It’s the IDs that are the tricky part to find when migrating:

Channels:
        ID: switch_dimmer
        Label: Dimmer
        Type: zwave:switch_dimmer
        Description: The brightness channel allows to control the brightness of a light. It is also possible to switch the light on and off.

        ID: scene_number
        Label: Scene Number
        Type: zwave:scene_number
        Description: Triggers when a scene button is pressed

There is a tutorial on migrating too…

20

Sorry I mentioned OH 1.x at the onset. I was referring to the way you just added jar files to a directory back then to install bindings. I switched from OH back then and came back to now due to new developments. So I am not migrating a OH1 system.

Sure. Yes, it seems that I have almost all nodes set up and migrated to the new binding. So far so good. What I was referring to was that yes, I have a Thing for node 69 now in my system, but which device in my house is actually controlled by node 69?

I am sure I can go back to the backups I made before upgrading and figure it out and set all names again, make links with the proper names and all that, but effectively I am now starting over with the system.

I hope this does not mean that I will have to do this all again for every new release? Please tell me if I have misunderstood something, or missed a crucial step somewhere.

21

I’m not sure, but I don’t really see how that’s a binding problem as such. Your earlier message talked about people being disappointed about stability, but it doesn’t look like you have such stability problems?

22

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?

23

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:

org.eclipse.smarthome.core.thing.Thing.json
org.eclipse.smarthome.core.thing.link.ItemChannelLink.json

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,

24

This will not happen.

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.

25

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 :-).

26

I don’t disagree - it would be nice, but not possible without a lot of work, sorry.

27

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.

So, how should I do it?

28

I define the items for all my zwave devices in a zwave.items file (creative, huh?).

I use HABmin exclusively to manage the zwave things.

29

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

https://www.cd-jackson.com/index.php/zwave/device-initialisation

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…

30

FWIW, check out Configuration | openHAB

31

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”.

32

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.

33

@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 :wink: 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

34

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) ?