Another problem ive found out is, that when i enter a server b, the interval of the data reported to solis cloud gets totally unreliable.
In the Solis Cloud app says, the data was updated 1 minute ago, but the data is like 15 min old.
You might be pleased to hear that I’ve set myself almost exactly the same challenge as you. I think there are some really big opportunities to get the most out of solar power with predictive battery management!
And, even better, I think I’ve almost solved (so far in a very hacky way) everything up to your step 5, using the Solis data logging stick and an awesome custom component by a guy called Stephan Joubert. I’ve created a fork here with some very basic initial proof of concept:
Have taken it a little further since then, but it has been very slow progress as I’m leaning home assistant development environment and Python at the same time. Can share with you what I have if it would be useful. It’s really going to need someone competent in writing the user interface to make it useable.
The basic concept is different to what has been discussed here so far, because it directly reads data from the stick with Modbus TCP I believe, and doesn’t need any additional setup on the stick, and doesn’t rely on the cloud at all. It may be that this method is limited to only some versions of data longing stick however (more details on Stephens thread+ GitHub). Additional bonus is that this may also work for other inverters which all appear to use very similar protocols.
I found exactly the same as you, it looked like it was accepting my inputs, but didn’t actually change any behaviour. You might want to look at my last post as that’s the route I went which has worked for me.
Yes, with the looming prospect of time-variable energy pricing and the growing availability of battery systems, I agree that there is a wide-open gap in the ‘smart home’ domestic energy market for integrated inverter and/or battery energy management. In the mean time we have to ‘DIY’ a way of getting data from (and to) the inverter…
Software: I am not pursuing the GitHub route as I struggle to understand how it all works. Node-RED can read and write to my inverter with just one ‘simple’ Modbus node, which seems to replace a great deal of python code. So, for now, I am developing in Node-RED, running alongside HA and with the Node-RED dashboard companion. I can now control my inverter directly from a Node-RED dashboard, and pass important stuff to HA using the ‘entity’ node to create sensors. I can then host helpers, automations, and template sensors in HA, and get stuff back into Node-RED by directly reading the homeassistant global variable.
Hardware: Thanks for the update - I have checked and discovered that I can indeed communicate directly with the Solis Data Logging Stick internal server using simple Modbus TCP. Maybe my stick is very old, but I don’t actually need any protocol, just Modbus TCP (which Node-RED handles). I assume that the stick is acting as a repeater, handing commands straight through to the inverter. However, as my logging stick only works intermittently, and Solis Cloud stubbornly refuses to swap and bind my inverter to the newer stick I bought, I am only running the old stick as a ‘back up’ and for the novelty value.
I have tested USB converters but as I am in this for the long term, I have settled on using industrial grade ethernet adapters. My setup (from the left in photo) has an ethernet-CAN bus module. Used to monitor the battery-inverter CAN-bus comms so I get the battery SOC etc direct from the ‘horse’s mouth’. This also has a spare RS485 port which I use to access the Pylontech via the RS485 port. Then I have an ethernet RS232/RS485 module. I use the RS232 port to access the Pylontech console port, and the RS485 as a Modbus over TCP link ‘direct’ to the inverter. The next module is a 3-port RS485 unit, running in its special dual-Modbus-master mode. This allows me to access the inverter alongside the data stick (as two masters reading one client). Appears to work quite well, and I have also cannibalised the ‘stick’ so as to have easier access and to use the header to plug into the RS485 link. The hardware/Node-RED is rock-solid – this has been running for 26 days 24/7 (my inverter never sleeps) since the last power-cycle without missing a beat, which is a lot more than I can say for the Solis Logging Stick. I do continue to get the data from the stick ‘server b’ when it works.
Having tried or looked at most of the half dozen ways of getting data from a Solis inverter, I think the simplest, most resilient, and most flexible is Modbus TCP using Node-RED. With the ‘right’ and working data logging stick no additional hardware is required either.
Automation: I have tried HA sensors directly reading from the inverter (modbus platform). Great for just reading data, but I struggle to see how to build a sophisticated ‘program’ with complex UI and error checking. Something that for me is more achievable in Node-RED.
My initial thought for automation was to run some kind of predictive SOC model, but that seems fraught with difficulties over load and solar forecasting. I am with Octopus on a Fixed Outgoing (7.5p) tariff, but hope to move to Agile Outgoing at some point, so I decided to build a test automation based on an agile pricing model, using the concept of different actions depending on how much I could get for exporting excess solar or discharging from the battery. My (Solis Hybrid) inverter supports self-use (default - store excess solar to battery) feed-in (sell excess to grid), timed charging/discharging (dump charge to grid, or force battery charge).
Yes, it has been and continues to be a very steep learning curve. And certainly, most of my Node-RED code is for the UI and error management. Reading the inverter registers is one thing, writing to them is another, and my current difficulty is how to deal with failed writes when the code is trying to switch the inverter from ‘charge’ to ‘discharge’ in the middle of the night. This stuff is of no use unless it is reliable.
Here is a screen shot of where I am with my automation model at the moment. Still very much in testing mode. What it all does: -
Read Octopus Agile tariff for my area (both in/out) once a day. Assign an action to each half hour slot dependent on export price (££££ dump = discharge battery to grid, £££ sell = send excess solar to grid, ££ default = excess solar to battery, £ burn = turn on extra appliances to increase load).
Adjust for daylight period, smooth out, and reduce to a list of single ‘trigger’ events.
At each trigger event, change inverter settings accordingly (charge/discharge time & current). Run a ‘mode check’ in the background every 3 minutes. This looks at the UI switch setting, the battery SOC, time-slice average load and excess solar, and makes the necessary change to the inverter op-control register as required (turn on/off/pause).
I have added extra code to set the battery to charge overnight every 28 days as Pylontech batteries need to be held at 100% for at least one hour once a month to allow recalibration of the SOC. I also have an issue with the Pylontech batteries continuing to discharge a small current when down at the OverDischarge SOC. So another routine runs every few minutes to monitor for that, and (if the automation is not doing anything else) will switch on ‘charge from grid’ for 1 minute, which I have found is effective in forcing the inverter to turn the batteries ‘off’.
I could add further actions to operate a ‘price to buy’ mode to charge the battery based on low import costs, and also to use the Solis inverter ‘backup’ mode. Backup on the Hybrid inverters can be set for a specific SOC, and will charge the battery from grid up to that value, so ‘part charging’ becomes easier to implement.
Capturing operating actions to a file record and calculating the cost-benefit analysis is yet more work required. Far too many variables involved in all of this!
3 Likes
I seem to be stuck with this as the S/N for my data logger is alphanumeric, and that seems to cause this integration some problems…
Is there anywhere else this is being discussed which you might be aware of?
Thanks
So happy to have found this thread, going down the solar and inverter route now. @Biscuit could we get more detail on the picture?
First, thanks for the info and the learning and trial and error. Would love to get more insights on how everything is chained together inside your box. There is a lot going on with the hardware but I absolutely want this sort of data and control in my environment as well. Node-Red and Home Assisatnt - yes please 
I have a Solis hybrid inverter and Pylontech batteries. These are simply what my installer provided. Apparently they are the best in the market for domestic inverters and domestic batteries, but I have found both of them to be very challenging to connect to, with scant information and complicated connectivity as well as many variations on hardware and protocols.
The bottom line is that, whatever you find on a site like this where someone has managed to connect to either Solis or Pylontech, you can be fairly sure that your (later/other part of the world) system is different and their solution will not work. It is all proving to be very tricky indeed.
There are at least half a dozen ways to get information from a Solis inverter once you have connected the de facto data logging stick.
- scrape the data from the solis cloud website
- api call to solis cloud website (solis API call has been deprecated I believe)
- scrape the stick internal status page
- set up the stick internal ‘B’ server to push data to your HA device (only ‘old’ models work)
- poll the stick internal Modbus server (best solution - no hardware required)
- replace the stick and connect directly (several hardware solutions)
- piggy back with the stick and connect directly
I have maintained the data stick - it has a timing issue and only connects to the cloud or my system for 10-20 minutes every three to six hours, but it still updates and I have some use for the cloud data / support.
I have running the ‘B’ server (yes it works on my old stick - at least it does when the stick works)
I also have running a direct Modbus poll bypassing the stick - I am using a special bit of kit to enable me to run both the stick and direct connection over Modbus. Normally you can only have one master on Modbus (which the stick is) but I can successfully run both the stick and my HA kit as a two-master arrangement.
I also have a Canbus sniffer on the battery-inverter comms, a serial connection to the battery comms port, and a serial connection to the battery RS485 port.
PICTURE: - the hardware
The inverter is in the garage, to which I have internet feed, and I have gone down the ‘over TCP’ route with several ethernet to Canbus/serial converters. These all plug into a network connected hub and have static IP addresses, so sat here at my desk PC I can log into the status/setup pages of everything. Connectivity is then a case of setting up a TCP connection to each device and thereby the associated serial ports.
This lot was not the cheap £25 USB RS485 dongle stuff, but it is (semi) industrial and has been running rock solid since April. No failures, no issues, no updates or changes, no reboots. Restart from power outage without issue. All available (just) in the UK with a bit of searching.
From the right hand side…
In the museum display box, the guts of my Solis Data Logging Stick (LAN type, orange board issue). Off picture right is the inverter - the data stick RS485 comms plug/socket used is a difficult to source model but I found a PC 4 way 1.5mm pinout connector (plug/socket) which fits (the white bit at the top of the stick pc board) so I can take the 5v power from inverter to stick, and take the RS485 comms pair to my adaptor.
Network connection at bottom, switch in box on right to cut 5V power - quick and easy to reset the stick. Clear cover so I can see the power/comms/link leds flashing wildly as it constantly tries to connect to the cloud (and fails).
The white box is a special tri-port RS485 box. This can be set up to do many things, but one mode allows two Modbus masters to communicate without upsetting the bus. The stick is a master, and my HA is a master, so I have both connected to a different RS485 port, with the third port going to the data stick. It works. It might be the cause of my timing issues with the stick-cloud, but I have given up trying to fix the stick and I have no issues with my Modbus side getting to the inverter.
This bit of kit is only necessary if you want to have both direct access and stick running together. Someday I may take the plunge and cut out both the stick and this box altogether.
The middle box is an ethernet to serial converter, with an RS232 port and an RS485 port. The RS232 port goes to my Pylontech comms port. The RS485 port goes to the tri-port dual-master box.
It sounds complicated but my Modbus works like a dream. Node-RED is connected over TCP to the middle box, RS485 port working in Modbus mode. Modbus over TCP is converted to Modbus over serial, which goes to the white box, which converts the baud rate and forwards to the inverter, getting the response back (unpicking from the stick messages).
The left hand box is an ethernet to canbus converter. This supports two canbus ports and also has an RS485 port. I have connected the battery-inverter canbus communcation to one port and use this box to listen in (reading only) on the canbus. Very simple to setup and use, and I get the battery status (voltage, current, SOC, temp, alarms) updated every second. The RS485 port is connected to the battery RS485 port, and I use that to poll the Plyontech as well as the console port.
I only really need the middle (RS232 and RS485) box, the rest is overkill, but all the twinkling red, green, and blue lights make it all look busy and interesting.
I like the inverter, it has a great display screen on the front and supports backup power circuit from the battery during grid power failures, but boy this should all be so much easier to achieve…
1 Like
Hello
Help please.
I’ve imported the flow from post 1 of this thread but the flow has failed due to missing node type “buffer-parser”. I suspect I lack knowledge to proceed further.
Any help gratefully appreciated.
Tony
When importing a flow, any node types in the flow that are not currently installed into your pallet will show up as missing. Buffer-Parser is a community contribution node and not part of the ‘standard’ set.
Solution > install missing nodes.
In Node-RED. Top right hand ‘hamburger menu’ next to ‘deploy’. Select ‘manage pallet’. Select ‘install’ tab.
Type ‘buffer-parser’ into the search bar, and node-red-contrib-buffer-parser should appear. Install.
Installation of contribution nodes should be done with some due diligence first. You almost certainly will need to redeploy, and may have to do a refresh/restart of Node RED.
And - from time to time I have found it worth going into the pallet manager to check for installed nodes that are due for an update.
1 Like
Thank you, worked first time and a lesson learned. Fantastic community, even better contributor.
Panels and kit just arrived, install Thursday.
Will report back
Tony
Good luck. More recent posts have suggested that Solis are now shipping a newer WIFI data stick that has changed yet again. This post is related to using ‘server B’ option, success with which varies from possible to erratic and to not possible according to type (LAN/ WIFI) and age (protocol) of the Solis (SolarMan) data stick.
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
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