Batterimonitor

Webbsidan skapad 2022-04-10
 Till dokument slut 

Batterimonitor typ "tankmätare" för batterier där man summerar ström / effekt till batteribanken över tid till Ah/Wh urladdad status från 100% SOC fulladdat. Utifrån känd C20-batterikapacitet kan man då även försöka ange en relevant SOC-status för laddnivån som 0-100% SOC.
Är en väldigt viktig grundläggande funktion i ett off-grid solcellssystem för batteridriften!
NordicOffGrid ESP32-Batterimonitor övervakar många fler parameterar för driften än Ah/Wh så utgör en driftsövervakning av off-grid solcellssystemet, med även historisk data och statistik!
Gör även om rå mätdata till information, s.k. aggregerad data, med mer info över driften.
Det jag gör här blir mer som en "Battery System Monitor" (BSM) än en ren batterimonitor, med autonom proaktiv förbrukarstyrning för skonsam hantering av batteridriften!
Batterimonitorn kommer visa data och drifsstatistik med inställningsmöjligheter dels på en strömsnål LCD 16x2 teckendisplay, dels via local console on a network (LAN) dvs Webbsidor från webbserver i ESP32 via WiFi, vilka kan visas i webbläsare i mobilen, på laptop eller dator.
Batterimonitorn används i projektet: PWM-solladd­regulator
"Att mäta är att veta" myntades redan på 1800-talet av Werner von Siemens!
Kommer uppdatera här efterhand som jag utvecklar Batterimonitorn.
Innehållet här är huvudsakligen råa minnesanteckningar i dagboksform till mig själv som dokumentation av projektet, men här och där är även mer beskrivande / förklarande texter inlagda.
I aktiv drift i mitt lilla experiment off-grid solcellssystem sedan 2023-02-20.
Men med mycket vidareutveckling av kod och funktion sedan dess så blivit betydligt kraftfullare, mer funktionellt, feltolerant och robustare med tiden!

Hur avläsningen av mätdata går till i elektroniken 2024-08-23

Jag använder en INA260 med 15A intern strömshunt för solcellsströmmen, som med mina 250Wp solcellseffekt aldrig kommer över 15A, samt en INA226 med extern strömshunt på 100A/50mV som mäter batteriströmmen. INA260 ska klara 15A kontinuerligt.
Och skillnaden mellan dem blir förbrukarströmmen.
Båda mäter med 16bit upplösning, så mäter ström på mA-nivå, samt de är extremt långtids- och temperatur-stabila så jag inte trodde det var tekniskt möjligt.
De är även fabrikskalibrerade så med 0A genom strömshuntarna ger de mätvärdet 0,0000A ut! Är från Texas Instruments så man kan lita på dessa uppgifter.
Båda INA-sensorerna kan självständigt sampla ett antal ström / spänning / effekt mätvärden som de sedan medelvärdesbildar och sparar i ett register ESP32 kan hämta dem ifrån då de sätter en interrupt-flag för det, medan de fortsätter med nästa samplingsserie. Finns ett antal olika fasta samplingsintervall och antal sampel som ska göras man kan välja bland.
ESP32 läser av mätdatan från dem via I2C-buss.
Så jag låter dessa INA-sensorer sampla 1024st mätdata självständigt under ca 1,2s som de då medelvärdesbildar. Interrupt-signalen för nya mätvärden att avläsa triggar då en ISR (Interuppt Service Routine) för respektive sensor i ESP32 som i sin tur triggar vars Deferred interrupt processing Task i FreeRTOS i min C++ kod. Genom att använda Deferred interrupt processing minimeras tiden och koden i ISR så ESP32 blockeras så minimalt det går av interrupten! En jäkla fin teknik.
INA260/226 fungerar därmed nästan lite som coprocessorer till ESP32 och avlastar mycket av strömmätandet.
Samplar därmed ström / spänning / effekt värdena drygt 50.000ggr/min, så följer även väldigt dynamisk ström med hög precision typ kylskåpskompressorns startström.
Utnyttjar även ESP32 light-sleep för strömsnål nattdrift, som den då väcks ur av interrupt-signalen från INA266 ca 1ggr/1,2s, så är aktiv mätning även då.
Är då i nattdrift mer än 95% av tiden i light-sleep som ger en märkbar strömbesparing, vilket inte minst är viktigt vid vinterdrift med de korta dagarna då och den minimala solcellsströmmen i mitt off-grid solcellssystem. Strömsnål nattdrift är nu 98,75 - 96,25% av tiden i light-sleep med ett medelvärde på 97,9%, från senaste mätningarna! Är riktigt bra.

Beskrivning av grundfunktion:

Genom att mäta den ström / effekt som laddas ur/i batterierna över tiden fås den strömmängd som påverkar hur mycket av batterikapaciteten som för tillfället lånats ur batterierna. Med 1A ström urladdning under 1h har 1Ah laddats ur batterierna, och motsvarande med 12W effekt urladdning under 1h har 12Wh laddats ur. Men då strömmen normalt varierar mycket över tid måste den mätas väldigt ofta och för varje sådant kort tidsintervall summeras ihop till den totala strömmängden.
För att få en bra noggrannhet över lite längre tid så måste både ström / effekt mätas väldigt noga och med stort dynamiskt omfång samt de korta tidsintervallen måste också kunna mätas med hög precision. Stort dynamiskt omfång betyder att man måste både kunna mäta väldigt små strömmar och de stora som systemet är max dimensionerat för, då även väldigt små strömmar blir en signifikant strömmängd över en längre tid.
En ström på bara 10mA (0,010A) blir på en vecka till 1,7Ah.
Sedan tillkommer problem med att batteri­verknings­graden är lägre än 100%, att den varierar med hur fulladdade batterierna är samt med om driften hela tiden växlar mellan kortare ur/i-laddningar eller längre kontinuerliga ur/i-laddningar. Samt verknings­graden påverkas även av hur hög ström ur/i-laddningen sker med, det som kallas för Peukert´s law, och batterier har en viss självurladdning också. Detta är även olika för olika batterityper, där vanliga blybatterier har rätt stor inverkan av detta, blykol-batterier betydligt mindre och LiFePO4 ännu mindre.
Så för en bra batterimonitor-funktion bör det tas hänsyn till dessa förluster samt man måste även ha en väldigt stabil bra synkronisering mot 100% SOC fulladdad batteribank för att mot fulladdad batteribank kalibrera bort den drift / onoggranhet som ofrånkomligen summeras över tid.
Det enda säkra tillståndet att nollställa / kalibera batterimonitorn mot är 100% SOC fulladdade batterier! Så är en oerhört viktig funktion att få stabil med hög noggrannhet, som även sköter sig helautomatiskt själv utan inställningar av användaren.
Idealet för en batterimonitor är att den själv kan utvärdera dessa olika parametrar dynamiskt under drift, då de varier över dels tid, dels med temperatur samt dels med hur driften är. Så för bra noggrann långtidsstabil drift kan man inte ha fasta inställningsvärden för dessa, värden som dessutom är svåra för användaren att avgöra!
Så min ambition är att försöka utveckla en batterimonitor som hanterar detta själv, sedan får vi se hur långt jag lyckas nå med det. Är svårt så hela vägen når jag nog inte!
Mina analyser visar att batterimonitorn då måste ha tillgång till information om hur solladdregulatorn arbetar för stunden med batteriladdningen, direkt från regulatorn. Är inget som den själv kan utvärdera tillräckligt bra via sina egna mätvärden. Så jag tänker bygga en hybrid PWM-solladdregulator med integrerad batterimonitor. (Och solladdregulatorn i sin tur behöver veta strömmen in-/ut-ur batteribanken för bäst laddstyrning, så en hybrid är välmotiverat.)
2022-10-26
En frågeställning är dock hur får man till allt helt rätt när man har både sol och andra laddare samtidigt?

Peukert´s Law: 2022-10-14

I denna batterimonitor kommer jag inte alls ha med Peukert´s law för Ah- och SOC-beräkningar, samt kommer som första början räkna mot blybatteriernas nominella C20-kapacitet så får resten bara bli en extra marginal för åldrande vid moderata strömuttag.
Jag och en del andra som tittat rätt mycket på detta med batterimonitor är inne på att för batterimonitor i ett off-grid solcellssystem bör man inte alls ta med Peukert´s law så för SOC-beräkningarna, då det blir ett missbruk av den och Peukert´s law inte alls beskriver det driftsfallet eller en verklig förlust av batterikapacitet vid sådan växlande battericykling!

Peukert´s law gäller bara för en urladdning med konstant ström i ett svep från 100% SOC till "0% SOC" som bestäms av att urladdningen avbryts vid 10,5V batterispänning för 12V blybatteri. Så Peukert´s law gäller inte alls när man som i ett off-grid solcellssystem har ständigt växlande laddning / urladdning som det blir där!
Därmed är det väldigt osäkert vad den bidrar till i en batterimonitor? Bör ge helt fel resultat!
Är väldigt svårt att hitta kunskap kring hur blybatterier beter sig ur Peukert´s law synvinkel med en växlande daglig laddning från solceller och urladdning där emellan.
Peukert´s relation describes how the capacity is related to the total time to discharge the battery to 10.5 volts. Simply put, the reason you get less amp hours out when the amps are higher is that the higher amps drag down the volts more than a lower amp load, so the 10.5 volts endpoint is reached sooner. It is not because some of the electrons [capacity] in the battery get lost or wasted when you draw current out faster. [källa]
Så Peukert´s Law beskriver inte en förlust i batterikapacitet, utan bara hur mycket av kapaciteten som kan urladdas i ett svep för olika strömmar innan man når 10,5V batterispänning!
Vilket då är helt ointressant för en batterimonitor, inte minst i ett off-grid solcellssystem!
Handlar om tillfälliga polarisations-effekter som sänker batterispänningen under urladdning, mer vid högre ström, som återställs vid vila eller minskar signifikant vid låg ström, mer ju lägre!

Som exempel, låter man ett blybatteri som laddats ur till 0% SOC enligt Peukert´s law vila 24h så hämtar det sig och är inte längre urladdat till 0% SOC, utan en signifikant del av kapaciteten återkommer igen under vilan.
Och det är ju precis så driften sker i off-grid solcellssystem, där solcellsladdning i detta sammanhang kan ses som "supervila" för blybatterierna! Så vid ständig växlande laddning / urladdning får man inte alls de förluster i kapacitet som Peukert´s law beskriver när ett blybatteri laddas ur helt i ett svep!
It is a common misunderstanding that the energy not delivered by the battery due to Peukert´s law is "lost" (as heat for example). In fact, once the load is removed, the battery voltage will recover and more energy can again be drawn out of the battery. This is because the law applies specifically to batteries discharged at constant current down to the cutoff voltage. The battery will no longer be able to deliver that current without falling below the cutoff voltage, so it is considered discharged at that point, despite significant energy still remaining in the battery.
What happens is that the chemical process (diffusion) responsible for transporting active chemicals around the battery progresses at a finite rate, so draining the battery quickly causes the voltage to reach the cutoff level prematurely before all the active material in the battery is used up. Given time, the active material will diffuse through the cell (for example, sulfuric acid in a lead-acid battery will diffuse through the porous lead plates and separators) and be available for further reaction.
What Peukert really meant: When energy is drawn, battery voltage falls. As an example were a battery able to sustain 5 amps for 20 hours (before falling below 10.6 volts) it can be rated as being 100 amp hours.
When a heavier load (say 50 amps) is connected across that battery, its voltage falls more rapidly. After (say) 60 minutes, it is likely below 10.6 volts. The battery is consequently unable to sustain that discharge rate. But its energy has been depleted by 50 amp hours. No more – nor less.
A lead acid battery reacts very slowly. Once that 50 amp load is removed it slowly recovers. Off-load voltage will be 12.2-12.3 volts. It may still be able to supply 50 amps, but this time for only 30 minutes. Delivered available capacity is now 75%. The 25% remaining is still available, but now at five or so amps.
So, what Peukert really meant is that rate of discharge does not affect overall capacity. That which it affects is only its usable capacity when loaded above its rated current. In other words its rated capacity (energy) is still available, but only at its intended (rated) current. Some see that as "available capacity". [källa]

Men riktigt vad man får tillgång till för extra kapacitet vid moderata urladdningsströmmar vet jag inte, då jag hittat absolut noll kunskap kring det för denna växlande driften i ett off-grid solcellssystem. Så i ett senare skede ska jag troligen försöka utvärdera det ur blybatterispänningen vid lägre SOC när strömmen är som lägst nattetid utan solcellsladdning. Men då främst för åldrandet.

2023-08-02
Beräknat för 5 dygns dåligt-väder-reserv (C120) medelström skulle man då ur 100Ah C20 blybatterikapacitet kunna ladda ur 156Ah vid Peukerts exponent 1.25, vilket känns helt orealistiskt mycket! Det skulle innebära att vid C20´s 20h urladdning skulle bara 64% av det aktiva elektrodmaterialet delta i omvandlingen från laddat till urladdat kemiskt tillstånd, vilket känns helt osannolikt lite! Beskrivs även i en forskningsrapport: "The classical Peukert´s equation is not applicable at small discharge currents as according to this equation, at the discharge current decrease, the capacity released by the cells tends to infinity."
En annan forskningsrapport tittar på "Adapting the Peukert Equation to Batteries Discharged at Pulse Currents" och kom fram till "Therefore, the methodology proposed here may extend Peukert´s law to batteries in which the discharge current is not constant."
"Peukert´s law has always been applied to the discharge of batteries at constant currents. Today, however, there are more and more applications in which batteries are used with pulse currents (e.g. wireless sensors, electric vehicles, [off-grid PV-systems])."
Dvs Peukert´s law gäller inte för urladdning med varierande strömstyrka eller vid ständig växling mellan laddning och urladdning i solcellssystem (precis som jag bedömt).
En person med Victron SmartShunt batterimonitor tyckte den visade 76% SoC med Peukert exponent 1.25 kändes hög, då urladdade Ah motsvarade 50% SoC räknat mot fritidsblybatteriernas C20-kapacitet. Så han provade att ändra till Peukert exponent 1.00 och då visade SmartShunt 50% SoC. Ändrad tillbaka till 1.25 visades åter 76% SoC! Så Victron SmartShunt använder Peukert exponent för att räkna ut användbar batterikapacitet vs strömbelastning, vilket då vid låga strömmar (<C20-urladdning) blir en högre kapacitet än blybatteriets C20-kapacitet!
I detta fallet med 50Ah urladdat / 100Ah C20 har Victron SmartShunt för den låga strömbelastningen räknat fram 208Ah användbar kapacitet ur 100Ah C20-kapacitet, vilket är helt orimligt att det skulle stämma med verkligheten bedömer jag! Den ovan nämda forskningsrapportet säger samma: "The classical Peukert´s equation is not applicable at small discharge currents"!
De 208Ah ur 100Ah/C20 i SmartShunt-fallet motsvarar en Discharge Rate = 0.053 i Peukert-beräkningen dvs C20 / 0.053 = C377 urladdning i snitt (typ 15 dygns dåligt-väder-reserv).
Detta stärker också min bedömning att inte använda Peukert´s Law i batterimonitorer!
Även Mastervolt använder Peukert´s Law i sina batterimonitorer: "Peukert´s Law describes the effect of different discharge values on the capacity of a battery, i.e. that battery capacity is reduced at higher discharge rates. All Mastervolt battery monitors take this equation into account so you will always know the correct status of your batteries."
Balmar SG200 batterymonitor använder Peukert´s Law, men bara för Time-To-Go beräkningarna: "Changing the PEUKERT Value will not effect Charge Termination, only TIME REMAINING Calculations".
Simarine verkar också använda sig av Peukert´s Law via: "The nominal battery capacity for the next C ratings: C/20, C/10, and C/5. If you don´t know all the ratings, fill in just those ratings that you know. It is highly recommended to fill at least two C ratings (one is not enough for precise calculations).
Studer Battery Status Processor BSP 1200 använder också Peukert´s Law: "The capacity varies according to the discharge current. With this parameter one can set the Peukert exponent that goes along with the nominal capacity and nominal discharge time."
Trots detta är det min övertygelse att Peukert´s Law inte är tillämpbar för en batterimonitor, speciellt inte i ett off-grid solcellssystem! Finns tillräckligt med vetenskapliga rapporter och fakta som stödjer att Peukert´s Law inte gäller för fluktuerande strömurladdningar samt inte beskriver några kapacitetsförluster för kvarvarande batterikapacitet efter viss urladdning, anser jag!
Vid lite efterforskning finns det en Kinetic Battery Model (KiBaM) för drift i typ off-grid solcellssystem. Det finns en ur KiBaM vidareutvecklad modell "addressing four characteristics of operation: charging, discharging, rest after charge, and rest after discharge" Comprehensive Model for Real Battery Simulation Responsive to Variable Load (4-KiVM) som såifall kanske kunde användas i en batterimonitor i motsats till Peukert´s law. Referens till "The KiBaM battery model" finns i Wikipedia artikeln Recovery effect.
Mer: Battery Aging, Battery Charging and the Kinetic Battery Model: A First Exploration
A realistic model for battery state of charge prediction in energy management simulation tools, baserad på the Kinetic Battery Model.
HOMER uses the Kinetic Battery Model to determine the amount of energy that can be absorbed by or withdrawn from the storage bank each time step. (Visualiserar principen!)

Jag har av dessa anledningar inte heller med Peukert´s law i min Kalkylator små Solelsystem II då jag under min drift sedan 2007 i mitt off-grid solcellssystem inte kunnat se någon inverkan av det som Peukert´s law beskriver!
Jag hade med den från början men har under åren verkligen letat väldigt noga efter inverkan av Peukert's law i min off-grid drift och inte kunnat hitta några spår av den. Då har jag i och för sig rätt måttliga strömmar, men ska man klara 5dygns dåligt-väder-reserv kan höga urladdningsströmma bara förekomma väldigt korta tider av den totala driftstiden, så bör vara i stort samma för alla. Precis under en kortvarig hög urladdningsström borde man kunna notera en effekt av Peukert´s law, men sedan hämtar sig blybatterierna från den s.k "Recovery effect" / "Relaxation effect" (i stort helt vid driften i ett off-grid solcellssystem vad jag kunnat få fram).

Bogart Engineering med sin TriMetric batterimonitor beskriver tydligt varför de inte använder Peukert´s law i sin batterimonitor, och det utifrån över 25 års erfarenhet av att utveckla batterimonitorer.
När jag läser på Victrons webbsida om Peukert exponent för deras BMV 700-serie batterimonitorer får jag uppfattningen att Victron till stor del har missförstått vad Peukert´s Law står för och vad för effekt i blybatterier den beskriver då Victron bl.a. skriver "The capacity of a battery depends on the rate of discharge. The faster the rate of discharge, the less capacity will be available.", vilket känns lite märkligt ihop med batterimonitor i off-grid solcellssystem (även om Peukert´s Law missuppfattas rätt ofta, så förståeligt om även deras ingenjörer gjort så)!
Peukert´s exponent ökar även med blybatteriernas åldrande, så den kommer ju aldrig vara korrekt över tid, och som sagt beskriver inget fenomen användbart för en batterimonitor så som jag och en del andra uppfattat det. Samt den är många gånger svår att få tag på för sina blybatterier, men går att räkna fram om de har minst två kapaciteter angivna typ C5 / C10 / C20 / C100.
De delar av Peukerts effekt som eventuellt påverkar lite även vid cyklisk drift kommer då till stor del med som del av den utvärderade batteriverkningsgraden i batterimonitorn. Så med sådan funktion kan jag verkligen inte se något behov av Peukert´s exponent i batterimonitorn!

Utökad funktion: 2022-06-30 / 2023-04-18

För oss lite mer intresserade kunde det vara intressant med mer information än bara Ah och SOC från en batterimonitor, typ hur mycket ström som använts direkt från solcellerna och hur mycket som plockats ur batteribanken. Hur mycket av strömförbrukning som just nu kommer från solcellerna respektive batteribanken samt ström / effekt ut till utgående förbrukning.
Och vid off-grid för fritidsboende att man kunde nollställa och mäta för en boendeperiod där hur mycket av strömmen som solcellerna resp. batteribanken levererat samt systemet förbrukat, både för boendeperioden och senaste dygnet (24h). Ur det kunde systemet även mer smart beräkna hur länge till batteribankens dåligt-väder-reserv räcker utifrån senaste 24h drift.
Har man 5 dygns dåligt-väder-reserv i batteribanken och solcellerna levererar 75% av förbrukad ström i molnig väder så räcker den reserven då i 20 dygn som exempel.
Kanske även en prognos baserat på senaste timmens förbrukning, men baserat på momentan förbrukning som flera batterimonitorer idag gör känns rätt meningslöst.
Bra att få info om, men lite krävande att själv försöka uppskatta!
Även detta görs lättas genom en samverkan mellan solladdregulator och batterimonitor.
Jag tänker även försöka lagra data kortare tid lokalt i ESP32 (typ 24h till 7? dygn, samt viss nyckeldata kanske ett år och annan 30dygn) samt regelbundet koppla upp den mot egen webbplats inhyrd på webbhotell och lagra långtidsdata där. Så kan jag hålla koll på batteridriften även via Internet varifrån jag vill. Får se under utvecklingen hur mycket sparad data som verkar vettigt!
Sedan hade även någon form av "Battery state of health estimation (SOH)" varit bra, som även kunde larma om något batteri börjar bli dåligt, men får nog ses som överkurs.
Har dock lite funderingar på att övervaka float-ström när solladdregulatorn reglerar den, hålla koll på lägsta batterispänning nattetid samt kanske mäta batteribankens impedans när PWM-regulatorn strömpulsar fulladdad batteribank. Bör kunna ge viss insikt om batteribankens status om någon av de börjar avvika från de normalt uppmätta värdena över lite längre tid!
Även kanske jämföra olika tidsfiltrerade batteriverkningsgrads-mätningar, typ 1/1, 1/10, 1/100 & 1/1000 och se om det blir en tydlig plötslig förändring i batteriverkningsgrad över tid som då kan indikera utvecklingen av problem i blybatterierna! Borde kunna vara ett bra mått!

Hårdvara att bygga på:

Har nu detaljstuderat databladen för INA260 (datasheet) och INA226 (datasheet) och de har verkligen flera riktigt bra funktioner för att kunna bygga en batterimonitor med hög precision! Mer om INA260/INA226.
Dels kan man sätta ADC (Analogue to Digital Converter) conversion time till mellan 140µs och 8.244ms där längre tid ger en mer exakt avläsning, dels kan man låta dem beräkna medelvärdena för mellan 1 till 1024st mätningar, vilket också ger möjlighet till noggrannare mätning av ström och effekt. INA226 använder extern strömshunt med mätområdet ≤36V, ±81,9mV, 16-bit, som då ger möjlighet till externt RC-filter av signalen från strömshunten så ingen data missas mellan samplingarna typ kraftiga korta strömpulser. INA260 har intern 2mΩ strömshunt för ±15A och ≤36V 16-bit mätområde inom -40°C to +85°C. The device operates from a single 2.7V to 5.5V supply, drawing 310 µA (typical), så är strömsnåla också!
Innebär att med maxvärdena 8.244ms och 1024st mätningar fås nya exakta medelvärdesbildade aggregerade data 1ggr/8,64s och som snabbast ca 1ggr/140µs, som INA260/226 då arbetar självständigt med att samla in. Kretsarna har även en signalutgång som indikerar exakt när nya aggregerade mätvärden är tillgängliga, så man kan synka av läsningen av ström/effekt från INA260/226 hos ESP32-mikro-processorkortet med den, vilket görs via s.k. interrupt.
Den utsignalen skulle under långvarig standby-drift även kunna användas till att väcka upp ESP32 mikroprocessorkortet (källa2) ifrån strömsnål light-sleep och läsa av strömförbrukningen med upp till 1ggr/8,64s intervall och vara i light-sleep däremellan, som strömsnål batterimonitor! Men 2x (U+I) 1.1ms conversion time och 1024 averages, 1ggr/2,25s, är nog vettigt så kan responstiden på knapptryckning under light-sleep bli max 2,25s. Då borde kanske ca 22ms RC-filter bli lagom? Typ 4,12kΩ * 4,7µF, R82 50V (RC=19ms), så bör INA226´s 830kΩ ingångsresistans inverka minimalt på mätresultaten.
2023-02-16
Är bara INA226 spänningsmätning VBUS som har 830kΩ ingångsresistans, strömmätningens ingångar I_IN+/I_IN- har en Input bias current på typ 10µA, men uppmätt ca 35µA i drift!
Så går inte att göra en RC-filtrering på samma lätta sätt där som för VBUS!
Med 4,7µF/4,2kΩ (20ms RC) fick jag 341mA mätt med 500mA genom strömshunten! Utan 4,2kΩ mättes 501,7mA genom 60A/60mV shunten (LSB=1,8mA / 2,5µV).

Multiple INA226´s with INA226_WE library (limit: 4 INA226).
Kanske kan kombinera interrupt med ISR och light sleep wakeup på samma GPIO?
Låter möjligt: ESP32 using interrupt to momentarily wake from Light Sleep - bug?
Går att göra via ONLOW_WE / ONHIGH_WE attachInterrupt(pin, ISR, ONLOW_WE); där WE=Wakeup Enabled, dvs Interrupt och Wakeup från sleep på samma digitala ingång.
Kan göras som deferred interrupt via Queue API med tidsstämpling på 1µs upplösning för effektiv interrupt-hantering och exakt Ah-/Wh-summering / integrering.
Och ESP32 i sin tur har en 64-bitars tidmätning som mäter tiden med 1µs upplösning (0,000001s) och som bara startar om (overflow) 1ggr/292år så man kan mäta tiden mellan ström- och effekt-mätningarna med riktigt hög precision, vilken används för att summera ihop ström (A) och effekt (W) till Ah och Wh för värdena i batterimonitorn.
Ihop med batterier som trivs/tål att float-laddas 100% SOC längre tid (typ blybatterier) kan jag då även göra så batterimonitorn regelbundet automatisk nollströmskalibrerar sig under drift, vilket också ökar långtidsstabiliteten och precisionen. Har jag inte sett någon batterimonitor nu på marknaden har (möjligen BALMAR SG200). Kanske nollströmskalibrera sig mot den ström som är självurladdningen, då det egentligen är en strömförbrukning som inte ström­shunten kan registrera och inte bör komma med i ∑Ah / ∑Wh.
Ska bli spännande det här!

Mobil 4G Router Teltonika RUT241: 2022-07-30

Införskaffat den 4G-router jag ska använda för att överföra driftsdata från off-grid sol­cells­systemet till min webbplats server. Valet föll på en Teltonika RUT241 4G/LTE(Cat 4), 3G, 2G industriell router med bra rykte om stabil till­för­lit­lig drift, med bra temperatur­drifts­om­råde på -40°C - +75°C, drifts­spänning 9VDC - 30VDC samt chassit är i aluminium för bästa värme­över­föring och kylning. Drar uppkopplad mot 4G utan datatrafik 1,2W matad från 12V enligt wiki, <2,5Ah/dygn. Har rimligt pris för prestandan tycker jag!
"RUT241 is an excellent fit in various IoT and M2M solutions that require easy setup, reliable network, and remote accessibility.
Kommer använda extern rundstrålande puck-antenn placerad uppe i takluckan i husvagnen, då alla väggar av aluminiumplåt skärmar av rätt mycket där det är dålig mottagning.
RUT241 är en ny version av RUT240, beskriven som: "Teltonika RUT241 är en ny uppgraderad version av den klassiska industriella LTE-routern RUT240. De är nära identiska förutom styrkretsen som uppgraderats till Mediatek MT7628 som har väsentligt bättre tillgänglighet och något snabbare prestanda [580MHz vs 400MHz]." Samt dubbelt så mycket RAM-minne som RUT240, så plats för uppgradering till mer krävande OS i framtiden.

• Teltonika RUT241 4G/LTE(Cat 4, ≤150Mbps), 3G, 2G
• Teltonika RUT241 Flyer
• Teltonika RUT241 Datasheet
• Teltonika RUT241 Quick start guide
• Teltonika RUT241 Wiki
• Teltonika RUT241 Wiki Power Consumption
• Teltonika RUT241 Wiki Firewall
• Teltonika RUT241 Firmware Downloads
• COMBO MIMO Mobile ROOF SMA Antenna
• COMBO MIMO Mobile ROOF SMA Antenna, Datasheet
• Power cable with 4-way screw terminal
• Power cable with 4-way screw terminal, Datasheet
• Teltonika RUT240 Setup Wizard
• Teltonika: Mobile Signal Strength Recommendations
• RUT241 Remote Monitoring & Administration, JSON-RPC, Modbus TCP, MQTT, etc.
• Dustin: Teltonika RUT241
• Ställt in tidsserver se.pool.ntp.org & europe.pool.ntp.org hos RUT241: europe.pool.ntp.org Samt uppdaterat till senaste firmware.

ESP32 WIFI uppkopplad till RUT241: 2022-08-03

Har kopplat upp RUT241 här hemma nu och tycker WIFI känns helt OK! Har placerat RUT241 ute i köket med en armerad betongvägg i vägen in till vardagsrummet där jag sitter längst in nu. Får full signalstyrka på mobilen där ifrån RUT241 samt min ESP32 som är lite kinkig kopplade upp och synkade med tidsserver på Internet utan problem via RUT241 här längst in i vardagsrummet vid datorn.
ESP32 kopplar upp snabbare till RUT241 än till min bredbands-router som finns i hallen precis utanför dörröppningen in till vardagsrummet och således med bättre kontaktväg så utan armerad betongvägg i vägen. Och den är ändå bra.
I mobilen får inte min bredbands-router riktigt full signalstyrka hela tiden här inne i vardagsrummet, så RUT241 verkar ge något bättre WIFI. Här är ändå 14st andra routrar från grannar som sänder ut WIFI jag ser i mobilen, så är väl ingen perfekt miljö här precis tänker jag.
Har låtit ESP32 koppla upp och synka mot tidsserver via RUT241 8-9ggr nu och fungerar bra hela tiden. 2022-12-16 Nu har min ESP32 bootat och hämtat tid från NTP-server >1000ggr!
Så känns riktigt lovande för husvagnen och mitt kommande PWM-regulator + batterimonitor ESP32 projekt.
Lär ju få tillgång till WIFI även utanför husvagnen, vilket blir som en extra bonus då jag är fullt nöjd med bra Internet inne i husvagnen.
Jag får nu WIFI-signalstyrka RSSI -59dBm i ESP32, vilken anses som:
-50 to -67dBm – At Good signal strength for Web browsing, voice/video calls.
Wireless dBm table

Teltonika RUT241 4G-router i glesbygd: 2022-08-28

Tog med Teltonika RUT241 till husvagnen för test av funktion där. Är en ofta svag långsam intermittent mobil-uppkoppling där via mobilen, så en bra referensplats för funktion i bergig skogig Östgötsk glesbygd. Testade även hur ESP32 kan koppla upp och synka sin RTC mot tidsserver på Internet via RUT241´s wifi, och det skedde fint stabilt samt snabbt!

Fick -81dB signalstyrka med puck-antenn på soffbordet där nära mobilen samt pendlade mellan 2-3 (5) streck på RUT241´s indikator. Uppe i taklucka låg den på 3 streck signalstyrka större delen av tiden. Samt fick ned 4-8Mbit/s och upp 0,5-2Mbit/s med snitt runt 6Mbit/s ned och 0,7Mbit/s upp, en 5-10ggr snabbare än med mobilen direkt mot 4G! Är ofta låg kapacitet så hos basstationer ute i glesbygd, som brukar vara rätt hårt belastade så här vid 17:30-tiden på dygnet. Men den mest avgörande skillnaden var att RUT241 behöll sin uppkoppling stabilt med 2-3 streck i signalstyrka, där mobilen tappar den av och till lite längre perioder.
Och wifi räckte bra långt utanför husvagnen med bra signalstyrka 8-10m bort, trots husvagnens utsida av Al-plåt. Så jag känner mig helt nöjd med funktionen, som känns bättre än en del framhållit på Internet för föregångaren RUT240!

Adafruit Proto-Screwshield Arduino R3: 2022-12-01

Lödde ihop ett Proto-Screwshield R3 för utvecklingsfasen när jag testar fram funktionen. Är smidigt och enkelt att arbeta med, att slippa löda in anslutningstrådar från givare, strömförsörjning, etc. till WeMOS ESP32 D1 R32 Uno.
"The next generation Proto-ScrewShield is a dual-purpose prototyping shield. Not only does it have a large 0.1" grid prototyping area but it also extends the Arduino pins to sturdy, secure, and dependable screw terminal blocks. You even get a few bonus terminals for extra GND and four ´free´ terminals for whatever connections you wish! New! As of June 23, 2014 we now have an R3 update to this design - we now have a stacking header for the ICSP 2x3 pins and breakout the SCL and SDA pins. It now works much better with R3 UNO´s, Mega, Leonardo, as well as stacking nicely with any shield.
The stack-able wing design allows you slip this under any shield and still get easy access to the "analog" & "digital" ports of the Arduino. The ScrewShield can be stacked above or below pretty much every other shield."

Solid-state relay AC/DC: 2022-12-04

För att styra strömmatningen till Teltonika RUT241 4G Router behöver jag solid-state-relay / load-switch / power-switch funktion som kan styra strömmen ON/OFF på high-side med 3.3V signal från ESP32. Hittade denna hos Electrokit, men finns nog billigare: LCA717 DIP-6 Solid-state relay AC/DC.
What is a Load Switch?
Load switches (TI)
Load switches Low quiescent current, 0-3A (TI)

Batteriverkningsgrad: 2022-12-11

Lite idéer / tankar dök upp kring hur den ska mätas / utvärderas... Kanske som funktion av hur djup en battericykling varit (max DOD) samt kanske hur lång tid den varat innan 100% SOC fulladdat igen? Kan den även vara beroende av batteritemperatur? Får mäta och se när jag har batterimonitorn i skarp drift med den första inledande funktionen för batteri­verkningsgrad och coulomb­verkningsgrad.
Är nog en sådan funktion som kunde använda ML (machine learning) i framtiden?
ML | What is Machine Learning?, GeeksForGeeks
Se även TinyML ESP32 Arduino, TensorFlow.

Grundkoden med menyer & NTP tid klar: 2022-12-13

Blev idag klar med grundkoden för alla menyer, WiFi samt för synkning av RTC (Real Time Clock) med NTP tidsserver på Internet. Sparade en kopia av den som bas för framtida ESP32-projekt. Detta är en mycket stor del av den totala kodningen men bara så viktig med det smidiga användargränssnitt den ger via 16x2 LCD displayen. Samt välutvecklat i FreeRTOS så det med väldigt lite kodning lätt läggs till nya menyer, både som editerar dataparameterar samt som visar driftsdata eller Datum / Tid från RTC, etc.
Har även varit ett lärosteg för mig att börja använda FreeRTOS för effektiv realtidsfunktion! Så hela funktionen är uppbyggd kring ett antal FreeRTOS-tasks, och Arduino loop() raderad.

ID för varje ESP32, macAdress: 2022-12-14

När driftsdata ska skickas till en webbserver på Internet kan ESP32´s MAC-adress användas som ID för respektive ESP32, då det ska vara unikt för varje individ. Så kan data skickas från flera olika ESP32-batterimonitorer utan risk att blandas ihop!
WiFi.macAddress() - Espressif MAC-adress, Convert MAC Address to String

ESP32 Async web server SSE: 2022-12-18

Nu kodat färdig för en Async Webbserver med webbsida i ESP32 som skickar datauppdateringar direkt till webbsidan via Server-Sent Events (SSE). SSE är effektivt, strömsnålt och elegant!
Har använt infon och en del kod från: ESP32 Web Server using Server-Sent Events.
Samt från ESP32 WiFiMulti: Connect to the Strongest Wi-Fi Network (from a list of networks)
Med biblioteket: ESPAsyncWebServer-esphome installerat inifrån PlatformIO, ett "Asynchronous HTTP and WebSocket Server Library for ESP8266 and ESP32".
ESPAsyncWebServer-esphome Readme user manual!!!
Var förvånadsvärt enkelt och smärtfritt samt gick mycket snabbare än jag hade förväntat mig! Fungerade direkt.
Är lite snabbt kodat så är inte slutligt utförande / design, samt skickar just nu bara fuskade slumtalsvärden för att se funktionen.
Fungerar jättebra mot wifi-routern här hemma samt mot Teltonika RUT241! ESP32 skickar webbsidan via wifi till routern som i sin tur skickar den vidare via sin wifi ut till mobil / dator.
Så på plats i ett off-grid boende / husvagn kan man kolla sin solcells-batteri driftsstatus inom hela området som routerns wifi når, vilket bör bli ett större områden än för en app via Bluetooth.
ESP32 skickar först hela webbsidan till webbläsaren och sedan bara den data som uppdateras där direkt till webbsidan via Server Sent Events (SSE), vilket är jätteeffektivt och strömsnålt även när flera olika enheter är uppkopplade mot webbsidan samtidigt.
Jag har valt att skicka nya data 1ggr/s så upplevs visningen stabil.
I mobilen kan man välja fullskärmsläge som då ser ut precis som en app, så blir lika snyggt med webbsidan på så sätt utan något beroende av någon extern tjänst eller kontakt med mobilnätet.
Jag väljer att använda en webbsida istället för app, dels för att jag redan har bra kunskap i att koda webbsidor, dels att driftsdatan då kan visas på en mängd olika enheter med webbläsare.
Så vill man ha en stor display kan man bara köpa en billig enkel surfplatta och montera hos sig, samt går ju även att visa på en smart-TV om man har en sådan.
Ska senare koda den som en progressive web app! (Web app manifests | Installing web apps)
Och smidigt att visa driftsdata så direkt från ESP32 mikrokontrollern!
Ska visas mer info där efterhand som projektet framskrider, som en dashboard.
Men nästa steg är att skriva koden för ström-energi-sensorn INA226 och koppla in den mot mitt lilla experimentella off-grid solcellssystem här hemma är tanken. Ska bli intressant!
ESP32 Useful WiFi Library Functions, Arduino
Espressif: ESP32 WiFi API Reference, Networking APIs
HTML vs Body: How to Set Width and Height for Full Page Size
HTML vs Body in CSS (2018)

ESP32 Async web server kraschar: 2022-12-21

Har nu kört med ESP32 Async web server SSE några dagar och det visar sig att ESP32-koden kraschar oregelbundet rätt glest (typ 5-10min) när en eller flera webbläsare är uppkopplad aktivt mot ESP32-webbservern och får Server Side Events skickade till sig. Bara då!
ESP32 bootar då om i en oändlig loop utan att lyckas starta om, förutom typ efter 80st gånger som vid debug-utskriften nedan (ResetBootCountRTC in RTC memory: 80).
Trodde först de orsakades av lite svag strömmatning via USB då LCD-displayens LED-bakgrundsbelysning blinkar lite när WiFi kortvarigt drar lite högre ström.
Men dels får jag Reset reason: 4, ESP_RST_PANIC, vilket inte är orsakat av spänningsmatning, dels blev det ingen skillnad när jag monterade in en kondensator för stabilisering av 5V på ESP32!
Och sedan hittad jag hur det gick att få ut mer debug-info i serial-monitor.
Så får där nu följande när det händer:
-------
Reset reason: 4, ESP_RST_PANIC
ResetBootCountRTC in RTC memory: 80
Total booting / resets: 2855

assert failed: tcpip_api_call IDF/components/lwip/lwip/src/api/tcpip.c:497 (Invalid mbox)
(Ser ut som ett av Espressiv-IDF biblioteken är orsak - kan det då fixas med någon inställning för webbservern, eller annat kodmässigt?)

Backtrace:0x40083b71:0x3ffb4c700x4008dadd:0x3ffb4c90 0x40093119:0x3ffb4cb0 0x400fadf1:0x3ffb4de0 0x401493f1:0x3ffb4e10 0x40149c15:0x3ffb4e50 0x400e095e:0x3ffb4e90 0x400d476b:0x3ffb4eb0 0x400d4854:0x3ffb4f20

ELF file SHA256: 0000000000000000

Rebooting...
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
-------
Så får dels läsa på mer i ESPAsyncWebServer-esphome Readme user manual, dels se om jag kan få felutskrift för heap corruption diagnostics, om det kan vara en orsak.
Espressif: Heap Memory Debugging
Samt i övrigt gå igenom min kod mer grundligt, ihop med att leta lite mer info på Internet.
Har sett indikation på lösning med att skicka SSE lite mer sällan än nuvarande 1ggr/s?
Vad jag förstått körs allt ESP32-internt kring WiFi / Bluetooth stöd i Core0, så att jag lagt mina funktioner för ESP32-webbserver också i Core0 kanske leder till någon krock av något slag, så får även testa att byta till Core1!

Efter att slagit på mer debug-info kom följande fram:
> assert [RX:' '] [RX:'failed: tcpip_api_call IDF/comp'] failed: tcpip_api_call IDF/comp [RX:'o'] o [RX:'nents/lwip/lwip/src/api/tcpip.c'] nents/lwip/lwip/src/api/tcpip.c [RX:':'] : [RX:'497 (Invalid mbox)\r\n
> \r\n
> \r\n
> Backtra'] 497 (Invalid mbox)
Så problemet ligger tydligen i tcpip...
Edit: Det mesta pekar på att det var ett spänningsfall av strömspik när SSE-data skickas via WiFi / Webbserver, då en 470µF kondensator kopplad till 3,3V på ESP32-kortet för att buffra för dessa fick kodkrasher med det felmeddelandet att försvinna!
Därmed är per se inte min kod det direkta problemet, men får testa ändå med att koda om lite för bättre mer renodlad kod samt lägga i Core1 och se om det kan påverka. Har ändrat så SSE bara exekveras 1ggr/3s (från 1ggr/s) och det verkar lite stabilare!
Samt även läsa på mer i ESPAsyncWebServer-esphome Readme user manual för att se om det är saker i min kod som kan förbättras för ESP32-webbservern. Kanske typ finns någon buffert man kan dimensionera upp?
2022-12-22
Testat en del olika samt läst på nu och blivit något klokare.
Provade att lägga in en vTaskDelay() på 2ms mellan varje av de 11st events.send(), men det gjorde ingen skillnad.
Provade att ändra frekvensen för SSE från 1ggr/s till 1ggr/3s och det blev märkbart stabilare men kraschade ändå någon gång per timme.
Provade att bara låta sända 4st events.send() data mot 11st hittills och då fick jag ingen krasch under flera timmar.
Provade då att öka till 6st events.send() data och då fick jag en krasch under drygt två timmar, när jag hade webbsidan aktiv i två olika webbläsare samtidigt som SSE-data skickades till.
Har något luddigt minnesfragment av att jag läst att vid behov av många datavärden bör man välja att skicka dessa i en JSON fil istället, så ska nog prova det som alternativ.
Även mätt tiden det tog att skicka de 11st events.send() data och blev 12-20ms, så tänkte att med id = millis() fanns risken att två kunde få samma id och det kanske krashade då. Så även provat med id=micros() för att utesluta det, men blev ingen skillnad.
Men jag kan med 6st events.send() data gå vidare nu och koda för energi/ström-sensorn INA226 och installera den mot blybatteriet för lite riktiga mätvärden. Är så nyfiken på att få den sensor i drift och känna pulsen på den!
Och därefter koda om för data via JSON-fil.
Funderar även på ESP32 Webbserver byggt på WebSocket för att kunna få en tvåvägskommunikation så jag kan justera inställningsvärden från webbsidan och aktivera funktioner i ESP32, via Remote Control.
2022-12-22
Kört i flera timmar med bara 6st events.send() data skickade samt ett webbläsarfönster anslutet till ESP32 utan någon krasch!
2022-12-23
Provade att flytta de 11st events.send() data från den Deferred-Interrupt-Task med höga FreeRTOS Priority=7 där jag lagt dem tillfälligt till en nykodad Task_WebServerESP32 med låga FreeRTOS Priority=2 i Core0 som tänkt, och då med den lägre prioriteten fungerade det mycket stabilare.
Så sannolikt krockar en så hög FreeRTOS prioritet för webb-/WiFi-kommunikation med Espressif-IDF bibliotekskods prioritet i core0! Men måste ändå vara en bug/svaghet där, då den kraschar så hårt att ESP32 fastnar i en ändlös reboot och kräver manuell fysisk reset.

Kunde köra två webbläsarfönster anslutna till ESP32-webbservern som uppdaterades med 11st events.send() data under ett par timmar utan krasch. Och med två datorer + en mobil med total 4st webbläsarfönster mot ESP32-webbservern klarade den drygt 15min innan krasch, vilket inte gick alls tidigare. Syns även på RAM-minnes hanteringen som ser mer stabil ut nu!
Så är på rätt spår. Har även checkat att det inte är något minnesläckage!
Sedan flyttade jag allt eget med wifi / webbserver till core1 så blev det ytterligare stabilare samt några andra småmodifieringar.
Så tydligt krockade den hög task-prioriteten med de task Espressif lagt för wifi i core0 så webbservern blockerade det. Har även prova att lägga in en 100ms vTaskDelay() efter hälften av events.send() som delegerar processorkraften i FreeRTOS till andra uppgifter de 100ms.
Har även tittat över alla ESP32 FreeRTOS Task stack size för mina kodade Tasks och optimerat dem.
Nu även kopplat den SSE-skickade datan till den canvas-grafik dashboard jag har på ESP32-webbsidan så mätvärden och mätare uppdateras där, vilket känns riktigt häftigt och coolt! Visar en sneak-peek av dashboard-grafiken och kommer visa hela när jag har den i full drift.
De två olika felmeddelande jag får vid krasch nu är:
assert failed: tcpip_api_call IDF/components/lwip/lwip/src/api/tcpip.c:497 (Invalid mbox)
Guru Meditation Error: Core 0 panic´ed (LoadProhibited). Exception was unhandled.
Där "LoadProhibited" = The error LoadProhibited means that the CPU tried to load a variable form an illegal address.
2022-12-28
Ändrade alla globala variabler till static typedef så de bara blir globala inom min fil, vilket är det normala inom C/C++ för att slippa namnkrock med variabler i inlänkade bibliotek. Verkar som det löste mina misstankar om en klassisk C/C++ bug typ pekarefel eller dylikt som jag hade isolerat till att finnas i en av mina Task. Har i vart fall inte fått något mer sådant felmeddelande.
Men får ändå enstaka glesa kraschar så inte helt stabilt ännu, även om jag oftast kan exekvera fler timmar i sträck.
Ska kolla upp att jag verkligen använder Mutex för exklusiv åtkomst till data / resurser på alla ställen i koden det behövs för att undvika krockar mellan min olika asynkront exekverande FreeRTOS-Tasks! Och om jag inte hittar något där så ta bort alla String-class variabler jag använt (Php-kodvana) och ersätta med klassisk C/C++ char[]-array istället, vilket är mycket effektivare samt antytts någon stans att String kan vålla dessa krascher ihop med webbserver-biblioteket ESPAsyncWebServer-esphome jag använder. Så hoppas få det helt stabilt så!
Lite intressant läsning kring C++ kodning:
Static local variables, Learn C++
Sharing global constants across multiple files (using inline variables)
Why (non-const) global variables are evil
2022-12-29
Fick "Guru Meditation Error: Core 1 panic´ed (LoadProhibited). Exception was unhandled." igen när jag aktiverade en av tryckknapparna, och misstänker det har något att göra med missad Mutex kring min DisplayHandler(), Task_DisplayViewHandler() samt Task_LCDButtonsHandler(), eller Mutex kring Serial.print() då det händer när jag aktiverar menyn för att Serial.printa info om FreeRTOS Task stack size!
Nya versioner av espressif/arduino-esp32 (ESP32 Arduino 2.0.6 based on ESP-IDF 4.4.3) och av platformio/platform-espressif32, 5.3.0 med bl.a. "Fixed issue where esp32 won´t reconnect to WiFi AP if the AP was restarted." som jag tackar för just nu när jag håller på med WiFi och async webbserver!
Har även upptäckt att med PlatformIO längre tid passiv i bakgrunden med öppen Serie-Monitor ansluten till ESP32 så kraschar ESP32-webbservern ibland, men stänger jag Serie-Monitor så undviks det! Verkar som Serie-Monitor blir inaktiv då.

2022-12-31
Har nu fin långtidsstabilitet med ESP32-webbservern med en uppkopplad webbläsare / webbsida samt med att jag sänkt uppdateringsfrekvensen till 1ggr/2s. Den sänkta uppdateringsfrekvensen beror troligen på att mitt Olimex LCD-shield arbetar så enormt långsamt då det saknar en buffert för inkommande texter så min kod får vänta på den riktigt långsamma skrivning av varje tecken till själva displayen med drygt 640ms för att skriva alla de 2x16 tecknen (20ms/tecken) vid I2C busshastighet 80kHz som är max den klarar.
Vid data till flera webbläsarfönster får jag fortfarande krascher med felmeddelandet: "assert failed: tcpip_api_call IDF/components/lwip/lwip/src/api/tcpip.c:497 (Invalid mbox)". Nämns dock något om ESP32 reset WiFi stack samt How can I increase wifi task stack size?, ESP32: Increase wifi task stack size to support advanced logging, 4WAY_HANDSHAKE_TIMEOUT.
Espressif: Optimization of Internal RAM, Fatal Errors, Guru Meditation Errors
Verkar vara någon buffert / stack size som inte räcker till, men inte lyckats hitta någon bra info om det trots mycket sökande på Internet!

---

2023-01-18
Har nu hittat både CONFIG_ASYNC_TCP_STACK stack-size och CONFIG_ASYNC_TCP_QUEUE_SIZE event-queue-size för AsyncTCP.cpp i AsyncTCP-esphome-biblioteket:
me-no-dev / AsyncTCP
Sending big blocks of data triggers async_tcp task watchdog, i AsyncTCP.cpp:
event-queue-size:
static inline bool _init_async_event_queue(){
  if(!_async_queue){
    _async_queue = xQueueCreate(512, sizeof(lwip_event_packet_t *)); // 32 default
    if(!_async_queue){
    return false;
    }
  }
  return true;
}
Att öka event-queue-size från default 32 till 512 gjorde att jag kunde öka gränsen för antal events.avgPacketsWaiting() jag tillåter samt köra det helt stabilt även när jag hetsar med 5ggr snabbare sändningsfrekvens via SSE till webbsidorna, även när jag uppdaterar mot två samtidiga webbsidor! Kan med interrupt via tryckknapp uppdatera ca 5ggr/s och fungerar ändå stabil!
Kanske inte skulle behöva kö-övervakningen alls nu, men när jag nu kodat den funktionen känns den bra att ha där. Nu med ökad gräns behöver den i stort aldrig ingripa.
Beskrivs även här: AsyncWebServer giving wdt reset.
Där tipsas även om EspExceptionDecoder för felsökning.
Är ju synd bara att de inte kodat en funktion i AsyncTCP.cpp så man kan justera både dess stack-size och event-queue-size inifrån sin egen kod!
Och i AsyncTCP.h #define CONFIG_ASYNC_TCP_STACK_SIZE 8192 * 2, som jag även ska prova att öka.
Ökade till 16384 * 2 men det tar mycket RAM-minne, så går tillbaka igen till default. Märkte ingen skillnad vid en snabb test.
Lite mer att läsa:
Using server.serveStatic causes WDT crashes
ESPAsyncWebServer Fork
The combination I currently using Wenserver

---

Känns inuitivt som att det skulle fixa sig genom att gå över till WebSocket istället för nuvarande SSE med den datamängd jag skickar!
Eller annars använda antingen JSON-data eller Protocol Buffers (Protobuf) (is a free and open-source cross-platform data format used to serialize structured data) för datan.
Går vidare med att koda för och koppla in INA226 energi-/ström-sensorn nu, så får test med WebSocket komma senare. Blir en intressant start på nya året!
2023-01-01
Har haft problem med ESPAsyncWebServer template processing engine då den ersätter template-namn mellan två %-tecken, typ %VOLTAGE% med datan från en C/C++-variable i ESP32-koden. Blir problem dels när man använder % som längdmått i CCS typ width=100%;, samt dels även som enhet i sin html-text! Har ägnat flera dagar åt att hitta en möjlig fix till detta och löste det idag äntligen :-)
Provade att införa #define TEMPLATE_PLACEHOLDER '$' i min kod, men fungerade inte då det inte rår på ESPAsyncWebServer biblioteket.
Hittade tips om att build_flags = -TEMPLATE_PLACEHOLDER='$' i platformio.ini filen skulle fixa det, men inte!
Infogade #define TEMPLATE_PLACEHOLDER '$' i min kod så fick jag upp ett felmeddelande om att symbolen i WebResponseImpl.h var redefinierad och kunde då klicka upp den filen där den ursprungliga #define fanns, så editerade jag den där till #define TEMPLATE_PLACEHOLDER '$'! Och det fungerade!
Där finns även #define TEMPLATE_PARAM_NAME_LENGTH 32, så default kan max 32 tecken användas.
Och även där är en allvarlig bug i denna kodfunktionen, för den tar inledande %-tecken och de följande 32 tecknen och ersätter fast inte hittat avslutande %-tecken. Egentligen är det nog huvudproblemet, och ett grovt kodningsfel tycker jag!
Genom att behålla #define TEMPLATE_PLACEHOLDER '$' i min kod så kommer jag bli uppmärksam på ny uppdatering av ESPAsyncWebServer / WebResponseImpl.h vid kompilering och får då editera där igen. Men oförändrad blir det inga felmeddelande så.
Känns rätt klantigt att använda "%"-tecken för denna funktion, liksom att inte infört ett lätt sätt att själv i sin kod kunna välja lämpligt tecken! Jag provad även att i den egna processor() funktion man gör för utbytet att returnera den var-String man får där ihop med %-tecken, så skulle ju det vid width=100%; ersättas med ursprunglig kod och ingen skada skedd, men då reprocessar den hela den koden från början för varje template-name-processing så hamnade då i en oändlig loop! Också rätt märklig kodfunktion som slösar processorkraft! Borde ju fungerat!
Han som kodat detta bad redan 2018 om ursäkt för den funktionen, men ändå är det nu drygt 4 år senare inte åtgärdat! Ger ett lite dåligt intryck av biblioteket som trots det är det mest använda och mest aktuellt uppdaterade Async Web Server SSE bibliotekt vad jag ser.
Ska senare kolla in WebSockets och då även kanske testa PlatformIO biblioteket WebSocket Server and Client for Arduino ESP32.

• WebResponseImpl.h - #define TEMPLATE_PLACEHOLDER '%'
• PlatformIO: Setting variables in code using build_flags
• Allow to override default template placeholder value with #define during compilation
• Template confused by data containing percent ('%')
• Send large webpage from PROGMEM containing templates with '%' sign in it (CSS part of page)
• Using template processor corrupts response HTML if it includes %
• CSS styles are removed when served by ESP8266 running an ESPAsyncWebServer
• DuckDuckGo: ESPAsyncWebServer "TEMPLATE_PLACEHOLDER"
• ESP32 Arduino HTTP server: Template processing
• ESP32 web server: template processing when serving HTML from file system
• ESPAsyncWebServer README.md

2023-01-03
Har nu visat driftsdata (slumptals-fejkade än så länge) från min ESP32 batterimonitor (och blivande PWM-regulator) aktivt uppdaterat via WiFi mot mobilen två timmar i ett streck med stabil funktion från webbservern i ESP32 mikrokontrollern!
Så känns tillräckligt stabilt nu för att gå vidare med att koppla in energi-/ström-sensorn INA226 och fixa programkoden för den samt ansluta till min lilla experiments-solcellsanläggning här hemma.
Server Side Events (SSE) är en elegant smidig teknik, men med detta kodbiblioteket känns den inte riktigt stabil för en "större" datamängd som här, så ska senare testa med WebSockets istället. Men går nu först vidare med att koppla in INA226!
Är så jäkla nyfiken på att testa den smarta INA226: 36V, 16-bit, ultra-precise I2C output current / voltage / power monitor w/alert!

2023-01-05
Nu verkar jag fått min ESP32-webbserver att arbeta helt stabilt utan kodkrascher, både med 1ggr/s uppdateringfrekvens av SSE-data till webbsidan och av LCD-displayen, genom fem ytterligare åtgärder. Har även provat med 2st webbsidor på datorn och 1st i mobilen nu.

1. Införde en Mutex för DisplayHandler-funktionen så bara en instans av den kan vara aktiv åt gången via anrop från olika FreeRTOS Tasks. Fast den i sig utnyttjar Mutex för I2C-seriebussen så belastar det RAM-minnet med flera aktiva instanser av DisplayHandler inlästa där helt i onödan, samt tar även processorkraft. Syntes tydligt på heap-minnet!
2. Införde adaptiva funktioner i koden som minskar uppdateringsfrekvensen av SSE-skickade data till webbsidan samt av uppdateringen av LCD-displayen så fort det blir för mycket kö i de Queue-dataflödena. Gjorde stor märkbar skillnad, samt innebär att jag nu normalt kan uppdatera båda 1ggr/s, som väldigt glest tillfälligt görs långsammare individuellt för de olika enheterna. För SSE-skickade data var detta extra kritiskt när en nedstängd webbserver väcks upp igen!
3. Ändrade WiFi.useStaticBuffers(true); till true (set the buffers memory allocation to dynamic = false), då dynamisk minnesbuffert verkade fragmentera heap-minnet och efter lång driftstid kraschade exekveringen med felmeddelande att heap-allocation inte gick.
4. Bytte ut den 10µF kondensator jag kopplat till 3,3V på ESP32-kortet till en 470µF kondensator för att buffra för de korta lite högre strömspikar WiFi-kommunikationen drar, vilket gjorde stor skillnad. Nu försvann helt det väldigt glesa kodkrascherna när jag hade ett webbläsarfönster öppet mot ESP32-webbservern, och de mer frekventa krascherna vid 2-3 uppkopplad webbläsarfönster försvann också, så var helt klart spänningsdippar som störde mikroprocessorn! Det luriga är att jag fick inga Brownout-resets utan ESP_RST_PANIC (Panic Handler), så Brownout´s detekterar tydligen inte så korta spänningsdrop!
5. I min Task där jag skickar alla SSE-data events.send() till webbsidan införde jag ckeck för events.avgPacketsWaiting() så inte de köar upp för mycket väntande Packets i webbservern utan väntar då med att skicka nya, vilket även skonade RAM/Heap-utnyttjandet signifikant. Med events.count() får man även antal webbsidor som servas för stunden!
   Var ett litet dektivjobb att hitta, då det inte tas med i de enkla exemplen för webbserver-kod till ESP32 jag hittat på Internet!
   Har testat vid svag WiFi-signal och arbetar helt stabilt nu även när det kan ta 10-15s mellan att SSE-data via events.send() når webbläsaren! Tidigare kraschade kod-exekveringen då!
   Köandet ökar inte vid 3st anslutna webbläsarfönster mot 1st, så är inte skickad datamängd som ger kö utan tydligen antal anrop till events.send(). Har läst att vid större mängd data blir det bättre att packa in dem i en JSON-fil och skicka med ett anrop till events.send(), så ska prova det senare. Även sett info om att WebSockets skulle vara bättre / effektivare vid denna typ av dataskickande till webbsida, bl.a. för att den kan även skicka binär data (typ float/int tal) mot SSE som bara tar textsträngar, så även det ska jag prova senare.
   Men då jag fått det stabilt nu installerar jag först effekt/ström-sensor INA226 så jag får igång riktig mätning mot batteriet i mitt lilla experiment off-grid solcellssystem här hemma!

2023-01-07
Har lagt in en WiFi.onEvent() som aktiverar server.begin() så att webbservern helt säkert återstartas direkt när WiFi har återanslutit och fått IP efter varit nedkopplad. Tidigare kunde webbserverns återstartande vara lite segt, som ibland t.o.m. kraschade kodexekveringen.
Gör att även efter automatisk WiFi-Reconnect med WiFi.setAutoReconnect(true) så återstartas webbservern direkt!
WiFi.onEvent() är riktigt snabb så WiFi.onEvent(ARDUINO_EVENT_WIFI_STA_GOT_IP); aktiveras innan wifiMulti.run() exekverat färdigt med sin anslutning till WiFi! Märks även när jag nu testat med att min ESP32-kod fått stänga ned WiFi och sedan återstarta en mängd gånger, att webbservern återansluter väldigt snabbt och SSE-data kan uppdateras direkt i webbläsaren efter WiFi-Reconnect! Samt har varit 100% stabilt!
Så ytterligare en pusselbit i att få en riktigt långtidsstabil ESP32 webbserver kod-funktion.
Info och kodtips från: Reconnect to Wi-Fi Network After Lost Connection (Wi-Fi Events)
ESP32 C/C++ kod:
WiFi.onEvent(WiFiGotIP, WiFiEvent_t::ARDUINO_EVENT_WIFI_STA_GOT_IP);
void WiFiGotIP(WiFiEvent_t event, WiFiEventInfo_t info){
  server.begin();
}
Funktionens parametrar: ESP32 Arduino: Getting WiFi Event information.
2023-01-11
Mätt upp via oscilloskop hur snabbt jag kan växla en GPIO-utgång 1-0-1 på mitt ESP32-kort. Är förberedelse inför att kunna utvärdera en Deferred interrupt processing jag snart ska implementera för INA226. Tog 100ns (10MHz), vilket jag är nöjd med!
Så kan göra sådana utvärderingar då med 100ns upplösning!
När jag sedan mäter med interrupt så måste jag göra det via oscilloskop såhär, då signalen kommer utifrån från INA226.
Gör detta med direkt portmanipulation:
GPIO.out_w1tc = ((uint32_t)1 << 18); // Set PIO 18 to 0
GPIO.out_w1ts = ((uint32_t)1 << 18); // Set PIO 18 to 1
GPIO.out_w1tc = ((uint32_t)1 << 18); // Set PIO 18 to 0

Mätte även upp hur exakt den FreeRTOS-Task jag exekverar 1ggr/1000ms blir i sin frekvens samt den tid själva Task-exekveringen tar varje gång. Styrs då av vTaskDelayUntil( &xLastWakeTime, 1000 / portTICK_PERIOD_MS ) samt exekveringen innefattar bl.a. 2st xQueueSend() som initierar exekvering av två andra Task.
Den önskade 1ggr/1000ms exekveringsfrekvensen mäts till 1ggr/1000,01ms stabilt med Std-Dev 4,78µs över 50 mätningar, så det är ju imponerande bra!
Oscilloskopet mäter upp en exekveringsfrekvens på 999,99mHz!

Samt själva exekveringen tar 0,6 - 0,7ms, så xQueueSend()-data till andra Task är också snabbt, då jag gör lite andra småsaker också under Task-exekveringen. Detta går ju att mäta inne i koden också med microsekund-upplösning. Men man ser tydligare hur tiden varierar på oscilloskopet.
Så en duty-cycle för exekveringen på 0,06% - 0,07% i denna Task!
Inte så hård belastning på processorn precis :-)
Gör detta för att få insikt i hur exekveringen och koden arbetar, för eventuellt senare optimering om det behövs! Ökar även min kunskap om hur det jag gör verkligen fungerar.

2023-01-16
Kodat Interrupt och WakeUp från light sleep på samma GPIO:
För INA226 effekt/ström-sensorn så dess Alert-interrupt signal både kan indikera nya mätvärden att läsa av samt samtidigt väcka upp ESP32 via GPIO från light sleep när i energisparläge. Görs med attachInterrupt(19, ISR, ONLOW_WE);, där WE=WakeUp Enabled. Var svårt att hitta info om, men nu fungerar det emulerat via en tryckknapp på bread-board. Så nästa steg är att koppla ihop med INA226!
2023-01-18
Har nu hittat både CONFIG_ASYNC_TCP_STACK stack-size och CONFIG_ASYNC_TCP_QUEUE_SIZE event-queue-size för AsyncTCP.cpp i AsyncTCP-esphome-biblioteket:
me-no-dev / AsyncTCP
Sending big blocks of data triggers async_tcp task watchdog, i AsyncTCP.cpp:
event-queue-size:
static inline bool _init_async_event_queue(){
  if(!_async_queue){
    _async_queue = xQueueCreate(512, sizeof(lwip_event_packet_t *)); // 32 default
    if(!_async_queue){
    return false;
    }
  }
  return true;
}
Att öka event-queue-size från default 32 till 512 gjorde att jag kunde öka gränsen för antal events.avgPacketsWaiting() jag tillåter samt köra det helt stabilt även när jag hetsar med 5ggr snabbare sändningsfrekvens via SSE till webbsidorna, även när jag uppdaterar mot två samtidiga webbsidor! Kan med interrupt via tryckknapp uppdatera ca 5ggr/s och fungerar ändå stabil!
Kanske inte skulle behöva kö-övervakningen alls nu, men när jag nu kodat den funktionen känns den bra att ha där. Nu med ökad gräns behöver den i stort aldrig ingripa.
Beskrivs även här: AsyncWebServer giving wdt reset.
Där tipsas även om EspExceptionDecoder för felsökning.
Är ju synd bara att de inte kodat en funktion i AsyncTCP.cpp så man kan justera både dess stack-size och event-queue-size inifrån sin egen kod!
Och i AsyncTCP.h #define CONFIG_ASYNC_TCP_STACK_SIZE 8192 * 2, som jag även ska prova att öka.
Ökade till 16384 * 2 men det tar mycket RAM-minne, så går tillbaka igen till default. Märkte ingen skillnad vid en snabb test.
Lite mer att läsa:
Using server.serveStatic causes WDT crashes
ESPAsyncWebServer Fork
The combination I currently using Wenserver
2023-01-20

Har nu kodat ett menysystem färdigt till 5st webbsidor i ESP32, så nu är där en hel webbplats. Huvud­webbsidan är nu 41,23 kB i överförd storlek som tar ca 150-300ms att ladda ned för webbläsaren. Jag tycker det är imponerande hanterat av ESP32 prestandamässigt!
Är gjort som en modern s.k. "responsive hamburger menu" med en inline <svg></svg> hamburger-icon kod från CSS-Tricks.
Har delat upp webbkoden i separata CSS, JavaScript & Html char-variabler kodblock som är gemensamma för alla webbsidorna, som kopieras in via processor-funktionen i ESPAsyncWebServer-esphome. Sparar på så sätt flash-minne samt slipper redundant kod så blir enklare att uppdatera koden för webbsidorna.
Är fortfarande gott om plats i ESP32 där kompilatorn rapporterar:
RAM: [= ] 14.4% (used 47196 bytes from 327680 bytes)
Flash: [=== ] 28.9% (used 908177 bytes from 3145728 bytes)
Samt i aktiv drift mäter jag i ESP32:
FreeSketchSpace(%): 75
FreeHeap(%): 57 (52% när SSE skickas till webbsida)
SdkVersion: v4.4.3
ChipModel: ESP32-D0WDQ6
ChipRevision: 1
Har även lagt in <svg></svg> för en icon för aktivering av full-screen mode uppe till höger.
Koden hämtad från Arrows fullscreen Icon Svg Code. Finns även Arrows Maximize Icon SVG.
Här är alla FontAwesomeIcons SVG Icons | SVG Code Generator.

Har även lagt till en SVG-FavIcon: Use inline SVG as favicon där <svg></svg>-koden URL-encodes via URL-encoder for SVG.
Nu som första start använder jag Speedometer2 SVG Icon Code men tänker senare skapa en egen SVG-FavIcon.
Html-kodas såhär i <head>-sektionen:
<link rel="icon" href="data:image/svg+xml,[YOUR URL-ENCODED SVG HERE]" type="image/svg+xml" />


2023-01-21
Har kopplat in INA226 till ESP32 med INA226_WE biblioteket och dess Conversion-Ready-Alarm Interrupt signal triggar min ISR och dess deferred interrupt processing Task med en väldigt hög repetitiv precision på 1129695±2µs! Mätt via 64-bit esp_timer_get_time()!
En otrolig tidsnoggrannhet upplever jag, men kommer ändå summera Ah med den mätta tiden!
Har då satt INA226 till 1.1ms conversion time och 512 samples för medelvärdesbildning och det är spänning + ström som läses av så 1,1ms * 512 * 2 = 1126ms mellan att INA226 ska ha färdiga nya mätvärden att läsa av, plus ca 4ms overhead på det tydligen.
INA226 mäter därmed ström och spänning 512ggr/1,129695s dvs 453ggr/s, 1ggr/2,2ms!
Ihop med 19ms RC-filter fångas även de allra snabbaste och korta pulser upp i mätningarna!
Så INA226 styr på så sätt nu "pulsen" för min kods exekvering.

Har ingen ström ansluten till INA226 ännu så den mäter nu 3,286V, 0,000A & 0,000W, då spänningsmätningen är kopplad till 3,3V matningsspänningen. Mätdatan 3,286V ligger exakt stabilt på den spänningen och strömmen är 0,000A hela tiden, riktigt imponerande!
Mätt med min digitala multimeter får jag 3,285V.
Ser ut att bli riktigt bra förutsättningar för en hög noggrannhet i batterimonitorn med detta!
Så stämmer med hur jag noga valt komponenter.

Att medelvärdesbilda så här över 1,1s ger väldigt stabila värden att visa och att reglera på!
Blir spännande att se hur stabila mätvärden jag får inkopplat mot blybatteriet senare.
Är möjligt sedan när jag ska reglera laddningen att jag behöver läsa av strömmen lite oftare, men får prova då. Med 588µs conversion time och 256 samples får jag 0,588ms * 256 * 2 = 301ms intervall, som nog kan vara bra att sikta mot om jag behöver snabbare respons för strömmen.
Men samtidigt är den medelvärdesbildade strömmätningen så extremt stabil brusfri att man kan göra en snabbare och mer exakt reglering på den, så tror ändå det räcker med 1ggr/1,1s avläsning. Vid en linjärt förändrad ström över tid så skulle man kunna ta 2ggr förändringen sedan senaste medelvärdesbildade mätvärde, då det skulle motsvara nuvarande momentant värde, så kan experimentera med att ta 1,5-2ggr strömförändringen så i PWM-regleringen. Sedan är en ren PWM-reglering smidig då en ändring i duty-cycle / pulskvot direkt motsvarar en strömändring, så går att matematiskt räkna fram väldigt nog hur mycket pulskvoten behöver ändras för att justera en viss avvikelse i strömregleringen! Och strömreglering i sig mot blybatterier har mycket snabbare respons än spänningsreglering, så det blir en bra bas för regleringen.
Kan se att min nuvarande rent spänningsreglerande PWM-regulator agerar rätt långsamt pga det för stabil reglering mot blybatterierna, då de är rätt spänningströga!
Ska även ha en ström+ reglering för extra snabb noggrann laddreglering, min specialare.

Fri SRAM ligger fortfarande kvar på 52% under aktiv exekvering med SSE-data till webbsida, så en försumbar inverkan på ESP32 prestandan liksom en minimal försumbar tid att hämta mätvärden över I2C. Totala aktiva exekveringstiden för mina FreeRTOS Task´s är kvar på ca 1%.

Och jag lyckas få ihop detta med använt I2C Olimex Shield-LCD 16x2 som har svårt att samsas med annan enhet på samma I2C. Har gjort lite smart kodande där som adaptivt håller koll på detta och skyddar och optimerar Olimex Shield-LCD´s I2C-kommunikation.
Och det går inte ut över INA226´s I2C-kommunikation, så känner mig väldigt nöjd så!
2023-01-22
Testad att sätta ESP32 i light-sleep strömsparläge mellan varje INA226-avläsning, som väcks upp av interrupt från INA226 för ny avläsning av mätdata och sedan light-sleep igen. Nu med 1,1s cykeltid får jag då 10% aktiv drift (för uppdatering av LCD med nya datan) och 90% light-sleep energisparläge. I light-sleep drar ESP32 ca 15mA från 5V USB, samt ca 52mA i aktiv drift utan WiFi och med WiFi i snitt runt 75mA grovt. Fungerade jättebra!
I sådan drift blir strömförbrukning ca 19mA i snitt, vilket känns rätt OK. Vid drift från 12V via DC-DC-konverter bör det bli lägre, beroende på effektiviteten hos DC-DC-konvertern.
2023-01-23
Gjort nu att i strömsparläge med light-sleep så väntar koden adaptivt in en uppdatering av LCD, vilket då tar 2-5% av cykeltiden. Så medelströmförbrukningen då blir vid 5% 0,05x52mA + 0,95x15mA = 17mA från 5V USB. Samt lagt in att när någon av de fyra tryckknapparna är nedtryckt går den ur strömsparläge. Fungerar bra.
It is common to use the idle hook function to place the microcontroller CPU into a power saving mode. The Idle Task Hook - får titta in på detta för light-sleep strömsparfunktion!

INA226 breakout-boardet har en 100mOhm strömshunt, så ställt in INA226 för 100mOhm och 1A mätområde nu under inledande testande. Då mäter den med 0,00125V / 0,00003A upplösning (1 LSB step size). Med ström via 1k+3,3V matningsspänning mäter den då stabilt 3,28625V, 0,00366A samt 0,012W, utan att siffrorna ändras sig alls, dvs utan något som helst brus! Någon gång glest ibland växlar den till 3,28750V dvs 1 LSB upp. Mätvärdena är då medelvärdena av 512st avläsningar av strömshunten, spänningen samt effekten under 1,1s. Medelvärdesbildningen i INA226 så ger väldigt stabila mätvärden samtidigt som avläsning 512ggr/1,1s internt i INA226 fångar upp snabba förändringar i batteribankens ström / spänning för noggrann Ah/Wh-mätning!
Håller jag med två fuktiga fingrar över 1k-motståndet ökar strömvärdet till 0,00369A med just +0,03mA minsta mätsteget (1 LSB step size).
Så med 100A 0,5mOhm strömshunt blir mätupplösningen 3mA i mitt off-grid solcellssystem!
Senare ska jag ta bort strömshunten på INA226 breakout-boardet och koppla mot extern strömshunt 60A / 60mV som jag har i mitt lilla experiment off-grid solcellssystem här hemma.

Mätt med digitalt minnes-oscilloskop för: Interrupt → ISR → ISR Deferred Handling Task

Finns lite att läsa på hos espressif kring snabbheten för Interrupt och kod:
High-Level Interrupts
Interrupt allocation
Maximizing Execution Speed

Med portYIELD_FROM_ISR() / taskYIELD_FROM_ISR() context switch (ger samma funktion) i ISR fås en bra realtidsfunktion med extremt liten variation i de ca 25µs Deferred ISR Interrupt Latency, ESP32 Interrupt ISR → Deferred Task interrupt processing latency! En extrem skillnad mot utan Yield() då latencyn varierar slumpmässigt ≤1ms!
Mätt med digitalt minnes-oscilloskop för: Interrupt → ISR → ISR Deferred Handling Task.
void IRAM_ATTR ISR_INA226Batt(void)
{
 auto InterruptTime = esp_timer_get_time();
 BaseType_t xHigherPriorityTaskWoken = pdFALSE;
 xQueueSendToBackFromISR(DeferredInterruptQueue, &InterruptTime, &xHigherPriorityTaskWoken);
 if( xHigherPriorityTaskWoken )
 {
  portYIELD_FROM_ISR(); // same as taskYIELD_FROM_ISR()
 }
}
Beskrivning av ISR context switch samt FreeRTOS: Why to call taskYIELD_FROM_ISR() method within the isrHandler. "Calling either xQueueSendFromISR() or xQueueReceiveFromISR() within an interrupt service routine can potentially cause a task to leave the Blocked state which then necessitates a context switch if the unblocked task has a higher priority than the interrupted task.
A context switch is performed transparently (within the API functions) when either xQueueSend() or xQueueReceive() cause a task of higher priority than the calling task to exit the Blocked state. This behavior is desirable from a task, but not from an interrupt service routine. Therefore, xQueueSendFromISR() and xQueueReceiveFromISR(), rather than performing the context switch themselves, instead return a value indicative of whether a context switch is required. If a context switch is required, the application writer can use taskYIELD_FROM_ISR() to perform the context switch at the most appropriate time, normally at the end of the interrupt handler."
Utan Yield() varierar ESP32 Interrupt ISR → Deferred Task interrupt processing latency mellan 52µs till 900µs.
Beror troligen på att FreeRTOS portTICK_PERIOD_MS är 1ms i ESP32, dvs FreeRTOS tick rate = 1000Hz som är så ofta FreeRTOS kan växla mellan Task under sin Preemptive Multitasking. Min ISR Deferred Interrupt Task har här priority 7 (medelhög).
ESP32 FreeRTOS max Task priority är: 24. Low priority numbers denote low priority tasks. The idle task has priority zero (tskIDLE_PRIORITY).
Max latency utan Yield() för ISR → deferred interrupt processing kan därmed sannolikt bli ≤1000µs = portTICK_PERIOD_MS för en deferred Task med högre prioritet än övriga Tasks.

2023-01-28
Har idag kodat in en finite-state machine i form av en C++ class i mitt ESP32 batterimonitor / PWM-regulator hobbyprojekt. Blev riktigt bra och trevlig!

Styr och håller koll på vilka driftslägen den arbetar i samt sköter om växlingen mellan olika driftslägen på ett strukturerat robust sätt, så jag smidigt kan sköta det från en central kod-funktion.
Blir nu mycket tydligare i programkoden vad som görs samt väldigt mycket enklare att implementera en avancerad robust funktion kring detta! Som att stänga ned i light-sleep kräver att det görs i ett antal steg för bra stabil funktion i mitt projekt, och då tar finite-state machinen hand om den processen bl.a. att stänga ned WiFi först.
Och behöver jag framöver optimera en sådan process eller föra in nya driftslägen så blir det väldigt smidig med en gemensam central kod / class som tar hand om det.

Nu har jag för WiFi / Webbserverns drift samt för CPU-diftsläge / strömsparläge med olika CPU-klockning samt light-sleep. Kommer senare även att ha för PWM-regulatorn och dess olika laddfaser för blybatterierna.
Kan då även från olika delar i koden fråga finite-state machinen om aktuellt driftsläge för de olika funktionerna.

Är väl något man gjort intuitivt förut också, men inte såhär formaliserat och tydligt, vilket blev mycket bättre och kraftfullare :-)
Så känns som detta projektet tog ett tydligt steg framåt idag!
Även lagt in ny LCD-meny för dels att nolla datan för ESP32 Hard- / WDT-resets, dels för Ah/Wh.
Samt lött in en 470µF/16V/105°C och en 2.2µF/50V R82 kondensator mot den pyttelilla som finns invid ESP32-shipets 3,3V matning, för att hantera när ESP32 sänder data via WiFi.
2023-01-29
Nu summerar ESP32 Ah/Wh både vid CPU 240MHz och i Light-Sleep energisparläge. Lagt in en Serial.print() som visar miljarddelar av en Ah/Wh för att lätt kunna följa summeringen över tid där med den lilla 0,00366A ström (1kΩ) 3,28500V jag mäter just nu.
Får utskrivet vid Light-Sleep / 240MHz typ:
Serial.print(): INA226 Interrupt Time: 45232715734µs, TimeDiff (µs): 2261571 / 1129689, 0.046016466Ah, 0.153235674Wh, 99.959991% vid ström 0,00366A och spänning 3,28500V.
Ger 0.046016466Ah / 0,00366A = 12,57h samma som 45232,715734s / 3600 = 12,57h så OK!
Har då infört en C++ BatteriMonitor class som tar hand om denna loggning.
Har även optimerat funktionen vid drift med Light-Sleep så INA226 växlar till AVERAGE_1024 från AVERAGE_512 annars som ihop med 1,1ms conversion-time ger 2,2s resp. 1,1s cykeltid, samt gjort lite annan kod tydligare. Med 2,2s cykeltid blir Light-Sleep driften extra strömsnål.
Processorn väcks upp ur Light-Sleep via INA260-interrupt och efter avlästa mätvärden, uträknade Ah/Wh och uppdaterad LCD sätts i Light-Sleep igen. Så är då i Light-Sleep >95% av tiden när i energisparläge typ nattdrift, där den då drar 15mA från 5V USB.
2023-01-30
Mätte med ESP32+INA226 i frysen (-18°C) och då blev 0,00000A i rumstemperatur -0,00012A nedkyld vid 1A mätområde, så en hyfsat liten inverkan. Mätningen strulade lite så vet inte hur säkert resultatet blev. Motsvarar då -12mA vid 100A mätområde, ca 2Ah/vecka i felvisning så ifall. Men jag har tänkt att automatiskt regelbundet nollström-kalibrera mot aktiv float-laddström vid 100% SOC fulladdat så även batteribankens självurladdning kommer med, så då blir påverkan försumbar.
Är tänkt att göra en förenklad ML (Machine Learning) hur det varierar med batteritemperaturen, en sorts kalibreringstabell-funktion vs batteritemperatur, för extra precision i Ah-räknandet. Senare kanske via TinyML / Tensorflow om det verkar kunna ge någon fördel.
Även tänkt utvärdera batteriverkningsgrad på liknande sätt, vs temperatur, urladdningsdjup, tid sedan senaste fulladdat, etc.
2023-01-31
Köpt DollaTek 10st MP1584EN ultra liten DC-DC 3A ström step-down omvandlare efter tips om att DC-DC-omvandlare baserade på MP1584 har låg tomgångsström (quiescent current). Testat nu och utan utgående ström drar de låga 0,24mA matad med 12,5V, och ut 7,03V belastade med 22Ω / 0,304A drar den 0,182A. Blir 7,03 x 0,304 / (12,5 x 0,182) = 0,94 dvs 94% verkningsgrad vid så låg belastning! Känns lovande för låg strömförbrukning för ESP32 i drift matad via denna! Bör kunna bli ca 10mA i strömsparläge typ nattdrift med bara loggning av strömförbrukning från/till batterierna aktiv med >95% i light-sleep som drar 15mA från 5V USB. Målet har varit <15mA för strömsnål vinterdrift. Får se hur den och ESP32 trivs ihop.
Driftstemperatur: -45°C till 85°C, Storlek: 22mm gånger 17mm.
Finns även hos svenska Invize: Spänningsomvandlare step-down 3A MP1584
2023-02-01
Ändrat så vid night-mode strömsparläge med light-sleep sänks CPU-frekvensen från 240MHz till 80MHz. Med 10, 20 & 40MHz fungerade inte Serial.print() OK, troligen för ESP32 inte hinner skriva databuffertern innan satt i light-sleep. Övriga koden fungerade helt OK även vid 10MHz!
Men är OK med 80MHz som då ger omkring 0,05x40mA + 0,95x15mA = 16mA från 5V USB. Bör kunna bli ca 10mA i snitt via DC-DC-konverter från 12V, klart under målet <15mA.
Har mätt nu och drar ca 11mA från 12,5V vid 7,0V ut vid night-mode strömsparläge med light-sleep, så är nöjd med det! Går kanske att trimma ned till 6,5-6V, men får bli senare testande vart den gränsen går.
Kodat så bara de ändrade mätvärdena skickas över via SSE (Server Side Events) till webbsidan, vilket både belastar SSE mindre samt gav lägre strömförbrukning. Då även kodat in en liten punkt som blinkar på webbsidan i takt med uppdateringarna, så man ser att SSE är aktiv även om inga siffervärden ändras. Den punktens events() uppdaterar även canvas-grafiken.
2023-02-03
Kodat in att menyinställningarna för strömshunt (mV/A, typ 60mV/60A) nu även ändrar inställningarna i INA226 via ina226.setResistorRange(Ω,A), så därmed kodmässigt klart för inkoppling mot blybatteriet i mitt lilla experiment off-grid solcellssystem.
Även installerat breadboard och ESP32 på en gemensam bottenplatta med fasta kopplingsplintar för att säkert kunna dra elledningarna till batteriet. Blir inte så bra direkt från breadboard!
2023-02-04
Kört och loggat min lilla testström lite längre idag, här i strömsparläge / light-sleep:
INA226 Interrupt Time: 26808049418, TimeDiff (us): 2262446, -2.735489130Ah, -8.853511810Wh, SOC 97.621315%. Kodfunktionen för Ah / Wh & SOC är på plats!
2023-02-05
Optimerat Task_LCDbuttonsHandler() för snabbare respons på knapptryckning samt mindre inverkan på övrig kodexekvering. Blev även en renare, tydligare och kortare kod kring I2C.
2023-02-16
Är bara INA226 spänningsmätning VBUS som har 830kΩ ingångsresistans, strömmätningens ingångar I_IN+/I_IN- har en Input bias current på typ 10µA, men uppmätt ca 35µA i drift!
Så går inte att göra en RC-filtrering på samma lätta sätt där som för VBUS!
Med 4,7µF/4,12kΩ (20ms RC) fick jag 341mA mätt med 500mA genom strömshunten! Utan 4,2kΩ mättes 501,7mA genom 60A/60mV shunten (LSB=1,8mA / 2,5µV).
Missat där så blev lite feltänk! Få fundera på hur jag kan göra istället för att inte missa strömmätningen mellan 2,2ms samplings intervallen! Vill få med även korta strömspikar!
Har nu 22Ω och 4,7µF för strömingångarna som skydd, vilket bara ger 0,10ms tidskonstant.
2023-02-20
Kopplat in min ESP32-batterimonitor till mitt lille experiment off-grid solcellssystem här hemma i lägenhet nu i testdrift.
Så jag kan testa i riktigt driftsmiljö och utveckla den vidare mot färdig funktion med verklig driftsdata för mer skarp drift.
Visar sig då ett elektriskt fenomen som gör att de snabba superkorta strömpulserna från min Battery Reconditioner (9kHz, >50A) ger fel strömvärden vid avläsning av spänningsfallet över 60A/60mV strömshunten. Det då även en så grov strömshunt innehar lite induktans så spänningen vid snabba strömpulser visar inte bara den resistiva spänningen över shunten utan en induktiv sådan också som blir som en falsk strömsignal! Så kondensatorn i strömmätningens RC-filter på 22Ω / 4,7µF laddas upp så det vid strömmar på 100-200mA fås 5-10ggr högre mätt ström, samt vid 800mA ca 2ggr högre!
Utan djupare analys trodde jag att de skulle ta ut sig över en cykel med inverkan av den mikroinduktansens strömtröghet, men gör uppenbarligen inte så!
Så ska försöka få lite hjälp med mer djup kunskap kring det från folk som kan elteorier mer på djupet än jag kan och kanske få tips eller tankar som gör att jag kan arbeta vidare med att nå en lösning även på det. Men kändes lite motigt tillfälligt nu.
Funderar lite kring om LC- eller LRC-lågpassfilter skulle kunna lösa det?
Men känns ändå jäkla skoj att kommit såhär lång nu!
Vid kontinuerlig jämn DC-ström mäter den med väldig hög precision!
Lite input kring detta:
- Kalkylator för låg-/högpassfilter
- LC Filter Calculator – How LC filters work
- LC low pass calculator
- Basic Knowledge of LC Filters
- Transient Robustness for Current Shunt Monitor, Tips?
- TI: INA226 - pulse current measurement
- INA226: 1uA measure current resolution for INA226
- INA226: Measurement resolution and ADC error, 1 LSB Shunt Voltage: 2.5µV
- INA226: Current measurement error with PWM motor driver
- INA240 -4 to 80V, bidirectional, ultra-precise current sensor with enhanced PWM rejection
- ESP32 corrupt heap when handling multiple simultaneous requests, Websockets has been updated / fixed, but SSE (which has similarities with websockets) not. As stated I use Server Sent Events so possible an issue still exists in SSE. (2018, ESPAsyncWebServer)
2023-02-23
Mätt upp strömförbrukningen till: 35mA/12,5V WiFi/webbserver + LCD-bakgrundsbelysning + ESP32 240MHz awake, 33mA vid 1/3-del "Soft" LCD-bakgrundsbelysning mode.
Drar 9mA i snitt med Wifi-OFF, släckt LCD-bakgrundsbelysning, ESP32 80MHz samt light-sleep som väcks upp av INA226-interrupt bara för att kort läsa av nya mätvärden och uppdatera LCD-display 1ggr/2,2s, vid 7,0V från DC-DC omvandlaren. Under själva light-sleep drar den 7mA.
Känner mig nöjd med 9mA då det är <<15mA som var målet!
2023-02-26
Mätt upp strömvärden i off-grid solcellsdrift via de tre olika källorn PWM-display / DMM (True RMS spänning över strömshunt) & INA226 (över strömshunt 60A/60mV), när PWM-regulatorn strömpulsar med drygt 8A pulser 30Hz (ca 7% duty-cycle) samt en Battery Reconditioner strömpulsar >50A 9kHz extremt korta strömpulser genom strömshunten in i blybatteriet:
Mätn1: PWM: 0,3A / DMM: 0,55A / INA226: 1,483A
Mätn2: PWM: 0,2A / DMM: 0,48A / INA226: 1,459A
Vid Batteri: 13,87V = PV Throttle, INA226 mätt ca 20W.
Så är något i min mättekniska utformning kring INA226 som måste fixas för att hantera sådan kraftigt strömpulsad mätning OK!
När ingen strömpulsning förekommer mäter alla tre källorna lika strömvärde!
OBS! PWM-regulatorns egen strömmätning från solpanelen visar också stort fel gentemot DMM True RMS mätvärdet, och då inkluderar det även ESP32´s egenförbrukning på 9mA samt Battery Reconditioner´s på ca 20mA!

2023-03-02
Fått strömmätningen med kraftiga strömpulser att fungera nu genom att spänningen över 60A/60mV strömshunten filtreras i ett LRCL-filter vid ingångarna till INA226. Nu stämmer strömvärdena från INA226 med DMM True RMS spänningsmätningar (mV med 2 decimaler) över strömshunten. Ska utvärdera och analysera mätningarna mer noga framöver. Jag kan inte ännu riktigt förklara el-teoretiskt varför det fungerar så och därmed inte heller optimera komponentvärdena för det. Men troligen är det inte mer känsligt än för ett RC-filter, då det ser ut att visa rätt med båda de helt olika strömpulserna! Har gått på min analyserande intuition vad som borde kunna fixa detta!
Visar en liten sneak-peek från mitt grafiska dashboard för "PV off-grid Operational status" i verkligt drift nu i mitt lilla experimentella off-grid solcellssystem vid mobil-laddning.

2023-03-07
Presentation av projektstatus i ett par Facebook-grupper:

---

Nu har jag mitt ESP32-mikrokontroller baserade batterimonitor projekt i drift sedan en dryg vecka här hemma i mitt lilla experiment off-grid solcellssystem i lägenheten :-)
Känns riktigt skoj att kommit så långt, men är lite svårare än jag tänkt och tar rätt mycket tid att utveckla!
Laddar mobilen här 9 månader/år för att få lite verklig drift, övrig tid på vintern räcker inte strömmen till. Så är mobil-säsong nu igen.
Skoj då att kunna följa driften så detaljerat nu :-)

Med 60A/60mV strömshunt här kan den mäta med en upplösning på 1,8mA (LSB). Med 100A/50mV strömshunt i mitt riktiga off-grid solcellssystem blir det med 3,0mA LSB, så bra precision.
Med INA226 "ultra-precise I2C output current / voltage / power monitor" med väldigt hög precision samt hög noggrannhet över lång tid och stort temperaturområde (så jag inte trodde det var tekniskt möjligt med den prestandan) så bör jag få en riktigt fin precision hos batterimonitorns mätningar, även över hyfsat lång tid.

INA226 får göra upprepat i kontinuerlig följ 512st mätningar av spänning / ström / effekt under 1,1s som den då medelvärdesbildar och sätter en interruptsignal till ESP32 att det finns nya mätvärde att hämta från dess buffert. Så ESP32 hämta varje 1,1s nya sådana fint aggregerade data till sina beräkningar. Får på så sätt både väldigt stabila data som ändå tar med snabba förändringar i ström / spänning 512ggr/1,1s!
I ESP32 mäter jag tid med 1µs upplösning, så beräkningen / summering av Ah och Wh sker med väldigt hög precision så också.

Jag har en Battery Reconditioner till batteriet som via strömshunten strömpulsar med väldigt korta skarpa pulser på >50A i 9kHz för att motverka sulfatering samt PWM-regulatorn strömpulsar med >8A 30Hz när den begränsar laddströmmen för att anpassa laddningen till batteriet.
Jag har nu lyckats få till att jag ändå kan mäta så små strömmar som några mA utan att mätningen störs ut av de höga strömpulserna, och samtidigt mäta strömmängden de höga strömpulserna ger. Ska senare utvärdera lite bättre hur bra det blivit, men ser så här långt riktigt bra ut. Min NASA BM1 batterimonitor jag har i mitt off-grid solcellssystem idag störs helt klart av det strömpulsandet och mäter inte riktigt rätt då. Samt den är inte riktigt temperaturstabil eller långtidsstabil heller, men har ändå haft väldigt bra nytta av den under många år.

Har även en webbserver kodad i ESP32 med webbsidor som visar driftsdata, statistik och info på fem olika webbsidor, som jag då via WiFi kan se i webbläsaren på mobilen eller på en dator, som man ser i mobilen på fotot.

Men är rätt mycket jobb kvar ändå till helt färdigt.
Att göra en egen batterimonitor såhär innebär att jag kan visa precis den driftsdata och statistik jag vill se, samt som det ser ut nu kan jag få en väldigt hög precision i mätningarna.
Ska senare även försöka att skicka data via WiFi / Internet till en webbsida jag har på webbhotell, där jag kan samla driftsdata över längre tid, samt som jag då kan se hemifrån eller vart jag än befinner mig.

Men några gånger har jag nästan varit på väg att ge upp då det dykt upp svårigheter som kändes omöjliga att lösa för mig, men jag lyckats med till slut ändå :-)
Samt är mycket nytt att lära för mig, då detta är mitt första ESP32-projekt samt första gången jag använder FreeRTOS i kodandet! Tror dock jag tagit mig igenom de värsta svårigheterna så nu...

Jag gör detta som ett hobbyprojekt till mig själv för bättre funktion i mitt off-grid solcellssystem i husvagnen och är bara självlärd inom elektronik, C++ kodning samt ESP32-mikrokontroller.
Samt gör det även lite för att ha något tekniskt att engagera mig i och få stimulans från som pensionär.
För de som är nyfikna kan man se mer på min webbsida för projektet:
https://www.nordicoffgrid.se/datalogging/batterymonitor.php

---

2023-03-08
Texas Instruments benämner sin sensor INA226 jag använder för "ultra-precise I2C output current / voltage / power monitor". Så ihop med den precision jag kan får ut ur ESP32 så får jag kanske då en ultra-precise batterimonitor som kan mäta sig väl mot de som finns på marknaden.

Det jag via min ESP32-batterimonitor nu följt laddningen i mitt 44Ah blykolbatteri här hemma senaste dygnet är riktigt intressant, där -2Ah urladdat (95% SOC) återladdades igår via bulk-, absorptions- och float-laddning i fullt solsken under dagen ger en väldigt detaljerad info om laddförloppet.
PWM-regulatorn skiftade från kontinuerlig float-laddning till bulk- / absorptions-laddning, då batterispänning sjönk till ca 12,3V vid mobilladdning, under <12,4V som är gränsen för det. Är det initiala spänningdroppet "coup de fouet" man får vid riktigt 100% SOC fulladdade blybatterier i bra kondition, så strömpuls-laddningen har verkligen hunnit fräschat upp blybatteriet efter ca 2,5 vintermånader utan att nått 100% SOC full laddnivå!
Riktigt skoj att kunna följa det så noga, vilket även gav mig ett par nya intressanta kunskaper kring blybatteriladdning.

Kunde bl.a. bekräfta ett antagande jag gjort utifrån ett flertal olika källor om nivån på 0,015C / 1,5% tail-current (1,5A/100Ah) som gräns där absorptions-laddningen bör avbrytas för optimal laddning, så man låter blybatterierna själva tala om när de fått lagom med absorptions-laddning.
Så kommer använda det i min egna PWM-solladdregulator.
Strömmen under 3h absorptions-laddning gick ned till <0,44A/44Ah (0,01C / 1%) utan tvekan där, så blir bra marginaler!
Samt vid 13,8V float-laddning stabiliserade sig den pulsade laddströmmen på ca 200mA (för högt). När solen sedan började gå ned så solcellsströmmen sjönk långsamt och stabilt så blev strömmen vid 13,4V ca 35mA, vilket känns mer lagom för standby-laddning.
Är så grovt och primitiv att köra med en fast tidsgräns för absorptions-laddning, och även med en adaptiv tidsfunktion mot batterispänningen precis när laddningen startar på morgonen blir en grov osäker styrning av blybatteriladdningen, om än något bättre.

Senare ska jag koda lite mer analytisk funktion så jag får ut än mer intressant data från den, som även ska kunna styra laddförloppet bättre.
Jag tycker hela den här branschen med 12/24/48V off-grid solcellssystem är lite seg i att utnyttja den moderna tekniken och skapa lite aktivare smartare laddhantering.
När man gick från oreglerad laddning till s.k. smarta batteriladdare för blybatterier var det ett stort steg, men lite synd utvecklingen verkar ha stannat där känner jag!
Man verkar helt ha nöjt sig med vanlig flerstegsladdning med fasta gränser!

På kvällen uppdaterades de grundbibliotek från Espressif man använder för ESP32 kodning inkl. Arduino v2.0.7, och var några buggfixar där som eventuellt åtgärdar några saker jag haft lite problem kring med WiFi / Webbservern.
Har även gjort lite code refactoring så jag nu fått in i stort all driftsstyrning via en Finite-State Machine (FSM) och därmed en bättre tydligare funktion. Innebär att alla de olika driftslägena, "states", nu styrs och växlas mellan av StateMachine-koden, så allt det är samlat på en plats och det blir inte redundant kod. Blir även mycket enklare att underhålla den delen av funktionaliteten samlad centralt på så sätt, samt mindre risk för buggar.
En tydlig förbättring blev att jag införde en Task_StateMachine() för asynkron växling av driftsläge, så t.ex. inte aktivering av WiFi / Webbserver blockerar responsen hos tryckknapparna. Task_StateMachine() kommunicerar med class StateMachine som har en synkron funktion.
Idag 14 Mars när jag aktiverade ESP32-batterymonitorn med en knapptryckning på morgonen kopplade den upp snabbt smidigt mot WiFi, vilket efter en natts drift tidigare ofta varit trögt och ibland misslyckats. Om det håller i sig är det ett signifikant framsteg mot stabil 24/7/365 drift!
Jag hade en svag intuitiv känsla att en asynkron Finite-State Machine (FSM) funktion skulle kunna ha den inverkan, så håller tummarna för det!
Förfinade även ESP32-webbsidornas meny-funktion lite, med att när man tryckt på ett menyval så fälls meny in snyggt mjukt igen tills webbläsaren hinner växla webbsida.
2023-03-15

Även idag startade ESP32-batterymonitor upp WiFi snabbt och smidigt vid knapptryckning!
Samt flera gånger under gårdagen och kvällen.
Kan även se att när WiFi / Webbserver stängs ned frigör mycket SRAM nu (52% till 76% ledigt), vilket inte skett tidigare, så indikerar också tydliga förändringar i kodens funktion som känns positiva. Samt lägsta ledigt SRAM nu 129204b under dessa dygn och största allokerbart heap block 110580b stabilt. Är ca 161970b vid 52% ledigt SRAM.
Är stabilaste drift hittills under flera dygn såhär! Känns riktigt lovande!
Aktiv WiFi, webbserver och SSE-data till webbsida drar ca 35mA för sin drift, så rätt måttligt.
2023-03-16
Helt stabil snabb smidig uppkoppling mot WiFi nu tredje morgonen (24/3-drift) i drift också, när aktiverad med knapptryckning! Riktigt upplyftande, känns att jag går i mål med detta nu.
Samma många gånger under hela gårdagen, så ett riktigt bra framsteg för 24/7/365-drift!
Är sannolikt en kombination av WiFi-buggfixar i Platform-espressif32 v6.1.0 / ESP-IDF v5.0.1 / Arduino v2.0.7 samt min dynamiska Task_StateMachine() ihop med min code refactoring!
2023-03-17
Har två gånger fått kod-krascher när jag aktiverat WiFi / Webbserver med felmeddelandet:
"Guru Meditation Error: Core 0 panic´ed (IntegerDivideByZero). Exception was unhandled."
Har lite snabbt sökt men inte hittat orsaken i min kod. Ska göra det noggrannare senare!
Men ESP32 fixar Rebooting snabbt och bra direkt efter det, så inget som direkt påverkar stabil 24/7/365-drift annat än att <15min (<2hr) data förloras!
2023-03-18

Har kodat "Senaste 24-timmars löpande stati­stik" för ström­men, med Akuell-, Medel­värd­es-, Max­värd­es- & Min­värd­es-ström över sen­as­te 24 timmarna löpande. Ska bli för de andra mätvärdena också. Får här tränga djupare in i C++, klasser och objektorientering m.m.!
Ger en bra överblick över senaste dygnets drift i off-grid solcellssystemet.
ESP-batterimonitorn fortsätter att arbeta stabilt över dygnet.
2023-03-19

Hade haft Nordic­Off­Grid Batteri­mon­itorn i drift i dryga 24h när skärm­dumpen från mobilen togs idag. De senaste 24h har medel­ström­men då varit -5mA i det väldigt gråmulna vädret, samt Max +73mA och Min -82mA. Max ladd­ström mitt lilla ex­peri­ment sol­cells­sy­stem ger är ca 1A i bra soligt väder, så idag ca 7% av det som mest. Är mätt med en 60A/60mV ström­shunt.

Det löpande ström­medel­vär­det för 24h är beräknat på ca 80.000 ström­värd­en hanterade i ESP32 från INA226-sensorn, som i sin tur skapar varje sådant strömvärde som medelvärdet under 1,1s för 512st strömmätningar.
Så totalt baseras det löpande 24h strömmedelvärdet på ca 40.000.000 strömmätningar, vilket ger bra precision! Liknande gäller för Max- och Min-värdena. Max- och Min-värdena bygger på de under 1,1s medelvärdesbildade mätvärdena från 512st mätningar i INA226, så korta irrelevanta strömspikar filtreras bort på så sätt. Blir samma för batterispänning och övriga datamätvärden också.
Med så många mätvärden blir det viktigt med en bra effektiv algoritm för hur man hanterar det i programkoden, och jag har fixat en som både är väldigt snål på minne och CPU-belastning.

Med strömmedelvärdet för senaste 24h kommer jag göra en bra tidsprognos för hur länge kvarvarande batterikapacitet bör räcka, något helt annat än den prognos baserad på momentan-strömmen min NASA BM1 ger idag. Baserat på momentanström fås olika tidsprognos när 12V kylskåpskompressorn arbetar eller pausar i sin drift, helt oanvändbart! Med 24h tas även den lägre strömförbrukningen under natten med i prognosen.
Ger en bra överblick över senaste dygnets drift i off-grid solcellssystemet.
Blir mer som driftsövervakning av off-grid solcellssystemet än bara batterimonitor!
Ger på så sätt en tydligare överblick över driften av min Victron blykolbatteribank, samt kommer bättre kunna planera aktiv drift i lite längre dåligt solcellsväder.
Känns roligt med en batterimonitor med bra precision och bra info via aggregerad data :-)
2023-03-24

Har idag kodat en "Time To Go" panel för en bra tidprognos över hur länge kvarvarande batterikapacitet bör räcka för driften vid urladdning, eller tid till fulladdat när solcellerna laddar upp batteribanken. Upp↑/ned↓-pilar visar laddning/urladdning.
Visar bara i hela dagar och timmar, då minuter blir för precist i förhållande till den långtidsprecision man får i ett sådant här system anser jag, och kanske än mer till hur noga man rent tekniskt kan synkronisera 100% SOC med verkligt fulladdad batteribank. Blir då inom ±30min som ↑↓1hr visas avrundat.
Tidprognosen visas dels för senaste löpande 24hr strömmedelvärde, dels för senaste 1hr strömmedelvärde. På så sätt får man en stabil bra uppfattning över hur man ligger till med driften av batteribanken och off-grid socellssystemet oavsett lite varierande ström över dygnet eller från kylskåpskompressors drift ON/OFF, från korta solglimtar, etc. "Time To Go" baserat på momentanström är värdelös!
Kanske blir det senare någon form av adaptiv funktion för 1hr visningen, som någon gav förslag på för anpassning till hur aktuell drift är.

Idag är det väder med ständigt korta solglimtar, men får då ändå en stabil fin prognos för hur lång återladdningstid som är kvar, istället för att den hoppar kraftigt fram och tillbaka efter hur den momentana strömmen är i systemet!
Strömmen varierade då 400-500% till 1000% snabbt upp och ned, så blir svårt att bilda sig en uppfattning på det momentana strömvärdet / tidsprognosen, men med 1hr medelvärde får man ändå stabila fina värden både för strömmen och återstående laddtid! Riktigt häftigt!

Ska även bli löpande 7dygns statistik och troligen även 30dygns, för än bättre info, insikt och överblick det ger över off-grid-systemets drift. I ett sunt dimensionerat off-grid solcellssystem med ≥5dygns dåligt-väder-reserv (Days Of Autonomy) utjämnar batteribanken normalt variationer i strömproduktion av verkligt väder över minst 1-2 veckors tid, så 7dygns strömstatistik är värdefullt i sådan drift.
Min vision med detta är även ett system som helt autonomt smart kan styra laster efter hur mycket ström den utvärderar att det finns att utnyttja över tid, typ 4G router, fläkt, belysning, etc.

Skapat en TIME-panel för dels ESP32 Uptime, dels för datum/tid för ESP32 RTC samt Client tid, så kan se hur länge ESP32 varit igång sedan senaste bootning samt kan jämföra hur ESP32 RTC-tiden håller sig och är uppdaterad.
Har efter det fått ett par panic-reboot med felmeddelandet: "Guru Meditation Error: Core 0 panic´ed (LoadProhibited). Exception was unhandled.", som jag får felsöka!
The error LoadProhibited means that the CPU tried to load a variable form an illegal address.
Do you use String Class and do a lot off String constructions with String c = "a" + "b", or are you creating char arrays on the fly e.g. char d[ ] = "efg".
Arduino: ESP32 - Guru Meditation Error: Core 1 panic´ed (LoadProhibited): "My guess is that "lastData" returnedData = int(lastData[7]); has not been set and is still a null (0) pointer. You get an error when you try to read address 7."
Har lagt in att alla class StateMachine´s public variabler initieras i dess Constructor StateMachine(), kanske en möjlig orsak? En variabel, ESP_Time_us, som jag missat där används tidigt för just Uptime, kanske innan den hade initierats med något värde!

Optimerat för detta när bara IP förloras, så WiFi nu ska startas om och återansluta IP:
15:32:02.824 > INA226 Interrupt Time: 144809137, TimeDiff(us): 4592239, -0.038083Ah, 0.596590Wh, 99.913%, 0.96/0.52W
15:32:05.962 > [157673][V][WiFiGeneric.cpp:374] _arduino_event_cb(): STA IP Lost
15:32:05.968 > [157674][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 9 - STA_LOST_IP
15:32:05.973 > WiFi.onEvent(): No WifiConnect, Event: 9
15:32:05.975 >
15:32:07.851 > INA226 Interrupt Time: 150549432, TimeDiff(us): 5740295, -0.038016Ah, 0.598343Wh, 99.914%, 1.10/0.54W
OBS! WiFi.status() != WL_CONNECTED blir nog inte True då, vilket jag nog förutsatt!?
Får fundera mer på det och söka kunskap om! Inträffar så väldigt sällan, så svårt att ha tur och fånga upp meddelandet såhär.Har modifierat nu så det bör återansluta WiFi / IP!
Hanterar nu dessa WiFi.onEvent(): RDUINO_EVENT_WIFI_STA_DISCONNECTED || ARDUINO_EVENT_WIFI_STA_LOST_IP || ARDUINO_EVENT_WIFI_STA_STOP för anrop av WiFiReconnect(), samt har tagit bort villkoret WiFi.status() != WL_CONNECTED för återanslutning.

Har problem med att sällsynt ibland (typ <1ggr/dag) så blir det kodexekveringsfel, men bara med WiFi / webbserver ingång vad jag kan se. I nattmode med nedsläckt LCD-display och WiFi / webbserver har jag aldrigt noterat det, så minskar ned koden jag behöver leta i. Samtidgt vet jag då inte om det är min kod eller Espressif system-kod för WiFi eller webbserver-biblioteket?
Skulle jag kunna använda IDF Monitor ihop med Espressif Arduino-framework så skulle jag få ut det radnummer det inträffar vid samt i vilken kod-fil! Då hade det genast blivit mycket lättare att hitta och åtgärda (om det är i min kod-fil), så får söka efter om det är möjligt på något sätt!

Felmeddelande jag får i Verbose mode (DCORE_DEBUG_LEVEL=5):
Guru Meditation Error: Core 0 panic´ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x40094090 PS : 0x00060233 A0 : 0x80094506 A1 : 0x3ffe1c10
A2 : 0x3ffb8014 A3 : 0x3ffb8e1c A4 : 0xabba1234 A5 : 0x00000010 A6 : 0x00000003 A7 : 0x00000003 A8 : 0x00000003 A9 : 0x00000002
A10 : 0x3ffb8e18 A11 : 0x0000003c A12 : 0x00000059 A13 : 0x3ffb8e14
A14 : 0x3ffb8e48 A15 : 0x00000000 SAR : 0x0000001d EXCCAUSE: 0x0000001d
EXCVADDR: 0xabba1240 LBEG : 0x4008be5d LEND : 0x4008be6d LCOUNT : 0xfffffffe

Guru Meditation Error: Core 0 panic´ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x400ded89 PS : 0x00060030 A0 : 0x800deded A1 : 0x3ffe1d80
A2 : 0x3ffb85d4 A3 : 0xbaad5678 A4 : 0x3ffb85e0 A5 : 0x3ffb93c8
A6 : 0x0a0d0a0d A7 : 0x32343031 A8 : 0x800ded85 A9 : 0x3ffe1d60
A10 : 0x00000000 A11 : 0xbaad5678 A12 : 0x00000000 A13 : 0x3ffb857c
A14 : 0x00000000 A15 : 0x74000a0d SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0xbaad567c LBEG : 0x4008a530 LEND : 0x4008a546 LCOUNT : 0xffffffff

Här finns felbeskrivning av LoadProhibited, StoreProhibited:
"These CPU exceptions happen when an application attempts to read from or write to an invalid memory location. The address which has been written/read is found in the EXCVADDR register in the register dump. If this address is zero, it usually means that the application has attempted to dereference a NULL pointer. If this address is close to zero, it usually means that the application has attempted to access a member of a structure, but the pointer to the structure is NULL. If this address is something else (garbage value, not in 0x3fxxxxxx - 0x6xxxxxxx range), it likely means that the pointer used to access the data is either not initialized or has been corrupted."
Så antagligen försöker min C++ programkod läsa/skriva till en variabel som inte längre existerar (ett klassiskt C++ kodfel), som kanske skulle behöva göras static för att behållas i programminnet typ Local variable scope.
Eftersom exekveringsfelet inträffar i Core 0 (där Espressif WiFi systemkod ligger, ihop med en del av mina FreeRTOS Task) skulle jag som felsökning kunna flytta alla mina Task till Core 1 temporärt. Följer då felet med till Core 1 så är det någon av mina Task. Då kan jag flytta en Task i taget tillbaks och när felet följer med tillbaka till Core 0 så vet jag vilken Task som orsakar det. Men hade varit lättare om det inträffade oftare!
Verkar dock som jag lyckats skapa något pekar- eller variable scope-fel i min senare kodning nu! Känns bara lite konstigt att det inträffar så sällan med många timmar emellan!
Nu senast LoadProhibited med EXCVADDR: 0x00000005.
Får även senare framöver titta på Get started with Arduino and ESP32-DevKitC: debugging and unit testing!
Även kanske om problemen fortsätter: Please build project in debug configuration to get more details about an exception, ihop med PlatformIO meny: PROJEKT TASKS - wemos_d1_uno32 - General - Monitor (kan det vara "IDF Monitor"?).
Man ska inte använda färdiga kopplingssladdar till breadboards för strömförsörjningen till sin ESP32!
Har nu lokaliserat ett problem jag fick efter den senaste större kodförändringen till dålig kontakt och glappkontakt i just en sådan som går mellan min DC-DC-konverter och ESP32! Trodde naturligtvis jag fått till någon dum bugg i min kod, men hittade glappkontakt och sannolikt även dålig kontakt i den kopplingstråden. Sedan är det nog även något typ pekarfel i min C++ kod!
Samt efter de senaste kodförändringarna har ESP32 fått svårt att återansluta till WiFi / Webbserver, så något blev inte bra där!
Backar därför till senaste version jag märkt OK (2023-03-14), och där fungerar det bra igen. Så blir att återinföra förändringar sedan dess en i taget och checka när problemet uppstår. Går lätt via "Compare Selected" i PlatformIO / VSCode där jag får upp de två filer jag jämför sida vid sida med alla skillnader utmärkta, så bara kopiera kod mellan dem steg för steg via den pil-icon-kopieringsfunktionen som finns där. Blev två steg fram ett tillbaka nu, som det blir ibland!

Haft version 2023-03-14 i drift idag i drygt 8h med aktiv WiFi / Webbserver utan något problem. Har då modifierat koden så jag på Serial.print bara får ut debug- och felinformation, så det är lätt att följa vad som händer. Så denna versionen verkar helt OK och stabil!
Är inget minnesläckage heller under den tiden med: Fri SRAM 52% (161660b), Lägst ledig heap: 135324b samt Största allokerbara heap 110580b.
Så noga under så lång tid har jag inte följt upp kodexekveringen förut, även om jag haft igång den i flera dygn tidigare. Men ville nu vara säker på att jag utgår från en stabilt fungerande kod för felsökningen av senare tillagd kod!
Känns skönt, för då ska det lättare gå att hitta buggen / buggarna i den kod jag successivt återinför steg för steg nu igen.
Även om det känns lite märkligt att ett typ pekarfel kan inträffa så glest som 3-4h eller längre tid med programkoden exekverandes 1ggr/1,1s! Men är delvis asynkrona kodloopar med FreeRTOS Task ihop med att lite olika kod exekveras beroende på mätt batteriström, så kanske någon kombination kan uppstå så sällan då? Samt har bara hänt när WiFi / Webbservern är aktiva, så är i någon kod som bara exekveras då så har mina aningar var jag ska se upp lite extra när koden återinförs steg för steg! Detta är lärpengar som ny på objektorienterad C++ kodning!
Får läsa på lite mer om det, som typ: Grundläggande objektorienterad programmering i C++: Klasser och objekt, Creating a class object in C++, References to the class object. Access to a class object by reference., DuckDuckGo: C++ "class" "object" new pointer vs reference, DuckDuckGo: C++ new reference "class" "object", Static Objects in C++, Static Members of a C++ Class.
Ser ut som att jag missuppfattat någon nyans där och bör modifiera min C++ OOP-kod?
W3school testing C++ OOP coding.
Justerade C++ OOP-koden för alla class-object så den säkert inte allokeras i stack-minnet utan i heap, men blev samma kodkrascher ändå med koden för class RingBuffer24hr:
[746963][D][WiFiGeneric.cpp:931] _eventCGuru Meditation Error: Core 0 panic´ed (IntegerDivideByZero). Exception was unhandled.
Guru Meditation Error: Core 0 panic´ed (LoadStoreAlignment). Exception was unhandled. EXCVADDR: 0x401057be LBEG
Vid aktivering av strömsparläge light-sleep?
[747746][D][WiFiGeneric.cpp:931] _eventGuru Meditation Error: Core 0 panic´ed (IntegerDivideByZero). Exception was unhandled.
Kom efter: Uptime: 00y00m00d 00:12:26, med 12 minuters tid till aktivering av strömsparläge light-sleep!

Återinförde all kod utom den som gör statistiska beräkningar inom class RingBuffer24hr och då fungerar det stabilt inklusive Time-displayen med Uptime och datum! Så kodbuggen finns i den koden för statistiska beräkningarna inom class RingBuffer24hr eller dess SSE-skickande till webbsidan. Så får gå igenom koden för varje sådan statistikdata där och införa en och en tills jag hittat kodfelet. En hyfsat rimlig uppgift!
Skönt jag fått stabil drift igen så långt med koden!
Konstaterar samtidigt så tomt det känns med bara rå mätdata med frånvaro av den omgjord till information s.k aggregerad data! Så min vision kring detta är helt rätt och värt arbetet!
Och efter Uptime: 00y00m00d 01:35:34 kom det igen:
Guru Meditation Error: Core 0 panic´ed (LoadProhibited). Exception was unhandled. EXCVADDR: 0x00000005 LBE
Kommer så jäkla sällan, så svårt att veta vilken kodförändring som orsakar det!

Ska nog bara ha egen kod i Core 1 då man dels annars drabbas av komplexiteten av "ESP32 inter-processor communication" vad det gäller access till globala variabler med konflikt om man inte skapar exklusiv access via Semaphore-Mutex, dels kör Espressif all systemfunktion med WiFi på Core 0 som man riskerar att störa. Är risk det är bl.a. detta jag har haft problem med!
Provar nu att köra alla mina Task på Core 1.
Har tänkt att float- och int-variabler accessas inom en klockcykel så ingen risk för kollision där, men kan ju bli det när en global sådan variabel accessas samtidigt från de två olika CPU-kärnorna! Så ett lite feltänk pga oerfaren inom Multitasking- / Multicore-kodande!
Samt får nog även kolla att jag ger exklusiv access till globala double-variabler (s.k. none-atomic variables) då de tar två klockcykler att accessa, samt troligen samma till alla class-object instanser (eller bara dess funktioner()?) i min Multitasking-koddrift!

Nu har jag återställt all kod samt, fixat några små buggar, optimerat lite kod samt gjort lite Code refactoring, ihop med att all min kod nu körs på Core 1. Och nu ser det ut att arbeta stabilt och bra utan kodkrasch, i vart fall i ett par 3-4 timmar pass.
Har även omprövat min tidigare åsikt och redovisar nu "Time To Go" antingen som ddhh eller hhmm, dvs gått ifrån att visa timme som minsta mått utan tar även minuter så man får lite mer upplösning på det. Man får se det som tid kvar till att batterimonitorn når 100% SOC, vilket kan skilja något från batteribankens verklighet.
Kommer framöver för 24hr Time-To-Go statistiskt analysera hela dess datamängd och få en lite bättre prognos som aldrig bör komma fram till en fulladdad tid mitt i natten! Blir även senare liknande för löpande 7 dygns statistik!

Har fått in lite mer 24hr data, samt framförallt kunnat kör 1dygns och 17h stabil drift nu. Här ser man tydligt nyttan av 24hr Time-To-Go prognos över 1hr Time-To-Go prognos tidig morgon med bara en ytterst svag laddström ännu. Samt jag tycker det är smidigt med "24hr ΔCHARGE" som visar hur laddningen i batteribanken har förändrats under senast 24 timmarna, så man själv inte behöver memorera något sådant eller läsa av ur diagram. Ger en bra bild över utvecklingen av batteribankens laddstatus så man speciellt i sämre väder kan planera sin drift bättre.
Denna 24hr statistik baseras på 40.000.000 mätvärden / dygn av spänning, ström och effekt till/från batteribanken, så fångar även upp snabba förändringar för hög precision.
Är det VOLTAGE, POWER, DISCHARGE & SOC som också ska få sina 24hr data, vilket den mesta C++ OOP-koden redan är kodad för.
Ska senare bli en lika dan dashboard för "Latest 7days running statistics"!

Har nu passerat 5 dygns uptime, när detta skrivs 00y00m05d 06:43:11. Så det visar på hög exekveringsstabilitet. Det motsvar ca 412.000 programloopsexekveringar, så alla kombinationer borde ha hunnit uppstå då som kan leda till kodkrasch tänker jag.
Är lite av en milstolpe för 24/7/365-drift känner jag!
Är bara att koda vidare för att VOLTAGE, POWER, DISCHARGE & SOC också ska få sina 24hr data, vilket den mesta C++ OOP-koden redan är kodad för.

Nu är "Dashboard - Latest 24hr running statistics" färdigkodad och i drift, vilket känns skoj! Hann dessförinnan nå drygt 7 dygns kontinuerlig drift som är rekordet hittills.
Kan även konstatera att objektorinterad programmering (OOP) är bara så bra och smidigt, samt att jag trivs bra med att koda i C/C++ som ger väldigt snabb prestanda och minnessnål kod!
I Computer Sweden´s De 10 mest populära programmeringsspråken i april 2023 ligger C på 2:a och C++ på 4:e plats i populäritet, så är populära hos många.

Fick tips om IoTPlotter som "is a service which collects data from your IoT devices for long-term graph plotting and storage, completely free" där jag enkelt skulle kunna komma igång snabbt med att få upp data i diagram som jag når ifrån hela Internet. Som ett första steg innan jag kodat eget till mina egna webbsidor på Internet.
Men ska först göra ett snabbt test om jag inte lite enkelt kan skicka data till min egna webbsite.
Även fått tips att använda Grafana på egen server hemma för att visa aggregerad mätdata i olika dashboards som är lätta att tyda. Får kolla upp om det även går på min webbplats inhyrd på webbhotell! Grafana ser fint ut och har spanat in det för rätt länge sedan då Grafana kan ge fina grafiska dashboards.
Samt en som via Zabbix gjort egen monitoring från Victron-enheter i sin båt.
Själv skulle jag i framtiden vilja använda MQTT med en tidsdatabas typ InfluxDB + MQTT.
Samt för egen grafisk display ser LVGL - Light and Versatile Graphics Library trevligt ut.
Testkört min kod som utvärderar batteribankens Coulomb(Ah) och Energy(Wh) verkningsgrad i batterimonitorn. Än så länge med manuell aktivering för fulladdat batteri vid en "Tail current" på ca 0,005C (0,5%) laddström vid 13,8V aktivt reglerad float-laddning.
Vid cykling 100%-98%-100% SOC blir Coulomb(Ah)-verkningsgraden 48% för mitt gamla blykol-startbatteri jag använder i experiment solcellssystemet här hemma. Utgör den cykling min mobil-laddning ger.
Är betydligt bättre verkningsgrad än jag trodde för den lilla marginella cyklingen. Vid automatisk mätning av verkningsgraden senare ska det bara göras för de urladdningscykler som batteriet nått <90% SOC för att ge vettiga värden är tanken.
Denna aktuella verkningsgradssiffra kommer jag använda på ett smart sätt i batterimonitorn för att få riktigt bra precision i dess mätningar, vilket då sker med en ständigt uppdaterad aktuell verkningsgradssiffra för batteribanken.
Ska bli spännande att mäta på mina Victron lead-carbon batterier i mitt riktiga off-grid solcellssystem inom några veckor!
Här med laddströmmen 0,157A för 44Ah batteriet under aktiv float-laddning är det 0,0036C dvs ca 1,4ggr marginal mot 0,005C för Tail current! Är också något jag kunde övervaka för stabil robust funktion / drift, och till en början följa upp när i skarp drift. Nu under några dygn mätt till >1,5ggr lägsta ström vid aktiv float-laddning!
Inspiration / referens:
AI-felsökning i 5G-mobilnätet med maskininlärning visar hur analys av stora datamängder ger fördel!
Batteribolaget: "Tur-och-retur-verkningsgrad (urladdning från 100% till 0% och tillbaka till 100% laddning) hos det genomsnittliga blybatteriet är 80%. Motsvarande för ett LFP-batteri (LiFePO4) är 92%. Laddningsprocessen hos bly-syra batterier blir särskilt ineffektivt när 80% laddningstillståndet har uppnåtts, vilket resulterar i 50% effektivitet eller till och med mindre i solcellssystem där flera dagars reservenergi krävs (batteritid i 70% till 100% laddat tillstånd)."
TAO Performance: A complete Energy Management System
UPS VRLA lead acid battery predictive maintenance.

Nu vid 17-tiden blev en ny laddcykel klar vid Tail-current <0,005C (0,5%) och aktiv float-laddning i mitt gamla 44Ah blykol-startbatteri jag har i mitt lille experiment solcellssystem. Urladdade till 96% SOC laddnivå denna gången igår kväll vid laddning av urladdad mobil.
Fick då mätt av min ESP32 batterimonitor batteriverkningsgrad 75% nu mot 48% när jag cyklade till 98% SOC, vilket är riktigt bra för så minimal 4% DOD cykling. Det blykol-startbatteriet är från 2016, så indikerar att det är rimligt fräscht fortfarande märkligt nog men naturligtvis krävs det djupare urladdning för att avgöra det mer säkert.
Energiverkningsgraden 58% är inte helt OK mätt ännu, då jag har någon överledning / störning i hårdvaran vid låga effekter så den mäter fel där. Men vet ungefär vad jag ska ändra på hårdvarumässigt, dock valt att få programkoden rimligt färdig först.
Men programkoden verkar fungera fint som tänkt i att utvärdera batteriverkningsgrad!
(Siffrorna (99) / (97) är bara fake ännu, men ska bli något medelvärde över tid.)
Nästa steg är att lyckas koppla upp mot befintlig PWM-regulator så jag får en automatisk detektering av Tail-current 0,005C vid aktiv float-laddning för synkning mot 100% SOC fulladdad blybatteribank.

Infört en synkningsrutin för 100% SOC mot fulladdad batteribank vid grundare urladdningar där inte batteriverkningsgrad beräknas. Kom på en smart algoritm där som ger en noggrann synkning av 100% SOC mot fulladdad batteribank, utan några kepiga svåra inställningar! Får fundera på om den kunde användas för all 100% SOC synkning?
Utvärdering av batteribankens coulomb-verkningsgrad (Ah) är intressant data att ta del av, men främst är det viktig data för hög precision i batterimonitorns mätning av SOC/Ah-laddningsnivå status i batteribanken! Coulomb-verkningsgraden blir löpande utvärderad så den fås för aktuellt driftsmönster och batteritemperatur för bästa precision. På så sätt får man hela tiden aktuell batteriverkningsgrad för den typ av drift / cykling man har för sin blybatteribank samt för batteritemperatur och inverkan från åldrande batterier.
För att kunna mäta batteriverkningsgrad rimligt exakt krävs det att batterimonitorn har en bra precision i att kunna synkronisera sitt 100% SOC fulladdat mätvärde med verkligt 100% SOC fulladdat batteri, och där har jag fått till bra funktion nu.
Samt under de första tio cyklingarna kalibrerar sig batterimonitorn mot batteribanken!
Blir en helt annan precision än om man som användare ska försöka mata in ett fast sådant värde själv för batteriverkningsgrad som inställning!
Ska man uppnå en bra långtidsstabiltet i mätningarna av batteribankens SOC/Ah-laddstatus vid längre tids partiell (PSOC) cykling krävs ett bra verkligt värde för batteriverkningsgraden för att det inte ska driva iväg, så en viktig funktion för det. Med båda LiFePO4 och AGM-blykol (lead-carbon) som tål mycket PSOC-cykling blir detta mer viktigt hos en batterimonitor än tidigare!
I förrgår natt hade jag 230V 100W växelriktaren igång för att ladda ur lite så kom ned på 96% SOC laddnivå, och igår hann solen ladda det fullt igen. Hamnade då på 70,3% Coulomb­verknings­grad, vilket är jäkla bra för bara 4% DOD urladdning. I en vetenskaplig noggrann rapport mätte de upp ca 50% verkningsgrad vid cykling med 15-20% urladdning, och än sämre vid ännu grundare urladdningar hos ett fint kvalitetsblybatteri.
Så måste vara kombinationen blykolbatteri (mitt gamla Tudor High Tech Carbon Boost 2.0 startbatteri) och strömpulsad laddning från PWM-regulatorns som ger den bra verkningsgraden.

Är skoj att mäta upp och få data på, men den riktiga vinsten är i att med den datan kunna mäta urladdningsnivån (SOC / Ah-urladdning) i blybatteriet med högre precision då jag använder verkningsgraden i beräkningarna där! Här systemdata jag får ut (dock alla datavärden inte helt korrekt där då jag flera gånger laddat upp ny programkod som då stört mitt i mätningar).

Igår kväll/inatt laddade jag ur till 93% SOC så blev absorptions-laddning idag. Då denna PWM-regulator har en fast 3h absorptionstid så kom laddströmmen ned ända till 350mA (0,008C) innan växling till float-laddning, vilket är betydligt lägre än den 0,015C (1,5%, 0,66A/44Ah) Tail-current som är lämplig gräns att avbryta absorptions-laddningen vid för växling till float-laddning.
Om växling skett vid 0,015C Tail-current hade laddnivån då varit någon stans mellan 99,5-100% SOC, så absorptions-laddningen hade kommit väldigt nära 100% SOC fulladdat och bara några få 1/10-dels procent återstått att ladda via float-laddning!
Så blev en bra kvittens på att 0,015C (1,5%) Tail-current är en bra säker gräns att avbryta absorptions-laddningen vid, med god marginal mot hur låg laddströmmen kan bli under absorptions-laddningen. Visar även att 0,015C Tail-current hade avbrutit denna absorptions-laddning signifikant tidigare än dess nu fasta 3h gräns som ger lite onödig överladdning!
Ger ny intressant kunskap med en batterimonitor som mäter med så hög precision!
Så ger bra input till laddcykelstyrningen hos Nordic PV-controller.

Är inte bara för mig det tar tid att utveckla mjukvaran / programkoden och testa av den noga för denna batterimonitorn!
I höst skulle Volvos nya elbil EX90 börja produceras, men så blir det inte:
"– Volvo Cars behöver ytterligare tid i mjukvaruutveckling och testning och justerar den planerade produktionsstarten. Produktionen beräknas nu påbörjas under första halvåret 2024, uppger bolaget i ett pressmeddelande.
Även andra tillverkar har haft kraftiga förseningar pga tid som mjukvaruutvecklingen tar!
Nu har jag inför fälttest i mitt riktiga off-grid solcellssystem kvar att införa en meny för reset av statistikdata, två mindre funktioner som behöver en lätt optimering samt att skapa det elektriska informationsutbytet mellan befintlig PWM-regulators driftsmode och batterimonitorn. Så förhållandevis lite kvar :-)
Och även att bygga ett exemplar till av hårdvaran, men det går rätt fort!
Mätningen / utvärderingen av batteriverkningsgrad fungerar bra nu:

Hittade intressant data om nominal float-laddström för AGM-blybatterier hos Float Current Monitoring: a complete overview "Remote monitoring expertise for over four decades", samt även en lista med "Float Current behaviors to monitor"!
A good rule of thumb for VRLA is 10mA of float current for each 100Ah capacity (float at 13,5V). Vid 13,8V och +25°C gäller enligt dem:
Nominal AGM Float-current = 1.6mA/Ah ±33%, så 160±53mA/100Ah.
Eftersom AGM-blykol har något lägre laddspänning så gäller det nog för lite lägre float-spänning hos dem.

Även hittat en Ultra-High Precision Coulometry för cyklisk mätning / utvärdering av battericeller. What Coulombic Efficiency (CE) measurements mean and how they can be used to quantify cell performance.
Exploring Coulombic Inefficiency Per Hour (CIE/HR): "There´s no denying the usefulness and importance of Coulombic Efficiency. However, when comparing cells cycled under different conditions, to have a direct comparison, there´s a few things that must be considered since cell degradation depends on both time and cycle number. Things like reactions of electrolyte components will occur even if a cell is sitting on a shelf not being cycled.
The time dependence of reactions within a lithium-ion cell are challenging for meaningful comparisons of CE – which measures these reactions – where cycles take a different amount of time to complete; cells with cycles that take more time will experience more reactions per cycles. In this way, CE is understood to be a function of both cycle number and time."

Ger mig en tanke att jag kanske skulle addera till en antagen (uppmätt?) självurladdning för en bättre långtidsstabilitet i mätningen av SOC/Ah-laddnivå i batteribanken? Men utvärderar först från lite testdrift i mitt riktiga off-grid solcellssystem. Jag har inte någon data på blybatteriers cykliska drift från en ultra-precis batterimonitor och ej hittat någon sådan data på Internet.
Eller fångas det upp rimligt bra av mätningen av batteriverkningsgraden?
Båda dessa ger en kvittens på att jag är rätt på det med tankar kring att utvärdera olika dynamiska driftsparametrar för att få en indikation på när något blybatteri i batteribanken börjar få problem i sin batterikemi!

Två intressanta rapporter som ger lite mer kunskapsinsikt kring blybattericykling i off-grid solcellssystem, samt kring hur valet av blybatteriverkningsgrad i batterimonitorn är beroende av ens egen battericykling i ett solcellssystem för att få en noggrann visning i batterimonitorn.
Dels: "Superkondensatorer kombinerat med blybatterier" (vilket man även har integrerat i blykol-batterikemin) som även har en del resonemang kring batteriverkningsgrad och Peukerts effekt.
Dels den jag läste redan för något år sedan och som även refereras till i rapporten ovan, där Trojan djupurladdnings flooded kvalitetsblybatterier cyklas med strömbelastningar aktuella i off-grid solcellssystem (C/30): "A Study of Lead-Acid Battery Efficiency Near Top-of-Charge and the Impact on PV System Design"

Det verkar vanligt att man anger 85% blybatteriverkningsgrad i en batterimonitor men för den typiska cyklingen i ett sunt dimensionerat off-grid solcellssystem blir det ofta signifikant fel enligt dessa rapporter!
"Notice also that the overall efficiency shows high values, with full charge represented by approximately 85% efficiency, a commonly used value for battery charge efficiency. More importantly, notice the dramatically lower efficiencies for the increments above about 80% state of charge, where most values are below 60% efficiency, and full charge is represented by less than 50% efficiency."
Så har man då den typiska grunda blybattericyklingen det blir i ett sunt dimensionerat off-grid solcellssystem så är 85% verkningsgrad på tok för högt för batterimonitorn, som med den då ger felvisning.
Nu tror jag att AGM-blybatterier är något lite bättre än öppna flooded blysyrabatterier på detta, men har inte sett några fakta på det.

Verkningsgraden hos ett blysyrabatteri varierar väldigt mycket beroende på omständigheterna.
Tre viktiga variabler är urladdningsdjup (DoD), temperatur och strömbelastning, men även typ av laddning har stor inverkan samt även åldrande.

Enligt rapporten ger en grund cykling på 3-4% DOD en blybatteriverkningsgrad (Ah) på 45-50% bara! När jag nu cyklat mitt gamla blykol-startbatteri i mitt lilla experiment solcellssystem med 3-4% DOD har min batterimonitor mätt upp en batteriverkningsgrad (Ah) på 70-73%! Dvs ca 1,55ggr / 55% bättre batteriverkningsgrad!
Sannolikt är det från kombinationen strömpulsad laddning via PWM-regulator (som är förstärkt av mig) samt att det är blykol-batteri. Men jag tror att det är den strömpulsade laddningen som bidrar mest till den bra blybatteriverkningsgraden!
Vid sådan grund blybattericykling ger strömpulsad laddning markant bättre batteriverkningsgrad, så det enligt mina erfarenheter i stort uppväger att PWM-regulatorn inte kan utnyttja de extra 15-25% ström som en MPPT-regulator får ut från solpanelerna under bulk-laddfasen då den typiska battericyklingen sker inom 70-100% SOC i ett off-grid solcellssystem.

Min batterimonitor jag utvecklar som ett hobbyprojekt utvärderar löpande batteriverkningsgraden vid den aktuella cyklingen man har i sitt batterisystem, så inverkan av olika urladdningsdjup (DoD), temperatur och strömbelastning samt även laddsätt kommer med från den verkliga driften. På så sätt räknar jag med att löpande kunna få riktigt bra precision i den, samt jag slipper en besvärlig inställning.
De delar av Peukerts effekt som eventuellt påverkar lite även vid cyklisk drift kommer då till stor del med som del av den utvärderade batteriverkningsgraden, så även den slipper jag ha som ett inställningsvärde.
Sedan varierar blybatteriverkningsgraden med hur djupt batteribanken cyklas, så är den utvärderad för rätt grund cykling i bra väder så kommer den inte stämma fullt ut för de mer sällsynta djupa urladdningarna i längre dåligt väder. Men bör ändå bli hyfsat bra, speciellt med tanke på att batteriverkningsgraden blir något högre vid djupare urladdningscykel så man kommer då att ha något större marginaler än batterimonitorn visar. Så utvärdering av blybatteriverkningsgraden vid grundare cykling kommer aldrig leda till någon kritisk överraskning för driften vid en mer sällsynt djupare urladdning i längre dåligt väder!
I princip skulle man kunna utvärdera den biten också efterhand som ens blybatteribank cyklas olika djupt, men just nu känner jag mig tveksam till om det är värt att komplicera programkoden med det samt att lägga energi på hur det skulle hanteras.

En av marknadens mer avancerade och välutvecklade BMS för LiFePO4 TAO Performance BMS visar också sin driftsdata i en local dashboard via WiFi och webbläsare, precis som jag gör via webbservern i denna batterimonitorn!
Batterimonitorn använder två metoder för att synkronisera 100% SOC fulladdat till verkligt fulladdad blybatteribank, dels via tail-current under aktiv float-reglering, dels en annan speciell utvecklad mätmetod bara utifrån sina egna mätdata som blir lite som en reservmetod.
Denna reservmetod är nu testad en tid och fungerar riktigt bra! Ska optimera den lite ytterligare för att bli mer oberoende av batteribankens kapacitet (Ah) samt av hur aktuell drift är. Ger en hög precision i synkningen samt kräver inga inställningar för aktuell installation!
Tail-current metoden behövs fortfarande för att få en mer likartad utvärdering av batteriverkningsgrad, då det är blybatterierna som direkt själva talar om när de precis är 100% SOC fulladdade.

Kämpar vidare med att uppnå full 24/7/365 driftsstabilitet!
Har haft fortsatt glesa kodkrascher när jag bläddrar runt aktivt mellan de olika webbsidorna med driftsdata från ESP32, där kodbiblioteket ESP32 ESPAsyncWebServer-esphome kraschar i sin programkod. Men i nattdrift med bara min egen kod i drift är det fullt stabilt!
Känns surt/motigt att det är välrenomerade kodbibliotek jag använder som skapar problem för stabil kodfunktion och inte mitt egna kodande. Interaktionen med kodbiblioteket är väldigt tydligt och rättfram, så känner mig säker på att jag inte gör fel där!
Har ökat CONFIG_ASYNC_TCP_QUEUE_SIZE från 512 till 1024 (från original 32) i AsyncTCP.h, men osäker på om det behövdes. Men har det så en tid nu som test. Gör det i xQueueCreate(1024, sizeof(lwip_event_packet_t *)) i AsyncTCP.ccp.
Har gjort en rutin som aktiverar events.close() på alla de olika instanserna där events.count() == 0 för att säkert stänga ned all SSE-kommunikation som inte är aktiv längre och behövs!
if (eventsStat.count() == 0U)
{
  eventsStat.close();
}
Det verkar göra nytta att rensa upp så! Har inte sett någon kodkrasch sedan dess relaterat till bläddrande bland ESP32-webbsidorna i webbläsaren på datorn! Men hittar inget skrivet alls om detta utan hittade close() när jag studerade alla funktioner som gick att applicera på en events från dess kodbibliotek. Har hört att vid vanlig webbsideskodning med SSE för Internet är det ett problem som uppstår ibland att inte all gammal oanvänd SSE-kommunikation rensas ut så och tillslut leder till kodkrasch då SSE blir överbelastat, att SSE anslutningarna aldrig stängs även när de borde ha stängts.
Events.close() leder till filen AsyncEventSource.cpp och inom webbutveckling finns EventSource close() method: The close() method of the EventSource interface closes the SSE connection, if one is made. Så känns som close() stänger en kvarlämnad SSE-anslutning.
Samt har optimerat free stack space för mina olika FreeRTOS Task så de har lite drygt 2000 bytes free stack under drift. Kör med god marginal nu under utvecklingen men tanken är att gå ned till ca 1000 bytes free stack space senare och slutgiltigt 500 bytes:
Task minimum free stack space (bytes):

1.TaskSetupESP32:	(2628)
2.TaskDisplayViewHandler:	2032
3.TaskLCDbuttonsHandler:	2052
4.TaskWebServerESP32:	2080
5.TaskDeferredInterruptINA226:	2040
6.TaskStateMachine:	2072

Samt har även ändrat Task_DeferredInterruptIN226´s xQueueReceive() xTicksToWait från 1500 till 5000ms så den inte aktiveras för en mindre fördröjning av interrupt från INA226 pga eventuell krock med interrupt mot ESPAsyncWebServer. Har haft någon väldigt sällsynt kodkrasch som verkar vara kopplad till Task_DeferredInterruptIN226, typ 1ggr/10dygn när ESP32 webbsida visas med aktiv SSE.
Har även ändrat i TaskWebServerESP32 så att SSE-events bara max får utnyttja 450ms av 1100ms cykeltiden, mot tidigare 750ms. Ger mer ostörd tid för ESPAsyncWebServer, om det kanske är lite av problemet!
Känns dock som ett misstag att jag fortsatte med SSE (Server Side Events) för dataskickandet till webbsidorna så länge för första fälttestet i husvagnen, istället för att byta till WebSockets som jag senare fått uppfattningen är stabilare i sin funktion.
Behöver WebSockets dubbelriktade kommunikation för en webbsida med inställningar samt WebSocket kan skicka binär data.
Så når jag inte full stabiltet med dessa kodrefaktorings så får jag bita i det sura äpplet och byta till WebSockets nu, vilket jag annars gör senare efter lite test och utvärdering!
Är mer hype kring WebSocket så verkar vara mer välutvecklat därför, som bl.a. beskrivs i ESPAsyncWebServer manualen:
Limiting the number of web socket clients:
Browsers sometimes do not correctly close the websocket connection, even when the close() function is called in javascript. This will eventually exhaust the web server´s resources and will cause the server to crash. Periodically calling the cleanClients() function from the main loop() function limits the number of clients by closing the oldest client when the maximum number of clients has been exceeded. This can called be every cycle, however, if you wish to use less power, then calling as infrequently as once per second is sufficient.
void loop(){
  ws.cleanupClients();
} cleanupClients() finns inte för SSE där!

Så långt är det stabilt nu med förändringarna beskrivna ovan.
Fångade en komplett battericykling ned till 95% SOC och fick verkningsgrad utvärderad.
Blev hela 81,2% coulomb-verkningsgrad för så grund urladdning, så blykol-batteri ihop med strömpulsad laddning är helt klart en bra kombination. Ytterligare en urladdning till 97,3% SOC gav 73,4% coulomb-verkningsgrad. Jag har fortfarande en hårdvarumässig överhörning vid mätning av låga effekter, så energi-verkningsgraden blir inte rätt ännu.
Men har inte heller försökt att lösa det problemet ännu. Tror det är rätt enkelt.
Övriga data där blir mer intressant med lite fler cyklingar på rad utan kodkrasch!

Hade återigen en syllsynt kodkrasch (typ <1ggr/vecka) när jag aktivt snabbt bläddrade runt bland webbsidorna från ESP32-webbservern, precis när en ny webbsida skulle visas. Nu efter 6 dygns OK funktion med mycket stresstestande. Finns inget bra sätt att felsöka så sällsynta händelser för mig. Men lite logiskt tänkande ledde till att kanske SSE anslutningen inte stängs korrekt när webbsidan stängs och avslutas, så ESP32-webbservern blir överbelastad av det (att kanske försöka skicka både SSE och ny webbsida samtidigt).
Så provat att lagt in sådan funktion nu i min webbsideskod som avslutar SSE innan webbsidan stängs. Kunde se i "Verktyg för webbutvecklare - Nätverk" i webbläsaren att utan den kodfunktionen kommer det ett Error-meddelande för förra visade webbsidans SSE-events vid sidväxling men nu med detta inlagt så försvinner det Error-meddelandet! Så känns helt rätt och kan nog faktiskt vara en orsak. Men inget jag sett något tips om eller beskrivning av - är så mycket jag själv måste lista ut kring att få SSE att fungera stabilt med webbsidorna och ESP32-webbservern!
Ser även en lite ytterligare distinkt funktion i aktiveringen av SSE på nya visade webbsidan, vilket även skett lite efter de övriga senaste förändringarna. Så en liten indirekt indikation på att kodförbättringen kanske gör nytta.
window.addEventListener("pagehide", (event) => {
  eventsource.close();
},false);
document.addEventListener("visibilitychange", (event) => {
  if (document.visibilityState === "hidden") {
    eventsource.close();
  }
},false);
Page Lifecycle API
Förhoppningsvis är det så stabilt nu att jag med denna koden kan starta fältprov i mitt riktiga off-grid solcellssystem bara jag byggt prototyp 2 färdig. Sedan är det att skicka driftsdata till webbsida på webbhotell samt att börja testa WebSocket som står på tur. Men ska först då vara off-grid aktivt lite och uppleva ESP32-batterimonitorns funktion i skarp drift.
Jag tror starkt på att ersätta SSE (Server Side Events) med WebSocket för mindre problem och mer prestanda i datautbytet mellan webbservern och webbsidan, men återstår att testa!

Att utvärdera att batterimonitorn mäter rätt strömvärde för ren kontinuerlig jämn DC likström är inte svårt, men vid olika pulsad ström blir det svårare! De mätinstrument jag har mäter TRMS och batterimontorn mäter medelvärde, vilka skiljer sig åt för olika kurvformer. Blir extra tydligt vid låga PWM-pulskvoter från PWM-regulatorn! Ska senare se om mitt digtala oscilloskop kan hjälpa mig där vid en mer slutlig utvärdering.
Men under några timmars mätning vid olika strömpulsande ser batterimonitorn ut att hålla en bra precision i strömmätningarna!
Även effektmätningen har blivit betydligt bättre efter en smärre förändring hårdvarumässigt och räknar med en signifikant förbättring när jag gör om hårdvaru-layouten så överhörning från strömpulsandet minimeras.
Nu när programkoden verkar fungera stabilt och bra fokuserar jag lite på att verifiera och förbättra hårdvaran när jag bygger protyp två nu!
Mer kunskap:
- How to derive the RMS value of pulse and square waveforms
- Digital Multimeters- Basic Guide, Fluke
- Electronic Test Instruments: Measurement Theory

Nu kört drift stabilt drygt 7dygn och gjort en massa stresstestande med en mängd aktiveringar av WiFi / Webbserver samt bläddrande mellan alla ESP32-webbsidorna! Har inte gått förut!
Så känns riktigt lovande för stabil 24/7/365-drift. Ser även att belastningen av SRAM-minnet är ytterligare stabilare nu under dessa 7+ dygn med 127096 bytes som lägsta ledigt samt i snitt ca 51% ledigt med visad aktiv webbsida!
Har haft problem med funktionen från det välrenommerade ESPAsyncWebServer-esphome biblioteket. Har dels fått hacka det lite, dels fått lista ut en del ej dokumenterade funktioner som krävs, samt fått koda en övervakning och reglering av webbserverns SSE-drift så den inte överbelastas i SSE-kommunikationen till webbsidorna som visar driftsdata.
Verkar som den senaste justeringen nu i webbsideskoden som stänger SSE precis innan webbsidan avslutas var det sista som behövdes för att kunna växla stabilt mellan webbsidorna!

Fick färdigt den 2:a prototypen av ESP32-batterimonitorn idag som fungerade direkt. Testkört den en del men inte inkopplad i solcellssystem ännu. Är mer noga byggd samt med en bättre hårdvarulayout som bör förhindra överhörning från strömpulsande!
Ska göra en del mer laboratoriemässiga mätningar och analyser på ström- och effekt-mätningen på den först nu.
Sedan provköra i mitt lilla experiment solcellssystem och därefter installera i mitt riktiga off-grid solcellssystem.

För att ytterligare minimera risken för problem mellan ESPAsyncWebServer-esphome biblioteket och min programkod har jag omslutit hela min ISR-funktions kod för INA226´s interrupt med en kritisk sektion portENTER_CRITICAL_ISR(&Mux) / portEXIT_CRITICAL_ISR(&Mux), vilken ger att "inside the critical section interrupts are disabled" källa1, källa2, källa3, källa4, atomic instruction.
Key of a critical section is that it´s not preempted. One will not get a context switch in a critical section with interrupts disabled! Vilket känns viktigt för denna ISR_INA226Batt()!
Critical sections are used as a valid protection method against simultaneous access in FreeRTOS - Critical Sections & Disabling Interrupts.
ESPAsyncWebServer-esphome lär ha interrupts för sin funktion så bör undvika störning av annat samtidigt interrupt på detta sätt, vilket jag sett extremt glesa händelser jag tolkar skulle kunna vara en interrupt "context switch" när min ISR-funktion ISR_INA226Batt() exekverar.
Men då detta har hänt typ 1ggr/2veckor tar det tid att verifiera en förbättring!
Samt det händer bara när ESPAsyncWebServern aktiveras och visar webbsidor.
Kan i vart fall inte se någon negativ effekt av portENTER_CRITICAL_ISR(&Mux) / portEXIT_CRITICAL_ISR(&Mux) i ISR för min kod-funktion!
Läs mer om Deferred interrupt context switch på webbsidan om Arduino ESP32 C/C++ kodning.
Är mycket med kodinteraktionen med RTOS att förstå sig på riktigt djupt och få känsla för!
Men samtidigt intressant och spännande att utforska.

Gör nu en del mer laboratoriemässiga mätningar och analyser på ström- och effekt-mätningen på min 2:a prototyp. Ser att jag behöver justera hur jag kopplat hårdvaran då det finns lite mätavvikelse vid riktigt låga strömmar. Egentligen borde jag ha strömshunten på high-side (batteri-plus) men min nuvarande batterimonitor i off-grid solcellssystemet har den på low-side (batteri-minus), vilket är det vanliga hos batterimonitorer. Vill helst slippa en ombyggnad i elsystemet så försöker lite till med low-side! INA226 är annars mest anpassade för high-side vid dubbelriktad strömmätning.
Men mäter och provar lite olika små justeringar och lär mig INA226 i mer detalj ett tag. Får jag det tillräckligt bra nu med low-side så monterar jag in den i skarp drift i mitt off-grid solcellssystem, så fortsätter jag att optimera med protyp 1 här hemma i experiment solcellssystemet.

En liten enkel justering i hårdvarans INA226 inkoppling fixade helt mätavvikelsen vid låga strömmar och mäter nu 100% korrekt, med strömshunten ansluten low-side (batteri minus).
Är intressant att se att medan strömvisningen på labora­torie­nät­aggre­gatet fladdrar mellan 11mA till 24mA så visar ESP32 stabilt -13mA medelström mätt över 2,2s vid nattdrift. Är växlingarna mellan ESP32 light-sleep och kort full drift för avläsning av INA226-sensorn samt en blinkande LED som ger variationerna i strömförbrukning men som ligger absolut stilla som medelvärde!
Ger en väldigt behaglig stabil och precis strömvisning, samt strömvärde för beräkningar!
Har även validerat labora­torie­nät­aggre­gatets strömvisning med en bra multimeter.

Köpt nytt blybatteri till mitt lilla experiment off-grid solcellssystem hemma i Lägenheten. Ska ersätta mitt gamla utrangerade 44Ah blykol-startbatteri från 2016-01-23, som inte är AGM och jag inte kan kolla syranivån i (så det inte händer en olycka med det). Det beter sig annars spännings-, ström-, laddnings- och verkningsgrads-mässigt väldigt fräscht vid mina grunda cyklingar (≥95% SoC) med värden som i stort hos ett nytt batteri. Strömpulsladdning rocks!
Det nya 12V UPLUS 90Ah Lead-Carbon (Bly-Kol) är ett "true deep cycle AGM technology" som ger ett bra kvalitetsintryck. "UPLUS Bly-Carbon batterier är utvecklade för elfordon och för att användas som ett förbrukningsbatteri i mobila och marina applikationer. Batterierna fungerar dock även bra som ett stand-by batteri." Så ska fungera väldigt bra med min drift här med mest väldigt grunda cyklingar från laddning av mobilen, nästan som standby-drift. Och samtidigt kunna fungera lite som reservkraft vid eventuellt strömavbrott.
Detta UPLUS 90Ah Lead-Carbon höll 12,60V vid leverans, vilket känns helt OK (≈90% SoC).

• True deep cycle AGM technology-GREEN SOLUTION
• Over 99.99% virgin lead for grid plate and active material
• Heavy duty grid/paste design for deep cycle application
• Maintenance free, non-spillable, valve-regulated
• Double separator configuration: long cycle life &
  High energy density and super anti-vibration design
• Low self-discharge for longer shelf life

SellPower Nordic AB som är generalagent för dessa i Sverige ger ett bra, seriöst kunnigt intryck och verkar noga med att bara ha kvalitetsprodukter i sitt sortiment, flera med en grön profil!
Har nu även fått ett par feedback av folk som jobbat med dem eller haft affärer ihop som säger att SellPower är väldigt seriösa och duktiga, vilket bekräftar min analys av SellPower!
Blir även bra att min fortsatta utveckling sker mot ett AGM-blykol batteri för djupurladdning till solcellssystem, så jag har rätt förutsättningar. Utökar även till dubbla solcellseffekten.

Kopplat in prototyp II på mitt lilla experimentella off-grid solcellssystem i lägenheten och det fungerar fint! Förändringarna i hårdvarans layout för INA226 blev bra.
Känner av när PWM-regulatorn är i aktiv reglermode och PWM-strömpulsar s.k PV Throttle, precis som tänkt. Och i kombination med Tail-current <0,005C (0,5%) så synkar den 100% SoC mot fulladdat batteri bara så fint och exakt. Kan därmed få riktigt bra precision i uppmätning av batteri­verknings­grad och därmed även SoC / Ah-laddnivå! Vid aktiv strömbegränsande reglering ihop med 0,5% Tail-current så talar batteriet själv om när det är fulladdat.
Har därmed fått min PWM-solladdregulator och denna ESP32 batterimonitor att kommunicera med varandra, vilket behövs för riktigt bra funktion hos batterimonitorn.
PV Throttle dektekteringen fungerar från riktigt hög pulskvot, så fångar verkligen direkt PWM-strömpulsandet börjar. Så osäkerheten kring det är helt skingrad nu.
Har gjort lite speciell kodning kring detta som kvalitetssäkrar detekteringen av PV Throttling och 100% SoC fulladdad blybatteribank via Tail-current.
Men är 0,5% Tail-current ett säkert fast värde att gå på som alltid kan nås i ett blybatteri? I mitt nuvarande gamla utrangerade 44Ah blykol-startbatteri från 2016-01-23 här hemma når jag ända ned till åtminstone 0,25% Tail-current, så ger 2ggr säkerhet i detekteringen av 0,5% Tail-current!
Sedan kommer jag bygga in en övervakning av detta, så om den lägsta mätta Tail-current vid PV Throttle börjar närma sig eller överstiger 0,5% så kommer en kodfunktion justera upp den automatiskt för att säkra funktionen. En sorts inbyggd automatisk kvalitetssäkrande funktion.

Varit flera dygn utan att blivit fulladdat, men så idag blev blybatteriet 100% SoC fulladdat.
Kombinationen PV Throttle = ON och Tail-current <0,005C (0,5%) plus lite kvalitetssäkrande logik ger en riktig fin precision i avkänning av 100% SoC batteriladdnivå! Idag var det växlande soligt med moln så en svår instabil situation att detektera 100% SoC men batterimonitorn gjorde det väldigt stabilt med riktigt bra precision! Är imponerande utan att ha trimmat funktionen!
Så ett första bra steg i valideringen av den funktionen, som är så grundläggande!
Tyvärr blockerar jag utvärderingen av batteriverkningsgrad vid första 100% SoC synkningen, men såg ut att ha blivit väldigt hög verkningsgrad annars. Så är nästa spännande att se.

Kodat 5st till LCD displayvyer, för SoC-data, TimeToGo 1hr/24hr, 24hr ΔCHARGE (Ah/Wh), Batteriverkningsgrad samt Cycled Discharge. Har nu totalt 21st LCD-displayvyer att bländra runt som en cirkel mellan, både som visar driftsdata och menyer för inställningar.
Kan nu även se den mesta driftsdatan via LCD-displayen av det som visas på webbsidorna.

Med prototyp II som mäter rätt även för små strömmar samt synkar 100% SoC till fulladdat batteri med hög precision utvärderades en Coulomb(Ah) verkningsgrad på hela 92% för 44Ah bly­kol­start­batteriet från 2016-01-23 strömpuls­laddat med låg ström <1A/44Ah=<0,023C. Är för 1st laddcykel över två dygn med -1,7Ah/44Ah urladdning.
Är sannolikt pga kombinationen blykol-batteri, ström­puls­ladd­ning och låg laddström, men ändå väldigt imponerande för det gamla blybatteriet! Intressant att kunna mäta nu!
Samt mätte en Energi(Wh) verkningsgrad på 87%.
Behövs dock mätningar över flera batteri­cyklingar innan man kan känna sig mer säker på dessa värden, men just nu prioriterar jag den sista justeringen i koden inför att installera i mitt riktiga off-grid sol­cells­system! Var dock skoj att se för en batteri­cykling såhär.

Har gjort lite kodrefaktoring, optimerat några kodfunktioner samt verifierat programkoden lite mer så den nu bör vara redo för skarpt fältprov i mitt riktiga off-grid solcellssytem! Några små verifieringar ytterligare av hårdvaran också bara samt uppdatering till samma hårdvarulayout i prototyp I som stannar här hemma i experiment off-grid solcellssystemet.
Är lättast att göra det när jag har de två prototyperna anslutna parallellt här hemma så jag kan jämföra mellan dem. Ska se om jag kan förenkla det filter jag har som gör att jag mäter strömmen för kraftigt snabbt strömpulsande rätt. Tror det men ändå lite osäker.
Har ju hittills mest lagt tiden på programkodningen, då det varit huvudutmaningen.

Är jäkla spännande att få mätt batteriverkningsgraden för sitt blykolbatteri via batterimonitorn för varje battericykel (dock gammalt blykol­start­batteri från 2016-01-23 här hemma just nu)!
Både Coulomb(Ah) och Energy(Wh) verkningsgrad.

Förra battericykeln gav 92,0% Coulomb(Ah)-verkningsgrad cyklad -1,7Ah av 44Ah, till bara 97,7% SoC.
Då skedda återladdningen i bra solsken mot slutet av tiden under de två dygnen.
Återladdat med låg solcellsström <1A / 44Ah = <0,023C och mot slutet när regulatorn begränsar strömmen PWM-strömpuls­laddat.
Återladdningen vid så grund cykling sker i enbart float-laddning med min PWM-regulator.

Batteriet själv talar då om när det är fulladdat vid aktiv float-strömreglering och Tail-current <0,005C (0,5%). Samt ihop med lite kvalitetssäkrande kod så den detekteringen blir robust och stabil även i växlande solsken.
Har sett nu att detta ser ut att ske med riktigt bra repeterbar precision!
Så även batterimonitorns 100% SoC blir väldigt exakt synkad till full blybatteribank.
Här kan man se att Tail-current kommit ned ända på +0,123A vid aktiv PWM-reglering, mot 0,220A som är 0,005C / 0,5% för 44Ah batteriet.

Senaste battericykeln klar nu seneftermiddag återladdad stor del av tiden med riktigt låg ström i varierande väder med mycket molnigt slutade med 98,4% Coulomb(Ah)-verkningsgrad cyklad -1,3Ah av 44Ah, till bara 97,2% SoC.
Jag cyklar här normalt bara med laddning av min mobil.

Vid så grunda cyklingar brukar traditionella blybatterier ha urusel verkningsgrad under 50%!
Att jag får så hög här bör vara kombinationen väldigt låg laddström, PWM-strömpulsladdning och blykol-batteri.
(Samt det kräver egentligen verifiering från lite fler laddcykler för säkra siffror, och blir bättre uppmätt med urladdning <90% SoC.)

Planen är att ha denna batterimonitor inmonterad i mitt off-grid solcellssystem med Victron lead-carbon batterier senast under nästa vecka. Och där kommer då batteriverkningsgrad bara utvärderas för battericykler som går under 90% SoC!
Ska bli väldigt intressant att få mätt Victron lead-carbon´s batteriverkningsgrad under min normala aktiva drift där!
Tyvärr har jag varit rätt sjuk senaste månaderna så är en viss osäkerhet kring det om tidplanen håller.
Men programkoden (firmware) för detta är i alla fall äntligen färdig, debuggad och testad nu.

Senaste laddcykel över ett dygn gav 100% Ah-batteriverkningsgrad (!) för -1,6Ah/44Ah cyklad urladdning och 96,5% SoC. Så antingen någon liten felmätning av pulsad ström eller möjligen att det skett lite ytterligare desulfatering, för 100% verkningrad har det absolut inte. Är extremt känsligt när man mäter såhär väldigt grunda urladdningar, så blir intressantare sedan för drift i mitt riktiga off-grid solcellssystem.
Lägsta Tail-current sjönk något ytterligare ned till omkring 105mA (≈0,0024C), vilket tyder på lite ytterligare gjord desulfatering i batteriet av strömpulsandet.
Är svårt att verifiera att batterimonitorn mäter pulsad ström med tillräckligt bra noggrannhet vid PWM-strömpulsad laddning! Ska se om jag kan verifiera det bättre med mitt digitala oscilloskop som jag tror kan mäta medelspänningen över strömshunten för pulsande ström.
För båda de senaste dygnens kompletta små laddcyklar har medelströmmen under 24h varit +8mA/+9mA, så en väldigt liten mängd "bortslösad" ström som förlust i blykolbatteriet!
Visar att blybatterier kan arbeta betydligt mer effektivt än de allmänt beskrivs som. Innebär sannolikt i stort noll gasning och bara lite ström till desulfatering, cellbalansering och förluster.
Strömpulsladdning ger extremt låg gasning som en av flera fördelar!
Har inget noterbart minnesläckage (memory leak) under 2-3 veckors drift:
ESP.getMinFreeHeap(): 132004 bytes (lägsta sedan start)
ESP.getMaxAllocHeap(): 110580 bytes (största fritt minnesblock)
ESP.getFreeHeap() / ESP.getHeapSize(): 50-51% Wifi+Webserver ON, 74% Wifi+Webserver OFF

Kodat en adaptiv funktion som hanterar Tail-current gränsvärdet (0,005C / 0,5%) så det vid behov justeras upp automatisk efter blybatteriernas funktion så en robust stabil synkronisering av 100% SoC till fulladdat blybatteri alltid kan göras utifrån Tail-current.
Sedan finns det en reservmetod som också synkroniserar 100% SoC med bra precision, men inte tidsmässigt lika exakt för bra beräkning av batteriverkningsgrad.

Mätt upp strömförbrukningen för Mobil 4G Router Teltonika RUT241 vid uppkopplad drift, som då drar ≈90mA i snitt från 12,5V. Motsvarar i 24/7-drift ca 2Ah/dygn, vilket känns överkomligt.
Optimerade / förenklade även filtret för strömsignalen för korrekt mätning av pulsad ström. Då jag hade både version I & II inkopplade samtidigt kunde jag jämföra och med modifieringen blev mätningen något lugnare men gav ändå i stort samma strömvärden. Jag bedömmer att det blev något bättre noggrannhet för små strömvärden under ca 150mA för 60A/60mV strömshunten.
Ska senare försöka göra än mer noga utvärdering via digitalt oscilloskop som kan mäta medelvärdet för kontinuerligt pulsande. Men vill komma i provdrift nu i fält!

Installerat protype II i mitt off-grid solcellssystem i husvagnen för riktig fälttest.
Fungerar väldigt bra och ger en riktigt fin driftsöversikt över AGM-blykol batterierna. Vistades där i två dygn och kunde verifiera att de två olika Time-To-Go prognoserna (från 1hr / 24hr statistik) är riktigt bra och fungerar som tänkt med 12V kylskåpskompressorns intermittenta drift med ca 25% av tiden aktivt igång! Fick fint stabila drifttidsprognoser, både för 24hr dygnsdriftens längre tid och aktuell korttids laddningsprognos baserat på senaste 1hr strömstatistik.
De kompletterar varandra väldigt fint!
Även batterimonitorns 100% SoC synkning till helt fulladdat batteri fungerar med väldigt bra repeterbar precision, så riktigt imponerande! Även vid snabbt växlande soligt / molnigt väder!
Visar nu även i PV Battery Dashboard om PV Throttle är ON/OFF (om aktiv strömbegränsad reglering i solladdregulatorn), via grön färgmarkering (ON) av cirkeldiagrammets centrum där:

Vid passiv standby-drift i mitt lilla experiment off-grid solcellssystem här hemma med gammalt 44Ah blykolstartbatteri (än så länge) så blir dygnsladdningen för helt fulladdat blybatteri ca +0,140Ah/24h, ca +6mA i medelström. Är baserat på senaste uppmätt 24h medelström.
Är imponerande lite strömförbrukning, speciellt med tanke på att en Battery Reconditioner (9kHz, >50A) hela tiden ligger och pulsar ström in i blybatteriet och laddar upp sig med ström från blybatteriet. Kan finnas ett mindre mätfel för strömmen när PWM-regulatorn strömpulsar, vilket jag ska mäta upp och analysera mer noga senare och så ifall justera filtret för.

Stämt av att tidmätningen via esp_timer_get_time() 64bit tid internt i ESP32 inte bidrar med en signifikant onoggrannhet till Ah-summeringen från de samplade strömvärdena pga av avvikande CPU-klockfrekvens. Och fick som svar att Industristandard för klockkristallerna är ±20ppm, men idag är kristaller så bra att det är sannolikt inom ±10ppm. Så det är betydligt högre precision än jag får i strömmätningen, så bidrar inte till någon onoggrannhet i Ah-summeringen!
Fick även följdfrågan: "Frågan är väl också hur klockan propagerar internt i processorn? (Både mellan olika delar av hårdvaran men också exekveringstiden för olika instruktioner.)"
Som jag svarade på: Jo det är också en intressant frågeställning.
Men via esp_timer_get_time() får jag tid med µs upplösning, och tar tidsstämplingen via interrupt när INA226-sensorn signalerar att nya mätvärden finns att hämta.
Så tidsstämplingen och mätvärdena får en bra noggrannhet mot varandra.
Sedan skickas de vidare till en Deferred interrupt processing funktion som getts hög prioritet i FreeRTOS, så den exekveringen blir som en direkt förlängning på ISR-funktionen som interruptet triggar. Där hämtar jag strömmätvärdena från en buffert de är lagrade i hos INA226-sensorn, så de påverkas inte av att det tar någon lite tid.
Med µs upplösning har jag goda marginaler för tillräckligt hög tidsprecision samt allt övrigt är kodat så jag inte förstör den precisionen.
Som jag förstått det så tickar inte tiden på från esp_timer_get_time() inne i ISR-funktionen, så jag får verkligen tidsstämplingen för exakt när interruptet triggades.
Har även via 200MHz digitalt minnes-oscilloskop checkat av att interruptet med ISR sker tillräckligt snabbt.
Så jag tror jag har tillräcklig koll på den biten.
Men helt klart en viktig frågeställning också i detta sammanhanget!

Var och tittade till installationen i off-grid solcellssystemet samt uppdaterade hårdvaran lite enligt det senaste här hemma. Ska ge lite mer exakt mätning av strömpulsandet från PWM-regulatorn vid spänningsreglerad laddning mot blybatteribanken.
De dryga två dygnen jag bodde där nyss när jag installerade ESP32-batterimonitorn där gav lite intressanta första mätvärden och driftsstatistik nu när batteribanken hunnit bli fulladdad igen:
- Senaste lägsta SoC: 75,7% (motsvara ca -51,5Ah)
- Senaste cyklade urladdning: -81,1Ah
- Batteriverkningsgrad Ah: 94,0%
- Batteriverkningsgrad Wh: 88,2%
- Low Tail current: ca 0,14% / 0,0014C
Under de dryga aktiva två dygnen boende blev batteribanken inte fulladdad, men en hel del laddades tillbaka i det växlande solskenet dagtid. Så därför senast lägsta SoC bara motsvarar -51,5Ah urladdat medans "Senaste cyklad urladdning" blev -81,1Ah då den räknar all cyklad urladdning tills fulladdat igen. Är en intressant siffra tycker jag!
Den mätta Batteriverkningsgraden känns bra för några dygns aktiv drift ihop med några dygn till tills fulladdat i det mulna vädret, men de mätningarna kommer troligen påverkas lite av den justering jag gjorde i hårdvaran idag. Samt tror det skiljer lite vid första aktiva drift såhär efter en längre passiv standby-drift mot vid en lite längre aktiv drift med flera fulladdningar under tiden.
Men för blybatteri är de verkningsgraderna riktigt bra vid denna battericyklingen, så märks den är signifikant bättre hos AGM-blykol batterier!

Har förbättrat mätningarna av PWM-solladdregulatorns 30Hz strömpulsade laddning så ESP32 via INA226 nu samplar spänningen över strömshunten i 3,5kHz just när det är PWM-strömpulsning. Det är max vad INA226 kan prestera! Använder då Conversion time 140µs och Averaging 1024 st mätningar. Så 1024st mätningar medelvärdesbildas i INA226 innan interrupt sätts till ESP32 så den hämtar den datan ur bufferten.
Innebär ca 117 samplingar per 30Hz pulsperiod samt medelvärdet för ca 35st 30Hz pulscykler, ihop med en RC-filter tidskonstant på 0,31ms dvs i storlekordning för 1% Duty-cycle.
Så skulle helst velat upp i 2-5ms RC-tidskonstant!
Samplar då kontinuerligt i ca 3,5kHz och mätt att ESP32 hinner med att hantera detta i helt jämn takt med INA226 med nya data var 292:a ms, även när driftsdata förmedlas via ESP32 webbservern via WiFi till webbsida på datorn.
Gör detta bara då ESP32 detekterar att PWM-solladdregulatorn strömpulsar, annars samplas med ca 450Hz dvs blir 7,8ggr oftare såhär.
Jag tycker det märks skillnad, dels så varierade strömvärdet signifikant mer förut (vilket jag trodde var PWM-regulatorn som var lite orolig i regleringen), dels har jag idag haft ett par gånger när solinstrålning minskat långsamt från fullt solsken så PWM-regulatorn växlat mjukt från strömpulsande till jämn DC-ström ut och det har inte gett något synbart hopp i det mätta strömvärdet vid växlingen.
Så känns som det blev bättre såhär med lite mer noggrann mätning av den strömpulsade laddningen. Känns som ett skoj steg framåt!
Impulsen kommer ifrån när jag frågat mer kunniga inom RC-filter / datafiltrering och sampling om råd på Internet. Jag är lite utanför min kunskapszon här!
Ska senare i höst försöka utvärdera det mer nog i mätning via mitt digitala oscilloskop.

Håller på att i KiCad Spice simulera lite olika filterkonfiguration för strömsignalerna från ström­shunten. För optimering av funktion samt öka kunskapen och insikten kring detta.
Grönt är INA226´s sampling av mätdata ca 3,5kHz, Lila = 1% duty-cycle 30Hz PWM-strömpuls (solladdregulator), Blå = en filterkonfiguration & Röd = en annan filterkonfiguration.
Den röda kurvan sprider ut strömpulsen mjukt över längre tid så den hinner samplas fler gånger för bättre mätprecision. Att den svänger en del gör inget så länge summan (med tecken) av areorna mellan kurvan och 0V X-axeln motsvarar korrekt mätt Ah-summering dvs arean för PWM-strömpulsen, vilket det ser ut att göra. Får ju även medelvärdet för 1024 sådana samplingar som motsvarar ca 35st 30Hz cykler, så svängningen blir helt bortfiltrerad på så sätt.
Skulle vilja ha längre tidskonstant för filtret, men INA226 strömmätingångar får max ha 20-22Ω total filterresistans samt lägsta LSB mätspänning är 2.5µV som gör det svårt ihop!
Men ur detta får jag till lite ytterligare förbättrad mätprecision för strömmen vid aktiv PWM.

Simulerat mer med KiCad Spice och utvärderat 3st olika samplingfrekvenser mot det analoga strömsignalfiltret. Ser att den högre ca 3,5kHz samplingen är bra vid PWM-strömpulsladdning samt att en 2ggr högre samplingfrekvens än jag haft hittills samverkar bättre med filtret för mer exakt strömmätning, så ändrat till det för aktiv batteridrift. Behåller den tidigare långsammare samplingen för energisparläge vid nattdrift. Så simuleringarna har därmed hjälpt mig att både optimera programkoden i batterimonitorn och det analoga strömsignalfiltret för ökad mätprecision för strömmen! Så nu analyserar programkoden den momentana batteridriften och växlar mellan tre olika samplingfrekvenser och driftslägen automatiskt. Ser bara så fint ut!
På så sätt utnyttjar jag även INA226-strömsensorns prestanda och möjligheter optimalt.

Är jäkla intressant med mitt ESP32-baserade "Ultra-precise Battery System Monitor" hobbyprojekt som mäter ström stabilt nere på mA / mAh nivå med bra upplösning!
Så kan väldigt detaljerat följa mitt utrangerade gamla (2016-01-23) startblykolbatteris drift i mitt lilla experiment off-grid solcellssystem här hemma.

Under hela sommaren har lägsta stabil TailCurrent vid fulladdat batteri och aktiv strömbegränsande reglering via PWM-solladdregulatorn sjunkit och är nu nere i ca 110mA dvs 0,25% av de 44Ah i batteriet.
Det bör innebära att PWM-strömpulsladdningen fortsätter att långsamt återbilda gammal sulfatering i blybatteriet, vilket även ström- / spännings-responsen under drift antyder.
Så vid de rätt grunda urladdningar (laddar bara mobilen) så beter sig detta gamla blybatteri som nytt ström- och spännings-mässigt! Laddar väl ur ned till ca 92-93% SoC då och då, mätt mot dess nominella 44Ah C20-kapacitet.
Har inte testat hur det reagerar vid lite djupare urladdning då det är så pass gammalt och inte till för denna typ av drift.
Jag får just nu 100% uppmätt batt­eri­verk­nings­grad vid små urladdningar som jag misstänker beror på små mätfel orsakade av långa signalkablar mellan strömshunt och INA226-sensor i den temporär ex­peri­ment­upp­kopp­ling­en här hemma. Men skulle även delvis kunna bero på att PWM-strömpulsande desulfatera blybatteriet så man via det når TailCurrent lite tidigare.

Jag har byggt ihop en kommunikation mellan min batterimonitor och PWM-solladdregulator, så batterimonitorn får väldigt exakt info om när regulator aktivt PWM-strömpulsar för att begränsa laddströmmen. Indikeras även med grön LED.
Samt använder en TailCurrent < 220mA / 0,5% vid aktiv PWM-pulsreglering som indikering för fulladdat blybatteri, vilket ger väldigt bra precision i 100% SoC synkning till fulladdat blybatteri!
Har därmed en bra marginal mot hur lågt TailCurrent går ned till i aktiv float-laddning som nu de 110mA.
Är 0,5% TailCurrent så vid aktiv strömreglerad float-laddning som indikerar fulladdat blybatteri med bra precision, vilket man inte kan få bara baserat på batterispänning + TailCurrent.

Sägs att lägsta TailCurrent så ökar hos åldrade blybatterier men är inget jag ser här eller heller sett hos min gamla fritidsblybatteribank ens vid 9 års ålder på den. Är kanske pga nyttan PWM-strömpulsladdningen gör?
Men min batterimonitor utvärderar det adaptivt kontinuerligt och anpassar helt automatisk TailCurrent gränsen uppåt för 100% SoC fulladdat blybatteri om det behövs för funktionen.

Har köpt ett nytt AGM-blykol batteri avsett för djupurladdning och solcellsdrift som även klarar av typ längre UPS-standby drift bra med fin livslängd, så bör bli perfekt här hemma.
Så ska snart flytta över mitt hemmasystem till det och får då även som lite mer riktig reservkraft här hemma på 12V 90Ah.
Samt blir lite mer korrekt blybatteridrift för solcellssystemet att utvärdera mot!
Men ser ju även med startblykolbatteriet så intressanta egenskaper blykol ger.

Kom nu vid 17:40-tiden precis ned i ca 90mA / 0,20% TailCurrent vid 5,5% Duty-Cycle PWM-strömpulsande, lägsta hittills :-)
Varit fint soligt hela eftermiddagen.

Har ändrat till ett par svenska officiella NTP-tidsservrar för synkning av ESP32-RTC:
const char* ntpServer1 = "ntp.netnod.se";
const char* ntpServer2 = "ntp.se";
const char* ntpServer3 = "europe.pool.ntp.org";
Kör nu med denna kombinationen av netnod.se, ntp.se och ntp.org vilket fungerar bra!
Känns vettigt att ha från några olika väletablerade tidsserverdomäner!
Enligt rekommendation ska netnod.se vara allra bäst att använda sig av i Sverige.
Netnod har ett samhällsuppdrag i Sverige att gratis leverera exakt tid över internet, finansierat av Post- och telestyrelsen (PTS).
Samt har nu verifierat att växlingen från bulk-laddning till PWM-pulsande 14,50V aborptionsladdning ger exakt samma uppmätta ladd­ström­värde i helt stabilt fullt solsken, där laddningen segade sig väldigt långsamt upp mot de 14,50V med konstant laddström.
Då växlas INA226´s sampling från 1024x2x588µs till 4x1024x2x140µs som då ger samma mätvärden direkt efter växlingen precis som tänkt, för att sedan långsamt sjunka då laddströmmen begränsas för att hålla konstant reglerad 14,50V laddspänningen för batteriets temperatur.
När den efter ett tag reglerar med ca 80% duty-cycle PWM-pulsat håller de uppmätta strömvärdena sig väldigt stabilt, vilket indikerar att 30Hz strömpulsandet mäts med bra precision såhär!
När jag tidigare mätte 30Hz strömpulsande med INA226 samplande 512x2x1,1ms så fick jag någon sorts interferens så uppmätt strömvärde varierade mycket, vilket såg ut som om regulatorn svängde rätt mycket i sin reglering men var då mätfel.
Så är bättre mätprecision nu, precis som KiCad Spice simuleringarna här ovan visade på!

Jag hade väldig nytta av denna 24h driftsstatistik när jag var ute och fricampade inne längs småvägar i Östgötsk skogsnatur under 7 dygn i början av September. Kom då aldrig under 14 dygns kvarvarande driftstid för 24h Time-To-Go prognosen, och låg flera av dagarna på 3-4 veckors kvarvarande driftstid i det hyfsat soliga vädret med bl.a. 12V kom­pressor­kyl­skåp i drift.
Samt kunde fint se mätvärden på senaste 24 timmarnas förändring i Ah / Wh laddnivå i batteribanken (24hr ΔCHARGE) så jag såg tendensen för laddnivåns utveckling, dvs hur många Ah / Wh man gått plus eller minus senaste 24h.
Laddnivån i batteribanken pendlade mellan ca 70% och 93% SoC där mina AGM-blykol batterier hela tiden tog emot full laddström från solpanelerna under hela den turen, dvs en PSoC-drift under de 7 dygnen som AGM-blykol tål så bra (PSoC: Partial State of Charge).
Min Ultra-precise Battery System Monitor ger riktigt bra nytta under sådan off-grid solcellsdrift!

Har kodat om, gjort code refactoring, av koden för SSE (Server-Sent Events) ihop med biblioteket ESPAsyncWebServer-esphome ver.3.1.0. Hade gjort en "smart" kodning där jag slog ihop 2-4st datavärden separerade med "|" till en sträng jag skickade via SSE AsyncEventSource::send() till webbsidan där JavaScript avkodade det.
Men visade sig att avgPacketsWaiting() då visade på mycket köande av data som gjorde överföringen extremt långsam samt att kodbiblioteket fick kodkrascher då och då av detta.
Så nu gjort om så att jag bara skickar ett enda datavärde via varje SSE AsyncEventSource::send() samt bara om det är ett nytt förändrat värde.
Så långt provat ett par dagar har det fungerat stabilt och snabbt i dataöverföringen till webbsidorna, kanske ihop med nya förbättrade version 3.1.0 av ESPAsyncWebServer. Men krävs typ ett par veckors drift innan det går att avgöra mer säkert om detta löst de lite sällsynta kodkrascherna vid visade webbsidor.
Ska ändå prova med WebSockets för nästa webbsida med inställningar för ESP32-batterimonitorn!
Är fortfarande en hel del som pekar på att WebSockets är stabilare i detta kodbiblioteket!
De nya svenska officiella NTP-tidsservrarna jag nu synkar ESP32-RTC mot fungerar också distinktare och snabbare, så bör ge mindre konkurrens om ESP32-WiFi ihop med SSE vilket även det kanske minskar risken för kodkrasch?

Lagt in SSEpulse-indikering på alla webbsidorna så ESP32 vet när någon webbsida visas aktivt i webbläsare. ESP32 kan på så sätt hålla webbservern aktiv så länge någon av webbsidorna visas aktivt.
Även skapat en ny Configuration-webbsida för inställningar av ESP32-batterimonitorn, tom än så länge. Ska bli data via WebSockets.

Håller nu på att lär mig WebSockets kommunikation mellan ESP32-webbservern och dess webbsidor visade i webbläsare. Har kört med SSE (Server-Sent Events) hittills.
Blir en tvåvägskommunikation som även bör kunna hantera större mängd data.
Ska nu först göra en Configuration-webbsida där jag i mitt ESP32-batterimonitor projekt kan göra inställningar för batteribankens kapacitet, strömshuntens data, etc.
Här en första test bara att få igång WebSockets och se att jag lyckas få det att fungera utifrån givet exempel.
När jag har webbsidan upp både i mobilen och på datorn och jag klickar på tryckknappen i mobilen så växlar "State: ON/OFF" direkt via WebSocket-kommunikation Webbsida-ESP32-Webbsida samt uppdateras samtidigt på datorn :-)
Så en bra smidig realtidskommunikation mellan samtliga aktiva webbsidor på olika enheter!
Gick förvånansvärt smärtfritt, snabbt och smidigt att komma såhär långt. Känns riktigt skoj och lovande!
Är utifrån denna artikeln: ESP32 WebSocket Server Arduino – Control GPIOs and Relays
Har här både SSE-pulse indikering (den lilla grå pricken som blinkar) samt WebSockets parallellt i drift på samma webbsida, så de olika teknikerna går att köra parallellt samtidigt.

Kommit lite längre nu med WebSocket och Configuration-webbsidan.
När jag nu är inne på tredje dagen med kodande / lärande av WebSocket så känns det riktigt intressant och ger flera fina möjligheter till kommunikation server-webbsida-server och därmed möjlighet till väldigt fin funktion.
Samt hyfsat lätt att greppa, koda och få i funktion tycker jag!
Visar här två skärmdumpar från den webbsidan med WebSocket jag kodar nu i ESP32.
"State: ON" är en del av förlagan i artikeln jag utgår ifrån och har jag bara kvar där temporärt medan jag lär mig och utvecklar detta, så kan jag testa av toggling av den ON/OFF via knapptryckning på ena enheten och se att den infon uppdateras samtidigt på alla enheters skärmar som har webbsidan aktiv visad vilket är lite coolt. Ska utnyttja den WebSocket-funktionen till lite annat sedan.
Jag färg-kodar "Save Data" tryckknappen så den visar grönt när all data är sparad och rött så fort något värde för konfigureringen är ändrat och ej sparat, så det syns tydligt.
Växlar tillbaka till grönt först då datan verkligen har sparats i ESP32-flashminnet och returnerar då ett OK från ESP32 via WebSocket till webbsidan som först då växlar till grön bakgrund.

Lite mer färdig layout på Configuration-webbsidan:
Detta är de få inställningar som min ESP32 Ultra-precise Battery System Monitor behöver!

AGM-blykol (lead-carbon) uppmätt 97,8%(Ah) / 92,4%(Wh) batteriverkningsgrad:
Hämtat driftsdata från ESP32-batterimonitorn i mitt off-grid solcellssystem från sju dygns fricampande i husvagnen 5-11 September 2023.
Under turen blev batteribanken aldrig helt fulladdad så fick sju dygns PSoC-cyklande mellan ca 95% och 70% SoC laddnivå, vilket är jättebra för utvärdering av batteriverkningsgraden med hög precision! Och detta då i verklig cyklisk solcellsdrift med 12V kompressorkylskåp m.m.!
Mina 2x106Ah Victron lead-carbon AGM-blykol i 12V parallelldrift jobbade då med en batteriverkningsgrad på hela 97,8%(Ah) / 92,4%(Wh), vilket är jättebra för blybatterier! Speciell vid så pass grund cykling som max 29% DoD (71% SoC)!
Lägst laddnivå var 71% SoC / -61,5Ah samt totalt cyklad urladdning var -213,1Ah under veckan.
Batterimonitorn summerar totalt urladdade Ah så när batterierna cyklas fram och tillbaka under flera dygn i PSoC-drift innan de tillslut blir fulladdade igen.
Nu är mina AGM-blykol strömpulsladdade via en PWM-regulator, vilket ger bättre batteriverkningsgrad och bättre laddmottagning högre upp i SoC mot fulladdat. För enkla öppna fritidsblybatterier gör det signifikant skillnad med jag vet inte hur mycket blykol påverkas av det.
Var en hyfsat solig vecka med många stunder med helt klart solsken samt en del soldis och lite lätt molnigt kortare stunder i vacker skogsbygd.
AGM-blykol batterierna tog emot full laddström som kom från mina 250Wp + 40Wp solpaneler utan att PWM-solladdregulatorn behövde strypa strömmen någon enda gång under veckan!
Det innebär att mina AGM-blykol ger samma effektivitet som LiFePO4 hade gjort i min drift, men i mitt tycke med en enklare mer bekymmersfri drift! Så riktig skoj att få mätt det av min ESP32-batterimonitor!
Den uppmätta Batteriverkningsgraden används i batterimonitorn för att kunna få riktigt bra precision på mätt laddstatus!
Efter nästan två månaders skarp drift nu fanns inget synligt minnesläckage för kodexekveringen i ESP32, trots att det ofta hävdas att det blir så med C++! Samt ESP32 har inte rebootat utan haft 100% stabil drift. Känns bra! Ska jag bara få det kring WiFi, webbservern och webbsidor helt 100% stabilt också, vilket ger kodkrasch någon sällsynt gång typ 1ggr/14dygn vid frekvent visande av driftsdata via webbsidorna. Men nått lång även där nu - verkar vara något med WiFi eller Serial.print() nu som bråkar. Ska testa Serial.end() och se om det gör skillnad!
Idag blev även den s.k. "coup-de-fouet" effektens initiala spänningsdipp vid urladdning väldigt tydlig då batterispänningen snabbt sjönk ned till 12,15V initialt, för att sedan hämta sig igen efter lite mer urladdning. En djup "coup-de-fouet" effekt innebär dels att blybatterierna är riktigt 100% SoC fulladdade, samt dels att blybatterierna är i riktigt bra kondition!
Så en bra signal från min AGM-blykolbatteribank, kanske något jag även borde logga i min ESP32-batterimonitor? Kan användas som ett värde på SoH (State of Health) för blybatterier: Battery state of health estimation through coup de fouet, så kunde kanske ge en bild av batteribankens hälsa över tid?

Installerade ytterligare en solpanel till mitt lilla experimentella off-grid solcellssystem i lägenheten, denna på 45Wp. Så har nu 40Wp + 45Wp innanför fönsterrutor (som dämpar ca 50% av solenergin med sina energiglas) i SydVäst-läge. Ger nu ca 2,5ggr mer ström, så tydligen fungerar den nya solpanelen lite bättre innanför fönsterglasen.
Blir lite bättre med ström för bra utvärdering av min ESP32-batterimonitor samt för AGM-blykol batteriets drift. Bör även fungera något bättre under vintermånaderna nu! Den nya solpanelen sitter även lite bättre placerad så den får vintersol lite tidigare utan trädskugga.
Blev tydligt bättre med laddström nu så kändes skoj, vilket även syns på batterimonitorns webbsida "Latest 24hr running statistics" efter ett drygt dygns drift 2023-11-07:

Yes, nu tror jag att jag löst att min ESP32-batterimonitor med webbserver glest kraschat när jag växlar visad webbsida i webbläsaren, vilket gäckat mig länge nu!
När man klickar på webbsidans meny för att visa en annan webbsida så kan man råka klicka dubbelt på en sådan länk och då skickas två nästan simultana request till ESP32-webbservern, vilket den då blir överbelastad av och man får en kodkrasch. Är nog störst risk i mobilen.
Samma skulle kunna hända om man visar ESP32-webbsidorna på flera olika enheter samtidigt typ mobil och laptop och användarna där råkar klicka på länk till ny webbsida i menyn i stort simultant.
Så nu har jag både i webbsidornas html-kod spärrat detta samt även om man skulle råka trycka två olika meny-länkar nästan direkt simultant.
Samt jag har även nu lagt in i ESP32 C++ koden för webbserverns funktion så att simultana request för webbsidor där fördröjs 1500ms sedan senaste request innan de skickas till webbläsaren, om de nu kommer tätare än så. Annars skickas webbsidan direkt som vanligt.
Men tar ju några veckors drift innan jag kan känna mig hyfsat säker på att detta var lösningen på det problemet, då jag på senare tid bara fått sådan kodkrasch ca 1ggr/14dagar.
De exempel med webbserver i ESP32 jag hittat visar bara för en enda basic webbsida, så sådant här måste man lista ut själv och lära sig vilket inte är helt enkelt.
Men en bit till på väg mot helt stabil kodfunktion även med webbserver igång och webbsidor visade i webbläsare.
Övrig egen kod har fungerat helt stabil i verklig drift nu i mitt off-grid solcellssystem sedan i somras. Även helt utan något minnesläckage!

Har idag kört en stresstest med 3st enheter uppkopplade samtidigt flera timmar mot ESP32-webbservern samt bläddrat mycket mellan webbsidorna på servern i ESP32-batterimonitorn, och allt fungerade stabilt och med bra respons.
Har inte varit helt stabilt förut, så en bra indikering på att stabiliteten blivit signifikant bättre. Känns lovande!

Har idag tagit "mod" till mig och kopplat den högeffektiva MP1584EN DC-DC 3A step-down omvandlare direkt till +5V på ESP32-kortet, justerad till 5,0V utspänning. Det sänkte strömförbrukningen i light-sleep för min ESP32-batterimonitor till 6mA, vilket ger knappt 8mA genomsnittligt förbrukning i night-mode energispardrift med stor del av tiden i light-sleep mellan strömavläsningarna och beräkningarna 1ggr/2,2s!

Andra dagen med lite sol som märktes för blykol-batteriets laddstatus här hemma i mitt lilla experiment off-grid solcellssystem :-)
Annars har det nästan dagligen laddats ur lite sedan många veckor tillbaks så det varit nere på 68% SoC som lägst nu enligt min ESP32-batterimonitor.
Motsvarar nog närmre 2 månaders urladdning med strömmen från PWM-solladdregulatorn, min ESP32-batterimonitor samt 2st Battery Reconditioner elektronikboxar. Jag har i en annan Dashboard-webbsida än de jag visar här med en tidräkning sedan senast fulladdning, men nu håller jag på att utveckla min programkod / firmware så batterimonitorn startas om lite då och då när jag laddar in ny kod, så kan därför inte se hur länge sedan det var.
Är inte så många timmar/dag som solen når mina solpaneler direkt nu, samt stor del av den tiden lyser den låga solen genom en stor lövträdkrona. Så max ström ↑+0.928A känns bra (av max ca +2A på sommaren), samt +1.309Ah/24hr ΔCHARGE hyfsat ändå idag.
Jag gillar min Dashboard-webbsida "Latest 24hr running statistics" där jag får bra data och aggregerad statistik över senaste 24h driften! Så ser väldigt tydligt hur laddningen utvecklat sig, hur mycket Ah/Wh som laddats ur/i batteriet senaste 24h (24hr ΔCHARGE) samt hur lång återstående laddtid det är med den senaste 24h solpanelströmmen (TIME TO GO) som nu visar ↑08d20h. Eller annars återstående driftstid, typ ↓35d15h.
Ger bara så mycket mer info och bättre överblick över batteri­driften än bara precis Ah- och SoC-laddstatus samt Time-To-Go för den momentana ur­ladd­nings­ström­men som nu kvällstid!
Där kan jag se att senaste 24h var lägsta batterispänning ↓12.241V, vilket motsvarar ca 70% SoC enligt SoC-Volt-tabellen för blykol-batteri under svag urladdning, vilket väldigt bra motsvarar lägsta uppmätta SoC på ↓70% samma 24h period.
Så verkar som att långtids­stabili­teten i batteri­monitorns ladd­status­mät­ning har bra precision :-)
Har nu 7st Dashboard-webbsidor i ESP32 mikrokontrollerns webbserver. Fortsätter att utveckla detta, nu senast med tvåvägs-kommunikation via WebSocket mellan ESP32 och webbsida för inställningar. Samt optimerar och säkrar koden lite ytterligare.
Så ett kul hobbyprojekt att utveckla vidare nu under vintern :-)

Kodat så det nu används 2st I2C-seriebussar, en separat för Olimex LCD-modulen som har lite svårt för samverkan med andra enheter på samma I2C och en för INA226-strömsensorn. Blev riktigt bra och får därmed en betydligt mer aktiv snabbare kommunikation då jag slipper lägga in pauser mellan de två enheternas I2C-kommunikation. Var snabbt och enkelt gjort!
Vid nattströmspardrift med light-sleep blev nu den lilla vakna stunden när INA226-interruptet väcker upp ESP32 signifikant kortare så kunde ta upp mot 12-15s innan Task_LCDbuttonsHandler´s asynkrona knappavkänning var 250:e ms kom i interferens med det korta aktiva fönstret och kunde väcka upp batterimonitorn från strömsparläget.
Så fick införa FreeRTOS xTaskAbortDelay(TaskLCDbuttonsHandler) som "Forces the task to leave the Blocked state of the xTaskDelayUntil()", så jag därmed kunde få en synkroniserad avkänning av tryckknapparna med när koden exekverar i det korta aktiva fönstret, vilket blev jättebra! Så blir funktionen kodmässigt helt bra, vilket skulle varit där redan tidigare!
Kräver lite speciell hänsyn vid kodningen: Be careful when using xTaskAbortDelay() along vTaskDelayUntil()!
Känns som detta även lite ytterligare ökar stabiltiteten / robustheten i koden så kodkraschrisken ytterligare minimeras samt reboot vid eventuellt kodproblem helt säkert alltid kan genomföras.
Stresstestat ESP32-webbservern med att visat dess webbsidor på 4st olika enheter samtidigt under en längre tid och bläddrat mellan de olika webbsidorna. Fungerade helt stabilt och bra, med bara något lite segare uppdatering av data! Vid tidigare tester har det lett till kodkrasch, så fått till bra stabilitet nu!
Minnesbelastningen blev då:
84.636b som lägsta lediga heap-minne.
73.716b som största allokerbara heap-minnesfält.
>120.000b (44%) ledigt heap-minne.

Är svårt att få funktionen med xTaskAbortDelay() stabil ihop med Light-Sleep utan har fått glesa kodkrascher nu med den ett par ggr/dygn.
Provar lite olika lösningar men kanske får jag byta till xQueueSend() istället?
Provar just nu med vTaskDelay(2 / portTICK_PERIOD_MS); efter, som delegerar tid till andra FreeRTOS-Tasks.

Funktionen xTaskDelayUntil(&xLastWakeTime, xFrequency); i Task_LCDbuttonsHandler() i kombination med xTaskAbortDelay(TaskLCDbuttonsHandler) där Light-Sleep strömsparläget hanteras ger tyvärr glesa kodkrascher, så inte stabilt för den typ av drift!
Så har nu bytt till xQueueReceive(LCDbuttonsHandlerTrigQueue, &LCDLoopTrigQueue, xTicksToWait); i Task_LCDbuttonsHandler() med logik som ger repeterbar 250ms loop-time med xTicksToWait, samt ihop med xQueueSend(LCDbuttonsHandlerTrigQueue, &LoopTrigQueue1, pdFALSE); där Light-Sleep strömsparläge hanteras för synkron avläsning av tryckknapparna där. Och det har fungerat helt stabil i dryga dygnet nu samt ger lika stabil 250ms cykeltid för avkänning av tryckknapparna som med xTaskDelayUntil()!
Och tryckknapparna känns av stabilt varje gång i det väldigt korta aktiva fönstret där ESP32 läser av data fråm INA226-strömsensorn samt bearbetar den och visar på LCD-displayen under i övrigt Light-Sleep, så man enkelt kan väcka upp från strömsparläget till aktiv drift.

Med drygt 4 dygns kontinuerlig drift nu helt stabilt igen visar det att kombinationen xQueueReceive(LCDbuttonsHandlerTrigQueue, &LCDLoopTrigQueue, xTicksToWait) och xQueueSend(LCDbuttonsHandlerTrigQueue, &LoopTrigQueue1, pdFALSE) för Task_LCDbuttonsHandler() fungerar OK så att dess normalt asynkrona drift kan triggas synkront från Light-Sleep strömsparfunktionen.
Dock är det lite överarbetat med en Queue-funktion här då det inte finns något behov av att sända någon data, men använder den redan på annan plats i koden så var snabbt att testa med! Egentligen skulle en Binary Semaphore användas för detta, men "Direct To Task Notifications" verkar än bättre.
Så ska testa med "Direct To Task Notifications" för effektivare kod: "Unblocking an RTOS task with a direct notification is 45% faster and uses less RAM than unblocking a task with a binary semaphore."
Görs via ulTaskNotifyTake() / xTaskNotifyGive().
Gav perfekt funktion direkt med "Direct To Task Notifications" samt ren tydlig enkel kod, så bara att testa om driften håller sig stabil under några dygn nu utan kodkrasch!
Och sedan rensa upp koden för att behålla detta, code refactoring.
Nu 28h kontinuerlig drift med "Direct To Task Notifications" och det fungerar helt stabilt med riktigt bra tänkt funktion!
Läst lite mer om Direct To Task Notifications och den är avsedd just för denna tillämpning jag gör här, se kodexempel.
"Direct To Task Notifications" fortsätter att fungera helt stabilt! I nattströmsparläge är ESP32 99,8% av tiden i light-sleep och 0,2% av tiden aktiv med att läsa av mätdata från INA226-strömsensorn, bearbeta dessa samt uppdatera LCD-displayen med. Samt via "Direct To Task Notifications" känner då även ESP32 synkront av tryckknapparnas status, och om någon är nedtryckt så går den ur energisparläget och blir aktiv 100% av tiden. Och då arbetar FreeRTOS Task_LCDbuttonsHandler() helt asynkront och känner av tryckknapparnas status 1ggr/250ms för en responsiv känsla oberoende av övrig kodexekvering.
Har tidigare sänkt ESP32-processorns klockning till 80MHz under strömsparläget, men provad nu att köra 240MHz (max) och det gav en gnutta lite lägre strömförbrukning för strömsparläget! Så kör så nu. Då kanske strömsparläget närmar sig 99,9% tid i light-sleep?
Då drar min ESP32-batterimonitor från 12,5V matning bara 6mA i nattströmsparläget, väl under mitt mål på <15mA!
Har nu även provat att istället för CONV_TIME_1100 behålla CONV_TIME_588 & AVERAGE_1024 för INA226 under nattströmsparläget, och nu med den snabbare dataavläsning med 2xI2C så påverkades strömförbrukningen minimalt i strömsparläge och är fortfarande väl <7mA.
Med CONV_TIME_588 får batterimonitorns INA226 lite noggrannare avläsning av dynamiska strömvärden då det samspelar bättre med RLC-filtret!
Så när det nu påverkar strömsparlägets strömförbrukning minimalt behåller jag det. Kan nog då senare även förenkla och rensa programkoden lite via en code refactoring.
Har gått igenom koden noga för Task_LCDbuttonsHandler() ihop med StateMachine() och optimerat för strömsnålast och bäst responsiv tryckknapp-funktion under strömsparläge med Light-Sleep. Blev riktigt bra och en märkbar förbättring mot tidigare!
Innan dessa senaste code refactorings hade jag inte kodat för synkron avkänning i det lilla tidsfönstret då ESP32 är i aktiv drift under light-sleep i strömsparläget, så var inte helt responsiv då med avkänning av trycknapparna varje sådan kort period med aktiv processor!
Optimeringarna nu gjordes via noggranna mätningar av kodfunktionen i drift, så riktigt fint tekniskt utvärderat! Nu även något lite strömsnålare i natts­tröm­spar­läge med light-sleep, och framförallt mäter dynamiska strömvärden med bättre precision nu i strömsparläget!
På min ESP32-batterimonitor från off-grid solcellssystem har jag här hemma kopplat om så DC-DC-omvandlar matar 5V direkt till ESP32-kortet utan att gå via dess 5V-regulator, och där har jag inte haft någon kodkrasch på länge men har inte det lika mycket i drift heller.
Så ska göra samma omkoppling på det i solcellssystemet här hemma, då det kanske kan vara en bidragande orsak att ESP32´s driftspänning kanske droppar för mycket ibland med WiFi och webbserver igång.
Med direkt 5.0V från DC-DC-omvandlaren har ESP32 där 3,3V matningsspänning, medan där jag matar via 5V-regulatorn är det 4,5V resp. 3,2V.
I strömsparläge 99,5% tid i light-sleep ned till 95% beroende av hur mycket som skrivs till LCD-displayen, men >99% i snitt.
Dock är denna tidsdata utskriven via Serial.print() som också tar lite exekveringstid:
Active CPU-time in Light-Sleep (us): 6121, Cycle Time (ms): 1207, Time-quota (%): 0.51.
Gjort lite code refactoring typ Task Stack Size optimering, eliminerat ytterligare några fall som kanske kunde ge Division by Zero (fick en sådan kodkrasch nyss, men inte haft på länge vad jag vet) samt optimerat / förtydligat en del beräkningar, etc.

Espressif32 systemprogramvaran blev uppdaterad till ver. 6.5.0:
- Platformio / Platform-Espressif32 v6.5.0
- Arduino Release v2.0.14, lite fixat i WiFiClient som kan vara bra för mig
- Espressif ESP-IDF Release v5.1.2, a bugfix update
Och nyligen kom också PlatformIO IDE 3.0 for VSCode och har nu PlatformIO 3.4.4.
Är väldigt många mikrokontrollers som stöds nu: Platformio/Espressif32/boards.
Med Espressif32 v6.5.0 minskade SRAM-användningen med ca 30% (!), både lägsta ledigt under exekvering, största allokerbara minnessegment samt totalt ledigt minne under exkevering i mitt projekt! Är väldigt positivt!
Jag har även gjort en helt ny Hard-reset-handler placerad i Setup()-funktionen, så även soft-resets görs till hard-resets. Detta då ESP32 flera gånger hängt sig när den av någon anledning själv bootat om med soft-reset. Jag loggar nu även 8st olika händelser som får ESP32 till att boota om, så jag får bra statistik på vad som är orsaken, om det nu skulle inträffa.
Målet är att ESP32 aldrig själv ska boota om!
Jag har även äntligen börjat hitta mer info om hur jag ska koda WebSocket för en multi-webbsides webbplats i ESP32! Så känns som det börjar lossna lite där också.
Ska gå över helt till WebSocket från att jag nu använder SSE (Server Side Events)!

2023-12-31
Har uppdaterat kod-blockschemat för ESP32-batterimonitor delen i PWM-solladd­regulatorn med den senaste kodutvecklingen. Har bl.a. nu senast ändrat så att Task_DeferredInterruptIN226() nu skickar ett Queue-meddelande till Task_StateMachine() istället för att direkt anropa StateMachine->StateHandler() funktionen. Så nu sker allt via Inter-Task Communication från Task_DeferredInterruptIN226(), så som tänkt!

Förut med direkt funktionsanrop till StateMachine->StateHandler() så vid nattströmsparläge sätts ESP32 i light-sleep inne i den funktionen, vilket medförde att Task_Deferred­Interrupt­IN226() väntade på det och ej exekverade färdigt. Det innebar i sin tur att i Light-Sleep-Mode var då inte Task_Deferred­Interrupt­IN226() i läge att direkt ta emot INA226´s interrupt via dessa ISR utan det skedde en fördröjning där i väntan på att State­Machine->State­Handler() och Task_Deferred­Interrupt­IN226() skulle exekvera färdigt efter att INA226-interruptet väckt upp ESP32 igen från light-sleep!
Nu tar det bara 4-5µs med xQueueSend() till Task_StateMachine() och sedan exekverar Task_DeferredInterruptIN226() färdigt till xQueueReceive() där den väntar beredd på att ta emot nästa xQueueSendToBackFromISR() från INA226-ISR för att läsa av de nya datavärdena från INA226. Det innebär att programkoden nu arbetar mer optimalt och effektivt med bättre precision, samt så asynkront oberoende som är min kodstrategi! Ett bra steg framåt för en riktigt bra kodfunktion!
Trots att detta är rätt avancerad FreeRTOS-funktionalitet krävdes bara 5 kodrader för att uppnå funktionen, vilka fungerade perfekt direkt. En typisk fördel med FreeRTOS kodning!
Nu fungerar det som en charm i hur de olika kodblocken samarbetar med varanda via Task´s.

Har nu även kodat nytt hur programmet hanterar reset (reboot) efter eventuell kodkrasch som ger soft-reset, där programmet nu alltid gör en hard-reset direkt på det i setup() för att säkerställa OK programfunktion igen, efter att först sparat statistik på orsaken samt sparat driftsdata.
Sparar nu 8st olika orsaker till reset (reboot) så man kan följa vad som orsakar det, även om målet är att det aldrig ska inträffa. Samt sparar i flash den viktigaste driftsdatan för själva batterimonitorns funktion, så inget går förlorat där kring batteribankens laddstatus.
Har då lärt mig att man kan inte spara en instans av en class i RTC-minnet via RTC_NOINIT_ATTR utan de datavärdena nollställs när class-definitionen på nytt laddas in. Så har fått gå över till att spara denna data även i separata RTC_NOINIT_ATTR-variabler!
Är noga validerat idag 2023-12-31 och fungerar nu helt perfekt, efter en hel del efterforskning!
Bl.a. lärt mig: "Variable with RTC_NOINIT_ATTR is not initialized at program start to not erase the value stored in the RTC memory." Så gör det i setup() nu för ESP_RST_POWERON.
Läs mer om min RTC data store längre ned här.

En soft-reset, t.ex. via esp_restart(), resulterar i: "After successful restart, CPU reset reason will be SW_CPU_RESET. Peripherals (except for Wi-Fi, BT, UART0, SPI1, and legacy timers) are not reset.", vilket innebär att även soft-reset från kodkrasch eller WatchDog-Timer inte återställer allt i mikroprocessorn och inte motsvarar en PowerON hard-reset! Som exempelvis vid problem med I2C stack.
Jag har sett detta att efter panic´ed soft-reset kodkrasch har processorn ibland hängt sig och inte nått fram till normalt exekverande programkod igen, typ att "some of the data is still corrupted instead of being cleared out", vilket då krävt en manuell hard-reset via RST-knappen. Och då har den fungerat igen!
Så för att få en fullständig säker ren reset / reboot måste en hard-reset göras, vilket är det jag hackar nu. Är bättre än en extern WDT för den situationen! 2024-05-10

Samt konstaterar att efter kodkrasch med soft-reset fungerar inte kodens hard-reset OK via att en GPIO drar RST-pin (EN-pin) låg, för det sker troligen för kort stund för OK hard-reset.
"The ESP32 chip enable needs to be low for 150µs at each reset." Guaranteeing a minimum reset pulse with, required to ensure all registers are cleared.
WROOM-32 datasheet: To ensure the power supply to the ESP32 chip during power-up, it is advised to add a RC delay circuit at the EN pin. The recommended setting for the RC delay circuit is usually R = 10kΩ and C = 0.1µF. källa
I ESP32-WROOM Datasheet står det:
"To ensure that the power supply to the ESP32 chip is stable during power-up, it is advised to add an RC delay circuit at the EN pin. The recommended setting for the RC delay circuit is usually R = 10kΩ and C = 1µF. However, specific parameters should be adjusted based on the power-up timing of the module and the power-up and reset sequence timing of the chip."
I Espressif Boot Mode Selection står:
"If this circuitry is implemented (all Espressif boards have it), adding a capacitor between the EN pin and GND (in the 1µF-10µF range) is necessary for the reset circuitry to work reliably. This is shown in the ESP32 Module section of the schematic."
Så en kondensator mellan 0,1µF - 10µF är enligt detta OK för ESP32 EN-pin (reset-pin).
En ESP32-GPIO utgång bör max belastas med -15mA dvs ≥220Ω, för urladdning av 0.1µF.
ESP32 GPIO pins info, restrictions and features - 220Ω x 0.1µF = 22µs, ESP-pullupR≥45kΩ
Så R bör kunna vara åtminstone 1kΩ!
Får prova med ett sådant RC-nät till RST-pin och se om det fixar hard-reset problemet.
Ett sådant RC-nätverk gör även att ESP32 kan boota säkert när stigtiden för matningsspänningen är lite för långsam, då RST-pin hålls låg medan matningsspänningen hinner stabilisera sig.
Har nu fått det att fungera stabilt via ett RC-nät mot RST/EN-pin! 2024-05-09

INA226 samplar nu mätvärden (ström, spänning, effekt) drygt 70.000.000ggr/24h (även i natt-ström­spar­läge Light-Sleep-Mode) dvs ca 1ggr/1,2ms, samt när PWM-regulatorn strömpulsar 30Hz samplar INA226 4ggr så ofta ca 1ggr/0,3ms (3.333Hz) för hög precision i mätningarna då.
Det innebär att ESP32-batterimonitorn mäter även väldigt dynamisk ström med hög precision!
Bidrar till en riktigt långtidsstabil exakt mätning av laddnivån i batteribanken!

2024-01-03
Haft i drift 3,5dygn med senaste kodförbättringarna med den egna koden i drift men utan webbservern aktiv och kan inte se något minnesläckage alls, vilket känns bra för drygt 7000 rader egenskriven C++ kod!
RAM ESP.getMinFreeHeap(): L129.816B
RAM ESP.getMaxAllocHeap: A110.580B
RAM ESP.getFreeHeap: F238.528B (77%)
Har även hela dagen idag återaktiverat WiFi & Webbservern i ESP32 via dess trycknapp en massa gånger från nattströmsparläge (Light-Sleep-Mode) och det fungerar superstabilt nu!

2024-01-05
Äntligen kan jag avkoda de Back-/Stack-Trace jag får vid kodkrasch i ESP32, via tips om en Stack Trace Decoder, vilket underlättar felsökning och kodutveckling framöver nu!
Nu har jag fångat en Back-/Stack-Trace för "Guru Meditation Error: Core 1 panic´ed (IntegerDivideByZero). Exception was unhandled." och avkodat den via ESP Stack Trace Decoder utifrån min firmware.elf fil. Är sannolikt det kvarvarande problem jag har med kodkrasch ibland med webbservern i ESP32 aktiv bläddrandes mellan alla webbsidorna där.
Hade "Guru Meditation Error: Core 0 panic´ed (IntegerDivideByZero)" redan 2023-03-17!
Och det är i ESPAsyncWebServer-esphome/src\AsyncEventSource.cpp:312 den kodkraschen sker, där i min kod rad 6605 anropar min funktion "if (HandlerEventDataSSE(eventsStat24hr, LoopTimeTask)" som i min kod rad 7051 anropar "EventsSSE.avgPacketsWaiting() * EventsSSE.count()" som är i "ESPAsyncWebServer-esphome/src\AsyncEventSource.cpp" där tydligen kodkraschen sker på rad 312 som är i dess funktion "AsyncEventSource::­avgPacketsWaiting()"!

Så är anropet till "EventsSSE.avgPacketsWaiting()" som tydligen resulterar i en IntegerDivideByZero, då det blir det 2:a anropet till "AsyncEventSource.cpp:312"!
Och kodraden AsyncEventSource.cpp:312:
return ((aql) + (nConnectedClients/2))/(nConnectedClients);, där divisionen är!
Så när det är nConnectedClients=0 blir det kodkrasch där!
Är en integer: uint32_t nConnectedClients.
Så är inte min kod som kraschar utan i SSE-koden hos ESPAsyncWebServer-esphome!
Det stärker min tanke på att växla från SSE till WebSocket som en möjlig lösning, vilket jag påbörjat! Men blir SSE stabilt nu får det vara kvar på några webbsidor!
Har läst att WebSocket ska vara stabilare och mer välutvecklat än SSE i ESPAsyncWebServer, men det var långt efter att jag satsade på SSE i mitt kodprojekt ESP32-batterymonitor!

Jag har länge misstänkt ESPAsyncWebServer-esphome kodbiblioteket för dessa kodkrascher och nu äntligen kunnat bekräfta det!
Har provat en liten bugfix där för AsyncEventSource.cpp:312:
return ((aql) + (nConnectedClients/2))/(fmax(nConnectedClients, 1));
som ser till att det inte blir division med zero där, bara som en test om min kod blir stabil då!
(original: return ((aql) + (nConnectedClients/2))/(nConnectedClients);)
Nu har jag idiotbläddrat fram och tillbaka mellan alla min webbsidor i ESP32-webbservern en lång stund, även växlat innan de är färdigladdade, och ingen kodkrasch!
Det har jag inte kunnat förut!
Även nu testat att ha webbservern igång under 4h och regelbundet bläddrat mellan alla webbsidorna helt stabilt!
RAM-minnesbelastningen är då: L126.320B, A110.580B & F159.200B 51% / F236.556B 76%.
Bara så jäkla skönt - då kan jag fokusera på att nu utveckla funktionalitet istället!
Så verkar som den lilla kodfixen i det kodbiblioteket fixade mitt kvarvarande problem!
Då borde jag ju egentligen bidra med den bugfixen till dem efter en längre tids test av den här hemma, men har aldrig gjort något sådant till ett open-source kodbibliotek.
ESPHome skriver om sin webbserver: "Please note that enabling this component will take up a lot of memory and may decrease stability"! Så kanske löst en del av det med min bugfix.

2024-01-09
Jag har nu analyserat den funktionen avgPacketsWaiting() i AsyncEventSource.cpp där detta sker i, i kodbiblioteket ESPAsyncWebServer-esphome. Och de tar egentligen hand om detta fallet precis i början av den funktionen där med check om if(_clients.isEmpty()) return 0;, så detta måste handla om en sällsynt s.k race condition pga preemptive multitasking i FreeRTOS!
Så när ett variabelvärde hinner ändra sig pga FreeRTOS race condition mellan att det checkas precis i början av funktionen till att det används för division i retur-värdet i slutet så blir det sällsynt division med noll.
Då är min kodlösning med fmax() rätt säker då jag där bara använder nConnectedClients-värdet en gång för att undvika division med noll där som ger en Thread-safe lösning:
return ((aql) + (nConnectedClients/2))/(fmax(nConnectedClients, 1));
Från originalet: return ((aql) + (nConnectedClients/2))/nConnectedClients;
Bör finnas en liten risk för även sällsynt race condition med en if-else sats istället, tänker jag!
Om nConnectedClients hinner ändras från att det checkas i if() till att det används i divisorn.
Men bäst vore om man tilldelade värdet till en lokal variabel som sedan används konsekvent genom funktionen! Det blir dels tydligare, dels mer framtidssäkert mot kodningsmisstag om funktionens kod vidareutvecklas. Blir nog även exekveringsmässigt något effektivare. Ville dock inte ändra så mycket i denna koden.
Ett väldigt intressant fall upplever jag, kring svårigheten med att koda för preemptive multitasking med FreeRTOS!
Då har jag lyckats bra i min egen C++ FreeRTOS kodnings 7000 rader, då den kört stabilt i skarp drift fler månader i sträck utan vare sig någon kodkrasch eller något minnesläckage, trots flitig avancerad användning av FreeRTOS´s funktionalitet samt C++ objectorienterad kodning.
Läst på och analyserat lite mer kring denna race-condition i funktionen avgPacketsWaiting() i AsyncEventSource.cpp och nu istället ersatt originalkoden:
return ((aql) + (nConnectedClients/2))/nConnectedClients;
med denna if()-else-satsen då variabeln nConnectedClients är en lokal variable som ej kan ändras av annan kod och därmed är säker mot race-condition:
if (nConnectedClients > 0U)
{
 return ((aql) + (nConnectedClients/2)) / nConnectedClients; // round up
}
else
{
 return 0;
}

2024-01-06
Har nu (äntligen) byggt ett nytt batteriboxsystem runt mitt nya AGM-blykol batteri 12V UPLUS 90Ah Lead-Carbon och installerat PWM-regulator, strömshunt samt el-/USB-uttag och min ESP32-batterimonitor där, allt kopplat till solceller för ström. Även monterat en 12V/230V 100W ren sinus växelriktare, strömsnål och tyst fläktlös.
Gjort ett betydligt bättre och snyggare bygge nu, då det förra var lite provisoriskt som test och snabbt få något att kunna utveckla mot.
Det gamla tog jag i drift 2019-05-05 med mitt gamla Blykol-startbatteri Tudor High Tech Carbon Boost 2.0 från bilen Tudor High Tech TA456 45Ah Flooded, nu det 2:a där i drift köpt 2016-01-23 överflyttat till batteriboxen 2021-03-25 efter drygt 5 års drift i bilen, och fortfarande välfungerande nu 8 år gammalt!

Har varit bra att testköra min ESP32-batterimonitor mot ett så gammalt blybatteri och sett att allt fungerar bra då också, med 0,5% Tail-current för 100% SoC fulladdat m.m.!
UPLUS 90Ah Lead-Carbon är ett AGM-blykol batteri avsett för djupurladdning och solcellsdrift med exceptionellt bra cyklingslivslängd, som även klarar av typ längre UPS-standby drift bra så bör bli perfekt här hemma.
Blir då lite mer korrekt blybatteridrift för solcellssystemet att utvärdera mot, samt får då även som lite mer riktig reservkraft här hemma på 12V 90Ah ca 1kWh!

Idag var det soligt så PWM-regulator kom upp till strömpulsad reglerad laddning >1h idag mot det fulladdade UPUS-blykol. Det innebär att det blev aktiverat och helt 100% SoC fulladdat, en bra utgångspunkt nu att följa dess drift. Ska var flera soliga dagar på rad nu.
Med 0,5% Tail-current (<450mA för 90Ah) som indikering för 100% SoC fulladdat under spänningsreglerad laddning, så kom den redan idag ned i 300mA i 13,8V float-laddning, dvs med 1,5ggr marginal för den utvärderingen. Blir nog än lägre framöver då batteriet aktiverats lite mer av strömpulsad laddning. Skoj att jag nu löst buggen i webbservern som gäckat mig länge, när jag nu börjar följa detta batteriets drift via min Ultra-precise ESP32-batterimonitor!

Min ESP32-batterimonitor har nu varit i drift här hemma sedan 3 Mars 2023, så 3/4 år. Min C++ kod har hela tiden arbetat stabilt utan minnesläckage, men jag har haft problem med stabiliteten hos kodbiblioteket ESPAsyncWebServer-esphome för webbservern i ESP32. Men där har jag nu gjort en buggfix. Givetvis har programkoden förbättrats och förfinats samt fått lite mer funktionalitet under vägen, men har ändå hela tiden loggat laddnivån i blybatteriet fint. Men precisionen har förbättrats något under resan, så nu är den riktigt bra!

2024-01-08
Följer den fina data & info jag får över batterisystemets drift i mitt lilla experiment solcellssystem här hemma i lägenheten i dagens solväder för mitt nya fina AGM-blykol batteri 12V UPLUS 90Ah Lead-Carbon.
Nu precis synkade min ESP32-baserade "Ultra-precise Battery System Monitor" sin 100% SoC fulladdat mot fulladdat batteri, och precis sekunden innan det skedda visade den -0,29Ah i laddnivå för blybatteriet!
Och då har jag ännu inte haft en battericykel den hunnit utvärdera batteriverkningsgraden för det, så den använder 100% för det, vilket innebär att med utvärderad batteriverkningsgrad hade den kommit ytterligare närmre 0,0Ah i laddnivå vid synkningen!
Men -0,29Ah för ett 90Ah batteri utgör ändå en högprecisions synkning av 100% SoC, så känner mig nöjd med det.
Så är väldigt tillfreds med den princip jag har för att synka 100% SoC, ihop med de få lätta inställningarna som krävs!
Synkade då vid 99,7% SoC, vilket ju är superbra precision!
Är en del av att min ESP32-batterimonitor ger så bra precision i sin mätning och beräkning av batteribankens laddnivå, ihop med att den använder verklig uppmätt batteriverkningsgrad för varje laddcykel samt en Ultra-precise strömsensor.
Och har aktiverat ESP32-webbservern samt bläddrat bland webbsidorna över driftsdatan för batteridriften rätt många gånger nu senaste dygnet där, inte minst idag, och ingen kodkrasch!!!

2024-01-09
Soligt väder idag också, och ESP32-batterimonitorn synkade 100% SoC till fulladdat batteri vid -0,166Ah laddnivå, i och för sig bara från -1Ah laddnivå. Men skoj 100% SoC synkningen sker med sådan precision även vid så minimala battericyklingar.

2024-01-13
Lagt in i programkoden så att den nu loggar dels "Battery Cell Balancing time" (hr/day), dels loggar total driftstid för ESP32-batteriomonitorn. "Battery Cell Balancing time" gäller blybatterier och den tid de befinner sig i aktiv spänningsreglerad drift i antingen absorptions- eller float-laddfaserna. Det är främst då blybatteriets självbalansering av cellerna är aktiv.
Nu har ESP32-batterimonitorn till mitt lilla off-grid experiment solcellssystem varit i drift i drygt 6 dygn sedan bugfixen i kodbiblioteket ESPAsyncWebServer-esphome, där jag flera gånger varje dag bläddrat runt bland dess webbsidor med driftsdata. Och helt fullt stabilt nu utan minsta lilla kodkrasch, samt utan något mätbart minnesläckage eller fragmentering av RAM-minnet!
Är första gången jag kunnat checka minnesläckage / fragmentering över en längre tid med ESPAsyncWebServer-webbservern i drift bläddrande runt bland webbsidorna, då det tidigare lett till kodkrasch! Så ett ytterligare stort steg framåt nu!
Blir skoj nu att kunna fokusera på att utveckla kod / funktion istället för buggletande!
Men det har lett till en bättre kod som även belastar RAM-minnet mindre, så varit bra ändå.
Samt jag har ökat min kunskap och insikt om FreeRTOS-kodning märkbart!

2024-01-15
Kodat en till LCD-meny med en displayvy för "Battery Cell Balancing time" plus total driftstid för ESP32-batterimonitorn. Har nu 23st LCD-displayvyer man kan bläddra runt bland, som visar den mesta av de driftsdata man kan se via webbsidorna, där man kan göra konfigurering av ESP32-batterimonitorn samt man kan nollställa loggad mätdata via 2x16 teckendisplayen.

2024-01-16
Med det nya mätvärdet CellBalancing (hr/day) för blybatterier som mäts sedan idrifttagning i min ESP32-batterimonitor har jag nu fått 3 dygns mätning, med en helsolig dag idag:
CellBalancing är den tid som solladdregulatorn aktivt reglerar batterispänningen och stryper strömmen från solpanelerna. Det är främst då som blybatteriernas självbalansering av battericellerna pågår. För omvårdande blybatteridrift bör man ha tillräckligt med sådan tid, men vad tillräcklig är vet jag inte. Har inte hittat något att läsa om det på Internet.
Men tycker det är motiverat att logga ändå.
Senare ska jag även ha 28dagars loggning av driftsstatistik, så då kommer man kunna se den och de andra siffrorna valbart för 1-4 veckor.
Som idag var första dagen med solsken sedan jag började logga detta och det blev då 16min CellBalancering.
Och jo jag har ett litet mätfel i strömmätningen på ca 3mA som beror på någon läckström eller liknande i min hårdvara, så när mitt AGM-blykol batteri här hemma i lilla experiment off-grid solcellssystem nu bara precis cyklas med den ström som PWM-regulatorn, ESP32-batterimonitorn och mina två Battery Reconditioner drar samt den svaga ström solpanelerna ger nu vintertid så påverkar den så jag falskt får mätt 100% batteriverkningsgrad. Men är väldigt grunda battericyklingar då, samt tyder ju på väldigt hög batteriverkningsgrad.
Själva strömsensorn i sig mäter dock helt korrekt är checkat. Vid 0A ström genom strömshunten visar den 0,0000A, så mäter då 0A med fyra decimaler!
Ska snart ta itu med det i hårdvaran och se hur jag kan åtgärda det!
Men redan märker jag att solen börjar ge mer ström nu jämfört med vid midvinter 21 December, så förändrar sig snabbt nu :-)
Dagens max laddström hamnade på +0,787A (av max ca +2A här sommartid) och batteriet blev fulladdat idag med en fin precisions-synkning till 100% SoC fulladdat batteri igen.

2024-01-19
Kodat en säkerhetsfunktion att om INA226 skulle hänga sig och sluta skicka interrupt för ny data att hämta så görs en automatisk soft-reset av INA226 nu.
Är ett led i att uppnå 24/7/365 stabil drift för batterimonitorn!
I experimentuppkopplingen här hemma har jag ca 1m långa kablar mellan INA226 och strömsensorn och det gör att den Battery Reconditioner som sköter om blybatteriet med 9kHz extremt korta kraftfulla strömpulser in i batteriet motsvarande ca 1MHz och lite långsammar 9kHz 3A strömpulser från batteriet för uppladdning mäts fel i sin strömförbrukning! De korta snabba strömpulserna dämpas och når inte helt fram till INA226, så mäter inte riktigt dessa strömpulser som matas tillbaka in i batteriet. Kom på att partvinna dessa mätkablar nog inte var så smart då, så nu särat på dem och ser ut att mäte mer rätt nu, kanske helt rätt. Är svårt att mäta snabbt pulsad ström helt korrekt!
I skarp drift ska dessa kablar vara max 2dm långa, troligen ca 1dm och då EJ partvinnade.
Får se när batteriet blir helt fulladdat nästa gång med 100% SoC synkning. Men redan idag med denna ändring i drift halva tiden sedan senaste 100% SoC synkning kom jag upp på +0,001Ah som max. Bör bli lite mer imorgon, så en rättvis batteriverkningsgrad kan räknas även för dessa låga strömmar.
Idag blev det lite längre PWM-strömpulsad laddning i solskenet och kom då ned i en tail-current på 265mA jämfört med 450mA som är tail-current för 100% SoC synkronisering (0,5% av 90Ah). Så en marginal mot det på 1,7ggr som känns betryggande! Men styrs även adaptivt.

2024-01-20
Beskrev på Facebook ESP32-batterimonitorns kodfunktion (se även kod-blockschema):
Jag har ingen traditionell programloop i min kod, utan loop() från Espressif Arduino-framework raderar jag direkt utan att använda.
Jag kör istället med 5-6st FreeRTOS Task som fungerar ungefär som självständiga program som kan exekvera oberoende av varandra multitaskande via FreeRTOS preemptive multitasking, så i princip samtidigt parallellt.
Så finns ingen programloop där man linjärt i koden kan följa vad programmet gör.

Jag har en Task som fungerar lite liknande en sådan programloop, en "Deferred interrupt processing" Task som triggas av en interrupt från min smarta INA226-strömsensor via en ISR-funktion() ca 1ggr/s när nya aggregerade mätdata finns att hämta, som är den Task där det mesta utgår ifrån. Den sätter sätter pulsen för programmets exekvering och utgör därmed lite av kärnan i programkoden.
Sedan har jag en "Finite-State Machine (FSM)" Task som styr och övervakar i vilket programläge "state" som min batterimonitor ska arbeta i, som styr vilken funktionalitet som är aktiv för stunden och som reagerar både på input från användaren och från annan kodexekvering samt signaler och då även övervakar WiFi när aktiv.

Och i den Task som fungerar lite liknande en programloop anropar jag inga funktioner() som den då måste invänta dess exekvering innan den kan gå vidare i sin egen exekvering, utan allt sker via s.k. FreeRTOS intertask communications "meddelanden" där det snabbt skickas ett meddelande till en annan Task om vad som ska göras och sedan direkt exekverar vidare.
På så sätt kan denna Task snabbt exekvera färdigt sin loop och invänta ny deferred interrupt från INA226 utan att behöva vänta in exekvering av annan kodfunktion!
Medan de Task den skickat meddelande till exekverar parallellt multitaskande med den.

Jag får på så sätt ett program som exekverar väldigt effektivt, med avancerad funktion som är svår att uppnå utan FreeTROS-Task och på ett sätt en tydlig kod.
Men jag tror kodens programfunktion är jobbig att sätta sig in i för någon annan just för att mycket pågår samtidigt nästan simultant! Så man får ha ett sorts 3D-tänk kring kodexekveringen!

Som exempel har jag en Task som läser av de fyra tryckknapparna på mitt LCD-display shield exakt 1ggr/250ms ±0,5ms självständigt helt asynkront med övrig kodexekvering, som ger en väldigt fin responsive känsla i avkänning av nedtryckt tryckknapp. Den skickar då direkt meddelande till Task LCD-display-handler asynkront för snabb reaktion på LCD-teckendisplayen på nedtryckt knapp, utan att behöva vänta in någon annan kods exekvering.
Samt den Task som läser av mätdatan från INA226-strömsensorn skickar genast de nya datavärdena via ett queue-meddelande till Task LCD-display-handler asynkront för snabb uppdatering på LCD-teckendisplayen.
Kommer båda dessa samtidigt så köas de bara upp i den Task som sköter LCD-displayen och exekveras direkt efter varandra.

Ger bara så fin, smidig och bra funktion, så FreeRTOS med sin multitasking är helt underbart för lite mer avancerad programkodfunktion!
Och gör det lätt att koda avancerad kodfunktion!
"This approach enables parallel execution of tasks, reducing the overall execution time and increasing the system´s responsiveness."
"ISR programming enables the system to respond rapidly to critical events by prioritizing interrupt requests. In time-critical applications, such as data acquisition systems or control systems, interrupts can be employed to capture time-sensitive data accurately without compromising the system´s performance." Dvs det jag gör med interrup för avläsning av INA226´s aggregerade datavärden från dess självständiga kontinuerligt upprepade 1024st mätningar.
Jag ska dock via code-refactoring göra Finite-state Machine funktionen tydligare med mer entydig funktion, då jag nu lärt mig mer samt funderat igenom funktionaliteten bättre.

2024-01-23
Råkade göra ett kodningsfel som triggade WDT (Watchdog Timer) och fick då verifierat att loggningen av de 8st olika felorsakerna fungerar som tänkt i setup():
Total Power-ON resets: 46
WDT soft-resets in total: 479
INT_WDT resets in total: 0
TASK_WDT resets in total: 5
Brownout resets in total: 1
RST_SW resets in total: 6
Other resets in total: 0
Panic Hard-Resets total: 12
Är värdefullt för uppföljning av 24/7/365-driften i skarp drift, att kunna se vilka orsakerna är till reset / reboot samt om / hur ofta det förekommer, där målsättningen är noll gånger.
Men är även värdefullt vid utvecklingen av programkoden såhär!
Kom tack vare det på att detektering av ESP_RST_BROWNOUT inte går att spara som statistik i flash-minnet via preferences, då flash-minnet kan bli korrupt vid skrivning när matningsspänningen är för låg! Fångat 2st BrownOut så nu som gjort programkoden i flash korrupt så den måste laddas upp igen till ESP32! Blev då indikerat som rst:0x10 (RTCWDT_RTC_RESET) efter reset, med direkt reset igen i en kontinuerlig loop.
"The RTC watchdog is used in the startup code to keep track of execution time and it also helps to prevent a lock-up caused by an unstable power source. It is enabled by default (see CONFIG_BOOTLOADER_WDT_ENABLE). If the execution time is exceeded, the RTC watchdog will restart the system.
The RTC watchdog covers the execution time from the first stage bootloader (ROM bootloader) to application startup. It is initially set in the ROM bootloader, then configured in the bootloader with the CONFIG_BOOTLOADER_WDT_TIME_MS option (9000 ms by default).
Är många kod-detaljer att upptäcka på vägen, som inte går att läsa sig till på ett lätt sätt!
Nu varit i drift 18 dygn med buggfixen och lite förbättrad kod samt visat ESP32-webbsidorna med driftsdata flera ggr/dag helt stabilt utan någon kodkrasch! Är lite av ett genombrott!
Mäter även strömmen för 9kHz strömpulserna från Battery Reconditioner med bättre precision nu, trots svårmätt då de extremt korta kraftiga strömpulserna motsvarar ca 1MHz så både induktans och kapacitans i ledningarna och strömshunten inverkar negativt.

2024-01-24
Nu har jag kodat så min Configuration-webbsida hämtar data till de olika input-fälten från ESP32 via WebSocket samt uppdaterar batterispänningen kontinuerligt där. Har tagit bort all SSE (Server Sent Events) för den webbsidan.
Nästa steg blir att skicka tillbaka ändrade data till ESP32 och spara i flash-minnet via preferences. Läst på mycket om WebSocket nu och finns ingen inbyggd funktion för event-driven kodning för varje datavärde men använder onMessage-event där man själv kan skapa en event-liknande struktur via messagedata och switch()-sats. Där är ju SSE lite smidigt med sin helt event-driven funktion, men WebSocket har annan kraftfull funktion.
Efter lite funderande så kan nog WebSocket via sin onMessage-event kombinerat med switch()-sats bli tydligare, mer överskådligt, kompaktare samt få bättre kodstruktur.
Jag tar det lugnt såhär, läser på och funderar så jag får till en bra kodstruktur som är lätt och smidig att bygga vidare på, som nu kring WebSocket! Är nödvändigt med 7000+ rader kod!
Men tills vidare behåller jag SSE för de webbsidor som bara uppdateras med enkla datavärden då det fungerar stabilt nu, men framtiden får utvisa vad WebSocket går för.
På ett sätt är det smidigt att skicka all data via JSON och event-liknande switch()-sats, som med WebSocket! Får se hur det blir med signifikant mer data via JSON för andra webbsidor.
Dessa sex datavärden skickas i alla fall snabbt via JSON / WebSocket.

2024-01-26
WebSocket-koden för att spara data i ESP32 flash-minnet från Configuration-webbsida är nu klar! Fått till en väldigt bra struktur och tydlighet i koden, med fint strukturerad funktion.
Samt en kod det är lätt och smidigt att återanvända och bygga vidare på!
Med WebSocket kan jag hantera datavärden väldigt fint strukturerat, med avancerad funktion!
Jag tjänar helt klart på att ta tid på mig och smälta den info jag läst, som om WebSocket nu!
Så fort man editerat någon konfigurerings-data så ändras Save-Data knappen till rött för tydlig visuell indikation att den ändrade datan inte är sparade. Och när man trycker på knappen för att spara så ändras den inte till grönt förrän webbsidan fått tillbaka kvittens på att ESP32 övervakat och checkat att datan verkligen blev sparad i flash-minnet!
Så man kan inte bli lurad om det skulle bli problem med data­kommu­nika­tionen mellan webbsidan och ESP32 med dess webbserver! Ger full datasäkerhet.
Om man har Configuration-webbsidan aktiv i webbläsare på flera enheter så uppdateras den nya datan direkt på alla enheter i stort momentant när den sparas via Save-Data knappen. Och om datan även håller på att editeras på en av de andra enheter så skiftas då Save-Data knappen från rött till grönt på den, så man blir uppmärksammad på att det kommit nya data.
Även funktionen att återupprätta en förlorad WebSocket-anslutning fungerar bra som tänkt. Med webbsidan aktiv i webbläsaren slog jag av strömmen till ESP32 och efter en stund försökte webbsidan kontinuerligt upprepat återupprätta anslutningen 1ggr/2s. När jag sedan slog på strömmen till ESP32 och den startat webbservern så återupprättades WebSocket-anslutningen automatiskt igen! Är också en trevlig funktion med väldigt lite kod för.
Från webbläsarens Konsol:
Trying to open a WebSocket connection...
Firefox kan inte upprätta en anslutning till servern på ws://192.168.112.211/wsConfiguration.
WebSocket Connection closed
Trying to open a WebSocket connection...
GET ws://192.168.112.211/wsConfiguration [HTTP/1.1 500 Internal Server Error 109ms]
Firefox kan inte upprätta en anslutning till servern på ws://192.168.112.211/wsConfiguration.
WebSocket Connection closed
Trying to open a WebSocket connection...
WebSocket Connection opened
myObj0: 212
myObj1: 100
myObj2: 50
myObj3: 90
myObj4: true
myObj5: 12.499


2024-02-02
Är intressant och lärorikt det här att utveckla en egen ESP32-batterimonitor!
Att mäta ström som varierar snabbt är inte så enkelt och jag har lagt ned mycket arbete på att få bra precision även för det i min batterimonitors mätningar. Och har fått det bra.
Igår var det fint solväder så solpanelerna i mitt lilla experiment off-grid solcellssystem här hemma producerade förhållandevis bra.
Kom upp till så pass fulladdat att PWM-regulatorn började strypa strömmen och då strömpulsade.
Min PWM-regulator visade då +0,4A från solpanelerna i sin display medan min batterimonitor mätte +1,026A in till blykol-batteriet.
Så PWM-regulatorn mätte ca 60% för lite ström när den själv strömpulsade!
Jag har även sett att min NASA-BM1 batterimonitor i husvagnen mäter strömmen lite fel under sådan strömpulsning.
Så ger ju min ESP32-batterimonitor bättre precision i mätning av batteribankens laddnivå och laddström!
Och jo, jag har på olika sätt validerat att det är min som mäter mest rätt.
Och detta har även betydelse utan PWM-strömpulsande då strömmen varierar en del dynamiskt då också.
T.ex. mäter min ESP32-batterimonitor hela det korta startströmförloppet när kylskåpskompressorn startar med hög precision, samt strömmen lär variera en del med växelriktare i drift, etc.
Min batterimonitor gör 1024mätningar/1,2s normalt (1ggr/1,2ms) samt vid PWM-strömpulsandet 4ggr fler dvs 4096mätningar/1,2s (1ggr/0,3ms) , vilket gör att den kan följa även snabba strömförändringar fint.
Jag har dessutom ett speciellt filter för strömsignalen från strömshunten in till strömsensorn som bidrar till den fina mätprecisionen, vilket jag utvecklat via kraftfull simulering i datorprogram.
Man kan ju undra med vilken precision andra batterimonitorer på marknaden mäter dynamiskt varierande ström?
Den grön lysdioden nere till vänster indikerar att solladdregulatorn begränsar strömmen och batteribanken får max ström den kan ta emot, vilket även visas tydligt i driftsdatan på webbsida:

2024-02-04
Nu har jag fått min "Battery 24hr operational graph" diagram över batteridriften i funktion i min ESP32-batterimonitor :-)
Är inte färdigt ännu, då jag bl.a. visar medelvärdet för varje hel timme nu för datavärdena men ska minska ned till för varje 15:e minut eller kanske varje 10:e minut beroende på hur jag upplever det. Varje hel timme räckte gott till annan driftsstatistik jag beräknar ur dem, men blir lite glest för diagrammet.
Men även de medelvärdena uppdateras hela tiden 1ggr/s så är ju ett levande diagram så ändå.
Och de bygger på ca 3 miljoner mätvärden/hr för varje data för driften så är ju mycket och detaljerad data bakom.
Skal-indelningen till höger för ström/effekt justeras automatiskt för datavärdena under de senaste visade 24hr, och då på ett ingenjörsmässigt sätt så det blir lätt att läsa av kurvorna.

X-axeln visar dygnets tid (hr) i kronologisk ordning och jag har då en vertikal svart linje som markerar aktuell tid i diagrammet. Så till vänster är dagens mätvärden och till höger om den är gårdagens värden. På så sätt kan man väldigt tydligt jämföra driften idag med gårdagens utfall, vilket jag tycker ger tydligt bra info över driften. Blir tydligt här med dagens regnväder mot solsken igår! Jag har inte sett det någon annan stans så är en helt egen idé (men finns säkert).

Att jag kör med medelvärden så för datakurvorna är för att få rena tydliga kurvor som tydligt visar batteridriften, samt är ju så batteribanken påverkas av strömmen.
Jag brukar kalla det för att jag förädlar rådata till information!
Är populärt annars att visa precis alla datavärden helt ofiltrerat för data 1ggr/min eller t.o.m. 1ggr/s vilket i mitt tycke ger en rörig otydlig svårtolkad info över driften.
Har funderingar på att senare komplettera med max/min-skuggning till ett par av diagramkurvorna för att visa hur mycket datavärdena varierat, men prioriterar inte det nu.
Har dock redan nu max/min-datavärden sparade för visning på annan webbsida över driften.
Är bara så häftigt att få till visualisering av off-grid batteridriften så som jag önskar, som ger en bara så bra översikt över min solcellsdrift:

2024-02-04
Nu har jag ändra från medelvärde per hr till per 10min och det tog knapp 20min kodfixande att göra det och fungerade direkt - är bara så bra med riktigt välstrukturerad tydligt C++ kodande.
Är en sorts löpande 10min medelvärde som visas, så datakurvorna är hela tiden levande och responsiva uppdaterade 1ggr/1,2s! Och varje sådant 10min medelvärde består av ca 512.000 mätningar för var datakurva, så är bra dataunderlag!
Så provkör detta nu. Skickar då ca 600st mätvärden för senaste 24hr drift via Websocket från ESP32 webbservern till webbsidan i webbläsaren (580st float-mätdata + lite styrdata)!
Och det segar inte utan går snabbt samt ser bra ut!
Har alltid senaste 24hr driftsdata i ESP32, så direkt man öppnar diagram-webbsidan så visas kompletta datakurvor för senaste 24hr!
Efter att ha brottats med SSE-skickade data länge så är detta imponerande!
Så nu visar jag diagrammet med medelvärden för var 10:e minut under 24hr för de 4 data­kurv­orna! Är rätt imponerande att ESP32 med webbserver kan hantera detta så bra!
Ska lägga in en linje som visar när synkning till 100% SoC fulladdat har skett under visade 24hr, samt en indikering under vilka tider PWM-regulatorn begränsat laddströmmen s.k. PV-Throttle.
Har även fixat en extremt sällsynt FreeRTOS race condition som försöker göra två eller flera anslutningar simultant till WiFi och då får WiFi-anslutningen att hänga sig och meddela att där inte finns något WiFi-kort som då kräver reset, WiFiRaceCondBlock.

2024-02-05
Nu är mitt diagram "Battery 24hr operational graph" i min ESP32-batterimonitor produktionsfärdig för skarp drift.
Är fixat så det nu visar medelvärdet för var 10 minuters period mot tidigare var timmes period, så blir lite mer levande diagram nu.
Känns som en sweet-spot mellan hur mycket RAM-minne det tar i ESP32 för all 24h datan, hur mycket data som ska skickas mellan ESP32 och webbsidan när den klickas upp i webbläsaren (nu med 10-minuters intervall ca 600 datavärden som skickas från ESP32 via Websocket till webbsidan) samt balansen mellan lugna stabila datakurvor med tillräcklig detalj och respons på förändrade värden.

Diagrammet är levande och uppdateras hela tiden ca 1ggr/s med nya data för kurvorna skickade via Websocket från ESP32, efterhand som de olika beräknade medelvärdena förändras av ny indata. Samt ESP32 håller alltid senaste 24hr driftsdata, så diagrammet är komplett med 24hr datakurvor så fort webbsidan öppnas!
Även om man inte ser snabba strömspikar med 10-minuters medelvärden så är data för dem med och påverkar medelvärdena så kommer med i diagramkurvorna ändå med de ca 500.000 mätningar av data som underlag för varje sådant 10 minuters medelvärde!

Är bara några små finputsningar till att göra men i princip färdigt.
Här ett diagram över 24 timmar med först varierande molnslöjor med solsken mellan 11:30 till 13:30, sedan lite kraftigare solsken där laddningen kom upp i aktivt reglerad float-laddning (13,8V) under ca 1h. Därefter började solen gå ned.
Att dagens senaste datavärden möts med gårdagens för samma tid på ömse sidor om tidslinjen gör det lätt att se förändringar under senaste 24hr, som nu SOC-laddnivån som ökat något lite här.
När det blivit en 100% SOC synkning under de 24 timmarna så kommer dess tidpunkt markeras med en streckad vertikal linje i diagrammet.
(Att spänningskurvan (blå) rör sig i tydliga steg beror på att jag av misstag bara fått med en decimal mot tänkta två för spänningsvärdena när de skickas till webbsidan, men är fixat nu.)

2024-02-07
Det här blir riktigt trevligt i skarp drift i mitt riktiga off-grid solcellssystem!
Här från senaste 24h drift i mitt lilla experiment off-grid solcellssystem, med fixad upplösning för spänningskurvan (blå) så även den nu varier kontinuerligt jämnt:

2024-02-06
Idag blev batteriet helt fulladdat och ESP32-batterimonitorn synkade 100% SoC mot batteriet. Nu har enda urladdningen varit strömförbrukningen för batterimonitorn, PWM-regulatorn och två Battery Reconditioner ihop, så väldigt små strömmar. Så när batterimonitorn detekterade 100% SoC via tail-current vid aktiv float-laddning (PV Throttle) så var det fortfarande någon Ah kvar att återladda enligt mätningarna. Det beror på svårigheter att mäta strömförbrukningen korrekt från den Battery Reconditioner som strömpulsar i 9kHz med superkorta strömpulser motsvarande 1MHz och som utgör den största strömförbrukaren såhär.
Felet motsvarade ca 5mA mätfel under de 20 dygn som gått sedan senaste fulladdat med totalt -12,7Ah cyklad urladdning och 94,9% SoC som lägst av 90Ah, så ändå rätt obetydligt samt verkar rimligt. Nu för experiment off-grid solcellssystemet här hemma har jag att detta mäts ihop med batteriverkningsgrad även vid väldigt grunda urladdningar mot annars minst 10% DoD urladdning för sådan mätning. Så i husvagnens off-grid solcellssystem ger detta helt försumbar inverkan under drift vid aktivt boende där, samt kommer troligen minska med INA226 placerad närmre ström­shunten med korta ledningar.
Kan även jämföras med Victrons BMV-712 / SmartShunt som har en Current threshold på 0,1A som fabriksinställning, dvs den mäter inte inom ±100mA ström, 20ggr större fel än detta!

2024-02-10
Njuter av det fina diagrammet över driften jag fått till :-)
Fixar några småsaker till i diagram-presentationen så är jag riktigt nöjd sedan!
Känns som dessa 10 minuters medelvärden kurvorna ritas utifrån är riktigt bra för att visa driften tydligt! Och att ändå varje sådan 10 minuters punkt är medelvärdet av ca 500.000 mätningar, så riktigt bra dataunderlag där även minsta strömspik är med i medelvärdet.
Och att senaste pågående medelvärdena uppdateras 1ggr/1,2s med en sorts löpande 10 minuters medelvärde så diagrammet är levande hela tiden att titta på.
Ger en tydligare bild av batteribankens drift än med datakurvor ritade utifrån helt ofiltrerad data!
Korta strömspikar påverkar inte laddnivån i batteribanken, men detta visar det som verkligen påverkar laddnivån samtidigt som datakurvorna blir rena, lugna och tydliga.

2024-02-11
RISE Research Institutes of Sweden:
"Visualiseringar gör att alla kan förstå behov och utmaningar lättare."
"Tillgången på data har ökar snabbt i industrin – och ännu mer blir det i spåren av IoT, sensorer och utbudet av externa data som allt enklare kan integreras i systemen. Men hur kan datan användas till att förbättra processer, förhindra problem, fatta rätt beslut och använda personal och utrustning effektivare? Det är där visualiseringar blir helt avgörande."
RISE: Sju skäl att visualisera data:
"1. Visualiseringar tar sig in i hjärnan blixtsnabbt:
– Våra hjärnor är gjorda för att snabbt se mönster visuellt. Att tolka rådata i Excel tar mycket längre tid, oavsett om datat kommer i form av siffror eller text. Det är också svårt att få överblick – man kan gå igenom siffror i ett kalkylark i timmar och ändå inte få en bra förståelse för hur de hänger ihop. Det här är något som datavisualisering kan ge en omedelbar bild av, där man direkt förstår inte bara siffrorna utan hur de förhåller sig till annat data. Det är så man får verkliga insikter, säger Kristina Knaving."
"4. Visualiseringar är mer inkluderande." Typ hela familjen!
"6. Visualiseringar kan visa trender."
Lite det jag gör i ESP32-batterimonitorn för off-grid driften och inte bara visar rå-data :-)
Med min ESP32-batterimonitors drygt 50.000 mätningar/minut rå-data måste all den datan bearbetas för att bli överskådlig, dvs omvandlas till information och visualiseras!

2024-02-12
Här ser man tydligt nyttan med strömsparläget med 99% av tiden i ESP32 light-sleep!
Under natten fram till 06:30 är det strömsparläge, sedan aktiverar jag ESP32 WiFi + webbserver och tar upp webbsidan med detta diagrammet i mobilens webbläsare mellan 06:30-07:30, och sedan flera gånger under den gråmulna dagen samt igår eftermiddag / kväll:

2024-02-13
Lät ESP32-batterimonitorn arbeta helt orörd under dagen utan att aktivera WiFi + webbserver och titta på data-diagrammet, för att få fram hur den då visar driftskurvorna ostört.
Ger en väldigt tydligt bild över driften, i kontrast till exemplet nedanför från Victrons VRM portal som ger en helt annan otydlig bild av driften med sin nervösa rådata samt val av skalindelning. Tar med referens även från den andra stora Europeiska tillverkaren Studer Innotec.
Jag har läst mycket om gränssnittsdesign (GUI), Human-Machine Interface (HMI) / Dashboard och datavisualisering av större datamängder, så är den kunskapen jag tillämpar här!

2024-02-15
Har lagt in max/min-skuggning (max/min shading) för batterispänningens och strömmens kurvor i diagrammet, så man ser hur mycket dessa har varierat inom varje 10min intervall.
Nu kör jag fortfarande passiv standby vinterdrift här hemma i mitt lilla off-grid solcellssystem, så är inga strömbelastningar som ger någon synbar max/min-shading för batterispänningen.
Tycker man får det bästa av två världar på så sätt, med en lugn tydlig medelvärdesbaserad kurva med skuggningen som visar variationen inom var 10min-segment.
Intressant att se här hur mycket solcellsströmmen varierade mellan 12:30 och 14:00!
Varje Max/Min värde mäts som medelvärdet av 1024 mätningar under 1,2s så helt irrelevanta korta spikar filtreras bort även där, samt varje datapunkt för Max/Min i diagrammet är för en 10min-period med Max/Min av ca 500 sådana Max/Min värden. Och kurvlinjerna representerar medelvädet för varje 10min-period av ca 500.000 mätvärden. Så är kraftfullt dataunderlag!
Ska bli intressant att senare se hur pass spänningsstyva mina AGM-blykol batterier är i min riktiga off-grid solcellsdrift med sin gamla 12V-kylkompressors intermittenta drift!

2024-02-16
Yes, nu är all funktionalitet i "Battery 24hr operational graph" diagrammet testad och verifierad!
"PV-Throttle" visar när regulatorn begränsar solcellsströmmen för att inte överladda batterierna, här mellan 12:00 och 15:30, samt "Sync 100% SoC" visar när batterimonitorns senaste synkning av sin 100% SoC skett mot fulladdat batteri under denna 24hr period, här vid ca 18:15.
Nu laddade jag även från labaggregatet för att förbereda blykol-batteriet att kunna hinna göra en för detta off-grid solcellssystemet naturlig sådan här laddcykel i morgondagens solväder. Och det gjorde att 100% SoC sykningen skedde med en av två reservmetoder då batteriet lämnar fulladdat tillstånd. Huvudmetoden för synkning är via Tailcurrent då batteribanken precis blir 100% SoC fulladdad, vilket krävs för att kunna beräkna batteriverkningsgrad med bra precision.
Och då fortgår 100% SoC synkningen tills Tailcurrent-villkoret upphör, vilket är tidpunkten som visas här i diagrammet då som "Sync 100% SoC".
Intressant även att när jag ökade laddspänningen från 13,8V float till 14,2V absorption så ökade laddströmmen väldigt lite, vilket nog är en typisk egenskap för AGM-blykol batterier vid så hög SoC som ca 98% här. Men är då laddning utan strömpulsning från labaggregatet!

2024-02-17
Nu är det färdiga "Battery 24hr operational graph" diagrammet testat med en 24hr cykel med enbart solcellsström under en solig dag, och det ser riktigt trevligt ut precis som tänkt!
När jag här strax efter kl.21 går in och tittar på dagens batteridrift i off-grid solcellssystemet får jag en tydlig bra bild av den tycker jag! Så blir trevligt med detta framöver nu i mitt off-grid.
Skriver även ut siffervärdena för senaste plottade datapunkterna i diagrammets nedre marginal.
Känns som en bra kombination med diagramkurvor plottade från 10min medelvärden samt max/min-skuggning som visar hur ström och spänning varierat inom de 10min-intervallerna.
Blir tydliga data-kurvlinjer samt max-min-plottning som visar driften riktigt bra med dessa statistiskt bearbetade rådata, istället för hysteriskt varierande kurvlinjer direkt från rådata!
Runt kl.15:00 kan man se en hel del max/min-strömvariation men ser man på den plottade röda linjen för medelvärdena så har den påverkats minimalt ändå, och är det som utgör batteriladdningen. Visar även att solladdregulatorn hanterar dessa korta variationer i solinstrålning från molntussar väldigt bra. Strax efter kl.16 försvinner den låga vintersolen bakom ett höghus.
Blev drygt 3h PV-Throttle kl.13-16:20, dvs att solladdregulatorn begränsade solcellsströmmen för att undvika överladdning av batteriet. Och samtidigt med att PV-Throttlingen upphörde så avslutades synkning av 100% SoC mot fulladdat batteri, som indikeras med vertikal lila punktlinje.
Och då den svarta grövre vertikala linjen som indikerar aktuell tid.
Då är detta diagrammet helt färdigt kod- och funktions-mässigt, förutom en liten justering av den blå max/min-skuggningen för spänningen som får göras lite mörkare för bättre synlighet.
Känner mig riktigt nöjd och det gick att göra precis som den målbild / vision jag haft!
Att jämföra sig med konkurrenter, Benchmarking (konkurrentanalys), är en integrerad del i produktutvecklingsprocessen vid kommersiell utveckling, men även intressant vid sådana här pensionärs-hobbyprojekt, därav att jag jämför mig med de marknadsledande inom off-grid solcellsteknik i Europa Studer Innotec och Victron Energy! Och jag tycker mitt hävdar sig bra!
Nästa steg bli att ansluta en till strömsensor för mätning av solcellsströmmen och koppla ihop dess data med en färdigkodad grafik jag redan har.

2024-02-19
I dagens mulna väder blev max/min-skuggningen till diagrammets röda strömkurva extra tydlig och fin! Som ett skolboksexempel. Strömvariationen kommer här främst ifrån de två Battery Reconditioner´s strömpulsande, där man även ser hur de minskar sin frekvens när batterispänningen sjunker som syns på medelströmmens kurva mellan kl.04:00 och 07:30.
De lite glesa djupare strömdipparna är när ESP32 kopplar upp sig mot WiFi och Internet och synkar realtidsklockan mot en tidsserver samt därefter visar diagram-webbsidan på datorn. Då går dels ESP32 ur strömsparläget, dels drar WiFi och webbservern lite ström.

2024-02-21
Fixat den förhoppningsvis sista syllsynta FreeRTOS race condition där via tryckknapp 1 aktivering av WiFi / Webbserver riskerar att ske medans fortfarande i Light-Sleep strömsparläge, och då hänger sig WiFi och kräver en hård reset för kunna aktiveras igen. Nu testat hela dagen och verkligen försökt provocera fram detta normalt sällsynta genom att trycka på tryckknapp 1 precis när LED blinkar för avläsning av ström från INA226 i strömsparläge. Är då den har hängt sig tidigare väldigt glest, men inget alls idag ännu. Men krävs några veckors testande.
Är det sista jag sett nu som kunnat äventyra en helt stabil 24/7/365-drift.
Sedan får ju en riktigt lång skarp drift i mitt off-grid solcellssystem bekräfta det!

2024-02-28
Nu har jag bytt från SSE (Server-Sent Events) till WebSocket för dataöverföringen till webbsidan "Operational data" (Main Dashboard), som en förberedelse att koppla in en INA260-strömsensor för solcellsströmmen samt en temperaturgivare för batteriet. WebSocket är så mycket effektivare och trevligare att arbeta med än SSE samt i denna webbservern ESP­Async­Web­Server-esphome hanterar WebSocket mycket större datamängder smidigt och stabilt. Sedan ger WebSocket möjlighet till tvåvägskommunikation också.
Nästa steg är att ta nuvarande hårdvaran från BreadBoard till att löda in på experimentkort, för att ge plats för INA260 på mitt BreadBoard. Och därefter koppla in och koda för INA260!

2024-03-04
Njuter under tiden av den fina visualiseringen av min off-grid solcells batteridrift!
Fick en perfekt soldag för att visa all funktionalitet tydligt i mitt dashboard-diagram "Battery 24hr operational graph", lite som man skulle ha gjort laboratoriemässigt för att få fram det.
Här visas 4st datakurvlinjer, spänningens och strömmens max/min-skuggning, PV-Throttle samt "Sync 100% SoC" väldigt tydligt plottade utifrån statistiska 10-minuters medelvärden samt max/min för varje 10min intervall. Rådata bearbetad till information. Både under pågående "Sync 100% SoC" samt efteråt samt både vid laddning och urladdning av blykolbatteriet.
Max/min-skuggning är en väletablerad teknik samt att låta 0,5% (0,005C) Tail-current under pågående aktiv spänningsreglerad batteriladdning (PV-Throttle) indikerar 100% SoC fulladdat blybatteri är också väletablerad teknisk kunskap, här 450mA Tail-current för mitt 90Ah blykol.
Visar hela senaste 24h driftsperioden, med dagens data till vänster om den vertikala svarta tidslinjen, och gårdagens till höger om så blir lätt att jämföra vid aktuell tidslinje.
Ger ihop en tydlig bra bild av off-grid solcellssystemets senaste 24h batteridrift tycker jag.
Som den stora strömvariationen från molntussar mellan kl.12-15, sedan mer stabilt solsken.
I första bilden ser man att Tail-current kommit ned till 320mA, så är robusta 40% marginaler mot gränsen 450mA för 100% SoC indikering! Var liknande för mina 9år gamla blybatterier.
Ger en väldigt exakt, robust och stabil synkning av 100% SoC mot fulladdade batterier!
Att göra det utifrån enbart batterispänning och Tail-current går aldrig att få robust och exakt!
Är bara en tillämpning av väletablerade tekniska kunskaper för visad driftdata i diagrammet!
Om det inte skett en "Sync 100% SoC" inom senaste 24h så har jag tiden till senaste sådan angivet på en annan webbsida, men tycker det ger bra info att även ha med i 24h-diagrammet.
Inledde härmed också årets säsong med all mobil-laddning från mitt lilla off-grid solcellssystem.
Ska senare göra ett motsvarande diagram som visar hela off-grid solcellssystemets 24h drift.
Samt jobbar nu på intressant grafik för tydlig visualisering av pågående aktuell off-grid drift.

Jämför man med diagrammet nedan som är lite av branschstandard inom marknaden för off-grid solcellssystem där datakurvorna växlar frenetiskt plottade från rådata, så ser man hur mycket svårare det är att läsa ut information ur det! Datakurvlinjerna trasslar in sig i varandra och blir svårt att avgöra medelvärdena samt svårt med mer än två kurvor i samma diagram.
Med mina datakurvlinjer plottade från statistiskt bearbetad data kan jag visa fyra sådana i samma diagram och de syns tydligt ändå samt ger bra information som verkligen visar batteridriften tydligt! En ingenjörsmässig skalning i mitt diagram gör det också lätt att läsa av data ur det.
Jag är maskiningenjör men har utvecklat mycket mekatroniska system, så är min yrkeskunskap och erfarenhet från det jag nu utnyttjar i mitt pensionärs hobbyprojekt här med batterimonitor.

2024-03-14
Fick frågan om strömförbrukningen för min ESP32-batterimonitor, så skrev ihop:
ESP32 inkl. INA226 strömsensorn och nattbelyst LCD-teckendisplay drar ca 6mA från 12,5V i aktiv grunddrift när den samplar aktivt 500.000ggr/10min. Jobbar då i ett strömsparläge. Strömsensorn arbetar självständigt strömsnålt och tar kontinuerligt 1024st samplingar som den medelvärdesbildar, sparar i buffert och sätter interrupt-flag till ESP32 var gång det är klart, så ESP32 hämtar bara den mätdatan 1ggr för var 1024:e sampling. Under tiden kan ESP32 vara i light-sleep när jag har den i strömsparläge, vilket blir ca 99% av tiden i light-sleep då.
Vid lite högre strömmar går den ur strömsparläget och då drar den ca 25mA från 12,5V. Om jag minns rätt är gränsen ±150mA när den går ur strömsparläget.
Med även aktiv WiFi och webbserver och kontinuerlig WebSocket-data skickade till webbsida i webbläsare drar den ca 35mA från 12,5V.
Jag ska senare titta på att variera klockfrekvensen för ESP32 (görs direkt i C++ koden), så jag rampar upp prestanda / strömförbrukning när jag går ur strömsparläget med light-sleep, så det inte blir vid en fast strömgräns på ±150mA som nu. Ska se om jag kan få till då att batterimonitorns strömförbrukning är <1/10-del av aktuell batteriström som max.
Har även under flera dagar haft diagrammet nedan öppet i annan webbläsare med aktiv WebSocket under många timmar nu medan jag arbetat framför datorn i annan webbäsaren, och inte noterat att WiFi kopplat ifrån en enda gång! Men har funktioner för återanslutning både för WiFi och WebSocket, så kan ju skett kortvarigt utan att jag sett det. Så ska lägga in räknare i WiFiReconnect() funktionen så jag kan följa upp om det sker.

2024-03-18
Nu har vårsolen för off-grid solcellssystemet kommit på riktigt här i Östergötland, med ca 5h PV-Throttle idag dvs att solladdregulatorn begränsar strömmen från solpanelerna för att hålla den reglerade 13,8V float-laddspänningen korrekt. Min PWM-regulator startar en ny laddcykel med bulk-, absorption-, float-laddning första när batterispänningen kommit under 12,3V, så fram till dess ligger den kvar i float-laddning som är skonsamt för blybatterierna.
Mina solpaneler här hemma står i SydVäst-läge så kl.10:30 lyser solen parallellt med fönstret, sedan början den långsamt lysa mer och mer in genom fönstret mot solpanelerna fram till lite innan 17-tiden, då den såhär års försvinner bakom ett höghus så solcellsströmmen snabbt minskar då.
PV-Throttel innebär att PWM-regulatorn då strömpulsar laddningen, vilket gör att blybatteriet blir verkligen 100,0% SoC fulladdat! Det syns på att Tail-current kom ned till 200mA jämfört med de 450mA (0,5% / 0,005C av 90Ah) som här utgör gräns för detektering av fulladdat blybatteri i min ESP32-batterimonitor.
Med en MPPT-regulators kontinuerliga float-laddström tar det nästan oändlig tid att nå 100,0% SoC fulladdat för blybatterier!
Så då har jag 450mA / 200mA = 2,25ggr marginal mot att säkert kunna detektera fulladdat blybatteri för 100% SoC synkning i batterimonitorn. Ger en stabil robust funktion för det!
Innebär att den välkända tekniska kunskap som finns om 0,5% Tail-current för 100% SoC detektering under PV-Throttle stämmer väldigt bra med verkligheten :-)
Med 0,5% Tail-current under PV-Throttle för detektering av fulladdat blybatteri fås en väldigt exakt och fint repeterbar funktion för det, vilket ger mycket bra precision åt batterimonitorn.
Räknat på de loggade datavärdena här ger dessa 0,5% Tail-current en detektering av fulladdat blybatteri vid drygt 99% SoC, vilket är extremt bra precision då lite marginal alltid behövs.
Med den långa PV-Throttle tiden här idag bör det då blivit minst 99,9% SoC i blybatteriet för 100% SoC synkningen, eftersom Tail-current planar ut på strax under 200mA.

2024-03-20
Har gjort en större code-refactoring på WiFi-anslutningen, där jag haft både gammal och ny kod som inte blivit så optimalt. Är första Arduino/ESP32 projektet jag kodar med FreeRTOS så har lärt mig mycket under vägen nu och utnyttjar FreeRTOS möjligheter betydligt bättre nu i kodandet. Använder bl.a. Inter-task Communication mer flitigt nu för bra effektiv kodexekvering.
Blev både mycket tydligare kod att läsa och förstå, samt förbättrade även funktionen. Anslutningen till 4G-routerns WiFi går signifikant snabbare nu, så kodfunktionen måste ha blivit märkbart bättre såhär nu! Jag har verkligen utvecklas i att koda med FreeRTOS.
På köpet använder programkoden något lite mindre RAM nu, nog för att jag fört över kod i ett par olika egna funktioner men även att köande sker i en meddelandekö till en Task istället för en i RAM inladdad funktion. Är något jag senare ska göra mer av i hela min programkod.
Speciellt ska jag verifiera om det gör skillnad att lyfta ut koden från Task´s så i egna funktioner!
Jag utnyttjar kodbiblioteket WiFiMulti så kan jag ha alla de WiFi-källor som är aktuella för mig definierade samtidigt med SSID i min kod, förutom övrig bra smidig funktion.
2024-03-25
Gjort lite ytterligare code-refactoring på WiFi-anslutningen på delen med synkning av datum/tid mot NTP Client-Server. Fick lite snabbare och bättre tidssynkning där också.
Samt gjort om koden så den nu inte ansluter mot WiFi och NTP under setup() utan man får aktivera det sjäv manuellt via tryckknapp 1, för smidigare inkoppling av ESP32-batterimonitorn i det elektriska systemet.
Samt fortsätter att njuta av mitt diagram över batteridriften, där man här ser att SoC-laddnivån slutade på samma vid 19:15-tiden, så ur- / upp-laddning tog precis ut varandra under dygnet:

2024-04-07
Dels kodat så vid uppkoppling mot WiFi via WiFiMulti() så görs upprepade försök i en loop under lite längre tid tills success, så 4G-routern får tid att starta upp då det är aktuellt. Som förberedelse till att ESP32-batterimonitorn ska kunna slå på strömmen till 4G-routern, skicka data till webbsida på webbhotell samt sedan stänga ned 4G-routern igen.
Dels förbättrat stabiliteten för WebSocket genom att ws.text() / ws.textAll() skickande av data till webbsidorna nu villkoras med ws.availableForWrite() / ws.availableForWriteAll() som internt i AsyncWebSocket.cpp checkar om queueIsFull(). Så inte dess buffert överskrids!
Syntes resultat även vid normal drift då ESP.getMinFreeHeap() gav lite mer fritt lägsta RAM mot innan vid webb­sides­blädd­ran­de på två olika enheter (mobil+dator), så WebSocket funktionen verkar stabilare såhär. Ws.text() / ws.textAll() verkar inte stressa bufferten lika mycket nu!
Är ett väldigt letande i kodbiblioteken för att hitta alla möjligheter där, som detta, då det inte är med i de enklare kodexemplen på Internet!

Hade en incident som gav ESP_RST_PANIC så ESP32 botade om, då WebSocket stressades av att ESP32 hade svårt att nå bra kontak via WiFi och jag upprepade gånger startade om webbsidan så WebSocket stressades att skicka data upprepade gånger fast det då var svårt att få fram den! Men då fungerade det jag kodat / byggt så den SoftReset som ESP_RST_PANIC ger upphov till omvandlades till en HardReset typ PowerOn med sparande av viktig data dessförinnan, så skoj att fått det testat också. Så resulterade bara i ett minimalt avbrott i dataloggningen då, helt utan betydelse för precisionen i mätningen av batteribankens laddnivå!

I WiFiMulti.cpp tog jag även bort den sista else{} paragrafen där det görs en WiFi.scanNetworks(true); som är en asynkron scanning om den första synkrona misslyckas, vars resultat aldrig används så känns som en sorts bug. I vart fall stör den när man själv efter att WiFiMulti.cpp misslyckats med att ansluta till WiFi gör upprepade anrop till WiFiMulti.cpp via WiFiMulti::run() för att få till en WiFi-anslutning!

Även lagt tid på att välja mer optimala färger på datakurvlinjerna samt ljusare bakgrund i "Battery 24hr operational graph" för lättare tydligare avläsning på olika enheters skärmar.
Samt även blivit lite code-refactoring där jag varit inne och rotat i koden, så dess funktion och tydlighet hela tiden förfinas. Så börjar kännas riktigt bra nu!
Utöver denna lite självförvållade incidenten (som härmed bör vara förebyggd) har ESP32-batt­eri­moni­torn nu arbeta 100% 24/7-stabilt i flera veckor, trots mina stresstester av den med ständigt aktiverande av WiFi / ESP32-webbserver och bläddrande bland dess webbsidor!

Ska nu koncentera mig på att skapa riktig tennlödd hårdvara i kapsling för det jag hittills har gjort och sedan inkludera en INA260 för strömmätning av strömmen från solcellerna.
I diagrammet syns att de mörkgrå molnen med små klarblå luckor som snabbt drev fram över himmeln gav stor variation i solcellsström mellan kl.14-16, som följdes av klarblå himmel. Strömmen varierade då 10-15ggr på mindre än en sekund, typ från 1A till 10-15A på <1s! Då krävs att batterimonitorn är konstruerad för att mäta så snabbt varierande dynamisk ström för att mäta laddnivån för batteribanken korrekt, som min ESP32-batterimonitor som samplar mätvärdena drygt 50.000ggr/min ihop med noga utvecklat ingångsfilter för strömsignalen!

2024-04-14
ESP32 WiFi med 2,4GHz kan ibland störas ut när det här i lägenheten är 10st WiFi-routers samtidigt som WiFiMulti.run() detekterar via WiFi.scanNetworks(). Just 2,4GHz är lite extra känsligt för det.
Så jag låter min programkod göra upprepade försök under 180s att via WiFiMulti.run() koppla upp mot min 4G-routers WiFi, vilket dock är svårt att simulera och testa att det fungerar bra.
Men igår och idag har det blivit tre gånger som det krävts flera försök och de två gångerna igår fungerade det bra på 4:e försöket men idag blev det åter returvärdet WL_NO_SSID_AVAIL som innebär att WiFi.scanNetworks() redan kör. Har då haft vTaskDelay() 500ms mellan försöken så ökar den nu till 1000ms. Hade tidigare 50ms och då blev det WL_NO_SSID_AVAIL varje gång första anslutningen misslyckades. Krävs tydligen lite "settling time"!
Även de svårigheter / seghet det kan ge för WebSocket kommunikation så fungerar ändå den stabilt och bra och återansluter fint automatiskt när den då tappar kontakten, samt villkorandet med ws.availableForWrite() / ws.availableForWriteAll() gör att det blir inga minnes- eller buffert-problem heller då som ger kodkrasch.

2024-04-15
I 180s loopen med WiFiMulti.run() som väntar in WiFi från 4G-routern lagt in följande:
if (ReturnValue == WL_NO_SSID_AVAIL)
{
  vTaskDelay(5000 / portTICK_PERIOD_MS); // Settling time to WiFiMulti.run
}
Där WL_NO_SSID_AVAIL är felkoden WIFI_SCAN_RUNNING from WiFi.scanNetworks() i WiFiMulti.cpp.
Tiden får utvisa om 5000ms Settling-time är tillräckligt här eller om den behöver ökas.
Idag vid 19-tiden blev det en WiFi-anslutning som gick via WL_NO_SSID_AVAIL på 3:e försöket och sedan på 4:e försöket anslöt fint till WiFi, så där fungerade det med 5000ms Settling-time!
Senare på kvällen blev det liknande en gång till, så ser ut som att 5000ms Settling-time är OK här! För övriga felkoder är det 1000ms vTaskDelay(), så totalt då 6000ms.

2024-04-16
Idag gick den igenom WL_DISCONNECTED, WL_IDLE_STATUS, WL_NO_SSID_AVAIL innan det på 7:e försöket blev WL_CONNECTED, så känns rätt säkert att 5000ms Settling-time är OK!
Och ytterligare en gång liknande där den kopplade upp på 6:e försöket, så fungerar bra nu!
Samt även någon timme innan med bara 2st WL_DISCONNECTED och på 3:e försöket WL_CONNECTED.
Då verkar den funktionen för robust drift ihop med 4G-modem löst! Ytterligare ett steg mot slutlig funktion och drift.
Har justerat till 1500ms vTaskDelay() för alla returvärden utom WL_NO_SSID_AVAIL som nu har 1500ms + 4500ms, då 1000ms verkade lite snålt för bra funktion.
Fungerade bra med anslutning vid 3:e försöket när det inträffade idag 2024-04-20!
2024-04-24 Har nu sett fin stabil funktion flera gånger vid upprepade anslutningförsök med färre WL_NO_SSID_AVAIL, så blev bra med 1500ms + 4500ms Settling-time för WiFiMulti.run()!
Varför löpande uppmätt verkligt batteriverkningsgrad är så centralt:
I September under 7 dygns fricampingtur blev det kumulativt PSoC-cyklat -213,1Ah pendlande mellan ca 95% SoC och lägst 71% SoC (-61,5Ah absolut) ur min 212Ah batteribank med uppmätt batteri­verk­nings­grad 97,8%(Ah), mätt av min batterimonitor. Då med ett fel i batter­iverk­nings­grad på 5% av -213,1Ah = -10,7Ah vid i snitt 83% SoC (-36Ah absolut) så fås -10,7Ah / -36Ah = 0,30 dvs 30% mätfel i SoC efter bara 7 dygns PSoC-cykling!
Så redan bara 2,5%-enheters feluppskattad batteri­verk­nings­grad skulle då motsvarande gett 15% mätfel i SoC för dessa 7 dygns PSoC-cykling!
Och 7 dygns PSoC-drift är ändå inte så lång tid, så batteri­verk­nings­graden är central i SoC-beräkningarna! Bör klara minst 14 dygns PSoC-cyklingsdrift med bra precison och upp mot en månad med rimlig precsion är min målsättning.
SoC-beräkningen baseras på skillnaden mellan den kumulativa urladdningen / iladdningen fram till nästa 100% SoC synkning och då avgör batteri­verk­nings­graden hur mycket av den kumulativa iladdningen som blir räknat som laddning i batterikemin och hur mycket som blir borträknat som förlust, och beräknas förlusten fel ger det stor inverkan!
Vid många dygns PSoC-cyklande blir skillnaden mellan kumulativ och absolut urladdning snabbt väldigt stor så även små fel i förlustberäkningen ger stor inverkan på beräknad SoC!
Som flera olika säljföretag skriver så variera batteri­verk­nings­graden mycket för traditionella blybatterier beroende på driften de utsätts för, så där är det helt avgörande att bygga SoC-beräkningarna på löpande uppmätt verklig batteri­verk­nings­grad, men även med LiFePO4 fås lätt >2,5%-enheters fel i en manuellt angiven batteri­verk­nings­grad:
"I flera applikationer (särskilt icke nätanslutna solcells och/eller vindanläggningar) kan [batteri] energiverkningsgrad vara av avgörande betydelse.
Tur och retur verkningsgrad (urladdning från 100% till 0% och tillbaka till 100% laddning) hos det genomsnittliga bly-syra batteriet är 80%.
Motsvarande för ett LFP batteri är 92%.
Laddningsprocessen hos bly-syra batterier blir särskilt ineffektivt när 80% laddningstillståndet har uppnåtts, vilket resulterar i 50% effektivitet eller till och med mindre i solcellssystem där flera dagars reservenergi krävs (batteritid i 70% till 100% laddat tillstånd).
Däremot kommer ett LFP batteri fortfarande att uppnå 90% verkningsgrad under ytliga urladdningsförhållanden."
Det sista är även intressant då min ESP32-batterimonitor med hög precision mätt upp 97,8%(Ah) / 92,4%(Wh) batteri­verk­nings­grad för mina AGM-blykol cyklat inom 71%-95% SoC!

2024-04-17
Hade turen att titta på datan över ESP32 RAM-minnes­ut­nytt­jan­det då WebSocket-data­över­för­ing­en till "Battery 24hr operational graph"-webbsidan stördes ut en längre stund av de 9 andra 2,4GHz WiFi-routers från grannarna, och då användes 10-12kB av det fria RAM-minnet innan ws.availableForWrite() / ws.availableForWriteAll() slog till bromsarna. Och när WebSocket-kom­munika­tion­en kom igång igen så återlämnades det RAM-minnet.
Trevligt att få chans att se hur bra, robust och verkningsfullt det fungerar att villkora WebSocket-kom­munika­tion­en med ws.availableForWrite() / ws.availableForWriteAll()!
Så gissningsvis kan man räkna med att WebSocket-data­över­för­ing­en använder max 15kB av RAM då när ws.availableForWrite() / ws.availableForWriteAll() bli falska, vilket känns rimligt.

2024-04-24
Robust driftsäkerhet via funktionalitet i programkoden:
Jag kodar en del funktionalitet i ESP32 C++ koden som bara är till för att ge en ökad robusthet i exekveringen / driften. Både aktiv och passiv sådan, där vissa delar i driften övervakas och andra kritiska händelser undviks. Som vissa kritiska passager i koden kan man skydda mot risk för s.k. race-condition, samt sådant som RAM-minne, minnesfragmentering och strömsensorns funktion via I2C m.m. kan övervakas och göras aktiva åtgärder mot om det blir kritiskt där.
Har verifierat att det bidrar till en mer robust stabil 24/7/365-drift av ESP32 kodexekveringen!

Har nu gjort signifikanta framsteg där i hanteringen av WiFi-anslutningen samt WebSocket datakommunikationen. Så dels fungerar de stabilt nu med att kunna hantera rätt grova störningar de övriga ofta 9st 2,4GHz WiFi-nätverken från grannarna här i lägenheten kan orsaka glest.
Dels när ESP32 ska ansluta till WiFi-nätverket kan den nu upprepat stabilt försöka det under rätt lång tid tills lyckad uppkoppling. Samt WebSocket datakommunikationen mellan ESP32-webbservern och webbsidan i webbläsaren kan webbsidan själv automatiskt återansluta om den förloras, vilket är bra om jag är i utkanten av täckningsområdet för WiFi eller den störs ut av andra WiFi-nätverk eller kanske åskoväder.
Är en viktig funktion då ESP32-batterimonitorn vintertid ska kunna stänga ned 4G-routern för extremt strömsnål drift och bara starta den glest för dataöverföring till webbservern. Görs då adaptivt efter hur solcellerna i vintermörkret klarar laddningen av batterierna.

Espressifs ESP32 har 8kB+8kB RAM-minne i realtidsklockan (RTC) där den ena 8kB SRAM (RTC Slow Memory) bibehåller sitt innehåll vid soft-reset från watchdog, reset från panic-funktion i koden eller en kontrollerad reboot från min programkod samt även under deep-sleep, vilket ger intressanta möjligheter. Det minnet raderas bara vid tryck på reset button (hard-reset).
Används via attribute macrot RTC_NOINIT_ATTR för variablerna.
För en batterimonitor är det essentiellt att kunna bibehålla all data som berör batteribankens laddstatus (SoC) även om det skulle inträffa en ESP32 panic-reset av en yttre störning. Så man efter t.ex. 1 veckas PSoC-drift inte riskerar att förlora batteribankens laddstatus!
Så min ESP32-batterimonitor utnyttjar RTC Slow Memory för sådan SoC-data, vilket jag verifierat fungerar perfekt vid soft-reset från watchdog eller reset från panic-funktion i koden!
Jag sparar även dessa data som berör SoC i flash-minnet lite glest, men då flash har begränsad livslängd så kan det inte göras för ofta. Men blir ytterligare en backup för den viktiga datan!
Såg nu senare (2024-05-07) att intressant nog använder ESP Insights också RTC data store: "ESP-Insight currently uses RTC memory to store the messages until it is sent to the cloud. Unlike, normal RAM, RTC store makes data available across soft resets. Thus, it brodens the usefulness of the data across reboot." Beskrivs även här. Läs mer om min RTC data store här ovan.
ESP Insights API och ett kodexempel på To get started with Insights.

Målsättningen är att klara stabil 24/7/365-drift utan att någonsin behöva boota om, men sannolikheten att aldrig behöva boota om är nog inte så stor. Men ska i vartfall uppnå en riktigt lång tid mellan reboot, som då helst enbart ska göras kontrollerat när något krititisk som kräver reboot detekteras via min övervakning av ESP32-driften.
Sker en okontrollerad reboot så garanteras ändå datan kring SoC via RTC Slow Memory!
Detta tar dock kring året i skarp drift att verifiera, men verifierat i 14-dagars stresstestad drift nu.
Samt delar av det är verifierat under det dryga årets skarp drift här hemma under utvecklingen.
Har parallellt med detta nu även verifierat och analyserat hårdvarans kopplingsschema kring INA226 extra noga innan jag löder ihop en mer permanent sådan. Och den är OK!

2024-04-25
Valet jag gjorde för min ESP32-batterimonitor att visa driftsinfo och inställningar på webbsidor via WiFi och webbserver i ESP32 känns helt rätt, än mer nu kanske när jag fått se det i drift.
En modern webbläsare i mobilen / datorn är en avancerad resurs med fint kraftfullt stöd för både grafik-, text/font-, layout- och data-hantering samt JavaScript, och ger via WebSocket en bra möjlighet till fin tvåvägs data- och informations-utbyte direkt mellan webbsida och ESP32.
Ytterligare fördelar är att den resursen belastar inte ESP32 internt samt hanterar touch-skärm.

Har idag kodat så jag via en tryckknapp på webbsidan kan nollställa viss mätdata i ESP32, vilken visas på webbsidan. Har då även inline-kodat en SVG-icon för trycknappen för trevlig grafisk utformning på webbsidan.
Nollställningen gör jag via WebSocket-kommunikation och var inte många kodrader som behövdes för att få till det, inkl. modal dialogruta för kvittens av att datan verkligen ska nollställas.
Sedan direkt efter nollställning skickas den nollade datan ut via WebSocket till alla webbläsare som just då visar den webbsidan, så infon direkt blir uppdaterad där.
Är bara så jäkla smidigt :-)

Gör allt kodande i PlatformIO på VSCode, där jag då kan koda både C++ koden för ESP32 och webbsides-koden för webbsidorna, vilken också lagras i ESP32.
Smidigt att kunna koda allt i samma IDE med så bra stöd som den ger i allt kodandet!
PlatformIO hanterar även de kodbibliotek jag använder till ESP32.

Samt idag har jag haft WiFi i ESP32 igång uppkopplad mot routern och skickande WebSocket data stabilt till webbsida under ca 5h, och då har det registrerats 1st automatisk återanslutning via min WiFiReconnect()!
Så känns bra tycker jag, både stabiliteten och att min WiFiReconnect() faktiskt aktiveras när det behövs.

2024-04-28
Har fått reaktioner på att man i ett privat hobbyprojekt inte skulle kunna få fram en batteri­monitor bättre än de utvecklade av stora företag i Europa som Studer Innotec, Victron Energy m.fl. Men i ett pen­sionärs­hobby­pro­jekt har man tid på ett helt annat sätt!
Som lilla startupen Omotion i Lund med trehjuliga elfordonet Omotion 2 utvecklar också helt själva bland annat system för övervakning, felsökning, diagnosticering samt kontroll av batteri- och laddstatus med mera som går via en app, enligt artikel i NyTeknik. Och som startup har man inte lika mycket tid som en pensionerad ingenjör. Men de gör så ändå!
Så jag tycker inte det är så märkligt att jag kan det med all min yrkeserfarenhet av avancerad teknikutveckling samt allmänna tekniska nyfikenhet och driv!

Har nu kodat så det även visas en vertikal linje för dygnets första 0,5% Tail-current "Sync 100% SoC" i min "Battery 24hr operational graph", så jag smidigt kan se / utvärdera dess funktion.
Är blybatteriet som själv talar om att det är fulladdat så vid 0,5% Tail-current (0,45A för mitt 90Ah AGM-blykol), vilket det finns gedigen teknisk information kring från högskola och gurus.
Och ser man här bryter strömkurvans minskning av och blir flackare strax innan vilket sannolikt indikerar att blybatteriet är fulladdat då. Så vetenskap / teori och praktik verkar hänga ihop!
Och strömkurvan planar successivt ut på ca 0,25A som då ger 0,45 / 0,25 = 1,8ggr marginal för robust 0,5% Tail-current funktion. Sedan övervakar min programkod detta och kan adaptivt vid behov öka de 0,5% för Tail-current, om det skulle behövas för typ riktigt åldrade blybatterier.
Ska bli intressant att se mer av vid battericykling med lite djupare urladdningar senare!
Har även en del andra parametrar kodade som mäter och analyserar för att noga verifiera funktionen och precisionen hos min ESP32-batterimonitor, med de visar jag inte.
Är väldigt intressant att blybatteriet själv talar om info såhär om dess drift istället för att försöka ha några grovt gissade kriterier och fasta värden i programkoden för det!
Blybatterier kan även själva tala om på liknande sätt när absorptions-laddningen ska avbrytas och växla till float-laddning, vilket blir mycket exaktare och skonsammar för blybatteriladdningen än någon fast kodad algoritm för det i en solladdregulator!
Både olika battericykling, temperatur, åldrande samt varierande laddströmmar från solceller påverkar detta som då batteriet har med sig när det ger info om att avbryta absorptions-laddningen, på ett helt annat sätt än en fast kodad algoritm kan.
Går naturligtvis att göra för LiFePO4-batterier också, även om en aktiv cellbalanserare kanske kan stör det lite jämfört med den mer naturliga funktionen med självbalansering av cellerna i blybatterikemin.
Jag har idéer kring hur blybatterierna ska kunna ge ytterligare info kring sin drift för än mer optimal skonsam styrning av batteridriften / laddningen, som jag hoppas få chans at testa.
Hur många andra batterimonitorer visar i diagram när Sync 100% SoC sker, så man själv kan se hur precisionen är med det?

2024-04-30
Löste ett lite kodproblem igår med att synkningen av RTC till NTP-tidsserver gjorde att aktuellt index för mina 24h data-arrayer backade ett steg om RTC justerades tillbaka något i tid, vilket hänt rätt sällsynt med synliga små krusningar på datalinjerna tidigare.
Får fram aktuellt 10min-index via:
ArrInd24hrNow = TimeInfo.tm_hour * 6 + (TimeInfo.tm_min / 10);
Så om typ kl.15:10:00 backar till 15:09:59 så backade arrayindex ett steg.
Och med min nya tidslinje för dygnets första Sync 100% SoC så hoppade den igår plötsligt fram ett stort kliv på eftermiddagen samtidigt som det blev små krusningar på datakurvorna. Och ny sådan tidslinje får bara detekteras efter att nytt dygn börjat, som min kod baserar på att senaste dataindex blir mindre än föregående. Och när RTC-tiden justerades bak något igår blev det uppfyllt mitt på dagen! Och då blir det även små fel i beräkningen för datakurvlinjerna.
Har sett sådana små oförklarliga krusningar på datalinjerna glest tidigare också men då inte förstått orsakan, men nu blev det så tydligt.
Så har lagt in en logik där nu att dataindex får bara backa om det görs ett tidshopp i dataindexet på >12h, vilket bör bli idiotsäkert.
Kan bli så dels när ESP32 kört död räkning en tid mellan anrop till SNTP, samt ibland blir även synkningen mot tidsservern fördröjd någon sekund, så man får synkning mot en aning gammal tid. Ständiga små förbättringar i programkoden.
Och nu idag fungerade det perfekt. Och med tredje dagen nu så fortsätter man här att se att strömkurvans minskning bryter av och blir flackare strax innan eller vid första 100% SoC synkningen för dagen, vilket sannolikt indikerar att blybatteriet är fulladdat då.
Så ska bli jätteintressant att följa detta vid lite mer aktiv battericykling framöver, som ger lite djupare urladdningar! Lägsta uppmätta Tail-current under PV-Throttle är nu 183mA.

2024-05-01
Dagens första "Sync 100% SoC" skedde vid 99,3% SoC, vilket är riktigt bra precision!
Samt AGM-blykolbatteriet laddades med full solcellsström fram till ca 97,5% SoC då PV-Throttel startade, men är rätt låg laddström här i mitt experiment off-grid solcellssystem (<2,4A / 90Ah).
Och detta ifrån 92% SoC urladdad nivå som lägst denna battericykeln.
Riktig bra värden fast jag ännu har ca 1m mätkablar mellan strömsensorn och strömshunt, vilket ger lite felmätning av 9kHz strömpulsandet från Battery Reconditioner med något lite för mycket mätt urladdning. Så när jag lött ihop den delen med strömsensorn monterad i en apparatlåda intill strömshunten kommer dessa värden bli ytterligare något bättre!
Laddade både mobilen och lite verktygsbatterier igår kväll, med som mest 64W momentant.

2024-05-03
Idag skedde "Sync 100% SoC" vid 99,1% SoC, mätt av ESP32. Under denna battericykel var lägsta SoC då 95,2% samt cyklad urladdning -4,3Ah / 90Ah, också mätt av ESP32.
Men har då en felmätning av 9kHz strömpulsandet från Battery Reconditioner på grovt -0,8Ah/dygn. Utan den felmätningen hade det skett vid lite högre SoC väldigt nära 100% SoC!
Den felmätningen av de 9kHz strömpulserna kommer minska då jag får strömsensorn INA226 monterad i apparatlåda nära strömshunten, mot de ca 1m långa kablarna mellan dem just nu. Men även såhär är -0,8Ah/dygn fel i stort försumbart i mitt riktiga off-grid solcellssystem!
Även här ser man hur strömkurvans minskning bryter av och blir flackare ungefär vid första "Sync 100% SoC" för dygnet (inringat), vilket sannolikt indikerar att blybatteriet är fulladdat då. Så vetenskap / teori och praktik verkar hänga ihop bra kring 0,5% Tail-current!
Men får bättre data senare från lite djupare battericykling i mitt riktiga off-grid solcellssystem!
Detta är från mitt lilla experiment off-grid solcellssystem i lägenheten.
Är som rena konstverket efter att under så lång tid ha slitit med att få till detta i ESP32 :-)
Så jag tillåter mig att njuta av de fina kurvlinjer över battericykeln jag får i mitt diagram nu :-)
Och samtidigt får jag nya kunskaper och insikter om hur AGM-blykol batterikemin fungerar!

2024-05-06
Visar nu analysdata över själva ESP32-batterimonitorns funktion på webbsida. Mäter, analyserar och beräknar statistik över lite olika nyckelparameterar / nyckeldata under drift som visar med vilken precision min ESP32-batterimonitor arbetar, för att objektivt få fram data på det.
Är ett ingenjörsmässigt sätt att utveckla detta på, med inbyggd analys av egen funktion!
Hittills visar det på väldigt bra precision, i vissa delar på exceptionellt bra precision.
Så verkar kunna leva upp till namnet: Ultra-precise Battery System Monitor!
Samt har ändrat på precisionen i datavisningen av SoC så det är med en decimal överallt nu.
Har även justerat så jag börjar med att ta med 100% av uppmätt batteriverkningsgrad i beräkningarna nu från början, så får verklig drift visa hur det blir. Med den höga precisionen indikerad nu bör det bli bra!

2024-05-07
Första PV-Throttle för dagen idag skedde vid 96% SoC efter återladdning från 92% SoC i float-laddning med max 1,4A. Hade det varit med absorption-laddning hade det varit vid högre SoC, samt har ännu den där lilla felmätningen av 9kHz strömpulsandet från Battery Reconditioner.
Mest bara checkat att mätning med datavisning på webbsidan fungerar OK.
Blir intressant att se vad det blir i mitt riktiga off-grid solcellssystem vid mer aktiv battericykling!

2024-05-08
Fick ny version av ESPAsyncWebServer-esphome:
PS D:\...\Documents\PlatformIO\Projects\PWMcontroller> pio pkg update
Resolving wemos_d1_uno32 dependencies...
Library Manager: Updating ESPAsyncWebServer-esphome @ 3.1.0
Library Manager: Removing ESPAsyncWebServer-esphome @ 3.1.0
Library Manager: ESPAsyncWebServer-esphome@3.1.0 has been removed!
Library Manager: Installing ottowinter/ESPAsyncWebServer-esphome @ 3.2.0
Downloading [####################################] 100%
Unpacking [####################################] 100%
Library Manager: ESPAsyncWebServer-esphome@3.2.0 has been installed!
Library Manager: Resolving dependencies...
Library Manager: Installing esphome/ESPAsyncTCP-esphome
Downloading [####################################] 100%
Unpacking [####################################] 100%
Library Manager: ESPAsyncTCP-esphome@2.0.0 has been installed! (för ESP8266)
Library Manager: Installing Hash
Library Manager: Installing ESP8266WiFi
What´s Changed: Add mutex for queue processing.

Infogade min bugfix i AsyncEventSource.cpp in function avgPacketsWaiting() samt ändrade till TEMPLATE_PLACEHOLDER '$' för preprocessorn.
På webbsidorna med SSE (Server-Sent Events) uppdateras all SSE-data signifikant snabbare nu och all data i ett svep utan att kön blir aktiverad, så en positiv förbättring.
Även ESP32-RTC synkar nu mer exakt mot NTP-tidsserver så webbläsare och ESP32 visar samma sekund var gång.
När jag superstressade websidan "System Operational Data" som har väldigt mycket SSE-data fick jag en panic´ed-reset, men är inte så jag använder webbsidorna normalt. Så räknar inte det om det inte händer fler gånger vid normal användning. ESP32 gjorde i alla fall en soft-reset + hard-reset (PowerON), så fungerar som tänkt och var igång igen med loggning efter bara några sekunder. Och då med all essentiell loggdata för batterimonitorn sparad och återställd!
Så är "bara" 24h loggdatan för presentation av batteridriften som går förlorad, men ska senare titta på om även den ryms att sparas i RTC Slow Memory (8kB RAM), vilket jag tror.
Så ifall hade man inte märkt något alls av en sådan här reset, då även WebSocket webbsidorna återansluter automatiskt efter sådan reboot.
En 24h datatidsserie tar 1824bytes och alla 6 då 10944bytes, så blir för mycket. Men 4st som visas i diagrammet blir 7296bytes, vilket kanske har chans att rymmas i RTC Slow Memory.
Men ska nog titta på en kombination av glest lagrad data via Preferences samt bara datan sedan dess i RTC Slow Memory, och så ifall kommer jag kunna spara all data inkl. 7dygns drifttidsdata senare. Ska göra lite inledande tester med det!

2024-05-09

Har nu fått det stabilt efter eventuell kodkrasch som ger soft-reset att programkoden nu alltid gör en hard-reset direkt på det i setup() och kan aktivera RST/EN-pin för en PowerON reset (hard-reset)! Har nu fått det att fungera stabilt via ett RC-nät mot RST/EN-pin! Och det loggas fint också.
Kan då även robust stabilt få till en ESP_RST_POWERON hard-reset via en kontrollerad esp_restart() soft-reset när programkoden t.ex. detekterar för lite ledigt RAM-minne eller för fragmenterat RAM-minne etc.
Här finns alla esp_reset_reason_t Reset reasons definierade för ESP32.
Får även titta lite mer på Error Handling och alla dess Error Codes References.

2024-05-11
Kodat så att efter varje PowerON och soft-reset synkas RTC mot NTP-server automatiskt, med försök under 180s tills lyckad tidssynkronisering. Testade utan tillgänglig WiFi och då hann den med 46st sökande efter WiFi via WiFiMulti.run() under de 180s, tyst stabilt i bakgrunden medan ESP32 visade avlästa datavärden från INA226 på LCD-teckendisplayen. Riktigt bra :-)
Om inte RTC_NTP_Synchronized == true efter 180s så görs nya försök var 30:e minut tills lyckad tids­synk­ro­ni­ser­ing, då det krävs innan loggning av data med tidsstämpling startar. Om uppkopplingen till mobilnätet är svag eller inte fungerar t.ex., för robust helt autonom drift.
Har nu ökat de 180s till 300s samt verifierat att programkoden som gör nya försök var 30:e minut tills RTC_NTP_Synchronized == true uppnås fungerar som tänkt! Var 30:e minut spar ström.
Med 300s bör det bli bra marginaler att boota upp 4G-routern samt koppla upp till Internet via mobilnätet, men får också verfieras senare.
Är ytterligare ett steg mot robust stabil autonom 24/7/365-drift!

Senaste dygnet har jag haft min 100W 230V växelriktare påslagen som strömförbrukare så att batterispänningen större delen av tiden legat under den nivån som aktiverar mitt 9kHz strömpulsande från Battery Reconditioner. Så då stämmer mätningarna bättre.
AGM-blykol batteriet blev då urladdat till 94,5% SoC samt PV-Throttling startade vid 97.4% SoC och "Sync 100% SoC" skedde vid 99,7% SoC! Så indikerar laddning med full ström från solcellerna högt upp i SoC samt riktigt bra precision i "Sync 100% SoC"!
Men är dels med lågt urladdningsdjup samt dels med låg laddström, så därför jag kallar det för indikation. Får säkrare bättre värden senare från mitt riktiga off-grid solcellssystem med lite djupare urladdningar och större strömmar. Är ESP32 som loggar dessa mätvärden för utvärdering (samt en del annat också med analys / statistik).

2024-05-13
Kodat så RTC´s epoch-time sparas under en soft-reset så RTC-tiden återställs när ESP32 bootat om efter störning. Är helt nödvändigt för att dataloggningen ska kunna fortsätta med sin RTC-tidsstämpling då uppkoppling mot mobilnätet inte fungerar. Är bara 2-3s som går förlorat under reboot, vilket är helt försumbart för mina 10 minuters data jag tidsstämplar.
Var komplicerat att få till både med tidsfunktioner men än mer att integrera med övrig programfunktion! Men nu hanteras det på ett tydligt robust sätt som även samverkar fint med synkningen mot NTP-tidsserver när mobilnätet är tillgängligt. Espressif System Time, ESP32 – SNTP
Har inte hittat någon kodfunktion som flaggar när RTC har synkat tiden med NTP-tidsservern, så har utvecklat stabila robusta egna funktioner som analyserar och detekterar det, så WiFi-uppkopplingen bibehålls tills tidssynkningen är genomförd oavsett tiden det tar upp till maxtid.
Såg att jag med nya versionen av ESPAsyncWebServer-esphome hade för lite stack-size för Task_WebServerESP32() så ökade på den också. Hade någon kodkrasch i början när jag stresstestade nya versionen, så kan varit denna stack-size som tog slut då.
Körde även igår en dygnsdrift som minimerade felmätningen av mitt 9kHz strömpulsande från Battery Reconditioner.
AGM-blykol batteriet blev då urladdat till 94,2% SoC samt PV-Throttling startade vid 97.6% SoC och "Sync 100% SoC" skedde vid 99,8% SoC! Så indikerar åter laddning med full ström från solcellerna högt upp i SoC samt riktigt bra precision i "Sync 100% SoC" med bra stabil repeterbarhet! Så det här ser bättre ut än vad jag trodde var möjligt! Mätt och analyserat av ESP32.

Day	Lowest SoC	First PV-Throttle SoC	First "Sync 100% SoC"
2024-05-11	94,5%	97.4%	99,7%
2024-05-12	94,2%	97.6%	99,8%

2024-05-16
Börjat läsa på om C++11 & C++14 i boken Effective Modern C++ (O´Reilly) då koden default kompileras till C++11 i PlatformIO till ESP32 via Espressif Arduino framework (Compilation C++: 201103). Tanken är att successivt ändra så mycket som möjligt till C++11 i min kod, då det ger bättre, tydligare och säkrare kod!
Dock: By default, ESP-IDF compiles C++ code with C++23 language standard with GNU extensions (-std=gnu++23), så Espressif Arduino framework ligger lite efter där.
C++ features supported: All C++ features implemented by GCC, except for some Limitations, där GCC är lite som MicroC++ typ som MicroPython vs Python (som jag uppfattat det).
Jag provade i platformio.ini med:
build_unflags = -std=gnu++11
build_flags = -std=gnu++17
och då blev det "Compilation C++: 201703", så även GNU C++17 fungerar, vilket är bra då boken har underrubriken: "42 Specific Ways to Improve Your Use of C++11 and C++14"!
Kompilerar därmed nu i PlatformIO med GNU C++17 till ESP32, vilket fungerar bra.
Så siktar då på C++11 / C++14 för min programkod, men även sett visst bra i C++17.
Med C++11 kom även ett bra utökat Standard Template Library (STL) med många färdiga användbara algoritmer, datastrukturer, klasser och funktioner, som ett generellt kodbibliotek.
"Before you assume that you need to write a custom algorithm for your program, first review the C++ Standard Library algorithms. The Standard Library contains an ever-growing assortment of algorithms for many common operations such as searching, sorting, filtering, and randomizing. The math library is extensive." Microsoft
GeeksForGeeks: C++ 11 vs C++ 14 vs C++ 17, Efterlängtat: C++17 new feature : If Else and Switch Statements with initializers if(auto var1 = foo(); var1 > 2). Wikipedia C++11, Wikipedia C++14, Modern C++ features: C++20/17/14/11, The evolution of statements with initializers in C++ - part 1, The evolution of statements with initializers in C++ - part 2

Microsoft skriver i artikeln "Welcome back to C++ - Modern C++":
"One of the major classes of bugs in C-style programming is the memory leak. Leaks are often caused by a failure to call delete for memory that was allocated with new. Modern C++ emphasizes the principle of resource acquisition is initialization (RAII). The idea is simple. Resources (heap memory, file handles, sockets, and so on) should be owned by an object. That object creates, or receives, the newly allocated resource in its constructor, and deletes it in its destructor. The principle of RAII guarantees that all resources get properly returned to the operating system when the owning object goes out of scope." Vilket då bl.a. de nya smarta pointers hanterar.
Så det klassiska problemet med minnesläckage i C är i C++11 eliminerat med detta!
Såg även att heap minneshanteringen i MicroPython är benägen att skapa problem med heap-fragmentering, där minneshanteringen i C++ är mer robust avseende heap-fragmentering, men beror även mycket på hur man kodar. Så med C++11 / C++14 kodning kan man då sannolikt få minst lika stabilt exekverande kod för 24/7/365-drift som med MicroPython.
Och C++ på ESP32 ger väldigt snabb interrupt-hantering i koden, vilket är en avgörande realtidsfunktion för den höga mätprecision jag får i avläsningen från strömsensorn.
C++ är mycket snabbare än MicroPython, ofta 25-255ggr eller än snabbare!
C++ är även "strictly typed" / "statically typed" vilket jag älskar!
Så valet mellan C++ / MicroPython är nog mest fråga om tycke och smak, samt realtidskrav.
Språk med garbage collection (som MicroPython) är dock olämpliga för realtidssystem.

Bjarne Stroustrup: "C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever." C++11 - the new ISO C++ standard
Så C eller C++11+ är som två helt olika programmeringsspråk att koda i!

Har nu som första steg bytt alla const till constexp där tillämpligt, och det fungerar bra.
Samt ändrat int64_t ESP_Time_us; till std::atomic<int64_t> ESP_Time_us; i class StateMachine så den hanteras atomic överallt för thread-safety så race-conditions undviks i multitasking / concurrency (concurrency API). Det gick också bra efter några små bra kodförändringar som kompilatorn pekade ut att det krävdes. Så blev även en form av kvalitetscheck av programkoden där.
Ska se över fler variabler att ändras till std::atomic för säkrare multitasking via FreeRTOS.
Kan kanske även ta bort några FreeRTOS-Mutex på så sätt, vilket blir bättre säkrare kod!
Detta är nog även en grund till att kunna utnyttja båda ESP32´s kärnor för min programkod.
Får även titta på std::string framöver, samt kanske std::vector / std::mutex. C++11: std::string
"C-style strings are another major source of bugs. By using std::string and std::wstring, you can eliminate virtually all the errors associated with C-style strings. You also gain the benefit of member functions for searching, appending, prepending, and so on. Both are highly optimized for speed. When passing a string to a function that requires only read-only access, in C++17 you can use std::string_view for even greater performance benefit." Microsoft
- How To Use Basic Methods Of Strings In C++?.
- std::string formatting like sprintf
- C++ String class fragmentation ESP32
- C++ String class heap memory leaks ESP32
- String Views, Studyplan
- Working with String Views, Studyplan
- Dynamic Arrays using std::vector, Studyplan
- Exceptions: throw, try and catch, Studyplan

2024-05-17
Har fortsatt med att ge fler variabler std::atomic så alla gemensamma variabler med övriga kodfunktioner hos både Task_LCDbuttonsHandler() och GetNTPtimeInternetTimeserverToRTC() och några fler blir atomic för undvikande av race-condition. Totalt 23st std::atomic nu!
Gjorde att jag nu kunde flytta Task_LCDbuttonsHandler() till core0 utan att något race-condition, konstiga värden eller kodkrasch uppstod som det gjorde vid tidigare försök.
Var den saknade pusselbiten för att smidigt fixa det istället för med mer omständig mutex.
Så std::atomic hos C++11 / C++14 är ett riktigt lyft för multitasking / threads / concurrency! Samt kodas bara där variabeln typas / definieras, så ingen risk man glömmer någon stans i koden som med mutex, och ger dessutom effektivare kodexekvering och renare tydligare kod.
Kompilatorn ger då även en sorts check att man tänkt rätt kring concurrency med de variablerna, med felmeddelande när något man kodat inte är förenligt med std::atomic.
GeeksForGeeks: C++ 11 – <atomic> Header, introduces a powerful mechanism for managing concurrent access to shared data in multithreaded applications.

2024-05-18
Kom nya versioner av platform-espressif32 och Espressif Arduino framework i PlatformIO:
Espressif32 6.7.0 som supportar ESP-IDF v5.1.2 samt Arduino ESP32 v2.0.16.
Espressif32 6.7.0 har fått en förbättrad esp32_exception_decoder, så blir intressant om/när jag får en ny kodkrasch att få se tydligare felmeddelande.
Min kod kompilerade och fungerade fint med detta, och en kod-bug som gav en kompileringsvarning jag bug-anmält var nu fixad. Så slipper jag se det gult skrikande varningsmeddelandet!

2024-05-19
Att köra Task_LCDbuttonsHandler() i core0 fungerar nu helt stabilt via std::atomic för variabler delade med övriga Task´s! Fick tidigare glest panic´ed-kodkrasch vid soft-reset reboot från GetNTPtimeInternetTimeserverToRTC() då den exekverade parallellt med övrig kodexekvering och det ibland uppstod en race-condition för variabler den delade med andra Task´s, men ser också ut att vara helt löst nu via std::atomic. Så det nya concurrency API i C++11 / C++14 är ett riktigt lyft för smidigt kodande av multitasking / threads / concurrency via FreeRTOS!
Nu även kodat så all Trip-data sparas och återställs vid soft-reset.

2024-05-20
Fick idag ofrivilligt testat att RTC uppdaterar sig mot NTP-tidsserver med försök var 30:e minut tills OK, då Internet var nere 1h timme här hemma när jag startade ESP32. Och när Internet kom tillbaka då så synkade RTC med NTP när första 30-minuters intervallet inträffade.
Och ingen 24h statistisk RTC-tidsstämplad driftsdata skapades innan dess RTC blivit synkad.
Men övrig funktion var i full drift, bara 24h statistiken som inte fanns eller visades.
Så där har jag uppnått avsedd full funktion i min kod, riktigt trevligt!
Nu får jag vid kodkrasch ut precis samma omfattande info via esp32_exception_decoder i serie-terminalen i PlatformIO som jag får ut via ESP Stack Trace Decoder på webben :-)
Så senaste uppdateringen till Espressif32 6.7.0 blev riktigt bra!
Kodat så jag nu får statistik över Heap-minnet (RAM), så jag får info att utgå ifrån för att senare lägga in en kontrollerad soft-reset om det blir kritiskt lågt eller fragmenterat.

2024-05-21
Kodat att det sparas lite statistik för High-SoC battericykling samt vid "Heap-memory critical low" görs nu en kontrollerad soft-reset, både vid för lågt lägsta Heap-memory sedan PowerON samt vid för mycket Heap-fragmentering.
Baserar "if heap critical state requiring a controlled soft-reset" på första uppmätta statistiken över Heap-minnet, så får justera dess villkor när jag fått data för längre tids drift.
Min ESP32-batterimonitor har varit i drift utan uppdatering av programkoden i 7 dygn nu och inte en enda byte i Heap-fragmentering samt även MinFreeHeap stabiliserade sig på en viss nivå så pekar mot frånvaro av minnesläckage. MinFreeHeap kräver en längre driftsperiod för att säkert avgöra frånvaro av Heap-minnesläckage då minnet används dynamiskt hela tiden vid bläddrande mellan webbsidorna.
När man bläddrar mellan de olika webbsidorna från ESP32 så är det slumpen som avgör om skickade SSE / WebSocket data, laddande av webbsideskod samt avläsning av strömsensorns värden med efterföljande statistisk beräkning inträffar exakt samtidigt, så worst-case i Heap-minnesbelastning kan ta ett bra tag innan det registrerats!
7 dygns drift motsvar drygt 500.000 programloopsexekveringar för den Task som är central.

2024-05-22
Har kodat så att om datakommunikationen via I2C till INA226 strömsensorn hänger sig och >5st reset av INA226 misslyckats görs en soft-reset av ESP32, så hela ESP32 startar om automatiskt med allt initierat på nytt igen. Via lite hackad funktion görs då en total reset!
Jag har arbetat som utvecklingsingenjör inom maskinutveckling för processindustrin stor del av yrkeslivet där nedtid / stillastående är extremt dyrt och oacceptabelt, och där är det vanligt med självövervakning så hos maskinsystem. Så tar det tänket med mig här i utvecklingen av mikrokontroller baserade system för autonom 24/7/365-drift nu i mitt pensionärs hobbyprojekt.

2024-05-24

Efter ca 3 dygns drift med mätning av Min-Heap så fås:
MinFreeHeap: 107000b
Min MaxAllocHeap: 61428b
MaxAllocHeap: 94196b
Verkar ha stabiliserat sig här, med mycket bläddrande bland webbsidorna samt samtidigt både i mobilen och på datorn. Men får se efter längre driftstid senare.
MaxAllocHeap har hållit sig länge på 94196b nu, så den fragmenteras inte. Men kan ju finnas ett / flera kontinuerligt fritt mindre minnesblock som fragmenteras som jag inte ser ännu.
Men å andra sidan så allokeras där 94196b - 61428b = 32768b emellanåt utan fragmentering.

2024-05-26
Preferences har inte plats / kan inte spara mina 6x2080b 24hr loggdata så måste använda LittleFS filsystem istället. Även LittleFS har Dynamic wear leveling för Flash!
Använder i platformio.ini:
board_build.partitions = huge_app.csv
board_build.filesystem = littlefs
Med huge_app.csv fås: SPIFFS 917504b, app0 3145728b, nvs (preferences) 20480b
Och installerat i koden får jag följande data för LittleFS;
[D][main.cpp:2227] setup(): LittleFS mounted OK
[D][main.cpp:2230] setup(): LittleFS.totalBytes: 917504 bytes
[D][main.cpp:2231] setup(): LittleFS.usedBytes: 8192 bytes
huge_app.csv partition table:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x300000,
spiffs, data, spiffs, 0x310000,0xE0000,
coredump, data, coredump,0x3F0000,0x10000,

Ny version av ESPAsyncWebServer-esphome (v3.2.2) och då kom detta tillbaka då jag glömde lägga in min buggfix för det:
Guru Meditation Error: Core 1 panic'ed (IntegerDivideByZero). Exception was unhandled.

Core 1 register dump:
PC : 0x400eb236 PS : 0x00060a30 A0 : 0x800d5eb0 A1 : 0x3ffb4910
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x3ffe0f74
A6 : 0x00000004 A7 : 0x3ffb492c A8 : 0x00000000 A9 : 0x3ffb48f0
A10 : 0x3ffb4918 A11 : 0x3ffdff4c A12 : 0x00000000 A13 : 0x00000000
A14 : 0x372e3537 A15 : 0x00000000 SAR : 0x0000001b EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x4008ac1c LEND : 0x4008ac32 LCOUNT : 0xffffffff

Backtrace: 0x400eb233:0x3ffb4910 0x400d5ead:0x3ffb4940 0x400e2afd:0x3ffb4960
#0 0x400eb233 in AsyncEventSource::avgPacketsWaiting() const at .pio/libdeps/wemos_d1_uno32/ESPAsyncWebServer-esphome/src/AsyncEventSource.cpp:329
#1 0x400d5ead in HandlerEventDataSSE(AsyncEventSource const&, unsigned long const&, unsigned int) at src/main.cpp:5716
#2 0x400e2afd in Task_WebServerESP32(void*) at src/main.cpp:5400 (discriminator 7)
Är fint att jag numera får alla denna Backtrace info direkt i serieterminalen i PlatformIO.
Backtrace info fås via platformio.ino: monitor_filters = time, esp32_exception_decoder
Lagt in den buggfixen nu igen för AsyncEventSource.cpp:329!

2024-05-27
Provar lite med LittleFS, a little fail-safe filesystem designed for microcontrollers.
Testade att via LittleFS skriva en class objects rådata direkt till en datafil, läsa tillbaka den rådatan från datafilen direkt in i class object utan serialization av datan, samt både före och efter läsa av datastorleken för det class object. Som ersättare för Preferences för större dataobjekt:
Size of RingBuff24hrAmp: 2088 bytes
Time to write data: 67939 us
File data written: 2088 bytes
File size stored: 2088 bytes
Time to read data: 15404 us
File data read: 2088 bytes
Size of RingBuff24hrAmp: 2088 bytes
Och det gick bra både rent datamässig i antal bytes samt diagramkurvorna ritas ut precis på samma sätt som innan denna övningen, så blev ingen korrupt data i RingBuff24hrAmp class object! Så ska kunna komplettera Preferences för större dataobjekt som 24hr statistik.
Best way of writing / reading classes-objects to / from txt file, rådata utan serialization:
But, this will only do a byte-for-byte, shallow copy. It will fail if the object contains pointers, references or other objects that contain pointers or references. It will also fail to stream the value of any static data members.
How to store a struct in a file?
LittleFS – the Best File System for Embedded Projects?:
LittleFS is designed to ensure that the file system does not become corrupted and does not wear out from overuse. Organizes its on-disk data structures to be resilient to loss of power.
LittleFS has a very small code size and uses surprisingly little RAM.
LittleFS provides hooks that allow it to be thread safe. The Moddable SDK implements these hooks on devices running FreeRTOS, which includes the ESP32.
Making LittleFS thread-safe - use xSemaphoreTake(fs_mutex,0xffffffff), is already build in

2024-05-28
Igår var det en mängd molntussar som drev förbi på den soliga himlen och gav snabba stora strömvariationer från solcellerna.
Känner mig nöjd med hur jag presenterar det i diagrammet över batteridriften i min ESP32-batterimonitor över off-grid solcellssystemets drift.
Får tydligt fram både hur mycket ström och batterispänning varierar samt visar ändå tydliga stabil kurvor över den aktiva batteriladdningen.
Variationen visas med Max/Min-skuggning till diagramlinjerna för ström/spänning som visar plottade 10min medelvärden. Varje sådan 10min medelvärdes datapunkt är i sin tur medelvärdet för drygt 500.000 datasamplingar, så fångar driften detaljerat.
Sådan Max/Min-skuggning till diagramkurvor är en väl etablerad teknik, så inget jag hittat på.
De flesta batterimonitorer jag sett plottar istället rådatan direkt, som i detta fallet hade gett kurvor som svängt snabbt upp och ned i ett enda virrvarr där de trasslar in sig i varandra och det går inte att läsa ut något vettigt ur dem tycker jag.
Närmar sig att återmontera det andra exemplaret i husvagnen!

2024-05-30

Lite Heap-minnesstatistik för firmware version 2024-05-21 efter 8dygn 15h drift. Har legat stabilt där några dygn nu trots lite stresstestande, så indikerar inget problem med minnesläckage eller fragmentering.
Min MaxAllocHeap: 61428b, MaxAllocHeap: 94196b var så redan 2024-05-24, se inlägg då här ovan.
Trots en mängd molnflak som drev förbi på den blå himlen orsakande väldigt dynamiskt varierande solcellsström sker första "Sync 100% SoC" för dygnet robust stabilt! Så den tekniska funktionen jag använder där blev bra och låter sig inte luras av stor ström­dyna­mik i sådant väder, samt fungerar även fint i långvarig float-laddning:

2024-06-01

Senaste dagarna blev det riktigt komplex avancerad kodning, nog lite på gränsen till hackande både mjukvarumässigt och hårdvarumässigt, och definitivt över gränsen för vad jag direkt behärskar.
Och då blev det ju inte rätt och funktionellt direkt, utan en hel del kodkrascher "panic´ed", WDT-reset, etc.
Men precis varenda gång startar ESP32 om igen via automatisk reboot utan att hänga sig, och det hade jag ju aldrig testat självmant såhär omfattande.
Är en kombination av ESP32´s förmåga och min kod som fixar det.
Men min loggning av reboot orsaker fungerar perfekt!
ESP32 har Hardware Watchdog Timers (WDT) separata för varje kärna, så nog därför den alltid klarar att boota om. ESP32 har även en "RTC Watchdog Timer (RTC_WDT) - used to track the boot time from power-up until the user´s main function" som övervakar hela boot-sekvensen!
Jag gissar att det i stort ger lika bra funktion som en extern WDT, som jag hittills inte kunnat se något behov av. Finns naturligtvis alltid en liten minimal risk att skenande kod råkar stänga av den interna hårdvarubaserade WDT, men tror den risken är mikroskopisk och mest behöver tas hänsyn till i riktigt säkerhetskritiska system som i medicinsk utrustning eller i typ kärnkraftverk.
Men finns då en risk att skenande kod även råkar trigga en GPIO till extern WDT!

Yes nu fungerar allt detta 100% perfekt! Bara så coolt!
Testat stabilt under 3h drift nu, med ett par reboot, och all 24h data och statistik är intakt!
Så nu sparas all 24hr loggdata som jag har lokalt i ESP32, samt alla andra variabler med statistik och data över batteridriften, om ESP32 okontrollerat bootar om av kodkrasch av yttre störning eller problem i programkoden som minnesläckage eller heap-fragmentering eller annat. Samt även vid kontrollerad reset naturligtvis. Är ca 2800st datavärden som sparas.
Och all loggdatan återställs då efter reboot, så blir bara ett par sekunders avbrott.
Senare när jag även har 7 dygns loggdata är kodstrukturen sådan nu att det är lätt att inkludera i detta med väldigt lite ytterligare kod.
Men krävde att jag lärde mig lite nytt inom C++ objektorienterad kodning samt mer djupare detaljer om hur ESP32 fungerar, samt även lärde mig LittleFS.
Har ju haft en hel del kodkrasch-problem med ESPAsyncWebServer-esphome, även om det verkar stabilt nu sedan ett bra tag med min buggfix till det kodbiblioteket.
Så även om en sådan panic´ed soft-reset omstart sker när jag är ute och fricampar kommer jag inte tappa 24h driftstatistik eller data till denna Battery 24hr operational graph här ovan.

Fick nästan 11h kontinuerlig ESP32-batterimonitor drift i mitt lilla experiment off-grid solcellssystem med firmware version 2024-05-21 innan jag nu laddad upp denna nya firmware versionens programkod. Med 100% stabil drift trots en hel del stresstestning, så ser riktigt bra ut!
Nu ska jag löda ihop lite hårdvara samt därefter ta en INA260 strömsensor för solcellsströmmen i drift samt fixa den sista C++ koden som krävs för det. Men mycket är redan förberett för det.
Sedan är det äntligen skarp drift igen med camping i husvagnen som gäller.

2024-06-03
Summerade allt RAM-minne jag använder i RTC Slow memory via RTC_NOINIT_ATTR allokering, från sizeof() av de variabler och struct-variables jag använder i min programkod. Blev nu 2495 bytes, så bör vara goda marginaler mot RTC Slow memory´s 8kB.
Då har jag redan med struct-variablerna för solcellsströmmen, så bör inte vara något problem att även få rum för 7dygns driftsdatan till diagram, m.m. framöver!
Lyckades inte hitta någon funktion som ger info om RTC Slow memory minnesanvändning!
Med den nya version av ESPAsyncWebServer-esphome (v3.2.2) så fick jag återigen glesa panic´ed kodkrascher när jag bländrar mellen mina webbsidor från en webbsida med SSE-datakommunikation. Känns rätt hopplöst och får någon gång i framtiden byta ut mina två kvarvarande SSE-webbsidor till WebSocket, då mina WebSocket baserade webbsidor fungerar helt stabilt och med bättre funktion! Men är för stort kodprojekt nu, så ska ha det i skarp drift i husvagnen först. Speciellt den ena SSE-websidan hanterar väldigt mycket olika data att koda för!
Men lyckades i alla fall gör lite optimeringar och kodförbättringar som i stort tog bort problemet, och skulle det nu hända någon gång väldigt glest så bootar ESP32 om automatiskt stabilt nu och återställer all den momentant sparade 24h datan och driftsstatiken så jag har kvar den för visade 24h-statistiken i diagrammen. Så nöjer mig så nu och löder hårdvara istället.
Är löst nu för SSE (se längre ned) med lite anpassning av dynamiken i min kod för SSE-webbsides kommunikationen, så var ingen bugg.

2024-06-04
Efter att kodat att all 24h statistik data sparas / återställs vid SoftReset så fick jag problem med triggad Task WDT under strömspardrift med light-sleep. När jag väl lyckats fånga felmeddelandet "Task watchdog got triggered. The following tasks did not reset the watchdog in time: task_wdt: Task_StateMachi (CPU 1)" så gick det ganska lätt att logiskt ringa in orsaken.
Task_StateMachine() hanterar de asynkrona anropen från DeferredInterruptIN226() och där jag då la anropet till StateMachine::­RTCRingBuff24hrSetData efter StateMachine::­STATE_HANDLER, och STATE_HANDLER hanterar light-sleep så då låste de två varandra.
Anropet till StateMachine::­STATE_HANDLER måste komma sist så övriga hinner exekveras den korta stund ESP32 är vaken för att läsa datavärden från INA226 samt hantera LCD-display och tryckknappsavkänning samt nu då även RTCRingBuff24hrSetData, innan STATE_HANDLER aktiverar light-sleep igen!
Under natten hann det bli 24st triggade Task WDT och all 24h statistik data sparades / återställdes helt korrekt samt ESP32 bootade om helt stabilt, så blev en ofrivillig stresstest på det!
Den funktionaliteten har jag fått riktigt robust och stabil nu för sådana driftsavbrott!
Nu när anropet till StateMachine::­STATE_HANDLER är sist igen så ser allt ut att arbeta stabilt.
Även mätt upp att de 6x 1832 bytes 24h class-object data sparade via LittleFS tar ca 550ms - 815ms i exekveringstid att skriva till filsystemet, vilket är helt OK då det görs så extremt sällan.
Däremellan spara jag den ickesparade datan i RTC Slow-memory RAM, vilket både går snabbt samt ej slits av allt skrivande till det. Men finns bara 8kB RAM där, så får kombineras såhär.
Använder 2024-06-18 2500 bytes i RTC-SRAM.

2024-06-05
Yes, det var lösningen på triggad Task WDT, verifierat under nattens Light-Sleep drift! Även "MinFreeHeap: 107164b" ligger lite högre nu, vilket är positivt.
Därmed är denna programkod OK för skarp drift i husvagnen. Så ska bara löda lite hårdvara samt ta i drift en INA260 strömsensor för solcellsströmmen samt lite kodning för det, där mycket redan är förberett i koden. Så närmar sig nu :-)

Jag trodde att en extremt grund obetydlig urladdning som till 98,8% SoC under battericykeln skulle ge en lite mer diffus otydligt detektering av "Sync 100% SoC" fulladdat blybatteri, men blev istället ännu tydligare. Strömkurvans nedgång under PV-Throttle bryter tydligt av precis då 0,5% Tail-current detekteras som indikering för fulladdat blybatteri, vilket sannolikt är pga att det är fulladdat precis då. Har sett detta vid varje "Sync 100% SoC" nu men blev extra tydligt här!
Att laddströmmen minskar snabbare fram till dess och sedan en mer flack minskning efter det.
Gör då även att beräkningen av batteriverkningsgrad sker med hög fin precision!
Så att utgå från väl beprövad vetenskaplig kunskap för detta är helt rätt val!
Ska bli intressant sedan i mitt riktiga off-grid solcellssystem med större strömmar och lite djupare urladdningar att se om det blir lika tydligt där samt stämmer lika bra tidsmässigt.
Är även intressant att se de olika perioderna under dagen med molntussar som driver förbi på den blå himlen och dess inverkan på solcellsström och batterispänning.
Ger en massa fin ny kunskap kring blybatteridrift med denna precisionen i loggning av den.
Och är man nördigt intresserad av blybatteridriften som jag, så är det riktigt skoj!
Är även övertygad om att med en så exakt uppmätt batteriverkningsgrad för varje battericykel så får man en bra indikering för försämrad blybatterihälsa (SoH) om batteriverkningsgraden plötsligt börjar minska. Så ska använda det som en av flera parameterar för SoH senare.
Därmed är ESP32-batterimonitor programkodens funktion väl verifierad för skarp drift nu!
Lite ny info från en stor batteritillverkare: Lead Carbon Battery Technology

2024-06-07

Har nu stresstestat min senaste programkod-version genom att frenetiskt bläddra mellan webbsidorna, lite extra mycket mellan de två där det lite glest blev en kodkrasch tidigare med nya versionen av ESP­Async­Web­Server-esphome (v3.2.2), och helt stabilt nu!
Krävdes lite anpassning av dynamiken i min kod för SSE-webbsides kommunikationen nu när den blivit effektivare och snabbare i ESPAsyncWebServer-esphome (v3.2.0), vilket nu är verifierat att det fixade stabiliteten! Så nu fungerar (äntligen) även SSE bra i ESPAsyncWebServer-esphome (med min bugfix). Därmed är denna ESP32 kodutvecklingen färdig för skarp drift!
Gjorde förändringar i HandlerEventDataSSE() för if(EventsSSE.count() < 1U) samt i hur SSEevents.close() hanteras, hur det annars ger panic´ed kodkrasch glest för SSEevents.send() vid växling av webbsida som en sorts konflikt nu när webbservern hanterar SSE effektivare.
Lite bra läsning: Order of Evaluation in C++17.

2024-06-11
Lade till en rak rödstreckad linje för strömmens medelvärde under senaste 24h i diagrammet. Tycker det är intressant info för batteridriften som diagrammet fokuserar på, även om det blev en aning mer rörigt. Är svårt att uppskatta det medelvärdet själv ur strömkurvan.
Skönt att ha en väl strukturerad programkod, så detta tog inte många kodrader att infoga:
2st kodrader i ESP32 C++ koden, för skickande av denna WebSocket-datan till webbsidan.
12st kodrader i html-filen, för att ta emot WebSocket-datan samt rita önskad diagramlinje.

2024-06-12
Då blev det solcellsström idag som verifierade att dagens första "Sync 100% SoC" blir kvar även vid två fulladdningar av batteriet under 24h med mellanliggande mindre urladdning.

2024-06-16
Skriver ut ESP-info om aktuell ESP32 MCU i mitt projekt när den bootar, och utökade nu med partitionstabellen (kod) och lite annat:
Compilation date: Jun 15 2024
Compilation time: 18:52:09
Compilation file: src/main.cpp
Compilation C++: 201703
ChipCores: 2
ChipModel: ESP32-D0WDQ6
ChipRevision: 1
CpuFreq(MHz): 240
FlashChipSpeed(MHz): 80
FlashChipMode: 2
FlashChipSize(B): 4194304
FlashChipSize(MB): 4.0
SketchSpace(B): 3145728
SketchSize(B): 1191968
FreeSketchSpace(%): 62
HeapSize(B): 312452
FreeHeap(B): 273952
FreeHeap(%): 88
Partition table:
partition addr: 0x010000; size: 0x300000 / 3145728 (bytes); label: app0
partition addr: 0x009000; size: 0x005000 /    20480 (bytes); label: nvs
partition addr: 0x00e000; size: 0x002000 /      8192 (bytes); label: otadata
partition addr: 0x310000; size: 0x0e0000 /  917504 (bytes); label: spiffs
partition addr: 0x3f0000; size: 0x010000 /     65536 (bytes); label: coredump
ESP32 FreeRTOS max Task priority: 24
Use time slicing for equal priority, configUSE_TIME_SLICING: 1
Use preemption, configUSE_PREEMPTION: 1
Tick Rate (Hz), configTICK_RATE_HZ: 1000
Use idle hook, configUSE_IDLE_HOOK: 1
Use tick hook, configUSE_TICK_HOOK: 1
Use runtime stats, configGENERATE_RUN_TIME_STATS: 0
Maximum log verbosity, CONFIG_LOG_MAXIMUM_LEVEL: 1
Default log verbosity, CONFIG_LOG_DEFAULT_LEVEL: 1
SdkVersion: v4.4.7-dirty
ESP IDF version: v4.4.7-dirty
ESP_ARDUINO_VERSION: 2.0.16
sizeof(*RingBuff24hrVolt) (bytes): 1832
6*sizeof(*RingBuff24hrVolt) (bytes): 10992
sizeof(*RTC_24hrUnsavedDataAh) (bytes): 264
6*sizeof(*RTC_24hrUnsavedDataAh) (bytes): 1584

Jag använder i mitt projekt Espressif Arduino-ESP32 huge_app.csv partition table:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x300000,
spiffs, data, spiffs, 0x310000,0xE0000,
coredump, data, coredump,0x3F0000,0x10000,
vilket stämmer bra med min boot-utskrift.

Fick tips om arduino-esp32/cores/esp32/chip-debug-report.cpp som troligen är en del av nya Espressif Arduino 3.0.x, så ska titta om det är någon mer info där som jag har nytta av att skriva ut vid boot.
Espressif Partition Tables
Espressif Partitions API

2024-06-18
Synkronisering av tid på internet görs ofta med det gamla NTP-protokollet, vilket är lätt att manipulera skriver NyTeknik.
"Trots att NTP är ett äldre protokoll, kan den alltså fortfarande utgöra en mer stabil lösning för tidssynkronisering. För med ett par relativt enkla ändringar i inställningarna kan man ganska säkert skydda sig mot manipulation av tiden. Det kräver dock att man aktivt tar ställning till hur man tar emot tid från NTP-servrar.
– Man kan aktivt säkerställa att få flera NTP-källor samtidigt. Till exempel kör både Apple och Microsoft sina egna NTP-servrar, säger Mikael Vingaard."
Så har jag gjort och kör med Swedish Distributed Time Service Netnod´s NTP-tidserver, som är en säker NTP-leverantör ägd av TU-stiftelsen (Stiftelsen för Telematikens utveckling). De distribuerar svensk nationell tid genom Network Time Protocol (NTP). Sedan har jag även två till helt andra NTP-källor angivna för synkronisering av ESP32 RTC.
Netnod har ett direkt samarbete med PTS som finansierar stora delar av verksamheten.
Sverige först i världen med säker internet-tid, Computer Sweden 2019.
Netnod: What is Network Time Security and why is it important?

2024-06-21
Ett 24h diagram över batteridriften då jag haft en strömförbrukare inkopplad hela dygnet så felmätningen pga långa mätkablar + Battery Reconditioner 9kHz strömpulsandet minimerades.
Gav första PV_Throttle PWM-strömregleringen vid 96,1% SoC samt första "Sync 100% SoC" blev vid höga 99,8% från lägst 94,8% SoC urladdat för battericykeln, mätt av ESP32. Samt vid skärmdumpens tidpunkt ca 22:20 så var det samma SoC på ömse sidor om den vertikala tidslinjen samtidigt som medelströmmen var ≈0A och battericykeln varat ca 1 dygn, vilket innebär extrem hög batteriverkningsgrad och för så grund urladdning! Annars skulle medelströmmen blivit högre för att kompensera för förluster i AGM-blykol batteriet. Snart har jag korta mätkablar mellan INA226 strömsensorn och strömshunten, vilket blir spännande att se effekten av.
Mätt batteriverkningsgrad för denna battericykeln blev: Last Energy(Wh): 97.2%, Last Coulomb(Ah): 100.0%, så det är fortfarande ett litet mätfel från Battery Reconditioner 9kHz strömpulsandet som förhoppningsvis i stort försvinner med korta mätkablar.
Enligt en forskarstudie på Trojan 30XHS battery 100Ah flooded / öppet kvalitetsblybatteri är batteriverkningsgraden vid såhär grund cyklisk drift bara ca 50% vid kontinuerlig laddström (typ MPPT-regulator) med ström motsvarande vad som är aktuellt i off-grid solcellssystem!
Innebär att mitt AGM-blykol batteri har extremt mycket bättre batteriverkningsgrad med strömpulsad laddning vid grund cyklisk drift här! Är intressant med högprecisions-batterimonitor!
AGM-blykol beter sig mer likt LiFePO4 än traditionella blybatterier i sund off-grid solcellsdrift.

2024-06-23
Idag när jag åter en gång aktiverade ESP32-webbservern började min pulse-LED blinka långsammare och checkade via LCD-displayen att program-loopens tid nu var 2758ms mot normala ca 1200ms, samt tittade igenom driftsdatan för mina olika Task´s och kunde se att Task_DeferredInterruptIN226() belastade CPU med 91% mot normalt <1%. Så något hade hänt där i kodexekveringen, vilket är första gången sedan den kom i skarp drift här hemma för dryga året sedan. Och kodexekveringen var fast i det, så efter ett tag fick jag göra en manuell soft-reset via tryckknapparna.
Har nu lagt in en driftsövervakning för även detta som gör en kontrollerad soft-reset om det detekteras under en viss tid. Är fördelen med lite längre utvecklingstid, att även sällsynta händelser hinner uppträda (även om det är frustrerande att inte få det klart snabbare)!
Har läst att Victron SmartSolar MPPT verkar sällsynt drabbas av något liknande som gör att de inte reglerar batteriladdning som de ska men i övrigt är i funktion, som då kräver reset via att göras strömlös. Så är nog något man får räkna med kan inträffa sällsynt vid lite mer komplex kodfunktion i embedded mikrokontrollers. Och då är min funktion med automatisk driftsövervakning och reset / reboot när kritiskt tillstånd detekteras bara så väldigt mycket bättre än att manuellt behöva koppla loss strömmatningen!
Både för min ESP32-batterimonitor och för en solcellsregulator är det då viktigt att automatiskt göra en kontrollerad reset / reboot snarast för att få tillbaka full funktion. Att typ istället bygga in en förebyggande reboot 1ggr/vecka i programkoden löser inte denna sortens problem, då man i värsta fall kan bli utan fullvärdig funktion en hel vecka!
Min ESP32-batterimonitor har nu ett antal sådana här driftsparametrar den självövervakar inkl. RAM-minnet och I2C-bussen och gör en automatisk kontrollerad soft-reset om något kritiskt detekteras, för robust tillförlitlig 24/7/365-drift.
Jag har en pulse-LED nu under kodutvecklingen som visuellt indikerar looptiden samt blinkar med ett för ögat osynligt snabbt mönster som visar kodfunktionen kring deferred interrupt ISR i koden, vilket jag kan studera via oscilloskop för verifiering av kodfunktion.

Jag har lite liknande tänk kring ESP32 soft-reset från WDT (WatchDog Timer) eller panic´ed kodkrasch att för robust drift måste jag då garantera att kritiska mätvärden och statistik sparas och återladdas för fullvärdig fortsatt drift efter reboot, vilket inte en extern WDT löser i sig.
ESP32´s interna WDT är hårdvarubaserad på en separat hårdvarudel på chipet separata för varje kärna samt övervakar även bootsekvensen, så verkar ha en väldigt robust stabil funktion. Finns naturligtvis alltid en liten minimal risk att skenande kod råkar stänga av den interna hårdvarubaserade WDT, men tror den risken är mikroskopisk och mest behöver tas hänsyn till i riktigt säkerhetskritiska system. Jag har valt att kör utan extern WDT men med hard-reset!
Så tills vidare förlitar jag mig helt på intern WDT och fokuserar istället på att soft-reset i sin tur triggar en hard-reset som vid PowerOn så ESP32 inte riskerar att hänga sig efter reboot pga något korrupt som kan bli kvar efter enbart en soft-reset (och då skulle kräva extern WDT), via att jag hackat både hårdvara och mjukvara för att få den funktionen.
Innan jag införde att soft-reset direkt följs av hard-reset hände det ibland att ESP32 hängde sig under bootsekvensen efter en panic´ed kodkrasch och då hade istället en extern WDT behövts. Jag tror detta är en bättre lösning i stort på det, vilket tiden får utvisa.
Så efter en soft-reset sparar jag bara kritisk data lagrad i RTC Slow Memory (8kB RAM) och därefter görs direkt en hard-reset. Tycker jag då får full driftssäkerhet inkl. bevarad kritisk data, även om naturligtvis en extern WDT är en form av den yttersta garanten för att få reboot om ESP32´s interna WDT inte skulle fixa det, men med en rätt grov klumpig funktion i mina ögon sett. Jag tror dock den risken med enbart intern WDT är mikroskopisk nu när soft-reset nästan direkt får trigga en hard-reset varje gång så allt återställs fullständigt i ESP32.
Hittills har det fungerat 100% robust och stabilt såhär via soft- + hard-reset, utan extern WDT!

2024-06-25
Ett 24h diagram över batteridriften igen då jag haft en strömförbrukare inkopplad hela dygnet så felmätningen pga långa mätkablar + Battery Reconditioner 9kHz strömpulsandet minimerades.
Gav första PV_Throttle PWM-strömregleringen vid 96,1% SoC samt första "Sync 100% SoC" blev vid 99,5% från lägst 91,2% SoC urladdat för battericykeln, mätt av ESP32.
Mätt batteriverkningsgrad för denna battericykeln blev: Last Energy(Wh): 96.5%, Last Coulomb(Ah): 100.0%, så det är ändå kvar ett litet mätfel från Battery Reconditioner 9kHz strömpulsandet som förhoppningsvis i stort försvinner med korta mätkablar. Samt denna battericykel varad 3d:22h:33m med totalt -15,6Ah cyklad urladdning, allt mätt av ESP32.

2024-06-28
Fick nya versionen ArduinoJson 7.1 av det kodbiblioteket med lite ny funktionalitet som inte är aktuell för mig nu, samt med lite kodoptimering. För nästa version lovas: "For the next release, I plan to optimize memory consumption. Hopefully, I´ll keep my promise this time." Låter bra!
Borde dock kanske titta lite närmre på denna nya funktion med MessagePack. "MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it´s faster and smaller."
Min kod kompilerar fint med denna nya versionen!

2024-06-29
Blev lite hårdvara färdiglödd idag, på klassiska experimentkort.
Två stycken små burkar med strömsensor som till höger där ansluts mot strömshunt och batteribank och till vänster är signalkabeln med I2C, Interrupt-signal samt 3,3V strömförsörjning från ESP32. Inte lika tjusig som egenritade PCB men funkar ändå.
Har hittills haft det uppkopplat på bread-board.
Ett exemplar är inkopplad i drift och fungerade perfekt direkt. Ska snart koppla in den andra också placerad nära intill min strömshunt i mitt lilla experiment off-grid solcellssystem här hemma.
Blir då intressant att se om mätprecisionen ökar med korta mätkablar för 9kHz strömpulsandet från en Battery Reconditioner på AGM-blykol batteriet. Jag tror det. Den ger extrem korta men kraftiga strömstötar som motsvarar ca 1MHz i frekvens, så därför svårt att mäta helt rätt över en strömshunt via lite längre mätkablar som jag haft hittills. Nu blir längden istället i signalkabeln och verkar inte vara något problem där med ca 1m längd för de digitala signalerna.
Så är verkligen på sluttampen nu med min ESP32-batterimonitor.
Mätte strömförbrukning i light-sleep strömsparläget till ca 8,5mA nu med tre deciamaler med digitalmultimetern och stämmer med vad min ESP32-batterimonitor mäter också. Så allt blev OK! Är med senaste programkoden. Då jag införde StateMachine::RTCRingBuff24hrSetData ökade strömförbrukningen något pga att tiden i light-sleep per loop blev något kortare då.
Och när allt drivs från USB 5V och labbaggregatet visar 0,000A så visar ESP32-batterimonitorn också 0,000A. Är underbart med fabrikskalibrerad "ultra-precise I2C output current sensor".

2024-07-01
Kopplat in en INA260 för solcellsströmmen, kodat och fått kontakt med. Fungerar bra på samma I2C-buss som INA226 för batteriströmmen såhär långt.
Så är bara att koda vidare för fullt integrerad funktion.
2024-07-02
Får fina tydliga medelvärdesfiltrerade diagramkurvor över batteridriften även i väldigt växlande solsken med mycket moln, där kurvor på ofiltrerad rådata bara hade blivit ett enda kaos man inte kunnat läsa ut något vettigt ur. Och samtidig får jag info om hur mycket ström och spänning varierat via skuggning till deras datakurvor ur råmätdatan, så missar inte den informationen!
Kan då även se hur pass bra solladdregulatorn sköter sin reglering.
Är väldigt nöjd med detta.

Yes, nu har jag listat ut hur interrupt-baserad avläsning av data från INA260 fungerar ihop med Adafruits kodbibliotek. Hittade inget kodexempel för just det, så sökt och hittat flera olika kodfragment som gav bra ledtrådar.
Testar av med lite kod direkt i setupESP32() för att lära och få kunskap om hur jag samverkar med det INA260-kodbibliotket.
Så nu är det bara lite grovarbete i att fixa ihop min programkod kring dess användning.
22:00:22.732 > Found INA260 chip
22:00:22.739 > INA260 Voltage(mV): 3311.25
22:00:22.739 > INA260 Current(mA): 2.50
22:00:22.741 > INA260 Power(mW): 10.00
22:00:22.744 > INA260 time read(us): 2147
22:00:22.747 > INA260 Alert pin: 0
22:00:23.922 > INA260 Voltage(mV): 3312.50
22:00:23.922 > INA260 Current(mA): 2.50
22:00:23.925 > INA260 Power(mW): 10.00
22:00:23.928 > INA260 time read(us): 2230
22:00:23.931 > INA260 Alert pin: 1
ΔT: 25.108 - 23.922 = 1.186s innan nya mätdata är färdiga för avläsning via ConvReadyAlert
22:00:25.108 > INA260 Voltage(mV): 3312.50
22:00:25.108 > INA260 Current(mA): 2.50
22:00:25.111 > INA260 Power(mW): 10.00
22:00:25.114 > INA260 time read(us): 2108
22:00:25.117 > INA260 Alert time(ms): 1186
22:00:25.119 > INA260 Alert pin: 1
Med 1024st counts av 0,558ms + 0,558ms fås 1,143s, så stämmer bra med ΔT 1.186s ihop med lite overhead plus att jag här läser av en vanlig GPIO input och inte är en interrupt!
Om all tidsskillnaden utgör overhead fås (186ms - 143ms) / 2048 = 21µs/sampling i overhead.
Därmed har jag listat ut hur interrupt-baserad avläsning av data från INA260 fungerar ihop med Adafruits kodbibliotek samt verifierat att det fungerar.
Använder då:
ina260.setAveragingCount(INA260_COUNT_1024);
ina260.setCurrentConversionTime(INA260_TIME_558_us);
ina260.setVoltageConversionTime(INA260_TIME_558_us);
ina260.setMode(INA260_MODE_CONTINUOUS);
ina260.setAlertType(INA260_ALERT_CONVERSION_READY);
ina260.setAlertPolarity(INA260_ALERT_POLARITY_NORMAL);
ina260.setAlertLatch(INA260_ALERT_LATCH_ENABLED);
samt för reset av Alert: ina260.getAlertLatch(); (länk)

2024-07-03
Tog bara en dryg halvdag att koda allt för att få INA260 strömsensorn till solcellerna i drift med sin ISR deferred interrupt processing samt all loggning och backup inkl. alla datastrukturer kring det. Är bara småjusteringar kring dess samverkan med light-sleep (LS) strömsparläge att fixa och utvärdera. Gjorde mycket copy-&-paste av koden med anpassning tll INA260 funktion, så åter igen blev det tydligt hur bra det är med en tydlig genomtänkt kodstruktur! Skoj!!!
ISR intervall-tiden för INA260 med 1024 avläsningar för medelvärde och 2x588µs samplingtid blir 1186309±2µs, vilket är en oehört liten spridning ihop med att övrig kod exekverar! Deferred interrupt processing + ESP32 är grymt bra med bara ±2µs variation!
Då exekverar samtidigt INA226´s ISR deferred interrupt processing med högre Task-prioritet!
Detta bidrar starkt till att jag kan mäta/logga Ah/Wh med så hög precision!
Printar dess utdata:

2024-07-04
Har nu fixat det sista kring INA260 ISR deferred interrupt processings samverkan med Light-Sleep strömsparläge, och nu fungerar allt effektivt och stabilt. I Light-Sleep körs inte INA260 ISR deferred interrupt processing utan dess mätvärden läses av inne i INA226 ISR deferred interrupt processing, vilket fungera bra då detta bara sker vid väldigt låg ström från solcellerna.
I den printade utdatan ser man att när Light-Sleep (LS) aktiveras ökar ISR intervall-tiden för INA260 från ca 1186301µs till ca 1206570µs som är den för INA226 ISR.
Hade först lite problem med glest triggad WDT, både Task & ISR, samt även lite glesa felmeddelanden från I2C under strömsparläge i light-sleep, men är helt löst nu.
Hittade lite ny funktionalitet för driften i strömsparläget, så koden blev även lite förbättrad såhär.
Så väntar nu ut att båda ISR Deferred Interrupt processing Task´s exekverat färdigt innan jag går in i light-sleep igen. Och samma för DisplayHandler Task.
while(eTaskGetState(TaskDeferredInterruptINA260) != eBlocked || uxQueueMessagesWaiting(INA260PVDeferredInterruptQueue) > 0 || eTaskGetState(TaskDeferredInterruptINA226) != eBlocked)
{
  vTaskDelay(2 / portTICK_PERIOD_MS);
}
Lägger en strömgräns för solcellsström på <50mA/100Ah batterikapacitet för att alls få gå in i Light-Sleep strömsparläge.
Med gränsen <50mA/100Ah batterikapacitet fås en strömförsörjning från solcellerna för den egna driften av ESP-batterimonitorn när strömmen överstiger det, från ≥90Ah batterikapacitet. Då även inklusive strömförbrukningen för mina Battery Reconditioner.
Strömförbrukningen ökade inte synbart med INA260 och dess kodfunktioner i drift.
Hade nog misstänkt det då även INA260´s ISR Deferred Interrupt Task nu ska hinna med att exekvera inom den lilla tidsluckan som hålls öppen för det i varje loop innan ESP32 går in i Light-Sleep igen. Tänkte att de proportionerna skulle försämras så strömförbrukningen ökade något.
Får se om jag senare gör ett ultra-strömsparläge där INA226/INA260 samplar betydligt långsammare så det kanske blir upp emot 5-10s/loop, som då kunde styras av att solcellsströmmen är <5mA/100Ah batterikapacitet i Light-Sleep dvs försumbart med ström från solcellerna. Lite typ extra strömsnål "invintringsdrift" / nattdrift. Kunde vara extra viktigt off-grid vintertid.

Införde även Backup-Flags som indikerar pågående databackup till filsystemet och då blockerar light-sleep under den loop-perioden backupen pågår, då det orsakar problem att gå in i light-sleep under pågående skrivning till filsystemet. Checkat nu under ett antal backups i Light-Sleep Mode och fungerar perfekt (körde var 5:e minut)! Samtidigt blockeras även light-sleep när det då byggts upp en liten kö av meddelanden till Task_StateMachine(), som 4st här nedan, så den kön betas av direkt. Sådan backup görs så sällan så inverkan av blockerad light-sleep loop påverkar strömförbrukningen försumbart! Är mycket kring Light-Sleep drift att tänka på!
Under övrig Light-Sleep drift har jag inte sett någon kö till Task_StateMachine().

2024-07-05
Allt arbetar stabilt och bra med även INA260 i drift via gemensamma I2C-bussen och dataavläsning via dess Alert-Interrupt och ISR med Deferred Interupt processing Task. Har varit i drift många timmar nu med detaljerad uppföljnng via PlatformIO´s serial terminal.

Är intressant att efter flera dygns passiv standby-drift med många timmars PV_Throttle float-laddning per dag så blir medelladdströmmen för 24h bara +8mA! Jag gissar att det är lite lågt mätt pga mätfel för 9kHz strömpulsandet från Battery Reconditioner pga långa mätkablar, vilket blir intressant att se skillnaden när jag snart monterar INA226-hårdvaran med korta mätkablar.
Jämfört med självurladdningen som är ca -3%/mån: 0,03 * 90Ah / 30 / 24h = 0,004A dvs 4mA.
Är bl.a. sådan data för batteridriften som är intressant att se, tycker jag! Se diagram nedan:

2024-07-06
Trots haveriet – därför kan Volvo vinna teknikracet - är inte bara mitt projekt som är försenat ;-)
Och även jag vinner nog teknikracet inom detta segment, då funktionaliteten nu är bättre i min ESP32-batterimonitor än jag trodde var möjligt från början!
Idag fått ett intressant cirkeldiagram levande med strömvärdena från solcellerna via nya INA260-strömsensorn. Med rådata bearbetad till fin information. Blev bara så jäkla bra!
ESP32-batterimonitorn drar nu 47mA uppkopplad mot WiFi / Internet och sänder WebSocket data till index.html webbsidan, samt 9mA i light-sleep strömsparläge och 32mA i aktiv drift med webbserver off och tänd LCD-display. Så light-sleep mode sparar drygt 70% ström mot aktiv drift samt 80% mot full webbserver-drift, vilket innebär ordentlig strömspar nytta!

2024-07-07
Lite prestandasiffror kring min egenutvecklade ESP32-batterimonitor:
Genom att koda i modern C++ (C++17) ihop med FreeRTOS kan jag få väldigt bra realtidsprestanda i ESP32 för den interrupt-baserade avläsningen av de två strömsensorernas medelströmvärden. Samtidigt som det stödjer multitasking och att utnyttja båda processorkärnorna Thread-safe med Atomic Operations samt att undvika race-conditions. Modern C++ (från C++11) har även inbyggt skydd mot minnesläckage som automatiskt frigör allokerat minne direkt det slutar användas, till skillnad mot att minnesläckaget i efterhand tas bort via garbage-collection som i MicroPython. Garbage-collection är normalt negativt för realtidsprestanda!
"Garbage collection may take a significant proportion of a program´s total processing time, and affect performance as a result. [...] Garbage collection is rarely used on embedded or real-time systems because of the usual need for very tight control over the use of limited resources."
"This fundamental tenet of garbage collection and the resulting effect on application execution is called the garbage-collection pause or GC pause time. In applications with multiple threads, this can quickly lead to scalability problems."
Programkod i modern C++ med FreeRTOS gör att ström-/effekt-medelvärdena ESP32 hämtar ca 1ggr/s från strömsensorernas 1024st samplingar (ca 50.000samplingar/min) kan hämtas med en tidsonoggrannhet på bara ±2µs, 1.000.000±2µs (uppmätt!)! Därmed sker omvandlingen från A/W till Ah/Wh med oerhört hög tidsprecision. Även realtidsmässig har jag mätt upp tidsonoggrannheten till ca ±10µs, 1.000.000±10µs, dvs felet i den omvandlingen håller sig inom ca 20ppm (0,002%) så helt försumbart!
Har även utvecklat ett avancerat filter för strömsignalerna från strömshunten via simulering i KiCad Spice, så även snabba strömförlopp mellan samplingarna fångas upp.
Strömsensorerna arbetar med 16-bit dubbelriktad (Bi-Directional) upplösning dvs 1/32768 per steg, vilket för 100A strömshunt teoretiskt innebär 3mA upplösning, men dess 1 LSB step size är 2.5µV som för en 100A/50mV strömshunt ger 5mA upplösning. Samt har i övrigt en väldig hög fabrikskalibrerad precision med både extremt bra långtids- och temperatur-stabilitet inom -40°C to +125°C. Så även noggrannheten är väldig bra hos dem.
Med 15A strömsensorn för solcellsströmmen blir då upplösningen teoretiskt 0,5mA, men dess 1-LSB step size är 1.25mA.
Nu finns även motsvarande strömsensor med 20-bit upplösning dvs 1/524288 per steg som för 100A strömshunt ger teoretiskt 0,2mA upplösning, men dess 1 LSB step size på 312.5nV ger för en 100A/50mV strömshunt 0,625mA upplösning! Jag har köpt en sådan och ska senare prova i version två av min ESP-batterimonitor, men den nuvarande räcker nog långt!
Ihop med att jag använder samma exakta metod för att detektera fulladdat blybatteri som inom vetenskaplig forskning, dock lätt anpassad för praktisk off-grid solcellsdrift, så uppnår jag väldigt bra robust precision både i mätningen av batteribankens laddstatus, dess batteriverkningsgrad samt i synkningen av 100% SoC!
Och strömförbrukningen är bara 9mA (12V) vid off-grid passiv standby nattdrift via avancerat utnyttjande av ESP32 Light-Sleep, fortfarande med aktiv strömavläsning ca 1ggr/s från strömsensorerna som i sin tur självständigt samplar data ca 50.000ggr/min från strömshunt.

2024-07-09
Fick ett fint diagram över standby-drift i stabilt solsken som tydligt visar att strömkurvan bryter av kraftigt precis där AGM-blykol batteriet detekteras vara fulladdat och första Sync 100% SoC sker för dagen, se inringat område. Jag tolkar det som att blybatteriet verkligen är fulladdat då med den reaktionen i strömkurvan. Blir intressant att snart kunna se om det blir samma med lite djupare urladdningar och större strömmar i mitt riktiga off-grid solcellssystem i husvagnen.

2024-07-13

ESP32-batterimonitorn har nu varit i 14-dygns drift oavbrutet helt stabilt med kodversion 2024-06-23 (17-dygn nu), utan något tecken på minnesfragmentering eller minnesläckage. Detta då jag infört ny hårdvara INA260-strömsensor och kodat för den i mitt andra exemplar av batterimonitorn samt löder ihop hårdvara för den.
Vid lite flyttande av batterimonitorn så kom de långa mätkablarna mellan strömshunten och INA226 en aning mer isär och då minskade tydligt felmätningen av 9kHz strömpulsandet från Battery Reconditioner, så när jag snart har korta mätkablar bör felmätningen bli minimal! Är tydligen den kapacitiva kopplingen som stör.
Såg hos MidNite batterimonitor att de har som ett trafikljus för hur länge sedan blybatterierna blev fulladdade, med:
Grönt: inom senaste 7 dygnen
Gult: mellan 7 - 14 dygn
Rött: mer än 14 dygn sedan
Är en intressant information för att visa en viktig driftsparameter för blybatterier så de mår bra och får lång livslängd. Har själv lite fundering så på en webbsida med tydlig bearbetad info över batteridriften där även folk som inte nördat ned sig i off-grid solcells batteridrift ska kunna få förståelig information, där bl.a. lite liknande info är tänkt. Så en skoj referens!

2024-07-16
ESP32-batterimonitorn låter sig inte luras av kraftigt varierande solcellsström utan gör ändå sin första för dagen "Sync 100% SoC" med hög precision! Ser riktigt bra ut.

2024-07-19
Hade lite givande diskussioner på FB om termer kring batteriladdning.
Varta översätter tail-current för avslutning av absorptions-laddfasen till "slutladdström" i sitt dokument Definitioner av industrispecifika batteritermer, samt anger det som "uppnådda strömmen i slutet av en IU-laddningsprocess (gasbildningsström)".
Innebär att den tail-current som ska avsluta absorptions-laddfasen bör var något över gasbildningsströmmen för AGM- / GEL-blybatterier.
Sedan togs upp att inversen på coulomb-verkningsgrad benäms laddningsfaktor, där min uppmätta 97,8%(Ah) då blir laddningsfaktor 1,022, där 1,15-1,20 ofta anges för traditionella blybatterier men även ned mot 1,08 för optimerade AGM-batterier.
Coulomb-verkningsgrad kan benämnas: Faraday efficiency (also called faradaic efficiency, faradaic yield, coulombic efficiency, or current efficiency.
Och batteriverkningsgrad är då energieffektiviteten (Wh).
Gassing Voltage in Battery Charging
Controlling the corrosion and hydrogen gas liberation inside lead-acid battery

Har kopplat in en DS18B20 för batteritemperatur samt kodat för dess funktion.
Använder kodbiblioteket robtillaart/DS18B20, "Arduino library for the DS18B20 temperature sensor. Restricted to a single sensor per pin. Minimalistic version, async only.", och det verkar verkligen vara minimalistiskt då jag inte ser något ökat utnyttjande av RAM! DS18B20 har mätområde -55°C till +125°C.
Gick snabbt och enkelt med kodning och få det i drift med all funktion direkt.
Läser av DS18B20 med 12bit / 0.0625°C upplösning med ett max fel på ±0.5°C och i snitt inom ±0.2°C, vilket tar 625ms att läsa av var gång om det görs inom en programloop i en sekvens. Men om requestTemperatures() görs i en loop tar det 2,1ms och sedan isConversionComplete() + getTempC() i efterföljande loop tar det 25ms, totalt 27ms för "async only" non-blocking avläsning av temperatur. Motsvarar drygt 2% av en programloop i snitt, så läser jag av var 5:e programloop / 6:e sekund belastar det bara med ca 0,5% i snitt som är i stort försumbart.
Vid WiFi=OFF läser jag bara av var 20:e programloop / 24:e sekund för max strömsnålhet, vilket bara belastar med ca 0,1%.
På så sätt gör DS18B20 sin tidskrävande 12bit konvertering självständigt i bakgrunden!
Ett blybatteri förändrar temperatur så långsamt, så var 24:e sekund blir i realtid ändå!
Limmar fast DS18B20 i en M8 25mm² rörkabelsko för direkt avläsning från en batteripol.
Har även lagt in att om inte isConversionComplete() för getTempC() så aktiverar jag isConnected(5U) som då "resets oneWire and checks if a device can be found" och som därmed försöker återupprätta kontakten med DS18B20-sensorn oavsett dess serienummer. Gör det då även lätt att byta ut till en ny DS18B20.
2024-07-22
Har kopplat upp hela ESP32-batterimonitor enheten inkl. 4G-routern RUT241 som ska vara i husvagnen och testkört komplett i laboratoriemiljö. ESP32´s styrning av strömmatningen till RUT241 fungerar helt som tänkt samt hela sekvensen med att synkronisera RTC med NTP-tidserver på Internet fungerar också perfekt och hanterar väntan på att RUT241 startar och kopplar upp sig så som tänkt. Inga problem med värme heller under många timmars aktiv drift i +27°C. Så ser riktigt lovande ut!
Med RUT241 aktiv drar allt ca 150mA från 12,5V matningen och kortvarigt knappt 350mA som max under anslutning till WiFi / Internet, så är långt under de max 2A för det lilla fina Solid-state relay LCA717 som styr strömmen till RUT241.
Några gånger hade webbläsaren i mobilen svårt att koppla upp till ESP32-webbservern trots att båda var anslutna till RUT241´s WiFi, vilket verkar hänga ihop med det korta avståndet mellan WiFi-antennen och ESP32 på ca 70cm men räckte att rucka lite på antennens läge då.
Fått en fin hållare 3D-printad till min RUT241 4G-router av sonen samt limmar fast DS18B20 tempgivaren för batteritemperatur i en M8 25mm² rörkabelsko för anslutning direkt på batteripol. Skoj att kunna se temperaturen, men ska senare i höst/vinter användas för temperatur-kompenserad blybatteriladdning i den egenutvecklade PWM-regulator jag ska ta fram och integrera i min ESP32-batterimonitor.
2024-07-23
Är fascinerande hur bra, exakt och robust stabilt min detektering av när RTC blivit synkroniserad med NTP-tidserver är! Även när jag nu några dagar kört med uppkoppling via 4G-routern RUT241 som tar sin tid (≈75s i lägenheten) att starta upp och ansluta till Internet med sin strömanslutning styrd av ESP32. Skoj att nu ha verifierat det också.
Därmed är all funktion för skarp drift i husvagnen verifierad laboratoriemässigt. Ska jag bara uppdatera hårdvaran i mitt andra exemplar i lilla experiment solcellssystemet här hemma så jag kan verifiera denna versionen av programkoden i riktig solcellsdrift också, så blir det montage i husvagnen därefter.

2024-07-29
Lött ihop det andra Arduino-shield till ESP32-batterimonitor, så nu har jag två kompletta exemplar färdiga och testad med OK funktion. Blir inte lika smidigt / fint som egna designade PCB, men lika funktionellt.

Efter att jag köpt fina högprestanda AGM-blykol (lead-carbon) batterier våren 2021 kom efter ett tag önskan om en bättre batterimonitor än min NASA BM1, även om jag haft väldigt bra nytta av den sedan 2007. En batterimonitor med bättre långtidsprecision, med automatisk exakt synkronisering till 100% SoC fulladdat (NASA är manuell) samt som visar betydligt mer info om batteridriften.
Men hittade ingen som uppfyllde mina önskemål.
Så jag började koda en mockup-webbsida för hur jag ville ha den grafiska presentationen av batteridriften från en batterimonitor, där jag kunde simulera funktionen via reglage. Där batteridriften visades via rådata som bearbetas till tydlig driftsinformation.
Vilket senare ledde till att jag började utveckla min egna ESP32-batterimonitor!

Och nu äntligen har jag den grafiska visningen aktiv i verklig off-grid solcellsdrift och får se mina tankar där i skarp drift med både solcellsström och batteriström uppdaterat ca 1ggr/s :-)
Visar proportionerna mellan hur mycket av strömmen som kommer från solcellerna respektive batteriet, samt när batterierna laddas hur stor del av solcellsströmmen som går till förbrukning respektive laddning. Samt visar SoC-laddnivå tydligt via en batterisymbol.
Cirkeldiagrammets centrum blir grönt när det är överskott på solcellsström som solladdregulatorn stryper samt blir rött när laddnivån går under 30% SoC så man uppmärksammas på det.
Färgkodningen gör att jag på en liten mobilskärm kan se hur driften är på 3-4m avstånd från den! Sedan har jag andra webbsidor med både mer typ rådata siffror, med driftsstatistik och diagram med rådata bearbetade till information.
Så min ESP32-batterimonitor är nu redo för att återmonteras i husvagnen igen!
Men jag förstår att alla inte tycker detta är ett bra sätt att visa batteridriften på, men är så jag vill ha det. Är bara skoj om vi gör på lite olika personliga sätt, tycker jag.
2024-07-31

Skoj att nu få en så bra 24h-översikt över off-grid solcellssystemets drift, där jag nu ser hur mycket av strömmen som solcellerna står för (i procent) av systemets strömförbrukning de olika tiderna under dygnet. Samt kan se fördelningen mellan solcellerna och batteriet samt vid laddningen hur solcellsströmmen fördelas mellan förbrukare och batteriladdning. Samt då i cirkeldiagrammet se den momentana strömfördelningen i solcellssystemet.
Samt ser hur lång tid under dygnet solcellerna ger ett överskott på ström (PV-Throttle), ca 5h igår.
Som igår stod solcellerna för 100% av strömförsörjningen ca 14h det dygnet i mitt lilla experiment off-grid solcellssystem här hemma, samt som max fick AGM-blykol batteriet ca 90% av tillgänglig solcellsström för sin laddning igår.
All data uppdateras live på webbsidorna ca 1ggr/s. Görs via WebSocket / SSE från ESP32 webbservern.

Nu har jag även INA226-strömsenor placerad intill strömshunten med knapp 1dm långa mätkablar mot ca 1m tidigare. Nu är istället den digitala överföringen via I2C ca 1m lång.
Och då verkar den mäta 9kHz strömpulsandet från Battery Reconditioner mer korrekt med sina korta kraftiga strömpulser (50-100A) motsvarande ca 1MHz (ca -75mA medelström när aktiv enligt datablad och nu mätt här), vilket mättes en del fel tidigare. Både nu och tidigare har dess lite längre 3A strömpulser för uppladdning mätts rätt, så därför det summerat blev lite fel förut på lite grovt ca 75-100mA för medelströmmen.
Vid 12,82V batterispänning förbrukades förut -75mA och nu -55mA cirka i kvällsmörker, och -15mA när 12,6V då denna 9kHz Battery Reconditioner är inaktiv under 12,7V.
Blir då: (75-15) / (55-15) = 1,50, så mätte 50% för hög förbrukning för 9kHz strömpulsandet förut! Vilket har påverkat märkbart då det är huvudströmförbrukaren under passiv standby-drift!
Så det känns också skoj! Även om den nog inte mäts 100% rätt nu heller, men väldigt nära.
Vid ca 13,8V float-laddning mäts den dra ca -75mA nu vilket är det som står i dess datablad.
Förut såg den ut att dra minst 150mA vid 13,8V som det mättes då, så en väsentlig skillnad.
Innebär att nu har jag riktigt bra mätprecision även vid låga strömmar trots 9kHz / 1MHz strömpulsandet. Även kraftigt dynamiskt varierande ström mäts därmed väldigt exakt.

Idag satte jag mobilen på laddning vid 9-tiden och då syns att batteriet fick stå för den större delen av den laddströmmen i det mulna vädret. Samt kan se att ca kl.04:30 började solcellerna leverera sin första ström idag.
Jag tycker detta ger en helt annan överskådlig uppfattning om solcellsdriften än bara en massa strömvärden.
Sedan kan jag titta på diagrammet över själva batteridriften och där se dess ström, spänning och laddstatus under dygnet när jag vill ha sådana mer absoluta siffror.
Utöver det har jag webbsidor som visar en mängd olika driftsaspekter i statistik och siffror, där jag då även får en detaljerad objektiv statistik över mina AGM-blykol batteriers drift, som batteriverkningsgrad, hur högt upp i SoC-laddnivå de tar emot full solcellsström (igår till 98,6%), vid vilken SoC-laddnivå batterimonitorn detekterar 100% fulladdade batterier och synkar 100% SoC (igår vid 99,7% SoC), etc.
Så kommer där få vetenskapligt objektiva exakta data som backar upp mina påståenden om hur högpresterande bra mina AGM-blykol batterier fungerar i min batteridrift!
Så ska bli skoj att senare ge mig ut på lite fricampingturer med min batterimonitor i drift i husvagnen :-)
Fick på FB kommentaren: "Du har fått till det grafiska gränssnittet riktigt bra." från en som är riktigt kunnig på gränssnittsdesign, så känns verkligen skoj!
Fler kommentarer: Riktigt snyggt! Bra jobbat! || Wow toppen! Önskar att jag hade tid att pilla på med sånt oxå. Bra jobbat! Toppen design. || Grymt jobbat! Blir det en kommersiell produkt av detta? || Imponerende diy-overvåkning! || Väldigt fint gränssnitt. Lättöverskådligt! || Riktigt snyggt! || Du får helt enkelt bygga fler och sälja :-) Ser fantastiskt ut! || Du inspirerar! || Väldigt snyggt och bra information!

2024-08-02
Fixat ett par matematiska buggar i beräkningarna för Consumption Ah & Wh.
Blev verifierade under dagens drift att det nu är OK.
WebSocket orsakade Panic´ed reset då ESP32 tappade kontakten med WiFi!
Har hänt extremt glest så har varit svårt att fånga en Backtrace-rapport för en sådan händelse och därmed har jag inte haft en aning vad orsakan kunde vara, men lyckades idag.
Fick WiFi STA Disconnected 58ms innan "Guru Meditation Error: Core 1 panic´ed".
Samt "WebSocket client #5 disconnected" 14ms innan "Guru Meditation Error: Core 1 panic´ed".
Backtrace-rapporten angav då rad 5842 som sista exekverade i min kod sedan var det i AsyncWebSocket.cpp:
5840 if (wsOperationalData.availableForWriteAll())
5841 {
5842  wsOperationalData.textAll(String(int(PulseInd)));
5843 }
Så kompletterade den if()-satsen på alla ställen med:
5840 if (wsOperationalData.availableForWriteAll() && WiFi.status() == WL_CONNECTED)
5841 {
5842  wsOperationalData.textAll(String(int(PulseInd)));
5843 }
Samt då även:
 if (wsConfiguration.availableForWrite(client->id()) && WiFi.status() == WL_CONNECTED)
 {
  wsConfiguration.text(client->id(), output);
 }
Så hoppas jag på att det är lösningen för detta!
Jag hittade ett snarlikt fall på Internet: ERROR: Too many messages queued, samt även Crash in AsyncWebSocket::textAll(String const&).
Nu håller jag tummarna för att inte något mer dyker upp från den senaste utvigningen med INA260 för solcellsströmmen samt DS18B20 för batteritemperaturen, med tillhörande mer bearbetad statistisk mätdata.

2024-08-03
Installerat ett exemplar av min ESP32-batterimonitor i husvagnen nu och den fungerar bra. Inga synliga buggar i programkoden men då jag började med all data nollad så blev några småsaker synliga som behöver några småjusteringar i koden.
Blev bra testat med ström ända upp till 15A samt laddeffekt på 220W som mest.
Men strömshunten i husvagnen verkar ha lite fel i resistansvärdet så mäter en aning för hög ström med dess nominella värden inställda, så får ta fram justerade värden som stämmer bättre med verkligheten. Har ju kontrollmätt här hemma med noggrann strömshunt och då mäter systemet rätt.
Har länge väldigt glest fått panic´ed kodkrasch när jag växlat från webbsidan "Statistic 24hr Data" till annan webbsida och inte förstått hur jag ska åtgärda det eller vad orsaken är, men nu under två dygns campande kom jag plötsligt på den sannolika orsaken till att just den webbsidan ibland orsakar kodkrasch!
Webbsidan får data via SSE från ESP32 webbservern och dess SSE är inte så stabil och kraftfull. Provad från början att slå ihop 3st siffervariablers data till en textsträng och skicka då jag tyckte det kändes rationell och effektivt, men då blev det kodkrasch titt som tätt. Så när jag ändrade till att bara skicka en variabels siffror i taget blev det mycket stabilare. Men denna webbsidan har 3st data-tid uppgifter den skickar och det blir rätt långa textsträngar, jämfört med 4-5 siffror som data, så troligen är problemet där! Samt dessa skickas precis varje loop-cykel dessutom. Så tänker dela upp i datum och tid separat, och datumet behöver bara skickas nytt 1ggr/dygn. Skulle även kunna separera HH:MM från SS så det bara blir sekundsiffrorna som skickas precis varje gång:
Uptime: 00y00m01d 14h18m29s
ESP32: 2024-08-07 22:56:09
Client: 2024-08-07 22:56:09
Även webbsidan "System Data" innehåller en sådan tidsangivelse som uppdateras varje programloop, så bör fixa den också på samma sätt.
Blev lite plottrigt otydligt med 5st diagramkurvor i "PV off-grid Operational status" diagrammet när kylskåpets kompressor hela tiden varier strömmen så kraftigt med sin ON/OFF-drift, vilket jag misstänkte men ville prova.
Så minskar ned till 3st kurvor: SoC, PV-Solar & Batt-Charge, som då ger en tydligt bild av solcells batteridriften.
Samt dubbelcheckar några av beräkningarna igen, som var OK.
Glömde även att koda så RTC synkas minst 1ggr/dygn med NTP tidsserver på Internet, genom att starta upp 4G-routern autonomt! Så får bli en egen Task som hanterar det asynkront från all annan funktion.

2024-08-09
Kodat en Task_WiFiSyncRTC(), en asynkron FreeRTOS Task för att aktivera WiFi och synkronisera RTC med NTP-tidsservers tid på Internet. Avbryter inte någon av de andra kodslingorna eller interagerar med dem negativt, oavsett hur lång tid det tar.
Med Task_WiFiSyncRTC() hanteras nu all anslutning till WiFi / Internet samt aktivering av ESP32 webbservern. Därmed förhindras att det köas upp meddelande i Task_StateMachine() som stör funktionalitet under de normala programlooparna då anslutning till WiFi kan ta en bra stund!
Används bl.a. till att synkronisera RTC med NTP tidsserver på Internet vid varje midnatt.
Har nu bara 3st diagramkurvor i "PV off-grid Operational status" diagrammet, vilket blev mycket tydligare.
Kodat så att tidsangivelser med datum+klockslag nu delas upp och skickas separat för minskad SSE-belastning. Även int_64-tider delas nu upp så tid motsvarande YY:MM:DD skickas separat från tid motsvarande HH:MM:SS.
Hade missat att säkra mot "division by zero panic´ed" där % räknas fram i Tripmätaren samt för Amp-Sources, så är fixat nu.
Förreglat PV-Throttle med 5s innan aktiveras då PWM-regulatorn med väldigt korta pulser blockerar sin laddström ut glest, sannolikt för att detektera ifall det är spänning från solcellerna fortfarande.

2024-08-12
Har modifierat lite kring portENTER_CRITICAL() / portEXIT_CRITICAL() för 2xISR samt där ESP.getMaxAllocHeap() används. Samt även ändrat så ESP.getMaxAllocHeap() bara anropas på ett ställe i koden och den datan lagras i en atomic-variabel för använding på övriga ställen.
ESP.getMaxAllocHeap() anropas bara i Task_LCDbuttonsHandler() nu och då omgiven av portENTER_CRITICAL() / portEXIT_CRITICAL().
Tog samtidigt bort portENTER_CRITICAL_ISR() / portEXIT_CRITICAL_ISR() i båda ISR.
Bör ihop lösa en extremt sällsynt störning i kodexekveringen!
Gav även lite stabilare kodexekvering minnesmässigt.
Men fångade likt förbaskat att det är även en bugg kring Mutex i ESPAsyncWebServer-esphome => AsyncEventSource.cpp vid SSE-data från webbservern till webbsidan! Så får byta till WebSocket för alla webbsidorna så småningom, men är ett rätt stort jobb. Sker dock väldigt glest nu.

Råkade se följande från LiU: "Li-jon: För korta laddcykler är läckströmmar försumbara och Coulombverkningsgraden alltså nära 100%.
Så kan kanske stämma att jag även för mitt 90Ah AGM-blykol vid grunda urladdningar bara ned till strax under 97,5% SoC får mätt 100% Coulombverkningsgrad? Har bara förutsatt att det måste vara ett mätfel, men vad jag kan avgöra verkar ESP32-batterimonitorn nu mäta även 9kHz ströpulsandet från battery reconditioner rimligt korrekt. Men har haft en aningen djupare urladdning och då blev det drygt 97% Coulombverkningsgrad uppmätt. Får testa mer senare.
När mitt experiment AGM-blykol batteri blivit fulladdat (Sync 100% SoC) inom en 24h-period från senaste gången så blir medelsladdströmmen för 24h oftast +10mA - +20mA vid uppnådda 95-97% SoC urladdningsnivå, vilket indikerar väldigt nära 100% batteriverkningsgrad. Att den då vid första "Sync 100% SoC" för dagen mäter 100% coulombverkningsgrad beror på att efter att 0,5% tail-current dektekteras för "Sync 100% SoC" laddas det in några 1/10-dels procent till av SoC-urladdningen som inte kommer med i mätningen, som syns i diagrammet nedan.
Är här i mitt lilla experiment off-grid solcellssystem jag utvärderar batteriverkningsgrad redan när urladdningen bara gått under 97,5% SoC, medan vid drift i mitt riktiga off-grid solcellssystem mäts bara batteriverkningsgrad för urladdning <90% SoC och då blir det helt försumbart!
Går inte att ha lägre än 0,5% tail-current som gräns för detektering av "Sync 100% SoC" för robust tillförlitlig funktion och behövs inte heller vid mer verklig drift i off-grid solcellssystem där den ger en väldigt bra precision i detektering av fulladdat blybatteri. Redan här detekteras fulladdat batteri inom ca 99,7% SoC till 100,1% SoC, en enormt bra precision!
Slutsatsen blir att detta 90Ah AGM-blykol batteri arbetar med extremt bra verkningsgrad vid dessa grunda urladdningar med dessa låga strömmar!

2024-08-21
Lite kodrefaktoring och fixande / optimerande:
Optimerat lite till kring TailCurrentFirstOK så det fungerar än bättre.
Förändrat hur Ah/Wh beräknas / summeras totalt / trip för både solcellsström (PV) och batteriström, så det blir en tydligare mer ensad beräkning av dem, via BattIs100SoC. Innebär att de summeras kontinuerligt så länge inte 100% SoC fulladdat batteri detekteras, då bara PV beräknas / summeras minus det till batteriet då. Ger bättre mätvärden för batteridriften där även små urladdningar kommer med samt får mätvärdena att stämma bättre inbördes. Samtidigt som inte en massa ström som matas in i fulladdad batteribank över lång tid tas med, typ i Standby-drift.
Har även gått igenom alla WebSocket.cleanupClients(); så de fungerar OK för de olika WebSocket baserade webbsidorna! Hittade en kodmiss där för wsOperationalData.cleanupClients(); som kan ha orsakat glesa Panic´ed i ESPAsyncWebServer-esphome kodbiblioteket.
Har gjort förbättringar i webbsidornas Meny-hantering vs SSE / WebSocket så ny webbsida enligt menyval inte aktiveras förrän den initiala belastningen av SSE / WebSocket dataöverföringen är avslutad, genom att räkna antal PulseId´s som är den sista datan som överförs så det krävs 3st PulseId´s innan växlig av webbsida tillåts. Tror det då kan undvika Panic´ed pga av mutex-bugg i ESPAsyncWebServer-esphome. Den har nog bara väldigt glest aktiverats just när jag växlat webbsida snabbt, speciellt då WiFi har fungerat svagt. För när jag nu under två veckor själv manuellt kollat in PulseID så den intitiala dataöverföringen är avslutad har inte den buggen aktiverats vid växling av webbsida!
Har då även lagt in en timer-funktion, så om SSE / WebSocket kommunikationen felar så växlas ändå till ny webbsida 20s efter gjort menyval, så inte detta hänger sig helt då.
Blev en jäkla bra, smidig och effektiv JavaScript-kod för Meny-hanteringen vs SSE / WebSocket för webbsidorna! Som bara märks av när man växlar webbsida lite väl snabbt.
Så är tur jag behärskar både ESP32 C++ / FreRTOS & webbsides Html / JavaScript kodande!
WebSocket Events: Kodat så Events till varje webbsida nu finns i vars sin egen funktion ConfigurationWsEvents(), DataGraphsWsEvents() & OperationalDataWsEvents(), vilket dels tar bort redundant kod för initiering+drift, dels därmed tar mindre plats i ESP32 flash-minnet samt även belastar RAM-minnet mindre då bara den / de av dessa funktioner som aktivt för stunden används till en webbsida laddas in i RAM. Ska inte ha någon redundant kod!
Gör det även lättare att uppdatera funktionen i framtiden och undviker då att missa att uppdatera samma kod på två ställen, vilket annars är en stor felkälla!
Då är allt färdig för fälttestomgång två i husvagnen igen, då det blev några saker såhär jag behövde fixa och uppdatera och gjorde då även lite motiverad kodrefaktoring för ökad effektivitet.

2024-08-25
Efter de senaste gjorda uppdateringarna gick inte ESP32 in i light-sleep längre, så har gjort en väldigt enkel buggfix för det.
Var bara en kodrad med OnWiFiReconnect som råkat hamna innanför en IF()-sats istället för precis allra sist i funktionen utanför den.
Passade även på att optimera de olika villkoren för att gå in i light-sleep inkl. den while()-fördröjning jag har för att låta parallellt exekverande kod exekvera färdig innan tillåts gå in i light-sleep, så att display, tryckknappar, webbserver, 2x TaskDeferredInterrupt, synkning av RTC till NTP-tidsserver, etc hinner exekvera färdigt med sina funktioner först.
Fick därmed vid nattdrift lite ytterligare mer tid i light-sleep och därmed lite ytterligare mer strömsnål drift.
Strömsnål nattdrift är nu 98,75 - 96,25% av tiden i light-sleep, med ett medelvärde på 97,9%!

2024-09-03
Justerat lite till kring portENTER_CRITICAL(&Critical_Section_Mux); så jag bara använder det på två kritiska ställen i koden nu, samt tagit hänsyn till att FreeRTOS API functions must not be called from within a critical section som annars vållar problem. Har även infört en bool INA260Found flag.
Med den nya Task_WiFiSyncRTC() (se ovan), en asynkron FreeRTOS Task för att aktivera WiFi och synkronisera RTC med NTP-tidsservers tid på Internet, blev WiFi-uppkopplingen stabilare och kopplar nu alltid upp snabbt. Eller om det är fixandet med portENTER_CRITICAL() som fick den påverkan. En helt överraskande effekt mot när det hanterades via en annan Task som hanterade många olika uppgifter i den löpande program-loopen eller en portENTER_CRITICAL() med FreeRTOS API-funktion anropad inom / fler portENTER_CRITICAL() kodblock som stör FreeRTOS. Så verkar som WiFi och webbserverns kod körs på ett stabilare mer oberoende sätt nu!
Har nu arbetat helt stabilt i 7 dygn, med webbservern aktiverad med visade webbsidor flertalet gånger varje dag samt även under längre tider. Med autonom automatisk uppkoppling till NTP-tidsserver varje natt för synkronisering av RTC.

2024-09-15
Under liten husvagnstur visade sig några mindre problem med batterimonitorns drift. Var då WiFi / Webbserver var aktiverad via att huvudströmbrytaren var påslagen i husvagnen och WiFi stängs av automatiskt mellan 23:00 och 06:00 och jag manuellt försökte aktivera WiFi / Webbserver då.
Är ingen drift jag kör här hemma så var bara rudimentärt avstestat. Får koppla upp sådan drift här hemma också för mer utförlig testning och optimering av den.

2024-09-20
Uppdaterat till ArduinoJson 7.2.0 som släpptes för ett par dagar sedan. Har bättre och snålare minnesanvändning "memory optimizations for arrays", vilket märks nu efter ett drygt dygns drift med den versionen. Minnesanvändningen blev lite snålare och mer stabil också ser det ut som. Så positivt!
Gör skillnad då jag skickar ganska stora JSON-dataarrayer via WebSocket till webbsidor.
Märks extra tydligt nu när jag visar webbsidorna både i mobilen och på datorn samtidigt och bläddrar runt bland dem på båda enheterna.
Blir intressant att se efter lite fler dygns drift.

2024-09-25
Svarade på frågan om jag driver projektet som open-source och vill få hjälp av andra:
Då jag arbetat med avancerad teknisk utveckling som maskiningenjör under större delen av mitt yrkesliv med mycket jämkande och kompromissande tycker jag det nu som pensionär med eget hobbyprojekt är så skönt att kunna styra det själv helt efter mina egna tankar och idéer.
Så just nu vill jag inte driva det som ett öppet open-source projekt med folk som bidrar, även om säkert mer kunskap på så sätt hade varit till nytta inte minst inom FreeRTOS. Tanken är att släppa det som open-source senare när jag uppnått välverifierad full tänkt grundläggande funktion och stabilitet, men dröjer ännu.
Jag har dock köpt en bra bok om FreeRTOS kodning och läst på mycket, så använder FreeRTOS hyfsat avancerat nu upplever jag.
Samt även läst på om C++11 och C++17 för stabil multitasking / multithreading / multicore kodexekveringen i ESP32.
Kör det som en Event-driven architecture (EDA) kodfunktion via Queue-meddelanden mellan FreeRTOS Task´s där en finite-state machine (FSM) styr och övervakar driften, inkluderande även objektorienterad programmering (OOP).

Om någon annan skulle bidra behöver den själv ha ett eget litet off-grid solcellssystem i drift med samma elektronikhårdvara jag byggt för att kunna testa av funktionen av sitt kodande, annars skulle jag få ägna min mesta tid åt det istället för att förverkliga mina tankar. Samt för närvarande har jag ca 8600 egenkodade rader C++ / FreeRTOS kod (plus alla html / JavaScript webbsidorna), så är rätt maffigt för någon annan att sätta sig in i även om jag prioriterar tydligt skriven kod med kommentarer. Samt då att riktigt förstå hur allt exekverar asynkront parallellt i olika Task's på olika processorkärnor.
Och när jag växlar över i strömsnål nattdrift med drygt 97% av tiden i Light-Sleep då måste kodexekveringen växla till en sorts synkron parallell funktion för att hålla den aktiva time-slot så liten som möjligt, vilket jag dock funnit bra stöd för i FreeRTOS. Är fascinerande att jag med <3% time-slot av total exekveringstid kan hålla igång batterimonitorns funktion att logga all ström, samt känna av de fyra tryckknapparna och uppdatera LCD-displayen med aktuell driftsdata. Ger bra strömsnål drift!
Men då fungerar de två strömsensorerna lite som coprocessorer till ESP32.

2024-09-26 - 2024-10-08
Fixar lite småproblem samt gör en lite större code refactoring på främst de äldre delarna av koden. Så dels jag får till en mer renodlad Event-driven architecture (EDA) kodfunktion via Queue-meddelanden i mellan FreeRTOS Task´s samt går igenom så det inte finns något redundant anrop av olika funktioner så flera instanser av dem körs samtidigt och kan vålla mystiska problem samt belasta RAM. Om en funktion beordras samtidigt från olika delar av koden köas det då i Task Queue och körs i kronologisk ordning efter varandra, vilket är effektivt, minnessnålt och säkert så race-condition och oönskade effekter undviks.

• Aktivering av WiFi / webbserver sker enbart via Queue till Task_WiFiSyncRTC() även hos WiFiReconnect(), så styrs det med vilken Priority det exekveras asynkront samt i vilken Core.
  Då WiFiReconnect() exekveras via WiFi.onEvent() så vet jag inte vilken Prority den exekveras med, men finns tecken på att det är så hög att det stör de inbyggda WiFi-funktionerna om den direkt exekverar StateMach->SetStateWiFi().
• All LCD- och WiFi-statusförändring sker nu via Queue till Task_WiFiSyncRTC().
  Blev inte bra att ha även LCD-statusförändring via Task_WiFiSyncRTC() då den då får invänta WiFi-statusförändring som med 4G-router kan ta sin tid och man då inte får någon direkt respons på aktiverad tryckknapp! Så provar att flytta LCD-statusförändring till direkt i Task_DisplayViewHandler(). Ändrar även Task_DisplayViewHandler() Priority = 3 (1) samt Task_WiFiSyncRTC Priority = 1 (3), så att statusförändring av LCD prioriteras över anslutning till WiFi etc.
  Dessa förändringar för LCD-status fungerar bra och effektivt! Ger även bättre kodstruktur.
• INA260-interrupt stängs av via detachInterrupt() under nattdriftens Light-Sleep, och drivs då via Task_DeferredInterruptIN226(). Minskar risken för problem i Light-Sleep driften!
• Tagit bort näst sista portENTER_CRITICAL(&Critical_Section_Mux); för ESP.getMaxAllocHeap().
• Vid avstängning av WiFi / webbserver aktiveras nu server.end() direkt som första aktion. Har tidigare gett assert failed men fungerar OK nu. Rensar troligen upp buffertar och kod i RAM så risken för minnesläckage och minnesfragmentering minskar. Kanske även ger stabilare funktion för ESPAsyncWebServer-esphome kodbiblioteket över tid.
• Förbättrat WiFi.onEvent() + WiFiReconnect() lite för effektivare funktion och mer funktionssäker. Bl.a infört bool Lost_STA_IP samt server.end(); för bättre funktionssäkerhet. Reaktivering av WiFi / Webbserver sker nu via Queue till Task_WiFiSyncRTC() för styrning av lämplig Priority samt Core för dess exekvering. Vet inte vilken Priority WiFi.onEvent() ger annars.
• Alla SSE.send() villkoras nu med SSE.count() >0 för undvika kodkrasch vid växling av webbsida.
  Men där är fortfarande någon bugg i ESPAsyncWebServer-esphome kodbibliotekt för SSE.send()) som sällsynt ger kodkrasch vid växling mellan webbsidor, även om det sker mer sällan såhär nu:
  assert failed: spinlock_acquire spinlock.h:122 (result == core_id || result == SPINLOCK_FREE)
  Så ska byta till WebSocket för de två kvarvarande SSE-webbsidorna, men är mycket kodande för dem så avvaktar lite.
• Task_LCDbuttonsHandler() interagerar nu bara via Task Queue-meddelanden.
• Task_DisplayViewHandler() interagerar nu bara via Task Queue-meddelanden.
• Provat att flytta Task_WiFiSyncRTC() till Core0, vilket verkar OK. Är 3st Task i Core0 nu.
• Försett några fler variabler med std::atomic<> som används mer globalt av flera olika FreeRTOS Task´s, för undvikande av race-conditions. Någon jag missat orsakade problem.
• Tagit bort static för en del lokala variabler i Task´s.
• Har i Task_WiFiSyncRTC() infört while (eTaskGetState(TaskDisplayViewHandler) != eBlocked) i case StateMachine::LCD_ON: för att "lets Task_DisplayViewHandler() finish execution to lit up LCD" direkt när trycknapp aktiveras vid släckt LCD, vilket fungerar perfekt! Då Task_WiFiSyncRTC() har högre prioritet än TaskDisplayViewHandler exekveras annars aktivering av WiFi färdigt i Task_WiFiSyncRTC() innan LCD-displayen tänds upp. FreeRTOS är häftigt!
• In Task_DisplayViewHandler() made switch(StateMach->LCDState) conditional with if(OldLCDState != StateMach->LCDState) to only execute when needed.
• Märkligt att WiFiReconnect() fungerar bara med WiFi.onEvent(), event == ARDUINO_EVENT_WIFI_STA_LOST_IP som kommer exakt 120s efter _arduino_event_cb(): STA Disconnected som har _arduino_event_cb(): STA Stopped tätt i släptåget, så man får ha livlig fantasi och kreativitet i sitt felsökande! Så ändrat till det nu och då får jag stabil funktion även med utnyttjande av server.end(); trots vad som sägs här om Bind error: -8 för felkod AsyncTCP.cpp:1334] begin(): bind error: -8 som jag fick tidigare! Utan server.end(); har det ofta fungerat förut, men med andra nackdelar. Så är bra att jag nu kan använda server.end();!
  Error -8 = Address in use, ger en ledtråd om förklaringen!
  Lite synd det måste ta 120s att återansluta WiFi / webbserver, men det viktiga är att det fungerar stabilt! Har aktiverat WiFiReconnect() upprepat nu simulerat med WiFi.mode(WIFI_OFF) via tryckknapp.
• Då det krävs WiFi.onEvent(), event == ARDUINO_EVENT_WIFI_STA_LOST_IP för automatisk återanslutning av WiFi måste samma gälla för manuell återanslutning, så har infört ett sådant villkor där också. Både via ARDUINO_EVENT_WIFI_STA_LOST_IP / ARDUINO_EVENT_WIFI_STA_GOT_IP (≤120s) samt via en tidsgräns på 200s som backup för säker funktion.
  Normalt aktiverar man WiFi manuellt glesare än detta, så kommer inte märkas av i praktiken.
  Är nog förklaringen till att jag ett par gånger haft IP-adress men webbservern inte fungerat.
• Totalt har allt detta gett drygt 20% lägre strömförbrukning under nattströmspardrift i light-sleep ca 98% av tiden, ca 7mA nu! Skoj då mitt mål har varit <15mA.
• Ökat så det nu krävs 5st (3st) PulseId´s innan växlig till ny webbsida tillåts i Meny-hantering så ny webbsida enligt menyval inte aktiveras förrän den initiala belastningen av SSE / WebSocket dataöverföringen är avslutad.
• Infört att gå in i nattströmspardriftens light-sleep måste invänta Lost_IP, WiFi.onEvent(): event == ARDUINO_EVENT_WIFI_STA_LOST_IP för att ge tid till ESP32´s WiFi-systemprogramvara och webbserver att stänga ned korrekt under ESP32 i aktiv drift. Som för webbservern att stänga alla SSE / Websocket uppkopplingar. Löste några frågetecken jag haft!
  Detta ger perfekt kodfunktion, även om det är synd att behöva vänta ca 120s på att få Lost_IP, som ESP32´s WiFi-systemprogramvara tar på sig för det. Gäller främst vid WiFiReconnect().
  Är förvånansvärt komplext att implementera light-sleep OK för nattdriften! Är både detta med Lost_IP men även hur de olika FreeRTOS Task´s samverkar OK med nattdriftens light-sleep. Får då en interruptsignal från INA226 som väcker upp ESP32 ca 1ggr/s från light-sleep när det finns nya aggregerade mätdata att hämta, som då läses av, bearbetas och uppdateras på LCD-displayen via olika FreeRTOS Task innan ESP32 går in i light-sleep igen, vilket hinns med i den ca 2% tidslucka som detta tar i anspråk adaptivt och ger ca 98% tid i light-sleep.
  Nu fungerar dock allt detta extremt bra kodmässigt under exekvering!
• Provat drygt 20ggr nu och fungerar perfekt stabilt enligt nedan exekverade sekvens:
  20:30:16.183 > Today date from NTP: 2024-10-03 20:30:16
20:30:16.183 > ====================================================
20:42:01.313 > [5205178][D][main.cpp:3921] WifiHandler(): server.end()...
20:42:01.414 > [5205287][V][WiFiGeneric.cpp:363] _arduino_event_cb(): STA Disconnected: SSID: xxx, BSSID: xxx, Reason: 8
20:42:01.430 > [5205300][D][WiFiGeneric.cpp:1040] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
20:42:01.448 > [5205302][V][WiFiGeneric.cpp:344] _arduino_event_cb(): STA Stopped
20:42:01.451 > [5205314][W][WiFiGeneric.cpp:1062] _eventCallback(): Reason: 8 - ASSOC_LEAVE
20:42:01.451 > [5205321][D][main.cpp:7354] WiFiReconnect(): StateMach->WiFiState, 4=ON, 6=OFF: 6, Time: 5205321
20:42:01.465 > WiFi.onEvent(): No WifiReConnect, Event: 5
20:42:01.465 >
20:42:01.465 > wifi_sta_disconnected.reason: 8
20:42:01.465 > [5205330][D][WiFiGeneric.cpp:1040] _eventCallback(): Arduino Event: 3 - STA_STOP
20:42:01.482 > [5205344][D][main.cpp:7354] WiFiReconnect(): StateMach->WiFiState, 4=ON, 6=OFF: 6, Time: 5205344
20:42:01.482 > WiFi.onEvent(): No WifiReConnect, Event: 3
20:42:01.497 >
20:42:03.813 > [5207685][D][main.cpp:6906] Task_WebServerESP32(): Time to close all SSE / Websocket: 1300 (ms)
20:44:01.442 > [5325301][V][WiFiGeneric.cpp:375] _arduino_event_cb(): STA IP Lost
20:44:01.448 > [5325307][D][WiFiGeneric.cpp:1040] _eventCallback(): Arduino Event: 9 - STA_LOST_IP
20:44:01.454 > [5325315][D][main.cpp:7354] WiFiReconnect(): StateMach->WiFiState, 4=ON, 6=OFF: 6, Time: 5325315
20:44:01.463 > WiFi.onEvent(): No WifiReConnect, Event: 9
20:44:01.976 > [D][main.cpp:1646] StateHandler(): Initiates Light-Sleep night operation...

• Har på webbsidan "System Operational Data" infört 4st till loggade data i "MIN HEAP (RAM)", så jag kan följa HEAP/RAM utnyttjande mer i detalj över tid även för Light-Sleep nattdrift. Ser då bättre om det uppstår något minnesläckage eller fragmentering samt vad RAM-minnesanvändningen stabiliserar sig på.
  Mäter maxvärdena under varje light-sleep natt­drifts­period (LS), vilket blev jättebra.
• All exekvering av BattDynDataSaveViaPreferences() sker nu via Task_WiFiSyncRTC(), så köas upp ihop med aktivering av WiFi / webbserver exekveringen samt synkning av RTC till NTP-tidsserver.
  Så de exekverer numerer sekventiellt efter varandra så de aldrig kan krocka.
  BattDynDataSaveViaPreferences() vid boot / reset skickas som queue-meddelande till Task_WiFiSyncRTC() vid andra loopen i StateHandler(), vilket innebär att den hamnar i kö efter synkning av RTC till NTP-tidsserver via aktiverad WiFi / webbserver och exekveras först efter att RTC synkat sin tid. Därmed sker den databackupen först när allt är i stabil drift efter reset! Kan då inte heller krocka med när RTC synkas automatiskt vid varje midnatt!
  BattDynDataSaveViaPreferences() har optimerats lite med vTaskDelay() mellan varje skrivning till LittleFS för delegering av exekveringen då den tar ca 2s för att spara all data.
  SetDataToRTC() fick en liten bugg-fix.
  Samt en till variable har fått std::atomic för att undvika en potentiell race-condition. Är sammanlagt 103st nu i min kod, troligen inte alla nödvändiga men är lite abstrakt att analysera vilka som verkligen behövs i så stor kodmassa. Fungerar i alla fall bra nu!
  

  
  

• Task_WiFiSyncRTC() får ta hand om all asynkron exekvering som inte behöver ske i sekvens med Interrupten från INA226-strömsensorn samt som kan ta lite längre tid och/eller inte får ske samtidigt utan köas där, medan Task_StateMachine() tar hand om den asynkrona exekvering som ska ske i sekvens med Interrupten från INA226-strömsensorn och hinnas med inom dess loop-tid. Ger en bra uppdelning för min Event-driven architecture (EDA) kodfunktion.
  Funderade ett tag på om webbserverns funktion skulle flyttas över till Task_WiFiSyncRTC(), men gör sig nog bäst som sin egna Task_WebServerESP32() då den ska exekveras i sekvens med Interrupten från INA226-strömsensorn och inte blockas av andra längre exekveringar, samtidigt som den exekverar parallellt med annan kod i andra Task´s.
• Har åter justerat alla 8st Task stack space efter 5 dygns kontinuerligt drift då Task minimum free stack space loggas. Tänker att efter fem dygn bör det ha stabiliserats på sin miniminivå i max utnyttjande av varje Task´s allokerade stack minne.
  Justerade även Task_SetupESP32´s Task priority till 8, så den får högst prioritet av mina Task. Provad även med prioritet 1, men det blev sämre ur Heap / RAM minnes synpunkt. Provad även att ta bort Task_SetupESP32() helt och anropa setupESP32() sist i setup(), men det blev ännu sämre för Heap / RAM minnet! Så är rätt uttänkt. Bra att ha verifierat detta.
  Siktar på ca 1002b minimum free stack space nu och 500b sedan när allt är långtidsvaliderat:
  Task minimum free stack space, allokated, new (bytes):
  1.TaskSetupESP32: (1580), 3400, 2820
  2.TaskDisplayViewHandler: 1524, 3550, 3028
  3.TaskLCDbuttonsHandler: 1076, 2200, 2126
  4.TaskWebServerESP32: 1272, 3500, 3230
  5.TaskDeferredInterruptINA226: 1392, 2600, 2210
  6.TaskDeferredInterruptINA260: 1012, 2800, 2790
  7.TaskStateMachine: 2096, 4000, 2906
  8.Task_WiFiSyncRTC: 0808, 3800, 3994
  
• Validerat noga nu 2024-10-15 att driften då WiFi+webbserver aktiveras av påslagen huvudströmbrytare i 12V elsystemet, och då har ett automatiskt nattuppehåll, fungerar med att man under nattuppehållet manuellt via tryckknapp aktiverar WiFi+webbserver. Har inte validerat just det tidigare och fick lite problem med den funktionen under senaste husvagnsturen. Men har sedan dess optimerat funktionen kring det som del av denna code-refactoring.
  Nu fungerade detta perfekt och stabilt testat ett flertal gånger! Så har blivit optimerat.
• Byt C String class till C++ std::string då de ska minska risken för heap-fragmentering, exekvera snabbare och ger mer funktionalitet, samt kanske std::vector. Se mer ovan
  "While both string classes use dynamic memory, most implementations of std::string have Small String Optimizations (SSO), where small strings are allocated on the stack instead of the heap. This can slightly reduce the amount of fragmentation caused by the strings."
  Alla String är nu utbytta mot std::string där det är möjligt.
  Har även ersatt en del av std::string med std::string_view, speciellt i funktions-parametrar. Samt använder std::string.reserve() för att undvika heap-fragmentering.
  Är färdigfixat 2024-11-01 och fungerar bra! Ser ut att bli lite bättre minneshantering av det.
  Men är några till jag ska titta på senare ihop med SSE.send(). Har inte hittat något smidigt sätt för ersättning där, men tror inte heller det är så kritiskt i den användningen.
  Nu är även alla String ihop med SSE.send() fixade och fungerar bra via egenkodad funktion som ersätter. (2024-11-02)
  De 17st String som nu är kvar i koden är till externt kodbibliotek som kräver det, i funktionen processor() för webbservern ESPAsyncWebServer-esphome. Är 33st std::string data samt 3st std::string_view definierade i koden nu.
• DisplayHandler() till LCD-displayn är nu optimerad och omkodad enligt C++17 inkl. std::string_view, std::string, std::vector<std::string> & static_cast<std::string>. (2024-11-02)
• Bytt till C++17 std::max(), std::min() & std::abs() C++ Standard Template Library (STL) funktioner överallt i koden, vilket även gav mindre heap-fotavtryck då troligen färre funktioner länkas in. Där jag även använder std::string::length(), std::string::capacity(), std::string::size() etc enligt ovan. C++ STL Cheat Sheet (2024-11-03)
• Flyttat all GetFreeHeap-data till överst i webbserverns kodblock för eventsSystemData så de heap-datavärdena mäts innan alla eventsSystemData.send() som påverkar med sina varierande antal exekveringar. Får en stabilare mer repeterbara mätning av heap-minnesdata på så sätt som blir lättare att analysera och följa.
• All code-refactoring såhär långt till mer C++17 kodstil med mer användning av C++ Standard Template Library (STL) funktioner m.m. har gett en minskad dynamik i heap-minnes användningen, vilket bör ge en stabilare 24/7/365-drift över lång tid. (2024-11-03)
• Bytte från sprintf() till snprintf() resp. snprintf_P() överallt för att dels få minnessäkrare kod då man undviker att det skrivs utanför allokerad buffers storlek vid tankefel, samt dels för att spara SRAM-minne och läsa direkt från Flash vid större format-sträng (2024-12-31):
  Formatted output with sprintf() & Co
  char buf[46];
snprintf_P(buf, sizeof(buf) / sizeof(buf[0]), PSTR("Datan är: %04u"), datavariabel);
Serial.println(buf);
  
• Vid uppdatering av koden återladda 24h statistiken - checka för ny compile-time - Fixat!
  Varje gång diagramdatan sparas så sparar jag nu även RTC-Epoch-time och jämför med vid boot/reboot/reset och om det är <3hr sedan senast åtställs all 24h diagramdatan. Väntar då nu även in att RTC synkat med NTP-tidsserver.
  Och efter det sparas 24h digramdatan igen, via att den läggs i kön till Task_WiFiSyncRTC(), så fast asynkront så köas de i Task här sekventiellt synkront med varandra.
  Så fungerar även när ny programkod laddas upp i ESP32. (2025-01-05)
• Fixat så även WebSocket nu kan återansluta automatisk efter förlorad kontakt med webbservern, vilket då även fungerar efter panic´ed kodkrash eller andra orsaker till soft-reset. Även efter uppladdning av ny programkod. (2025-01-12)
  Förfinat detta så det nu hanterar alla olika drifsfall robust korrekt, bl.a. med att utgå ifrån SSE.onError. (2025-01-27)
• Vid paniced kodkrasch så återaktivera WiFi / webbserver efter rebooot om den var aktiverade vid paniced.
  Löst det genom att webbservern inte stängs ner efter RTC synkning med NTP-server om någon webbsida återanslutit sin WebSocket / SSE då, avkänt via SumCountWebsocketSSE() funktionen. (2025-01-12)
• Överför en del av webbsidan "System Operational Data" till "Battery Cycle Data" för dels tydligare och med mindre innehåll per webbsida, dels mindre belastning på webbservern som kanske kan eliminera de nu väldigt glesa panic´ed kodkrascherna hos webbservern.
  Får därmed driftdatan uppdelad tydligt i "senaste 24hr", "battericykel" med senaste och pågående, aktuell driftsöversikt samt systeminfo över driften.
  Fixat färdigt 2025-01-20.
• Rensa upp och gör tydligare i setup() & setupESP32(), så funktionen för all PowerOn-reset och för soft-reset omstart blir tydligare och mer renodlade. Så det blir lättare att vidareutveckla i framtiden och förstå sig på då! Tror det är lite redundant kod där nu med att hämta/återställa preferences-data samt när det görs för de olika driftsfallen är lite otydligt.
  Var en del redundant kod som nu fixas, så blivit tydligare kodstruktur, minnessnålare samt lättare att uppdatera framöver.
  Nu är boot / reboot / reset uppdelad i fem tydliga driftsfall:
  - case Brownout: direkt omstart vid låg matningsspänning
  - case ColdPowerON: första boot efter spänningspåslag eller efter uppladdad kod
  - case SoftPowerON: PowerON efter Soft-Reset där osparad driftsdata sparats och återställs
  - case SoftReset: Soft-Reset där osparad driftsdata sparas via RTC Slow memory
  - case VeryFirstBoot: vid allra första boot innan någon driftsdata sparats
  Är därmed en mycket bättre tydligare kodstruktur nu där man tydligt ser vad koden gör! Därmed blir den även mycket lättare att underhålla och uppdatera framöver.
  Var ett stort tungt code-refactoring jobb! Färdigt 2025-01-25.
• Ändrat så att i webbsidornas meny-hantering den växlar till ny vald webbsida i menyn först när SSE / WebSocket datan PulseInd indikeringen fått sin nya data, vilket är den sista i varje dataöverföring. Därmed sker växling av webbsida säkert synkront med när webbservern i ESP32 skickar SSE / WebSocket data så inte data skickas till en just nedstängd föregående webbsida.
  Har kunnat lokalisera väldigt glesa panic´ed kodkrascher i webbservern till just den situationen, att data skickas till den föregående webbsidan man just växlat ifrån, vid växling från SSE-webbsida till WebSocket-webbsida. Förhoppningsvis elimineras dessa kodkrascher på detta sättet, samt känns som ett välkodat sätt att hanter webbsidor som det skickas mycket SSE / WebSocket data till, som mina här. (2025-01-26)
  Gav även lite mindre RAM-/HEAP-minnesbelastning när man bläddrar bland webbsidorna (mer MinFreeHeap kvar), vilket är rätt naturligt när man tänker efter.
• Fixa att även diagrammet i index.html automatiskt skalar till mobilens webbsidesfönsters storlek!
• Bytt ut alla C array[ ] till C++ std::array< > / std::vector< >. (2025-01-29)
  Introduction to std::array, Learn C++
  std::array length and indexing, Learn C++
  std::vector resizing and capacity, Learn C++
  std::array vs C-style Arrays, Studyplan
  Dynamic Arrays using std::vector, Studyplan
  C++ Why Use std::array?
  C++ Declaration and Initialization of std::array, 1-10 avsnitt
  C++ Accessing Elements in std::array
  Arrays and std::array - Benefits of Using, Bounds-checking with .at()
  array at() function in C++ STL, GeeksForGeeks
  STD::array in C++, GeeksForGeeks
  Is it possible to create an atomic vector or array in C++?
  Förutom säkerheten med boundary-checking och mer funktionalitet fås även en enklare tydligare kod men renare notation, typ:
  for (int i = 0; i < (sizeof(RingBuff1hrAvg) / sizeof(float)); i++)
{
  RingBuff1hrAvg[i] = 9e+009f; // To indicate / distinguish not yet used Array-items
}
till:
RingBuff1hrAvg.fill(9e+009f); // To indicate / distinguish not yet used Array-items
respektive:
std::copy(std::begin(RingBuff1hrAvg), std::end(RingBuff1hrAvg), std::begin(RTC_24hrUnsavedData.RingBuff1hrAvg));
till:
RTC_24hrUnsavedData.RingBuff1hrAvg = RingBuff1hrAvg;
Och fast jag bytt ifrån C array[ ] till std::array.at( ) överallt i koden så exekverar koden något snabbare nu. Så den minimala extra exekveringstid .at( ) tar uppvägs mer än väl av att övrig kod runt array blir effektivare!
• xxxx
• xxxx
• xxxx
• Checka för förlorad IP-adress / nedstängd Webbserver utan aktiverad WiFiReconnect() - återaktivera
• Mät ytterligare lite Ah-laddning efter Tail-current synkronisering för rätt batteriverkningsgrad - OBS måste synkas med all loggning av Ah
• UTC-tidsstämpla loggdata
• Använd if(sntp_get_sync_status() == SNTP_SYNC_STATUS_COMPLETED) även som kvittens vid uppkoppling mot WiFi att ESP32 fått kontakt med Internet, vid loggdatalagring på webbhotellet!
  Görs via variabeln: if(StateMach->InternetSyncOK == true)
  ESP-IDF Espressif IoT Development Framework Programming Guide: sntp_get_sync_status()
  #include "esp_sntp.h"
// Checks if RTC SNTP update is completed
if (sntp_get_sync_status() == SNTP_SYNC_STATUS_COMPLETED)
{
}
Då vet man dessutom att RTC är synkroniserad med NTP-tidsservern på Internet för 100% korrekt tidsstämpling.
  
• Kolla om att flytta webbsidors filer till LittleFS och includera CSS och JS direkt därifrån som man bör och helt skippa funktionen processor(const String& var) för Webbservern!
  Skulle då dels bli av med de sista String, dels säkert minska RAM-minnesbelastningen när webbsida skickas. Kanske ladda upp respektive fil från de variabler jag nu håller dem i till LittleFS under boot för samma smidig hantering som idag, när kompileringsdatum är färskt / nytt? Nog även minska risken för minnesläckage då hanteringen av processor(const String& var) verkar dåligt kodad!
• Se över användningen av static variabler i Task´s!
• xxxx
•  Till dokument slut 

Inte bara mitt kodprojekt som tar tid att få till alla detaljer i: Victron Venus OS Beta v3.50, it is still in beta, porting all the features and functions of the old UI over to the new one is an enormous task, and I expect that to take several more months. Sannolikt av ett helt team.
Och Victron kodar ändå "bara" om UI medan jag kodar både helt eget UI och hela mät­dat­ain­sam­ling­en och analysen med förädling av rådata till information och statistik i mitt helt själv!
Men min ESP32-batterimonitor har varit i kontinuerlig drift ca 1 år nu med korta avbrott för koduppdatering som förbättrar och stabiliserar funktionen samt gör koden effektivare.

2024-10-13
Projekt ESP32-batterimonitor:
Håller på att validera programkodens funktion och stabilitet lite mer noga nu, vilket är spännande och intressant.
Här från 7 dygns kontinuerlig drift utan reboot / reset där dels kodstabilitet i exekveringen mäts, samt dels om det är något problem med minnesläckage eller minnesfragmentering av HEAP / RAM.
Att få ESP32 att arbeta helt stabilt 1-2 dygn är inget problem, men redan vid 5 dygn och med WiFi och webbserver aktiva börjar problem visa sig om inte programkoden är riktigt bra. Och för minnesläckage / fragmentering behövs det åtminstone ca 7 dygn för att se att de värdena stabiliserar sig och inget synbart minnesproblem uppträder, men kräv nog omkring 30 dygn för att ha tillräcklig stabila resultat för att känna sig säker.
Har tidigare validerat över 20 dygns kontinuerlig drift med lite stresstester med OK resultat, men hade inte lika många olika loggade data då.

Såhär lång under 7 dygn ser allt stabilt ut utan några synbara minnesproblem.
Under nattdrift med 97% Light-Sleep (LS / L Sleep) har "LS MacAllocHeap" (från ESP.getMaxAllocHeap()) varit samma 81908b ända sedan boot som ett väldigt bra tecken mot fragmentering, "the largest free block of memory able to be allocated". Samt "L Sleep FreeHeap" (från ESP.getFreeHeap()) har stabiliserat sig kring 199696b, men är något dynamiskt och har t.o.m. ökat något senaste dygnet.
"MaxAllocHeap" mäts med WiFi / webbserver i drift då SSE-data (Server-Sent Events) hela tiden skickas till visad webbsida på dator / mobil och har nu stabiliserat sig kring ca 73716b, men varierar lite dynamiskt med dataflödet från webbservern. Samma för "FreeHeap" som stabiliserat sig kring ca 117260b, men som varierar rätt dynamiskt med webbserverns drift och blir lite olika var gång WiFi / webbserver aktiveras.
De minnesstorlekar som mäts under nattdrift med 97% Light-Sleep utan WiFi / webbserver aktiva blir stabilast och ger nog allra bäst data för stabiliteten i minnesanvändningen. Och det ser väldigt bra ut för dessa 7 dygns drift!

Har en liten kodfunktion till jag ska uppdatera / optimera, sedan göra en noga stresstest och därefter om OK installera i husvagnen också, och om allt ser OK ut då ska jag ta en längre paus från detta och får då längre driftstider systemet valideras över.

2024-10-14
Senaste battericykeln nu tog 5 dygn (00y00m04d 23:01:00) innan blykol-batteriet blev fulladdat igen, med rätt mulet väder flera av dagarna.
Detektering av fullt batteri för synkning till 100% SoC skedde då vid 100.2% SoC, så riktigt bra precision även över några dygns battericykel såhär.
Battericykeln var nere på 93.6% SoC som lägst och totalt cyklades då -6.9Ah ur 90Ah AGM-blykol batteriet.
Solladdregulatorn började begränsa laddströmmen först vid 99.5% SoC, så fram till dess tog blykol-batteriet emot full laddström från solcellerna, som nog var rätt låg i vädret som var.
Så riktigt bra precision och exakt funktion även över fem dygns battericykel!
Innebär att onoggrannheten över 5 dygns battericykeln var ca 0,2% SoC till fulladdat blybatteri!
Bättre än jag från början trodde var möjligt och sannolikt minst lika bra som de bästa batterimonitorererna för småskaliga off-grid solcellssystem på marknaden, eller troligen bättre!

2024-10-21
Installing ottowinter/ESPAsyncWebServer-esphome @ 3.3.0 - ny uppdaterad version av webbservern (från 3.2.2)! Full Changelog
- Adds "try_" overloads that return false if the message could not be queued for send, and adds an onDisconnect callback (#43)
- Bugfix: AsyncEventSource writes multiple events per tcp send, including partial events that straddle buffers; Improvement: don´t hold onto event items until ack, immediately remove them from queue (#41)
Låter intressanta båda som kanske lösning på mina problem där, så kanske både blir stabilare och lite minnessnålare så får testas snarast (inkl. min egna buggfix i kodbiblioteket)!
2024-10-22
Fungerar OK, samt blev märkbart snabbare för min SSE-webbsida med mycket data, där all den stora SSE-datamängden nu i stort uppdateras momentant så snabbt som webbläsaren kan skriva ut den på skärmen. Ser ut att använda lite mindre minne också speciellt MinFreeHeap / Min MaxAllocHeap, men ser jag tydligt först efter minst en veckas drift.
Min buggfix #5 i WiFiMulti.cpp hade kommit bort i någon uppdatering från Espressif så lade in den igen, vilket gav lite stabilare initiering av anslutning till WiFi igen!
Blev inte bra att ha även LCD-statusförändring via Task_WiFiSyncRTC() då den då får invänta WiFi-statusförändring som med 4G-router kan ta sin tid och man då inte får någon direkt respons på aktiverad tryckknapp! Så provar att flytta LCD-statusförändring till direkt i Task_DisplayViewHandler(). Ändrar även Task_DisplayViewHandler() Priority = 3 (1) samt Task_WiFiSyncRTC Priority = 1 (3), så att statusförändring av LCD prioriteras över anslutning till WiFi etc.
Dessa förändringar för LCD-status fungerar bra och effektivt! Ger även bättre kodstruktur.
Efter fem dygn med ESPAsyncWebServer-esphome v 3.3.0 och lite stresstester kan jag konstatera att den fungerar stabilt och väldigt bra, med en helt annan snabbhet i respons än tidigare! Lite som jag från början hade förväntat mig, så är skoj det kom nu.

2024-10-26
Intressant att FreeRTOS nu har blivit SESIP Level 3 certified (Security Evaluation Standard for IoT Platforms)!

2024-10-27
Inatt skiftade det till vintertid kl.03:00 till kl.02:00, så checkade hur realtidsklockan i mitt ESP32-projekt hanterade detta.
Mitt ESP32-projekt kopplar automatiskt upp till NTP-tidsserver på Internet 1ggr/dygn strax efter midnatt för synkning av realtidsklockan, så har inte varit uppkopplad mot Internet / WiFi under eller efter skiftet till vintertid inatt. Men visade ändå korrekt tid nu på morgonen på LCD-displayen, så uppenbarligen hanterade dess programvara kodad i C++ med Espressif Arduino Framework tidsomställningen korrekt utan kontakt med Internet eller WiFi-uppkoppling aktiv.
Känns bra för mitt ESP32-batterimonitor projekt som tidsstämplar sin loggdata utifrån tiden hos ESP32's inbyggda realtidsklocka!
Sedan exakt vad denna skiftning av tid en timme medför för den loggade datan har jag inte analyserat ännu!
Men själva loggningen av batteribankens laddnivå (SoC) görs oberoende av realtidsklockans tid, så den förblir korrekt opåverkad av tidsomställningen. Är bara loggdatan för presentation av driften i diagram som påverkas av att realtidsklockan ställs om såhär.

Blev lite bra diskussioner på Facebook kring ett inlägg jag gjorde om detta som gav input till bra reflektion!
Syns inget märkligt i mina diagram vid 2-3-tiden inatt, men beroende på hur jag loggar så har ju upp till en timmes data skrivits över.
Så får fundera vidare kring detta om jag ska basera tidsstämplingen på UTC tid istället (eller om jag kanske redan gör det).
Har hittills haft fokus på så mycket annat i kodfunktionen så inte gått djupare in i denna aspekten ännu. Men nu när allt annat börjar fungera problemfritt precis som tänkt blir det tid att titta igenom sådana här aspekter i projektet också. Lite därför jag observerade vad som hände idag.
Men oavsett hur man gör så i själva presentationen såhär i diagram med visad lokal tid längs X-axeln kommer det alltid få en påverkan just dessa dygnen med tidsomställningen, så kan kräva lite mer genomtanke hur jag hanterar det kodmässigt. Om jag UTC-tidsstämplar loggdatan så kan jag utgå ifrån senaste aktuell lokal tid för hela 24 timmars perioden och bortse ifrån att det skett ett 1h tidsskifte vid kl.03-tiden på natten! Ger mest korrekt diagram mot verkligheten!
Men den bakomliggande loggdatan ska helst ha en tidsstämpling som inte påverkas av dessa tidsomställningar, för att kunna göra korrekta analyser på den!
Så känns nog som jag borde tidsstämpla loggdatan med UTC-tid, så får ta och tränga in i det igen och sätta upp som en till punkt för den större code-refactoring jag håller på med nu.
Lite om detta med tidskodning: Falsehoods programmers believe about time.

2024-10-28
Nu är det 8,5 dygn sedan (Last Sync: 00y00m08d 18:00:06) mitt AGM-blykol batteri blev fulladdat här hemma i mitt lilla experiment off-grid solcellssystem. Har varit mulet väder samt årstiden nu ger inte så mycket solcellsström här.
Det har då cyklas fram och tillbaka i s.k. PSoC-drift (Partial State of Charge). Batterimonitorn mäter då hela tiden hur mycket ström som laddas ur och laddas i och summerar skillnaden mellan dem för att få fram laddstatus i batteriet, både i urladdade Ah och som SoC.
Just nu -4.513Ah / 95,0% SoC.
Min ESP32-batterimonitor mäter / summerar även då all urladdad ström tills nästa gång batteriet blir fulladdat dvs hur mycket ström som cyklats ur batteriet under pågående battericykel.
Just nu ∑-13.4Ah under dessa 8,5 dygn.
Jag tycker det är intressant att kunna se båda de mätta värdena för batteridriften, då ∑-13.4Ah talar om hur mycket batteriet fått jobba.
Vid längre PSoC-drift såhär över flera dygn är det även intressant med den statistiska Time-To-Go tidsprognosen för batteridriften, där jag har både för senaste 1h driften samt för senaste 24h driften.
Just nu ↓30d06h (24hr) resp. ↑07d04h (1hr). Dvs 24h statistiken talar om att strömmen räcker till 30dygns drift ytterligare under samma förhållanden samt 1h statistiken säger just nu att det krävs drygt 7dygn tills fulladdat batteri med senaste timmens förutsättningar.

Några kommentarer på sociala media:
"Varken Victron enheternas egna statistik eller den delstatistik som skickas till VRM är tillräckligt bra. I jämförelse med ovan nämnda statistik så ligger Victron långt efter."
"Väldigt bra användning av data, tycker du tänker helt rätt."
"Detta är alltjämt ett av de mer ambitiösa och väl genomförda projekt jag sett på en stund!"

2024-10-29
Ändrar WiFi.setAutoReconnect(false); till WiFi.setAutoReconnect(true); som test.

2024-11-07
Volvo Cars: "Elektrifiering och datorisering är två omvälvande skiften inom bilbranschen som av närmast en tillfällighet just nu sker samtidigt. (Anders Bell, teknikchef / CTO)
Elektrifieringen är den enklare av de båda, enligt Anders Bell, och den som Volvo har nått längst inom. Kompetensen finns på plats och ingenjörerna jobbar oförtrutet med att förbättra tekniken."
Så lär ju även gälla den avancerade datorisering av off-grid solcellssystems driftsövervakning och styrning som jag utvecklar här (att det är svårt och tar tid att utveckla)!

I dagens solsken med 19 dygns PSoC drift började 2h PV-Throttle vid drygt 98% SoC samt laddnivån nådde 99,8% SoC under PV-Throttle drift utan att fulladdat batteri detekterades. Laddströmmen var då nere på ca 0,6A och vid 0,45A Tail-current detekteras fulladdat batteri, så väldigt nära.
När PV-Throttle påbörjades gick ca 88% av solcellsströmmen till batteriladdning.
Under dessa 19 dygns PSoC drift (Partial State of Charge) har då totalt ∑-19,6Ah cyklats och -0,164Ah / 99,8% SoC blev den högsta laddnivån idag.
Tyder på fin hög precision i mätningen av batteribankens SoC-laddnivå vid längre PSoC drift!

2024-11-08
Idag blev fulladdat AGM-blykol batteri detekterat via 0,5% tail-current vid 100,6% SoC i slutet av ca 2h PV-Throttle och ESP32-batterimonitorn synkade sin 100% SoC.
Var efter 20 dygns PSoC drift (Partial State of Charge) vilket är en helt otroligt hög fin precision att logga SoC-laddnivån så exakt under 20 dygn! Trodde inte jag var möjligt att nå den precisionen via Coulomb-counting (CC)! För 90Ah AGM-blykol batteriet registrerades +0,507Ah då fulladdat batteri detekterades som ger 100% * 90,507Ah / 90Ah = 100,56% SoC.
Om jag minns rätt var lägsta SoC = ca 93% under denna 20 dygns battericykel.
Räknar man på att det denna battericykel cyklas ca -21Ah och då ca +22Ah så ger det 100% * 0,507Ah / 43Ah = 1,2% summerat mätfel, men precisionen är högre än så då trots hög precision onoggrannhet i detekteringen av fulladdat batteri är en signifikant del i de +0,507Ah. Samt beräkningarna av laddnivå / SoC gjordes med något för hög batteriverkningsgrad (99,4%) då den inte tidigare beräknas för så lång battericykel som ger bättre precision för den.
Hade dessa -21Ah cyklas i ett svep hade det motsvarat en urladdning ned till 76% SoC.
Har sett minst samma mätprecision vid lite djupare urladdning över 4-5 dygns PSoC drift.
Så sannolikt är mätfelet <0,5% för ∑Ah till SoC-beräkningen över en 20 dygns PSoC drift!
Nu är detta mätt med låg strömbelastning på blybatteriet och mätprecisionen blir bättre vid högre strömbelastning, vilket gör resultatet än bättre.
Vid så små battericyklingar så måste även nattströmmen på 12-20mA mätas med hög precisionen över 60A strömschunten för att uppnå denna mätprecision!
Nu var detta första 100% SoC synkning efter koduppdatering så då sparas tyvärr inte statistik för själva battericykeln mer än det som visas som senaste 24-statistik.
Detta är första indikation för mätprecisionen över längre PSoC drift, men blir intressant att senare se sådana mätningar från husvagnens off-grid solcellssystem.
Dessa mätvärden indikerar även en hög AGM-blykol batteriverkningsgrad omkring 97-98% vid denna 20 dygns battericynkling inom ca 99-93% SoC, vilket är extremt mycket bättre än hos traditionella blybatterier vid så grund cykling.

2024-11-16
Var ute på husvagnstur 2024-10-17 - 19 med min ESP32-batterimonitor loggandes batteridriften i mina Victron lead-carbon AGM-batterier. Ger en väldigt fin överblick över batteridriften och laddningstillståndet i batteribanken!
Blev totalt 8 dygns PSoC-drift (Partial State of Charge) innan fulladdad blybatteribank detekterades igen med mätvärden för den battericykeln.
Batteriverkningsgraden blev då 96,9%(Ah) / 90,6%(Wh), lägsta laddnivå 73,3% SoC samt totalt cyklades -68,0Ah ur 212Ah batteribanken under battericykeln.
Mina AGM-blykols här 90,6%(Wh) batteriverkningsgrad är exakt samma som L.I.M.E Power mätt upp för sina LiFePO4! Och L.I.M.E Power har mätt upp en 90% DoD cykellivslängd på 1000 battericykler för sina LiFePO4, samma som mina AGM-blykol bör klara!
Vid en tidigare veckolång husvagnstur med PSoC-drift uppmättes 97,8%(Ah) / 92,4%(Wh) batteriverkningsgrad, lägsta laddnivå 71% SoC samt totalt cyklad urladdning -213,1Ah då. Var då i lite varmare och bättre solväder än turen nu i Oktober.
Så batteriverkningsgraden ligger där kring 97,5%(Ah) / 91,5%(Wh) för dessa Victron lead-carbon AGM-blykol batterier i min off-grid solcellsdrift vid battericykling mellan 70% - 100% SoC. Är jäkla bra för blybatterier och signifikant bättre än hos traditionella blybatterier! Bevisar AGM-blykol batteriers fina effektivitet och prestanda.
En batteriverkningsgrad kring 97,5%(Ah) är i stort samma som LiFePO4 bör ha i samma drift vad jag läst mig till, så jag får riktigt bra effektiv drift från mina AGM-blykol.
Mina Victron lead-carbon installerades i Maj 2021, så de har haft fyra driftssäsonger nu. Samt är i ett off-grid solcellssystem med en dåligt-väder-reserv på 5 dygn i batteribanken (days of autonomy), sunt dimensionerat för drift under sommarhalvåret.
Jag mäter även hur högt upp i SoC-laddnivå som AGM-blykol batterierna tar emot full laddström från solcellerna innan regulatorn börjar strypa strömmen, men det görs först fr.o.m. 2:a laddcykeln så kom inte med här då jag precis hade uppdaterat programkoden (firmware). Håller även på att koda för några fler mätvärden för battericykeln, så kommer kunna se dessa data för batteridriften lite senare under vinterns drift.

2024-12-23
Idag har min ESP32-batterimonitor varit i kontinuerlig drift under 50 dygn utan något minsta driftsavbrott eller HEAP- / RAM-minnesproblem! Under de 50 dygnen har den flera ggr/dygn alltid anslutit till WiFi snabbt och stabilt med senaste kodfixen!
Och inte en enda gång har den tappat kontakten och behövt återansluta till WiFi! Loggar driftsstatistik noga kring allt detta.
Var att jag behövde göra en buggfix i Espressif's WiFiMulti kodbibliotek!
Inget som AI-chattboten gav svar på när jag försökte få hjälp där via flertalet olika frågeställningar.

Samt det är 30 dygn sedan mitt AGM-blykol batteriet blev fulladdad senast och då PSoC-cyklat (Partial State of Charge) fram och tillbaka vid omkring 90%-97% SoC sedan dess.
Så blir spännande att se hur bra långtidsprecisionen blir för den långa PSoC-driften när blybatterier detekteras helt fulladdat igen!
Är det intressanta denna årstiden med underdimensionerad solpaneleffekt i mitt lilla experiment off-grid solcellssystem här hemma, att det nu blir längre battericyklingsperioder i PSoC-drift. Kan då validera långtidsprecisionen hos min ESP32-batterimonitor.

Så verifierad 50 dygns problemfri kontinuerlig drift nu blev som en liten julklapp :-)

Under dessa 50 dygn har det varit en 20-dygns (påbörjad före dessa 50 dygn) och en 7-dygns battericykel och nu pågående uppe i 30 dygn.
För 20-dygns cykeln detekterades fulladdat batteri vid 100,6% SoC och för 7-dygns vid 100,5% SoC, en extremt bra långtidsprecision! Ger bra intressant data att logga det!

2024-12-29
Blev uppdaterad till ArduinoJson @ 7.3.0 (@ 7.2.1).
ArduinoJson 7.3: safer copy policies
2024-12-30
Blev uppdaterad till INA226_WE @ 1.2.12 (@ 1.2.11)

2024-12-31
Lite fixar, justeringar samt lite robustare kod de sista dagarna på året:

• Funktionen BattDynDataSaveViaPreferences() som sparar preferences data regelbundet under drift sparar nu bara de data som förändrat sig sedan senast, så minskar skrivslitaget på flashminnet. Vid lite testdrift har det blivit 12 av 23 data.
• Checkade "Task minimum free stack space" nu efter 57 dygns kontinuerlig drift då de bör ha stabiliserat sig riktigt fint. Samt justerade dem mot att nu ge ca 600 bytes minimum free stack space mot ca 1000 tidigare [main.cpp:5306]:
  

  Task_DisplayViewHandler(): Task minimum free stack space (bytes):
  1.TaskSetupESP32:	Free (0812)	Stack now	delta	Stack new
  2.TaskDisplayViewHandler:	0384	3028	+236	3264
  3.TaskLCDbuttonsHandler:	0984	2126	-384	1742
  4.TaskWebServerESP32:	0856	3230	-256	2974
  5.TaskDeferredInterruptINA226:	0616	2210	-16	2194
  6.TaskDeferredInterruptINA260:	0996	2790	-396	2394
  7.TaskStateMachine:	0976	2906	-376	2530
  8.TaskWiFiSyncRTC:	0960	3994	-360	3634

  Fixade även ett utskriftsproblem mot serial monitor med aktivering / deaktivering av Serial:
  if (!Serial) // After Serial.end()
{
  Serial.begin(115200); // 115200
  Serial.setDebugOutput(true);
}

• Bytte från sprintf() till snprintf() resp. snprintf_P() överallt för att dels få minnessäkrare kod då man undviker att det skrivs utanför allokerad buffers storlek vid tankefel, samt dels för att spara SRAM-minne och läsa direkt från Flash vid större format-sträng:
  Formatted output with sprintf() & Co
  char buf[46];
snprintf_P(buf, sizeof(buf) / sizeof(buf[0]), PSTR("Datan är: %04u"), datavariabel);
Serial.println(buf);
  
• Lyckades äntligen hitta hur jag detekterar när RTC blivit uppdaterad via SNTP-tidsserver synkronisering, så min kod kan vänta in att RTC verkligen blivit synkroniserad!
  Fick problem i husvagnen via 4G-router och långsamt mobilnät i glesbygd att min indirekta metod att detektera det inte fungerade, som jag kodade då jag inte hittade detta tidigare. Så RTC blev där inte synkroniserad som tänkt trots kort uppkoppling mot Internet varje natt!
  Har letat efter denna lösning av och till nästan i ett års tid!
  Lösningen jag missat tidigare är att det behövs #include "esp_sntp.h" för att kunna använda Espressif´s ESP-IDF funktion sntp_get_sync_status(), så blir mer användning av ESP-IDF Espressif IoT Development Framework framöver nu:
  #include "esp_sntp.h"
// Checks if RTC SNTP update is completed
if (sntp_get_sync_status() == SNTP_SYNC_STATUS_COMPLETED)
{
}
Använder då även under boot sntp_get_sync_interval() för att skriva ut aktuellt sync interval (ms) i PlatformIO Serial Monitor:
  The RTC sync interval of SNTP operation (ms): 10800000
  Så synkar var 3:e timma uppkopplad mot Internet samt var gång den kopplar upp mot Internet. Så jag låter den vara så.
  Erfarenheten från detta är: Leta alltid efter den #include header som krävs för att kunna använda en ESP-IDF funktion i Espressif´s Arduino Framework!
  
  Fungera så fint nu när ESP32 bootar:
  14:07:29.282 > Get NTP server time:
14:07:29.292 > Actual RTC date sync SNTP: 2024:12:31 11:48:21
14:07:30.315 > Actual RTC date sync SNTP: 2024:12:31 11:48:22
14:07:31.335 > Actual RTC date sync SNTP: 2024:12:31 11:48:23
14:07:32.355 > Actual RTC date sync SNTP: 2024:12:31 11:48:24
14:07:33.375 > Get NTP StateMach->RTC_NTP_Synchronized = true
14:07:33.387 > Actual RTC date sync SNTP: 2024:12:31 14:07:33

• Efter ett längre uppehåll i kodandet kunde jag inte få kontakt från PlatformIO IDE till ESP32, sannolikt pga Windows 11 uppdateringar.
  Visade sig efter flera timmars letande på Internet att CH340-drivrutinen behövde backas ett par generationer till ver.3.7 2022-01-18, och då fungerade det igen. Har haft det så hela tiden på min laptop utan att hitta någon lösning, så provade samma där och nu fungerar även den mot ESP32. Så framöver kommer jag kunna ha kvar ESP32-batterimonitorn i husvagnen och bara ta med laptopen för uppdatering av programvaran, så som tänkt. Blir riktigt bra!

2025-01-02
Idag har min ESP32-batterimonitor varit i kontinuerlig avbrottsfri drift i 60 dygn i mitt lilla experiment off-grid solcellssystem här hemma!
60 dygn med kontinuerlig exekvering i programvaran jag kodat.
Ingen reboot, inga driftsavbrott och inga problem med HEAP-/RAM-minne eller något annat, bara OK drift. Loggar noga statistik för det i ESP32, så vet det fullt säkert!
Är även 40 dygn sedan mitt AGM-blykol batteri blev fulladdat senast här, så blir spännande att se långtidsprecisionen för min ESP32-batterimonitor när det blir fulladdat igen av solcellerna.
Är nu 89,5% SoC laddnivå i blybatteriet och har cyklats fram och tillbaka i PSoC-drift utan att bli fulladdat. Men idag är det fint vintersolväder, så kommer ladda på en del.
Samt min ESP32-batterimonitor har varit i konstant drift i 11 månader nu ihop med AGM-blykol batteriet, med bara glesa korta avbrott för uppdatering av programkoden i den efterhand som jag vidareutvecklat den.
Så det funkar absolut att koda detta i C++ och FreeRTOS!
Men kliar ju i fingrarna att få uppdatera koden, men kommer avvakta tills batteriet blir fulladdat igen så jag inte missar chansen att se långtidsstabiliteten i mätningen av SoC-laddnivån i batteriet. Min ESP32-batterimonitor mäter upp långtidsprecisionen själv!
Men har just nu mitt andra exemplar från husvagnen hemma, så kodar lite mot den. Bl.a lite mer statistik för varje battericykel så jag ser max/min spänning, ström, och effekt för batteriet, samt även medelspänningen. Både sparat för senaste battericykeln och för pågående battericykel.
Känner mig väldigt nöjd så här långt nu, lite som en milstolpe i projektet!
Visar tydligt att man som amatör som hobby kan utveckla intressant kompetent elektronik inom detta idag!
Blev lite batteriladdning med solcellsström i dagens solväder:

2025-01-04
Nu under 62 dygns kontinuerlig drift har min ESP32-batterimonitor gjort ca:
4.533.358.000 samplingar (mätningar) av batteriets ström och spänning, som lite sifferexercis.
Samtidigt görs lika många samplingar av solcellsströmmen.
Hela 4,5 miljarder!
Så den har hyfsat bra koll på batteridriften, eller snarare superkoll.
Gör 1024st samplingar per 1,210 sekunder dvs drygt 50.000st/min eller 73.000.000st/dygn.
Sparar den programkoden märkt med 60 dygn, så blir det en bra kodbas som jag vet arbetar helt stabil att kunna gå tillbaka till och jämföra den vidareutvecklade koden mot om det skulle uppstå något problem med dess driftssäkerhet framöver.
Som en felsökningsreferens.

2025-01-05
Fixat så att all 24h diagramdata återladdas efter programkoduppdatering! Fungerar OK.
Blir smidigt när jag uppdaterar programkoden ute i fält i husvagnen, att jag då inte förlorar 24h diagramdatan över batteridriften!
Varje gång diagramdatan sparas så sparar jag nu även RTC-Epoch-time och jämför med vid boot / reboot / reset och om det är <3h sedan senast åtställs all 24h diagramdatan. Väntar då nu även in att RTC synkat med NTP-tidsserver.
Och efter det sparas 24h diagramdatan igen, via att den läggs i kön till Task_WiFiSyncRTC(), så fast asynkront så köas de i Task här sekventiellt synkront med varandra. Vilket ger en robustare funktion för detta än tidigare, som jag fick på köpet nu! Smidigt att köa så via FreeRTOS Task()!
Så nu förlorar jag aldrig 24h diagramdatan eller övrigt driftsdata / statistik vid reboot, varken vid koduppdatering, panic´d kodkrash, WDT (WatchDog Timer) reboot eller om min övervakningskod finner något kritiskt tillstånd i ESP32's drift i kodexekveringen och gör en kontrollerad automatisk reboot. Bara så jäkla bra för en batterimonitor i 24/7/365-drift där det är viktigt att aldrig riskera att förlora sin driftsdata över batteridriften !
Här ifrån en dag med väldigt många koduppladdningar till ESP32-batterimonitorn:

2025-01-06
ESP32 & C++17 & FreeRTOS <3
Kodade så jag på min konfigurerings webbsida i ESP32-batterimonitorn nu även kan välja att manuellt spara all 24h diagramdata m.m., den som sparas automatiskt som backup lite glest regelbundet i flash-minnet.
Så jag har all den senaste datan sparad när jag laddar upp ny programkod i ESP32, som då återställs efter reboot numera.
Har haft så jag kan göra det via tryckknappar på LCD-display shielden, men detta blir ett smidigt bra komplement!

När jag förändrar någon inställning där på konfigurerings webbsidan så blir "Save Data"-tryckknappen genast röd och den växlar inte till grönt igen förrän webbsidan via WebSockets fått en kvittens tillbaka från ESP32 att önskad ändring är genomförd i ESP32 efter knapptryckning.
Så som att kryssa för checkboxen "Save Graph Data", och då blir tryckknappen grön igen först efter att ESP32 verkligen sparat all data i flash-minnet och skickat kvittens på det :-)
Känns vettigt att koda funktionaliteten så tycker jag.

Och naturligtvis var jag tvungen att testa vad som händer om jag gör detta ifrån den webbsidan aktiv både på mobilen och i datorn exakt samtidigt!
Varje webbsidas WebSocket instans har sin egen id, så det då aktiveras två instanser av den funktionen som hanterar önskan (WebSocket message) från knapptryckningen på webbsidan (eller om messages köas på vägen dit) och datan sparas två gånger direkt efter varandra då.
Det köas upp så fint i den FreeRTOS Task som hanterar detta så blir inte att de försöker spara datan från två instanser samtidigt i ett kaos! Och därmed körs även bara en instans i taget av funktionen som spara datan, direkt efter varande, vilket blir RAM-minnessnålt.
Men tryckknappen blir grön på båda webbsidorna direkt första instansen har sparat datan, då kvittensen om det skickas ut som broadcasting message till alla enheter med denna webbsidan öppnad i. Och det är helt rätt, för då är datan sparad.
Samtidigt fortsätter ESP32 att logga batteriets ström och spänning helt opåverkat via sin multitasking som jag gett en högre prioritet, så det prioriteras före webbsidan och sparandet av datan. Men allt med webbsidan är riktigt responsivt ändå, då ESP32 har goda prestanda-marginaler för detta!

Med bra struktur på koden är detta lättkodat, då FreeRTOS bjuder på så mycket fin kodfunktionalitet! Tog inte lång tid idag att lägga till denna checkboxen och skriva koden för ESP32 som hanterar det.
Men man får ju då även vara lite slängd i html webbsideskodande!

2025-01-10
Fixat en kodbit som hängt med från ett exempel på Internet och jag sedan inte funderat vidare över förrän nu, så ändrat hos alla SSE xxx.send() nu:
eventsSystemData.send(NumToString(int(PulseInd)).c_str(),"SSEpulsInd",millis(),5000U); // Gamla
eventsSystemData.send(NumToString(int(PulseInd)).c_str(),"SSEpulsInd",millis()); // Uppdaterade
void AsyncEventSource::send(const char *message, const char *event = (const char *)__null, uint32_t id = 0U, uint32_t reconnect = 0U)// Kodreferns
Kan vara den 5000 ms reconnect tid jag haft där som orsakar de glesa panic´ed kodkrascherna i webbservern då jag växlar webbsida - hoppas på det! Passar inte alls ihop med hur kodstrukturen och funktionen med SSE är nu i min kod, så default 0U ms blir bättre oavsett.
Webbsidan "System Operational Data" (systemdatas.html) började få för mycket information visad, som även en hel del snarare var "Battery Cycle Data", så splittrade upp den och skapade en ny webbsida "Battery Cycle Data" (battcycledata.html).
Känns betydligt bättre och ger webbsidor över batteridriften med mer renodlat innehåll på varje.

2025-01-11
Flyttat systemtid-panelen från "Latest 24hr running statistics" webbsidan till "System Operational Data" webbsidan, där den hör mer logiskt hemma.
Funderar på att lägga in batteritemperaturen på "Latest 24hr running statistics" webbsidan istället. Batteritemperatur är inlagd där nu, både aktuell och medelvärdet för senaste 24h.

2025-01-12
Fixat så även WebSocket nu kan återansluta automatisk efter förlorad kontakt med webbservern, vilket då även fungerar efter panic´ed kodkrash eller andra orsaker till soft-reset. Även efter uppladdning av ny programkod.
Ser ut så här när WebSockets återanslutning arbetar nu efter en reboot:
14:14:58,495 Got no onMessage in time - Reconnecting WebSocket.
14:14:58,496 Trying to open a WebSocket connection...
14:15:18,856 Firefox kan inte upprätta en anslutning till servern
14:15:18,857 WebSocket Connection closed
14:15:18,857 WebSocket Reconnecting, retry time (s): 20.4
14:15:19,857 Trying to open a WebSocket connection...
14:15:39,963 Firefox kan inte upprätta en anslutning till servern
14:15:39,963 WebSocket Connection closed
14:15:39,963 WebSocket Reconnecting, retry time (s): 41.5
14:15:41,973 Trying to open a WebSocket connection...
14:15:42,236 WebSocket Connection opened
2025-01-27
Förfinat detta så det nu hanterar alla olika drifsfall robust korrekt, bl.a. med att utgå ifrån SSE.onError, vilket blir såhär nu efter reboot:
10:20:32,752 Got no onMessage in time - Reconnecting WebSocket.
10:20:32,753 Trying to open a WebSocket connection...
10:20:52,985 Firefox kan inte upprätta en anslutning till servern
10:20:52,986 WebSocket onError:
10:20:52,990 WebSocket Reconnecting, retry time (s): 20.2
10:20:52,990 WebSocket Connection closed
10:20:54,003 Trying to open a WebSocket connection...
10:21:14,036 Firefox kan inte upprätta en anslutning till servern
10:21:14,036 WebSocket onError:
10:21:14,037 WebSocket Reconnecting, retry time (s): 41.3
10:21:14,037 WebSocket Connection closed
10:21:15,552 Trying to open a WebSocket connection...
10:21:18,394 WebSocket Connection opened

2025-01-28
Då jag ska uppdatera alla C array[ ] till C++ std::array< > så fick jag väldigt motsägande svar från Internet på frågan om man bör använda [ ]-notation eller .at( ) med boundary-check och flera åsikter hävdar att man bör använda klassisk [ ] pga prestandaskillnaden medan några hävdade att prestandaskillnaden är extremt liten.
Så tog och mätte upp prestandaskillnaden mellan dem för kod i ESP32:
Time std::array<float,500> 2000x accessed via array[ ] (µs): 494
Time std::array<float,500> 2000x accessed via array.at( ) (µs): 521
Så via .at( ) vs via [ ] tar 1,05ggr längre tid, bara 5%!
Bara 27µs extra för 2000ggr access via array.at( ).
Så är i de allra flesta fall helt försumbart och värt det, då man kan undvika svårfunna buggar som kan ta tid att visa sig! Jag körde tidigt i projektet med en feldimensionerad array ett tag så ej allokerat minne accessades utan att ge någon kodkrash, men hade sannolikt gett kodkrasch förr eller senare. Med array.at( ) hade jag då direkt fått felmeddelande om att jag accessade utanför dess boundary!
Och fast jag nu bytt ifrån C array[ ] till std::array.at( ) överallt i koden så exekverar koden något snabbare nu. Så den minimala extra exekveringstid .at( ) tar uppvägs mer än väl av att övrig kod runt array blir effektivare med C++ std::array< >´s funktionalitet!
std::array<float, 500> TimeTest;
TimeTest.fill(0.0f);
auto StartT = micros();
for (size_t i = 0; i < 4; i++)
{
  for (size_t i = 0; i < TimeTest.size(); i++)
  {
    TimeTest[i] = i * 1.0f / 3.0f;
  }
}
auto EndT = micros();
log_d("Time array 2000x [] (us): %zu", EndT - StartT);
StartT = micros();
for (size_t i = 0; i < 4; i++)
{
  for (size_t i = 0; i < TimeTest.size(); i++)
  {
    TimeTest.at(i) = i * 1.0f / 3.0f;
  }
}
EndT = micros();
log_d("Time array 2000x .at() (us): %zu", EndT - StartT);

2025-02-01
ESP32-batterimonitorn har nu varit i kontinuerlig aktiv 24/7 drift i 90 dygn utan minsta driftsavbrott eller driftsproblem.
Inget problem med minnesläckage eller minnesfragmentering av RAM/Heap, ingen hängd processor / kodexekvering, ingen kodkrasch samt ingen reboot, allt noga loggat!
Samt varit i aktiv drift sedan 2023-02-20 med bara korta avbrott för koduppladdningar (och någon gles kodkrasch på den tiden).
Så dels fungerar det uppenbarligt fint att koda sådant här i C++ / FreeRTOS trots påstridiga påståenden om motsatsen, dels fungerar det fint utan någon extern WDT (WatchDog Timer) som jag även fått höra väldigt bestämt inte skulle gå.
Under denna kontinuerliga aktiva 24/7 drift i 90 dygn har ESP32-kodloopen exekverats ca 6.500.000ggr och mätvärdena samplats ca 6.600.000.000ggr, så bedömer det som tillräckligt länge för att ha validerat frånvaron av minnesläckage och fragmentering samt av en rubust tillförlitlig drift.
Därmed är en milstolpe uppnådd med 90 dygns 24/7-drift och nästa milstolpe är när AGM-blybatteriet blir fulladdat igen efter lång tid i PSoC-drift nu under vintern (Last Sync: 00y02m11d 11:21:21). Då kommer den själv utvärdera långtidsprecisionen.

Jag har bra personkemi med C++ / FreeRTOS som från C++11 har bra kodfunktionalitet som hanterar multicore multitasking / multithreading robust tillförlitligt utan risk för kodinterferens / race-condition samt även FreeRTOS har funktionalitet för det också, så medveten om problemet är det nu lätt att undvika. Jag kör egen kod i båda CPU-kärnorna i ESP32.
Samt i och med C++11 och än mer i C++17 som jag kodar i finns mycket programfunktionalitet ihop med ett standardbibliotek som gör det enkelt att undvika minnesläckage och fragmentering, samt med förståelse för vad som kan orsaka minnesläckage har jag utvecklat en kodstil där risken för det även minimeras.
Har 3st FreeRTOS Task på core 0 och 4st Task på core 1.
Har fördelat dem så att de som kan störa varandras tidskritiska funktion är placerad på olika kärnor, så jag därmed får absolut bäst prestanda / precision i de tidskritiska mätningarna av ström / spänning för batteriet och solcellsströmmen.
Sedan utöver det ger jag de olika Task olika prioritet, så de mest tidskritiska har högst prioritet att exekvera.
Samt tar då även hänsyn till vilken prioritet Espressif's egna Task i core 0 för WiFi etc har, så jag inte stör ut dem och sabbar deras exekvering. Annars lär man få sämre funktionalitet eller kanske t.o.m. driftsavbrott för WiFi.
Så nu ska ESP32-batterimonitorn få vara i kontinuerligt drift även i husvagnen och ska börja titta på att koda för att skicka driftsdata till min webbplats på webbhotellet.
Skärmdumpar på driften i dagens solsken:

2025-02-04
Is it possible to use C++20 for ESP32 with Arduino framework?
"Espressif is currently working on Arduino version 3.0. This will then be based on ESP-IDF 5.x and therefore also use the newer tool chain [C++20 / C++23?].
Announcing the Arduino ESP32 Core version 3.0.0
Installing latest Arduino framework for ESP32 (3.0.x) will crash
Can´t get esp32-arduino 3.0.0rc1 installed
Support Arduino ESP32 v3.0 based on ESP-IDF v5.1

2025-02-06
Blybatteridrift och strömpulsad laddning:
Idag blev mitt AGM-blykol batteri i mitt lilla experiment off-grid solcellssystem här hemma äntligen nästan fulladdat i solskenet igen efter drygt 2 månader och 14 dagars PSoC-drift (Partial State of Charge) vid runt 90% SoC stor del av tiden.
Nådde till 99,2% SoC enligt min ESP32-batterimonitor samt blev aktiv PV-Throttle dvs att PWM-regulatorn började float-reglera laddströmmen aktivt från solcellerna för första gången på 2,5 månader. Lägsta laddnivå detta 24h dygn var 95,0% SoC.
Aktiv PV_Throttle började vid 96,5% SoC, så laddade med full solcellsström upp till dit, men är rätt låga solcellsströmmar i denna experimentanläggning. Men ändå en intressant siffra som visar en bra egenskap hos AGM-blykol med sin fina laddmottagning!

Det riktigt intressanta här är att efter att PWM-regulatorn börjat reglera och begränsa strömmen från solcellerna med sitt PWM-strömpulsande (PV-Throttle) så ökade laddströmmen signifikant under spänningsregleringen, vilket är ett tydligt bevis för att strömpulsad laddning är väldigt positivt för blybatterikemin. Och laddströmmen ökade successivt under hela den dryga timme som den PWM-strömpulsande regleringen pågick idag!
Det normala är annars att strömmen successivt minskar under den spänningsreglerade konstanta laddspänningen under float-laddningen, vilket den helt säkert hade gjort med en MPPT-regulator här med sin kontinuerliga jämna laddström.
Men efter 2,5 månaders PSoC-drift fanns det tydligen lite som behövdes fräschas upp i batterikemin av PWM-strömpulsandet.
Det här är första gången jag lyckats fånga detta helt objektivt via ett högprecisions mätsystem såhär som min ESP32-batterimonitor utgör.
Det här visar att strömpulsad laddning även gör nytta för AGM-blykol batterier med sin superkondensator i batterikemin!

Alla dessa olika datasiffror är loggade med hög precision av min ESP32-batterimonitor, så ger en bra objektiv bild av batteridriften. Så blir nästan lite som blybatteriforskning.

Att laddningen nådde 99,2% SoC och hade drygt 1h PV-Throttle float-laddning visar att AGM-blykol batteriet är väldigt när 100% SoC fulladdat och det i sin tur visar att min ESP32-batterimonitor ser ut att ha en extremt bra långtidsprecision i mätning av SoC.
När det blir 100% SoC fulladdat som blybatteriet själv talar om kommer jag få mätdata på hur bra långtids-mätprecisionen av SoC varit för dessa dryga 2,5 månaders PSoC-drift! Vilket enligt väderprognosen bör ske i början av nästa vecka :-)
Så det blir riktigt spännande och intressant!

2025-02-10
Justerat hur Trip- och Total- driftsdata Ah/Wh loggas så inte data för små mikrobattericyklingar loggas. Nu måste battericykel komma under <98,0% SoC för att börja loggas, men då adderas driftsdata för 100% SoC - 98% SoC till den loggningen så inte den går förlorad.
Med mycket driftstid i passiv standbydrift fås annars mycket ointressant "skräpdata" loggad som blir som en störning för den nyttiga information jag önskar få ut från denna data.

2025-02-13
Gjort om så att de gemensamma main.css, menuhandler.js samt fullscreen.js filerna nu ligger på LittleFS-partionen (likt en intern SSD-disk) och laddas därifrån av respektive webbsida. Så nu blir funktionen med webbservern som på en större dator. Samt har även därmed kunnat ta bort preprocessorn processor() och därmed dels eliminerat de sista String-variablerna och har nu bara std::string samt slipper även att varje webbsidesfil ska laddas upp i RAM och preprocessas där innan den skickas till webbläsaren. Ger ytterligare något snålare lite stabilare robustare RAM/HEAP-minneshantering.
Nu även lagt alla webbsidornas html-kod filer i LittleFS filsystemet så även de laddas därifrån.
Fungerar riktigt bra och känns betydligt mer rätt!

2025-02-14
2,5 månaders PSoC-battericykel verifierad för AGM-blykol & ESP32-batterimonitorn.
Batteriverkningsgrad 96,1%(Ah), 100% fulladdat batteri detekterat vid 100,8% SoC mätvärde.

Yes, idag blev mitt AGM-blykol batteri i lilla experiment off-grid solcellssystemet hemma i lägenheten fulladdat igen efter drygt 2,5 månaders PSoC-drift¹ (Last Cycle: 00y02m18d 07:11:51)!
ESP32-batterimonitorn har då även varit i nästan 3,5 månader kontinuerligt oavbruten drift (Uptime: 00y03m12d 02h28m59s) utan någon reboot eller RAM/HEAP-minnesproblem!
Samt AGM-blykol batteriet har varit i drift drygt ett år nu (∑OpTime: 01y00m21d 08h55m) - nollställde all loggad statistik och driftsdata i ESP32-batterimonitorn vid byte av batteri, så den har även varit i kontinuerligt drift med riktigt bra funktion längre än så med bara korta avbrott för uppladdning av ny firmware- / programkod-version. Fungerar stabilt och bra!
Med väldigt imponerande driftsdata både för AGM-blykol batteriet och ESP32-batterimonitorn!

För denna drygt 2,5 månaders PSoC-battericykel¹ mätt av ESP32-batterimonitorn:
Batteriverkningsgrad 96,1%(Ah) / 92,0%(Wh), Lägsta SoC 86,9%, ∑cyklad urladdning -33,0Ah.
ESP32-batterimonitor: PVThrottle vid 98,5% SoC, Sync 100% SoC vid 100,8% SoC, dvs blykolbatteriet tog emot full solcellsström upp till 98,5% SoC samt detekterade 100% fulladdat batteri vid sitt 100,8% SoC mätvärde, en helt otroligt bra långtidsprecision för en batterimonitor.
Nu är detta med låg strömbelastning samt där battericyklingen lång tid hållit sig mellan 95% - 90% SoC med även självurladdningen inkluderad, men ändå jäkla bra. Har dock även sett motsvarande driftsdata från ESP32-batterimonitorn vid ett par veckolånga turer med husvagnen och dess off-grid solcellssystem med AGM-blykol och då högre strömmar och mer battericykling.
Att 100% SoC fulladdat batteri detekteras från batteriet självt vid uppmätt 100,8% SoC efter 2,5 månaders PSoC-drift¹ är en helt otroligt fin långtidsprecision, nästan så det känns overkligt. Men sett samma fina precision över flera tidigare veckolånga battericykler. Det innebär att jag kan alltid lita på uppmätt SoC-laddnivå för batteribanken även vid längre PSoC-batteridrift¹!
Därmed är Mission completed!

Det här bevisar både att AGM-blykol är en väldigt bra högprestanda blybatterikemi samt att jag lyckats extremt bra med min ESP32-batterimonitor!

Som referens har öppna flooded djupurladdnings blybatterier av bra kvalitet en batteriverkningsgrad på 50-60% vid så grund cykling i off-grid solcellssystem, så detta AGM-blykol är extremt mycket bättre! Vilket även märks på att det klarat sig så bra under hela denna vintersäsongen utan annan laddning än från underdimensionerad solpaneleffekt. Mitt förra blybatteri klarade inte det pga så mycket sämre batteriverkningsgrad.
Och ser jag på laddström / urladdningsström och batterispänning har AGM-blykol batteriet inte tagit någon skada av denna 2,5 månader långa PSoC-drift, vilket inte hade varit så bra för ett traditionellt blybatteri.
Typ 12,79V efter -0,48Ah / 7:15h / -65mA i snitt urladdning samt 12,76V efter -0,81Ah / 14:45h / -55mA i snitt urladdning för detta 90Ah AGM-blykol batteri.
¹⁾ Partial State of Charge, dvs battericykling utan att bli fulladdat.

2025-02-18
Färdig med den store code-refactoring jag hållit på med över vintern och dels är i princip all kod uppdaterad till C++17 med bl.a. std::array<> & std::string<>, där alla String() är elimierade. Dels har en del funktion uppdaterats samt gammal kod, alla webbsidesfiler ligger nu på LittleFS-partionen likt en intern SSD-disk och en ny webbsida för Batteri-cykel data skapats.
Även RTC´s synkning med NTP-tidsserver har gjorts bättre och stabilare där tidssynkroniseringen nu verifieras korrekt stabilt, vilket bör ge signifikant bättre funktion i husvagnen med 4G-router och svagt mobilnät!
Ser ut att fungera riktigt bra. C++17 exekverar något snabbare, ger stabilare RAM/HEAP minnesanvändning samt till viss del tydligare och enklare kod med sin bättre funktionalitet.
Så ska någon av de närmsta veckorna återmontera det ena exemplaret av ESP32-batterimonitorn fast i husvagnens off-grid solcellssytem.

2025-02-19
AGM-blykol batterier - kunskap om dess driftsegenskaper.
Under denna vintern blev det drygt 2,5 månaders PSoC-drift (00y02m18d 07:11:51) utan att mitt UPLUS 90Ah AGM-blykol batteri blev fulladdat i mitt lilla experiment off-grid solcellssystem här hemma, utan det cyklades delvis laddat (Partial State of Charge) runt 85-95% SoC.
Den 6 Februari blev det fulladdat första gången igen, men utan att Float Tailcurrent kom under 0,5% (450mA) som indikerar fulladdat batteri utan slutade på 1,1A den gången, så en av de andra metoderna min batterimonitor har fick detektera fulladdat. Visar att blykol-batteriet har påverkats av 2,5 månaders PSoC-drift.
Även de två följande gångerna det blev fulladdat kom Float Tailcurrent inte under 0,5% (0,45A/450mA) utan blev 0,75A resp. 0,55A.
Fjärde gången fulladdat kom Float Tailcurrent under 0,5% ned till 0,40A.
Och idag kom Float Tailcurrent vid fulladdat ned till ca 0,38A, ungefär där det var förra sommarhalvåret. Och dagen efter blev Float Tailcurrent 345mA.

Innebär att den lite negativa påverkan 2,5 månaders PSoC-drift haft på AGM-blykol batteriet har i stort återställts redan under 5:e fulladdningen efter det.
Traditionella blybatterier återställs oftast inte efter sådan påverkan, utan det är en utmärkande egenskap för just AGM-blykol batterikemin.
Har läst en annan rapporterad erfarenhet från sådan drift att blykol-batterier återställs så ett tag efter längre PSoC-drift, så skoj att själv verifiera det.
Så det lär även gälla mina Victron lead-carbon blybatterier i husvagnen, även om de hålls laddade av solcellerna under vintern.

Är det trevliga med att ha min ESP32-batterimonitor som arbetar med hög precision och fungerar som ett mätsystem över batteridriften, att jag kan få ut sådan detaljerad kunskap om AGM-blykol batteriers driftsegenskaper.
Är säkert de som hävdar att LiFePO4 har inga sådana egenheter alls, men det vet man inte så länge man inte har ett avancerat kompetent mätsystem inkopplat som analyserar batteridriften. Förekommer lite spridda uppgifter om att LiFePO4 skulle ha en minneseffekt vid PSoC-drift och andra som dementerar det.

2025-02-24
Centraldatorarkitektur
Huskvarna AB går mot centraldatorarkitektur för sina robotgräsklippare:
"En ai-kamera ställer betydligt högre krav på beräkningskraften ombord. I dagsläget är Husqvarnas robotgräsklippare uppbyggda som en distribuerad arkitektur, enligt samma princip som bilar länge byggts. Ett antal styrenheter eller noder, upp till 23 beroende på gräsklipparmodell, sköter olika sysslor och pratar med varandra genom kommunikationsprotokollet CAN-buss.
Men precis som personbilstillverkarna nu i allt högre grad går över till en arkitektur med en centraldator kommer Husqvarna att göra en liknande resa i och med införandet av en betydligt kraftfullare dator av typen Raspbery Pi med ai-accelerator.
– Vi kommer visserligen fortfarande att ha en distribuerad nod-baserad arkitektur. Men precis som att biltillverkarna går från 150 noder till betydligt färre med en centraldator så går vi från 14 ner mot 3–4 noder, i fallet med hemgräsklipparna, säger han."
Är det jag satsat på också för min kombinerade batterimonitor och solladdregulator med tänkt loaddump-funktion i framtiden. Att ha en central ESP32 mikrokontroller där allt styrs och koordineras i och sedan bara ansluta olika kraftenheter / effektsteg till den som sköter hanteringen av de stora strömmarna. På så sätt finns all driftsdata på ett ställe och kan utnyttjas för optimal styrning av all funktionalitet samt blir lättare att logga och analysera.

2025-02-27
Uppdaterad till: ArduinoJson 7.3.1 release
Changes:
Fix conversion from static string to number
Slightly reduce code size
- Trevligt med optimerad kodstorlek!

2025-03-01
High SoC efficiency mäts här i experiment off-grid solcellssystemet då battericykeln nått mellan 99,0% & 97,5% SoC urladdningsdjup. Så är verkligen under riktigt grund battericykling.
Har här cyklats fram och tillbaka under flera dygn i PSoC-drift där innan fulladdat igen.
Är imponerande hög 91,6% batteriverkningsgrad då vid så grund urladdning för UPLUS 90Ah Lead-Carbon! Samt precisionen att 100% SoC fulladdat batteri detekteras vid 100,4% SoC mätt laddnivå är imponerande.

2025-03-10
Espressif´s Response to ESP32 Undocumented Bluetooth HCI Commands - den påstådda säkerhetsrisken / bakdörren i ESP32 som inte utgör något direkt problem:
"Recently, some media have reported on a press release initially calling out ESP32 chips for having a "backdoor". Espressif would like to take this opportunity to clarify this matter for our users and partners.":
Espressif´s Response to Claimed Backdoor and Undocumented Commands in ESP32 Bluetooth Stack
ESP32 Undocumented Bluetooth Commands: Clearing the Air

2025-03-14
Time-To-Go (24hr) tidsprognosen för batteridriften är nu förbättrad och den renodlade beräkningen utifrån 24h-medelströmbalansen är nu utbytt mot en analys av den senaste 24h uppmätta strömbalansens fördelning över tid för solcells batteridriften.
Det innebär att nu tas hänsyn till hur solcellsströmladdning av batteribanken varit fördelad över senaste 24h så kan nu aldrig ge en prognos om fulladd batteribank mitt i natten, som ju är en omöjlighet solcellsladdat. Hände tidigare då och då, riktigt störigt!

Eftersom Time-To-Go (24hr) nu i den analyserande beräkningen baseras på senaste 24h strömbalansens fördelning över det dygnet, och därmed även solcellsströmmens / förbrukningens fördelning över senaste 24 timmarna, blir även tidsprognosen ytterligare bättre nu.

När jag på kvällen vid 22-tiden först checkade Time-To-Go (24hr) visade den drygt 3h kvar till fulladdat, dvs vid ca kl.01-tiden mitt i natten. När jag sedan hade laddat upp den nya koden/firmware i ESP32 visade Time-To-Go (24hr) drygt 14h för samma data, dvs vid ca kl.12:10 mitt på dagen. Så en tydligt signifikant bättre tidsprognos med nya analyserande koden som stämmer bättre med verkligheten!
Motsvarande blir det då i sämre solväder med Time-To-Go (24hr) tidsprognos för kvarvarande urladdningstid för batteribanken, att den då tar hänsyn till hur strömbalansen fördelas över senaste 24h med mest urladdning under natten och solcellsström som bidrar under dagen.
Så blir troligare att man når max urladdningsnivå (DoD) någon gång under en natt då, nu med nya analyserande beräkningen.

Time-To-Go (24hr) tidsprognosen baseras därmed på en statistisk matematisk analys av ca 73.000.000 samplade/uppmätta strömvärdends fördelning under senaste 24 timmarnas batteridrift, vilket ger en tidprognos för batteridriften i en helt annan klass än det mer vanliga i batterimonitorer baserat på momentan strömbalans in/ut ur batteribanken som är rätt oanvändbar.
Men jag reducerar antalet mätdata i ett par steg via statistisk beräkning, så hanterar inte 73.000.000 mätdata direkt i Time-To-Go beräkningarna. Hade belastat minne och CPU-prestanda för hårt i ESP32. Men datan/infon från alla 73.000.000 mätdata är med i beräkningarna.

Om man plockat in data från väderprognoser hade man kunnat få ännu bättre Time-To-Go tidsprognos över batteriernas driftstid, men kvarstår ändå osäkerhet i förbrukningsmönster samt i mobilt fordon hur det påverkas av skuggning på olika platser. Har inga planer nu på att ta in även väderprognos, dels för att det redan nu blir förvånandsvärt bra tidsprognos, dels att jag prioriterar tid åt annan utveckling som nu framöver att skicka driftsdatan till min webbsida på webbhotellet, etc.
Kan framöver även titta på att analysera 24h driftsdatan för solcellsströmmen och ta med skillnaden mellan idag och igår för att få med skillnad i solintensitet samt titta hela dess datamängd, för lite ytterligare bättre Time-To-Go tidsprognos över batteridriften. Samt går nog att göra än smartare dataanalys än jag gör nu, för en aning ytterligare bättre funktion.
Men bara den mer analyserande funktionen nu gjorde 24h-baserade Time-To-Go tidsprognosen imponerande mycket bättre, mer än jag hade föreställt mig! Så känns riktigt skoj!
Är även så att med 5 dygns dåligt-väder-reserv (days of autonomy) i batteribanken så handlar Time-To-Go analysen mycket om minst 5 dygns drift i dåligt väder och mer normalt om storleksordningen 10-20 dygns driftstid, över vilken då inverkan av vädervariationer indirekt utjämnas. Så är mest vid tidsprognos för återladdningstider <1 dygn som ett snabbt skifte i solväder ger en stor påverkan på Time-To-Go (24hr) tidsprognosen.

Att Time-To-Go (24hr) tidsprognosen för batteridriften baseras på analys av senaste 24h driftsdata gör att den blir opåverkad av kylskåpskompressorns intermittenta drift, av molntussar som kortvarigt skuggar solen samt även i stort av om jag läser av den mitt på dagen i fullt solsken eller på kvällen i nattmörker. Så kan sitta på kvällen och planera morgondagens husvagnstur med hänsyn till om jag ska prioritera solbelysning mot solpanelerna eller om mycket skogsskugga är OK beroende på hur lång återstående driftstid jag har från batteribanken, etc.
Detta till skillnad mot de batterimonitorer som baserar Time-To-Go tidsprognosen på momentan strömbalans in/ut ur batteribanken, där jag får en tidprognos om kylskåpskompressorna råkar arbeta, en helt annan om den står still, totalt olika tidprognos om en molntuss skuggar solen eller ej samt katastrofalt olika tidsprognos om jag tittar på den dagtid i fullt solsken eller kvällstid i nattmörkar! Så en sådan Time-To-Go tidsprognos är i stort helt oanvändbar till någon övervakning av solcells batteridriften!
Min NASA BM1 batterimonitor jag haft i många år ger en sådan helt oanvändbar momentan Time-To-Go tidsprognos, så där har jag bara använt antal loggade urladdade Ah ur batteribanken och själv gjort en grov tidprognos ur det i huvudet. Men har ändå haft bra nytta av den.
Victrons BMV-712 / SmartShunt batterimonitorer kan filtrera strömbalansen in/ut ur batteribanken under upp till max 12min (Time-to-go averaging period), så även de ger i stort en tidsprognos för den momentana strömsituationen som då är rätt oanvändbar.

Min Time-To-Go (24hr) tidsprognosen för batteridriften är ett sådant lyft och nu får jag koll på batteridriften på en helt annan nivå som verkligen ger stor nytta! Har upplevt det under ett par veckolånga campingturer, den ena i September som min solcellsdrift inte är dimensioerad för och hade då så jäkla bra översikt och koll på batteridriften och kunde se att jag hade bra fina marginaler under hels turen. Fick även info så det var lätt att besluta om att använda min extra lösa 40Wp solpanel under den turen. Såg tydligt de dagar jag borde prioriter skuggfri plats för husvagnen med sina solpaneler.
Så om någon knuten till de Europeiska tillverkarna av system till småskalig off-grid solcellsdrift läser detta kan de kanske inspireras till att utveckla bättre funktion till sina kunder.

Även Time-To-Go (1hr) tidprognosen bör gå att göra bättre analys för med att samanalysera driftsstatistiken för strömbalansen in/ut ur batteribanken och solcellsströmmen in till elsystemet.
Med även solcellsströmmen ingående i Time-To-Go (1hr) analysen kan jag bättre fånga förändringar i den, vilket är svårare vid analys av bara strömbalansen in/ut ur batterierna då den störs av kylskåpskompressorns intermittenta drift.

2025-03-16
När jag idag laddade upp ny kod i ESP32-batterimonitorn som var i full drift så blev något korrupt i minnet och vid reboot så blev det panic´ed-kodkrasch med ny reboot upprepade gånger av det. Ena gången 15st panic´ed på rad sedan kom den igång i normal exekvering, andra gången 190st(!) panic´ed kodkrasch med reboot och sedan av någon märklig anledning kom den igång med normal OK exekvering.
Alla tre gångerna laddade jag upp nya koden när ESP32 var i en högintensiv driftsmode (fulladdat batteri & solsken) där sannolikt de båda CPU-kärnorna sällan är samtidigt i idle-Task. Så misstänker att kodens exekvering avbrutits inför koduppladdning mitt i någon skrivning till minnet som då blivit korrupt och sedan lagrats korrupt i Preferences data i Flash. När då den korrupta Preferences data läses tillbaka i minnet efter reboot ger det panic´ed-kodkrasch!

Under min normala driftsmode exekvering i ESP32 kommer båda kärnorna vara samtidigt i idle-Task längre stunder regelbundet, så antagligen avbryts då kodens exekvering för koduppladdning när båda kärnorna är i idle-Task samtidigt för att inte riskera korrupt data (min gissning).
Och då fungerar uppladdning av ny kod i ESP32 alltid stabilt och OK!
Normalt sysslar jag inte med kodning och uppladdning av ny kod till ESP32 när det är soligt väder med fulladdade batterier, men denna gången höll jag på att optimera lite kod jag ville testa just vid den driften.

Har råkat ut för liknande 4-5ggr tidigare också men då antagit det var problem i min kod. Då inväntade jag inte upp mot 190st reboot utan la tillfälligt in i koden att all Preferences data raderades och laddade upp den koden och då var det korrupta borta. Men nu har jag ett drygt års driftsstatistik i ESP32-batterimonitorn jag inte ville förlora, så var ju skönt ESP32 lyckades boota om så efter ett tag!
Så tänker prova att lägga in en funktion där jag manuellt via Configuration-webbsidan kan aktivera att den högintensiva driftsmoden blockeras en viss tid inför koduppladdning, så är det förhoppningsvis lösningen på detta.
2025-03-16 - Lösning:
De tre senaste gånger jag nu fick paniced kodkrasher eftet koduppladdning var när ESP32 arbetade i en högintensiv driftsmode i min kod med högre processorbelastning.
Blir normalt inte att jag laddar upp kod just då, men nu var det en optimering jag ville testa just i den driftsmoden i soligt väder med fulladdat batteri.
Nu har jag hittat en kodbug som gav denna paniced kodkrasch vid reboot i den driftsmoden! Så egentligen var inte problemet kopplat till koduppladdning utan den påföljande reboot då.
Var en array som indexerades utanför sitt område och tack vare att jag använder C++11 std::array ihop med array.at() så fick jag tydlig info om sista kodrad exekverad i min kod innan paniced kodkrasch samt info om att det var array index out of bound.
Hade jag kört med gamla C-style array hade jag aldrig kunnat hitta denna kodbuggen!
Så förutom såhär så är std::array trevligt med sin mer funktionalitet som ger enklare renare och tydligare kod.
Så är bara så nöjd att jag nu har all kod uppdaterad till C++11 / C++17 kodning!
Har nu även förbättrat den kodbiten vid reboot så min kodexekvering startar upp med större stabilitet samt att den högintensiva driftsmode kodexekveringen inte kan starta förrän efter att RTC synkroniserat med Internet tidsserver.
Ett ytterligare litet framsteg!
Så nu ska jag kunna uppdatera ESP32 koden på plats i husvagnen i drift där på ett säkert sätt oavsett vilken driftsmode den råkar arbeta i just då.
Har även gjort att jag kan aktivera en Code Upload Time Slot där dels statistik och loggad data sparas, dels den högintensiva driftsmoden blockeras under 12 min för att ge robustare förutsättningar för koduppladdning. Indikeras med LED-symbol grönt/rött om i OK Upload Time Slot.
Har nu testat och gjort några koduppladdningar) där den högintensiva driftsmoden var i drift och blockerades såhär och fungera OK nu:

2025-03-18

AGM-blykol - driftsstatistik / prestanda

Har nu fått lite mer driftsstatistik för några battericykler i det fina solskenet för mitt UPLUS 12V 90Ah AGM-blykol batteri, med den utökade driftsdatan jag kodat under vintern.
Är imponerande siffror för AGM-blykol batteriet, så hade man inte vetat hade man nog gissat att de gällde för ett LiFePO4-batteri!
Är en helt ny paradigm inom blybatterikemin helt väsensskilt från traditionella blybatterier!
Driftsdata för senaste battericykeln loggat av ESP32-batterimonitorn:
- Last Cycle: 00y00m00d 21:49:42 (battericykelns varaktighet)
- Efficiency (batteriverkningsgrad): 98,6%(Ah), snitt 98,0%
- Efficiency (batteriverkningsgrad): 91,6%(Wh), snitt 94,5%
- SoC cycle lowest: 97,0%, föregående 86,9%, snitt 95,4% (lägsta laddnivå under battericykeln)
- SoC at PVThrottle: 98,5%, föregående 98,8%, snitt 98,5% (då regulatorn börjar reglera)
- Throttle Amp at PVThrottle start: 1,115A (när regulatorn börjar reglera / strypa)
- SoC at sync 100% (fulladdat): 100,0%, föregående 100,0%, snitt 99,8%
- Max PV Power: 20,90W
- Max Battery charge Power: 18,87W
- Max Battery charge Current: 1,357A
- Batteri medeltemperatur: 23,5°C
- Batteri medelspänning: 12,994V

SoC at PVThrottle innebär SoC-laddnivån när solladdregulatorn börjar strypa laddningen till blybatteriet, fram tills dess har solpanelerna laddat med full effekt. Throttle Amp at PVThrottle är laddströmmen då solladdregulatorn precis börjar strypa laddströmmen.
SoC at sync 100% (fulladdat) är loggad SoC-laddnivå då batterimonitorn detekterar fulladdat batteri från batteriet själv, så att det sker vi 100,0% / 99,8% är en exceptionellt bra mätprecision! Ger bra precision för övrig loggad driftsdata.

Är med PWM-regulator som strömpulsladdar under absorptions- och float-laddning samt med en strömpulsande Battery Reconditioner. Ger ihop lite effektivare blybatteridrift, men huvuddelen av den bättre effektiviteten står blykol-batterikemin för. Är i mitt lilla experiment off-grid solcellssystem i lägenheten där det är låga strömbelastningar på batteriet.
Men har sett liknande data vid drift i min husvagns off-grid solcellssystem också loggat med min ESP32-batterimonitor, men har under vintern utökat mängden driftsdata jag kodat så kan nu göra en mer vetenskaplig utvärdering av blykol-batterikemin.
Ett traditionellt blybatteri har vid så grund cykling som ned till 95-97% SoC en batteriverkningsgrad omkring 50% enligt en vetenskaplig rapport. Så får ca 2ggr bättre batteriverkningsgrad vid denna grunda battericyklingen, och det märks på mer tillgänglig ström!
Ska inom närmsta veckan återmontera mitt andra ESP32-batterimonitor exemplar i husvagnen och börja få denna driftsdatan där också för varje battericykel :-)
Får då mer driftsstatistik över mina 4 år gamla Victron lead-carbon AGM-blykol batteriprestanda. Blir intressant!

Låta batterikemin styra laddförloppet i solcellssystem

2025-04-04
Är intressant att låta blybatterikemin själv tala om när den är fulladdad. Har sett så många gånger nu under dryga året hur laddströmmens kurva bryter av tydligt precis där min batterimonitor detekterar fulladdat blybatteri via 0,5% Tail-current (0,005C)! Vilket då sannolikt visar att 0,5% Tail-current ger korrekt detektering av 100% SoC fulladdat blybatteri.
Se de inritade svarta linjerna för strömkurvan före och efter 0,5% Tail-current i diagrammet.
Och 0,5% Tail-current för detta har jag plockat från flera vetenskapliga källor, så verkar vara en hyfsad konsensus kring den strömnivån för blybatterikemin.
Här är det för ett 12V 90Ah AGM-blykol djupurladdningsbatteri i off-grid solcellsdrift.

Ska bli intressant att senare i vår eller försommar få min gamla Victron lead-carbon blybatteribank i husvagnen fulladdad så under aktiv husvagnstur och se om strömkurvan även för de bryter av lika tydligt vid 0,5% Tail-current. Har inte ännu fått en sådan kurva loggad där via min ESP32-batterimonitor, då de blivit fulladdade efter turen hittills under tiden jag haft den installerad där.
Från bara ett blybatteri är det svårt att dra några säkra slutsatser, men blir det lika dant med mina Victron lead-carbon så blir det en tydlig tendens.
Så ifall kan man dra slutsatsen att detta visar att 0,5% Tail-current stämmer bra med hur blybatterikemin fungerar för detektering av fulladdat blybatteri.
Har sett det även för min tidigare fritidsblybatteribank, men då manuellt iakttaget så inte så bra precision som jag får mätt nu.

Sedan är tanken att låta en lite högre Tail-current få styra när absorptions-laddningen ska växla till float-laddning, så att blybatteriet själv även får styra det istället för fasta tidsgränser eller grovt uppskattade dynamiska tidsgränser.
Bör ge en betydligt bättre och skonsammare blybatteriladdning, som då tar hänsyn till alla förutsättningar i blybatterikemin och inverkan av hur senaste battericykeln varit.

Troligen går det att gör liknande för LiFePO4 batterikemin. Jag har inte trängt in lika djupt i den men vad jag kan se vid lite enklare analys verkar det möjligt där också.
Har dock inte lyckats hitta samma vetenskaplig kunskap kring dem.

2025-04-05
Har nu noga validerat att algoritmerna för vinterns utökade kodade funktion för mer battericykel statistik fungerar korrekt i olika soligt väder:
Mörkt mulna dagar med en mängd små blå solluckor som snabbt driver förbi med sina korta kraftiga solglimtar ger lite kaotiska mätvärden för batteridriften. Solcellsströmmen kan då variera med en faktor 10 inom bara 1 sekund fram och tillbaka, som här mellan ca 3W och drygt 30W solcellseffekt. Med min kurvplottning av 10min medelvärden fås stabila tydliga kurvor ändå över hur batteridriften är, samtidigt som den mer momentana variation visas som skuggning till batteri-spänning (blå) och -ström (röd) kurvorna. Får på så sätt det bästa av två världar!

Med datakurvor plottade direkt från rådata hade de farit upp och ner kaotiskt och trasslat in sig i varandra så man inte hade kunnat läsa ut något vettigt ur dem för batteridriften!

Varje 10min datapunkt är medelvärdet av 512.000st mätdatasamplingar, så följer den snabba dynamisk solcellströmmen väldigt exakt i sådant här väder, vilket ger hög precision i SoC-laddnivå mätningarna samt för övrig mätdata och statistik också över lång tid.

Fick här även validerat att mina algoritmer för diverse statistikdata samt för detektering av 100% fulladdat batteri för synkronisering av 100% SoC fungerade robust tillförlitligt med hög precision även under dessa kaotiska förhållanden för mätvärdena. Här detekterades fulladdat batteri vid loggad 100,0% SoC laddnivå, så superperfekt! Men var då en battericykel med grund urladdning bara ned till 97,5% SoC.
Mätt batteriverkningsgrad blev 94,5%(Ah) / 88,4%(Wh), vilket är imponerande för ett blybatteri vid så grund urladdning, som visar att AGM-blykol är riktigt effektiva blybatterier!
Har här ett 12V 90Ah AGM-blykol djupurladdningsbatteri i mitt lilla experiment off-grid solcellsystem här hemma, vilket ger 32-35W som mest från solcellerna, drygt 2A.

Driftsöversikt för off-grid solcellssystems batteridrift

2025-04-09
Nu har jag fått dit de sista siffrorna i driftsöversikten för off-grid solcellssystemets batteridrift i min ESP32-batterimonitor, över förlusterna för ström mellanlagrad i batteribanken.
Nu ser man totalt levererad ström från solcellerna, den solcellsström som gått direkt till förbrukare, den förbrukarström som gått via batteribanken samt de förluster man fått av det i batteribanken. Samt även separat data för förbrukarströmmen.
Både som trippmätare och totalt sedan loggningen började.
Jag tycker det är intressant att kunna se hur mycket av strömmen som går direkt till förbrukarna och hur mycket som först passerar batteribanken och mellanlagras där.

I mitt 90Ah AGM-blykol batteri här hemma i mitt lilla experiment off-grid solcellssystem är batteriförlusten 1,2-1,3% av total ström levererad från solpanelerna, en extrem låg förlust i batteriet.
Är då totalt för drygt 14 månaders kontinuerlig solcellsdrift, ∑OpTime: 01y02m12d 14h17m.
Respektive för ∑TripTime: 00y00m02d 21h52m trippmätning.
För senaste battericykeln blev batteriverkningsgraden 88,0%(Ah) / 81,9%(Wh), men då låg den länge och cyklade fram och tillbaka kring 98% SoC laddnivå i vädret som var. Vid så fulladdat är det väldigt bra värden.
Medelvärdena över lite tid är 97,0%(Ah) / 92,2%(Wh) verkningsgrad.

Man hade inte fått lika trevliga siffror för ett traditionellt AGM-blybatteri och än sämre för ett traditionellt fritidsblybatteri.
Jag märkte en signifikant skillnad vid bytet från traditionella fritidsblybatterier till AGM-blykol i min off-grid husvagn, att jag fick märkbart mer användbar ström från solpanelerna då förlusterna i batteribanken blev så mycket lägre.
Men gäller då för hur min batteridrift är, med strömpulsad laddning från PWM-solladdregulator!

Systemet kräver för detta strömmätning av både strömmen in/ut ur batteribanken samt strömmen från solpanelerna. Jag tycker det är först såhär man får en riktigt bra bild över driften i sitt off-grid solcellssystem!

2025-04-10
Library Manager: Updating ArduinoJson @ 7.3.1
Library Manager: Installing bblanchon/ArduinoJson @ 7.4.0
Changes:
Optimize storage of tiny strings (up to 3 characters)
Fix support for const char[] (issue #2166)
2025-04-12
Library Manager: Updating ArduinoJson @ 7.4.0
Library Manager: Installing bblanchon/ArduinoJson @ 7.4.1
Changes:
Fix crash with tiny Flash strings (issue #2170)

AGM-blykol (lead-carbon) batteridrift 2025-04-13

Nu har jag många battericykler bakom mig med mitt 90Ah AGM-blykol batteri, och vid de rätt grunda cyklingarna (i snitt till bara 95,5% SoC) så laddas det med full solcellsström upp till 98,8% SoC i snitt (SOC@PVTHROTTLE) innan PWM-solladdregulatorn börjar strypa laddströmmen, detekteras fulladdat blybatteri vid loggad 99,9% SoC (SOC@SYNC100%) i snitt samt är i snitt batteriverkningsgraden 97,0%(Ah) / 92,0%(Wh) (EFFICIENCY).
Senaste battericykeln idag laddades med full solcellsström upp till 98,6% SoC med 1A laddström då PVThrottle påbörjades, detekterades fulladdat batteri vid 100,0% SoC samt blev batteriverkningsgraden 98,0%(Ah) / 91,5%(Wh). Med lägsta laddnivå 97,4% SoC.

Är imponerande effektivt detta 12V 90Ah UPLUS lead-carbon deep-cycle AGM-blykol batteri är vid så grunda urladdningar!
Är skoj att kunna logga driftsdatan med så hög precision!
Är då i mitt lilla experiment off-grid solcellssystem hemma i lägenheten där det är väldigt låg strömbelastning under battericyklingarna.

Planen är att i veckan åka och uppdatera programkoden / firmware i min ESP32-batterimonitor i off-grid husvagnen, så jag kan börja logga batteridriften där med vinterns gjorda förbättringar med utökad battericykeldata samt lite förfinade mätningar. Ska bli intressant.
Där får jag lite mer aktiv battericykling, lite djupare urladdningar och med mer normal strömbelastning för ett sådant småskaligt off-grid solcellssystem.
Så när jag fått lite battericykler där också kommer jag redovisa loggad data över batteridriften där med mina Victron lead-carbon AGM-blykol batterier, som är inne på 5:e driftssäsongen nu.

Lastbalansering för webbservern i ESP32 2025-04-19

När jag förra veckan uppdaterade min ESP32-batterimonitor i off-grid husvagnen med vinterns kodande av utökad funktionalitet så blev det fortfarande glesa kodkrascher där i webbservern när jag bläddrade mellan de olika webbsidorna i ESP32 med info över batteridriften. Här hemma i lägenheten har det fungerar stabilt senaste året.
Med den bättre infon nu på webbsidorna uppfattar jag det som att bandbredden för WebSocket / SSE dataöverföringen är signifikant lägre i husvagnen av någon anledning och att webbservern då inte hinner med att hantera all den data jag skickar via WebSocket / SSE.
Så med den insikten blev min slutsats att jag måste koda en lastbalansering som ser till att webbservern aldrig blir helt överbelastad, då den har svagheten att krascha då.

En avgörande orsak är nog att requesten om ny webbsida från min webbläsare när jag valt det i menyn där kommer helt asynkront multitaskande simultant i ESP32 och då glest kan komma exakt samtidigt som ESP32 via webbservern skickar WebSocket / SSE data till nuvarande webbsida och då blir webbservern överbelastad.
De glesa kodkrascherna sker alltid precis när jag klickat på ny webbsida i webbsidesmenyn där.
Så nu har jag kodat en fin lastbalansering som även tar hand om problemet med att inte en request om ny webbsida kan krocka med pågående WebSocket / SSE dataskickande.
Använder då kodfunktionerna availableForWriteAll() / availableForWrite() (WebSocket) och avgPacketsWaiting() (SSE) för att få info om ESPAsyncWebServer är ledig eller har jobb på gång. Som i ESPAsyncWebServer är kodade:
size_t AsyncEventSource::avgPacketsWaiting() const {
  if(_clients.isEmpty())
    return 0;
...

bool AsyncWebSocket::availableForWriteAll(){
  for(const auto& c: _clients){
    if(c->queueIsFull()) return false;
  }
  return true;
}
bool AsyncWebSocketClient::queueIsFull(){
if((_messageQueue.length() >= WS_MAX_QUEUED_MESSAGES) || (_status != WS_CONNECTED) ) return true;
return false;
}
#define WS_MAX_QUEUED_MESSAGES 32

Nu har jag försökt stresstesta min lastbalanseringslösning för webbservern i ESP32 genom att placera ESP32 med sin antenn på kretskortet på en jordad ESD-Antistatmatta på min arbetsbänk samt omsluta den med en aluminiumfolie i plastpåse också jordansluten till skyddsjord.
Men dataöverföringen via WiFi bara tuffar på obekymrat nu ändå helt stabilt, liksom WiFi-uppkopplingen.
Har då webbsidor uppe både i mobilen och på datorn och när jag då växlar webbsida på datorn kan jag se att dataskickandet till webbsidan i mobilen pausas ett par programcykler medan den andra webbsidan laddas och all dess WebSocket / SSE data skickas över till den ifrån ESP32. Och allt sker nu synkron med varandra, där uppladdningen av den nya webbsidan inväntar synkront så att all data via WebSocket / SSE är färdigskickade så webbservern är ledig för att ladda upp den nya webbsidan och all dess data.
Och under tiden nya webbsidan och dess data laddas upp så pausas all övrig dataskickande via WebSocket / SSE.
Så hade jag det inte förut!

När det gäller diagramwebbsidan över batteridriftens senaste 24hr så är det en massiv mängd data för de 5st 24hr datakurvorna som skickas över via WebSocket direkt när webbsidan har laddats upp!
Har nu gjort en hel del andra optimeringar också i hela min kodfunktion mot webbservern som också verkar ha ökat marginalerna signifikant.
Så ser ut som att en stabil funktion med webbsidor i ESP32 med WebSocket / SSE dataöverföring samt WiFi handlar mycket om riktigt bra kodad funktion mot dessa i ens programkod!
Här hemma har det fungerat stabilt länge med endast en loggad omstart av WiFi i min programkod under ett halvår.
Ska bli jäkla spännande att köra detta nu i husvagnen och se om jag äntligen når helt stabilt funktion där också eller om jag går på pumpen där ännu en gång.
Jag tycker det känns lovande nu (men har jag tyckt flera gånger förut).

Högprecisions spännings/ström-sensorer 2025-04-20 

Är underbart när man satsat på riktigt fina högprecisions spännings/ström-sensorer från Texas Instruments i sin batterimonitor och man kan konstatera att direkt fabrikskalibrerade mäter sensorn för batteriströmmen och sensorn för solcellsströmmen sina respektive spänningar exakt lika ned på mV-nivå!
Som här VOLTAGE 12,668V från båda när strömmen från solcellerna precis blivit 0,000A fram mot kvällen så det inte är något spänningsfall genom PWM-regulatorn pga ström.
Känner mig nöjd!

Längre stunds WiFi / Webbserver drift 2025-04-23 

Har idag haft min gamla mobil uppkopplad mot ESP32-batterimonitorn kontinuerligt under 6-7h här hemma visande en webbsida över batteridriften med aktivt skickande av driftsdata till den. Växlat lite mellan både webbsida med WebSocket data och webbsida med SSE data.
Under den tiden arbetade både WiFi och webbservern i ESP32 helt stabilt utan något som helst avbrott! Under en del av tiden hade jag totalt tre olika enheter samtidigt uppkopplad mot ESP32 så med olika visade webbsidor över batteridriften från den, också då helt stabilt.
Och under 2h mobilladdning placerad lite tight mellan blybatteriet och en större metallsak direkt på golvet av armerad betong så tappade den inte heller kontakten, vilket den brukat göra glest förut. Såg någon enstaka programloop med överhoppad dataöverföring, som då bör varit min lastbalansering i aktiv drift. Så det indikerar bättre robustare funktion nu med den kodadad lastbalanseringen för ESPAsyncWebServer webbservern och lite andra kodförbättringar i ESP32!
Så det bekräftar åter att "A problem well stated is a problem half-solved."
Ser bra och lovande ut!

Critical state reboot 2025-04-25 

Har optimerat critical state reboot lite, för robustare funktion kring kritiskt RAM-minne.
Samt kodat så SumMinFreeHeap & MinMaxAllocHeap sparas precis innan reboot vid critical state.
Så en för låg RAM-minnes nivå som triggar critical state reboot helt säkert loggas.


 Mer för Refactoring ToDo, se högre upp 

---

Idéer: 2023-07-04 / 2024-07-05

• Titta mer på Resource acquisition is initialization (RAII): Minne, minneshantering & minnesläckage.
• Ultra-strömsparläge:
  Får se om jag senare gör ett ultra-strömsparläge där INA226/INA260 samplar betydligt långsammare så det kanske blir upp emot 5-10s/loop, som då kunde styras av att solcellsströmmen är <5mA/100Ah batterikapacitet i Light-Sleep dvs försumbart med ström från solcellerna. Lite typ extra strömsnål "invintringsdrift" / nattdrift. Kunde vara extra viktigt off-grid vintertid.
  Men får då mäta hur mycket det sparar mot vad jag förlorar i pulsström mätprecison!
  Har nu testat både praktiskt samt mätt exekveringstiden för INA260´s Deferred Interrupt Task, och den är minimala 2,4ms av loop-cykelns 1200ms så är försumbart det kan påverka!
• Nya ESP32 kodversioner:
  Arduino Release v3.0.1 based on ESP-IDF v5.1.4
  Migration from 2.x to 3.0
  ESP32: Migrating from version 2.x to 3.0 (Arduino IDE)
  Arduino Release v2.0.16 based on ESP-IDF v4.4.7
  Platform Espressif32 6.7.0
  -----------------
  platformio/framework-arduinoespressif32, 3.20017.0 (2.0.17)
  espressif/arduino-esp32 , Migration guide from version 2.x to 3.x is available here.
  Arduino Release v2.0.17 based on ESP-IDF v4.4.7
  Platform Espressif32 6.8.1
  ESP32: Migrating from version 2.x to 3.0 (Arduino IDE), Randomnerdtutorials
  
• Ev. 4 x trafikljus diagram: för 7dygn (5dygn?), 24hr, 60min & momentant SoC statistiskt analyserat som visar hur driften ligger till mot "dåligt-väder-reserven". "Dåligt-väder-reserven" kan i sin tur räknas fram ur mätt dygnsmedelström och angiven C20 batterikapacitet plus max DoD.
  Momentant kan vara intressant för att se vad inkopplad last ger för driftstid, typ vid elektrisk matlagning.
  Med 60min SoC statistik då som sämst typ natt likt den som gäller för 24hr.
• Varning för osäket SoC: Ser flera som tror deras batterier är dåliga baserat på felvisad SoC från batterimonitorn, så vore nog bra med en varning när batterimonitorn är okaliberad eller det gått för lång tid sedan dess synkning av 100% SoC till detekterat fulladda batteri.
  Så användaren varnas för när SoC-värdet är osäkert och kan visa fel.
• Uppdatera Finite-state Machine funktionaliteten:
  • Förtydliga / utveckla SetStateEnergyCPU() för mikroprocessorns energy-mode:
    
    • Light-Sleep Mode 240MHz, även invintringsmode med sin ca 12V/6mA strömförbrukning
      Väcks upp 1ggr/s av INA226 interrupt för avläsning av mätvärden + uppdatera LCD-display. Är normalt 99,5% av tiden i light-sleep då för max strömsnålhet.
      Kanske även styra att LCD-displayen uppdateras mindre frekvent, eller filtrera för lugnare ström, då uppdatering av LCD ger bara ca 95% tid i light-sleep då visad data ändras?
      Bör med sin låga strömförbrukning även kunna fungera som invintringsmode för de flesta off-grid solcellssystem, så behov av att koppla loss från batterierna för att rädda batteribanken från djup urladdning vintertid elimineras! = användarvänligt.
    • ESP32 har 240MHz, 160MHz, 80MHz, 40MHz, 20MHz & 10MHz
      Välj frekvens så batterimonitorns strömförbrukning är <1/10-del av aktuell batteriström?
    • 240MHz för full prestand aktiv utan light-sleep vid: högre strömmar / PWM-controller pulsande / WiFi & Webbserver aktiv. (Ger strömsnålast nattdrift i light-sleep, se ovan.)
    • 160MHz för mellanhöga strömmar men ej PWM-controller pulsande / ej WiFi
    • 80MHz för lägre strömmar men ej PWM-controller pulsande / ej WiFi
    • 10MHz?, no-Serial.print, no-WiFi, no-BLE, no-PWM, ej PWM-controller pulsande
      Skulle så ifall vara strömsnålt läge vid låga strömmar utan att gå in i light-sleep.
    • Kanske införa en StateEnergyHandler() för tydligare framtidssäker funktion?
  • Se till / checka så allt som hanterar LCD-displayen är i egen kod / Task, för lättare byte till annan LCD-display!
  • Checka av så allt som hanterar trycknapparna är i egen kod / Task, för lätt anpassning till andra tryckknappar!
• Nu går "bara" 24h loggdatan för presentation av batteridriften förlorad vid reset, men ska senare titta på om även den ryms att sparas i RTC Slow Memory (8kB RAM), vilket jag tror.
  Är fixat ihop med LittleFS!
• Diagram över 24hr + 1hr Time-To-Go för fast max visad ±14dygns prognostid, inom 28-dygns statistiken.
• Göra en temperaturstyrd uppdatering av LCD-teckendisplayen? Uppdatera displayen mer sällan när det är kallt. Då slipper man det "kosmetiska" felet av den långsamma uppdateringen av LCD-kristallerna i kyla!
  Jag funderar även på något liknande när jag är i strömspar-mode då ESP32 är i light-sleep 99,5% av tiden, men när det skrivs nya tecken till displayen blir det "bara" ca 95% i light-sleep då det kräver tid.
  För bäst strömsparande bör jag gå över till mer sällan uppdatering av displayen då också.
  Dessa två funktioner hade ju passat att samordna.
  I nästa version tänker jag gå över till INA228 strömsensor och den har en temperaturgivare i sig, så då har jag även den på köpet!
• Mät batteribankens interna resistans (IR) när kylkåpskompressorn stängs av, för den momentana förändringen i strömförbrukning! Skapa även en kvot mot SoC-nivån just då.
• Logga tid i aktiv PWM-reglering senaste 14 dygnen. Styr 4G-router uppkoppling för datalagring på server så minst 2h/14dygn ∑ PWM-tid uppnås för AGM-blykol batteriers välmående.
  Styr 12V ström till 4G-router via enkel analys över utvecklingen under senaste 14 dygnen.
  Loggas per dygn för de 14 dygnen för att kunna analyseras bra.
  Minimum uppkoppling 1ggr/dygn och max kontinuerligt är tanken.
• Mäta vid vilken SoC PV Throttle = ON, dvs till hur högt SoC tar batteribanken emot full laddström från solcellerna. Både senaste och som medelvärde.
  Kanske ha två styck olika mätvärden, där den ena bara mäter för en viss minsta laddström?
  Typ kanske laddström >1%/0,01C av batterikapaciteten?
  Bara mäta för cyklingar <90% SoC?
• Mätningen av µs i ESP32 är beroende av processorns klockning som kan avvika något från angiven frekven. Man skulle kunna kaliberar den mot RTC-realtid som hämtas från Internet och mäta över lite längre tid. På så sätt skulle man kunna få en kaliberingssiffra för den som kompenserar för dess avvikelse och därmed öka precisionen i summeringen av Ah / Wh över längre tid. Precisionen är tillräcklig ändå i förhållande till mätgivarna, så behövs inte!
• Övervaka RAM-minnet för om minnesläckage detekteras som ger kritiskt lite ledigt minne eller för mycket fragmentering av RAM-minnet, och då göra en kontrollerad hard reset där driftsdata sparar så all driftspåverkan undviks?
• Titta över min strategi för watchdog timer i ESP32-koden:
  A Designer´s Guide to Watchdog Timers , DigiKey
  Understanding ESP32´s Multitasking and Watchdog Mechanism: A Deep Dive
  What is a watchdog timer (WDT)?, ABLIC Inc.
  Watchdog timer, Wikipedia

Länkar: 2023-06-16

• Kalkylator för låg-/högpassfilter, RC, LC & RL, Digikey
• ESP32 corrupt heap when handling multiple simultaneous requests, Websockets has been updated / fixed, but SSE (which has similarities with websockets) not. As stated I use Server Sent Events so possible an issue still exists in SSE. (2018, ESPAsyncWebServer).
  "Now I use Mongoose that works very well :)"
  Mongoose Library - a state-of-the art open source embedded web server:
  - Mongoose - Embedded Web Server / Embedded Networking Library
  - ArduinoMongoose, ESP32
  - Espressif: ArduinoMongoose
  - Mongoose Library Embedded Web Server, homepage
  - Mongoose Build options for ESP32 & FreeRTOS
  - Mongosse Using JSON
  - Mongoose Library Websocket server
  - Mongoose User Guide - 2-minute integration guide
  - Mongoose - ESP32: Device Dashboard
  - Mongoose Web Server Library Case Studies
  - Mongoose Testimonials
  - Websockets using Mongoose Library on ESP32 - Controlling an LED, Youtube
  - Use Mongoose as a replacement for AsyncWebServer
  - Mongoose/webserver, github snippet
  - Mongoose (web server), Wikipedia, officially supported on FreeRTOS
  - Mongoose OS Introduces ESP32-based IoT Starter Kits, Espressif
  - Mongoose web-server on ESP32 using PlatformIO - part 1, YouTube
  Eventually this code library:
  - WebSockets by Markus, WebSocket Server and Client for Arduino ESP32, PlatformIO
  - ArduinoWebSockets, GitHub
  - ArduinoWebSockets - Comparing changes, GitHub
  - Markus, GitHub
  
• X WebSocket Data Exchange with JSON for ArduinoJson 6, Steph´s µLab +++
• X ESP32 WebSocket Server using Arduino - Control GPIOs and Relays
• X ESP32 WebSocket Server: Display Sensor Readings
• X ESP32 Web Server (WebSocket) with Multiple Sliders (JSON), getValues()
• X How to post JSON data to a HTTP server endpoint [https://] from your ESP32 development board with ArduinoJson
• X bblanchon / ArduinoJson, PlatformIO, arduinojson.org
• Search: html5 post recieve JSON data php
• How to receive JSON POST with PHP?, GeeksforGeeks
• Espressif-arduino-esp32/libraries/HTTPClient/
• Espressif-arduino-esp32/libraries/WiFiClientSecure/
• ESP32: Insert Data into MySQL Database using PHP, on own server [https://]
• ESP32: How to Log Data (9 Different Ways)
• ESP32: Send Email Notification using PHP Script
• 160+ ESP32 Projects, Tutorials and Guides
• BVR-M-R001-1.0 - Motstånd, ytmontering 4W, 1mOhm, 1%, Isabellenhütte, (pdf)
• PBV-R001-F1-1.0 - Effektmotstånd 3W 1mOhm 1 %, Isabellenhütte
• BLOCK SHUNT 100A/50MV - Shunt 100 A, 50 mV class 1.0, Fujita
• PWR220T-20-10R0F - Strömavkänningsmotstånd, Bourns, 10Ω, 20W, TO-220
• Mouser: DC-shunt
• NorthStar NSB Blue+ Battery® lead-carbon Application Manual, 100Ah: Exceptional PSoC cyclic performance, Design life 12+ years, Ultra fast recharge (no charge max current limit), Operating temperature range -40°C to +65°C, Impedance (1Khz) 2.6 mΩ, 34kg, har en coulomb-verkningsgrad på 94% - 99,5% angivet, varierande med temperatur och hur djup urladdningen varit - "The higher the DOD and the higher the temperature is the higher this overcharge need to be to fully charge the battery."
  Lägre temperatur = högre coulomb-verkningsgrad.
• The overall (charge/discharge) coulomb (current*time efficiency) of prismatic LFP batteries is around 99%. From my logged data over a period of around eighteen months I have 99.4%. The overall power efficiency which is a combination of the coulomb efficiency and the voltage efficiency for my battery is around 95%. This matches the figure I have seen in allot of literature on the subject.
• L.I.M.E Power Cyklingstålighet LiFePO4: "Vi laddar och laddar ur vid ca 0,7C, det vill säga ca 28A mellan 14,8 och 11,0 volt. Mätt i wattimmar laddar vi ur ca 480Wh/cykel och laddar i ca 530Wh/cykel (skillnaden är inre förluster). [Dvs 90% Wh-verkningsgrad.] Det betyder att vi tar nästan hela batteriets kapacitet i anspråk (DOD90%).
  Vi har genomfört drygt 500 cykler. Kapaciteten sjönk med 10,8%.
  Vi kan konstatera att batteriet mycket väl kan klara 80% av ursprunglig kapacitet efter 1000 cykler. Dessa 500 cykler innebär sannolikt att batterierna även efter 10 års användning i fritidsbåt har en försämring i användbar kapacitet som knappt märks."
• Making Your Battery Monitor More Accurate, Marine How To
• Testing the Balmar SG200 Self-Learning Battery Monitor, Marine How To
• Balmar SG200 Battery Monitor
• Balmar Smartgauge Battery Monitoring Unit, Marine How To
• Balmar Smartgauge™ Battery Monitor
• An effect similar to Peukert´s effect during charging, Smartgauge
• A-BMS – Active Battery Management System (lead-acid)
• Simarine PICO, Redefining Smart Battery Monitors
• Simarine Setup & Review, in a RV
• Victron Battery Monitor vs Simarine Pico Monitor, in a RV
• TAO Performance: A complete Energy Management System
• TAO Performance: Keeping your LiFePO4 battery healthy Learn about the optimal conditions and a few simple precautions to keep your LiFePO battery healthy for a long life. Med det TAO rekommenderar så har man i princip samma prestanda från LiFePO4 och bra AGM-blykol batterier med bl.a. max laddström ≤0,3C.
  Beskrivs även här: Most LiFePO4 manufacturers specify a maximum charge rate of 0.3C. Låter allvarligare att överskrida max laddström för LiFePO4 än för blybatterier!
  För AGM-blykol (lead carbon) ser en max laddström på ≤0,5C ut att vara vanligt!
• TAO Performance: What reduces the life of a LiFePO4 battery? Never recharge a LiFePO4 cell when it´s voltage as gone below 2.0 volt. It could create an internal short-circuit and a risk of fire. Allowing a LiFePO4 cell to drop below 2.5V will not only damage the cell but it converts the cell into a timebomb.
• TAO Performance: LiFePO4 Charge Cycle Management TAO BMS has a new feature to manage the LiFePO4 charge cycles and extend battery life.
• TAO Performance: New local and Cloud dashboard
• X2 BMS introduces five new BMS technologies
• LiFePO4 - Blybatteri hybrid
• OpenHybridBMS, ESP8266 based. This project was started because I was not satisfied with the commercial Battery Management Systems available.
• OpenHybridBMS Example status webpage via WiFi
• OpenHybridBMS, GitHub
• Lithium (LiFePO4) management - How to keep Lithium cells safe and healthy
• LiFePO4 - Approaching and exceeding the limits
• Studer Innotec: A year of solar autarky
• Studer Innotec: The next3 latest software release allows now the installation of 2 next3 in parallel, with the same or independent batteries??
• Studer Innotec Facebook
• Studer Innotec website
• OpenStuder gateway is the link from the IT world to a Studer Innotec installation, Open-source
• OpenStuder WebSocket
• Studer: Swiss made advanced energy management via Solar Manager
• Solar Manager FB
• Solar Manager website
• OFF-GRID Expo + Conference
• Victron Open-source
• How to set up Victron BMV Battery Monitor for lead and lithium batteries
• Victron solar production forecast feature, See your estimated future solar yield today.
• Solcast solar data or forecasts, Forecasting data for irradiance and PV power.
• Victron Dynamic ESS Node-RED, uses VRM forecasting and algorithm to optimize when to sell, buy and hold the grid to zero.
• SMHI API för väderprognosdata
• SMHI Meteorologisk prognosmodell PMP3g (2,8 km upplösning) - API
• SMHI Villkor för användning, öppen data
• Förimpedans, "En livsviktig regel är att matningen i en elektrisk starkströmsanläggning frånkopplas inom 0,4s vid kortslutning mellan fas och skyddsjord (höljet) i en apparat. I SS 424 14 05 finns angivet Imax för utlösning av säkring vid olika tider. Med säkring som skydd gäller t.ex. att en 10A diazed kräver en ström på minst 82 A (fabrikat Ifö bryter på 56 A) för att lösa inom 0,4s. En C10A dvärg kräver 100A. En B10A dvärg kräver istället bara 50A för att lösa."
  Så 20A => 100A 0,4s tidskonstant för inbyggd 20A eFuse funktion?