Git Product home page Git Product logo

ginlong-solis's Introduction

Ginlong Solis solar inverters

Preamble

Ginlong Solis is one of the world's recognised manufacturers of string solar inverters. Almost all of their products have an Modbus RS-485 interface for reading live status and statistics.

Quick start, you'll find here:

The ESPHome solution also has some advanced features such as limiting the inverter output power, synchronising the inverter time via NTP and more.

If in doubt, I recommend choosing the Solis S3 stick with the alternative firmware. You can currently buy the Solis S3 stick for about 20 € and get a rugged, waterproof case, external antenna, etc. For this price you can not buy and assemble the individual parts.

Please do me a favor: 👍 If you use any information or code you find here, please link back to this page. ⭐ Also, please consider to star this project. I really like to keep track of who is using this to do creative things, especially if you are from other parts of the world. 😃 You are welcome to open an issue to report on your personal success project and share it with others.

Solis ESPHome sample screen

ESP8266 Solis interface

Hardware

You need a proprietary Exceedconn EC04681-2014-BF connector (available on Ebay, alternatively nextguyover offers a model for 3D printing) and an RS485-to-serial adapter (a cheap one without DE/RE pins is sufficient, e.g. the HW-0519, XY-K485 or XY-017). Wire all components to e.g. a Wemos D1 mini (also available as 'pro' variant with an SMA connector and external antenna for better reception) as follows:

Solis ESP8266 wiring

A bit strange, you have to connect the RX pin of the HW-0519 adapter to the RX pin of the ESP (and the TX pin to the TX pin), so no RX-TX-crossover like normal.

Software (ESPHome)

Especially recommended if you use Home Assistant, solis-esphome-esp8266.yaml is an ready-to-use configuration file for ESPHome, using an ESP8266. With the ESPHome dashboard you can easily set up your system with just a few clicks via a user-friendly web interface.

Software (Arduino)

With solis2influx.ino one can read out all inverter data (status and statistics) via Modbus and push it to InfluxDB. It uses WiFiManager to setup WiFi, so you have to connect to the SOLIS2INFLUX access point with your mobile phone first.

The reading of the data starts immediately after configuring WiFi. The data is not sent to the InfluxDB server until the inverter's serial number has been read, which may take a moment (the serial number is added as a mandatory tag to distinguish multiple inverters):

DC voltage 1 = 243.70V
DC current 1 = 0.90A
Inverter temperature = 22.50°C
Grid frequency = 49.98Hz
Writing to influxDB: solis,serialnumber=1801020221230123 DC\ voltage\ 1=243.70,DC\ current\ 2=0.90,Inverter\ temperature=22.5,Grid\ frequency=49.98
Energy last month = 234kWh
Energy today = 1.23kWh
Energy last day = 3.45kWh
Writing to influxDB: solis,serialnumber=1801020221230123 Energy\ last\ month=234i,Energy\ today=1.23,Energy\ last\ day=3.45

Solis S3 WiFi Data Logging Stick (3rd gen)

The WiFi stick is Solis' current solution for connecting the inverter to their 'SolisCloud' platform (which is operated by Alibaba China). You can recognise the 3rd gen stick by the three LEDs on the front and the reset button on the back.

Software

The firmware of the stick offers support for connecting the stick to the home WiFi and displays basic inverter statistics. The firmware (at least the current version 1012F) is a kind of beta and incomplete, as it lacks important functions that are available in the previous generation WiFi sticks. In particular, support for setting a second remote logging server (called "Server B") is missing.

The web interface is protected by HTTP simple auth with fixed username admin and password 123456789. After connecting the stick to your home WiFi the web password changes without notice to your WiFi password. So you need to login to the web admin interface with admin and your WiFi password. This somewhat wierd behaviour again shows the immature state of the firmware.

Since the current firmware does not support setting up your own remote logging server, there is solis2influx.pl to read basic statistics from the web interface (/inverter.cgi) and publish this information in an influx db.

The stick firmware is based on Alibaba's AliOS-Things 3.0.0 embedded operating system (not sure if some parts of MXCHIPS's MiCO OS were been mixed in). It uses hardcoded DNS servers (public1.alidns.com and public2.alidns.com) and frequently pushes data to *.iot-as-mqtt.*.aliyuncs.com (this server is chosen depending on your geolocation).

Hardware

The stick hardware is based on MXCHIP's EMW3080-E MCU (ARM Cortex-M4F, 2.4G Hz IEEE 802.11 b/g/n WiFi, Suffix -E denotes IPEX antenna, MX1290 processor). Datasheet: V2.2.

✋ Contrary to all available datasheets, the EMW3080-E (at least the one in my Solis S3 stick) does not have 2MB flash installed, but an 8MB flash module.

The EMW3080 is some kind of relabeled (call it the same family) RTL8710BN MCU (Ameba-Z series). One can find more info about the EMW3080 at A_D Electronics and a discussion at esp8266.ru.

The stick is connected to the inverter via a type of proprietary Exceedconn EC04681-2014-BF connector (circular pin arrangement: 1=VCC=5V, 2=GND, 3=RS485+, 4=RS485-) . The external antenna is connected via a standard SMA connector. You can open the case by pressing the notches towards the centre of the stick.

Solis WiFi Stick PCB Front Solis WiFi Stick PCB Back

There is a serial interface (LogCLI) on the PCB connected to UART2_Log_TX and UART2_Log_RX of the MCU (115200 8N1, 3.3 Volt).

Update: Since end of 2022 there is a new PCB version which contains a hardware watchdog. You can recognize these new boards by the silkscreen '22.34' (which probably corresponds to the year and week of manufacture) .

Analysis via the serial port

You get a first impression when you examine the UART2_Log output:

ROM:[V0.1]
FLASHRATE:4
BOOT TYPE:0 XTAL:40000000
IMG1 DATA[1128:10002000]
IMG1 ENTRY[800053d:100021ef]
IMG1 ENTER
CHIPID[000000ff]
read_mode idx:2, flash_speed idx:2
calibration_result:[1:19:13][3:15]
calibration_result:[2:21:11][1:15]
calibration_result:[3:1:1][1:1]
calibration_ok:[2:21:11]
FLASH CALIB[NEW OK]
OTA2 ADDR[8100000]
OTAx SELE[ffffffff]
OTA1 USE
IMG2 DATA[0x800f1c0:36:0x10005000]
IMG2 SIGN[RTKWin(10005008)]
IMG2 ENTRY[0x10005000:0x800b105]
BOOT_FLASH_RDP RDP enable
RDP bin decryption Failed!
checksum_ipsec = 0x46956286, checksum_rdp_flash = 0x80d838a
2ndboot image start

Press key 'w' to 2ndboot cli menu in 100ms.
122: ota crc cal:0x7a1a param:0xffff
17: ota upg_flag:0xffffcount:0 crc;0xffff
30: No OTA upgrade.

See the full (anonymized) bootlog for more details.

When holding the 'w' key during boot an extremely limited 2ndboot CLI starts:

2ndboot image start 

Press key 'w' to 2ndboot cli menu in 100ms.
2ndboot ver: 2ndboot-1.0.0-20210917.200018
Please input 1-2 to select functions
[1] Uart Ymodem Upgrade 
[2] System Reboot 
[h] Help Info
2ndboot# h 
2ndboot ver: 2ndboot-1.0.0-20210917.200018
Please input 1-2 to select functions
2ndboot# 

When pulling TX pin 21 (PA_30) low during boot, the device waits for a xmodem transfer (UART boot mode):

ROM:[V0.1]
FLASHRATE:4
UARTIMG_Download 2
Open xModem Transfer on Log UART...

When the device is in this mode, one can download the firmware using RTLtool (depends on Python2) (Update: ltchiptool is now a better option):

$ python2 ./rtltool.py -p /dev/ttyUSB0 gf
Connecting...
Flash Status value: 0x40
$ python2 ./rtltool.py -p /dev/ttyUSB0 rf 0x8000000 0x800000 dump-0x8000000-0x800000.bin
Connecting...
Read Flash data from 0x08000000 to 0x08800000 in file: dump-0x8000000-0x800000.bin ...
Done!

Analysis of the memory content (firmware 1012F)

The dump contains all kinds of interesting stuff (AOS-R-3.0.0 and sdk-c-3.0.1 clearly link to AliOS-Things 3.0.0). With the help of Realtek AmebaZ Memory Layout, Introduction to Ameba-Z SDK and mk3080/flash_partitions.c one can reconstruct the flash partition table found at address 0x800e320:

DESCRIPTION     START_ADDR    LENGTH
Bootloader      0x0           0x8000        // = AliOS-Things/platform/mcu/rtl8710bn/bin/boot_all.bin
Recovery        0xb000        0x6000        // 2ndboot
Application     0x19000       0x127000
OTA Storage     0x150000      0x127000
Parameter1      0x2a0000      0x2000
Parameter2      0x2a2000      0x2000        // WiFi credentials @ 0x2a3000
Parameter3      0x2a4000      0x2000        // AliOS PK+PS+DN+DS
Parameter4      0x2a6000      0x2000
Parameter5      0x2a8000      0x10000
Parameter55     0x2b8000      0x1000
Parameter33     0x7fe000      0x1000        // Backup of Parameter3 ?
Offline         0x300000      0x4fe000      // 0x1000 zeros + some noise

Playing with the Alibaba IOT Platform

Partition 'Parameter3' contains the 'Product Key' (PK) and 'Device Secret' (DS) needed to connect to the Alibaba IOT Platform. The serial number of the stick is used as 'Device Name' (DN). With the Link SDK for Python you can easily impersonate as the inverter and send MQTT data to the SolisCloud.

Analysis of the main application (firmware 1012F)

The main application starts at 0x19000 with a TEXT segment for flash in place execution (XIP). It is followed by a DATA segment for RAM execution. I will refer to this part as 'APP1'.

The complete APP1 in OTA package format (including checksums) starts at 0x19000 with length 797628 and MD5 checksum 0a88cb5556ab28ffba63a8d56e131d56. With decode-alios-ota-firmware.pl one can view all details and validate the checksums:

$ ./decode-alios-ota-firmware.pl solis-s3-app-1012F_ota.bin
# Segment .text
  0x00000000:  Signature        = 0x3831393538373131 (OK)
  0x00000008:  Code length      = 790112
  0x0000000c:  Address          = 0x00000000 (FLASH XIP)
  0x00000010:  Reserved         = 0xffffffffffffffffffffffffffffffff
  0x00000020:  Code             = (byte code)

# Segment .data
  0x000c0e80:  Signature        = 0x3831393538373131 (OK)
  0x000c0e88:  Code length      = 7420
  0x000c0e8c:  Address          = 0x10005000 (RAM)
  0x000c0e90:  Reserved         = 0xffffffffffffffffffffffffffffffff
  0x000c0ea0:  Code             = (byte code)

# Segments checksum
  0x000c2b9c:  Checksum         = 0x25249404 (OK)

# OTA trailer
  0x000c2ba0:  Magic            = 0xefefefef (OK)
  0x000c2ba4:  Size             = 797600 (OK)
  0x000c2ba8:  MD5 checksum     = 0x85a615f88804cfb7784ffab81c27795b (OK)
  0x000c2bb8:  Reserved         = 0xffffffff

# End of data
  0x000c2bbc:  Filesize         = 0xc2bbc = 797628 (OK)

Somewhat unexpectedly, the APP1 part is followed by a second app ('APP2') starting with TEXT at 0xdbbbc (length 222276) and DATA at 0x112020 (length 3656). This APP2 is binary identical to AliOS ate.bin. It is currently not clear whether it is being used at all, there is a suspicion that it is an ATE firmware for Automatic test equipment or to set eFuses/RDP.

Tampering with the main application (firmware 1012F)

With knowledge of the source code it is easy to locate the corresponding byte code in the dump. For example, the Mbed TLS wrapper code

if (ca_crt != NULL) {
   mbedtls_ssl_conf_authmode(&(pTlsData->conf), MBEDTLS_SSL_VERIFY_REQUIRED);

corresponds to the binary

0803fb86 ba f1 00 0f     cmp.w      r10,#0x0
0803fb8a 2f d0           beq        LAB_0803fbec
0803fb8c 02 21           movs       r1,#0x2		// 0x2 = MBEDTLS_SSL_VERIFY_REQUIRED
0803fb8e 2e e0           b          LAB_0803fbee

So, if you change value 02 21 to 00 21 (0x0 = MBEDTLS_SSL_VERIFY_NONE) at offset 0x3fb8c, the destination SSL certificate will not be checked anymore and you can man-in-the-middle or redirect the SSL traffic (MQTT, HTTP, ... to Alibaba cloud).

When writing to the flash with RTLtool (wf cmd), make sure to always write full 4096 bytes aligned data blocks (flash SECTOR_SIZE 0x1000).

⚠️ Warning: Obviously writing to the flash memory is dangerous and may permanently damage your device.

Replacing the main application

Thanks to the fine folks at LibreTiny, arduino-compatible cores for RTL8710B chips are available. And even better, LibreTiny is now part of ESPHome. With solis-esphome-emw3080.yaml you can read out all relevant status and statistics data from your Solis inverter and push it to Home Assistant.

Install the ESPHome firmware for the S3 stick as follows:

  1. Install the ESPHome dashboard for Home Assistant (at least version 2023.9.0).
  2. If you not already have one, add a secrets.yaml to the ESPHome addon, containing at least wifi_ssid, wifi_password, wifi_ap_ssid, wifi_ap_password, api_encryption_key and ota_password.
  3. Add solis-esphome-emw3080.yaml to the ESPHome addon.
  4. Depending on your device type (standard inverter INV, hybrid inverter ESINV or export power manager EPM), copy one of solis-modbus-inv.yaml, solis-modbus-esinv.yaml or solis-modbus-epm.yaml as well.
  5. Within solis-esphome-emw3080.yaml edit device type accordingly (include statement within packages section).
  6. Click the three-dots button, then "Install" and "Manual Download".
  7. Wait for the compilation process to finish and download the "UF2 package".
  8. Set the MCU to UART boot mode (pull TX pin low during boot -- you do not need to solder, just inserting some jumper wires is sufficient). Make sure your serial adapter uses 3.3V voltage, read the notes below carefully about possible challenges with these adapters.
  9. Backup the stock firmware with ltchiptool (also available as a Win GUI version):
    $ ltchiptool -V
    ltchiptool v4.10.1 # use at least this version
    $ ltchiptool flash read -d /dev/ttyUSB0 RTL8710B solis-s3-firmware-1012f.bin
    I: Connecting to 'Realtek AmebaZ' on /dev/ttyUSB0 @ 1500000
    I: Reading Flash (8 MiB)
    $ ls -l solis-s3-firmware-1012f.bin
    8388608 # file size should be exactly this, otherwise something has gone wrong
    
  10. Flashing the ESPHome image (replacing stock AliOS 2ndboot and main app altogether) is as simple as
    $ ltchiptool flash write -d /dev/ttyUSB0 solis-emw3080.uf2
    

After flashing, you can reconnect the S3 WiFi stick to the inverter and the status data will magically appear in Home Assistant. For subsequent updates you can simply OTA-upload the firmware via the ESPHome addon.

⚠️ Warning: Obviously writing to the flash memory is dangerous and may permanently damage your device. Be careful and keep children away.

⚠️ It is recommended to use a good FTDI FT232RL USB serial adapter for dumping and flashing. Other adapters may have problems with the required high transfer rate. In some cases, the serial adapter or USB port does not supply enough power to flash the stick, then try a different adapter or USB port.

💡 This integration uses a patched version of the ArduinoCore-API. This workaround is necessary until libretiny-eu/libretiny#154 is fixed.

💡 Matching the EMW3080 datasheet, one should actually use the generic-rtl8710bn-2mb-788k board profile for LibreTiny. But since the Solis WiFi stick has a special 8MB version of the MCU with an OTA address of 0x100000, the not exactly matching profile generic-rtl8710bx-4mb-980k is used here, manually setting the MCU type and frequency in the PlatformIO options to the correct value.

Solis Modbus Register Map and RS-485 documentation

Solis products feature (at least) two different Modbus register maps, the ESINV (energy storage inverter) map mostly uses registers in the 3xxxx (ten-thousands) range and the INV (inverter) map uses the 3xxx (thousands) range. It is probably a good practice (not thoroughly tested) to query register 35000 ("inverter type definition") and act according to the first two decimal places of the read value (the documentation says: "high 8 bit means protocol version, low 8 bit means inverter model", but I think this is only correct if you interpret it as some kind of 'decimal bits'):

For the INV 3xxx Register Map, you'll need to subtract offset 1 from addresses before transmitting on the bus (see explanation in section 5.3 of the document).

Dr. Brian Coghlan initially translated the ESINV-Modbus inverter communication protocol from chinese to english in 2018, but it now seems to me to have been superseded by the official versions from Solis linked above.

Misc

Credits

ginlong-solis's People

Contributors

air-fuel-ratio avatar belaial avatar hn avatar nextguyover avatar thegroundzero avatar tomjones1977 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

ginlong-solis's Issues

High values for Active Power

Hi,

I have an Solis RHI-5K-48ES-5G, and I'm using a wifi stick flashed with the latest firmware (as discussed here), and I'm having these strange values for "Active Power":
image.

I can try to templatize this to remove these peaks, but was wondering if anyone else has seen this as well?

Thanks,
Erwin

Synchronisation intervl

Do you think it would be possible to reduce the data synchronisation interval? At the moment the data is updated every minute. I'd like to go down to 2 seconds for certain sensors. Do you have any ideas?
Thanks

Set the MCU to UART boot mode (pull TX pin low during boot)

Hi

Not an issue with the project or the code but asking here anyway in case someone else wonders and can look up this ticket.

"Set the MCU to UART boot mode (pull TX pin low during boot)"

I am not familiar what it means to pull a pin low, I am using a USB to serial adapter and can read the boot process just fine with a speed of 115200, however to enter into "Set the MCU to UART boot mode" I need to pull the TX pin low, could someone explain how that is done?

Maybe it can't be performed with a regular cheap USB to Serial adapter?

Compilation fails with latest LibreTiny

Just as a test I tried to compile the firmware with the latest version (when writing this - v1.2.0) of LibreTiny and got the following error

python3 -m esphome compile solis-esphome-emw3080.yaml
INFO ESPHome 2023.8.0-dev
INFO Reading configuration solis-esphome-emw3080.yaml...
Failed config

libretiny: [source solis-esphome-emw3080.yaml:44]
  
  The LibreTiny component is now split between supported chip families.
  Migrate your config file to include a chip-based configuration, instead of the 'libretiny:' block.
  For example 'bk72xx:' or 'rtl87xx:'.
  board: generic-rtl8710bx-4mb-980k
  framework: 
    version: latest

I guess some modifications are needed to make this project compatible with latest LibreTiny.

Solis inverter type definition = 0x0000 (S5-GR3P15K)

Thanks for the comprehensive code and documentation on this.

I have a S5-GR3P15K 3 phase Solis inverter and after following your excellent guide and building a ESP8266 logger I have Solis inverter type definition = 0x0000 outputted to the serial console. Does this mean that my inverter isn't being seen or that it's not currently supported?

If someone could point me in the right direction on how to start debugging this I would love to be able to try and get my inverter supported.

Solis smart meter support

I cant see anything relating to the smart meter, does this support reading from the smart meter plugged into the inverter?

Crash after WiFi scan with "RTL8195A Hard Fault Error" with LT 1.5.0

Hi again, long time no see :)

So I read that there was a new way to flash the stick via ESPHome, figured why not.... and this is probably where I made a mistake.

I read up on all instructions and ignored the manual flashing part, since my stick was already running custom firmware and was reachable via IP I figured I could just flash the stick via OTA directly instead of doing it manually via serial first.

I put together a configuration, re-checked everything and figured it was all good, validated the config and hit install via wireless, all looked good but when a few minutes passed I figured something was wrong.... I took the stick inside to see what it was doing and it's just boot looping with the following output

ROM:[V0.1]                                                                   
FLASHRATE:4                                                                  
BOOT TYPE:0 XTAL:40000000                                                    
IMG1 DATA[1128:10002000]                                                     
IMG1 ENTRY[800053d:100021ef]                                                 
IMG1 ENTER                                                                   
CHIPID[000000ff]                                                             
read_mode idx:2, flash_speed idx:2                                           
calibration_result:[1:19:13][3:15]                                           
calibration_result:[2:21:11][1:15]                                           
calibration_result:[3:0:0][ff:ff]                                            
calibration_ok:[2:21:11]                                                     
FLASH CALIB[NEW OK]                                                          
OTA2 ADDR[8100000]
OTAx SELE[f8000000]
OTA2 USE
OTA2 SIGN[35393138:31313738]
IMG2 DATA[0x81a80c0:4496:0x10005000]
IMG2 SIGN[RTKWin(10005008)]
IMG2 ENTRY[0x10005000:0x81361ad]
BOOT_FLASH_RDP RDP enable 
RDP bin decryption Failed!
checksum_ipsec = 0x4e784fc0, checksum_rdp_flash = 0xfd90f7a6
System_Init1
System_Init2
I [      0.000] LibreTiny v1.5.0 on generic-rtl8710bx-4mb-980k, compiled at Feb 22 2024 18:08:06, GCC 10.3.1 (-Os)
[I][logger:403]: Log initialized
[C][ota:483]: There have been 1 suspected unsuccessful boot attempts.
[D][lt.preferences:104]: Saving 1 preferences to flash...
[D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[I][app:029]: Running through setup()...
[C][uart.lt:049]: Setting up UART...
[C][switch.gpio:011]: Setting up GPIO Switch 'led_orange_com'...
[D][switch:016]: 'led_orange_com' Turning OFF.
[D][switch:055]: 'led_orange_com': Sending state OFF
[D][switch:016]: 'led_orange_com' Turning OFF.
[C][switch.gpio:011]: Setting up GPIO Switch 'led_green_net'...
[D][switch:016]: 'led_green_net' Turning OFF.
[D][switch:055]: 'led_green_net': Sending state OFF
[D][switch:016]: 'led_green_net' Turning OFF.
[C][switch.gpio:011]: Setting up GPIO Switch 'wdt_reset'...
[D][switch:016]: 'wdt_reset' Turning OFF.
[D][switch:055]: 'wdt_reset': Sending state OFF
[D][switch:016]: 'wdt_reset' Turning OFF.
[D][binary_sensor:034]: 'button_reset': Sending initial state OFF
[C][wifi:038]: Setting up WiFi...
[C][wifi:051]: Starting WiFi...
[C][wifi:052]:   Local MAC: 80:A0:36:A7:F7:1F
interface 0 is initialized
                          interface 1 is initialized

Initializing WIFI ...
WIFI initialized
                [D][wifi:459]: Starting scan...
RTL8195A[HAL]: Hard Fault Error!!!!
RTL8195A[HAL]: R0 = 0x1b9
RTL8195A[HAL]: R1 = 0x1
RTL8195A[HAL]: R2 = 0x0
RTL8195A[HAL]: R3 = 0x9
RTL8195A[HAL]: R12 = 0x1b9
RTL8195A[HAL]: LR = 0x8110bad
RTL8195A[HAL]: PC = 0x1eb8dcf0
RTL8195A[HAL]: PSR = 0x80000000
RTL8195A[HAL]: BFAR = 0xe000ed38
RTL8195A[HAL]: CFSR = 0x20000
RTL8195A[HAL]: HFSR = 0x40000000
RTL8195A[HAL]: DFSR = 0x0
RTL8195A[HAL]: AFSR = 0x0
RTL8195A[HAL]: PriMask 0x0
RTL8195A[HAL]: BasePri 0x0
RTL8195A[HAL]: SVC priority: 0x00
RTL8195A[HAL]: PendSVC priority: 0xf0
RTL8195A[HAL]: Systick priority: 0xf0

And that just repeats over and over again

If I try to pull TX pin 21 low during boot to re-flash the stick via serial it just won't work

python2 rtltool2.py -p /dev/ttyUSB0 gf
Connecting...
Flash Status value: 0x15

python2 rtltool2.py -p /dev/ttyUSB0 wf 0xb000 solis-emw3080-0x00B000.bin 
Connecting...
Write Flash data 0x0800b000 to 0x080b424c from file: solis-emw3080-0x00B000.bin ...
Error: Write Flash!

I see that the flash status is 0x15 and not 0x40 as in the guide, quite sure I did not see this before when we did all the troubleshooting back in last year before I started to use a better serial adapter and I am using the same good adapter now so that should not be the issue.

Any ideas what could be wrong? Did I finally manage to kill the stick with my curiosity....

Can't upload to S3

I have an error when uploading the firmware. It start flashing, then after some time, I am getting an error : ValueError: Failed to write to 0x800B000

Here is the log :

➜  libretiny-esphome git:(platform/libretuya) ✗ python3.10 -m esphome upload solis2-stick.yaml --device
/dev/tty.SLAB_USBtoUART
INFO Reading configuration solis2-stick.yaml...
****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
Obsolete PIO Core v6.1.6 is used (previous was 6.1.7)
Please remove multiple PIO Cores from a system:
https://docs.platformio.org/en/latest/core/installation/troubleshooting.html
****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
Processing solis2-stick (board: generic-rtl8710bx-4mb-980k; framework: arduino; platform: libretiny)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Configuring upload protocol...
AVAILABLE: uart
CURRENT: upload_protocol = uart
Looking for upload port...
Using manually specified: /dev/tty.SLAB_USBtoUART
Uploading .pioenvs/solis2-stick/firmware.uf2
|-- Detected file type: UF2 - esphome 2023.5.0-dev
|-- Connecting to 'Realtek AmebaZ' on /dev/tty.SLAB_USBtoUART @ 1500000
|   |-- Success! Chip info: Realtek RTL87xxB
|-- Writing '.pioenvs/solis2-stick/firmware.uf2'
|   |-- esphome 2023.5.0-dev @ 2023-05-23 00:27:42 -> generic-rtl8710bx-4mb-980k
|-- ValueError: Failed to write to 0x800B000
|   |-- File "/usr/local/lib/python3.10/site-packages/ltchiptool/soc/ambz/flash.py", line 147, in flash_write_raw

My chip looks the same as yours :
IMG_7466

Stick won't connect back to WiFi

First of I found this issue libretiny-eu/libretiny#113 but that seems to be resolved or at least closed so not sure if this is a new issue or the same.

Regarding versions and so on running on the stick I just got my stick to work last night (07 July 2023) so everything is the latest there is to my knowledge following the guide here https://github.com/hn/ginlong-solis#replacing-the-main-application

The stick worked perfect last night for a few hours when I was testing things out, this morning when I woke up everything was still working, the stick goes offline during the night on my inverter but that is expected since the inverter powers down the COM-port, I know this from running this project https://github.com/incub77/solis2mqtt before getting my stick re-flashed, I had to use external power on the Pi to keep it running during the night.

This morning I tested more things, when I powered down a access point I have in the house all of a sudden I lost the Solis stick, I waited a few minutes expecting it to reconnect back but it did not, I powered on the access point again and waited but the stick did not reconnect. I have now power cycled the stick 4 times, waited 10-20 minutes in between but it has not reconnected.

I don't have easy serial access to the stick right now since I assembled the case again but I guess that is the next step to see what is going on unless someone have some other tips for me.

The only thing that worries me is this line I noticed during boot of the Solis stick

[W][ota:102]: Last Boot was an unhandled reset, will proceed to safe mode in 7 restarts

I saw this number go down every time I booted the stick with serial connected so.... maybe the stick is stuck in safe mode now?

..... Now all of a sudden it just works again.....

So.... during the time I was writing this ticket (20 minutes maybe since last stick power cycle) the stick just all of a sudden connected back after 2927 seconds (had a rolling ping towards it that is how I know the number of second, it was rebooted several times during these 2927 seconds so why it decided to work now I have no clue...)

I will post this ticket anyway now in case there is some discussion to have regarding this, if this is excepted behavior I guess we can just close this ticket.

Exceedconn EC04681-2014-BF connector 3D models

I recently did a writeup of my own implementation of ESPHome on my Solis PV system, where I 3D modelled and printed the Exceedconn EC04681-2014-BF connector.

Since this is a much cheaper alternative to purchasing the connector, or purchasing a new Wi-Fi stick altogether, I thought this might be a useful resource to reference here as well.

I have made download links for 3D models of the connector (and an enclosure) available at the blogpost above (plus instructions for 3D printing and forming the contacts for the connector). If you think this would be useful, feel free to link the blogpost from the readme.

Alternatively, I'm also happy for you to include the 3D model files directly on this repo with attribution, let me know if you would like me to make a PR.

Thanks again for the work you've done with reverse engineering this, it has been very useful 🙂.

Red led , impossible to re flash

I have 2 solis sticks.
The first one i flashed sucessful , have connection and see it in HA

i flashed the second one , this one came also in HA online , but after few minutes it came offline and only the red led light up.

if i put it on the serial usb i dont see anything or can not flash
Is this device bricked ? Other solution ?

Values Unknown : Inverter type definiton : 2030

hello ,

after succesful flashing my Wifi stick , i receive for my second inverter unknown values.
The only value i see is Inverter type definition 2030

Is this type supported by the custom firmware or how to solve ?

S5-GR1P5K ModBus problems with holding registers

I'm currently using the ESPHome config provided here with a S5-GR1P5K inverter. All the 3000+ read registers are working correctly, all values are being read. However, I am not able to read from 3000+ holding registers.

E.g. when attempting to read the time (holding reg 3000-3005, so 3000-1 = 2999 = 0xBB7), I get the following error:

[W][modbus_controller:030]: Modbus device=1 set offline
[D][modbus_controller:043]: Modbus command to device=1 register=0xBB7 countdown=0 no response received - removed from send queue
[W][modbus_controller:064]: Modbus device=1 back online

I'm wondering whether the register range for settings is possibly different for my model of inverter? I've also tried some of the other possible ranges for time from the documentation PDFs in the readme. I tried 33022-33027, which is the expected range for an ESINV, but this also returns the same error. Range 43000-43005 actually returns data, but the data here doesn't seem correct for a timestamp.

Values in Home Assistant becomes unavalible for a split second

Hi,

I have only spent about 1,5 days running this project on my Solis stick now but one of my findings so far is that about every 15 minutes or so the readings in Home Assistant for a split second becomes Unavailable and then goes back just as fast, I have tried to get a recording of this to show for demonstration purposes but no luck yet with that.

This seems to happen on most if not all the values I read out but the value I know it happens for and that causes issues for me is Active Power, the reason I know this is that I spent hours trying to figure out why one of my automation's stopped working when I changed from my Pi running https://github.com/incub77/solis2mqtt to reading stuff out with the Solis stick, the automation is simple, if Active Power is above 750W for 20 minutes it should turn on a power outlet, I noticed this had not happened for many hours of Active Power being greater than 750W, when I was looking at this I noticed with my eyes how Active Power all of a sudden was Unavailable and then back to whatever the actual power was, since this seems to happen around every ~15 minutes or so my automation of 20 minutes won't trigger since the value has not been above 750 for 20 minutes with these small Unavailable breaks in between, I could just lower the timer on my automation and be done with it but I figured it's best to report it if it might be something that could be solved.

I am 99% sure this is not related to my reportings regarding WiFi here #12 since I see the stick online via ping at the same time as values becomes Unavailable.

The only "proof" I can show of this issue now is based on the "Logbook" in Home Assistant, however for some reason the Active Power does not get logged there so I will show history of the value for Country Code instead

image

Also here it can be seen as small gaps in the timeline

image

Now this is for Country Code as and example, even more values does this at the same time

image

And then they return within the same second or 1-2 seconds after.

Any ideas what could be causing this?
I can just lower the timers on my automation but hopefully we can figure out the issue and resolve it.

Replacing the main application fails

Hello @hn,
I'm trying to flash esphome image to the Solis S3 WiFi Data Logging Stick (3rd gen). I followed your instructions, but the very last step fails with just a generic error:

user@linux-pc:~/rtltool/libretiny-esphome$ python3 -m esphome upload solis-inv-esphome.yaml --device /dev/ttyUSB0
INFO Reading configuration solis-inv-esphome.yaml...
Processing solis-inv (board: generic-rtl8710bx-4mb-980k; framework: arduino; platform: libretiny)

Configuring upload protocol...
AVAILABLE: uart
CURRENT: upload_protocol = uart
Looking for upload port...
Using manually specified: /dev/ttyUSB0
Uploading .pioenvs/solis-inv/firmware.uf2
|-- Detected file type: UF2 - esphome 2023.5.0-dev
|-- Connecting to 'Realtek AmebaZ' on /dev/ttyUSB0 @ 1500000
|   |-- Success! Chip info: Realtek RTL87xxB
|-- Writing '.pioenvs/solis-inv/firmware.uf2'
|   |-- esphome 2023.5.0-dev @ 2023-04-29 22:50:42 -> generic-rtl8710bx-4mb-980k
|-- ValueError: Failed to write to 0x800B000
|   |-- File "/home/user/.local/lib/python3.10/site-packages/ltchiptool/soc/ambz/flash.py", line 147, in flash_write_raw
*** [upload] Error 1

The stick is in bricked state after flashing fails. I managed to restore the stock firmware by running (MCU is in UART boot mode):

user@linux-pc:~/rtltool$ python3 rtltool.py -p /dev/ttyUSB0 wf 0x8000000 solis-s3-firmware-1012f.bin 
Connecting...
Write Flash data 0x08000000 to 0x08800000 from file: solis-s3-firmware-1012f.bin ...
Traceback (most recent call last):
  File "/home/user/rtltool/rtltool.py", line 523, in <module>
    main(*sys.argv[1:])
  File "/home/user/rtltool/rtltool.py", line 388, in main
    for _ in gen:
TypeError: 'bool' object is not iterable

Even though I get this error, the stick seems to work fine with the stock firmware.

Any ideas what I might be doing wrong?

solis-rhi-3k-48es-5g support

Dear Hajo,

your code is genius. Thanks for this. Surely beyond my own skills..
Planning to fork your code and add MQTT - at least MQTT is running already in mine testbed successful

I realized my Solis Inverter (solis-rhi-3k-48es-5g) does not get detected, hence the script did not work as expected:
Register 35000 delivers: 2031--- 1 phase LV AC Couple energy storage inverter

Made those changes to accomodate:

case SDT_ITYPE:  /* Solis inverter type definition, switches lookup table */
    {
      char buf[2 + 4 + 1];
      unsigned int regvalue = modbus.getResponseBuffer(0);
      
      sprintf(buf, "0x%04X", regvalue);
      Serial.print(buf);


      if ((regvalue / 100) == 10) {           /* RS485_MODBUS (INV-3000ID EPM-36000ID) inverter protocol */
        solis = solisINV;
      } else if ((regvalue / 100) == 20) {    /* RS485_MODBUS (ESINV-33000ID) energy storage inverter protocol */
        solis = solisESINV;
      } else if ((regvalue) == 8241) {    /* RS485_MODBUS solis-rhi-3k-48es-5g */
        solis = solisESINV;
         
      }
    }
    break;

Reading of Serial somehow fails as well. Still looking into this and will you keep updated.

Again, thanks for this execellent piece of work

thanks

Backup the stock firmware fails

Trying to backup the stock firmware fails for me, to the best of my knowledge I have followed the instructions so need to ask for help...

I am quite sure I am able to "Set the MCU to UART boot mode (#9)" since the stick does not start flashing all it's LEDs, only power LED is lit (if the stick boots regularly all the LEDs light up) if I try and read the stick with

sudo screen /dev/ttyUSB0 115200

I only get a continuous "spamming line" of "????????????" so I guess the baud rate might be wrong in this mode, I have tried 9600 also but that gives nothing.

Once in the mode where only the power LED is lit I try to run

./rtltool.py -p /dev/ttyUSB0 rf 0x8000000 0x800000 solis-s3-firmware-1012f.bin

But I get the following error

./rtltool.py -p /dev/ttyUSB0 rf 0x8000000 0x800000 solis-s3-firmware-1012f.bin File "/home/test/Desktop/solis/./rtltool.py", line 56 print 'Error: Open %s, %d baud!' % (port, baud) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?

I am using the rtltool linked in the guide ( https://github.com/pvvx/RTL0B_SDK/blob/master/mkb/rtltool.py )

Any idea what I could be doing wrong? I have also tried with the stick not connected and the same error appears so I guess there is something wrong with my rtltool.py or the arguments I am trying to pass.

ESPHome 2024.5.0 linker error: .ram_heap.data will not fit in region BD_RAM

Hello

in receive next error when i compile , someone ?,
Someone who can help ?

/data/cache/platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: .pioenvs/solis-emw3080/raw_firmware.ota1.elf section .ram_heap.data' will not fit in region BD_RAM'
/data/cache/platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: region `BD_RAM' overflowed by 224 bytes

collect2: error: ld returned 1 exit status

|-- Generated file not found: .pioenvs/solis-emw3080/raw_firmware.ota1.elf
*** [.pioenvs/solis-emw3080/raw_firmware.elf] Error 1

Not getting data from RHI-3P10K-HVES-5G

Hello,

I stumbled accross this neat project, because I want to integrate my RHI-3P10K-HVES-5G into my home assistant and get real time data instead of 5-6 min summaries via Alibaba cloud.

I flashed esphome on a d1_mini_pro and integrated it with home assistant. That part works. I don't get any data from the inverter though.

The only response I got, is that it set the inverter type to 2060.

Am I on the right path here, what could I be missing?

Best,
Matthias

Can't build firmware with latest instructions

Hi,

I was going to build the latest firmware to include the fix for modbus getting desynchronised, however I must be doing something wrong.

I started of fresh from the beginning, all works until this line

wget https://raw.githubusercontent.com/hn/ginlong-solis/libretiny-ringbuffer-workaround.diff

That throws a 400: Invalid request, was fixed with using this link instead for me (notice the /master/ part in the working link)

https://raw.githubusercontent.com/hn/ginlong-solis/master/libretiny-ringbuffer-workaround.diff

However later on in the guide when I am about to apply the fix contained in libretiny-ringbuffer-workaround.diff I get the following


~/.platformio$ patch -p1 < libretiny-ringbuffer-workaround.diff
can't find file to patch at input line 6
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Workaround for the Arduino ringbuffer, so that it can no longer have a permanently
|inconsistent state. Implemented by removing the redunant storage of the buffer
|state in three variables.
|--- a/packages/framework-arduino-api/api/RingBuffer.h	2023-08-12 13:07:59.074806708 +0200
|+++ b/packages/framework-arduino-api/api/RingBuffer.h	2023-08-11 15:35:11.847630525 +0200
--------------------------
File to patch:

I tried looking for the file

Screenshot from 2023-08-15 09-48-53

I also tried to manually find the file but I don't even have the framework-arduino-api folder

~/.platformio/packages$ ll
total 44
drwxrwxr-x 11 user user 4096 Aug 15 09:32  ./
drwxrwxr-x  5 user user 4096 Aug 15 09:36  ../
drwx------  7 user user 4096 Aug 15 09:31  library-flashdb/
drwx------  4 user user 4096 Jul  7 22:14  library-freertos/
drwx------  7 user user 4096 Aug 15 09:31  library-freertos-port/
drwx------  7 user user 4096 Jul  7 22:14  library-lwip/
drwx------  6 user user 4096 Aug 15 09:31  library-printf/
drwx------  6 user user 4096 Aug 15 09:31  library-uf2ota/
drwx------  8 user user 4096 Aug 15 09:32  toolchain-gccarmnoneeabi/
drwx------ 10 user user 4096 Jul 17 12:00 '[email protected]'/
drwx------  3 user user 4096 Jul  7 22:14  tool-scons/

Am I missing something here? Sorry in advance if I am doing something obviously wrong...

Limited output power

Hi, I build the configuration for the esp version with an ESP32. I get al the data but it is not possible to limit the output power from my solis S6-GR1P4K converter.

In HA is a message: this entity is switch off. Is there a way to enable this function?
Screenshot_2024-05-12-10-28-14-24_c3a231c25ed346e59462e84656a70e50

Commit b25f978 prohibiting reboot if WiFi is not connected?

Hi, last night I switched out my Raspberry Pi running https://github.com/incub77/solis2mqtt for the modified Solis stick, I waited until after midnight since I did not want to mess up my graphs in HA.

This morning I woke up hoping to see everything work (Inverter had the COM-port down when I plugged in the stick so it did not boot up until later when I was asleep) to my surprise tho the stick was offline when I woke up, I went out to check on it and it had power but no connection, I pressed the reset button on the back of the stick and it then booted up and connected just fine.

I later did some quick tests with this complied and flashed (used 3 minutes to put it under the interval: 280s in commit b25f978,

wifi:
  reboot_timeout: 3min

But it seems the stick does not reboot when WiFi is not connected, could this somehow be related to the commit b25f978 which fixed the hardware watchdog we had issues with before?

I was asked to check this before (see below), I did however not test what would happen in WiFi was not connected, only that it stopped the reboot every 15 minutes due to the hardware watchdog.

@Belaial Can you please check b25f978 . It sends a 100ms 'high' pulse every just under 5 minutes to reset the WDT, but only if WiFi is connected (so it should catch WiFi reconnect problems as well).

I only have one Solis S3 stick and it's now connected to the inverter so don't want to remove it since it's collecting data (can remove it after midnight if needed for more testing), do you happen to have more than one stick @hn ? Was thinking if you could do a quick test to see if b25f978 interferes with the reboot if WiFi is not connected.

I don't see how b25f978 could interfere with the reboot if not connected to WiFi but need to ask since I'm out of ideas..

EDIT

(On vacation so might reply very slow in case some testing is needed)

ModBus CRC check fails / UART traffic gets desynchronised

Sometimes ModBus traffic fails with CRC errors after several hours of correct operation:

[W][modbus:109]: Modbus CRC Check failed! 8498!=10
[W][modbus:109]: Modbus CRC Check failed! 4F02!=10
[W][modbus:109]: Modbus CRC Check failed! 83D2!=10

Once these errors have started, the system is desynchronised and only a reboot will fix the problem.

This topic has been discussed in various places and I would like to collect all the information here.

Battery SOC view and set

Is it possible to view/set the battery SOC from Home Assistant? From the sccreenshots it appears to only be voltage and current.

Is it possible to view the kWh that has been sent/received to/from the battery?

Serial number format

180 102 0 22 x xx xxxx
110  F2 2 21 x xx xxxx
110  F2 2 19 x xx xxxx 
180 504 0 xx x xx xxxx

Regarding serial numbers, it seems the digits for models have been extended by one digit, 102 is shown as version in the Soliscloud for a S6-GR1P1.5K-M-DC where as F2 is shown for a RHI-4.6K-48ES-5G-EU as well as RHI-4.6K-48ES (4G !, maybe distinguished by product date cut-off?). 504 is a S5-GR3P8K,

Meter EnergyP value, value read from smart meter

How do i get the inverters Meter EnergyP value to read? This value which appears on the inverters LCD screen looks like the value being read from the acr10r-d16te smart meter. modbus documented here: https://www.acrelenergy.com/uploads/file/single-phase-acr10r-d16te-manual.pdf.

The inverters "Internal EPM" mode is set to consumption monitoring.

Inverter model: S5-GR1P5K

[02:40:15][I][app:100]: ESPHome version 2024.4.2 compiled on Jul 8 2024, 00:32:24
[02:40:15][C][wifi:580]: WiFi:
[02:40:15][C][wifi:408]: Local MAC: [redacted]
[02:40:15][C][wifi:413]: SSID: [redacted]
[02:40:15][C][wifi:416]: IP Address: 10.0.2.119
[02:40:15][C][wifi:419]: BSSID: [redacted]
[02:40:15][C][wifi:421]: Hostname: [redacted]
[02:40:15][C][wifi:423]: Signal strength: -53 dB ▂▄▆█
[02:40:15][C][wifi:427]: Channel: 1
[02:40:15][C][wifi:428]: Subnet: 255.255.255.0
[02:40:15][C][wifi:429]: Gateway: 10.0.2.1
[02:40:15][C][wifi:430]: DNS1: 10.0.2.1
[02:40:15][C][wifi:431]: DNS2: 0.0.0.0
[02:40:15][C][logger:166]: Logger:
[02:40:15][C][logger:167]: Level: DEBUG
[02:40:15][C][logger:169]: Log Baud Rate: 115200
[02:40:15][C][logger:170]: Hardware UART: UART0
[02:40:15][C][uart.arduino_esp8266:118]: UART Bus:
[02:40:15][C][uart.arduino_esp8266:119]: TX Pin: GPIO12
[02:40:15][C][uart.arduino_esp8266:120]: RX Pin: GPIO14
[02:40:15][C][uart.arduino_esp8266:122]: RX Buffer Size: 256
[02:40:15][C][uart.arduino_esp8266:124]: Baud Rate: 9600 baud
[02:40:15][C][uart.arduino_esp8266:125]: Data Bits: 8
[02:40:15][C][uart.arduino_esp8266:126]: Parity: NONE
[02:40:15][C][uart.arduino_esp8266:127]: Stop bits: 1
[02:40:15][C][uart.arduino_esp8266:131]: Using software serial
[02:40:16][C][modbus:143]: Modbus:
[02:40:16][C][modbus:145]: Send Wait Time: 300 ms
[02:40:16][C][modbus:146]: CRC Disabled: NO
[02:40:16][C][modbus.number:083]: modbus.numberModbus Number 'Limit output power'
[02:40:16][C][modbus.number:083]: modbus.number Icon: 'mdi:percent'
[02:40:16][C][modbus.number:083]: modbus.number Unit of Measurement: '%'
[02:40:16][C][modbus_controller.select:009]: modbus_controller.selectModbus Controller Select 'Working Mode'
[02:40:16][C][modbus_controller.select:009]: modbus_controller.select Icon: 'mdi:cog-outline'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Normal'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Initializing'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Grid off'
[02:40:16][C][modbus_controller.binary_sensor:009]: Device Class: 'problem'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Fault to stop'
[02:40:16][C][modbus_controller.binary_sensor:009]: Device Class: 'problem'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Standby'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Derating'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Limitating'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Grid surge'
[02:40:16][C][modbus_controller.binary_sensor:009]: Device Class: 'problem'
[02:40:16][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Working status Fan fault'
[02:40:16][C][modbus_controller.binary_sensor:009]: Device Class: 'problem'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Active Power'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'power'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'W'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Total DC output power'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'power'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'W'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Total energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'total_increasing'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'kWh'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Energy this month'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'total_increasing'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'kWh'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Energy last month'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'total_increasing'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'kWh'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Energy today'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'total_increasing'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'kWh'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Energy last day'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'energy'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'total_increasing'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'kWh'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'DC voltage 1'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'voltage'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'V'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'DC current 1'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'current'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'A'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'DC voltage 2'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'voltage'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'V'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'DC current 2'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'current'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'A'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'AC voltage'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'voltage'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'V'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Inverter temperature'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Grid frequency'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'frequency'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: 'measurement'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: 'Hz'
[02:40:16][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 2
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'Product model'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:factory'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'DSP software version'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:chip'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'LCD software version'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:chip'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'Country standard code'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:earth'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'Inverter SN'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:numeric'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'inverter_rtc'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:clock-digital'
[02:40:16][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'Inverter type definition'
[02:40:16][C][modbus_controller.text_sensor:012]: Icon: 'mdi:chip'
[02:40:16][C][homeassistant.time:010]: Home Assistant Time:
[02:40:16][C][homeassistant.time:011]: Timezone: 'UTC0'
[02:40:16][C][factory_reset.button:011]: Factory Reset Button 'Restart with factory default settings'
[02:40:16][C][factory_reset.button:011]: Icon: 'mdi:restart-alert'
[02:40:16][C][restart.button:017]: Restart Button 'Reboot device'
[02:40:16][C][captive_portal:088]: Captive Portal:
[02:40:16][C][mdns:115]: mDNS:
[02:40:16][C][mdns:116]: Hostname: [redacted]
[02:40:16][C][ota:096]: Over-The-Air Updates:
[02:40:16][C][ota:097]: Address: [redacted].local.lan:8266
[02:40:16][C][ota:100]: Using Password.
[02:40:16][C][ota:103]: OTA version: 2.
[02:40:16][C][api:139]: API Server:
[02:40:16][C][api:140]: Address: [redacted].local.lan:6053
[02:40:16][C][api:142]: Using noise encryption: YES
[02:40:16][C][wifi_signal.sensor:009]: WiFi Signal 'WiFi Signal'
[02:40:16][C][wifi_signal.sensor:009]: Device Class: 'signal_strength'
[02:40:16][C][wifi_signal.sensor:009]: State Class: 'measurement'
[02:40:16][C][wifi_signal.sensor:009]: Unit of Measurement: 'dBm'
[02:40:17][C][wifi_signal.sensor:009]: Accuracy Decimals: 0
[02:40:17][C][modbus_controller:298]: ModbusController:
[02:40:17][C][modbus_controller:299]: Address: 0x01

ltchiptool usage, download mode, wiring

Hi

I'm attempting to flash my S3-WIFI-ST stick but I can´t even get serial comms to works.

I hooked up the module to my FTDI adapter.
Set the adapter to 3.3V, tried 5V as well*. (this says 3V, this says 5V?)

  • On 5V, green LED turns on and blinks slowly if TX is pulled low, orange blinks rapidly


VCC -> 3.3V/5V
TX -> RX
RX -> TX
GND -> GND
(Jumper between TX and GND)

dmesg output

[ 5325.135580] usb 1-4: USB disconnect, device number 10
[ 5364.899209] usb 1-4: new full-speed USB device number 11 using xhci_hcd
[ 5365.321499] usb 1-4: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 5365.321506] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5365.321508] usb 1-4: Product: FT232R USB UART
[ 5365.321510] usb 1-4: Manufacturer: FTDI
[ 5365.321512] usb 1-4: SerialNumber: A50285BI
[ 5365.350420] BPF: 	 type_id=138692 bits_offset=0
[ 5365.350425] BPF:  
[ 5365.350426] BPF: Invalid name
[ 5365.350428] BPF: 
[ 5365.350429] failed to validate module [usbserial] BTF: -22

Of course ltchuptool can´t identify the correct serial port.

Stick has a MXCHIP EMW3080-E. Firmware version 00010186
I'm working on Pop!_OS (Linux 6.8.0-76060800daily20240311-generic #202403110203~1711393930~22.04~331756a SMP PREEMPT_DYNAMIC Mon M x86_64 x86_64 x86_64 GNU/Linux)

Inverter type (register 35000) and model type database

To be able to determine the inverter type automatically, the exact content of ModBus register 35000 is important. There seem to be different interpretations of the documentation, so it would be interesting to collect as many register values as possible here to create a robust detection logic.

If you want to contribute, just post here:

Inverter type as printed on the unit:
Type definition (reg 35000):
Model type (reg 3000 for INV, reg 33000 for ESINV):

Please pay attention to whether the value is hexadecimal or decimal, this seems to be an inconsistency.

Problems with wemos/esphome & Solis RHI-5K-48ES-5G

Hi,

First of all: thank you for making this possible, and for all the work that you have put in this! I don't like the need of pulling my data from the ginlong servers, and this projects would fit all my needs.

I've set up a wemos D1 device using ESPHome as indicated in the readme, device_base solis-modbus-esinv.yaml. The RX/TX lights of the RS485-to-serial adapter are blinking. However, I can't get this to work: the state of all sensors is "NA" and I'm getting the following from the logs:

[D][modbus_controller:040]: Modbus command to device=1 register=0x8119 countdown=0 no response received - removed from send queue [D][modbus_controller:040]: Modbus command to device=1 register=0x8121 countdown=0 no response received - removed from send queue [D][modbus_controller:040]: Modbus command to device=1 register=0x8131 countdown=0 no response received - removed from send queue [D][modbus_controller:040]: Modbus command to device=1 register=0x8137 countdown=0 no response received - removed from send queue [D][modbus_controller:040]: Modbus command to device=1 register=0x8161 countdown=0 no response received - removed from send queue

I'll be very honest to start off: this whole modbus thing is super new to me and I'm still quite confused about this. Any hints as to what is happening or where to start troubleshooting, would be very much appreciated :)

Thank you in advance!

Kind regards,
Erwin

ESPHome 2024.6.3 - 'ota' requires a 'platform' key but it was not specified.

Small issue, easy fix, would do a pull request but not sure how to do those since I am a github-noob 😄

In ESPHome 2024.6.3 (maybe earlier also) there is a new line needed in

https://github.com/hn/ginlong-solis/blob/master/solis-esphome-emw3080.yaml
https://github.com/hn/ginlong-solis/blob/master/solis-esphome-esp8266.yaml

This

ota:
  password: !secret ota_password

Needs to be this

ota:
- platform: esphome
  password: !secret ota_password

So just add "- platform: esphome" and that should be all as far as I know 👍

Updating firmware

Sorry for the very basic question, but even though I'm familiar with ESPHome and Home Assistant, I've never actually flashed the firmware on any other device!

My understanding is that I need to connect the S3 wifi stick via a serial adapter to my Raspberry Pi and then I can run the commands in the readme. Will the following adapter work?

https://www.amazon.co.uk/dp/B08CRL6KHV?psc=1&ref=ppx_yo2ov_dt_b_product_details

Do I then attach wires between the stick and the serial adapter (TX to TX, RX to RX and GND to GND)?

image

I understand that I will need to connect the TX pin to GND at boot so the firmware can be flashed.

I then think I just type the code into a terminal on the Pi and the stick will be updated with ESPHome firmware that will provide data directly to Home Assistant?

Thanks in advance for any help, I don't want to fry the wifi stick by doing this wrong!

no success with ESPHome and Wemos D1 mini

I try the Wemos D1 mini - variant and got the following output:

... [08:40:47][E][modbus_controller:095]: Modbus error - last command: function code=0x4 register address = 0x8161 registers count=1 payload size=0 ...

Ideas?

Problems with flashing wifi stick (data transfer issues?)

Hi all,

I'm quite used to flashing devices using UART (mostly shelly plugs and sonoff switches) but this wifi stick is giving me more problems that I anticipated :-/

I had the same as user Belaial (from the image here) and I can confirm what kuba2k2 mentioned here: these adapters are apparently not strong enough for the required baudrate. I bought a new one, based on the FT232 and only with that adapter was able to communicate in the download mode, using ltchiptool-v4.10.2.

I compiled the firmware using esphome on my other computer, and tried to flash the firmware.uf2 using the Windows version. However, during upload, I get the following errors:

I: Found new device: COM7 - USB Serial Port - FTDI (0403/6001)
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
E: send error: expected ACK; got b'\x15' for block 2
E: send error: expected ACK; got b'\x15' for block 2
E: send error: expected ACK; got b'\x15' for block 19
E: send error: expected ACK; got b'\x15' for block 19
E: send error: expected ACK; got b'\x15' for block 23
E: send error: expected ACK; got b'\x15' for block 23
...
E: send error: expected ACK; got b'\x15' for block 168
E: send error: expected ACK; got b'\x15' for block 168
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).
I: Transmission successful (ACK received).

I'm not quite sure what these write errors have as a consequence, but I've tried it multiple times and I think the amount of errors differs between some runs. When I read out the terminal during normal boot, it always reboots during the scanning of the wifi:

<RTL8195A>ROM:[V0.1]
FLASHRATE:4
BOOT TYPE:0 XTAL:40000000
IMG1 DATA[1128:10002000]
IMG1 ENTRY[800053d:100021ef]
IMG1 ENTER
CHIPID[000000ff]
read_mode idx:0, flash_speed idx:0
calibration_result:[1:0:0][ff:ff] 
calibration_result:[2:0:0][ff:ff] 
calibration_result:[3:0:0][ff:ff] 

FLASH Calibration Fail!!!
Please set proper flash speed and read mode in SYSTEM DATA!!!

OTA2 ADDR[8100000]
OTAx SELE[ffffffff]
OTA1 USE
IMG2 DATA[0x80b40d0:4520:0x10005000]
IMG2 SIGN[RTKWin(10005008)]
IMG2 ENTRY[0x10005000:0x8041eb1]
BOOT_FLASH_RDP RDP enable 
SYSTEM.bin RDP Empty.
System_Init1
System_Init2
I [      0.000] LibreTiny v1.5.0 on generic-rtl8710bx-4mb-980k, compiled at Feb 29 2024 05:55:03, GCC 10.3.1 (-Os)
[I][logger:395]: Log initialized
[C][ota:473]: There have been 9 suspected unsuccessful boot attempts.
[D][lt.preferences:104]: Saving 1 preferences to flash...
[D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[I][app:029]: Running through setup()...
[C][uart.lt:049]: Setting up UART...
[C][switch.gpio:011]: Setting up GPIO Switch 'led_orange_com'...
[D][switch:016]: 'led_orange_com' Turning OFF.
[D][switch:055]: 'led_orange_com': Sending state OFF
[D][switch:016]: 'led_orange_com' Turning OFF.
[C][switch.gpio:011]: Setting up GPIO Switch 'led_green_net'...
[D][switch:016]: 'led_green_net' Turning OFF.
[D][switch:055]: 'led_green_net': Sending state OFF
[D][switch:016]: 'led_green_net' Turning OFF.
[C][switch.gpio:011]: Setting up GPIO Switch 'wdt_reset'...
[D][switch:016]: 'wdt_reset' Turning OFF.
[D][switch:055]: 'wdt_reset': Sending state OFF
[D][switch:016]: 'wdt_reset' Turning OFF.
[D][binary_sensor:034]: 'button_reset': Sending initial state OFF
[C][wifi:038]: Setting up WiFi...
[C][wifi:051]: Starting WiFi...
[C][wifi:052]:   Local MAC: D0:BA:E4:88:8E:EC
interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...
WIFI initialized
[D][wifi:455]: Starting scan...
<RTL8195A>ROM:[V0.1]
FLASHRATE:4
BOOT TYPE:0 XTAL:40000000
IMG1 DATA[1128:10002000]
IMG1 ENTRY[800053d:100021ef]
IMG1 ENTER
CHIPID[000000ff]
read_mode idx:0, flash_speed idx:0
calibration_result:[1:0:0][ff:ff] 
calibration_result:[2:0:0][ff:ff] 
calibration_result:[3:0:0][ff:ff] 

FLASH Calibration Fail!!!
Please set proper flash speed and read mode in SYSTEM DATA!!!

OTA2 ADDR[8100000]
OTAx SELE[ffffffff]
OTA1 USE
IMG2 DATA[0x80b40d0:4520:0x10005000]
IMG2 SIGN[RTKWin(10005008)]
IMG2 ENTRY[0x10005000:0x8041eb1]
BOOT_FLASH_RDP RDP enable 
SYSTEM.bin RDP Empty.
System_Init1
System_Init2
I [      0.000] LibreTiny v1.5.0 on generic-rtl8710bx-4mb-980k, compiled at Feb 29 2024 05:55:03, GCC 10.3.1 (-Os)
[I][logger:395]: Log initialized
[C][ota:473]: There have been 10 suspected unsuccessful boot attempts.
[D][lt.preferences:104]: Saving 1 preferences to flash...
[D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[E][ota:480]: Boot loop detected. Proceeding to safe mode.
[I][app:029]: Running through setup()...
[C][wifi:038]: Setting up WiFi...
[C][wifi:051]: Starting WiFi...
[C][wifi:052]:   Local MAC: D0:BA:E4:88:8E:EC
interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...
WIFI initialized
[D][wifi:455]: Starting scan...
<RTL8195A>ROM:[V0.1]
FLASHRATE:4
BOOT TYPE:0 XTAL:40000000

I think there is a problem during data transfer, but I've already tried 2 different set of cables, including the one that came with the adapter. Can anyone recommend cables? Or is there an other issue at play?

Thanks in advance,
Erwin

Component modbus_controller took a long time for an operation

This is maybe more of a question than an issue I guess but creating one anyway to make sure.

This morning I flashed the latest possible build with ESPHome and LibreTiny 1.5.1, all works perfect so far for 10 minutes.

Since I now have the stick compiled and monitored via Home Assistant I saw the log output after compile and OTA update and I then noticed this between the readouts of data from the inverter.

[07:57:27][W][component:214]: Component modbus_controller took a long time for an operation (0.12 s).
[07:57:27][W][component:215]: Components should block for at most 20-30ms.

[07:58:25][W][component:214]: Component modbus_controller took a long time for an operation (0.06 s).
[07:58:25][W][component:215]: Components should block for at most 20-30ms.

[07:58:25][W][component:214]: Component modbus_controller took a long time for an operation (0.08 s).
[07:58:25][W][component:215]: Components should block for at most 20-30ms.

[07:58:25][W][component:214]: Component modbus_controller took a long time for an operation (0.12 s).
[07:58:25][W][component:215]: Components should block for at most 20-30ms.

If this is expected warnings just ignore and close this ticket but maybe there is something to tweak to avoid these warnings in the logs?

ltchiptool upload error "Not a valid FlashMode"

Hello,

I successfully dumped the original firmware from the Datalogger Model S3 and have been experimented with various codes using PlatformIO. Uploading codes to the chip has been smooth without any issues.

But, I encountered an error when attempting to flash the firmware file generated using ESPHome as the instructions. As I'm new to ESPHome,
Screenshot_4
I hope this data is enough for troubleshooting.

Thank you!

ESPHome missing sensors versus SolisCloud integration

I'm (currently) not using many sensors that the inverter provides, but I noticed there is a difference between what I used to get from SolisCloud versus what ESPHome now reports.

SolisCloud / ESPHome
SolisCloudESPHome

Notably, I appear to be missing the Solis AC Output Total Power which depicts my solar production, and Solis Battery Power which shows me power flowing to/from the battery.
Unless that's what Total DC output power is supposed to report? It's reporting 0W while I would expect to still be drawing power from my battery as it's still 45% full.
Active Power perhaps? Or does that include solar?

Also, somehow the Solis integration was reporting 2493kWh of Total Energy produced, while ESPHome now "only" reports 2486kWh?
I did, shortly, have a different Solis inverter before it got replaced with my current, so maybe the first only produced 7kWh and the SolisCloud integration is reporting the sum of the 2 although it created 2 devices for the 2 inverters?

MQTT support for RTL87xx boards

A feature request to support publishing Solis inverter metrics to MQTT brokers for RTL87XX boards.

I have Solis S3 WiFi stick with the newer emw3080 pcb and compiling the MQTT client in ESPHome fails:

% esphome compile solis-esphome-emw3080.yaml
INFO ESPHome 2024.6.6
INFO Reading configuration solis-esphome-emw3080.yaml...
Failed config

mqtt: [source solis-esphome-emw3080.yaml:164]

  This feature is only available on ['esp32', 'esp8266', 'bk72xx'].
  broker: 192.168.1.100
  port: 8883

No connection to ESPHome API possible

Hello,
I am using the solis adapter in Home Assistant with the ESPHome add-on and since the update of ESPHome from 2024.6.1 to 2024.6.4 the solis-esphome-esp8266.yaml has issues with the connection to the ESPHome API and does not work properly anymore. The change for the OTA settings I already implemented (adding the additional line with platform: esphome). Information from the log: (I replaced the IP of the adapter with "localIIP"):

"Can't connect to ESPHome API for solis-esphome-esp8266 @ localIP: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2 >, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='localIP', port=6053))]: [Errno 111] Connect call failed ('localIP', 6053) (SocketAPIError) "

Does anyone else experience the same issue with the 2024.6.4 release of ESPHome? Any idea that needs to be changed to get it running back? Only a switch back to ESPHome Version 2024.4.1 brought back the adapter, even with the 2024.6.1 ESPHome Version it was not working anymore.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.