RVM

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.

Ingen kjempegode tips nei, men klarer du å feilsøke hvor problemet oppstår? Forstår jeg det riktig at du får importert pandas, men at det feiler på pd.read_csv fordi den ikke får sendt requesten?

Hvis du vil kalkulere det selv tror jeg du må mellomlagre historiske prisdata for måneden selv, f.eks. ved å bruke Node-Red/Pyscript/InfluxDB e.l. opp mot Home Assistant. Mulig du kan få det til med en trigger-based template sensor også. Eller du kan hente beregnet snittpris og kompensasjon fra Internett ved å bruke f.eks. en REST sensor, som herfra med hjelp av denne.

Har du sjekket i loggen om du får noen feilmeldinger fra Pyscript? Du kan jo også evt. legge inn noen log.info() eller log.error() rundt omkring i koden for å verifisere hva som funker/feiler. Jeg liker å ha en notify til mobilen på alle feilmeldinger fra Pyscript.

Har du prøvd å legge det til i requirements.txt?

Jeg bruker alltid Heat, og justerer ned settpunktet 3 grader når PID/pris/nattsenk dikterer at de ikke skal trekke strøm.

Jeg har vært fornøyd med EasyAccess EasyFingerTouch, som snakker zigbee med en tilleggsmodul inni låsen. Funker strålende i HA via Zigbee2MQTT hos meg. Liker at den har mekanisk nødnøkkel hvis all elektronikk skulle feile. De koster også "bare" 2500 kroner på tilbud (+ zigbee-modul), så hvis du skal ha 3 stk kan det kanskje det være litt å spare sammenlignet med Yale Doorman osv.

Du trenger vel bare en automasjon som kaller service climate.set_temperature? F.eks. noe sånt: service: climate.set_temperature data: temperature: "{{ state_attr('climate.bathroom_floor', 'temperature') - 2 }}" target: device_id: [din device_id]

Tør jeg gjette på at du prøvde å kopiere {{ l }} fra skjermbildet mitt og endte opp med {{ 1 }} istedenfor? 😀 {{ l }} var bare for å vise hva variabelen l inneholdt, men hvis du skriver {{ 1 }} i developer tools får du helt riktig en output som er et number med verdi 1.

Visningen er multiple-entity-row.

Tusen takk for denne (og til han som har laget det)! Jeg kan ingenting om R, men siden han automatisk publiserer csv/json daglig er det lett å hente inn forecast for månedspris og strømstøtte fra modellen hans med f.eks. pandas og pyscript: import pandas as pd @pyscript_compile def read_csv(): # Separate function for blocking I/O, using @pyscript_compile url = "https://raw.githubusercontent.com/martinju/stromstotte/master/data/current_estimated_compensation.csv" try: df = pd.read_csv(url) df = df[df["area"] == "NO2"] # Only look at region NO2 df = df.set_index("type") out = {} out["mean"] = df.loc["mean"]["mean_price"] out["quantile_0.025"] = df.loc["quantile_0.025"]["mean_price"] out["quantile_0.975"] = df.loc["quantile_0.975"]["mean_price"] return out, None except Exception as exc: return None, exc @time_trigger("cron(@daily)") def get_forecast(): result, exception = task.executor(read_csv) if exception: raise exception else: pyscript.forecast_monthly_electricity_price_mean = round(result["mean"], 3) pyscript.forecast_monthly_electricity_price_quantile_0_025 = round(result["quantile_0.025"], 3) pyscript.forecast_monthly_electricity_price_quantile_0_975 = round(result["quantile_0.975"], 3)

Jeg tror de fleste estimerer timesforbruket som estimat = (forbruk så langt denne timen) + sanntidseffekt*(andel av timen som gjenstår). Det kan du lage en template sensor for i HA, f.eks. med verdier fra en AMS-leser som forklart over. Sanntidseffekten kan være grei å sende gjennom et lavpassfilter først sånn at estimatet ikke blir så følsomt for hurtige endringer i effekt, noen laster skrur seg jo hyppig av og på. Filtrerer man derimot "for mye" kan estimatet fort ligge litt på etterskudd, så man må finne en middelvei. Jeg har satt min time_constant til 30, det fungerer godt nok for meg. Estimatet fungerer greit nok, men det er naturligvis ganske unøyaktig i begynnelsen av timen, og blir mer og mer presist etterhvert som estimatet blir mindre sensitivt for ekstrapolert effekt. Hvis lastene er deterministiske (eks. fra oppvaskmaskin med kjent oppvaskprogram) kan man hypotetisk forbedre estimatet med det kjente framtidige forbruket fra eksempelvis oppvaskmaskinen, men det blir fort for komplisert i en template sensor ser jeg for meg, da ville jeg brukt noe sånt som Node-Red eller Pyscript osv.

Avhengig av hvordan du har satt opp configuration.yaml, så kan du ta bort default_config og administrere default-integrasjonene selv, inkludert logbook. For logbook-integrasjonen kan du legge til en exclude avhengig av hva du vil ignorere (f.eks. enten en entity eller et helt domain)

Tror ikke det, jeg bruker den bare til å terminere skjerm i en ende.

Mener å huske den siste var gnd selv om det ikke er merket, men sjekk med multimeteret mot en av de andre jordterminalene.

Det skal være notert ned i igangkjøringsprotokollen du skal ha fått overlevert for aggregatet. Hvis ikke ville jeg begynt med slaveadresse 1, baud 9600, og ingen paritet. Hvis ikke det fungerer ville jeg prøvd andre vanlige baudrater, og så begynt på ny med partalls paritet. Selv om det står at baudrate begynner på 9600 i parameterdokumentet, var 1200 en gyldig baudrate på min VTR300. Kobler du til på A+/B- terminalene? I så fall, kan du ha byttet om på lederne? Eller brukt for lange (uflettede) ledere?