Strom Zähler einbinden

Begonnen von Zwiebel, 30 November 2011, 09:56:47

Vorheriges Thema - Nächstes Thema

Zwiebel

                                                 

Hallo Zusammen.

Mein Stromanbieter ENBW hat mir einen intelligenten Strom Zähler
installiert. Jetzt würde ich den gern per FHEM auslesen, und plotten
lassen.
Jetzt hab ich ein shell script erstellt das die aktuelle leistung in
ein log file schreibt. Das würd ich gern im FHEM verarbeiten. Aber so
ganz optimal scheint das nicht zu werden. Auf meiner fritzbox hab ich
kein cron und ständig das script zu pollen ist eher auch nicht so gut.

Hat jemand eine bessere idee, wie ich vorgehn soll?

Wenn ich das mit dem Zähler hin bekommen habe möchte ich meine
Solaranlage auswerten. Mein Wechselrichter stellt mir auch einen
webserver zur verfügung mit einer aktuellen einspeiseleistung. Aber
das kommt erst später.

vielen dank Gruß
Zwiebel

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Mein Stromanbieter ENBW hat mir einen intelligenten Strom Zähler installiert.

Was genau ist intelligent an dem Stromzaehler ? :)


> Auf meiner fritzbox hab ich kein cron und ständig das script zu pollen ist
> eher auch nicht so gut.

define StromDaten at *+00:05 "schreibeStromLog.sh"

oder

define StromDaten at *+00:05 { fhem "trigger StromDaten ".`leseStromWert.sh`}
define StromLog FileLog log/StromLog.csv StromDaten

Letzteres ist nur zu empfehlen, wenn leseStromWert.sh sich nicht blockieren
kann.


> Hat jemand eine bessere idee, wie ich vorgehn soll?

Fhem Modul schreiben :)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

> Was genau ist intelligent an dem Stromzaehler ? :)

Intelligent würd ich die ned nennen :-) aber die zeigen immerhin in
echtzeit deinen Stromverbrauch an... und man kann an schönen Graphen
verfolgen, welchen Gerät nach dem Einschalten bzw Ausschalten wieviel
Strom verbraucht.

Und wird nur noch der genaue Verbrauch abgerechnet ohne Vorauszahlung
und / oder Hochrechnungen.

Fhem Modul is ne gute Idee - könnt ich auch noch brauchen :-)

Christian

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Zwiebel

                                                 

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

Guest

Originally posted by: <email address deleted>

Hallo zusammen,

noch kleine Anregung:
Die letzten beiden Zeilen würde ich folgendermaßen abändern (dann wird
nicht die zum jeweiligen Zeitpunkt gerade aktuelle Leistung gelesen,
sondern die durchschnittliche Leistung der letzten viertel Stunde):
mydata="$(wget -q $url -O - | grep " W$" )"
echo $mydata | sed "s/^/$date /" >> $logtarget

Im cfg dann folgende Einträge sorgen dafür, dass alle 15 Minuten
gelesen wird (vorher power4enbw wie beschrieben bereitstellen und in
der ersten Zeile +* eintragen anstatt *+):
define EnBWDaten at +*00:15:00 "FHEM/enbw_lesen.sh"
define FileLog_EnBWDaten FileLog ./log/enbw.log EnBWDaten
attr FileLog_EnBWDaten logtype power4enbw
attr FileLog_EnBWDaten room Heizung


On 30 Nov., 21:27, zwiebel 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

Zwiebel

                                                 

Hallo cge,

das mit dem durchschnittlichen Leistung hat mich auch intressiert.
Ich hab es dann so gelöst.

mydata="$(wget -q $url -O - | grep " W" )"
echo $mydata | sed 's/^M$//' | sed 's/
//g' |
sed 's/<\/div>//g' | sed "s/^/$date /" >> $logtarget

das liefert dann im log ein:
2011-12-12_22:22:39 543 W 843 W
2011-12-12_22:27:40 1162 W 843 W

das lässt sich dann auch noch schön plotten...

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.




On 12 Dez., 22:24, cge wrote:
> Hallo zusammen,
>
> noch kleine Anregung:
> Die letzten beiden Zeilen würde ich folgendermaßen abändern (dann wird
> nicht die zum jeweiligen Zeitpunkt gerade aktuelle Leistung gelesen,
> sondern die durchschnittliche Leistung der letzten viertel Stunde):
> mydata="$(wget -q $url -O - | grep " W$" )"
> echo $mydata | sed "s/^/$date /" >> $logtarget
>
> Im cfg dann folgende Einträge sorgen dafür, dass alle 15 Minuten
> gelesen wird (vorher power4enbw wie beschrieben bereitstellen und in
> der ersten Zeile +* eintragen anstatt *+):
> define EnBWDaten at +*00:15:00 "FHEM/enbw_lesen.sh"
> define FileLog_EnBWDaten FileLog ./log/enbw.log EnBWDaten
> attr FileLog_EnBWDaten logtype power4enbw
> attr FileLog_EnBWDaten room Heizung
>
> On 30 Nov., 21:27, zwiebel 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

Guest

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

Zwiebel

                                                 

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

Guest

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

Zwiebel

                                                 

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

Guest

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

Zwiebel

                                                 

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

Guest

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

Guest

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

rudolfkoenig

                                                   

> 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

Zwiebel

                                                 

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

Zwiebel

                                                 

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

rudolfkoenig

                                                   

> 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

Guest

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

Guest

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

Guest

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

Guest

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