There were quite a few firmware updates and smaller hotfixes after the C8 was released, which makes some sense as it was a new hardware revision of the hub actually out in the wild for the first time.
Usually if you’re not seeing a new firmware update from the dev team, it’s because they’re busy working on the next one.
Current firmware is stable and works great. I can't think of much else I need, either. They could release them every year or two as far as I'm concerned.
I hope in the next release, the lack of the ability to link Z-Wave devices as HomeSeer can do is addressed. My HomeSeer system allows me to directly link devices such that several switches controlling different loads can be easily linked by simply selecting the device to be linked. It is easy to have A control B & B control A or A control B, B control C & C control A. I use this feature to have any one switch for outdoor lighting control all the outdoor lighting. Earlier this summer, I sought forum help with this issue and was told to use the Mirror app. The Mirror app doesn't properly work! Quickly turning off one light gets missed by the other light. Dimming one light using a dashboard is not reflected in the other light. The HomeSeer link Z-Wave link feature doesn't have these problems.
The process you’re describing is zwave direct association. It’s very unlikely that there will be a built-in app/driver for direct association, as indicated by Hubitat staff a few times in the past.
However, there are already a few community tools available for direct association. Here’s one from @MrFarmer:
Leaving direct association aside, this is a sure fire sign of a marginally functional zwave mesh.
Those devices look pretty good. It isn't many to create a robust mesh, but doesn't seem like it is needed.
You may want to see about custom drivers that support device association. Not sure about Jasco, but i know the Zooz Drivers created by the community support Device Association.
The network shown was part of my existing HomeSeer system which has many more nodes. The HomeSeer system does not require any custom drivers to link Z-Wave devices. I ran into some other issues with my HomeSeer system caused by an upgrade to the system firmware. It seemed the Hubitat system would be an easy transition from HomeSeer. This does not seem to be the case. I don't see why Hubitat makes something easily done on a competitive system so difficult.
In what way? There really is no way to transfer the radio database of one manufacturers hub to another. They all have to be excluded/reset and re paired. If Hubitat has the signature of the device it pairs quite easily and gets the correct driver. Next it will assign what it thinks is closest and that can easily be changed with a button click. Or it will pair as DEVICE and you can change it to a compatible driver with a button click. Not sure where the difficulty lies.
I could be wrong, but I thought that devices controlled by z-wave associations didn’t report the state change back to the hub when it happened. This is why I got away from using associations and just use rules instead. It may be a tiny bit slower, but the hub then knows what state the device is in. I have to assume that the HE staff prioritized using hub based automations over direct associations to avoid this issue.
I think they are talking about how HS could automagically associate ZW devices together, whereas associations are more tedious to set up with any other system.
I have zero clue how HS does that, but I suspect it involves something murky behind the curtain; otherwise, I think you'd see other systems (HE, HA, whatever) embrace an easier path. Or maybe the other systems simply don't see the benefit of putting any effort into it (when rule-based automations can effectively do the same thing).
@user5396 And to pile onto what has already been said, Zwave direct association (including in HomeSeer) is a bit of a mess. I tried it numerous times when I used HomeSeer, and it sounds great, on paper, but it is very device dependent and it can cause the hub to get out of of sync with the devices.
Here's the issue. Let's say you direct associate A to (B and C), so that a change in A controls B and C. Let's assume these are all simple dimmers, but with B and C from different vendors.
When you make a change at A, it will report it to the hub and also command B and C. So the Hub will be synced with A.
B and C also change, but the hub doesn't (directly) see the command, so the hub doesn't know about the change
But maybe the hub learns about the change - here comes the device dependent part. When B and C undergo a change, some devices report every change back to their group 1 associated device (i.e., the hub), others don't.
So, since B and C are from different vendors, B might report to the Hub "I've changed, here is my new value" (ideally, all devices would do this, but they don't). For those that report, the hub gets synced
But maybe C doesn't report. So, though it changed, the hub sees it as unchanged.
Now any triggers that are based on C's state may fail.
My past experience was that "newer" devices tended to report back to the hub any time they are changed, but that "older" ones didn't. I think the newer HomeSeer dimmers / switches will report to the hub, but I had many older ones (WS100+ and WD100+ Zwave Plus devices but with pre-S2 firmware).
So, what you get with direct association is a fast way to control devices, but a lot of user experimentation to try and figure out what is going on with device reporting.
At the risk of rehashing a previous thread, have you seen this?
I have the later model GE toggles. "Multilevel" sounds like a dimmer. If you have the later model dimmers, "alternate exclusion" is also an option on @JasonJoel 's fine drivers.
Direct associations are not standard. Some devices do not support them at all, others have anywhere from 1 - 10 association groups. To know what each group does you need to check with the docs for that device. Now you could assume that group 2 is nearly always a basic on/off event, and usually group 3 has something to do with dimming. Outside of that its all over the place.
If you are really interested in setting up some associations start a separate thread and you can tag me, I can guide you through it.
In Insteon the direct device association implementation was very simple. In addition to the
primary Device Id each device had/has a Group Id. Once Group Id is added to the device
EEPROM it listens and responds to the Commands with Primary and Group IDs matching.
Why the direct association implementation for the ZWave/Zigbee devices is very messy
is a BIG IF.
What makes you say that direct association for zigbee devices is very messy? Endpoint binding (the zigbee term for direct association) is very simple to setup for zigbee coordinators that support it.
I guess, a different thread is better to be created for this discussion.
Anyway, actively using many different Home Automation platforms for many years and
being very experienced EE for near half a century I think (just my opinion) all these current
implementations is extremely and unnecessary overcomplicated. All together this creates a
HUGE mess with all existing communication protocols and brings interoperability near to zero. Think about how smart Ethernet (actually TCP/IP) was design more than half century ago.
Just deliver a packet from point-to-point over whatever existing media (you can use even a
water pipe with say, ultrasonic transducers) and suddenly everything will work just fine.
So, why something very similar and simple was not adopted for the Home Automation
is a big mystery. Instead we have gazillions of different protocols and physical layers.
Each one is talking foreign language and as a result could not understand each other.
Very nice for the 21th century!
But again, this is a very different discussion.