Har satt Fibaro PowerMeter's på både vaskemaskin og tørketrommel. Det er flere formål her;
1) Varsling når vaskemaskin/tørketrommel er ferdig. Begge står litt bortgjemt i en etasje vi normalt ikke befinner oss i.
2) Varsling dersom vi drar fra huset når enten tørketrommel eller vaskemaskin går
3) Varsling dersom huset settes i nattmodus mens tørketrommel eller vaskemaskin fortsatt går.
Egentlig mye det samme som GeneralVirus tidligere har beskrevet.
Utstyr
2 x Fibaro PowerMeter
HS3 med HStouch på ekstern klient (nettbrett på vegg)
Siden verken vaskemaskin eller tørketrommel kommuniserer med noe, er tanken å derivere status via strømforbruket. Dermed starter hele øvelsen med en kjapp analyse av strømforbruket på en typisk syklus. Dette logges lett med PowerMeter. Brukte opprinnelig et script som skrev tidspunkt og forbruk til en tekstfil, men oppdaget kjapt at det var enklere å bare hente informasjonen rett fra loggen i HS3.
Slik ser forbruket ut for vaskemaskinen på to tilfeldige programmer:
Vaskemaskinen har ganske varierende forbruk, inkludert noen "spikes" opp til like over 2000 W. Forbruket vises derfor best på logaritmisk skala. Det er en utfordring at forbruket varierer såpass mye. Det som imidlertid er klart er at et ultralavt forbruk over tid er en god indikasjon på at programmet er ferdig.
Slik ser samme grafen ut zoomet inn på de siste minuttene:
Jeg legger derfor opp til å detektere den flate linjen etter at vasken er ferdig.
For tørketrommelen ser forbruket litt annerledes ut (vist på lineær skala):
Tørketrommelen har en funksjon som gjør at den vender (ikke "vente" slik det står i grafikken...) tøyet litt ca hvert 30 sekund etter at den er ferdig. Samme type forbruk kan ses flere ganger langs syklusen, så det i seg selv er ikke diagnostisk. Forbruket i pausene på slutten er imidlertid bittelitt lavere enn forbruket ellers, og fungerer som diagnose.
Slik ser Fibaro PowerMeter ut i HS3. Det er subdevice "Power" som brukes i dette oppsettet:
I HS3 setter jeg opp virtuelle devicer for å kategorisere strømforbruket. Det er nyttig, fordi man da får et ledd mellom statusen og selve forbruket. Da kan man legge inn krav om en viss varighet på forbruk osv, og man kan dermed fjerne effekten av de ultrakorte spikene i forbruk. Statusen er også en virtuell device. Som dere ser hadde jeg opprinnelig en plan om å detektere sentrifugering, men den kjappe dataanalysen viser at det blir vanskelig. Teksten i status-devicene er laget for å gi grammatisk mening når den vises i HStouch.
Eventer endrer proxyene basert på avlest forbruk, og andre eventer (vist under) fanger opp endringene i proxyene, og setter selve statusene. Her er eventen som fanger opp om vaskemaskinen er ferdig med et program. Her har jeg valgt å bake inn varslingen i samme event. En litt mer ryddig måte å gjøre det på vil være å ha en egen event som styrer kommunikasjonen basert på om statusen endres til "er ferdig". Smak og behag, I guess.
Verdiene for "lav" og andre forbrukskategorier justeres etter forbruket og signaturen til de ulike programmene. Utfordringen er å finne noe som er diagnostisk på tvers av alle ulike programmer.
Her er det også viktig å bruke "has been XX for exactly", i stedet for "at least". Sistnevnte vil fortsette å trigge eventen i all evighet, mens førstnevnte kriterier oppfylles bare 1 gang. I praksis ble det ganske mange eventer ut av dette, og det hadde nok vært best med et script. Det får bli på sikt. Etter at screenshot ble tatt har jeg lagt inn en sjekk i disse eventene for om statusen er noe annet enn "er ferdig".