Aeotec Z-Wave Stick gen7

Is the Aeotec Z-Wave Stick gen7 already implemented in the binding? I saw threads where it was discussed already in 2021, but till now i can’t find any information about if it would work? Meanwhile this controller is more than a year on the market, lot of gen7 products are for sale.

The stick is not supported, series 700 devices are supported.

A slight correction. 700 series controllers are not supported. 700 series devices are because they fall back to the older protocol when necessary.

I hope this get fixed very soon. Waiting for 700 series controllers support since long (too long)

The Zwave Alliance has made it basically impossible to legally access and use the code that defines the API to these controllers for open source projects. So it’s going to require reverse engineering the API and I’m not sure there is anyone on the openHAB project looking to do that.

Thanks, your comments are appreciated.

Why is Home Assistant already supporting 700 series controllers?

For test purposes I installed HA parallel to openHAB on my Synology. OH recognises the Z-Stick 7 but cannot do anything with it, while HA not only recognises it but also works properly. Both are open source projects. So I am confused.

Happy New Year

There are two ways to get the information - reverse engineer it, or pay for it. In the past when writing the OH binding, I paid for the information - it cost around $2k. I think the licensing has changed now and you need to be a member of the alliance which is a lot more, and an annual subscription.

Reverse engineering isn’t too hard, but it takes time and is error prone…

Like he wrote

Maybe we could make a startup to finance the membership. Would be nice to have, because z-wave is an important binding and without future improvements is not worth…

This is going to sound backwards but reverse engineering a protocol isn’t the hard part. And before someone says “have you ever done it” I’d point you at the pending PR for the shieldtv binding. The hard part in most cases is performing the MITM properly to gather the data. APIs are built to be interfaced with in a standard and repetitive way.

Equipment is stupid, cheap equipment like zwave devices are even less likely to do anything that isn’t very cut and dry. People/companies are too lazy to write things obscurely these days because of modern encryption. They’re even less likely to produce a custom ASIC when they can get a commodity chip that can be programmed to do something as long as it fits inside of what ever industry specifications they built it to. Custom chips are expensive and the cost of zwave devices will never warrant that level of captial investment.

99.999% of people won’t understand or be capable of properly injecting themselves into an encrypted communication path in such a way that they get exposed to the keys and are able to record and decrypt the data. This is acceptable to most companies as a means to protect their data. And that’s not meant to be an insult to anyone, its just not something you learn unless you need to. In the case of the shield, getting in the middle wasn’t hard because they didn’t bother to really authenticate anything on the initial connection. Wireshark, tcpdump, openssl, a cert from letsencrypt, and a raspberry pi was enough to fool the app and jump in the middle. In the case of a serial zwave controller it likely wont be as easy. You’re going to need to find a shim that can act as a middleman and recorder. Its highly likely that the protocol is similar to the old one, because again people are lazy and why rewrite something from scratch when you can just reuse and modify something you already have. But until you know how to get into that crypto path, you’re dead in the water. Once you’re in, it’s basically just a complex replay attack.

My very basic understanding of the new controller is that it adds a layer of encryption to the exchange that didn’t exist previously. As a possible attack vector, I’d be intrigued to see if sending a basic TLS handshake over the serial connection responds with anything. As zwave devices obviously cant get out to the internet the concept of validating the certificate path is out the window. Also, the zwave developers are absolutely not going to write their own encryption mechansims, so it stands to reason that they may have simply reused existing libraries. You may be able to use OH to do this. You already have the code written to make the serial connection. Plenty of bindings exist that establish TLS connections to devices over the IP stack. I’d bet you could augment the existing zwave binding to act as a test harness directly. If you can establish a TLS session, dump the raw data out via logger.trace and see if you can find repetition. In the case of the shield, as soon as I saw that they prefix most packets in a certain way, terminate almost the same way, and use 0x12 as a mid packet delimiter the rest of the packet began to make sense.

Agreed, and that’s also what I said above -:

And that’s basically true, but you also need to remember the second part of what I said -:

The ZWave protocol was reverse engineered 10 years ago to create the initial binding for OH1. It took me a lot of time and effort, and expense as I ended up having to purchase a lot of different devices as the protocol is quite extensive.

The big problem is you always have to guess what something means - then when the protocol gets published you find out how many errors there are. This can then become really difficult if there are fundamental errors in assumptions that have been made…

No - there’s no new encryption between the controller and the host.

The issue at the moment is just that I have limited time, so don’t have the time to do this - even though it’s not that hard, and I’ve done it a lot in the past.

1 Like

First I shall express my appreciation for all the work done to develop this binding in the past. Based on this I am running my home reliably since a few years :pray: :pray: :pray:

However, may I suggest kind of crowd funding to cover the membership fees in the Z-Wave Alliance and access to the documentation to enable development on a future proof foundation. Else openHAB may be considered End-of-life pretty soon I am afraid.


Wow, this is a very strange point of view and definitely not the case.

Its true what CHTHSCH wrote. Z-Wave with MQTT, Zigbee, KNX and some other protocols is a very important part of a home automation system. And if OH cant offer the safety to maintain this devices, than would sooner or later(and i think this would be sooner) not worth to use it. And this is even more true if other open source and free systems are more flexible and they offer this improvements.

1 Like

I have been around OH for a few years and am primarily a zwave user. As such I have followed the 700 chip discussions, (possibly reaching the wrong conclusions :wink:), but it seems the 700 series was intended for a new Z/IP protocol. However, along the way Z/IP seems to have been put on the backburner (I have not read much about it recently) and the 700 series was modified to run in the serial mode like the 500 series. However, from this comparison I find the improvements over 500 chips generally modest (same speeds, a little longer range). The range increase in my systems with 20+ devices is not relevant. As confirmed by Zniffer, ninety percent of my devices are in direct contact with the controller and the rest are one hop away. The only item that attracted my attention was the longer battery life, but since OH supports 700 devices that benefit can be theoretically obtained without a 700 zstick. Finally, from the following you will need to upgrade the firmware as the original firmware versions were buggy. I’m not sure if all the bugs are resolved, so in a sense OH dodged a bullet.

A little off topic, but I bought 2 Zooz ZSE43 700 tilt to run side by side with the Ecolink Tilt2.5 (500) on my garage doors to test the battery life. On the first try the batteries on the 700 series were dead after 4-6 months. After contacting Zooz there was a firmware update that seems to have improved the situation. Time will tell, but I’m still getting battery fluctuations on the 700 series versus rock solid 100% readings on the Ecolinks. I’m quite skeptical at this point that the 700 series will live up to the 10-year battery life. I think the jump down from the CR123 to CR2032 was largely aspirational. Also from Zniffer monitoring the speed and range (zero or one hop) is identical to the Ecolinks.

Bottom line for me (IMHO) is that the 700 controller is not a big deal (certainly no reason to jump platforms). Also any 700 series Zwave user is going to need the Silabs Simplicity Suite as firmware upgrades on 700 devices seem frequently needed. Pure speculation, but seeing an 800 series (out of sequence 3,5,7,8?) might be a sign to skip the 700 series entirely. I saw one article that EOF for 700 series was 2022?

1 Like

Trying to take the perspective of a newbie:

  1. Oh cool, openHAB comes with support for Z-Wave!
  2. Let’s buy the latest Z-Wave controller from a leading Z-Wave vendor (7>5 => Z-Stick 7 is supposed to be better …).
  3. first disappointment: Z-Wave Binding does not support Z-Stick 7.
  4. 2nd disappointment: response from the openHAB community: Read the documentation before you buy hardware!

Obviously the openHAB community is right :grin:, but the newbie will turn to another home automation solution. Even if it’s the newbie’s (or the Z-Wave Alliance’s …) fault, it’s a bad customer experience and a potential loss to the openHAB community.

There is one place where the 700 controller (and later) is important: availability. Over time, 500 controllers will become harder to come by and without support for 700 controllers, new users and those whose existing 500 series controllers need to be replaced will be out of luck.


Agree. This was the case for a couple of newbies in the last two months

Agree, but these devices do last a long time. I’m still using a 5 year Aeotec, but did do a firmware update last year.

My comments were more directed at the replacement of a 500 controller with a 700 controller by an existing OH user. Mostly the idea to switch platforms for what I view is a marginal improvement.

And thats the point. I have already the third Aeotec z-wave stick gen 5 and i see that this beginning to make problems too. I would need to change sooner or later. If in a Half year the series 5 would not be for sale anymore, than for me is not a big deal that the 700 is not an improvement. i would need to get somewhere a used stick, or i can throw out z-wave modules in worth of some 1000 euro. So if i have system where i see, that now this happening with the z-wave binding, i would make a conclusion, that next time maybe the same would happen with knx, or with zigbee or with something else. I don’t buy items in lot of 1000 euro value for some years. There must be some art of garantie that updates would follow…

I think there’s a few issues being discussed here so a few thoughts from me :slight_smile:

I guess this depends on what happens with Smart Home protocols in future to a large degree - will ZWave still be so dominant in a few years time - who knows. It has been picked up by SiLabs, so that’s a positive, but on the other side it’s not part of Matter which is being pushed by all the big players.

Either way, while I agree it’s currently a major binding, and if ZWave suddenly disappeared from OH, I doubt that OH will go “end of life” - there are a LOT of users who don’t use ZWave still.

In the past, I paid for this information, and I had a quite a lot of people who said they would contribute. It cost me around US$2k to get this and it was done when I added security to the binding. Many people donated to the OH Foundation as a result of the request for donations, thinking that it would support this endeavour, but in fact the foundation has a policy of not supporting such development. As a result, I personally ended up significantly out of pocket when trying to help the community and I’m very hesitant to get into that situation again.

I completely understand this, and agree that the binding should support this for exactly this reason - don’t get me wrong. I’ve written support for the 700 series for another project so have a good idea what to do - but it still takes some time.

There are never any guarantees in life :slight_smile: . The ZWave Alliance (or Silicon Labs) probably shouldn’t have changed the API - this was done at the time they were pushing their Z/IP software component which was considered “mandatory” for all future systems. Prior to this one of the nice things about ZWave was that all sticks supported the same API and ZWave was nicely interoperable - until the 700 series came along.

This is an open source project, and contributors do this in their spare time, so while I understand the sentiment, no-one can “guarantee” support for anything. At the moment I have a lot on my plate - hopefully in a couple of months that might change and I’ll find some time to look at the 700 support.