If you group the devices in HE and expose that group device to NR?
edit: I see you have some groups already in the sequences. I will add some more devices to HB including lutron switch or two and see what happens.
Using 2.2.2 of your plugin and really amazed by how well it works. Working well on both my C-7 and C-4 HEs. Question - I noticed you are running HB 1.2.5. I'm still running 1.1.7 and all seems to be working well with the exception of a couple frozen devices occasionally in IOS. Did you notice any improvement going to 1.2.5 ? Trying to decide if the HB update is worth doing. Thanks!
I really don't think it's your app or the plug-in as I'm seeing the same (or similar) behavior if I use RM, Nodered or Homebridge. I'm running 1.2.5 for my "live" instance and just installed 1.3 beta on the "test" instance (very few devices on this).
At one point, someone had recommended (in RM) that I check if the device was "on" before sending the "off" command. I did that for all my Z-Wave devices but not for Zigbee. I carried the same logic over to Nodered. For a couple of lights, that are activated by a lux reading, I now keep the status of the device in a global variable and just check that before sending the "off" command. This is primarily to avoid having to get the state from HE every time the lux reading changes within the threshold range. Any thoughts if this approach should be used for other devices as well?
My understanding is the HE Device Node caches state so you can check it with little or no impact.
1 Like
Also be careful about using "Globals" if you want them to persist use a "file storage" based context...
https://nodered.org/docs/user-guide/context
Apologies for deviating off topic!!!
Yep - I haven't used "file storage" but I do get the current state on startup and populate the global variable and also once a day (just to be safe). I also have the "send event" checked in that flow so every time the state changes, the variable will be updated. That way (hopefully), NR and HE will be in sync.
This is not necessary the HE Nodes will keep state for you. In the config under advanced you can also set it to rebuild cache on Hubitat systemStart event. Much better than trying to manage it yourself.
Edit: might want to take this over to the NR thread..
If you can put the lights in a group, or groups, then you can select optimize on/off in the group which will do the checking for you. I’m assuming you’re dealing with z-wave since it’s taking so long. I had this problem a while back (before I got rid of my non-plus devices and replaced them with Zigbee) and this made a big difference for me.
1 Like
I just noticed a big improvement with a HomeKit installation that I've done.
Instead of sending my lights from Hubitat to Homebridge to HomeKit, (they are approximately 60+ Lutron switches), I found out that you can connect Lutron directly to HomeKit. So, I've pared back on the HomeBridge to just non-Lutron devices.
2 Likes
I have a mix, Z-Wave (Plus and non-Plus) and Zigbee. I have the Zigbee devices in groups and use the optimize for the group, hence I don't check for current status. For the Z-Wave I do - the non-plus devices are the locks (old Kwikset ones that I've had for ages). Also, possibly a GE outdoor plug and a Leviton switch (though I think this is plus). I think all my other Z-Wave stuff should be more current (Inovelli - black and red series Zooz Zen25, Aeotec multi-sensor).
I'm also on 1.2.5 and is working very well. Recently I was on 1.1.7 like you. If you are using the Config-UI-X plugin its very easy to upgrade/downgrade homebridge versions. I tried 1.3 beta not too long ago but I was getting longer device status updates so rolled back to 1.2.5 in a matter of minutes.
3 Likes
Thanks for the quick feedback!! Will definitely give 1.2.5 a try, especially given how easy it is to go back. Thanks again!
2 Likes
Some more research on slow/non-responding commands:
I’ve done more digging, watching the logs in real time under 2.2.5.XXX now:
Homebridge 2.2.2 is clearly sending commands to lock, close, turn off 60 some odd devices with a Apple Scene I created. It’s almost like my C7 ignores some of them. I see the app send the commands, but some devices just never get told to execute, or it takes over a minute. Very strange. Maybe something in the handoff to the z-wave chip?
My mesh is strong, I have good SNR, good response times for individual devices. It’s like my C7 just gets dumb sometimes.
Next step is to see if the number of “lights” on and items to execute makes a difference. My hunch is that one or two lights and the lock to turn off, and it’s very reliable. Have 20 lights to turn off, 2 doors to lock and a garage to close and the reliability/chance of everything happening goes down to near zero.
I welcome any thoughts and feedback, but this doesn’t appear to be a Homebridge issue...
Are the lights Zigbee? If so create a group and enable "Zigbee group messaging".
If not you still might want to create groups and/or matching scene in HE and call it from Homekit..
It sounds like HE may have a zwave queue size limit, and the large number of commands has it dumping the queue?
There is, although limit is pretty generous. I can add an endpoint for people running into limits and willing to experiment.
3 Likes
I'm going to be That Guy. 
Popping in to ask @tonesto7... is the Button functionality coming soon?
1 Like
Buttons are a nightmare under homekit with the way Hubitat split out all the buttons 
Unfortunately, It's at the bottom of my priorities list at the moment.
Sorry for the bad news!!!
Noooooooo! 
Thanks for letting me know!
1 Like
Hi @tonesto7,
I reverted my changes and tried adding the fan light device to the Lights category in Homebridge v2 Hubitat app. This resulted in only the light being visible in Home, no fan. And of course, I'm not able to add the same device again under the fan category.
I've done an audit of all available fan drivers for Hubitat, built-in and community, and have come up with this capability matrix:
As you can see, all fan drivers support FanControl, while some support SwitchLevel for either controlling a fan or controlling a light. After doing some research into the history of SwitchLevel for fans, I see some merit in allowing SwitchLevel for DC fans that allow any percentage level to be set.
My problems with the current implementation of homebridge-hubitat-tonesto7 are:
- No support for FanControl and setSpeed(). fanSpeed attribute and setFanSpeed() are not valid in Hubitat.
- No support for fans and lights under a single button in Homebridge
- No support for fans on dimmer delays to act as single speed fans (such as exhaust fans)
What I propose:
- In Hubitat Homebridge v2, have the following categories under Fans:
- Fans (percentage): Any device with capability SwitchLevel
- Fans (single speed): Any device with capability Switch
- Fans (3-speed): Any device with capability FanControl
- Fans (4-speed): Any device with capability FanControl
- Fans (5-speed): Any device with capability FanControl
- In homebridge-hubitat-tonesto7, use:
- setLevel() for percentage fans
- on()/off() and disable characteristic rotation for single speed fans
- setSpeed() for 3/4/5 speed fans.
If this sounds OK to you, I'll get working on a PR.
