In general, there are limited benefits. The protocol radio channels are the same - the maximum radio speed is still 100kb/s. The radio performance is slightly better, but probably not something that people will notice. The processor used is better, and that may help in some areas, but again since the protocol is generally very slow, it is unlikely to make any significant difference.
It will not improve the speed at all. While it might increase the RS232 speed, this would be dependant on the controller and not related to USB since USB can run much much faster than RS232. However in general this won’t make any significant difference since the protocol speed is mostly governed by the radio channels which have not changed for a long time.
You’ll also find some comments above from @apella12 -:
Thanks for the info. I don’t think I’ve seen any significant benefits stated anywhere and you’ve just confirmed that. Even if the gen 7 controllers had better range that would only work in one direction unless they also had significantly more sensitive antennae. I.e., the controller might be able to talk directly to more devices in the home but messages from those devices will still take two or more hops to get back to the controller.
In short, I’m not seeing a compelling reason to upgrade my gen5 to a gen7 controller at this time.
If I remember correctly, the receive performance is also improved, but it’s only a couple of dB and IoT sensors (etc) tend to be limited more by other factors (environment, poor antennas etc) so the improvement, while “real” in the lab is not likely to be noticeable in the real world.
I would certainly not be upgrading a working system on the hope that it will be better with the gen7
That sounds very sensible to me. If I had coverage issues I think I’d look into moving the controller to a more central position in the building first.
Or get a mains-powered Z-Wave device that can act as a repeater. I recall someone saying that they bought a Z-Wave wall plug for less than a dedicated Z-Wave repeater.
As mentioned earlier in this thread, the biggest concern is that 500-series controllers are going out of stock and being replaced by 700-series controllers. I was going to say “slowly going out of stock”, but I just had a quick look on Google/Amazon and I can’t find any (reasonably priced) 500-series controllers in Canada. I only have about eight Z-Wave devices in total, so it’s not a big deal for me to switch to Z-Wave JS UI or ditch Z-Wave in favour of Matter/Thread/Zigbee. However, that could be painful for others.
Which brings me back to:
It seems to me like it would make sense to adopt Z-Wave JS for future implementation of 700-series controllers, while maintaining the Z-Wave Binding for legacy purposes. This would give us a path forward for new/existing users, while also reducing the burden on Chris and the few others in the community who have enough expertise to support Z-Wave (I am not one of them).
If it were possible to include Z-Wave JS in openHABian (which already includes an MQTT broker), we’d have a solution that is more complex than a binding, but will perhaps be easier to maintain due to the independent development of Z-Wave JS. It would be similar to using ZigBee2MQTT or Tasmota/MQTT.
I’m pretty far out of my depth on this suggestion, so feel free to tell me that I don’t know what I’m talking about. I really don’t.
That’s a very important point. This would lead to the current zwave binding effectively becoming legacy technology simply because of the hardware availability of controllers that can be used with it. Eventually even availability on eBay will dry up.
I don’t know know how foundations works in your country, but if you can’t finance the development, and you can’t finance the items needed to develop and maintan the system(like the api’s, and other things what are needed in the future), than for what can you use the money? I can’t imagine that nothing from this could be financed.
Just to give you a short answer.
Who do you think is paying the servers running this community or the free myopenHAB service ?
It is paid by the foundation.
But I am not going into more details how the foundation spends the money, as this is closed information for members.
The openHAB Foundation is an “eingetragener Verein” (registered association/club) under German law. As such it is very limited in spending money without loosing its tax-exempt status. Some irritation may arise from the fact that “Foundation” is usually translated as “Stiftung” (under German law). Unlike an “eingetragener Verein”, a “Stiftung” does not have to be charitable.
Last time I checked, the relevant API had not been released. The statement from Silabs was that we had to use the Z/IP protocol and they would not release the API except to Alliance members. I’ve not looked at the latest docs for about 12 months as I’ve been very busy with other things - maybe they’ve finally decided to release this.
Anyway, my point earlier about funding was historical - before any of the ZWave docs were released, the only way to get the information was to purchase the developers kit at around $2k USD which I had to do personally. Now it’s a bit different - some of the protocol layers were released a few years back, and some layers were kept private). Again, I’ve not checked the latest status.
As eventually the 500 series sticks will becoming eol/legacy/ unable to buy, i’m really hoping for a solution. Coming late to the discussion, i’m i right, there are two main problems?
You can only get the API documentation if you are member of the aliance? And money won’t help Chris into the aliance will it? Or what are the criteria to enter?
Jumping the wagon of this thread. Seeing my gen 5 aging and the lack of proper tooling, I considered upgrading to gen 7.
It ends up being a total catastrophy despite my efforts (I spent already DAYS on trying to get that to work to a decent level).
It has been hard to migration from gen 5 to having a network with the gen7 as primary and the gen5 as secondary but I made it. In the end, it works very poorly when at all. I still need to use the gen5 to perform any inclusion/exclusion… it defies the purpose.
The “recommandation” is to use PC Controller 5 for most of the maintenance task but even that thing is a mess. Nothing is reproducible, things work sometimes, you redo the exact same and it does not…
I am now considering switching back to the gen5 (now motidifed to work with the RPi4) and sending back this gen 7.
The gen 7 is not a consumer product, it is a dev platform at best. It would be great if open source but it is not, so it is a dev kit, but you don’t get the source…
I would expect a proper migration path from a product to the next gen AND that the resulting migration works. This is not the case.
Since the question was “Aeotec Z-Wave Stick gen7” I would love to say it is a nice little stick that works well but for me it does not. Plus losing the baterry and the option to walk to the devices to include/exclude them is a huge loss. I don’t understand this product AT ALL, this is not an evolution beside a bigger model number…
I wonder if this feature was removed due to the confusion it created for secure devices, which must be included through software. We’ve helped a number of people who assumed they could use the button on their Gen5 sticks to add their Z-Wave locks.
That doesn’t sound like a true migration. That sounds like a hack to keep using the Gen 5 and not have to change your existing network off of the Gen 5.
Assuming you didn’t have a backup before, is seems a more straight forward, and perhaps more reasonable migration would be to simply move everything over to the Gen 7 alone and retire the Gen 5 controller entirely. Maybe that would give you a more reasonable experience.
Note that my understanding is that only really old Zwave devices at this point require close proximity to the controller for inclusion. You shouldn’t need to be close to the device to include it anymore meaning you should be able to put the controller into inclusion mode on your phone through MainUI and press the button or whatever on the device to complete inclusion. I’ve successfully done this even with battery powered devices.
Not really. Actually, I would be happy not to depend on the gen5 anymore.
I may be wrong but I don’t think I could restore a gen5 backup to a gen7 stick.
So the only remaining option is a shift. This is a sporty option but I got it to work (and documented so I can make a post out of it once all the issues are resolved).
The problem was that, in the network running solely on the gen7, I could not do any inclusion/exclusion.
As soon I as brought the gen5 to the game, I could finally include some of the devices (not all).
So far, I found it an acceptable solution.
That was my initial plan but it did not work out.
Even 10cm away, I could not include on the gen7, using OH or PC5.
Way up in this chain; Gen7 was started with Z/IP in mind, but reverted back (mostly) to what Gen5 was using. However, because this transition took time, your make sure your gen7 stick is using SDK 7.18.2 or greater. Earlier versions had issues.
On the OH side the PR that allowed Gen7 to work is in OH4.1 or later. Without that version inclusion will not work. Also make sure you are using Network wide inclusion.
If neither of those are an issue, a debug of a failed inclusion would be helpful to diagnose.
I would certainly not be upgrading a working system on the hope that it will be better with the gen7 
If I had coverage issues I think I’d look into moving the controller to a more central position in the building first.