Fetch Schedule Interval
I'm running GoSungrow without HA. When I'm starting via ./GoSungrow mqtt run goSungrow responds with
2023/09/14 14:58:28 INFO: Starting ticker...
2023/09/14 14:58:28 INFO: Fetch Schedule: 5m
2023/09/14 14:58:28 INFO: Sleep Delay: 40s
Even ./GoSungrow mqtt sync is responding a 5min interval:
2023/09/14 14:55:59 INFO: Created job schedule using '*/5 * * * *
I'd like to change the interval to e.g. 60m or more. Is there a command or flag to change it?
Hi, I have similar request, just in the other direction. I would like to reduce the fetch interval to something rather small like 10s. I see the fetch interval is configurable from 2m to 10m, but what if I want the interval smaller? Any possibility?
Caveat: most of this is guesswork - not fact.
I don’t believe that what you want to do is possible with the HA add-on. Although some crontab examples are scattered about in the repo, I think they legacy items that aren’t being used.
Here’s my reasoning:
-
Open a shell into the container:
# docker exec -it addon_ba22da74_gosungrow bash # -
How many crontabs are defined in the container:
# cd /var/spool/cron/crontabs # ls root -
What is in root’s crontab?
# crontab -l # do daily/weekly/monthly maintenance # min hour day month weekday command */15 * * * * run-parts /etc/periodic/15min 0 * * * * run-parts /etc/periodic/hourly 0 2 * * * run-parts /etc/periodic/daily 0 3 * * 6 run-parts /etc/periodic/weekly 0 5 1 * * run-parts /etc/periodic/monthlyAll the subdirectories in
/etc/periodicare empty so nothing there triggers anything to do with GoSungrow. I’ll leave you to double-check that for yourself.I also added a
*/1(“every minute”) job to the list and I don’t think the cron daemon is even running inside the container. -
So, what is running inside the container?
# ps -a PID USER TIME COMMAND 1 root 0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service 14 root 0:00 {rc.init} /bin/sh -e /run/s6/basedir/scripts/rc.init top /usr/local/bin/run.sh 15 root 0:00 s6-supervise s6-linux-init-shutdownd 17 root 0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -c /run/s6/basedir -g 3000 -C -B 24 root 0:00 s6-supervise s6rc-oneshot-runner 25 root 0:00 s6-supervise s6rc-fdholder 33 root 0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 78 root 0:00 bash /usr/bin/bashio /usr/local/bin/run.sh 115 root 4:24 /usr/local/bin/GoSungrow mqtt run 124 root 0:00 bash 135 root 0:00 ps -aIt looks to me like the meat is process ID 115 and that it’s likely self-timed (ie, internal, with no dependence on cron).
-
In some of the Dockerfiles, there are things like this:
CMD [“/usr/local/bin/GoSungrow”, “cron”, “run”, “00”, “07”, “.”, “.”, “.”, “sync”, “default”] ``` That *implies* there’s a `cron` sub-command which can be used (rather than the `mqtt` sub-command at process ID 115 above). However, if you try to run:GoSungrow cron
ERROR: Unknown command string: [cron]
Rolling all that together, I’d say that an earlier version of GoSungrow did indeed rely on cron but that got yanked when the container was set up to use s6.
Now, if I wanted to run GoSungrow on a shorter or longer interval, I’d first look to see if either the GoSungrow mqtt run (self-timed) or GoSungrow mqtt sync (one-shot) commands could take the necessary arguments. I don’t think they can but it’s possible that I’ve missed something in the help text so you should confirm that for yourself.
Next, I wouldn’t run GoSungrow as a Docker container (either as the Home Assistant add-on or via docker run or docker-compose). I’d use the standalone binary and then set up a cron job to invoke GoSungrow mqtt sync at the desired interval.
Why? Because the container seems to be set up with the specific goal of running GoSungrow mqtt run and making it do something else probably isn’t going to be all that simple. You’ll either need to launch it with docker run or docker-compose so you can pass it a different CMD and either of those implies “outside Home Assistant”. Plus, there’s a whole bunch of nonsense (process ID 78 above) which munges the configuration info just to get it to GoSungrow. It looks to me like that’s all a workaround for sourcing config information from Home Assistant whereas, if you just use the standalone binary, you can set up everything with GoSungrow config write and it all sits in ~/.GoSungrow/config.json where you can pretty much forget about it.
I hope something in all this winds up helping you to achieve what you want.