Interface til OpenHAB

[rahbek]

Hej

Jeg har været ved at kigge på opensource hjemmeautomatisering. Et rigtig interessant bud er OpenHAB (http://openhab.org). Det består grundlæggende af en platform som kan holde styr på information om husets installationer og deres tilstande, styre disse ud fra brugerdefinerede regler, og stå for at forbinde en hel masse forskellige systemer, fx IHC, z-wave, multimedier og diverse cloud-tjenester. Mulighederne er som det fremgår af projektets side tæt på uendelige.

Systemet er modulbaseret, og kompatibilitet med nye systemer kan tilføjes i pakker kaldet "bindings", som der pt er over 40 af. Jeg synes det kunne være både interessant og oplagt at få lavet en binding til enten stokercloud, eller direkte til styringen.

En mulighed jeg har overvejet er at styre fyret ud fra en google kalender - det virker som en let, men effektiv måde at planlægge hvornår der fyres hvor meget.

Er det her noget der kunne interessere andre end mig?

Det der i første omgang mangler er pålidelig information om hvordan man interfacer til stokercloud. Det er relativt lige til at hive driftdata ud i json-format, og jeg kan også starte og stoppe fyret, samt afstille alarmer, men det er umiddelbart af en lidt kringlet vej, og det kunne være interessant at kunne sætte flere af værdierne, som man kan med stokercloud. Er der nogen som ligger ind med mere information, eller som har lyst til på anden måde at hjælpe til?

[BoinkUser]

Hej

Jeg har været ved at kigge på opensource hjemmeautomatisering. Et rigtig interessant bud er OpenHAB (http://openhab.org). Det består grundlæggende af en platform som kan holde styr på information om husets installationer og deres tilstande, styre disse ud fra brugerdefinerede regler, og stå for at forbinde en hel masse forskellige systemer, fx IHC, z-wave, multimedier og diverse cloud-tjenester. Mulighederne er som det fremgår af projektets side tæt på uendelige.

Systemet er modulbaseret, og kompatibilitet med nye systemer kan tilføjes i pakker kaldet "bindings", som der pt er over 40 af. Jeg synes det kunne være både interessant og oplagt at få lavet en binding til enten stokercloud, eller direkte til styringen.

En mulighed jeg har overvejet er at styre fyret ud fra en google kalender - det virker som en let, men effektiv måde at planlægge hvornår der fyres hvor meget.

Er det her noget der kunne interessere andre end mig?

Det der i første omgang mangler er pålidelig information om hvordan man interfacer til stokercloud. Det er relativt lige til at hive driftdata ud i json-format, og jeg kan også starte og stoppe fyret, samt afstille alarmer, men det er umiddelbart af en lidt kringlet vej, og det kunne være interessant at kunne sætte flere af værdierne, som man kan med stokercloud. Er der nogen som ligger ind med mere information, eller som har lyst til på anden måde at hjælpe til?

Hej Rahbek

Det ser spændende ud. Ja det kunne være rigtig fint med en binding til StokerCloud, nu har jeg ikke lige nærlæst det derinde, men måske du kan bruge en HTTP binding eller en af de andre, så du er fri for at lave en ny og så bare konfiguerere den op.

Du kan bruge en af disse til udtræk af data, formatet ligger fast, dog kan vi godt finde på at tilføje data hen ad vejen, men der bliver ikke flyttet/fjernet data.
json:
http://stokercloud.dk/dev/getdriftjson.php?mac=<brugernavn>
jsonp:
http://stokercloud.dk/dev/getdriftjson.php?mac=<brugernavn>&callback=myjsonpfunc

Det er ikke muligt at sætte parametre, men hvis du gerne vil prøve f.eks. med en "sæt kedeltemperatur", "start/stop fyr" så kan vi nok finde ud af det. Spørgsmålet er, hvad der er mest hensigtsmæssigt iforhold til openhab, der er jo igen grund til at komplicere det unødigt. Men helt alm. REST http post/get er til at håndtere for de fleste systemer, og så er der lidt med svaret du skal have tilbage.

Men prøv evt. at kigge lidt på det med udlæsning først, og se om det er noget der dur.

Er der noget du gerne vil vide, spørger du bare, helst på info@stokersoft.com.

Mvh. Jens

[motoz]

Sounds like a perfect match for the PellMon project. I see there is already an openHAB 'exec' binding that can execute arbitrary commands, that could be used together with PellMon's  command line interface right away to get read/write access to all control commands, measurement data and setting parameters in a scotte/woody v4/5/6. Or a new binding could be made for openHAB that uses the pellmon DBUS interface.

Jens, how about making that json data available locally? Home automation can't in my opinion rely on the uptime of external third party servers and internet connection for anything important.

[BoinkUser]

Sounds like a perfect match for the PellMon project. I see there is already an openHAB 'exec' binding that can execute arbitrary commands, that could be used together with PellMon's  command line interface right away to get read/write access to all control commands, measurement data and setting parameters in a scotte/woody v4/5/6. Or a new binding could be made for openHAB that uses the pellmon DBUS interface.

Jens, how about making that json data available locally? Home automation can't in my opinion rely on the uptime of external third party servers and internet connection for anything important.

Hi Motoz

We are currently not supporting direct calls to the control box, i do not think you should worry too much about connectivity, access through the cloud is an easy solution. Today we use Internet connections for about anything, my live stops when the Internet connection is down, so its by far more reliable than it was just years ago.

Regards Jens

[motoz]

I know you are currently not supporting local access, I was just expressing the need for it and fishing for something along the lines of "I can't promise anything but we are looking into implementing it in the future"...

I'm not in any way trying to imply that the NBE servers would be unreliable, but there is the principle of avoiding to depend on a single third party that can't be replaced if it ceases to exist in it's current form in the future, and the security aspect of having important equipment that can't be audited internet accessible. Plus of course the thing that much of the locally available functionality in the V6 is missing from the cloud.

As I see it there are lots of arguments for local access and only two against:
1) It would cost too much to implement and maintain it
2) Customer lock in is desired for business reasons, which does not make any sense at all as long as the service is free.

My bet is on number one, that's why I'm hoping for local access eventually when things settle with the new firmware.

(I suppose you don't mean your life literally stops when internet goes down, that would be the worst possible outcome of relying on internet connection for important functions, but it is a great illustration for my point...)

[rahbek]

Så kører det hele Både udlæsning af data og styring af fyr og temperatur. Det skal dog lige finpudses lidt før det kan frigives (brugernavn er pt hardcoded).

Jens, er der kontrol af om der sættes fornuftige værdier, enten i stokercloud eller selve styringen? Jeg tænker mest på kedeltemperatur (har ikke planer om at sætte andre værdier), den skal jo hverken kunne sættes for højt eller lavt (hvad bør grænserne være?)

Mvh rahbek

[BoinkUser]

Så kører det hele Både udlæsning af data og styring af fyr og temperatur. Det skal dog lige finpudses lidt før det kan frigives (brugernavn er pt hardcoded).

Jens, er der kontrol af om der sættes fornuftige værdier, enten i stokercloud eller selve styringen? Jeg tænker mest på kedeltemperatur (har ikke planer om at sætte andre værdier), den skal jo hverken kunne sættes for højt eller lavt (hvad bør grænserne være?)

Mvh rahbek

Hej Rahbek

Det lyder dælme godt, styringen accepterer ikke noget som ligger ud over grænserne, StokerCloud har også intern kontrol, som meget snart bliver visuel. Grænserne svinger fra version til version, hvis du går ind i styringsboksen kan du se dem.

Mvh. Jens

[perhansen]

Hvordan ser det ud med kommunikationen mellem OpenHAB og woody? Er udviklingen gået i stå? Jeg er pt. ved at implementere en OpenHAB-server til styring af mit IHC m.m og kunne derfor godt tænke mig at høre mere om bindingen op mod woody'en.

[BoinkUser]

Hvordan ser det ud med kommunikationen mellem OpenHAB og woody? Er udviklingen gået i stå? Jeg er pt. ved at implementere en OpenHAB-server til styring af mit IHC m.m og kunne derfor godt tænke mig at høre mere om bindingen op mod woody'en.

Jeg kender ikke endelig status på det, men du kan prøve at høre Rahbek, om du må prøve hans modul.

Mvh. Jens

[rahbek]

Hvordan ser det ud med kommunikationen mellem OpenHAB og woody? Er udviklingen gået i stå? Jeg er pt. ved at implementere en OpenHAB-server til styring af mit IHC m.m og kunne derfor godt tænke mig at høre mere om bindingen op mod woody'en.

Jeg er midt i en omfattende renovering af huset, og pillefyret er ved den lejlighed blevet flyttet og er endnu ikke sat til igen, så derfor er det gået lidt i stå. Det virker sådan set fint allerede (kan læse og sætte værdier i stokercloud, og fx starte og stoppe fyret) , jeg havde bare regnet med lige at rydde lidt op i det inden jeg lægger det op. Men hvis det har interesse kan jeg godt lægge det jeg har frem i mellemtiden?

Edit: Jeg er forøvrigt generelt meget imponeret over OpenHAB, det kan vitterligt snakke med alt, selvom det stadig kan være lidt kryptisk at sætte sig ind i første gang - men det er eftersigende noget af det der arbejdes på at forbedre. Vær opmærksom på at din java-installation skal have sikkerhedscertifikatet fra IHC-controlleren tilføjet, ellers kan der ikke oprettes SSL-forbindelse.

[motoz]

Seems as MQTT is a fast rising protocol for so colled 'internet-of-things' connectivity, and OpenHAB has an MQTT client binding here: https://github.com/openhab/openhab/wiki/MQTT-Binding

I tried cooking up a small test here: https://github.com/motoz/pellmonMQTT, where all data available in a scotte (as made available by PellMon) is published to an MQTT broker. Any client can then subscribe to the data they are interested in and will be updated on changes, listen2pellmon.py is a testprogram that subscribes to everything and prints data received.  It seems to work fine but not that useful yet (only outbound connection, no encryption...), it could probably be turned into something useful if there is interest.

A native MQTT client that can connect to the users choice of broker would make the V7/V10 box awesome! Please...

[BoinkUser]

Seems as MQTT is a fast rising protocol for so colled 'internet-of-things' connectivity, and OpenHAB has an MQTT client binding here: https://github.com/openhab/openhab/wiki/MQTT-Binding

I tried cooking up a small test here: https://github.com/motoz/pellmonMQTT, where all data available in a scotte (as made available by PellMon) is published to an MQTT broker. Any client can then subscribe to the data they are interested in and will be updated on changes, listen2pellmon.py is a testprogram that subscribes to everything and prints data received.  It seems to work fine but not that useful yet (only outbound connection, no encryption...), it could probably be turned into something useful if there is interest.

A native MQTT client that can connect to the users choice of broker would make the V7/V10 box awesome! Please...

Yes, it would be nice, no doubt about that.

What about a stokercloud MQTT client, you can connect to any broker, almost as nice, and much faster to implement.

Regards Jens

[motoz]

That would be great!!

Not quite as great as a 'local' client, but still great

[BoinkUser]

That would be great!!

Not quite as great as a 'local' client, but still great

I will take a look at it - no promises. Will also look at the complexity of introducing it in the local controlbox, but I might consider something even more simple for that.

Regards Jens

[motoz]

Super!

I'm fully aware of the complexities involved in re-architecting stuff that already works (ie. it's hardly ever a good idea), but from a quick outside view it seems as mqtt could fit perfectly as the main communication protocol between the control boxes and stokercloud, which would also act as a broker. The default 'just works' setting would be an encrypted authenticated connection to stokercloud, with an 'advanced' option to connect to any broker.

But hey, any simple local access api is great!