Vinnerliste

Nei, du kan ikke få noe lurt ut av dem, før du vet hva det er, og hvordan ting henger sammen. Hvis du har mer utstyr enn det man har i en leilighet, kan det være veldig interessant, for reaktiv effekt er det som er dimensjonerende for sikringer og ledningsføring. Man skal ikke ha for mange gamle lysrørarmaturer i et hus før reaktiv effekt drar på så mye at det spiser kapasitet på sikringer. Jeg har ikke spesielt mye merkelig hos meg, men ser titt og ofte mer enn 1 kVAr, og hvis alt er på en kurs, blir det lite tilbake. Nå er det vel ikke bare folk uten noe interesse for strøm som går løs på å bygge egen HAN-leser, så det er nok flere enn jeg som finner det litt interessant. Som jeg sa et annet sted, så er det mer enn nok med tallet uten noe mer fancy. Kanskje noen blir nysgjerrige, og prøver å lære mer også. Alt som kan få opp interessen for strøm hos ungdom er av det gode.

Listene over OBIS-koder som NEK har publisert bruker kVAr og kVArh, så det er ikke helt feil vil jeg mene.

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.

Jeg tror han mener stedet man kjøper HC Lite fra for så å returnere den og få igjen pengene. De må ta kostnadene ved at ett produkt går fra å være standard utsalg til "outlet" siden noen har brukt det og så returnert.

Det er jo synd du blander inn en uskyldig 3. person i dette som må ta dine kostnader 🤔

Så hvis jeg leser det riktig så er forsjellen mellom spink og spar og tut og kjør 340 kr per måned? Da er det ikke akkurat der jeg skal være redd for å ende opp øverst, men heller alle de timene hvor strømprisen er veldig høy. Ergo blir det lading, vasking og oppvarming når man ligger og sover (satt på spissen).

Jeg tar mase-oppfordringen på strakarm. Sendte denne mailen til Fibaro akkurat.

Det er selvfølgelig ikke optimalt å kjøre uten Termostater. Men TTT Har tatt litt tid å kjøre inn huset. For kjøkkenet trenger lengere pauser enn stua for å holde samme Temperatur. Nå blir det litt varmt når temperaturen ute stiger og tilsvarende lavt når temperaturen ute synker. med en termostat kunne jeg lettere kompensert for endringer. men det kommer når jeg får tid. WAF(Wife Acceptance factor) er stabilt lavt, så da kan det bare bli bedre

Hva er det ?? 🤣🤣🤣🤣🤣🤣 Har ikke kommet så langt. Men driver å lager noen selv basert på ESP32. Jeg har heller ikke gulv føler lagt ned i betong, men kommer til å legge en føler på betongen under parketten for å se til at vi har en jevn betong temp (som mulig). Ser litt på Z-TRM3 fra Heatit. Men har ikke 230V til veggboksene mine så derfor avventer jeg litt med det. Om du lurer styrer jeg mine ventiler med PWM. 10 minutter på og et selvalgt pause mellom. Et eks stuen 10 minutter på og 30 minutter av(Så lenge strøm prisen er lavere enn snittet for dagen )

Neppe som privatperson i og med at du ikke betaler for dette. Større bedrifter slipper ikke unna og må betale. For kraftprodusentene er det stort sett penger rett ut av vinduet å levere reaktiv effekt til husholdninger, men lite å gjøre noe med.

Bruker homeseer og z-water i dag. Bruker tibberseer som @Moskus har laget og styrer ventilene(aktunator) etter strømprisen. Har vannbåren varme med elkassett. Har ikke mulighet for å slå av elkassetten idag. Derfor styrer jeg ventilene til sløyfene. Sent fra min SM-G970F via Tapatalk

Ser ut til at den mistet timespakken på midnatt. Jeg har tenkt at den skal fordele neste timespakke 50/50 på manglende timer, men har ikke kommet så langt enda.

Det står også noe om hva kraftbransjen bruker. Det er en grunn til at de bruker store bokstaver, som jeg skrev. Verden er større enn EU, selv om de sikkert ikke er enig :-)

Blir litt paralellkjøring av andre tråder med denne men skitt au. Jeg kjører automatikken i Node Red så det hele ser en smule anderledes ut enn i HA selv om prinsippene kan være nokså like. Kommet et godt skritt videre, fra litt stivbeint lastprioritering etter strømpris har jeg laget PID regulator som på en langt mer dynamisk måte prioriterer last ut fra et setpunkt på max kWh pr time. Ser så langt ut til å fungere veldig godt. Setpunktet til PID regulatoren er et beregnet kWh timefornbruk som tas fra aktuelt forbruk til nå denne time delt på antall sekund inn i denne time ganget med 3600. For å prøve å unngå store hopp ved timeskift fryses setpunktet inntil akkumulert verdi denne time er > 0.1kWh, det hjelper en del men er ikke godt nok, får funke inntil videre: Har av og til litt trøbbel i timeskiftene dersom lasten endrer seg en del blir der noen store hopp men den tar seg nå godt inn igjen rimelig kjapt. Styrer setpunkt på regulatoren i 3 trinn ut fra strømpris og det ser ut til å funke bra det og. Akkurat nå, for testing, er grensene satt en god del lavere enn de kommer til å være (billig: 3.2kWh, medium: 1.8kWh og dyr: 1.2kWh) men om ikke der skjer store endringer i forbruket så blir kanskje grensene liggende slik framover... Blå strek er utsignalet fra PID og alle laster som kan prioriteres bort er plassert en eller annen plass på 0-100 skalaen (omskalert til 0-10 i bildet her). Lavest prioritet har vv bereder som slår seg av ved 90% og på igjen ved 95. Gulvvarme, luft/vann varmepumpe og slikt er plassert noenlunde likt nedover på skalaen. Ideelt sett skulle f.eks. 10% endring av utsignalet også gi rundt 10% endring i last men det er helt umulig å få til i praksis, f.eks. når utsignalet passerer grense for å slå på gulvvarme kan det jo godt være at det ikke skjer fordi termostaten allerede har slått det av. Jeg ser de som kjører HA har noen heeeelt andre PID parametre som funker for dem men som en tommelfingerregel skal D være noe i området rundt 1/3 av I, jeg har funnet at 1/2 av I er en nær grense for hvor mye derivasjon jeg bør ha:

Hva i alle dager er det du snakker om? Trolling much?

NB NB: Denne plugin ser ikke ut til å være kompatibel med nyere varmepumper fra Daikin (2021 eller nyere). Daikin har valgt å endre på WIFI-modulen slik at alt ligger i en sky. Og tilsynelatende kun gitt tilgang til "third parties" som betaler for tilgang.