Integration - Fange Tryk

[Troels Larsen1354922265]

Jeg har fået skrevet et .NET Core program, der kan opfange når et output skifter, men jeg ville gerne kunne fange når nogen trykker på en knap, hvad enten er der wireless eller kablet.

Det lader ikke til at være muligt at fange disse notifikationer i deres soap API i controlleren, så jeg tænkte det ville være muligt, hvis jeg:

- Købte et 24V Output modul
- Smed en Raspberry Pi, ESP8266 eller Arduino på dette modul. (der skal nok lige reguleres 24V -> 3.3V for RPi på en eller anden måde)
- Programmerede de ting, jeg gerne ville i IHC Visual, så den 'tænder' for microcontrolleren, der så sender et signal til hvad så end, det er jeg skal gøre.

Er der nogen, der kan komme på en bedre løsning?

[Mikkel Skovgaard]

Der er flere muligheder - men kan du fange noget output kan du også fange input. Alternativt lave en funktionsblok hvor alle inputs ryger ind i også ændre et output.

Du kan også se på mit IHC Captain

[Troels Larsen1354922265]

Min løsning står og poller API'et så hurtigt den kan - typisk 2-3 gange i sekundet. Her kan jeg læse hele projekt status.

Men jeg tænker, at indgangene ikke har nogen 'status' - altså enten at det ikke kan lade sig gøre at aflæse om der er trykket eller ej - eller at jeg i givet fald skal ramme API'et i lige præcis den period, hvor knappen bliver trykket ind.

Det er derfor jeg tænkte det, som du også beskriver - at lave en funktionsblok/kip, der tænder et output, der ikke er forbundet til andet end et 24V output.

En 3. løsning kunne være at erstatte et 24V Output med en raspberry, hvis det ellers er klart hvordan IHC controlleren kommunikerer med modulerne (I2C?) Det tænker jeg dog er lidt mere risikabelt.

Jeg ved ikke helt hvad IHC Captain er, men det undersøger jeg da lige.

Tilføjet efter at have hørt om eksistensen af IHC Captain:

Ja ok, jeg kan se, at der nok er en del overlap i IHC Captain og det, jeg laver. Kan du i IHC Captain få en notifikation når en indgang skifter? Og vil du i så fald af med hemmeligheden? Det kan sagtens være en forkert antagelse fra min side, og at inputs skifter hver gang man trykker. Hvis det er tilfældet, kan jeg uden de store armbevægelser også få inputs med, hvilket vil være en langt bedre løsning end microcontroller + 24V output.

[Kandersen]

1 time siden, Troels Larsen1354922265 skrev:

Kan du i IHC Captain få en notifikation når en indgang skifter?

Svare lige på denne, selvom det er Mikkel der står bag IHC Captain.

ja, det er ren barnemad at få en notifikation når en indgang skifter. Jeg bruger pushover til dette, og modtager en notifikation på min mobil, på de aktiviteter jeg har sat. (når ellers jeg aftaster det rigtige ).

Så vidt jeg forstår på IHC Captain, så aftaster den påvirkningerne, plus at den også selv kan gå ind og påvirke, uanset om det er ind eller ud. I bund og grund er IHC Captain vel at betragte som en udvidet serviceview, hvor du på forhånd kan predefinere hændelser, og hvad der evt skal ske ved disse hændelser.
Fordelen ved det er, at du flytter praktisk talt alle funktioner i IHC controlleren ud på WiFi/LAN nettet, (og egentlig også ud på WAN) via IHC Captain. Så principielt kan du styre alt der er net forbundet, så længe der er en brugbar API til det, og du kender kommandoerne. Fx tænde/slukke/starte/stoppe Sonos, Philips Hue oa..
Og som jeg forstod på Mikkel for kort tid siden, så har han netop skabt support for z-wave også. Så når den kommer, og med en z-wave dongle i en RPi, så er man flyvende på det net også.

Det der er problemet med IHC Captain og de andre systemer, det er at de bliver ikke skræddersyet færdig til en given enhed. Du har ikke et interface hvor du bare vælger din enhed (Sonos, Philips Hue oa), og så klikker du på nogle knapper, sætte nogle simple værdier, og så vupti, så kan du det hele, via IHCén. Nej, man skal selv som bruger ind og finde ud af hvorledes man styre enheden. Fx Philips Hue skal du selv ind og sætte URL samt kommandoerne, og ikke mindst niveauer på de forskellige funktioner. IHC Captain og de andre systemer skaber egentlig bare en forbindelse imellem (interfacer). Det gør at systemet bliver for nørder, der skal bruge en del tid ved siden af på at sætte sig ind i, hvordan man styre enhederne internt. Jeg er endnu ikke selv nået så langt med IHC Captain. Og egentlig ved jeg heller ikke om jeg når dertil, inden at enten IHC helt er uddødet eller udviklingen i IHC Captain i sig selv er stoppet. Måske har jeg helt droppet ideen om Philips Hue på det tidspunkt og i stedet faldet over noget andet, som jeg så skal sætte mig ind i, osv osv.. Meget kan ske, når man skal bruge meget tid på ting, som reelt bare er lir og ekstra komfort/magelighed. Men det er fedt der i det mindste er nogen der gider, når nu LK ikke selv gider. 

[Troels Larsen1354922265]

Kandersen: Det er sikkert let med IHC Captain, men jeg tror ikke jeg kommer til at erstatte min løsning med dette, da det lader til at have et lidt andet scope end mit projekt. Captain lyder til at være en controller, hvorimod jeg udelukkende beskæftiger mig med IHC.

Derfor gik mit spørgsmål mere på hvordan IHC Captain havde gjort ift. LK Controlleren.

Helt enig med skræddersyning. Men LK er langt bedre end f.eks. Danfoss. Jeg ville så inderligt ønske at jeg kunne styre min gulvvarme (master regulator). LK har trods alt et semi-åbent API, selvom REST havde været at foretrække. Men forståeligt nok med SOAP, alderen taget i betragtning.

I mine løsninger har jeg pt. integration med Netatmo, Kodi (tidl. XBMC), Wake-on-LAN til PC'er og mPower fra Ubiquiti.

Men en IHC Captain, der kunne interface med IFTTT ville da sikkert være et hit for mange. Så fik man jo styring af Hue, Sonos og halvdelen af verden 'gratis'.

[Kandersen]

Jeg tror nu ikke IFTTT er så svært at implementere. Men Hue kan jo styres på andre måder end via IFTTT. I øvrigt synes jeg at have læst at netop IFTTT er rimelig ustabilt og ikke specielt hurtigt reagerende. Men det har en hel del smarte funktioner, som jeg dog aldrig rigtig har fået sat mig ind i. Netamo tror jeg også er en god ide, da det vist ligner noget der vil frem. mpower er lidt mere vanskeligt at sige, ikke mindst fordi der findes et hav af den slags løsninger efterhånden (fjernbetjent stikkontakter). Jeg forstår ikke Ubiquiti har set sig et behov for dette. Det irriterende ved alle disse er, at de ikke følger en fælles standard. Man skal, som forbruger, hele tiden sætte sig ind i et nyt system, for at få udført samme aktivitet. Det er gabende idiotisk.. Jeg bruger iøvrigt Osram Lightify plug sammen med min Philips Hue, bare for at komme med et modsat eksempel. Selvom der er lidt knas med tilbagemelding, (Hue melder den ikke kan se den), så fungere det helt perfekt alligevel. Det er rent plug&play, hvis man altså lige kender Hue i forvejen.   

Jeg er kæmpe fan af alle dem der laver disse integreret løsninger. Men engang imellem kunne man godt tænke sig, at de/i lige stopper op med antallet af funktioner, og ser lidt mere dybdegående på brugervenligheden. Og så måske lidt væk fra den ide med, at alle og enhver skal sidde og opfinde den dybe tallerken for gud ved hvilken gang. Set lidt ovenfra så er det jo spild af fantastiske ressorucer og viden, når flere sidder og udvikler noget hver for sig, der lige så vel kunne være et massiv fælles projekt. Openhab er et fælles projekt. Men ingen af udviklerne formår at tænke lidt ned af den nørdede rangstige og få skabt en platform der i den grad trækker interesseret ind.
 
Har du noget løsning du vil have testet, så råber du bare op, så varmer jeg Rpién op. Nå, men det var et lille sidespring 

[Troels Larsen1354922265]

Det 'smukke' ved IFTTT er jo netop at de samler alle de mange løsninger i én pakke, som man selv 'programmerer'. Dvs. at der kun er én person, der skal skrive et interface til f.eks. Hue. Ulempen er, at det foregår online. Dvs. intet virker uden internet og svartiderne er længere. Hvis IFTTT var et bibliotek af programblokke man kunne downloade, ville det være genialt. Så ville Mikkel og undertegnede være fri for at selv at skulle kode hele interaktionen med diverse tjenester. Det er netop det, du efterspørger.

Problemet er at alle gerne vil være controlleren og kun få gider lave åbne interfaces. Derfor har vi IFTTT, Openhab, Smarthome, SmartThings, etc.

Jeg prøver lige at kigge svaret fra IHC controlleren igennem en ekstra gang i morgen og ser om jeg kan finde Inputs også.

[EjvindHald]

Prøv at se på OpenHab2 - der er interfaces til rigtig meget inkl. IHC, z-wave, Hue, Homekit, Sonos, Pushover m.m. I OpenHab kan du på IHC aflæse og sætte ikke kun input og output moduler, mens også alle værdier i funktionsblokke. Jeg synes, at det er ret cool sammen med IHC, og det er tilgængelig bl.a. til Windows, RPI og Synology NAS server.

Hvis du ikke ønsker OpenHab, så kan du blot se i kildekoden på GitHub, hvordan bindingen til IHC er lavet. Herefter kan du implementere det samme i .Net - jeg formoder, at du udvikler i C#.

[Mikkel Skovgaard]

Du kan i IHC soap api bede om at overvåge en hvilken som helst ressource - så skal du ikke polle hele tiden og belaste controler.

Basically:

1. Bed om at overvåge X ressource
2. Du får et svar øjeblikkeligt med nuværende værdi
3. Bed om at overvåge X igen med YY timeout i sekunder
4. Hvis X ændre værdi inden YY så får du den nye værdi
5. Hvis X IKKE ændre værdi inden YY så start igen ved 3.

[Mikkel Skovgaard]

IHC captain er ikke en controller - det er pt. begge dele:

1. En måde nemt at opsætte overvågning på og trigger en handling - den handling kan være Sonos styring, køre en kommando lokalt, post noget web etc.
2. Remote "control" hvor man kan styre IHC controlleren

[Troels Larsen1354922265]

16 minutter siden, Mikkel Skovgaard skrev:

Du kan i IHC soap api bede om at overvåge en hvilken som helst ressource - så skal du ikke polle hele tiden og belaste controler.

Basically:

1. Bed om at overvåge X ressource
2. Du får et svar øjeblikkeligt med nuværende værdi
3. Bed om at overvåge X igen med YY timeout i sekunder
4. Hvis X ændre værdi inden YY så får du den nye værdi
5. Hvis X IKKE ændre værdi inden YY så start igen ved 3.

Hmm.. Jeg har set den funktionalitet, men tænkte at siden der ikke var mulighed for bare at lytte på alt, ville det nok ikke virke så godt. Det vil jeg da lige prøve igen, da jeg ikke er vild med polling hvis det kan undgåes.

Jeg fik tid til det i aften alligevel, så nu kan jeg godt se at inputs også har en value i getRuntimeValue(id), der kortvarigt bliver sat til true når jeg trykker. Så nu kan jeg reagere på dem, men vil da fluks se om jeg ikke kan få interrupts til at virke istedet.

 

18 minutter siden, Mikkel Skovgaard skrev:

IHC captain er ikke en controller - det er pt. begge dele:

1. En måde nemt at opsætte overvågning på og trigger en handling - den handling kan være Sonos styring, køre en kommando lokalt, post noget web etc.
2. Remote "control" hvor man kan styre IHC controlleren

Det er det, jeg mener med controller. At det er dit program, der bestemmer hvad der skal ske - det er ikke blot et passivt interface. Det er præcist det samme, jeg laver - bortset fra at det er lavet i individuelle klumper (API'er der kan deployes til Docker) så at man kan bruge IHC delen uden de andre og vice versa. Ved ikke helt hvordan vi kom ind på dette. Der er ikke noget galt med at være controller. Problemet med mange (ikke din) løsninger er, at de alle gerne vil være 'master controller' og ikke lade andre styre dem udefra. Hvis bare alt havde et API, var jeg glad

[Troels Larsen1354922265]

Nå, indtil videre fandt jeg den, jeg stødte ind i sidste gang, i ResourceInteractionService:

- enableRuntimeValueNotifications(ArrayOfInt) //Liste af resurser, der skal notificeres
- waitForResourceValueChanges(Int) //timeout i sekunder

Så, ganske rigtigt:

1. Slå notifikationer til med enableRuntimeValueNotifications
2. Kald waitForResourceValueChanges, som giver værdier med det samme
3. Kald waitForResourceValueChanges, som ikke svarer før en værdi skifter eller timeouten udløber

Kan det passe, at jeg skal sende hele listen af både inputs og outputs med hvis jeg vil notificeres om det hele?

Tusinde tak for hjælpen allesammen, men især Mikkel. Dette er en lang bedre løsning ift. polling.

Nu skal jeg lige overveje hvad der skal hvis nogen trykker på en knap før jeg kan hooke en ny 'event handler' på.

[Troels Larsen1354922265]

3 timer siden, EjvindHald skrev:

Prøv at se på OpenHab2 - der er interfaces til rigtig meget inkl. IHC, z-wave, Hue, Homekit, Sonos, Pushover m.m. I OpenHab kan du på IHC aflæse og sætte ikke kun input og output moduler, mens også alle værdier i funktionsblokke. Jeg synes, at det er ret cool sammen med IHC, og det er tilgængelig bl.a. til Windows, RPI og Synology NAS server.

Hvis du ikke ønsker OpenHab, så kan du blot se i kildekoden på GitHub, hvordan bindingen til IHC er lavet. Herefter kan du implementere det samme i .Net - jeg formoder, at du udvikler i C#.

Tak for tippet. OpenHab var så venlige at dokumentere hvad parametrene til kaldene var. Det står ikke velbeskrevet i LK's WSDL, så det var en stor hjælp.

[Kristian Poulsen]

Troels

Du har misforstået noget, hvis du mener at det er nødvendigt at polle controlleren hele tiden.

API'et understøtter - ganske som Mikkel har beskrevet - at man "abonnerer" på en resource, og hvis denne resource skifter status, så får du et svar. Der ligger .net kode og beskrivelse på dette forum et eller andet sted - for jeg har selv skrevet det :-)

mvh

  Kristian

[Kristian Poulsen]

.Net kode finder du her

og en forklaring på side 5 i ovennævnte tråd - men ellers er den her:

Umiddelbart kan man ikke bruge events via Web Services, men LK har alligevel lavet noget smart.
Med metoden enableRuntimeValueNotifications sender man et array af resources som man gerne vil 'abonnere på'.
Herefter kalder man metoden waitForResourceValueChanges med ventetid i sekunder (typisk 10 sekunder) som parameter.
Metoden lytter så på events fra controlleren, og hvis der sker noget returnerer den et svar.
Hvis ikke så returneres et tomt svar når ventetiden udløber.

håber at det kan bruges ...

mvh

  Kristian

[EjvindHald]

20 timer siden, Troels Larsen1354922265 skrev:

Tak for tippet. OpenHab var så venlige at dokumentere hvad parametrene til kaldene var. Det står ikke velbeskrevet i LK's WSDL, så det var en stor hjælp.

Faktisk er Openhab open source, så dokumentationen og koden er ikke foretaget af dem. I stedet er det Pauli Anttila fra IHC-User.dk forum, som venligt har udviklet denne integration, så vi alle frit kan bruge det. Og både deres eget nye UI - Habpanel lavet af en person fra Frankrig - og Apple Homekit er i mine øjne meget brugervenlige.

[Troels Larsen1354922265]

22 timer siden, Kristian Poulsen skrev:

Troels

Du har misforstået noget, hvis du mener at det er nødvendigt at polle controlleren hele tiden.

API'et understøtter - ganske som Mikkel har beskrevet - at man "abonnerer" på en resource, og hvis denne resource skifter status, så får du et svar. Der ligger .net kode og beskrivelse på dette forum et eller andet sted - for jeg har selv skrevet det :-)

mvh

  Kristian

Jep, jeg fik det implementeret i går med både input og outputs, uden de store problemer. Men tak for tipsene.