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

Vinnerliste

  1. Okstad

    Okstad

    Medlemmer


    • Poeng

      5

    • Innlegg

      21


  2. Moskus

    Moskus

    Administrator


    • Poeng

      3

    • Innlegg

      16 801


  3. ZoRaC

    ZoRaC

    Crew


    • Poeng

      3

    • Innlegg

      5 744


  4. toonwolf

    toonwolf

    Medlemmer


    • Poeng

      3

    • Innlegg

      738


Populært innhold

Viser innholdet med mest poeng fra 07. mars 2018 i alle områder

  1. Da har jeg fått løst denne og ELKO-dimmeren fungerer nå uten nevneverdig forsinkleser mot jowiHue i HomeSeer. Løsningen var å definere "Reporting Interval" på 0x0000 attributten for både "On/Off" og "Level Control" i deCONZ Jeg definerte følgende verdier: Min Report Interval: 1 Max Report Interval: 300 Reportable Change: 1 Jeg opprettet også direkte binding melom begge disse cluterene og ConBee-kontrolleren.
    5 poeng
  2. Til info om det er flere som er interessert i akkurat denne funksjonen så har @INTIN RuneV nå i dag bekreftet at dette er noe som er nytt i 150 "Ja, på 150 kan du fjernåpne og la den stå ulåst. Det gikk ikke på 101. Kan prøve å få testet dette med HomeSeer og Beta versjonen av z-wave chip som vi har fått. Låsen støtter det ihvertfall"
    3 poeng
  3. Fikk det til! Nå kjører det i OSX
    2 poeng
  4. Jeg laget for to uker siden en liten(?) kode for å optimalisere strømforbruket med tanke på strømutgifter (ikke strømforbruk) for å ta hensyn til varierende pris gjennom døgnet (og siden jeg for et par uker siden fikk timesavlesning gjennom ny måler fra BKK og strømregning hos Tibber). Grunntanken er å forvarme huset når prisen er billig. For å kunne gjøre dette må man ha en modell av huset som beskriver strømforbruk som funksjon av husets tilstand (temperatur) og hvilken temperatur man ønsker. Jeg har i et halvt år samlet strømforbruk hvert 5. minutt og samtidig logget temperatur. Ved å se på midlere strømforbruk for hver time og sammenligne det med temperaturer og temperaturendring over hver time så kan man bygge en modell på dette (hvis jeg gjentar denne analysebiten kontinuerlig, så kan det kalles maskinlæring). Jeg bruker da sklearn i Python til å lage en (multi)lineær modell som predikerer strømforbruk utifra temperaturendring og differanse mellom ute og innetemperatur. Det er betydelig med støy i denne modellen, se plott av alle dataene mine her: Som en bilineær modell i Python, så implementerer jeg den slik, dette blir nesten analogt med de rette linjene i plottet over: def hourly_power_usage(tmpincrease, insideoutsidediff): """This function could do multlinear regression on the dataset or use finished regression coefficients. It answers what power (in KwH) is needed for the whole house to reach the delta temperature in one hour. """ # from sklearn import linear_model # model = lm.fit(X, y) # X = [inne_diff, inne_diff_ute], y=Smappee5minavg(hour)] coef = [2.150, 0.189] # beware W vs KW intercept = 0.5735 return coef[0] * tmpincrease + coef[1] * insideoutsidediff + intercept Her er det tallene 2.150 og 0.189 kW som man kan tolke: 2150 er ekstraeffekten som kreves for å øke temperaturen med en grad i løpet av en time, samt at man må legge på 189W for hver grad differanse det er på ute og inne, og blir et mål på hvor godt huset er isolert. Kaldere utetemperatur gir høyere pådrag på 189-koeffisienten. I tillegg passer det modellen å legge på 573 watt uansett hvordan temperaturforholdene er. Når denne modellen er på plass, så kan man ved å kjenne framtidas strømpris, framtidas temperaturbehov (ønsket termostatinnstilling) og framtidas utetemperatur (yr) estimere strømforbruk og tilhørende kostnad. I tillegg kan man få tilpasset start av oppvarming for å møte et framtid temperaturønske. Jeg har delt "optimaliseringen" i to deler. Først en kodesnutt som flytter oppvarming tidligere i tid i tilfelle estimert effektpådrag blir for stort. Hvis man skal hoppe fra 18 grader til 25 grader i ett jafs, så tilsier modellen et effektuttak på omtrent 14KW. Jeg har ikke nok variabel effekt (Multireg x 5 (snart 10) + varmepumpe) til å klare dette, så det betyr at jeg må starte en eller to timer tidligere. Koden er enkel brute-force som øker termostatverdien timen forut for høyt estimert effektuttak og gjør dette omigjen helt til effektuttaket går under en viss grenseverdi. Resultatet av det steget ligger i den blåe linja i plottene lenger nede, kalt 'Kwh-adjusted'. Neste steg er optimalisering - her gjør jeg det med hjemmelaget brute-force (jeg tror optimaliseringsteknikken kalles 'simulated annealing'). Jeg øker temperaturen med 0.5 grader på tilfeldige tidspunkt (untatt i nedkjøliingsperioder) og rekalkulerer kostnad. Hvis en viss temperaturøkning resulterer i redusert kostnad, bevares forslaget, ellers forkastes det. Dette gjøres iterativt, og endel ganger omigjen for å øke sannsynligheten for at man ender opp på et globalt minimum. Resultatet blir som man kan se i plottet under. Optimaliseringen gjentas hver time, og jeg har justert antall iterasjoner slik at det tar ca 1 minutt å kjøre. Her kan man se blå kurve som startpunkt, og rød kurve som ferdig produkt. I natt har altså huset tenkt å begynne med forsiktig oppvarming allerede klokka ett for å på billigst mulige måte klare holde 25 grader mellom 7 og 8 i morgen tidlig når prisen er 80 øre (25 grader er 'master-termostat', faktiske termostater har en viss delta i forhold til denne utifra rommets behov). Det regnes også ut hvor mye man sparer på optimaliseringen, akkurat i denne perioden er det hele 2.37 kr (det er mye i forhold til det jeg har sett de i ukene dette har vært i drift..). (i plottet ser man at jeg også skrur av varmtvannstank i døgnets tre-fire dyreste timer) Så, virker det? Vel, jeg har ikke kontroll på alt effektuttak ennå (venter på 5 stk multireg som skal monteres av elektriker), men jeg er ihvertfall i stand til å observere historisk strømforbruk og pris som ser slik ut: og gjetter på at akkurat her har jeg spart noen titalls øre
    1 poeng
  5. Jeg tror du kan komme vesentlig bedre utav det med deCONZ.
    1 poeng
  6. Fikk svar fra Kamstrup på en forespørsel dit: Dokumentet som refereres til er v3.1 av det vi tidligere hadde som v3.0. Dette er lastet opp på github Har også sendt forespørsel til NVE og NTE om hvordan vi kan holde oss oppdatert på slike endringer, og om Kaifa nå kommer med samme endring. Lurer litt på å kjøpe en utgave av NEK IEC 62056-7-5:2016, men er ikke 100% sikker på om den dekker alle detaljer. Noen som har tilgang til denne, evt. et abbonement hos standard.no? Edit: fikset versjonsnummer på dok
    1 poeng
  7. Da høres det ut som assosiasjonene er satt opp feil. Hvordan ser de ut? Hvilken versjon av Z-wave-plugin? Mener å ha sett denne Fibaro-enheten nevnt i noen nylige releasenotes.
    1 poeng
  8. Liten oppdatering: Snakket med produktsjefen i Somfy, og han kunne fortelle at Somfy kommer med åpent API i April, og det var ingenting som tydet på forsinkelser. Mulig man må fortsatt ha Tahoma hub, men jeg går likevel for IO
    1 poeng
  9. Nei, man trenger det ikke for det grunnleggende. Så går det fint til et visst punkt. Og det punktet er vanskelig å definere... SKal du kjøre en del plugins, logging, oppslag, etc, så er det like greit å bare starte med en liten PC med en gang.
    1 poeng
  10. Jeg har prøvd å studere dette fenomenet litt. Dette er det jeg har funnet så langt: Det finnes en software på GitHub som vi har såvidt vært innom tidligere, og denne kan kjøres opp i test-modus for push meldinger: https://github.com/Gurux/Gurux.DLMS.Net Eksempel for test-kjøring er det som ligger under folderen Gurux.DLMS.Push.Listener.Example.Net Per default er denne testen satt opp med InterfaceType.WRAPPER. Ved å endre dette til InterfaceType.HDLC kan en motta slike 7E ... 7E meldinger som måleren vår sender (må også fikse noe adressering, men det ser en av feilmeldinger) Prøver en så å sende inn Kamstrup-data, så stopper den fordi E6 ikke er gjenkjent som en kommando. Problemet her er at kommandoen i pakken er 0F. Det ligger tre bytes i Kamstrup (og Kaifa) sine data som denne softwaren ikke kjenner igjen. Disse er E6 E7 00. Ved å debugge litt og manuelt overstyre er det mulig å skippe disse tre bytes. Gjør en det vil faktisk hele Kamstrup pakken leses fint inn. Ser jeg nærmere etter hva som skjer etter at 0F kommandoen blir funnet, så forventes det å hoppe over 4 bytes (00 00 00 00) og så lese inn lengden på et informasjonsfelt (0C = 12 bytes). I koden fra Gurux leses disse tvert inn i et datoformat, uten noe mer sjekk. (Se funksjonen HandleDataNotification i GXDLMS.cs) Så, prøver jeg å gjøre det samme med Kaifa dataene fra min måler, så feiler dette når denne timestamp blir forsøkt lest Er jeg kreativ og endrer Kaifa data og fjerner 09 fra denne timestamp, så fungerer det også (må da oppdatere størrelse og rekalkulere checksum for header og pakke) Så, dette er jo en viss indikasjon på at dette skal være slik (dvs. ingen 09 byte i timestamp), men det er også litt urovekkende at ikke Gurux klarer å lese pakken uten å hoppe over denne E6 E7 00. Sekvensen jeg måtte ta bort er beskrevet som Destination LSAP, Source LSAP og LLC. Kapittel 8.3.2, Fig 19 i den grønne boken beskriver dette, men jeg blir ikke så veldig klok av det. Jeg har heller ikke den komplette boken, bare denne extract-versjonen, hvor det plutselig står "for more details see the complete Green Book". Beklager alle detaljene her, jeg måtte bare få ting notert. Godt mulig løsningen er å ha noen ekstra settinger per målertype som kan hjelpe oss å navigere til riktig sted på riktig måte...
    1 poeng
  11. @moskus , det er bare å stikke innom i sentrum, så skal du få et loddekurs på chipper og pcb?
    1 poeng
  12. Har nå fått data fra AMS til raspberry, men hva er enkleste vei videre til Homeseer?
    1 poeng
  13. Permanent: https://discord.gg/fhsWucy
    1 poeng
  14. Blir status i Homeseer oppdatert når du slår av/på med bryteren?
    1 poeng
  15. Ganske sikker på at den kjører stabilt nå
    1 poeng
  16. Tok en runde med fjernkontrollen til webasto varmeren (Audi) i dag: Har remote som først trenger et trykk for "wake up" av kontrolleren, deretter er det bryter ved siden av som må brytes for å starte varmer. Så brukte en Nodemcu med et rele for dette, remote bruker 3V og rele går på 5V. Brukte D6 Output direkte på knapp 1 for wake up, trenger bare et "3V støt" for å komme i gang, deretter venter jeg bare et par sekunder så remote er oppe og går og så bryter jeg knapp 2 med rele for å sende RF til bilen som da starter diesel varmer. Så blir vel å legge den på MQTT hvis jeg ikke tar den direkte fra Homeseer. "Alexa, heat my car" ? Utdrag av test kode: // setup pinMode(D6, OUTPUT); // Power ON pinMode(D7, OUTPUT); // Trigger relay digitalWrite(D6, LOW); digitalWrite(D7, HIGH); // set relay HIGH, use LOW to toggle // loop digitalWrite(D6, HIGH); // Power on remote control delay(500); // Delay digitalWrite(D6, LOW); // Power off delay(2000); // wait 2 sec for remote contol to wake up digitalWrite(D7, LOW); // Send to relay/short button on remote control to send "heater on" delay(500); // 0.5 sec should be long enough for tooggle switch digitalWrite(D7, HIGH); // turn off toogle relay Bilder: Knapp 1 er nede for power up, knapp 2 over er styrt av rele. Kjører inn 3.3 Volt på undersiden hvor batteri sitter:
    1 poeng
  17. Meget bra at Gilje Tre bruker uavhengig tredjepartsteknologi i stedet for å prøve å lage noe selv og som kun funker med GiljeTreAppen.
    1 poeng
Vinnerlisten er satt til Oslo/GMT+01:00
×
×
  • 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.