xibriz

Det er korrekt, jeg har kun fokusert på effektleddet. Det som i realiteten skjer er jo at strømforbruket begrenses, spesielt på oppvarming. Boligen min har ett umettelig oppvarmingsbehov så all besparelse er pga. at komforttemperaturen i år nok er litt lavere enn i fjor. En annen effekt er at jeg ofte skrur av unødvendige ting for å få mer strøm tilgjengelig til oppvarming, og prioriterer hvilke rom som skal varmes opp. Det er nok her besparelsen ligger.

Nå er året snart omme, og jeg ligger an til en besparelse på mellom 4 og 5000 kWh på hele året pga. skriptet som prøver å holde forbruket under 5 kWh siden fastledded dobles fra 2-5 kontra 5-10 kWh. 200 kvm ende-rekkehus fra 1970: 2021: 28 000 kWh 2022: 23 000 kWh Det som er irriterende er jo at jeg ikke har styring på absolutt alt, så hvis det sniker seg inn en time der det ikke er mer å slå av, så havner jeg likevel over 😡 Den toppen kostet 150 kr:

Jeg holdt mye på med radiostyrte biler og lipo-batterier før. En gang koblet jeg feil på pluss og minus til laderen, og når jeg skjønte det etter 1.5 sekund så var ledningene så varm at jeg måtte ofre en del hud for å dra ut ledningene. Der snakker vi om farlige greier 🤯

Etter litt reasearch på sofaen: En pir-sensor har gjerne 2-4 felter som detekterer bevegelse når ett objekt flytter seg fra ett felt til ett annet på sensoren. Plasttypen polyethylene (finnes i plastposer) slipper gjennom riktige bølgelender. En "skyggelinse" er en fattigmannsversjon av frensel 😛 En kjapp test viser at jeg er inne på noe her Lesestoff for de intereserte: http://www.glolab.com/focusdevices/focus.html

Ja det var vel det jeg fryktet. Jeg må se om jeg kan finne noe brukende å demontere her hjemme.

Har jobbet med en multisensor (lys, temperatur og bevegelse) de siste dagene. Jeg hadde ikke lyst til å ha den vanlige "domen" som er forran PIR-sensoren så jeg har prøvd noen materialer (transparent PLA, utklipp fra noe emballasje) uten hell. Slik jeg skjønner det så må jeg finne noe materiale som slipper gjennom de riktige IR-bølgelengdene. Noen som har noen tips til materialvalg? For scale

Det er litt misvisende for jeg har panelovner på 800w og konvektorovner på 2000w, varmekabler på henholdsvis 500w (sov), 700w (gang), og 800w (bad). Så min gamle elbil hadde ett strømforbruk på: 3x konvektorovn + varmekabel sov + varmekabel bad - varmekabel gang = 6.6 kW Siden jeg bare har 2 konvektorovner så blir dette vanskelig å forholde seg til 🤣

Jeg synes hele nettleiediskusjonen er veldig uoversiktlig og minner om propaganda fra alle kanter. I det ene øyeblikket så sies det at hvis man ikke foretar seg noe så kommer man dårligere ut med ny nettleie enn med dagens modell. I neste øyeblikk så taper kundene på at den nye nettleiemodellen nå utsettes. Hva som er fakta er ikke lett å finne ut av. I tillegg så har min kraftleverandør (Arva) ikke publisert noen priser om ny modell selv om det knapt 2 uker til den skal innføres. Nå skylder de på regjeringen men de hadde ikke publisert noen info før fredagen heller.

Dere burde roe ned bruken av å starte en topic med / Det gir ingen mening og best practice er at man ikke bruker "leading slash".

Det er så vidt man ser C# der nede på listen Ref https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages

Er det effektrapportering på disse dimmerene? Jeg plugget nettopp i 4 stk aeotec switch 6 og opplever at z-wave-nettverket ble betraktelig mye tregere. Jeg antar at dette er pga. effektrapporteringen. Det må sikkert bare tunes litt så blir det vel bra, men det irriterer meg ikke foreløpig

For meg personlig passer det ypperlig med billigere strøm på dagtid siden det er da jeg bruker mest 😉

Helt enig. Jeg føler at de eneste som driver med smarte løsninger for strøm er nettselskapene. Det er helt håpløst å bruke mest mulig strøm når den er billigst samtidig som man holder seg under en maksverdi på timen.

Tok en kjapp kikk på dokumentasjonen: https://www.home-assistant.io/integrations/sensor.mqtt/ og https://www.home-assistant.io/docs/configuration/templating/#attributes Og det ser ut som det skal være `value__json` og ikke `value.json`.

Vi får vente til en kar fra ett kraftselskap med litt teknisk kompetanse stikker innom tråden

Grunnen til at jeg spør er at en slektning ble kontaktet av kraftselskapet om at han hadde jordfeil og måtte fikse det. En elektriker fant jordfeil i en skjøteledning etter 3-4 timers feilsøking. Også leser jeg her: https://www.tromskraftnett.no/privat/ams Så da tenkte jeg at kanskje man kunne være preventiv hvis man visste dette så fort som mulig (kanskje man akkurat hadde plugget i noe).

En annen ting, jeg vet at nettselskapet kan bruke AMS-måleren til å se jordfeil. Er dette noe man kan dra ut av HAN-porten?

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.

Du må huske å justere tallene (4500, 4800, 6000 osv) til noe nærmere 10000 hvis du satser på 10kWh.

Jeg lagrer verdien når jeg får den og bruker timestamp på serveren og ikke fra måleren. Men forsinkelsen er vel ikke værre enn at det blir +- ett par målinger. Så tar jeg å leser alle verdier innenfor gjeldende time, summerer de sammen og deler på antall verdier. Jeg bruker den versjonen fra da jeg var med på å lage den, og den er vel fra 2018 eller eldre Kanskje jeg må legge inn en bestilling hos deg siden min krever stikkontakt. Det gikk bra i det forrige huset fordi der hadde jeg kontakt på DIN-skinnen, men her må jeg strekke en lang kabel til nærmeste stikk 😛

Jeg lurer på om det er litt tidsforsinkelse på dataen som nettleverandøren bruker. Jeg fikk en differanse på over 4% en time der det var høyt effektbruk i timeskillet. Det er helt i grenseland av hva som er håndterbart dersom mine beregninger hadde vist 4800kWh.

Det værste er at det ikke er mange minuttene man må slå av varmekilder/store laster på en time for å kompansere. Maks 5-10 minutter har jeg erfart siden jeg begynte på søndag

Jeg vurderte å gå over til HomeAssistant, men openHAB er blitt så bra at jeg ikke orket Det jeg liker best med openHAB er at man kan skrive alt i tekstfiler. Ja, man hadde sikkert klart å lage regelen over i GUI, men kan man programmere er det kjappere å bare bruke nano i bash

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.

Dette er det beste svaret så langt