Aeon Zwave Stick Gen 5 + Plus

Hello, i am about to take the plunge. does anyone know if the new AEON zwave stick gen5 + or Plus will work with openhab?

this one

i dont see why not given i think it is effectively the same stick but someone with experience/thoughts would be great

thanks

Any Z-Wave certified USB controller should work with OH, since the serial API is part of the specification, but @chris knows best.

2 Likes

As @5iver said - this will be fine - I think many many people here use the Aeon sticks. Gen7 sticks will not work as they use a newer version of the API that is not publicly documented, but Gen3 and 5 are fine and are all the same.

1 Like

I have the Gen5+ and it works well. I needed to upgrade from the older Gen5 because that does not work on the RPi4.

Some additional info in case others are searching for answers: The upgrade from the non-plus Gen 5 to the Gen5+ was very easy. It was as simple as installing an app to download the configuration from my old stick and then uploading it to the new stick.

I also had a Gen 3 but the upgrade from that to the non-plus Gen 5 was painful since I have ~40 Z-Wave devices.

B34N

1 Like

hey B34N

i am wondering since you have experience with the whole Zwave ecosystem.
I have a vera plus setup that works well, i decided to “torture” myself a little and go from a slow moving proprietary system to something open/faster moving and hoping also to be very stable. I realize i will have a fairly hard time remembering basic programming to use open hab but do you have any insihgt on the question of why open hab and not one of the others (docomoticz, pidome etc) would you do it all again wiht Open hab? (why?) ty for the time!

Open and stable are keys.

I have been using openHAB for 5+ years. I was previously using LinuxMCE for both Z-wave and media but I decided to move to Plex for media so I needed something for z-Wave. Back then there were less options.

I have not tried the others but I have had success with openHAB so there was no reason to migrate. I really like how it allows me to bring in a variety of control types into one platform. While Z-wave is my primary use I do use other control systems.

I have been happy with the community at openHAB. I like the support that I get. I have looked at Home Assistant. That looks a bit easier to get started with and I like the showier YouTube instructional videos, but every time I needed something, I get results with openHAB. TBH: openHAB has good support and they keep improving, so I have no need to look elsewhere. Also, my openHAB has been rock solid for those 5+ years. I cannot emphasize that enough. It keeps SHMBO happy so that is really saying something.

B34N

1 Like

Does @chris or anyone know if the Gen7 Z-Wave devices are nicely backward compatible with Gen5 (5+) controllers? The Z-Wave Alliance touts backward compatibility, but I’d like to hear personal experience. The AeoTec Smart Switch 7 is now available (to replace the 6). Many have surely heard that Gen7 is claimed to have about 2x the range (at least when meshing with other Gen7 devices). It would appear that the secret to a good Z-Wave network is to rely on mesh as little as possible (so improved range is welcome). Gen 7 is claimed to have better routing too. Is there reason to think that the Gen7 API won’t be published, making the benefits available to the OH world?

I am very sure Aeon knows.

No - they are not 100% compatible. Mostly the API is the same, but there are some differences and at the moment the 700 API is not publicly documented so I’m avoiding doing too much with this at the moment. I do expect that will change - the public release of the 700 API was meant to have been this year, but I’ve not seen it come out so far.

2 Likes

Thanks for the info. If the API is mostly the same, perhaps the most basic functions on some of the new gen7 devices will work with a Gen5 controller (stick). For example, the Aeotec 7-series “Smart Switch 7” might work with a simple on/off command, and thus could be a better choice (today) in terms of ‘future-proofing’.

I don’t consider myself to be an expert, but Z-Wave 700 series seems like a significant step forward in terms of addressing nearly everything that has bugged me about Z-Wave 5 (e.g. inclusion, routing, latency, range, battery-based sensors with multi-year lifespan. etc), so I have been mostly waiting for 700-series hardware to become available before expanding my (very) small Z-Wave network.

The improved chipset combined with what appears to be a push toward open sourcing some of their libraries, I’m surprised I don’t hear more excited chatter about it.

The hardware certainly gives some enhancements - it will have lower power and has better performance, but most of the things you talk about are software features that I think can also run on the 500 series chips - if they have the right firmware.

Silabs are open sourcing the specifications to allow other manufacturers to produce ZWave compatible chipsets. This is still an ongoing process though and isn’t really going to help most systems - remember that the ZWave APIs were published a couple of years ago already…

1 Like

Good points @chris. Based on my research, a good example of what you’re describing is the Fibaro FGS-224, which now brings S2 security and “SmartStart” to a module based on the 500 chipset. This means that an integrator (or end user) can pre-include (or re-include) devices to a new controller without having to take rediculous, unfriendly steps, like open up wall-box lightswitches to push a little button on a module inside (across the entire network).

Z-Wave v7’s ARM core, faster CPU, and larger on-SIP storage is not likely so important to OH users since most logic is implemented externally in OH. I imagine it will make life easier for HW developers who want to implement more complex functions internally, such as a Thermostat that needs complex logic internally for calculations of dead-band, stage offset, reset curves, scheduling etc.)

The difference in v7 power draw seems relevant ONLY to battery-powered sensors, since MOST of the power consumed by a mains-powered module is the low-voltage power supply itself, and not the z-wave chip.

Thus, in my mind, the indispensable v7 feature is the improvement in range. While sensitivity in v5 can be improved via an optional SAW filter, the broadcast power can’t be improved. Naturally it takes 2-directions to have a radio conversation.

Personally, my biggest peave in smart lighting is latency and non-deterministic behavior. My observation that: if an untrained user flips a switch, and the related thing doesn’t do its ONE job in less than half a second, every time, then that user will conclude: “this system is crappy”.

According to that metric, my experience with v5 is that Z-Wave goes from crappy to fabulous if you can just get endpoints to be within ONE hop of the controller. Thus, one would conclude that v7 could improve on that, seemingly significantly by way of its better range.

What I am curious about (if I even understand v5 correctly) is whether v7’s more capable ARM core will allow for a better/smarter command processing, such as a command queue depth of greater than one. If I understand it correctly, it could make the relationship between signal degradation and network ‘crappiness’ (as defined above) to be more of a linear relationship, not the exponential one that I observe. Currently I observe Z-Wave performance decreasing to the square of the decrease in signal quality (i.e. hope count). Presumably this is due to the interaction of the two factors: increased number of hops (and related acks) combined with a command depth of just one.

If there could be multiple on-the-fly commands, it seems like it could decrease both the growth in latency and variance in latency as hop count increases. If anyone can speak to this I’d be very interested in understanding it better.

The link budget on the 700 series is only a few dB better so it will not significantly improve things. The home environment is dictated by many different factors and a few dB here and there is unlikely to make much difference in the grand scheme of things.It certainly won’t allow you to get all devices within one hop of the controller - and even if it did - ALL devices would need to use this chip - not just the controller.

1 Like

@chris few questions related to this that I’ve been wondering:

  1. Zooz has released their 700 series USB stick now, and it claims to be OpenHAB compatible. Is that accurate to your knowledge (given the discussion above)

  2. I’ve been thinking about how to improve performance of my zwave network. Do things like better controllers (I.e. the Gen 5+ version of Aeotec’s stick vs the Gen 5) make a difference? I realize in this sense “performance” would be incremental

  3. Continuing on the performance line of thinking, I’ve been trying to dive a bit into a deeper understanding of zwave and how things work, I.e. ghost nodes and their impact on the network, mixing of chip series (300/500/700), what SDK version a controller runs, etc. There such doesn’t seem to be much easily findable info out there. Would love to see some sort of guide in improving one’s setup.

I would doubt it unless they have programmed this stick with the older firmware (which I didn’t think was available for the ARM processor, but I’m not certain). Of the 700 series sticks I have here, they are not directly working with OH, but it is certainly possible to produce firmware that has the same interface as the 500 series.

Technically, yes. Practically… I’d be surprised if you see significant improvements, but it depends. If a link is “right on the edge”, then a few dB will make the difference, but I think in most cases it won’t be noticable.

2 Likes

I wasn’t able to find anything stating that the “ZST10 700” supports OpenHab or HomeAssistant but I just posed the following question to Zooz support:

Two questions:
1.
Users in the OpenHAB and HomeAssistant community would like to begin using the ZST10-700 device, but it appears that that the new 7-sereis API has not yet been released. Is the ZST10-700 device compatible with the existing serial API used by the Gen5 USB devices today? Can the ZST10-700 be used as a drop-in replacement for the ZST10?
2.
I’ve been following the Z-Wave alliance page closely to see when new devices are released supporting 700 series chipset (Z-wave Plus v2). Somehow the “ZST10 700” usb stick is not on the Z-Wave alliance web site. Indeed none of the Zooz 700 series products are listed there. Does this represent a lack of certification of these devices or is there some kind of glitch preventing your products from showing up?

I will follow up on this post when they reply.

The 700 series sticks are not currently compatible. They use a slightly different API that is not currently publicly released. Silabs told me it would be released late last year, but so far it has not been made available.

There appear to be a good number of 700-series USB sticks available. Do you know who’s using them? Are they essentially for use with closed-source smarthome products behind an Partner NDAs and ‘magic’ binary blobs?

Do you happen to know if a 700 series zwave USB stick could be used for RF troubleshooting of an existing network of 500 series devices using a laptop (e.g. Mac/Linux/Windows) and the appropriate SilLabs tools?

When I determined that it was time to replace my aging zstick, I bought the ZST10 700 to try to futureproof my setup. I ran into issues immediately and found this thread, so I requested a return.

Zooz claimed to me in an email today that they “recently verified compatibility and resolved any issues with the ZST10 700 and openHAB” and offered to help me troubleshoot.

Before I waste my time, @chris, should I be able to use the ZST10 700 with openHAB3? If so, do I need a snapshot z-wave binding?

I do not personally have this device so cannot comment. In general, the 700 series firmware is completely different to the older 500 series firmware, even if the API is largely the same. Maybe Zooz have modified the firmware to make it more compatible with the older API - I simply don’t know and as I don’t have one, am unfortunately unable to confirm either way.