HomeKit Integration: Losing Config After Changing an Item

I’m having some trouble with my HomeKit integration through the regular binding. I’m usually at the point where everything’s working nicely.

However, when I change an item that I tagged for the use with HomeKit, the Home app on my devices loses all of the items. The only items still available are the openHAB bridge and my Apple TV. After restarting openHAB, all items will re-appear, but not in the rooms I associated them with before. They’ll just appear in the same room as the openHAB bridge. At this point, the change I made before is effective.

Anyone else seeing this?

For reference: I’m using openHAB 2.3 and my HomeKit.items looks like this:

Group gHomeKit
    "Alle HomeKit Items"

// Lampen

Dimmer hkEingangsbereichHelligkeit
    "Trådfri Eingang" 
    (gHomeKit)
    ["Lighting"] 
    { channel="hue:0220:1:5:brightness" }

Dimmer hkPapierlampeLinus 
    "Papierlampe Linus" 
    (gHomeKit)
    ["Lighting"] 
    { channel="hue:0100:1:3:brightness" }

Dimmer hkStehlampeSchlafzimmer 
    "Stehlampe Schlafzimmer" 
    (gHomeKit)
    ["Lighting"] 
    { channel="hue:0100:1:4:brightness" }

Color hkWohnzimmerCouchlampeFarbe 
    "Couchlampe Farbe" 
    (gHomeKit)
    ["Lighting"] 
    { channel="hue:0210:1:2:color" }

Color hkWohnzimmerLivingColors 
    "Living Colors Farbe" 
    (gHomeKit)
    ["Lighting"] 
    { channel="hue:0200:1:1:color" }

// Steckdosen

Switch hkOsramSteckdose
    "Schreibtischlampe"
    (gHomeKit)
    ["Switchable"]
    { channel="hue:0010:1:6:switch" }

// Wetter

Number hkWetterYahoo_Temperatur 
    "Außentemperatur [%.1f °C]" 
    (gHomeKit)
    ["CurrentTemperature"] 
    { channel="yahooweather:weather:paulushofen:temperature" }

Number hkWetterYahoo_Luftfeuchtigkeit
    "Luftfeuchtigkeit [%.0f%%]" 
    (gHomeKit)
    ["CurrentHumidity"] 
    { channel="yahooweather:weather:paulushofen:humidity" }

I’ve seen the same thing happen since today. Additionally, it seems that for colored lamps, homekit is not able to set the saturation but only the color.

I have the same problem, does anyone have a solution?

Last weekend I added a few more lamps and – funnily enough – this time it did work as expected and not screw up my Home integration. I don’t know what I did differently this time, though.

Same problem here.

Does anybody have the same? Is there a workarround? :cry:

I gave up with the homekit binding as the reliability was just awful. I replaced it with a simple nodejs bridge - took a couple of hours to work it out, but has been 100% reliable ever since.

See More reliable Homekit alternative using a simple nodejs bridge

I don’t know how many times I’ve already redone my entire homekit setup because OH just goes wild
Since OH 2.3 it behaves like described above and just goes nuts every time any items file involved with anything HomeKit gets touched.

I was actually thinking of replacing OpenHAB altogether since there doesn’t seem to be any interest in improving these fairly fundamental areas.
Thanks for sharing this, let’s see if maybe this will solve some of my headaches

@pnuding (and all) - we’ve had some recent discussion on this. The reasoning in this thread (HomeKit losing config) is why I dumped OH HomeKit and went for NodeRed.

The link from Dan is about nodejs - in my opinion NodeRed is probably going to be easier to work with.

Check it out:

1 Like

Yeah, the nodejs certainly took a bit of fiddling, but I think my instructions linked above are pretty foolproof. Haven’t had to redo the HomeKit settings once since I got it going (and I too was getting very bored of this before).

Either approach should work just great depending on what people want to do and what people are comfortable with.

I’m reading over your nodejs approach right now and there are probably more things you can do with this - for instance you could more easily add battery levels to your HomeKit items.

Are your items individual or bridged? I like the nodered bridge option because you can add/remove devices in nodered as you like and they’ll show up right away without adding a new accessory. Nodered was super easy for me to pick up - the GUI worked for me.

Essentially both approaches use the same underlying nodejs - I’ll leave it up to everyone to decide which to use.

1 Like

I’m using the bridged route.

My impression is that nodered looks much easier if you already have MQTT setup, but perhaps not if you don’t. But it’s great people have choices. Just a shame the openHAB implementation is so flaky.

Agree 100%.

The connection between nodered and openhab is actually handled through the RESTful API if I understand correctly. Add the nodes for openhab and homekit - and go.

No MQTT necessary.

It appears your setup is sending commands to OpenHAB over HTTP GET requests? Through the classicui? That could probably be switched over to RESTful API codes … and I just read further down in that thread seeing that someone else said the exact same thing. While I have your attention - do you have any link about doing the HTTP commands through the classicui? I was looking for that a while ago and found nothing.

Seems like about 95% the exact same underlying code - one programmed directly in NodeJS and the other through the nodered interface.

1 Like

well then nodered is probably much easier to set up.

Yes, I use the HTTP GET request because I am too stupid/lazy to use the proper way. The HTTP GET/classicui route is deprecated and will presumably break at some point, and then I’ll be forced to do it properly.

I think the documentation has now been pulled, but the basic format is:

wget "http://[url]:[port]/classicui/CMD?[item]=[state]" -P /tmp

There was also a way to query the state, but I can’t remember what it was, and can’t find it anywhere…

Fixed it for you.

I believe I was trying to get the classicui working so I could send a GET command from a very simple device where I couldn’t compose a PUT command. I got the CMD working as you’ve described but then I wanted to send a postUpdate type command - which I couldn’t figure out. It’s a moot point as I eventually gave up and figured out some other workaround…

I’ve now finally made the switch over from the Homekit binding to Node-RED.
Was it clunky and annoying? Yes.

Is it working better? Hell yes. Besides finally being able to correctly represent valves, shutters, smoke alarms and sensors, it’s also much faster and doesn’t have hiccups when a scene updates many items at once.

I still think it’s sad that OpenHAB has such inadequate native support for Homekit, but this crutch does the trick beautifully.

I would suggest to everyone who want to use HomeKit to give a try for Node-RED and it’s HomeKit implementation. For me, since I moved to Node-RED, HomeKit doesn’t really have any problem, the connection is much better and stable.
Moving to Node-RED takes some time, you have to learn how it works (not so hard - very intuitive) but if you have not too much items which will be exposed to HomeKit, it should take more than a few hours. Plus you can do it simultaneously. You don’t have to delete your openHab HomeKit, just install Node-RED and it’s HomeKit and connect it to your phone as a ‘second’ home. You can test it out and gradually add things to it and if you feel it is good enough, you can delete the original HomeKit binding in openHab - and the Home from your phone.

@rkrisi @pnuding
I agree with you at 1000%

unfortunately this is the reality for some years

Frankly, setting up Homekit through Node-RED was fiddly and annoying and it took me a while before I had all the details working the way I wanted.
But I’ve never looked back. It’s stable as a rock, faster and finally has all the flexibility I was missing. And it seems OH itself is also more stable now that I’ve removed Homekit and also moved from the ever so unreliable Zigbee binding to Zigbee2MQTT.
Maybe I’ll eventually have the Homekit setup talk directly to MQTT so Openhab becomes optional