I just updated my Home Assistant Core, and now the Enphase Envoy self-discovers as an Integration, with a message that I can remove it from my config.yaml.
That’s great! However, how can I now configure settings, such as the frequency of fetching, and exactly which elements I want to retrieve from the system?
Hi there,
Im faced with the same issue tht I updated to the latest core 2021.5.1 and then all my Enphase entities stopped working and like you now I see the Enphase has been discovered as an Integration. I got two integrations for some reasons. One was for the Inverters and the other for the other data.
But when I try to Configure the following prompt just rapidly flashes and does not connect to the envoy. I know this is the correct IP addres:
Does anyone know how to set up the new Enphase Envoy integration since moving to the laters HA Core?
What makes matters worse is that even I try to go back to an earlier FULL snapshot my system remains broken and no longer does the Enphase integrations work!
Thanx in Advance for any assistance.
EDIT: After commenting out the config.yaml for the original Enphase controller I now only have one Enphase Integration but still unable to connect to it:
First, I should say that the new Integration seems much more reliable. For me, the previous version used to stop collecting metrics after 1-2 days and I had to restart HA to get it working.
The Password is the last 6 digits of your Serial Number. You can view the Serial number by going to the IP address of the Envoy system – it will display an information screen with the data.
I updated my Lovelace elements to use the new Envoy names and it seems to be working quite well. I also found that I could edit the Integration and disable the Inverter metrics (which I don’t need). So, all-up it seems to be working well now.
Hi Fermax,
Thanx for the tip about the last 6 digits of the serial number as the password I had forgotten that from the original set up, but I still cant connect… is the username as per the default and “envoy”?
OK figured out something, not sure if it is a bug in the new integration. My Envoy was connected via WIFI (192.168.100.40) and the integration just refused to connect. Then I plugged in the LAN cable and restarted HA. Then the new integration was available but with different IP address for the LAN connection (still in the same IP range 192.168.100.125). So now it connected almost immediately, now going through all my automations and .yaml files as previously I had called my Enphase integration “hauxtonenvoy” and now the entities are all called “sensor.envoy_1220190xxxxxx_blah_blah” So now using the Envoy serial number within the entity naming… Hopefully there wont be any more chnges to how this integration defines entities in the future!
Great!
FYI, depending on your router, the Pi can be accessed using envoy.local as a DNS Name, which the router should resolve to the correct IP address.
I actually didn’t make this change, but thanks for the heads up. Things like this should not be changing, unless there’s a good reason. I was MIA for a while due to COVID and family issues, and the change from yaml to config UI was done at that time. It was something I was planning on doing but never had the time.
I know though for config UI (config-flow) to a unique ID has to be setup for each device.
So before I hit the Reply button, I actually looked into the Release Notes for HA 2021.5 and it appears to be noted in the Breaking Changes section.
I know it only mentions the Inverters, is the change also giving a unique ID to other entities as well, thus changing your automations?
Hi @gregtd
Sorry to hear that, I hope that everything worked out ok for you and your family.
I guess they have kind of double dipped on the “unique id” but as every entity for Enphase already had the serial number of the entity, for the inverters. So now we get the entity name as a long string including the EnvoyS controller id and also the inverters id…makes reading the entities difficult as the on screen portion that can be read is always the same for all inverters as it is the EnvoyS id.
Example: sensor.envoy_12201902xxxx_inverter_12194202xxxx
Other entities that previously did not have any id are now like:
sensor.envoy_12201902xxxx_current_energy_consumption which isn’t to bad.
As previously in the .yaml config, I had set my name as ‘qwerty’ then all my other config files used ‘sensor.qwertyenvoy…’ so arguable had a unique entity id.
But long story short, all good for me now, once I realised the changes required. But usual story…the release break changes only tell you it will break and never the solution. As I had set the original integration several months ago, I had forgotten about the last 6 digits of the serial had to be used as the password.
Regards Chris
I’m looking into the code and seeing about only letting the user initially enter in the IP address/hostname, and let the API test if the default username and password works. If so then no more info needed and the integration will be setup. If the default credentials fails a dialog will appear asking for a username and password. And if the user still does not have the credentials continue with the setup but will not gather inverter details.
Some users on the older Envoys don’t have access to the inverter data without going through an Android app to decrypt retrieve the installer password from the serial number.
I think this might be a better solution, as most users will only need an IP address to have the underlying API get all of the Envoy data including Inverter data.
I have most of the code done, I just need to clean it up and submit a PR but here are the screenshots for the change during setup:
Updated Hass to 2021.5.x, Envoy integration got autodiscovered. Now have sensors for all microinverters, whether I wanted them or not 
However the new integration is still marked as “Discovered” with a highlighted configure button.
I have a separate new “Envoy” card under integrations. It shows 27 entities, one for each microinverter, but doesn’t show any of the main entities such as production today.
So I haven’t explicitly enabled the new integration but yet it seems to be enabled.
It is great to see all of the progress that has been made on this, but I’ve got some questions:
It does look like I’ve got new consumption sensors that I never had before. (I don’t have consumption CTs so this is incorrect data that I don’t need to store.)
If one wants to disable the new integration, or some of the entities like consumption, how does that happen? Configuration via YAML is now marked as deprecated.
What’s the default scan interval for the inverter data and the other data?
If the envoy gets overloaded, how do I disable the inverter data collection? See the above comment about the current state of the integration cards. There is an Envoy card that covers the inverters, but nothing else. It’s not clear, if I disable that does it affect just the inverters, or all envoy sensors?
If I want to raise issues, I don’t think these are envoy_reader issues, so do they need to be raised against Home Assistant to be tied to the integration?
Note: I have the old manually configured envoy sensor. I don’t know how this changed the UX for the autodiscovery of the new/updated integration.
sensor envoy:
- platform: enphase_envoy
ip_address: envoy
scan_interval: 150
monitored_conditions:
- production
- daily_production
Hi @rct
You can disable entites through HA Configuration. From the Integrations page click on the like for the Enphase Envoy entities. This will filter the Entity list to only Enphase entities. Click on the entities you want to disable. In the screenshot I have the production entitiy but this is just an example of what the dialog looks like. Click on the Enable Entity slider to move it to the left and click on the Update buton. The entity will not become unavailable. Though the entity is unavailable, data is still retrieved via the API.
The SCAN_INTERVAL in the code is set to 60 seconds.
At this point there is no way to disable inverter data gathering. A workaround if you don’t want to collect or even retrieve the inverter data is to remove the Enphase Envoy integration from the Configuration page, and re-discover the Envoy. Though when prompted for the username and password put in some credential that will fail. The code then should not retrieve the inverter data.
There is someone working on code to only retrieve inverter data at a greater interval than 60 seconds to avoid over loading the Envoy. But that is still a work in progress.
An issue can be raised in Github against Home Assistant and specifying the Enphase Envoy integration. But if its a change in current behavior you can start here and maybe an issue would need to be opened against the envoy_reader API instead.
When I setup my connection with Envoy via the official integration, everything is working fine. But I’m missing the daily_production entity, unless I also add the configuration via YAML.
Any idea how to solve this and get the daily_production without the yaml configuration which is deprecated?
I am using the official integration without any YAML configuration residues and I automatically get an entity sensor.envoy_today_s_energy_production.
The first thing I would recommend is to look into the integration’s device overview which lists all entities that the integration has created. There may be cases where an entity is disabled by default and you have to manually enable it.
Thanks for the help! I now have 8 entities (4 production, 4 consumption) available with correct values without any setting in the configuration.yaml for envoy.
The only issue that remains is the entities for the micro-optimizers.
[
{
"serialNumber": "122107025358",
"lastReportDate": 1622905634,
"devType": 1,
"lastReportWatts": 24,
"maxReportWatts": 297
},
Any idea why the entities for the optimizers are not available in HA for me?
SOLVED!
Although I was able to login with my own credentials and get the 8 entities, I needed to login using envoy and the last six digits of the envoy serial number, to get the inverter entities also.
In case it helps anyone else, some advice from my struggle with cleaning up my Envoy entities due to the migration from the old YAML configured version to the new UI configured version.
If you have the old YAML configured version, remove it from your configuration before upgrading Home Assistant to 2021.5 or later. Hopefully this will avoid the entity duplication and related naming/renaming issues I encountered.
Also if you are feeding data from Home Assistant to something that persists it, like InfluxDB, you might want to do the upgrade and migration at night so any lost data won’t impact the accuracy of your numbers.
Notes:
The new version will be discovered, create entities, and be at least partially active before you “configure” it. As soon as I upgraded to 2021.5 I had new entities from the updated integration mixed in with the entities from the old version. At this stage I did not enable the new integration. So the new entities were not editable in the UI. (The UI said they didn’t have unique IDs so they couldn’t be edited.)
After I removed the old integration, restarted, and enabled the new integration, I wound up with 35 new entities (27 microinverters + 7 envoy entities) that contain the envoy serial number as an additional component of the entity names. This wasn’t present before. From what people have posted here, it doesn’t look like that is the default behavior.
I believe this was done to avoid conflict with the old entities from the previous integration and is arguably the correct behavior. It probably also enables you to have multiple envoy’s configured or is a step in that direction.
I wound up manually renaming both the entities and the names in order to connect the data from the old entities to the new ones for continuity. I could have left any new entities that I wasn’t previously storing alone, but the inconsistency would have driven me a bit crazy. Also I ran into a problem that renaming entities using the Home Assistant iOS app was silently failing. No idea why.
I’m happy to see all the progress with the Envoy integration. The path for new users will be much easier. I’m not sure whether the issues I saw related to the transition should be considered a bug, or just a poor UX for the case of migration.
FWIW, here’s my theory on what happened:
When I upgraded to 2021.5 was that the new code that expects the UI configuration was running, but my old YAML configuration was ignored so all of the entities available from the integration were enabled including inverters which I never had before. However, from the Hass UI the integration hadn’t really been enabled yet.
Once I deleted the YAML config and restarted, I configured the new integration. The integration configuration page showed I had two Envoy integrations. One had no devices, entities, or UI configuration controls. The second integration was “Envoy 1218NNNNNN” with 1 device and 35 entities. This is when I wound up with all the new entities which included the envoy serial number.
Your own credentials resulted in an failed authentication. Only the main entities are read.
Using the envoy or installer user will result in a successful authentication and will get you all the inverters.
Not all entities of the Envoy integration are listed in the filtered list on the integration page.
Check Dev tools en filter on envoy to see them all
One other thing i found not connected to your issue.
If you open the URL http://envoy/installer/pcu_comm_check with a browser or on command line with wget.
The data will become near realtime for about 2 minutes. instead of the default 5 or 15 minutes.
I guess I have to make a cronjob for this somewhere 
You will need installer authentication for this.
How to get that password is mentioned somewhere in this thread i presume.
Is anyone else having issues with Enphase after the Envoy-s gateway upgraded to D7.0.43 this last week?
I’ve had to raise an issue on GitHub as the integration is now broken for my system.
Bit shattered that Enphase appeared to have broken their own local API capability, because the Enphase integration was literally how I discovered Home Assistant in the first place and it’s always been a 100% rock solid integration…
I don’t think that Enphase ever planned this as a “local API”. At least I only discovered that my Envoy-S exposed all the data via REST when I looked at the built-in website. And that’s what then later was used in this integration.
Keeping an eye on this. Haven’t seen a firmware upgrade yet (Envoy IQ). I suppose it is too much to hope that it will stay the way it is.
Currently the most information about the change in local authentication seems to be in this GitHub issue against Hass Core (#51766) however the fix will likely be needed in Envoy Reader issue #78 not much info yet) and possibly the integration if some sort of OAUTH2 auth flow is needed.
(From the image posted with the issue against Hass Core it looks like the local authentication might be something token-based.)
