I am currently evaluating different smart home standards for my new place. At the moment I only have a bunch of Hue(and Tradfri) hardware. Since I am very happy with the hue gateway i want to keep it. But since it cannot to much besides lights I am looking for a second smart home solution. Zigbee, Z-Wave, HomeMatic and EnOcean come to mind.
I read a lot of stuff online and it only made me more confused.
Z-Wave:
Closed system.
Very well supported (by openhab etc.)
Mesh Network.
Radiator thermostats aren’t very reliable from what I have heard.
Zigbee:
Open standard. Cluttered and not very well supported(apart from ZLL).
Seems to be more expensive.
Mesh Network.
HomeMatic:
Closed system. Old and I think it is gonna be phased out for the HomeMatic IP.
CCU UI is very outdated and a pain to use in my opinion. But it gets the job done.
Most inexpensive option so far.
Power plugs are ugly.
The retrofit wall switches are very nice thou.
HomeMatic IP:
More expensive than HomeMatic. You only get the better UI with the cloud based HomeMatic IP Gateway. Works with the CCUs too, but then it is not much different than normal HomeMatic.
EnOcean:
More expensive
Open standard?
I don’t know much about the support.
Many things that harvest energy and do not need batteries. I like that.
WiFi/Bluetooth:
Fine for some things, but not in general.
What I need?
Radiator thermostats, power plugs(with energy monitoring at best), wall switches, window sensors. Roller shutters/belt winders are optional.
In theory I could get a dongle or base station for everything. But I don’t want to invest in stuff, that is unreliable and needs tinkering every other day to get it working. And having a whole additional protocol for just one thing seems weird to me.
Can anyone shed some light and give me some recommendations? I would be very grateful.
No. This forum is on openHAB not on general Home Automation.
Browse the forum, there’s all sorts of posts on open questions like this, but noone will get you a recommendation, that you have to find out for yourself (anyone’s requirements and starting point are unique so there’s no single or correct answer to these questions).
Thanks for the info. I though it might somewhat apply. Since i am looking for openhab support/compatibility too. To be fair I did not make that very clear. But if that is not the place for such a question/discussion thats fine with me.
Hello,
I would recommend Zwave in your case. With a bit of planning you can make a zwave mesh network very stable and it would actually complement your Hue bridge very well as it offers all those things you have on your agenda except nice cheap colorful lightbulbs which you already have thanks to the Hue. You could even think about moving those Phillips components over to a zigbee stick to not have an extra bridge at a later point and gain more flexibility. Not to forget the Zwave binding is quite robust and works great for many people here.
Enocean while nice is rather expensive and has a major range disadvantage as it relies on a star topography and you will need good planning and or repeaters which are pricy too. Also the binding is still quite young and inmature so if you dont already have enocean equipment I wouldnt recommend it for your use case right now.
Another think that comes to mind is that if by any chance you have an AVM Router you could look at dect ule radiator thermostats which can be used over the fritz binding.
Johannes
Typically Zigbee is cheaper than Z-wave. Both Hue and Tradfri use Zigbee.
Not really. Everyone’s needs are unique and what works for me may not work for you. The good thing about OH is you don’t have to choose just one technology. It supports all of the ones you list. I suggest you make your decisions on a case by case basis.
From personal experience I’m pretty happy with Zwave. It’s well supported by OH, has lots and lots of different devices, and they have published the full spec so it isn’t as closed as it once was. But I went with Zwave because at the time there was no Zibgee support in openHAB.
Rather than trying to decide on a technology, research the best fit for individual devices you need and let that drive what choices in technology you make. Go slow so if you find you chose poorly it isn’t expensive to move to something else.
How it Z-Wave closed & Zigbee open? AFAIK they are both open standards but have certain testing requirements to use the standard name.
I looked at Zigbee, Wi-Fi, & Z-Wave and here are my observations and opinions.
Zigbee & Wi-Fi both use the extremely cluttered 2.4 GHz RF space even though they have other options. Zigbee is also defined for 900 MHz? and Wi-Fi has 2.5 GHz.
Z-Wave is in a different RF space that is less prone to interference. The standard is also defined tight enough to insure device compatibility across vendors. Z-Wave Plus also focused on better range & battery life.
Zigbee standard is very loose so there are different incompatible variants. Both Zigbee & Wi-Fi vendors are focused in trying to lock you into their “walled gardens”
Although Z-Wave is more expensive, that is currently my focus. The USB stick I have also does Zigbee should I decide to use that too.
I’ve been somewhat corrected on this in the past. It isn’t so much that Zigbee is a loose standard as it is that some vendors add extra stuff to the standard. Because there is no governing body like there is with Zwave this can result in incompatibilities. For example, Xiaomi devices (IIRC) implement full Zigbee but add on some extra stuff. If you want to use the full capability of the devices you need to move beyond support for just the standard Zigbee spec.
The only thing preventing Zwave device makers from doing this is that they cannot call it zwave if they do so. But I’m not sure that Xiaomi actually advertises their stuff as Zigbee. It’s just one of those well known open secrets.
I think Zigbee lighting is different than Zigbee home Automation too
The Wi-Fi Alliance testing up until now has focused mainly on interoperability.
Starting with Wi-Fi 6 and WPA3, their testing will be focused on adhering to the standard with no cheating like is happening now.
No - this is not really correct any more as the standard is now open.
I don’t think it’s “not well supported”. There are some devices (lets say cheap Chinese devices) that don’t stick to the standards, but IMHO ZigBee has a cleaner implementation than ZWave these days.
I would say that at the moment, ZigBee is less popular than ZWave for home automation, but much more popular commercially.
Not really. It’s the same cluster library spec although some devices may decide to only work with ZLL devices. In general though newer devices should use the unified standard, and most older devices should work across both profiles.
Your experience and opinion carry more weight than mine. What about vendor lock-in though? Isn’t Zigbee worse?
At the university I work for, the 2.4GHz space has so much interference we only provide 2,4 GHz wireless with minimal support.5 GHz is much more supportable.
It shouldn’t be. A standard is a standard - it’s there for interoperability reasons. So long as a device is marked as ZigBee compliant, then it should be compliant to the standard, and therefore interoperable with other devices from other suppliers.
I’ve not personally come across anything that has this issue - not if it’s really a ZigBee certified device.
Well that’s a whole different issue, and yes, there’s no getting away from the fact that 2.4 GHz is crowded. I’m not really sure though that the sub-gig bands where ZWave, some HomeMatic, EnOcean, and lots of other protocols reside is a lot better. That said, range in these bands tends to be better…
I’ve not hit any great problems with ZigBee in 2.4GHz. There are 16 channels in use, and in most cases it should work ok. I can also provide a good example where this can be managed well. Once company I work with (a rather large hotel chain) are running ZigBee in their hotel rooms. Each room has its own network, and their hotels each have hundreds of rooms. On top of that, they have WiFi - all in 2.4GHz.
For my home, Wi-Fi 2.4GHz is a non-starter.
Here in the US there are only 3 non-overlapping channels (1, 6, 11). I have only 1 of my 2 APS using 2.4 on channel 1 because I have a neighbor on channel 7 which interferes with 6 & 11.
I wanted range outside my Wi-Fi coverage anyway for some outdoor lighting. Hopefully Z-Wave is my answer but my USB stick does Zigbee too.
While the message, serial and application layers are open the protocol layer is still not in the public domain.
One thing you may want to put into the mix is that the latest incarnation the dev kit has no implementation of the standard serial controller but only the bridge controller aimed at Z/IP so to use the latest 700 series chips as a standard serial controller would require you to implement your own or possibly one of the manufacturers will at some point. Nothing from silicon labs. So for just now there is no way to use the latest chip as a controller on OpenHab.
I am working with the devkit and while it works I am still struggling to see the advantage of Z/IP over the simple serial interface that OpenHab uses. If it aint broke don’t fix it would be my comment. It is sad as the 700 series chip is definitely faster and easier to work with.
It is early days but possibly Zwave has taken a wrong turn so when you pay your money you may want to include upgrade path. I am enjoying working with the new version but it does seem a lot of effort for something that will have few advantages over the current OpenHab. S2 security I guess will come faster form the latest and work better on the 700 chip but other than that that protocol appears to have very similar behaviour.
I can’t comment on the other options but zwave works well as it stands but the future is far from clear.
Yes, this is unfortunately also my view. I’ve been working with Sigma for the past couple of years, and more recently with Silabs. When I was at the last partner summit in Austin late last year I tried to change this, but it’s really heavily driven by Sigmas direction before Silabs took over.
There are some advantages with Z/IP, but it’s minimal. I wouldn’t be too surprised to see this change, but let’s see.
I probably should add that from a user perspective, I don’t think this will make any difference…
@chris you really make a difference here. I am looking again at OH in large part due to your work here on Z-Wave.
In my view, the main competitors of HA are using variants of openzwave that are missing many devices, especially US ones.
Interestingly, when I set up my online database (4 years back I think) I reached out to the OZW team to see if they wanted to collaborate, but I was told they wanted to keep separate. I don’t really keep up with OZW these days, but if they are missing devices, then there is still an exporter from my database to the OZW format
Yeah, but Home Assistant uses their own older fork, that gets replaced every release. Fortunately they only use the device definitions when the device is initially onboarded. I cheated by modifying the definitions before adding some of my devices. Unlike OH, they do not recognize well devices that have been previously added to the Z-Wave network.
The latest OH snapshot recognizes all my devices with no issues
The only case I see is for very large busy stretched networks or a property with very substantial building construction when having several controllers working together over a wired IP network would beat trying to get zwave to work at any reliable level.
Interesting that it may change. Just taken the latest cut of the developer kit and can see nothing in it but I would love it as your implementation works fine for me. No need for lots of extra complexity.
I was not talking about the IP part of this - that’s a complete red-herring as far as I’m concerned and adds no value at all.
I was getting at the fact that some of the lower layers are now provided by Silabs - ie encapsulation and security which is where many of the incompatibility issues arise.
Don’t get me wrong - that’s just my view and you won’t find that in any documentation. Personally I would like to see this encapsulated in the M4 rather than in the host and I’m hoping that’s the way it will ultimately go. The M4 used in the 700 is probably not going to cut it though as it’s too shy on memory unfortunately. If they did that it would be more in line with how other protocols such as Thread and ZigBee are implemented at Silabs as well.
Unfortunately we’re going to have to live with this for a while and ZWA have told me they are unlikely to accept certification requests in future that are not using this approach so it’s likely going to be needed in the near future.
Particularly as they use open SSL rather than a smaller security lib.
Very sad as what you have done in your OpenHab binding is extremely good.
I think the new retry and queue strategy in the latest SDK will probably improve the resilience of a zwave network but your binding as it stands is great. Many thanks for all of your hard work.
