Bisher habe ich mit USB Logging gearbeitet und mir die Daten hin und wieder aufbereitet. Das ist mir aber auf die Dauer zu aufwendig und nützt mir auch nichts, wenn ich längere Zeit abwesend bin.
Varianten mit externer Software habe bisher nicht eingesetzt, weil bei den gängigen Lösungen ein 7/24 Rechner/Server + externe Software nötig sind. Und genau das will ich vermeiden.
Ich habe mich deshalb nach Clouddiensten umgesehen, die man evtl. für diesen Zweck einsetzen kann.
Dabei sollten folgende Kriterien erfüllt sein:
Kostenfrei
Einfache direkte Anbindung der CCU per Schnittstelle, die mit Boardmitteln möglich sind.
Ansprechendes, flexibles Äußeres
Prinzipiell bin ich bisher bei 3 Diensten fündig geworden, die man einsetzen könnte, wobei ich einen Dienst in die CCU integriert habe.
Der Dienst, den ich implementiert habe ist http://www.exosite.com
Hier mal eine Blick auf mein Portal, was ich mir dort eingerichtet habe.
- Bild 1: Mein Portal
- Exosite bietet neben kostenpflichtiger Nutzung auch eine freie eingeschränkte Nutzung, die für meine Zwecke ausreichend ist
- Exosite bietet sehr einfache APIs, die die Implementation in die CCU recht einfach gemacht haben. Neben HTTP ist auch HTTPS möglich.
- Eine eigene Seite (Portal-Seite) ist sehr schnell eingerichtet und schaut recht ansprechend aus (find ich jedenfalls)
Auf der Seite werden vorgefertigte Wigets plaziert, die die eigentlichen daten visualisieren. Hier sind neben Standardvorlagen auch Custom Vorlagen möglich, die z.B. die Daten mittels der Google-API visualisieren.
- Es sind Mail(SMS) Events möglich (die ich i.M. aber nicht nutze)
Ich habe die Seite inzwischen seit ca. 4 Wochen angebunden und konnte keine Probleme feststellen.
Wie gehts?
Achtung! Ich bringe hier keine Lösung, die sich 1:1 übernehmen läßt. Vielmehr soll diese Beispielimpementation als Vorlage für eigene Implementaionen dienen.
1. Bei exosite.com registrieren
2. Nach erfolgreicher Registrierung landet man nach dem Login immer auf seiner Portalseite. Die vorhandenen Widgets auf dem eigenen Portal kann man dann erstmal alle löschen.
3. Dann richtet man sich am Besten erst einmal ein DEVICES ein. Ein DEVICES bzw. die innerhalb des DEVICES angelegten DATAs können dann in den unterschiedlichsten Widgets visualisiert werden. Über die Organisation seiner Devices sollte man sich etwas Gedanken machen. In der freien Variante sind (glaub ich) max. 2 Devices mit je 3 Datenquellen (DATA) möglich. Man könnte z.B. einen Raum als ein Device definieren und darin Temperatur und Feuchtigkeit darstellen, die dann in einem Widget visualisiert werden können. Ich habe aber statt dessen ein Temperatur-DEVICE und ein Feuchte-DEVICE angelegt. So kann ich die Kurven 3er Räume jeweils in einen Temperatur-/Feuchtediagramm visualisieren.
- Bild 2: Temperaturdevice
Der dargestellte CIK funktioniert inzwischen natürlich nicht mehr
Das war nur ein Testdevice.4. Nun legt man seine Datenquellen für die jeweiligen Devices an
- Bild 3: Datenquelle
- Bild 4: Add Widget
Ok, soweit ist erstmal alles eingerichtet, was man für erste Tests benötigt.
Wie kommen nun die Daten rein?
Dazu muss man eine der angeboteten APIs bemühen. Hier findet man alle nötigen Infos:
http://exosite.com/products/onep/documentation?cid=517
Ich habe mich für das einfache HTTP - Interface entschieden, dass gleichermaßen HTTP uns HTTPS unterstützt. Dabei wird über ein simples HTTP-POST kommuniziert.
Um mal gleich ein Erfolgserlebnis zu haben kann man das Ganze im Terminal (Win/Mac/Linux sollte egal sein) mit WGET testen:
Code: Alles auswählen
wget --header='Content-Type: application/x-www-form-urlencoded; charset=utf-8' \
--header='X-Exosite-CIK: hier_muss_die_CIK_Ihres_Decvie_rein'\
--header='Content-Length: 11' \
--post-data 'WTemp=24.44' \
--timeout=10 \
http://m2.exosite.com/api:v1/stack/alias
Wenn alles geklappt hat, sollte der erste Punkt im Widget ihrer Portalseite auftauchen.
Natürlich kann auch CURL benutzt werden, damit sollte dann auch HTTPS klappen.
Ein Programm auf der CCU braucht eigentlich nur noch den Content-String (im Beispiel „WTemp=24.4“) aufbereiten und dann den WGET per SYSTEM
Zur Aufbereitung des Content-String benutze ich das allseits bekannte Script zum Wetterlogging auf USB, was bei mir sowieso zur Langzeitspeicherung mitläuft.
Da werden die interessierenden Wettersensoren rausgefiltert:
Achtung nur Programmauszug!
Code: Alles auswählen
if (vDevice == "WZKlima")
{
exTemp = exTemp + "&" + "HTemp=" + vIstWert;
exFeuchte = exFeuchte + "&" + "HHum=" + vFeuchte;
}
Code: Alles auswählen
! evtl & an der 1.Stelle entfernen
if (exTemp.Length() >1)
{
exTemp = exTemp.Substr(1);
}
if (exFeuchte.Length() >1)
{
exFeuchte = exFeuchte.Substr(1);
}
exTemp = '"'+exTemp+'"';
exFeuchte = '"'+exFeuchte+'"';
! an Exosite senden
system.Exec("tclsh /etc/config/sendexosite.tcl " + exTemp +" "+exFeuchte ,&out, &err);
Hier könnte eigentlich gleich mit WGET gearbeitet werden. Ein kleines TCL-Schript ist da aber für mich flexibler:
Code: Alles auswählen
# Aufruf tclsh sendexosite.tcl <SenddataTempTemperatur> <SenddataTempLuftfeuchte>
# tclsh sendexosite.tcl "WTemp=31" "WHum=55"
# tclsh sendexosite.tcl "GTemp=13.30&WTemp=18.60&HTemp=21.40" "GHum=95&WHum=61&HHum=61"
#
# http Package wird gebraucht
package require http 2
proc sendexo {url CIK Content} {
# Header aufbereiten
# -header besteht aus einer Liste vom Header-Paaren {"Content-Type" "application/x-www-form-urlencoded; charset=utf-8"}
# wird zu "Content-Type: application/x-www-form-urlencoded; charset=utf-8"
# Als letzte Headerzeile steht "Content-Length: <Anzahl der in dataTemp übergebenen Zeichen>"
#
# set head [concat {"Content-Type" "application/x-www-form-urlencoded; charset=utf-8" "X-Exosite-CIK" "0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1" "Content-Length"} [format %u [string length $Content]]]
# setzte den Returncode auf -1 (default)
set returnCode -1
set head [list "Content-Type" "application/x-www-form-urlencoded; charset=utf-8" "X-Exosite-CIK" $CIK "Content-Length" [format %u [string length $Content]]]
catch {
# Übertragung
set tok [http::geturl $url -query $Content -headers $head -type text/xml -channel stdout]
# ab HTTP package 2.5 gibt es dass Commando ncode, dass direkt den ReturnCode zurückgibt
# puts [http::ncode $tok]
# muss lauten:
# 204
# set returnCode [http::ncode $tok]
# HM hat das HTTP package V2.2 installiert, da gibt es noch kein ncode, hier kann der ReturnCode aus dem HTTP-Returnstring extrahiert werden
# Standard Return ist:
#
# HTTP/1.1 204 No Content
#
#
# Der Returncode ist dann das 2. Listelement
set returnCode [lindex [split [http::code $tok]] 1]
# puts $returnCode
# löscht das array tok
http::cleanup $tok
}
return $returnCode
}
# exosite url
set url "http://m2.exosite.com/api:v1/stack/alias"
#-----------------------------------------------------------------------
# Temperatur DEVICE bedienen (returnCode wird derzeit nicht ausgewertet)
# Content Temperatur wird als 1. Parameter übernommem
set Content [lindex $argv 0]
# Temperatur CIK
set CIK "Hier_die_CIK_FÜR_DAS Temperatur_DEVICE_rein"
set ret [sendexo $url $CIK $Content]
#puts "ReturnCode: $ret"
#----------------------------------------------------------------------
# Feuchte DEVICE bedienen (returnCode wird derzeit nicht ausgewertet)
# Feuchte wird als 2. Parameter übernommem
set Content [lindex $argv 1]
# Feuchte CIK
set CIK "Hier_die_CIK_FÜR_DAS Feuchte_DEVICE_rein"
set ret [sendexo $url $CIK $Content]
#puts "ReturnCode: $ret"
Ich bin jetzt nicht so der große TCL Hacker, da gibt es bestimmt noch einiges zu verbessern.
Vielleicht greift jemand die Idee auf und das Ganze entwickelt sich noch etwas:
Folgende Dinge kann ich mir noch vorstellen:
- Umstellung auf HTTPS (hab ich in TCL aber keine Erfahrung)
- Auswertung ReturnCode und bei Fehler ein Eintrag ins Syslog oder gar eine Mail.
rewe0815
