Vinnerliste

@Preben Må få begynne med å takke deg for denne 😁 Jeg har dog litt issues med å få dette til å fungere skikkelig. yaml filen validerer korrekt, den bygger helt fint (plukker opp mbus.h) Men når den har flashet esp32'en så nekter esp32'en å koble på WIFI. Den bare står og scanner ut fra log output'en når jeg kobler til med serial. Den scanner og finner nettverk, det den skal koble seg til er også på listen over nettverk den finner. men kobler ikke til. Står bare og scanner om og om igjen. Flasher jeg med en helt "clean" yaml fil så kobler den seg opp helt fint opp på WIFI. (Har også prøvd 2 forskjellige esp32'er) Noen som har hatt det problemet før? Ja, nå funka det... 🤦‍♂️ Tok kopi av alle yaml filene, sletta hele esphome from home assistant og startet helt på nytt. Må ha vært noe rusk en plass.

Jeg har lagt inn en sjekk om Tibberseer kjører. Gjør det ikke det: Stop plugin, vent litt, start plugin. Dette går automatisk hos meg via et event, og fungerer så vidt jeg vet 100%. Jon00 har laget scriptet du evt trenger: http://www.jon00.me.uk/index.shtml Log inn på hans server, og finn frem til "Jon00 Plugin Enable/Disable utility for Homeseer 3 & Homeseer 4" Gratis, men man bør donere noen kroner. Scriptet kan selvfølgelig brukes på alle plugins der du vil ha automatisk stop/start av en eller annen grunn. (Rettet: Skrev feil navn på scriptet i første utgave)

Jeg har laget meg et enkelt verktøy for kartlegging i første omgang. kWh og pris lagres hver time i SQL og hentes fram igjen i NodeRed. Så langt har jeg holdt meg under 5kWh alltid men jeg må jo sikre meg med å gjøre noen tiltak innen nyttår. Har til nå utelukkende hatt fokus på å flytte strømforbruk til tider med lav pris og det virker i alle fall. Har ikke noen automatisk beregning på besparelse men har regnet litt manuelt på noen få dager der strømmen har pristopper og finner i alle fall besparelse på 10-11% i forhold til om strømprisen hadde ligget på gjennomsnitt hele dagen. Antagelig er besparelsen større siden pristoppene er på de tidsperiodene der en normalt bruker mer strøm som ved middagskoking.

Nå er det opp til hver netteier og hvordan det er hos deg der du bor er ikke godt for meg å vite. Men mange netteiere har gått for en modell der den timen i løpet av en måned med størst forbruk setter prisen. De bruker ikke snitt over 24 timer. Hvilken netteier er det der du bor?

Dette er egentlig en P-regulator. Etterhvert tror jeg du vil få mer og mer lyst på integrasjondelen også 😉 Og det er ikke veldig vanskelig. Du kan løse det med en template sensor i tillegg til det du har eller bare utvide den du har. Et godt tips. Vurdere noe av det samme, enten som dette eller at andre parametre endrer seg avhengig av hvor langt i timen en er kommet.

Hei, er ny her. PIDer etc er ikke min styrke for å si det mildt. Har løst kapasitetsavgiftstrusselen på følgende måte - inntil videre med tall fra nettet som ikke er fra min netteier, men 'man tager hvad man haver': Tibber med Pulse gir meg følgende realtidsverdier: Venstre instrument er så å si direkte fra Tibber {{ states.sensor.accumulated_consumption_current_hour_.....state | round(2) }} mens høyre instrument beregner og viser forventet forbruk den pågående timen basert på historien av timen så langt - og ikke noe mer {{ ((states.sensor.accumulated_consumption_current_hour_......state | float * 60) / (now().minute+1)) | round(2) }} Når verdien til høyre overstiger 4.8 (for sikkerhets skyld styrer jeg mot 4.8 kWh/h, ikke 5) kutter jeg ut noen laster. Har ikke så mye som er lett å kutte, men så langt - noen få døgn - holdt det. Når verdien synker under 4.7 slår jeg lastene på igjen. "(now().minute+1))" er jo 'å jukse litt' - jeg bytter litt unøyaktighet i beregningen mot at jeg ikke får delt-på-null-feil det første minutt i timen. Jeg venter med på/av-prosedyren inntil den første kWh har blitt forbrukt fordi svært lavt forbruk (kWh) delt på svært kort tid (0..1 minutt) gir resultater i den første tiden som spriker lett i alle retninger. Når timen nærmer seg slutten viser begge instrumentene det samme.

Som @NilsOF sier: Kvaliteten varierer MYE, og man vet ikke hva man får. Denne synes jeg er fantastisk:

Det er definitivt ikke slik, den oppdaterer selve termostatens under boot (det ser du enkelt i displayet.)Den i menyen gjør ingenting for denne fw. For Zigbee-delen er jeg usikker, så derfor foreslo jeg belte og bukseseler

Hei stigvi, Takk for tilbakemelding. Jeg skal forøke å øke D igjen for å få redusere raske endringer. Stemmer at denne har ligget til 0 siden endringene. Grunnen til endring var at jeg leste (wikipedia) at ofte var det ikke nødvendig med D funksjonen, derfor la jeg denne ned foreløpig for det da ble mindre å holde øye med under testing. Kan nok ha misforstått eller blandet med dempning ser jeg når jeg leser dette en gang til Ellers må jeg si at scriptet ditt fungerer jo som bare det, selv med ikke optimale innstillinger treffer det som regel meget bra. Dette har motivert meg til å få integrert bedre min OpenEVSE i home assistant, slik at regulatoren kan sette laderstrømmen slik du har gjort på din lader. Legger ut konfigurasjonen i en egen tråd i tilfelle noen andre her har eller kommer til å ha en OpenEVSE sammen med home assistant.

Når du setter D til 1 så har du vel i praksis deaktivert denne. Tipper D-utgangen på regulatoren står på konstant null? D vil motvirke raske endringer på utgangen, så jeg vil anbefale en høy nok verdi til at du ser at den bidrar. Den kan f.eks hindre at regulatoren øker pådraget så kraftig at forbruket passerer 5kwh for en kortere periode. Å redusere I og P vil gjøre regulatoren tregere, men du kan øke disse to og samtidig øke D for å hindre at det blir ustabilt.

ESP32 kjører MicroPython greit, men det går betydelig kjappere med C++. ... men det er selvfølgelig avhengig av hva du skal gjøre. Liker at ESP32 er to-kjernet, så kan man samle og tolke data med en kjerne, og laste opp med en annen.

Fordi man aldri vet hva man får? Feks. en stor "industri" i Kina er samensnekring på kjøkkenbordet imellom bleieskift på minstemann og bestefar. Dette kan være alt fra rep og modifikasjon av forkastede dingser fra en større fabrikk til bygging av kopi av kopi. I tillegg er forfalskning av komponenter et stort problem. Når en større aktør her hjemme skal ha noe for elnettet så bestilles det fra fabrikk etter spesifikasjon. Ikke fra Ali Baba og de syv røverne.

Fikk et tips av @Moskus i en annen tråd at ESP32 er mye billigere og like god som Arduino.... så da gikk der ikke så fryktelig lang tid før 10 stk ESP32Dev dukket opp i posten (en av få utenlandspakker som virkelig kommer fram for tiden). Prøvde først å bare laste over den eksisterende Arduinokoden jeg hadde men det virket ikke helt... Litt småleting og jeg endret WiFi bibliotek fra WiFiNINA.h til WiFi.h og endret seriell overvåker fra 9600 til 115200 baud, det var det hele 👍 (og trykk på "BOOT" må til for det meste når koden skal lastes ned på ESPen, det slipper en på Ardino). Fant en fin side her: https://dronebotworkshop.com/esp32-intro/ som bl.a. sier dette om ESP32 vs Arduino: Ser ut til å bli mer ESP32 framover... og gjerne knotte mer Python framover og... ESP32 skal kunne kjøre Python greit og det kan ikke Arduino.

Parameter 19

Det er lagt inn et parameter hvor du kan velge relestatus etter strømbrudd. Så kan du slå av og på rele med inkluderingsknappen. Nå inkluderer du med tre trykk på knappen Det er lagt inn dette parameteret. This parameter determines if the device will return to state prior to the power failure after power is restored. Available settings: 0 – the device does not save the state prior to the power failure and returns to „off” position 1 – the device restores its state prior to the power failure Default setting: 1 Parameter size: 1 [byte]zrelay_EU_2_01b3.otz

Jeg har tenkt å løse dette (altså å sørge for at jeg aldri passerer 5 kWh på en time) på følgende måte med HomeSeer og Tibber Pulse: Har laget en global variabel i HomeSeer som heter consumption_prev_value. Den oppretter jeg i startup.vb, siden globale variable slettes ved restart. Setter den ved oppstart til gjeldende verdi av "Realtime AccumulatedConsumption" i TibberSeer. Jeg har et script i HomeSeer som oppdaterer denne variablen hver hele time. Så har jeg laget en virtuell device i HomeSeer som heter RealTime Hourly Consumption. Den oppdaterer jeg vha et script hver gang Realtime AccumulatedConsumption endrer seg. Verdien settes til ("Realtime AccumulatedConsumption"-consumption_prev_value). Da har jeg til enhver tid en device i HS som viser hvor mye strøm jeg har brukt siste timen. Har også opprettet en virtuell device som heter Power Level. Denne bruker jeg til å styre strømforbruket. Lager et script som kjører hver time som setter Power Level avhengig av om strømmen er billig eller ikke (relativt sett til dagsprisen, litt logikk med standardavvik osv). I tillegg monitorerer jeg RealTime Hourly Consumption, og dersom jeg passerer et gitt nivå, feks 4 kWh, setter jeg Power Level i sparemodus (overstyrer da strømprisen som var utgangspunktet for innstilling denne timen). Jeg styrer også varmen via HS. I dette scriptet skrur jeg opp temperaturen ved lav Power Level, og ned varmen dersom Power Level tilsier at jeg må spare strøm. I tillegg (og viktigst) skrur jeg av varmtvannstanken og senker temperatur på varmekabler. Sender også en advarsel via pushover dersom dette ikke er tilstrekkelig så jeg kan skru av tørketrommel eller annet (men det tror jeg ikke jeg kommer til å trenge).

Endelig mulig å justere Strømtrekk i apiet! teslaSeer testes i noen dager før det er tilgjengelig i shoppen