berland

Thanks a lot, your websocket code worked straight away for me. I will merge your GPL3 code into mine GPL code 👌

Every tenth second here 😎 But I will try out hansrunes websocket code, an then maybe that often is not that relevant

Jeg lagde selv en liten integrasjon mot mitt OpenHAB-hus i fjor høst, og ser ut til å ha kommet like langt som deg. Ingen websocket som fungerte, selv etter kontakt med kundeservice og mye testing i Postman. Savner status på dørlås via API, den fikk jeg aldri, men hadde kanskje fått tak i den hvis jeg fikk websocket til å fungere. Min lille bit med kildekode ligger på https://github.com/berland/pyrotun/blob/master/pyrotun/connections/homely.py, denne har tuslet og gått i det minste siden oktober.

Min modbus-konfigurasjon (som jeg fant på nettet en gang, og som virker på OpenHAB2 (og tidligere)) konfigurer Modbus som under. Mulig du kan plukke ut noe relevant derfra for å bruke på ditt system? pi@loftspi:/etc/openhab2 $ cat services/modbus.cfg poll=5000 writemultiperegisters=true serial.vvfan.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvfan.id=1 serial.vvfan.start=100 serial.vvfan.length=38 serial.vvfan.type=holding serial.vvfan.valuetype=int16 serial.vvhc.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvhc.id=1 serial.vvhc.start=200 serial.vvhc.length=21 serial.vvhc.type=holding serial.vvhc.valuetype=int16 serial.vvrot.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvrot.id=1 serial.vvrot.start=350 serial.vvrot.length=2 serial.vvrot.type=holding serial.vvrot.valuetype=int16 serial.vvsys.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvsys.id=1 serial.vvsys.start=500 serial.vvsys.length=7 serial.vvsys.type=holding serial.vvsys.valuetype=int16 serial.vvnvm.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvnvm.id=1 serial.vvnvm.start=548 serial.vvnvm.length=1 serial.vvnvm.type=holding serial.vvnvm.valuetype=int16 serial.vvclock.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvclock.id=1 serial.vvclock.start=550 serial.vvclock.length=7 serial.vvclock.type=holding serial.vvclock.valuetype=int16 serial.vvfilter.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvfilter.id=1 serial.vvfilter.start=600 serial.vvfilter.length=2 serial.vvfilter.type=holding serial.vvfilter.valuetype=int16 serial.vvdefr.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvdefr.id=1 serial.vvdefr.start=670 serial.vvdefr.length=2 serial.vvdefr.type=holding serial.vvdefr.valuetype=int16 serial.vvdig.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvdig.id=1 serial.vvdig.start=700 serial.vvdig.length=9 serial.vvdig.type=holding serial.vvdig.valuetype=int16 serial.vvtsf.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvtsf.id=1 serial.vvtsf.start=3488 serial.vvtsf.length=5 serial.vvtsf.type=coil serial.vvtsf.valuetype=bit serial.vvdi.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvdi.id=1 serial.vvdi.start=11200 serial.vvdi.length=7 serial.vvdi.type=coil serial.vvdi.valuetype=bit serial.vvpcu.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vvpcu.id=1 serial.vvpcu.start=12000 serial.vvpcu.length=3 serial.vvpcu.type=coil serial.vvpcu.valuetype=bit serial.vval.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:5000 serial.vval.id=1 serial.vval.start=12800 serial.vval.length=9 serial.vval.type=coil serial.vval.valuetype=bit # sets refresh interval to Modbus polling service. # Value in milliseconds (optional, defaults to 200) ## Example of Modbus TCP slave # Connection parameters to Modbus TCP server ("slave"), values separated by colon (:) # - host or ip of the modbus server ("slave"), mandatory # - port, optional, default 502 # - interTransactionDelayMillis, optional, in milliseconds, default 60 # - reconnectAfterMillis, optional, in milliseconds, default 0 # - interConnectDelayMillis, optional, in milliseconds, default 0 # - connectMaxTries, optional, default 3 # - connectTimeout, optional, in milliseconds, default 0 (=infinite or OS default) # # As a general rule, usually only host needs to be specified. Parameters other than host # and port should be overridden only in cases when extreme performance is required, or when there are # errors with the default parameter values. # # See wiki for more details. # # # # (slave name) (host or IP) # | | (port) # | | | (interTransactionDelayMillis, in milliseconds) # | | | | (reconnectAfterMillis, in milliseconds) # | | | | | (interConnectDelayMillis, in milliseconds) # | | | | | | (connectMaxTries) # | | | | | | | (connectTimeout) # | | | | | | | | #tcp.slave1.connection=192.168.1.100:502:60:0:0:3:100 # The data type, can be "coil" "discrete" "holding" "input". See wiki for more details. #tcp.slave1.type= # The slave id (optional, defaults to '1') #tcp.slave1.id= # The slave start address (optional, defaults to '0') #tcp.slave1.start= # The number of data item to read # (optional, defaults to '0' - but set it to something meaningful) #tcp.slave1.length= # Value type, required for combined registers (details: http://www.simplymodbus.ca/FAQ.htm#Types) # Can be "bit", "int8", "uint8", "int16", "uint16", "int32", "uint32", "float32" # (optional, defaults to 'uint16') #tcp.slave1.valuetype= # For other slave parameters, consult the wiki. ## Example of Modbus Serial slave # Connection parameters to Modbus Serial server ("slave"), values separated by colon (:) # - serial port, mandatory. Example: /dev/ttyS0 (linux) or COM3 (windows) # - baudRate, optional, default 9600 # - dataBits, optional, in milliseconds, default 8 # - parity, optional, default none # - stopBits, optional, default 1 # - encoding, optional, default rtu # - interTransactionDelayMillis, optional, in milliseconds, default 35 # - receiveTimeoutMillis, optional, in milliseconds, default 1500 # - flowControlIn, optional, default none # - flowControlOut, optional, default none # # As a general rule, usually one needs to specify serial port, baudRate, dataBits, parity, stopBits, and encoding. Other parameters # should be overriden only in cases when extreme performance is required, or when there are # errors with the default parameter values. # # See wiki for more details. # # # # (slave name) (host or IP) # | | (baud) # | | | (dataBits) # | | | | (parity) # | | | | | (stopBits) # | | | | | | (encoding) # | | | | | | | (interTransactionDelayMillis) # | | | | | | | | (receiveTimeoutMillis) # | | | | | | | | | (flowControlIn) # | | | | | | | | | | (flowControlOut) # | | | | | | | | | | | # | | | | | | | | | | | #serial.slave1.connection=/dev/ttyS0:38400:8:none:1:rtu:35:1500:none:none # The data type, can be "coil" "discrete" "holding" "input". See wiki for more details. #serial.slave1.type= # The slave id (optional, defaults to '1') #serial.slave1.id= # The slave start address (optional, defaults to '0') #serial.slave1.start= # The number of data item to read # (optional, defaults to '0' - but set it to something meaningful) #serial.slave1.length= # Value type, required for combined registers (details: http://www.simplymodbus.ca/FAQ.htm#Types) # Can be "bit", "int8", "uint8", "int16", "uint16", "int32", "uint32", "float32" # (optional, defaults to 'uint16') #serial.slave1.valuetype= # For other slave parameters, consult the wiki.

Equinor får neppe mer penger til å elektrifisere sokkelen direkte av situasjonen, men siden hovedårsaken til dagens strømpriser er høye gasspriser, så tjener Equinor likevel milliarder på milliarder av situasjonen. Denne inntjeningen går først og fremst til skatt til staten (da snakker vi rundt 80%), og så deles resten på eierene til Equinor (og der finner vi jammen staten Norge igjen med 2/3 eierskap). Hvis man ikke stoler på egne myndigheter, så oppleves det selvsagt problematisk at myndighetene håver inn i bøtter og spann. Jeg har tillit til at norske myndigheter bruker disse pengene fornuftig (det store byråkratiet fungerer som en sikkerhetsbarriere mot ufornuftig pengebruk), enten inntektene kommer fra stømsalg eller hydrokarbon-salg. Å selge deler av dette til underpris i lokalt marked er eksempel på slik ufornuftig pengebruk, med tullete energisløsing som konsekvens. Det taper miljøet på. Miljøet har tapt nok allerede på manglende insentiver til investeringer i isolerte hus pga lave strømpriser de siste årene.

Beklager, der traff du ikke

Tenk på om vi hadde forvaltet oljeressursene på en slik måte, dvs. solgt den med intensjon om billigst mulig pris innenlands og solgt minst mulig til utlandet for å verne om lave priser innenlands. Hvor stort hadde oljefondet vært da? Null? Jeg vil påstå at det utvilsomt er det beste for almennheten (både økonomisk og miljømessig) å selge strømmen til høystbydende. Vi har mange muligheter til omfordeling av pengene i etterkant, det dummeste stedet man kan subsidiere strøm på er ved struping av prisen. Ja til flere kabler. Helst en til Island også.

Jeg har kode som skal gjøre det samme, håper å ha koden klar til 1. januar Det blir en ren Python-løsning, som snakker med OpenHAB (men forsåvidt ikke avhengig av OpenHAB på noen måte). En utvidelse av koden som ligger på https://github.com/berland/pyrotun Så lenge utetemperaturen her i Bergen ikke kommer under 6-8 minusgrader (døgnsnitt), så tilsier statistikken her i huset at det skal gå an å holde seg under 5 kilowatt. Men strømprisvariasjonene nå til dags gjør at den lastflyttingen jeg gjør allerede (floors.py og waterheater.py i kode-repoet over) er i stand til å tjene inn over 100 kr pr måned. Det er helt umulig å vite 1. januar 2022 om det er mest økonomisk å ligge under 5 kW, eller mellom 5 og 10 kW, akkurat det er irriterende.

Noen måneder har gått med denne algoritmen kjørende, så det er på tide å analysere litt. Første plott her viser hva jeg estimerer til å være kostnadsbesparelse pr. døgn på grunn av lastflytting. Estimatet er laget ved å anta at totalforbruk gjennom døgnet hadde vært det samme, men hvis forbruket hadde fulgt en gjennomsnittlig døgnprofil for norske forbrukere. Gjennomsnittet av dagsbeløpet i disse 3 mnd er 1.8 NOK, som innebærer 1-2% av strømregningen. Variasjon i daglig sparebeløp kommer av akkurat hvordan prisprofilen er de relevante dagene, og når på døgnet lavpunktet kommer. Den viktige antakelsen for besparelsen estimert over er at jeg ikke bruker mer strøm enn ellers. Dette er uansett en sannhet med modifikasjoner, for fyring av varmekabler når man ellers kunne nattsenket vil nødvendigvis gjøre at huset risikerer å holde en høyere gjennomsnittstemperatur enn ellers, som medfører mer varmetap. Dette er ikke til å unngå, så spørsmålet er om lastflyttingen sparer så mange kroner at denne effekten overskygges. Varmtvannstank er inkludert i besparelsen over, og der gjelder ikke denne effekten like mye. Enn så lenge, så er det heller ingen elbil-lading inkludert. Jeg bruker et scatter-plott for døgnforbruk mot utetemperatur for å avgjøre dette. Her er alle grå punktene data for de siste 2 år, og punkter med farge er de hvor algoritmen har vært aktiv, og fargeskalaen er den estimerte besparelsen (samme tall som i plottet over): Antakelsen om at strømforbruket ikke endrer seg ville stemt hvis alle de fargene punktene lå "midt" i den gråe skya. Dette ser bare ut til å stemme for de dagene der besparelsen er opp til 3-4 kr (som forsåvidt er en helt grei besparelse!). Når besparelsen er oppi 10 kr og over, så ser det ut som om algoritmen blir for aggressiv, og gjør at huset er litt for varmt, kanskje 500-1000W for mye forbruk, noe som forsåvidt er tilsvarende besparelsen de aktuelle dagene i kroner og øre. For enkelhets skyld og med litt godvilje, vil jeg da påstå at oppnåelig besparelse for meg tilsvarer 1% av strømregningen. Jeg skal si meg fornøyd nok med det og kommer ikke til å skru av algoritmen. Jeg trenger ikke lenger se strømprisprofilen på en skjerm, jeg tråkker bare inn på baderomsgolvet, er det varmt, så vet jeg at strømmen akkurat har vært billig og snart er dyr

Jeg lager det den dagen jeg kan spare mer enn ett øre dagen på det. Men først må effekttariff vedtas og komme, jeg har gitt opp å vente på det.

Takker for omtale som 100% løsning! Ser fortsatt noen bugs som er tunge å rette opp i, men det kommer kanskje. Det er klart det vil kreve kunnskap å ta dette i bruk hos andre. Jeg har tenkt mye på hvordan jeg skulle gjøre dette enklere (på lite viktige rom som garasje og "verksted" mellom garasje og hus har jeg en slik enkel løsning som gjør at termostaten bare er aktiv de 5 billigste timene i døgnet f.eks), men ikke klart å finne noen enkle triks som jeg anser som gode nok (og kanskje også som utfordrende nok, her er det snev av akademiske øvelser) Med fare for å bli mer opphengt i kronene enn kompleksiteten: Hvis min løsning er 100%, så betyr det at det var maksimalt 36 kr å spare (hos meg) i går. Hvor mange kr hadde en enklere algoritme klart å spare, uten å gå på bekostning av komfort? (tør jeg gjette på at din 90% løsning ikke klarer spare 32.4 kr?)

Jeg tenker at et badegulv må tåle å oscillere mellom 20 og si 33 grader, det får være innenfor (men makstemperatur er en separat innstilling hos meg pr. kurs). For parketten hos meg har oscilleringene skapt av luftsensor på Heatit vært mye verre (men dette jeg ha fikset med mye mindre programmering, det er bare å skaffe seg en ekstra sensor som jeg nå har gjort)

Noen lenker til kildekode (GPLv3), det kan hende det er gjenbrukbart for noen med Python-kunnskaper, men tut og kjør er det neppe.. Kjøres hvert 10. minutt og optimaliserer hvert av gulvene mine, og setter ny termostatverdi: https://github.com/berland/pyrotun/blob/master/pyrotun/floors.py Estimat av besparelse: https://github.com/berland/pyrotun/blob/master/pyrotun/poweranalysis.py#L41 CSV-fil med "normal" forbruksprofil: https://github.com/berland/pyrotun/blob/master/pyrotun/daypowerprofile.csv

Dette er Heatit Z-THRM1, som jeg styrer som termostater (ikke som effektregulator). Noen av varmekabelkursene mangler gulvføler, og Heat-it på luftsensor fungerer egentlig ekstremt dårlig. Det jeg da har gjort er å kjøpe flere Ruuvi-sensorer (https://www.hjemmeautomasjon.no/forums/topic/5829-ruuvi/) som jeg har lagt direkte på gulvet med noe isolasjon over seg (under seng/skap etc) og bruker dette som gulvsensor i stedet. Python-koden sender da f.eks 30 grader til termostaten hvis den skal på, og 10 grader hvis den skal være av, basert på gulvsensoren. Bonus for dette er at jeg for første gang har kontroll på parkett-temperaturen på noen kjellergulv. Med luft-sensoren har den sikkert vært langt over 30 grader av og til.

For kjellergulv så vil det medføre noe større varmetap å gå høyere enn ønsketemperatur. Hvis gulvet ikke er isolert, vil man se dette på at gulvtemperaturen faller mye raskere når temperaturen er høy (ikke-lineært). Jeg vet ikke hvor mange cm isopor jeg har under kjelleren (gammelt hus), men jeg konstaterer at temperaturene mine faller linært nok til at dette ikke bekymrer meg. Det er åpenbart at varmetapet fra gulv til lufta over er mye større, og det er hensikten. Jeg har også sett på temperaturprofilen til et bad i 1. etasje (kjeller under), og det faller like raskt som et kjellergulv, altså er det temperaturtap til luft som er hovedfaktoren. Hele huset derimot har høyere varmetap når huset er varmere, dette ligger på 160W pr grad for differanse ute vs inne hos meg. Men det er varmetap gjennom vegger og tak, og jeg har ikke signifikant høyere lufttemperatur pga. de varme gulvene (men masse ekstra WAF for kjempevarmt gulv på badet kl 07:00).

Jeg fant en døgnprofil på https://www.ssb.no/a/publikasjoner/pdf/oa_200806/ericson.pdf og bruker den bare til å gjette på når jeg hadde brukt strøm om jeg ikke hadde hatt noe smartstyring. Jeg tar da samme antall KWh som jeg bruker, og fordeler de utover døgnet i henhold til den profilen, og regnet ut hva jeg hadde betalt da i døgnpris på strømmen.

Koden lager prediksjoner pr. rom, da målinger viser at det er stor forskjell på hvor fort enkeltgulv varmes opp og hvor fort de kjøles ned. Oppvarmingsraten er stort sett bare watt og hvor stor termisk masse det er snakk om (betong vs parkett), nedkjølingsraten skulle vært ganske ikke-lineær, men ser lineær nok ut til at dette er en ok approksimasjon. Nedkjølingsraten sier også noe om hvor mye isolasjon kjellergulv har, og dette har overrasket meg, jeg har trodd kjellergulvene mine var betydelig dårligere isolert. Eksempel fra et lite kjellergulv med fliser, her gjettes det på at det skal holde hele morgendagen med oppvarming fra ca. 03:00 Eksempel på et parkettgulv som ikke får lov å gå høyt i temperatur:

Mange kvelder har gått med til å lage ny styring av husets varmekabler, resultatet kaster endelig av seg med vestlandets store variasjoner i strømpris: Jeg har funnet en typisk strømprofil for norske forbrukere og regnet ut hva min strømkostnad er versus denne, og besparelsen for de to døgnene som vises i plottet er 15 kr og 40 kr. Styringen jeg har for varmekabler er omtrent samme kode som for varmtvannstanken, en Dijstra shortest-path gjennom tid-termostattemperatur-rommet, og der koden gjør approksimasjonen at temperaturen går opp eller ned med fast rate pr. time (tilpasset pr. gulv fra målte data)

Min 200-liters varmtvannsbereder sparer ca 1.50 kr i døgnet på optimal styring (Dijkstras shortest-path for å finne optimal planlegging framover i tid) med dagens strømspriser (Bergen). 4 personer i husstanden.

Jeg er bare på vei over til OH3, har det kjørende på en test-server. Tenkte først å gi etter for "GUI-presset" og ha i det minste den semantiske modellen definert i GUI, men ga opp det også, det ble tekstfiler på alt etter å ha funnet en glimrende guide på forumet https://community.openhab.org/t/oh3-semantic-model-setup-via-tags-in-configuration-items-files/112520

Den ligger allerede på nett ser jeg: https://gist.github.com/berland/ec762e4c555a167953829aece46ec4a3

Jeg har Python-kode som fungerer som bro mellom mqtt og Powerview hub. Interessert? Det er et hack skrevet for den ene gardina jeg har.

Liten oppdatering for OpenHAB-interesserte. OH3 støtter ikke lenger http-bindingen fra OH1, så metoden over virker ikke der. For OH3 http binding gjør man slik (dette krevde mye fikling): Thing http:url:yrmjolfjell "MjølfjellYrAPI" [baseURL="https://frost.met.no/observations", refresh="3600", username="", username="edxxxxx8-9xx8-4xxb-8fxxa-xxxxxxxxxx", password=""] { Channels: Type number : snodybde "Snødybde" [stateExtension="v0.jsonld?sources=SN51800&referencetime=latest&elements=surface_snow_thickness", mode="READONLY", stateTransformation="JSONPATH:$.data[0].observations[0].value"] Type number : temperatur "Temperatur" [stateExtension="v0.jsonld?sources=SN51800&referencetime=latest&elements=air_temperature", mode="READONLY", stateTransformation="JSONPATH:$.data[0].observations[0].value"] } og Items som refererer til kanalene: Number SnodybdeMjolfjell "Snødybde Mjølfjell" (gYr, gResetExpire) {channel="http:url:yrmjolfjell:snodybde", expire="48h"} Number TemperaturMjolfjell "Temperatur Mjølfjell" (gYr,gResetExpire) {channel="http:url:yrmjolfjell:temperatur", expire="48h"}

Knall! Dette signalet går da ikke via en Hue bridge? Hos meg må OpenHAB polle min Hue bridge, default to ganger i sekunder, for å spørre om noen detektorer er utløst, og da er vel nesten snøen nede. (På samme måte som man er ferdig på do når z-wave sensoren og z-wave lyset reagerer på en annen tidsskala)

Tape eller 3D-printet plast, det bør gjøres på en måte slik at det åpenbart for utenforstående at ikke noe annet enn det som er lovlig filmes (nei, det er ikke sikkert at er lett)