GoSungrow icon indicating copy to clipboard operation
GoSungrow copied to clipboard

Fetch Schedule Interval

Open khkissel opened this issue 2 years ago • 2 comments

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?

khkissel avatar Sep 14 '23 13:09 khkissel

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?

steikohein avatar Jun 15 '24 14:06 steikohein

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:

  1. Open a shell into the container:

    # docker exec -it addon_ba22da74_gosungrow bash
    #
    
  2. How many crontabs are defined in the container:

    # cd /var/spool/cron/crontabs
    # ls
    root
    
  3. 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/monthly
    

    All the subdirectories in /etc/periodic are 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.

  4. 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 -a
    

    It looks to me like the meat is process ID 115 and that it’s likely self-timed (ie, internal, with no dependence on cron).

  5. 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.

Paraphraser avatar Jun 17 '24 14:06 Paraphraser