Habe ich auch erst gestern Abend eingebaut 
Is the battery in your app also separately controllable?
Thanks
“The DTSU666 is the same meter that I have installed as well. Do you have up‑to‑date firmware versions on your devices (dongle, inverter, etc.)?
Hello @Andi , excellent job and evolution you are doing here. Love the fact you added the SmartCharger for EVs. Question what options will be available in flow cards? Can a flow be, “when” export to grid starts “and” if SmartCharger have cable connected, “then” starts charging EV?
Will there be such an interaction/capabilities?
Can’t wait for my sytem to be installed.
Thanks,
Gonçalo
Awesome! The new Emma Modbus works great and acts like an inverter now! I could not get the new EMMA battery to work but the normal battery works anyway!
Salü Andi
Happy to support testing!
My setup:
- SmartGuard-63A-T0 (EMMA integrated)
- SUN2000-8KTL-M1
- LUNA2000-10KW-C1
Until now i managed my setup with Virtual devices for the energy tab and the app Solaredge + Growatt TCP Modbus. Disabled that all and started using your (starch vermissti) App.
so far so good → let’s see 
Beschte Dank voruus!
1 Like
Guten Abend Andi
I’m missing the “THEN” cards for the EMMA devices - e.g. :
- storage_working_mode_settings (Battery) → Betriebsmodus Speicher
- i can change them manually but not with a card
- storage_excess_pv_energy_use_in_tou → PV Überschuss Nutzung
- dito (no scenario for me currently)
thx
The EMMA Modbus interface exposes only read-only registers for the Smart Charger — there are no write registers at all in this table. Starting, stopping, or controlling the charge power is therefore not possible through the EMMA Modbus driver.
If anyone has the other Modbus Interface Definition (the full spec, not the EMMA subset) and knows whether charger control registers are documented there, or has experience controlling the charger via a different route, please share — happy to implement it if the registers are known.
Hoi Rick
Action Flows are implemented now.
LG Andi
1 Like
I am on newer software versions (although I don’t know whether that matters):
-
SDongleA‑05: V200R022C10SPC312
-
SUN2000‑10KTL‑M1: V100R001C00SPC173
-
LUNA2000: V100R002C00SPC637
Attached is the explanation of how the values are derived:
All registers of the DTSU666 driver (read from SUN2000 registers 371xx, Unit ID 1):
| Register | Name | Type | Unit | Capability | Note |
|---|---|---|---|---|---|
| 37101 | Grid Phase A Voltage | INT32 | V | measure_voltage.phase1 | |
| 37103 | Grid Phase B Voltage | INT32 | V | measure_voltage.phase2 | |
| 37105 | Grid Phase C Voltage | INT32 | V | measure_voltage.phase3 | |
| 37107 | Grid Phase A Current | INT32 | A | measure_current.phase1 | |
| 37109 | Grid Phase B Current | INT32 | A | measure_current.phase2 | |
| 37111 | Grid Phase C Current | INT32 | A | measure_current.phase3 | |
| 37113 | Power Meter Active Power | INT32 | W | measure_power | inverted: + = consumption |
| 37119 | Grid Exported Energy | INT32 | kWh | meter_power.exported | |
| 37121 | Grid Accumulated Energy | INT32 | kWh | meter_power | total grid import |
| 37132 | Grid Phase A Power | INT32 | W | measure_power.phase1 | inverted |
| 37134 | Grid Phase B Power | INT32 | W | measure_power.phase2 | inverted |
| 37136 | Grid Phase C Power | INT32 | W | measure_power.phase3 | inverted |
Important: All registers are in the SUN2000 address space — use the IP and Modbus ID of the SUN2000, not of the DTSU666.
The signs of registers 37113 / 37132–37136 are inverted because the SUN2000 convention is + = export, but Homey expects + = import.
The 371xx registers are SUN2000 registers, not DTSU666 registers.
The driver does not read the DTSU666 directly — it reads the meter data that the SUN2000 collects from the DTSU666 via RS485 and exposes in its own holding registers 37101–37136.
This means:
-
The IP address must be the IP of the SUN2000 / SDongle, not the DTSU666
-
The Modbus ID must be the Unit ID of the SUN2000 (default: 1), not the meter’s ID
-
The DTSU666 itself has no LAN/TCP connection — it is only connected via RS485 to the SUN2000
1 Like
thx!
storage working mode works fine with the cards (tested it from 2 to 5 and vice versa)
1 Like
This is correct as per this other discussion I found: Huawei FusionCharge Wallbox · evcc-io/evcc · Discussion #10262 · GitHub
Only via OCCP protocol it is possible but there are some limitations below 4.2kW still needing development from Huawei R&D
But I also found that it has the option to activate modbus on itself independently: https://docs.eniris.be/en/Controller/Devices/EV-charging-station/HuaweiSCHarger
Hi @Andi
Shouldn’t the curve for Electricity total (value of measure_power?) be *-*1? The curve is is blue for importing, but the battery is full and currently exporting. In my opinion the Netzwerkleistung should be * - 1.
Energy SDK screenshot
Have a request @Andi is it possible to add the force charge/discharge option settings for the luna2000 modbus device to set the rules for forced charge/discharge?
// Teddy
1 Like
If someone is able to provide the RW modbus registers for SCharger, I’m happy to implement it
3 new flow action cards for luna2000_modbus in version 1.1.2
| Card | Registers written | Args |
|---|---|---|
| Start force charge | 47102 (power) → 47104 (SoC) → 47100 (0xBB) | Power (W), Target SoC (%) |
| Set force charge power | 47102 | Power (W) |
| Set force charge target percentage | 47104 | Target SoC (%) |
Key details:
-
The combined “Start force charge” card writes power and SoC before issuing the force charge command — so the parameters are in place when the command executes
-
SoC raw value =
target_soc × 10(register 47104 has gain 10 per Huawei spec) -
Power is written in W directly (register 47102, no scaling)
-
The force charge command value is
187(0xBB), same as the existing “Set force charge/discharge” card
2 Likes
Should be fixed now.
Andi
1 Like
Your the best Andi ill write a script to empty out my batteri in the morning so it is reset for the sunny day under specific conditions.
// Teddy
1 Like
