Envoy S Production data is not read / read incorrectly when current transformers are not enabled/installed [bug]

[lnlp]

Problem

Envoy S Production data is not read when not using current transformers which renders reported Production data useless.

This is because envoy_reader assumes that when `envoy/production.json' exists that this is the location to read the Production data from. But that is an incorrect assumption because it is only valid when current transformers (CT) are enabled/installed.

Situation

I use Envoy S but without any CT's installed.
For a 3-phase installation I would need to buy 4 additional CT's while consumption and production data is already provided by my smart electricity meter (via DSMR P1 port). I therefore did not install any CT's.

When using Envoy S without having CT's enabled then production data in envoy/production.json is NOT updated.

Actual Production that gets updated is available via envoy/api/v1/production however.
But envoy_reader does not read it. It only reads envoy/production.json.
As a result the reported Production values are either 0 or some bogus value.
(I have observed bogus values for 'production' and 'consumption' in range between 0 and 2).

An Envoy S (and probably Envoy IQ) without CT's enabled should be handled as 'endpoint_type' "P" instead of 'endpoint_type' "PC".

Details about my Envoy:
Enphase Envoy S 'metered' Multiphase (probably identical to Envoy IQ).
Part number: 800-00554-r03,
Software Version: R4.10.35 (6ed292)
Electrical system: 3-phase 230V.

Solution

Handle Envoy S (and Envoy IQ) without CT's as 'endpoint_type' "P" instead of 'endpoint_type' "PC".

There are 2 options to implement this:

• Manual: Add an extra parameter e.g. ct_enabled with default value True (requires no changes in existing client code).
  When True the Envoy should be handled as endpoint_type "PC", when False as endpoint_type "P".

• Automatic: When CT's are not enabled this is shown on the envoy/home page so it should be possible to automatically scrape the status of whether CT's are enabled or not.

By default envoy_reader should automatically determine whether CT's are enabled and act accordingly.
By providing an optional ct_enabled parameter the user can override it for testing purposes.

This is what is shown on the envoy/home page when CT's are not enabled:

Let me know if you need more information or help.

[gtdiehl]

@lnlp Would it be possible for you to post a copy of your /production.json?

The code currently does a check to see if the attributes of production and consumption exist in the web page. I'm thinking maybe another check of the attribute eim. If these are zero than poll data from the other production page.

Also would need to check this behavior on newer firmware such as D5.0.49 (77afa8) to see what happens when metering is not setup and if the /production.json page returns valid data or not.

[rct]

Currently there are two problems:

1. Envoy reader makes an assumption depending on the type of Envoy whether CT metering is being used. CT metering can be turned off even on newer Envoys if the CTs aren't installed or are installed incorrectly. So far, I haven't seen a flag from the Envoy API that indicates whether it is using the inverter measurements or the CTs, but maybe I haven't looked deeply enough. It does show in the HTML output, but scraping should be avoided.

2. Envoy reader doesn't have the flexibility to allow the user to override envoy reader's assumption and specify which data items or sources you'd like to track in Home Assistant.

---

Current production Watts (wNow) from either inverters, CTs, or both

I believe there should be the option to get either or both production wNow values for the inverters and the eim (CT) structures. The inverters and the CTs don’t report the same values and Envoy reader can make an incorrect assumption about whether CT metering is being used. Ideally, the user should be able to specify and track either or both from Home Assistant.

I'm not sure what would be a good way to name production Watts data elements to allow referencing either or both of them in Home Assistant's configuration. Perhaps for compatibility there should be three available entities for the wNow values in Home Assistant:

• production - the current key that references the code's choice of wNow source
• production_inverters - a new key that references wNow for productiontype == inverters. (* This is production[0].wNow)
• production_eim - a new key that references wNow for production type == eim (* This is production[1].wNow)

Having these three elements would allow the user to override Envoy reader's choice if necessary as well as track both on systems with CTs if the user chooses that.

(*) Note: I don't know that production[0].type is always inverters and production[1].type is always eim.

---

Obtaining WH totals/accumulation:

From what I have seen on the Envoy IQ it only accumulates WH totals (today and 7 day) in the eim production structure of production.json WHEN CT metering is enabled.

When CT metering is off you have to look at /api/v1/production for the WH accumulation (today, 7 day) totals. This isn't currently accessible via Home Assistant, since at least for my configuration it is polling production.json and using the `eim`` structure which never change, which is the issue being reported here.

In other words, without CTs to use the Envoy's accumulation of WH Today and WH Past 7 days, you'd need to be able to get Envoy Reader to poll /api/v1/production.

An alternative to polling /api/v1/production is to use production.json type == inverter whLifeTime and compute the delta locally, either within envoy reader, or Home Assistant. This would allow access to finer grained energy production data for uses such as graphing 15 minute intervals.

@gtdiehl Here is my current production.json from my IQ D5.0.49 (77afa8) with CT metering turned off. /api/v1/production

{
  "production": [
    {
      "type": "inverters",
      "activeCount": 27,
      "readingTime": 1604240164,
      "wNow": 485,
      "whLifetime": 12877526
    },
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "production",
      "readingTime": 1604240284,
      "wNow": 543.128,
      "whLifetime": 26225.198,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 9500.168,
      "vahLifetime": 34969.369,
      "rmsCurrent": 6.616,
      "rmsVoltage": 251.275,
      "reactPwr": 571.381,
      "apprntPwr": 831.587,
      "pwrFactor": 0.65,
      "whToday": 32.198,
      "whLastSevenDays": 32.198,
      "vahToday": 41.369,
      "varhLeadToday": 0,
      "varhLagToday": 17.168
    }
  ],
  "consumption": [
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "total-consumption",
      "readingTime": 1604240284,
      "wNow": 543.128,
      "whLifetime": 26225.198,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 9500.168,
      "vahLifetime": 0,
      "rmsCurrent": 6.343,
      "rmsVoltage": 251.642,
      "reactPwr": -571.381,
      "apprntPwr": 1596.116,
      "pwrFactor": 0.34,
      "whToday": 26225.198,
      "whLastSevenDays": 26225.198,
      "vahToday": 0,
      "varhLeadToday": 0,
      "varhLagToday": 9500.168
    },
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "net-consumption",
      "readingTime": 1604240284,
      "wNow": -0,
      "whLifetime": 0,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 0,
      "vahLifetime": 0,
      "rmsCurrent": 0.273,
      "rmsVoltage": 252.009,
      "reactPwr": -0,
      "apprntPwr": 34.56,
      "pwrFactor": 0,
      "whToday": 0,
      "whLastSevenDays": 0,
      "vahToday": 0,
      "varhLeadToday": 0,
      "varhLagToday": 0
    }
  ],
  "storage": [
    {
      "type": "acb",
      "activeCount": 0,
      "readingTime": 0,
      "wNow": 0,
      "whNow": 0,
      "state": "idle"
    }
  ]
}

Here is my current http://envoy.local/api/v1/production

{
  "wattHoursToday": 867,
  "wattHoursSevenDays": 75431,
  "wattHoursLifetime": 12877300,
  "wattsNow": 529
}

[gtdiehl]

I have read through everything yet but I want to point out that when polling uses the /api/v1/production page the envoy appears to only update it every 15mins. Some may view this as a draw back. Like I said I haven't looked through all of the comments yet.

@rct If you have code changes could you post it to GitHub for a possible merge?

[rct]

@gtdiehl - I think the only cases where you'd want to use /api/v1/production are:

1. The envoy doesn't support production.json
2. The envoy is configured without CT metering and the user wants WH totals for today and 7 days which aren't available in production.json.

I don't have code changes that are worth submitting. I need to understand how the Home Assistant configuration interface interacts with envoy_reader to configure it.

[gtdiehl]

@rct Those are good points. 😃

I'll look through the code and see what it might take to implement. Or atleast get reporting working for all attributes for each hardware platform.

[lnlp]

@lnlp Would it be possible for you to post a copy of your /production.json?

I will make a capture tomorrow when it's light and the system is actualually producing.

I have read through everything yet but I want to point out that when polling uses the /api/v1/production page the envoy appears to only update it every 15mins. Some may view this as a draw back.

This is not my experience. I see information in /api/v1/procuction and /api/v1/production/inverters being updated every 5 minutes. Maybe this is Envoy-S Metered (Multiphase) and or firmware version dependent?
(Maybe you are mistaking with the cloud API's update frequency?)

My /api/v1/production/inverters inverter data is already properly read and output by envoy_reader (I can see the values in Home Assistant).
I currently check the /api/v1/production data in a browser and refresh manually.

Fyi: There exist 3 different Envoy-S models:

• Envoy-S Standard
• Envoy-S Metered
• Envoy-S Metered Multiphase which appears to be identical to IQ Envoy (except maybe for electrical differences)

I have the Envoy-S Metered Multiphase (EU) SKU: ENV-S-WM-230.

Envoy-S Metered and Envoy-S Metered Multiphase (IQ Envoy) are both black but the Envoy-S Metered Multiphase has the cover screw on the right side while the Envoy-S Metered has the cover screw on the left side (like Envoy-S Standard).

[lnlp]

@gtdiehl - I think the only cases where you'd want to use /api/v1/production are:

1. The envoy doesn't support production.json
2. The envoy is configured without CT metering and the user wants WH totals for today and 7 days which aren't available in production.json.

Regarding bullet 2: No, not only those two values.
In Home Assistant ('Enphase Envoy' add-in which uses envoy_reader) I do not get actual values for all 4 values shown in /api/v1/production.
Because envoy_reader appears to read them from /production.json where the names are present but their values are 0 and do not get updated.

When I run envoy_reader from a command prompt, the 4 production values shown are 0. When I modify envoy_reader.phy to explicitly set endpoint_type to "P" then the production values are read from /api/v1/production and are displayed properly.

[gtdiehl]

I'm still looking over the code and the different paths taken and the different types of envoy devices with and without features.

Though I wonder if something like this would solve the problem

Add a function called hasMeteringEnabled() which will return True if production[1]eim activeCount is >= 1 else False

Then change part of detect_model() from

envoy_reader/envoy_reader/envoy_reader.py

Lines 50 to 51 in c43704c

	if response.status_code == 200 and self.hasProductionAndConsumption(response.json()):
	self.endpoint_type = "PC"

To:

        if response.status_code == 200 and self.hasProductionAndConsumption(response.json()) and self.hasMeteringEnabled():
            self.endpoint_type = "PC"

So if the Envoy has Metering enabled values will be retrieved from /production.json and if Metering is not enabled values will be retrieved from /api/v1/production.

I just wonder is there a configuration of the Envoy where a production CT is installed without a consumption CT?
EDIT: I actually just found a setup like this. A CT is installed and Metering is only monitoring Production. According to the IQ Envoy manual this is possible if the user wants revenue-grade production metering.

[lnlp]

Here are captures of /api/v1/production, /production.json and /api/v1/production/inverters.
All were taken at the same time. Data coming from /api/v1/* is updated every 5 minutes.

/api/v1/production:

{
  "wattHoursToday": 1716,
  "wattHoursSevenDays": 53220,
  "wattHoursLifetime": 92854,
  "wattsNow": 2236
}

/production.json:

{
    "production": [
        {
            "type": "inverters",
            "activeCount": 15,
            "readingTime": 1604478431,
            "wNow": 2235,
            "whLifetime": 92854
        },
        {
            "type": "eim",
            "activeCount": 0,
            "measurementType": "production",
            "readingTime": 1604478474,
            "wNow": 2.599,
            "whLifetime": 0.0,
            "varhLeadLifetime": 0.0,
            "varhLagLifetime": 0.0,
            "vahLifetime": 0.0,
            "rmsCurrent": 0.534,
            "rmsVoltage": 245.583,
            "reactPwr": -0.0,
            "apprntPwr": 60.789,
            "pwrFactor": 0.01,
            "whToday": 0.0,
            "whLastSevenDays": 0.0,
            "vahToday": 0.0,
            "varhLeadToday": 0.0,
            "varhLagToday": 0.0
        }
    ],
    "consumption": [
        {
            "type": "eim",
            "activeCount": 0,
            "measurementType": "total-consumption",
            "readingTime": 1604478474,
            "wNow": -0.035,
            "whLifetime": 0.0,
            "varhLeadLifetime": 0.0,
            "varhLagLifetime": 0.0,
            "vahLifetime": 0.0,
            "rmsCurrent": 0.285,
            "rmsVoltage": 246.27,
            "reactPwr": 0.0,
            "apprntPwr": 70.082,
            "pwrFactor": -0.0,
            "whToday": 0.0,
            "whLastSevenDays": 0.0,
            "vahToday": 0.0,
            "varhLeadToday": 0.0,
            "varhLagToday": 0.0
        },
        {
            "type": "eim",
            "activeCount": 0,
            "measurementType": "net-consumption",
            "readingTime": 1604478474,
            "wNow": -2.634,
            "whLifetime": 0.0,
            "varhLeadLifetime": 0.0,
            "varhLagLifetime": 0.0,
            "vahLifetime": 0.0,
            "rmsCurrent": 0.249,
            "rmsVoltage": 246.958,
            "reactPwr": 0.0,
            "apprntPwr": 59.944,
            "pwrFactor": -0.12,
            "whToday": 0,
            "whLastSevenDays": 0,
            "vahToday": 0,
            "varhLeadToday": 0,
            "varhLagToday": 0
        }
    ],
    "storage": [
        {
            "type": "acb",
            "activeCount": 0,
            "readingTime": 0,
            "wNow": 0,
            "whNow": 0,
            "state": "idle"
        }
    ]
}

/api/v1/production/inverters (serial numbers have been obfuscated):

[
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478424,
      "devType": 1,
      "lastReportWatts": 151,
      "maxReportWatts": 244
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478408,
      "devType": 1,
      "lastReportWatts": 152,
      "maxReportWatts": 252
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478415,
      "devType": 1,
      "lastReportWatts": 148,
      "maxReportWatts": 246
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478420,
      "devType": 1,
      "lastReportWatts": 151,
      "maxReportWatts": 242
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478411,
      "devType": 1,
      "lastReportWatts": 149,
      "maxReportWatts": 247
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478416,
      "devType": 1,
      "lastReportWatts": 147,
      "maxReportWatts": 246
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478421,
      "devType": 1,
      "lastReportWatts": 151,
      "maxReportWatts": 244
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478428,
      "devType": 1,
      "lastReportWatts": 148,
      "maxReportWatts": 240
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478412,
      "devType": 1,
      "lastReportWatts": 151,
      "maxReportWatts": 250
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478416,
      "devType": 1,
      "lastReportWatts": 147,
      "maxReportWatts": 241
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478424,
      "devType": 1,
      "lastReportWatts": 147,
      "maxReportWatts": 244
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478407,
      "devType": 1,
      "lastReportWatts": 150,
      "maxReportWatts": 252
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478413,
      "devType": 1,
      "lastReportWatts": 146,
      "maxReportWatts": 245
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478420,
      "devType": 1,
      "lastReportWatts": 148,
      "maxReportWatts": 241
    },
    {
      "serialNumber": "12203xxxxxxx",
      "lastReportDate": 1604478426,
      "devType": 1,
      "lastReportWatts": 150,
      "maxReportWatts": 239
    }
  ]
  

Observations:

• /api/v1/production "wattsNow": 2236
  /production.json "type": "inverters", "wNow": 2235
  A difference of 1 Watt, which may be caused by a rounding error, or by a small difference in moments of measurement.

• /api/v1/production does not contain "readingTime" but /production.json "type": "inverters" does.
  This "readingTime" is probably accurate enough to be used as timestamp for data in /api/v1/production.

• /production.json: "type": "eim", "rmsCurrent": 0.534
  /production.json: "type": "eim", "rmsVoltage": 245.583
  The rmsVoltage may actually be measured by the Envoy, but without any CT's installed, the rmsCurrent value apparently is a bogus value(?)

Questions

• My solar installer connected only a single phase to power the Envoy, while all three phases L1, L2 and L3 can be connected.
  Apparently the Envoy uses this to measure the voltage on each phase.
  I wonder if all three phases are connected if this will automatically cause creation of three separate "eim" entries in /product.json, one for each phase and each reporting their own rmsVoltage.
  Does anyone have experience with this (all 3 phases connect to Envoy but without any CT's installed)?

[lnlp]

I'm still looking over the code and the different paths taken and the different types of envoy devices with and without features.

Though I wonder if something like this would solve the problem

Add a function called hasMeteringEnabled() which will return True if production[1]eim activeCount is >= 1 else False

Then change part of detect_model() from
...

That should probably do it.

Do you know what the "eim" stands for?
(I suspect something like: electrical induction metering)

[lnlp]

Also would need to check this behavior on newer firmware such as D5.0.49 (77afa8) to see what happens when metering is not setup and if the /production.json page returns valid data or not.

Is that new Envoy firmware?
Does that get installed automatically?

[lnlp]

I'm not sure what would be a good way to name production Watts data elements to allow referencing either or both of them in Home Assistant's configuration. Perhaps for compatibility there should be three available entities for the wNow values in Home Assistant:

• production - the current key that references the code's choice of wNow source
• production_inverters - a new key that references wNow for productiontype == inverters. (* This is production[0].wNow)
• production_eim - a new key that references wNow for production type == eim (* This is production[1].wNow)

Having these three elements would allow the user to override Envoy reader's choice if necessary as well as track both on systems with CTs if the user chooses that.

(*) Note: I don't know that production[0].type is always inverters and production[1].type is always eim.

What about 3-phase systems? Will there be / shouldn't there be 3 separate "eim" sections, each for one phase?
In that case, where is the total power reported in /production.json ? In the "inverters" section?

And when envoy_reader reads its data from the "eim" section shouldn't that be done for each phase separately and then summed to get totals for all 3 phases?

I'm a bit puzzled here because I have a 3-phase system with no CT's installed, and (only) a single "eim" production section shows up where a single rmsVoltage (and rmsCurrent) are specified while each phase has its own different voltage (which my smart electricity meter shows).

[gtdiehl]

I agree a better solution would be to have additional parameters.

Currently the envoy_reader api returns:

production
daily_production
seven_days_production
lifetime_production

consumption
daily_consumption
seven_days_consumption
lifetime_consumption

inverter_production

These come from mainly 3 pages (excluding Envoy running <3.9 firmware)

/api/v1/production
/production.json
/api/v1/production/inverters

I would propose removing the original consumption parameters and adding additional parameters (lets prepend them in this example with metered_*

metered_production
metered_daily_production
metered_seven_days_production
metered_lifetime_production

metered_consumption
metered_daily_consumption
metered_seven_days_consumption
metered_lifetime_consumption

Then change it so any polling of the original production parameters only come from /api/v1/production. And the metered_* parameters come from the appropriate section of /production.json that contains type of eim.

Currently to minimize api calls between the envoy and home assistant one function is called to gather up all the data (even if the device does not support the parameter) and send it across.

Then a question, does the api return the eim values that is got from the envoy even when the activeCount = 0? And possibly add another parameter called activeCTCount to tell the user if the Metering feature is enabled on their Envoy?

Going down this path means renaming 4 monitored_conditions and adding 4 or5 new ones will appear for each new Envoy sensor added to Home Assistant

I'm a bit puzzled here because I have a 3-phase system with no CT's installed, and (only) a single "eim" production section shows up where a single rmsVoltage (and rmsCurrent) are specified while each phase has its own different voltage (which my smart electricity meter shows).

I'm not sure on this one. According to the Envoy-S Metered Multiphase Installation manual there are 3 CTs installed on the Production and Consumption sides. Would have to find a system that has 3Phase with Metering enabled and CTs installed.

@jesserizzo What do you think about moving all of the production polling to /api/v1/production and only use /production.json for metered production and consumption data?

[lnlp]

@gtdiehl
I like the suggestion of using /api/v1/production by default and add the additional metered_* parameters for /production.json.

I would also prefer if the timestamp of when the values were updated can be added, e.g. lastReportDate and readTime (there's little consistency in the different names unfortunately).

For /api/v1/production the timestamp can be read from production.json "inverters" section.

And for the nice to have wishlist:
It would be nice if other useful parameters e.g. rmsCurrent and rmsVoltage could be reported by envoy_reader as well.

[rct]

@gtdiehl

• Good catch on production[1](eim).activeCount == 0 as the flag that CT metering is off.
• Re: using /api/v1/production by default - If I understand things correctly, when production CT metering is being used, I think everything you need is in production[1](eim). So polling /api/v1/production would be unnecessary overhead for those who have CT production metering. Given the limited resources of the envoy it would probably be best to avoid unnessary HTTP requests if possible. production.json if available has a lot more useful data items
• Correct me if I'm wrong, without CT metering /api/v1/production is only useful for wattHoursToday and wattHoursSevenDays because from production.json you can get production0.wNow and whLifeTime which are the same as /api/v1/production - wattHoursToday and wattHoursLifeTime.
  • However, with envoy_reader, production[0].whLifeTime isn't currently accessible because of the assumption that CT metering is always on. I think the changes to the detection code you are proposing would fix that.
  • Also, If state was kept and easily accessible in either envoy_reader (or Home Assistant), today's WH production and the last seven days of WH production could be determined from tracking the whLifeTime deltas. If I were storing this directly in a time series, I'd just track the whLifeTime counter.
• If CT metering isn't turned on, and the user wants to see the Envoy's inverter totals for today and the last seven days, then /api/v1/production needs to be polled. In envoy reader, can you tell what sensors the user has actually configured?

Question for you or anyone who has CT metering turned on:

• in production.json are both production[0].whLifeTime (inverters) and production[1].whLifeTime (eim/CTs) accumulating?

I believe production.json - production[0].wNow shows the current power from the inverters regardless of whether CT metering is turned on or not. Unless I'm wrong about that, it would be useful to be able to get wNow (production) for both, so hopefully your naming would also include inverters_production. If the answer to the above question is true, then it would also be useful to have inverter_lifetime_production in addition to metered_lifetime_production.

Thanks for working on this.

[rct]

@lnlp - trying to answer a few of your questions with what I've learned so far.

• Envoy firmware gets updated by Enphase automatically. My Envoy IQ is running D5.0.49 (77afa8) Build date Thu Mar 19, 2020 01:44 AM PDT. My envoy has been updated twice (or more) as far as I remember.
• production.json eim only shows an aggregated number. Regarding measurements for each phase, he Envoy has a URL that deliveries a stream of measurements - /stream/meter I haven't dug into it. IIRC you need to use the installer password to authenticate to access that URL. See https://thecomputerperson.wordpress.com/2016/08/03/enphase-envoy-s-data-scraping/#comment-5838 I think some of the software that people have put together for storing in a time series database with extensive graphing uses that data. The comment I linked to on the stream URL is also from a guy who has a 3 phase setup.
• EIM - Your guess on the meaning of the acronym is 'electrical induction metering' is possibly correct. I have assumed it was 'Voltage and Current Metering' using the ohm's law variables (P = EI), so EIM.
• See the comments above to @gtdiehl. In Home Assistant you actually should be able to get a whLifeTime value from production.json, the problem is that envoy_reader is using EIM instead of inverters. The readings you posted show identical values for whLifeTime and wattHoursLifetime across the two URLs.

[gtdiehl]

So I've hacked together some code

Here is the output of envoy_reader from various Envoys. I removed the inverter data and right now the values are zero due to no sunlight, but you should get an idea of what would be sent to Home Assistant once that sensor code is updated.

Envoy-S or IQ running D5.0.49 without Metering Enabled

Reading...
production:                                  0
daily_production:                            42499
seven_days_production:                       297600
lifetime_production:                         23543316
metered_production_activeCount:              0
metered_production:                          0
metered_daily_production:                    0
metered_seven_days_production:               0
metered_lifetime_production:                 0
metered_consunsumption_activeCount:          0
metered_consumption:                         0
metered_daily_consumption:                   0
metered_seven_days_consumption:              0
metered_lifetime_consumption:                0
inverters_production:                        {....}

Envoy-S or IQ running D5.0.49 with Metering Enabled

Reading...
production:                                  0
daily_production:                            33110
seven_days_production:                       215061
lifetime_production:                         41599751
metered_production_activeCount:              1
metered_production:                          0
metered_daily_production:                    33111
metered_seven_days_production:               215062
metered_lifetime_production:                 41599752
metered_consunsumption_activeCount:          1
metered_consumption:                         27
metered_daily_consumption:                   39608
metered_seven_days_consumption:              171145
metered_lifetime_consumption:                -140548
inverters_production:                        {...}

Envoy-S running D5.0.49 without Metering Enabled and the /production.json page does not contain Production or Consumption keys

Reading...
production:                                  0
daily_production:                            131036
seven_days_production:                       1641458
lifetime_production:                         424042360
metered_production_activeCount:              Metered Production data not available for your Envoy device.
metered_production:                          Metered Production data not available for your Envoy device.
metered_daily_production:                    Metered Production data not available for your Envoy device.
metered_seven_days_production:               Metered Production data not available for your Envoy device.
metered_lifetime_production:                 Metered Production data not available for your Envoy device.
metered_consunsumption_activeCount:          Metered Consumption data not available for your Envoy device.
metered_consumption:                         Metered Consumption data not available for your Envoy device.
metered_daily_consumption:                   Metered Consumption data not available for your Envoy device.
metered_seven_days_consumption:              Metered Consumption data not available for your Envoy device.
metered_lifetime_consumption:                Metered Consumption data not available for your Envoy device.
inverters_production:                        {...}

Envoy-C running D3.15.7

Reading...
production:                                  0
daily_production:                            10271
seven_days_production:                       73658
lifetime_production:                         18227440
metered_production_activeCount:              Metered Production data not available for your Envoy device.
metered_production:                          Metered Production data not available for your Envoy device.
metered_daily_production:                    Metered Production data not available for your Envoy device.
metered_seven_days_production:               Metered Production data not available for your Envoy device.
metered_lifetime_production:                 Metered Production data not available for your Envoy device.
metered_consunsumption_activeCount:          Metered Consumption data not available for your Envoy device.
metered_consumption:                         Metered Consumption data not available for your Envoy device.
metered_daily_consumption:                   Metered Consumption data not available for your Envoy device.
metered_seven_days_consumption:              Metered Consumption data not available for your Envoy device.
metered_lifetime_consumption:                Metered Consumption data not available for your Envoy device.
inverters_production:                        {...}

[gtdiehl]

The code is on one of my branches. I would like some input from @jesserizzo and others before opening a PR to merge this change.

Modified envoy_reader.py

[lnlp]

I would like some input from @jesserizzo and others

I tested your modified envoy_reader with my Envoy-S Metered Multiphase with metering disabled (no CT's).
It appears to work fine.

Observation: metered values get truncated instead of rounded.
Why not use actual values (with decimals, when reported)?

My Envoy reports tiny metered values while metering is disabled.
This is caused by my Envoy not by envoy_reader. Could this have been fixed in a later firmware revision?
Reported values while metering disabled:
metered_production wNow: 2.79 (gets truncated to 2)
metered_consumption wNow: 0.836 (gets truncated to 0).

My Envoy homepage shows "Software version R4.10.35 (6ed292)" is that the Envoy's firmware version?
Is D5.0.49 newer than R4.10.35? (latter number is lower but 'R' looks higher/newer than 'D')

Can you please add the following parameters for reading timestamps?:
production_readingtime (source: production.json production inverters readingTime)
metered_production_readingtime
metered_consumption_readingtime

[lnlp]

How about simplifying
"Metered Production data not available for your Envoy device." and
"Metered Production data not available for your Envoy device."

to: "not available"

[rct]

@gtdiehl - Here's my Envoy IQ (metering turned off) output using your change_polling_pages branch:

• I think it is working as you intended, but see my comments above
• Note: I've got production and consumption metering turned off (activeCount == 0). The code is currently returning values for those rather than your 'not available' message. Looks like you are checking for not set/zero vs. checking activeCount. My envoy has values for those rather than all zero, because metering was turned on a while but wasn't giving the right values. To me this isn't a problem right now, unless there winds up being some logic that depends on those being zero vs. not used.

production:                                  3032
daily_production:                            9615
seven_days_production:                       108838
lifetime_production:                         12948525
metered_production_activeCount:              0
metered_production:                          2323
metered_daily_production:                    32
metered_seven_days_production:               32
metered_lifetime_production:                 26225
metered_consunsumption_activeCount:          0
metered_consumption:                         2323
metered_daily_consumption:                   26225
metered_seven_days_consumption:              26225
metered_lifetime_consumption:                26225
inverters_production: <snip>

/api/v1/production

{
  "wattHoursToday": 9615,
  "wattHoursSevenDays": 108838,
  "wattHoursLifetime": 12948525,
  "wattsNow": 3032
}

production.json

{
  "production": [
    {
      "type": "inverters",
      "activeCount": 27,
      "readingTime": 1604594985,
      "wNow": 3033,
      "whLifetime": 12948525
    },
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "production",
      "readingTime": 1604595051,
      "wNow": 2334.435,
      "whLifetime": 26225.198,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 9500.168,
      "vahLifetime": 34969.369,
      "rmsCurrent": 19.475,
      "rmsVoltage": 252.92,
      "reactPwr": 618.904,
      "apprntPwr": 2460.099,
      "pwrFactor": 0.95,
      "whToday": 32.198,
      "whLastSevenDays": 32.198,
      "vahToday": 41.369,
      "varhLeadToday": 0,
      "varhLagToday": 17.168
    }
  ],
  "consumption": [
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "total-consumption",
      "readingTime": 1604595051,
      "wNow": 2334.435,
      "whLifetime": 26225.198,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 9500.168,
      "vahLifetime": 0,
      "rmsCurrent": 19.204,
      "rmsVoltage": 253.218,
      "reactPwr": -618.904,
      "apprntPwr": 4862.85,
      "pwrFactor": 0.48,
      "whToday": 26225.198,
      "whLastSevenDays": 26225.198,
      "vahToday": 0,
      "varhLeadToday": 0,
      "varhLagToday": 9500.168
    },
    {
      "type": "eim",
      "activeCount": 0,
      "measurementType": "net-consumption",
      "readingTime": 1604595051,
      "wNow": -0,
      "whLifetime": 0,
      "varhLeadLifetime": 0,
      "varhLagLifetime": 0,
      "vahLifetime": 0,
      "rmsCurrent": 0.27,
      "rmsVoltage": 253.516,
      "reactPwr": -0,
      "apprntPwr": 34.248,
      "pwrFactor": 0,
      "whToday": 0,
      "whLastSevenDays": 0,
      "vahToday": 0,
      "varhLeadToday": 0,
      "varhLagToday": 0
    }
  ],
  "storage": [
    {
      "type": "acb",
      "activeCount": 0,
      "readingTime": 0,
      "wNow": 0,
      "whNow": 0,
      "state": "idle"
    }
  ]
}

[gtdiehl]

Thank you for running the code!

I originally had the metered values not being returned when metering is disabled (activeCount == 0), but then I thought someone might want these values or some other reason. So I just display the values unless the device actually does not support metering.

They can always filter these values out in Home Assistant by specifying which monitored_conditions they want to see.

[rct]

Yes, I do want and think the values for both inverters and eim should be accessible if available. I just wanted to let you know the logic might not be working as intended.

In my comments above, I was arguing for the case to still be able to get the inverter numbers even if metering is enabled.

[gtdiehl]

I see where you are coming from but to keep the code simple I'm retrieving inverter production values from /api/v1/production rather than pulling a value from /production.json and the rest from /api/v1/production

It seems the the values are almost the same and they are both updated every 5mins. Other than reducing http calls to the envoy device, is there another benefit to pull the production data from the two pages rather than one?

[gtdiehl]

Observation: metered values get truncated instead of rounded.

Why not use actual values (with decimals, when reported)?

Good catch! I'll return values with a decimal

[rct]

Other than reducing http calls to the envoy device, is there another benefit to pull the production data from the two pages rather than one?

One case that is not handled, if you want the inverters current production and WH lifetime production, with metering turned on, you can only get that from production.json. In other words, if you explicitly want to access that data for the inverters whether or not metering is on, production[0] is the place to get it.

Maybe this is only of interest to me. When metering gets turned on /api/v1/production will switch over to metered values and will no longer have access to the history in the inverter data.

[gtdiehl]

One case that is not handled, if you want the inverters current production and WH lifetime production, with metering turned on, you can only get that from production.json. In other words, if you explicitly want to access that data for the inverters whether or not metering is on, production[0] is the place to get it.

Maybe this is only of interest to me. When metering gets turned on /api/v1/production will switch over to metered values and will no longer have access to the history in the inverter data.

@rct I get what you're saying. I'll have to look into this one a bit.

[gtdiehl]

I know this may seem like a back step but I'm thinking of changing back to the original output of the envoy_reader api, and have the code get the production values based on the activeCount attribute. The rationale is so that the Home Assistant sensor monitored_conditions does not have to change which ultimately does not create a breaking change or force users to change their environment.

Like I said I'm still thinking about it and weighing the pros and cons. I really like to give the user all of the data and let them figure out what they want to use. But have to think about current users.

[gtdiehl]

I have tested your latest envoy_reader.py.
This is the output:
@lnlp Thank you for running the code!

• I suggest to use the term 'CT Metering' (or 'CT Metering Enabled') instead of "Metering (CT) Status".
  'Status' also gives an impression that its value may change frequently which is not the case. In most cases this value will be fixed for the lifetime of the system.

This status was for me while debugging. It'll be removed from the code.

• Be aware that CT's can be installed for either Production, or Consumption, or both.
  envoy_reader should handle all these (4) situations correctly.
  So in practice it can be possible that only CT('s) for consumption are installed.
  This means that we need separate 'CT Metering' parameters for production and for consumption.
  I suggest to add the following two output parameters for this (so they can be read as sensor values in Home Assistant also);

  • ct_metering_production
  • ct_metering_consumption
    (add '_enabled' to these names if preferred)

Can you open a new issue (enhancement) to track adding new parameters?

• If ct_metering_consumption is false then the consumption values should be omitted from the output because it is meaningless to report values (and create sensors for them in Home Assistant) that are actually not present / not generated.
  Parameter ct_metering_consumption should allways be present in the output however and should not be omitted (for Envoys that output production.json).

I'm following the current convention that was previously coded. I would have to look into how to send specific data from the envoy_reader API to Home Assistant. Can you open a new issue (enhancement) to track this one?

• As previously requested please add the following output parameters:
  (for recent Envoy models that output production.json)

  • production_readingtime
  • consumption_readingtime (only when ct_metering_consumption is True)
    When ct_metering_production is False readingTime should be taken from the production/inverters section, when True from the production/eim section.

• In my situation (ct_metering_production is False) the production value is read correctly from the production/inverters section in production.json.

Can you open a new issue (enhancement) to track this one?

Questions

• When the production version of envoy_reader will be updated, will this get automatically updated in existing Home Assistant (Enphase Envoy add-in) installations?

No Home Assistant will not get fully updated automatically. That's why I'm asking to track the above as separate issues.

When I mean fully is that if something can be fixed on the Api side, such as the original bug of the Production values being zero than I can make a change here and request Home Assistant through a PR to update the version of the API being used. That's one line changed on the Home Assistant side and as long as the reviewer is okay with the API side change log the updated API will be included in the next Home Assistant release.

Now to change how things are displayed in Home Assistant, or adding/removing sensors that means probably both an API side code change as well as the sensor code change on the Home Assistant side. The review process is greater.

I know not a perfect solution but through small changes eventually we will get to a release that meets the needs of Envoy users across all firmwares 😃

So as it stands is your original bug of Production values displaying zero fixed?

[OllemGit]

@OllemGit

Exactly: I have only CT's installed for measuring Consumption...

"CT's" is plural but consumption/eim/activeCount only shows 1.
Is it correct that you have only one single CT for consumption?

That's an interesting question... I have a 3 phase power system, so I also have 3 CT's which each measure 1 fase, but in the Ephase app the value is shown as a single Power consumption parameter.

[lnlp]

Very interesting indeed. I would expect to see at least three different sets of values, one for each phase.

Could there there be another (URL) location on the Envoy where differentiated data for each phase is available?
Or maybe the Envoy combines the data of all three phases and the differentiation gets lost?

What use are values of e.g. rmsCurrent and rmsVoltage if only single instances reported for these instead of separately per phase?

[lnlp]

So as it stands is your original bug of Production values displaying zero fixed?

Yes the original bug in envoy_reader has been fixed.

I hope we can see it being updated in Home Assistant as well soon.

[lnlp]

@gtdiehl

• ct_metering_production
• ct_metering_consumption
  (add '_enabled' to these names if preferred)

Can you open a new issue (enhancement) to track adding new parameters?

Done, see #43.

• production_readingtime
• consumption_readingtime (only when ct_metering_consumption is True)
  When ct_metering_production is False readingTime should be taken from the production/inverters section, when True from the production/eim section.
• In my situation (ct_metering_production is False) the production value is read correctly from the production/inverters section in production.json.

Can you open a new issue (enhancement) to track this one?

Done, see #42.

[gtdiehl]

So as it stands is your original bug of Production values displaying zero fixed?

Yes the original bug in envoy_reader has been fixed.

I hope we can see it being updated in Home Assistant as well soon.

@lnlp I'll release the new version on pypi this weekend and open a PR on the Home Assistant side as well. Yeah hopefully it'll make it into the 0.119 release!

[gtdiehl]

@gtdiehl

• ct_metering_production
• ct_metering_consumption
  (add '_enabled' to these names if preferred)

Can you open a new issue (enhancement) to track adding new parameters?

Done, see #43.

• production_readingtime
• consumption_readingtime (only when ct_metering_consumption is True)
  When ct_metering_production is False readingTime should be taken from the production/inverters section, when True from the production/eim section.
• In my situation (ct_metering_production is False) the production value is read correctly from the production/inverters section in production.json.

Can you open a new issue (enhancement) to track this one?

Done, see #42.

Thank you for opening those issues. Maybe I should have been a little clearer but Home Assistant is not letting existing integrations to change their monitored_conditions. So to make changes unfortunately we can't add a new sensor and display the new data. I added some more detail in the Issue #41.

[lnlp]

See my response in #41.

[gtdiehl]

Very interesting indeed. I would expect to see at least three different sets of values, one for each phase.

Could there there be another (URL) location on the Envoy where differentiated data for each phase is available?

Or maybe the Envoy combines the data of all three phases and the differentiation gets lost?

What use are values of e.g. rmsCurrent and rmsVoltage if only single instances reported for these instead of separately per phase?

There was a reply in the Home Assistant Community forum where a person took this screenshot.

Not sure what the actual url for the page is though.

Forum link

[lnlp]

Data from /stream/meter (updates every second) shows the data separately for each phase but unfortunately this requires installer permissions. The data from my Envoy (3-phase, no CT's) looks like this (pretty-printed):

data: {
    "production": {
        "ph-a": {
            "p": 2.69,
            "q": 0.913,
            "s": 58.822,
            "v": 235.022,
            "i": 0.25,
            "pf": 0.13,
            "f": 50.0
        },
        "ph-b": {
            "p": 0.212,
            "q": -0.0,
            "s": 0.714,
            "v": 3.764,
            "i": 0.191,
            "pf": 1.0,
            "f": 50.0
        },
        "ph-c": {
            "p": 0.071,
            "q": 0.0,
            "s": 0.35,
            "v": 3.657,
            "i": 0.097,
            "pf": 0.0,
            "f": 50.0
        }
    },
    "net-consumption": {
        "ph-a": {
            "p": -2.686,
            "q": 0.689,
            "s": 58.584,
            "v": 235.027,
            "i": 0.25,
            "pf": 0.0,
            "f": 50.0
        },
        "ph-b": {
            "p": 0.0,
            "q": 0.0,
            "s": -0.0,
            "v": 3.344,
            "i": -0.0,
            "pf": -1.0,
            "f": 50.0
        },
        "ph-c": {
            "p": -0.0,
            "q": -0.0,
            "s": 0.0,
            "v": 5.602,
            "i": 0.0,
            "pf": -1.0,
            "f": 50.0
        }
    },
    "total-consumption": {
        "ph-a": {
            "p": 0.004,
            "q": -0.224,
            "s": 0.048,
            "v": 235.024,
            "i": 0.0,
            "pf": 0.07,
            "f": 50.0
        },
        "ph-b": {
            "p": 0.212,
            "q": 0.0,
            "s": 0.68,
            "v": 3.554,
            "i": 0.191,
            "pf": 0.31,
            "f": 50.0
        },
        "ph-c": {
            "p": 0.071,
            "q": -0.0,
            "s": 0.448,
            "v": 4.629,
            "i": 0.097,
            "pf": 0.16,
            "f": 50.0
        }
    }
}

From @OllemGit's feedback:

That's an interesting question... I have a 3 phase power system, so I also have 3 CT's which each measure 1 fase, but in the Ephase app the value is shown as a single Power consumption parameter.

Based on above it appears that /production.json is not going to contain data for each phase separately (in 3-phase system). Hopefully that data can be read from elsewhere on the Envoy, without requiring installer permissions.

@OllemGit
Are all three phases wired to your Envoy power connector_(most-left connector on the Envoy)_?

[OllemGit]

Are all three phases wired to your Envoy power connector_(most-left connector on the Envoy)_?
=> 4 wires enter the most-left connector of the Envoy + 3x2 wires for the CT's
I did not check (yet) where the come from and/or lead to

[lnlp]

I did not check (yet) where the come from and/or lead to

Thanks for checking.

That can only mean that all 3 phases are connected, the 4 wires will be: N, L1, L2 and L3.

My guess is that data from /stream/meter on your envoy will report realistric (true) voltages for all three of data/production/ph-a/v, data/production/ph-b/v and data/production/ph-c/v.

@OllemGit Would it be possible for you to verify this?

---

My Envoy reports a realistic value for data/production/ph-a/v while no CT's are installed. So this voltage is apparently read from L1 on the 'power input' connector. (My solar installer did not connect L2 and L3 on the 'power input' connector so I am currently unable to verify for ph-b and ph-c.)

My Envoy also reports a realistic value for data/xxx-consumption/ph-a/v. It appears that this value is probably taken from the same L1 input, but its value differs few-thousand's of a volt. An explanation for the difference may be rounding errors or different time of measurement.

The CT (current transformers) are used for measuring current. Theoretically one of the two CT wires could also be used for measuring voltage. Whether this is actually implemented (case B') when CT's are installed or that only the power input lines (left connector) are used ('case A') for voltage measurement I'm not sure.
In 'case A' one may wonder why the phase voltages are reported separately for production, net-consumption and total-consumption. In 'case B' one may wonder why the 'power connector' on the left exists and allows to wire all 3 phases.

From the 'Envoy-S Metered Multiphase (ENV-S-WM-230) Installation and Operation Manual':

Use a Phase Coupler for a Multiphase Site
If you are installing in a multiphase application, the power line communication signal must be “coupled”
between the phases to allow the Envoy to communicate with all of the Enphase devices in the system.
Install a phase coupler on the load side of the over-current protection device.

A phase coupler for communication with the inverters is not built-in to the Envoy. From this perspective it is not required to connect all 3 phases to the power connector.

2. Provide a Power Connection
   The Envoy-S Metered Multiphase (ENV-S-WM-230) uses terminal blocks for power and metering
   connections. It does not include an AC power cord, and you must hard-wire it.

The manual is not clear about why all 3 phases should be connected to the 'power input' connector.
Connecting only a single phase to the 'power input' connector (instead of all 3) already makes the system work (but will cause some values to be reported incorrectly).

For just the powering of the Envoy a single phase would be sufficient. This does not require to connect all 3 phases to the power connector.

From above I derive the conclusion that the reason of the presence of all 3 phases on the 'power input' connector must be to measure the voltage of each phase (as there appears no other plausible reason for wiring all 3 phases on this connector).

[pedrocr]

Instead of /stream/meter has anyone tried /ivp/meters/readings? I've seen that referred online as being able to get the individual readings and maybe it doesn't require the installer password.

[rct]

Interesting, /ivp/meters gives some configuration/status information such as phaseCount and phaseMode that I haven't seen elsewhere:

[
    {
        "eid": 704643xxx,
        "state": "disabled",
        "measurementType": "production",
        "phaseMode": "split",
        "phaseCount": 2,
        "meteringStatus": "normal",
        "statusFlags": []
    },
    {
        "eid": 704643yyy,
        "state": "disabled",
        "measurementType": "net-consumption",
        "phaseMode": "split",
        "phaseCount": 2,
        "meteringStatus": "normal",
        "statusFlags": []
    }
]

http://envoy.local/ivp/meters/readings seems to be very useful. I does give a way of polling the detailed data from each CT for what looks to be all three phases, whether it is installed or not. At first I seemed to get a 404 for but maybe I didn't get the plurals right though http://envoy.local/ivp/meters/readings.

Here's my output. Note: my CTs are currently disabled. There isn't any identifying object info inside the two objects in the top-level list. So it looks like you need to join with /ivp/meters based on eid to know what you are looking at and whether it is enabled.

[
    {
        "eid": 704643xxx,
        "timestamp": 1606326399,
        "actEnergyDlvd": 26225.198,
        "actEnergyRcvd": 1745.899,
        "apparentEnergy": 34969.369,
        "reactEnergyLagg": 9500.168,
        "reactEnergyLead": 0.000,
        "instantaneousDemand": 4741.303,
        "activePower": 4741.303,
        "apparentPower": 4869.138,
        "reactivePower": 672.800,
        "pwrFactor": 0.975,
        "voltage": 252.728,
        "current": 38.569,
        "freq": 60.000,
        "channels": [
            {
                "eid": 1778385yyy,
                "timestamp": 1606326399,
                "actEnergyDlvd": 13116.878,
                "actEnergyRcvd": 872.078,
                "apparentEnergy": 17522.510,
                "reactEnergyLagg": 4758.520,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": 2376.200,
                "activePower": 2376.200,
                "apparentPower": 2439.620,
                "reactivePower": 337.502,
                "pwrFactor": 0.976,
                "voltage": 126.641,
                "current": 19.280,
                "freq": 60.000
            },
            {
                "eid": 1778385170,
                "timestamp": 1606326399,
                "actEnergyDlvd": 13108.320,
                "actEnergyRcvd": 873.821,
                "apparentEnergy": 17446.859,
                "reactEnergyLagg": 4741.648,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": 2365.104,
                "activePower": 2365.104,
                "apparentPower": 2429.518,
                "reactivePower": 335.298,
                "pwrFactor": 0.973,
                "voltage": 126.087,
                "current": 19.289,
                "freq": 60.000
            },
            {
                "eid": 1778385171,
                "timestamp": 1606326399,
                "actEnergyDlvd": 0.000,
                "actEnergyRcvd": 0.000,
                "apparentEnergy": 0.000,
                "reactEnergyLagg": 0.000,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": 0.000,
                "activePower": 0.000,
                "apparentPower": 0.000,
                "reactivePower": 0.000,
                "pwrFactor": 0.000,
                "voltage": 0.000,
                "current": 0.000,
                "freq": 60.000
            }
        ]
    },
    {
        "eid": 704643584,
        "timestamp": 1606326399,
        "actEnergyDlvd": 0.000,
        "actEnergyRcvd": 0.000,
        "apparentEnergy": 0.000,
        "reactEnergyLagg": 0.000,
        "reactEnergyLead": 0.000,
        "instantaneousDemand": -0.000,
        "activePower": -0.000,
        "apparentPower": 34.637,
        "reactivePower": 0.703,
        "pwrFactor": 0.000,
        "voltage": 253.326,
        "current": 0.274,
        "freq": 60.000,
        "channels": [
            {
                "eid": 1778385425,
                "timestamp": 1606326399,
                "actEnergyDlvd": 0.000,
                "actEnergyRcvd": 0.000,
                "apparentEnergy": 0.000,
                "reactEnergyLagg": 0.000,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": 0.000,
                "activePower": 0.000,
                "apparentPower": 16.618,
                "reactivePower": -0.000,
                "pwrFactor": 0.000,
                "voltage": 126.916,
                "current": 0.130,
                "freq": 60.000
            },
            {
                "eid": 1778385426,
                "timestamp": 1606326399,
                "actEnergyDlvd": 0.000,
                "actEnergyRcvd": 0.000,
                "apparentEnergy": 0.000,
                "reactEnergyLagg": 0.000,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": -0.000,
                "activePower": -0.000,
                "apparentPower": 18.019,
                "reactivePower": 0.703,
                "pwrFactor": 0.000,
                "voltage": 126.410,
                "current": 0.144,
                "freq": 60.000
            },
            {
                "eid": 1778385427,
                "timestamp": 1606326399,
                "actEnergyDlvd": 0.000,
                "actEnergyRcvd": 0.000,
                "apparentEnergy": 0.000,
                "reactEnergyLagg": 0.000,
                "reactEnergyLead": 0.000,
                "instantaneousDemand": 0.000,
                "activePower": 0.000,
                "apparentPower": 0.000,
                "reactivePower": 0.000,
                "pwrFactor": 0.000,
                "voltage": 0.000,
                "current": 0.000,
                "freq": 60.000
            }
        ]
    }
]

I see now that there was mention of these URLs in the Envoy-S data scraping blog that I missed previously

[pedrocr]

@rct the scraping blog was where I got that URL. Can you confirm that you can get this without any authentication? If so this may end up being the best solution, although it requires 2 requests.

[lnlp]

Can you confirm that you can get this without any authentication?

I just tested it in Windows Sandbox: No authentication required for both url's.

[pedrocr]

Seems like this is the winner for #46

[lnlp]

I discovered that /production.json can also provide per-phase values.

See following comment in #46 for more information.

[gtdiehl]

Well sorry to say but there was a bug in the code. It causes Home Assistant to not update after a couple of polls. I have made the change to fix it, actually just removed a single line of code, PR #51. Now I have to get this included in a bugfix-release for Home Assistant as 2020.12.0 includes the envoy_reader with the bug. I'm sorry about this!

[lnlp]

Too bad, but no need to feel sorry. 🙂
Thanks for your continuing efforts!

I was happy to see it working in 2020.12.0 now but then noticed values reported in HA don't match /api/v1/production.
Your message explains this.

Do you expect to get the fix into the next (bug-fix) release (presumably 2020.12.1)?

Mmm, just wondering: will a HA 2020.12.1 bug-fix release automatically become 2021.01.0 if released in January 2021?

[gtdiehl]

@lnlp Thanks! 😃 The fix was merged into the dev branch yesterday, which usually means it will make it into the next release (2021.01.0). Though this time I had someone add my PR to the list of PRs that should be included in 2020.12.1. Cross your fingers, and I'm hoping it will be included in 2020.12.1.

[lnlp]

I upgraded to HA 2020.12.1 today and the /api/v1/production counters now appear to report properly in HA.
(Envoy-S metered multi-phase (EU) with no CT's installed.)

[Matthew1471]

Do you know what the "eim" stands for? (I suspect something like: electrical induction metering)

Envoy Integrated Meter