Hello, I searched the last days and found mostly old threads with openHAB 2 where it was described that the Homekit integration looses rooms. I just started some weeks before to integrate all my KNX items also in Homekit to consolidate my setup. Before I used only three shelly devices and some AVM DECT 200 outlets with openHAB / Homekit integration. Now in the two last weeks I lost three time all openHAB rooms. Now I did not like to sort again and thing about give up. My openHAB is 3.1 in a virtual Ubuntu Linux 20.04 LTS, running as a KVM virtual machine in Proxmox. Are there any new ideas what can be the reason for this?
Hi Lars,
rooms are stored locally on apple device, i.e. openHAB has no way to define rooms or assign an item to the room. it is not openhab but apple limitation.
the only things that helps a little is to put the room name as first word in openhab item name, e.g.
- kitchen_light
- bedroom_night_lights
it will not create the room but it will help to pre-select the room from the list and also remove room name from the item, once it is added to the room
now to reasons for room assignment lost: if apple device get an empty list of accessories then it will delete all accessories and rooms assignments completely. next time it get the accessories list it cannot find the room assignments.
one of the most common reason for empty accessory list is broken openHab item configuration,
e.g. you are changing something in configuration, store it and it is invalid, e.g. syntax error, so, item list cannot be created. if apple device request an accessory list, it will get an empty list and will delete room assignments
if you change you configuration often, then either wait with room assignments until you get stable configuration or install app to make home app configuration backup, e.g. “Controller for Homekit” ‎Controller for HomeKit on the App Store
Hi,
the broken configuration could not the reason. You see my late reply to your answer, I had not time to change actually anything at my openHAB instance. Today again all items are lost from the items. The only thing what happened was a Backup job of my Ubuntu machine. I used a KVM machine inside Proxmox and at the weekend, the machine will be stopped, a backup created and started again. And after this Backups, I had lost mostly the items from rooms.
I think I will delete the Homekit definitions from openHAB and go back to my old solution for the KNX devices HKKNX. I makes not so much fun to assign a big list of items every week again.
yes, agree. assigning all items to rooms is not fun.
there is not much we can do on openHAB side for it. ios asks regularly for list of homekit accessories from openHAB and if for some reason that list is not complete or very different to previous one, then ios will delete all items and rooms assignment.
it must be something in the startup phase, where not all items are loaded but ios home app asks for the accessories.
we have even implemented a feature for this case - startDelay. it delays the homekit binding starts for 30 seconds (configurable) if the number of accessories is different to the last reboot.
i dont have experience with KVM, but if you start the machine again, do you restart the openHAB or you just load it as memory snapshot without real openHAB start?
this kind of complex scenarios with KVM and backups with full stop would difficult to reproduce in order to find and fix issue you have. so, if you have a working solution with HKNX then probably better to go back to it.
The KVM maschine is like a normal PC. When I make my backups, I shutdown the complete machine and make a fresh boot after. The OS is Ubuntu 20.04 LTS, so for openHAB the complete process is like a restart. Where can I find more information about the startDeleay? Or is this something coming with the openHAB 3.2 release?
if it is a proper restart of openhab then it should not have any impact on the home app and room assignments.
nevertheless, try to increase startDelay via ui settings
you can also try to
- increase log level (via karaf console
log:set TRACE org.openhab.io.homekit.internal - check openhab log files after reboot
it should report how many homekit items were found and created
1 Like
Hi!
Just wanted to chime in and write that I’m facing the same problem. Since a couple of days (maybe weeks) Homekit removes all devices from my rooms and assigns them to the “standard room” if I do a system:shutdown and then start again. It is definitely a proper restart, no killing of processes or anything. Of course iOS 15 happened around the same time these problems startet, so this could be the cause. I know that I did not change a single thing in my openHAB configuration for quite a long time now.
Just to be clear: My rooms are not removed. Just all devices are removed and put in the “standard room”.
Since I have to restart openHAB every time my internet connection (cable) fails (this causes problems with the homematic binding for reasons that escape me), this is starting to be a big problem. I have arrived at a point where I am thinking of forgoing rooms in Homekit completely and just leaving everything in the “standard room”.
I will try to increase the startDelay though, which I didn’t know of.
Bye
Jens
I have increased the startDelay from 30 to 120 (I’m assuming these are seconds) and restarted openHAB. This time the devices remained assigned to their rooms. I will monitor the situation and do a couple of more restarts tomorrow.
It might be interesting to know that I’m running openHAB on a Mac mini 2018 almost exclusively. The relatively high speed of the system might add to the timing issue. (If it is one.) From what the OP @iLion wrote I gather his system is also on the faster side of things.
1 Like
Just in case you are still looking (and for everybody else): You have to look under “Other Services” and not under “Addons” → Bindings. I’m running openHAB 3.1 Release.
let see. if it helps, we could increase the default value from 30 to 120 seconds or even longer. this delay has no impact on normal start / reboot. it delays the homekit start only if the number of accessories is lower than last time. so, it is fine to have a bigger delay in such cases.
1 Like
Come to think of it: While I did not change the openHAB configuration for a long time, I did move openHAB from a much older Mac mini to the 2018 model. There was a lot of iOS and Mac shuffling going on in our family a couple of weeks ago because we needed to upgrade some of the kid’s devices which had finally gotten too old. That’s why I completely forgot that we also switched out the Mac mini. I guess it’s a credit to openHAB that the switch went so smoothly (copy over the folder) that I did not remember it at first. 
Anyway: All the more reason to suspect that the speed of the host could have something to do with it.
Ok, this weekend I spent some time to solve this issue. Spoiler: No solution up to now. First I changed the startDelay option for up to 180 Seconds, because I thought that this could be a problem with my KNX devices. Most of them are Powernet devices and need some time to respond their status when openHAB starts. But every start all items are moved from their rooms. I also own a license of the app Home+, where you can make a backup and restore. I tried this the first time, but the backup did not finished and after, one of my lights has his own life and switches randomly. At the end the decision was to start from scratch. I removed all bridges and devices. Deleted my homekit home and created a new one. You can imagine what a lot of work this could be. I also removed all homekit assignments from my KNX items, at the end only 14 items come actually from openHAB to homekit. This are three Shellys, five AVM DECT 200 plugs, two VELUX rollershutters and three virtual switches for sending signals to my garage door. Last night my server was shutdown again for backup and at the morning, all openHAB items had lost again there rooms.
Now there is only one idea left, that this could to something with the VELUX items, because I had the problem that the items are still offline after a restart, up to the time I power off the KLF200 gateway and power on after some seconds. When not, openHAB could not connect to the KLF200 again. Perhaps there is a solution for this to automate this process, because I had a Tasmota based plug for the KLF200 installed.
It is very frustrating.
the response time of the devices should not lead to room reset in home app.
the only way to loose rooms, if home app receives a list of homekit accessories which is empty or very different one.
if some accessory have no value it should be fine, as long as they are on the list. also downtime is not an issue.
as examples following sequence would delete room assignments:
- home app requests list of accessories from openhab
- get 100 accessories.
- you assign the rooms in home app. home app stores the link between “accessory id” and “room” locally on ios device
- after some time home app requests the list of accessories again (maybe on app restart or just to get status of accessories
- it receives an empty list from openhab.
important: it should get response. in case of no response it would just try later again. - home app thinks that devices are gone and delete them from local database including the link to the room.
- after some time home app may request the list again, and will potential get the complete list with 100 accessories, but it has not room in the local database from them anymore.
the key question is why the list get empty.
do you see any errors in the openhab log? try to increase the log of homekit binding. it should tell on start how many accessories were found
One week before I cut the connection between homekit and openHAB, cleared over the console the homekit pairings and connect openHAB with homekit again. I reduced the items now to 11, no KNX items anymore. The last week I had an restart through the update to openHAB 3.1.1, at the weekend the shutdown for backup and today for the upgrade to openHAB 3.2. In all cases the homekit connection was stable and I lost no items in rooms. For the moment, it is ok and I will use HKKNX for KNX connection to homekit as an extra bridge.
Had to change the RAM of my openHAB server today and there was a downtime of approx. one or two hours because of that. After the server was up and running again all Homekit devices were back in the standard room. 
Not sure if this was related to the long-ish downtime (@yfre 's post would suggest otherwise) or if it was the restart in general. Which would suggest that increasing the delay time significantly hasn’t really worked for me.
Anyway… it is really annoying. 
correct, the downtime as such, including long downtime, or long network disruption should not reset room assignments in home app. i tested on my side with downtime > 1 hour, all recovered afterwards
it is not documented by apple but it looks like the logic is pretty basic.
home app stores on the device/icloud for every bridge like openhab following information
- accessory id (which is openhab item id)
- room selected by user in home app
- icon and local name (if changed by user in home app)
and in case home app receives accessories list from openhab different to previous, e.g. different accessories Id or accessories is missing, it cleans up the assignments to rooms and names.
room and name information remains in device/icloud and never transferred between openhab and home app. so, we have no change to influence it.
Thanks for the detailed explanation. 
How can I tell which devices are being reported to Homekit? Could I perhaps increase the log level of the binding? I suppose it can happen every time Homekit polls the bridge… I have no idea how often that happens. I would have to isolate the incident where the list is empty (or at least incomplete), correct?
Another question: What happens if the openHAB server is reachable but the timeout (in my case 120s) is still running and Homekit polls the server during that timeframe? Is the response delayed? Is the request rejected? I’m just tossing around ideas because clearly this only happens on startup (or restart) and never during normal operation. At least as far as I can tell.
Maybe I should try and set the delay to an insane amount like 20min or so just to definitely rule out openHAB sending an empty device list?
homekit binding accepts requests only after startDelay is over, until that point binding does not respond to any request and looks for home app as down. this should not remove the rooms assignments.
once startDelay is over, homekit binding start to accept requests from home app and sends whatever it has identified as homekit accessories to home app.
try to increase the log levels:
- in order to get more details on config parsing, startDelay timeout, number of accessories found
log:set TRACE org.openhab.io.homekit.internal
- in order to see every single request and response to home app
log:set TRACE io.github.hapjava
Last week, some packages for Ubuntu 20.04 where available and because of an kernel update, a restart was required. With this necessary restart I lost the rooms for all items coming from openHAB. Yesterday, my scheduled backup with shutdown and restart was made and everything was ok, All items stay in there rooms. I did not see any real difference between both restarts for openHAB.