MickMake / GoSungrow

GoLang implementation to access the iSolarCloud API updated by SunGrow inverters.
https://mickmake.com/
GNU General Public License v2.0
148 stars 42 forks source link

Fetch Schedule Interval #86

Open khkissel opened 9 months ago

khkissel commented 9 months ago

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?

steikohein commented 2 weeks ago

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?

Paraphraser commented 2 weeks ago

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.