I believe no there is no link mechanism but I’m no core dev and don"t really know. @J-N-K jan maybe knows ?
Thank you very much for the reply, I will try to do this and if it works I will get back to you. This is a big issue in Sweden as we can have a price difference of up to 2200% in one day. it can make big savings in a year.
Thank´s again Joakim A
This is pretty much what openEMS does, it standardizes channel instances and value ranges in order to build portable controllers (algorithms). In its case inverter must provide power related channels (generation, max active power, max apparent power) + few more in order to utilize rest of the system. Obviously there is a way to implement inverter without all channels, but then you can’t rely on system core.
Still it is easy to say because openEMS is domain specific system, while openHAB is (fairly) generic purpose.
Cheers,
Łukasz
I forked your repository and added RAW Modbus für LAN based Logger LSE-3:
That’s a great addition!
I’ve contributed the binding to the Openhab addon repo (openhab-addons/bundles/org.openhab.binding.solarman at main · openhab/openhab-addons · GitHub), it will be out in 4.3. Can you please open a PR there?
Yes, I opened a PR:
Thx
getting a Deye SUN-6K-SG03LP1-EU in a few days and i was wondering what is the delay of the info using that binding?
By default, the binding queries the data from the inverter every minute, so a value will at most be 1 minute old.
thnx ,so for instant values i must go with solar assistant and mqtt than this binding?
All the options you mentioned behave the same as this binding: they query the inverter at a regular interval, which AFAIK is also 1 minute.
What you could do is decrease the refresh interval in the configuration from 60s to something lower, like 30s or even 10s.
Just out of curiosity, why do you need “instant” values, in my experience one value per minute is enough?
need the data to create automation senarios for example if no sunshine,time is 3pm and battery is not fully charged yet then dont allow to start the oven or play a message and advise my wife not to start the dryer at night…something like that.I think refresh interval of 30s will be ok but i ma exploring all options…
Hi, I am using OpenHABian x64 on RPI4, OH Version 4.3 (all quite up to date 
)
I ran into some strange issues when trying to connect the Solarman binding to my two “balcony type” solar inverters.
They are of type “Bosswerk Mi 300”, but internally they are rebranded Deye SUN 300 devices (yes, those which have the missing relays 
I have the external WiFi coupled Deye relays retrofitted)
But, well noted, it is Deye SUN 300 equivalent, with one MPPT circuit (and not 6 SUN 600 / 2x MPPT). Nevertheless, differences seem to be minimal otherwise; they come with an integrated WiFi logger and by default connect to the Solarman cloud, just like the SUN 600. Up and running for 3 years.
So I gave it a try in the binding by selecting SUN 600, entered the IP and the logger serial (easy to find in the Solarman app), and … well… got an error
I already logged it with “TRACE” setting. I hope someone can support me here
2024-12-26 15:39:46.136 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Found definition for deye_2mppt
2024-12-26 15:39:46.138 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Raw Type V5MODBUS
2024-12-26 15:39:46.187 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Updated thing with id solarman:logger and 37 channels
2024-12-26 15:39:46.192 [DEBUG] [ernal.updater.SolarmanChannelUpdater] - Fetching data from logger
2024-12-26 15:39:46.194 [TRACE] [rnal.modbus.SolarmanLoggerConnection] - Request frame: A517001045000081A615F502000000000000000000000000000001030001007DD42B2015
2024-12-26 15:39:46.297 [TRACE] [rnal.modbus.SolarmanLoggerConnection] - Response frame: 41542B595A434D505645523D4D57335F3136555F353430385F352E30432D530D0A0D0A
==> /var/log/openhab/events.log <==
2024-12-26 15:39:46.075 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2024-12-26 15:39:46.088 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from INITIALIZING to UNKNOWN
2024-12-26 15:39:46.299 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Error fetching data from logger, here are the errors:
Request Request{start=0x1, end=0x7d, mbFunctioncode=0x3} returned error: Response frame has invalid starting byte
@Hundertvolt1 - can you try using RAWMODBUS as solarmanLoggerMode and check if that works?
I already tried this, yet without the detailed logs. In the UI Thing the error message was identical.
If you need the logs from OH, we’ll need to wait until tomorrow as the sun has already set and my devices went offline 
Sun is back, and so is the inverter 
Here’s what it told me in RAW Modbus mode:
2024-12-27 09:21:23.495 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Found definition for deye_2mppt
2024-12-27 09:21:23.496 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Raw Type RAWMODBUS
2024-12-27 09:21:23.530 [DEBUG] [arman.internal.SolarmanLoggerHandler] - Updated thing with id solarman:logger and 37 channels
2024-12-27 09:21:23.541 [DEBUG] [ernal.updater.SolarmanChannelUpdater] - Fetching data from logger
2024-12-27 09:21:23.542 [TRACE] [rnal.modbus.SolarmanLoggerConnection] - Request frame: 03E80000000801030001007DD42B
2024-12-27 09:21:23.644 [TRACE] [rnal.modbus.SolarmanLoggerConnection] - Response frame: 41542B595A434D505645523D4D57335F3136555F353430385F352E30432D530D0A0D0A
==> /var/log/openhab/events.log <==
2024-12-27 09:21:23.464 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2024-12-27 09:21:23.472 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from INITIALIZING to UNKNOWN
2024-12-27 09:21:23.646 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarman:logger:260685a828' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Error fetching data from logger, here are the errors:
Request Request{start=0x1, end=0x7d, mbFunctioncode=0x3} returned error: Response frame has invalid starting byte
Just as an info: I also tried to reach port 8899 via a web browser. It is definitely “alive”; there are about 2…3 binary messages per second coming out, but also AT commands like AT+YZCMPVER=MW3_16U_5408_5.0C-S which seem to give a hint about the firmware version.
It’s a bit of a surprise - there is sparse documentation that there is such thing as an AT command Modbus on Deye inverters on port 48899 while 8899 should be TCP modbus. I would not have expected AT commands there…
Anyway, I found this repo where all Deye Microinverters (SUN 300, 600 and upwards) are listed with the same register configs. So I still wonder why my 300 type inverters are so unwilling if other people could make their 600 type talking…
Please let me know which settings or tests I can try!
Some things which came to my mind while searching for a solution…
- Can it be possible that TCP Modbus is no longer supported? In the repo mentioned before, I found
However, logger firmware versions 2.x does not seem to expose Modbus/TCP interface anymore, hence Modbus/AT protocol support has been implemented.
Which would explain the AT command I saw on that interface. Is AT Modbus somehow supported by the binding?
- Could there be an address / ID clash with another device on the bus? Maybe the relay box is also communicating via Modbus and we are accidentally not filtering out these messages?
I see there is an implementation of the AT+Modbus protocol implemented here: deye-inverter-mqtt/src/deye_at_connector.py at main · kbialek/deye-inverter-mqtt · GitHub
Have you tried deye-inverter-mqtt to see if it correctly fetches the data from your inverter?
Been thinking about that for days, but in Winter time it’s hard to find a good time for testing, as the inverters wake up after, and go to sleep before the kids 
Anyhow, no success here… the Docker setup of the repo is functional and gives many debug messages, but they seem to confirm what I already saw on port 8899:
- in tcp mode, it tells me it detected AT commands (as I did in the browser attempt) and recommends me to switch to AT modbus
- in at mode, it permanently runs into response timeouts
- on port 48899, which is sometimes associated with AT modbus, there is no response at all (unreachable)
The integrated logger seems to stubbornly ignore any incoming commands and - just by itself on any established connection, even without receiving any command - to send the same binary message allover again, only interrupted every 5 minutes by an AT command telling the firmware version. 
I still suspect the external relay box communication to run over this port. The fix for the “relay gate issue”, you know 
Is there any “known good” contact address of the Deye support I could write to?
Hi again, now we have some news! 
<TL;DR> With a different firmware from Deye support, AT Modbus runs on port 48899. TCP Modbus is no longer supported. So AT Modbus support in the binding would be very much appreciated
I contacted Deye with very successful, friendly, but yet very scary results.
- Firmware version MW3_16U_5408_5.0C-S (or even the 5-series) of Deye or rebrand microinverters DO NOT SUPPORT MODBUS at all.
- The Deye support is very friendly and very responsive; I asked them about logging, and they told me that they do not offer any technical support, but can provide Firmware version MW3_16U_5406_2.33-E3, which indeed supports Modbus.
- As far as I know, the version before the upgrade to 5 was something like 2.01 (but not sure), so I have at least the impression that there is another firmware branch which still has the logging feature, but you don’t get this installed by default. So don’t hesitate to ask.
- The scary part is how the firmware finds its way onto the inverters. It’s not that you get a download of a binary file. You write the serial numbers of the inverters to the Deye support, and then somebody in China presses a button and 5 minutes later you have another version on your inverter… technically this works, all further thoughts are up to you, but there is no real alternative, is it?
- As mentioned in the MQTT repo mentioned above, it is true that the 2.xx firmware does NOT support TCP Modbus. But in AT Modbus mode, I actually got meaningful responses from the inverter!
- On Port 8899, there is nothing responding, neither to TCP, nor to AT commands. The AT Modbus runs on Port 48899 (and plainly works there).
Therefore, in the config.env file, the most important non-default settings (besides IP addresses and Inverter serial number) for Deye microinverter were:
DEYE_LOGGER_PORT=48899
DEYE_LOGGER_PROTOCOL=at
DEYE_METRIC_GROUPS=micro, settings_micro
leading to a successful readout (with serials and IPs blanked):
2025-01-10 08:59:14,950 - DeyeDaemon - DEBUG - Invoking action
2025-01-10 08:59:14,950 - DeyeInverterState - INFO - Reading start
2025-01-10 08:59:14,950 - DeyeInverterState - INFO - Reading registers [metrics group: {'micro'}, range: 003c-0074]
2025-01-10 08:59:14,950 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2025-01-10 08:59:15,050 - DeyeAtConnector - DEBUG - Received AT response in 1. attempt: b'192.168.xx.x,289C6E2517EE,**********'
2025-01-10 08:59:15,051 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2025-01-10 08:59:15,151 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103003c003945d4\n'
2025-01-10 08:59:16,252 - DeyeAtConnector - DEBUG - Received AT response in 1. attempt: b'+ok=01\x1003\x1072\x1000\x1000\x1000\x1000\x1000\x1000\x1009\x10A7\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1009\x10A7\x1000\x1000\x1000\x1000\x1000\x1000\x1009\x104C\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1013\x1088\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1006\x1018\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1001\x109D\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1000\x1088\x10DA\x10\r\n\r\n'
2025-01-10 08:59:16,253 - DeyeAtConnector - DEBUG - Extracted Modbus response 01037200000000000009a70000000000000000000009a7000000000000094c00000000000000000000138800000000000000000000000000000000000000000618000000000000000000000000000000000000000000000000000000000000000000000000019d000000000000000000000000000088da
2025-01-10 08:59:16,253 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+Q\n'
2025-01-10 08:59:16,353 - DeyeInverterState - INFO - Reading registers [metrics group: {'settings', 'settings_micro'}, range: 0028-0028]
2025-01-10 08:59:16,353 - DeyeAtConnector - DEBUG - Sending AT command: b'WIFIKIT-214028-READ'
2025-01-10 08:59:16,454 - DeyeAtConnector - DEBUG - Received AT response in 1. attempt: b'192.168.**.*,289C6E2517EE,**********'
2025-01-10 08:59:16,454 - DeyeAtConnector - DEBUG - Sending AT command: b'+ok'
2025-01-10 08:59:16,554 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+INVDATA=8,0103002800010402\n'
2025-01-10 08:59:17,656 - DeyeAtConnector - DEBUG - Received AT response in 1. attempt: b'+ok=01\x1003\x1002\x1000\x1064\x10B9\x10AF\x10\r\n\r\n'
2025-01-10 08:59:17,656 - DeyeAtConnector - DEBUG - Extracted Modbus response 0103020064b9af
2025-01-10 08:59:17,656 - DeyeAtConnector - DEBUG - Sending AT command: b'AT+Q\n'
2025-01-10 08:59:17,756 - DeyeInverterState - DEBUG - Production today: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - Production Total: 247.1
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - Phase1 Voltage: 238.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - Phase1 Current: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - Phase1 Power: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - AC Freq: 50.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - Uptime: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV1 Voltage: 41.3
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV1 Current: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV1 Power: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV1 Production today: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV1 Total: 247.1
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV2 Voltage: 0.0
2025-01-10 08:59:17,757 - DeyeInverterState - DEBUG - PV2 Current: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV2 Power: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV2 Production today: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV2 Total: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV3 Voltage: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV3 Current: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV3 Power: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV3 Production today: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV3 Total: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV4 Voltage: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV4 Current: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV4 Power: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV4 Production today: 0.0
2025-01-10 08:59:17,758 - DeyeInverterState - DEBUG - PV4 Total: 0.0
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - DC Total Power: 0.0
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - Operating Power: 0.0
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - AC Active Power: 0.0
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - Radiator temperature: 5.6
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - Active power regulation: 100.0
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - Data readiness observations: [total_energy@2025-01-10 08:59:17.756822:247.10000000000002]
2025-01-10 08:59:17,759 - DeyeInverterState - DEBUG - Data readiness check result: True
2025-01-10 08:59:17,761 - DeyeInverterState - INFO - Reading completed
Wow, thanks for the heads up and the investigation, glad it works using AT. I’ll see if I can get my hands on a serial logger which supports AT commands (I don’t have a micro-inverter setup), to try and add this to the binding.