Interface > Online systemer

Interface til OpenHAB

(1/7) > >>

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:

--- Citat fra: rahbek efter Jan 08, 2014, 12:32 ---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?

--- Afslutning på citat ---

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:

--- Citat fra: motoz efter Jan 09, 2014, 06:33 ---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.

--- Afslutning på citat ---

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...)

Navigering

[0] Emneindeks

[#] Næste side