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.
I am running a new Enphase system with the IQ Combiner 6C. I have been trying to get my Hubitat to talk with the Envoy system locally for while now, but does not appear to be capturing the tokens. The driver I am using is notated as written by Supun Vidana Pathiranage v1.0.0. (I believe the one posted by augoisms). Some of the latest interations discussed in this thread do not appear to be available anymore. Any tips on making this connection.
Hey Bryan,
Welcome to the Hubitat community.
This is a driver I developed. Thanks for trying it. I can see your token has been generated correctly in the logs, so if you're not seeing the production and consumption data, it should be another issue.
Please try the latest version first (v0.0.7):
https://raw.githubusercontent.com/vpsupun/hubitat/refs/heads/master/EnvoyLocalData/EnvoyLocalData.groovy
If you're using HPM, this driver now available on HPM as well.
IMPORTANT: When you're sharing debug logs, pay attention to what's in them. In your case, we can see the auth token. Next time, mask the sensitive contents. Try to rotate/remove this token from the Enphase portal. DM me if you need any help with that.
Why don’t the values for the local API match the Enphase app? They are always wildly different.
Since Friday July 3rd I have had errors and not getting local data. Anyone else having issues? I have rebooted the controller twice and I confirmed the local IP address is correct. The Enphase app is working fine. Cloud data is reporting.
dev:9542026-07-09 9:26:54.939 amwarnUnable to get a valid token. Aborting...
dev:9542026-07-09 9:26:54.938 amwarnGenerated token is not valid. Investigate with debug logs
dev:9542026-07-09 9:26:54.937 amwarnHTTP post failed: status code: 403, reason phrase: Forbidden
dev:9542026-07-09 9:26:52.376 amwarnHTTP get failed: status code: 401, reason phrase: Unauthorized
When I try to go directly to the IP address I first get a popup saying “Sorry, you are not authorized to view that page.” but I think I have seen that before. I then go to login and can see my local system.
Is there something wrong with their token system? @dJOS
I have a Fronius Inverter so can’t really help with this one.
I just checked and getting corrected data.
But I can help debugging the issue.
Will you be able to enable debugging logs and refresh the token and see if there any errors?
You can force refresh the token by re login.
When you share the logs in this forum, redact the token value before sharing.
I had a forked version from a while ago and once I updated to the latest release, I am back to working. Thanks for offering to help.
If you're able, it would be a good idea to update the URL in the initial post from this thread, as it points to a dead link. BTW, thanks for this driver, I've been using (my hacked version of) it for a year, feeding the results to InfluxDB, and enjoying my Grafana graphs. But...
A few days ago some of my graphs flatlined. After some investigation, I found that my Envoy is now running a firmware build dated June 23 2026, almost certainly since a pair of reboots on July 29, which I suspect correspond to an over-the-air-update from Enphase. I queried the Envoy manually, and discovered that it is now feeding me garbage data on /api/v1/energy, where numbers remain unchanged over time, hence the flatlined graphs. This remained true even after I cold-booted the unit; it seems to me that some of the APIs got broken in the recent firmware update; is anyone else seeing this? This is an Envoy IQ with software "D8.3.5433", release version "02.00.1785".02.00.1785.
The unit itself is feeding correct data to the mother ship, as evidenced by correct-looking graphs when I consult the Enphase Enlighten web site. If I query the unit using /production.json, I still get some nonsense data (for production, whToday, whLifetime, and whLastSevenDays are identical to each other, and the same is true for total-consumption), but wNow values change over time, so they may be okay. I'm not sure if any of the aggregate data are correct in any of the API endpoints, but for my purposes I use only the point-in-time data, so if I can modify the driver to use an API endpoint that shows correct data, I'll be back in business. (Also, some time ago I hacked on data collection per-panel, and that still worked fine, which clued me in to the type of problem I was seeing.)
Anyway, I wonder if anyone else is seeing this (likely) firmware bug on the Envoy IQ, and if so, whether you're planning to re-code for it, or whether I should just proceed at this end...
I'm continuing to look into this (Claude.AI is helping). In this posting, a Home Assistant user quotes a reply he got from Enphase concerning which API endpoints are recommended:
Enphase core integration , problem with local api accuracy · Issue #162302 · home-assistant/core · GitHub
That was last February; I have not yet tested whether that info is still valid.
Well, that was a month ago, and no responses. In view of the threads in the Home Assistant forum, this is a real bug on the Envoy, and I would expect everyone using this driver to see their data collection frozen at old values.
Meanwhile, I now have code which restores the point-in-time data, but not the "today" nor "past 7 days" data. Is anyone out there using "today" and "past 7 days"? Note: my code now optionally collects per-inverter data as well, though it requires a small "child" driver to be installed to accomplish this.
The question is: is anyone out there?
I'm here. I pm'd @vpsupun several weeks ago on a change request regarding seeing the values in kW instead of Watts. I'm not sure if he's been on the forums in a while.
I have this on my dashboard and look at a few times each day, and I have not seen any issues with frozen data, but I could very well just not see it.
If your production and consumption data are changing, then you don't have the problem. Do you know what the firmware revision is on your Envoy gateway? My aggregate data (production, consumption) stopped getting updated as of an automatic firmware update to D8.3.5433; the build is dated last June, but I got the update in late July.
My Envoy gateway is D8.3.5167
So that's earlier than my D8.3.5433; I imagine you'll see the data problem once you get the update, if indeed you get automatic updates.
