-
Notifications
You must be signed in to change notification settings - Fork 5
Lights are set to red when DNS disappears #11
Comments
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? |
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
It appears that systemd may have tried to restart 'hue-load-default.service':
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:
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:
While we're there, |
Thank you for your thorough investigation.
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. |
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.
The text was updated successfully, but these errors were encountered: