Getting Data from Solis Inverter

Thanks, have read extensively, and suspect at some point I’m going to have to delve into modbus. For me that’s a real dark art.

I’ll try with the wifi stick which is coming as it seems the easiest option for me.

If that doesn’t work its other options.

Tony

Solis wifi stick datalogger version 3.4.

Comments?

@Biscuit / Geoff - thanks for your detailed comments here. I too have just had a Solis RHI-5K-48ES-5G installed with a stack of Pylontech Force L2 batteries on the way. My install forgot the wifi stick so I’m currently running blind (except for my grid import/export kW value every 10seconds via my smart meter). I too am very much considering the hardware approach you’ve taken here given it seems to avoid most of the guesswork and potential frustrations around incompatibilities with new wifi sticks etc etc.

I have a couple of questions about your setup:
Why have you chosen to connect to both the CAN and RS485 interfaces on your pylontech batteries? Does the data they provide diff? I always thought they’d have a large overlap.
I know my Solis inverter will have to be wired to the Pylontech CAN interface, so how do you “double stack” your CAN reader hardware with what’s needed for the Solis inverter to work with the batteries (Does this suffer from the same multi-master issue that you described RS485 does?)
Once you have the Modbus TCP exposed, how do you control that in Home Assistant? Can you release any more exact details here or do the Modbus registers vary wildly between models / firmware versions (as the data logger seems to!)? What writes (if any) do you perform? I want to set my battery to charge/discharge based on my variable import tariff price & other factors that I already have in Home Assistant.

Thanks!

Is this not the very latest version? The new fancy stick with a reset button and the lights on the outside - at least three upgrades ahead of my very old LAN model.

https://www.ginlong.com/uploads/file/Manual_S3-WIFI-Stick-ver3,4.pdf

I cannot say for sure as I don’t know what the ‘advanced’ tab on the setup page provides, but I do not believe that a ‘server b’ option is available on this one, so this thread is unlikely to be of use to you.

As this one is new there may be very little information about it out there, but you are looking for an internal server B (push data), an internal server (for Modbus connection), or a hidden config page that has more settings.

Modbus is not actually that difficult once you get your head around it!

Thanks for that!

And I agree that modbus is actually doable.

Can I sacrifice this stick and solder, or rather get someone to solder two wires on it?

If so will that preserve the cloud?

I have been looking at an MQTT option because I’m familiar with that and have a server running to support some ancient sonoff devices.

But yet again I suspect I’m screwed by the stick.

Background:
I started late last year after my new Solar PV system was installed, and I went for the ‘server B’ option as my stick can do that, and it worked without hardware. Lots of learning about Node-RED. After that I wanted to connect to my Pylontech US3000C, so I used their BatteryView software and MultiSIBControl to connect, first to the RS232 console port, then to the RS485 port as well. This required the adaptors and physical connections. Over time I gradually worked my way through both comms ports/protocols connecting directly to Node-RED.
Then it was Modbus, and I decided that I would also try the CANbus line. Why not - it is there.

Answers:
Good luck with the WIFI stick!

The CAN connection is passive, but the data is fast, accurate, and straight from the ‘horses mouth’. I get to see exactly what the inverter is being told, and as my Solis decides to change some of the battery BMS data (battery in/out power being 96 watts when the Pylontech says 24 watts - work that one out), I wanted to be absolutely sure I knew what my battery units were saying.
The other port data is delayed, and yes the data does differ between the RS485 and console ports.

The CAN bus is the only coms link battery to inverter in my setup, and is one-way from battery to inverter. The RS485 comms ports can be used to talk to some inverters, but are mostly used to connect battery stacks, and work on a completely different approach / protocol. In the latest series you can have up to 16 Pylontech batteries link connected as one stack, the master unit connected to the inverter. Multiple stacks are then connected to the first stack, linked with the RS485 ports.

The CAN bus is a two-wire high speed ‘shout when you want’ system used in cars, with everything just connected in parallel. Absolutely essential NOT to break the battery-inverter connection, but I just linked the line through a network socket and tied in my adaptor. There is no master in a CAN bus.

I wrote up the entire CAN project on here, not that I think it is of much interest to anyone, but you can find ALL the details here

https://community.home-assistant.io/t/reading-can-bus-communication-between-pylontech-battery-and-solis-inverter/420788

Modbus:
The simple place to start is ‘read only’, and this can be done in place of the stick, alongside the stick, or via the stick (if you can find the internal Modbus server). Reading in HA is possible, but I prefer to work in Node-RED. Once I had the reading sorted, I moved onto the control. I have an almost working control system based on the UK Octopus Energy outgoing price, able to switch the inverter to charge the battery / sell the excess / dump and sell charge etc. This has to be done with some care - I have manual control set up so I can remotely change time (inverter internal time walks) the charging time and control settings, the SOC, and the master control flag to change the mode. I have extensively experimented with automatic control but find the Modbus write is not 100% reliable (for me) so I do everything manually and visually check the outcome.

From my Modbus register reading, all done in Node-RED, I push any values I want to HA using the entity node. This gives me a very rich dashboard with state and history. At the moment I do very little control, and this is done by using the Node-RED dashboard, but I have Node-RED dashboard set up in the side menu bar, so effectively everything from HA screen.

As for the registers - there is information out there, and I have found almost everything I needed either via searches or by informed experimentation. However, given the consideration of ‘disclosure’ and ‘safety’ I am not willing to on-publish what is proprietary information, and I don’t trust my own code with my own inverter so why should you? Accidently writing the wrong value to a register can have serious and expensive implications.

I was lucky with getting a very old stick. I have bought two newer sticks /boxes. Although I cannot get the inverter to register with them (so I can’t actually use them) I have connected to them and checked out the settings, and it seems that with each issue less and less ‘useful’ stuff is exposed.

Options

  • use the stick only
  • don’t bother with the stick, prise it apart for the plug
  • keep the stick and try to piggy back onto the data lines inside the plug
  • if the plug wire to board wire has a connector (mine does) source one of those to go between them

The cloud will work only if the stick is connected. Piggy backing directly to the stick does give rise to the ‘two master’ issue, which is probably acceptable for read only, but not a good idea when trying to write to the inverter registers.

I did contact Solis technical support with a query, and the technician I spoke with was able to check my inverter firmware version remotely - I believe that having the stick connected and working has some side benefits like remote update and support.

Thanks for all the info. Shame about the unreliable modbus writes. I see similar with a few other modbus TCP thermostats I control via NodeRED.

I have an idea for what my setup will look like now and hope I can make the writes reliable enough through retries etc to make it automated. I too am on Octopus (Intelligent tariff which I’ve written a HA integration for) so will be interesting to see.

It is quite frustrating that in this day and age devices still get pushed out with such poor automation opportunities out the box.

Thanks for all the help and information.

Question: what is known about server b functionality on the lan stick?

Is there a list of server b versions of the wifi stick if I was to invest in an earlier model, and are there any gotchas associated with that course of action?

Tony

Short questions - long answers…

The data sticks are made by Solarman, which makes solar logging and monitoring software for a wide range of manufacturers. There are many physical models, many firmware releases, and many communication protocols. Solis simply badge engineer.

The sticks vary over time, but also by location, so what you can buy here in the UK will be different to what anyone in Australia gets.

Via the (difficult to source) plug/socket arrangement, the sticks act as a client (master) to the inverter internal server (slave) and pulls data, presumably on a regular basis (done over one centimetre of serial Modbus). The stick has a server A, pointing to Solarman/Solis cloud, which responds to the Cloud client - the protocol, now version 5, is apparently complex, with bi-directional handshakes that must be matched exactly otherwise nothing happens. Something like stick calls cloud, cloud calls back, stick sends data. Most sticks have two such servers, and with varying degrees of success the second (alternative) server can/cannot be setup to point to anything. Ironically this ‘server’ pushes data of its own accord, when servers should actually respond to a client request. My guess is that this setup was non standard and has been effectively deprecated. Data logging to the cloud/anything is always a problem since the cloud should do the polling, but the stick here wants to push data…

Various posts (on many platforms) have posted their model numbers, so I am aware of several different boards, firmware, and some of the ‘features’. To save me typing it all out again I point you to my earlier post in this very thread →

The salient features to look for on your stick are:

  • the status page, showing power etc, which can be scraped if you so wish
  • a second / alternative server, which can be set to push data or to be polled using Protocol v4 or v5
  • a hidden config page with further options
  • settings for the stick’s own internal Modbus server

I can only experiment with my first stick, but I know that it has server A pointing to the cloud, server B pointing to my HA, and another internal server that I can send Modbus requests to. The status page does not work, issues I believe with this old stick not coping with the later Hybrid (battery) Solis inverter.

My best suggestion - don’t bother.
You almost certainly won’t be able to find an earlier or even a particular model. I tried. I ordered from several UK solar ‘suppliers’. Two took my money on the e-shop and I have neither seen nor heard anything since. Caveat Emptor - I should have done my due diligence first, one shop owner has been taking thousands from online orders while fending off repeated attempts to strike off his ltd company.

I am only running the stick for the value of the long term data analysis I get from Solis cloud. I really should turn off the server B as I no longer use it. It was there when I first started, it required no hardware to work, it was a great exercise to learn Node-RED, and it was a real pain trying to decipher the protocol.

My old LAN stick is very different to the WIFI versions. The progression of the various stick versions appears to be moving towards one standard WIFI model, using a full handshake protocol, and with all extra options fully hidden from view. LAN stick versions are just WIFI ones with a port-out between the board and where the WIFI module would be.

Personally, I think the Server B option is no longer viable. If you can find the internal Modbus server, then that is the way forward, as it requires no further hardware and manages running both stick to cloud and stick to HA / Node-RED via Modbus.

What is that old saying? You should Solis Data Logging Stick it where…

Got it thanks

I just found out, i have the same stick as you.
LAN with serial number 19 13
Firmware ME-121001-V1.0.6(202011261020)

Can you share your homeassistant settings for the modbus connection?

I tried feeding homeassistant with this hacs addon:

But its very unreliable for me and only works for a day and after that it only works again after a restart of homeassistant

The HACS addon you refer to appears to use a direct API call to Solis Cloud, and has nothing to do with the data logging stick (as far as I can tell). Some integrations do this by using the cloud username and password - I have not tried this method.
Solis Cloud was significantly updated and moved to a new platform at the start of this year, and I did read somewhere that the Solis API feature has been deprecated, which may explain why such integrations now have issues.

For Modbus, I use Node-RED rather than HA as I have found this easier to work with (HA has to be completely restarted every time I make just one change to the config…). Since my stick no longer functions most of the time, I am not using the stick internal Modbus server but rather piggy backing on to the direct Modbus RS485 port out of the inverter.

Yes, getting data out of a Solis inverter is not easy

Yes the addon im using grabs the data directly from soliscloud website over the api.
The api is not deprecated, as theres a new feature since a few weeks, where you can create your own api key and dont have to ask support for it.

But because of the problems im encountering with this way of getting data, i want to change it to local.

1 Like

I can’t get into my data stick at the moment - it is very unstable, only works for minutes every few hours. There is a manual setting page in there somewhere (you will just have to look) for the internal server that responds to Modbus calls over TCP. You need to ensure that is running, and note the server port being used.

I experimented with the following HA setting as proof of concept.

modbus:
  - name: "solis"
    delay: 5
    timeout: 5
    type: tcp
    host: 192.168.0.182
    port: 30003
    sensors:
      - name: "HA meter Volt"
        unit_of_measurement: V
        address: 33251
        slave: 1
        count: 1
        input_type: input
        data_type: uint16
        device_class: voltage
        state_class: measurement
        scan_interval: 30
        scale: 0.1
        precision: 1

host - IP address of stick
port - server port setting on stick

This was experimentation, most of the options are unnecessary.

Thank you.

do you have a list with all the registers?
Or is it the list in post 30 of you with a fixed offset?

The Solis register list is out there on the web if you search for it. No guarantee that the register list will match a particular model though.
I understand that Ginlong will provide the ‘read only’ registers if you ask. Write registers are another matter.

We are being herded like sheep into the cloud. When the flock is big enough we’ll be charged for continuing access.

Enjoy free data whilst you can - however you manage to get it.

Tony

I’ve gone down a different path that seems to be fairly straightforward, in my opinion, and is working flawlessly since I configured it.

I purchased a Protoss-PE11-H RS485 to Wired Ethernet Bridge from AliExpress for £16.

I suspect that the WiFi version would also work, but I prefer wired reliability.

I purchased the famous German RS-485 plug that fits the Solis inverter, which it does, and followed the wiring guide as shown in the listing. I confirmed the 5V and Gnd rails with a multimeter.

I configured the PE11 to modus, 9600 baud, 8 bits, 1 stop, no parity. As well as a TCP server on port 502.

Then in home assistant the following

modbus:
  - name: "Solis_Inverter"
    type: tcp
    host: 192.168.1.24
    port: 502
    sensors:
      - name: Solis_Watts
        data_type: uint32
        slave: 1
        address: 3004
        input_type: input
        count: 2
        unit_of_measurement: W
        state_class: measurement
        scan_interval: 20
      - name: Solis_today_kwh
        data_type: uint16
        slave: 1
        address: 3014
        input_type: input
        count: 1
        unit_of_measurement: kWh
        state_class: total_increasing
        scan_interval: 60
        scale: 0.1
        precision: 1
      - name: Solis_yesterday_kwh
        data_type: uint16
        slave: 1
        address: 3015
        input_type: input
        count: 1
        unit_of_measurement: kWh
        state_class: measurement
        scan_interval: 3600
        scale: 0.1
        precision: 1
      - name: Solis_total_energy
        data_type: uint32
        slave: 1
        address: 3008
        input_type: input
        count: 2
        unit_of_measurement: kWh
        state_class: total_increasing
        scan_interval: 300
      - name: Solis_total_energy_this_month
        data_type: uint32
        slave: 1
        address: 3010
        input_type: input
        count: 2
        unit_of_measurement: kWh
        state_class: total_increasing
        scan_interval: 300
      - name: Solis_total_energy_last_month
        data_type: uint32
        slave: 1
        address: 3012
        input_type: input
        count: 2
        unit_of_measurement: kWh
        state_class: measurement
        scan_interval: 3600
      - name: Solis_total_energy_this_year
        data_type: uint32
        slave: 1
        address: 3016
        input_type: input
        count: 2
        unit_of_measurement: kWh
        state_class: total_increasing
        scan_interval: 300
      - name: Solis_temp
        data_type: uint16
        slave: 1
        address: 3041
        input_type: input
        count: 1
        unit_of_measurement: C
        state_class: measurement
        scan_interval: 120
        scale: 0.1
        precision: 1
      - name: Solis_grid_freq
        data_type: uint16
        slave: 1
        address: 3042
        input_type: input
        count: 1
        unit_of_measurement: Hz
        state_class: measurement
        scan_interval: 60
        scale: 0.01
        precision: 2
      - name: Solis_grid_current
        data_type: uint16
        slave: 1
        address: 3038
        input_type: input
        count: 1
        unit_of_measurement: A
        state_class: measurement
        scan_interval: 60
        scale: 0.1
        precision: 1
      - name: Solis_grid_voltage
        data_type: uint16
        slave: 1
        address: 3035
        input_type: input
        count: 1
        unit_of_measurement: V
        state_class: measurement
        scan_interval: 60
        scale: 0.1
        precision: 1

I have also written values to the inverter using nodeRed as it is just easier to do that way. Happy to share that example if required.

Using this example, it is cheap only required 1 device with no modification, no python, no coding, no resister fiddling. Most importantly no cloud, and update frequencies that you control. One of the key things was setting the input_type to input and not holding as that dictates the function code 3 vs 4 which matters a lot.

Hope this helps someone.

4 Likes

Actually if you have a solis wifi logger you can use this https://github.com/StephanJoubert/home_assistant_solarman to get the values locally as well via modbus.
Would be helpful if you share the wiring diagram for the rs485 round connector too.