Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

RVM

Medlemmer
  • Innlegg

    174
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    4

Innlegg skrevet av RVM

  1. 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!😬

  2. 37 minutes ago, stigvi said:

    Det enkleste og sannsynligvis billigste er nok å kjøpe en superbillig trådløs aksesspunkt og sette den opp i nærheten av skapet. Det finnes esp32 noder med nettverkstilkobling, men da må du sitte inne med kunnskaper om å lodde og koble deler sammen på egenhånd.

     

    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.

  3. 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) }}

  4. 2 minutes ago, stigvi said:


    Har vurdert det samme. Og å lage det slik at prisene for hvor time enten hentes fra Nordpool integrasjon eller Entsoe-e integrasjon, avhengig av tilgjengelighet på priser. Da får jeg to kilder som jeg varierer på, alt ettersom.

    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.

  5. 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.

  6. +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.

    • Thanks 1
  7. 8 hours ago, TurboJens said:

    Så, varmtvannsbereder er egentlig det einaste eg treng å styre for å klare detta men den er på 2800w så når den slår inn får eg stoore utslag på "estimert strømforbruk denne time" når det typisk ligge på rundt 300w og så kjem det ei last på 2800w oppå. Driftstida til vvtanken er berre på ca 10min når den skal kompensere for varmetapet så det utgjere ikkje så mykje, men når ungane skal bade ex. går det jo litt ekstra krutt.

     

    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.

  8. 8 minutes ago, hjemmedude said:

    Justerte effektledd til 5kwh i mai, men i følge nettleie så har jeg 3 dager med 5,6 og nedover i forbruk. 
    Har ikke endret på noe spesielt og HA rapporterer ca 4,8 kwh forbruk på de timene BKK melder 5,6.

    Hvor begynner man feilsøke dette mon tro? 

     

    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.

  9. 1 hour ago, SveinHa said:

    Det er vel ikke særlig vanlig her på berget med så store veggbokser som den på illustrasjonen...

     

    Jeg ville vel mistenkt at den store boksen er brukt for ansvarsfraskrivelse, putter du Aquaraen inn i en mindre boks har du ikke fulgt bruksanvisningen og har deg selv å takke for evt. problemer.

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

  10. 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:

     

    image.png.fc2606a14aa1221c7eb0113ea358ec73.png

     

    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å:

     

    image.png.fb84303c415d9bed0503d5a43212c9b0.png

    • Like 2
  11. On 05/03/2023 at 10:25, OlavT said:

    Så innfører en en ny modell for nettleie som til en stor grad motarbeider dette ved å gjøre det dyrere å forbruke mer effekt uansett om dette skjer i de få timene nettet faktisk er hardt belastet eller ikke.

     

    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.

    • Like 1
  12. 12 minutes ago, Sickel said:

    Det er relativt standard at måleinstrumenter viser micro eller nano Sv/h. Det tallet må tolkes som potensiell helkroppsdose for en person som er der instrumentet er, men ja, for et GM-rør blir dette et guesstimate med en god del forutsetninger, blant annet så er det vanlig å regne ut fra at all strålingen som registreres er gammastråling fra 137-Cs.

    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...

  13. 6 minutes ago, Sickel said:

    Når du sier Bq/m3, regner jeg med at du tenker på radon.

     

    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.

  14. 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.

     

    12 hours ago, fred said:

    Det finnes konverteringsfaktorer til mikrosivert/time som faktisk gir deg et tall på strålingsdose, for sbm-20 er disse hhv 0.00664  for Cobolt 60 (60Co), 0.00584 for a Cesium 137 (137Cs), og 0.00507 for the Radon (226Ra), men det krever som sagt at du vet hvilken isotop det dreier seg om. Så i bunn og grunn gir denne deg ikke noen annen informasjon enn at det finnes en radioaktiv kilde i nærheten.

    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?

  15. 1 hour ago, fred said:

    Hardware:

    • Dedikert pc bygd i 4u kabinett som kjører ubuntu Server
    • Zigbee stick SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P

    Software:

    • Docker med 18 containere. I forhold til hjemmeautomasjon kjører jeg
      - Homeassistant
      - Mariadb
      - Influxdb
      - Node red
      - Grafana

    Backup... her er jeg alt for dårlig...!

    • Github backup av alt av composefiler og config.
    • manuell backup av databaser til nas, dette burde være automatisert men jeg er lat

     

     

    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.

  16. 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"?

     

    4 hours ago, OlavT said:

    Jeg ville ha logget nøkkelverdier som algoritmen beregner beslutningene ut fra og tatt en titt på disse.

     

    Enig, det ville vært min innfallsvinkel også.

  17. Kardemomme skrev (3 minutter siden):

    Jeg trodde strøm støtten var 90% av kosten over 70 øre.

    Altså: (1,42-0,70)x0,90=0,65

     

     Noen som kan gi en forklaring på hvordan en skal regne ut strøm støtten fra gjenomsnitts pris

     

    Du må regne med mva. på de 70 ørene.

    Altså: (1,42-0,70*1,25)x0,90=0,4905

    • Like 1
  18. stigvi skrev (14 minutter siden):

    Jeg kjører Home Assistant på en Rbpi 4 og la til zigbee2mqtt som en addon. Mqtt (mosquitto broker) er også en addon.

    Og zigbee2mqtt fungerer ekstra godt sammen med Home Assistant i og med at de bruker systemet for "auto discovery". 

    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.

  19. Gunnar-K skrev (19 minutter siden):

     

    Jeg er også interessert i å få til en sensor som kan estimere strømstøtten etter som dagene går, og som gir riktig resultat  siste dag i måneden når gjennomsnittsprisen er kjent.

    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.

     

    image.png.efbd8ea21f3226148ed2dc572f974290.png

    • Like 2
    • Thanks 1
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.