I have a fairly fresh installation of MultiPlus-II (3P) and GobelPower Batteries running now quite well after my latest addion of a VM-3P75CT as a grid meter. I’m still working on the additional PV using SmartSolar MPPTs (DC-coupling), but my 12yr-old 4.3 kWp PV is not visible to my GX/ESS as single phase AC-Coupled-PV.
The StecaGrid3600 is quite old and only provides readings via a proprietary RS485 interface. I did reverse engineer the Steca RS485 protocol some time ago ( GitHub - Aeroid/stecagrid_rs485: A simple script to read out StecaGrid inverter using rs485 ), so I do get the momentary inverter AC output (W) and DC (panel) input (V/A/W) and publish that via MQTT to my Home Assistant at short invervals.
My primary goal is of course to use and charge my batteries, but I do have a fairly nice fixed price to sell this energy (14c/kwh), but only from that old PV! So there is no need to limit the Steca production: my grid is fairly reliable and it would also make sense commercially. Allthough my Victron installation doesn’t know anything about this PV, it does limit grid use and redirects oversupply to the batteries… works fine, as far as I can tell from the last few days.
But here comes my challenge:
Assuming my new PV (additional 8kWp) will “outshine” and become my primary supply (batteries and day consumption), I might as well want to primarily supply the Steca PV output (amount) to the grid as much as possible, when it’s not needed to be fully charged at the end of the day.
One very simple idea was to simply add an alternative clamp to be switchable to 3P75CT on Phase 1 behind and in front of the PV AC coupling point. That would exclude the AC-in-coupled Steca PV and 3P75CT & GX would assume that to be part of the grid supply completly. This very crude but simple hardware approach could be a simple “summer/winter” switch or might be automated via a relais I’m sure.
But how can I possibly make my ESS and GX aware of this PV supply and possibly solve this via software by actively managing the “Grid Setpoint”? This might not be as simple as the fourth clamp, but might be more complete as the ESS would know about the extra 4.4kWp PV. And yes, I’ve planned to use dynamic ESS for the winter when all of that PV won’t fully charge my batteries.
Can I partially emulate a Fronius/SMA/etc inverter by software? (I already looked into emulating the 3P75CT UDP stream, but that’s just a meter, not sure if ESS/GX will treat this as PV supply properly)
Can I publish MQTT data to make the GX aware of the Steca PV power?
Thanks, I saw that before and I was a bit confused if that’s still needed since there was mention of the related dbus-mqtt was replaced by dbus-mqtt-flashmq-plugin … but, yes I saw the pvinverter example there.
Am I then getting it correctly, that the registration can’t be done via MQTT, but after the successful registration I would be able to supply the partial data via MQTT?
What is “Energy/Forward”?
Other that that I would be able to supply
Ac/MaxPower
Ac/Power
Ac/Current
Ac/L1/Current
Ac/L1/Power
Ac/L1/Voltage
Would that then be suffient for the ESS?
Let’s ingore that I have an Ekrano GX and I’m a bit hesitant to customize the installation (not sure if even possible). So if the registration would work via MQTT, that wouldbe much appreciated.
Oh, maybe you do mean “installation” rather than “registration”, then.
Well, installation cannot be done via mqtt, I am afraid.
This is not an officially supported modufication (but it should be, IMHO).
If it would be just the installation/registration process that needs to happen once somehow and thereafter I would be able to supply the data via MQTT I would look into that.
Can I simply install a PVInverter (e.g. via dbus or similar) on the commandline of the EkranoGX?
I found this: github .com/victronenergy/venus/wiki/dbus#pv-inverters
And would map the Steca readings as follows
Steca 3600 PVInverter Notes
Total yield -> /Ac/Energy/Forward <- kWh - Total produced energy over all phases
Grid power -> /Ac/Power <- W - Total power of all phases, preferably real power
(Grid power/Grid voltage) -> /Ac/L1/Current <- A AC
Total yield -> /Ac/L1/Energy/Forward <- kWh
Grid power -> /Ac/L1/Power <- W
Grid voltage -> /Ac/L1/Voltage <- V AC
3600 W -> /Ac/MaxPower <- Max rated power (in Watts) of the inverter
Leaving Position,StatusCode, ErrorCode at defaults
You can install a PV-Inverter if it is compatible with the GX.
This means compatible with the (modbus(-tcp) / web-APi of that manufacturer or model.
SMA uses sunspec, Fronius, Kostal use differnt specs, maybe.
You could, of course. simulate a well-known pv-inverter via an RPi running Node-red, ioBroker or simular (i.e. providing a Modbus/modbus-tcp interface known by the GX) and feed /provide the data from your steca through that.
I’m the author of the dbus-mqtt-devices driver. Victron provide an interface over MQTT for reading and writing values on the dbus. My driver just lets you register your own device via MQTT so that you can use then use the standard Victron MQTT interface. My advice to anyone wanting to register their own device is to first experiment by defining a simple temperature sensor before moving on to something more complex. There are examples in the README and in the samples folder.
@freakent Thanks for the advise, appricated!
Would you recommend using your driver on any EkranoGX?
Or would you know/recommend a different (external) method to register a custom PVInverter?
Registration is not a one time process. Every time you connect to MQTT you should also register the device using a “connect” message. This is all explained in the README. If you think about the way most devices connected to a GX device, it’s via a cable. The GX device registers the connected device when the cable is inserted and deregisters the device when the cable is disconnected. The dbus-mqtt-driver emulates this over MQTT. If your device disconnects from MQTT broker it should be unregistered.
The driver should run fine on your Ekrano. I have an Ekrano too now. You may get an error during install, but check the troubleshooting guide in the readme and install the dependant library as explained. This is a temporary work around until I release a minor update.