Originally posted by: <email address deleted>
Hallo Zusammen,
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 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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Moin,
> 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 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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Hallo Kai,
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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Salve.
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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Mittwoch 30 Dezember 2009 schrieb 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.
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.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Hallo Zusammen,
>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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Martin Fischer wrote:
>> 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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
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? :)
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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Donnerstag 31 Dezember 2009 schrieb Kai 'wusel' Siering:
> [...]
> > 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?).
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.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
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.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Hi all,
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.
>
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Moin,
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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> Und soweit ich es verstanden habe gab es einige Gründe, FHEM bis dato
> 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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Freitag 01 Januar 2010 schrieb Rudolf Koenig:
> [...]
>
> 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.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Donnerstag 31 Dezember 2009 schrieb Kai 'wusel' Siering:
> Moin,
>
> 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 ;)
anyway.. sourcen stehen doch auch im ppa.. nur noch ein build unter etch
ausführen :-) sollte wohl klappen..
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> 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.
Habs auf meine TODO geschrieben, kann aber etwas dauern, weil es mehr Zeit
erfordert.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
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 jeder benötigt
>> 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.
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
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Montag 04 Januar 2010 schrieb Rudolf Koenig:
> > 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.
>
> 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 :-)
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am Montag 04 Januar 2010 schrieb Kai 'wusel' Siering:
> 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
> >> jeder benötigt 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.
>
> 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?
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
:-)
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Hallo Axel,
hast du zufällig noch den Arduino Sketch und den FHEM Code für deine Lösung?
Ich würde das nämlich gerne (fast) genauso umsetzen, aber habe noch nichts
brauchbares gefunden..
siehe:
https://groups.google.com/forum/?fromgroups#!topic/fhem-users/4Oq-j90Hefw
Das würde mir sehr weiterhelfen!
Vielen Dank schonmal.
Gruß,
Alex
...
ich suche nach einer Möglichkeit* Temperaturdaten,* welche von *DS1820*1-Wire Sensoren erfasst und an ein
*Arduino Ethernet Board* übermittelt werden in *FHEM* einzubinden.
Mir fehlt momentan der* passende Sketch für das Arduino,* sowie der *Code
für FHEM*.
Was ich bereits habe ist die Temperaturübermittlung der Daten der DS1820 an
den seriellen Monitor des Arduino. (das funktioniert einwandfrei)
...
Am Mittwoch, 30. Dezember 2009 10:48:05 UTC+1 schrieb Axel:
> Hallo Zusammen,
>
> 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 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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com