do you have any idea what went wrong in my case.
I moved from one vendor to AEOTEC Gen5 Stick, and did the cleanest way - as i had some strange behaviours in the network (as you may remember) and wanted to start from scratch. So i excluded all devices and manually included all to the new stick…removed all things in PaperUI and did a scan with the new stick…which found all things from zwave again…of course with different number…also created of course before a new Controller thing.
The binding identifies only for a few things the vendor so the properties and channels are correct, however most only show zwavenode…or zwave node (+ an address similar to MAC)…i knew this may be the case in the beginning, but after 1 day still no resolution…
The ones that are recognized correctly, work as before transition.
I already tried clear cache/tmp and remve xml files…nothing helped…removed things again and did a new search…
Any idea what went wrong? I’m on Build 1077…until build 1070 it worked fine with the previous stick.
Not all devices are resetted to default when excluding from the network.
I would grab one of the devices which does not work, reset it manually (procedure should be in the manual) and include it again …
thanks for the insight…
as i’m not a deep expert in zwave its little unfair to complain but i really do hate zwave management of the controller and insertion of nodes. its a nightmare to remove nodes from the stick, its a nightmare to add items to the new stick that are in a remote location not easy to reach…does this work easier when buying out-of-the-box controller units? i guess no as otherwise openhab would have implemented something similar…
Final question: what is required in openhab when moving forward from one stick to another…cache, xml-zwave-files removal? or nothing at all and the system will clear itself…except rewrite of items file and adding of new things…
If you are using the same node device id (the part before the node number in channel="zwave:device:15ca6a108b9:node10 ...) when adding the stick as thing nothing else should be required … theoretically
hm…guess you have seen this before…FIBARO is not that enthusiastic about RESET…any idea why this is such a big deal? or is FIBARO in fear that the existing controller may get in trouble if another NODE-ID shows up even if the same device…like in your 40NODES network…
Resetting the device is not the recommend-ed way of removing the device from the
Z-Wave network. use reset procedure only if the primary controller is missing or
hm…i now reset the controller stick + all devices (a variety of vendors and types of nodes).
Again…like the Evergreen AN158 is recognized instantly after inclusion.
Fibaro WallPlug not even after several trials to send info packages, the same for a Fibaro Flood Sensor…
highly annoying as i have not clue how i could force Openhab2 and these nodes to get recognized as what they are… @chris , any idea what I’m doing wrong…
I use both HABmin and PaperUI for inclusion and exclusion of my ZWave devices. If you use, for example the Aeotec ZStick Gen5 you can also use the stick standalone for in-and exclusion but I’ve found HABmin to be the easiest and most reliable.
For management of my ‘things’ I prefer the text based config using ‘.things’ text files but it’s as of now only supported by.the ZWave test binding and not the released version.
I can share your frustration - unfortunately, if you search around the web you will find lots of people with problems on different controllers and different devices. This sort of thing is always difficult, and also isn’t limited to Z-Wave - ZigBee has similar issues - it’s fine when it works, but if a device doesn’t join the network, then there’s just no information available without special tools . The inclusion and exclusion are all handled directly in the controller (ie stick) so the binding only has the responsibility to enable and disable the mode (I exclude security here as that IS handled in the binding).
Anyway, that is inclusion - after inclusion comes the interrogation where the binding detects the device features, and this is where it decides what device type it is. I’m not sure from your messages if the problem is in the inclusion, or if it’s in the interrogation. If the device is shown in the inbox, then the inclusion has worked ok and the problem is then in the detection of the device by the binding. You can’t force this, but the binding should detect the device based on the information it gets - a debug log file is needed to work out what is wrong if things aren’t working as they should.
I surely have the same Fibaro Issue like others in the parallel threat. I right now bring my switches together to provide the requested information. Somehow still its strange as i have two switches included and one is shown as unknown device but online, the other device is not shown as online and again unknown…so its hard to find any property at all, tried ON OFF several times,…remove/plug into wall…nothing helps.
Sorry to do so - but i really have to share my frustration as a structured kind of person. what i hate most and suffer right now a lot - devices that (for whatever reason) generate a controller inclusion fail result in “lost Node IDs” as it then simply jumps ofter the next available NodeID and simply uses the next…so if the last was 20 now we continue with 22…and there is no way to “simply” see a table and remove such dead-nodes…if registered as nodes anyhow as Habmin does not show Node21 anyway.
Also - at least i had this now several times while including about 40 nodes…a node is included, its shown as available, i press “ADD”…its included as Thing…after a while, or with next SCAN the same NodeID is shown again in the “found Nodes”…so I press again ADD…even though its already in the THING list…at least, happy that there is not generated a second ghost element…maybe you know about this snapshot issue (if its not just me)…Build 1077.
It shouldn’t matter if there are node IDs that aren’t used - this is normal, and it’s just the way that ZWave works. The controller selects the ID that’s all.
I’m afraid that I’m still not sure at all what the problem is that you’re talking about - sorry. I don’t know if the inclusion isn’t working, or if the inclusion works, but the device is not discovered following the interrogation. Sorry if you’ve posted logs somewhere that I’ve not seen yet.
Please clearly describe the issue you have with adding a device. Please provide a debug log that shows the problem so we can see what is happening - I’m sorry, but at the moment it’s very unclear to me how I can help even .
Sure - i get it that some IDs in ZWAVE may be “lost” and it seems to be the way how zwave works - but i do not like it think about IP, if you have a Class-C network and from time to time you loose IP-addresses which are not useable anymore…you will be able to handle it as you start to simply skip these but hard to believe that this was standardized that way…but zwave is like that and anyhow after transition is finished with my zwave stick i will not have to deal with numbers anyway
Regarding my issue, sorry if unclear. I can include Fibaro Nodes…some are ONLINE some after inclusion create a Node but are OFFLINE all the time…but ALL of them are unknown devices. I would wait until you try to fix this current Fibaro WallPlug issue…to see if it all is related to this (the offlines maybe I need to reinclude…but lets see how it goes).
I already included the details you requested for the FW101-plugs in the other threat.
No - it’s not the same. Node IDs are not “lost” - they are just skipped. The controller will re-use unused values later. When the controller has allocated all 232 node addresses, it will then start at the lowest available number and continue to issue the addresses.
sorry, you are right. i’ve seen this before as my last NodeID on the “old” stick was 52 and the most recent inserted node received ID 2 as it was skipped/set free by exclusion some time before. Thanks for clarification! cheers Norbert
btw, another question related another observation we discussed before.
IsGetSupport FALSE in OH2…i changed it to TRUE and all worked fine the last few months.
Did you at that point incorporate into the main snapshot, or still needs to be changed manually? Guess this will be lost after transition to new stick, as nodeIDs will change and the XMLs as well.