I have just reset my master controller (aeon zstick) and when re-adding ‘things’ (one at a time) I have found my inbox says the wrong item.
I am trying to add a dimmer switch, and openhab thinks it’s a thermostat receiver (which is already added, and working).
Is there a way to force openhab to look up the device from scratch? I am 99% sure the node in question used to be the receiver, so would it be keeping the old description?
Also, a little off-topic, but openhab wont re-connect to the controller again after I remove and re-insert it, I have to restart the openhab service. Is this normal?
This is very odd behavior. Are running off of an SD card? If so your card might be failing. If not I’ve no idea except that this should not be happening.
This is normal. When the zwave binding starts it gets a lock on the USB device. When you unplug the device the binding still has a lock on that device so the file that represents the device (e.g. /dev/ttyUSB0) stays around. When you plug the USB dongle back in it can’t use /dev/ttyUSB0 anymore because /dev/ttyUSB0 already exists so it shows up on /dev/ttyUSB1 instead and OH can’t find it.
If you stop OH before removing the USB dongle, or do your inclusion of new devices from PaperUI or Habmin without removing the dongle then this problem will not occur.
There are also ways to create a link that lets you use the same path to the device no matter on which /dev/tty it shows up on, though I’m not 100% sure how well that works with unplugging and replugging in the device.
I am indeed, a RPi, wouldn’t an SD card fail have other ramifications? I mean I would expect to see other unexplained behaviour.
Is there an option for that? I have seen ‘Exclusion Mode’ but not anything to do with inclusion.
Interesting, where would I find this information, it’s not really vital to have this, but for adding and removing devices (especially those which might need to route) I do find it a lot easier.
It is always subtle, never predictable, and progressive but it never progresses at the same rate. But one of the big sign is when you open one file and get a different file (in this case, if I’m right, OH is loading nodex.xml and getting nodey.xml) or you delete a file and it comes back, log files fail to rotate, changes made to files become unmade after awhile, etc.
But the failures are highly localized. The whole card doesn’t wear out all at once. One sector at a time wears out as it reaches its max number of writes and stops responding. Since most of the writing that takes place on these systems are not done in ways you would necessarily notice unless you look for it (e.g. logging) it is possible for a card to be failing for quite some time with no outward symptoms. I had a card fail and never knew it until my log file filled the card because the log rotates were failing. Everything else worked just fine, though the longer I ran more and more problems would occur as more of the card wears out.
I’ve seen people say it is possible. I’ve never don’t it myself.
Search the forum for “symlink” and a bunch of posts will be in the results.
Thanks again Rich, I am beginning to think you are the only one who reads my posts. LOL.
I’ve looked at those ‘port pairing/naming’ posts and I have to admit, it scares me.
It’s no big deal to restart the server, I am surprised you can’t restart the server from any of the UIs (or even from a rule), that would be a handy little feature.
As for the duplicated item, I have also deleted the entire /var/lib/openhab2/jsondb folder (as suggested in another post I stumbled on) as well as the NodeXX.xml file in the var/lib/openhab2/zwave folder, no luck so far.
I have left the item excluded for over 4 hours now, maybe it needs time to sort itself out, I will try to re-add it and see what happens.
I checked that, since OH creates the xml of the node in the folder mentioned earlier, I could actually compare both xml files, they are identical, same manufacturer, same command classes, the node simply gets created as the wrong thing.
Success!! The node now shows as what it should do (although it didn’t take the same node number as before (it is 8 instead of 7), now I have a gap (who cares, it works).
Looks like patience (and some selective deleting) might just be the key here.
