Svenska ElektronikForumet

Det kom en massa annat emellan, så det blev en längre paus...

Jag har skrapat mej en hel del i huvudet med att fundera hur uppgifterna bäst skall fördelas mellan kärnorna [i ESP32:n] och därmed också vilkendera kärnan som samtalar med vilka givare.
För närvarande styrs ju processen av en Arduino Uno, och den räcker bra till, så allt snack om att fördela lasten på två kärnor är förstås ren fåfänga, eftersom en ESP32-kärna utan problem kunde sköta hela ruljansen mycket effektivare än en AVR328.
Ändå vill man ju göra det krångligt, bara för att det är möjligt att göra det. Båda kärnorna kommer dessutom att behöva sin egen I2C-buss…

Jag tänker då som så, att kärna #1 skall göra precis bara det som Arduinon gör idag, d.v.s användarprocessen och styrningen av inverter, pumpar och reningsenhet, medan kärna #0 tar hand om alla nya sensorer, mätningar, uträkningar och optimeringsinställningar, och sedan förmedla styrvärden till #1.
Programmet idag är en lägesmaskin (state machine) som körs som en ändlös loop och lämpar sig därför utmärkt för att köras i en slavprocessor, men också semaforuppsättningen (signaleringen mellan kärnorna) blir så möjligast enkel. Det är ju vanligtvis där det brukar uppstå problem då man kör olika processer i olika kärnor.
Behövs iaf en semafor #1 → #0 för att meddela läget, en #0 → #1 som anger ifall tappning och/eller rening får startas just nu, och så någon semafor med vilken #0 kan tvångsstyra/stoppa #1 ifall någon situation uppstår.
Därutöver kommer några parametervärden att behövas i båda processerna, men det betyder bara, att de variablerna måste vara globala.

Så skall man ju få igång all kringutrustning och kunna prata med den också...
Det bästa (och samtidigt det värsta) i Arduino IDE-världen är en stor uppsättning biblioteksrutiner för så gott som alla möjliga och omöjliga I/O-enheter som finns.
Vill man göra något ”quick-n-dirty” är det bara att välja och vraka. Biblioteken är då oftast den rakaste och enklaste vägen.
Vill man däremot göra något specifikt, optimerat och kanske standardisera gränssnittet till drivrutinerna, och dessutom dokumentera det väl kan biblioteken vara rena h....et!

”Dom stora pojkarna”, som Adafruit, Sparkfun m.fl utvecklar och testar sina rutiner väl, och de är ofta rätt väl dokumenterade också, men även de gör ”the Adafruit way”, ”the Sparkfun way” el.dyl.
Speciellt Adafruit har, iofs förtjänstfullt, byggt upp en arkitektur med olika lager (layers), vilket dessvärre medför, att än flera rutiner måste inkluderas.
Dessutom bakar de oftast in en massa liknande kretsar och versioner av kretsar i samma biblioteksrutin och man måste sedan med olika Defs berätta vilken krets/version man vill kompilera för. Compilern sköter ju nog för all del om, att endast de behövliga delarna tas med i binären, men det är helt omöjligt att dokumentera.
Enskilda programmerare och mindre aktörer har ibland enklare och mera lättlästa rutiner, men de kan sedan i sin tur ha sinsemellan helt olika metoder eller t.o.m vara bristfälligt dokumenterade.

Mao: hjälps inte annat än att läsa igenom ett stort antal, leta fram algoritmerna och sedan re-factorera.

Är det verkligen semaforer, som hanteras med speciella instruktioner som gör att de kan testas-och-sättas utan att den andra kärnan kan använda samma minnesplats mitt emellan? Jag tycker mer det låter som flaggor, där ena kärnan sätter deras tillstånd och andra kärnan läser av tillstånden, ungefär som handskakningsledningar mellan två datorer.

Det är nog bara typ flaggor, vilka man använder så, att bara den ena får sätta men båda får läsa. Har alltid bara kallat dom "semaforer", kanske är det missvisande...
Det blir ju då ofta så, att en semafor egentligen är två flaggor, en i vardera riktningen. Ex. (F1)#0->#1:"Nytt värde i P1" och sedan (F2)#1->#0:"P1 läst", varefter #0 återigen nollställer (F1) och därefter nollar #1 (F2).
Så åtminstone så länge kommuniceringen på det logiska planet är synkron.
Ifall den är asynkron och #0 dessutom kan leverera flera nya parametervärden förrän #1 läser ens det första, så måste man implementera en buffert och kanske också något slags Xon/Xoff-signalering.
Bl.a just för att undvika sådana semaforer kom jag fram till, att det är bäst att minimera mängden data som skall skyfflas över från den ena kärnans processer till den andra. Därför bliev det så, att den ena kärnan endast sköter styrningen av användarprocessen med rening och tappning - den behöver i princip bara veta är det "GO" eller är det "No GO". Den andra kärnan gör allt det andra, och baserat på de uträkningarna sätter den semaforen som indikerar vad användarprocessen får göra.

Julklappar på gång.
Tyckte att nu var designen äntligen klar, så jag lade in en order på kretskortet.
100 x 100 mm, 4 layers, 5 st (=minimikvantitet). Sammanlagt 22 Euro, inklusive frakt.
Två kort behövs minimum, dvs ett i användning och ett som reservdel ifall av katastrofala elfel, strömpikar/EMP av blixtnedslag, eller liknande.
Det kan ju förstås vara bra att ha något kort extra för lödningsövningar, då en krets är packad i TSSOP-16 med 0.65 mm från ben till ben. Får se hur det går.
Lyckligtvis finns det ett fullt utrustat arbetsbord för ytmontering i Hacklabbet. Mikroskopet där hjälper mot ålderssynen, men darrar man på manschetten
kan det ändå vara knepigt.

Angående pilliga saker att löda:

Vissa tillverkare erbjuder att sälja korten med komponenter monterade.

Jo, det gör nog JLC också, men det var två saker som förhindrade det. För det första så har de ett begränsat urval av komponenter, så det är alltid bäst att börja designen utgående från deras komponentlista.
För det andra så saknar flera motstånd fortfarande värdet, jag har bara inte gjort mätningarna/beräkningarna ännu.
Flera kompisar på Hacklabbet har beställt monterade kort, så jag vet att tjänsten fungerar bra, men ex. den AD-omvandlaren jag valde finns inte på JLCs lista. (och det är just den som kommer i TSSOP-16 )
Jag vill ha bara 8 bitar för att göra datahanteringen möjligast enkel och ta minst utrymme (en byte (uint8_t) per mätresultat).
Den minst noggranna signifikansen (LSB), alltså på 24V-mätningen, blir då ca 0.1v och det räcker mer än väl.

Jag har knåpat med algoritmerna och programmen för att följa med laddningen i batterierna, dvs hur många Ampere-sekunder (Coulomb) det går in och hur många man tar ut. Den beräkningen behövs när man försöker optimera när och hur systemet bäst skall köras, men förhållandet mellan laddning och urladdning anger också över tid i vilket skick batterierna är. (Enligt litteraturen på nätet kallas det SoH - State of Health).
Det som stökar till beräkningarna är, att det är besvärligt att fastställa utgångsläget (SoC - State of Charge) och svårt att avgöra när batteriet efter en urladdning är återställt. Sökningar på nätet visar, att just detta är ett av de områden runt laddningsbara batterier som det forskas och experimenteras med mest. Det kallas "Coulomb Counting" och artiklarna som behandlar sådant talar just precis om svårigheten att fastställa utgångsläget.
Besvärligare blir det dessutom med tiden, då batteriet degraderar och man måste mata in mer och mer för varje Coulomb man vill ta ut.
Genom att följa med laddningen kan man ändå ganska bra bestämma när batteriet är fullt då förbrukningen är noll, solpanelerna producerar tillräckligt för att kunna ladda, men batteriet tar inte emot (laddningsströmmen är noll).
Det är dock inte en helt säker metod, eftersom intelligenta laddningsregulatorer gör vissa tricks när batteriet närmar sig fullt. Laddningen pulserar för att "klämma in det sista". För bly/syrabatterier sägs denna pulsering vara viktig för att förlänga livslängden. Hur mycket det nu stämmer vet jag inte, men pulseringen gör mätningarna besvärligare.
Medan jag satt och funderade på det gick jag in på Morningstar Corp.s hemsida (Solpanelernas laddningsregulator) och fann ut, att den stöder Modbus över en RS232-port som finns inne i boxen. Där har den funnits hela tiden, jag hade bara glömt bort den...
Efter att ha letat runt på nätsidan hittade jag specen för interfacet, dvs Modbus-"kartan". Där finns faktiskt en massa värdefulla parametrar, bl.a en som talar om när regulatorn anser att batteriet är fulladdat.
Det är många gånger enklare att lägga till en RS232-port till systemet jag håller på med, än att försöka odla fram några nya algoritmer som skall försöka räkna sig till samma resultat.
Det blev en betydande genväg!
Regulatorn kan dock inte berätta allt [som behövs], för den har ingen uppfattning om förbrukningen. Förbrukningsströmmen går inte igenom regulatorn, utan all last är kopplad direkt på batteriet. Därför måste jag fortfarande mäta strömmen till från batteriet.
Det ger ändå också helt nya möjligheter. När solen skiner klart och vattenreningen är igång, så går största delen av strömmen direkt från solpaneler och regulator, till förbrukning, alltså s.a.s förbi batteriet.
Jag tyckte att den inte ens behöver mätas, men nu är även det möjligt.

Lyckligtvis hade jag ritat in några (3) extra digitala portar på kretskortet (som redan är beställt). Två går nu åt till serieporten. Behövs dock ännu en TTL-to-RS232 modul.
Nu finns bara en ledig digital port kvar, plus fyra analoga (till AD-konvertern, icke konfigurerbara till annat).

Att utveckla ett system med så många olika rörliga delar som det som är på gång här, är som att lägga ett stort pussel. Att sedan försöka beskriva tankegångarna under utvecklingen är som att försöka beskriva pusselbilden när bara kantbitarna är på plats och alla de andra ligger huller om buller och osammanhängande utspridda innanför.
Det blir lätt mera som ett enda svammel.

Närmast för att klara upp mina egna tankar går jag därför lite tillbaka och upprepar sådant som jag redan nämnt i tidigare inlägg – som ett slags sammanfattning.

Alltså: Systemet har två huvudprocesser. Den ena hanterar själva vattenreningen och den andra optimeringen. Jag har försökt hitta på bra (=enkla och beskrivande) namn åt processerna, f.n ”Användarprocessen” resp. ”Styrprocessen”. Jag är inte nöjd med någondera, men det är nu inget att hänga upp sig på just nu. Hädanefter så hänvisar jag till dom med ”p.A” resp. ”p.S”.

Eftersom ESP32:an har två kärnor (Core0 och Core1) skall p.A och p.S snurra i varsin kärna. Programmet utvecklar jag i Arduino IDE, som per default placerar rutinerna setup() och den ändlösa loopen loop() i Core1. Ifall man sedan vill ta i bruk den andra kärnan skapar men en till ändlös loop, ex. loop1() som speciellt kommenderas att snurra i den kärnan. De funktioner och rutiner som kallas från någondera loop() eller loop1() kommer automatiskt att köras i samma kärna som loopen de kallas ifrån.
Core0 och Core1 är sinsemellan helt likvärdiga, så det har absolut ingen betydelse i sig vilken process som får vilken kärna så länge de har varsin. Variabler och IO-pinnar är lika tillgängliga för båda, så detta kan utnyttjas för att förmedla information från den ena processen till den andra.

Då uppstod frågan: är det någon skillnad vilkendera processen som behandlas som ”Default”?

För mig kom avgörandet via !2C-bussen. Båda processerna behöver tala till I2C-kringenheter, dock så, att p.A behöver bara en IO-expander, medan p.S sköter om alla andra I2C-enheter.
För att processerna inte skall konkurrera om en och samma buss – vilket skulle skapa behov för extra semaforeringar – beslöt jag utnyttja det att ESP32:n faktiskt stöder två !2C-bussar, och ger vardera processen en egen I2C-buss också.
Rutinerna för I2C-bussen finns i Arduino IDE i biblioteket Wire. Genom att skapa en instans Wire har man tillgång till ”default”-bussen, och med en till instans, ex. Wire1 öppnas den andra, ”secondary” (på valfria andra pinnar). Precis om variabler och pinnar har båda processerna i princip tillgång till vardera bussen, det gäller bara att i programmet hålla dom isär.
Varje I2C-enhet behöver förstås sina egna drivrutiner, vilka det finns massor att välja bland Arduino-miljön. De jag valt har jag sedan modifierat efter behov, närmast strippa dom för att göra dom enklare.
De här rutinerna är i första hand – undantagslöst – skrivna med tanke på standard-I2C-bussen. De vilka även möjliggör att definiera och utnyttja Secondary-bussen var mycket stökigare i och med att de använde sig av ytterligare, underliggande bibliotek vilka skulle länkas med. Iofs bra och användbart, men ett h..e att dokumentera för en eventuell efterföljare som skall fortsätta underhålla systemet efter att den här gamla guben har lämnat sin lådda.
Summan av kardemumman blev då den, att det enklaste var att modda [bara] ett bibliotek för att kunna använda Secondary-bussen, alla andra får gå på default-bussen. Då blev det också så, att p.S snurrar på default-kärnan, p.A på den andra. Punkt och slut med den saken.

p.A motsvarar sgs helt den process som snurrar i det ”gamla” systemet. Förutom användarens knapptryckningar använder den processen ett mätvärde (batterispänningen) och några digitala insignaler för att styra processen. Därutöver finns det ett antal parametrar vilka utgör gränsvärden för något beteende, ex. stäng av efter x sekunder, o.s.v. Parametrarna har hittills varit definierade som konstantvärden och fastslagna redan då man kompilerar och laddar ner programmet.
Nu blir det i stället så, att parametrarna finns som vanliga variabler i en behållare (C/C++: ”struct”) och de har utgångsmässigt ett lämpligt värde. p.A läser hädanefter värdena därifrån
I p.S finns sedan motsvarande behållare och man kan där bolla och leka med värdena utan att störa p.A. Så länge man håller behållaren möjligast enkel (bara direkta variabler, inte pekare eller flera structs), så kan man sedan överföra värdena till p.A på enklast möjliga sätt, typ A = B. Det tillåter då också, att p.A behärskat kan ta de nya värdena i bruk, t.ex genom att kort pausa.

De parametrar som funnits hittills räcker långt, men för att möjliggöra ännu flexiblare styrning av p.A behövs några kompletteringar. Det som i första hand behövs är tryckmätning (tryckexpansionskärlet) för att optimera sugpumpens gångtid, och uppgift om klockslaget för att avgöra när det lönar sig/inte lönar sig att köra rening.
p.A behöver i sig inte realtidsklocka, det räcker med en flagga som säger kör/kör inte.
Därutöver kan jag tänka mig några andra signaler som nog kan vara bra-å-ha. Ex flagga om nödstopp (vid läckage) uppgifter om vissa signaler skall inverka OR, eller AND, o.s.v. Mera om detta senare när jag hunnit fundera på det själv.

Till slut, några ord om p.S.
p.S ger parametervärdena till p.A, enligt vilka reningen körs, gångtiderna tajmas, m.m.
Till att börja med kommer parametervärdena kanske mest att bestämmas empiriskt enligt trial-and-error, men tanken är nog att efter hand utveckla någon form av automatik och dynamik.
p.S har tillgång till alla mätvärden som systemets olika sensorer kan ge. Många värden kan mätas direkt, andra kan härledas eller räknas ut med hjälp av mätvärdena.
Batterispänningen kan mätas med fyra olika mätare. Två i laddningsregulatorn (läses över Modbus), en direkt AD-ingång (8 bitar) och en i U-I-P-sensorn (32 bitar) direkt på ena batteripolen.
p.A följer spänningen enligt AD-ingången just för att den i sin enkelhet passar bäst för detta. Ifall spänningen faller för lågt pausas reningen tills batteriet återhämtat sig till en viss förutbestämd nivå.
Spänningen direkt på solpanelerna kan mätas, därtill kan solljusets intensitet mätas via en annan sensor.
Strömmen och effekten från panelerna, från regulatorn, och till och från batteriet kan mätas, mm. mm.
Det som jag ännu inte har är en nivåmätare för vattentanken (bäst vore en I2C-ansluten lösning), samt ett system som ger alarm i händelse av läckage (vatten på golvet).

Kom gärna med förslag!

p.S skall också mäta och räkna ut värden för optimera reningen, gällande batteriets skick (SoH) och laddningsnivå (SoC), tryckväxlingarna i tryckexpansionstanken, för att påvisa ev. läckage (mottrycket), o.s.v.
Jag blev också tillfrågad ifall man kunde mäta verkningsgraden på reningen i form av (liter rent vatten)/(liter havsvatten), vilket kunde ange när det är dags att byta osmosfiltrena. Det behövs dock inte här, eftersom filtren räcker längre än en säsong, men de måste bytas varje år, eftersom de inte kan sparas annat än i vattenbad i över 0 grader. => vore tvungen att ta in dom till sta’n i en hink med vatten över vintern. Icke sa’ Nicke!

Jaha, det var dagens postilla. Hoppas det klargjorde tankegångarna ens en aning, själv behövde jag den renskrivningen för att lätta på dimman.

Blir knappast flera inlägg före jul, så GOD JUL till alla!

Här skulle jag egentligen ha lagt in ett stort åskmoln, men så beslöt jag räkna till bortåt tiotusen först, så den stormen har hunnit lugna sig en aning.

Jag hade ju beställt kretskorten från Kina, och den 2.1 beslöt jag kolla var i världen de rörde sig.
På kurirens trackingsida hittade jag: 17.12 kommit till landet, 18.12 tullklarerats, 1.1.2025 returneras till avsändaren(!)
Enligt trackingen hade paketet aldrig ens försökts levereras. Jag hade inte heller fått något som helst meddelande om det.

Så försökte jag först chatta med en [urkorkad] "virtuell assistent", men det ledde ju ingen vart.
Efter mycket rotande lyckades jag slutligen hitta ett väl gömt telefonnummer till kundservicen och fick tag på en aningen (men bara aningen) fiffigare "humanoid".
Hen kunde dessvärre inte ge något som helst svar på vad som höll på att hända eller varför, men slutligen, efter att jag väntat en längre stund medan hen redde ut frågan med "någon", försäkrade, att "returen" gick att återkalla och paketet levereras, men inte förrän den 7.1, och bara till "ett annat" utlämningsställe en dryg kilometer längre bort, där det då skulle finnas "lediga boxar".
Kör för det, det är fortfarande närmare än Hong Kong, tänkte jag. Jag blev också utlovad ett textmeddelande när paketet kunde avhämtas från boxarna där.

Inga som helst meddelanden, men jag var ju färdigt misstänksam, så jag följde dagligen med hur saken framskrider, och visste därför när paketet var framme (= 7.1 på kvällen).
Åkte då efter paketet, bara för att se, att där inte fanns boxar alls, utan att det var ett bemannat ställe med öppna lagerhyllor och plats för hur många leveranser helst.
Tala om att den ena handen inte vet vad den andra gör...

Nåväl, jag fick ju ut paketet och till den delen var allt frid och fröjd, men det blir nog att välja en annan kurir nästa gång...
Det kommer nog att ta några dagar innan komponenterna är monterade och det blir dags att testa. På det lokala Hacklabbet finns allt som behövs för ytmontering, börjande från mikroskop och god belysning. Bara att inte darra på manschetten!

I mellandagarna efter julen planerade jag ett annat kretskort till en box för att koppla sensorerna för "kritiska" händelser, typ läckage, överhettning och sådant.
Övervakningen behöver inte individuellt ta ställning till sådana händelser, utan bara bums stänga av alltsammans. Det är sedan upp till "administratören" att analysera och åtgärda.

Tyckte det kunde behövas möjlighet till mer än en givare, så jag designade en typ "hubb" för upp till 8 alarmkretsar. En signallampa i hubben anger vilken krets som alarmerar, centralenheten avläser bara 1 st signal, och det på en direktansluten pinne så, att processorn genast skall kunna känna av signalen. Vid behov kan man hantera det som en interrupt också. Att det blev 8 kretsar/kanaler berodde helt på att jag tittade i "bra-å-ha -lådan" vad det fanns.
Kortet (2-sidigt) fräste jag ut.
De flesta komponenterna fastlödda, signallamporna (2-färgade LED:ar) saknas ännu. Efter det skall kortet ännu rengöras och lackas.

Det blev en ofrivillig paus i byggandet då en leverans blev på efterkälken. Jag saknade en RAM-krets och så bara dröjde och dröjde det.
I veckan kom den äntligen, så det skall väl gå vidare nu, hoppas jag.
Medan jag väntade på den planerade och byggde jag boxen. Även den börjar vara färdig, nu skall alla kablar och trådar kopplas.
Sidorna är i 3mm faner och fronten 3mm klar akryl, målad svart på insidan. Bottenplattan är 6mm. Bitarna är utskurna med laser. Texten är lasergraverad från insidan och tecknen fyllda med vit färg. Tyvärr var fonten så liten att färgen ville flöda över så att kanterna inte blev riktigt skarpa. Får duga tills vidare, gör kanske ett nytt försök senare.
Det skall LEDar i de tomma hålen, förutom ett håll för att komma åt reset-knappen.

Öppnad: Korten är monterade med leder så, att det går att fälla ut dom som på ett gångjärn. Det behövs för att komma åt det undre kortet och alla kopplingar: På bottenplattan blir det kopplingsplintar för kablar och trådar.

Lederna och konsolerna är akryl, utskurna med laser.

Alla komponenter är inte monterade ännu. Membranswitcharna skall sitta nedanför displayen. Systemet blir meny-styrt, så de enda tangenter som behövs är fyra navigeringstangenter (Upp-Ner och Vänster-Höger) och en tangent för att bekräfta. Därutöver en halvt dold Reset-knapp också.

Jag 3D-printade ut ett tangenbord. I PrusaSlicer såg det ut så här: ...och i verkligheten blev det: Man hade kunna få ytfinishen ännu bättre, men jag har inte vanan inne ännu, så det får vara så här tillsvidare. Kan byta ut det senare, ifall det där stör...
Tangenterna är designade i Blender och utskrivna med en Prusa XL med fem munstycken. Materialet är vit resp. svart nGen.
Jag var lite osäker om tangent"maskarna" skulle flexa tillräckligt, men den oron visade sig obefogad. Membranswitcharnas rörelse är endast 0.3 mm, tangenterna flexar mer än väl.

Ser ut som en genomtänkt låda, blir det någon ytbehandling av fanern så det inte suger åt sig fukt?

Den är två gånger lackad utan och innan med matt lack. Eventuellt drar jag ännu ett lager båtlack utanpå - för glansens skull.
Även kretskorten (de hemgjorda) skall lackas. Havsluften kommer åt precis allt. Dessutom måste man åtminstone förtenna ändorna på alla kopparkablar med flertrådiga ledare,
annars svartnar trådarna, kopparn blir spröd, och förr eller senare brister de.
Bästa resultatet får man då man först förtennar trådändan och sedan täcker till skarven mellan isoleringen och förtenningen med en stump krympslang med lim.
Med tunna trådar är det dessvärre struligt. Jag har inte fått tag på krympslang mindre än 3.2 mm diam och den vill inte alltid krympa tillräckligt så att den faktiskt sluter tätt.

Bara för att nu nämna det: Strandbodarna är faktiskt utsatta ibland. Vid riktigt extrema höststormar har havet legat mer än 10 cm på golvet inne. Golvet har därför 1% lutning och i nedre ändan en springa så att vattnet
kan rinna rakt ner. Det går ju inte att hindra havet från att komma in, men man kan iaf hjälpa det att komma snabbt ut.

Programmet skall som jag tidigare nämnt delas i två processer, av vilka den ena, p.A (användarprcessen) sköter själva vattenhanteringen och den andra, p.S (styrprocessen) följer med olika omgivande förhållanden som ex. batterinivå, laddningseffekt och realtid, men gör också olika beräkningar, vilkas resultat sedan skall användas i vattenhanteringen för att försöka få den så effektiv som möjligt och verkningsgraden så hög som möjligt.

Det ”gamla” systemet, som är byggt kring en Arduino Uno, har egentligen ingen intelligens alls. Med det vill jag säga, att den inte på något sätt tar lärdom av något som händer, utan den gör precis så som blev bestämt när programmet kompilerades och laddades i Arduinons minne. Alla parametrar är en gång för alla satta, och behöver något ändras är det bara att ladda upp en ny programversion med korrigerade parametervärden.
Med fem somrars erfarenhet har de flesta parametrarna ändå ”hittat” sina i det närmaste optimala värden, iaf för ett dylikt statiskt system, och som sådant fungerar det riktigt hyfsat.

Användarprocessen fungerar som en lägesmaskin, ”State machine”. I början fanns det endast tre stabila lägen, men snart märkte jag att det behövdes några till.
De ursprungliga tre lägena är:
S1: Viloläge
S2: Vattenrening
S3: Vattentappning

De två lägen som jag lade till litet senare är
S4: Felläge
S6: Standby, d.v.s rening är kommenderat, men systemet går i standby, p.g.a för låg batterinivå.
När batterinivån återhämtat sig ”tillräckligt” går vattenreningen automatiskt igång igen.

Därtill finns faktiskt ett ”läge” till, S0: Uppstart (boot), men eftersom detta inte är s.a.s stabilt utan utförs och passeras bara en gång, så bör man kanske kalla det transition.
I en tidigare programversion fanns även S5: återställning efter felläge. Även detta läge skulle ev. kallas transition. Funktionen var att man med en på förhand definerad knapptryckningssekvens kunde nollställa felläget S4 och gå till viloläget. Efter hand visade det sig dock, att det säkraste var ändå att köra en riktig "Hard Reset" på systemet. Läget S5 finns inte med för närvarande, men kanske återuppstår senare.
Triggers för S1, S2 resp. S3 är användarens knapptryckningar. Dessutom går systemet från S2 automatiskt till S1 då tanken blivit full.
Triggern för S6 är låg batterinivå under rening, medan triggern för S4 är något annat fel, så som att trycket in sjunker för lågt, trots att pumpen är igång (ex. läckage, stopp i insugsröret, ...).
Lägesmaskinen fungerar så, att tryckknapparna pollas kontinuerligt. Ifall en knapp är intryckt sköter sedan en underprocess om övergången från "nuvarande" läge till det "begärda" läget. Den utför också allt som behövs för ifrågavarande övergång och i den ordning och med de tidsintervall som behövs för en korrekt övergång, samt ställer in de gångparametrar som berörs.
Användaren kan helt enkelt inte göra något fel eller något som skulle kunna orsaka någon skada på vattenreningssystemet.

Det finns ingen orsak att göra några större ändringar på denna lägesmaskin, systemet fungerar hyfsat bra. Det nya systemet skall därför följa exakt samma mönster, med den skillnaden att parametervärdena som styr processen och vilka hittills varit statiska, framöver avläses från variabler vilka dynamiskt och under gång kan ställas av systemprocessen. På så sätt skall det vara möjligt att dynamiskt kunna trimma in systemet för bättre prestanda.
Utmaningarna är alltså att identifiera alla parametrar som behövs och till vad/hur deras värden skall användas, samt därefter att trimma in dom och dessutom, förhoppningsvis, hitta på algoritmer med vilka systemet automatiskt skall kunna leta sig fram till det mest optimala. Det både låter och ÄR mycket ambitiöst, jag förväntar mig inte att den optimeringen blir färdig och fungerande till inkommande sommar. Jag tror att det finns en del att undersöka och empiriskt testa och följa med än, innan man får det ihopknåpat till en fungerande algoritm...

Några exempel på parametrar (värden) som behövs för reningen är
- Minimi batterinivå
- Minimi solljusnivå
- Realtid
- Vattennivå
- Tryck, vid vilket insugspumpen skall starta
- Tryck vid vilket insugspumpen skall stanna
- Max gångtid för insugspumpen

Listan kommer med all sannolikhet att bli längre.

Förutom flera parametrar, så kommer det att bli till flera nya triggers [för övergång till nytt läge], men också flera villkor vilka skall vara uppfyllda för att tillåta byte av läge.

Dessa kommer [främst] att styras och ställas i styrprocessen, därför tar jag upp den härnäst.

Det var länge sedan jag uppdaterade här på forumet, men arbetet har nog hela tiden gått framåt.
Det som orsakat en hel del extra arbete är strippandet av drivrutinerna för de olika I2C-anslutna funktionerna. Standardbiblioteken vill ofatst vara universella och innehåller därför en massa #defines och #ifdefines. Sådana är omöjliga att dokumentera förståeligt, därför har jag rensat och förenklat dem och dessutom strävat till att homogenisera interfacet till de olika rutinerna.
Nu har det gjort och alla I2C-enheter fungerar.

Styrprocessen

Styrprocessens uppgift är att samla in olika mätvärden, föra statistik och göra olika beräkningar samt förse Användarprocessen med styrdata för rening och tappning. Den är uppbyggd kring en mycket kort loop som bara bevakar två olika händelser: knapptryck (som aktiveras av en användare) och en flagga, vilken aktiveras av en interruptrutin. Knapptryckningen skickas vidare till något jag kallar en navigeringsrutin (sköter menyer och allt som man kan göra i menyerna), interruptflaggan kallar på en rutin som läser in mätdata från alla sensorer som inte kan läsas direkt på någon av CPU:ns I/O-pinnar.
Interrupten triggas en gång i sekunden mha en 1Hz-signal från klock-kretsen. Jag hade först tänkt att inläsningen av sensordata skulle ske i interruptrutinen, men det gick inte, ESP32:an råkade i panik och bootade. I [den del av] manualen [som jag inte läst tillräckligt noga på] står det, att Interrupt-funktionens egen övervaknings-”vakthund” inte tillåter så tidsödande operationer som t.ex att läsa I2C-bussen.
Jag fick alltså ändra det så, att interruptrutinen bara sätter en flagga, och i huvudloopen , ifall flaggan är satt, får datainsamlingsrutinen ta över.
Alla rutiner är skrivna så, att programmet ingenstans blir och vänta på någon händelse, aktion, eller vad som helst som s.a.s får programmet att ens ett kort ögonblick stanna upp. Detta är förstås inte riktigt 100% sant, eftersom t.ex I2C-läsningen innebär att man väntar på svaret [minst ACK-signalen] från motparten. Det är oifrånkomligt och därför s.a.s den mints möjliga tidsenheten.
Men i övrigt är alla rutiner skrivna så, att programmet bara går runt och kollar, och går genast vidare. Du kan t.ex inte haka upp programmet genom att hålla en knapp intryckt. Knapptryckningen registreras nog genast, men orsakar reaktion först när tangenten släpps.
Detta innebär för det första ett antal flaggor vilka anger vad som är på gång, ex. vilken meny som ”just nu” är aktiv och har kontrollen, men det förutsätter också en hel del globala variabler för att värdena skall bibehållas. Detta i sin tur kräver både god disciplin och god dokumentation, så att man inte i misstag går och ändrar värden som andra rutiner behöver.
Nåjo, för att vara på säkra sidan sätter interruptrutinen inte en binär flagga, utan den lägger på ett till ”tick” på en räknare. Datainsamlingsloopen nollställer alltid denna räknare, men ifall huvudloopen av någon orsak blivit fördröjd och det hunnit ske flere interrupts sedan föregående datainsamling, så behöver datainsamlineg inte göra lika många insamlingar, utan i stället bara alltid multiplicera vissa mätningar med antalet ”ticks”, då blir statistiken rätt.
Det där kan förstås leda till mindre räknefel, men jag utgår från att det balanserar ut sig i längden och det här är inget kritiskt. Vi håller ju inte på och räknar fria neutroner i en kärnkraftskärna!

Här följer några bilder på hur kopplingarna ser ut just nu. Alarmenhetens anslutningar är vanliga 3.5 mm pluggar. Behändigare att serva då man kan vika ut modulerna, vilket inte heller stör funktionen. På bottnet i lådan finns "strömskenor" i form av skruvterminaler. Alla fyra spänningar behövs. Anslutningar till reläer, användarens tryckknappar utanför, mm. mm. Jag har också fixat med sensorerna. Först en möjligast simpel 3D-printad box för fuktsensorerna, vilka skall ge alarm ifall av vattenläckage. Själva vattenavkänningen tänkte jag göra med två pinnar från en pinribba. Löder fast en tvåpolig kabel till två pinnar, tätar lödningen med smältlim och utanpå en bit krympslang. Jag har dock inte skaffat kabeln ännu, därför inga bilder…
Sensorerna ansluts till alarmenheten (3.5 mm plugg) som är kopplad så, att om ingen sensor är ansluten är respektive LED släckt, annars grön om läget är OK och röd ifall sensorn ger alarm, och då lyser också den gemensamma Alarm-leden.

Jag har ett antal [Kina-] fuktsensorer vilka blev över från växthusprojektet. Kommer väl till pass här.
Läckageavkännare kommer iaf under vardera pumpen och under vattenreningsenheten. Man kunde förstås ha flera avkännare kopplade till samma sensor, emn jag ville ändå enklare se exakt varifrån alarmet kommer. Sammanlagt 3..4 fuktsensorer.
Dessutom kommer det en värmeavkänning på insugspumpen (iaf) - en värmesäkring som öppnar vid 70 grader ( den lägsta temperatur jag hittade).
Det kan behövas andra alarm senare också.

En av de viktigaste sensorerna är en ACS37800 (Allegro Microsystems) som mäter spänningen på och strömmen till/från batterierna. Den skall kopplas direkt på ena batteripolen och kommer därför en bit ifrån centralenheten. En medlem här på forumet tipsade mig om kretsen med vilken man kan förlänga I2C-bussen massor av metrar. Fungerar som tåget! Tack för ett gott tips!

Det här är den mest avancerade sensorn, men gav absolut minst utmaningar. Fungerade rakt av, utan några som helst strul. Eftersom detta är en i sig unik krets så har standard-drivrutinen inte heller några överflödiga #ifs-defs, så det krävdes bara kosmetiska ändringar.
Här några bilder utan och med 3D-printat hölje. ”Igelkotten” fanns i skrotlådan och härstammar från någon isärplockad grej. Den är i nog rätt så överdimensionerad, då bara ca 3W behöver kylas som max => vid ca 50 A(!!!) ström genom kretsen. (Specad till 90A).

Kretskortet har jag gjort i fräsen. Kopplqas med "Remote"-I2C till centralenheten. Jag använder RJ45 och CAT6-kabel. Kontakterna är kopplade som för en PoE-anslutning. Höljet är 3D-printat i PETG. Även LEDens "lins" är ditprintad, i klar PETG.

Trevligt projekt!
En hel massa olika moment. Intressant att följa med.