diy solar

diy solar

DIY Vendor agnostic Smart Shunt & Victron Smart Solar MPPT data logger based on ESP8266

And the smart shunt for all of them?
Yes. Between the battery and rest of the world so I can count AH in and out of the batteries. The inverters - 1 Samlex 600W PSW that is electrically quiet for my 125W 24/7 loads, and my PC's that consume another 250W), and 1 Victron 24/1200, for charging my EV, and in an emergency run the fridge and freezer as it can actually start them.
 
If you don't mind to tinker a little bit wiring a dozen of wires on a prototyping board,
I can provide a variant that does the same as a Victron smart shunt e.g. for your two Epever SCCs and / or the inverters.
I have already done it as an ESP8266 data logger.

The bill of materiel will roughly be:
-An ESP8266 (e.g. Wemos -D1)
-An INA226 voltage / current monitor board e.g. https://www.ebay.com/itm/386196324315
-A micro buck converter to DC 5V
-A soldering prototyping board
-A power shunt (if not already present)
-Optionally an OLED display for the Wemos-D1 if you want a local display.

It will be able to monitor batteries up to a voltage of 36v (24V nominal) and currents determined only by the shunt used.
And the best: it will send it's data over WiFi to a Victron-On-Steroids device ! (beside doing it to Telnet and -if required- to Thinger.io)

I am on a family trip and can't post a picture yet, but will upload asap the code to Github. The rest following in January.
 
If you don't mind to tinker a little bit wiring a dozen of wires on a prototyping board,
I can provide a variant that does the same as a Victron smart shunt e.g. for your two Epever SCCs and / or the inverters.
I have already done it as an ESP8266 data logger.

The bill of materiel will roughly be:
-An ESP8266 (e.g. Wemos -D1)
-An INA226 voltage / current monitor board e.g. https://www.ebay.com/itm/386196324315
-A micro buck converter to DC 5V
-A soldering prototyping board
-A power shunt (if not already present)
-Optionally an OLED display for the Wemos-D1 if you want a local display.

It will be able to monitor batteries up to a voltage of 36v (24V nominal) and currents determined only by the shunt used.
And the best: it will send it's data over WiFi to a Victron-On-Steroids device ! (beside doing it to Telnet and -if required- to Thinger.io)

I am on a family trip and can't post a picture yet, but will upload asap the code to Github. The rest following in January.
Totally interested and up for it. FWIW, I prototype, build, and do PCB layouts mostly as a hobby, sometimes for work, usually using smt parts. Not much scares me. Enjoy your trip - looking forward to details when you get the time!
 
Totally interested and up for it. FWIW, I prototype, build, and do PCB layouts mostly as a hobby, sometimes for work, usually using smt parts. Not much scares me. Enjoy your trip - looking forward to details when you get the time!
I have drawn the schematic:
The project will now have several options:
a) plain Victron logger from the VE-direct port.
b) Vendor-agnostic smart shunt based on the INA226 chip and an extra shunt.
c) Extra-voltage measurement that can be used to measure half-battery voltage or double battery voltage*

*the INA226 chip can measure up to 36V off-rails. Also the small DC-DC converters are usually limited to 28V max.
So if you have a 48V battery system, you must feed the measurement from the lowest 24V battery, and use the extra-voltage measurement to get the full battery voltage.
If you have two 12V batteries and a 24V system, you feed the measurement normally from 24V and use the extra-voltage measurement to get the half battery voltage.

Finally I will use a cheap ESP8266 as the hardware-base for all measuring units with each the capability of reporting one device/battery (Telnet/Thinger.io/UDP)
Later I will use an ESP32 that has more memory to aggregate several ESP8266 over WiFi/UDP to make one wireless central reporting and local display unit.
2024 will be a good year...
 
Last edited:
Totally interested and up for it. FWIW, I prototype, build, and do PCB layouts mostly as a hobby, sometimes for work, usually using smt parts. Not much scares me. Enjoy your trip - looking forward to details when you get the time!
So if you have the stuff at hand, so please check the intermediary project
with your Victron 150/45 and the Victron smart shunt hardware, which i don't have.
Maybe (probably) we'll have to provide more config files, if their protocol is different from the basic already tested lower-end devices.
 
Finally I will use a cheap ESP8266 as the hardware-base for all measuring units with each the capability of reporting one device/battery (Telnet/Thinger.io/UDP)
Later I will use an ESP32 that has more memory to aggregate several ESP8266 over WiFi/UDP to make one wireless central reporting and local display unit.
2014 will be a good year...
have you been going 88 miles an hour in your DeLorean again? ;) ?️ ⏲️
 
Actually i am looking for a micro-DC-DC buck converter that can be fed by a 24V nominal battery. That battery can go up to 30V.
The highest voltage I have found for tiny buck converters is 28V featuring a MP1584 chip.
So, since the power drawn is quite low, a possible solution could be to lower the input voltage by a Zener of, say, 5V, 0,5 or 1W?
That would put the input voltage of the buck converter to a safe 16-25V.
Have you a better solution? A mini buck converter that accepts 36V?

I have 12V and no problem. Of course if your 24V battery is done with 2x12V you are on the safe side, but I would prefer designing a solution that fits 24V batteries.
 
Last edited:
I am now preparing the software to following configurable features:
  • Gathering weather data from OpenWeatherMap
  • Communications between ESPs
  • Thinger dashboard
  • OLED display
So you can define
  • what does A1,
  • If you use Victron VE on D7 or
  • If you use an INA226 on a shunt,
  • If you use an OLED display and which one,
  • If you gather weather from the internet
  • If you use a dashboard service (now Thinger, possibly InfluxDB)
  • If you use UDP to forward/receive data and with which address/ports
The configuration looks like that:
Code:
//----------------------- HARDWARE OPTIONS ---------------------------------

#define AO_IS_NONE        // _NONE , _DOUBLE-BATTERY , _HALF-BATTERY , _PANEL
#define D7_IS_NONE        // _NONE , _VICTRON
#define OLED_IS_NONE      // _NONE , _48*48 , _128*48
#define INA_IS_NONE       // _NONE , _226
#include "MPPT_75_15.h"
#include "LIFEPO_24_100.h"

//----------------------- SOFTWARE OPTIONS ---------------------------------
#define WEATHER_IS_NONE   // _NONE , _OWM             // (Source of the Weather Information)
#define DASHBRD_IS_NONE   // _NONE , _THINGER         // (Internet Dashboard)
#define UDP_IS_NONE       // _NONE , _SEND , _RECEIVE // (UDP Inter-ESP Communication)
#define UDP_ADDR   "192.168.188.32"                   // (IP of the receiving ESP)
#define UDP_PORT   4200                               // (Port used to send/receive Values to other ESP)
....

On Github I have reorganized the files and put the files in dedicated folders
  • Hardware
  • Software
  • Configuration
  • Documentation
I have split the hardware configuration into individual configuration files for each type of Victron SCC , Victron Smart Shunt, Battery type etc. so to configure, you just include the file you need.

In final with the same program you will be able* to use an (several) ESP8266 devices to:
  • read Victron data and use it directly with Telnet / Thinger.io and optionally display on a built in OLED screen
  • measure shunts and use its data directly with Telnet / Thinger.io and optionally display on a built in OLED screen
  • mesure an individual voltage over A0 and use its data directly with Telnet / Thinger.io and optionally display on a built in OLED screen
  • for all three above mentioned purposes instead of using data directly, forward it over WiFi UPD to another ESP8266 inhouse that will use it with Telnet / Thinger.io and optionally display on a built in OLED screen.
* that is to 80% recycling of code from my other project Drok-Juntek-on-Steroids, so progress will be fast.

With another program running on an ESP32 you will be able** to receive the data from several ESP8266 to compute aggregations and forward all data to Telnet / Thinger.io and optionally display on a built in LCD screen.

** that will come as well, but may take a couple of months because I won't be able to recycle as much code.
 
This is all progressing quickly :) (y)

Who are the questions aimed at?
I am not directly asking questions, but I would be happy to hear from you, if I am doing it in a way that is useful and understandable for the most people.
I would also appreciate collaboration:
  • testing the preliminary (see #46) with Victron hardware, that I don't have,
  • eventually tell me from realised serial interfaces to other manufacturers,
  • proofreading my GitHub stuff and giving me advice on how to formulate it in a way that is understandable by noobs,
  • give me input on proven c++ methods to evaluate SOC from battery voltages,
  • later design a PCB for the ESP8266 that can host all options.
 
Last edited:
Sorry, not enough :coffee::coffee:, I'd read that as "So can you define", doh! All sounds interesting and happy to input my 2p worth over time. The inter-ESP comms sounds very interesting / useful. I can certainly contribute to the "proofreading my GitHub stuff" bit. I suspect the "proven c++ methods to evaluate SOC from battery voltages" will be impossible to achieve any degree of accuracy, compared to coulomb counting, apart from in the knees and with low load levels.
 
Sorry, not enough :coffee::coffee:, I'd read that as "So can you define", doh! All sounds interesting and happy to input my 2p worth over time. The inter-ESP comms sounds very interesting / useful. I can certainly contribute to the "proofreading my GitHub stuff" bit. I suspect the "proven c++ methods to evaluate SOC from battery voltages" will be impossible to achieve any degree of accuracy, compared to coulomb counting, apart from in the knees and with low load levels.
The inter-ESP stuff is the easy part.
I have grouped all the primary variables into a structure. I send the memory content of that structure over UDP and receive it 1:1 at the other side.
Code:
struct payload {
//***Operating Values from Victron/SmartShunt***
float BatV;           // V   Battery voltage, V
float BatI;           // I   Battery current, A
float BatW ;          //  BatV*BatI

float PanV;           // VPV Panel voltage,   V
float PanI ;          // PanW/PanV
float PanW;           // PPV Panel power,     W

float LodI ;          // IL  Load Current     A
float LodW ;          //  LodI*BatV
float IOhm ;          //  dV / dI

int   ChSt;           // CS  Charge state, 0 to 9
int   Err;            // ERR Error code, 0 to 119
boolean LodOn ;       // LOAD ON Load output state, ON/OFF
} payload;
Its fast and simple.
But is NOT compatible with different receiver hardware / software version.

Regarding the SOC computation, I have already an evaluation of the internal resistance; I imagine computing the internal battery voltage to compensate the effect of current and make a polynomial linearization from it.
Eventually two or three different linearizations for charge/discharge/float? It would be fine to get that from the battery chemistry configuration file. Precision will be... what it is. (+-10% seems acceptable to me).

Coulomb counting is possible, requires however periodic calibration of the capacity.
I will provide a capacity evaluation too, but it needs a full charge / discharge cycle without parasitic effects.
 
Last edited:
I made a major upload to Github.

Now you can configure whether you want a console on Telnet, SoftwareSerial or Serial (the later when no Victron serial is used)
Generally the configuration is easy to understand:
Code:
//----------------------- HARDWARE OPTIONS ---------------------------------

#define AO_IS_NONE        // _NONE , _DOUBLE-BATTERY , _HALF-BATTERY
#define D7_IS_NONE        // _NONE , _VICTRON
#define OLED_IS_NONE      // _NONE , _48X48 , _128X48
#define OLED_IS_NORMAL    // _IS_NORMAL, _IS_REVERSED To turn the display 180° if required
#define INA_IS_NONE       // _NONE , _226
#include "MPPT_75_15.h"
#include "LiFePo_13V_100Ah.h"

//----------------------- SOFTWARE OPTIONS ---------------------------------
#define WEATHER_IS_OWM    // _NONE , _OWM                // (Source of the Weather Information)
#define DASHBRD_IS_NONE   // _NONE , _THINGER            // (Internet Dashboard)
#define TERM_IS_SERIAL    // _NONE , _TELNET, _SERIAL , _SOFTSER // where do Menus and Reports occur: _SERIAL and D7_IS_VICTRON mutually exclusive )
#define UDP_IS_RECEIVE       // _NONE , _SEND , _RECEIVE // (UDP Inter-ESP Communication)
#define UDP_ADDR          "192.168.188.5"                // (IP of the receiving ESP)
#define UDP_PORT          4200                           // (Port used to send/receive Values to other ESP)
 
#define DEVICE_NAME            "Victron-Steroids-3"

You can already split the functionality between an ESP8266 at the Victron sending to another one indoors, which reports the data and more...

Quite a good part of my plans is already working:

Work progress​

Victron Input processing: Working for SmartSolar 75/15, looking for confimations for other modules especially SmartShunts
  • Victron Input Translation: Working
  • Shunt INA 226 input processing : programmed, can't test yet.
  • A0 input processing: Easy, but not yet done.
  • OLED Display: Programm chunks exist, can't test, further progress in January
  • Weather Data: Working
  • Thinger dashboard: currently testing, not a big issue since program exists
  • Serial communication: Tested for Telnet, SoftwareSerial and Serial (on receiver only)
  • UDP synchronization between Sender-Receiver: Working
  • Evaluation of battery internal resistance: apparently Working, plausible results.
  • Evaluation of SOC: ideas not yet done:
  • Coulomb counting by hours: Programmed (need Thinger to make it Reset-surviving)
  • Streamlined configuration, Switching options: Working
  • Menu over Serial, Telnet, SoftwareSerial: Working
  • Reports: Working

My Todo List​

  • ESP32 Gateway and Domotic processing (Scheduled for Q1 2024)
  • Finish work/tests wenn Hardware at hand
  • Battery capacity measurement (over full cycle)
  • Other domotic sensors (Temperature, Humidity, Light flash counter, whatever...)
  • Other domotic actuators (Heating valves, Sender for wireless plugs...
  • Documentation, documentation, documentation...

Input required !​

  • Test with other Victron products
  • Provide other manufacturer serial processing?
  • Provide algorithm to evaluate SOC
  • Provide input for Battery capacity measurement (over full cycle)
  • Proofread my documentation tell me where it's hard to understand.
  • Make the Victron serial processing working without configuration files
  • Reasonable improvement suggestions, especially to streamline the code (while keeping readability)
 
Last edited:
The reports are getting more and more elaborate:
Code:
14:13:33.999 -> Waiting for input

14:19:17.504 -> B
14:19:17.504 ->  Battery Stats
14:19:18.143 ->  Hour   |   00   |   01   |   02   |   03   |   04   |   05   |   06   |   07   |   08   |   09   |   10   |   11   |
14:19:18.178 ->  Bat Ah | +4.823 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.955 | +0.959 | +0.958 |
14:19:18.253 ->  Bat V  | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +13.320 | +13.430 | +13.470 |
14:19:18.320 ->  Hour   |   12   |   13   |   14   |   15   |   16   |   17   |   18   |   19   |   20   |   21   |   22   |   23   |
14:19:18.387 ->  Bat Ah | +0.957 | +0.955 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 |
14:19:18.453 ->  Bat V  | +13.600 | +13.700 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 | +0.000 |

14:19:24.747 -> W
14:19:24.747 -> Weather list :
14:19:25.146 -> Temp: 9.3 Hum: 91.0 Press: 1002 WindSpeed: 4.6 Direction: 160 %Clouds: 75 Summary: light intensity shower rain

14:19:33.642 -> V
14:19:33.642 -> Values Report
14:19:34.138 -> BatV:13.35 BatI:-0.010 BatW: -0.13 PanV: 0.01 PanW: -0.13, LoadI 0.00, LoadW 0.00, IOhm 0.0014
14:19:35.142 -> BatV:13.35 BatI:-0.010 BatW: -0.13 PanV: 0.01 PanW: -0.13, LoadI 0.00, LoadW 0.00, IOhm 0.0014
14:19:36.163 -> BatV:13.35 BatI:-0.010 BatW: -0.13 PanV: 0.01 PanW: -0.13, LoadI 0.00, LoadW 0.00, IOhm 0.0014
14:19:37.148 -> BatV:13.35 BatI:-0.010 BatW: -0.13 PanV: 0.01 PanW: -0.13, LoadI 0.00, LoadW 0.00, IOhm 0.0014
14:19:38.148 -> BatV:13.35 BatI:-0.010 BatW: -0.13 PanV: 0.01 PanW: -0.13, LoadI 0.00, LoadW 0.00, IOhm 0.0014

14:19:38.621 -> J
14:19:38.621 -> Job Timing
14:19:39.155 -> Job Durations(mS) Current - Max
14:19:39.155 -> Vict:000 - 001
14:19:39.155 -> Fast:000 - 002
14:19:39.193 -> Slow:000 - 001
14:19:39.193 -> Stat:000 - 220
14:19:39.193 -> Disp:000 - 000
14:19:39.193 -> Seri:-998 - 314
14:19:39.193 -> Wifi:000 - 001
14:19:40.141 ->

And the battery report B, is optionally pushed over UDP to another computer every midnight, to be appended to a logfile.
 
Last edited:
Now made a major upload on
Victron-on-Steroids
what I can test without specialized hardware works.
Look at the progress on the README.md and the docs on /Documentation, I have documented examples with screenshots.
I will now make a longer Christmas pause from programming. Just evtl. add documentation...
I encourage you to download, compile and test...
I hope some contributions/suggestions/improvements will come.
It's not motivating, when nobody participates.
 
I hope some contributions/suggestions/improvements will come.

Bit busy for the next day or two, but I will feedback on the following - have already had a quick look at your previous code (y)

  • Proofread my documentation tell me where it's hard to understand.
  • Reasonable improvement suggestions, especially to streamline the code (while keeping readability)
 
Back
Top