Lights return to default homekit room on restart

[tinglis1]

Lights return to default homekit room on restart

[jbroadice]

My workaround for this issue was to set a 1min timer in the systemd service config so that homebridge doesn't start before HA / ZWave.

The issue consistently occurs otherwise for any devices that aren't immediately available when homebridge boots.

[jbroadice]

@timsamuelsson Hey. Sure. 👍

In /etc/systemd/system, I have the service named homebridge.service:

[Unit]
Description=Node.js HomeKit Server 
After=syslog.target network-online.target

[Service]
Type=simple
User=homebridge
EnvironmentFile=/etc/default/homebridge
# Adapt this to your specific setup (could be /usr/bin/homebridge)
# See comments below for more information
ExecStart=/usr/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Then, the timer named homebridge.timer:

[Unit]
Description=Runs Homebridge after 2 minutes

[Timer]
OnBootSec=2min
Unit=homebridge.service

[Install]
WantedBy=multi-user.target

Then it's a matter of disabling the original service using sudo systemctl disable homebridge, and subsequently enabling using sudo systemctl enable homebridge.timer.

Hope this works for you!

[schmittx]

I have a similar issue if I don't start/shutdown HASS and Homebridge in the correct order. Homebridge will lose the accessory information and when they're discovered again, they appear in default room and as a favorite (using iOS Home app).

@robbiet480 Is it possible to specify this type of info in HASS customize like we do with "homebridge_name" currently? Image would be something like "homebridge_room" (string), "homebridge_favorite" (true or false), or "homebridge_switch_type" (fan, light, or switch).

[timcv]

Thanks alot! Worked like a charm!

[theseal]

I also have the same problem - my hue devices disappears from HomeKit while restarting Home-assistant and then appear but in wrong room. It would be great if the homebridge plugin could hold on to found devices even when homeassistant doesn't think it have them configured. Just for a while - like a grace period.

In the mean while I made a systemd ExecStartPre command which will hold on the start of home bridge until one of my Hues are found.
The script:

#!/usr/bin/env bash
while true; do
    statusCode=$(curl --silent --output /dev/stderr --write-out "%{http_code}" -X GET -H "x-ha-access: $1" -H "Content-Type: application/json" localhost:$2/api/states/$3)
    if [ ${statusCode} -ne 200 ];then
        sleep 5
    else
        break
    fi
done

And configuration to the systemd service:

ExecStartPre=/home/home-assistant/checkDevice <your-top-secret-password> <the-port-you-run-hass-on> <your-missing-device>

[technicalpickles]

How are you configuring your hue lights in HA, with the discovery component? Can you try explicitly configuring it, like on https://home-assistant.io/components/light.hue/ ?

[tinglis1]

That seems to have solved my issue.
I guess it must be when the homebridge starts without the devices causing homekit to forget them and then when they reappear homekit thinks they are new devices.

It would still be good to find a more system orientated way of beating this problem. I was able to solve my issue by statically assigning them but this may not always be an option.

Do you know if having a serial number on the homekit device might help with keeping the item?

[technicalpickles]

I guess it must be when the homebridge starts without the devices causing homekit to forget them and then when they reappear homekit thinks they are new devices.

I'm pretty sure devices are fetched a single time. If you startup homebridge before the things are discovered, new devices found wouldn't be added.

Do you know if having a serial number on the homekit device might help with keeping the item?

It looks like they do have serial numbers, but they are all xxx: https://github.com/home-assistant/homebridge-homeassistant/search?utf8=%E2%9C%93&q=serial

[tinglis1]

I saw the 'xxx' serial number in iOS 10 as it is displayed along side the manufacturer (HA) and model (light etc) on the device details page, that's why I wondered if it may be a bit more important.
I thought that maybe if the HomeKit devices had a unique serial number such as the entity_id that HomeKit may be less forgetful.

[tinglis1]

I created a fork and added the entity_id to the serial number. It did not stop the defaulting of devices to the default room.
https://github.com/tinglis1/homebridge-homeassistant/tree/entity_serial_numbers

The entities passed though correctly (see the image below). I tested it by connecting homebridge with all the light correctly showing in the correct rooms, then physically powering of the lights (lifx and hue) then restarting HA and homebridge. Once confirmed they were not showing in homebridge I powered them back on and restarted HA and homebridge. The usual defaulting of the room occurred.

@technicalpickles I can do a pull request for the entity_id serial number if you would like, although it doesn't seem to help this issue.

[tinglis1]

Just in case someone else wants to try the branch in a docker like I have below are the steps:

• I am using cbrandlehner/homebridge-docker container.
• To add additional packages to this docker use the following code in the packages.json

 {  "scripts": {
    "install": "npm install -g https://github.com/tinglis1/homebridge-homeassistant.git#entity_serial_numbers"
  }
}

That is instead of the usual
npm install -g homebridge-homeassistant

This process worked for me and is handing for any future development I try to undertake.

[tinglis1]

I think I am going to have to create a solution in Home Assistant to try and keep the lights from dropping off. I have one LIFX light that is regularly turned on and off at the switch. If HA is restarted when it is off then it disappears and if homebridge is started the light is removed.

At the moment I see two ways to work around the problem but they are both LIFX component fixes.

• Ability to create persistant lights rather than just discovery
• discover lights after HA has started.

I will take this issue back to the forum for discussion.

[tinglis1]

On the other topic raised of serial numbers.
I am willing to raise a PR with the change to use entity_id as serial numbers if there are no objections.

It is a really simple fix of changing
.setCharacteristic(Characteristic.SerialNumber, "xxx");
to
.setCharacteristic(Characteristic.SerialNumber, this.entity_id);

Otherwise this issue appears to be a HA discovery/startup order issue or apple forgetfulness issue.

[robbiet480]

@tinglis1 Done in #63

[robbiet480]

Wondering if the actual fix was #54 since SerialNumber informs the UUID...

[robbiet480]

Is this still an issue when using the latest version? (Hasn't been released to npm yet so you need to do npm install -g home-assistant/homebridge-homeassistant to install it).

[tinglis1]

I have just started testing with the new version and will get back to you with the results.

[landerss0n]

Im having this exact issue right now, what's the status on this?

[davispw]

Still a problem for me with 2.0.1 and with npm install -g home-assistant/homebridge-homeassistant as of a2e20f9.

Noting that this seems to affect multiple types of devices, not just lights, and multiple customizations (e.g. accessory name hat I edit with the Elgato Eve app on my iPad) not just the Room. This is affecting all my Z-Wave devices in HomeAssistant (many!) as well as Ecobee thermostats.

[davispw]

If I shut down homebridge while restarting HomeAssistant, it fortunately avoids the issue. But that's risky -- I had to remove homebridge from auto-startup just so it doesn't start while HomeAssistant is still starting!

This bug also destroys any rules/automations that use the reset devices so this is quite a serious data loss issue!

[dcrypt3d]

I've been experiencing this same issue. I can mitigate it slightly by using pm2 and a shell script automation to make sure that homebridge shutdowns before homeassistant and starts after homeassistant but that doesn't always work and I have a handful of z-wave locks, lights, switches and sensors that always go back to Default Room.

[Emptyless]

Isn't there something like this possible for homebridge-homeassistant: https://www.npmjs.com/package/homebridge-openhab

You can set customAttrs to define in the homebridge config where to place the accessories.

[tinglis1]

Not sure if it is that easy.
homebridge/homebridge#874
There is the same issues for other homebridge plugins as well.

[shokk]

Am still seeing this. Needs a way to make previous accessories remembered so it doesn't lose the info for existing homebridge items. This is actually regardless of that I have set in home-assistant.

[timcv]

@JChapple Could you post som code for that?

[shokk]

Is it only dependent on service startup or is there an order for service shutdown as well?

[jbroadice]

@shokk As long as home-assistant stays alive, restarting homebridge seems to be fine.

[johnboiles]

The timer method works pretty well for me, but every so often something goes wrong with my zwave setup (e.g. my zwave usb dongle changes from /dev/ttyACM0 to /dev/ttyACM1 or my zwave component breaks because of some sort of update). It's rare but a huge bummer when it happens.

I wonder if it'd be possible, at least for Hass.io, for the Hass.io Supervisor to watch for a certain set of Home Assistant components to load before launching the HomeBridge addon. For my use case, it would wait until the zwave component is loaded before HomeBridge was launched. That way, there'd be the minimum necessary amount of time before HomeBridge loads, and HomeBridge wouldn't try to launch (and reset all my accessories) if something is wrong with the zwave component.

[mynameisdaniel32]

I would also love to see something like schmittx has posted above implemented (if it's possible), managing this manually is becoming very tedious.

Ideally I would have devices permanently declared in the HomeKit world, that way, as they are discovered in Home Assistant they would become 'available' and HomeKit data/assignments and the little things like the order in my favourites page, would never be lost. Unfortunately it isn't possible to manually declare everything in Home Assistant (i.e. LIFX lights).

I will add a timer to delay the startup on boot up which should help to some extent but some devices (such as LIFX lights) take a while to be discovered so I don't think this will be a perfect solution and this is a pain I go through with every reboot/outage of my system.

[schmittx]

FYI, It's not possible within HomeKit to specify the room for each device.