Vinnerliste

Har første utkast på hjemmelaget ssscat klart. Kommer ikke lenger før jeg får delene fra Ebay. Planen er å lage en kjerne av laserkluttet akry og en 3D printet kropp som kjernen kan monteres i. Det er mange antagelser angående dimensjoner så alt må tegnes på nytt når jeg har alle komponentene i hende, men tror dette er en løsning som vil fungere.

Jeg skriver en masteroppgave hvor jeg i høst har forsket på strømdataen jeg har fått fra min smartmåler Kaifa i Bergen og lurer på om noen har litt data å dele fra sin måler. I forskningen min har jeg sett på muligheten for å identifisere og klasssifisere laster i det totale forbrruket, altså dataen tilgjengelig gjennom HAN, slik at jeg kan med XX % sikkerhet si hvilket apparat som var ansvarlig for endingen i totalt forbruk (Nonintrusive load monitoring, NILM). Siden jeg har samlet inn data i Bergen, hvor jeg har vært koblet til et TT-nett, får jeg ikke så gode målinger som jeg tror er tilgjengelig om man er koblet til TN eller IT. På bildene vedlagt ser dere hvordan fasene er lagt opp og hvordan lastene viser seg på to faser i current_phase_1, current_phase_2 og current_phase_3. Det jeg lurer på er om disse induviduelle fasemålingene vil være "renere" hos en AMS som ikke bruker TT-nett. Er det noen som kan dele litt data, evt plots fra de induviduelle fasemålingene hos dere hadde det vært til stor hjelp! phases_and_circuits.pdf 2018-11-05:I1-Current phase 1,2,3 [A].pdf

Se her: https://www.tronika.no/no/104_sunricher

Takk for innspill! Jeg fikk en pm med litt data så jeg tror jeg skal klare meg med det. Ja det stemmer at dette er et spennende felt! Jeg ville ikke tenkt så mye på den skumle biten da dataen kun sendes tilbake til strømleverandør én gang i timen og HAN-porten du kan hente ut data til eget bruk (aktiv effekt hvert 2. sekund, reaktiv og fasespesifisert hvert 10. sekund) er kryptert som standard og som regel kun fysisk tilgjengelig i din egen husholdning/borettslag. Denne var jeg faktisk ikke klar over! Men ja, det er akkurat det jeg kartlegger mulighetene for i Norge. Jeg leverer oppgaven min på tirsdag men kjører fortsatt algoritmene med forskjellige parametre for å se hvor nære jeg kan komme. Foreløpig ser det ut som om det eksisterer et potensiale, men jeg er enig med Smappee at man trenger hjelp fra brukerne til å klassifisere stegendringene i forbruket. Et problem jeg ser i noen tilfeller er panelovner som skrur seg av og på uregelmessig hele dagen, disse kan da "gjemme" andre stegendringer slik som du beskriver i av-hendelsene. Dette er grunnen til at jeg er interessert i å vite om målere tilkoblet TN- eller IT-nett skiller disse ut bedre, gitt at de er på samme fase. I mitt tilfelle er panelovnene koblet mellom fase 2 og fase 3 og disse fasene er derfor overfylt. Om dere er interessert kan jeg legge ut oppgaven min her når den er ferdig, så kan dere lære mer om NILM og mulighetene jeg fant gjennom forskningen min?

Slettet alt av gamle regler og handlinger og sånn, før jeg satt opp ny trigger og handling. Så det var ikke det som skrubbet. Mye mulig det bare var hastverk fra min side. Kom hjem fra jobb nettopp, og tempen i stua hadde såvidt går under temperaturen jeg satt. Lampa lyste som ei sol! Så det funker bra når det funker. Sent fra min Moto G (5S) Plus via Tapatalk

Joda. Kan jo det og ? Det første jeg satt opp var et skript for å slå pinell-radioen på badet på og velge AUXinngang, samt slå på orange-pien jeg bruker som snapcastmottaker. Og et skript for å slå det av igjen. musikk_bad_on: alias: musikk bad on sequence: - service: media_player.turn_on entity_id: - media_player.pinell_supersound_002261086da2 - service: switch.turn_on entity_id: - switch.musikk_bad_switch - service: media_player.select_source data: entity_id: media_player.pinell_supersound_002261086da2 source: 'AUX inngang' musikk_bad_off: alias: musikk bad off sequence: - service: media_player.turn_off entity_id: - media_player.pinell_supersound_002261086da2 - service: switch.turn_off entity_id: - switch.musikk_bad_switch Lagde så en bryter som kjører skriptet musikk_bad_on når den blir slått på og musikk_bad_off når den blir slått av. Brukte template switch. - platform: template switches: musikkbad: friendly_name: "Musikk bad" value_template: "{{ is_state('switch.musikk_bad_switch', 'on') }}" turn_on: service: script.turn_on entity_id: script.musikk_bad_on turn_off: service: script.turn_on entity_id: script.musikk_bad_off Kommer til å gjøre det samme med flere steder i huset så jeg kan få laget min egen multirom-løsning som kan kontrolleres fra en fane i Lovelace. Har mopidy-server og snapcast-server kjørende på en linuxpc jeg bruker til Plex-server som alltid er på.

Første gang for alt [emoji6] Sent from my SM-G930F using Tapatalk

Regner med det er noe av det samme som Smappee også har implementert https://www.smappee.com/be_en/blog/smappee-appliance-recognition/ Dette har jeg også i hus, men hos meg er det ikke robust nok til at jeg kan bruke det i praksis. Kunne i prinsippet hentet ut hendelser som Smappee registrerer for laster som går av og på, men det kan ikke brukes i praksis da jeg ikke kan være sikker på at jeg får med meg av-hendelsen etter en tilhørende på-hendelse. Laster som er like klarer den heller ikke skille, feks varmekabelkurser i ulike rom men som har likt areal. Kanskje det kan være robust nok i små leiligheter med lavt strømforbruk.

Dette høres både spennende og skummelt ut. Men mest spennende!

Jeg har ihvertfall disse dataene, uten å vite hva jeg skal bruke de til..

Hmmmm! Det kan du ha rett i, jeg pleier å gjøre det slik for å minske belastningen plugin'ene mine har på HomeSeer. I andre plugins er det jo verdier som oppdaterer seg VESENTLIG oftere (tenk få sekunder mellom hver oppdatering) og det er vanligvis helt unødvendig å oppdatere HomeSeer devicen når kaffetrakteren hvert 3. sekund bekrefter at nå har den fremdeles antall kopper satt til 6... Men akkurat her ser jeg at det skaper problemer. Men jeg har et enkelt alternativ. ... merk at jeg gir plugin'en 30 sekunders tid slik at vi vet at prisen er oppdatert. Dette vil i praksis ha samme effekt.

Ja, jeg har fått enhetene. Måtte vente på USB-RS485-konverteren, og den er også i hus nå. Oppkopling av systemet ble gjort i går, men der strandet det foreløpig. Er ikke helt sikker på hvordan alt dette skal henge sammen. Har lastet ned noen testprogrammer for MODBUS, men får ikke kontakt enda. Så jeg også skulle gjerne hatt litt bistand fra de erfarne der ute. Uansett så skal jeg komme tilbake med resultat, når det foreligger noe som er verd å dele.

https://www.power.no/hjem-og-fritid/reisetilbehoer/us-to-eu-adapter-bulk/p-647626/?q=eu adapter

Ble bra her med Luxaflex og ingen synlige ledninger. WAF var lav etter innkjøp pga pris, men steg igjen når det ble montert. OpenHAB 2.3 har bug i powerview-bindingen, den er fikset til 2.4 (som ikke er sluppet) - men så oppdaget jeg at Duette-gardinen ikke er støttet, dvs. OpenHAB 2.4 klarer ikke styre den øverste skinna, kun den nederste. Pga. bug i 2.3 lagde jeg meg min egen kobling med MQTT mot Powerview-hub'en i Python. Denne vil virke for alle andre uavhengig av OpenHAB, men krever litt ad-hoc skreddersøm. I tilfelle noen trenger det (Når OpenHAB bare snakker MQTT mot mitt eget Python-script så omgår jeg hele bug'en og også Duette-begrensinngen - hadde jeg vært bedre i Java hadde jeg nok heller fikset OpenHAB enn å gjøre det omigjen i Python..) Åpner seg i topp om morgenen. Lukket på husalarm er på siden det er vinter, og disse isolerer godt. Åpent på dagtid når vi er hjemme. Åpen kun øvre halvdel om kvelden for å minske innsyn.

Fibaro RGBW controller og en passende 12V strømforsyning.