RVM

Jeg har internett fra Altibox (Lyse), og har fått melding om at de skal legge om fra IPv4 til IPv6 hos meg i natt. De påstår at "utover nedetiden, vil dette sannsynligvis ikke påvirke deg", men jeg har mine tvil. Jeg har hjemmesentralen i bromodus og noen Asus mesh-routere som jeg administrerer selv, og tenkte jeg skulle være forberedt og få litt hjelp av kundeservice til hvordan IPv6 må settes opp i min Asus-router. Det eneste de kunne foreslå var å resette routeren hvis det blei problemer. De kunne ikke svare på om jeg skulle bruke f.eks. native IPv6 eller Tunnel 6rd etter omleggingen, og jeg kan alt for lite om nettverk (i alle fall om IPv6 - kan akkurat nok om IPv4 og subnetting til å være farlig) til å kunne ha en formening selv. Er det noen som har fått lagt om fra IPv4 til IPv6 fra Altibox nylig, og kan dele litt om hva jeg må gjøre i morgen tidlig? Hvordan påvirker det f.eks. Nabu Casa, OpenVPN, POW-U AMS-leser, Synology NAS, Linux servere (Proxmox/Debian), IOT-gatewayer (Gardena, Systemair, Eufy), lokale statiske IPv4-adresser osv. osv.? Jeg gruer meg allerede til i morgen tidlig - grøss!😬

Jeg har også litt skranten wifi-forbindelse ved AMS-måleren, som står inni et faraday-bur av et inntaksskap. Jeg endte opp med å trekke en ethernet-kabel mellom HAN-porten og lavspentskapet til routeren etter noen måneder med ergrelse, sånn at POW-U AMS-leseren kunne stå der det er godt signal. Jeg var "heldig" og hadde allerede ha et ledig trekkerør i veggen som jeg kunne bruke, men trådstarter snakker jo om å bruke LAN, så da har han/hun vel mulighet til å kable.

Uten at jeg har testa det sjøl, ville jeg ha prøvd å lage en template sensor som gir 650 W hvis "heating" fra Heatit, og så bruke en Helper->"Integration - Riemann sum integral" av template sensoren, og muligens en Helper->"Utility Meter" med integralet som input. Da tipper jeg du er langt på vei. Edit, template sensoren blir vel noe sånt: {{ iif(states('climate.entrance_floor')=='heat', 650, 0) }}

Du har kanskje noe dokumentasjon på skjult varme i Boligmappa? Hos meg finner jeg f.eks.: ...som stemmer ganske bra med effekten som Heatit-termostaten måler: I så fall kan du jo integrere dokumentert effekt over tiden den rapporterer "heating".

Og RSS-feeds til NRKs podcaster finner man her: https://sindrel.github.io/nrk-pod-feeds/

Litt av poenget med å gjøre det akkurat sånn for meg, var at jeg da slapp å endre så mye på logikk som bruker raw_today/raw_tomorrow andre steder, siden jeg har samme format for raw_today/raw_tomorrow i min nettopris.

Jeg har nylig gått over til å la Nordpool-integrasjonen kun ta seg av spotprisen, og så lar jeg andre entities holde på nettleie og strømstøtte hver for seg, før jeg summerer opp en netto strømpris. Synes sjøl at det var ryddigst og enklest, men det blir jo subjektivt. Gjør dette ved å "speile" raw_today og raw_tomorrow fra Nordpool til nye Pyscript-variabler, slik at de er på samme format som Nordpool-entity'en. Nettleie: # ... YEAR = datetime.today().year NOR_HOLIDAYS = holidays.NO(years=[YEAR, YEAR+1, YEAR+2]) @time_trigger @state_trigger("sensor.nordpool_kwh_krsand_nok_3_10_025") def calculate_grid_tariff(): now = datetime.now(tz=tz) pyscript.electricity_grid_tariff = PEAK_RATE if is_peak(now) else OFFPEAK_RATE pyscript.electricity_grid_tariff.raw_today = sensor.nordpool_kwh_krsand_nok_3_10_025.raw_today.copy() pyscript.electricity_grid_tariff.raw_tomorrow = sensor.nordpool_kwh_krsand_nok_3_10_025.raw_tomorrow.copy() for rt in pyscript.electricity_grid_tariff.raw_today: rt['grid_tariff'] = PEAK_RATE if is_peak(rt['start']) else OFFPEAK_RATE for rt in pyscript.electricity_grid_tariff.raw_tomorrow: rt['grid_tariff'] = PEAK_RATE if is_peak(rt['start']) else OFFPEAK_RATE def is_peak(t): is_holiday = t.date() in NOR_HOLIDAYS is_weekend = t.isoweekday() >= 6 is_night = t.hour <= 5 or t.hour >= 22 if is_holiday or is_weekend or is_night: return False else: return True Strømstøtte: # ... @time_trigger @state_trigger("sensor.nordpool_kwh_krsand_nok_3_10_025") def calculate_subsidy(): now = datetime.now(tz=tz) spot = float(sensor.nordpool_kwh_krsand_nok_3_10_025) pyscript.electricity_subsidy = get_subsidy(spot) pyscript.electricity_subsidy.raw_today = sensor.nordpool_kwh_krsand_nok_3_10_025.raw_today.copy() pyscript.electricity_subsidy.raw_tomorrow = sensor.nordpool_kwh_krsand_nok_3_10_025.raw_tomorrow.copy() for rt in pyscript.electricity_subsidy.raw_today: rt['subsidy'] = get_subsidy(rt['value']) for rt in pyscript.electricity_subsidy.raw_tomorrow: rt['subsidy'] = get_subsidy(rt['value']) def get_subsidy(spot_price): subsidy = max((spot_price - SUBSIDY_THRESHOLD)*SUBSIDY_LEVEL, 0) return round(subsidy, 4) Så er det bare å iterere gjennom raw_today/raw_tomorrow og summere opp nettoprisen per time.

Stemmer, for min del er det kun snakk om harddisk-plassen, inklusive backupene.

+1 for InfluxDB. Jeg mater alle aktuelle sanntidsdata inn i InfluxDB fra Home Assistant, og gjør Flux queries i Python i Home Assistant. Skal ikke påstå at jeg er spesielt dreven med Flux, så jeg prøver og feiler til jeg finner noe som funker som det skal. Her er et eksempel på hvordan jeg henter ut peak forbruk i inneværende døgn: peak_consumption_today_query= f''' import "timezone" option location = timezone.location(name: "Europe/Oslo") from(bucket: "home_assistant") |> range(start:{start_string}, stop: now()) |> filter(fn: (r) => r["_measurement"] == "pyscript.electricity_current_hour_consumption") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: 1h, fn: max, createEmpty: false) |> max() |> yield(name: "peak_consumption_today") ''' Ulempen er selvfølgelig at det kan bli mye data i InfluxDB. Jeg har 3 måneder retention på "hoveddatabasen", og så har jeg en Task som downsampler de mest interessante dataene til en annen database med uendelig retention policy for langtidslagring.

Du kan jo f.eks. velge å bare slå av VVB etter 40 minutter inn i timen, på det tidspunktet er VVB sitt "bidrag" i ekstrapolasjonen (antatt videre forbruk i resten av timen) bare på 2.8kW*20min = 1 kWh, og hvis det øvrige forbruket ditt ligger nokså flatt på 300-500 watt vil du som regel være godt innafor 2 kWh på estimert forbruk. Du kan også trekke ut hele VVB-effekten fra boligens sanntidseffekt mens VVB er aktiv før du ekstrapolerer, og så lage deg en slags modell for hvor mye VVB forbruker i en aktiv time. Hvis den som regel bare er aktiv i 10 minutter om gangen som du sier, kan du legge på 2.8kW*10min = 0.47kWh i estimatet, evt. med en god sikkerhetsfaktor. Hvis du er redd for å slite ut releet, kan du legge på en forsinkelse slik at den bare skrur seg på igjen etter x minutter etter å ha blitt slått av. Da slår den i alle fall ikke ut og inn hele tida.

Hvis det fortsatt er en POW-U fra AMS-leser du har, ville jeg sjekket om den rebooter i blant (f.eks. pga lav spenning). Da resettes timesforbruket på 0 kWh igjen, dvs. at den rapporterer feil forbruk. Jeg opplevde det med min, og måtte massere måledataene litt før jeg flyttet den innendørs til bedre WiFi-dekning.

Jeg har alle mine smartdimmere (riktignok ingen fra Aqara) inni Elko BigBox, håper de er store nok 😬

Trakk en cat6-kabel mellom det utvendige inntaksskapet til nettverksskapet inne før helga, for å få bedre sendeforhold for AMS-leseren som tidligere var inne i et Faraday-bur. Sleit med at den rebootet et par ganger i måneden når sendestyrken og/eller spenningen ble for lav. Hadde heldigvis et ledig trekkerør allerede. Med AMS-leseren (POW-U) innendørs er signalstyrken mye bedre og forsyningsspenningen på POW-U rimelig stabil, selv om den fortsatt er matet fra HAN-porten. Skiftet er ved 3. mars ca. 18:00: Slik måtte jeg massere inndataene (f.eks. timeforbruk) tidligere gjennom et Python-script for å ta høyde for kræsj, men det kan jeg heldigvis fjerne nå:

Synes gapet mellom dagpris og natt-/helgepris på nettleia er nokså smalt, bare 8 øre/kWh i forskjell hos mitt lokale nettselskap. Kunne godt hatt et skikkelig skille, slik at det ble mer gunstig å flytte høyere effekt til utenfor rushtida.

PM sendt.

Takk for korrigering! Angående ekvivalent/effektiv dose avhenger det sikkert av om dosen er utenfra eller inntatt også? Mener å huske skoleeksempelet med at strontium tas opp av skjelettet fordi det ligner sånn på kalsium, og det må vel påvirke f.eks. beinmargen i større grad enn andre organer? Men ja, det har jo ingenting med GM-rør å gjøre...

Jeg kan bare svare for meg selv, men for meg er radon fra grunnen helt uinteressant. Bor i et moderne hus med radonsperre, balansert ventilasjon, og ingen oppholdsrom i sokkeletasjen. Ville vært mye mer interessert i fange opp variasjoner i atmosfærisk- og bakgrunnstråling, bare for nysgjerrighetens skyld.

Kjempespennende prosjekt! Jeg hadde et kjernefysikk-fag på universitet for en 12-13 år siden, og vi var litt innom dosimetri og laboratorieoppgaver med Cs137-prøver fra Nord-Trøndelag datert 1986. Skal notere meg prosjektet ditt bak øret og forhåpentligvis hive meg på en gang jeg får tid. Det er jo dette som er så vanskelig med dosimetrien såvidt jeg husker. Ville ikke brydd meg så mye med konverteringsfaktorene til Sv/h tror jeg, man har vel liten forutsetning for å vite hva ekvivalent dose eller effektiv dose i de ulike organene er (beinmarg har f.eks høyere vektingsfaktor enn hud for effektiv dose). Absorbert dose i Gy/h eller R hadde kanskje vært et bedre mål, men fortsatt nokså upresist med en geigerteller vil jeg tro. Som du er inne på tror jeg du bare får et relativt mål på om radioaktiviteten nær deg går opp eller ned. Kan man estimere Bq/m³ fra CPM?

Høres ut som vi har omtrent samme oppsett. Jeg kunne også vært bedre på backup, men har valgt en lettvint løsning med å ha en cronjob som zipper opp hele /home/ (dvs. alt av filer til docker containere) i Ubuntu Server ved midnatt og syncer til NAS med rullende backup for siste 14 dager. Ikke så sofistikert kanskje, men det funker.

Støtter forslaget om å bruke Nabu Casa, det bidrar også til utviklingen av HA. Disse innloggingsforsøkene som feiler, er det tilfeldigvis 127.0.0.1 eller intern IP (192.168.x.x e.l.)?

Jeg bruker også Vibb uten Vibb+, og da ser det sånn ut:

Fine script på githuben din, tror jeg kommer til å låne litt derfra! Ville begynt med å utelukke opplagte feil i beregningen. Se f.eks. på grafen idet du bikker midnatt. Estimert forbruk begynner på >5 kWh rett etter midnatt, selv om laderen har vært av i mer enn 15 minutter (hele bidraget må altså komme fra øvrig forbruk siste 15 min?). Likevel beregner du at current kan settes til 32 A (ca. 7.3 kWh), selv om du har 10 kWh som terskelverdi? Hva dekker f.eks. "sensor.garasje_power"? Enig, det ville vært min innfallsvinkel også.

Du må regne med mva. på de 70 ørene. Altså: (1,42-0,70*1,25)x0,90=0,4905

Skyter inn fra sida at for oss som bruker Home Assistant Container og dermed kjører Zigbee2MQTT i en egen docker container, så stiller ikke Home Assistant krav til at Zigbee2MQTT er like up-to-date som f.eks. Zwavejs2MQTT. La merke til at jeg ofte ble hengende noen måneder på etterskudd med oppdateringer av Zigbee2MQTT. Endte nylig opp med å lage et bash script som automatiserer docker stop -> docker rm -> docker rmi -> docker-compose up.

Gjentar det her også: Tror det beste estimatet du kan få til med minst mulig innsats er å benytte deg av denne statistiske modellen for estimert snittpris og strømstøtte. Dataene publiseres automatisk daglig, og du kan hente det inn i HA med f.eks. en REST sensor.