AstraMeter with a Sungrow inverter + DTSU666 smart meter

[JeremyPerales]

Hi,

I’m trying to use AstraMeter with a Sungrow inverter + DTSU666 smart meter for EVCC.

Current setup:

• Sungrow inverter
• DTSU666 smart meter
• AstraMeter running in Docker on Synology DSM
• EVCC works correctly and shows the real grid consumption/import/export values
• AstraMeter discovery works
• Shelly emulation works
• Ports 1010 and 2220 are listening correctly

I plan to buy a Marstek Venus E 3.0 battery soon and want to make sure the Shelly Pro 3EM emulation works correctly before buying/installing the battery.
The Marstek Venus will later be integrated into EVCC.

Docker run command:

sudo docker run -d
--name astrameter
--restart unless-stopped
--network host
--privileged
--user 0:0
-v /volume1/docker/astrameter/config.ini:/app/config.ini
ghcr.io/tomquist/astrameter:latest

Current config:

[GENERAL]
DEVICE_TYPE = shellypro3em

[MODBUS]
HOST = 192.168.178.22
PORT = 502
UNIT_ID = 1
ADDRESS = 13009
COUNT = 2
DATA_TYPE = INT32
BYTE_ORDER = BIG
WORD_ORDER = BIG
REGISTER_TYPE = HOLDING

I tested several registers:

• 13007 → -1W / 0W
• 13009 → around 85W but does not react to load changes
• 13021 → -1W
• 13033 → -1W
• 5601 with REGISTER_TYPE=INPUT → 0W

Example:
When switching on a water kettle (~2000W), EVCC correctly shows the higher grid consumption, but AstraMeter still stays at ~85W on register 13009.

Logs always show:
Successfully fetched ModbusPowermeter powermeter value ...

but mostly:

• -1W
• 0W
• or fixed 85W

There is also this recurring error:
TypeError: AsyncModbusTcpClient.close() got an unexpected keyword argument 'intern'

Could someone help identify the correct Sungrow/DTSU666 power register and register type for AstraMeter?

Thanks!

Here the logs at Register 13009:

[tomquist]

I don't have a Sungrow + DTSU666 rig to test against, so take this with a grain of salt but I went and dug through the usual Sungrow Modbus references and I think two settings in your [MODBUS] block are the problem. My best guess from reading those maps is that the 5xxx/13xxx registers are input registers, not holding, and that Sungrow sends 32‑bit values word‑swapped. If that's right, that combination would explain a read that "succeeds" but never moves off ~85 W.

Worth a try:

[MODBUS]
HOST = 192.168.178.22
PORT = 502
UNIT_ID = 1
ADDRESS = 13009          # "Export power"
COUNT = 2
DATA_TYPE = INT32
BYTE_ORDER = BIG
WORD_ORDER = LITTLE      # <-- was BIG; Sungrow looks to be word-swapped
REGISTER_TYPE = INPUT    # <-- was HOLDING; Sungrow seems to use input registers (FC04)
# 13009 reads positive when exporting; Shelly/EVCC want import = positive,
# so you'll probably need to flip the sign:
POWER_MULTIPLIER = -1

Where I'm getting the register details (I just looked these up, haven't verified them on hardware):

• The addresses and the "these are input registers, read word‑swapped" detail come from mkaiser's Sungrow‑SHx HA Modbus map, which is the most widely-used community reference I could find. According to that map:
  • 13009 is "Export power": grid power, positive = export, so it likely needs POWER_MULTIPLIER = -1.
  • 5600 is "Meter active power": the DTSU666 reading directly (described as valid when the meter is wired to the inverter, which is your case). Might be the cleaner choice. One thing I noticed: you tried 5601 earlier per that map it should be 5600 (5601 would be the high word).
  • 13033 ("Total active power") and 13007 ("Load power") look like inverter/house figures rather than grid power, so I'd avoid those for this.
• There's also the official Sungrow protocol PDF mirrored in bohdan-s/Sungrow‑Inverter if you want to cross-check against the source doc.

How you'll know it worked: with the kettle on, the value should jump clearly positive (~2000 W from the grid). If it goes negative instead, just drop the POWER_MULTIPLIER = -1 I'm least sure about the sign, especially for 5600, since it can vary by firmware.

On the close() ... 'intern' error: that one I'm more confident about, it's a known pymodbus 3.6.5 bug (fixed in 3.6.6) that only fires when the TCP connection gets dropped. On Sungrow the common cause, going by mkaiser's connection FAQ, is that the WiNet‑S dongle only allows one Modbus client at a time, so if EVCC (or HA/SunGather) is polling the inverter at the same time as AstraMeter, they'll knock each other off. Might be worth confirming only one tool is talking to the inverter; a wired LAN connection instead of WiNet‑S is also reportedly much more stable.

Again, this is all from reading the docs rather than a working setup, so I'd love to hear whether the INPUT + word‑swap change actually moves the needle for you.

[JeremyPerales]

Thanks a lot for digging into this.

Your suggestions were actually very helpful and I now have a working power reading with my Sungrow setup.

What worked for me:

[MODBUS]
HOST = 192.168.178.22
PORT = 502
UNIT_ID = 1
ADDRESS = 5600
COUNT = 2
DATA_TYPE = INT32
BYTE_ORDER = BIG
WORD_ORDER = LITTLE
REGISTER_TYPE = INPUT

I can now confirm:
Register 13009 required: POWER_MULTIPLIER = -1
Register 5600 did NOT require the multiplier.

Both registers seem to work correctly now.

From what I understand, 5600 is probably the better choice because it appears to be the direct DTSU666 meter active power value, while 13009 is more of an inverter/export calculation.

The values I received matched my current real household consumption quite well.

Unfortunately I could not properly do the kettle (~2 kW) stress test because of the remaining Modbus/pymodbus connection error. Even with the EVCC container stopped, AstraMeter still occasionally throws:

AsyncModbusTcpClient.close() got an unexpected keyword argument 'intern'

So I could only verify against normal household load, not against a large sudden load increase.

Still, the INPUT register + LITTLE word order fix definitely solved the main issue.

The remaining error:

AsyncModbusTcpClient.close() got an unexpected keyword argument 'intern'

still appears occasionally, even with EVCC disabled, but it does not seem to prevent correct readings.

For context:
I currently use a Sungrow inverter with DTSU666 meter and I plan to buy a Marstek Venus E 3.0 battery soon. My goal is to first get the emulated Shelly working reliably before purchasing the battery, because the battery will later be integrated into EVCC as well.

So overall your INPUT-register + word-swapped assumption seems to have been exactly right. Thanks again!

Do you think the remaining error will not work for my system? Right now I have a Sungrow SH10RT inverter related to a DTSU 666 Smart Meter linked via evcc to a go e charger. I want to integrate to that system a Marstek Venus E 3.0 and want to be sure that this will work.

Thank you.

[tomquist]

Awesome, glad that sorted it and thanks for posting the working config back, that's useful for the next person who hits this. Quick recap for posterity:

• 5600 ("Meter active power", the DTSU666 directly): REGISTER_TYPE = INPUT, WORD_ORDER = LITTLE, no multiplier needed. Sign comes out right because the meter reports import-positive already.
• 13009 ("Export power", the inverter's own figure): same settings but needs POWER_MULTIPLIER = -1 to flip export-positive into the import-positive convention Shelly/EVCC expect.

Your instinct to prefer 5600 matches what I'd lean toward too, it's the raw DTSU666 reading rather than something the inverter derives, so it should track grid changes with the least lag.

On the intermittent pymodbus error, to be upfront, I'm going off the bug reports rather than a reproduction here, but it lines up with a known pymodbus 3.6.5 bug (close() getting an unexpected intern kwarg, fixed in 3.6.6) that only fires when the TCP connection drops. So it's cosmetic in the sense you've found, the next poll just reconnects, but it's a signal the connection is being torn down periodically. On Sungrow that's most often the WiNet‑S dongle only tolerating one Modbus client at a time (mkaiser's connection FAQ covers this). If EVCC or HA is also polling the inverter, that'd explain the intermittency. I'll look at bumping AstraMeter's pinned pymodbus to ≥3.6.6 so the error at least stops cluttering your logs.

For the Marstek Venus E 3.0 next step: once the battery's in self-adaptation mode it should start following the emulated Shelly. The kettle test is still your friend, flip it on and the battery should react to the positive (import) swing. If you run into anything odd there, happy to help; might be worth a fresh discussion thread so it's findable on its own.

[JeremyPerales]

Thanks, thanks and thanks again for your perfect help! If anything occurs when I have the Marstek I will let you know.