Docker container doesn't create config.json in mounted folder

[cawith]

Hi,

Since the last Docker version, where the config.json moved to /opt/kelvin/config.json, the config.json isn't created in my mounted folder on the Synology NAS.
Kelvin is running and adjusts the lights according to the standard values, but I can't find and edit the JSON file. This was no issue with the previous release.

Thanks for the great app!

[stefanwichmann]

Hi cawith,

thanks for reporting this issue.

Sadly volume management in docker can become tricky but we will find a solution for you. I see two ways to get through this.

1. You enable the web interface as described in the README.
2. We solve your problem by mounting the files to the correct place.

I highly suggest to take the first approach because it will be much easier than the second one. The second approach also might need some additional adjustments on Kelvin's side...

I assume you goal is to edit the configuration to your needs as easy as possible. In case of a container based deployment (like docker) you should use the web interface for this. Right now this isn't enabled by default (because it's not really pretty right now, lacks some features and I don't want to open ports on peoples computers without proper thought!) so we will have to enable it manually.

To enable the web interface we have to edit the config.json inside the container. To do this, you can follow these steps on your Synology:

1. Start a container on your Synology (as you already did) without any volumes but with port 8080 mapped.
2. Log into your Synology via SSH (see https://www.synology.com/en-global/knowledgebase/DSM/help/DSM/AdminCenter/system_terminal for instructions)
3. Log into your running Kelvin container (see README)
4. Start an editor via vi /opt/kelvin/config.json and in the section webinterfacechange the line enabled: false into enabled: true. Safe the changes and exit (:wq in vi).
5. Restart the running container via the Synology web interface or inside your SSH shell by running docker restart $CONTAINER_ID (see README for details)
6. You should now be able to access the web interface of Kelvin on http://$SYNOLOGY_IP:8080/. Here you can easily adjust the configuration to your needs.

These instructions should get you going.

For the sake of completeness the needed steps for the volume solution. Volumes in docker are not really suited to get existing files or folder out of a container. The core of the problem is described here:

https://docs.docker.com/storage/bind-mounts/#mounting-into-a-non-empty-directory-on-the-container

So the only chance to get around this would be to separate the configuration and Kelvin's binary again, as it was the case before the current release. In this case Kelvin's would have to able to load the configuration from any external folder which it can't do right now. Currently is looks for the config inside the working directory. You could get around this using file system links, but this gets even more complicated...

Hope this helps!?! Let me know if you got Kelvin working!

[cawith]

Hi Stefan,

Thanks for your quick answer.
I actually just solved it a bit easier just an hour before you posted this. I downloaded and ran the Windows version on my computer, which then created a config.json with the correct bridge IP and username/ID. Just edited this file with webinterface enabled before copying to the NAS and then mounting this file as stated in the readme.

Kelvin now works and the webinterface also works as expected.
I do have a few questions that I can't find any answers for anywhere:

1. How quick are the adjustments in brightness and temperature, when one of the times in the schedule are reached, and will it start adjusting up to the defined times or after the time has been passed?

2. What happens after midnight? Does the last setting from the "after sunset" schedule stick until the first before sunset?

3. If I have defined an action for a time, which with spring and summer coming shortly, someday will move into the "Daylight" time period, will I just be ignored until daylight time shortens again, or will it be applied at exactly sunset time?

I have another suggestion for a variable. Instead of only having schedules reacting to exact times, maybe it would be possible to add a "relative to sunset/sunrise" variable.
For example, I want lights to slowly turn dimmer a certain amount of hours after sunset. Of course I can define this by certain times as well, but with daylight times changing so much this time of year, I'd have to modify the config.json every week or so.
Maybe it would be possible to implement it so that "relative to sunset/sunrise" has priority over "precise time" schedule.

Example:
Let's say sunset is at 19:00
Schedule says light shall set brightness to 50% at 19:30
However "relative to sunset" variable is that 1 hour after sunset brightness shall be reduced to 75%. This then makes the system ignored all schedules between sunset and the last "relative to sunset" variables, which in this case is at 20:00. Does this make sense?

[stefanwichmann]

Hi cawith,

first of all I glad you got it working. In the meantime I went for a long run, thought about this issue and came to the conclusion that both solutions (and yours as well) are way to complicated! This should be considered a bug! So let's change that first...

[stefanwichmann]

Now to your questions:

1. Kelvin will always reach the wanted color temperature and brightness at the configured timestamp. In between these timestamps it will shift both values linearly every minute.
   Example: Daylight ends at 20:00 with 2750K and 100% brightness, and you have configured a custom timestamp at 21:00 with 2300K and 80% brightness. Kelvin will now shift the color and brightness between 20:00 to 21:00 every minute. This also means that shorter intervals have a faster transition.

2. Every day at midnight the schedule for the next day will be calculated. The interval between midnight and the first timestamp (custom or sunrise) will use the settings of this timestamp. Same goes for the interval between the last timestamp of a day and 23:59:59.

3. If you have a custom setting that falls into the daytime interval at certain times of the year, it will be ignored.

Regarding your proposal: This has been broad up before in other issues. I created issue #27 to discuss and evaluate this and the future direction of Kelvin. If you are interested please feel free to comment and ask there regarding relative timestamps. (Spoiler alert: Relative timestamps come with there own issues...)

Hope this helps. Feel free to ask if you have any more questions... now I will have to fix this bug! ;-)

[stefanwichmann]

Ok, fixed with release v1.1.4

[cawith]

Thank you very much for clarifying.
I found another issue, but will report it as a new issue. :)