These ESP devices are really fantastic little devices. I have also been playing with Micropython on some.
1 Like
So I build dongles for Deye/Sunsynk to integrate them directly into HA and I sell them online.
A friend of mine has a Deye 8kW with a 2kW solis on the generator input port.
He asked me to build a dongle that could grab the solis data, so I did. Now he is able to combine the two inverters into a nice unified view with real-time data and numbers (into home assistant) I thought I would post this here to show what can be done with a solis inverter and some home assistant magic
3 Likes
My intention here is to build something with a sunspec interface. That should make it compatible with a lot of equipment out there. The idea is also to make it fairly simple to add extra implementations. The web side will be somewhat brutally simple. You get this screen (already built, and completely ripped off Tasmota for the moment):
It simply translates from input to output.
I have no intent on selling this, it would be somewhat of a conflict of interest in any case (since I also maintain the sunspec stack for someone else).
It needs a few more tweaks to make it deal with bad configuration (a few try/except clauses), but as of last week it can already read a single phase Solis inverter and make it show up as a sunspec device.
Limiting is not supported (yet).
Of course it also has no special discovery features, and it never will. I assume your HA dongle probably does MQTT autodiscovery?
Also, I have zero intent of building hardware and selling it. As far as possible Iām trying to stick with what is on the board already. For example, the āI need to active the local AP to reconfigure thisā button is simply the GPIO0 button on the board (to the right of the USB socket), so that people literally only need an ESP32 and an RS485 interface to get it going.
I did try to see if I can find existing hardware that has RS485 onboard. It does exist, but it is costly. An ESP32 is like R250, and the RS485 board can be had for under R50.
4 Likes
I opted to not to add any MQTT. Everything is native Home Assistant components which makes the integration work like it was part Home Assistant from the beginning. It makes writing automations as simple as selecting the option from the dropdown.
So let me understand your device. It connects via RS485 to a meter/inverter and translates the modbus to Sunspec output via network(WIFI)? Sending it directly to the CerboGX / Venus OS to see a unified display?
It essentially remaps the modbus registers. That is all it does. It takes register value X, does some optional conversion to it, and stuffs it in register Y.
Then it also converts an RTU connection to TCP. That is, it also acts like an RTU<->TCP bridge.
The output layout is sunspec, so that Venus-OS can detect and read it automatically. It doesnāt send it there, Venus-OS fetches it.
There are however two kinds of sunspec by now. There is the older kind, and then there is the new IEEE 1547 layout that a handful of new inverters are using (models in the 700 range). I also need a development platform to build this, so this will serve that purpose as well.
Sunspec, for interest, works like this. You have several āmodelsā, which are essentially numbered blocks. Every block starts with a number (the model number) and then a length (how long the block is), with the next block following after it. So to traverse the entire space quickly and see what is available, you read two blocks (model number and length). If you are interested in that model, you make a note of where to find it, otherwise you use the length field to skip over it, and you repeat the process.
Before the very first block (at address 40000), you put two registers with the values [0x5375, 0x6e53], āSunSā in ascii.
Any remote service can then detect sunspec by reading just two registers, and once it knows you support sunspec, it can traverse the models and check if the ones it needs are there.
For the purposes of this task, the vast majority of the modbus space simply returns 0xFFFF. Iām only implementing the bits needed.
2 Likes
Alright, here we go. For the tinkerers, you can find it here.
Very threadbare at the moment. The limiting support was blindly coded last night and is completely untested. No support for 3-phase (that needs writing the solis3p.py module, and adding a call so model 101 can be changed into model 103 (to reflect the phase count).
3 Likes
I guess if you wanted to you could also modify the project to also do Modbus TCP non-SunSpec to Sunspec for the guys out there with SMA inverters? (IIRC you once said SMA does kind of use Sunspec but they also donāt implement it fully)
Well, a lot of detail to that part of the story!
SMA does fully support sunspec, but the support is very model specific.
Some inverters need to be āunlockedā. There is a specific procedure to perform (essentially writing a password to the right registers), and then it will allow you to control them remotely.
Some inverters support model 123 out of the box, but the register is write-only. In earlier versions of the Victron Sunspec implementation, that broke things. ABB/Fimer has since broken that a second time, so a readable WMaxLimPct (the name of the field) in model 123 is no longer a requirement.
Their latest inverters use the new IEEE 1547 models (701, 702, 704), for which there is zero support at the moment. To get them working, at least models 701 and 702 needs to be implemented.
The reason SMA limiting was never implemented, was precisely because of the added complication in activating it, or detecting if it was supported.
Then we have SolarEdge also out there. They are no longer a SunSpec alliance member, but they do still support it. Their cheaper inverters only allow a single concurrent TCP connection, and they donāt support anything but the bare minimum. They do (apparently) have their own register somewhere for limiting, which could in theory be supported, but there is really little demand for it.
Tried to wire the ESP32 to the Solis for real yesterday and today, and the modbus comms totally stopped working. The Solis has a 5V supply on the socket, so the obvious answer was to use that to supply the ESP32 (which has its own 3.3V regulator) and the MAX485. I eventually threw the scope on it, and since RS485 is differential, I put one probe on each data line. Data-B had a clear signal on it, but Data-A was just a flat line. Something about the way this works is grounding out Data-A.
I snipped the power supply and plugged it in with an external supply, and it started working immediately.
Sooooā¦ there is a bit more to this than I thought. Iām probably going to need an isolated RS485 comms chip of sorts. Or just power it with a separate USB PSUā¦ which is more Ghetto than I was hoping for.
@plonkster Came across this and read with mounting interestā¦! I like Solis but the lack of Victron comms has been limiting. You made any progress again?
The code is available and should workā¦ though the limiting was not fully implemented or tested. I implemented limiting (via sunspec), but of course the Victron side doesnāt use it, and I didnāt get around to testing it.
If you use an ESP32, wire it to a suitable RS485 board, get a suitable way to power it (I discovered I cannot use the 5V supply on the Solis without isolating either the power supply or the comms), then it should already work.
Code is here, written in micropython:
It has a demo mode now.
The initial approach, to add this as a Venus driver, has been put on ice. Mostly because the original driver base did not have a distinction between input- and holding registers, and adding that in a way that appeased my fellow developer, compared to the excitement of playing with an ESP32ā¦ well the latter won out. But it might still happen, because there is some generator controller that needs input registers to work and that might incentivise starting up a pure venus driver again.
I kinda sorta lost interest, not completely, just got busy with other things.