Web-Based-Sensors: Sensordaten (z.B. temperatur) per http nach FHEM
Axel
bei mir sind zwei Module aus einer "Bastelei" entstanden:
18_WBS.pm und 99_CGI_RAWMSG.pm
In Kombination der beiden Module kann man Sensordaten per HTTP-Aufruf
bei FHEM-Abgeben.
Die Daten werden von FHEM behandelt, als ob sie von einem "normalen"
IODEV (z.B. CUL) stammen.
Die Abgabe erfolgt dann über: http://[FHEMWEB]/fhem/rawmsg?DATEN
Aktuelle unterstützt werden die Formate WBS,CUL_WS und HMS.
Beispiele:
HMS -> http://[FHEMWEB]/fhem/rawmsg?810e04e60511a00123b8000001510200
CUL_WS -> http://[FHEMWEB]/fhem/rawmsg?K310582483C
WBS (Web Based Sensors):
[FHEM] -> define WBS001 WBS Temperature 1032D8ED01080011
[FHEM]# $defs$defs{WBS001}{TYPE} = WBS
[FHEM]# $defs$defs{WBS001}{CODE} = 1032D8ED01080011
[FHEM]# $defs{WBS001}{READINGS}{Temperature}{VAL} = 0
[FHEM]# $defs{WBS001}{READINGS}{Temperature}{TIME} = TimeNow()
[UPDATE]MSG-Format: WBS:SENSOR-CODE:VALUE
[UPDATE] -> WBS:1032D8ED01080011:23.32
Allgemein: define <NAME> WBS TYPE CODE
TYPE: Aus dem Type wird das READING....hier ist alles "erlaubt"
CODE: Muss eindeutig sein...bzw. kann frei gewählt werden, darf aber
nur einmal vorkommen
Und wofür.....
Ich lese (bald ;-) ) 6 OneWire-Tempsensoren per Arduino-Board aus.
Die Daten werde ich dann per HTTP nach FHEM "schicken":
http://[FHEMWEB_LAN]/fhem/rawmsg?WBS:1032D8ED01080011:23.98
Oder...
Aus der Wiki-Diskussion...Temperaturen "meines" Root-Servers (= Feste-
IP)
- [Mein_Router] FirewallRegel: Source-IP = IP-Root-server -> Dest-IP->
FHEMWEB Port:xxxx
- [FHEM] define ROOT001_TEMP WBS Temperature 1001
- [ROOTSRV] Temp auslesen = 35.38
- [ROOTSRV] curl -d 'rawmsg?WBS:1001:35.38' http://[URL_FHEM]/
Wollte mal hören ob jemand interesse hat....
Dann würd ich's per CVS zum testen bereitsellen....
Schöne Grüße
Axel
Kai 'wusel' Siering
> bei mir sind zwei Module aus einer "Bastelei" entstanden:
> 18_WBS.pm und 99_CGI_RAWMSG.pm
>
> In Kombination der beiden Module kann man Sensordaten per HTTP-Aufruf
> bei FHEM-Abgeben.
cool!
> Die Daten werden von FHEM behandelt, als ob sie von einem "normalen"
> IODEV (z.B. CUL) stammen.
> Die Abgabe erfolgt dann über: http://[FHEMWEB]/fhem/rawmsg?DATEN
> Aktuelle unterstützt werden die Formate WBS,CUL_WS und HMS.
> Beispiele:
> HMS -> http://[FHEMWEB]/fhem/rawmsg?810e04e60511a00123b8000001510200
> CUL_WS -> http://[FHEMWEB]/fhem/rawmsg?K310582483C
> WBS (Web Based Sensors):
[...]
Ist denn unterscheidbar, von wo (echter CUL oder Web-CUL) die Daten
kommen? Sprich, mit welchem IODev kommt das bei FHEM an? (Das wäre
z. B. wichtig für CUL_WS, nicht daß mir externe, von keinem meiner
CULs empfangbare S300TH dann meine lokalen Daten zermarmeln.)
> Allgemein: define <NAME> WBS TYPE CODE
> TYPE: Aus dem Type wird das READING....hier ist alles "erlaubt"
> CODE: Muss eindeutig sein...bzw. kann frei gewählt werden, darf aber
> nur einmal vorkommen
>
> Und wofür.....
> Ich lese (bald ;-) ) 6 OneWire-Tempsensoren per Arduino-Board aus.
> Die Daten werde ich dann per HTTP nach FHEM "schicken":
> http://[FHEMWEB_LAN]/fhem/rawmsg?WBS:1032D8ED01080011:23.98
Nette Idee. 1-Wire habe ich auch an einem meiner Server im RZ, das
nach FHEM zu bekommen auf diesem Weg wäre schon charmant weil ohne
großen Aufwand dort realisierbar. => Bitte einchecken ;)
Hmm, eine Authentisierung siehst Du nicht vor/überläßt Du dem vor-
geschalteten Indianer? Ist rawmsg unabhängig von pgm2 nutzbar oder
setzt es dessen Aktivierung zwingend voraus?
MfG,
kai
Axel
ist im CVS.../fhem/contrib/WBS
18_WBS.pm und 99_CGI_RAWMSG.pm
also testen und Feedback ;-))
Ist alles noch BETA ;-))
Hier ist auf jeden Fall noch was zu tun....
> Ist denn unterscheidbar, von wo (echter CUL oder Web-CUL) die Daten kommen?
Ich hoffe ;-))
99_CGI_RAWMSG.pm legt automatisch eine "pseudo"-Device an.
Das schaut dann so aus:
CGI_RAWMSG_MSGCNT 1
CGI_RAWMSG_TIME 2009-12-30 14:24:46
NAME CGI_RAWMSG
NR 2
RAWMSG WBS:1032D8ED01080011:12.98
STATE AKTIV 99_CGI_RAWMSG
TYPE CGI_RAWMSG
fhem scheint das Device allerdings noch nicht soo richtig zu
akzeptieren...
Es wurden keine IODEV-Daten (MSGCNT etc.) nach WBS001 geschrieben....
> CULs empfangbare S300TH dann meine lokalen Daten zermarmeln.)
Dafür hatte ich 18_WBS gedacht...
Damit definiert man Sensoren die NUR per HTTP-daten "empfangen"
können.
CUL/FHZ und Konsorten kennen das Format WBS:* nicht...
HSM und CUL_WS rawmsg per HTTP...da dachte ich eher an FHEM zu FHEM
oder sowas....
Oder vieleicht ins ganz weiter Zukunft...der CUN könnte sowas...
Wenn du dir z.B. `nen CUN und ein paar HMS/CUL_WS in "dein" RZ oder
Ferienhaus (oder sonst wo) stellst und dann die Daten zu Hause haben
willst... ;-)))
> Nette Idee. 1-Wire habe ich auch an einem meiner Server im RZ,
Also...bei den Module ist keine OneWire-Umsetzung dabei...bitte nicht
missverstehen.
Die Umsetzung OneWire-daten auf HTTP macht bei dann das Arduino-Board
NICHT FHEM.
Authentisierung = keine
>rawmsg unabhängig von pgm2
Aktuelle Nein...läuft NUR mit pgm2/FHEMWEB...
Hatte bei der Entwicklung auch schon mit Rudi gemailt...
Rudi schlug auch eine unabhängige Implamentierung um...d.h. auf
eigenem Port.
Wenn da Intersse da ist...kann ichs gerne versuchen ;-))
Und dann bei Authentisierung...an was denkst du da ?
? IP-Adresse und/oder Username/Pwd ??
Schöne Grüße
Axel
Kai 'wusel' Siering
Axel wrote:
> ist im CVS.../fhem/contrib/WBS
> 18_WBS.pm und 99_CGI_RAWMSG.pm
>
> also testen und Feedback ;-))
Cool; komme heute wohl nicht mehr dazu, aber vielleicht noch morgen kurz :)
>> CULs empfangbare S300TH dann meine lokalen Daten zermarmeln.)
> Daf�r hatte ich 18_WBS gedacht...
> Damit definiert man Sensoren die NUR per HTTP-daten "empfangen"
> k�nnen.
> CUL/FHZ und Konsorten kennen das Format WBS:* nicht...
> HSM und CUL_WS rawmsg per HTTP...da dachte ich eher an FHEM zu FHEM
> oder sowas....
> Oder vieleicht ins ganz weiter Zukunft...der CUN k�nnte sowas...
> Wenn du dir z.B. `nen CUN und ein paar HMS/CUL_WS in "dein" RZ oder
> Ferienhaus (oder sonst wo) stellst und dann die Daten zu Hause haben
> willst... ;-)))
Also, wenn ich den CUN erreichen kann (und daf�r sorgt im Zweifel das
openvpn auf der Fritzbox ;)), geht das ja auch jetzt schon. Aber ein
HTTP-Interface zum "abladen" von Daten finde ich generell praktisch.
>> Nette Idee. 1-Wire habe ich auch an einem meiner Server im RZ,
> Also...bei den Module ist keine OneWire-Umsetzung dabei...bitte nicht
> missverstehen.
Nee, schon klar; ich mache bislang digitemp_$irgendas und parse das,
da k�me jetzt einfach ein wget-Aufruf dazu ...
> Authentisierung = keine
Dar�ber sollten wir vielleicht noch mal reden ;)
>> rawmsg unabh�ngig von pgm2
> Aktuelle Nein...l�uft NUR mit pgm2/FHEMWEB...
Ack, klang so ;)
> Hatte bei der Entwicklung auch schon mit Rudi gemailt...
> Rudi schlug auch eine unabh�ngige Implamentierung um...d.h. auf
> eigenem Port.
> Wenn da Intersse da ist...kann ichs gerne versuchen ;-))
> Und dann bei Authentisierung...an was denkst du da ?
> ? IP-Adresse und/oder Username/Pwd ??
Naja, den Pfad kann ich ja im Apachen auf Quellhosts oder gar per BasicAuth
absichern. Wenn man keinen Webserver vor FHEM stehen haben will (z. B. weil
Host zu schwach), dann w�re ein eigenst�ndiges Modul sinnig, andererseits
fri�t FHEMWEB auch nicht viel Ressourcen, solange es nicht angesprochen wird,
oder? Mal abwarten w�rde ich sagen.
kai
Martin Fischer
> [...]
> Nette Idee. 1-Wire habe ich auch an einem meiner Server im RZ, das
> nach FHEM zu bekommen auf diesem Weg wäre schon charmant weil ohne
> großen Aufwand dort realisierbar. => Bitte einchecken ;)
nur mal so als idee:
auf deinem server owfs installieren und auf deinem fhem-rechner ebenfalls.
dann kannst du über die owfs-server auf auf remote-owfs-server zugreifen.
21_OWTEMP.pm als vorlage nehmen, um dann ein modul für den entsprechenden
sensor zu bauen.
Axel
>fhem scheint das Device allerdings noch nicht soo richtig zu akzeptieren...
>Es wurden keine IODEV-Daten (MSGCNT etc.) nach WBS001 geschrieben....
Natürlich lags nicht an FHEM ;-))
Also dass funktioniert nun...die IODEV-Informationen werden
geschrieben:
CGI_RAWMSG_MSGCNT 1
CGI_RAWMSG_RAWMSG WBS:1032D8ED01080011:12.28
CGI_RAWMSG_TIME 2009-12-30 20:48:59
D.h. man erkennt jetzt wer die Msg "einliefert"....
Axel
Kai 'wusel' Siering
>> Nette Idee. 1-Wire habe ich auch an einem meiner Server im RZ, das
>> nach FHEM zu bekommen auf diesem Weg w�re schon charmant weil ohne
>> gro�en Aufwand dort realisierbar. => Bitte einchecken ;)
>
> nur mal so als idee:
>
> auf deinem server owfs installieren und auf deinem fhem-rechner ebenfalls.
Klar, aber ich schrieb ja schon "ohne gro�en Aufwand":
Die digitemp-cron-L�sung rennt; owfs w�re nachzuinstallieren (Pakete vor-
handen?).
Mit digitemp-cron sende ich die Updates, wenn welche da sind (triggere
schon jetzt Scripte, die die Werte nach rrd schaufeln); owfs w�rde da
pollen, finde ich generell nicht so sch�n. Insbesondere funktioniert die
L�sung mit digitemp seit Jahren stabil; zu owfs auf dem System kann ich
keine Aussagen machen.
kai
Manfred Caspari
> Insbesondere funktioniert die Lï¿œsung mit digitemp seit Jahren stabil;
> zu owfs auf dem System kann ich keine Aussagen machen.
Vielleicht bringst Du Deine Lï¿œsung mit Digitemp ins Wiki ein? :)
was mir an der owfs-lï¿œsung nicht gefï¿œllt: Der WAF des Gesammtsystems
fï¿œllt. Ich habe 7 DS1820, wovon 3 alle 10sec, einer alle 60sec und drei
weitere alle 5min gepollt werden. Die Response auf Fernbedienbefehle ist
deutlich hï¿œher geworden :(
Grￜￜe,
Manfred
Martin Fischer
> [...]
> > ebenfalls.
>
>
> Die digitemp-cron-Lösung rennt; owfs wäre nachzuinstallieren (Pakete vor-
> handen?).
pakete habe ich in meinem ppa für ubuntu bereit gestellt:
https://launchpad.net/~mfischer/+archive/ppa
> Mit digitemp-cron sende ich die Updates, wenn welche da sind (triggere
> schon jetzt Scripte, die die Werte nach rrd schaufeln); owfs würde da
> pollen, finde ich generell nicht so schön. Insbesondere funktioniert die
> Lösung mit digitemp seit Jahren stabil; zu owfs auf dem System kann ich
> keine Aussagen machen.
ich habe das auch jahre mit digitemp gemacht. dagegen spricht absolut nichts.
Martin Fischer
> Kai 'wusel' Siering schrieb:
> > zu owfs auf dem System kann ich keine Aussagen machen.
>
genau :-)
> was mir an der owfs-lösung nicht gefällt: Der WAF des Gesammtsystems
> fällt. Ich habe 7 DS1820, wovon 3 alle 10sec, einer alle 60sec und drei
> weitere alle 5min gepollt werden. Die Response auf Fernbedienbefehle ist
> deutlich höher geworden :(
in der tat! da hast du absolut recht und das ist unschön. bei mir fällt das
nicht so in's gewicht, da ich nur alle 5 mins polle.
leider ist das technisch bedingt: vereinfacht gesagt "laden" sich ja die
sensoren beim pollen auf um mit der spannung dann die temperatur zu berechnen
und zu senden. und genau das "bremst" das ganze dann aus.
das verhält sich zumindest so im parasitärmodus. bisher habe ich aus
zeitgründen noch keine externe spannung in den bus gespeist. wäre halt
interessant ob sich dann das zeitliche verhalten verringert.
aber: es hängt auch stark von den sensoren ab! ein DS18S20 liefert die daten
als 12bit paket. der DS18B20 kann als kleinste grösse auch 9bit. ich habe zwar
rund 10 von den DS18B20 liegen um das verhalten mal zu beobachten, bin aber
noch nicht dazu gekommen.
eine andere alternative wäre fhem multithreading beizubringen, so dass diese
"jobs" parallel ausgeführt werden ohne das es einfluss auf das pushen von
anderen modulen hat.
Olaf Droegehorn
auch wenns hart am off-topic ist:
Die meisten Perl-Installationen auf Embedded-Ger�ten verf�gen NICHT �ber
multi-thread Funktionalit�t.
Und soweit ich es verstanden habe gab es einige Gr�nde, FHEM bis dato
single-threaded zu halten.
Ansonsten sind die Digi-Temps sicher eine interessante Erweiterung.
Ein �hnliches Problem habe ich mit dem Rendern von Grafiken, dass im
Hintergrund geschehen soll. Solgane FHEM Grafiken bastelt ist der
Prozess auch blockiert.
Wenn ich mich recht entsinne k�nnte ein fork in einen zweiten Prozess
gehen, oder ?
Gru�,
Olaf
Martin Fischer schrieb:
> Am Donnerstag 31 Dezember 2009 schrieb Manfred Caspari:
>> Kai 'wusel' Siering schrieb:
>>> Insbesondere funktioniert die L�sung mit digitemp seit Jahren stabil;
>>> zu owfs auf dem System kann ich keine Aussagen machen.
>> Vielleicht bringst Du Deine L�sung mit Digitemp ins Wiki ein? :)
>
> genau :-)
>
>> was mir an der owfs-l�sung nicht gef�llt: Der WAF des Gesammtsystems
>> f�llt. Ich habe 7 DS1820, wovon 3 alle 10sec, einer alle 60sec und drei
>> weitere alle 5min gepollt werden. Die Response auf Fernbedienbefehle ist
>> deutlich h�her geworden :(
>
> in der tat! da hast du absolut recht und das ist unsch�n. bei mir f�llt das
> nicht so in's gewicht, da ich nur alle 5 mins polle.
>
> leider ist das technisch bedingt: vereinfacht gesagt "laden" sich ja die
> sensoren beim pollen auf um mit der spannung dann die temperatur zu berechnen
> und zu senden. und genau das "bremst" das ganze dann aus.
>
> das verh�lt sich zumindest so im parasit�rmodus. bisher habe ich aus
> zeitgr�nden noch keine externe spannung in den bus gespeist. w�re halt
> interessant ob sich dann das zeitliche verhalten verringert.
>
> aber: es h�ngt auch stark von den sensoren ab! ein DS18S20 liefert die daten
> als 12bit paket. der DS18B20 kann als kleinste gr�sse auch 9bit. ich habe zwar
> rund 10 von den DS18B20 liegen um das verhalten mal zu beobachten, bin aber
> noch nicht dazu gekommen.
>
> eine andere alternative w�re fhem multithreading beizubringen, so dass diese
> "jobs" parallel ausgef�hrt werden ohne das es einfluss auf das pushen von
> anderen modulen hat.
>
Kai 'wusel' Siering
Martin Fischer wrote:
>> Die digitemp-cron-L�sung rennt; owfs w�re nachzuinstallieren (Pakete vor-
>> handen?).
>
> pakete habe ich in meinem ppa f�r ubuntu bereit gestellt:
> https://launchpad.net/~mfischer/+archive/ppa
Die fragliche Kiste ist'n Etch ;)
> ich habe das auch jahre mit digitemp gemacht. dagegen spricht absolut nichts.
Eben; ich bin bei Servern schon ein Freund von �never touch ...�,
zumal da ein paar VMs drauf laufen. OWFS ist, IIRC, zwar Userspace,
aber warum ein Risiko eingehen, wenn es auch per wget ginge. OWFS
werde ich wohl im LAN einsetzen, ins WAN ist mir das (schon wg. der
Downtime w�hrend Zwangstrennung) noch zu heikel (lies: ich kenne es
nicht genug).
kai
Rudolf Koenig
> single-threaded zu halten.
Da gibt es zwei Gruende:
- perl mit threads sind (waren?) kompliziert zu installieren.
- thread-Programmierung finde ich kompliziert und Fehler schwer zu finden wegen
der schwer zu reproduzierenden Nebenlaeufigkeit, insb. wenn man auf die
gleichen Datenstrukturen zugreift.
> Wenn ich mich recht entsinne k�nnte ein fork in einen zweiten Prozess
> gehen, oder ?
Ich ziehe zwar fork (d.h. mehrere Prozesse) dem threads vor (habe gerade fork
in 01_FHEMWEB.pm fuer showlog eingebaut), fuer blockierendes Lesen ist aber
einfacher den globalen select mit dem Warten zu beauftragen, so wie andere
Module wie 00_CUL.pm / 00_FHZ.pm es auch tun. Bei Bedarf kann ich helfen den
Code mit select zu begluecken.
Gruss,
Rudi
Martin Fischer
> [...]
>
> Ich ziehe zwar fork (d.h. mehrere Prozesse) dem threads vor (habe gerade
> fork in 01_FHEMWEB.pm fuer showlog eingebaut), fuer blockierendes Lesen
> ist aber einfacher den globalen select mit dem Warten zu beauftragen, so
> wie andere Module wie 00_CUL.pm / 00_FHZ.pm es auch tun. Bei Bedarf kann
> ich helfen den Code mit select zu begluecken.
vielleicht sollten wir uns das mal mit owfs ansehen. ich habe da so meine
bedenken, wenn jemand fhem mit 33 sensoren betreiben will und jeder benötigt
mehrere sekunden zum auslesen. das könnte fhem dann schon mal totlegen.
Martin Fischer
>
> Martin Fischer wrote:
> >> Die digitemp-cron-Lösung rennt; owfs wäre nachzuinstallieren (Pakete
> >> vor- handen?).
> >
> > pakete habe ich in meinem ppa für ubuntu bereit gestellt:
anyway.. sourcen stehen doch auch im ppa.. nur noch ein build unter etch
ausführen :-) sollte wohl klappen..
Rudolf Koenig
> mehrere sekunden zum auslesen. das k�nnte fhem dann schon mal totlegen.
Habs auf meine TODO geschrieben, kann aber etwas dauern, weil es mehr Zeit
erfordert.
Kai 'wusel' Siering
Da ich die Ansynchronit�t f�r das Auslesen f�r die WS3600-Geschichte schon
zusammengestrickt habe (bin nur noch nicht �berzeugt vom Timing des fhem-
internen schedulings; imho m��te da viel fr�her die entspr. Routine wieder
aufgerufen werden), vielleicht liesse sich davon was �bernehmen?
kai
Martin Fischer
> > vielleicht sollten wir uns das mal mit owfs ansehen. ich habe da so meine
> > bedenken, wenn jemand fhem mit 33 sensoren betreiben will und jeder
> > totlegen.
>
> Habs auf meine TODO geschrieben, kann aber etwas dauern, weil es mehr Zeit
> erfordert.
selbiges sollten wir evtl. auch für X10 machen. ich habe ab- und an mal das
problem, das sich CM11 weghängt und dann bis zum timeout alles tot ist.
aber auch wenn CM11 nicht tot ist passiert das:
beispiel:
3 deckenlampen werden angesteuert. 2 über einen fs20 dimmer und einer über
einen x10 dimmer. die fs20er reagieren beim ein- und ausschalten deutlich
versetzt.
aber eigentlich gehört das in einen anderen thread :-)
Martin Fischer
> Rudolf Koenig wrote:
> >> vielleicht sollten wir uns das mal mit owfs ansehen. ich habe da so
> >> meine bedenken, wenn jemand fhem mit 33 sensoren betreiben will und
> >> mal totlegen.
> >
> > Habs auf meine TODO geschrieben, kann aber etwas dauern, weil es mehr
> > Zeit erfordert.
>
> zusammengestrickt habe (bin nur noch nicht überzeugt vom Timing des fhem-
> internen schedulings; imho müßte da viel früher die entspr. Routine wieder
> aufgerufen werden), vielleicht liesse sich davon was übernehmen?
ich werds mir auch bei gelegenheit mal ansehen. aktuell habe ich gerade die
zeit gefunden mal wieder myHCE weiter zu entwickeln. sieht schon ganz nett aus
:-)