PowermeterType 11 not supported - S10X - "11 is not a valid PowermeterType"

[mkkri]

System Health details

System Information

version	core-2025.11.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.13.9
os_name	Linux
os_version	6.12.51-haos
arch	x86_64
timezone	Europe/Berlin
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4994
Installed Version	2.0.5
Stage	running
Available Repositories	2456
Downloaded Repositories	2

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 16.3
update_channel	stable
supervisor_version	supervisor-2025.11.5
agent_version	1.7.2
docker_version	28.3.3
disk_total	30.8 GB
disk_used	6.5 GB
nameservers	172.21.3.254, 8.8.8.8
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization	kvm
board	ova
supervisor_api	ok
version_api	ok
installed_addons	Advanced SSH & Web Terminal (22.0.3), Studio Code Server (6.0.1), Get HACS (1.3.1)

Dashboards

dashboards	2
resources	0
views	0
mode	storage

Network Configuration

adapters	lo (disabled), enp6s18 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth4161286 (disabled), veth7894243 (disabled), veth2ac3704 (disabled), vetha7acc7b (disabled), veth7018ef2 (disabled), veth88f45d3 (disabled), veth0ab551f (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp6s18 (172.21.0.200/22), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth4161286 (), veth7894243 (), veth2ac3704 (), vetha7acc7b (), veth7018ef2 (), veth88f45d3 (), veth0ab551f ()
ipv6_addresses	lo (::1/128), enp6s18 (fe80::269:dfdf:8f7d:5661/64), hassio (fd0c:ac1e:2100::1/48, fe80::8030:b2ff:fe06:d0cd/64), docker0 (fe80::a87a:dfff:fe11:d4ed/64), veth4161286 (fe80::10ca:18ff:fea2:edfb/64), veth7894243 (fe80::e00a:a0ff:febf:bbb6/64), veth2ac3704 (fe80::141d:73ff:fe5e:706b/64), vetha7acc7b (fe80::6c14:1bff:fef4:a982/64), veth7018ef2 (fe80::d813:1aff:fe20:342/64), veth88f45d3 (fe80::e0a3:9aff:fea8:fdbf/64), veth0ab551f (fe80::6c17:a1ff:feb3:9bc1/64)
announce_addresses	172.21.0.200, fe80::269:dfdf:8f7d:5661

Recorder

oldest_recorder_run	17. November 2025 um 09:10
current_recorder_run	28. November 2025 um 14:27
estimated_db_size	8.44 MiB
database_engine	sqlite
database_version	3.49.2

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of currently previous issues..

Describe the issue

Setup:

• E3DC S10X
• Home Assistant Version: (deine Version eintragen)
• Integration: E3DC Remote Storage Control Protocol (Git) v3.10.0

Problem:
Die Integration lässt sich mit korrekten Zugangsdaten und RSCP-Passwort hinzufügen.
Danach erscheint dauerhaft:

"Einrichtungsfehler, wird erneut versucht: Configuration not yet ready: Fatal error when talking to E3DC"

Im Log steht wiederholt:

2025-11-28 14:56:47.495 DEBUG (SyncWorker_3) [custom_components.e3dc_rscp.e3dc_proxy] Fatal error when talking to E3DC: 11 is not a valid PowermeterType
File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 29, in wrapper_handle_e3dc_ex
File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 156, in get_powermeters
return self.e3dc.get_powermeters(keepAlive=True)
File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 2108, in get_powermeters
File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py", line 3803, in getStrPowermeterType

Username, Passwort und RSCP Password sind korrekt (falsche Daten führen sofort zu "connection failed").
Die S10X ist im gleichen Subnetz wie Home Assistant.

Vermutung:
Mein System liefert einen PowermeterType mit ID 11, der in python-e3dc / _rscpTags.py noch nicht definiert ist.

Wenn gewünscht, kann ich einen Diagnostics-Dump der Integration aus Home Assistant anhängen.

Reproduction steps

1. Install the "E3DC Remote Storage Control Protocol (Git)" integration via HACS.
2. Restart Home Assistant.
3. Add the integration:
   • Hostname:
   • Username: my E3DC portal user (same e-mail as on the S10X standard user)
   • Password: my E3DC portal password
   • RSCP Password: the RSCP password configured on the S10X (in my case: 123456)
4. The integration is added successfully (wrong credentials immediately lead to "connection failed").
5. After that, Home Assistant shows:
   "Configuration not yet ready: Fatal error when talking to E3DC"
6. In the debug logs the following error is repeated:
   "Fatal error when talking to E3DC: 11 is not a valid PowermeterType"

The S10X Device is brend new

Debug logs

2025-11-28 14:56:47.495 DEBUG (SyncWorker_3) [custom_components.e3dc_rscp.e3dc_proxy] Fatal error when talking to E3DC: 11 is not a valid PowermeterType
  File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 29, in wrapper_handle_e3dc_ex
  File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 156, in get_powermeters
    return self.e3dc.get_powermeters(keepAlive=True)
  File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 2108, in get_powermeters
  File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py", line 3803, in getStrPowermeterType

2025-11-28 15:04:17.894 DEBUG (SyncWorker_2) [custom_components.e3dc_rscp.e3dc_proxy] Fatal error when talking to E3DC: 11 is not a valid PowermeterType
  File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 29, in wrapper_handle_e3dc_ex
  File "/config/custom_components/e3dc_rscp/e3dc_proxy.py", line 156, in get_powermeters
    return self.e3dc.get_powermeters(keepAlive=True)
  File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 2108, in get_powermeters
  File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py", line 3803, in getStrPowermeterType

Diagnostics dump

No response

[bullitt186]

I looked at https://github.com/fsantini/python-e3dc (the python lib used to talk to the e3dc) and can confirm, pm type 11 is not defined (yet). Also the iobroker integration https://github.com/git-kick/ioBroker.e3dc-rscp which is sometimes a little bit ahead does not know about this type yet.
So i assume either E3DC has changed something internally with your new S10X or you have something else connected.
Do you have besides the S10X anything else like an additional powermeter, a new Efy Wallbox or a new E3DC One in farming? (Or something else besides the naked S10X)?
In the E3DC Smartphone app, do you have more than one powermeter "Netz" in german, i assume "Grid" in english shown?
If so, what kind of power meter is this?

[mkkri]

Thanks for your quick reply and for checking the python-e3dc lib!

I think I have found the most likely reason for powermeter type 11 in my setup:

• My S10X has an "Externe Quelle" (external source) configured.
• This is shown as an extra source in the E3DC dashboard – additional PV modules ("Balkon-PV") feeding into the system.
• So the S10X is not a "naked" system, but has this extra external source configured in the E3DC settings.

In addition, my account also has access to another E3DC system:

• A separate E3DC S10 SN at a different location (different network, different IP, connected via VPN).
• This S10 SN can be integrated in Home Assistant via the same integration without any problems, even while the S10X is active.
• The S10 SN does NOT have an external source configured and does NOT show this issue – so the problem seems to be specific to the S10X with the configured "Externe Quelle".

In the E3DC smartphone app for the S10X I see:

• The usual "Netz" (Grid) meter
• Plus the additional "Externe Quelle" flow

So my guess is:
PowermeterType 11 is the internal representation for the external source (additional PV) on the S10X with this configuration.

One more detail: The S10X installation is completely new and was only commissioned 2 days ago.
So it is likely running a very recent firmware, which might use the new powermeter type 11 for the external source.

If it helps, I can provide screenshots from the app showing the external source in the dashboard and the powermeter overview.

[bullitt186]

Thanks for the additional information!

As far as I know, external generators such as the balcony power plant require the home power plant to have an additional external power meter from E3/DC such as the LM3p40isp/-iec, LM3p80hhc, or LM3pU iec.
Perhaps also an XEM470 (see https://www.e3dc.com/wp-content/uploads/2022/02/E3DC_Broschuere_Technik_der_Produkte.pdf, page 27).

But perhaps there is also a newer component here that is not yet listed in the 2022 brochure, which is causing the new ID.

Can you check your home distribution system or the S10X distribution box to see if there is an additional meter installed and specify the type?

Thank you!

[mkkri]

I have checked the S10X distribution and the external wiring.

Inside the S10X itself there is an internal E3DC meter of type LM3p40iec.
In addition, there is a second external E3DC meter of type LM3p80hhc installed, which is used for the balcony PV modules ("Externe Quelle") and is connected via CAN bus to the S10X.

So my setup is:

• Internal meter: LM3p40iec (inside the S10X)
• External source meter (balcony PV): LM3p80hhc, connected via CAN

I have also taken a photo of both meters and can upload it here if that helps.
My guess is that powermeter type 11 corresponds to the external LM3p80hhc used for the "Externe Quelle".

[bullitt186]

Thanks for posting including pictures.
That is really odd. I have the very same LM3p80hhc connected to my S10X Compact, but as a meter for consumption of my heating pump.
I did some further digging and found in the installation manual of the LM3p80hhc these IDs

and in the Modbus Manual from October these additions:

But both mention no ID 11.
Te installation manual states "Die Typisierung und Benennung des Leistungsmessers erfolgt
in der Funktion Externe Quellen im Hauptmenü des S10 Hauskraftwerks."

Could you do one more check on the S10X display:
Hauptmenü->Leistungsmesser->Einstellungen->Right Arrow (from Netz to the next one) until it says "Balkonmodule" under Name?
On that screen it would be valuable to know that it says under Type.
Here's a picture of the screen from my S10X, so you know what i mean:

I am curious whether it's something new or a misconfiguration.

[mkkri]

I checked the S10X display as you suggested:

Path on the S10X:
Hauptmenü -> Leistungsmesser -> Einstellungen -> (right arrow) to the meter named "Balkonmodule".

On that screen it shows:

• Name: Balkonmodule
• Type: "Produktionszähler (keine Speicherung)"
• Measured phases: L1, L2, L3

So the external source (balcony PV) with the LM3p80hhc is configured as a
"Produktionszähler (keine Speicherung)" on all three phases (L1, L2, L3).

I have attached a photo of this screen from the S10X UI for reference.
Given this, my guess is that powermeter type 11 corresponds to this
"Produktionszähler (keine Speicherung)" configuration for the external source (LM3p80hhc, Balkonmodule).

[bullitt186]

I have a patch to the base library python-e3dc open in my fork

To make sure it works, would you be able to modify File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py" around Line 3637 (class PowermeterType)? This class defines all known powermeter types.

You need to add the line

    PM_TYPE_DATA_DISPLAY = 0x09
    PM_TYPE_REGULATION_BYPASS = 0x0A
    PM_TYPE_ADDITIONAL_PRODUCTION_NO_STORAGE = 0x0B

so that in total it looks like this

class PowermeterType(Enum):
    """All available powermeter types."""

    PM_TYPE_UNDEFINED = 0x00
    PM_TYPE_ROOT = 0x01
    PM_TYPE_ADDITIONAL = 0x02
    PM_TYPE_ADDITIONAL_PRODUCTION = 0x03
    PM_TYPE_ADDITIONAL_CONSUMPTION = 0x04
    PM_TYPE_FARM = 0x05
    PM_TYPE_UNUSED = 0x06
    PM_TYPE_WALLBOX = 0x07
    PM_TYPE_FARM_ADDITIONAL = 0x08
    PM_TYPE_DATA_DISPLAY = 0x09
    PM_TYPE_REGULATION_BYPASS = 0x0A
    PM_TYPE_ADDITIONAL_PRODUCTION_NO_STORAGE = 0x0B

There are many ways of doing so but one way could be:

• Install the Advanced SSH & Web Terminal.
• Disable save mode in the terminal settings
• enter the HA container via docker exec -it homeassistant bash
• Edit the file via vi /usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py
• Go to line 3637 via :3637
• Enter edit mode py pressing i
• enter the the three mentioned lines
• Exit edit mode by pressing escape
• Save the changes via :wq
• you should be back to the command line
• exit the container via exit
• exit the terminal and restart HA

If all goes well the E3DC integration should work afterwards and have sensors called "Additional Production No Storage" for the Balkonkraftwerk. It would be great if you could report back if this works and whether the values of that sensor really match your Balkonkraftwerk's

Thank you

[mkkri]

Huge thanks for your help and all the effort you put into this!

I applied the changes to PowermeterType in _rscpTags.py exactly as you suggested:

PM_TYPE_DATA_DISPLAY = 0x09
PM_TYPE_REGULATION_BYPASS = 0x0A
PM_TYPE_ADDITIONAL_PRODUCTION_NO_STORAGE = 0x0B

After restarting Home Assistant, the integration now works perfectly with my S10X:

• The error Fatal error when talking to E3DC: 11 is not a valid PowermeterType is gone.
• The E3DC RSCP integration is fully initialized without configuration errors.
• My S10X now shows 43 entities in Home Assistant.

So your new definition for PM_TYPE_ADDITIONAL_PRODUCTION_NO_STORAGE = 0x0B fits my setup very well.

Just to recap my configuration for completeness:

• System: E3DC S10X (new installation, commissioned only a few days ago)
• Internal meter: LM3p40iec inside the S10X
• External source (balcony PV) with LM3p80hhc connected via CAN bus
• On the S10X UI this external source is configured as:
  • Name: "Balkonmodule"
  • Type: "Produktionszähler (keine Speicherung)"
  • Phases: L1, L2, L3

Everything is now running smoothly on my side.
Thank you very much again for the quick support, the detailed guidance and the patch – really appreciated!

One question for the future:
Since I have modified _rscpTags.py directly inside the Home Assistant container, are there any recommendations on what I should watch out for regarding future updates?
For example:

• Will a future release of python-e3dc / this integration include this change so that I can safely update without re-applying the patch?
• Are there any Home Assistant Core or integration updates I should avoid until this is merged, because they might overwrite the file again?

Any guidance on how to handle updates in the future would be very helpful. If you need any further tests with my S10X setup, I’m happy to help.

[bullitt186]

I opened a PR at python-e3dc with the changes, after it is integrated and a new version is released, hacs-e3dc can be updated as well. if there are hacs-e3dc releases in the meantime, you may have to re-apply the fix again.

[bullitt186]

PR fsantini/python-e3dc#137 has been merged at python-e3dc, but in order to help you in your case, it needs also a new release of python-e3dc

[mkkri]

Just a short update from my side:

My electrician has changed the meter type of the external LM3p80hhc in the S10X settings from
"Produktionszähler (keine Speicherung)" to simply "Produktionszähler".

With this change, the values from the external source (Balkonmodule) now arrive correctly in the
"Additional production no storage" entity in Home Assistant. So from a practical point of view,
the integration is working fine for me with the current configuration.

I have one additional question/idea:

Is it possible to expose the three phases of the LM3p80hhc as separate entities in Home Assistant?
In my setup, I have a different photovoltaic field on each phase (L1, L2 and L3). It would be very
interesting to see the individual power per phase, not only the total power of the external source.

If RSCP / python-e3dc provides per-phase data for this meter, would it be possible in the future
to map these as separate entities (e.g. "Additional production no storage L1/L2/L3" or similar)?

Thanks again for all your support and for the great work on this integration!