wrote:
>
>
>
>
>
>
>
> > hier mein shell scriptchen :) (ich bin sicher das geht noch viel
> > schöner )
>
> > #!/bin/sh
> > date=`date +"%Y-%m-%d_%H:%M:%S"`
> > url="http://192.168.0.56/index.html"
> > logtarget="/var/media/ftp/fhem/log/enbw.log"
> > mydata="$(wget -q $url -O - | grep " W" | grep akt )"
> > echo $mydata | sed 's///g' | sed 's/<\/div>//
> > g' | sed "s/^/$date /" >> $logtarget
>
> > dann noch so wie von Rudolf Koenig beschrieben und funktioniert!
>
> > auf basis von power4.gplot das unten abgeändert und dann hat man noch
> > ein plot!
>
> > #FileLog 2::0:
> > plot "" using 1:2 notitle with lines
>
> > Bin sowas von begeistert! :) vielen dank!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
zwiebel wrote:
> Ich frage den enbw Zähler über ein vpn tunnel ab und der kann von der
> netzwerk bandbreite "dicht" sein. Das führt dazu das das shell script
> 2x oder noch öfters läuft. Und damit FHEM alles blokiert. Das hab ich
> halbwegs in den griff bekommen mit diversen kill schleifen.
>
> Aber so ganz gefällt mir das shell scriptchen eh nicht.
> Auf welcher basis könnte ich ein perl modul erweitern? Die unter FHEM
> sind mir etwas zu kompliziert, die zumindest die ich mir angeschaut
> habe.
Mal abgesehen davon, daß ein simpler wget selbst durch ein verstopftes
DSL-Nadelöhr plus VPN-Overhead noch passen sollte ... würde ich sowas
eher als externen Prozeß, der ein Logfile/ein date-value-Paar schreibt,
realisieren.
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Zusammen,
ich hab jetzt das umgesetzt was Rudolf König vorgeschlagen hatte. :)
Ein eigenes perl modul ist einfach besser. Ich hab es jetzt schon paar
Wochen im Einsatz und es funktioniert bestens.
Es wird jetzt auch nicht mehr die Webseite runter geladen und ausgewertet.
Besser ist es das ComModul anzusprechen. Ich hab herausgefunden das
ENBW "Intelligenter Strom Zähler" und Yellow Strom "Sparzähler"
genau gleich arbeiten. Vielleicht gibt es noch mehr solcher Geräte....
Jetzt meine frage wie kann ich das modul zur verfügung stellen?
Hier hoch laden oder doch auf http://sourceforge.net, aber wie?
Als namen für das modul hab ich mir "70_smartmeter.pm" überlegt, spricht da
was dagegen?
Gruß
Zwiebel
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hm, "smartmeter" ist zu generisch - auch andere Messgeräte haben
"Inteligenz". Besser wäre 70_TYPENBEZEICHNUNG.pm - denn bedenke, alle
subroutinen fangen mit dem Namen an.
Ich habe z.B. das Modul für meinen solaren Wechselrichter 70_NT5000.pm
genannt - eben die Typenbezeichnung des WR.
LG
pah
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
ok - dann wird es besser 70_COMMODUL.pm heißen?
70_ENBW.pm oder 70_YELLOWSTROM.pm ist auch nicht gut....
Gruß
Zwiebel
Am Freitag, 6. April 2012 15:27:49 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Hm, "smartmeter" ist zu generisch - auch andere Messgeräte haben
> "Inteligenz". Besser wäre 70_TYPENBEZEICHNUNG.pm - denn bedenke, alle
> subroutinen fangen mit dem Namen an.
>
> Ich habe z.B. das Modul für meinen solaren Wechselrichter 70_NT5000.pm
> genannt - eben die Typenbezeichnung des WR.
>
> LG
>
> pah
>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nun, es gibt auch andere Module, die einen COM-Port nutzen - und etwas
"MODUL" zu nennen, das die Endung .pm = "Perl Module" hat, ist auch nicht
so prickelnd.
Gängige Typen der neuen Stormzähler sind z.B.** MT372 von Iskra, oder
EDL21, EDL40 oder irgendetwas Anderes - das steht mit Sicherheit auf dem
Ding irgendwo drauf.
Genau dieses solltest Du als Modulbezeichnung verwenden - denn ein Zähler
eines anderen Typs hat möglicherweise ein anderes Protokoll. Wenn Du also
einen generischen Namen verwendest (etwa "stromzaehler.pm" wäre das nicht
so ganz einfach, die beiden Dinge zu verschmelzen. Das sollte z.B. in
Zukunft durch ein parsen der SML (Smart Metering Language, eine
XML-Anwendung) - Daten der Zähler geschehen.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Pah,
wußt garnicht das es so viele Strom Zähler gibt.
Hätte auch nicht gedacht das es so viel um den modul name zu überlegen gibt.
Die Anleitung passt auch für mein Strom Messer von ENBW:
https://yellowiki.wikispaces.com/file/view/2010_Beschreibung_XML_Schnittstelle_version_1.pdf
Eine Typen Bezeichnung wird sich nicht finden lassen.
Weil es halt bei
ENBW -> "Intelligenter Strom Zähler"
und bei
Yellow Strom -> "Sparzähler"
heißt.
Gemeinsamkeit scheint das ComModul zu sein....(ComModul SCM2010903)
gruß
Zwiebel
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Aha, wir kommen der Sache näher ...
Das so genannte Com Modul ist nur ein Stück Hardware, das in die Zähler
eingebaut wird und die Daten via TCP/IP abfragbar macht. Es implementiert
tatsächlich aber eine XML-Syntax der Smart Message Language SML (nicht
Smart Metering Language, wie ich oben naiverweise behauptet habe). Diese
scheint sich derzeit als Standard für die Abfrage der elektronischen
Stromzähler zu etablieren.
Wir können also davon ausgehen, dass sich Dein Modul mit wenig Aufwand an
andere Zählertypen anpassen lässt.
Damit wäre es sicher gut, als Modulname zu wählen 70_SML.pm. Bei der
Definition in der fhem.cfg würde dann ein Zählermodell mit angegeben werden
können, um unterschiedliche Stromzähler verarbeiten zu können.
Für die Daten selber noch ein Vorschlag von mir:
1. Es ist sinnvoll, für den gemessenen Wert als Namen nicht irgendetwas
Nichtssagendes zu verwenden wie "messung" oder "wert", sondern genauer zu
charakterisieren, um was es sich handelt. Also z.B. "energy" für die
Kilowattstunden, oder kürzer "Wd" für die innerhalb eines Tages
aufgelaufenen kWh. Oder z.B. "power" für die momentane Leistung in kW.
2. Setzt man dann im Modul den Wert $hash->{READINGS}{power}, so ist dies
ja wieder ein assoziatives Array, welches die Werte
$hash->{READINGS}{power}{VAL} und $hash->{READINGS}{power}{TIME} erhält.
Ich schlage vor, neben den beiden bisher verwendeten Schklüsselwörtern
"VAL" und "TIME" zwei zusätzliche zu verwenden, nämlich "UNIT" und "TYPE".
UNIT soll die Messeinheit sein, und TYPE die Art des Messwertes. Zur
Begründung: FHEM wird immer komplexer, es wächst also die Vielzahl der
möglichen Messwerte. Damit ein Frontend nun selbständig "entscheiden" kann,
wie irgendwelche Wert edargestellt werden (mit/ohne Einheiten, in Grad
Fahrenheit oder Celsius, als Kilowattstunden oder BTU...), muss es wissen,
um was es sich handelt und auf welcher Skala die Messwerte angegeben
wurden. Du könntest also in Deinem Modul einmalig am Anfang setzen:
$hash->{READINGS}{power}{UNIT} = "kWh";
$hash->{READINGS}{power}{TYPE} = "power";
und dann jeweils beim Einreffen eines aktuellen Wertes
$hash->{READINGS}{power}{VAL} = ;
$hash->{READINGS}{power}{TIME} = ;
dazuschreiben.
Das ist übrigens vollständig kompatibel mit den gegenwärtigen Frontends.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Aha, wir kommen der Sache näher ...
Das so genannte Com Modul ist nur ein Stück Hardware, das in die Zähler
eingebaut wird und die Daten via TCP/IP abfragbar macht. Es implementiert
tatsächlich aber eine XML-Syntax der Smart Message Language SML (nicht
Smart Metering Language, wie ich oben naiverweise behauptet habe). Diese
scheint sich derzeit als Standard für die Abfrage der elektronischen
Stromzähler zu etablieren.
Wir können also davon ausgehen, dass sich Dein Modul mit wenig Aufwand an
andere Zählertypen anpassen lässt.
Damit wäre es sicher gut, als Modulname zu wählen 70_SML.pm. Bei der
Definition in der fhem.cfg würde dann ein Zählermodell mit angegeben werden
können, um unterschiedliche Stromzähler verarbeiten zu können.
Für die Daten selber noch ein Vorschlag von mir:
1. Es ist sinnvoll, für den gemessenen Wert als Namen nicht irgendetwas
Nichtssagendes zu verwenden wie "messung" oder "wert", sondern genauer zu
charakterisieren, um was es sich handelt. Also z.B. "energy" für die
Kilowattstunden, oder kürzer "Wd" für die innerhalb eines Tages
aufgelaufenen kWh. Oder z.B. "power" für die momentane Leistung in kW.
2. Setzt man dann im Modul den Wert $hash->{READINGS}{power}, so ist dies
ja wieder ein assoziatives Array, welches die Werte
$hash->{READINGS}{power}{VAL} und $hash->{READINGS}{power}{TIME} erhält.
Ich schlage vor, neben den beiden bisher verwendeten Schklüsselwörtern
"VAL" und "TIME" zwei zusätzliche zu verwenden, nämlich "UNIT" und "TYPE".
UNIT soll die Messeinheit sein, und TYPE die Art des Messwertes. Zur
Begründung: FHEM wird immer komplexer, es wächst also die Vielzahl der
möglichen Messwerte. Damit ein Frontend nun selbständig "entscheiden" kann,
wie irgendwelche Wert edargestellt werden (mit/ohne Einheiten, in Grad
Fahrenheit oder Celsius, als Kilowattstunden oder BTU...), muss es wissen,
um was es sich handelt und auf welcher Skala die Messwerte angegeben
wurden. Du könntest also in Deinem Modul einmalig am Anfang setzen:
$hash->{READINGS}{power}{UNIT} = "kW";
$hash->{READINGS}{power}{TYPE} = "power";
und dann jeweils beim Einreffen eines aktuellen Wertes
$hash->{READINGS}{power}{VAL} = ;
$hash->{READINGS}{power}{TIME} = ;
dazuschreiben.
Das ist übrigens vollständig kompatibel mit den gegenwärtigen Frontends.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Jetzt meine frage wie kann ich das modul zur verfügung stellen?
sourceforge id mir mailen, und Modul einchecken.
Wenn es ein commandref.html Eintrag dafuer gibt und Du es in der naechsten Zeit
auch supporten willst, dann direkt nach fhem/FHEM (damit wird es auch mit
updatefhem verteilt), sonst nach contrib.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
70_SML.pm ist ok macht jetzt auch mehr sinn, mit der erklärung von dir.
ich denk schon sinvolle variablen genommen zu haben....
$hash->{READINGS}{currentPower}{VAL}
$hash->{READINGS}{intervalPower}{VAL}
Readings:
2012-04-07 09:20:43 currentPower 959
2012-04-07 09:20:43 intervalPower 1003.90
Gruß
Zwiebel
Am Samstag, 7. April 2012 07:30:51 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Aha, wir kommen der Sache näher ...
>
> Das so genannte Com Modul ist nur ein Stück Hardware, das in die Zähler
> eingebaut wird und die Daten via TCP/IP abfragbar macht. Es implementiert
> tatsächlich aber eine XML-Syntax der Smart Message Language SML (nicht
> Smart Metering Language, wie ich oben naiverweise behauptet habe). Diese
> scheint sich derzeit als Standard für die Abfrage der elektronischen
> Stromzähler zu etablieren.
>
> Wir können also davon ausgehen, dass sich Dein Modul mit wenig Aufwand an
> andere Zählertypen anpassen lässt.
> Damit wäre es sicher gut, als Modulname zu wählen 70_SML.pm. Bei der
> Definition in der fhem.cfg würde dann ein Zählermodell mit angegeben werden
> können, um unterschiedliche Stromzähler verarbeiten zu können.
>
> Für die Daten selber noch ein Vorschlag von mir:
>
> 1. Es ist sinnvoll, für den gemessenen Wert als Namen nicht irgendetwas
> Nichtssagendes zu verwenden wie "messung" oder "wert", sondern genauer zu
> charakterisieren, um was es sich handelt. Also z.B. "energy" für die
> Kilowattstunden, oder kürzer "Wd" für die innerhalb eines Tages
> aufgelaufenen kWh. Oder z.B. "power" für die momentane Leistung in kW.
>
> 2. Setzt man dann im Modul den Wert $hash->{READINGS}{power}, so ist dies
> ja wieder ein assoziatives Array, welches die Werte
> $hash->{READINGS}{power}{VAL} und $hash->{READINGS}{power}{TIME} erhält.
> Ich schlage vor, neben den beiden bisher verwendeten Schklüsselwörtern
> "VAL" und "TIME" zwei zusätzliche zu verwenden, nämlich "UNIT" und "TYPE".
> UNIT soll die Messeinheit sein, und TYPE die Art des Messwertes. Zur
> Begründung: FHEM wird immer komplexer, es wächst also die Vielzahl der
> möglichen Messwerte. Damit ein Frontend nun selbständig "entscheiden" kann,
> wie irgendwelche Wert edargestellt werden (mit/ohne Einheiten, in Grad
> Fahrenheit oder Celsius, als Kilowattstunden oder BTU...), muss es wissen,
> um was es sich handelt und auf welcher Skala die Messwerte angegeben
> wurden. Du könntest also in Deinem Modul einmalig am Anfang setzen:
>
> $hash->{READINGS}{power}{UNIT} = "kW";
> $hash->{READINGS}{power}{TYPE} = "power";
>
> und dann jeweils beim Einreffen eines aktuellen Wertes
>
> $hash->{READINGS}{power}{VAL} = ;
> $hash->{READINGS}{power}{TIME} = ;
>
> dazuschreiben.
>
> Das ist übrigens vollständig kompatibel mit den gegenwärtigen Frontends.
>
> LG
>
> pah
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich würde gern in dem Modul auch noch die Tages Summe ausrechnen.
Dazu müsste ich die intervalPower innerhalb einer Stunde aufaddieren und
den durschnitt bilden.
Wie kann ich die einzel intervalle in ein array speichern, am besten mit
der Uhrzeit.
2012-04-10_14:00:00 211.90
2012-04-10_14:05:00 123.90
2012-04-10_14:10:00 111.90
2012-04-10_14:15:00 233.90
...
2012-04-10_14:55:00 555.90
2012-04-10_15:00:00 211.90
________________________________________________
# ausgabe im log letzte Stunde wurden 300 Wh verbraucht
# seit anfang des Tages wurden bis jetzt (2012-04-10_15:00:00) 3,5 kwh
verbraucht
________________________________________________
2012-04-10_15:05:00 444.90
2012-04-10_15:15:00 555.90
wie bekomm ich das hin so ein array oder hash der vielleicht sogar ein fhem
neu start überlebt zu realisieren?
vielen dank!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Wie kann ich die einzel intervalle in ein array speichern, am besten mit
> der Uhrzeit.
Stuendlich (wenn die Stunde sich aendert) ein event generieren, und den mit
einem FileLog abspeichern. Ist aber eigentlich nicht nowedig, weil die
#FileLog Anweisung (.gplot) hat fuer sowas die delta-h Funktion. Alternativ
erfindet man 24 readings, die in fhem.save landen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...so langsam arbeite ich mich bei meiner Installation zum Stromzähler vor.
Dieser ist ein ISKRA MT171
Tja, jetzt stellt sich die Frage, wie ich diesen in fhem einbinde. Es gibt
zwei Möglichkeiten:
1. Der Zähler hat ein optisches IR Interface, welches man mit einem
seriellen Protokoll abfragen kann. Problem: der Schreib-/Lesekopf ist etwas
umständlich zu bauen und die Ergebnisse müssen verarbeiten werden.
2. Mein Zähler ist vom Sub-Typ G12. Das heisst, das er einen
potentialfreien Ausgang auf der Unterseite hat, an dem die Zählimpulse
abgegriffen werden könnten. Problem dabei: ich müsst das Siegel des
Energieversorgers entfernen, um an den Ausgang zu kommen.
Telefonisch hat der Fachmann meines Energieversorgers gelangweilt
abgewunken, was das Siegel angeht. Sprich: das interessiert die nicht.
Zu was raten die Experten? Eine Photozelle mit Knete auf das Gehäuse
kleben. um die blinkende LED auszuwerten ist mir zu sehr gebastelt :-)
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...hier noch der Link zum Schreib-/Lesekopf
http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> ...hier noch der Link zum Schreib-/Lesekopf
>
> http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf
>
...da ich nicht basteln kann, habe ich mir beim C für 9,95 die "RS-232
Schnittstellenadapter für VOLTCRAFT® Multimeter"* *gekauft. Die "kleben"
seit 4 Monaten per Magnet am optischen IR-Forntinterface meiner Zählern
(Hager und EMH) und loggen per C#-Prog die Zählerstände. Wirklich nicht
schön, aber es läuft....
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@dou
der ISKRA spricht DLMS oder 1107
Du musst ein Kennwort haben und am Anfang richtig initaliesieren abhängig
davon, ob du DLMS oder 1107 sprechen willst. DLMS ist mit CRC16 und Source
und Destinationadresse nicht so einfach
Abhängig davon wie der Zähler parametriert ist sendet er alle x Sek den
Zählerstand und ggf ein paar Infos mehr so wie bei Krikan.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com