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.
I appreciate your attention to the details here... That spreadsheet actually helps a bunch.
Can I assume that the device you are using creates a composite child device for both the light and fan?
The way it was designed is assign the individual devices (light and fan) to the individual defined inputs or light and fan type.
I'm certain there is definitely some changes needed to the fan capability detection under the plugin.
As far as your changes i think it only needs to be to add support for 5-speed fans and make sure speed attribute and FanControl capability added.
Give me a few and I will see if I can get this working
Both the Modern Form Fan and Haiku Fan drivers don't use individual child components for fan and light. They are a single driver. I have the Haiku Fan.
I can probably convert the Haiku Fan driver to parent/child form. Although it is a bit sad that we can't support both fan and light on the one button, like this:
What are your thoughts on a "single speed fan" category to get this functionality:
The device it is hanging off is an Aeotec Nano Dimmer which supports Switch and SwitchLevel, however I've configured it to have a min and max value of 100 and definitely want it behaving like a switch without level control.
I’m not saying we can’t support both, in fact I want it to be that way. I just want to spend some time and code it right.
Quick question, I set port 8000 for direct connect in my config, but in the status area of homebridge I see it listening on port 8001. Is that correct? Not seeing any errors and all devices seem to be working fine.
This is from the status:
[2/8/2021, 9:56:16 pm] [Hubitat-v2] INFO: Direct Connect Active | Listening at 10.1.20.19:8001
My config:
"direct_ip": "10.1.20.19",
"direct_port": 8000,
If 8000 was in use the plugin tried the next port
