I would go with child devices using standard commands and attributes. At least for commands and attributes that I want displayed on a dashboard or to track changes for (InfluxDB, Watchtower, etc.).
It's all right to use custom commands and attributes for non-critical or debug stuff, that can only be used/seen on the device details page.
I went with this approach in this driver for a ESP device that reports a ton of data: ems-esp-driver
Hope this helps.
Dan, thanks for the code link - that is very beautifully written and commented code, a real inspiration!
The hard part for me is going to be to learn what the standard commands and attributes are for a solar energy system (and ideally, for another project, also for a radon sensor). I need to look into Capabilities, I think, and I vaguely recall finding some documentation about them when I was trying to find a clean way to send radon measurements to Grafana via InfluxDB-Logger (and in that case, there just was no support at all for radon-related attributes, at least at that time, so I hacked something ugly).
Solar power is really taking off these days, so I hope I'll be able to determine what people are using as attributes to report production, consumption, and net use (import/export). Also, I have some devices that measure daily/weekly/annual use or production of electricity (Wh) in addition to point-in-time measurements (W), and those can be useful to report/graph as well.
With respect to the child driver (individual inverters, versus the parent driver that reported on the solar energy system as a whole), it doesn't really need to do anything much other than hold the attribute values. Theoretically we could ask to refesh the data for just one inverter, but that would be the cherry on top, and not really all that useful in practice. The parent can perform a single API call on the communications gateway to gather the data for all of the inverters in one shot. I gather that best practice is to use an existing "Hubitat generic" driver for the children in such cases, but I don't know whether one exists for this type of device.
More research!
Create a new virtual device, and in the dropdown for type search for "component". These are the builtin drivers you can use as children, the "generic" ones are a different matter.
Usually there is one builtin component driver for each Capability; if your child devices need to implement more than one Capability, you probably have to create your own.
Not so much in the US, with everything that is happening threre there days. But you are right, I believe Hubitat should offer more in this regard.
Download the Hubitat app
