[Solved] MSR doesn't like January?
-
I've been trying to track down what is causing this Date/Time issue. I'm getting closer and figured I would post something to start the topic/hunt. I wrote a rule based on my kids school schedule. The ultimate concept was to turn the lights on and whatnot based on if they had school or not, and if the school day was a late start or regular start schedule. It took me a few times and tweaks to get what I think is accurate and going to work. Along the way I noticed that sometimes a defined month would revert back to (every month) instead of the month I had defined. I think this has something to do with going into next year, but like I said, I'm still trying to get a RCA. What it appears like in my screenshots is that I only see the issues for some, not all, months that have Jan (1) defined.
In my images below, the overview shows all the Jan months and in the next image down shows (every month) where a Jan should be. But not ALL the Jan's were reverted. And I have seen this on a Dec every once in a while too.
-
Yes, I see this. Will be fixed for a latest build later today.
-
Awesome. Thank you.
What are your thoughts on making your docker images available based on versions? I/E: Adding a few more tags. Right now you have Generic-1.0 and Latest. I would like to switch to the latest to get the build later today, but I may want to not get the next few releases. Just curious if that is an option. -
You can just not install (pull) them?
-
I'll be honest, I'm not a docker expert. To my knowledge my Docker (running on unRAID) uses the tags to pull down the image. My repository is defined as: "toggledbits/reactor:1.0.0-generic-amd64". I don't believe I can define it as: "toggledbits/reactor:latest:21219" to only pull down that build, unless there was a label/tag that you define to point at that image.
-
Once the container is built, it will use the image it was built from, unless you pull a newer image and build a new container from it. The assumption is that the container is modifying its copy of the image, so any changes it may make, one would want those to be available across restarts of the container going forward.
Pulling a new image for an upgrade requires you to delete the existing container and (correctly) reapply all the original settings on the new container (like bind mounts). Many prefer to use
docker-compose
, where those settings are encapsulated into a JSON file and the container built from them when directed. But you can also just keep a copy of the necessary command line(s) as a script. I do this with Home Assistant. When I'm made aware of an update, I run my script that stops my Hass docker container, removes it, pulls the current latest build, then starts the new container, building from the new image. Applied to MSR, that might look like this:#!/bin/sh docker pull toggledbits/reactor:latest-generic-amd64 docker stop reactor docker rm reactor docker run --init -d \ --name reactor \ --restart=unless-stopped \ -e "TZ=America/New_York" \ -v /home/patrick/Documents/reactor:/var/reactor \ -v /etc/localtime:/etc/localtime:ro \ toggledbits/reactor:latest-generic-amd64
Note: if your current container name is not
reactor
, you will need to stop and remove the container yourself the first time. After that, the script specifies that the container be namedreactor
.I will probably introduce a stable branch at some point as well.
-
Yeah. That's the same process that the unRAID docker does, just with a GUI front end. Pull, Stop, Remove, Run, and then it deletes the previous image. I'll just have to get over my OCD when I see the message "apply update" and only update if I want/need to. Until you create that stable branch.
-
OK. Build 21221 is up with the rule editor fix for date/time January.
-
@toggledbits said in MSR doesn't like January?:
OK. Build 21221 is up with the rule editor fix for date/time January.
Thank you. I can confirm that the (every month) no longer appears when I edit the rule.
-
1/9