Lights are set to red when DNS disappears

[mmmdwyer]

I've got a confusing issue, where sometimes all the lights that are currently ON turn red. It seems to be related to the network -- specifically DNS -- dropping.

I had originally thought that it was running a scene upon dropping and reconnecting from the hub, but I tried to disable that, and it is still happening.

DEFAULT_SCENE='hueload-random'

The only scene is 'default.scene', which looks like it might set things red, but to try to debug this issue before, I had tried inserting an 'exit' in default.scene before it does anything.

However, it still set the lights red when the DNS server rebooted.

[Josef-Friedrich]

In all honesty, I can’t believe it’s DNS related. Possibly a second app / service controls your bridge in the background? You have configured your bridge over an IP address in HUE shell?

[mmmdwyer]

Well, it just happened, the hue logs suggest it came from the hue-shell. This certainly seems to implicate hue-shell. However, I'm not seeing any network issues at this time, so I still don't know what the trigger is.

/var/log/hue-shell.log

Thu 10 Dec 2020 02:40:25 AM UTC [hueload-random] HTTP_REQUEST: PUT PATH: groups/0/action DATA: {"ct":369,"bri":254}
Thu 10 Dec 2020 02:40:25 AM UTC [hueload-random] huecolor-basic --red
Thu 10 Dec 2020 02:40:25 AM UTC [huecolor-basic] HTTP_REQUEST: PUT PATH: groups/0/action DATA: {"sat":255,"bri":255,"xy":[0.674,0.322]}

It appears that systemd may have tried to restart 'hue-load-default.service':

# systemctl status  hue-load-default
● hue-load-default.service - Hue-shell: load default scene
     Loaded: loaded (/lib/systemd/system/hue-load-default.service; enabled; vendor preset: enabled)
     Active: failed (Result: protocol) since Tue 2020-08-04 01:20:21 UTC; 4 months 6 days ago

Aug 04 01:20:21 viz systemd[1]: hue-load-default.service: Scheduled restart job, restart counter is at 5.
Aug 04 01:20:21 viz systemd[1]: Stopped Hue-shell: load default scene.
Aug 04 01:20:21 viz systemd[1]: hue-load-default.service: Start request repeated too quickly.
Aug 04 01:20:21 viz systemd[1]: hue-load-default.service: Failed with result 'protocol'.
Aug 04 01:20:21 viz systemd[1]: Failed to start Hue-shell: load default scene.

I don't know why it picked NOW to try to restart again. The good news is that it appears that I can disable the hue-load-default service and that will probably make this problem go away.

However, this seems to have uncovered a path issue:

journalctl:

Dec 10 02:39:25 hueservice-detect-bridge[3828508]: cat: /.config/hue-shell/hue-shell.pids: No such file or directory
Dec 10 02:39:25 hueservice-detect-bridge[743]: /usr/bin/hueservice-detect-bridge: 74: cannot create /.config/hue-shell/hue-shell.pids: Directory nonexistent
Dec 10 02:40:25 hueservice-detect-bridge[3828562]: cat: /.config/hue-shell/hue-shell.pids: No such file or directory
Dec 10 02:40:25 hueservice-detect-bridge[3828558]: /usr/bin/hueload-random: 74: cannot create /.config/hue-shell/hue-shell.pids: Directory nonexistent
Dec 10 02:40:25 hueservice-detect-bridge[3828580]: /usr/bin/hueload-random: 32: cannot open /.config/hue-shell/hue-shell-random-seed: No such file
Dec 10 02:40:25 hueservice-detect-bridge[3828579]: /usr/bin/hueload-random: 34: cannot create /.config/hue-shell/hue-shell-random-seed: Directory nonexistent
Dec 10 02:40:25 hueservice-detect-bridge[3828591]: cat: /.config/hue-shell/hue-shell.pids: No such file or directory
Dec 10 02:40:25  hueservice-detect-bridge[3828588]: /usr/bin/huecolor-basic: 74: cannot create /.config/hue-shell/hue-shell.pids: Directory nonexistent

The problem appears to be the expectation that $HOME will be set. But systemd is being typically obtuse about it.

/etc/hue-shell/hue-shell.conf has a definition for "DIR_CONF" but load-default doesn't use that:

echo $$ > "$HOME/.config/hue-shell/daemon.pid"

While we're there, DIR_RUN_PERM="$HOME/.config/$NAME" is a bit concerning, too. I think that should probably be in /var/run somewhere.

[Josef-Friedrich]

Thank you for your thorough investigation.
I just made a commit where I added this line in the Systemd unit files. Hopefully this solves this issue:

Environment=HOME=%h

I decided to use the home directory, so that you don’t have to run Hue-shell as root. Maybe that was not a good decision. PR are welcome.