1-wire und gemeinsames plotten mehrerer Devices
Georg
Großes Lob erstmal für FHEM - ich beschäftige mich erst seit gestern
damit und etliches läuft schon sehr gut, insbesondere der CUNO +
autocreate der FS20/FHTs devices. Daran sieht man dann auch schön, wie
andere Devices wie z.B. 1-Wire (die bei mir noch nicht am CUNO hängen,
sondern an einem 9097U) konfigurieren muss. Folgende Themen habe ich
aber noch:
- Jeder Temperatursensor ist derzeit ein Device, schreibt per OWTEMP
in sein eigenes FileLog, aus dem dann ein eigenes .gplot mit einer
Temperaturkurve gezeichnet wird. Ich habe aber z.B. Heizungsvor- und
rücklauf (je ein Sensor), die ich gern gemeinsam plotten würde. In
der .gplot könnte ich das konfigurieren, wenn ich die Daten der beiden
Sensoren in ein gemeinsames FileLog bekäme. Das aber schaffe ich
nicht... Muss ich in mysql loggen? Oder ändere ich einfacher das
OWTEMP ab, damit es gleich mehrere Sensoren abfragt und in ein
gemeinsames FileLog schreibt (ich würde die also quasi als ein Device
konfigurieren und dann die Adressen in das OWTEMP schreiben)? Bei FHTs
werden ja auch mehrere Werte geloggt.
- Ein ziemliches Verständnisproblem habe ich noch bzgl. 1-wire: Könnte
man nicht die derzeitige Beschränkung auf Temperatursensoren umgehen,
indem man einfach die Sensoren mit dem Programm OWREAD abfragt, das
Bestandteil des Pakets OWFS ist? Das machte ich bislang so
(webminstats custom module + rrd) und das scheint vielseitiger, denn
der Befehl:
"/usr/local/bin/owread -s localhost:3003 /10.0FC300020800/temperature"
gibt dann z.B. "45.2343" aus, was die Temperatur in Celsius ist. Der
Befehl:
"/etc/webmin/sysstats/modules/custom-0.10/gasincrem.sh" zeigt bei mir
auf eine inkrementelle oder gesamte Auswertung des Gaszählers per Reed-
Kontakt und 1-wire Zähler (batteriegepufferter DS2423) an. Hier mal
der Zählerstand, wobei ich einfach vom Ausgangswert aus die
Zählerwerte aufaddiere (Z ist ein Korrekturfaktor, weil der Magnet in
meinem Zähler auf einer weit rechts sitzenden Scheibe sitzt und
entsprechend kleine Teilmengen zählt...):
"#!/bin/sh
# Verbrauch insgesamt (Zählerstand war bei 13947.35)
X=13947.35
Y=$(/usr/local/bin/owread -s localhost:3003 /1D.746D07000000/
counters.A)
Z=100
echo "$X+($Y/$Z)" | bc -l"
Hier noch die inkrementelle Auswertung (die zeigt mir aktuellen
Gasverbrauch an, ich sehe daran z.B. Brennerstarts der Heizung - nur
die baucht bei uns Gas):
"#!/bin/sh
# Inkrementeller Verbrauch
X=$(/usr/local/bin/owread -s localhost:3003 /1D.746D07000000/
counters.A)
Y=30
echo "$X*$Y" | bc"
Was ich nur zeigen will ist, dass sich Zähler mit OWREAD ganz ähnlich
wie der Temperatursensor oben abgefragt wird.
Jetzt würde ich das gern in FHEM integrieren, bin aber leider
absoluter PERL-Anfänger und würde mich über Tipps freuen, wie ich so
etwas einbinde. Beim Suchen in der Gruppe habe ich auch schon etwas
gefunden, nämlich sinngemäß für meinen Temperatursensor oben (wenn ich
das korrekt übertragen habe):
"define HeizVL_tmp_at at +*00:05 {\
my $a=`/usr/local/bin/owread -s localhost:3003 /10.0FC300020800/
temperature`;;\
DoTrigger("global", "T: $a")\
} "
Wenn das so stimmt, schreibt man das einfach in die fhem.cfg oder baut
man sich besser ein extra .pm?
Fragen über Fragen - bin halt Grünschnabel :-)
Vielen Dank jedenfalls für Eure Hilfe!
Georg
Rudolf Koenig
> wenn ich die Daten der beiden Sensoren in ein gemeinsames FileLog bek�me.
Dem FileLog kann man per regexp sagen, was er loggen soll. Beipiel:
define owtemp1 ...
define owtemp2 ...
define multiLog FileLog /tmp/multi-%Y.log owtemp1|owtemp2
Siehe auch http://fhem.de/commandref.html#FileLog
> "define HeizVL_tmp_at at +*00:05 {\
> my $a=`/usr/local/bin/owread -s localhost:3003 /10.0FC300020800/
> temperature`;;\
> DoTrigger("global", "T: $a")\
>
> } "
Statt "global" wuerde ich den Namen eines anderen definierten Geraetes nehmen,
notalls kann man ja auch ein dummy definieren.
> Wenn das so stimmt, schreibt man das einfach in die fhem.cfg oder baut
> man sich besser ein extra .pm?
Fuer einfache Sachen fhem.cfg, fuer komplexere eher ein .pm. Wo die Grenze
liegt darf jeder fuer sich entscheiden :)
Fhem intern sollte man InternalTimer() verwenden statt "at", Beispiele gibt es
viele in den vorhandenen Modulen.
Gruss,
Rudi
P.S. owfs fragen muessen die anderen beantworten, ich hab kein OneWire.
Georg
> Dem FileLog kann man per regexp sagen, was er loggen soll. Beipiel:
> define owtemp1 ...
> define owtemp2 ...
> define multiLog FileLog /tmp/multi-%Y.log owtemp1|owtemp2
> Siehe auchhttp://fhem.de/commandref.html#FileLog
überlesen...
> Statt "global" wuerde ich den Namen eines anderen definierten Geraetes nehmen,
> notalls kann man ja auch ein dummy definieren.
> P.S. owfs fragen muessen die anderen beantworten, ich hab kein OneWire.
oben ein localhost:3003 steht, weil ich auf meinem Guruplug einen
owserver laufen habe, der auch Bestandteil von OWFS ist und die
Anfragen sortiert / Timingprobleme verhindert -> http://owfs.sourceforge.net/owserver.1.html
Schönen Sonntag noch!
Georg
Martin Fischer
Am Sonntag 13 März 2011 schrieb Georg:
> [...]
> > danke, probiere ich!
>
> > P.S. owfs fragen muessen die anderen beantworten, ich hab kein OneWire.
>
> ich weiß. Und der Vollständigkeit halber sollte ich noch sagen, dass
die owfs module stammen aus meiner feder. aktuell bin ich dabei diese komplett
zu überarbeiten. hab noch etwas geduld und es gibt bald neue module im cvs.
die owfs-module in fhem fragen den owfs-server über perl ab. das passiert im
prinzip genau so wie $bash:owread. allerdings mit viel mehr logik.
aktuell (bei mir, noch nicht im cvs) wird DS9097, DS9097U, DS9490R, DS18S20,
DS18B20, HUBRJ45 ( siehe http://goo.gl/xd4xM = 1-wire hub bei
http://www.eservice-online.de ) unterstützt. je nach wunsch baue ich weitere
hinzu.
welche benötigst du?
gruss martin
Georg
> die owfs module stammen aus meiner feder. aktuell bin ich dabei diese komplett
> zu überarbeiten. hab noch etwas geduld und es gibt bald neue module im cvs.
9097U einfach als 9097 in fhem.cfg eingebunden und bei näherem
Hinsehen sehe ich auch, dass ich den tatsächlich eh über localhost:
3003 (also owserver) anspreche. Ich nutze Deine owfs.pm und owtemp.pm,
lediglich für die Zähler habe ich derzeit die oben vorgeschlagene
Lösung. Davon komme ich aber gern wieder ab :-)
> die owfs-module in fhem fragen den owfs-server über perl ab. das passiert im
> prinzip genau so wie $bash:owread. allerdings mit viel mehr logik.
> je nach wunsch baue ich weitere hinzu. Welche benötigst du?
Klasse! Am dringensten den Zähler DS2423, denn ich nutze diese GP-1
Module hier: http://www.homechip.com/catalog/product_info.php?cPath=27&products_id=140
Sinnvoll (aber sicher schwieriger wären dann noch die DS2406 für diese
2-Kanal I/O-Module: http://www.homechip.com/catalog/product_info.php?cPath=27&products_id=149
Ich kann Dir übrigens testweise gern je einen GP-1 und ein I/O-Modul
schicken... das I/O-Modul kannst Du dann gern auch behalten :-)
Die Abfrage des DS2423 steht aber auch oben, der hat eine 1D.*-Kennung
im Gegensatz zur 10.*-Kennung der Temperatursensoren.
Viele Grüße!
Georg
Martin Fischer
Am Montag 14 März 2011 schrieb Georg:
> [...]
> > je nach wunsch baue ich weitere hinzu. Welche benötigst du?
>
> Klasse! Am dringensten den Zähler DS2423, denn ich nutze diese GP-1
> Module hier:
> http://www.homechip.com/catalog/product_info.php?cPath=27&products_id=140
scheint nicht so aufwendig zu sein... für den DS2423 benötigt man ja
eigentlich nur die werte von counters.A .. counters.B so wie ich das im moment
sehe. unklar ist hier noch die aufgabe des DS2406, der dort auch verbaut ist.
> Sinnvoll (aber sicher schwieriger wären dann noch die DS2406 für diese
> 2-Kanal I/O-Module:
> http://www.homechip.com/catalog/product_info.php?cPath=27&products_id=149
hier muss ich dann schauen, was benötigt wird. wahrscheinlich sind das neben
latch.A .. latch.B, PIO.A .. PIO.B, sowie set_alarm. letzteres scheint etwas
tricky zu sein.. schaun wa ma, wenn's soweit ist.
mit "was benötigt wird" meine ich übrigens bei beiden fällen jeweils die
"special properties" die ein read/write zulassen. alle anderen "properties"
die read-only sind und NICHT binär sind werden dann eh angezeigt. mit ausnahme
solcher informationen wie "r_address, r_id, locator, r_locator". da sehe ich
keinen sinn drin. im prinzip, werden aber eigentlich alle properties
unterstützt, die im man vom jeweiligen baustein im owfs unterstützt werden.
diese sind im quelltext halt auskommentiert und könnten bei bedarf einfach
dazugenommen werden. nur ist bei den auskommentierten porperties dann keine
logik wie z.b. umrechnungen oder so vorhanden, sondern die werte werden dann
so geliefert, wie sie owfs liefert.
> Ich kann Dir übrigens testweise gern je einen GP-1 und ein I/O-Modul
> schicken... das I/O-Modul kannst Du dann gern auch behalten :-)
danke für's angebot! ich denke das ich das erstmal nicht benötige, da owfs ja
zum glück auch die möglichkeit bietet mittels "FAKE" 1-wire module zu
simulieren, die sich dann im bus wie physikalisch vorhandene verhalten. und
wenn alle stricke reissen, dann musst du halt als beta-tester hinhalten ;-)
> Die Abfrage des DS2423 steht aber auch oben, der hat eine 1D.*-Kennung
> im Gegensatz zur 10.*-Kennung der Temperatursensoren.
genau das sollte dann als ergebnis mittels "FAKE" auch im bus angezeigt
werden.
aber nun ein kurzer ausblick:
erstmal muss ich mich noch einwenig mit dem genannten 1-wire HUB vom
http://www.eservice-online.de befassen. dieser setzt ein DS2450 ein um die
spannung und den strom des busses zu überwachen. da sind aber noch ein paar
umrechnungsfaktoren nötig um die werte korrekt im fhem anzuzeigen.
wenn ich den fertig habe, dann gehe ich als nächstes den PIO DS2413 an. da
weiss ich seit langem, das der peter aus wien (schöne grüsse von hier) darauf
schon lange warte. stelle ich mir aber nicht so kompliziert vor.
wenn ich diese beiden dann fertig habe, dann schaue ich mir deine sachen an.
kann sich also, je nachdem wieviel zeit ich finde, bis ende april ziehen.
gruss martin
Willi
DS2423 ein, um meinen Gasverbrauch zu monitoren. Bis vor kurzem ohne
FHEM, einfach Logging in eine Datei per OWFS-Dateisystem (nicht das
FHEM-Modul, sondern das Dateisystem von http://owfs.org/). Den
Gasverbrauch schaue ich mir seit Jahren über ein einfaches AWK-Skript
an.
Es ist dieses Board:
http://www.hobby-boards.com/catalog/product_info.php?products_id=42
Die Platine habe ich direkt in den USA bestellt, zusammengelötet und
per Reed-Kontakt mit meinem Gaszähler verbunden.
Da ich jetzt FHEM in größerem Rahmen einsetze, habe ich vor einigen
Wochen OWFS um ein neues Modul OWCOUNT erweitert:
--- 20_OWFS.pm.old 2010-08-14 20:45:11.127995077 +0200
+++ 20_OWFS.pm 2011-01-19 20:17:13.904958875 +0100
@@ -36,6 +36,7 @@
"1:DS9420" => "01",
"2:DS1420" => "81",
"3:DS1820" => "10",
+ "4:DS2423" => "1D",
);
my %gets = (
@@ -60,7 +61,7 @@
# Provider
$hash->{WriteFn} = "OWFS_Write";
- $hash->{Clients} = ":OWTEMP:";
+ $hash->{Clients} = ":OWTEMP:OWCOUNT:";
Mit diesem kann man dann den Dual-Counter in fhem.cfg definieren und
nutzen. Dabei kann man einen Korrekturfaktor setzen, der mit den
erhaltenen Werten multipliziert wird (Bei mir mit 0,1 bei beiden
Zählern):
define COUNTER OWCOUNT A9EB09000000 0.1 0.1
Damit kann ich mir jetzt den Gasverbrauch per SVG-Plot in FHEM
ansehen.
Das Modul basiert einfach auf OWTEMP, welches ich an den DS2423 an
gepasst habe.
Ich war bisher davon ausgegangen, dass ich allein Bedarf für ein
solches Modul für DS2423 (Dual-Counter) habe. Daher hatte ich mich
bisher nicht gemeldet.
Ich hatte mich bisher auf meine anderen Module (RFXCOM, OREGON, etc.)
konzentriert und fast wieder vergessen, dass ich bereits die Anpassung
für DS2423 vorgenommen habe. Ich hatte auch keine Anstalten gemacht es
ins CVS einzustellen, da es eine Quick-And-Dirty-Erstellung, lediglich
mit dem Zweck der Funktionsfähigkeit (der so geänderte Code sieht
nicht besonders schön aus...) war. Andererseits funktioniert es jetzt
seit mehren Wochen (seit 19. Januar 2011) ohne irgendwelche Probleme.
Wenn jetzt Bedarf besteht: Ich kann das Modul gerne zur Verfügung
stellen, sofern gewünscht. Es stellt sich dann nur die Frage in
welcher Form, da anscheinend gerade das OWFS-Modul grundlegend
geändert wird.
Georg
Martin, der 2406 wird im GP-1 Modul nicht gesondert abgefragt, sondern
macht offenbar irgendwas internes. Nur der 2423 wird abgefragt und
dort nur Counter.A und Counter.B.
Wenn Willis Modul nutzbar ist - umso besser! Ich kann's nicht wirklich
beurteilen aber was red ich auch, ich lese den ja gerade per bash
aus...
Der 2406 ist dann die Kür denke ich :-)
Viele Grüße
Georg
Martin Fischer
Am Dienstag 15 März 2011 schrieb Willi:
> Ich setzte bei mir seit 2008 ein Dual-Counter-Board basierend auf
> DS2423 ein, um meinen Gasverbrauch zu monitoren. Bis vor kurzem ohne
> [...]
> Es ist dieses Board:
> http://www.hobby-boards.com/catalog/product_info.php?products_id=42
selbiges ist letzte woche auch bei mir "eingetrudelt". bin nur noch nicht dazu
gekommen es in betrieb zu nehmen.
> [...]
> Wenn jetzt Bedarf besteht: Ich kann das Modul gerne zur Verfügung
> stellen, sofern gewünscht. Es stellt sich dann nur die Frage in
> welcher Form, da anscheinend gerade das OWFS-Modul grundlegend
> geändert wird.
da ich ja auch das dual-counter-board habe werde ich dafür natürlich auch ein
auf die änderungen im OWFS modul angepasstes modul für den counter
bereitstellen.
klar kannst/sollst du dein modul gerne zur verfügung stellen. da ich aber ein
paar grundsätzliche änderungen an dem OWFS und demnach auch an dem OWTEMP
modul vornehme, stellt sich die frage ob das dann von bestand ist.
gruss martin
Martin Fischer
> Cool! Vielen Dank Euch beiden!
> Martin, der 2406 wird im GP-1 Modul nicht gesondert abgefragt, sondern
> macht offenbar irgendwas internes. Nur der 2423 wird abgefragt und
> dort nur Counter.A und Counter.B.
das habe ich mir schon gedacht.
> Wenn Willis Modul nutzbar ist - umso besser! Ich kann's nicht wirklich
> beurteilen aber was red ich auch, ich lese den ja gerade per bash
> aus...
na dann nutz doch erstmal das modul von willi. und wenn ich dann die neuen
module release, liegt es ja an euch, welches ihr dann nutzt :-)
gruss martin
Willi
wenn Du ein neues Modul für DS2423 schreiben willst, kein Problem.
Ich hänge nicht an meinem Modul. Es macht nur das, was ich derzeit
brauche. Nicht mehr und nicht weniger.
Es macht allerdings keinen Sinn, dann nach Release Deines Moduls mein
altes Modul weiterzunutzen. Ich finde es auch nicht gut im CVS zwei
konkurrierende Module mit gleicher Funktionalität zu haben.
Hintergrund: Mein Modul 21_OWCOUNT.pm nach Release Deines Moduls
weiterzunutzen geht schlecht, da es nicht eigenständig läuft, sondern
von Deinem alten 20_OWFS.pm aus dem CVS genutzt wird:
--- 20_OWFS.pm.old 2010-08-14 20:45:11.127995077 +0200
+++ 20_OWFS.pm 2011-01-19 20:17:13.904958875 +0100
@@ -36,6 +36,7 @@
"1:DS9420" => "01",
"2:DS1420" => "81",
"3:DS1820" => "10",
+ "4:DS2423" => "1D",
);
my %gets = (
@@ -60,7 +61,7 @@
# Provider
$hash->{WriteFn} = "OWFS_Write";
- $hash->{Clients} = ":OWTEMP:";
+ $hash->{Clients} = ":OWTEMP:OWCOUNT:";
(alt und neu) braucht, da mein Modul von 20_OWFS.pm abhängig ist.
Es ist daher die Frage, ob es überhaupt Sinn macht, wenn Georg mein
Modul übergangsweise benutzt. Beim späteren Wechsel, müsste er seine
alten Filelogs entweder löschen oder in das neue Format konvertieren.
Damit ich Dein neues Modul für DS2423 nutzen kann, wäre mir wichtig,
dass Dein Modul für Dual-Counter auch einen Korrekturfaktor zur
Multiplikation hat und die so berechneten Werte als Reading generiert
(für Filelog).
In meinem Fall ist es wichtig den Zählerwert mit 0,1 zu
multiplizieren, da ich dann den Verbrauch als kwh bekomme. Das ist
dann auch bzgl. der Darstellung (pgm2/SVG-Plots) besser.
Deshalb sieht meine Definition wie folgt aus:
realisieren bzw. bist Du bereit das zu realisieren?
Ich selbst habe keine Probleme damit meine alte Filelog nach Release
Deines neuen Moduls entsprechend zu konvertieren und auch evtl. mein
gplot anzupassen.
MfG Willi
Martin Fischer
Am Freitag 18 März 2011 schrieb Willi:
> [...]
> In meinem Fall ist es wichtig den Zählerwert mit 0,1 zu
> multiplizieren, da ich dann den Verbrauch als kwh bekomme. Das ist
> dann auch bzgl. der Darstellung (pgm2/SVG-Plots) besser.
>
> Deshalb sieht meine Definition wie folgt aus:
> define COUNTER OWCOUNT A9EB09000000 0.1 0.1
>
> Kannst Du Dein geplantes Modul beim DS2423 bzgl. Korrekturfaktor so
> realisieren bzw. bist Du bereit das zu realisieren?
das hatte ich vor. mein gaszähler signalisiert 1 impuls je 0,01 m³. einmal
wollte ich rawcounter und dann den umgewandelten wert als reading speichern.
wozu definierst du aber zweimal 0.1?
darüber hinaus will ich noch als attribut die einheit mitgeben, also m³, kwh
o.a.
aber mal kurz zurück zum dual-counter von hobby-boards:
ich habe den heute mal an den bus und den reedkontakt geklemmt und
festgestellt, das er wohl ab und an mal "prellt". also statt einen wert
hochzählen, auch schon mal zwei.
tritt das bei dir auch auf, bzw. ist dir das auch schon aufgefallen?
ich habe zwischen count A und +5 V noch ein 4,7k ohm pullup widerstand
gesetzt. vielleicht ist das ja meine fehlerquelle.
gruss martin
Willi
>
> das hatte ich vor. mein gaszähler signalisiert 1 impuls je 0,01 m³. einmal
> wollte ich rawcounter und dann den umgewandelten wert als reading speichern.
>
> wozu definierst du aber zweimal 0.1?
Also der erste Korrekturfaktor für Counter.A, der zweite für Counter.B
> aber mal kurz zurück zum dual-counter von hobby-boards:
>
> ich habe den heute mal an den bus und den reedkontakt geklemmt und
> festgestellt, das er wohl ab und an mal "prellt". also statt einen wert
> hochzählen, auch schon mal zwei.
>
> tritt das bei dir auch auf, bzw. ist dir das auch schon aufgefallen?
>
> ich habe zwischen count A und +5 V noch ein 4,7k ohm pullup widerstand
> gesetzt. vielleicht ist das ja meine fehlerquelle.
dasselbe Problem. Ohne Widerstand sollte es nicht mehr prellen (macht
es zumindest bei mir nicht).
Kritisch kann auch die Kabellänge sein. Ich würde kein Kabel nutzen,
welches mehr als ein paar Meter lang ist. Ich wollte am zweiten
Countereingang noch einen Wasserzähler anschließen.Das hat bei einer
Kabellänge von 20 Meter aber nicht funktioniert, trotz CAT-6-Kabel.
MfG Willi
Martin Fischer
> [...]
> Also der erste Korrekturfaktor für Counter.A, der zweite für Counter.B
ne, wat logisch ;-) hatte ich gerade mal unter den tisch gekehrt den count B..
> > aber mal kurz zurück zum dual-counter von hobby-boards:
> [...]
> > ich habe zwischen count A und +5 V noch ein 4,7k ohm pullup widerstand
> > gesetzt. vielleicht ist das ja meine fehlerquelle.
>
> Wenn ich mich recht erinnere, hatte ich damals mit Vorwiderstand
> dasselbe Problem. Ohne Widerstand sollte es nicht mehr prellen (macht
> es zumindest bei mir nicht).
na dann werde ich das mal ausprobieren. nur dumm, das der counter gerade rund
350 km von mir entfernt ist. muss ich dann mal sonntag abend testen.
> Kritisch kann auch die Kabellänge sein. Ich würde kein Kabel nutzen,
> welches mehr als ein paar Meter lang ist. Ich wollte am zweiten
> Countereingang noch einen Wasserzähler anschließen.Das hat bei einer
> Kabellänge von 20 Meter aber nicht funktioniert, trotz CAT-6-Kabel.
daran sollte es bei mir nicht liegen. die länge beträgt nur gut 2 meter.
aber trotzdem danke für den tip!
gruss martin