Home App delays state updates from HKLS devices

I think I originally entered them myself a fair while ago when I was having an issue where it was binding to a different IP address I use for a Drobo iSCSI device (yes yes I know it really needs replacing!), but here's the weird thing... I've just went in, removed the IPs, reloaded the plugin, working fine, updated the plugin.. working fine. Seems like somethings happening where even although it wasn't seeing the IPs on .26 they were still present somewhere in the background, but removing them prior to update resolved the problem!

Thanks for all your work on this plugin, it's really amazing!

Glenn, you mentioned in a previous post that you moved from a zeroconf instance for each bridge to a shared zeroconf in v0.6.16. That seems inconsistent to me as I just recently tested with v0.6.5 to see if delays were present... and they were there. So... if there were multiple zeroconf instances in v0.6.5, a shared instance in v0.6.16, and now back to multiple instances in v0.6.26, I would expect no delays in V0.6.5, delays in v0.6.16, and no delays again in v0.6.26. I'm just pointing this out in case there might some other cause of the behavior, maybe unrelated to zeroconf instances. Just a suggestion.

David

Thanks

The seperate Zeroconf instance came in between 0.5.11 and 0.6.0. It’s been there for a while…

(Pretty hard to rollback to 0.5.11 given architecture changes, so wouldn’t recommend it. May be fine, but 0.5.11 and below no longer file saves the homekit device iids so they stay consistent. Which they mostly did anyway - but saving ensures they will.)

Pretty happy relates to Zeroconf. May yet change to a single Zeroconf thread / asyncio for all bridges. The previous attempt was obviously bogged down in plugin and bridge actions somewhere so was not happening quickly enough. Interesting one bridge only should not have noticed any difference - perhaps why not major reports.

More thinking aloud follows, while a ‘proper’ instance would probably also fix, it would create potential issues if Zeroconf instance fails with bridges/or rest plugin still up. Combining the 2 as I do here at least bypasses that potential complication. One combined instance would likely use less overhead potentially, but may not be that much difference overall. A seperate cooperating with other Zeroconf instances (as currently) with each bridge would likely in most, if not all circumstances be the most responsive.

The combination of Indigoserver, plugin, threads and asyncio (which zeroconf is and pyHAP homekit library) is a minefield basically.


Sent from my iPad using Tapatalk