I have a question about Z-Wave associations - hoping @jtp10181 will read this!
I would like to use direct associations where one Z-Wave device needs to control another Z-Wave device with a simple on/off logic. Multi-way switching being the classic example. This works well for ZEN 71/72/51's but not all the Zooz drivers give you the option, although Zooz say their firmware supports it.
Does anyone know how difficult this is - is it possible to add a "Set Association Report" command in the Basic Z-Wave Tool driver?
I installed the app using HPM and set up an association between 2 ZEN 71's using group 2. Unfortunately I got the following error:
2023-07-13 03:40:58.630 PMerrorjava.lang.IllegalArgumentException: Command 'setAssociationGroup' is not supported by device 73. on line 71 (method updated)
Is this saying it expects to find the setAssociationGroup command in the driver? I am using @jtp10181 's driver and that sets the association in the preferences rather than as a command.
Unfortunately a similar result using the "Basic Z-Wave Association Tool". It throws the following error:
java.lang.ArrayIndexOutOfBoundsException: -1 on line 216 (method addAssociation)
As this is the device driver code it suggests the Zooz firmware doesn't support the "standard" way of accessing the device associations but @jtp10181 managed it somehow in his driver. Suspect I just have learn a lot more about Z-Wave and read his driver!
I'm not. I have a bunch of things not in HPM (and some not in github too) as it takes extra steps to do so, and I have limited time/sometimes forget to do them.
@jtp10181 : Yes, your drivers allow me to set the associations and they work fine - thank you. However not all the Zooz drivers do support associations (ZEN 04/32/40/43/44 at least) and I don't think you have written drivers for them? So I was looking for a way to set the associations for those devices. I have your code in front of me now & am trying to work out how it's done but this is my first time with a Z-Wave driver!
90% of the time I plagiarize myself I copy/paste a new block/paragraph, then grab a fresh new UUID and paste on top of the old one. After that's more about spelling the package name correctly
In other words, my cheat sheet is any previous json I can access.
I have a driver for ZEN04, ZSE40 and ZSE44
I did not include the code to set associations on these because it seemed like an extreme edge case that anyone would ever need to do anything with them on HE, since you can much more easily write and maintain a rule to do the same things.
What are you trying to do exactly? Chances are it can be done much more easily with a hub rule.
The only one that might be sort of useful is the ZEN32 if you want to use it for dimming, which can be done as a hub rule but may work better with the association (possibly).
This crude driver I ported over from ST (below) can also set associations on any device/group. If you follow the instructions in the second post it shows how to set multi-channel associations, and regular associations are set the same way just without the :# extra digit at the end.
Setting the battery devices will be tricky because you have to time it with a wakeup. The driver does not have built in support to work easily with a battery device.
@jtp10181 : I prefer to use associations when "people" are involved, eg someone opens a door and they expect the light to come on in less than one second. At about one second people start looking for the switch. Occasionally I see delays of up to 10 seconds between the door opening and the rule responding - way too long. I expect this is down to something hogging the hub processor time and I will track it down. However I can insulate my system against such failures by using associations on time critical actions.
I have multiple rules using motion and contact sensors. The speed at which the lights turn on is solely dependent on how fast the sensor reacts. My contact sensor for the basement lights, the light will be on before you even step through the door. This is using a ZSE41 with a hub rule.
Sounds like you have Z-wave mesh issues if its that slow.
I managed to catch the logs of fast & slow switching event. The event is a Z-Wave door sensor opening which turns on a Kasa WiFi bulb.
dev:1202023-07-19 03:08:48.903 PMinfo1 - Rear Hall - Closet Light-2.3.5-1: setSysinfo: [status: [on_off:1, mode:normal, brightness:100, hue:0, saturation:0, color_temp:2700, err_code:0]]
dev:1192023-07-19 03:08:43.271 PMinfo1 - Rear Hall - Closet Sensor is open
dev:1202023-07-19 01:43:07.264 PMinfo1 - Rear Hall - Closet Light-2.3.5-1: setSysinfo: [status: [on_off:1, mode:normal, brightness:100, hue:0, saturation:0, color_temp:2700, err_code:0]]
dev:1192023-07-19 01:43:07.067 PMinfo1 - Rear Hall - Closet Sensor is open
In the bottom log (first in time) the Kasa driver responds 200msec after the Z-Wave device registers the event but in the top log it takes 5.6secs for the Kasa Driver to respond. One might argue that this is a problem with the Kasa driver that just happen when it was processing something else. However I have seen similar behavior on other rules using Z-Wave to Z-Wave events.
So my guess is something is hogging the processor but I think device to device associations only need the Z-Wave radio chip and do not reach the main processor?