OlavT

Du må legge til Multi Channel Associations mellom termostatene og Z-Water. Som det ser ut til at du har gjort, men det ser ut til at du har lagt 31.2 under feil gruppe (3 skriver du). Riktig gruppe skal være 2 Dette er et eksempel fra en termostat hjemme hos meg: Dette sier at når bryteren på termostaten (Switch Set) slås av / på, så skal det sendes en av / på kommando til Z-Wave node 8 og endepunkt 1 (det vi si det første releet i rekken på Z-Water).

80 grader kontra 70 grader gir ca 20% større varmetap. Da går er en del av vinningen opp i spinningen.

Jeg vil anbefale en USB stick fremfor en PI-Hat. En stick er mye mer fleksibel om en skulle trenge å kjøre den på noe annet en Raspberry PI. Jeg bruker for eksempel Silicon Labs ZWave PC Controller på en bærbar maskin for å sjekke ut diverse ZWave funksjoner og da er det greit å kunne plugge stick’en i en PC.

HeatIt -Z-Water er fin til å styre aktuatorer.

Ok, da bruker du over 2x i forhold til meg. NO2 kontra NO1 forklarer nok også mye nå om dagen. Jeg regnet også litt konservativt på besparelsen. Mitt gjennomsnitt kontra gjennomsnittelig strømpris.

Hva er forbruket i kWt per dag ca på det du styrer med Heavy Duty?

Enig i det, lokalt er det jo ofte fysisk kobling som gjelder. Det er jo litt kjipt å være avhengig av for mye utenfor om en ønsker å styre fra egen gateway.

En kobling ut er som regel alltid sikrere enn noe som kan ta i mot koblinger inn.

Skjønner det, men har du regnet på dette basert på hele måneder. Er ikke så ofte der er dramatiske forskjeller.

Hvordan får du spart så mye? Jeg har tegnet med at jeg sparer ca 90-100kr per mnd på å varme vann i billige timer kontra gjennomsnittlig. Har en dårlig isolert OSO EP400 fra 1999.

Det er ofte enklere å lage en klient som er låst til å koble seg opp mot en skytjeneste på en sokker måte enn å lage noe som skal håndtere innkommende requests og være tilstrekkelig sikret.

Trenger ikke temperaturvakt bare du skrur termostaten tilstrekkelig høyt og lar den gå lenge nok (til den slår seg av).

Dette fungerer på tid:

HAN porten sender vel ut data om importert / eksportert strøm, men vil vel bare rapportere evt overskudd av strøm du har produsert med solceller. Det vil si mengden produsert minus det du selv har forbrukt.

Vi regner selvfølgelig strømpris inkludert nettleie og avgifter og kompensert for strømstøtte. Det vil si ca minus 47 øre tidligere i dag for NO1.

Nok en helg der effekt-leddet for nettleien og lave strømpriser trekker i hver sin retning når det gjelder å optimalisere for laveste total-kostnad.

Docker gjør det meget enkelt å kjøre noe hvor som helst uten å installere noe annet enn OS + Docker. Det gjør det mye enklere og raskere å sette opp en ny Raspberry PI om en for eksempel du trenger å bytte MicroSD kortet eller trenger å bytte annen hw, eller å installere igjen fra bunnen. Dersom alt er installert på Raspberry PI er du også sårbar ved oppgradering av software komponenter om noe går galt. Da har en kanskje flere timer foran seg med re-installasjon av alle komponenter.

I dag var sannsynlig en dag der effekt-leddet i nettleien ødela for god utnyttelse av billig strøm. Tipper at nettet i dag helt fint hadde tålt mer samtidig effekt da dette er en lørdag midt i ferien. Lite smart modell for nettleie vil jeg si.

Mulig det er avhengig av versjon på sw i bilen. Min 2016 S70D har ikke det valget.

Standard Tesla-app kan ikke sette ladestrømmen. Må gjøres i bilen. Tesla-API har sikkert denne muligheten.

Ok, usikker på hvor stor forskjell det blir i praksis. Sensoren for luft-temperaturen i en termostat vil klart trigge ved åpen dør og sette på varmen til setpoint-temperaturen er nådd og så slå av varmen til temperaturen igjen faller. En regulator vil slå av / på for å oppnå x% effekt. Hva som blir forskjellen i oppførsel / strømforbruk / comfort med disse to måtene å regulere på er jeg ikke sikker på.

Hva er fordelen med en regulator i forhod til en termostat i dette tilfellet?

Ja, det gir mening.

Ja! Oppdaterte akkurat posten med disse betraktningene. Slik gjør jeg det i mine egenutviklede scripts (her for varmtvannsbereder): { "if": { "ElectricityConsumptionCouldExceedHourlyLimit": { "thisDevicePowerConsumptionProperty": "WaterHeater.PowerConsumption", "thisDeviceMaxPowerConsumption": 2480 // in Watts }, "then": { "executeCommand": { "deviceGroupId": "ZWave", "deviceId": "6", "capabilityId": "SwitchBinary.000", "commandId": "SwitchOff" } } } } Bak dette ligger denne settingen:

La oss anta at det ser slik ut som i tabellen og grensen er 5.0kWh. Hvorfor skulle du ønske å styre etter 2.97kWh? Du kan jo i dette tilfellet styre etter 6.93kWh. Ulempen med å styre etter 6.93kWh i dette ilfellet er at en i neste omgang må styre etter laveste (3.76kWh) og det kan bli vanskelig. Dersom gjennomsnittet allerede er 5.0kWh eller større, så gjelder logikken din. Jeg vil nok konsentrert meg om å styre etter 5.0kWh hele tiden. Kunne kansje vært fristende å "bruke opp" kvoten ved å gå over på slutten av perioden, men det er nok litt risikosport.