stigvi

Måleren skal registrere forbruk i intervaller på maks 60 minutter og den skal sende inn dette minst en gang i døgnet og før kl 0700. https://lovdata.no/dokument/SF/forskrift/1999-03-11-301/KAPITTEL_4#§4-2

Slike meldinger vil du slippe fordi nettselskapet har ikke data tilgjengelig for å kunne få det til.

Raspberry pi 4 er jo vesentlig kraftigere enn rpi 3

Det er i så fall din netteier som har bestemt. Disse trinnene er jo ikke bestemt av NVE og det er forskjellige trinn rundt om i Norge.

Det tror jeg den gjør. Folk flest innser at det ikke er nødvendig å lade bilen med størst mulig effekt bare fordi en har muligheten. Og jeg mener trådstarter overdriver. Det er ikke hensikten at en skal tyne seg under 5kWh/h en hel måned. Poenget er å unngå toppene og passe på at en holder seg i et effektrinn lavere enn det en ville gjort hvis en ga blaffen. Å presse seg selv to effekttrinn ned kan en jo gjøre hvis en absolutt vil, men bakdelene blir større enn fordelene og det har jo trådstarter funnet ut allerede, kanskje.

Nå har jeg lest ditt "forslag" 3 ganger uten å skjønne hva du mener så det er tydeligvis ikke bare NVE som bommer 🙂

Antar at å bytte ut tranformatorer i boligområder og eventuelt grave ned kabler med større tverrsnitt også koster. Det er nå uansett det som er begrunnelsen som er oppgitt. Det norske nettet takler ikke at flere og flere skal lade bilen sin med 11kW de få timene i døgnet strømmen er billig. Tibber som attpåtil automatiserer dette for folk er kanskje en viktig grunn for at noe måtte gjøres. NVE så jo hvordan teknologien kunne brukes og det har vel skremt de litt, tenker jeg.

Den hundrelappen representerer selvfølgelig ikke kostnaden med å oppgradere nettet. Hundrelappen er der for å motivere folk til å flytte forbruket sitt og spre det ut over flere timer.

Det er vel bare det at kostnad for å produsere strøm og kostnad for å levere den hjem til deg, ikke er relatert til hverandre. Vi har hatt en nærmest eksplosiv utbytting av biler i Norge og det norske elnettet er ikke lagd for at folk skal lade bilene sine billig i løpet av en time eller to. Det går bare ikke.

Jeg bruker ikke schedy. 5 minutters "pause" på ovnene la jeg inn i pyscript kode som jeg har for å styre varmen i huset. Poenget med pid regulator er nettopp at det er enkelt. Det finnes knapt noe så enkelt som det. Men det kan være litt jobb å justere den inn. Du har i alle fall veldig mye mer svingninger enn det jeg har. Hvis du tok vekk D leddet så er det naturlig med ustabilitet hvis du samtidig ikke reduserer P og I leddet. D leddet er stabiliserende, spesielt når det er så høyt som 2500 som det jeg brukte.

Alt som nå er under pidrun må du flytte til initialize. Under pidrun som du kjører hvert 10 sekund må du ha noe som dette: c = (0.9 * last_c) + (0.1 * pid(float(self.get_state("sensor.estimated_hourly_consumption")))) if round(last_c, 0) != round(c, 0): self.set_state("sensor.et_eller_annet") = round(c, 0) last_c = c

Appdeamon har en litt annen måte å referere til sensorer på enn det pyscript har. Kikk litt i dokumentasjonen til appdaemon. Store endringer er det ikke.

FYI: I tilfelle du ser etter noe nytt. Mine Nobø panelovner (og varmekabel termostater) har virket med 100% oppetid i HA siste 2 år.

Det håndteres ved at jeg ikke har noen last hjemme som er større enn 5kW og som jeg ikke kan kontrollere. Men summen av flere kan bli større enn 5kW. Jeg slår av alt annet som kan styres. Det er all varme, VVB og lading av biler. Men skulle oppvaskmaskin, vaskemaskin, stekeovn og koketopp bli satt på samtidig så får jeg heller ta kostnaden med det den måneden.

Jeg brukte omtrent 2 måneder i fjor på å stille inn parametre etter forsøk og feiling. Derivatleddet ble høyt fordi jeg ønsket en rask respons. Spesielt på slutten av en time. Men det som kanskje ikke kommer fram her er at jeg glatter ut det estimerte timesforbruket. Det baserer seg på de siste 5 minutters forbruk og da får jeg ikke slike store endringer som du ser. Varmekabel-termostatene mine slår av og på varme i 5 minutters intervaller så jeg ble nødt til å gjøre noe med den biten. - platform: derivative source: sensor.sensor_klepp_energi_effekt_integral name: real_time_consumption_gabriel_edlands_veg_16_integral_derivative round: 3 unit_time: h time_window: "00:05:00" Siden det er antall kwh/h som er satt i grenseverdiene hos netteiere, så er det det jeg regulerer etter. Jeg kan fint bruke opp mot 10kW mot slutten av en time hvis jeg holder meg under 5kWh den timen.

Hvis du har lagt inn appdaemon så passer det nok bedre å kjøre pid regulatoren der enn i pyscript.

Nedenfor er målingene som netteier har på 15. mai. 4,82kW er det høyeste og det ligger 0,02kW over det jeg regulerer etter. Årsaken til at jeg endte opp med 4,8kW er at jeg i en testperiode i fjor så at jeg kunne komme over grensen hvis jeg gikk inn for det og skrudde på koketopp på maks når det var nesten slutt på en time. Da nyttet det ikke å slå av alle varmekabler. Men nå lemper de litt på kravet og det er snittet av maks forbruk på 3 forskjellige dager som skal gjelde. Da går det kanskje å legge seg enda nærmere grensen på 5kW så mulig jeg øker det til 4,9kW istedenfor 4,8kW.

Her er den. Merk at jeg har en VVB jeg kan sette effekten trinnløst på og det blir brukt i koden nedenfor. Så ta det som et eksempel. Du må gjøre endringer uansett. Om pid regulatoren på hacs er brukbar, kan jeg ikke svare på. Men den er kanskje verd et forsøk? Jeg har hatt min i drift i mai og maks forbruk da ble 4,823kWh som er bra. Som du ser så regulerer jeg etter 0,2kWh under 5kWh så 4,8kWh er målet. Den 15. mai ble all varme slått på i huset etter en ferie. Da ble det 10 timer sammenhengende regulering under 100% for å ligge under 4,8kWh. Litt svingninger ble det de første 40 minuttene, men deretter fungerte det veldig stabilt. I hele mai har det vært 4 tilfeller der regulatoren har gått ned til ca 0% og slått av all varme. Det er 2 biler som skal lades så jeg innser at 5kWh/h blir for vanskelig for meg når behovet for oppvarming øker. I mai har det vært lett. Hvis en ser vekk i fra 15. mai så ville jeg vært under grensen uten å gjøre noe som helst. Alle disse "dippene" en ser i kurven nedenfor er i starten på en time der det estimerte forbruket er mest usikkert. Jeg kunne unngått nesten alle av de hvis en ikke regulerte ned de første 5 minuttene på hver time. Så kanskje det blir neste endring - noe som setter settpunkt til 10kWh i starten på hver time. Samtidig er det heller ingen heft med at varmekablene settes på lav temperatur i noen minutter....... from simple_pid import PID pid = PID(40.0, 0.4, 2500.0, setpoint=float(input_select.nettleie_pristrinn) - 0.2) pid.set_auto_mode(False) pid.sample_time = 1.9 pid.output_limits = (0, 100) pid.proportional_on_measurement = False pid.set_auto_mode(True, last_output=100.0) last_c = 100.0 turned_off_all = False turned_off_car = False @state_trigger("sensor.energy") def new_state(): global pid global last_c global turned_off_all global turned_off_car c = (0.9 * last_c) + (0.1 * pid(float(sensor.estimated_hourly_consumption))) #p, i, d = pid.components #state.set("sensor.regulator_p", round(p,1)) #state.set("sensor.regulator_i", round(i,1)) #state.set("sensor.regulator_d", round(d,1)) if round(last_c, 0) != round(c, 0): sensor.regulator_energy_usage = round(c, 0) v = max(5 * round(c, 0) - 400, 0.0) number.effekt_varmtvannsbereder.set_value(round(v,1)) last_c = c if c < 10 and turned_off_car == False: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "0") turned_off_car = True if c > 30 and turned_off_car == True: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "16") turned_off_car = False if c < 2 and turned_off_all == False: esphome.terrassevarmer_pause() switch.heru_electric_heater_connected.turn_off() persistent_notification.create(title = "Strøm", message = "Effektbegrensing slo av alt.") turned_off_all = True if c > 5 and turned_off_all == True: esphome.terrassevarmer_resume() switch.heru_electric_heater_connected.turn_on() turned_off_all = False @state_trigger("input_select.nettleie_pristrinn") def setpoint(value=None): pid.setpoint = float(value) - 0.2 @state_trigger("input_number.consumption_lasthour") def hourly_usage(value=None): if float(value) >= float(input_select.nettleie_pristrinn): script.turn_on(entity_id = "script.send_melding", variables = {'message': 'Strømforbruk var større enn grense', 'title': 'Strøm', 'channel': 'Info'})

Du har i alle fall muligheter innenfor 5 års reklamasjonsrett. Men utover det så vet jeg ikke om andre muligheter enn det som eventuelt står i avtalen du har inngått med de når du kjøpte dette.

Det er noe som skurrer her. Jeg forstår "logikken" at netteier må få dekket sine utgifter, men det er litt spesielt at dette lempes over på netteier og sluttkunde. I andre bransjer må produsent ofte dekke svinn. Her kunne en bare ignorert tapet og dermed ville det vært kraftprodusenten som tok utgiften i form av reduserte inntekter. Edit: Men det er vel lagd som det er for å synliggjøre tapet og skape en form for motivasjon for netteier å redusere det så godt som mulig.

Netteier har et tap i ledninger og transformatorer. Det er dette de skal dekke inn fordi kostnaden med dette blir belastet eier av nett.

???? Jeg har ikke nevnt nødladere. Det er 2 easee ladere som står på en felles 400V / 16A 3-fase kurs. Jeg har 11kW tilgjengelig, men har satt det ned til sneglefart. Som er greit nok, bilene trenger ikke lades fort.

Fungerer fint hos meg. Bildet viser effekten i mitt hus etter en periode der jeg var på ferie og kl 0900 ble VVB og varme påslått. De første 40 minutter er det en del ustabilitet, men deretter ligger effekten fint på 5kW. Kurven nedenfor er nesten lik, men den viser kWh som i 10 timer ligger rett under 5kWh/h. Er egentlig veldig fornøyd med PID regulatoren. Jeg har to elbiler og ladeeffekt er satt til 1,4kW på de begge. Det gjør det lettere å unngå å komme over maks effekt, men det nytter ikke å utnytte lav strømpris. Ladingen tar for lang tid til det.

Da har du i så fall siktet deg inn på et for lavt effekttrinn 🙂

Der er vi i så fall uenige 🙂 Det rettferdige er at inntektene gjenspeiler utgiftene, synes jeg og tydeligvis NVE.