Firmware for Node-MCU?

[kuttikutt]

Hello,

thank you for this interesting description. I actually want to reproduce that, because I also want to keep the Solis WiFi Dongle and just "grab" the data.

You wrote, that "Node-MCU / Wemos or similar ESP8266 or ESP32 device" is needed. What firmware did you flash onto this device?

Maybe Tasmota?

Can you provide some information about that? I guess you set up a MQTT via USB serial? I would try to get the MCU in my LAN via WiFi...

Martin

[grob6000]

Hi Martin,

The firmware for the device is created using 'esphome': https://esphome.io/

Think of it like tasmota - but it has the key difference of building firmware specific for each device, rather than using the one firmware on all your devices.

I'd suggest having a look at the esphome site, it has instructions for installation and flashing there. If you have any questions about this repository, external component and the sample yaml config - please do let me know.

As per 'MQTT via USB serial' - for the inverter end, I provided a schematic for the device, please refer to that. On the other end (where you want the data to go!), you can configure esphome to connect to a MQTT server if you have one already. It also works quite seamlessly with home assistant if you use that (and that's what my sample config file does).

Thanks,
George

[kuttikutt]

Hello and Thanks for the reply.

I'll have a look into it. First task would be to read some data from the inverter ;)

[kuttikutt]

Hello, I'm back ;)

since it was an easy and quick task, I gave the Ginlong API to access Soliscloud a try. It works really well. Actually, I did try this, because I could not find any information about the refresh rate. It's exactly 5 minutes .. so so slow :/

Since you grab the data from the RS485 bus: Does the inverter send some data only every 5 mins? Can you provide an information about the frequency, how often the solis pipes out some data?

Martin

[grob6000]

Yes, the online API amalgamates what it receives and only provides 5 minute interval data. Also, the most recent data from Soliscloud can be a few more minutes old (maybe it takes a bit of time to process and add to the database) - so the latest value via that API can be 5-10 minutes old!

I think different solis inverters work a little differently, so I can only speak for my S5 GR3P5K AU. This sends data on RS-485 at approximately 30 second intervals. The ESPHome firmware can buffer this and send to mqtt/home assistant at longer intervals if preferred (just set update_interval to what is required in the yaml configuration). My setup is working fine with this at 30 seconds.

[kuttikutt]

Alright,

thank you for that information.
I got the RHI-3P10K-HVES-5G with the WiFi stick.

but 30s sounds much better than 5 mins :)

It may take a little but I have everything ready to grab the RS485 (converter, esp...). Right now I'm a bit busy with work .. grrr ...

[kuttikutt]

Hey, it's me again.

Again, sorry if my questions may sound a bit n00by. I did a lot of close-to-the hardware development in my life, but all of this is a completely new topic for me :)

New in case of Solis, HomeAssistant, ESP controllers and its "home" and all the surrounding stuff.

However: I would call this a success:

I know - there is no data, since I didn't hook up the ESP to the RS485 --> TTL converter --> Solis Hybrid yet.

I noticed a thing right away: My inverter supports up to 4 strings and a battery. Your project provides 22 entities, but the GinLong API provides 49. So if (hopefully) everything is working, once I connect the ESP to the Solis this screams to be further developed.

Oh my - to get an entry into this from point zero is quite difficult. I fiddled around with VSCode, but got a lot of errors concerning missing esphome libs. After a while, I stumbled over the VSCode plugin for HomeAssistant. Out of curiosity: did you write the code with that? At least there it does not complain about the missing libs...

If I'm correct: What extension do you use to run and debug the code?
I get: You don't have an extension for debugging C++. Should we find a C++ extension in the Marketplace?
But there are quite a lot ...

Maybe I really need to grab some packets with a sniffer ...

Or maybe I can send you a dump of my Solis and you want to add the new data to your project?

regards and thanks so far,
Martin

[kuttikutt]

Hello, unless you got an idea, I guess we can close this.

I spend hours to make some sense out of this.
The ESP seems to work - at least if I send some data via a USB to RS232 interface it reads it correctly.

well well - it seems that the protocol has changed and I can't make heads or tails out of it.

[21:32:07][D][solis_s5:157]: message recieved len=8 [21:32:07][D][solis_s5:158]: -->��\x88\xb8<-- [21:32:07][D][solis_s5:157]: message recieved len=7 [21:32:07][D][solis_s5:158]: -->��� \xa0\xd8O�<--
[21:32:07][D][solis_s5:157]: message recieved len=8
[21:32:07][D][solis_s5:158]: -->��\x80\xe8<--
[21:32:07][D][solis_s5:157]: message recieved len=55
[21:32:07][D][solis_s5:158]: -->��2<--
[21:32:08][D][solis_s5:157]: message recieved len=8
[21:32:08][D][solis_s5:158]: -->��\x81�<--
[21:32:08][D][solis_s5:157]: message recieved len=55
[21:32:08][D][solis_s5:158]: -->��2<--
[21:32:08][D][solis_s5:157]: message recieved len=8
[21:32:08][D][solis_s5:158]: -->��\x81�<--
[21:32:08][D][solis_s5:157]: message recieved len=55
[21:32:08][D][solis_s5:158]: -->��2<--
[21:32:08][D][solis_s5:157]: message recieved len=63
[21:32:08][D][solis_s5:158]: -->��\x813<--
[21:32:08][D][solis_s5:157]: message recieved len=63
[21:32:08][D][solis_s5:158]: -->��\x81P<--
[21:32:08][D][solis_s5:157]: message recieved len=63
[21:32:09][D][solis_s5:158]: -->��\x81l<--
[21:32:09][D][solis_s5:157]: message recieved len=8
[21:32:09][D][solis_s5:158]: -->��\x81\x88<--
[21:32:09][D][solis_s5:157]: message recieved len=55
[21:32:09][D][solis_s5:158]: -->��2�<--
[21:32:09][D][solis_s5:157]: message recieved len=63
[21:32:09][D][solis_s5:158]: -->��\x81\xbd<--
[21:32:09][D][solis_s5:157]: message recieved len=53
[21:32:09][D][solis_s5:158]: -->��\x81\xd6<--
[21:32:09][D][solis_s5:157]: message recieved len=63
[21:32:09][D][solis_s5:158]: -->��\x81\xe2<--
[21:32:09][D][solis_s5:157]: message recieved len=8
[21:32:09][D][solis_s5:158]: -->��\x81\xfb<--
[21:32:10][D][solis_s5:157]: message recieved len=55
[21:32:10][D][solis_s5:158]: -->��2<--
[21:32:10][D][solis_s5:157]: message recieved len=8
[21:32:10][D][solis_s5:158]: -->��\x88\xb8<--
[21:32:12][D][solis_s5:157]: message recieved len=8
[21:32:12][D][solis_s5:158]: -->��\x8c\xa0<--
[21:32:14][D][solis_s5:157]: message recieved len=8
[21:32:14][D][solis_s5:158]: -->���\xb7<--
[21:32:16][D][solis_s5:157]: message recieved len=8
[21:32:16][D][solis_s5:158]: -->��\x80\xe8<--
[21:32:16][D][sensor:126]: 'Solis Inverter ESPHome Uptime': Sending state 401.96100 s with 0 decimals of accuracy
[21:32:18][D][solis_s5:157]: message recieved len=55
[21:32:18][D][solis_s5:158]: -->~�\xa1<--
[21:32:18][D][solis_s5:178]: wifi stick command received; ignoring
[21:32:20][D][sensor:126]: 'Solis Inverter ESPHome Wifi Signal': Sending state -61.00000 dBm with 0 decimals of accuracy
[21:32:21][D][solis_s5:157]: message recieved len=8
[21:32:21][D][solis_s5:158]: -->��\x88\xb8<--
[21:32:23][D][solis_s5:157]: message recieved len=8
[21:32:23][D][solis_s5:158]: -->��\x8c\xa0<--
[21:32:25][D][solis_s5:157]: message recieved len=8
[21:32:25][D][solis_s5:158]: -->���\xb7<--
[21:32:27][D][solis_s5:157]: message recieved len=8
[21:32:27][D][solis_s5:158]: -->��\x80\xe8<--
[21:32:29][D][solis_s5:157]: message recieved len=55
[21:32:29][D][solis_s5:158]: -->~�\xa1<--
[21:32:29][D][solis_s5:178]: wifi stick command received; ignoring`

and so on
Made a small change:
if (loopwait > SOLIS_S5_LOOP_WAIT) { // some time has passed without receiving another character. this should be the end of a message. ESP_LOGD(TAG, "message recieved len=%d", index); ESP_LOGD(TAG, "-->%s<--", buffer); if (buffer[0] == 126) { // message starts with the right preamble

to get this

I also tried to invert the data on the serial port, because I found that here: https://github.com/hn/ginlong-solis but still no luck. Without a proper description - the time I have to spend on this is wasted... especially it would bring (in my case) no advantage.

See:

[21:37:07][D][solis_s5:157]: message recieved len=8 [21:37:07][D][solis_s5:158]: -->��\x88\xb8<-- [21:37:07][D][solis_s5:157]: message recieved len=7 [21:37:07][D][solis_s5:158]: -->��� \xa0\xd8O�<--
[21:37:07][D][solis_s5:157]: message recieved len=8
[21:37:07][D][solis_s5:158]: -->��\x80\xe8<--
[21:37:08][D][solis_s5:157]: message recieved len=55
[21:37:08][D][solis_s5:158]: -->��2<--
[21:37:08][D][solis_s5:157]: message recieved len=63
[21:37:08][D][solis_s5:158]: -->��\x81�<--
[21:37:08][D][solis_s5:157]: message recieved len=63
[21:37:08][D][solis_s5:158]: -->��\x81�<--
[21:37:08][D][solis_s5:157]: message recieved len=8
[21:37:08][D][solis_s5:158]: -->��\x813<--
[21:37:08][D][solis_s5:157]: message recieved len=55
[21:37:08][D][solis_s5:158]: -->��2 �<--
[21:37:08][D][solis_s5:157]: message recieved len=63
[21:37:08][D][solis_s5:158]: -->��\x81P<--
[21:37:09][D][solis_s5:157]: message recieved len=63`

As you can see:
The last data was sent at: [21:32:29]
this one [21:37:07]

This is actually the same update rate I get when using the API from GinLong ...

This is so sad :(

[grob6000]

The following is promising, as it indicates the wifi stick is sending it's identity and data to the inverter with the same protocol as mine:
[21:32:18][D][solis_s5:178]: wifi stick command received; ignoring

Otherwise, looks like there's a fair bit more data coming out than I'd expected. Understandable this is frustrating; seems crazy to have so many random protocols from one manufacturer!

ESPHome has a function to print serial data out to the log in hex, which might help either you or I decode it a bit more. You could try this in the config; it will hopefully print something a bit more intelligible than the string (although well done working out how to get that done).

uart:
  id: uart_bus
  tx_pin: 1
  rx_pin: 3
  baud_rate: 9600
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      timeout: 100ms

Any other direct log of the data coming out of the inverter with the stick connected and otherwise working (preferably raw binary, or hex, rather than in string form?) I could take a look at.

[grob6000]

Example of the logging option added to config - see #e9f702b

[kuttikutt]

Hello!

I think we use different stick with different controllers and firmware. See: hultenvp/solis-sensor#100 (reply in thread)

I got the S3-WiFi-ST but most of the code is for the S2-WL-ST

I also found: https://github.com/hn/ginlong-solis Since I did a lot in the Arduino IDE I am very close in giving that a try

They write there:
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.

This means they use the S3-WiFi-ST (login is "admin" and "your WiFis password").

Since they also did the decoding of the hex-codes aswell, there would be no need to reinvent the wheel ;)

[jonnyrider]

I've got the S3 wifi stick, and was planning on attempting this later. If I send you the output file would you be able to help decode this? Looks like it does provide some output, and as I also need to keep the cloud component connected, I'm hoping this will work.

Thanks

[grob6000]

Yeah please go for it! Make sure to turn on the debug feature of the esphome UART bus to show the raw messages, or any kind of raw serial log of the comms between the stick and the inverter you can get is helpful. Hopefully it will be close enough it will only take some minor tweaks to work. Worst case might need to find the time to get stuck in but very least I can help you having a crack at it.

…

On Wed, 28 June 2023, 12:55 Jonathan Rider, ***@***.***> wrote: I've got the S3 wifi stick, and was planning on attempting this later. If I send you the output file would you be able to help decode this? Looks like it does provide some output, and as I also need to keep the cloud component connected, I'm hoping this will work. Thanks — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACA3FBBLLNG5PYQA4I7TJKLXNQLULANCNFSM6AAAAAATZUQLT4> . You are receiving this because you commented.Message ID: ***@***.***>

[jonnyrider]

I've attempted this, but not having any luck! Think it may be down to my poor soldering skills, but just not getting anything on the debug messages. I'll keep trying.

[jonnyrider]

I've given up on this, as I just couldn't get it to work. I connected the uart port of the WiFi stick to my Pi and it looks like the data is sent to the stick but not actually processed until it is sent to the Solis cloud. So, no point trying to hack this as it doesn't get any better! The WiFi stick S3 just seems so locked up that it isn't worth it.

…

On Wed, 28 Jun 2023, 13:04 George, ***@***.***> wrote: Yeah please go for it! Make sure to turn on the debug feature of the esphome UART bus to show the raw messages, or any kind of raw serial log of the comms between the stick and the inverter you can get is helpful. Hopefully it will be close enough it will only take some minor tweaks to work. Worst case might need to find the time to get stuck in but very least I can help you having a crack at it. On Wed, 28 June 2023, 12:55 Jonathan Rider, ***@***.***> wrote: > I've got the S3 wifi stick, and was planning on attempting this later. If > I send you the output file would you be able to help decode this? Looks > like it does provide some output, and as I also need to keep the cloud > component connected, I'm hoping this will work. > > Thanks > > — > Reply to this email directly, view it on GitHub > < #1 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ACA3FBBLLNG5PYQA4I7TJKLXNQLULANCNFSM6AAAAAATZUQLT4> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALQ4KYA2QG2DY4XRKNUJQ3TXNQMTPANCNFSM6AAAAAATZUQLT4> . You are receiving this because you commented.Message ID: ***@***.***>