Hi there, long time Insteon owner trying to switch to newer and better things. I have a hubitat and after evaluating a few brands of switches picked up a ton of Inovelli red series dimmers and switches.
One behavior I got quite used to with the Insteon dimmers was how they handled a tap while in the dim state. With how many options these Inovelli dimmers have, I know there’s probably an option to handle it, but I figured I’d ask the group if there’s something I’m missing.
Insteon Dimmer Behavior (firmware 1.48 and the inovelli driver from 2021-01-28)
Dimmer set to 50% Single tap up → Full Power
Single tap down from 50% → Off
Inovelli Dimmer Behavior:
Dimmer set to 50% Single tap up → No change
Single tap down from 50% → Off
Now, I tried mucking around with catching the Button 1 behavior at the Hubitat and then setting the level to 99, but it isn’t as responsive as I’d like. Not to mention setting that behavior up on a bunch of the dimmers in the rulemachine is a drag. Is there a parameter that supports this behavior at the switch level?
Haven’t done anything with groovy, but maybe I may be able to put this behavior at the driver/app. But it seems like it would still have about the same latency as having hubitat process a rule.
That would be one way to do it. Depending on how intuitive you want it to be, you can also use the config button and you won’t have any problem catching that.
Buttons are already exposed, you have to trap them on the hub side.
If it wasn’t noticeable, I probably wouldn’t have asked The switch in question I’m trying from is about 15 feet away from the hub, so there shouldn’t be any repeating, but there’s nearly a full second in the response time. Compared to the instant behavior from the last switches, it feels broken enough that my family noticed the difference and asked what was wrong. I did the default security options when paired (s2?), would that be an issue in the response time?
Don’t know how to tell about the hops, will do some research. Toying around with it a bit more, I think the problem is more related to when the switch decides it’s a single tap vs multitap up - Setting the option “Button Press Delay” to 100ms seems to make my scenario more responsive and still recognize the double taps (and might be good enough to pass the family test). If it’s ‘good enough’, I will take a look to see if I can make an app or something that builds that rule for all the dimmers.
@PBergman use the Z-Wave Details tool accessed by going to the kebab menu on the top right. Hops and bandwidth are shown in the far right column. Top device routes through the second device to get to the hub.
Thanks for that. The device in question I’m messing with is Kitchen Overheads (0x1C), I’m having a hard time reading if it’s taking one hop through Hallway Slave or going through Hallway Slave->Master Bathroom (which would be silly, as hallway slave and kitchen overheads are in same junction box and master bathroom is on a different floor through 35’ of drywall.
I agree with you that it looks like Hub → Hallway Slave → Kitchen Overheads, but I’m not sure how/why Hallway Slave is going through Master Bathroom Light. I’m not on Hubitat so I’ll cede to others on that.
The concerning thing to me is the 9.6kbps, these are capable and should run at 40kbps, (like the Hallway Slave). I’d recommend a heal mesh and see if anything changes.
Edit: also any reason Hallway Slave is None on security? Usually I like my devices to match security if possible.
no idea why hallway slave is none on security. It has no load and is using zwave association to drive another dimmer. I can remove and re-add. That may be the issue causing the lower bitrate.
Master Bathroom 0x09 is another brand switch that I was testing out.
I second @kreene1987’s suggestion. Your mesh isn’t behaving correctly. The slave is probably the discrepant device and it might be related to the security levels. Most of the time, when you have a switch misbehaving over z-wave it’s because something is going on with an intermediate device. When the big Hubitat update came out earlier this year and I performed a mesh repair, it’s been more solid than ever without even a hiccup really since then.
I used to have large >5s delays on one particular dimmer on occasion and it turned out it was attempting to route in the most backwards way possible (like going in a circle through walls vs direct line-of-sight). The routing doesn’t always make sense at first glance, but a healthy mesh minimizes hops and maximizes signal strength all in order to maximize bandwidth and thus minimize latency while keeping high reliability. It’s pretty interesting to watch the mesh reroute over time, especially for devices that don’t message very often (battery sensors mostly).
Thanks for the guidance, I ended up re-adding them and repairing the mesh. Most of them show 100kpbs now. There’s still some funniness where some switches seem to route out of the ‘logical’ way. I think between that and setting the button press delay down to 100ms (I think it defaults higher), it now mostly passes the family test.
I hadn’t ever played with groovy before, but am a software developer for my day job, so to make my life easier than using the rule engine, I built an app to do the “if got button press and my level is less than 99, set level 99”. It work great for the non-associated, but that strategy (and rule engine) seems to have some difficulty with the z-wave associated switches due to some race conditions. It does seem if I get that notification from one of the ‘client switches’ and set the level on the main switch then it works well.
The switch in question I’m trying from is about 15 feet away from the hub, so there shouldn’t be any repeating, but there’s nearly a full second in the response time. Compared to the instant behavior from the last switches, it feels broken enough that my family noticed the difference and asked what was wrong. I did the default security options when paired (s2?), would that be an issue in the response time?
