Moving toward Z-wave and Zigbee

It depends… There are many things that will influence the range, including the noise environment (ie other electronic devices), the way a building is built (eg wood/brick) and the devices themselves.

Generally, I would suggest to keep devices within 20 to 30 feet. ZWave may have slightly better range due to the lower frequency, but note that ZWave mesh can only handle 4 hops where ZigBee can run much further.

1 Like

I hooked up an SSD with this case.
https://www.amazon.com/gp/product/B07K72TY63/

1 Like

Burned out how? I’ve an RPi 1 that has been happily running strong for almost a decade now. In fact, I’ve never had any RPi “burn out,” and one of them has spent the past five years mounted to the wall in my garage (very wide temperature swings).

Perhaps you’ve experienced problems with the SD cards? SD cards do in fact wear out and how quickly they wear out depends on how often the RPi writes to it. More writes means faster death of the SD card. And when it does wear out the behaviors you see can be bizarre like random kernel panics, files that you change but revert back to their old version, files just will not stay deleted, etc.

Another source of problems with RPis can be power losses. Again, this is more of an SD card issue, though it is is present on any storage media. If the RPi happens to be writing out to disk when power is lost, you run the risk of losing not only part of the file you are actively writing to but other files too, like maybe a device driver in the kernel which will cause kernel panics next time you start up.

Finally, RPis are sensitive to the quality of the power they are fed, particularly if you have some power hungry accessories plugged into the USB ports.

All of these can make it appear that your RPi has “burned out” when in fact the machine is just fine. You just need to replace/rebuild the SD card or find a better power supply.

As for openHAB, hundreds to thousands of users of OH have successfully run openHAB on an RPi for years without even the SD card problems described above. But there are lots of mitigations one can use to avoid the problems described above as well. For example, openHABian, a set of script that will set up an RPi to run OH and related software, includes an option to configure OH to run in zram. This means that all the writes are taking place in RAM, not on the SD card. This also means that should you lose power you are not writing to disk so you won’t risk corrupting the disk. Lots of users opt to use an SDD and add battery backup as well.

But if you are keeping backups like you should, replacing and restoring a worn out SD card shouldn’t take more than a few minutes of your time. Some people keep a spare SD card in a known location and train their family to just swap out the cards when something goes wrong.

If I were not running my main openHAB on a server in a VM, I’d be running my main OH on an RPi. My remote instance of openHAB is running on an RPi. And this device is 100 miles away so I need it to be reliable as I don’t have physical access to it. It’s been running dead solidly reliable for two years now on an RPi 3.

For future readers. The configuration for HABPanel is either stored on the device where you created it, or you can have it saved to the server (highly recommended you use this option). Then if you use openhab-cli backup your HABPanel configs will be included in the backup.

If defining your own backups instead of using openhab-cli, make sure to include /etc/openhab2 ($OH_CONF) as well as /var/lib/openhab2 ($OH_USERDATA) minus the cache and temp folders. That will preserve all of your OH configs no matter where or how you’ve made the configuration changes.

When running off of SD cards, periodically creating duplicates that can easily be swapped out is also popular.

I’ve no experience with SmartThings, but I do know that if it has the Zwave logo on it, it will work with OH using the Zwave binding. I know a lot of SmartThings users migrate to OH because SmartThings’ device support isn’t as good. If these are new devices, you might have to wait a few days for it to be added to the database but it will work.

I’ve less experience with Zigbee, but my understanding is the same is true if the device as the Zigbee logo on it. Where people run into trouble is for devices that use Zigbee but add to it like Tadfri and Xiaomi. They don’t claim to be Zigbee compatible so whether or not an individual device is supported is hit and miss.

I use the HUSZB-1 for production and am very happy with it. It’s a very popular device here on the forum.

For Zwave I believe it’s 232. Zigbee works a little differently and I’m not the best person to explain it. But I think the number of devices isn’t constrained by the coordinator itself so the number of devices it can support isn’t relevant. A Google search says 240.

Anything that bears the Zwave logo is compatible with anything else that bears the Zwave logo.

Burned out as in it will no longer work. It’s not an SD card issue as I’ve at times had multiple PIs and could swap in a known good SD card that was still running fine. Ditto the power supply (and I don’t typically use any USB devices). My typical use case in the past has been as an XBMC client with power supplied via a TV USB port. At some point, every single one of my PIs has simply quit working, and would no longer load anything.

I’m certainly willing to give it another try at some point, but for now I have an intel ATOM based system that I can use.

True - but backups don’t help when the board itself is fried.

In my case it was on the server, but it was in a different place (apparently) than the rest of my configuration. I’ll keep your advice in mind for the future.

Well, the Xiaomi sensors claim to be Zigbee, but they don’t appear to work with most Zigbee hubs. I was just trying to make sure this wasn’t a similar situation.

Within the same world region. I think ZigBee devices are worldwide.

Not if they’re made by Xiaomi…

Yes - even if they are made by Xiaomi. They are still world wide as they use the standard 802.15.4 protocol in the 2.4GHz band, which is the same allocation world wide.

1 Like

So the OpenHab Zigbee binding will work with Xiaomi sensors?

Yes, they work with the ZigBee binding. They are a bit problematic due to the way they work, but that’s certainly not a regional issue as per your statement above.

Many people are using Xiaomi devices with the ZigBee binding - on the other hand, others have problems with getting them working well, but again, it’s not a regional issue in any way,

How do I get something added to the database.

I just looked here, and don’t see the GE 14297 Fan Controller on the list.

This is a community maintained database. The guide is here.
What is required us the xml file generated by OpenHAB along with a pdf of the user guide and an image.
Either you can then add it or somebody else here can do that.

After the entry is approved, the database is uploaded to GitHub once or twice week. The database then gets picked up bu the build process into a snapshot zwave binding. You are then able to update just that binding, if needed.

I’m completely stuck trying to install the HUSBZB-1 stick. Trying to search for the Zigbee or Z-wave stick gives me nothing at all. I’ve verified that /dev/ttyUSB0 and 1 exist and dmesg shows that the two ports were added when I plugged in the stick.

Here is what I’ve done:
Plugged stick into USB port
Added openhab to tty group and put in the extra JAVA options and added the serial binding as noted here.
Confirmed that OS sees the stick
Added Zigbee and Z-wave bindings in PaperUI
Went to Inbox and “Search or things”, selected “Z-Wave Binding” and then “Z-wave serial Controller” and set the serial port to /dev/USB0. It creates the thing, but it says “OFFLINE - COMMUNICATION ERROR”
Tried adding is as a zigbee stick using manual and selecting the Ember EM35x Coordinator and setting it up like the picture here. Also communication error.

Am I missing a step?

You should be able to select it from the dropdown and it is usually /dev/ttyUSB0

image

Maybe it is related with this:

Only needed for Zigbee, not Z-Wave

I just did it, you got everything right
maybe restart openhab if you haven’t otherwise, relax, it takes a few minutes

1 Like

What do you mean by this?

The ZWave binding doesn’t support searching for sticks at all - you must manually add the stick. I’m also not sure if the ZigBee binding will do this either - the USB search doesn’t work on all operating systems, and probably won’t work for all sticks. Just do this manually.

It shouldn’t be required for ZigBee either if using the Snapshot.

1 Like

There is no dropdown - but that’s a typo in my original message. I did set it to /dev/ttyUSB0. It’s just a text box to type the serial port into.

Note that when I click through to the Z-wave Serial controller it gives additional error information:

Serial Error: Port {0} does not exist

As mentioned, I’ve confirmed that /dev/ttyUSB0 and 1 exist. They are not there when the stick is not plugged in, and they appear once the stick has been plugged in.

I tried a restart. Same behavior.

If I do a search for new things, I don’t get anything automatically detected. Maybe I should’t have expected that. So I did add the stick manually for both Z-wave and Zigbee; but both show communication error.

I installed the bindings using PaperUI - what do I have to do differently to “use the Snapshot”?