Add Shelly EM1

[FrankvdAa]

This PR adds modbus support for Shelly EM1-based devices.

The EM1 are 1-phase meters, so I set phase2/3 to 0 with const for currents and voltages, as I couldn't find how to only provide single phase. I reckon it's enough to always provide L1 data, right? Otherwise I can add a parameter with which you could set the phase it's measuring.

[sourcery-ai]

Hey - I've left some high level feedback:

• The usage parameter is defined but never referenced in the template render; consider either wiring it into the configuration or removing it to avoid confusion.
• For currents and voltages, you currently hardcode two additional phases as constant zero values; if this is meant to be strictly single-phase, consider modeling it explicitly as single-phase or making the number of phases configurable instead of padding with zeros.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `usage` parameter is defined but never referenced in the template render; consider either wiring it into the configuration or removing it to avoid confusion.
- For `currents` and `voltages`, you currently hardcode two additional phases as constant zero values; if this is meant to be strictly single-phase, consider modeling it explicitly as single-phase or making the number of phases configurable instead of padding with zeros.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[FrankvdAa]

I also have a template prepared for 3-phase EM-based Shelly devices, but as I do not have one for testing yet, I've not pushed it.

In case anybody is available for testing it, let me know.

[github-actions]

Code review

templates/definition/meter/shelly-em1-modbus.yaml (lines 12-13, 21-36): usage param has no effect on pv/charge

The template declares usage: choice: ["grid", "pv", "charge"], but the render block never branches on .usage — the same power, energy, returnenergy, currents, and voltages registers are emitted identically regardless of the selected usage.

This is inconsistent with the established convention across other modbus meter templates in this repo: templates offering a pv choice typically apply a sign flip (and sometimes swap to a dedicated export-energy register) when usage == "pv", since the raw register is oriented for grid-import-positive while a PV meter is conventionally positive-for-generation. For example, in templates/definition/meter/eastron-sdm120.yaml:

evcc/templates/definition/meter/eastron-sdm120.yaml

Lines 17 to 23 in 8487a31

	address: 0x0c # Active power
	type: input
	decode: float32
	{{- if eq .usage "pv" }}
	scale: -1
	{{- end }}
	energy:

      address: 0x0c # Active power
      type: input
      decode: float32
    {{- if eq .usage "pv" }}
    scale: -1
    {{- end }}

The same pattern appears in bgetech-ws100.yaml, acrel-adw300.yaml, and dozens of other templates. As written, selecting pv (or charge) for this Shelly EM1 template reports power/energy with the same sign orientation as grid, which is likely incorrect for a PV/charge-point installation.

(Note: this overlaps with Sourcery's first comment above.)

[andig]

We don't have a consistent model for phase values on 1p devices- please remove phase readings for time being. May revisit later.

/cc @premultiply

[andig]

/cc @thierolm

[thierolm]

@FrankvdAa , what's the bennefit of your new modbus EM1 Shelly connection compared to the existing Shelly API support of evcc?

[andig]

Yikes. Please let me know if this needs be reverted and/or the model moved to an existing template. Thank you!

[FrankvdAa]

@FrankvdAa , what's the bennefit of your new modbus EM1 Shelly connection compared to the existing Shelly API support of evcc?

For HTTP API I have to configure admin password in EVCC for each Shelly, while modbus allows me to have local readonly access to valyes without authentication, while webinterface can still require password for access.

[andig]

I've reverted- lets agree on a strategy first. We surely don't want to duplicate implementations.

[FrankvdAa]

@andig, I think Modbus TCP is the more widely used protocol for energy systems.

The HTTP API is currently what's implemented for Shelly within EVCC and does not need to be removed in my opinion, but not adding the Modbus integration seems strange to me.

Modbus TCP is enabled by default on the newer Shelly devices: https://support.shelly.cloud/en/support/solutions/articles/103000316046-which-devices-supports-modbus-

[andig]

@premultiply @thierolm whyt?

[thierolm]

I would prefer not to add a dedicated Modbus implementation.
The existing Shelly HTTP/RPC integration already supports the broad Shelly ecosystem across generations, is well-tested in evcc, and exposes all data required by evcc.
Adding Modbus would create a second integration path for essentially the same information, increasing maintenance effort, documentation complexity, testing requirements, and support load.
For most evcc users, HTTP configuration is also significantly easier to understand than Modbus-specific concepts such as registers, scaling and slave addressing.

=> Unless Modbus provides functionality that is unavailable through the existing HTTP API, the additional protocol mainly adds complexity without delivering additional user value.

[FrankvdAa]

For most evcc users, HTTP configuration is also significantly easier to understand than Modbus-specific concepts such as registers, scaling and slave addressing.

I think this isn't a valid argument, as that is handled by the templates and isn't directly visible to the normal users.

At the moment you already have three Shelly templates of which two are shelly type one is a custom.

I do not see an issue with adding two modbus variants, one being 1p and the other 3p, that support all Shelly devices with modbus support.

Adding Modbus would create a second integration path for essentially the same information, increasing maintenance effort, documentation complexity, testing requirements, and support load.

These device templates (also non-Shelly) are not directly supported by EVCC crew and rely on community to support them, right?

[thierolm]

Not on me to decide :-)

[FrankvdAa]

Not on me to decide :-)

Me neither, unfortunatly ;-)