Homekit looses rooms

We have iPads, iPhones and Macs in our household. Yesterday I noticed something strange: Both our MacBooks which we had recently updated to Monterey 12.1 seemed “decoupled” from Homekit iCloud sync. The sync was active, same Apple ID. Items were responsive, lights could be switched off and on, etc. on all devices. But moving Items to rooms only affected the particular Mac and was not synced to the iOS devices. Also vice-versa. Disabling and re-enabling iCloud sync did not help.

Google suggested the following: Disabling iCloud sync for Homekit on the MacBooks, deleting the Homekit folder in ~/Library (this was an important step!), restarting the MacBooks and re-enabling Homekit iCloud sync. I did this on both MacBooks and afterwards they synced again without issues.

I am writing this because I suppose while I had this bug there was no telling which is which in terms of room assignment bugs. I do not believe it was the cause of why we keep losing room assignments with openHAB items. Just thought I’d mention this here.

1 Like

I had yesterday also on my iMac with macOS 12.1 the problem, that items had lost there rooms and I changed them under macOS. They reached not my iPhone, so I do the same again on my Phone. My two iPad’s had no problems with sync. But whatever the problem with the macOS is, I lost actually every time my rooms, when I update the OS (Ubuntu) and make a restart, because a new kernel was installed or an other package need a restart of the server.

Yesterday morning (over night) all openHAB items were back in the standard room. OpenHAB was running non-stop during that time. I know for sure because I have it running on a Mac mini and I have to do a manual start via Terminal every time the Mac restarts. So there is no way an openHAB restart could have happened unnoticed. Don’t know where that leaves us but wanted to report it. :man_shrugging:

interesting and :frowning:

which version of openhab you have?
could it be that you had network disruptions? maybe even a very short one which got recovered quickly? anything in log files regarding homekit restart?

trying to understand whether it fits to the issue reported here

@yfre Eugen, don’t know if this is relevant, but in my log files I can find countless events of “removing existing subscription for …”, shortlly after followed by adding the subscriptions again. Definitely without interaction with openHAB during those events, sometimes connected with Homekit bridge restarts, but not always.But most of these events seem to happen unnnoticed to the user.

My logs are now running on TRACE level for the HomeKit binding and the hapjava HomeKit server. You can have a look if you want.

Christian, in your case im pretty sure that your bridge restarts due the network change events. and currently the restart on network change uses the same functions as binding restart. so, it is a full restart with first removing all accessories and them adding them again. it was just easy to re-use existing logic.

but it looks like it can create issues, so, im working on changing this so that restart on network change is a light one, without changes to accessories list. this should make it faster, fix the issue with room resets and create less entries in the logs.

probably i would need another day or two + few days on the code review.

until then the only solution would be to fix the root cause of the network changes, if possible

or you can install older version of binding, 3.1, without restart on network changes

I agree, but I can also find examples where “out of nowhere” all item subscriptions are removed and re-added. Without any ntewtork interruption/change, without a bridge restart, without any other obvious event in the logs.

I have also lost my rooms but only after installing openHab updates.
I have another maybe related problem when I use Homekit Automation to control OpenHab Accessories. I can create Automations and the Automations can control my OpenHab Accesoriess but if I reboot the Openhab server all OpenHab Accessories are often removed from the Homekit Automation setups after the reboot.

I run OpenHab 3.2 and openHabian on a Raspberry PI 4.

it does not need to be like this. the update should not have any impact on rooms in home app.
have you changed anything in items configuration during the update?
do you need to repair or have you got all accessory back, but without rooms?

regarding automation - it could be the same reasons. if you lose you rooms then home app has deleted all accessories from your ios device and probably removed them from automation as well. once it gets new list it does not have the old information regarding rooms and automation.

you say, “often removed”. so, sometimes you reboot openhab and everything is still fine, rights? in such case, try to increase startDelay parameter in openhab homekit settings. e.g. double it.
it delays the home bridge start if the number of accessories is different to previous start

I lost my room setup and all my accessories was moved to the default room both when I updated to openHab 3.1 and 3.2.

I haven’t found a way to 100 % reproduce the problem with automation. When I reboot my system I have often changed something in my configuration so the removal of the openHab accessories in automations is maybe linked to these changes. When the accessories are removed from automation the room setup for the accessories is still OK.

I have already changed the startDelay to 120 s.

When I reboot I have found the following line in the openHab log:

[INFO ] [mekit.internal.HomekitChangeListener] - Created 20 HomeKit items.

Later in the log I can see that several of the openHab items is changed from NULL to a valid number. Is this OK or is there a timing problem?

changing and adding new items should be fine and not change the room assignments in home app.

but if at some point in time you have incorrect configuration, e.g. typos in the configuration if you do it using text files, then openHAB cannot parse and understand config and reports 0 homekit items and this would delete all information about items in home app, including rooms assignments and automation.

the best practice here is to keep configuration files small (if you do it using files), so that only one part get broken in case on typos.

NULL as value is fine. this does not create any issues. this means that the real device, e.g. sensor, has not reported the temperature yet and in such case homekit binding would send default value to home app, e.g. 0 for temperature. so, NULL is perfectly fine, it just for you information

Thanks for the input.
Up to now I have seen 3 different error scenarios:

  1. openhab items disappear from HomeKit rooms, scenes and automations
  2. openHab items disappear from HomeKit scenes and automations but remains in rooms
  3. openHab items disappear from HomeKit scenes but remains in rooms and automations

I currently don’t change my configuration of items and all my items are defined trough UI. All changes are in rules as I move my rules from DSL textfiles to UI ECMAScrips version 11. I the process I have a couple of times seen memory problems after JavaScript errors and then I reboot the system. So maybe the JavaScript errors or memory problems trigger the problem.
I will keep looking for a pattern in my problems.

interesting. i do have explanation for scenario 1. but no idea how 2. and 3. could happen.
but all 3 items: rooms, scenes and automation are managed only on ios device (and icloud) and home app and icloud are black boxes, closed source and we have no idea how they work, what is the logic and what kind of bugs they have. with icloud and homekit bridge (ipad, appletv, homepad) it becomes even more mystery.

from openHAB we can only send the list of accessories, with accessories IDs, properties and values for properties and hope that home app assigned them to correct rooms, scenes and automation.

I don’t think it’s due to any broken configuration or a change in configuration. Today a Zulu Java update was offered. I stopped openHAB via systemctl, then performed the update and restarted openHAB via systemctl. After that, the HomeKit devices provided by openHAB were gone from their rooms again. In addition to openHAB, I have e.g. a Hue bridge, which makes no problems, but also the “HomeKit Bridge for KNX” from Matthias Hochgatterer also under Ubuntu in use. Here there is no room loss, no matter how I stop, update or restart the system.

Actually I gave up and installed Homebridge under Docker last week and plan to migrate the remaining HomeKit devices.

@iLion sad that OH homekit binding is not working for you. i have no explanation for room lost after restart without config changes. maybe higher startDelay could help but it is 30 seconds by default, by that time the config should get parsed.

can you try to enable high log level, at least DEBUG, do restart and check the log file for this message
" it looks like not all items were initialized yet. Old configuration had … accessories, the current one has only … accessories. Delay HomeKit bridge start for … seconds.", in case you have not migrated everything to homebridge yet

Give it up and save your nerves, Openhab and Homekit, it just doesnt work.

@iLion @Tani agree. if it does not work for you it is probably better switch to another solution as currently no fixes planned (and no clear root cause for issues identified).
however, in most of the cases homekit binding runs without any issue for months and years.

or you can help to identify the root cause and i can try to get it fixed.

1 Like

I’m grateful to @yfre for all the fiddling and late hours which I‘m sure have to be put in regularly. Unfortunately I also have to agree with @Tani that openHAB and Homekit do not go that well together. The problem is that there is no real alternative to Homekit control if one is in the Apple ecosystem. As for alternate bindings, I’ve been there. I tried a node.js based approach which was running fine most of the time but boy oh boy I am NOT going back to that bottomless pit of pain and suffering. The solution is definitely not “add another server based on a completely different technology!” :sweat_smile:

Our “solution” currently is to just leave all devices in the standard room. Admitting defeat, basically. :sweat_smile: Fortunately I decided (long before I implememted Homekit) to name all ligts e.g. “Light in the living room” etc. — so “Hey Siri, switch on the light in the living room” works without Siri knowing anything about room assignments. It is not very elegant as something like “switch off all lights in the study” does not work. But it is doable.

Having said all this, Apple definitely need to get their sh** together! The room sync issue I was talking about before in this thread now plagues all of our devices. Not just MacBooks. I am looking at my iPad right now with room assignments I do not see on my iPhone next to me. There is something very wrong with HomeKit since iOS 15 / macOS 12. At least in our household. Maybe I should remove the openHAB bridge and that will cure it. But, honestly, I’ve done that too often already and even if it is just once a year it is still not a solution.

It is very obvious when using the HomePods (which serve as hubs) that many things are seriously wrong with Homekit. Those buggers were constantly asking for apple id credentials. (This has now been fixed apparently.) Updates would hang. From time to time only one in a stereo pair would play (also now apparently fixed). I could go on.

As long as all of this is happening I’m a bit reluctant to blame openHAB.

I guess we’ll just have to wait for Cupertino to bless their puny subjects with updates. :grimacing::wink:

thank you Jens for your kind words.

actually, i happens to me yesterday, after more than a year - i have lost my room assignments with 122 homekit accessories. argh, i feel your pain.

it was my fault - i was adding new devices and did a typo in the items config. probably I should switch to mainUI for new items.

so, im thinking how to prevent this kind of issues. maybe just dont start the bridge if number of accessories is less than last time and have a button in mainUI to force the start in case items were removed intentionally.

and yes, agree, a lot of home works is on apple side - fix the bridges so that they work consistently, add new accessories, allow homekit device to suggest the room and icons, add custom attributes to devices

1 Like

@yfre May I ask how many iOS devices you have that Apple classifies as “home hubs”? We have two HomePods, two HomePod minis and one AppleTV.

Why I’m asking: I have a feeling that those “home hubs” are interfering with each other in some way. And I think the HomePods are especially prone to causing problems. The problem is that while an iPad (etc.) can be made a home hub via a setting, HomePods and AppleTVs are always home hubs.

After what I wrote above I did the following:

  • Pulled the plug (literally!) on all HomePods and the AppleTV
  • Made one of my iPads a home hub by enabling the option
  • Removed the openHAB bridge from Home
  • Added it again

After doing that all devices (MacBooks, iPads, etc.) were immediately syncing all openHAB devices again. So I could move devices around in rooms on a MacBook, an iPad and an iPhone and all synced.

After doing that I plugged in my HomePods and the AppleTV again. Minutes later: All devices back to the standard room. I have a feeling that the problems began when the HomePods re-entered the scene. I then removed the openHAB bride (again) and added it. Now Home complained that the bridge “could not be added because it needed to be reset”. I then restarted the Homebridge binding (only the binding) and after waiting a couple of minutes I was able to add the bridge again to Home.

Since then everything is working fine. But it has only been one hour or so.

Should the problems return I will try and shut the HomePods off for a couple of days and see if this helps.