Vinnerliste

Nei, "var" er ikke noe nytt og mystisk. Reaktiv effekt måler man med et voltmeter og et amperemeter. Verdiene multipliseres, og man får volt-ampere. Det er ikke alltid man fysisk kan måle dem fordi det er for eksempel en resistans i den koppertråden som man bruker for å vikle en spole, men det endrer ikke prinsippet. Problemet med reaktiv effekt, er at den er i volt-ampere, akkurat som det som kalles "tilsynelatende effekt". Når man for eksempel måler strømtrekket til et kjøleskap (som er induktivt på grunn av motoren) og multipliserer med tilført spenning, får man en effekt. Vi vet at strøm x spenning er Watt, men det stemner bare hvis det er likestrøm, eller at lasten er rent resistiv (ohmsk motstand, f. eks. ei glødelampe eller en helt tradisjonell panelovn eller gammeldags komfyr). Da vil strøm x spenning gi svaret i watt. Når det er noe reaktivt (spoler og / eller kondensatorer) inne i bildet, får vi faseforskyving, og strømmens maksimale verdi vil ikke opptre samtidig som spenningens maksimale verdi. Da vil ikke den effekten vi regnet ut for kjøleskapet være den samme effekten som faktisk gjør et arbeid for oss (den som måles i watt). Det er derfor den kalles "tilsynelatende effekt". Jeg skrev at de fleste lærebøkene skriver VAr med r-en som subscript. Det er for å vise at r-en ikke er en ny enhet, men at VA er reaktiv, og ikke den tilsynelatende effekten som bare skrives VA. * Vi har den effekten som gjør en jobb for oss. Den måles Watt, og beregnes som P = U x I Vi har den tilsynelatende effekten. Den måles i VA, og beregnes som S = U x I Til slutt har vi den reaktive effekten som ikke gjør noe annet enn å flytte strøm frem og tilbake mellom kilden og forbrukeren. Den måles også i VA, men for å skille den fra den tilsynelatende effekten, slenger vi på en liten r slik at det blir VAr. Den beregnes som Q = U x I Alle disse tre effekten henger sammen, og vi kan beregne dem ved hjelp av pytagoras i effekttrekanten. Da får vi også ut fasevinkelen som er vist som fi i figuren. Det er ikke vinkelen vi er interessert, men cos fi som blir P/S. Den skal ideelt være lik 1 (dvs. ikke noe reaktiv last), men det er vrient å få til. Grunnen til at nettselskapene ikke liker reaktiv last, er at den må flyttes rundt i nettet, og den "bruker opp" plass i ledninger og transformatorer. Den blir ikke borte på noe vis, så det er ikke slik at den i seg selv gir et tap, men den medfører ekstra kostnader. Den gir et tap på grunn av at ledninger varmes opp, men det er ikke det store problemet. Det virkelige problemet, er at man må bruke kraftigere transformatorer og ledninger enn hva man egentlig behøver for å flytte den effekten som gjør en jobb, og som de kan selge. Det er ikke noe annet enn helt standard SI-enheter i disse regnestykkene, så det er derfor de aller fleste skriver VAr, hvor r-en kun er ment å fortelle at svaret er reaktivt. Jeg kan legge til at transformatorer og generatorer aldri oppgis i watt. De oppgis alltid i VA, siden den verdien aldri kan bli mindre en verdien i watt. Det er for å ta hensyn til den reaktive effekten som nesten alltid er i et nett. Det med "var" som en enhet stammer visst fra 30-tallet. Det har skjedd mye siden den tiden, selv om metriske måleenheter fantes. Det er sikkert noen som har lært elektromagnetisme med GCS-systemet, som ikke er lei seg for at det også har endt opp på skraphaugen. Når man ser poenget med SI, er det ingen logisk grunn til å finne opp noe annet, slik som "var" faktisk er.

Jeg tenkte å ta en kjapp wirte up på hvordan jeg har begrenset effektleddet med openHAB. Jeg ser at det skrives noe om PID andre steder men det ble for avansert for meg å sette meg inn i Før man begynner må man ha inn ActiveImportPower fra HAN-porten på en eller annen måte. Jeg bruker kortet jeg lagde i 2017/18 som blant annet @ArnieO har tatt til nye høyder. Først lagrer jeg alle verdier i InfluxDB for enkelhets skyld med følgende dette python-script. Det kjører som en service. # -*- coding: utf-8 -*- import random import time from datetime import datetime from paho.mqtt import client as mqtt_client from influxdb import InfluxDBClient broker = 'openhabian.localdomain' port = 1883 topic = "esp/ams/activeimportpower" client_id = f'python-ams-mqtt-influx-{random.randint(0, 1000)}' dbname = "ams" dbuser = "ams" dbpass = "ams" def connect_mqtt(): def on_connect(client, userdata, flags, rc): if rc == 0: print("Connected to MQTT Broker!") else: print("Failed to connect, return code %d\n", rc) # Set Connecting Client ID client = mqtt_client.Client(client_id) client.on_connect = on_connect client.connect(broker, port) return client def subscribe(client: mqtt_client, dbclient: InfluxDBClient): def on_message(client, userdata, msg): print(f"Received `{msg.payload.decode()}` from `{msg.topic}` topic") store(dbclient, msg.payload.decode()) client.subscribe(topic) client.on_message = on_message def store(dbclient: InfluxDBClient, power): json_body = [ { "measurement": "activeimportpower", "time": datetime.now(), "fields": { "value": int(power) } } ] dbclient.write_points(json_body) def run(): dbclient = InfluxDBClient('localhost', 8086, dbuser, dbpass, dbname) client = connect_mqtt() subscribe(client, dbclient) client.loop_forever() if __name__ == '__main__': run() Deretter kalkulerer jeg gjeldende kWh-forbruk hver andre minutt med dette scriptet. Det kjører som en cron-jobb (*/2 * * * *). # -*- coding: utf-8 -*- import random import time from datetime import datetime from paho.mqtt import client as mqtt_client from influxdb import InfluxDBClient broker = 'openhabian.localdomain' port = 1883 topic = "esp/ams/avaragewh" client_id = f'python-avarage-wh-{random.randint(0, 1000)}' dbname = "ams" dbuser = "ams" dbpass = "ams" def connect_mqtt(): def on_connect(client, userdata, flags, rc): if rc != 0: print("Failed to connect, return code %d\n", rc) # Set Connecting Client ID client = mqtt_client.Client(client_id) client.on_connect = on_connect client.connect(broker, port) return client def publish(client, dbclient): avarage = avarage_wh(dbclient) # If avarage is None we probably don't have enough data to calculate the avarage if avarage is None: return result = client.publish(topic, avarage) # result: [0, 1] status = result[0] if status != 0: print(f"Failed to send message to topic {topic}") def avarage_wh(dbclient): hour_start = str(datetime.now().replace(microsecond=0, second=0, minute=0)).replace(' ', 'T') result = dbclient.query(f"SELECT * FROM activeimportpower WHERE time >= '{hour_start}Z'") count = 0 sum = 0 try: for val in list(result)[0]: count += 1 sum += val['value'] except: return None return round(sum / count) def run(): dbclient = InfluxDBClient('localhost', 8086, dbuser, dbpass, dbname) client = connect_mqtt() publish(client, dbclient) client.disconnect() if __name__ == '__main__': run() Da får vi gjeldende kWh ut på mqtt-topic "esp/ams/avaragewh" som vi kan bruke i openHAB til å gjøre noen beslutninger med disse reglene: var high_kwh_threshold = 4800 // Turn off items if kWh is above this number var low_kwh_threshold = 4600 // Turn on items if kWh is below this number var min_current_w = 4500 // If we need to turn off items, turn off enough items so that the current watt usage is below this number var max_current_w = 6000 // If we can turn on items, turn on enough items so that the current watt usage is below this number rule "high kwh" when Item AMS_AvarageWh changed then // If the avarage is above 4800 kWh we need to bring the current usage below 4500w if ((AMS_AvarageWh.state as Number) > high_kwh_threshold) { var current_w = AMS_ActiveImportPower.state as Number // Turn off office if (current_w > min_current_w && OfficeHeat_Switch.state == ON) { OfficeHeat_Switch.sendCommand(OFF) current_w -= OfficeHeat_Electricmeterwatts.state as Number // Subtract current usage } // Turn off hallway if (current_w > min_current_w && (HallwayFloor_Thermostatmode.state as Number) == 1) { HallwayFloor_Thermostatmode.sendCommand(0) current_w -= HallwayFloor_Electricmeterwatts.state as Number // Subtract current usage } // Turn off bath room if (current_w > min_current_w && (BathRoomFloor_Thermostatmode.state as Number) == 1) { BathRoomFloor_Thermostatmode.sendCommand(0) current_w -= BathRoomFloor_Electricmeterwatts.state as Number // Subtract current usage } // Turn off living room if (current_w > min_current_w && LivingHeat_Switch.state == ON) { LivingHeat_Switch.sendCommand(OFF) current_w -= LivingHeat_Electricmeterwatts.state as Number // Subtract current usage } } end rule "low kwh" when Item AMS_AvarageWh changed then //logDebug("ams", "LOW KWH START") // If the avarage is below 4600 kWh we can start to bring the current usage up if ((AMS_AvarageWh.state as Number) < low_kwh_threshold) { var current_w = AMS_ActiveImportPower.state as Number // Turn on living room if (current_w < max_current_w && LivingHeat_Switch.state == OFF) { LivingHeat_Switch.sendCommand(ON) current_w += 1200 // Based on experience } // Turn on bath room if (current_w < max_current_w && (BathRoomFloor_Thermostatmode.state as Number) == 0) { BathRoomFloor_Thermostatmode.sendCommand(1) current_w += 800 // Based on experience } // Turn on hallway if (current_w < max_current_w && (HallwayFloor_Thermostatmode.state as Number) == 0) { HallwayFloor_Thermostatmode.sendCommand(1) current_w += 700 // Based on experience } // Turn on office if (current_w < max_current_w && OfficeHeat_Switch.state == OFF) { OfficeHeat_Switch.sendCommand(ON) current_w += 700 // Based on experience } } end Her er det en del tall jeg bare har tatt rett ut av luften. F.eks. så ønsker jeg at kWh holder seg under 4800. For å klare det har jeg gjettet på at effekten må under 4500w for å komme under 4800kWh dersom man har kommet over. Deretter når man har kommet under 4600kWh så gjetter jeg på at man kan slå på ting helt til man er på maks 6000w. Det er bare 4 aktører jeg har lagt inn (alle varmekildene) i min prioriterte rekkefølge. Her ser man hvordan scriptet har jobbet seg gjennom natten med VVB og oppvaskmaskin i sving: Her er når vi våknet i dag. Som man ser så er det ugunstig å gå inn i timen med høy effektbruk: Middagslagingen i går gikk bedre fordi da startet jeg tilfeldigvis på halv time: Her er mine beregninger opp mot hva nettleverandører mener. Ser greit ut med +- 2% avvik på det meste.

Takk! 🙂 Det er for så vidt det jeg gjør i Pow-U (trekker power fra HAN). Fra den gjerrigste måleren i bruk i Norge kan man trekke 144 mW (ved 24/12V), det blir ca 30 mA på 3,3V. Det er så vidt jeg vet for lite for å drive en Raspberry Pi Zero W. https://raspi.tv/2017/how-much-power-does-pi-zero-w-use

Fantastisk prosjekt! - Kunne man trukket power fra HAN på en generisk måte til å drive feks en raspberry pi w zero?

Dette har vært svært effektivt for oss som ligger helt i grenseland når jeg ser på den timen med høyes forbruk på en gitt dag. Men jeg ser at dagsforbruket (kolonnen til venstre) holder seg svært likt. Det har bare jevnet seg litt mer ut.

Takk @Nedrehagen med litt tweaking så ble dette en bra oversikt.

Du kan forsøke å bruke dynamiske PID variabler. Rett før du går over til ny time kan du forsøke å redusere P verdien din en god del, slik at I leddet får jobbet seg rolig oppover, så etter kanskje 15 minutter skifter du tilbake den opprinnelige P verdien.

Tror det typisk skjer når Tibber sine servere sliter, dessverre...

Monterte idag en Apex Smart Plug på en 2kw bereder 🙂

Aqara-plugger støtter at man deaktiverer av/på, og de er Zigbee. Selges f.eks hos Kjell: https://www.kjell.com/no/produkter/smarte-hjem/smarte-hjem-losninger/aqara-smarte-hjem/aqara-smart-plug-p51329