OK, I think that’s clear. I’ll give it a test and then post the Javascript code here later (the Javascript examples are all empty on the helper libraries pages, unfortunately).
You should be able to figure it out from the Python examples as it works the same way. Remember, all this stuff you are working with are actually Java anyway.
I don’t think I’ll do this in the end because it would mess up my existing code, and I’m pretty sure all my data sources are set to Celsius.
Last night I decided to bite the bullet. I excluded all of the devices from the Zipabox, including the Z-Stick itself, then inspected the Z-Stick in the Z-Wave PC Controller (aka ZenSys tool). To my surprise, it reported the Z-Stick as being the primary, so I didn’t reset it as I had planned. I started re-including all the devices on the Z-Stick until I had just two left which didn’t seem to respond when trying to include them. I focused on setting up the things for the included devices, and then went back to try and include the remaining ones. Now, suddenly, the Z-Stick refused to include anything: instead of a flashing blue light, the blue light flashes once and then an orange light flashes, and that’s it. The same thing happens when trying to exclude a device - you get the orange light and then nothing. Inspecting the Z-Stick in Z-Wave PC Controller, I see that it now says “Network role: SUC, secondary”. I must have done something, but I have no idea what.
I made a separate post on this to see if anyone can help. I’m 98% of the way there. Argh.
I noticed that one of the “Alexa guard” things from one of my Echo dots was in the “unknown” state (State not found) whilst the other two were fine. I discovered why: that particular Echo dot seems to need rebooting occasionally, like so many devices containing software, probably because of resource leaks. Just unplugging it briefly and plugging it in again brought it online. Later I think I’ll attach it to a socket so it can be rebooted automatically.
Another offline thing problem that I have partially solved: when I completely shut down openHab, as opposed to merely rebooting, all the Modbus things associated with my Brink ventilation unit remain offline on restarting. If I unplug the Modbus gateway briefly and plug it in again, most of them recover, but not a couple of the write register things. I’m not sure if the fault here is with the gateway or the binding, but the write register things can be recovered by disabling and reenabling them, which I do automatically in my rules. It’s possible that doing the same with the bridge might be enough to bring everything online, without power-cycling the gateway. I’ll try it. I posted the Javascript/JSR223/helper libraries code for enabling and reenabling things elsewhere, but if someone can’t find it I’ll post it again.
Just disabling and reenabling the bridge does not correct the problem, nor does disabling and reenabling each Modbus thing. Power-cycling the gateway seems to be indispensable.
Aeotec have suggested a procedure to try to solve the Z-Wave situation, but I’m a bit dubious because it involves the same PC controller software I already have. We’ll see.
In the meantime I notice that, around 50 minutes after the programmed Z-Wave “network heal”, half of my devices go into the “not communicating with controller” state, which is rather the opposite of what you might expect from the word “heal”. For now I’ve turned heal off. This morning I found the heat pump turned on (the clue came from the house’s power usage) but the heating off according to openHab. The reason was that the actuator switches couldn’t communicate with the node and were shown as “off” when, presumably, they were “on”. All rather unnerving when you’re dealing with valves and water pressure.
Let’s see if resolving the general Z-Wave controller situation helps any.
You might check if openHAB’s view of Item states was UNDEF (“don’t know”). This gets represented in UI switchy widgets as “off”, seeing as it is “not-on”. But rules can distinguish OFF from UNDEF and perhaps take some failsafe action or alerting.
1 Like
Yes, that was exactly my plan yesterday. I tried to force the error by setting “network heal” for a time when I could watch what happened… and of course nothing happened. In any event, I’ve created a rule whereby if a decent number of Z-Wave devices are not online (an easy test), it will reboot. A reboot seems to cure it every time. I don’t know if there’s a way to reboot a specific binding programmatically, which would be even cleaner.
One thing I learned yesterday was not to shut down (or perhaps restart OH?) whilst a backup (openhab-cli) is underway. It completely killed my SD card, stone dead. Fortunately, an openhab-cli restore from a backup from the previous day (they run daily and are also copied to my PC daily) on top of a card backup from just before Christmas completely restored the system. I always have the latest changes on the PC anyway.
It was a mistake to programme the backup earlier so that the PC could copy it before shutting down for the night. Better to have it run during the depths of the night, when I’m quite unlikely to be awake (you can never rule it out), and then have it copied whenever the PC wakes up.
What I’m not sure about is what happens if you try to restart the openHab service via script when the opencli-backup is running. For safety, I’ll disable those reboots when the backup is running.
You can do this from the karaf console so should be able to get that to happen with executeCommandLine. There are several tutorials on the forum.
What probably happened was the machine didn’t wait for all the write processes to complete before killing power. When a machine loses power while writing to flash it not only loses the file lost, it loses anything else that happens to be stored in that sector being written. Thanks to wear leveling, that means anything can be in that sector: parts of the kernel, file system tables, boot sector, etc. So when reboot killed the power, you probably lost something important to the file system.
The card itself is probably OK to use, unless this was just a fluke coincidence and the card is actually wearing out. That’s pretty unlikely though.
You shouldn’t have the same problem just restarting openHAB instead of the whole machine because the machine will never lose power. However, when OH shuts down it dumps a whole bunch of stuff to disk, including JSONDB which means there will be all sorts of files changing while the backup is ongoing which is often not a good idea. It can result in inconsistent or even corrupt backups.
1 Like
I’ll look into it!
The safest way is definitely to avoid reboots during backups. I’m already setting up so it doesn’t happen.
When I put it in the card reader it doesn’t even appear as an unformatted card 
. I’ll have another look at it today if my mild vaccine-induced fever clears.
Well, then it’s probably toast but I’m not sure that it was directly caused by the backup happening when the machine rebooted. Something else was likely the cause as anything that would have happened with this scenario would have happened at the file system level, not the hardware level.
Samsung and others make SD card utilities that might be able to recognize the card and reformat it.
1 Like
This time I set network heal for 20:00 and a load of Z-Wave devices went offline as before. Auto-rebooting cures it. I’ll disable network heal anyway.
For completeness I’ll repost here my account of my fight to reset the Z-Wave network.
Last night I set about trying to reset all my Z-Wave devices (and the Z-Stick). I tried to maintain the order in which I added the nodes, to avoid having to reconfigure the devices in openHab. With many devices, there’s very little or no feedback to tell you whether the reset has worked, so you’re pretty much flying blind there. Then I tried to add them all again, fully expecting problems. And there were problems, lots of them.
The SIR-321 RF Countdown Timer was the first device I tried to add, since it was node 2. I can’t really say what was wrong, or what worked. I tried resetting it, adding it and excluding it numerous times until I finally managed to get it included, as node 3. One thing I learned: once a node is used, it can’t be “reused” until you do a “replace” in the control software. The new node IDs start from the maximum ID used at any point since you reset the controller.
The Aeotec multisensors, Qubino smart meter and Fibaro sockets didn’t really give me problems. They were straightforward to reset and include.
The Fibaro flood sensors are a little trickier since they’re battery-powered. Sometimes they get included in an incoherent state where certain channels never update, or you can never modify configuration parameters because every time you click save they are immediately replaced by the defaults (no matter how many times you press the TMP button you never see “pending” and the new values are never saved). In a few cases I had to reset the devices again and add them again.
The single Düwi socket I still had did not have a reset procedure. They apparently hadn’t thought of it. It was always a horribly unreliable device, turning itself off at random like the other two I used to have. Good riddance. I already had a Fibaro as replacement.
The three TKB sockets were a headache. The official reset procedure from the manual (Press on/off button 3 times within 1.5 seconds; within 5 seconds, press on/off button again for 1 second until LED is off) doesn’t work. What works is doing the exclude procedure, even if it’s a new network where the sockets were never added. I was ready to throw them all away until I found the post explaining this.
The nightmare: the Fibaro FGS 222 relay switches. The official procedure is to reset by holding the B button for 3 sec. after connecting the mains voltage to the switch (implying that you’ve cut the power previously). During all the tests I did, once one of them seemed to get included without even doing the include procedure after cutting the power, but since I didn’t know which of the two it was, I removed it again. After that I failed utterly to include either of them. I tried every reset procedure I found online, including pressing the B button for 3 seconds, then cutting the power, then pressing it again (maybe?). The consensus seems to be that you need to cut the power, then press the B button as the power is restored (i.e. it requires two people). I can’t get anything to work. Since I also failed to attach physical switches to the relays to operate them manually when I have problems like this, I’m seriously considering throwing them away and buying something else. But I don’t know what. They control the heating and cooling, so this is no trivial matter. Fortunately I still have a gas boiler I can switch to in the cold weather.
All the rest I managed to add, most of them with the same nodes.
I was up until 7:30 in the morning fighting with all that lot. It really underlines how unrealistic a prospect this sort of thing is for non-tinkerers. At least one person has seen me wrestling with this stuff and the insane number of hours I spend on it, and said “and you want me to put home automation in my house? I don’t think so!”
I’ve finally got the relays added to openHab by replacing them with a newer model, FGS-224. I don’t know whether it’ll be possible to salvage the old ones.
My system is now essentially complete, and the Zipabox is sitting in a drawer. It’s taken two and a half years.
I managed to get the restarting of bindings from rules working, following this tutorial, not without difficulties:
I’m using it to revive Sonos speakers when I get the “not registered” error, but for some reason the grouping of speakers is not always working correctly.
I’ve also found another case where a timer-based rule is being paralysed because the rule does too much waiting, causing my blinds not to open this morning. As I’ve done elsewhere, I’ll use a switch item as a trigger for the code involving the waiting, so that the thread executed by the timer-based rule can exit.
Then I have to delve deeper into the whole SD backup situation.
1 Like
The Sonos speakers are now grouping reliably. After restarting the uPnP binding, I disable and re-enable any speakers that are not online. That seems to solve everything.
I’ve confirmed that, if I use a larger SD card to restore an image (say, an 8GB image on a 16GB card), on taking an image from the larger card is still occupies the same, smaller, size (8GB in this case). If I remember correctly I’m using an option with dd that truncates the image - this doesn’t seem to do any harm (the resulting card works fine). This solves the problem of cards that are slightly too small, whilst avoiding a ratchet effect whereby each cycle doubles the size of the card, until they contain more gigabytes than there are atoms in the universe. 
The remaining problem I have is that reading the cards sometimes leaves my card reader in an unusable state, forcing me to restart the OS. I would use my desktop, which I don’t mind turning on and off, but it has Windows 7 and I can’t get Ext2Fsd to work on it.
I solved the Roomba problem - I was using the wrong password 
. When I tried to get the password again and couldn’t, I assumed the firmware update had changed the password, too, but it hadn’t. Yesterday I used the newer Python scripts to get the password again, and then discovered that I already had it. . So now I can use the battery level and state in my rules.
The one remaining problem is including the Nexa socket. I want to use it to reboot the Modbus gateway, which frequently seems to cause most of the Modbus things to go offline.
Turns out I need a remote for the Nexa socket. There’s no other way to get the code in RFXmngr.
I discovered that, to get timely power consumption updates from Fibaro wall plugs, you need to use the sensor_power channel, incorrectly labelled as “kWh”, not meter_watts, inaccurately labelled as “instantaneous” (it is very much not instantaneous: it updates every ten minutes or perhaps even less than that).