Vinnerliste
Populært innhold
Viser innholdet med mest poeng fra 20. feb. 2017 i alle områder
-
Nå er det mulig å styre en varmekilde med en vilkårlig temperatursensor og en vilkårlig varmekilde (av/på). Jeg har lovet i lengre tid å slippe script-pakken min, men det har vært litt mer utfordrende å lage en fungerende frontend. Nå har jeg imidlertid hoppet bukk over den problemstillingen og har flyttet innstillingene fra selve root-devicen og over i en tradisjonell ini-fil. Det gjør det lettere å endre alle innstillingene, selv om det er et stykke fra å være ideelt. Merk: Script-pakken er testet, men må vurderes som en beta-versjon. Egenskaper: "Auto", automatisk modus: Temperatur hentes ut fra et eller to oppsatte programmer. Programmene kan bruke ferdigdefinerte temperaturer eller egendefinerte. "Manual", manuell temperatur: justeres med nedtrekksboks og knapper for + og -) "High" og "Low" for hurtigvalg av forhåndsdefinerte "Schedule" og "AlternativeSchedule" kan byttes på f.eks. med Fridager.vb-scriptet (eller en vilkårlig annen On/Off virtuell device). Foreløpige begrensninger: Fungerer foreløpig ikke på Zee 1 eller 2. Begrensning i mono gjør at Enums ikke fungerer (visstnok). Jeg kan imidlertid unngå enums med litt omskriving (selv om det er veldig praktisk), så det kommer i en ny versjon. Nedtrekksboksen for manuell temperaturvalg setter ikke "Mode" til "Manual" automatisk (begrensning i scripting, kan ikke, så vidt jeg vet sette opp return CAPI-kall i script). + og - knappene gjør imidlertid dette helt fint. Oppsett 1. Først finn device Ref/IDene til både devicen for temperatursensoren og devicen for av/på bryteren til varmekilden (ovnen?). Device Ref står øverst på "Advanced"-tab'en etter at du har trykket på en device (eller i URLen som dukker opp når du holder musepekeren over linken til devicen). 2. Lag et event som du kaller "Termostat setup" (f.eks), sett trigger til "This Event is manually triggered". Legg til en Action som er "Run a Script", og trykk så på knappen "Edit, og skriv inn "VirtualThermostat.vb" (filnavnet er VELDIG viktig) og trykk OK. 3. Nå kollapser scriptet, så vi utvider det igjen og trykker på det røde flyet : . I scriptboksen (det store blanke feltet med Sub Main.... etc) fjerner du alt og kopierer inn scriptet under: ... og trykk på "Save Script" knappen nederst. HUSK: Trykk på "Save Script" knappen nederst. Gjort det? I "Sub or Function"-boksen skal det stå "Setup". I Parameter skal det stå: HeaterDeviceReference=1139,ExternalTemperatureSensorRef=74 ... der du bytter ut 1139 med dev-ref til av/på-bryteren og 74 med dev-ref til temperatursensoren. Da skal alt se slik ut: 4. Trykk på den blå pilen øverst på eventet for å sette i gang setup-rutinen. Da er vi snart ferdige. 5. Scriptet oppretter et Event (i Event-kategorien "Virtual Thermostat") som kjører scriptet hvert 5. minutt, og det er nesten helt riktig. Vi må bare justere et par ting. Åpne scriptet som ligger under "Virtual Thermostat". Gi det et litt mer beskrivende navn, så er det enklere å finne tilbake. 6. Utvid Run Script action'en, og deaktiver "Only allow a single instance to run at a time" (ellers er det jo bare en termostat som vil fungere) Hvis alt nå er vel, skal det se slik ut: 7. Personlig skrur jeg av logging på slike eventer: 7. ??? 8. Profit! Konfigurasjon I /Config-mappen din har det nå dukket opp en fil som heter "VirtualThermostat_nnn.ini" der nnn er device referansen til root'en (den samme som også navngir eventet over). Den vil se f.eks. slik ut: [Settings] ExternalTemperatureSensorRef=74 TemperatureCorrectionAddition=0 TemperatureCorrectionMultiplier=1 TemperatureOffset=0,3 Log=False HeaterDeviceReference=1139 TemperatureHigh=22 TemperatureLow=19 AlternativeScheduleDeviceReference=0 [Schedule] 6:00=High 8:0=Low 16:00=High 22:00=Low [AlternativeSchedule] 6:00=High 23:00=Low ... der vi kjenner igjen ExternalTemperatureSensorRef og HeaterDeviceReference som de vi satte opp i Setup-rutinen. De andre feltene har følgende forklaring: TemperatureCorrectionAddition=0 er hvor mye som legges til eller trekkes fra den faktiske temperatursensoren. Fint for kalibrering TemperatureCorrectionMultiplier=1 hvor mye temperatursensoren skaleres med fra den faktiske temperatursensoren. Fint for kalibrering. (1 = ingen skalering) TemperatureOffset er hvor langt ned under "Setpoint" temperaturen tillates å bli før varmekilden skrus på. Hvis Setpoint er satt til 22 grader, vil ikke ovnen bli satt på før temperaturen har sunket under 21,7 grader. TemperatureHigh og Low er selvforklarende. AlternativeScheduleDeviceReference er referanse til en enhet som bestemmer om det er "Schedule" eller "AlternativeSchedule" som skal brukes. Schedule og AlternativeSchedule: Her står klokkeslett (i stigende rekkefølge og uten ledende nuller) og tilhørende temperaturer. Med mindre du spesifiserer noe annet, vil kl 0:00 alltid begynne med "Low" temperaturvalg. Så da leser vi Schedule slik: Mellom kl 00 og 06 er det "Low" Mellom kl 6 og 8 er det "High" Mellom 8 og 16 er det "Low" Mellom 16 og 22 er det "High" Og fra 22 og utover er det "Low" Du kan spesifisere din egen temperatur istedenfor "High" og "Low" også, i tilfelle du vil ha en halv grad ekstra om kvelden. Da kan det f.eks. se slik ut: [Schedule] 6:00=High 8:0=Low 16:00=High 20:00=22,5 22:00=Low Pro tip: Du kan også sette opp Eventet til å kjøre på "device change" når temperatursensoren endrer verdi, istedenfor hvert 5. minutt (eller hvor ofte det å passer deg). Da kan det også være lurt å sette opp et par tilleggs-triggere til på bestemte klokkeslett eller andre hendelser, for det er jo ingen garanti at temperaturen endrer seg slik at scriptet trigges. Enjoy!6 poeng
-
En av de større manglene i HS3 er, etter min mening, en god tilstede-funksjon for å trigge events avhengig av husets status. Dette er min løsning på tilstede-funksjon i HS3. Se vedlagte PDF for fremgangsmåte og ZIP for nødvendige filer. Håper dette kommer til nytte for flere :-) HS3_Presence.pdf HS3_Presence.zip5 poeng
-
4 poeng
-
Jeg satt litt i går kveld for å prøve å legge til NRK dagsnytt som en skill til Alexa. Å sette opp en newsflash skill er relativt enkelt (klikk, klikk, neste, neste). Problemer oppstod når jeg skulle legge til rss feeden fra dagsnytt siden selve filen var altfor stor, så løsningen ble å importere rss-en til min egen webserver for så å lage en egen rss feed. Dagsnytt podcastene går direkte 07:30 og 16:00, de legges ut på nett ca. 10 minutter etter sendestart så min rss oppdaterer seg hvert 10. minutt. For å unngå gamle nyheter er det kun de 2 siste podcastene som blir listet i min rss. RSS feed: http://rosander.no/dagsnytt/ Bonus: Her er en rss feed med norske nyheter på engelsk som kan brukes i en newsflash skill. Dette er tekstnyheter som blir tolket med vanlig "Text-to-Speech" av Alexa så det kan høres litt robotaktig til tider.3 poeng
-
3 poeng
-
2 poeng
-
Elektrikeren din har rett. Du kan ikke benytte dine eksisterende dimmere, du må bytte dem ut med brytere + impulsfjær.1 poeng
-
1 poeng
-
That makes sense, because it's an unreleased plugin by Fermate and me. It's still in development.1 poeng
-
Dette er "suffix" under status graphics1 poeng
-
Ok, for på Mono er det noen versjoner hvor den ikke stoler på noen sertifikater uten at man importerer CA-sertifikatene selv. Men, her er sikkert problemet at PRTG kjører på et selfsigned sertifikat? Det er sikkert det som blir "avvist". Vet ikke om det er en .NET-setting eller om det ligger i plugin. Du kan kanskje sjekke med Jon00? Mitt problem løste jeg med wget. Kjører en jobb som henter ned siden og lagrer i html-katalogen til HomeSeer og så bruker jeg bare http://localhost/filen.htm i scraperen.1 poeng
-
1 poeng
-
1 poeng
-
For å svare på mitt opprinnelige spørsmål; Hvordan identifisere dårlige noder? Jeg innser nå at spørsmålet er feil. Det riktige spørsmålet er: Hvordan få oversikt over nettverket? Det går opp for meg at mye informasjon er tilgjengelig i node-oversikten. Elementær info for Moskus og iblis og andre, selvsagt, men kanskje kjekt for en random googler som ender opp her. I oversikten står det hvilken kommunikasjonsrute de ulike nodene bruker, og hvilken hastighet de kommuniserer med. Skulle likt å ta den informasjonen inn i et visualiseringsverktøy. I mellomtiden gir det meg litt verdi å kjapt tegne opp mitt nettverk, som da ser slik ut: Opprinnelig laget jeg alle rutene, men har her tatt bort alle direkteruter, og erstattet de med farten som label. Oversikten forteller meg at jeg har et par noder som ikke kommuniserer optimalt mot kontrolleren, for eksempel nr 53 helt til venstre. Dette er en fibaro multisensor. Den har valgt seg en rute via en Fibaro dimmer, og oppnår kun 9.6K. Samtidig står det en Fibaro wall plug (47) ikke langt borte, som har god forbindelse. Så multisensoren burde heller rutes via denne (kanskje). Jeg ser også at node 9, som er en Qubino roller shutter, har blitt veldig populær blant andre noder som gjerne ikke vil snakke med interfacen direkte. Så her går det en del trafikk gjennom. Det er litt merkelig, fordi den er veldig usentralt plassert, men har god forbindelse med interface. En del av disse rutene burde kanskje fjernes, og gjøres direkte. Denne visualiseringen kan garantert automatiseres dersom man har kunnskapen og tiden. All informasjonen ligger i HS3, og kan sikkert hentes både direkte og indirekte (scraping). Jeg savner et slikt analyseverktøy. Dette i seg selv løser ikke problemene mine, men jeg ser jo at jeg må begynne å ha litt mer kontroll på hvordan nettverket mitt ser ut. Jeg skal forsøke å utbedre en del av disse rutene og se om det har en effekt, men kommer til å vente noen dager slik at jeg ikke roter til min egen debugging nå. Ingenting er verre enn å fjerne et symptom uten å vite hva problemet egentlig var... Angrer på at jeg ikke gjorde dette mens IDlock'ene var i nettverket, og før jeg eksluderte/inkluderte 4 multisensorer tidligere i dag for å gjøre de ukrypterte.1 poeng
-
1 poeng
-
1 poeng
-
1 poeng
Vinnerlisten er satt til Oslo/GMT+01:00