Home App delays state updates from HKLS devices

I've noticed lately that most of the time the Home App (iPhone, iPad and Mac) delays updating the state of HLKS devices when the states are changed by Indigo. For example, if I turn on a Z-wave light in the Indigo Home Window, it will not change in the Home App until some time later. I've measured delays from 13 sec to 55 sec. Although I can't say definitively, this behavior seems to be new... like in the last month or two. Additionally, if while waiting for an update in the Home App, I actuate another device within the Home App, the state of the device that I was waiting for changes immediately. So it seems that the new state is updated in HomeKit, bur the Home App simply does not update until the delay completes or it is forced to update by another action.

I am running all the latest software: Mac OS Ventura 13.5.1, Indigo 2022.2.2, HKLS v0.6.17, and IOS 16.6 on all HomeKit devices. Also, as a test, I downgraded HLKS to the released version v0.6.5 and I observed the same behavior. So, it doesn't appear to be an HLKS issue.

Although this is not a serious problem, it is annoying sometimes. Has anyone else observed these Home App delays? Any ideas about possible causes?

Thanks,

David

There is another thread here mentioning this as well.

It seems to be entirely in HomeKits hands unfortunately. HKLS updates status immediately with no way of caching etc. Something has changed with new architecture?

Googling seems to be some reports of behaviour changing when notification relates to person present/not present?
Was going to check - but haven’t quite got to it as yet.

You will notice if don’t have a homeHub can’t setup notifications at all.

We do have a notify immediately option - which appears only enabled for Programmable button presses as per library. Tempted to enable for all and see response - just need a Hub for my test system now…

Glenn

Sent from my iPad using Tapatalk

Have a try of 0.6.20

Updated a few things.

I’m seeing a delay of <60 seconds, perhaps the same as was, perhaps better?

I Looked at the notify immediate setting, this is current enabled at library level, for programmable buttons only. We don’t really use this setting, although essentially some devices may end up being equivalent. Have left it off for the moment, was really a question of enabling it for all or as currently.

I’ll have a better look and see if immediate notification can be enabled for some devices and not others. Potentially this might speed things up a bit.

Glenn


Sent from my iPad using Tapatalk

This seems like new HomeKit behavior to me, perhaps 6.16. I don't usually watch the Home App in real time so I don't know exactly when it started. Last fall however, when I was testing VGD with HKLS, I carefully watched the Home App on my iPad and watched the door states update near instantaneously. Something changed... perhaps we'll have to wait for Apple to find it and fix it.

David

Yeah - I have had a good look and can’t see any library or major code issues. Few updates I have just pushed aside.

Seems like OS behaviour.

Few reports about unifi Wifi settings BBS Transition and the like - but haven’t found anything consistent.

Hopefully OS17 fixes… due soon….

Glenn


Sent from my iPad using Tapatalk

Thanks Glenn.

I think I have tracked this down to me, rather than Apple!

Try out version 0.6.26 - replaces the 0.6.16 pre-release.

Basically after a huge amount of logging (including ipad profile logging from Home App, which reminds me have to remove..), and general looking into, checking code. I believe it was the shared Asyncio ZeroConf instance causing it. Likely was only apparent with more than one bridge and more bridges may have added.

Certainly removing the shared zeroconf instance, and returning (like prior 0.6.16) to one zeroconf per-bridge appears to have returned instant reactions again. Took a bit of reworking to continue with advanced server options which I believe I have replicated.

Have also added locks to the immediate notification category (only button presses currently within)

Try 0.6.26 and report back.

Currently I bundle zeroconf (which is pretty regularly updated) with server plugin. There are some wheels generated with pip install and wonder whether removing the bundle and requiring users to pip3 install it may be better option. This is me thinking aloud somewhat! Currently remains bundled with latest version.

Glenn


Sent from my iPad using Tapatalk

So I’ve updated from .21 to .26 but my HomeKit devices all say no response in the home app. I’ve ran the permissions fix but no joy, and revering to .21 revives the devices. Not done any other troubleshooting yet as didn’t wanna risk knackering my config


Sent from my iPhone using Tapatalk Pro

Hmmm.
At a guess will be something in the advanced options panel (whether you meant to have it there or not). This is the HKLS Plugin Config page - advanced options.

Do you have any logging - for example 0 HomeKit devices started. This is often the error when something in advanced config is wrong. A network adapter that doesn’t exist etc..

I have upgraded 2 systems without problems. And on the test system did have to test a lot of advanced options - to make sure was all going.

Let me know what you have in there…

Won’t break any config things once going (well shouldn’t…)

I suspect you have something entered in advanced config that you perhaps shouldn’t? (defaults or all empty would be ideal)

Glenn


Sent from my iPad using Tapatalk

So in .21 I have it configured to use my server IP and ipv4. I’ve updated to .26 and those settings have.. vanished. I’ve re-populated them, but still nothing.

As for the logs.. all bridges and 166 devices load as normal, no errors in the log.


Sent from my iPhone using Tapatalk Pro

Well I updated to .26 and now everything refreshes almost immediately so you have eradicated that bug. Thank you

So in .21 I have it configured to use my server IP and ipv4. I’ve updated to .26 and those settings have.. vanished. I’ve re-populated them, but still nothing.
Sent from my iPhone using Tapatalk Pro

@durosity
I did play around with the Advanced option menu and got the same problem as you, the answer is use only IPVersion.All and leave the 2 IP address's under that to nothing, when I filled them in I got the same as you did, no idea what they do but definately not required.

Don't clear the Driver Start Port Number, that is terminal death and needs you to delete the indipref's file before it will start again.

Basically I will be leaving the Advanced Menu alone.

Yeah I did try it with the ip all setting but no dice!


Sent from my iPhone using Tapatalk Pro

This works for me

[img]

Use with care, only updated on plugin StartRestart. Show Advanced Options.jpg (50.97 KiB) Viewed 1317 times

[/img]

Hi Glenn, I installed HKLS v0.6.26 and everything works great in my system. HKLS device states update near instantaneously.

Thanks for the quick fix.

David

Glad all is working well, and much much quicker for everyone. Well everyone except durosity that is…. Not quite sure how I missed this - asyncio was queing the command, but appear would be delayed depending on what else was going on with this async ‘thread’.

(Slightly concerned about overhead this approach might cause (in my testing CPU hasn’t been particularly high). This may not yet be final approach - could more properly share a brand new Zeroconf instance across all bridges… )

Few pointers:

1. Advanced settings - as per the blue down the bottom - to action these you need to reload the plugin and restart it entirely.
2. Best default option is to have completely blank for the 2 boxes which can have IP addresses in them.
3. IP Version will be either IVP.4 or IVP.All - 6 essentially isn’t used for HAP server side. (so no way to be only IVP.6 - after typing this probably should remove it as an option…)
4. Would force restart Home App for good measure

Leaving these IP boxes blank, should work as default for 99% of users.

Not sure why you have IP address in here durosity? (don’t believe it was part of any past troubleshooting)

Can PM me zipped log at startup, with debug pyHAP library bit on.

Sent from my iPad using Tapatalk