2 ?????? 2017??. 12:46:30 CET, "Petr Kub?nek" <petr at
kubanek.net> ?????:>Hi NUT developers,
>
>we rely on NUT to access valuable UPS data for our autonomous
>telescopes (see http://rts2.org for list, locations are not complete..)
>. Thanks for a software which does exactly what we need.
>
>Now we are starting new era, with installing telescopes on hostile
>spots without infrastructure. So we will have a solar cells, storing
>power to batteries during day, to be used during night to run the
>observatory.
>
>We bought Victron Energy solar system, including theirs invertor and
>battery monitor. Victron has its own tools, but the serial protocol is
>well documented and quite easy to understand.
>
>I would like to add NUT driver. But I will need to add new variables,
>showing state of different solar panels, connected to the controller.
>Can you suggest where to put those?
>
>Can you also discourage me if proving NUT driver for solar cells is a
>bad idea? I know how to write direct RTS2 drivers, but I believe using
>NUT layer will bring more benefits for the community.
>
>Thanks
>
>Petr Kub?nek
>http://rts2.org
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Sounds like a decent approach. IIRC either upstream/master or some WIP branches
already considered solar devices. Perhaps trawl open issues and/or branches...
I think that if the setup has one management controller and multiple panels to
track, you can use the common NUT approach of 'device.N.field = value'
to enumerate the panels (see e.g. support for multiple sockets of an EPDU, etc).
Usually N==0 is same as 'device.field' and serves to aggregate some
infomonitoring/management of the overall device (depends on what makes sense as
aggregation, sum, average, etc.).
Hope this helps as a starter,
Jim Klimov
--
Typos courtesy of K-9 Mail on my Samsung Android