stigvi

Glemte å nevne at en annen svakhet med Xiaomi er at de fungerer mindre bra hvis det er noen routere i zigbee-nettet som faller ut. Det kan feks være en lyspære som får strømmen brudt. Da kan Xiaomi sensorene bruke dager/uker på å finne en ny rute å sende dataene sine på. Hjemme hos meg har jeg ikke dette problemet da alt står koblet til strøm hele tiden og det er null endringer i zigbee topologien. En annen svakhet er at Xiaomi sine sensorer ikke er 100% zigbee kompatible og det finnes enheter som rett og slett nekter å rute meldinger videre. Samsung sin stikkontakt-bryter er et eksempel. Jeg har en slik, men den står i borteste hjørnet i garasjen så den fungerer neppe som noen ruter for noe som helst. Men den kan potensielt være ødeleggende for mine temperatursensorer, spesielt den som er i garasjen.

Jeg har 8 stk temperatur og fuktighetfølere av den runde gamle typen til Xiaomi / Aqara, 3 stk av den nyere firkantet type. Og så har jeg 16 stk dør / vindu sensor av den nyere firkantet typen og 5 stk av den eldre typen med runde kortender, fra Xiaomi / Aqara. Og til slutt 3 stk bevegelsesensorer. Alle samme fungerer stort sett veldig bra og det har de gjort i mange år, først med deconz og nå med zigbee2mqtt. Men noen svakheter har de. CR2032 batteriet konker ut når det blir for kaldt så den som ligger i fryseren har fått påloddet to AA batterier. Av og til registrerer ikke dørsensorene at døren er lukket før den henter seg inn en time etterpå, skjer 3-4 ganger i året på hoveddør så det er ikke ofte. Bevegelsesensorene sender kun lysstyrke samtidig med bevegelse. Så jeg kan ikke bruke de til å slå av lys når det lysner om morgenen. De 3 bevegelsesensorene skal jeg bytte ut nå i julen med 3 Philips Hue bevegelse sensorer, kun for å få rapportert lysstyrke kontinuerlig. Jeg har ingen planer om å bytte ut det andre, men allikevel har jeg kikket litt på alternativer. I tilfelle noe slutter å virke og det må erstattes. Ser at Frient / Develco sine sensorer har noen gode egenskaper. De bruker AA og AAA batterier og dørsensoren er oppgitt til 9 år levetid. Temperatursensor til 5 år med rapportering hvert 5. minutt. Minus er at de er større. Men spørsmålet: Er det noen som har gode sensorer for temperatur, fuktighet, dør og vindu som de kan anbefale. Viktigste kriterie er at de skal fungere nærmest problemfritt sammen med zigbee2mqtt

Hvis du er godt innenfor så er den på 100%, ja

Det er jo opplagt - ha farget lys.

node.warn(kWh_part - 45000000) Dette setter jo ikke kWh_part til en ny verdi og du vil derfor ikke se hva som skjer. Her setter du en parameter til funksjonen warn og den har nok en annen datatype enn det kWh_part har. Ta heller å skriv ut kWh_part i koden din og se hva det er der. Eller sett kWh_part til en int32 og se om feilen forsvinner

Men her er det context.get("kWh_part") sin returverdi som bestemmer datatypen. Javascript har noen merkelig funksjonalitet ang datatyper og jeg er på gyngende grunn her. Kjenner ikke javascript godt nok. Men her må du se på sannsynlige årsaker. Javascript roter ikke med noe så enkelt som kWh_acc = kWh_acc + 0.01; Det nekter jeg å tro på.

Det vesentlig er om den er unsigned. Da feiler det hvis du gjør 23000000 - 36000000

Vet du hvor mange ganger den går gjennom sløyfen? Hva om kwh_part er "unsigned int" og når du trekker fra 36000000 så kan kwh_part ende opp med å få en veldig stor verdi. Kanskje. Men hvorfor har du en sløyfe der i det hele tatt? Kan du ikke bare regne ut kwh_acc og kwh_part?

Tibber gir meg disse to tallene.... For meg betyr denne forskjellen ca 500 kroner så langt i desember

Men OlavT sitt poeng er kanskje: Du får 5000 kroner i støtte. Hvis du kun bruker den aller billgste strømmen så betaler du 6000 for den og reell utgift har vært 1000 kroner. Hvis strømmen varierer en 2-gang i pris og du kun bruker den dyreste så betaler du 12000. Og ender opp med å betale 7000 etter støtte. Da, etter støtte, er variasjonen 7 ganger.

Tja, hvorfor det? Jeg ser poenget ditt, men jeg ser at det går fint å tenke på en annen måte også, at støtten er en helt uavhengig kontantstøtte. Og det er ikke helt feil i og med at støtten ikke er relatert til variasjonen i pris time for time og at total strømforbruk i en måned er gitt med lite slingringsmonn. Det jeg prøver å få fram - du klarer ikke å få regningen for strømmen til å endre seg en 10-gang. Du klarer å påvirke den innenfor den faktiske strømprisen sin variasjon.

Tibber tar grep etter fakturasjokket: – Ingen skal fungere som bank for Tibber - Tu.no

Min kurve for timeforbruk ser ut som dette. Jeg har satt 10kWh/h som grense pga nettleie. Hadde 5kWh/h som grense i november og det gikk såvidt. Varighetskurven som jeg finner på "minside" hos netteier, ser slik ut for desember For november var den slik med en lang og flat topp. Det er en del timer der jeg lå helt oppunder 5kWh

Mange oppgir som grunn at de ikke vil gi Tibber kreditt og det er greit nok. Noen skriver at regningen som kom for Desember ble et sjokk. Til de kan en vel opplyse at sjokket kommer uansett hvilken leverandør en bruker. Strømmen er dyr for øyeblikket.

Det er jo en god start (du tenker da på direkte assosiering?) Hvorfor var det kaldt i dag hvis termostatene kan åpne ventilene direkte uten at HS kjører?

Slik er jo synd, men det er jo egentlig forventet. Alle slik systemer vil før eller siden (helst før) stoppe opp. Det lureste en kan gjøre er å sørge for en plan B, at varme og lys fungerer uten at systemet på topp er i drift.

Ok, min feil. Jeg trodde du brukte denne: gskjold/AmsToMqttBridge: ESP8266 and ESP32 compatible firmware to read, interpret and publish data to MQTT from AMS electrical meters, both DLMS and DSMR is supported (github.com)

Har du tatt med en sensor med state_topic som dette? state_topic: "power/realtime/import/hour"

Den har det, altså forbruk i inneværende time.

TP-Link Tapo C320WS WiFi utendørs sikkerhetskamera - Elkjøp (elkjop.no) Funker veldig bra. Har det du etterspør. Integrerer fint i Home Assistant, som jeg har Edit: Lagrer ikke på egen server, men på et minnekort i kamera.

Jeg har lagt til et truncate filter. HA kan ikke ha en tilstandsverdi som er lenger enn 255 tegn. Men attributter kan være lenger. Spørsmålet da er hvordan en henter denne teksten inn i en attributt? Men som en midlertidig fix blir teksten begrenset i lengde - platform: rest resource: https://api.met.no/weatherapi/textforecast/2.0/?forecast=landoverview name: textweather scan_interval: 3612 value_template: '{{ (value_json.textforecast.time[0].forecasttype.location|selectattr("@id", "eq", "0611")|first)["#text"]|truncate(254,True) }}'

Det skulle være grei skuring. Hva er det du har nå?

Jeg mener det ikke spiller noen rolle. At anbefalingene om ikke for lav temperatur der et kombiskap står, dreier seg om andre ting enn det du mener. Du har ennå ikke funnet noe som sier at skapet blir ødelagt hvis temperaturen kommer under X grader?

-12 er alt for varmt. Du bør ikke ha det varmere enn -18.

Men du får ikke strømstøtten tidligere hvis du hadde valgt en leverandør med gjennomfakturering. Sånn sett er det lite relevant å ta det med.