Everything was working as I kept adding lights and sockets to conf/items/ihc.items file
At one point homekit items just stopped responding. From openHAB interface everything works, but in Home application on iphone, all items just read as “Updating” or “No answer”
On the iphone, I removed the openHAB bridge and then added it back. This resolved the issue for now. Not sure if this will re-appear though.
The process of adding the openHAB bridge to homeKit is quite tedious as it asks about location for every light (26) and socket (9) in the house.
It happened again. All Homekit items became “unresponsive”.
Of course I can remove the bridge and add them back, but since there are 29 lightbulps and 11 sockets, this takes quite a while.
Effectively I will not be doing that every week
I’m seeing this same behaviour. If I restart openHAB, all is well again for a while, but then I get no response from all 43 accessories. Not yet upgraded to 3 so I don’t think that’s the issue, however, until recently it was working without error.
there could be many different reasons for unresponsive items.
examples i saw in the discussions:
firewall rules
bad networking connection / unstable access points
apple tv/ipad/homepod configured as homekit bridge but got disconnected
usage of IPv6 or changing Ip address (often in combination with docker)
race condition bug in mDNS library we use
sleep mode of openHAB server (cannot reconnect after the sleep mode)
missing rights to write jsondb/homekit.json that stores information of connected items
homekit.json got lost/overwritten
in general,
if restarts of openhab helps, then it is probably issue with openHAB / homekit binding (not enough memory, sleep mode, etc).
if restart does not help then it is either network issue or issue with homekit.json.
as the first step, when you get “unresponsive” next time, please check with “discovery” app whether openHAB is visible for your iphone/ipad as described here
I’m starting to use OH3, with deConz (Raspbee II, operating ok), z-wave (Zwave.me not yet initialized), and RFXComm (TRX433E, mainly Energenie and Oregon, with a touch of Anslut and ARC). Many of these things are being exposed over HAP for Homekit. This is a new system for me too; however, I am not a new hand to this I’ve been using Domoticz for years. So far, with OH3, I’m well impressed. It’s vastly superior to the performance of Domoticz and with Homekit integration, I wouldn’t have to run my own software to integrate with Homekit. I have never been much of a fan of “home bridge” either, also generally because of poor performance.
Responses are instantaneous, no more waiting for a second or two…Seemingly, no more misfires, but this is a new deployment, so time living with it and using is the only true testament.
I currently have around 30 items exposed over HomeKit (zigbee and 433mhz items), I expect this to more than double over the coming weeks as I get Z-Wave moving.
Now to the point, Homekit Integration fails for me too. I have it running in parallel with an existing system that is stable and runs for months without interruption (Domoticz is the master manager). I am in the process of duplicating an existing system, the one I intend to replace. So far in its 2/3 days of deployment, I have had to restart the server every morning. A restart solves it, but a restart is required. Now, this is a real shame because everything else is ticking away happily, there is nothing present in the tail log to suggest something has gone awry.
I intend to run ZWave door locks through this, so I can’t afford to run a system that might become unresponsive at the drop of a hat.
Just to re-enforce the investigation level:
firewall rules
– no, there is a current installation working
bad networking connection / unstable access points
– no, there is a current installation working
apple tv/ipad/homepod configured as homekit bridge but got disconnected
– no, there is a current installation working
usage of IPv6 or changing Ip address (often in combination with docker)
– no, there is a current installation working
race condition bug in mDNS library we use
– what’s this?
sleep mode of openHAB server (cannot reconnect after the sleep mode)
– what’s this?
missing rights to write jsondb/homekit.json that stores information of connected items
– I’m updating this regularly over the course of a day as I configure the system, so this is unlikely
homekit.json got lost/overwritten
– no, a configuration is present, correct, and works (when it’s responsive)
memory
– no, Not much happening, 3% CPU. It’s running at 400MB of 4GB and I have a swap file of 1TB. I’m ‘htopping’ on a regular basis to check for load and leakage. I have seen memory growth of around 6/8MB from start-up over 4 hours this morning. I would expect that growth to level out; to continue growing would constitute a small memory leak and you will eventually run out of memory, regardless of how much you have.
I said the previous system is running Domoticz and that the HAP implementation is my own. To clarify, it is written in Swift, runs on a Mac and it uses Bonjour. So there are no ‘differences’ to compare. That system is stable and operational. The reason for the switch is dependency on multiple systems, I want a ‘one stop shop’ with everything integrated. A couple of by products seems to be one, a better, fresher, more modern management interface (even though I’m seeing some evidence of bugs) and general performance.
I have just turned off the internal wifi power management of the PI (RPi4) as there is some evidence that it will turn off if it detects no activity.
For anybody who wants this turned off here’s what to do:
iwconfig will report on power management state
/sbin/iw wlan0 get power_save this also reports power save
To manually turn off power saving: sudo /sbin/iw wlan0 set power_save off
For reboots change the file: sudo nano /etc/rc.local
Before the line exit 0 put: /sbin/iw wlan0 set power_save off
When I’ve finished this PI will use PoE and be placed in the loft, so the WIFI settings will be a moot point. But for now and for some it might fix the problem. I’ll find out tomorrow…
then it is probably the mDNS issue. once your items are not responsive next time check with “Discovery” ios app or something else whether openHAB is published/visible via mDNS.
you can also try to switch off “Use OpenHAB mDNS service” in homekit binding setting.
The power management disable on the wifi didn’t work. So, if I turn off the mDNS on the integration will it automatically fire up the Avahi daemon and start advertising through that?
it uses java based mDNS library jmDNS. the switch tells only whether homekit binding should start its own instance of jmDNS or uses one included in openHab
Switching off the ‘internal’ nDNS didn’t work. It’s still unresponsive this morning. The HAP service is being advertised OK, I can see it. I’ve checked memory and we’ve got 9 hour uptime and we’ve swallowed an extra 10MB ram from start up, so it’s on around 408MB now. Power management is still turned off on the wifi card.
I am seeing this in the service start up log:
Sep 06 21:49:30 openhabian systemd[1]: Started openHAB instance, reachable at http://openhabian:8080.
Sep 06 21:50:06 openhabian karaf[1525]: RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0
Sep 06 21:50:06 openhabian karaf[1525]: RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
Sep 06 21:50:06 openhabian ka**Warning:** The unit file, source configuration file or drop-ins of openhab.service changed on disk. Run 'systemctl daemon-reload' to reload units
raf[1525]: FAILED TO OPEN: Permission denied
Sep 06 21:50:06 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Sep 06 21:50:06 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Sep 06 21:50:06 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Sep 06 21:50:15 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Sep 06 21:50:15 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Sep 06 22:06:03 openhabian karaf[1525]: FAILED TO OPEN: Permission denied
Now I have ‘fixed’ this on numerous occasions by running systemctl daemon-reload. It doesn’t seem to actually fix the problem. It doesn’t stop the HomeKit integration initially, but it might have some effect later.
Got any ideas as to what this problem is? BTW, thanks for your persistence with this.
As an experiment, without restarting OH or the PI, I flicked the HomeKit integration nDNS from external, to internal (saved) and then back to external and saved again. It reactivated the service. So, I’m of the option that whilst the issue is around advertising, the source of the problem is inside the integration and not with the actual mDNS / jmDNS implementations themselves.
I think that requires a developer fix, is the integration actively supported?
I asked about maintainers… But it looks like you are the maintainer? (of the add-on, if not the actual java HAP module which is Beowulfs?) It doesn’t look like that source has changed for some time.
What can we do about missing characteristics, as there are lot’s of them.
correct, im maintainer for homekit binding and did also some work on java-hap lib.
to my understanding we dont miss that many characteristics, besides of TV/Audio support. i tried to add all characteristics of a type.
Do you have examples where we have accessory type but not all characteristics? actually i dont know what to add to the binding, therefore no new commits to it.
and of course contributions are more than welcome.
regarding your issue, please try to run with mDNS switch off, i.e. keep it off all time. this is typically more stable setup.
can you also share how your mDNS entry looks like when openhab items are not accessible?
