stigvi

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.

Som nevnt, det blir nok sannsynligvis et problem fordi når kjøledelen slutter å kjøle så vil frysedelen også slutte. Det er normalt at kun kjøledelen har termostat og så er det et luftespjeld mellom frysedel og kjøledel som angir forholdet i temperatur mellom de to. Men alt baserer seg på at kjøleskap står i romtemperatur og at kompressor går i sine faste intervaller.

Men gassen må jo fordampe ved en lavere temperatur enn det frysedelen er ment å fryse ned til. R600a koker ved -11,7 ved 1 atm trykk. I skapet er trykket lavere enn dette for å få et lavere kokepunkt.

Hvor har du det fra at et slikt skap ikke tåler lavere temperatur? Kondensator på baksiden skal jo kvitte seg med varme og sånn sett er det gunstig med et kaldt rom. Det som kan bli et problem er hvis du forventer -20 i frysedelen og skapet kun har termostat i kjøledelen og en enkel kompressor. Blir det kaldt i rommet så vil kjøledelen bli mindre og mindre brukt og det får frysedelen til å øke i temperatur. Men har ikke hørt noe om at selve skapet tar skade av det.

Ja, nå er det kun 2 dager igjen til den 14. desember. De estimerte strøm til 5200 kroner for meg som er i NO2 sonen og så langt er jeg på 4700 kroner. Ser ut som om estimatet stemte veldig bra. Hva med dine 7000?