Hi Folks,
Ab sofort unterstützt 47_OBIS auch den SML-Standard.
Da SML ja nichts anderes als codierte OBIS-Meldungen sind, habe ich gemeinsam mit matzefisi das SMLUSB mit meinem OBIS verschmolzen.
Somit sollten jetzt ziemlich viele Smartmeter, die über USB, RS232, RS485 und sonstiges ausgelesen werden, mit einem Modul erreicht.
Die Grundfunktionalität ist gelich geblieben, neu ist hinzugekommen:
1) MeterType: SML
Wie der Name schon sagt, werden hiermit SML-Meter ausgelesen.
Die SMLDaten werden ins OBIS-Format konvertiert und als Readings bereitgestellt.
zB:
define MyObis OBIS /dev/ttyVoltcraft@9600,7,E,1 SML
2) Attribut unitReadings
Wer es unbedingt will, kann hiermit an die Readings die passenden Units anhängen
Das Update bekommt ihr ab morgen früh mittels FHEM-Update automatisch.
Danke nochmal an matzefisi und immi fürs Testen, Tips und die allgemeine Unterstützung.
Für zusätzliche Wünsche, Anregungen, Beschwerden uns sonstiges bin ich natürlich jederzeit für euch erreichbar.
lg, Stefan
So, da ich gestern Abend wenig Zeit hatte, hier nochmal ein paar weitere Infos zum Modul:
1) Define:
define myObis OBIS <schnittstelle> <metertyp>
Metertyp kann hier sein:
VSM102 -> Voltcraft VSM102
Dieser Meter (und manche andere) senden nicht automatisch ihre Daten, sondern brauchen erst eine Anfrage vom Programm.
Soweit ich bisher gesehen habe, ist diese Anfrage bei vielen gleich, also kann das VSM102 evtl. auch bei anderen Metern genutzt werden.
Standard -> Plain OBIS
Für Smartmeter, die ihre Daten als reine OBIS-Meldungen ohne auffroderung senden.
SML -> SML-codierte OBIS-Daten
Wie der Name schon sagt :) Mit diesem Metertyp wird das SMLUSB-Modul ersetzt.
2) Attribute:
interval
Das Interval in Sekunden, in denen die Daten vom Smartmeter abgerufen werden.
Wird einerseits benutzt beim VSM102-Typ, wo die Daten ja abgerufen werden müssen.
Andererseits auch in Kombination mit dem Polling-Mode (siehe unten) interessant.
offset_feed
offset_energy
Hiermit kann der Gesamt-Zählerstand um den angegebenen Wert angepasst werden.
Mein Zähler hängt zB hinter dem Ferraris-Zähler meines Stromversorgers.
Damit kann ich meinen Zähler an den offiziellen Zählerstand anpassen.
channels
Wenn man die Channel-Readings umbenennen will, oder einen Channel hat, der vom Modul nicht abgedeckt wird,
kann hiermit ein Perl-Array angegeben werden, welches zusätzlich zu den Internen Zuordnungen durchsucht wird.
zB:attr myObis channels {"21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
directions
Manche Zähler senden die Stromrichtung (von / zum) EVU in einem Statusbyte mit.
Dies ergibt dann zusätzliche Readings:
2016-04-08 19:41:54 dir_total_consumption in
2016-04-08 19:41:45 dir_total_feed out
"in/out" sind hier als Standard vorgegeben, können aber mit diesem Attribut geändert werden.
zB:
{"<"=>"←",">"=>"→"}
um die Richtung als Pfeile zu erhalten (← / →)
alignTime
Nur in Kombination mit interval nutzbringend.
Mit diesem Attribut wird das Interval auf die hier angegebene Zeit angepasst.
Selbe funktionalität wie beim at.
Bei einem interval von 600 (=10 Minuten) und aligbTime von "00:00:00" wird immer um hh:00:00, hh:10:00, hh:20:00 usw. abgerufen.
pollingMode
Da es bei Metern, die ihre Daten im Sekundentakt senden, teilweise zu erhöhter CPU-Last kommt, kann hiermit auf den FHEM-internen Polling-Mechanismus umgeschaltet werden.
Hierbei werden die Daten nicht mehr Event-basiert abgerufen, sondern nur mehr ca. alle 5 Sekunden.
Nachteil: Damit kann sich evtl. eine leichte Verzögerung im Abrufen der Daten ergeben.
So, hoffe mal, das war ein wenig Informativ :)
Schönes Wochenende euch allen,
Stefan
Hi Stefan, da musste ich natürlich sofort aktualisieren, um zu testen,ob dann auch die bekannten kleineren Fehler bereinigt sind. Sind sie ! Danke !
Läuft für ASCII-OBIS fast wie gehabt, lediglich an den Readings zu current und power hat sich etwas unschön verändert: Wie vom device gelesen, werden nun führende Nullen angezeigt, by power(channels x1) auch das ggfs. vorhandene + Vorzeichen
Schönes Wochenende
Markus
Hi Markus,
danke für die Meldung.
Sollte beides mit dem Fix von morgen früh beseitigt sein (oder du holsts dir gleich aus dem SVN).
lg, Stefan
prima. geht.
macht das automatische setzen von event-on-change-reading beim define eigentlich Sinn ? Ich lösch es nach jedem Restart wieder, da ich nur die Leistung logge.
Grüße Markus
Bei jenen, deren Meter in Sekundentakt die Daten senden macht das durchaus Sinn.
Und bei allen anderen dürfte es mMn nicht wirklich zu Nebeneffekten führen (Ausser, du willst zB auch im Minutentakt die Daten loggen, obwohl sie sich nicht ändern)
War ein User-Wunsch, kann ich gerne auch wieder entfernen, wenns wem stört.
dafür hast Du doch pollingMode und interval eingebaut ;-)
ich verstehe Attribute als Mittel zur individuellen Konfiguration und es ist doch eher unüblich die per Modul zu setzen. In meinem Fall brauche ich das event als trigger für mein userreading, welches sich möglicherweise verändert: die Zählerleistung ist zwar unverändert aber Erzeugung und Verbrauch haben sich möglicherweise geändert.
Ich fänds ohne besser. Warte mal noch andere Meinungen ab.
Grüße Markus
Hi Markus
mea culpa
ich habe event-on-change-reading vorgeschlagen.
Ich habe an newbie gedacht:
define xxx obis /dev/usb
define xxxlog filelog log.txt xxx
Damit werden mehrere GB data pro Tag generiert, bei Meeter die in Sekundentakt arbeiten
...aber Publickey bleibt immer gleich, Version auch....
deswegen event-on-change-reading "by default" macht sinn für newbie.
Erfahrene FHEM Users können immer folgende Behfel in fhem.cfg eintragen
define xxx obis /dev/usb
deleteattr xxx event-on-change-reading
Hi Stefan
other topic
by next bugfix, if you want, you can add a hint in the obis-reference-manual.
47_obis works out-of-the.box well also over a ser2net connection
e.g.
define myPowerMeter OBIS 10.0.1.13:1234
it is quite usefull if your fhem server is far away from the powermeeter.
as you know my ser2net hardware is just a cheap esp8266 (every other hardware with ser2net is fine)
immi
Hi Immi,
verstehe ich. Owner, Serial, Status und Version(publickey gibt es bei mir nicht) sollten aber schon modulintern seit einiger Zeit nicht wiederholt zu einem Event führen.
@Stefan: Komischerweise habe ich gerade festgestellt, dass dies in der aktuellen Version aber nur für "Version" gilt ?
Macht es dann nicht mehr Sinn, die Attribute pollingMode=on und interval=60 zu setzen ? Damit wären doch die newbies noch mehr vor Datenmüll geschützt und die Systeme sind auch automatisch performanter.
@Stefan: mir ist noch ein kleines Fehlerchen aufgefallen. Bei Definition ohne metertype wurde bei mir der metertype "SML" anstatt "Standard" vorbesetzt.
Grüße
Markus
Hallo,
vielen Dank für das Modul kam genau passend zu meinem IR Lesekopf.
Nun wird bei meinem Hager Zweiwegezähler im Reading Power bei Bezug die korrekte Bezugsleistung in Watt angezeigt. Bei Einspeisung jedoch nicht - kann ich das irgendwie umrechnen?
Hmm, komisch, dürfte eigentlich nicht sein.
Inwieweit ist der Wert falsch?
Du könntest ihn zB mit einem Userreading umrechnen.
Besser wärs aber, du schickst mir mal nen kompletten Datensatz, wie er vom Lesekopf kommt, dann schau ich, wo da der Fehler liegt.
@Markus:
ZitatBei Definition ohne metertype wurde bei mir der metertype "SML" anstatt "Standard" vorbesetzt.
Eigentlich sollte der Metertyp automatisch auf den richtigen Wert gesetzt werden (SML oder Standard, je nachdem, in welchem Format die Daten kommen)
Werd ich mir auch nochmal ansehen.
Und die automatisch gesetzten Attribute lass ich ganz fallen.
Ich denke, ein User, der das OBIS definiert, sollte mündig genug sein um zu wissen, waelche Attribute er setzen soll/muss.
Die Korrekturen bekommt ihr spätestens am Donnerstag per Update geliefert.
lg, Stefan
hab mir die Werte von tenya mal angesehen. demnach ein 2-tarif-2-richtungszähler ? stimmen die werte mit der anzeige am Zähler überein ? mir kommt die glatt 1000 in beiden Richtungen in Tarif2 arg komisch vor.
@Stefan kann es sein, dass bei Einspeisung ein minus-zeichen nicht oder falsch interpretiert wird ? 64 kW macht die Anlage sicherlich nicht oder ich würd schon mal die Feuerwehr in Rufbereitschaft versetzen ;-)
@tenya mach doch mal ne messreihe, nee besser, wir haben ja fhem, log doch mal den power-wert, dann sieht man schön den Wechsel von Bezug zu Einspeisung
Grüße Markus
Zitat64 kW macht die Anlage sicherlich nicht
Vielleicht will er seinen privaten Atommeiler loggen? **scnr**
THEORETISCH dürfte das nicht falsch berechnet werden, ich rechne mir den Wret und den Scaler genau nach den offiziellen Richtlinien aus.
TATSÄCHLICH wird er scheinbar schon falsch berechnet.
Daher auch die Bitte nach einem kompletten Frame 8)
64841 Watt klingt verdächtig nach 216 - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?
Zitat von: willybauss am 17 April 2016, 10:36:40
64841 Watt klingt verdächtig nach 216 - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?
Oder signed / unsigned ? -695W
Gruß Friedrich
Hallo,
nachdem Ihr dem Modul auch SML beigebracht habt, bin ich auch wieder mit meinem Easymeter Q3C dabei, danke dafür.
den aktuellen Wert bekomme ich auf Anhieb, aber den Gesamtenbezug oder die Einspeisewerte kommen nicht an, der Log bringt:
2016.04.17 09:56:19 5: OBIS (EasymeterQ3C) - Msg-Parse: !
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: /ESY
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 129-129:199.130.3*255(ESY)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.0*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.0*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.1*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.2*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.3*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.4*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.5*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.6*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.7*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.8*255(3e+97)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:1.7.0*255(54.77*W)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:21.7.0*255(150.9*W)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:41.7.0*255(7.89*W)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:61.7.0*255(-104.02*W)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:96.5.5*255(16784)
2016.04.17 09:56:21 5: OBIS (EasymeterQ3C) - Msg-Parse: !
meine aktuelle Definition:
define EasymeterQ3C OBIS /dev/ttyUSB0@9600,8,N,1 SML
attr EasymeterQ3C channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
#attr EasymeterQ3C event-min-interval *:30
attr EasymeterQ3C unitReadings on
mit dem VZlogger kommen folgende Wert:
Strombezug 4444161.3 Wh
StromLieferung 4031988.7 Wh
woran kann ich noch drehen, dass ich auch diese Werte wieder als Readings bekomme?
Gruß osid-timo
Zitat von: Omega-5 am 17 April 2016, 11:00:15
Oder signed / unsigned ? -695W
Gruß Friedrich
genau das hatte ich gemeint :)
Zitat von: Icinger am 16 April 2016, 21:31:06
Vielleicht will er seinen privaten Atommeiler loggen? **scnr**
THEORETISCH dürfte das nicht falsch berechnet werden, ich rechne mir den Wret und den Scaler genau nach den offiziellen Richtlinien aus.
TATSÄCHLICH wird er scheinbar schon falsch berechnet.
Daher auch die Bitte nach einem kompletten Frame 8)
So anbei zwei Frames einmal mit Bezug wo ja alles ok ist und eines mit Lieferung (rund 9000w) im fhem reading stand ca. 58000
und nein kein 64kwP Anlage ;-) aka Atommeiler - nur 15kwP
Hallo!
Ich hoffe Ihr könnt mir helfen!!!
Schon seit Tagen versuche ich meinen Stromzähler "Pafal 20EC3g" vom Bayernwerk (EON) mit dem OBIS-Modul per Fhem auszulesen.
Zum auslesen benutze ich den original IR-Kopf von Udo (vom Volkszählerprojekt)
Bei mir läuft nur Fhem ohne die Volkszählersoftware mit dem USB-IR-Kopf auf einem Raspberry.
Angelegt habe ich das ganze als:
define MyObis OBIS /dev/ttyUSB0@300,7,E,1 VSM102
Das state wird mit "opened" angezeigt.
Ich bekomme nur leider keine Readings.
Klicke ich jedoch bei "TYPE" auf "OBIS" um die Internals sehe ich beim "Buffer" meine Zählerwerte durchlaufen. (nach mehrmaligen aktualisieren)
z.B. "BUFFER 1.8.1*00(000103.06)" --> Das ist mein Bezugszähler im Tarif 1
-------------------------------------------------------------------------------------------------------------------------
CHANGED
DEF /dev/ttyUSB0@300,7,E,1 VSM102
DeviceName /dev/ttyUSB0@300,7,E,1
FD 10
MeterType VSM102
NAME MyObis
NR 28
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-04-17 20:26:10 Version PAF5EC3g00006
2016-04-18 21:20:19 state opened
Helper:
BUFFER 1.8.1*00(000103.06)
Channels
EoM 0
SPEED 0
TRIGGERTIME 1461007219.60298
DEVICES:
/?!
10
000
Attributes:
event-on-change-reading .*
interval 10
room zähler
-------------------------------------------------------------------------------------------------------------------------
Ändere ich nun den MeterType von "VSM102" zu "SML" und schalte wieder auf die Internals um, hab ich manchmal Glück und ALLE auszulesenden Werte stehen da, werden aber nicht mehr erneut ausgelesen. -> Erst als VSM102 wird wieder ausgelesen. Readings erscheinen trotzdem keine. :-[
----------------------------------------------------------------------------------------------------------------
Internals:
CHANGED
DEF /dev/ttyUSB0@300,7,E,1 SML
DeviceName /dev/ttyUSB0@300,7,E,1
FD 10
MeterType SML
NAME MyObis
NR 28
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-04-17 20:26:10 Version PAF5EC3g00006
2016-04-18 20:57:34 state opened
Helper:
BUFFER 0.0.0(72045525)x0.0.1(PAF)
F.F(00)
0.2.0(1.29)
1.8.1*00(000102.22)
1.8.2*00(000097.07)
2.8.0*00(000200.51)
C.2.1(000000000000)( )
0.2.2(:::::G11)!
A
EoM -1
SPEED 0
TRIGGERTIME 1461005853.97947
Channels:
1.8.1 energy_L1
DEVICES:
10
Attributes:
channels {"1.8.1"=>"energy_L1"}
event-on-change-reading .*
interval 10
room zähler
---------------------------------------------------------------------------------------------------------------------------------
1.8.1*00(000102.22)
1.8.2*00(000097.07)
2.8.0*00(000200.51)
Das sind die Werte, die ich brauche....
1.8.1 ist Bezug Tarif 1
1.8.2 ist Bezug Tarif 2
2.8.0 ist Geliefert (eingespeißt durch PV-Anlage)
Die Einstellungen mit 300Baut ,7,E,1 sollten laut diesem Link stimmen. Hier wird beschrieben wie man diesen Zähler z.B. mit Volkszähler ausliest:
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/pafal-20ec3gr#beispiel_fuer_eine_vzloggerconf
Leider sind meine Perlkenntnisse zu gering, als dass ich die richtigen Anpassungen im Modul durchführen könnte.
Wäre gaaaanz toll, wenn mir jemand helfen könnte. ::)
Chris
Hallo Chris,
Das ist auch eines der Smartmeter, die eine extra Aufforderung brauchen, um die Daten zu senden.
Setze den Metertyp mal bitte auf "VSM102". Sollte damit eigentlich auf anhieb klappen.
Dabei wird aber automatisch ein Abfrageinterval von 10 Minuten gesetzt, das kannst du ja aber auch runtersetzen.
lg, Stefan
PS: Habe gerade eben eine neue Version commited, bei der
1) keine Attribute mehr gesetzt werden
2) das sign/unsigned-Problem behiben sein sollte.
Wie immer ab morgen per Update oder heute schon direkt aus dem SVN holen.
Zitat von: dbox2user am 18 April 2016, 21:43:33
... Angelegt habe ich das ganze als:
define MyObis OBIS /dev/ttyUSB0@300,7,E,1 VSM102
Das state wird mit "opened" angezeigt.
Ich bekomme nur leider keine Readings.
Zitat von: Icinger am 19 April 2016, 05:42:52
...
Setze den Metertyp mal bitte auf "VSM102". Sollte damit eigentlich auf anhieb klappen.
...
Muss ich jetzt nicht unbedingt verstehen ...
Hallo Stefan,
Danke schonmal für die rasche Antwort! :)
Den Metertyp auf "VSM102" umstellen habe ich ja schon gemacht. (wie im vorherigen Post beschrieben).
Hier sehe ich in den Internals, dass meine Zähler-Werte im "Buffer" nacheinander durchlaufen. -> Das sieht man durch mehrmaliges aktualisieren des Browserfensters. Leider erscheinen die Werte nur nacheinander im "Buffer" aber sonst nirgendwo.
Erst nach dem ändern auf "SML" werden --MANCHMAL-- die zuvor per "VSM102" gelesenen Werte als seperater Block in den Internals dauerhaft angezeigt . Als "SML" wird dann aber nichts neues mehr eingelesen.
Normale Readings der Zählerstände bekomme ich NIE.
Nur diese beiden Readings:
2016-04-17 20:26:10 Version PAF5EC3g00006
2016-04-18 21:20:19 state opened
Würden eigentlich Werte, die das Modul nicht kennt als Reading angezeigt werden (z.B. 1.8.1*00(000102.22) 1.8.2*00(000097.07) 2.8.0*00(000200.51) )
Oder müsste man diese "unbekannten Werte" erst mit dem Atribut "channels" benannt werden, dass Readings erscheinen (laut Beschreibung: "channels:
Wenn man die Channel-Readings umbenennen will, oder einen Channel hat, der vom Modul nicht abgedeckt wird,
kann hiermit ein Perl-Array angegeben werden, welches zusätzlich zu den Internen Zuordnungen durchsucht wird."
Ich hoffe es ist verständlich was ich meine. :o
Gruß,
Chris
Hallo Icinger,
danke für deinen Einsatz. Auch bei meinem Zweiwegezähler wird nun alles korrekt angezeigt und ich kann mich daran machen den Überschuss möglichst geschickt auszunutzen. :)
ZitatMuss ich jetzt nicht unbedingt verstehen ...
Nööööööö 8)
ZitatMuss ich jetzt nicht unbedingt verstehen ...
Sorry, hab ich in der Früh im Schlaftaumel übersehen.
Ich schau mir das spätestens am Donnerstag (da hab ich frei) an, wo da der Käfer begraben liegt.
lg, Stefan
@dbox2user:
^B0.0.0(715xxxxx)
0.0.1(PAF)
F.F(00)
0.2.0(1.27)
1.8.0*00(000094.17)
2.8.0*00(000266.55)
C.2.1(000000000000)( )
0.2.2(:::::G11)!
Das is ja ganz was perverses, was dein Meter da sendet, das hat mit einem OBIS-Standard rein gar nix zu tun :(
kA ob ich da irgendwas machen kann.
Aber lass mich mal überlegen....
lg, Stefan
erst dachte ich, es sei ein Datenfehler, aber im Netz findet man dasselbe, passt also. Evtl. kann man auf die wichtigsten Daten (1.8.0, 2.8.0) filtern und den Rest verwerfen?
Schonmal eine großes Dankeschön, dass sich hier einige um die Anliegen anderer kümmern! :)
Zitat von: Icinger am 19 April 2016, 21:12:56
@dbox2user:
^B0.0.0(715xxxxx)
0.0.1(PAF)
F.F(00)
0.2.0(1.27)
1.8.0*00(000094.17)
2.8.0*00(000266.55)
C.2.1(000000000000)( )
0.2.2(:::::G11)!
Das is ja ganz was perverses, was dein Meter da sendet, das hat mit einem OBIS-Standard rein gar nix zu tun :(
kA ob ich da irgendwas machen kann.
Aber lass mich mal überlegen....
lg, Stefan
Na toll, da hat mir das EVU ja nen "tollen" Zähler in Zeiten von Smartmeter & Co eingebaut. :-[
Wie gesagt, wichtig wären eigentlich 3 Werte:
1.8.1*00(000102.22) ist Bezug Tarif 1 =102,22kWh
1.8.2*00(000097.07) ist Bezug Tarif 2 =97,07kWh
2.8.0*00(000200.51) ist Geliefert (eingespeißt durch PV-Anlage) =200,51kWh
Wenn man nur darauf filtern könnte und diese dann als Readings hätte wäre ich happy!
Kann man evtl. etwas wichtiges aus dem Perl Script von hier verwenden...?
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/pafal-20ec3gr#beispiel_fuer_eine_vzloggerconf (http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/pafal-20ec3gr#beispiel_fuer_eine_vzloggerconf)
Gruß,
Chris
Guten Morgen,
Für sowas hab ich mir eh eine Option freigelassen.
Das OBIS ist so aufgebaut, dass es auch als zweistufiges Modul funktioniert.
Ich kann also ein extra-Modul machen, welches auf der Schnittstelle lauscht, dann seine Daten in einen richtigen OBIS-Frame umwandelt und diese dann an das OBIS dispatched.
Direkt im OBIS will ich das nicht unbedingt implementieren, weil ich da dann lauter Sonderregelungen bräuchte (es passen ja nichtmal "Beginn des Datensatzes" und "Ende des Datensatzes".
Werd mich mal dranmachen und schaun, ob das wirklich so funktioniert, wie ich mir das ursprünglich vorgestellt habe.
Also bitte noch ein bisschen Geduld, das werden wir schon hinbekommen :D
lg, Stefan
Guten Morgen,
ich habe mich im Eifer des Gefechts wohl zu früh gefreut :-\
Anbei nochmal ein Frame mit passendem Ausschnitt aus FHEM
@Icinger - bringt es dir noch etwas wenn ich aus dem Log was ausschneide?
Zum Zeitpunkt der Frameaufzeichnung waren ca. 3500W Einspeisung - ich kann auch keinen Zusammenhang zwischen den verschiedenen Einspeiseleistungen und den Werten im Reading herstellen. Bei höherer Einspeisung sind diese manchmal niedrieger im Reading.
Oder liefert mein Zähler einfach nur Mist?
Guten Morgen,
Zitat von: Icinger am 21 April 2016, 06:39:10
Werd mich mal dranmachen und schaun, ob das wirklich so funktioniert, wie ich mir das ursprünglich vorgestellt habe.
Also bitte noch ein bisschen Geduld, das werden wir schon hinbekommen :D
lg, Stefan
OK. Dann halt´ ich mal die Füße still, lasse Dich tüfteln und hoffe dass Du erfolgreich bist. ;)
Gruß,
Chris
Hi Tanya,
hab mir das jetzt nochmal angeschaut.
Die Readings stimmen genau mit den Werten überein, die ich aus deinen Daten herausbekommen:
zB Daten für reading "total_feed":
77 07 01 00 02 08 00 FF -> 62A2 01 621E 52FF 5513F00BEB 01
Leerschritte und "->" habe ich mal eingefügt.
Übersetzt lt. OBIS-Standard heisst das:
77 -> Start eines Eintrags
07 -> (T/L-Feld) Länge 7 Bytes ( =dieses und 6 folgende)
01 00 02 08 00 FF -> Die Obis-Adresse (=1-0:2.8.0*255)
Dann kommt zuerst ein Status-Byte:
62 -> (T/L-Feld) Typ unsigned, Länge 2 Bytes ( =dieses und 1 folgendes)
A2 -> Richtung ("in" oder "out")
Dann kommt ein "Time"-field, das nicht benutzt wird:
01 -> (T/L-Feld) Typ String, Länge 1 Bytes ( =dieses und KEIN folgendes)
Dann kommt die Einheit:
62 -> (T/L-Feld) Typ unsigned, Länge 2 Bytes ( =dieses und 1 folgendes)
1E -> Watt-Stunden
Dann kommt der Scaler, der wird später mit dem Wert multipliziert
52 -> (T/L-Feld) Typ signed Integer, Länge 2 Bytes ( =dieses und 1 folgendes)
FF -> gibt -1, also Richtung "out"
Oh, da hatte ich noch nen Fehler bei der Berechnung vom Scaler, Komma war um eine Stele verschoben.
Jetzt fehlt nur noch der Wert:
55 -> (T/L-Feld) Typ signed Int32, Länge 5 Bytes ( =dieses und 4 folgendes)
13F00BEB -> ergibt umgerechnet 334498795
01 -> Kennzeichnet das Ende des Frames.
334498795 * Scaler von vorhin (255 = -1) gibt dann -334498795 Wh
Der Wert würde soweit also stimmen, wenn ich nicht nen krassen Denkfehler irgendwo habe, oder?
lg, Stefan
Hi Stefan,
Es stimmen auch alle Werte außer dem Power Wert während der Einspeisung. Bei Bezug stimmt der Wert dagegen.
Sorry, Fehler gefunden, so sollte es jetzt passen :D
2016-04-21 14:01:19 ManufID HAG
2016-04-21 14:01:19 PublicKey 5A35-0882-EC00-4172-55E4-7368-C5BA-68EC-2009-2246-1CAF-EA58-F778-1768-E5D1-8
FBE-2AD1-CD76-1307-D488-B1B5-60C8-46B1-1326-01
2016-04-21 10:09:00 Status 386
2016-04-21 10:09:39 Version HAG\06-48-41-47-01-04-C5-37-63-3F
2016-04-21 14:01:19 dir_total_consumption out
2016-04-21 14:01:19 dir_total_feed out
2016-04-21 14:01:19 power -3194
2016-04-21 10:09:00 power_L1 1
2016-04-21 10:09:00 power_L2 137
2016-04-21 10:09:00 power_L3 1
2016-03-28 18:25:07 state disconnected
2016-04-21 14:01:19 total_consumption 8964784.3
2016-04-21 14:01:19 total_consumption_Ch1 8963784.3
2016-04-21 14:01:19 total_consumption_Ch2 1000
2016-04-21 14:01:19 total_feed 33449879.5
2016-04-21 14:01:19 total_feed_Ch1 33448879.5
2016-04-21 14:01:19 total_feed_Ch2 1000
Ich checke heute abend ein Update dazu ein.
Zitat von: Icinger am 21 April 2016, 10:07:45
Dann kommt der Scaler, der wird später mit dem Wert multipliziert
52 -> (T/L-Feld) Typ signed Integer, Länge 2 Bytes ( =dieses und 1 folgendes)
FF -> gibt -1, also Richtung "out"
Oh, da hatte ich noch nen Fehler bei der Berechnung vom Scaler, Komma war um eine Stele verschoben.
Hallo Stefan,
die Interpretation des scalers ist so nicht richtig. Ich habe nochmal in die Beschreibung des SML-Datenprotokolls geschaut.
Der Wert von scaler gibt den Exponenten zur Basis 10 an, er ist immer positiv.
52 FF --> scaler (int8) -1 = *10^-1 = /10
Es gibt auch die Möglichkeit das der scaler weitere Werte annimmt.
52FD = 10^-3 (x0,001)
52FE = 10^-2 (x0,01)
52FF = 10^-1 (x0,1)
5200 = 10^0 (x1)
5201 = 10^1 (x10)
5202 = 10^2 (x100)Die Richtung wird nur durch das Statusbyte angegeben.
Gruß Friedrich
Hallo Friedrich,
ja, so hab ich sie eh berechnet:
10**unpack("c", pack("C", hex($scaler)))
lg, Stefan
PS: Update ist grade commited worden.
Hi Stefan,
nach Update startet fhem nicht mehr
ZitatUndefined subroutine &main::OBIS_Set called at fhem.pl line 3163.
Zeile 73 war in der vorherigen Version auskommentiert. Wieder kommentiert, läufts.
Ich bin aber beim Reload(bei mir ohne metertype definiert) und nachfolgendes modify wieder auf den Bug gestoßen, dass SML vorbesetzt wurde. Schnell ein modify mit metertype=Standard und alles war gut. Außerdem funktioniert nach einem reload bzw. modify der pollingMode nicht mehr, zumindest steigt die CPU-Last danach wieder deutlich an. pollingMode abgeschaltet und wieder eingeschaltet und dann läuft es wieder wie es soll.
Schönes Wochenende Markus
Edit: Irrtum bzgl. pollingMode: der Zähler lief gar nicht mehr: Ich kann machen was ich will, aber pollingMode will nur nach Restart :'(
Jup musst die Zeile auch auskommentieren. Dafür wird jetzt die Momentanpower angezeigt :-)
-430W für gerade abgelesen Einspeisung.
ZitatUndefined subroutine &main::OBIS_Set called at fhem.pl line 3163.
Sorry, mein Fehler, hab zum Testen diverser SML-Daten eine OBIS_Set in einer externen Datei liegen.
Hab vergessen, das beim release auszukommentieren.
lg, Stefan
Hallo,
Nachdem ich seit heute ebenfalls einen USB Lesekopf vom volkszaehler.org Projekt besitze und diesen montiert habe, komme ich mit dem OBIS Modul irgendwie noch nicht so klar.
Also Auslesen geht schon einmal, aber außer "power" wird bei mir nichts ausgelesen. Der Wert von Power als momentane Leistung scheint plausibel.
Ich vermute ich muss irgendwas mit den "channels" attribute "mappen", aber ich habe keine Ahnung wie diese Channels denn überhaupt definiert sind, die Beispiele hier im Thread sagen ja z.B. 71=>power_L3, aber wo sehe ich denn den Kanal 71?
Ist ein EMH Zähler: http://www.emh-metering.com/de/produkte/ehz-i/ der laut Beschreibung das SML Protokoll spricht.
nein, an den channels liegt es nicht. die dienen nur der anwenderspezifischen Bezeichnung der readings.
Du liest die SML-Schnittstelle(Infrarot) und nicht die D0(LED-Impulse) ? Vermutlich SML, sonst hättest Du ja kein power.
Hattest Du denn mit anderer Software mehr Daten ?
mach mal bitte ein list devicename und poste das Ergebnis
@Stefan: im Datenblatt steht, dass die Kiste pushed. Könnte das ein Problem bei SML sein ?
Grüße Markus
Edit: gerade erst den screenshot gesehen: sind doch ne menge readings, nur die zählerstände leider noch null ;-(
Ich lese via SML Infrarot ab.
Mit dem "minicom" aus dem Volkszähler Wiki erhalte ich aber nur Müll, die Parity (8N1) und Baud 9600 habe ich denke ich korrekt eingestellt. Zumindest scheint das OBIS Modul damit ja auch das Power auszuwerten.
Hier mal der List:
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010660A3-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010660A3-if00-port0@9600,8,N,1
FD 12
MeterType SML
NAME powerMeter
NR 21
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-04-23 23:31:33 ManufID EMH
2016-04-23 23:31:33 PublicKey
2016-04-23 18:16:30 Version EMH\09-01-45-4D-48-00-00-54-5E-15
2016-04-23 23:31:12 dir_energy_total in
2016-04-23 23:31:33 dir_total_consumption in
2016-04-23 23:31:12 energy_total 0
2016-04-23 23:31:12 energy_total_Ch1 0
2016-04-23 23:31:12 energy_total_Ch2 0
2016-04-23 23:31:33 power 341.1
2016-04-23 23:31:33 statEnergy_total Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-04-23_22:33:27 )
2016-04-23 23:31:33 statPowerDay Min: 86.1 Avg: 202.3 Max: 2347.8 (since: 2016-04-23_17:39:54 )
2016-04-23 23:31:33 statPowerMonth Min: 86.1 Avg: 202.3 Max: 2347.8 (since: 2016-04-23_17:39:54 )
2016-04-23 23:31:33 statPowerYear Min: 86.1 Avg: 202.2 Max: 2347.8 (since: 2016-04-23_17:39:54 )
2016-04-23 23:28:41 state opened
2016-04-23 23:31:33 total_consumption 0
2016-04-23 23:31:33 total_consumption_Ch1 0
2016-04-23 23:31:33 total_consumption_Ch2 0
Helper:
BUFFER
EoM -1
SPEED 5
TRIGGERTIME 1461446921.24283
_98_statistics statPowerMeter
Channels:
DEVICES:
5
Directions:
Attributes:
event-min-interval power:10
interval 5
Merkwürdig ist halt, das nicht mal die "Standards" wie PublicKey, welches ja vermutlich eindeutig definiert ist leer sind.
Hier mal noch ein Auszug aus dem Log mit verbose 5
2016.04.23 23:33:36 5: SW:
2016.04.23 23:33:36 5: OBIS (powerMeter) - Internal timer set to 2016-04-23 23:33:41
2016.04.23 23:33:38 3: Telegram=77078181C78203FF0101010104454D4801
2016.04.23 23:33:38 3: Telegram=77070100000009FF010101010B0901454D480000545E1501
2016.04.23 23:33:38 3: Telegram=77070100010800FF6400018201621E52FF56000004A59E01
2016.04.23 23:33:38 3: Telegram=77070100010801FF0101621E52FF56000004A59E01
2016.04.23 23:33:38 3: Telegram=77070100010802FF0101621E52FF56000000000001
2016.04.23 23:33:38 3: Telegram=77070100100700FF0101621B52FF550000041001
2016.04.23 23:33:38 3: Telegram=77078181C78205FF0172620165000491C801018302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C214010101635C24007607000B000BC7706200620072630201710163179100000000
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: /EMH\09-01-45-4D-48-00-00-54-5E-15
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.3*255(EMH)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:0.0.9*255(09-01-45-4D-48-00-00-54-5E-15)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.0*255(>0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:16.7.0*255(104*W)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.5*255()
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: !
2016.04.23 23:33:41 5: SW:
2016.04.23 23:33:41 5: OBIS (powerMeter) - Internal timer set to 2016-04-23 23:33:46
2016.04.23 23:33:44 3: Telegram=77078181C78203FF0101010104454D4801
2016.04.23 23:33:44 3: Telegram=77070100000009FF010101010B0901454D480000545E1501
2016.04.23 23:33:44 3: Telegram=77070100010800FF6400018201621E52FF56000004A5A001
2016.04.23 23:33:44 3: Telegram=77070100010801FF0101621E52FF56000004A5A001
2016.04.23 23:33:44 3: Telegram=77070100010802FF0101621E52FF56000000000001
2016.04.23 23:33:44 3: Telegram=77070100100700FF0101621B52FF550000040B01
2016.04.23 23:33:44 3: Telegram=77078181C78205FF0172620165000491CF01018302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C21401010163A8A1007607000B000BC77C6200620072630201710163E87300000000
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: /EMH\09-01-45-4D-48-00-00-54-5E-15
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.3*255(EMH)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:0.0.9*255(09-01-45-4D-48-00-00-54-5E-15)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.0*255(>0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:16.7.0*255(103.5*W)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.5*255()
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: !
Hi,
bin grad vom Männerabend heimgekommen.
Für 1-0:1.8.2 liefert der Zähler wirklich einen Wert von 0.
Die restlichen Daten sehen ansich gut aus, muss ich mir anschaun, warum die nicht richtig umgerechnet werden.
Hat sonst noch jemand das Problem mit Null-Werten? Dürfte so eigentlich nicht sein.
Werd ich mir heute im lauf des Tages mal näher ansehen.
lg, Stefan
Ich habe mich jetzt mal getraut, ein Update zu machen (bin da immer erst etwas zurückhaltend). Ich hatte vorher noch die Version vom 6. März drauf, also ohne SML. Und mein Zähler war einer derer, die Kummer bereitet hatten, weil er die Daten ungefragt pusht, und dadurch die CPU übermäßig beanspruchte.
Nach dem Update läuft alles genauso weiter wie vorher musste ich erst mal die Zeile 73 ($hash->{SetFn} = "OBIS_Set") auskommentieren, damit es lief; anschließend: die Daten kommen im Minutentakt (interval 60) und die CPU-Last bleibt niedrig (pollingMode on). Auch an der define-Zeile musste ich nichts ändern (... -port0@9600,7,E,1), also weiterhin ohne Zählertypangabe.
Super, danke!!! :) Bitte das mit der auskommentierten Zeile noch korrigieren.
@rretsiem:
Hab mir das mal angeschaut, dein Zähler schickt innerhalb des Datenpakets komische Daten mit.
zB PublicKey:
2016.04.24 10:24:53 3: Telegram=77078181C78205FF (Status-->)01 7262 (valTime-->)01 6500052093 (unit-->)01 (scaler-->)01 (Daten-->)8302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C214010101633E3C007607000B000D26DF620062007263020171016361B700000000
Die Infos in Klammern habe ich dazugeschrieben.
Die "7262" und "6500052093" sind zwar grundsätzlich gültige T/L-Felder mit Daten, haben aber lt. SML-Standard an dieser Stelle nichts zu suchen.
Auch laut http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/emh-ehz-h1 (http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/emh-ehz-h1) haben die da nicht drinnen zu sein.
Ich überlege grade, wie ich solche unnötigen Daten rausfiltern könnte......Vielleicht fällt mir da was dazu ein, aber erstmal bin ich grade noch ratlos.
lg, Stefan
Hallo,
habe gestern auch auf das OBIS Modul umgestellt. Es kommen Daten an aber fhem hängt sich immer wieder auf.
Folgendes taucht im LogFile auf
2016.04.24 13:02:14 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 576.
2016.04.24 13:02:14 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:02:14 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:02:14 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA61F01
2016.04.24 13:02:14 3: Telegram=77070100010801FF0101621E52FF590000000003DCA61F01
2016.04.24 13:02:14 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:02:14 3: Telegram=770701000F0700FF0101621B520065000000D601
2016.04.24 13:02:14 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D01010163B04E0076050AA3D7FB6200620072630201710163719700
2016.04.24 13:03:01 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:03:01 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:03:01 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA65501
2016.04.24 13:03:01 3: Telegram=77070100010801FF0101621E52FF590000000003DCA65501
2016.04.24 13:03:01 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:03:01 3: Telegram=770701000F0700FF0101621B520065000000D901
2016.04.24 13:03:01 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D010101637FE40076050AA3D89D6200620072630201710163FDC500
2016.04.24 13:04:00 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:04:00 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:04:00 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA67901
2016.04.24 13:04:00 3: Telegram=77070100010801FF0101621E52FF590000000003DCA67901
2016.04.24 13:04:00 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:04:00 3: Telegram=770701000F0700FF0101621B520065000000DD01
2016.04.24 13:04:00 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D01010163345D0076050AA3D9096200620072630201710163A3FD00
2016.04.24 13:05:02 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:05:02 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:05:02 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA69E01
2016.04.24 13:05:02 3: Telegram=77070100010801FF0101621E52FF590000000003DCA69E01
2016.04.24 13:05:02 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:05:02 3: Telegram=770701000F0700FF0101621B520065000000DD01
2016.04.24 13:05:02 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D010101633CBA0076050AA3D9786200620072630201710163F8F600
Undefined subroutine &main::OBIS_Set called at fhem.pl line 3163.
Wo könnte der Fehler liegen?
Gruß, hf
Liegt daran, dass in dem Modul ein Fehler ist :)
KOmmentiere bitte - wie in den Posts darüber auch schon gesagt - die Zeile 73 aus.
Korrigierte Version kommt morgen früh per Update.
lg, Stefan
Hi Stefan
$val=unpack("q", pack("Q", hex($data))) if ($dataL==8);
und
$val=unpack("Q", pack("Q", hex($data))) if ($dataL==8);
sind bei mir problematisch.
Errormessage Invalid type 'Q' in pack at /opt/fhem/FHEM/47_OBIS.pm line 253.
--> fhem crashes as soon as first telegrams come
Ich bin nicht sicher ob es hat etwas zu tun http://perldoc.perl.org/functions/pack.html
ZitatQuads are available only if your system supports 64-bit integer values _and_ if Perl has been compiled to support those. Raises an exception otherwise.
immi
Hi Leuts,
hab grad ein Update hochgeladen.
1) OBIS_Set is raus, sorry nochmal, hatte ich zum testen drinnen.
2) @immi: Ich checke jetzt, ob du 32 oder 64bit hast. Sollte also klappen.
3) Der Auto-Detect sollte jetzt auch funktionieren.
lg, Stefan
Hallo
Ich wollte mal fragen ob man 2 x IR Kopf aus dem Volkszählerprojekt an OBIS anbinden kann, und wie man das konfiguriert?
Der Hintergrund ist der, ich habe eine Produktionszähler und einen Bezug/Lieferzähler, beides EHZ.
Gruß
Hi Stefan
yes if (length(pack('j', -1))*8 == 64) detects the 32bits and disables the unpack('q'
As a predictable sideeffect, I do not get the total_consumption anymore.
2016.04.25 22:09:59 5: OBIS (PowerMeter) - Msg-Parse: 1-0:1.8.0*255(>0*Wh)
2016.04.25 22:09:59 5: OBIS (PowerMeter) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2016.04.25 22:09:59 5: OBIS (PowerMeter) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2016.04.25 22:09:59 5: OBIS (PowerMeter) - Msg-Parse: 1-0:15.7.0*255(387*W)
would you be so nice to consider my suggestion in the pm of sunday?
thanks
immi
@Edi77 Frage hab ich schon in Deinem anderen Thread beantwortet.
Zitat von: Icinger am 21 April 2016, 06:39:10
Guten Morgen,
Für sowas hab ich mir eh eine Option freigelassen.
Das OBIS ist so aufgebaut, dass es auch als zweistufiges Modul funktioniert.
Ich kann also ein extra-Modul machen, welches auf der Schnittstelle lauscht, dann seine Daten in einen richtigen OBIS-Frame umwandelt und diese dann an das OBIS dispatched.
Direkt im OBIS will ich das nicht unbedingt implementieren, weil ich da dann lauter Sonderregelungen bräuchte (es passen ja nichtmal "Beginn des Datensatzes" und "Ende des Datensatzes".
Werd mich mal dranmachen und schaun, ob das wirklich so funktioniert, wie ich mir das ursprünglich vorgestellt habe.
Also bitte noch ein bisschen Geduld, das werden wir schon hinbekommen :D
lg, Stefan
Hallo Stefan!
Na, hast Du Dich mal "dran gemacht"? ;)
Wollte nur mal hören ob Du evtl schon neue Ekenntnisse hast. :)
Gruß,
Chris
Hi Chris,
Komme momentan leider nicht wirklich zu irgendwas, aber ich habs im Hinterkopf.....
Ich haffe mal, dass ich jetzt im laufe des Mai's was hinbekomme.
lg, Stefan
Hi
Does anybody use this module with Landis E350? It doesn´t give me any readings. I use
define MyObis OBIS /dev/ttyUSB1@115200,8,N,1
/dev/ttyUSB1@115200 too is used for SmartMeterP1 and that works. The log for this device reports is 8,N,1 so I guess I should use them.
The obis version I use is:
# $Id: 47_OBIS.pm 11208 2016-04-09 14:37:09Z icinger $
What could be may mistake?
Thanks
Hi Harry,
what do you get in your Log with a verbose 5?
Hi
I get
2016.05.15 18:09:55 3: Opening MyObis device /dev/ttyUSB1
2016.05.15 18:09:55 3: Setting MyObis serial parameters to 115200,8,N,1
2016.05.15 18:09:55 3: MyObis device opened
[...]
016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: /XMX5LGBBFG1009198749
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse:
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-3:0.2.8(42)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:1.0.0(160515181000S)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.1.1(4530303331303033313438313939363135)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:1.8.1(000073.217*kWh)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:1.8.2(000026.572*kWh)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:2.8.1(000091.209*kWh)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:2.8.2(000154.517*kWh)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.14.0(0001)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:1.7.0(00.000*kW)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:2.7.0(00.259*kW)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.7.21(00001)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.7.9(00000)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:99.97.0(0)(0-0:96.7.19)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:32.32.0(00000)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:32.36.0(00000)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.13.1()
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-0:96.13.0()
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:31.7.0(001*A)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:21.7.0(00.000*kW)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 1-0:22.7.0(00.259*kW)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:24.1.0(003)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:96.1.0(4730303235303033333630333031323136)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:24.2.1(160515180000S)(00041.661*m3)
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: !370E
every 10 seconds.
See (https://i.imgsafe.org/2989515.jpeg) for a pic of Obis.
{HT}
Ok, got it up and running here.....
I'll commit it in some minutes, so you can update tomorrow.
Standard-OBIS has a 6-Byte-Adress for the readings like
1-0:2.8.1*255(000091.209*kWh)
This *255 is missing in your data, so the regExes didn't grab it.
Adjusted the regExes for that.
What I don't know, is what THIS readings are for:
1-3:0.2.8(42)
0-0:96.1.1(4530303331303033313438313939363135)
0-0:96.14.0(0001)
0-0:96.7.21(00001)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:32.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.0(4730303235303033333630333031323136)
0-1:24.2.1(160515180000S)(00041.661*m3)
Especially the last line is interesting.....What does your meter count here?
Gas should start with 7-1:
Water should start with 8-1:
and district heating should be 6-1:
Hi
The last line is gas
If you send me the module I can test it
{HT}
BTW (160515180000S) is the time of the last Gas measurement
{HT}
Hi Stefan!
Nach dem post von HarryT hab ich auch mal verbose auf 5 gestellt und nun seh ich alle Einträge im Log.
Vorher hatte ich die Werte ja aus den "Internals" des Moduls kopiert.
Die Werte aus dem Log-File schauen denke ich garnicht mehr so "pervers" aus. ;)
Vielleicht kannst Du mir jetzt mit ganz wenig Aufwand helfen...
Hier mal die Log-Einträge:
2016.05.16 09:39:53 3: Opening MyObis2 device /dev/ttyUSB0
2016.05.16 09:39:53 3: Setting MyObis2 serial parameters to 300,7,E,1
2016.05.16 09:39:53 3: MyObis2 device opened
...
2016.05.16 09:40:03 5: SW: 2f3f210d0a
2016.05.16 09:40:04 5: OBIS (MyObis2) - Internal timer set to 2016-05-16 09:40:14
2016.05.16 09:40:05 5: OBIS (MyObis2) - Msg-Parse: /PAF5EC3g00006
2016.05.16 09:40:05 5: SW: 063030300d0a
2016.05.16 09:40:07 5: OBIS (MyObis2) - Msg-Parse: 0.0.0(72045525)
2016.05.16 09:40:08 5: OBIS (MyObis2) - Msg-Parse: 0.0.1(PAF)
2016.05.16 09:40:09 5: OBIS (MyObis2) - Msg-Parse: F.F(00)
2016.05.16 09:40:09 5: OBIS (MyObis2) - Msg-Parse: 0.2.0(1.29)
2016.05.16 09:40:10 5: OBIS (MyObis2) - Msg-Parse: 1.8.1*00(000275.40)
2016.05.16 09:40:11 5: OBIS (MyObis2) - Msg-Parse: 1.8.2*00(000305.89)
2016.05.16 09:40:12 5: OBIS (MyObis2) - Msg-Parse: 2.8.0*00(000801.48)
2016.05.16 09:40:14 5: SW: 2f3f210d0a
2016.05.16 09:40:14 5: OBIS (MyObis2) - Internal timer set to 2016-05-16 09:40:24
2016.05.16 09:40:14 5: OBIS (MyObis2) - Msg-Parse: C.2.1(000000000000)( )
2016.05.16 09:40:15 5: OBIS (MyObis2) - Msg-Parse: 0.2.2(:::::G11)!
Interessant sind ja nur die Zeilen:
2016.05.16 09:40:10 5: OBIS (MyObis2) - Msg-Parse: 1.8.1*00(000275.40) Bezug Tarif 1
2016.05.16 09:40:11 5: OBIS (MyObis2) - Msg-Parse: 1.8.2*00(000305.89) Bezug Tarif 2
2016.05.16 09:40:12 5: OBIS (MyObis2) - Msg-Parse: 2.8.0*00(000801.48) Geliefert durch PV-Anlage
Du hast ja bei HarryT geschrieben ... ein Standard-Obis-Eintrag wäre z.B. 1-0:2.8.1*255(000091.209*kWh) .... kannst Du die regExes so anpassen, dass sie eben auch auf meine "00" und ohne "kWh" reagieren würden?
Liebe Grüße,
Chris
Hallo Icinger,
tolle Leistung, bei mir kommen jetzt auch die für mich wichtigen Daten im Log an:
2016.05.16 11:26:44 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.0*255(4571810.4947*Wh)
2016.05.16 11:26:44 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.0*255(4265801.645*Wh)
wie ist die vorgesehen Methode um diese Werte in die Readings aufzunehmen?
Gruß Osid-timo
Hi
Thanks for your work.
With the current 47_OBIS module I get:
Constant subroutine main::URL redefined at /var/InternerSpeicher/fhem/lib/perl5/5.12.2/constant.pm line 130, <$fh> line 442.
Possible unintended interpolation of @115200 in string at ./FHEM/00_SmartMeterP1.pm line 84, <$fh> line 505.
2016.05.16 11:02:53 3: Opening SmartMeterP1 device /dev/ttyUSB1
2016.05.16 11:02:53 3: Setting SmartMeterP1 serial parameters to 115200,8,N,1
2016.05.16 11:02:53 3: SmartMeterP1 device opened
2016.05.16 11:02:53 3: SmartMeterP1:Updating attribute 'removeLeadingZero' to 'true'
2016.05.16 11:02:53 3: SmartMeterP1:Updating attribute 'removeUnitSeparator' to 'true'
2016.05.16 11:02:53 3: SmartMeterP1:Updating attribute 'room' to 'Sturing'
main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 590, <$fh> line 517.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 127, <$fh> line 517.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 127, <$fh> line 517.
2016.05.16 11:02:53 3: Opening MyObis device /dev/ttyUSB2
2016.05.16 11:02:53 3: Can't open /dev/ttyUSB2: No such file or directory
A bit ugly as I use SmartmeterP1 and OBIS. But:
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 127, <$fh> line 517.
is persistent.
Now I get:
(https://postimg.org/image/h02u8y80h/)
and can compare that with:
(https://postimg.org/image/b7go7ud5d/)
So I miss the
Gas readings and its timestamp
TarifIndicatorElectricity
I don´t know what
current_L1
Unknown_Channel_22
is.
Is it possible to change the namings?
I think it would be more consistent if "power" was renamend to "consumption" as it is used for "total-consumption".
{HT}
Hi
I guess this is interesting info.
Thanks to/copied from: # $Id: 00_SmartMeterP1 michelverbraak $
(The module was posted on this forum but has no clear copyright message. I guess it is ok to use it, at least read it.)
if ($obis_ref eq "0-0:1.0.0") {
#Date-time stamp of the P1 message
# YYMMDDhhmmssW
[...]
elsif ($obis_ref eq "1-0:1.8.1") {
# Meter reading electricity delivered to client low Tariff in 0,001 kWh
[...]
elsif ($obis_ref eq "1-0:1.8.2") {
# Meter reading electricity delivered to client normal Tariff in 0,001 kWh
[...]
elsif ($obis_ref eq "1-0:2.8.1") {
# Meter reading electricity delivered by client low Tariff in 0,001 kWh
[...]
elsif ($obis_ref eq "1-0:2.8.2") {
# Meter reading electricity delivered by client normal Tariff in 0,001 kWh
[...]
elsif ($obis_ref eq "1-0:1.7.0") {
# Actual electricity power delivered (+P) in 1 Watt resolution
[...]
elsif ($obis_ref eq "1-0:2.7.0") {
# Actual electricity power received (-P) in 1 Watt resolution
[...]
elsif ($obis_ref eq "0-0:17.0.0") {
# The actual threshold Electricity in kW
[...]
elsif ($obis_ref eq "0-0:96.14.0") {
# Tariff indicator electricity.
[...]
elsif ($obis_ref eq "0-0:96.3.10") {
# Switch position electricity
[...]
elsif ($obis_ref eq "0-1:24.2.1") {
# Last hourly value gas delivered to client in m3
[...]
elsif ($obis_ref eq "0-1:24.3.0") {
$hash->{Telegram}->{Gas}->{used} = 1;
[...]
elsif ($obis_ref eq "") {
if (($hash->{Telegram}->{Gas}->{used} == 1) && ($hash->{Telegram}->{Gas}->{obis_ref} eq "0-1:24.2.1" )) {
# Last hourly value gas delivered to client in m3
[...]
elsif ($obis_ref eq "0-1:24.4.0") {
# Valve position Gas
{HT}
@osid-timo:
Zitatbei mir kommen jetzt auch die für mich wichtigen Daten im Log an:
Code: [Auswählen]
2016.05.16 11:26:44 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.0*255(4571810.4947*Wh)
2016.05.16 11:26:44 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.0*255(4265801.645*Wh)
wie ist die vorgesehen Methode um diese Werte in die Readings aufzunehmen?
Diese beiden Datensätze sollten eigentlich auch als Reding angelegt werden.
Die RegEx greift bei denen.
Wenn dem nicht so ist, bräuchte ich bitte einen etwas längeren Daten-Auszug aus dem Log.
@HarryT:
Zitat2016.05.16 11:02:53 3: Can't open /dev/ttyUSB2: No such file or directory
So, how should that work then, if there's no USB2-Device?
ZitatSo I miss the
Gas readings and its timestamp
TarifIndicatorElectricity
As is stated yesterday, Gas isn't yet implemented.
But i sent you a private Message yesterday, with a version of OBIS, that also takes care of the Gas-Reading for testing.
ZitatIs it possible to change the namings?
-->see attribute "Channels"
Zitat
I think it would be more consistent if "power" was renamend to "consumption" as it is used for "total-consumption".
Obis has dedicated readings for total consumption and total feed.
But for the "power"-Readings: They can contain a minus-sign for feeding and a plus (or no sign) for consuming. But you can also rename them to something else by setting the Channel-Attribute.
hth, Stefan
Zitat von: Icinger am 16 Mai 2016, 12:42:59
@HarryT:So, how should that work then, if there's no USB2-Device?
:-) I toggle USB2 and USB1 to switch between SmartmeterP1 and OBIS.
Zitat
As is stated yesterday, Gas isn't yet implemented.
But i sent you a private Message yesterday, with a version of OBIS, that also takes care of the Gas-Reading for testing.
Mea culpa, I didn't see the message. But I just tested it and it works.
However it works a bit different for Gas. The BK-G4 ETB gasmeter send its status to the Landis E350 every hour. And the Landis E350 sends them to FHEM every 10 seconds. So its timestamp is different from the Electricity timestamp. It would be nice if the Gas timestamp is also a reading.
Zitat
-->see attribute "Channels"
Obis has dedicated readings for total consumption and total feed.
But for the "power"-Readings: They can contain a minus-sign for feeding and a plus (or no sign) for consuming. But you can also rename them to something else by setting the Channel-Attribute.
hth, Stefan
I will play around with that.
Thanks
ZitatHowever it works a bit different for Gas. The BK-G4 ETB gasmeter send its status to the Landis E350 every hour. And the Landis E350 sends them to FHEM every 10 seconds. So its timestamp is different from the Electricity timestamp. It would be nice if the Gas timestamp is also a reading.
Hmm, thats something special, not realy OBIS-like :/
How about an event-on-change on the Gas-Reading? So you should always have a nearly corretc timestamp for the Gas-reading.
Zitat von: Icinger am 16 Mai 2016, 13:17:05
Hmm, thats something special, not realy OBIS-like :/
Zitat
:-) these are 2 devices. Common in the Netherlands.
The actual timestamp is the number just for the measurement.
In this case:
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:24.2.1(160515180000S)(00041.661*m3)
160515180000S is the timestamp of the gas measurement.
Zitat
How about an event-on-change on the Gas-Reading? So you should always have a nearly corretc timestamp for the Gas-reading.
Better. I guess on the other measurement too. This will avoid the logging of growing very rapid.
In the logging I only see the Gas and the totals. Not the current measurement. The current measurements are very usefull for plotting. Is it possible to include them?
Regards
{HT}
Thats why i said yesterday, i dunno knbow what these Datas are:
1-3:0.2.8(42)
0-0:96.1.1(4530303331303033313438313939363135) -> E0031003148199615 (Serial??)
0-0:96.14.0(0001)
0-0:96.7.21(00001)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:32.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.0(4730303235303033333630333031323136) -> G0025003360301216 (Serial??)
If you tell me, what's what, i could include them 8)
I have only this list:
"0-0:1.0.0" Date-time stamp of the P1 message # YYMMDDhhmmssW
"1-0:1.8.1" Meter reading electricity delivered to client low Tariff in 0,001 kWh
"1-0:1.8.2" Meter reading electricity delivered to client normal Tariff in 0,001 kWh
"1-0:2.8.1" Meter reading electricity delivered by client low Tariff in 0,001 kWh
"1-0:2.8.2" Meter reading electricity delivered by client normal Tariff in 0,001 kWh
"1-0:1.7.0" Actual electricity power delivered (+P) in 1 Watt resolution
"1-0:2.7.0" Actual electricity power received (-P) in 1 Watt resolution
"0-0:17.0.0" The actual threshold Electricity in kW
"0-0:96.14.0" Tariff indicator electricity.
"0-0:96.3.10" Switch position electricity
"0-1:24.2.1" Last hourly value gas delivered to client in m3
"0-1:24.3.0" ??
"0-1:24.4.0" Valve position Gas
So from the list of unknown readings in my logs, just
"0-0:96.14.0" Tariff indicator electricity.
can be added yet.
May be I can see some gas usage tonight and find out if "0-1:24.2.1" Last hourly value gas delivered to client in m3 is reported.
BTW you saw the part in my message about the missing current values in the log?
{HT}
Hallo Icinger,
wie gesagt mir geht es noch um die Werte:
1.8.0
2.8.0
im Reading
ein vollständiger Datensatz sieht wie folgt aus:
2016.05.16 15:51:02 5: SW:
2016.05.16 15:51:02 5: OBIS (EasymeterQ3C) - Internal timer set to 2016-05-16 15:51:12
2016.05.16 15:51:03 5: OBIS: Full message-> 1B1B1B1B010101017605CA4F081A62006200726500000101760101074553595133430B0645535901071B92BDC301016312EB007605CA4F081B6200620072650000070177010B0645535901071B92BDC3017262016504ABF884F10077078181C78203FF01010101044553590177070101010800FF6341B07262016504ABF884621E52FC690000000AA58A48500177070102020800FF6341B07262016504ABF884621E52FC6900000009EF882B5D0177070101010801FF6341B07262016504ABF884621E5201650006F7F60177070101010802FF6341B07262016504ABF884621E520165000000700177070101010803FF6341B07262016504ABF884621E520165000000710177070101010804FF6341B07262016504ABF884621E520165000000710177070101010805FF6341B07262016504ABF884621E520165000000710177070101010806FF6341B07262016504ABF884621E5201650000007C0177070102020807FF6341B07262016504ABF884621E5201650006827D0177070102020808FF6341B07262016504ABF884621E520165000000700177070100010700FF0101621B52FE55FFFF3D240177070100150700FF0101621B52FE550000472F0177070100290700FF0101621B52FE55000002E801770701003D0700FF0101621B52FE55FFFEF30D0177070100600505FF010101016341B001010163A83D007605CA4F081C62006200726500000201710163FF7C0000001B1B1B1B1A021E05
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: /ESY
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 129-129:199.130.3*255(ESY)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.0*255(4572697.608*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.0*255(4267338.4285*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.1*255(4566940*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.2*255(1120*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.3*255(1130*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.4*255(1130*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.5*255(1130*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-1:1.8.6*255(1240*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.7*255(4266210*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-2:2.8.8*255(1120*Wh)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:1.7.0*255(-498.84*W-498.84*W)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:21.7.0*255(182.23*W182.23*W)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:41.7.0*255(7.44*W7.44*W)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:61.7.0*255(-688.51*W-688.51*W)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: 1-0:96.5.5*255(16816)
2016.05.16 15:51:03 5: OBIS (EasymeterQ3C) - Msg-Parse: !
als Channels habe ich folgende Definition:
channels {"21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","1"=>"energy_current","18"=>"energy_total","28"=>"feed_total"}
es wäre toll wenn auch das noch klappen könnte
Gruß Oswald
Hi,
ich lad gleich mal wieder eine neue Version hoch.
Habe einige gravierende Umgestaltungen heute gemacht. Wobei die bisherige Funktionalität aber weiterhin gegeben sein sollte.
Ab sofort werden unbekannte Readings mit dem gesamten OBIS-Code gesetzt, also zB:
2016-05-16 19:39:07 0-0:96.1.1 4530303331303033313438313939363135
2016-05-16 19:39:07 0-0:96.14.0 0001
2016-05-16 19:39:07 0-0:96.7.21 1
2016-05-16 19:38:27 0-0:96.7.9 0
2016-05-16 19:39:07 0-1:24.1.0 003
2016-05-16 19:39:07 0-1:96.1.0 4730303235303033333630333031323136
2016-05-16 19:39:07 1-0:22.7.0 0.259
2016-05-16 19:39:07 1-0:32.32.0 00000
2016-05-16 19:39:07 1-0:32.36.0 00000
2016-05-16 19:39:07 1-0:99.97.0 0-0:96.7.19
2016-05-16 19:39:07 1-3:0.2.8 42
2016-05-16 19:39:07 Gas 41.661
2016-05-16 19:39:07 Powerdrops 00000
2016-05-16 19:39:07 Time_current 01-01-1970 01:00:01
2016-05-16 19:38:27 Version XMX5LGBBFG1009198749
2016-05-16 19:39:07 current_L1 1
2016-05-16 19:39:07 feed_L1 0.259
2016-05-16 19:39:07 power 0
2016-05-16 19:39:07 power_L1 0
2016-05-16 19:39:07 total_consumption_Ch1 73.217
2016-05-16 19:39:07 total_consumption_Ch2 26.572
2016-05-16 19:39:07 total_feed_Ch1 91.209
2016-05-16 19:39:07 total_feed_Ch2 154.517
Sofern bekannt ist, was diese Readings beinhalten, können sie mit dem channels-Attribut umbenannt werden.
zum obigen Beispiel:
attr <myDevice> channels {"1-0:22.7.0"=>"TestReading"}
Bei meinen bisherigen Tests mit euren Daten sind mir bislang keine Ungereimtheiten aufgefallen, ich hoffe, das bleibt auch so ^^
Frage an alle: Wollt ihr ein Attribut, mit dem man ungenutzte, unbekannte Readings auf "stumm" setzen kann? Oder ist das egal und ihr ignoriert diese Readings dann einfach?
lg, Stefan
Can I download the version for a test already?
If so, where?
{HT}
You can get it directly from the SVN.
https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/ (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/)
Nice.
A few problems, Time_current is not correct and not changed.
I used
attr SmartMeter event-on-change-reading Gas,total_consumption_Ch1,total_consumption_Ch2,total_feed_Ch1,total_feed_Ch2,Powerdrops,consumption,feed_L1,TariffIndicator
attr SmartMeter channels {"21"=>"consumption", "1"=>"power1", "15"=>"power16", "16"=>"power16", "0-0:96.14.0"=>"TariffIndicator", "Gas"=>"total_gas"}
"0-0:96.14.0"=>"TariffIndicator", "Gas"=>"total_gas" doesn't do anything. Is my syntax wrong?
(https://postimg.org/image/b4o3v2rpt/)
Hi
In the log I get:
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 0-0:96.1.1 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 0-0:96.14.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 0-0:96.7.21 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 0-1:24.1.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 0-1:96.1.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 1-0:22.7.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 1-0:32.32.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 1-0:32.36.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 1-0:99.97.0 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.05.16 22:36:33 3: WARNING: unsupported character in reading 1-3:0.2.8 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
{HT}
Hallo Stefan!
Danke für die neue Version des Moduls!!!!!!!! ;D ;D ;D
Jetzt funzt es auch bei meinem "tollen" Zähler.
Anbei zwei pics....
Einmal direkt nach dem anlegen und einmal mit den channel-Attribut.
DANKE !!!
Gruß,
Chris
Hi,
sorry, my mistake.
Uploaded the fixed version now.
For readings and the channel-attribute: All ":" and "-" are now converted to "."
So an OBIS-Number would look like 0.1.24.2.1
For the Gas-Reading: You have to give the OBIS-Number to the attribute, so correct is:
"0.1.24.2.1"=>"total_gas"
Have a nice evening,
Stefan
Hi Stefan,
ZitatFrage an alle: Wollt ihr ein Attribut, mit dem man ungenutzte, unbekannte Readings auf "stumm" setzen kann? Oder ist das egal und ihr ignoriert diese Readings dann einfach?
BITTE etwas zum stumm schalten, denn jetzt kommt allermöglicher Schrott als neues reading an >:(
Und dann hatte ich doch noch das Problem, dass ohne Angabe des metertypes nicht immer Standard resultiert. Systematik konnte ich keine feststellen. Mal gehts, mal nicht. Was ich aber feststellen konnte: Selbst wenn man es über ein modify durch ändern des metertypes=Standard korrigiert, bleibt der pollingmode=on außen vor. Warum auch immer. Ich hab jetzt einfach mal metertype=Standard in der cfg definiert und dann läufts auch wie geschmiert.
Grüße, Markus
Hi Stefan
Zitat von: Icinger am 17 Mai 2016, 20:27:51
Hi,
sorry, my mistake.
No problem, I am happy I can provide a bit help by testing. Thanks for all the work.
Zitat
Uploaded the fixed version now.
For readings and the channel-attribute: All ":" and "-" are now converted to "."
So an OBIS-Number would look like 0.1.24.2.1
For the Gas-Reading: You have to give the OBIS-Number to the attribute, so correct is:
"0.1.24.2.1"=>"total_gas"
Nice, this works fine.
However the old name Gas is still displayed in the detail page but not updated. The same for other names I don't use anymore. How to get rid of them? Resetting my desktop and my fritzbox (on which fhem is running) is not sufficient. Shutting FHEM down and removing the values from fhem.save and start FHEM again works but it doesn't look as the way how this should be handled. :-)
0.0.1.0.0 is still 01-01-1970 01:00:01 and that doesn't change. (It is the timestamp of the last message) If I remember correct this worked in the past.
Maybe you missed it, in
2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:24.2.1(160515180000S)(00041.661*m3)
160515180000S is the time of the last gas measurement. Is it possible to make a reading for it?
Zitat
Have a nice evening,
Stefan
Although it is a bit late, have a nice evening too.
BTW I don't mind to see the other readings which I don't know yet what they mean. Maybe I can find out if I see the values.
{HT}
ZitatShutting FHEM down and removing the values from fhem.save and start FHEM again works but it doesn't look as the way how this should be handled. :-)
similar, but more easy: delete the device(without saving fhem.cfg) - shutdown - restart - Voila
Regards, Markus
Hoi
Do you guys know this document?
http://files.domoticaforum.eu/uploads/Smartmetering/DSMR%20v4.0%20final%20P1.pdf
Now I only miss the meaning of code 1.0.22.7.0
{HT}
Just found the link below which gives a newer document:
http://nbn-assets.netbeheernederland.nl/32768/?k=aHyn8n3Kk9ch_GFgG7TdJk-DFCl-ZaBOna0WUSvqYBfhdggUuSR_pbVF6YbO6SYcWv6IjNhu4-uQCkkVTjXFiJaPWY1T_KytQrYJnnVLQdYOeBw6hGWkqpyZOGTKnhpin2aQD8CS6v3rtlya3Jx2X_4JEd2NV9RcbJaN_CQNppERAvqLFctIKjWN6FCgb6bQ56M9wRdgH5N_ssdkN5VHiiiK6_ZuXzgJEzLIG9gDOALQ-Q8-qCt9dum54l-RAToBRuYVOflju8sh970jmgi1Z4wMxr9fAAxTPAw2waJPthSws_mU4WSE2o_zQu5pngCCqxkkXbGnQCBxf7ReaJ9nHvl9fvRU8igWz9hM6pCl4PdozRoAxHMhmvmO4hRsAm62sr2mdqFlfOQGYLAmwO1cNP0zZo0tnLQm6lynS5ttBEyGsUoFNrBtf81Ad74MUCo3dlTQsMKVtbrEIjR3jrrwpsJgMMy1rhG4WwmtnF-aLqLSBB8YlAcx5Hw8xBPc588OK4LMTuKWfP7DxhaAYsxEvmhUbWERFjdLVSt84PqWMhkM9BSLRhVGDFTJmr_ydv5Zn1vFRnjbwKk_01RRiuiNGwjJm6glrcCVLj0jPNxQW6emC-FNU5DPg3W2w6JIHrKgcHl1cnriYkagbwhcKhaYFUTj8dMNiXlglp83Q0eAwH526iUxZy_KZIQ-sj_x4wJmdDjQ1fof_yPuVf5KtH9iZZDOYXdYqRLM5h0QNs4UhHfJcKQXtPtrOxDJne3KQMCx8ugcitkgw1dYDnbTe3HhEKV2GTvGRm0dMmc_T6aNszg=&u=
Zitatdelete the device(without saving fhem.cfg) - shutdown - restart - Voila
ZitatHowever the old name Gas is still displayed in the detail page but not updated. The same for other names I don't use anymore. How to get rid of them? Resetting my desktop and my fritzbox (on which fhem is running) is not sufficient. Shutting FHEM down and removing the values from fhem.save and start FHEM again works but it doesn't look as the way how this should be handled. :-)
???
That what's "deletereading" is for :D
Just a simple
deletereading <device> <reading-regexp>and everything is fine :D
Cheers,
Stefan
Zitat0.0.1.0.0 is still 01-01-1970 01:00:01 and that doesn't change. (It is the timestamp of the last message) If I remember correct this worked in the past.
No, this never worked....
I'm unsure, how to deal with that. Standard-OBIS should be a Unix-Timestamp, and also .
Your reading is a <ddmmyyhhmmss>-Format. Now sure how to distinguish that.
Same for
Zitat2016.05.15 18:10:03 5: OBIS (MyObis) - Msg-Parse: 0-1:24.2.1(160515180000S)(00041.661*m3)
That first pair of () would need a very special treatment.....
BTW. Just uploaded a new version with a "ignoreUnknown"-Attribute, so that unknown readings (x.x.x.x) are ignored.
If you use a channel-attribute, which covers this unknown readings, these are correctly handled.
Zitat von: Icinger am 18 Mai 2016, 06:09:53
No, this never worked....
I'm unsure, how to deal with that. Standard-OBIS should be a Unix-Timestamp, and also .
Your reading is a <ddmmyyhhmmss>-Format. Now sure how to distinguish that.
Same for That first pair of () would need a very special treatment.....
BTW. Just uploaded a new version with a "ignoreUnknown"-Attribute, so that unknown readings (x.x.x.x) are ignored.
If you use a channel-attribute, which covers this unknown readings, these are correctly handled.
Nice. With the channel attribute I also used
"1.0.2.8.1"=>"ElektriciteitsstandTerugleveringLaagtarief",
to overwrite the channel settings in the OBIS module. This works except it adds -Ch1 to the names. Is this intentional? No big deal if it stays this way.
The same for the dates. I like it to see the dates, but if it is to difficult, it is not a show stopper.
BTW, the OBIS module changed the last week from a simple module to a utility-module with much more possibilities. But it needs specific settings to work nice. I will post my settings as I think these will be a good starting point for almost every smartmeter user in the netherlands.
Thansk for all the fantastic work.
{HT}
Hi
Here are my settings for the 47_OBIS.pm module. I use a Landis E350 smartmeter with a BK-G4 ETB gasmeter in the Netherlands. Most likely it is compatible with other smartmeters in the Netherlands.
In my fhem.cfg:
define SmartMeter OBIS /dev/ttyUSB1@115200,8,N,1
attr SmartMeter channels {"0.0.1.0.0"=>"date-time_laatste_P1_bericht", "0.1.24.1.0"=>"_andere_apparaten_op_de_M-Bus", "0.1.24.2.1"=>"VerbruikteHoeveelheidGas", "0.1.96.1.0"=>"_identificatie_van_de_gasmeter", "0.0.96.1.1"=>"_equipment identifier", "0.0.96.7.9"=>"_number_of_long power_failures_in_any_phase", "0.0.96.7.21"=>"_number_of_power_failures_in_any_phase", "0.0.96.13.1"=>"BerichtNumeriek", "0.0.96.13.0"=>"BerichtTekst", "0.0.96.14.0"=>"ActueleTarief", "1.0.1.7.0"=>"HuidigVerbruik", "1.0.2.7.0"=>"HuidigTeruglevering", "1.0.1.8.1"=>"ElektriciteitsstandLaagtarief", "1.0.1.8.2"=>"ElektriciteitsstandNormaaltarief", "1.0.2.8.1"=>"ElektriciteitsstandTerugleveringLaagtarief", "1.0.2.8.2"=>"ElektriciteitsstandTerugleveringNormaaltarief", "1.0.21.7.0"=>"_Instantaneous_active_power_L1_+P_in_W_resolution", "1.0.22.7.0"=>"_Instantaneous_active_power_L1_-P_in_W_resolution", "1.0.32.32.0"=>"_number_of_voltage_sags_in_phase_L1", "1.0.32.36.0"=>"_number_of_voltage_swells_in_phase_L1", "1.0.99.97.0"=>"_power_Failure_Event_Log_long_power_failures", "1.0.31.7.0"=>"_instantaneous_current_L1_-P", "1.3.0.2.8"=>"_DSMR_version_ 4.0"}
attr SmartMeter event-on-change-reading VerbruikteHoeveelheidGas,BerichtNumeriek,BerichtTekst,ActueleTarief,HuidigVerbruik,HuidigTeruglevering,ElektriciteitsstandLaagtarief_Ch1,ElektriciteitsstandNormaaltarief_Ch2,ElektriciteitsstandTerugleveringLaagtarief_Ch1, ElektriciteitsstandTerugleveringNormaaltarief_Ch2
attr SmartMeter room Sturing
#attr SmartMeter verbose 5
define FileLog_SmartMeter FileLog ../USB-LOGGING/logs/fhem/%Y-%m-SmartMeter.log SmartMeter
attr FileLog_SmartMeter logtype text
attr FileLog_SmartMeter room Sturing
define weblink_SmartMeter SVG FileLog_SmartMeter:mySmartMeter:CURRENT
attr weblink_SmartMeter label "SmartMeter Max $data{max1}, Last $data{currval1}"
attr weblink_SmartMeter room Plots
And I have a plot file fhem/www/gplot/mySmartMeter.gplot
# Created by FHEM/98_SVG.pm, 2016-05-18 22:16:37
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics nomirror
set y2tics
set grid ytics y2tics
set ylabel "kW"
set y2label "m3"
#FileLog_SmartMeter 4:SmartMeter.HuidigTeruglevering\x3a:1:
#FileLog_SmartMeter 4:SmartMeter.HuidigVerbruik\x3a:1:
#FileLog_SmartMeter 4:SmartMeter.VerbruikteHoeveelheidGas\x3a:1:
plot "<IN>" using 1:2 axes x1y1 title 'kW geleverd' ls l1fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'kW gebruikt' ls l0fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'm3 gebruikt' ls l3 lw 1 with lines
Hope this helps people to start with the 47_OBIS module
{HT}
Hi Stefan
After the latest update I get these error messages:
2016.05.19 22:14:22 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 335.
2016.05.19 22:14:22 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 336.
2016.05.19 22:14:22 1: PERL WARNING: Use of uninitialized value $channel in hash element at ./FHEM/47_OBIS.pm line 408.
2016.05.19 22:14:22 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 408.
{HT}
Hi Harry,
a little bit mor Info would be great :)
Just a Verbose 5 of the Data please.
Cheers, Stefan
Zitat von: Icinger am 20 Mai 2016, 05:56:29
Hi Harry,
a little bit mor Info would be great :)
Just a Verbose 5 of the Data please.
Cheers, Stefan
Hi Stefan
It looks as if verbose 5 doesn't give more info, but there is another line in the log which might be usefull:
Constant subroutine main::URL redefined at /var/InternerSpeicher/fhem/lib/perl5/5.12.2/constant.pm line 130, <$fh> line 444.
main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 623, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
2016.05.20 14:36:52 3: Opening SmartMeter device /dev/ttyUSB1
2016.05.20 14:36:52 3: Setting SmartMeter serial parameters to 115200,8,N,1
2016.05.20 14:36:52 3: SmartMeter device opened
2016.05.20 14:36:55 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2016.05.20 14:36:57 1: Including ./fhem.save
2016.05.20 14:36:58 1: usb create starting
2016.05.20 14:37:01 1: usb create end
2016.05.20 14:37:01 0: Featurelevel: 5.7
2016.05.20 14:37:01 0: Server started with 162 defined entities (fhem.pl:11256/2016-04-16 perl:5.012002 os:linux user:root pid:24400)
2016.05.20 14:37:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2016.05.20 14:37:01 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 335.
2016.05.20 14:37:01 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 336.
2016.05.20 14:37:01 1: PERL WARNING: Use of uninitialized value $channel in hash element at ./FHEM/47_OBIS.pm line 408.
2016.05.20 14:37:01 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 408.
And with verbose 5:
2016.05.20 14:42:45 0: Server shutdown
Useless use of a constant (myTwilight) in void context at ./FHEM/99_myUtils.pm line 39.
Useless use of a constant (twilight) in void context at ./FHEM/99_myUtils.pm line 39.
Useless use of a constant (myTwilight) in void context at ./FHEM/99_myUtils.pm line 40.
Useless use of a constant (twilight_weather) in void context at ./FHEM/99_myUtils.pm line 40.
main::GetOutsideWeather() called too early to check prototype at ./FHEM/99_myUtils.pm line 24.
2016.05.20 14:42:50 1: Including fhem.cfg
2016.05.20 14:42:51 3: telnetPort: port 7072 opened
2016.05.20 14:42:52 3: WEB: port 8083 opened
2016.05.20 14:42:52 3: WEBphone: port 8084 opened
2016.05.20 14:42:52 3: WEBtablet: port 8085 opened
2016.05.20 14:42:52 3: Opening RFXTRXUSB device /dev/ttyUSB0
2016.05.20 14:42:53 3: RFXTRXUSB device opened
2016.05.20 14:42:56 1: TRX: Initialization Error hexline='0873ff', expected 0d0100......................
2016.05.20 14:42:56 1: Cannot init /dev/ttyUSB0, ignoring it (RFXTRXUSB)
2016.05.20 14:42:56 3: Opening TRX_0 device /dev/ttyUSB0
2016.05.20 14:42:56 3: Setting TRX_0 serial parameters to 38400,8,N,1
2016.05.20 14:42:56 3: TRX_0 device opened
2016.05.20 14:42:58 1: TRX: Init OK
2016.05.20 14:42:58 1: TRX: Init status: '433.92MHz transceiver, firmware=64, protocols enabled: Lighting4 LaCrosse Hideki Visonic OREGON HOMEEASY AC X10 '
2016.05.20 14:42:58 3: Opening ZWDongle_0 device /dev/ttyACM0
2016.05.20 14:42:58 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2016.05.20 14:42:58 3: ZWDongle_0 device opened
2016.05.20 14:43:03 3: owo mijnWeer: created
Constant subroutine main::URL redefined at /var/InternerSpeicher/fhem/lib/perl5/5.12.2/constant.pm line 130, <$fh> line 444.
main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 623, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
2016.05.20 14:43:04 3: Opening SmartMeter device /dev/ttyUSB1
2016.05.20 14:43:04 3: Setting SmartMeter serial parameters to 115200,8,N,1
2016.05.20 14:43:04 3: SmartMeter device opened
2016.05.20 14:43:07 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2016.05.20 14:43:09 1: Including ./fhem.save
2016.05.20 14:43:10 1: usb create starting
2016.05.20 14:43:13 1: usb create end
2016.05.20 14:43:13 0: Featurelevel: 5.7
2016.05.20 14:43:13 0: Server started with 162 defined entities (fhem.pl:11256/2016-04-16 perl:5.012002 os:linux user:root pid:24618)
2016.05.20 14:43:13 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse:
/XMX5LGBBFG1009198749
2016.05.20 14:43:13 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 335.
2016.05.20 14:43:13 1: PERL WARNING: Use of uninitialized value $channel in substitution (s///) at ./FHEM/47_OBIS.pm line 336.
2016.05.20 14:43:13 1: PERL WARNING: Use of uninitialized value $channel in hash element at ./FHEM/47_OBIS.pm line 408.
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse:
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-3:0.2.8(42)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:1.0.0(160520144306S)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.1.1(4530303331303033313438313939363135)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:1.8.1(000090.025*kWh)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:1.8.2(000031.211*kWh)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:2.8.1(000098.284*kWh)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:2.8.2(000192.568*kWh)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.14.0(0002)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:1.7.0(00.000*kW)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:2.7.0(00.628*kW)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.7.21(00001)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.7.9(00000)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:99.97.0(0)(0-0:96.7.19)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:32.32.0(00000)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:32.36.0(00000)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.13.1()
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-0:96.13.0()
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:31.7.0(004*A)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:21.7.0(00.000*kW)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 1-0:22.7.0(00.798*kW)
2016.05.20 14:43:13 5: OBIS (SmartMeter) - Msg-Parse: 0-1:24.1.0(003)
2016.05.20 14:43:21 5: OBIS (SmartMeter) - Msg-Parse: 0-1:96.1.0(4730303235303033333630333031323136)
2016.05.20 14:43:21 5: OBIS (SmartMeter) - Msg-Parse: 0-1:24.2.1(160520140000S)(00043.563*m3)
2016.05.20 14:43:21 5: OBIS (SmartMeter) - Msg-Parse: !C02C
2016.05.20 14:43:21 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 408.
2016.05.20 14:43:21 5: OBIS (SmartMeter) - Msg-Parse: /XMX5LGBBFG1009198749
Hope thise helps
{HT}
Hi guys,
hope everything works now? Uploaded a new version 3 Days ago to fix this Startup-Problem.
Any complains?
Sunny Sunday,
Stefan
Hi Stefan
Just updated to the latest version.
Right after the start I get:
Constant subroutine main::URL redefined at /var/InternerSpeicher/fhem/lib/perl5/5.12.2/constant.pm line 130, <$fh> line 444.
main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 629, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 129, <$fh> line 507.
2016.05.22 13:09:21 3: Opening SmartMeter device /dev/ttyUSB1
2016.05.22 13:09:21 3: Setting SmartMeter serial parameters to 115200,8,N,1
2016.05.22 13:09:21 3: SmartMeter device opened
But the module works nice.
There is an isssue, but I don't know if this is in the smartmeter or in your module:
2016-05-22_12:29:00 SmartMeter CurConsume: 2.267
2016-05-22_12:29:10 SmartMeter CurConsume: 2.127
2016-05-22_12:29:20 SmartMeter CurConsume: 0
2016-05-22_12:29:20 SmartMeter CurFeed: 2.244
2016-05-22_12:29:30 SmartMeter CurFeed: 0.391
2016-05-22_12:29:40 SmartMeter CurFeed: 0.627
The measurements on 12:29:20 can't be right. They should be the opposite. I have seen more strange readigns, but not investigated them. These are simply impossible. It seems there is sometimes an issue when there is a switch from consume to feed.
Further I didn't find a way to get the time of the last changed readings. It is show on the webinterface, but when I use ReadingsTimestamp("SmartMeter","HuidigVerbruik","0") I simply get the last time SmartMeter did on update. Not the last change. Is there a way to get the last change of a reading? I use event-on-change.
{HT}
Hallo zusammen,
ich habe das Modul zum Auslesen unseres Stromzählers im Einsatz, funktioniert hervorragend.
Ich habe nun festgestellt, dass unser Wärmemengenzähler Landis Gyr T550 Ultraheat ebenfalls über diese Schnittstelle verfügt. Etwas naiv dachte ich mir dann, ich könnte dieses Modul ebenfalls hierfür verwenden, muss nur die channels anpassen........weit bin ich also nicht gekommen ;-)
Doku habe ich keine gefunden, und am USB-Port mitlauschen brachte nichts.
Somit meine Frage an die Experten: Ist es überhaupt möglich, dieses Modul zum Tracken des Wärmemengenzählers zu verwenden?
Ich habe bei einem anderen Projekt folgenden Eintrag gefunden:
http://www.sedelmaier.at/content/siemens-uh50-landisgyr-ultraheat-t550-mit-openhab
https://github.com/lolodomo/openhab/commit/4aefdde25c11b751f92654526d814ae2920e10da
Hat jemand eine Idee, ob und wie ich das lösen kann?
Bin für jeden Tipp dankbar
Vielen Dank udn Grüsse
klaso
dann gib doch erst mal Deine Erkenntnisse über den Zähler bekannt: muss er erst zum Senden animiert werden, pushed er, kommt irgend was mit verbose 5 im Log ? List des device.......
Grüße, Markus
Aus dem zweiten Link:
private static final byte[] REQUEST_MESSAGE = new byte[] { (byte) 0x2F, (byte) 0x3F, (byte) 0x21, (byte) 0x0D,
(byte) 0x0A };
private static final byte[] ACKNOWLEDGE = new byte[] { (byte) 0x06, (byte) 0x30, (byte) 0x30, (byte) 0x30,
(byte) 0x0D, (byte) 0x0A };
Sieht danach aus, als ob die Abfrage angestossen werden muss.
Würde mal mit Metertyp=VSM102 testen zB.
lg, Stefan
Hallo,
ich habe mit unterschiedlichen Metertyp getestet, bei Metertyp VSM102 wird mit list MyObis zumindest etwas unter devices angezeigt, bei Metertyp Standard oder SML wird dort garnichts angezeigt.
Meine cfg:
define MyObis OBIS /dev/ttyUSB0@9600,8,N,1 VSM102
attr MyObis event-on-change-reading
attr MyObis verbose 5
define FileLog_MyObis FileLog ./log/%Y-%m-MyObis.log MyObis
attr FileLog_MyObis logtype text
andere Bautrate habe ich auch mal versucht => keine Änderung
das myObis-Log bleibt leer
im fhem-Log sehe ich folgendes:
2016.05.28 20:49:03.071 5: Cmd: >define MyObis OBIS /dev/ttyUSB0@9600,8,N,1 VSM102<
2016.05.28 20:49:03.071 5: Loading ./FHEM/47_OBIS.pm
2016.05.28 20:49:03.095 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 360, <$fh> line 44.
2016.05.28 20:49:03.112 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 629, <$fh> line 44.
2016.05.28 20:49:03.142 5: OBIS (MyObis) - Internal timer set to 2016-05-28 20:59:03
2016.05.28 20:49:03.143 5: OBIS (MyObis) - Opening device...
2016.05.28 20:49:03.143 3: Opening MyObis device /dev/ttyUSB0
2016.05.28 20:49:03.241 3: Setting MyObis serial parameters to 9600,8,N,1
2016.05.28 20:49:03.250 3: MyObis device opened
2016.05.28 20:49:03.251 5: Cmd: >attr MyObis event-on-change-reading<
2016.05.28 20:49:03.252 5: Cmd: >attr MyObis verbose 5<
2016.05.28 20:49:03.253 5: Cmd: >define FileLog_MyObis FileLog ./log/%Y-%m-MyObis.log MyObis<
2016.05.28 20:49:03.254 5: Cmd: >attr FileLog_MyObis logtype text<
2016.05.28 20:49:03.256 1: Including /opt/fhem/log/fhem.save
2016.05.28 20:49:03.256 5: Cmd: >setstate FileLog_MyObis active<
2016.05.28 20:49:03.257 5: Cmd: >setstate Logfile active<
2016.05.28 20:49:03.258 5: Cmd: >setstate MyObis opened<
2016.05.28 20:49:03.258 5: Cmd: >setstate MyObis 2016-05-28 20:48:42 state opened<
2016.05.28 20:49:03.259 5: Cmd: >setstate autocreate active<
2016.05.28 20:49:03.259 5: Cmd: >setstate eventTypes active<
2016.05.28 20:49:03.260 5: Cmd: >setstate global <no definition><
2016.05.28 20:49:03.261 5: Triggering global (1 changes)
2016.05.28 20:49:03.261 5: Starting notify loop for global, first event INITIALIZED
2016.05.28 20:49:03.262 2: Messages collected while initializing FHEM
2016.05.28 20:49:03.265 0: Featurelevel: 5.7
list MyObis
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 VSM102
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 10
MeterType VSM102
NAME MyObis
NR 25
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-05-28 20:49:03 state opened
Helper:
EoM -1
SPEED 5
TRIGGERTIME 1464461343.14236
DEVICES:
/?!
600
050
ich finde zu diesem WMZ nur sehr "allgemiene" Informationen, bzw. Infos in welcher Ausstattung es diesen Zähler gibt. Ich habe keinerlei Infos gefunden zu Protokollen, etc. ( nur den oben erwähnten Beitrag in Verbindung mit Obenhab; aber dieses hatte ich schon, ich bleib bei fhem ;-) )
VG
klaso
Argh, schon wieder so ein Kauderwelsch:
/LUGCUH50
6.8(0074900*kWh)6.26(04142.48*m3)9.21(66409080)
6.26*01(03957.55*m3)6.8*01(0071925*kWh)
F(0)9.20(66409080)6.35(60*m)
6.6(0016.2*kW)6.6*01(0015.3*kW)6.33(001.608*m3ph)9.4(094.4*C&092.9*C)
6.31(0046124*h)6.32(0000000*h)9.22(R)9.6(000&66409080&0&000&66409080&0)
9.7(60000)6.32*01(0000000*h)6.36(01-01&00:00)6.33*01(001.608*m3ph)
6.8.1()6.8.2()6.8.3()6.8.4()6.8.5()
6.8.1*01()6.8.2*01()6.8.3*01()
6.8.4*01()6.8.5*01()
9.4*01(094.4*C&092.9*C)
6.36.1(2016-01-18)6.36.1*01(2011-07-13)
6.36.2(2015-01-07)6.36.2*01(2015-01-07)
6.36.3(2014-12-23)6.36.3*01(2014-12-23)
6.36.4(2014-03-14)6.36.4*01(2014-03-14)
6.36.5()6.36*02(01&00:00)9.36(2016-02-12&19:36:08)9.24(1.5*m3ph)
9.17(0)9.18()9.19()9.25()
9.1(0&1&0&0000&CECV&CECV&1&5.16&5.16&F&101008&1>1>04&08&0)
9.2(&&)9.29()9.31(0014842*h)
9.0.1(00000000)9.0.2(00000000)9.34.1(000.00000*m3)9.34.2(000.00000*m3)
8.26.1(00000000*m3)8.26.2(00000000*m3)
8.26.1*01(00000000*m3)8.26.2*01(00000000*m3)
6.26.1()6.26.4()6.26.5()
6.26.1*01()6.26.4*01()6.26.5*01()0.0(66409080)
!
Hier steht was darüber:
http://www.sedelmaier.at/node/112 (http://www.sedelmaier.at/node/112)
Vielen Dank, ich werde mich mal daran versuchen ;-)
VG
klaso
Hi Stefan,
wenn ich es so richtig verstanden habe, hast Du ja früher auf x.y.z*255 für einen gültigen OBIS-Code abgefragt. Dann hatte dbox2user das Problem, dass dessen Zähler x.y.z*00 ausgibt und Du hattest dann den rexgexp so umgestellt, dass(spekuliere ich) alle numerischen Werte hinter dem * als gültig erkannt werden. Nun hat hier:
https://forum.fhem.de/index.php/topic,53906.0.html
jemand einen Zähler, der historische Werte mit x.y.z*ab(ab=01-20) liefert. Viel schlimmer scheint aber noch zu sein, dass der aktuelle Wert lediglich mit x.y.z, also ohne *irgendwas kommt. In den Readings steht natürlich mit der jetzigen Version immer einer der zuletzt gelesenen historischen und nicht der aktuelle Werte.
Lässt sich da etwas Sinnvolles z.B. über den metertype machen ? Oder über ein neues Attribut attr currValue mit "*255" für Standard, "*00" für den Fall von dbox2user und "" für diesen neuen Fall ?
Schönes RestWochenende, Markus
Hi Markus,
hab im anderen Thread schon geantwortet.
Ich überlege grade, was das kleinere Übel der beiden Lösungen ist, die mir grade einfallen:
1) Universeller, aber schlecht, weils alle bisherigen Nutzer betrifft:
das "*xxx" in die RegEx mitaufnehmen, somit würde für jede Zeile dann ein zusätzliches Reading erstellt, welches auch mit dem Channel-Attribut gemappt werden kann.
2) Spezieller, aber betrifft eben nur die Nutzer dieses einen Meters:
einen neuen Metertyp, und für diesen dann alle RegExes im Modul einzeln anpassen.
Ausserdem überlege ich grade, wie ich das mit der Baudrate machen könnte.
Grundsätzlich kann in der ersten Antwort ans Meter die zukünftige Baudrate mitgegeben werden.
Würde aber bedeuten, dass ich zuerst die Schnittstelle mit der Baudrate, die im define angegeben ist, öffnen muss, dann das Init schicken, und danach irgendwoher die Info bekommen muss, auf welche neue Speed der User denn umsteigen will.
Da dieses Init in der Define-Routine gesendet wird, kommt ein eventuelles Attribut leider zu spät.
Also entweder eine zusätzliche, optionale Angabe im Define-String, oder die Baudrate nach dem Init fix auf die höchstmögliche Geschwindigkeit setzen (was mir aber nicht so wirklich gefällt)
lg, Stefan
sind ja erst 10 Nutzer und mit einem kleinen Kommentar beim Update..... ;)
Mit der Baudrate würd ich mir nicht so den Kopf machen. Wenn ich das so richtig gesehen habe, hat der Zähler keine Leistungsdaten und was will man dann mit häufigeren Updates der readings ?
Schönen Abend & Danke, Markus
Guten Morgen.
habe grade die neueste Version commited.
Neuigkeiten:
1) Auch solche Daten sollten jetzt erkannt werden:
+6.36.1(2016-01-18)
6.36.1*01(2011-07-13)
6.36.2(2015-01-07)
6.36.2*01(2015-01-07)
Es wird für JEDEN Datensatz ein reading angelegt. Wenn es zuviele werden, könnt ihr sie mit dem >channel"-Attribut mappen und dann "ignoreUnknown" setzen :)
2) Ein neues Attribut "bracketValue": Kann "first", "second" oder "both" sein.
Je nachdem, wird bei Datensätzen, die zwei Klammerpaare beinhalten, der erste oder zweite Wert genommen.
Bei "both" werden für beide Werte readings angelegt, jeweils mit "_1" und "_2"-Suffix.
zB:
0-1:24.2.1(160520140000S)(00043.563*m3)
lg, Stefan
Hallo Stefan,
nach knapp 24h Einsatz des geänderten Moduls, läuft es mit meinem pushenden Zähler stabil. Allerdings ist heute Nacht das erste Mal das passiert, was ich befürchtet hatte: ein "Schrottdatensatz" ist verarbeitet worden und hat ein Reading angelegt:
1.0.961.7.0*255 0.34 2016-06-06 04:19:35
Wenn ich jetzt für jedes neuerliche Schrott-Reading ein channel-Attribut setzen muss, um es auszuschließen, wird das arg zäh.
Da fand ich den vorherigen generellen Ausschluss sinnvoller.
Denkst Du auch noch an die Beseitigung der Log-Meldungen beim FHEM-Start:
2016.06.05 12:32:47 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 657, <> line 162
2016.06.05 12:32:59 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 410.
2016.06.05 12:32:59 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 439
Grüße, Markus
Edit: und das kommt jetzt bei einem restart:
2016.06.06 08:56:13 3: WARNING: unsupported character in reading 1.0.0.0.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.06 08:56:13 3: WARNING: unsupported character in reading 1.0.96.5.5*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.06 08:56:13 3: WARNING: unsupported character in reading 1.0.961.7.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
ZitatWenn ich jetzt für jedes neuerliche Schrott-Reading ein channel-Attribut setzen muss, um es auszuschließen, wird das arg zäh.
Da fand ich den vorherigen generellen Ausschluss sinnvoller.
Das gibts doch eh noch, setz einfach das "ignoreUnknown" auf on 8)
ZitatEdit: und das kommt jetzt bei einem restart:
Das wird vmtl. am statefile liegen, in dem noch Readingsleichen liegen.
Am einfachsten wär's, das komplette Device zu löschen und neu anzulegen.
zB die aktuelle Definition aus der Config kopieren, dann löschen, und dann wieder zB per Telnet copy&paste neu anzulegen.
Hmm, die Start-Meldungen kommen immer noch? Dachte eigentlich, die hätte ich endlich weg.
Da bin ich momentan aber echt mit meinem Latein am Ende, kA wo die noch herkommen :(
lg, Stefan
ZitatDas gibts doch eh noch, setz einfach das "ignoreUnknown" auf on 8)
Hab ich doch >:(
Ich hatte Dich so verstanden, dass vermeintlich neue OBIS-Codes(also auch Schrott) erst einmal angelegt werden(wie auch immer das praktisch funktionieren sollte)
Aber warum hat dann das ignoreUnknown nicht funktioniert ? :(
2 früher erzeugte (aber unbedeutende) readings waren immer mit z.B. "1.0.0.0.0" angelegt worden. Mit der neuen Version mit "1.0.0.0.0*255". Das dachte ich wäre so gewollt. Aber hilft vielleicht eine Einschränkung zu definieren ? Im Moment lässt Du ja alles Mögliche zu, damit auch die Exoten(warum ist OBIS eigentlich ein Standard, wenn sich keiner dran hält) bedient werden.
ZitatDas wird vmtl. am statefile liegen, in dem noch Readingsleichen liegen.
Die haue ich morgen mal nach einem shutdown raus und restarte manuell. Werde berichten.
Gute Nacht
Edit: Da wolltest Du mich wohl aufs Glatteis führen ;D Die vermeintlichen Readingsleichen sind gar keine Leichen, sondern exakt die Readings, erzeugt durch die neue Version, die ich gar nicht haben möchte :'(
Hi,
mit dem morgigen Update sollten diese unbeliebten x.x.x-Readings der Vergangenheit angehören.
Genauso wie die
2016.06.06 08:56:13 3: WARNING: unsupported character in reading 1.0.0.0.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.Fehlermeldungen.
lg, Stefan
Und das
Zitatwarum ist OBIS eigentlich ein Standard, wenn sich keiner dran hält
frag ich mich schon lange ^^
Zitat von: Icinger am 09 Juni 2016, 19:50:20
Hi,
mit dem morgigen Update sollten diese unbeliebten x.x.x-Readings der Vergangenheit angehören.
Genauso wie die
2016.06.06 08:56:13 3: WARNING: unsupported character in reading 1.0.0.0.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
Fehlermeldungen.
lg, Stefan
Und dasfrag ich mich schon lange ^^
Hi Icinger,
leider existiert das Problem nach dem Update weiterhin. Es ist sogar noch schlimmer geworden - bei mir existieren weiterhin die Fehlermeldungen und zusätzlich doppelt so viele Readings wie zuvor:
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 1.0.0.0.9*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 1.0.36.7.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 1.0.56.7.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 1.0.76.7.0*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 129.129.199.130.3*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2016.06.10 22:34:59 3: WARNING: unsupported character in reading 129.129.199.130.5*255 (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
Hi. Bin arbeiten....aber hast du die "alten" readings auch sichet gelöscht? Bei mir funktioenierts mit div. Testdaten einwandfrei.
Lg stefan
Gesendet von meinem SM-N9005 mit Tapatalk
Sagt bitte mal: Welche Hardware/Selbstbauanleitung könntet ihr evtl. empfehlen, wenn ich meinen Easymeter mittels Raspberry auslesen will?
Bisher hatte ich mich am anderen Thread https://forum.fhem.de/index.php?topic=48143.0 orientieren wollen. Aber vielleicht habt ihr ja noch einen guten Tipp. Danke.
Vorkonfektionierten IR-Lesekopf beim Fachhändler/Elektriker z.B. von Hager, ABN..... und an einen RS232/USB-Wandler. Funktionioniert problemlos bei meinem Hager ehz.
Grüße, Markus
Zitat von: FunkOdyssey am 11 Juni 2016, 22:33:53
Sagt bitte mal: Welche Hardware/Selbstbauanleitung könntet ihr evtl. empfehlen, wenn ich meinen Easymeter mittels Raspberry auslesen will?
Den von Udo aus dem Volkszähler-Projekt gibt es als Bausatz und Fertiggerät. (empfehlenswert/preiswert) 8)
http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-usb-ausgang (http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-usb-ausgang)
Gruß Friedrich
Hi Stefan,
hab dann auch jetzt nach mehrtätigem Tests Infos zum Verhalten der neuen Version:
- "Schrottreadings A la 47.1.1*255 sind nicht mehr aufgetaucht, aber
- sporadisch werden 2 readings erzeugt/update
feed_L1, wo eine Spannung und power wo eine Stromstärke drin steht. "gesamt" power hat der zähler aber gar nicht und alle Phasen-Kennzahlen(Leistung,Spannung,Stromstärke) sind gemappt und funktionieren auch.
ne Idee ?
Grüße, Markus
Hallo zusammen,
erst mal Daumen Hoch! Cooles Modul.
Ich hatte bislang VolksZaehler am laufen, doch der schrottet mit alle Naselang mit den vielen Schreibzyklen die SD im RasPi.
Jetzt dachte ich mir, wenn man sowieso schon mal neu macht, fangen wir doch bei fhem an :) Das Modul hat auf anhieb geklappt.
Nun stelle ich mir aber die Frage, wie sinnvoll loggen/plotten/berechnen?
Ich moechte auf jeden fall grafische Darstellungen des Verbrauchs und der Einspeisung haben. Den Wechselrichter habe ich bereits in fhem.
Den Eigenverbrauch muss ich dann noch irgendwie berechnen... (Consumption = Generation + Import - Export) Das koennte ich evtl mit DOIF.
Was mir jetzt noch fehlt ist eine Moeglichkeit die Daten sinnvoll zu speichern...
Any Ideas?
was meinst Du mit
ZitatWas mir jetzt noch fehlt ist eine Moeglichkeit die Daten sinnvoll zu speichern...
Logging in File oder DB !
Ein userReading Consumption löst besser als ein doif Deinen Wunsch, sofern Du die "Generation" irgendwo her hast. Ich synchronisiere, indem ich das align Attr nutze und 1 sek. vorher die Wechselricherdaten polle. Geht ganz gut mit kleineren Unsauberkeiten.
siehe hier: https://forum.fhem.de/index.php/topic,50661.msg422886.html#msg422886
Grüße, Markus
Interessanter Ansatz :)
das ich die Daten in DB oder File speichern kann weiß ich. Das habe ich ja vorher mit dem Volkszaehler schon gemacht.
Das problem ist nur der Zyklus... bei einer sekuendlichen Aktualisierung macht das Pro Wert 86400 Eintraege pro Tag. Das ist ein Datenberg und eine Anzahl an Schreibzugriffen, die ich nicht haben moechte. Ich wuerde lieber alle 5-10 Minuten den Wert fuer den Eigenverbrauch irgendwoher mitteln und speichern. Davon haette ich ehrlich gesagt mehr.
Die Generation habe ich. Aktuell errechne ich das per DOIF, aber egal womit, es gibt jede Sekunde eine Neuberechnung. ???
[EDIT]
Gruß, ebenso Markus ;)
irgendwie gibt es hier fast nur Markus ;)
ZitatDas problem ist nur der Zyklus...
Wobei ? Generation oder zaehler-Daten ? statistische Werte ggfs. mit dem statistics modul. Ich logge minütlich(interval=60) mit den dann jeweils aktuellen Werten. Das reicht für aussagekräftige plots. Den tatsächlichen Verbrauch speichere ich kumulierend in einem User-Reading, das ich nächtlich zurücksetze und in einem separaten Log.
Grüße, Markus
Zitat von: KölnSolar am 15 Juni 2016, 14:04:11
irgendwie gibt es hier fast nur Markus ;) Wobei ? Generation oder zaehler-Daten ? statistische Werte ggfs. mit dem statistics modul. Ich logge minütlich(interval=60) mit den dann jeweils aktuellen Werten. Das reicht für aussagekräftige plots. Den tatsächlichen Verbrauch speichere ich kumulierend in einem User-Reading, das ich nächtlich zurücksetze und in einem separaten Log.
Grüße, Markus
Mehr Details bitte :)
UserReading bekomme ich hin...
Mein "Endziel" ist es, eine Auswertung zu haben, in welchem Monat wieviel erzeugt, eingespeist, bezogen und direkt verbraucht wurde.
Ich habe auf pvoutput.org bereits meine PV Daten archiviert, wenn ich da jetzt noch einen sinnvollen Eigenverbrauchswert dazu bekomme, waere mir viel geholfen.
Also entweder alles in FHEM oder alles zu pvoutput.org uebertragen aber in beiden Faellen scheint viel Bastelarbeit vorzuherrschen.
Wie gesagt, das statistics Modul. Ist sehr mächtig und liefert Durchschnitts-, als auch kumulierte Werte(siehe commandref). Zu Pvout kann ich nix sagen, ob man da einen Wert rüberschieben kann.
Have fun, Markus
Ich werd mal sehen was ich rausholen kann :)
Danke,
Markus
Zitat von: Icinger am 29 Mai 2016, 21:05:33
....
Ausserdem überlege ich grade, wie ich das mit der Baudrate machen könnte.
Grundsätzlich kann in der ersten Antwort ans Meter die zukünftige Baudrate mitgegeben werden.
Würde aber bedeuten, dass ich zuerst die Schnittstelle mit der Baudrate, die im define angegeben ist, öffnen muss, dann das Init schicken, und danach irgendwoher die Info bekommen muss, auf welche neue Speed der User denn umsteigen will.
...
Hallo Icinger,
ich habe einen Siemens TD3511 dieser wird zur Zeit über ein perlscript ausgelesen. Dieser kann auf 9600 oder 19200 umgeschaltet werden. Die Erstinitialisierung erfolgt immer mit 300 Baud. Damit der TD3511 Daten sendet wird ein Initstring gesendet. Ich habe schon etwas angefangen ein vorhandenes Modul anzupassen, bekomme aber die Umschaltung auf die höhere Baudrate nicht hin und mit 300 auslesen dauert zu lange. Vielleicht hast du ja eine Idee.
Hier und hier sind noch ein einige Angaben: https://forum.fhem.de/index.php/topic,14117.msg286358.html#msg286358
https://forum.fhem.de/index.php/topic,14117.msg284254.html#msg284254
Aufruf Perlscript 99_TD3511.pl in FHEM:
define TD3511 at +*00:01:00 {fhem "trigger TD3511 ".`FHEM/99_TD3511.pl &`}
define FileLog_TD3511 FileLog ./log/TD3511Log-%Y-%m.log TD3511
attr FileLog_TD3511 room HausZaehler
define SVG_FileLog_TD3511_1 SVG FileLog_TD3511:SVG_FileLog_TD3511_1:CURRENT
attr SVG_FileLog_TD3511_1 room HausZaehler
Mit dem Modul 70_TD3511.pm habe ich es in FHEM direkt versucht, habe aber noch nicht die Umschaltung hinbekommen und deshalb auch noch nicht wieder weitergemacht.
pejonp
Hallo Icinger,
habe hier in seltsames Problem. Nach einem FHEM update funktioniert meine Datenerfassung über das OBIS Modul nicht mehr.
FHEM stürzt einfach ab.
Meine Einbindung war:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK05HFPL-if00-port0@300,7,E,1 VSM102
Sobald ich aus der Definition nun VSM102 lösche, ist der Status des Device zwar open, aber es kommen keine Daten mehr.
Bin am verzweifeln.
Kann jemand helfen?
Gruß
Willi
Guten Morgen, Willy,
hmmm, in letzter Zeit hat sich eigentlich nichts geändert am OBIS.
Wann war dein letztes Update?
Bekommst du irgendwas mit Verbose 5 oder Stacktrace im Logfile?
lg, Stefan
Hi
habe auch gerade festgestellt das mir ObisvSchrott Readings erzeugt hat.
deletereading Strom 0*255
funktioniert leider nicht.
ignore unknown habe ich aktiviert.
irgendwelche Ideen?
Guten Morgen,
sorry, dass ich euch das damals mit den Schrott-Readings angetan hatte :)
deletereading Strom 0*255
kann nicht gehn, weil das * als RegEx-Quantifyer bewertet wird.
Möglichkeit 1: Mit
deletereading Strom .*
einmalig alle Reading löschen und neu anlegen lassen
Möglichkeit 2: Mit
deletereading Strom .*\*.*
müssten alle Readings, die ein * beinhalten, * gelöscht werden.
lg, Stefan
Dafür nicht wenigstens geht es weiter auf dem Weg zur Weltherrschaft ;D
in der Commandref stand nicht drinne das man mit .* alle löscht wäre vielleicht ganz nett ;)
Stimmt, da steht zwar nicht, dass mann mit .* alle löscht, aber es steht:
Zitat<readingname> ist ein perl Regular-Expression.......
8)
lg, Stefan
würde für meinen ED300L auch gerne die Daten auswerten.
Welche Hardware benötige ich da?
Danke
Laut Datenblatt hat der ja eh eine
ZitatRS232 elektrische bidirektionale Datenschnittstelle (MSB-Schnittstelle) zur Datenauslesung und Einstellung des Zählers (push-pull-Betrieb)
Somit also nur ein serielles Kabel zu deinem Rechner, und ab geht die Post :D
lg, Stefan
Hallo,
ich nutze das OBIS Modul seit einiger Zeit als Ablösung für das SMLUSB Modul für den Stromzähler via USB/RS232.
Vor kurzem habe ich festgestellt, dass nun mein Logfile vor Warnungen überquillt...
2016.09.05 00:00:14 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/47_OBIS.pm line 229, <GEN26> line 47.
2016.09.05 00:00:14 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 491, <GEN26> line 47.
Hat einer eine Idee woran das liegen könnte?
Ich habe an der Konfig von dem Device nichts geändert. Nachdem ich das festgestellt habe habe ich auch mal ein update gemacht, das hat allerdings nichts geändert.
Vielen Dank schon mal für eure Hilfe!
Zitat
Internals:
CFGFN ./FHEM/fhem-strom.cfg
CHANGED
DEF /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@9600 SML
DeviceName /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@9600
MeterType SML
NAME Dev_StromHaus
NR 138
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-08-09 14:33:42 0.118.5.15.166.255 0
2016-09-07 22:47:21 1.0.0.0.9.255 08-05-35-34-2D-4C-6D-D3
2016-09-07 22:47:21 1.0.96.5.5.255 386
2016-09-07 22:47:21 129.129.199.130.3.255 ISK
2016-09-07 22:47:21 129.129.199.130.5.255 F300-C2FF-4980-7FB1-9DC7-F94E-3B96-A622-EA4B-8781-2B69-5CBB-AC66-C4FD-D726-F072-69A3-49FB-5906-9FDF-5A83-0B87-2E15-B6D7-01
2016-08-06 23:06:06 ManufID ISK
2016-08-06 23:06:06 PublicKey F300-C2FF-4980-7FB1-9DC7-F94E-3B96-A622-EA4B-8781-2B69-5CBB-AC66-C4FD-D726-F072-69A3-49FB-5906-9FDF-5A83-0B87-2E15-B6D7-01
2016-08-06 23:06:06 Status 386
2016-09-07 22:16:13 Version ISK\080535342D4C6DD3
2016-09-07 22:47:21 dir_total_consumption in
2016-09-07 22:47:21 power 340
2016-09-07 22:47:21 power_L1 239
2016-09-07 22:47:21 power_L2 82
2016-09-07 22:47:21 power_L3 19
2016-09-07 22:47:02 statPowerDay Min: 119 Avg: 234 Max: 2796
2016-09-06 23:59:55 statPowerDayLast Min: 121 Avg: 288 Max: 4739
2016-09-07 22:47:02 statPowerHour Min: 208 Avg: 291 Max: 755
2016-09-07 21:59:55 statPowerHourLast Min: 238 Avg: 310 Max: 1098
2016-09-07 22:47:02 statPowerMonth Min: 119 Avg: 363 Max: 6345
2016-08-31 23:59:55 statPowerMonthLast Min: 94 Avg: 302 Max: 6926
2016-09-07 22:47:02 statPowerYear Min: 94 Avg: 358 Max: 7513 (since: 2016-05-05_23:32:43 )
2016-09-07 22:47:02 statTotal_consumption Hour: 231.1 Day: 5332.3 Month: 60597.0 Year: 1075931.7 (since: 2016-05-05 )
2016-09-07 21:59:55 statTotal_consumptionLast Hour: 304.1 Day: 6846.5 Month: 225442.8 Year: -
2016-09-05 22:08:48 state opened
2016-09-07 22:47:21 total_consumption 17776477.5
2016-09-07 22:47:21 total_consumption_Ch1 17776477.5
2016-09-07 22:47:21 total_consumption_Ch2 0
Helper:
BUFFER
EoM 0
SPEED 5
TRIGGERTIME 1473106128.71682
_98_statistics statisticsStromHaus
Channels:
DEVICES:
-1
Directions:
Attributes:
event-min-interval power:30
event-on-change-reading statTotal_consumptionLast,statPowerDayLast
event-on-update-reading power
pollingMode on
room Stromzaehler
Komisch, dass die beiden plötzlich auftreten.
Aber ich hab grad eben nen Fix commited, kommt mit dem morgigen Update.
lg, Stefan
Hi Stefan,
irgendwie mag die neue Version gar nix mehr machen. Mit verbose 5 kommt nur unendlich oft
2016.09.08 09:20:25 4: parsing....
der timer fürs polling wird korrekt gesetzt.
Grüße
Markus
Edit: Noch weiter getestet. Ominös. Geht, geht nicht ?!?! Also nach shutdown, restart läuft es nicht. Nach einem modify geht es dann. Aber auch nicht immer beim ersten modify ?!?!?! Wenn das Modify "erfolgreich" war kommt hinter
2016.09.08 10:03:24 3: Init done
2016.09.08 10:03:24 3: zaehler device opened
noch ein weiterer Logeintrag
2016.09.08 10:03:25 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 525.
Sehr seltsam (für mich).
Sehr komisch......
Habe gerade ca. 10mal ein modify probiert, hatte nie Probleme.....Daten kamen auch immer schön brav rein.
Ausserdem habe ich in der define-Routine und in dem Bereich der Fehlermeldung gar nichts geändert.
Kann ich mir aktuell absolut nicht erklären...
lg, Stefan
Musst ja nix geändert haben. Vielleicht auch im Zusammenhang mit dem bei mir neu eingesetzten RPI_GPIO. Das macht nämlich lustige OBIS-Meldungen, obwohl die beiden keine logische Verbindung in fhem haben, guck mal
https://forum.fhem.de/index.php/topic,51806.msg488077.html#msg488077
Hilft Dir verbose 5 ?
Reboot
2016.09.08 21:39:40 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 457, <$fh> line 159.
2016.09.08 21:39:40 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 761, <$fh> line 159.
2016.09.08 21:39:40 3: Opening zaehler device /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
2016.09.08 21:39:40 3: Setting zaehler serial parameters to 9600,7,E,1
2016.09.08 21:39:40 3: Init done
2016.09.08 21:39:40 3: zaehler device opened
2016.09.08 21:39:40 5: OBIS (zaehler) - Internal timer set to 2016-09-08 21:40:00
2016.09.08 21:40:00 5: SW:
2016.09.08 21:40:00 4: Wrote
2016.09.08 21:40:00 5: OBIS (zaehler) - Internal timer set to 2016-09-08 21:41:00
2016.09.08 21:41:00 5: SW:
2016.09.08 21:41:00 4: Wrote
2016.09.08 21:41:00 5: OBIS (zaehler) - Internal timer set to 2016-09-08 21:42:00
Modify
2016.09.08 21:41:25 5: OBIS (zaehler) - Internal timer set to 2016-09-08 21:42:00
2016.09.08 21:41:25 5: OBIS (zaehler) - Opening device...
2016.09.08 21:41:25 3: Opening zaehler device /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
2016.09.08 21:41:25 3: Setting zaehler serial parameters to 9600,7,E,1
2016.09.08 21:41:25 3: Init done
2016.09.08 21:41:25 3: zaehler device opened
2016.09.08 21:41:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/47_OBIS.pm line 252.
2016.09.08 21:41:25 4: Part 1
2016.09.08 21:41:25 5: SW:
2016.09.08 21:41:25 4: Writing
2016.09.08 21:41:26 4: Part 2
2016.09.08 21:41:26 4: Old Dev: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0@9600,7,E,1
2016.09.08 21:41:26 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 268.
2016.09.08 21:41:26 4: Replaced dev: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0@,7,E,1
2016.09.08 21:41:26 5: OBIS (zaehler) - Opening device...
2016.09.08 21:41:26 5: OBIS (zaehler) - Internal timer set to 2016-09-08 21:42:00
2016.09.08 21:41:26 3: Setting zaehler serial parameters to 7,8,N,1
2016.09.08 21:41:26 3: Init done
2016.09.08 21:41:26 1: /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 reappeared (zaehler)
2016.09.08 21:41:26 4: Cleared helper
2016.09.08 21:41:58 4: parsing....
2016.09.08 21:41:58 4: parsing....
Grüße Markus
Habe gestern ein update gemacht. Seither stöhnt der Raspi wieder wegen 10 ... 15% CPU-Last. Danach habe ich wieder das alte 47_OBIS-Modul eingespielt (diese Version hat im Filesystem einen Zeitstempel vom 25. April 2016), nun ist die Systemlast wieder unter 1%.
Damals hatten wir soooo lange rum gemacht, um die Last runter zu bekommen. Kann mich nicht mehr genau erinnern, es war irgendwas mir gepollten Abfragen oder sowas. Warum ist das in der aktuellen Modulversion wieder kaputt ??? :(
Habe grade die Lösung gefunden. Damals hatte ich geschrieben:
Zitat von: willybauss am 24 April 2016, 09:40:14
Nach dem Update . . . musste ich erst mal die Zeile 73 ($hash->{SetFn} = "OBIS_Set") auskommentieren, damit es lief; anschließend: die Daten kommen im Minutentakt (interval 60) und die CPU-Last bleibt niedrig (pollingMode on). Auch an der define-Zeile musste ich nichts ändern (... -port0@9600,7,E,1), also weiterhin ohne Zählertypangabe.
Bitte das mit der auskommentierten Zeile noch korrigieren.
Irgendwie scheint das untergegangen zu sein. Oder was ist der Grund, dass die Zeile immernoch/wieder drin ist ? ? ?
danke ;D sieht jetzt wieder im monitor sehr entspannt aus
Hi
The OBIS module works perfect for me. But when I restart fhem I get in the logfile:
2016.09.22 20:39:11 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 744, <$fh> line 533.
2016.09.22 20:39:11 3: Opening SmartMeter device /dev/ttyUSB1
2016.09.22 20:39:11 3: Setting SmartMeter serial parameters to 115200,8,N,1
2016.09.22 20:39:11 3: Init done
2016.09.22 20:39:11 3: SmartMeter device opened
[...]
2016.09.22 20:39:21 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/47_OBIS.pm line 235.
2016.09.22 20:39:21 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 251.
2016.09.22 20:39:21 3: Setting SmartMeter serial parameters to 8,8,N,1
2016.09.22 20:39:21 3: Init done
2016.09.22 20:39:21 1: /dev/ttyUSB1 reappeared (SmartMeter)
It seems to be no problem but maybe nif is nice if it can be solved.
Just before the restart I did an update, so I use the latest version 2016-09-13.
{HT}
Found it, I had to delete my readings.
Hi,
bei mir funktioniert die Aktualisierung nur manchmal.
Hab es jetzt versucht zu reproduzieren, schaut so aus als ob es aktualisiert, wenn lange keine Aktivität mehr auf der Oberfläche war und ich mich dann einlogge.
Neustart bringt keine Aktualisierung. Auch mit interval und event-* zeigt sich kein verändertes Verhalten...
Geloggt wurde bis jetzt folgendes:
2016-09-23_16:11:49 MyObis power: 261
2016-09-23_16:11:50 MyObis power: 251
2016-09-23_16:29:44 MyObis power: 286
Hardware habe ich einen Weidmann IR-Kopf an einem EMH Basiszähler eBZD. Der Zähler hat laut Produktdatenblatt eine optische Datenschnittstelle inidirektional – Push-Betrieb, SML, 9600 Baud.
Und in der fhem.conf nichts drinne ausser
define MyObis OBIS /dev/ttyUSB0@9600,8,N,1 SML
Aktuell habe ich keinen Suchansatz mehr und freue mich auf Ideen.
Was sagt denn das internal "CRC_Errors"?
Ansonsten mal auf V4 oder V5 setzen und mir das Log schicken
lg, Stefan
Hi,
die CRC Fehler laufen nur hoch, wenn ich auf 7E1 setze. Auf 8N1 bleiben die still.
Solange ich nicht an FHEM rumdoktore schein es besser zu laufen und ich bekomme unregelmäßg Messwerte (Fön an und aus sollte eigentlich mehr Werte ergeben):
2016-09-23_18:23:09 MyObis power: 247 W
2016-09-23_18:28:46 MyObis power: 311 W
2016-09-23_18:31:56 MyObis power: 1318 W
2016-09-23_18:33:06 MyObis power: 1310 W
2016-09-23_18:35:03 MyObis power: 341 W
2016-09-23_18:39:45 MyObis power: 270 W
2016.09.23 22:08:53 5: OBIS: Full message-> 1B1B1B1B010101017605002601A36200620072630101760107FFFFFFFFFFFF05000CAB370B0A01454D4800005A561C726201640DF166620163F0DF007605002601A462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1667577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF166621E52FF6404AA770177070100020800FF01726201640DF166621E52FF6324910177070100100700FF0101621B520053011F0101016350E6007605002601A56200620072630201710163554E000000001B1B1B1B1A034A69
2016.09.23 22:08:53 5: OBIS: Telegram=1B1B1B1B010101017605002601A36200620072630101760107FFFFFFFFFFFF05000CAB370B0A01454D4800005A561C726201640DF166620163F0DF007605002601A462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1667577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF166621E52FF6404AA770177070100020800FF01726201640DF166621E52FF6324910177070100100700FF0101621B520053011F0101016350E6007605002601A56200620072630201710163554E000000001B1B1B1B1A034A69
2016.09.23 22:08:53 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:08:53 5: OBIS (MyObis) - Msg-Parse: 1-0:16.7.0*255(287*W)
2016.09.23 22:08:53 5: Msg 1-0:16.7.0*255(287*W) is of type Channels
2016.09.23 22:08:53 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:08:53 4: parsing....
2016.09.23 22:08:54 5: OBIS: Full message-> 1B1B1B1B010101017605002601A66200620072630101760107FFFFFFFFFFFF05000CAB380B0A01454D4800005A561C726201640DF1676201639C6A007605002601A762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1677577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF167621E52FF6404AA770177070100020800FF01726201640DF167621E52FF6324910177070100100700FF0101621B520053011F01010163F6EB007605002601A862006200726302017101633BF9000000001B1B1B1B1A03AC8F
2016.09.23 22:08:54 5: OBIS: Telegram=1B1B1B1B010101017605002601A66200620072630101760107FFFFFFFFFFFF05000CAB380B0A01454D4800005A561C726201640DF1676201639C6A007605002601A762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1677577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF167621E52FF6404AA770177070100020800FF01726201640DF167621E52FF6324910177070100100700FF0101621B520053011F01010163F6EB007605002601A862006200726302017101633BF9000000001B1B1B1B1A03AC8F
2016.09.23 22:08:54 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:08:54 5: OBIS (MyObis) - Msg-Parse: 1-0:16.7.0*255(287*W)
2016.09.23 22:08:54 5: Msg 1-0:16.7.0*255(287*W) is of type Channels
2016.09.23 22:08:54 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:08:54 4: parsing....
2016.09.23 22:08:55 5: OBIS: Full message-> 1B1B1B1B010101017605002601A96200620072630101760107FFFFFFFFFFFF05000CAB390B0A01454D4800005A561C726201640DF1686201636976007605002601AA62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1687577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF168621E52FF6404AA780177070100020800FF01726201640DF168621E52FF6324910177070100100700FF0101621B520053011E01010163A9A6007605002601AB62006200726302017101638807000000001B1B1B1B1A035B55
2016.09.23 22:08:55 5: OBIS: Telegram=1B1B1B1B010101017605002601A96200620072630101760107FFFFFFFFFFFF05000CAB390B0A01454D4800005A561C726201640DF1686201636976007605002601AA62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1687577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF168621E52FF6404AA780177070100020800FF01726201640DF168621E52FF6324910177070100100700FF0101621B520053011E01010163A9A6007605002601AB62006200726302017101638807000000001B1B1B1B1A035B55
2016.09.23 22:08:55 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:08:55 5: OBIS (MyObis) - Msg-Parse: 255-255:255.255.255*255()
2016.09.23 22:08:55 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:08:55 4: parsing....
2016.09.23 22:08:56 5: OBIS: Full message-> 1B1B1B1B010101017605002601AC6200620072630101760107FFFFFFFFFFFF05000CAB3A0B0A01454D4800005A561C726201640DF169620163C4AD007605002601AD62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1697577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF169621E52FF6404AA790177070100020800FF01726201640DF169621E52FF6324910177070100100700FF0101621B5200530122010101638F6A007605002601AE62006200726302017101634C0C000000001B1B1B1B1A0367DE
2016.09.23 22:08:56 5: OBIS: Telegram=1B1B1B1B010101017605002601AC6200620072630101760107FFFFFFFFFFFF05000CAB3A0B0A01454D4800005A561C726201640DF169620163C4AD007605002601AD62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF1697577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF169621E52FF6404AA790177070100020800FF01726201640DF169621E52FF6324910177070100100700FF0101621B5200530122010101638F6A007605002601AE62006200726302017101634C0C000000001B1B1B1B1A0367DE
2016.09.23 22:08:56 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:08:56 5: OBIS (MyObis) - Msg-Parse: 255-255:255.255.255*255()
2016.09.23 22:08:56 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:08:56 4: parsing....
...
...
...
...
2016.09.23 22:14:02 5: OBIS: Full message-> 1B1B1B1B010101017605002605426200620072630101760107FFFFFFFFFFFF05000CAC6C0B0A01454D4800005A561C726201640DF29B620163676F0076050026054362006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29B7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29B621E52FF6404AB760177070100020800FF01726201640DF29B621E52FF6324910177070100100700FF0101621B52005301360101016373F100760500260544620062007263020171016326A3000000001B1B1B1B1A03CDC9
2016.09.23 22:14:02 5: OBIS: Telegram=1B1B1B1B010101017605002605426200620072630101760107FFFFFFFFFFFF05000CAC6C0B0A01454D4800005A561C726201640DF29B620163676F0076050026054362006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29B7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29B621E52FF6404AB760177070100020800FF01726201640DF29B621E52FF6324910177070100100700FF0101621B52005301360101016373F100760500260544620062007263020171016326A3000000001B1B1B1B1A03CDC9
2016.09.23 22:14:02 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:14:02 5: OBIS (MyObis) - Msg-Parse: 255-255:255.255.255*255()
2016.09.23 22:14:02 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:14:02 4: parsing....
2016.09.23 22:14:03 5: OBIS: Full message-> 1B1B1B1B010101017605002605456200620072630101760107FFFFFFFFFFFF05000CAC6D0B0A01454D4800005A561C726201640DF29C62016343D30076050026054662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29C621E52FF6404AB770177070100020800FF01726201640DF29C621E52FF6324910177070100100700FF0101621B520053012C0101016319F6007605002605476200620072630201710163955D000000001B1B1B1B1A0310B4
2016.09.23 22:14:03 5: OBIS: Telegram=1B1B1B1B010101017605002605456200620072630101760107FFFFFFFFFFFF05000CAC6D0B0A01454D4800005A561C726201640DF29C62016343D30076050026054662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29C621E52FF6404AB770177070100020800FF01726201640DF29C621E52FF6324910177070100100700FF0101621B520053012C0101016319F6007605002605476200620072630201710163955D000000001B1B1B1B1A0310B4
2016.09.23 22:14:03 5: OBIS (MyObis) - Msg-Parse: /
2016.09.23 22:14:03 5: OBIS (MyObis) - Msg-Parse: 1-0:16.7.0*255(300*W)
2016.09.23 22:14:03 5: Msg 1-0:16.7.0*255(300*W) is of type Channels
2016.09.23 22:14:03 5: OBIS (MyObis) - Msg-Parse: !
2016.09.23 22:14:03 4: parsing....
2016-09-23_22:08:53 MyObis power: 287 W
2016-09-23_22:14:03 MyObis power: 300 W
2016-09-23_22:19:20 MyObis power: 281 W
Welche davon jetzt eingelesen werden erkennt man eigentlich im log. Logisch ist das für mich trotzdem nicht.
Vielen Dank schonmal für die Hilfe.
Hi Alex,
Dürfte auf den ersten Blick eigentlich nicht passieren, die Daten sind alle da......
Ich schau mir das heute oder morgen mal an.
lg, Stefan
Hi Stefan
please consider fixing line 229,
if (defined $hash->{helper}{SpeedChange} && $hash->{helper}{SpeedChange} eq "")
You have not implemented the case that $hash->{helper}{SpeedChange} is not defined.
My quick and dirty fix
if ( !defined($hash->{helper}{SpeedChange}) || ($hash->{helper}{SpeedChange} eq ""))
even better would be to make 2 nested "if" instead using "Short Circuit" operators.
thanks
immi
Zitat von: unclejay am 07 September 2016, 22:50:07
Hallo,
ich nutze das OBIS Modul seit einiger Zeit als Ablösung für das SMLUSB Modul für den Stromzähler via USB/RS232.
Vor kurzem habe ich festgestellt, dass nun mein Logfile vor Warnungen überquillt...
2016.09.05 00:00:14 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/47_OBIS.pm line 229, <GEN26> line 47.
2016.09.05 00:00:14 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 491, <GEN26> line 47.
Hat einer eine Idee woran das liegen könnte?
Ich habe an der Konfig von dem Device nichts geändert. Nachdem ich das festgestellt habe habe ich auch mal ein update gemacht, das hat allerdings nichts geändert.
Vielen Dank schon mal für eure Hilfe!
Most likely you have old readings stored.
Try deleting your old readings with:
deletereading Dev_StromHaus .*
{HT}
Hi
After updating 47_OBIS from 2016-05-18 to 2016-09-13 version I won't get any readings. Verbose 5 does not generate any line in my logfiles.
After setting the old version of 47_OBIS back everything works again.
What can be wrong? Any more info needed?
My settings:
define SmartMeter OBIS /dev/ttyUSB1@115200,8,N,1
attr SmartMeter channels {"0.0.1.0.0"=>"date-time_laatste_P1_bericht", "0.1.24.1.0"=>"_andere_apparaten_op_de_M-Bus", "0.1.24.2.1"=>"VerbruikteHoeveelheidGas", "0.1.96.1.0"=>"_identificatie_van_de_gasmeter", "0.0.96.1.1"=>"_equipment_identifier", "0.0.96.7.9"=>"_number_of_long_power_failures_in_any_phase", "0.0.96.7.21"=>"_number_of_power_failures_in_any_phase", "0.0.96.13.1"=>"BerichtNumeriek", "0.0.96.13.0"=>"BerichtTekst", "0.0.96.14.0"=>"ActueleTarief", "1.0.1.7.0"=>"HuidigVerbruik", "1.0.2.7.0"=>"HuidigTeruglevering", "1.0.1.8.1"=>"ElektriciteitsstandLaagtarief", "1.0.1.8.2"=>"ElektriciteitsstandNormaaltarief", "1.0.2.8.1"=>"ElektriciteitsstandTerugleveringLaagtarief", "1.0.2.8.2"=>"ElektriciteitsstandTerugleveringNormaaltarief", "1.0.21.7.0"=>"_Instantaneous_active_power_L1_P_in_W", "1.0.22.7.0"=>"_Instantaneous_active_power_L1_-P_in_W", "1.0.32.32.0"=>"_number_of_voltage_sags_in_phase_L1", "1.0.32.36.0"=>"_number_of_voltage_swells_in_phase_L1", "1.0.99.97.0"=>"_power_Failure_Event_Log_long_power_failures", "1.0.31.7.0"=>"_instantaneous_current_L1_-P", "1.3.0.2.8"=>"_DSMR_version_4.0"}
attr SmartMeter event-on-change-reading VerbruikteHoeveelheidGas,BerichtNumeriek,BerichtTekst,ActueleTarief,HuidigVerbruik,HuidigTeruglevering,ElektriciteitsstandLaagtarief_Ch1,ElektriciteitsstandNormaaltarief_Ch2,ElektriciteitsstandTerugleveringLaagtarief_Ch1, ElektriciteitsstandTerugleveringNormaaltarief_Ch2
{HT}
Maybe my problem
https://forum.fhem.de/index.php/topic,51948.msg489056.html#msg489056
is similar to yours. Try to modify the definition (w/o changing anything) until it works.
Regards Markus
Zitat von: HarryT am 25 September 2016, 14:53:09
After updating 47_OBIS from 2016-05-18 to 2016-09-13 version I won't get any readings. Verbose 5 does not generate any line in my logfiles.
After setting the old version of 47_OBIS back everything works again.
Hi HarryT
I had the same symptoms (I do not know, if we have the same root cause).
It is now working again for me, using last version but with the fix posted above.
https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777 (https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777)
immi
Thanks Immi and KölnSolar for your response.
It seems we have the same problem. I observed during my tests that 1 time I got readings. After deleting my readings it didn't work anymore and I was not able to reproduce it. So I didn't mention it in my posting before.
If my observation is correct, you may loose your readings if you modify again.
I think it doesn't make much sense to modify until it works. There is a problem in the module.
In my opinion it is best to check which of the versions in the repository work and which is the first with the problem. I volunteer for this testing, and will try it tomorrow.
Hope this might help icinger to find the problem.
{HT}
Zitat von: Icinger am 24 September 2016, 10:14:10
Hi Alex,
Dürfte auf den ersten Blick eigentlich nicht passieren, die Daten sind alle da......
Ich schau mir das heute oder morgen mal an.
lg, Stefan
Hi Stefan,
hab jetzt ein Update auf die Rev 12154 gemacht und bekomme beim starten folgende Meldungen:
1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/47_0BIS.pm line 235.
1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/47_0BIS.pm line 251
1: PERL WARNING: substr outside of string at ./FHEM/47_0BIS.pm line 737.
1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_0BIS.pm line 751.
1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_0BIS.pm line 753.
1: PERL WARNING: substr outside of string at ./FHEM/47_0BIS.pm line 753.
1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/470BIS.pm line 734.
1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/470BIS.pm line 736.
1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_0BIS.pm line 737.
Die ersten beiden scheinen ja auch andere zu haben. Die restlichen erschließen sich mir nicht wirklich, da ja die Länge der Telegramme (eingelesen und nicht eingelesen) identisch sind...
Zitat von: HarryT am 26 September 2016, 22:56:25
In my opinion it is best to check which of the versions in the repository work and which is the first with the problem. I volunteer for this testing, and will try it tomorrow.
Hope this might help icinger to find the problem.
{HT}
I did some testing. The latest version which gives me readings is the version # $Id: 47_OBIS.pm 11636 2016-06-09 08:30:29Z icinger $
In the logging I get:
2016.09.27 21:04:25 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 666, <$fh> line 533.
2016.09.27 21:04:25 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 133, <$fh> line 533.
2016.09.27 21:04:25 3: Opening SmartMeter device /dev/ttyUSB1
2016.09.27 21:04:25 3: Setting SmartMeter serial parameters to 115200,8,N,1
2016.09.27 21:04:25 3: SmartMeter device opened
2016.09.27 21:04:25 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/47_OBIS.pm line 133, <$fh> line 550.
[...]
2016.09.27 21:04:31 1: Including ./fhem.save
[...]
2016.09.27 21:04:35 0: Featurelevel: 5.7
2016.09.27 21:04:35 0: Server started with 184 defined entities (fhem.pl:12191/2016-09-21 perl:5.012002 os:linux user:root pid:24266)
[...]
2016.09.27 21:04:35 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 447.
I hope this helps in finding the issue.
If someone finds a solution I could test it.
(HT}
Zitat von: HarryT am 27 September 2016, 21:14:04
I did some testing. The latest version which gives me readings is the version # $Id: 47_OBIS.pm 11636 2016-06-09 08:30:29Z icinger $
Unfortunately this version does not give all readings. The last correct versions is from 2016-05-18
{HT}
Ich bräuchte wohl mal eure Hilfe. Nach tagelangen Versuchen komme ich nun nicht mehr weiter.
Ich habe mir von Co.met (mySmartShop) folgenden Leser geholt:
http://www.mysmartshop.de/co-met-infrarot-schnittstelle-easycom.html
Diesen habe ich erst einmal mit diesen (https://de.aliexpress.com/item/WholeSale-Free-Shipping-PL2303-USB-To-RS232-TTL-Converter-Adapter-Module-with-PL2303HX/619593741.html?spm=2114.13010608.0.0.lfOyFC) USB-RS232-TTL-Converter angeschlossen und auch über die UART-PINs des Raspberry Pi2 B. Demnach habe ich entweder /dev/ttyUSB0 oder /dev/ttyAMA0.
Ich komme mir folgenden Varianten nicht zum Erfolg:
/dev/ttyUSB0@9600,7,E,1 Standard
/dev/ttyAMA0@9600,7,E,1 Standard
Es kommen zwar Daten in Raspian Jessie an, aber diese werden scheinbar nicht erkannt bzw. verarbeitet.
root@FHEM:~# cat /dev/ttyUSB0 | od -tx1
0000000 28 1d 56 53 65 17 66 57 75 3e 9f 9b 99 65 a3 9f
0000020 99 e5 bd ce af 52 fb 8b 9f a3 9f a3 9f ab 93 59
0000040 d9 ed f2 22 1e 36 5a ca d6 9d 69 b6 9d b4 64 fb
0000060 ab 93 59 76 7b 1f 1f 1b 56 76 52 32 3b 22 22 2a
0000100 1f 1f 13 2b 0a 14 21 25 56 1d 69 36 1b 27 34 32
0000120 5b 2a 15 2b 13 59 59 6d 76 76 36 52 56 32 4b 19
0000140 2b 14 2b 39 3d 52 7b 0b 17 19 8b 46 9b 65 65 95
0000160 93 59 d9 ed f6 f6 36 f6 f6 36 cb 91 95 d1 29 d6
0000200 9d 69 b6 93 9d b4 32 db 2a 95 ab 93 59 d9 ed f6
0000220 f6 d6 d2 52 36 15 1f 2b 14 2b 39 3d 27 69 36 1d
0000240 34 32 5b 2a 15 2b 13 59 59 6d 76 76 56 13 11 34
0000260 13 36 09 34 4a 56 1d 69 36 0d 36 ab a3 95 ab 93
0000300 59 d9 cd 64 d2 29 d6 9f a5 9f 8b 8d 93 a3 9d b4
0000320 93 59 d9 65 52 56 f6 eb ea 56 53 27 76 d2 f2 f6
0000340 f6 b6 f2 16 d2 d6 bd e5 3d
0000351
Hat jemand eine Idee wo der Fehler liegen könnte?
Danke
Die Schnittstelleneinstellungen 9600,7,E,1 vielleicht ? Welchen Zähler liest Du aus ? OBIS-Klartext ?
Grüße Markus
Ich lese einen Easymeter Q3D aus. Diese sollte 9600,7,E,1 und OBIS haben.
Bei meinem Gerät handelt sich wohl exakt um diesen Leser (http://www.emh-metering.de/de/produkte/okk-bke-f/).
---
Ich habe auch irgendwo mal etwas darüber gelesen, dass bei gewissen Tastköpfen die Signale invertiert werden müssen. Nicht, dass das bei meinem Leser auch gemacht werden muss.
---
Ich sehe mit dem Windows-Tool "hterm", dass zyklisch Daten reinkommen. Dort habe ich mich quasi durch alle Baudraten & co. geklickt. Und es kam nichts leserliches bei raus.
Zitat von: FunkOdyssey am 05 Oktober 2016, 21:17:37
Ich lese einen Easymeter Q3D aus. Diese sollte 9600,7,E,1 und OBIS haben.
If it is obis cleartext, why are you using "od -tx1" which gives you the hex?
"cat" in unix can confuse you, because it uses the settings your port is already configured.
With the following command you get the given configuration
stty -F /dev/ttyACM0
or
stty -F /dev/ttyUSB0
with stty you can also change speed, parity ...
https://linux.die.net/man/1/stty
if you find the command line too complicated, you can test your hardware with minicom, picocom....
at the end, for your meeter, you need to get something like
/ESY5Q3DA1002 V3.021-
0:0.0.0*255(54920)
1-0:1.8.0*255(00003984.9338242*kWh)
1-0:21.7.255*255(000176.85*W)
1-0:41.7.255*255(001025.66*W)
1-0:61.7.255*255(002529.68*W)
1-0:1.7.255*255(003732.19*W)
1-0:96.5.5*255(82)
0-0:96.1.255*255(1ESY0943000XXX)!
Thanks for your hints. I have tried a few things, but it is only wrong data received.
Picocom shows me something like this:
�����������������������������42[*+YYmvvv62;"V"+9=R{
�����������'42[*+YYmvvVr2k++9=R{
��������������������������������42[*+YYmvvvV6{)�R42[*+YYmvvv26;&++9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv2��dr2<+9=R{
�����������������������������42[*+YYmvvvV2kQ)Vi6'42[*+YYmvvVr2++9=R{
##+YYmdR)V>%����������������42[*+YYmvvvV6{++9='i642[*+YY���24r6 4JVi6
#4YYeRVvkjVS'vRrvv6rR)(VSefWu>e#e=N/R{
��������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6
��������������cc2R6<+9=R{
�������������������������42[*+YYmvvvV2{2++9=R{
������'42[*+YYMvvVr2{&++9=R{
����������������������������42[*+YYmvvvV6{++9=R{
������������������������������������������������42[*+YYmvvv262
����������.V"+9=R{
##+YYmdR)V%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6
d%!qh)Vi642[*+YYmvvv62{Q)Vi6'42[*+YYMvvVr2{"V"+9=R{
���������������������������������������������������42[*+YYmvvvV6{++9=R{
##+YYmdR)V%
�������������������42[*+YYmvvv262kQ)Vi6
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6
c!qh)Vi642[*+YYmvvv62["V"+9=R{
������������������������������'42[*+YYmvvVr2kQ)Vi642[*+YYmvvvV6k>++9='i642[*+YYmvvv26[++9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6
f22<+9=R{
���������42[*+YYmvvv62K++9=R{
�����������������������������'42[*+YYmvvVrvF++9=R{
��������������������������������������������������42[*+YYmvvvV6k6V"+9='i642[*+YYmvvv26+++9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
##+YYmdR)=V�+YYmvvv62KQ)Vi6'42[*+YYmvvV>�cI%Q)Vi642[*+YYmvvvV6k6V"+9='i642[*+YYmvvv26KQ)Vi6
������������4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
�##+YYmr"6ZJVi64d{+YYmvv�>w4dvVVR6<+9=R{
����������������������������������������42[*+YYmvvv62K++9=R{
��������������������'42[*+YYmvvVr2{6V"+9=R{
�������������������������������������������42[*+YYmvvvV6k*++9=R{
������������42[*�*Y26["V"+9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6{>��!h)Vi642[*+YYmvvv62kV"+9=R{
���������'42[*+YYmvvVr2
�����������������������V"+9='i642[*+YYmvvvV6k&++9=R{##+YYmdR)V%
42[*+YYMvvv2��� Q%Vi6
#4YYeRVvkjVS'vRrvv6rR)V=e=(VefWu>e#e=N/R{
�����������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6{>2{VRh)Vi642[*+YYmvvvV2kQ)Vi6'42[*+YYmvvVr2
���������������������*++9=R{
##+YYMdR)V%�����������������42[*+YYmvvvV6k:V"+9='i642[*+YYmvvv262{���Ni6
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv��Y%!qh)Vi642[*+YYmvvvV2K++9=R{
��������'42[*+YYmvvVr2
����������������������V"+9=R{
�����������������������������42[*+YYmvvvV6{++9='i642[*+YY��I62k++9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'Rrvv6rR)V=e=(VSefWu>e#e=N/R{
�����������������������������������������##+YYmr"6ZJVi64d{+YYmvv6rVv6{>f$c6<+9=R{
++9=R{
�����������������������������42�ee�/#
������'42[*+YYmvvVr2kQ)Vi642[*+YYmvvvV6k.V"+9='i642[*+YYmvvv2V2
�����������.V"+9=R{
##+YYmdR)V>%
#4YYeRVvkjVS'vRrvv6rR)V=e=(VSefWu>e#e=N/R{
������������������������������������������##+YYmr"6ZJV'i,F46Y*/v6{>2V66<+9=R{
�������������������������42[*+YYmvvvv6
I had to copy the text from the clipboard of a smartphone. For this reason some details have been lost. You can see a pattern, but not a plain text.
I will get another reader and make further attempts.
Are you sure that picocom is set to 9600,7,E,1?
If yes and you do not get a plain text, than you have to try other settings/speed of the serial interface, untill you get the expected telegram from the meeter.
immi
Oh, I forgot to mention that I had really tried all baud rates and other settings.
Anyway, I've given up and try it with another reader.
Hallo,
Mal baud 300 versuchen, bei meinem muss ich damit anfangen und kann dann per Sequenz auf 19200 umschalten. Vielleicht hilft es ja.
Pejonp
Zitat von: FunkOdyssey am 28 September 2016, 13:19:53
Ich habe mir von Co.met (mySmartShop) folgenden Leser geholt:
http://www.mysmartshop.de/co-met-infrarot-schnittstelle-easycom.html
Das ist ein IR-Leser mit einer RS232-Schnittstelle: https://de.wikipedia.org/wiki/RS-232#/media/File:Rs232_oscilloscope_trace.svg
RS232 arbeitet mit + - Signal-Pegeln, TTL nur mit + Signalpegel.
Den versuchst du an einen TTL auf USB Wandler anzuschließen:
Zitat von: FunkOdyssey am 28 September 2016, 13:19:53
Diesen habe ich erst einmal mit diesen (https://de.aliexpress.com/item/WholeSale-Free-Shipping-PL2303-USB-To-RS232-TTL-Converter-Adapter-Module-with-PL2303HX/619593741.html?spm=2114.13010608.0.0.lfOyFC) USB-RS232-TTL-Converter angeschlossen und auch über die UART-PINs des Raspberry Pi2 B. Demnach habe ich entweder /dev/ttyUSB0 oder /dev/ttyAMA0.
Das kann nicht funktionieren.
Leider wird der Begriff RS232 immer wieder auf Ebay, vor allem von unseren chinesischen Freunden, fälschlich für einfache TTL-Signale benutzt.
Gruß
Udo
Hey super. Vielen Dank, Udo, für die Richtigstellung.
Ich habe den Tastkopf nun leider schon retourniert. Ärgerlich für den Shop. Und ich habe fast zwei Wochen nach dem Fehler gesucht und hatte einfach nur den falschen Adapter. Wobei ich es sogar noch mit einem ganz anderen Modell ausprobiert hatte: https://de.aliexpress.com/item/Free-Shipping-FT232RL-FT232-USB-TO-TTL-5V-3-3V-Download-Cable-To-Serial-Adapter-Module/1927444755.html?spm=2114.13010608.0.0.EdLRFB
Jedoch war ein richtig netter Udo aus nem anderen Forum (scheinbar auch dein Spezialgebiet ;) ) so nett und sorgt dafür, dass ich morgen schon einen neuen IR Lesekopf haben werde. :)
Frage am Rande: Hätte es über die Serial-UART-GPIO Pinseln des Raspberry nicht funktionieren müssen? Oder verwechsel ich hier wieder etwas?
Zitat von: FunkOdyssey am 07 Oktober 2016, 19:53:29
Frage am Rande: Hätte es über die Serial-UART-GPIO Pinseln des Raspberry nicht funktionieren müssen?
Nein, weil der Lesekopf eine RS232-Schnittstelle hatte, keine TTL-Schnittstelle.
Gruß
Udo
Hallo,
ich bekomme beim Start von FHEM folgende Meldungen im Log:
2016.10.08 19:26:13 1 : PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 753.
2016.10.08 19:26:14 1 : PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 346.
Grüße
Olli
PS: Es funktioniert aber alles, die Werte kommen vom EasyMeter...
Ich gehöre nun auch zum Club.
Ich habe aber das gleiche Problem wie einige anderen hier.
Desöfteren stoppt die Übermittlung. Z.B. auch nach nem FHEM/Pi-Neustart.
Ich muss die DEF einmal modifizieren und dann klappt es.
Dazu gibt es noch kein Fix, der committed werden könnte, oder? ;-)
---
Nachtrag:
Mein Log wird auch komplett zugemüllt:
2016.10.09 00:58:10 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4131, <GEN14851> line 1.
2016.10.09 00:58:11 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 525, <GEN14851> line 1.
Hallo Zusammen,
das Modul funktioniert (fast vollständig) mit dem Apator 12EC3g Zähler mit IR-Schreib-/Lesekopf
von Weidmann Elektronik (USB).
Die serielle Schnittstelle erscheint bei mir im Linux-System unter /dev/ttyUSB0.
Serielle Schnittstelle auf 300bps 7bit Even 1-Stopbit einstellen - z.B. unter Linux durch Konfiguration
in minicom und Verlassen des Programms mit Strg-A Q (Verlassen ohne Beenden der Verbindung).
Die Konfiguration der seriellen kann mit 'stty -g -F <serielles Device>' ausgelesen und mit
'stty -F <serielles Device> <lange Zeichenkette mit Doppelpunkten>' wieder hergestellt werden.
Test hat bei mir funktioniert mit:
echo -n -e '\x2F\x3F\x21\x0D\x0A' > <serielles Device>; sleep 2; echo -n -e '\x06\x30\x30\x30\x0D\x0A' > <serielles Device>; sleep 0.5; cat <serielles Device>
Als Ausgabe habe ich folgendes erhalten:
0.0.0(90540888)
0.0.1(PAF)
F.F(00)
0.2.0(1.29)
1.8.0*00(001582.34)
2.8.0*00(000051.05)
C.2.1(1D070F282300)( )
0.2.2(:::::G11)!
Verwertbarer wird das ganze nach Bestimmung der Länge mit
echo -n -e '\x2F\x3F\x21\x0D\x0A' > <serielles Device>; sleep 2; echo -n -e '\x06\x30\x30\x30\x0D\x0A' > <serielles Device>; sleep 0.5; cat <serielles Device> | (read -N 184 T; echo $T | xxd)
0000000: 0230 2e30 2e30 2839 3035 3430 3838 3829 .0.0.0(90540888)
0000010: 0d20 302e 302e 3128 5041 4629 0d20 462e . 0.0.1(PAF). F.
0000020: 4628 3030 290d 2030 2e32 2e30 2831 2e32 F(00). 0.2.0(1.2
0000030: 3929 0d20 312e 382e 302a 3030 2830 3031 9). 1.8.0*00(001
0000040: 3538 322e 3732 290d 2032 2e38 2e30 2a30 582.72). 2.8.0*0
0000050: 3028 3030 3030 3531 2e30 3529 0d20 432e 0(000051.05). C.
0000060: 322e 3128 3144 3037 3046 3238 3233 3030 2.1(1D070F282300
0000070: 2928 2029 0d20 302e 322e 3228 3a3a 3a3a )( ). 0.2.2(::::
0000080: 3a47 3131 2921 0d20 030a :G11)!. ..
In FHEM sieht die Definition bei mir so aus:
define 12EC3g OBIS /dev/vtty0@300,7,E,1 VSM102
attr 12EC3g icon measure_power_meter
attr 12EC3g interval 60
Eine Ausgabe habe ich als Screenshot angehängt.
Wie zu sehen ist, ergeben die Felder total_consumption und total_feed eine sinnvolle Ausgabe. Die restlichen Felder scheinen etwas durcheinander gekommen zu sein.
In meiner Konfiguration hängt der USB-IR-Schreib-/Lesekopf an einem RaspberryPi, da mein FHEM nicht neben dem Zähler steht.
Auf dem RPI habe ich ser2net installiert, das den seriellen Port /dev/ttyUSB0 vom IR-Schreib/-Lesekopf via tcp im Netzwerk verfügbar macht.
Im FHEM läuft das Kommando 'socat TCP4:192.168.2.4:2000 pty,link=/dev/vtty0,raw,echo=0,user=fhem', das den seriellen Port als /dev/vtty0 verfügbar macht - Besitzer ist der Benutzer fhem, unter dem bei mir fhem.pl läuft.
Vielleicht ist die Information ja für weitere Benutzer hilfreich.
Natürlich würde ich mich freuen, wenn die hex-Daten von oben dabei helfen, die Felder für die FHEM-readings besser für diesen Zähler zuzuordnen.
Mit freundlichen Grüßen
Chris
Irgendwie ist da etwas merkwürdig.
Als ich mit OBIS vor kurzem angefangen bin, hatte ich auf Anhieb eine CPU-Auslastung von 10% bei einer 2-Sekunden-Übertragung des Stromzählers.
Daraufhin hatte ich pollingMode=on und Intervall auf 5 Sek. gesetzt. Daraufhin sank die CPU-Auslastung auf ungefähr 5%.
Irgendwann am Tag (im Zuge der Rumspielerei in FHEM) stieg die Auslastung wieder auf 10%. Ich denke, dass war, als ich Intervall auf 60 Sekunden gesetzt hatte.
Versuche ich das aber nun zu reproduzieren (also Intervall temporär auf 5s), so sinkt die Auslastung nicht mehr.
Ehrlich gesagt sehe ich plötzlich keinen Unterschied mehr zwischen ein- oder ausgeschaltetem pollingMode.
Hat jemand eine Idee woran das liegen könnte?
Hallo zusammen,
mittlerweile versuche ich auch mit dem OBIS-Modul meinen Zähler von Hager (EHZ361) mittels IR-Lesekopf ( von den Volkszählern) auszulesen.
Die Schnittstelle habe ich unter /dev/ttyUSB0 auch gefunden.
Definiere ich nun den Lesekopf mit:
define myObis OBIS /dev/ttyUSB0@9600,7,N,1 SML
wird mir als Status "opend" angezeigt.
im Logfile wird aber angezeigt, das sekundlich die Schnittstelle connected und dann wieder disconnected wird.
Habe auch schon die ganzen Parameter der Baudrate durch gehechelt, aber ohne erfolg >:(
Habt ihr vielleicht eine Idee woran das liegen kann??
Gruß
PappaB
fhem auf Rasp 2B; FS20, 1-Wire
Hab ja auch einen Hager ehz. Der macht aber kein SML, sondern OBIS-Klartext. Bist Du Dir mit SML sicher ? Schnittstellenparameter sollten stimmen. Ansonsten würd ich das Verhalten auf den Volkszähler schieben :( Mit einem gekauften Lesekopf und Anschluss an einen USB-RS232 Konverter hab ich keinerlei Probleme. Der Einfachheit halber hatte ich damals mit HTERM und dem Windows-PC getestet, bis dann endlich die Klartext-Daten sichtbar waren.
Grüße Markus
Edit: schnell noch mal auf mein device geguckt und siehe da, doch andere Paramter nämlich mit Parity Even, also 9600,7,E,1
Edit2: @FunkOdyssey: Das Gefühl hab ich auch. Seit der SML-Integration, holpert das Modul an verschiedenen Stellen :-\
Zitat von: Pappa B am 11 Oktober 2016, 17:22:37
mittlerweile versuche ich auch mit dem OBIS-Modul meinen Zähler von Hager (EHZ361) mittels IR-Lesekopf ( von den Volkszählern) auszulesen.
Die Schnittstelle habe ich unter /dev/ttyUSB0 auch gefunden.
Definiere ich nun den Lesekopf mit:
define myObis OBIS /dev/ttyUSB0@9600,7,N,1 SML
Manchmal ist ein Datenblatt hilfreich: http://datenblatt.energiezaehlershop.de/hager/ehz_betriebsanleitung_mid.pdf (http://datenblatt.energiezaehlershop.de/hager/ehz_betriebsanleitung_mid.pdf)
Zitatwird mir als Status "opend" angezeigt.
im Logfile wird aber angezeigt, das sekundlich die Schnittstelle connected und dann wieder disconnected wird.
Hast du weitere USB-Devices? Mit Seriell-USB-Wandlern die sich ins Gehege kommen? Z.B. FTDI Fakes?
Gruß Friedrich
Wie ich weiter oben bereits erwähnte, muss ich nach jedem Neustart die Device-Definition einmal öffnen und speichern.
Ich habe nun versucht, das ständige manuell Modizifieren der DEFinition mit einem DOIF zu umgehen:
(
[global:?INITIALIZED]
)
(
(modify myObis /dev/ttyUSB0@9600,7,E,1 Standard)
)
Leider ohne Erfolg. Vielleicht ist das DOIF zu früh oder ein - im Hintergrund - ausgeführtes modify reicht nicht aus.
Zitat von: FunkOdyssey am 13 Oktober 2016, 16:18:07
Wie ich weiter oben bereits erwähnte, muss ich nach jedem Neustart die Device-Definition einmal öffnen und speichern.
Ich habe nun versucht, das ständige manuell Modizifieren der DEFinition mit einem DOIF zu umgehen:
hat du probiert mein workaround?
https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777 (https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777)
Zitat von: immi am 13 Oktober 2016, 18:58:23
hat du probiert mein workaround?
https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777 (https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777)
Perfekt. Läuft einwandfrei.
Vielleicht sollte man diese Fix einchecken. :-)
Dann habe ich nur noch die Massen an Warnings im FHEM-Log:
2016.10.09 00:58:10 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4131, <GEN14851> line 1.
2016.10.09 00:58:11 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 525, <GEN14851> line 1.
Hallo zusammen,
habe nun mein System etwas aufgeräumt und alle überflüssigen USB-Devices entfernt.
Zusätzlich habe ich mir noch einen anderen IR-Lesekopf besorgt.
Die Schnittstelle wird nun korrekt connected :D
Über minicom erhalte ich die Daten im Klartext:
/HAG5eHZ010C_EHZ1NA12
1-0:0.0.0*255(1095090000035229)
1-0:2.8.0*255(154464.0085)
1-0:96.5.5*255(82)
0-0:96.1.255*255(0000035229)
1-0:32.7.0*255(227.90*V)
1-0:52.7.0*255(226.39*V)
1-0:72.7.0*255(225.85*V)
1-0:31.7.0*255(009.31*A)
1-0:51.7.0*255(009.22*A)
1-0:71.7.0*255(008.52*A)
1-0:21.7.0*255(-01884*W)
1-0:41.7.0*255(-01897*W)
1-0:61.7.0*255(-01683*W)
1-0:96.50.0*0(FE)
1-0:96.50.0*1(07D1)
1-0:96.50.0*2(1A)
1-0:96.50.0*3(12)
1-0:96.50.0*4(21)
1-0:96.50.0*5(02)
1-0:96.50.0*6(003D381B130909710403640500009F80)
1-0:96.50.0*7(00)
Bei fhem sieht das ganze dann so aus:
�HAG5eHZ0�0�_�HZ�NA���
�
�-0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�5����.�6�9��
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(���.9��V��
�-0:5�.�.0��55(���.30�V��
�-0:��.�.0��55(���.36�V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.���A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000���ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0�D���
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
Habt ihr einen Tipp für mich wie ich das klar stellen kann??
Gruß
Thomas
Du hattest meine Antwort auf Deinen vorhergehenden Post gelesen ? Wie hast Du das device definiert ?
Grüße Markus
Hallo Markus,
deine Antwort hatte ich gelesen und entsprechend auch die Parameter angepasst:
define myObis OBIS /dev/ttyUSB1@9600,7,E,1 Standard
attr myObis channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
attr myObis interval 300
attr myObis pollingMode on
attr myObis room Zähler
Das sollte dann ja eigentlich funktionieren, tut es aber nicht. :( :(
Gruß
Thomas
Hmm, wie hast Du die Daten denn zusammengestellt, die Du unter
ZitatBei fhem sieht das ganze dann so aus:
gelistet hast ? Aus dem Log(bei verbose=5) oder event monitor oder..... kopiert ? Dann kann ich mal versuchen das nachzustellen.
Das ist ein reiner Erzeugungszähler, oder ?
Grüße Markus
habe die Daten mit "list myObis" aufgerufen.
Ja mit dem Zähler erfasse ich meinen erzeugten Strom von meinem BHKW.
Gruß
Thomas
Zitathabe die Daten mit "list myObis" aufgerufen.
Nee, kann nicht sein. Mit list devicename werden Dir internals und readings angezeigt.
sorry,
aber wenn ich "list myObis" aufrufe bekomme ich folgenden Infos:
Internals:
DEF /dev/ttyUSB0@9600,7,E,1 Standard
DeviceName /dev/ttyUSB0@,7,E,1
FD 51
MeterType Standard
NAME myObis
NR 273
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-10-21 18:06:44 state opened
Helper:
BUFFER -0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�5503�.9�6���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(���.���V��
�-0:5�.�.0��55(���.���V��
�-0:��.�.0��55(��6.���V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.���A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0�D0��
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
�HAG5eHZ0�0�_�HZ�NA���
�
�-0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�5503�.9�6���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(���.�0�V��
�-0:5�.�.0��55(���.���V��
�-0:��.�.0��55(��6.���V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.���A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0�D0��
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
�HAG5eHZ0�0�_�HZ�NA���
�
�-0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�5503�.9�6���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(��9.53�V��
�-0:5�.�.0��55(���.99�V��
�-0:��.�.0��55(���.���V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.�0�A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0�D���
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
EoM -1
SPEED 5
SpeedChange
SpeedChange2
TRIGGERTIME 1477066000.74933
Channels:
1 energy_current
1.7 Aktuelle_Leistung
1.8 energy_total
2.8 feed_total
21 energy_L1
31 power_L1
41 energy_L2
51 power_L2
61 energy_L3
71 power_L3
DEVICES:
300
Attributes:
channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
interval 300
pollingMode on
room Zähler
verbose 3
Was kann daran nicht stimmen?
Internals bekomme ich ja, aber keine readings.
Die Feinheiten ;)
Konnte nicht ahnen, dass das der Inhalt des Buffers ist >:(
Das bedeutet aber, dass Deine Daten im buffer auflaufen und nicht abgearbeitet werden. Vielleicht nur der altbekannte Fehler, dass die Schnittstelle nicht mehr richtig initialisiert wird ? Mach mal ein paar modifys auf das device. Damit bekomme ich das device immer zum laufen.
Ansonsten auch mal verbose 5 auf das device und GANZ wichtig, mal den Auszug aus dem Log hier posten.
Grüße Markus
Zitat von: KölnSolar am 22 Oktober 2016, 00:40:25
Nee, kann nicht sein. Mit list devicename werden Dir internals und readings angezeigt.
Internals:
DEF /dev/ttyUSB0@9600,7,E,1 Standard
DeviceName /dev/ttyUSB0@,7,E,1 Ist das denn richtig? Müsste nicht beim DeviceName auch die Baudrate angezeigt werden.
Ich habe noch SMLUSB da wird beim Device das gleiche angezeigt wie in der DEF.
Gruß Friedrich
Du Fuchs ;D natürlich müsste das da stehen !
Und jetzt hab ich es nachgestellt ! Es ist das bekannte Initialisierungsproblem. Auch ich habe dann den buffer gefüllt und die Baudrate fehlt.
Nachdem der zaehler über modify initilisiert ist, verschwinden die buffer-Inhalte und auch die Baudrate steht im Devicename.
Vielleicht hilft das ja Stefan den bug zu fixen.
Grüße Markus
Zitat von: immi am 25 September 2016, 21:19:37
Hi HarryT
I had the same symptoms (I do not know, if we have the same root cause).
It is now working again for me, using last version but with the fix posted above.
https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777 (https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777)
immi
Sorry for the hugh delay. This patch indeed solves my problem. I expected it was already implemented before my test.
Thanks.
Would be nice if the versio in trunk would be fixed.
{HT}
Zitat von: HarryT am 27 Oktober 2016, 23:27:46
Sorry for the hugh delay. This patch indeed solves my problem. I expected it was already implemented before my test.
Thanks.
Would be nice if the versio in trunk would be fixed.
{HT}
https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777 (https://forum.fhem.de/index.php/topic,51948.msg494777.html#msg494777)
Hi Harry and FunkOdyssey
I am not going to commit the patch for 2 reasons
1) Only the OBIS-Modulowner (stefan Icinger) should update his module
2) I have not the possibility to check sideeffects on other meeters. I posted the patch, because it fixed the issues on my meeter.
immi
Das weiß ich doch. :-)
Zitat von: FunkOdyssey am 28 Oktober 2016, 11:29:14
Das weiß ich doch. :-)
The same for me.
It is just that I don´t see a reaction of Stefan while he was very responsive in the past. I hope the OBIS module is not abandoned.
{HT}
Hi,
The module is not abandoned, I just had almost absolutely no time in the past.
If all goes well, i'll commit an Update in the midst of next week.
Stefan
Gesendet von meinem SM-N9005 mit Tapatalk
Zitat von: Icinger am 28 Oktober 2016, 16:10:14
Hi,
The module is not abandoned, I just had almost absolutely no time in the past.
If all goes well, i'll commit an Update in the midst of next week.
Stefan
Gesendet von meinem SM-N9005 mit Tapatalk
Nice. Happy to hear OBIS is still maintained. If useful, I volunteer for testing.
{HT}
Zitat von: Icinger am 29 Mai 2016, 21:05:33
Hi Markus,
hab im anderen Thread schon geantwortet.
Ich überlege grade, was das kleinere Übel der beiden Lösungen ist, die mir grade einfallen:
1) Universeller, aber schlecht, weils alle bisherigen Nutzer betrifft:
das "*xxx" in die RegEx mitaufnehmen, somit würde für jede Zeile dann ein zusätzliches Reading erstellt, welches auch mit dem Channel-Attribut gemappt werden kann.
2) Spezieller, aber betrifft eben nur die Nutzer dieses einen Meters:
einen neuen Metertyp, und für diesen dann alle RegExes im Modul einzeln anpassen.
Ausserdem überlege ich grade, wie ich das mit der Baudrate machen könnte.
Grundsätzlich kann in der ersten Antwort ans Meter die zukünftige Baudrate mitgegeben werden.
Würde aber bedeuten, dass ich zuerst die Schnittstelle mit der Baudrate, die im define angegeben ist, öffnen muss, dann das Init schicken, und danach irgendwoher die Info bekommen muss, auf welche neue Speed der User denn umsteigen will.
Da dieses Init in der Define-Routine gesendet wird, kommt ein eventuelles Attribut leider zu spät.
Also entweder eine zusätzliche, optionale Angabe im Define-String, oder die Baudrate nach dem Init fix auf die höchstmögliche Geschwindigkeit setzen (was mir aber nicht so wirklich gefällt)
lg, Stefan
I guess I have troubles with this.
I use:
attr SmartMeter channels {"0.0.1.0.0"=>"date-time_laatste_P1_bericht", "0.1.24.1.0"=>"_andere_apparaten_op_de_M-Bus", "0.1.24.2.1"=>"VerbruikteHoeveelheidGas", "0.1.96.1.0"=>"_identificatie_van_de_gasmeter", "0.0.96.1.1"=>"_equipment_identifier", "0.0.96.7.9"=>"_number_of_long_power_failures_in_any_phase", "0.0.96.7.21"=>"_number_of_power_failures_in_any_phase", "0.0.96.13.1"=>"BerichtNumeriek", "0.0.96.13.0"=>"BerichtTekst", "0.0.96.14.0"=>"ActueleTarief", "1.0.1.7.0"=>"HuidigVerbruik", "1.0.2.7.0"=>"HuidigTeruglevering", "1.0.1.8.1"=>"ElektriciteitLaagtarief", "1.0.1.8.2"=>"ElektriciteitsstandNormaaltarief", "1.0.2.8.1"=>"ElektriciteitsstandTerugleveringLaagtarief", "1.0.2.8.2"=>"ElektriciteitsstandTerugleveringNormaaltarief", "1.0.21.7.0"=>"_Instantaneous_active_power_L1_P_in_W", "1.0.22.7.0"=>"_Instantaneous_active_power_L1_-P_in_W", "1.0.32.32.0"=>"_number_of_voltage_sags_in_phase_L1", "1.0.32.36.0"=>"_number_of_voltage_swells_in_phase_L1", "1.0.99.97.0"=>"_power_Failure_Event_Log_long_power_failures", "1.0.31.7.0"=>"_instantaneous_current_L1_-P", "1.3.0.2.8"=>"_DSMR_version_4.0"}
And now I don´t get the readings from everything which had a _Ch1 etc in the past. The values are read fine if I use verbose 5
OBIS (SmartMeter) - Msg-Parse: 1-0:1.8.1(000595.143*kWh)
and they are visible in the readings of the fhem GUI.
But with ReadingsVal("SmartMeter","ElektriciteitLaagtarief_Ch1","?") I get an ?
So there must be an easy explanation but I don't see it. Any hint?
Thanks
{HT}
Zitat1.0.1.8.1"=>"ElektriciteitLaagtarief"
ZitatReadingsVal("SmartMeter","ElektriciteitLaagtarief_Ch1","?")
should be ReadingsVal("SmartMeter","ElektriciteitLaagtarief","?")
Zitat von: KölnSolar am 30 Oktober 2016, 00:04:11
should be ReadingsVal("SmartMeter","ElektriciteitLaagtarief","?")
Thanks that worked.
_Ch1 seems indeed no longer needed.
{HT}
Hallo,
nachdem ich mein System noch einmal neu aufgesetzt und alle eure guten Ratschläge umgesetzt habe, stehe ich mit meiner Zählerauslesung immer noch auf dem Schlauch. :-[ :-\
Meine Definition sieht so aus:
define myObis OBIS /dev/ttyUSB0@9600,7,E,1 Standard
attr myObis channels {"1.7"=>"Aktuelle_Leistung","1.8"=>"energy_total","2.8"=>"feed_total"}
attr myObis interval 300
attr myObis pollingMode on
attr myObis room Zähler
attr myObis verbose 3
mit verbose 5 wird meine LOG-Datei vollgemüllt mit jeder Menge von "parsing" - Einträgen:
2016.11.03 17:15:02 3: Opening myObis device /dev/ttyUSB0
2016.11.03 17:15:02 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.03 17:15:02 3: Init done
2016.11.03 17:15:02 3: myObis device opened
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:40 4: parsing....
2016.11.03 17:15:41 4: parsing....
2016.11.03 17:15:41 4: parsing....
2016.11.03 17:15:42 4: parsing....
und wenn ich das Device öffne habe ich immer noch die Hieroglyphen:
Internals:
DEF /dev/ttyUSB0@9600,7,E,1 Standard
DeviceName /dev/ttyUSB0@9600,7,E,1
FD 51
MeterType Standard
NAME myObis
NR 213
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-11-03 17:15:02 state opened
Helper:
BUFFER -0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�55959.900���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(��6.�3�V��
�-0:5�.�.0��55(���.03�V��
�-0:��.�.0��55(��3.���V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.�0�A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0��Ʃ�
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
�HAG5eHZ0�0�_�HZ�NA���
�
�-0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�55959.900���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(��6.�9�V��
�-0:5�.�.0��55(���.50�V��
�-0:��.�.0��55(��3.9��V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.�0�A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0��Ʃ�
�-0:96.50.0��(�é�
�-0:96.50.0�3(����
�-0:96.50.0��(����
�-0:96.50.0�5(0���
�-0:96.50.0�6(003D3��B�30909��0�036�0500009Ƹ0��
�-0:96.50.0��(00��
!�
EoM -1
SPEED 5
SpeedChange
SpeedChange2
TRIGGERTIME 1478189702.4586
Channels:
1.7 Aktuelle_Leistung
1.8 energy_total
2.8 feed_total
DEVICES:
300
Attributes:
channels {"1.7"=>"Aktuelle_Leistung","1.8"=>"energy_total","2.8"=>"feed_total"}
interval 300
pollingMode on
room Zähler
verbose 3
Mittlerweile bin ich ganz schön am verzweifeln :-[ :-\
Thomas
Aber nicht, wenn Du meinen Tipp an Dich vom 22.10. beherzigst ::)
Morgen oder Übermorgen gibts ne neue Version.
Habe heut ein Modul zum Testen an Harry geschickt, sobald ich von ihm das OK habe, wirds eingecheckt.
lg, Stefan
Hallo Markus.
ich muss dich leider enttäuschen :-X
Trotz mehrmaliges modify des Devices ändert sich nichts.
Hin und wieder kommt mal ein input/output Error oder ein"/dev/ttyUSB0 reappeared (myObis)" aber ansonsten immer ein "Init done".
2016.11.04 11:19:24 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:19:24 3: Can't open /dev/ttyUSB0: Input/output error
2016.11.04 11:19:24 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:19:24 3: Init done
2016.11.04 11:19:24 1: /dev/ttyUSB0 reappeared (myObis)
2016.11.04 11:20:12 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:20:12 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:20:12 3: Init done
2016.11.04 11:20:12 3: myObis device opened
2016.11.04 11:21:35 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:21:35 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:21:35 3: Init done
2016.11.04 11:21:35 3: myObis device opened
2016.11.04 11:23:13 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:23:13 3: Can't open /dev/ttyUSB0: Input/output error
2016.11.04 11:23:13 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:23:13 3: Init done
2016.11.04 11:23:13 1: /dev/ttyUSB0 reappeared (myObis)
2016.11.04 11:24:31 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:24:31 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:24:31 3: Init done
2016.11.04 11:24:31 3: myObis device opened
2016.11.04 11:25:24 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:25:24 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:25:24 3: Init done
2016.11.04 11:25:24 3: myObis device opened
2016.11.04 11:26:38 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:26:39 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:26:39 3: Init done
2016.11.04 11:26:39 3: myObis device opened
2016.11.04 11:54:54 3: Opening myObis device /dev/ttyUSB0
2016.11.04 11:54:54 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.04 11:54:54 3: Init done
2016.11.04 11:54:54 3: myObis device opened
2016.11.05 22:01:52 3: Opening myObis device /dev/ttyUSB0
2016.11.05 22:01:52 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.05 22:01:52 3: Init done
2016.11.05 22:01:52 3: myObis device opened
2016.11.05 22:04:58 3: Opening myObis device /dev/ttyUSB0
2016.11.05 22:04:58 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.05 22:04:58 3: Init done
2016.11.05 22:04:58 3: myObis device opened
2016.11.05 22:07:16 3: Opening myObis device /dev/ttyUSB0
2016.11.05 22:07:16 3: Setting myObis serial parameters to 9600,7,E,1
2016.11.05 22:07:16 3: Init done
2016.11.05 22:07:16 3: myObis device opened
Hi Leute,
so, hat paar Tage länger gedauert, aber jetzt habe ich grade eine neue Version hochgeladen.
Hab erstmal das setSpeed rausgenommen, das war ja eh noch experimentell.
Das hat auch die Probleme verursacht.
Lt. Harry läufts seit gestern fehlerfrei.
@PappaB:
�HAG5eHZ0�0�_�HZ�NA���
�
�-0:0.0.0��55(�095090000035��9��
�-0:�.�.0��55(�55959.900���
�-0:96.5.5��55(00��
0-0:96.�.�55��55(0000035��9��
�-0:3�.�.0��55(��6.�9�V��
�-0:5�.�.0��55(���.50�V��
�-0:��.�.0��55(��3.9��V��
�-0:3�.�.0��55(000.00�A��
�-0:5�.�.0��55(000.00�A��
�-0:��.�.0��55(000.�0�A��
�-0:��.�.0��55(+00000�ש�
�-0:��.�.0��55(+00000�ש�
�-0:6�.�.0��55(+000�6�ש�
�-0:96.50.0�0(Ÿ��
�-0:96.50.0��(0��Ʃ�
Das sieht mir nach einem Parity-Fehler aus, sowas hatte ich auch schon irgendwann mal in einem anderen Zusammenhang.
lg, Stefan
Zitat von: FunkOdyssey am 16 Oktober 2016, 14:33:17
Dann habe ich nur noch die Massen an Warnings im FHEM-Log:
2016.10.09 00:58:10 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4131, <GEN14851> line 1.
2016.10.09 00:58:11 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 525, <GEN14851> line 1.
Hast du zufällig auch das hier gefixt?
Update: Hat sich erledigt. Habe es in den Commits gesehen.
Hi Stefan,
da ist aber wohl was Falsches im SVN gelandet :(
In Zeile 529 habe ich die } entfernt und dann scheints zu laufen.
Zitat2016.11.07 08:46:18 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 444, <$fh> line 161.
2016.11.07 08:46:18 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 748, <$fh> line 161.
2016.11.07 08:46:18 3: Opening zaehler device /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
2016.11.07 08:46:18 3: Setting zaehler serial parameters to 9600,7,E,1
2016.11.07 08:46:18 3: Init done
2016.11.07 08:46:18 3: zaehler device opened
3* den Restart getestet und immer war das device (ohne modify) sofort verfügbar und auf Empfang ;)
Grüße Markus
Zitat von: KölnSolar am 07 November 2016, 08:55:24
Hi Stefan,
da ist aber wohl was Falsches im SVN gelandet :(
In Zeile 529 habe ich die } entfernt und dann scheints zu laufen.3* den Restart getestet und immer war das device (ohne modify) sofort verfügbar und auf Empfang ;)
Grüße Markus
:-( a last minute change. The other changes where tested by me.
I hope Stefan can change this again.
{HT}
Hallo zusammen
ich wollte gerade das Modul auf einem frischen FHEM zum testen einbinden
define MyObis OBIS /dev/ttyVoltcraft@9600,7,E,1 SML
Ich bekomme aber folgende Fehlermeldungen
Zitat
Global symbol "$v1" requires explicit package name at ./FHEM/47_OBIS.pm line 531.
Global symbol "$v1" requires explicit package name at ./FHEM/47_OBIS.pm line 531.
Global symbol "$v2" requires explicit package name at ./FHEM/47_OBIS.pm line 532.
Global symbol "$v2" requires explicit package name at ./FHEM/47_OBIS.pm line 532.
Global symbol "$chan" requires explicit package name at ./FHEM/47_OBIS.pm line 534.
Global symbol "$chan1" requires explicit package name at ./FHEM/47_OBIS.pm line 535.
Global symbol "$v1" requires explicit package name at ./FHEM/47_OBIS.pm line 535.
Global symbol "$v1" requires explicit package name at ./FHEM/47_OBIS.pm line 535.
Global symbol "$chan2" requires explicit package name at ./FHEM/47_OBIS.pm line 536.
Global symbol "$v2" requires explicit package name at ./FHEM/47_OBIS.pm line 536.
Global symbol "$v2" requires explicit package name at ./FHEM/47_OBIS.pm line 536.
Global symbol "$remainingSML" requires explicit package name at ./FHEM/47_OBIS.pm line 546.
Global symbol "$hash" requires explicit package name at ./FHEM/47_OBIS.pm line 546.
Global symbol "$remainingSML" requires explicit package name at ./FHEM/47_OBIS.pm line 546.
Global symbol "$hash" requires explicit package name at ./FHEM/47_OBIS.pm line 547.
Global symbol "$buffer" requires explicit package name at ./FHEM/47_OBIS.pm line 547.
Global symbol "$hash" requires explicit package name at ./FHEM/47_OBIS.pm line 548.
Global symbol "$hash" requires explicit package name at ./FHEM/47_OBIS.pm line 548.
Global symbol "$name" requires explicit package name at ./FHEM/47_OBIS.pm line 549.
Unmatched right curly bracket at ./FHEM/47_OBIS.pm line 550, at end of line
./FHEM/47_OBIS.pm has too many errors.
Fehlt mir noch ein Modul in meiner Installation ?
LG
Stefan
Seit dem letzten Update ist auch bei mir Obis ohne Funktion mit verbose kommt nur
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 4: parsing....
2016.11.07 20:49:23 5: SW:
2016.11.07 20:49:23 4: Wrote
2016.11.07 20:49:23 5: OBIS (Strom) - Internal timer set to 2016-11-07 20:49:33
2016.11.07 20:49:25 4: parsing....
Downgrade hilft...
Hi Leute,
sorry, irgendwie hat sich diese Bracket da mit eingeschlichen :(
Habs grade gefixt.
lg, Stefan
Hallo zusammen,
ich bin leider noch relativ neu in der Materie, konnte aber immerhin den Sensor in FHEM einbinden. :-)
Wie kann ich denn jetzt genau die Werte meines Zählers auslesen? Bisher sieht meine Config so aus:
Attributes
channels {"1.7"=>"Aktuelle_Leistung","1.8"=>"energy_total","2.8"=>"feed_total"}
interval 20
room Strom
Internals
DEF /dev/ttyUSB0@9600,8,N,1 Standard
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 12
MeterType Standard
NAME myObis
NR 33
PARTIAL STATE opened
TYPE OBIS
Unter "Readings" findet sich jedoch leider nur der State "opened".
Dann kommen (noch) keine Readings vom Zähler an, die würden sonst autmatisch angelegt.
Welchen Zähler hast du?
Kommen Daten in einem Terminalprogramm an?
Wir haben einen eHZ-Zähler (von EMH?).
Tatsächlich kommen über cat /dev/ttyUSB0 | od -tx1 keine Daten mehr an. Gestern ging's komischerweise noch.. Bin jetzt leider nicht daheim, kann also den Sensor momentan nicht ab- und wieder anstecken.
Hallo zusammen
ich bekomme auch nur opened angezeigt und keine readings.
was mache ich falsch ?
Über CuteCom sind gestern diese Daten gekommen.
Zitat
2f3f210d0a
063030300d0a
/LGZ5ZMF100AC.M27
F.F(00)
0.0(001LGZ0031633583)
0.2.0(M27)
0.2.1(4757)
0.2.8(FD25)
1.8.0(000013*kWh)
36.7(000.451*kW)
56.7(000.362*kW)
76.7(000.936*kW)
16.7(001.744*kW)
32.7(230*V)
52.7(229*V)
72.7(229*V)
31.7(001.81*A)
51.7(001.69*A)
71.7(004.34*A)
33.7(0.97)
53.7(0.98)
73.7(0.99)
13.7(0.99)
14.7(50.0*Hz)
C.5.0(0400)
C.7.0(0001)
C.7.1(0001)
C.7.2(0000)
C.7.3(0000)
!
define MyObis OBIS /dev/ttyUSB0@300,7,E,1 SML
attr MyObis interval 60
attr MyObis pollingMode on
attr MyObis room Energie
attr MyObis verbose 5
Zitat
2016.11.08 18:35:28 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 444, <$fh> line 38.
2016.11.08 18:35:28 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 748, <$fh> line 38.
2016.11.08 18:35:28 3: Opening MyObis device /dev/ttyUSB0
2016.11.08 18:35:28 3: Setting MyObis serial parameters to 300,7,E,1
2016.11.08 18:35:28 3: Init done
2016.11.08 18:35:28 3: MyObis device opened
2016.11.08 18:35:46 5: OBIS (MyObis) - Internal timer set to 2016-11-08 18:36:46
2016.11.08 18:35:46 5: OBIS (MyObis) - Opening device...
2016.11.08 18:35:46 3: Opening MyObis device /dev/ttyUSB0
2016.11.08 18:35:46 3: Setting MyObis serial parameters to 300,7,E,1
2016.11.08 18:35:46 3: Init done
2016.11.08 18:35:46 3: MyObis device opened
2016.11.08 18:36:46 5: SW:
2016.11.08 18:36:46 4: Wrote
2016.11.08 18:36:46 5: OBIS (MyObis) - Internal timer set to 2016-11-08 18:37:46
Lg
Stefan
Da liegt der Hund begraben:
Zitatdefine MyObis OBIS /dev/ttyUSB0@300,7,E,1 SML
Du bekommst deine Daten als Klartext rein, nicht als SML wie du angegeben hast.
Mit einem
define MyObis OBIS /dev/ttyUSB0@300,7,E,1 Standardsollte alles klappen.
lg, Stefan
Hi
leider nein
/dev/ttyUSB0@300,7,E,1 Standard
Zitat
2016.11.08 19:55:44 5: OBIS (MyObis) - Internal timer set to 2016-11-08 19:56:44
2016.11.08 19:55:44 5: OBIS (MyObis) - Opening device...
2016.11.08 19:55:44 3: Opening MyObis device /dev/ttyUSB0
2016.11.08 19:55:44 3: Setting MyObis serial parameters to 300,7,E,1
2016.11.08 19:55:44 3: Init done
2016.11.08 19:55:44 3: MyObis device opened
2016.11.08 19:56:44 5: SW:
2016.11.08 19:56:44 4: Wrote
2016.11.08 19:56:44 5: OBIS (MyObis) - Internal timer set to 2016-11-08 19:57:44
2016.11.08 19:57:44 5: SW:
2016.11.08 19:57:44 4: Wrote
2016.11.08 19:57:44 5: OBIS (MyObis) - Internal timer set to 2016-11-08 19:58:44
2016.11.08 19:58:18 5: OBIS (MyObis) - Internal timer set to 2016-11-08 19:59:18
2016.11.08 19:58:18 5: OBIS (MyObis) - Opening device...
2016.11.08 19:58:18 3: Opening MyObis device /dev/ttyUSB0
2016.11.08 19:58:18 3: Setting MyObis serial parameters to 300,7,E,1
2016.11.08 19:58:18 3: Init done
2016.11.08 19:58:18 3: MyObis device opened
2016.11.08 19:59:18 5: SW:
2016.11.08 19:59:18 4: Wrote
2016.11.08 19:59:18 5: OBIS (MyObis) - Internal timer set to 2016-11-08 20:00:18
LG
Stefan
P.S.
Komisch ist wenn ich parallel dazu den CuteCom auf dem raspberry anwerfe, werden Daten gelesen.
Kann es sein das was mit
Initialisierungssequenz: /?! (in hex: 2F 3F 21 plus CR LF )
Startsequenz: -000 (in hex: 06 30 30 30 plus CR LF)
noch nicht passt ?
Nein, kann eigentlich nicht sein, klappt sonst eigentlich überall.
Meiner braucht auch so eine Init und des funktioniert.
AAAAABER:
Zitatparallel dazu den CuteCom
Ja, ne, is klar.....Die Schnittstelle kann eigentlich nur von einem Programm geöffnet sein.
Somit blockiert die CuteCom ja den Port.
Aber ansonsten bin ich grad auch ratlos, was des sein könnte.
Bin jetzt leider auch (ab sofort) die nächsten beiden Tage nicht hier, um noch was zu schaun.
Vielleicht hat ja sonst noch jemand ne Idee?
lg, Stefan
Hallo zusammen
ich hab es gefunden die Initialisierung für Standard hat im Modul gefehlt
Hab es angepasst und es funktioniert.
Evtl sollte man einen neuen Type erstellen (LandisGyrE350USB)
"Standard" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
Zitat
0.0 001LGZ0031633583 2016-11-08 21:33:06
0.2.0 M27 2016-11-08 21:33:07
0.2.1 4757 2016-11-08 21:33:07
0.2.8 FD25 2016-11-08 21:33:08
13.7 0.97 2016-11-08 21:33:15
14.7 50.0*Hz 2016-11-08 21:33:16
16.7 001.194*kW 2016-11-08 21:33:11
31.7 001.95*A 2016-11-08 21:33:12
32.7 227*V 2016-11-08 21:33:11
33.7 0.98 2016-11-08 21:33:14
36.7 000.434*kW 2016-11-08 21:33:09
51.7 001.33*A 2016-11-08 21:33:13
52.7 228*V 2016-11-08 21:33:11
53.7 0.97 2016-11-08 21:33:14
56.7 000.267*kW 2016-11-08 21:33:09
71.7 002.62*A 2016-11-08 21:33:13
72.7 227*V 2016-11-08 21:33:12
73.7 0.97 2016-11-08 21:33:15
76.7 000.495*kW 2016-11-08 21:33:10
C.5.0 400 2016-11-08 21:33:16
C.7.0 1 2016-11-08 21:33:16
C.7.1 1 2016-11-08 21:33:17
C.7.2 0 2016-11-08 21:33:17
C.7.3 0 2016-11-08 21:33:18
Version LGZ5ZMF100AC.M27 2016-11-08 21:28:05
energy_total 33 kWh 2016-11-08 21:33:08
state opened 2016-11-08 21:27:04
LG
Stefan
@Icinger:
Ich habe das Attribut "unitReadings" jetzt wieder gelöscht, da mich die Einheiten in allen Folgemodulen wie ReadingsGroup, SVG, etc. stören.
Leider ist aber auch nach der neuesten Änderung noch eine (bei mir: minütliche) WARNING im FHEM-Log.
2016.11.09 10:01:14 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 529, <GEN495> line 1.
Hey zusammen :)
Ich hab' leider immer noch das Problem, dass bei mir keine Readings ankommen. Der Sensor liefert brav seine Werte (getestet via "$ cat /dev/ttyUSB0 | od -tx1").
Im Log tauchen folgende Fehler/Warnungen auf:
(Neustart)
2016.11.09 18:38:56 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 444, <$fh> line 37.
2016.11.09 18:38:56 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 748, <$fh> line 37.
2016.11.09 18:38:56 3: Opening MyObis device /dev/ttyUSB0
2016.11.09 18:38:56 3: Setting MyObis serial parameters to 9600,8,N,1
2016.11.09 18:38:56 3: Init done
2016.11.09 18:38:56 3: MyObis device opened
[..]
2016.11.09 18:39:00 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 741.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 755.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 757.
2016.11.09 18:39:00 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 757.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 738.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 740.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 741.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 529.
2016.11.09 18:40:11 3: 8
2016.11.09 18:41:11 3: 8
2016.11.09 18:42:04 3: 8
2016.11.09 18:43:06 3: 8
Weiß jemand Rat?
Wir haben einen EMH eHZ-I Zähler daheim. Laut Datenblatt sendet der alles über SML.
PS:
Wenn ich Verbose 5 einstelle, wird der Log von der Meldung "parsing ..." nur so überladen... :-(
Der Zähler macht doch SML, oder ? Dann anstatt Standard auch als SML definieren .
Grüße Markus
Hab' ich bereits gestern korrigiert. Trotzdem hatte es nich funktioniert..
Interessanterweise kamen aber heute Nacht gegen 5:58 Uhr tatsächlich einmal die Werte an - das war's aber auch schon.
Alle 30 Sekunden kommt im Log folgender Eintrag vor: "3: 8"
Meine Attribute:
event-min-interval 30
interval 30
Hab die Lösung gefunden: Einfach die Attribute rausnehmen. Geht plötzlich, zwar weiterhin unregelmäßig, aber wenigstens im ~5min-Takt. Ist es irgendwie möglich das in "Echtzeit" (5sec oder so) abzufragen?
Zitat von: Housefrau am 10 November 2016, 08:31:17
Hab' ich bereits gestern korrigiert. Trotzdem hatte es nich funktioniert..
Interessanterweise kamen aber heute Nacht gegen 5:58 Uhr tatsächlich einmal die Werte an - das war's aber auch schon.
Alle 30 Sekunden kommt im Log folgender Eintrag vor: "3: 8"
Meine Attribute:
event-min-interval 30
interval 30
Hab die Lösung gefunden: Einfach die Attribute rausnehmen. Geht plötzlich, zwar weiterhin unregelmäßig, aber wenigstens im ~5min-Takt. Ist es irgendwie möglich das in "Echtzeit" (5sec oder so) abzufragen?
Die " 3: 8 " bekomme ich nun mit dem Update auch...
hänge mich mal an :)
Hallo zusammen,
ich habe das gleiche Problem. Verbose auf 0 zu setzen hat keine Wirkung gezeigt.
Die Ursache ist wohl in der 47_OBIS.pm in Zeile 304 zu finden:
Log 3,@list;
Nach auskommentieren verschwinden zumindest die Log Meldungen.
Gruß
Tim
Hi Leute,
Solange ich von niemandem mit diesem Problem ein Log5 bekomme (am besten per PN), kann ich da leider nichts machen.
Mit den bisherigen ca. 40 Datensätzen von verschiedenen Zählern kann ich das absolut nicht nachstellen.
lg, Stefan
Zitat von: Housefrau am 10 November 2016, 08:31:17
Alle 30 Sekunden kommt im Log folgender Eintrag vor: "3: 8"
just follow the hint from barawer
delete line 304 (Log 3,@list;)
immi
Ich bin mit der CPU-Auslastung generell ja ganz gut zufrieden.
Ich hatte hier im Thread (https://forum.fhem.de/index.php/topic,51948.msg501950.html#msg501950) ja auch schon einmal angemerkt, dass die CPU Auslastung mal dauerhaft höher und mal dauerhaft niedriger ist. Nun habe ich mal darauf geachtet.
- Bearbeite ich das Device-DEF, dann habe ich eine Auslastung von 5-6%
- Nach jedem FHEM Update sinkt die CPU-Auslastung merkwürdigerweise auf 1-2%
Anbei Screenshots der letzten beiden Tage. Man erkennt ganz kurz eine höhere Auslastung (durch CommandRef-Join verursacht) und dann den Sprung nach unten.
Guten Abend zusammen,
ich konnte nun nach längerem Suchen und Probieren die "Schuld" der unregelmäßigen Readings (kommen immer nur alle 3-5min) auf meinen Zähler schieben.
Wir haben einen EMH EHZ-N (2016). Hat sonst wer Probleme mit diesem Zähler?
Verbose 5 zeigt folgendes:
[unendlich viele "parsing ..."]
2016.11.15 19:14:12 5: OBIS: Full message-> 1B1B1B1B010101017605007476646200620072630101760107FFFFFFFFFFFF050026D2220B0A01454D4800005A1F557262016426DDAF62016347460076050074766562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A1F55070100620AFFFF7262016426DDAF7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A1F550177070100010800FF641C81047262016426DDAF621E52FF644640FF0177070100010801FF017262016426DDAF621E52FF62000177070100010802FF017262016426DDAF621E52FF644640FF0177070100020800FF017262016426DDAF621E52FF6333250177070100020801FF017262016426DDAF621E52FF62000177070100020802FF017262016426DDAF621E52FF6333250177070100100700FF0101621B5200530C6B010101637E98007605007476666200620072630201710163B336001B1B1B1B1A007AD2
2016.11.15 19:14:12 5: OBIS: Telegram=1B1B1B1B010101017605007476646200620072630101760107FFFFFFFFFFFF050026D2220B0A01454D4800005A1F557262016426DDAF62016347460076050074766562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A1F55070100620AFFFF7262016426DDAF7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A1F550177070100010800FF641C81047262016426DDAF621E52FF644640FF0177070100010801FF017262016426DDAF621E52FF62000177070100010802FF017262016426DDAF621E52FF644640FF0177070100020800FF017262016426DDAF621E52FF6333250177070100020801FF017262016426DDAF621E52FF62000177070100020802FF017262016426DDAF621E52FF6333250177070100100700FF0101621B5200530C6B010101637E98007605007476666200620072630201710163B336001B1B1B1B1A007AD2
2016.11.15 19:14:12 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.11.15 19:14:12 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.11.15 19:14:12 5: OBIS (Stromzaehler) - Msg-Parse: !
[unendlich viele "parsing ..."]
Der Zähler schickt laut Datenblatt alles im Sekundentakt. Wenn ich von 8,N,1 auf 7,E,1 umstelle, kommen nur CRC-Fehler hoch.
Irgendwer eine Idee? Bin echt am verzweifeln. :(
Hi Leute,
diese ganzen Fehler:
2016.11.09 18:39:00 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 757.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 738.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 740.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 741.
2016.11.09 18:39:00 1: PERL WARNING: Use of uninitialized value $v2 in substitution (s///) at ./FHEM/47_OBIS.pm line 529.behebe ich im laufe des abends mit einem commit :)
@housefrau: Ich schau mir morgen mal deinen Datensatz genauer durch, warum da nicht mehr geparst wird.
@StefanM:
Zitat
Evtl sollte man einen neuen Type erstellen (LandisGyrE350USB)
Da kannst du auch den VSM102 oder E110-Typ nehmen, die haben alle den selben Init-String.
Aber ich nehm den LGE350USB auch gern noch mit rein.
lg, Stefan
Moin moin,
ich hab da mal ne Frage, vllt könnt ihr mir helfen. Ich hab FHEM auf meinem NAS Server und am Zähler nen Raspberry PI mit IR-Lesekopf von volkszaehler an einem Elster AS1440 Zähler.
Nun hab ich bisher auf dem Raspberry PI die vzlogger Software laufen und hol mir von FHEM aus in 5 Minuten Abständen die Daten über JSON mit dem HTTPMOD Modul.
Nun wollte ich das etwas eleganter mit dem OBIS Modul machen nur wie bekomm ich das hin? Bin irgendwie noch nich ganz dahinter gekommen wie ich ohne die vzlogger middleware auskomme und wie ich den USB IR Lesekopf übers Netzwerk an das OBIS Modul weiterreichen kann. Hier mal noch ein Auszug aus der vzlogger Config.
"protocol": "d0",
"device": "/dev/usb-ir-lesekopf0",
"pullseq": "2F3F210D0A",
"baudrate": 300,
"parity": "7e1",
"baudrate_read": 9600,
"ackseq": "063035300d0a",
"baudrate_change_delay": 500
Hoffe ihr könnt mir helfen bzw. sagen wo ich nachlesen muss um es zum laufen zu bekommen.
Hi Oliver,
der sollte eigentlich mit der "Standard-Aufforderung" zum sprechen gebracht werden.
Probier mal ein
/dev/usb-ir-lesekopf0@300,7,E,1 VSM102
Anm: Der VSM102 (am Ende def defines) nutzt dieselbe Aufforderung wie dein Meter.
Den Geschwindogkeitswechsel hab ich zwar mal eingebaut gehabt, hat aber nicht richtig funktioniert, daher ist das aktuell ausser Funktion gesetzt.
Mir fehlt auch ein Gerät, welches das unterstützt zum testen.
lg, Stefan
Zitat von: Bootscreen am 29 November 2016, 14:54:52
Moin moin,
ich hab da mal ne Frage, vllt könnt ihr mir helfen. Ich hab FHEM auf meinem NAS Server und am Zähler nen Raspberry PI mit IR-Lesekopf von volkszaehler an einem Elster AS1440 Zähler.
Nun hab ich bisher auf dem Raspberry PI die vzlogger Software laufen und hol mir von FHEM aus in 5 Minuten Abständen die Daten über JSON mit dem HTTPMOD Modul.
Nun wollte ich das etwas eleganter mit dem OBIS Modul machen
I see 2 possibilities:
FHEM on NAS
FHEM on RASPI with OBIS module
you connect NAS and RASPI with FHEM2FHEMor
FHEM on NAS with OBIS module
SER2NET on RASPI (10.0.x.y on port 1234 with 300,7,E,1)
The OBIS module connects directly to the ip of the raspi
define PowerMeter OBIS 10.0.x.y:1234immi
Hi Leute,
Ich bin was eHz Auslesen angeht Anfänger.
Udo hat mir freundlicherweise einen IR RS232 Kopf gebaut.
Der Kopf wird später per USB RS232 Prolific Adapter an FHEM angebunden. Ich muss leider ein Parameter von Zählerschrank zu FHEM überbrücken, da ist USB leider nicht für geeignet.
Jetzt zu meiner Frage, es werden beim define befehl Parameter eingetragen, Baudrate, parität usw., werden diese dann auch auf em Adapter gesetzt?
Anderst Ausgedrückt: stellt FHEM die eingegeben Werte im Adapter auch ein?
Danke und Gruß Robert
@Icinger: das ging ja nicht. war ja nen anderer Rechner ;)
@Immi: Thx, the way with ser2net works fine =)
Mir ist aber ein Problem aufgefallen. Bei einer ser2net Verbindung nimmt er als Baudrate 9600 unabhängig was in ser2net eingetragen ist und das führt bei mir zu Problemen. Mein Elster AS1440 muss erst mit 300 angesprochen werden und kann hinter auf 9600 hochgeschraubt werden. Über ser2net muss ich ihn aber wohl komplett mit 300 betreiben. Wenn ich nach dem /?! mit <ACK>050<CR><LF> bekomm ich nur einen kauderwelsch (siehe unten). Lass ich den Part weg funktioniert es.
ZitatInternals:
CFGFN
CHANGED
DEF XXX.XXX.XXX.XXX:1234 VSM102
DeviceName XXX.XXX.XXX.XXX:1234
FD 18
MeterType VSM102
NAME PowerMeter
NEXT 2016-12-05 14:30:00
NR 81752
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-12-05 13:50:11 1.1.0.0.0 3494593
2016-12-05 13:50:12 1.1.0.0.1 0
2016-12-05 13:50:12 1.1.0.0.2 0
2016-12-05 13:50:22 1.1.0.1.2.03 1604010000
2016-12-05 13:50:21 1.1.0.1.2.04 1605010000
2016-12-05 13:50:20 1.1.0.1.2.06 1607010000
2016-12-05 13:50:19 1.1.0.1.2.07 1608010000
2016-12-05 13:50:18 1.1.0.1.2.08 1609010000
2016-12-05 13:50:17 1.1.0.1.2.09 1610010000
2016-12-05 13:50:16 1.1.0.1.2.10 1611010000
2016-12-05 13:50:15 1.1.0.1.2.11 1612010000
2016-12-05 13:52:26 1.1.0.2.0 467A
2016-12-05 13:52:26 1.1.0.2.2 ----H---
2016-12-05 13:50:13 1.1.0.9.1 134956
2016-12-05 13:50:14 1.1.0.9.2 161205
2016-12-05 13:50:22 1.1.1.7.0 0.199
2016-12-05 13:51:17 1.1.1.9.0 43.84
2016-12-05 13:51:21 1.1.2.7.0 0.001
2016-12-05 13:52:15 1.1.2.9.0 40
2016-12-05 13:52:25 1.1.2.9.0.03 0
2016-12-05 13:52:24 1.1.2.9.0.04 0
2016-12-05 13:52:22 1.1.2.9.0.06 0
2016-12-05 13:52:21 1.1.2.9.0.07 202.68
2016-12-05 13:52:20 1.1.2.9.0.08 429.42
2016-12-05 13:52:19 1.1.2.9.0.09 392.72
2016-12-05 13:52:18 1.1.2.9.0.10 69.51
2016-12-05 13:52:17 1.1.2.9.0.11 77.94
2016-12-05 13:50:23 1.1.21.7.0 0.003
2016-12-05 13:51:22 1.1.22.7.0 0
2016-12-05 13:50:24 1.1.41.7.0 0
2016-12-05 13:51:22 1.1.42.7.0 0.817
2016-12-05 13:50:25 1.1.61.7.0 0.936
2016-12-05 13:51:23 1.1.62.7.0 0
2016-12-05 12:10:01 Version ELS5\@V9.34
2016-12-05 12:01:10 state opened
2016-12-05 13:50:35 total_consumption 0
2016-12-05 13:50:45 total_consumption_Ch1 0
2016-12-05 13:50:56 total_consumption_Ch2 0
2016-12-05 13:51:06 total_consumption_Ch5 0
2016-12-05 13:51:16 total_consumption_Ch6 0
2016-12-05 13:51:33 total_feed 0
2016-12-05 13:51:44 total_feed_Ch1 0
2016-12-05 13:51:54 total_feed_Ch2 0
2016-12-05 13:52:04 total_feed_Ch5 0
2016-12-05 13:52:14 total_feed_Ch6 0
Helper:
BUFFER `jdrtbx.~X~p~z~r~v>z~h82"2aBbx~A"~2pb?02~J2 9pb"?02boc2X Q6>f2?F2?9b/`b>Fov"?_V~r?xhhXb:3,?R~aab>x,~b9&0~@.pX~&XR8~a/Tb n4a?&a j2~q/n F2>x~/P"r0~2~b(~0~b"~~}
EoM 0
SPEED 5
TRIGGERTIME 1480944600
Channels:
DEVICES:
/?!
600
050
Attributes:
alignTime 00:00:00
interval 600
room Zähler
Zitat von: no_Legend am 04 Dezember 2016, 21:27:55
Ich muss leider ein Parameter von Zählerschrank zu FHEM überbrücken, da ist USB leider nicht für geeignet.
Ich nehmemal an du meintest "ein paar Meter". ;)
Zitat
Jetzt zu meiner Frage, es werden beim define befehl Parameter eingetragen, Baudrate, parität usw., werden diese dann auch auf em Adapter gesetzt?
Anderst Ausgedrückt: stellt FHEM die eingegeben Werte im Adapter auch ein?
Der USB-RS232-Adapter verhält sich transparent was die Übertragungsparameter angeht. Du musst nur beim
define in FHEM die für deinen Zähler passenden angeben.
Was ein wenig trickreich ist, ist die Spannungsversorgung des Lesekopfes über
DTR. An Pin4 des 9-poligen Steckers benötigst du +5V. Ich weiß nicht was der Profilic dort ausgibt.
http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-rs232-ausgang (http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-rs232-ausgang)
ZitatEs muss DTR per Software auf High gelegt werden. z. B. dadurch, dass man in Hterm den Schalter: DTR aktiviert.
Beim NET-IO muss man von Pin 4 der 9-Poligen-Sub-D-Buchse eine Brücke nach +5V löten.
Gruß Friedrich
Zitatund kann hinter auf 9600 hochgeschraubt werden.
Genau das kann das OBIS-Modul (noch) nicht. Hatte das kurzfristig drinnen, dann aber wieder rausgenommen, weils Probleme gab.
Da ich keinen Zähler habe, der das kann/braucht (meiner sendet gleich von vornherein auf 9600), kann ich das auch nicht lokal testen.
Aber der Winter ist ja noch lang, und Weihnachten kommt auch bald ^^ Vlt. fällt mir bis dahin was ein gg
lg, Stefan
Zitat von: Bootscreen am 05 Dezember 2016, 14:38:07
Mein Elster AS1440 muss erst mit 300 angesprochen werden und kann hinter auf 9600 hochgeschraubt werden. Über ser2net muss ich ihn aber wohl komplett mit 300 betreiben. Wenn ich nach dem /?! mit <ACK>050<CR><LF> bekomm ich nur einen kauderwelsch (siehe unten). Lass ich den Part weg funktioniert es.
I do not understand, why don't you remain at 300.
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
here is written that you can decide the speed
Change the code; have a look at about line 143 of 47_OBIS.pm
immi
Zitat von: Icinger am 05 Dezember 2016, 17:15:40
Genau das kann das OBIS-Modul (noch) nicht. Hatte das kurzfristig drinnen, dann aber wieder rausgenommen, weils Probleme gab.
Da ich keinen Zähler habe, der das kann/braucht (meiner sendet gleich von vornherein auf 9600), kann ich das auch nicht lokal testen.
...
Hallo Icinger,
ich hatte hier schon einmal angefragt (https://forum.fhem.de/index.php/topic,51948.msg468090.html#msg468090) ist aber wahrscheinlich untergegangen. Könntest du mir einmal eine Version mit der Anpassung zukommen lassen. Ich würde es gerne bei meinem TD3511 testen, ich habe es so im Modul nicht hinbekommen. Danke.
Tschüß Jörg.
Zitat von: Omega-5 am 05 Dezember 2016, 17:01:22
Ich nehmemal an du meintest "ein paar Meter". ;)
Genau ein paar Meter, sind so geschätzte 10-15m
Zitat von: Omega-5 am 05 Dezember 2016, 17:01:22
Der USB-RS232-Adapter verhält sich transparent was die Übertragungsparameter angeht. Du musst nur beim define in FHEM die für deinen Zähler passenden angeben.
Heißt transparent nun dass FHEM die wählte Baudrate einstellt oder dass FHEM diese vom Adapter übernimmt?
Zitat von: Omega-5 am 05 Dezember 2016, 17:01:22
Was ein wenig trickreich ist, ist die Spannungsversorgung des Lesekopfes über DTR. An Pin4 des 9-poligen Steckers benötigst du +5V. Ich weiß nicht was der Profilic dort ausgibt.
Dazu habe ich unterschiedliche Aussagen im Netz gefunden.
Ein Beitrag sagt das DTR per Standard aktiviert ist.
Wie ich den DTR pin aber High bekomme, hab ich bisher nicht wirklich gefunden.
Eventuell geht es mit stty und dem befehl -cdtrdsr.
Muss ich einfach mal Ausprobieren.
Ansonsten muss ich halt noch ne Leitung zuästzlich benutzen und 5V vom USB oder von einem Netzteil abzapfen.
Damke und Gruß Robert
Hallo! Ich habe gerade eben erst dieses Modul entdeckt. Ich habe einen ED300L Zähler http://www.emh-metering.de/de/produkte/ed300l/ (http://www.emh-metering.de/de/produkte/ed300l/) und als Adapter einen COM-1 Smart Meter Gateway http://www.mysmartshop.de/co-met-com-1-smart-meter-gateway.html (http://www.mysmartshop.de/co-met-com-1-smart-meter-gateway.html), das mir die SML-Daten per Web-Service im LAN zur Verfügung stellt. Ich hatte lange Zeit eine Kopplung über Volkszähler am laufen, aber beim Umzug auf einen neuen Raspi war mir nun der ganze Overhead zu viel. Ich habe mir ein Shell-Script gebaut, das mir die Daten ausliest und Fehler abfängt, die es manchmal beim Auslesen der Daten gibt. Den Zählerstand und ein paar andere Header-Daten schicke ich dann einmal pro Minute (cron) bzw. einmal am Tag per trigger an ein fhem dummy Device.
Macht es Sinn diese Schnittstelle in Euer OBIS Modul zu integrieren und so das shell-script zu ersetzen?
Hier mein Skript
#!/bin/bash
# Datei strom.sh zum Abfragen des SML-Stromzählers wird einmal pro Minute aufgerufen
# set debugmode to true for simulation
debugmode=false #true
# tbd myTelnetPW nicht im Klartext hier ablegen
myTelnetPW="xxxxx"
# fhem dummy Device über das ein notify per trigger ausgelöst wird
n_dev="strom_event"
# URL des SML-Stromzähleradapters
URL=192.168.2.xxx:5000
# fhemdir is /opt/fhem on RaspberryPi
fhemdir="/opt/fhem"
# Verzeichnis für Hilfsdateien
helpdir="/opt/fhem/scripts"
# Dateiname zur temporären Speicherung eines SML-Datensatzes
SML_FILE=$helpdir/com_sml.txt
# Dateiname zur temporären Speicherung des letzten Zählerstandes
LAST_FILE=$helpdir/letzter_zaehlerstand.txt
READ_TIME=6
# Uhrzeit zum täglichen Auslesen der Kopfzeilen mit MAC-Addresse etc.
CHECKTIME="01:23"
###################################
# Zähler auslesen (Kopfzeilen und SML Datensatz)
/usr/bin/curl $URL --max-time $READ_TIME | tail -n 6 > $SML_FILE
# Zählerstand extrahieren
ZAEHLERSTAND=$(cat $SML_FILE|cut -b316-325)
if [ "$ZAEHLERSTAND" = "" ]; then
echo "leere SML-Datei"
else
# Umwandlung ins Dezimalsystem
ZDEZIMAL=$(echo "ibase=16;obase=A;$ZAEHLERSTAND"|bc)
# Umrechnung in kWh
ZKWH=$(echo "scale=4;$ZDEZIMAL/10000"|bc)
# letzten Zählerstand aus Datei lesen
LAST=$(cat $LAST_FILE)
if [ "$LAST" = "" ]; then
# falls das System neu startet oder aus dem Tritt gekommen ist, hier die Initialisierung
echo "$ZKWH" > $LAST_FILE
fi
# Differenz zum letzten Zählerstand berechnen in Wh
DIFF=$(echo "scale=0;($ZKWH *1000 - $LAST * 1000)/1"|bc)
# prüfen ob die Differenz im erwarteten Rahmen liegt
if [ $DIFF -gt 0 ] && [ $DIFF -lt 1500 ]; then
DIFFOK=true
# aktuellen Zählerstand in Datei speichern
echo "$ZKWH" > $LAST_FILE
else
DIFFOK=false
fi
if [ $debugmode = true ]; then
echo "Der in SML codierte Zählerstand ist $ZAEHLERSTAND."
echo "Der Dezimalwert des codierten Zählerstandes ist $ZDEZIMAL."
echo "Der aktuelle Zählerstand ist $ZKWH kWh."
echo "Der letzte Zählerstand war $LAST kWh, also eine Differenz von $DIFF Wh."
if [ $DIFFOK = true ]; then
echo "Differenz liegt im erwarteten Größenbereich von 0 bis 1500 Wh, das entspricht etwa einer max. Leistung von 90 kW"
else
echo "Differenz liegt nicht im erwarteten Größenbereich von 0 bis 1500 Wh, das entspricht etwa einer max. Leistung von 90 kW"
fi
else
if [ $DIFFOK = true ]; then
perl "$fhemdir"/fhem.pl 7072 $myTelnetPW "trigger $n_dev meter_reading $ZKWH kWh"
fi
fi
# Kopfzeilen einmal täglich auswerten
UHRZEIT=`date +%H:%M`
if [ "$UHRZEIT" = "$CHECKTIME" ]; then
MAC=$(cat $SML_FILE|mawk 'BEGIN { FS = "[=\n\f\r]" } /mac/ { print($2) }')
FW=$(cat $SML_FILE|mawk 'BEGIN { FS = "[=\n\f\r]" } /fw/ { print($2) }')
TIME=$(cat $SML_FILE|mawk 'BEGIN { FS = "[=\n\f\r]" } /time/ { print($2) }')
ZPB=$(cat $SML_FILE|mawk 'BEGIN { FS = "[=\n\f\r]" } /zpb/ { print($2) }')
if [ $debugmode = true ]; then
echo "MAC-Adresse: $MAC."
echo "Firmware-Version: $FW."
echo "Zählpunktbezeichnung (ZPB): $ZPB."
echo "TIME: $TIME."
else
perl "$fhemdir"/fhem.pl 7072 $myTelnetPW "trigger $n_dev MAC_address $MAC"
perl "$fhemdir"/fhem.pl 7072 $myTelnetPW "trigger $n_dev firmware_version $FW"
perl "$fhemdir"/fhem.pl 7072 $myTelnetPW "trigger $n_dev meter_point_designation $ZPB"
fi
fi
fi
Und dann noch die zugehörigen fhem Definitionen
## Stromzählerstände werden über dieses dummy getriggert
define strom_event dummy
attr strom_event comment Dieses Dummy wird einmal pro Minute vom shell script strom.sh getriggert (Stromzählerstand)
## Stromzählerstand der Wohnung
define Stromzaehler.Wohnung dummy
attr Stromzaehler.Wohnung group Energie
attr Stromzaehler.Wohnung room Energie
## übertrage den gemeldeten Stromzählerstand und andere Header-Informationen in das dummy Device
define n_Stromzaehler.Wohnung notify strom_event:.* setreading Stromzaehler.Wohnung $EVENT
## Logfile für den Stromzählerstand
define FileLog_Stromzaehler.Wohnung FileLog %L/stromzaehler-%Y-%m.log Stromzaehler.Wohnung
attr FileLog_Stromzaehler.Wohnung group log_Sensor
attr FileLog_Stromzaehler.Wohnung logtype text
attr FileLog_Stromzaehler.Wohnung room log
## Plot für den Stromzählerstand der Wohnung
define SVG_FileLog_Stromzaehler.Wohnung SVG FileLog_Stromzaehler.Wohnung:SVG_FileLog_Stromzaehler.Wohnung:CURRENT
attr SVG_FileLog_Stromzaehler.Wohnung group Energie
attr SVG_FileLog_Stromzaehler.Wohnung label "Wohnung: Stromverbrauch: aktuell $data{currval1} kWh" :: "Zählerstand / kWh"
attr SVG_FileLog_Stromzaehler.Wohnung room Energie,Plots
## Statistische Auswertung des Stromverbrauchs der Wohnung
define Energie.Wohnung ElectricityCalculator Stromzaehler.Wohnung:meter_reading:.*
attr Energie.Wohnung BasicPricePerAnnum 0
attr Energie.Wohnung Currency €;
attr Energie.Wohnung ElectricityCounterOffset 0
attr Energie.Wohnung ElectricityKwhPerCounts 1
attr Energie.Wohnung ElectricityPricePerKWh 0.2567
attr Energie.Wohnung MonthOfAnnualReading 5
attr Energie.Wohnung MonthlyPayment 0
attr Energie.Wohnung ReadingDestination CalculatorDevice
attr Energie.Wohnung SiPrefixPower W
attr Energie.Wohnung room Energie
## Logfile für die erfasste/berechnete Stromleistung von Wohnung und wichtigen elektrischen Geräten
define FileLog_Strom.Leistung FileLog %L/strom_leistung-%Y-%m.log (FBDECT_fb1_.*|Waschmaschine|Energie.Wohnung):(power|.*PowerCurrent).*
attr FileLog_Strom.Leistung group log_Sensor
attr FileLog_Strom.Leistung logtype text
attr FileLog_Strom.Leistung room log
## Plot für die elektrischen Leistungsdaten wichtiger Geräte und der Wohnung insgesamt
defmod SVG_FileLog_Strom.Leistung_1 SVG FileLog_Strom.Leistung:SVG_FileLog_Strom.Leistung_1:CURRENT
attr SVG_FileLog_Strom.Leistung_1 group Leistung
attr SVG_FileLog_Strom.Leistung_1 label sprintf('Elektrische Leistung: Wohnung min %i W, max %i W, aktuell %i W',$data{min1},$data{max1},$data{currval1}) :: "Leistung / W"
attr SVG_FileLog_Strom.Leistung_1 room Energie,Plots
Ob Dein Wunsch Sinn macht, kann nur der Modulautor beantworten.
Mit dem COM-1-Gateway gehst Du ja einen technisch ganz anderen Weg. Üblicherweise haben die Nutzer des OBIS-Moduls ein Gateway, welches, in der Regel, IR-Signale in serieller Datenkommunikation empfängt und an einer USB-Schnittstelle zur "Verfügung" stellt. In Deinem Fall passiert die Wandlung von OBIS-Daten bereits im COM-1-Gateway. Ich sehe daher folgende Möglichkeiten für Dich.
1.) Du verzichtest auf das COM-1-Gatway und legst Dir neue Hardware zum Auslesen des Zählers zu.(ich weiß, eine neue Investition tätigt man ungern)
2.) Du öffnest das COM-1-Gateway und versuchst die seriellen Daten mit einem RS232/USB Wandler abzugreifen
3.) Du leitest die Daten über ein Skript auf eine serielle Schnittstelle um. Das ist aber nur so ein Gedanke und ich nicht kompetent, ob sich das überhaupt realisieren lässt.
Wenn ich das Skript richtig überflogen hab, bekommst Du ja nur den Zählerstand aus dem Gateway. Für OBIS-Modul-Nutzer ist das arg wenig, denn der Zähler liefert viel, viel mehr. Ist das eine Einschränkung des Gateways oder Deiner Installation/Skripte ? Stell doch mal den Dateiinhalt hier ein, dass man eine Vorstellung von Aufbau und Inhalt der Datei hat.
Grüße Markus
Zitat von: hartenthaler am 07 Dezember 2016, 03:29:31
Macht es Sinn diese Schnittstelle in Euer OBIS Modul zu integrieren und so das shell-script zu ersetzen?
Another option.
If you just need Zählerstand, HTTPMOD should be fine.
http://www.fhemwiki.de/wiki/HTTPMOD
if you want more, Stefan(aka Icinger) will need to have a look to the complete file which you get with /usr/bin/curl
immi
Hmm,
ZitatIch habe gerade eben erst dieses Modul entdeckt. Ich habe einen ED300L Zähler http://www.emh-metering.de/de/produkte/ed300l/ und als Adapter einen COM-1 Smart Meter Gateway http://www.mysmartshop.de/co-met-com-1-smart-meter-gateway.html, das mir die SML-Daten per Web-Service im LAN zur Verfügung stellt.
Warum lässt du dieses Com1-Smartmeter-Gateway nicht weg und hängst den Lesekopf direkt an einen UART?
Dann könntest du die Daten direkt mit dem OBIS-Modul auslesen.
lg, Stefan
Hallo,
vielleicht könnte man die Art der Anbindung auch wie beim 19_VBUSIF.pm lösen. Dort kann entweder über COM oder TCPIP gelesen werden.
Ist die Frage wie stellt das COM-1 Smart Meter Gateway die Daten bereit.
...
# if(@a != 3) {
# return "wrong syntax: define <name> VBUSIF [<hostname:7053> or <dev>]";
# }
my $name = $a[0];
my $dev = $a[2];
$hash->{Clients} = ":VBUSDEV:";
my %matchList = ( "1:VBUSDEV" => ".*" );
$hash->{MatchList} = \%matchList;
Log3 $hash, 4,"$name: VBUSIF_Define: $hash->{MatchList} ";
DevIo_CloseDev($hash);
$hash->{DeviceName} = $dev;
my @dev_name = split('@', $dev);
if ( -c ${dev_name}[0]) {
$hash->{DeviceType} = "Serial";
} else {
$hash->{DeviceType} = "Net";
}
my $ret = DevIo_OpenDev($hash, 0, "VBUSIF_DoInit");
return $ret;
}
###############################
sub VBUSIF_DoInit($)
{
my $hash = shift;
if ($hash->{DeviceType} eq "Net" ) {
my $name = $hash->{NAME};
delete $hash->{HANDLE}; # else reregister fails / RELEASE is deadly
my $conn = $hash->{TCPDev};
$conn->autoflush(1);
$conn->getline();
$conn->write("PASS vbus\n");
$conn->getline();
$conn->write("DATA\n");
$conn->getline();
}
Log3 $hash, 4,"VBUSIF_DoInit ";
return undef;
...
}
PS: oder man leitet den TCPIP-Port Datenstrom auf COM um. Der Port /dev/ttyS0 darf aber nicht von Hardware belegt sein.
socat pty,link=/dev/ttyS0,nonblock,b115200,raw,echo=1 TCP4:IP-Gatewaye:Port &
pejonp
Hallo Leute,
ich konnte jetzt meinen Lesekopf in betrieb nehmen.
Laut Linux console und cat kommen werte an.
0000000 1b 1b 1b 1b 01 01 01 01 76 05 00 25 52 53 62 00
0000020 62 00 72 63 01 01 76 01 07 ff ff ff ff ff ff 05
0000040 00 0c 70 c7 0b 0a 01 45 4d 48 00 00 5a 0a 58 72
0000060 62 01 64 0c 7d b9 62 01 63 5b 91 00 76 05 00 25
0000100 52 54 62 00 62 00 72 63 07 01 77 07 ff ff ff ff
0000120 ff ff 0b 0a 01 45 4d 48 00 00 5a 0a 58 07 01 00
0000140 62 0a ff ff 72 62 01 64 0c 7d b9 79 77 07 01 00
0000160 60 32 01 01 01 01 01 01 04 45 4d 48 01 77 07 01
0000200 00 60 01 00 ff 01 01 01 01 0b 0a 01 45 4d 48 00
0000220 00 5a 0a 58 01 77 07 01 00 01 08 00 ff 64 1c 01
0000240 04 72 62 01 64 0c 7d b9 62 1e 52 ff 64 21 c9 17
0000260 01 77 07 01 00 01 08 01 ff 01 72 62 01 64 0c 7d
0000300 b9 62 1e 52 ff 62 00 01 77 07 01 00 01 08 02 ff
Definiert wurde das Device wie folgt:
define Stromzaehler OBIS /dev/ttyUSB1@9600,8,E,1 SML
attr Stromzaehler channels 1
attr Stromzaehler room 9.04_Energiewerte
Es scheint als wurde am Anfang die Werte irgendwann mal akzeptiert.
Allerdings werden den die readings nicht mehr aktualisiert. Als Zeitstempel steht immer 2016-12-07 19:43:28
Es ändert sich auch nichts wenn ich pollmode oder Intervall aktiviere.
Zum Intervall ist auch nichts in der Commandref zu finden welche Einheit hier genommen wird Sekunden, Minuten, Stunden.
Als Zähler ist EMH eHZ-NW8E2A6L0HQ20
Hab ich was falsch gemacht oder einen Denkfehler?
Danke und Gruß Robert
Laut Datenblatt:
ZitatDer Zähler sendet lastabhängig alle paar Sekunden unaufgefordert ein SML-Datenpaket.
Sollte eigentlich passen, das define schaut auch gut aus.
Aber das Channels-Attribut passt nicht.
Lösch das mal raus, dann sollten alle eingehenden Werte automatisch angelegt werden.
Das Channels-Attribut sollte folgendermaßen aussehen:
attr Stromzaehler channels {"2.6.0*20"=>"Tsetreading","2.6.0"=>"Testreading"}@penjop:
Zitatoder man leitet den TCPIP-Port Datenstrom auf COM um. Der Port /dev/ttyS0 darf aber nicht von Hardware belegt sein.
Kommt drauf an, wie die Daten aussehen, die vom Gateway kommen.
lg, Stefan
@Icinger
Einen Fehler auf meiner Seite hatte ich gefunden.
Ich musste eine UDEV regle anlegen, da der USB Port immer wieder gewechselt hat, bei einem Neustart.
Beim Define wird nun einmal die Daten ausgelesen.
Danach nicht mehr.
Auch deine Chanel angebe hab ich eingefugt, hat aber bisher nichts bewirkt.
Ich muss um den Lesekopf mit Spannung zuversorgen den DTR pin am Rs232 USB Adapter dauerhaft auf High setzten.
FHEM setzt doch beim Define die Adapter Einstellungen oder?
Gruß Robert
Hi Robert,
Was sagt denn ein Verbose 5?
Und ein List Stromzaehler?
Meine Channel-Angabe war eigentlich nur als Beispiel gedacht.
Die Adapter-Einstellungen werden durch das FHEM-Interne DevIO-Modul erledigt.
Dort wird eigentlich auf DTR etc keine Rücksicht genommen.
Müsst ich mal schaun, ob ich das implementieren kann.
lg, Stefan
@Icinger
Hi Stefan,
Das mit den Chanel's habe ich so nicht verstanden gehabt. LOL
Bin auch noch neu im Thema.
Wie schnell/oft sollten denn die Daten eigentlich reinflattern?
Das mit verbose 5 kann ich erst morgen machen.
Wegen den Chanel's, gibt es dazu eine Erklärung?
Gruß Robert
Hallo Robert,
hmm, hab grad mit Schrecken festgestellt, dass im Commandref noch ne Uralt-Erklärung zu den Channels ist :(
Naja, im prinzip ist das nur ein Perl-Array mit RegExes, die auf ein reinkommendes Reading matchen müssen/sollen.
Obis-Kennzahlen sind normalerweise in folgendem Format: w.x.y*z.
Am sinnvollsten ist es, das Channel erstmal wegzulassen, dann schaun, welche Readings angelegt werden und dann das Channel dementsprechend aufzubauen.
Wie oft die Daten kommen? Lt. offiziellem Datenblatt "alle paar Sekunden". Genauer kann ichs dir auch nicht sagen ;)
Schönen Abend und gute Nacht,
Stefan
Zitat von: pejonp am 07 Dezember 2016, 17:23:27
Ist die Frage wie stellt das COM-1 Smart Meter Gateway die Daten bereit.
Ich hole mir nur den Zählerstand raus, aber das COM-1 liefert etwa alle 1 bis 2 Sekunden ein Paket ab (MAC-Adresse habe ich ausge-x-t):
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881492
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C3A620062007263010176010107000E0390CEBE0B06454D4801096D8FCDEE01016328DC007607000E0C4D6C3B620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E07777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE630177070100010801FF0101621E52FF560006AAEE630177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF550000198A0177078181C78205FF01726201650390F3E0010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D010101636E18007607000E0C4D6C3E62006200726302017101634B1F000000001B1B1B1B1A0379B1)
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881493
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C40620062007263010176010107000E0390CEC00B06454D4801096D8FCDEE01016372A3007607000E0C4D6C41620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E17777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE660177070100010801FF0101621E52FF560006AAEE660177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000019AE0177078181C78205FF01726201650390F3E2010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D0101016342CF007607000E0C4D6C4462006200726302017101630956000000001B1B1B1B1A03277A)
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881495
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C46620062007263010176010107000E0390CEC20B06454D4801096D8FCDEE010163FB65007607000E0C4D6C47620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E37777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE690177070100010801FF0101621E52FF560006AAEE690177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000019940177078181C78205FF01726201650390F3E3010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D010101637304007607000E0C4D6C4A6200620072630201710163D41F000000001B1B1B1B1A038273)
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881497
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C4C620062007263010176010107000E0390CEC40B06454D4801096D8FCDEE0101637126007607000E0C4D6C4D620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E57777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE6C0177070100010801FF0101621E52FF560006AAEE6C0177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000019A70177078181C78205FF01726201650390F3E5010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D010101632D36007607000E0C4D6C5062006200726302017101631979000000001B1B1B1B1A03E9BB)
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881498
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C52620062007263010176010107000E0390CEC60B06454D4801096D8FCDEE0101638C0D007607000E0C4D6C53620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E67777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE6F0177070100010801FF0101621E52FF560006AAEE6F0177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000019A60177078181C78205FF01726201650390F3E6010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D010101635FC8007607000E0C4D6C5662006200726302017101636E8C000000001B1B1B1B1A03CE41)
Eigentlich will ich das COM 1 nicht gegen etwas anderes eintauschen, denn es tut seit Jahr und Tag völlig klaglos seinen Dienst und zickt nicht rum. Schön wäre nur, wenn man noch mehr Daten dekodieren könnte oder wenn ich den Zwischenschritt über cronjob/Script weglassen könnte und direkt ein fhem-Modul die Daten auslesen würde, denn dann müsste man auch nicht ständig ein File schreiben (habe etwas Angst um meine SD-Karte). Könnt ihr in dem Datenpaket noch etwas interessantes entdecken? Der größte Teil ist ja statisch und nur im hinteren Teil tut sich etwas. Ich erinnere mich, dass ich irgendwo die Information gefunden hatte welcher Tarif gerade gilt, aber da ich nur einen Tarif habe, war mir das nicht wichtig).
Zitat von: Icinger am 07 Dezember 2016, 13:06:45
Warum lässt du dieses Com1-Smartmeter-Gateway nicht weg und hängst den Lesekopf direkt an einen UART?
Dann könntest du die Daten direkt mit dem OBIS-Modul auslesen.
Beim COM 1 ist der IR-Lesekopf mit einem festverdrahteten Kabel mit dem Wandlerkästchen verbunden. Da komme ich nicht dazwischen.
Zitat von: pejonp am 07 Dezember 2016, 17:23:27
PS: oder man leitet den TCPIP-Port Datenstrom auf COM um. Der Port /dev/ttyS0 darf aber nicht von Hardware belegt sein.
socat pty,link=/dev/ttyS0,nonblock,b115200,raw,echo=1 TCP4:IP-Gatewaye:Port &
Das kann ich natürlich machen. Kann denn dann das OBIS-Modul auf diese Art direkt von COM lesen und dekodieren?
Hallo hartenthaler,
Versuche doch einmal die Daten mit socat umzuleiten. Ein Problem wird vielleicht das passwort sein.obwohl das passwort liegt ja auf dem telnet-zugang. Wenn die Daten im Standarte liegen einfach mit dem Modul einlesen.
Pejonp
Zitat von: Icinger am 07 Dezember 2016, 22:37:02
Hallo Robert,
hmm, hab grad mit Schrecken festgestellt, dass im Commandref noch ne Uralt-Erklärung zu den Channels ist :(
Guten Morgen erst mal.
Wenn du hier am korrigieren bist, schau dir mal bitte das Define an. Da stehen zwei @@ drin im Commandref
Zitat von: Icinger am 07 Dezember 2016, 22:37:02
Naja, im prinzip ist das nur ein Perl-Array mit RegExes, die auf ein reinkommendes Reading matchen müssen/sollen.
Obis-Kennzahlen sind normalerweise in folgendem Format: w.x.y*z.
Am sinnvollsten ist es, das Channel erstmal wegzulassen, dann schaun, welche Readings angelegt werden und dann das Channel dementsprechend aufzubauen.
Readings werde nicht viele erzeugt. 7 Stück sind es momentan.
Zitat von: Icinger am 07 Dezember 2016, 22:37:02
Wie oft die Daten kommen? Lt. offiziellem Datenblatt "alle paar Sekunden". Genauer kann ichs dir auch nicht sagen ;)
Es scheint als ob die Daten hin und wieder aktualisiert werden, alle paar Minuten.
Von allen Paar Sekunden kann hier aber nicht die rede sein.
Um dass genau zu sehen, sollte ich vll noch ein Log für den Stromzähler einrichten.
mit Verbose 5 meinst du doch direkt auf dem Stromzähler Device?
Zitat von: hartenthaler am 08 Dezember 2016, 00:08:27
Das kann ich natürlich machen. Kann denn dann das OBIS-Modul auf diese Art direkt von COM lesen und dekodieren?
Solche Mehrfachposts hintereinader machen die Threads irgendwann unübersichtlich.
Es gibt auch eine Edit funktion für die Beiträge.
Damit kannst du den Inhalt immer wieder ändern.
Dazu kannst du auch wenn du am Tippen der Nachricht bist, all Zität die du benötigst per Zitat einfügen hinzufügen.
Gruß Robert
Guten Morgen,
mac=00:08:xx:xx:xx:6C
boot=1
fw=02.00
time=1262881492
zpb=DE0000000000000000000000000000002
SML(1B1B1B1B010101017607000E0C4D6C3A620062007263010176010107000E0390CEBE0B06454D4801096D8FCDEE01016328DC007607000E0C4D6C3B620062007263070177010B06454D4801096D8FCDEE070100620AFFFF726201650390F3E07777078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D8FCDEE0177070100010800FF6400018201621E52FF560006AAEE630177070100010801FF0101621E52FF560006AAEE630177070100010802FF0101621E52FF5600000000000177070100100700FF0101621B52FF550000198A0177078181C78205FF01726201650390F3E0010183025E55C42C87907119C50ADCE734FD37D8CC42CD856F9E9888D3FD0E3515CEB6269B525CC71A44B9241723B8F83512400D010101636E18007607000E0C4D6C3E62006200726302017101634B1F000000001B1B1B1B1A0379B1)
Das sieht schon mal gut aus. Ich hab die Daten jetzt zwar noch nicht zerlegt, aber mit dem SMl-String lässt sich schon was anfangen.
In Kombination von
socat pty,link=/dev/ttyS0,nonblock,b115200,raw,echo=1 TCP4:IP-Gatewaye:Port &und einem neuen MeterType, bei dem ich einen Filter setze um das "SML()" zu entfernen, lässt sich das ohne Probleme so realisieren.
Zitatmit Verbose 5 meinst du doch direkt auf dem Stromzähler Device?
genau das meinte ich :)
Weiss ned, ob ich heute zu was komme (trotz Feiertag), aber mal schauen :D
lg, Stefan
@Icinger
Laut Device log kommen die Daten in unregelmäßigen Abständen:
18:38:51
18:41:37
18:46:57
18:49:41
18:52:27
18:53:49
19:06:30
Und hier mal ein paar Minuten FHEM LOG mit verbose 5:
[code]2016.12.08 19:08:08 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:08 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:08 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:08 5: OBIS: Telegram=1B1B1B1B010101017605002933596200620072630101760107FFFFFFFFFFFF05000DBBC90B0A01454D4800005A0A58726201640DC8BB62016362E40076050029335A62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8BB7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8BB621E52FF6424CBA60177070100010801FF01726201640DC8BB621E52FF62000177070100010802FF01726201640DC8BB621E52FF6424CBA60177070100020800FF01726201640DC8BB621E52FF6339CA0177070100020801FF01726201640DC8BB621E52FF62000177070100020802FF01726201640DC8BB621E52FF6339CA0177070100100700FF0101621B520053045B0101016382CA0076050029335B6200620072630201710163A1C2001B1B1B1B1A007751
2016.12.08 19:08:08 5: OBIS: Full message-> 1B1B1B1B010101017605002933596200620072630101760107FFFFFFFFFFFF05000DBBC90B0A01454D4800005A0A58726201640DC8BB62016362E40076050029335A62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8BB7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8BB621E52FF6424CBA60177070100010801FF01726201640DC8BB621E52FF62000177070100010802FF01726201640DC8BB621E52FF6424CBA60177070100020800FF01726201640DC8BB621E52FF6339CA0177070100020801FF01726201640DC8BB621E52FF62000177070100020802FF01726201640DC8BB621E52FF6339CA0177070100100700FF0101621B520053045B0101016382CA0076050029335B6200620072630201710163A1C2001B1B1B1B1A007751
2016.12.08 19:08:08 4: parsing....
2016.12.08 19:08:08 4: parsing....
2016.12.08 19:08:08 4: parsing....
2016.12.08 19:08:08 4: parsing....
2016.12.08 19:08:08 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:08:08 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:07 5: OBIS: Telegram=1B1B1B1B010101017605002933566200620072630101760107FFFFFFFFFFFF05000DBBC80B0A01454D4800005A0A58726201640DC8BA6201638CE80076050029335762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8BA7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8BA621E52FF6424CBA30177070100010801FF01726201640DC8BA621E52FF62000177070100010802FF01726201640DC8BA621E52FF6424CBA30177070100020800FF01726201640DC8BA621E52FF6339CA0177070100020801FF01726201640DC8BA621E52FF62000177070100020802FF01726201640DC8BA621E52FF6339CA0177070100100700FF0101621B520053045C0101016385D4007605002933586200620072630201710163123C001B1B1B1B1A00A1BB
2016.12.08 19:08:07 5: OBIS: Full message-> 1B1B1B1B010101017605002933566200620072630101760107FFFFFFFFFFFF05000DBBC80B0A01454D4800005A0A58726201640DC8BA6201638CE80076050029335762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8BA7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8BA621E52FF6424CBA30177070100010801FF01726201640DC8BA621E52FF62000177070100010802FF01726201640DC8BA621E52FF6424CBA30177070100020800FF01726201640DC8BA621E52FF6339CA0177070100020801FF01726201640DC8BA621E52FF62000177070100020802FF01726201640DC8BA621E52FF6339CA0177070100100700FF0101621B520053045C0101016385D4007605002933586200620072630201710163123C001B1B1B1B1A00A1BB
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 4: parsing....
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:07 5: OBIS: Telegram=1B1B1B1B010101017605002933536200620072630101760107FFFFFFFFFFFF05000DBBC70B0A01454D4800005A0A58726201640DC8B962016358E80076050029335462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B97977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B9621E52FF6424CBA00177070100010801FF01726201640DC8B9621E52FF62000177070100010802FF01726201640DC8B9621E52FF6424CBA00177070100020800FF01726201640DC8B9621E52FF6339CA0177070100020801FF01726201640DC8B9621E52FF62000177070100020802FF01726201640DC8B9621E52FF6339CA0177070100100700FF0101621B520053045E01010163AD200076050029335562006200726302017101637C8B001B1B1B1B1A00D754
2016.12.08 19:08:07 5: OBIS: Full message-> 1B1B1B1B010101017605002933536200620072630101760107FFFFFFFFFFFF05000DBBC70B0A01454D4800005A0A58726201640DC8B962016358E80076050029335462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B97977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B9621E52FF6424CBA00177070100010801FF01726201640DC8B9621E52FF62000177070100010802FF01726201640DC8B9621E52FF6424CBA00177070100020800FF01726201640DC8B9621E52FF6339CA0177070100020801FF01726201640DC8B9621E52FF62000177070100020802FF01726201640DC8B9621E52FF6339CA0177070100100700FF0101621B520053045E01010163AD200076050029335562006200726302017101637C8B001B1B1B1B1A00D754
2016.12.08 19:08:06 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:05 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:05 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:05 5: OBIS: Telegram=1B1B1B1B010101017605002933506200620072630101760107FFFFFFFFFFFF05000DBBC60B0A01454D4800005A0A58726201640DC8B8620163A4350076050029335162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B87977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B8621E52FF6424CB9D0177070100010801FF01726201640DC8B8621E52FF62000177070100010802FF01726201640DC8B8621E52FF6424CB9D0177070100020800FF01726201640DC8B8621E52FF6339CA0177070100020801FF01726201640DC8B8621E52FF62000177070100020802FF01726201640DC8B8621E52FF6339CA0177070100100700FF0101621B520053046101010163D64E0076050029335262006200726302017101639A2B001B1B1B1B1A000C9D
2016.12.08 19:08:05 5: OBIS: Full message-> 1B1B1B1B010101017605002933506200620072630101760107FFFFFFFFFFFF05000DBBC60B0A01454D4800005A0A58726201640DC8B8620163A4350076050029335162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B87977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B8621E52FF6424CB9D0177070100010801FF01726201640DC8B8621E52FF62000177070100010802FF01726201640DC8B8621E52FF6424CB9D0177070100020800FF01726201640DC8B8621E52FF6339CA0177070100020801FF01726201640DC8B8621E52FF62000177070100020802FF01726201640DC8B8621E52FF6339CA0177070100100700FF0101621B520053046101010163D64E0076050029335262006200726302017101639A2B001B1B1B1B1A000C9D
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:05 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:04 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:04 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:04 5: OBIS: Telegram=1B1B1B1B0101010176050029334D6200620072630101760107FFFFFFFFFFFF05000DBBC50B0A01454D4800005A0A58726201640DC8B762016327540076050029334E62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B77977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B7621E52FF6424CB9A0177070100010801FF01726201640DC8B7621E52FF62000177070100010802FF01726201640DC8B7621E52FF6424CB9A0177070100020800FF01726201640DC8B7621E52FF6339CA0177070100020801FF01726201640DC8B7621E52FF62000177070100020802FF01726201640DC8B7621E52FF6339CA0177070100100700FF0101621B520053045D010101639ABB0076050029334F6200620072630201710163B1ED001B1B1B1B1A003844
2016.12.08 19:08:04 5: OBIS: Full message-> 1B1B1B1B0101010176050029334D6200620072630101760107FFFFFFFFFFFF05000DBBC50B0A01454D4800005A0A58726201640DC8B762016327540076050029334E62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B77977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B7621E52FF6424CB9A0177070100010801FF01726201640DC8B7621E52FF62000177070100010802FF01726201640DC8B7621E52FF6424CB9A0177070100020800FF01726201640DC8B7621E52FF6339CA0177070100020801FF01726201640DC8B7621E52FF62000177070100020802FF01726201640DC8B7621E52FF6339CA0177070100100700FF0101621B520053045D010101639ABB0076050029334F6200620072630201710163B1ED001B1B1B1B1A003844
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:04 4: parsing....
2016.12.08 19:08:03 4: parsing....
2016.12.08 19:08:03 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:03 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:03 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:03 5: OBIS: Telegram=1B1B1B1B0101010176050029334A6200620072630101760107FFFFFFFFFFFF05000DBBC40B0A01454D4800005A0A58726201640DC8B6620163DA3E0076050029334B62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B67977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B6621E52FF6424CB970177070100010801FF01726201640DC8B6621E52FF62000177070100010802FF01726201640DC8B6621E52FF6424CB970177070100020800FF01726201640DC8B6621E52FF6339CA0177070100020801FF01726201640DC8B6621E52FF62000177070100020802FF01726201640DC8B6621E52FF6339CA0177070100100700FF0101621B520053045C0101016340570076050029334C62006200726302017101630213001B1B1B1B1A00FA02
2016.12.08 19:08:03 5: OBIS: Full message-> 1B1B1B1B0101010176050029334A6200620072630101760107FFFFFFFFFFFF05000DBBC40B0A01454D4800005A0A58726201640DC8B6620163DA3E0076050029334B62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B67977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B6621E52FF6424CB970177070100010801FF01726201640DC8B6621E52FF62000177070100010802FF01726201640DC8B6621E52FF6424CB970177070100020800FF01726201640DC8B6621E52FF6339CA0177070100020801FF01726201640DC8B6621E52FF62000177070100020802FF01726201640DC8B6621E52FF6339CA0177070100100700FF0101621B520053045C0101016340570076050029334C62006200726302017101630213001B1B1B1B1A00FA02
2016.12.08 19:08:03 4: parsing....
2016.12.08 19:08:03 4: parsing....
2016.12.08 19:08:03 4: parsing....
2016.12.08 19:08:02 4: parsing....
2016.12.08 19:08:02 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:02 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:02 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:02 5: OBIS: Telegram=1B1B1B1B010101017605002933446200620072630101760107FFFFFFFFFFFF05000DBBC20B0A01454D4800005A0A58726201640DC8B462016390360076050029334562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B47977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B4621E52FF6424CB910177070100010801FF01726201640DC8B4621E52FF62000177070100010802FF01726201640DC8B4621E52FF6424CB910177070100020800FF01726201640DC8B4621E52FF6339CA0177070100020801FF01726201640DC8B4621E52FF62000177070100020802FF01726201640DC8B4621E52FF6339CA0177070100100700FF0101621B520053045E010101634EEA0076050029334662006200726302017101638A04001B1B1B1B1A00770B
2016.12.08 19:08:02 5: OBIS: Full message-> 1B1B1B1B010101017605002933446200620072630101760107FFFFFFFFFFFF05000DBBC20B0A01454D4800005A0A58726201640DC8B462016390360076050029334562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B47977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B4621E52FF6424CB910177070100010801FF01726201640DC8B4621E52FF62000177070100010802FF01726201640DC8B4621E52FF6424CB910177070100020800FF01726201640DC8B4621E52FF6339CA0177070100020801FF01726201640DC8B4621E52FF62000177070100020802FF01726201640DC8B4621E52FF6339CA0177070100100700FF0101621B520053045E010101634EEA0076050029334662006200726302017101638A04001B1B1B1B1A00770B
2016.12.08 19:08:02 4: parsing....
2016.12.08 19:08:01 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:08:01 4: parsing....
2016.12.08 19:08:01 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:08:01 4: parsing....
2016.12.08 19:08:01 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:01 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:01 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:08:01 5: OBIS: Telegram=1B1B1B1B0101010176050029333E6200620072630101760107FFFFFFFFFFFF05000DBBC00B0A01454D4800005A0A58726201640DC8B2620163DA430076050029333F62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B27977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B2621E52FF6424CB8A0177070100010801FF01726201640DC8B2621E52FF62000177070100010802FF01726201640DC8B2621E52FF6424CB8A0177070100020800FF01726201640DC8B2621E52FF6339CA0177070100020801FF01726201640DC8B2621E52FF62000177070100020802FF01726201640DC8B2621E52FF6339CA0177070100100700FF0101621B520053045E0101016361B9007605002933406200620072630201710163FDF1001B1B1B1B1A00BA5A
2016.12.08 19:08:01 5: OBIS: Full message-> 1B1B1B1B0101010176050029333E6200620072630101760107FFFFFFFFFFFF05000DBBC00B0A01454D4800005A0A58726201640DC8B2620163DA430076050029333F62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B27977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B2621E52FF6424CB8A0177070100010801FF01726201640DC8B2621E52FF62000177070100010802FF01726201640DC8B2621E52FF6424CB8A0177070100020800FF01726201640DC8B2621E52FF6339CA0177070100020801FF01726201640DC8B2621E52FF62000177070100020802FF01726201640DC8B2621E52FF6339CA0177070100100700FF0101621B520053045E0101016361B9007605002933406200620072630201710163FDF1001B1B1B1B1A00BA5A
2016.12.08 19:08:00 4: parsing....
2016.12.08 19:07:58 4: parsing....
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:58 5: OBIS: Telegram=1B1B1B1B0101010176050029333B6200620072630101760107FFFFFFFFFFFF05000DBBBF0B0A01454D4800005A0A58726201640DC8B1620163C6430076050029333C62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B17977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B1621E52FF6424CB870177070100010801FF01726201640DC8B1621E52FF62000177070100010802FF01726201640DC8B1621E52FF6424CB870177070100020800FF01726201640DC8B1621E52FF6339CA0177070100020801FF01726201640DC8B1621E52FF62000177070100020802FF01726201640DC8B1621E52FF6339CA0177070100100700FF0101621B5200530459010101631E620076050029333D62006200726302017101635918001B1B1B1B1A00940A
2016.12.08 19:07:58 5: OBIS: Full message-> 1B1B1B1B0101010176050029333B6200620072630101760107FFFFFFFFFFFF05000DBBBF0B0A01454D4800005A0A58726201640DC8B1620163C6430076050029333C62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B17977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B1621E52FF6424CB870177070100010801FF01726201640DC8B1621E52FF62000177070100010802FF01726201640DC8B1621E52FF6424CB870177070100020800FF01726201640DC8B1621E52FF6339CA0177070100020801FF01726201640DC8B1621E52FF62000177070100020802FF01726201640DC8B1621E52FF6339CA0177070100100700FF0101621B5200530459010101631E620076050029333D62006200726302017101635918001B1B1B1B1A00940A
2016.12.08 19:07:58 4: parsing....
2016.12.08 19:07:58 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:58 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:58 4: parsing....
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:58 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:58 5: OBIS: Telegram=1B1B1B1B010101017605002933386200620072630101760107FFFFFFFFFFFF05000DBBBE0B0A01454D4800005A0A58726201640DC8B06201633A9E0076050029333962006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B07977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B0621E52FF6424CB840177070100010801FF01726201640DC8B0621E52FF62000177070100010802FF01726201640DC8B0621E52FF6424CB840177070100020800FF01726201640DC8B0621E52FF6339CA0177070100020801FF01726201640DC8B0621E52FF62000177070100020802FF01726201640DC8B0621E52FF6339CA0177070100100700FF0101621B5200530457010101633D7D0076050029333A6200620072630201710163BFB8001B1B1B1B1A007429
2016.12.08 19:07:58 5: OBIS: Full message-> 1B1B1B1B010101017605002933386200620072630101760107FFFFFFFFFFFF05000DBBBE0B0A01454D4800005A0A58726201640DC8B06201633A9E0076050029333962006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8B07977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8B0621E52FF6424CB840177070100010801FF01726201640DC8B0621E52FF62000177070100010802FF01726201640DC8B0621E52FF6424CB840177070100020800FF01726201640DC8B0621E52FF6339CA0177070100020801FF01726201640DC8B0621E52FF62000177070100020802FF01726201640DC8B0621E52FF6339CA0177070100100700FF0101621B5200530457010101633D7D0076050029333A6200620072630201710163BFB8001B1B1B1B1A007429
2016.12.08 19:07:57 4: parsing....
2016.12.08 19:07:57 4: parsing....
2016.12.08 19:07:57 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:57 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:57 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:57 5: OBIS: Telegram=1B1B1B1B010101017605002933326200620072630101760107FFFFFFFFFFFF05000DBBBC0B0A01454D4800005A0A58726201640DC8AE620163F7DC0076050029333362006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AE7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AE621E52FF6424CB7E0177070100010801FF01726201640DC8AE621E52FF62000177070100010802FF01726201640DC8AE621E52FF6424CB7E0177070100020800FF01726201640DC8AE621E52FF6339CA0177070100020801FF01726201640DC8AE621E52FF62000177070100020802FF01726201640DC8AE621E52FF6339CA0177070100100700FF0101621B520053044E01010163B4C500760500293334620062007263020171016362F1001B1B1B1B1A00E9E4
2016.12.08 19:07:57 5: OBIS: Full message-> 1B1B1B1B010101017605002933326200620072630101760107FFFFFFFFFFFF05000DBBBC0B0A01454D4800005A0A58726201640DC8AE620163F7DC0076050029333362006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AE7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AE621E52FF6424CB7E0177070100010801FF01726201640DC8AE621E52FF62000177070100010802FF01726201640DC8AE621E52FF6424CB7E0177070100020800FF01726201640DC8AE621E52FF6339CA0177070100020801FF01726201640DC8AE621E52FF62000177070100020802FF01726201640DC8AE621E52FF6339CA0177070100100700FF0101621B520053044E01010163B4C500760500293334620062007263020171016362F1001B1B1B1B1A00E9E4
2016.12.08 19:07:57 4: parsing....
2016.12.08 19:07:56 4: parsing....
2016.12.08 19:07:55 4: parsing....
2016.12.08 19:07:55 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:55 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:55 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:55 5: OBIS: Telegram=1B1B1B1B0101010176050029332C6200620072630101760107FFFFFFFFFFFF05000DBBBA0B0A01454D4800005A0A58726201640DC8AC6201639B180076050029332D62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AC7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AC621E52FF6424CB780177070100010801FF01726201640DC8AC621E52FF62000177070100010802FF01726201640DC8AC621E52FF6424CB780177070100020800FF01726201640DC8AC621E52FF6339CA0177070100020801FF01726201640DC8AC621E52FF62000177070100020802FF01726201640DC8AC621E52FF6339CA0177070100100700FF0101621B520053046401010163AEB00076050029332E6200620072630201710163AF97001B1B1B1B1A009519
2016.12.08 19:07:55 5: OBIS: Full message-> 1B1B1B1B0101010176050029332C6200620072630101760107FFFFFFFFFFFF05000DBBBA0B0A01454D4800005A0A58726201640DC8AC6201639B180076050029332D62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AC7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AC621E52FF6424CB780177070100010801FF01726201640DC8AC621E52FF62000177070100010802FF01726201640DC8AC621E52FF6424CB780177070100020800FF01726201640DC8AC621E52FF6339CA0177070100020801FF01726201640DC8AC621E52FF62000177070100020802FF01726201640DC8AC621E52FF6339CA0177070100100700FF0101621B520053046401010163AEB00076050029332E6200620072630201710163AF97001B1B1B1B1A009519
2016.12.08 19:07:54 4: parsing....
2016.12.08 19:07:53 4: parsing....
2016.12.08 19:07:53 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:53 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:53 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:53 5: OBIS: Telegram=1B1B1B1B010101017605002933296200620072630101760107FFFFFFFFFFFF05000DBBB90B0A01454D4800005A0A58726201640DC8AB620163EF150076050029332A62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AB7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AB621E52FF6424CB750177070100010801FF01726201640DC8AB621E52FF62000177070100010802FF01726201640DC8AB621E52FF6424CB750177070100020800FF01726201640DC8AB621E52FF6339CA0177070100020801FF01726201640DC8AB621E52FF62000177070100020802FF01726201640DC8AB621E52FF6339CA0177070100100700FF0101621B520053046201010163535A0076050029332B62006200726302017101636B9C001B1B1B1B1A00629A
2016.12.08 19:07:53 5: OBIS: Full message-> 1B1B1B1B010101017605002933296200620072630101760107FFFFFFFFFFFF05000DBBB90B0A01454D4800005A0A58726201640DC8AB620163EF150076050029332A62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AB7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AB621E52FF6424CB750177070100010801FF01726201640DC8AB621E52FF62000177070100010802FF01726201640DC8AB621E52FF6424CB750177070100020800FF01726201640DC8AB621E52FF6339CA0177070100020801FF01726201640DC8AB621E52FF62000177070100020802FF01726201640DC8AB621E52FF6339CA0177070100100700FF0101621B520053046201010163535A0076050029332B62006200726302017101636B9C001B1B1B1B1A00629A
2016.12.08 19:07:52 4: parsing....
2016.12.08 19:07:52 4: parsing....
2016.12.08 19:07:52 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:52 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:52 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:52 5: OBIS: Telegram=1B1B1B1B010101017605002933266200620072630101760107FFFFFFFFFFFF05000DBBB80B0A01454D4800005A0A58726201640DC8AA62016301190076050029332762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AA7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AA621E52FF6424CB720177070100010801FF01726201640DC8AA621E52FF62000177070100010802FF01726201640DC8AA621E52FF6424CB720177070100020800FF01726201640DC8AA621E52FF6339CA0177070100020801FF01726201640DC8AA621E52FF62000177070100020802FF01726201640DC8AA621E52FF6339CA0177070100100700FF0101621B520053045F0101016308CF007605002933286200620072630201710163D862001B1B1B1B1A00F068
2016.12.08 19:07:52 5: OBIS: Full message-> 1B1B1B1B010101017605002933266200620072630101760107FFFFFFFFFFFF05000DBBB80B0A01454D4800005A0A58726201640DC8AA62016301190076050029332762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8AA7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8AA621E52FF6424CB720177070100010801FF01726201640DC8AA621E52FF62000177070100010802FF01726201640DC8AA621E52FF6424CB720177070100020800FF01726201640DC8AA621E52FF6339CA0177070100020801FF01726201640DC8AA621E52FF62000177070100020802FF01726201640DC8AA621E52FF6339CA0177070100100700FF0101621B520053045F0101016308CF007605002933286200620072630201710163D862001B1B1B1B1A00F068
2016.12.08 19:07:51 4: parsing....
2016.12.08 19:07:51 4: parsing....
2016.12.08 19:07:51 4: parsing....
2016.12.08 19:07:51 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:51 4: parsing....
2016.12.08 19:07:51 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:51 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:51 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:51 5: OBIS: Telegram=1B1B1B1B010101017605002933236200620072630101760107FFFFFFFFFFFF05000DBBB70B0A01454D4800005A0A58726201640DC8A9620163D5190076050029332462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A97977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A9621E52FF6424CB6F0177070100010801FF01726201640DC8A9621E52FF62000177070100010802FF01726201640DC8A9621E52FF6424CB6F0177070100020800FF01726201640DC8A9621E52FF6339CA0177070100020801FF01726201640DC8A9621E52FF62000177070100020802FF01726201640DC8A9621E52FF6339CA0177070100100700FF0101621B52005304580101016377CC007605002933256200620072630201710163B6D5001B1B1B1B1A006E72
2016.12.08 19:07:51 5: OBIS: Full message-> 1B1B1B1B010101017605002933236200620072630101760107FFFFFFFFFFFF05000DBBB70B0A01454D4800005A0A58726201640DC8A9620163D5190076050029332462006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A97977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A9621E52FF6424CB6F0177070100010801FF01726201640DC8A9621E52FF62000177070100010802FF01726201640DC8A9621E52FF6424CB6F0177070100020800FF01726201640DC8A9621E52FF6339CA0177070100020801FF01726201640DC8A9621E52FF62000177070100020802FF01726201640DC8A9621E52FF6339CA0177070100100700FF0101621B52005304580101016377CC007605002933256200620072630201710163B6D5001B1B1B1B1A006E72
2016.12.08 19:07:51 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:51 4: parsing....
2016.12.08 19:07:50 4: parsing....
2016.12.08 19:07:50 4: parsing....
2016.12.08 19:07:49 4: parsing....
2016.12.08 19:07:49 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:49 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:49 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:49 5: OBIS: Telegram=1B1B1B1B010101017605002933206200620072630101760107FFFFFFFFFFFF05000DBBB60B0A01454D4800005A0A58726201640DC8A862016329C40076050029332162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A87977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A8621E52FF6424CB6B0177070100010801FF01726201640DC8A8621E52FF62000177070100010802FF01726201640DC8A8621E52FF6424CB6B0177070100020800FF01726201640DC8A8621E52FF6339CA0177070100020801FF01726201640DC8A8621E52FF62000177070100020802FF01726201640DC8A8621E52FF6339CA0177070100100700FF0101621B520053045A01010163E0640076050029332262006200726302017101635075001B1B1B1B1A009FD0
2016.12.08 19:07:49 5: OBIS: Full message-> 1B1B1B1B010101017605002933206200620072630101760107FFFFFFFFFFFF05000DBBB60B0A01454D4800005A0A58726201640DC8A862016329C40076050029332162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A87977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A8621E52FF6424CB6B0177070100010801FF01726201640DC8A8621E52FF62000177070100010802FF01726201640DC8A8621E52FF6424CB6B0177070100020800FF01726201640DC8A8621E52FF6339CA0177070100020801FF01726201640DC8A8621E52FF62000177070100020802FF01726201640DC8A8621E52FF6339CA0177070100100700FF0101621B520053045A01010163E0640076050029332262006200726302017101635075001B1B1B1B1A009FD0
2016.12.08 19:07:49 4: parsing....
2016.12.08 19:07:49 4: parsing....
2016.12.08 19:07:48 4: parsing....
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:48 5: OBIS: Telegram=1B1B1B1B0101010176050029331D6200620072630101760107FFFFFFFFFFFF05000DBBB50B0A01454D4800005A0A58726201640DC8A7620163F7350076050029331E62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A77977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A7621E52FF6424CB680177070100010801FF01726201640DC8A7621E52FF62000177070100010802FF01726201640DC8A7621E52FF6424CB680177070100020800FF01726201640DC8A7621E52FF6339CA0177070100020801FF01726201640DC8A7621E52FF62000177070100020802FF01726201640DC8A7621E52FF6339CA0177070100100700FF0101621B52005304210101016315AB0076050029331F6200620072630201710163F151001B1B1B1B1A003482
2016.12.08 19:07:48 5: OBIS: Full message-> 1B1B1B1B0101010176050029331D6200620072630101760107FFFFFFFFFFFF05000DBBB50B0A01454D4800005A0A58726201640DC8A7620163F7350076050029331E62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A77977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A7621E52FF6424CB680177070100010801FF01726201640DC8A7621E52FF62000177070100010802FF01726201640DC8A7621E52FF6424CB680177070100020800FF01726201640DC8A7621E52FF6339CA0177070100020801FF01726201640DC8A7621E52FF62000177070100020802FF01726201640DC8A7621E52FF6339CA0177070100100700FF0101621B52005304210101016315AB0076050029331F6200620072630201710163F151001B1B1B1B1A003482
2016.12.08 19:07:48 4: parsing....
2016.12.08 19:07:48 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:48 4: parsing....
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:48 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:48 5: OBIS: Telegram=1B1B1B1B0101010176050029331A6200620072630101760107FFFFFFFFFFFF05000DBBB40B0A01454D4800005A0A58726201640DC8A66201630A5F0076050029331B62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A67977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A6621E52FF6424CB650177070100010801FF01726201640DC8A6621E52FF62000177070100010802FF01726201640DC8A6621E52FF6424CB650177070100020800FF01726201640DC8A6621E52FF6339CA0177070100020801FF01726201640DC8A6621E52FF62000177070100020802FF01726201640DC8A6621E52FF6339CA0177070100100700FF0101621B520053040D0101016313430076050029331C620062007263020171016342AF001B1B1B1B1A00A239
2016.12.08 19:07:48 5: OBIS: Full message-> 1B1B1B1B0101010176050029331A6200620072630101760107FFFFFFFFFFFF05000DBBB40B0A01454D4800005A0A58726201640DC8A66201630A5F0076050029331B62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A67977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A6621E52FF6424CB650177070100010801FF01726201640DC8A6621E52FF62000177070100010802FF01726201640DC8A6621E52FF6424CB650177070100020800FF01726201640DC8A6621E52FF6339CA0177070100020801FF01726201640DC8A6621E52FF62000177070100020802FF01726201640DC8A6621E52FF6339CA0177070100100700FF0101621B520053040D0101016313430076050029331C620062007263020171016342AF001B1B1B1B1A00A239
2016.12.08 19:07:48 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:48 4: parsing....
2016.12.08 19:07:47 4: parsing....
2016.12.08 19:07:47 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:47 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:47 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:47 5: OBIS: Telegram=1B1B1B1B010101017605002933176200620072630101760107FFFFFFFFFFFF05000DBBB30B0A01454D4800005A0A58726201640DC8A5620163BC8A0076050029331862006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A57977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A5621E52FF6424CB620177070100010801FF01726201640DC8A5621E52FF62000177070100010802FF01726201640DC8A5621E52FF6424CB620177070100020800FF01726201640DC8A5621E52FF6339CA0177070100020801FF01726201640DC8A5621E52FF62000177070100020802FF01726201640DC8A5621E52FF6339CA0177070100100700FF0101621B520053046F01010163DF1800760500293319620062007263020171016386A4001B1B1B1B1A002CD2
2016.12.08 19:07:47 5: OBIS: Full message-> 1B1B1B1B010101017605002933176200620072630101760107FFFFFFFFFFFF05000DBBB30B0A01454D4800005A0A58726201640DC8A5620163BC8A0076050029331862006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A57977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A5621E52FF6424CB620177070100010801FF01726201640DC8A5621E52FF62000177070100010802FF01726201640DC8A5621E52FF6424CB620177070100020800FF01726201640DC8A5621E52FF6339CA0177070100020801FF01726201640DC8A5621E52FF62000177070100020802FF01726201640DC8A5621E52FF6339CA0177070100100700FF0101621B520053046F01010163DF1800760500293319620062007263020171016386A4001B1B1B1B1A002CD2
2016.12.08 19:07:46 4: parsing....
2016.12.08 19:07:45 4: parsing....
2016.12.08 19:07:45 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:45 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:45 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:45 5: OBIS: Telegram=1B1B1B1B010101017605002933146200620072630101760107FFFFFFFFFFFF05000DBBB20B0A01454D4800005A0A58726201640DC8A462016340570076050029331562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A47977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A4621E52FF6424CB5F0177070100010801FF01726201640DC8A4621E52FF62000177070100010802FF01726201640DC8A4621E52FF6424CB5F0177070100020800FF01726201640DC8A4621E52FF6339CA0177070100020801FF01726201640DC8A4621E52FF62000177070100020802FF01726201640DC8A4621E52FF6339CA0177070100100700FF0101621B520053046301010163DCCA007605002933166200620072630201710163CAB8001B1B1B1B1A004CDE
2016.12.08 19:07:45 5: OBIS: Full message-> 1B1B1B1B010101017605002933146200620072630101760107FFFFFFFFFFFF05000DBBB20B0A01454D4800005A0A58726201640DC8A462016340570076050029331562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A47977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A4621E52FF6424CB5F0177070100010801FF01726201640DC8A4621E52FF62000177070100010802FF01726201640DC8A4621E52FF6424CB5F0177070100020800FF01726201640DC8A4621E52FF6339CA0177070100020801FF01726201640DC8A4621E52FF62000177070100020802FF01726201640DC8A4621E52FF6339CA0177070100100700FF0101621B520053046301010163DCCA007605002933166200620072630201710163CAB8001B1B1B1B1A004CDE
2016.12.08 19:07:45 4: parsing....
2016.12.08 19:07:44 4: parsing....
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:44 5: OBIS: Telegram=1B1B1B1B010101017605002933116200620072630101760107FFFFFFFFFFFF05000DBBB10B0A01454D4800005A0A58726201640DC8A3620163345A0076050029331262006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A37977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A3621E52FF6424CB5C0177070100010801FF01726201640DC8A3621E52FF62000177070100010802FF01726201640DC8A3621E52FF6424CB5C0177070100020800FF01726201640DC8A3621E52FF6339CA0177070100020801FF01726201640DC8A3621E52FF62000177070100020802FF01726201640DC8A3621E52FF6339CA0177070100100700FF0101621B52005304650101016321610076050029331362006200726302017101630EB3001B1B1B1B1A0089C9
2016.12.08 19:07:44 5: OBIS: Full message-> 1B1B1B1B010101017605002933116200620072630101760107FFFFFFFFFFFF05000DBBB10B0A01454D4800005A0A58726201640DC8A3620163345A0076050029331262006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A37977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A3621E52FF6424CB5C0177070100010801FF01726201640DC8A3621E52FF62000177070100010802FF01726201640DC8A3621E52FF6424CB5C0177070100020800FF01726201640DC8A3621E52FF6339CA0177070100020801FF01726201640DC8A3621E52FF62000177070100020802FF01726201640DC8A3621E52FF6339CA0177070100100700FF0101621B52005304650101016321610076050029331362006200726302017101630EB3001B1B1B1B1A0089C9
2016.12.08 19:07:44 4: parsing....
2016.12.08 19:07:44 4: parsing....
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:44 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:44 5: OBIS: Telegram=1B1B1B1B0101010176050029330E6200620072630101760107FFFFFFFFFFFF05000DBBB00B0A01454D4800005A0A58726201640DC8A2620163FC9A0076050029330F62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A27977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A2621E52FF6424CB590177070100010801FF01726201640DC8A2621E52FF62000177070100010802FF01726201640DC8A2621E52FF6424CB590177070100020800FF01726201640DC8A2621E52FF6339CA0177070100020801FF01726201640DC8A2621E52FF62000177070100020802FF01726201640DC8A2621E52FF6339CA0177070100100700FF0101621B520053046501010163988A007605002933106200620072630201710163BD4D001B1B1B1B1A00C8FA
2016.12.08 19:07:44 5: OBIS: Full message-> 1B1B1B1B0101010176050029330E6200620072630101760107FFFFFFFFFFFF05000DBBB00B0A01454D4800005A0A58726201640DC8A2620163FC9A0076050029330F62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A27977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A2621E52FF6424CB590177070100010801FF01726201640DC8A2621E52FF62000177070100010802FF01726201640DC8A2621E52FF6424CB590177070100020800FF01726201640DC8A2621E52FF6339CA0177070100020801FF01726201640DC8A2621E52FF62000177070100020802FF01726201640DC8A2621E52FF6339CA0177070100100700FF0101621B520053046501010163988A007605002933106200620072630201710163BD4D001B1B1B1B1A00C8FA
2016.12.08 19:07:43 4: parsing....
2016.12.08 19:07:43 4: parsing....
2016.12.08 19:07:43 4: parsing....
2016.12.08 19:07:43 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:43 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:43 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:43 5: OBIS: Telegram=1B1B1B1B010101017605002933086200620072630101760107FFFFFFFFFFFF05000DBBAE0B0A01454D4800005A0A58726201640DC8A062016327290076050029330962006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A07977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A0621E52FF6424CB530177070100010801FF01726201640DC8A0621E52FF62000177070100010802FF01726201640DC8A0621E52FF6424CB530177070100020800FF01726201640DC8A0621E52FF6339CA0177070100020801FF01726201640DC8A0621E52FF62000177070100020802FF01726201640DC8A0621E52FF6339CA0177070100100700FF0101621B520053046801010163280A0076050029330A6200620072630201710163702B001B1B1B1B1A00A1AC
2016.12.08 19:07:43 5: OBIS: Full message-> 1B1B1B1B010101017605002933086200620072630101760107FFFFFFFFFFFF05000DBBAE0B0A01454D4800005A0A58726201640DC8A062016327290076050029330962006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8A07977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC8A0621E52FF6424CB530177070100010801FF01726201640DC8A0621E52FF62000177070100010802FF01726201640DC8A0621E52FF6424CB530177070100020800FF01726201640DC8A0621E52FF6339CA0177070100020801FF01726201640DC8A0621E52FF62000177070100020802FF01726201640DC8A0621E52FF6339CA0177070100100700FF0101621B520053046801010163280A0076050029330A6200620072630201710163702B001B1B1B1B1A00A1AC
2016.12.08 19:07:42 4: parsing....
2016.12.08 19:07:41 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:40 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:40 4: parsing....
2016.12.08 19:07:40 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:40 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:40 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:40 5: OBIS: Telegram=1B1B1B1B010101017605002933056200620072630101760107FFFFFFFFFFFF05000DBBAD0B0A01454D4800005A0A58726201640DC89F6201632C020076050029330662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89F7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89F621E52FF6424CB500177070100010801FF01726201640DC89F621E52FF62000177070100010802FF01726201640DC89F621E52FF6424CB500177070100020800FF01726201640DC89F621E52FF6339CA0177070100020801FF01726201640DC89F621E52FF62000177070100020802FF01726201640DC89F621E52FF6339CA0177070100100700FF0101621B520053046C010101635CF80076050029330762006200726302017101631E9C001B1B1B1B1A00EB6E
2016.12.08 19:07:40 5: OBIS: Full message-> 1B1B1B1B010101017605002933056200620072630101760107FFFFFFFFFFFF05000DBBAD0B0A01454D4800005A0A58726201640DC89F6201632C020076050029330662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89F7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89F621E52FF6424CB500177070100010801FF01726201640DC89F621E52FF62000177070100010802FF01726201640DC89F621E52FF6424CB500177070100020800FF01726201640DC89F621E52FF6339CA0177070100020801FF01726201640DC89F621E52FF62000177070100020802FF01726201640DC89F621E52FF6339CA0177070100100700FF0101621B520053046C010101635CF80076050029330762006200726302017101631E9C001B1B1B1B1A00EB6E
2016.12.08 19:07:40 4: parsing....
2016.12.08 19:07:39 4: parsing....
2016.12.08 19:07:39 4: parsing....
2016.12.08 19:07:39 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:39 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:39 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:39 5: OBIS: Telegram=1B1B1B1B010101017605002932FF6200620072630101760107FFFFFFFFFFFF05000DBBAB0B0A01454D4800005A0A58726201640DC89D620163A6180076050029330062006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89D7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89D621E52FF6424CB490177070100010801FF01726201640DC89D621E52FF62000177070100010802FF01726201640DC89D621E52FF6424CB490177070100020800FF01726201640DC89D621E52FF6339CA0177070100020801FF01726201640DC89D621E52FF62000177070100020802FF01726201640DC89D621E52FF6339CA0177070100100700FF0101621B520053044D010101630BAE0076050029330162006200726302017101636969001B1B1B1B1A00F109
2016.12.08 19:07:39 5: OBIS: Full message-> 1B1B1B1B010101017605002932FF6200620072630101760107FFFFFFFFFFFF05000DBBAB0B0A01454D4800005A0A58726201640DC89D620163A6180076050029330062006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89D7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89D621E52FF6424CB490177070100010801FF01726201640DC89D621E52FF62000177070100010802FF01726201640DC89D621E52FF6424CB490177070100020800FF01726201640DC89D621E52FF6339CA0177070100020801FF01726201640DC89D621E52FF62000177070100020802FF01726201640DC89D621E52FF6339CA0177070100100700FF0101621B520053044D010101630BAE0076050029330162006200726302017101636969001B1B1B1B1A00F109
2016.12.08 19:07:39 4: parsing....
2016.12.08 19:07:38 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:38 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:37 4: parsing....
2016.12.08 19:07:37 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:37 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:37 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:37 5: OBIS: Telegram=1B1B1B1B010101017605002932FC6200620072630101760107FFFFFFFFFFFF05000DBBAA0B0A01454D4800005A0A58726201640DC89C6201635AC5007605002932FD62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89C7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89C621E52FF6424CB460177070100010801FF01726201640DC89C621E52FF62000177070100010802FF01726201640DC89C621E52FF6424CB460177070100020800FF01726201640DC89C621E52FF6339CA0177070100020801FF01726201640DC89C621E52FF62000177070100020802FF01726201640DC89C621E52FF6339CA0177070100100700FF0101621B520053044E01010163623C007605002932FE6200620072630201710163A13C001B1B1B1B1A00BD3D
2016.12.08 19:07:37 5: OBIS: Full message-> 1B1B1B1B010101017605002932FC6200620072630101760107FFFFFFFFFFFF05000DBBAA0B0A01454D4800005A0A58726201640DC89C6201635AC5007605002932FD62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89C7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89C621E52FF6424CB460177070100010801FF01726201640DC89C621E52FF62000177070100010802FF01726201640DC89C621E52FF6424CB460177070100020800FF01726201640DC89C621E52FF6339CA0177070100020801FF01726201640DC89C621E52FF62000177070100020802FF01726201640DC89C621E52FF6339CA0177070100100700FF0101621B520053044E01010163623C007605002932FE6200620072630201710163A13C001B1B1B1B1A00BD3D
2016.12.08 19:07:37 4: parsing....
2016.12.08 19:07:37 4: parsing....
2016.12.08 19:07:36 4: parsing....
2016.12.08 19:07:36 4: parsing....
2016.12.08 19:07:36 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:36 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:36 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:36 5: OBIS: Telegram=1B1B1B1B010101017605002932F66200620072630101760107FFFFFFFFFFFF05000DBBA80B0A01454D4800005A0A58726201640DC89A620163C0C4007605002932F762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89A7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89A621E52FF6424CB400177070100010801FF01726201640DC89A621E52FF62000177070100010802FF01726201640DC89A621E52FF6424CB400177070100020800FF01726201640DC89A621E52FF6339CA0177070100020801FF01726201640DC89A621E52FF62000177070100020802FF01726201640DC89A621E52FF6339CA0177070100100700FF0101621B520053045701010163E1AF007605002932F86200620072630201710163D6C9001B1B1B1B1A00AF5E
2016.12.08 19:07:36 5: OBIS: Full message-> 1B1B1B1B010101017605002932F66200620072630101760107FFFFFFFFFFFF05000DBBA80B0A01454D4800005A0A58726201640DC89A620163C0C4007605002932F762006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC89A7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC89A621E52FF6424CB400177070100010801FF01726201640DC89A621E52FF62000177070100010802FF01726201640DC89A621E52FF6424CB400177070100020800FF01726201640DC89A621E52FF6339CA0177070100020801FF01726201640DC89A621E52FF62000177070100020802FF01726201640DC89A621E52FF6339CA0177070100100700FF0101621B520053045701010163E1AF007605002932F86200620072630201710163D6C9001B1B1B1B1A00AF5E
2016.12.08 19:07:36 4: parsing....
2016.12.08 19:07:35 4: parsing....
2016.12.08 19:07:34 4: parsing....
2016.12.08 19:07:34 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:34 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:34 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:34 5: OBIS: Telegram=1B1B1B1B010101017605002932F06200620072630101760107FFFFFFFFFFFF05000DBBA60B0A01454D4800005A0A58726201640DC898620163E819007605002932F162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8987977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC898621E52FF6424CB3A0177070100010801FF01726201640DC898621E52FF62000177070100010802FF01726201640DC898621E52FF6424CB3A0177070100020800FF01726201640DC898621E52FF6339CA0177070100020801FF01726201640DC898621E52FF62000177070100020802FF01726201640DC898621E52FF6339CA0177070100100700FF0101621B520053042901010163FB48007605002932F262006200726302017101635EDE001B1B1B1B1A00D3D2
2016.12.08 19:07:34 5: OBIS: Full message-> 1B1B1B1B010101017605002932F06200620072630101760107FFFFFFFFFFFF05000DBBA60B0A01454D4800005A0A58726201640DC898620163E819007605002932F162006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8987977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC898621E52FF6424CB3A0177070100010801FF01726201640DC898621E52FF62000177070100010802FF01726201640DC898621E52FF6424CB3A0177070100020800FF01726201640DC898621E52FF6339CA0177070100020801FF01726201640DC898621E52FF62000177070100020802FF01726201640DC898621E52FF6339CA0177070100100700FF0101621B520053042901010163FB48007605002932F262006200726302017101635EDE001B1B1B1B1A00D3D2
2016.12.08 19:07:34 4: parsing....
2016.12.08 19:07:34 4: parsing....
2016.12.08 19:07:33 4: parsing....
2016.12.08 19:07:33 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:33 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:33 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:33 5: OBIS: Telegram=1B1B1B1B010101017605002932EA6200620072630101760107FFFFFFFFFFFF05000DBBA40B0A01454D4800005A0A58726201640DC8966201639612007605002932EB62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8967977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC896621E52FF6424CB340177070100010801FF01726201640DC896621E52FF62000177070100010802FF01726201640DC896621E52FF6424CB340177070100020800FF01726201640DC896621E52FF6339CA0177070100020801FF01726201640DC896621E52FF62000177070100020802FF01726201640DC896621E52FF6339CA0177070100100700FF0101621B520053045301010163FB26007605002932EC6200620072630201710163C6E6001B1B1B1B1A007C7B
2016.12.08 19:07:33 5: OBIS: Full message-> 1B1B1B1B010101017605002932EA6200620072630101760107FFFFFFFFFFFF05000DBBA40B0A01454D4800005A0A58726201640DC8966201639612007605002932EB62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8967977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC896621E52FF6424CB340177070100010801FF01726201640DC896621E52FF62000177070100010802FF01726201640DC896621E52FF6424CB340177070100020800FF01726201640DC896621E52FF6339CA0177070100020801FF01726201640DC896621E52FF62000177070100020802FF01726201640DC896621E52FF6339CA0177070100100700FF0101621B520053045301010163FB26007605002932EC6200620072630201710163C6E6001B1B1B1B1A007C7B
2016.12.08 19:07:32 4: parsing....
2016.12.08 19:07:30 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:30 4: parsing....
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:30 5: OBIS: Telegram=1B1B1B1B010101017605002932E76200620072630101760107FFFFFFFFFFFF05000DBBA30B0A01454D4800005A0A58726201640DC89562016320C7007605002932E862006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8957977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC895621E52FF6424CB310177070100010801FF01726201640DC895621E52FF62000177070100010802FF01726201640DC895621E52FF6424CB310177070100020800FF01726201640DC895621E52FF6339CA0177070100020801FF01726201640DC895621E52FF62000177070100020802FF01726201640DC895621E52FF6339CA0177070100100700FF0101621B520053045301010163A5C6007605002932E9620062007263020171016302ED001B1B1B1B1A007359
2016.12.08 19:07:30 5: OBIS: Full message-> 1B1B1B1B010101017605002932E76200620072630101760107FFFFFFFFFFFF05000DBBA30B0A01454D4800005A0A58726201640DC89562016320C7007605002932E862006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8957977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC895621E52FF6424CB310177070100010801FF01726201640DC895621E52FF62000177070100010802FF01726201640DC895621E52FF6424CB310177070100020800FF01726201640DC895621E52FF6339CA0177070100020801FF01726201640DC895621E52FF62000177070100020802FF01726201640DC895621E52FF6339CA0177070100100700FF0101621B520053045301010163A5C6007605002932E9620062007263020171016302ED001B1B1B1B1A007359
2016.12.08 19:07:30 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:30 4: parsing....
2016.12.08 19:07:30 4: parsing....
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:30 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:30 5: OBIS: Telegram=1B1B1B1B010101017605002932E46200620072630101760107FFFFFFFFFFFF05000DBBA20B0A01454D4800005A0A58726201640DC894620163DC1A007605002932E562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8947977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC894621E52FF6424CB2E0177070100010801FF01726201640DC894621E52FF62000177070100010802FF01726201640DC894621E52FF6424CB2E0177070100020800FF01726201640DC894621E52FF6339CA0177070100020801FF01726201640DC894621E52FF62000177070100020802FF01726201640DC894621E52FF6339CA0177070100100700FF0101621B520053045A01010163E0D9007605002932E662006200726302017101634EF1001B1B1B1B1A00B6ED
2016.12.08 19:07:30 5: OBIS: Full message-> 1B1B1B1B010101017605002932E46200620072630101760107FFFFFFFFFFFF05000DBBA20B0A01454D4800005A0A58726201640DC894620163DC1A007605002932E562006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8947977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC894621E52FF6424CB2E0177070100010801FF01726201640DC894621E52FF62000177070100010802FF01726201640DC894621E52FF6424CB2E0177070100020800FF01726201640DC894621E52FF6339CA0177070100020801FF01726201640DC894621E52FF62000177070100020802FF01726201640DC894621E52FF6339CA0177070100100700FF0101621B520053045A01010163E0D9007605002932E662006200726302017101634EF1001B1B1B1B1A00B6ED
2016.12.08 19:07:29 4: parsing....
2016.12.08 19:07:29 4: parsing....
2016.12.08 19:07:28 4: parsing....
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:28 5: OBIS: Telegram=1B1B1B1B010101017605002932E16200620072630101760107FFFFFFFFFFFF05000DBBA10B0A01454D4800005A0A58726201640DC893620163A817007605002932E262006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8937977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC893621E52FF6424CB2B0177070100010801FF01726201640DC893621E52FF62000177070100010802FF01726201640DC893621E52FF6424CB2B0177070100020800FF01726201640DC893621E52FF6339CA0177070100020801FF01726201640DC893621E52FF62000177070100020802FF01726201640DC893621E52FF6339CA0177070100100700FF0101621B520053044501010163DF65007605002932E362006200726302017101638AFA001B1B1B1B1A00B0FA
2016.12.08 19:07:28 5: OBIS: Full message-> 1B1B1B1B010101017605002932E16200620072630101760107FFFFFFFFFFFF05000DBBA10B0A01454D4800005A0A58726201640DC893620163A817007605002932E262006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8937977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC893621E52FF6424CB2B0177070100010801FF01726201640DC893621E52FF62000177070100010802FF01726201640DC893621E52FF6424CB2B0177070100020800FF01726201640DC893621E52FF6339CA0177070100020801FF01726201640DC893621E52FF62000177070100020802FF01726201640DC893621E52FF6339CA0177070100100700FF0101621B520053044501010163DF65007605002932E362006200726302017101638AFA001B1B1B1B1A00B0FA
2016.12.08 19:07:28 4: parsing....
2016.12.08 19:07:28 2: plex.server: notification websocket: Switching Protocols failed
2016.12.08 19:07:28 3: plex.server: notification websocket opened to 192.168.1.3
2016.12.08 19:07:28 4: parsing....
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:28 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:28 5: OBIS: Telegram=1B1B1B1B010101017605002932DE6200620072630101760107FFFFFFFFFFFF05000DBBA00B0A01454D4800005A0A58726201640DC8926201633D47007605002932DF62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8927977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC892621E52FF6424CB280177070100010801FF01726201640DC892621E52FF62000177070100010802FF01726201640DC892621E52FF6424CB280177070100020800FF01726201640DC892621E52FF6339CA0177070100020801FF01726201640DC892621E52FF62000177070100020802FF01726201640DC892621E52FF6339CA0177070100100700FF0101621B520053041E010101634AFB007605002932E062006200726302017101633904001B1B1B1B1A00C1F6
2016.12.08 19:07:28 5: OBIS: Full message-> 1B1B1B1B010101017605002932DE6200620072630101760107FFFFFFFFFFFF05000DBBA00B0A01454D4800005A0A58726201640DC8926201633D47007605002932DF62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8927977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC892621E52FF6424CB280177070100010801FF01726201640DC892621E52FF62000177070100010802FF01726201640DC892621E52FF6424CB280177070100020800FF01726201640DC892621E52FF6339CA0177070100020801FF01726201640DC892621E52FF62000177070100020802FF01726201640DC892621E52FF6339CA0177070100100700FF0101621B520053041E010101634AFB007605002932E062006200726302017101633904001B1B1B1B1A00C1F6
2016.12.08 19:07:27 4: parsing....
2016.12.08 19:07:27 4: parsing....
2016.12.08 19:07:27 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:27 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:27 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:27 5: OBIS: Telegram=1B1B1B1B010101017605002932DB6200620072630101760107FFFFFFFFFFFF05000DBB9F0B0A01454D4800005A0A58726201640DC891620163FCF4007605002932DC62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8917977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC891621E52FF6424CB250177070100010801FF01726201640DC891621E52FF62000177070100010802FF01726201640DC891621E52FF6424CB250177070100020800FF01726201640DC891621E52FF6339CA0177070100020801FF01726201640DC891621E52FF62000177070100020802FF01726201640DC891621E52FF6339CA0177070100100700FF0101621B520053045501010163B6A1007605002932DD62006200726302017101639820001B1B1B1B1A007369
2016.12.08 19:07:27 5: OBIS: Full message-> 1B1B1B1B010101017605002932DB6200620072630101760107FFFFFFFFFFFF05000DBB9F0B0A01454D4800005A0A58726201640DC891620163FCF4007605002932DC62006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC8917977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC891621E52FF6424CB250177070100010801FF01726201640DC891621E52FF62000177070100010802FF01726201640DC891621E52FF6424CB250177070100020800FF01726201640DC891621E52FF6339CA0177070100020801FF01726201640DC891621E52FF62000177070100020802FF01726201640DC891621E52FF6339CA0177070100100700FF0101621B520053045501010163B6A1007605002932DD62006200726302017101639820001B1B1B1B1A007369
2016.12.08 19:07:26 4: parsing....
2016.12.08 19:07:26 4: parsing....
2016.12.08 19:07:26 4: parsing....
2016.12.08 19:07:26 4: parsing....
2016.12.08 19:07:26 4: parsing....
2016.12.08 19:07:25 4: parsing....
2016.12.08 19:07:25 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:07:25 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:07:25 5: OBIS (Stromzaehler) - Msg-Parse: /
2016.12.08 19:07:25 5: OBIS: Telegram=1B1B1B1B010101017605002932D56200620072630101760107FFFFFFFFFFFF05000DBB9D0B0A01454D4800005A0A58726201640DC88F6201633001007605002932D662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A0A58070100620AFFFF726201640DC88F7977070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A0A580177070100010800FF641C0104726201640DC88F621E52FF6424CB1F0177070100010801FF01726201640DC88F621E52FF62000177070100010802FF01726201640DC88F621E52FF6424CB1F0177070100020800FF01726201640DC88F621E52FF6339CA0177070100020801FF01726201640DC88
Hmm, komisch, das ist jetzt schon der zweite Zähler (zusammen mit dem von Housefrau), der nicht richtig dekodiert wird.
Entweder gibts was neues im OBIS-Standard, das ich noch nicht gefunden habe, oder die haben was vermurkst.
Muss ich wohl wieder mal ein paar Datensätze händisch dekodieren 8)
lg, Stefan
@Icinger
Lass es mich wissen wenn ich dir irgendwo behilflich sein kann.
Wenn du möchtest kann ich dir das Handbuch nach dem Feierabend scannen, wenn es dir weiter hilft?
Gibt es nicht andere Projekte die dir die Arbeit abnehmen können?
Volkszähler oder so?
Gesendet von iPhone mit Tapatalk Pro
Na, das ist, denke ich, keine allzu große Aufgabe.
Wäre nur interessant, mal einen Datensatz von dir zu haben, wo mehr als nur das 255er-Reading geparst wird.
Da muss ja auch wo ein Unterschied sein.
Muss mich nur dazu aufraffen gg
lg, Stefan
Achja, beim nächsten mal bitte Code-Tags für das Log verwenden (oder gleich mir als PN schicken) 8)
Ich hab ich ne bissel mehr geloggt. Hab nur ein paar Zeilen kopiert.
Ich kann dir nachher noch mal das ganze log von mir per PN schicken.
Gruß Robert
Gesendet von iPhone mit Tapatalk Pro
Kannst Du bitte noch Deinen obigen Logauszug in Code-Tags packen. Ist so fürchterlich unübersichtlich und ich blätter so ungern ;)
Grüße Markus
Zitat von: KölnSolar am 09 Dezember 2016, 15:44:23
Kannst Du bitte noch Deinen obigen Logauszug in Code-Tags packen. Ist so fürchterlich unübersichtlich und ich blätter so ungern ;)
Grüße Markus
Erledigt.
Zitat von: no_Legend am 09 Dezember 2016, 16:31:45
Erledigt.
Leider fehlt noch das Code ende: [/ code]
(Ohne Leerzeichen)
Hallo,
ich habe mit OBIS meinen Pafal Zähler eingebunden.
Leider bekomme ich nicht mehr als das zurück:
0.0.1 PAF
0.2.0 1.29
C.2.1
Version PAF5EC3g00006
state opened
total_consumption 1599.93
total_feed 2731.97
Gibt es nicht mehr Werte dich ich auslesen kann oder fehlt etwas in meiner Config?
/dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0106521B-if00-port0@300,7,E,1 VSM102
Gruß
Björnar
Wenn readings kommen, und wenn NUR diese kommen, gibt der Zähler einfach nicht mehr her leider.
lg, Stefan
Hallo,
weiß nicht, ob das hier unbedingt reinpasst. Aber ich frage trotzdem mal: ich möchte den IR-Kopf von Volkszähler-Udo remote per SOCAT mittels OBIS an FHEM anbinden. Dazu habe ich in die rc.local des Pi, an welchem der USB-IR-Kopf angesteckt ist, folgendes eingetragen:
socat TCP4-LISTEN:3000,fork,reuseaddr /dev/ttyUSB0,raw,echo=0,b9600
Bei dem Pi, auf dem FHEM läuft, habe ich in FHEM das hier eingetragen:
define ZSensor OBIS uart://192.168.0.6:3000 SML
Funktioniert leider nicht. Status disconnected. Die Vorgehensweise habe ich so von meinem remote angebunden HM-MOD-RPI-PCB-Modul übernommen (ist an einem anderen, 3. Pi eingesteckt), was problemlos funktioniert.
Der IR-Kopf ist an ttyUSB0 angeschlossen. Netzwerkadresse passt. Beim Rest bin ich mir unsicher. Insbesondere bei dem "uart" vor der Netzwerkadresse zweifle ich die Richtigkeit an. Aber auch der rc.löcal-Eintrag stimmt so vermutlich nicht. Kann mir bitte jemand helfen?
Zitat von: rih am 22 Dezember 2016, 20:03:04
define ZSensor OBIS uart://192.168.0.6:3000 SML
define ZSensor OBIS 192.168.0.6:3000
Danke immi, so geht es. Die Verbindung steht. Habe halt noch das SML dran gehängt. Jetzt muss / kann ich mich weiter zu dem Thema OBIS einlesen. Heißt, die aktuell 18 Seiten durchlesen.
Zitat von: rih am 23 Dezember 2016, 20:25:07
Danke immi, so geht es. Die Verbindung steht. Habe halt noch das SML dran gehängt. Jetzt muss / kann ich mich weiter zu dem Thema OBIS einlesen. Heißt, die aktuell 18 Seiten durchlesen.
SML muss Du nicht schreiben (darfst du); es sollte automagically erkannt werden.
Mit eine raspi, mag ich lieber SER2NET als socat (de gustibus non disputandum est).
immi
Hallo, ich habe meinen IR Leser per ser2net verfügbar gemacht. Das klappt auch (Verbindung steht).
Ich habe jetzt folgendes Verhalten:
pollingMode = off und interval auf 5:
zwischen den 5 Sekunden (bzw in Abhänigkeit zu interval): Tausende Einträge parsing.... aber die Daten werden alle 5 Sekunden geschrieben. Das Log läuft durch das x fache parsing.... pro Sekunde halt irgendwann über.
Stelle ich pollingMode auf on und interval auf 5: Keine parsing.... Meldungen mehr dafür aber kein Schreiben der Werte, sondern nur ein:
2017.01.01 19:22:49 5 : SW:
2017.01.01 19:22:49 4 : Wrote
2017.01.01 19:22:49 5 : OBIS (Strom) - Internal timer set to 2017-01-01 19:22:54
Ich vermute das Verhalten hängt mit der entfernten Verbindung zusammen ?
ser2net ist auf der Gegenstelle so eingerichtet:
3000:raw:0:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT
Danke und Gruß
Christian
Zitat von: awex102 am 01 Januar 2017, 19:25:30
Hallo, ich habe meinen IR Leser per ser2net verfügbar gemacht. Das klappt auch (Verbindung steht).
pollingMode = off und interval auf 5:
Hi Christian
Ich habe SML (per ser2net) und vervende/brauche nicht interval oder pollingmode;
ich mag lieber event-aggregator
attr PowerMeter event-aggregator power:120:linear:mean,total_consumption:300:none:v,total_consumption_Ch1:300:none:v
attr PowerMeter event-on-change-reading .*immi
Ah, verstehe, danke! Eine Rückfrage: Kann man power:120:linear:mean direkt abrunden? Da kommen im Schnitt 10 Nachkommastellen zurück.
Nur zum Verständnis: Es ist also "normal", dass ständig Daten verarbeitet werden auf der Schnittstelle? Bei pollingMode on war meine Annahme, dass nur im Moment der Abfrage Datenverkehr herrscht und ansonsten Ruhe ist...
Zitat von: awex102 am 02 Januar 2017, 08:23:54
Ah, verstehe, danke! Eine Rückfrage: Kann man power:120:linear:mean direkt abrunden? Da kommen im Schnitt 10 Nachkommastellen zurück.
direkt abrunden https://forum.fhem.de/index.php/topic,36771.15.html
m.E ist umständig aber kannst du mit userreading
Zitat
Nur zum Verständnis: Es ist also "normal", dass ständig Daten verarbeitet werden auf der Schnittstelle? Bei pollingMode on war meine Annahme, dass nur im Moment der Abfrage Datenverkehr herrscht und ansonsten Ruhe ist...
both approaches have pro and contra.
----polling mode-
pollingMode is the preferred solution from Stefan, for his system
if you see high CPU load in fhem, you should use it
----
--my setup (photodiode-> transistor-amp -> esp8266 -> wlanrouter -> NAS) ---
The amount of data trasferred over wlan is negligible, if you send all data from the meeter.
Therefore I prefer getting all data to fhem and process what I need.
I like to have an avarage of power over 2 minutes, because my meeter makes no avarage over time; therefore i need 1 reading/second.
I do not like to stop the interface and restart it; I have the impression that the connection is not so stable
-------
immi
Hallo,
hat sich schon mal jemand mit dem Thema "Auswertung" beschäftigt?
Ich stelle mir eine grafische Auswertung per tablet UI vor, also z.B. Verbrauch über den Tag, Verbrauch / Tag, Verbrauch / Monat, Vebrauch / Jahr.
Z.B. in Form von Linien- und Balkendiagrammen (also z.B. ein Balkendiagramm mit 12 aggregierten Balken jeweils pro Monat ein Balken) usw?
Gibt es in fhem entsprechende "out of the box" Lösungen auf Basis der Logfiles ? Das gleiche könnte man ja z.B. auch für die Photovoltaik Anlage, Stromverbrauch der THZ Heizung usw nutzen. Generisch formuliert: Auswertung von devices, die "verbrauchswerte" ausgeben.
Danke und Gruß
Schau mal ob eventuell das energy calculator Modul was für dich ist.
Ohne irgendein Logging bekommst du keine Diagramm hin.
Entweder per filelog oder dB log.
Wo her soll sich FHEM die daten zum anzeigen holen, wenn nichts gespeichert wird?
Gesendet von iPhone mit Tapatalk Pro
zustimm !!!
Ich formuliere es aber mal anders. Du postest Deine Anfrage zu einem device, welches Zählerdaten ausliest. :o Dessen readings kannst Du je nach Geschmack loggen. Wenn Du dann Statistiken fahren willst, kannst Du Dir über das statistics-Modul(nein, die Bezeichnung ist kein Zufall) Daten aggregieren lassen. Die kannst Du dann auch wieder loggen. Was geloggt ist, kannst Du auch plotten.
Grüße Markus
Hi Leute,
habe gerade - endlich - einen Fix eingecheckt, mit dem jene User, die nur das
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: !
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: 255-255:255.255.255*255()
2016.12.08 19:08:07 5: OBIS (Stromzaehler) - Msg-Parse: /
upgedatet bekommen haben jetzt endlich an ihre Daten kommen :D
no_legend hats getestet und es scheint alles zu funktionieren.
Das Problem war, das hier innerhalb des Datenpakets ein Datensatz mit dieser Adresse kommt (eben 255-255:255.255.255*255), welcher sich nicht an die Standard-Kodierung hält.
Somit hat mein Modul kein Ende gefunden und die darauffolgenden Daten nicht mehr auswerten könenn.
Dieser spezielle Datensatz wird nun komplett ausgefiltert.
lg, Stefan
@Icinger
Danke noch mal für deine Hilfe.
Hallo. Ich frage mal vorsichtig in diese Runde.
Nach dem letzten Update habe ich wilde Logbucheinträge die sich mit de Zeiten der Aktualisierung der OBIS Geräte decken.
2017.01.07 15:20:05 3: '7707''81''81''C7''82''03''FF''0101010104454D480177070100000000FF010101010939303036393638310177070100010801FF628201621E52FF560008F1FBBA0177070100020801FF628201621E52FF560008AEF66701770700006001FFFF010101010B303030323235333833300177070100010700FF0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''01''00''00''00''00''FF''010101010939303036393638310177070100010801FF628201621E52FF560008F1FBBA0177070100020801FF628201621E52FF560008AEF66701770700006001FFFF010101010B303030323235333833300177070100010700FF0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''01''00''01''08''01''FF''628201621E52FF560008F1FBBA0177070100020801FF628201621E52FF560008AEF66701770700006001FFFF010101010B303030323235333833300177070100010700FF0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''01''00''02''08''01''FF''628201621E52FF560008AEF66701770700006001FFFF010101010B303030323235333833300177070100010700FF0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''00''00''60''01''FF''FF''010101010B303030323235333833300177070100010700FF0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''01''00''01''07''00''FF''0101621B52FF5500005C7A0177070100020700FF0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:20:05 3: '7707''01''00''02''07''00''FF''0101621B52FF55000000000101016398B8007607000F0A8C0641620062007263020171016353CF000000001B1B1B1B1A0374D5'
2017.01.07 15:21:07 3: '7707''81''81''C7''82''03''FF''0101010104454D480177070100000000FF010101010939303036373237360177070100020801FF620001621E52FF56000CC56B2A01770700006001FFFF010101010B303030323135303933350177070100020700FF0101621B52FF550000000001010163B4FE00760700170A26071F62006200726302017101633D1900001B1B1B1B1A013C4B'
2017.01.07 15:21:07 3: '7707''01''00''00''00''00''FF''010101010939303036373237360177070100020801FF620001621E52FF56000CC56B2A01770700006001FFFF010101010B303030323135303933350177070100020700FF0101621B52FF550000000001010163B4FE00760700170A26071F62006200726302017101633D1900001B1B1B1B1A013C4B'
2017.01.07 15:21:07 3: '7707''01''00''02''08''01''FF''620001621E52FF56000CC56B2A01770700006001FFFF010101010B303030323135303933350177070100020700FF0101621B52FF550000000001010163B4FE00760700170A26071F62006200726302017101633D1900001B1B1B1B1A013C4B'
2017.01.07 15:21:07 3: '7707''00''00''60''01''FF''FF''010101010B303030323135303933350177070100020700FF0101621B52FF550000000001010163B4FE00760700170A26071F62006200726302017101633D1900001B1B1B1B1A013C4B'
2017.01.07 15:21:07 3: '7707''01''00''02''07''00''FF''0101621B52FF550000000001010163B4FE00760700170A26071F62006200726302017101633D1900001B1B1B1B1A013C4B'
Kann das jemand bestätigen? Wenn ja kann man das abstellen?
Upps, da hab ich eine Log-Zeile vergessen auszukommentieren.
Bitte bei Zeile 310
Log 3,Dumper(@list);
einfach ein # davor machen.
Fix kommt morgen mit dem Update.
lg, Stefan
Danke
Hallo Zusammen,
ich bin Neuling und versuche gerade meine ISKRA MT681 mit dem IR-Kopf von Udo in FHEM einzubinden.
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/iskraemeco_mt681
Ich nutze: define Waermepumpe OBIS /dev/ttyUSB0@9600,8,N,1 SML
Ich Trockenlauf am Schreibtisch ist alles ok. Das Device ist eingerichtet und USB verbunden.
Sobald ich aber den Lesekopf auf die IR-Schnittstelle des eHZ setze stürzt FHEM komplett ab.
Sprich so lange der Kopf keine Daten empfängt ist alles ok und sobald er etwas empfängt crasht FHEM.
'fhem is not running'
Es lässt sich reproduzieren und ich bin gerade 20x in den Keller gelaufen um dies herauszufinden... ;-)
Wer kann mir sagen was ich falsch mache?
Keine Ahnung......Aber setz bitte mal das OBIS auf verbose 5 und schau, ob was im log kommt.
Evtl. auch mal stacktrace setzen
hab gerade noch einmal update gemacht. nun läuft es. bekomme readings.
letztes update war von ende letzter woche. war wohl da etwas kaputt...
Hallo Zusammen,
gibt es irgendeine Möglichkeit die Werte direkt umzustellen?
Der Zähler spuckt Wh aus ich hätte aber gern kWh.
Irgendwie beachtet er auch die Channels überhaupt nicht. .
Meine Config:
define SmartMeter OBIS /dev/ttyUSB0@9600,8,N,1 SML
attr SmartMeter channels {"1.0.1.8.1"=>"Zählerstand", "1.0.1.7.0"=>"Last"}
attr SmartMeter group Strom
attr SmartMeter room Heizung
attr SmartMeter interval 30
Zitat von: Takero am 08 Februar 2017, 15:49:52
Hallo Zusammen,
gibt es irgendeine Möglichkeit die Werte direkt umzustellen?
Der Zähler spuckt Wh aus ich hätte aber gern kWh.
Irgendwie beachtet er auch die Channels überhaupt nicht. .
Meine Config:
define SmartMeter OBIS /dev/ttyUSB0@9600,8,N,1 SML
attr SmartMeter channels {"1.0.1.8.1"=>"Zählerstand", "1.0.1.7.0"=>"Last"}
attr SmartMeter group Strom
attr SmartMeter room Heizung
attr SmartMeter interval 30
Mach dir nen UserReading.
ZitatIrgendwie beachtet er auch die Channels überhaupt nicht.
Heisst was genau? Glaskugel ist grade beleidigt, die will heute nicht so wie ich will.
Zitat von: Icinger am 08 Februar 2017, 19:47:56
Heisst was genau? Glaskugel ist grade beleidigt, die will heute nicht so wie ich will.
total_consumption_kWh { my $temp1 = ReadingsVal($name,"total_consumption",0)/1000; return $temp1;}
Das Userreading war mir schon klar, octek.
Mich würde eher interessieren, was Takero mit
ZitatIrgendwie beachtet er auch die Channels überhaupt nicht.
meinte.
Zitat von: Icinger am 08 Februar 2017, 20:50:29
Das Userreading war mir schon klar, octek.
Mich würde eher interessieren, was Takero mit meinte.
Oh sorry, hab nicht richtig geschaut wer geschrieben hatte (Tomaten auf den Augen).
Na klar weißt du das...
Hallo,
danke für die Antworten. Mit Channels anzeigen meine ich das diese nicht als Einzelwerte auftauche. Ich bin davon ausgegangen das dies erkannt wird und separat zur Anzeige kommt. Vielleicht müsste ich mich mal mehr mit Fhem auseinandersetzen. Ich nutze es im Moment nur als Datenschnittstelle zum einsammeln der Daten und nicht als primäres "SmartHome" Interface, ich übertrage die Daten nur an ioBroker.
Mit den umsetzten von Wh auf kWh habe ich geschafft.
Vielen Dank und viele Grüße
Falls dein Zähler die Channels einzeln schickt, sollten auch die Readings dementsprechend angelegt werden.
Wenn dem nicht so ist, bitte genauere Daten zu dem Zähler, evtl. einen gantzen Datensatz von der Schnittstelle usw....
lg, Stefan
Achso, dann macht es sinn. Mein Zähler schickt die beiden Werte einzeln.
Ich habe einen EHZ-G, er sendet ungefragt MomentanLast und Zählerstand via. SML
ZitatAchso, dann macht es sinn.
Naja, ich kann halt nur die Daten auswerten, die dein Zähler auch schickt.
Alles andere wäre Raterei (Wieviel grade auf welcher Phase gezogen wird)
Hallo, ich habe gerade von SMLUSB auf OBIS umgestellt, war ein Kinderspiel, danke für die gute Arbeit.
Die Werte sehen korrekt aus, ich bekomme allerdings im Log immer folgende Zeilen beim Start des Servers:
2017.02.13 14:10:45 0: Featurelevel: 5.7
2017.02.13 14:10:45 0: Server started with 39 defined entities (fhem.pl:13400/2017-02-12 perl:5.020002 os:linux user:fhem pid:2395)
2017.02.13 14:10:47 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 334.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 342.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 343.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 313.
und währed des Betriebs bekomme ich regelmäßig:
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Bezug-Total (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Tarif-1-Bezug (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Bezug-Total (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Tarif-1-Bezug (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
Was könnte da noch falsch sein? Meine Zähler sind definiert als
define Zaehler OBIS /dev/lesekopf1@9600 SML
Das Device ist via udev-Regel auf /dev/ttyUSB0 gemappt.
Zitat von: maximalz am 13 Februar 2017, 14:31:41
Hallo, ich habe gerade von SMLUSB auf OBIS umgestellt, war ein Kinderspiel, danke für die gute Arbeit.
Die Werte sehen korrekt aus, ich bekomme allerdings im Log immer folgende Zeilen beim Start des Servers:
2017.02.13 14:10:45 0: Featurelevel: 5.7
2017.02.13 14:10:45 0: Server started with 39 defined entities (fhem.pl:13400/2017-02-12 perl:5.020002 os:linux user:fhem pid:2395)
2017.02.13 14:10:47 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 334.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 342.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 343.
2017.02.13 14:11:50 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 313.
und währed des Betriebs bekomme ich regelmäßig:
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Bezug-Total (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Tarif-1-Bezug (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Bezug-Total (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Tarif-1-Bezug (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
Was könnte da noch falsch sein? Meine Zähler sind definiert als
define Zaehler OBIS /dev/lesekopf1@9600 SML
Das Device ist via udev-Regel auf /dev/ttyUSB0 gemappt.
Musst du nicht noch angeben, wie die Daten ankommen?
/dev/ttyPlugwise@@9600,7,E,1https://fhem.de/commandref_DE.html#OBIS
Zitat
2017.02.13 14:10:45 3: WARNING: unsupported character in reading Zählerstand-Tarif-1-Bezug (not A-Za-z/\d_\.-), notify the OBIS module maintainer.
Umlaute in Readings-Namen sind seit 5.7 nicht mehr erlaubt.
Also einfach dein Channels-Attribut ändern, und die Sache ist gegessen.
Evtl. musst du noch die alten Readings löschen.
lg, Stefan
Zitat von: Icinger am 13 Februar 2017, 15:09:49
Umlaute in Readings-Namen sind seit 5.7 nicht mehr erlaubt.
Also einfach dein Channels-Attribut ändern, und die Sache ist gegessen.
Evtl. musst du noch die alten Readings löschen.
lg, Stefan
@Icinger
Stefan in der Commandref auf https://fhem.de/commandref_DE.html#OBIS steht immer noch mit "@@" das Define.
Gruß Robert
Hi Robert,
Danke für den Hinweis, nehm hier hier gleich raus und beim nächsten Update kommt das dann mit.
lg, Stefan
Vielen Dank, die Warnungen sind weg.
Hallo Zusammen,
ich versuch seit einigen Tagen OBIS und optische Lesekopf mit meinen neuen Stromzähler ISKAR MT174 zum laufen zu bringen. Leider gelingt mir das nicht vollständig.
Der Zähler muss mit "/?!CR-LR" gepollt werden. Daher habe ich mich nach einigen Versuchen für die Varianten "/dev/ttyUSB1@300,7,E,1 VSM102"
entschieden. Da bekomme ich zumindest einige Readings:
1.0.0.0.0.255 67-81-11-43
1.0.0.0.1.255 1ISK00
1.0.0.0.2 4M012531
1.0.0.1.0.255 3
1.0.0.1.2.01 1702010000
1.0.0.1.2.02 1701230856
1.0.0.1.2.03 1701230856
1.0.0.9.1.255 124136
1.0.0.9.2.255 170214
Version ISk5MT174-0001
state opened
total_consumption 0
total_consumption_Ch1 0
total_consumption_Ch2 0
total_consumption_Ch3 0
Aber Leider bleibt "total_consumption" immer bei "0". Wenn man der Datenauslese eine weile zusieht erscheint ab und an mel ein Wert und wird binnen ca. 0s wieder "0".
Hat einer eine Idee was ich ändern muss ?
Ich hänge mal die vollständige Ausgabe des Zählers als Dump im raw-Foremat an. Vieleicht hilfs ja was.
tatu123
Zitat1-0:1.8.0*255(0000344.481*kWh)
1-0:1.8.0*01(0000129.574*kWh)
1-0:1.8.0*02(0000000.001*kWh)
1-0:1.8.0*03(0000000.000*kWh)
1-0:1.8.1*255(0000219.574*kWh)
1-0:1.8.1*01(0000085.841*kWh)
1-0:1.8.1*02(0000000.001*kWh)
1-0:1.8.1*03(0000000.000*kWh)
1-0:1.8.2*255(0000124.908*kWh)
1-0:1.8.2*01(0000043.733*kWh)
1-0:1.8.2*02(0000000.000*kWh)
1-0:1.8.2*03(0000000.000*kWh)
Hmm, das ist der erste Zähler, der scheinbar meherer Subchannels hat (1.8.1, 1.8.2, 1.8.3 usw)
Kurzfristig solltest du das mittels des Channels-Attributes lösen können.
zB
{"1-0:1.8.0*01"=>"consumption_1","1-0:1.8.1*01"=>"consumption_2","1-0:1.8.3*01"=>"consumption_3"}usw....
Kanns mir gern demnächst mal genauer ansehen, komme momentan nur nicht dazu.
Grad bisschen Stress daheim (gestern abend wurde die Seitenscheibe vom Auto meiner Frau eingeschlagen).
lg, Stefan
Hallo,
tolles Modul! Ich habe gestern mal schnell meinen AS1440 per Lesekopf von Udo und diesem Modul hier in Fhem eingebunden :) Beim Typ habe ich mich für VSM102 entschieden, da dieser Trigger-Code (/?!\r\n) gesendet werden muss. Gibt es eigentlich zwischen den Typen VSM102, E110 und E350USB einen Unterschied in der Kommunikation?
Der AS1440 sendet über 5 Minuten lang Daten per 300 bd, daher reihe ich mich mal in die Schlage derer ein, die die Baudrate nach dem Trigger-Code erhöhen wollen.
Ansonsten habe ich ähnlich wie tatu123 festgestellt, dass einige Readings auf '0' stehen und nur kurzzeitig mal einen Wert haben. Im Log sieht das so aus:
2017.02.14 19:56:44 5: OBIS (as1440) - Msg-Parse: 1.8.0(0000024.4*kWh)
2017.02.14 19:56:44 5: Msg 1.8.0(0000024.4*kWh) is of type Counter
2017.02.14 19:56:45 5: OBIS (as1440) - Msg-Parse: 1.8.0*00(0000000.0*kWh)
2017.02.14 19:56:45 5: Msg 1.8.0*00(0000000.0*kWh) is of type Counter
2017.02.14 19:56:46 5: OBIS (as1440) - Msg-Parse: 1.8.0*99(0000000.0*kWh)
2017.02.14 19:56:46 5: Msg 1.8.0*99(0000000.0*kWh) is of type Counter
2017.02.14 19:56:47 5: OBIS (as1440) - Msg-Parse: 1.8.0*98(0000000.0*kWh)
2017.02.14 19:56:47 5: Msg 1.8.0*98(0000000.0*kWh) is of type Counter
2017.02.14 19:56:48 5: OBIS (as1440) - Msg-Parse: 1.8.0*97(0000000.0*kWh)
2017.02.14 19:56:48 5: Msg 1.8.0*97(0000000.0*kWh) is of type Counter
2017.02.14 19:56:49 5: OBIS (as1440) - Msg-Parse: 1.8.0*96(0000000.0*kWh)
2017.02.14 19:56:49 5: Msg 1.8.0*96(0000000.0*kWh) is of type Counter
2017.02.14 19:56:50 5: OBIS (as1440) - Msg-Parse: 1.8.0*95(0000000.0*kWh)
2017.02.14 19:56:50 5: Msg 1.8.0*95(0000000.0*kWh) is of type Counter
2017.02.14 19:56:51 5: OBIS (as1440) - Msg-Parse: 1.8.0*94(0000000.0*kWh)
2017.02.14 19:56:51 5: Msg 1.8.0*94(0000000.0*kWh) is of type Counter
2017.02.14 19:56:52 5: OBIS (as1440) - Msg-Parse: 1.8.0*93(0000000.0*kWh)
2017.02.14 19:56:52 5: Msg 1.8.0*93(0000000.0*kWh) is of type Counter
2017.02.14 19:56:53 5: OBIS (as1440) - Msg-Parse: 1.8.0*92(0000000.0*kWh)
2017.02.14 19:56:53 5: Msg 1.8.0*92(0000000.0*kWh) is of type Counter
2017.02.14 19:56:54 5: OBIS (as1440) - Msg-Parse: 1.8.0*91(0000000.0*kWh)
2017.02.14 19:56:54 5: Msg 1.8.0*91(0000000.0*kWh) is of type Counter
2017.02.14 19:56:55 5: OBIS (as1440) - Msg-Parse: 1.8.0*90(0000000.0*kWh)
2017.02.14 19:56:55 5: Msg 1.8.0*90(0000000.0*kWh) is of type Counter
2017.02.14 19:56:55 5: OBIS (as1440) - Msg-Parse: 1.8.0*89(0000000.0*kWh)
2017.02.14 19:56:55 5: Msg 1.8.0*89(0000000.0*kWh) is of type Counter
2017.02.14 19:56:56 5: OBIS (as1440) - Msg-Parse: 1.8.0*88(0000000.0*kWh)
2017.02.14 19:56:56 5: Msg 1.8.0*88(0000000.0*kWh) is of type Counter
2017.02.14 19:56:57 5: OBIS (as1440) - Msg-Parse: 1.8.0*87(0000000.0*kWh)
2017.02.14 19:56:57 5: Msg 1.8.0*87(0000000.0*kWh) is of type Counter
2017.02.14 19:56:58 5: OBIS (as1440) - Msg-Parse: 1.8.0*86(0000000.0*kWh)
2017.02.14 19:56:58 5: Msg 1.8.0*86(0000000.0*kWh) is of type Counter
2017.02.14 19:56:59 5: OBIS (as1440) - Msg-Parse: 1.8.1(0000024.4*kWh)
2017.02.14 19:56:59 5: Msg 1.8.1(0000024.4*kWh) is of type Counter
2017.02.14 19:57:00 5: OBIS (as1440) - Msg-Parse: 1.8.1*00(0000000.0*kWh)
2017.02.14 19:57:00 5: Msg 1.8.1*00(0000000.0*kWh) is of type Counter
2017.02.14 19:57:01 5: OBIS (as1440) - Msg-Parse: 1.8.1*99(0000000.0*kWh)
2017.02.14 19:57:01 5: Msg 1.8.1*99(0000000.0*kWh) is of type Counter
2017.02.14 19:57:02 5: OBIS (as1440) - Msg-Parse: 1.8.1*98(0000000.0*kWh)
2017.02.14 19:57:02 5: Msg 1.8.1*98(0000000.0*kWh) is of type Counter
2017.02.14 19:57:03 5: OBIS (as1440) - Msg-Parse: 1.8.1*97(0000000.0*kWh)
2017.02.14 19:57:03 5: Msg 1.8.1*97(0000000.0*kWh) is of type Counter
2017.02.14 19:57:04 5: OBIS (as1440) - Msg-Parse: 1.8.1*96(0000000.0*kWh)
2017.02.14 19:57:04 5: Msg 1.8.1*96(0000000.0*kWh) is of type Counter
2017.02.14 19:57:05 5: OBIS (as1440) - Msg-Parse: 1.8.1*95(0000000.0*kWh)
2017.02.14 19:57:05 5: Msg 1.8.1*95(0000000.0*kWh) is of type Counter
2017.02.14 19:57:06 5: OBIS (as1440) - Msg-Parse: 1.8.1*94(0000000.0*kWh)
2017.02.14 19:57:06 5: Msg 1.8.1*94(0000000.0*kWh) is of type Counter
2017.02.14 19:57:06 5: OBIS (as1440) - Msg-Parse: 1.8.1*93(0000000.0*kWh)
2017.02.14 19:57:06 5: Msg 1.8.1*93(0000000.0*kWh) is of type Counter
2017.02.14 19:57:07 5: OBIS (as1440) - Msg-Parse: 1.8.1*92(0000000.0*kWh)
2017.02.14 19:57:07 5: Msg 1.8.1*92(0000000.0*kWh) is of type Counter
2017.02.14 19:57:08 5: OBIS (as1440) - Msg-Parse: 1.8.1*91(0000000.0*kWh)
2017.02.14 19:57:08 5: Msg 1.8.1*91(0000000.0*kWh) is of type Counter
2017.02.14 19:57:09 5: OBIS (as1440) - Msg-Parse: 1.8.1*90(0000000.0*kWh)
2017.02.14 19:57:09 5: Msg 1.8.1*90(0000000.0*kWh) is of type Counter
2017.02.14 19:57:10 5: OBIS (as1440) - Msg-Parse: 1.8.1*89(0000000.0*kWh)
2017.02.14 19:57:10 5: Msg 1.8.1*89(0000000.0*kWh) is of type Counter
2017.02.14 19:57:11 5: OBIS (as1440) - Msg-Parse: 1.8.1*88(0000000.0*kWh)
2017.02.14 19:57:11 5: Msg 1.8.1*88(0000000.0*kWh) is of type Counter
2017.02.14 19:57:12 5: OBIS (as1440) - Msg-Parse: 1.8.1*87(0000000.0*kWh)
2017.02.14 19:57:12 5: Msg 1.8.1*87(0000000.0*kWh) is of type Counter
2017.02.14 19:57:13 5: OBIS (as1440) - Msg-Parse: 1.8.1*86(0000000.0*kWh)
2017.02.14 19:57:13 5: Msg 1.8.1*86(0000000.0*kWh) is of type Counter
Es sieht für mich so aus, als ob der Code 1.8.0 gleich wieder von 1.8.0*00 überschrieben wird. Dieses Muster sehe ich auch bei allen ähnlichen Codes, die der Zähler so liefert. Mit dem Channel-Attribute könnte man das wahrscheinlich erst mal "hinbiegen" oder?
Gruß Vuffiraa
Danke für die schnelle Antwort. Mit dem Channel-attr komme ich erst mal hin. Aber währ schon schön wenn der Zähler "richtig" Unterstützt werden würde. Aber natürlich löse erst mal deine priv Probleme. geht natürlich vor.
Ich hab mal meine Sammlung der Channel zusammengestellt:
0.1.2.1 Speicherdatum Vorwert 1
0.1.2.1 Speicherzeitpunkt Vorwert 1
0.1.2.2 Speicherdatum Vorwert 2
0.1.2.2 Speicherzeitpunkt Vorwert 2
bis zu 9 bzw. 15 Zeitpunkte abrufbar
0.2.0 Softwareversion
0.2.2 Tarifprogramm
1.8.0 aktueller Zählerstand Bezug untarifiert
1.8.0.1 Zählerstand zu Beginn des Monats
1.8.0.2 Zählerstand zu Beginn des Vormonats
bis zu 9 bzw. 15 Vorwerte abrufbar
1.8.1 aktueller Zählerstand im Tarif 1 (Hochtarif)
1.8.1.1 Zählerstand zu Beginn des Monats
1.8.1.2 Zählerstand zu Beginn des Vormonats
bis zu 9 bzw. 15 Vorwerte abrufbar
Es folgen in gleicher Weise 1.8.2.x und – sofern vorhanden – 1.8.3.x
sowie 1.8.4.x für die Tarife T2, T3, T4.
1.7.0 aktuelle Leistung
0.9.1 Uhrzeit hh:mm:ss
0.9.2 Datum dd.mm.jj
31.7.0 Strom in L1
51.7.0 Strom in L2
71.7.0 Strom in L3
F.F.0 Fehlerregister (F.F.0 0000000 ist fehlerfrei; ggf. ausgeblendet)
Der Zähler kann auch mit 9600 übertragen. Die Umschaltung erfolgt so:
/?!<0D><0A>
Der Zähler antwortet z.B. mit
/ISk5MT174-0001
Die Baudrate läßt sich auch auf 9600 Baud umstellen wenn man innerhalb von 2s nachdem der Zähler seine Identifikation geschickt hat, ein Acknowledge Paket (ACK050CRLF) schickt.
<06>050<0D><0A>
Worauf der Zähler beginnt seine Daten mit 9600 Baud auszugeben.
Grüße
tatu123
Hi Leute,
das mit den gleichen Channels werde ich demnächst nachreichen, bitte zwischenzeitlich wie schon angemerkt mit dem Channels-Attribut arbeiten.
@tatu123:
Das mit dem Umschalten hab ich eh am Schirm, nur wars bislang noch nicht wirklich so notwendig :)
Du kannst deinen Zähler auch zB auf 38400 setzen mittels
<06>080<0D><0A>
Das ist halt immer nur temporär, solange die Schnittstelle geöffnet ist :)
lg, Stefan
Hallo vuffira, ich habe auch 2 Leseköpfe von Udo und bei mir liefert
define Zaehler OBIS /dev/lesekopf1@9600,8,N,1 SML
jede Sekunde alle relevanten Messwerte.
Ich uabe eher das Problem, dass eas 86400 Werte am Tag sind und ich beide Zähler ih einem Plot darstelle, was dann zum Aufbau der Seite ca. 5 min. benötigt.
Weiß jemand, wie ich fürvdas Plot z.b. 10 Messwerte zu einem aggregieren kann?
Dafür gibts
Zitatevent-aggregator
The primary uses of this attribute are to calculate (time-weighted) averages of readings over time periods and to throttle the update rate of readings and thus the amount of data written to the logs.
lg, Stefan
Danke für den Tipp, ich habe das mal konfiguriert
Zitat von: Icinger am 19 Februar 2017, 09:11:10
Dafür gibts
lg, Stefan
und würde jetet erwarten, dass der aktuelle Verbrauch alle 5 Minuten geloggt wird, der Zählerstand jede Stunde und Rest einmal am Tag.
attr ZaehlerWP event-aggregator \
0.118.7.0.37.255:86400:none:v0, \
1.0.0.0.9.255:86400:const:v0, \
129.129.199.130.3.255:86400:const:v0, \
129.129.199.130.5.255:86400:const:v0, \
dir_total_consumption:86400:const:v0, \
power:30:linear:mean, \
state:86400:none:v0, \
total_consumption:3600:const:v, \
total_consumption_Ch1:3600:const:v, \
total_consumption_Ch2:3600:const:v, \
Version:86400:none:v0
Allerdings werden alle Werte ca. alle 5 Sekunden geloggt. Was habe ich hier nicht verstanden?
Gruß
Frank
Zitat von: maximalz am 19 Februar 2017, 08:54:04
Hallo vuffira, ich habe auch 2 Leseköpfe von Udo und bei mir liefert
define Zaehler OBIS /dev/lesekopf1@9600,8,N,1 SML
jede Sekunde alle relevanten Messwerte.
Hallo Frank,
Du hast wahrscheinlich andere Zähler, ich habe einen Elster AS1440. Die Zähler unterscheiden sich bei Baudrate und Sendefrequenz.
Zu deinem Problem mit den vielen Werten, schau die mal das Attribute event-on-change-reading an https://wiki.fhem.de/wiki/Event-on-change-reading (https://wiki.fhem.de/wiki/Event-on-change-reading).
Gruß Vuffiraa
Danke für den Tipp, das blendet zwar jetzt die statischen Werte auw, aber power und totalconsumption werden immer noch viel zu oft geloggt. Ich möchte erreichen, dass ich nur in definierten Intervallen Werte geloggt bekomme.
Zitat von: maximalz am 19 Februar 2017, 18:57:05
Danke für den Tipp, das blendet zwar jetzt die statischen Werte auw, aber power und totalconsumption werden immer noch viel zu oft geloggt. Ich möchte erreichen, dass ich nur in definierten Intervallen Werte geloggt bekomme.
Auf der Wiki-Seite ist noch kurz die Kombination mit dem Attribut Event-min-Intervall erwähnt. Damit sollte es gehen.
müsste nicht polling mode, interval und ggfs. aligntime funktionieren ?
Grüße Markus
Die Lösungen verhindern zwar beide, dass ich zu viele Log-Einträge bekomme, aber in beiden Fällen verliere ich Werte, die dann nicht mal gemittelt ins Log eingehen oder?
Mit dem event-aggregator sollte ich doch mehrere Werte zu einem Event zusammenfassen können. Das scheint aber nicht so einfach zu sein, denn ich habe mehrere Posts gefunden, bei denen es so nicht funktioniert.
Ich könnte auch alle Werte in Elasticsearch pumpen, dann bin ich bei der Auswertung flexibel, das ist aber Overkill denke ich...
Dann schau dir alternativ das statistics-Modul an.
Ich habe die Lösung gefunden. Das event-aggregator funktioniert, allerdings dürfen in dem Ausdruck keine Leerzeichen und auch keine maskierten Zeilenumbrüche enthalten sein.
Hallo zusammen,
ich nutze den IR-Schreib-Lesekopf mit USB-Interface von volkszaehler.org zur Erfassung meines EasyMeter Q3D (ESY5Q3DA1006 V3.04).
Mir ist aufgefallen, dass der in FHEM angezeigte Wert des Readings total_consumption dem am Stronzähler angezeigten Wert mit der Zeit immer mehr hinterherläuft, d.h. die Differenz wird mit der Zeit zunehmend größer.
Ich habe den Eindruck, dass entweder der Stromzähler oder der IR-Schreib-Lesekopf intern die Werte puffert und das OBIS-Modul immer nur den ältesten Wert abholt. Ich habe daher mal auf der Konsole den Befehl
cat /dev/ttyUSB0
abgesetzt, daraufhin habe ich innerhalb von Sekundenbruchteilen einen Haufen Datenpakete bekommen, in denen der Zählerstand kontinuierlich hochlief. Der Versuch, das Kommando sofort nochmal auszuführen, lieferte keine Ausgabe - erst, wenn ich ein paar Sekunden warte, scheinen wieder Daten da zu sein.
In FHEM konnte ich beobachten, dass nach diesem "Leeren" des Puffers das Reading total_consumption einen Sprung machte und wieder mit dem auf dem Zähler angezeigten Wert übereinstimmte.
Die Definition in der fhem.cfg sieht wie folgt aus:
##### Stromzaehler: Geraete-Definition
define Stromzaehler OBIS /dev/ttyUSB0@9600,7,E,1 SML
attr Stromzaehler interval 60
attr Stromzaehler pollingMode on
attr Stromzaehler room Strom
attr Stromzaehler unitReadings off
attr Stromzaehler verbose 5
Wie bekomme ich es hin, dass mir der aktuelle Wert und nicht der älteste Wert aus irgend einem internen Puffer angezeigt wird?
Zitatattr Stromzaehler interval 60
attr Stromzaehler pollingMode on
Nimm das mal raus.
Polling bringt nur bei Zählern was, die die Daten nicht von selbst senden sondern eine eigene Aufforderung dazu benötigen.
lg, Stefan
ich denke, das ist mein altbekanntes Problem https://forum.fhem.de/index.php/topic,50905.msg425379.html#msg425379, welches ich leider immer noch nicht gelöst habe. Schon lustig, wenn man morgens die Kaffeemaschine einschaltet und während der Wartezeit den Leistungsplot aufruft, der dann nur ein paar Watt anzeigt. Man denkt man schläft noch. ;D
Dass das cat die Schnittstelle leert ist gut zu wissen. Das probier ich mal aus. Vielleicht ein Weg zur Lösung...
Grüße Markus
Edit: Schachti, welchen Chip hast Du im USB/RS232-Wandler ?
Das führt dazu, dass die Readings scheinbar nicht aktualisiert werden, und im Log steht das:
2017.02.22 21:36:43 3: Opening Stromzaehler device /dev/ttyUSB0
2017.02.22 21:36:43 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:36:43 3: Init done
2017.02.22 21:36:43 3: Stromzaehler device opened
2017.02.22 21:36:52 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.02.22 21:36:52 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 233.
2017.02.22 21:36:52 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:36:52 3: Init done
2017.02.22 21:36:52 1: /dev/ttyUSB0 reappeared (Stromzaehler)
2017.02.22 21:36:54 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.02.22 21:36:54 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:36:54 3: Init done
2017.02.22 21:36:54 1: /dev/ttyUSB0 reappeared (Stromzaehler)
2017.02.22 21:36:56 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.02.22 21:36:56 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:36:56 3: Init done
2017.02.22 21:36:56 1: /dev/ttyUSB0 reappeared (Stromzaehler)
2017.02.22 21:37:00 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.02.22 21:37:00 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:37:00 3: Init done
2017.02.22 21:37:00 1: /dev/ttyUSB0 reappeared (Stromzaehler)
2017.02.22 21:37:02 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.02.22 21:37:02 3: Setting Stromzaehler serial parameters to 9600,7,E,1
2017.02.22 21:37:02 3: Init done
KölnSolar: wie finde ich das heraus?
Hast du nur die Attribute gelöscht?
Probier mal bitte einen Neustart von FHEM.
Will nicht ausschließen, dass es mit einem gelöschten PollingMode Probleme gibt (wobei ich mir aber nicht vorstellen kann, weshalb).
Das hat geklappt, bekomme jetzt alle 2 Sekunden neue Werte. Erhöht aber leider die CPU-Last.
ZitatPolling bringt nur bei Zählern was, die die Daten nicht von selbst senden sondern eine eigene Aufforderung dazu benötigen.
Stefan, Du verwirrst mich. Das hattest Du doch damals eingebaut, um genau das
ZitatErhöht aber leider die CPU-Last.
für unsere pushenden Zähler zu vermeiden ???
@schachi: Wenn Du lsusb in der Konsole(z. B. mit putty) eingibst, bekommst Du eine Liste Deiner USB-Geräte. Vermutlich ist der Wandler "Future..." oder "prolific.."
lsusb lirfert mir
ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Guten Morgen,
sorry Markus, du hast natürlich recht.
Polling bringt durchaus auch was bei pushenden Zählern.
Und eigentlich dürfte der Buffer auch nicht vollaufen :/
Kenn jemand bezugsquellen für Günstige RS232 Wandler, welche die Seriennummer übertragen?
Ich hab mir auf Amazon einen 4,99 bestellt, der bringt leider keine Seriennummer mit.
Ein weiter von Digitus für 10,99 überträgt sie.
Hab in letzter Zeit zwei geschossen und bin deshalb auf der Suche.
Gruß Robert
Aha, also ein CP210x-Chip, während ich den Prolific PL2303 verbaut habe. Den hatte damals jemand als grundsätzlich problematisch/fehleranfällig "deklassiert". Aber dann liegt das Problem wohl woanders. Da Du den Puffer(wo auch immer) mit cat leeren konntest, muss es aber vermutlich am Wandler-Rpi liegen. Du hast ihn doch an einem Rpi ?
Ja, ist ein Raspberry Pi Modell B mit Raspbian Jessie.
Hallo zusammen,
bei mir funktioniert das Auslesen nicht, kann mir bitte jemand helfen?
Der Zähler ist ein "DD3 BZ06" der Firma eBZ, der Lesekopf ein Weidmann-Emlog, der sollte baugleich zum Volkslesekopf sein.
Die grüne LED des Lesekopfes blinkt (langsam), die Definition in fhem lautet:
define sz OBIS /dev/ttyUSB-powermeter@9600,8,N,1
Das Device zeigt "opened" an, s. 1. Screenshot. Ein "verbose 5" erzeugt aber nichts im Log, die Readings bleiben leer bzw. es werden keine angezeigt.
Klicke ich auf "TYPE OBIS" erhalte ich die Ansicht des zweiten Screenshots. Die dort auftauchenden "565" stellen auch den aktuellen Zählerstand dar (s. 3. Screenshot).
Es scheint also etwas nicht ganz richtig konfiguriert zu sein.
Hat jemand eine Idee?
Gruß,
td
Das 2. Bild sieht ja schon fast richtig aus. Mir scheint, dass da noch was mit den seriellen Parametern im argen ist. Versuch mal das N durch E oder O und die 1 durch 0 oder 2 zu ersetzen. Oder der Lesekopf sitzt noch nicht korrekt ?
Im Inet findet sich leider keine Protokollbeschreibung :'(
Das sind typischer Bitfehler-Daten.
Ich tippe mal auf 7E1, bin mir aber nicht ganz sicher ^^
lg, Stefan
Hallo KölnSolar und Icinger!
Danke, es war 7E0!
Internals:
CHANGED
DEF /dev/ttyUSB-powermeter@9600,7,E,0
DeviceName /dev/ttyUSB-powermeter@9600,7,E,0
FD 4
MeterType Standard
NAME sz
NR 709
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-03 19:49:07 0.0.96.8.0.255 0033E4EF
2017-03-03 19:49:06 1.0.0.0.0.255 95-61-05-1
2017-03-03 19:49:07 1.0.36.7.0.255 151.04
2017-03-03 19:49:07 1.0.56.7.0.255 259.33
2017-03-03 19:49:07 1.0.76.7.0.255 311.36
2017-03-03 19:49:06 1.0.96.1.0.255 1EBZ0100010492
2017-03-03 19:49:07 1.0.96.5.5.255 001C-0104
2017-03-03 19:43:41 Version EBZ5DD3BZ06ETA_105
2017-03-03 19:49:07 power 721.73
2017-03-03 19:48:58 state opened
2017-03-03 19:49:07 total_consumption 567.72194582
Helper:
BUFFER
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1488566938.32587
Channels:
DEVICES:
-1
Attributes:
Interessant, da ich die 8N1 mit dem Testprogramm unter Windows ermittelt hatte.
Leider finde ich nicht für alle Channels online eine Erläuterung, z. B. "1.0.96.5.5.255". Hat da jemand eine Übersicht?
Gruß,
td
Hmm, 7E0 hatte ich noch nie :D
Hier: http://www.itrona.ch/stuff/F2-2_PJM_5_Beschreibung%20SML%20Datenprotokoll%20V1.2_26.04.2011.pdf (http://www.itrona.ch/stuff/F2-2_PJM_5_Beschreibung%20SML%20Datenprotokoll%20V1.2_26.04.2011.pdf)
gibts zwar eine ziemlich ausführliche Beschreibung, dein 96.5.5 ist allerdings nicht dabei.
Die 96..... sind meist herstellerabhängige Readings. Sieht für mich nach irgendeiner Software-Versionsnummer oder sowas aus.
lg, Stefan
Hallo,
ich habe diesen Zähler:
http://wiki.volkszaehler.org/doku.php?id=hardware:channels:meters:power:edl-ehz:easymeter_q3c
(http://wiki.volkszaehler.org/doku.php?id=hardware:channels:meters:power:edl-ehz:easymeter_q3c)
Ich kann nur die Info-Schnittstelle nutzen.
Laut Erklärung muss folgendes getan werden:
Wird die Info-Schnittstelle abgefragt, muss der Zähler mittels Initialisierungssequenz (in HEX) aufgefordert werden seine Daten zu senden.
"pullseq": "1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241",
Ich sehe das im 47_OBIS wohl schon sowas angedacht war:
Da unter der sub OBIS_Initialize($) folgende Strings aufgelistet sind:
#1B1B1B1B010101017605002605426200620072630101760107FFFFFFFFFFFF05000CAC6C0B0A01454D4800005A561C726201640DF29B620163676F0076050026054362006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29B7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29B621E52FF6404AB760177070100020800FF01726201640DF29B621E52FF6324910177070100100700FF0101621B52005301360101016373F100760500260544620062007263020171016326A3000000001B1B1B1B1A03CDC9
#1B1B1B1B010101017605002605456200620072630101760107FFFFFFFFFFFF05000CAC6D0B0A01454D4800005A561C726201640DF29C62016343D30076050026054662006200726307017707FFFFFFFFFFFF0B0A01454D4800005A561C070100620AFFFF726201640DF29C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800005A561C0177070100010800FF641C0104726201640DF29C621E52FF6404AB770177070100020800FF01726201640DF29C621E52FF6324910177070100100700FF0101621B520053012C0101016319F6007605002605476200620072630201710163955D000000001B1B1B1B1A0310B4
Ich hatte gedacht das man das hier irgendwie einbauen kann?
# Update-Routine
sub GetUpdate($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
my $type= $hash->{MeterType};
RemoveInternalTimer($hash);
$hash->{helper}{EoM}=-1;
if ($hash->{helper}{DEVICES}[1] eq "") {return undef;}
if( $init_done ) {
DevIo_SimpleWrite($hash,$hash->{helper}{DEVICES}[0],undef) ;
hier--> DevIo_SimpleWrite -->1B1B1B1B0101010 .....",
Log3 $hash,4,"Wrote $hash->{helper}{DEVICES}[0]";
}
my $t=OBIS_adjustAlign($hash,AttrVal($name,"alignTime",undef),$hash->{helper}{DEVICES}[1]);
Log3 ($hash,5,"OBIS ($name) - Internal timer set to ".FmtDateTime($t)) if ($hash->{helper}{DEVICES}[1]>0);
InternalTimer($t, "GetUpdate", $hash, 1) if ($hash->{helper}{DEVICES}[1]>0);
}
aber leider kenne ich mich nicht mit der Syntax aus.
oder kommt es einfach in den initstring rein?
my %devs= (
# Name, Init-String, interval, 2ndInit
"none" => ["", -1, ""],
"Unknown" => ["", -1, ""],
"SML" => ["", -1, ""],
hier--> "SMLPULL" => ["1B1B1B1B0101010 .....", -1, ""],
"Ext" => ["", -1, ""],
"Standard" => ["", -1, ""],
"VSM102" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E110" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E350USB" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
);
Ich vermute das ein neuer Devicetyp hinzugefügt werden muss da man ja für die selbst sendende Zähler keinen Init senden möchte.
--> Ich hab jetzt schon einige Zeit mit fhem "verdaddelt" und nach Eltako Bus , Fritzbox Dect 200,und Viessmann Heizung fehlt vorerst noch der Stromzähler
Kann mir jemand helfen und das einbauen?
Bzw. mich Anleiten mit ein Paar Codesschnipseln.
Und Entschuldigung wenn dieses Thema irgendwo schon behandelt wurde. Ich habe ein Weilchen gesucht aber leider nichts gefunden.
ach ja falls jemand nach der Config fragt :-)
define EasymeterQ3C OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ZENSIERT-if00-port0@9600,8,N,1 SML
attr EasymeterQ3C channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
attr EasymeterQ3C interval 5
attr EasymeterQ3C pollingMode on
attr EasymeterQ3C room Interface
attr EasymeterQ3C unitReadings on
Viele Grüße
Robert
Hallo Robert,
bitte nicht falsch verstehen, aber diese Info von Volkszähler kann imho nicht ganz stimmen (lasse mich aber gern eines besseren belehren)
1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241
Das ist ein gültiger SML-Datensatz.
Wenn das wirklich stimmt, war dein Ansatz schon richtig, du könntest einen zusätzlichen Metertype definieren.
Also:
"VSM102" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E110" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"EMq3c" => ["1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241", 600, ""],
"E350USB" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
Versuchs mal bitte und gib Bescheid. Wenns funktioniert, binde ich den offiziell ein.
Finde leider nicht wirklich irgendwelche weiterführenden Infos zu dem Zähler.
lg, Stefan
Hey Stefan,
Danke für so schnelle Antwort! Leider klappt das nicht so.
wenn ich das so einstelle, sehe ich den Weidmann IR-Schreibkopf alle 5 Sekunden blinken (obwohl in der Anleitung gar keine LED zur Kontrolle beschrieben ist).
Ich sehe also, dass alle 5 Sekunden etwas passiert.
Halte ich den Schreib Lesekopf in die Luft blinkt die Kontrollleuchte nicht. Halte ich sie wieder an den Zähler beginnt es zu blinken.
(Allerdings beginnt sie wohl auch immer direkt an Oberflächen zu blinken)
Ich erhalte keine readings aber einen Buffer der wohl alle 5 Sekunden wächst.
Original Einstellungen vs
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ZENSIERT-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ZENSIERT-if00-port0@9600,8,N,1
MeterType SML
NAME EasymeterQ3C
NR 177
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-08 18:58:45 state opened
Helper:
EoM -1
SPEED 5
SPEED2 5
TRIGGERTIME 1488999525.21585
Channels:
1 energy_current
1.7 Aktuelle_Leistung
1.8 energy_total
2.8 feed_total
21 energy_L1
31 power_L1
41 energy_L2
51 power_L2
61 energy_L3
71 power_L3
DEVICES:
5
Attributes:
channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
interval 5
pollingMode on
room Interface
unitReadings on
und nun mit der neuen Einstellung:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ZENSIERT-if00-port0@9600,8,N,1 EMq3c
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ZENSIERT-if00-port0@9600,8,N,1
FD 4
MeterType EMq3c
NAME EasymeterQ3C
NR 177
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-08 19:04:35 state opened
Helper:
BUFFER 1bb011700060027650000700193331362001603607303600725007070100131c0603206207600001675d000b11b072111bb101107336206072500170113313338630110633306331260026007071100131cb0030206207600000116756d0000001b11a741b1b100110300020765000070091331336200116067030600207500700011003c00633220606000071167d0000b11ba071bb1110016330206206000077100133113321001036003016027650000500106340763332060020002071376d001bb11a2741bb11110016330206026000077103113313321001303060301062076000005011064b076332060250002713760001bb1a274
EoM -1
SPEED 5
SPEED2 5
TRIGGERTIME 1488999849.19654
Channels:
1 energy_current
1.7 Aktuelle_Leistung
1.8 energy_total
2.8 feed_total
21 energy_L1
31 power_L1
41 energy_L2
51 power_L2
61 energy_L3
71 power_L3
DEVICES:
1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241
5
Attributes:
channels {"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
interval 5
pollingMode on
room Interface
unitReadings on
meinst du das das irgendwelche Empfangsdaten sind oder nur Fehler oder Reflexionen?
Kannst du weiterhelfen oder soll ich erstmal versuchen die Software vom volkszähler zu installieren?
Viele Grüße
Robert
Hmm, ich kann zwar an den Daten im Buffer sehen, dass sie sich wiederholen, daher glaube ich nicht so sehr an Reflexionen.
Kann aber auch leider keine wie auch immer gearteten OBIS-Daten erkennen :(
Wieso kannst du nicht an die obere Schnittstelle ran (zumindest testweise)? Die sollte doch regelmäßig automatisch die Daten senden.
Dann wäre mal geklärt, ob der eh in OBIS sendet (wovon ich eigentlich schon ausgehe)
lg, Stefan
Hi,
die obere Schnittstelle ist versiegelt. Angeblich kann man mit der oberen Schnittstelle Tag und Nacht Zähler umschalten ...
Also würde ich ungern das Siegel entfernen ;-)
Hmm ich bin am überlegen vielleicht komme ich am Wochenende mal dazu mir das genauer anzuschauen.
Danke auf jeden Fall!!!
ZitatDie Zählergehäuse sind verschweißt und als ,,Sealed-forever" Geräte ausgeführt.
Hinweis: Die mechanischen Schnittstellen, die Spannungsschnittstellen und die D0-Schnittstelle sind nicht patentiert oder herstellerseitig geschützt. Auf Wunsch werden weitere Detailzeichnungen und Spezifikationen zur Verfügung gestellt.
Die Geräte weisen eine bidirektionale D0-Schnittstelle nach DIN EN 62056 auf, welche Daten in Form des SML-Protokolls ausgibt (Smart Message Language).
Zitat
6.1.2 Info-Schnittstelle
Der Zähler verfügt über eine für den Endkunden zugängliche potentialfreie optische Datenschnittstelle (INFO-DSS).
Diese optische Datenschnittstelle ist eine bidirektionale, infrarote Kommunikationsschnittstelle und dient folgenden Aufgaben:
• zur Ausgabe der abrechungsrelevanten Messwerte (auf Anforderung)
• zur Ausgabe der Zähleridentifikation
ZitatUnidirektionale Info-Schnittstelle
• Pull-Betrieb, Datenabfrage über Get List Kommando
• Umschaltbar in den Impulsbetrieb (für Messzwecke)
habe folgendes in einem Forum gefunden:
https://www.photovoltaikforum.com/freesol-f113/freesol-sml-s0-ueber-easymeter-q3c-info-schnittste-t78192-s20.html
Zitatvon uweklatt » 03.01.2013, 14:19
Hallo,
hier das Ergebnis der Kommunikationsversuche an der Frontschnittstelle des Easymeter Q3C:
Mit einem "vernünftigen" Lesekopf ist es möglich, zumindest die abrechnungsrelevanten Daten auszulesen.
Wie schon geschrieben, muss dazu eine korrekte SML-Datei gesendet werden.
Im konkreten Fall sieht diese wie folgt aus:
1b 1b 1b 1b 01 01 01 01 76 03 30 30 62 00 62 00 72 65 00 00 01 00 77 01 01 09 31 31 33 31 31 38 36 32 01 01 01 01 63 03 36 00 76 03 30 31 62 00 62 00 72 65 00 00 07 00 75 01 01 01 01 01 63 14 cb 00 76 03 30 32 62 00 62 00 72 65 00 00 02 00 71 01 63 75 6d 00 00 00 1b 1b 1b 1b 1a 02 72 41
Nach dem Senden mit 9600 Baud 8N1 antwortet der Zähler mit einer SML-Datei, die wie beim Q3B zu verarbeiten ist.
Ich hoffe, mein Beitrag zu FreeSol bzw. Volkszaehler.org hilft weiter.
Tschau
Uwe
Hast du eine Ahnung ob genau das dein initstring machen sollte?
Grüße Robert
Hi Robert,
hmm, hab jetzt mal ein wenig weitergegoogelt.
Also soweit ich >Daten dazu finde, sollte das mit diesem Init-String schon so klappen.
Auch hier: https://www.photovoltaikforum.com/volkszaehler-org-f131/easymeter-q3c-auslesen-t111112.html (https://www.photovoltaikforum.com/volkszaehler-org-f131/easymeter-q3c-auslesen-t111112.html) hat das jemand so hinbekommen.
Setz das OBIS-Modul mal auf Verbose 5, dann siehst du im Log genauer, was über die Schnittstelle reinkommt. (Wird aber vmtl. nicht viel mehr sein, als eh im Buffer steht, aber man weiss ja nie ^^)
Ansonsten bin ich mom. bisschen ratlos, weil ich selbst keine Erfahrung mit IR-Schnittstellen habe. Mein Zähler hat nen direkten RS485-Ausgang.
lg, Stefan
hallo Stefan,
ich habe jetzt schon ein paar stunden Zeit verdaddelt und muss mich erstmal um andere Dinge kümmern.
Ich schaffe auf einfachen Wege keine Kommunikation mit dem Zähler.
Grundsätzlich hätte ich jetzt einfach gedacht, das nach dem Initstring-Aufruf tatsächlich eine SML Antwort folgt, die dann ganz Normal von deinem Modul interpretiert werden kann.
Aber ich bekomm nichts hin und als alter Windowsuser fehlt mir tatsächlich so eine einfache Anwendung wie hyperterminal. in dem ich eine Verbindung öffnen kann ich ein sende und ein Antwortfenster habe und dort einfach "spielen" kann.
Die Linux Welt ist mir da zu "kompliziert" und ich bekomm keine Ergebnisse.
Und wenn sich Nichtwissen(Linux minicom etc) mit Unwissenheit(Zähler, SML) paart kommt halt nichts raus.
Danke für die Hilfe ich melde mich dann ggf. später falls der Initstring so funzt.
#!/bin/bash
# read and evaluate SML output received from EMH eHZ
# set serial device
echo "r1"
INPUT_DEV="/dev/ttyUSB1"
#set $INPUT_DEV to 9600 8N1
#stty -F $INPUT_DEV 1:0:8bd:0:3:1c:7f:15:4:5:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
stty -F $INPUT_DEV 500:5:18b2:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
echo "r2"
SML_START_SEQUENCE="1B1B1B1B0101010176"
METER_OUTPUT__START_SEQUENCE=""
smlinitstring="1b1b1b1b010101017603303062006200726500000100770101093131333131383632010101016303360076033031620062007265000007007501010101016314cb007603303262006200726500000200710163756d0000001b1b1b1b1a027241"
#echo $smlinitstring > $INPUT_DEV
while [ "$METER_OUTPUT__START_SEQUENCE" != "$SML_START_SEQUENCE" ]
do
#echo $smlinitstring > $INPUT_DEV
METER_OUTPUT=`cat $INPUT_DEV 2>/dev/null | xxd -p -u -l 460`
METER_OUTPUT__START_SEQUENCE=$(echo "${METER_OUTPUT:0:18}")
if [ $METER_OUTPUT__START_SEQUENCE != $SML_START_SEQUENCE ];
then
echo METER_OUTPUT__START_SEQUENCE
echo "missed start and trying again..."
#exit 1
fi
echo "r3"
done
echo "r4"
let METER_180=0x${METER_OUTPUT:390:10}
VALUE=$(echo "scale=2; $METER_180 / 10000" |bc)
echo "Meter 1.8.0 (from plant): " $VALUE "kWh"
let METER_180=0x${METER_OUTPUT:347:10}
VALUE=$(echo "scale=2; $METER_180 / 10000" |bc)
echo "Meter 2.8.0 (to plant): " $VALUE "kWh"
let METER_180=0x${METER_OUTPUT:518:8}
VALUE=$(echo "scale=2; $METER_180 / 10" |bc)
echo "Total effective power (+/-): " $VALUE "W"
hatte mal das adaptiert aber er kommt nicht mal zum "r3" (die Baudraten habe ich mal angepasst)
Es sah mit verbose 5 so aus als ob mit 9600 8n1 dein OBIS sich ständig reconnectet und mit 300 7N1 die Verbindung nicht abbricht.
Grüße Robert
Hallo,
ich habe einen ACE3000 Typ 260. Zum testen habe ich einen RASPI frisch installiert. Der Lesekopf ist ein SChreibLesekopf von UDO aus dem VZ.
Das python Skirpt von dieser Seite
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/itron_ace3000_type_260 (http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/itron_ace3000_type_260)
läuft einwandfrei, saubere Ausgabe der 1.8.0 Werte.
FHEM habe ich nun so konfiguriert:
define Stromzaehler OBIS /dev/ttyUSB0@300,7,E,1 VSM102
attr Stromzaehler interval 60
attr Stromzaehler pollingMode on
attr Stromzaehler verbose 5
nachfolgendes im LOG (aus der putty console)
2017.03.26 21:50:46 5: OBIS (Stromzaehler) - Internal timer set to 2017-03-26 21:51:46
2017.03.26 21:50:51 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(0155/?!
2017.03.26 21:50:51 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.18
2017.03.26 21:50:51 5: SW: 063035300d0a
2017.03.26 21:50:51 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2017.03.26 21:50:51 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126120053234874)
2017.03.26 21:50:51 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
2017.03.26 21:50:53 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(015588.7*
@
!
2017.03.26 21:51:46 5: SW: 2f3f210d0a
2017.03.26 21:51:46 4: Wrote /?!
2017.03.26 21:51:46 5: OBIS (Stromzaehler) - Internal timer set to 2017-03-26 21:52:46
2017.03.26 21:51:51 5: OBIS (Stromzaehler) - Msg-Parse: /?!
2017.03.26 21:51:51 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.18
2017.03.26 21:51:51 5: SW: 063035300d0a
2017.03.26 21:51:51 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2017.03.26 21:51:51 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126120053234874)
2017.03.26 21:51:51 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
Dargestellt auf der Webpage von fhem sieht es so aus:
2017.03.26 23:16:03 5: OBIS (Stromzaehler) - Internal timer set to 2017-03-26 23:17:03
2017.03.26 23:16:08 5: OBIS (Stromzaehler) - Msg-Parse: /?!
2017.03.26 23:16:08 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.18
2017.03.26 23:16:08 5: SW: 063030300d0a
2017.03.26 23:16:08 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2017.03.26 23:16:08 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126120053234874)
2017.03.26 23:16:08 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
2017.03.26 23:16:13 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(015589.6*0
a!
2017.03.26 23:17:03 5: SW: 2f3f210d0a
2017.03.26 23:17:03 4: Wrote /?!
2017.03.26 23:17:03 5: OBIS (Stromzaehler) - Internal timer set to 2017-03-26 23:18:03
2017.03.26 23:17:08 5: OBIS (Stromzaehler) - Msg-Parse: /?!
2017.03.26 23:17:08 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.18
2017.03.26 23:17:08 5: SW: 063030300d0a
2017.03.26 23:17:08 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2017.03.26 23:17:08 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126120053234874)
2017.03.26 23:17:08 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
2017.03.26 23:17:13 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(015589.@
2017.03.26 23:17:13 5: OBIS (Stromzaehler) - Msg-Parse:
Die 1.8.0 Channel sind eigentlich fast immer Abgeschnitten, hin und wieder kommen diese auch richtig durch und es wurde bereits ein Channel angelegt.
Kann mir hier jemand weiterhelfen?
Kai
So bei mir geht es jetzt :)
Habe gerade diesen Thread rauf und runter gelesen und dann einfach mal am polling gedreht.
Zuerst hab ich es auf off gesetzt, dann ist das Stromzaehler Device immer reappeared und connected
2017.03.27 21:03:23 3: Init done
2017.03.27 21:03:23 1: /dev/ttyUSB0 reappeared (Stromzaehler)
2017.03.27 21:03:24 1: /dev/ttyUSB0 disconnected, waiting to reappear (Stromzaehler)
2017.03.27 21:03:24 3: Setting Stromzaehler serial parameters to 300,7,E,1
bringt mich also nicht weiter, aber dann habe ich das polling wieder auf on gesetzt und siehe da, (ich habe fhem nicht neu gestartet, ich habe nur in der WEB Oberfläche im Device den Wert geändert...
2017.03.27 21:15:12 5: OBIS (Stromzaehler) - Internal timer set to 2017-03-27 21:16:12
2017.03.27 21:15:12 5: OBIS (Stromzaehler) - Msg-Parse: /?!
2017.03.27 21:15:13 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.18
2017.03.27 21:15:13 5: SW: 063035300d0a
2017.03.27 21:15:13 5: OBIS (Stromzaehler) - Msg-Parse: 050
2017.03.27 21:15:15 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2017.03.27 21:15:16 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126120053234874)
2017.03.27 21:15:16 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
2017.03.27 21:15:17 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(015597.6*kWh)
2017.03.27 21:15:17 5: Msg 1.8.0(015597.6*kWh) is of type Counter
2017.03.27 21:15:17 5: OBIS (Stromzaehler) - Msg-Parse: !
es läuft..... Aber erklären kann ich es mir nicht....
So es läuft jetzt erstmal ganze 7 Minuten.... Falls es morgen wieder nicht geht meld ich mich....
Kai
Kai
Nabend zusammen,
nach dem ich mich jetzt mit volkszaehler und verschiedenen Skripten beschäftigt hatte, bin ich durch Zufall auf das OBIS Modul gekommen.
Die Middelware aus VZ ist für das Speichern meiner Zählerstände von HT und NT zu viel. Daher der Versuch das Modul von FHEM zum Reden zu bringen.
Soweit so gut:
Internals:
DEF /dev/ttyUSB0@300,7,E,1 SML
DeviceName /dev/ttyUSB0@300,7,E,1
FD 18
MeterType SML
NAME MyObis
NR 153
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-27 22:49:35 Version PAF5EC3r000
2017-03-28 00:07:30 state opened
Helper:
BUFFER /PAF5EC3r000
/PAF5EC3r000
/PAF5EC3r000
/PAF5EC3r000
/PAF5EC3r000
EoM -1
SPEED 0
SPEED2 0
TRIGGERTIME 1490652450.4796
DEVICES:
/?!
5
Attributes:
interval 5
pollingMode on
verbose 5
Ich habe ebenfalls einen USB-Lesekopf von Weidmann Elektronik. Der Lesekopf wird als ttyUSB0 angesprochen und funktioniert mit meinem Pafal 20ec3gr und einem Pi mit VZ Image einwandfrei.
Ebenso das Shell Skript von VZ http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/pafal-20ec3gr (http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/pafal-20ec3gr) liefert mir die nötigen Daten:
14 <> /PAF5EC3r000
uuid=c5a6a760-1332-11e7-xxxxx-efa29cac46d9 , key=1.8.0, pos=4, len=9
1.8.0 =
c5a6a760-1332-11e7-xxxxx-efa29cac46d9 : 0
255 <> 0.0.0(70922339)
0.0.1(PAF)
F.F(00)
0.2.0(1.27)
C.5(10000)
1.8.0*00(026094.92)
1.8.1*00(016996.69)
1.8.2*00(009098.23)
1.8.3*00(000000.00)
1.8.4*00(000000.00)
1.8.1*01(000000.00)
1.8.2*01(000000.00)
1.8.3*01(000000.00)
1.8.4*01(000000.00)
1.
uuid=c5a6a760-1332-11e7-xxxxxx-efa29cac46d9 , key=1.8.0, pos=4, len=9
1.8.0 = 1.8.0*00(026094.92)
1.8.1*00(016996.69)
1.8.2*00
c5a6a760-1332-11e7-xxxxxx-efa29cac46d9 : 26094920
255 <> 8.1*02(000000.00)
1.8.2*02(000000.00)
1.8.3*02(000000.00)
1.8.4*02(000000.00)
1.6.0*00(00.0000)(00:00:00,00-00-00)
1.6.0*01(00.0000)(00:00:00,00-00-00)
0.1.2*01(00:00:00,00-00-00)
1.35(00.0000)
1.35.90*00(0000.0000)
1.36.90*00(00000)(000000000000
uuid=c5a6a760-1332-11e7-xxxxxx-efa29cac46d9 , key=1.8.0, pos=4, len=9
1.8.0 = 0
c5a6a760-1332-11e7-xxxxx-efa29cac46d9 : 0
167 <> 0000)
1.36.90*01(00000)(0000000000000000)
1.2.0(0000.0000)
0.1.0(00000)
C.2.1(01040B140A0B)( )
0.2.2(::::::::)!
uuid=c5a6a760-1332-11e7-xxxxx-efa29cac46d9 , key=1.8.0, pos=4, len=9
1.8.0 =
c5a6a760-1332-11e7-xxxxx-efa29cac46d9 : 0
Das OBIS Modul liefert mit trotz "Connected" zur Schnittstelle im Verbose 5 Log nur ein:
2017.03.28 00:07:22 5: OBIS (MyObis) - Internal timer set to 2017-03-28 00:07:27
2017.03.28 00:07:27 5: SW: 2f3f210d0a
2017.03.28 00:07:27 4: Wrote /?!
Ich verstehe es nicht.. :-X. Es Handelt sich um einen d0 Zähler der OBIS Daten bereitstellt. Das sehe ich jedenfalls auch im
Log der Volkszaehlerskripte:
[Mar 28 00:05:25][d0] Parsed reading (OBIS code=0.2.2, value=::::::::, unit=)
[Mar 28 00:05:25][d0] Read package with 29 tuples (vendor=PAF, baudrate=5, identification=EC3r000)
[Mar 28 00:05:25][mtr0] Got 29 new readings from meter:
[Mar 28 00:05:25][mtr0] Reading: id=255-255:0.0.0*255/ObisIdentifier:255-255:0.0.0*255 value=70922339.00 ts=1490652297238
[Mar 28 00:05:25][mtr0] Reading: id=255-255:0.0.1*255/ObisIdentifier:255-255:0.0.1*255 value=0.00 ts=1490652297841
[Mar 28 00:05:25][mtr0] Reading: id=255-255:97.97.255*255/ObisIdentifier:255-255:97.97.255*255 value=0.00 ts=1490652298344
[Mar 28 00:05:25][mtr0] Reading: id=255-255:0.2.0*255/ObisIdentifier:255-255:0.2.0*255 value=1.27 ts=1490652298982
[Mar 28 00:05:25][mtr0] Reading: id=255-255:96.5.255*255/ObisIdentifier:255-255:96.5.255*255 value=10000.00 ts=1490652299586
[Mar 28 00:05:25][mtr0] Reading: id=255-255:1.8.0*0/ObisIdentifier:255-255:1.8.0*0 value=26094.92 ts=1490652300495
[Mar 28 00:05:25][mtr0] Reading: id=255-255:1.8.1*0/ObisIdentifier:255-255:1.8.1*0 value=16996.69 ts=1490652301415
[Mar 28 00:05:25][mtr0] Reading: id=255-255:1.8.2*0/ObisIdentifier:255-255:1.8.2*0 value=9098.23 ts=1490652302335
Kann mir vielleicht jemand noch den entscheidenden Tipp für die richtige Richtung geben?
Danke und Grüße!
Dirk
Zitat von: Devender am 28 März 2017, 00:17:47
Das OBIS Modul liefert mit trotz "Connected" zur Schnittstelle im Verbose 5 Log nur ein:
2017.03.28 00:07:22 5: OBIS (MyObis) - Internal timer set to 2017-03-28 00:07:27
2017.03.28 00:07:27 5: SW: 2f3f210d0a
2017.03.28 00:07:27 4: Wrote /?!
Hallo Dirk,
dieser merkwürdige Zähler brauch nach dem Schreiben von " /?!" und einer Wartezeit von ca. 2sek einen zweiten String zum Abrufen der Daten.
Zitat"pullseq": "2F3F210D0A"
"ackseq": "063030300D0A"
Gruß Friedrich
In der sub Obis_Init im 47_OBIS.pm steht der loglevel auf 3, damit log der Obis alle paar Sekunden ein InitDone ins Logfile, aber nur wenn der Polling Mode off gesetzt ist, m.E. wäre hier ein Log 6 angenehmer oder nur beim ersten mal ein log 3....
sub OBIS_Init($)
{
Log 3,"Init done";
return undef;
}
eigentlich ist das ja auch noch das alte logformat:
https://forum.fhem.de/index.php/topic,14341.0.html (https://forum.fhem.de/index.php/topic,14341.0.html)
müsste dann ja eigentlich lauten:
sub OBIS_Init($)
{
Log3 undef, 6,"Init done";
return undef;
}
Kai
Zitat von: Omega-5 am 28 März 2017, 09:45:40
Hallo Dirk,
dieser merkwürdige Zähler brauch nach dem Schreiben von " /?!" und einer Wartezeit von ca. 2sek einen zweiten String zum Abrufen der Daten.
Gruß Friedrich
Hallo Friedrich,
danke für deine Antwort.
Die Werte pullseq": "2F3F210D0A" und "ackseq": "063030300D0A" sind ja Bestandteil des vzconfig files.
Mit welchem Attribute muesste ich diese im OBIS Modul einbinden oder im Modul selbst ein weiteren Triggern anstossen?
Ich glaube ich stehe da gerade auf dem Schlauch. :-[.
Laut Beschreibungen handelt es sich wohl um einen Zähler der nur auf Anfrage plaudert. Merkt man allerdings beim Betrieb mit VZ nicht. Es scheint ein gängiger Zaehler bei einem Zweitarifbezug (also HT/NT) zu sein den die eon damals eingebaut haben.
Gruesse,
Dirk
Guten Morgen,
hmm, grundsätzlich sende ich ja die beiden Init-Strings, allerdings hatte ich bisher noch nie die Anforderung, dazwischen 2 sek. zu warten.
Ich lass mir was einfallen und Dirk bekommt in den nächsten Tagen mal ne Testversion mit Delay und einem neuen MeterType.
lg, Stefan
Danke dir Stefan!
:D
Hallo,
ich habe es auch nur von hier: https://www.symcon.de/forum/threads/31166-Stromz%C3%A4hler-Pafal-20EC3gr-auslesen (https://www.symcon.de/forum/threads/31166-Stromz%C3%A4hler-Pafal-20EC3gr-auslesen)
und irgendwo stand, ich finde es im Moment nur nicht mehr, der Zähler ist seeeeehr langsam. >:(
Gruß Friedrich
Zitat von: Omega-5 am 29 März 2017, 13:02:47
Hallo,
ich habe es auch nur von hier: https://www.symcon.de/forum/threads/31166-Stromz%C3%A4hler-Pafal-20EC3gr-auslesen (https://www.symcon.de/forum/threads/31166-Stromz%C3%A4hler-Pafal-20EC3gr-auslesen)
und irgendwo stand, ich finde es im Moment nur nicht mehr, der Zähler ist seeeeehr langsam. >:(
Gruß Friedrich
Danke!
Jetzt habe ich das mit den 2 Sec kapiert. Den Thread kannte ich nicht nicht. Und ich habs in dem Shellskript von VZ auch gefunden, dass er kurz wartet und erneut sendet.
Und ja das teil ist langsam. Meine Testdatei braucht mehr als 10Sec für die Ausgabe...
Naja, in dem Thread steht ja eigentlich, dass der zweite Initstring INNERHALB von 2 sec kommen muss.
Das ist bei den Smwartmetern eh so standard. Kommt in 2 sec nix, muss man mit dem ersten Initstring wieder beginnen.
Sollte soweit also stimmmen.
@Devender:
Mir ist aber grade was anderes aufgefallen:
/dev/ttyUSB0@300,7,E,1 SML
Dein Zähler sendet nicht in SML, sondern in Klartext.
Ändere dein Define bitte mal auf
/dev/ttyUSB0@300,7,E,1 VSM102
Damit sollte es dann klappen, denke ich.
lg, Stefan
Hallo Stefan,
ich habe das DEF jetzt mal auf VSM102 gesetzt. Allerdings bekomme ich weiterhin keine verwertbaren Werte.
2017.03.30 10:06:55 5: OBIS (MyObis) - Internal timer set to 2017-03-30 10:07:05
2017.03.30 10:07:00 5: OBIS (MyObis) - Msg-Parse: ~~|}z}xxx
~z~ /PAF5EC3r000
2017.03.30 10:07:00 5: SW: 063035300d0a
2017.03.30 10:07:05 5: SW: 2f3f210d0a
2017.03.30 10:07:05 4: Wrote /?!
2017.03.30 10:07:05 5: OBIS (MyObis) - Internal timer set to 2017-03-30 10:07:15
2017.03.30 10:07:07 5: OBIS (MyObis) - Internal timer set to 2017-03-30 10:09:07
2017.03.30 10:07:07 5: OBIS (MyObis) - Msg-Parse: /PAF5EC3r000
2017.03.30 10:07:07 5: SW: 063035300d0a
2017.03.30 10:09:07 5: SW: 2f3f210d0a
2017.03.30 10:09:07 4: Wrote /?!
2017.03.30 10:09:07 5: OBIS (MyObis) - Internal timer set to 2017-03-30 10:11:07
2017.03.30 10:09:12 5: OBIS (MyObis) - Msg-Parse: x~J
JGD/PAF5EC3r000
2017.03.30 10:09:12 5: SW: 063035300d0a
Ich habe mich auch noch mal durch alle 23 Seiten gelesen und dort auch Mitstreiter mit einem Parfal gefunden.
Bei https://forum.fhem.de/index.php/topic,51948.msg451815.html#msg451815 war ich mir fast sicher, dass es bei mir klappen könnte.
Daher habe ich das attr channels wie folgt gesetzt:
{"1.8.1"=>"Bezug_HT","1.8.2"=>'Bezug_NT,"1.8.0"=>'Bezug_Gesamt"}
Leider hat das auch nicht funktioniert. Der User dbox2user hat wohl auch eine "andere" Version vom Zähler:
Er hat: PAF5EC3g00006
Ich habe: PAF5EC3r000
Hatte mir gestern Abend auch noch mal die Ausgabe des Shell zu gemüte geführt. Da ich bei perl noch blütiger Anfänger bin traue ich mich nicht in deinem Modul zu experimentieren :-X
Das Shell gibt jedesmal sowas aus:
14 <> /PAF5EC3r000
uuid=c5a6a760-xxxx-11e7-a45e-efa29cac46d9 , key=1.8.0, pos=4, len=9
1.8.0 =
c5a6a760-xxxx-11e7-a45e-efa29cac46d9 : 0
255 <> 0.0.0(70922339)
0.0.1(PAF)
F.F(00)
0.2.0(1.27)
C.5(10000)
1.8.0*00(026108.52)
1.8.1*00(017004.40)
1.8.2*00(009104.12)
Könntes es sein, dass sich dein Modul an Zeilenumbrüchen verschluckt?
Im obigen Log sieht es ja auch etws mysteriös aus:
2017.03.30 10:07:00 5: OBIS (MyObis) - Msg-Parse: ~~|}z}xxx
~z~ /PAF5EC3r000
Ich hatte gestern noch schnell per Skript / grep und sed die Zeilen 12-14 formatiert ausgeben lassen. Das funktioniert problemlos, da die Werte - die ich brauche - auch immer in der selben Zeile stehen.
Ich hoffe du kannst mit den kryptischen Daten was anfangen ;)
Grüße,
Dirk
Hallo zusammen,
ich habe den gleichen Zähler wie Devender und hatte bis zum Update vom 23.03.2017 keine Probleme.
Nach dem Update werden die Werte nicht mehr aktualisiert. Eventuell hilft es mal die 47_OBIS.pm vom Januar einzuspielen?
Beste Grüße,
Blixman
Zitat von: Blixman am 31 März 2017, 07:41:40
Hallo zusammen,
ich habe den gleichen Zähler wie Devender und hatte bis zum Update vom 23.03.2017 keine Probleme.
Nach dem Update werden die Werte nicht mehr aktualisiert. Eventuell hilft es mal die 47_OBIS.pm vom Januar einzuspielen?
Beste Grüße,
Blixman
Hallo Blixman,
das war der richtige Tipp! Super, vielen Dank. :)
Nach dem ich eine Version aus meiner Sicherung vom
15.03.2017 eingespielt habe werden die Daten meines Zählers abgerufen.
In dieser Version gibt es auch noch kein GET als Implementierung.
@Blixman
Vielleicht kannst du mir noch ein List deines Device posten. Denn aktuell ließt OBIS alle Daten (HT/NT/Gesamt)
2017.03.31 09:46:12 5: OBIS (MyObis) - Msg-Parse: 1.8.0*00(026109.51)
2017.03.31 09:46:12 5: Msg 1.8.0*00(026109.51) is of type Counter
2017.03.31 09:46:13 5: OBIS (MyObis) - Msg-Parse: 1.8.1*00(017005.25)
2017.03.31 09:46:13 5: Msg 1.8.1*00(017005.25) is of type Counter
2017.03.31 09:46:14 5: OBIS (MyObis) - Msg-Parse: 1.8.2*00(009104.26)
2017.03.31 09:46:14 5: Msg 1.8.2*00(009104.26) is of type Counter
aus; überschreibt HT/NT aber beim zweiten Durchlauf wieder mit 0-Werten.
Grund hierfür ist, dass der Zähler im Log sowas ausgibt:
2017.03.31 09:46:17 5: Msg 1.8.1*[b]01[/b](000000.00) is of type Counter
2017.03.31 09:46:18 5: OBIS (MyObis) - Msg-Parse: 1.8.2*01(000000.00)
2017.03.31 09:46:18 5: Msg 1.8.2*[b]01[/b](000000.00) is of type Counter
2017.03.31 09:46:19 5: OBIS (MyObis) - Msg-Parse: 1.8.3*01(000000.00)
2017.03.31 09:46:19 5: Msg 1.8.3*01(000000.00) is of type Counter
2017.03.31 09:46:20 5: OBIS (MyObis) - Msg-Parse: 1.8.4*01(000000.00)
2017.03.31 09:46:20 5: Msg 1.8.4*01(000000.00) is of type Counter
Also ein zweites Reading mit *01.
Ich habe versucht mein Channel Regex nochmal anzupassen was allerdings nicht funktioniert hat, da das "*" als Wildcard im Regex fungiertMit dem attr Channels :
{"1.8.1*00"=>"Bezug_HT","1.8.2*00"=>"Bezug_NT","1.8.0*00"=>"Bezug_Gesamt"}Funktioniert die Anzeige der Readings. Die Readings werden neu angelegt und dort der Wert gespeichert. Passt also :-)
Hier mein aktuelles List:
Internals:
CHANGED
DEF /dev/ttyUSB0@300,7,E,1 VSM102
DeviceName /dev/ttyUSB0@300,7,E,1
FD 17
MeterType VSM102
NAME MyObis
NR 152
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-31 09:52:10 0.0.1 PAF
2017-03-31 09:52:34 0.1.0 0
2017-03-31 09:52:28 0.1.2.01 00:00:00,00-00-00
2017-03-31 09:52:11 0.2.0 1.27
2017-03-31 09:52:28 1.35 0
2017-03-31 09:52:29 1.35.90.00 0
2017-03-31 09:52:31 1.36.90.00 0
2017-03-31 09:52:32 1.36.90.01 0
2017-03-31 09:52:25 1.6.0.00 00:00:00,00-00-00
2017-03-31 09:52:26 1.6.0.01 00:00:00,00-00-00
2017-03-31 09:52:36 C.2.1
2017-03-31 09:52:12 C.5 0
2017-03-27 22:49:35 Version PAF5EC3r000
2017-03-31 09:52:33 power 0
2017-03-31 09:40:35 state opened
2017-03-31 09:52:12 total_consumption 26109.51
2017-03-31 09:52:21 total_consumption_Ch1 0
2017-03-31 09:52:22 total_consumption_Ch2 0
2017-03-31 09:52:22 total_consumption_Ch3 0
2017-03-31 09:52:23 total_consumption_Ch4 0
Helper:
BUFFER
EoM 0
SPEED 0
SPEED2 0
TRIGGERTIME 1490946035.74906
Channels:
1.8.0*00( Bezug_Gesamt
1.8.1*00( Bezug_HT
1.8.2*00( Bezug_NT
DEVICES:
/?!
30
000
Attributes:
channels {"1.8.1\*00("=>"Bezug_HT","1.8.2\*00("=>"Bezug_NT","1.8.0\*00("=>"Bezug_Gesamt"}
interval 30
pollingMode on
verbose 0
Vielen Dank!
Dirk
Hallo Devender,
anbei das von dir gewünschte List :
Internals:
CHANGED
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_Strom1-if00-port0@300,7,E,1 VSM102
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_Strom1-if00-port0@300,7,E,1
FD 11
MeterType VSM102
NAME Heizung
NR 30
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-03-31 10:31:44 0.0.1 PAF
2017-03-31 10:31:44 0.2.0 1.29
2017-03-31 10:31:45 C.2.1
2016-12-06 16:46:34 Version PAF5EC3g00006
2017-03-31 07:31:35 state opened
2017-03-31 10:31:44 total_consumption_Ch1 3998.38
2017-03-31 10:31:44 total_consumption_Ch1_CounterCurrent 3998.380
2017-03-31 00:03:36 total_consumption_Ch1_CounterDay1st 3996.840
2017-03-31 00:03:36 total_consumption_Ch1_CounterDayLast 3996.840
2016-12-14 12:28:07 total_consumption_Ch1_CounterMeter1st 2919.09
2016-12-14 12:28:07 total_consumption_Ch1_CounterMeterLast 2918.940
2017-03-01 00:10:08 total_consumption_Ch1_CounterMonth1st 3827.280
2017-03-01 00:10:08 total_consumption_Ch1_CounterMonthLast 3827.280
2016-12-14 12:28:07 total_consumption_Ch1_CounterYear1st 2919.09
2016-12-14 12:28:07 total_consumption_Ch1_CounterYearLast 2918.940
2017-03-31 10:31:44 total_consumption_Ch1_EnergyCostDay 0.377
2017-03-31 00:03:36 total_consumption_Ch1_EnergyCostDayLast 0.519
2017-03-31 10:31:44 total_consumption_Ch1_EnergyCostMeter 264.318
2017-03-31 10:31:44 total_consumption_Ch1_EnergyCostMonth 41.902
2017-03-01 00:10:08 total_consumption_Ch1_EnergyCostMonthLast 67.884
2017-03-31 10:31:44 total_consumption_Ch1_EnergyCostYear 264.318
2017-03-31 10:31:44 total_consumption_Ch1_EnergyDay 1.540
2017-03-31 00:03:36 total_consumption_Ch1_EnergyDayLast 2.120
2017-03-31 10:31:44 total_consumption_Ch1_EnergyMeter 1079.290
2017-03-31 10:31:44 total_consumption_Ch1_EnergyMonth 171.100
2017-03-01 00:10:08 total_consumption_Ch1_EnergyMonthLast 277.190
2017-03-31 10:31:44 total_consumption_Ch1_EnergyYear 1079.290
2017-03-31 10:31:44 total_consumption_Ch1_FinanceReserve -264.318
2017-03-31 10:31:44 total_consumption_Ch1_MonthMeterReading 11
2017-03-31 10:31:44 total_consumption_Ch1_PowerCurrent 119.205
2017-03-31 10:31:44 total_consumption_Ch1_PowerDayAver 234.948
2016-12-23 00:18:44 total_consumption_Ch1_PowerDayCount 0
2017-03-31 06:43:36 total_consumption_Ch1_PowerDayMax 2160.000
2017-03-31 00:03:36 total_consumption_Ch1_PowerDayMin 0.000
2016-12-23 00:18:44 total_consumption_Ch1_PowerDaySum 0
2017-03-31 10:31:44 total_consumption_Ch2 2359.23
2017-03-31 10:31:44 total_consumption_Ch2_CounterCurrent 2359.230
2017-03-31 00:03:37 total_consumption_Ch2_CounterDay1st 2356.780
2017-03-31 00:03:37 total_consumption_Ch2_CounterDayLast 2356.770
2016-12-14 12:38:08 total_consumption_Ch2_CounterMeter1st 1665.79
2016-12-14 12:38:08 total_consumption_Ch2_CounterMeterLast 1665.790
2017-03-01 00:00:08 total_consumption_Ch2_CounterMonth1st 2203.120
2017-03-01 00:00:08 total_consumption_Ch2_CounterMonthLast 2203.110
2016-12-14 12:38:08 total_consumption_Ch2_CounterYear1st 1665.79
2016-12-14 12:38:08 total_consumption_Ch2_CounterYearLast 1665.790
2017-03-31 10:31:44 total_consumption_Ch2_EnergyCostDay 0.629
2017-03-31 00:03:37 total_consumption_Ch2_EnergyCostDayLast 0.323
2017-03-31 10:31:44 total_consumption_Ch2_EnergyCostMeter 178.006
2017-03-31 10:31:44 total_consumption_Ch2_EnergyCostMonth 40.073
2017-03-01 00:00:08 total_consumption_Ch2_EnergyCostMonthLast 46.686
2017-03-31 10:31:44 total_consumption_Ch2_EnergyCostYear 178.006
2017-03-31 10:31:44 total_consumption_Ch2_EnergyDay 2.450
2017-03-31 00:03:37 total_consumption_Ch2_EnergyDayLast 1.260
2017-03-31 10:31:44 total_consumption_Ch2_EnergyMeter 693.440
2017-03-31 10:31:44 total_consumption_Ch2_EnergyMonth 156.110
2017-03-01 00:00:08 total_consumption_Ch2_EnergyMonthLast 181.870
2017-03-31 10:31:44 total_consumption_Ch2_EnergyYear 693.440
2017-03-31 10:31:44 total_consumption_Ch2_FinanceReserve -178.006
2017-03-31 10:31:44 total_consumption_Ch2_MonthMeterReading 11
2017-03-31 10:31:44 total_consumption_Ch2_PowerCurrent 0.000
2017-03-31 10:31:44 total_consumption_Ch2_PowerDayAver 347.571
2016-12-23 00:08:45 total_consumption_Ch2_PowerDayCount 0
2017-03-31 04:58:37 total_consumption_Ch2_PowerDayMax 840.000
2017-03-31 06:08:37 total_consumption_Ch2_PowerDayMin 0
2016-12-23 00:08:45 total_consumption_Ch2_PowerDaySum 0
Helper:
BUFFER
EoM 1
SPEED 0
SPEED2 0
TRIGGERTIME 1490938295.60619
Channels:
DEVICES:
/?!
300
000
Attributes:
event-min-interval total_consumption_Ch1:600,total_consumption_Ch2:600,total_consumption_Ch1_PowerCurrent:600,total_consumption_Ch2_PowerCurrent:600,total_consumption_Ch1_EnergyDay:600,total_consumption_Ch2_EnergyDay:600
event-on-change-reading total_consumption_Ch1,total_consumption_Ch2,total_consumption_Ch1_PowerCurrent,total_consumption_Ch2_PowerCurrent,total_consumption_Ch1_EnergyDay,total_consumption_Ch2_EnergyDay
interval 300
verbose 5
Es sieht so aus, als ob wir nur einen ähnlichen aber nicht den gleichen Zähler haben. Ich habe zusätzlich noch den ElectricityCounter drin, also nicht wundern.
Besten Gruß,
Blixman
Danke und du scheinst recht zu haben, ein wenig Unterscheiden sich die Zähler auch....
Jeder Kocht sein eigenes Süppchen .... ::)
Den ElectricityCalculator schaue ich mir auch gerade an.
Wäre es möglich, dass du mir dort auch ein List deines Devices posten könntest?
Dann kann ich mich damit mal weiter auseinandersetzen.
Mein Ziel wäre es den Verbauch des Zählers mit dem Verbrauch der Wärmemenge meiner LWP abzugleichen und damit meine Excelliste zu automatisieren.
Danke!
Hallo,
ich bekomme folgende Perl Warnings vom OBIS Modul:
Bei FHEM Start:
PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 481, <$fh> line 60.
2017.04.01 16:57:58 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 801, <$fh> line 60.
2017.04.01 16:57:58 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/47_OBIS.pm line 154, <$fh> line 60.
2017.04.01 16:58:04 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 810.
2017.04.01 16:58:04 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 387.
Und zu unterschiedlichen Tageszeiten manchmal:
2017.04.02 00:00:38 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 793.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 808.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 810.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 353.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 361.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 362.
2017.04.02 00:00:38 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 332.
Woran kann das liegen? Grundsätzlich funktioniert sonst alles.
Grüße
Oliver
Hallo an alle,
ich nutze FHEM seit einiger Zeit mit verschiedenen Modulen. Tolle Sache. Seit 2 Monaten auch OBIS. Alles lief völlig fehlerfrei. Seit einiger Zeit fiel mir auf, dass sich das Verhaltem im Log verändert hat. Nähere Untersuchungen führten dazu, dass sie 24.03.17 nicht mehr auf alle Anfragen die an den Zähler gestellt werden mit Werden beantwortet werden. An dem Tag wurde auch das Modul upgedatet ?(zumindest hat 47_OBIS.pm) dort ein neues Datum.
Hier mal die Einstellungen:
define Stromzaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505RFZT-if00-port0@300,7,E,1 VSM102
attr Stromzaehler channels {"1.0.1.8.0.255"=>"aktueller_Zaehlerstand","1.0.1.8.0.01"=>"Zaehlerstand_letzter_Monat","1.0.1.8.0.02"=>"Zaehlerstand_vorletzter_Monat","1.0.1.8.0.03"=>"Zaehlerstand_aktuell-3","1.0.1.8.0.04"=>"Zaehlerstand_aktuell-4","1.0.1.8.0.05"=>"Zaehlerstand_aktuell-5","1.0.1.8.0.06"=>"Zaehlerstand_aktuell-6","1.0.1.8.0.07"=>"Zaehlerstand_aktuell-7","1.0.1.8.0.08"=>"Zaehlerstand_aktuell-8","1.0.1.8.0.09"=>"Zaehlerstand_aktuell-9","1.0.1.8.0.10"=>"Zaehlerstand_aktuell-10","1.0.1.8.0.11"=>"Zaehlerstand_aktuell-11","1.0.1.8.0.12"=>"Zaehlerstand_aktuell-12"}
attr Stromzaehler event-on-update-reading aktueller_Zaehlerstand,Delta_Stromzaehler_2min
attr Stromzaehler ignoreUnknown on
attr Stromzaehler interval 120
attr Stromzaehler room 1_0_Haus,1_3_Strom
attr Stromzaehler stateFormat akueller Verbrauch: Delta_Stromzaehler_2min kW, \
momentaner Zählerstand: aktueller_Zaehlerstand kWh
attr Stromzaehler userReadings Delta_Stromzaehler_2min:aktueller_Zaehlerstand.* differential { ReadingsVal ("Stromzaehler","aktueller_Zaehlerstand",0)*3600 }
attr Stromzaehler verbose 5
Hier nochmal ein Auschnitt aus dem Log:
2017.04.02 12:31:13 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-02 12:33:13
2017.04.02 12:31:14 5: OBIS (Stromzaehler) - Msg-Parse: /ISk5MT174-0001
2017.04.02 12:31:14 5: SW: 063035300d0a
2017.04.02 12:33:13 5: SW: 2f3f210d0a
2017.04.02 12:33:13 4: Wrote /?!^M
2017.04.02 12:33:13 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-02 12:35:13
2017.04.02 12:33:14 5: OBIS (Stromzaehler) - Msg-Parse: a[^N^P
^Pq#Z+^Z^[c0c9cc;x0F^P^Xa^YzLcNcz^X^PF^S/ISk5MT174-0001
2017.04.02 12:33:14 5: SW: 063035300d0a
2017.04.02 12:35:13 5: SW: 2f3f210d0a
2017.04.02 12:35:13 4: Wrote /?!^M
und manchmal gehts dann wieder. Hier mal der Anfang einer funktionierenden Abfrage:
2017.04.02 12:29:13 5: SW: 2f3f210d0a
2017.04.02 12:29:13 4: Wrote /?!^M
2017.04.02 12:29:13 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-02 12:31:13
2017.04.02 12:29:14 5: OBIS (Stromzaehler) - Msg-Parse: !E+Eq^L.^[r^[zy^zPc^]F^D^Ya^[^U:c^X^]y/1a:lay#^]hc#z
S/ISk5MT174-0001
2017.04.02 12:29:16 5: OBIS (Stromzaehler) - Msg-Parse: ^B0-0:F.F.0*255(0000000)
2017.04.02 12:29:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.1*255(1ISK1000)
2017.04.02 12:29:17 5: Msg 1-0:0.0.1*255(1ISK1000) is of type Serial
2017.04.02 12:29:18 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.0*255(47490825)
2017.04.02 12:29:18 5: Msg 1-0:0.0.0*255(47490825) is of type Owner
2017.04.02 12:29:19 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.9.1*255(120137)
2017.04.02 12:29:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.9.2*255(1170402)
2017.04.02 12:29:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.1.0*255(77)
2017.04.02 12:29:21 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.1.2*01(1704010000)
2017.04.02 12:29:22 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.1.2*02(1703010000)
Hat jemand eine Idee? Alternative wäre aus einem Backup die funktionierende pm wieder restaurieren. ?
Schon mal vielen Dank für eure Bemühungen
Andreas
Mein Zähler funktioniert mit der neuen Version gar nicht. Mit einem Backup vom Januar geht es, allerdings hat er auch hin und wieder Aussetzer beim Lesen.
Hatte des jetzt aber auf meinen Zaehler geschoben.
Ich hatte gestern die beiden Versionen mal verglichen. Es gibt in der define Funktion sowie in der zum Lesen der Reading ein paar Änderungen.
Ich hatte mehrfach versucht durch Auskommentieren der Veränderungen das Problem einzugrenzen. Leider schlägt dann das von dir ebenfalls beschrieben Problem mit mal geht und mal geht nicht zu.
Das macht einen Vergleich dann schwierig.
Ich stehe aber gerne fuer weitere Test bereit um den Fehler einzugrenzen.
Icinger kann ja nicht jeden Fall kennen :) und testen.
Die letzten Code-Änderungen sind auf einen Vorschlag von immi hin erfolgt.
Hatten bei mir keinerlei Nebenwirkungen, daher hatte ich sie eingecheckt.
Da sie scheinbar doch bei mehreren zu Problemen führen, werde ich das wieder rückgängig machen, bis sich eine andere Lösung findet.
Sollte heute abend dazukommen, das neue alte Update einzuspielen.
lg, Stefan
Klappt alle wieder, besten Dank
Andreas
Bei mir auch.
Danke!
Auch wenn ich den Update Button jetzt vermisse 8).
Mal eine Frage in die Runde:
Ein wirklichen WIKI Eintrag zu dem ganzen Thema gibt es noch nicht, oder?
Bei meiner Suche am Sonntag habe ich nur einen alten Eintrag gefunden der auf dein OBIS verweist und diesen Thread angibt.
Ich habe aus der ganzen Anwesenheitsthematik schon einen Wikibereich erstellt und könnte dies für OBIS auch machen wenn gewünscht.
Das Thema ist vom Umfang her ja auch schon angewachsen mit den ganzen Zusätzen von ReadingsGroups, Auswertungen und Co.
Ich bräuchte allerdings noch ein paar Infos zu den funktionieren Zählern etc.
Viele Grüße,
Dirk
ZitatAuch wenn ich den Update Button jetzt vermisse
Der sollte nach wie vor vorhanden sein.
lg, Stefan
Zitat von: Icinger am 04 April 2017, 05:40:29
Der sollte nach wie vor vorhanden sein.
lg, Stefan
Ja, du hast recht. Man sollte nach dem Update auch ein reload machen.... :'(
Hallo,
nachdem ich den Weidemann-Lesekopf erfolgreich einsetze, stelle ich fest, daß immer nach einigen Stunden einwandfreier Funktion keine Werte mehr ausgelesen werden.
Ich habe auch bereits verbose auf 5 gesetzt, im log tauchen jedoch keine Fehlermeldungen auf:
2017.04.05 03:29:12 5: SW:
2017.04.05 03:29:12 4: Wrote
2017.04.05 03:29:12 5: OBIS (sz) - Internal timer set to 2017-04-05 03:30:12
statt eines vollständigen Eintrages
2017.04.05 03:28:12 5: SW:
2017.04.05 03:28:12 4: Wrote
2017.04.05 03:28:12 5: OBIS (sz) - Internal timer set to 2017-04-05 03:29:12
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: /EBZ5DD3BZ06ETA_105
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse:
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:0.0.0*255(9561051)
2017.04.05 03:28:12 5: Msg 1-0:0.0.0*255(9561051) is of type Owner
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:96.1.0*255(1EBZ0100010492)
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:1.8.0*255(001004.18511543*kWh)
2017.04.05 03:28:12 5: Msg 1-0:1.8.0*255(001004.18511543*kWh) is of type Counter
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:16.7.0*255(000426.06*W)
2017.04.05 03:28:12 5: Msg 1-0:16.7.0*255(000426.06*W) is of type Channels
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:36.7.0*255(000119.84*W)
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:56.7.0*255(000091.01*W)
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:76.7.0*255(000215.21*W)
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 1-0:96.5.5*255(001C0104)
2017.04.05 03:28:12 5: Msg 1-0:96.5.5*255(001C0104) is of type Status
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: 0-0:96.8.0*255(005E729B)
2017.04.05 03:28:12 5: OBIS (sz) - Msg-Parse: !
Nach einem "shutdown restart" oder Aufrufen der Definition und Abspeichern mit "modify" in der Web-Oberfläche fuktioniert es wieder für einige Stunden.
Die Definition und Parametrierung lautet
define sz OBIS /dev/ttyUSB-powermeter@9600,7,E,1
attr sz alias Stromzähler
attr sz channels {"1.0.36.7.0.255"=>"L1","1.0.56.7.0.255"=>"L2","1.0.76.7.0.255"=>"L3"}
attr sz event-on-change-reading L1,L2,L3,power,total_consumption,statTotal_consumptionLast,statTotal_consumptionDayLast
attr sz interval 60
attr sz pollingMode on
Kann mir bitte jemand einen Tip geben, woran das liegen könnte?
Gruß
td
Moin Moin,
seit einiger Zeit flooded mir das OBIS Modul das Logfile mit:
substr outside of string at ./FHEM/47_OBIS.pm line 791.
Diese zeile kommt hundertfach.
Ich kann nicht genau sagen seit wann.
Eventuell seit ich von "ttyUSB1" auf "/dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0" umgestellt habe. kann ich aber nicht mit Sicherheit sagen.
weis jemand Rat?
klingt nach defekten Datensätzen....Bitte mal ein Verbose-5-Log.
lg, Stefan
Zitat von: Icinger am 13 April 2017, 20:36:42
klingt nach defekten Datensätzen....Bitte mal ein Verbose-5-Log.
lg, Stefan
Kommt. Was mir grad noch mit auffällt, ab und an ist ein "<GEN39> line 69." hinten dran wobei die line wechselt.
Die Logeinträge sind allesamt ohne Datum/Uhrzeit.
ZitatDie Logeinträge sind allesamt ohne Datum/Uhrzeit.
Das dürfte eigentlich gar nicht sein, die kommen ja vom FHEM-Log3-Befehl, der macht das automatisch
Verbose5: (nur auf das Obis device)
2017.04.13 21:22:55 5: OBIS: Telegram=0177078181C78205FF0172620165009E606301018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C0101016324DD007607000701C243CF62006200726302017101632EAD000000001B1B1B1B1A038402
2017.04.13 21:22:55 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401927.1*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400359.7*Wh)
1-0:16.7.0*255(246.2*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:22:55 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:22:55 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401927.1*Wh)
2017.04.13 21:22:55 5: Msg 1-0:1.8.0*255(>1401927.1*Wh) is of type Counter
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:22:55 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400359.7*Wh)
2017.04.13 21:22:55 5: Msg 1-0:1.8.2*255(1400359.7*Wh) is of type Counter
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(246.2*W)
2017.04.13 21:22:55 5: Msg 1-0:16.7.0*255(246.2*W) is of type Channels
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:22:55 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:22:55 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:23:25 5: SW:
2017.04.13 21:23:25 4: Wrote
2017.04.13 21:23:25 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:23:55
2017.04.13 21:23:27 5: SML-Parse 1B1B1B1B010101017607000701C244316200620072630101760101070007009E16BB0B0901454D48000059DF150101638FA8007607000701C24432620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60827777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAE20177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Full message-> 1B1B1B1B010101017607000701C244316200620072630101760101070007009E16BB0B0901454D48000059DF150101638FA8007607000701C24432620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60827777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAE20177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:23:27 5: OBIS: Telegram=1B1B1B1B010101017607000701C244316200620072630101760101070007009E16BB0B0901454D48000059DF150101638FA8007607000701C24432620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60827777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAE20177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAE20177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EAE20177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5ADA80177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000BEA0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 5: OBIS: Telegram=0177078181C78205FF0172620165009E608201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101637347007607000701C244356200620072630201710163EFF4000000001B1B1B1B1A0340F5
2017.04.13 21:23:27 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401929.8*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400362.4*Wh)
1-0:16.7.0*255(305*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:23:27 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:23:27 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401929.8*Wh)
2017.04.13 21:23:27 5: Msg 1-0:1.8.0*255(>1401929.8*Wh) is of type Counter
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:23:27 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400362.4*Wh)
2017.04.13 21:23:27 5: Msg 1-0:1.8.2*255(1400362.4*Wh) is of type Counter
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(305*W)
2017.04.13 21:23:27 5: Msg 1-0:16.7.0*255(305*W) is of type Channels
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:23:27 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:23:27 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:23:55 5: SW:
2017.04.13 21:23:55 4: Wrote
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:24:25
2017.04.13 21:23:55 5: SML-Parse 1B1B1B1B010101017607000701C244796200620072630101760101070007009E16D30B0901454D48000059DF150101635233007607000701C2447A620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E609F7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAFA0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Full message-> 1B1B1B1B010101017607000701C244796200620072630101760101070007009E16D30B0901454D48000059DF150101635233007607000701C2447A620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E609F7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAFA0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:23:55 5: OBIS: Telegram=1B1B1B1B010101017607000701C244796200620072630101760101070007009E16D30B0901454D48000059DF150101635233007607000701C2447A620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E609F7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAFA0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EAFA0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EAFA0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5ADC00177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 5: OBIS: Telegram=0177078181C78205FF0172620165009E609F01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBD2007607000701C2447D62006200726302017101634085000000001B1B1B1B1A03CB93
2017.04.13 21:23:55 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401932.2*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400364.8*Wh)
1-0:16.7.0*255(288*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:23:55 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:23:55 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401932.2*Wh)
2017.04.13 21:23:55 5: Msg 1-0:1.8.0*255(>1401932.2*Wh) is of type Counter
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:23:55 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400364.8*Wh)
2017.04.13 21:23:55 5: Msg 1-0:1.8.2*255(1400364.8*Wh) is of type Counter
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(288*W)
2017.04.13 21:23:55 5: Msg 1-0:16.7.0*255(288*W) is of type Channels
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:23:55 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:23:55 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:24:25 5: SW:
2017.04.13 21:24:25 4: Wrote
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:24:55
2017.04.13 21:24:25 5: SML-Parse 1B1B1B1B010101017607000701C244C16200620072630101760101070007009E16EB0B0901454D48000059DF1501016319BC007607000701C244C2620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60BD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB120177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Full message-> 1B1B1B1B010101017607000701C244C16200620072630101760101070007009E16EB0B0901454D48000059DF1501016319BC007607000701C244C2620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60BD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB120177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:24:25 5: OBIS: Telegram=1B1B1B1B010101017607000701C244C16200620072630101760101070007009E16EB0B0901454D48000059DF1501016319BC007607000701C244C2620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60BD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB120177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB120177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB120177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5ADD80177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B460177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 5: OBIS: Telegram=0177078181C78205FF0172620165009E60BD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163AB56007607000701C244C562006200726302017101633E38000000001B1B1B1B1A038A9C
2017.04.13 21:24:25 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401934.6*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400367.2*Wh)
1-0:16.7.0*255(288.6*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:24:25 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:24:25 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401934.6*Wh)
2017.04.13 21:24:25 5: Msg 1-0:1.8.0*255(>1401934.6*Wh) is of type Counter
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:24:25 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400367.2*Wh)
2017.04.13 21:24:25 5: Msg 1-0:1.8.2*255(1400367.2*Wh) is of type Counter
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(288.6*W)
2017.04.13 21:24:25 5: Msg 1-0:16.7.0*255(288.6*W) is of type Channels
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:24:25 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:24:25 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:24:55 5: SW:
2017.04.13 21:24:55 4: Wrote
2017.04.13 21:24:55 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:25:25
2017.04.13 21:24:57 5: SML-Parse 1B1B1B1B010101017607000701C2450F6200620072630101760101070007009E17050B0901454D48000059DF15010163F9FE007607000701C24510620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60DD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB2C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Full message-> 1B1B1B1B010101017607000701C2450F6200620072630101760101070007009E17050B0901454D48000059DF15010163F9FE007607000701C24510620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60DD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB2C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:24:57 5: OBIS: Telegram=1B1B1B1B010101017607000701C2450F6200620072630101760101070007009E17050B0901454D48000059DF15010163F9FE007607000701C24510620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60DD7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB2C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB2C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB2C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5ADF20177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B570177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 5: OBIS: Telegram=0177078181C78205FF0172620165009E60DD01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101635C5C007607000701C2451362006200726302017101634766000000001B1B1B1B1A03CC75
2017.04.13 21:24:57 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401937.2*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400369.8*Wh)
1-0:16.7.0*255(290.3*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:24:57 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:24:57 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401937.2*Wh)
2017.04.13 21:24:57 5: Msg 1-0:1.8.0*255(>1401937.2*Wh) is of type Counter
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:24:57 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400369.8*Wh)
2017.04.13 21:24:57 5: Msg 1-0:1.8.2*255(1400369.8*Wh) is of type Counter
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(290.3*W)
2017.04.13 21:24:57 5: Msg 1-0:16.7.0*255(290.3*W) is of type Channels
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:24:57 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:24:57 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:25:25 5: SW:
2017.04.13 21:25:25 4: Wrote
2017.04.13 21:25:25 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:25:55
2017.04.13 21:25:27 5: SML-Parse 1B1B1B1B010101017607000701C245576200620072630101760101070007009E171D0B0901454D48000059DF15010163741B007607000701C24558620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60FB7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB440177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Full message-> 1B1B1B1B010101017607000701C245576200620072630101760101070007009E171D0B0901454D48000059DF15010163741B007607000701C24558620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60FB7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB440177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:25:27 5: OBIS: Telegram=1B1B1B1B010101017607000701C245576200620072630101760101070007009E171D0B0901454D48000059DF15010163741B007607000701C24558620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E60FB7777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB440177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB440177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB440177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5AE0A0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B5B0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 5: OBIS: Telegram=0177078181C78205FF0172620165009E60FB01018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163EBE1007607000701C2455B6200620072630201710163E817000000001B1B1B1B1A03343F
2017.04.13 21:25:27 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401939.6*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400372.2*Wh)
1-0:16.7.0*255(290.7*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:25:27 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:25:27 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401939.6*Wh)
2017.04.13 21:25:27 5: Msg 1-0:1.8.0*255(>1401939.6*Wh) is of type Counter
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:25:27 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400372.2*Wh)
2017.04.13 21:25:27 5: Msg 1-0:1.8.2*255(1400372.2*Wh) is of type Counter
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(290.7*W)
2017.04.13 21:25:27 5: Msg 1-0:16.7.0*255(290.7*W) is of type Channels
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:25:27 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:25:27 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:25:55 5: SW:
2017.04.13 21:25:55 4: Wrote
2017.04.13 21:25:55 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:26:25
2017.04.13 21:25:57 5: SML-Parse 1B1B1B1B010101017607000701C2459F6200620072630101760101070007009E17350B0901454D48000059DF150101635CA1007607000701C245A0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61197777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB5C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Full message-> 1B1B1B1B010101017607000701C2459F6200620072630101760101070007009E17350B0901454D48000059DF150101635CA1007607000701C245A0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61197777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB5C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:25:57 5: OBIS: Telegram=1B1B1B1B010101017607000701C2459F6200620072630101760101070007009E17350B0901454D48000059DF150101635CA1007607000701C245A0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61197777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB5C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB5C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB5C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5AE220177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B490177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 5: OBIS: Telegram=0177078181C78205FF0172620165009E611901018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101636E2D007607000701C245A362006200726302017101639367000000001B1B1B1B1A0362D1
2017.04.13 21:25:57 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401942*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400374.6*Wh)
1-0:16.7.0*255(288.9*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:25:57 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:25:57 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401942*Wh)
2017.04.13 21:25:57 5: Msg 1-0:1.8.0*255(>1401942*Wh) is of type Counter
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:25:57 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400374.6*Wh)
2017.04.13 21:25:57 5: Msg 1-0:1.8.2*255(1400374.6*Wh) is of type Counter
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(288.9*W)
2017.04.13 21:25:57 5: Msg 1-0:16.7.0*255(288.9*W) is of type Channels
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:25:57 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:25:57 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:26:25 5: SW:
2017.04.13 21:26:25 4: Wrote
2017.04.13 21:26:25 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:26:55
2017.04.13 21:26:27 5: SML-Parse 1B1B1B1B010101017607000701C245E76200620072630101760101070007009E174D0B0901454D48000059DF15010163AF3E007607000701C245E8620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61367777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB740177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Full message-> 1B1B1B1B010101017607000701C245E76200620072630101760101070007009E174D0B0901454D48000059DF15010163AF3E007607000701C245E8620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61367777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB740177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:26:27 5: OBIS: Telegram=1B1B1B1B010101017607000701C245E76200620072630101760101070007009E174D0B0901454D48000059DF15010163AF3E007607000701C245E8620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61367777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB740177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB740177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB740177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5AE3A0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B470177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 5: OBIS: Telegram=0177078181C78205FF0172620165009E613701018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A985007607000701C245EB62006200726302017101633C16000000001B1B1B1B1A032B5E
2017.04.13 21:26:27 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401944.4*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400377*Wh)
1-0:16.7.0*255(288.7*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:26:27 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:26:27 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401944.4*Wh)
2017.04.13 21:26:27 5: Msg 1-0:1.8.0*255(>1401944.4*Wh) is of type Counter
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:26:27 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400377*Wh)
2017.04.13 21:26:27 5: Msg 1-0:1.8.2*255(1400377*Wh) is of type Counter
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(288.7*W)
2017.04.13 21:26:27 5: Msg 1-0:16.7.0*255(288.7*W) is of type Channels
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:26:27 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:26:27 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:26:55 5: SW:
2017.04.13 21:26:55 4: Wrote
2017.04.13 21:26:55 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:27:25
2017.04.13 21:26:57 5: SML-Parse 1B1B1B1B010101017607000701C2462F6200620072630101760101070007009E17650B0901454D48000059DF150101632244007607000701C24630620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61547777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB8C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Full message-> 1B1B1B1B010101017607000701C2462F6200620072630101760101070007009E17650B0901454D48000059DF150101632244007607000701C24630620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61547777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB8C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:26:57 5: OBIS: Telegram=1B1B1B1B010101017607000701C2462F6200620072630101760101070007009E17650B0901454D48000059DF150101632244007607000701C24630620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61547777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB8C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EB8C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EB8C0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5AE520177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B4F0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 5: OBIS: Telegram=0177078181C78205FF0172620165009E615401018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A866007607000701C2463362006200726302017101632303000000001B1B1B1B1A03AD28
2017.04.13 21:26:57 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401946.8*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400379.4*Wh)
1-0:16.7.0*255(289.5*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:26:57 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:26:57 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401946.8*Wh)
2017.04.13 21:26:57 5: Msg 1-0:1.8.0*255(>1401946.8*Wh) is of type Counter
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:26:57 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400379.4*Wh)
2017.04.13 21:26:57 5: Msg 1-0:1.8.2*255(1400379.4*Wh) is of type Counter
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(289.5*W)
2017.04.13 21:26:57 5: Msg 1-0:16.7.0*255(289.5*W) is of type Channels
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:26:57 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:26:57 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:27:25 5: SW:
2017.04.13 21:27:25 4: Wrote
2017.04.13 21:27:25 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:27:55
2017.04.13 21:27:27 5: SML-Parse 1B1B1B1B010101017607000701C246776200620072630101760101070007009E177D0B0901454D48000059DF15010163AFA1007607000701C24678620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61727777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBA40177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Full message-> 1B1B1B1B010101017607000701C246776200620072630101760101070007009E177D0B0901454D48000059DF15010163AFA1007607000701C24678620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61727777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBA40177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:27:27 5: OBIS: Telegram=1B1B1B1B010101017607000701C246776200620072630101760101070007009E177D0B0901454D48000059DF15010163AFA1007607000701C24678620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61727777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBA40177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBA40177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177070100010800FF6400028201621E52FF560000D5EBA40177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177070100010802FF0101621E52FF560000D5AE6A0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177070100100700FF0101621B52FF5500000B400177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 5: OBIS: Telegram=0177078181C78205FF0172620165009E617201018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01010163A014007607000701C2467B62006200726302017101638C72000000001B1B1B1B1A038D08
2017.04.13 21:27:27 4: MSG IS:
/EMH\0901454D48000059DF15
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000059DF15)
1-0:1.8.0*255(>1401949.2*Wh)
1-0:1.8.1*255(1567.4*Wh)
1-0:1.8.2*255(1400381.8*Wh)
1-0:16.7.0*255(288*W)
129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
!
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: /EMH\0901454D48000059DF15
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.04.13 21:27:27 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(0901454D48000059DF15)
2017.04.13 21:27:27 5: Msg 1-0:0.0.9*255(0901454D48000059DF15) is of type Serial
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>1401949.2*Wh)
2017.04.13 21:27:27 5: Msg 1-0:1.8.0*255(>1401949.2*Wh) is of type Counter
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(1567.4*Wh)
2017.04.13 21:27:27 5: Msg 1-0:1.8.1*255(1567.4*Wh) is of type Counter
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(1400381.8*Wh)
2017.04.13 21:27:27 5: Msg 1-0:1.8.2*255(1400381.8*Wh) is of type Counter
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(288*W)
2017.04.13 21:27:27 5: Msg 1-0:16.7.0*255(288*W) is of type Channels
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01)
2017.04.13 21:27:27 5: Msg 129-129:199.130.5*255(CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C01) is of type PublicKey
2017.04.13 21:27:27 5: OBIS (Stromzaehler) - Msg-Parse: !
2017.04.13 21:27:55 5: SW:
2017.04.13 21:27:55 4: Wrote
2017.04.13 21:27:55 5: OBIS (Stromzaehler) - Internal timer set to 2017-04-13 21:28:25
2017.04.13 21:27:57 5: SML-Parse 1B1B1B1B010101017607000701C246BF6200620072630101760101070007009E17950B0901454D48000059DF1501016336DE007607000701C246C0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61907777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBBC0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE820177070100100700FF0101621B52FF5500000B440177078181C78205FF0172620165009E619001018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101630803007607000701C246C36200620072630201710163F2CF000000001B1B1B1B1A03D24C
2017.04.13 21:27:57 5: OBIS: Full message-> 1B1B1B1B010101017607000701C246BF6200620072630101760101070007009E17950B0901454D48000059DF1501016336DE007607000701C246C0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61907777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBBC0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE820177070100100700FF0101621B52FF5500000B440177078181C78205FF0172620165009E619001018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101630803007607000701C246C36200620072630201710163F2CF000000001B1B1B1B1A03D24C
substr outside of string at ./FHEM/47_OBIS.pm line 791.
2017.04.13 21:27:57 5: OBIS: Telegram=1B1B1B1B010101017607000701C246BF6200620072630101760101070007009E17950B0901454D48000059DF1501016336DE007607000701C246C0620062007263070177010B0901454D48000059DF15070100620AFFFF72620165009E61907777078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBBC0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE820177070100100700FF0101621B52FF5500000B440177078181C78205FF0172620165009E619001018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101630803007607000701C246C36200620072630201710163F2CF000000001B1B1B1B1A03D24C
2017.04.13 21:27:57 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000059DF150177070100010800FF6400028201621E52FF560000D5EBBC0177070100010801FF0101621E52FF560000003D3A0177070100010802FF0101621E52FF560000D5AE820177070100100700FF0101621B52FF5500000B440177078181C78205FF0172620165009E619001018302CD85F0859E86B06A7A3BBB9033F7BDA48F81F5BF5F39136C67F21628D866BE94C96F576E8A0D50F20E1FDAA6040F3D8C010101630803007607000701C246C36200620072630201710163F2CF000000001B1B1B1B1A03D24C
LogEinträge ohne Zeit:
https://abload.de/img/logpesna.png
wird auch gerade hier diskuttert:
https://forum.fhem.de/index.php/topic,70503.0.html
Ok, werd mir das ansehen, wird aber paar Tage dauern, ich fang morgen mit Pool-mauern an...
Zitat von: Icinger am 13 April 2017, 22:01:23
Ok, werd mir das ansehen, wird aber paar Tage dauern, ich fang morgen mit Pool-mauern an...
Hab ich glaub anderstwo schon gelesen. :-)
Ich hab keine EIle, es funzt ja alles.
viel Spass beim mauern!
gibts ne FHEM community Poolparty wenns fertig ist? :)
Zitatgibts ne FHEM community Poolparty wenns fertig ist?
Wennst von Karlsruhe ins schöne Weinviertel kommst, kein Problem ^^
Hi Zusammen.
Bin gerade durch Zufall auf dieses Modul gestoßen.
Aktuell lese ich meinen Zähler mit einem Photoresistor an der LED des Stromzählers aus. Der Resistor ist mit einem GPIO am Raspberry verbunden. Zähle 60min lang die Impulse und werte das dann aus. Klappt soweit auch ganz gut, hätte es aber gerne doch was genauer.
Jetzt hätte ich mal ne Frage. Um nicht wieder alles umstricken zu müssen würde ich gerne so wenig wie möglich ändern. Ist es möglich mit dem Modul anstatt einen Seriellen Port, auch einen GPIO Port als Datenquelle zu nehmen? Oder kann man vorgaukeln das der GPIO Port ein Serieller Port ist?
Bekommst vom Photoresistor ja nur Impulse.
Wie willst du daraus eine OBIS-Nachricht erzeugen, die das Modul dann auswerten kann?
Eien OBIS-Message sieht zB so aus:
/ESY
129-129:199.130.3*255(ESY)
1-1:1.8.0*255(3e+97)
1-2:2.8.0*255(3e+97)
1-1:1.8.1*255(3e+97)
1-1:1.8.2*255(3e+97)
1-1:1.8.3*255(3e+97)
1-1:1.8.4*255(3e+97)
1-1:1.8.5*255(3e+97)
1-1:1.8.6*255(3e+97)
1-2:2.8.7*255(3e+97)
1-2:2.8.8*255(3e+97)
1-0:1.7.0*255(54.77*W)
1-0:21.7.0*255(150.9*W)
1-0:41.7.0*255(7.89*W)
1-0:61.7.0*255(-104.02*W)
1-0:96.5.5*255(16784)
!
Damit kann das Modul was anfangen, aber nicht mit einzelnen Impulsen.
lg, Stefan
Hallo zusammen,
ich hänge mich hier mal mit an.
Seit 2 Jahren habe ich den 2 Wege Stromzähler mit Udos Lesekopf an fhem angebunden.
Ich kann alle Werte lesen und diese werden auch aktualisiert und geloggt.
Seit dem letzten Update wächst die log Datei nun ins Unermessliche im Sekundentakt.
Es ist immer die gleiche Meldung:
substr outside of string at ./FHEM/47_OBIS.pm line 791.
^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4325.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
Internals:
CHANGED
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F30001-if00-port0@9600,8,N,1, SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F30001-if00-port0@9600,8,N,1,
MeterType SML
NAME Stromzaehler
NR 204
PARTIAL
STATE opened
TYPE OBIS
Readings:
2016-08-05 19:56:34 1.0.0.0.9.255 06-45-4D-48-01-04-C5-6C-B8-C3
2016-08-05 19:56:34 129.129.199.130.3.255 EMH
2016-08-05 19:56:34 129.129.199.130.5.255 110C-DE3D-9852-AA33-FCB8-C1B2-0838-F645-2DEA-81C2-F1B5-3196-AD19-E2DA-210C-1E20-E1DA-6AB2-0139-9CE3-5131-AC3D-07BB-E598-01
2017-04-18 18:46:26 Version EMH\06454D480104C56CB8C3
2017-04-18 21:54:17 dir_total_consumption Bezug
2017-04-18 21:54:17 dir_total_feed Bezug
2017-04-18 21:54:17 power 449.4
2017-04-17 18:25:44 state opened
2017-04-18 21:54:17 total_consumption 6672050.6
2017-04-18 21:54:17 total_consumption_Ch1 6672050.6
2017-04-18 21:54:17 total_consumption_Ch2 0
2017-04-18 21:54:17 total_feed 27593850.8
2017-04-18 21:54:17 total_feed_Ch1 27593850.8
2017-04-18 21:54:17 total_feed_Ch2 0
Helper:
BUFFER
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1492446344.72668
Channels:
DEVICES:
-1
Directions:
< Einspeisung
> Bezug
Attributes:
directions {">" => "Bezug", "<"=>"Einspeisung"}
event-min-interval .*:60
ignoreUnknown on
pollingMode on
room Unsorted
unitReadings off
verbose 2
Dateiversion: 47_OBIS.pm 13885 2017-04-03 03:50:45Z Icinger
Eingebunden in fhem mit:
/dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F30001-if00-port0@9600,8,N,1, SML
Zählertyp ist von EMH EHZ Generation 1
Was hat sich geändert oder was muss ich ändern?
Danke vorab für eure Hilfe
Andreas
@Icinger
Danke Dir für die Antwort.
Wo kann ich denn diesen Lesekopf ordern? Gibt es hier nen Kontakt dazu?
Hallo Vectra130
den gibts bei Udo aus dem Volkszählerprojekt zu bestellen.
http://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-usb-ausgang
http://volkszaehler.org/
Das ist aber hier im Forum schon beschrieben worden.
Gruss Andreas
Bei mir haut es das Log auch wie folgt zu:
Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 791.
Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 789.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 784.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
Gruß Robert
leider hab auch ich seit einem der letzten FHEM updates zwischen 10-18.4. diese Meldungen:
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
Hat schon jemand ne Möglichkeit gefunden diese Meldungen zu unterbinden?
Grüße Tomy
Nabend zusammen ;)
hat noch jemand das Problem, dass keine Zählerdaten mehr abgerufen werden?
Ich habe mittlerweile noch einen zweiten Lesekopf an einem anderen Zähler und beide werden seit 01.05. 23:30 nicht mehr aktualisiert.
Ich habe nichts verändert, da es ja vorher ohne Probleme gelaufen ist. Im Log sehe ich auch nur, dass die Zähler geöffnet werden aber es werden keine Readings gelesen.
Ich stehe grad echt auf dem Schlauch :-(
Auch das Anlegen einer Kopie (/dev/ttyUSB1@9600,8,N,1 SML) und vorherigem deaktivieren des Originalen DEFs ändert nichts.
Im Log steht weiterhin nur
2017.05.05 22:07:35 3: Opening Strom device /dev/ttyUSB1
2017.05.05 22:07:35 3: Setting Strom serial parameters to 9600,8,N,1
2017.05.05 22:07:35 3: Init done
2017.05.05 22:07:35 3: Strom device opened
2017.05.05 22:08:06 5: SW:
2017.05.05 22:08:06 4: Wrote
2017.05.05 22:08:06 5: SW:
2017.05.05 22:10:30 4: Wrote
Grüße,
Dirk
Edit: Nach löschen beider ttyUSB Files und Neuanmelden der Leseköpfe werden beide wieder erkannt. Also eher ein HW Problem am Pi, vermutlich.
Zitat von: Tomy am 23 April 2017, 19:52:39
leider hab auch ich seit einem der letzten FHEM updates zwischen 10-18.4. diese Meldungen:
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
Hat schon jemand ne Möglichkeit gefunden diese Meldungen zu unterbinden?
Grüße Tomy
Schließe mich der Frage an, gibt's schon etwas neues?
Wer ist denn maintainer des Moduls?
Gesendet von meinem S3_32 mit Tapatalk
Hallo zusammen,
laut Stefan/Icinger ist das Problem mit dem
substr outside of string at ./FHEM/47_OBIS.pm line 791.
substr outside of string at ./FHEM/47_OBIS.pm line 791.
mit dem Update von heute 10.05.17 im 47_OBIS.pm Modul behoben.
LG
Tomy
soeben update durchgeführt, ist behoben....PRIMA - VIELEN DANK !!!!
Bitte, gern geschehen :D
Ich möchte gerne mein "Kamstrup Multical 402" auslesen und bin mir nicht sicher welchen Metertypen ich verwenden muss bzw ob dieser überhaupt unterstützt wird. Im Volkszählerwiki konnte ich einen Eintrag zum Vorgänger finden: Kamstrup Multical 401 (https://wiki.volkszaehler.org/hardware/channels/meters/warming/kamstrup_multical_401)
Bitte wer kommt auf so eine geisteskranke Idee?
ZitatKurioserweise hat man sich bei Kamstrup dafür entschieden, dass Befehle mit 300 Baud angenommen werden, dieser Antwortet jedoch mit 1200 Baud.
Naja, das kann das OBIS leider (noch) nicht....Vlt. hab ich irgendwann mal Zeit und Muße, mir da was einfallen zu lassen, aktuell schauts da aber nicht gut aus.
Da dies hier:
/?![CR][LF][ACK]000[CR][LF]ein Standard-Init ist, könntest du's mal trotzdem mit Metertyp=VSM102 versuchen.
Vielleicht hast du Glück, und es wurde da ja was geändert, seit der Volkszähler-Artikel entstanden ist.
ZitatZuletzt geändert: 2013/10/30 23:28
lg, Stefan
seit ein paar Updates habe ich immer folgende Fehlermeldungen im LOG:
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 348.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 356.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 357.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 327.
HAt jemand eine Idee, ob mir ein Modul oder so fehlt? Oder ist das ein Bug in OBIS????
Das Auslesen von 2 Zählern funktioniert sonst einwandfrei.
Danke
Hallo Icinger,
nach dem Update geht nun alles. Danke für die Arbeit.
Andreas
Hallo,
nachdem ich mich jetzt durch den ganzen Fred gearbeitet habe, und meinen Zähler erfolgreich eingebunden habe, möchte ich einfach mal ein Danke schön für die viele Mühe und Arbeit, die bereits in diesem Modul steckt, zum Ausdruck bringen.
Gruß, Christoph
Ich möchte gerne meinen Zähler (Siemens) auch damit auslesen. Ich kann in den Beiträgen nicht dazu finden.
Funktioniert dieser Zähler mit dem Modul auch?
Zum Darstellen der Werte muss ich einen AES Key hinterlegen.
Kann ich diesen hier eingeben?
Ich habe zwar schon volkszähler installiert, möchte aber alles in fhem haben.
Das Lesen der Einträge vom Volkszähler von Fhem aus funktioniert bei mir einfach nicht.
fhem sucht immer das Modul VOLKSZAEHLER, obwohl ich alles installiert habe. Auch erforderlichen Zusätze habe ich installiert.
Ein direktes Lesen in fhem ist mir lieber als der Umweg über Volkszähler.
Hmm, meine Glaskugel kann mir grade leider nicht sagen, welchen Siemens-Zähler du hast.
Wenn du mir da weiterhelfen kannst, kann ich mal schaun, was der Zähler kann (oder auch nicht)
Wichtig wäre, dass der Zähler irgendeine Schnittstelle hat, über die Daten om OBIS oder SML-Format ausgegeben werden.
Alles weitere lässt sich sicher machen, wie zB AES-Key oder sowas. Müsste ich halt das Modul um dieses Feature erweitern.
lg, Stefan
Sorry, ich hätte auch etwas genauer sein können.
Der Zähler ist ein TD-3511 von Siemens.
Das ist ein Zweirichtungszähler mit AMIS Kundenschnittstelle.
Die Ausgabe der Schnittstelle ist mit einem AES Code verschlüsselt.
Ich hoffe das sind die wichtigsten Infos.
Ok, muss ich mich mal einlesen.....
Dauert aber sicher etwas, bin momentan beruflich und privat zuviel eingespannt leider.
lg, Stefan
Kein Problem! :)
Die Welt ist auch nicht von heute auf morgen erschaffen worden!
Hi maci,
du kannst auch nur vzlogger von volkszaehler benutzen. In vzlogger wird dein Zähler als OMS behandelt. Dort kannst du auch deinen AES-Code eingeben.
Siehe das AMIS-Zähler Beispiel in volkszaehler:
http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511_in_oberoesterreich
Mit dem vzlogger-Modul in FHEM kannst du die Daten dann in FHEM einlesen.
https://forum.fhem.de/index.php/topic,40766.msg617243.html#msg617243
Gruß
Udo
Erst einmal vielen Dank für das tolle Modul. Hat alles perfekt geklappt...
Nur den Stromzähler (EMH eHz) per IR-Lesekopf und Seriell-2-USB Adapter angeschlossen und schon hatte ich die Daten per OBIS (SML) in FHEM drinnen.
Danke.
Jetzt muss ich mir nur noch etwas für unseren Wärmezaehler von Landis+Gyr (Ultraheat, 2WR5) einfallen lassen. Vor einiger Zeit hatte gesehen dass andere das ja wohl auch schon versucht hatten. Weiß jemand ob das von Erfolg gekrönt war? So einfach wie beim Stromzähler wir es wohl nicht werden... ein paar Modifikationen am Code werden wohl schon nötig sein ;) ... da man diesen Zähler zuerst bei 300Bd initialisieren muss, um dann bei 2400Bd die Daten auszulesen.
Soviel habe ich schon herausfinden können.
Gruß,
Andreas
Servus,
Ich habe den Ultraheat T550, kann diesen mit Hife von dieser Site auslesen
http://www.sedelmaier.at
Weiss aber nicht, ob dies deinen Zähler auch unterstützt, aber vielleicht hilft es dir...
VG und viel Erfolg
Klaso
Hi Klaso,
vielen Dank für den Tipp. Ich vermute das es damit auch gehen wird, probiert habe ich es allerdings nicht.
Zum Auslesen unseres Wärmezählers (unabhängig von FHEM) habe ich im Netz eine alte Version von Pappawin gefunden.
Diese läuft allerdings nur unter Win XP, gibt mir aber denselben Output wie auch das von Dir empfohlene Python Skript.
Zumindest sollten die beiden Wärmezähler kompatibel sein, nur das sich meiner mit /LUGC2WR5 meldet.
Mit dem OBIS-Modul klappt es derzeit noch nicht... scheint noch irgendwelche Timing-Probleme zu geben.
Manchmal kommt nach dem SimpleWrite einfach nichts vom Zähler zurück und adjustAlign führt manchmal zum doppelten Auslösen von GetUpdate.
Aber gut... so einfach hatte ich es mir ja auch nicht vorgestellt. Noch habe ich nicht aufgegeben :D
Gruß,
Andreas
Ich habe immer wieder das Problem, dass beim Neustart von FHEM das alignTime Attribut verloren geht. Sofort, nachdem ich es gesetzt habe, mache ich ein "save config". Dennoch fehlt das Attribut nach dem nächsten Neustart von FHEM. Kann es sein, dass das Modul beim Start das gesetzte Attribut ignoriert?
Bei mir geht es nicht verloren.
Mal nach save und den 3 Zuständen(nach save, nach shutdown, nach restart) in die config gucken, um den Zeitpunkt des Verschwindens einzugrenzen.
Hatte ich noch nie, habs bei mir auch grade getestet....AlignTime (genauso wie alle anderen Attribute) überlebt nen restart genauso wie nen reboot...
lg, Stefan
Zitat von: KölnSolar am 03 Juli 2017, 10:03:17
Bei mir geht es nicht verloren.
Mal nach save und den 3 Zuständen(nach save, nach shutdown, nach restart) in die config gucken, um den Zeitpunkt des Verschwindens einzugrenzen.
Wird etwas dauern. Bin inzwischen im Urlaub.
Im config File steht das Attribut richtig drin mit 00:00:00, aber das UI meldet:
Messages collected while initializing FHEM:
configfile: OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified
Ein anderes alignTime Attribut mit 00:00:01 funktioniert problemlos. Könnte bitte jemand probieren, ob es an 00:00:00 liegt? Ich bin im Urlaub und kann nur mühsam per Handy testen.
Zitat von: willybauss am 04 Juli 2017, 18:05:25
Im config File steht das Attribut richtig drin mit 00:00:00, aber das UI meldet:
configfile: OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified
Hallo,
steht doch da, wenn das Attribut 00:00:00 ist, wird es nicht benötigt. Also Attribut alignTime löschen.
Gruß Friedrich
Ohne alignTime Attribut werden die Werte zu beliebigen Zeiten geloggt. Das Attribut brauche ich, um 00:00:00 zu erzwingen.
ich hab auch 00:00:00, damit immer zur vollen Minute gelesen wird. Dazu aber auch interval=60 und das scheinst Du ja nicht zu haben.
Doch. Interval=60 habe ich gesetzt.
Na dann wundert mich die Fehlermeldung
ZitatMessages collected while initializing FHEM:
configfile: OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified
die ich trotz gleichen Attributen nicht habe. Stell mal zum Abgleich ein list des Zählers ein.
Also, ein alignTime mit "00:00" in Kombination mit interval=60 funktioniert hier bei mir seit den Anfängen der Entwicklung dieses Moduls.
Tiefer gehende Analysen kann ich erst Ende nächster Woche machen. Bin grade nur mit dem Handy online.
Nochmal zurück zu dem Problem mit
Messages collected while initializing FHEM:
configfile: OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specifiedDas Problem hält sich hartnäckig.
Im config File ist das Attribut "interval = 60" drin und bleibt auch bei einem Restart drin.
Aber alignTime fliegt beim Restart aus der config raus, wohl wegen der o.g. Meldung.
Wenn ich alignTime neu setze, dann geht das fehlerfrei. Wenn ich aber "interval" lösche und dann alignTime setzen will, dann kommt eine Meldung wie oben (... braucht interval Attribut ...). Demnach erkennt das Modul zur Laufzeit durchaus, dass das interval Attribut da ist, nur nicht beim Start von fhem.
Im list ist interval ebenfalls sichtbar:
ZitatInternals:
DEF /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
DeviceName /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
MeterType Standard
NAME Hausstrom_Zaehler
NEXT 2017-08-06 21:31:01
NR 462
PARTIAL
STATE opened
TYPE OBIS
Readings:
2017-08-06 21:30:02 Owner 20836181
2017-08-06 21:30:02 P_Bezug_Watt 509
2017-08-06 21:30:02 P_Bezug_temp 508.963662646162
2017-08-06 21:30:02 P_Einsp_Watt 0
2017-08-06 21:30:02 P_Einsp_temp 0
2017-08-06 21:30:02 Serial 0002477555
2017-08-06 21:30:02 Status 82
2016-02-23 22:33:21 Version EMH5----eHZ-E0028E
2017-08-01 00:00:01 Zaehlerstand_Einspeis 43127.3925
2017-08-01 00:00:01 Zaehlerstand_Verbrauch 14737.2009
2017-01-07 21:15:32 statStateDay opened: 02:11:13 opened_Count: 1 (since: 2017-01-07_19:04:19)
2017-01-07 21:15:32 statStateMonth opened: 02:11:13 opened_Count: 1 (since: 2017-01-07_19:04:19)
2017-01-07 21:15:32 statStateYear opened: 02:11:13 opened_Count: 1 (since: 2017-01-07_19:04:19)
2017-01-07 21:14:31 statTotal_consumption_Ch1 Hour: 0.1232 Day: 1.2159 Month: 1.2159 Year: 1.2159 (since: 2017-01-07_19:13:30 )
2017-01-07 21:14:31 statTotal_consumption_Ch1Hour 0.1232
2017-01-07 20:59:55 statTotal_consumption_Ch1HourLast 0.6899
2017-01-07 20:59:55 statTotal_consumption_Ch1Last Hour: 0.6899 Day: - Month: - Year: -
2017-01-07 21:14:31 statTotal_feed_Ch1 Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 0.0000 (since: 2017-01-07_19:13:30 )
2017-01-07 21:14:31 statTotal_feed_Ch1Hour 0.0000
2017-01-07 20:59:55 statTotal_feed_Ch1HourLast 0.0000
2017-01-07 20:59:55 statTotal_feed_Ch1Last Hour: 0.0000 Day: - Month: - Year: -
2017-08-04 16:02:42 state opened
2017-08-06 21:30:02 total_consumption_Ch1 14768.253
2017-08-06 21:30:02 total_feed_Ch1 43260.7884
Helper:
BUFFER
EoM 1
SPEED 5
TRIGGERTIME 1502047861
Channels:
DEVICES:
60
Attributes:
alignTime 00:00:01
event-min-interval .*:5
event-on-change-reading .*
interval 60
pollingMode on
room Stromzaehler
userReadings P_Bezug_temp:total_consumption_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_consumption_Ch1",0)*3600000 },
P_Einsp_temp:total_feed_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_feed_Ch1",0)*3600000 },
P_Bezug_Watt:P_Bezug_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) },
P_Einsp_Watt:P_Einsp_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) },
P_Verbrauch_Watt:P_Einsp_Watt.* ({ sprintf("%.0f",ReadingsVal("PV_Zaehler","electricityPower",0)) } - { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_Watt",0)) })
verbose 3
Ich habe keinen Plan, woran es liegen könnte. Fällt an dem List Jemand was auf?
Oder braucht fhem beim Start eine bestimmte Reihenfolge im config Fiel oder in einem anderen File? Oder oder oder ... ???
Ich kann das zwar in keinster Weise nachvollziehen, aber einen Versuch ists alle mal wert, in der config zu schauen, ob "interval" vor dem "alignTime" definiert wird.
lg, Stefan
Zitat von: Icinger am 07 August 2017, 07:34:49
... in der config zu schauen, ob "interval" vor dem "alignTime" definiert wird.
lg, Stefan
Das war offenbar das Problem. Hab die Reihenfolge umgedreht und das Problem ist gelöst. Eigenartig, dass fhem selbst nicht in der Lage ist, sein eigenes config-File richtig zu sortieren. Spätestens, als ich die Attribute raus genommen und neu gesetzt hatte, hätte die Reihenfolge ja neu bestimmt werden müssen.
Besten Dank nochmal für die Hilfe.
Hallo,
ich habe auch ab und zu dieselben Meldungen im LOG wie firebal301 in Antwort #377:
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 348.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 356.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 357.
2017.05.12 20:48:53 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 327.
Gibt es hierfür eine Erklärung oder Lösung?
Ansonsten funktioniert das Auslesen des EMH-Stromzählers einwandfrei.
Danke
Zitat von: maci am 02 Juni 2017, 20:42:25
Sorry, ich hätte auch etwas genauer sein können.
Der Zähler ist ein TD-3511 von Siemens.
Das ist ein Zweirichtungszähler mit AMIS Kundenschnittstelle.
Die Ausgabe der Schnittstelle ist mit einem AES Code verschlüsselt.
Ich hoffe das sind die wichtigsten Infos.
hallo gibts jetzt schon die Möglichkeit mit dem Obis Modul ein Passwort zu übergeben?
mir hat Pejonp sein 99_td3511.pm Modul geschickt dass würde wahrscheinlich weiterhelfen.
leider hab ich es noch nicht geschafft dass ganze auch ohne Datenbank (somit überhaupt) zum laufen zu bringen.
ps.: ja bis jetzt habe ich mit dem Volkszähler ausgelesen, allerdings läuft der bei mir nicht Stabil, außderdem kann ich nicht fhem und VZ auf einem Gerät laufen lassen und zusätzlich möchte ich mich unbedingt von der Datenbank verabschieden und die Werte zu den restlichen Logfiles auf die tmpfs Partition legen.
lg
Nein, habe bisher noch gar nichts in Richtung AES unternommen.
Habe mir grade eben das td3511.pm angesehen, das hat aber auch gar nichts mit AES oder so am Hut, könnte eigentlich direkt durch mein OBIS ersetzt werden.
lg, Stefan
Zitat von: willybauss am 07 August 2017, 12:43:49
Das war offenbar das Problem. Hab die Reihenfolge von "interval" und "alignTime" umgedreht und das Problem ist gelöst. Eigenartig, dass fhem selbst nicht in der Lage ist, sein eigenes config-File richtig zu sortieren. Spätestens, als ich die Attribute raus genommen und neu gesetzt hatte, hätte die Reihenfolge ja neu bestimmt werden müssen.
Besten Dank nochmal für die Hilfe.
Das war wohl nichts. Aus irgendeinem Grund ist die Reihenfolge jetzt wieder falsch. Somit ist dasselbe Problem wieder da. Offenbar führt fhem da ein widerliches Eigenleben.
Hmm.....Das sollte sich morgen recht einfach fixen lassen......
Schau ich mir an.
lg, Stefan
Antw:Neues Modul: Easymeter (ersetzt durch 47_OBIS)
« Antwort #207 am: 21 August 2017, 01:12:08 »
Hallo,
ich habe an meinen Raspi einen Fototransistor angeschlossen und will damit gern das Modul betreiben.
LIRC ist installiert, und mit mode2 /dev/lirc0 bekomme ich auch Signale ausgegeben.
Dennoch kann ich den Empfänger in fhem nicht öffnen, ich bekomme die Fehlermeldung
"Can't open /dev/lirc0: Das Argument ist ungültig"
Es scheint eine Fehlermeldung des devIO zu sein. Was mache ich falsch
Nachdem ich mich vor längerer Zeit schon mal erkundigt habe.
Mein Zähler gibt die Daten im MBUS Format aus.
Ist wie schon mal gesagt ein TD-3511 von Siemens.
Daran montiert habe ich einen IR Lesekopf mit USB Anschluß
Derzeit lese ich die Daten mit dem Volkszähler aus.
Habe damit aber so meine Probleme. Ich bekomme nur Verbrauchsdaten, aber keinen Zählerstand.
lt. Beschreibung sollte der doch auch ausgegeben werden.
Aber das gehört nicht hierher.
Hallo Zusammen,
nun schliesse ich mich mal dem Thread an..
Da ich noch einen USB IR Schreib- / Lesekopf (volkszaehler.org) liegen hatte, habe ich diesen gestern mal mittels OBIS in Betrieb genommen. Er soll künftig die Daten eines Landis + Gyr E230, ZMR120ARe Stromzählers verarbeiten.
Nachdem ich mit etwas probieren herausfand, das ich den MeterType im Modul OBIS auf VSM102 (d0 Prokoll wäre vielleicht(?) treffender) und mich in die gute alte Zeit meines Akustikkopplers "Dataphon s21d" zurück entsinnte (300 Bit/s), "tröpfelten" dann auch schon die ersten Daten heraus. So weit, so gut... ;)
Allerdings gibt es Probleme beim Parsen der Daten, speziell bei folgenden:
total_consumption,
total_consumption_Ch1,
total_consumption_Ch2
Hier werden die Werte in einem Durchlauf mehrfach überschrieben. Das ist ja im ersten Moment nicht weiter tragisch, doch weichen die Werte jedesmal von einander ab. Ich bin jetzt nicht in die einzelnen Meldungen eingestiegen, was mir jedoch auffällt, zeige ich am Beispiel total_consumption_Ch1:
Folgende Events (gefiltert auf "Set total_consumption_Ch1") gehen bei einem Durchlauf ein:
2017.09.11 20:55:05 4: Set total_consumption_Ch1 to 5449.845
2017.09.11 20:55:19 4: Set total_consumption_Ch1 to 5373.721
2017.09.11 20:55:22 4: Set total_consumption_Ch1 to 5149.744
2017.09.11 20:55:26 4: Set total_consumption_Ch1 to 4925.983
2017.09.11 20:55:29 4: Set total_consumption_Ch1 to 4716.804
2017.09.11 20:55:33 4: Set total_consumption_Ch1 to 4498.873
2017.09.11 20:55:36 4: Set total_consumption_Ch1 to 4292.119
2017.09.11 20:55:40 4: Set total_consumption_Ch1 to 4254.031
2017.09.11 20:55:44 4: Set total_consumption_Ch1 to 4078.582
2017.09.11 20:55:47 4: Set total_consumption_Ch1 to 3874.128
2017.09.11 20:55:50 4: Set total_consumption_Ch1 to 3633.982
2017.09.11 20:55:54 4: Set total_consumption_Ch1 to 3408.986
2017.09.11 20:55:57 4: Set total_consumption_Ch1 to 3187.478
2017.09.11 20:56:01 4: Set total_consumption_Ch1 to 3174.357
2017.09.11 20:56:04 4: Set total_consumption_Ch1 to 2962.042
2017.09.11 20:56:08 4: Set total_consumption_Ch1 to 2757.815
Jeder einzelner Wert wird nun mit einem anderen reading multipliziert:
[...]
2017.09.11 21:05:05 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1(005449.923*kWh)
2017.09.11 21:05:05 5: Msg 1.8.1(005449.923*kWh) is of type Counter
2017.09.11 21:05:05 4: Set total_consumption_Ch1 to 5449.923
[...]
2017.09.11 21:05:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*29(17-09-01 00:00)
2017.09.11 21:05:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*29(29)
2017.09.11 21:05:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*29(005373.721)
2017.09.11 21:05:18 5: Msg 1.8.1*29(005373.721) is of type Counter
2017.09.11 21:05:18 4: Set total_consumption_Ch1 to 5373.721
[...]
2017.09.11 21:05:21 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*28(17-08-01 00:00)
2017.09.11 21:05:21 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*28(28)
2017.09.11 21:05:22 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*28(005149.744)
2017.09.11 21:05:22 5: Msg 1.8.1*28(005149.744) is of type Counter
2017.09.11 21:05:22 4: Set total_consumption_Ch1 to 5149.744
[...]
Warum ist das so? Mir erschliesst sich der Sinn nicht. Problem ist halt, das eigentlich nur der erste Wert korrekt ist und durch das laufende Überschreiben verloren geht. unitReadings ist im Übrigen auch davon betroffen und greift dann nicht mehr; beim ersten Wert werden diese noch gesetzt aber dann komplett "verdrängt". Mir erklären sich auch die Kanäle 0.1.015..29 nicht.
Hier mal eine Übersicht der aktuellen (passen nicht mehr zu den obigen) Werten:
Internals:
CFGFN
DEF /dev/cp210x01@300,7,E,1 VSM102
DeviceName /dev/cp210x01@300,7,E,1
MeterType VSM102
NAME KG.fl.SM.PWR.01
NEXT 2017-09-11 21:15:00
NR 78855
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2017-09-11 21:10:03 0.0.0 30369686
2017-09-11 21:10:03 0.0.1 00252625
2017-09-11 21:10:04 0.0.2
2017-09-11 21:11:07 0.1.0.15 15
2017-09-11 21:11:04 0.1.0.16 16
2017-09-11 21:11:01 0.1.0.17 17
2017-09-11 21:10:57 0.1.0.18 18
2017-09-11 21:10:53 0.1.0.19 19
2017-09-11 21:10:49 0.1.0.20 20
2017-09-11 21:10:47 0.1.0.21 21
2017-09-11 21:10:42 0.1.0.22 22
2017-09-11 21:10:39 0.1.0.23 23
2017-09-11 21:10:35 0.1.0.24 24
2017-09-11 21:10:32 0.1.0.25 25
2017-09-11 21:10:29 0.1.0.26 26
2017-09-11 21:10:25 0.1.0.27 27
2017-09-11 21:10:22 0.1.0.28 28
2017-09-11 21:10:18 0.1.0.29 29
2017-09-11 21:10:07 0.2.0 K53-0-C
2017-09-11 21:10:08 0.2.1 354 C
2017-09-11 21:10:08 0.2.2 4141
2017-09-11 21:10:10 0.9.1 21:11:38
2017-09-11 21:10:09 0.9.2 17-09-11
2017-09-11 21:10:13 36.7.0 0.36 kW
2017-09-11 21:10:13 56.7.0 0.01 kW
2017-09-11 21:10:14 76.7.0 0.15 kW
2017-09-11 21:10:16 C.3.0 0
2017-09-11 21:10:16 C.4.0 2800000
2017-09-11 21:10:15 C.5.0 0118E0F1
2017-09-11 21:10:16 C.7.0 0
2017-09-11 01:29:01 Version LGZ5ZMR120AR.K53
2017-09-11 21:10:11 current_L1 1.67 A
2017-09-11 21:10:12 current_L2 0.16 A
2017-09-11 21:10:12 current_L3 0.83 A
2017-09-11 21:10:14 power 0.53 kW
2017-09-11 01:26:01 state opened
2017-09-11 21:11:10 total_consumption 3881.264
2017-09-11 21:11:08 total_consumption_Ch1 2757.815
2017-09-11 21:11:09 total_consumption_Ch2 1123.449
2017-09-11 21:10:10 voltage_L1 231 V
2017-09-11 21:10:10 voltage_L2 232 V
2017-09-11 21:10:11 voltage_L3 233 V
helper:
BUFFER
EoM 1
SPEED 0
SPEED2 0
TRIGGERTIME 1505157300
Channels:
DEVICES:
/?!
300
000
Attributes:
alignTime 00:00:00
event-on-change-reading current_L1,current_L2,current_L3,power,total_consumption,total_consumption_Ch1,total_consumption_Ch2,voltage_L1,voltage_L2,voltage_L3
group Verbrauchsmessung
interval 300
pollingMode on
room KG Flur
unitReadings on
valueBracket first
verbose 5
Für Interessierte hänge ich mal eine (kurze) Bedienungsanleitung meines Zählers mit an, die die relevanten Werte wiedergibt.
Viele Grüße
Martin
Dir wird es nicht wirklich helfen, aber Stefan hat dann vielleicht weniger zu suchen:
Scheinbar hat Dein Zähler wie auch immer geartete "Zwischenstände" bzw. "Zeiträume". Nämlich genau die 0.1.0.15....0.1.0.29. Neben dem aktuellen Zählerstand haut der Zähler dann zusätzlich noch die "Zwischenstände" raus. Dafür wird die letzte Ziffer der OBIS-Kennzahl angefügt.
Zitat2017.09.11 21:05:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*29(005373.721)
@Stefan: Hi Stefan, Du müsstest also nach meiner Interpretation entweder die x.y.z*nn ignorieren oder eben als zusätzliche readings(halt ich aber nicht f. sinnvoll) anlegen.
@Martin: Vielleicht lassen sich aber die Zeiträume löschen/verändern, so dass ine Moduländerung nicht notwendig wird ? :-\
Grüße Markus
lassen sich die zusätzlichen Daten mit event-min-interval unterdrücken?
Hi Leute,
bin arbeiten, daher nur mal kurz:
Scheint ein sehr gesprächiger Zähler zu sein.
Martin's "Problem" lässt sich mit dem Channels-Attribut umgehen :)
lg, Stefan
Ich habe seit 2 Wochen einen neuen Zweirichtungszähler. ISKRA eHZ MT681-D4A5
Für die Einspeisung habe ich die Zählerstände als total_feed_Ch1 und total_feed_Ch1.
Beide Readings landen aber nicht im DBlog. Auch nicht mit 'attr Hausstrom DbLogInclude total_feed_Ch1,dir_total_consumption'.
Was mache ich falsch?
Das ist aber mMn eher ein DBLog-Problem.
Wie sieht denn die DBLog-Definition aus?
Am besten mal ein List von beiden Defs geben.
lg, Stefan
Klar, das wars. Ich Dämel.... :o
Trotzdem noch eine Frage. Ich lasse das Statistics Modul laufen. Es erzeugt aber nur Werte für die Stromeinkauf Readings, nicht aber für die Einspeisung (total_feed_Ch1 und total_feed_Ch1).
Hab ich da auch was übersehen?
Vermutlich auch wieder ein Config-Problem vom statistics-Modul.
Gib mal hier beide Lists bitte :D
ist mir das peinlich...
attr im deltaReadings war falsch. :P
Hihi, kann passieren, manchmal steht man einfach auf dem Kabel :D
Ich trau mich fast gar nicht zu fragen, aber wie ermittelt ihr den Eigenverbrauch?
Nur mit OBIS, es sei denn Du hast einen OBIS-Erzeugungszähler, gar nicht. Daher bitte neues Thema eröffnen, falls meine Antwort nicht ausreicht.
Definiere ein Userreading mit Eigenverbrauch = Bezug + Erzeugung(woher auch immer) - Einspeisung.
Zitat von: KölnSolar am 13 September 2017, 23:02:34
Definiere ein Userreading mit Eigenverbrauch = Bezug + Erzeugung(woher auch immer) - Einspeisung.
So habe ich es gemacht. Verbrauch/Einspeisung mit OBIS, Erzeugung mit JSONMETER (Youless 110). Obwohl ich beide Zählerauslesungen synchronisiert habe (alignTime-Attribut) passiert es immer wieder, dass die Berechnung zu "negativem Eigenverbrauch" führt, wenn sich z.B. an Tagen mit wolkigem Himmel und gleichzeitig schwankendem Verbrauch die Werte ungünstig addieren, sh. z.B. im Bild die blauen Zacken in den positiven Bereich zwischen 14 und 17 Uhr.
@Martin: Hat das mit dem Channels-Attribut jetzt geklappt?
Hallo Stefan,
Zitat von: Icinger am 16 September 2017, 08:22:51
@Martin: Hat das mit dem Channels-Attribut jetzt geklappt?
ich war ein paar Tage geschäftlich unterwegs, so dass ich noch nicht dazu kam. In wie fern soll das denn mit dem Channels Attribut Abhilfe schaffen? So wie ich lese, wird damit "nur" der Channel umbenannt. Dann werden diese nicht mehr als Multiplikator herangezogen?
Rein rhetorisch gefragt: Wie sollte ich denn die Channels nennen? ;)
Oder anders: Ich brauche diese Channels
0.1.015..29 ja vermutlich überhaupt nicht, da sie zum einen immer den selben Wert liefern und zum anderen (mir) nicht bekannt ist, was sich hinter diesen Channels "versteckt".
Da wäre es aus meiner Sicht einfacher (und besser) ein "ignoreChannels" oder ähnlich einzuführen. Warum sollte ich readings mitführen, die keinen Informationsgehalt haben und vermutlich nur mit "Platzhalterwerten" belegt sind.
Gruß Martin
Hmm, mir ist nicht ganz klar, wo du eine Multiplikation siehst.
Für mich stellt sich das eher so dar, dass die Messpunkte
1.8.1
1.8.1*29
1.8.1*28
usw
jeweils den Punkt 1.8.1 nacheinander überschreiben.
Das ist grundsätzlich schon mal richtig so, weil ich das *xx ausfiltere, weil jeder Zähler da andere Werte hinten hat leider.
Gibt zwar nen de-facto Standard, nur hält sich niemand genau daran :(
Mit einem
attr <dev> channels {"1.8.1.\d\d"=>"unused"}
könntest du die unnötigen 1.8.1er-Daten in ein "Nebenreading" schubsen, damit bleibt nur mehr der 1.8.1 alleine übrig.
Es gibt schon ein (hab gerade gesehen, dass ich das noch nicht dokumentiert habe)
attr <dev> ignoreUnknown on
Damit sollten die ganzen nicht zuordenbaren Readings dann nicht mehr gesetzt werden (bitte einmal ein deletereadings......... machen).
lg, Stefan
Hallo Stefan,
Zitat von: Icinger am 18 September 2017, 20:08:44
Hmm, mir ist nicht ganz klar, wo du eine Multiplikation siehst.
Das war natürlich Schmarn... Es war ein langer Tag und ich nicht bei der Sache ;)
Zitat
Für mich stellt sich das eher so dar, dass die Messpunkte
[...]
jeweils den Punkt 1.8.1 nacheinander überschreiben.
Korrekt.
Zitat
Mit einem
attr <dev> channels {"1.8.1.\d\d"=>"unused"}
könntest du die unnötigen 1.8.1er-Daten in ein "Nebenreading" schubsen, damit bleibt nur mehr der 1.8.1 alleine übrig.
PERL WARNING: Unrecognized escape \d passed through at (eval 1254292) line 1.Habe mal auf die Schnelle (ohne den Quelltext zu "auditieren" ;) ) verschiedene RegExp ausprobiert; keiner führte dazu, dass das Überschreiben ausbleibt.
Zitat
Es gibt schon ein (hab gerade gesehen, dass ich das noch nicht dokumentiert habe)
attr <dev> ignoreUnknown on
Damit sollten die ganzen nicht zuordenbaren Readings dann nicht mehr gesetzt werden (bitte einmal ein deletereadings......... machen).
ja, den hatte ich schon gesetzt.. ist aber nicht das was ich meinte. Ein "ignoreChannel" und dann eine Aufzählung der zu ignorierenden Channels halte ich für "selbsterklärender".
Dann machs umgekehrt:
attr <dev> attr <dev> channels {"1.8.1"=>"total_consumption_Ch1"}ZitatEin "ignoreChannel" und dann eine Aufzählung der zu ignorierenden Channels halte ich für "selbsterklärender".
Würde halt - zb in deinem Fall - zu einem endlos langen Wust führen und ein wenig Frustration (denke ich).
Kanns aber gern mal implementieren, jetzt kommt eh wieder die Zeit, wo man mehr drinnen als draussen ist gg
lg, Stefan
Zitat von: Icinger am 18 September 2017, 21:16:06
Dann machs umgekehrt:
attr <dev> attr <dev> channels {"1.8.1"=>"total_consumption_Ch1"}
Vielleicht könntest Du das, genau so wie den umgekehrten Fall, mal testen.. beides funktioniert nämlich nicht so, wie es in Deiner Theorie gedacht ist ;)
Attributes:
alignTime 00:00:00
channels {"1.8.0"=>"total_consumption","1.8.1"=>"total_consumption_Ch1", "1.8.2"=>"total_consumption_Ch2"}
group Verbrauchsmessung
ignoreUnknown on
interval 120
pollingMode on
room KG Flur
unitReadings on
verbose 5 2017.09.18 21:56:00 5: SW: 2f3f210d0a
2017.09.18 21:56:00 4: Wrote /?!
2017.09.18 21:56:00 5: OBIS (KG.fl.SM.PWR.01) - Internal timer set to 2017-09-18 21:58:00
2017.09.18 21:56:01 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: /LGZ5ZMR120AR.K53
2017.09.18 21:56:01 5: SW: 063030300d0a
2017.09.18 21:56:02 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: F.F.0(02000000)
2017.09.18 21:56:03 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.0.0(30369686)
2017.09.18 21:56:03 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.0.1(00252625)
2017.09.18 21:56:03 5: Msg 0.0.1(00252625) is of type Serial
2017.09.18 21:56:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.0.2( )
2017.09.18 21:56:04 5: Msg 0.0.2( ) is of type Serial
2017.09.18 21:56:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1(005501.426*kWh)
2017.09.18 21:56:06 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2(002374.749*kWh)
2017.09.18 21:56:06 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0(007876.175*kWh)
2017.09.18 21:56:07 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.2.0(K53-0-C)
2017.09.18 21:56:08 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.2.1(354C)
2017.09.18 21:56:08 5: Msg 0.2.1(354C) is of type Channels2
2017.09.18 21:56:08 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.2.2(4141 )
2017.09.18 21:56:08 5: Msg 0.2.2(4141 ) is of type Channels2
2017.09.18 21:56:08 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.9.2(17-09-18)
2017.09.18 21:56:09 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.9.1(21:57:47)
2017.09.18 21:56:09 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 32.7.0(231*V)
2017.09.18 21:56:09 5: Msg 32.7.0(231*V) is of type Channels
2017.09.18 21:56:10 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 52.7.0(231*V)
2017.09.18 21:56:10 5: Msg 52.7.0(231*V) is of type Channels
2017.09.18 21:56:10 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 72.7.0(231*V)
2017.09.18 21:56:10 5: Msg 72.7.0(231*V) is of type Channels
2017.09.18 21:56:11 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 31.7.0(001.34*A)
2017.09.18 21:56:11 5: Msg 31.7.0(001.34*A) is of type Channels
2017.09.18 21:56:11 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 51.7.0(000.15*A)
2017.09.18 21:56:11 5: Msg 51.7.0(000.15*A) is of type Channels
2017.09.18 21:56:12 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 71.7.0(000.81*A)
2017.09.18 21:56:12 5: Msg 71.7.0(000.81*A) is of type Channels
2017.09.18 21:56:12 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 36.7.0(000.25*kW)
2017.09.18 21:56:12 5: Msg 36.7.0(000.25*kW) is of type Channels
2017.09.18 21:56:14 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 56.7.0(000.00*kW)
2017.09.18 21:56:14 5: Msg 56.7.0(000.00*kW) is of type Channels
2017.09.18 21:56:14 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 76.7.0(000.14*kW)
2017.09.18 21:56:14 5: Msg 76.7.0(000.14*kW) is of type Channels
2017.09.18 21:56:15 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 16.7.0(000.42*kW)
2017.09.18 21:56:15 5: Msg 16.7.0(000.42*kW) is of type Channels
2017.09.18 21:56:16 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: C.5.0(0118E0F1)
2017.09.18 21:56:16 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: C.3.0(00000000)
2017.09.18 21:56:17 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: C.4.0(02800000)
2017.09.18 21:56:17 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: C.7.0(0000)
2017.09.18 21:56:17 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*29(17-09-01 00:00)
2017.09.18 21:56:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*29(29)
2017.09.18 21:56:18 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*29(005373.721)
2017.09.18 21:56:18 5: Msg 1.8.1*29(005373.721) is of type Counter
2017.09.18 21:56:18 4: Set total_consumption_Ch1 to 5373.721
2017.09.18 21:56:19 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*29(002315.411)
2017.09.18 21:56:19 5: Msg 1.8.2*29(002315.411) is of type Counter
2017.09.18 21:56:19 4: Set total_consumption_Ch2 to 2315.411
2017.09.18 21:56:21 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*29(007689.132)
2017.09.18 21:56:21 5: Msg 1.8.0*29(007689.132) is of type Counter
2017.09.18 21:56:21 4: Set total_consumption to 7689.132
2017.09.18 21:56:22 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*28(17-08-01 00:00)
2017.09.18 21:56:22 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*28(28)
2017.09.18 21:56:22 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*28(005149.744)
2017.09.18 21:56:22 5: Msg 1.8.1*28(005149.744) is of type Counter
2017.09.18 21:56:22 4: Set total_consumption_Ch1 to 5149.744
2017.09.18 21:56:23 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*28(002211.632)
2017.09.18 21:56:23 5: Msg 1.8.2*28(002211.632) is of type Counter
2017.09.18 21:56:23 4: Set total_consumption_Ch2 to 2211.632
2017.09.18 21:56:24 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*28(007361.376)
2017.09.18 21:56:24 5: Msg 1.8.0*28(007361.376) is of type Counter
2017.09.18 21:56:24 4: Set total_consumption to 7361.376
2017.09.18 21:56:25 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*27(17-07-01 00:00)
2017.09.18 21:56:26 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*27(27)
2017.09.18 21:56:26 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*27(004925.983)
2017.09.18 21:56:26 5: Msg 1.8.1*27(004925.983) is of type Counter
2017.09.18 21:56:26 4: Set total_consumption_Ch1 to 4925.983
2017.09.18 21:56:27 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*27(002101.737)
2017.09.18 21:56:27 5: Msg 1.8.2*27(002101.737) is of type Counter
2017.09.18 21:56:27 4: Set total_consumption_Ch2 to 2101.737
2017.09.18 21:56:27 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*27(007027.720)
2017.09.18 21:56:27 5: Msg 1.8.0*27(007027.720) is of type Counter
2017.09.18 21:56:27 4: Set total_consumption to 7027.72
2017.09.18 21:56:28 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*26(17-06-01 00:00)
2017.09.18 21:56:28 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*26(26)
2017.09.18 21:56:29 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*26(004716.804)
2017.09.18 21:56:29 5: Msg 1.8.1*26(004716.804) is of type Counter
2017.09.18 21:56:29 4: Set total_consumption_Ch1 to 4716.804
2017.09.18 21:56:30 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*26(002003.413)
2017.09.18 21:56:30 5: Msg 1.8.2*26(002003.413) is of type Counter
2017.09.18 21:56:30 4: Set total_consumption_Ch2 to 2003.413
2017.09.18 21:56:31 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*26(006720.217)
2017.09.18 21:56:31 5: Msg 1.8.0*26(006720.217) is of type Counter
2017.09.18 21:56:31 4: Set total_consumption to 6720.217
2017.09.18 21:56:32 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*25(17-05-01 00:00)
2017.09.18 21:56:32 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*25(25)
2017.09.18 21:56:33 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*25(004498.873)
2017.09.18 21:56:33 5: Msg 1.8.1*25(004498.873) is of type Counter
2017.09.18 21:56:33 4: Set total_consumption_Ch1 to 4498.873
2017.09.18 21:56:34 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*25(001900.229)
2017.09.18 21:56:34 5: Msg 1.8.2*25(001900.229) is of type Counter
2017.09.18 21:56:34 4: Set total_consumption_Ch2 to 1900.229
2017.09.18 21:56:34 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*25(006399.102)
2017.09.18 21:56:34 5: Msg 1.8.0*25(006399.102) is of type Counter
2017.09.18 21:56:34 4: Set total_consumption to 6399.102
2017.09.18 21:56:35 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*24(17-04-01 00:00)
2017.09.18 21:56:36 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*24(24)
2017.09.18 21:56:36 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*24(004292.119)
2017.09.18 21:56:36 5: Msg 1.8.1*24(004292.119) is of type Counter
2017.09.18 21:56:36 4: Set total_consumption_Ch1 to 4292.119
2017.09.18 21:56:37 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*24(001805.232)
2017.09.18 21:56:37 5: Msg 1.8.2*24(001805.232) is of type Counter
2017.09.18 21:56:37 4: Set total_consumption_Ch2 to 1805.232
2017.09.18 21:56:37 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*24(006097.351)
2017.09.18 21:56:37 5: Msg 1.8.0*24(006097.351) is of type Counter
2017.09.18 21:56:37 4: Set total_consumption to 6097.351
2017.09.18 21:56:38 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*23(17-03-26 03:00)
2017.09.18 21:56:39 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*23(23)
2017.09.18 21:56:39 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*23(004254.031)
2017.09.18 21:56:39 5: Msg 1.8.1*23(004254.031) is of type Counter
2017.09.18 21:56:39 4: Set total_consumption_Ch1 to 4254.031
2017.09.18 21:56:41 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*23(001788.109)
2017.09.18 21:56:41 5: Msg 1.8.2*23(001788.109) is of type Counter
2017.09.18 21:56:41 4: Set total_consumption_Ch2 to 1788.109
2017.09.18 21:56:42 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*23(006042.140)
2017.09.18 21:56:42 5: Msg 1.8.0*23(006042.140) is of type Counter
2017.09.18 21:56:42 4: Set total_consumption to 6042.14
2017.09.18 21:56:42 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*22(17-03-01 00:00)
2017.09.18 21:56:42 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*22(22)
2017.09.18 21:56:43 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*22(004078.582)
2017.09.18 21:56:43 5: Msg 1.8.1*22(004078.582) is of type Counter
2017.09.18 21:56:43 4: Set total_consumption_Ch1 to 4078.582
2017.09.18 21:56:44 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*22(001709.101)
2017.09.18 21:56:44 5: Msg 1.8.2*22(001709.101) is of type Counter
2017.09.18 21:56:44 4: Set total_consumption_Ch2 to 1709.101
2017.09.18 21:56:44 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*22(005787.683)
2017.09.18 21:56:44 5: Msg 1.8.0*22(005787.683) is of type Counter
2017.09.18 21:56:44 4: Set total_consumption to 5787.683
2017.09.18 21:56:45 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*21(17-02-01 00:00)
2017.09.18 21:56:47 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*21(21)
2017.09.18 21:56:47 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*21(003874.128)
2017.09.18 21:56:47 5: Msg 1.8.1*21(003874.128) is of type Counter
2017.09.18 21:56:47 4: Set total_consumption_Ch1 to 3874.128
2017.09.18 21:56:47 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*21(001618.911)
2017.09.18 21:56:47 5: Msg 1.8.2*21(001618.911) is of type Counter
2017.09.18 21:56:47 4: Set total_consumption_Ch2 to 1618.911
2017.09.18 21:56:48 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*21(005493.039)
2017.09.18 21:56:48 5: Msg 1.8.0*21(005493.039) is of type Counter
2017.09.18 21:56:48 4: Set total_consumption to 5493.039
2017.09.18 21:56:49 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*20(17-01-01 00:00)
2017.09.18 21:56:49 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*20(20)
2017.09.18 21:56:50 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*20(003633.982)
2017.09.18 21:56:50 5: Msg 1.8.1*20(003633.982) is of type Counter
2017.09.18 21:56:50 4: Set total_consumption_Ch1 to 3633.982
2017.09.18 21:56:52 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*20(001517.557)
2017.09.18 21:56:52 5: Msg 1.8.2*20(001517.557) is of type Counter
2017.09.18 21:56:52 4: Set total_consumption_Ch2 to 1517.557
2017.09.18 21:56:52 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*20(005151.539)
2017.09.18 21:56:52 5: Msg 1.8.0*20(005151.539) is of type Counter
2017.09.18 21:56:52 4: Set total_consumption to 5151.539
2017.09.18 21:56:53 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*19(16-12-01 00:00)
2017.09.18 21:56:53 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*19(19)
2017.09.18 21:56:54 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*19(003408.986)
2017.09.18 21:56:54 5: Msg 1.8.1*19(003408.986) is of type Counter
2017.09.18 21:56:54 4: Set total_consumption_Ch1 to 3408.986
2017.09.18 21:56:54 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*19(001418.385)
2017.09.18 21:56:54 5: Msg 1.8.2*19(001418.385) is of type Counter
2017.09.18 21:56:54 4: Set total_consumption_Ch2 to 1418.385
2017.09.18 21:56:55 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*19(004827.371)
2017.09.18 21:56:55 5: Msg 1.8.0*19(004827.371) is of type Counter
2017.09.18 21:56:55 4: Set total_consumption to 4827.371
2017.09.18 21:56:56 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*18(16-11-01 00:00)
2017.09.18 21:56:56 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*18(18)
2017.09.18 21:56:57 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*18(003187.478)
2017.09.18 21:56:57 5: Msg 1.8.1*18(003187.478) is of type Counter
2017.09.18 21:56:57 4: Set total_consumption_Ch1 to 3187.478
2017.09.18 21:56:58 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*18(001322.390)
2017.09.18 21:56:58 5: Msg 1.8.2*18(001322.390) is of type Counter
2017.09.18 21:56:58 4: Set total_consumption_Ch2 to 1322.39
2017.09.18 21:56:59 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*18(004509.868)
2017.09.18 21:56:59 5: Msg 1.8.0*18(004509.868) is of type Counter
2017.09.18 21:56:59 4: Set total_consumption to 4509.868
2017.09.18 21:57:00 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*17(16-10-30 02:00)
2017.09.18 21:57:00 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*17(17)
2017.09.18 21:57:00 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*17(003174.357)
2017.09.18 21:57:00 5: Msg 1.8.1*17(003174.357) is of type Counter
2017.09.18 21:57:00 4: Set total_consumption_Ch1 to 3174.357
2017.09.18 21:57:01 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*17(001316.803)
2017.09.18 21:57:01 5: Msg 1.8.2*17(001316.803) is of type Counter
2017.09.18 21:57:01 4: Set total_consumption_Ch2 to 1316.803
2017.09.18 21:57:02 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*17(004491.160)
2017.09.18 21:57:02 5: Msg 1.8.0*17(004491.160) is of type Counter
2017.09.18 21:57:02 4: Set total_consumption to 4491.16
2017.09.18 21:57:03 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*16(16-10-01 00:00)
2017.09.18 21:57:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*16(16)
2017.09.18 21:57:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*16(002962.042)
2017.09.18 21:57:04 5: Msg 1.8.1*16(002962.042) is of type Counter
2017.09.18 21:57:04 4: Set total_consumption_Ch1 to 2962.042
2017.09.18 21:57:06 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*16(001219.258)
2017.09.18 21:57:06 5: Msg 1.8.2*16(001219.258) is of type Counter
2017.09.18 21:57:06 4: Set total_consumption_Ch2 to 1219.258
2017.09.18 21:57:06 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*16(004181.300)
2017.09.18 21:57:06 5: Msg 1.8.0*16(004181.300) is of type Counter
2017.09.18 21:57:06 4: Set total_consumption to 4181.3
2017.09.18 21:57:07 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*15(16-09-01 00:00)
2017.09.18 21:57:07 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 0.1.0*15(15)
2017.09.18 21:57:08 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*15(002757.815)
2017.09.18 21:57:08 5: Msg 1.8.1*15(002757.815) is of type Counter
2017.09.18 21:57:08 4: Set total_consumption_Ch1 to 2757.815
2017.09.18 21:57:08 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.2*15(001123.449)
2017.09.18 21:57:08 5: Msg 1.8.2*15(001123.449) is of type Counter
2017.09.18 21:57:08 4: Set total_consumption_Ch2 to 1123.449
2017.09.18 21:57:09 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.0*15(003881.264)
2017.09.18 21:57:09 5: Msg 1.8.0*15(003881.264) is of type Counter
2017.09.18 21:57:09 4: Set total_consumption to 3881.264
2017.09.18 21:57:09 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: !
Zitat von: Martin Fischer am 18 September 2017, 21:58:57
Vielleicht könntest Du das, genau so wie den umgekehrten Fall, mal testen.. beides funktioniert nämlich nicht so, wie es in Deiner Theorie gedacht ist ;)
FHEM (myhce01)> inform timer KG.fl.SM.PWR.01
2017-09-18 22:03:04 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 005501.443*kWh
2017-09-18 22:03:05 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 002374.786*kWh
2017-09-18 22:03:06 OBIS KG.fl.SM.PWR.01 total_consumption: 007876.229*kWh
2017-09-18 22:03:09 OBIS KG.fl.SM.PWR.01 voltage_L1: 230 V
2017-09-18 22:03:09 OBIS KG.fl.SM.PWR.01 voltage_L2: 230 V
2017-09-18 22:03:10 OBIS KG.fl.SM.PWR.01 voltage_L3: 231 V
2017-09-18 22:03:10 OBIS KG.fl.SM.PWR.01 current_L1: 1.32 A
2017-09-18 22:03:11 OBIS KG.fl.SM.PWR.01 current_L2: 0.16 A
2017-09-18 22:03:12 OBIS KG.fl.SM.PWR.01 current_L3: 0.81 A
2017-09-18 22:03:14 OBIS KG.fl.SM.PWR.01 power: 0.53 kW
2017-09-18 22:03:18 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 5373.721
2017-09-18 22:03:19 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 2315.411
2017-09-18 22:03:20 OBIS KG.fl.SM.PWR.01 total_consumption: 7689.132
2017-09-18 22:03:22 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 5149.744
2017-09-18 22:03:23 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 2211.632
2017-09-18 22:03:23 OBIS KG.fl.SM.PWR.01 total_consumption: 7361.376
2017-09-18 22:03:25 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4925.983
2017-09-18 22:03:26 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 2101.737
2017-09-18 22:03:27 OBIS KG.fl.SM.PWR.01 total_consumption: 7027.72
2017-09-18 22:03:29 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4716.804
2017-09-18 22:03:30 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 2003.413
2017-09-18 22:03:30 OBIS KG.fl.SM.PWR.01 total_consumption: 6720.217
2017-09-18 22:03:32 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4498.873
2017-09-18 22:03:33 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1900.229
2017-09-18 22:03:34 OBIS KG.fl.SM.PWR.01 total_consumption: 6399.102
2017-09-18 22:03:36 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4292.119
2017-09-18 22:03:37 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1805.232
2017-09-18 22:03:37 OBIS KG.fl.SM.PWR.01 total_consumption: 6097.351
2017-09-18 22:03:39 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4254.031
2017-09-18 22:03:40 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1788.109
2017-09-18 22:03:41 OBIS KG.fl.SM.PWR.01 total_consumption: 6042.14
2017-09-18 22:03:43 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 4078.582
2017-09-18 22:03:44 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1709.101
2017-09-18 22:03:44 OBIS KG.fl.SM.PWR.01 total_consumption: 5787.683
2017-09-18 22:03:46 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 3874.128
2017-09-18 22:03:47 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1618.911
2017-09-18 22:03:48 OBIS KG.fl.SM.PWR.01 total_consumption: 5493.039
2017-09-18 22:03:50 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 3633.982
2017-09-18 22:03:52 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1517.557
2017-09-18 22:03:52 OBIS KG.fl.SM.PWR.01 total_consumption: 5151.539
2017-09-18 22:03:53 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 3408.986
2017-09-18 22:03:54 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1418.385
2017-09-18 22:03:55 OBIS KG.fl.SM.PWR.01 total_consumption: 4827.371
2017-09-18 22:03:57 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 3187.478
2017-09-18 22:03:58 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1322.39
2017-09-18 22:03:58 OBIS KG.fl.SM.PWR.01 total_consumption: 4509.868
2017-09-18 22:04:00 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 3174.357
2017-09-18 22:04:01 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1316.803
2017-09-18 22:04:02 OBIS KG.fl.SM.PWR.01 total_consumption: 4491.16
2017-09-18 22:04:04 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 2962.042
2017-09-18 22:04:05 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1219.258
2017-09-18 22:04:05 OBIS KG.fl.SM.PWR.01 total_consumption: 4181.3
2017-09-18 22:04:07 OBIS KG.fl.SM.PWR.01 total_consumption_Ch1: 2757.815
2017-09-18 22:04:08 OBIS KG.fl.SM.PWR.01 total_consumption_Ch2: 1123.449
2017-09-18 22:04:09 OBIS KG.fl.SM.PWR.01 total_consumption: 3881.264
Holla, das ist ja mal ne Datenflut, so einen gesprächigen hatte ich noch nie :)
Schau ich mir an. Wenn der Wetterbericht stimmt und es morgen den ganzen Tag schüttet, hab ich Zeit :)
lg, Stefan
Hallo Martin,
tja, da hatte ich gestern abend auch einen Aussetzer :D
Du musst beim Channel-Attribut einen anderen Readingsnamen verwenden, zB
attr <dev> channels {"1.8.1"=>"irgendwas"}
Das Problem mit dem Überschreiben ist dann erstmal aus der Welt.
Für den "Standard"-Readingsnamen greift ja bei den anderen Datensätzen immer noch die rudimentäre RegEx im Modul.
Und diese ist halt recht allgemein gehalten, da viele Zähler irgendwelche anderen Zahlen hinter dem 1.8.1xxxxxxx für ein und den selben Wert nehmen :( (soviel wieder mal zum "Standard")
lg, Stefan
Hallo Stefan,
Zitat von: Icinger am 19 September 2017, 15:20:26
Du musst beim Channel-Attribut einen anderen Readingsnamen verwenden, zB
attr <dev> channels {"1.8.1"=>"irgendwas"}
Das Problem mit dem Überschreiben ist dann erstmal aus der Welt.
mit Verlaub: das ist aus meiner Sicht keine Lösung. Warum sollte ich die "regulären" Channels:
1.8.0 = total_consumption
1.8.1 = total_consumption_Ch1
1.8.2 = total_consumption_Ch2jeweils nach "
irgendwas[_Ch[1|2]]" schieben um das Problem des Überschreibens zu "umgehen"?
Mein Landys + Gyr Zähler liefert schon die korrekten Werte bei den entsprechenden Teilen "
C.D.E" der OBIS-Kennzahlen:
1.8.0 Wirkarbeit Bezug gesamt (Summe aller tarifunterschiedenen Zählerstände)
1.8.1 Wirkarbeit Bezug Tarif 1 (Zählerstand zeitabhängiger Tarif 1)
1.8.2 Wirkarbeit Bezug Tarif 2 (Zählerstand zeitabhängiger Tarif 2)Man will doch an dieser Stelle die "regulären" Channels nicht zu Gunsten eines "Workarounds" aufgeben, bzw. in ein anderes Reading schieben. Also ich zumindest nicht. ;)
Darüber hinaus liefert mein Zähler aber auch 15 Vorwerte. Hier am Beispiel "Zählerstand zeitabhängiger Tarif 1":
2017.09.19 17:18:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1(005506.056*kWh)
2017.09.19 17:18:19 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*29(005373.721)
2017.09.19 17:18:22 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*28(005149.744)
2017.09.19 17:18:26 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*27(004925.983)
2017.09.19 17:18:29 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*26(004716.804)
2017.09.19 17:18:33 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*25(004498.873)
2017.09.19 17:18:36 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*24(004292.119)
2017.09.19 17:18:40 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*23(004254.031)
2017.09.19 17:18:44 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*22(004078.582)
2017.09.19 17:18:47 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*21(003874.128)
2017.09.19 17:18:50 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*20(003633.982)
2017.09.19 17:18:54 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*19(003408.986)
2017.09.19 17:18:58 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*18(003187.478)
2017.09.19 17:19:01 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*17(003174.357)
2017.09.19 17:19:04 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*16(002962.042)
2017.09.19 17:19:09 5: OBIS (KG.fl.SM.PWR.01) - Msg-Parse: 1.8.1*15(002757.815)
Dein "Workaround" verlagert ja nur das eigentliche Problem:
Die eigentlichen Channels werden in "neue" Readings verschoben; die regulären Readings werden aber weiterhin durch die Vorwerte überschrieben. Das ist nicht ganz so im Sinne der "Philosophie" von FHEM: 1 Reading = 1 Wert = 1 Timestamp. Hier wird jedoch bei "einem Lauf" das Reading mehrfach mit neuen Werten überschrieben.
Zum einen könnte man diese Vorwerte durchaus in FHEM verwenden und in entsprechende Readings schieben und daraus Deltas bilden. Dazu müsste aber auch der Zeitpunkt des jeweiligen Vorzählerwertes bekannt sein. Ich habe jetzt nicht alle OBIS Kennzahlen gesichtet aber evtl. gibt es ja ein Channel in der ein passender Interval oder Zeitstempel steht, der auf die jeweiligen Vorwerte zutrifft.
Zum anderen ist hier durch das Trennzeichen '*' aber auch klar ersichtlich, das es sich um diese Vorwerte handelt. Diese kann man also sehr einfach parsen und ggf. ignorieren, sofern Du dies in die Logik aufnehmen würdest und ggf. ein neues Attribut spendierst. Somit können dann die Kennzahlen in das vorgesehen Reading geschrieben werden und man muss nicht erst ein "irgendwas" Reading zudichten.
In der Darstellung der Werte ist meiner Meinung nach ein Fehler. Setzt man das Attribut
unitReadings auf
on, dann sehen die Werte wie folgt aus:
2017-09-19 17:30:06 foo_consumption 007884.126*kWh
2017-09-19 17:30:04 foo_consumption_Ch1 005506.126*kWh
2017-09-19 17:30:05 foo_consumption_Ch2 002378.000*kWh
2017-09-19 17:30:15 power 0.33 kW
2017-09-18 21:43:26 state opened
2017-09-19 17:30:37 total_consumption 6097.351
2017-09-19 17:30:36 total_consumption_Ch1 4292.119
2017-09-19 17:30:37 total_consumption_Ch2 1805.232 Dabei entsprechen die "
foo_" Werte den "verschobenen" Channels 1.8.[0-2] und die "
total_" Werte den sich überschreibenden Werten. Bei gesetztem Attribut
unitReadings sollte meiner Meinung nach noch etwas "Housekeeping" durchgeführt und die führenden Nullen entfernt und die Maßeinheit mittels Leerstelle und nicht dem '*' getrennt werden.
Ich würde mich freuen, wenn Du diese Änderungen übernehmen könntest. Andere Installationen sollte das nicht beeinflussen.
Viele Grüße
Martin
Hallo Martin,
Zitatmit Verlaub: das ist aus meiner Sicht keine Lösung.
Es ist eine kurzfristige Lösung, aber keine langfristige, da geb ich dir durchaus recht.
ZitatMan will doch an dieser Stelle die "regulären" Channels nicht zu Gunsten eines "Workarounds" aufgeben, bzw. in ein anderes Reading schieben. Also ich zumindest nicht.
Das streite ich dir auch nicht ab. Bislang war allerdings der Bedarf dafür nicht gegeben.
Das mit den Vorwerten ist mir auch neu und habe ich wohl bei meinen Recherchen übersehen bzw. wurde ich auch bislang nicht darauf hingewiesen.
Da mein Zähler das nicht sendet, ist mir das auch nie aufgefallen.
Auch nicht bei den verschiedenen Test-Daten, die ich von anderen Usern habe.
ZitatDazu müsste aber auch der Zeitpunkt des jeweiligen Vorzählerwertes bekannt sein. Ich habe jetzt nicht alle OBIS Kennzahlen gesichtet aber evtl. gibt es ja ein Channel in der ein passender Interval oder Zeitstempel steht, der auf die jeweiligen Vorwerte zutrifft.
Ich sehe in deinen Beispieldaten keine Hinweise auf irgendwelche Zeitstempel, du kannst mich aber gerne mit der Nase daraufstoßen.
ZitatBei gesetztem Attribut unitReadings sollte meiner Meinung nach noch etwas "Housekeeping" durchgeführt und die führenden Nullen entfernt und die Maßeinheit mittels Leerstelle und nicht dem '*' getrennt werden.
Eigentlich WIRD dieses Housekeeping durchgeführt, bei den anderen Werten stimmt es ja auch:
2017-09-19 19:02:54 current_L1 1.34 A
2017-09-19 19:02:54 current_L2 0.15 A
2017-09-19 19:02:54 current_L3 0.81 A
2017-09-19 19:02:54 power 0.42 kW
2017-09-19 19:02:54 voltage_L1 231 V
2017-09-19 19:02:54 voltage_L2 231 V
2017-09-19 19:02:54 voltage_L3 231 V Warum dem bei den kWh nicht so ist, werde ich mir ansehen.
Das sind übrigens die Daten von deinem gestrigen Post.
Wie gesagt, kurzfristige Lösung steht oben.
Längerfristige Lösung dauert sicher noch ein wenig.
Ich habe aktuell dank 10-Stunden-Tag plus einer Stunde Autofahrt davor und danach sowie Haus, Garten, Baustelle nicht wirklich viel Zeit.
Sehe zwar täglich kurz als Zeitvertreib hier in Forum, allerdings fehlt mir eben aktuell die Muße, mich erst wieder in den Code einzulesen.
Aber ich habs als ToDo ganz oben stehn und sobald ich nichts mehr draussen machen kann, kommt das an die Reihe.
Schönen Abend noch,
Stefan
Hallo zusammen,
seit ca. 1 Jahr nutze ich FHEM mit zwave, Jeelink und lese meine THZ 300 AL aus. Plus meine 2 Stromzähler, bisher mit SMLUSB. Ich habe UDOs Leseköpfe im Einsatz. Leider musste nun der eine Zähler getauscht werden. Es wurde ein Logarex LK1 verbaut. Aber irgendwie bekomme ich OBIS nicht ans fliegen.
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F2EC44-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F2EC44-if00-port0@9600,8,N,1
FD 11
MeterType SML
NAME wpZaehler
NR 49
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2017-10-28 17:13:20 1.0.0.0.9.255 04-03-9F-C6-8A-4B-90-8E
2017-10-28 17:13:20 129.129.199.130.3.255 EMH
2017-10-28 17:13:20 129.129.199.130.5.255 04AC-C325-9506-5A7B-17E4-EC3D-F85A-C6F5-267C-0A39-3175-7C93-5265-4324-8D78-7528-FA29-EDCF-A973-2D0D-F419-DDD0-3B3E-1B90-01
2017-10-28 17:08:43 Version EMH\04039FC68A4B908E
2017-10-28 17:13:20 dir_total_consumption in
2017-10-28 17:13:20 dir_total_feed in
2017-10-28 17:13:20 power 553.6
2017-10-28 17:08:30 state opened
2017-10-28 17:13:20 total_consumption 20112101.6
2017-10-28 17:13:20 total_consumption_Ch1 20112101.6
2017-10-28 17:13:20 total_consumption_Ch2 0
2017-10-28 17:13:20 total_feed 469.4
2017-10-28 17:13:20 total_feed_Ch1 469.4
helper:
BUFFER
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1509203310.90527
Channels:
DEVICES:
Im Log bekomme ich folgendes
2017.10.28 16:28:50 5: SML-Parse 1B1B1B1B010101017607000A1FB24B58620062007263010176010107000A0A95C3C80904039FC68A4B908E010163E486007607000A1FB24B59620062007263070177010904039FC68A4B908E01726201650A95C1DB7977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFCCDAB0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Full message-> 1B1B1B1B010101017607000A1FB24B58620062007263010176010107000A0A95C3C80904039FC68A4B908E010163E486007607000A1FB24B59620062007263070177010904039FC68A4B908E01726201650A95C1DB7977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFCCDAB0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=1B1B1B1B010101017607000A1FB24B58620062007263010176010107000A0A95C3C80904039FC68A4B908E010163E486007607000A1FB24B59620062007263070177010904039FC68A4B908E01726201650A95C1DB7977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFCCDAB0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFCCDAB0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100010800FF63018201621E52FF56000BFCCDAB0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100010801FF0101621E52FF56000BFCCDAB0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=01770701000F0700FF0101621B52FF55000014140177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 5: OBIS: Telegram=0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B900101016332C0007607000A1FB24B5C62006200726302017101633630000000001B1B1B1B1A031C93
2017.10.28 16:28:50 4: MSG IS:
/EMH\04039FC68A4B908E
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(04039FC68A4B908E)
1-0:1.8.0*255(>20111709.9*Wh)
1-0:2.8.0*255(>469.4*Wh)
1-0:1.8.1*255(20111709.9*Wh)
1-0:2.8.1*255(469.4*Wh)
1-0:1.8.2*255(0*Wh)
1-0:15.7.0*255(514*W)
129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001)
!
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: /EMH\04039FC68A4B908E
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.10.28 16:28:50 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:0.0.9*255(04039FC68A4B908E)
2017.10.28 16:28:50 5: Msg 1-0:0.0.9*255(04039FC68A4B908E) is of type Serial
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.0*255(>20111709.9*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.0*255(>20111709.9*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption to 20111709.9
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.0*255(>469.4*Wh)
2017.10.28 16:28:50 5: Msg 1-0:2.8.0*255(>469.4*Wh) is of type Counter
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.1*255(20111709.9*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.1*255(20111709.9*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption_Ch1 to 20111709.9
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.1*255(469.4*Wh)
2017.10.28 16:28:50 5: Msg 1-0:2.8.1*255(469.4*Wh) is of type Counter
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.2*255(0*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption_Ch2 to 0
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:15.7.0*255(514*W)
2017.10.28 16:28:50 5: Msg 1-0:15.7.0*255(514*W) is of type Channels
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001)
2017.10.28 16:28:50 5: Msg 129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001) is of type PublicKey
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: !
Der Zähler hat zwei Tarife, der 1.8.1 liegt bei ca. 7 KW und der Nacht 1.8.2 liegt bei 2.2 KW.
Leider bekomme ich nur die Werte für Power, plus Werte die ich nicht zuordnen kann?!
Die Aktualisierung erfolgt sekundlich, habe auch schon mit anderen Einstellungen gespielt, doch leider bekomme ich dann keine Werte.
@9600,8,N,1 SML, ist die einzige Einstellung mit der ich Werte bekomme.
Wenn ich mir das Telegram aus dem Log anschaue, sind definitiv Einträge für die Werte der Zählerstände vorhanden wenn ich mich nicht täusche.
'77070100010801FF' => 'Zählerstand-Tarif-1-Bezug',
'77070100010802FF' => 'Zählerstand-Tarif-2-Bezug',
aber ich bekomme sie nicht angezeigt.
Freue mich auf eure Hilfe.
Vielen Dank
Marcus
ich versteh Deine Frage nicht :-\
Zitat2017-10-28 17:13:20 total_consumption 20112101.6
2017-10-28 17:13:20 total_consumption_Ch1 20112101.6
2017-10-28 17:13:20 total_consumption_Ch2 0
2017-10-28 17:13:20 total_feed 469.4
2017-10-28 17:13:20 total_feed_Ch1 469.4
sind doch Zählerstandsreadings, die hier entstanden sind
Zitat2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.0*255(>20111709.9*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.0*255(>20111709.9*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption to 20111709.9
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.0*255(>469.4*Wh)
2017.10.28 16:28:50 5: Msg 1-0:2.8.0*255(>469.4*Wh) is of type Counter
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.1*255(20111709.9*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.1*255(20111709.9*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption_Ch1 to 20111709.9
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.1*255(469.4*Wh)
2017.10.28 16:28:50 5: Msg 1-0:2.8.1*255(469.4*Wh) is of type Counter
2017.10.28 16:28:50 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2017.10.28 16:28:50 5: Msg 1-0:1.8.2*255(0*Wh) is of type Counter
2017.10.28 16:28:50 4: Set total_consumption_Ch2 to 0
(ok, ne 3/4 Sunde vorher)
Oder meinst Du mit
ZitatDer Zähler hat zwei Tarife, der 1.8.1 liegt bei ca. 7 KW und der Nacht 1.8.2 liegt bei 2.2 KW.
(Einheit ist kWh u. nicht kW), dass die Readings nicht mit der Anzeige übereinstimmen ?
Glaskugel an: wpzähler =Wärmepumpenzähler ? Und da wird auch eingespeist ? Verwechselst Du die Zähler ?
Grüße Markus
Hi,
sorry für die Verwirrung.
Also es handelt sich um den Zähler der Wärmepumpe, mit einem Hauptraif und einem Nebentarif.
Ich Speise nicht ein.
Es wird irgendwas übermittelt, aber nicht die Zählerstände, dass wollte ich damit ausdrücken. Der Haupttarif lag etwa bei 6kwh und der Nachttaeif bei 2,5kwh.
Somit stimmen die Readings nicht überein.
Wenn man sich die OBIS Dokumentation durchliest, dann sollte, vielleicht habe ich das falsch verstanden, der Hautptarif 1.8.1 übermittelt werden und 1.8.2 der Nebentarif.
Keine Ahnung was in diesen Readings übermittelt wird.
Was ich gerne auswerten möchte, oder bisher auch ausgewertet habe
OBIS 1.8.1 Wirkarbeit Bezug Tarif 1 (Zählerstand zeitabhängiger Tarif 1)
OBIS 1.8.2 Wirkarbeit Bezug Tarif 2 (Zählerstand zeitabhängiger Tarif 2)
Und den Momentanverbrauch.
Viele Grüße
Marcus
Hi Marcus,
aber die Daten sind doch da
OBIS 1.8.1 Wirkarbeit Bezug Tarif 1 (Zählerstand zeitabhängiger Tarif 1) =2017-10-28 17:13:20 total_consumption_Ch1 20112101.6 =OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.1*255(20111709.9*Wh)
OBIS 1.8.2 Wirkarbeit Bezug Tarif 2 (Zählerstand zeitabhängiger Tarif 2) ist 0
Ich versteh weder, warum das nicht zu der Anzeige passt, noch warum ein Einspeisewert(total_feed_Ch1 469.4) übertragen wird, den Du weder im Display siehst und Du gar keine Eigenerzeugungsanlage hast :-\
Grüße Markus
Edit: 20112101.6 / 3600 / 1000 = 5,586
Fast 6,5. Zufall ?
Guten Morgen Markus,
ja es sind Daten da, aber keine Ahnung was für Daten?
Anbei aktuelle Daten aus dem LOG mit verbose 5
2017.10.29 10:25:31 5: SML-Parse 1B1B1B1B010101017607000A1FB5D102620062007263010176010107000A0A96F0560904039FC68A4B908E0101632C0F007607000A1FB5D103620062007263070177010904039FC68A4B908E01726201650A96CC447977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFE662B0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Full message-> 1B1B1B1B010101017607000A1FB5D102620062007263010176010107000A0A96F0560904039FC68A4B908E0101632C0F007607000A1FB5D103620062007263070177010904039FC68A4B908E01726201650A96CC447977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFE662B0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=1B1B1B1B010101017607000A1FB5D102620062007263010176010107000A0A96F0560904039FC68A4B908E0101632C0F007607000A1FB5D103620062007263070177010904039FC68A4B908E01726201650A96CC447977078181C78203FF0101010104454D480177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFE662B0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100000009FF010101010904039FC68A4B908E0177070100010800FF63018201621E52FF56000BFE662B0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100010800FF63018201621E52FF56000BFE662B0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100020800FF63018201621E52FF5600000012560177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100010801FF0101621E52FF56000BFE662B0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100020801FF0101621E52FF5600000012560177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177070100010802FF0101621E52FF56000000000001770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=01770701000F0700FF0101621B52FF550000109A0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 5: OBIS: Telegram=0177078181C78205FF01010101830204ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B90010101636DA8007607000A1FB5D1066200620072630201710163F230000000001B1B1B1B1A03F144
2017.10.29 10:25:31 4: MSG IS:
/EMH\04039FC68A4B908E
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(04039FC68A4B908E)
1-0:1.8.0*255(>20122167.5*Wh)
1-0:2.8.0*255(>469.4*Wh)
1-0:1.8.1*255(20122167.5*Wh)
1-0:2.8.1*255(469.4*Wh)
1-0:1.8.2*255(0*Wh)
1-0:15.7.0*255(425*W)
129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001)
!
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: /EMH\04039FC68A4B908E
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2017.10.29 10:25:31 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:0.0.9*255(04039FC68A4B908E)
2017.10.29 10:25:31 5: Msg 1-0:0.0.9*255(04039FC68A4B908E) is of type Serial
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.0*255(>20122167.5*Wh)
2017.10.29 10:25:31 5: Msg 1-0:1.8.0*255(>20122167.5*Wh) is of type Counter
2017.10.29 10:25:31 4: Set total_consumption to 20122167.5
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.0*255(>469.4*Wh)
2017.10.29 10:25:31 5: Msg 1-0:2.8.0*255(>469.4*Wh) is of type Counter
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.1*255(20122167.5*Wh)
2017.10.29 10:25:31 5: Msg 1-0:1.8.1*255(20122167.5*Wh) is of type Counter
2017.10.29 10:25:31 4: Set total_consumption_Ch1 to 20122167.5
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:2.8.1*255(469.4*Wh)
2017.10.29 10:25:31 5: Msg 1-0:2.8.1*255(469.4*Wh) is of type Counter
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2017.10.29 10:25:31 5: Msg 1-0:1.8.2*255(0*Wh) is of type Counter
2017.10.29 10:25:31 4: Set total_consumption_Ch2 to 0
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 1-0:15.7.0*255(425*W)
2017.10.29 10:25:31 5: Msg 1-0:15.7.0*255(425*W) is of type Channels
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: 129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001)
2017.10.29 10:25:31 5: Msg 129-129:199.130.5*255(04ACC32595065A7B17E4EC3DF85AC6F5267C0A3931757C93526543248D787528FA29EDCFA9732D0DF419DDD03B3E1B9001) is of type PublicKey
2017.10.29 10:25:31 5: OBIS (wpZaehler) - Msg-Parse: !
Auszug aus der Oberfläche:
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F2EC44-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F2EC44-if00-port0@9600,8,N,1
FD 12
MeterType SML
NAME wpZaehler
NR 49
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2017-10-29 10:25:31 1.0.0.0.9.255 04-03-9F-C6-8A-4B-90-8E
2017-10-29 10:25:31 129.129.199.130.3.255 EMH
2017-10-29 10:25:31 129.129.199.130.5.255 04AC-C325-9506-5A7B-17E4-EC3D-F85A-C6F5-267C-0A39-3175-7C93-5265-4324-8D78-7528-FA29-EDCF-A973-2D0D-F419-DDD0-3B3E-1B90-01
2017-10-29 03:16:15 Version EMH\04039FC68A4B908E
2017-10-29 10:25:31 dir_total_consumption pwr consuming
2017-10-29 10:25:31 dir_total_feed pwr consuming
2017-10-29 10:25:31 power 425
2017-10-29 10:25:25 state opened
2017-10-29 10:25:31 total_consumption 20122167.5
2017-10-29 10:25:31 total_consumption_Ch1 20122167.5
2017-10-29 10:25:31 total_consumption_Ch2 0
2017-10-29 10:25:31 total_feed 469.4
2017-10-29 10:25:31 total_feed_Ch1 469.4
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1509269125.51096
Channels:
DEVICES:
60
directions:
< pwr feeding
> pwr consuming
Attributes:
directions {">" => "pwr consuming", "<"=>"pwr feeding"}
interval 60
room System
Dazu Fotos vom Zähler, einmal mit 1.8.1 mit 11,7 kWh und dem 1.8.2 mit 4,8 kWh.
Den Werten nach dürfte ich ja nur 5,589 kWh verbraucht haben, wenn ich den Werten total_consumption_Ch1 20122167.5 vertrauen würde.
Hilfe, was muss ich machen, oder anders machen, um den Zähler richtig auszulesen?
Vielen Dank
Marcus
Hallo Marcus,
war halt nur so ne Idee, dass es einen Umrechnungsfaktor geben muss, der den Unterschied zwischen FHEM u. Zählerdisplay erklärt. Nu isse kaputt die Idee :'(
Bliebe das "vertauschter Zähler" oder hattest Du uns aufklären wollen, dass Du nur einen hast/abfragst
Du könntest mal die Kaffeemaschine/Wasserkocher/Mikrowelle einschalten und gucken, ob das power-reading entsprechend hoch geht.
Hallo Markus,
ich bin zu blö... :'( :'( :'(
Beim kopieren der OBIS Einstellungen habe ich den Devicename, die UUID vom Hauptstrom reinkopiert :'( Daher auch nur CH1. Ach ja...
So jetzt versuche ich mit der richtigen Device das auslesen ans fliegen zu bekommen.
Bekommt man irgendwo die Daten her, wie der Zähler kommuniziert?
Also wie viel Baut oder welches Protokoll. Habe zu diesem neuen Zähler bisher nur das gefunden https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/geb%C3%A4udetechnik-ohne-knx-eib/42090-digitale-stromz%C3%A4hler-auslesen-logarex-lk13b (https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/geb%C3%A4udetechnik-ohne-knx-eib/42090-digitale-stromz%C3%A4hler-auslesen-logarex-lk13b) aber leider fängt der Zähler nicht an zu quatschen wenn ich ihn auf 7E1 bei 4800 Baud stelle? Man warum musste der Zähler bloß kaputt gehen.
Vielleicht hast du ja dazu einen Tipp und sorry für die falschen Infos!
Viele Grüße
Marcus
da hilft nur googeln oder probieren. Unter Umständen musst Du ihn auch anders "ansteuern"(siehe commandref).
Eine Frage die mglw. nur der Modulautor beantworten kann.
In diesem (https://forum.fhem.de/index.php/topic,24517.msg705602.html#msg705602) Thread geht es um einen Zähler, der laut Datenblatt WMBUS als Transportprotokoll nutzt und SML für die Nutzdaten.
Das WMBUS Modul kann mit den Nutzdaten daher nichts anfangen.
Daher folgende Fragen:
1. Ist die Payload die das WMBUS Modul erkennt überhaupt SML?
Das sind diese Daten
6600c005e05d37b09c3300bb541c99d118578a1c7e7bdde725547e850eca6de75bb47356488113398595deb5ca7d3a08e0e0c41e0720541f2430bad440e876cb3e1f1c9dce31690dd2b6cba998866341110d833503d207a91ca81c90e3b81def642ab522afda8418471d37cfa712c4df03fd4faa50aee5d1c0c5cbcfe25d59c2ce6ecd410ff16dae53a8a8d11c95f3eac8e1e0dcf0ed6251a313c9b04c51dbeddeb9c70487515d94e232266d71604ecca762a7335f07a8fbafd05e4e2ea629674537bc83
2. Falls ja, gibt es eine Möglichkeit die an das OBIS Modul weiterzuleiten? Es gibt ja einen Devicetyp none, ist der für sowas gedacht?
Ein Versuch mit
define obis OBIS none SML
hat mich nicht wirklich weiter gebracht.
Hallo Kaihs,
sieht auf den ersten Blick nicht nach SML aus.
Habs auch gerade durch die Decode-Routine laufen lassen, die hat leider auch nicht angeschlagen.
Ich glaube auch nicht, dass nur am Anfang oder Ende ein Teil fehlt.
Gewisse Strukturen innerhalb der Hex-Daten fehlen mir auch irgendwie.
lg, Stefan
kannst Du mal bitte schauen obe da was bei ist, bce kommt mir so bekannst vor, ich weiß aber nicht mehr woher
2017.10.30 21:21:54 4: CUL_Parse: MyCUL bCE44A815940377030102073E7FBE00C0055391DA66393AE942F3F9982EFEC9A8912A809FD391466BDCB95E07710BCD3F1D5E37CE435003037E9EC8A4A8AE3217E474707FB533A8D5BFFFD96C6147A819CEB01F266080A05FF60CEFFCBE291224B3A053BD2206B790F3785AA18A7C53AF3487C3F11A2F6463935165CFFA1849EC25C82CCDCEAD624DFB57B3553A6D16CB5B14F7175EF1000C54F45C594D948364403007C064E4879633AFBA5F15DD660A27E88220EC3DE6040339BBFE60C608F79E1FF8F35AC73B14C47A7C3231FB1C1CF931341212314D2E83AEB10E3ABCF355F9181769AC62E27123D1228011 -65.5
2017.10.30 21:21:54 5: MyCUL: dispatch bCE44A815940377030102073E7FBE00C0055391DA66393AE942F3F9982EFEC9A8912A809FD391466BDCB95E07710BCD3F1D5E37CE435003037E9EC8A4A8AE3217E474707FB533A8D5BFFFD96C6147A819CEB01F266080A05FF60CEFFCBE291224B3A053BD2206B790F3785AA18A7C53AF3487C3F11A2F6463935165CFFA1849EC25C82CCDCEAD624DFB57B3553A6D16CB5B14F7175EF1000C54F45C594D948364403007C064E4879633AFBA5F15DD660A27E88220EC3DE6040339BBFE60C608F79E1FF8F35AC73B14C47A7C3231FB1C1CF931341212314D2E83AEB10E3ABCF355F9181769AC62E27123D12280::-65.5
2017.10.30 21:21:54 5: WMBUS raw msg bCE44A815940377030102073E7FBE00C0055391DA66393AE942F3F9982EFEC9A8912A809FD391466BDCB95E07710BCD3F1D5E37CE435003037E9EC8A4A8AE3217E474707FB533A8D5BFFFD96C6147A819CEB01F266080A05FF60CEFFCBE291224B3A053BD2206B790F3785AA18A7C53AF3487C3F11A2F6463935165CFFA1849EC25C82CCDCEAD624DFB57B3553A6D16CB5B14F7175EF1000C54F45C594D948364403007C064E4879633AFBA5F15DD660A27E88220EC3DE6040339BBFE60C608F79E1FF8F35AC73B14C47A7C3231FB1C1CF931341212314D2E83AEB10E3ABCF355F9181769AC62E27123D12280::-65.5
Hallo Harry,
da muss ich dich leider auch enttäuschen.
lg, Stefan
PS: Ich komm mal in euren Thread :D
Hallo,
habe das Modul mit meinem AS1440 fast problemlos in Betrieb nehmen können. Mit der Standardinitialisierung bekomme ich die Vorwerte und der Zähler benötigt ca. 5 min um alles auszulesen (Speedumschaltung funktioniert wohl nicht). Da ich keine Vorwerte benötige, habe ich den Zähler etwas anders initialisiert. Ich nutze nicht
"/?!"
sondern
"/2!"
Mit dieser Initialisierung werden nur aktuelle Werte geliefert und ein Überschreiben der Werte finden auch nicht statt. Habe mir deshalb ein identisches Device wie den VSM102 definiert
my %devs= (
# Name, Init-String, interval, 2ndInit
"none" => ["", -1, ""],
"Unknown" => ["", -1, ""],
"SML" => ["", -1, ""],
"Ext" => ["", -1, ""],
"Standard" => ["", -1, ""],
"VSM102" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E110" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E350USB" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"AS1440" => ["/2!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
);
Nach dem nächsten Update wird der geänderte Programmcode natürlich wieder überschrieben. Daher meine Frage: Kann man den Zähler neu mit aufnehmen oder kann man die Möglichkeit schaffen die Initialisierung wie den Parameter Speed zu setzen ?
Hallo,
ich habe auch den AS1440 per ser2net eingebunden (von einem Raspberry).
Ich habe aber Probleme ihn zeitgenau auszulesen. Mit welchen Parametern ist er bei Ihnen eingebunden??? (ser2net und FHEM)
4001:raw:600:/dev/ttyUSB0:300 EVEN 1STOPBIT 7DATABITS -XONXOFF -RTSCTS-off
Internals:
DEF 192.168.99.7:4001 AS1440
DeviceName 192.168.99.7:4001
FD 127
MeterType AS1440
NAME PowerMeter
NR 1330
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2017-11-24 15:38:13 0.0.0 3264480
2017-11-24 15:30:12 0.1.2.01 1702010000
...
2017-11-24 14:49:48 voltage_L3 228.8
helper:
EoM -1
SPEED 5
TRIGGERTIME 1511535806.35519
DEVICES:
/2!
600
050
Attributes:
room 1_Energie
Bin für jeden Tipp dankbar.
Danke!!
MfG,
Rainer.
Bei mir schmiert das OBIS-Modul gelegentlich ab, z.B. gestern mit folgenden Fehlermeldungen:
Zitat2017.11.28 17:31:18 1: PERL WARNING: portable_TIOCINQ(21531) ioctl failed: Eingabe-/Ausgabefehler at ./FHEM/47_OBIS.pm line 409
2017.11.28 17:31:18 1: PERL WARNING: Use of uninitialized value $InBytes in numeric gt (>) at ./FHEM/47_OBIS.pm line 410.
1. Woran kann das liegen?
2. Gibt es eine Möglichkeit, das Modul zum Restart zu bewegen, ohne fhem neu zu starten?
Das habe ich auch manchmal. Das Modul liefert dann keine Daten oder hat sich aufgehangen oder what ever.
Ich überprüfe das mit einem WatchDog. Normalerweise werden die Daten aller fünf Minuten aktualisiert. Wenn die Aktualisierung nicht in den 5 Minuten und 10 Sekunden stattgefunden hat wird das Modul neu gestartet.
defmod WatchDogVersorgerZaehler watchdog VersorgerZaehler 00:05:10 SAME {\
Log(3,"Der Versorgerzähler liefert keine Daten!");;\
fhem("set telegram message Der Versorgerzähler liefert keine Daten!");;\
fhem("reload 47_OBIS.pm");;\
}
attr WatchDogVersorgerZaehler autoRestart 1
Grüße
oh, das klingt cool. Watchdog kannte ich noch gar nicht. Für einen ähnlichen Fall beim Homematic CUL hatte ich mir ein DOIF mir 'ReadingsAge' gebastelt. Das kann ich dann ja auch auf Watchdog umbauen.
Besten Dank für den Tipp!
Was ist eigentlich
set telegram message Der Versorgerzähler liefert keine Daten!
??
set telegram message Der Versorgerzähler liefert keine Daten!
Damit wird eine Nachricht via Telegramm Messenger auf das Handy versendet. Spielerei.
ok. Telegram hab ich nicht. Aber das gab mir die Idee, dasselbe mit WhatsApp zu bauen.
Zitat von: majorshark am 02 Dezember 2017, 08:47:39
Das habe ich auch manchmal. Das Modul liefert dann keine Daten oder hat sich aufgehangen oder what ever.
Ich überprüfe das mit einem WatchDog. Normalerweise werden die Daten aller fünf Minuten aktualisiert. Wenn die Aktualisierung nicht in den 5 Minuten und 10 Sekunden stattgefunden hat wird das Modul neu gestartet.
defmod WatchDogVersorgerZaehler watchdog VersorgerZaehler 00:05:10 SAME {\
Log(3,"Der Versorgerzähler liefert keine Daten!");;\
fhem("set telegram message Der Versorgerzähler liefert keine Daten!");;\
fhem("reload 47_OBIS.pm");;\
}
attr WatchDogVersorgerZaehler autoRestart 1
Grüße
Ich habe das jetzt so implementiert, aber trotz reload 47_OBIS.pm hängt das Modul weiterhin, auch wenn ich reload 47_OBIS.pm manuell auf der Kommandozeile ausführe. Momentan hilft nur ein kompletter Restart von fhem. Hat Jemand eine Idee, woran das liegen kann?
Edit:
attr PollingMode off
und gleich danach
attr PollingMode on
scheint den Hänger zu beheben. Werde das jetzt mal so umschreiben und hoffe, dass es hilft.
Ich habe einen ISKRA MT691 Stromzähler bekommen und spreche den über einen USB IR Schreib-Lesekopf aus.
Erstmal die gute Nachricht: Nachdem ich diverse kleine Skripte zum Auslesen des Zählers probiert habe und keines den aktuellen Verbrauch lesen wollte und nur eines den korrekten Zählerstand ausgelesen hat, hat mich FHEM mit dem 47_OBIS.pm Modul sehr positiv überrascht, indem es mir Zählerstand und aktuelle Leistung problemlos ausgibt.
Ohne Polling erfolgen die Updates jedoch ein wenig häufig (alle 1-2 Sekunden), also habe ich Polling eingeschaltet und das reduziert die Updates immerhin auf alle 5 Sekunden.
Ich wollte die Updates aber noch weiter reduzieren und habe interval auf verschiedene Werte, z.B. 10 gesetzt. Das hat jedoch den seltsamen Effekt, dass jetzt nur noch das erste Reading, nämlich "1.0.96.50.1.255" (liefert den String "ISK", vermutlich soll das Hersteller sein) regelmäßig aktualisiert wird.
Habe ich userReadings definiert (um z.B. den Zählerstand von Wh auf kWh umzurechnen), werden diese userReadings zwar ebenfalls regelmäßig aktualisiert, leider aber immer auf Basis des nicht mehr aktualisierten Basiswertes (power sowie total_consumption).
Sobald ich interval wieder lösche, werden die Werte wieder wie erwartet aktualisiert.
Habe ich da einen Denkfehler (bin nicht so firm mit FHEM) oder ist das ein Bug?
Als Zusatzinfo sollte ich vermutlich noch die OBIS-Felder liefern, die der MT691 liefert, der scheint ja noch nicht so verbreitet zu sein:
- 1-0:96.50.1*255(ISK)
- 1-0:96.1.0*255(^AISK^@^D!#y) <-- binärer Schrott...
- 1-0:1.8.0*255(115071.7*Wh) type Counter => total_consumption
- 1-0:16.7.0*255(396*W) type Channels => power
Mehr spuckt er wohl nicht aus, aber eigentlich reicht mir das ja auch, außer wenn ich interval konfiguriere...
Viele Grüße
Roland
Hallo Roland,
mein Zähler funktioniert ebenfalls nach dem push-Prinzip. Daher auch bei mir der pollingmode und interval=60. Zusätzlich habe ich noch aligntime=00:00:00, aber das hat eigentlich andere Gründe. Vielleich ist ein interval=10 einfach nur zu klein für eine korrekte Funktionsweise und Du solltest es mal mit z.B. 60 wie bei mir probieren.
Grüße Markus
Moin Markus,
Zitat von: KölnSolar am 13 Dezember 2017, 19:04:34
mein Zähler funktioniert ebenfalls nach dem push-Prinzip. Daher auch bei mir der pollingmode und interval=60. Zusätzlich habe ich noch aligntime=00:00:00, aber das hat eigentlich andere Gründe. Vielleich ist ein interval=10 einfach nur zu klein für eine korrekte Funktionsweise und Du solltest es mal mit z.B. 60 wie bei mir probieren.
Das hat leider nicht geholfen (auch nicht das Setzen von alignTime).
Allerdings habe ich jetzt mal wieder verbose=5 gesetzt und damit sieht man, dass mit gesetztem "interval" der Parser nach 1-0:96.1.0*255(^AISK^@^D!#y) aufhört. Lösche ich "interval", geht's danach weiter und er parst auch 1-0:1.8.0*255(123616.8*Wh) und 1-0:16.7.0*255(418*W).
Wobei die eigentliche Message (MSG IS:...) mit und ohne interval setting immer gleich aussieht und die beiden (mit interval nicht geparsten) Einträge enthält.
Gruß
Roland
dann ist es vermutlich der "binäre Schrott". Das muss sich dann der "Chef" angucken ;) Zu dessen Unterstützung kannst Du ja schon einmal ein list des devices in CodeTags(#-Zeichen oben) hier posten, also den Output von "list DeinOBIS-device"
Zitat von: KölnSolar am 13 Dezember 2017, 20:11:29
dann ist es vermutlich der "binäre Schrott". Das muss sich dann der "Chef" angucken ;) Zu dessen Unterstützung kannst Du ja schon einmal ein list des devices in CodeTags(#-Zeichen oben) hier posten, also den Output von "list DeinOBIS-device"
Okay, hier die Ausgabe:
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
MeterType SML
NAME stromzaehler
NR 27
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2017-12-13 21:40:16 1.0.96.50.1.255 ISK
2017-12-13 21:40:16 Leistung_W 746
2017-12-13 21:40:16 Zaehlerstand_kWh 125.3247
2017-12-13 21:40:16 power 746
2017-12-13 21:37:24 state opened
2017-12-13 21:40:16 total_consumption 125324.7
helper:
BUFFER ISKw`�
ISK!#yw�e b R�e �w�bRS�c�Xv1�bbrcqcl���v1�bbrcvW�
ISK!#yrbeT�c8�v1�bbrcw
ISK!#yb
��rbeT�tw`2ISKw`�
ISK!#yw
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1513197493.01802
Channels:
DEVICES:
0
Attributes:
pollingMode on
userReadings Zaehlerstand_kWh { ReadingsVal("stromzaehler", "total_consumption", 0)/1000;;;;}, Leistung_W {ReadingsVal("stromzaehler", "power", 0);;;;}Zur Sicherheit auch gleich nochmal ein kompletter Parse (ohne interval) der Daten:
2017.12.13 21:42:11 5: SML-Parse 1B1B1B1B010101017605003108C3620062007263010176010105001058410B0A0149534B0004212379726201650010551201632E5C007605003108C4620062007263070177010B0A0149534B0004212379070100620AFFFF7262016500105512747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650013203F0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 5: OBIS: Full message-> 1B1B1B1B010101017605003108C3620062007263010176010105001058410B0A0149534B0004212379726201650010551201632E5C007605003108C4620062007263070177010B0A0149534B0004212379070100620AFFFF7262016500105512747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650013203F0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 5: OBIS: Telegram=1B1B1B1B010101017605003108C3620062007263010176010105001058410B0A0149534B0004212379726201650010551201632E5C007605003108C4620062007263070177010B0A0149534B0004212379070100620AFFFF7262016500105512747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650013203F0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 5: OBIS: Telegram=0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650013203F0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 5: OBIS: Telegram=0177070100010800FF65001C010401621E52FF650013203F0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 5: OBIS: Telegram=0177070100100700FF0101621B52005302EB0101016332B5007605003108C56200620072630201710163F0AC0000001B1B1B1B1A02785F
2017.12.13 21:42:11 4: MSG IS:
/
1-0:96.50.1*255(ISK)
1-0:96.1.0*255(
^AISK^@^D!#y)
1-0:1.8.0*255(125343.9*Wh)
1-0:16.7.0*255(747*W)
!
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: /
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.50.1*255(ISK)
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
^AISK^@^D!#y)
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: 1-0:1.8.0*255(125343.9*Wh)
2017.12.13 21:42:11 5: Msg 1-0:1.8.0*255(125343.9*Wh) is of type Counter
2017.12.13 21:42:11 4: Set total_consumption to 125343.9
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: 1-0:16.7.0*255(747*W)
2017.12.13 21:42:11 5: Msg 1-0:16.7.0*255(747*W) is of type Channels
2017.12.13 21:42:11 5: OBIS (stromzaehler) - Msg-Parse: !Und nun die Kurzfassung mit interval:
2017.12.13 21:44:46 5: SW:
2017.12.13 21:44:46 4: Wrote
2017.12.13 21:44:46 5: OBIS (stromzaehler) - Internal timer set to 2017-12-13 21:45:46
2017.12.13 21:44:46 5: SML-Parse 1B1B1B1B01010101760500310A79620062007263010176010105001058D30B0A0149534B000421237972620165001055A40163705B00760500310A7A620062007263070177010B0A0149534B0004212379070100620AFFFF72620165001055A4747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF65001321730177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 5: OBIS: Full message-> 1B1B1B1B01010101760500310A79620062007263010176010105001058D30B0A0149534B000421237972620165001055A40163705B00760500310A7A620062007263070177010B0A0149534B0004212379070100620AFFFF72620165001055A4747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF65001321730177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 5: OBIS: Telegram=1B1B1B1B01010101760500310A79620062007263010176010105001058D30B0A0149534B000421237972620165001055A40163705B00760500310A7A620062007263070177010B0A0149534B0004212379070100620AFFFF72620165001055A4747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF65001321730177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 5: OBIS: Telegram=0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF65001321730177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 5: OBIS: Telegram=0177070100010800FF65001C010401621E52FF65001321730177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 5: OBIS: Telegram=0177070100100700FF0101621B52005302EC0101016376AF00760500310A7B620062007263020171016342E60000001B1B1B1B1A02D29F
2017.12.13 21:44:46 4: MSG IS:
/
1-0:96.50.1*255(ISK)
1-0:96.1.0*255(
ISK!#y)
1-0:1.8.0*255(125374.7*Wh)
1-0:16.7.0*255(748*W)
!
2017.12.13 21:44:46 5: OBIS (stromzaehler) - Msg-Parse: /
2017.12.13 21:44:46 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.50.1*255(ISK)
2017.12.13 21:44:46 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ISK!#y)
Bei zu häufigen Logeinträgen hilft bei mir
event-min-interval .*:5
event-on-change-reading .*
interval 60
pollingMode on
Anliegend ein commandref-Patch für das aktuelle Modul. Habe ein paar Zeilenumbrüche sowie <ul> und Co hinzugefügt, die fehlten. Insbesondere waren die Attribute teilweise in einer Zeile zusammengeschoben und deshalb für mich schlecht lesbar.
Gruß, Christian
@krikan:
Danke, übernehm ich übermorgen, sobald ich daheim bin von den SchwieEltern.
@RoRo:
Schau ich mir auch übermorgen an.
Hab zwar grad grob meinen Source überflogen, auf die schnelle aber nichts gefunden, woher das kommen könnte.
Frohe Feiertage noch,
Stefan
Hallo und allen erst mal ein gutes und glückliches neues Jahr!!!
Sorry, wenn ich jetzt so in die Katerstimmung platze... :-)
Ich hab's gestern doch wirklich noch geschafft (..ohne grosse Vorkenntnisse mit FHEM, etc.) das OBIS-Modul an meinem Rasperry Pi 3 mit einem USB-IR-Schreib-/Lesekopf von Wiesmann Elektronik zum Laufen zu bekommen. Ich bekomme auch zyklische Aktualisierungen (eingestellt habe ich aktuell ein Intervall von 8h), allerdings kapiere ich das Verhalten nicht ganz und weiss nicht, ob das OBIS-Protokoll-spezifisch und -konform ist oder ob's vielleicht per Konfiguration anders ginge.
Wenn ein Aktualisierungslauf finde ich im Log erst mal die korrekten Verbrauchs- und Lieferdaten - ist ein Zweirichtungszähler ISKRA MT174. Im Haus gibt's nur einen Stromkreis, an dem auch die PV-Anlage incl. Li-Speicher hängt, daher gibt's Bezugs- und Lieferdaten.
Hier der Log-Abschnitt dazu:
2018-01-01_08:57:26 Stromzaehler 1.0.0.0.1.255: 1ISK0067511756
2018-01-01_08:57:27 Stromzaehler 1.0.0.1.0.255: 15
2018-01-01_08:57:27 Stromzaehler 1.0.0.2.0.255: 1.06
2018-01-01_08:57:28 Stromzaehler 0.0.C.1.0.255: 67511756
2018-01-01_08:57:29 Stromzaehler 0.0.C.1.6.255: 391B
2018-01-01_08:57:29 Stromzaehler 0.0.C.51.1.255: 4
2018-01-01_08:57:30 Stromzaehler 0.0.C.51.2.255: 161125121246
2018-01-01_08:57:31 Stromzaehler 0.0.C.51.2.01: 161125121246
2018-01-01_08:57:32 Stromzaehler 0.0.C.51.2.02: 1160712200812
2018-01-01_08:57:33 Stromzaehler 0.0.C.51.2.03: 1160712200756
2018-01-01_08:57:34 Stromzaehler 0.0.C.51.2.04: 1160712200752
2018-01-01_08:57:42 Stromzaehler 1.0.1.6.0.255: 1801010300
2018-01-01_08:57:43 Stromzaehler power: 1.29
2018-01-01_08:57:44 Stromzaehler total_consumption: 6044.62
2018-01-01_08:57:45 Stromzaehler total_consumption_Ch1: 6044.62
2018-01-01_08:57:46 Stromzaehler total_consumption_Ch2: 0
2018-01-01_08:57:47 Stromzaehler total_consumption_Ch3: 0
2018-01-01_08:57:48 Stromzaehler total_consumption_Ch4: 0
2018-01-01_08:57:49 Stromzaehler 1.0.2.6.0.255: 1801010845
2018-01-01_08:57:50 Stromzaehler feed_L1: 0
2018-01-01_08:57:51 Stromzaehler total_feed: 3565.513
2018-01-01_08:57:52 Stromzaehler total_feed_Ch1: 3565.513
2018-01-01_08:57:53 Stromzaehler total_feed_Ch2: 0
2018-01-01_08:57:54 Stromzaehler total_feed_Ch3: 0
2018-01-01_08:57:56 Stromzaehler total_feed_Ch4: 0
Nach einiger Zeit sehe ich dann in den Readings, dass zuerst nacheinander beide Beträge für total_consumption nach unten bis auf Null zählen und kurz drauf auch die für total_feed, was auch im Log nachvollziehbar ist.
Hier wieder die beiden Logg-Abschnitte dazu:
2018-01-01_08:58:29 Stromzaehler total_consumption: 6034.338
2018-01-01_08:58:30 Stromzaehler total_consumption: 5052.114
2018-01-01_08:58:31 Stromzaehler total_consumption: 4420.534
2018-01-01_08:58:32 Stromzaehler total_consumption: 4112.441
2018-01-01_08:58:33 Stromzaehler total_consumption: 3990.655
2018-01-01_08:58:34 Stromzaehler total_consumption: 3963.479
2018-01-01_08:58:35 Stromzaehler total_consumption: 3947.032
2018-01-01_08:58:36 Stromzaehler total_consumption: 3938.592
2018-01-01_08:58:37 Stromzaehler total_consumption: 3896.649
2018-01-01_08:58:38 Stromzaehler total_consumption: 3682.053
2018-01-01_08:58:39 Stromzaehler total_consumption: 3363.648
2018-01-01_08:58:40 Stromzaehler total_consumption: 2784.297
2018-01-01_08:58:41 Stromzaehler total_consumption: 1369.286
2018-01-01_08:58:42 Stromzaehler total_consumption: 143.052
2018-01-01_08:58:43 Stromzaehler total_consumption: 0
2018-01-01_08:59:27 Stromzaehler total_consumption_Ch1: 6034.338
2018-01-01_08:59:28 Stromzaehler total_consumption_Ch1: 5052.114
2018-01-01_08:59:29 Stromzaehler total_consumption_Ch1: 4420.534
2018-01-01_08:59:30 Stromzaehler total_consumption_Ch1: 4112.441
2018-01-01_08:59:31 Stromzaehler total_consumption_Ch1: 3990.655
2018-01-01_08:59:32 Stromzaehler total_consumption_Ch1: 3963.479
2018-01-01_08:59:33 Stromzaehler total_consumption_Ch1: 3947.032
2018-01-01_08:59:34 Stromzaehler total_consumption_Ch1: 3938.592
2018-01-01_08:59:35 Stromzaehler total_consumption_Ch1: 3896.649
2018-01-01_08:59:36 Stromzaehler total_consumption_Ch1: 3682.053
2018-01-01_08:59:37 Stromzaehler total_consumption_Ch1: 3363.648
2018-01-01_08:59:38 Stromzaehler total_consumption_Ch1: 2784.297
2018-01-01_08:59:39 Stromzaehler total_consumption_Ch1: 1369.286
2018-01-01_08:59:40 Stromzaehler total_consumption_Ch1: 143.052
2018-01-01_08:59:41 Stromzaehler total_consumption_Ch1: 0
Am Ende sehe ich dann in den Readings für alle Werte Null - das hätte ich anders erwartet. ???
Kann mir das vielleicht einer der Spezialisten erklären - ..und ggf. wenn möglich sagen, ob man das irgendwie ändern kann?
Schon mal vielen Dank dafür und ganz besonders an die Leute, die das realisiert haben, so dass so ein Grünling wie ich es noch bin, das in so kurzer Zeit zum laufen gebracht hat.
Ciao
Tom
Schau mal hier https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868 (https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868)
Derselbe Zähler, auch das Problem klingt ähnlich.
Evtl. kannst Du erst mal mit "interval" oder "event-min-interval" die unnötigen Einträge unterdrücken. Kommen denn irgendwann auch wieder "richtige" Werte?
Servus Willy - ..und ein gutes Neues!!!
das Attribut interval hab ich ja gesetzt - zum Testen auf 10 Minuten und nachdem ich das beschriebene Verhalten mehrfach festgestellt hab und dann auch mal bisschen feiern wollte :o, hab ich's auf 8h gestellt. Die Kontrolle heute früh zeigte dann identisches Verhalten. Es beginnt mit dem korrekten Werten und dann folgt das Runterzählen - bis eben Null.
Beim nächsten Aufruf dann wieder das gleiche Spiel.
Leider hab ich jetzt grad keine Zeit mehr - vielleicht heute Abend wieder ein Test.
Jetzt war mir mal das automatische tägliche Sichern der kompletten FHEM-Installation auf dem NAS-Backup-Share wichtiger... :-) - tut auch schon...
Ciao
Tom
Mein Problem scheint tatsächlich das selbe zu sein, das tatu123 im Februar '17 geschildert hat.
https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868 (https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868)
Jetzt ist mir auch klar, warum am Ende dann Null steht! In den nächsten Monaten würde dann einer der anderen Werte stehen. Den Zähler haben wir noch keine 15 Monate und daher ist im letzten Eintrag noch eine Null, da der Historienspeicher max. 15 Monate zurückreicht, wie tatu123 beschreibt und auch so im Datenblatt nachzulesen ist.
https://www.newfound-energy.co.uk/wp-content/uploads/2014/11/mt174.pdf (https://www.newfound-energy.co.uk/wp-content/uploads/2014/11/mt174.pdf)
2.8.3. Data downloaded via optical port
Data downloaded via an interface (optical port or RS485 interface) are identified with OBIS (OBject Identification System) codes in compliance with IEC 62056-61 standard. On request the data identification
codes can be EDIS (Energy Data Identification System) in compliance with DIN43863, Part 3 standard. On request, historical data for previous billing periods, besides data for a current billing period, can be also downloaded via the optical port and an interface (if it is built-in). Historical data can be downloaded for maximum 15 last billing periods.
Das wäre also schon mal plausibel!
Scheinbar ist es optional, diese Daten über das Protokoll auszulesen. Leider habe ich auf die Schnelle nicht die Protokoll-Spezifikation gefunden (bzw. nur auf dem IEC-Dokumenten-Server und nicht kostenlos). Vielleicht gibt's sogar ein entsprechendes on/off-Bit im Protokoll?
Den Workaround, den Icinger (Stefan) gemacht hat https://forum.fhem.de/index.php/topic,51948.msg585181.html#msg585181 (https://forum.fhem.de/index.php/topic,51948.msg585181.html#msg585181), habe ich aber leider nicht wirklich verstanden. Vielleicht liegt das auch an den anders aussehenden Log - oder an meinen noch sehr beschränkten Kenntnissen bzgl. FHEM (..die ich aber nach und nach verbessern möchte).
Log von tatu123
1-0:1.8.0*255(0000344.481*kWh)
1-0:1.8.0*01(0000129.574*kWh)
1-0:1.8.0*02(0000000.001*kWh)
1-0:1.8.0*03(0000000.000*kWh)
1-0:1.8.1*255(0000219.574*kWh)
1-0:1.8.1*01(0000085.841*kWh)
1-0:1.8.1*02(0000000.001*kWh)
1-0:1.8.1*03(0000000.000*kWh)
1-0:1.8.2*255(0000124.908*kWh)
1-0:1.8.2*01(0000043.733*kWh)
1-0:1.8.2*02(0000000.000*kWh)
1-0:1.8.2*03(0000000.000*kWh)
Log via FHEM-OBIS-Modul:
2018-01-01_08:57:44 Stromzaehler total_consumption: 6044.62
2018-01-01_08:57:45 Stromzaehler total_consumption_Ch1: 6044.62
...
2018-01-01_08:57:51 Stromzaehler total_feed: 3565.513
2018-01-01_08:57:52 Stromzaehler total_feed_Ch1: 3565.513
Vorgeschlagener Workaround:
{"1-0:1.8.0*01"=>"consumption_1","1-0:1.8.1*01"=>"consumption_2","1-0:1.8.3*01"=>"consumption_3"}
Kann mir bitte jemand - vielleicht sogar Stefan - helfen, was ich ändern bzw. wo ich eingreifen muss?
@Willy: Vielen Dank für deinen Hinweis auf den früheren Beitrag. Den hätte ich natürlich auch selbst finden können, hätte ich die Suche bemüht - hab da ehrlich gesagt nicht dran gedacht - sorry!
Zitat von: parabacus am 01 Januar 2018, 19:46:15
@Willy: Vielen Dank für deinen Hinweis auf den früheren Beitrag. Den hätte ich natürlich auch selbst finden können, hätte ich die Suche bemüht - hab da ehrlich gesagt nicht dran gedacht - sorry!
Kein Thema. Ich habe mich auch nur deshalb auf die Suche gemacht, weil mir der Name ISKRA bekannt vorkam. Mein Bauchgefühl lag wohl richtig.
Es ist immer wieder "interessant", wie manche alten Hasen reagieren, wenn man als Neuling was anderes zu tun hat als 97 Seiten alter Beiträge zu lesen, nur um die 5%-Chance auf einen Treffer zu nutzen. Diese "RTFM" Reaktionen kann ich nicht immer nachvollziehen (nur wenn sich Jemand permanent sperrig stellt ...).
Ach ja: ... und die Suchfunktion des Forums ist eher besch...eiden.
Die Werte des Zählers bekommst Du mit
z.B.
attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon","1-0:1.8.0*02"=>"verbrauch_vor_2_Mon","1-0:1.8.0*03"=>"verbrauch_vor_3_Mon","1-0:1.8.0*04"=>"verbrauch_vor_4_Mon","1-0:1.8.0*05"=>"verbrauch_vor_5_Mon","1-0:1.8.0*06"=>"verbrauch_vor_6_Mon","1-0:1.8.0*07"=>"verbrauch_vor_7_Mon","1-0:1.8.0*08"=>"verbrauch_vor_8_Mon"}
attr zaehler event-on-change-reading verbrauch_akt
Das Modul kann offensichtlich nicht die Sub-Channel des Zähler richtig zuordnen. Es werden immer alle Werte von 1.08* in den gleichen Wert geschrieben und da der neueste Wert zu erst kommt wird er immer mit den älteren Werten überschrieben. Das setzen des channels-attributs umgeht das zumindest.
Wenn dich, wie mich, die vordefinierten Werte stören kannst Du die mit
attr zaehler suppressReading total_consumption.*
ausblenden. Steht eh nur quatsch drin.
Ich hoffe das die Unterstützung der Sub-channel irgend wann mal, für den Zähler, richtig implementiert wird. Aber da wir jetzt schon min 2 mit dem Zähler wird es vieleicht doch mal.
Ach und die schon lange in Planung befindliche Auslesegeschwindigkeitsumschaltung kommt dann hoffentlich auch.
Viele Grüße
tatu123
Hallo tatu123!
danke dass du dich dazu meldest, allerdings hab ich's noch immer nicht ganz kapiert!
Mich stören natürlich nur die Folgewerte der Vormonate - der Wert total_consumption des aktuellen Zählerstandes interessieren mich natürlich schon.
Blende ich mit "attr zaehler suppressReading total_consumption.*" dann alles aus oder nur die der Vormonate? - oder was meinst du mit "vordefinierte Werte"?
Wenn's bisschen schneller gehen würde, wäre das natürlich auch toll - so kann man ja den einzelnen Bits fast zuschauen, wie sie rübertröpfeln... :-)
Wenn ich das Problem richtig verstanden habe, dann heißen bei Dir alle Readings (auch die der Vormonate) "Stromzaehler total_consumption". Eine Unterscheidung anhand eines Suffixes (z.B. 1-0:1.8.0*02) ist also nicht möglich.
Findest Du evtl. eine Möglichkeit, den Zähler zu einer anderen Art der Werte-Darstellung zu überreden?
Schalt doch mal den Event Monitor ein mit einem Filter auf alles, was den Stromzähler betrifft, und poste den Inhalt hier. Vielleicht gibt es ja doch noch ein Unterscheidungsmerkmal.
Ansonsten würde mir einfallen, dass Du alle "Stromzaehler total_consumption" Readings mit dem vorigen Wert vergleichst, und nur dann ins Logfile schreibst, wenn der Wert höher ist als der vorige. Dazu müsstest du jedes mal, wenn ein Wert geschrieben wird, ihn zusätzlich in einer Dummy-Variablen speichern, die Du bei weiteren Werten als Basis für den Vergleich her nimmst.
Hi Willy,
hier mal ein Log...
Vielleicht hab ich's jetzt kappiert...
Im Code steht folgendes:
my %OBIS_channels = ( "21" =>"power_L1",
"41" =>"power_L2",
"61" =>"power_L3",
"12" =>"voltage_avg",
"32" =>"voltage_L1",
"52" =>"voltage_L2",
"72" =>"voltage_L3",
"11" =>"current_sum",
"31" =>"current_L1",
"51" =>"current_L2",
"71" =>"current_L3",
"1.8" =>"total_consumption",
"2.8 =>"total_feed",
"2" =>"feed_L1",
"4" =>"feed_L2",
"6" =>"feed_L3",
"1" =>"power",
"15" =>"power",
"16" =>"power",
"24" =>"Gas",
);
Wenn ich jetzt meinen Log betrachte, finde ich dann an den Stellen, wo 1.8 bzw. 2.8 ausgelesen wird, die Ersetzung mit der Bedeutung des Wertes - eben total_Consupmtion bzw total_feed.
Wenn ich jetzt - und so interpretiere ich die den Vorschlag von tatu123 - diese Ersetzung zurücksetze, müsste im Log die Bennenung nach OBIS-Protokoll erscheinen.
Dann wäre eine neue Zuweisung - auch nach Vorschlag von tatu123 - mit attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon", ...} möglich und man könnte dann auf Wert verbrauch_akt filtern, womit man dann auch nur den einen Wert bekommt, da die weiteren Werte nicht mehr auf die selbe Variable geschrieben werden.
Hab ich das jetzt korrekt interpretiert?
In deinem angehängten Textfile sehe ich durchaus Suffixe, z.B.
1-0:1.8.1*01(0005052.114*kWh)
Demnach dürfte das, was in deinen Logs steht ("total_consumption" in allen Zeilen) bereits die Interpretation sein, die zuschlägt, sobald sie irgendwas findet, das mit 1.8 anfängt (gemäß der zitierten Stelle im Code). Das von tatu123 vorgeschlagene Attribut
attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon ...
scheint eine Präzisierung dieser pauschalen Zuweisung zu definieren. Versuch das mal.
Am Code des Moduls würde ich nach Möglichkeit nichts ändern, sonst musst Du das Modul von zukünftigen Updates ausschließen, damit Deine Änderungen erhalten bleiben. Ich vermute, dass die pauschale Interpretation (1.8 => ...) durch die präzisere ersetzt wird, sobald das Attribut gesetzt ist. Insofern braucht es wahrscheinlich keine Codeänderung.
PS:
Du bist hiermit bereits auf der Schattenseite von FHEM angekommen. Alles ist open source, alles ist mehr oder weniger supportet, und Vieles ist mit Ausnahmen und Sonderfällen behaftet, die Zeit und Verständnis benötigen.
Das kommt raus, wenn man mal schnell schnell was macht zwischen Tür und Angel... - ich Hornochse hab den falsche Log hochgeladen ::) - das war einer mit dem Test-Programm EmLog, das mit dem IR-Lesekopf mitkommt.
Jetzt der richtige Log, aufgenommen mit dem FHEM-Event-Monitor.
Das war wahrscheinlich sogar gut so. Denn sonst hätten wir nie gesehen, dass der Zähler tatsächlich die Werte mit Suffix liefert, die das Modul offenbar schon vor dem Event Monitor in "total_consumption" übersetzt. Hier sieht man es ja auch beispielsweise:
2018-01-02 10:04:52 OBIS Stromzaehler 1.0.1.6.1.01: 1712020515
2018-01-02 10:04:53 OBIS Stromzaehler 1.0.1.6.1.02: 1711181145
2018-01-02 10:04:55 OBIS Stromzaehler 1.0.1.6.1.03: 1710120715
2018-01-02 10:04:56 OBIS Stromzaehler 1.0.1.6.1.04: 1709210845
2018-01-02 10:04:57 OBIS Stromzaehler 1.0.1.6.1.05: 1708040800
2018-01-02 10:04:58 OBIS Stromzaehler 1.0.1.6.1.06: 1707250515
2018-01-02 10:05:00 OBIS Stromzaehler 1.0.1.6.1.07: 1706070330
2018-01-02 10:05:01 OBIS Stromzaehler 1.0.1.6.1.08: 1705060430
2018-01-02 10:05:02 OBIS Stromzaehler 1.0.1.6.1.09: 1704082200
2018-01-02 10:05:03 OBIS Stromzaehler 1.0.1.6.1.10: 1703232045
2018-01-02 10:05:05 OBIS Stromzaehler 1.0.1.6.1.11: 1702220745
2018-01-02 10:05:06 OBIS Stromzaehler 1.0.1.6.1.12: 1701240830
2018-01-02 10:05:07 OBIS Stromzaehler 1.0.1.6.1.13: 1612301230
2018-01-02 10:05:08 OBIS Stromzaehler 1.0.1.6.1.14: 1611271800
2018-01-02 10:05:10 OBIS Stromzaehler 1.0.1.6.1.15: 1611251145
Gib dem Attribut mal eine Chance.
Yeah - der Workaround tut's...! ;D
In den Readings sehe ich jetzt...
Einspeisung_Vormon 3565.513 2018-01-02 12:47:50
Einspeisung_akt 3565.799 2018-01-02 12:44:54
Verbrauch_Vormon 6034.338 2018-01-02 12:45:32
Verbrauch_akt 6068.426 2018-01-02 12:44:47
Hier die Lösung meines Problems:
attr Stromzaehler suppressReading {total_consumption.*, total_feed.*}
attr Stromzaehler channels {"1-0:1.8.0*255"=>"Verbrauch_akt","1-0:1.8.0*01"=>"Verbrauch_Vormon","1-0:2.8.0*255"=>"Einspeisung_akt","1-0:2.8.0*01"=>"Einspeisung_Vormon"}
Vielen Dank an tatu123, der das analog bei seinem Problem gemacht hat und an Willy mit seiner "Engelsgeduld" mir zu Helfen.
Again what learnd...! ;D
Ich habe seit heute urplötzlich folgende Ausgabe im FHEM-Log:
2018.01.02 17:14:50.130 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN286691> line 1.
2018.01.02 17:14:50.132 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN286691> line 1.
Wie immer: Am System hat niemand etwas verändert. :-)
Hat jemand einen Tipp woher das kommt? Danke.
Ich habe auch (immernoch) ein Problem.
Stefan antwortete mir damals:
Zitat von: Icinger am 07 August 2017, 07:34:49
Ich kann das zwar in keinster Weise nachvollziehen, aber einen Versuch ists alle mal wert, in der config zu schauen, ob "interval" vor dem "alignTime" definiert wird.
lg, Stefan
Das löste zwar das Problem insofern, dass die "alignTime" Attribute nicht mehr gelöscht wurden, dennoch habe ich seither immer wieder Einträge im Logfile
OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified
Das liegt nach wie vor daran, dass FHEM beim speichern die Attribute alphabetisch sortiert. Aber das OBIS-Modul akzeptiert nicht, dass alignTime vor interval gelesen wird; deshalb kommt die Meldung ins Logfile.
Einer, der es wissen müsste, schrieb hier
https://forum.fhem.de/index.php/topic,69494.msg611381.html#msg611381 (https://forum.fhem.de/index.php/topic,69494.msg611381.html#msg611381):
ZitatDie Attribute werden immer alphabetisch sortiert gespeichert, d.h. eine manuelle Umsortierung ist hier nur von kurzer Dauer. Da der Modul-Maintainer sich darauf verlassen kann, kann er notfalls die Namen der Attribute anpassen. Oder die Pruefung erst nach der Initialisierung ($init_done) durchfuehren.
Mit anderen Worten: wenn das OBIS-Modul mit einer alphabetischen Sortierung der Attribute zu solchen Fehlermeldungen neigt, dann ist das ein Bug.
==> Stefan: kannst Du das bitte korrigieren, z.B. in der von Rudolf König vorgeschlagenen Weise?
Hi Leute,
Frohes neues Jahr!
Hab grad nen kleines Update eingespielt:
*) Commandref-Patch von krikan
*) Die alignTime is useless, if no interval is specified-Meldung kommt nur mehr, wenn FHEM schon initialized ist.
*) Roro's "binärer Schrott"-Fehler sollte (hoffentlich) nicht mehr auftreten. Es werden in der SMLDecode-Routine nur mehr "printable chars" akzeptiert, alles andere wird durch nen . ersetzt (hoff ich mal)
*) tr_ex's Vorschlag für den AS1440 wurde implementiert. Der Zähler wird mit "/2!" initialisiert statt mit "/?!"....Damit bleiben bei seinem Zähler die Vorwerte weg. Könnte das jemand anders auch probieren, bitte?
Soweit mal ein Anfang :)
lg, Stefan
Klingt prima, besten Dank.
Aber was verstehe ich unter "...kommt nur mehr, wenn FHEM schon initialized ist"?
PS: ebenfalls Alles Gute zum neuen Jahr!
ZitatAber was verstehe ich unter "...kommt nur mehr, wenn FHEM schon initialized ist"?
Dass diese Fehlermeldung nur dann kommt, wenn der User selbst das alignTime-Attr setzt, ohne ein Intervall gesetzt zu haben.
Wenn das Attribut im Zuge des einlesens der Config (beim Hochfahren, bei rereadcfg...) gesetzt wird, wird das attr erstmal gesetzt und darauf "gehofft", dass auch ein intervall noch aus der config folgt :)
lg, Stefan
Klingt brauchbar, danke.
@Icinger:
Hattest du das hier heute zufällig gesehen?
Hast du dazu ne Idee? Danke.
Zitat von: FunkOdyssey am 02 Januar 2018, 17:28:53
Ich habe seit heute urplötzlich folgende Ausgabe im FHEM-Log:
2018.01.02 17:14:50.130 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN286691> line 1.
2018.01.02 17:14:50.132 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN286691> line 1.
Wie immer: Am System hat niemand etwas verändert. :-)
Hat jemand einen Tipp woher das kommt? Danke.
Irgendwann hatte ich diesen Fehler schon mal, kann mich nur nimmer erinnern.....
Ein LogV5 wäre von vorteil und ein list vom Gerät.
Gute Nacht,
Stefan
PS: Kurz gegoogelt.....Dein Zähler liefert scheinbar 64bit-Werte :o
ZitatJust because perl issues a warning, it doesn't mean perl doesn't do the right thing. It's true, converting "0x000fffff7f00fffc" with hex is non-portable as it won't do the same thing on a 32-bit perl (to which I say, so what? Adding number isn't portable either, as you may get different results as well, but addition doesn't come with a warning).
Schick trotzdem mel ein Log, vlt. fällt mir irgendwas ein.
Zitat von: Icinger am 02 Januar 2018, 21:45:27
Hi Leute,
Frohes neues Jahr!
Hab grad nen kleines Update eingespielt:
*) Commandref-Patch von krikan
*) Die alignTime is useless, if no interval is specified-Meldung kommt nur mehr, wenn FHEM schon initialized ist.
*) Roro's "binärer Schrott"-Fehler sollte (hoffentlich) nicht mehr auftreten. Es werden in der SMLDecode-Routine nur mehr "printable chars" akzeptiert, alles andere wird durch nen . ersetzt (hoff ich mal)
*) tr_ex's Vorschlag für den AS1440 wurde implementiert. Der Zähler wird mit "/2!" initialisiert statt mit "/?!"....Damit bleiben bei seinem Zähler die Vorwerte weg. Könnte das jemand anders auch probieren, bitte?
Soweit mal ein Anfang :)
lg, Stefan
Hi Stefan,
seit Deinem Update von gestern Abend stürzt mein fhem unwiderruflich ab, sobald ich einen Raum öffne, in dem ein OBIS-Device vorhanden ist.
fhem-Log zeigt folgendes:
Undefined subroutine &main::myOBIS_Set called at fhem.pl line 3488.Nach kurzem Debugging glaube ich (in meinem jugendlichen Leichtsinn) den Fehler (zumindest ist es bei mir einer) gefunden zu haben:
79 79 # $hash->{SetFn} = "OBIS_Set";
80 $hash->{SetFn} = "myOBIS_Set";Wenn ich myOBIS_Set wieder durch OBIS_Set ersetze funktioniert alles einwandfrei.
Falls der Fehler doch bei mir liegt, lasst es mich bitte wissen.
Gruß
Richtig debuggt, allerdings kannst du die Zeile komplett auskommentieren.
Die ist mir wieder mal reingerutscht beim debuggen :)
lg, Stefan
Hallo Icinger,
danke, dass du deine Hilfe anbietest. Die einzige Änderungen waren eigentlich nur der Jahreswechsel und der Wechsel des Stromanbieter. Ich weiß aber nicht, wieso sich das auf den Zähler auswirken sollte. Und am 01.01. war es auch noch ruhig. Es ging erst am 02.01. um 13:30 Uhr los mit den Warnungen.
List vom Device
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01065B27-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01065B27-if00-port0@9600,8,N,1
MeterType SML
NAME obis_stromzaehler
NR 434
PARTIAL
STATE 442.43
TYPE OBIS
READINGS:
2018-01-03 14:09:47 1.0.0.0.0.255 31-45-53-59-31-31-36-30-37-35-36-35-37-30
2018-01-03 14:09:47 1.0.0.0.9.255 09-01-45-53-59-11-03-9F-12-5A
2018-01-03 14:09:47 129.129.199.130.3.255 ESY
2018-01-03 14:09:47 129.129.199.130.5.255 E2EB-8458-74D8-B964-A8E1-8B0C-D4C5-C5B5-A475-AFC7-5B47-632A-0BAF-87D7-5E78-6E97-588A-A19B-D919-0846-1225-6F47-32B3-438F-01
2017-12-31 04:01:16 Version ESY\090145535911039F125A\3145535931313630373536353730
2018-01-03 14:09:47 counter 445.8104125
2018-01-03 14:09:47 energy 445.8104125
2018-01-03 14:09:47 power 442.43
2018-01-03 14:09:47 power_L1 136.41
2018-01-03 14:09:47 power_L2 192.77
2018-01-03 14:09:47 power_L3 113.24
2018-01-02 22:23:40 state opened
2018-01-03 14:09:47 total_consumption 445810.4125
2018-01-03 14:09:47 total_consumption_Ch1 445600.4744
2018-01-03 14:09:47 total_consumption_Ch2 209.9381
2018-01-03 14:09:47 voltage_L1 222.7
2018-01-03 14:09:47 voltage_L2 221
2018-01-03 14:09:47 voltage_L3 229.1
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1514928220.12291
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
DEVICES:
120
Attributes:
channels {"1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
event-on-change-reading total_consumption,energy,power,counter
ignoreUnknown off
interval 120
pollingMode on
stateFormat power
unitReadings off
userReadings energy:total_consumption.* {ReadingsNum($name,"total_consumption",0)/1000},
counter:total_consumption.* {ReadingsNum($name,"total_consumption",0)/1000}
verbose 5
Verbose 5 Log
2018.01.03 14:11:46.623 5: SW:
2018.01.03 14:11:46.625 4: Wrote
2018.01.03 14:11:46.627 5: OBIS (obis_stromzaehler) - Internal timer set to 2018-01-03 14:13:46
2018.01.03 14:11:46.828 5: SML-Parse 1B1B1B1B01010101760B4553594D125A006B8F60620062007263010176010445535908455359DB758F600B090145535911039F125A0101636F4400760B4553594D125A006B8F61620062007263070177010B090145535911039F125A070100620AFFFF726201650023DB757E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BB8D910177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.841 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D125A006B8F60620062007263010176010445535908455359DB758F600B090145535911039F125A0101636F4400760B4553594D125A006B8F61620062007263070177010B090145535911039F125A070100620AFFFF726201650023DB757E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BB8D910177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.843 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D125A006B8F60620062007263010176010445535908455359DB758F600B090145535911039F125A0101636F4400760B4553594D125A006B8F61620062007263070177010B090145535911039F125A070100620AFFFF726201650023DB757E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BB8D910177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.846 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BB8D910177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.848 5: OBIS: Telegram=0177070100010800FF6401018001621E52FC590000000109BB8D910177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.850 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN91149> line 1.
2018.01.03 14:11:46.851 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN91149> line 1.
2018.01.03 14:11:46.852 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000001099B84DB0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.855 5: OBIS: Telegram=0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.857 5: OBIS: Telegram=0177070100100700FF0101621B52FE59000000000000B0910177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.859 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000035000177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.860 5: OBIS: Telegram=0177070100380700FF0101621B52FE590000000000004FE701770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.862 5: OBIS: Telegram=01770701004C0700FF0101621B52FE590000000000002BA90177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.863 5: OBIS: Telegram=0177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.865 5: OBIS: Telegram=77070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.866 5: OBIS: Telegram=0177070100200700FF0101622352FF6308AE0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.868 5: OBIS: Telegram=0177070100340700FF0101622352FF6308B80177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.870 5: OBIS: Telegram=0177070100480700FF0101622352FF6308DD01010163175700760B4553594D125A006B8F626200620072630201710163C735000000001B1B1B1B1A032A1B
2018.01.03 14:11:46.871 4: MSG IS:
/ESY\090145535911039F125A\3145535931313630373536353730
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039F125A)
1-0:1.8.0*255(445825.3713*Wh)
1-0:1.8.1*255(445615.4331*Wh)
1-0:1.8.2*255(209.9381*Wh)
1-0:16.7.0*255(452.01*W)
1-0:36.7.0*255(135.68*W)
1-0:56.7.0*255(204.55*W)
1-0:76.7.0*255(111.77*W)
129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
1-0:0.0.0*255(3145535931313630373536353730)
1-0:32.7.0*255(222.2*V)
1-0:52.7.0*255(223.2*V)
1-0:72.7.0*255(226.9*V)
!
2018.01.03 14:11:46.873 5: OBIS (obis_stromzaehler) - Msg-Parse: /ESY\090145535911039F125A\3145535931313630373536353730
2018.01.03 14:11:46.874 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2018.01.03 14:11:46.875 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2018.01.03 14:11:46.878 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039F125A)
2018.01.03 14:11:46.879 5: Msg 1-0:0.0.9*255(090145535911039F125A) is of type Serial
2018.01.03 14:11:46.882 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.0*255(445825.3713*Wh)
2018.01.03 14:11:46.883 5: Msg 1-0:1.8.0*255(445825.3713*Wh) is of type Counter
2018.01.03 14:11:46.885 4: Set total_consumption to 445825.3713
2018.01.03 14:11:46.887 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.1*255(445615.4331*Wh)
2018.01.03 14:11:46.888 5: Msg 1-0:1.8.1*255(445615.4331*Wh) is of type Counter
2018.01.03 14:11:46.889 4: Set total_consumption_Ch1 to 445615.4331
2018.01.03 14:11:46.891 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.2*255(209.9381*Wh)
2018.01.03 14:11:46.892 5: Msg 1-0:1.8.2*255(209.9381*Wh) is of type Counter
2018.01.03 14:11:46.893 4: Set total_consumption_Ch2 to 209.9381
2018.01.03 14:11:46.895 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:16.7.0*255(452.01*W)
2018.01.03 14:11:46.896 5: Msg 1-0:16.7.0*255(452.01*W) is of type Channels
2018.01.03 14:11:46.898 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:36.7.0*255(135.68*W)
2018.01.03 14:11:46.901 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:56.7.0*255(204.55*W)
2018.01.03 14:11:46.903 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:76.7.0*255(111.77*W)
2018.01.03 14:11:46.905 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
2018.01.03 14:11:46.906 5: Msg 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01) is of type PublicKey
2018.01.03 14:11:46.908 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.0*255(3145535931313630373536353730)
2018.01.03 14:11:46.910 5: Msg 1-0:0.0.0*255(3145535931313630373536353730) is of type Owner
2018.01.03 14:11:46.912 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:32.7.0*255(222.2*V)
2018.01.03 14:11:46.913 5: Msg 1-0:32.7.0*255(222.2*V) is of type Channels
2018.01.03 14:11:46.915 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:52.7.0*255(223.2*V)
2018.01.03 14:11:46.916 5: Msg 1-0:52.7.0*255(223.2*V) is of type Channels
2018.01.03 14:11:46.918 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:72.7.0*255(226.9*V)
2018.01.03 14:11:46.919 5: Msg 1-0:72.7.0*255(226.9*V) is of type Channels
2018.01.03 14:11:46.921 5: OBIS (obis_stromzaehler) - Msg-Parse: !
2018.01.03 14:13:46.636 5: SW:
2018.01.03 14:13:46.638 4: Wrote
2018.01.03 14:13:46.639 5: OBIS (obis_stromzaehler) - Internal timer set to 2018-01-03 14:15:46
2018.01.03 14:13:48.473 5: SML-Parse 1B1B1B1B01010101760B4553594D125A006B90CB620062007263010176010445535908455359DBEE90CB0B090145535911039F125A010163EE6B00760B4553594D125A006B90CC620062007263070177010B090145535911039F125A070100620AFFFF726201650023DBEE7E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BE1DBD0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.478 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D125A006B90CB620062007263010176010445535908455359DBEE90CB0B090145535911039F125A010163EE6B00760B4553594D125A006B90CC620062007263070177010B090145535911039F125A070100620AFFFF726201650023DBEE7E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BE1DBD0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.479 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D125A006B90CB620062007263010176010445535908455359DBEE90CB0B090145535911039F125A010163EE6B00760B4553594D125A006B90CC620062007263070177010B090145535911039F125A070100620AFFFF726201650023DBEE7E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BE1DBD0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.481 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000109BE1DBD0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.482 5: OBIS: Telegram=0177070100010800FF6401018001621E52FC590000000109BE1DBD0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.483 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN91323> line 1.
2018.01.03 14:13:48.484 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN91323> line 1.
2018.01.03 14:13:48.485 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000001099E15080177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.486 5: OBIS: Telegram=0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.487 5: OBIS: Telegram=0177070100100700FF0101621B52FE59000000000000D3760177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.488 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000036670177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.490 5: OBIS: Telegram=0177070100380700FF0101621B52FE59000000000000769501770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.491 5: OBIS: Telegram=01770701004C0700FF0101621B52FE5900000000000026790177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.492 5: OBIS: Telegram=0177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.493 5: OBIS: Telegram=77070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.494 5: OBIS: Telegram=0177070100200700FF0101622352FF6308CC0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.495 5: OBIS: Telegram=0177070100340700FF0101622352FF6308B50177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.496 5: OBIS: Telegram=0177070100480700FF0101622352FF6308CE0101016369C200760B4553594D125A006B90CD6200620072630201710163B6C4000000001B1B1B1B1A032E13
2018.01.03 14:13:48.497 4: MSG IS:
/ESY\090145535911039F125A\3145535931313630373536353730
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039F125A)
1-0:1.8.0*255(445842.1693*Wh)
1-0:1.8.1*255(445632.2312*Wh)
1-0:1.8.2*255(209.9381*Wh)
1-0:16.7.0*255(541.34*W)
1-0:36.7.0*255(139.27*W)
1-0:56.7.0*255(303.57*W)
1-0:76.7.0*255(98.49*W)
129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
1-0:0.0.0*255(3145535931313630373536353730)
1-0:32.7.0*255(225.2*V)
1-0:52.7.0*255(222.9*V)
1-0:72.7.0*255(225.4*V)
!
2018.01.03 14:13:48.498 5: OBIS (obis_stromzaehler) - Msg-Parse: /ESY\090145535911039F125A\3145535931313630373536353730
2018.01.03 14:13:48.499 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2018.01.03 14:13:48.500 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2018.01.03 14:13:48.501 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039F125A)
2018.01.03 14:13:48.502 5: Msg 1-0:0.0.9*255(090145535911039F125A) is of type Serial
2018.01.03 14:13:48.503 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.0*255(445842.1693*Wh)
2018.01.03 14:13:48.504 5: Msg 1-0:1.8.0*255(445842.1693*Wh) is of type Counter
2018.01.03 14:13:48.505 4: Set total_consumption to 445842.1693
2018.01.03 14:13:48.506 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.1*255(445632.2312*Wh)
2018.01.03 14:13:48.507 5: Msg 1-0:1.8.1*255(445632.2312*Wh) is of type Counter
2018.01.03 14:13:48.507 4: Set total_consumption_Ch1 to 445632.2312
2018.01.03 14:13:48.508 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.2*255(209.9381*Wh)
2018.01.03 14:13:48.509 5: Msg 1-0:1.8.2*255(209.9381*Wh) is of type Counter
2018.01.03 14:13:48.510 4: Set total_consumption_Ch2 to 209.9381
2018.01.03 14:13:48.511 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:16.7.0*255(541.34*W)
2018.01.03 14:13:48.512 5: Msg 1-0:16.7.0*255(541.34*W) is of type Channels
2018.01.03 14:13:48.513 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:36.7.0*255(139.27*W)
2018.01.03 14:13:48.514 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:56.7.0*255(303.57*W)
2018.01.03 14:13:48.516 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:76.7.0*255(98.49*W)
2018.01.03 14:13:48.517 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
2018.01.03 14:13:48.518 5: Msg 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01) is of type PublicKey
2018.01.03 14:13:48.519 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.0*255(3145535931313630373536353730)
2018.01.03 14:13:48.520 5: Msg 1-0:0.0.0*255(3145535931313630373536353730) is of type Owner
2018.01.03 14:13:48.521 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:32.7.0*255(225.2*V)
2018.01.03 14:13:48.522 5: Msg 1-0:32.7.0*255(225.2*V) is of type Channels
2018.01.03 14:13:48.523 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:52.7.0*255(222.9*V)
2018.01.03 14:13:48.524 5: Msg 1-0:52.7.0*255(222.9*V) is of type Channels
2018.01.03 14:13:48.525 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:72.7.0*255(225.4*V)
2018.01.03 14:13:48.526 5: Msg 1-0:72.7.0*255(225.4*V) is of type Channels
2018.01.03 14:13:48.527 5: OBIS (obis_stromzaehler) - Msg-Parse: !
Super, schau ich mir an.
Aktuell was anderes: Ist jemand online, der Zeit hat was zu testen? Bräuchte jemanden mit History-Werten, die vom Zähler kommen.
also zB parabacus oder Martin Fischer :)
bitte eine kurze PN......
lg, Stefan
Zitat von: Icinger am 03 Januar 2018, 14:04:22
Richtig debuggt, allerdings kannst du die Zeile komplett auskommentieren.
Die ist mir wieder mal reingerutscht beim debuggen :)
lg, Stefan
ja, habe ich ja auch gemacht :-)
änderst du das wieder im Repository?
was ich nicht verstehe, wieso ist da außer mir niemand drüber gestolpert außer mir? Müsste doch eigentlich jeden betreffen...
Wird heute noch geupdatet, morgen früh kommt die reparierte Version per update.
Müsste jeden betreffen, der HEUTE ein Update gemacht hat :) Da vermutlich ein Großteil nicht täglich updatet (ich ja auch nicht), wirds nicht so viele betreffen :)
lg, Stefan
ich habe heute auch mal nach langem wieder geupdatet, scheinbar hätte ich lieber noch länger gewartet ;D
Immerhin konnte ich so auch für andere ein wenig was beitragen.
Grüße! 8)
Zitat von: Icinger am 02 Januar 2018, 21:45:27
*) Roro's "binärer Schrott"-Fehler sollte (hoffentlich) nicht mehr auftreten. Es werden in der SMLDecode-Routine nur mehr "printable chars" akzeptiert, alles andere wird durch nen . ersetzt (hoff ich mal)
So, nachdem mein FHEM wieder startet ("my" gelöscht) muss ich leider feststellen, dass sich das Verhalten nach Setzen des interval-Attributs leider nicht wesentlich verändert hat.
Mit interval sieht mein log so aus:
2018.01.03 20:37:45 5: SW:
2018.01.03 20:37:45 4: Wrote
2018.01.03 20:37:45 5: OBIS (stromzaehler) - Internal timer set to 2018-01-03 20:38:05
2018.01.03 20:37:49 5: SML-Parse 1B1B1B1B0101010176050083E82A620062007263010176010105002BF80E0B0A0149534B000421237972620165002BF4F6016346910076050083E82B620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4F6747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035BA250177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 5: OBIS: Full message-> 1B1B1B1B0101010176050083E82A620062007263010176010105002BF80E0B0A0149534B000421237972620165002BF4F6016346910076050083E82B620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4F6747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035BA250177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 5: OBIS: Telegram=1B1B1B1B0101010176050083E82A620062007263010176010105002BF80E0B0A0149534B000421237972620165002BF4F6016346910076050083E82B620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4F6747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035BA250177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 5: OBIS: Telegram=0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035BA250177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 5: OBIS: Telegram=0177070100010800FF65001C010401621E52FF650035BA250177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 5: OBIS: Telegram=0177070100100700FF0101621B5200530286010101633E440076050083E82C6200620072630201710163C7080000001B1B1B1B1A02733D
2018.01.03 20:37:49 4: MSG IS:
/
1-0:96.50.1*255(ISK)
1-0:96.1.0*255(
ISK!#y)
1-0:1.8.0*255(352106.1*Wh)
1-0:16.7.0*255(646*W)
!
2018.01.03 20:37:49 5: OBIS (stromzaehler) - Msg-Parse: /
2018.01.03 20:37:49 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.50.1*255(ISK)
2018.01.03 20:37:49 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ISK!#y)
Man beachte, dass in der letzten Logzeile scheinbar ein Zeilenumbruch vorkommt und dass das Log für diesen Durchgang hier endet!
Ohne interval-Attribut sieht es hingegen so aus:
2018.01.03 20:37:25 5: SML-Parse 1B1B1B1B0101010176050083E7E8620062007263010176010105002BF7F80B0A0149534B000421237972620165002BF4E00163D0D90076050083E7E9620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4E0747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035B9FD0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 5: OBIS: Full message-> 1B1B1B1B0101010176050083E7E8620062007263010176010105002BF7F80B0A0149534B000421237972620165002BF4E00163D0D90076050083E7E9620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4E0747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035B9FD0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 5: OBIS: Telegram=1B1B1B1B0101010176050083E7E8620062007263010176010105002BF7F80B0A0149534B000421237972620165002BF4E00163D0D90076050083E7E9620062007263070177010B0A0149534B0004212379070100620AFFFF72620165002BF4E0747707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035B9FD0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 5: OBIS: Telegram=0177070100600100FF010101010B0A0149534B00042123790177070100010800FF65001C010401621E52FF650035B9FD0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 5: OBIS: Telegram=0177070100010800FF65001C010401621E52FF650035B9FD0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 5: OBIS: Telegram=0177070100100700FF0101621B520053028B010101634B5F0076050083E7EA6200620072630201710163DA2A0000001B1B1B1B1A02A009
2018.01.03 20:37:25 4: MSG IS:
/
1-0:96.50.1*255(ISK)
1-0:96.1.0*255(
ISK!#y)
1-0:1.8.0*255(352102.1*Wh)
1-0:16.7.0*255(651*W)
!
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: /
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.50.1*255(ISK)
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ISK!#y)
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: 1-0:1.8.0*255(352102.1*Wh)
2018.01.03 20:37:25 5: Msg 1-0:1.8.0*255(352102.1*Wh) is of type Counter
2018.01.03 20:37:25 4: Set total_consumption to 352102.1
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: 1-0:16.7.0*255(651*W)
2018.01.03 20:37:25 5: Msg 1-0:16.7.0*255(651*W) is of type Channels
2018.01.03 20:37:25 5: OBIS (stromzaehler) - Msg-Parse: !
Auch hier gibt es in "1-0:96.1.0*255" einen Zeilenumbruch, aber danach kommen noch weitere Messages, die geparst werden...
Gruß
Roland
PS: Beim Start von FHEM sehe ich folgende beiden Warnungen im Log:
2018.01.03 20:19:25 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 480, <$fh> line 42.
2018.01.03 20:19:25 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 792, <$fh> line 42.
Wobei, die gab es mit der letzten Version auch schon...
Ok, dann muss ich mal weitersuche, wo da der Fehler liegt......
Auf welchen Wert hast du eigentlich Interval gesetzt?
lg, Stefan
Zitat von: der_oBi am 03 Januar 2018, 18:15:03
was ich nicht verstehe, wieso ist da außer mir niemand drüber gestolpert außer mir? Müsste doch eigentlich jeden betreffen...
Ältere Menschen (solche wie ich) sind nicht mehr so schnell wie die jungen. Zu CPM-Zeiten gab es keine Updates, es sei denn man machte sie mit dem Hex-Editor selbst. Zu Zeiten von DOS 4 und Windows 3.1 habe ich auch immer sofort jedes Update eingespielt - mit dem Ergebnis, dass wegen Bugs in den Bugfixes oft gar nichts mehr lief. Dann durfte man das letzte Backup mit Hilfe von 50 - 60 Floppy-Disketten wieder restaurieren.
Wenn alte Leute langsamer sind, dann ist das nicht immer Gebrechlichkeit, sondern manchmal auch Erfahrung :).
Zitat von: Icinger am 03 Januar 2018, 21:12:27
Ok, dann muss ich mal weitersuche, wo da der Fehler liegt......
Auf welchen Wert hast du eigentlich Interval gesetzt?
lg, Stefan
Diesmal auf 60. Ich hatte aber auch schon Mal 10 probiert.
Gesendet von meinem XT1635-02 mit Tapatalk
Zitat von: Icinger am 02 Januar 2018, 23:09:33
PS: Kurz gegoogelt.....Dein Zähler liefert scheinbar 64bit-Werte :o
Schick trotzdem mel ein Log, vlt. fällt mir irgendwas ein.
Tatsächlich. Der Counter war zum Tatzeitpunkt > 4294967295.
dies scheint die Schwelle zu 64 bit zu sein, oder?
Aus der Herstellerdoku:
Zitat
Es werden pro Datensatz folgende Messwerte ausgegeben:
der Zählwerksstand T0 (1.8.0 und/oder 2.8.0) (13-stellig in kWh, mit 6 Vor- und 7 Nachkommastellen)
derTarifregisterstandT1(1.8.1und/oder2.8.1) (8-stellig in kWh, mit 6 Vor- und 2 Nachkommastellen)
der Tarifregisterstand T2 (1.8.2 und/oder 2.8.2) (8-stellig in kWh, mit 6 Vor- und 2 Nachkommastellen)
diePhasenleistungenPL1,PL2,PL3
(71⁄2-stellig in W, 5 Vor- und 2 Nachkommastellen, Vorzeichen)
dieSummenleistungPtot
(71⁄2-stellig in W, 5 Vor- und 2 Nachkommastellen, Vorzeichen)
diePhasenspannungUL1,UL2,UL3
(4-stellig in V, 3 Vor- und 1 Nachkommastellen)
Der Easymeter Q3M Zähler ist komplett neu. Im November getauscht.
Mein Gedamtverbrauch liegt heute bei: 487489.137 Wh
Beim alten Zähler wurde in kWh übermittelt.
Wäre echt super, wenn du mir helfen könntest. Auch mit verbose=0 werde ich die Warnungen nicht los.
Zitat von: Icinger am 02 Januar 2018, 21:45:27
*) tr_ex's Vorschlag für den AS1440 wurde implementiert. Der Zähler wird mit "/2!" initialisiert statt mit "/?!"....Damit bleiben bei seinem Zähler die Vorwerte weg. Könnte das jemand anders auch probieren, bitte?
Ich habe es mal probiert und für gut befunden :)
Die Vorwerte sind zwar die Daten, die der Netzbetreiber aus meinem Zähler bekommt, aber die finde ich bei Fhem auch in der DB. Daher vielen Dank für die Optimierung. Die Abfrage ist damit bei mir von gut 5 Minuten auf nicht mal eine halbe Minute gesunken.
Gruß Vuffiraa
Hi, nach dem ich jetzt ein Jahr mit Volkszaehler meinen Doppeltarifzähler ausgelesen habe, habe ich mal den IR Lesekopf an Fhem angeschlossen.
Vielen Dank für das Modul, es hat auf anhieb geklappt!
Leider ist mein Zähler (PAF5EC3g00006) nicht sehr gesprächig und ich bekomme nur die beiden Zählerstände auf abruf.
Wie kann ich mir jetzt den aktuellen Verbrauch und Plot dazu Anzeigen?
Bzw. welche Einstellungen würdet ihr mir für OBIS empfehlen, damit hier sinvolle Werte rauskommen?
Hier noch ein List vom Device:
Internals:
CFGFN
CHANGED
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0106513B-if00-port0@300,7,E,1 VSM102
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0106513B-if00-port0@300,7,E,1
FD 31
MeterType VSM102
NAME KG_FL_SM_Heizung
NEXT 2018-01-07 21:31:00
NR 118
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2018-01-06 15:13:30 0.0.1 PAF
2018-01-06 15:13:31 0.2.0 1.29
2018-01-06 15:13:35 C.2.1
2018-01-06 15:06:26 Version PAF5EC3g00006
2018-01-07 21:30:06 Zaehlerstand_HT 910.92
2018-01-07 21:30:07 Zaehlerstand_NT 3628.67
2018-01-06 15:05:25 state opened
helper:
BUFFER
EoM 1
SPEED 0
SPEED2 0
TRIGGERTIME 1515357060
Channels:
1.8.1*00 Zaehlerstand_HT
1.8.2*00 Zaehlerstand_NT
DEVICES:
/?!
60
000
Attributes:
alias Zähler Heizung
alignTime 00:00
channels {"1.8.1*00"=>"Zaehlerstand_HT","1.8.2*00"=>"Zaehlerstand_NT"}
event-min-interval .*:1200
event-on-change-reading .*
ignoreUnknown on
interval 60
Vielen Dank für eure Unterstützung
Zitat von: Viktor am 07 Januar 2018, 21:47:05
... ich bekomme nur die beiden Zählerstände auf abruf...
Ui, ein hässliches Thema, das mir viele graue Haare einbrachte.
Ich habe mir dafür userReadings mit der "differential" Methode gemacht. Grob gesagt nimmt das userReading den Zählerstand minus dem vorherigen Zählerstand und teilt das Ergebnis durch die inzwischen vergangene Zeit. Dabei kommt es zu unschönen Ergebnissen mit ungefähr 87 Nachkommastellen ;), weshalb das Ganze dann noch per sprintf() gerundet wird.
defmod Hausstrom_Zaehler OBIS /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
attr Hausstrom_Zaehler alignTime 00:00:01
attr Hausstrom_Zaehler event-min-interval .*:5
attr Hausstrom_Zaehler event-on-change-reading .*
attr Hausstrom_Zaehler interval 60
attr Hausstrom_Zaehler pollingMode on
attr Hausstrom_Zaehler room Stromzaehler
attr Hausstrom_Zaehler userReadings P_Bezug_temp:total_consumption_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_consumption_Ch1",0)*3600000 }, \
P_Einsp_temp:total_feed_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_feed_Ch1",0)*3600000 }, \
P_Bezug_Watt:P_Bezug_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) }, \
P_Einsp_Watt:P_Einsp_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) }, \
Hast Du auch eine PV-Anlage, und willst aus beiden Zählerständen Eigenverbrauch bzw. Einspeisung ermitteln, dann wäre zusätzlich interessant:
defmod Strom_Eigenverbrauch at +*00:01:00 IF (\
((ReadingsAge("Hausstrom_Zaehler","P_Einsp_Watt",0) - ReadingsAge("PV_Zaehler","electricityPower",0)) < 1)\
and ((ReadingsAge("Hausstrom_Zaehler","P_Einsp_Watt",0) - ReadingsAge("PV_Zaehler","electricityPower",0)) > -1)\
and ([PV_Zaehler:electricityPower] > 0)\
)\
(IF (\
([PV_Zaehler:electricityPower] - [Hausstrom_Zaehler:P_Einsp_Watt] + [Hausstrom_Zaehler:P_Bezug_Watt]) > 0\
)\
(setreading Strom_Eigenverbrauch Verbrauch {([PV_Zaehler:electricityPower] - [Hausstrom_Zaehler:P_Einsp_Watt] + [Hausstrom_Zaehler:P_Bezug_Watt])}\
)\
ELSE\
(setreading Strom_Eigenverbrauch Verbrauch 0\
)\
)\
attr Strom_Eigenverbrauch alignTime 00:00:06
attr Strom_Eigenverbrauch room StromzaehlerDann musst D aber die Zählerauslesungen synchronisieren, z.B. mit dem alignTime-Attribut, oder wenn (wie bei mit) das Modul sowas nicht kann, sowas:
defmod PVgetData at +*00:01:00 set PV_Zaehler update
attr PVgetData alignTime 00:00:02
attr PVgetData room Stromzaehler
Der Check, ob die Werte synchron sind, ist im obigen DOIF bereits drin (ReadingsAge).
Ui, ein hässliches Thema, das mir viele graue Haare einbrachte.
Ich habe mir dafür userReadings mit der "differential" Methode gemacht. Grob gesagt nimmt das userReading den Zählerstand minus dem vorherigen Zählerstand und teilt das Ergebnis durch die inzwischen vergangene Zeit. Dabei kommt es zu unschönen Ergebnissen mit ungefähr 87 Nachkommastellen ;), weshalb das Ganze dann noch per sprintf() gerundet wird.
defmod Hausstrom_Zaehler OBIS /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
attr Hausstrom_Zaehler alignTime 00:00:01
attr Hausstrom_Zaehler event-min-interval .*:5
attr Hausstrom_Zaehler event-on-change-reading .*
attr Hausstrom_Zaehler interval 60
attr Hausstrom_Zaehler pollingMode on
attr Hausstrom_Zaehler room Stromzaehler
attr Hausstrom_Zaehler userReadings P_Bezug_temp:total_consumption_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_consumption_Ch1",0)*3600000 }, \
P_Einsp_temp:total_feed_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_feed_Ch1",0)*3600000 }, \
P_Bezug_Watt:P_Bezug_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) }, \
P_Einsp_Watt:P_Einsp_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) }, \
Hast Du auch eine PV-Anlage, und willst aus beiden Zählerständen Eigenverbrauch bzw. Einspeisung ermitteln, dann wäre zusätzlich interessant:
defmod Strom_Eigenverbrauch at +*00:01:00 IF (\
((ReadingsAge("Hausstrom_Zaehler","P_Einsp_Watt",0) - ReadingsAge("PV_Zaehler","electricityPower",0)) < 1)\
and ((ReadingsAge("Hausstrom_Zaehler","P_Einsp_Watt",0) - ReadingsAge("PV_Zaehler","electricityPower",0)) > -1)\
and ([PV_Zaehler:electricityPower] > 0)\
)\
(IF (\
([PV_Zaehler:electricityPower] - [Hausstrom_Zaehler:P_Einsp_Watt] + [Hausstrom_Zaehler:P_Bezug_Watt]) > 0\
)\
(setreading Strom_Eigenverbrauch Verbrauch {([PV_Zaehler:electricityPower] - [Hausstrom_Zaehler:P_Einsp_Watt] + [Hausstrom_Zaehler:P_Bezug_Watt])}\
)\
ELSE\
(setreading Strom_Eigenverbrauch Verbrauch 0\
)\
)\
attr Strom_Eigenverbrauch alignTime 00:00:06
attr Strom_Eigenverbrauch room Stromzaehler
Dann musst D aber die Zählerauslesungen synchronisieren, z.B. mit dem alignTime-Attribut, oder wenn (wie bei mir) das Modul sowas nicht kann, sowas:
defmod PVgetData at +*00:01:00 set PV_Zaehler update
attr PVgetData alignTime 00:00:02
attr PVgetData room Stromzaehler
Der Check, ob die Werte synchron sind, ist im obigen DOIF bereits drin (ReadingsAge).
Hi, erstmal Danke für Hilfe.
Also ein PV habe ich nicht. Nur Wärmepumpe und Solaranlage hängen an dem Zähler.
Muss event-min-interval nicht größer als der interval sein? So ist es doch wirkungslos?!
Das userReading mit differential habe ich mal eingefügt. Funktioniert, aber die Werte schwanken bei jedem interval, das füllt nur unnötig das Log. (das war mit dem Volkszaehler nicht so)
Ich habe jetzt noch das Modul ElectricityCalculator https://forum.fhem.de/index.php/topic,57106.0.html (https://forum.fhem.de/index.php/topic,57106.0.html) gefunden, das liefert eigentlich schon zuviele Readings ;D
Das Modul braucht nur die Zählerstände und errechnet alles andere automatisch.
Ich lasse mir jetz mal den "Verbrauch" (PowerCurrent) in ein Log schreiben und Versuche das mal in einem Plot darzustellen.
Außerdem habe ich den Interval auf 120 gestellt, da sonst die "Auflösung"/Sprünge (bei 2 Nachkommerstellen vom Zähler) bei 600W liegen :(
Wenn noch jemand weitere Tipps hat (auch bezüglich Plot Einstellungen) würde ich mich freuen.
Zitat von: Viktor am 11 Januar 2018, 22:52:23
... die Werte schwanken bei jedem interval, ...
Ich gehe nicht davon aus, dass der Stromverbrauch deines Hauses immer völlig konstant ist. Somit sind Schwankungen normal.
Inzwischen habe mit noch ein weiteres Problem bei meiner Installation beobachtet: die mit "pollingMode on" gemessenen Werte haben ein Delay, welches über die Laufzeit auf mehrere Minuten anwächst.
Soll heißen: Ich schalte den Wasserkocher ein und erst z.B. 15 Minuten später geht die gemessene Leistung hoch (beim Abschalten des Wasserkochers natürlich analog).
Durch ein Restart von FHEM kann ich das Delay erstmal wieder zurücksetzen, aber es wächst dann über die Zeit wieder an.
Wenn ich den pollingMode ganz ausschalte, scheint es keine Verzögerungen zu geben, aber ich möchte mit der dadurch entstehenden Datenflut nicht den Server und die Platte stressen, daher ist das keine sinnvolle Option.
Ich vermute mal, dass das Problem dadurch entsteht, dass die Daten in /dev/ttyUSB0 irgendwie gequeued und nicht zeitnah genug abgerufen werden, so dass ich dann immer alte Daten sehe.
Gruß
Roland
Das Problem mit den fehlenden Daten nach Konfigurieren eines interval habe ich jetzt gefunden: Das Problem ist der Wert von 1-0:96.1.0*255, welcher "ISK!#y" (oder so ähnlich) lautet und von OBIS_Parse() für "End of Message" gehaltet wird, weil $rmsg=~/!.*/ matcht. Das sorgt für den Abbruch des Parsers und folglich erhalte ich natürlich keine Daten, die im Datenstrom hinter 1-0:96.1.0*255 liegen.
Soweit ich erkennen kann, sollte folgender Patch das Problem beseitigen:
--- 47_OBIS.pm.org 2018-01-13 17:02:03.401721634 +0100
+++ 47_OBIS.pm 2018-01-13 19:17:41.513516901 +0100
@@ -461,7 +461,7 @@
# }
# End of Message
- if ($rmsg=~/!.*/) {
+ if ($rmsg eq '!') {
$hash->{helper}{EoM}+=1 if ($hash->{helper}{DEVICES}[1]>0);
}
#Version
Er sorgt dafür, dass "End of Message" nicht mehr bei einem Ausrufezeichen irgendwo in $rmsg erkannt wird, sondern nur noch dann, wenn $rmsg genau aus dem Ausrufezeichen besteht.
Ich hoffe, dass damit nicht für andere Leute Probleme entstehen, aber bei mir scheint es so zu funktionieren und ich kann jetzt das Attribut interval wieder wie gewünscht benutzen.
Ob das im vorherigen Posting genannte Problem mit dem Delay damit auch weg ist, muss ich noch testen...
Viele Grüße
Roland
Leider fixt mein Patch aus dem vorherigen Posting das Problem mit dem Delay aus dem vorletzten Posting nicht, sondern verschlimmert es nur.
Momentan habe ich interval auf 15 Sekunden konfiguriert, wenn ich das richtig verstehe, liefert der Stromzähler aber etwa im Sekundentakt neue Daten.
Es scheint mir, als würden diese Daten irgendwo gequeued (vielleicht in /dev/ttyUSB0?) und nur alle 15 Sekunden eines der Pakete aus der Queue ausgelesen.
Laut FHEM müsste der Herd bei uns immer noch eingeschaltet sein, obwohl wir inzwischen schon gegessen haben und der Herd seit über einer halben Stunde ausgeschaltet ist...
Eigentlich müsste das Device alle 15 Sekunden geleert werden und nur der neuste Datensatz ausgelesen werden, aber das passiert nicht, soweit ich erkennen kann.
Ja, das kommt davon, dass dein Zähler ohne Aufforderung Daten schickt.
Hab dir mal eine Testversion geschickt, damit sollte es klappen.
lg, Stefan
Hi Leute,
habe grade eine neue Version eingecheckt.
1) Der Fehler
2018.01.02 17:14:50.130 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN286691> line 1.
2018.01.02 17:14:50.132 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN286691> line 1. sollte nicht mehr auftreten.
2) Neues Attribut extChannels
Damit werden extra Readings für eventuelle Historywerte angelegt.
zB: 2018-01-14 18:30:29 total_consumption_Ch2 1123.449
2018-01-14 18:31:46 total_consumption_Ch2.15 1123.449
2018-01-14 18:31:46 total_consumption_Ch2.16 1219.258
2018-01-14 18:31:46 total_consumption_Ch2.17 1316.803
2018-01-14 18:31:46 total_consumption_Ch2.18 1322.39
2018-01-14 18:31:46 total_consumption_Ch2.19 1418.385
2018-01-14 18:31:46 total_consumption_Ch2.20 1517.557
2018-01-14 18:31:46 total_consumption_Ch2.21 1618.911
2018-01-14 18:31:46 total_consumption_Ch2.22 1709.101
2018-01-14 18:31:46 total_consumption_Ch2.23 1788.109
2018-01-14 18:31:46 total_consumption_Ch2.24 1805.232
2018-01-14 18:31:46 total_consumption_Ch2.25 1900.229
2018-01-14 18:31:46 total_consumption_Ch2.26 2003.413
2018-01-14 18:31:46 total_consumption_Ch2.27 2101.737
2018-01-14 18:31:46 total_consumption_Ch2.28 2211.632
2018-01-14 18:31:46 total_consumption_Ch2.29 2315.411
Inwieweit sich die Nummern dieser Historyreadings ändern, kann ich leider nicht sagen. Wenn ihr da mehr dazu habt, bitte um Info.
lg, Stefan
Oh, ist das geil. Ich wurde schon nervös - wollte dich aber nicht erneut darauf ansprechen. Mein FHEM war nahezu unbrauchbar, da die Logs das System in die Knie zwangen. Vielen vielen Dank. Du hast mir einen großen Gefallen getan.
Am Rande: Wäre das neue Attribut als ,,extChannels" (<> ,,ExtChannels") von der Namensgebung nicht konsistenter?
Zitat von: Icinger am 14 Januar 2018, 18:35:28
Hi Leute,
habe grade eine neue Version eingecheckt.
1) Der Fehler
2018.01.02 17:14:50.130 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN286691> line 1.
2018.01.02 17:14:50.132 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN286691> line 1. sollte nicht mehr auftreten.
Hmm, so leid es mir tut, aber der Fehler scheint noch vorhanden zu sein.
Verbose 5 Log:2018.01.14 19:47:40.694 5: SW:
2018.01.14 19:47:40.696 4: Wrote
2018.01.14 19:47:40.697 5: OBIS (obis_stromzaehler) - Internal timer set to 2018-01-14 19:49:40
2018.01.14 19:47:43.104 5: SML-Parse 1B1B1B1B01010101760B4553594D125A0097FCA8620062007263010176010445535908455359AA91FCA80B090145535911039F125A010163846C00760B4553594D125A0097FCA9620062007263070177010B090145535911039F125A070100620AFFFF726201650032AA917E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC5900000001607245C60177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.111 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D125A0097FCA8620062007263010176010445535908455359AA91FCA80B090145535911039F125A010163846C00760B4553594D125A0097FCA9620062007263070177010B090145535911039F125A070100620AFFFF726201650032AA917E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC5900000001607245C60177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.113 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D125A0097FCA8620062007263010176010445535908455359AA91FCA80B090145535911039F125A010163846C00760B4553594D125A0097FCA9620062007263070177010B090145535911039F125A070100620AFFFF726201650032AA917E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC5900000001607245C60177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.115 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC5900000001607245C60177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.117 5: OBIS: Telegram=0177070100010800FF6401018001621E52FC5900000001607245C60177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.119 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 371, <GEN64991> line 1.
2018.01.14 19:47:43.120 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 375, <GEN64991> line 1.
2018.01.14 19:47:43.121 5: OBIS: Telegram=0177070100010801FF0101621E52FC590000000160523D110177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.123 5: OBIS: Telegram=0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.125 5: OBIS: Telegram=0177070100100700FF0101621B52FE59000000000001AF360177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.128 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000025E50177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.130 5: OBIS: Telegram=0177070100380700FF0101621B52FE590000000000011AAC01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.131 5: OBIS: Telegram=01770701004C0700FF0101621B52FE590000000000006EA50177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.133 5: OBIS: Telegram=0177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.135 5: OBIS: Telegram=77070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.136 5: OBIS: Telegram=0177070100200700FF0101622352FF6308C00177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.138 5: OBIS: Telegram=0177070100340700FF0101622352FF6308E40177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.140 5: OBIS: Telegram=0177070100480700FF0101622352FF6308E201010163A87A00760B4553594D125A0097FCAA6200620072630201710163CA49000000001B1B1B1B1A036598
2018.01.14 19:47:43.141 4: MSG IS:
/ESY\090145535911039F125A\3145535931313630373536353730
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039F125A)
1-0:1.8.0*255(591306.8998*Wh)
1-0:1.8.1*255(591096.9617*Wh)
1-0:1.8.2*255(209.9381*Wh)
1-0:16.7.0*255(1103.9*W)
1-0:36.7.0*255(97.01*W)
1-0:56.7.0*255(723.64*W)
1-0:76.7.0*255(283.25*W)
129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
1-0:0.0.0*255(3145535931313630373536353730)
1-0:32.7.0*255(224*V)
1-0:52.7.0*255(227.6*V)
1-0:72.7.0*255(227.4*V)
!
2018.01.14 19:47:43.142 5: OBIS (obis_stromzaehler) - Msg-Parse: /ESY\090145535911039F125A\3145535931313630373536353730
2018.01.14 19:47:43.143 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2018.01.14 19:47:43.145 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2018.01.14 19:47:43.147 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039F125A)
2018.01.14 19:47:43.149 5: Msg 1-0:0.0.9*255(090145535911039F125A) is of type Serial
2018.01.14 19:47:43.151 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.0*255(591306.8998*Wh)
2018.01.14 19:47:43.152 5: Msg 1-0:1.8.0*255(591306.8998*Wh) is of type Counter
2018.01.14 19:47:43.153 4: Set total_consumption.255 to 591306.8998
2018.01.14 19:47:43.155 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.1*255(591096.9617*Wh)
2018.01.14 19:47:43.156 5: Msg 1-0:1.8.1*255(591096.9617*Wh) is of type Counter
2018.01.14 19:47:43.158 4: Set total_consumption_Ch1.255 to 591096.9617
2018.01.14 19:47:43.159 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.2*255(209.9381*Wh)
2018.01.14 19:47:43.161 5: Msg 1-0:1.8.2*255(209.9381*Wh) is of type Counter
2018.01.14 19:47:43.161 4: Set total_consumption_Ch2.255 to 209.9381
2018.01.14 19:47:43.163 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:16.7.0*255(1103.9*W)
2018.01.14 19:47:43.164 5: Msg 1-0:16.7.0*255(1103.9*W) is of type Channels
2018.01.14 19:47:43.166 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:36.7.0*255(97.01*W)
2018.01.14 19:47:43.170 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:56.7.0*255(723.64*W)
2018.01.14 19:47:43.172 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:76.7.0*255(283.25*W)
2018.01.14 19:47:43.174 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
2018.01.14 19:47:43.175 5: Msg 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01) is of type PublicKey
2018.01.14 19:47:43.178 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.0*255(3145535931313630373536353730)
2018.01.14 19:47:43.180 5: Msg 1-0:0.0.0*255(3145535931313630373536353730) is of type Owner
2018.01.14 19:47:43.182 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:32.7.0*255(224*V)
2018.01.14 19:47:43.183 5: Msg 1-0:32.7.0*255(224*V) is of type Channels
2018.01.14 19:47:43.185 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:52.7.0*255(227.6*V)
2018.01.14 19:47:43.186 5: Msg 1-0:52.7.0*255(227.6*V) is of type Channels
2018.01.14 19:47:43.188 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:72.7.0*255(227.4*V)
2018.01.14 19:47:43.190 5: Msg 1-0:72.7.0*255(227.4*V) is of type Channels
2018.01.14 19:47:43.192 5: OBIS (obis_stromzaehler) - Msg-Parse: !
2018.01.14 19:49:40.705 5: SW:
2018.01.14 19:49:40.707 4: Wrote
2018.01.14 19:49:40.708 5: OBIS (obis_stromzaehler) - Internal timer set to 2018-01-14 19:51:40
2018.01.14 19:49:41.961 5: SML-Parse 1B1B1B1B01010101760B4553594D125A0097FE04620062007263010176010445535908455359AB05FE040B090145535911039F125A010163364B00760B4553594D125A0097FE05620062007263070177010B090145535911039F125A070100620AFFFF726201650032AB057E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000160778C550177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.968 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D125A0097FE04620062007263010176010445535908455359AB05FE040B090145535911039F125A010163364B00760B4553594D125A0097FE05620062007263070177010B090145535911039F125A070100620AFFFF726201650032AB057E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000160778C550177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.969 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D125A0097FE04620062007263010176010445535908455359AB05FE040B090145535911039F125A010163364B00760B4553594D125A0097FE05620062007263070177010B090145535911039F125A070100620AFFFF726201650032AB057E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000160778C550177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.972 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039F125A0177070100010800FF6401018001621E52FC590000000160778C550177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.973 5: OBIS: Telegram=0177070100010800FF6401018001621E52FC590000000160778C550177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.975 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 371, <GEN65281> line 1.
2018.01.14 19:49:41.976 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 375, <GEN65281> line 1.
2018.01.14 19:49:41.977 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000001605783A00177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.979 5: OBIS: Telegram=0177070100010802FF0101621E52FC5900000000002008B50177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.981 5: OBIS: Telegram=0177070100100700FF0101621B52FE590000000000019D8A0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.983 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000029310177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.985 5: OBIS: Telegram=0177070100380700FF0101621B52FE59000000000001114401770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.986 5: OBIS: Telegram=01770701004C0700FF0101621B52FE5900000000000063150177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.988 5: OBIS: Telegram=0177078181C78205FF010101018302E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F0177070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.989 5: OBIS: Telegram=77070100000000FF010101010F31455359313136303735363537300177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.991 5: OBIS: Telegram=0177070100200700FF0101622352FF6308DD0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.992 5: OBIS: Telegram=0177070100340700FF0101622352FF6308DE0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.994 5: OBIS: Telegram=0177070100480700FF0101622352FF6308DD01010163312C00760B4553594D125A0097FE0662006200726302017101631FD9000000001B1B1B1B1A03FCA8
2018.01.14 19:49:41.995 4: MSG IS:
/ESY\090145535911039F125A\3145535931313630373536353730
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039F125A)
1-0:1.8.0*255(591341.4741*Wh)
1-0:1.8.1*255(591131.536*Wh)
1-0:1.8.2*255(209.9381*Wh)
1-0:16.7.0*255(1058.66*W)
1-0:36.7.0*255(105.45*W)
1-0:56.7.0*255(699.56*W)
1-0:76.7.0*255(253.65*W)
129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
1-0:0.0.0*255(3145535931313630373536353730)
1-0:32.7.0*255(226.9*V)
1-0:52.7.0*255(227*V)
1-0:72.7.0*255(226.9*V)
!
2018.01.14 19:49:41.996 5: OBIS (obis_stromzaehler) - Msg-Parse: /ESY\090145535911039F125A\3145535931313630373536353730
2018.01.14 19:49:41.997 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2018.01.14 19:49:41.999 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2018.01.14 19:49:42.001 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039F125A)
2018.01.14 19:49:42.003 5: Msg 1-0:0.0.9*255(090145535911039F125A) is of type Serial
2018.01.14 19:49:42.005 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.0*255(591341.4741*Wh)
2018.01.14 19:49:42.006 5: Msg 1-0:1.8.0*255(591341.4741*Wh) is of type Counter
2018.01.14 19:49:42.007 4: Set total_consumption.255 to 591341.4741
2018.01.14 19:49:42.009 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.1*255(591131.536*Wh)
2018.01.14 19:49:42.010 5: Msg 1-0:1.8.1*255(591131.536*Wh) is of type Counter
2018.01.14 19:49:42.011 4: Set total_consumption_Ch1.255 to 591131.536
2018.01.14 19:49:42.013 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:1.8.2*255(209.9381*Wh)
2018.01.14 19:49:42.014 5: Msg 1-0:1.8.2*255(209.9381*Wh) is of type Counter
2018.01.14 19:49:42.015 4: Set total_consumption_Ch2.255 to 209.9381
2018.01.14 19:49:42.017 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:16.7.0*255(1058.66*W)
2018.01.14 19:49:42.018 5: Msg 1-0:16.7.0*255(1058.66*W) is of type Channels
2018.01.14 19:49:42.020 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:36.7.0*255(105.45*W)
2018.01.14 19:49:42.023 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:56.7.0*255(699.56*W)
2018.01.14 19:49:42.025 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:76.7.0*255(253.65*W)
2018.01.14 19:49:42.027 5: OBIS (obis_stromzaehler) - Msg-Parse: 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01)
2018.01.14 19:49:42.028 5: Msg 129-129:199.130.5*255(E2EB845874D8B964A8E18B0CD4C5C5B5A475AFC75B47632A0BAF87D75E786E97588AA19BD919084612256F4732B3438F01) is of type PublicKey
2018.01.14 19:49:42.030 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:0.0.0*255(3145535931313630373536353730)
2018.01.14 19:49:42.032 5: Msg 1-0:0.0.0*255(3145535931313630373536353730) is of type Owner
2018.01.14 19:49:42.034 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:32.7.0*255(226.9*V)
2018.01.14 19:49:42.035 5: Msg 1-0:32.7.0*255(226.9*V) is of type Channels
2018.01.14 19:49:42.037 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:52.7.0*255(227*V)
2018.01.14 19:49:42.038 5: Msg 1-0:52.7.0*255(227*V) is of type Channels
2018.01.14 19:49:42.040 5: OBIS (obis_stromzaehler) - Msg-Parse: 1-0:72.7.0*255(226.9*V)
2018.01.14 19:49:42.041 5: Msg 1-0:72.7.0*255(226.9*V) is of type Channels
2018.01.14 19:49:42.042 5: OBIS (obis_stromzaehler) - Msg-Parse: !Kann ich irgendwie helfen, in dem ich irgendwo irgendwelche Debug-Zeilen ergänze?
Device
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01065B27-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01065B27-if00-port0@9600,8,N,1
MeterType SML
NAME obis_stromzaehler
NR 434
PARTIAL
STATE 812.99
TYPE OBIS
READINGS:
2018-01-14 19:55:43 1.0.0.0.0.255 31-45-53-59-31-31-36-30-37-35-36-35-37-30
2018-01-14 19:55:43 1.0.0.0.9.255 09-01-45-53-59-11-03-9F-12-5A
2018-01-14 19:55:43 129.129.199.130.3.255 ESY
2018-01-14 19:55:43 129.129.199.130.5.255 E2EB-8458-74D8-B964-A8E1-8B0C-D4C5-C5B5-A475-AFC7-5B47-632A-0BAF-87D7-5E78-6E97-588A-A19B-D919-0846-1225-6F47-32B3-438F-01
2017-12-31 04:01:16 Version ESY\090145535911039F125A\3145535931313630373536353730
2018-01-14 19:17:41 counter 590.8085608
2018-01-14 19:17:41 energy 590.8085608
2018-01-14 19:55:43 power 812.99
2018-01-14 19:55:43 power_L1 96.99
2018-01-14 19:55:43 power_L2 597.38
2018-01-14 19:55:43 power_L3 118.61
2018-01-14 12:31:36 state opened
2018-01-14 19:17:41 total_consumption 590808.5608
2018-01-14 19:55:43 total_consumption.255 591428.8071
2018-01-14 19:17:41 total_consumption_Ch1 590598.6227
2018-01-14 19:55:43 total_consumption_Ch1.255 591218.8689
2018-01-14 19:17:41 total_consumption_Ch2 209.9381
2018-01-14 19:55:43 total_consumption_Ch2.255 209.9381
2018-01-14 19:55:43 voltage_L1 224.5
2018-01-14 19:55:43 voltage_L2 218.7
2018-01-14 19:55:43 voltage_L3 228.3
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1515929496.24326
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
DEVICES:
120
directions:
Attributes:
ExtChannels on
channels {"1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
event-on-change-reading total_consumption,energy,power,counter
ignoreUnknown off
interval 120
pollingMode on
stateFormat power
unitReadings off
userReadings energy:total_consumption.* {ReadingsNum($name,"total_consumption",0)/1000},
counter:total_consumption.* {ReadingsNum($name,"total_consumption",0)/1000}
Dürfte dank dieser Direktive:
no warnings 'portable'; # Support for 64-bit ints required
eigentlich nicht mehr aufpoppen...... Hmmmmm....
Zitat von: willybauss am 12 Januar 2018, 08:29:01
Ich gehe nicht davon aus, dass der Stromverbrauch deines Hauses immer völlig konstant ist. Somit sind Schwankungen normal.
Ich dachte mir schon das das falsch rüberkommt ;D Ich meine eher das die Werte z.B. immer zwischen 2099,xx und 2100,xx springen.
Bei Volkszaehler und dem ElectricityCalculator Modul sind es immer 2100.00. Wenn meine Wärmepumpe läuft ist der Wert immer entweder 1800W oder 2100W (120sec Interval = 300W Abstufung, bei Werten die darüber liegen).
Ich habe mal paar Bilder angehängt, vielleicht wird es dann verständlicher.
Hallo zusammen,
ich habe heute das neueste Update (inkl. 47_OBIS.pm) eingespielt und festgestellt, dass meine beiden Stromzähler nicht mehr
ausgelesen werden. Musste die vorherige Version wieder einspielen, dann ging es wieder.
Ich habe zwei Pafal Zähler.
Gehört das hierher?
Gruß,
Blixman
Hallo
Kann man auch Stromzähler auslesen, die eine Anforderungssequenz benötigen?
Ich habe ein EMH ITZ
Dies lsst sich per Lesekopf mit 300bd 7E1 im Klartext auslesen.
Leider muss dies angefordert werden mit folgender Sequenz "/?!"
Kann das das Modul und wenn ja wie definiere ich es?
per Skript:
echo -e "\x2f\x3f\x21\x0d\x0a" > /dev/ttyUSB0
Folgendes Ausleseskript funktioniert, ich hätte es aber gern direkt aus FHEM :)
https://github.com/wiresio/lesekopf/blob/master/d0test.sh
Gib beim definieren des OBIS-Devices hinten noch als MeterType entweder VSM102 oder E110 oder E350USB an.
Diese drei Typen senden jeweils das Pull-Signal mit.
lg, Stefan
Gibt es eine einfache Möglichkeit, dem OBIS-Modul statistische Werte, z.B. den aufsummierten täglichen Energieverbrauch, zu entlocken? Das JSONMETER Modul beispielsweise liefert durch einfaches setzen des Attributs "doStatistics" eine ganze Latte von Messwerten:
statElectricityConsumed Hour: 0 Day: 11520 Month: 27986 Year: 227080 2018-02-04 21:51:02
statElectricityConsumedLast Hour: 0 Day: 7053 Month: 199094 Year: 2754133 2018-02-04 21:00:02
statElectricityConsumedToday 11520 2018-02-04 21:51:02
statElectricityPowerDay Min: 0 Avg: 524 Max: 5815 2018-02-04 22:00:02
statElectricityPowerDayLast Min: 0 Avg: 296 Max: 5478 2018-02-04 00:00:02
statElectricityPowerMonth Min: 0 Avg: 303 Max: 5815 2018-02-04 21:55:02
statElectricityPowerMonthLast Min: 0 Avg: 271 Max: 5926 2018-02-01 00:00:38
statElectricityPowerYear Min: 0 Avg: 275 Max: 5926 2018-02-04 21:51:02
statElectricityPowerYearLast Min: 0 Avg: 702 Max: 6066 2018-01-01 00:00:45
Ich lasse mir statElectricityConsumedToday alle paar Minuten ins Logfile schreiben und bekomme eine hübsche Kurve der Energieerzeugung meiner PV-Anlage im Tagesverlauf.
Wenn man dasselbe für die Energieverbräuche von Hausstrom und Wärmepumpe macht, hat man eine gute Basis, um die notwendige Größe eines Batteriepuffers für die PV-Anlage zu ermitteln.
Zur Not reicht aber auch der Tageswert kurz vor 24 Uhr, den ich mir dann per DOIF erzeugen kann.
ZitatZur Not reicht aber auch der Tageswert kurz vor 24 Uhr, den ich mir dann per DOIF erzeugen kann.
So mach ich das. ein tägliches at, welches ein Reading auf den aktuellen Stand setzt und ein userReading, welches permanent die Differenz = actual-lastday berechnet.
Grüße Markus
Wozu gibts ein eigenes Statistics-Modul?
2018-02-05 05:44:01 statEnergy_currentDay Min: 0.2439 Avg: 1.0589 Max: 4.1484
2018-02-04 23:59:56 statEnergy_currentDayLast Min: 0.2506 Avg: 1.6035 Max: 6.2240
2018-02-05 05:44:01 statEnergy_currentMonth Min: 0.1730 Avg: 1.0842 Max: 6.9674
2018-01-31 23:59:55 statEnergy_currentMonthLast Min: 0.0000 Avg: 0.8430 Max: 7.8800
2018-02-05 05:44:01 statEnergy_currentYear Min: 0.0000 Avg: 0.8720 Max: 7.8800
2017-12-31 23:59:56 statEnergy_currentYearLast Min: 0.1588 Avg: 0.9843 Max: 11.3212 (since: 2017-07-19_09:46:51 )
2018-02-05 05:44:01 statEnergy_total Hour: 0.54 Day: 6.17 Month: 110.51 Year: 729.99
2018-02-05 05:44:01 statEnergy_totalDay 6.17
2018-02-04 23:59:56 statEnergy_totalDayLast 38.34
2018-02-05 05:44:01 statEnergy_totalHour 0.54
2018-02-05 04:59:56 statEnergy_totalHourLast 0.93
2018-02-05 04:59:56 statEnergy_totalHourMaxLast 121361.24
2018-02-05 04:59:56 statEnergy_totalLast Hour: 0.93 Day: 38.34 Month: 619.48 Year: 4157.47 (since: 2017-07-20 )
2018-02-05 05:44:01 statEnergy_totalMonth 110.51
2018-01-31 23:59:55 statEnergy_totalMonthLast 619.48
2018-01-31 23:59:55 statEnergy_totalMonthMaxLast 121251.27
2018-02-05 05:44:01 statEnergy_totalYear 729.99
2017-12-31 23:59:56 statEnergy_totalYearLast 4157.47
lg, Stefan
Das hatte ich vergessen zu erwähnen: sobald ich das benutze steigt die Prozessorlast von 2 auf über 15%. Es frisst 5 mal so viel Rechenleistung wie meine ganze sonstige FHM-Konfiguration zusammen. Deshalb suche ich einen anderen Weg.
Ich nehme für die Aufgabe ElectricityCalculator
Dann läuft da aber was schief, wennst so hohe Prozessorlast hast......
Mein Statistics greift auch 20 oder 30 devices zu und mein FHEM dümpelt so bei 0.5 bis 7% dahin......
Vlt. event-on-change-reading??
Ich empfehle das neue Modul Freezemon(unter Codeschnipsel) einzusetzen. Dann kommt man den Modulen mit Prozessorhunger auf die Spur.. ;)
Grüße Markus
ElectricityCalculator und Freezemon sehen gut aus. Danke!
Hi zusammen,
ich hab nun auch das letzte Update eingespielt und seit dem werden meine "directions" nicht mehr aktualisiert. Jetzt habe ich gesehen, dass es ein neues Attribut dafür gibt. Allerdings wenn ich das einfach nur definiere (Wert = 1) stürzt mein FHEM ab bzw. lässt sich nicht mehr starten. Und wenn ich das Beispiel aus der Doku nutze ändert sich nichts. Hat noch jemand das Phänomen?
Screenshot dazu im Anhang.
MfG
Matthias
ZitatJetzt habe ich gesehen, dass es ein neues Attribut dafür gibt.
:o Von welchem neuen Attribut sprichst du? :o
Ist das "directions" Attribut nicht neu? :o Ich dachte das wäre jetzt erst mit dem letzten Update gekommen.
Ich habe auch seit einiger Zeit mal wieder ein update gemacht. Jetzt geht auch das Attribut "extChannels" nicht mehr. Alles es noch groß geschrieben wurde war noch alles gut.
Viele Grüße
Das directions-Attribut ist jetzt knappe 2 Jahre alt, siehe https://forum.fhem.de/index.php/topic,51948.msg437018/topicseen.html#msg437018 (https://forum.fhem.de/index.php/topic,51948.msg437018/topicseen.html#msg437018)
Auch am extChannels habe ich nicht wirklich was geändert :O
Oh sorry ::). Dann liegt es wohl woanders dran und ich habe mich heftigst verlesen.
Ich werde nächste Woche mal etwas debuggen und hier berichten.
Also in Version 15760 geht "ExtChannels" wie erwartet. In der neuen Version mit "extChannels" passiert nichts. Das heisst ich denke ob ich das Attribut setzte oder nicht immer das gleiche Ergebnis. Das Modul verhält sich wie ohne das Attribut.
Viele Grüße
Ich merke gerade, dass ich schon lange nicht mehr aktualisiert habe. Die vorherige Version mit der die Directions noch aktualisiert wurden war die hier:
$Id: 47_OBIS.pm [b]14235 [/b]2017-05-09 19:24:14Z Icinger $
Ich habe die jetzt erstmal wieder zurückgesichert. Ich hoffe ich habe diese Woche nochmal etwas Zeit weiter zu analysieren.
Eine Versionsnummer im Modul könnte nicht schaden ...
So konnte heute das Problem mit dem nicht funktionierenden Attribut "extChannels" beheben.
Kurzbeschreibung: ExtChannles -> extChannels Line 502
@tatu123: Danke, ist gefixt und eingecheckt...
Ich weiß, dass das wahrscheinlich nicht zusammenhängt, aber ich habe seit der Aktivierung des letzten Updates neue Readings mit dem Suffix ,,.255".
2018-02-15 10:55:10 total_consumption 965931.0197
2018-02-17 10:52:45 total_consumption.255 983223.7839
2018-02-15 10:55:10 total_consumption_Ch1 965721.0815
2018-02-17 10:52:45 total_consumption_Ch1.255 983013.8458
2018-02-15 10:55:10 total_consumption_Ch2 209.9381
2018-02-17 10:52:45 total_consumption_Ch2.255 209.9381
Leider funktionieren seitdem sämtliche Berechnungen nicht mehr, da sich das Basisreading geändert hat. Hast du eine Idee woher das kommt?
Ich würde denken du hast "extChannels" aktiviert.
Aktiviert hatte ich das seit der Einführung. Mit dem Fix vom 13.2. wurde das Attribut erstmals scharf geschaltet. Ich hatte damals gemeckert, dass man das Attribut extChannels und nicht ExtChannels nennen soll. Das habe ich nun davon. :-)
Ich habe es gelöscht und prompt wird ,,total_consumption" wieder aktualisiert. Danke für den Hinweis.
Ich wundere mich nur, warum mit ,,extChannels = on" das primäre Reading ,,total_consumption" nicht aktualisiert wird und plötzlich ,,total_consumption.255" erscheint.
Hallo, ich habe ganz frisch mit fhem angefangen.
Ziel ist es die aktuellen PV Überschüsse in der Küche auf einem Display anzuzeigen, und möglichst automatisiert in warmes Wasser und eine warme Wohnung zu verwandeln.
Der erste Schritt ist mit dem Raspberry pi 3 (Raspian) und einen EMLOG IR Schreib/ Lesekopf USB von Weidmann Elektronik die Werte des Zweirichtungsstromzählers Elster AS1440 auszulesen.
Der Zähler ist mit einer Initialisierungssequenz anzusprechen bevor er Daten sendet. Diese beinhaltet in meinem Fall die 8 stellige Identifikationsnummer des Zählers:
/?<Identifikationsnummer>! <CR/LF>
(Führende Nullen der Identifikationsnummer können ignoriert werden). Siehe: https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440 (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440)
Wenn ich wie in diesem pdf vom Optokopf-Hersteller beschrieben vorgehe, kann ich die Zählerdaten als lesbaren Text (OBIS Protokoll) im LXTerminal sehen:
https://shop.weidmann-elektronik.de/media/files_public/9d73b590bf0752a5beff32d229d4497d/HowToRaspberryPi.pdf (https://shop.weidmann-elektronik.de/media/files_public/9d73b590bf0752a5beff32d229d4497d/HowToRaspberryPi.pdf)
Alle Werte im Terminal stimmen mit den Daten vom Display des Stromzählers überein.
Das 47_OBIS.pm Modul habe ich wie folgt definiert:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06GH3P-if00-port0@300,7,E,1 AS1440
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06GH3P-if00-port0@300,7,E,1
MeterType AS1440
NAME MVVZaehler
NR 25
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2018-04-02 11:17:24 Version ?!
2018-04-02 21:36:38 state opened
helper:
EoM -1
SPEED 0
SPEED2 0
TRIGGERTIME 1522702934.82179
DEVICES:
/2!
10
000
Attributes:
interval 10
pollingMode on
verbose 5
Es kommen keinerlei Daten vom Zähler in den readings / dem Logfile an, wahrscheinlich weil die Identifikationsnummer des Zählers in der Anforderungssequenz fehlt.
Ich habe versucht die Änderung in ein edit file auf der Basis von 47_OBIS.pm einzubauen, finde jedoch nicht die neuralgische Stelle im Code und mache das alles hier sowieso nur auf Cargo-Kult Niveau. Hat Icinger / Stefan eine Möglichkeit das Modul anzupassen? Oder brauche ich nur einen guten Tipp von euch?
Das Logfile zeigt:
2018.04.01 23:57:30 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-01 23:57:40
2018.04.01 23:57:40 5: SW: 2f32210d0a
2018.04.01 23:57:40 4: Wrote /2!
Übrigens hat der Zähler nur auf /?! reagiert und nicht auf /2! wie es bei 'Meter Type: AS1440' im OBIS Modul hinterlegt ist. Das ist zwar für andere User egal weil die einfach einen anderen Meter Type wählen können, aber wenn die Möglichkeit zur Eingabe der Identifiktionsnummer nur beim 'Meter Type AS1440' mit der festen Anforderungssequenz /2! eingebaut werden würde, hätte ich wieder ein Problem...
Ich habe nun doch über ein edit file das OBIS Modul in Zeile 152 angepasst und der Zähler wirft wenn ich ihn mit
/?01234567!
statt mit
/2!
anspreche Daten aus. (Hierbei ist 1234567 stellvertetend für meine 8 Stellige Identifikationsnummer ohne führende 0 zu verstehen) Das sehe ich daran dass die grüne Kontroll LED auf der Rückseite des IR Sensors nun blinkt und zwar in der gleichen Weise wie sie auch blinkt wenn ich mit cat die Daten im LXTerminal empfange. Ausserdem kann ich die IR LED des Stromzählers wenn ich den IR Sensor während der Übertragung herunternehme auch mit dem bloßen Auge schwach leuchten / blinken sehen. Auf Hardwareebene scheint jetzt also alles in Butter.
Das hatte vorher zunächst nicht funktioniert und im logfile stand trotz des geänderten OBIS codes immer noch der Aufruf /2! aber nachdem ich meine Device einmal gelöscht und neu definiert hatte ging es dann doch.
Nur: Immer noch keine sinnvollen readings. Ich bekomme
Version: �1���@�zg�.u�Tg�n� 2018-04-07 22:56:25
state: opened 2018-04-08 10:25:26
und das wars.
Auch das logfile zeigt mit verbose 5 nur
2018.04.09 20:21:09 5: OBIS (MVVZaehler) - Msg-Parse: 2.8.85.k22)
2018.04.09 20:21:30 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:21:30 4: Wrote /?1234567!
2018.04.09 20:21:30 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-09 20:22:02
2018.04.09 20:22:02 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:22:02 4: Wrote /?1234567!
2018.04.09 20:22:02 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-09 20:22:34
2018.04.09 20:22:34 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:22:34 4: Wrote /?1234567!
Die Zählerdaten werden von fhem nicht richtig angenommen und ich habe aktuell keine Idee hierzu.
Schon komisch.....Deinem Log-Auszug zufolge kommen nähmlich gar keine Daten im Obis-Modul an.....
Das mit der Init-Sequenz kann ich evtl. über ein zusätzliches Attribut lösen, muss ich mir mal ansehen.
lg, Stefan
Hallo Belit,
der Zähler ist demnach passwortgesichert. Der richtige Initialisierungsstring müsste nun
/?<Identifikationsnummer oder Passwort>!
sein
Da Du bereits mit LXTerminal Daten empängst, wie lange sendet der Zähler ?
Vielleicht klappt auch
/2<Identifikationsnummer oder Passwort>!
Dann vermute ich, kommen nur die Mommentanwerte
Es wäre schön, wenn man den Initialisierungsstring als Parameter übergeben könnte. Dann müsste man nicht die Liste der "Zählertypen" erweitern
Hallo,
erst einmal ganz herzlichen Dank für das module. Finde ich echt klasse.
Ich habe jedoch ein kleines Problem. Ich verwende unter Linux die IR-Leseköpfe von Volkszähler.
Prinzipiell holt er die Daten auch sauber aber jedoch bekomme ich in unregelmäßigen Abständen ein DISCONNECT
Siehe bild im Anhang.
defmod KG.sr.VZ.Hausstrom OBIS /dev/lesekopfHausStrom@@9600,7,E,1 SML
attr KG.sr.VZ.Hausstrom DbLogExclude .*
attr KG.sr.VZ.Hausstrom DbLogInclude state,total_consumption:300,total_consumption_Ch1:300,total_consumption_Ch2:300
attr KG.sr.VZ.Hausstrom event-on-change-reading .*
attr KG.sr.VZ.Hausstrom pollingMode off
attr KG.sr.VZ.Hausstrom room 3.1_Strom
setstate KG.sr.VZ.Hausstrom opened
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 1.0.0.0.9.255 06-45-4D-48-01-07-19-81-C3-57
setstate KG.sr.VZ.Hausstrom 2018-04-23 16:25:07 122.119.7.129.129.255 -1e+30
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 129.129.199.130.3.255 EMH
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 129.129.199.130.5.255 05AE-4006-5B0E-15BE-5126-45EA-652F-9A67-C313-185E-ABB6-F7AF-76AB-89AC-9539-779B-6A44-6EB9-D513-565E-858B-7475-ADED-6EF6-01
setstate KG.sr.VZ.Hausstrom 2018-04-25 13:57:30 Version EMH\06454D4801071981C357
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 power 379.6
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:50 state opened
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_consumption 16109800.8
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_consumption_Ch1 2625.1
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_consumption_Ch2 16107175.7
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_feed 545.2
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_feed_Ch1 545.2
setstate KG.sr.VZ.Hausstrom 2018-04-26 15:30:51 total_feed_Ch2 0
Ich habe eigentlich sonst keine Applikation die auf den USB zugreift.
Über jeden Hilfe dankbar.
defmod KG.sr.VZ.Hausstrom OBIS /dev/lesekopfHausStrom@@9600,7,E,1 SML
Wieso zwei @-Zeichen?
Das ist das einzig auffällige an deinem define.
Sehe sonst nichts, was Probleme machen könnte.
lg, Stefan
hab ich aus der commandref
Beispiel:
define myPowerMeter OBIS /dev/ttyPlugwise@@9600,7,E,1 VSM102
Hallo, danke für die Tipps, ich habe nun das zweite Problem auch beseitigen können, alle Readings kommen jetzt wie erwartet.
Weil fhem für mich neu ist habe ich nicht bemerkt, dass vermutlich durch autocreate ganz zu Beginn ein device angelegt wurde das den USB0 port blockiert hat. Man muss halt erst überall auf alles einmal geklickt haben und einiges gelesen haben bevor man sowas erkennen kann. Habe spontan einen Freudentanz aufgeführt als ich diese device zugegebenermaßen recht spät mal geöffnet und als nicht-fhem-grund-funktion identifiziert hatte.
Ich hab READINGS!!! fhem fängt an zu funktionieren, Juhu!
Hallo,
habe gestern meinen Zweirichtungszähler vom EVU bekommen (EMH, Typ eHZ-PW8E) und mit dem IR-Schreiblesekopf verbunden. Das Modul OBIS definiert.
Internals:
CFGFN
DEF /dev/ttyUSB1 SML
DeviceName /dev/ttyUSB1
FD 43
MeterType SML
NAME ZRZ
NR 7758
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2018-05-18 10:07:34 1.0.96.50.1.255 EMH
2018-05-18 10:06:09 state opened
2018-05-18 10:07:34 total_consumption 3000
2018-05-18 10:07:34 total_feed 12000
helper:
BUFFER
EoM 0
SPEED 5
TRIGGERTIME 1526630769.27109
Channels:
DEVICES:
-1
directions:
Attributes:
room Testraum
Leider erhalte ich in den Readings nur Werte von ganzen KWh, das ist scheinbar der Zählerstand-Bezug-Total, bzw Zählerstand-Lieferung-Total. Ich benötige aber eine höhere Auflösung, also andere Register. Der Zähler hat via SML eine Auflösung von 0,1 Wh.
Wie kann ich die anderen Register des Zählers anzeigen lassen?
VG
Alex
ZitatLeider erhalte ich in den Readings nur Werte von ganzen KWh,
Ansich sollten alle Daten, die vom Zähler kommen, auch in Readings umgewandelt werden.
Kannst du mir mal nen kompletten Datensatz mit Verbose 5 schicken, bitte? Dann schau ich mir das an.
lg, Stefan
Hallo,
anbei das Log mit verbose 5:
pi@raspberrypi:/opt/fhem/log $ tail -f fhem-2018-05.log
2018.05.22 15:24:19.795 3: PV_WR - Send request 00020051003F2600FF3F2600 to 192.168.3.31 on port 9522
2018.05.22 15:24:19.815 3: PV_WR - Send request 00020051005A2900FF5A2900 to 192.168.3.31 on port 9522
2018.05.22 15:24:19.833 3: PV_WR - Format of inverter response does not fit.
2018.05.22 15:24:50.480 3: PV_WR - Send request 00020058001E8200FF208200 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.490 3: PV_WR - Send request 0002005400012600FF222600 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.510 3: PV_WR - Send request 00028053001E2500FF1E2500 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.530 3: PV_WR - Send request 0002005100404600FF424600 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.550 3: PV_WR - Send request 00020051003F2600FF3F2600 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.570 3: PV_WR - Send request 00020051005A2900FF5A2900 to 192.168.3.31 on port 9522
2018.05.22 15:24:50.588 3: PV_WR - Format of inverter response does not fit.
2018.05.22 15:25:20.503 3: PV_WR - Send request 00020058001E8200FF208200 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.521 3: PV_WR - Send request 0002005400012600FF222600 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.540 3: PV_WR - Send request 00028053001E2500FF1E2500 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.562 3: PV_WR - Send request 0002005100404600FF424600 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.580 3: PV_WR - Send request 00020051003F2600FF3F2600 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.600 3: PV_WR - Send request 00020051005A2900FF5A2900 to 192.168.3.31 on port 9522
2018.05.22 15:25:20.620 3: PV_WR - Format of inverter response does not fit.
2018.05.22 15:25:37.174 5: SW:
2018.05.22 15:25:37.176 4: Wrote
2018.05.22 15:25:37.178 5: OBIS (ZRZ) - Internal timer set to 2018-05-22 15:25:57
2018.05.22 15:25:38.345 5: SML-Parse 1B1B1B1B0101010176050013ED576200620072630101760107FFFFFFFFFFFF050006A4730B0A01454D48000072A7317262016406AB9A62016383000076050013ED5862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A731070100620AFFFF7262016406AB9A7477070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A7310177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.347 5: OBIS: Full message-> 1B1B1B1B0101010176050013ED576200620072630101760107FFFFFFFFFFFF050006A4730B0A01454D48000072A7317262016406AB9A62016383000076050013ED5862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A731070100620AFFFF7262016406AB9A7477070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A7310177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.348 5: OBIS: Telegram=1B1B1B1B0101010176050013ED576200620072630101760107FFFFFFFFFFFF050006A4730B0A01454D48000072A7317262016406AB9A62016383000076050013ED5862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A731070100620AFFFF7262016406AB9A7477070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A7310177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.349 5: OBIS: Telegram=77070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A7310177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.351 5: OBIS: Telegram=0177070100600100FF010101010B0A01454D48000072A7310177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.352 5: OBIS: Telegram=0177070100010800FF641C59047262016406AB9A621E520362100177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.353 5: OBIS: Telegram=0177070100020800FF017262016406AB9A621E5203629301010163FDEA0076050013ED5962006200726302017101639841001B1B1B1B1A001042
2018.05.22 15:25:38.354 4: MSG IS:
/
1-0:96.50.1*255(EMH)
1-0:96.1.0*255(
EMHr1)
1-0:1.8.0*255(16000*Wh)
1-0:2.8.0*255(147000*Wh)
!
2018.05.22 15:25:38.355 5: OBIS (ZRZ) - Msg-Parse: /
2018.05.22 15:25:38.356 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*255(EMH)
2018.05.22 15:25:38.358 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(
EMHr1)
2018.05.22 15:25:38.358 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(16000*Wh)
2018.05.22 15:25:38.359 5: Msg 1-0:1.8.0*255(16000*Wh) is of type Counter
2018.05.22 15:25:38.360 4: Set total_consumption to 16000
2018.05.22 15:25:38.361 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(147000*Wh)
2018.05.22 15:25:38.362 5: Msg 1-0:2.8.0*255(147000*Wh) is of type Counter
2018.05.22 15:25:38.363 5: OBIS (ZRZ) - Msg-Parse: !
VG
Alex
Tja, dein Telegram vom Zähler beinhaltet leider nicht mehr als diese 4 Datensätze....
Dazuerfinden kann ich leider nichts :)
Danke erstmal, bin gerade mit dem EVU in Kontakt, damit der Zähler mehr auspuckt.
Hallo,
also der EHZ von EMH bringt nach Zählertausch mit einem vorkonfigurierten jetzt die gewünschten Obis codes.
Jetzt hab ich wieder mal das logfile durchsucht und Warnings vom 47_OBIS Modul gefunden, mir denen ich nichts anfangen kann.
Die Fehler sind sporadisch mit folgendem Kontext (LogLevel 1):
2018.07.05 16:01:31.515 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25125.
2018.07.05 16:01:31.516 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25125.
2018.07.05 16:22:51.537 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN20> line 447.
2018.07.05 16:22:51.539 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN20> line 447.
2018.07.05 16:30:28.535 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN20> line 456.
2018.07.05 16:30:28.536 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN20> line 456.
2018.07.05 16:34:37.538 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25145.
2018.07.05 16:34:37.540 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25145.
2018.07.05 20:44:45.602 1: PERL WARNING: Argument "on" isn't numeric in subtraction (-) at (eval 5972149) line 4.
2018.07.05 20:44:45.836 1: PERL WARNING: Argument "on" isn't numeric in subtraction (-) at (eval 5972254) line 4.
2018.07.05 21:56:31.813 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25187.
2018.07.05 21:56:31.814 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25187.
2018.07.06 07:43:03.973 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN20> line 462.
2018.07.06 07:43:03.974 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN20> line 462.
2018.07.06 07:43:19.233 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777, <GEN30> line 795.
2018.07.06 07:43:19.234 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN30> line 795.
2018.07.06 07:43:19.235 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342, <GEN30> line 795.
2018.07.06 07:43:19.236 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349, <GEN30> line 795.
2018.07.06 07:43:19.236 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350, <GEN30> line 795.
2018.07.06 07:43:19.237 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351, <GEN30> line 795.
2018.07.06 07:43:19.237 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330, <GEN30> line 795.
2018.07.06 08:20:26.269 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25429.
2018.07.06 08:20:26.271 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25429.
2018.07.06 14:42:09.560 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25565.
2018.07.06 14:42:09.571 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25565.
2018.07.06 15:02:46.570 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25617.
2018.07.06 15:02:46.571 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25617.
2018.07.06 16:40:20.662 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25736.
2018.07.06 16:40:20.663 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25736.
2018.07.06 16:46:54.660 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 25758.
2018.07.06 16:46:54.662 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 25758.
das Modul in Def.:
Internals:
CFGFN
DEF /dev/ttyUSB1 SML
DeviceName /dev/ttyUSB1
FD 36
MeterType SML
NAME ZRZ
NR 41903
PARTIAL
STATE opened
TYPE OBIS
OLDREADINGS:
READINGS:
2018-07-02 09:13:43 0.0.0.0.27.255 0
2018-06-15 18:23:13 0.118.5.0.17.255 0
2018-06-17 10:40:49 0.118.5.0.23.255 0
2018-07-07 22:14:43 1.0.96.5.0.255 1835268
2018-07-07 22:14:43 Hersteller EMH
2018-07-07 22:14:43 Power.av 457.160
2018-07-07 22:14:43 Powerconsumption 471
2018-07-07 22:14:43 power 471
2018-07-07 22:14:43 power_L1 67
2018-07-07 22:14:43 power_L2 171
2018-07-07 22:14:43 power_L3 232
2018-06-15 15:29:09 state opened
2018-07-07 22:14:43 total_consumption 55199.8
2018-07-07 22:14:43 total_feed 468635.3
helper:
BUFFER
EoM 1
SPEED 5
TRIGGERTIME 1530952677.44334
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
1.0.96.50.1.255 Hersteller
DEVICES:
10
directions:
history:
ARRAY(0x45f2b88)
ARRAY(0x45f1c50)
ARRAY(0x41b8f88)
ARRAY(0x16cde30)
ARRAY(0x3ed8378)
ARRAY(0x46635d8)
ARRAY(0x4061100)
ARRAY(0x435c9e8)
ARRAY(0x40b7100)
ARRAY(0x41b43f8)
ARRAY(0x40625a8)
ARRAY(0x41bb380)
ARRAY(0x3a9f9a8)
ARRAY(0x4055de0)
ARRAY(0x41b9ba8)
ARRAY(0x372e030)
ARRAY(0x3d491f0)
ARRAY(0x373a3e8)
ARRAY(0x43de8b0)
ARRAY(0x4658750)
ARRAY(0x4693548)
ARRAY(0x411c8f8)
ARRAY(0x443f788)
ARRAY(0x42240d8)
ARRAY(0x4436258)
Attributes:
channels {"1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
group Verbrauchszähler
interval 10
room Keller,PV_Anlage
userReadings Power.av {movingAverage("ZRZ","power",100)},
Powerconsumption {ReadingsVal("PV_WR","SPOT_PACTOT",0) + ReadingsVal("ZRZ","power",0)}
Kann da mal nachgesehen werden, wieso die Warnings kommen (sind doch einige).
Danke!
VG
Alex
Guten Morgen,
das sieht mir nach wie vor aus, als ob unvollständige Daten reinkommen.
Könntest du mal ein V5-Log machen, bitte?
Hallo Ici,
ich habe mal einen Logauszug mit V=5. Die Warning tritt bei 10:31:59.974 und ...976 auf (rot markiert).
Kannst ja mal schauen, vielleicht fällt Dir was auf.
Vieln Dank erstmal.
VG
Alex
2018.07.12 10:31:48.692 5: SW:
2018.07.12 10:31:48.695 4: Wrote
2018.07.12 10:31:48.696 5: OBIS (ZRZ) - Internal timer set to 2018-07-12 10:31:58
2018.07.12 10:31:49.964 5: SML-Parse 1B1B1B1B010101017605005E82BF6200620072630101760107FFFFFFFFFFFF05001F80EB0B0A01454D48000072A72E726201642239F962016370A6007605005E82C062006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF726201642239F97977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.967 5: OBIS: Full message-> 1B1B1B1B010101017605005E82BF6200620072630101760107FFFFFFFFFFFF05001F80EB0B0A01454D48000072A72E726201642239F962016370A6007605005E82C062006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF726201642239F97977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.968 5: OBIS: Telegram=1B1B1B1B010101017605005E82BF6200620072630101760107FFFFFFFFFFFF05001F80EB0B0A01454D48000072A72E726201642239F962016370A6007605005E82C062006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF726201642239F97977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.968 5: OBIS: Telegram=77070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.970 5: OBIS: Telegram=0177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.971 5: OBIS: Telegram=0177070100010800FF641C5104726201642239F9621E52FF640A0A5B0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.972 5: OBIS: Telegram=0177070100020800FF01726201642239F9621E52FF6453A1790177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.973 5: OBIS: Telegram=0177070100100700FF0101621B520053034A0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.973 5: OBIS: Telegram=0177070100240700FF0101621B520053FF1E0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.974 5: OBIS: Telegram=0177070100380700FF0101621B520053061301770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.975 5: OBIS: Telegram=01770701004C0700FF0101621B520053FE170177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.976 5: OBIS: Telegram=0177070100600500FF01010101641C510401010163378E007605005E82C16200620072630201710163E8B7000000001B1B1B1B1A033331
2018.07.12 10:31:49.976 4: MSG IS:
/
1-0:96.50.1*255(EMH)
1-0:96.1.0*255(
EMHr.)
1-0:1.8.0*255(65801.1*Wh)
1-0:2.8.0*255(548082.5*Wh)
1-0:16.7.0*255(842*W)
1-0:36.7.0*255(-226*W)
1-0:56.7.0*255(1555*W)
1-0:76.7.0*255(-489*W)
1-0:96.5.0*255(1855748)
!
2018.07.12 10:31:49.977 5: OBIS (ZRZ) - Msg-Parse: /
2018.07.12 10:31:49.977 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*255(EMH)
2018.07.12 10:31:49.978 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(
EMHr.)
2018.07.12 10:31:49.978 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(65801.1*Wh)
2018.07.12 10:31:49.979 5: Msg 1-0:1.8.0*255(65801.1*Wh) is of type Counter
2018.07.12 10:31:49.980 4: Set total_consumption to 65801.1
2018.07.12 10:31:49.980 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(548082.5*Wh)
2018.07.12 10:31:49.981 5: Msg 1-0:2.8.0*255(548082.5*Wh) is of type Counter
2018.07.12 10:31:49.982 5: OBIS (ZRZ) - Msg-Parse: 1-0:16.7.0*255(842*W)
2018.07.12 10:31:49.983 5: Msg 1-0:16.7.0*255(842*W) is of type Channels
2018.07.12 10:31:49.983 5: OBIS (ZRZ) - Msg-Parse: 1-0:36.7.0*255(-226*W)
2018.07.12 10:31:49.984 5: OBIS (ZRZ) - Msg-Parse: 1-0:56.7.0*255(1555*W)
2018.07.12 10:31:49.985 5: OBIS (ZRZ) - Msg-Parse: 1-0:76.7.0*255(-489*W)
2018.07.12 10:31:49.986 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1855748)
2018.07.12 10:31:49.987 5: OBIS (ZRZ) - Msg-Parse: !
2018.07.12 10:31:51.033 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 7480116) line 1, <GEN103> line 36481.
2018.07.12 10:31:51.034 3: eval: di_Autobeschattung_AZ: warning in condition c01
2018.07.12 10:31:58.703 5: SW:
2018.07.12 10:31:58.705 4: Wrote
2018.07.12 10:31:58.706 5: OBIS (ZRZ) - Internal timer set to 2018-07-12 10:32:08
2018.07.12 10:31:59.967 5: SML-Parse 1B1B1B1B010101017605005E82DD6200620072630101760107FFFFFFFFFFFF05001F80F50B0A01454D48000072A72E72620164223A036201636775007605005E82DE62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A037977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A03621E52FF640A0A770177070100020800FF0172620164223A03621E52FF6453A1790177070100100700FF0101621B520053041A0177070100240700FF0101621B520053FEFD0177070100380700FF0101621B520053070701770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.973 5: OBIS: Full message-> 1B1B1B1B010101017605005E82DD6200620072630101760107FFFFFFFFFFFF05001F80F50B0A01454D48000072A72E72620164223A036201636775007605005E82DE62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A037977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A03621E52FF640A0A770177070100020800FF0172620164223A03621E52FF6453A1790177070100100700FF0101621B520053041A0177070100240700FF0101621B520053FEFD0177070100380700FF0101621B520053070701770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
[color=red]2018.07.12 10:31:59.974 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787, <GEN103> line 36481.
2018.07.12 10:31:59.976 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793, <GEN103> line 36481.[/color]
2018.07.12 10:31:59.976 5: OBIS: Telegram=1B1B1B1B010101017605005E82DD6200620072630101760107FFFFFFFFFFFF05001F80F50B0A01454D48000072A72E72620164223A036201636775007605005E82DE62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A037977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A03621E52FF640A0A770177070100020800FF0172620164223A03621E52FF6453A1790177070100100700FF0101621B520053041A0177070100240700FF0101621B520053FEFD0177070100380700FF0101621B520053070701770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.977 5: OBIS: Telegram=0177070100240700FF0101621B520053FEFD0177070100380700FF0101621B520053070701770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.979 5: OBIS: Telegram=0177070100380700FF0101621B520053070701770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.979 5: OBIS: Telegram=01770701004C0700FF0101621B520053FE150177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.980 5: OBIS: Telegram=0177070100600500FF01010101641C510401010163B851007605005E82DF6200620072630201710163708F000000001B1B1B1B1A036CFD
2018.07.12 10:31:59.981 4: MSG IS:
/
1-0:16.7.0*255(1050*W)
1-0:36.7.0*255(-259*W)
1-0:56.7.0*255(1799*W)
1-0:76.7.0*255(-491*W)
1-0:96.5.0*255(1855748)
!
2018.07.12 10:31:59.982 5: OBIS (ZRZ) - Msg-Parse: /
2018.07.12 10:31:59.982 5: OBIS (ZRZ) - Msg-Parse: 1-0:16.7.0*255(1050*W)
2018.07.12 10:31:59.984 5: Msg 1-0:16.7.0*255(1050*W) is of type Channels
2018.07.12 10:31:59.985 5: OBIS (ZRZ) - Msg-Parse: 1-0:36.7.0*255(-259*W)
2018.07.12 10:31:59.987 5: OBIS (ZRZ) - Msg-Parse: 1-0:56.7.0*255(1799*W)
2018.07.12 10:31:59.988 5: OBIS (ZRZ) - Msg-Parse: 1-0:76.7.0*255(-491*W)
2018.07.12 10:31:59.989 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1855748)
2018.07.12 10:31:59.990 5: OBIS (ZRZ) - Msg-Parse: !
2018.07.12 10:32:09.444 5: SW:
2018.07.12 10:32:09.448 4: Wrote
2018.07.12 10:32:09.450 5: OBIS (ZRZ) - Internal timer set to 2018-07-12 10:32:19
2018.07.12 10:32:09.996 5: SML-Parse 1B1B1B1B010101017605005E82FB6200620072630101760107FFFFFFFFFFFF05001F80FF0B0A01454D48000072A72E72620164223A0D6201630140007605005E82FC62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A0D7977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.000 5: OBIS: Full message-> 1B1B1B1B010101017605005E82FB6200620072630101760107FFFFFFFFFFFF05001F80FF0B0A01454D48000072A72E72620164223A0D6201630140007605005E82FC62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A0D7977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.001 5: OBIS: Telegram=1B1B1B1B010101017605005E82FB6200620072630101760107FFFFFFFFFFFF05001F80FF0B0A01454D48000072A72E72620164223A0D6201630140007605005E82FC62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF72620164223A0D7977070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.002 5: OBIS: Telegram=77070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.003 5: OBIS: Telegram=0177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.004 5: OBIS: Telegram=0177070100010800FF641C510472620164223A0D621E52FF640A0A930177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.005 5: OBIS: Telegram=0177070100020800FF0172620164223A0D621E52FF6453A1790177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.006 5: OBIS: Telegram=0177070100100700FF0101621B52005303EC0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.007 5: OBIS: Telegram=0177070100240700FF0101621B520053FEE00177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.008 5: OBIS: Telegram=0177070100380700FF0101621B52005306F801770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.008 5: OBIS: Telegram=01770701004C0700FF0101621B520053FE130177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.009 5: OBIS: Telegram=0177070100600500FF01010101641C5104010101638EE8007605005E82FD6200620072630201710163D8C6000000001B1B1B1B1A034530
2018.07.12 10:32:10.010 4: MSG IS:
/
1-0:96.50.1*255(EMH)
1-0:96.1.0*255(
EMHr.)
1-0:1.8.0*255(65806.7*Wh)
1-0:2.8.0*255(548082.5*Wh)
1-0:16.7.0*255(1004*W)
1-0:36.7.0*255(-288*W)
1-0:56.7.0*255(1784*W)
1-0:76.7.0*255(-493*W)
1-0:96.5.0*255(1855748)
!
Hi, kann mir vielleicht jemand von euch helfen?
Was bedeuten die ersten 3 Werte in den Readings?
Ich hätte gerne den Momentan Verbrauch kann man den daraus herauslesen ?
Wäre Super wenn ihr helfen könntet.
Gruß
Rimjim
Guten Morgen,
0.0.96.1 -> Seriennummer
1.0.0.0 -> Eigentumsnummer
1.0.96.5 -> Status, hexadezimal
mehr steht da leider nicht drinnen.
Je nachdem, wie oft total_consumption aktualisiert wird, könntest du mit einem UserReading arbeiten, welches die Diff zwischen letztem und aktuellem Wert berechnet.
lg, Stefan
Danke für die schnelle Antwort.
Könntest du mir bitte bei dem UserReading helfen?
Bin da leider noch nicht so weit.
Gruß
Rimjim
Aus der commandref:
Zitatdifference: das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert gesetzt.
differential: das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert, geteilt durch die Sekunden zw. der aktuellen Zeit und der letzten Auswertung, sekundengenau. Kein Wert wird berechnet, falls der Unterschied unter eine Sekunde liegt.
Also zB:
attr Heizung_Stromzaehler userReadings Verbrauch:total_consumption_Ch1 differential {ReadingsVal("Heizung_Stromzaehler","total_consumption_Ch1",0)}
ACHTUNG: Ungetestet, da ich noch nie mit dem diff-Modifier gearbeitet habe.
Schau Dir in der CommandRef zu UserReadings die Option "differential" an. Damit geht's, musst hat ein passendes Ausleseintervall definieren. Bei mir ist das so ungefähr:
attr Hausstrom_Zaehler userReadings P_Bezug_temp:total_consumption_Ch1.* differential { ReadingsVal("Hausstrom_Zaehler","total_consumption_Ch1",0)*3600000 }, \
P_Bezug_Watt:P_Bezug_temp.* { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) }, \
...
Die erste Zeile (P_Bezug_temp) berechnet die Leistung, gibt das Ergebnis aber mit zig Nachkommastellen aus. Deshalb wird in der zweiten Zeile (P_Bezug_Watt) gerundet. Nur der gerundete Wert kommt ins Logfile.
Guten Abend,
danke für die Hilfe !!!
ich habe mich noch ein wenig durchgekämpft, letztendlich hat es wie folgt funktioniert.
Verbrauch differential {ReadingsVal("Zaehler_Heizung","total_consumption_Ch1",0)}
Leider hab ich das mit dem Runden jedoch nicht hinbekommen, habe alles mögliche ausprobiert
Gruß
Rimjim
Hallo liebe Leute,
ich Habe 2 Siemens TD-3511 Zähler welche in Österreich verschlüsselt sind, und würde sie auch gerne mit diesem tollen ObisModul auslesen können.
ich habe Versucht im ObisModul den Zähler E110 abzuwandeln für meinen:
my %devs= (
# Name, Init-String, interval, 2ndInit
"none" => ["", -1, ""],
"Unknown" => ["", -1, ""],
"SML" => ["", -1, ""],
"Ext" => ["", -1, ""],
"Standard" => ["", -1, ""],
"VSM102" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E350USB" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"AS1440" => ["/2!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
"E110" => ["/?3F322211F1E873A66382248779777822!CRLF".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)]
);
jedoch bekomme ich folgende Fehlermeldungen :
2018.08.09 13:34:32 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 98.
2018.08.09 13:34:32 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 98.
2018.08.09 13:34:33 3: Opening myPowerMeter device /dev/ttyUSB0
2018.08.09 13:34:33 3: Setting myPowerMeter serial parameters to 9600,8,N,1
2018.08.09 13:34:33 3: Init done
2018.08.09 13:34:33 3: myPowerMeter device opened
Obwohl ich dem Zähler mit "define myPowerMeter OBIS /dev/ttyUSB0@9600,7,E,1 E110" definiere.
Die Zeichenkette in der Init zwischen ? und ! ist so ähnlich wie mein Schlüssel (bei mir steht natürlich der richtige drinnen, aber die Länge stimmt) und CRLF braucht mein Zähler laut Datenblatt als Abschlusszeichen (ohne CRLF bekomme ich die selben Fehler).
ich schätze mein Passwort ist zu lang und muss seperat übergeben werden kann mir da bitte jemand helfen?
ich liebe FHEM quasi aber ich habe den Volkszähler am selben Gerät laufen und der schmiert leider immer wieder mal ab. (ich habe den vzlogger natürlich beendet)
Danke
lg Johannes
Weiß zufällig jemand, ob man mit OBIS bei einem EasyMeter Zweirichtungszähler auch beide Richtungen auslesen kann?
Liegt im JSON auch die erzeugte Energie vor?
@Watt:
2018.08.09 13:34:32 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 98.
2018.08.09 13:34:32 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 98.
2018.08.09 13:34:33 3: Opening myPowerMeter device /dev/ttyUSB0
2018.08.09 13:34:33 3: Setting myPowerMeter serial parameters to 9600,8,N,1
2018.08.09 13:34:33 3: Init done
2018.08.09 13:34:33 3: myPowerMeter device opened
Ich seh da keine Fehlermeldung, sondern nur ein Warning.
Das kommt manchmal vor, wenn Perl das Modul grade neu lädt, aber in diesem moment schon Daten reinkommen.
Keine Bange ab dem nächsten Interval sollte es problemlos laufen.
@FunkOdyssey:
Wenn das Easymeter die Daten sendet, wertet das Modul diese auch aus.
lg, Stefan
@Watt
Ich habe auch einen TD3511. Mit dem obis-modul habe ich es mal versucht und nicht zum Laufen bekommen, da der TD3511 zu erst mit 300 baud und einer Zeichenfolge beginnt und dann kann man auf 9600 -19200 baud umschalten, mit der nächsten Zeichenfolge. Ich habe mir dafür ein extra perlmodul gebaut was die Daten ausliest und in eine MySQL db schreibt auf die ich über fhem zugreife.
Pejonp
Hallo,
leider funktioniert es trozdem nicht und ich vermute immer noch Stark dass es an dem Passwort liegt.
kann mir bitte Jemand sagen wo die Zählerdaten entschlüsselt vorliegen sollten (ich schätze in OBIS_Parse) und wie ich mir $hash oder $buf ausprinten kann um zu sehen was vom Zähler ankommt?
Ich schätze es sind globale Strukturen aber ohne zu wissen wie die aussehen kann ich sie leider nicht ausgeben.
oder hat jemand ne andere Idee wie ich da debuggen könnte und wo sollten die Daten normalerweise ankommen?
ich hab hald folgendes Filelog eingerichtet, aber da wird nur das "Version: SAT63511D01546005085" hineingeschrieben.
define VZ.Log FileLog ./log/vz-%Y-%m.log (myPowerMeter.*)
@Pejonp
Ja ich habe dein DT3511 Modul auch schon probiert aber wie gesagt ich muss ein Passwort übergeben und ich weiß nicht an welcher stelle ich die Übergabe machen muss (ausserdem bevorzuge ich Logfiles vor einer Datenbank).
Danke schon mal sry wenn ich nerve aber ich will unbedingt meine Zähler endlich auch nur mit FHEM auslesen können, und ich bin leider gerade nicht mehr so am ball mim progen.
Vielen Dank
lg Watt
Zitat von: Watt am 09 August 2018, 14:27:03
Hallo liebe Leute,
...
ich habe Versucht im ObisModul den Zähler E110 abzuwandeln für meinen:
"E110" => ["/?3F322211F1E873A66382248779777822!CRLF".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)]
);
Hallo,
da hast du was das CRLF angeht etwas falsch verstanden. Damit sind die Steuerzeichen chr(13) und chr(10) gemeint, und die sind ja schon hinter dem Password vorhanden.
Gruß Friedrich
Ja danke ich habs ohne "CRLF" auch probiert, funktioniert aber auch nicht.
aber vl verstehe ich wirklich noch nicht ganz wo die Daten ausgegeben werden, vl funktioniert ja alles aber ich lese die werte nicht aus.
lg
Wie wärs denn einfach mal mit einem V5-Log?
Hallo, im Anhang ist mein V5-Log.
ich habe nun noch einmal mit unterschiedlichen Übergabewerten, getestet leider ohne Erfolg, in meinem Obis Logfile landen Leider nur CONNECTED/DISCONNECTED.
Und im Modul selbst werde auch keine Readings aufgelistet.
Danke
Lg Watt
Hallo,
ich lese einen Stromzähler mit einem USB-Modul aus. Der schickt die Daten extrem häufig, daraufhin habe ich den Polling-Modus eingeschaltet (mit 60s interval)
Nun habe ich manchmal einen zeitverzug von 10min in den Daten?
Hab mal ein Bild angehängt. Im Bild sieht man es recht deutlich:
Die dünne Linie kommt vom Wechselrichter und zeigt einen PV-Einbruch durch eine Wolke um 13:30. Der etwas dickere ist der Zähler und zeigt den Einbruch um 13:40?
Meine Berechnung des Strombedarfs (gelbe Linie) wird dadurch falsch...
Wie finde ich raus, was da schiefläuft?
Herzlichen Dank, Harald
@haneub
Du kannst mal versuchen das attr alignTime zu setzen. Einmal auf 00:00:00 und beim anderen auf 00:00:59.
vielleicht hilf es.
Pejonp
Mit welchem Modul liest du den Wechselrichter aus? Kostalpiko?
Hallo,
ich hab nen sma WR. Die Daten seh ich sehr zeitnah im fhem. Der ist ja auch immer früher dran, das denke ich passt.
Ich hab jetzt mal Pollingmode auf off gesetzt und es passt ganz wunderbar (so ab 14:40) läuft es wunderbar synchron.
Gruß, Harald
Ist klar.....Dein Zähler sendet ständig Daten.......
Mit Polling ruft das Modul aber nur alle 10 Minuten einen Satz Daten ab.
Der Rest bleibt zwischendurch im System-Buffer und summiert sich hoch.....
Hallo,
ich dachte mit interval 60 würde ich dann alle Minute Daten bekommen?
Pollingmode macht fix 10min Intervall? Das ist zu langsam, da ich eigentlich damit demnächst Ladung von e-Auto steuern will. Da ist 10min zu langsam, die Wolken ziehen schneller...
Ohne Pollingmode hängt das Interface (da auf dem Fhem auch noch der SMA per IP, eine Lüftung per modbus, homematic als modul und wlan-Steckdosen laufen...)
Gruß, Harald
Moin,
ich habe einen neuen Stromzähler bekommen und versuche diesen nun auszulesen.
Es ist ein DZG DWS7412.1 mit optischer Schnittstelle.
Ich habe mir einen IR-Schrei/Lesekopf besorgt und ihn per USB mit meinem FHEM + OBIS gekoppelt.
Scheint soweit auch wunderbar zu funktionieren, ich empfange Daten.
Ich habe nur das merkwürdige Problem das ich mal plausible, mal negative Verbrauchswerte erhalte.
Eingrenzen oder reproduzieren kann ich es nicht. (OBIS zeigt z.B. -279W an während der Zähler selbst 500W anzeigt)
Der Gesamtverbrauch stimmt mit den Angaben des Zählers überein.
Ich habe keine Idee woran das liegen kann und hoffe jemand kann mir helfen.
Hier log vom gesamten Lesevorgang:
2018.09.08 07:04:50 5: SW:
2018.09.08 07:04:50 4: Wrote
2018.09.08 07:04:50 5: OBIS (Stromzaehler) - Internal timer set to 2018-09-08 07:05:20
2018.09.08 07:04:51 5: SML-Parse 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Full message-> 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 4: MSG IS:
/
1-0:96.50.1*255(DZG)
1-0:96.1.0*255(
DZGu)
1-0:1.8.0*255(36281.5*Wh)
1-0:16.7.0*255(-275.62*W)
!
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: /
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*255(DZG)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGu)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(36281.5*Wh)
2018.09.08 07:04:51 5: Msg 1-0:1.8.0*255(36281.5*Wh) is of type Counter
2018.09.08 07:04:51 4: Set total_consumption to 36281.5
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-275.62*W)
2018.09.08 07:04:51 5: Msg 1-0:16.7.0*255(-275.62*W) is of type Channels
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: !
Und ein list vom Device:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
MeterType SML
NAME Stromzaehler
NR 130
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
logdb1:
TIME 1536383271.01572
VALUE -207.91
READINGS:
2018-09-08 07:07:51 1.0.96.50.1.255 DZG
2018-09-08 07:07:51 power -207.91
2018-09-08 06:55:20 state opened
2018-09-08 07:07:51 total_consumption 36300.6
helper:
BUFFER
EoM -1
SPEED
SPEED2
TRIGGERTIME 1536382520.06882
Channels:
DEVICES:
30
directions:
Attributes:
interval 30
pollingMode on
verbose 1
Vielen Dank im voraus.
Gruß
C0mmanda
Ich habe wegen meinem Problem mal den Verkäufer des IR-Lesekopfes angeschrieben. (Nicht Volkszähler).
Er sagt das Problem mit meinem Zähler ist ihm seit wenigen Tagen bekannt und er würde an einem Fix für die Software arbeiten (Emlog).
Weiß jetzt nicht wie hilfreich das ist, aber es scheint ja an der Auswertung der Daten zu liegen...
Habe testweise mal vzlogger installiert, da werden die Daten auch nicht korrekt ausgelesen.... :(
Gruß
Hallo zusammen,
nachdem ich Anfang des Jahres nach einem 47_OBIS.pm update schon Probleme hatte, habe ich es nochmal probiert, bekomme aber nach dem
Update auf die aktuellste Version leider keine Readings mehr. Ich habe einen Pafal Zähler und bekomme mit der aktuellsten Version und Verbose 5 folgende Ausgabe:
2018.09.07 08:33:08 5: OBIS (Haushaltsstrom_PV) - Internal timer set to 2018-09-07 08:36:08
2018.09.07 08:33:08 5: OBIS (Haushaltsstrom_PV) - Msg-Parse: /?!
2018.09.07 08:33:08 5: SW: 063030300d0a
2018.09.07 08:33:09 5: OBIS (Haushaltsstrom_PV) - Msg-Parse: 000
2018.09.07 08:33:37 5: SW: 2f3f210d0a
2018.09.07 08:33:37 4: Wrote /?!
Mehr kommt leider nicht an und die bestehenden Readings werden nicht aktualisiert. Wenn ich dann eine ältere Version von OBIS einspiele (irgendeine von Anfang Januar) dann geht alles wieder.
Für mich ist das Thema aktuell, da ich versuche das bei einem Kollegen mit dem gleichen Zähler einzurichten, da klappt es leider auch nicht.
Kann mir jemand weiterhelfen oder mir sagen, was ich "falsch" mache?
Anbei noch mein define:
define Haushaltsstrom_PV OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_Strom2-if00-port0@300,7,E,1 VSM102
attr Haushaltsstrom_PV event-min-interval total_consumption:600,total_feed:600,total_consumption_PowerCurrent:600,total_consumption_EnergyDay:600,total_consumption_EnergyMonth:600,tota_consumption_EnergyYear:600,total_feed_PowerCurrent:600,total_feed_EnergyDay:600,total_feed_EnergyMonth:600,total_feed_EnergyYear:600,total_consumption_CounterCurrent:600,total_feed_CounterCurrent:600
attr Haushaltsstrom_PV event-on-change-reading total_consumption,total_feed,total_consumption_PowerCurrent,total_consumption_EnergyDay,total_consumption_EnergyMonth,tota_consumption_EnergyYear,total_feed_PowerCurrent,total_feed_EnergyDay,total_feed_EnergyMonth,total_feed_EnergyYear,total_consumption_CounterCurrent,total_feed_CounterCurrent
attr Haushaltsstrom_PV interval 180
attr Haushaltsstrom_PV verbose 0
Vielen Dank schonmal, Grüße, Blixman.
Noch mal zum polling-mode:
Kann ich das irgendwie hinkriegen, das da jede 60s oder 120s ein aktueller Wert erscheint? Im Moment habe ich 10min Zeitversatz und das ist bei den durchziehenden Wolken zu langsam zum regeln eines E-Mobils.
Sonst muss ich einen Raspi(Zero?) nur dafür daneben bauen?
Danke, Harald
Hallo Harald,
Du hast einen "pushenden" Zähler, richtig ?
Dann sollte es mit interval =60 klappen. pejonp hatte Dir dann noch den aligntime Tipp gegeben. Dann liegen die Werte nur minimal auseinander, um den konkreten Verbrauch/Erzeugungsüberschuss zu berechnen. Bei mir klappt das 1a.
Ich hatte früher auch mal ein vergleichbares Problem, aber das hat sich zwischenzeitlich in Luft aufgelöst. Bei mir hat es aber auch damals immer perfekt nach einem Restart funktioniert.
aktuelle Grafik(blau=Zähler;pink=Erzeuger)
Grüße Markus
Also, meine Erfahrung ist, dass im "online-Modus", also Messwerte praktisch zeitgleich mit dem Ereignis (Stromverbraucher an/aus) die Belastung für einen Raspi doch deutlich hoch geht. Ich habe hier auf einem Pi 2+ durchgängig bei 30% CPU Belastung - es läuft lediglich FHEM mit DBLOG und OBIS. Das ist mehr als mein Haupt-PI mit 280 Geräten als Steuerung für Heizung, Lüftung, Wärme-Solar sowie einigen weiteren Schnickschnack :-)
Herzliche Grüße
Christian
pollender oder pushender Zähler ? Beim pushenden den pollingmode=on setzen u. interval definieren, sofern Du nicht unbedingt die permanenten Daten möchtest.
Hallo,
hab ich versucht.
Ich würde gerne jede 1-2 Minuten einen aktuellen Leistungswert bekommen. Die Zählerstände brauche ich nicht so zeitnah.
Mit pollingmode on und interval 60 erhalte ich Werte die 10min zeitverzögert sind.
Ohne Poliingmode erhalte ich die aktuellen Werte.
define ez OBIS /dev/ttyUSB1@9600,8,N,1 SML
attr ez event-min-interval total_feed:300,total_consumption:300,PEin:300,PBezug:300,power:120
attr ez pollingMode on
attr ez interval 60
Bin ein wenig ratlos.
Danke, Harald
Ich würd mal das event-min-interval weglassen. Das ist zumindest kontraproduktiv zu Deinem Ziel von 1' und ich weiß nicht, ob das im Modul überhaupt richtig implementiert ist.
Mal die events nach einem Reboot im Event-Monitor beobachtet ?
Hat jemand einen Elster AS1440 im Einsatz ? Ich vermute schon, da Stefan den ja als Zählertyp implementiert hat. ;D Wenn ich die vielen gegoogelten Dokumente interpretiere, dann hat der keine Werte/Phase. Richtig ?
Grüße Markus
Zitat von: KölnSolar am 25 September 2018, 14:46:48
Hat jemand einen Elster AS1440 im Einsatz ? Ich vermute schon, da Stefan den ja als Zählertyp implementiert hat.
Ich hatte diesen Zähler bei einem Bekannten kurz ausgelesen. Wobei "kurz" hier nicht wirklich richtig ist. Die Baudrate lag bei 300 und die Übertragung sämtliche Daten zog sich über einen sehr langen Zeitraum hin. Es kam aber alles an. Mehr kann ich dazu nicht sagen, da der Lesekopf nun wieder am EasyMeter hängt.
Dank Dir für die Rückmeldung.
ZitatDie Baudrate lag bei 300
....ist nach meinem Verständnis die Grundeinstellung, die sich aber verändern lässt(Oder macht es das OBIS-Modul gar "automatisch" ? :-\)
ZitatEs kam aber alles an.
Also pro Phase ? Mir sind halt die Leistungsdaten/Phase wichtig und bis 31.12. muss mein jetziger Hager wg. Ablauf der Eichfrist getauscht werden. Und ich erwäge den Wechsel des Messstellenbetreibers, da ich wg. tollem Gesetz u. PV > 7 kWp bald wieder vermutlich mit einem neuen Zähler(dann als "intelligente Messeinrichtung" mit Gateway ::) :'( >:( >:( >:() zwangsbeglückt werde.
Hallo!
Mein Netzbetreiber hat mir heute meinen Hager-Zähler für die PV-Anlage durch einen emh-Zähler getauscht. Den Haber konnte ich mit Obis einwandfrei auslesen. Den emh mit SML nicht. Alle Werte bleiben bei Null.
Verbose 5 gibt mir das aus:
2018.10.26 11:40:05 5: SML-Parse 1B1B1B1B010101017607000900006F936200620072630101760101070009000025310B0901454D48000067EAB80101636190007607000900006F94620062007263070177010B0901454D48000067EAB8070100620AFFFF72620165000030177677078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000067EAB80177070100020800FF640100A201621E52035600000000000177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Full message-> 1B1B1B1B010101017607000900006F936200620072630101760101070009000025310B0901454D48000067EAB80101636190007607000900006F94620062007263070177010B0901454D48000067EAB8070100620AFFFF72620165000030177677078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000067EAB80177070100020800FF640100A201621E52035600000000000177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=1B1B1B1B010101017607000900006F936200620072630101760101070009000025310B0901454D48000067EAB80101636190007607000900006F94620062007263070177010B0901454D48000067EAB8070100620AFFFF72620165000030177677078181C78203FF0101010104454D480177070100000009FF010101010B0901454D48000067EAB80177070100020800FF640100A201621E52035600000000000177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=0177070100000009FF010101010B0901454D48000067EAB80177070100020800FF640100A201621E52035600000000000177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=0177070100020800FF640100A201621E52035600000000000177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=0177070100020801FF0101621E52035600000000000177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=0177070100020802FF0101621E52035600000000000177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 5: OBIS: Telegram=0177078181C78205FF010101018302BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401010163A584007607000900006F97620062007263020171016332B00000001B1B1B1B1A023071
2018.10.26 11:40:05 4: MSG IS:
/EMH\0901454D48000067EAB8
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D48000067EAB8)
1-0:2.8.0*255(<0*Wh)
1-0:2.8.1*255(0*Wh)
1-0:2.8.2*255(0*Wh)
129-129:199.130.5*255(BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401)
!
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: /EMH\0901454D48000067EAB8
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 129-129:199.130.3*255(EMH)
2018.10.26 11:40:05 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 1-0:0.0.9*255(0901454D48000067EAB8)
2018.10.26 11:40:05 5: Msg 1-0:0.0.9*255(0901454D48000067EAB8) is of type Serial
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 1-0:2.8.0*255(<0*Wh)
2018.10.26 11:40:05 5: Msg 1-0:2.8.0*255(<0*Wh) is of type Counter
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 1-0:2.8.1*255(0*Wh)
2018.10.26 11:40:05 5: Msg 1-0:2.8.1*255(0*Wh) is of type Counter
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 1-0:2.8.2*255(0*Wh)
2018.10.26 11:40:05 5: Msg 1-0:2.8.2*255(0*Wh) is of type Counter
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: 129-129:199.130.5*255(BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401)
2018.10.26 11:40:05 5: Msg 129-129:199.130.5*255(BF8FA4536EC45EE4FD775DE9A7EB63F054F76317E918774BF03669D5CBCADDAC22B5404739C22537D95610ACA37BB5A401) is of type PublicKey
2018.10.26 11:40:05 5: OBIS (EHZ_PV) - Msg-Parse: !
Ein list gibt das:
Internals:
CFGFN
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_1402-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_1402-if00-port0@9600,8,N,1
FD 28
MeterType SML
NAME EHZ_PV
NR 569
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2018-10-26 11:43:54 1.0.0.0.9.255 09-01-45-4D-48-00-00-67-EA-B8
2018-10-26 11:43:54 129.129.199.130.3.255 EMH
2018-10-26 11:43:54 129.129.199.130.5.255 BF8F-A453-6EC4-5EE4-FD77-5DE9-A7EB-63F0-54F7-6317-E918-774B-F036-69D5-CBCA-DDAC-22B5-4047-39C2-2537-D956-10AC-A37B-B5A4-01
2018-10-26 11:38:48 Version EMH\0901454D48000067EAB8
2018-10-26 11:43:54 statTotal_feed_Ch1 Hour: 0 Day: 0 Month: 0 Year: 0 (since: )
2018-10-26 11:43:54 statTotal_feed_Ch1Day 0
2018-10-26 11:43:54 statTotal_feed_Ch1Hour 0
2018-10-26 11:43:54 statTotal_feed_Ch1Month 0
2018-10-26 11:43:54 statTotal_feed_Ch1Year 0
2018-10-26 11:38:47 state opened
2018-10-26 11:43:54 total_feed 0
2018-10-26 11:43:54 total_feed_Ch1 0
2018-10-26 11:43:54 total_feed_Ch2 0
helper:
BUFFER v
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1540546727.34973
_98_statistics Statistik_EHZ_PV
Channels:
DEVICES:
-1
directions:
Attributes:
Habe jetzt die knapp 40 Seiten durch, habe auch gesehen, dass es irgendwo mal as Problem gab, habe aber die Lösung nicht gesehen oder übersehen.
Hat jemand einen Tipp?
Danke und Grüße
Niel
EDIT: Nachdem die Anzeige am Zähler jetzt die erste kWh anzeigt, liefert mir das Modul als Reading-Wert "1000". Wird das irgendwo gerundet? Kann man das einstellen?
Einen (zwei) EMH Zähler habe ich auch. Funktioniert einwandfrei. Hast Du mal das Device gelöscht und neu angelegt?
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F31B12-if00-port0@9600 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F31B12-if00-port0@9600
MeterType SML
NAME VersorgerZaehler
NR 274
PARTIAL
STATE <div style='color:green'>-300.0 W</div>
TYPE OBIS
READINGS:
2018-10-26 12:11:17 0.0.96.1.255.255 2253830
2018-10-26 12:11:17 1.0.0.0.0.255 39-30-30-36-39-36-38-31
2018-10-26 12:11:17 129.129.199.130.3.255 EMH
2018-10-25 08:06:17 Version EMH\3930303639363831
2018-10-26 12:11:17 color #3aab2c
2018-10-26 12:11:17 differenz -300
2018-10-26 12:11:17 feed_L1 300.4
2018-10-26 12:11:17 power 0
2018-10-23 17:56:13 state opened
2018-10-26 12:11:17 total_consumption_Ch1 19881933.3
2018-10-26 12:11:17 total_feed_Ch1 21438318.2
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1540310173.74467
Channels:
DEVICES:
300
directions:
Attributes:
interval 300
pollingMode on
Mehrfach schon.
Kann es sein, dass mein Netzbetreiber die Ausgabe beschnitten hat?
Edit: Habe den Zähler jetzt mal mit dem PIN gefüttert. Jetzt zeigt er mir am Display die Momentanleistung an und das Datenprotokoll gibt jetzt auch 0,0001 kWh aus. Alles gut also!
Was für ein PIN? Woher kommt der?
Hallo zusammen,
hatte die ganze Zeit das Obis Modul vom
# $Id: 47_OBIS.pm 13885 2017-04-03 03:50:45Z Icinger $
mit einem Zweirichtungs EMH Zähler am Laufen. Habe nun nach langer Zeit auf die aktuellste Version vom
# $Id: 47_OBIS.pm 16167 2018-02-13 20:36:00Z Icinger $
upgedatet.
Mit der alten Modulversion wurden die "directions" für "pwr consuming" und "pwr feeding" korrekt erkannt. Sobald ich die aktuellste Version lade wird das Statusbit nicht erkannt und die Readings "dir_total_consumption" und "dir_total_feed" werden nicht mehr aktualisiert.
Hat jemand ne Idee was da falsch läuft?
Hier mal ein list vom device (mit einigen von mir angelegten Userreadings)
Internals:
DEF /dev/ttyUSB_StromHaus@9600,8,N,1 SML
DeviceName /dev/ttyUSB_StromHaus@9600,8,N,1
MeterType SML
NAME stromZaehler
NEXT 2018-11-05 20:20:25
NR 216
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2018-11-05 20:19:58 1.0.0.0.9.255 06-45-4D-48-01-09-6D-95-E0-8B
2018-11-05 20:19:58 129.129.199.130.3.255 EMH
2018-11-05 20:19:58 129.129.199.130.5.255 A463-E151-7725-FEAA-8437-505B-7D06-E541-73B8-2CE7-EDD6-4674-9727-82DE-58C9-28BC-FAF8-42E7-21B7-A0E1-9C09-B93B-A728-5498-01
2018-11-05 20:19:59 Eigenverbrauch-Total 4569.9
2018-11-05 20:19:59 Eigenverbrauch-o-HS 3215.1
2018-11-05 20:19:59 Momentanleistung 187
2018-11-05 20:19:59 Momentanleistung_feed 0
2018-11-05 05:29:27 Version EMH\06454D4801096D95E08B
2018-11-05 20:19:59 Zaehlerstand-Bezug-Total 2619.0
2018-11-05 20:19:59 Zaehlerstand-Lieferung-Total 19988.0
2018-11-05 20:19:58 dir_total_consumption pwr consuming
2018-11-05 20:19:58 dir_total_feed pwr consuming
2018-11-05 20:19:58 power 186.6
2018-11-05 20:19:59 statEigenverbrauch-Total Hour: 0.0 Day: 2.3 Month: 12.9 Year: 1307.0 (since: )
2018-11-05 20:19:59 statEigenverbrauch-TotalDay 2.3
2018-11-04 23:59:55 statEigenverbrauch-TotalDayLast 1.8
2018-11-05 20:19:59 statEigenverbrauch-TotalHour 0.0
2018-11-05 19:59:55 statEigenverbrauch-TotalHourLast 0.0
2018-11-05 19:59:55 statEigenverbrauch-TotalLast Hour: 0.0 Day: 1.8 Month: 244.3 Year: 2364.3 (since: )
2018-11-05 20:19:59 statEigenverbrauch-TotalMonth 12.9
2018-10-31 23:59:55 statEigenverbrauch-TotalMonthLast 244.3
2018-11-05 20:19:59 statEigenverbrauch-TotalYear 1307.0
2017-12-31 23:59:33 statEigenverbrauch-TotalYearLast 2364.3
2018-11-05 20:19:59 statEigenverbrauch-o-HS Hour: 0.0 Day: 2.3 Month: 12.9 Year: 1294.3 (since: )
2018-11-05 20:19:59 statEigenverbrauch-o-HSDay 2.3
2018-11-04 23:59:55 statEigenverbrauch-o-HSDayLast 1.8
2018-11-05 19:59:55 statEigenverbrauch-o-HSLast Hour: 0.0 Day: 1.8 Month: 243.6 Year: 1604.3 (since: )
2018-11-05 20:19:59 statEigenverbrauch-o-HSMonth 12.9
2018-10-31 23:59:55 statEigenverbrauch-o-HSMonthLast 243.6
2018-11-05 20:19:59 statEigenverbrauch-o-HSYear 1294.3
2017-12-31 23:59:33 statEigenverbrauch-o-HSYearLast 1604.3
2018-11-05 20:19:59 statMomentanleistungDay Min: 0 Avg: 227 Max: 3033
2018-11-04 23:59:55 statMomentanleistungDayLast Min: 3 Avg: 268 Max: 2980
2018-11-05 20:19:59 statMomentanleistungHour Min: 172 Avg: 402 Max: 2286
2018-11-05 19:59:55 statMomentanleistungHourLast Min: 172 Avg: 247 Max: 869
2018-11-05 20:19:59 statMomentanleistungMonth Min: 0 Avg: 274 Max: 4433
2018-10-31 23:59:55 statMomentanleistungMonthLast Min: 0 Avg: 104 Max: 4305 (since: )
2018-11-05 20:19:59 statMomentanleistungYear Min: 0 Avg: 117 Max: 6698 (since: )
2017-12-31 23:59:33 statMomentanleistungYearLast Min: 0 Avg: 132 Max: 6617
2018-11-05 20:19:59 statMomentanleistung_feedDay Min: 0 Avg: 601 Max: 4182
2018-11-04 23:59:55 statMomentanleistung_feedDayLast Min: 0 Avg: 0 Max: 0
2018-11-05 20:19:59 statMomentanleistung_feedHour Min: 0 Avg: 0 Max: 0
2018-11-05 19:59:55 statMomentanleistung_feedHourLast Min: 0 Avg: 0 Max: 0
2018-11-05 20:19:59 statMomentanleistung_feedMonth Min: 0 Avg: 288 Max: 4216
2018-10-31 23:59:55 statMomentanleistung_feedMonthLast Min: 0 Avg: 951 Max: 6786 (since: )
2018-11-05 20:19:59 statMomentanleistung_feedYear Min: 0 Avg: 900 Max: 7738 (since: )
2017-12-31 23:59:33 statMomentanleistung_feedYearLast Min: 0 Avg: 813 Max: 7480
2018-11-05 20:19:59 statZaehlerstand-Bezug-Total Hour: 0.1 Day: 2.7 Month: 20.2 Year: 812.6 (since: )
2018-11-05 20:19:59 statZaehlerstand-Bezug-TotalDay 2.7
2018-11-04 23:59:55 statZaehlerstand-Bezug-TotalDayLast 3.6
2018-11-05 20:19:59 statZaehlerstand-Bezug-TotalHour 0.1
2018-11-05 19:59:55 statZaehlerstand-Bezug-TotalHourLast 0.2
2018-11-05 19:59:55 statZaehlerstand-Bezug-TotalLast Hour: 0.2 Day: 3.6 Month: 154.5 Year: 1156.8 (since: )
2018-11-05 20:19:59 statZaehlerstand-Bezug-TotalMonth 20.2
2018-10-31 23:59:55 statZaehlerstand-Bezug-TotalMonthLast 154.5
2018-11-05 20:19:59 statZaehlerstand-Bezug-TotalYear 812.6
2017-12-31 23:59:33 statZaehlerstand-Bezug-TotalYearLast 1156.8
2018-11-05 20:19:59 statZaehlerstand-Lieferung-Total Hour: 0.0 Day: 14.5 Month: 45.7 Year: 8197.6 (since: )
2018-11-05 20:19:59 statZaehlerstand-Lieferung-TotalDay 14.5
2018-11-04 23:59:55 statZaehlerstand-Lieferung-TotalDayLast 2.9
2018-11-05 20:19:59 statZaehlerstand-Lieferung-TotalHour 0.0
2018-11-05 19:59:55 statZaehlerstand-Lieferung-TotalHourLast 0.0
2018-11-05 19:59:55 statZaehlerstand-Lieferung-TotalLast Hour: 0.0 Day: 2.9 Month: 1371.3 Year: 7210.0 (since: )
2018-11-05 20:19:59 statZaehlerstand-Lieferung-TotalMonth 45.7
2018-10-31 23:59:55 statZaehlerstand-Lieferung-TotalMonthLast 1371.3
2018-11-05 20:19:59 statZaehlerstand-Lieferung-TotalYear 8197.6
2017-12-31 23:59:33 statZaehlerstand-Lieferung-TotalYearLast 7210.0
2018-11-05 10:41:14 state opened
2018-11-05 20:19:58 total_consumption 2619045
2018-11-05 20:19:58 total_consumption_Ch1 2619045
2018-11-05 20:19:58 total_consumption_Ch2 0
2018-11-05 20:19:58 total_feed 19988042
2018-11-05 20:19:58 total_feed_Ch1 19988042
2018-11-05 20:19:58 total_feed_Ch2 0
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1541445625
_98_statistics statisticsPowerHaus
Channels:
DEVICES:
30
directions:
< pwr feeding
> pwr consuming
Attributes:
alignTime 00:00:55
comment Strom_allgemein
directions {">" => "pwr consuming", "<"=>"pwr feeding"}
event-min-interval .*:3600
event-on-change-reading statZaehlerstand-Lieferung-TotalHourLast.*:1,statZaehlerstand-Bezug-TotalHourLast.*:0.1,statZaehlerstand-Lieferung-TotalDayLast.*:1,Momentanleistung:50,Momentanleistung_feed:100,Zaehlerstand-Bezug-Total:0.5,statZaehlerstand-Bezug-TotalYearLast:1,statZaehlerstand-Bezug-TotalMonthLast:1,Zaehlerstand-Lieferung-Total:0.5,statZaehlerstand-Lieferung-TotalYearLast:1,statZaehlerstand-Lieferung-TotalMonthLast:1,Eigenverbrauch-Total:0.5,statEigenverbrauch-TotalDayLast:1,statEigenverbrauch-o-HSDayLast:1,statEigenverbrauch-TotalMonthLast:1,statEigenverbrauch-o-HSMonthLast:1,power:150
ignoreUnknown off
interval 30
pollingMode on
room Strom_Haus
unitReadings off
userReadings Zaehlerstand-Bezug-Total { sprintf("%.1f",ReadingsVal("stromZaehler","total_consumption",0)/1000) },
Zaehlerstand-Lieferung-Total { sprintf("%.1f",ReadingsVal("stromZaehler","total_feed",0)/1000) },
Momentanleistung { if (ReadingsVal("stromZaehler","dir_total_feed",0) eq "pwr consuming")
{sprintf("%.0f",abs(ReadingsVal("stromZaehler","power",0)))} else {"0"} },
Momentanleistung_feed { if (ReadingsVal("stromZaehler","dir_total_feed",0) eq "pwr feeding")
{sprintf("%.0f",abs(ReadingsVal("stromZaehler","power",0)))} else {"0"} },
Eigenverbrauch-Total { sprintf("%.1f",(ReadingsVal("pvliwa1","Energy_Total__kWh",0)-38.7)
-(ReadingsVal("stromZaehler","Zaehlerstand-Lieferung-Total",0)))},
Eigenverbrauch-o-HS { sprintf("%.1f",(ReadingsVal("pvliwa1","Energy_Total__kWh",0)-38.7)
-(ReadingsVal("stromZaehler","Zaehlerstand-Lieferung-Total",0))-(ReadingsVal("HM_2DD93A_Pwr","energy-Heater",0)))}
verbose 5
und ein Log:
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: /EMH\06454D4801096D95E08B
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2018.11.05 20:14:58 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:0.0.9*255(06454D4801096D95E08B)
2018.11.05 20:14:58 5: Msg 1-0:0.0.9*255(06454D4801096D95E08B) is of type Serial
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:1.8.0*255(>2619008.2*Wh)
2018.11.05 20:14:58 5: Msg 1-0:1.8.0*255(>2619008.2*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:2.8.0*255(>19988042*Wh)
2018.11.05 20:14:58 5: Msg 1-0:2.8.0*255(>19988042*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:1.8.1*255(2619008.2*Wh)
2018.11.05 20:14:58 5: Msg 1-0:1.8.1*255(2619008.2*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:2.8.1*255(19988042*Wh)
2018.11.05 20:14:58 5: Msg 1-0:2.8.1*255(19988042*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2018.11.05 20:14:58 5: Msg 1-0:1.8.2*255(0*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:2.8.2*255(0*Wh)
2018.11.05 20:14:58 5: Msg 1-0:2.8.2*255(0*Wh) is of type Counter
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 1-0:16.7.0*255(187.3*W)
2018.11.05 20:14:58 5: Msg 1-0:16.7.0*255(187.3*W) is of type Channels
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: 129-129:199.130.5*255(A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801)
2018.11.05 20:14:58 5: Msg 129-129:199.130.5*255(A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801) is of type PublicKey
2018.11.05 20:14:58 5: OBIS (stromZaehler) - Msg-Parse: !
2018.11.05 20:15:25 5: SW:
2018.11.05 20:15:25 4: Wrote
2018.11.05 20:15:25 5: OBIS (stromZaehler) - Internal timer set to 2018-11-05 20:15:55
2018.11.05 20:15:28 5: SML-Parse 1B1B1B1B010101017607000A0383FB50620062007263010176010107000A0494FE700B06454D4801096D95E08B01016336AB007607000A0383FB51620062007263070177010B06454D4801096D95E08B070100620AFFFF72620165049457387A77078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D95E08B0177070100010800FF6401018201621E52FF5600018FA1120177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Full message-> 1B1B1B1B010101017607000A0383FB50620062007263010176010107000A0494FE700B06454D4801096D95E08B01016336AB007607000A0383FB51620062007263070177010B06454D4801096D95E08B070100620AFFFF72620165049457387A77078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D95E08B0177070100010800FF6401018201621E52FF5600018FA1120177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=1B1B1B1B010101017607000A0383FB50620062007263010176010107000A0494FE700B06454D4801096D95E08B01016336AB007607000A0383FB51620062007263070177010B06454D4801096D95E08B070100620AFFFF72620165049457387A77078181C78203FF0101010104454D480177070100000009FF010101010B06454D4801096D95E08B0177070100010800FF6401018201621E52FF5600018FA1120177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100000009FF010101010B06454D4801096D95E08B0177070100010800FF6401018201621E52FF5600018FA1120177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100010800FF6401018201621E52FF5600018FA1120177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100020800FF6401018201621E52FF56000BE9EEE40177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100010801FF0101621E52FF5600018FA1120177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100020801FF0101621E52FF56000BE9EEE40177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100010802FF0101621E52FF5600000000000177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177070100100700FF0101621B52FF55000007420177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 5: OBIS: Telegram=0177078181C78205FF01726201650494573801018302A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801010163458C007607000A0383FB546200620072630201710163E43C00001B1B1B1B1A012C94
2018.11.05 20:15:28 4: MSG IS:
/EMH\06454D4801096D95E08B
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(06454D4801096D95E08B)
1-0:1.8.0*255(>2619009.8*Wh)
1-0:2.8.0*255(>19988042*Wh)
1-0:1.8.1*255(2619009.8*Wh)
1-0:2.8.1*255(19988042*Wh)
1-0:1.8.2*255(0*Wh)
1-0:2.8.2*255(0*Wh)
1-0:16.7.0*255(185.8*W)
129-129:199.130.5*255(A463E1517725FEAA8437505B7D06E54173B82CE7EDD64674972782DE58C928BCFAF842E721B7A0E19C09B93BA728549801)
!
Danke euch schon mal fürs anschauen.
Grüße Tomy
Hallo zusammen,
ich bin nun auch (stolzer) Besitzer eines elektronischen Zählers mit IR Schnittstelle: Apator EC3. Für die Einbindung in FHEM habe ich mir natürlich umgehend einen IR- Lese- Kopf besorgt und an meinem Raspberry Pi angebunden. Soweit so gut... ein OBIS device erstellt, aber leider kamen keine Daten. Daraufhin habe mit dem Volkszähler Projekt mal Tests gemacht und weiss nun, dass es sich um einen Zähler mit "d0" Protokoll und nach dem Pull Verfahren handelt. Die folgende Einstellung in VZLogger funktioniert mit meinem Meter:
"meters": [
{
"enabled": true,
"allowskip": false,
"protocol": "d0",
"device": "/dev/ttyUSB0",
"dump_file": "/home/pi/2_pull_d0.txt",
"pullseq": "2F3F210D0A",
"ackseq": "063030300D0A",
"baudrate": 300,
"baudrate_change_delay": 0,
"parity": "7e1"
}
--> Nun meine Frage: Wie bekomme ich die notwendige Pullsequence und Acksequence mit OBIS in FHEM realisiert:
"pullseq": "2F3F210D0A",
"ackseq": "063030300D0A"
Vielen lieben Dank für jedwede Hilfe!
Sascha
Hallo Saschenka,
Deine Pullsequenz wird verwendet wenn du beim define einen der folgenden Metertypen einsetzt:
VSM102
E110
E350USB
Acksequenz habe ich im Code des Moduls nicht gefunden, wird meines Wissens nicht vom Modul verwendet. Wenn ich es richtig verstehe wird der Zähler nur mit der Pullsequenz angesprochen und danach empfängt das Modul die Daten.
Baudratenumstellung vermisse ich selbst sehr dringend aber die gibt es derzeit nicht. Siehe Antwort#294 von Icinger.
Ich würde unheimlich gerne auf 9600 Baud umstellen weil ich meine Einspeiseleistung der PV Anlage zum schnellen steuern einer Klimaanlage im Heizbetrieb verwenden möchte. Wenn die erst nach 47 Sekunden das Signal bekommt dass irgend ein Großverbraucher wie die Waschmaschine plötzlich den ganzen Strom wegsaugt, wird die Klima solange Kohlestrom verheizen und das ist doch unschön.
Viele Grüße
PS: Code liegt unter: https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/47_OBIS.pm
Hallo Saschenka,
deine Acksequenz wird vom Modul automatisch verwendet wie von dir angegeben, sofern du einen der drei oben genannten Zählertypen definierst.
Sorry für die Verwirrung.
Hallo,
habe heute meinen USB reader bekommen und dank dieses threads (die 40 Seiten haben schon etwas gedauert...) funktioniert alles soweit sehr gut. Der eMeter ist ein ISKRA MT174, der leider keine aktuelle Leistung ausgibt.
Wie könnte ich aus der Differenz zweier aufeinender folgenden Verbrauswerte die Leistung möglichst geschickt rechnen ?
Ich hab es mit "differential probiert, aber es ist wahrscheinlich auch schon zu spät ...
# direct reading via OBIS fhem module
#
define eMeter OBIS /dev/ttyUSB3@300,7,E,1 VSM102
attr eMeter interval 120
attr eMeter room Stromverbrauch
attr eMeter unitReadings off
attr eMeter channels {"1-0:1.8.0*255"=>"kWh_total","1-0:1.8.0*01"=>"kWh_start_this_month","1-0:1.8.1*01"=>"kWh_start_last_month"}
#
#copy reading before processing
attr eMeter userReadings copy_kWh_total { ReadingsVal("eMeter","kWh_total",0)}
# differential
attr eMeter userReadings power differential {ReadingsVal("eMeter","copy_kWh_total",0)}
Die readings kommen fein rein, aber die Differenz will noch nicht.
kWh_start_last_month 49.566 2018-11-28 03:53:09
kWh_start_this_month 86.56 2018-11-28 03:52:58
kWh_total 345.379 2018-11-28 03:52:58
power 0 2018-11-28 03:53:22
Wie kann das bitte gehen ?
bin etwas weiter und bekomme zumindest mal einen Differenzwert angezeigt... und der Wert wird auch aktualisiert.
dummy power_calc 0.00559006868464985
# direct reading via OBIS fhem module
#
define eMeter OBIS /dev/ttyUSB3@300,7,E,1 VSM102
attr eMeter channels {"1-0:1.8.0*255"=>"kWh_total","1-0:1.8.0*01"=>"kWh_start_this_month","1-0:1.8.1*01"=>"kWh_start_last_month"}
attr eMeter interval 120
attr eMeter room Stromverbrauch
attr eMeter unitReadings off
attr eMeter userReadings power_delta differential {ReadingsVal("eMeter","kWh_total",0)}
attr power_delta stateFormat {sprintf("%.1f W",ReadingsVal("power_delta","value",0))}
#
define power_calc dummy
attr power_calc room Stromverbrauch
define Set_power_calc DOIF ([eMeter:power_delta] != 0 ) (set power_calc [eMeter:power_delta])
aber die Umrechnung Energie in Leistung geht (noch) nicht - habe einiges probiert...
Eine kWh Differenz müsste mit 30000 multipliziert werden 1000/k *60min/h / intervall 2min = W
Differential teil ggf. schon durch die Sekunden - dann ist das anzupassen. Mir geht es erstmal um eine gute Lösung und die Syntax, wie das generell gerechnet werden kann. Das Zeitintervall ist ggf. auch noch zu kurz...
Könntest Du bitte ein eigenes Thema eröffnen. Das hat jetzt wenig mit dem Modul zu tun, denn das scheint ja zu funktionieren.
Grüße Markus
da der ISKRA MT174 weit verbreitet ist und das power reading fehlt (wird zumindest in einigen threads berichtet), könnte das auch in das OBIS modul als option aufgenommen werden. auch mit der 9600bd Umschaltung, die hier schon besprochen wurde.
nur so eine Idee...
Hi
ich habe bei mir seit monaten einen SML Zähler an einem PI und mit Fhem2Fhem and meine Main FHEM angekoppelt. Nun sind mir viele Fehler im Log von einem Notify aufgefallen, aber ich habe irgendwie vergessen wozu dies da war. Hat jmd eine Idee?
define RemoteFHEM FHEM2FHEM 192.168.178.57:7072 LOG:EasymeterQ3C.* xxxxx
attr RemoteFHEM room Devices
define EasymeterQ3C dummy
attr EasymeterQ3C room Allgemein
define EasymeterQ3C_notify notify EasymeterQ3C { $EVENT=~s/://;;;; fhem("setreading EasymeterQ3C $EVENT") ;;;; my $power= ReadingsVal("EasymeterQ3C","power",0) ;;;; fhem("setreading EasymeterQ3C power: $power") ;;;; my $total_consumption= ReadingsVal("EasymeterQ3C","total_consumption",0) ;;;; fhem("setreading EasymeterQ3C total_consumption: $total_consumption" ;;;; my $statTotal_consumptionDay= ReadingsVal("EasymeterQ3C","statTotal_consumptionDay",0) ;;;; fhem("setreading EasymeterQ3C statTotal_consumptionDay: $statTotal_consumptionDay") ;;;; my $statTotal_consumptionHour= ReadingsVal("EasymeterQ3C","statTotal_consumptionHour",0) ;;;; fhem("setreading EasymeterQ3C statTotal_consumptionHour: $statTotal_consumptionHour") ;;;; my $statTotal_consumptionMonth= ReadingsVal("EasymeterQ3C","statTotal_consumptionMonth",0) ;;;; fhem("setreading EasymeterQ3C statTotal_consumptionMonth: $statTotal_consumptionMonth") ;;;; my $statTotal_consumptionYear= ReadingsVal("EasymeterQ3C","statTotal_consumptionYear",0) ;;;; fhem("setreading EasymeterQ3C statTotal_consumptionYear: $statTotal_consumptionYear") }
Im Dummy sind folgende readings. mit oder ohne nofify aktualisieren die sich. Irgendwie bin ich hierzu überfragt
Readings
1.0.96.5.5.255
1678-4
2018-12-04 08:24:34
129.129.199.130.3.255
ESY
2018-12-04 08:24:33
power
621.23 W
2018-12-04 08:24:34
power_L1
494.63 W
2018-12-04 08:24:34
power_L2
54.83 W
2018-12-04 08:24:34
power_L3
71.77 W
2018-12-04 08:24:34
statPowerDayLast
Min: 130.81 Avg: 320.84 Max: 3943.82
2018-12-03 23:59:55
statPowerHourLast
Min: 242.98 Avg: 563.63 Max: 785.01
2018-12-04 07:59:55
statTotal_consumption
Hour: 227.3896 Day: 2351.7105 Month: 26562.1686 Year: 1395180.4709 (since: 2018-06-30_08:16:13 )
2018-12-04 08:24:34
statTotal_consumptionDay
2351.7105
2018-12-04 08:24:34
statTotal_consumptionDayLast
7680.7115
2018-12-03 23:59:55
statTotal_consumptionHour
227.3896
2018-12-04 08:24:34
statTotal_consumptionHourLast
563.8339
2018-12-04 07:59:55
statTotal_consumptionLast
Hour: 563.8339 Day: 7680.7115 Month: 258619.8591 Year: -
2018-12-04 07:59:55
statTotal_consumptionMonth
26562.1686
2018-12-04 08:24:34
statTotal_consumptionYear
1395180.4709
2018-12-04 08:24:34
statTotal_consumption_Ch1
Hour: 230 Day: 2350 Month: 26560 Year: 1395180 (since: 2018-06-30_08:16:13 )
2018-12-04 08:24:34
statTotal_consumption_Ch1Last
Hour: 560 Day: 7680 Month: 258620 Year: -
2018-12-04 07:59:55
statTotal_feed
Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 4708.9537 (since: 2018-06-30_08:16:13 )
2018-12-04 08:24:34
statTotal_feedLast
Hour: 0.0000 Day: 0.0000 Month: 876.0773 Year: -
2018-12-04 07:59:55
total_consumption
18493323.2743 Wh
2018-12-04 08:24:33
total_consumption_Ch1
18486740 Wh
2018-12-04 08:24:34
total_consumption_Ch2
1260 Wh
2018-12-04 08:24:34
total_consumption_Ch3
1270 Wh
2018-12-04 08:24:34
total_consumption_Ch4
1270 Wh
2018-12-04 08:24:34
total_consumption_Ch5
1270 Wh
2018-12-04 08:24:34
total_consumption_Ch6
1510 Wh
2018-12-04 08:24:34
total_feed
79457.6192 Wh
2018-12-04 08:24:34
total_feed_Ch7
78200 Wh
2018-12-04 08:24:34
total_feed_Ch8
1250 Wh
2018-12-04 08:24:34
@Niel: Habe auch einen EHZ von der Firma emh verpasst bekommen. Je nachdem, wie das EVU den Zähler ordert, ist neben dem PIN Schutz eine weitere Sicherheit eingebaut, welche nach 240 sek. wieder nur die Standardausgabe (sieht man im Display abwechselnd die Info für Bezug und Lieferung) anzeigt. Somit werden über die vorderseitige optische Schnittstelle auch nur diese Daten zur Verfügung gestellt.
Nach langem Hin und her hat es ein Techniker meines Netzbetreibers geschafft, diesen automatischen Rückfall auf default-Ausgabe zu deaktivieren. Seither zeigt der Zähler auch die aktuelle Leistung im Display (2. Zeile) und liefert mit SML noch weitere Power-Daten der einzelnen Phasen, usw.
Hallo zusammen,
habe erst seit ein paar Tagen mein RPi3 mit FHEM laufen, bin also ein FHEM-Neuling.
Beim Auslesen meines Easymeters per Infrarot-Lesekopf stoße ich leider auf Probleme.
Leider wird mir im Logfile mit verbose=5 nur die SML-Nachrichten angezeigt, leider werden diese aber nicht dekodiert und es werden keine Readings erzeugt.
Hat jemand eine Idee, wo ich ansetzen könnte?
Hier ein Ausschnitt aus meinem Log:
2019.01.04 22:08:00 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112113620062007263010176010445535908455359627C21130B090145535911032340060101637C3B00760B4553594D400601112114620062007263070177010B09014553591103234006080100620A7F7F00726201650005627C74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163702100760B4553594D40060111211562006200726302017101636931001B1B1B1B1A000461
2019.01.04 22:08:01 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112116620062007263010176010445535908455359627D21160B090145535911032340060101636E3500760B4553594D400601112117620062007263070177010B09014553591103234006080100620A7F7F00726201650005627D74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101634C7300760B4553594D40060111211862006200726302017101630706001B1B1B1B1A000927
2019.01.04 22:08:02 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112119620062007263010176010445535908455359627E21190B09014553591103234006010163582700760B4553594D40060111211A620062007263070177010B09014553591103234006080100620A7F7F00726201650005627E74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163495800760B4553594D40060111211B62006200726302017101633478001B1B1B1B1A000B6B
2019.01.04 22:08:03 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111211C620062007263010176010445535908455359627F211C0B090145535911032340060101634A2900760B4553594D40060111211D620062007263070177010B09014553591103234006080100620A7F7F00726201650005627F74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101635D2000760B4553594D40060111211E62006200726302017101637073001B1B1B1B1A002172
2019.01.04 22:08:04 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111211F6200620072630101760104455359084553596200211F0B090145535911032340060101632D6C00760B4553594D400601112120620062007263070177010B09014553591103234006080100620A7F7F00726201650005620074770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163663400760B4553594D4006011121216200620072630201710163737C001B1B1B1B1A00381E
2019.01.04 22:08:05 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112122620062007263010176010445535908455359620121220B09014553591103234006010163660000760B4553594D400601112123620062007263070177010B09014553591103234006080100620A7F7F00726201650005620174770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101635A6600760B4553594D40060111212462006200726302017101633777001B1B1B1B1A001634
2019.01.04 22:08:06 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112125620062007263010176010445535908455359620221250B090145535911032340060101631E3700760B4553594D400601112126620062007263070177010B09014553591103234006080100620A7F7F00726201650005620274770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101630F1900760B4553594D40060111212762006200726302017101630409001B1B1B1B1A002E6F
2019.01.04 22:08:07 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112128620062007263010176010445535908455359620321280B09014553591103234006010163421C00760B4553594D400601112129620062007263070177010B09014553591103234006080100620A7F7F00726201650005620374770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101634B3500760B4553594D40060111212A62006200726302017101636A3E001B1B1B1B1A001918
2019.01.04 22:08:08 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111212B6200620072630101760104455359084553596204212B0B090145535911032340060101637F5100760B4553594D40060111212C620062007263070177010B09014553591103234006080100620A7F7F00726201650005620474770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163256600760B4553594D40060111212D62006200726302017101630C1E001B1B1B1B1A002218
2019.01.04 22:08:09 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111212E6200620072630101760104455359084553596205212E0B090145535911032340060101636D5F00760B4553594D40060111212F620062007263070177010B09014553591103234006080100620A7F7F00726201650005620574770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163193400760B4553594D40060111213062006200726302017101632758001B1B1B1B1A00612D
2019.01.04 22:08:10 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112131620062007263010176010445535908455359620621310B09014553591103234006010163560F00760B4553594D400601112132620062007263070177010B09014553591103234006080100620A7F7F00726201650005620674770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101633C3700760B4553594D40060111213362006200726302017101631426001B1B1B1B1A000646
2019.01.04 22:08:11 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112134620062007263010176010445535908455359620721340B09014553591103234006010163440100760B4553594D400601112135620062007263070177010B09014553591103234006080100620A7F7F00726201650005620774770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163284F00760B4553594D4006011121366200620072630201710163502D001B1B1B1B1A002C5F
2019.01.04 22:08:12 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112137620062007263010176010445535908455359620821370B090145535911032340060101633D1C00760B4553594D400601112138620062007263070177010B09014553591103234006080100620A7F7F00726201650005620874770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163601100760B4553594D40060111213962006200726302017101631C31001B1B1B1B1A003A76
2019.01.04 22:08:13 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111213A6200620072630101760104455359084553596209213A0B09014553591103234006010163613700760B4553594D40060111213B620062007263070177010B09014553591103234006080100620A7F7F00726201650005620974770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101635C4300760B4553594D40060111213C6200620072630201710163583A001B1B1B1B1A002A13
2019.01.04 22:08:14 5: SML-Parse 1B1B1B1B01010101760B4553594D40060111213D620062007263010176010445535908455359620A213D0B09014553591103234006010163190000760B4553594D40060111213E620062007263070177010B09014553591103234006080100620A7F7F00726201650005620A74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163093C00760B4553594D40060111213F62006200726302017101636B44001B1B1B1B1A001248
2019.01.04 22:08:15 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112140620062007263010176010445535908455359620B21400B09014553591103234006010163776E00760B4553594D400601112141620062007263070177010B09014553591103234006080100620A7F7F00726201650005620B74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E5203590000000000000045010101631E5300760B4553594D40060111214262006200726302017101634F2D001B1B1B1B1A005603
2019.01.04 22:08:16 5: SML-Parse 1B1B1B1B01010101760B4553594D400601112143620062007263010176010445535908455359620C21430B090145535911032340060101634A2300760B4553594D400601112144620062007263070177010B09014553591103234006080100620A7F7F00726201650005620C74770701014702037F010101010445535901770701000000097F010101010B0901455359110323400601770701000108007F6400000001621E5203590000000000000C0401770701000208007F6400000001621E520359000000000000004501010163700000760B4553594D4006011121456200620072630201710163290D001B1B1B1B1A006D03
und so weiter...
Schonmal vielen Dank vorab!
Gruß
Moritz
Ergänzung:
Ich sehe, dass die CRC-Fehler hochlaufen. Schaue ich mir das Signal vom IR-Lesekopf mit dem Logicanalyzer an, wird das 9600/7/E/1 aber sauber und richtig dekodiert. Auch die Start- und Stoppsequenzen 1B 1B 1B 1B stimmen immer.
Hi,
ich nutze Obis seit mehreren Wochen mit SML. Heute brauchte es wohl mein Fhem zum stillstand:
PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Anbei das List:
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FUUID 5c4f2794-f33f-a5c5-4b74-71084e19126a2e87
MeterType SML
NAME Haus.Strom
NR 209
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
1.0.36.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 25.41
1.0.56.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 377.1
1.0.76.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 53.02
Kosten:
logdb:
TIME 1548698664.00174
VALUE 533.21
Total:
logdb:
TIME 1548698800.56931
VALUE 1838.80657201
VerbrauchZeitraum:
logdb:
TIME 1548698800.56931
VALUE 1833.806
power:
logdb:
TIME 1548698800.56931
VALUE 455.53
statTotal:
logdb:
TIME 1548698800.56931
VALUE Hour: 0.05155741000001 Day: 4.70848022000030 Month: 161.83761771000039 Year: 161.83761771000039 (since: 2019-01-13 )
statTotalLast:
logdb:
TIME 1548698395.02574
VALUE Hour: 0.54433040000012 Day: 12.93388224999973 Month: - Year: -
total_consumption:
logdb:
TIME 1548698800.56931
VALUE 1838806.57201
total_consumption_Ch1:
logdb:
TIME 1548698800.56931
VALUE 1838806
READINGS:
..........
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1548691348.6034
_98_statistics myStatDevice
Channels:
DEVICES:
5
directions:
Attributes:
event-on-change-reading .*
interval 5
pollingMode on
room Gerät - Stromverbrauch,Raum - HWR
userReadings Total:total_consumption.* {ReadingsVal("Haus.Strom","total_consumption",0)/1000},
VerbrauchZeitraum:total_consumption_Ch1.* {ReadingsVal("Haus.Strom","total_consumption_Ch1",0)/1000-5},
Kosten:VerbrauchZeitraum.* { {sprintf("%.2f",ReadingsVal("Haus.Strom", "VerbrauchZeitraum", 0)*0.26+56.42);} },
Guthaben:total_consumption_Ch1.* {ReadingsVal("Haus.Strom","Guthaben",0)}
Könnte jemand den Fehler analysieren? Ich bin natürlich gern behilflich
Grüße
Hallo Zusammen,
ich habe 2 Zähler mit OBIS eingebunden.
Im Log bekomme ich:
2019.01.29 18:44:31 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2019.01.29 18:44:31 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2019.01.29 18:44:31 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2019.01.29 18:44:31 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
Ich finde aber nicht den Fehler. Hier ein List der beiden Devices.
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010670FA-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010670FA-if00-port0@9600,8,N,1
FUUID 5c472d1d-f33f-2776-8052-1bc32e870408dc57
MeterType SML
NAME Hausstrom
NR 148
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
DBLogging:
TIME 1548833292.4998
VALUE 122
statPowerDayLast:
DBLogging:
TIME 1548802795.47434
VALUE Min: -1933 Avg: -1 Max: 3163
statPowerHourLast:
DBLogging:
TIME 1548831595.40419
VALUE Min: 121 Avg: 364 Max: 1196
statTotal_consumption_Ch1:
DBLogging:
TIME 1548833292.4998
VALUE Hour: 107.7 Day: 1870.9 Month: 212508.6 Year: 212508.6
statTotal_consumption_Ch1Last:
DBLogging:
TIME 1548831595.40419
VALUE Hour: 317.8 Day: 4633.8 Month: 275656.9 Year: 1753928.0
statTotal_feed_Ch1Last:
DBLogging:
TIME 1548802795.47434
VALUE Hour: 0.0 Day: 4415.8 Month: 17653.2 Year: 5679435.9
total_consumption_Ch1:
DBLogging:
TIME 1548833292.4998
VALUE 2725632.9
READINGS:
2019-01-30 08:28:12 1.0.0.0.9.255 09-01-49-53-4B-00-04-1E-7A-24
2019-01-30 08:28:12 1.0.36.7.0.255 38
2019-01-30 08:28:12 1.0.56.7.0.255 60
2019-01-30 08:28:12 1.0.76.7.0.255 22
2019-01-30 08:28:12 129.129.199.130.3.255 ISK
2019-01-30 08:28:12 129.129.199.130.5.255 6CA0-0E72-F74F-2DD1-84B6-34B7-359F-3396-47CA-EFBA-A523-B9B4-BB61-773F-FA53-198B-7B2F-ED20-7206-A9F3-14A6-F1E5-01E1-1E7B-01
2019-01-30 08:28:12 EinkaufBisherigerTagesverbrauch 1.8709
2019-01-30 08:28:12 EinkaufStromZaehlerstand 2725.6329
2019-01-30 08:28:12 EinkaufVerbrauchLetzteStunde 317.8
2019-01-30 08:28:12 EinkaufVerbrauchLetzterTag 4.6338
2019-01-30 08:28:12 EinkaufbisherigerTagesverbrauchInEUR 0.486434
2019-01-30 08:28:12 VerkaufBisherigeTagesEinspeisung 0
2019-01-30 08:28:12 VerkaufBisherigeTageseinspeisungInEUR 0
2019-01-30 08:28:12 VerkaufEinspeisungLetzteStunde 0.0
2019-01-30 08:28:12 VerkaufEinspeisungLetzterTag 4.4158
2019-01-30 08:28:12 VerkaufStromZaehlerstand 6509.6813
2019-01-25 17:03:58 Version ISK\090149534B00041E7A24
2019-01-30 08:28:12 power 122
2019-01-30 08:28:12 statPowerDay Min: 120 Avg: 237 Max: 1196
2019-01-29 23:59:55 statPowerDayLast Min: -1933 Avg: -1 Max: 3163
2019-01-30 08:28:12 statPowerHour Min: 122 Avg: 265 Max: 479
2019-01-30 07:59:55 statPowerHourLast Min: 121 Avg: 364 Max: 1196
2019-01-30 08:28:12 statPowerMonth Min: -2067 Avg: 257 Max: 6465
2018-12-31 23:59:55 statPowerMonthLast Min: -1521 Avg: 346 Max: 8413
2019-01-30 08:28:12 statPowerYear Min: -2067 Avg: 257 Max: 6465
2018-12-31 23:59:55 statPowerYearLast Min: -6384 Avg: -779 Max: 8413
2019-01-30 08:28:12 statTotal_consumption_Ch1 Hour: 107.7 Day: 1870.9 Month: 212508.6 Year: 212508.6
2019-01-30 07:59:55 statTotal_consumption_Ch1Last Hour: 317.8 Day: 4633.8 Month: 275656.9 Year: 1753928.0
2019-01-30 08:28:12 statTotal_feed_Ch1 Hour: 0.0 Day: 0.0 Month: 30658.3 Year: 30658.3
2019-01-30 07:59:55 statTotal_feed_Ch1Last Hour: 0.0 Day: 4415.8 Month: 17653.2 Year: 5679435.9
2019-01-29 17:12:40 state opened
2019-01-30 08:28:12 total_consumption 2725632.9
2019-01-30 08:28:12 total_consumption_Ch1 2725632.9
2019-01-30 08:28:12 total_consumption_Ch2 0
2019-01-30 08:28:12 total_feed 6509681.3
2019-01-30 08:28:12 total_feed_Ch1 6509681.3
2019-01-30 08:28:12 total_feed_Ch2 0
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1548778360.56674
_98_statistics Statistik
Channels:
DEVICES:
300
directions:
Attributes:
DbLogInclude power|statTotal_consumption_Ch1Last|statTotal_consumption_Ch1|statPowerDayLast|statPowerHourLast|total_consumption_Ch1|total_feed_Ch1|statTotal_feed_Ch1Last
event-on-change-reading .*
interval 300
pollingMode on
userReadings EinkaufBisherigerTagesverbrauch { my @Verbrauch = split ' ',ReadingsVal("Hausstrom","statTotal_consumption_Ch1",0);;$Verbrauch[3]/1000},
EinkaufVerbrauchLetzteStunde { my @STDVerbrauch = split ' ',ReadingsVal("Hausstrom","statTotal_consumption_Ch1Last",0);;$STDVerbrauch[1]},
EinkaufVerbrauchLetzterTag { my @TagVerbrauch = split ' ',ReadingsVal("Hausstrom","statTotal_consumption_Ch1Last",0);;$TagVerbrauch[3]/1000},
EinkaufbisherigerTagesverbrauchInEUR { my @EURVerbrauch = split ' ',ReadingsVal("Hausstrom","statTotal_consumption_Ch1",0);;$EURVerbrauch[3]/1000*0.26},
EinkaufStromZaehlerstand { my @EinkaufStromZaehlerstand = split ' ',ReadingsVal("Hausstrom","total_consumption_Ch1",0);;$EinkaufStromZaehlerstand[0]/1000},
VerkaufBisherigeTagesEinspeisung { my @Einspeisung = split ' ',ReadingsVal("Hausstrom","statTotal_feed_Ch1",0);;$Einspeisung[3]/1000},
VerkaufEinspeisungLetzteStunde { my @STDEinspeisung = split ' ',ReadingsVal("Hausstrom","statTotal_feed_Ch1Last",0);;$STDEinspeisung[1]},
VerkaufEinspeisungLetzterTag { my @TagEinspeisung = split ' ',ReadingsVal("Hausstrom","statTotal_feed_Ch1Last",0);;$TagEinspeisung[3]/1000},
VerkaufBisherigeTageseinspeisungInEUR { my @EUREinspeisung = split ' ',ReadingsVal("Hausstrom","statTotal_feed_Ch1",0);;$EUREinspeisung[3]/1000*0.122},
VerkaufStromZaehlerstand { my @VerkaufStromZaehlerstand = split ' ',ReadingsVal("Hausstrom","total_feed_Ch1",0);;$VerkaufStromZaehlerstand[0]/1000}
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01064D97-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01064D97-if00-port0@9600,8,N,1
FUUID 5c472d11-f33f-2776-0674-7de264363a807391
MeterType SML
NAME Waermepumpe
NR 25
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
DBLogging:
TIME 1548833328.4677
VALUE 79
statPowerDayLast:
DBLogging:
TIME 1548802795.62817
VALUE Min: 17 Avg: 1240 Max: 8416
statPowerHourLast:
DBLogging:
TIME 1548831595.56153
VALUE Min: 79 Avg: 1183 Max: 2501
statTotal_consumption_Ch1:
DBLogging:
TIME 1548833328.4677
VALUE Hour: 546.3 Day: 9114.0 Month: 745239.4 Year: 745239.4
statTotal_consumption_Ch1Last:
DBLogging:
TIME 1548831595.56153
VALUE Hour: 1169.5 Day: 29050.1 Month: 563048.8 Year: 3738205.4
total_consumption_Ch1:
DBLogging:
TIME 1548833328.4677
VALUE 83657062.9
READINGS:
2018-12-16 06:15:50 0.0.0.0.27.255 0
2017-01-10 18:24:59 0.118.5.20.110.255 0
2019-01-30 08:28:48 1.0.0.0.0.255 08-05-0E-42-2D-4C-90-A3
2019-01-30 08:28:48 1.0.96.5.5.255 128
2019-01-30 08:28:48 129.129.199.130.3.255 ISKRA
2018-03-27 06:48:27 130.214.32.6.32.255 0
2018-03-27 06:56:29 158.54.32.6.32.255 0
2018-03-27 07:00:27 171.182.32.6.32.255 0
2019-01-30 08:28:48 HeizungZaehlerstand 83657.0629
2019-01-30 08:28:48 VerbrauchLetzteStunde 1169.5
2019-01-30 08:28:48 VerbrauchLetzterTag 29.0501
2017-01-09 19:50:51 Version ISKRA\08050E422D4C90A3
2019-01-30 08:28:48 bisherigerTagesverbrauch 9.114
2019-01-30 08:28:48 bisherigerTagesverbrauchInEUR 1.540266
2018-01-18 11:21:13 dir_total_consumption in
2019-01-30 08:28:48 power 79
2019-01-30 08:28:48 statPowerDay Min: 79 Avg: 1040 Max: 3001
2019-01-29 23:59:55 statPowerDayLast Min: 17 Avg: 1240 Max: 8416
2019-01-30 08:28:48 statPowerHour Min: 79 Avg: 1025 Max: 2501
2019-01-30 07:59:55 statPowerHourLast Min: 79 Avg: 1183 Max: 2501
2019-01-30 08:28:48 statPowerMonth Min: 16 Avg: 1062 Max: 9455
2018-12-31 23:59:55 statPowerMonthLast Min: 15 Avg: 753 Max: 9932
2019-01-30 08:28:48 statPowerYear Min: 16 Avg: 1062 Max: 9455
2018-12-31 23:59:55 statPowerYearLast Min: 0 Avg: 411 Max: 9932
2019-01-30 08:28:48 statTotal_consumption_Ch1 Hour: 546.3 Day: 9114.0 Month: 745239.4 Year: 745239.4
2019-01-30 07:59:55 statTotal_consumption_Ch1Last Hour: 1169.5 Day: 29050.1 Month: 563048.8 Year: 3738205.4
2019-01-29 17:12:28 state opened
2019-01-30 08:28:48 total_consumption_Ch1 83657062.9
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1548778348.12169
_98_statistics Statistik
Channels:
DEVICES:
240
directions:
Attributes:
DbLogInclude power|statTotal_consumption_Ch1Last|statTotal_consumption_Ch1|statPowerDayLast|statPowerHourLast|total_consumption_Ch1|total_feed_Ch1|statTotal_feed_Ch1Last
interval 240
pollingMode on
userReadings bisherigerTagesverbrauch { my @Verbrauch = split ' ',ReadingsVal("Waermepumpe","statTotal_consumption_Ch1",0);$Verbrauch[3]/1000},
VerbrauchLetzteStunde { my @STDVerbrauch = split ' ',ReadingsVal("Waermepumpe","statTotal_consumption_Ch1Last",0);$STDVerbrauch[1]},
VerbrauchLetzterTag { my @TagVerbrauch = split ' ',ReadingsVal("Waermepumpe","statTotal_consumption_Ch1Last",0);$TagVerbrauch[3]/1000},
bisherigerTagesverbrauchInEUR { my @EURVerbrauch = split ' ',ReadingsVal("Waermepumpe","statTotal_consumption_Ch1",0);$EURVerbrauch[3]/1000*0.169},
HeizungZaehlerstand { my @HeizungZaehlerstand = split ' ',ReadingsVal("Waermepumpe","total_consumption_Ch1",0);$HeizungZaehlerstand [0]/1000}
Könnte mir jemand auf die Sprünge helfen?
Danke Euch
Zitat von: eisenhauer1987 am 28 Januar 2019, 19:08:15
Hi,
ich nutze Obis seit mehreren Wochen mit SML. Heute brauchte es wohl mein Fhem zum stillstand:
PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Anbei das List:
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FUUID 5c4f2794-f33f-a5c5-4b74-71084e19126a2e87
MeterType SML
NAME Haus.Strom
NR 209
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
1.0.36.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 25.41
1.0.56.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 377.1
1.0.76.7.0.255:
logdb:
TIME 1548698800.56931
VALUE 53.02
Kosten:
logdb:
TIME 1548698664.00174
VALUE 533.21
Total:
logdb:
TIME 1548698800.56931
VALUE 1838.80657201
VerbrauchZeitraum:
logdb:
TIME 1548698800.56931
VALUE 1833.806
power:
logdb:
TIME 1548698800.56931
VALUE 455.53
statTotal:
logdb:
TIME 1548698800.56931
VALUE Hour: 0.05155741000001 Day: 4.70848022000030 Month: 161.83761771000039 Year: 161.83761771000039 (since: 2019-01-13 )
statTotalLast:
logdb:
TIME 1548698395.02574
VALUE Hour: 0.54433040000012 Day: 12.93388224999973 Month: - Year: -
total_consumption:
logdb:
TIME 1548698800.56931
VALUE 1838806.57201
total_consumption_Ch1:
logdb:
TIME 1548698800.56931
VALUE 1838806
READINGS:
..........
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1548691348.6034
_98_statistics myStatDevice
Channels:
DEVICES:
5
directions:
Attributes:
event-on-change-reading .*
interval 5
pollingMode on
room Gerät - Stromverbrauch,Raum - HWR
userReadings Total:total_consumption.* {ReadingsVal("Haus.Strom","total_consumption",0)/1000},
VerbrauchZeitraum:total_consumption_Ch1.* {ReadingsVal("Haus.Strom","total_consumption_Ch1",0)/1000-5},
Kosten:VerbrauchZeitraum.* { {sprintf("%.2f",ReadingsVal("Haus.Strom", "VerbrauchZeitraum", 0)*0.26+56.42);} },
Guthaben:total_consumption_Ch1.* {ReadingsVal("Haus.Strom","Guthaben",0)}
Könnte jemand den Fehler analysieren? Ich bin natürlich gern behilflich
Grüße
Hi,
ich hatte jetzt zum dritten Mal einen Stillstand von Shem durch diesen Fehler. Die Umwandlung von großen Hexadezimalzahlen scheint fehlzuschlagen. Könnte das jemand im Quellcode überprüfen und eventuell verbessern?
Grüße
Hallo zusammen,
ich habe genau das gleiche Problem, das mein FHEM auf raspi zum Absturz bringt:
2019.02.09 17:06:02 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 794.
2019.02.09 17:06:02 1: PERL WARNING: Use of uninitialized value $msg in substr at ./FHEM/47_OBIS.pm line 796.
2019.02.10 02:47:44 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Da scheint er mit einigen Werten nicht zu recht zu kommen.
Hallo,
Bei mir das Gleiche 1 - 3x pro Woche ein hänger
https://forum.fhem.de/index.php/topic,96934.0.html (https://forum.fhem.de/index.php/topic,96934.0.html)
Hab mal einen fix eingespielt, sollte ab morgen übers Update kommen.
lg, Stefan
Hallo @Icinger
Seit dem Fix habe ich auf meinem EMH Zähler mit SML nur noch 1 - 2Watt bei power bzw. feed_L1 :o
Was ist da passiert?
Zähler1
2019-02-12_13:51:15 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_13:51:15 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_13:51:15 powerzaehler total_consumption_Ch1: 59318734.4
2019-02-12_13:51:15 powerzaehler total_feed_Ch1: 36177158.6
2019-02-12_13:51:15 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_13:51:15 powerzaehler power: 0
2019-02-12_13:51:15 powerzaehler feed_L1: 738.8
2019-02-12_13:51:45 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_13:51:45 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_13:51:45 powerzaehler total_consumption_Ch1: 59318734.4
2019-02-12_13:51:45 powerzaehler total_feed_Ch1: 36177163.1
2019-02-12_13:51:45 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_13:51:45 powerzaehler power: 0
2019-02-12_13:51:45 powerzaehler feed_L1: 584.8
2019-02-12_13:52:45 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_13:52:45 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_13:52:45 powerzaehler total_consumption_Ch1: 59318734.4
2019-02-12_13:52:45 powerzaehler total_feed_Ch1: 36177171.4
2019-02-12_13:52:45 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_13:52:45 powerzaehler power: 0
2019-02-12_13:52:45 powerzaehler feed_L1: 472.7
2019-02-12_13:55:01 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_13:55:01 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_13:55:01 powerzaehler total_consumption_Ch1: 5.93187344
2019-02-12_13:55:01 powerzaehler total_feed_Ch1: 3.61779625
2019-02-12_13:55:01 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_13:55:01 powerzaehler power: 0
2019-02-12_13:55:01 powerzaehler feed_L1: 5.049
2019-02-12_14:03:07 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_14:03:07 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_14:03:07 powerzaehler total_consumption_Ch1: 5.93187344
2019-02-12_14:03:07 powerzaehler total_feed_Ch1: 3.61779647
2019-02-12_14:03:07 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_14:03:07 powerzaehler power: 0
2019-02-12_14:03:07 powerzaehler feed_L1: 4.86
2019-02-12_14:03:37 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_14:03:37 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_14:03:37 powerzaehler total_consumption_Ch1: 5.93187344
2019-02-12_14:03:37 powerzaehler total_feed_Ch1: 3.61779657
2019-02-12_14:03:37 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_14:03:37 powerzaehler power: 0
2019-02-12_14:03:37 powerzaehler feed_L1: 4.908
2019-02-12_14:04:07 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_14:04:07 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_14:04:07 powerzaehler total_consumption_Ch1: 5.93187344
2019-02-12_14:04:07 powerzaehler total_feed_Ch1: 3.61779671
2019-02-12_14:04:07 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_14:04:07 powerzaehler power: 0
2019-02-12_14:04:07 powerzaehler feed_L1: 4.917
2019-02-12_14:04:37 powerzaehler 129.129.199.130.3.255: EMH
2019-02-12_14:04:37 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-12_14:04:37 powerzaehler total_consumption_Ch1: 5.93187344
2019-02-12_14:04:37 powerzaehler total_feed_Ch1: 3.61779681
2019-02-12_14:04:37 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-12_14:04:37 powerzaehler power: 0
2019-02-12_14:04:37 powerzaehler feed_L1: 4.903
Zähler2
2019-02-12_14:00:29 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_14:00:29 powerzaehler_solar total_feed_Ch1: 57396788.1
2019-02-12_14:00:29 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_14:00:29 powerzaehler_solar feed_L1: 1095.8
2019-02-12_14:00:59 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_14:00:59 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_14:00:59 powerzaehler_solar total_feed_Ch1: 57396797.1
2019-02-12_14:00:59 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_14:00:59 powerzaehler_solar feed_L1: 1078.1
2019-02-12_14:01:29 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_14:01:29 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_14:01:29 powerzaehler_solar total_feed_Ch1: 57396805.9
2019-02-12_14:01:29 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_14:01:29 powerzaehler_solar feed_L1: 1070.6
2019-02-12_13:33:20 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_13:33:20 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_13:33:20 powerzaehler_solar total_feed_Ch1: 5.73968247
2019-02-12_13:33:20 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_13:33:20 powerzaehler_solar feed_L1: 1.0482
2019-02-12_13:33:50 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_13:33:50 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_13:33:50 powerzaehler_solar total_feed_Ch1: 5.73968334
2019-02-12_13:33:50 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_13:33:50 powerzaehler_solar feed_L1: 1.0416
2019-02-12_14:03:11 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_14:03:11 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_14:03:11 powerzaehler_solar total_feed_Ch1: 5.73968358
2019-02-12_14:03:11 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_14:03:11 powerzaehler_solar feed_L1: 1.0366
2019-02-12_14:03:41 powerzaehler_solar 129.129.199.130.3.255: EMH
2019-02-12_14:03:41 powerzaehler_solar 1.0.0.0.0.255: 31-39-30-30-30-30-30-31-38-
2019-02-12_14:03:41 powerzaehler_solar total_feed_Ch1: 5.73968444
2019-02-12_14:03:41 powerzaehler_solar 0.0.96.1.255.255: 2148705
2019-02-12_14:03:41 powerzaehler_solar feed_L1: 1.0315
Bei mir ist ebenfalls jetzt die Einheit beim aktuellen Verbrauch falsch, statt 290W werden 2.9W angezeigt.
Bei mir auch. Und wenn man die Einheiten anzeigen lässt, wird der Messwert in Exponentialdarstellung angezeigt.
Gruß
Raymund
Dann bin ich ja nicht er einzige, ich dacht schon ich spinne, wenn mein verbrauch so wäre, wäre ich zufrieden :o ;D
Heute Morgen ein Update gemacht und meine Zählerstände stimmen nicht mehr.
total_consumption und total_feed
Kommastellen haben sich um 3 Stellen verschoben.
Wäre toll wenn das schnell wieder gefixt werden könnte.
Bis der Fix da ist, könntet ihr doch eure PM einfach aus dem Restore-Verzeichnis zurückholen.
https://svn.fhem.de/trac/changeset/18560/
Hallo, ich hab den Fix auch eingespielt (danke dafür) und ich hab bisher auch keinen Ausfall mehr und bei mir wird power noch korrekt angezeigt. Nur total_consumption ist um 6 Stellen verrutscht.
power 2168 2019-02-13 19:21:00
state opened 2019-02-13 19:18:12
total_consumption 3.6376053 2019-02-13 19:21:00
power mit 2168 Watt passt. Aber total_consumption nicht.
Zitatbei power bzw. feed_L1
ZitatMesswert in Exponentialdarstellung angezeigt
Zitattotal_consumption und total_feed
ZitatNur total_consumption ist um 6 Stellen verrutscht.
Hmm, das ist aber extrem mysteriös jetzt, das einzige, was ich geändert habe, ist die betreffende Zeile
$scaler=$scaler ne "" ? 10**unpack("c", pack("C", hex($scaler))) : 1;auf
$scaler=$scaler ne "" ? 10**unpack("l", pack("L", hex($scaler))) : 1;geändert.
Also von 8 bit
Zitatc A signed char (8-bit) value.
C An unsigned char (octet) value.
auf long geändert
Zitatl A signed long (32-bit) value.
L An unsigned long value.
**facepalm** Eigentlich sollte es ja
Zitati A signed integer value.
I A unsigned integer value.
sein, merke ich gerade.
Könnt ihr das bitte mal testen? Einfach die Zeile auf
$scaler=$scaler ne "" ? 10**unpack("i", pack("I", hex($scaler))) : 1;tauschen und dann ein
reload 47_Obis[/quote] machen?
lg, Stefan
Hallo,
Keine änderung
mit
$scaler=$scaler ne "" ? 10**unpack("c", pack("C", hex($scaler))) : 1;
läuft es
2019-02-13_23:01:53 powerzaehler 129.129.199.130.3.255: EMH
2019-02-13_23:01:53 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-13_23:01:53 powerzaehler total_consumption_Ch1: 5.93459516
2019-02-13_23:01:53 powerzaehler total_feed_Ch1: 3.61900506
2019-02-13_23:01:53 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-13_23:01:53 powerzaehler power: 1.588
2019-02-13_23:01:53 powerzaehler feed_L1: 0
2019-02-13_23:02:14 powerzaehler 129.129.199.130.3.255: EMH
2019-02-13_23:02:14 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-13_23:02:14 powerzaehler total_consumption_Ch1: 5.9345978
2019-02-13_23:02:14 powerzaehler total_feed_Ch1: 3.61900506
2019-02-13_23:02:14 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-13_23:02:14 powerzaehler power: 1.5858
2019-02-13_23:02:14 powerzaehler feed_L1: 0
2019-02-13_23:02:54 powerzaehler 129.129.199.130.3.255: EMH
2019-02-13_23:02:54 powerzaehler 1.0.0.0.0.255: 31-39-30-30-30-30-30-33-34-
2019-02-13_23:02:54 powerzaehler total_consumption_Ch1: 5.93459882
2019-02-13_23:02:54 powerzaehler total_feed_Ch1: 3.61900506
2019-02-13_23:02:54 powerzaehler 0.0.96.1.255.255: 2266198
2019-02-13_23:02:54 powerzaehler power: 1.588
2019-02-13_23:02:54 powerzaehler feed_L1: 0
Ich hab den Patch jetzt mal rückgängig gemacht.
Solange ich keine SML-Daten von dem Absturz habe, kann ich nichts testen.
lg, Stefan
Hi,
erklär mal bitte wie wir dir helfen können? Du brauchst also die ausgelesenen Daten direkt zu Absturzzeitpunkt? Wie kann ich dir die liefen? Bringt loglevel 5 hier was?
Grüße
Ja, Verbose auf 5 setzen in dem OBIS-Device
Dann bräuchte ich die letzte
2016.04.23 23:33:44 3: Telegram=77078181C78205FF0172620165000491CF01018302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C21401010163A8A1007607000B000BC77C6200620072630201710163E87300000000
Zeile vor dem Absturz.
Hab heute das aktuelle über Update installiert.
Nun stimmen die Werte bei mir wieder.
Gruß Robert
Gesendet von iPhone mit Tapatalk Pro
Dito
Werte stimmen wieder
Gruß
Sebastian
Hallo,
Die Werte stimmen vielleicht ....... vielleicht auch nicht. Ich habe manchmal Verbrauchswerte die dank einiger Nachgeschalteter Zähler nicht stimmen können, z.B. wenn die nachgeschalteten Zähler zusammen ca. 800W ergeben und der Hauptzähler 3600W hat, dann stimmt da was nicht. Oder wenn ich auf dem Zähler sehe das Strom eingespeist wird, und OBIS aber Werte liefert das ich Strom beziehen würde, muss ich auch sagen das da was nicht stimmt :o
Es kann ja wohl auch nicht sein das ich mehr Strom einspeise als ich produziere oder? :o
...dann musst du den OBIS-Wert mal mit der Anzeige auf deinem Zähler vergleichen, stimmt das denn überein ? Evtl hat der Zähler ja eine Macke. Interessant wäre sicher auch, ob das Phänomen neu ist oder auch mit früheren Versionen des Moduls auftritt ?
Wie immer: Bitte Datenpakete.
Theoretisch kann das nicht sein, weil das OBIS-Modul keine Berechnungen vornimmt, sondern nur das Datenpaket auseinanderklabustert und aus den darin enthaltenen Werten Readings erzeugt.
Praktisch will ichs aber auch nicht ausschließen.
lg, Stefan
Wie komme ich an die Datenpakete?
Habe mich auch gefragt ob Lichteinfall das Problem sein könnte?! :o ::)
attr deinObismodul verbose 5
Hallo,
Habe da was entdeckt heute, da kommt ja keine "Telegram" :-\
2019.02.21 09:02:47 5: OBIS (powerzaehler) - Internal timer set to 2019-02-21 09:03:17
2019.02.21 09:02:57 5: SML-Parse 1B1B1B1B0101011B1B1B1B01010101760701140001EF5762006200726301017601010701141093A51D0D313930303030303334303835010163DE0600760701140001EF58620062007263070177010D3139303030303033343038350172620165109346727777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC4F0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000078F0177070100020700FF0101621B52FF550000000001010163AF8C00760701140001EF5962006200726302017101638910000000001B1B1B1B1A037921
2019.02.21 09:03:07 5: SML-Parse 1B1B1B1B01010101760701140001EF5A62006200726301017601010701141093A51E0D3139303030303033343038350101638D1C00760701140001EF5B620062007263070177010D3139303030303033343038350172620165109346747777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC500177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000736017707011B1B1B1B01010101760701140001EF6062006200726301017601010701141093A5200D3139303030303033343038350101636CF900760701140001EF61620062007263070177010D3139303030303033343038350172620165109346787777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC520177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000007F10177070100020700FF0101621B52FF550000000001010163A90200760701140001EF6262006200726302017101635FC1000000001B1B1B1B1A03BECB
2019.02.21 09:03:17 5: SML-Parse 1B1B1B1B01010101760701140001EF6362006200726301017601010701141093A5210D3139303030303033343038350101631B8500760701140001EF64620062007263070177010D31393030303030333430383501726201651093467A7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC530177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000715017707011B1B1B1B01010101760701140001EF6F62006200726301017601010701141093A5250D313930303030303334303835010163D67C00760701140001EF70620062007263070177010D3139303030303033343038350172620165109346827777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC570177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000006ED0177070100020700FF0101621B52FF550000000001010163F94000760701140001EF716200620072630201710163A94E000000001B1B1B1B1A034D86
2019.02.21 09:03:17 5: SW:
2019.02.21 09:03:17 4: Wrote
2019.02.21 09:03:17 5: OBIS (powerzaehler) - Internal timer set to 2019-02-21 09:03:47
2019.02.21 09:03:27 5: SML-Parse 1B1B1B1B01010101760701140001EF7262006200726301017601010701141093A5260D313930303030303334303835010163005300760701140001EF73620062007263070177010D3139303030303033343038350172620165109346857777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC580177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000668017707011B1B1B1B01010101760701140001EF7B62006200726301017601010701141093A5290D313930303030303334303835010163907E00760701140001EF7C620062007263070177010D31393030303030333430383501726201651093468B7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC5B0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000006200177070100020700FF0101621B52FF5500000000010101632B5A00760701140001EF7D620062007263020171016356AC000000001B1B1B1B1A03EB43
2019.02.21 09:03:37 5: SML-Parse 1B1B1B1B01010101760701140001EF7E62006200726301017601010701141093A52A0D31393030303030333430383501016309FA00760701140001EF7F620062007263070177010D31393030303030333430383501726201651093468E7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC5C0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000628017707011B1B1B1B01010101760701140001EF8162006200726301017601010701141093A52B0D313930303030303334303835010163737B00760701140001EF82620062007263070177010D3139303030303033343038350172620165109346907777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC5D0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000063A0177070100020700FF0101621B52FF550000000001010163E04C00760701140001EF8362006200726302017101635A29000000001B1B1B1B1A034EC4
2019.02.21 09:03:47 5: SML-Parse 1B1B1B1B01010101760701140001EF8462006200726301017601010701141093A52C0D31393030303030333430383501016388D700760701140001EF85620062007263070177010D3139303030303033343038350172620165109346927777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC5E0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000628017707011B1B1B1B01010101760701140001EF9062006200726301017601010701141093A5300D313930303030303334303835010163467400760701140001EF91620062007263070177010D31393030303030333430383501726201651093469C7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC620177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000005C90177070100020700FF0101621B52FF55000000000101016306FB00760701140001EF9262006200726302017101638E0D000000001B1B1B1B1A035EA5
2019.02.21 09:03:47 5: SW:
2019.02.21 09:03:47 4: Wrote
2019.02.21 09:03:47 5: OBIS (powerzaehler) - Internal timer set to 2019-02-21 09:04:17
2019.02.21 09:03:52 5: SML-Parse 1B1B1B1B01010101760701140001EF9362006200726301017601010701141093A5310D313930303030303334303835010163310800760701140001EF94620062007263070177010D31393030303030333430383501726201651093469E7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC630177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000005D7017707011B1B1B1B01010101760701140001EF9C62006200726301017601010701141093A5340D3139303030303033343038350101638B8D00760701140001EF9D620062007263070177010D3139303030303033343038350172620165109346A57777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC660177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000005990177070100020700FF0101621B52FF550000000001010163040E00760701140001EF9E620062007263020171016371EF000000001B1B1B1B1A03EB6E
2019.02.21 09:04:02 5: SML-Parse 1B1B1B1B01010101760701140001EF9F62006200726301017601010701141093A5350D313930303030303334303835010163FCF100760701140001EFA0620062007263070177010D3139303030303033343038350172620165109346A87777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC670177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000578017707011B1B1B1B01010101760701140001EFA262006200726301017601010701141093A5360D31393030303030333430383501016320B500760701140001EFA3620062007263070177010D3139303030303033343038350172620165109346AA7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC680177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000005FB0177070100020700FF0101621B52FF550000000001010163B1A200760701140001EFA46200620072630201710163366B000000001B1B1B1B1A039558
2019.02.21 09:04:12 5: SML-Parse 1B1B1B1B01010101760701140001EFA562006200726301017601010701141093A5370D313930303030303334303835010163328600760701140001EFA6620062007263070177010D3139303030303033343038350172620165109346AD7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC690177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000591017707011B1B1B1B01010101760701140001EFAE62006200726301017601010701141093A53A0D313930303030303334303835010163291C00760701140001EFAF620062007263070177010D3139303030303033343038350172620165109346B47777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC6C0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000005AA0177070100020700FF0101621B52FF550000000001010163873700760701140001EFB062006200726302017101632644000000001B1B1B1B1A03B2F8
2019.02.21 09:04:17 5: SW:
2019.02.21 09:04:17 4: Wrote
2019.02.21 09:04:17 5: OBIS (powerzaehler) - Internal timer set to 2019-02-21 09:04:47
2019.02.21 09:04:22 5: SML-Parse 1B1B1B1B01010101760701140001EFB162006200726301017601010701141093A53B0D313930303030303334303835010163748400760701140001EFB2620062007263070177010D3139303030303033343038350172620165109346B77777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC6D0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000052C017707011B1B1B1B01010101760701140001EFB462006200726301017601010701141093A53C0D3139303030303033343038350101638F2800760701140001EFB5620062007263070177010D3139303030303033343038350172620165109346BA7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC6E0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000004DD0177070100020700FF0101621B52FF550000000001010163766A00760701140001EFB6620062007263020171016351B1000000001B1B1B1B1A03EFB8
2019.02.21 09:04:32 5: SML-Parse 1B1B1B1B01010101760701140001EFB762006200726301017601010701141093A53D0D313930303030303334303835010163F85400760701140001EFB8620062007263070177010D3139303030303033343038350172620165109346BD7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC6F0177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000474017707011B1B1B1B01010101760701140001EFBD62006200726301017601010701141093A53F0D313930303030303334303835010163B97D00760701140001EFBE620062007263070177010D3139303030303033343038350172620165109346C37777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC710177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000040F0177070100020700FF0101621B52FF550000000001010163FF8E00760701140001EFBF62006200726302017101636A58000000001B1B1B1B1A030364
2019.02.21 09:04:42 5: SML-Parse 1B1B1B1B01010101760701140001EFC062006200726301017601010701141093A5400D3139303030303033343038350101635CEB00760701140001EFC1620062007263070177010D3139303030303033343038350172620165109346C67777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC720177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000476017707011B1B1B1B01010101760701140001EFC662006200726301017601010701141093A5420D313930303030303334303835010163B21300760701140001EFC7620062007263070177010D3139303030303033343038350172620165109346CD7777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC740177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000048B0177070100020700FF0101621B52FF5500000000010101631AEC00760701140001EFC8620062007263020171016346A6000000001B1B1B1B1A03C8C0
2019.02.21 09:04:47 5: SML-Parse 1B1B1B1B01010101760701140001EFC962006200726301017601010701141093A5430D3139303030303033343038350101636ABE00760701140001EFCA620062007263070177010D3139303030303033343038350172620165109346D07777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC750177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500000414017707011B1B1B1B01010101760701140001EFCF62006200726301017601010701141093A5450D313930303030303334303835010163E66E00760701140001EFD0620062007263070177010D3139303030303033343038350172620165109346D77777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF56002374EC770177070100020801FF628201621E52FF560015A01D2301770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF550000039B0177070100020700FF0101621B52FF5500000000010101637CD200760701140001EFD16200620072630201710163383E000000001B1B1B1B1A03384B
2019.02.21 09:04:47 5: SW:
Hi,
heute ist der Fehler mit komplett Absturz von fhem und verbose 5 wieder aufgetreten.
2019.02.22 13:07:32 5: SW:
2019.02.22 13:07:32 4: Wrote
2019.02.22 13:07:32 5: OBIS (Haus.Strom) - Internal timer set to 2019-02-22 13:07:37
2019.02.22 13:07:33 5: SML-Parse 1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 5: OBIS: Full message-> 1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 5: OBIS: Telegram=1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Hallo,
Also irgendwie sind die Zählerwerte komisch.
Ich kann die Hardware tauschen verschiedene Linux Versionen und es passt nicht.
Wenn meine Solaranlage (Geeichter Zähler) mit OBIS mir einen Wert liefert das ich 2600W produziere, und der 2te Zähler für Lieferung/Produktion (geeichter Zähler) mir anzeigt das ich 2200W Liefere obwohl der Herd läuft, Spülmaschine und Waschmaschine, und mir ein Zwischenzähler ein Verbrauch von 1400W verstehe ich das nicht, den 2600 - 2200 = 400W für Herd, Spülmaschine und Waschmaschine, das ist schon ein Wunder oder?
Am Zähler selbst sehe ich aber das ich Strom beziehe und nicht liefere :o
Zitat von: Edi77 am 23 Februar 2019, 13:47:11
Hallo,
Also irgendwie sind die Zählerwerte komisch ...
Hallo,
Edi77 ist nicht alleine ;) Bei mir entsprechen die Daten (elektr. Leistung und Energie, nur Bezug) nach einem Fhem-Neustart denen am Zähler. Nach einer gewissen Zeit (Stunden) liegen sie um Faktoren daneben.
Ich verwende OBIS exklusiv auf einem Rpi2 mit aktuellem Fhem. Sonst läuft "nichts" auf diesem Rechner. Die Daten kommen von dem bekannten Volkszaehler IR-Schreib-Lesekopf mit USB-Interface (SML).
Hallo,
Wie bei mir, den bekannte Volkszaehler IR-Schreib-Lesekopf mit USB-Interface.
Habe schon geschaut den alten 70_SMLUSB.pm wieder in betriebt zu nehmen, aber leider bekomme ich da nur den Zählerstand, und nicht die Leistung, Durchschnittswerte usw.
Und nach ein paar Neustarts läuft es wieder. Also irgendwas muss doch da falsch laufen!!!
Eure Aussagen lassen sich so nicht nachvollziehen. ::) Wie Stefan schon schrieb, macht das Modul ja keine Berechnungen, sondern wertet nur empfangene Datenpakete aus. Ihr müsst also schon Datenreihen für die Fernanalyse liefern. Ansonsten ist bei 120+ funktionierenden Installationen eine Ferndiagnose unmöglich.
ZitatDurchschnittswerte
ist mir als OBIS-Wert nicht bekannt. Die kommen tatsächlich raw vom Zähler ? :-\
Ich hatte früher die Probleme, dass Daten tw. erst mit Zeitverzug ankamen.
@Edi77: log doch mal Leistung von Erzeugungszähler, 2R-Zähler und, wenn Du kannst, Wechselrichtererzeugung. Dann würde man in einem Plot einen Zeitversatz erkennen, aber auch sonst die zeitliche Ausprägung(plötzlich falsch, schleichend falscher.....)
(zum loggen in ein File eins der devices per userattr erweitern).
Zitat von: eisenhauer1987 am 22 Februar 2019, 14:59:59
Hi,
heute ist der Fehler mit komplett Absturz von fhem und verbose 5 wieder aufgetreten.
2019.02.22 13:07:32 5: SW:
2019.02.22 13:07:32 4: Wrote
2019.02.22 13:07:32 5: OBIS (Haus.Strom) - Internal timer set to 2019-02-22 13:07:37
2019.02.22 13:07:33 5: SML-Parse 1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 5: OBIS: Full message-> 1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 5: OBIS: Telegram=1B1B1B1B0101010176050A82B20F620062007265000001017601010765425A4444330B090145425A0100016D76010163801C0076050A82B2106200620072650000070177010B090145425A0100016D76017262016501C077077977078181C78203FF010101010445425A0177070100000009FF010101010B090145425A0100016D760177070100010800FF6401018001621E52FB6900000030C0934E2E0177070100010801FF0101621E520065001FF3450177070100010802FF0101621E520065000000000177070100100700FF0101621B52FE550000A4170177070100240700FF0101621B52FE5500002E2E0177070100380700FF0101621B52FE550000227F01770701004C0700FF0101621B52FE550000536A010101630A130076050A82B21162006200726500000201710163BE820000001B1B1B1B1A02784E
2019.02.22 13:07:33 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Also bei mir stimmen die Werte von Obis mit dehnen vom Zähler. Aber halt der Absturz beim o.g. Telegram. Kann das jemand checken?
Grüße
Hallo
Produktionszähler
2019.02.24 14:30:11 4: Connection closed for WEB_192.168.1.20_56441: EOF
2019.02.24 14:30:11 5: SML-Parse 1B1B1B1B01010101760701E800D28C7662006200726301017601010701E8108C2ED20D3139303030303031383631340101635FE100760701E800D28C77620062007263070177010D3139303030303031383631340172620165108CFE5F7577078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303031383631340177070100020801FF628001621E52FF5600225502E801770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Full message-> 1B1B1B1B01010101760701E800D28C7662006200726301017601010701E8108C2ED20D3139303030303031383631340101635FE100760701E800D28C77620062007263070177010D3139303030303031383631340172620165108CFE5F7577078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303031383631340177070100020801FF628001621E52FF5600225502E801770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Telegram=1B1B1B1B01010101760701E800D28C7662006200726301017601010701E8108C2ED20D3139303030303031383631340101635FE100760701E800D28C77620062007263070177010D3139303030303031383631340172620165108CFE5F7577078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303031383631340177070100020801FF628001621E52FF5600225502E801770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Telegram=0177070100000000FF010101010D3139303030303031383631340177070100020801FF628001621E52FF5600225502E801770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Telegram=0177070100020801FF628001621E52FF5600225502E801770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Telegram=01770700006001FFFF010101010B303030323134383730350177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 5: OBIS: Telegram=0177070100020700FF0101621B52FF550000269E01010163648F00760701E800D28C786200620072630201710163499F00001B1B1B1B1A01752A
2019.02.24 14:30:11 4: MSG IS:
/EMH\313930303030303138363134
129-129:199.130.3*255(EMH)
1-0:0.0.0*255(313930303030303138363134)
1-0:2.8.1*255(57599664.8*Wh)
0-0:96.1.255*255(0002148705)
1-0:2.7.0*255(988.6*W)
!
Liefer/Bezugszähler
2019.02.24 14:30:26 5: SML-Parse 1B1B1B1B010101017607012000003FF36200620072630101760101070120109715510D3139303030303033343038350101633234007607012000003FF4620062007263070177010D313930303030303334303835017262016510978B807777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600237E52200177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Full message-> 1B1B1B1B010101017607012000003FF36200620072630101760101070120109715510D3139303030303033343038350101633234007607012000003FF4620062007263070177010D313930303030303334303835017262016510978B807777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600237E52200177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=1B1B1B1B010101017607012000003FF36200620072630101760101070120109715510D3139303030303033343038350101633234007607012000003FF4620062007263070177010D313930303030303334303835017262016510978B807777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600237E52200177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=0177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600237E52200177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=0177070100010801FF628201621E52FF5600237E52200177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=0177070100020801FF628201621E52FF560015A7B4AF01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=0177070100010700FF0101621B52FF55000000000177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 5: OBIS: Telegram=0177070100020700FF0101621B52FF5500001F8D01010163F9A5007607012000003FF56200620072630201710163B6AC000000001B1B1B1B1A03BC11
2019.02.24 14:30:26 4: MSG IS:
/EMH\313930303030303334303835
129-129:199.130.3*255(EMH)
1-0:0.0.0*255(313930303030303334303835)
1-0:1.8.1*255(>59548112*Wh)
1-0:2.8.1*255(>36331230.3*Wh)
0-0:96.1.255*255(0002266198)
1-0:1.7.0*255(0*W)
1-0:2.7.0*255(807.7*W)
USV
state active 2019-02-24 14:33:17
ups.load 35.5 2019-02-24 14:32:27
ups.power 710 2019-02-24 14:32:27
ups.realpower 570 2019-02-24 14:32:27
Also ich produziere 988W ich liefere 807W also wäre mein Eigenverbrauch (988 - 807 =181W ) 181W!!!
Wie kann es dann sein das alleine meine USV schon 570W bezieht??? :o
Zitat von: Edi77 am 23 Februar 2019, 13:47:11
Hallo,
Also irgendwie sind die Zählerwerte komisch ...
Also, ich habe weiter geforscht (siehe Post von vorgestern): meine Probleme mit falschen Powerwerten treten nach ca. 1 h nur im PollingMode auf. Im "LoopingModus" stimmen sie. Allerdings braucht Fhem (perl) dann ca. 19% CPU. Ansonsten ca. 0,5% ! Trotz gesetzten event-min-interval-Attributes im Übrigen. Mit SMLUSB braucht Fhem nur ca. 9% CPU und liefert mir zuverlässig dasselbe Ergebnis. Das ist für mich OK so.
Ich gehe mal davon aus das wenn du pollingMode off machst somit der loopingModus aktiv wird?
SMLUSB liefert dir auch den Momentanen verbraucht? Bei mir nicht.
19% CPU Last auf was für einer CPU?
Da ich ja für jeden Zähler einen separaten Orange Pi One mit Allwinder H3 am laufen habe ist die CPU last schon etwas gestiegen, von meistens fast nichts auf 5 - 15% im Mittel 10%.
Hallo Edi77,
ich habe immer noch den Rpi2 im Einsatz, wie vorgestern geschrieben ;-) OBIS verwendet DevIo, d.h. wenn der PollingMode aus ist, dann geht das wohl lt. Doku so:
ZitatIn der zentralen Schleife (Main-Loop) von fhem.pl wird mit select() überwacht, ob über eine der geöffneten Schnittstellen Daten zum Lesen anstehen. Wenn dies der Fall ist, dann wird die Lesefunktion (X_Read) des zuständigen Moduls aufgerufen, damit es die Daten entgegennimmt und verarbeitet.
https://wiki.fhem.de/wiki/DevelopmentModuleIntro (https://wiki.fhem.de/wiki/DevelopmentModuleIntro). Und das passiert beim "Volkszaehler" im Sekundentakt. Daher die CPU-Belastung.
Und ja: ich bekomme von SMLUSB sowohl die elektr. Leistung (power) als auch die Energie (total_consumption). Die Energie reicht mir eigentlich für meine täglichen Statistiken. Daher bevorzuge ich auch den PollingMode. Ich werde nochmal nachsehen, ob sowas wie der PollingMode auch im SMLUSB-Modul geht. Nach erstem "Drüberschauen" nicht. Dann würde ich versuchen, das "nachzurüsten". Dazu muss man sich ja nicht in die SML-Thematik einarbeiten ;D
Wohl gemerkt: das ist mein Privatvergnügen und soll nicht in Konkurrenz zu OBIS betrachtet werden.
Erstaunlich das du auch die Power Werte bekommst.
Von welchem Hersteller sind deine Stromzähler?
19% Last bei RPi2 kann ich dann auch verstehen.
Stromzähler ist ein ITRON OpenWay 3.HZ
Zitat von: Raymund am 25 Februar 2019, 13:03:28
Und das passiert beim "Volkszaehler" im Sekundentakt. Daher die CPU-Belastung.
Hallo,
bei mir läuft ALLES auf einem RPI 2B (also alle Lampen, Rolläden, Alexa, OBIS,.....) Mein IR_Lesekopf ist an einem Wemos (8266) und per WLAN an FHEM und bei mir ist die CPU-Auslastung vom RPI zusammen gerade mal bei 10%, teilweise deutlich drunter !
und die bei meinem Zähler verwertbaren Readings sind Power (aktuelle Last) und Total Consumption (Zählerstand), soweit ich mich erinnere...
Grüße
Christian
Hallo,
Meine Zähler sind von EMH.
Der Volkszaehler ist meist noch eine serialtousb Chip verbaut.
Wenn du das über den 8266 machst, ist dein Lesekopf Serial und der 8266 kann da auch schon etwas Vorarbeit leisten.
Überträgst du per Telnet oder mqtt?
ZitatMeine Zähler sind von EMH.
Die gibt es in unterschiedlicher Ausstattung.
ZitatErstaunlich das du auch die Power Werte bekommst.
Ich auch beim EMH. ;) Evtl. musst Du bei Deinem Msb die Pin anfordern und kannst zusätzliche Daten damit freischalten.
Die Power Werte bekomme ich nur bei OBIS bei SMLUSB nicht!!!
Daher habe ich bei meinem Netzbetreibe ja schon nachgefragt wegen der Pin.
Aussage bei den 2009 und 2010 Modellen gibt es keine Power Werte und auch keine Pin, ich muss das nehmen was ich bekommen.
Daher muss ich davon ausgehen das OBIS die Power Werte berechnet, weil SMLUSB sie ja sonst auch liefern würde?! :o
Zitat
Daher muss ich davon ausgehen das OBIS die Power Werte berechnet, weil SMLUSB sie ja sonst auch liefern würde?! :o
Nö, glaub ich nicht. Schalt doch einfach mal verbose=5 ein, dann siehst Du doch im Detail, was der Zähler liefert. SMLUSB kann ich nicht beurteilen.
Siehe mein Post etwas weiter oben dann siehst du was die Zähler liefern bei verbose 5 ::)
Hier noch das was SMLUSB liefert
2019-02-23_15:36:00 powerzaehler1 tariff1_consumption: 59527488.50
2019-02-23_15:36:00 powerzaehler1 tarrif1_feed: 36313182.60
2019-02-23_15:36:02 powerzaehler1 tariff1_consumption: 59527488.70
2019-02-23_15:36:02 powerzaehler1 tarrif1_feed: 36313182.60
2019-02-23_15:36:04 powerzaehler1 tariff1_consumption: 59527488.90
2019-02-23_15:36:04 powerzaehler1 tarrif1_feed: 36313182.60
2019-02-23_15:36:06 powerzaehler1 tariff1_consumption: 59527489.10
2019-02-23_15:36:06 powerzaehler1 tarrif1_feed: 36313182.60
2019-02-23_15:36:08 powerzaehler1 tariff1_consumption: 59527489.30
2019-02-23_15:36:08 powerzaehler1 tarrif1_feed: 36313182.60
OBIS-Daten Leistung(power):
Zitat1-0:2.7.0*255(988.6*W)
Zitat1-0:1.7.0*255(0*W)
1-0:2.7.0*255(807.7*W)
Kommt also pur aus dem Zähler.
Scheint so, kann aber nicht stimmen, wie schon beschrieben.
988 - 807 = 181W
Alleine meine USV hat zu dem Zeitpunkt 570W benötigt.
Wie passt das zusammen?
ZitatZeitpunkt
ist das Stichwort. Und nun drehen wir uns im Kreis (https://forum.fhem.de/index.php/topic,51948.msg910691.html#msg910691)
Zitat von: Edi77 am 26 Februar 2019, 13:05:11
Hallo,
Meine Zähler sind von EMH.
Der Volkszaehler ist meist noch eine serialtousb Chip verbaut.
Wenn du das über den 8266 machst, ist dein Lesekopf Serial und der 8266 kann da auch schon etwas Vorarbeit leisten.
Überträgst du per Telnet oder mqtt?
Also mein Zähler ist ein EMH ED300S. Mit IR-Sensor von Udo über TTL an ESP8266 (RX/TX) mit ESPLink. Läuft seit ner Ewigkeit stabil, ausser dass von Zeit zu Zeit mitmal keine Werte mehr gekommen sind. Daher wird mit einem Timer, wenn das readingsAge >60s ist, einfach ein defmod gesendet, dann läuft der wieder normal weiter. Hab ich auch schon eine Weile nicht mehr upgedatet. CPU-Auslastung (wie geschrieben steuert der RPI alle Rolladen, 2x EbusD, Lampen, 10 Temperatursensoren, und noch ein paar Dinge mehr) zwischen 5 und 15%, selten mal bei 20%, Werte kommen ca. alle 1-2s rein.
Grüße
Christian
Richtig der Zeitpunkt ist wichtig, Hier die Leistungswerte der Unterverteilung wo auch die USV angeschlossen ist.
Also immer noch
988-807 = 181W!!!
Ist weniger wie USV 570W
Ist weniger wie die Unterverteilung 860W
Und dann sind da noch andere Gerät die nicht erfasst wurden.
Also eine Different von mehr wie 600W !!!!
Wie geht das? ???
2019-02-24_14:30:28 ESP62_UV 861.573808156232
2019-02-24_14:30:28 ESP62_UV 861.573808156232
2019-02-24_14:30:28 ESP62_UV 864.055299539171
2019-02-24_14:30:28 ESP62_UV 864.055299539171
2019-02-24_14:31:33 ESP62_UV 864.055299539171
2019-02-24_14:31:33 ESP62_UV 864.055299539171
2019-02-24_14:31:33 ESP62_UV 860.256165169184
2019-02-24_14:31:33 ESP62_UV 860.256165169184
2019-02-24_14:32:31 ESP62_UV 860.256165169184
2019-02-24_14:32:31 ESP62_UV 860.256165169184
2019-02-24_14:32:31 ESP62_UV 853.889943074004
2019-02-24_14:32:31 ESP62_UV 853.889943074004
2019-02-24_14:33:30 ESP62_UV 853.889943074004
Vielleicht hast du die Frage ja schon beantwortet, aber mich würde mal interessieren, ob denn der in FHEM angezeigte Wert für den jeweiligen Zähler mit dem Display des Zählers übereinstimmt ?
Grüße
Christian
Durch pollingMode off habe ich jetzt schon ehr realistische Werte.
Auf dem Zähler wird nur der Zählerstand, keine Leistung usw. angezeigt, weil er das auch laut Netzbetreibe nicht kann.
hmmm, mein EMH ED300S kann das. Intern kann der sogar Monatsstände speichern, die bekommt man aber über OBIS nicht übermittelt...
Hier ein List vom Device
Internals:
DEF 192.168.2.61:23
DeviceName 192.168.2.61:23
FD 87
FUUID 5c47753f-f33f-1755-f124-ddd22ff8c0993b07
MeterType SML
NAME Stromzaehler
NR 426
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2019-02-22 17:49:02 0.118.7.0.10.255 0
2018-04-11 20:12:26 0.118.7.0.9.255 0
2017-08-28 00:19:51 0.70.32.6.32.255 0
2019-02-27 12:04:43 1.0.0.0.0.255 30-31-30-37-31-30-35-34-31-32-38-32-37
2019-02-27 12:04:43 1.0.0.0.1.255 31-45-4D-48-30-30-30-35-34-31-32-38-32-37
2019-02-27 12:04:43 1.0.0.0.9.255 09-01-45-4D-48-00-00-52-97-DB
2017-08-28 00:21:02 10.6.32.6.32.255 0
2017-08-28 00:32:27 104.134.32.6.32.255 0
2017-08-28 00:32:32 105.70.32.6.32.255 0
2017-08-28 00:32:38 106.6.32.6.32.255 0
2017-08-28 00:32:52 107.230.32.6.32.255 0
2017-08-28 00:32:57 108.166.32.6.32.255 0
2017-08-28 00:33:05 109.198.32.6.32.255 0
2017-08-28 00:21:13 11.134.32.6.32.255 0
2017-08-28 00:33:08 110.38.32.6.32.255 0
2017-08-28 00:33:41 114.166.32.6.32.255 0
2019-02-21 20:37:10 118.119.7.129.129.255 EMHRwdbRV%wrbe
2017-08-28 00:34:21 121.6.32.6.32.255 0
2017-08-28 00:34:35 123.166.32.6.32.255 0
2017-08-28 00:34:41 124.198.32.6.32.255 0
2017-08-28 00:34:45 125.134.32.6.32.255 0
2017-08-28 00:34:48 126.70.32.6.32.255 0
2017-08-28 00:34:56 128.38.32.6.32.255 0
2019-02-27 12:04:43 129.129.199.130.3.255 EMH
2017-08-28 00:21:24 13.6.32.6.32.255 0
2017-08-28 00:35:14 132.166.32.6.32.255 0
2017-08-28 00:35:22 134.134.32.6.32.255 0
2017-08-28 00:35:25 135.70.32.6.32.255 0
2017-08-28 00:35:32 137.38.32.6.32.255 0
2017-08-28 00:35:43 139.198.32.6.32.255 0
2017-08-28 00:35:46 140.134.32.6.32.255 0
2017-08-28 00:35:52 142.6.32.6.32.255 0
2017-08-28 00:36:10 146.134.32.6.32.255 0
2017-08-28 00:36:21 148.102.32.6.32.255 0
2017-08-28 00:36:22 149.134.32.6.32.255 0
2017-08-28 00:21:43 15.166.32.6.32.255 0
2017-08-28 00:36:25 150.70.32.6.32.255 0
2017-08-28 00:36:28 151.6.32.6.32.255 0
2017-08-28 00:36:46 155.134.32.6.32.255 0
2017-08-28 00:36:53 157.102.32.6.32.255 0
2017-08-28 00:21:46 16.6.32.6.32.255 0
2017-08-28 00:37:14 162.166.32.6.32.255 0
2017-08-28 00:37:39 168.166.32.6.32.255 0
2017-08-28 00:37:42 169.102.32.6.32.255 0
2017-08-28 00:21:59 17.230.32.6.32.255 0
2017-08-28 00:37:46 170.134.32.6.32.255 0
2017-08-28 00:38:02 174.70.32.6.32.255 0
2017-08-28 00:38:08 175.198.32.6.32.255 0
2017-08-28 00:38:16 177.166.32.6.32.255 0
2017-08-28 00:38:26 180.70.32.6.32.255 0
2017-08-28 00:38:37 182.230.32.6.32.255 0
2017-08-28 00:38:39 183.70.32.6.32.255 0
2017-08-28 00:38:43 184.102.32.6.32.255 0
2017-08-28 00:38:46 185.38.32.6.32.255 0
2017-08-28 00:38:51 186.70.32.6.32.255 0
2017-08-28 00:39:02 188.230.32.6.32.255 0
2017-08-28 00:22:13 19.198.32.6.32.255 0
2017-08-28 00:22:07 19.6.32.6.32.255 0
2017-08-28 00:39:09 190.198.32.6.32.255 0
2017-08-28 00:39:12 191.134.32.6.32.255 0
2017-08-28 00:39:15 192.70.32.6.32.255 0
2017-08-28 00:39:26 194.230.32.6.32.255 0
2017-08-28 00:39:37 197.134.32.6.32.255 0
2017-08-28 00:39:42 198.166.32.6.32.255 0
2017-08-28 00:39:43 199.6.32.6.32.255 0
2017-08-28 00:22:16 20.38.32.6.32.255 0
2017-08-28 00:39:51 200.230.32.6.32.255 0
2017-08-28 00:39:52 201.70.32.6.32.255 0
2017-08-28 00:39:57 202.102.32.6.32.255 0
2017-08-28 00:40:03 203.230.32.6.32.255 0
2017-08-28 00:40:00 203.38.32.6.32.255 0
2017-08-28 00:40:08 205.6.32.6.32.255 0
2017-08-28 00:22:26 21.166.32.6.32.255 0
2017-08-28 00:40:31 210.166.32.6.32.255 0
2017-08-28 00:40:39 212.134.32.6.32.255 0
2017-08-28 00:40:56 216.166.32.6.32.255 0
2017-08-28 00:41:00 217.198.32.6.32.255 0
2017-08-28 00:40:57 217.6.32.6.32.255 0
2017-08-28 00:41:02 218.38.32.6.32.255 0
2017-08-28 00:41:27 223.102.32.6.32.255 0
2017-08-28 00:41:47 227.38.32.6.32.255 0
2017-08-28 00:42:01 229.198.32.6.32.255 0
2017-08-28 00:41:57 229.6.32.6.32.255 0
2017-08-28 00:42:07 230.230.32.6.32.255 0
2017-08-28 00:42:11 231.166.32.6.32.255 0
2017-08-28 00:42:37 236.134.32.6.32.255 0
2017-08-28 00:42:47 238.102.32.6.32.255 0
2017-08-28 00:42:53 239.134.32.6.32.255 0
2017-08-28 00:43:05 241.198.32.6.32.255 0
2017-08-28 00:43:09 242.134.32.6.32.255 0
2017-08-28 00:43:21 244.6.32.6.32.255 0
2017-08-28 00:43:25 245.134.32.6.32.255 0
2017-08-28 00:43:31 246.166.32.6.32.255 0
2017-08-28 00:43:35 247.102.32.6.32.255 0
2017-08-28 00:43:40 248.134.32.6.32.255 0
2017-08-28 00:43:50 250.102.32.6.32.255 0
2017-08-28 00:43:58 251.230.32.6.32.255 0
2017-08-28 00:44:09 253.102.32.6.32.255 0
2017-08-28 00:44:14 254.38.32.6.32.255 0
2017-08-28 00:23:02 26.134.32.6.32.255 0
2017-08-28 00:20:13 3.70.32.6.32.255 0
2017-08-28 00:23:29 30.70.32.6.32.255 0
2017-08-28 00:23:40 31.198.32.6.32.255 0
2017-08-28 00:23:48 32.230.32.6.32.255 0
2017-08-28 00:23:43 32.38.32.6.32.255 0
2017-08-28 00:23:54 33.166.32.6.32.255 0
2017-08-28 00:25:07 43.198.32.6.32.255 0
2017-08-28 00:25:15 44.230.32.6.32.255 0
2017-08-28 00:25:26 46.102.32.6.32.255 0
2017-08-28 00:25:34 47.134.32.6.32.255 0
2017-08-28 00:25:51 49.198.32.6.32.255 0
2017-08-28 00:20:32 5.230.32.6.32.255 0
2017-08-28 00:20:26 5.38.32.6.32.255 0
2017-08-28 00:25:56 50.134.32.6.32.255 0
2017-08-28 00:26:01 51.70.32.6.32.255 0
2017-08-28 00:26:10 52.102.32.6.32.255 0
2017-08-28 00:27:10 60.166.32.6.32.255 0
2017-08-28 00:27:15 61.102.32.6.32.255 0
2017-08-28 00:27:29 63.70.32.6.32.255 0
2017-08-28 00:27:34 64.6.32.6.32.255 0
2017-08-28 00:27:45 65.134.32.6.32.255 0
2017-08-28 00:27:53 66.166.32.6.32.255 0
2017-08-28 00:27:59 67.102.32.6.32.255 0
2017-08-28 00:28:04 68.38.32.6.32.255 0
2017-08-28 00:28:12 69.70.32.6.32.255 0
2017-08-28 00:20:40 7.6.32.6.32.255 0
2017-08-28 00:28:31 71.230.32.6.32.255 0
2017-08-28 00:28:47 74.38.32.6.32.255 0
2017-08-28 00:29:01 76.6.32.6.32.255 0
2017-08-28 00:29:28 79.198.32.6.32.255 0
2017-08-28 00:20:54 8.230.32.6.32.255 0
2017-08-28 00:29:53 83.38.32.6.32.255 0
2017-08-28 00:31:16 84.70.32.6.32.255 0
2019-02-27 12:02:30 Version EMH\30313037313035343132383237\31454D4830303035343132383237\0901454D4800005297DB
2018-01-18 19:47:27 dir_total_consumption in
2019-02-27 12:04:43 power 493.6
2019-02-27 12:04:43 statPowerDay Min: 171.900 Avg: 469.859 Max: 4038.100
2019-02-26 23:59:55 statPowerDayLast Min: 175.800 Avg: 523.583 Max: 5875.100
2019-02-27 12:04:43 statPowerHour Min: 333.800 Avg: 465.833 Max: 568.400
2019-02-27 11:59:55 statPowerHourLast Min: 233.700 Avg: 405.606 Max: 1281.200
2019-02-27 12:04:43 statPowerMonth Min: 4.378 Avg: 471.239 Max: 6678.500
2019-02-01 00:00:00 statPowerMonthLast Min: 155.8 Avg: 482.2 Max: 7416.0
2019-02-27 12:04:43 statPowerYear Min: 4.378 Avg: 477.122 Max: 7416.000
2018-12-31 23:59:55 statPowerYearLast Min: 76.9 Avg: 432.3 Max: 8901.5
2019-02-27 12:04:43 statTotal_consumption Hour: 37.5000000 Day: 5676.1000000 Month: 309584.3000000 Year: 680650.3000000
2019-02-27 11:59:55 statTotal_consumptionLast Hour: 405.3000000 Day: 12560.7000000 Month: 371066.0 Year: 3786181.5
2019-02-23 23:13:03 state opened
2019-02-27 12:04:43 total_consumption 9860140.6
helper:
BUFFER
EoM 0
SPEED 5
TRIGGERTIME 1550959983.73991
_98_statistics Stromstatistik_HH
Channels:
DEVICES:
-1
directions:
Attributes:
room Strom_Wasser
valueBracket both
Hatte jetzt auch wieder einen Absturz heute Nacht.
Scheint wohl das USB Port oder der Lesekopf gewesen zu sein
2019.03.01 03:44:44 5: OBIS (powerzaehler) - Internal timer set to 2019-03-01 03:44:54
2019.03.01 03:44:46 5: SML-Parse 1B1B1B1B01010101760701480001958D6200620072630101760101070148109D872F0D313930303030303334303835010163459200760701480001958E620062007263070177010D3139303030303033343038350172620165109D90B97777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600238CDC7F0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Full message-> 1B1B1B1B01010101760701480001958D6200620072630101760101070148109D872F0D313930303030303334303835010163459200760701480001958E620062007263070177010D3139303030303033343038350172620165109D90B97777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600238CDC7F0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=1B1B1B1B01010101760701480001958D6200620072630101760101070148109D872F0D313930303030303334303835010163459200760701480001958E620062007263070177010D3139303030303033343038350172620165109D90B97777078181C78203FF0101010104454D480177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600238CDC7F0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=0177070100000000FF010101010D3139303030303033343038350177070100010801FF628201621E52FF5600238CDC7F0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=0177070100010801FF628201621E52FF5600238CDC7F0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=0177070100020801FF628201621E52FF560015B2471901770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=01770700006001FFFF010101010B303030323236363139380177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=0177070100010700FF0101621B52FF5500002CA80177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 5: OBIS: Telegram=0177070100020700FF0101621B52FF550000000001010163C4E700760701480001958F620062007263020171016367EA000000001B1B1B1B1A030F5D
2019.03.01 03:44:46 4: MSG IS:
/EMH\313930303030303334303835
129-129:199.130.3*255(EMH)
1-0:0.0.0*255(313930303030303334303835)
1-0:1.8.1*255(>59643404.7*Wh)
1-0:2.8.1*255(>36400514.5*Wh)
0-0:96.1.255*255(0002266198)
1-0:1.7.0*255(1143.2*W)
1-0:2.7.0*255(0*W)
!
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: /EMH\313930303030303334303835
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 129-129:199.130.3*255(EMH)
2019.03.01 03:44:46 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 1-0:0.0.0*255(313930303030303334303835)
2019.03.01 03:44:46 5: Msg 1-0:0.0.0*255(313930303030303334303835) is of type Owner
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 1-0:1.8.1*255(>59643404.7*Wh)
2019.03.01 03:44:46 5: Msg 1-0:1.8.1*255(>59643404.7*Wh) is of type Counter
2019.03.01 03:44:46 4: Set total_consumption_Ch1 to 59643404.7
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 1-0:2.8.1*255(>36400514.5*Wh)
2019.03.01 03:44:46 5: Msg 1-0:2.8.1*255(>36400514.5*Wh) is of type Counter
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 0-0:96.1.255*255(0002266198)
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 1-0:1.7.0*255(1143.2*W)
2019.03.01 03:44:46 5: Msg 1-0:1.7.0*255(1143.2*W) is of type Channels
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: 1-0:2.7.0*255(0*W)
2019.03.01 03:44:46 5: Msg 1-0:2.7.0*255(0*W) is of type Channels
2019.03.01 03:44:46 5: OBIS (powerzaehler) - Msg-Parse: !
2019.03.01 03:44:46 5: Starting notify loop for powerzaehler, 7 event(s), first is 129.129.199.130.3.255: EMH
2019.03.01 03:44:46 5: End notify loop for powerzaehler
2019.03.01 03:44:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (powerzaehler)
2019.03.01 03:44:48 5: Starting notify loop for powerzaehler, 1 event(s), first is DISCONNECTED
2019.03.01 03:44:48 5: End notify loop for powerzaehler
2019.03.01 03:44:48 3: Setting powerzaehler serial parameters to 9600,8,N,1
2019.03.01 03:44:48 3: Init done
2019.03.01 03:44:48 1: /dev/ttyUSB0 reappeared (powerzaehler)
2019.03.01 03:44:48 5: Starting notify loop for powerzaehler, 1 event(s), first is CONNECTED
2019.03.01 03:44:48 5: End notify loop for powerzaehler
2019.03.01 03:44:51 1: /dev/ttyUSB0 disconnected, waiting to reappear (powerzaehler)
2019.03.01 03:44:51 5: Starting notify loop for powerzaehler, 1 event(s), first is DISCONNECTED
2019.03.01 03:44:51 5: End notify loop for powerzaehler
2019.03.01 03:44:51 3: Setting powerzaehler serial parameters to 9600,8,N,1
2019.03.01 03:44:51 3: Init done
2019.03.01 03:44:51 1: /dev/ttyUSB0 reappeared (powerzaehler)
2019.03.01 03:44:51 5: Starting notify loop for powerzaehler, 1 event(s), first is CONNECTED
2019.03.01 03:44:51 5: End notify loop for powerzaehler
2019.03.01 03:44:54 1: /dev/ttyUSB0 disconnected, waiting to reappear (powerzaehler)
2019.03.01 03:44:54 5: Starting notify loop for powerzaehler, 1 event(s), first is DISCONNECTED
2019.03.01 03:44:54 5: End no2019.03.01 03:20:11 5: Initializing Type Library:
2019.03.01 03:20:11 1: Including fhem.cfg
2019.03.01 03:20:11 5: Cmd: >attr global userattr cmdIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride<
2019.03.01 03:20:11 5: Cmd: >attr global logfile ./log/fhem-%Y-%m-%d.log<
2019.03.01 03:20:11 5: Cmd: >attr global modpath .<
2019.03.01 03:20:11 5: Cmd: >attr global motd SecurityCheck:
/dev/ttyUSB0
Könne es theoretisch sein, dass ein anderes Gerät auch mit reinpfuscht?
Sinnvoller wäre eine def wie zB
/dev/serial/by-path/platform-sw-ehci.1-usb-0:1.1.2:1.0-port0@9600,7,E,1
oder
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Hallo
Der Orange Pi one hat nur 1 USB Anschluss, und der macht nichts anderes als diesen einen Stromzähler auszulesen
Zitat von: eisenhauer1987 am 24 Februar 2019, 12:11:18
Also bei mir stimmen die Werte von Obis mit dehnen vom Zähler. Aber halt der Absturz beim o.g. Telegram. Kann das jemand checken?
Grüße
Und auch bei mir wieder heute Nacht das gleiche. Gibt es eine Lösung?
Bei mir werden nicht alle Einheiten richtig angezeigt. Wenn ich das Attribut UnitReadings aktiviere, werden die Einheiten für die power Readings nicht richtig dargestellt.Fehlerhaft sind nur die Readings power_L1, power_L2 und power_L3. Das Reading power passt komischerweise ;)
Die Power L1-L3 Readings kommen aus den Channels:"1.0.36.7.0.255"=>"power_L1",
"1.0.56.7.0.255"=>"power_L2",
"1.0.76.7.0.255"=>"power_L3",
Zitat von: Homalix99 am 24 Mai 2018, 11:38:08
Danke erstmal, bin gerade mit dem EVU in Kontakt, damit der Zähler mehr auspuckt.
Hallo,
ich ahbe selbiges Problem, einige EMH Benutzer haben ja ne Menge Readings. Ich habe nur diese
energy_total
energy_total_Ch1
energy_total_Ch2
feed_total
feed_total_Ch1
feed_total_Ch2
state
total_consumption
total_consumption_Ch1
total_consumption_Ch2
total_feed
total_feed_Ch1
total_feed_Ch2
Was hast du erreichen können?
Gruß Rene
Hallo,
ich hatte bis letzte Woche zwei EMH-Stromzähler und habe 2-3 Jahre das SMLUSB-Modul verwendet. Nun habe ich zwei DTZ541 Drehstromzähler von Holley Technology mit einer optischen Info-Schnittstelle bekommen.
Mein erster Versuch war die beiden optischen Lesegeräte wieder anzuschließen, bekam dabei allerdings Division durch 0 Fehler, die mein gesamtes Fhem zum Absturz gebracht haben. Aus dem Grund bin ich auf das Obis-Modul umgestiegen. Mein 2-Tarif-Zähler liest mit beiden Lesegeräten brauchbare Werte aus. An dem anderen Zähler bekomme ich mit keinem Lesegerät brauchbare Ergebnisse. Beide Lesegeräte sind in Shem gleich konfiguriert.
An dem nicht funktionierenden Zähler bekomme ich die ganze Zeit crc_errors
Verbose 5 liefert folgende Daten:
2019.03.12 20:14:09 5: SML-Parse 1B1B1B1B01010101760400000162006200726500000101760101070000000829AA0B0A01484C590200010995010163823F0076040000026200620072650000070177010B0A01484C59020001099501017777070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000109950177070100010800FF65001C010465000829AA621E52FF65000B33070177070100020800FF65001C010465000829AA621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163FDC400760400000362006200726500000201710163EBF4001B1B1B1B1A003869
Definition:
define normalStrom OBIS /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DCF91-if00-port0@9600,8,N,1 SML
8-N-1 ist laut Herstelleranleitung auch korrekt und funktioniert bei dem anderen Zähler.
Hat jemand eine Idee warum ich keine Daten von meinen Stromzähler bekomme?
Danke und Gruß
Jaykoert
Ich habe vom Hersteller die Info bekommen, dass der funktionierende Zähler CRC-Algorithmus von ,,X25" verwendet. Der nicht funktionierende Zähler verwendet CRC-Algorithmus von ,,CCITT".
Kann man das irgendwie einstellen?
Alternative wäre die CRC-Prüfung abzuschalten. Geht das?
Nein, kann man nicht einstellen, ist der erste Zähler, von dem ich höre, dass der ein anderes CRC hat.
Du kannst mal zum testen die Zeile 758
return $crc2==$crc ? 1 : 0;
durch ein einfaches
return 1;
ersetzen.
Damit werden die Daten ausgewertet, egal, ob CRC richtig oder falsch ist.
lg, Stefan
Jetzt funktioniert es.
Hier mal der Auszug aus dem Log:
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: !
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:96.5.0*255(1835268)
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:96.90.2*255(A01A)
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:0.2.0*255(1.02.007)
2019.03.13 19:23:35 5: Msg 1-0:2.8.0*255(0*Wh) is of type Counter
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2019.03.13 19:23:35 4: Set total_consumption to 82222.4
2019.03.13 19:23:35 5: Msg 1-0:1.8.0*255(82222.4*Wh) is of type Counter
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:1.8.0*255(82222.4*Wh)
HLY )
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:96.1.0*255(
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: 1-0:96.50.1*255(HLY)
2019.03.13 19:23:35 5: OBIS (normalStrom) - Msg-Parse: /
!
1-0:96.5.0*255(1835268)
1-0:96.90.2*255(A01A)
1-0:0.2.0*255(1.02.007)
1-0:2.8.0*255(0*Wh)
1-0:1.8.0*255(82222.4*Wh)
HLY )
1-0:96.1.0*255(
1-0:96.50.1*255(HLY)
/
2019.03.13 19:23:35 4: MSG IS:
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100010800FF65001C01046500096F50621E52FF65000C8BD00177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=0177070100600100FF010101010B0A01484C5902000109950177070100010800FF65001C01046500096F50621E52FF65000C8BD00177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Telegram=1B1B1B1B0101010176040000016200620072650000010176010107000000096F500B0A01484C5902000109950101638B1E0076040000026200620072650000070177010B0A01484C59020001099501017777070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000109950177070100010800FF65001C01046500096F50621E52FF65000C8BD00177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: OBIS: Full message-> 1B1B1B1B0101010176040000016200620072650000010176010107000000096F500B0A01484C5902000109950101638B1E0076040000026200620072650000070177010B0A01484C59020001099501017777070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000109950177070100010800FF65001C01046500096F50621E52FF65000C8BD00177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
2019.03.13 19:23:35 5: SML-Parse 1B1B1B1B0101010176040000016200620072650000010176010107000000096F500B0A01484C5902000109950101638B1E0076040000026200620072650000070177010B0A01484C59020001099501017777070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000109950177070100010800FF65001C01046500096F50621E52FF65000C8BD00177070100020800FF65001C01046500096F50621E52FF62000177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163A93200760400000362006200726500000201710163EBF4001B1B1B1B1A00ACA8
Zum Testen ganz nett, aber beim nächsten Update ist es wieder weg.
ZitatDer nicht funktionierende Zähler verwendet CRC-Algorithmus von ,,CCITT".
um das zu implementieren, bräuchte man halt auch den Startwert für die CRC-Berechnung. Dann sollte das kein allzugroßes Problem darstellen
Hallo zusammen,
ich möchte hier nochmal auf das Bufferoverflow Thema kommen, welches vor einigen Wochen ein paar Probleme gemacht hatte. Ich hatte dann eine aktuelle Version eingespielt und dachte das Problem wäre damit beseitigt. Es ist auch deutlich besser geworden. Allerdings gibt es immer noch ca. alle 2 Wochen einen Komplettausfall des FHEM wegen OBIS. Damals wurde ja empfohlen das Loglevel hochzusetezn, das habe ich gemacht, hier ist der Auszug:
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:1.8.0*255(4478162.4*Wh)
2019.03.16 06:53:13 5: Msg 1-0:1.8.0*255(4478162.4*Wh) is of type Counter
2019.03.16 06:53:13 4: Set total_consumption to 4478162.4
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:16.7.0*255(919*W)
2019.03.16 06:53:13 5: Msg 1-0:16.7.0*255(919*W) is of type Channels
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: !
2019.03.16 06:53:14 5: SML-Parse 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Full message-> 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Telegram=1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Könnte das mal einer der Experten Debuggen?
Vielen Dank euch, mohel
Hallo,
ich habe da mal eine Frage, ich habe den EMH ED300S und wenn ich das richtig gelesen habe, dann ist der "große" Datensatz aktiviert, aber ich bekomme nur die aktuelle Nutzlast und den Zählerstand aus dem Modul raus, keine Phasenlast und sonst auch nichts. Kann ich da im Modul noch irgendwo was aktivieren ?
Grüße
Christian
eher nicht. :'(
Mit Attribut ignoreUnknown=off wird Dir eigentlich alles ausgeworfen, was über die Schnittstelle kommt. Ggfs. kannst Du mit einem kurzzeitigen verbose=5 im Log die Details prüfen.
Grüße Markus
Schade, dachte, weil einige ja auch die Phasen- Lasten bekommen und in der Bedienungsanleitung eben steht, dass die Nutzlast nur mit dem großen Datensatz geliefert würde...
Bei den EMH's kann man das nie so genau sagen. :'( Mein "großer" Datensatz des EMH hat leider auch keine Phasendaten. Zum Glück aber an der hinteren Msb-Schnittstelle. Nun hab ich einfach die Verkabelung getauscht. Der Msb bekommt nun die Daten über die vordere "Kundenschnittstelle" und mein FHEM wird mit den Daten der hinteren Msb-Schnittstelle mit Phasendaten beliefert. ;D
Ggfs. lässt sich da was über den Versorger(bzw. den Msb) lösen, indem er unterstützt, dass der Kunden-IR-Lesekopf(darf dann nicht die runde Ausführung sein) in die Msb-Schnittstelle eingesetzt wird.
"an der hinteren Msb-Schnittstelle" ? lt. Datenblatt hat der EMH ED300S doch nur die RS232-Schnittstelle unter dem Klemmendeckel (welcher plombiert sein sollte ?!) oder gibt's da noch mehr Schnittstellen (neben der vorderen IR-Schnittstelle natürlich), an die der Verbraucher dran kommt ?
Zitatlt. Datenblatt hat der EMH ED300S doch nur die RS232-Schnittstelle unter dem Klemmendeckel (welcher plombiert sein sollte ?!)
BEIDE Schnittstellen sind Infrarot und RS232. Also technisch quasi gleich. Vorne für den Kunden, hinten(verdeckt und plombiert) für den Msb. Deshalb ist ja die "Unterstützung" des Versorgers(Msb) notwendig.
aha... na da hab ich bei meinem Anbieter wenig Hoffnung....
Zitat von: mohel am 16 März 2019, 10:42:03
Hallo zusammen,
ich möchte hier nochmal auf das Bufferoverflow Thema kommen, welches vor einigen Wochen ein paar Probleme gemacht hatte. Ich hatte dann eine aktuelle Version eingespielt und dachte das Problem wäre damit beseitigt. Es ist auch deutlich besser geworden. Allerdings gibt es immer noch ca. alle 2 Wochen einen Komplettausfall des FHEM wegen OBIS. Damals wurde ja empfohlen das Loglevel hochzusetezn, das habe ich gemacht, hier ist der Auszug:
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:1.8.0*255(4478162.4*Wh)
2019.03.16 06:53:13 5: Msg 1-0:1.8.0*255(4478162.4*Wh) is of type Counter
2019.03.16 06:53:13 4: Set total_consumption to 4478162.4
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:16.7.0*255(919*W)
2019.03.16 06:53:13 5: Msg 1-0:16.7.0*255(919*W) is of type Channels
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: !
2019.03.16 06:53:14 5: SML-Parse 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Full message-> 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Telegram=1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Könnte das mal einer der Experten Debuggen?
Vielen Dank euch, mohel
Hi,
ich habe ja das gleiche Problem und auch schon Log gepostet, leider habe ich keine Rückmeldung hierzu erhalten. Für mich ist das ganze OBIS Modul zur Zeit nicht mehr nutzbar. Wenn nötig kann ich natürlich auch weitere Daten liefern.
Grüße
Hallo
Erst mal Danke für das Modul!
Hab es versucht zum laufen zu bringen und bekomme momentan auch Daten vom Zähler, nur nicht so wie ich es mir vorstelle!
Energiezähler ist ein Siemens TD-3511. Hab in mit
/dev/ttyUSB0@300,7,E,1 E110
angelegt, es kommen auch Daten nur halt nicht alle lesbar.
Die Daten kommen interessanter weise auch ohne Pin vom Betreiber obwohl ich den auch hätte!
Bei den fehlerhaften Daten steht im reading immer (00-00-00 00:00)?????
im Log sieht man das aber die Messwerte auch dabei wären.
2019.03.29 17:46:18 5: OBIS (Energiemeter) - Internal timer set to 2019-03-29 17:46:19
2019.03.29 17:46:20 5: OBIS (Energiemeter) - Msg-Parse: 51.7(3.53*A)(00-00-00 00:00)
2019.03.29 17:46:20 5: SW: 2f3f210d0a
2019.03.29 17:46:20 4: Wrote /?!
2019.03.29 17:46:20 5: OBIS (Energiemeter) - Internal timer set to 2019-03-29 17:46:21
2019.03.29 17:46:21 5: OBIS (Energiemeter) - Msg-Parse: 71.7(0.33*A)
2019.03.29 17:46:21 5: OBIS (Energiemeter) - Msg-Parse: 91.7(8.08*A)
2019.03.29 17:46:21 5: SW: 2f3f210d0a
2019.03.29 17:46:21 4: Wrote /?!
71.7 zeigt 0,33
91.7 zeigt 8,08
aber 51.7 zeigt (00-00-00 00:00)
Kann mir da bitte jemand weiter helfen?
Hallo,
die Pin brauchst du nur, um den Zähler einmal für die Ausgabe über die Infrarotschnittstelle freizuschalten, das machst du mit einer Taschenlampe (bzw. je nachdem wie das bei deinem Zähler gelöst wurde), die Schnittstelle, über die du dann ausliest ist normalerweise nur "read only". Ggf. mal probieren den Pin am Zähler einzugeben und dann schauen, ob mehr Werte kommen. An meinem EHM-Zähler kommen auch nach Pin leider "nur" die Wirkleistung komplett und der gesamt Zählerstand... Aber immer noch besser als mit dem analogen Zähler vorher ;-)
Grüße
Christian
Hallo,
Das mit dem Pin ist eigentlich eher Nebensache, war nur halt verwunderlich das der Zähler auch ohne Pin Daten ausgibt. Mein Hauptproblem ist das hinder manchen Werten immer dieses (00-00-00 00:00) erscheint und dann natürlich der Messwert nicht mehr wie im Beispiel bei 51.7!!
Hab jetzt noch
attr Energiemeter valueBracket first
eingestellt dann erhalte ich zu mindestens meistens richtige werte, aber leider auch nicht überall. Die Zähler Seriennummer wird noch immer mit (00-00-00 00:00) angezeigt, ebenso C.70.2.
Was mir auch noch aufgefallen ist das trotz event-min-interval .*:120 nicht alle werte ins log geschrieben werden.
Anbei noch mal mein Code für den Energiezähler
# - Stromverbrauch -
define Energiemeter OBIS /dev/ttyUSB0@300,7,E,1 VSM102
setuuid Energiemeter 5c9d399b-f33f-d922-7356-d70a6789c0bea7a2
attr Energiemeter userattr event-min-interval event-on-change-reading verbose webCmd
attr Energiemeter event-min-interval .*:120
attr Energiemeter event-on-change-reading .*
attr Energiemeter interval 1
attr Energiemeter pollingMode on
attr Energiemeter room Energie
attr Energiemeter valueBracket first
define stromverbrauch FileLog ./log/Energie-%Y-%m.log Energiemeter
setuuid stromverbrauch 5c9d30ec-f33f-d922-8ff8-95467c17d556a150
attr stromverbrauch nrarchive 2
attr stromverbrauch room Energie
Logfile
2019.04.01 17:30:00 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:01
2019.04.01 17:30:01 5: OBIS (Energiemeter) - Msg-Parse:
ER0001/SAT63511D01448004700
2019.04.01 17:30:01 5: SW: 063030300d0a
2019.04.01 17:30:01 5: SW: 2f3f210d0a
2019.04.01 17:30:01 4: Wrote /?!
2019.04.01 17:30:01 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:02
2019.04.01 17:30:02 5: SW: 2f3f210d0a
2019.04.01 17:30:02 4: Wrote /?!
2019.04.01 17:30:02 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:03
2019.04.01 17:30:03 5: OBIS (Energiemeter) - Msg-Parse: ER0007F.F(00000000)(00-00-00 00:00)
2019.04.01 17:30:03 5: SW: 2f3f210d0a
2019.04.01 17:30:03 4: Wrote /?!
2019.04.01 17:30:03 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:04
2019.04.01 17:30:04 5: OBIS (Energiemeter) - Msg-Parse: 0.0.0(003122137)(00-00-00 00:00)
2019.04.01 17:30:04 5: SW: 2f3f210d0a
2019.04.01 17:30:04 4: Wrote /?!
2019.04.01 17:30:04 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:05
2019.04.01 17:30:05 5: SW: 2f3f210d0a
2019.04.01 17:30:05 4: Wrote /?!
2019.04.01 17:30:05 5: OBIS (Energiemeter) - Internal timer set to 2019-04-01 17:30:06
2019.04.01 17:30:06 5: OBIS (Energiemeter) - Msg-Parse: 0.0.1(G23-511-D.01/448-004700)(00-00-00 00:00)
2019.04.01 17:30:06 5: SW: 063030300d0a
2019.04.01 17:30:06 5: OBIS (Energiemeter) - Msg-Parse: C.70.0()
2019.04.01 17:30:06 5: SW: 2f3f210d0a
2019.04.01 17:30:06 4: Wrote /?!
LG Christian
Hallo !
Ich habe eine Frage an den Modulautor.
OBIS läuft sein 10 Monaten stabil, nur kommt es alle paar Monate vor, dass der Zweirichtungszähler (Fa. EMH, Typ P) aus unerfindlichen Gründen undefinierte SML-Daten auswirft, welche vom Modul als Readings interpretiert wird (siehe unten).
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0
FD 32
MeterType SML
NAME ZRZ
NR 1218
PARTIAL
STATE opened
TYPE OBIS
.attraggr:
.attreocr:
.*
.attrminint:
10
.userReadings:
HASH(0x5252db8)
HASH(0x5300bd0)
READINGS:
2019-03-22 04:46:55 0.0.0.0.27.255 0
2019-03-29 23:15:47 0.11.10.1.69.255 643620
2019-02-19 02:00:40 0.118.5.3.203.255 0
2019-03-30 18:58:50 0.118.5.4.104.255 459007
2019-03-31 07:25:32 0.118.5.4.106.255 -93
2019-03-23 13:36:16 0.118.5.4.75.255 3327118.7
2019-03-29 23:15:57 10.11.10.1.69.255 590340
2019-03-29 23:17:27 100.11.10.1.69.255 192960
2019-03-29 23:17:37 110.11.10.1.69.255 555060
2019-03-29 23:17:57 130.11.10.1.69.255 594260
2019-03-29 23:18:07 140.11.10.1.69.255 336120
2019-03-29 23:18:27 160.11.10.1.69.255 637690
2019-03-29 23:18:37 170.11.10.1.69.255 524670
2019-03-29 23:18:47 180.11.10.1.69.255 117140
2019-03-29 23:18:57 190.11.10.1.69.255 203310
2019-03-29 23:16:07 20.11.10.1.69.255 229670
2019-03-29 23:19:07 200.11.10.1.69.255 505770
2019-03-29 23:19:17 210.11.10.1.69.255 455010
2019-03-29 23:19:27 220.11.10.1.69.255 517110
2019-03-29 23:19:37 230.11.10.1.69.255 413640
2019-03-29 23:19:47 240.11.10.1.69.255 307520
2019-03-29 23:19:57 250.11.10.1.69.255 224950
2019-03-29 23:16:17 30.11.10.1.69.255 517170
2019-03-29 23:16:27 40.11.10.1.69.255 273690
2019-03-29 23:16:37 50.11.10.1.69.255 317270
2019-03-29 23:16:47 60.11.10.1.69.255 42250
2019-03-29 23:16:57 70.11.10.1.69.255 212440
2019-03-29 23:17:07 80.11.10.1.69.255 313150
2019-03-29 23:17:17 90.11.10.1.69.255 109560
2019-04-05 10:57:43 Hersteller EMH
2019-04-05 10:57:43 Power.av -341.640
2019-04-05 10:57:43 Powerconsumption 270
2019-04-05 10:57:43 ZRZ_Status 1865988
2019-04-05 10:57:43 power -346
2019-04-05 10:57:43 power_L1 -136
2019-04-05 10:57:43 power_L2 -24
2019-04-05 10:57:43 power_L3 -188
2019-04-04 13:02:56 state opened
2019-04-05 10:57:43 total_consumption 1826726.1
2019-04-05 10:57:43 total_feed 3575439.7
helper:
BUFFER
EoM 1
SPEED 5
TRIGGERTIME 1554375776.3594
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
1.0.96.5.0.255 ZRZ_Status
1.0.96.50.1.255 Hersteller
DEVICES:
10
directions:
history:
ARRAY(0x2867158)
ARRAY(0x491ea10)
ARRAY(0x58eb7c8)
ARRAY(0x2883988)
ARRAY(0x5a3a0a8)
ARRAY(0x5c699f8)
ARRAY(0x5ac0698)
ARRAY(0x590b100)
ARRAY(0x5aa7298)
ARRAY(0x30a2708)
ARRAY(0x59b6108)
ARRAY(0x59afad0)
ARRAY(0x49b5298)
ARRAY(0x28001a8)
ARRAY(0x58d54e8)
ARRAY(0x28833e8)
ARRAY(0x58d5800)
ARRAY(0x58961b8)
ARRAY(0x5dad600)
ARRAY(0x592f170)
ARRAY(0x5b24848)
ARRAY(0x592dcc8)
ARRAY(0x479e1d8)
ARRAY(0x5900498)
ARRAY(0x5ae0ad0)
Attributes:
Device_dependend eHZ_History
channels {"1.0.96.5.0.255"=>"ZRZ_Status","1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
event-min-interval 10
event-on-change-reading .*
group Verbrauchszähler
icon electric_meter_bidirectional
interval 10
room Keller,PV_Anlage
userReadings Power.av {movingAverage("ZRZ","power",100)},
Powerconsumption {ReadingsVal("PV_WR","SPOT_PACTOT",0) + ReadingsVal("ZRZ","power",0)}
verbose 0
Dann stehen 20 - 30 schwachsinnige Readings im Objekt und es ist lässtig, immer bis nach unten zu scrollen um die eigentlich interessanten readings zu sehen.
Frage: Kann man so was im Modul abfangen, z. B. mit einem Atrribut "disable_autocreate_readings", was defaultmässig auf 0 (enabled) gesetzt ist (zum erstmaligen Anlegen der gültigen Readings) und dann auf 1 (disable) um dies zu vermeiden?
VG
Alex
Hallo Alex,
bin zwar nicht der Modulautor, aber ignoreUnknown=on sollte Dein Bedürfnis befriedigen.
Grüße Markus
Oh danke für den Hinweis. Habe ich in der Referenz nicht gefunden (dort ist es scheinbar nicht dokumentiert). Als Attribut verfügbar und bereits gesetzt. Ich denke das war die Lösung.
VG
Alex
Hallo an alle,
ich komme mit meinem Zähler nicht weiter - das einzige was ich bekomme ist nicht verständlich.
Im Buffer steht folgendes (etwas beschnitten)
Internals:
CFGFN
DEF /dev/ttyStrom@9600,7,N,1 Standard
DeviceName /dev/ttyStrom@9600,7,N,1
FD 34
FUUID 5caf98af-f33f-a0bc-0a4a-0aaf823f74c4749c
MeterType Standard
NAME strom
NR 50801
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2019-04-12 08:00:23 state opened
helper:
BUFFER ,~6{FY*e{Rfc+9/9( /*vw{|{GQA R9{{l?{cY*ekj/j{{rvR)'i
~;{e{VvkjK '{rvR)'i ~v{e{Vv{__VRh)'i;{FY*e{Vf%!qh)'i~Y{e{Vv{[~'R){,~6{FY*e{Rc+9/9( /*vw{|{GQA R9/{{l?{~Y* ' K '{rvR)'ic{~;{e{Vvkjoj{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{V%!qh)'i{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9( /*vw | QA R9/{{l?{~Y*ekj/j{{vR)'i
~;{e{Vvkj/j{{vR)'i ~v{e{Vv{_^VRh)'i4v{e{Vv{V %!qh)'ic{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9( /*vw{|{GQA R9/{{l?{~Y*ekj/j{{vR)'i
~;{e{VvkjK '{rvR)'i |v{e{Vv{__VRh)'i;{FY*e{V%!qh)'i
ce~Y*e{[~'R){,~6{FY*e{R c+9/9( /*vw{|{GQA R9{{l?{~Y*ekjj{{vR)'i
~;{e{Vvkj/j{{ vR)'i'~v{e{Vv{__VRh)'i|v{e{Vv{Vf%!qh)'i
~Y{esVv{[~'R){,~6{FY*e{Rc+9/9( /*vw|{GQA R9{{l?{~Y* ' /j{{vR)'ic{~;{e{Vvkj/j{{vR)'i |v{e{Vv{__VRh)'i|v{e{Vv{V%!qh)'ic{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9( /*vw{|{GQA R9/{{l?{~Y*ekj/j{{vR)'i
~;{{VvkjK '{vR)'i ~v{e{Vv{__VRh)'i;{FY*e{V%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rc
+9/9( o*vw{|{GQA R9/{{ c?{e{Vvkjj{{rvR)'i
~;{e{VvkjK '{rvR)'i ~v{e{Vv{__VRh)'i ~v{e{Vv{Vf%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rc}-9/9( Kw{|{GQA R9{{l?{~Y*ekjoj{{vR)'i~;{e{Vvkj/j{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{Vf%!qh)'icz~Y{e{Vv{[~'R){,~6{FY*e{Rfc{-9/9( /*vw{|{GQA R9/{{l?{~Y*ekj/j{{vR)'i
~;{e{Vvkjj{{rvR)'i ~v{e{Vv{__~VRh)'i;{FY*e{V%!qh)'i
{~Y{e{Vv{[~'R){,~6{FY*e{R cy+9/9( /*vw{|}QA R9/{{l?{~Y*ekjK '{vR)'i
~;{e{VvkjK '{rvR)'i ~v{e{Vv{__VRh)'i~v{e{Vv{V%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rcw-9/9( /*vw{|{GQA R9/{{ ~?{e{Vvkj?j{{vR)'i
{~;{e{Vvkj/j{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{Vf%!qh)'i
ce~Y*e{[~'R){,~6{FY*e{Rcu+9/9( /*vw{|{GQA R9/{{l?{~Y*ekj/j{{vR)'i
Zähler ist ein eBZ DD3 2R06 ETA - ODZ1
Lesekopf ist die TTL-Version von Volkszähler
Erst hatte ich den Zähler an einen Raspberry PI Zero W direkt am ttyAMA0 angeschlossen und über ser2net weitergegeben.
vom Zähler habe ich gar keine ausgaben bekommen.
Loopback funktionierte aber - da erhielte ich alles so wieder wie gesendet.
Als ich den Lesekopf an einen FTDI-USB Adapter und dann an den USB Port des RPi angeschlossen habe, bekam ich eine Ausgabe wie oben.
Mit dem Databits, Stopbits und Parity habe ich natürlich auch versucht etwas zu erreichen.
Nächster Versuch ist ein ESP8266 mit EasyESP und dem Serial Server - was ja auch ein ser2net ist.
Gleiches Ergebnis. Auch hier rumgespielt mit den Settings.
Von seriellen Übertragungen habe ich wenig Ahnung.
In der Ausgabe kann ich auch keine Werte erkennen, die da sein sollten
Laut einer im Internet gefunden Anleitung vom DD3 sollte es 7E1 sein - in diesem Thread hatte jemand mit 7E0 erfolgt.
Änderte bei mir wenig.
Es sieht auch komplett anders aus, als bei anderen hier, wenn es falsch war :)
Hat jemand eine Idee an welche Schraube ich noch drehen könnte? Bin für jeden Tipp Dankbar.
Hatte ja den Lesekopf in Verdacht, aber da das Loopback funktioniert...
Danke
Grüße
Falko
Hi Falko,
Standard ist aber richtig u. nicht evtl. SML ? :-\
Auch die Baudrate mal runtergedreht ? Ich las von Zählern die wohl nur 300 können. :-\
Grüße Markus
Sieht mir verdammt stark nach falscher Baudrate aus.....
Edith: 10 Sekunden Google:
Zitat6.1Aufbau derDatentelegramme
TelegrammMode D:nach DIN EN 625056-21
Baudrate:9600 Baud (Z=5)
Byte-Format:(7,even,1)
Du hast aber 7N1 eingestellt!
Hallo,
ich habe Udos Volkszähler-IR-Kopf an ESP8266 mit ESP Link angebunden, UART-Pins normal, Haken bei Pullup, 9600 Baut, 8N1, RX vom Kopf an TX vom ESP und umgekehrt. Erst nach dem ich die Einstellungen so hatte, kamen in der uConsole auch kryptische Zeichen und dann konnte ich den Zähler in FHEM auch einbinden
Grüße
Christian
Hallo,
danke für die Tips.
7E1 hatte ich natürlich als erstes versucht - die Anleitung hatte ich auch gefunden.
War aber ähnlich im Ergebnis und keine Readings wurden erstellt.
Wie gesagt - hatte mit den Einstellungen etwas rumgespielt.
Auf 300 bin ich wiederum nicht runter gegangen - auch mal testen.
ESPLink wiederum habe ich noch nicht probiert.
Werde den ESP neu bespielen.
Wie nimmst Du das die Daten auf dem FHEM Server an?
Socat?
Grüße
Falko
Hallo nochmal,
mit ESP-Link habe ich ähnlich Ergebnisse.
Wiederrum meldet das Log, das es möglicherweise eine falsche Baudrate ist - spontan habe ich aber keine Möglichkeit gefunden Werte unter 9600 einzugeben.
Muss mal schauen, ob ich irgendwo einen anderen Lesekopf leihen kann bzw den Kopf irgendwo testen kann.
Grüße
Falko
Also ich kann auf ESPLink mit Version esp-link v3.2.47-g9c6530d die Baudrate von 300 bis 460800 einstellen.
Mein Fehler,
Hatte Version 2.2.3 gehabt. Da scheint es nicht zu gehen.
Mit Version 3.0.14 kann ich es einstellen. Die aktuellste Version endete bei meinem ESP in einer Bootloop und da sollte man die 3.0.14 nehmen.
Leider scheint mein Problem aber nicht daher zu kommen.
Auch hier habe ich ziemlich die gleichen Daten.
Habe soweit alle Baudraten von 300 bis 57600 versucht.
Im DebugLog stand auch bei alle baudraten
UART framing error (bad baud rate?)
Wünsche ein paar ruhige Tage
Grüße
Falko
...hast du mal mit 8N1 bei 9600 Baut probiert ? Bei mir ist der dann in FHEM so eingebunden:
define Stromzaehler OBIS 192.168.2.61:23
attr Stromzaehler ignoreUnknown off
attr Stromzaehler valueBracket both
wobei 192.168.2.61 bei mir die IP vom ESP mit ESP-Link ist. Im ESP-Link mal so wie angehängt konfigurieren. Dran gedacht, RX vom IR-Kopf an TX vom ESP und umgekehrt zu verdrahten ?
Moin,
ja habe Deine Einstellungen mal probiert - auch kein Erfolg.
Hatt auch mal die RX/TX Stecker getauscht - da kam dan wie erwartet gar nichts :)
Entweder sendet mein Zähler seltsam oder am Ende ist mein Lesekopf das Problem.
Der Loopback über einer weissen Fläche klappte zwar, aber wer weiß.
Werde mal schauen, ob ich irgendwo an einen anderen Zähler komme - wenn es mit dem klappt, wäre ich zumindest ein Schritt weiter.
Zitat von: mohel am 16 März 2019, 10:42:03
Hallo zusammen,
ich möchte hier nochmal auf das Bufferoverflow Thema kommen, welches vor einigen Wochen ein paar Probleme gemacht hatte. Ich hatte dann eine aktuelle Version eingespielt und dachte das Problem wäre damit beseitigt. Es ist auch deutlich besser geworden. Allerdings gibt es immer noch ca. alle 2 Wochen einen Komplettausfall des FHEM wegen OBIS. Damals wurde ja empfohlen das Loglevel hochzusetezn, das habe ich gemacht, hier ist der Auszug:
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:1.8.0*255(4478162.4*Wh)
2019.03.16 06:53:13 5: Msg 1-0:1.8.0*255(4478162.4*Wh) is of type Counter
2019.03.16 06:53:13 4: Set total_consumption to 4478162.4
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:16.7.0*255(919*W)
2019.03.16 06:53:13 5: Msg 1-0:16.7.0*255(919*W) is of type Channels
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: !
2019.03.16 06:53:14 5: SML-Parse 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Full message-> 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Telegram=1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Könnte das mal einer der Experten Debuggen?
Vielen Dank euch, mohel
Hi,
gibt es zu diesem Problem neue Erkenntnisse? Ich habe das Problem noch immer. Ist eine Lösung in Sicht?
Grüße
Weiß nicht, ob das schon irgendwo, in den >500 Beiträgen hier, steht.
Der ED300S geht so:
define S-Zaehler OBIS /dev/ttyUSB0@9600,8,N,1 SML
Habe den an einem RPiZero-W, der hier noch sinnlos rumgammelte.
Dort FHEM drauf und die Daten per FHEM2FHEM abgeholt, fertig.
Lesekopf ist der von Weidmann.
Hallo,
danke, Klasse Modul.
Ich habe meinen Solaranlagen 2-Richtungszstromzähler EMH ED300L über den Weidmann IR Sensor mit
define Energie OBIS /dev/ttyUSB0@9600,8,N,1 SML
problemlos einbinden können. Es erscheinen die Readings:
2019-05-13 18:30:00 OBIS Energie total_consumption: 25789861.1
2019-05-13 18:30:00 OBIS Energie total_feed: 34760919.2
2019-05-13 18:30:00 OBIS Energie total_consumption_Ch1: 0
2019-05-13 18:30:00 OBIS Energie total_feed_Ch1: 34760919.2
2019-05-13 18:30:00 OBIS Energie total_consumption_Ch2: 25789861.1
2019-05-13 18:30:00 OBIS Energie power: 425.8
Vielleicht hilft die ja jemanden mit ähnlicher Konstellation.
Nur leider fehlt mir für "power" die Stromrichtung bzw. ein (separates) Plus oder Minuszeichen.
In der Originalmeldung müsste es vorhanden sein, bei einem Openhab Ausflug konnte ich das einblenden.
Hat jemand eine Idee wie man diese Information herankommen könnte?
Log File (Verbose 5):
2019.05.13 18:38:12 5: OBIS (Energie) - Msg-Parse: !
2019.05.13 18:38:14 5: SML-Parse 1B1B1B1B010101017607000D0130209F620062007263010176010107000D0E2B60350904039FC8DE5D847D01016396AF007607000D013020A0620062007263070177010904039FC8DE5D847D01726201650E2B4F327977078181C78203FF0101010104454D480177070100000009FF010101010904039FC8DE5D847D0177070100010800FF6302A201621E52FF56000F5F38730177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Full message-> 1B1B1B1B010101017607000D0130209F620062007263010176010107000D0E2B60350904039FC8DE5D847D01016396AF007607000D013020A0620062007263070177010904039FC8DE5D847D01726201650E2B4F327977078181C78203FF0101010104454D480177070100000009FF010101010904039FC8DE5D847D0177070100010800FF6302A201621E52FF56000F5F38730177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=1B1B1B1B010101017607000D0130209F620062007263010176010107000D0E2B60350904039FC8DE5D847D01016396AF007607000D013020A0620062007263070177010904039FC8DE5D847D01726201650E2B4F327977078181C78203FF0101010104454D480177070100000009FF010101010904039FC8DE5D847D0177070100010800FF6302A201621E52FF56000F5F38730177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100000009FF010101010904039FC8DE5D847D0177070100010800FF6302A201621E52FF56000F5F38730177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100010800FF6302A201621E52FF56000F5F38730177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100020800FF6302A201621E52FF560014B81A5A0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100010801FF0101621E52FF5600000000000177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100020801FF0101621E52FF560014B81A5A0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177070100010802FF0101621E52FF56000F5F387301770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=01770701000F0700FF0101621B52FF55000008750177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 5: OBIS: Telegram=0177078181C78205FF010101018302F19671B239AC37DA0B784077F1DEF23AE4F9655EDC5CDD608750CFFE32AA3D5B03D22B7670D9517F799BF411660EF43E010101636F03007607000D013020A362006200726302017101639F1B000000001B1B1B1B1A03510A
2019.05.13 18:38:14 4: MSG IS:
/EMH\04039FC8DE5D847D
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(04039FC8DE5D847D)
1-0:1.8.0*255(<25789861.1*Wh)
1-0:2.8.0*255(<34760969*Wh)
1-0:1.8.1*255(0*Wh)
1-0:2.8.1*255(34760969*Wh)
1-0:1.8.2*255(25789861.1*Wh)
1-0:15.7.0*255(216.5*W)
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: /EMH\04039FC8DE5D847D
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 129-129:199.130.3*255(EMH)
2019.05.13 18:38:14 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:0.0.9*255(04039FC8DE5D847D)
2019.05.13 18:38:14 5: Msg 1-0:0.0.9*255(04039FC8DE5D847D) is of type Serial
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:1.8.0*255(<25789861.1*Wh)
2019.05.13 18:38:14 5: Msg 1-0:1.8.0*255(<25789861.1*Wh) is of type Counter
2019.05.13 18:38:14 4: Set total_consumption to 25789861.1
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:2.8.0*255(<34760969*Wh)
2019.05.13 18:38:14 5: Msg 1-0:2.8.0*255(<34760969*Wh) is of type Counter
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2019.05.13 18:38:14 5: Msg 1-0:1.8.1*255(0*Wh) is of type Counter
2019.05.13 18:38:14 4: Set total_consumption_Ch1 to 0
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:2.8.1*255(34760969*Wh)
2019.05.13 18:38:14 5: Msg 1-0:2.8.1*255(34760969*Wh) is of type Counter
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:1.8.2*255(25789861.1*Wh)
2019.05.13 18:38:14 5: Msg 1-0:1.8.2*255(25789861.1*Wh) is of type Counter
2019.05.13 18:38:14 4: Set total_consumption_Ch2 to 25789861.1
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse: 1-0:15.7.0*255(216.5*W)
2019.05.13 18:38:14 5: Msg 1-0:15.7.0*255(216.5*W) is of type Channels
2019.05.13 18:38:14 5: OBIS (Energie) - Msg-Parse:
Zusätzlich im Log 2 für mich unverständliche Warnungen:
2019.05.13 18:44:01 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 29.
2019.05.13 18:44:01 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 29.
Liebe Grüße
Olaf
Vielen Dank für das Obis Modul. Ich konnte ohne Probleme heute einen Landis+Gyr E220 mit dem IR Lesekopf einbinden.
Was mich etwa ärgert ist, dass der Zähler nur volle kWh und auch nur Gesamt-Import und Export sendet.
Oder kann man da noch etwas an den Readings feilen?
In FHEM eher nicht. Aber vielleicht über Pin vom Msb.
Grüße Markus
Mir ist eben was aufgefallen.
Nimmt man "attr poll on" mit rein, wird alle 5sek ausgelesen.
Dazu "attr intervall 60" liest alle 65sek aus.
Also Intervall auf 55 eingestellt, macht dann minütlich eine "Auslese". ::)
Mein Fehler oder wirklich so?
Jetzt läuft es mit 60-er Intervall auch alle Minute, also Fehler bei mir.....
Bin Noch nicht ganz fit mit fhem, hab das problem das wenn ich mit vzlogger die werte abfrage bekomme ich power in Watt bei fhem abfrage über obis leider nur kW kann das sein das der wert irgendwie umgerechnet wird, oder kann man das irgendwie anders ändern? Würde die aktuelle leistung gern in eine leistungsanzeige anzeigen lassen und da wären watt besser. Bitte um hilfe!!!!
ob kW oder W ist doch dem Trend egal. ::)
mit einem attr.... userReadings powerW:power.* {ReadingsVal($name,"power",0) * 1000}bekommst Du powerW[W]n ;)
Danke für die schnelle hilfe! :D dem trend is es egal da stimm ich zu aber ich hab auf meinem tablet ui ein knob widget bei dem ich die aktuelle leistung als wert anzeige und das schaut doof aus mit 0,163!! Danke noch mal!
Ich benutze seit kurzem OBIS und alles funktioniert prima. Danke!
Im LOG kommen allerdings nach einem FHEM-Neustart folgende Zeilen (reproduzierbar):
2019.06.25 22:38:44 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2019.06.25 22:38:44 1: PERL WARNING: Use of uninitialized value $buf in unpack at ./FHEM/47_OBIS.pm line 410.
2019.06.25 22:38:44 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 423.
2019.06.25 22:38:44 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 433.
Gruß
Blueberry63
Hallo,
hat jemand schon mal das OBIS Modul inklusive SML Unterstützung via telnet getestet?
Ich habe einen Pi welcher via ser2net die Daten weitergibt. Am Server habe ich dann das Modul auf den Port eingestellt.
Ich erhalte jeweils CTC Error.
Zähler: ED300L --> Pi --> via ser2net --> Server ---> OBIS Modul
MfG
Ich habe den Sensor (USB) ebenfalls übers Netzwerk eingebunden, verwende allerdings "socat" auf der Senderseite. Die Einbindung in FHEM geht dann so:
define Stromz_Sensor OBIS 192.168.99.119:3000 SML
Der Port wird bei "socat" definiert.
Gruß
Blueberry63
Zitat von: blueberry63 am 27 Juni 2019, 17:16:38
Ich habe den Sensor (USB) ebenfalls übers Netzwerk eingebunden, verwende allerdings "socat" auf der Senderseite. Die Einbindung in FHEM geht dann so:
define Stromz_Sensor OBIS 192.168.99.119:3000 SML
Der Port wird bei "socat" definiert.
Gruß
Blueberry63
Danke für die schnelle Antwort.
So ähnlich ist es bei telnet auch aber ich vermute die Daten sind "falsch" weitergegeben.
Internals:
CFGFN
CRC_Errors 275
DEF raspberrypi-vz:2323 SMLWie hast du dein "socat" konfiguriert? Vielleicht liegt es bei telnet an
2323:telnet:600:/dev/ttyUSB0:9600 7DATABITS NONE 1STOPBIT bannerMit 8 Datenbits habe ich auch schon getestet und nichts kam an. Telnet empfängt aber, nur nicht das zum verarbeiten.
Probiere es dochmal mit "socat":
apt-get install socat
Dann folgende Datei anlegen, ausführbar machen und starten mit:
run_socat.sh &
#!/bin/sh
DEV=/dev/ttyUSB0
/usr/bin/socat TCP4-LISTEN:3000,fork $DEV,raw,echo=0
Ggf. in den Init-Vorgang einbinden
Blueberry63
Besten Dank :)
es klappt auf Anhieb.
Gesendet von iPhone mit Tapatalk Pro
Hallo,
seit gestern läuft bei mir ein Easymeter Q3MA2100 (V6.02) mit IR-USB-Anbindung an 47_OBIS.pl in FHEM auf einem Raspberry Pi 3B+. Den Stromzähler habe ich gekauft und nach dem Ferraris-Hauszähler installieren lassen. Über die obere MSB-Schnittstelle kommt nur Unverständliches, aber über die vordere INFO-DSS-Schnittstelle kommt, was kommen soll (/dev/ttyUSB0@9600,8,N,1 SML). Das OBIS-Modul hat alle möglichen Readings angelegt, die einmal pro Sekunden aktualisiert werden. Das ist großartig - vielen Dank für das Modul!
List des device:
Internals:
CRC_Errors 6
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 11
FUUID 5d2ee439-f33f-abc2-ad14-1ebfc4653575fb2d
MeterType SML
NAME Stromzaehler
NR 61
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2019-07-17 23:12:07 1.0.0.0.0.255 31-30-32-36-32-38-36
2019-07-17 23:12:07 1.0.0.0.9.255 09-01-45-53-59-11-03-9D-4F-77
2019-07-17 23:12:07 1.0.36.7.0.255 20.42
2019-07-17 23:12:07 1.0.56.7.0.255 306.87
2019-07-17 23:12:07 1.0.76.7.0.255 103.49
2019-07-17 23:12:07 129.129.199.130.3.255 ESY
2019-07-17 23:12:07 129.129.199.130.5.255 A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17 22:35:26 Version ESY\090145535911039D4F77\31303236323836
2019-07-17 23:12:07 power 430.79
2019-07-17 21:28:17 state opened
2019-07-17 23:12:07 total_consumption 358502.7497
2019-07-17 23:12:07 total_consumption_Ch1 334082.8208
2019-07-17 23:12:07 total_consumption_Ch2 24419.9288
2019-07-17 23:12:07 voltage_L1 230.9
2019-07-17 23:12:07 voltage_L2 231.5
2019-07-17 23:12:07 voltage_L3 232.5
helper:
BUFFER v ESYMOw
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1563391697.44707
Channels:
DEVICES:
-1
directions:
Attributes:
room Keller
verbose 5
Leider schießt das Modul auch bei mir anscheinend ziemlich regelmäßig FHEM mit der Fehlermeldung PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364. ab.
Wie angeraten habe ich daher Loglevel auf 5 gestellt, um die Ursache zu finden. Das Ergebnis nach Absturz um 2019-07-17_21:04:48:
Log des Stromzähler-Device:
2019-07-17_21:04:43 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:43 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:43 Stromzaehler total_consumption: 355903.8245
2019-07-17_21:04:43 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:43 Stromzaehler total_consumption_Ch2: 24306.3177
2019-07-17_21:04:43 Stromzaehler power: 274.63
2019-07-17_21:04:43 Stromzaehler 1.0.36.7.0.255: 18
2019-07-17_21:04:43 Stromzaehler 1.0.56.7.0.255: 229.36
2019-07-17_21:04:43 Stromzaehler 1.0.76.7.0.255: 27.27
2019-07-17_21:04:43 Stromzaehler voltage_L1: 232.1
2019-07-17_21:04:43 Stromzaehler voltage_L2: 231.6
2019-07-17_21:04:43 Stromzaehler voltage_L3: 232.5
2019-07-17_21:04:43 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:43 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:04:44 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:44 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:44 Stromzaehler total_consumption: 355903.9008
2019-07-17_21:04:44 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:44 Stromzaehler total_consumption_Ch2: 24306.394
2019-07-17_21:04:44 Stromzaehler power: 274.75
2019-07-17_21:04:44 Stromzaehler 1.0.36.7.0.255: 17.93
2019-07-17_21:04:44 Stromzaehler 1.0.56.7.0.255: 229.49
2019-07-17_21:04:44 Stromzaehler 1.0.76.7.0.255: 27.32
2019-07-17_21:04:44 Stromzaehler voltage_L1: 232.1
2019-07-17_21:04:44 Stromzaehler voltage_L2: 231.7
2019-07-17_21:04:44 Stromzaehler voltage_L3: 232.5
2019-07-17_21:04:44 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:44 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:04:45 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:45 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:45 Stromzaehler total_consumption: 355903.9772
2019-07-17_21:04:45 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:45 Stromzaehler total_consumption_Ch2: 24306.4704
2019-07-17_21:04:45 Stromzaehler power: 274.82
2019-07-17_21:04:45 Stromzaehler 1.0.36.7.0.255: 17.93
2019-07-17_21:04:45 Stromzaehler 1.0.56.7.0.255: 229.62
2019-07-17_21:04:45 Stromzaehler 1.0.76.7.0.255: 27.26
2019-07-17_21:04:45 Stromzaehler voltage_L1: 232.1
2019-07-17_21:04:45 Stromzaehler voltage_L2: 231.7
2019-07-17_21:04:45 Stromzaehler voltage_L3: 232.6
2019-07-17_21:04:45 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:45 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:04:46 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:46 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:46 Stromzaehler total_consumption: 355904.0534
2019-07-17_21:04:46 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:46 Stromzaehler total_consumption_Ch2: 24306.5467
2019-07-17_21:04:46 Stromzaehler power: 274.59
2019-07-17_21:04:46 Stromzaehler 1.0.36.7.0.255: 17.93
2019-07-17_21:04:46 Stromzaehler 1.0.56.7.0.255: 229.5
2019-07-17_21:04:46 Stromzaehler 1.0.76.7.0.255: 27.15
2019-07-17_21:04:46 Stromzaehler voltage_L1: 232
2019-07-17_21:04:46 Stromzaehler voltage_L2: 231.7
2019-07-17_21:04:46 Stromzaehler voltage_L3: 232.4
2019-07-17_21:04:46 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:46 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:04:47 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:47 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:47 Stromzaehler total_consumption: 355904.1296
2019-07-17_21:04:47 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:47 Stromzaehler total_consumption_Ch2: 24306.6228
2019-07-17_21:04:47 Stromzaehler power: 274.09
2019-07-17_21:04:47 Stromzaehler 1.0.36.7.0.255: 17.86
2019-07-17_21:04:47 Stromzaehler 1.0.56.7.0.255: 229.05
2019-07-17_21:04:47 Stromzaehler 1.0.76.7.0.255: 27.17
2019-07-17_21:04:47 Stromzaehler voltage_L1: 231.9
2019-07-17_21:04:47 Stromzaehler voltage_L2: 231.6
2019-07-17_21:04:47 Stromzaehler voltage_L3: 232.4
2019-07-17_21:04:47 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:47 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:04:48 Stromzaehler 129.129.199.130.3.255: ESY
2019-07-17_21:04:48 Stromzaehler 1.0.0.0.9.255: 09-01-45-53-59-11-03-9D-4F-77
2019-07-17_21:04:48 Stromzaehler total_consumption: 355904.2057
2019-07-17_21:04:48 Stromzaehler total_consumption_Ch1: 331597.5067
2019-07-17_21:04:48 Stromzaehler total_consumption_Ch2: 24306.6989
2019-07-17_21:04:48 Stromzaehler power: 273.98
2019-07-17_21:04:48 Stromzaehler 1.0.36.7.0.255: 17.74
2019-07-17_21:04:48 Stromzaehler 1.0.56.7.0.255: 228.87
2019-07-17_21:04:48 Stromzaehler 1.0.76.7.0.255: 27.36
2019-07-17_21:04:48 Stromzaehler voltage_L1: 231.8
2019-07-17_21:04:48 Stromzaehler voltage_L2: 231.5
2019-07-17_21:04:48 Stromzaehler voltage_L3: 232.7
2019-07-17_21:04:48 Stromzaehler 129.129.199.130.5.255: A0B4-1C52-B0EF-C65F-7055-2DAD-ACC9-EF72-4697-9D68-9642-2477-DDAD-DCD1-3222-A3A0-423D-041F-2811-211A-B54B-9BB6-482F-C842-01
2019-07-17_21:04:48 Stromzaehler 1.0.0.0.0.255: 31-30-32-36-32-38-36
2019-07-17_21:28:28 Stromzaehler 129.129.199.130.3.255: ESY
FHEM-Log:
2019.07.17 21:04:46 5: SML-Parse 1B1B1B1B01010101760B4553594D4F77000576FD620062007263010176010445535908455359823176FD0B090145535911039D4F770101634EBD00760B4553594D4F77000576FE620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82317E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A6160177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D4F77000576FD620062007263010176010445535908455359823176FD0B090145535911039D4F770101634EBD00760B4553594D4F77000576FE620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82317E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A6160177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D4F77000576FD620062007263010176010445535908455359823176FD0B090145535911039D4F770101634EBD00760B4553594D4F77000576FE620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82317E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A6160177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A6160177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100010800FF6400028001621E52FC5900000000D422A6160177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100010802FF0101621E52FC59000000000E7CE27B0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100100700FF0101621B52FE590000000000006B430177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000007010177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100380700FF0101621B52FE5900000000000059A601770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=01770701004C0700FF0101621B52FE590000000000000A9B0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100200700FF0101622352FF6309100177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100340700FF0101622352FF63090D0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=0177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 5: OBIS: Telegram=77070100000000FF010101010831303236323836010101633BA200760B4553594D4F77000576FF6200620072630201710163F57200001B1B1B1B1A01BC29
2019.07.17 21:04:46 4: MSG IS:
/ESY\090145535911039D4F77\31303236323836
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039D4F77)
1-0:1.8.0*255(355904.0534*Wh)
1-0:1.8.1*255(331597.5067*Wh)
1-0:1.8.2*255(24306.5467*Wh)
1-0:16.7.0*255(274.59*W)
1-0:36.7.0*255(17.93*W)
1-0:56.7.0*255(229.5*W)
1-0:76.7.0*255(27.15*W)
1-0:32.7.0*255(232*V)
1-0:52.7.0*255(231.7*V)
1-0:72.7.0*255(232.4*V)
129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
1-0:0.0.0*255(31303236323836)
!
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: /ESY\090145535911039D4F77\31303236323836
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2019.07.17 21:04:46 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039D4F77)
2019.07.17 21:04:46 5: Msg 1-0:0.0.9*255(090145535911039D4F77) is of type Serial
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(355904.0534*Wh)
2019.07.17 21:04:46 5: Msg 1-0:1.8.0*255(355904.0534*Wh) is of type Counter
2019.07.17 21:04:46 4: Set total_consumption to 355904.0534
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(331597.5067*Wh)
2019.07.17 21:04:46 5: Msg 1-0:1.8.1*255(331597.5067*Wh) is of type Counter
2019.07.17 21:04:46 4: Set total_consumption_Ch1 to 331597.5067
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(24306.5467*Wh)
2019.07.17 21:04:46 5: Msg 1-0:1.8.2*255(24306.5467*Wh) is of type Counter
2019.07.17 21:04:46 4: Set total_consumption_Ch2 to 24306.5467
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(274.59*W)
2019.07.17 21:04:46 5: Msg 1-0:16.7.0*255(274.59*W) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:36.7.0*255(17.93*W)
2019.07.17 21:04:46 5: Msg 1-0:36.7.0*255(17.93*W) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:56.7.0*255(229.5*W)
2019.07.17 21:04:46 5: Msg 1-0:56.7.0*255(229.5*W) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:76.7.0*255(27.15*W)
2019.07.17 21:04:46 5: Msg 1-0:76.7.0*255(27.15*W) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:32.7.0*255(232*V)
2019.07.17 21:04:46 5: Msg 1-0:32.7.0*255(232*V) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:52.7.0*255(231.7*V)
2019.07.17 21:04:46 5: Msg 1-0:52.7.0*255(231.7*V) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:72.7.0*255(232.4*V)
2019.07.17 21:04:46 5: Msg 1-0:72.7.0*255(232.4*V) is of type Channels
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
2019.07.17 21:04:46 5: Msg 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201) is of type PublicKey
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.0*255(31303236323836)
2019.07.17 21:04:46 5: Msg 1-0:0.0.0*255(31303236323836) is of type Owner
2019.07.17 21:04:46 5: OBIS (Stromzaehler) - Msg-Parse: !
2019.07.17 21:04:47 5: SML-Parse 1B1B1B1B01010101760B4553594D4F7700057700620062007263010176010445535908455359823277000B090145535911039D4F77010163AE3100760B4553594D4F7700057701620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82327E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A9100177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D4F7700057700620062007263010176010445535908455359823277000B090145535911039D4F77010163AE3100760B4553594D4F7700057701620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82327E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A9100177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D4F7700057700620062007263010176010445535908455359823277000B090145535911039D4F77010163AE3100760B4553594D4F7700057701620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82327E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A9100177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422A9100177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100010800FF6400028001621E52FC5900000000D422A9100177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100010802FF0101621E52FC59000000000E7CE5740177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100100700FF0101621B52FE590000000000006B110177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000006FA0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100380700FF0101621B52FE59000000000000597901770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=01770701004C0700FF0101621B52FE590000000000000A9D0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100200700FF0101622352FF63090F0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100340700FF0101622352FF63090C0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177070100480700FF0101622352FF6309140177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=0177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 5: OBIS: Telegram=77070100000000FF01010101083130323632383601010163A0C000760B4553594D4F770005770262006200726302017101631F8C00001B1B1B1B1A013AA0
2019.07.17 21:04:47 4: MSG IS:
/ESY\090145535911039D4F77\31303236323836
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039D4F77)
1-0:1.8.0*255(355904.1296*Wh)
1-0:1.8.1*255(331597.5067*Wh)
1-0:1.8.2*255(24306.6228*Wh)
1-0:16.7.0*255(274.09*W)
1-0:36.7.0*255(17.86*W)
1-0:56.7.0*255(229.05*W)
1-0:76.7.0*255(27.17*W)
1-0:32.7.0*255(231.9*V)
1-0:52.7.0*255(231.6*V)
1-0:72.7.0*255(232.4*V)
129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
1-0:0.0.0*255(31303236323836)
!
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: /ESY\090145535911039D4F77\31303236323836
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2019.07.17 21:04:47 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039D4F77)
2019.07.17 21:04:47 5: Msg 1-0:0.0.9*255(090145535911039D4F77) is of type Serial
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(355904.1296*Wh)
2019.07.17 21:04:47 5: Msg 1-0:1.8.0*255(355904.1296*Wh) is of type Counter
2019.07.17 21:04:47 4: Set total_consumption to 355904.1296
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(331597.5067*Wh)
2019.07.17 21:04:47 5: Msg 1-0:1.8.1*255(331597.5067*Wh) is of type Counter
2019.07.17 21:04:47 4: Set total_consumption_Ch1 to 331597.5067
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(24306.6228*Wh)
2019.07.17 21:04:47 5: Msg 1-0:1.8.2*255(24306.6228*Wh) is of type Counter
2019.07.17 21:04:47 4: Set total_consumption_Ch2 to 24306.6228
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(274.09*W)
2019.07.17 21:04:47 5: Msg 1-0:16.7.0*255(274.09*W) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:36.7.0*255(17.86*W)
2019.07.17 21:04:47 5: Msg 1-0:36.7.0*255(17.86*W) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:56.7.0*255(229.05*W)
2019.07.17 21:04:47 5: Msg 1-0:56.7.0*255(229.05*W) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:76.7.0*255(27.17*W)
2019.07.17 21:04:47 5: Msg 1-0:76.7.0*255(27.17*W) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:32.7.0*255(231.9*V)
2019.07.17 21:04:47 5: Msg 1-0:32.7.0*255(231.9*V) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:52.7.0*255(231.6*V)
2019.07.17 21:04:47 5: Msg 1-0:52.7.0*255(231.6*V) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:72.7.0*255(232.4*V)
2019.07.17 21:04:47 5: Msg 1-0:72.7.0*255(232.4*V) is of type Channels
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
2019.07.17 21:04:47 5: Msg 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201) is of type PublicKey
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.0*255(31303236323836)
2019.07.17 21:04:47 5: Msg 1-0:0.0.0*255(31303236323836) is of type Owner
2019.07.17 21:04:47 5: OBIS (Stromzaehler) - Msg-Parse: !
2019.07.17 21:04:48 5: SML-Parse 1B1B1B1B01010101760B4553594D4F7700057703620062007263010176010445535908455359823377030B090145535911039D4F7701016340C000760B4553594D4F7700057704620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82337E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AC090177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D4F7700057703620062007263010176010445535908455359823377030B090145535911039D4F7701016340C000760B4553594D4F7700057704620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82337E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AC090177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D4F7700057703620062007263010176010445535908455359823377030B090145535911039D4F7701016340C000760B4553594D4F7700057704620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82337E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AC090177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AC090177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100010800FF6400028001621E52FC5900000000D422AC090177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100010802FF0101621E52FC59000000000E7CE86D0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100100700FF0101621B52FE590000000000006B060177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100240700FF0101621B52FE5900000000000006EE0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100380700FF0101621B52FE59000000000000596701770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=01770701004C0700FF0101621B52FE590000000000000AB00177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177070100480700FF0101622352FF6309170177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=0177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 5: OBIS: Telegram=77070100000000FF010101010831303236323836010101634B4800760B4553594D4F77000577056200620072630201710163F92C00001B1B1B1B1A01B025
2019.07.17 21:04:48 4: MSG IS:
/ESY\090145535911039D4F77\31303236323836
129-129:199.130.3*255(ESY)
1-0:0.0.9*255(090145535911039D4F77)
1-0:1.8.0*255(355904.2057*Wh)
1-0:1.8.1*255(331597.5067*Wh)
1-0:1.8.2*255(24306.6989*Wh)
1-0:16.7.0*255(273.98*W)
1-0:36.7.0*255(17.74*W)
1-0:56.7.0*255(228.87*W)
1-0:76.7.0*255(27.36*W)
1-0:32.7.0*255(231.8*V)
1-0:52.7.0*255(231.5*V)
1-0:72.7.0*255(232.7*V)
129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
1-0:0.0.0*255(31303236323836)
!
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: /ESY\090145535911039D4F77\31303236323836
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.3*255(ESY)
2019.07.17 21:04:48 5: Msg 129-129:199.130.3*255(ESY) is of type ManufID
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.9*255(090145535911039D4F77)
2019.07.17 21:04:48 5: Msg 1-0:0.0.9*255(090145535911039D4F77) is of type Serial
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(355904.2057*Wh)
2019.07.17 21:04:48 5: Msg 1-0:1.8.0*255(355904.2057*Wh) is of type Counter
2019.07.17 21:04:48 4: Set total_consumption to 355904.2057
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.1*255(331597.5067*Wh)
2019.07.17 21:04:48 5: Msg 1-0:1.8.1*255(331597.5067*Wh) is of type Counter
2019.07.17 21:04:48 4: Set total_consumption_Ch1 to 331597.5067
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.2*255(24306.6989*Wh)
2019.07.17 21:04:48 5: Msg 1-0:1.8.2*255(24306.6989*Wh) is of type Counter
2019.07.17 21:04:48 4: Set total_consumption_Ch2 to 24306.6989
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(273.98*W)
2019.07.17 21:04:48 5: Msg 1-0:16.7.0*255(273.98*W) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:36.7.0*255(17.74*W)
2019.07.17 21:04:48 5: Msg 1-0:36.7.0*255(17.74*W) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:56.7.0*255(228.87*W)
2019.07.17 21:04:48 5: Msg 1-0:56.7.0*255(228.87*W) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:76.7.0*255(27.36*W)
2019.07.17 21:04:48 5: Msg 1-0:76.7.0*255(27.36*W) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:32.7.0*255(231.8*V)
2019.07.17 21:04:48 5: Msg 1-0:32.7.0*255(231.8*V) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:52.7.0*255(231.5*V)
2019.07.17 21:04:48 5: Msg 1-0:52.7.0*255(231.5*V) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:72.7.0*255(232.7*V)
2019.07.17 21:04:48 5: Msg 1-0:72.7.0*255(232.7*V) is of type Channels
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201)
2019.07.17 21:04:48 5: Msg 129-129:199.130.5*255(A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC84201) is of type PublicKey
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.0*255(31303236323836)
2019.07.17 21:04:48 5: Msg 1-0:0.0.0*255(31303236323836) is of type Owner
2019.07.17 21:04:48 5: OBIS (Stromzaehler) - Msg-Parse: !
2019.07.17 21:04:49 5: SML-Parse 1B1B1B1B01010101760B4553594D4F7700057706620062007263010176010445535908455359823477060B090145535911039D4F7701016301F200760B4553594D4F7700057707620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82347E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AF020177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CEB660177070100100700FF0101621B52FE590000000000006B0C0177070100240700FF0101621B52FE5900000000000006EC0177070100380700FF0101621B52FE59000000000000597001770701004C0700FF0101621B52FE590000000000000AAE0177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309180177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634E7200760B4553594D4F77000577086200620072630201710163979B00001B1B1B1B1A0146BC
2019.07.17 21:04:49 5: OBIS: Full message-> 1B1B1B1B01010101760B4553594D4F7700057706620062007263010176010445535908455359823477060B090145535911039D4F7701016301F200760B4553594D4F7700057707620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82347E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AF020177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CEB660177070100100700FF0101621B52FE590000000000006B0C0177070100240700FF0101621B52FE5900000000000006EC0177070100380700FF0101621B52FE59000000000000597001770701004C0700FF0101621B52FE590000000000000AAE0177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309180177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634E7200760B4553594D4F77000577086200620072630201710163979B00001B1B1B1B1A0146BC
2019.07.17 21:04:49 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D4F7700057706620062007263010176010445535908455359823477060B090145535911039D4F7701016301F200760B4553594D4F7700057707620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EC82347E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000D422AF020177070100010801FF0101621E52FC5900000000C5A5C39B0177070100010802FF0101621E52FC59000000000E7CEB660177070100100700FF0101621B52FE590000000000006B0C0177070100240700FF0101621B52FE5900000000000006EC0177070100380700FF0101621B52FE59000000000000597001770701004C0700FF0101621B52FE590000000000000AAE0177070100200700FF0101622352FF63090E0177070100340700FF0101622352FF63090B0177070100480700FF0101622352FF6309180177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF010101010831303236323836010101634E7200760B4553594D4F77000577086200620072630201710163979B00001B1B1B1B1A0146BC
2019.07.17 21:04:49 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Es wäre wirklich schade, wenn Kauf und Einbau umsonst gewesen wären. Lässt sich aus diesen Daten erkennen, was das Problem ist?
Danke und Grüße
frankbatzen
Nächster Absturz, diesmal nach folgendem Telegram:
2019.07.19 09:29:25 5: OBIS: Telegram=1B1B1B1B01010101760B4553594D4F77000B7706620062007263010176010445535908455359823477060B090145535911039D4F77010163976A00760B4553594D4F77000B7707620062007263070177010B090145535911039D4F77080100620AFFFF007262016500EE82347E77078181C78203FF01010101044553590177070100000009FF010101010B090145535911039D4F770177070100010800FF6400028001621E52FC5900000000E6C646470177070100010801FF0101621E52FC5900000000CCBB0D370177070100010802FF0101621E52FC59000000001A0B39100177070100100700FF0101621B52FE59000000000000840B0177070100240700FF0101621B52FE5900000000000006A10177070100380700FF0101621B52FE5900000000000062B901770701004C0700FF0101621B52FE590000000000001AB00177070100200700FF0101622352FF6308F30177070100340700FF0101622352FF6308F50177070100480700FF0101622352FF6308F10177078181C78205FF010101018302A0B41C52B0EFC65F70552DADACC9EF7246979D6896422477DDADDCD13222A3A0423D041F2811211AB54B9BB6482FC8420177070100000000FF01010101083130323632383601010163B27F00760B4553594D4F77000B7708620062007263020171016311AB00001B1B1B1B1A010B1F
2019.07.19 09:29:25 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 364.
Gruß
frankbatzen
...möglicherweise war meine Version des OBIS Moduls nicht aktuell. Mein FHEM Update brach aufgrund von Problemen mit Dateirechten ab, was ich möglicherweise erst jetzt bemerkt habe. Seit dem das korrigiert ist und alle Module aktuell sind, hatte ich bislang keine Abstürze mehr.
Also, auch wenn das hier ein Selbstgespräch ist: Meine Probleme habe ich wahrscheinlich selbst verursacht - das Modul scheint gut zu funktionieren.
Gruß
frankbatzen
Hi,
ich habe die gleichen Probleme wie du, auch mit aktueller Modulversion. Leider läuft es nur mal Stunden mal Tage mal Wochen. Ich hatte hier schon mehrmal mit logs geschrieben, leider gibt es keine Lösung.
Moin liebes Forum,
ich habe vor einem guten Monat von meinem Netzversorger eine moderne Messeinrichtung erhalten (siehe Bild).
Den digitalen Stromzähler kann ich via Taschenlampe "steuern" und mir unterschiedliche Messwerte anzeigen lassen.
Meine Frage: Kann ich per IR Lesekopf Daten von dem Zähler auslesen via OBIS Modul?
Da alle Stromzähler leider im Keller sind und ich im 1.OG wohne, wird es von der Reichweite mit WLAN extrem schwer.
Ggf. komme ich mit meiner HomeMatic Reichweite bis in den Keller, dies müsste ich mit einem Sensor mal "testen".
Gruß
Mathze
Hallo,
Du müßtest schon rausfinden, ob Dein Zähler die Daten per IR ausgibt und das SML-Protokoll unterstützt wird.
Gruß
Blueberry63
...wenn du das rausgefunden hast, kannst du ggf. auch einen IR-Lesekopf (du brauchst nur den Leseteil, also angeblich soll das auch mit einem IT-Transistor an einem GPIO vom ESP gehen)an einen ESP8266 mit ESPLink (ESPEasy war bei mir nicht stabil genug, da hat sich das mehrmals am Tag abgehängt) über WLAN anbinden, das läuft bei mir auch über mehrere Räume und durch diverse Mauern durch... evtl. mal nach "Udos Volkszähler" googlen...
Hallo eisenhauer1987,
Du hast leider recht. Ich hatte zum Zeitpunkt meines letzten Postings wohl nur zufällig eine längere absturzfreie Zeit. Ich habe jetzt einen cronjob, der minütlich überprüft, ob FHEM noch läuft und - wenn nicht - neu startet :-\. Das passiert jetzt im Schnitt einmal am Tag. Manchmal nach 3 Tagen, manchmal 3 mal am Tag.
Gruß,
frankbatzen
Hallo zusammen,
ich habe mal eine Frage zur Definition der Schnittstelle bei der OBIS-Integration. Hoffe, die Frage kam nicht schon irgendwo - hab den Thread und die CommandRef durchstöbert, bin aber leider nicht fündig geworden.
Wofür steht denn die Angabe:
[...]8,N,1[...]
nach der Baudrate?
Ich habe meinen Lesekopf so eingebunden:
define MyStromzaehler OBIS /dev/ttyUSB0@9600 SML
Und erhalte die Werte für Bezug, Lieferung, Hersteller und Seriennummer - allerdings nicht mehr.
Meine Fragen sind nun:
Was bewirken diese Angaben?
Brauche ich diese Erweiterung an der Schnittstelle (egal, ob 8,N,1 oder 7,N,1)?
Wenn ja, woher weiß ich, welche dieser Angaben die richtigen sind?
Gruß
Kptkip
ZitatBrauche ich diese Erweiterung an der Schnittstelle (egal, ob 8,N,1 oder 7,N,1)?
Wenn ja, woher weiß ich, welche dieser Angaben die richtigen sind?
Klar brauchst Du das. Ohne korrekte Angabe gibt es Datensalat.
Die Parameter beziehen sich neben der Baudrate auf die serielle Schnittstelle: anz. Datenbits, Parität,Stopbits
Entweder probierst Du die Varianten aus(in der Regel 8,N,1) oder Du bekommst sie vom Hersteller des devices(in inserem Fall also vom Zählerhersteller).
Hallo,
danke für den Tipp, dann muss ich mal forschen, was der Zähler so haben will. Es ist ein Gerät von EMH.
ZitatKlar brauchst Du das. Ohne korrekte Angabe gibt es Datensalat.
Meine Beobachtung bisher ist komischerweise die, dass ich keine Unterschiede erkenne, wenn ich die Werte mit angebe oder nicht. Der Zähler wird auch ohne Angabe genauso ausgelesen. Die Werte sind auch genau die, die ich am Zähler sehe.
Ich gebe aber nochmal Rückmeldung, ob sich an anderer Stelle noch ein Unterschied ergibt.
Gruß
kptkip
Einer meiner Zähler ist auch ein EMH und funktioniert mit 8,N,1.
Mit der Ergänzung funktioniert es. Vielen Dank!
Gibt Dir der Zähler auch nur ganze kWh aus? Ich finde das etwas zu grobgranular. Auch einen aktuellen Verbrauch in kW/W, der raus- oder reingeht, fände ich super.
8N1 ist mehr oder weniger der Standard im RS232-Bereich, oder sagen wir besser "das gängigste".
Wenn du bei der Baudrate keine Angaben machst, nimmt das System automatisch das als Vorgabe.
Wenn du so Daten bekommst, passt das. Du wirst nicht mehr Daten vom Zähler bekommen, wenn du da was änderst, im Gegenteil: Mit anderen Werten bekommst du Datensalat und somit dann GAR KEINE Werte mehr :)
lg, Stefan
ZitatGibt Dir der Zähler auch nur ganze kWh aus? Ich finde das etwas zu grobgranular. Auch einen aktuellen Verbrauch in kW/W, der raus- oder reingeht, fände ich super.
Ich bin in der glücklichen Lage, die rückwärtige Msb-Schnittstelle abgreifen zu können. 8)
Evtl. kann Dir der Msb einen Pincode geben, dass Du mehr Infos freischalten kannst.
Zitat von: frankbatzen am 09 August 2019, 09:17:53
Hallo eisenhauer1987,
Du hast leider recht. Ich hatte zum Zeitpunkt meines letzten Postings wohl nur zufällig eine längere absturzfreie Zeit. Ich habe jetzt einen cronjob, der minütlich überprüft, ob FHEM noch läuft und - wenn nicht - neu startet :-\. Das passiert jetzt im Schnitt einmal am Tag. Manchmal nach 3 Tagen, manchmal 3 mal am Tag.
Gruß,
frankbatzen
Hi,
wie heißt dein Zähler, eventuell lässt sich das Thema so eingrenzen...Aber insgesamt ist die Situation sehr unbefriedigend.
Ich habe mir diesen und andere Threads zum Thema "eletronischen Zähler" auslesen schon mehrfach durchgelesen. Blicke aber nicht wirklich durch.
Ich bin hier in Köln bei der Rhein Energie und habe den Iskra Zähler MT691 mit dem nötigen Pin erhalten. Jetzt habe ich hier im Forum gelesen, das es einige gibt die das mit Volkzähler machen, andere mit dem Obis Modul und div. Leseköpfen und auch andere Varianten. Ich habe aber keine zusammenhängende Konstellation gefunden, wo ich als Neuling mit dieser Thematik was anfangen kann. Mein Zähler hängt im Keller, Lan Anschluss ist vorhanden, mein Raspi steht in der 1.Etage. Was brauche ich dann für eine Hardware. Welchen Lesekopf, und wie schließe ich den am entfernten Raspi an. Einen zweiten Raspi zu installieren möchte ich vermeiden (kriege ich wahrscheinlich nicht ans laufen.....?). Wo finde ich eine Anleitung dazu, was man braucht und wie so was einfach zu bewerkstelligen ist?
Wer kann mir dazu einen Rat oder Tip geben, damit ich sowas auch ans laufen kriege.
Gruß aus Köln
Norbert
Hallo Norbert,
ist relativ simpel: Volkszähler nutzen unsinnigerweise die, die Volkszähler vor FHEM hatten und nicht auf OBIS umgestiegen sind. Volkszähler hat den Nachteil, dass es außerhalb von FHEM ein eigenständiger Server ist. Vielleicht den Vorteil, dass Grafiken, Statistiken etc. sicherlich schon vorgefertigt sind.
OBIS nutzt dieselbe Technik: IR-Zähler-serieller IR-Lesekopf-USB-Konverter. Vorteil: keine Fremdapplikation, unendliche Darstellungsmöglichkeiten....FHEM halt. Bekommst Du die Technik nicht ans rennen, kannst Du hier fragen. 8)
ZitatWer kann mir dazu einen Rat oder Tip geben, damit ich sowas auch ans laufen kriege.
USB müsste auf die Entfernung noch funktionieren. :-\ Ggfs. kann ich Dir Vor-Ort-Support bieten. ;)
Grüße Markus
@KölnSolar
Hallo Markus,
vielen Dank für deine Hinweise und dein Hilfeangebot. Als IR Lesekopf kann ich ja sicherlich den USB Optokopf von Weidmann benutzen? Den habe ich hier oft in den Foren wieder gefunden. Den kann ich ja dann vom Keller aus an den Raspi mit einer ca. 10m USB Verlängerung anschließen. Und du meinst das ist nicht zu lang und müßte noch funktionieren?.
Gruß aus "Kölle"
Norbert
Hallo,
ich bin auch nicht so technisch beschlagen und suche eine Anbindung mittels Udos IR-Lesekopf an den Rechner, auf dem FHEM woanders im Haus läuft.
Anbindung über LAN ist vorhanden.
Wenn ich die Schritte richtig verstanden haben, schließe ich den IR-Lesekopf an einen Raspi-USB-Eingang an.
Falls das passende Image (über volkszaehler.org?) im Raspi läuft, wird der Lesekopf gefunden.
Wie bekommt man jetzt die Anbindung Raspi an FHEM-Rechner hin, um dort die Daten zu verarbeiten?
Ein Link auf einen entsprechenden Beitrag würde reichen.
Vielen Dank!
Hallo,
hat der Lesekopf denn überhaupt einen USB-Anschluss ? Meiner hatte nämlich nur 4 Drähte.... die Habe ich dann an einen ESP8266 angeschlossen und mit ESPLink dann an FHEM angeschlossen. Dafür braucht man dann keinen ganzen Raspi opfern, der dann nur den Lesekopf bedient...
Grüße
Christian
Ja, USB-Anschluss ist vorhanden.
Wie kommt man bitte am einfachsten auf dem FHEM-Rechner an die Daten?
ZitatWie kommt man bitte am einfachsten auf dem FHEM-Rechner an die Daten?
OBIS-Modul
ZitatFalls das passende Image (über volkszaehler.org?) im Raspi läuft, wird der Lesekopf gefunden.
Mit Volkszähler hat man dann nichts mehr am Hut. In FHEM das OBIS-device definiert und fertig.
Zitathat der Lesekopf denn überhaupt einen USB-Anschluss ? Meiner hatte nämlich nur 4 Drähte.... die Habe ich dann an einen ESP8266 angeschlossen und mit ESPLink dann an FHEM angeschlossen.
Die Standard-Leseköpfe haben kein USB, sondern RJ11(oder 12...?). Mit einer Wandlerplatine(RS232-USB) oder eben Deiner WLAN-Lösung wird an den Rpi angebunden.
ZitatAls IR Lesekopf kann ich ja sicherlich den USB Optokopf von Weidmann benutzen? Den habe ich hier oft in den Foren wieder gefunden. Den kann ich ja dann vom Keller aus an den Raspi mit einer ca. 10m USB Verlängerung anschließen. Und du meinst das ist nicht zu lang und müßte noch funktionieren?.
2-mal "ich vermute" ;) Weidmann wird wohl klappen u. 10m auch. Mit "Standardlesekopf" u. RS232-USB-Wandler lässt sich schon der USB-Anschluss in die 1. Etage legen und zwischen Keller u. 1.OG liegt der RS232-Bus.
Nun, wenn am Ende meines IR-Optokopplers eine normale USB-Kupplung ist, ist es kaum zu bestreiten, dass hier ein USB-Anschluss vorliegt.
Wenn der Rechner mit FHEM direkt neben dem Stromzähler laufen würde wäre das kein Problem.
Dann könnte man in FHEM mit OBIS direkt auswerten.
Da der Rechner mit FHEM aber eben woanders steht, muss man hier eine andere Lösung finden.
Die USB-Kupplung abschneiden, um irgendwelche Drähte mit dem vorgeschlagenen WLAN-Modul zu verbinden, wäre nicht mein Ding.
Also gibt es nur die Raspi-Zwischenlösung?
Und in FHEM verweise ich dann statt auf den USB-Port auf was?
define myPowerMeter OBIS /dev/ttyPlugwise@@9600,7,E,1 VSM102
ZitatAlso gibt es nur die Raspi-Zwischenlösung?
irgendwie musst Du ja nun mal "verbinden". Wenn kein RS232-Kabel, USB-Kabel, ESP-WLAN, fiele mir noch ein USB-LAN-Adapter ein. Ansonsten nur über einen weiteren Server.
Definition bei LAN/WLAN weiß cs-online besser. ser2net ? :-\ Bei der Serverlösung FHEM2FHEM ? :-\
ZitatDa der Rechner mit FHEM aber eben woanders steht, muss man hier eine andere Lösung finden.
Bei mir ist der Sicherungskasten auch "woanders" und daher benutze ich ebenfalls einen RPI2 mit separater FHEM-Instanz. Der "zieht" nach eigener Messung ca. 1,9 Watt Wirkleistung. Das Wattjahr kostet ca. 2,5 Euronen. Ein Weizenbier weniger im Jahr und ... ;)
Mein RPI1 braucht nach eigener Messung übrigens fast das Doppelte gegenüber dem RPI2.
Die Übertragung der gemessenen Daten an ein (gleichnamiges) Dummy in meiner "Haupt-FHEM-Instanz" mache ich mit einem simplen GetFileFromURL in einem Notify alle 30 Sekunden. FHEM2FHEM macht das ja ähnlich und noch einiges mehr, was unnötig ist.
Hier das Notify dazu:
Stromzaehler.power:..+ {
$EVTPART0 =~ s/://;
GetFileFromURL "http://192.168.0.XX:8083/fhem?XHR=1&cmd=setreading%20${NAME}%20${EVTPART0}%20$EVTPART1", 1;
}
Nachdem ich den ganzen Nachmittag damit zugebracht habe eine USB Leitung durch Decken und Kamin zu ziehen und auch noch genug gebohrt habe, ist es vollbracht. Die USB Verbindung zum Zähler und zum Raspi steht und funktioniert. Nur kommen recht wenig Daten bei mit an für einen Zweirichtungszähler.
define ISKRA_MT691 OBIS /dev/ttyUSB0@9600,8,N,1 SML
setuuid ISKRA_MT691 5d6a8b10-f33f-6f9b-51f5-096f290c6e0079b0
attr ISKRA_MT691 alias Stromzähler ISKRA MT691
attr ISKRA_MT691 event-min-interval .*:30
Und was vom Zähler zurück kommt sieht so aus:
Internals:
CHANGED
CRC_Errors 47
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 39
FUUID 5d6a8b10-f33f-6f9b-51f5-096f290c6e0079b0
MeterType SML
NAME ISKRA_MT691
NR 1449
PARTIAL
STATE opened
TYPE OBIS
OLDREADINGS:
READINGS:
2019-08-31 18:49:49 1.0.96.50.1.255 ISK
2019-08-31 18:49:49 power -142
2019-08-31 18:24:53 state opened
2019-08-31 18:49:49 total_consumption 1167863.3
2019-08-31 18:49:49 total_feed 8894431.4
helper:
BUFFER
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1567268693.02526
Channels:
DEVICES:
-1
directions:
Attributes:
alias Stromzähler ISKRA MT691
event-min-interval .*:30
group Systemkontrolle
room System
Muß man an dem Zähler noch irgendwelche Einstellungen im Menü vornehmen oder einen bestimmten Menüpunkt aktivieren/deaktivieren, das der mehr Infos rausgibt?
oder woran liegt es?
Gruß aus Köln
Norbert
ZitatNachdem ich den ganzen Nachmittag damit zugebracht habe eine USB Leitung durch Decken und Kamin zu ziehen und auch noch genug gebohrt habe
Du hast Dich bestimmt nur vor Gartenarbeit bei Ü30° in den kühlen Keller verdrückt. ;D
Das Modul spuckt alles aus was ankommt. Das nennt man bei der R... wohl Fortschritt. :o ::) :'( Früher gab es Hager-Zähler mit tollen Daten/Phase. :-X
Ist Deine PV größer 7 kW ?
Grüße Markus
Ich habe eine 10kW Solaranlage im Garten auf der Garage stehen und eine 10KW Speicherbatterie im Keller und möchte deshalb so viele Daten wie möglich auslesen.
Die Daten der Wechselrichter, des Solarlogs, der Batteriesteuerung und von der Batterie habe ich bereits ausgelesen. Aber mich würden natürlich die Einspeise- und Bezugsdaten interessieren, weil ich die nur direkt am Zweirichtungszähler kriegen kann.
Gruß
Norbert
Dann wirst Du ja irgendwann ::) mit dem Schwachsinn "intelligente Messeinrichtung" zwangsbeglückt. Kostet 100 EUR/Jahr bei R.. :o Da empfehle ich den Messstellenbetreiber zu wechseln. ;) Dann gibt es auch mehr Daten. ;D
Einen Erzeugungszähler hast Du auch noch (bei > 10 kWp) ?
Die Anlage habe ich 2011 gebaut und die hat genau 9750 Watt und fällt deshalb noch nicht in die >10KW Regelung.
Wo bekomme ich dann raus welche Daten der Zähler eigendlich rausgibt?
Gruß
Norbert
Wenn der Zähler wirklich nur diese 3 Werte von sich gibt muß ich wohl damit leben. Was mich aber noch an der Ausgabe stört ist, das es keine einzelnen Werte für Bezug und Einspeisung gibt. Diese werden unter "power" mit positiven und negativen Vorzeichen ausgegeben. Meine Idee dazu: Zwei Userreadings anlegen und diese je nach Vorzeichen mit den "power" Werten füllen. Negative Werte sind Einspeisung und positive sind Bezug. Wobei der Einspeisewert ohne das "-" Zeichen übergeben werden müßte.
attr ISKRA_MT691 userReadings Verbrauch {ReadingsVal("ISKRA_MT691","power","")},Bezug {ReadingsVal("ISKRA_MT691","power","")}
Jetzt müßte ich noch die ">0" Werte dem Bezug und die "<0" Werte der Einspeisung ohne "-" zuordnen und bei Nichtzutreffen die Werte auf "0" setzen.
Kann man das in direkt in der "attr ISKRA_MT691 userReadings......." Zeile machen oder muß ich das mit IF/ELSE oder mit DOIF bewerkstelligen.
Hat jemand vielleicht eine Lösung oder Hinweis wie ich das hin kriege? Oder geht das so nicht?
Gruß aus Köln
Norbert
ZitatWas mich aber noch an der Ausgabe stört ist, das es keine einzelnen Werte für Bezug und Einspeisung gibt. Diese werden unter "power" mit positiven und negativen Vorzeichen ausgegeben.
Das ist normal.
userReadings sind der richtige Lösungsansatz. Allerdings nur nach Vorzeichen auszuwerten ist ein wenig sinnfrei. Wichtigste Größe ist ja eigentlich der Verbrauch/Leistung. Bei mir über den Erzeugungszähler ermittelbar. Bei Dir aus Solarlog-Daten(ggfs. Batterie).
Weil ziemlich OT, schicke ich Dir ne PN.
Über Solarlog läßt sich nicht der Einspeise wert ermitteln, weil dort immer der Ladestrom der Batterie mitgerechnet wird, den ich aber einzeln nicht bekomme. Deshalb habe ich ja den Zweirichtungszähler angezapft. Genauer geht es ja nicht. Und ich finde das nicht unbedingt sinnfrei, weil ich keine andere Möglichkeit sehe die Daten aus dem Zähler sonst zu differenzieren. Deshalb habe ich bis jetzt diese Lösung bevorzugt, solange es nix besseres gibt.
define ISKRA_MT691_notify notify ISKRA_MT691 { my $Strom = ReadingsVal("ISKRA_MT691", "power", " ") ;; {if ($Strom > 0) {fhem ("setreading ISKRA_MT691 Bezug $Strom");;} else {if ($Strom <= 0) {fhem ("setreading ISKRA_MT691 Bezug 0");;{if ($Strom < 0) {fhem ("setreading ISKRA_MT691 Einspeisung $Strom");;} else {if ($Strom >= 0) {fhem ("setreading ISKRA_MT691 Einspeisung 0");;}}}}}}}
So funktioniert es zumindest mit den Werten. An dieser Stelle müßte aber noch das Minusvorzeichen "verschwinden". Ich habe überall geguckt. Nichts gefunden außer der Perl-Funktion "abs". Da weiß ich aber nicht wie ich die hier einbauen kann.
{if ($Strom > 0) {fhem ("setreading ISKRA_MT691 Bezug $Strom")
Kann mir da einer weiterhelfen?
Gruß aus Kölle
Norbert
Hallo zusammen
Habe eine Frage. Wir haben bei uns einen AS3000 Zähler von Elster. Jetzt beherrschst der Zähler aber nur EN 62056-21 Protokoll (wie Landis&Gyr E110 oder E350).
Von Volkszähler gibt es eine Anleitung zum auslesen dieses Zählers (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as3000).
Jedoch möchte ich den Zähler mit FHEM auslesen. Gibt es dafür eine Möglichkeit, diesen in das Modul zu Pflegen, oder habe ich etwas übersehen?
Gruss Ichotolot85
Guck mal hier zur Definition eines E110 (https://forum.fhem.de/index.php/topic,53906.msg455255.html#msg455255).
Zitat von: KölnSolar am 03 September 2019, 08:03:57
Guck mal hier zur Definition eines E110 (https://forum.fhem.de/index.php/topic,53906.msg455255.html#msg455255).
Vielen Dank KölnSolar, so hat das auslesen funktioniert.
Als Input für eine zukünftige 47_OBIS Version wäre eine Lösung für das Problem, welches auch in diesem Artikel vorhanden ist (Initalkommando 300 Baud und Umstellung auf 9600 Baud).
Zitat von: hypetsch am 27 Mai 2016, 21:57:50
1) Ein kompletter Auslesezyklus über 3 Minuten
Das Auslesen funktioniert scheinbar nur mit 300 Baud. Stellt man im define auf 9600 werden keine Daten mehr empfangen. Soweit ich weiß sollte der Zähler auch ein Auslesen mit 9600 Baud unterstützen. Eventuell liegt es daran, dass die "Initialisierungskommandos" immer mit 300 Baud geschickt werden müssen.
Aber eben, nur als Input, ich bin froh das ich den Zähler überhaupt auslesen kann.
Ich habe hier im Thread einiges über das statistics Modul gelesen und wollte damit die Daten des Obis Moduls auslesen und erweitern.
Ich habe zwei Devices im statistics Modul definiert. Einzeln funktionieren sie mit dem Modul aber ich bekomme nicht beide untergebracht, weil beide Devices ein Reading "power" haben und das bringt das statistics Modul durcheinander.
define Statistiken statistics HMFMS_01_Pwr|ISKRA_MT691
setuuid Statistiken 5c470f64-f33f-6f9b-e138-380736f0cc4abdb1
attr Statistiken dayChangeTime 00:00
attr Statistiken deltaReadings ISAKRA_MT691:Bezug | ISAKRA_MT691:Einspeisung | HMFMS_01:power
attr Statistiken excludedReadings ISKRA_MT691:power
attr Statistiken ignoreDefaultAssignments 1
attr Statistiken room Test,Unsorted
Es handelt sich um einen Zähler und um eine HM Mess-Steckdose. Gebe ich als deltaReadings folgendes an:
attr Statistiken deltaReadings Bezug,Einspeisung,power
werden von den beiden Devices jeweils abwechsend die "power" Werte ausgewertet. Das gibt ein heilloses Durcheinander.
Setze ich das Attribut, wie oben,
attr Statistiken singularReadings ISKRA_MT691:Einspeisung:Delta:(Hour|Day|Month|Year) | ISKRA_MT691:Bezug:Delta:(Hour|Day|Month|Year) | HMFMS_01_Pwr:state:Delta:(Hour|Day|Month|Year)
dann funktioniert das Modul nicht mehr. Wie muß ich die Attribute setzen um beide Devices getrennt auszuwerten?
Gruß aus Köln
Norbert
Hallo,
mein OBIS Sensor am Landis & Gyr E230 via
/dev/ttyUSB0@300,7,E,1 VSM102
hängt ca alle 10 Tage immer um 02:00.
Liefert einfach keine Daten mehr.
Ausser den Raspberry Pi new zu booten ist es mir noch nicht gelungen das zu beheben.
Hat jemand eine Idee woran das liegen könnte?
USB device ist noch da
Bus 001 Device 005: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Hallo,
ich hatte so ein ähnliches Problem, schau ich mittels Timer (at) einmal pro Minute auf das ReadingsAge (also die Zeit seit dem letzten Reading) und wenn das >60s ist, dann schicke ich ein defmod (also dahinter genauso, wie unter raw Definition am Ende der Seite vom OBIS-Device steht) los, damit wird das Modul dann neu gestartet. Gewöhnlich läuft das damit sehr stabil, ausser mein ESP, der die Datenübertragung macht, hängt sich selber weg, dann hilft nur ab und anstöpseln...
Kannst ja mal testen,
Grüße
Christian
Zitat von: cs-online am 30 September 2019, 09:32:50
mittels Timer (at) einmal pro Minute auf das ReadingsAge (also die Zeit seit dem letzten Reading) und wenn das >60s ist, dann schicke ich ein defmod
Hi, Danke! :-)
Kannst Du den Code Schnipsel, der das macht kund tun.
Grüsse
gramels
hier der Timer:
define Stromwerte_Timer at +*00:01:00 {\
my $d3 = ReadingsAge("Stromzaehler","power",0);;\ #GGF. ANPASSEN, BEI MIR HEISST DAS OBIS-DEVICE Stromzaehler
if ($d3 >= 60) {fhem ("defmod Stromzaehler OBIS 192.168.2.61:23");;;;\ #HIER DIE DEF VON DEINEM STROMZÄHLER REIN !!!
my $d4 = ReadingsVal("Stromzaehler","Anzahl_Neustarts",0);;\
$d4 = $d4 + 1;;\
fhem ("setreading Stromzaehler Anzahl_Neustarts $d4");;;;\
fhem ("setreading Stromzaehler Neustart ".TimeNow());;;;\
fhem ("save");;;;\
}\
}
So aus der Raw-Definition heraus kopiert...
Ich habe heute nach dem Neustart von FHEM mal in den LOG gesehen und dort Fehlermeldungen zum Obis Modul gesehen:
2019.10.07 17:18:40 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 476.
2019.10.07 17:18:40 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 544.
2019.10.07 17:18:40 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 560.
Modul funktioniert bei mir zwar einwandfrei, aber vielleicht kann der Maintainer des Moduls mit der Fehlermeldung was anfangen und korrigieren.
Gruß aus Köln
Norbert
@ichotolot85
Versuch mal die Definition mit dem AS1440 anstatt des E110. Dann kommen nur aktuelle Daten und die historischen Werte werden unterdrückt. Funktioniert zwar auch nur mit 300 Baud, aber der Datenumfang ist deutlich geringer.
Hallo zusammen,
ich habe jetzt schon eine Weile hier im OBIS Thread gelesen aber für mein Problem konnte ich noch keine Lösung finden.
Ich habe einen PAFAL 20EC3gr Zähler mit einem IR USB und folgende Definition angelegt:
define Stromzaehler2 OBIS /dev/ttyUSB0@300,7,E,1 VSM102
attr Stromzaehler2 interval 60
attr Stromzaehler2 pollingMode off
attr Stromzaehler2 verbose 5
Der Zähler sendet folgendes Lebenszeichen: "/PAF5EC3r000" aber sendet keine Messdaten bzw. Zählerstand.
Nun habe ich im Photovoltaik- Forum gelesen https://www.photovoltaikforum.com/thread/89365-weitere-pv-anlage-mit-eigenstromverbrauch-%C3%BCberwachen/?t=89365 (https://www.photovoltaikforum.com/thread/89365-weitere-pv-anlage-mit-eigenstromverbrauch-%C3%BCberwachen/?t=89365) dass der Zähler einmal angesprochen werden muss um sich zu melden und innerhalb von 1,5s eine zweite Anfrage für die Messdaten bekommen muss.
Unterstützt das OBIS V2 Modul diese Vorgehensweise?
Wenn ja, was muss ich noch zusätzlich tun um die zweite Anfrage über FHEM zu senden?
Vielen Dank im Voraus!
Gruß, Andi
Hallo AnDiBaCkE
laut dem Beitrag muss der Zähler mit 3 Sendesequenzen zum Messwerteversand überredet werden. Das ist aktuell nicht möglich. Du müsstes bitte einmal Deinen Zähler mit hterm zum Senden der Daten bringen und uns schreiben wie Du dies angestellt hast. Wenn die Pause nicht notwendig ist, besteht gute Hoffnung der Integration.
Hallo tr_ex,
ich habe mich einmal an hterm versucht:
#1 Wenn ich einzeln 2F 3F 21 0D 0A sende dann erhalte ich als Antwort "PAF5EC3r000".
#2 Wenn ich nun den 3in1 hex-Befehl inkl. Pause (2F 3F 21 0D 0A 00 00 00 00 00 00 00 06 30 30 30 0D 0A) sende dann kommt gar keine Antwort.
#3 Wenn ich ich den kombinierten 3in1 hex-cmd-Befehl (2F 3F 21 0D 0A wait=2500 06 30 30 30 0D 0A) sende dann stürzt mein hterm ab.
#4 Wenn ich beiden Befehle (2F 3F 21 0D 0A + 06 30 30 30 0D 0A) einzeln mit einer manuellen Pause sende erhalte ich auch keine Antwort.
Nun bin ich leider immer noch nicht schlauer :-\
Der PAFAL Zähler ist ja scheinbar noch nicht "smart" oder kann es sein das ich erst einen Freischaltcode vom Netzbetreiber holen muss?
Vielen Dank!
Gruß,
Andi
Hallo zusammen,
ich hab gerade meinen Stromzähler (DTZ541) über RS485 angebunden. Der Zähler scheint aber über 1.8.0 mehrer Werte zu senden. Erst den tatsächlichen Stromverbrauch in Wh, anschließend noch historische Werte 1d, 7d, 30d, 365d und seit letztem Rücksetzen lt. Doku. Gleiches gilt für die Einspeiserichtung 2.8.0. Ich seh im EventMonitor nur das er 6 mal die readings total_consumption und total_feed überschreibt.
Kann ich das irgendwie umgehen und entweder nur den ersten Wert übernehmen oder die historischen Werte in eigene Readings umleiten?
Mit verbose=5 konnte ich folgende Telegramme abfangen
SML FullMessage
1B1B1B1B0101010176040000016200620072650000010176010107000000146A950B0A01484C590200037DC9010163BDE90076040000026200620072650000070177010B0A01484C590200037DC90101F10E77070100603201010101010104484C590177070100600100FF010101010B0A01484C590200037DC90177070100010800FF65001C01046500146A95621E52FF65001193DE0177070100020800FF65001C01046500146A95621E52FF6325940177070100100700FF0101621B520053016A0177070100200700FF0101622352FF6308FB0177070100340700FF0101622352FF6308DB0177070100480700FF0101622352FF63090101770701001F0700FF0101622152FE62120177070100330700FF0101622152FE629C0177070100470700FF0101622152FE62190177070100510701FF01016208520062000177070100510702FF01016208520062000177070100510704FF01016208520063012D017707010051070FFF010162085200630149017707010051071AFF01016208520063013301770701000E0700FF0101622C52FF6301F30177070100010800600101621E5202625B0177070100010800610101621E52026302140177070100010800620101621E520262000177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
Das sollte der normale Zählerstand sein
Telegram=0177070100010800FF65001C01046500146A95621E52FF65001193DE0177070100020800FF65001C01046500146A95621E52FF6325940177070100100700FF0101621B520053016A0177070100200700FF0101622352FF6308FB0177070100340700FF0101622352FF6308DB0177070100480700FF0101622352FF63090101770701001F0700FF0101622152FE62120177070100330700FF0101622152FE629C0177070100470700FF0101622152FE62190177070100510701FF01016208520062000177070100510702FF01016208520062000177070100510704FF01016208520063012D017707010051070FFF010162085200630149017707010051071AFF01016208520063013301770701000E0700FF0101622C52FF6301F30177070100010800600101621E5202625B0177070100010800610101621E52026302140177070100010800620101621E520262000177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
Das dann die historischen Werte
2019.12.11 21:04:04 5: OBIS: Telegram=0177070100010800600101621E5202625B0177070100010800610101621E52026302140177070100010800620101621E520262000177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
2019.12.11 21:04:04 5: OBIS: Telegram=0177070100010800610101621E52026302140177070100010800620101621E520262000177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
2019.12.11 21:04:04 5: OBIS: Telegram=0177070100010800620101621E520262000177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
2019.12.11 21:04:04 5: OBIS: Telegram=0177070100010800630101621E520262000177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
2019.12.11 21:04:04 5: OBIS: Telegram=0177070100010800640101621E520263047F0177070100020800600101621E520262030177070100020800610101621E520262070177070100020800620101621E520262000177070100020800630101621E520262000177070100020800640101621E520262090177070100000200000101010109312E30322E3030370177070100605A02010101010105413031410177070100600500FF0101010165001C010401010163200E00760400000362006200726500000201710163E82300001B1B1B1B1A0156BD
Hallo zusammen,
nur zur Info: Ich habe gerade den neu getauschten Zähler EFR SGM-C4 mittels optischer Schnittstelle erfolgreich angebunden. Der Zähler war standardmäßig mit einer PIN geschützt. Mit der PIN vom Versorger habe ich die PIN Abfrage dauerhaft abgeschaltet und im Menü des Zählers auf den vollen OBIS Datensatz umgeschaltet. Nur so waren die Ausgaben auf der Schnittstelle für mich brauchbar.
Eingerichtet ist der Zähler bei mir so: define Zaehler OBIS /dev/ttyUSB0@@9600,8,N,1 SML
Es gibt bei mir folgende READINGS:
2019-12-13 17:39:13 1.0.0.2.0.255 2.04
2019-12-13 17:39:13 1.0.14.7.0.255 50
2019-12-13 17:39:13 1.0.81.7.1.255 121
2019-12-13 17:39:13 1.0.81.7.15.255 345
2019-12-13 17:39:13 1.0.81.7.2.255 239
2019-12-13 17:39:13 1.0.81.7.26.255 316
2019-12-13 17:39:13 1.0.81.7.4.255 318
2019-12-13 17:39:13 1.0.96.50.1.255 P1.2.5
2019-12-13 17:39:13 1.0.96.50.4.255 p
2019-12-13 17:39:13 1.0.96.90.2.255 1
2019-12-13 17:39:13 current_L1 1.75
2019-12-13 17:39:13 current_L2 2.11
2019-12-13 17:39:13 current_L3 0.53
2019-12-13 17:39:13 power 741
2019-12-13 17:11:04 state opened
2019-12-13 17:39:13 total_consumption 14916.2
2019-12-13 17:39:13 voltage_L1 227.4
2019-12-13 17:39:13 voltage_L2 225.8
2019-12-13 17:39:13 voltage_L3 225.7
LG
Hallo,
kann es sein, dass die Reading-Werte für "state" nicht konsistent sind?
Im Web-Interface sehe ich bei verbundenem Device den Wert "opened" für "STATE" (Internal) und "state" (Reading). Im DBLog ist der Wert für das Reading "state" mit "CONNECTED" zu sehen!?
Ist das Device nicht verbunden, wird im Web-Interface "disconnected" angezeigt, im DBLog dagegen "DISCONNECTED" eingetragen.
Gruß
Blueberry63
Hallo guten Abend,
nun habe ich fast alle Seiten durchgeforstet und bin nicht weiter gekommen, habe einen Zaehler Siemens TD 3511 und einen IR-Kopf von Volkszaehler Udo. Diesen hatte ich bis vor zwei Wochen mit einem YPORT+ per WLAN und volkszaehler.org in Betrieb (seit 2015). Nun ist der YPORT nicht mehr erreichbar (tot) und versuche jetzt mit einem Raspi2 mit volkszaehler Image plus Fhem 5.9 den USB-IR-Kopf an ttyUSB0 mit OBIS auszulesen.
Die Installation in FHEM mit :
define IR_Port OBIS /dev/ttyUSB0@300,7,E,1 SML oder VSM102 oder AS1440
wird zwar mit
STATE opened
angezeigt, aber im Reding passiert nichts. Die Abfragen im raspi zeigen das :
pi@vzpi:~ $ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Dez 15 22:37 /dev/ttyUSB0
pi@vzpi:~ $ ls -l /dev/serial/by-*
/dev/serial/by-id:
insgesamt 0
lrwxrwxrwx 1 root root 13 Dez 15 22:37 usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0 -> ../../ttyUSB0
/dev/serial/by-path:
insgesamt 0
lrwxrwxrwx 1 root root 13 Dez 15 22:37 platform-20980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
Versuche mit minicom oder screen erzeugen komische aber nicht lesbare Ausgaben.
Da ich nicht der jüngste bin hoffe ich, daß ich hier mal wieder auf den richtigen Weg geschubst werde.
Liebe Grüße von Peter aus Calw
...kannst du diese "komischen" Ausgaben mal posten ? Wobei die "insgesamt 0" mich ein wenig irritieren. Hängt da nochwas am USB ?
Hallo Christian,
danke für Deine Anfrage. An dem Raspi hängt noch ein USB-WLAN-Stick und am 2. USB der IR-Kopf.
Hier die Daten aus einem screen Start, einem minicom Ergebnis :
screen
�
j�����
j����/?!
�
j�����
j�����
j�����
j����T
minicom
Willkommen zu minicom 2.7.1
Optionen: I18n
Ãœbersetzt am Aug 13 2017, 15:25:34.
Port /dev/ttyUSB0, 23:10:32
Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten
m
jwm
jTnxm
jTnx
Und hier hatte ich einmal ein reading in FHEM mit OBIS, habe das aber nie wieder hinbekommen :
DeviceOverview IR_Kopf opened
IR_Kopf
Internals
DEF /dev/ttyUSB0@9600,7,E,1 AS1440
DeviceName /dev/ttyUSB0@9600,7,E,1
FD 4
FUUID 5defbf7b-f33f-0a9f-7a20-6223866ccca1c9b4
MeterType AS1440
NAME IR_Kopf
NR 16
PARTIAL STATE opened
TYPE OBIS
Readings
1.4.0 2019-12-10 18:52:32
1.6.0 19-12-04 00:15
1.6.0.00 19-06-22 22:15 2019-12-10 18:52:34
1.6.0.01 19-07-02 22:15 2019-12-10 18:52:40
1.6.0.02 19-08-07 05:15 2019-12-10 18:52:39
1.6.0.03 19-09-23 05:15 2019-12-10 18:52:38
1.6.0.04 19-10-05 02:45 2019-12-10 18:52:37
1.6.0.05 19-11-15 02:00 2019-12-10 18:52:35
1.6.0.91 18-09-29 04:00 2019-12-10 18:52:51
1.6.0.92 18-10-02 02:00 2019-12-10 18:52:50
1.6.0.93 18-11-19 00:00 2019-12-10 18:52:49
1.6.0.94 18-12-14 22:45 2019-12-10 18:52:48
1.6.0.95 19-01-30 23:00 2019-12-10 18:52:47
1.6.0.96 19-02-02 22:45 2019-12-10 18:52:46
1.6.0.97 19-03-07 02:15 2019-12-10 18:52:44
1.6.0.98 19-04-11 03:00 2019-12-10 18:52:43
1.6.0.99 19-05-02 05:00 2019-12-10 18:52:42
1.8.0 138177.598 2019-12-10 18:53:10
2.4.0 07 0.000 2019-12-10 18:52:33
2.6.0 19-12-02 12:45 2019-12-10 18:52:52
2.6.0.00 19-06-13 12:45 2019-12-10 18:52:59
2.6.0.01 19-07-30 12:15 2019-12-10 18:52:58
2.6.0.02 19-08-01 13:45 2019-12-10 18:52:57
2.6.0.03 19-09-02 13:15 2019-12-10 18:52:56
2.6.0.04 19-10-07 13:00 2019-12-10 18:52:55
2.6.0.05 19-11-09 12:45 2019-12-10 18:52:53
2.6.0.91 18-09-08 13:45 2019-12-10 18:53:09
2.6.0.92 18-10-06 13:00 2019-12-10 18:53:08
2.6.0.93 18-11-01 11:45 2019-12-10 18:53:07
2.6.0.94 18-12-01 11:15 2019-12-10 18:53:06
2.6.0.95 05-01-01 00:00 2019-12-10 18:53:04
2.6.0.96 05-01-01 00:00 2019-12-10 18:53:03
2.6.0.97 19-03-31 14:00 2019-12-10 18:53:02
2.6.0.98 19-04-07 13:30 2019-12-10 18:53:01
2.6.0.99 19-05-15 12:45 2019-12-10 18:53:00
Version �
;k.Rii* 2019-12-10 18:54:26
state opened 2019-12-12 22:53:16
total_consumption 132921.349
Hoffe nun Dir notwendige Details geliefert zu haben.
LG Peter
ZitatVSM102 oder AS1440
Das sind 2 verschiedene Init-Strings. In deinem Post oben hast du mit AS1440 definiert, das ist aber ein anderer Init als ihn dein Zähler braucht.
Für dich sollte VSM102 oder E110 passen.
lg, Stefan
Hallo Stefan,
habe nun mit beiden Versionen versucht :
/dev/ttyUSB0@300,7,E,1 VSM102
/dev/ttyUSB0@300,8,N,1 VSM102
/dev/ttyUSB0@300,7,E,1 E110
/dev/ttyUSB0@300,8,N,1 E110
im reading wird nur state opened aktualisiert.
In meiner ursprünglichen YPORT+ Abfrage mit einem php-skript finde ich das :
echo "Request senden ...";
$out = "/?!\r\n";
fwrite($fp, $out);
echo "OK.\n";
könnte das weiterhelfen ?
LG Peter
Hallo Stefa,
gerade habe ich irres Erlebnis, mit minicom und folgender Einstellung :
A Device :/dev/ttyUSB0
E Bps/Par/Bits :9600 8N1
F Hardware Flow Control : Nein |
G Software Flow Control : Nein
speichern und verlassen - dann rennt der los und zeigt die OBIS in Original an (1.4.0 bis ....2.8....)
In FHEM aber nichts.
Gruß Peter
...dort ist die Baudrate aber auch komplett anders, versuche doch mal
/dev/ttyUSB0@9600,8,N,1 VSM102
oder
/dev/ttyUSB0@9600,8,N,1 E110
und dann ist es immer besser, by-id zu referenzieren, weil u.U. nach einem Neustart die USBs neu sortiert werden und dann ist unter ttyUSB0 möglicherweise nicht mehr der IR-Kopf dran...
Hallo Stefan,
das hatte ich auch gleich versucht, aber beim Versuch vorhin hatte ich vergessen zu schreiben, daß nach verlassen (minicom)die Eingabe von :
"/?!\r\n"
nötig war, gerade funktioniert wieder gar nichts mit minicom - da steht, daß ttyUSB0 offline ist ???
Obwohl bei :
sudo systemctl status serial-getty@ttyUSB0.service
serial-getty@ttyUSB0.service - Serial Getty on ttyUSB0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2019-12-16 18:18:40 CET; 4min 38s ago
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Main PID: 1097 (agetty)
Memory: 160.0K
CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyUSB0.service
└─1097 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyUSB0 vt220
Dez 16 18:18:40 vzpi systemd[1]: Started Serial Getty on ttyUSB0.
LG Peter
Zitat von: blueberry63 am 15 Dezember 2019, 11:27:48
Hallo,
kann es sein, dass die Reading-Werte für "state" nicht konsistent sind?
Im Web-Interface sehe ich bei verbundenem Device den Wert "opened" für "STATE" (Internal) und "state" (Reading). Im DBLog ist der Wert für das Reading "state" mit "CONNECTED" zu sehen!?
Ist das Device nicht verbunden, wird im Web-Interface "disconnected" angezeigt, im DBLog dagegen "DISCONNECTED" eingetragen.
Gruß
Blueberry63
Ich wollte meine Anfrage nochmal "nach vorne holen", denn ich denke, dass diese Ungereimtheit im Sinne aller behoben (oder wenigsten diskutiert) werden sollte.
Danke für Euer Verständnis
Blueberry63
Das hat nichts mit dem OBIS-Modul zu tun, sondern kommt aus den Tiefen der DevIO.
lg, Stefan
Das verstehe ich nicht: wer definiert denn wo die möglichen Werte für state/STATE? Und warum werden in der DBLog wieder andere Werte abgelegt?
Gruß
Blueberry63
Das kommt alles direkt von FHEM bzw. der DevIO.
Wenn du im OBIS-Modul nach "connected" suchst, kommt das genau EINMAL vor, und da innerhalb einer Abfrage
return DevIo_OpenDev($hash, 1, "OBIS_Init")
if($hash->{STATE} eq "dis[color=red]connect[/color]ed");
Auf alles andere hab ich keinen Einfluss leider.
lg, Stefan
Hallo Stefan,
...dann müssen wir damit wohl leben. Aber vielleicht kannst Du mir OT einen Tipp geben: wir frage ich denn mit DOIF den Status-Wert für ein OBIS Device ab?
So etwa?
...([Stromzaehler] eq "DISCONNECTED") (set Telegram message Stromzaehler ist OFFLINE!) DOELSEIF ...
Gruß
Blueberry63
Hallo guten Abend,
mit meinem Problem "OBIS" gibt es glaube ich keine Lösung, habe nun alle Tipps ausprobiert aber in FHEM gibt es trotz "state opened" keine Ausgaben vom IR-Kopf. Vermutlich liegts an meinem Zaehlertyp Siemens TD 3511.
Kann es möglich sein, daß dieser Zaehler nur in Baden Württemberg (und Österreich ) eingesetzt wird ?
Oder gibt es ein YPORT+ Ersatzmodul das die YPORT+ USB-Daten per WLAN mit meinem "php-skript" ausgelesen werden kann ?
Freue mich über jeden Tipp.
LG Peter
also, ich bin auf dem Gebiet kein Fachmann aber wenn ich das richtig nachlese, dann kann der Zähler doch SML oder ? Dann müsste doch analog, wenn das in dem anderen mit 9600baud 8 bit und 1 parity gelaufen ist (so läuft mein Volkszählerkopf von UDO auch, allerdings nicht über USB sondern per TTL an einem 8266), so ca. so definierbar sein oder ?
define Stromzaehler OBIS /dev/ttyUSB0@9600,8,N,1 SML
ich habe bei mir noch die Attribute
attr Stromzaehler ignoreUnknown off
attr Stromzaehler valueBracket both
vielleicht bewirken die ja noch was bei der Auswahl, wo die Daten hergelesen werden sollen.
Gibt's mit Verbose 5 ein Log von dem Device ? Vielleicht verrät uns das noch was ?
Grüße
Christian
Hallo Christian,
danke für Deine Unterstützung, habe nun mal Deine "attr" Vorschläge eingefügt - Ohne Änderung, schicke Dir mal den Auszug der FHEM Log von heute nach der Änderung:
2019.12.18 16:57:25 3: Setting IR_Kopf serial parameters to 9600,8,N,1
2019.12.18 16:57:25 3: Init done
2019.12.18 16:57:25 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0 reappeared (IR_Kopf)
2019.12.18 16:58:50 0: Server shutdown
2019.12.18 16:58:54 1: Including fhem.cfg
2019.12.18 16:58:57 3: WEB: port 8083 opened
2019.12.18 16:58:57 2: eventTypes: loaded 10 events from ./log/eventTypes.txt
2019.12.18 16:58:58 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 31.
2019.12.18 16:58:58 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 31.
2019.12.18 16:58:58 3: Opening IR_Kopf device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0
2019.12.18 16:58:58 3: Setting IR_Kopf serial parameters to 9600,8,N,1
2019.12.18 16:58:58 3: Init done
2019.12.18 16:58:58 3: IR_Kopf device opened
2019.12.18 16:59:00 1: Including ./log/fhem.save
2019.12.18 16:59:00 1: usb create starting
2019.12.18 16:59:01 3: Probing ZWDongle device /dev/serial0
2019.12.18 16:59:01 3: Probing CUL device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing ZWDongle device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing SIGNALDuino device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing MYSENSORS device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing ArduCounter device /dev/ttyAMA0
2019.12.18 16:59:02 3: Probing ElsnerWS device /dev/ttyAMA0
2019.12.18 16:59:03 3: Probing FRM device /dev/ttyAMA0
2019.12.18 16:59:09 1: usb create end
2019.12.18 16:59:09 0: Featurelevel: 5.9
2019.12.18 16:59:09 0: Server started with 8 defined entities (fhem.pl:20651/2019-12-03 perl:5.028001 os:linux user:fhem pid:7847)
2019.12.18 16:59:10 3: FHEMWEB WEB CSRF error: csrf_821049747790302 ne csrf_279259008183356 for client WEB_192.168.2.46_61658 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
2019.12.18 17:00:21 0: Server shutdown
2019.12.18 17:00:45 1: Including fhem.cfg
2019.12.18 17:00:48 3: WEB: port 8083 opened
2019.12.18 17:00:49 2: eventTypes: loaded 10 events from ./log/eventTypes.txt
2019.12.18 17:00:49 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 31.
2019.12.18 17:00:49 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 31.
2019.12.18 17:00:49 3: Opening IR_Kopf device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0
2019.12.18 17:00:49 3: Setting IR_Kopf serial parameters to 9600,8,N,1
2019.12.18 17:00:49 3: Init done
2019.12.18 17:00:49 3: IR_Kopf device opened
2019.12.18 17:00:51 1: Including ./log/fhem.save
2019.12.18 17:00:51 1: usb create starting
2019.12.18 17:00:52 3: Probing ZWDongle device /dev/serial0
2019.12.18 17:00:52 3: Probing CUL device /dev/ttyAMA0
2019.12.18 17:00:52 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.12.18 17:00:53 3: Probing ZWDongle device /dev/ttyAMA0
2019.12.18 17:00:53 3: Probing SIGNALDuino device /dev/ttyAMA0
2019.12.18 17:00:53 3: Probing MYSENSORS device /dev/ttyAMA0
2019.12.18 17:00:53 3: Probing ArduCounter device /dev/ttyAMA0
2019.12.18 17:00:53 3: Probing ElsnerWS device /dev/ttyAMA0
2019.12.18 17:00:54 3: Probing FRM device /dev/ttyAMA0
2019.12.18 17:01:00 1: usb create end
2019.12.18 17:01:00 0: Featurelevel: 5.9
2019.12.18 17:01:00 0: Server started with 8 defined entities (fhem.pl:20651/2019-12-03 perl:5.028001 os:linux user:fhem pid:7940)
2019.12.18 17:01:40 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:03:40
2019.12.18 17:01:40 5: OBIS (IR_Kopf) - Opening device...
2019.12.18 17:01:40 3: Opening IR_Kopf device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0
2019.12.18 17:01:40 3: Setting IR_Kopf serial parameters to 9600,8,N,1
2019.12.18 17:01:40 3: Init done
2019.12.18 17:01:40 3: IR_Kopf device opened
2019.12.18 17:02:59 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:03:59
2019.12.18 17:03:59 5: SW:
2019.12.18 17:03:59 4: Wrote
2019.12.18 17:03:59 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:04:59
Vielleicht ist hier der Fehler irgendwo erkennbar, meine Kenntnisse übersteigt das Ergebnis.
LG Peter
Hallo Christian,
habe es nochmal mit "AS1440" versucht, jetzt steht im Log was anderes :
2019.12.18 17:32:12 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:33:12
2019.12.18 17:33:12 5: SW: 2f3f210d0a
2019.12.18 17:33:12 4: Wrote /?!
2019.12.18 17:33:12 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:34:12
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Initialize redefined at ./FHEM/47_OBIS.pm line 76.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Define redefined at ./FHEM/47_OBIS.pm line 97.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Get redefined at ./FHEM/47_OBIS.pm line 171.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Set redefined at ./FHEM/47_OBIS.pm line 185.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine GetUpdate redefined at ./FHEM/47_OBIS.pm line 213.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Init redefined at ./FHEM/47_OBIS.pm line 231.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Undef redefined at ./FHEM/47_OBIS.pm line 237.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Read redefined at ./FHEM/47_OBIS.pm line 246.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_trySMLdecode redefined at ./FHEM/47_OBIS.pm line 304.
2019.12.18 17:34:08 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Parse redefined at ./FHEM/47_OBIS.pm line 408.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Ready redefined at ./FHEM/47_OBIS.pm line 587.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_Attr redefined at ./FHEM/47_OBIS.pm line 603.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_adjustAlign redefined at ./FHEM/47_OBIS.pm line 686.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_hex2int redefined at ./FHEM/47_OBIS.pm line 717.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_CRC16 redefined at ./FHEM/47_OBIS.pm line 725.
2019.12.18 17:34:08 1: PERL WARNING: Subroutine OBIS_decodeTL redefined at ./FHEM/47_OBIS.pm line 766.
2019.12.18 17:34:12 5: SW: 2f3f210d0a
2019.12.18 17:34:12 4: Wrote /?!
2019.12.18 17:34:12 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:35:12
2019.12.18 17:34:48 5: SW: 2f3f210d0a
2019.12.18 17:34:48 4: Wrote /?!
2019.12.18 17:34:48 5: OBIS (IR_Kopf) - Internal timer set to 2019-12-18 17:35:48
da ist jetzt mal ein Hinweis auf "/?!" , das soll ja der Start zum Auslesen des Zählers sein, aber es kommt halt immer noch nichts.
Allerdings gibt es jetzt einige "PERL" Fehlermeldungen.
LG Peter
Die Perl Warnings sind keine Fehlermeldungen, die sagen nur, dass sich etwas im Modul geändert hat (redefined) aufgrund der geänderten Konfiguration. Ich kann da keinen Fehler erkennen. Du bist sicher, dass der Lesekopf immer noch sauber auf dem Zähler sitzt ? Ich hatte das mal, da war der etwas verrutscht, dann kam auch nichts mehr. Nach den Logeinträgen ist (für mich) nichts auffälliges zu erkennen...
Hmm, grad nochmal hier geschaut:
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511 (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511)
da steht oben, dass der mit
Gelesen werden kann mittels IR-Schreib-Lese-Kopf bei 300bd 7E1,
das würde ja für
define Stromzaehler OBIS /dev/ttyUSB0@300,7,N,1 AS1440
bzw
define Stromzaehler OBIS /dev/ttyUSB0@300,7,E,1 AS1440
sprechen... Aber das ist eher geraten als gesichert...
@Icinger:
Auf der Seite steht, dass der Zähler nach Startsequenz
\x06\x30\x35\x31\x0D\x0A
\x06050\r\n
mit 9600 Baud könnte, wie kann man denn die Startparameter ändern oder macht das Modul das (irgendwie) automatisch ?
Grüße
Christian
Hallo Christian,
das mit
\x06\x30\x35\x31\x0D\x0A
\x06050\r\n
versuche ich auch zu finden, in meinem php-skript steht das so drin :
echo "Request senden ...";
$out = "/?!\r\n";
fwrite($fp, $out);
echo "OK.\n";
echo "Lese eine Zeile\n";
echo fgets($fp);
echo "gelesen\n";
echo "Lese eine Zeile\n";
echo fgets($fp);
echo "gelesen\n";
usleep(500 * 1000);
echo "bps-Rate-Request senden ...";
$out = "\x06\x30\x35\x31\x0D\x0A";
$out = "\x06060\r\n";
//$out = "\x06050\r\n";
fwrite($fp, $out);
echo "OK.\n";
echo 'Antwort-Zeichen:'.bin2hex($a=fgetc($fp))." $a\n";
echo 'Antwort-Zeichen:'.bin2hex($a=fgetc($fp))." $a\n";
echo 'Antwort-Zeichen:'.bin2hex($a=fgetc($fp))." $a\n";
echo 'Antwort-Zeichen:'.bin2hex($a=fgetc($fp))." $a\n";
.............................usw
Könnte man einen raspi auch als Ersatz für meinen defekten YPORT+ verwenden ?
Also über "ser2net" auslesen.
LG Peter
Also ich habe an meinem FHEM Raspi mehrere USB-Seriellgeräte dran und lese die direkt aus, also einfach über den Port, also ...by-id... angesprochen. Vielleicht läuft da bei dir auch einfach zuviel, was den Port blockiert...
Hallo Christian,
an dem raspi steckt ein USB-WLAN Stick und der IR-Kopf - sonst nichts.
Am IR-Kopf wurde nichts verändert und wurde auch nicht angefasst seit der YPORT+ sich verabschiedet hat.
Bin jetzt gerade dabei es mit vzlogger zu versuchen. Mal sehen ob ich das hinbekomme.
LG Peter
Hallo,
ich habe einen IR Kopf von Weidmann und diesen Zähler https://digimeto.de/wps/wcm/connect/digimeto/a7c0814f-550e-4387-9a73-69bd36a7296c/Bedienungsanleitung-SGM-DD.pdf?MOD=AJPERES&CVID=mX5YQ1O
Leider bekomme ich es nicht hin irgendwelche Daten auszulesen. Ich habe bei dem Zähler die Pinabfrage deaktiviert und in den Einstellungen die Schnittstelle auf den dSS-Protokollstandard gestellt (siehe Anleitung Seite 14) dabei werden laut Anleitung aktuelle Daten in SML permanent unverschlüsselt ausgegeben. Seitdem ich das gemacht habe blinkt auch am Weidmann Lesekopf die Grüne Status Diode (im d0 Modus konnte ich gar nichts bewirken). Doch leider bekomme ich immer noch keine Daten mit denen ich was anfangen kann. Wenn ich auf TYPE -> OBIS klicke sehe ich folgendes Bild (siehe Anhang). Es scheint als ob der Buffer mit irgendwelchen Datan vollläuft die aber nicht Verarbeitet werden können. Ich sehe nur einen riesen Datensalat. Eine Idee was da nicht in Ordnung ist?
Mein Fhem ist auf den letzten Stand. Es ist auch eine Testinstallation sprich ein ganz neues System ohne sonstige Konfiguration.
Bin mit meinem Latein am Ende :-[
Moin,
in der Beschreibung auf Seite 16 steht: Kommunikations-Einstellungen: 7 Datenbits, Parität=even, 1 Stoppbit , Auto-Mode C mit Anfangsbaudrate 300, Kommunikation bis 9600 Bd. Vielleicht ist hier das Problem. Ich hatte auch mal einen Zähler, der immer mit 300 Bd angefangen hat und per Telegramm erst auf 9600 umgestellt werden musste.
LG
OK das könnte ich probieren. Habe das ganze jetzt versucht mit VZLOGGER auszulesen und da kommen brauchbare Werte an. Sprich der Lesekopf und die gesendeten Daten des Zähler scheinen OK zu sein, so kann ich diese Fehlerquelle erst einmal ausschliesen :)
Ich habe seit gestern meinen ISKRA Zähler mit dem PIN gefüttert. Im Zählerdisplay werden alle Verbräuche zwar angezeigt nur kommen nur die Stände im FHEM an.
Habe ich irgendwas übersehen?
Mit dem OBIS V2 Modul lese ich meinen ISKRA 2-Richtungs-Zähler über einen Lesekopf aus. Das hat auch über Monate wunderbar funktioniert.
Ich habe vor einer Woche lediglich das Betriebssystem von Jessie nach Buster gewechselt (kompl.neu auf einem Raspi 4b installiert). Danach funktionierte alles wie vorher. Jetzt ist mir aufgefallen, das das Modul irgendwann einfach nicht mehr ausliest und steht. Im LOG finde ich zu diesem Zeitpunkt keine Meldung. Starte ich das Modul wieder läuft es ungefähr 1 Tag wieder einwandfrei und bleibt dann wieder hängen, so heute nacht um 3.18 Uhr.
Das kann doch nicht mit dem Wechsel von Jessie nach Buster zu tun haben? Vielleicht muß ein bestimmtes Modul nachinstalliert werden?
Was kann ich machen um den Fehler einzukreisen?
Gruß
Norbert
Hi Norbert,
mit Buster dürfte das nicht direkt zu tun haben. Ich würd auf den Rpi4 tippen. Guck mal mit "dmesg" in Dein Systemlog, ob Du da evtl. siehst, dass sich die Schnittstelle verabschiedet.
Grüße Markus
Hallo Markus,
Ich habe mal "dmesg" gestartet. Mit den Ausgaben kann ich nur bedingt was anfangen. Aber da der Raspi ja jetzt läuft, glaube ich das man in der Ausgabe nix mehr sehen kann. Oder liege ich da falsch. Ich habe die Zeilen trotzdem mal hier gepostet:
pi@raspberrypi-pi4-master:~ $ dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.19.75-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1270 SMP Tue Sep 24 18:51:41 BST 2019
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x000000001ec00000
[ 0.000000] On node 0 totalpages: 1012736
[ 0.000000] DMA zone: 1728 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 196608 pages, LIFO batch:63
[ 0.000000] HighMem zone: 816128 pages, LIFO batch:63
[ 0.000000] random: get_random_bytes called from start_kernel+0xc0/0x4e8 with crng_init=0
[ 0.000000] percpu: Embedded 17 pages/cpu s39488 r8192 d21952 u69632
[ 0.000000] pcpu-alloc: s39488 r8192 d21952 u69632 alloc=17*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1011008
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M cma=256M smsc95xx.macaddr=DC:A6:32:22:95:17 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 3735592K/4050944K available (8192K kernel code, 661K rwdata, 2352K rodata, 2048K init, 850K bss, 53208K reserved, 262144K cma-reserved, 3264512K highmem)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0x(ptrval) - 0x(ptrval) (10208 kB)
.init : 0x(ptrval) - 0x(ptrval) (2048 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 662 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 851 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 28124 entries in 83 pages
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[ 0.000005] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[ 0.000022] Switching to timer-based delay loop, resolution 18ns
[ 0.000249] Console: colour dummy device 80x30
[ 0.000705] console [tty1] enabled
[ 0.000756] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)
[ 0.000799] pid_max: default: 32768 minimum: 301
[ 0.001074] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.001107] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.001868] CPU: Testing write buffer coherency: ok
[ 0.002292] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.002942] Setting up static identity map for 0x200000 - 0x20003c
[ 0.003114] rcu: Hierarchical SRCU implementation.
[ 0.003994] smp: Bringing up secondary CPUs ...
[ 0.004904] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.005930] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.006915] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.007046] smp: Brought up 1 node, 4 CPUs
[ 0.007115] SMP: Total of 4 processors activated (432.00 BogoMIPS).
[ 0.007138] CPU: All CPU(s) started in HYP mode.
[ 0.007158] CPU: Virtualization extensions available.
[ 0.007958] devtmpfs: initialized
[ 0.018152] VFP support v0.3: implementor 41 architecture 3 part 40 variant 8 rev 0
[ 0.018380] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.018422] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.025816] pinctrl core: initialized pinctrl subsystem
[ 0.026685] NET: Registered protocol family 16
[ 0.029591] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.031005] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.031035] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.031237] Serial: AMBA PL011 UART driver
[ 0.034301] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[ 0.069963] bcm2835-dma fe007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
[ 0.072434] vgaarb: loaded
[ 0.072816] SCSI subsystem initialized
[ 0.073025] usbcore: registered new interface driver usbfs
[ 0.073090] usbcore: registered new interface driver hub
[ 0.073199] usbcore: registered new device driver usb
[ 0.090391] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-09-24 17:34, variant start
[ 0.100110] raspberrypi-firmware soc:firmware: Firmware hash is cd3add54955f8fa065b414d8fc07c525e7ddffc8
[ 0.111529] clocksource: Switched to clocksource arch_sys_counter
[ 0.188891] VFS: Disk quotas dquot_6.6.0
[ 0.188991] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.189159] FS-Cache: Loaded
[ 0.189355] CacheFiles: Loaded
[ 0.189870] simple-framebuffer: probe of 0.framebuffer failed with error -12
[ 0.198594] NET: Registered protocol family 2
[ 0.199253] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[ 0.199298] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.199383] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.199467] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.199599] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.199643] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.199960] NET: Registered protocol family 1
[ 0.200504] RPC: Registered named UNIX socket transport module.
[ 0.200529] RPC: Registered udp transport module.
[ 0.200550] RPC: Registered tcp transport module.
[ 0.200571] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.200600] PCI: CLS 0 bytes, default 64
[ 0.203598] Initialise system trusted keyrings
[ 0.203779] workingset: timestamp_bits=14 max_order=20 bucket_order=6
[ 0.212774] FS-Cache: Netfs 'nfs' registered for caching
[ 0.213277] NFS: Registering the id_resolver key type
[ 0.213314] Key type id_resolver registered
[ 0.213336] Key type id_legacy registered
[ 0.213367] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.215607] Key type asymmetric registered
[ 0.215633] Asymmetric key parser 'x509' registered
[ 0.215754] bounce: pool size: 64 pages
[ 0.215809] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.215983] io scheduler noop registered
[ 0.216006] io scheduler deadline registered (default)
[ 0.216169] io scheduler cfq registered
[ 0.216192] io scheduler mq-deadline registered (default)
[ 0.216215] io scheduler kyber registered
[ 0.247127] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[ 0.247172] brcm-pcie fd500000.pcie: could not get clock
[ 0.247248] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.247300] brcm-pcie fd500000.pcie: MEM 0x600000000..0x603ffffff -> 0xf8000000
[ 0.301564] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[ 0.301850] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[ 0.301880] pci_bus 0000:00: root bus resource [bus 00-01]
[ 0.301911] pci_bus 0000:00: root bus resource [mem 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff])
[ 0.301973] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400
[ 0.302113] pci 0000:00:00.0: PME# supported from D0 D3hot
[ 0.304834] PCI: bus0: Fast back to back transfers disabled
[ 0.304866] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.305088] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330
[ 0.305212] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00000fff 64bit]
[ 0.305533] pci 0000:01:00.0: PME# supported from D0 D3cold
[ 0.308272] PCI: bus1: Fast back to back transfers disabled
[ 0.308302] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
[ 0.308349] pci 0000:00:00.0: BAR 8: assigned [mem 0x600000000-0x6000fffff]
[ 0.308383] pci 0000:01:00.0: BAR 0: assigned [mem 0x600000000-0x600000fff 64bit]
[ 0.308472] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 0.308503] pci 0000:00:00.0: bridge window [mem 0x600000000-0x6000fffff]
[ 0.308724] pcieport 0000:00:00.0: enabling device (0140 -> 0142)
[ 0.308920] pcieport 0000:00:00.0: Signaling PME with IRQ 55
[ 0.309098] pcieport 0000:00:00.0: AER enabled with IRQ 55
[ 0.309279] pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 0.312571] iproc-rng200 fe104000.rng: hwrng registered
[ 0.312806] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 0.313314] vc-sm: Videocore shared memory driver
[ 0.313727] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
[ 0.323697] brd: module loaded
[ 0.333286] loop: module loaded
[ 0.334035] Loading iSCSI transport class v2.0-870.
[ 0.335707] libphy: Fixed MDIO Bus: probed
[ 0.336140] bcmgenet fd580000.genet: failed to get enet clock
[ 0.336171] bcmgenet fd580000.genet: GENET 5.0 EPHY: 0x0000
[ 0.336201] bcmgenet fd580000.genet: failed to get enet-wol clock
[ 0.336231] bcmgenet fd580000.genet: failed to get enet-eee clock
[ 0.336267] bcmgenet: Skipping UMAC reset
[ 0.336512] unimac-mdio unimac-mdio.-19: DMA mask not set
[ 0.351558] libphy: bcmgenet MII bus: probed
[ 0.392054] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus at 0x(ptrval)
[ 0.392970] usbcore: registered new interface driver r8152
[ 0.393047] usbcore: registered new interface driver lan78xx
[ 0.393114] usbcore: registered new interface driver smsc95xx
[ 0.393425] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 0.393470] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 0.395725] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000001000000890
[ 0.396062] genirq: irq_chip Brcm_MSI did not update eff. affinity mask of irq 56
[ 0.396933] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.396966] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.396995] usb usb1: Product: xHCI Host Controller
[ 0.397018] usb usb1: Manufacturer: Linux 4.19.75-v7l+ xhci-hcd
[ 0.397042] usb usb1: SerialNumber: 0000:01:00.0
[ 0.397568] hub 1-0:1.0: USB hub found
[ 0.397667] hub 1-0:1.0: 1 port detected
[ 0.398141] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 0.398177] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 0.398213] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
[ 0.398633] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
[ 0.398665] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.398693] usb usb2: Product: xHCI Host Controller
[ 0.398717] usb usb2: Manufacturer: Linux 4.19.75-v7l+ xhci-hcd
[ 0.398741] usb usb2: SerialNumber: 0000:01:00.0
[ 0.399238] hub 2-0:1.0: USB hub found
[ 0.399319] hub 2-0:1.0: 4 ports detected
[ 0.400483] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 0.426063] dwc_otg fe980000.usb: base=(ptrval)
[ 0.626330] Core Release: 2.80a
[ 0.626364] Setting default values for core params
[ 0.626407] Finished setting default values for core params
[ 0.826748] Using Buffer DMA mode
[ 0.826771] Periodic Transfer Interrupt Enhancement - disabled
[ 0.826794] Multiprocessor Interrupt Enhancement - disabled
[ 0.826818] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 0.826888] Dedicated Tx FIFOs mode
[ 0.827813] WARN::dwc_otg_hcd_init:1045: FIQ DMA bounce buffers: virt = ded38000 dma = 0x00000000ded38000 len=9024
[ 0.827860] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 0.827918] dwc_otg: Microframe scheduler enabled
[ 0.828128] WARN::hcd_init_fiq:457: FIQ on core 1
[ 0.828158] WARN::hcd_init_fiq:458: FIQ ASM at c07b6224 length 36
[ 0.828188] WARN::hcd_init_fiq:497: MPHI regs_base at f0810200
[ 0.828235] dwc_otg fe980000.usb: DWC OTG Controller
[ 0.828280] dwc_otg fe980000.usb: new USB bus registered, assigned bus number 3
[ 0.828332] dwc_otg fe980000.usb: irq 37, io mem 0x00000000
[ 0.828397] Init: Port Power? op_state=1
[ 0.828418] Init: Power Port (0)
[ 0.828678] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.828710] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.828739] usb usb3: Product: DWC OTG Controller
[ 0.828762] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
[ 0.828786] usb usb3: SerialNumber: fe980000.usb
[ 0.829317] hub 3-0:1.0: USB hub found
[ 0.829378] hub 3-0:1.0: 1 port detected
[ 0.829947] dwc_otg: FIQ enabled
[ 0.829957] dwc_otg: NAK holdoff enabled
[ 0.829965] dwc_otg: FIQ split-transaction FSM enabled
[ 0.829979] Module dwc_common_port init
[ 0.830179] usbcore: registered new interface driver uas
[ 0.830309] usbcore: registered new interface driver usb-storage
[ 0.830486] mousedev: PS/2 mouse device common for all mice
[ 0.831686] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 0.831904] bcm2835-cpufreq: min=600000 max=1500000
[ 0.832521] sdhci: Secure Digital Host Controller Interface driver
[ 0.832544] sdhci: Copyright(c) Pierre Ossman
[ 0.832941] mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
[ 0.833328] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.836305] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.836461] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.836612] usbcore: registered new interface driver usbhid
[ 0.836635] usbhid: USB HID core driver
[ 0.837401] vchiq: vchiq_init_state: slot_zero = (ptrval), is_master = 0
[ 0.839159] [vc_sm_connected_init]: start
[ 0.848087] [vc_sm_connected_init]: end - returning 0
[ 0.849158] Initializing XFRM netlink socket
[ 0.849200] NET: Registered protocol family 17
[ 0.849292] Key type dns_resolver registered
[ 0.849591] Registering SWP/SWPB emulation handler
[ 0.850179] registered taskstats version 1
[ 0.850209] Loading compiled-in X.509 certificates
[ 0.857953] uart-pl011 fe201000.serial: cts_event_workaround enabled
[ 0.858042] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
[ 0.861068] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 0.861634] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[ 0.862254] mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 0.862281] mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
[ 0.888321] sdhci-iproc fe340000.emmc2: Linked as a consumer to regulator.1
[ 0.908771] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 0.910400] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.912043] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.914948] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 0.916574] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.924416] mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
[ 0.926952] of_cfs_init
[ 0.927056] of_cfs_init: OK
[ 0.927664] Waiting for root device PARTUUID=6c586e13-02...
[ 0.971569] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 0.972608] random: fast init done
[ 0.985598] mmc1: new high speed SDIO card at address 0001
[ 1.027726] mmc0: new ultra high speed DDR50 SDHC card at address aaaa
[ 1.028887] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[ 1.031204] mmcblk0: p1 p2
[ 1.051918] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 1.051986] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.056981] devtmpfs: mounted
[ 1.063304] Freeing unused kernel memory: 2048K
[ 1.081786] Run /sbin/init as init process
[ 1.164295] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[ 1.164336] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.164363] usb 1-1: Product: USB2.0 Hub
[ 1.166203] hub 1-1:1.0: USB hub found
[ 1.166541] hub 1-1:1.0: 4 ports detected
[ 1.311932] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.343125] usb 2-2: New USB device found, idVendor=0781, idProduct=5591, bcdDevice= 1.00
[ 1.343164] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.343191] usb 2-2: Product: Ultra USB 3.0
[ 1.343215] usb 2-2: Manufacturer: SanDisk
[ 1.343238] usb 2-2: SerialNumber: 010173772a1b9c4c7550a5023919be4e27bdd85c7040632379c85dbf31f1fe1c5f0a00000000000000000000cf3a5b1a001f2f009155810796269acc
[ 1.346072] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1.346683] scsi host0: usb-storage 2-2:1.0
[ 1.480111] systemd[1]: System time before build time, advancing clock.
[ 1.491571] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd
[ 1.563912] NET: Registered protocol family 10
[ 1.565142] Segment Routing with IPv6
[ 1.597891] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 1.598592] systemd[1]: Detected architecture arm.
[ 1.611004] systemd[1]: Set hostname to <raspberrypi-pi4-master>.
[ 1.612887] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 1.622113] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[ 1.622152] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.622183] usb 1-1.3: Product: USB 2.0 Hub
[ 1.623997] hub 1-1.3:1.0: USB hub found
[ 1.624130] hub 1-1.3:1.0: 4 ports detected
[ 1.721616] usb 1-1.4: new full-speed USB device number 4 using xhci_hcd
[ 1.864252] usb 1-1.4: New USB device found, idVendor=03eb, idProduct=204b, bcdDevice= 0.00
[ 1.864302] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.864341] usb 1-1.4: Product: CUL868
[ 1.864370] usb 1-1.4: Manufacturer: busware.de
[ 1.868747] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
[ 1.868811] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
[ 2.061577] usb 1-1.3.4: new full-speed USB device number 5 using xhci_hcd
[ 2.177867] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.185744] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.186094] systemd[1]: Listening on initctl Compatibility Named Pipe.
[ 2.186844] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.187517] systemd[1]: Listening on Journal Socket.
[ 2.200742] systemd[1]: Starting Load Kernel Modules...
[ 2.209184] systemd[1]: Listening on Syslog Socket.
[ 2.314225] usb 1-1.3.4: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 2.314271] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.314305] usb 1-1.3.4: Product: FT232R USB UART
[ 2.314333] usb 1-1.3.4: Manufacturer: FTDI
[ 2.314359] usb 1-1.3.4: SerialNumber: AB0JDXH6
[ 2.393001] scsi 0:0:0:0: Direct-Access SanDisk Ultra USB 3.0 1.00 PQ: 0 ANSI: 6
[ 2.395145] sd 0:0:0:0: [sda] 120176640 512-byte logical blocks: (61.5 GB/57.3 GiB)
[ 2.396777] sd 0:0:0:0: [sda] Write Protect is off
[ 2.396815] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 2.397715] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2.407497] sda: sda1
[ 2.412198] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 2.860048] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 2.949684] systemd-journald[116]: Received request to flush runtime journal from PID 1
[ 3.280073] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3.520925] usbcore: registered new interface driver usbserial_generic
[ 3.520992] usbserial: USB Serial support registered for generic
[ 3.540826] usbcore: registered new interface driver ftdi_sio
[ 3.540908] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3.541281] ftdi_sio 1-1.3.4:1.0: FTDI USB Serial Device converter detected
[ 3.541427] usb 1-1.3.4: Detected FT232RL
[ 3.548887] usb 1-1.3.4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 3.787447] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 3.806979] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 3.876474] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 3.892824] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[ 3.928089] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 3.939066] bcm2835_audio soc:audio: card created with 8 channels
[ 3.941338] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 3.943870] usbcore: registered new interface driver brcmfmac
[ 4.020021] [drm] No displays found. Consider forcing hotplug if HDMI is attached
[ 4.020116] vc4-drm soc:gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
[ 4.023333] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 1
[ 4.023346] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4.023356] [drm] No driver support for vblank timestamp query.
[ 4.023365] [drm] Setting vblank_disable_immediate to false because get_vblank_timestamp == NULL
[ 4.186178] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.201035] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[ 4.645992] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.648048] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 4.648064] [vc_sm_connected_init]: start
[ 4.659864] media: Linux media interface: v0.10
[ 4.667774] [vc_sm_connected_init]: installed successfully
[ 4.692233] rpivid-mem feb00000.hevc-decoder: rpivid-hevcmem initialised: Registers at 0xfeb00000 length 0x0000ffff
[ 4.697559] rpivid-mem feb10000.rpivid-local-intc: rpivid-intcmem initialised: Registers at 0xfeb10000 length 0x00000fff
[ 4.699726] rpivid-mem feb20000.h264-decoder: rpivid-h264mem initialised: Registers at 0xfeb20000 length 0x0000ffff
[ 4.700225] rpivid-mem feb30000.vp9-decoder: rpivid-vp9mem initialised: Registers at 0xfeb30000 length 0x0000ffff
[ 4.717211] videodev: Linux video capture interface: v2.00
[ 4.742085] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.755729] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.762150] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.785287] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 4.785328] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 4.790453] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ 4.797291] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 4.797324] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 4.797448] usbcore: registered new interface driver cdc_acm
[ 4.797460] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 4.805169] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 4.805211] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 6.266243] 8021q: 802.1Q VLAN Support v1.8
[ 6.281808] uart-pl011 fe201000.serial: no DMA platform data
[ 6.386401] random: crng init done
[ 6.386409] random: 7 urandom warning(s) missed due to ratelimiting
[ 6.459512] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 6.516368] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 6.516397] brcmfmac: power management disabled
[ 6.734719] bcmgenet: Skipping UMAC reset
[ 6.831802] bcmgenet fd580000.genet: configuring instance for external RGMII (no delay)
[ 6.832152] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 7.911784] bcmgenet fd580000.genet eth0: Link is Down
[ 11.031815] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 11.031851] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 12.394186] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead
[ 12.964714] Bluetooth: Core ver 2.22
[ 12.964801] NET: Registered protocol family 31
[ 12.964812] Bluetooth: HCI device and connection manager initialized
[ 12.964832] Bluetooth: HCI socket layer initialized
[ 12.964848] Bluetooth: L2CAP socket layer initialized
[ 12.964893] Bluetooth: SCO socket layer initialized
[ 13.010087] Bluetooth: HCI UART driver ver 2.3
[ 13.010102] Bluetooth: HCI UART protocol H4 registered
[ 13.010213] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 13.010457] Bluetooth: HCI UART protocol Broadcom registered
[ 13.208915] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 13.208922] Bluetooth: BNEP filters: protocol multicast
[ 13.208932] Bluetooth: BNEP socket layer initialized
pi@raspberrypi-pi4-master:~ $
Aber wenn die USB Schnittstelle ausfällt, müßte doch das OBIS Modul trotzdem versuchen alle 30sek die Schnittstelle auszulesen? und eine ERROR Meldung rausgeben?
Gruß
Norbert
ZitatAber wenn die USB Schnittstelle ausfällt, müßte doch das OBIS Modul trotzdem versuchen alle 30sek die Schnittstelle auszulesen?
Macht es. Schneller Test mit nicht existentem device
2020.01.03 20:14:00 5: SW:
2020.01.03 20:14:00 4: Wrote
2020.01.03 20:14:00 5: OBIS (zaehler) - Internal timer set to 2020-01-03 20:15:00
2020.01.03 20:15:00 5: SW:
2020.01.03 20:15:00 4: Wrote
2020.01.03 20:15:00 5: OBIS (zaehler) - Internal timer set to 2020-01-03 20:16:00
2020.01.03 20:16:00 5: SW:
2020.01.03 20:16:00 4: Wrote
2020.01.03 20:16:00 5: OBIS (zaehler) - Internal timer set to 2020-01-03 20:17:00
2020.01.03 20:17:00 5: SW:
2020.01.03 20:17:00 4: Wrote
2020.01.03 20:17:00 5: OBIS (zaehler) - Internal timer set to 2020-01-03 20:18:00 Zitatund eine ERROR Meldung rausgeben?
Quasi schon. Der state dürfte von online auf disconnected wechseln.
Ich habe im LOG zum Zeitpunkt als das Modul stand, keine einzige Fehlermeldung gefunden.
Auch das Modul selbst zeigte keine Meldung, das es hängen geblieben ist, state stand auf opened.
Wie kann ich feststellen, was die Ursache dafür ist und wie ich den Fehler finden und beseitgen kann?
Gruß
Norbert
Ich habe heute morgen folgende Zeilen im LOG gesehen:
2020.01.04 08:00:01 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2020.01.04 08:00:01 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
Hat jemand eine Idee, wo das herkommt?
Hinweis: FHEM ist bei mir vor einigen Tagen das letzte Mal aktualisiert worden, also quasi aktuell.
Gruß
Blueberry63
Ich habe ähnliche Einträge!
2020.01.04 18:27:38.665 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777.
2020.01.04 18:27:38.666 1: stacktrace:
2020.01.04 18:27:38.666 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (777)
2020.01.04 18:27:38.666 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.01.04 18:27:38.667 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.667 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.667 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.668 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.668 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.01.04 18:27:38.668 1: stacktrace:
2020.01.04 18:27:38.669 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (793)
2020.01.04 18:27:38.669 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.01.04 18:27:38.669 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.670 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.670 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.670 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.671 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342.
2020.01.04 18:27:38.671 1: stacktrace:
2020.01.04 18:27:38.671 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (342)
2020.01.04 18:27:38.672 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.672 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.673 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.673 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.673 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2020.01.04 18:27:38.674 1: stacktrace:
2020.01.04 18:27:38.674 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (349)
2020.01.04 18:27:38.674 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.675 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.675 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.675 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.676 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2020.01.04 18:27:38.676 1: stacktrace:
2020.01.04 18:27:38.676 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (350)
2020.01.04 18:27:38.677 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.677 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.677 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.678 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.678 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2020.01.04 18:27:38.678 1: stacktrace:
2020.01.04 18:27:38.679 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (351)
2020.01.04 18:27:38.679 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.680 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.680 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.680 1: main::CallFn called by fhem.pl (756)
2020.01.04 18:27:38.680 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
2020.01.04 18:27:38.680 1: stacktrace:
2020.01.04 18:27:38.680 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (330)
2020.01.04 18:27:38.680 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.01.04 18:27:38.680 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.01.04 18:27:38.681 1: main::OBIS_Read called by fhem.pl (3763)
2020.01.04 18:27:38.681 1: main::CallFn called by fhem.pl (756)
Zusätzlich habe ich noch das Problem, dass der STATE auf disconnected geht. In welchen Abständen wird den versucht das Device wieder zu verbinden?
Anbei noch ein List von meinem konfigurierten Gerät:
Internals:
CHANGED
CRC_Errors 16
DEF 10.10.2.3:23 SML
DeviceName 10.10.2.3:23
FD 23
FUUID 5e0e2359-f33f-e2f1-f8de-52197c2a429c54f0
MeterType SML
NAME myPowerMeter
NR 269
PARTIAL
STATE 3221 kWh
TYPE OBIS
.attraggr:
.attreocr:
.*
.attrminint:
Helper:
DBLOG:
total_consumption:
fhem.dblog:
TIME 1578158778.66736
VALUE 3221000
READINGS:
2020-01-04 18:31:05 xxxx ISK
2020-01-02 23:01:09 statStateDay opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateMonth opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateYear opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-04 18:26:18 statTotal_consumption Hour: 1000 Day: 19000 Month: 40000 Year: 40000 (since: 2020-01-03 )
2020-01-04 18:26:18 statTotal_consumptionDay 19000
2020-01-03 23:59:55 statTotal_consumptionDayLast 19000
2020-01-04 18:26:18 statTotal_consumptionHour 1000
2020-01-04 17:59:55 statTotal_consumptionHourLast 1000
2020-01-04 17:59:55 statTotal_consumptionLast Hour: 1000 Day: 19000 Month: 19000 Year: 19000
2020-01-04 18:26:18 statTotal_consumptionMonth 40000
2020-01-04 18:26:18 statTotal_consumptionYear 40000
2020-01-04 16:19:06 state opened
2020-01-04 18:31:05 total_consumption 3221000
helper:
BUFFER
EoM 0
SPEED 5
TRIGGERTIME 1578151146.52585
_98_statistics haus.strom
Channels:
DEVICES:
-1
directions:
Attributes:
alias Stromzähler
event-on-change-reading .*
room ZZ_Strom
stateFormat {(ReadingsVal($name,"total_consumption",0) / 1000)." kWh"}
Ich auch.
Ich behaupte, dass es an stellenweise falschen Daten(Übertragungsfehler) liegt, was sich vermutlich nur mit gleichzeitigem verbose =4 oder gar 5 verifizieren ließe. Da platzt mir aber das Log. Also lebe ich mit den Warnings.
ZitatZusätzlich habe ich noch das Problem, dass der STATE auf disconnected geht. In welchen Abständen wird den versucht das Device wieder zu verbinden?
Wenn ich richtig liege, dann gibt es keine zyklische Prüfung, sondern der reconnect kommt "zentral" aus FHEM. Scheinbar verabschiedet sich ja Dein USB. Da müsste dmesg Erkenntnisse liefern...
Grüße Markus
Zitat von: KölnSolar am 04 Januar 2020, 22:03:29
Ich auch.
Ich behaupte, dass es an stellenweise falschen Daten(Übertragungsfehler) liegt, was sich vermutlich nur mit gleichzeitigem verbose =4 oder gar 5 verifizieren ließe. Da platzt mir aber das Log. Also lebe ich mit den Warnings.
Wenn ich richtig liege, dann gibt es keine zyklische Prüfung, sondern der reconnect kommt "zentral" aus FHEM. Scheinbar verabschiedet sich ja Dein USB. Da müsste dmesg Erkenntnisse liefern...
Grüße Markus
Mein IR Empfänger wird über einen ESPEasy Seriel Gateway betrieben. Daher gibt es keine USB Verbindung. Damit die Verbindung wieder sauber funktioniert muss ich entweder den FHEM Server neustarten, oder die DEF noch mal kurz modifizieren. Direkt danach funktioniert das Modul wieder.
ZitatESPEasy Seriel Gateway
Ok, da geht dann also die IP nicht. Da muss dann Stefan was zu sagen, warum kein automatischer reconnect erfolgt.
ZitatDamit die Verbindung wieder sauber funktioniert muss ich entweder den FHEM Server neustarten, oder die DEF noch mal kurz modifizieren
Dann ja lieber die 2. Variante. ;)
Ich habe mir mal heute den LOG vom OBIS angesehen. Da tauchen immer in genau den gleichen Abständen Fehlermeldungen auf und zwar immer die gleichen:
2020.01.05 13:00:14 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 3338.
2020.01.05 13:00:14 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 3338.
und 9 sek später:
2020.01.05 13:00:23 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 476.
2020.01.05 13:00:23 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 544.
2020.01.05 13:00:23 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 560.
und dann wieder dasselbe nach 1 STD 10 sek wieder beide Meldungen im Abstand von 9 sek :
2020.01.05 14:24:47 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 3338.
2020.01.05 14:24:47 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 3338.
2020.01.05 14:24:56 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 476.
2020.01.05 14:24:56 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 544.
2020.01.05 14:24:56 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 560.
Was ist das? Vielleicht liegt da die Ursache oder warum kommen immer diese Meldungen dauernd?
Gruß
Norbert
Zitat von: michael.winkler am 04 Januar 2020, 23:03:57
Mein IR Empfänger wird über einen ESPEasy Seriel Gateway betrieben. Daher gibt es keine USB Verbindung. Damit die Verbindung wieder sauber funktioniert muss ich entweder den FHEM Server neustarten, oder die DEF noch mal kurz modifizieren. Direkt danach funktioniert das Modul wieder.
...das Problem habe ich auch von Zeit zu Zeit, ich habe allerdings mit dem ESPEasy an der Stelle nicht so gute Erfahrungen gemacht, da gab es häufiger Verbindungsabbrüche, mit ESP-Link ist es dann sehr selten. Ich frage minütlich das ReadingsAge ab und wenn das >60 ist, dann schicke ich ein defmod mit der Definition des Devices los, dann connected sich das ganze wieder neu... Nicht das eleganteste, aber funktioniert.
Grüße
Christian
Guten Tag ihr allen.
Ich möchte den OBIS module nutzen um die daten van mein DSMR smart meter (luxembourg) zu lesen.
Die Telegrammen sind aber codiert. Mit den DSMR proxy (https://github.com/mweimerskirch/smarty_dsmr_proxy) und
socat, lauft es immerhin doch. Aber ... am liebsten würde ich das der OBIS module selber das decrypten der Telegrammen übernimmt.
Bin kein PERL (or Python) Experte. Konnte es natürlich lernen. Bin aber erst auf die Suche nach den "owner" der OBIS module.
Die letzter version der OBIS module ist (in so ferne ich es sehen kann) von 2018-02-13.
BG,
Erik Proper
Hallo Erik,
ZitatDie letzter version der OBIS module ist (in so ferne ich es sehen kann) von 2018-02-13
Die Version ist nicht aktuelle. Die aktuelle Version ist vom 15.2.2019.
Du müsstest also ein update von FHEM machen.
Es wird Dir aber vermutlich nicht helfen, weil es ja verschlüsselte Daten sind und eine spezifische Entschlüsselung für "Einzelfälle" im Modul keinen Sinn machen dürfte. Entscheiden müsste tatsächlich Stefan.
Grüße Markus
Leider muß ich mich nochmals melden. Ich kriege es sonst nicht ans laufen. Das Modul bleibt weiterhin sporadisch mal nach 1 Tag mal nach ein paar stunden stehen, zeigt aber opend an.Das Modul ist gestern abend um 20.18 stehen geblieben, und ich habe heute morgen, ohne das Modul zu starten, dem Vorschlag von Markus zur Folge mal ein dmesg gemacht. Vielleicht hilt das ja weiter, das es wieder fehlerfrei läuft:
pi@raspberrypi-pi4-master:~ $ dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.19.75-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1270 SMP Tue Sep 24 18:51:41 BST 2019
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x000000001ec00000
[ 0.000000] On node 0 totalpages: 1012736
[ 0.000000] DMA zone: 1728 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 196608 pages, LIFO batch:63
[ 0.000000] HighMem zone: 816128 pages, LIFO batch:63
[ 0.000000] random: get_random_bytes called from start_kernel+0xc0/0x4e8 with crng_init=0
[ 0.000000] percpu: Embedded 17 pages/cpu s39488 r8192 d21952 u69632
[ 0.000000] pcpu-alloc: s39488 r8192 d21952 u69632 alloc=17*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1011008
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 cma=64M cma=256M smsc95xx.macaddr=DC:A6:32:22:95:17 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 3735592K/4050944K available (8192K kernel code, 661K rwdata, 2352K rodata, 2048K init, 850K bss, 53208K reserved, 262144K cma-reserved, 3264512K highmem)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0x(ptrval) - 0x(ptrval) (10208 kB)
.init : 0x(ptrval) - 0x(ptrval) (2048 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 662 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 851 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 28124 entries in 83 pages
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[ 0.000005] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[ 0.000022] Switching to timer-based delay loop, resolution 18ns
[ 0.000250] Console: colour dummy device 80x30
[ 0.000703] console [tty1] enabled
[ 0.000755] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)
[ 0.000797] pid_max: default: 32768 minimum: 301
[ 0.001071] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.001105] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.001866] CPU: Testing write buffer coherency: ok
[ 0.002290] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.002946] Setting up static identity map for 0x200000 - 0x20003c
[ 0.003117] rcu: Hierarchical SRCU implementation.
[ 0.003993] smp: Bringing up secondary CPUs ...
[ 0.004905] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.005938] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.006928] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.007060] smp: Brought up 1 node, 4 CPUs
[ 0.007128] SMP: Total of 4 processors activated (432.00 BogoMIPS).
[ 0.007151] CPU: All CPU(s) started in HYP mode.
[ 0.007171] CPU: Virtualization extensions available.
[ 0.007965] devtmpfs: initialized
[ 0.018024] VFP support v0.3: implementor 41 architecture 3 part 40 variant 8 rev 0
[ 0.018255] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.018298] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.025825] pinctrl core: initialized pinctrl subsystem
[ 0.026690] NET: Registered protocol family 16
[ 0.029612] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.031030] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.031062] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.031268] Serial: AMBA PL011 UART driver
[ 0.034337] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[ 0.069955] bcm2835-dma fe007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
[ 0.072420] vgaarb: loaded
[ 0.072806] SCSI subsystem initialized
[ 0.073014] usbcore: registered new interface driver usbfs
[ 0.073079] usbcore: registered new interface driver hub
[ 0.073189] usbcore: registered new device driver usb
[ 0.090386] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-09-24 17:34, variant start
[ 0.100109] raspberrypi-firmware soc:firmware: Firmware hash is cd3add54955f8fa065b414d8fc07c525e7ddffc8
[ 0.111537] clocksource: Switched to clocksource arch_sys_counter
[ 0.188980] VFS: Disk quotas dquot_6.6.0
[ 0.189076] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.189242] FS-Cache: Loaded
[ 0.189439] CacheFiles: Loaded
[ 0.189960] simple-framebuffer: probe of 0.framebuffer failed with error -12
[ 0.198751] NET: Registered protocol family 2
[ 0.199409] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[ 0.199454] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.199541] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.199625] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.199758] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.199802] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.200114] NET: Registered protocol family 1
[ 0.200663] RPC: Registered named UNIX socket transport module.
[ 0.200689] RPC: Registered udp transport module.
[ 0.200711] RPC: Registered tcp transport module.
[ 0.200732] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.200760] PCI: CLS 0 bytes, default 64
[ 0.203750] Initialise system trusted keyrings
[ 0.203930] workingset: timestamp_bits=14 max_order=20 bucket_order=6
[ 0.212979] FS-Cache: Netfs 'nfs' registered for caching
[ 0.213490] NFS: Registering the id_resolver key type
[ 0.213532] Key type id_resolver registered
[ 0.213554] Key type id_legacy registered
[ 0.213585] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.215819] Key type asymmetric registered
[ 0.215845] Asymmetric key parser 'x509' registered
[ 0.215966] bounce: pool size: 64 pages
[ 0.216020] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.216196] io scheduler noop registered
[ 0.216220] io scheduler deadline registered (default)
[ 0.216383] io scheduler cfq registered
[ 0.216406] io scheduler mq-deadline registered (default)
[ 0.216429] io scheduler kyber registered
[ 0.247321] brcm-pcie fd500000.pcie: dmabounce: initialised - 32768 kB, threshold 0x00000000c0000000
[ 0.247366] brcm-pcie fd500000.pcie: could not get clock
[ 0.247440] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.247492] brcm-pcie fd500000.pcie: MEM 0x600000000..0x603ffffff -> 0xf8000000
[ 0.301574] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[ 0.301859] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[ 0.301889] pci_bus 0000:00: root bus resource [bus 00-01]
[ 0.301919] pci_bus 0000:00: root bus resource [mem 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff])
[ 0.301982] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400
[ 0.302122] pci 0000:00:00.0: PME# supported from D0 D3hot
[ 0.304842] PCI: bus0: Fast back to back transfers disabled
[ 0.304873] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.305094] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330
[ 0.305219] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00000fff 64bit]
[ 0.305538] pci 0000:01:00.0: PME# supported from D0 D3cold
[ 0.308262] PCI: bus1: Fast back to back transfers disabled
[ 0.308292] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
[ 0.308339] pci 0000:00:00.0: BAR 8: assigned [mem 0x600000000-0x6000fffff]
[ 0.308374] pci 0000:01:00.0: BAR 0: assigned [mem 0x600000000-0x600000fff 64bit]
[ 0.308462] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 0.308492] pci 0000:00:00.0: bridge window [mem 0x600000000-0x6000fffff]
[ 0.308712] pcieport 0000:00:00.0: enabling device (0140 -> 0142)
[ 0.308908] pcieport 0000:00:00.0: Signaling PME with IRQ 55
[ 0.309082] pcieport 0000:00:00.0: AER enabled with IRQ 55
[ 0.309264] pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 0.312558] iproc-rng200 fe104000.rng: hwrng registered
[ 0.312789] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 0.313299] vc-sm: Videocore shared memory driver
[ 0.313709] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
[ 0.323650] brd: module loaded
[ 0.333253] loop: module loaded
[ 0.334000] Loading iSCSI transport class v2.0-870.
[ 0.335667] libphy: Fixed MDIO Bus: probed
[ 0.336099] bcmgenet fd580000.genet: failed to get enet clock
[ 0.336131] bcmgenet fd580000.genet: GENET 5.0 EPHY: 0x0000
[ 0.336161] bcmgenet fd580000.genet: failed to get enet-wol clock
[ 0.336190] bcmgenet fd580000.genet: failed to get enet-eee clock
[ 0.336226] bcmgenet: Skipping UMAC reset
[ 0.336468] unimac-mdio unimac-mdio.-19: DMA mask not set
[ 0.351567] libphy: bcmgenet MII bus: probed
[ 0.392060] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus at 0x(ptrval)
[ 0.392980] usbcore: registered new interface driver r8152
[ 0.393057] usbcore: registered new interface driver lan78xx
[ 0.393124] usbcore: registered new interface driver smsc95xx
[ 0.393437] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 0.393482] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 0.395737] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000001000000890
[ 0.396071] genirq: irq_chip Brcm_MSI did not update eff. affinity mask of irq 56
[ 0.396944] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.396977] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.397006] usb usb1: Product: xHCI Host Controller
[ 0.397029] usb usb1: Manufacturer: Linux 4.19.75-v7l+ xhci-hcd
[ 0.397053] usb usb1: SerialNumber: 0000:01:00.0
[ 0.397577] hub 1-0:1.0: USB hub found
[ 0.397676] hub 1-0:1.0: 1 port detected
[ 0.398152] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 0.398188] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 0.398225] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
[ 0.398643] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
[ 0.398676] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.398704] usb usb2: Product: xHCI Host Controller
[ 0.398727] usb usb2: Manufacturer: Linux 4.19.75-v7l+ xhci-hcd
[ 0.398751] usb usb2: SerialNumber: 0000:01:00.0
[ 0.399249] hub 2-0:1.0: USB hub found
[ 0.399332] hub 2-0:1.0: 4 ports detected
[ 0.400536] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 0.426116] dwc_otg fe980000.usb: base=(ptrval)
[ 0.626383] Core Release: 2.80a
[ 0.626418] Setting default values for core params
[ 0.626460] Finished setting default values for core params
[ 0.826801] Using Buffer DMA mode
[ 0.826824] Periodic Transfer Interrupt Enhancement - disabled
[ 0.826847] Multiprocessor Interrupt Enhancement - disabled
[ 0.826871] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 0.826941] Dedicated Tx FIFOs mode
[ 0.827865] WARN::dwc_otg_hcd_init:1045: FIQ DMA bounce buffers: virt = ded38000 dma = 0x00000000ded38000 len=9024
[ 0.827913] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 0.827970] dwc_otg: Microframe scheduler enabled
[ 0.828181] WARN::hcd_init_fiq:457: FIQ on core 1
[ 0.828211] WARN::hcd_init_fiq:458: FIQ ASM at c07b6224 length 36
[ 0.828241] WARN::hcd_init_fiq:497: MPHI regs_base at f0810200
[ 0.828290] dwc_otg fe980000.usb: DWC OTG Controller
[ 0.828335] dwc_otg fe980000.usb: new USB bus registered, assigned bus number 3
[ 0.828387] dwc_otg fe980000.usb: irq 37, io mem 0x00000000
[ 0.828452] Init: Port Power? op_state=1
[ 0.828473] Init: Power Port (0)
[ 0.828732] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.828765] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.828793] usb usb3: Product: DWC OTG Controller
[ 0.828817] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
[ 0.828841] usb usb3: SerialNumber: fe980000.usb
[ 0.829375] hub 3-0:1.0: USB hub found
[ 0.829438] hub 3-0:1.0: 1 port detected
[ 0.830004] dwc_otg: FIQ enabled
[ 0.830013] dwc_otg: NAK holdoff enabled
[ 0.830022] dwc_otg: FIQ split-transaction FSM enabled
[ 0.830035] Module dwc_common_port init
[ 0.830238] usbcore: registered new interface driver uas
[ 0.830364] usbcore: registered new interface driver usb-storage
[ 0.830544] mousedev: PS/2 mouse device common for all mice
[ 0.831748] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 0.831961] bcm2835-cpufreq: min=600000 max=1500000
[ 0.832578] sdhci: Secure Digital Host Controller Interface driver
[ 0.832602] sdhci: Copyright(c) Pierre Ossman
[ 0.833001] mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
[ 0.833386] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.836374] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.836529] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.836679] usbcore: registered new interface driver usbhid
[ 0.836702] usbhid: USB HID core driver
[ 0.837468] vchiq: vchiq_init_state: slot_zero = (ptrval), is_master = 0
[ 0.839266] [vc_sm_connected_init]: start
[ 0.848204] [vc_sm_connected_init]: end - returning 0
[ 0.849280] Initializing XFRM netlink socket
[ 0.849321] NET: Registered protocol family 17
[ 0.849422] Key type dns_resolver registered
[ 0.849729] Registering SWP/SWPB emulation handler
[ 0.850320] registered taskstats version 1
[ 0.850350] Loading compiled-in X.509 certificates
[ 0.858093] uart-pl011 fe201000.serial: cts_event_workaround enabled
[ 0.858182] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
[ 0.861202] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 0.861777] brcmstb_thermal fd5d2200.thermal: registered AVS TMON of-sensor driver
[ 0.862397] mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 0.862424] mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
[ 0.888458] sdhci-iproc fe340000.emmc2: Linked as a consumer to regulator.1
[ 0.905895] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 0.907520] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.909141] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.912041] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 0.913665] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 0.922529] mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
[ 0.925076] of_cfs_init
[ 0.925179] of_cfs_init: OK
[ 0.925787] Waiting for root device PARTUUID=6c586e13-02...
[ 0.970241] random: fast init done
[ 0.971615] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 0.982443] mmc1: new high speed SDIO card at address 0001
[ 1.027370] mmc0: new ultra high speed DDR50 SDHC card at address aaaa
[ 1.028544] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[ 1.030879] mmcblk0: p1 p2
[ 1.051999] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 1.052069] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.057087] devtmpfs: mounted
[ 1.063407] Freeing unused kernel memory: 2048K
[ 1.081794] Run /sbin/init as init process
[ 1.154191] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[ 1.154238] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.154266] usb 1-1: Product: USB2.0 Hub
[ 1.156412] hub 1-1:1.0: USB hub found
[ 1.156754] hub 1-1:1.0: 4 ports detected
[ 1.301940] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.333167] usb 2-2: New USB device found, idVendor=0781, idProduct=5591, bcdDevice= 1.00
[ 1.333206] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.333233] usb 2-2: Product: Ultra USB 3.0
[ 1.333258] usb 2-2: Manufacturer: SanDisk
[ 1.333282] usb 2-2: SerialNumber: 010173772a1b9c4c7550a5023919be4e27bdd85c7040632379c85dbf31f1fe1c5f0a00000000000000000000cf3a5b1a001f2f009155810796269acc
[ 1.335876] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 1.336372] scsi host0: usb-storage 2-2:1.0
[ 1.481585] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd
[ 1.482177] systemd[1]: System time before build time, advancing clock.
[ 1.566201] NET: Registered protocol family 10
[ 1.567421] Segment Routing with IPv6
[ 1.599944] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 1.600646] systemd[1]: Detected architecture arm.
[ 1.612128] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[ 1.612168] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.612223] usb 1-1.3: Product: USB 2.0 Hub
[ 1.613623] systemd[1]: Set hostname to <raspberrypi-pi4-master>.
[ 1.614079] hub 1-1.3:1.0: USB hub found
[ 1.614274] hub 1-1.3:1.0: 4 ports detected
[ 1.615614] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 1.711663] usb 1-1.4: new full-speed USB device number 4 using xhci_hcd
[ 1.852392] usb 1-1.4: New USB device found, idVendor=03eb, idProduct=204b, bcdDevice= 0.00
[ 1.852434] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.852466] usb 1-1.4: Product: CUL868
[ 1.852490] usb 1-1.4: Manufacturer: busware.de
[ 1.888261] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
[ 1.888322] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
[ 2.041592] usb 1-1.3.4: new full-speed USB device number 5 using xhci_hcd
[ 2.196911] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.204823] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.208910] systemd[1]: Created slice User and Session Slice.
[ 2.209512] random: systemd: uninitialized urandom read (16 bytes read)
[ 2.209591] systemd[1]: Reached target Swap.
[ 2.210682] systemd[1]: Listening on Journal Socket.
[ 2.211572] systemd[1]: Listening on udev Kernel Socket.
[ 2.289630] usb 1-1.3.4: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 2.289702] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.289741] usb 1-1.3.4: Product: FT232R USB UART
[ 2.289766] usb 1-1.3.4: Manufacturer: FTDI
[ 2.289790] usb 1-1.3.4: SerialNumber: AB0JDXH6
[ 2.392968] scsi 0:0:0:0: Direct-Access SanDisk Ultra USB 3.0 1.00 PQ: 0 ANSI: 6
[ 2.394857] sd 0:0:0:0: [sda] 120176640 512-byte logical blocks: (61.5 GB/57.3 GiB)
[ 2.396452] sd 0:0:0:0: [sda] Write Protect is off
[ 2.396492] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 2.397332] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2.406765] sda: sda1
[ 2.411465] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 2.873171] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 2.969315] systemd-journald[125]: Received request to flush runtime journal from PID 1
[ 3.298041] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3.418881] usbcore: registered new interface driver usbserial_generic
[ 3.419048] usbserial: USB Serial support registered for generic
[ 3.429737] usbcore: registered new interface driver ftdi_sio
[ 3.429812] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3.430268] ftdi_sio 1-1.3.4:1.0: FTDI USB Serial Device converter detected
[ 3.430411] usb 1-1.3.4: Detected FT232RL
[ 3.445249] usb 1-1.3.4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 3.728433] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 3.769083] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[ 3.769590] bcm2835_audio soc:audio: card created with 8 channels
[ 3.928859] [drm] No displays found. Consider forcing hotplug if HDMI is attached
[ 3.928955] vc4-drm soc:gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
[ 3.931058] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 1
[ 3.931070] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.931080] [drm] No driver support for vblank timestamp query.
[ 3.931089] [drm] Setting vblank_disable_immediate to false because get_vblank_timestamp == NULL
[ 4.112472] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.223442] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4.275838] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 4.284151] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.284807] usbcore: registered new interface driver brcmfmac
[ 4.506169] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.521284] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[ 4.761144] rpivid-mem feb00000.hevc-decoder: rpivid-hevcmem initialised: Registers at 0xfeb00000 length 0x0000ffff
[ 4.762606] rpivid-mem feb10000.rpivid-local-intc: rpivid-intcmem initialised: Registers at 0xfeb10000 length 0x00000fff
[ 4.763141] rpivid-mem feb20000.h264-decoder: rpivid-h264mem initialised: Registers at 0xfeb20000 length 0x0000ffff
[ 4.763730] rpivid-mem feb30000.vp9-decoder: rpivid-vp9mem initialised: Registers at 0xfeb30000 length 0x0000ffff
[ 4.858234] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.860381] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 4.860397] [vc_sm_connected_init]: start
[ 4.863521] [vc_sm_connected_init]: installed successfully
[ 4.900380] media: Linux media interface: v0.10
[ 4.934977] videodev: Linux video capture interface: v2.00
[ 4.945998] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[ 4.950614] usbcore: registered new interface driver cdc_acm
[ 4.950626] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 4.968558] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.968569] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.977406] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.003673] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.028198] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 5.028247] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 5.034030] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 5.034062] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 5.075808] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 5.075842] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 6.092400] uart-pl011 fe201000.serial: no DMA platform data
[ 6.108396] random: crng init done
[ 6.108410] random: 7 urandom warning(s) missed due to ratelimiting
[ 6.202625] 8021q: 802.1Q VLAN Support v1.8
[ 6.333774] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 6.399894] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 6.399960] brcmfmac: power management disabled
[ 6.695398] bcmgenet: Skipping UMAC reset
[ 6.802073] bcmgenet fd580000.genet: configuring instance for external RGMII (no delay)
[ 6.802669] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 7.831777] bcmgenet fd580000.genet eth0: Link is Down
[ 10.951826] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 10.951863] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 12.807571] Bluetooth: Core ver 2.22
[ 12.807643] NET: Registered protocol family 31
[ 12.807653] Bluetooth: HCI device and connection manager initialized
[ 12.807674] Bluetooth: HCI socket layer initialized
[ 12.807690] Bluetooth: L2CAP socket layer initialized
[ 12.807734] Bluetooth: SCO socket layer initialized
[ 12.825629] Bluetooth: HCI UART driver ver 2.3
[ 12.825644] Bluetooth: HCI UART protocol H4 registered
[ 12.825729] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 12.825963] Bluetooth: HCI UART protocol Broadcom registered
[ 12.875363] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead
[ 13.006931] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 13.006937] Bluetooth: BNEP filters: protocol multicast
[ 13.006948] Bluetooth: BNEP socket layer initialized
pi@raspberrypi-pi4-master:~ $
Ich kann nicht so richtig was damit anfangen, aber vielleicht sieht einer von euch die Ursache des hängenbleibens oder weiß wie ich sonst noch dem Fehler auf die Spur kommen könnte. Ich habe das Modul bei mir in die komplette Solar-Auswertung eingebaut und kann es nicht durch irgendwas anders ersetzen.
Gruß aus Köln
norbert
Ich habe jetzt den raspberry neiú gebootet und FHEM neu gestartet. Jetzt meldet das OBIS Modul einen ständig wechselnden State von opened und disconnected, was dann auch sekündlich meine LOG Datei füllt:
2020.01.11 16:45:47 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:47 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:47 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:47 3: Init done
2020.01.11 16:45:47 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2020.01.11 16:45:48 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2020.01.11 16:45:48 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)
2020.01.11 16:45:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:48 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:48 3: Init done
2020.01.11 16:45:48 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:48 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:48 3: Init done
2020.01.11 16:45:48 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:48 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:48 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:48 3: Init done
2020.01.11 16:45:48 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:49 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2020.01.11 16:45:49 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2020.01.11 16:45:49 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)
2020.01.11 16:45:49 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2020.01.11 16:45:49 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2020.01.11 16:45:49 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)
2020.01.11 16:45:49 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:49 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:49 3: Init done
2020.01.11 16:45:49 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
2020.01.11 16:45:49 1: /dev/ttyUSB0 disconnected, waiting to reappear (ISKRA_MT691)
2020.01.11 16:45:49 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.01.11 16:45:49 3: Init done
2020.01.11 16:45:49 1: /dev/ttyUSB0 reappeared (ISKRA_MT691)
Und es taucht immer ein "Device"? TCM_ESP2.0 im LOG auf. Ich hoffe damit können die FHEM Spezialisten hier im Booard was mit anfangen. Ich leider nicht und weiß auch keinen Rat dazu.
Gruß
Norbert
Hallo zusammen,
habe mit OBIS Modul (15.2.2019) das Problem mit dem Reading "power", hier mal Auszüge aus dem Reading :
erstmal das DEF (Stromzaehler Siemens TD 3511):
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0@300,7,E,1 VSM102
Auszug aus dem Reading :
power 565.972 2020-01-11 17:42:14
state opened 2020-01-11 16:57:47
power 0.476 2020-01-11 17:45:36
state opened 2020-01-11 16:57:47
power 565.972 2020-01-11 17:48:14
state opened 2020-01-11 16:57:47
power 0.48 2020-01-11 17:51:39
state opened 2020-01-11 16:57:47
offensichtlich wird der powerwert nach jedem intervall (180 sec) auf den Wert 565.972 gesetzt ?
Habe den Boud schon mal mit 9600 versucht, dann gibt es keine readings mehr.
Bin ziemlich ratlos, da alle anderen Werte stimmen.
Gruß Peter
Zitat/dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
Wenn Du es nicht weißt ? Muss ja ein device in Deinem System sein. Per autocreate angelegt ? Guck mal im Log.
Benutzt den selben Port wie der ISKRA. Also löschen oder wenigstens umdefinieren.
ZitatProblem mit dem Reading "power",
Dann mal ein verbose=5-Logauszug.
Grüße Markus
Hallo Markus,
hier das Log nach "verbose 5" :
2020-01-11_18:39:32 IR_Kopf 0.9.1: 18:39:32
2020-01-11_18:39:32 IR_Kopf aktuell: 0.565972
2020-01-11_18:39:36 IR_Kopf 0.9.2: 20-01-11
2020-01-11_18:39:36 IR_Kopf 0.2.0: 11
2020-01-11_18:39:36 IR_Kopf power: 0.538
2020-01-11_18:39:36 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:36 IR_Kopf feed_L1: 0
2020-01-11_18:39:36 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:39 IR_Kopf 3.7.0: 0
2020-01-11_18:39:39 IR_Kopf feed_L2: 0.127
2020-01-11_18:39:39 IR_Kopf 14.7: 50.01
2020-01-11_18:39:39 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:39 IR_Kopf 32.7: 234
2020-01-11_18:39:39 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:44 IR_Kopf 52.7: 233.8
2020-01-11_18:39:44 IR_Kopf 72.7: 235.5
2020-01-11_18:39:44 IR_Kopf 31.7: 0.46
2020-01-11_18:39:44 IR_Kopf 51.7: 1.2
2020-01-11_18:39:44 IR_Kopf 71.7: 1.03
2020-01-11_18:39:44 IR_Kopf 91.7: 1.14
2020-01-11_18:39:44 IR_Kopf 81.7.4: -3.7
2020-01-11_18:39:44 IR_Kopf 81.7.15: -12.9
2020-01-11_18:39:44 IR_Kopf 81.7.26: -17.3
2020-01-11_18:39:44 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:49 IR_Kopf 81.7.1: 119.7
2020-01-11_18:39:49 IR_Kopf 81.7.12: 120.1
2020-01-11_18:39:49 IR_Kopf 81.7.20: 120.1
2020-01-11_18:39:49 IR_Kopf 32.36.0: 05-01-01 00:00
2020-01-11_18:39:49 IR_Kopf 52.36.0: 05-01-01 00:00
2020-01-11_18:39:49 IR_Kopf 72.36.0: 05-01-01 00:00
2020-01-11_18:39:49 IR_Kopf aktuell: 0.000538
2020-01-11_18:39:54 IR_Kopf 32.32.0: 05-01-01 00:00
2020-01-11_18:39:54 IR_Kopf 52.32.0: 05-01-01 00:00
2020-01-11_18:39:54 IR_Kopf 72.32.0: 05-01-01 00:00
2020-01-11_18:39:54 IR_Kopf C.2.1: 05-01-01 00:00
2020-01-11_18:39:54 IR_Kopf C.7.0: 19-07-24 00:13
2020-01-11
_18:39:54 IR_Kopf C.7.1: 14-04-06 14:07
2020-01-11_18:39:54 IR_Kopf aktuell: 0.000538
Gruß Peter
was ist das ? sieht so aus
edit: persönliche Daten gelöscht
Ui, ist der gesprächig. Die entscheidende Stelle hab ich nicht gesehen, aber Du hast ja Monatswerte. Möglicherweise auch für power ??? :-\2020.01.11 18:51:01 5: OBIS (zaehler) - Msg-Parse: 1-0:16.7.0*255(174.6*W)
2020.01.11 18:51:01 5: Msg 1-0:16.7.0*255(174.6*W) is of type Channels
Hallo Markus,
glaube habe den richtigen Ansatz gefunden, "power" als momentaner Verbrauchswert ist offensichtlich der falsche Readingswert, es muß bestimmt "1.7.0" sein :
020.01.11 19:33:42 5: OBIS (IR_Kopf) - Msg-Parse: C.60.5.2(07.000 0000 B7FD)(14-03-12 16:55)
2020.01.11 19:33:42 5: OBIS (IR_Kopf) - Msg-Parse: 1.7.0(0.696*kW)
2020.01.11 19:33:42 5: Msg 1.7.0(0.696*kW) is of type Channels
2020.01.11 19:33:42 5: OBIS (IR_Kopf) - Msg-Parse: C.60.5.1(C.01)
2
nur sehe ich den im aktuellen Reading von dem IR_Kopf nicht.
Das Modul habe ich erst seit ein paar Tagen am probieren.
Gruß Peter
IgnoreUnknown auf off ?
stand auf on, nach Änderung auf off keine Auswirkung auf "power" , wieder auf 565.972.
Bin Laie, warum erscheint in fhem.log der OBIS Wert "1.7.0" und nicht im Reading von IR_Kopf ?
Hallo Markus,
nach einem update von 47_OBIS.pm, dann fhem.log geleert, raspi Neustart und fhem restart, hier das Ergebnis in der fhem.log :
2020.01.11 21:53:29 1: Including fhem.cfg
2020.01.11 21:53:32 3: WEB: port 8083 opened
2020.01.11 21:53:33 2: eventTypes: loaded 91 events from ./log/eventTypes.txt
2020.01.11 21:53:33 3: telnetPort: port 7072 opened
2020.01.11 21:53:33 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 38.
2020.01.11 21:53:33 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 38.
2020.01.11 21:53:33 3: Opening IR_Kopf device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0
2020.01.11 21:53:33 3: Setting IR_Kopf serial parameters to 300,7,E,1
2020.01.11 21:53:33 3: Init done
2020.01.11 21:53:33 3: IR_Kopf device opened
die Hinweise auf die Zeilen in 47_OBIS.pm können vielleicht hilfreich sein.
Gruß Peter
Nein, die warnings sind "normal".
Zitatstand auf on, nach Änderung auf off keine Auswirkung auf "power" , wieder auf 565.972.
Bin Laie, warum erscheint in fhem.log der OBIS Wert "1.7.0" und nicht im Reading von IR_Kopf ?
Auf power wird sich das auch nicht auswirken. Das musst/kannst Du über channels machen.
Aber eigentlich müsste dann u.a. 1.7.0 als reading auftauchen. ??? :-\
und genau das 1.7.0 erscheint im reading nicht :-\ :-[
wünsche jetzt eine gute Nachtruhe
Gruß Peter
Ich hab mal für Dich in den Code gegucktmy %OBIS_channels = ( "...
"1" =>"power",
"15" =>"power",
"16" =>"power",
....
Du hast wahrscheinlich mindestens 2 dieser "channels". Das erklärte das überschreiben im power-reading und das Fehlen von 1.7.0.
Du musst per channel-Attribut mappen....
Hallo Markus,
danke erstmal für Deine Geduld mit einem schwäbischen Grufti. In 47_OBIS.pm steht ja das drin :
my %OBIS_channels = ( "21" =>"power_L1",
"41" =>"power_L2",
"61" =>"power_L3",
"12" =>"voltage_avg",
"32" =>"voltage_L1",
"52" =>"voltage_L2",
"72" =>"voltage_L3",
"11" =>"current_sum",
"31" =>"current_L1",
"51" =>"current_L2",
"71" =>"current_L3",
"1.8" =>"total_consumption",
"2.8" =>"total_feed",
"2" =>"feed_L1",
"4" =>"feed_L2",
"6" =>"feed_L3",
"1" =>"power",
"15" =>"power",
"16" =>"power",
"24" =>"Gas",
da voller Unkenntnis hab ich mal in IR_Kopf channels das eingetragen :
{"1.7.0"=>"aktuell"}
es erscheint halt trotzdem kein "1.7.0" Reading, wie macht man das denn richtig ?
Gruß Peter
Hallo Markus,
Kommando zurück - es funktioniert, habe nicht lange genug gewartet. ;D ;D ;D
Bedanke mich herzlich für Deine Unterstützung.
Eine Frage hätte ich dennoch, mein DEF im Raspi direkt am Zählerkasten heisst ja so :
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD01QVKZ-if00-port0@300,7,E,1 VSM102
wie könnte man von einem entfernten (Haupt)FHEM auf diesen ttyUSB0 zugreifen ?
Gruß Peter
Es gibt ne Menge Lösungen ohne FHEM(per LAN od. WLAN). Mit FHEM müsste fhem2fhem die Lösung sein.
Ok, hatte ursprünglich einen YPORT+(ser2net > WLAN) in Verbindung mit einem php skript und volkszähler im Einsatz. Leider hat sich der YPORT verabschiedet, deshalb jetzt diese Lösung in Verbindung mit fhemfhem2 und es funktioniert nun ja auch.
Nochmal besten Dank und Gruß von Peter
Hallo Markus,
habe jetzt doch noch eine Frage, mit :
channels {"1.7.0"=>"E-aktuell"}
geht das super, wie bringt man jetzt noch diesen dazu ?
{"2.7.0"=>"P-aktuell"}
Gruß Peter
channels {"1.7.0"=>"E-aktuell","2.7.0"=>"P-aktuell"}
Kannst Du noch in dem einen riesenlangen Post die letzte Zeile rausschmeißen u. das Codeende einfügen: "[/code]" (ohne " natürlich)
Grüße Markus
habe den Eintrag einfach gelöscht, ist hoffentlich gut so.
Danke für den Tipp, probiert habe ich einige Optionen - die einfachste nicht.
Gruß Peter
Hallo,
da ich jetzt auch auf OBIS V2 umgestiegen bin (bis jetzt hatte ich das Script "AS1440.sh" im Einsatz) und ich in den vielen Beiträgen noch nicht die passende Antwort gefunden habe, versuche ich hiermit:
Ist mittlerweile eine Baudraten-Umschaltung implementiert? Denn das Auslesen aller Parameter des AS1440 dauert bei mir fast 2 min!!
Oder kann man die Anzahl der Parameter deutlich reduzieren?
Denn ich habe ein einfach Script geschrieben, was am Ende des Tages (23:59) eine Tagesauswertung mit den letzten Werten des AS1440 und meiner PV Anlage errechnet.
Da aber das LOG File vom AS1140 am ende des Tages nicht immer mit den gleichen Werten endet (da der letzte Abruf wegen der langen Auslesezeit nicht vor 0.00 Uhr fertig wird) bekommt mein Script immer die falschen Werte. (Ich hoffe das ist irgendwie verständlich geschrieben).
Vielen Dank im Voraus für Tipps.
Grüße Jürgen
Hallo Jürgen,
zu Deiner Frage kann ich vielleicht einen Tipp geben, habe das auch irgendwann hier im Forum erhalten da ich ein ähnliches Problem hatte. Mit diesem "at" werden Daten aus heute in das Log von morgen weitergeschrieben, wie das genau funktioniert ist mir zu hoch - aber es funktioniert :
define a_actuator at +*00:05 {addLog("AC_LSHK","state");;addLog("HK_szeit","state");;addLog("UX_v22","state");;addLog("UX_v06","state");;addLog("TH_HKRestw","temperature")}
Dann erscheint eine Eingabemaske mit möglichen Eingaben. Es ist bestimmt einen Versuch wert.
Da Du diese Daten vermutlich auch irgendwo speichern wirst kann ich noch einen Tipp geben. Meine Verbrauchsdaten (HT,NT,Einsp.,Tagesertrag etc.) stehen in einer Log, dieses Log ist mit einer Libreoffice Calc verknüpft und die Calc-Datei wird bei mir um 22:00 Uhr per cron gestartet, mit dem Start läuft ein integriertes Makro ab das meine Daten jeweils immer in die erste freie Zeile schreibt.
Bei Interesse stelle ich die Calc-Tabelle gerne zu Verfügung.
erstmal guten Erfolg und LG von Peter
Ich habe immer noch das Problem, dass das OBIS Modul auf disconnected steht und von sich aus auch keinen Reconnect mehr durchführt. Zum Zeitpunkt des Disconnectes habe ich folgendes im LOG stehen:
2020.01.22 11:19:51.247 1: 10.10.2.3:23 disconnected, waiting to reappear (myPowerMeter)
2020.01.22 11:19:51.250 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.01.22 11:19:51.250 1: stacktrace:
2020.01.22 11:19:51.250 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.01.22 11:19:51.250 1: main::OBIS_Read called by fhem.pl (3761)
2020.01.22 11:19:51.250 1: main::CallFn called by fhem.pl (756)
Als Workaround habe ich jetzt erst mal einen AT eingerichtet der alle 10 Sekunden schaut ob die Readings nicht älter als 60 Sekunden sind. Wenn die Readings älter als 60 Sekunden sind wird das OBIS Modul durch ein "modify myPowerMeter 10.10.2.3:23 SML" neugestartet. Direkt danach läuft das Modul wieder, daher schließe ich das ESPEasy Modul, welches die SML Daten liefert, als Fehlerquelle aus.
Wäre gut wenn Sich mal ein Entwickler des Modules dazu meldet.
Gruß
Michael
Hallo Peter,
vielen Dank für Deine Tipps.
Ich wollte das "addlog" ausprobieren, bekomme aber eine Fehlermeldung:
"a_actuator: Undefined subroutine &main::addLog called at (eval 228461) line 1."
In meiner meiner fhem.cfg habe folgendes eingetragen:
define AS1440 OBIS /dev/ttyUSB0@300,7,E,1 AS1440
attr AS1440 interval 300
attr AS1440 pollingMode on
attr AS1440 room Stromdaten
define a_actuator at +*00:05 {addLog("AS1440","1.1.1.8.0")}
Im wiki habe ich unter addLog noch folgendes gelesen:
"HINWEIS: Es gibt mittlerweile (12/2019) das Attribut addLog für FileLog Devices."
Vielleicht versuche ich es mal als Attribut.
Das kopieren der Daten in eine Tabelle ist auch eine gute Idee. Aber ich wollte erstmal die täglichen Verbräuche "nur" grafisch mit FHEM darstellen.
Wichtig für mich wäre immer noch die "Datenflut" des AS1440 zu reduzieren, um auch die LOG Files nicht zu überfüllen.
Vielleicht hat ja da noch jemand einen Tipp?
Grüße
Jürgen
Hallo Jürgen,
ZitatWichtig für mich wäre immer noch die "Datenflut" des AS1440 zu reduzieren, um auch die LOG Files nicht zu überfüllen.
Dazu kannst Du entweder:
- die event....-Attribute beim OBIS-Device(Du schränkst generell events ein)
- den für Dich passenden regexp beim Log-device (Du schränkst nicht die events ein, sondern nur das Datenvolumen im Log)
einsetzen.
Grüße Markus
Hallo Jürgen,
vielleicht habe ich auch etwas nicht richtig verstanden, meine Lösung hat sich auf die Fortschreibung von Events in Logs über den 00:00 Uhr Übergang für Anzeigen im Plot bezogen, also wenn ein Event um 23:35 Uhr erfolgt, soll dieser im Plot
nicht abbrechen.
LG Peter
Hey,
nach Umzug auf ein neues System fehlen mir die Parameter dir_total_consumption und dir_total_feed auf beiden SML Zaehlern.
Konfiguration ist aber wie beim alten System auf dem die Parameter auch jetzt noch da sind.
Ne Idee wie ich die wieder herbekomme?
Das Modul läuft bei mir2-3Tage ohne Probleme, bleibt aber dann plötzlich stehen. So auch heute morgen wieder um 07:48 Uhr. Auch ein get update hilft nicht mehr. Das ist ärgerlich, weil meine gesamte Energie-Berechnung der Photovoltaik-Anlage und des Stromspeichers auch mit diesen Werten gemacht wird, die dann natürlich nicht mehr stimmt.
Im Status steht "opend". Ich habe mal ein "list ISKRA_MT691 gemacht"
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 35
FUUID 5d6a8b10-f33f-6f9b-51f5-096f290c6e0079b0
MeterType SML
NAME ISKRA_MT691
NR 1444
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-01-31 07:07:48 1.0.96.50.1.255 ISK
2020-01-31 07:07:48 Bezug 47
2020-01-31 07:07:48 Einspeisung 0
2020-01-31 07:07:48 power 47
2020-01-31 11:59:55 statTotal_consumption Hour: 0.0 Day: 344.8 Month: 281895.7 Year: 281895.7
2020-01-31 11:59:55 statTotal_consumptionDay 344.8
2020-01-30 23:59:55 statTotal_consumptionDayLast 4495.9
2020-01-31 11:59:55 statTotal_consumptionHour 0.0
2020-01-31 11:59:55 statTotal_consumptionHourLast 0.0
2020-01-31 11:59:55 statTotal_consumptionLast Hour: 0.0 Day: 4495.9 Month: 11749.8 Year: 11749.8 (since: 2019-12-30 )
2020-01-31 11:59:55 statTotal_consumptionMonth 281895.7
2020-01-31 11:59:55 statTotal_consumptionYear 281895.7
2019-12-31 23:59:55 statTotal_consumptionYearLast 11749.8
2020-01-31 11:59:55 statTotal_feed Hour: 0.0 Day: 0.0 Month: 18799.7 Year: 18799.7
2020-01-31 11:59:55 statTotal_feedDay 0.0
2020-01-30 23:59:55 statTotal_feedDayLast 69.6
2020-01-31 11:59:55 statTotal_feedHour 0.0
2020-01-31 11:59:55 statTotal_feedHourLast 0.0
2020-01-31 11:59:55 statTotal_feedLast Hour: 0.0 Day: 69.6 Month: 15.7 Year: 15.7 (since: 2019-12-31_14:55:27 )
2020-01-31 11:59:55 statTotal_feedMonth 18799.7
2019-12-31 23:59:55 statTotal_feedMonthLast 15.7
2020-01-31 11:59:55 statTotal_feedYear 18799.7
2019-12-31 23:59:55 statTotal_feedYearLast 15.7
2020-01-30 19:17:42 state opened
2020-01-31 07:07:48 total_consumption 2085544.3
2020-01-31 07:07:48 total_feed 9583067
helper:
BUFFER
EoM -1
SPEED 5
SPEED2 5
TRIGGERTIME 1580408262.16903
_98_statistics myStatDevices
Channels:
DEVICES:
30
directions:
Attributes:
alias Stromzähler RNG
event-min-interval .*:30
group Systemkontrolle
interval 30
room System
userReadings Bezug:power.* { if (ReadingsVal($name,"power",0) > 0) { ReadingsVal($name,"power",0) } else { 0 } }, Einspeisung:power.* { if (ReadingsVal($name,"power",0) <= 0) { - ReadingsVal($name,"power",0) } else { 0 } }
Da sehe ich aber auch nichts ungewöhnliches, warum das Modul plötzlich steht. Woran kann das liegen? und vor allem, was kann ich machen um herauszufinden was die Ursache ist. Im LOG habe ich keinen Eintrag zu dieser Zeit gefunden.
Gruß aus Köln
Norbert
ZitatDas Modul läuft bei mir2-3Tage ohne Probleme, bleibt aber dann plötzlich stehen.
Hallo, ich hatte ein ähnliches Problem, bis ich rausgefunden hatte, dass mein "Volkszähler" immer mal wieder "falsche" SML-Files übermittelt. Es fehlen dann meistens zwei Bytes, was aber z.B. auch an der Software des Zählers liegen könnte (keine Schuldzuweisung hier). Vielleicht mal "vorne anfangen" und die Files bzw. deren Länge loggen !?
Danke für deinen Hinweis aber ich habe keinen Volkszähler dran, sondern dieses Teil:
Weidmann Elektronik Stromzähler, Smart Meter IR (Infrarot) Schreib/Lesekopf USB (Optokopf)
und der Kopf hat ja einige Zeit einwandfrei gearbeitet und ich habe nichts an der Verkabelung oder am Lesekopf verändert.
Gruß
Norbert
Das war auch eher als "Anregung zur Selbsthilfe" gedacht. Ich würde auf "verbose 5" stellen und mich auf die Lauer legen, bis Du die Anweisungen eingrenzen kannst, bei denen das Programm stehen bleibt. In der Zwischenzeit kannst Du ja schon einmal ein bisschen die "SML-Norm" studieren. Dann sukzessive Log3-Anweisungen verteilen, bis der "Übeltäter" feststeht. Dauert halt aber nur so geht's, wenn Dir vorher keiner einen Tipp geben kann.
Es ist definitiv so, wie Raymund gesagt hat:
Dir fehlen ein paar Bytes. Das letzte Telegramm wurde nicht vollständig empfangen.
Hinweis dafür ist das Internal "EoM" (=EndOfMessage), welches solange auf -1 steht, bis eine komplette Message empfangen wurde.
lg, Stefan
Auch die Position des Lesekopfes (genau) über den/der IR-LED kann bedeutsam sein. Ich konnte damit meine Lesefehler zwar nicht ausschalten aber doch reduzieren. Die "Pünktchen" auf dem Zählergehäuse müssen übrigens nicht automatisch richtig positioniert sein. Also mal seitlich "reinlinsen" ...
Ich denke, Raymund hat ne Menge Tipps gegeben, wie man dem Problem von "disconnects"(state=opened, aber kein Datenempfang;state wechselt auf disconnected...)auf die Spur kommen kann.
Ihr müsst auch mal zusammenfassend Eure Installation u. das Problem mit den verschiedenen Problemlösungsversuchen u. deren Erfolg beschreiben. Ist schon schwierig über die verteilten Posts die verschiedenenen Situationen(Norbert, Michael....) nachzuvollziehen. :'(
Was sind Eure workarounds ? physisches disconnect/reconnect, defmod, get device update, FHEM-reboot, Systemreboot, delete/define device.....
Ich selber hab mittlerweile 3 pushende Zählertypen und über Jahre noch nie das beschriebene Problem mit serial-USB-Lesekopf gehabt. ???
ZitatDas letzte Telegramm wurde nicht vollständig empfangen.
Hi Stefan, aber dann müsste doch beim nächsten Datensatz wieder alles funktionieren, oder ?
@Norbert: Mir ist jetzt nur Dein interval=30 aufgefallen. Was passiert, wenn Du mal ein größeres Intervall nimmst ? (nur so ne Idee)
Grüße Markus
ZitatHi Stefan, aber dann müsste doch beim nächsten Datensatz wieder alles funktionieren, oder ?
Nein, weil ja noch immer auf das Ende des vergangenen gewartet wird.
Ich glaub ich verstehe. Aber irgendwann müsste das Modul das "warten" ja beenden und den "Puffer" leeren. :-\ Unvollständige/Fehlerhafte Datensätze kann es ja immer mal geben.
Ist das bei allen Zählertypen gleich oder zwischen pushenden u. pollenden unterschiedlich ?
Edit: Und bei Norbert ist der buffer scheinbar leer.
Zitat
helper:
BUFFER
EoM -1
Danke dass sich jetzt mal jemand dem Thema annimmt. Wie ich schon geschrieben habe, habe ich im LOG Einträge stehen, womit das Modul wohl auf Fehler stößt. Kurz darauf meldet das Modul einen disconnect. Dieser bleibt auch so lange auf disconnect bis ich entweder den FHEM Server neu startet oder das Device von mal mit einem DEF aktualisiere. Ich denke auch dass das SML Paket nicht vollständig ist, oder einfach falsche Informationen liefert. Allerdings bin ich der Meinung das genau sowas das Modul abfangen sollte.
Aktuell behelfe ich mir mit einem Workaround.
Ich habe mit einen "AT" mit folgendem Inhalt angelegt:
+*00:00:10 {
my $PowerAge = ReadingsAge("myPowerMeter","power",0);
if ($PowerAge >= 130) {
if (ReadingsAge("myPowerMeter","startSML",0) >= 60) {
Log3 "watchdog",3,"myPowerMeter start SML! ReadingAage=$PowerAge";
fhem "modify myPowerMeter 10.10.2.3:23 SML";
fhem "setreading myPowerMeter startSML $PowerAge"
}
}
elsif ($PowerAge >= 65 ) {
if (ReadingsAge("myPowerMeter","startESP",0) >= 200) {
Log3 "watchdog",3,"myPowerMeter start ESP! ReadingAage=$PowerAge";
fhem "set haus.strom.esp reboot";
fhem "setreading myPowerMeter startESP $PowerAge"
}
}
}
Den Reboot für das ESP Modul könnte man sich sparen. Führe Ihn aber trotzdem vorsorglich aus. Im Februar Log habe ich bis jetzt folgende Einträge.
2020.02.01 16:27:28.275 3: myPowerMeter start ESP! ReadingAage=67
2020.02.01 16:28:38.275 3: myPowerMeter start SML! ReadingAage=137
2020.02.01 16:29:38.275 3: myPowerMeter start SML! ReadingAage=197
2020.02.01 19:40:48.275 3: myPowerMeter start ESP! ReadingAage=69
2020.02.01 19:41:58.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.01 19:42:58.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 02:50:08.275 3: myPowerMeter start ESP! ReadingAage=69
2020.02.02 02:51:18.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 02:52:18.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 13:24:28.275 3: myPowerMeter start ESP! ReadingAage=68
2020.02.02 13:25:38.275 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:27:48.275 3: myPowerMeter start ESP! ReadingAage=128
2020.02.02 13:27:58.277 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:28:58.275 3: myPowerMeter start SML! ReadingAage=198
2020.02.02 13:37:08.275 3: myPowerMeter start ESP! ReadingAage=70
2020.02.02 13:38:08.274 3: myPowerMeter start SML! ReadingAage=130
2020.02.02 13:39:08.275 3: myPowerMeter start SML! ReadingAage=190
Daran sieht man das es sehr regelmäßig auftritt.
Gruß
Michael
Disconnects sind was anderes als unvollständige Pakete.
Ich kann im Modul nicht einfach so mirnichts dirnichts ein Reconnect machen. Woher soll ich wissen, dass das (Lesekopf, USB-Wandler o.ä.) nicht willentlich abgesteckt wurde?
Das OBIS führt von sich aus keinen Disconnect aus, somit liegt das entweder an FHEM oder aus Hardware-Ebene.
Bin aber für realistische Vorschläge, wie man das abfangen kann, durchaus offen.
Zitat von: Icinger am 02 Februar 2020, 14:17:10
Disconnects sind was anderes als unvollständige Pakete.
Ich kann im Modul nicht einfach so mirnichts dirnichts ein Reconnect machen. Woher soll ich wissen, dass das (Lesekopf, USB-Wandler o.ä.) nicht willentlich abgesteckt wurde?
Das OBIS führt von sich aus keinen Disconnect aus, somit liegt das entweder an FHEM oder aus Hardware-Ebene.
Bin aber für realistische Vorschläge, wie man das abfangen kann, durchaus offen.
wie kann man feststellen warum ein disconnect geschehen ist?
Folgendes habe ich bei den Disconnects im FHEM LOG stehen:
2020.02.01 16:26:51.439 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.01 16:26:51.439 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.02.01 16:26:51.439 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.01 19:40:20.824 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.01 19:40:20.824 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.02.01 19:40:20.824 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 02:49:33.302 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 02:49:33.302 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.02.02 02:49:33.302 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:25:55.460 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 13:25:55.461 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.02.02 13:25:55.461 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:37:02.074 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 13:37:02.074 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (253)
2020.02.02 13:37:02.074 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:37:02.074 1: PERL WARNING: Use of uninitialized value $buf in unpack at ./FHEM/47_OBIS.pm line 410.
2020.02.02 13:37:02.074 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (410)
2020.02.02 13:37:02.074 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.074 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 423.
2020.02.02 13:37:02.075 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (423)
2020.02.02 13:37:02.075 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 433.
2020.02.02 13:37:02.075 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (433)
2020.02.02 13:37:02.075 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1: main::OBIS_Read called by fhem.pl (3763)
Hallo Michael,
schick' mir mal eines (oder mehrere) von den SML-Files, die den Ärger verursachen. Ich schau mir das an.
Und noch mindestens eines, das keinen Ärger gemacht hat zum Vergleich.
Gruß
Raymund
ZitatFolgendes habe ich bei den Disconnects im FHEM LOG stehen:
Diese Warnung in Zeile 253 entsteht vermutlich daraus, dass DevIo_SimpleRead keine Daten geliefert hat. Die Variable $b ist dann "leer". Füge dazu in Zeile 251 folgendes hinten an, dass es so aussieht:
my $buf = DevIo_DoSimpleRead($hash); return undef unless ($buf);Dann könnte dies schon einmal Vergangenheit sein. So steht es auch in https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung (https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung).
Gruß
Raymund
Zitat von: Raymund am 02 Februar 2020, 15:23:53
Hallo Michael,
schick' mir mal eines (oder mehrere) von den SML-Files, die den Ärger verursachen. Ich schau mir das an.
Und noch mindestens eines, das keinen Ärger gemacht hat zum Vergleich.
Gruß
Raymund
welche Files meinst du, wo finde ich die?
Zitat von: Raymund am 02 Februar 2020, 16:13:02
Dieser Fehler in Zeile 253 entsteht vermutlich daraus, dass DevIo_SimpleRead keine Daten geliefert hat. Die Variable $b ist dann "leer". Füge dazu in Zeile 251 folgendes hinten an, dass es so aussieht:
my $buf = DevIo_DoSimpleRead($hash); return undef unless ($buf);
Dann könnte dieser Fehler schon einmal Vergangenheit sein. So steht es auch in https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung (https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung).
Gruß
Raymund
Wird das noch in das offizielle Modul mit aufgenommen?
ZitatWird das noch in das offizielle Modul mit aufgenommen?
Validiere doch erst einmal, ob es das auch war. ;)
Zitat von: Raymund am 02 Februar 2020, 16:36:30
Validiere doch erst einmal, ob es das auch war. ;)
OK, mache ich
hast du diese Zeilen auch gesehen?
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 423.
2020.02.02 13:37:02.075 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (423)
2020.02.02 13:37:02.075 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 433.
2020.02.02 13:37:02.075 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (433)
2020.02.02 13:37:02.075 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1: main::OBIS_Read called by fhem.pl (3763)
Das sieht mir sehr nach einem Folgeproblem aus, weil die Sub OBIS_Parse direkt nach der Warnung aus Zeile 253 aufgerufen wird und die leere Variable $buf weitergereicht wird.
Zitatwelche Files meinst du, wo finde ich die?
Die SML-Spezifikation (z.B. hier https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml_protokoll.htm (https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml_protokoll.htm)) nennt die einzelnen "Datensätze", die die Lesegeräte ausgeben, "Files" oder eben "Dateien". So ein Datensatz fängt mit "1B 1B 1B 1B 01 01 01 01" an und hört mit "1B 1B 1B 1B 1A AF 56 FC" auf, wobei die letzten 6 Bytes eine Prüfsumme enthalten und also variabel sind. Dazwischen liegen die SML-Messages. Die Gesamtanzahl der Zeichen eines solchen Files muss übrigens durch 4 teilbar sein (ohne Rest natürlich ;) ), was schon mal ein erstes Anzeichen für seine "Validität" wäre.
Diese Files solltest Du dem Logfile von FHEM entnehmen können, wenn verbose auf 5 steht.
Guten Morgen,
jetzt tauchen im LOG neue Fehler auf:
2020.02.02 19:04:29.656 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.02 19:04:29.657 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.02.02 19:04:29.657 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.657 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.657 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.657 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.657 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.02 19:04:29.657 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.02.02 19:04:29.657 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.657 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.657 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.657 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.657 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.02 19:04:29.657 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.02.02 19:04:29.657 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.657 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.657 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.657 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.657 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.02 19:04:29.657 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.02.02 19:04:29.657 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.657 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.657 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.657 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.657 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.02 19:04:29.658 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.02.02 19:04:29.658 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.658 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.658 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.658 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.658 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.02.02 19:04:29.658 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (793)
2020.02.02 19:04:29.658 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.02 19:04:29.658 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.658 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.658 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.658 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342.
2020.02.02 19:04:29.658 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (342)
2020.02.02 19:04:29.658 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.658 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.658 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.658 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2020.02.02 19:04:29.658 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (349)
2020.02.02 19:04:29.658 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.658 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.658 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.658 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2020.02.02 19:04:29.658 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (350)
2020.02.02 19:04:29.658 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.658 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.658 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.659 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2020.02.02 19:04:29.659 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (351)
2020.02.02 19:04:29.659 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.659 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.659 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.02 19:04:29.659 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
2020.02.02 19:04:29.659 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (330)
2020.02.02 19:04:29.659 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.02 19:04:29.659 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.02 19:04:29.659 1: main::OBIS_Read called by fhem.pl (3763)
Gruß
Michael
Hi Michael,
die Perl warnings halte ich für unproblematisch, da es, wie Raymund schon schrieb, nur Folgefehler/Symptome sind.
Ein verbose=5-Log könnte helfen, warum sich in Deinem Fall das device disconnected
Zitat2020.01.22 11:19:51.247 1: 10.10.2.3:23 disconnected, waiting to reappear (myPowerMeter)
und ein modify/defmod als workaround funktioniert, nicht aber der übliche Mechanismus über die ReadyFn u. selectList.
Du kannst auch mal ein Logging in die OBIS_Ready Funktion einbauen, da dort ja eigentlich der automatische reopen über die selectlist stattfindet, wenn das device wieder verfügbar ist.
Da Du mit WLAN arbeitest, kann doch eigentlich der disconnect nur erfolgen, weil die WiFi-Verbindung nicht mehr steht. Kannst Du das nicht in einem Log Deines Access-Points nachvollziehen ?
Grüße Markus
Zitat von: KölnSolar am 03 Februar 2020, 09:25:19
Hi Michael,
die Perl warnings halte ich für unproblematisch, da es, wie Raymund schon schrieb, nur Folgefehler/Symptome sind.
Ein verbose=5-Log könnte helfen, warum sich in Deinem Fall das device disconnected und ein modify/defmod als workaround funktioniert, nicht aber der übliche Mechanismus über die ReadyFn u. selectList.
Du kannst auch mal ein Logging in die OBIS_Ready Funktion einbauen, da dort ja eigentlich der automatische reopen über die selectlist stattfindet, wenn das device wieder verfügbar ist.
Da Du mit WLAN arbeitest, kann doch eigentlich der disconnect nur erfolgen, weil die WiFi-Verbindung nicht mehr steht. Kannst Du das nicht in einem Log Deines Access-Points nachvollziehen ?
Grüße Markus
Hi Markus,
Werde mal ein Verbose 5 LOG anschalten. Hoffe dass der Fehler relativ schnell auftaucht.
Wenn Ihr mir sagt in welche Zeile ich welches LOG eintragen soll, kann ich das gerne tun. Wollte jetzt eigentlich nicht das Modul studieren und daran selber programmieren. Dafür bin ich auch zuweit von der SML Thematik weg.
Kann schon sein dass das WLAN hier ein Verursacher ist. Allerdings spricht hier die Tatsache dass ich das ESP per WLAN booten kann und die Tatsache das ein einfaches defmod/modify die Funktion wiederherstellt.
Anhand des Logs ist auch zu sehen dass das Modul innerhalb von mindestens 130 Sekunden kein Reconnect herstellt.
2020.02.01 16:28:38.275 3: myPowerMeter start SML! ReadingAage=137
2020.02.01 16:29:38.275 3: myPowerMeter start SML! ReadingAage=197
2020.02.01 19:41:58.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.01 19:42:58.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 02:51:18.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 02:52:18.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 13:25:38.275 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:27:58.277 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:28:58.275 3: myPowerMeter start SML! ReadingAage=198
2020.02.02 13:38:08.274 3: myPowerMeter start SML! ReadingAage=130
2020.02.02 13:39:08.275 3: myPowerMeter start SML! ReadingAage=190
2020.02.02 16:27:28.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 16:29:48.274 3: myPowerMeter start SML! ReadingAage=137
2020.02.02 19:00:08.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 19:04:28.274 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 19:05:28.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.03 08:18:48.275 3: myPowerMeter start SML! ReadingAage=138
ZitatWenn Ihr mir sagt in welche Zeile ich welches LOG eintragen soll, kann ich das gerne tun. Wollte jetzt eigentlich nicht das Modul studieren und daran selber programmieren.
Nana.
ZitatOBIS_Ready Funktion
wirst Du doch als Entwickler im Source-Code noch finden. Und da einfach ein
Log3 $hash,1,"OBIS - Ready Function ";hinter
my ($hash) = @_;Edit:
ZitatKann schon sein dass das WLAN hier ein Verursacher ist. Allerdings spricht hier die Tatsache dass ich das ESP per WLAN booten kann und die Tatsache das ein einfaches defmod/modify die Funktion wiederherstellt.
Ja, klar. Ich zumindest würde nach überfliegen des SourceCodes erwarten, dass die ReadyFn Dein Problem löst. Und warum es das offensichtlich nicht tut, gilt es nun herauszufinden. ;)
Edit2: Und vermutlich lässt sich der case relativ leicht provozieren, indem Du den ESP aus dem WLAN nimmst.
ZitatGuten Morgen,
jetzt tauchen im LOG neue Fehler auf:
Auch diese Warnings entstehen m.M.n, da hier "leere Daten" zum Parsen übergeben werden.
Zitat von: KölnSolar am 03 Februar 2020, 10:13:19
Nana. wirst Du doch als Entwickler im Source-Code noch finden. Und da einfach ein Log3 $hash,1,"OBIS - Ready Function ";
hinter
my ($hash) = @_;
Edit: Ja, klar. Ich zumindest würde nach überfliegen des SourceCodes erwarten, dass die ReadyFn Dein Problem löst. Und warum es das offensichtlich nicht tut, gilt es nun herauszufinden. ;)
Edit2: Und vermutlich lässt sich der case relativ leicht provozieren, indem Du den ESP aus dem WLAN nimmst.
Habe es mal eingetragen.
Ich glaube nicht das der Fehler durch das einfache nicht erreichen per WLAN kommt. Werde es aber mal testen.
Ich habe eure Tips mal umgesetzt. Die Position des Lesekopfs kontrolliert, mal verbose 5 gesetzt und als nächstes werde ich mal ein Monat altes image einspielen um zu gucken ob es an irgend einem Update gelegen hat. Und es auch mal mit Putty und einem "sudo apt-get dist-upgrade" versuchen.
Gruß
Norbert
Zitat von: micomat am 29 Januar 2020, 13:01:16
Hey,
nach Umzug auf ein neues System fehlen mir die Parameter dir_total_consumption und dir_total_feed auf beiden SML Zaehlern.
Konfiguration ist aber wie beim alten System auf dem die Parameter auch jetzt noch da sind.
Ne Idee wie ich die wieder herbekomme?
ich quaele mich immer noch mit dieser Frage und finde keine Loesung =( Keiner eine Idee?
So wie Du es beschreibst, kann man kaum eine Lösungsidee entwickeln: Deine Beschreibung: Alles ist so wie früher, aber ich habe ein Problem. Wo sollen wir dann einen Lösungsansatz finden ? ::)
Ich kann mir nur vorstellen, dass es in Deinem speziellen Fall ja irgendwie mit dem Attribut directions zu tun haben müsste, welches ich nicht nutze. Schonmal per setstate oder setreading versucht die (vermutlich) fehlenden readings anzulegen ? Vielleicht tut sich danach ja was. :-\
Moin,
ich habe eine Frage zur Nutzung des AS1440 Zählers von Elster als OBIS devce. Ich hatte das folgende im Nachbar-Thread (https://forum.fhem.de/index.php/topic,107045.msg1020665.html#msg1020665) gepostet, war dann aber von KölnSolar (https://forum.fhem.de/index.php/topic,107045.msg1020801.html#msg1020801) nach hier verwiesen worden. Vielleicht kann mir hier jemand nen Tipp geben, wie man den AS1440 zu 9600 baud überredet.
Besten Dank im Voraus!
Zitat von: alkazaa am 03 Februar 2020, 19:41:11
Hallo Marcus,
Du schriebst:Wie muss man es denn anstellen, die Baudrate auf z.B. 9600 zu erhöhen? Ich habe zwar einen Weidmann Lesekopf als OBIS device mit 300 baud am AS 1440 zum Laufen bekommen, aber ein einfaches Ersetzen von 300 durch 9600 bringt's bei mir nicht.
Hier mein device listing:
Internals:
CHANGED
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 AS1440
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1
FD 14
FUUID 5e3277ae-f33f-a50b-f3d9-4ef9d6ce4ac82511
MeterType AS1440
NAME E_Zaehler
NR 83
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
logdb:
TIME 1580754629.92682
VALUE 0.416
READINGS:
2020-02-03 19:30:28 0.0.0 4235885
2020-02-03 19:28:31 0.0.1 00!! ] a1.7.0(0.415*kW
2020-02-03 19:30:47 0.2.2 0
2020-02-03 19:30:27 0.9.1 193011
2020-02-03 19:30:28 0.9.2 200203
2020-02-03 19:30:30 1.8.0 3170.2
2020-02-03 19:30:31 1.8.1 3170.2
2020-02-03 19:30:32 1.8.2 0
2020-02-03 19:30:33 1.8.3 0
2020-02-03 19:30:33 1.8.4 0
2020-02-03 19:30:34 1.8.5 0
2020-02-03 19:30:35 1.8.6 0
2020-02-03 19:30:36 1.8.7 0
2020-02-03 19:30:37 1.8.8 0
2020-02-03 19:30:38 1.9.0 48
2020-02-03 19:28:04 2.8.0 139.5
2020-02-03 19:30:40 2.8.1 139.5
2020-02-03 19:30:41 2.8.2 0
2020-02-03 19:30:41 2.8.3 0
2020-02-03 19:30:42 2.8.4 0
2020-02-03 19:30:43 2.8.5 0
2020-02-03 19:30:44 2.8.6 0
2020-02-03 19:30:45 2.8.7 0
2020-02-03 19:30:46 2.8.8 0
2020-02-03 19:30:46 2.9.0 0.3
2020-02-03 19:28:20 Version 2!
2020-02-03 19:30:50 current_L1 2.435
2020-02-03 19:30:50 current_L2 0.478
2020-02-03 19:30:51 current_L3 0.713
2020-02-03 19:30:38 feed_L1 0
2020-02-03 19:30:29 power 0.416
2020-02-03 19:30:08 state opened
2020-02-03 19:30:48 voltage_L1 234.7
2020-02-03 19:30:48 voltage_L2 234.5
2020-02-03 19:30:49 voltage_L3 234.9
helper:
BUFFER D
EoM 0
SPEED 0
SPEED2 0
TRIGGERTIME 1580754644.99644
Channels:
DEVICES:
/2!
300
000
Attributes:
DbLogInclude power
event-on-change-reading power, 1.*, 2.*
interval 300
room HWR
Beste Grüße
Franz
Zitat von: KölnSolar am 04 Februar 2020, 08:13:59
So wie Du es beschreibst, kann man kaum eine Lösungsidee entwickeln: Deine Beschreibung: Alles ist so wie früher, aber ich habe ein Problem. Wo sollen wir dann einen Lösungsansatz finden ? ::)
Ich kann mir nur vorstellen, dass es in Deinem speziellen Fall ja irgendwie mit dem Attribut directions zu tun haben müsste, welches ich nicht nutze. Schonmal per setstate oder setreading versucht die (vermutlich) fehlenden readings anzulegen ? Vielleicht tut sich danach ja was. :-\
Wahrscheinlich habe ich durch das neue Setup eine neue Modulversion von OBIS erhalten.
Ich hatte auf der alten Installation kein attribut "directions" gesetzt, dennoch waren diese als "in" und "out" im Reading vorhanden.
Das haendische setzen dieses attributes hilft leider nicht.
Hier noch die DeviceInfos:
Internals:
DEF 192.168.178.52:2003 SML
DeviceName 192.168.178.52:2003
FD 23
FUUID 5e2de4dd-f33f-2b81-6a6f-4729341f36e7eecb
MeterType SML
NAME Zaehler_Gesamt
NR 78
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-02-05 13:06:28 1.0.0.0.9.255 09-01-45-4D-48-00-00-47-2D-DE
2020-02-05 13:06:28 129.129.199.130.3.255 EMH
2020-02-05 13:06:28 129.129.199.130.5.255 9DF3-D5EE-CACB-45ED-6FF4-922D-28B1-4974-B740-2204-7B0D-7902-FC3F-7633-4384-3116-3C2F-37B9-91C2-AEA0-5821-921A-3E56-E8C7-01
2020-02-05 13:06:28 Bezug_Gesamt 16180.7333
2020-02-05 13:06:28 Bezug_Hochtarif 9608.9254
2020-02-05 13:06:28 Bezug_Niedertarif 6571.8079
2020-02-05 13:06:28 Einspeisung 17095.9685
2020-02-05 13:06:28 Leistung 327.6
2020-02-04 00:14:59 Version EMH\0901454D480000472DDE
2020-02-05 13:01:48 dir_total_consumption 0
2020-02-05 13:02:04 dir_total_feed 0
2020-02-05 13:06:28 power 327.6
2020-02-05 13:06:28 statBezug_Gesamt Hour: 0.0406 Day: 10.1373 Month: 69.9167 Year: 154.8016 (since: 2020-01-27 )
2020-02-05 12:59:55 statBezug_GesamtLast Hour: 0.6395 Day: 22.1956 Month: 84.8849 Year: - (since: 2020-01-27 )
2020-02-05 13:06:28 statBezug_Hochtarif Hour: 0.0406 Day: 4.3854 Month: 47.4498 Year: 99.5616 (since: 2020-01-27 )
2020-02-05 12:59:55 statBezug_HochtarifLast Hour: 0.6395 Day: 17.8039 Month: 52.1118 Year: - (since: 2020-01-27 )
2020-02-05 13:06:28 statBezug_Niedertarif Hour: 0.0000 Day: 5.7519 Month: 22.4669 Year: 55.2400 (since: 2020-01-27 )
2020-02-05 12:59:55 statBezug_NiedertarifLast Hour: 0.0000 Day: 4.3917 Month: 32.7731 Year: - (since: 2020-01-27 )
2020-02-05 13:06:28 statEinspeisung Hour: 0.0000 Day: 0.0000 Month: 12.8636 Year: 43.4431 (since: 2020-01-27 )
2020-02-05 12:59:55 statEinspeisungLast Hour: 0.0000 Day: 1.0882 Month: 30.5795 Year: - (since: 2020-01-27 )
2020-02-05 13:06:28 statPowerDay Min: 231.4 Avg: 769.9 Max: 2472.0
2020-02-04 23:59:55 statPowerDayLast Min: -3398.0 Avg: 874.0 Max: 4357.1
2020-02-05 13:06:28 statPowerMonth Min: -3398.0 Avg: 520.1 Max: 4357.1
2020-01-31 23:59:55 statPowerMonthLast Min: -3612.7 Avg: 456.3 Max: 6584.4 (since: 2020-01-26_20:26:02 )
2020-02-05 13:06:28 statPowerYear Min: -3612.7 Avg: 486.2 Max: 6584.4 (since: 2020-01-26_20:26:02 )
2020-02-04 16:24:22 state opened
2020-02-05 13:06:28 total_consumption 16180733.3
2020-02-05 13:06:28 total_consumption_Ch1 9608925.4
2020-02-05 13:06:28 total_consumption_Ch2 6571807.9
2020-02-05 13:06:28 total_feed 17095968.5
2020-02-05 13:06:28 total_feed_Ch1 17095968.5
2020-02-05 13:06:28 total_feed_Ch2 0
helper:
BUFFER
EoM 1
SPEED 5
TRIGGERTIME 1580829862.51021
_98_statistics Zaehler_Statistics
Channels:
DEVICES:
30
directions:
Attributes:
icon measure_power_meter
interval 30
room Energie
userReadings Leistung:power.* {ReadingsVal("Zaehler_Gesamt","power",0)}, Einspeisung:total_feed.* {ReadingsVal("Zaehler_Gesamt","total_feed",0)/1000}, Bezug_Gesamt:total_consumption.* {ReadingsVal("Zaehler_Gesamt","total_consumption",0)/1000}, Bezug_Hochtarif:total_consumption_Ch1.* {ReadingsVal("Zaehler_Gesamt","total_consumption_Ch1",0)/1000}, Bezug_Niedertarif:total_consumption_Ch2.* {ReadingsVal("Zaehler_Gesamt","total_consumption_Ch2",0)/1000}
verbose 3
ZitatWahrscheinlich habe ich durch das neue Setup eine neue Modulversion von OBIS erhalten.
Glaub ich eher nicht. Aber Du kannst es ja prüfen...
Und vielleicht auch mal ein list von der alten Installation, denn
ZitatIch kann mir nur vorstellen, dass es in Deinem speziellen Fall ja irgendwie mit dem Attribut directions zu tun haben müsste, welches ich nicht nutze.
Hi Stefan,
weil ich directions noch nicht kannte, hab ich es mir mal etwas näher angesehen. Da scheint mir ein bug im regexp oder im Code
Zitat2020.02.05 19:59:03 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.0*255(>1324931.5*Wh)
2020.02.05 19:59:03 5: Msg 1-0:1.8.0*255(>1324931.5*Wh) is of type Counter
2020.02.05 19:59:03 4: Set total_consumption to 1324931.5
macht in $4 =255, müsste aber > sein, oder ? mit $5 kommt dann auch das reading dir_total_consumption mit value aus directions für >.
Grüße Markus
Zitat von: Raymund am 02 Februar 2020, 16:36:30
Validiere doch erst einmal, ob es das auch war. ;)
LOG Technisch sieht es bei mir jetzt besser aus. Die dubiosen disconnects sind aber leider geblieben. Was im LOG noch zu sehen ist ist folgendes:
2020.02.07 09:26:22.682 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 778.
2020.02.07 09:26:22.682 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (778)
2020.02.07 09:26:22.682 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.07 09:26:22.682 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.682 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.682 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.682 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 794.
2020.02.07 09:26:22.682 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (794)
2020.02.07 09:26:22.682 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (337)
2020.02.07 09:26:22.682 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.682 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.682 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.682 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342.
2020.02.07 09:26:22.682 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (342)
2020.02.07 09:26:22.682 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.682 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.682 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.682 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2020.02.07 09:26:22.682 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (349)
2020.02.07 09:26:22.682 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.682 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.682 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.683 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2020.02.07 09:26:22.683 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (350)
2020.02.07 09:26:22.683 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.683 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.683 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.683 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2020.02.07 09:26:22.683 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (351)
2020.02.07 09:26:22.683 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.683 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.683 1: main::OBIS_Read called by fhem.pl (3763)
2020.02.07 09:26:22.683 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
2020.02.07 09:26:22.683 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (330)
2020.02.07 09:26:22.683 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.02.07 09:26:22.683 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.02.07 09:26:22.683 1: main::OBIS_Read called by fhem.pl (3763)
Was kann ich, vor einem modify, vorher an Infos abziehen die uns eventuell bei der Fehlersuche weiterhelfen?
Zusätzliches Logging in der ReadyFn eingebaut ?
Grüße Markus
Zitat von: KölnSolar am 07 Februar 2020, 12:20:48
Zusätzliches Logging in der ReadyFn eingebaut ?
Grüße Markus
ja
#####################################
sub OBIS_Ready($)
{
my ($hash) = @_;
Log3 $hash,1,"OBIS - Ready Function ";
return DevIo_OpenDev($hash, 1, "OBIS_Init")
Ich muß mich doch noch mal melden um Hilfe und einen Rat zu bekommen. Heute nach 6 Tagen blieb OBIS wieder plötzlich stehen. Ich hatte es mit einem älteren Image probiert, auch mit Update und Upgrade, sogar mit rpi-upgrade. Kabelverbindungen und Position des Lesekopfes kontrolliert, brachte kein Erfolg. Nur ein verbose 5 kann ich nicht machen, weil ich alle 30sek eine Abfrage mache und der Fehler nur einmal in der Woche auftritt. Da würde die LOG Datei sicherlich ein bischen zu groß. Wenn das Modul stehen bleibt kann ich es mit nichts mehr "überreden" wieder zu funktionieren, weder mit get update noch mit reload 47_Obis.pm. Aber es gab diesmal in der LOG Datei nach einem reload einige Einträge, die vielleicht helfen können, das Problem zu erkennen.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Initialize redefined at ./FHEM/47_OBIS.pm line 76.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Define redefined at ./FHEM/47_OBIS.pm line 97.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Get redefined at ./FHEM/47_OBIS.pm line 171.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Set redefined at ./FHEM/47_OBIS.pm line 185.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine GetUpdate redefined at ./FHEM/47_OBIS.pm line 213.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Init redefined at ./FHEM/47_OBIS.pm line 231.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Undef redefined at ./FHEM/47_OBIS.pm line 237.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Read redefined at ./FHEM/47_OBIS.pm line 246.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_trySMLdecode redefined at ./FHEM/47_OBIS.pm line 304.
2020.02.07 12:00:55 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Parse redefined at ./FHEM/47_OBIS.pm line 408.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Ready redefined at ./FHEM/47_OBIS.pm line 587.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_Attr redefined at ./FHEM/47_OBIS.pm line 603.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_adjustAlign redefined at ./FHEM/47_OBIS.pm line 686.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_hex2int redefined at ./FHEM/47_OBIS.pm line 717.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_CRC16 redefined at ./FHEM/47_OBIS.pm line 725.
2020.02.07 12:00:55 1: PERL WARNING: Subroutine OBIS_decodeTL redefined at ./FHEM/47_OBIS.pm line 766.
2020.02.07 12:00:57 1: RMDIR: ./restoreDir/save/2020-02-04
Mit diesem LOG kann man doch sicherlich was anfangen, hoffe ich. Es wurde ja auch schon die Vermutung geäussert, das es eventuell einen Datenübertragungfehler gäb, aber dadurch darf doch das MODUL nicht unwiderruflich hängen bleiben. Es müßte eine ERROR Meldung geben und danach wieder weiter laufen, so als wenn ich den Lesekopf vom Zähler nehmen und dann wieder aufsetze. Dann läuft es ja auch weiter. Oder es müßte zumindest mit reload wieder laufen, dann könnte man vielleicht als "Krücke" alle 24 STD ein reload einbauen, oder immer wenn das Modul keine Daten mehr liefert.
Na,na mal sehen ob jemand aus den LOG-Daten was ersehen kann. Es würde mich freuen, wenn das "Teil" wieder funktionieren würde.
Gruß
Norbert
ZitatAber es gab diesmal in der LOG Datei nach einem reload einige Einträge, die vielleicht helfen können, das Problem zu erkennen.
Nein, die helfen nicht. Das sind nur Meldungen aufgrund des reloads.
Du hast per serial-USB angeschlossen, oder ?
Zitatja
Und keine entsprechenden Meldungen im Log ? Dann wird der ESP wohl disconnected u. die selectlist bekommt keinen reconnect mit.
Ich teste mal einen erzwungenen disconnect....
Ich habe diesen Schreib/Lesekopf an einen USB Port am Raspi:
Weidmann Elektronik Stromzähler, Smart Meter IR (Infrarot) Schreib/Lesekopf USB (Optokopf)
Der Ausfall als die Readings aufhörten war heute morgen:
1.0.96.50.1.255 ISK 2020-02-07 04:12:36
zu diesem Zeitpunkt werden einige FS20/HM Aktoren zur Sicherheit in die Ausgangsposition geschaltet, aber es gibt kein Hinweis auf OBIS im LOG:
2020.02.07 04:11:00 3: FS20 set Laptop off
2020.02.07 04:11:00 3: CUL_HM set Bad_EG_Schalter off
2020.02.07 04:11:00 3: CUL_HM set Werkstatt_Led off
2020.02.07 04:11:00 3: FS20 set Heizdecke_1 off
2020.02.07 04:11:00 3: FS20 set Heizdecke_2 off
2020.02.07 04:11:46 3: FS20 set URL_Werkstatt on
2020.02.07 04:16:00 3: FS20 set Laptop off
2020.02.07 04:16:00 3: CUL_HM set Bad_EG_Schalter off
2020.02.07 04:16:00 3: CUL_HM set Werkstatt_Led off
2020.02.07 04:16:00 3: FS20 set Heizdecke_1 off
2020.02.07 04:16:00 3: FS20 set Heizdecke_2 off
Hier ist bestimmt guter Rat teuer..........
Gruß
Norbert
Habs mal provoziert. Erst kein disconnected :-\ Ein modify u. dann aber das was es soll: disconnected, anstöpseln->opened, abstöpseln->disconnected, anstöpseln->opened
dmesg sieht dann in etwa so aus
[1028405.785018] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1028405.785095] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1028405.943284] usb 1-1.3.1: USB disconnect, device number 6
[1028405.943734] pl2303 ttyUSB1: pl2303_set_control_lines - failed: -19
[1028405.943753] pl2303 ttyUSB1: error sending break = -19
[1028405.944238] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
[1028405.944407] pl2303 1-1.3.1:1.0: device disconnected
[1028506.508432] ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[1028506.510582] ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[1028506.511885] ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[1028512.183070] usb 1-1.3.2: USB disconnect, device number 8
[1028512.183518] pl2303 ttyUSB3: pl2303_set_control_lines - failed: -19
[1028512.183529] pl2303 ttyUSB3: error sending break = -19
[1028512.183927] pl2303 ttyUSB3: pl2303 converter now disconnected from ttyUSB3
[1028512.184025] pl2303 1-1.3.2:1.0: device disconnected
[1028512.185004] usb 1-1.3.3: USB disconnect, device number 10
[1028512.185253] ftdi_sio ttyUSB2: error from flowcontrol urb
[1028512.185633] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
[1028512.185704] ftdi_sio 1-1.3.3:1.0: device disconnected
[1028512.284643] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg
[1028512.754611] usb 1-1.3.1: new full-speed USB device number 30 using dwc_otg
[1028512.886851] usb 1-1.3.1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[1028512.886860] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1028512.886865] usb 1-1.3.1: Product: USB-Serial Controller D
[1028512.886870] usb 1-1.3.1: Manufacturer: Prolific Technology Inc.
[1028512.888059] pl2303 1-1.3.1:1.0: pl2303 converter detected
[1028512.891831] usb 1-1.3.1: pl2303 converter now attached to ttyUSB2
[1028512.984639] usb 1-1.3.2: new full-speed USB device number 31 using dwc_otg
[1028513.117107] usb 1-1.3.2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[1028513.117117] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1028513.117122] usb 1-1.3.2: Product: USB-Serial Controller D
[1028513.117127] usb 1-1.3.2: Manufacturer: Prolific Technology Inc.
[1028513.120461] pl2303 1-1.3.2:1.0: pl2303 converter detected
[1028513.124365] usb 1-1.3.2: pl2303 converter now attached to ttyUSB4
[1028513.234625] usb 1-1.3.3: new full-speed USB device number 32 using dwc_otg
[1028513.392100] usb 1-1.3.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[1028513.392111] usb 1-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1028513.392116] usb 1-1.3.3: Product: FT232R USB UART
[1028513.392121] usb 1-1.3.3: Manufacturer: FTDI
[1028513.392126] usb 1-1.3.3: SerialNumber: A6019S96
[1028513.400009] ftdi_sio 1-1.3.3:1.0: FTDI USB Serial Device converter detected
[1028513.400124] usb 1-1.3.3: Detected FT232RL
[1028513.400847] usb 1-1.3.3: FTDI USB Serial Device converter now attached to ttyUSB5
[1028599.440253] usb 1-1.3.1: USB disconnect, device number 30
[1028599.441157] pl2303 ttyUSB2: pl2303 converter now disconnected from ttyUSB2
[1028599.441281] pl2303 1-1.3.1:1.0: device disconnected
[1028678.324958] usb 1-1.3.1: new full-speed USB device number 33 using dwc_otg
[1028678.457226] usb 1-1.3.1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[1028678.457237] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1028678.457242] usb 1-1.3.1: Product: USB-Serial Controller D
[1028678.457246] usb 1-1.3.1: Manufacturer: Prolific Technology Inc.
[1028678.458256] pl2303 1-1.3.1:1.0: pl2303 converter detected
[1028678.464495] usb 1-1.3.1: pl2303 converter now attached to ttyUSB1
[1028720.096719] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1028720.096828] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1028720.272164] usb 1-1.3.1: USB disconnect, device number 33
[1028720.272424] pl2303 ttyUSB1: pl2303_set_control_lines - failed: -19
[1028720.272436] pl2303 ttyUSB1: error sending break = -19
[1028720.272663] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
[1028720.272704] pl2303 1-1.3.1:1.0: device disconnected
[1028725.945093] usb 1-1.3.1: new full-speed USB device number 34 using dwc_otg
[1028726.077504] usb 1-1.3.1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[1028726.077519] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1028726.077529] usb 1-1.3.1: Product: USB-Serial Controller D
[1028726.077538] usb 1-1.3.1: Manufacturer: Prolific Technology Inc.
[1028726.078611] pl2303 1-1.3.1:1.0: pl2303 converter detected
[1028726.082753] usb 1-1.3.1: pl2303 converter now attached to ttyUSB1
Zitat
Weidmann Elektronik Stromzähler, Smart Meter IR (Infrarot) Schreib/Lesekopf USB (Optokopf)
Wie sieht Dein list aus ? Evtl. nicht serial-by-Id oder serial-by-path definiert ?
ZitatOder es müßte zumindest mit reload wieder laufen, dann könnte man vielleicht als "Krücke" alle 24 STD ein reload einbauen,
Nicht reload(lädt ja nur die aktuelle 47_OBIS.pm aus Deinem FHEM-Verzeichnis in den Speicher) aber defmod sollte klappen.
@Michael: Und bei Dir behaupte ich immer noch, dass das WLAN die Probleme macht(und vermutlich der "unterbrochene" Datensatz). Bei IP weiß ich nicht wie die selectlist funktioniert. Ist Dein Zähler ein pollender oder pushender ?
Das mit der Zuordnung über Path, bzw. ID hatte ich mir auch überlegt und auch probiert. OBIS blieb bei jeder Zuordnung auf disconnect, weil ich nicht ersehen konnte welcher USB genutzt wird. USB0 ist ja nicht der direkt zugeordnete USB Port wo der Lesekopf steckt, oder? Wenn doch, wo müßte dann welche Zuordnung rein. Würde ich mal probieren, bevor ich mit dauerndem Neustart anfage.
pi@raspberrypi-pi4-master:~ $ ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Feb 3 15:55 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Feb 3 15:55 usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 -> ../../ttyUSB0
pi@raspberrypi-pi4-master:~ $
und hier mein list:
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 37
FUUID 5d6a8b10-f33f-6f9b-51f5-096f290c6e0079b0
MeterType SML
NAME ISKRA_MT691
NR 1446
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-02-07 15:34:25 1.0.96.50.1.255 ISK
2020-02-07 15:34:25 Bezug 74
2020-02-07 15:34:25 Einspeisung 0
2020-02-07 15:34:25 power 74
2020-02-07 15:34:26 statTotal_consumption Hour: 21.2 Day: 4026.5 Month: 40452.5 Year: 324847.3
2020-02-07 15:34:26 statTotal_consumptionDay 4026.5
2020-02-06 23:59:55 statTotal_consumptionDayLast 2786.0
2020-02-07 15:34:26 statTotal_consumptionHour 21.2
2020-02-07 14:59:55 statTotal_consumptionHourLast 0.0
2020-02-07 14:59:55 statTotal_consumptionLast Hour: 0.0 Day: 2786.0 Month: 284394.8 Year: 11749.8 (since: 2019-12-30 )
2020-02-07 15:34:26 statTotal_consumptionMonth 40452.5
2020-01-31 23:59:55 statTotal_consumptionMonthLast 284394.8
2020-02-07 15:34:26 statTotal_consumptionYear 324847.3
2019-12-31 23:59:55 statTotal_consumptionYearLast 11749.8
2020-02-07 15:34:26 statTotal_feed Hour: 105.9 Day: 14632.5 Month: 21954.8 Year: 41136.6
2020-02-07 15:34:26 statTotal_feedDay 14632.5
2020-02-06 23:59:55 statTotal_feedDayLast 92.1
2020-02-07 15:34:26 statTotal_feedHour 105.9
2020-02-07 14:59:55 statTotal_feedHourLast 2713.0
2020-02-07 14:59:55 statTotal_feedLast Hour: 2713.0 Day: 92.1 Month: 19181.8 Year: 15.7 (since: 2019-12-31_14:55:27 )
2020-02-07 15:34:26 statTotal_feedMonth 21954.8
2020-01-31 23:59:55 statTotal_feedMonthLast 19181.8
2020-02-07 15:34:26 statTotal_feedYear 41136.6
2019-12-31 23:59:55 statTotal_feedYearLast 15.7
2020-02-07 15:00:52 state opened
2020-02-07 15:34:25 total_consumption 2128495.9
2020-02-07 15:34:25 total_feed 9605403.9
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1581084052.57229
_98_statistics myStatDevices
Channels:
DEVICES:
30
directions:
Attributes:
alias Stromzähler RNG
group Systemkontrolle
interval 30
room System
userReadings Bezug:power.* { if (ReadingsVal($name,"power",0) > 0) { ReadingsVal($name,"power",0) } else { 0 } }, Einspeisung:power.* { if (ReadingsVal($name,"power",0) <= 0) { - ReadingsVal($name,"power",0) } else { 0 } }
Gruß
Norbert
define ISKRA_MT691 OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0@9600,8,N,1 SML
und den CUL auch direkt mit
define DeinCULname CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 4711
Glaub zwar nicht, dass es hilft, aber die Definition ist schon mal sauberer.
Schon mal die disconnects "provoziert", also so wie ich mit ab-,anstöpseln des USB ?
Edit: Ist ja bestimmt ein Zähler meiner RNG-Freunde. Kriegst Du dem nicht mehr Daten entlockt(durch Pin) ?
Ja ist ein Zähler von deinen Freunden.
PIN habe ich auch eingegeben, kann auch am Zähler die Tages,Wochen,Monats und Jahresdaten abrufen, aber nicht über Optokopf.
Laut Hersteller soll das nicht gehen. Nur Zählerstände Einspeisung und Bezug, mehr nicht.
Mit dem Ein-und Ausstecken werde nachher probieren.
Muß ich den RASPI vorher neu starten, damit nicht soviel in der Datei steht?
Gruß
Nobbi
ZitatMuß ich den RASPI vorher neu starten, damit nicht soviel in der Datei steht?
Nein, brauchst Du nicht. Für die Änderung der Definitionen auch nicht.
ZitatNur Zählerstände Einspeisung und Bezug, mehr nicht.
Ich wusste warum ich den Msb gewechselt habe. ;D Wenigstens power/Phase möchte man doch haben.
Grüße Markus
Zitat von: KölnSolar am 05 Februar 2020, 19:29:23
Glaub ich eher nicht. Aber Du kannst es ja prüfen...
Und vielleicht auch mal ein list von der alten Installation, denn
Servus, danke fuer die Antwort.
Hier das List der alten Installation in der ich das Attribut ebenfalls nicht gesetzt hatte, die Readings jedoch da waren.
Internals:
DEF 192.168.178.52:2009 SML
DeviceName 192.168.178.52:2009
MeterType SML
NAME Zaehler_Gesamt
NEXT_OPEN 1581093629
NR 370
PARTIAL
STATE disconnected
TYPE OBIS
Readings:
2019-10-22 14:51:50 0.118.7.0.22.255 0
2020-01-29 12:56:56 1.0.0.0.9.255 09-01-45-4D-48-00-00-47-2D-DE
2020-01-07 03:13:26 122.119.7.129.129.255 -1e+30
2020-01-29 12:56:56 129.129.199.130.3.255 EMH
2020-01-29 12:56:56 129.129.199.130.5.255 9DF3-D5EE-CACB-45ED-6FF4-922D-28B1-4974-B740-2204-7B0D-7902-FC3F-7633-4384-3116-3C2F-37B9-91C2-AEA0-5821-921A-3E56-E8C7-01
2020-01-29 12:56:56 Bezug_Gesamt 16071.4338
2020-01-29 12:56:56 Bezug_Hochtarif 9533.8764
2020-01-29 05:59:49 Bezug_Niedertarif 6537.5574
2020-01-29 12:03:26 Einspeisung 17064.0748
2020-01-29 12:56:56 Leistung 2807.1
2020-01-26 23:58:23 Version EMH\0901454D480000472DDE
2020-01-29 12:56:56 dir_total_consumption in
2020-01-29 12:56:56 dir_total_feed in
2020-01-29 12:56:56 power 2807.1
2020-02-07 16:59:55 statBezug_Gesamt Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 564.4660
2020-02-07 16:59:55 statBezug_GesamtLast Hour: 0.0000 Day: 0.0000 Month: 564.4660 Year: 3885.7910 (since: 2019-01-05 )
2020-02-07 16:59:55 statBezug_Hochtarif Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 349.3857
2020-02-07 16:59:55 statBezug_HochtarifLast Hour: 0.0000 Day: 0.0000 Month: 349.3857 Year: 2325.6281 (since: 2019-01-05 )
2020-02-07 16:59:55 statBezug_Niedertarif Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 215.0803
2020-02-07 16:59:55 statBezug_NiedertarifLast Hour: 0.0000 Day: 0.0000 Month: 215.0803 Year: 1560.1629 (since: 2019-01-05 )
2020-02-07 16:59:55 statEinspeisung Hour: 0.0000 Day: 0.0000 Month: 0.0000 Year: 145.5842
2020-02-07 16:59:55 statEinspeisungLast Hour: 0.0000 Day: 0.0000 Month: 145.5842 Year: 4291.2339 (since: 2019-01-05 )
2020-02-07 16:59:55 statPowerDay Min: 2807.1 Avg: 2807.1 Max: 2807.1
2020-02-06 23:59:55 statPowerDayLast Min: 2807.1 Avg: 2807.1 Max: 2807.1
2020-02-07 16:59:55 statPowerMonth Min: 2807.1 Avg: 2807.1 Max: 2807.1
2020-01-31 23:59:55 statPowerMonthLast Min: -3599.5 Avg: 781.3 Max: 7738.6
2020-02-07 16:59:55 statPowerYear Min: -3599.5 Avg: 1141.7 Max: 7738.6
2019-12-31 23:59:55 statPowerYearLast Min: -3753.6 Avg: -43.0 Max: 11196.2 (since: 2019-01-04_21:01:58 )
2020-02-07 17:39:29 state disconnected
2020-01-29 12:56:56 total_consumption 16071433.8
2020-01-29 12:56:56 total_consumption_Ch1 9533876.4
2020-01-29 12:56:56 total_consumption_Ch2 6537557.4
2020-01-29 12:56:56 total_feed 17064074.8
2020-01-29 12:56:56 total_feed_Ch1 17064074.8
2020-01-29 12:56:56 total_feed_Ch2 0
Helper:
BUFFER
EoM -1
SPEED 5
TRIGGERTIME 1580299035.46488
_98_statistics Zaehler_Statistics
Channels:
DEVICES:
30
Directions:
Attributes:
event-on-change-reading .*
icon measure_power_meter
interval 30
room Energie Leider ist die commandref hier etwas unklar:
directions
Some Meters report feeding/comnsuming of power in a statusword. If this is set, you get an extra reading dir_total_consumption which defaults to "in" and "out".
Here, you can change this text with, e.g.: attr myOBIS directions {">" => "pwr consuming", "<"=>"pwr feeding"}Bedeutet das jetzt, wenn ich das Attribut setze (die Frage ist dann erst mal, auf was?), nur dann bekomme ich das Reading? Oder kann ich damit nur den angezeigten Text anapssen?
BG
Hallo Markus,
habe den Opto Kopf mehrfach aus-und eingesteckt. wurde immer wieder connected:
2020.02.07 17:48:32 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 disconnected, waiting to reappear (ISKRA_MT691)
2020.02.07 17:48:32 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.07 17:48:48 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.02.07 17:48:48 3: Init done
2020.02.07 17:48:48 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 reappeared (ISKRA_MT691)
2020.02.07 17:49:05 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 disconnected, waiting to reappear (ISKRA_MT691)
2020.02.07 17:49:25 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2020.02.07 17:49:25 3: Init done
2020.02.07 17:49:25 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 reappeared (ISKRA_MT691)
auch im LOG von FHEM.
Ich lass das System jetzt mal einfach laufen und wenn es nach ein paar Tagen hängen bleiben sollte, komme noch noch mal auf dein Vorschlag mit DEFMOD zurück.
gruß
Norbert
ZitatNur ein verbose 5 kann ich nicht machen ...
@cocojambo: dann fährst Du sicher auch in die Autowerkstatt mit Motorschaden und sagst: bitte schnell reparieren, aber die Motorhaube darf nicht geöffnet werden ;)
Setze doch als Kompromiss bitte im Obis-Modul in der Zeile 315 das Loglevel von 5 auf z.B. 3 und ergänze um ein "if" wie folgt:
Log3 $hash,3,"SML-Parse $1" if (length($1) % 4);Danach ein Reload oder Neustart. Damit werden zunächst mal nur die Files geloggt, deren Länge nicht durch 4 teilbar ist, die also definitiv "kaputt" sind. Vielleicht komme ich ja so doch noch an ein SML-File zum Zeitpunkt des "Aufhängens" und kann mal checken, was da so durchläuft oder eben nicht ::)
Wer keine Angst vor großen Logfiles hat, sollte die if-Klausel weglassen. Mir reichen die Einträge vor dem "Hängenbleiben".
ZitatBedeutet das jetzt, wenn ich das Attribut setze (die Frage ist dann erst mal, auf was?), nur dann bekomme ich das Reading? Oder kann ich damit nur den angezeigten Text anapssen?
Ich behaupte nur dann bekommst Du die readings(frag mich nicht, warum es vorher ohne ging).
attr Zaehler_Gesamt {">" => "in", "<"=>"out"}
Hast Du da vielleicht den Attributnamen "directions" vergessen, etwa so?
attr Zaehler_Gesamt directions {">" => "in", "<"=>"out"}
Ich habe mal ein bisschen im Code gestöbert. Die Readings sollten auch ohne dieses Attribut kommen. Siehe die Zeilen 427ff.
ZitatHast Du da vielleicht den Attributnamen "directions" vergessen, etwa so?
:-[ wenn man "schnell" noch etwas posten will. ::)
ZitatDie Readings sollten auch ohne dieses Attribut kommen.
Meine Tests widersprechen. ;) Kann aber auch hieran gelegen haben.
Zitat von: KölnSolar am 05 Februar 2020, 22:35:27
Hi Stefan,
weil ich directions noch nicht kannte, hab ich es mir mal etwas näher angesehen. Da scheint mir ein bug im regexp oder im Code
2020.02.05 19:59:03 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.0*255(>1324931.5*Wh)
2020.02.05 19:59:03 5: Msg 1-0:1.8.0*255(>1324931.5*Wh) is of type Counter
2020.02.05 19:59:03 4: Set total_consumption to 1324931.5macht in $4 =255, müsste aber > sein, oder ? mit $5 kommt dann auch das reading dir_total_consumption mit value aus directions für >.
Grüße Markus
@micomat: ein verbose5_Log(so wie meine 3 Zeilen) könnte uns ggfs etwas erhellen. ::)
Schönes Wochenende
@KölnSolar
Das mit dem Auto ist wirklich ein an den Haaren herbeigezogener Vergleich. Unser Raspi hängt am LAN, was gleichzusetzen wäre mit der OBD Buchse des KFZ.
Und wenn ich da ein Steuergerät veranlassen würde große Datenmengen im Speicher zu loggen, würde das Auto irgendwann stehen bleiben, sowie der Raspi mit großen Datenmengen auch.
Aber mal zurück zum eigendlichen Problem.
Ich mache mal deine Änderung im OBIS Modul und gucke ich mal was passiert, wenn das Teil mal wieder keine Lust hat.
Gruß
Norbert
Ergänzung:
Habe die Änderung gerade eingefügt, steht aber bei mir in Zeile 324.
Okay, Attribut gesetzt, leider ohne Erfolg.
Hier das Verbose Log:
2020.02.08 12:21:18 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.02.08 14:13:40 1: RMDIR: ./restoreDir/save/2020-02-04
2020.02.08 14:15:18 5: SW:
2020.02.08 14:15:18 4: Wrote
2020.02.08 14:15:18 5: OBIS (Zaehler_Gesamt) - Internal timer set to 2020-02-08 14:15:48
2020.02.08 14:15:19 5: SML-Parse 1B1B1B1B01010101760700160379E3486200620072630101760101070016079FA1180B0901454D480000472DDE0101637B5D00760700160379E349620062007263070177010B0901454D480000472DDE070100620AFFFF72620165079F42917A77078181C78203FF0101010104454D480177070100000009FF010101010B0901454D480000472DDE0177070100010800FF640101A201621E52FF560009AE53560177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Full message-> 1B1B1B1B01010101760700160379E3486200620072630101760101070016079FA1180B0901454D480000472DDE0101637B5D00760700160379E349620062007263070177010B0901454D480000472DDE070100620AFFFF72620165079F42917A77078181C78203FF0101010104454D480177070100000009FF010101010B0901454D480000472DDE0177070100010800FF640101A201621E52FF560009AE53560177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=1B1B1B1B01010101760700160379E3486200620072630101760101070016079FA1180B0901454D480000472DDE0101637B5D00760700160379E349620062007263070177010B0901454D480000472DDE070100620AFFFF72620165079F42917A77078181C78203FF0101010104454D480177070100000009FF010101010B0901454D480000472DDE0177070100010800FF640101A201621E52FF560009AE53560177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100000009FF010101010B0901454D480000472DDE0177070100010800FF640101A201621E52FF560009AE53560177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100010800FF640101A201621E52FF560009AE53560177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100020800FF640101A201621E52FF56000A35431E0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100010801FF0101621E52FF560005BF35370177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100020801FF0101621E52FF56000A35431E0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100010802FF0101621E52FF560003EF1E1F0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100020802FF0101621E52FF5600000000000177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177070100100700FF0101621B52FF55FFFFC57D0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 5: OBIS: Telegram=0177078181C78205FF0172620165079F4292010183029DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C70101016304DF00760700160379E34A6200620072630201710163D6AC00001B1B1B1B1A01830B
2020.02.08 14:15:19 4: MSG IS:
/EMH\0901454D480000472DDE
129-129:199.130.3*255(EMH)
1-0:0.0.9*255(0901454D480000472DDE)
1-0:1.8.0*255(<16241954.2*Wh)
1-0:2.8.0*255(<17126275*Wh)
1-0:1.8.1*255(9641707.9*Wh)
1-0:2.8.1*255(17126275*Wh)
1-0:1.8.2*255(6600246.3*Wh)
1-0:2.8.2*255(0*Wh)
1-0:16.7.0*255(-1497.9*W)
129-129:199.130.5*255(9DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C701)
!
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: /EMH\0901454D480000472DDE
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 129-129:199.130.3*255(EMH)
2020.02.08 14:15:19 5: Msg 129-129:199.130.3*255(EMH) is of type ManufID
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:0.0.9*255(0901454D480000472DDE)
2020.02.08 14:15:19 5: Msg 1-0:0.0.9*255(0901454D480000472DDE) is of type Serial
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:1.8.0*255(<16241954.2*Wh)
2020.02.08 14:15:19 5: Msg 1-0:1.8.0*255(<16241954.2*Wh) is of type Counter
2020.02.08 14:15:19 4: Set total_consumption to 16241954.2
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:2.8.0*255(<17126275*Wh)
2020.02.08 14:15:19 5: Msg 1-0:2.8.0*255(<17126275*Wh) is of type Counter
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:1.8.1*255(9641707.9*Wh)
2020.02.08 14:15:19 5: Msg 1-0:1.8.1*255(9641707.9*Wh) is of type Counter
2020.02.08 14:15:19 4: Set total_consumption_Ch1 to 9641707.9
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:2.8.1*255(17126275*Wh)
2020.02.08 14:15:19 5: Msg 1-0:2.8.1*255(17126275*Wh) is of type Counter
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:1.8.2*255(6600246.3*Wh)
2020.02.08 14:15:19 5: Msg 1-0:1.8.2*255(6600246.3*Wh) is of type Counter
2020.02.08 14:15:19 4: Set total_consumption_Ch2 to 6600246.3
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:2.8.2*255(0*Wh)
2020.02.08 14:15:19 5: Msg 1-0:2.8.2*255(0*Wh) is of type Counter
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 1-0:16.7.0*255(-1497.9*W)
2020.02.08 14:15:19 5: Msg 1-0:16.7.0*255(-1497.9*W) is of type Channels
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: 129-129:199.130.5*255(9DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C701)
2020.02.08 14:15:19 5: Msg 129-129:199.130.5*255(9DF3D5EECACB45ED6FF4922D28B14974B74022047B0D7902FC3F7633438431163C2F37B991C2AEA05821921A3E56E8C701) is of type PublicKey
2020.02.08 14:15:19 5: OBIS (Zaehler_Gesamt) - Msg-Parse: !
Folgender Log Eintrag ist mir heute noch aufgefallen:
2020.02.08 12:21:18 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
Danke euch :)
Zitat@KölnSolar
Das mit dem Auto ....
Ich ? :o
ZitatOkay, Attribut gesetzt, leider ohne Erfolg.
Ok. Du hast einen EMH, wie ich, also
Zitatmacht in $4 =255, müsste aber > sein, oder ? mit $5 kommt dann auch das reading dir_total_consumption mit value aus directions für >.
Such mal im SourceCode(ungefähr Zeile 510)
readingsBulkUpdate($hash, "dir_$L",$hash->{helper}{directions}{$4} // $dir{$4}) if (length $4);die $4 jeweils durch $5 ersetzen, speichern, ein reload 47_OBIS in FHEM und dann solltest Du glücklich sein. ;)
@KölnSolar
nein nicht du, war falscher Fehler, war eigendlich für =>
@ Raymund
Das mit dem Auto ist wirklich ein an den Haaren herbeigezogener Vergleich. Unser Raspi hängt am LAN, was gleichzusetzen wäre mit der OBD Buchse des KFZ.
Und wenn ich da ein Steuergerät veranlassen würde große Datenmengen im Speicher zu loggen, würde das Auto irgendwann stehen bleiben, sowie der Raspi mit großen Datenmengen auch.
Gruß
Norbert
ZitatUnser Raspi hängt am LAN, was gleichzusetzen wäre mit der OBD Buchse des KFZ.
@cocojambo: jetzt verstehe ich Deinen OBD-Vergleich nicht wirklich. Es geht mir lediglich darum, ein paar Zeilen des Obis-Moduls zu loggen und sonst nichts. Und wenn man "Speicher"-Probleme befürchtet, kann man ja einen USB-Stick dranhängen. Da Glaskugeln ja nicht mehr so en vogue sind, bleiben eben nur die Logfiles zum Zeitpunkt kurz vor dem "Abgang" als Analysemöglichkeit.
Ich hätte ja auch nichts dagegen, wenn der Maintainer sich der Sache annimmt. Ich habe da null Ehrgeiz ;)
@Raimund
Du mußt ja nicht gleich beleidigt sein, nur weil ich bedenken habe das FHEM hängen bleibt. Das ist mir schon mal bei einem verbose 5 passiert.
Da bin ich echt in Schwierigkeiten gekommen. Ich weiß nicht, und habe es auch noch nicht probiert, wie groß die LOG Datei wird, wenn ich OBIS alle 30 sek und das 7 Tage mit verbose 5 logge.
Das mit USB Stick ist ein guter Vorschlag, den ich wenn es so nicht klappt, gerne aufgreifen werde.
Nix für ungut von mir "aus Kölle vum Rhing"
Gruß
Norbert
3 Kölner u. OBIS. ;D ;D ;D
Zitat von: KölnSolar am 08 Februar 2020, 14:27:04
Ich ? :o
Ok. Du hast einen EMH, wie ich, alsoSuch mal im SourceCode(ungefähr Zeile 510)
readingsBulkUpdate($hash, "dir_$L",$hash->{helper}{directions}{$4} // $dir{$4}) if (length $4);
die $4 jeweils durch $5 ersetzen, speichern, ein reload 47_OBIS in FHEM und dann solltest Du glücklich sein. ;)
Vielen Dank :) Readings sind wieder da!
Wie schon vorher geschrieben habe ich einen "AT" laufen der alle 10 Sekunden schaut wie alt das Power Reading ist. Wie in dem LOG unten zu sehen ist wurde festgestellt, dass das Reading 68 Sekunden alt ist. Da es schon so alt ist starte ich einmal das ESPEasy Modul per WLAN neu. Da der Reboot auch erfolgt ist das ESPEasy auch noch erreichbar. Leider baut das OBIS Modul keine erneute Verbindung auf. Daher wird ein eine "DEFMOD" ausgeführt nachdem festgestellt wurde dass das Reading 138 Sekunden alt ist. direkt danach besteht auch wieder eine Verbindung.
Hier mal mein LOG Auszug. Eventuell fällt jemanden auf warum die Verbindung auf einmal nicht mehr funktioniert.
2020.02.09 16:48:15.311 3: myPowerMeter start ESP! ReadingAage=68
2020.02.09 16:48:15.311 3: list myPowerMeter : Internals:
CRC_Errors 18
DEF 10.10.2.3:23 SML
DeviceName 10.10.2.3:23
FD 9
FUUID 5e0e2359-f33f-e2f1-f8de-52197c2a429c54f0
MeterType SML
NAME myPowerMeter
NR 265
PARTIAL
STATE 3854 kWh / 405 W / opened
TYPE OBIS
.attraggr:
.attreocr:
.*
.attrminint:
Helper:
DBLOG:
power:
fhem.dblog:
TIME 1581263227.24477
VALUE 405
total_consumption:
fhem.dblog:
TIME 1581263227.24477
VALUE 3854105.4
READINGS:
2020-01-04 21:54:10 0.118.5.5.145.255 0
2020-02-09 16:47:07 1.0.96.50.1.255 ISK
2020-02-09 16:47:07 power 405
2020-01-14 15:39:44 price 0.2711
2020-02-09 08:48:55 startESP 68
2020-02-07 10:58:31 startList 53
2020-02-09 08:50:05 startSML 138
2020-02-09 16:47:07 statPowerDay Min: 340 Avg: 426 Max: 1006
2020-02-08 23:59:55 statPowerDayLast Min: 337 Avg: 439 Max: 1639
2020-02-09 16:47:07 statPowerMonth Min: 331 Avg: 697 Max: 8555
2020-01-31 23:59:55 statPowerMonthLast Min: 341 Avg: 817 Max: 7637 (since: 2020-01-14_13:59:52 )
2020-02-09 16:47:07 statPowerYear Min: 331 Avg: 777 Max: 8555 (since: 2020-01-14_13:59:52 )
2020-01-02 23:01:09 statStateDay opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateMonth opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateYear opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-02-09 16:47:07 statTotal_consumption Hour: 324.8 Day: 7164.3 Month: 145560.9 Year: 673105.4 (since: 2020-01-03 )
2020-02-09 16:47:07 statTotal_consumptionDay 7164.3
2020-02-08 23:59:55 statTotal_consumptionDayLast 10566.6
2020-01-14 20:44:27 statTotal_consumptionDayLastPrice 0.2711
2020-01-14 20:43:02 statTotal_consumptionDayPrice 0.2711
2020-02-09 16:47:07 statTotal_consumptionHour 324.8
2020-02-09 15:59:55 statTotal_consumptionHourLast 456.6
2020-02-09 15:59:55 statTotal_consumptionLast Hour: 456.6 Day: 10566.6 Month: 527544.5 Year: 19000 (since: 2020-01-03 )
2020-02-09 16:47:07 statTotal_consumptionMonth 145560.9
2020-01-31 23:59:55 statTotal_consumptionMonthLast 527544.5
2020-01-14 20:43:12 statTotal_consumptionMonthPrice 0.2711
2020-02-09 16:47:07 statTotal_consumptionYear 673105.4
2020-01-14 20:43:34 statTotal_consumptionYearPrice 0.2711
2020-02-09 08:50:05 state opened
2020-02-09 16:47:07 total_consumption 3854105.4
2020-01-14 20:43:47 total_consumptionPrice 0.2711
2020-01-14 22:13:20 watchdog 0
helper:
BUFFER
EoM -1
SPEED 5
TRIGGERTIME 1581234605.31214
_98_statistics haus.strom
Channels:
DEVICES:
60
directions:
Attributes:
alias Stromzähler
event-on-change-reading .*
interval 60
room ZZ_Strom
stateFormat {sprintf("%.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " / ". sprintf("%.0f W", ReadingsVal($name,"power",0)). " / ".ReadingsVal($name,"state",0)}
2020.02.09 16:48:15.312 3: ESPEasy haus.strom.esp: set haus.strom.esp reboot
2020.02.09 16:48:59.104 3: HMUARTLGW HNMWHWG001: connect to http://10.10.0.181:23 timed out, retrying in 60.00s
2020.02.09 16:49:25.311 3: myPowerMeter start SML! ReadingAage=138
2020.02.09 16:49:25.312 3: list myPowerMeter : Internals:
CHANGED
CRC_Errors 18
DEF 10.10.2.3:23 SML
DeviceName 10.10.2.3:23
FD 9
FUUID 5e0e2359-f33f-e2f1-f8de-52197c2a429c54f0
MeterType SML
NAME myPowerMeter
NR 265
PARTIAL
STATE 3854 kWh / 405 W / opened
TYPE OBIS
.attraggr:
.attreocr:
.*
.attrminint:
Helper:
DBLOG:
power:
fhem.dblog:
TIME 1581263227.24477
VALUE 405
total_consumption:
fhem.dblog:
TIME 1581263227.24477
VALUE 3854105.4
READINGS:
2020-01-04 21:54:10 0.118.5.5.145.255 0
2020-02-09 16:47:07 1.0.96.50.1.255 ISK
2020-02-09 16:47:07 power 405
2020-01-14 15:39:44 price 0.2711
2020-02-09 16:48:15 startESP 68
2020-02-07 10:58:31 startList 53
2020-02-09 08:50:05 startSML 138
2020-02-09 16:47:07 statPowerDay Min: 340 Avg: 426 Max: 1006
2020-02-08 23:59:55 statPowerDayLast Min: 337 Avg: 439 Max: 1639
2020-02-09 16:47:07 statPowerMonth Min: 331 Avg: 697 Max: 8555
2020-01-31 23:59:55 statPowerMonthLast Min: 341 Avg: 817 Max: 7637 (since: 2020-01-14_13:59:52 )
2020-02-09 16:47:07 statPowerYear Min: 331 Avg: 777 Max: 8555 (since: 2020-01-14_13:59:52 )
2020-01-02 23:01:09 statStateDay opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateMonth opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-01-02 23:01:09 statStateYear opened: 00:00:00 opened_Count: 1 (since: 2020-01-02_23:01:09)
2020-02-09 16:47:07 statTotal_consumption Hour: 324.8 Day: 7164.3 Month: 145560.9 Year: 673105.4 (since: 2020-01-03 )
2020-02-09 16:47:07 statTotal_consumptionDay 7164.3
2020-02-08 23:59:55 statTotal_consumptionDayLast 10566.6
2020-01-14 20:44:27 statTotal_consumptionDayLastPrice 0.2711
2020-01-14 20:43:02 statTotal_consumptionDayPrice 0.2711
2020-02-09 16:47:07 statTotal_consumptionHour 324.8
2020-02-09 15:59:55 statTotal_consumptionHourLast 456.6
2020-02-09 15:59:55 statTotal_consumptionLast Hour: 456.6 Day: 10566.6 Month: 527544.5 Year: 19000 (since: 2020-01-03 )
2020-02-09 16:47:07 statTotal_consumptionMonth 145560.9
2020-01-31 23:59:55 statTotal_consumptionMonthLast 527544.5
2020-01-14 20:43:12 statTotal_consumptionMonthPrice 0.2711
2020-02-09 16:47:07 statTotal_consumptionYear 673105.4
2020-01-14 20:43:34 statTotal_consumptionYearPrice 0.2711
2020-02-09 08:50:05 state opened
2020-02-09 16:47:07 total_consumption 3854105.4
2020-01-14 20:43:47 total_consumptionPrice 0.2711
2020-01-14 22:13:20 watchdog 0
helper:
BUFFER
EoM -1
SPEED 5
TRIGGERTIME 1581234605.31214
_98_statistics haus.strom
Channels:
DEVICES:
60
directions:
Attributes:
alias Stromzähler
event-on-change-reading .*
interval 60
room ZZ_Strom
stateFormat {sprintf("%.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " / ". sprintf("%.0f W", ReadingsVal($name,"power",0)). " / ".ReadingsVal($name,"state",0)}
2020.02.09 16:49:25.312 3: Opening myPowerMeter device 10.10.2.3:23
2020.02.09 16:49:25.506 3: Init done
2020.02.09 16:49:25.506 3: myPowerMeter device opened
Hallo,
ich habe seit kurzen aufgrund einer Photovoltaikanlage Smartmeters von Bayernwerk bekommen. Diese sind Holley DTZ541 welche wohl SML sprechen, aber nicht ganz....
Scheinbar ist dieses Problem beim Volkszähler bekannt und gefixt: https://github.com/volkszaehler/libsml/issues/75 bzw. https://github.com/Apollon77/ioBroker.smartmeter/issues/34
Da ich den Volkszähler aber auch nicht richtig zum laufen kriege und ich eigentlich eh kein zweites System möchte und ich leider gar keine Ahnung vom Programmieren und noch weniger von Perl habe, meine Frage:
Kann mir und vermutlich vielen im Süden Deutschlands(welche wohl bald alle Holley´s besitzen) helfen und dieses wunderbare Modul um eben diesen Zähler erweitern?
Kommunikation mit dem SmartMeter an sich scheint zu gehen:
Internals:
CFGFN
CRC_Errors 3
DEF /dev/ttyUSB0@@9600,8,N,1
DeviceName /dev/ttyUSB0@@9600,8,N,1
FD 7
FUUID 5e59395f-f33f-e182-39bb-c2b3f456e66dc78b
MeterType SML
NAME myPowerMeter
NR 18
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-02-28 17:39:31 1.0.0.2.0.255 1.02.007
2020-02-28 17:39:31 1.0.96.5.0.255 1841412
2020-02-28 17:39:31 1.0.96.50.1.255 HLY
2020-02-28 17:39:31 1.0.96.90.2.255 A01A
2020-02-28 16:01:35 state opened
2020-02-28 17:39:31 total_consumption 1999534
2020-02-28 17:39:31 total_feed 158423.1
helper:
BUFFER
EoM 0
SPEED
SPEED2
TRIGGERTIME 1582905695.88716
Channels:
DEVICES:
-1
directions:
Attributes:
room SMARTMETER
Vielen Dank
Grüße
Roland
Hallo Roland,
ich hab unter dem Link nichts gesehen, was ein Problem machen sollte und Du hast doch readings.
Was ist also Deine Erwartung, die nicht erfüllt ist ?
Grüße Markus
Servus Markus,
ich denke es sollten ein paar mehr readings sein. Und CRC errors sind vermutlich auch nicht richtig.
Ich vermisse mindestens die Readings 2.8.0 und 1.8.0! Die will ich ja mindestens sehen!
Oder muss ich mir die selbst irgendwie zusammenbasteln.
Im Volkszähler hatte ich eben auch so ein Problem, da ich eine zu alte Version installiert habe... nach update kamen alle Werte rein!
Allerdings nicht wirklich stabil und nachvollziehbar... Mal kamen Werte für ein paar Minuten rein, mal nicht...
Ich dachte mir, das Problem liegt laut github.com/volkszaehler/libsml/issues/75 3.Post bei:
there are several crc algorithms known as crc-16/ccitt.
SML uses
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e residue=0xf0b8 name="CRC-16/IBM-SDLC"
But Holleys DTZ541 uses
width=16 poly=0x1021 init=0x0000 refin=true refout=true xorout=0x0000 check=0x2189 residue=0x0000 name="CRC-16/KERMIT"
Where:
after the first message is parsed, the crc is calculated. At this point i could try another algo and set it for future usage. That could be a solution, yes.
I can only read the manufacturer, but i think making a decision on that is too broad. Perhaps they have some correct working meters.
Mercie
OMG....
Kommando zurück... Ich war so überzeugt, dass mein Zähler nicht geht, dass ich total_consumption und total_feed völlig ignoriert habe, weil die Zahlen so irrwitzig groß sind :o
Derweil sind das Watt und genau das was ich sehen will.
Sorry :-[
Bin begeistert!! DANKE
Hallo zusammen,
ich habe seit kurzem einen Easymeter Q3A V10.04. Daraufhin habe ich mir einen IR USB Schreib-/Lesekopf bei ebay geholt (bei Volkszähler gibt's gerade keine fertigen). Den habe ich angestöpselt, OBIS Modul eingerichtet - geht wunderbar.
Jetzt habe ich eben einen Cat 6 Hutschienenmodul und eine Hutschienensteckdose in meinem Zählerschrank gebaut und meinen NUC (darauf läuft mein fhem unter Ubuntu Server 16.04) in den Zählerschrank verfrachtet.
Nun habe ich festgestellt, daß fhem nach einem reboot nicht mehr hochkommt, wenn der USB Kopf angeschlossen ist. Ich muß den abziehen, NUC neu starten, den IR Kopf wieder anstecken und dann im meinem OBIS Device "Strom" die Def einmal ändern, dann gibts wieder Daten.
Wenn man zuhause ist, ist das soweit ok, aber wenn ich mal nicht zuhause bin und "remote support" leisten muß, steht mein fhem, wenn ich vielleicht mal remote rebooten muß.
Das würde den mühsam erarbeiteten WAF möglichweise unter die Toleranzschwelle drücken. Und auf die aktuellen Verbrauchsdaten würde ich auch ungern wieder verzichten wollen.
Hat jemand eine Idee, wo es klemmen könnte und wie man das handeln kann?
Ein list meines OBIS Device hänge ich mal mit dran, aber die Ursache vermute ich eher nicht dort.
Internals:
CRC_Errors 1
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 92
FUUID 5e6cbb0a-f33f-af18-f81d-b28bdf1ed604db32
MeterType SML
NAME Strom
NR 1057
PARTIAL
STATE Momentanverbrauch:1297.3 W/h,Gesamtverbrauch:484.313 kW/h
TYPE OBIS
Helper:
DBLOG:
power:
myDbLog:
TIME 1584294343.32964
VALUE 1073.83
power_L1:
myDbLog:
TIME 1584294343.32964
VALUE 748.95
power_L2:
myDbLog:
TIME 1584294343.32964
VALUE 288.39
power_L3:
myDbLog:
TIME 1584294343.32964
VALUE 36.48
READINGS:
2020-03-15 18:46:05 1.0.0.0.0.255 xx-xx-xx-.......
2020-03-15 18:46:05 1.0.0.0.9.255 xx-xx-xx-.......
2020-03-14 14:15:49 1.0.36.7.0.255 485.64
2020-03-14 14:15:49 1.0.56.7.0.255 183.03
2020-03-14 14:15:49 1.0.76.7.0.255 212.63
2020-03-15 13:18:43 125.119.7.129.129.255 808.1
2020-03-15 18:46:05 129.129.199.130.3.255 ESY
2020-03-15 18:46:05 129.129.199.130.5.255 xxxx-xxxx-xxxx-..................
2020-03-15 18:46:05 KW 484.313 kW/h
2020-03-15 17:53:35 Version ESY\09014553591103AA643D\3145535931313631343938343239
2020-03-15 18:46:05 power 1297.3
2020-03-15 18:46:05 power_L1 975.39
2020-03-15 18:46:05 power_L2 285.38
2020-03-15 18:46:05 power_L3 36.51
2020-03-15 18:46:05 statPowerDay Min: 447.15 Avg: 1145.40 Max: 7506.53
2020-03-14 23:59:55 statPowerDayLast Min: 535.58 Avg: 924.07 Max: 3297.71 (since: 2020-03-14_19:05:11 )
2020-03-15 18:46:05 statPowerMonth Min: 447.15 Avg: 1099.46 Max: 7506.53 (since: 2020-03-14_19:05:11 )
2020-03-15 18:46:05 statPowerYear Min: 447.15 Avg: 1099.44 Max: 7506.53 (since: 2020-03-14_19:05:11 )
2020-03-15 18:27:33 state opened
2020-03-15 18:46:05 total_consumption 484313.3566
2020-03-15 18:46:05 voltage_L1 230.3
2020-03-15 18:46:05 voltage_L2 226.7
2020-03-15 18:46:05 voltage_L3 230.9
helper:
BUFFER v ESYAd=\KbbrcvESYESY��K ESY�d=cуv ESYAd=\K bbrcw ESY�d=b
��rbe ��}w��ǂ�ESYw � ESY�d=w�d�b R�Y �hVw�bR�Y�Xw$�bR�Yt�w8�bR�YoOwL�bR�Y4w��ǂ���Nc=�x�!��^
EoM 0
SPEED 5
SPEED2 5
TRIGGERTIME 1584293253.92494
_98_statistics Statistic
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
1.0.96.5.0.255 ZRZ_Status
1.0.96.50.1.255 Hersteller
DEVICES:
-1
directions:
Attributes:
DbLogInclude power.*
alias Strom
channels {"1.0.96.5.0.255"=>"ZRZ_Status","1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
event-min-interval power.*:60,statP.*:600
group IOs
icon measure_power_meter
pollingMode on
room Strom,Technikraum
stateFormat Momentanverbrauch:power W/h,Gesamtverbrauch:KW
userReadings KW {sprintf("%.3f kW/h",ReadingsVal($name,"total_consumption",0)/1000)}
Der Inhalt von Buffer scheinen noch nicht decodierte Rohdaten zu sein, so ähnlich sieht es aus, wenn man mit "cat /dev/ttyUSB0" nachschaut, ob überhaupt was ankommt.
Gruß Roland
@Raymund
Das Obis Modul ist zwischenzeitlich wieder ein paar mal hängengeblieben, heute z.B. um 08:04:52 Uhr.
Ich hatte ja auf deinen Rat hin diese Zeile im Modul geändert um eine Fehlermeldung im LOG zu erhalten:
ZitatLog3 $hash,3,"SML-Parse $1" if (length($1) % 4);
Zu diesen Zeitpunkten ist eine Fehlermeldung im LOG aufgetaucht auch kein anderes Event. Auch ein reload bringt das Modul nicht mehr zum Laufen. Es bleibt scheinbar einfach hängen. Nur ein shutdown reload startet es wieder und es läuft dann wieder mal ein Tag und zuletzt sogar 5 Tage.
Was kann ich machen, das man dahinter kommt, was diesen Fehler verursacht?
Schönen Gruß aus Köln
Norbert
Hi Norbert,
ZitatAuch ein reload bringt das Modul nicht mehr zum Laufen.
Kann ja auch nicht. Das Verhalten bei einem modify bzw. defmod wäre interessant(zumindest gäbe es dann evtl. den workaround den Michael macht)
Grüße Markus
Ich weiß Markus, hasst du mir schon mal ein paar Posts vorher gesagt.
Vielleicht sollte ich das wirklich mit DEFMOD machen. Ich müßte dann nur den Zeitpunkt feststellen an dem das Modul steht, um es dann neu zu starten, weil das Modul ja im Fehlerfall immer noch den State "opend" meldet und keine Error Meldung rauswirft.
Ich habe jetzt mal verbose 5 gesetzt um mal zu gucken ob dann was im LOG steht.
Gruß
Nobbi
..das kannst du z.b. mit einen Timer mit 60sec. abfangen:
my $d3 = ReadingsAge("Stromzaehler","power",0);
if ($d3 >= 60) {fhem ("defmod Stromzaehler OBIS 192.168.2.61:23");;};
Grüsse Christian
Hallo Christian,
danke für deinen Tip mit dem "automatischen" defmod. Ich werde das auf jeden Fall probieren, wenn ich durch verbose 5 nicht dahinter komme warum das Modul plötzlich unverhofft stehen bleibt. Oder es keinen Hinweis im LOG dazu gibt.
Gruß
Norbert
Zitat von: cocojambo am 22 März 2020, 16:32:16
Hallo Christian,
danke für deinen Tip mit dem "automatischen" defmod. Ich werde das auf jeden Fall probieren, wenn ich durch verbose 5 nicht dahinter komme warum das Modul plötzlich unverhofft stehen bleibt. Oder es keinen Hinweis im LOG dazu gibt.
Gruß
Norbert
Ich habe aufgegeben den Fehler zu suchen. Bei mir scheint es so zu sein, das sporadisch die SML Message nicht vollständig übertragen wird. Dann bleibt das Modul einfach stehen bzw. geht irgendwann auf disconnect. Beide Fälle führen aber dazu, dass ein manueller Eingriff erfolgen muss damit das Modul wieder arbeitet.
Mein aktueller Workaround arbeitet jetzt seit mehreren Wochen erfolgreich.
Da sich hier keine Entwickler dazu gemeldet hat, glaube ich nicht, dass in naher Zukunft sich hier was ändern wird.
Gruß
Michael
Hat eigentlich jemand eine Idee gehabt zu meinem Problem in Beitrag 883 (https://forum.fhem.de/index.php/topic,51948.msg1032007.html#msg1032007)?
Vielleicht hätte ich auch ein neues Thema aufmachen sollen, ist wahrscheinlich eher ein Unix-Problem, will aber jetzt kein Doppel-Posting machen.
Gruß Roland
Hi Roland,
ZitatNun habe ich festgestellt, daß fhem nach einem reboot nicht mehr hochkommt, wenn der USB Kopf angeschlossen ist.
Da Du schon selber vermutetest, dass es nicht direkt mit dem Modul zu tun hat, würde ein Log mit verbose=5 helfen, um zu sehen wo es hängt. ::)
Ich könnt mir z.B. usbcreate als Übeltäter vorstellen...
Grüße Markus
Danke für den Ansatz, Markus.
Gruß Roland
Hallo,
seit dem Zählertausch bekomme ich keine Daten mehr. Es ist ein Digimeto EFR SGM-DD-4A92T .
https://digimeto.de/wps/wcm/connect/digimeto/a7c0814f-550e-4387-9a73-69bd36a7296c/DIGImeto_efr_SGM-DD_Bedienungsanleitung_lang_Web.pdf?MOD=AJPERES&CVID=n2HdSYL (https://digimeto.de/wps/wcm/connect/digimeto/a7c0814f-550e-4387-9a73-69bd36a7296c/DIGImeto_efr_SGM-DD_Bedienungsanleitung_lang_Web.pdf?MOD=AJPERES&CVID=n2HdSYL)
Meine Definition:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0@9600,7,E,1 VSM102
bringt im Logfile;
020.03.26 11:21:52 5: OBIS (STROM) - Opening device...
2020.03.26 11:21:52 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.03.26 11:21:52 3: Setting STROM serial parameters to 9600,7,E,1
2020.03.26 11:21:52 3: Init done
2020.03.26 11:21:52 3: STROM device opened
2020.03.26 11:22:10 5: SW: 2f3f210d0a
2020.03.26 11:22:10 4: Wrote /?!
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0@9600,7,E,1 SML
2020.03.26 11:33:36 5: OBIS (STROM) - Opening device...
2020.03.26 11:33:36 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.03.26 11:33:36 3: Setting STROM serial parameters to 9600,7,E,1
2020.03.26 11:33:36 3: Init done
2020.03.26 11:33:36 3: STROM device opened
2020.03.26 11:33:39 5: SW:
2020.03.26 11:33:39 4: Wrote
Laut Handbuch ist der Kommunikationsaufbau:
13.2. Technische Informationen zur D0-Dialogschnittstelle
Beschreibung der Schnittstelle:
Protokoll nach IEC 62056-21
Einstellungen:
7 Datenbits, Parität even, 1 Stopbit
Startbaudrate: 300 Bd
Kommunikationsbaudrate: 9600 Bd
Kommunikationsaufbau:
Befehlskette:
Komm: 300,7,E,1
Send: /?!<CR><LF>
Recv: / [Herstellerkennung] <CR><LF>
Send: <ACK>050<CR><LF>
Komm: 9600,7,E,1
Recv: <STX>0-1:97.97.0*255(0) <CR><LF>
...
weiterer Datenempfang
...
Recv: ! <CR><LF>
Recv: <ETX><NAK> Soll: <NAK>
Kommunikation wird beendet
Hat jemand eine Idee? Lieben Dank, Stephan
Mein SML Zähler läuft und läuft... bestimmt schon knapp zwei Jahre.
Dennoch bekomme ich immer wieder Fehler im Log, evlt. kennt sich jemand damit aus?
2020.03.30 10:16:38 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.03.30 10:16:38 1: stacktrace:
2020.03.30 10:16:38 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.03.30 10:16:38 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.03.30 10:16:38 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.03.30 10:16:38 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.03.30 10:16:38 1: main::OBIS_Read called by fhem.pl (3772)
2020.03.30 10:16:38 1: main::CallFn called by fhem.pl (757)
2020.03.30 10:16:38 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.03.30 10:16:38 1: stacktrace:
2020.03.30 10:16:38 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (793)
2020.03.30 10:16:38 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.03.30 10:16:38 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.03.30 10:16:38 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.03.30 10:16:38 1: main::OBIS_Read called by fhem.pl (3772)
2020.03.30 10:16:38 1: main::CallFn called by fhem.pl (757)
Zitatseit dem Zählertausch bekomme ich keine Daten mehr.
Hast Du
define initialUsbCheck notify global:INITIALIZED usb createdefiniert? Kannst es ja mit 'list initialUsbCheck' checken.
Wenn ja könnte es sein, dass das Modul "autocreate", das das "usb create" ausführt, Deine 'by-id' Definition nicht als Link erkennt (Rudi schreibt im Modul 'Optimized for linux /dev/serial/by-path/... links') und auf 'Deinem' Port ein anderes Objekt anlegt. Dann gibt das Huddel im Programm.
Ich habe nämlich letzte Woche mit dem User 'Cocojambo' diesen Fall diskutiert.
Gruß
Raymund
ZitatMein SML Zähler läuft und läuft... bestimmt schon knapp zwei Jahre.
Dennoch bekomme ich immer wieder Fehler im Log, evlt. kennt sich jemand damit aus?
Da sollte der Modulautor wohl mal seine "sub OBIS_decodeTL" optimieren. Aber wenn alle Daten da sind, die Du erwartest, dann ist das eher ein "Schönheitsfehler".
Gruß
Raymund
Hi,
habe jetzt mal meine OBIS Umgebung komplett dokumentiert, inkl. Bau eines Sensors.
https://mwinkler.jimdo.com/smarthome/aktoren-sensoren/stromz%C3%A4hler-digital/
Vielleicht kann es ja jemand gebrauchen.
Gruß
Michael
@StG (DD)
Funktioniert den die Umschaltung von 300 Baud auf 9600 Baud.
Pejonp
@icinger
hier der log. mehr kommt nicht.
2020.04.17 18:28:31 5: OBIS (zaehler1) - Internal timer set to 2020-04-17 18:38:31
2020.04.17 18:29:00 5: OBIS (zaehler1) - Internal timer set to 2020-04-17 18:39:00
2020.04.17 18:29:00 5: OBIS (zaehler1) - Opening device...
2020.04.17 18:29:01 3: Opening zaehler1 device /dev/lesekopf0
2020.04.17 18:29:01 3: Setting zaehler1 serial parameters to 300,7,E,1
2020.04.17 18:29:01 3: Init done
2020.04.17 18:29:01 3: zaehler1 device opened
hier ein List vom Device
Internals:
DEF /dev/lesekopf0@300,7,E,1 AS1440 19200
DeviceName /dev/lesekopf0@300,7,E,1
FD 13
FUUID 5e99d822-f33f-be85-8cda-7f0f6835a831bd28
MeterType AS1440
NAME zaehler1
NR 42
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-04-17 18:29:01 state opened
helper:
EoM -1
SPEED 0
SPEED2
TRIGGERTIME 1587140940.99494
DEVICES:
/2!
600
000
Attributes:
verbose 5
pejonp
@icinger
zeile 136: steht 18200 habe ich in 19200 geändert
my %bd=("300"=>"0","600"=>"1","1200"=>"2","2400"=>"3","4800"=>"4","9600"=>"5","19200"=>"6","36400"=>"7","57600"=>"8","115200"=>"9");
zeile 152: habe ich den init-String geändert, danach wird etwas in FHEM angezeigt
"AS1440" => ["\n/?!\r\n".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)]
Umschalten auf die höher Baudrate (9600 oder 19200) erfolgt aber noch nicht.
Ich benötige eigentlich nur diese Werte, aber dann pro Monat
1.8.1.x Bezug (kWh) 6:00 - 22:00
1.8.2.x Bezug (kWh) 22:00 - 6:00
2.8.1.x (2.8.6.x) Rücklieferung/Einspeisung (kWh)
der Monat steht hier:
0.1.2*67(20-04-01 00:00)
1.8.1.67 Bezug (kWh) 6:00 - 22:00
1.8.1*67(9082.038)
1.8.2.x Bezug (kWh) 22:00 - 6:00
1.8.2*67(5232.090)
2.8.1.x (2.8.6.x) Rücklieferung/Einspeisung (kWh)
2.8.1*67(0.000) ist leer deshalb --> 2.8.6*67(9468.792)
list Device
Internals:
DEF /dev/lesekopf0@300,7,E,1 AS1440 9600
DeviceName /dev/lesekopf0@300,7,E,1
FUUID 5e99d822-f33f-be85-8cda-7f0f6835a831bd28
MeterType AS1440
NAME zaehler1
NR 42
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-04-17 19:22:20 0.0.0 91700173
2020-04-17 19:22:22 0.1.0 67
2020-04-17 19:22:37 0.1.2.53 19-02-01 00:00
2020-04-17 19:22:37 0.1.2.54 19-03-01 00:00
2020-04-17 19:22:37 0.1.2.55 19-04-01 00:00
2020-04-17 19:22:37 0.1.2.56 19-05-01 00:00
2020-04-17 19:22:32 0.1.2.57 19-06-01 00:00
2020-04-17 19:22:32 0.1.2.58 19-07-01 00:00
2020-04-17 19:22:32 0.1.2.59 19-08-01 00:00
2020-04-17 19:22:32 0.1.2.60 19-09-01 00:00
2020-04-17 19:22:32 0.1.2.61 19-10-01 00:00
2020-04-17 19:22:27 0.1.2.62 19-11-01 00:00
2020-04-17 19:22:27 0.1.2.63 19-12-01 00:00
2020-04-17 19:22:27 0.1.2.64 20-01-01 00:00
2020-04-17 19:22:27 0.1.2.65 20-02-01 00:00
2020-04-17 19:22:27 0.1.2.66 20-03-01 00:00
2020-04-17 19:22:27 0.1.2.67 20-04-01 00:00
2020-04-17 19:19:40 0.2.0 14
2020-04-17 19:19:38 0.9.1 19:21:30
2020-04-17 19:19:38 0.9.2 20-04-17
2020-04-17 19:22:22 1.128.0 0
2020-04-17 19:22:37 1.4.0 09 0.028
2020-04-17 19:22:38 1.6.0 20-04-01 22:30
2020-04-17 19:22:59 1.6.0.53 19-01-06 22:30
2020-04-17 19:22:54 1.6.0.54 19-02-26 22:45
2020-04-17 19:22:54 1.6.0.55 19-03-15 22:30
2020-04-17 19:22:54 1.6.0.56 19-04-28 11:45
2020-04-17 19:22:54 1.6.0.57 19-05-22 10:00
2020-04-17 19:22:54 1.6.0.58 19-06-10 11:45
2020-04-17 19:22:49 1.6.0.59 19-07-13 18:45
2020-04-17 19:22:49 1.6.0.60 19-08-19 08:45
2020-04-17 19:22:49 1.6.0.61 19-09-24 11:45
2020-04-17 19:22:49 1.6.0.62 19-10-10 12:45
2020-04-17 19:22:49 1.6.0.63 19-11-05 13:15
2020-04-17 19:22:44 1.6.0.64 19-12-25 11:45
2020-04-17 19:22:41 1.6.0.65 20-01-11 23:00
2020-04-17 19:22:41 1.6.0.66 20-02-01 11:45
2020-04-17 19:22:40 1.6.0.67 20-03-10 13:00
2020-04-17 19:23:15 1.8.0 14386.848
2020-04-17 19:23:27 1.8.1 9108.379
2020-04-17 19:23:36 1.8.2 5278.469
2020-04-17 19:23:48 1.8.3 0
2020-04-17 19:17:45 1.8.4 0
2020-04-17 19:17:51 1.8.5 0
2020-04-17 19:18:01 1.8.6 0
2020-04-17 19:19:45 14.7 49.99
2020-04-17 19:22:37 2.4.0 09 0.004
2020-04-17 19:22:59 2.6.0 20-04-14 13:30
2020-04-17 19:23:15 2.6.0.53 19-01-31 14:15
2020-04-17 19:23:15 2.6.0.54 19-02-24 13:00
2020-04-17 19:23:15 2.6.0.55 19-03-20 13:45
2020-04-17 19:23:09 2.6.0.56 19-04-16 13:15
2020-04-17 19:23:09 2.6.0.57 19-05-21 12:45
2020-04-17 19:23:07 2.6.0.58 19-06-21 14:15
2020-04-17 19:23:07 2.6.0.59 19-07-11 12:45
2020-04-17 19:23:05 2.6.0.60 19-08-03 15:00
2020-04-17 19:23:05 2.6.0.61 19-09-11 14:45
2020-04-17 19:23:05 2.6.0.62 19-10-07 14:45
2020-04-17 19:23:05 2.6.0.63 19-11-14 12:45
2020-04-17 19:23:05 2.6.0.64 19-12-28 13:00
2020-04-17 19:23:00 2.6.0.65 20-01-18 13:00
2020-04-17 19:22:59 2.6.0.66 20-02-25 14:45
2020-04-17 19:22:59 2.6.0.67 20-03-31 13:15
2020-04-17 19:18:11 2.8.0 9669.016
2020-04-17 19:18:20 2.8.1 0
2020-04-17 19:18:29 2.8.2 0
2020-04-17 19:18:38 2.8.3 0
2020-04-17 19:18:47 2.8.4 0
2020-04-17 19:19:00 2.8.5 0
2020-04-17 19:19:07 2.8.6 9669.016
2020-04-17 19:19:45 3.7.0 0
2020-04-17 19:19:20 3.8.1 598.07
2020-04-17 19:19:50 31.7 1.73
2020-04-17 19:19:55 32.32.0 05-01-01 00:00
2020-04-17 19:19:55 32.36.0 05-01-01 00:00
2020-04-17 19:19:45 32.7 231.8
2020-04-17 19:19:28 4.8.1 21846.568
2020-04-17 19:19:50 51.7 1.05
2020-04-17 19:20:00 52.32.0 05-01-01 00:00
2020-04-17 19:19:55 52.36.0 05-01-01 00:00
2020-04-17 19:19:45 52.7 230.1
2020-04-17 19:19:50 71.7 2.03
2020-04-17 19:20:00 72.32.0 05-01-01 00:00
2020-04-17 19:19:55 72.36.0 05-01-01 00:00
2020-04-17 19:19:50 72.7 231.6
2020-04-17 19:19:50 81.7.1 120.3
2020-04-17 19:19:55 81.7.12 119.8
2020-04-17 19:19:50 81.7.15 -89.8
2020-04-17 19:19:55 81.7.20 119.7
2020-04-17 19:19:50 81.7.26 -35.2
2020-04-17 19:19:50 81.7.4 -121.6
2020-04-17 19:19:50 91.7 3.24
2020-04-17 19:20:00 C.2.1 14-10-24 06:51
2020-04-17 19:20:00 C.7.0 18-11-13 13:57
2020-04-17 19:20:00 C.7.1 05-01-01 00:00
2020-04-17 19:20:05 C.7.2 05-01-01 00:00
2020-04-17 19:20:05 C.7.3 18-08-16 08:33
2020-04-17 19:20:12 C.71.1 1
2020-04-17 19:20:12 C.71.2 120
2020-04-17 19:20:12 C.71.3 0
2020-04-17 19:20:12 C.71.4 0
2020-04-17 19:20:12 C.71.5 2
2020-04-17 19:22:20 Version 442-000673)
2020-04-17 19:22:37 feed_L1 155.407
2020-04-17 19:19:45 feed_L2 0.687
2020-04-17 19:22:37 power 251.446
2020-04-17 19:14:36 state opened
2020-04-17 19:23:27 total_consumption 11407.043
2020-04-17 19:23:36 total_consumption_Ch1 7433.388
2020-04-17 19:23:45 total_consumption_Ch2 3973.655
2020-04-17 19:23:48 total_consumption_Ch3 0
2020-04-17 19:17:50 total_consumption_Ch4 0
2020-04-17 19:18:00 total_consumption_Ch5 0
2020-04-17 19:18:11 total_consumption_Ch6 0
2020-04-17 19:18:20 total_feed 7003.225
2020-04-17 19:18:29 total_feed_Ch1 0
2020-04-17 19:18:38 total_feed_Ch2 0
2020-04-17 19:18:47 total_feed_Ch3 0
2020-04-17 19:19:00 total_feed_Ch4 0
2020-04-17 19:19:05 total_feed_Ch5 0
2020-04-17 19:19:15 total_feed_Ch6 7003.225
helper:
BUFFER 1.8.3*64(0.
EoM 0
SPEED 0
SPEED2 5
TRIGGERTIME 1587143895.35665
Channels:
DEVICES: /?!
120
000
directions:
Attributes:
interval 120
pollingMode on
room HausZaehler
verbose 5
habe den log mal als Datei angehangen.
pejonp
Dann hats da aber irgendwas......
Bei mir funktioniert das:
2020.04.17 21:29:08 4: Second Device -> /dev/serial/by-path/platform-1c1c000.usb-usb-0:1.1.2:1.0-port0@115200,7,E,1
2020.04.17 21:29:08 5: OBIS (Strom) - Internal timer set to 2020-04-17 21:30:00
2020.04.17 21:29:08 5: OBIS (Strom) - Opening device...
2020.04.17 21:29:08 3: Opening Strom device /dev/serial/by-path/platform-1c1c000.usb-usb-0:1.1.2:1.0-port0
2020.04.17 21:29:08 3: Setting Strom serial parameters to 9600,7,E,1
2020.04.17 21:29:08 3: Init done
2020.04.17 21:29:08 3: Strom device opened
2020.04.17 21:29:48 4: Wrote /?!
2020.04.17 21:29:48 4: Writing 090
2020.04.17 21:29:48 5: SW: 063039300d0a
2020.04.17 21:29:48 4: Closing Device
2020.04.17 21:29:48 4: Opening /dev/serial/by-path/platform-1c1c000.usb-usb-0:1.1.2:1.0-port0@115200,7,E,1
2020.04.17 21:29:48 3: Opening Strom device /dev/serial/by-path/platform-1c1c000.usb-usb-0:1.1.2:1.0-port0
2020.04.17 21:29:48 3: Setting Strom serial parameters to 115200,7,E,1
2020.04.17 21:29:48 3: Init done
2020.04.17 21:29:48 3: Strom device opened
Vielleicht findet sich ja noch jemand ander, der die Umschaltung testen will?
Jetzt war ich interessiert und wollte auch mal die Umschaltung testen. Leider scheint es auch bei mir nicht so zu funktionieren.
list device
Internals:
DEF /dev/ttyUSB0@300,7,E,1 AS1440 115200
DeviceName /dev/ttyUSB0@300,7,E,1
FD 10
FUUID 5e9c6438-f33f-0a2c-7a16-852904a4ca941fd4
MeterType AS1440
NAME as1440
NEXT 2020-04-19 17:40:00
NR 23
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-04-19 17:30:04 0.0.0 10191000
2020-04-19 17:30:04 0.0.1 03214286
2020-04-19 17:30:22 0.2.2 0
2020-04-19 17:30:02 0.9.1 173004
2020-04-19 17:30:03 0.9.2 200419
2020-04-19 17:30:07 1.8.2 0
2020-04-19 17:30:08 1.8.3 0
2020-04-19 17:30:09 1.8.4 0
2020-04-19 17:30:10 1.8.5 0
2020-04-19 17:30:11 1.8.6 0
2020-04-19 17:30:11 1.8.7 0
2020-04-19 17:30:12 1.8.8 0
2020-04-19 17:30:13 1.9.0 72.8
2020-04-19 17:30:16 2.8.2 0
2020-04-19 17:30:17 2.8.3 0
2020-04-19 17:30:18 2.8.4 0
2020-04-19 17:30:19 2.8.5 0
2020-04-19 17:30:19 2.8.6 0
2020-04-19 17:30:20 2.8.7 0
2020-04-19 17:30:21 2.8.8 0
2020-04-19 17:30:22 2.9.0 757.1
2020-04-19 16:50:01 Version ELS5\@V9.30
2020-04-19 17:30:06 count_consumption 4716.4
2020-04-19 17:30:06 count_consumption_Ch1 4716.4
2020-04-19 17:30:14 count_feed 22903.4
2020-04-19 17:30:15 count_feed_Ch1 22903.4
2020-04-19 17:30:25 current_L1 1.025
2020-04-19 17:30:26 current_L2 1.202
2020-04-19 17:30:26 current_L3 0.678
2020-04-19 17:30:14 feed_L1 0.662
2020-04-19 17:30:05 power 0
2020-04-19 17:33:01 state opened
2020-04-19 16:40:07 total_consumption_Ch2 0
2020-04-19 16:40:08 total_consumption_Ch3 0
2020-04-19 16:40:09 total_consumption_Ch4 0
2020-04-19 16:40:10 total_consumption_Ch5 0
2020-04-19 16:40:10 total_consumption_Ch6 0
2020-04-19 16:40:11 total_consumption_Ch7 0
2020-04-19 16:40:12 total_consumption_Ch8 0
2020-04-19 16:40:16 total_feed_Ch2 0
2020-04-19 16:40:17 total_feed_Ch3 0
2020-04-19 16:40:18 total_feed_Ch4 0
2020-04-19 16:40:19 total_feed_Ch5 0
2020-04-19 16:40:19 total_feed_Ch6 0
2020-04-19 16:40:20 total_feed_Ch7 0
2020-04-19 16:40:21 total_feed_Ch8 0
2020-04-19 17:30:23 voltage_L1 236.4
2020-04-19 17:30:24 voltage_L2 236.5
2020-04-19 17:30:24 voltage_L3 236.2
helper:
BUFFER
EoM -1
SPEED 0
SPEED2 9
TRIGGERTIME 1587310800
Channels:
1.8.0 count_consumption
1.8.1 count_consumption_Ch1
2.8.0 count_feed
2.8.1 count_feed_Ch1
DEVICES:
/2!
600
000
Attributes:
alignTime 00:00:00
channels {"1.8.0"=>"count_consumption","1.8.1"=>"count_consumption_Ch1","2.8.0"=>"count_feed","2.8.1"=>"count_feed_Ch1"}
event-on-change-reading .*
room System
verbose 5
log
2020.04.19 17:33:01 5: OBIS (as1440) - Internal timer set to 2020-04-19 17:40:00
2020.04.19 17:33:01 5: OBIS (as1440) - Opening device...
2020.04.19 17:33:01 3: Opening as1440 device /dev/ttyUSB0
2020.04.19 17:33:01 3: Setting as1440 serial parameters to 300,7,E,1
2020.04.19 17:33:01 3: Init done
2020.04.19 17:33:01 3: as1440 device opened
2020.04.19 17:40:00 5: SW: 2f32210d0a
2020.04.19 17:40:00 4: Wrote /2!
2020.04.19 17:40:00 5: OBIS (as1440) - Internal timer set to 2020-04-19 17:50:00
2020.04.19 17:40:01 5: OBIS (as1440) - Msg-Parse: /ELS5\@V9.30
2020.04.19 17:40:01 5: SW: 063030300d0a
2020.04.19 17:40:02 5: OBIS (as1440) - Msg-Parse: F.F(00000000)
2020.04.19 17:40:02 5: OBIS (as1440) - Msg-Parse: 0.9.1(174005)
2020.04.19 17:40:03 5: OBIS (as1440) - Msg-Parse: 0.9.2(200419)
2020.04.19 17:40:04 5: OBIS (as1440) - Msg-Parse: 0.0.0(10191000)
2020.04.19 17:40:04 5: OBIS (as1440) - Msg-Parse: 0.0.1(03214286)
2020.04.19 17:40:04 5: Msg 0.0.1(03214286) is of type Serial
2020.04.19 17:40:05 5: OBIS (as1440) - Msg-Parse: 1.7.0(0.000*kW)
2020.04.19 17:40:05 5: Msg 1.7.0(0.000*kW) is of type Channels
2020.04.19 17:40:06 5: OBIS (as1440) - Msg-Parse: 1.8.0(0004716.4*kWh)
2020.04.19 17:40:07 5: OBIS (as1440) - Msg-Parse: 1.8.1(0004716.4*kWh)
2020.04.19 17:40:07 5: OBIS (as1440) - Msg-Parse: 1.8.2(0000000.0*kWh)
2020.04.19 17:40:08 5: OBIS (as1440) - Msg-Parse: 1.8.3(0000000.0*kWh)
2020.04.19 17:40:09 5: OBIS (as1440) - Msg-Parse: 1.8.4(0000000.0*kWh)
2020.04.19 17:40:10 5: OBIS (as1440) - Msg-Parse: 1.8.5(0000000.0*kWh)
2020.04.19 17:40:11 5: OBIS (as1440) - Msg-Parse: 1.8.6(0000000.0*kWh)
2020.04.19 17:40:11 5: OBIS (as1440) - Msg-Parse: 1.8.7(0000000.0*kWh)
2020.04.19 17:40:12 5: OBIS (as1440) - Msg-Parse: 1.8.8(0000000.0*kWh)
2020.04.19 17:40:13 5: OBIS (as1440) - Msg-Parse: 1.9.0(0000072.8*kWh)
2020.04.19 17:40:14 5: OBIS (as1440) - Msg-Parse: 2.7.0(0.460*kW)
2020.04.19 17:40:14 5: Msg 2.7.0(0.460*kW) is of type Channels
2020.04.19 17:40:15 5: OBIS (as1440) - Msg-Parse: 2.8.0(0022903.5*kWh)
2020.04.19 17:40:15 5: OBIS (as1440) - Msg-Parse: 2.8.1(0022903.5*kWh)
2020.04.19 17:40:16 5: OBIS (as1440) - Msg-Parse: 2.8.2(0000000.0*kWh)
2020.04.19 17:40:17 5: OBIS (as1440) - Msg-Parse: 2.8.3(0000000.0*kWh)
2020.04.19 17:40:18 5: OBIS (as1440) - Msg-Parse: 2.8.4(0000000.0*kWh)
2020.04.19 17:40:19 5: OBIS (as1440) - Msg-Parse: 2.8.5(0000000.0*kWh)
2020.04.19 17:40:19 5: OBIS (as1440) - Msg-Parse: 2.8.6(0000000.0*kWh)
2020.04.19 17:40:20 5: OBIS (as1440) - Msg-Parse: 2.8.7(0000000.0*kWh)
2020.04.19 17:40:21 5: OBIS (as1440) - Msg-Parse: 2.8.8(0000000.0*kWh)
2020.04.19 17:40:22 5: OBIS (as1440) - Msg-Parse: 2.9.0(0000757.2*kWh)
2020.04.19 17:40:23 5: OBIS (as1440) - Msg-Parse: 0.2.2(00000000)
2020.04.19 17:40:23 5: Msg 0.2.2(00000000) is of type Channels2
2020.04.19 17:40:23 5: OBIS (as1440) - Msg-Parse: 32.7.0(235.0*V)
2020.04.19 17:40:23 5: Msg 32.7.0(235.0*V) is of type Channels
2020.04.19 17:40:24 5: OBIS (as1440) - Msg-Parse: 52.7.0(236.5*V)
2020.04.19 17:40:24 5: Msg 52.7.0(236.5*V) is of type Channels
2020.04.19 17:40:24 5: OBIS (as1440) - Msg-Parse: 72.7.0(235.9*V)
2020.04.19 17:40:24 5: Msg 72.7.0(235.9*V) is of type Channels
2020.04.19 17:40:25 5: OBIS (as1440) - Msg-Parse: 31.7.0(0.738*A)
2020.04.19 17:40:25 5: Msg 31.7.0(0.738*A) is of type Channels
2020.04.19 17:40:26 5: OBIS (as1440) - Msg-Parse: 51.7.0(0.966*A)
2020.04.19 17:40:26 5: Msg 51.7.0(0.966*A) is of type Channels
2020.04.19 17:40:26 5: OBIS (as1440) - Msg-Parse: 71.7.0(0.522*A)
2020.04.19 17:40:26 5: Msg 71.7.0(0.522*A) is of type Channels
2020.04.19 17:40:26 5: OBIS (as1440) - Msg-Parse: !
Ich habe das Ganze mit ... 9600 und ... 115200 durchgespielt. Die Daten wurden aber immer nur mit 300 Baud gelesen.
Was kann ich noch tun?
Gruß VuffiRaa
@vuffiraa
Kannst du gar nicht testen, weil du das Modul von mir (noch) nicht hast :D
PS: Bekommst gleich PN
Zitat von: Icinger am 19 April 2020, 18:29:25
@vuffiraa
Kannst du gar nicht testen, weil du das Modul von mir (noch) nicht hast :D
PS: Bekommst gleich PN
Deshalb habe ich die passende Stelle im Modul nicht finden können ;)
Mit dem richtigen Modul ist der Umschaltversuch zu sehen, aber Daten kommen dann leider nicht:
2020.04.19 19:27:35 1: Including fhem.cfg
2020.04.19 19:27:35 3: telnetPort: port 7072 opened
2020.04.19 19:27:38 3: WEB: port 8083 opened
2020.04.19 19:27:38 3: WEBphone: port 8084 opened
2020.04.19 19:27:38 3: WEBtablet: port 8085 opened
2020.04.19 19:27:38 2: eventTypes: loaded 79 events from ./log/eventTypes.txt
2020.04.19 19:27:40 1: PERL WARNING: Possible attempt to separate words with commas at ./FHEM/47_OBIS.pm line 167, <$fh> line 55.
2020.04.19 19:27:40 3: Opening as1440 device /dev/ttyUSB0
2020.04.19 19:27:40 3: Setting as1440 serial parameters to 300,7,E,1
2020.04.19 19:27:40 3: Init done
2020.04.19 19:27:40 3: as1440 device opened
2020.04.19 19:27:40 1: Including ./log/fhem.save
2020.04.19 19:27:41 1: Messages collected while initializing FHEM:SecurityCheck:
WEBtablet is not password protected
WEB is not password protected
telnetPort is not password protected
WEBphone is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
2020.04.19 19:27:41 0: Featurelevel: 6
2020.04.19 19:27:41 0: Server started with 12 defined entities (fhem.pl:21709/2020-04-17 perl:5.020002 os:linux user:fhem pid:30155)
2020.04.19 19:30:00 5: SW: 2f32210d0a
2020.04.19 19:30:00 4: Wrote /2!
2020.04.19 19:30:00 4: Writing 050
2020.04.19 19:30:00 5: SW: 063035300d0a
2020.04.19 19:30:00 4: Closing Device
2020.04.19 19:30:00 4: Opening /dev/ttyUSB0@9600,7,E,1
2020.04.19 19:30:00 3: Opening as1440 device /dev/ttyUSB0
2020.04.19 19:30:00 3: Setting as1440 serial parameters to 9600,7,E,1
2020.04.19 19:30:00 3: Init done
2020.04.19 19:30:00 3: as1440 device opened
2020.04.19 19:30:00 5: OBIS (as1440) - Internal timer set to 2020-04-19 19:40:00
2020.04.19 19:40:00 5: SW: 2f32210d0a
2020.04.19 19:40:00 4: Wrote /2!
2020.04.19 19:40:00 5: OBIS (as1440) - Internal timer set to 2020-04-19 19:50:00
EDIT: Ich habe mal im Volkszähler-Wik (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440) geschaut. Interessant sind wohl die Sätze:
Alternativ kann die Kommunikation statt mit /?!\r\n manchmal auch mit /2!\r\n (hex 2F 32 21 0D 0A) angestoßen werden. Der Zähler antwortet dann direkt, ohne Baudratenumschaltung, mit der Liste der Aktualwerte.
Ich könnte mal schauen, ob ich es bei mir "hingebogen" bekomme.
Gruß VuffiRaa
Hab mir das VZ-Wiki grad nochmal durchgeschaut.
Mich macht da ganz was anderes stutzig:
ZitatWenn die Datenrate geändert wurde, muss man das natürlich berücksichtigen, also z.B. bei hterm auf 9600 Baud umstellen.
Jetzt kann man mit dem Zähler kommunizieren, s. Befehle. Wenn für ca. 6s keine weiteren Befehle gesendet werden, beendet der Zähler die Kommunikation mit der Sequenz
Diese Befehle, die weiter unten stehen, sind aber nicht die Standard-Aufforderung um die Daten zu senden.
Meine Vermutung:
Die Umschaltung klappt mal, aber da muss dann ein Befehl zB zum
ZitatKompletten Lastgangspeicher 1 auslesen (enthält standardmäßig 15-Min-Werte der importierten und exportierten Leistung ca. der letzten 3 Wochen)
gesendet werden.
lg, Stefan
Juhuuuuuu, ich glaub, es ist (endlich) vollbracht.
Baudraten-Umschaltung sollte funktionieren :D
Bräuchte noch ein, zwei Tester. Freiwillige bitte kurz melden :)
Ging ursprünglich davon aus, dass die einmal erfolgte Baudratenumstellung danach endgültig ist.
DENKSTE! Richtig ist:
Mit 300bd die Umstellung anfordern, danach den Port schließen/neu öffnen.
Daten mit höherer Speed empfangen.
Und danach: Port schließen, mit 300 wieder öffnen und neu anfordern :(
Da muss ma mal drauf kommen. **facepalm**
Danke an vuffiraa für den Wink mit dem Zaunpfahl :)
lg, Stefan
Hallo,
bei mir verliert der Zähler seit einiger Zeit alle 3-5 Tage immer wieder Nachts die Verbindung.
Das lief eine Weile gut, nachdem ich auf serial/by-id umgestellt hatte, nu seit 3-4 Woche passiert das wieder.
2020.05.10 01:59:23 1: PERL WARNING: portable_TIOCINQ(21531) ioctl failed: Input/output error at ./FHEM/47_OBIS.pm line 598.
2020.05.10 01:59:23 1: PERL WARNING: Use of uninitialized value $InBytes in numeric gt (>) at ./FHEM/47_OBIS.pm line 599.
defmod EWS_Mittlerschwanden_13 OBIS /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN03T8ET-if00-port0@300,7,E,1 VSM102
attr EWS_Mittlerschwanden_13 alignTime 00:00
attr EWS_Mittlerschwanden_13 event-on-change-reading .*
attr EWS_Mittlerschwanden_13 interval 30
attr EWS_Mittlerschwanden_13 pollingMode on
hat jemand eine Idee, wo ich schauen könnte?
Linux ? Mit dmesg evtl. das "disconnect" sichtbar ?
Lesekopf nicht mehr 100% richtig positioniert ?(gab es just die Tage einen Fall, wo genau das die "plötzliche" Ursache war.)
Wenn da alles unverdächtig ist, mal das list(und nicht raw) des devices posten, dann sehen wir auch die internals.
Grüße Markus
Hallo zusammen,
darf ich was zu den OBIS Daten zwischen fragen. Gibt es eine Aufstellung der Obis Daten?
Mein Zähler spuckt die Obisdaten auch aus, ich kann die Daten anhand der Obis Codenummer nicht zuordnen.
Danke und Gruß
Gesendet von meinem SM-G975F mit Tapatalk
Klar (https://de.wikipedia.org/wiki/OBIS-Kennzahlen)
Besten dank das schaue ich mir an.
Gruß
Zitat von: KölnSolar am 10 Mai 2020, 08:59:43
Linux ? Mit dmesg evtl. das "disconnect" sichtbar ?
[1778479.503954] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1778479.504069] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1778479.529216] usb 1-1.5: USB disconnect, device number 11
[1778479.529543] ftdi_sio ttyUSB1: error from flowcontrol urb
[1778479.529919] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[1778479.529988] ftdi_sio 1-1.5:1.0: device disconnected
[1778479.828003] usb 1-1.5: new full-speed USB device number 12 using dwc_otg
[1778479.986724] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[1778479.986738] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1778479.986748] usb 1-1.5: Product: FT230X Basic UART
[1778479.986757] usb 1-1.5: Manufacturer: FTDI
[1778479.986766] usb 1-1.5: SerialNumber: DN03T8ET
[1778479.995880] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[1778479.996070] usb 1-1.5: Detected FT-X
[1778479.996925] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB0
Zitat
Lesekopf nicht mehr 100% richtig positioniert ?(gab es just die Tage einen Fall, wo genau das die "plötzliche" Ursache war.)
unwahrscheinlich, denn das tritt immer um 2 Uhr Nachts auf.
Zitat
Wenn da alles unverdächtig ist, mal das list(und nicht raw) des devices posten, dann sehen wir auch die internals.
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN03T8ET-if00-port0@300,7,E,1 VSM102
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN03T8ET-if00-port0@300,7,E,1
FUUID 5ca3a44c-f33f-23af-7cfd-ab4530f662574c52
MeterType VSM102
NAME EWS_Mittlerschwanden_13
NEXT 2020-05-10 22:04:00
NR 14
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-05-10 22:03:40 0.0.2 15214533
2020-05-10 22:03:19 0.2.0 K76-0-8
2020-05-10 22:03:45 1.8.0 31925.777
2020-05-10 22:03:40 1.8.1 18794.079
2020-05-10 22:03:40 1.8.2 13131.698
2020-05-10 22:03:45 15.8.0 31925.778
2020-05-10 22:03:45 2.8.0 0
2020-05-10 22:03:45 2.8.1 0
2020-05-10 22:03:45 2.8.2 0
2020-05-10 22:03:40 C.1.0 15214533
2020-05-10 22:03:40 C.1.1
2020-05-10 22:03:19 C.5.0 0004E0F0
2020-05-10 22:03:45 C.7.0 18
2020-04-18 21:18:05 Version LGZ4ZMR120AC.K76
2020-05-10 07:22:42 current 1.42
2020-05-10 22:03:46 current_L1 0.33
2020-05-10 22:03:46 current_L2 0.89
2020-05-10 22:03:19 current_L3 0.97
2020-05-10 07:22:42 power 328.35
2020-05-10 07:22:42 power_L1 83.16
2020-05-10 07:22:42 power_L2 76.56
2020-05-10 07:22:42 power_L3 168.63
2020-05-10 07:32:04 state opened
2020-05-10 22:03:45 voltage_L1 229
2020-05-10 22:03:45 voltage_L2 230
2020-05-10 22:03:46 voltage_L3 229
helper:
BUFFER 71.7.0(000.93*A
EoM 0
SPEED 0
SPEED2 0
TRIGGERTIME 1589141040
Channels:
DEVICES:
/?!
30
000
Attributes:
alignTime 00:00
event-on-change-reading .*
interval 30
pollingMode on
Das sieht mir nach einen Spannungsproblem auf dem USB-Bus bzw. beim FTDI aus.
Ich hatte mit einem USB-Hub dieses Problem.
Sporadisch gab es Reconnects. Dann habe ich ihn gegen einen mit Netzteil ausgetauscht. Seither ohne Probleme
ok, das Ding hängt an einem step down wandler vie PoE, den kann ich mal hoch regeln.. Aber wieso immer nachts um 02:00?
Moin Stefan,
ich hole mal einen alten Beitrag hoch und wollte mal nachfassen, wie es denn damit steht ;)
Im Kern ging es um die Vorwerte und ein Ignore- bzw. Exclude Attribut.
siehe auch:
https://forum.fhem.de/index.php/topic,51948.msg687566.html#msg687566 (https://forum.fhem.de/index.php/topic,51948.msg687566.html#msg687566) und etwas davor.
Viele Grüße
Martin
Zitat von: Icinger am 19 September 2017, 19:13:19
Hallo Martin,
Es ist eine kurzfristige Lösung, aber keine langfristige, da geb ich dir durchaus recht.
Das streite ich dir auch nicht ab. Bislang war allerdings der Bedarf dafür nicht gegeben.
Das mit den Vorwerten ist mir auch neu und habe ich wohl bei meinen Recherchen übersehen bzw. wurde ich auch bislang nicht darauf hingewiesen.
Da mein Zähler das nicht sendet, ist mir das auch nie aufgefallen.
Auch nicht bei den verschiedenen Test-Daten, die ich von anderen Usern habe.
Ich sehe in deinen Beispieldaten keine Hinweise auf irgendwelche Zeitstempel, du kannst mich aber gerne mit der Nase daraufstoßen.
Eigentlich WIRD dieses Housekeeping durchgeführt, bei den anderen Werten stimmt es ja auch:
2017-09-19 19:02:54 current_L1 1.34 A
2017-09-19 19:02:54 current_L2 0.15 A
2017-09-19 19:02:54 current_L3 0.81 A
2017-09-19 19:02:54 power 0.42 kW
2017-09-19 19:02:54 voltage_L1 231 V
2017-09-19 19:02:54 voltage_L2 231 V
2017-09-19 19:02:54 voltage_L3 231 V
Warum dem bei den kWh nicht so ist, werde ich mir ansehen.
Das sind übrigens die Daten von deinem gestrigen Post.
Wie gesagt, kurzfristige Lösung steht oben.
Längerfristige Lösung dauert sicher noch ein wenig.
Ich habe aktuell dank 10-Stunden-Tag plus einer Stunde Autofahrt davor und danach sowie Haus, Garten, Baustelle nicht wirklich viel Zeit.
Sehe zwar täglich kurz als Zeitvertreib hier in Forum, allerdings fehlt mir eben aktuell die Muße, mich erst wieder in den Code einzulesen.
Aber ich habs als ToDo ganz oben stehn und sobald ich nichts mehr draussen machen kann, kommt das an die Reihe.
Schönen Abend noch,
Stefan
Zitatich hole mal einen alten Beitrag hoch und wollte mal nachfassen, wie es denn damit steht ;)
Hatte ich nimmer auf dem Schirm, kann ich aber machen.
Hast du mal ein vollständiges Datagramm für mich, bitte?
Zitat von: Icinger am 16 Mai 2020, 17:58:03
Hast du mal ein vollständiges Datagramm für mich, bitte?
Sehr gerne...Dabei ist mir aufgefallen, das im Logfile ein Linefeed nicht bereinigt wird:
2020.05.17 10:35:00.003 4: Wrote /?!^MDas erzeugt dann unschöne Leerzeilen ;)
Im Anhang ein Mitschnitt meines (gesprächigen) Landis + Gyr E230.
Danke im vorraus!
Viele Grüße
Martin
Hi,
ich habe bei mir 2 Zähler mittels den IR Leseköpfen vom Volkszähler eingerichtet.
Einer ist der Bezugs-Lieferzähler und der andere der Solar Zähler der Photovoltaikanlage.
Das ganze lief auch jetzt eine knappe Woche gut und ohne Probleme.
Nun habe ich heut festgestellt das der Bezugslieferzähler auf einmal seit dem 29.05. gegen 22:00 auf disconnected steht. Im log steht das er auf das USB Device nicht zugreifen kann.
Ein reboot hat auch nicht geholfen.
Hat irgendwer eine Idee?
Internals:
DEF /dev/ttyUSB0,8,N,1 SML
DeviceName /dev/ttyUSB0,8,N,1
FUUID 5ecc1694-f33f-3f4d-9a66-e39a4f030cb13adf
MeterType SML
NAME Zaehler1
NR 16
PARTIAL
STATE disconnected
TYPE OBIS
2020.06.01 11:18:18 3: Opening Zaehler1 device /dev/ttyUSB0,8,N,1
2020.06.01 11:18:18 1: Zaehler1: Can't open /dev/ttyUSB0,8,N,1: No such file or directory
Gesendet von iPhone mit Tapatalk Pro
als erstes prüfen, ob die Schnittstelle überhaupt im System ist: dmesg bei Linux
Eine Definition mit /dev/serial/by-id/... od. wenigstens /dev/serial/by-path/... schützt vor Zuordnungsproblemen.
Zitat von: KölnSolar am 01 Juni 2020, 16:32:07
als erstes prüfen, ob die Schnittstelle überhaupt im System ist: dmesg bei Linux
Eine Definition mit /dev/serial/by-id/... od. wenigstens /dev/serial/by-path/... schützt vor Zuordnungsproblemen.
okay prüfe ich heut abend gleich wenn ich wieder daheim bin.
was mich wundert ist das es ja erst eine ganze weile ging und dann auf einmal nicht mehr.
Gesendet von iPhone mit Tapatalk Pro
laut dmesg ist die Schnittstelle da:
[ 6.830072] usbserial: USB Serial support registered for cp210x
[ 6.830246] cp210x 1-1.2:1.0: cp210x converter detected
[ 6.850745] usb 1-1.2: cp210x converter now attached to ttyUSB0
[ 6.851945] cp210x 1-1.1.2:1.0: cp210x converter detected
[ 6.864804] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
auch ein lsusb zeigt mir die Devices an:
kellerpi:~# lsusb
Bus 001 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family]
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family]
Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
nur irgendwie will er nicht auf connected gehen.
Wenn ich mit minicom auf USB zugreife kommen auch Daten an.
ls /dev/serial/by-id/* -l ergibt was ?
ZitatEine Definition mit /dev/serial/by-id/... od. wenigstens /dev/serial/by-path/... schützt vor Zuordnungsproblemen.
Zitat von: KölnSolar am 02 Juni 2020, 09:15:54
ls /dev/serial/by-id/* -l ergibt was ?
kellerpi:~# ls /dev/serial/by-id/* -l
lrwxrwxrwx 1 root root 13 Jun 2 09:15 /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01A62442-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jun 2 09:15 /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01A64D43-if00-port0 -> ../../ttyUSB0
Im FHEM Log steht folgendes:
2020.06.02 09:15:16 1: PERL WARNING: Smartmatch is experimental at ./FHEM/47_OBIS.pm line 472, <$fh> line 49.
2020.06.02 09:15:16 1: PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 785, <$fh> line 49.
2020.06.02 09:15:16 3: Opening Zaehler1 device /dev/ttyUSB0,8,N,1
2020.06.02 09:15:16 1: Zaehler1: Can't open /dev/ttyUSB0,8,N,1: No such file or directory
2020.06.02 09:15:16 3: Opening Zaehler2 device /dev/ttyUSB1,8,N,1
2020.06.02 09:15:16 1: Zaehler2: Can't open /dev/ttyUSB1,8,N,1: No such file or directory
Mit /dev/serial/by-id/... kommt das selbe. Habe ich auch schon probiert.
Du solltest auf jeden Fall by-id definieren...
Zitat2020.06.02 09:15:16 3: Opening Zaehler1 device /dev/ttyUSB0,8,N,1
2020.06.02 09:15:16 1: Zaehler1: Can't open /dev/ttyUSB0,8,N,1: No such file or directory
Ähmmm
ZitatDas ganze lief auch jetzt eine knappe Woche gut und ohne Probleme.
Kann ich mir so definiert nicht vorstellen.
ZitatExample:
define myPowerMeter OBIS /dev/ttyPlugwise@@9600,7,E,1 VSM102
(Edit: sah gerade: das doppelte @ im Bsp. der commandref dürfte falsch sein :()
Wo ist Dein @ mit Baudrate ? :o
Zitat von: KölnSolar am 02 Juni 2020, 09:48:00
Du solltest auf jeden Fall by-id definieren...
ÄhmmmKann ich mir so definiert nicht vorstellen.(Edit: sah gerade: das doppelte @ im Bsp. der commandref dürfte falsch sein :()
Wo ist Dein @ mit Baudrate ? :o
Doch es lief.
Aber ich hab Dank Dir jetzt auch den Fehler gefunden :_)
Das Problem war das ich ein at im FHEM definiert hatte hatte was checkt ob sich Power 10 Minuten lang nicht ändert und wenn ja ein modify auf das Device macht um es wiederzubeleben.
Im dem Modify war ein type und der hat das @ geklaut vor der Baudrate. Manchmal ist man echt blind.
Danke Dir. :-) :-) :-)
Hallo Stefan,
Zitat von: Icinger am 19 April 2020, 18:29:25
Kannst du gar nicht testen, weil du das Modul von mir (noch) nicht hast :D
kannst Du mir auch das Modul mit der Baudratenumschaltung zusenden?
Ich habe hier einen Iskrameco MT173 Zähler der ohne Umschaltung von 300 auf 9600 Baud die Daten nicht vollständig überträgt.
Danke und Grüße
Franz
Zitat von: Raymund am 30 März 2020, 10:57:41
Hast Du
define initialUsbCheck notify global:INITIALIZED usb create
definiert? Kannst es ja mit 'list initialUsbCheck' checken.
Wenn ja könnte es sein, dass das Modul "autocreate", das das "usb create" ausführt, Deine 'by-id' Definition nicht als Link erkennt (Rudi schreibt im Modul 'Optimized for linux /dev/serial/by-path/... links') und auf 'Deinem' Port ein anderes Objekt anlegt. Dann gibt das Huddel im Programm.
Ich habe nämlich letzte Woche mit dem User 'Cocojambo' diesen Fall diskutiert.
Gruß
Raymund
Hallo Raymund,
danke für Deine Antwort. Hatte leider keine Email bekommen, daher erst jetzt wieder mal in Forum geschaut.
"list initialUsbCheck" liefert "No device named initialUsbCheck found"
(Hatte zuerst auf den Raspi geschaut, aber das OBIS läuft auf einem separaten Bananapi im Keller)
Zitat von: pejonp am 16 April 2020, 16:40:38
@StG (DD)
Funktioniert den die Umschaltung von 300 Baud auf 9600 Baud.
Pejonp
Meinst Du technisch? Also egal ob ich 300 oder 9600 einstelle, es kommen keine Daten außer bei der Definition: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0@9600,7,E,1 VSM102
020.03.26 11:21:52 5: OBIS (STROM) - Opening device...
2020.03.26 11:21:52 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.03.26 11:21:52 3: Setting STROM serial parameters to 9600,7,E,1
2020.03.26 11:21:52 3: Init done
2020.03.26 11:21:52 3: STROM device opened
2020.03.26 11:22:10 5: SW: 2f3f210d0a
2020.03.26 11:22:10 4: Wrote /?!da kommt zumindest ein bissl SW
mit Definition: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0@300,7,E,1 SML
kommt:
2020.06.13 21:25:30 5: OBIS (STROM) - Opening device...
2020.06.13 21:25:30 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.06.13 21:25:30 3: Setting STROM serial parameters to 300,7,E,1
2020.06.13 21:25:30 3: Init done
2020.06.13 21:25:30 3: STROM device opened
2020.06.13 21:25:30 5: OBIS (STROM) - Opening device...
2020.06.13 21:25:30 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.06.13 21:25:30 3: Setting STROM serial parameters to 300,7,E,1
2020.06.13 21:25:30 3: Init done
2020.06.13 21:25:30 3: STROM device openedmit Definition: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0@300,7,E,1 VSM102
kommt:
2020.06.13 21:31:14 5: OBIS (STROM) - Opening device...
2020.06.13 21:31:14 3: Opening STROM device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A105TDRT-if00-port0
2020.06.13 21:31:14 3: Setting STROM serial parameters to 300,7,E,1
2020.06.13 21:31:14 3: Init done
2020.06.13 21:31:14 3: STROM device opened
Ich weiss nicht ob es das Thema schonmal gab, aber ich habe im Keller einen SML-Zähler, den ich nicht direkt an den Raspberry anschliessen kann. Deshalb habe ich über den ESP8266 eine SerialBridge eingebaut. Damit sind die Definitionen übers Netz abholbar. Das klappt auch ganz wundervoll über so eine Definition:
define smlobis 192.168.1.53:23 SML
Allerdings ist meine Netzverbindung in den Keller nicht super stabil (erst WLAN und dann Powerline), deshalb ist die Verbindung regelmässig mal weg. Leider gibt es kein automatisches reconnect und auch kein manuelles. Momentan behelfe ich mir mit einem defmod, dass an verschiedene Bedingungen geknüpft ist (presence und auch ein DOIF auf regelmässige updates). Also zum Beispiel sowas wie
define smlobis_presence:watchdog watchdog smlobis_presence:presence:.present 00:10 smlobis_presence:presence:.absent { my $def = $defs{smlobis }->{DEF}; fhem("defmod smlobis OBIS $def"); }
Es wäre schön wen es ein reconnect gäbe entweder manuell oder automatisch für das Modul also etwas wie
set smlobis reconnect
Hallo zusammen,
ich habe vor einigen Wochen auch eine ModerneMessEinrichtung von meinem Energieversorger bekommen.
Also Lesekopf besorgt, kabel verlegt und grundsaetzlich funktioniert das auch...
Aber:
wenn ich auf polling umstelle und den intervall setze (30 Sekunden) bekomme ich (gefuehlt) nicht mehr die richtige momentane Leistungs angezeigt.
(Ich habe zum Test den Siebtraeger angeschaltet, mit rund 1,5kW muesste der schon auffallen.)
Dann habe ich zum Test das Polling ausgeschaltet (aber den Intervall gelassen), das funktioniert auch wie gedacht, allerdings wechselt jetzt die Schnittstelle zwischen "Connected und Disconnected" und schreibt das Logfile voll...
Auch greifen einige der RegExpressions bei dem Model scheinbar nicht...
Readings
1.0.0.0.9.255 09-01-49-53-4B-00-04-75-B9-A5 2020-06-14 16:16:57
129.129.199.130.3.255 ISK 2020-06-14 16:16:57
129.129.199.130.5.255 E014-F16F-ECE9-44E0-6B19-7923-7384-6F19-4F88-18F5-F31E-6A9B-0F76-A317-A586-0983-E523-4F63-2A41-A954-E69C-C481-B6FB-B72D-01 2020-06-14 16:16:57
Version ISK\090149534B000475B9A5 2020-06-14 14:42:11
power 654 2020-06-14 16:16:57
state opened 2020-06-14 16:15:44
total_consumption 199500.6 2020-06-14 16:16:57
total_consumption_Ch1 199500.6 2020-06-14 16:16:57
total_consumption_Ch2 0 2020-06-14 16:16:57
Vielleicht helfen diese Angaben etwas...
Vielen Dank und Gruesse
Michael
Hallo zusammen,
Kurzes Update. Nach einem Update scheint es jetzt zu funktionieren...
Hab das Intervall gesetzt und das Polling wieder deaktiviert...
Viele Grüße Michael
Jetzt hat der Netzbetreiber auch bei mir den Zähler gewechselt. Vorher hatte ich einen eHZ-GW8E2A Zähler von 2009 drin. Mit dem Funktionierte das Auslesen der Daten über Jahre tadellos. Jetzt habe ich einen ISKRA eHZ-EDL Type MT681 eingebaut bekommen. Alles was der Zähler jetzt noch anzeigt sind die aufgelaufenen Leistungsdaten des Verbrauches und der Einspeisung und noch ein paar andere Daten. Die Momentanwerte für Power und "Feed_L1" fehlen. Somit habe ich auch keine Leistungsdaten die zur Steuerung heranziehen könnte.
Habe ich jetzt beim durchforsten des Threads etwas übersehen, was ich noch nachjustieren muss oder liefert der Zähler die Daten schlichtweg einfach nicht? Das wäre sehr ärgerlich. Oder gibt es eine Möglichkeit an die Daten wieder heran zu kommen?
defmod VersorgerZaehler OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_00F31B12-if00-port0@9600 SML
attr VersorgerZaehler icon measure_power
attr VersorgerZaehler interval 300
attr VersorgerZaehler pollingMode on
attr VersorgerZaehler room 3.10_Zaehler
attr VersorgerZaehler stateFormat {\
if(ReadingsVal("VersorgerZaehler","differenz",0) < 0) {\
"<div style='color:green'>". sprintf("%.1f",ReadingsVal("VersorgerZaehler","differenz",0)) . " W</div>"\
} else {\
"<div style='color:red'>". sprintf("%.1f",ReadingsVal("VersorgerZaehler","differenz",0)) . " W</div>"\
}\
}\
attr VersorgerZaehler userReadings color { (ReadingsVal("VersorgerZaehler","differenz","?") > 0) ? "#ad3333":"#3aab2c";;},\
differenz {sprintf("%.0f",ReadingsVal("VersorgerZaehler","power","?")-ReadingsVal("VersorgerZaehler","feed_L1","?"))}
attr VersorgerZaehler verbose 0
setstate VersorgerZaehler <div style='color:green'>-2862.0 W</div>
setstate VersorgerZaehler 2020-06-22 15:39:11 0.0.96.1.255.255 2253830
setstate VersorgerZaehler 2020-06-22 15:39:11 1.0.0.0.0.255 39-30-30-36-39-36-38-31
setstate VersorgerZaehler 2020-06-22 17:39:07 1.0.0.0.9.255 09-01-49-53-4B-00-04-75-34-55
setstate VersorgerZaehler 2020-06-22 17:39:07 129.129.199.130.3.255 ISK
setstate VersorgerZaehler 2020-06-22 17:39:07 129.129.199.130.5.255 C338-4D09-59DA-BDDA-1037-FED9-9814-7581-B5C7-FB62-EB39-077C-F39F-C283-D227-B536-C80A-5C20-F493-F564-D61E-3292-A2E8-BF8D-01
setstate VersorgerZaehler 2020-06-22 15:43:39 Version ISK\090149534B0004753455
setstate VersorgerZaehler 2020-06-22 17:39:07 color #3aab2c
setstate VersorgerZaehler 2020-06-22 17:39:07 differenz -2862
setstate VersorgerZaehler 2020-06-22 15:39:11 feed_L1 2861.6
setstate VersorgerZaehler 2020-06-22 15:39:11 power 0
setstate VersorgerZaehler 2020-06-22 17:20:47 state opened
setstate VersorgerZaehler 2020-06-22 17:39:07 total_consumption 0
setstate VersorgerZaehler 2020-06-22 17:39:07 total_consumption_Ch1 0
setstate VersorgerZaehler 2020-06-22 17:39:07 total_consumption_Ch2 0
setstate VersorgerZaehler 2020-06-22 17:39:07 total_feed 2000
setstate VersorgerZaehler 2020-06-22 17:39:07 total_feed_Ch1 2000
setstate VersorgerZaehler 2020-06-22 17:39:07 total_feed_Ch2 0
Und hier noch ein aktuelles Log.
2020.06.22 17:28:06 5: OBIS (VersorgerZaehler) - Internal timer set to 2020-06-22 17:28:36
2020.06.22 17:28:11 5: SML-Parse 1B1B1B1B0101010176050000402A620062007263010176010105000015640B090149534B0004753455010163A2AB0076050000402B620062007263070177010B090149534B0004753455070100620AFFFF72620165000019657977078181C78203FF010101010449534B0177070100000009FF010101010B090149534B00047534550177070100010800FF65000101A001621E52036900000000000000000177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Full message-> 1B1B1B1B0101010176050000402A620062007263010176010105000015640B090149534B0004753455010163A2AB0076050000402B620062007263070177010B090149534B0004753455070100620AFFFF72620165000019657977078181C78203FF010101010449534B0177070100000009FF010101010B090149534B00047534550177070100010800FF65000101A001621E52036900000000000000000177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=1B1B1B1B0101010176050000402A620062007263010176010105000015640B090149534B0004753455010163A2AB0076050000402B620062007263070177010B090149534B0004753455070100620AFFFF72620165000019657977078181C78203FF010101010449534B0177070100000009FF010101010B090149534B00047534550177070100010800FF65000101A001621E52036900000000000000000177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100000009FF010101010B090149534B00047534550177070100010800FF65000101A001621E52036900000000000000000177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100010800FF65000101A001621E52036900000000000000000177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100010801FF0101621E52036900000000000000000177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100010802FF0101621E52036900000000000000000177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100020800FF0101621E52036900000000000000020177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100020801FF0101621E52036900000000000000020177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177070100020802FF0101621E52036900000000000000000177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 5: OBIS: Telegram=0177078181C78205FF010101018302C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01010163BAD70076050000402C62006200726302017101630E4F001B1B1B1B1A00EAF9
2020.06.22 17:28:11 4: MSG IS:
/ISK\090149534B0004753455
129-129:199.130.3*255(ISK)
1-0:0.0.9*255(090149534B0004753455)
1-0:1.8.0*255(0*Wh)
1-0:1.8.1*255(0*Wh)
1-0:1.8.2*255(0*Wh)
1-0:2.8.0*255(2000*Wh)
1-0:2.8.1*255(2000*Wh)
1-0:2.8.2*255(0*Wh)
129-129:199.130.5*255(C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01)
!
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: /ISK\090149534B0004753455
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 129-129:199.130.3*255(ISK)
2020.06.22 17:28:11 5: Msg 129-129:199.130.3*255(ISK) is of type ManufID
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:0.0.9*255(090149534B0004753455)
2020.06.22 17:28:11 5: Msg 1-0:0.0.9*255(090149534B0004753455) is of type Serial
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:1.8.0*255(0*Wh)
2020.06.22 17:28:11 5: Msg 1-0:1.8.0*255(0*Wh) is of type Counter
2020.06.22 17:28:11 4: Set total_consumption to 0
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2020.06.22 17:28:11 5: Msg 1-0:1.8.1*255(0*Wh) is of type Counter
2020.06.22 17:28:11 4: Set total_consumption_Ch1 to 0
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2020.06.22 17:28:11 5: Msg 1-0:1.8.2*255(0*Wh) is of type Counter
2020.06.22 17:28:11 4: Set total_consumption_Ch2 to 0
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:2.8.0*255(2000*Wh)
2020.06.22 17:28:11 5: Msg 1-0:2.8.0*255(2000*Wh) is of type Counter
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:2.8.1*255(2000*Wh)
2020.06.22 17:28:11 5: Msg 1-0:2.8.1*255(2000*Wh) is of type Counter
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 1-0:2.8.2*255(0*Wh)
2020.06.22 17:28:11 5: Msg 1-0:2.8.2*255(0*Wh) is of type Counter
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: 129-129:199.130.5*255(C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01)
2020.06.22 17:28:11 5: Msg 129-129:199.130.5*255(C3384D0959DABDDA1037FED998147581B5C7FB62EB39077CF39FC283D227B536C80A5C20F493F564D61E3292A2E8BF8D01) is of type PublicKey
2020.06.22 17:28:11 5: OBIS (VersorgerZaehler) - Msg-Parse: !
ZitatHabe ich jetzt beim durchforsten des Threads etwas übersehen, was ich noch nachjustieren muss oder liefert der Zähler die Daten schlichtweg einfach nicht? Das wäre sehr ärgerlich.
So wird es leider sein. :'(
ZitatOder gibt es eine Möglichkeit an die Daten wieder heran zu kommen?
Evtl. lässt sich über die Eingabe einer Pin mehr herausholen. Die müsstest Du bei Deinem Msb erfragen.
Ich nehme an Du hast einen IR-Kopf auf der vorderen Kundenschnittstelle ? Die hintere(verdeckt/verplombt) liefert oft weitere Daten. Aber dafür müsste Dir der Msb den Einbau dort erlauben.
Grüße Markus
Zitat von: KölnSolar am 22 Juni 2020, 18:11:43
So wird es leider sein. :'(
Das wäre großer Mist. Ein hoch auf den technischen Fortschritt! :(
Zitat von: KölnSolar am 22 Juni 2020, 18:11:43
Ich nehme an Du hast einen IR-Kopf auf der vorderen Kundenschnittstelle ?
Ja die habe ich wieder vorn drauf. An der gleichen Position wie bei dem Alten.
Also muss erst einmal die PIN her.
@majorshark: Ich habe zwar keinen MT681 aber einen anderen ISKRA-Zähler. Ich habe mir die PIN vom Versorger besorgt und seitdem sendet mein Zähler zumindest aktuelle Verbrauchsinfo und genauere Verbrauchssumme.
Bei meinem Versorger gab es dafür ein Formular dass man elektronisch senden konnte - die Eingabe per Taste und Taschenlampe ist zwar etwas nervig aber muss ja nicht dauernd gemacht werden
Zitat von: viegener am 22 Juni 2020, 18:47:07
Bei meinem Versorger gab es dafür ein Formular dass man elektronisch senden konnte - die Eingabe per Taste und Taschenlampe ist zwar etwas nervig aber muss ja nicht dauernd gemacht werden
Hmm ... also bei meinem Zähler steht in der Betriebsanleitung das ich das nach jedem Stromausfall machen darf. :(
Zitat von: AxelSchweiss am 22 Juni 2020, 18:56:49
Hmm ... also bei meinem Zähler steht in der Betriebsanleitung das ich das nach jedem Stromausfall machen darf. :(
Auf der suche nach der PIN Eingabe habe ich folgendes Video gefunden. Der Autor gibt darin auch hinweise wie Einstellungen dauerhaft gespeichert bleiben. Ein Versuch ist's Wert.
https://www.youtube.com/watch?v=TonPnmOtBM0 (https://www.youtube.com/watch?v=TonPnmOtBM0)
So, meine Probleme nach dem Zählerwechsel sind erledigt. Ich musste den persönlichen Aktivierungscode für den Zähler von meinen Messtellenbetreiber erfragen. Dann konnte ich im Einstellungsmenü von IEC 61107 auf SML umstellen. Außerdem musste ich noch die Protokolleinstellungen von @9600,7,E,1 SML auf @9600,8,N,1 SML ändern.
Jetzt kommen endlich wieder Daten vom Zähler. Vielleicht wäre die mögliche Notwendigkeit des Aktivierungsvorgangs und die Änderung der Protokolleinstellung eine Aufnahme in die Modulbeschreibung / Wiki wert.
VG, Stephan
Was ich mir für das Modul wünschen würde wäre eine Aktivierungsfunktion.
Konkret :
Wenn das Modul feststellt das n Minuten lang keine Daten bzw. keine vernüftigen Daten mehr ankommen wird die übertragung des Blinkcodes für die PIN und die Einstellungen ausgelöst.
Daraufhin sendet die IR-Sende-Diode dann die Blinkcodes und alles ist wieder schick.
Das sollte mit einem SchreibLeseKopf wie dem hier:
http://adl517.at/index.php/seitenmenue/25-zaehler-lesekopf (http://adl517.at/index.php/seitenmenue/25-zaehler-lesekopf)
eigentlich funktionieren.
Vorausgesetzt man hat nur eine Ser2Net Firmware a la ESPEasy drauf.
Das habe ich auch schon überlegt. Es würde ja reichen wenn man einfache Sequenzen über den Schreib/Lesekopf dem Zähler morsen könnte. Da braucht man nicht mit der Taschenlampe herum zu fummeln.
Ja genau.
Entweder manuell ausgelöst oder wenn Attribute im Datenstrom fehlen.
Zum Beispiel wird nur der Gesamverbrauch übermittelt aber der Sekundenwert fehlt. Und das für mehrere Minuten um Übertragungsfehler auszuschliesen.
So würde sich mein Zähler nach einem Stromausfall verhalten.
Dann könnte man eine Sequenz an das Modul analog dem guten alten Hays-Standard übermittel "1,,1,1,0" ;D
1 wäre Licht an/aus und das Komma bedeutet 1 Sekunde warten. Die Null ist dann das Ende der Sequenz.
Damit kannst du dann die PIN eingeben und durch die Untermenüs hüpfen.
Konfigurierbar müsste die zu überwachende Datensequenz, die Dauer des ausbleibens und die zu übermittelnde Blink-Sequenz sein.
Patches werden gerne entgegengenommen ^^
Da fängst schon an ... ich kann nicht programmieren ... :)
Ansonsten hätte ich das schon gemacht.
Aber ich könnte testen, Doku schreiben und so.
Die Baudratenumschaltung kann ich gerne testen.
Der AS1440 kann mit 2 Inititialisierungen umgehen. Einmal mit der Definition AS1440 ("/2!") oder mit VSM102 ("/?!") . Der Unterschied ist, das mit der Variante AS1440 nur minimale Werte ausgegeben werden und nicht die gesamten Vorwerte. Siehe dazu:
https://forum.fhem.de/index.php/topic,51948.msg743749/topicseen.html#msg743749 (https://forum.fhem.de/index.php/topic,51948.msg743749/topicseen.html#msg743749)
Die Baudratenumschaltung beim AS1440 mit der von Icinger weiterentwickelten 47_OBIS.pm Arbeitsversion (die er auf PN Anforderung zur Verfügung gestellt hat) funktioniert nun bei mir.
Entscheidend war, die alte device Definition
defmod E_Zaehler OBIS /dev/ttyUSB2@300,7,E,1 AS1440
nicht etwa durch
defmod E_Zaehler OBIS /dev/ttyUSB2@9600,7,E,1 AS1440
sondern durch
defmod E_Zaehler OBIS /dev/ttyUSB2@300,7,E,1 AS1440 9600
zu ersetzen.
-Franz
Leider muss ich die Erfolgsmeldung stark einschränken: lässt man es über längere Zeit laufen, hängt sich das ganze irgendwann auf.
Es liegt vermutlich am 'zickigen' Verhalten des AS1440. Diese 'Zickigkeit' wurde auch hier https://forum.fhem.de/index.php/topic,107045.msg1008941.html#msg1008941 beschrieben und hat dem dortigen Autor anscheinend eine Menge Aufwand abverlangt bis seine Lösung stabil war
Hi
Lässt sichbei dem Modul noch ein "Reconnect" integrieren ?
Ich habe das Problem das ab und an die Verbindung stirbt.
Aktuell löse ich das damit das ich den Port ändere und dann wieder richtig einstelle.
Ist aber nicht schön.
Zitat von: AxelSchweiss am 14 Juli 2020, 19:43:50
Hi
Lässt sichbei dem Modul noch ein "Reconnect" integrieren ?
Ich habe das Problem das ab und an die Verbindung stirbt.
Aktuell löse ich das damit das ich den Port ändere und dann wieder richtig einstelle.
Ist aber nicht schön.
Genau mein Problem - wie auch schon vor einiger Zeit mal angefragt...
(DU musst aber nicht den Port ändern ein defmod mit aktueller Definition hilft bei mir)
Ein reconnect / connect wäre toll...
Zitat von: viegener am 16 Juli 2020, 13:34:06
Genau mein Problem - wie auch schon vor einiger Zeit mal angefragt...
(DU musst aber nicht den Port ändern ein defmod mit aktueller Definition hilft bei mir)
Ein reconnect / connect wäre toll...
Dito. Auch bei mir stirbt alle 2-3 Tage die Verbindung. Bisher habe ich immer FHEM neu gestartet, was sehr umständlich ist.
Das Modul selbst meldet CRC_Errors 16 und folgende Ausgabe, wenn ich auf TYPE OBIS klicke:
CRC_Errors 16
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04JPL7-if00-port0 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04JPL7-if00-port0
FUUID 5c6c3e35-f33f-68c5-c801-596e3759f5738101
MeterType SML
NAME Stromzaehler
NR 274
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
logdb:
TIME 1595357327.71979
VALUE 324
READINGS:
2020-07-21 20:48:47 1.0.0.0.9.255 09-01-49-53-4B-00-04-31-A8-B6
2020-07-21 20:48:47 129.129.199.130.3.255 ISK
2020-07-21 20:48:47 129.129.199.130.5.255 B01F-40FB-D83E-7380-E263-DE68-40ED-00DC-7BB2-157C-4A20-C86A-85E7-8FEA-4220-E96C-A050-166E-C6B4-AE85-F489-B134-9C4D-2916-01
2020-06-09 02:47:28 Version ISK\090149534B000431A8B6
2020-07-21 20:48:47 power 324
2020-06-08 23:56:20 state opened
2020-07-21 20:48:47 total_consumption 5828654.1
2020-07-21 20:48:47 total_consumption_Ch1 5828654.1
2020-07-21 20:48:47 total_consumption_Ch2 0
helper:
BUFFER RU�v�U&bbrcv�q� ISKv�U*bbrcw ISK��v�U,bbrcv�q� ISKuv�U/bbrcv�q� ISKѮw�b R�Yw�bRUѮ w�b R�Yw�bRUѮ1w�b R�Yw�bRUv�USbbrcv�q� ISK%!v�UYbbrcv�q� ISKѮIw�b R�Yw�bRUѮUw�b R�Yw�bRUѮYw�b R�Yw�bRUѮ]w�b R�Yw�bRU�v�Uwbbrcv�q� ISK.=v�Uzbbrcv�q� ISKxpv�U�bbrcv�q� ISK�Ѯ�w�b R�Yw�bRUk{v�U�bbrcv�q� ISKѮ�w�b R�Yw�bRUѮ�w�b R�Yw�bRU�^v�U�bbrcv�q� ISKѮ�w�b R�Yw�bRUѮ�w�b R�Yw�bRU�.�v�U�bbrcv�q� ISKѮ�w�b R�Yw�bRUѮ�w�b R�Yw�bRU�lnv�U�bbrcv�q� ISKѮ�w�b R�Yw�bRUѮ�w�b R�Yw�bRUѮ�w�b R�Yw�bRU�Ѯ�w�b R�Yw�bRUѮ�w�b R�Yw�bRU�Ѯ�w�b R�Yw�bRU��Ѯ�w�b R�Yw�bRU��ѯw�b R�Yw�bRU�ѯw�b R�Yw�bRU��v�U�bbrcv�q� ISKѯ w�b R�Yw�bRUѯ!w�b R�Yw�bRUK�v�V
-�v�V
�Mbbrcv�r
�v�V(bbrcv�r ISK��v�V1bbrcv�r ISK���v�V7bbrcv�r ISK�) v�VXbbrcv�r �؏v�Vabbrcv�r! ISK;�v�Vgbbrcv�r# ISK��$v�Vybbrcv�r) ISK�v�V�bbrcv�r/ ISK�v�V�bbrcw ISK���ًv�V�bbrcv�r: ISKM�v�V�bbrcv�r< ISK��v�V�bbrcv�r= ISKΪv�V�bbrcv�r? ISKI�v�V�bbrcv�rA ISKJv�V�bbrcv�rD ISK��v�V�bbrcv�rE ISKl�v�V�bbrcv�rF ISK���Rv�V�bbrcv�rN ISK��Rv�V�bbrcv�rT ISK�Jv�W bbrcv�rZ ISK@~v�Wbbrcv�r\ ISK�<�v�W*bbrcv�rd ISK�v�W?bbrcv�rk ISKH�v�WBbb7Nv�WEbbrcv�rm ISK �v�WQbbrcv�rq ISK�~�v�Wcbbrcv�rw ISK�v�Wlbbrcv�rz ISK��'�v�W�bbrcv�r� ISKj�v�W�bbrcv�r� ISK�]v�W�bbrcv�r� ISKdxv�W�bbrcv�r� ISK���v�W�bbrcv�r� ISKF�v�W�bbrcv�r� ISK��v�W�bbrcv�r� ISK���v�W�bbrcv�r� ISK�Gv�W�bbrcv�r� ISK�_v�W�bbrcv�r� ISK��4�v�Xbbrcv�r� ISK�Ѱ�w�b R�Yw�bRU�bbrcv�r� ISK7 v�X bbrcv�r� ISKѰ�w�b R�Yw�bRUCv�X bbrcv�r� ISKѱw�b R�Yw�bRUѱw�b R�Yw�bRUѱ
���v�X8bbrcv�r� ISKѱ"w�b R�Yw�bRU��v�X>bbrcv�r� ISKѱ*w�b R�Yw�bRU�ѱBw�b R�Yw�bRUE�v�XVbbrcv�r� ISKѱJw�b R�Yw�bRUmov�X\bbrcv�r� ISKv�Xbbbrcv�r� ISK� v�Xhbbrcv�r� ISK��Sv�Xqbbrcv�r� ISK �v�Xzbbrcv�r� ISK�� Mv�X�bbrcv�r� ISK��iv�X�bbrcv�r� ISK��ev�X�bbrcv�r� ISK��v�X�bbrcv�r� ISKӻv�X�bbrcv�r� ISKѲ%w�b R�Yw�bRUѲ=w�b R�Yw�bRU��v�X�bbrcv�r� ISKѲAw�b R�Yw�bRUѲEw�b R�Yw�bRUѲIw�b R�Yw�bRU��v�X�bbrcv�r� ISK�v�X�bbrcv�r� ISK��v�X�bbrcv�r� ISK�Ѳiw�b R�Yw�bRU�Ѳqw�b R�Yw�bRUD#v�X�bbrcv�r� ISKѲuw�b R�Yw�bRU��,�v�Ybbrcv�s ISKѲ�w�b R�Yw�bRUѲ�w�b R�Yw�bRUѲ�w�b R�Yw�bRU)�v�Y bbrcv�s ISKѲ�w�b R�Yw�bRU��v�Y"bbrcv�s ISK�l�v�Y1bbrcv�s ISK� ISKuov�YCbbrcv ISKѲ�w�b R�Yw�bRUѲ�w�b R�Yw�bRU0Ѳ�w�b R�Yw�bRUѲ�w�b R�Yw�bRUáv�Yabbrcv�s! ISKѳw�b R�Yw�bRUv�Yqbbrcw ISK�
ѳ w�b R�Yw�bRU��v�Y�bbrcv�s, ISK�ѳ1w�b R�Yw�bRU�ѳ9w�b R�Yw�bRU��v�Y�bbrcv�s0 ISK�v�Y�bbrcv�s1 ISKوv�Y�bbrcv�s8 ISK��v�Y�bbrcv�s; ISKѳuw�b R�Yw�bRU�ѳ}w�b R�Yw�bRUѳ�w�b R�Yw�bRUVv�Y�bbrcv�sE ISKѳ�w�b R�Yw�bRU�
ѳ�w�b R�Yw�bRU�
v�Y�bbrcv�sH ISKѳ�w�b R�Yw�bRU���{v�Y�bbrcv�sQ ISKѳ�w�b R�Yw�bRUѳ�w�b R�Yw�bRUѳ�w�b R�Yw�bRUѳ�w�b R�Yw�bRUѴw�b R�Yw�bRUѴw�b R�Yw�bRUѴw�b R�Yw�bRUѴ w�b R�Yw�bRUѴ%w�b R�Yw�bRU�v�ZBbbrcv�sl ISK�Ѵ-w�b R�Yw�bRU�
v�ZHbbrcv�sn ISK��v�ZTbbrcv�sr ISKv�ZZbbrcv�st ISK��v�Z`bbrcv�sv ISKv�Zcbbrcv�sw ISKϡv�Zfbbrcv�sx ISK
Ѵ�w�b R�Yw�bRUѴ�w�b R�Yw�bRUE�v�Z�bbrcv�s� ISK�|J �j���B �l�Pnƴ���4�M)cYѴ�w�b R�Yw�bRU�Ѵ�w�b R�Yw�bRUѴ�w�b R�Yw�bRU9�v�Z�bbrcv�s� ISKѴ�w�b R�Yw�bRU
���v�Z�bbrcv�s� ISK��v�Z�bbrcv�s� ISKѴ�w�b R�Yw�bRU��v�Z�bbrcv�s� ISK��)
|J �j���B �l�Pnƴ���4�M)c��u�vbbrcv�s� ISK�2�v�[,bbrcv�s� ISK����v�[;bbrcv�s� ISK�cRv�[hbbrcv�s� ISK��)�v�[�bbrcv�s� ISK�|J �j���B �l�Pnƴ���4�M)cG
T�v�[�bbrcv�s� ISK�v�[�bbrcv�s� ISK\#v�[�bbrcv�s� ISK�Cv�[�bbrcv�s� ISKP�v�[�bbrcv�s� ISK-Dyv�[�bbrcv�s� ISK������ ISK��v�\@bbrcv�t ISK�[v�\Cbbrcv ISK2�v�\Fbbrcv�t ISK
�v�\Obbrcv�t ISK ISK�
�,v�\pbbrcv�t& ISK���������Ѹ
|J �j���B �l�Pnƴ���4�M)cx
o�v�\�bbrcv�tH ISKm�v�\�bbrcv�tR ISKv�v�\�bbrcv�tT ISK�.v�\�bbrcv�tU ISK��������_v�]?bbrcv�tk ISK���#v�]]bbrcv�tu ISK2�v�]xbbrcv�t~ ISKG�v�^bbrcv�t� ISK|J �j���B �l�Pnƴ���4�M)c-�v�^bbrcv�t� ISK�[v�^,bbrcv�t� ISK�zv�^Abbrcv�t� ISKL�v�^Jbbrcv�t� ISK���gv�^hbbrcv�t� ISK���v�^nbbrcv�t� ISK��v�^}bbrcv�t� ISK%v�^�bbrcv�t� ISK _v�^�bbrcv�t� ISK)'v�^�bbrcv�t� ISK�K�v�^�bbrcv�t� ISK�|v�^�bbrcv�t� ISK��
��xv�^�bbrcv�t� ISK�:�v�^�bbrcv�t� ISK$/v�^�bbrcv�t� ISK��v�^�bbrcv�t� ISK�rv�^�bbrcv�t� ISK|J �j���B �l�Pnƴ���4�M)c�
���
��x2v�_%bbrcv�u
�Vv�_(bbrcv�u ISK�@v�_1bbrcv�u ISK
(�v�_Ubbrcv�u ISKKv�_Xbbrcv�u ISK
EoM -1
SPEED 5
TRIGGERTIME 1591653381.01631
Channels:
total_consumption Verbrauch
DEVICES:
1
directions:
Attributes:
DbLogInclude power
alias Stromzaehler
channels {"total_consumption"=>"Verbrauch"}
event-min-interval 60
interval 1
pollingMode on
room Zähler
verbose 3Hochsetzen vom Verbose auf 5 ergibt für mich keine Aufschlussreichen Ausgaben im Logfile.
Andere USB Adapter (z.B. Vissmann VControl USB Adapter oder die 2 Signalduino) hängen am gleichen Aktiven USB Hub und haben keine Probleme in der Verbindung.
Von daher wäre es genial, wenn das OBIS Modul robuster bzw. um Status und Connect/Disconnect oder reconnect erweitert werden könnte.
Als Zähler habe ich einen Iskra MT175.
Gruß
Stefan
Ich behaupte, dass Eure Problem erst einmal auf der Hardware-Seite zu suchen sind.
Meine beiden USBs haben noch nie die Verbindung verloren. ???
Da ich mir auch das Modul etwas näher angesehen habe, dürfte dort keine Anpassung für reconnect notwendig sein.
Von Interesse wäre, ob pollingmode gesetzt ist. Hier weicht das Modul von "Standard-DevIo" ab. Bei mir laufen beide mit pollingmode=on für pushende Zähler(also wie bei Dir Stefan/luftdieb; Wie läuft das device ohne das Attribut bei Dir ?)
Zitatinterval 1
Sehe ich mal arg kritisch. Was willst Du mit Daten solch feiner zeitlicher Auflösung ? Ich hab 60. Würd ich zumindest mal für die Zeit der Analyse der Ausfälle deutlich höher als 1 setzen.
Grüße Markus
Zitat von: KölnSolar am 26 Juli 2020, 15:48:25
Ich behaupte, dass Eure Problem erst einmal auf der Hardware-Seite zu suchen sind.
Meine beiden USBs haben noch nie die Verbindung verloren. ???
Da ich mir auch das Modul etwas näher angesehen habe, dürfte dort keine Anpassung für reconnect notwendig sein.
Von Interesse wäre, ob pollingmode gesetzt ist. Hier weicht das Modul von "Standard-DevIo" ab. Bei mir laufen beide mit pollingmode=on für pushende Zähler(also wie bei Dir Stefan/luftdieb; Wie läuft das device ohne das Attribut bei Dir ?)
Sehe ich mal arg kritisch. Was willst Du mit Daten solch feiner zeitlicher Auflösung ? Ich hab 60. Würd ich zumindest mal für die Zeit der Analyse der Ausfälle deutlich höher als 1 setzen.
Grüße Markus
Das Problem mit dem Verbindungsverlust - zumindest bei mir hängt damit zusammen, dass dieser eben nicht per usb angeschlossen ist, sondern per Netzwerk - Dazwischen ist Powerline, WLAN und LAN - das verliert schonmal die Verbindung ...
Ja der reconnect müsste sich leicht umsetzen lassen, ich mache momentan ein defmod auf den Device, dabei wird der reconnect ausgeführt
ZitatVon Interesse wäre, ob pollingmode gesetzt ist.
Edit:
ZitatJa der reconnect müsste sich leicht umsetzen lassen, ich mache momentan ein defmod auf den Device
Sollte meines Erachtens aber auch nicht ins Modul, sondern separat, da es ein Hardware-/WLAN-problem scheint. Das Modul macht ja schon den DevIo-Standard-reconnect(es sei denn es gibt noch einen Bug :-\).
Zitat von: KölnSolar am 26 Juli 2020, 22:23:29
Edit: Sollte meines Erachtens aber auch nicht ins Modul, sondern separat, da es ein Hardware-/WLAN-problem scheint. Das Modul macht ja schon den DevIo-Standard-reconnect(es sei denn es gibt noch einen Bug :-\).
Nochmal ein Missverständnis, es geht nicht darum den reconnect automatisch im Modul zu machen, sondern einen reconnect-Befehl zu ermöglichen also so etwas wie
Zitatset <obisdevice> reconnect
Dann müsste man nicht auf defmod zurückgreifen
Bevor hier nochmehr Verwirrung gestiftet wird:
Ich hatte das auch genau hier schonmal erklärt: https://forum.fhem.de/index.php/topic,51948.msg1064241.html#msg1064241 (https://forum.fhem.de/index.php/topic,51948.msg1064241.html#msg1064241)
Also es geht um einen set-Befehl zum reconnect (oder reopen) - diesen könnte man verwenden, wenn durch äussere Einflüsse die Verbindung abbricht - Insbesondere wenn man das Modul für einen remote (also per Netzwerk) angeschlossenen Device am Smartmeter verwendet. Bei mir passieren diese ca. 5 mal am Tag aufgrund der speziellen Gegebenheiten.
Achso: polling mode ist bei mir nicht gesetzt - mir wäre jetzt auch nicht klar, ob polling bei jedem Zähler so funktionieren würde
Das bringt mich aber auch auf eine Alternativlösung -
Zitatdeleteattr <obisdevice> pollingMode
Das sollte ebenfalls die Verbindung neu aufbauen - solange FHEM die AttrFn weiterhin aufruft wenn ein Attribut gar nicht gesetzt ist und auch hier wird leider die Konfiguration als geändert markiert - so dass ein save erforderlich ist.
Ah jetzt, also ist der wichtige Punkt, dass die "Aktion" nicht zu einer "erkannten" Änderung der config führt.
Da kann ich ja jetzt nur noch die Worte des Modulautors zitieren ;)
Zitat von: Icinger am 24 Juni 2020, 20:32:03
Patches werden gerne entgegengenommen ^^
@icinger - gibt es ein github oder ähnlichesRepository - so dass ein pull request möglich ist ? - Patches sind mir zu fehleranfällig - pull requests sind zumesit für Ersteller und Owner viel angenehmer
Hallo,
ich habe vor einige Zeit die 47_OBIS.pm für mich geändert und ein set reopen eingebaut.
Ich hänge einmal den Patch an. Die Änderung läuft bei mir einwandfrei. Sie ist sich nicht perfekt da ich mich in Perl nicht so aus kenne, so wird der set nicht in Fhem web angezeigt.
Mit den at MT175Reconnect wird der Status alle 5 Minuten überprüft und bei bedarf ein reopen ausgeführt.
define MT175Reconnector at +*00:05:00 {\
my $deviceName = "MT175";;\
my $status = ReadingsVal($deviceName,"state",0);;\
if($status ne "opened") { fhem("set " . $deviceName . " reopen");;\
} \
}
Gruß
Klaus
Zitat von: viegener am 27 Juli 2020, 12:33:14
Nochmal ein Missverständnis, es geht nicht darum den reconnect automatisch im Modul zu machen, sondern einen reconnect-Befehl zu ermöglichen also so etwas wieDann müsste man nicht auf defmod zurückgreifen
Das kann man dann ggf. mit solchen Modulen wie DeviceMonitor machen.
Man überwacht ein Reading. Ändert es sich nach X-Minuten nicht führt man den reconnect aus.
Zitat von: KölnSolar am 26 Juli 2020, 15:48:25
Ich behaupte, dass Eure Problem erst einmal auf der Hardware-Seite zu suchen sind.
Meine beiden USBs haben noch nie die Verbindung verloren. ???
Da ich mir auch das Modul etwas näher angesehen habe, dürfte dort keine Anpassung für reconnect notwendig sein.
Von Interesse wäre, ob pollingmode gesetzt ist. Hier weicht das Modul von "Standard-DevIo" ab. Bei mir laufen beide mit pollingmode=on für pushende Zähler(also wie bei Dir Stefan/luftdieb; Wie läuft das device ohne das Attribut bei Dir ?)
Sehe ich mal arg kritisch. Was willst Du mit Daten solch feiner zeitlicher Auflösung ? Ich hab 60. Würd ich zumindest mal für die Zeit der Analyse der Ausfälle deutlich höher als 1 setzen.
Grüße Markus
Hi Markus,
vielen dank für den Tip. Ich habe es gestern ausprobiert mit Interval = 60 und muss leider feststellen, dass es auch nur einen halben Tag überlebt hatte bis das Modul wieder abgeschmiert war mit PollingMode=on.
Habe daraufhin den Tip ausprobiert mit "deleteattr Stromzaehler pollingMode". Daraufhin wurde die Übertragung wieder gestartet. Irgendwie sehr eigenartig. Erneut war auch kein Eintrag im Logfile zu sehen (Verbose 3).
Setze ich Verbose = 4, wird mein Logfile "zugemüllt"...
Interessant ist der Vergleich vom Buffer, jetzt im funktionsfähigen Zustand
ZitatInternals:
CRC_Errors 1
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04JPL7-if00-port0 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04JPL7-if00-port0
FUUID 5c6c3e35-f33f-68c5-c801-596e3759f5738101
MeterType SML
NAME Stromzaehler
NR 274
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
logdb:
TIME 1595870583.81038
VALUE 467
READINGS:
2020-07-27 19:23:03 1.0.0.0.9.255 09-01-49-53-4B-00-04-31-A8-B6
2020-07-27 19:23:03 129.129.199.130.3.255 ISK
2020-07-27 19:23:03 129.129.199.130.5.255 B01F-40FB-D83E-7380-E263-DE68-40ED-00DC-7BB2-157C-4A20-C86A-85E7-8FEA-4220-E96C-A050-166E-C6B4-AE85-F489-B134-9C4D-2916-01
2020-06-09 02:47:28 Version ISK\090149534B000431A8B6
2020-07-27 19:23:03 power 467
2020-07-27 19:17:04 state opened
2020-07-27 19:23:03 total_consumption 6427678.1
2020-07-27 19:23:03 total_consumption_Ch1 6427678.1
2020-07-27 19:23:03 total_consumption_Ch2 0
helper:
BUFFER ��/w�b R�Y��/w�b R�Yw�bRU�w��ǂ��� @��>s��c�h@��{�|J �j���B �l�Pnƴ���4�M)c��v�e�bbrcqc�fD�
EoM -1
SPEED 5
TRIGGERTIME 1595870277.48354
Channels:
total_consumption Verbrauch
DEVICES:
1
directions:
Attributes:
DbLogInclude power
alias Stromzaehler
channels {"total_consumption"=>"Verbrauch"}
comment Zählertyp: Iskra MT175
event-min-interval 60
interval 1
pollingMode on
room Zähler
verbose 4
Ich teste jetzt noch mal Interval = 60 und gelöschtem Attr PollingMode.
Generell wollte ich schon den Interval wieder auf 1 setzen, um eine Art Live Stromanzeige zu haben.
Weiterhin werde ich den Patch von trebron106 mit der Möglichkeit von reopen mal austesten. Klingt für mich nach dem, was ich gesucht habe ;-)
Gruß
Stefan
Hi Stefan,
setzt Du das freezemon-Modul ein ? Das würde Dir vermutlich die Augen öffnen wg. der Sek. interval. Mach vielleicht wenigstens 5 oder 3.
Du bist meines Wissens bisher der Erste, der mit einem Serial-USB-device diese Probleme hat. Siehst Du die Ausfälle mit dmesg ? Ändert sich der state(connected/disconnected) ?
(Ich müßte mal ausprobieren wie es sich bei mir bei einem provozierten disconnect verhält)
Vielleicht noch kurz zum pollingmode: wir haben uns bei pushenden Zählern in den Geburtsstunden des Moduls über extreme Performanceprobleme(hohe CPU-Auslastung) beklagt. Das hat Icinger dann wohl durch Außerkraftsetzen(ausklinken aus der Selectlist) des Standard-Verhaltens eines DevIo-devices gelöst.
Grüße Markus
Hallo,
ich bin mal so frei und verweise auf diese Meldung hin (https://forum.fhem.de/index.php/topic,111853.0.html).
Es wäre schön, wenn dies mit korrigiert wird.
Mfg
Hallo,
ich wollte noch mal eine Rückmeldung geben bezüglich der Abstürze. Nachdem ich mit "deleteattr Stromzaehler pollingMode" den Eintrag gelöscht habe und den Interval auf 5 Sekunden eingestellt habe, läuft das Modul seit 4 Tagen. Solange hatte es bisher nicht durchgehalten.
Mit dem Modul freezemon sehe ich vom Zählermodul keinerlei EInträge. Auch wenn ich den INtervall auf 1 reduziere. Lediglich mein OneWire Baustein sorgt zuverlässig für Einträge ;-(
Gruß
Stefan
Hallo,
habe das Modul jetzt seit einigen Tagen am laufen. Habe zwei Zähler über Netzwerk angebunden, einen über Lan (X-Port) und einen über WLAN (NodeMCU mit ESPEasy und ser2NET).
Es funktioniert alles einwandfrei bis zu einem Fhem-Neustart. Dann stehen beide Zähler auf Status "opened". Ich muss dann bei Beiden einmal das "Def" aufrufen und mit "modify" bestätigen, dann ist die Verbindung sofort wieder da. Ich meine, hier im Thread schon von dem Problem gelesen zu haben, gibt es inzwischen eine Lösung dafür ?
Gruß Thomas
Hat jemand erfolgreich einen Kamstrup Omnipower verbunden und kann mir die Parameter nennen?
Gerüchteweise muss man den mit 300baud schreiben und 1200baud lesen. Geht das mit diesem Modul?
Grüsse
Lothar
Hallo zusammen,
ich habe Fragen bezüglich des Moduls.
Ich habe einen Zaehler von EMH.
Der USB-IR-Leser ist angeschlossen und hat auch bereits einmal Readings ausgegeben. Allerdings nur den Gesamtstand des Zählers.
1.
Ich habe bei dem Zähler auch die PIN eingegeben, sodass dieser mir auf dem Display den aktuellen Verbrauch anzeigt.
Leider sehe ich diesen Verbrauch nicht in den Readings. Hat jemand von euch eine Idee, woran das liegen könnte?
2. In meinem Device springt der State immer zwischen disconnected und opened hin und her und erzeugt damit jede Menge Log-Einträge. Hat jemand eine Ahnung, was hier der Grund für sein könnte?
Spontan würde ich sagen, dass der Lesekopf nicht richtig sitzt.
Bei mir war die Ursache, das die Versorgungsspannung die ich über USB vom Raspi kam zu klein war. (zu viel USB Last am Raspi)
Ich habe den Lesekopf dann extra versorgt. Vielleicht liegs ja an Sowas.
Gruß
Norbert
Das mit der Spannungsversorung könnte sein, ich nutze da zur Zeit einen Rasperry PI 1. Ich probiere das mal mit nem anderen Raspi oder einem Powered USB Hub.
Meine zweite Frage konnte ich mir selbst beantworten.
Beim EMH muss man neben der PIN auch den Parameter Info von off auf on stellen.
Dann sollten auch weitere Daten, wie z.B. aktueller Verbrauch ausgegeben werden.
Edit: Bei mir gehts jetzt auch.
An meinem alten Raspberry PI 1 ging es nicht, auch nicht mit zusätzlicher Spannungsversorgung.
Am Raspberry Pi 4 läuft's wie geschmiert, auch wenn es overkill ist.
Hallo,
ich habe das Modul seit ca. 3 Wochen mit einem SGM-C4-4A920L am laufen. Es gib immer mal wieder ein paar Fehlermeldungen im Log. Aber im großen und ganzen hat es gut funktioniert. Bis heute gegen 19:00 Uhr. Seitdem werden total_consumption und total_feed nicht mehr aktualisiert. Mit verbose=5 ist folgendes im Log zu sehen:
2020.09.15 21:19:28 5: OBIS (PowerMeter) - Internal timer set to 2020-09-15 21:19:58
2020.09.15 21:19:29 5: SML-Parse 1B1B1B1B010101017605006D0F7B6200620072630101760107FFFFFFFFFFFF0500245A7F0B0A014546522002CD46BC7262016426C53A0163E2E5007605006D0F7C62006200726307017707FFFFFFFFFFFF0B0A014546522002CD46BC070100620AFFFF7262016426C53AF106770701006032010101010101044546520177070100600100FF010101010B0A014546522002CD46BC0177070100010800FF641C00047262016426C53A621E52FF640F57420177070100020800FF017262016426C53A621E52FF641996770177070100100700FF0101621B52005300B60177070100200700FF0101622352FF6308E60177070100340700FF0101622352FF6308D00177070100480700FF0101622352FF6308CF01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Full message-> 1B1B1B1B010101017605006D0F7B6200620072630101760107FFFFFFFFFFFF0500245A7F0B0A014546522002CD46BC7262016426C53A0163E2E5007605006D0F7C62006200726307017707FFFFFFFFFFFF0B0A014546522002CD46BC070100620AFFFF7262016426C53AF106770701006032010101010101044546520177070100600100FF010101010B0A014546522002CD46BC0177070100010800FF641C00047262016426C53A621E52FF640F57420177070100020800FF017262016426C53A621E52FF641996770177070100100700FF0101621B52005300B60177070100200700FF0101622352FF6308E60177070100340700FF0101622352FF6308D00177070100480700FF0101622352FF6308CF01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 787.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (787)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.09.15 21:19:29 1: stacktrace:
2020.09.15 21:19:29 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (793)
2020.09.15 21:19:29 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (324)
2020.09.15 21:19:29 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (430)
2020.09.15 21:19:29 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (254)
2020.09.15 21:19:29 1: main::OBIS_Read called by fhem.pl (3792)
2020.09.15 21:19:29 1: main::CallFn called by fhem.pl (761)
2020.09.15 21:19:29 5: OBIS: Telegram=1B1B1B1B010101017605006D0F7B6200620072630101760107FFFFFFFFFFFF0500245A7F0B0A014546522002CD46BC7262016426C53A0163E2E5007605006D0F7C62006200726307017707FFFFFFFFFFFF0B0A014546522002CD46BC070100620AFFFF7262016426C53AF106770701006032010101010101044546520177070100600100FF010101010B0A014546522002CD46BC0177070100010800FF641C00047262016426C53A621E52FF640F57420177070100020800FF017262016426C53A621E52FF641996770177070100100700FF0101621B52005300B60177070100200700FF0101622352FF6308E60177070100340700FF0101622352FF6308D00177070100480700FF0101622352FF6308CF01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100340700FF0101622352FF6308D00177070100480700FF0101622352FF6308CF01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100480700FF0101622352FF6308CF01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=01770701001F0700FF0101622152FE62120177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100330700FF0101622152FE62600177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100470700FF0101622152FE626B0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100510702FF0101620852005300EC0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100510704FF010162085200530117017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=017707010051070FFF010162085200530121017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=017707010051071AFF01016208520053013201770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=01770701000E0700FF0101622C52FF6301F3017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=01770701006161000001010101030000017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=017707010060320104010101010850312E322E31320177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 5: OBIS: Telegram=0177070100603204040101010103042201010163DAF0007605006D0F7D62006200726302017101634B910000001B1B1B1B1A0207CD
2020.09.15 21:19:29 4: MSG IS:
/
1-0:32.7.0*255(227.8*V)
1-0:52.7.0*255(225.6*V)
1-0:72.7.0*255(225.5*V)
1-0:31.7.0*255(0.18*A)
1-0:51.7.0*255(0.96*A)
1-0:71.7.0*255(1.07*A)
1-0:81.7.1*255(119*var)
1-0:81.7.2*255(236*var)
1-0:81.7.4*255(279*var)
1-0:81.7.15*255(289*var)
1-0:81.7.26*255(306*var)
1-0:14.7.0*255(49.9*Hz)
1-0:0.2.0*255(03.00)
1-0:96.90.2*255(B)
1-0:97.97.0*255()
1-0:96.50.1*255(P1.2.12)
1-0:96.50.4*255(")
!
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: /
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:32.7.0*255(227.8*V)
2020.09.15 21:19:29 5: Msg 1-0:32.7.0*255(227.8*V) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:52.7.0*255(225.6*V)
2020.09.15 21:19:29 5: Msg 1-0:52.7.0*255(225.6*V) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:72.7.0*255(225.5*V)
2020.09.15 21:19:29 5: Msg 1-0:72.7.0*255(225.5*V) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:31.7.0*255(0.18*A)
2020.09.15 21:19:29 5: Msg 1-0:31.7.0*255(0.18*A) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:51.7.0*255(0.96*A)
2020.09.15 21:19:29 5: Msg 1-0:51.7.0*255(0.96*A) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:71.7.0*255(1.07*A)
2020.09.15 21:19:29 5: Msg 1-0:71.7.0*255(1.07*A) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:81.7.1*255(119*var)
2020.09.15 21:19:29 5: Msg 1-0:81.7.1*255(119*var) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:81.7.2*255(236*var)
2020.09.15 21:19:29 5: Msg 1-0:81.7.2*255(236*var) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:81.7.4*255(279*var)
2020.09.15 21:19:29 5: Msg 1-0:81.7.4*255(279*var) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:81.7.15*255(289*var)
2020.09.15 21:19:29 5: Msg 1-0:81.7.15*255(289*var) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:81.7.26*255(306*var)
2020.09.15 21:19:29 5: Msg 1-0:81.7.26*255(306*var) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:14.7.0*255(49.9*Hz)
2020.09.15 21:19:29 5: Msg 1-0:14.7.0*255(49.9*Hz) is of type Channels
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:0.2.0*255(03.00)
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:96.90.2*255(B)
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:97.97.0*255()
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:96.50.1*255(P1.2.12)
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: 1-0:96.50.4*255(")
2020.09.15 21:19:29 5: OBIS (PowerMeter) - Msg-Parse: !
Ich hoffe, das läßt sich irgendwie schnell fixen.
In meiner Verzweiflung habe ich mal folgende 2 Zeilen auskommentiert.
my $OBISmsg="";
my $initstr="/";
# my $OBISid=$msg=~m/7701([0-9A-F]*?)01/g;
Log3 $hash,5,"OBIS: Full message-> $msg";
# (undef,undef,$OBISid,undef)=OBIS_decodeTL($1);
while ($msg =~ m/(7707)([0-9A-F]*)/g) {
my @list=$&=~/(7707)([0-9A-F]{2})([0-9A-F]{2})([0-9A-F]{2})([0-9A-F]{2})([0-9A-F]{2})([0-9A-F]{2})([0-9A-F]*)/g;
Seitdem scheint es wieder zuverlässig zu funktionieren. Ich habe aber keine Ahnung, ob das jetzt nicht andere Probleme verursacht.
Hallo zusammen,
ich habe lange mein eigenes Zeug verwendet, um meinen Zähler auszulesen. Nachdem jetzt einer getauscht und ein anderer neuer dazu kamen, bin ich froh, dieses Modul gefunden zu haben und mir viel Zeit zu sparen.
Mir sind ein paar Kleinigkeiten aufgefallen:
Doku:
Beim Beispiel
e.g.: attr myOBIS channels {"1.0.96.5.5.255"=>"Status","1.0.0.0.0.255"=>"Info","16.7"=>"Verbrauch"}>
ist die Spitze Klammer hinten zuviel. Verwirrt ggf. (weil es bei mir auch nicht gleich richtig funktioniert hat)
Sets, weather to use the value from the first or the second bracket, if applicable. Standard is "second"
Ich hab ernsthaft überlegt, was dieses Modul mit Wetterdaten machen will :)
Technisch:
Ich habe ein Reading
129.129.199.130.5.255
das enthält
DD53-CBE0-60DD-201F-E0A0-C457-797C-274A-04C8-381F-4F78-00C2-1776-1FD4-CB0F-FAAD-CD25-A53B-698E-E416-8224-01B2-2CF3-A65F-01
Wenn ich das Reading mit attr channels umbenenne, ändert sich der Inhalt in
DD53CBE060DD201FE0A0C457797C274A04C8381F4F7800C217761FD4CB0FFAADCD25A53B698EE416822401B22CF3A65F01
Betrifft
1.0.0.0.9.255
genauso. Jetzt kann man sich sicher streiten, welche Darstellung schöner ist - ich würde nur erwarten, dass sie gleich bleibt.
Vielen Danke und weiter so!
Stephan (der jetzt sein Fhem auf OBIS umbaut ;)
Ein wichtigerer Punkt ist mir grade aufgefallen:
Die Values werden bei aktiviertem unitReadings inklusive der Einheit in das Feld Value der DbLog-Datenbank geschrieben.
Wäre es möglich, das zu ändern, dass die Einheiten im Feld unit landen?
Grüße,
Stephan
Zitat von: blueberry63 am 15 Dezember 2019, 11:27:48
Hallo,
kann es sein, dass die Reading-Werte für "state" nicht konsistent sind?
Im Web-Interface sehe ich bei verbundenem Device den Wert "opened" für "STATE" (Internal) und "state" (Reading). Im DBLog ist der Wert für das Reading "state" mit "CONNECTED" zu sehen!?
Ist das Device nicht verbunden, wird im Web-Interface "disconnected" angezeigt, im DBLog dagegen "DISCONNECTED" eingetragen.
Das ist mir auch gerade aufgefallen, als ich ein Überwachungs-DOIF dafür anlegen wollte.
Besteht die Möglichkeit, dass man die State-Anzeige, Reading und/oder Event angleicht?
Vielen Dank.
Habe seit längerem ab und zu folgende Meldung in der Log und wollte das hier mal Mitteilen. Modul tut aber was es soll, bisher.
2020.12.04 08:00:36 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 777.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 793.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 342.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 349.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 350.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 351.
2020.12.04 08:00:36 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 330.
Hab nen optischen Leser an den Zählern:
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE266-if00-port0@9600,8,E,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE266-if00-port0@9600,8,E,1
FUUID 5c61c090-f33f-de9d-41b7-d9608e9cba0e3e71
MeterType SML
NAME Zaehler_HS
NR 24
PARTIAL
STATE ...
TYPE OBIS
Internals:
DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE653-if00-port0@9600,8,E,1 SML
DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE653-if00-port0@9600,8,E,1
FUUID 5c61c091-f33f-de9d-8881-1c123b0761c6f035
MeterType SML
NAME Zaehler_WP
NR 25
PARTIAL
STATE ...
TYPE OBIS
Viele Grüße
Chris
Hallo zusammen,
seit ich meinen PIN im Zähler eingegeben habe und der nun die historischen Daten usw. liefert, wird der Gesamtzähler immer mit mehreren Werten überschrieben.
Wie kann ich das am besten abstellen?
und nochmal eine andere Frage. Was sind das eigentlich für Werte "feed_L1, feed_L2, feed_L3"?
Danke und euch ein schönes Wochenende
2020.12.05 12:45:20.907 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:0.2.0*255(ver.03,432F,20170504)
2020.12.05 12:45:20.923 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:96.90.2*255(0F66)
2020.12.05 12:45:20.955 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:97.97.0*255(00000000)
2020.12.05 12:45:20.956 5: OBIS (OBISStromzaehler) - Msg-Parse: !
2020.12.05 12:45:21.147 5: OBIS (OBISStromzaehler) - Msg-Parse: /LOG5LK13BE803039
2020.12.05 12:45:21.147 5: OBIS (OBISStromzaehler) - Msg-Parse:
2020.12.05 12:45:21.178 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:96.1.0*255(001LOG0065518318)
2020.12.05 12:45:21.211 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*255(000261.4441*kWh)
2020.12.05 12:45:21.212 5: Msg 1-0:1.8.0*255(000261.4441*kWh) is of type Counter
2020.12.05 12:45:21.212 4: Set total_consumption to 261.4441
2020.12.05 12:45:21.259 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:2.8.0*255(000000.0165*kWh)
2020.12.05 12:45:21.260 5: Msg 1-0:2.8.0*255(000000.0165*kWh) is of type Counter
2020.12.05 12:45:21.274 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:16.7.0*255(000377*W)
2020.12.05 12:45:21.274 5: Msg 1-0:16.7.0*255(000377*W) is of type Channels
2020.12.05 12:45:21.307 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:32.7.0*255(228.1*V)
2020.12.05 12:45:21.307 5: Msg 1-0:32.7.0*255(228.1*V) is of type Channels
2020.12.05 12:45:21.338 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:52.7.0*255(225.3*V)
2020.12.05 12:45:21.339 5: Msg 1-0:52.7.0*255(225.3*V) is of type Channels
2020.12.05 12:45:21.355 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:72.7.0*255(226.3*V)
2020.12.05 12:45:21.355 5: Msg 1-0:72.7.0*255(226.3*V) is of type Channels
2020.12.05 12:45:21.387 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:31.7.0*255(000.75*A)
2020.12.05 12:45:21.388 5: Msg 1-0:31.7.0*255(000.75*A) is of type Channels
2020.12.05 12:45:21.418 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:51.7.0*255(001.01*A)
2020.12.05 12:45:21.418 5: Msg 1-0:51.7.0*255(001.01*A) is of type Channels
2020.12.05 12:45:21.450 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:71.7.0*255(001.24*A)
2020.12.05 12:45:21.451 5: Msg 1-0:71.7.0*255(001.24*A) is of type Channels
2020.12.05 12:45:21.467 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:81.7.1*255(121*deg)
2020.12.05 12:45:21.467 5: Msg 1-0:81.7.1*255(121*deg) is of type Channels
2020.12.05 12:45:21.498 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:81.7.2*255(241*deg)
2020.12.05 12:45:21.499 5: Msg 1-0:81.7.2*255(241*deg) is of type Channels
2020.12.05 12:45:21.529 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:81.7.4*255(079*deg)
2020.12.05 12:45:21.530 5: Msg 1-0:81.7.4*255(079*deg) is of type Channels
2020.12.05 12:45:21.562 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:81.7.15*255(054*deg)
2020.12.05 12:45:21.563 5: Msg 1-0:81.7.15*255(054*deg) is of type Channels
2020.12.05 12:45:21.578 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:81.7.26*255(039*deg)
2020.12.05 12:45:21.578 5: Msg 1-0:81.7.26*255(039*deg) is of type Channels
2020.12.05 12:45:21.610 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:14.7.0*255(50.0*Hz)
2020.12.05 12:45:21.611 5: Msg 1-0:14.7.0*255(50.0*Hz) is of type Channels
2020.12.05 12:45:21.642 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*96(00022.3*kWh)
2020.12.05 12:45:21.642 5: Msg 1-0:1.8.0*96(00022.3*kWh) is of type Counter
2020.12.05 12:45:21.643 4: Set total_consumption to 22.3
2020.12.05 12:45:21.673 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*97(00100.7*kWh)
2020.12.05 12:45:21.674 5: Msg 1-0:1.8.0*97(00100.7*kWh) is of type Counter
2020.12.05 12:45:21.674 4: Set total_consumption to 100.7
2020.12.05 12:45:21.706 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*98(00000.0*kWh)
2020.12.05 12:45:21.707 5: Msg 1-0:1.8.0*98(00000.0*kWh) is of type Counter
2020.12.05 12:45:21.707 4: Set total_consumption to 0
2020.12.05 12:45:21.721 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*99(00000.0*kWh)
2020.12.05 12:45:21.722 5: Msg 1-0:1.8.0*99(00000.0*kWh) is of type Counter
2020.12.05 12:45:21.722 4: Set total_consumption to 0
2020.12.05 12:45:21.755 5: OBIS (OBISStromzaehler) - Msg-Parse: 1-0:1.8.0*100(00261.4*kWh)
2020.12.05 12:45:21.756 5: Msg 1-0:1.8.0*100(00261.4*kWh) is of type Counter
2020.12.05 12:45:21.756 4: Set total_consumption to 261.4
Auszug aus DBLog
total_consumption
2020-12-05_12:42:50 261.4
2020-12-05_12:42:51 22.3
2020-12-05_12:42:51 100.7
2020-12-05_12:42:52 0.0
2020-12-05_12:42:52 261.4
2020-12-05_12:43:20 22.3
2020-12-05_12:43:20 100.7
2020-12-05_12:43:21 0.0
2020-12-05_12:43:21 261.4
2020-12-05_12:43:50 22.3
2020-12-05_12:43:50 100.7
2020-12-05_12:43:50 0.0
2020-12-05_12:43:50 261.4
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 8
FUUID 5fb255e5-f33f-4987-9654-921a75f08164bdc2
FVERSION 47_OBIS.pm:0.186010/2019-02-15
MeterType SML
NAME OBISStromzaehler
NR 19
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2020-12-05 06:56:25 0.100 249.4
2020-12-05 02:39:54 0.2.0.255 ver.03,432F,20170504
2020-12-05 07:41:25 0.2.255 0F66
2020-12-05 14:30:50 0.255 50
2020-12-04 13:22:21 0.96 14.5
2020-12-04 22:17:23 0.97 94.7
2020-12-05 02:42:54 0.98 0
2020-12-05 02:51:24 0.99 0
2020-12-05 14:37:51 1.0.0.2.0.255 ver.03,432F,20170504
2020-12-05 14:37:51 1.0.14.7.0.255 50
2020-12-05 09:04:56 1.0.255 001LOG0065518318
2020-12-05 14:37:51 1.0.81.7.1.255 119
2020-12-05 14:37:51 1.0.81.7.15.255 42
2020-12-05 14:37:51 1.0.81.7.2.255 237
2020-12-05 14:37:51 1.0.81.7.26.255 40
2020-12-05 14:37:51 1.0.81.7.4.255 78
2020-12-05 14:37:51 1.0.96.1.0.255 001LOG0065518318
2020-12-05 14:37:51 1.0.96.90.2.255 0F66
2020-12-05 14:37:51 1.0.97.97.0.255 0
2020-12-05 01:43:54 1.255 119
2020-12-05 11:21:42 100 260.3
2020-12-05 14:30:20 14.7.0.255 50
2020-12-05 14:15:50 15.255 40
2020-12-05 11:31:42 2.0.255 ver.03,432F,20170504
2020-12-05 07:40:55 2.255 0F66
2020-12-05 14:19:50 255 52
2020-12-05 02:17:24 26.255 52
2020-12-05 01:36:24 4.255 78
2020-12-05 13:47:50 5.255 39
2020-12-05 09:06:56 6.1.0.255 001LOG0065518318
2020-12-05 06:39:25 6.255 12
2020-12-05 11:42:12 6.90.2.255 0F66
2020-12-05 13:20:50 7.0.255 223.1
2020-12-05 13:57:20 7.1.255 121
2020-12-05 06:06:25 7.15.255 15
2020-12-05 14:03:20 7.2.255 233
2020-12-05 13:58:20 7.26.255 50
2020-12-05 10:23:12 7.4.255 73
2020-12-05 03:26:54 7.97.0.255 0
2020-12-05 10:55:42 8.0.100 259.5
2020-12-05 10:15:00 8.0.255 0.0165
2020-12-05 10:21:42 8.0.96 19.7
2020-12-05 10:56:12 8.0.97 98.5
2020-12-05 06:40:25 8.0.98 0
2020-12-05 07:11:25 8.0.99 0
2020-12-05 10:02:26 81.7.1.255 120
2020-12-05 14:13:20 81.7.15.255 47
2020-12-05 01:52:24 81.7.2.255 239
2020-12-05 14:24:20 81.7.26.255 35
2020-12-05 10:22:42 81.7.4.255 71
2020-12-05 11:42:42 90.2.255 0F66
2020-12-05 10:16:53 96.1.0.255 001LOG0065518318
2020-12-05 11:40:42 96.90.2.255 0F66
2020-12-05 07:48:55 97.0.255 0
2020-12-05 07:20:55 97.97.0.255 0
2020-11-16 11:36:05 Version LOG5LK13BE803039
2020-12-05 14:37:51 current_L1 0.74
2020-12-05 14:37:51 current_L2 1.5
2020-12-05 14:37:51 current_L3 1.35
2020-12-05 13:06:50 feed_L1 231.4
2020-12-05 06:40:55 feed_L2 49.9
2020-12-05 10:18:29 feed_L3 4112
2020-12-05 14:37:51 power 514
2020-12-05 10:19:44 state opened
2020-12-05 14:37:51 total_consumption 262.4
2020-12-05 14:37:51 total_feed 0.0165
2020-12-05 14:37:51 voltage_L1 221.7
2020-12-05 14:37:51 voltage_L2 227.3
2020-12-05 14:37:51 voltage_L3 225.2
helper:
BUFFER
EoM 1
SPEED 5
SPEED2 5
TRIGGERTIME 1607160042.59121
Channels:
DEVICES:
30
directions:
Attributes:
event-on-change-reading .*
interval 30
mqttPublish total_feed|total_consumption:topic={"FHEM/$device/$reading"}
room 04_Verbrauch
verbose 0
Hi,
ich habe nun meinen SmartMeter auch per Lesekopf angeschlossen.
Hätte eine Frage wegen den Hex Werten die nicht übersetzt werden.
Bei mir werden die als DEC angezeigt aber ich finde die Entsprechung in der Anleitung meines Smart Meters nicht.
Ist diese Übersetzung nach DEC sicher korrekt?
Es geht um folgende Werte (power und total_consumption wurden automatisch angepasst) :
1.0.36.7.0.255 0
1.0.56.7.0.255 139
1.0.76.7.0.255 13
1.0.96.50.1.255 EMH
power 152
total_consumption 1168098.1
Die Doku meines Meters sagt:
OBIS-T-Kennzahl Bezeichnung Einrichtungszähler+A Einrichtungszähler-A Zweirichtungszähler+A/-A SaldierenderZähler
01 00 60 32 01 01 Hersteller-Kennung X X X X
01 00 60 01 00 FF Geräte-Identifikation X X X X
01 00 01 08 00 FF Zählwerk positive Wirkenergie, tariflos X X
01 00 02 08 00 FF Zählwerk negative Wirkenergie, tariflos X X X
01 00 10 07 00 FF Aktuelle Momentanwirkleistung (nurim ,,Vollständigen Datensatz") X X X X
Wenn ich da was anschaue sehe ich z.B. Hersteller Kennung laut Doku ist:
01 00 60 32 01 01
In FHEM wird das mit 1.0.96.50.1.255 angezeigt. Das passt doch irgendwie nicht?
Hat jemand eine Idee?
Gruß,
Stefan
Hallo Stefan,
ZitatDas passt doch irgendwie nicht?
Oder zumindest fast ;)
01 00 60 32 01 01 Hersteller-Kennung X X X Xist gleich
1.0.96.50.1.255 EMHHex in Dec umgerechnet(nur bei der letzten Stelle nicht)
demnach
1.0.36.7.0.255 0
1.0.56.7.0.255 139
1.0.76.7.0.255 13
=
01 00 24 07 00 ??
01 00 38 07 00 ??
01 00 4C 07 00 ?? davon passt dann aber nichts auf Deine Beschreibung. :'(
Wenn Du das device mal auf verbose=5 stellt, sieht man auch die Originaldaten u. Interpretation.
Grüße Markus
Ok, dank dir vielmals.
Verbose 5 gibt leider auch nicht mehr her.
Dort kann ich aber sehen wie die Hex zusammen gebaut wird :-)
1-0:96.50.1*255(EMH)
1-0:96.1.0*255(
EMH5)
1-0:1.8.0*255(1173335.8*Wh)
1-0:36.7.0*255(0*W)
1-0:56.7.0*255(170*W)
1-0:76.7.0*255(12*W)
1-0:16.7.0*255(182*W)
Was mir auffällt ist das die 2 unbekannten Werte immer ungefähr die power ergeben:
Hier 170W + 12W = 182W.
Was könnten das für Bestandteile sein?
Dann gibt es noch einen 3ten Watt Wert der immer 0W ist.
Vielleicht hat noch jemand ne Idee?
Gruß,
Stefan
Hi Stefan,
so dargestellt erkennt es ein Blinder mit nem Krückstock. ;D Es sind die Leistungswerte(richtiger: Arbeitswerte) der einzelnen Phasen. 8)
0+170+12=182
Grüße Markus
Ah jetzt ja!
Das ist mir einfach nicht aufgefallen, aber klar, 3 Werte :-)
Dank dir!
Gruß,
Stefan
Guten Abend! Ich habe gestern alle 66 Seiten des Threads durchgelesen, und zunächst einmal herzlichen Dank an Icinger und alle Unermüdlichen, die hier im Thread helfen.
Ich möchte das Thema "Stromzähler-Auslesen" etwas pushen, und habe zunächst einmal eine Wiki-Seite zum "Stromzähler auslesen" verfasst. Ich würde mich über Korrekturen, Anmerkungen oder Erweiterungsvorschläge freuen und arbeite sie gerne ein:
https://wiki.fhem.de/wiki/Stromz%C3%A4hler_auslesen (https://wiki.fhem.de/wiki/Stromz%C3%A4hler_auslesen)
Vermutlich langweilt Euch die Seite fachlich - aber es geht eher darum, Einsteigern eine Orientierung zu bieten.
Als nächsten Schritt würde ich gerne eine Wiki-Seite zum OBIS-Modul schreiben - wobei: Bei mir schnurrt alles, seit ich im November 2018 den EMH ED300L bekam, und schnurrt mit dem 2-Richtungszähler von ISKRA genauso. Das war "Kopf wiederanklemmen, staunen, dass ich jetzt auch die Einzelwerte für die Phasen sehe".
Ich arbeite im Push-Mode ohne "Downscaling durch Poll-Intervall".
Ich kann mich gerne auch um Probleme im Code kümmern, denn Icinger fragt ja durchaus nach Patches.
Schön, dass Du Dich des Themas annimmst u. Stefan etwas unterstützt. 8)
Gefühlt ist es bei Stefan ähnlich wie bei mir: Hauptsache funktioniert. ;) Wenn ich es richtig in Erinnerung habe, sind in der commandref noch die ein oder andere Lücke. Und dann haben wir noch die Ansteuerung der Zähler, die immer wieder mal angesprochen wird u. Stefan die ein oder andere Zwischenversion eingestellt oder gar außerhalb des Forums "verteilt" hat. Das sollte im Wiki zum OBIS-Modul auf jeden Fall stehen, da nur Einzelne es mal benötigen, es aber meines Wissens aus dem Teststadium noch nicht herausgekommen ist.
Zähler-Wiki sieht gut aus. Die Zukunft besser erklärt als es die meisten EVUs/VNBs/Msbs hinbekommen. ;D
Grüße Markus
So, vorab: Tiefen Respekt vor Stefans Level of Perl! Da kann ich noch viel lernen... Ich schreibe nämlich angeblich - ob JS, Perl oder Java - in jeder Sprache immer nur C.
Trotzdem habe ich mich mal "ans Herz" getraut: An ein paar Stellen sind m.E. Redundanzen drin, bzw. - wenn man wie ich "reverse draufsieht" - Stellen wo man denkt: "Hey, dieser Zustand kann doch hier gar nicht vorkommen - weil: hast Du oben abgefangen".
Wer Lust hat, sein System kaputt zu machen, kann ja mal meine angehängte Version probieren.
Änderungen:
Da ja manchen Nutzern das Ganze auf einem Raspi 2 zu lahm war, habe ich an der Performance geschraubt: Bei mir auf dem Raspi 3B+ lagen die Zeiten für das Parsen einer Nachricht (vom MT175 von ISKRA) im Mittel bei 8,5 ms, jetzt sind es 5,5 ms. Dass anschließend bei mir 75 ms für die Notify-Verarbeitung draufgehen, weil viel dahinter hängt, ist eine andere Sache...
Außerdem wurden bei mir die Readings "PublicKey" und "ManufID" nur als "Zahlenreadings" angezeigt, obwohl die Regeln eigentlich im Code stecken (nur nicht greifen). Das habe ich gefixt.
Als Nächstes gehe ich wieder das Doku-Thema an.
@Stefan: Ich würde mich melden, wenn ich meine: "Das taugt jetzt..." Falls Du aber neugierig bei einem "diff" bist, warum ich irgendwas umgestellt habe: Gerne per Skype-Session drüber diskutieren... Im Kern habe ich einen Cache für Deine OBIS_code-Tabelle eingebaut, an ein paar Stellen m.E. optimiert (z.B. beim inkrementellen Buffer-Befüllen kein Hex hin / zurückkonvertieren) und RegExp-Auswertungen reduziert.
Sorry, wenn meine nachfolgende Frage Off Topic sein sollte, aber hier sind ja viele SML Experten zugange...
Ich habe jetzt auch eine sog. "Intelligente Messeinrichtung" bekommen, die spontan SML über IR sendet. Allerdings ist der Zähler sehr weit weg von meinem FHEM-Server. Serielle Kabel und WLAN scheiden damit aus, LAN wäre aber möglich.
Kennt jemand hier einen "Lesekopf", der sich unmittelbar an's Ethernet anschließen lässt und könnte OBIS damit etwas anfangen? Wenn ich das richtig verstehe, erwartet OBIS die SML-Daten bit/byteweise (UART, USB) und dekodiert diese dann!?
Im "Netz" wird dagegen ein Eigenbau angeboten, der den SML-Stream bereits "parsed" und dann per MQTT publiziert. Könnte dieser "fertige" SML-String dann an OBIS übergeben werden?
Alternativ könnte ich mir nur noch eine extra FHEM-Instanz z.B. auf einem Raspberry vorstellen, right?
Danke und ich bitte um Nachsicht, wenn das hier schon beantwortet worden sein sollte ...
ZitatIm "Netz" wird dagegen ein Eigenbau angeboten, der den SML-Stream bereits "parsed" und dann per MQTT publiziert.
Wenn es in MQTT vorliegt macht es vermutlich keinen Sinn, das dann wieder in OBIS zu konvertieren nur um das Modul zu nutzen.
ZitatKennt jemand hier einen "Lesekopf", der sich unmittelbar an's Ethernet anschließen lässt und könnte OBIS damit etwas anfangen?
Kennen tu ich es nicht, aber nichts anderes machen ja die ESP-Varianten. Man gibt einfach die IP anstatt dem serial_device an(glaub ich;den Rest macht FHEM intern) Auch gibt es diese serial2net Geschichten. Kenne ich mich aber nicht mit aus.
ZitatSerielle Kabel und WLAN scheiden damit aus, LAN wäre aber möglich.
Wieso geht LAN aber nicht seriell ? Draht ist ja dann scheinbar vorhanden. ;)
Grüße Markus
Egal, ob schon beantwortet oder nicht:
Ich habe ziemlich viel die letzten Tage recherchiert, was es gibt. Und ganz einfache Lösungen mit Ethernet sind mir nicht über den Weg gelaufen. Die ESP8266 / ESP32-Welt hat halt Wifi von Haus aus, aber kein Ethernet.
Kann sein, dass noch jemand eine andere Idee hat, aber ich würde einen zweiten Raspi als einfachste Option sehen, entweder gleichartig zu Deinem FHEM-Server als Hardware-Backup, oder möglichst klein und stromsparend (Raspberry B+? Für 30 Euro?). Einfach, weil Du dann Dir das Reinlernen in andere Umgebungen ersparst.
Markus hat ja schon hinterfragt, warum nicht den LAN-Draht für Seriell missbrauchen. Ich bin nicht so der Typ, bei dem "Ich probiere mal, USB über Ethernet-Draht zu führen, indem ich das dranlöte" i.d.R. zum Glück geführt hat. Mit dem "Keller-Raspi" kannst Du dann ggf. noch andere Dinge machen (z.B. den Raspi als Hungerleider-Hotspot im Keller betreiben, um dort Shellys wachsen zu lassen).
OBIS hat keinen Wert über die SML-Dekodierung hinaus. Wichtig ist ja nur, die Daten in FHEM reinzubekommen. Da würde ich dann vom Keller-Raspi zum FHEM-Mainframe über MQTT gehen.
Erst einmal vielen Dank für die schnellen Antworten. Super Forum hier :)
ZitatWieso geht LAN aber nicht seriell ?
In Zählernähe liegt ein LAN-Kabel, das auch als solches benutzt wird. Ein weiteres (serielles) Kabel wäre extrem unschön. Vielleicht bei der nächsten Renovierung. Aber das ist auch eine WAF-Frage ;)
Bin ja irgendwie froh, dass ich nicht so ganz falsch lag mit meiner Einschätzung. Inzwischen habe ich per Google einen Arduino-Sketch gefunden, der SML aus dem Stream "selektiert". Müsste, sofern der läuft, nur noch per MQTT verschickt werden. Vielleicht kann man das auch noch komplett parsen, also bis auf Readingsniveau, sozusagen. Einen Arduino Uno habe ich noch. Werde also mal ein Ethernet Shield in China ordern. Habe da auch noch ein paar Rest-Skills, die ich wieder auffrischen könnte. Man darf ja sowieso gerade nicht raus :-[
Schönen Abend noch.
RS485 ist keine Lösung ?
ZitatRS485 ist keine Lösung ?
Das ist doch auch kabelbasiert, soviel ich weiß !?
Ich habe mal weiter recherchiert: einen passenden Sketch, der den SML-Stream "zusammensetzt" habe ich ja gefunden. Den untersuche ich mal auf Eignung ;) Beim Chinesen gibt es Arduinos und Ethernet Shields für jeweils so um die 5-7 Euronen, ohne dass ich das jetzt optimiert hätte. Hätte gegenüber dem 2nd-Raspberry-Ansatz später den Out-of-the-Box-Vorteil, weil man vermutlich nicht viel konfigurieren muss (wegen DHCP wohl nur den MQTT-Broker einstellen), so meine Vorstellung ...
Also, ich mache mich mal dran "über die Tage" mit dem, was ich noch hier habe. Der Störfaktor seitens der Verwandtschaft ist ja dieses Jahr stark limitiert ;D
Wenn es dann interessiert, kann ich ja mit meinen potentiellen Resultaten einen extra Thread aufmachen.
Bis dahin (siehe Motto unten) ...
ZitatWenn es dann interessiert, kann ich ja mit meinen potentiellen Resultaten einen extra Thread aufmachen.
Mich interessiert es auf jeden Fall, ich würde die Stromzähler-Seite https://wiki.fhem.de/wiki/Stromzähler_auslesen dann um eine Ethernet-Lösung aktualisieren.
Hallo zusammen,
habe ungefähr das gleiche Problem, die SML-Daten zu übertragen.
Hier noch ein weiterer Ansatz:
https://www.jurasz.de/de/jarek/z%C3%A4hler
Auch fürs Wiki interessant.
Zitat von: Stromzähler am 18 Dezember 2020, 17:18:15
Sorry, wenn meine nachfolgende Frage Off Topic sein sollte, aber hier sind ja viele SML Experten zugange...
Ich habe jetzt auch eine sog. "Intelligente Messeinrichtung" bekommen, die spontan SML über IR sendet. Allerdings ist der Zähler sehr weit weg von meinem FHEM-Server. Serielle Kabel und WLAN scheiden damit aus, LAN wäre aber möglich.
Kennt jemand hier einen "Lesekopf", der sich unmittelbar an's Ethernet anschließen lässt und könnte OBIS damit etwas anfangen? Wenn ich das richtig verstehe, erwartet OBIS die SML-Daten bit/byteweise (UART, USB) und dekodiert diese dann!?
Im "Netz" wird dagegen ein Eigenbau angeboten, der den SML-Stream bereits "parsed" und dann per MQTT publiziert. Könnte dieser "fertige" SML-String dann an OBIS übergeben werden?
Alternativ könnte ich mir nur noch eine extra FHEM-Instanz z.B. auf einem Raspberry vorstellen, right?
Danke und ich bitte um Nachsicht, wenn das hier schon beantwortet worden sein sollte ...
Ich vermute Ethernet heisst auch, dass Strom vorhanden ist.
Bei mir läuft der Lesekopf an einem Arduino, der über einen ESP ins WLAN geht (Der ESP-würde nicht benötigt, aber ich die entsprechende Komponente war bereits fertig).
WLAN nach Ethernet wird bei mir über einen separaten WLAN-Accesspunkt gemacht.
Wie auch schon früher im Thread beschrieben funktioniert das Modul ja auch mit einem per Netz angekoppelten Lesekopf.
Wenn direkt Ethernet gebraucht wird, lässt sich natürlich auch ein Arduino per Ethernet koppeln - das erfordert allerdings etwas Programmierung
Danke ür die Antwort. Ja, Strom ist natürlich vorhanden.
ZitatWie auch schon früher im Thread beschrieben funktioniert das Modul ja auch mit einem per Netz angekoppelten Lesekopf.
So wie ich das verstehe, reicht diese Arduino-ESP-Lösung den Bytestream vom Lesekopf "unbearbeitet" durch? Das Netz transportiert bei einem Spontanleser also ununterbrochen Pakete, die erst in Fhem ausgewertet werden und das eben nur alle 30 Sekunden oder so?
Da hätte ich die Idee, dem Arduino etwas mehr zuzutrauen und ihn die Vorarbeit (vorparsen) machen zu lassen und dann eben nur in festgelegten Intervallen zu senden. In dieser ersten Stufe kämen dann "fertige" SmlFiles in Fhem an, die dort allerdings dann weiter "zerlegt" werden müssten. Ideal wäre natürlich im Arduino bis zu den einzelnen Readings (Power etc.) zu parsen.
Kann das OBIS-Modul schon komplette SmlFiles übernehmen? Ich habe das so nicht verstanden ...
Edit: einen ersten Machbarkeitserfolg habe ich: das SmlFile hat mein Arduino per MQTT an Fhem übertragen. Siehe Anhang ...
Zitat von: Stromzähler am 20 Dezember 2020, 10:57:12
Danke ür die Antwort. Ja, Strom ist natürlich vorhanden.
So wie ich das verstehe, reicht diese Arduino-ESP-Lösung den Bytestream vom Lesekopf "unbearbeitet" durch? Das Netz transportiert bei einem Spontanleser also ununterbrochen Pakete, die erst in Fhem ausgewertet werden und das eben nur alle 30 Sekunden oder so?
Da hätte ich die Idee, dem Arduino etwas mehr zuzutrauen und ihn die Vorarbeit (vorparsen) machen zu lassen und dann eben nur in festgelegten Intervallen zu senden. In dieser ersten Stufe kämen dann "fertige" SmlFiles in Fhem an, die dort allerdings dann weiter "zerlegt" werden müssten. Ideal wäre natürlich im Arduino bis zu den einzelnen Readings (Power etc.) zu parsen.
Natürlich kann man das auf hundert verschiedene Arten lösen - es ging mir nur um eine mögliche Lösung
Mehr im Arduino zu machen Das ist sicher möglich, aber wofür?
"Ununterbrochen Pakete" ist bei 9600 Baud ja selbst bei schlechter WLAN-Verbindung von 20 Mbit eine Auslastung von grob 0,1%
Wie oft im Modul aktualisiert wird - hängt davon ab, wie oft ein vollständiger Datensatz überkommt.
@Stromzähler: Wenn es 1-2 Tage sauber läuft und Du magst, beschreib' doch mal Deine Gesamtlösung. Packe ich dann ins Wiki.
Was m.E. für "lokales Dekodieren" spricht, ist die Anzahl der Pakete. Ich wäre interessiert, ob mal jemand mit ser2net schreiben kann, wie viele TCP-Pakete da in etwa je Aktualisierung generiert werden. Denn die Buffersize ist ja mutmaßlich sehr niedrig. Das OBIS-Modul ist nicht extrem effizient im Zusammensetzen der Pakete.
ZitatNatürlich kann man das auf hundert verschiedene Arten lösen -
Das stimmt sicher und wird daher langsam Off Topic. Ich werde "meine" Lösung, die ich jetzt zuerst einmal mit einem WeMos über WLAN gemacht habe (mangels Ethernet Shield), besser in einem eigenen Thread beschreiben.
Zitat von: viegener am 20 Dezember 2020, 22:44:33
Natürlich kann man das auf hundert verschiedene Arten lösen - es ging mir nur um eine mögliche Lösung
Mehr im Arduino zu machen Das ist sicher möglich, aber wofür?
"Ununterbrochen Pakete" ist bei 9600 Baud ja selbst bei schlechter WLAN-Verbindung von 20 Mbit eine Auslastung von grob 0,1%
Wie oft im Modul aktualisiert wird - hängt davon ab, wie oft ein vollständiger Datensatz überkommt.
...also mein EMH-Zähler, angebunden über den Volkslesekopf von Udo mit TTL an Wemos mit ESPLink drauf wird vom Modul ca. alle 1-2s empfangen. Traffic auf dem WLAN und Auslastung des RPI4 durchdas Modul nahezu NULL :-)
Meine Lösung für Ethernet ist folgende:
Lesekopf mit TTL Ausgang / Eingang hängt an einem X-Port von LANTRONICS als Wandler von seriell nach Ethernet, funktioniert tadellos und ist super simpel.
Gruß Thomas
Ich habe meinen Sensor über eine ESP8266 gebaut.
https://mwinkler.jimdo.com/smarthome/aktoren-sensoren/stromz%C3%A4hler-digital/
Zitat von: michael.winkler am 28 Dezember 2020, 11:44:28
Ich habe meinen Sensor über eine ESP8266 gebaut.
https://mwinkler.jimdo.com/smarthome/aktoren-sensoren/stromz%C3%A4hler-digital/
Hi
So habe ich das auch gemacht.
Aber da mir Kabel lieber ist ...
Wäre es auch möglich diese "Schaltung" an den LANTRONICS Wandler anzuschliesen ?
Zitat von: Icinger am 13 März 2019, 18:30:25
Nein, kann man nicht einstellen, ist der erste Zähler, von dem ich höre, dass der ein anderes CRC hat.
Du kannst mal zum testen die Zeile 758
return $crc2==$crc ? 1 : 0;
durch ein einfaches
return 1;
ersetzen.
Damit werden die Daten ausgewertet, egal, ob CRC richtig oder falsch ist.
lg, Stefan
Vielen Dank.
Ich habe auch einen Holley Zähler.
Ich hatte auch nur CRC Fehler.
Nachdem Ändern des Scripts bekomme ich nun auch Daten.
Zitat von: AxelSchweiss am 28 Dezember 2020, 11:50:42
Hi
So habe ich das auch gemacht.
Aber da mir Kabel lieber ist ...
Wäre es auch möglich diese "Schaltung" an den LANTRONICS Wandler anzuschliesen ?
Ja, am XPORT hast Du Rx und Tx mit 3,3V, sind aber auch 5V tolerant. Also kannst Du jeden Zählerkopf anschließen, der mit 3,3V oder 5V Signalpegel arbeitet.
Gruß Thomas
Hallo zusammen,
ich bekomme es leider nicht ans fliegen und brauche Hilfe.
Idee: D0-Lesekopf vom ISKRA MT681, der SML spricht auf der TX-Leitung anzapfen und mitlesen, was er an den SunnyHomeManager liefert. (Wenn man nach D0 Sunny Home Manager und Schnüffelstück googelt findet man ein Schaubild, das jemand in 2017 erstellt hat)
Modul ist definiert, alle möglichen Settings habe ich durch, es kommt nur unlesbarer Datenmüll, aber keine Readings. (8N1 laut Datenblatt)
Bin mir nicht sicher, ob "Update" überhaupt versucht zu lesen, da ich im Log nichts sehe. State ist connected, Datenmüll im Buffer ist zu sehen, keine Readings)
Kann ich denn die TX- und GND-Leitung direkt an UART 0 am Raspi klemmen? (Spannungsproblem wegen der 8Volt für den Lesekopf?)
Ich besitze so einen FTDI-RS232 Adapter - hier habe ich TX- und GND belegt und versuche über /dev/ttyUSB0 auszulesen, bisher auch nur mit mäßigem Erfolg.
Im Internet finde ich Schaltpläne, bei denen die TX-/RX-Leitungen des Adapters auf die UART-GPIO gesteckt wurden. Denke ich zu kompliziert? Ich habe am Lesekopf keinen USB-Anschluss ...will ja eben die TX-Leitung einfangen, also schließe ich den Adapter nicht am UART vom Raspi an, sondern am Lesekopf. FTDI-Adapter hängt korrekt am USB0.
Ach ja: 3.3 oder 5V am FTDI-Adapter? Ist das lesend? Also welches Gerät bekommt wie die 3.3 oder 5Volt? Vermutlich liegt hier mein Problem?!? Unterschiedliche Spannungsquellen - ich (BWLer;) dachte, die 8 Volt vom SHM aktivieren den Lesekopf, zurück kommen aber nur Impulse, die ich seriell ganz einfach mitlesen kann?!?
Danke für jeden Hinweis vorab!
Du hast also TX vom Lesekopf an TX vom USB-Adapter gelegt ? ....wenn du am FTDI-Adapter mal den RX nehmen würdest für Eingang Richtung USB, bringt das dann eine Änderung ? Also TX vom Lesekopf an RX vom USB-Adapter, würde ich mal probieren
Guten Abend!
Ich hab beide Varianten probiert - laut Anleitung die TX-Leitung des Sensors (Also Sensor --> SHM) auf die RX-Leitung vom Adapter und um keinen falschen Fehler zu machen, auch andersrum.
Mittlerweile hab ich das Gefühl, dass evtl. mein FTDI-Adapter nen Schuss hat. Gestern kam mein ESP32, den ich heute geflashed habe - bisher aber mit:
Internals:
CFGFN
DEF 192.168.178.77:23 SML
DeviceName 192.168.178.77:23
FUUID 5fec7728-f33f-bc2d-f147-c023326e0f191a35
MeterType SML
NAME ZAEHLER
NEXT_OPEN 1609356311.26502
NR 140
PARTIAL
STATE disconnected
TYPE OBIS
READINGS:
2020-12-30 20:24:11 state disconnected
helper:
EoM -1
SPEED 5
TRIGGERTIME 1609332520.90889
DEVICES:
-1
Attributes:
room Zähler
Leider ein "disconnect". Als MQTT-Device sehe ich den ESP32 mittlerweile.
Warum der ESP nicht erkannt wird, kapiere ich noch nicht - IP-Adresse ist korrekt, der Port offenbar der zu verwendende...
Neue FTDI-Adapter kommen morgen.
Zitat von: assi05 am 30 Dezember 2020, 20:30:34
... DEF 192.168.178.77:23 SML
Warum der ESP nicht erkannt wird, kapiere ich noch nicht - IP-Adresse ist korrekt, der Port offenbar der zu verwendende...
Hallo assi05,
der Port wird in ESP-EASY unter "Devices" -> "Communication - Serial Server" festgelegt. Musst dort mal unter "Edit" nachschauen ...
Evtl. mal eine andere Portnummer, z.B. 99 probieren !
Dann evtl. noch die Definition wie folgt eingeben (nicht SML sondern Standard):
DEF 192.168.178.77:[korrekter Port] Standard
Viel Erfolg
Gruß Thomas
Danke, Thomas!
Ich nutze bisher ESP-Easy nicht, sondern Tasmota. Nach den Feiertagen bin ich nun viiiieeeel weiter, aber jetzt hilft vermutlich nur noch ein Elektriker :
-ESP32 geflashed mit Tasmota, inkl. aktiviertem SML (Modul von AZ Delivery für ein paar Euro)
- KEINE Funktion, wenn korrekt angeschlossen
- Funktion in Tasmota sofort, sobald ich die Stiftleiste am ESP berühre. Reproduzierbar ...sobald GND angeschlossen ist, geht es nicht mehr. GND abgeklemmt und Finger ran: LÜBBT!
Ich scheine also ein Potential-Problem zu haben. Bin jetzt in Mega-Ohm-Schritten auf bis zu 4M hochgegangen (GND gegen Schutzleiter) - KEINE Funktion und vermutlich auch in OBIS sowohl über ESP als auch FTDI via USB nur Gemüse und kein Klartext aus diesem Grund.
Wenn es funktioniert, bekomme ich auch alles via MQTT nach FHEM - würde also OBIS sogar obsolet machen. Leider bin ich "elektrisch" mit meinem Wissen am Ende. Finger an die Stiftleiste, ohne GND und es funktioniert . Netzteil, etc. bereits getauscht.
Hat dazu jemand eine Idee?
Zitat von: assi05 am 01 Januar 2021, 21:52:10
Danke, Thomas!
Ich nutze bisher ESP-Easy nicht, sondern Tasmota. Nach den Feiertagen bin ich nun viiiieeeel weiter, aber jetzt hilft vermutlich nur noch ein Elektriker :
-ESP32 geflashed mit Tasmota, inkl. aktiviertem SML (Modul von AZ Delivery für ein paar Euro)
- KEINE Funktion, wenn korrekt angeschlossen
- Funktion in Tasmota sofort, sobald ich die Stiftleiste am ESP berühre. Reproduzierbar ...sobald GND angeschlossen ist, geht es nicht mehr. GND abgeklemmt und Finger ran: LÜBBT!
Ich scheine also ein Potential-Problem zu haben. Bin jetzt in Mega-Ohm-Schritten auf bis zu 4M hochgegangen (GND gegen Schutzleiter) - KEINE Funktion und vermutlich auch in OBIS sowohl über ESP als auch FTDI via USB nur Gemüse und kein Klartext aus diesem Grund.
Wenn es funktioniert, bekomme ich auch alles via MQTT nach FHEM - würde also OBIS sogar obsolet machen. Leider bin ich "elektrisch" mit meinem Wissen am Ende. Finger an die Stiftleiste, ohne GND und es funktioniert . Netzteil, etc. bereits getauscht.
Hat dazu jemand eine Idee?
Wie genau hast Du das Ganze verdrahtet ?
Laut Anleitung SHM ist die Rx Leitung die Datenübertragungsleitung vom Lesekopf Richtung SHM.
Kannst Du von der Rx und/oder der Tx Leitung evtl. eine Oszilloskop Messung machen ?
8V Versorgung für den Lesekopf könnte bedeuten, dass die Signalpegel auch 8V haben, könnten aber auch 5V sein.
Du müsstest also vom Lesekopf Rx (Pin C) und GND (Pin A) anzapfen und zum FTDI-Adapter nach GND und Rx verbinden, also GND -> GND und Lesekopf Rx -> Rx FTDI.Mit den Pegeln (5V oder auch 8V) müsste der FTDI-Adapter ohne Probleme zurechtkommen (den FTDI auf 5V einstellen).Das Ganze könnte auch ohne FTDI funktionieren, wenn Du einen Spannungsteiler an die Rx-Leitung vom Lesekopf gegen GND verwendest, der den Pegel auf 3,3V begrenzt.
Dazu müsstest Du allerdings wissen, wie hoch der Signalpegel ist (Oszi-Messung nötig).
Nach dem Spannungsteiler dann direkt auf die Rx Leitung vom ESP-Board gehen und natürlich GND mit GND verbinden.
Viel Erfolg ;o)
Gruß Thomas
Zitat von: assi05 am 01 Januar 2021, 21:52:10
Danke, Thomas!
Ich nutze bisher ESP-Easy nicht, sondern Tasmota. Nach den Feiertagen bin ich nun viiiieeeel weiter, aber jetzt hilft vermutlich nur noch ein Elektriker :
-ESP32 geflashed mit Tasmota, inkl. aktiviertem SML (Modul von AZ Delivery für ein paar Euro)
- KEINE Funktion, wenn korrekt angeschlossen
- Funktion in Tasmota sofort, sobald ich die Stiftleiste am ESP berühre. Reproduzierbar ...sobald GND angeschlossen ist, geht es nicht mehr. GND abgeklemmt und Finger ran: LÜBBT!
Ich scheine also ein Potential-Problem zu haben. Bin jetzt in Mega-Ohm-Schritten auf bis zu 4M hochgegangen (GND gegen Schutzleiter) - KEINE Funktion und vermutlich auch in OBIS sowohl über ESP als auch FTDI via USB nur Gemüse und kein Klartext aus diesem Grund.
Wenn es funktioniert, bekomme ich auch alles via MQTT nach FHEM - würde also OBIS sogar obsolet machen. Leider bin ich "elektrisch" mit meinem Wissen am Ende. Finger an die Stiftleiste, ohne GND und es funktioniert . Netzteil, etc. bereits getauscht.
Hat dazu jemand eine Idee?
Neben den Anmerkungen von hdgucken würde ich auch noch anmerken:
- Du solltest unbedingt Spannungswandler auch für den TX/RX port vorsehen zum ESP32 - die Ports sind laut Datenblatt nicht 5v tolerant
- Ich habe mit den AZDelivery ESP32 Probleme gehabt gerade mit der Stromversorgung und der Stabilität
Ich kann nicht sagen, ob das (nur) ein POtentialproblem ist,
Zitat von: viegener am 02 Januar 2021, 00:11:09
Neben den Anmerkungen von hdgucken würde ich auch noch anmerken:
- Du solltest unbedingt Spannungswandler auch für den TX/RX port vorsehen zum ESP32 - die Ports sind laut Datenblatt nicht 5v tolerant
- Ich habe mit den AZDelivery ESP32 Probleme gehabt gerade mit der Stromversorgung und der Stabilität
Ich kann nicht sagen, ob das (nur) ein POtentialproblem ist,
Hallo viegener,
Du hast natürlich Recht, der FTDI verträgt auch nur max. 5V an seinen Pins.
Man bräuchte nach dem Lesekopf einen RS232 auf 3,3V TTL Wandler (z.B. MAX3232). Danach könnte man dann direkt auf den UART am ESP gehen.
Da wäre es aber viel einfacher, einen Spannungsteiler an der Rx Leitung vom Lesekopf vorzusehen (z.B. 150kOhm / 100kOhm) und dann direkt auf den ESP.
Würde über dem 100kOhm Widerstand 3,2V ergeben, wenn der Signalpegel 8V ist und der LOW-Pegel 0V.
Gruß Thomas
Korrektur: der abgebildete Spannungsteiler funktioniert natürlich nur, wenn
KEIN RS232-Pegel (+/-12V), sondern ein einphasiges serielles Signal mit ca. 8V für HIGH und 0v für LOW ankommt
!!!
Zitat von: hdgucken am 02 Januar 2021, 01:25:10
Hallo viegener,
Du hast natürlich Recht, der FTDI verträgt auch nur max. 5V an seinen Pins.
Man bräuchte nach dem Lesekopf einen RS232 auf 3,3V TTL Wandler (z.B. MAX3232). Danach könnte man dann direkt auf den UART am ESP gehen.
Da wäre es aber viel einfacher, einen Spannungsteiler an der Rx Leitung vom Lesekopf vorzusehen (z.B. 150kOhm / 100kOhm) und dann direkt auf den ESP.
Würde über dem 100kOhm Widerstand 3,2V ergeben, wenn der Signalpegel 8V ist.
Gruß Thomas
Das mit dem Spannungsteiler passt sicher soweit - allerdings ist ja nicht klar, welche Signalpegel wirklich anliegen, oder habe ich das falsch verstanden - hier könnte sicher der bereits erwähnte Oszi mehr Klarheit bringen
Hallo Ihr beiden,
danke für Eure Hinweise!
Ich habe fast den ganzen Tag am Zählerkasten verbracht (bibber) und bin frustriert.
Ein Oszi habe ich leider nicht; könnte höchstens mit nem Logik-Analyzer dienen.
Auf den Lesekopf raus (SHM TX) gehen 8,3V. Zurück kommen auf der (SHM) RX-Leitung ca. 4,9V. Die 150/100k reduzieren die Spannung also zu weit. (siehe Dateianhang)
Ich hab diverse Optionen gelötet, Frage dazu: brauche ich exakt 3,3V, oder geht auch ein Pegel mit z.B. 2,5V - rein zum testen in Ermangelung der korrekten Widerstände ;)
Als Nicht-Elektriker noch zwei Fragen:
- auf der RX-Leitung vom Lesegerät sind die Pole umgekehrt, heißt alle Spannungen, die ich messe sind negativ (Minus auf GND gemessen)
- am ESP wiederum messe ich - ohne irgendwelche angeschlossenen Kabel: 3,2V auf dem UART RX (GPIO3) - auf TX sind es 0,1V weniger.
--> mein Verständnis wäre, dass hier keine Spannung anliegen sollte?
Als ich von Breadboard-Verkabelung heute auf Lötpunkte am SHM umgestiegen bin hatte ich auf einmal wieder schöne regelmäßige Telegramme auf der Konsole - aber wieder nur Kraut- und Rüben (bei -4,9V) und nur ohne Widerstände
Da mir das mit der Spannung auf GPIO3 komisch vorkam, hab ich auf GPIO 4 gewechselt (Also Serial RX und auch Script in Tasmota - hat keine Änderung ergeben).
Bin ich zu blöd, hab ich evtl. was falschgemacht beim flashen? Ich bin ratlos...
...Du hast einen ESP32 (keinen 8266) ? Und da hast du ESPEasy drauf und kannst dich auch sauber im WebIF vom ESPEasy einloggen und hast auch den richtigen RX/TX ausgewählt (ich meine der ESP32 hätte zwei UARTS) ? Unter Tools => Log solltest du sehen können, was auf dem ESP passiert. Also erstmal schauen, ob der ESP überhaupt über den Serial-Server was brauchbares empfangt. Normal wird dazu erstmal nur TX vom Lesekopf an RX vom ESP nötig, weil normal ja nichts an den Zähler geschickt werden muss, es sei denn es wäre z.B. für Baudumschaltung notwendig. Wenn der ESP nichts empfängt, kann das z.B. an der Baud-Rate liegen oder dem Parity/Stoppbit (sowas wie 8N1), das muss schon genau passen. Wenn das klappt, dann gibt der ESP zwar eben "Kraut und Rüben" aus:
v
� �bbrcv
�X� EMHR��c�Sv
� �bbrcw EMHR��b
��rbe�5Nvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,hw�rbe�5ObR�Uv�c�<v
� �bbrcqc,�Qv
� �bbrcv
�X� EMHR��cxv
� �bbrcw EMHR��b
��rbe�5Pvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,tw�rbe�5PbR�UxGc�Uv
� �bbrcqc�5
v
� �bbrcv
�X� EMHR��c�;v
� �bbrcw EMHR��b
��rbe�5Qvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5QbR�Ux�c\v
� �bbrcqc�a412827w � EMHR��w�d�b R�V
e,�w�rbe�5SbR�Uync{�v
� �bbrcqc v?�v
� �bbrcv
�X� EMHR��c�Qv
� �bbrcw EMHR��b
��rbe�5Tvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5TbR�U"�cnv
� �bbrcqc �cv
� �bbrcv
�X� EMHR��c��v
� �bbrcw EMHR��b
��rbe�5Vvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5VbR�U�c�Hv
� �bbrcqc�v
� �bbrcv
�X� EMHR��c<�v
� �bbrcw EMHR��b
��rbe�5Wvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5XbR�U�cC�v
� �bbrcqc�N;=v
� �bbrcv
�X� EMHR��cU�v
� �bbrcw EMHR��b
��rbe�5Yvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5YbR�U�c�v
� �bbrcqc>(�Nv
� �bbrcv
�X� EMHR��c�Wv
� �bbrcw EMHR��b
��rbe�5Zvw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5[bR�U�c�v
� �bbrcqc�av
� �bbrcv
�X� EMHR��cVv
� �bbrcw EMHR��b
��rbe�5\vw��ǂ�EMHw�0107105412827w�1EMH0005412827w � EMHR��w�d�b R�V
e,�w�rbe�5\bR�U�c9�v
� �bbrcqc�(�
Die Meldungen sollten zyklisch ähnlich aussehen. Das entschlüsselt aber das Modul im FHEM dann...
Wenn das im ESP läuft, dann kannst du schauen, dass FHEM den ESP empfängt. Unter Controler im ESP hast du FHEM eingerichtet oder ?
Grüße
Christian
Zitat von: cs-online am 02 Januar 2021, 19:36:03
...Du hast einen ESP32 (keinen 8266) ? Und da hast du ESPEasy drauf und kannst dich auch sauber im WebIF vom ESPEasy einloggen und hast auch den richtigen RX/TX ausgewählt (ich meine der ESP32 hätte zwei UARTS) ? Unter Tools => Log solltest du sehen können, was auf dem ESP passiert. Also erstmal schauen, ob der ESP überhaupt über den Serial-Server was brauchbares empfangt. Normal wird dazu erstmal nur TX vom Lesekopf an RX vom ESP nötig, weil normal ja nichts an den Zähler geschickt werden muss, es sei denn es wäre z.B. für Baudumschaltung notwendig. Wenn der ESP nichts empfängt, kann das z.B. an der Baud-Rate liegen oder dem Parity/Stoppbit (sowas wie 8N1), das muss schon genau passen. Wenn das klappt, dann gibt der ESP zwar eben "Kraut und Rüben" aus:
Hi Christian,
ja, korrekt, ein ESP32, aber nicht ESPEASY, sondern Tasmota. (Für alle Nachbauer: nehmt einen ESP8266, dafür gibt es aktuell stabilere Releases!!!!)
Ich habe selbst compiled mit GitPod, nachdem ich das SML-Protkoll aktiviert und ein paar weitere Änderungen vorgenommen habe. (bei Tasmota ist im Standard SML nicht aktiviert, da der Speicher knapp ist in den ESP-Devices - SML ist ja eher was besonderes, als Standard - daher in den offiziellen Releases deaktiviert)
Mein Zähler ist ein ISKRA MT681, der sendet SML mit 8N1 bei 9.6k. So weit, so gut.
Initiales Problem war:
Schließe ich TX Lesekopf auf RX des ESP und verbinde GND mit GND, passiert nichts.
Trenne ich GND und
berühre einen!spezifischen der mehreren GND-PIOs, sind alle Daten da, im korrekten Format, alles gut.
Wenn also mein (geerdeter) Finger am GND dazu führt, dass es funktioniert, riecht das nach Potentialausgleich (ich sniffe ja nur, d.h. TX und +V für den Lesekopf kommen ja nicht vom ESP, sondern das wird alles vom SunnyHomeManager aus "initiiert". Ich klemme mich nur auf die Telegram-Messages und will diese mitlesen.
Jetzt sagt mein Elektriker-Kumpel "Mann mit leicht feuchten Fingern hat so ca. 500k Ohm, verbinde den PIO mit 500k gegen Schutzleiter - leider ohne Ergebnis mit den Alternativen 500k, 1M, 2M, 3M, 4M.
Aber ja, so in etwa wie bei Dir sieht das dann aus, wobei Du ja schon ein paar Klartext-Passagen hast (EMH) - bei mir wirklich nur Durcheinander.
Aktuell (mit eingelöteten Widerständen auf dem SHM Mainboard kommen keine Telegramme mehr an)
Update:
Nach viel probieren habe ich die ESP32-Boards in die Ecke geworfen und mit einem FTDI-Adapter und Putty experimentiert.
Da die 9600 8N1 vorgegeben sind, konnte das mein Problem nicht sein.
Telegramme auf Putty kommen rein, aber wie beschrieben unlesbar.
Des Rätsels Lösung:
- SunnyHomeManager ohne jegliche Änderung / Anschluss Sniffer: funktioniert
- Löte ich auf die GNX und RX-Leitung vom Lesekopf mein Snifferkabel, sind die Telegramme auf FTDI unlesbar, Sunnyportal funktioniert weiter.
Außerdem musste ich zumindest anstatt wie im Forum beschrieben:
/dev/ttyUSB0@9600,8,N,1 SML die Definition wie folgt vornehmen, damit es funktioniert:
/dev/ttyUSB0@9600,8,N,1,SML
Auf "mikrokontroller.net" schreibt einer, es wäre die braune TX-Leitung vom Lesekopf anzuzapfen; das ist falsch - es ist die weiße RX-Leitung.
Die Tage hatte ich ja schon geschrieben, dass die Spannung "hochminus1" ist, also ich bekomme gegen GND-gemessen vom Lesekopf eine negative Spannung.
Versuchsweise habe ich daher "plus und minus" getauscht:
GND-Lesekopf --> RX-FTDI
RX-Lesekopf --> GND-FTDI
und siehe da: das Signal wird sofort erkannt, ist sauber und korrekt - Readings werden automatisch angelegt.
Einziges Problem:
ab diesem Augenblick friert der SHM ein, also bekommt keine Daten mehr. Dieses Verhalten ist reproduzierbar.
Jetzt stellt sich also die Frage: wie bekomme ich das Signal "invertiert"? Ist der Begriff in dem Zusammenhang korrekt?
Muss noch versuchen, ob es funktioniert, wenn der SHM und das Netzteil vom Raspberry auf unterschiedlichen Phasen liegen.
Ist jemand anwesend, der das technisch erklären kann?
Schönen Abend!
Zitat von: assi05 am 02 Januar 2021, 20:10:52
Hi Christian,
ja, korrekt, ein ESP32, aber nicht ESPEASY, sondern Tasmota. (Für alle Nachbauer: nehmt einen ESP8266, dafür gibt es aktuell stabilere Releases!!!!)
Ich habe selbst compiled mit GitPod, nachdem ich das SML-Protkoll aktiviert und ein paar weitere Änderungen vorgenommen habe. (bei Tasmota ist im Standard SML nicht aktiviert, da der Speicher knapp ist in den ESP-Devices - SML ist ja eher was besonderes, als Standard - daher in den offiziellen Releases deaktiviert)
Mein Zähler ist ein ISKRA MT681, der sendet SML mit 8N1 bei 9.6k. So weit, so gut.
Initiales Problem war:
Schließe ich TX Lesekopf auf RX des ESP und verbinde GND mit GND, passiert nichts.
Trenne ich GND und berühre einen!spezifischen der mehreren GND-PIOs, sind alle Daten da, im korrekten Format, alles gut.
Wenn also mein (geerdeter) Finger am GND dazu führt, dass es funktioniert, riecht das nach Potentialausgleich (ich sniffe ja nur, d.h. TX und +V für den Lesekopf kommen ja nicht vom ESP, sondern das wird alles vom SunnyHomeManager aus "initiiert". Ich klemme mich nur auf die Telegram-Messages und will diese mitlesen.
Jetzt sagt mein Elektriker-Kumpel "Mann mit leicht feuchten Fingern hat so ca. 500k Ohm, verbinde den PIO mit 500k gegen Schutzleiter - leider ohne Ergebnis mit den Alternativen 500k, 1M, 2M, 3M, 4M.
Aber ja, so in etwa wie bei Dir sieht das dann aus, wobei Du ja schon ein paar Klartext-Passagen hast (EMH) - bei mir wirklich nur Durcheinander.
Aktuell (mit eingelöteten Widerständen auf dem SHM Mainboard kommen keine Telegramme mehr an)
Sorry, jetzt ist alles klar. Ich dachte, der Lesekopf gibt wie meiner einfach die seriellen Daten im TTL Format aus, aber deiner gibt sie im RS232 Format aus !
Dort ist es so, das ein negativer Spannungspegel (z.B. -9V) ein "HIGH" darstellt und ein positiver Signalpegel (z.B. +9V) "LOW".
Die Pegel wechseln also immer von -9V nach +9V, 0V ist kein definierter Signalpegel.
Jetzt muss man entweder einen MAX3232 (RS232 -> 3,3V TTL) - Wandler benutzen oder eine Transistorstufe, siehe Bild ...
Gruß Thomas
Zitat von: assi05 am 03 Januar 2021, 20:40:06
Update:
Nach viel probieren habe ich die ESP32-Boards in die Ecke geworfen und mit einem FTDI-Adapter und Putty experimentiert.
Da die 9600 8N1 vorgegeben sind, konnte das mein Problem nicht sein.
Telegramme auf Putty kommen rein, aber wie beschrieben unlesbar.
Des Rätsels Lösung:
- SunnyHomeManager ohne jegliche Änderung / Anschluss Sniffer: funktioniert
- Löte ich auf die GNX und RX-Leitung vom Lesekopf mein Snifferkabel, sind die Telegramme auf FTDI unlesbar, Sunnyportal funktioniert weiter.
Außerdem musste ich zumindest anstatt wie im Forum beschrieben:
/dev/ttyUSB0@9600,8,N,1 SML die Definition wie folgt vornehmen, damit es funktioniert:
/dev/ttyUSB0@9600,8,N,1,SML
Auf "mikrokontroller.net" schreibt einer, es wäre die braune TX-Leitung vom Lesekopf anzuzapfen; das ist falsch - es ist die weiße RX-Leitung.
Die Tage hatte ich ja schon geschrieben, dass die Spannung "hochminus1" ist, also ich bekomme gegen GND-gemessen vom Lesekopf eine negative Spannung.
Versuchsweise habe ich daher "plus und minus" getauscht:
GND-Lesekopf --> RX-FTDI
RX-Lesekopf --> GND-FTDI
und siehe da: das Signal wird sofort erkannt, ist sauber und korrekt - Readings werden automatisch angelegt.
Einziges Problem:
ab diesem Augenblick friert der SHM ein, also bekommt keine Daten mehr. Dieses Verhalten ist reproduzierbar.
Jetzt stellt sich also die Frage: wie bekomme ich das Signal "invertiert"? Ist der Begriff in dem Zusammenhang korrekt?
Muss noch versuchen, ob es funktioniert, wenn der SHM und das Netzteil vom Raspberry auf unterschiedlichen Phasen liegen.
Ist jemand anwesend, der das technisch erklären kann?
Schönen Abend!
Ich denke da ist immer noch einiges durcheinander (zum Teil auch schon von hdgucken erwähnt):
- Die Spannungswerte sind vermutlich leicht zu erklären, wenn man davon ausgeht, dass es eine richtige serielle Schnittstelle also RS232 ist, denn dort sind historisch die Spannungen "bipolar" also logisch 1 ist Plus und logisch 0 ist minus - das klingt so also ob das heir passt - das hat nichts mit vertauscht zu tun
- Ob RX oder TX ist ja immer eine Frage der Sichtweise insofern vermute ich, dass RX aus Sicht der SHM beschriftet ist (ich kenne SHM überhuapt nicht, aber da es wohl korrektes RS232 ist wird hier vermutlich auch entsprechend beschriftet
- das zusätzlich Komma in Deiner Definition sorgt dafür, dass SML gar nicht übergeben wird denn das SML wird damit mit der Device-Definition zusammengezogen und dort vermutlich ignoriert (oder ist sowieso Standard ?)
Generell hast Du aber ein Problem, dass vermutlich eine gewisse Schaltung erfordert (und nicht unterschiedliche Phasen - denn das sollte hier eher nichts damit zu tun haben). Du brauchst etwas dass
1) Korrektes RS232 zumindest in Empfangsrichtung (ohne RTS, CTS und sogar TX) umsetzen kann in ESP32 oder zumindest TTL-Pegel - das gibt es fertig
2) Einen Signalabgriff, der das RS232-Signal sowenig verändert, dass SHM hier nicht auf die Nase fällt - es gibt so etwas als Harwaresplitter mit Schaltung aber vielleicht wird das auch schon mit 1 erreicht (es gab dazu früher auch einfach splitterkabel, die in vielen Fällen funktioniert haben - das bipolare Signal ist relativ stabil)
Ok, danke Euch beiden! So langsam lichtet sich der dunkle Wald. Ich hab mir vor Jahren bei den Chinesen einen Logik-Analyzer bestellt, hab damit ohne dem Wissen RS232 vs TTL von Thomas gestern aber nichts kapiert, geschweige denn das Ding korrekt bedient.
Ich ziehe wirklich viel Wissen aus solchen Beiträgen und bin dankbar dafür!
Solche Konverter gibt's ja bereits im 1€-Bereich....reicht ein solcher Mini Wandler aus?
https://www.ebay.de/i/293842603224?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=293842603224&targetid=994008894136&device=c&mktype=pla&googleloc=1003919&poi=&campaignid=10203814998&mkgroupid=101937413917&rlsatarget=pla-994008894136&abcId=1145992&merchantid=111982137&gclid=Cj0KCQiA88X_BRDUARIsACVMYD-uZH1GHcYnBv1_SP3OzSPPEY9U5r3kPNa0F1ZZ_AwJFh2zkITEnQYaAlPGEALw_wcB (https://www.ebay.de/i/293842603224?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=293842603224&targetid=994008894136&device=c&mktype=pla&googleloc=1003919&poi=&campaignid=10203814998&mkgroupid=101937413917&rlsatarget=pla-994008894136&abcId=1145992&merchantid=111982137&gclid=Cj0KCQiA88X_BRDUARIsACVMYD-uZH1GHcYnBv1_SP3OzSPPEY9U5r3kPNa0F1ZZ_AwJFh2zkITEnQYaAlPGEALw_wcB)
So viel Aufwand für ein wenig Bastelei, die Kinder haben Mama heute gefragt, wer der Mann da unten am Zählerschrank ist 🤣
Zitat von: assi05 am 04 Januar 2021, 00:18:57
Ok, danke Euch beiden! So langsam lichtet sich der dunkle Wald. Ich hab mir vor Jahren bei den Chinesen einen Logik-Analyzer bestellt, hab damit ohne dem Wissen RS232 vs TTL von Thomas gestern aber nichts kapiert, geschweige denn das Ding korrekt bedient.
Ich ziehe wirklich viel Wissen aus solchen Beiträgen und bin dankbar dafür!
Solche Konverter gibt's ja bereits im 1€-Bereich....reicht ein solcher Mini Wandler aus?
https://www.ebay.de/i/293842603224?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=293842603224&targetid=994008894136&device=c&mktype=pla&googleloc=1003919&poi=&campaignid=10203814998&mkgroupid=101937413917&rlsatarget=pla-994008894136&abcId=1145992&merchantid=111982137&gclid=Cj0KCQiA88X_BRDUARIsACVMYD-uZH1GHcYnBv1_SP3OzSPPEY9U5r3kPNa0F1ZZ_AwJFh2zkITEnQYaAlPGEALw_wcB (https://www.ebay.de/i/293842603224?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=293842603224&targetid=994008894136&device=c&mktype=pla&googleloc=1003919&poi=&campaignid=10203814998&mkgroupid=101937413917&rlsatarget=pla-994008894136&abcId=1145992&merchantid=111982137&gclid=Cj0KCQiA88X_BRDUARIsACVMYD-uZH1GHcYnBv1_SP3OzSPPEY9U5r3kPNa0F1ZZ_AwJFh2zkITEnQYaAlPGEALw_wcB)
So viel Aufwand für ein wenig Bastelei, die Kinder haben Mama heute gefragt, wer der Mann da unten am Zählerschrank ist 🤣
Nimm den:
https://www.ebay.de/itm/MAX3232-mini-seriell-TTL-Konverter-bidirektional-Modul-MAX232-RS232-Converter/393056957233?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D2%26asc%3D20160908110712%26meid%3D5aff566fa5d949f9b72f208ac2e4ab6a%26pid%3D100677%26rk%3D5%26rkt%3D30%26mehot%3Dnone%26sd%3D293842603224%26itm%3D393056957233%26pmt%3D1%26noa%3D1%26pg%3D2386202%26algv%3DDefaultOrganic%26brand%3DMarkenlos&_trksid=p2386202.c100677.m4598 (https://www.ebay.de/itm/MAX3232-mini-seriell-TTL-Konverter-bidirektional-Modul-MAX232-RS232-Converter/393056957233?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D2%26asc%3D20160908110712%26meid%3D5aff566fa5d949f9b72f208ac2e4ab6a%26pid%3D100677%26rk%3D5%26rkt%3D30%26mehot%3Dnone%26sd%3D293842603224%26itm%3D393056957233%26pmt%3D1%26noa%3D1%26pg%3D2386202%26algv%3DDefaultOrganic%26brand%3DMarkenlos&_trksid=p2386202.c100677.m4598)
Sieht gleich aus, aber in der Artikelbeschreibung steht explicit MAX
3232, der geht auch für 3,3V TTL-Pegel, der MAX232 ist nur für 5V TTL-Pegel geeignet.
Gruß Thomas
Melde folgenden Teilerfolg:
- MAX3232 eingeschleift
= SHM / Sunnyportal bekommt Werte und updated auch
= OBIS-Modul bekommt Werte und updated auch
Aber es gibt noch ein Problem:
Der FTDI-Adapter connected/disconnected ständig - mehrfach pro Sekunde. Daher ist es eher Zufall, ob ein Telegramm durchkommt.
Hat jemand eine Idee, woran dieses State "connected/disconnected" liegen kann?
Auszugsweise folgendes Log:
021-01-08 16:14:51 OBIS ZAEHLER CONNECTED
2021.01.08 16:14:51 1 : /dev/ttyUSB0 disconnected, waiting to reappear (ZAEHLER)
2021-01-08 16:14:51 OBIS ZAEHLER DISCONNECTED
2021.01.08 16:14:51 3 : Setting ZAEHLER serial parameters to 9600,8,N,1
2021.01.08 16:14:51 3 : Init done
2021.01.08 16:14:51 1 : /dev/ttyUSB0 reappeared (ZAEHLER)
2021-01-08 16:14:51 OBIS ZAEHLER CONNECTED
2021.01.08 16:14:51 5 : SML-Parse 1B1B1B1B0101010176051D85F9EE070100620AFFFF726201650E53CD8B7A77078181C78203FF010101010449534B0177070100000009FF010101010B0649534B0104CEE3D5990177070100010800FF650001018201621E52FF59000000000B4A40AB0177070100010801FF0101621E52FF59000000000B4A40ABFF0101621E52FF59000000001FBE94DC0177070100020802FF0101621E52FF5900000000000000000177070100100700FF0101621B520055000001580177078181C78205FF01010101830225DF1B1B1B1B010101017605D599070100620AFFFF726201650E53CD8D7A77078181C78203FF010101010449534B0177070100000009FF010101010B0649534B0104CEE3D5990177070100010800FF650001018201621E00020800FF650001018201621E52FF59000000001FBE94DC0177070100020801FF0101621E52FF59000000001FBE94DC0177070100020802FF0101621E52FF5900000000000000000177070100100700FF0101621B520055000001570177078181C78205FF01010101F9F362006200726302017101635403001B1B1B1B1A00F1BB
2021.01.08 16:14:51 1 : /dev/ttyUSB0 disconnected, waiting to reappear (ZAEHLER)
2021-01-08 16:14:51 OBIS ZAEHLER DISCONNECTED
2021.01.08 16:14:51 3 : Setting ZAEHLER serial parameters to 9600,8,N,1
2021.01.08 16:14:51 3 : Init done
2021.01.08 16:14:51 1 : /dev/ttyUSB0 reappeared (ZAEHLER)
2021-01-08 16:14:51 OBIS ZAEHLER CONNECTED
2021.01.08 16:14:51 1 : /dev/ttyUSB0 disconnected, waiting to reappear (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER DISCONNECTED
2021.01.08 16:14:52 3 : Setting ZAEHLER serial parameters to 9600,8,N,1
2021.01.08 16:14:52 3 : Init done
2021.01.08 16:14:52 1 : /dev/ttyUSB0 reappeared (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER CONNECTED
2021.01.08 16:14:52 1 : /dev/ttyUSB0 disconnected, waiting to reappear (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER DISCONNECTED
2021.01.08 16:14:52 3 : Setting ZAEHLER serial parameters to 9600,8,N,1
2021.01.08 16:14:52 3 : Init done
2021.01.08 16:14:52 1 : /dev/ttyUSB0 reappeared (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER CONNECTED
2021.01.08 16:14:52 1 : /dev/ttyUSB0 disconnected, waiting to reappear (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER DISCONNECTED
2021.01.08 16:14:52 3 : Setting ZAEHLER serial parameters to 9600,8,N,1
2021.01.08 16:14:52 3 : Init done
2021.01.08 16:14:52 1 : /dev/ttyUSB0 reappeared (ZAEHLER)
2021-01-08 16:14:52 OBIS ZAEHLER CONNECTED
2021-01-08 16:14:53 OBIS ZAEHLER DISCONNECTED
2021-01-08 16:14:53 OBIS ZAEHLER CONNECTED
2021-01-08 16:14:53 OBIS ZAEHLER DISCONNECTED
2021-01-08 16:14:53 OBIS ZAEHLER CONNECTED
2021-01-08 16:14:54 OBIS ZAEHLER DISCONNECTED
I
Attributes
interval 60
room Zähler
verbose 5
Eben das Ganze noch mit dem ESP32 aufgebaut und siehe da:
...hast du den FTDI an einem Hub dran gehabt ? Das war bei mir schon mal das Problem, weshalb sich der ständig connected/disconnescted hat...
Ich kenne die Meldung vor allem von Situationen, wo ich noch ein anderes Device auf den gleichen USB-Port definiert habe.
Oder einen externen Prozess. Außerdem verwende vielleicht besser /dev/serial/by-id/ statt dem direkten Port.
Zitat von: assi05 am 08 Januar 2021, 16:20:53
Melde folgenden Teilerfolg:
- MAX3232 eingeschleift
= SHM / Sunnyportal bekommt Werte und updated auch
= OBIS-Modul bekommt Werte und updated auch
Aber es gibt noch ein Problem:
Der FTDI-Adapter connected/disconnected ständig - mehrfach pro Sekunde. Daher ist es eher Zufall, ob ein Telegramm durchkommt.
Hat jemand eine Idee, woran dieses State "connected/disconnected" liegen kann?
Das sieht doch schon mal gut aus !
Wie gvzdus schrieb, serial by-id anstelle von ttyUSB0 ist auf jeden Fall zu empfehlen !
Dann ist es nämlich egal, an welchem USB-Port der FTDI angesteckt wird, er wir immer an Hand seiner eindeutigen ID erkannt.
Serial by-id herausfinden:
Mit putty auf dem RaspberryPi einloggen.
Ins Verzeichnis /opt/fhem/log wechseln und folgenden Befehl eingeben:
ls -al /dev/serial/by-id
es sollte in etwa solch ein Eintrag dabei sein:
lrwxrwxrwx 1 root root 13 Jun 24 17:29 usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0 -> ../../ttyUSB0
"usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0" ist die ID vom FTDI.
Die Definition müsste dann etwa so aussehen:
define ZAEHLER OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0@9600 Standard
Die Baudrate (9600) anzugeben sollte reichen. Ich glaube, 8N1 ist die Standardeinstellung für RS232, brauchst Du also nicht extra angeben.
Gruß Thomas
Hi ihr Drei,
danke für den Tipp!
Probiere ich asap aus; hab den Raspi aktuell nicht mehr am Stromkasten hängen.
Meinen Signalduino hab ich so eingebunden; sollte ich hinbekommen.
Schönen Abend!
Hallo,
ich habe auch mit dem Problem zu kämpfen das der Verbrauch nicht mehr aus dem SMA Portal ins FHEM kommt.
Der SHM1 liest den Zähler per original D0- Kopf aus und überträgt die Daten auch sauber ins SMA-Portal.
ESP8266 liegt hier auch noch rum, der hat früher den Ferraris-Zählern S0 Impulse entlocken wollen.
Aber wie genau soll der physikalische Anschluß denn sein?
Einfach TX vom D0-Lesekopf parallel auf RX vom 3,3 V ESP schalten klingt sportlich und himmelt wahrscheinlich den ESP, obwohl das noch die günstigste Komponente in diesem Konstruct ist.
Viele Dank für Hinweise und viele Grüße Nico
Hallo thor3,
siehe hier:
https://forum.fhem.de/index.php/topic,51948.msg1117497.html#msg1117497 (https://forum.fhem.de/index.php/topic,51948.msg1117497.html#msg1117497)
Entweder die Transistorstufe oder den RS232 Wandler verwenden. Auf keinen Fall direkt zum ESP gehen, der würde zerstört werden !
Gruß Thomas
Hallo assi05,
ich habe einen neuen Zähler in Betrieb genommen und hatte ständig das Problem mit connected/disconnected.
Da mein Zähler ständig automatisch sendet half das Setzen des PollingModes
attr xxx pollingMode on
Ich hab einen neuen Zähler mit dem OBIS Modul in Betrieb genommen. Da die Informationen zu diesem Gerät sehr schwer zu finden waren, habe ich dies einmal zusammengefasst:
Zähler: LOGAREX LK13BE
Definiert:
define NameZaehler OBIS /dev/serial/by-id/usb-FTDI_xxx-port0@9600,7,E,1 SML
attr NameZaehler alignTime 00:00:00
attr NameZaehler channels {"1.0.14.7.0.255"=>"Freq", "1-0:1.8.0*96"=>"V01", "1-0:1.8.0*97"=>"V07", "1-0:1.8.0*98"=>"V30", "1-0:1.8.0*99"=>"V99", "1-0:1.8.0*100"=>"VG"}
attr NameZaehler extChannels on
attr NameZaehler interval 60
attr NameZaehler pollingMode on
Der Zähler sendet selbständig die Daten. Wenn der Zählerpin vorliegt, kann man am Gerät selbst, die vollständige Datenausgabe aktivieren (Inf auf on stellen). Ist dies der Fall, werden neben dem Zählerstand auch Strom, Spannung, Mommentanleistung, Frequenz, Phasenwinkel und Historische Werte ausgegeben.
Die Obiskennzahlen mit der Messgröße 81 sind die Phasenwinkel.
Der Zeitpunkt, wann die historischen Werte im Gerät gebildet werden, hängt vom Zeitpunkt ab, wann diese das letzte mal gelöscht wurden. Erfolgt das Rücksetzen (HiS CLr auf on, E CLr auf on) um 12:00 Uhr, werden die Werte entsprechend ab diesem Zeitpunkt rollierend gebildet.
Die Register für die Historischen Werte habe ich mir eigene Channels definiert.
V01 - 1 Tag
V07 - 7 Tage
V30 - 30 Tage
V99 - 365 Tage
VG - Gesamtverbrauch
Hallo ich habe das gleiche Problem wie im Zitat unten beschrieben.
Wurde bereits ein möglicher Workaround gefunden?
Nach einer kurzen Internet Recherche ist dieses Problem auf beim Volkszähler aufgetreten.
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/dzg_dvs74
https://github.com/jmberg/libsml/commit/81c4026e3d94f7a384cdd89f62a727b83269cdec
Dort gibt es einen möglichen Workaround. Dieser ist leider in der Programmiersprache C
Da ich leider nicht die nötigen Perl Kenntnisse besitze, wäre es schön, ob sich jemand bereiterklärt sich dem Thema anzunehmen.
Gruß Domenik
Zitat von: C0mmanda am 08 September 2018, 07:19:52
Moin,
ich habe einen neuen Stromzähler bekommen und versuche diesen nun auszulesen.
Es ist ein DZG DWS7412.1 mit optischer Schnittstelle.
Ich habe mir einen IR-Schrei/Lesekopf besorgt und ihn per USB mit meinem FHEM + OBIS gekoppelt.
Scheint soweit auch wunderbar zu funktionieren, ich empfange Daten.
Ich habe nur das merkwürdige Problem das ich mal plausible, mal negative Verbrauchswerte erhalte.
Eingrenzen oder reproduzieren kann ich es nicht. (OBIS zeigt z.B. -279W an während der Zähler selbst 500W anzeigt)
Der Gesamtverbrauch stimmt mit den Angaben des Zählers überein.
Ich habe keine Idee woran das liegen kann und hoffe jemand kann mir helfen.
Hier log vom gesamten Lesevorgang:
2018.09.08 07:04:50 5: SW:
2018.09.08 07:04:50 4: Wrote
2018.09.08 07:04:50 5: OBIS (Stromzaehler) - Internal timer set to 2018-09-08 07:05:20
2018.09.08 07:04:51 5: SML-Parse 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Full message-> 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 4: MSG IS:
/
1-0:96.50.1*255(DZG)
1-0:96.1.0*255(
DZGu)
1-0:1.8.0*255(36281.5*Wh)
1-0:16.7.0*255(-275.62*W)
!
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: /
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*255(DZG)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGu)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(36281.5*Wh)
2018.09.08 07:04:51 5: Msg 1-0:1.8.0*255(36281.5*Wh) is of type Counter
2018.09.08 07:04:51 4: Set total_consumption to 36281.5
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-275.62*W)
2018.09.08 07:04:51 5: Msg 1-0:16.7.0*255(-275.62*W) is of type Channels
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: !
Und ein list vom Device:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
MeterType SML
NAME Stromzaehler
NR 130
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
power:
logdb1:
TIME 1536383271.01572
VALUE -207.91
READINGS:
2018-09-08 07:07:51 1.0.96.50.1.255 DZG
2018-09-08 07:07:51 power -207.91
2018-09-08 06:55:20 state opened
2018-09-08 07:07:51 total_consumption 36300.6
helper:
BUFFER
EoM -1
SPEED
SPEED2
TRIGGERTIME 1536382520.06882
Channels:
DEVICES:
30
directions:
Attributes:
interval 30
pollingMode on
verbose 1
Zitat von: hdgucken am 08 August 2020, 01:22:07
Hallo,
habe das Modul jetzt seit einigen Tagen am laufen. Habe zwei Zähler über Netzwerk angebunden, einen über Lan (X-Port) und einen über WLAN (NodeMCU mit ESPEasy und ser2NET).
Es funktioniert alles einwandfrei bis zu einem Fhem-Neustart. Dann stehen beide Zähler auf Status "opened". Ich muss dann bei Beiden einmal das "Def" aufrufen und mit "modify" bestätigen, dann ist die Verbindung sofort wieder da. Ich meine, hier im Thread schon von dem Problem gelesen zu haben, gibt es inzwischen eine Lösung dafür ?
Gruß Thomas
Hi,
ich wollte das obige Thema nochmal ansprechen, da ich ein ähnliches Verhalten beobachte.
Ich habe u.a. 2 Zähler-Sensoren per USB an einem Raspi, auf dem Ser2Net läuft. Soweit läuft auch alles stabil. Sobald der Raspi aber mal rebootet bzw. nach Stromausfall neu startet, wird die Verbindung nicht automatisch wieder hergestellt.
(Ich "bediene" auch noch ein anderes Modul (konkret das THZ-Modul) über ser2net vom gleichen Raspi aus und dort die Verbindung automatisch wieder hergestellt)
Bei mir steht das OBIS-Modul dann auf "disconnected" und im Log steht bspw. "
192.168.41.150:20001 disconnected, waiting to reappear (StromZ1)".
Daran ändert sich solange nichts, bis ich im Modul dann "Def" aufrufe und dann mit "modify" wieder schließe. Das muß ich 2x hintereinander machen und dann läuft die Verbindung wieder stabil bis eben der Raspi neu startet.
Gibt es hierzu weitere Erfahrungen von anderen oder Lösungsansätze?
Vielen Dank schonmal und Grüße
Daniel
Hi Domenik / Gmxspooker,
ich habe es mir mal angesehen. Unter Abnahme des Versprechens "Wir testen das dann bis Serienreife" mal anbei einer Version, die vielleicht hilft.
Ist aber schwierig, das Coden, ohne es vor sich zu sehen.
Ich bastele z.Zt. an eventuellen Patchen für das Modul - ich bin nicht der Maintainer!
Wenn es helfen sollte, schicke bitte einmal einen List Deines Devices, damit man - wie im Vorbild bei vzlogger - eine Erkennung auf den DZG-Zähler einbaut - die fehlt in meiner Version auf jeden Fall noch.
Viele Grüße, Georg
Zitat von: friesenjung am 02 Februar 2021, 14:12:15
Hi,
ich wollte das obige Thema nochmal ansprechen, da ich ein ähnliches Verhalten beobachte.
Ich habe u.a. 2 Zähler-Sensoren per USB an einem Raspi, auf dem Ser2Net läuft. Soweit läuft auch alles stabil. Sobald der Raspi aber mal rebootet bzw. nach Stromausfall neu startet, wird die Verbindung nicht automatisch wieder hergestellt.
(Ich "bediene" auch noch ein anderes Modul (konkret das THZ-Modul) über ser2net vom gleichen Raspi aus und dort die Verbindung automatisch wieder hergestellt)
Bei mir steht das OBIS-Modul dann auf "disconnected" und im Log steht bspw. "192.168.41.150:20001 disconnected, waiting to reappear (StromZ1)".
Daran ändert sich solange nichts, bis ich im Modul dann "Def" aufrufe und dann mit "modify" wieder schließe. Das muß ich 2x hintereinander machen und dann läuft die Verbindung wieder stabil bis eben der Raspi neu startet.
Gibt es hierzu weitere Erfahrungen von anderen oder Lösungsansätze?
Vielen Dank schonmal und Grüße
Daniel
Hallo Daniel und Georg,
habe mich die letzten Tage auch mit dem OBIS Modul beschäftigt, weil die Verbindung zu meinen Zählern nach einem Restart zwar auf "connected" stand
aber keine Daten kamen. Habe einige kleine Änderungen beim Verbindungsaufbau gemacht und was soll ich sagen: es funktioniert jetzt !
Hänge meine Version ebenfalls mit an, vielleicht kann man ja auch die Änderungen von Georg mit einfügen, wenn alles getestet ist ;o)
@Daniel wenn "disconnected" im Status steht, konnte vom OBIS Modul (bzw. DevIo) wirklich keine Verbindung aufgebaut werden, Parameter z.B. Port falsch ?
Meine Version sollte eigentlich eine Fehlermeldung im Log erzeugen, in etwa so: "OBIS StromZ1 - error while connecting: Fehler xyz".
Gruß Thomas
Ich mische das gerne zusammen. Allerdings: Meine Version von gestern ist wirklich nur eine Version für die DZG-Zähler mit dem Bug! Da wird "hardgecodet" unter bestimmten Umständen ein Signed Int als Unsigned Int interpretiert - No go für bugfreie Zähler!
Ich habe in der Version oben noch nicht eingebaut, dass er das *nur* für die DZG-Zähler macht! Deswegen warte ich da auf Rückmeldung.
Zitat von: gvzdus am 04 Februar 2021, 14:45:51
Ich mische das gerne zusammen. Allerdings: Meine Version von gestern ist wirklich nur eine Version für die DZG-Zähler mit dem Bug! Da wird "hardgecodet" unter bestimmten Umständen ein Signed Int als Unsigned Int interpretiert - No go für bugfreie Zähler!
Ich habe in der Version oben noch nicht eingebaut, dass er das *nur* für die DZG-Zähler macht! Deswegen warte ich da auf Rückmeldung.
Ok, dann warten wir erstmal auf Rückmeldung, um den DZG-Zähler korrekt mit einzubinden !
Gruß Thomas
Zitat von: gvzdus am 03 Februar 2021, 17:06:35
Hi Domenik / Gmxspooker,
ich habe es mir mal angesehen. Unter Abnahme des Versprechens "Wir testen das dann bis Serienreife" mal anbei einer Version, die vielleicht hilft.
Ist aber schwierig, das Coden, ohne es vor sich zu sehen.
Ich bastele z.Zt. an eventuellen Patchen für das Modul - ich bin nicht der Maintainer!
Wenn es helfen sollte, schicke bitte einmal einen List Deines Devices, damit man - wie im Vorbild bei vzlogger - eine Erkennung auf den DZG-Zähler einbaut - die fehlt in meiner Version auf jeden Fall noch.
Viele Grüße, Georg
Vielen Dank Georg.
Nachdem ich dein Modul eingespielt habe funktioniert nun alles wie es soll.
Es sind keine negativen werte mehr vorhanden.
Hier ist ein List von meinem Stromzähler:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1
FUUID 60104d9e-f33f-c37e-31d8-2f948e9886b6d240
MeterType SML
NAME Stromzaehler
NEXT 2021-02-03 23:31:10
NR 64
PARTIAL
STATE 702.27 W
TYPE OBIS
READINGS:
2021-02-03 23:30:50 1.0.96.50.1.255 DZG
2021-02-03 23:30:50 Aktuelle_Leistung 702.27 W
2021-02-03 23:30:50 Aktuelle_Leistung_Gleitendermittelwert_proMinute 589.971 W
2021-02-03 23:30:50 Bezug 8277.1741 kWh
2021-02-03 23:30:50 Einspeisung 49.2908 kWh
2021-02-03 23:30:50 power 702.27
2021-02-03 22:53:38 state opened
2021-02-03 23:30:50 total_consumption 8277174.1
2021-02-03 23:30:50 total_feed 49290.8
helper:
BUFFER
EoM -1
SPEED 5
SPEED2 5
TRIGGERTIME 1612391470
Channels:
DEVICES:
10
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
directions:
Attributes:
alignTime 00:00
icon measure_power_meter
interval 10
pollingMode on
stateFormat {ReadingsVal($name,"power",0)." W"}
unitReadings off
userReadings Bezug {ReadingsNum("Stromzaehler","total_consumption",0)/1000 ." kWh"},
Einspeisung {ReadingsNum("Stromzaehler","total_feed",0)/1000 ." kWh"},
Aktuelle_Leistung {ReadingsNum("Stromzaehler","power",0)/1 ." W"},
Aktuelle_Leistung_Gleitendermittelwert_proMinute {movingAverage("Stromzaehler","power",60)/1 ." W"}
verbose 3
Ich habe auch noch einen Plot angehängt zur Verdeutlichung.
Grüße Domenik
Hi Domenik,
Danke für das Feedback! Ich sehe mal zu, heute abend das "Erkenne den DZG-Zähler und wende den Workaround nur dann an" umzusetzen.
Da wäre Deine Hilfe (Dein Test) wichtig, weil ohne "Mach' es nur bei DZG" der Patch nicht auf die Allgemeinheit losgelassen werden könnte.
Was sind die großen Pausen der Aktualisierung im rechten Teil des Graphen? "Spielen / Lesekopf wackelt" oder noch ein Software-Issue?
Viele Grüße, Georg
Zitat von: gvzdus am 04 Februar 2021, 16:51:18
Hi Domenik,
Danke für das Feedback! Ich sehe mal zu, heute abend das "Erkenne den DZG-Zähler und wende den Workaround nur dann an" umzusetzen.
Da wäre Deine Hilfe (Dein Test) wichtig, weil ohne "Mach' es nur bei DZG" der Patch nicht auf die Allgemeinheit losgelassen werden könnte.
Was sind die großen Pausen der Aktualisierung im rechten Teil des Graphen? "Spielen / Lesekopf wackelt" oder noch ein Software-Issue?
Viele Grüße, Georg
In dem Zeitraum war der Raspberry Pi nicht mit dem Stromnetz verbunden
Zitat von: hdgucken am 04 Februar 2021, 14:38:54
Hallo Daniel und Georg,
...
@Daniel wenn "disconnected" im Status steht, konnte vom OBIS Modul (bzw. DevIo) wirklich keine Verbindung aufgebaut werden, Parameter z.B. Port falsch ?
Meine Version sollte eigentlich eine Fehlermeldung im Log erzeugen, in etwa so: "OBIS StromZ1 - error while connecting: Fehler xyz".
Gruß Thomas
Hallo Thomas,
danke für die Unterstützung!
Die Verbindungsparameter stimmen, also Port etc.. Wenn man nach einem Reboot des Raspi den "Def>Modify-Workaround" anwendet funktioniert die Verbindung ja tadellos.
Ich werde Dein Modul jetzt testen und morgen Rückmeldung geben.
VG
Daniel
Moin, ich habe jetzt "Thomas", "DZG-Patch in sauber" und meinen originalen Speedpatch zusammengemischt.
Die Bitte an Domenik: Bitte testen, ob es noch immer beim "Nicht-Negativen" bleibt. ("DZG-Patch").
Die Bitte an Thomas: Habe ich richtig gemerged?
Falls beides positiv ist, könnten wir mal an Icinger rantreten und fragen, ob er übernehmen und offiziell machen mag.
Ansonsten wäre meine Idee, ein paar Readings mehr mit Namen zu versehen. Ich habe z.B. für die drei Einzelwerte der Phasen für meinen ISK-Zähler definiert:
channels: {"1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
Guten Morgen ;)
@Georg: sieht gut aus, würde ich sagen. Hab noch die Html Doku ergänzt, soll ich Dir meinen letzten Stand per pm senden, dann kannst Du das noch mit übernehmen ?
Namen für readings ist ne gute Idee :D
@Daniel: hast natürlich Recht, wenn es mit zweimal "anstoßen" funktioniert hat, kann es eigentlich nur noch am Modul gelegen haben. Bin gespannt, ob es bei Dir klappt ...
Gruß Thomas
Scheiße, es ist schon wieder morgen früh statt Abend. Ja, schick' bitte rüber, ggf. per PM.
Zitat von: gvzdus am 05 Februar 2021, 00:34:49
Scheiße, es ist schon wieder morgen früh statt Abend. Ja, schick' bitte rüber, ggf. per PM.
;D hab ich auch gerade gesehen, ist schon abgeschickt, bis morgen dann ...
Ja, mit morgen = "heute + jetzt aber schlafen gehen".
Zitat von: gvzdus am 05 Februar 2021, 00:39:26
Ja, mit morgen = "heute + jetzt aber schlafen gehen".
Stimmt, jetzt ist aber wirklich Zeit, bringe schon alles durcheinander ;D
Bis nachher ...
Moin
konnte jetzt den Workaround von gestern mit meinem DZG-Zähler testen.
Es funktioniert einwandfrei!
Die Werte stimmen nun mit dem vom Zähler überein.
Vielen Dank dafür, hätte nicht gedacht dass sich
dessen noch einer annimmt nach fast 2,5 Jahren!
Grosse Klasse! Danke!
Gruß
Zitat von: hdgucken am 05 Februar 2021, 00:17:31
...
@Daniel: hast natürlich Recht, wenn es mit zweimal "anstoßen" funktioniert hat, kann es eigentlich nur noch am Modul gelegen haben. Bin gespannt, ob es bei Dir klappt ...
Gruß Thomas
Hi Thomas,
ich konnte es mittlerweile testen, aber leider ohne Erfolg.
Die Verbindung bleibt solange auf "disconnected" bis ich entweder wieder manuell verbinde (DEF>MODIFY) oder Fhem neu starte.
Ein drittes, nicht-OBIS Device, verbindet sich hingegen weiterhin wieder automatisch.
Bei den OBIS-Devices, die sich nicht selbst wieder verbinden, taucht dann noch dieses Internal auf:
DevIoJustClosed 1Was mir noch auffällt ist, dass ich mit Deinem Modul nun recht häufig solche Medlungen im Log habe (natürlich erst dann wenn die Verbindung wieder steht):
2021.02.05 06:26:12.630 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 854.
2021.02.05 06:26:12.634 3: OBIS (StromZ2) - Unknown Message: 0-118:5.1.219*255()
Please report to User icinger at forum.fhem.de
2021.02.05 06:34:00.636 3: OBIS (StromZ2) - Unknown Message: 215-112:120.24.28*255()
Please report to User icinger at forum.fhem.deVielleicht hilft das noch...
VG
Daniel
Nimmst Du meine Version oder Thomas im Original?
Die "Please report Icinger"-Meldung könnte auf meinem Mist gewachsen sein, falls ich im Parser was falsch gemacht habe. Oder aber halt echt was Neues.
Könntest Du mal mit "verbose 5" ein oder zwei solche "Report Icinger"-Meldungen loggen?
probiert habe ich zuerst die von Thomas und dann die von Dir, welche momentan auch noch aktiv ist!
Im Anhang mal ein Mitschnitt mit Verbose 5:
11:07:40 normaler Betrieb
11:08:54 ser2net gestoppt
11:09:11 manuell neu Verbunden (exemplarisch nur für das OBIS-Device "StromZ2")
VG
Moin,
magst Du mal per Hand in 47_OBIS (welche Version auch immer) editieren und aus
#####################################
# will be executed if connection establishment fails (see DevIo_OpenDev())
sub OBIS_Callback($)
ein
sub OBIS_Callback()
machen? Sprich: Das Dollar-Zeichen weg. Dann wird nämlich vermutlich auch der Fehler beim Reconnect geloggt...
Mit den "Please report icingers" werde ich nicht schlau. Ich hatte gehofft, den Datenstrom davor zu sehen, alles danach läuft ja sauber. Kann das einfach "Dreck" sein, der beim Start der Verbindung als Fragment reinkommt und nicht interpretiert werden kann? Denn nach etwas Brauchbarem sieht das nicht aus.
Hi,
ja klar, is ja schnell gemacht.
Habs geändert und die Logs wieder angehangen:
12:35:10 per "reload 47_OBIS.pm" geändertes Modul geladen
12:37:45 ser2net gestoppt
12:38:09 manuell neu Verbunden
Diese "Please report icingers" kommen ja auch nicht ständig, nur hin und wieder. Ich glaube mit dem offiziellen Modul gab es auch so unbekannte Fehler im Log. Die sahen aber anders aus. Erst mit den von euch angepassten Module kam das mit "Please report icingers".
Ich hab mal in nem alten Log von vorgestern geschaut, da sah es (noch!?) so aus:
2021.02.03 00:55:14.548 3: OBIS - Empty datagram: .010163F8E600760501D7EF076200620072630201710163137B001B1B1B1B1A007707
2021.02.03 00:55:14.606 1: PERL WARNING: Use of uninitialized value $list[1] in hex at ./FHEM/47_OBIS.pm line 329.
2021.02.03 00:55:14.606 1: PERL WARNING: Use of uninitialized value $list[2] in hex at ./FHEM/47_OBIS.pm line 329.
2021.02.03 00:55:14.606 1: PERL WARNING: Use of uninitialized value $list[3] in hex at ./FHEM/47_OBIS.pm line 329.
2021.02.03 00:55:14.606 1: PERL WARNING: Use of uninitialized value $list[4] in hex at ./FHEM/47_OBIS.pm line 329.
2021.02.03 00:55:14.606 1: PERL WARNING: Use of uninitialized value $list[5] in hex at ./FHEM/47_OBIS.pm line 329.
Bzgl. dem "Dreck": Keine Ahnung, ob der ISKRA da was komisches mitschickt, wenn Du das meinst...
VG
Sollte es eigentlich für das "historische-Werte-Problem" inzwischen eine Lösung geben? Hab hier einen Zählern der auch eine handvoll historische Werte ausspuckt und damit dann den total_consumption mit historischen Werten überschreibt.
2021.02.05 10:28:23 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(001666.1854*kWh)
2021.02.05 10:28:23 5: Msg 1-0:1.8.0*255(001666.1854*kWh) is of type Counter
2021.02.05 10:28:23 4: Set total_consumption to 1666.1854
2021.02.05 10:28:23 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*96(00013.3*kWh)
2021.02.05 10:28:23 5: Msg 1-0:1.8.0*96(00013.3*kWh) is of type Counter
2021.02.05 10:28:23 4: Set total_consumption to 13.3
2021.02.05 10:28:24 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*97(00055.0*kWh)
2021.02.05 10:28:24 5: Msg 1-0:1.8.0*97(00055.0*kWh) is of type Counter
2021.02.05 10:28:24 4: Set total_consumption to 55
2021.02.05 10:28:24 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*98(00277.7*kWh)
2021.02.05 10:28:24 5: Msg 1-0:1.8.0*98(00277.7*kWh) is of type Counter
2021.02.05 10:28:24 4: Set total_consumption to 277.7
2021.02.05 10:28:24 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*99(00000.0*kWh)
2021.02.05 10:28:24 5: Msg 1-0:1.8.0*99(00000.0*kWh) is of type Counter
2021.02.05 10:28:24 4: Set total_consumption to 0
2021.02.05 10:28:24 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*100(01666.1*kWh)
2021.02.05 10:28:24 5: Msg 1-0:1.8.0*100(01666.1*kWh) is of type Counter
2021.02.05 10:28:24 4: Set total_consumption to 1666.1
der Zähler sendet SML.
Zitat von: gnampf am 05 Februar 2021, 16:10:34
Sollte es eigentlich für das "historische-Werte-Problem" inzwischen eine Lösung geben? Hab hier einen Zählern der auch eine handvoll historische Werte ausspuckt und damit dann den total_consumption mit historischen Werten überschreibt.
setze mal das Attribut "extChannels" auf on ...
Hallo Georg und Daniel,
brüte und probiere nun schon den ganzen Vormittag, aber bin bis jetzt nicht wirklich weiter ;(
@Georg: Das "($)" bei der callback function muss wohl so sein, meiner Meinung nach sogar eher "($$)", aber egal was ich da auch einsetze, es passiert immer das gleiche: $error ist angeblich nichts zugewiesen laut Log. Wen ich mal "@_" in der callback function abfrage, steht da auch nur "2" drinnen und kein Fehlertext, wie im DevIo Wiki beschrieben, merkwürdig. Es sollte etwas in der Art übergeben werden:
"OBIS_Callback($hash, $error)".
Probiere mal nicht weiter, die Lösung ist einfach:
Callback wird nicht nur im Fehlerfall, sondern auch im Erfolgsfall aufgerufen. Der Code ist da suboptimal. Ich bastele gerade, kann aber Dein Problem nicht nachvollziehen.
Habe mir einfach mit "netcat" 2 Pseudo-TCP-Server gebaut und fahre die hoch- und runter. Bei mir kommt nach 60 Sekunden der Reconnect-Versuch und die Dinger stehen dann wieder auf "connected".
Es kommt noch was im Laufe des Abends, ich weiß nur nicht, ob es helfen wird.
Zitat von: gvzdus am 04 Februar 2021, 22:23:45
Moin, ich habe jetzt "Thomas", "DZG-Patch in sauber" und meinen originalen Speedpatch zusammengemischt.
Die Bitte an Domenik: Bitte testen, ob es noch immer beim "Nicht-Negativen" bleibt. ("DZG-Patch").
Die Bitte an Thomas: Habe ich richtig gemerged?
Falls beides positiv ist, könnten wir mal an Icinger rantreten und fragen, ob er übernehmen und offiziell machen mag.
Ansonsten wäre meine Idee, ein paar Readings mehr mit Namen zu versehen. Ich habe z.B. für die drei Einzelwerte der Phasen für meinen ISK-Zähler definiert:
channels: {"1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
Hallo Georg,
habe das neue Modul Heute eingespielt.
Ich erhalte keine negativen Werte.
Allerdings bekomme ich folgende Fehlermeldungen beim Neuladen des Moduls:
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Initialize redefined at /opt/fhem/FHEM/47_OBIS.pm line 86.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Define redefined at /opt/fhem/FHEM/47_OBIS.pm line 107.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Get redefined at /opt/fhem/FHEM/47_OBIS.pm line 208.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Set redefined at /opt/fhem/FHEM/47_OBIS.pm line 223.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine GetUpdate redefined at /opt/fhem/FHEM/47_OBIS.pm line 251.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Init redefined at /opt/fhem/FHEM/47_OBIS.pm line 269.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Undef redefined at /opt/fhem/FHEM/47_OBIS.pm line 275.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Read redefined at /opt/fhem/FHEM/47_OBIS.pm line 284.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_trySMLdecode redefined at /opt/fhem/FHEM/47_OBIS.pm line 343.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Parse redefined at /opt/fhem/FHEM/47_OBIS.pm line 462.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Ready redefined at /opt/fhem/FHEM/47_OBIS.pm line 654.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_Attr redefined at /opt/fhem/FHEM/47_OBIS.pm line 670.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_adjustAlign redefined at /opt/fhem/FHEM/47_OBIS.pm line 753.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_hex2int redefined at /opt/fhem/FHEM/47_OBIS.pm line 784.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_CRC16 redefined at /opt/fhem/FHEM/47_OBIS.pm line 792.
2021.02.05 18:10:15 1: PERL WARNING: Subroutine OBIS_decodeTL redefined at /opt/fhem/FHEM/47_OBIS.pm line 833.
2021.02.05 18:10:21 3: OBIS (Stromzaehler) - Unknown Message: 1-0:96.50.1*255(DZG)
Please report to User icinger at forum.fhem.de
Gruß Domenik
Zitat von: gvzdus am 05 Februar 2021, 17:55:48
Probiere mal nicht weiter, die Lösung ist einfach:
Callback wird nicht nur im Fehlerfall, sondern auch im Erfolgsfall aufgerufen. Der Code ist da suboptimal. Ich bastele gerade, kann aber Dein Problem nicht nachvollziehen.
Habe mir einfach mit "netcat" 2 Pseudo-TCP-Server gebaut und fahre die hoch- und runter. Bei mir kommt nach 60 Sekunden der Reconnect-Versuch und die Dinger stehen dann wieder auf "connected".
Es kommt noch was im Laufe des Abends, ich weiß nur nicht, ob es helfen wird.
Die 60 Sekunden sind Standard, wenn nichts Anderes angegeben wird ;)
konnte es nicht lassen, diese callback scheint ok zu sein :)
sub OBIS_Callback($;$)
{
my ($hash, $error) = @_;
my $name = $hash->{NAME};
# create a log emtry with the error message
Log 3,"OBIS $name - error while connecting: $error" if ($error);
return undef;
}
P.S. Diese Callback funktioniert, hab getestet ;o)
@Domenik:
ZitatAllerdings bekomme ich folgende Fehlermeldungen beim Neuladen des Moduls:
Die "redefined" sind strunznormal beim reload des Moduls. Bestimmte Dinge (kann ich aber nicht beschreiben) erfordern aber einen harten Shutdown-Restart.
Das "...report to user icinger" ist großer Mist. Das habe ich persönlich wieder aktiviert, er hatte es deaktiviert. Geht natürlich gar nicht, fehlt nur, dass ich noch seine Handynummer reinschreibe (wenn ich sie hätte). Ist jetzt raus. Aber ich logge trotzdem alles, was nur als Zahlen in den Readings auftaucht.
@Daniel:
Ich habe in der Version jetzt mal bei dem Reopen so rumgefummelt, wie es die anderen Kinder in ihren Modulen machen. Guck doch bitte mal, ob es was bringt!
@gnampf:
Klar, wir haben gerade Wünsch-Dir-Was-Tage :-) Wenn der Tipp mit extChannels nicht hilft, sag' Bescheid.
Außerdem ist in der Version jetzt die Hilfe eingepflegt und korrigiert.
@Georg: die OBIS_Ready function hatte ich völlig vergessen, hab ich auch angepasst auf ser2net. Die wird aufgerufen, wenn die Verbindung nicht aufgebaut werden konnte, also bei Status "disconnected". Dafür musste ich meine Variable "$netdev" modulweit verfügbar machen, steht deshalb jetzt ganz am Anfang des Moduls.
Hab jetzt noch folgenden Fehler neu:
2021.02.05 19:32:09 1: PERL WARNING: Use of uninitialized value $code in concatenation (.) or string at ./FHEM/47_OBIS.pm line 536
Ja, ich habe das ReadyFN angepasst und da auch den Reopen-Parameter auf 1 gesetzt - vielleicht bringt das was.
Nein, das mit der globalen Variable ist mir nicht aufgefallen. Das habe ich in meiner Variante ja in den Hash reingezogen. Das ist m.E. auch sauberer, denn wen schon Leute 3 Zähler damit auslesen, vielleicht mischen dann andere OBIS-Over-Net mit OBIS-USB. Und "netdev" ist etwas allgemein für global.
Der "neue" Fehler ist vermutlich mein Versuch, die Vendor-Zeile mit dem DSZ-Zähler als "ManufID2" zu deklarieren. Vielleicht Mist. Kannst Du die Zeile oben mit "ManufID2" mal löschen?
Zitat von: gvzdus am 05 Februar 2021, 19:54:57
Ja, ich habe das ReadyFN angepasst und da auch den Reopen-Parameter auf 1 gesetzt - vielleicht bringt das was.
Nein, das mit der globalen Variable ist mir nicht aufgefallen. Das habe ich in meiner Variante ja in den Hash reingezogen. Das ist m.E. auch sauberer, denn wen schon Leute 3 Zähler damit auslesen, vielleicht mischen dann andere OBIS-Over-Net mit OBIS-USB. Und "netdev" ist etwas allgemein für global.
Der "neue" Fehler ist vermutlich mein Versuch, die Vendor-Zeile mit dem DSZ-Zähler als "ManufID2" zu deklarieren. Vielleicht Mist. Kannst Du die Zeile oben mit "ManufID2" mal löschen?
Das sieht doch viel professioneller aus, bin nicht ganz so per Du mit Perl ;)
Habe gerade getestet, die Zeile mit "ManufID" ist auskommentiert. Funktioniert soweit, bis auf den Fehler in Zeile 536, der bleibt. In "$code" ist nichts drin :o
siehe hier im Log:
2021.02.05 21:06:10 3: Storing for 1-0:1.8.0*96 in Cache
2021.02.05 21:06:10 3: Storing for 1-0:1.8.0*97 in Cache
2021.02.05 21:06:10 3: Storing for 1-0:1.8.0*98 in Cache
2021.02.05 21:06:10 3: Storing for 1-0:1.8.0*99 in Cache
2021.02.05 21:06:10 3: Storing for 1-0:1.8.0*100 in Cache
Nachtrag: In der html Hilfe fehlt jeweils beim "Example" am Ende der ersten Zeile ein <br> für den Zeilenumbruch, sonst perfekt :)
hdgucken:
perfekt, extChannels auf on hat geholfen und stellt mir jetzt einzelne Readings zur Verfügung!
gvzdus:
also wenn wir wünsch dir was haben: ich wünsche mir eine Beschreibung der Attribute die FHEM dann anzeigt ;-)
Zitat von: gnampf am 05 Februar 2021, 21:34:14
hdgucken:
perfekt, extChannels auf on hat geholfen und stellt mir jetzt einzelne Readings zur Verfügung!
gvzdus:
also wenn wir wünsch dir was haben: ich wünsche mir eine Beschreibung der Attribute die FHEM dann anzeigt ;-)
@gnampf: super, das Problem kannte ich ;)
@Georg: Ich hab mir das mit Zeile 533 nochmal angesehen, meintest Du vielleicht "$c" statt "$code" ?
Hab ich mal geändert, jetzt siehts so aus:
2021.02.05 22:07:13 3: Storing Counter for 1-0:1.8.0*96 in Cache
2021.02.05 22:07:13 3: Storing Counter for 1-0:1.8.0*97 in Cache
2021.02.05 22:07:13 3: Storing Counter for 1-0:1.8.0*98 in Cache
2021.02.05 22:07:13 3: Storing Counter for 1-0:1.8.0*99 in Cache
2021.02.05 22:07:13 3: Storing Counter for 1-0:1.8.0*100 in Cache
Gruß Thomas
Beim 15. Mal drauf gucken ist es mir auch aufgefallen :-)
Hier jetzt die noch bessere Edition:
a) Kein Warning-Geplärre
b) Zeilenumbruch in der Hilfe
c) Die "Unknown Message" message kommt jetzt für jede Sequenz nur einmal.
Ich selber habe z.B. das hier im Logfile:
Unknown Message: 215-112:120.24.28*255()
Zitat von: gvzdus am 05 Februar 2021, 19:40:13
...
@Daniel:
Ich habe in der Version jetzt mal bei dem Reopen so rumgefummelt, wie es die anderen Kinder in ihren Modulen machen. Guck doch bitte mal, ob es was bringt!
...
Außerdem ist in der Version jetzt die Hilfe eingepflegt und korrigiert.
nabend zusammen,
habs gerade ausgiebig getestet, leider ohne Erfolg. :'(
keine Ahnung was da noch reinspielen könnte. Ich habe nochmal ein Log angehangen. Der Disconnect war bei 22:21:11.
VG
Naja, der Log zeigt ja als allerletzte Zeile:
2021.02.05 22:22:11.638 1: 192.168.41.150:20010 reappeared (Mythz)
Also genau nach den zu erwartenden 60 Sekunden probiert er es wieder und findet das Device. Eigentlich wird es ja dann erst spannend: Da kommt dann im Folgenden nichts mehr von Mythz? Vorher ist Mythz im Logfile aber auch nicht die Plappersuse im Vergleich zu StromZ1.
Ich glaube übrigens, verbose 4 reicht.
Zitat von: friesenjung am 05 Februar 2021, 22:28:55
nabend zusammen,
habs gerade ausgiebig getestet, leider ohne Erfolg. :'(
keine Ahnung was da noch reinspielen könnte. Ich habe nochmal ein Log angehangen. Der Disconnect war bei 22:21:11.
VG
StromZ2 hat sich wieder verbunden, oder hast Du Ihn von Hand angestoßen ?
Gruß Thomas
also soll ich beim THZ Device auch mal mit Verbose 4 mitloggen? Hatte bis jetzt immer nur das OBIS-Dev auf Verbose.
Noch ne Kleinigkeit. Ich hab die letzte Version noch eingespielt und nun habe ich noch ein wohl "neues" Internal: CRC_Errors 2 oder hab ich das bis jetzt gekonnt übersehen?
BTW. Danke im Übrigen für Eure Mühen!!!
Zitat von: hdgucken am 05 Februar 2021, 22:43:40
StromZ2 hat sich wieder verbunden, oder hast Du Ihn von Hand angestoßen ?
Gruß Thomas
hi,
ja, manuell verbunden
Also, der Reihe nach:
- Bitte richtiger Stop/Start von FHEM. Reload ist so ein Code-Refresher, es bleiben aber Daten erhalten, oder so
- Dir ist klar: Per Default wird nur minütlich ein Reconnect versucht?
- FHEM ist halbwegs aktuell? Ich arbeite mit irgendwas im Alter von ca. 7 Tagen
- Was ist das "Nicht-OBIS-Device", das funktioniert, für ein Device?
- Kannst Du uns die Devices noch mal kurz vorstellen? In welchem Intervall senden sie im "gesunden" Zustand?
Zitat von: gvzdus am 05 Februar 2021, 22:59:14
Also, der Reihe nach:
- Bitte richtiger Stop/Start von FHEM. Reload ist so ein Code-Refresher, es bleiben aber Daten erhalten, oder so
- Dir ist klar: Per Default wird nur minütlich ein Reconnect versucht?
- FHEM ist halbwegs aktuell? Ich arbeite mit irgendwas im Alter von ca. 7 Tagen
- Was ist das "Nicht-OBIS-Device", das funktioniert, für ein Device?
- Kannst Du uns die Devices noch mal kurz vorstellen? In welchem Intervall senden sie im "gesunden" Zustand?
ok, also:
- richtiger Start/Stop eben ausgeführt > getestet > gleiches Verhalten
- ja, hab auch schon mehrere Minuten gewartet
- FHEM ist aktuell (heut Nachmittag Update ausgeführt)
- Nicht-OBIS-Device ist meine Wärmepumpe, die am gleichen Raspi mit ser2net hängt. das Modul ist das 00_THZ.pm von immi
- Devices:
- das NICHT-OBIS (THZ-Modul) pollt verschiedene readings (alle Minute oder 5 Min, je nach Reading
- die beiden anderen sind die OBIS-Devs (StromZ1 und StromZ2) > je ein ISKRA MT681 Zweirichtungszähler mittels SML permanent Daten ausgelesen, also kein Polling. Dementsprechend habe ich auch kaum Attribute gesetzt (Device-spezifisch: channels, unitReadings; allgemeine Attr: event-on-change-reading, stateFormat, usw.)
Zitat von: friesenjung am 05 Februar 2021, 23:32:14
ok, also:
- richtiger Start/Stop eben ausgeführt > getestet > gleiches Verhalten
- ja, hab auch schon mehrere Minuten gewartet
- FHEM ist aktuell (heut Nachmittag Update ausgeführt)
- Nicht-OBIS-Device ist meine Wärmepumpe, die am gleichen Raspi mit ser2net hängt. das Modul ist das 00_THZ.pm von immi
- Devices:
- das NICHT-OBIS (THZ-Modul) pollt verschiedene readings (alle Minute oder 5 Min, je nach Reading
- die beiden anderen sind die OBIS-Devs (StromZ1 und StromZ2) > je ein ISKRA MT681 Zweirichtungszähler mittels SML permanent Daten ausgelesen, also kein Polling. Dementsprechend habe ich auch kaum Attribute gesetzt (Device-spezifisch: channels, unitReadings; allgemeine Attr: event-on-change-reading, stateFormat, usw.)
versuch mal bitte pollingMode: on und interval: 30 z.B.
So, ich habe bei mir umgebaut auf ser2net.
Version: 3.5 (Raspian Default)
Config:
20001:raw:0::/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0:9600 NONE 1STOPBIT 8DATABITS
defmod auf meinen Stromzähler:
defmod MT175 OBIS 127.0.0.1:20001
Funktioniert. ser2net abgeschossen, neu gestartet. Reconnected sauber nach 60 Sekunden.
FHEM vorher noch einmal aktualisiert.
Außerdem habe ich herausgefunden, dass der Großmeister mit ser2net schon mal geflucht hat: https://forum.fhem.de/index.php?topic=54732.0
Beide Stromzähler sollten übrigens nach dem Disconnect und vor dem Reconnect unter "Internals" einen Eintrag "NEXT_OPEN
1612598162.3827" haben. Zeit natürlich variierend. Ist das der Fall?
Polling-Mode kann man ja probieren, ich mag den aber nicht. Mein nächster Versuchsaufbau wäre dann mit tcpdump, ob ein Connect-Versuch erfolgt oder nicht. Und dann Rudi zu fragen - falls Du (friesenjung) Durchhaltevermögen hast.
Zitat von: hdgucken am 06 Februar 2021, 00:37:12
versuch mal bitte pollingMode: on und interval: 30 z.B.
Moin,
hab ich probiert. Richtig gearbeitet hat der Polling Mode erst nach einem Fhem-Neustart (nur als RandInfo). Danach hat der PollingMode das gemacht was er sollte > alle 30 Sekunden einen Messwert "geholt".
Leider kommt die Verbindung nach einer Unterbrechung auch nicht wieder hoch. Hab mehrere Minuten gewartet.
VG
Okay, was ist mit dem "NEXT_OPEN"?
Kennst Du Dich mit "tcpdump" aus? Falls nicht: Die Pakete solltest Du mit
sudo tcpdump -n host 192.168.41.150 and port 20001
sehen können.
Kommt nach dem Disconnect noch *irgendwas*, vor allem 60 Sekunden nach dem Shutdown?
Zitat von: gvzdus am 06 Februar 2021, 09:04:32
...
Beide Stromzähler sollten übrigens nach dem Disconnect und vor dem Reconnect unter "Internals" einen Eintrag "NEXT_OPEN
1612598162.3827" haben. Zeit natürlich variierend. Ist das der Fall?
Polling-Mode kann man ja probieren, ich mag den aber nicht. Mein nächster Versuchsaufbau wäre dann mit tcpdump, ob ein Connect-Versuch erfolgt oder nicht. Und dann Rudi zu fragen - falls Du (friesenjung) Durchhaltevermögen hast.
Moin, also was sofort auffällt ist, dass ich dieses Internal "NEXT_OPEN"
nicht habe! siehe Anhang...
Und ja, Durchhaltevermögen hab ich. Sowas fuchst mich, ich will wissen woran das liegt ;)
Vielleicht noch weitere Infos zu meinem System:
Wie in meiner Signatur ja schon ersichtlich, läuft mein FHEM im Docker auf einer Synology, was ja aber kein Grund für dieses Prob sein sollte, zumal andere Devs ja wieder konnekten.
Ansonsten ist die Version vom ser2net 3.5-2
VG
tcpdump kannst Du Dir sparen.
Wenn Du magst, lies die DevIo-Doku von Rudi:
Hat sich ein Gerät disconnected, wird periodisch die "ReadyFn"-Funktion des Moduls aufgerufen. Die sollte dann wieder DevIo_OpenDev aufrufen. NEXT_OPEN wird dort geschrieben. Frage ist für mich nun: Wird ReadyFN überhaupt aufgerufen? Bei mir passiert das mehrmals die Sekunde.
Könntest Du bitte in "meinem" Modul bei Zeile 656 die folgende Log3-Zeile einbauen?:
#####################################
sub OBIS_Ready($)
{
my ($hash) = @_;
Log3 1, $hash->{NAME}, "ReadyFn for " . $hash->{NAME} . " called, state is " . $hash->{STATE};
return DevIo_OpenDev($hash, 1, "OBIS_Init", $hash->{helper}{NETDEV} ? "OBIS_Callback" : undef)
if($hash->{STATE} eq "disconnected");
Das produziert nach einem Disconnect 1 Minute lang massenhaft die ReadyFn-Zeile, dann kommt der Connect:
2021.02.06 13:16:56 MT175: ReadyFn for MT175 called, state is disconnected
2021.02.06 13:16:56 MT175: ReadyFn for MT175 called, state is disconnected
2021.02.06 13:16:58 MT175: ReadyFn for MT175 called, state is disconnected
2021.02.06 13:16:58 3: Init done
2021.02.06 13:16:58 1: 127.0.0.1:20001 reappeared (MT175)
Falls die Zeile (trotz Restart von FHEM) nicht kommt, ist das wohl Rudi-pflichtig.
Zitat von: friesenjung am 06 Februar 2021, 13:00:15
Moin,
hab ich probiert. Richtig gearbeitet hat der Polling Mode erst nach einem Fhem-Neustart (nur als RandInfo). Danach hat der PollingMode das gemacht was er sollte > alle 30 Sekunden einen Messwert "geholt".
Leider kommt die Verbindung nach einer Unterbrechung auch nicht wieder hoch. Hab mehrere Minuten gewartet.
VG
@Daniel: Ok, war einen Versuch wert, aber dachte ich mir schon, schade ;o)
Ich habe gerade bei mir festgestellt, wenn ich den Netzwerkstecker (Zaehler2) abziehe oder die NodeMCU(WLAN) ausschalte (Zaehler1), passiert einfach nichts !
Es bleiben alle Readings einfach auf dem letzten Stand stehen. Stecke ich den Stecker wieder ein oder schalte die NodeMCU wieder ein, bleibt das so,
kein reconnect oder ähnliches ! Heißt: DevIo bekommt nicht mit, dass eine Verbindung verloren geht und stellt demzufolge auch keine wieder her.
Mache ich einen fhem Restart, und lasse ein Gerät ohne Verbindung, meldet DevIo, dass keine Verbindung aufgebaut werden konnte und versucht nach 60 sec erneut zu verbinden.
In den Internals steht dann auch NEXT_OPEN ... Wenn das Gerät wieder verbunden wird, kommt nach spätestens nach 60 sec der Connect und alles läuft wieder.
Das schaue ich mir gleich genauer an ...
Zitat von: gvzdus am 06 Februar 2021, 13:24:07
tcpdump kannst Du Dir sparen.
ok,
hab die Zeile eingebaut und diese ReadyFn kommt. HIer ein Log-Auszug
2021.02.06 14:02:55.837 1: 192.168.41.150:20002 disconnected, waiting to reappear (StromZ2)
2021.02.06 14:02:55.847 1: 192.168.41.150:20010 disconnected, waiting to reappear (Mythz)
2021.02.06 14:02:55.860 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 2308 W / rein: 2984 kWh / raus: 3183 kWh / disconnected
2021.02.06 14:02:55.860 1: PERL WARNING: Argument "StromZ2" isn't numeric in numeric gt (>) at fhem.pl line 974.
2021.02.06 14:02:55.860 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 2258 W / rein: 713 kWh / raus: 3410 kWh / disconnected
2021.02.06 14:02:55.871 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 2308 W / rein: 2984 kWh / raus: 3183 kWh / disconnected
.
.
.
2021.02.06 14:03:56.005 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 2308 W / rein: 2984 kWh / raus: 3183 kWh / disconnected
2021.02.06 14:03:56.005 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 2258 W / rein: 713 kWh / raus: 3410 kWh / disconnected
2021.02.06 14:03:56.022 1: 192.168.41.150:20010 reappeared (Mythz)
2021.02.06 14:03:56.064 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 2308 W / rein: 2984 kWh / raus: 3183 kWh / disconnected
2021.02.06 14:03:56.065 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 2258 W / rein: 713 kWh / raus: 3410 kWh / disconnected
.
.
.
2021.02.06 14:05:47.375 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 2258 W / rein: 713 kWh / raus: 3410 kWh / disconnected
2021.02.06 14:05:47.376 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 2258 W / rein: 713 kWh / raus: 3410 kWh / disconnected
2021.02.06 14:05:50.254 3: Opening StromZ2 device 192.168.41.150:20002
2021.02.06 14:05:50.264 3: Init done
2021.02.06 14:05:50.265 3: StromZ2 device opened
14:03:56 kommt die THZ wieder und am Ende dann wieder mein manueller Connect...
VG
Die ready function wird ständig durchlaufen, selbst wenn der Zähler verbunden ist ! Mein Log ist jetzt ca. 1km länger ;)
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
usw.
DevIo kann natürlich kein "disconnected" erkennen, weil disconnected nicht im Status erscheint, selbst, wenn das Gerät getrennt wird.
uaaaah,
ich fass es nicht, entferne ich stateFormat, geht es!!! :o
2021.02.06 14:15:59.621 1: 192.168.41.150:20010 reappeared (Mythz)
2021.02.06 14:15:59.633 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 5264 W / rein: 2985 kWh / raus: 3183 kWh / disconnected
2021.02.06 14:15:59.636 3: Init done
2021.02.06 14:15:59.636 1: 192.168.41.150:20002 reappeared (StromZ2)
habe das stateFormat nur für Zähler2 entfernt...gibts das?
Zitat von: hdgucken am 06 Februar 2021, 14:17:52
Die ready function wird ständig durchlaufen, selbst wenn der Zähler verbunden ist ! Mein Log ist jetzt ca. 1km länger ;)
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:40 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
2021.02.06 14:13:41 Zaehler2: ReadyFn for Zaehler2 called, state is erzeugt: 7473kWh, Leistung: 295W
usw.
wenn der Zähler wieder auf open ist, kommt die Meldung bei mir nicht mehr...
Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?
Wenn Du Dir die Perl-Zeile anguckst:
if($hash->{STATE} eq "disconnected");
Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.
Zur "Stecker-Zieh"-Problematik:
Das ist ein generelles Problem. Vor allem, bei uns ja nur gelesen wird. Würde auch regelmäßig geschrieben, würde FHEM irgendwann auffallen, dass die Gegenseite nicht mehr antwortet.
Es gibt 2 Workarounds:
- TCP Keepalive zu nutzen. Damit würde es immerhin - bei typischen Default-Werten - nach ein paar Stunden auffallen. Nachteil: Lässt sich m.W. bei Rasbian nur global parametrisieren
- Einen "Lebenszeichen"-Timer setzen: Kommt 5 Minuten nichts an, wird die Verbindung einmal geclosed und neu aufgebaut
Zitat von: gvzdus am 06 Februar 2021, 14:20:21
Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?
Wenn Du Dir die Perl-Zeile anguckst:
if($hash->{STATE} eq "disconnected");
Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.
Gerade getestet: ohne stateformat, Status opened, Stecker gezogen, Status bleibt opened ! Gerät verbindet sich also auch nicht neu.
Ja, siehe oben: Ein sehr generelles Problem bei "Read-Only" TCP-Verbindungen!
Auf jeden Fall wissen wir jetzt schon mal: Das "stateformat" macht den Reconnect bei "sauberem Shutdown statt Steckerziehen" kaputt.
Zitat von: gvzdus am 06 Februar 2021, 14:31:55
Ja, siehe oben: Ein sehr generelles Problem bei "Read-Only" TCP-Verbindungen!
Auf jeden Fall wissen wir jetzt schon mal: Das "stateformat" macht den Reconnect bei "sauberem Shutdown statt Steckerziehen" kaputt.
Stimmt, an das stateformat hatte ich schon mal gedacht, bin leider wieder von abgekommen ;D
Jetzt müssen wir uns was einfallen lassen, wie wir den Verbindungsverlust mitbekommen ...
Aus CPU-Gründen würde ich sagen:
1) Ein Internal "LastMessageTime", das bei jedem Datenpaket auf gettimeofday gesetzt wird
2) Ein Attribut "deadManTimeout" in Sekunden
2) Ein 60-Sekunden-Intervall-Job, der prüft, ob "gettimeofday - LastMessageTime > deadManTimeout". Wenn ja, close + open
Erscheint mir billiger, als bei jedem Paket einen InternalTimer zu starten und den alten zu löschen.
Update: Ich habe mal in der Entwickler-Ecke gefragt...
Zitat von: gvzdus am 06 Februar 2021, 14:20:21
Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?
...
Mann o mann, irre was alles so beeinflussende Faktoren sein können. Bin zwar nicht der große Programmierer, aber wenn du mir die Code-Zeile so "präsentierst" macht auf einmal alles Sinn. Immerhin ist das Problem gefunden und man kann reagieren.
Danke an der Stelle also nochmal für Eure Zeit und Mühen!!!!
In Deiner Code-Zeile prüfst Du ja auf
STATE was zu guter letzt ja das stateFormat übernimmt. Der Reading
state bleibt davon unberührt, also dort steht weiterhin "open" oder "disconnected". Vermutlich ist es aber auch keine Lösung hier auf "state" zu prüfen.
Also mein stateFormat sieht so aus:
{sprintf("aktuell: %.0f W", ReadingsVal($name,"power",0) ) . " / " . sprintf("rein: %.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " / " . sprintf("raus: %.0f kWh", (ReadingsVal($name,"total_feed",0) / 1000) ) . " / ". ReadingsVal($name,"state",0)}
Vom stateFormat verabschieden ginge schon, dann muss ich abwägen zwischen Funktionalität und schöner Anzeige direkt im Device...
VG
Mir ist noch was aufgefalen: sollte im STATE nicht "CONNECTED" stehen, wenn die Verbindung aufgebaut wurde ? Tut es nämlich nicht.
Laut DevIo sollte es aber so sein, suche gerade nach der Ursache.
Dann hab ich schon immer die folgende Fehlermeldung im Log:
PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 855, <$fh> line 3876.
wenn wir schon mal dabei sind, vielleicht kriegen wir das auch noch weg :)
Habe plötzlich auch die Readings feed_L1, feed_L2 und feed_L3, obwohl mein Zähler die definitiv nicht sendet und dann auch noch mit falschen Werten,
siehe Bild. Da muss beim parsen was irgendwas schieflaufen, die Readings sind auch schon etwas älter.
Bei mir steht im STATE opened bzw disconnected (wenn kein stateFormat angelegt ist), jedoch nie "connected"
Wegen der "Stecker-Zieh"-Problematik...um das zu verstehen habe ich eben auch mal getestet. Es gäbe ja 2 Möglichkeiten:
Gerät war auf opened und Kommunikation lief problemlos:
> nun habe ich zuerst mal den USB-Stecker am ser2net-Raspi gezogen: Resultat waren ständige disconnects und reappers im Sekundentakt > dann den Stecker wieder dran und er hat sich wieder richtig verbunden.
> Lan-Stecker am ser2net-Raspi gezogen, da war Stille. Da ich kein Polling aktiv habe war das auch korrekt, kamen halt keine Pakete mehr rein. Lan-Stecker wieder dran und die Kommunikation lief weiter
In Deinem Fall 2 "wissen" ja auch Client (FHEM) und Server (ser2net) voneinander, daher läuft es wieder an.
Wenn Du einen Fall 3 nimmst: "Steckerziehen" beim Server: Dann könnte es ewig hängen, weil der Client auf Pakete wartet, während der Server neu gestartet auf eine neue Verbindung wartet.
P.S.:
https://forum.fhem.de/index.php/topic,118547.0.html (https://forum.fhem.de/index.php/topic,118547.0.html) - Chef sagt: "Mach' selber im Modul". Dann mal loslegen...
mh, was die Antwort von Chefe bedeutet, da müsstest Du mir kurz auf die Sprünge helfen. Da komm ich tlws. nich mehr mit. Betrifft es das Problem, was wir mit "stateFormat entfernen" "gelöst haben oder eher das "Stecker ziehen Problem" oder n´beiden?
Zitat von: gvzdus am 06 Februar 2021, 14:20:21
Jo, dann ist auch klar, was das Problem ist:
Wie kommt der "Rein/Raus-State" bei Dir rein?
Wenn Du Dir die Perl-Zeile anguckst:
if($hash->{STATE} eq "disconnected");
Das bedeutet: Nur, wenn der State genau "disconnected" ist, dann wird der Open gemacht. Bei Dir endet es aber nur auf disconnected.
Ich würde jetzt eher sagen: "Kannst Du Dich vom State-Überbügeln verabschieden?". Dieser Vergleich auf "disconnected" ist ziemlicher Standard über viele Module.
ich bin da jetzt mal recht pragmatisch rangegangen und habe die Zeile in
if($hash->{STATE} = ".*disconnected.*");geändert, was bei mir dazu führt, dass der Reconnect auch mit (MEINEM) stateFormat funktioniert. Mir fehlt da ein wenig der Weitblick bzw. die Erfahrug, ob das ein Ansatz wäre. Zumal ja ein stateFormat auch ganz ohne die Info zu
opened/disconnected auskommen kann.
Grüße
Das ist eher so mitteloptimal, Deine Lösung. Wenn ich das richtig lese, vergleichst Du nichts, und wendest keine Suche an, sondern setzt schlichtweg STATE auf ".*disconnected.*" :-)
Nimm' mal lieber die angehängte Version... Die verhält sich wie von mir beschrieben: Kommen für "resetAfterNoDataTime" Sekunden keine Daten an, wird die Verbindung getrennt und neu initialisiert. Default: 90 Sekunden. Prüfung alle 60 Sekunden, also worst case nach 259 Sekunden.
Es sollte in allen Fällen greifen, auch mit friesischem State-Format!
Hoffe, Ihr habt noch Strom zum Testen! In Grevenbroich ging vor 30 Minuten der Eisregen runter.
P.S. Upps, Moment...
P.P.S. Jetzt aber.
jo,
funktioniert :)
2021.02.06 22:23:02.629 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 563 W / rein: 723 kWh / raus: 3410 kWh / disconnected
2021.02.06 22:23:02.630 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 627 W / rein: 3004 kWh / raus: 3183 kWh / disconnected
2021.02.06 22:23:02.654 StromZ2: ReadyFn for StromZ2 called, state is aktuell: 563 W / rein: 723 kWh / raus: 3410 kWh / disconnected
2021.02.06 22:23:02.654 StromZ1: ReadyFn for StromZ1 called, state is aktuell: 627 W / rein: 3004 kWh / raus: 3183 kWh / disconnected
2021.02.06 22:23:02.655 3: No data received for 98 seconds, resetting connection
2021.02.06 22:23:02.656 3: No data received for 98 seconds, resetting connection
2021.02.06 22:24:02.656 3: No data received for 158 seconds, resetting connection
2021.02.06 22:24:02.658 3: No data received for 158 seconds, resetting connection
2021.02.06 22:24:02.660 3: Init done
2021.02.06 22:24:02.661 1: 192.168.41.150:20002 reappeared (StromZ2)
2021.02.06 22:24:02.671 3: Init done
2021.02.06 22:24:02.671 1: 192.168.41.150:20001 reappeared (StromZ1)
Der Log-Eintrag für die ReadyFN Funktion ist aber noch drin ;)
Zitat von: gvzdus am 06 Februar 2021, 21:53:51
Das ist eher so mitteloptimal...
Das dachte ich mir schon, war quasi mein erster Code für überhaupt ein Fhem-Modul ;D
VG
PS: Strom ist noch da, da mein Forenname nicht direkt nen geografischen, sondern eher andere Gründe hat - wohne nahe Mainz :)
Zitat von: friesenjung am 06 Februar 2021, 22:33:12
Der Log-Eintrag für die ReadyFN Funktion ist aber noch drin ;)
Krutzifix! Habe die Datei ausgetauscht. Du weisst ja, was wo löschen.
N'Abend Jungs, mußte mich mal etwas um die Familie kümmern :)
Das sieht doch schon super aus, langsam wird es zum (fast) perfekten Modul ;)
Das mit dem "CONNECTED" war nicht ganz korrekt vorhin, DevIo schickt einen Event an das OBIS Modul mit "CONNECTED", das könnte man dann in der function OBIS_Notify verarbeiten. Wäre vielleicht auch noch ein Ansatz ?!
Positive Rückmeldung auch von mir, Modul läuft soweit und der Fehler ist jetzt verschwunden:
PERL WARNING: main::OBIS_decodeTL() called too early to check prototype at ./FHEM/47_OBIS.pm line 855, <$fh> line 3876.
also noch ein Problem abgehakt :)
Habe die OBIS_init etwas besser gemacht:
sub OBIS_Init($)
{
my ($hash) = @_;
Log 3,"$hash->{NAME} Init done";
return undef;
}
Damit weiß man, wenn man ins Log schaut, welches Gerät initialisiert wurde ;)
Könnte man evtl. auch noch Loglevel-abhängig machen.
Komm' - dann schon konsequent :-)
Logging ist in der angehängten Version durchgängig angepasst - und ich hoffe, die CPU-Last etwas weiter reduziert.
Außerdem habe ich jetzt die standardisierten Werte für die Phasen-Leistung aufgenommen, die "wir ISKRA"-Nutzer immer per Hand / channels eingeben:
my %OBIS_channels = (
"21" =>"power_L1", # Positive active instantaneous power
"36" =>"power_L1", # Sum active instantaneous power
"41" =>"power_L2",
"56" =>"power_L2",
"61" =>"power_L3",
"76" =>"power_L3",
Quelle: https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm (https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm)
Modul geht jetzt bei mir einwandfrei ohne Fehler. Tolle Arbeit, vielen Dank !
Hallo Leute,
na, hier tut sich ja einiges :)
Kurz zur Info an alle: Ich hatte gerade ein längeres Telefonat mit Georg (gvzdus).
Er ist hier ja grade sehr aktiv ist und durchaus an der Weiterentwicklung interessiert. Im Gegensatz dazu fehlt mir einfach die Zeit dafür.
Ich habe ihm angeboten, die Maintainerschaft für das Modul zu übernehmen. Ich denke, das ist durchaus im Sinne der gesamten Community hier.
Somit gehört das 47_OBIS ab sofort ganz offiziell nicht mehr mir, sondern Georg. Rudi wurde ebenfalls schon darüber informiert.
Liebe Grüße aus dem aktuell sehr vereisten Weinviertel,
Stefan
Herzlichen Dank für das Vertrauen, und ich möchte dann hiermit einmal klar feststellen:
Alle wesentlichen Funktionen des Codes sind unverändert von Stefan - falls sich jemand zum neuen Maintainer berufen fühlt - spätestens, wenn ich alt, griesgrämig und völlig untätig werde - soll es an Stefan sein, ggf. den neuen Maintainer zu berufen. Also: Ich "verwalte", "gehören" tut es für mich unverändert Stefan.
Dann möchte ich herzlich Mitleser bitten, die letzte Version hier im Thread zu testen. Denn ich werde sie dann morgen einchecken (1 Tag Warnfrist will ich noch lassen) - und dann lesen wir ja schon übermorgen hier, was der Neue alles so kaputt gemacht hat :-)
Und zum anderen: Herzlich gerne Code-Schnippsel beisteuern, oder wie beim DZG-Zähler ausgraben: "So kann man das machen - ich kann nur nicht selber programmieren".
Zitat von: gvzdus am 07 Februar 2021, 14:07:36
Und zum anderen: Herzlich gerne Code-Schnippsel beisteuern, oder wie beim DZG-Zähler ausgraben: "So kann man das machen - ich kann nur nicht selber programmieren".
Ich hätte da ne komplette, neue Routine zum Zerlegen der Nachrichten. Ist aber nicht im Modul, sondern als extra Perl-Programm. Das ganze kommt komplett ohne RegEx aus und kann kontinuierlich mit den Daten gefüttert werden. Leider stehe ich mit Perl absolut auf Kriegsfuß und habe das ganze dann erst mal wieder weggelegt.
Ich hänge das hier einfach mal ran (inklusive meiner Beispieldaten) - vielleicht kannst Du es ja gebrauchen.
$ perl sml.pl sml.bin
76 - 06
05 00 86 c6 3e
62 00
62 00
72 - 02
63 01 01
76 - 06
01
07 ff ff ff ff ff ff
05 00 2c ec c0
0b 0a 01 45 46 52 20 02 cd 46 bc
72 - 02
62 01
64 a5 0f 67
01
63 83 f9
00
76 - 06
05 00 86 c6 3f
62 00
62 00
72 - 02
63 07 01
77 - 07
255.255.255.255.255.255
07 ff ff ff ff ff ff
0b 0a 01 45 46 52 20 02 cd 46 bc
07 01 00 62 0a ff ff
72 - 02
62 01
64 a5 0f 67
f1 - 16
77 - 07
1.0.96.50.1.1
07 01 00 60 32 01 01
01
01
01
01
04 45 46 52
01
77 - 07
1.0.96.1.0.255
07 01 00 60 01 00 ff
01
01
01
01
0b 0a 01 45 46 52 20 02 cd 46 bc
01
77 - 07
1.0.1.8.0.255
07 01 00 01 08 00 ff
64 1c 00 04
72 - 02
62 01
64 a5 0f 67
62 1e
52 ff
64 64 04 53
01
77 - 07
1.0.2.8.0.255
07 01 00 02 08 00 ff
01
72 - 02
62 01
64 a5 0f 67
62 1e
52 ff
64 31 b3 0d
01
77 - 07
1.0.16.7.0.255
07 01 00 10 07 00 ff
01
01
62 1b
52 00
53 00 d4
01
77 - 07
1.0.32.7.0.255
07 01 00 20 07 00 ff
01
01
62 23
52 ff
63 08 ea
01
77 - 07
1.0.52.7.0.255
07 01 00 34 07 00 ff
01
01
62 23
52 ff
63 08 e4
01
77 - 07
1.0.72.7.0.255
07 01 00 48 07 00 ff
01
01
62 23
52 ff
63 08 e7
01
77 - 07
1.0.31.7.0.255
07 01 00 1f 07 00 ff
01
01
62 21
52 fe
62 14
01
77 - 07
1.0.51.7.0.255
07 01 00 33 07 00 ff
01
01
62 21
52 fe
62 74
01
77 - 07
1.0.71.7.0.255
07 01 00 47 07 00 ff
01
01
62 21
52 fe
62 51
01
77 - 07
1.0.81.7.1.255
07 01 00 51 07 01 ff
01
01
62 08
52 00
52 75
01
77 - 07
1.0.81.7.2.255
07 01 00 51 07 02 ff
01
01
62 08
52 00
53 00 ec
01
77 - 07
1.0.81.7.4.255
07 01 00 51 07 04 ff
01
01
62 08
52 00
53 01 19
01
77 - 07
1.0.81.7.15.255
07 01 00 51 07 0f ff
01
01
62 08
52 00
53 01 37
01
77 - 07
1.0.81.7.26.255
07 01 00 51 07 1a ff
01
01
62 08
52 00
53 01 1e
01
77 - 07
1.0.14.7.0.255
07 01 00 0e 07 00 ff
01
01
62 2c
52 ff
63 01 f3
01
77 - 07
1.0.0.2.0.0
07 01 00 00 02 00 00
01
01
01
01
06 30 33 2e 30 30
01
77 - 07
1.0.96.90.2.1
07 01 00 60 5a 02 01
01
01
01
01
03 42 bd
01
77 - 07
1.0.97.97.0.0
07 01 00 61 61 00 00
01
01
01
01
03 00 00
01
77 - 07
1.0.96.50.1.4
07 01 00 60 32 01 04
01
01
01
01
08 50 31 2e 32 2e 31 32
01
77 - 07
1.0.96.50.4.4
07 01 00 60 32 04 04
01
01
01
01
03 04 22
01
01
01
63 4b 64
00
76 - 06
05 00 86 c6 40
62 00
62 00
72 - 02
63 02 01
71 - 01
01
63 3f f0
00
Zitat von: gvzdus am 07 Februar 2021, 07:20:30
Komm' - dann schon konsequent :-)
Logging ist in der angehängten Version durchgängig angepasst - und ich hoffe, die CPU-Last etwas weiter reduziert.
Außerdem habe ich jetzt die standardisierten Werte für die Phasen-Leistung aufgenommen, die "wir ISKRA"-Nutzer immer per Hand / channels eingeben:
my %OBIS_channels = (
"21" =>"power_L1", # Positive active instantaneous power
"36" =>"power_L1", # Sum active instantaneous power
"41" =>"power_L2",
"56" =>"power_L2",
"61" =>"power_L3",
"76" =>"power_L3",
Quelle: https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm (https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm)
Moin zusammen,
ich hab zwar noch mit der vorletzten Version getestet, aber sieht schon perfekt aus, Gerät meldet sich nach einiger Zeit als "disconnected", wenn ich es wieder einstecke, startet es wieder, super !
Hab mal zwei Bilder angehängt...
Man könnte eigentlich die Channel-Liste deutlich erweitern, Frage ist nur, was gebraucht bzw. genutzt oder auch überhaupt von den gängigen Zählern geliefert wird.
Ich habe zwei Logarex-Zähler vom Typ LK13BE803039, da sind die Ausgabedaten recht bescheiden aber gut dokumentiert, hänge auch ein Bild mit an.
Teste gleich mal die letzte Version !
Bis gleich ...
ZitatMan könnte eigentlich die Channel-Liste deutlich erweitern, Frage ist nur, was gebraucht bzw. genutzt oder auch überhaupt von den gängigen Zählern geliefert wird.
Deswegen habe ich ja damals die Möglichkeit geschaffen, eigene Channels zu definieren :)
Zitat von: Icinger am 07 Februar 2021, 15:53:57
Deswegen habe ich ja damals die Möglichkeit geschaffen, eigene Channels zu definieren :)
Da hast Du auch wieder Recht, nur die gängigsten vordefinieren, seltener benötigte kann man sich ja relativ einfach dazu definieren.
Gruß Thomas
Hier noch die Registerbeschreibungen vom Logarex LK13BE...
@Georg: in der OBIS_define kannst Du noch die Zeile "my $netdev=0;" rausschmeißen.
in der englischen html-doku fehlt noch das <br> hinter der ersten Zeile von "Example:" ;)
Also, ich bin ja noch frisch und hochmotiviert :-)
Meine Zielsetzung wäre schon, dass man - solange es nicht "conflicting" ist - möglichst viele Definitionen rein nimmt. Denn so schön das mit "channel" ist: Das ist ja auch durchaus eine kleine Hürde.
Die historischen Werte wurde ja auch schon gewünscht, und das kann ich auch verstehen, weil es halt erst "extChannels" finden, und dann Rätseln ist. Mein Vorschlag wäre, hier "extChannels" um einen Modus "auto" zu erweitern. In dem wird "255" immer zum Default wie bei off, und die anderen Werte werden als postfix drangehängt (last_1d / last_7d / last_30d / last_365d / since_rset - mein Vorschlag).
Wichtig ist m.E.: Es darf bei niemandem was beim Update kaputt gehen: Wenn ich "extChannels" on habe und mein "power.255" wird mir plötzlich zum "power" gemacht, bin ich sauer. Aber dann stehe ich ja explizit auf "on".
Frage: Gibt es ausser den historischen Werten Fälle mit "extChannel != 255" ?
@hdgucken: Ich gucke mal, was ich abtippe...
Plan ist aber:
Dienstag morgen ist die jetzt aktuelle Version im SVN
Ab Mittwoch dann weiter.
Zitat von: gvzdus am 07 Februar 2021, 18:52:21
Also, ich bin ja noch frisch und hochmotiviert :-)
Meine Zielsetzung wäre schon, dass man - solange es nicht "conflicting" ist - möglichst viele Definitionen rein nimmt. Denn so schön das mit "channel" ist: Das ist ja auch durchaus eine kleine Hürde.
Die historischen Werte wurde ja auch schon gewünscht, und das kann ich auch verstehen, weil es halt erst "extChannels" finden, und dann Rätseln ist. Mein Vorschlag wäre, hier "extChannels" um einen Modus "auto" zu erweitern. In dem wird "255" immer zum Default wie bei off, und die anderen Werte werden als postfix drangehängt (last_1d / last_7d / last_30d / last_365d / since_rset - mein Vorschlag).
Wichtig ist m.E.: Es darf bei niemandem was beim Update kaputt gehen: Wenn ich "extChannels" on habe und mein "power.255" wird mir plötzlich zum "power" gemacht, bin ich sauer. Aber dann stehe ich ja explizit auf "on".
Frage: Gibt es ausser den historischen Werten Fälle mit "extChannel != 255" ?
@hdgucken: Ich gucke mal, was ich abtippe...
Plan ist aber:
Dienstag morgen ist die jetzt aktuelle Version im SVN
Ab Mittwoch dann weiter.
Das mit den historischen Werten (255 angehängt) hatte ich auch schon im Auge, gute Idee !
Weitere oft gewünschte Werte solltest Du auch mit reinnehmen, denke ich. Denn die nicht ganz so versierten Fhem User haben es dann doch einfacher :)
Keinen Stress, stell erstmal die aktuelle Version rein, können ja weiter dran arbeiten ;)
Gruß Thomas
Ich würde es erst mal als 255 oder 0 = Keine Extension programmieren. Beim Rest mit den vorgeschlagenen Namen. Mein ISKRA wirft keine historischen Zahlen aus. Aber etwas wie "last_month" oder "last_week" finde ich irreführend: Der letzte Monat ist der Januar aus Sicht von heute. Oder der Februar. Aber nicht die letzten 30 Tage.
Könnten die Inhaber von Zählern mit historischen Werten mal gucken, ob das wirklich die gleitenden letzten 7 Tage / 30 Tage etc. sind? Sollte ja einfach sein: Wenn es sich laufend ändert, ist es gleitend.
Zitat von: gvzdus am 07 Februar 2021, 20:44:58
Ich würde es erst mal als 255 oder 0 = Keine Extension programmieren. Beim Rest mit den vorgeschlagenen Namen. Mein ISKRA wirft keine historischen Zahlen aus. Aber etwas wie "last_month" oder "last_week" finde ich irreführend: Der letzte Monat ist der Januar aus Sicht von heute. Oder der Februar. Aber nicht die letzten 30 Tage.
Könnten die Inhaber von Zählern mit historischen Werten mal gucken, ob das wirklich die gleitenden letzten 7 Tage / 30 Tage etc. sind? Sollte ja einfach sein: Wenn es sich laufend ändert, ist es gleitend.
Beim Logarex kann ich die historischen Werte zu einem beliebigen Zeitpunkt zurücksetzen, also gleitend.
So, wie angekündigt: Ab morgen ist die neue 47_OBIS per FHEM-Update erhältlich. Mal gucken...
Am Rande:
Vielleicht ist es ja weit und breit bekannt, aber ein Charme am Einsatz von ser2net:
Mit dem Zusatz:
... max-connections=3
kann man erreichen, mit mehreren Software-Instanzen gleichzeitig die Werte zu lesen.
Ist für mich sehr hilfreich, um auf meinem Test-Raspi nach Lust und Laune mit echten Daten spielen zu können, ohne permanent einen vollen Restart meines "Arbeits-FHEMs" durchführen zu müssen, der auf Live-Daten vom Stromzähler für die Verbrauchersteuerung angewiesen ist.
Hi,
also der letzte Modulstand läuft bei mir nun 1 Tag.
Die Verbindungsproblematik scheint, unabhängig von stateFormat, sauber abgefangen zu sein.
Log-Auszug:
2021.02.08 12:19:39.008 1: 192.168.41.150:20001 disconnected, waiting to reappear (StromZ1)
2021.02.08 12:19:39.041 1: 192.168.41.150:20002 disconnected, waiting to reappear (StromZ2)
2021.02.08 12:19:39.050 1: 192.168.41.150:20010 disconnected, waiting to reappear (Mythz)
2021.02.08 12:20:39.398 1: 192.168.41.150:20010 reappeared (Mythz)
2021.02.08 12:21:37.534 3: OBIS (StromZ2) - No data received for 118 seconds, resetting connection
2021.02.08 12:21:37.555 3: OBIS (StromZ1) - No data received for 121 seconds, resetting connection
2021.02.08 12:22:37.545 3: OBIS (StromZ2) - No data received for 178 seconds, resetting connection
2021.02.08 12:22:37.550 3: OBIS (StromZ2) - Init done
2021.02.08 12:22:37.550 1: 192.168.41.150:20002 reappeared (StromZ2)
2021.02.08 12:22:37.570 3: OBIS (StromZ1) - No data received for 181 seconds, resetting connection
2021.02.08 12:22:37.573 3: OBIS (StromZ1) - Init done
2021.02.08 12:22:37.573 1: 192.168.41.150:20001 reappeared (StromZ1)
Die Channels kommen bei meinem ISKRA nun auch Standardmäßig an, brauche also das Channels-Attribut nicht mehr :)
Was mir aufgefallen ist, dass sowas hin und wieder kommt:
Habt Ihr das auch?
2021.02.08 05:32:13.811 3: OBIS - Empty datagram: .010163B68900760502604F456200620072630201710163EB2A001B1B1B1B1A007707
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[1] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[2] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[3] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[4] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.812 1: PERL WARNING: Use of uninitialized value $list[5] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.815 3: OBIS (StromZ1) - Unknown Message: 0-0:0.0.0*255()
Ansonsten wäre es vlt. noch schön zu jedem OBIS-spezifischen Attribut etwas in der Commandref zu finden. Beispielsweise habe ich keine Erklärung zu "extChannels" gefunden. Wahrscheinlich gibts noch ein paar Attribute, die vom OBIS-Modul kommen und dort nicht auftauchen?
Ansonsten bleibt mir nur nochmal ein Lob an alle Beteiligten loszuwerden!
VG...
Zitat von: friesenjung am 08 Februar 2021, 14:02:14
Was mir aufgefallen ist, dass sowas hin und wieder kommt:
Habt Ihr das auch?
2021.02.08 05:32:13.811 3: OBIS - Empty datagram: .010163B68900760502604F456200620072630201710163EB2A001B1B1B1B1A007707
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[1] in hex at ./FHEM/47_OBIS.pm line 405.
2021.02.08 05:32:13.811 1: PERL WARNING: Use of uninitialized value $list[2] in hex at ./FHEM/47_OBIS.pm line 405.
...
Das scheint mir ein vergessenes "next" im Code zu sein. Bei mir treten keine "Empty datagrams" auf. Könntest Du bitte die Zeile suchen und ändern?
if (!@list) {Log3 $hash,3,"OBIS - Empty datagram: .$msg";next};
Das "next" sollte zwar nur Gutes bewirken, aber Schleifen zu verkürzen hat immer das Restrisiko, sie endlos zu machen.
Erfolgsmeldung wäre ein "Empty datagram" im Logfile ohne die Warnings danach (und ein noch laufendes FHEM :-) ) - dann nehme ich es auf.
Zitat von: friesenjung am 08 Februar 2021, 14:02:14
Ansonsten wäre es vlt. noch schön zu jedem OBIS-spezifischen Attribut etwas in der Commandref zu finden. Beispielsweise habe ich keine Erklärung zu "extChannels" gefunden. Wahrscheinlich gibts noch ein paar Attribute, die vom OBIS-Modul kommen und dort nicht auftauchen?
Ich kann mal forschen. extChannels zu dokumentieren bietet sich ja an, wenn ich das "auto" wie vorgeschlagen implementiere.
Zitat von: gvzdus am 08 Februar 2021, 14:32:42
...
Erfolgsmeldung wäre ein "Empty datagram" im Logfile ohne die Warnings danach (und ein noch laufendes FHEM :-) ) - dann nehme ich es auf.
...
Habs grad eingespielt und schon ein "Empty datagram" im Logfile
ohne die Warnings danach und Fhem läuft noch :) Ich berichte dann morgen mehr...
Klasse, Danke!
Anbei nun eine Version, die wie vorgeschlagen:
- extChannels dokumentiert
- per Default im Modus "auto" ist und "sprechende" Postfixe anhängt
Wäre nett, wenn es jemand mit einem der Zähler testet - bei Erfolgsmeldung wäre es dann in der "Mittwoch"-Offiziell-Version.
Anleitung:
- Kommen ohne "extChannel"-Attribut (oder mit explizitem "auto") automatisch die historischen Werte? Wirken die passend?
- Allgemein: Tauchen die Postfixe irgendwo auf, wo sie Unsinn sind?
- Verhalten bei "on" sollte unverändert sein.
Der Patch mit "next" ist auch drin.
Nur noch ein Hinweis für nicht so FHEM-Versierte: Den "Schrott", der beim Testing entsteht (z.B. Readings mit ".255" am Ende) kann man mit "deletereading <devicename> <muster>" wegräumen, also z.B.
deletereading myobis .*255
Zitat von: gvzdus am 08 Februar 2021, 21:27:24
Klasse, Danke!
Da schließe ich mich an :)
ZitatAnbei nun eine Version, die wie vorgeschlagen:
- extChannels dokumentiert
- per Default im Modus "auto" ist und "sprechende" Postfixe anhängt
Wäre nett, wenn es jemand mit einem der Zähler testet - bei Erfolgsmeldung wäre es dann in der "Mittwoch"-Offiziell-Version.
Anleitung:
- Kommen ohne "extChannel"-Attribut (oder mit explizitem "auto") automatisch die historischen Werte? Wirken die passend?
- Allgemein: Tauchen die Postfixe irgendwo auf, wo sie Unsinn sind?
- Verhalten bei "on" sollte unverändert sein.
Der Patch mit "next" ist auch drin.
Habe es soeben getestet, funktioniert, wie beschrieben: "extChannels=on" es bleibt alles, wie es war.
Bei "extCannels=Auto" kommen die historischen Werte in lesbarer Form und wie gewohnt "total_consumption" und "total_feed" ohne die Endung ".255".
Perfekt gemacht !
Gruß Thomas
Danke.
Dann haue ich jetzt doch noch in das Release für morgen rein, ist also morgen offiziell!
Ergebnis kann ich auch bei meinem ISKRA MT175 bestätigen. Echt cool.
Gruß Uwe
Ist das korrekt, wenn "interval" z.B. auf 180 gesetzt ist, jede Minute ein Reset und eine neue Initialisierung stattfindet ?
z.B.
2021.02.08 23:58:30 1: /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D309V5ZE-if00-port0 reappeared (ISK)
2021.02.09 00:00:30 3: OBIS (ISK) - No data received for 111 seconds, resetting connection
2021.02.09 00:00:30 3: OBIS (ISK) - Init done
2021.02.09 00:00:30 1: /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D309V5ZE-if00-port0 reappeared (ISK)
2021.02.09 00:01:30 3: OBIS (ISK) - No data received for 171 seconds, resetting connection
2021.02.09 00:01:30 3: OBIS (ISK) - Init done
2021.02.09 00:01:30 1: /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D309V5ZE-if00-port0 reappeared (ISK)
2021.02.09 00:03:30 3: OBIS (ISK) - No data received for 111 seconds, resetting connection
2021.02.09 00:03:30 3: OBIS (ISK) - Init done
2021.02.09 00:03:30 1: /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D309V5ZE-if00-port0 reappeared (ISK)
2021.02.09 00:04:30 3: OBIS (ISK) - No data received for 171 seconds, resetting connection
2021.02.09 00:04:30 3: OBIS (ISK) - Init done
(Verbose 3)
Gruß Uwe
Auf die Schnelle sollte "resetAfterNoDataTime" auf 240 (also höher als Poll-Intervall) setzen helfen, aber der Reset sollte auch nicht schaden.
Lass' uns mal die Tage über den Sinn von pollTime sprechen! Mir erscheint das möglicherweise ungenau, und den Sinn möchte ich auch verstehen - jenseits von CPU. Ich lese auch punktgenau (stündlich, täglich) Zählerstände ab und bilde Tageswerte - mit at-Jobs. Aber erstmal gucken, ob ab morgen hier Tomatenwürfe im Forum auftauchen...
Ich habe jetzt auch mal die letzte Version versucht - leider habe ich dann folgende Probleme:
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (892)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
2021.02.09 08:36:23 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 898.
2021.02.09 08:36:23 1: stacktrace:
2021.02.09 08:36:23 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (898)
2021.02.09 08:36:23 1: main::OBIS_decodeTL called by ./FHEM/47_OBIS.pm (403)
2021.02.09 08:36:23 1: main::OBIS_trySMLdecode called by ./FHEM/47_OBIS.pm (515)
2021.02.09 08:36:23 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (321)
2021.02.09 08:36:23 1: main::OBIS_Read called by fhem.pl (3818)
2021.02.09 08:36:23 1: main::CallFn called by fhem.pl (822)
Wahrscheinlich das selbe Problem/Fix wie hier schon mal beschrieben.
https://forum.fhem.de/index.php/topic,51948.msg1085400.html#msg1085400
Zitat von: friesenjung am 08 Februar 2021, 21:14:57
Habs grad eingespielt und schon ein "Empty datagram" im Logfile ohne die Warnings danach und Fhem läuft noch :) Ich berichte dann morgen mehr...
Moin,
ich habe mal alle OBIS-relevanten Einträge zusammengefasst, seitdem ich das Modul um ca. 21:30 eingespielt hatte:
2021.02.08 22:11:07.317 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 882.
2021.02.08 22:11:07.317 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/47_OBIS.pm line 898.
2021.02.08 22:11:07.317 1: PERL WARNING: Use of uninitialized value $dataT in numeric eq (==) at ./FHEM/47_OBIS.pm line 421.
2021.02.08 22:11:07.317 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 428.
2021.02.08 22:11:07.317 1: PERL WARNING: Use of uninitialized value $data in substitution (s///) at ./FHEM/47_OBIS.pm line 429.
2021.02.08 22:11:07.317 1: PERL WARNING: Use of uninitialized value $data in string at ./FHEM/47_OBIS.pm line 430.
2021.02.08 22:11:07.318 1: PERL WARNING: Use of uninitialized value $msg in pattern match (m//) at ./FHEM/47_OBIS.pm line 409.
2021.02.08 22:11:07.318 3: OBIS (StromZ1) - Unknown Message: 215-112:120.24.28*255()
...
...
...
2021.02.09 00:00:59.903 3: OBIS (StromZ1) - Unknown Message: 0-27:27.27.27*255()
2021.02.09 03:16:04.136 1: PERL WARNING: Use of uninitialized value $tmp2 in concatenation (.) or string at ./FHEM/47_OBIS.pm line 892.
...
2021.02.09 04:06:59.602 3: OBIS (StromZ2) - Unknown Message: 0-27:27.27.27*255()
...
2021.02.09 06:08:23.599 3: OBIS - Empty datagram: .01016388A800760502638DAF62006200726302017101631B75001B1B1B1B1A007707
...
VG
Mir sind zwei Dinge aufgefallen:
- Ja, die Meldungen wie Deine (bzw. ähnliche) habe ich auch sporadisch. Sie sind ziemlich harmlos, aber eben irgendetwas, wo der Parser nicht glücklich ist. Ich werde mal "Langzeit-Mitschneiden", um die zugehörigen Rohdaten zu haben
- Etwas anders: ser2net läuft bei mir nicht besonders stabil mit 2 lesenden Clients. Ich hatte gestern und heute 1-2 Aufhänger. Mit strace stellte ich fest, dass ser2net zwar die TCP-Verbindungen hält, aber nichts mehr sendet. Was ich vermute: Das es unglücklich ist, wenn einer der beiden Clients sich plötzlich verabschiedet und keine Daten mehr annimmt. Denn meinem Test-Raspi wurde ein paar Mal der Strom genommen, sodass es zum unsauberen, einseitigen Ende der Verbindung kam.
Ich habe den Fehler (PERL WARNING, substr, u.s.w.) auch im Kasten. Außerdem die älteren Beiträge zum Thema gefunden. Das Ganze ist etwas Kniffeliger und geht ans Eingemachte: Die Message wird in Sequenzen, die mit 7707 beginnen, zergliedert. Kommt nun zufällig 7707 irgendwo "zufällig" vor, wird zu klein gehackt. Dabei ist 7707 obendrein "4bit-weise" zu verstehen, die Sequenz 37 70 73 würde auch matchen.
Etwas Geniales fällt mir nicht ein (ich finde den Code ohnehin schon ziemlich genial in Sachen Regexp-Anwendung). Lösung wäre ein sequentieller Parser, was aber auch wieder Gelegenheit zu vielen Fehlern bei der Implementierung bietet.
Deswegen nehme ich das erst einmal als "Known Bug" und "Todo".
P.S.: Ich habe übrigens die Typos in der Doku gefixt, die abc2006 im Herbst beschrieben hat - rund um die Seite, die papa verlinkt hatte. Ist im SVN, aber vielleicht nicht ganz der ultimative Grund für ein FHEM-Update.
Zitat von: gvzdus am 10 Februar 2021, 14:08:51
Ich habe den Fehler (PERL WARNING, substr, u.s.w.) auch im Kasten. Außerdem die älteren Beiträge zum Thema gefunden. Das Ganze ist etwas Kniffeliger und geht ans Eingemachte: Die Message wird in Sequenzen, die mit 7707 beginnen, zergliedert. Kommt nun zufällig 7707 irgendwo "zufällig" vor, wird zu klein gehackt. Dabei ist 7707 obendrein "4bit-weise" zu verstehen, die Sequenz 37 70 73 würde auch matchen.
Etwas Geniales fällt mir nicht ein (ich finde den Code ohnehin schon ziemlich genial in Sachen Regexp-Anwendung). Lösung wäre ein sequentieller Parser, was aber auch wieder Gelegenheit zu vielen Fehlern bei der Implementierung bietet.
Deshalb hatte ich mit dem extra Parser angefangen.
Ja, da steht auch noch die Antwort aus...
Ich bin da etwas im Konflikt:
- Das Ganze auf Binär umbauen? Z.B. gibt es die initiale Prüfung: Habe ich eine komplette Message erhalten? Das wird typischerweise mehrere Read-Optionen umfassen. Da wäre es schneller, binär zu bleiben, statt auf Hex zu konvertieren. Aber der Codeabschnitt funktioniert ja 100%ig
- Dann die "innere Schleife", wo es zur Split-Problematik kommt
Worüber ich nachdenke: Eine Binär-Logfunktion im Modul, um Testdaten zu haben: Etwas wie ein Attribut: "tracefile", dass allen eingehenden Verkehr in eine Datei mitschneidet, die man ggf. für Problemfälle zur Analyse verwenden kann und weniger "verbose" als das Logging im allgemeinen Logfile ist. Das Format müsste m.E. aber zusätzlich einen Zeitstempel und die einzelnen Reads wiedergeben, also kein reiner "cat /dev/ttyUSB0 > file.bin"-Mitschnitt sein. Ich hatte schon einmal geguckt, ob bei Volkszähler da ein Format "erfunden" wurde oder gar Beispiele für Parser-Tests vorhanden sind, habe aber nichts gefunden. Anregungen wären willkommen.
Wie schon geschrieben: Das ist Komplexer als mal eben ein Türmchen ans funktionierende Modul zu bauen.
seltsamerweise gibts bei mir (ISKRA Zähler MT175 ) anscheinend keine Fehler, außer innerhalb 24Std 2 crc errors. womit ich leben kann.
Habe nun noch eine Frage zum ,,DirektionsByte < >".
Das Statusbyte ist im diesem Zähler mitgegeben mit
1-0:1.8.0*255(>2282769.2*Wh) Bezug
1-0:1.8.0*255(<2301131.8*Wh) Einspeisung
beschrieben, da anscheinend kein extra Statusbyte anliegt.. Könnte man noch consum & feedin in implementieren ?
... ansonsten läuft alles super ohne Fehler. Besten Dank !
Zitat von: Violinux am 11 Februar 2021, 19:23:56
Das Statusbyte ist im diesem Zähler mitgegeben mit
1-0:1.8.0*255(>2282769.2*Wh) Bezug
1-0:1.8.0*255(<2301131.8*Wh) Einspeisung
beschrieben, da anscheinend kein extra Statusbyte anliegt..
Da muss ich mich noch einarbeiten. Könntest Du mal kurz auf "verbose 5" schalten und das Logfile von ein oder zwei "Zählerstandsübermittlungen" posten?
2 CRC-Fehler finde ich ziemlich normal, obwohl mein Lesekopf 0 produziert.
anbei 2 Log´s , der erste mit ca 2KW Belastung, der zweite ohne, da ja PV Energie anliegt, das man besser in und out erkennt.
So mal als Zwischenstand: Ich habe jetzt eine inoffizielle Debug-Funktion eingebaut (nein, checke ich nicht ein):
Mit
define <name> OBIS <dateiname mit pfad>
wird ein OBIS device angelegt, das seinen Input aus einer Text-Datei einliest. Und zwar nicht irgendeinem Binär-Format (da hatte ich ja mal drüber nachgedacht), sondern einfach dem FHEM-Logfile-Format. Konkret werden die
<datum> OBIS (name) - Full message-> ....
Zeilen gelesen und dann den Parse-Funktionen übergeben. Somit kann ich (oder jemand, der sich versuchen möchte) einfach die in verbose 5 erzeugten Logmeldungen in eine Datei packen, ggf. zur Verkürzung auf die "Full Message"-Zeilen filtern, und das Ganze nachspielen. Am Ende wird in "state" des neuen und nutzlosen Devices eine Speed-Statistik ausgegeben. Die ist nicht zutreffend, weil ja der ganze Teil "mehrere Reads zusammensetzen, Checksumme prüfen" nicht abgedeckt ist. Sie eignet sich aber zum Vergleich von Optimierungen im inneren Parser. Mit meinem Test-Raspi, einem 3A+, und den ISKRA-Zähler-Daten (hängt ja auch von der Länge der Nachrichten ab) komme ich übrigens auf 181 Zeilen pro Sekunde. Das wären nur 0,5% der CPU bei einer Nachricht / Sekunde (Achtung, siehe Einschränkung äußerer Parser).
Ziel ist natürlich, Logmeldungen wie die aus dem letzten Beitrag bequem nachspielen und verarbeiten zu können. Oder die auch bei mir beobachteten Fehlermeldungen. Die brauche ich jetzt nur noch in eine Datei zu kopieren und einmal das "define x OBIS /filename" aufzurufen.
Modul anbei für Leute, die spielen wollen und das idealerweise auch nicht auf einem produktiven System tun müssen.
Sag mal, Violinux:
ZitatKönnte man noch consum & feedin in implementieren ?
Was meinst Du damit? Konkret sehe ich halt bei Dir, wenn ich die Logzeilen von Dir ins System füttere, die üblichen Angaben:
- total_consumption
- total_feed
Was ist für Dich "consum" & "feedin"?
hallo gvzdus,
Zitat von: gvzdus am 13 Februar 2021, 18:59:26
Sag mal, Violinux:
Was ist für Dich "consum" & "feedin"?
Sorry, hatte mich falsch ausgedrückt.
Es wird ja immer 1-0:1.8.0*255(
>xxx oder 1-0:1.8.0*255(
<xxx
geloggt, d.h. die Stromrichtung wird mit angegeben. Da wäre es doch prima auch
ein extra Reading zu haben welches standardmäßig "in" bzw. "out" beinhaltet.
Du meinst also die "Grundrichtung": Rein oder raus? Aber das ist ja eigentlich direkt das Vorzeichen von "power". Ehrlich gesagt: Das ist mir zu trivial als Reading, zumal ich es entweder für andere Zähler dann simulieren müsste, oder es spezifisch für den Zähler ist.
Ich wünsche mir schon, dass mehr Folgeskripte ausgetauscht werden können, und dafür ist es m.E. am besten, wenn "power" und "total_consumption" die "Einheitswerte" sind, plus "total_feed" für die Solaranlagenleute wie mich.
Für eine sinnvolle Steuerung muss man eh noch viel Logik aufsetzen. Bei mir geht "power" in ein Notify, was zunächst einen Satz dummys mit 0 oder 1 befüllt: "plus50", "plus100", "plus500" u.s.w. Darauf hängen wiederum Watchdogs wie "strom100plusisstable120" für 120 Sekunden stabil über 100 Watt Überschuss. Und diese Watchdogs schalten dann Verbraucher an, und bei "strom50minusisstable100" z.B. nach 100 Sekunden mit mehr als 50 Watt Netzbezug wieder aus.
Was willst Du mit der nackten "Direction" anfangen?
gut, das wir darüber gesprochen haben. Du hast mich wieder auf den richtigen Weg gebracht, das mit den dummys und watchdog ist genial.
Besten Dank.
"Genial" weiß ich nicht. Ich beobachte viel, wie sich so das Regeln verhält. Generell schalte ich z.Zt. Verbraucher (TK-Truhe, HK-Pumpe und jetzt endlich auch das E-Auto) ein, wenn 1-2 Minuten der Überschuss vollumfänglich anliegt, und schalte sie nach 30-60 Sekunden deutlicher Unterdeckung aus. Mit dem Ausschalten versuche ich, dass z.B. der Kaffeevollautomat kein Abschalten auslöst: Dessen Aufheizperioden liegen < 60 Sekunden. Dagegen ist die Waschmaschine mit ihrem Grundmuster "Trommel drehen, Pause" das Gegenbeispiel: Alles < 60 Sekunden, aber soll jetzt abgeschaltet werden oder nicht? Außerdem ist das grundsätzlich nach der Maxime "Alles oder nichts": Voller Überschuss, um einzuschalten. Wenn ich aber weiß, dass ich jetzt noch 1 kW billigen Solarüberschuss mitnehmen kann, wenn ich 1 kW dazukaufe, um auf 2 kW zu kommen, ist es schlauer, das ab Nachmittag eher früher zu tun: Ein Später wird es nicht geben.
Aber da wird es echt kompliziert und fallspezifisch. Heute habe ich den ID.3 auf 85% geladen - am Ende unter Zukauf von 1 kW bei 1 kW Solarberschuss - weil es morgen mau werden wird. Ich weiß aber selber nicht, ob es nicht klüger wäre, den Wagen die nächsten 1-3 Tage halt auf 20% runterzufahren und auf die nächsten sonnigen Tage zu warten, wo ich mit 100% Solarüberschuss laden kann.
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.
E-Auto macht aber echt Spaß! Ich werte schon lange Autarkie und Nutzungsgrad aus: Ich würde sagen, man sieht, seit wann der ID.3 da ist (Standort: Grevenbroich):
Econs = Stromverbrauch (kWh) des Haushaltes
Enet = davon aus dem Netz bezogen
Esol = davon Eigenverbrauch Solar
Esolt = Gesamterzeugung Solarpanel
Autark = Autarkiequote
Usage = Eigennutzungsanteil des Solarstroms
Date Econs Enet Esol Esolt Autark Usage
2021-02-01 11.194 8.178 3.016 4.325 26.9% 69.7%
2021-02-02 9.880 7.322 2.558 3.514 25.9% 72.8%
2021-02-03 10.390 8.149 2.240 3.833 21.6% 58.5%
2021-02-04 10.601 5.324 5.277 16.236 49.8% 32.5%
2021-02-05 12.908 8.230 4.677 6.900 36.2% 67.8%
2021-02-06 12.165 9.912 2.253 2.427 18.5% 92.8%
2021-02-07 7.756 7.558 0.198 0.199 2.6% 99.6%
2021-02-08 15.028 14.691 0.337 0.339 2.2% 99.6%
2021-02-09 9.509 6.530 2.979 8.668 31.3% 34.4%
2021-02-10 11.774 7.606 4.168 16.077 35.4% 25.9%
2021-02-11 12.446 7.349 5.097 18.316 41.0% 27.8%
2021-02-12 10.268 6.624 3.644 20.584 35.5% 17.7%
2021-02-13 16.200 5.518 10.682 21.125 65.9% 50.6%
2021-02-14 18.503 4.421 14.082 20.836 76.1% 67.6%
Zitat von: gvzdus am 14 Februar 2021, 19:47:02
"Genial" weiß ich nicht. Ich beobachte viel, wie sich so das Regeln verhält. Generell schalte ich z.Zt. Verbraucher (TK-Truhe, HK-Pumpe und jetzt endlich auch das E-Auto) ein, wenn 1-2 Minuten der Überschuss vollumfänglich anliegt, und schalte sie nach 30-60 Sekunden deutlicher Unterdeckung aus. Mit dem Ausschalten versuche ich, dass z.B. der Kaffeevollautomat kein Abschalten auslöst: Dessen Aufheizperioden liegen < 60 Sekunden. Dagegen ist die Waschmaschine mit ihrem Grundmuster "Trommel drehen, Pause" das Gegenbeispiel: Alles < 60 Sekunden, aber soll jetzt abgeschaltet werden oder nicht? Außerdem ist das grundsätzlich nach der Maxime "Alles oder nichts": Voller Überschuss, um einzuschalten. Wenn ich aber weiß, dass ich jetzt noch 1 kW billigen Solarüberschuss mitnehmen kann, wenn ich 1 kW dazukaufe, um auf 2 kW zu kommen, ist es schlauer, das ab Nachmittag eher früher zu tun: Ein Später wird es nicht geben.
Aber da wird es echt kompliziert und fallspezifisch. Heute habe ich den ID.3 auf 85% geladen - am Ende unter Zukauf von 1 kW bei 1 kW Solarberschuss - weil es morgen mau werden wird. Ich weiß aber selber nicht, ob es nicht klüger wäre, den Wagen die nächsten 1-3 Tage halt auf 20% runterzufahren und auf die nächsten sonnigen Tage zu warten, wo ich mit 100% Solarüberschuss laden kann.
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.
E-Auto macht aber echt Spaß! Ich werte schon lange Autarkie und Nutzungsgrad aus: Ich würde sagen, man sieht, seit wann der ID.3 da ist (Standort: Grevenbroich):
Econs = Stromverbrauch (kWh) des Haushaltes
Enet = davon aus dem Netz bezogen
Esol = davon Eigenverbrauch Solar
Esolt = Gesamterzeugung Solarpanel
Autark = Autarkiequote
Usage = Eigennutzungsanteil des Solarstroms
Date Econs Enet Esol Esolt Autark Usage
2021-02-01 11.194 8.178 3.016 4.325 26.9% 69.7%
2021-02-02 9.880 7.322 2.558 3.514 25.9% 72.8%
2021-02-03 10.390 8.149 2.240 3.833 21.6% 58.5%
2021-02-04 10.601 5.324 5.277 16.236 49.8% 32.5%
2021-02-05 12.908 8.230 4.677 6.900 36.2% 67.8%
2021-02-06 12.165 9.912 2.253 2.427 18.5% 92.8%
2021-02-07 7.756 7.558 0.198 0.199 2.6% 99.6%
2021-02-08 15.028 14.691 0.337 0.339 2.2% 99.6%
2021-02-09 9.509 6.530 2.979 8.668 31.3% 34.4%
2021-02-10 11.774 7.606 4.168 16.077 35.4% 25.9%
2021-02-11 12.446 7.349 5.097 18.316 41.0% 27.8%
2021-02-12 10.268 6.624 3.644 20.584 35.5% 17.7%
2021-02-13 16.200 5.518 10.682 21.125 65.9% 50.6%
2021-02-14 18.503 4.421 14.082 20.836 76.1% 67.6%
Das mit dem E-Auto regelt mein E3DC S10E ;) Da kann man einige Dinge zu einstellen: Sonnenmodus (Laden aus PV-Überschuss) oder normales laden, wenn kein PV-Überschuss vorhanden.
Man kann 1-phasiges oder 3-phasiges Laden auswählen und die max. Stromstärke zum laden einstellen. Man kann vorgeben, ob der Hausakku oder der Fahrzeugakku priorität beim Laden mit PV haben soll
und ob der Hausakku vom Fahrzeug entladen werden darf oder nicht. Dann gibt es noch die Möglichkeit, festzulegen, wie lange das Fahrzeug mit dem Mindeststrom (6A) weiterladen soll, wenn kein PV-Überschuss mehr vorhanden ist, ehe es abschaltet. Zeiten, in denen das Fahrzeug geladen werden darf, lassen sich ebenfalls einstellen. Alles in allem eine super Sache, das S10E von E3DC :)
Die Wallbox stammt übrigends von Wallbe, auf E3DC gelabelt. Beide lassen sich über ModBus TCP auslesen, also problemlos in FHEM zu integrieren.
Im Moment steuere ich unsere Wärmepumpe so, dass die Warmwasser-Aufbereitung von 50 auf 55 Grad Celsius angehoben wird, wenn die PV-Anlage in die >70% Abregelung geht.
Ich fahre seit März 2019 elektrisch und kann Dir nur zustimmen, es macht richtig Spaß :)
Zitat von: gvzdus am 14 Februar 2021, 19:47:02
...
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.
...
oh ja, daran wäre ich auch interessiert. Ich suche schon länger nach einer Möglichkeit eine eigene Prognose berechnen zu können...
VG
Kennst Du das hier ?
https://forum.fhem.de/index.php/topic,117864.msg1124767.html#msg1124767
Zitat von: papa am 16 Februar 2021, 10:52:21
Kennst Du das hier ?
https://forum.fhem.de/index.php/topic,117864.msg1124767.html#msg1124767
hi,
danke für den Tipp, kannte ich noch nicht!
Da scheint sich ja einiges zu tun. Lesestoff für heut abend ;)
VG
Hi,
ich habe 2 digitale Strohmzähler per ESP8266 und OBIS angeschlossen.
Das tut soweit wunderbar.
Leider ist mir jetzt in den letzten Wochen 2 mal FHEM abgestürzt.
Am Ende des Fhem logs stand:
2021.03.07 20:25:53 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 440.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 440.
Ist das der Grund des Absturzes?
Gruß,
Stefan
Ich vermute: Ja.
Zeile 440 passt dazu, dass Du die letzte Version verwendest. Mir fehlt die Phantasie, was den Fehler auslöst.
Ich habe mal die ganze Parse-Funktion in einen eval-Block gesteckt, der einen Absturz verhindern *sollte*, und stattdessen hoffentlich die Input-Daten loggt. Deswegen packe ich sie auch nicht ins SVN, sondern erst mal nur hier in den Thread.
Anleitung:
Auf den Server bringen und restarten.
Nach 4 Wochen oder so bitte mal das Logfile nach "OBIS ($name) - Crashed with $@ on parsing buffer $buffer" (also natürlich ohne die Variablen) durchsuchen - vielleicht findet sich was.
Hoffe, es hilft!
Hallo zusammen,
ich habe ein Problem mit meinem eHZ, welcher an meinem Volkszähler einwandfrei läuft, in FHEM mit 47_OBIS.pm aber nicht alle Daten anzeigt. Im Volkszähler sehe ich die Daten
wogegen in FHEM 1.8.0 nicht angezeigt wird.
Parsen der Daten mittels libSML aus dem Volkszähler Projekt:
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#35#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#6#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#-28#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#-28#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#16#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#39#WFHEM Log der gleichen Daten:
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: /
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: 1-0:2.8.0*255(2780607.2*Wh)
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg 1-0:2.8.0*255(2780607.2*Wh) is of type Counter
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: 1-0:16.7.0*255(-41*W)
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg 1-0:16.7.0*255(-41*W) is of type Channels
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: !
2021.03.09 17:21:04 5: OBIS (EHZ) - SML-Parse 1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF726
20165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B52005224010101637C
2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Full message-> 1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFF
FF72620165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B5200522401010
1637C2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Telegram=1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF7262
0165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B52005224010101637C2
C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Telegram=0177070100100700FF0101621B52005224010101637C2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 4: OBIS (EHZ) - MSG IS:
/
1-0:2.8.0*255(2780607.2*Wh)
1-0:16.7.0*255(36*W)
!
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: /
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: 1-0:2.8.0*255(2780607.2*Wh)
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg 1-0:2.8.0*255(2780607.2*Wh) is of type Counter
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: 1-0:16.7.0*255(36*W)
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg 1-0:16.7.0*255(36*W) is of type Channels
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: !
2021.03.09 17:21:05 5: OBIS (EHZ) - SML-Parse 1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF726
20165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B520052030101016335
9A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Full message-> 1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFF
FF72620165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B5200520301010
163359A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Telegram=1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF7262
0165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B5200520301010163359
A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Telegram=0177070100100700FF0101621B5200520301010163359A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 4: OBIS (EHZ) - MSG IS:
/
1-0:2.8.0*255(2780607.2*Wh)
1-0:16.7.0*255(3*W)
!
Kann mir jemand hierbei einen Hinweis geben?
Gruß
Thomas
Hi Thomas,
wie es aussieht, verhaspelt sich der Parser des Moduls und überspringt Teile der Nachricht. Da muss ich tiefer rein, und vermutlich Teile des Parsers neu schreiben. Setz' Dir bitte eine Benachrichtigung auf den Thread - ich sehe zu, bald zu liefern (= eher in Tagen).
Du hast allen Input geliefert, der nötig ist, um dran zu arbeiten.
Cheers, Georg
Hi Georg,
danke erstmal für dein Feedback. Was hältst Du von der Idee die libSML zu benutzen anstelle des Parsers in 47_OBIS.pm?
Gruß
Thomas
libsml ist ein Haufen Klassen in C++. Natürlich kann man grundsätzlich in Perl C-Libraries einbinden, aber das ist eben hässlich.
Nach dem Review von meinem und Deinen Bytesequenzen, und der Überprüfung, dass libsml strukturiert vorgeht, während der gegenwärtiger Parser versucht, "das Fleisch im Bytestrom herauszufischen", denke ich, dass der strukturierte Ansatz funktionieren kann. Sollte auch nicht so schwer sein.
Meine Idee wäre eher aus der libSML ein stand alone executable zu bauen (ist bereits als Beispiel "sml_server" vorhanden) und dieses von dem perl Modul als Parser aufrufen zu lassen. Ist zwar auch nicht optimal, da dieser Parser für jede Architektur kompiliert werden müsste, scheint dafür aber recht gut getestet und performant zu sein.
Ein Aufruf von: "cat /dev/ttyUSB0 | ./sml_server -" liefert dann folgendes:
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1159302.2#Wh
1-0:2.8.0*255#2780685.1#Wh
1-0:16.7.0*255#420#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1159302.3#Wh
1-0:2.8.0*255#2780685.1#Wh
1-0:16.7.0*255#419#W
das wiederum sollte sich problemlos auswerten lassen
Hi gvzdus,
vielen Dank für die Version mit der ich es Monitoren kann.
Ich werde das tun und ab und zu nach den Fehlermeldungen suchen.
Mit welchem Loglevel werden die Meldungen rausgeschrieben?
Gruß und vielen Dank,
Stefan
@Stefan: Die Meldungen würden im höchsten Loglevel geschrieben - immerhin wurde ja beinahe ein Crash abgewendet :-)
Für alle
Letztlich habe ich mich jetzt mal hingesetzt und konzentriert den (vermeintlich sauberen) Parser implementiert. Außerdem arbeitet der Parser jetzt binär und streamend, also weniger Regex-Overhead und keine Nibble-Vertauschung. Wer in den Code gucken möchte:
Die neue Routine OBIS_Parse_List ist das Herzstück des Parsers und ersetzt die while (/7707/)-Schleife durch einen "richtigen" Parser.
Der Parser läuft bei mir seit ein paar Stunden fehlerfrei, und den Code von Thomas "frisst" er auch. Daher suche ich Freiwillige, die auch ohne Not zur angehängten Version Feedback geben. Besonders interessant wäre, ob - wie vermutet - auch Performance-Vorteile erkennbar sind.
P.S.: Stefan, die Wahrscheinlichkeit ist hoch, dass es am alten Parser lag. Deswegen vielleicht auch lieber diese Version hier verwenden, denn wenn keine Katastrophenmeldungen reinkommen, die ich nicht schnell lösen kann, wird diese Version bald die offizielle sein.
Noch ein Nachtrag: Wer mindestens auf "verbose 3" loggt, könnt mir den Gefallen tun, mal im historischen Logfile nach "OBIS_Ext called" im Logfile zu suchen. Mir erschloss sich nicht der Sinn dieses Codes, und ich habe ihn deaktiviert.
P.S. Version gelöscht, siehe weiter unten.
Kurzes Feedback von mir: Die neue Version läuft bis jetzt einwandfrei, die Performance ist geringfügig besser geworden.
Vielen Dank für deinen Einsatz!
Gruß
Thomas
Danke!
Zur Performance: Bei mir hängen eine Vielzahl von Regeln hinter dem Device. Auch der alte Parser war eigentlich relativ unbeachtlich (allerdings läuft bei mir alles auf Raspi 3 und höher): Die Kette danach kostet die CPU.
Generell finde ich den Pollmode eigentlich Mist. Er ergibt nur Sinn, wenn man nur die absoluten Zählerstände verwertet, also z.B. "Momentan"-Leistung als Delta aus den absoluten Wh-Ständen berechnet. Dann erhält man im einstelligen Watt-Bereich genaue Zahlen erst ab etwa 5 Minuten Intervall.
Daher ist eigentlich meine Zielsetzung, dass der "empfohlene" Einsatz ein permanentes Parsen ist, und wer die Systemlast reduzieren möchte, eher über das Standard-Attribut "event-aggregator" (Lesenswert!!) die Event-Rate reduziert. Nur ein Beispiel, wie ich den Shelly, der mein "Home-Office" misst und abschaltet, und wegen der Schaltnetzteile "verrückt spielt", etwas gedrosselt habe:
relay_0_power:30:linear:mean
Anbei eine neue Version. Heute morgen fand ich FHEM "aufgehängt" vor (100% CPU). Das ist mir bisher eigentlich vielleicht einmal passiert - der Verdacht liegt natürlich beim neuen Modul.
Ich habe daraufhin die Parse-Routine mit einigen 100 MB an Random-Daten beworfen und 2 Stellen im Code verbessert. Mal als "diff" für den Neugierigen:
< # $Id: 47_OBIS.pm TESTVERSION 2021-03-11 09:06:24Z gvzdus $
---
> # $Id: 47_OBIS.pm TESTVERSION 2021-03-10 15:06:44Z gvzdus $
421d420
< return undef if ($len>length $_[3] || $len<0);
457c456
< while ($len-- > 0) {
---
> while ($len--) {
Hier die geänderte Version:
(Zurückgezogen wegen mutmaßlichem Bug)
Ich hatte heute 2 Warnings aus dem neuen Modul (die Version von gestern):
2021.03.11 14:38:37 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 529.
2021.03.11 14:38:37 1: PERL WARNING: Use of uninitialized value in reverse at ./FHEM/47_OBIS.pm line 529.
Ich habe mal die Version von heute installiert, nach ca. 20 Minuten hatte ich den von dir beschriebenen Fehler (100%CPU).
Okay, dann war es wohl nicht der Parser (OBIS_Parse_List), sondern liegt noch außen drum herum. Dann ziehe ich erst mal das Ganze zurück und melde mich, wenn ich zumindest den nächsten Bug identifiziert habe.
Danke!
Ich denke, beides ist identifiziert und behoben:
- Die Meldung "substr outside..." kam, wenn im Input-Buffer ein endTag vor dem startTag von SML war. Reproduziert und behoben
- Man soll nie sagen: "Das war der letzte Bug". Aber ich konnte die "100% CPU" verifizieren, wenn ein CRC-Fehler auftritt. Stupid like that - wurde in der Schleife nicht sauber behandelt.
Anbei die natürlich beste Version aller Zeiten :-)
Die neueste Version ist jetzt über Nacht gelaufen, bisher keine Auffälligkeiten.
Ok ich teste auch mal die neue Version und gebe Rückmeldung.
Danke,
Stefan
Ja, bei mir ist auch alles friedlich mit der aktuellen Version.
Sorry ich hätte noch eine kurze Dummy Frage.
Ich nutze zur Zeit pollingmode = on und intervall = 2.
Was ist denn sinnvoller pollingmode off oder on?
Ich will eigentlich schon die aktuellen Daten live sehen.
Die Einstellung hatte ich gemacht da ich dachte damit die Last zu reduzieren.
Was wäre denn eure Empfehlung?
Ich habe zwei EMH SmartMeter die sekündlich Werte liefern an einem ESP8266 der das über zwei Serial Ports (pro Zähler einen) weiter gibt.
Gruß,
Stefan
Ausschalten! (Interval löschen, pollingMode off).
Zunächst mal hast Du den ganzen Overhead des Internal-Timers. Zweitens liest Du zu einem undefinierten Zeitpunkt, Du kannst also nicht sinnvoll mitteln. Wie ich schon schrieb: Zumindest bei mir entsteht die CPU-Last in der *Weiterverarbeitung* der Ergebnisse. Diese Last kann man viel genauer und besser mit event-aggregator auf dem Reading reduzieren.
Pollingmode ergibt m.E. erst ab allermindestens 1 Minute, besser 5 Minuten Sinn, und dann nur, wenn Du die "Momentanleistung" als
(Neuer-Zählerstand - alter-Zählerstand)/Zeit
bestimmst. Da die Genauigkeit i.d.R. 0,1 Wh ist, ergibt sich bei minütlicher Auswertung eine Messgenauigkeit von 6 Watt, bei 5 Minuten von gut 1 Watt.
Ok, danke hab es abgeschaltet.
Daten flutschen jetzt wirklich schnell.
Hab jetzt aber ziemlich oft CRC Fehler, vielleicht alle 3 bis 5 Sek einen.
Könnte aber an meinem Setup liegen, da ich die 2 Zähler mit einem ESP Auslese.
Das schaue ich mir bei Gelegenheit mal an.
Es kommen auf jeden fall sauber Daten durch.
Danke und Gruß,
Stefan
Ich würde auf unterschlagene Bytes tippen. Wenn Du mit "tcpdump" mitschneidest, sollte man das ja eingrenzen können. Auch ohne händische Analyse der SML-Bytes: Wenn Du 10 "Mess-Intervalle" als Hex untereinanderlegst, wird man das vermutlich erkennen können.
Ok, danke werde ich mal probieren.
Gruß,
Stefan
Zitat
Zunächst mal hast Du den ganzen Overhead des Internal-Timers. Zweitens liest Du zu einem undefinierten Zeitpunkt, Du kannst also nicht sinnvoll mitteln.
Zu 1) Es gibt durchaus Zähler, die nicht von selbst senden, da macht Polling-Intervall absolut Sinn (zB meiner)
Zu 2) Mittels dem Attribut allignTime hat man danach sehr wohl ienen definierten Zeitpunkt, an dem gelesen wird.
Aber ja, wenn der Zähler von selbst sendet, hat pollingMode absolut keinen Sinn.
Moin, das "undefinierter Zeitpunkt" bezog sich auf so kurze Intervalle wie 2 Sekunden. Wenn die Werte "etwa sekündlich" kommen, hat man mit "etwa alle 2 Sekunden lesen" so ziemlich schlechteste Voraussetzungen, die Messwerte als äquidistante Zeitreihe zu interpretieren, weil zwischen 0 und 0,999 Sekunden der Zufallsfehler ist.
Hi,
danke für den Input. Meine Zähler sendet ja insofern bin ich froh über den Tipp.
ich hab jetzt mal tcpdump angeworfen.
Werde aber nicht wirklich schlau daraus.
tcpdump port 23 and src 192.168.69.45
ergibt:
21:52:36.680271 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 1911301:1911406, ack 3335575270, win 5840, length 105
21:52:36.690494 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 105:116, ack 1, win 5840, length 11
21:52:36.700613 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 116:126, ack 1, win 5840, length 10
21:52:36.717293 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 126:139, ack 1, win 5840, length 13
21:52:36.731810 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 139:155, ack 1, win 5840, length 16
21:52:36.741803 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 155:165, ack 1, win 5840, length 10
21:52:36.752434 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 165:175, ack 1, win 5840, length 10
21:52:36.761343 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 175:184, ack 1, win 5840, length 9
21:52:36.770202 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 184:193, ack 1, win 5840, length 9
usw.
wenn ich
tcpdump -q -w output.dump 'port 23 and src 192.168.69.45'
Ist das dumpfile aber auch nicht besser:
Ôò¡ "ÔK`Oa
Ÿ Ÿ ²åM·QORd+
M E 'Q þ_zÀ¨E-À¨E^ ÈH *ÆÐÖæPÐæ vtümb b rcvÿÿÿÿÿÿ|T%
EMH "5rbe|UÒbc© vtünb b rcwÿÿÿÿÿÿ
EMH "5 b
ÿÿrbe"ÔK`>‰
A A ²åM·QORd+
M E 3Q þ_×À¨E-À¨E^ ÈH *nÆÐÖæPÐôK |UÒww `2"ÔK`Å°
@ @ ²åM·QORd+
M E 2Q þ_×À¨E-À¨E^ ÈH *yÆÐÖæPÐ§Ø EMH"ÔK`íñ
C C ²åM·QORd+
M E 5Q þ_ÒÀ¨E-À¨E^ ÈH *ƒÆÐÖæPÐñ€ w ` ÿ"ÔK`¢* F F ²åM·QORd+
M E 8Q þ_ÎÀ¨E-À¨E^ ÈH *ÆÐÖæPÐ~v
EMH "5w "ÔK`«Q @ @ ²åM·QORd+
usw.
Wie genau muss man das denn auswerten, bzw aufrufen um Zeilen vergleichen zu können?
Danke und Gruß,
Stefan
Okay, andere Strategie: Prüfe, ob das Paket netcat installiert ist. Dann
netcat <ip> <port> | od -A none -tx4
Guck' Dir kurz den Wikipedia-Artikel zu SML an: https://de.wikipedia.org/wiki/Smart_Message_Language
Du siehst: Jeder Block sollte eine durch 4 teilbare Anzahl Bytes haben.
Typischerweise wird Dein Output vom Kommando oben mit "1b1b1b1b 01010101 " anfangen, und das leitet jede Nachricht ein. Wenn dieses 1b1b1b1b im Laufe der Zeit "verrutscht", also zu einem "xxxx1b1b 1b1bxxxx" wird, fehlen Bytes.
Hi gvzdus,
wow richtig cool. Jetzt sehe ich die Pakete.
Tatsächlich sind nach einem restart des ESP die Fehler auf dem Hardware Serial auch weg.
Auf dem SoftwareSerial habe ich aber noch Fehler.
Das von dir beschriebene Verrutschen kann ich nicht erkennen.
Aber Pakete scheinen gekürzt zu sein.
Die Pakete sehen nicht so gleichmäßig wie auf dem SoftwareSerial aus.
Wahrscheinlich läuft mir da der SoftwareSerial Buffer auf dem ESP über.
Kannst du mal einen Blick reinwerfen.
Ich habe hier ein Log vom SoftwareSerial über ca. 2 Minuten.
Gruß und Danke,
Stefan
Naja, in Zeile 1393 ist z.B. das Problem zu sehen. Eigentlich ist bei Dir ja alle etwa 20 Zeilen die 1b1b1b1b01-Sequenz. Zeile 1393 ff:
1393 1b1b1b1b 5b64011a 10000107 01ff0007
1394 65016272 6d2b7d01 00521b62 01000055
1395 01010176 005ee663 77040576 00623e7c
1396 63720062 01710102 00c34063 1b1b1b00
1397 35011a1b 1b1b1bc0 0101011b 04057601
Hier geht es danach "mittendrin" los, und in Zeile 1397 ist das 1b1b1b1b aus dem 4er-Block rausgewandert. Und bei Zeile 1487 ist das Ganze um 2 Bytes verrutscht.
Hier sind dann doch noch 2 Warnings aus dem neuen Modul:
2021.03.13 16:06:27 1: PERL WARNING: Argument "0A01454D4800007EAB77" isn't numeric in numeric eq (==) at ./FHEM/47_OBIS.pm line 480, <FH> line 851.
2021.03.13 16:06:27 3: OBIS (EHZ) - Unknown Message: 255-255:255.255.255*255()
Zumindest Punkt 1 habe ich gefixt - da es aber völlig unkritisch ist, veröffentliche ich jetzt keine weitere Version.
Ah,
danke gvzdus,
das hatte ich mit meiner Suche nicht gesehen.
Das kommt sicher von der SoftwareSerial Implementierung im ESP.
Läuft der Buffer über verwerfe ich ihn im Moment einfach.
Ich müsste mal schauen was ich dagegen tun könnte.
Problem ist, dass der ESP doch etwas überfordert ist 2 solche ByteStreams zu verarbeiten und weiterzugeben.
Erstmal stört mich das aber nicht, für meinen Usecase ist es nicht tragisch wenn ein paar Sätze verloren gehen.
Gruß und vielen Dank
,
Stefan
Moin,
also das angepasste Modul läuft bei mir seit Freitag reibungslos. Auch sind keine "unknown Messages" mehr aufgetreten, die davor am Tag mind. 1x vorkamen.
Daumen Hoch :)
Hallo,
ich bin neu hier und habe einen ITRON ACE3000 Type 260 C20D R1 A.
Ich möchte diesen gern mit FHEM direkt auslesen.
Funktioniert das folgende define mit dem OBIS Modul?
"define myACE3000 OBIS /dev/ttyUSB0@300,7,E,1 VSM102"
Oder muss ich den Zähler noch anderweitig zum "sprechen" überreden?
Ich würde folgenden IR Kopf verwenden wollen:
https://de.elv.com/elv-bausatz-lesekopf-mit-usb-schnittstelle-fuer-digitale-zaehler-usb-iec-155523?Gads_Shopping_CSS&gclid=EAIaIQobChMIjtfCpfWx7wIVjv93Ch3wgAy3EAQYBCABEgIGZ_D_BwE
Vielen Dank.
Gruß Sven
Warum baut Ihr Euch diesen Sensor nicht selber?
Hier findet ihr meine Bauanleitung. Der Sensor kostet nur wenige Cents.
https://mwinkler.jimdo.com/smarthome/aktoren-sensoren/stromz%C3%A4hler-digital/
Die meisten Zähler in Deutschland brauchen nur einen Lesekopf, und die sind weitgehend vergleichbar. Wenige Zähler benötigen auch eine Sende-LED.
Du kannst es selber bauen, wie geschrieben, oder aber Dir auch das Löten wie bei ELV ersparen, und in der Bucht bestellen. Da gibt es vernünftige Angebote ab 20 Euro, ohne USB-Kabel teils weniger.
Nur als Beispiel:
https://www.ebay.de/itm/USB-IR-Lesekopf-EHZ-Lese-Schreib-Kopf-Volkszahler-Hichi/313455434998
"Deutschlands meiste Konfiguration" ist in FHEM dann:
define MT175 OBIS /dev/ttyUSB0@9600
oder für Fortgeschrittene, die keine Vertauschungen der USB-Ports erleben wollen:
ls /dev/serial/by-id/
define MT175 OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0@9600
Also 9600 Baud.
Ansonsten hier fragen...
Hallo,
danke für die Beiträge / Anleitung.
Klar, selber bauen oder aus der Bucht, das spart Geld.
Mich würde dennoch interessieren, ob der o.g. ITRON Zähler sich zum senden überreden lässt.
Lt.
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/itron_ace3000_type_260
benöigt dieser eine Initialisierungs-Sequenz ,,/?!" mit 300bd, 7E1 und ,,LF+CR" und läuft mit 300bd.
Ich werde es wohl einfach mal testen, denn zum Zähler selbst finde ich nicht so viel in Bezug auf FHEM/OBIS.
Gruß Sven
Moin, ich kann Dir meinen Ehrgeiz als Maintainer versichern, es zum Laufen zu bekommen - allerdings kann das viel Ping-Pong bedeuten.
Du brauchst auf jeden Fall die Variante mit Sende-LED. Das eine solche bei ELV vorhanden ist, geht nur implizit anhand der Anzeige daraus hervor. "Deutschlands meiste Konfiguration" passt für Dich nicht. Worst case musst Du volkszaehler installieren und die Daten per MQTT o.ä. an FHEM füttern.
Hey gvzdus,
danke für dein support.
Habe mir mal den https://www.ebay.de/itm/USB-IR-Lesekopf-EHZ-Lese-Schreib-Kopf-Volkszahler-Hichi/313455434998 kommen lassen und werde mich dran versuchen den ITRON zu überreden. Wenn ich Probleme habe melde ich mich hier.
Danke Sven
Hallo,
hier ein update.
Der o.g. IR Kopf funktioniert mit dem ITRON ACE3000. :)
Bekomme folgende readings:
1.8.0 - 21267 - 2021-03-17 08:10:03
C.1 - "Zählernumber" - 2021-03-17 08:10:03
C.5.0 - 0 - 2021-03-17 08:10:03
Version - ACE0\3k260V01.19 - 2021-03-17 08:09:59
state - opend
Lassen sich evtl. mehr readings abfragen (aktuelle Power o.ä.), oder ist das Zählerabhängig?
Er scheint als Einrichtungszähler parametriert zu sein.
Was sagt C.5.0?
Gruß Sven
Ich habe mal gegoogled, und das Ergebnis ist frustrierend. Also gleich der Dämpfer zu Deiner Freude.
Hier ist eine Anleitung des Zählers zu finden: https://www.photovoltaikforum.com/core/attachment/57831-ace3000-typ260-benutzerhandbuch-pdf/ (https://www.photovoltaikforum.com/core/attachment/57831-ace3000-typ260-benutzerhandbuch-pdf/)
Wie Du da siehst:
- Die Kiste kann allenfalls kWh (nicht wie die meisten Zähler: Wh) mit einer Nachkommastelle anzeigen, sofern so parametrisiert. Also Faktor 1000 bis 10.000 ungenauer als die anderen
- Nein, nach Momentanleistung sieht das nicht aus
- C.5.0 ist ein Ereignismelder, und 0 heisst wohl, dass der Zähler Dich für einen anständigen Menschen hält
Mit der Kiste kannst Du also nur stündlich auf 100 Watt genau messen, oder auf 24h auf 4 Watt genau. Was tun?
- Auf die Eichfrist gucken, wann Schiet durch was Besseres ersetzt werden könnte
- Den Meßstellenbetreiber die Ohren vollheulen. Bei mir saßen da wirklich sehr nette Menschen, die aus meinem Genöle herausgehört haben, dass der Zähler einen Defekt habe und ersetzt werden muss. Alternativ kannst Du den Messstellenbetreiber wechseln, aber die "frei gewählten" dürfen höhere Gebühren als die 20 Euro p.a. nehmen
- Eine Fachkraft Dir Deinen eigenen Zähler dahinter bauen lassen, oder so etwas wie den Shelly 3EM um die Hauptadern legen
- Dich in die Materie einlesen, ob so was Schrottiges der Definition einer modernen Meßeinrichtung im Gesetzestext entspricht, und damit beim Messstellenbetreiber nicht nur nölen, sondern qualifiziert meckern.
Sorry!
Hi,
die Anleitung zu C.5.0 hatte ich auch gefunden. Sagt ja viel aus. Danke.
Schade nur dass die Auflösung mit 100Watt so begrenzt ist. :-\
Ich werde mir noch nen S0 Zähler dahinterhängen und habe so den S0 Trigger über GPIO in Wh und den D0 Absolutwert vom ACE3000 über OBIS in Fhem.
Danke trotzdem.
Gruß Sven
Solar hast Du nicht? Dann geht ja vermutlich nicht viel mit S0 wegen fehlender Richtung.
Ich wäre schon gespannt, was ein guter eigener Stromzähler wäre, der vollumfänglich auslesbar ist. Bisher habe ich da den Orno OR-WE-516 oder OR-WE-517 gefunden, allerdings haben die wohl einen drahtgebundenen MODBUS-Ausgang.
Vielleicht hat jemand hier eine "Plug&Play"-Empfehlung...
Ich nutze neben dem Hauptzähler vom Energieversorger einen SDM630. Dieser kann über Modbus ausgelesen werden, wobei hier neben der Kabellösung auch ein ESP8266 genutzt werden könnte. Wenn mich nicht alles täuscht gibt es vom Hersteller sogar ein Wifi Modul.
Gibt es bzgl. der Übertragungsfehler beim Einsatz eines ESP8266 eine Lösung?
Ich nutze einen ESP um per Serial Server den IR Lesekopf auszulesen. Leider scheint es öfter zu Fehlern zu kommen, da meine Readings fast täglich mehr werden.
Könnte man hier eine Prüfung des empfangenen Streams einbauen?
Hallo,
ich binde meinen Stromzähler auch über einen IR-Lesekopf an, der mit RX/TX an einem ESP8266 hängt. Ich habe eigentlich nicht das von dir beschriebene Problem, welche Software hast du auf dem ESP ?
Grüße Christian
Bei mir läuft ESPEasy.
Ich lese ebenfalls über einen ESP per Serial Server die Modbus Karte eines PV Ladereglers aus - da habe ich das Problem auch nicht.
Major Update
Ich habe die Version mit dem neu geschriebenen Parser jetzt ins SVN eingestellt. Sie wird also morgen bei einem Update aktiv.
@sparkiie: Du könntest mal gucken, ob damit weniger Schrott in den Readings ankommt. Du hast aber nicht händisch den CRC-Check ausgebaut, oder? Eigentlich ist es schon unwahrscheinlich, dass der CRC-Check durchläuft, aber kaputte Readings erkannt werden. Dagegen könnte der neue Parser aber auch helfen.
Ich habe nichts ausgebaut.
Schaue mir das Ganze dann morgen mal mit dem neuen Modul an!
Hi,
ich hatte auch falsche readings trotz CRC check mit der alten Version.
Mit der neuen Version sind keine falschen readings mehr entstanden.
Würde behaupten das ist mit der neuen Version mit gefixed worden :-)
Danke gvzdus!
Gruß,
Stefan
Zitat von: stefanru am 19 März 2021, 12:20:24
Hi,
ich hatte auch falsche readings trotz CRC check mit der alten Version.
Mit der neuen Version sind keine falschen readings mehr entstanden.
Würde behaupten das ist mit der neuen Version mit gefixed worden :-)
Danke gvzdus!
Gruß,
Stefan
Bei mir sieht es bis jetzt auch sauber aus!
Ich möchte die geneigten Leserinnen und Leser des Threads noch einmal ermutigen, einen Update von FHEM (und damit des 47_OBIS-Moduls) durchzuführen.
Am Wochenende kann ich besser reagieren, wenn es Probleme geben sollte...
Ich habe eben das Update auf die neuste Version aus dem SVN gemacht läuft auch soweit auf den ersten Blick. Anschließend habe ich diese Empfehlung:
Zitat von: gvzdus am 12 März 2021, 18:22:33
Ausschalten! (Interval löschen, pollingMode off).
mit pollingMode off probiert. Ergebnis ist allerdings folgenden:
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:46 3: OBIS (zaehler) - Init done
2021.03.26 08:25:46 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:46 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:46 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.26 08:25:47 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.26 08:25:47 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.26 08:25:47 3: OBIS (zaehler) - Init done
2021.03.26 08:25:47 1: /dev/ttyUSB1 reappeared (zaehler)Dann habe ich mich wieder erinnert warum ich bei der Einrichtung letztes Jahr den pollingmode auf on gesetzt habe (hat also nichts mit dem aktuellen Update zu tun). Damit funktioniert es einwandfrei. Jemand eine Idee woran das liegen könnte? Anbei noch ein List vom Device:
nternals:
CRC_Errors 6
DEF /dev/ttyUSB1@9600,8,N,1 SML
DeviceName /dev/ttyUSB1@9600,8,N,1
FUUID 5f6dd829-f33f-ed05-f4d0-814621a84360c246
MeterType SML
NAME zaehler
NEXT 2021-03-26 08:33:45
NR 366
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2021-03-26 08:33:38 HausverbrauchW 8017
2021-03-26 08:33:38 HausverbrauchW_selfPV 8285.5
2021-03-26 08:33:38 ManufID2 EFR
2020-12-04 19:22:12 negativPower -380
2021-03-26 08:33:38 negativPowerkW 3.586
2021-03-26 08:33:38 power -3586
2021-03-26 08:25:47 state opened
2021-03-26 08:33:38 total_consumption 2676841.6
2021-03-26 08:33:38 total_consumption_Ch1 1535998.2
2021-03-26 08:33:38 total_consumption_Ch2 1140843.4
2021-03-26 08:33:38 total_feed 4197545.4
2021-03-26 08:33:38 total_feed_Ch1 3484671.4
2021-03-26 08:33:38 total_feed_Ch2 712874
helper:
BUFFER
EoM -1
LastPacketTime 1616744018.72764
SPEED 5
SPEED2 5
TRIGGERTIME 1616744025
Channels:
DEVICES:
5
RULECACHE:
1-0:1.8.0*255 Counter
1-0:1.8.1*255 Counter
1-0:1.8.2*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:2.8.1*255 Counter
1-0:2.8.2*255 Counter
1-0:96.50.1*1 ManufID2
255-255:255.255.255*255 unknown
directions:
Attributes:
alignTime 00:00:00
event-min-interval total.*:86400
event-on-change-reading power:10,total_consumption:10,total_consumption_Ch1:10,total_consumption_Ch2:10,total_feed:10,total_feed_Ch1:10,total_feed_Ch2:10,.*
interval 5
pollingMode on
verbose 3
Tritt die "Hektik" auch auf, wenn sowohl interval löscht als auch pollingMode auf off setzt?
Raspbian Buster?
Könnte es einen Konflikt um den Zugriff auf das Device geben (noch ein anderes Device, dass meint, für /dev/usb.. zuständig zu sein?)
interval löschen ändert nichts an dem Verhalten. Auch ein shutdown restart hat daran nicht verändert. OS ist Debian Buster auf einer ZBOX CI320. Ein anderes Device, welches auf /dev/ttyUSB1 zugreift habe ich nicht. Ausschließlich ein Modbus USB Stickt wird auf /dev/ttyUSB0 verwendet, dieser funktioniert mit dem 98_Modbus.pm auch einwandfrei. Wie könnte ich denn ermitteln, ob ggf. noch jemand anderes versucht auf das /dev/ttyUSB1 zuzugreifen?
Ich habe mal bei mir von "ser2net" (um am Produktions-Raspi *und* am Testsystem die Zählerdaten lesen zu können) auf "direkt" umgestellt - klappt bei mir super.
Die Fehlermeldung "disappeared, waiting to ..." kommt aus der DevIO-Bibliothek. Ein Grund ist z.B., wenn beim select das Vorhandensein von Daten gemeldet wird, aber dann beim tatsächlichen Lesen nichts kommt.
Ich weiß nicht, wie forschungsfreudig Du bist. Du könntest mal folgendes machen:
- Wieder polling / interval abschalten
- Auf der Shell einloggen, root werden
- PID von FHEM bestimmen
- "strace -p <pid> > strace.log 2>&1" für 10 Sekunden laufen lassen (jedenfalls so lange, dass Du einen "disappeared" im Kasten hast)
Das sieht bei mir dann so aus:
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
_newselect(120, [4 5 6 7 9 23 43 49 77 78 80 82 83 84 86 87 88 89 91 104 107 113 114], NULL, NULL, {tv_sec=1, tv_usec=912208}) = 1 (in [86], left {tv_sec=1, tv_usec=912034})
read(86, "'0\33-\16\246\372O\3162\\\331i\1", 255) = 14
_newselect(120, [4 5 6 7 9 23 43 49 77 78 80 82 83 84 86 87 88 89 91 104 107 113 114], NULL, NULL, {tv_sec=1, tv_usec=910135}) = 1 (in [86], left {tv_sec=1, tv_usec=905526})
read(86, "\1\1c\3276\0v\5\2\34\271\26b\0b\0", 255) = 16
_newselect(120, [4 5 6 7 9 23 43 49 77 78 80 82 83 84 86 87 88 89 91 104 107 113 114], NULL, NULL, {tv_sec=1, tv_usec=903762}) = 1 (in [86], left {tv_sec=1, tv_usec=889178})
read(86, "rc\2\1q\1c\340\37\0\33\33\33\33\32\0", 255) = 16
_newselect(120, [4 5 6 7 9 23 43 49 77 78 80 82 83 84 86 87 88 89 91 104 107 113 114], NULL, NULL, {tv_sec=1, tv_usec=887115}) = 1 (in [86], left {tv_sec=1, tv_usec=872835})
read(86, "]x", 255) = 2
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
Hier siehst Du: In der Hauptschleife von FHEM wird select (_newselect) aufgerufen, um auf zig offenen Files auf Input zu warten. Er kommt zurück mit "Jo, auf 86 liegt was an". Das ist (bei mir) der Filedescriptor mit dem USB-Lesekopf. Anschließend wird im Modul das Read aufgerufen und die Daten ausgelesen. Und wie Du siehst, liest er tatsächlich in 16 Byte-Häppchen... (Ein Grund, warum ich die Routine für das "Vollständig?" so beschleunigen wollte).
Ich wäre jetzt neugierig, wie das bei Dir aussieht.
Danke dir für deine Hilfe! :)
Ich habe es nach deiner Anleitung ausgeführt, im folgenden Ergebnis sollten zwei open bis disconnect enthalten sein, wenn ich das richtig sehe.
stat("/dev/ttyUSB1", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xbc, 0x1), ...}) = 0
openat(AT_FDCWD, "/dev/ttyUSB1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 30
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
lseek(30, 0, SEEK_CUR) = -1 ESPIPE (Nicht erlaubter Seek)
fstat(30, {st_mode=S_IFCHR|0660, st_rdev=makedev(0xbc, 0x1), ...}) = 0
fcntl(30, F_SETFD, FD_CLOEXEC) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 3: Setting z"..., 71) = 71
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 3: OBIS (zae"..., 50) = 50
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 1: /dev/ttyU"..., 57) = 57
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
select(40, [4 5 6 7 8 9 12 13 19 20 21 22 23 24 25 26 28 29 30 31 33], [21 28], NULL, {tv_sec=0, tv_usec=20175}) = 4 (in [13 30], out [21 28], left {tv_sec=0, tv_usec=20141})
read(30, "\\\1c\16\241\0v\5\2\211\236\"b\0b\0rc\7\1w\7\377\377\377\377\377", 255) = 27
read(30, "", 255) = 0
select(32, [30], NULL, NULL, {tv_sec=0, tv_usec=10000}) = 0 (Timeout)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 1: /dev/ttyU"..., 80) = 80
ioctl(30, TCFLSH, TCIOFLUSH) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(30, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
close(30) = 0
close(30) = -1 EBADF (Ungültiger Dateideskriptor)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
read(13, "GET /fhem?XHR=1&cmd=%7Bint%28Rea"..., 1024) = 160
stat("./www/pgm2/dark.js", 0x55bacacd34e8) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(21, "\27\3\3\1\f\347(_\202~\245X\rw\317)\"R\215\347\240\17\340W38^J\351svl"..., 273) = 273
write(28, "\27\3\3\1\fz\376\273z\302\303\241j\24\231\277*\352b\205P\263\265\216$ \370\4\371p\350@"..., 273) = 273
select(40, [4 5 6 7 8 9 12 13 19 20 21 22 23 24 25 26 28 29 31 33], [13], NULL, {tv_sec=0, tv_usec=26680}) = 1 (out [13], left {tv_sec=0, tv_usec=26637})
write(13, "HTTP/1.1 200 OK\r\nContent-Length:"..., 135) = 135
close(13) = 0
stat("/dev/ttyUSB1", {st_mode=S_IFCHR|0660, st_rdev=makedev(0xbc, 0x1), ...}) = 0
openat(AT_FDCWD, "/dev/ttyUSB1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 13
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
lseek(13, 0, SEEK_CUR) = -1 ESPIPE (Nicht erlaubter Seek)
fstat(13, {st_mode=S_IFCHR|0660, st_rdev=makedev(0xbc, 0x1), ...}) = 0
fcntl(13, F_SETFD, FD_CLOEXEC) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 3: Setting z"..., 71) = 71
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 3: OBIS (zae"..., 50) = 50
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 1: /dev/ttyU"..., 57) = 57
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
select(40, [4 5 6 7 8 9 12 13 19 20 21 22 23 24 25 26 28 29 31 33], [21 28], NULL, {tv_sec=0, tv_usec=4673}) = 3 (in [13], out [21 28], left {tv_sec=0, tv_usec=4635})
read(13, "\1\1\1\1\1\4EFR\1w", 255) = 11
read(13, "", 255) = 0
select(16, [13], NULL, NULL, {tv_sec=0, tv_usec=10000}) = 1 (in [13], left {tv_sec=0, tv_usec=4358})
read(13, "\7\1\0`\1\0\377\1\1\1\1\v\n\1E", 255) = 15
write(28, "\27\3\3\0\211z\376\273z\302\303\241k\317/IP\315U\201I\255\206[|\t\27#x\320^\314"..., 142) = 142
write(21, "\27\3\3\0\211\347(_\202~\245X\16\234\216\367}\327\300\2\237\354\347\2366\243\2411Y\220\231\t"..., 142) = 142
write(4, "\1\3~2\0\17\274)", 8) = 8
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=1000}) = 0 (Timeout)
select(40, [4 5 6 7 8 9 12 13 19 20 21 22 23 24 25 26 28 29 31 33], NULL, NULL, {tv_sec=0, tv_usec=317641}) = 1 (in [13], left {tv_sec=0, tv_usec=308870})
read(13, "FR \3\262\2520\1w\7\1\0\1\10\0", 255) = 15
read(13, "", 255) = 0
select(16, [13], NULL, NULL, {tv_sec=0, tv_usec=10000}) = 0 (Timeout)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(3, "2021.03.26 20:10:54 1: /dev/ttyU"..., 80) = 80
ioctl(13, TCFLSH, TCIOFLUSH) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(13, TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
close(13) = 0
close(13) = -1 EBADF (Ungültiger Dateideskriptor)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
select(40, [4 5 6 7 8 9 12 19 20 21 22 23 24 25 26 28 29 31 33], [21 28], NULL, {tv_sec=0, tv_usec=272319}) = 2 (out [21 28], left {tv_sec=0, tv_usec=272270})
write(28, "\27\3\3\0\233z\376\273z\302\303\241l\221\252\362@\3136|e\27\242\336\344\314K\6\253!\224\277"..., 160) = 160
write(21, "\27\3\3\0\233\347(_\202~\245X\17\216\371\36\253Y_iO\23&\34qg\363+>\23\17\330"..., 160) = 160
Das ist ja ziemlich verrückt!
FHEM erhält im Select die Nachricht: "Da sind Daten da!". Und dann wird direkt 2-mal hintereinander gelesen. Beim ersten Mal gibt es Daten, beim 2. Mal nicht, und das wird als "disappeared" interpretiert.
Also, Verdacht #1 ist wirklich: Du hast 2 Geräte auf /dev/ttyUSB1 konfiguriert. Mit "grep /dev/ttyUSB1 /opt/fhem/fhem.cfg" gäbe es zumindest mehrere Zeilen, wenn Du es auch unter dem Namen /dev/ttyUSB1 gemacht hast.
Wenn Du magst, erweitere mal den Code ab Zeile 333 um 2 Logzeilen (die Zeilen mit "Log3" einfügen):
if( $init_done ) {
my $name = $hash->{NAME};
Log3 $hash, 5, "OBIS ($name) - OBIS_Read called, hash is " . $hash;
my $buf = DevIo_SimpleRead($hash);
Log3 $hash, 5, "OBIS ($name) - OBIS_Read gave " . (defined($buf) ? length($buf) : "null");
return if(!defined($buf));
Neustarten oder Reloaden, und dann für ein paar Sekunden auf "verbose 5" gehen. Bei mir sieht das dann so im Logfile aus:
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 16
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 14
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 16
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 16
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 14
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 16
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 16
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 14
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read called, hash is HASH(0x3a85de0)
2021.03.26 21:00:55 5: OBIS (MT175) - OBIS_Read gave 12
2021.03.26 21:00:55 5: OBIS (MT175) - SML-Parse 1B1B1B1B010101017605021D835B62006200726301017601010500B4811F0B090149534B00047FE6A10101631569007605021D835C620062007263070177010B090149534B00047FE6A1070100620AFFFF7262016501352D527D77078181C78203FF010101010449534B0177070100000009F
P.S.:
attr initialUsbCheck disable 1
ist gesetzt?
initialUsbCheck habe ich von Anfang an schon gelöscht. Das Notify existiert bei mir also nicht. Das grep liefert wie erwartet ausschließlich:
root@home:/opt/fhem/FHEM# grep /dev/ttyUSB1 /opt/fhem/fhem.cfg
define zaehler OBIS /dev/ttyUSB1@9600,8,N,1 SML
Die Log3 Zeilen habe ich im Modul mal ergänzt. Mit pollingmode on und interval 5 kommt folgendes:
2021.03.27 10:20:00 4: OBIS (zaehler) - Wrote
2021.03.27 10:20:00 5: OBIS (zaehler) - Internal timer set to 2021-03-27 10:20:05
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read gave 109
2021.03.27 10:20:01 5: OBIS (zaehler) - SML-Parse 1B1B1B1B010101017605028BF3126200620072630101760107FFFFFFFFFFFF0500D951070B0A014546522003B2AA3072620164F687570163DCD7007605028BF31362006200726307017707FFFFFFFFFFFF0B0A014546522003B2AA30070100620AFFFF72620164F6875779770701006032010101010101044546520177070100600100FF010101010B0A014546522003B2AA300177070100010800FF641C010472620164F68757621E52FF65019961440177070100010801FF641C010472620164F68757621E52FF64EAF4D40177070100010802FF641C010472620164F68757621E52FF64AE6C700177070100020800FF0172620164F68757621E52FF65028CDA9E0177070100020801FF0172620164F68757621E52FF65021F05680177070100020802FF0172620164F68757621E52FF646DD5360177070100100700FF0101621B520053032201010163FBFD007605028BF3146200620072630201710163C46F0000001B1B1B1B1A02340B
2021.03.27 10:20:01 5: OBIS (zaehler) - Full message-> 1B1B1B1B010101017605028BF3126200620072630101760107FFFFFFFFFFFF0500D951070B0A014546522003B2AA3072620164F687570163DCD7007605028BF31362006200726307017707FFFFFFFFFFFF0B0A014546522003B2AA30070100620AFFFF72620164F6875779770701006032010101010101044546520177070100600100FF010101010B0A014546522003B2AA300177070100010800FF641C010472620164F68757621E52FF65019961440177070100010801FF641C010472620164F68757621E52FF64EAF4D40177070100010802FF641C010472620164F68757621E52FF64AE6C700177070100020800FF0172620164F68757621E52FF65028CDA9E0177070100020801FF0172620164F68757621E52FF65021F05680177070100020802FF0172620164F68757621E52FF646DD5360177070100100700FF0101621B520053032201010163FBFD007605028BF3146200620072630201710163C46F0000001B1B1B1B1A02340B
2021.03.27 10:20:01 4: OBIS (zaehler) - MSG IS:
/
1-0:96.50.1*1(EFR)
1-0:96.1.0*255(
EFR 0)
1-0:1.8.0*255(2682912.4*Wh)
1-0:1.8.1*255(1539810*Wh)
1-0:1.8.2*255(1143102.4*Wh)
1-0:2.8.0*255(4278543.8*Wh)
1-0:2.8.1*255(3558743.2*Wh)
1-0:2.8.2*255(719800.6*Wh)
1-0:16.7.0*255(802*W)
255-255:255.255.255*255()
!
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: /
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:96.50.1*1(EFR)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:96.50.1*1(EFR) is of type ManufID2
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:96.1.0*255(
EFR 0)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.0*255(2682912.4*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:1.8.0*255(2682912.4*Wh) is of type Counter
2021.03.27 10:20:01 4: OBIS (zaehler) - Set total_consumption to 2682912.4
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.1*255(1539810*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:1.8.1*255(1539810*Wh) is of type Counter
2021.03.27 10:20:01 4: OBIS (zaehler) - Set total_consumption_Ch1 to 1539810
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.2*255(1143102.4*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:1.8.2*255(1143102.4*Wh) is of type Counter
2021.03.27 10:20:01 4: OBIS (zaehler) - Set total_consumption_Ch2 to 1143102.4
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.0*255(4278543.8*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:2.8.0*255(4278543.8*Wh) is of type Counter
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.1*255(3558743.2*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:2.8.1*255(3558743.2*Wh) is of type Counter
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.2*255(719800.6*Wh)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:2.8.2*255(719800.6*Wh) is of type Counter
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 1-0:16.7.0*255(802*W)
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg 1-0:16.7.0*255(802*W) is of type Channels
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: 255-255:255.255.255*255()
2021.03.27 10:20:01 5: OBIS (zaehler) - Msg-Parse: !
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:01 5: OBIS (zaehler) - OBIS_Read gave 55
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 17
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 59
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 14
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 61
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 90
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 30
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 75
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:04 5: OBIS (zaehler) - OBIS_Read gave 20
2021.03.27 10:20:05 5: SW:
2021.03.27 10:20:05 4: OBIS (zaehler) - Wrote
2021.03.27 10:20:05 5: OBIS (zaehler) - Internal timer set to 2021-03-27 10:20:10
2021.03.27 10:20:05 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:05 5: OBIS (zaehler) - OBIS_Read gave 20
2021.03.27 10:20:05 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:05 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read gave 74
2021.03.27 10:20:06 5: OBIS (zaehler) - SML-Parse 1B1B1B1B010101017605028BF3216200620072630101760107FFFFFFFFFFFF0500D9510C0B0A014546522003B2AA3072620164F6875C016312F1007605028BF32262006200726307017707FFFFFFFFFFFF0B0A014546522003B2AA30070100620AFFFF72620164F6875C79770701006032010101010101044546520177070100600100FF010101010B0A014546522003B2AA300177070100010800FF641C010472620164F6875C621E52FF65019961500177070100010801FF641C010472620164F6875C621E52FF64EAF4E00177070100010802FF641C010472620164F6875C621E52FF64AE6C700177070100020800FF0172620164F6875C621E52FF65028CDA9E0177070100020801FF0172620164F6875C621E52FF65021F05680177070100020802FF0172620164F6875C621E52FF646DD5360177070100100700FF0101621B520053033E01010163C873007605028BF3236200620072630201710163ED5C0000001B1B1B1B1A02E591
2021.03.27 10:20:06 5: OBIS (zaehler) - Full message-> 1B1B1B1B010101017605028BF3216200620072630101760107FFFFFFFFFFFF0500D9510C0B0A014546522003B2AA3072620164F6875C016312F1007605028BF32262006200726307017707FFFFFFFFFFFF0B0A014546522003B2AA30070100620AFFFF72620164F6875C79770701006032010101010101044546520177070100600100FF010101010B0A014546522003B2AA300177070100010800FF641C010472620164F6875C621E52FF65019961500177070100010801FF641C010472620164F6875C621E52FF64EAF4E00177070100010802FF641C010472620164F6875C621E52FF64AE6C700177070100020800FF0172620164F6875C621E52FF65028CDA9E0177070100020801FF0172620164F6875C621E52FF65021F05680177070100020802FF0172620164F6875C621E52FF646DD5360177070100100700FF0101621B520053033E01010163C873007605028BF3236200620072630201710163ED5C0000001B1B1B1B1A02E591
2021.03.27 10:20:06 4: OBIS (zaehler) - MSG IS:
/
1-0:96.50.1*1(EFR)
1-0:96.1.0*255(
EFR 0)
1-0:1.8.0*255(2682913.6*Wh)
1-0:1.8.1*255(1539811.2*Wh)
1-0:1.8.2*255(1143102.4*Wh)
1-0:2.8.0*255(4278543.8*Wh)
1-0:2.8.1*255(3558743.2*Wh)
1-0:2.8.2*255(719800.6*Wh)
1-0:16.7.0*255(830*W)
255-255:255.255.255*255()
!
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: /
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:96.50.1*1(EFR)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:96.50.1*1(EFR) is of type ManufID2
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:96.1.0*255(
EFR 0)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.0*255(2682913.6*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:1.8.0*255(2682913.6*Wh) is of type Counter
2021.03.27 10:20:06 4: OBIS (zaehler) - Set total_consumption to 2682913.6
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.1*255(1539811.2*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:1.8.1*255(1539811.2*Wh) is of type Counter
2021.03.27 10:20:06 4: OBIS (zaehler) - Set total_consumption_Ch1 to 1539811.2
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:1.8.2*255(1143102.4*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:1.8.2*255(1143102.4*Wh) is of type Counter
2021.03.27 10:20:06 4: OBIS (zaehler) - Set total_consumption_Ch2 to 1143102.4
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.0*255(4278543.8*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:2.8.0*255(4278543.8*Wh) is of type Counter
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.1*255(3558743.2*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:2.8.1*255(3558743.2*Wh) is of type Counter
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:2.8.2*255(719800.6*Wh)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:2.8.2*255(719800.6*Wh) is of type Counter
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 1-0:16.7.0*255(830*W)
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg 1-0:16.7.0*255(830*W) is of type Channels
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: 255-255:255.255.255*255()
2021.03.27 10:20:06 5: OBIS (zaehler) - Msg-Parse: !
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read gave 255
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:06 5: OBIS (zaehler) - OBIS_Read gave 102
2021.03.27 10:20:07 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:07 5: OBIS (zaehler) - OBIS_Read gave 7
2021.03.27 10:20:07 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:07 5: OBIS (zaehler) - OBIS_Read gave 153
2021.03.27 10:20:08 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:08 5: OBIS (zaehler) - OBIS_Read gave 211
2021.03.27 10:20:08 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:08 5: OBIS (zaehler) - OBIS_Read gave 176
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 188
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 62
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 14
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 60
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 89
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 30
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 74
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:20:09 5: OBIS (zaehler) - OBIS_Read gave 20
2021.03.27 10:20:10 5: SW:
Mit gelöschtem pollingmode und interval kommt folgendes:
021.03.27 10:24:11 3: Opening zaehler device /dev/ttyUSB1
2021.03.27 10:24:11 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:11 3: OBIS (zaehler) - Init done
2021.03.27 10:24:11 3: zaehler device opened
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read gave 6
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:12 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:12 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:12 3: OBIS (zaehler) - Init done
2021.03.27 10:24:12 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read gave 16
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:12 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:12 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 2
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 3
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 3
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 10
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 3
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 6
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 8
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:14 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:14 3: OBIS (zaehler) - Init done
2021.03.27 10:24:14 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 7
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:14 5: OBIS (zaehler) - OBIS_Read gave 2
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave 10
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave null
2021.03.27 10:24:15 3: Setting zaehler serial parameters to 9600,8,N,1
2021.03.27 10:24:15 3: OBIS (zaehler) - Init done
2021.03.27 10:24:15 1: /dev/ttyUSB1 reappeared (zaehler)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave 123
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave 15
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read called, hash is HASH(0x559c9f968970)
2021.03.27 10:24:15 1: /dev/ttyUSB1 disconnected, waiting to reappear (zaehler)
2021.03.27 10:24:15 5: OBIS (zaehler) - OBIS_Read gave null
Okay. Könntest Du bei gelöschtem Polling-Mode einmal folgendes eingeben:
{ join (" ", map { $_ . "->" . $selectlist{$_}->{FD}} ( keys %selectlist ) ) }
Dabei kommt raus, welche Funktionen auf welchem Filedeskriptor lauschen, und zwar in der Syntax
"Eintrag -> <FileDescriptor>". Mein Verdacht: Du findest 2 Einträge (einer davon bei Dir vermutlich "Zaehler./dev/usb.."), die auf die gleiche Zahl zeigen.
Leckomio! Ich kann's reproduzieren!
Und zwar mit explizitem Polling-Mode off. Dann erhalte ich bei meinem Kommando:
MT175./dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0->107
MT175./dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0@9600,8,N,1->107
Dies führt zum doppelten Read-Aufruf, der dann einen vermeintlichen Fehler liefert. Bis zum Bugfix probier' doch bitte mal:
Attribute interval und pollingMode komplett löschen, Config speichern, "shutdown restart". Dann ist bei mir wieder Ruhe.
Damit kommen wir der Sache wahrscheinlich näher:
zaehler./dev/ttyUSB1->19
zaehler./dev/ttyUSB1@9600,8,N,1->19
ich kann mir allerdings nicht erklären, warum er das ohne Baudrate probiert?
Bei pollmode on sieht es so aus:
zaehler./dev/ttyUSB1->
EDIT: Ah hat sich überschnitten. Probiere ich dann gleich aus. Muss erst mal los. Melde mich heute Nachmittag. Vielen Dank für deine Hilfe. :)
Jo, siehe mein Posting eins drüber. Probier' bitte mal meinen Workaround oben, jetzt muss ich mich erst mal um die Family kümmern.
Es funktioniert! 8) Dabei war ich der festen Meinung, dass ich schon mal ein shutdown restart gemacht hatte, aber ggf. nur mit einem pollingmode off und nicht mit gelöschtem Attribut. Jetzt fliegen die Events nur so rein, durch PV und dem heute minütlich wechselndem Wetter. Dafür muss ich mir noch einen sinnvollen event-aggregator einfallen lassen. ;) Nochmals vielen Dank und ein schönes Wochenende. Falls ich für den Bugfix noch etwas testen soll, dann lass es mich wissen.
event-aggregator power:5:linear:mean
sollte z.B. "richtig" über 5 Sekunden mitteln. Aber die Nachkommastellen nerven :-)
Das Kernproblem habe ich gefixt, aber ich möchte es noch ganz sauber bekommen, mit den Übergängen polling on/off.
Morgen kommt eine neue Version per update - wer schon einmal testen (und HALT schreien möchte), unten hängt sie an.
Vor allem habe ich die Übergänge "pollingMode an / aus" etc. getestet. Neue Regel: "Polling" ist nur, wenn interval und pollMode gesetzt sind, sonst wird dauerhaft gelesen.
@Chris: Du machst wohl das Gleiche wie ich: PV-Überschuss-Steuerung. Es ist so eine Philosophie-Frage: Man könnte mit Mittelwerten über Zeit X arbeiten. Ich arbeite mit Events und Watchdogs: Z.B. wird bei 100 Watt Überschuss sofort ein Dummy "stromplus100" gesetzt, und darauf sitzt dann ein Watchdog, dass nach Zeit x Verbraucher zuschaltet. Nach Murphy schaltet dann das Laden des E-Autos ein, kurz bevor die nächste Wolke kommt, um Auszuschalten, kurz bevor die nächste Wolke schon fast wieder vorbei ist :-)
Zitat von: gvzdus am 27 März 2021, 21:01:51
... Nach Murphy schaltet dann das Laden des E-Autos ein, kurz bevor die nächste Wolke kommt, um Auszuschalten, kurz bevor die nächste Wolke schon fast wieder vorbei ist :-)
Für dieses Problem gibt es beim E3DC Hauskraftwerk eine optionale Einstellung:
wenn der PV Überschuss nicht mehr zum laden des Elektrofahrzeugs reicht, wird mit der einstellbaren Mindestladeleistung für eine ebenfalls einstellbare Zeit mit Netzbezug weitergeladen.
Kommt in dieser Zeit kein PV-Überschuss mehr, wird das Laden unterbrochen, bis erneut PV-Überschuss vorhanden ist ;o)
Murphy schlägt aber auch mit dieser Lösung ab und an zu 8)
Hi,
nach dem aktuellen Update (2021-03-27 19:52:47Z) zeigt mein Zähler keine negativen werte mehr an, vorher ging das problemlos?
Also wenn z.b. L1 -100 W (Pv einspeisung) haben sollte wird nur der Wert 1,8 W bei L1 angezeigt und auch der Wert power geht nicht auf - ?!?
bzw. vorher war L1 ja 1.0.36.7.0.255 und power_L1 bis power_L3 hatte ich vorher nicht
wäre toll wenn das wieder Klapt.
Danke
Gruß
Markus
Hi Markus,
kriegen wir gefixt.
Du weißt, dass Du unter /opt/fhem/restoreDir/update/<datum>/FHEM/47_OBIS.pm die alte Version für den Rollback findest?
Ich hätte gerne:
a) die alte Versionsnummer
b) ein paar Sekunden auf "verbose 5" aus dem FHEM-Log, die einen negativen Wert liefern (geht vermutlich nur tagsüber :-) ) - konkret brauche ich nur die "Full message-> 1B1B..."-Zeilen
Entweder per Privatnachricht oder hier im Forum.
Markus hat mir die Daten per Pmail zugeschickt.
Mit meinem neuen Parser ist ein Bug beim Parsen von 64bit Integer-Zahlen reingekommen: (1 << 64 ist bei "meinem" und sicherlich vielen anderen Perls 0).
Bugfix ist eingecheckt und morgen ab 8 Uhr live. Ich greife jetzt für 32 und 64-Bit-Zahlen auf unpack zurück (vermutlich eh schneller), bei > 64 Bit kommt eine Warnung, dass Perl hier streikt.
eben upgedatet...
Perfekt !!! funktioniert wieder Super
Vielen Dank für die schnelle Hilfe
Gruß
Markus
Hi, zuerst vielen Dank für deine tolle Arbeit ! Ich konnte nach dem Wechsel nun meinen Zähler wie folgt integrieren -> IR TTL Lesekopf -> NodeMCU -> SerialServer -> FHEM / OBIS Modul. Das funktioniert auch soweit... folgend ein List des Gerätes:
Internals:
CRC_Errors 2
DEF 192.168.178.x:23
DeviceName 192.168.178.x:23
FD 54
FUUID 606dc767-f33f-8d9b-8879-e241b616796c94f2
MeterType SML
NAME UG_Stromzaehler
NR 199
PARTIAL
STATE 705 kWh / 0 W / opened
TYPE OBIS
READINGS:
2021-04-08 00:15:40 ManufID EBZ
2021-04-08 00:15:40 Serial 09-0xxxx
2021-04-08 00:07:26 state opened
2021-04-08 00:15:40 total_consumption 705000
2021-04-08 00:15:40 total_consumption_Ch1 704000
2021-04-08 00:15:40 total_consumption_Ch2 1000
2021-04-08 00:15:40 total_feed 2000
helper:
BUFFER v�{bbreveBZDD3 EBZ
��c%&v�{bbrew EBZ
��rbeG��vw��ǂ�EBZw � EBZ
��w�d�b Re�w�b Re�w�b Re
EoM -1
LastPacketTime 1617833740.81676
NETDEV 1
SPEED 5
TRIGGERTIME 1617833472.37623
Channels:
DEVICES:
5
RULECACHE:
1-0:0.0.9*255 Serial
1-0:1.8.0*255 Counter
1-0:1.8.1*255 Counter
1-0:1.8.2*255 Counter
1-0:2.8.0*255 Counter
129-129:199.130.3*255 ManufID
directions:
Attributes:
DbLogExclude .*
event-on-change-reading .*
interval 5
pollingMode on
stateFormat {sprintf("%.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " / ". sprintf("%.0f W", ReadingsVal($name,"power",0)). " / ".ReadingsVal($name,"state",0)}
unitReadings off
Ich bekomme also die ersten Readings ausgelesen, welche auch im Sekundentakt aktualisieren. Ich habe den Zähler mittels PIN (Taschenlampe) "freigeschaltet"... leider fehlen mir die erhofften Readings wie POWER, Verbrauchshistorie usw...
Ich habe die vorhandene Doku soweit gelesen, kann aber keinen Hinweis finden.
In der Herstellerdoku findet sich folgendes:
Kennziffer Bedeutung
1.8.0 Strombezug gesamt
1.8.1 Strombezug Tarifzone 1
1.8.2 Strombezug Tarifzone 2
2.8.0 Stromlieferung gesamt
Rollierende Anzeige auf dem Display ohne Tarifierung
1.8.0 Strombezug gesamt, tariflos
2.8.0 Stromlieferung, falls Lieferzählwerk vorhanden
Info Bedeutung der Anzeige in Feld 6
PIN PIN-Eingabe erforderlich
P Aktuelle Leistung
E Verbrauch seit letzter Nullstellung
1d Verbrauch der letzten 24 Stunden
7d Verbrauch der letzten 7 Tage
30d Verbrauch der letzten 30 Tage
365d Verbrauch der letzten 365 Tage
0.2.2 Aktivierung PIN-Schutz
Du kannst ja vielleicht mal die Anleitung verlinken.
Auf mich wirken die Readings so, als wäre die PIN nicht / nicht richtig eingegeben worden. Zumindest war es bei meinem EMH-Zähler so, dass ohne PIN einerseits die kWh-Angaben so ungenau wie bei Dir waren (eben nur ganze kWh statt Wh mit 1 Nachkommastelle) und kein Momentanwert.
Natürlich *kann* es sein, dass das Gerät es nicht kann. Aber die genaue Modellbezeichnung erwähnst Du leider nicht.
Zitat von: gvzdus am 08 April 2021, 09:32:58
Du kannst ja vielleicht mal die Anleitung verlinken.
Auf mich wirken die Readings so, als wäre die PIN nicht / nicht richtig eingegeben worden. Zumindest war es bei meinem EMH-Zähler so, dass ohne PIN einerseits die kWh-Angaben so ungenau wie bei Dir waren (eben nur ganze kWh statt Wh mit 1 Nachkommastelle) und kein Momentanwert.
Natürlich *kann* es sein, dass das Gerät es nicht kann. Aber die genaue Modellbezeichnung erwähnst Du leider nicht.
danke für deine Antwort. Der LINK ist folgender: https://iam.westnetz.de/-/media/westnetz/documents/fuer-unsere-partner/edifact/edl21-kurzanleitung.pdf?la=de-DE&hash=1FE6C7E2F31D2340EB2FC18FE10967C2A886BA57 (https://iam.westnetz.de/-/media/westnetz/documents/fuer-unsere-partner/edifact/edl21-kurzanleitung.pdf?la=de-DE&hash=1FE6C7E2F31D2340EB2FC18FE10967C2A886BA57)
Ein Foto kann ich nachher zu Hause machen.
Nach der PIn eingabe konnte ich immerhin mehr ablesen, aber nicht auslesen.
Bei solchen Fällen gucke ich bei den Kollegen von volkszaehler nach - die haben halt eine gute "Zählerdatenbank". Der EDL21 von EMH ist da als "Null problemo" drin:
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/edl21-ehz
Ich habe nichts weiter gefunden, was Dir helfen könnte, sorry. Daher würde ich an Deiner Stelle mit dem Messstellenbetreiber telefonieren. In der Hoffnung, dass Du da auf Kompetenz triffst (bei mir bei der NEW definitiv der Fall):
"Ich habe die PIN erfolgreich eingegeben, die 2. Zeile ist auch sichtbar, aber auf der OBIS-Schnittstelle kommen nur verkürzte Datensätze heraus".
Ich habe jedenfalls keine Infos gefunden, dass man noch einmal nach eingegebener PIN explizit "vollständiger Datensatz" in irgend einem Menu aktivieren könnte.
Bei meinem musste ich auch nach der Pineingabe noch Info auf ON stellen. Vielleicht ist das hier ja auch so.
Hallo,
ich habe am 5. April das Obis Modul aktualisiert.
Seit dem scheint der DZG Patch nicht mehr zu Funktionieren. Ich bekomme wieder negative Werte.
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1
FD 20
FUUID 60104d9e-f33f-c37e-31d8-2f948e9886b6d240
MeterType SML
NAME Stromzaehler
NEXT 2021-04-08 19:06:50
NR 64
PARTIAL
STATE 2004.32 W
TYPE OBIS
READINGS:
2021-03-12 16:35:57 0.118.5.133.160.255 0
2021-03-11 23:26:02 0.118.5.37.214.255 0
2021-04-04 01:36:33 117.119.7.1.0.255 0
2021-04-08 19:06:40 Aktuelle_Leistung 2004.32 W
2021-04-08 19:06:40 Aktuelle_Leistung_Gleitendermittelwert_proMinute 1263.799 W
2021-04-08 19:06:40 Bezug 9086.7375 kWh
2021-04-08 19:06:40 Einspeisung 49.9769 kWh
2021-04-08 19:06:40 ManufID2 DZG*var
2021-04-08 19:06:40 power 2004.32
2021-04-07 23:06:28 state opened
2021-04-08 19:06:40 total_consumption 9086737.5
2021-04-08 19:06:40 total_feed 49976.9
helper:
BUFFER
EoM 1
LastPacketTime 1617901600.7979
SPEED 5
SPEED2 5
TRIGGERTIME 1617901610
Channels:
DEVICES:
10
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:96.50.1*1 ManufID2
directions:
Attributes:
alignTime 00:00
icon measure_power_meter
interval 10
pollingMode on
stateFormat {ReadingsVal($name,"power",0)." W"}
unitReadings off
userReadings Bezug {ReadingsNum("Stromzaehler","total_consumption",0)/1000 ." kWh"},
Einspeisung {ReadingsNum("Stromzaehler","total_feed",0)/1000 ." kWh"},
Aktuelle_Leistung {ReadingsNum("Stromzaehler","power",0)/1 ." W"},
Aktuelle_Leistung_Gleitendermittelwert_proMinute {movingAverage("Stromzaehler","power",60)/1 ." W"}
verbose 3
Gruß Domenik
Pfui... Dabei habe ich extra beim Rewrite des Parsers versucht, den Fall abzuhandeln.
Kannst Du bitte kurz auf "verbose 5" gehen und mir 3-4 "OBIS: Full message->"-Zeilen aus dem Logfile schicken? Pmail oder hier im Forum... Natürlich brauche ich die Fälle mit falsch-negativen Zahlen.
Zitat von: gvzdus am 08 April 2021, 19:50:40
Pfui... Dabei habe ich extra beim Rewrite des Parsers versucht, den Fall abzuhandeln.
Kannst Du bitte kurz auf "verbose 5" gehen und mir 3-4 "OBIS: Full message->"-Zeilen aus dem Logfile schicken? Pmail oder hier im Forum... Natürlich brauche ich die Fälle mit falsch-negativen Zahlen.
2021.04.08 19:52:20 5: SW:
2021.04.08 19:52:20 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:52:30
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176057A57E70D620062007263010176010102310B0A01445A4700035687207262016504B2BDF5620263E9870076057B57E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BDF57577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6C30177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F6C201010163BA8F0076057C57E70D6200620072630201710163E2F20000001B1B1B1B1A02EAC4
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176057A57E70D620062007263010176010102310B0A01445A4700035687207262016504B2BDF5620263E9870076057B57E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BDF57577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6C30177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F6C201010163BA8F0076057C57E70D6200620072630201710163E2F20000001B1B1B1B1A02EAC4
2021.04.08 19:52:20 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088377.9*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-23.66*W)
!
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088377.9*Wh)
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088377.9*Wh) is of type Counter
2021.04.08 19:52:20 4: OBIS (Stromzaehler) - Set total_consumption to 9088377.9
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-23.66*W)
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-23.66*W) is of type Channels
2021.04.08 19:52:20 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:52:21 1: RMDIR: /opt/fhem/restoreDir/save/2021-03-11
2021.04.08 19:52:30 5: SW:
2021.04.08 19:52:30 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:52:30 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:52:40
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176059857E70D620062007263010176010102310B0A01445A4700035687207262016504B2BDFF620263EB680076059957E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BDFF7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6D50177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F73501010163701D0076059A57E70D6200620072630201710163819C0000001B1B1B1B1A020486
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176059857E70D620062007263010176010102310B0A01445A4700035687207262016504B2BDFF620263EB680076059957E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BDFF7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6D50177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F73501010163701D0076059A57E70D6200620072630201710163819C0000001B1B1B1B1A020486
2021.04.08 19:52:31 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088379.7*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-22.51*W)
!
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088379.7*Wh)
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088379.7*Wh) is of type Counter
2021.04.08 19:52:31 4: OBIS (Stromzaehler) - Set total_consumption to 9088379.7
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-22.51*W)
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-22.51*W) is of type Channels
2021.04.08 19:52:31 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:52:40 5: SW:
2021.04.08 19:52:40 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:52:40 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:52:50
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605B657E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE0A6202637C90007605B757E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE0A7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6E70177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53FAF0010101636313007605B857E70D6200620072630201710163EAC40000001B1B1B1B1A02C415
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B010101017605B657E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE0A6202637C90007605B757E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE0A7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6E70177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53FAF0010101636313007605B857E70D6200620072630201710163EAC40000001B1B1B1B1A02C415
2021.04.08 19:52:41 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088381.5*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-12.96*W)
!
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088381.5*Wh)
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088381.5*Wh) is of type Counter
2021.04.08 19:52:41 4: OBIS (Stromzaehler) - Set total_consumption to 9088381.5
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-12.96*W)
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-12.96*W) is of type Channels
2021.04.08 19:52:41 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:52:50 5: SW:
2021.04.08 19:52:50 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:53:00
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605D157E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE1362026362DD007605D257E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE137577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6F70177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F78E010101631B39007605D357E70D6200620072630201710163674E0000001B1B1B1B1A02B1D2
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B010101017605D157E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE1362026362DD007605D257E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE137577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC6F70177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F78E010101631B39007605D357E70D6200620072630201710163674E0000001B1B1B1B1A02B1D2
2021.04.08 19:52:50 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088383.1*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-21.62*W)
!
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088383.1*Wh)
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088383.1*Wh) is of type Counter
2021.04.08 19:52:50 4: OBIS (Stromzaehler) - Set total_consumption to 9088383.1
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-21.62*W)
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-21.62*W) is of type Channels
2021.04.08 19:52:50 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:53:00 5: SW:
2021.04.08 19:53:00 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:53:10
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605EF57E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE1D6202638059007605F057E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE1D7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7090177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F69A010101632C13007605F157E70D62006200726302017101630C160000001B1B1B1B1A02C279
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B010101017605EF57E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE1D6202638059007605F057E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE1D7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7090177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53F69A010101632C13007605F157E70D62006200726302017101630C160000001B1B1B1B1A02C279
2021.04.08 19:53:00 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088384.9*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-24.06*W)
!
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088384.9*Wh)
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088384.9*Wh) is of type Counter
2021.04.08 19:53:00 4: OBIS (Stromzaehler) - Set total_consumption to 9088384.9
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-24.06*W)
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-24.06*W) is of type Channels
2021.04.08 19:53:00 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:53:10 5: SW:
2021.04.08 19:53:10 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:53:20
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176050D58E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE276202632FF50076050E58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE277577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7180177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53D826010101636D7A0076050F58E70D6200620072630201710163F0740000001B1B1B1B1A024ADF
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176050D58E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE276202632FF50076050E58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE277577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7180177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53D826010101636D7A0076050F58E70D6200620072630201710163F0740000001B1B1B1B1A024ADF
2021.04.08 19:53:10 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088386.4*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-102.02*W)
!
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088386.4*Wh)
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088386.4*Wh) is of type Counter
2021.04.08 19:53:10 4: OBIS (Stromzaehler) - Set total_consumption to 9088386.4
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-102.02*W)
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-102.02*W) is of type Channels
2021.04.08 19:53:10 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:53:20 5: SW:
2021.04.08 19:53:20 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:53:30
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176052B58E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE31620263A5B00076052C58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE317577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7280177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53E08101010163BBEF0076052D58E70D62006200726302017101639B2C0000001B1B1B1B1A024753
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176052B58E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE31620263A5B00076052C58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE317577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7280177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53E08101010163BBEF0076052D58E70D62006200726302017101639B2C0000001B1B1B1B1A024753
2021.04.08 19:53:20 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088388*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-80.63*W)
!
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088388*Wh)
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088388*Wh) is of type Counter
2021.04.08 19:53:20 4: OBIS (Stromzaehler) - Set total_consumption to 9088388
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-80.63*W)
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-80.63*W) is of type Channels
2021.04.08 19:53:20 5: OBIS (Stromzaehler) - Msg-Parse: !
2021.04.08 19:53:30 5: SW:
2021.04.08 19:53:30 4: OBIS (Stromzaehler) - Wrote
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Internal timer set to 2021-04-08 19:53:40
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176054958E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE3B62026380860076054A58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE3B7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7390177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53E3D0010101637EE20076054B58E70D620062007263020171016326C40000001B1B1B1B1A02364E
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176054958E70D620062007263010176010102310B0A01445A4700035687207262016504B2BE3B62026380860076054A58E70D620062007263070177010B0A01445A470003568720070100620AFFFF7262016504B2BE3B7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700035687200177070100010800FF641C01047262016200621E52FF65056AC7390177070100020800FF017262016200621E52FF6407A0390177070100100700FF017262016200621B52FE53E3D0010101637EE20076054B58E70D620062007263020171016326C40000001B1B1B1B1A02364E
2021.04.08 19:53:30 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZGV *var)
1-0:1.8.0*255(9088389.7*Wh)
1-0:2.8.0*255(49976.9*Wh)
1-0:16.7.0*255(-72.16*W)
!
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: /
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGV *var)
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(9088389.7*Wh)
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(9088389.7*Wh) is of type Counter
2021.04.08 19:53:30 4: OBIS (Stromzaehler) - Set total_consumption to 9088389.7
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(49976.9*Wh)
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(49976.9*Wh) is of type Counter
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-72.16*W)
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(-72.16*W) is of type Channels
2021.04.08 19:53:30 5: OBIS (Stromzaehler) - Msg-Parse: !
Herrje, kann man sich verhauen!
Bitte probiere mal diese Version aus!
Zitat von: gvzdus am 08 April 2021, 21:07:57
Herrje, kann man sich verhauen!
Bitte probiere mal diese Version aus!
Danke erstmal.
Es sieht so aus das es wieder Funktioniert.
Werde mich Morgen nochmal melden.
Ich bekomme aber noch folgende Sachen im Log:
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=257 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=2 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=26583 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1793 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1835268 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:00 1: OBIS - DZG: num=499769 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=27 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=254 subme=256
2021.04.08 21:37:00 1: OBIS - DZG: num=98589 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=11386 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=513 subme=0
2021.04.08 21:37:00 1: OBIS - DZG: num=31703 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=257 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=2 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=60805 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1793 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1835268 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:10 1: OBIS - DZG: num=499769 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=27 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=254 subme=256
2021.04.08 21:37:10 1: OBIS - DZG: num=98776 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=19294 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=513 subme=0
2021.04.08 21:37:10 1: OBIS - DZG: num=43388 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=257 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=2 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=42821 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1793 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1835268 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:20 1: OBIS - DZG: num=499769 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=27 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=254 subme=256
2021.04.08 21:37:20 1: OBIS - DZG: num=99675 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=11724 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=513 subme=0
2021.04.08 21:37:20 1: OBIS - DZG: num=44391 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=257 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=2 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=30968 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1793 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1835268 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=30 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=255 subme=256
2021.04.08 21:37:31 1: OBIS - DZG: num=499769 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=1 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=27 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=254 subme=256
2021.04.08 21:37:31 1: OBIS - DZG: num=102143 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=58870 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=0 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=513 subme=0
2021.04.08 21:37:31 1: OBIS - DZG: num=52213 subme=0
Shit! Eine Logzeile nicht auskommentiert - ich wollte die Zeilen erst für das Release löschen.
Suche folgende Zeile 439:
Log3 $hash, 1, "OBIS - DZG: num=$num subme=$subme";
und pack' ein "#" davor oder lösche sie.
Wer heute updated, bekommt die oben genannte "DZI-Again-Version" (mit gelöschten Debug-Meldungen).
Ich kann nun bestätigen das die neue Version vom DZG Patch einwandfrei funktioniert.
Vielen Dank für die Mühe.
Gruß Domenik
Zitat von: gvzdus am 08 April 2021, 16:30:01
Bei solchen Fällen gucke ich bei den Kollegen von volkszaehler nach - die haben halt eine gute "Zählerdatenbank". Der EDL21 von EMH ist da als "Null problemo" drin:
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/edl21-ehz
Ich habe nichts weiter gefunden, was Dir helfen könnte, sorry. Daher würde ich an Deiner Stelle mit dem Messstellenbetreiber telefonieren. In der Hoffnung, dass Du da auf Kompetenz triffst (bei mir bei der NEW definitiv der Fall):
"Ich habe die PIN erfolgreich eingegeben, die 2. Zeile ist auch sichtbar, aber auf der OBIS-Schnittstelle kommen nur verkürzte Datensätze heraus".
Ich habe jedenfalls keine Infos gefunden, dass man noch einmal nach eingegebener PIN explizit "vollständiger Datensatz" in irgend einem Menu aktivieren könnte.
Danke für deine Info. Ich kam leider erst heute dazu mich um das Thema zu kümmern. Ich habe mal ein Bild vom Zähler gemacht. Hier sieht man auch die freigeschaltet Anzeige des "Power" Wertes.
Was mir noch auffällt, ist das die CRC Fehlerangabe im kontinuierlich nach oben zählt. Ich werde also auch mal die Verkabelung testen.
Dann hast Du die falsche Bedienungsleitung verlinkt.
Eine andere gute Quelle ist die Doku von powerfox:
https://poweropti.powerfox.energy/wp-content/uploads/2020/07/Whitelist-Z%C3%A4hler.pdf (https://poweropti.powerfox.energy/wp-content/uploads/2020/07/Whitelist-Z%C3%A4hler.pdf)
Hier findet sich zu Deinem Zähler:
Kunde muss selbstständig die Info-DDS freischalten.
Ich würde Dir aber vorschlagen, Deinem Messstellenbetreiber auf die Nerven zu gehen - ganz konkret mit den Fragen hier. Es ist hilfreich, wenn die Messstellenbetreiber mitbekommen, mit welchen Geräten es Ärger gibt. CRC-Fehler könnte auch falsche Baudrate / Parität sein, aber dann dürfte eigentlich eher gar nichts ankommen.
Zitat von: gvzdus am 11 April 2021, 14:57:39
Dann hast Du die falsche Bedienungsleitung verlinkt.
Eine andere gute Quelle ist die Doku von powerfox:
https://poweropti.powerfox.energy/wp-content/uploads/2020/07/Whitelist-Z%C3%A4hler.pdf (https://poweropti.powerfox.energy/wp-content/uploads/2020/07/Whitelist-Z%C3%A4hler.pdf)
Hier findet sich zu Deinem Zähler:
Kunde muss selbstständig die Info-DDS freischalten.
Ich würde Dir aber vorschlagen, Deinem Messstellenbetreiber auf die Nerven zu gehen - ganz konkret mit den Fragen hier. Es ist hilfreich, wenn die Messstellenbetreiber mitbekommen, mit welchen Geräten es Ärger gibt. CRC-Fehler könnte auch falsche Baudrate / Parität sein, aber dann dürfte eigentlich eher gar nichts ankommen.
DANKE. Toll ist, das ich die Beschreibung / Link vom Betreiber bekommen habe. Ich werde nun mal weiter suchen. Danke für die Hilfe.
Hallo zusammen,
ich habe auf meinem PI 2 Model B Raspberry Pi 3 Model B Rev 1.2 mit FHEM das OBIS Modul installiert und möchte meinen Stromzähler Easymeter Q3A auslesen
DEF /dev/ttyAMA0@9600,7,E,1
DeviceName /dev/ttyAMA0@9600,7,E,1
FD 10
FUUID 60733fb4-f33f-0f40-537b-51088226c3fea2fa
MeterType Unknown
NAME Stromzaehler
NR 339
PARTIAL
STATE opened
TYPE OBIS
Readings
state opened 2021-04-11 20:56:52
verbose habe ich auf 5 gestellt
jedoch können es noch viele Fehlerquellen sein :-(
a) am Zähler wurde noch nicht mit einer PIN freigeschaltet
b) Der Schreib Leskopf Hitchi wurde per TTY an
3,3 V PIN 1
GND PIN 6
GPIO14 TX PIN 8
GPIO15 RX PIN 10
angeschlossen, das ganze habe ich über ein 10m Patchkabel mit dem Raspberry verbunden
c) Der Zähler hat kein Metall, d.h. den Kopf habe ich mit Klebeband befestigt (schön passt dieser nicht auf den Zähler)
d) Leskopf richtig rum? Kabel steht nach vorn (nicht zur Zählerbefestigung)
IR Diode Zähler ist mit HandyKamera sichtbar, vom Lesekopf kurz beim Boot vom Raspberrry
Wo beginnt man am besten?
Grüße
fritzmeier
Zur Machbarkeit:
Die Kollegen von powerfox schreiben:
"Q3A geht, außer die Modellnummer endet mit einer 0"
Bei schnellem googlen komme ich eher auf 9600 8N1 als 8E1 für die serielle Schnittstelle.
PIN einzugeben und ggf. Schnittstelle auf geschwätzig stellen kann natürlich nicht schaden:
https://www.easymeter.com/downloads/products/zaehler/Q3A/Betriebsanleitung_Q3A.pdf
Die "Hardware" (Position richtig, Kabellänge, PINs) ist remote einerseits natürlich schwer zu debuggen, außerdem nicht so mein Thema.
Hi,
Raspberry = Raspberry Pi 3 Model B Rev 1.2
das mit der PIN kann lt. Energieversorger noch dauern > liegt noch nicht vor.
Jedoch sollten auch jetzt schon Werte kommen.
hab es mal so probiert
define Stromzaehler OBIS /dev/ttyAMA0@9600,8,N,1 SML
> auch nichts
Auf dem Lesekopf sehe ich mit der Kamera kein Licht am Zähler schon :-(
Kabel habe ich jetzt mal kürzer zum Testen > geht auch nicht (1m)
Kann der Lesekopf getestet werden?
@ Admin > besser eigenen Beitrag eröffnen?
Grüße
fritzmeier
Nunja, ich bin halt Software-Maintainer und wollte mich mit Hardware nie rumärgern - ich habe "USB fertig" gekauft. Insofern kann ich Dir da nicht wirklich weiterhelfen - ob Du mit einem eigenen Thread mehr Glück hast, weiß ich aber auch nicht.
Hi,
weiß nicht ob ich den seriellen Anschluß richtig anspreche
define Stromzaehler OBIS /dev/ttyS0@9600,8,N,1 SML
oder
define Stromzaehler OBIS /dev/ttyAMA0@9600,8,N,1 SML
sonstige Anpassungen:
pi@raspberrypi:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=PARTUUID=424abaaf-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
cat /boot/config.txt
....
enable_uart=1
dtoverlay=pi3-disable-bt
seit das ich dies hinzugefügt habe "dtoverlay=pi3-disable-bt" um Bluetooth zu deaktiviren, ist der Status "disconnected"
USB hätte ich auch genommen, aber wegen der Kabellänge dann seriell
aktiviert habe ich seriell wie hier https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
A7 Serial auf enabled setzen
Grüße
fritzmeier
console=serial0,115200 wirkt auf jeden Fall falsch.
/dev/ttyS0 ist wesentlich üblicher als AMA.
Das
Zitatconsole=serial0,115200
und das
ZitatGPIO14 TX PIN 8
GPIO15 RX PIN 10
kann jedenfalls in Kombination gar nicht gehen.
Mit console=serial0,115200 aktivierst du die serielle Konsole, damit kannst du den Raspberry an RX/TX über ein Terminal-Programm steuern.
Dadurch ist aber RX/TX auf für andere Programme nicht ansprechbar.
Das also auf jeden Fall wieder rausnehmen aus der config.txt
Brauchst du auch wirklich nur im Notfall bzw. zum Einrichten des Raspberry, falls du keinen SSH-Zugang und keine Tasta/Monitor angeschlossen hast.
Hi,
config.txt ist nur das aktiv
dtparam=audio=on
enable_uart=1
dtoverlay=pi3-miniuart-bt
force_turbo=1
pi@raspberrypi:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=424abaaf-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
so wie hier beschrieben https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
somit, wenn ich richtig verstehe ttyAMA0 = richtig
Internals:
CFGFN
DEF /dev/ttyAMA0@9600,8,N,1 SML
DeviceName /dev/ttyAMA0@9600,8,N,1
FD 11
FUUID 607494c8-f33f-0f40-83e6-7216606e06cae3a0
MeterType SML
NAME Stromzaehler
NR 347
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2021-04-12 20:43:20 state opened
trotzdem sehe ich mit der Handykamera keine LED auch ein test mit der Fernbedienung ohne Erfolg.
den Leskopf habe ich mal mit hterm und der Fernbedienung getestet, da kommt eine Antwort zurück.
Grüße
fritzmeier
Hi,
nochmal Sensor an den Stromzähler und siehe da
ManufID ESY 2021-04-13 12:24:21
PublicKey xxxxx 2021-04-13 12:24:21
Serial 11-22-33-44-55 2021-04-13 12:24:21
power 3725.02 2021-04-13 12:24:21
power_L1 1942.4 2021-04-13 12:24:21
power_L2 -582.15 2021-04-13 12:24:21
power_L3 2364.76 2021-04-13 12:24:21
state opened 2021-04-13 12:22:22
total_consumption 76696.1692 2021-04-13 12:24:21
total_consumption_Ch1 213.9585 2021-04-13 12:24:21
total_consumption_Ch2 76482.2107 2021-04-13 12:24:21
total_feed 196952.8848 2021-04-13 12:24:21
voltage_L1 238.2 2021-04-13 12:24:21
voltage_L2 235.9 2021-04-13 12:24:21
voltage_L3 232.8 2021-04-13 12:24:21
Besten Dank
Grüße
fritzmeier
Klasse! Und, für die Nachwelt? Eine Idee, woran es zum Schluss hing?
Hi,
ging mal kurz ohne Änderung, dann wieder nicht.
hab noch mal nachgelötet, denke kalte Lötstelle, beobachte ich noch...., aktuell kommen Daten an.
Trotzdem besten Dank!
Zum Aufbau: Patchkabel mit RJ45 Stecker an Sensor (Pin 3,4,5,6) verwendet > RJ45 Buchse im Zählerschrank > 10 m Verlegekabel > Parchfeld > Patchkabel zum Raspi
Wegen Zähler, da habe ich ein kleines Blech mit ganz wenig Silikon oben angeklebt. Das pass für den Sensor optimal :-), dann mit Magnet aufgelegt.
Problem habe ich noch wegen der vielen Einträge im DBLog.
Trotz event-min-interval 1800 und interval 1800 sind diese im Sekunden Takt
Grüße
fritzmeier
Wenn Du nur stündlich o.ä. Daten haben willst -> interval + pollMode setzen.
Wenn Du nur z.B. alle 20 Sekunden Daten haben willst -> event-aggregator
Hallo fritzmeier
Was gvzdus hier anmerkt wäre für die Nachwelt echt hilfreich ;)
Zitat von: gvzdus am 13 April 2021, 12:41:04
Klasse! Und, für die Nachwelt? Eine Idee, woran es zum Schluss hing?
und zwar weniger die Hardware als die Konfiguration des Raspi3 um das richtige serielle Interface anzusprechen.
...wobei Homematic User die "/dev/ttyAMA0" eventuell mit dem "HM-MOD-RPI-PCB " belegt haben :-\
Hi,
so:
define haus.stromzaehler OBIS /dev/ttyAMA0@9600,8,N,1 SML
attr haus.stromzaehler DbLogExclude power_L1,power_L2,power_L3
attr haus.stromzaehler alias Stromzähler
attr haus.stromzaehler event-on-change-reading .*
attr haus.stromzaehler interval 30
attr haus.stromzaehler pollingMode on
attr haus.stromzaehler room Zaehler
attr haus.stromzaehler stateFormat {"Einspeisung: ".sprintf("%.0f kWh", (ReadingsVal($name,"total_feed",0) / 1000) ) ." | Bezug: ".sprintf("%.0f kWh", (ReadingsVal($name,"total_consumption",0) / 1000) ) . " | aktuelle Leistung: ". sprintf("%.0f W", ReadingsVal($name,"power",0)). " | status: ".ReadingsVal($name,"state",0)}
Grüße
Fritzmeier
Hallo zusammen,
Kann es sein, dass seit einem der letzten Updates das Attribut Intervall nich mehr funktioniert?
Hatte das bisher auf 15 stehen und bekam alle 15 Sekunden einen Wert.
Nun bekomme ich auf einmal jede Sekunde einen Wert obwohl ich nichts geändert habe.
Vielen Dank und Grüße
Michael
Hast Du pollmode auf "on"?
Es war vorher inkonsistent, jetzt ist es konsistent:
Intervallpollen nur, wenn pollmode auf "on" ist *und* ein Interval gesetzt ist.
Hallo,
Top, das war's.
Vielen Dank und Grüße
Michael
Ich habe jetzt auch mal die aktuelle Version ausprobiert. Bisher hatte ich immer "interval=30" und "pollingMode=on". Beide Attribute habe ich gelöscht und event-aggregator wie folgt definiert "power:30:linear:mean,total_consumption:30:none:v,total_feed:30:none:v". Es gibt auch ein Event alle 30 Sekunden. Soweit so gut .... leider habe ich jetzt auf dem Bananpi immer ca. 60% CPU Last durch den FHEM-Perl-Prozess. Vor dem Update des Modules war er eigentlich immer im Idle. Meine Vermutung ist jetzt, dass das Parsen der Daten die ganze CPU-Zeit benötigt - es kommen ja ca. alle 2 Sekunden neue Daten rein.
Hat jemand eine Idee, ob man das reduzieren kann ? Braucht das Parsen wirklich so viel Zeit ?
Zur Not gehe auf jeden Fall wieder zurück. Der Parser ist brilliant und effizient geschrieben, sagt der Autor :-)
Im Ernst: Ich kann mir eigentlich nicht den Parser als Problem vorstellen, für wahrscheinlicher halte ich den Overhead des "Einsammelns" eines Paket. Du könntest versuchen, ob man irgendwie die Blockgröße beim Lesen vom seriellen Port erhöhen kann (ich weiß aber nicht wie). Bei meinem Raspi 3 ist die Load mit sekündlichem Updateinterval vielleicht um die 5-10%.
Hm - mit so einer Antwort hatte ich gerechnet. Werde mal (wenn Zeit vorhanden) ein leeres FHEM aufsetzen und nur den Zähler anlegen. Mal sehen, wie dann die CPU-Load aussieht.
Du könntest auch mal mit "strace" gucken, wie viele "reads" erfolgen.
Bei mir:
strace -p [pid von fhem] > log 2>&1
nach 10 Sekunden abgebrochen.
Dann log durchgeguckt, und festgestellt, dass die read-Zeilen auf FD 43 die vom OBIS-Zähler sind.
Davon habe ich 191 in den (etwa) 10 Sekunden. Es werden typischerweise 14-16 Bytes gelesen:
read(43, "\0\2\10\1\377\1\1b\36R\377Y\0\0", 4096) = 14
read(43, "\0\0\1\336\312\306\1w\7\1\0\2\10\2\377\1", 4096) = 16
read(43, "\1b\36R\377Y\0\0\0\0\0\0\0\0\1w", 4096) = 16
read(43, "\7\1\0\20\7\0\377\1\1b\33R\0U\0", 4096) = 15
Pi mal Daumen habe ich also knapp 20 Leseoperationen inkl. des großen FHEM-"select", bis der Parser "ran darf". Daher meine Vermutung, dass das Zusammenklauben und der Vollständigkeitscheck eher teuer sind, nicht das Parsen. Wenn Du bei Dir noch kleinere Pakete sehen solltest, wäre eben ein größerer Buffer vielleicht hilfreich.
ich schau mir das mal mit einem separaten Setup an.
Das sieht hier ganz übel aus
read(5, "\7", 255) = 1
read(5, "\1\0", 255) = 2
read(5, "`", 255) = 1
read(5, "Z", 255) = 1
read(5, "\2\1", 255) = 2
read(5, "\1", 255) = 1
read(5, "\1\1", 255) = 2
Hat jemand ne Idee, wie ich es schaffe, die Anzahl der Byte pro Read zu erhöhen ?
Hallo zusammen,
auch bei mir (Raspberry 4B mit 4GB RAM) ist die Systemlast in letzter Zeit deutlich auf ~60% gestiegen (hatte nach längerer Zeit mal wieder ein Update durchgeführt).
Vorher hatte ich die definition mit intervall 30 ohne das pollingMode Attribut.
Deaktiviere ich OBIS, geht die Systemlast auf idle zurück.
aktiviere ich das attr pollingmode, geht die Systemlast auf ~20% zurück, lösche ich beide Attribute (intervall und pollingmode), so steigt die Systemlast wieder auf ~60%.
Das attr event-aggregator sieht bei mir folgendermaßen aus:
power:30:linear:mean,power_L1:30:linear:mean,power_L2:30:linear:mean,power_L2:30:linear:mean,total_consumption:30:none:v
Wie bekomme ich die Systemlast wieder auf ein annehmbares Niveau runter?
Gruß
Alex
Ist es vielleicht bei Dir auch ein "Micro-Read" (Byteweise?).
Ich habe am Freitag (nach Deinem Posting) mein Raspian Buster und FHEM auf den letzten Stand gebracht. Obwohl meine CPU deutlich schwächer ist (Raspi 3B) und mein Stromzähler quasi sekündlich inkl. 3 Phasen raushaut, liege ich bei < 15% - mit riesiger Eventverarbeitungskette.
Guck' Dir bitte mal mein Posting vom 25.04. (gleiche Seite) an... Allerdings ist das Pimpen des Bufferings nicht mein Knowhow-Gebiet.
Sieht ganz so aus.
Wie bekomme ich das in den Griff?
read(10, "729.82924505*kWh)\r\n1-0:16.7.0*25"..., 255) = 39
read(41, "", 256) = 0
read(10, "3.2", 255) = 3
read(10, "6", 255) = 1
read(10, "*", 255) = 1
read(10, "W", 255) = 1
read(10, ")", 255) = 1
read(10, "\r", 255) = 1
read(10, "\n", 255) = 1
read(10, "1-", 255) = 2
read(10, "0", 255) = 1
read(10, ":", 255) = 1
read(10, "3", 255) = 1
read(10, "6", 255) = 1
read(10, ".", 255) = 1
read(10, "7", 255) = 1
read(10, ".", 255) = 1
read(10, "0", 255) = 1
read(10, "*", 255) = 1
read(10, "2", 255) = 1
Meine letzte Idee war ser2net zwischen zu schalten. Da kann man per dev-to-net-bufsize Option die Größe des Readpuffer bestimmen. Leider ist bei meiner Uraltdistro diese Option noch nicht verfügbar. Aber vielelicht ist das für Dich eine mögliche Lösung.
Ist für mich leider, zumindest im Moment ebenfalls keine Lösung da ich mich knapp 9000km von dem Zähler entfernt aufhalte ;-)
ser2net ist eine Software :-)
Läuft bei mir normalerweise statt der direkten /dev/... - Konfiguration in FHEM, weil ich so auch mit meinem Test-Raspi gleichzeitig den OBIS-Zähler auslesen kann (2 FHEM-Instanzen auf 2 Raspis, aber nur ein Lesekopf am ersten Raspi).
Zitat von: gvzdus am 10 Mai 2021, 16:31:33
Läuft bei mir normalerweise statt der direkten /dev/... - Konfiguration in FHEM, weil ich so auch mit meinem Test-Raspi gleichzeitig den OBIS-Zähler auslesen kann (2 FHEM-Instanzen auf 2 Raspis, aber nur ein Lesekopf am ersten Raspi).
Ach wusste gar nicht, dass man da mit mehreren Klienten gleichzeitig auf eine Serielle zugreifen kann.
Das geht nur mit neueren ser2net-Versionen, und es ist nicht superstabil, wenn man z.B. den Zweit-Raspi einfach ausschaltet statt sauber runterzufahren.
Meine Config:
20001:raw:0::/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0:9600 NONE 1STOPBIT 8DATABITS max-connections=3
(max-connections=3 ist das Zauberwort)
Das ser2net ein SW ist war mir schon klar, bin nur nicht auf die Idee gekommen es auf localhost zu nutzen, danke für den Hint.
Habe gerade umgestellt und werde beobachten.
Danke und Gruß
Alex
Eine kurze Rückmeldung, mit Ser2Net ist die Dauerbelastung auf rund 20% heruntergegangen.
Danke für den Schubs in die richtige Richtung!
Gruß
Alex
Hallo zusammen,
nutze einen Weidmann IR Kopf und habe das Modul eingerichtet. Status ist auch auf "opened" allerdings werden keine Readings erzeugt? Fehlt da noch etwas?
define MyObis OBIS /dev/ttyUSB0@9600,7,E,1 SML
In der Console des Pi kann ich mit
cat /dev/ttyUSB0 sehen, dass dort sekündlich irgendwelche Daten ankommen.
Hey "huhu",
ggf. das Device auf "verbose 5" stellen und hier ein paar Sekunden des FHEM-Logfiles hochladen!
Interessant sind die Zeilen mit "Full message", darauf kannst Du auch gerne filtern:
2021.07.02 16:55:06 5: OBIS (MT175) - Full message-> 1B1B1B1B01010101760503113ADC6200620072630101760101050105BE4A0B090149534B00047FE6A1010163725F00760503113ADD620062007263070177010B090149534B00047FE6A1070100620AFFFF7262016501B618987D77078181C78203FF010101010449534B0177070100000009FF010101010B090...001B1B1B1B1A00E51E
Viele Grüße, Georg
Hallo Georg,
da kommt zumindest schon mal eine Rückmeldung und die LED am IR Kopf leuchet :)
Aber was nun? Habe das Modul zwischenzeitlich auch nochmal geupdated, das war von 2017 (Testumgebung)
Die CRC Error waren vor dem Update noch nicht da.
Viele Grüße
Andreas
Moin,
welcher Zähler ist das? Er scheint ungültige CRCs zu erzeugen.
Die schmutzige Methode:
Im Modul 47_OBIS in Zeile 506 machst Du aus:
if (OBIS_CRC16($hash,$msg) == 1) {
ein
if (OBIS_CRC16($hash,$msg) >= 0) {
Vermutlich wirst Du dann Daten bekommen, bist aber nicht vor sporadischen Fehlern geschützt.
Ich könnte mal gucken, ob ich die CRC-Methode des Zählers implementiere - ich habe aber keine Lust, Deinen Screenshot abzutippen :-)
Daher wäre dafür nötig, dass Du es als Textdatei hochlädst.
Das ist der EBZ DD3 Zähler.
Ich hab dir die Zeilen mal als PM geschickt, ich weiß leider nicht ob dort die Zählernummer ggfs im String enthalten ist, muss ja dann nicht öffentlich sein ;)
Vielen Dank fürs nachschauen :)
Update: Ja, mit abgeschalteter CRC-Prüfung klappt es. Nein, "Huhu" scheint seinen Zähler noch nicht "freigeblinkt" zu haben. Ich habe die CRCs mit diversen Verfahren und Verkürzungen probiert - einen systematischen Fehler finde ich nicht (z.B. statt CRC16 nach X25 einen anderen Algorithmus verwendet, oder das letzte Byte weggelassen, oder die Startsequenz).
Kann ich bestätigen, mit abgeschalteter Prüfung sind folgende Readings da :)
total_consumption.127 13000 2021-07-03 10:24:43
total_consumption_Ch1.127 1000 2021-07-03 10:24:43
total_consumption_Ch2.127 12000 2021-07-03 10:24:43
total_feed.127 5000 2021-07-03 10:24:43
PIN ist angefordert, mal sehen wie es sich dann verhält.
Kann ich den USB-IR-Lesekopf über Cat nicht verlängern? Hatte ein USB2LAN und LAN2USB Adapter versucht, das hatte leider nicht funktioniert. Gibt es Leseköpfe, die ich über die GPIO des Pi nutzen könnte?
Oder könnte ich den vorhandenen USB über GPIO verwurschteln? Wie würde das DEF für das Device dann ausschauen?
Vielen DAnk!
Hallo zusammen,
ich komme nicht weiter und hoffe, ihr könnt mir einige Tipps geben. Die gefundenen Infos haben in Summe leider nicht zum Ziel geführt.
FHEM läuft auf einer Syno 918 im Docker Container, der Optokopf hängt am USB der Syno.
Per lsusb und dmesg sollte der Optopkopf unter /dev/bus/usb/001/005 adressierbar sein.
Also im Docker
"--device=/dev/bus/usb/001/005" ergänzt.
Define mit "/dev/bus/usb/001/005@9600".
Selbst wenn der Docker-Cotainer im Privileged Modus läuft, finde ich im Log den Eintrag
SmartMeter: Can't open /dev/bus/usb/001/005: Permission denied
STATE disconnected
Hat jemand die Konstellation aus Syno, Docker Container und dem Optokopf im Einsatz und kann mir einen Hinweis geben?
Vielen Dank vorab und schöne Grüße
Dirk
Hab die Lösung für meine 918+ nach langer Suche und diversen Tests gefunden.
Syno DSM bringt zwar die USB-Treiber mit, diese sind aber nicht aktiv.
dmesg | grep tty liefert dann nicht,,now attached to ttyUSB0".
Also zuerst die Treiber aktivieren (hält temporär bis zum Reboot):
sudo insmod /lib/modules/usbserial.ko
sudo insmod /lib/modules/ftdi_sio.ko
Erster Test:
Den Container mit privilegierten Rechten starten (kann in der Docker GUI eingestellt werden), dann kann im Container auch "/dev/ttyUSB=" gefunden werden.
Dazu in der Docker GUI auf Terminal und Erstellen klicken, dann bash Fenster mit
ls | grep ttyUSB*
Wenn das funktioniert, können wir einen Weg ohne die priviligierten Rechte nutzen.
Docker Container, Einstellungen exportieren (auf ein Syno-Verzeichnis)
Eintrag ,,"devices" : null," suchen und ersetzen durch
"devices" : [
{
"pathOnHost": "/dev/ttyUSB0",
"PathInContainer": "/dev/ttyUSB0",
"CgroupPermissions": "rwm"
}
],
Die Einstellungen importieren (falls Container identisch heisst, den bereits vorhandenen vorher umbenennen).
Jetzt noch die Aktivierung der Treiber permanent einrichten.
Dazu ein File anlegen (per vi z.B.)
sudo vi /usr/local/etc/rc.d/startup.sh
2 Zeilen im File eintragen
sudo insmod /lib/modules/usbserial.ko
sudo insmod /lib/modules/ftdi_sio.ko
Abschließend noch die Rechte entsprechend setzen
chmod 700 /usr/local/etc/rc.d/startup.sh
Ob dieser Weg dann auch noch im DSM 7 funktioniert, ist die Frage. Sicherheitshalber habe ich mir mal die beiden Treiber-Files kopiert....
Viel Erfolg
Dirk
Kann mir jemand die OBIS-Kennzahlen und Bezeichnungen für dem MT691 geben?
Sowas wie https://wiki.volkszaehler.org/software/obis#iskraemeco_mt175 (http://xn--hier%20fr%20den%20mt175-jpc) ?
Ich möchte ein Skript für meinen ESP8266 mit tasmota schreiben.
Was spricht jetzt gegen Trial & Error? Lese sie aus, und es wird ziemlich selbsterklärend sein. Sie sind ja auch im Prinzip standardisiert, nur leicht unterschiedlich implementiert. Im 47_OBIS-Modul ist das in OBIS_codes hinterlegt.
Zitat von: huhu am 03 Juli 2021, 10:28:13
Kann ich bestätigen, mit abgeschalteter Prüfung sind folgende Readings da :)
total_consumption.127 13000 2021-07-03 10:24:43
total_consumption_Ch1.127 1000 2021-07-03 10:24:43
total_consumption_Ch2.127 12000 2021-07-03 10:24:43
total_feed.127 5000 2021-07-03 10:24:43
PIN ist angefordert, mal sehen wie es sich dann verhält.
Kann ich den USB-IR-Lesekopf über Cat nicht verlängern? Hatte ein USB2LAN und LAN2USB Adapter versucht, das hatte leider nicht funktioniert. Gibt es Leseköpfe, die ich über die GPIO des Pi nutzen könnte?
Oder könnte ich den vorhandenen USB über GPIO verwurschteln? Wie würde das DEF für das Device dann ausschauen?
Vielen DAnk!
So, PIN ist da, erweiterte Info im Zähler auf ON.
Allerdings hatte ich mir jetzt andere Readings erhofft... Fehlt da noch etwas seitens FHEM?
Insbesondere aktueller Verbrauch und Gesamt KWH Bezug/Einspeisung suche ich.
Moin, schick' mir bitte einfach noch mal ein paar Rohdaten aus "verbose 5"-Betrieb. Hilfreich wäre auch, wenn Du mir sagst, wie der Zählerstand ungefähr ist.
Die ersten 4 Zahlen sind wahrscheinlich die Power-Werte, und zwar gesamt (16) und die 3 einzelnen Phasen.
total_feed ist eingespeiste kWh, total_consumption Netzbezug.
Mein Lieber, ich gebe zu: Du hast schon im ersten Posting Deinen Fehler beschrieben - und ich bin jetzt erst drüber gestolpert:
Also: 7,E,1 ist definitiv und 100% falsch. Wir reden hier von 8 bit, und diskutieren kann man nur über 8,N,0 oder 8,N,1 etc...
Kein Wunder, dass alle Checksummen fehlschlagen, wenn das 8. Bit immer 0 ist!
Danke!! Dann war ich ja schon auf dem richtigen Weg.. mittlerweile habe ich das device als
dev/ttyUSB0@9600,8,N,1 SML
angelegt. Zwischenzeitlich den Check wieder eingebaut, aber leider hat sich am Endergebnis nichts geändert
Sooooo funktioniert es nun, statt 8,N,1 habe ich mal 8,N,0 getestet!:
/dev/ttyUSB0@9600,8,N,0 SML
Power und die jeweiige Phase sind selbsterklärend, total_consumption wird der Gesamtbezug sein und total_feed die Einspeisung?
Was genau machen die Werte total_consumption_CH1 und 2?
Vielen Dank Georg!
Du hast 2 Tarife: Tag und Nacht o.ä., die zählt er als Ch1 und Ch2. Und leckomio: Die Summe passt sogar :-)
Ahh wieder was gelernt, ich denke mal, dass dieser schon bei Auslieferung zu Testzwecken drauf war, er hatte in Summe 2kwh in beide Richtungen :)
Letzte Frage, ich habe noch einen IR Kopf den ich über Serial nutzen könnte, also sprich die GPIOs vom Pi. Kann ich das Modul dafür verwenden oder müsste ich mir etwas anderes einfallen lassen?
Das sollte gehen, aber dafür suche bitte mal in der Historie per Google und Co. Ich selber habe das nicht am Laufen. Das Wissen, wie es allgemein mit Raspi und TTL-Lesekopf geht, könnte sich auch bei den Kollegen von Volkszähler oder anderen SmartHome-Systemen finden. Das OBIS-Modul erwartet halt einfach per TCP oder eben als echtes Serial-Device etwas, wo die Daten rauspurzeln
Danke, ich schaue es mir mal. Zumindest läuft es erstmal das ist schonmal Prima :)
Wie loggt ihr die Werte, insbesondere Power? Der Ferraris Zähler vorher hat nur bei einer Umdrehung geloggt, also mal mehr mal weniger.
Mit min-interval 180 würde er alle 3min den Wert loggen, damit wüde ich aber immer nur den aktuellen Stand sehen, schöner wäre es, wenn man den Durchschnittswert der letzten 3min als Wert loggen könnte..
Edit: Das geht mit einerm Userreading, hier beschrieben: https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen
Zitat von: gvzdus am 06 Juli 2021, 20:30:38
Das sollte gehen, aber dafür suche bitte mal in der Historie per Google und Co. Ich selber habe das nicht am Laufen. Das Wissen, wie es allgemein mit Raspi und TTL-Lesekopf geht, könnte sich auch bei den Kollegen von Volkszähler oder anderen SmartHome-Systemen finden. Das OBIS-Modul erwartet halt einfach per TCP oder eben als echtes Serial-Device etwas, wo die Daten rauspurzeln
Wer es braucht, es geht so:
1. 3,3V, Ground, und TX PIN10 auf Pi anstecken
2. sudo nano /boot/config.txt - settings hinzufügen
#Serielle Schnittstelle aktiveren und Bluetooth deaktivieren
enable_uart=1
dtoverlay=disable-bt
3. sudo-raspi-config - 5- P6 Serial - No - Yes -Reboot
4. cat /boot/cmdline.txt - muss so ausehen:
console=tty1 root=PARTUUID=738a4d67-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
5. Device in FHEM anlegen mit
define StromIR OBIS /dev/ttyAMA0@9600,8,N,0 SML
Hallo zusammen,
ich habe einen ISKRA MT175 in FHEM eingebunden, läuft auch sauber, PIN wurde gesetzt.
Am Zähler lassen sich kumulierte Verbrauchswerte anzeigen (per Druck auf den blauen Knopf), u.a. 1D, 7D (also gestern, letzte Woche).
Als Reading bekomme ich die Werte nicht. Gibt es eine Möglichkeit, diese auch per OBIS zu bekommen?
Danke Euch und schöne Grüße
Dirk
Hi Dirk, nein, die Summenwerte werden an der Schnittstelle nicht ausgegeben. Dafür muss man sich entweder etwas per Hand basteln oder man setzt Module wie "statistics" dafür ein.
Zitat von: gvzdus am 13 Juli 2021, 14:59:32
Hi Dirk, nein, die Summenwerte werden an der Schnittstelle nicht ausgegeben. Dafür muss man sich entweder etwas per Hand basteln oder man setzt Module wie "statistics" dafür ein.
Ok, Danke Dir für die Info, statistics hatte ich tatsächlich in dem Zusammenhang hier im Forum schon gefunden.
Dann fange ich mal an zu basteln :)
PS: Das Wiki sieht schon passend aus, Stichwort singularReadings
https://wiki.fhem.de/wiki/Statistics (https://wiki.fhem.de/wiki/Statistics)
Hi,
ich hab das Problem das die Daten aus dem Buffer nicht interpretiert werden.
Ich habe einen Hager EHZ361Z5 (Zweirichtungszaehler) und bin mittels Hichis IR TTL Kopf und einem ESP8266 mit ESP Easy anf fhem gekoppelt.
(Danke an Immi der mir soweit geholfen hat)
Laut Handbuch des Zaehlers funktioniert der bei 9600, 7, E, 1 im Plain Text Mode.
Bevor ich in fhem das Komando define Stromzaehler OBIS 192.168.xxx.xx:4321 Standard gegeben habe konnte ich noch pernc 192.168.xxx.xx 4321 |hexdump -v den verfuegbaren Datenstrom sehen
0000060 215 \n ▒ H A G 5 e H Z 0 ▒ 0 ▒ _ ▒
0000070 ▒ ▒ ▒ Z A ▒ 0 215 \n 215 \n ▒ - 0 : 0
0000080 . 0 . 0 ▒ ▒ 5 5 ( ▒ 9 ▒ ▒ 0 ▒ -
0000090 5 0 ▒ ▒ ▒ 5 3 ▒ 215 \n ▒ - 0 : ▒ .
00000a0 ▒ . ▒ ▒ ▒ 5 5 ( 0 ▒ 6 9 9 ▒ . 6
00000b0 5 6 ▒ ▒ 215 \n ▒ - 0 : ▒ . ▒ . ▒ ▒
00000c0 ▒ 5 5 ( 0 3 ▒ 9 ▒ 3 . 6 3 0 ▒ ▒
00000d0 215 \n ▒ - 0 : 9 6 . 5 . 5 ▒ ▒ 5 5
00000e0 ( ▒ 0 ▒ 215 \n 0 - 0 : 9 6 . ▒ . ▒
00000f0 5 5 ▒ ▒ 5 5 ( 0 0 0 0 ▒ 0 ▒ ▒ ▒
0000100 5 ▒ 215 \n ! 215 \n ▒ H A G 5 e H Z 0
0000110 ▒ 0 ▒ _ ▒ ▒ ▒ ▒ Z A ▒ 0 215 \n 215 \n
0000120 ▒ - 0 : 0 . 0 . 0 ▒ ▒ 5 5 ( ▒ 9
0000130 ▒ ▒ 0 ▒ - 5 0 ▒ ▒ ▒ 5 3 ▒ 215 \n ▒
0000140 - 0 : ▒ . ▒ . ▒ ▒ ▒ 5 5 ( 0 ▒ 6
0000150 9 9 ▒ . 6 5 6 ▒ ▒ 215 \n ▒ - 0 : ▒
0000160 . ▒ . ▒ ▒ ▒ 5 5 ( 0 3 ▒ 9 ▒ 3 .
0000170 6 3 0 9 ▒ 215 \n ▒ - 0 : 9 6 . 5 .
0000180 5 ▒ ▒ 5 5 ( ▒ ▒ ▒ 215 \n 0 - 0 : 9
0000190 6 . ▒ . ▒ 5 5 ▒ ▒ 5 5 ( 0 0 0 0
00001a0 ▒ 0 ▒ ▒ ▒ 5 ▒ 215 \n ! 215 \n ▒ H A G
00001b0 5 e H Z 0 ▒ 0 ▒ _ ▒ ▒ ▒ ▒ Z A ▒
00001c0 0 215 \n 215 \n ▒ - 0 : 0 . 0 . 0 ▒ ▒
00001d0 5 5 ( ▒ 9 ▒ ▒ 0 ▒ - 5 0 ▒ ▒ ▒ 5
00001e0 3 ▒ 215 \n ▒ - 0 : ▒ . ▒ . ▒ ▒ ▒ 5
00001f0 5 ( 0 ▒ 6 9 9 ▒ . 6 5 6 ▒ ▒ 215 \n
0000200 ▒ - 0 : ▒ . ▒ . ▒ ▒ ▒ 5 5 ( 0 3
0000210 ▒ 9 ▒ 3 . 6 3 0 9 ▒ 215 \n ▒ - 0 :
0000220 9 6 . 5 . 5 ▒ ▒ 5 5 ( ▒ 0 ▒ 215 \n
0000230 0 - 0 : 9 6 . ▒ . ▒ 5 5 ▒ ▒ 5 5
0000240 ( 0 0 0 0 ▒ 0 ▒ ▒ ▒ 5 ▒ 215 \n ! 215
Da man ja wohl nur eine Verbindung gleichzeitig haben kann geht das nach der fhem definition nicht mehr, ich sehe aber bei einem List Stromzaehler dies hier:
Internals:
CFGFN
DEF 192.168.xxx.xx:4321 Standard
DeviceName 192.168.xxx.xx:4321
FD 42
FUUID 61029b4f-f33f-845e-24be-b477093902cc1293
MeterType Standard
NAME Stromzaehler
NR 339
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2021-07-29 14:13:04 state opened
helper:
BUFFER ��55(0�699�.656���
�-0:�.�.���55(03�9��.5966��
�-0:96.5.5��55(����
0-0:96.�.�55��55(0000�0���5��
!�
�HAG5eHZ0�0�_��űZA�0�
�
�-0:0.0.0��55(�9��0�-50���53��
�-0:�.�.���55(0�699�.656���
�-0:�.�.���55(03�9��.59����
�-0:96.5.5��55(����
0-0:96.�.�55��55(0000�0���5��
!�
�HAG5eHZ0�0�_��űZA�0�
�
�-0:0.0.0��55(�9��0�-50���53��
�-0:�.�.���55(0�699�.656���
�-0:�.�.���55(03�9��.59����
�-0:96.5.5��55(����
0-0:96.�.�55��55(0000�0���5��
!�
�HAG5eHZ0�0�_��űZA�0�
�
�-0:0.0.0��55(�9��0�-50���53��
�-0:�.�.���55(0�699�.656���
�-0:�.�.���55(03�9��.59�5��
�-0:96.5.5��55(����
0-0:96.�.�55��55(0000�0���5��
!�
....gekuertzt......
EoM -1
NETDEV 1
SPEED 5
TRIGGERTIME 1627560783.94934
DEVICES:
-1
RULECACHE:
Attributes:
ignoreUnknown off
Ich habe bereits gelesen das mehrmaliges Modify helfen soll, klappt aber leider bei mir nicht.
Verbose 5 bringt auch leider so gut wie nichts:
2021.07.29 14:13:03 3: Opening Stromzaehler device 192.168.xxx.xx:4321
2021.07.29 14:13:04 3: OBIS (Stromzaehler) - Init done
2021.07.29 14:13:04 3: Stromzaehler device opened
2021.07.29 14:29:35 5: OBIS (Stromzaehler) - Opening device...
2021.07.29 14:29:35 3: Opening Stromzaehler device 192.168.xxx.xx:4321
2021.07.29 14:29:35 5: HttpUtils url=http://192.168.xxx.xx:4321/ NonBlocking via http
2021.07.29 14:29:35 4: IP: 192.168.xxx.xx -> 192.168.xxx.xx
2021.07.29 14:29:35 3: OBIS (Stromzaehler) - Init done
2021.07.29 14:29:35 3: Stromzaehler device opened
Alle updates in fhem sind gemacht.
Was kann ich tun?
Danke schon mal fuer Eure Hilfe
Für mich sieht der Hexdump schräg aus. Ich habe mich bisher nur mit dem binär kodierten Zählern rumgeärgert, aber bei denen, die Plain SML liefern, müsste das m.E. völlig normal lesbarer Text sein.
Daher würde ich vorschlagen, mit den seriellen Parametern (7E1 aktuell bei Dir, 8N1 und 8N0 wäre m.E. mal einen Versuch wert) mal zu spielen, ob es lesbarer wird.
Ich habe sonst noch gefunden, dass jemand mal ein eigenes Modul für den Zähler geschrieben hat: https://forum.fhem.de/index.php/topic,14117.90.html
Danke gvzdus fuer deine Einschaetzung.
Das Datenblatt sagt zu dem Zaehler:
ZitatKommunikation
eHZ-Datentelegramme können mittels eines optischen Auslesekopfs nach DIN EN 62056-21 über die serielle Schnittstelle eines PC ausgelesen werden. Erforderlich ist ein Programm zur Darstellung serieller Daten, z.B. Windows »Hyperterminal« (hypertrm.exe). Einstellung: 9600 bd, Datenbit = 7, Parität = gerade, Stoppbits = 1, Flusssteuerung = kein. Im Fall des SML-Datentelegramms ist zur Interpretation der Daten ein Parser erforderlich und die Einstellung ist: 9600 bd, Datenbit = 8, Parität = kein, Stoppbits = 1, Flusssteuerung = kein.
habe auch beides erfolglose probiert also mit Standard (7,E,1) als auch mit SML (8,N,1)
8,N,0 wir leider nicht am ESP Easy angeboten.
Ich hab nun auch mal das Kabel am Lesekopf getauscht und ein abgeschirmetes genommen, allerdings auch ohne Erfolg. :'(
Hi,
ich habe herausgefunden das es konstant !! nur einige Zeichen sind!!, die falsch gelesen werden.
Die Zeichen H, A, G, e, Z, 9, 5, 0 werden immer richtig gelesen aber die Zeichen 1,2 immer falsch.
die 1 sollte Hex 31 sein, es kommt aber Hex immer b1 an.
Binaer waere richtig 0011 0001, es kommt aber 1011 0001.
Bei der 5 klappts aber immer richtig 0011 0101.
Soweit so klar, aber warum? und was kann ich dagegen tun?
Zitat von: Heiner am 30 Juli 2021, 11:44:16
Soweit so klar, aber warum? und was kann ich dagegen tun?
You went very far with "0011 0001 vs 1011 0001"
With an oscilloscope, you could debug it quite easily and implement one of the following options
- use a esp32 with harware serial
- different pin on esp8266 for softserial
- small pull-down to gnd (additional high resistance to gnd) at the pin of the esp8266
- schmitt trigger to clean up the signal before the pin of the esp8266
- add some capacitors to make more stable the voltage supply of the esp and of the IR-converter
Hi Immi,
initialy I thought of the noise as per your adivse but even the shielded cable did not help. I tried as well various Pins on the 8266, even went back to try HW Serial....
But as I almost constantly See that the same charactars get read accuratly, this can not be noise. In the entire log always the same figures get read but the character "1" and "2" never !!!
I will try next a ESP32, just in case the 8266 is broken and generate somehow always this same problem. I keep you posted.
Bist Du jetzt auf 7E1 oder 8N1? Bei 7E1 sollte ja gar kein "Bit 7" gesetzt sein können!
Hi,
i have only trouble with ESP Easy :-[
Whilst I was able to flash it on 8266 and code ser2net - it prodcued errors.
My brand new ESP32 I am unable to flash.
I tried then Tasmota and got via HWSerial and MQTT the exact clean Code transmitted which is wanted:
19:03:48.540 MQT: tasmota/RESULT = {"SSerialReceived":"/HAG5eHZ01xx_RWE1ZAxx"}
19:03:48.575 MQT: tasmota/RESULT = {"SSerialReceived":"1-0:0.0.0*255(797802-5011453)"}
19:03:48.605 MQT: tasmota/RESULT = {"SSerialReceived":"1-0:1.8.1*255(027028.4943)"}
19:03:48.633 MQT: tasmota/RESULT = {"SSerialReceived":"1-0:2.8.1*255(035059.7362)"}
19:03:48.654 MQT: tasmota/RESULT = {"SSerialReceived":"1-0:96.5.5*255(82)"}
19:03:48.686 MQT: tasmota/RESULT = {"SSerialReceived":"0-0:96.1.255*255(0000208xxx)"}
19:03:48.691 MQT: tasmota/RESULT = {"SSerialReceived":"!"}
unfortuniatly access only via MQTT and messages transmitted any second, this is too much trafic in the Network and too much information in the filelog.
However it shows the 8266 via HW Serial does recieve the right info and can forward it.
I strugle now to extract the MQTT into meaningfull readings as well as with the high traffic.
May be best to code something directly with Arduino, something more compact and hopefully working.
Does anyone has any further idea?
Many Thanks for helping
Okay, also das Fehlerproblem ist gelöst (bzw.: Ein Workaround da).
Filelog kann man abstellen.
Die Meßrate ist so hoch wie sie ist: Der Zähler wirft es eben in der Frequenz raus. Wenn Du weniger Daten haben möchtest, kannst Du das z.B. mit dem eventaggregator-Attribut erreichen.
Was ich Dir anbieten kann, ist, am Modul so zu schrauben, dass Du die MQTT-Events mit einem notify etc. in das OBIS-Modul reinwirfst und sie dort dekodiert werden. So etwas hatte ich schon mal vorbereitet.
Hi, das waere sicher eine super Sache.
Ich ba noch ein wenig weiter getestet.
In Tasmota bekomme ich auch nur den HW Serial so ans laufen nicht aber andere Pins ueber SoftwareSerial.
In ESPEasy bekomme ich nur ueber SoftwareSerial einen Fehlerhaften output aber nix ueber HW Serial.
Ich sollte so vermutlich bei Tasmota bleiben und die MQTT Daten versuchen zu verwerten.
Du sagst mit einem Notify (auf eingehende Message) also jede Sekunde, wird der MQTT Datensatz der im Reading SSerialRecieved ankommt interpretiert, richtig?
Oder kann man MQTT noch irgendwie so strukturieren das er 7 verschiedene Readings auswirft? Das hab ich leider nicht hinbekommen, würde aber helfen Events zu aggregieren.
Hi,
@GVZDUS bitte keinen Aufwand mehr in den MQTT import nach OBIS fuer mich stecken.
Ich habs final geschafft ( mit Web-Flasher meinen ESP32 mit ESP Easy zu flashen und mit HW Serial2 bekomme ich fehlerfreie Daten. Das Obis Device kanns lesen, alles funktioniert einwandfrei.
Puh, danke!
Hi,
Hi ich habe einen Stromzaehler erfolgreich per OBIS connected.
Leider zeigt dieser nicht die Momentanleistung sondern nur Zaehlerstaende
Das Statisitice modul kann mir leider nur das Stundenmittel liefern.
Ich versuche nun ueber min intervall 300 auf das 5 Minuten mittel zukommen das Multipliziert mit 12 die Durchschnittsleistung zeigen sollte.
Eigentlich sollte das hier klappen, liefert aber gar nichts, nicht mal einen Fehler.
power difference {ReadingsVal("Stromzaehler","total_consumption_Ch1",0)*12;;}
total_consumption_Ch1 liefert aber brav alle 5 minuten ein geaendertes Reading im Device Stromzaehler.
Was mach ich falsch, steht doch auch so im Hilfstext unter user Readings..... :-\
Danke fuer Eure Hilfe
Heiner
Moin, hast Du denn den Zähler entsperrt / die PIN "reingeblinkt"? Wie genau ist die "total_consumption"-Anzeige? Normalerweise geht sie bei den Geräten, die ich gesehen habe, auf 0,1 Wh (nicht: kWh) genau.
Mein Zaehler ist etwas aelter und hat noch keine PIN, auch der Betreiber hat mir das leider bestaetigt. Es gibt aber die IR Schnittstelle mit den Zaehlerstaenden, ist ein Zweirichtungszaehler. Der readingname ist der Verbrauch, das gleiche gibts noch als Einspeisung. Aber eben nur als Zaehlerstand, der wird sekuendlich mit vielen nachkommastellen uebermittelt
Entschuldige, dass etwas Zeit vergangen ist. Ich fühle mich auch nicht so zuständig als OBIS-Maintainer, weil es ja nicht um das Auslesen geht.
Ich selber bin Programmierer, deswegen nutze ich ungerne Module, die etwas Bestimmtes können, wenn ich das Gleiche auch mit ein paar Zeilen Code erschlagen kann.
Grundansatz:
3 "Devices":
a) Ein dummy-Device, dass die Werte "letzter Stand" und "Watt" aufnimmt
b) ein Filelog-Device, damit die Daten auf Platte landen
c) ein "at"-Job, der regelmäßig den Zähler ausliest.
Sieht dann so aus:
defmod power5min dummy
defmod FileLog_Verbrauch_5min FileLog ./log/stromverbrauch5min-%Y.log power5min
Und der Job:
defmod power5minjob at +*00:05:00 {\
my $power5min = $defs{"power5min"};;\
my $whneu=ReadingsVal("MT175","total_consumption","--");;\
my $whalt=ReadingsVal("power5min","kwh","--");;\
my $watt=$whalt>0 ? sprintf("%.1f", ($whneu-$whalt)*12) : 0;;\
my $fwhneu=ReadingsVal("MT175","total_feed","--");;\
my $fwhalt=ReadingsVal("power5min","kwhfeed","--");;\
my $fwatt=$fwhalt>0 ? sprintf("%.1f", ($fwhneu-$fwhalt)*12) : 0;;\
readingsBeginUpdate($power5min);;\
readingsBulkUpdate($power5min, "kwh", $whneu);;\
readingsBulkUpdate($power5min, "watt", $watt);;\
readingsBulkUpdate($power5min, "kwhfeed", $fwhneu);;\
readingsBulkUpdate($power5min, "wattfeed", $fwatt);;\
readingsEndUpdate($power5min, 1);;\
}
Wie unschwer zu erraten ist: "MT175" ist der Device-Name meines OBIS-Zählers. Auslesen werden "total_feed" und "total_consumption". Der Rest wird dann ausgerechnet.
OpenWBIch habe heute meine OpenWB-Wallbox angebunden, und es war ein Klacks. "Wir FHEMler" sparen uns ja mit dem OBIS-Lesekopf dann Technik, die anderswo 3-stellig kostet.
Die OpenWB möchte von Haus aus bis zu 3 Anbindungen haben:
- Der Netzübergang (vulgo: Zähler)
- Die PV-Erzeugung
- Die Daten eines Speichers
Wer das OBIS-Modul nutzt, hat das eigentlich flott konfiguriert. Der Netzübergang nennt sich "EVU-Modul" in der OpenWB-Welt. Man kann auch eine Lösung über MQTT wählen, ich habe mich aber für das generische HTTP-Modul entschieden.
Zunächst einmal muss man dafür einen Zugang zu FHEM ohne CSRF-Token konfigurieren, damit die OpenWB per HTTP abfragen kann. Das habe ich so gelöst:
defmod WEBopenwb FHEMWEB 8085 global
attr WEBopenwb allowfrom 192.168.0.106
attr WEBopenwb csrfToken none
Ich habe also auf Port 8085 einen weiteren Listener gestartet, der ohne csrfToken arbeitet, aber nur von der IP der OpenWB (hier: 192.168.0.106) erreichbar ist. Ich würde empfehlen, das "allowfrom" erst nach dem Testen zu setzen.
Die OpenWB möchte folgende Werte optimalerweise wissen:
- Watt-Bezug ("Momentanverbrauch", "power" normalerweise im OBIS-Modul)
- Wh-Bezug ("Zählerstand", "total_consumption" im OBIS-Modul)
- Wh-Einspeisung ("Zählerstand", "total_feed" im OBIS-Modul)
- Sowie die Ampere-Zahlen auf den Phasen (liefert mein Zähler nicht, aber er liefert Watt, also das 230-fache)
Falls Ihr also die Werte "power", "total_consumption", "total_feed" und vielleicht sogar "power_L1/L2/L3" habt, sieht eine vollständige URL-Tabelle so aus (meine FHEM-IP 192.168.0.3 natürlich geeignet ersetzen, und mein Zähler heißt als Device MT175):
Watt-Bezug:
http://192.168.0.3:8085/fhem?XHR=1&cmd=%7Bint(ReadingsVal(%22MT175%22,%22power%22,0))%7DWh-Bezug:
http://192.168.0.3:8085/fhem?XHR=1&cmd=%7Bint(ReadingsVal(%22MT175%22,%22total_consumption%22,0))%7DWh-Einspeisung:
http://192.168.0.3:8085/fhem?XHR=1&cmd=%7Bint(ReadingsVal(%22MT175%22,%22total_feed%22,0))%7DUnd bei den Phasen befindet sich noch die Division durch 230 (Volt) in der URL, um von Watt auf Ampere z kommen:
http://192.168.0.3:8085/fhem?XHR=1&cmd=%7Bint(ReadingsVal(%22MT175%22,%22power_L1%22,0)%2f230)%7DDas kann man, solange "allowfrom" noch nicht gesetzt ist, per curl von einer Shell aus testen:
curl "http://192.168.0.3:8085/fhem?XHR=1&cmd=%7Bint(ReadingsVal(%22MT175%22,%22power%22,0))%7D"
Es darf dann nur genau eine Zahl zurück kommen!
Ähnlich lässt sich auch ein an FHEM angebundener Wechselrichter auslesen - aber das führe ich hier jetzt nicht aus.
Hallo zusammen,
ich möchte mich an dieser Stelle für das Modul bedanken. Ich konnte erfolgreich meinen Stromzähler Itron OpenWay 3.HZ über die D0-Schnittstelle mit einem IR Schreib/Lesekopf USB (Optokopf) auslesen.
define ITR_Stromzaehler OBIS /dev/ttyUSB0@9600,8,N,1 SML
Im Anschluß wurden folgende Readings angelegt und im Sekundentakt abgefragt.
READINGS:
2021-08-26 10:33:03 ManufID2 ITR
2021-08-26 10:33:03 power 305
2021-08-26 10:31:23 state opened
2021-08-26 10:33:03 total_consumption 10012546.9
2021-08-26 10:33:03 total_feed 0
Nun zu meiner Frage: wenn ich am Zähler selber die Register mittels optischen Taster anschaue, zeigt der Zähler noch weitere Daten an. Werden diese nicht über die D0-Schnittstelle übermittelt?
Per Verbose 5 erhalte ich folgende Infos
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(10012583.1*Wh)
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg 1-0:1.8.0*255(10012583.1*Wh) is of type Counter
2021.08.26 10:39:58 4: OBIS (ITR_Stromzaehler) - Set total_consumption to 10012583.1
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg 1-0:2.8.0*255(0*Wh) is of type Counter
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(346*W)
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(346*W) is of type Channels
2021.08.26 10:39:58 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
2021.08.26 10:39:59 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF10040175DE63620062007265000001017601010900000000048D4EC00B0A01495452000349F04072620165048D4F1F01639FAE0076094AAF10040175DE646200620072650000070177010B0A01495452000349F040070100620AFFFF72620165048D4F1F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C050401621E52FF690000000005F7CC880177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000015A010101636DD20076094AAF10040175DE65620062007265000002017101636D3F0000001B1B1B1B1A02186F
2021.08.26 10:39:59 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF10040175DE63620062007265000001017601010900000000048D4EC00B0A01495452000349F04072620165048D4F1F01639FAE0076094AAF10040175DE646200620072650000070177010B0A01495452000349F040070100620AFFFF72620165048D4F1F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C050401621E52FF690000000005F7CC880177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000015A010101636DD20076094AAF10040175DE65620062007265000002017101636D3F0000001B1B1B1B1A02186F
2021.08.26 10:39:59 4: OBIS (ITR_Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(10012583.2*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(346*W)
!
Danke und Gruß
Ingo
Moin, falls Du Statistikwerte meinst: Nein, i.d.R: nicht. Du siehst ja auch schon im Decode: Da kommt nicht mehr rüber.
Wenn die Zahlen Dir wichtig sind, guck' Dir mal den Thread an:
https://forum.fhem.de/index.php?topic=69097.0
Danke, dann passt das. Bei anderen Beispielen habe ich gesehen das z.B. die einzelnen Phasen geliefert werden
Das Modul ElectricityCalculator habe ich bereits im Einsatz für den Zähler.
Hallo FHEM Gemeinde,
auch ich möchte mich für die geleistete Arbeit bedanken.
Meine Zähler vom Typ Holley DTZ541 in der Version BDBA lässt sich grundsätzlich ohne Probleme auslesen. Pin ist eingegeben.
Unter Windows habe ich zwar das Problem, dass der USB Port nicht angesprochen wird, unter Linux funktioniert dies jedoch. Daher anderes Thema.
Mein Problem ist das fehlende Vorzeichen in der Momentanleistung. Auch Eingespeiste Werte werden positiv angezeigt.
Nun habe ich kontakt mit Holley aufgenommen und herausbekommen, das die Stromrichtung im Statuswort des Zählerstands im bit 11 steckt. (Grüne Stelle, siehe auch Statuswort Bilder)
77
070100010800FF
65001C0104
72
6201
6500111FD1
621E
52FF
650009522E
SML-Time: 13.01.1970 23:44:17
+A Zaehlerstand 1.8.0: 000061,0862 kWh
01
Ist diese Auswertung schon implementiert?
Wie bekomme ich negative Werte bei Einspeisung angezeigt?
Hier noch ein stück Log:
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: /
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: 1-0:96.50.1*1(HLY)
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg 1-0:96.50.1*1(HLY) is of type ManufID2
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: 1-0:96.1.0*255(
HLY
-)
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: 1-0:1.8.0*255(93005.7*Wh)
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg 1-0:1.8.0*255(93005.7*Wh) is of type Counter
2021.09.01 15:20:19 4: OBIS (Zaehler_Hans) - Set total_consumption to 93005.7
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: 1-0:16.7.0*255(89*W)
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg 1-0:16.7.0*255(89*W) is of type Channels
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: 255-255:255.255.255*255()
2021.09.01 15:20:19 5: OBIS (Zaehler_Hans) - Msg-Parse: !
2021.09.01 15:20:20 5: OBIS (Zaehler_Hans) - SML-Parse 1B1B1B1B0101010176040000016200620072650000010176010107000000152F220B0A01484C5902000D2D977262016500152F220163E3AE007604000002620062007265000007017707FFFFFFFFFFFF0B0A01484C5902000D2D97070100620AFFFF7262016500152F227477070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000D2D970177070100010800FF65001D49047262016500152F22621E52FF65000E31090177070100100700FF0101621B5200525B0101016355BA00760400000362006200726500000201710163E82300001B1B1B1B1A014AE6
2021.09.01 15:20:20 5: OBIS (Zaehler_Hans) - Full message-> 1B1B1B1B0101010176040000016200620072650000010176010107000000152F220B0A01484C5902000D2D977262016500152F220163E3AE007604000002620062007265000007017707FFFFFFFFFFFF0B0A01484C5902000D2D97070100620AFFFF7262016500152F227477070100603201010101010104484C590177070100600100FF010101010B0A01484C5902000D2D970177070100010800FF65001D49047262016500152F22621E52FF65000E31090177070100100700FF0101621B5200525B0101016355BA00760400000362006200726500000201710163E82300001B1B1B1B1A014AE6
2021.09.01 15:20:20 4: OBIS (Zaehler_Hans) - MSG IS:
/
1-0:96.50.1*1(HLY)
1-0:96.1.0*255(
HLY
-)
1-0:1.8.0*255(93005.7*Wh)
1-0:16.7.0*255(91*W)
255-255:255.255.255*255()
Viele Grüße und schon mal Danke
Volker
Herzlichen Dank, wie gründlich Du das analysiert hast. Auch Holley hat da ja sehr fundiert geantwortet.
Zur Sache: Dieses Statuswort beim Zählerstand wird bisher weitgehend ignoriert. Im Code, den ich hoffentlich nicht verpfuscht habe, wird hier beim Wert 0xA2 beim Zählerstand ein "<" vorgehängt, bei 0x82 ein ">", was dann im weiteren ignoriert wird.
Angesichts der aktuellen Dunkelheit kann ich nicht nachvollziehen, ob mein ISKRA-Zähler hier auch die Richtung angibt. Dein Zähler scheint nach einer neueren Spezifikation bei diesem Status zu arbeiten - die Du ja netterweise gleich dazu gepackt hast.
Allerdings geben alle Zähler, die ich bisher kenne, trotzdem den Momentan-Wert mit Vorzeichen aus.
Anbei ist eine experimentelle Version, die unter den Bedingungen:
- Der Zähler meldet sich mit Manufacturer HLY...
- Bit 11 im Netz-Status ist 1, und die unteren 7 Bit sind 0x40
- Der Momentanwert ist positiv
den Wert negiert.
Schau' bitte mal, ob das für Dich funktioniert, ich checke morgen auf Seitenwirkungen bei meinem Zähler.
P.S. Bei meinem ISKRA funktioniert das geänderte Modul. Wenn es bei Dir den gewünschten Effekt bringt, checke ich es ein.
Hallo gvzdus,
vielen, vielen Dank für diese schnelle und für mich perfekte Lösung.
Genau so habe ich mir das vorgestellt.
Vielleicht hielft das ja auch noch dem Ein oder Anderen mit Holley Zähler weiter.
Mangels Programmierkönnen war an diesem Punkt der Recherche bei mir Ende.
Und auch stundenlanges Wälzen des Forums brachte mich keiner Lösung näher.
Viele Grüße aus dem heute zum Glück sonnigen Hessen
Volker
Funktioniert es denn? Hast Du jetzt negative Werte? Um 20 Uhr ja wohl eher nicht...
Ja, ich habe jetzt negative Werte, aber natürlich nicht um 20 Uhr. Ich kam nur nicht früher zum Antworten.
Okay, heute habe ich keine Lust mehr, aber morgen checke ich das dann ein. Sprich: Wenn Du übermorgen ein Update machst, ist die neue Version Bestandteil des "Standard-FHEMs".
Ist jetzt im SVN eingecheckt und dann ab morgen ca. 8 Uhr per "update" verfügbar.
Hallo gvzdus,
ich nutze seit kurzem auch deine tolle Arbeit um den Holley DTZ auszulesen. Bisher werden
die aktuelle Leistung (auch negativ bei Rückspeisung), der kummulierte Zählerstand und der kummulierte Zählerstand der Rückspeisung (-A) problemlos ausgelesen.
Mein Netzbetreiber stellt ca. 20 Werte (u.a. die Ströme auf den 3 Phasen) bereit. Hast du eine Idee, wie man an diese Daten kommt?
Hier mal als Beispiel der Auszug aus dem Logfile mit dem gegenwärtigen Device:
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: /
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 1-0:96.50.1*1(HLY)
2021.09.11 13:46:31 5: OBIS (PM1) - Msg 1-0:96.50.1*1(HLY) is of type ManufID2
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 1-0:96.1.0*255(
HLY
U)
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 1-0:1.8.0*255(>54213.1*Wh)
2021.09.11 13:46:31 5: OBIS (PM1) - Msg 1-0:1.8.0*255(>54213.1*Wh) is of type Counter
2021.09.11 13:46:31 4: OBIS (PM1) - Set total_consumption to 54213.1
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 1-0:2.8.0*255(6905.6*Wh)
2021.09.11 13:46:31 5: OBIS (PM1) - Msg 1-0:2.8.0*255(6905.6*Wh) is of type Counter
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 1-0:16.7.0*255(144*W)
2021.09.11 13:46:31 5: OBIS (PM1) - Msg 1-0:16.7.0*255(144*W) is of type Channels
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: 255-255:255.255.255*255()
2021.09.11 13:46:31 5: OBIS (PM1) - Msg-Parse: !
2021.09.11 13:46:32 5: OBIS (PM1) - SML-Parse 1B1B1B1B01010101xxxxx...xxxx1B1B1B1B1A01571C
2021.09.11 13:46:32 5: OBIS (PM1) - Full message-> 1B1B1B1B01010101xxxxx...xxxx1B1B1B1B1A01571C
2021.09.11 13:46:32 4: OBIS (PM1) - MSG IS:
/
1-0:96.50.1*1(HLY)
1-0:96.1.0*255(
HLY
U)
1-0:1.8.0*255(>54213.2*Wh)
1-0:2.8.0*255(6905.6*Wh)
1-0:16.7.0*255(147*W)
255-255:255.255.255*255()
!
Viele Grüße
Nico
Hi Nico,
ich habe mir mal die Mühe gemacht, Deinen Datensatz per Hand zu dekodieren, um zu gucken, ob da noch irgendwelche (relevanten) Informationen sind, die das Modul nicht erfasst. Wenn Du magst, kannst Du versuchen, es anhand der in Wikipedia unter "SML" verlinkten Doku nachzuvollziehen.
Der Bytestrom, der da geloggt wird, sind wirklich die Rohdaten vom Zähler. Und da steht drin, was unten steht. Wie Du siehst, hat das Protokoll zwar einen satten Satz an Overhead, aber es stehen eben nicht die Phasen-Infos drin. Wenn Du einen deutlich längeren Datensatz siehst, könnte das anders sein. Aber eigentlich ändern sich ja 3 Phasen schneller als die Summe der 3 Phasen - insofern bezweifele ich das.
Viele Grüße, Georg
1B1B1B1B Escape (Beginn)
01010101 Beginn SML V1
76
04000001 = TrxID
6200
6200
72
6500000101 = SML_PublicOpen.Res
76
01
01
070000000C20DE
0B0A01484C5902000D1B55
72
6201
65000C20DE
01
6357D8 = CRC
00 = EndOfSmlMsg
76
04000002 = TrxID
6200
6200
72
6500000701 = SML_GetList.Res
77
07FFFFFFFFFFFF = clientId
0B0A01484C5902000D1B55 = serverId
070100620AFFFF = listName
72 = actSensorTime
72 = actSensorTime
6201
65000C20DE
75 = valList (Jetzt geht's endlich los)
7707010060320101 0101010104484C5901 = 1-0:96.50.1*1(HLY)
77070100600100FF 010101010B0A01484C5902000D1B5501 = 1-0:96.1.0*255( HLY^MU)
77070100010800FF 65001C0104 726201 65000C20DE 621E52FF65000845B401 = 1-0:1.8.0*255(>54213.2*Wh)
77070100020800FF 0172620165000C20DE621E52FF6500010DC001 = 1-0:2.8.0*255(6905.6*Wh)
77070100100700FF 0101621B520053009301 = 1-0:16.7.0*255(147*W)
01
01
63C157 = CRC
00 = EndOfSmlMsg
76
04000003 = TrxID
6200
6200
72
6500000201 = SML_PublicClose.Res
71
01
63E823 = CRC
00 = EndOfSmlMsg
00 = Fuellbyte
1B1B1B1B = Escape (Ende)
1A = Ende der Nachricht
01571C = 1 Fuellbyte + CRC
Hi,
zunächst vielen Dank für das Modul. Funktioniert grundsätzlich auf Anhieb.
Allerdings habe ich eine Frage zur Handhabe des Moduls.
Ich habe einen efr Zähler (siehe Anleitung im Anhang).
Auf PDF-Seite 32 ist dort die optische Datenschnittstelle erläutert.
Diese Frage ich mit einem entsprechendem USB IR-Lesekopf ab. (https://www.ebay.de/itm/274962288487?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2648)
Laut Anleitung sollten aber deutlich mehr Readings zu lesen sein, als mir angezeigt wird. Siehe Bild im Anhang für vorhandene Readings in fhem.
Kriege ich auch irgendwie die anderen im Zähler vorhandenen Werte ausgelesen und als Reading dargestellt?
Die Pin ist eingegeben und die Abfrage des PIN im Zähler auf "off" gestellt.
Vielen Dank!
Bis denn
SouzA
Präzise Situationsbeschreibung, danke!
Guck doch mal im PDF auf Seite 26: "Reduzierter Datensatz versus voller Datensatz". Das erscheint mir ein unabhängiges Kriterium von "PIN eingegeben".
Zitat von: gvzdus am 14 Oktober 2021, 23:41:32
Präzise Situationsbeschreibung, danke!
War das jetzt gut oder böse gemeint? ???
Zitat von: gvzdus am 14 Oktober 2021, 23:41:32
Guck doch mal im PDF auf Seite 26: "Reduzierter Datensatz versus voller Datensatz". Das erscheint mir ein unabhängiges Kriterium von "PIN eingegeben".
Profis@its best! Das wars! Habe ich überlesen... ::)
Vielen Dank!
Thx und bis denn
SouzA
Nee, war positiv gemeint: PDF vom Hersteller dabei, Output klar: Konnte man runterlesen.
Zitat von: gvzdus am 14 Oktober 2021, 23:48:14
Nee, war positiv gemeint: PDF vom Hersteller dabei, Output klar: Konnte man runterlesen.
Dann is ja gut... ;)
Nochmals vielen Dank für das Modul und für die Hilfe!
Klasse Arbeit! :-* ;D
Bis denn
SouzA
Hallo,
ich hätte da noch einmal eine Frage.
Was bedeutet folgende Fehlermeldung:
2021.10.15 14:24:51 3: 2nd TL-byte != 0, reserved according spec
2021.10.15 14:24:51 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 713.
2021.10.15 14:25:21 3: 2nd TL-byte != 0, reserved according spec
Hab ich was falsch eingestellt?
Thx und bis denn
SouzA
Und noch eine Frage dazu:
Warum ist der Befehl für das update eigentlich ein get und nicht ein set?
Mit dem set hätte man vielleicht noch die Möglichkeit einen Button als webcmd zu basteln ;)
Dass entweder "ich" (bzw. Ur-Autor Stefan) oder der Hersteller die Spec nicht richtig gelesen hat :-)
Vorschlag: Schneide auf "verbose 5" die Rohdaten mit, bis der Fehler auftritt. Dann kann ich mal gucken... Die Rohdaten (also konkret nur das Beispiel drum rum) kannst Du mir auch per Privatnachricht schicken.
Zitat von: SouzA am 15 Oktober 2021, 14:28:05
Und noch eine Frage dazu:
Warum ist der Befehl für das update eigentlich ein get und nicht ein set?
Mit dem set hätte man vielleicht noch die Möglichkeit einen Button als webcmd zu basteln ;)
Du kannst doch ein WebCmd UPDATE setzen und dann ein Eventmap darauf legen oder ?
/get update:UPDATE/
Grüße
Christian
Zitat von: cs-online am 17 Oktober 2021, 18:04:47
Du kannst doch ein WebCmd UPDATE setzen und dann ein Eventmap darauf legen oder ?
/get update:UPDATE/
Grüße
Christian
Danke für den Tipp...
Allerdings bekomme ich dann die Fehlermeldung im Anhang.
Bis denn
SouzA
[UPDATE:]
Ich habe das unten beschriebene Problem nun doch selbst gelöst bekommen:
In der 47_OBIS.pm habe ich nach Zeile 601 eingefügt:
if ($hash->{MeterType} eq "MT382") {sleep(1)};
Außerdem habe ich nach Zeile 174 eingefügt:
"MT382" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
[Ursprüngliche Problembeschreibung:]
Ich bekomme seit einiger Zeit nur verstümmelte Antworten von meinem E-Zähler ISKRA MT382.
Das ganze liegt eber wohl nicht am Zähler oder am optischen USB-Interface, denn mit einem experimentellen 47_OBIS.pm, das mir Stefan Guttmann vor einiger Zeit zur Verfügung gestellt hatte, klappt die Kommunikation anscheinend. (Das Modul hat aber paar andere Macken, weshalb ich gern mit dem 'offiziellen' 47_OBIS.pm arbeiten möchte).
Mangels Perl-Kenntnissen komme ich leider nicht allein weiter und wäre für Hilfe dankbar.
Beste Grüße
Franz
Hier das device listing und ein log-Auszug bei Verwendung des offiziellen 47_OBIS.pm:
Internals:
CFGFN
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1
FD 29
FUUID 61792fe1-f33f-a50b-e07f-77fa04a29d60d90a
MeterType VSM102
NAME E_Zaehler
NR 1161
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2021-10-27 12:58:39 1.0.1.8.0 4468.88
2021-10-27 12:58:40 1.0.1.8.1 4468.88
2021-10-27 12:58:41 1.0.1.8.2 0
2021-10-27 12:58:42 1.0.1.8.3 0
2021-10-27 12:58:43 1.0.1.8.4 0
2021-10-27 12:58:44 1.0.2.8.0 1481.98
2021-10-27 12:55:35 Version ?!
2021-10-27 12:54:25 state opened
helper:
BUFFER
EoM 1
LastPacketTime 1635332324.31737
SPEED 0
SPEED2 0
TRIGGERTIME 1635332065.95239
Channels:
DEVICES:
/?!
150
000
RULECACHE:
1-0:1.8.0 unknown
1-0:1.8.1 unknown
1-0:1.8.2 unknown
1-0:1.8.3 unknown
1-0:1.8.4 unknown
1-0:2.8.0 unknown
Attributes:
interval 150
pollingMode on
room E,HWR,Haus
unitReadings off
verbose 5
und hier ein log-AUszug mit verbose=5:
2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Internal timer set to 2021-10-27 12:58:33
2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Msg-Parse: /?!
2021.10.27 12:56:03 5: DevIo_SimpleWrite E_Zaehler: 063030300d0a
2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Msg-Parse: 000
2021.10.27 12:56:09 5: OBIS (E_Zaehler) - Msg-Parse: -nU*%kE7Bk
Bk&$ jRJ2r
sB:;J*J
Jk&jRJ2r
s
C
#K*"5::J*J
Jk&jRJ:sJ:sBJk&kRrJr
C
+2Kk&kRrJrC ;Kk&kR
s:sB
s*J*R[W)
2021.10.27 12:56:09 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.0(004468.75*kWh)
2021.10.27 12:56:10 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.1(004468.75*kWh)
2021.10.27 12:56:11 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.2(000000.00*kWh)
2021.10.27 12:56:12 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.3(000000.00*kWh)
2021.10.27 12:56:13 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.4(000000.00*kWh)
2021.10.27 12:56:14 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:2.8.0(001481.98*kWh)
2021.10.27 12:56:14 5: OBIS (E_Zaehler) - Msg-Parse: !
Moin, ich habe mich jetzt etwas in den Code versenkt. Ich selber gehöre zu den Glücklichen mit einem Zähler, der ohne Initialisierung und insbesondere ohne 300/9600 Baud-Umschaltung fröhlich vor sich hin plappert...
An die Allgemeinheit:Gibt es jemanden, der 47_OBIS
- Mit Initialisierung
- Mit Speed-Umschaltung
nutzt?
Deine Zeile "602" kann ich nicht zuordnen. Ich hätte keine Probleme damit, die Definition "MT382" hinzuzunehmen - aber "sleep" ist wirklich megahäßlich in FHEM - da bleibt tatsächlich alles 1 Sekunde stehen. Selbst speziell für den MT382 würde ich das gerne verstehen. Du kannst auch einfach Deinen "kompletten" Code hier als Anhang ranhängen.
Zum MT382 finde ich keine (Detail)-Doku, aber für den MT171 beschreiben die Kollegen von volkszaehler.org, dass er eben von 300 Baud auf 9600 hochgeschaltet werden kann.
Noch eine Frage: Hast Du mal "interval" und "pollmode" entfernt und geguckt, wie sich der Zähler "im Dauerbetrieb" macht?
Moin, und danke für die Rückmeldung.
Zitat von: gvzdus am 28 Oktober 2021, 19:37:09
Deine Zeile "602" kann ich nicht zuordnen. Ich hätte keine Probleme damit, die Definition "MT382" hinzuzunehmen - aber "sleep" ist wirklich megahäßlich in FHEM - da bleibt tatsächlich alles 1 Sekunde stehen. Selbst speziell für den MT382 würde ich das gerne verstehen.
Dass sleep() irgendwie häßlich ist, ist mir auch klar. Auf die Idee, vor dem Senden des ACK noch etwas zu warten, war ich durch den Beitrag https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/iskraemeco_mt372 (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/iskraemeco_mt372) gekommen, in dem empfohlen wird, vor dem ACK diverse NUL characters zu senden (Ich hab vom MT372 fröhlich auf das MT382 verallgemeinert). Das mit den NUL's hab ich auch probiert, ging auch irgendwie, aber selbst bei acht NUL's noch nicht reproduzierbar. Da hab ich halt das brutale sleep() genommen. Habe auch versucht, mit usleep() die Zeit zu optimieren, es ging aber erst ab 900 msec, und deshalb habe ich dann gleich 1 sec genommen.
Zitat
Du kannst auch einfach Deinen "kompletten" Code hier als Anhang ranhängen.
Hängt an... (hab Änderungen mit alkazaa kommentiert)
Zitat
Zum MT382 finde ich keine (Detail)-Doku, aber für den MT171 beschreiben die Kollegen von volkszaehler.org, dass er eben von 300 Baud auf 9600 hochgeschaltet werden kann.
Manual des MT382 hänge ich ebenfalls an. Laut Angaben auf S. 83 sollte Baudumschaltung funktionieren.
Zitat
Noch eine Frage: Hast Du mal "interval" und "pollmode" entfernt und geguckt, wie sich der Zähler "im Dauerbetrieb" macht?
Werde ich testen und rückmelden.
Danke und beste Grüße
Franz
Moin, danke für die ausführlichen Rückmeldungen!
Okay, den Sinn verstehe ich jetzt. Ich kann das übernehmen, der Typ ist ja eh "Deine" Erfindung - insofern wird es niemanden stören, aber Dir helfen.
Da ich aber keine Chance habe, das "Ping-Pong" und die Umschaltung des Speeds zu testen, kann ich da nichts weiterentwickeln.
Mein Raspi / FHEM hat eine Fülle von Steueraufgaben, für mich wäre ein regelmäßiger 1-Sekunden-Freeze nicht akzeptabel - aber das kann ja bei Dir anders sein. Falls FHEM noch mehr bei Dir machen soll, würde ich über vzlogger und die MQTT-Anbindung nachdenken, insbesondere, falls ein "Nicht-Polling" bei Dir nicht funktioniert, also die Pause regelmäßig sein muss.
Moin!
Ich habe jetzt die unschöne Sache mit dem "sleep 1" wieder komplett entfernt. Es geht jetzt aber trotzdem (einigermaßen), weil ich die zusätzlichen NUL characters vor dem ACK (=chr(6)) in der device definitions-Tabelle wieder eingefügt habe. Dass das beim ersten Versuch nicht reproduzierbar ging, lag vielleicht daran, dass ich im Putty Terminal mit "tail -f /opt/fhem/log/fhem-2021-10.log" in Echtzeit die log Datei überwachen wollte.
(Das obige "einigermaßen" bezieht sich darauf, dass der als 1. response kommende Gerätetyp immer noch z.T. verstümmelt kommt. Aber der ist mir nicht wichtig.)
Also ist jetzt meine einzige Änderung an der 47_OBIS.pm die Zeile
"MT382" => ["/?!".chr(13).chr(10), 600, chr(0).chr(0).chr(0).chr(0).chr(0).chr(0).chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],#this line added by alkazaa in der "my %devs=..." Definitionstabelle. (Die Zeile kann man vielleicht eleganter schreiben...)
Zu Deiner Frage an die Allgemeinheit
Zitat von: gvzdus am 28 Oktober 2021, 19:37:09
An die Allgemeinheit:
Gibt es jemanden, der 47_OBIS
nutzt?
vermute ich, dass da wenig kommen wird: ich hab mal in diesem thread nach dem Stichwort 'umschaltung' gesucht, und dabei nur Teil-Diskussionen gefunden, die mehr oder weniger im Sande verliefen. Scheint also noch niemand wirklich zu nutzen.
Ich werde aber mal weiter rumprobieren...
Hi, ist so erst einmal eingecheckt, also ab morgen vormittag dann offiziell per Update.
Moin!
Ich schrieb:
Zitat von: alkazaa am 29 Oktober 2021, 17:03:30
Ich werde aber mal weiter rumprobieren... (an der Baudumschaltung)
Die gute Nachricht: ich habe es nun irgendwie hinbekommen.
Die weniger gute ist das irgendwie:
- ich habe nicht die 47_OBIS.pm aus dem SVN genommen, sondern eine per PN von Icinger erhaltene Experimentalversion (hänge ich hier nochmal an)
- auch mit der Version klappt die Umschaltung nur genau einmal, und zwar direkt nach dem define des Gerätes
- damit es regelmäßig funktioniert, habe ich als workaround ein at eingesetzt, das vor jedem get ein defmod durchführt (das hatte Icinger in Beitrag #907 dieses threads bereits erwähnt, es ist aber anscheinend nicht in der per PN gesendeten Version implementiert, daher das at)
- die vom Modul gelieferten readings heißen z.B. nicht 1.0.1.8.0, sondern 1.0:1.8.0 (der Doppelpunkt wird beim Start von FHEM angemeckert, es funktioniert aber trotzdem)
- interessanterweise ist das Senden mehrerer NUL characters vor den ACK nicht erforderlich!
- Langzeitstabilitätstest läuft noch
Die experimentelle Icinger-Version mit der aktuellen zusammenzuführen dürfte für mich mangels Perl Kenntnissen fast unmöglich sein, da die Struktur der beiden Versionen sehr unterschiedlich aussieht.
Aber vielleicht erbarmt sich jemand...
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@9600,7,E,1
FD 19
FUUID 617c6140-f33f-a50b-098c-eb709092f2f27ef3
MeterType VSM102
NAME E_Zaehler
NR 136
PARTIAL
STATE opened
TYPE OBIS
Helper:
DBLOG:
feed_280:
logdb:
TIME 1635587330.90736
VALUE 1488.11
feed_L1:
logdb:
TIME 1635587330.74844
VALUE 0.00
power:
logdb:
TIME 1635587330.74844
VALUE 1.813
power_2:
logdb:
TIME 1635587330.76355
VALUE 0.480000000010477
OLDREADINGS:
2021-10-30 11:46:20 1.0:1.8.0 4499.98
READINGS:
2021-10-30 11:48:50 0.0:96.1.1 3149534B30303737303935393133
2021-10-30 11:48:50 0.0:97.97.0 0
2021-10-30 11:48:50 1.0:0.9.1 114848
2021-10-30 11:48:50 1.0:0.9.2 211030
2021-10-30 11:48:50 1.0:1.8.0 4500
2021-10-30 11:48:50 1.0:1.8.1 4500
2021-10-30 11:48:50 1.0:1.8.2 0
2021-10-30 11:48:50 1.0:1.8.3 0
2021-10-30 11:48:50 1.0:1.8.4 0
2021-10-30 11:48:50 1.0:2.8.0 1488.11
2021-10-30 10:42:35 Version ISK
2021-10-30 11:48:50 feed_280 1488.11
2021-10-30 11:48:50 feed_L1 0.00
2021-10-30 11:48:50 power 1.813
2021-10-30 11:48:50 power_2 0.480000000010477
2021-10-30 11:48:50 state opened
helper:
BUFFER
DEV1 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1
DEV2 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@9600,7,E,1
EoM 1
SPEED 5
SPEED1 0
TRIGGERTIME 1635587329.10676
Channels:
DEVICES:
/?!
600
050
Attributes:
DbLogInclude (power|power_2|feed_280|feed_L1)
oldreadings .*1.8.0, .*2.8.0
pollingMode on
room E,HWR,Haus
unitReadings off
userReadings feed_L1:power.* {my $a=0.0; if (ReadingsVal("PVAnlage","AC_Power",0.0) > 0.0 and ReadingsVal($NAME,"power",0.01) <= 0.0) {$a = 3600.0 * (ReadingsVal($NAME,"1.0:2.8.0",0.0)-OldReadingsVal($NAME,"1.0:2.8.0",0.0))/(time -time_str2num(OldReadingsTimestamp($NAME,"1.0:2.8.0",0.0)))};
sprintf "%.2f", $a
},
power_2:1.0:1.8.0.* {3600.0 * (ReadingsVal($NAME,"1.0:1.8.0",0.0)-OldReadingsVal($NAME,"1.0:1.8.0",0.0))/(time -time_str2num(OldReadingsTimestamp($NAME,"1.0:1.8.0",0.0)))},
feed_280:1.0:2.8.0.* {ReadingsVal("E_Zaehler","1.0:2.8.0",0.0)}
verbose 3Internals:
COMMAND defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600 ; get E_Zaehler update
DEF +*00:02:30 defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600 ; get E_Zaehler update
FUUID 617d066a-f33f-a50b-6904-6191f256ebbc2a8d
NAME E_Zaehler_Read
NR 137
NTM 11:53:49
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 11:53:49
TIMESPEC 00:02:30
TRIGGERTIME 1635587629.09939
TRIGGERTIME_FMT 2021-10-30 11:53:49
TYPE at
READINGS:
2021-10-30 11:51:19 state Next: 11:53:49
Attributes:
disable 0
Moin!
Ich schrieb:
Zitat von: alkazaa am 29 Oktober 2021, 17:03:30
Ich werde aber mal weiter rumprobieren... (an der Baudumschaltung)
Zitat von: alkazaa am 30 Oktober 2021, 11:55:43
Die gute Nachricht: ich habe es nun irgendwie hinbekommen. Die weniger gute ist das irgendwie:
Das 'irgendwie' kann ich nun etwas genauer angeben:
- ich habe nicht die 47_OBIS.pm aus dem SVN genommen, sondern eine per PN von Icinger erhaltene Experimentalversion (hänge ich hier nochmal an)
auch mit der Version klappt die Umschaltung nur genau einmal, und zwar direkt nach dem define des Gerätes --> stimmt nicht, hab meinen Fehler gefundendamit es regelmäßig funktioniert, habe ich als workaround ein at eingesetzt, das vor jedem get ein defmod durchführt (das hatte Icinger in Beitrag #907 dieses threads bereits erwähnt, es ist aber anscheinend nicht in der per PN gesendeten Version implementiert, daher das at) --> ist natürlich nun nicht mehr nötig- die vom Modul gelieferten readings heißen z.B. nicht 1.0.1.8.0, sondern 1.0:1.8.0 (der Doppelpunkt wird beim Start von FHEM angemeckert, es funktioniert aber trotzdem)
- interessanterweise ist das Senden mehrerer NUL characters vor den ACK nicht erforderlich!
Langzeitstabilitätstest läuft noch --> scheint stabil zu laufen, wenn man nicht (wie ich zuletzt) ständig unterqualifiziert am source code herumfummelt- das attribut interval gibt es bei der Experimentalversion nicht; man muss es in der device-Definitionsliste im source code eintragen
Die SVN Version von 47_OBIS.pm kann die Speedumschaltung nicht, da dort eine subroutine speedchange() nicht definiert ist. In der Experimentalversion wird speedchange() zweimal in der subroutine Parse() aufgerufen.
Ich trau mir momentan noch nicht zu, die Versionen unfallfrei zusammenzuführen.
Des ist meine device Definition:
defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 MT382 9600Beste Grüße
Franz
Puh, da war Icinger aber weit weg von der Version, auf der ich gearbeitet habe!
Ich bin über ein paar Fragmente gestolpert, die wohl nie so recht funktioniert haben. In Deiner Version ergibt es Sinn. Ich habe mit einem Merge angefangen. Die Parametrisierung mit den Attributen "init1" und "init2" werde ich aber z.B. nicht unterstützen. Und: Da kommt viel Testing auf Dich zu, wenn Du dran bleiben möchtest :-)
Zitat von: gvzdus am 02 November 2021, 21:17:48
Puh, da war Icinger aber weit weg von der Version, auf der ich gearbeitet habe!....Ich habe mit einem Merge angefangen. ...Da kommt viel Testing auf Dich zu, wenn Du dran bleiben möchtest :-)
Super! und vielen Dank!
Und natürlich bleibe ich dran.
-Franz
[gelöst mit Patch aus folgender Nachricht] Vielen Dank für dieses wertvolle Modul, mit dem ich nun seit Monaten sowohl den Strombezug wie auch die Solar-Erzeugung logge. Allerdings spuckt mir die Solarerzeugung jetzt in der dunklen Jahreszeit ordentlich in meine Suppe der Eigenverbrauchsoptimierung. Bei Dunkelheit liefert die Solarmodule natürlich 0 W. Aber der Stringwechselrichter hat einen Eigenverbrauch und tankt alle paar Sekunden laut Display des digitalen Zählers kurzzeitig 3 W, dargestellt als -3W.
Im Reading Power würde ich nun -3 erwarten (oder 3W ohne Vorzeichen), nichts da: ich kriege irrsinnige 652.29 (manchmal .48)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: /
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:96.1.0*255(
DZG*var)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:1.8.0*255(>2939113.7*Wh)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:1.8.0*255(>2939113.7*Wh) is of type Counter
2021.11.11 17:39:25 4: OBIS (Solar) - Set total_consumption to 2939113.7
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:2.8.0*255(13314.4*Wh)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:2.8.0*255(13314.4*Wh) is of type Counter
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:16.7.0*255(0*W)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:16.7.0*255(0*W) is of type Channels
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: !
2021.11.11 17:39:26 5: OBIS (Solar) - SML-Parse 1B1B1B1B010101017605900C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FA620263BF79007605910C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FA7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FECD010101638B2D007605920C70086200620072630201710163B85B0000001B1B1B1B1A02B11E
2021.11.11 17:39:26 5: OBIS (Solar) - Full message-> 1B1B1B1B010101017605900C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FA620263BF79007605910C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FA7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FECD010101638B2D007605920C70086200620072630201710163B85B0000001B1B1B1B1A02B11E
2021.11.11 17:39:26 4: OBIS (Solar) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZG*var)
1-0:1.8.0*255(<2939113.7*Wh)
1-0:2.8.0*255(13314.4*Wh)
1-0:16.7.0*255(652.29*W)
!
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: /
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:96.1.0*255(
DZG*var)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:1.8.0*255(<2939113.7*Wh)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:1.8.0*255(<2939113.7*Wh) is of type Counter
2021.11.11 17:39:26 4: OBIS (Solar) - Set total_consumption to 2939113.7
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:2.8.0*255(13314.4*Wh)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:2.8.0*255(13314.4*Wh) is of type Counter
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:16.7.0*255(652.29*W)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:16.7.0*255(652.29*W) is of type Channels
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: !
2021.11.11 17:39:27 5: OBIS (Solar) - SML-Parse 1B1B1B1B010101017605930C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FB6202632AD4007605940C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FB7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FEBD010101635D5B007605950C700862006200726302017101633F2B0000001B1B1B1B1A020FC5
2021.11.11 17:39:27 5: OBIS (Solar) - Full message-> 1B1B1B1B010101017605930C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FB6202632AD4007605940C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FB7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FEBD010101635D5B007605950C700862006200726302017101633F2B0000001B1B1B1B1A020FC5
2021.11.11 17:39:27 4: OBIS (Solar) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZG*var)
1-0:1.8.0*255(<2939113.7*Wh)
1-0:2.8.0*255(13314.4*Wh)
1-0:16.7.0*255(652.13*W)
!
Was mache ich falsch/was läuft falsch? Hat jemand eine hilfreiche Idee?
Vielen Dank fürs Hirnen schon im Voraus!
Christian
Erstmal vorab: Ich habe es "per Hand" dekodiert:
Du findest die Sequenz in Deinem "Full-Message":
# We should have now an 7 element array: reading(0), status(1), valTime(2), unit(3), scaler(4), data(5)
070100100700FF = reading 1.0.16.7.0.255
01 = status
72 = valtime
6201
6200
621B = unit, 1B = Watt
52FE = scaler = -2
53FECD = data = 65229 in unsigned, -7 in signed => eigentlich -0,07 W
01
01
01
Wie Du siehst (oder nach dem Einlesen in das Kodieren nachvollziehen kannst): Eigentlich kommt super-sauber da -0,07 W raus aus der ersten Zeile. Nun gibt es aber einen ekeligen Bug in DZG-Zählern: Sie haben fälschlich unsigned als signed kodiert. Dafür gibt es im Code einen Hack, den DZG-Hack. Du findest ihn hier im Code:
if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) {
$tltype = 0x60;
}
Genau diese Stelle scheint sich bei Dir zu rächen: Weil es ein DZG-Zähler ist, der "signed" sagt, eine kurze Länge hat (< 4), es um das Werte-Feld und OBIS-Zahl 1.0.16.7.0 geht ("if"-Statement in Worten), macht der Code aus dem int ein unsigned int und damit die hohe Zahl.
Den Hack habe ich vor 1-2 Jahren eingebaut, findest Du früher hier im Thread. Vorschlag: Kommentiere diese 3 Zeilen mal aus, und gucke, ob Du damit definitiv glücklicher bist. (FHEM neu starten o.ä. ist natürlich nötig, damit das Auskommentieren oder Löschen wirksam wird). Sollte DZG Zähler in Umlauf gesetzt haben, die den Bug nicht mehr haben, dann würde ich den Hack nicht fest verdrahten, sondern "wegkonfigurierbar" machen.
Also: Schuld ist ein alter Fehler in den DZG-Zählern. Vielleicht ist er inzwischen behoben.
Zitat von: gvzdus am 11 November 2021, 21:48:51
Dafür gibt es im Code einen Hack, den DZG-Hack. Du findest ihn hier im Code:
if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) {
$tltype = 0x60;
}
Genau diese Stelle scheint sich bei Dir zu rächen: Weil es ein DZG-Zähler ist, der "signed" sagt, eine kurze Länge hat (< 4), es um das Werte-Feld und OBIS-Zahl 1.0.16.7.0 geht ("if"-Statement in Worten), macht der Code aus dem int ein unsigned int und damit die hohe Zahl.
Vielen Dank für diesen schnellen, kompetenten Hinweis: Funktioniert bei mir jetzt seit einer halben Stunde :-)
Obis decodiert die "Selbstvorstellung" des Zählers: ManufID2 DZG*var
Christian
Wenn Du mir einen Gefallen tun magst: Such' doch mal hier in diesem Thread mit der Suche nach "dem anderen" DZG-Nutzer! Der hat das Problem, der hatte den Patch für vzlogger rausgesucht, und hat ihn dann mir geschickt und ich habe es eingebaut. Wenn man irgendwie automatisch zwischen "kaputt" und "heile" unterscheiden kann (indem Ihr vergleicht: Mein Zähler sagt X, Deiner Y), wäre es natürlich am besten. Die ganz saubere Welt wäre natürlich, DZG anzuschreiben und zu sagen: "Sagt mal: Wie kriegt man am besten Euren Bug von damals gefixt?".
Ich versuch' nur, möglichst viele Leute glücklich zu machen...
Hallo,
ich habe gestern ein Update auf die Version von
47_OBIS.pm 25147 2021-10-29 15:14:14Z gvzdus
gemacht.
Seit dem wird beim Zählerstand ein Richtungszeichen vorangestellt (1.8.0_Verbrauch >11270024.3). Das hat natürlich zur Folge das das Stateformat nicht berechnet werden kann und der ElectricityCalculator so ebenfalls nicht rechnen kann.
Ist es möglich das Richtungszeichen aus dem Reading "1.8.0_Verbrauch" wieder zu entfernen oder mus sich über ein Userreading gehen?
Danke
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 9
FUUID 61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
MeterType SML
NAME ITR_Stromzaehler
NR 20
PARTIAL
STATE Aktuell: 312.0 W, Verbrauch: 0 kWh seit 25.11., 08:15.
TYPE OBIS
READINGS:
2021-11-25 08:15:49 1.8.0_Verbrauch >11269431.8
2021-11-25 08:15:49 2.8.0_Einspeisung 0
2021-11-25 08:15:49 ManufID2 ITR
2021-11-25 08:15:49 power 312
2021-11-24 20:02:19 state opened
helper:
BUFFER
DIRECTIONSUM >
EoM 1
LastPacketTime 1637824549.91025
SPEED 5
SPEED2 5
TRIGGERTIME 1637780539.29366
Channels:
1-0:1.8.0*255 1.8.0_Verbrauch
1-0:2.8.0*255 2.8.0_Einspeisung
DEVICES:
10
RULECACHE:
1-0:16.7.0*255 Channels
1-0:96.50.1*1 ManufID2
directions:
< pwr feeding
> pwr consuming
Attributes:
channels {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
interval 10
pollingMode on
room Stromzähler
stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }
Edit:
Laut commandref habe ich nun das Attribut "directions" eingefügt. Dieses erzeugt auch die beiden Readings "total_consumption" und "total_feed". Allerdings wird "total_consumption" nicht in dem gleichen Intervall (=10s) aktualisiert wie z.B. "power" oder "1.8.0_Verbrauch". Bisher wurde es nicht mehr aktualisiert...
Jemand einen Tipp?
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 9
FUUID 61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
MeterType SML
NAME ITR_Stromzaehler
NR 20
PARTIAL
STATE Aktuell: 313.0 W, Verbrauch: 11269 kWh seit 25.11., 09:51.
TYPE OBIS
READINGS:
2021-11-25 09:51:44 1.8.0_Verbrauch >11270024.3
2021-11-25 09:51:44 2.8.0_Einspeisung 0
2021-11-25 09:51:44 ManufID2 ITR
2021-11-25 09:51:44 power 313
2021-11-24 20:02:19 state opened
2021-11-25 09:18:21 total_consumption 11269811
2021-11-25 09:18:21 total_feed 0
helper:
BUFFER v J���
DIRECTIONSUM >
EoM -1
LastPacketTime 1637830304.93766
SPEED 5
SPEED2 5
TRIGGERTIME 1637780539.29366
directions pwr feeding
Channels:
1-0:1.8.0*255 1.8.0_Verbrauch
1-0:2.8.0*255 2.8.0_Einspeisung
DEVICES:
10
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:96.50.1*1 ManufID2
Attributes:
channels {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
directions ">" => "pwr consuming", "<"=>"pwr feeding"
interval 10
pollingMode on
room Stromzähler
stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"total_consumption",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }
Edit2:
habe wieder auf diese Version downgraded, damit wird dem Zählerstand kein Richtungszeichen vorangestellt.
47_OBIS.pm 24225 2021-04-12 11:37:25Z gvzdus
Hi, sorry, dass es kaputt gegangen ist!
Du findest auf Seite 88 um den 1. September den Grund für die Änderung. Ich hatte damals mit meinem ISKRA-Zähler die Änderung getestet, und bei mir war alles okay.
Ich denke, dass man das Fixen kann (und werde es tun). Könntest Du Dein OBIS-Device bitte kurz auf Loglevel 5 stellen und mir eine Log-Zeile mit "Full-Message" schicken, in der "total_consumption" übermittelt wird? Dann kann ich Deine Situation debuggen.
Du findest Backups der Vorversion übrigens immer unter /opt/fhem/restoreDir - von da kannst Du danach die Ursprungsversion, die noch lief, erst einmal zurück kopieren.
Hi, kein Problem. Habe wie du beschreibst die Vorgängerversion wiederhergestellt.
Hier das Verbose 5 Log und die Full message.
Danke und Gruß
2021.11.26 12:02:07 5: DevIo_SimpleWrite ITR_Stromzaehler:
2021.11.26 12:02:07 4: OBIS (ITR_Stromzaehler) - Wrote
2021.11.26 12:02:07 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 12:02:17
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E21EE26200620072650000010176010109000000000506B9950B0A01495452000349F040726201650506BA4F0163E9CF0076094AAF100402E21EE36200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506BA4F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006B9BD400177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B52005500000E0E01010163B2690076094AAF100402E21EE462006200726500000201710163A4CE0000001B1B1B1B1A028700
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E21EE26200620072650000010176010109000000000506B9950B0A01495452000349F040726201650506BA4F0163E9CF0076094AAF100402E21EE36200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506BA4F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006B9BD400177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B52005500000E0E01010163B2690076094AAF100402E21EE462006200726500000201710163A4CE0000001B1B1B1B1A028700
2021.11.26 12:02:08 4: OBIS (ITR_Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(11283590.4*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(3598*W)
!
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(11283590.4*Wh)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(3598*W)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(3598*W) is of type Channels
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
Hmmh. Bei mir erscheint mit Deinen Daten die Zeile total_consumption (das ist 1.8.0) ohne ">".
Könntest Du bitte einmal probieren, was ohne Dein "channels" kommt? Also, wenn es der "Default-Name" "total_consumption" ist?
Der pollmode mit 10 Sekunden ist nicht wirklich optimal: Da nicht immer alle Werte gesendet werden, könnte es sein, dass Dir da Werte, die sich nicht mit jedem Paket ändern, durch die Lappen gehen.
Ich bin jetzt das Wochenende erst mal weg vom Rechner...
wünsche schönes Wochenende
welches Interval wäre zu empfehlen?
Da habe ich nicht mitgedacht, das Verbose Log5 jetzt von der aktuellen 47_OBIS.pm Version
2021.11.26 15:32:50 5: DevIo_SimpleWrite ITR_Stromzaehler:
2021.11.26 15:32:50 4: OBIS (ITR_Stromzaehler) - Wrote
2021.11.26 15:32:50 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 15:33:00
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E2B30B6200620072650000010176010109000000000506EAF80B0A01495452000349F040726201650506EBB20163073B0076094AAF100402E2B30C6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBB275770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA404D0177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B520055000001960101016333130076094AAF100402E2B30D6200620072650000020171016363B70000001B1B1B1B1A02E994
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E2B30B6200620072650000010176010109000000000506EAF80B0A01495452000349F040726201650506EBB20163073B0076094AAF100402E2B30C6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBB275770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA404D0177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B520055000001960101016333130076094AAF100402E2B30D6200620072650000020171016363B70000001B1B1B1B1A02E994
2021.11.26 15:32:51 4: OBIS (ITR_Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(>11286945.3*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(406*W)
!
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>11286945.3*Wh)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(406*W)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(406*W) is of type Channels
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
2021.11.26 15:32:51 1: PERL WARNING: Argument ">11286945.3" isn't numeric in division (/) at (eval 57) line 1.
2021.11.26 15:32:51 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:33:00 5: DevIo_SimpleWrite ITR_Stromzaehler:
2021.11.26 15:33:00 4: OBIS (ITR_Stromzaehler) - Wrote
2021.11.26 15:33:00 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 15:33:10
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E2B3296200620072650000010176010109000000000506EB020B0A01495452000349F040726201650506EBBC016355F50076094AAF100402E2B32A6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBBC75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA40580177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000019001010163760E0076094AAF100402E2B32B620062007265000002017101632D1F0000001B1B1B1B1A02B9C8
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E2B3296200620072650000010176010109000000000506EB020B0A01495452000349F040726201650506EBBC016355F50076094AAF100402E2B32A6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBBC75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA40580177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000019001010163760E0076094AAF100402E2B32B620062007265000002017101632D1F0000001B1B1B1B1A02B9C8
2021.11.26 15:33:01 4: OBIS (ITR_Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(>11286946.4*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(400*W)
!
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>11286946.4*Wh)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(400*W)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(400*W) is of type Channels
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
2021.11.26 15:33:01 1: PERL WARNING: Argument ">11286946.4" isn't numeric in division (/) at (eval 58) line 1.
2021.11.26 15:33:01 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:33:11 1: PERL WARNING: Argument ">11286947.6" isn't numeric in division (/) at (eval 60) line 1.
2021.11.26 15:33:11 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:33:21 1: PERL WARNING: Argument ">11286948.7" isn't numeric in division (/) at (eval 61) line 1.
2021.11.26 15:33:21 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:33:31 1: PERL WARNING: Argument ">11286949.8" isn't numeric in division (/) at (eval 62) line 1.
2021.11.26 15:33:31 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:34:28 1: PERL WARNING: Argument ">11286950" isn't numeric in division (/) at (eval 328) line 1.
2021.11.26 15:34:28 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:34:38 1: PERL WARNING: Argument ">11286958.3" isn't numeric in division (/) at (eval 336) line 1.
2021.11.26 15:34:38 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:34:48 1: PERL WARNING: Argument ">11286959.6" isn't numeric in division (/) at (eval 338) line 1.
2021.11.26 15:34:48 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:34:58 1: PERL WARNING: Argument ">11286960.8" isn't numeric in division (/) at (eval 340) line 1.
2021.11.26 15:34:58 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:35:08 1: PERL WARNING: Argument ">11286962" isn't numeric in division (/) at (eval 341) line 1.
2021.11.26 15:35:08 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:35:18 1: PERL WARNING: Argument ">11286963.3" isn't numeric in division (/) at (eval 342) line 1.
2021.11.26 15:35:18 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
2021.11.26 15:35:28 1: PERL WARNING: Argument ">11286964.5" isn't numeric in division (/) at (eval 343) line 1.
2021.11.26 15:35:28 3: eval: sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));
Zunächst erst einmal ein riesiges Dankeschön gvzdus für die Entwicklung des OBIS Moduls. Leider kam ich in den letzten Wochen nicht dazu das Thema zu verfolgen. Ich habe nun mit deiner
ausführlichen Antwort aus dem September die Daten noch einmal manuell analysiert. Offensichtlich hat mein Holley DTZ541 auch einen reduzierten Datenmode. Das muss ich später genauer untersuchen.
Nun plagt mich ein neues Problem. Seit gestern ist plötzlich Schluss mit readings. Den Effekt von zeitweisen Aussetzern konnte ich im Oktober durch Neustart des raspis beheben.
Jetzt ist aber ganz Schluss. Der Status ist opened, es kommen aber keine Readings. Auch die Type information bleibt leer. Ein Update heute brachte leider auch nichts.
Hatte jemand schon einmal einen solchen Effekt? Kann ich prüfen ob der Lesekopf noch funktioniert?
Viele Grüße
Nico
Der Basis-Test ist eigentlich simpel:
FHEM beenden, und mit
cat /dev/ttyUSB1 | hexdump
gucken, was auf der Schnittstelle ankommt (statt USB1 natürlich ggf. das richtige Device). Ggf. mit Laptop am Zählerschrank und dabei am Lesekopf drehen und schieben.
Das Datenpaket beginnt mit 1b1b1b1b01010101, hier bei 0x18A:
0000160 8a7d 2dd9 e2c1 a49a fd9b 5348 e457 89b5
0000170 27e5 1b30 0e2d faa6 ce4f 5c32 69d9 0101
0000180 6301 4935 7600 0005 7af3 1b1b 1b1b 0101
0000190 0101 0576 b86b 626f 6200 7200 0163 7601
00001a0 0101 0105 3d79 0b7b 0109 5349 004b a1e6
00001b0 0101 0663 0078 0576 b86b 6270 6200 7200
Debugging Zähler: Mit meinem iPhone XR im Kameramodus auf den Zähler gerichtet, sehe ich das IR-Signal als sekündliches Lila leuchten.
Wenn da nix kommt: PIN noch einmal eingeben?
Achso, auch immer gerne eine Fehlerquelle: Viele USB-Geräte am Raspi, Reboot, und die Nummern werden neu verlost. Deswegen immer besser über den Gerätenamen ansprechen, bei mir z.B. statt /dev/ttyUSB1 lieber ein /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0. Das ist "mehr sticky".
Zitat von: karpate am 26 November 2021, 15:39:23
welches Interval wäre zu empfehlen?
Überhaupt kein Intervall! Kein "pollingMode"-Attribut, kein "interval"! Ich finde die Verwendung von "interval" sinnvoll, wenn z.B. alle 5 Minuten oder gar stündlich die "Meßwerte" bestimmt werden sollen. Dann ist es auch sinnvoll, die verbrauchte Leistung als Delta der Zählerstände zu ermitteln. Für Anwendungen wie bei mir, nämlich die Verbraucherüberschuss-Steuerung, musst Du eher entweder auf die genauen Werte gehen oder diese Werte mitteln.
Ich habe Deine Werte mal eingelesen, und ja, ich sehe auch im Debug-Log dann das Dekodieren wie:
2021.11.30 20:20:52 5: OBIS (ob) - Msg-Parse: 1-0:1.8.0*255(>11286946.4*Wh)Das Reading ist aber trotzdem ohne Präfix:
defmod ob OBIS /tmp/ob
attr ob verbose 5
setstate ob 2 lines in 0.0493559837341309 seconds = 41 lines per second
setstate ob 2021-11-30 20:20:52 ManufID2 ITR
setstate ob 2021-11-30 20:20:52 power 400
setstate ob 2021-11-30 20:20:52 state 2 lines in 0.0493559837341309 seconds = 41 lines per second
setstate ob 2021-11-30 20:20:52 total_consumption 11286946.4
setstate ob 2021-11-30 20:20:52 total_feed 0
(Meine Debug-Funktion: Obis mit File-Namen anlegen liest eine Logdatei auf verbose 5 ein).
Daher meine Frage: Was kommt, wenn Du mal "channels" rauswirfst und den "gottgebenen" Namen "total_consumption" wirken lässt?
Vielen Dank für die schnelle Hilfe.
sudo systemctl stop fhem
cat /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0029-if00-port0 | hexdump
brachte nichts. Danach machte ich den Handy-Test mit der IR-LED. Das funktionierte.
Nun drehte ich noch den Sensor, der 2 Monate funktionierte, um 180°.
Danach brachte der USB-Test das gewünschte Ergebnis als Hex-Datenblock.
Neustart von fhem und alles läuft wieder.
Noch einmal herzlichen Dank für die Hilfe. Rätselhaft bleibt es trotzdem.
Viele Grüße
Nico
Hallo,
ich habe mir jetzt auch mal ein IR-Lesegerät für meinen Zähler besorgt. Der basiert auf einem ESP8266 und übermittelt schon SML-Daten per WLAN an FHEM.
Dazu habe ich ein MQTT2_SERVER Device angelegt, welches wiederum per autocreate ein MQTT2_DEVICE erzeugt hat, in welchem nun auch die Werte einschlagen.
So weit, so gut.
Allerdings bekomme ich die Werte so angezeigt:
1-0_1.8.0_255_value 16460000
Ich vermute, dass mit dem OBIS Modul direkt angezeigt würde, dass es sich hier um den Zählerstand handelt?
Wie ich gesehen habe, kann man das mittels "none" auch als Auswertungs-Device anlegen, aber wie müsste der Notify dazu aussehen, um von meinem MQTT-Client die Daten ins OBIS zu bekommen? Oder geht das völlig anders, mache ich einen Denkfehler?
Das OBIS-Modul würde ich aus dem Spiel lassen - dessen Job hast Du ja auf den ESP verlagert. Du kannst aber im Code sehen, welche Codes was bedeuten, wenn es sich Dir nicht automatisch erschließt. Wenn Du gerne die OBIS-Nomensklatur hättest, definiere Dir doch einfach ein Dummy-Device und schreibe per notify die Werte vom MQTT-Endpunkt unter den "richtigen" Namen da rein.
Ich vermute, Du hast noch nicht die PIN in Deinen Zähler gemorsed - daher die hohe Ungenauigkeit beim Messwert.
ach so, ich dachte das OBIS Modul würde diese Nummern-Codierung in Klartext umsetzen? Dann hab' ich das in der Tat falsch verstanden. Wollte vermeiden, das Rad neu erfinden zu müssen. ;)
Die PIN habe ich bisher noch nicht bekommen, nein. :(
Hallo zusammen,
ich habe nun auch einen ,,modernen" Stromzähler bekommen und wollte die Daten in FHEM einlesen.
Der totale Verbrauch wird auch ausgelesen, aber der aktuelle Verbrauch nicht. Ich sehe auch Einträge, die nicht erkannt werden. Leider habe ich den Fehler im Thread nicht gefunden:
2021.12.10 14:29:55 3: Stromzaehler device opened
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: /EBZ5DD3BZ06ETA_107
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse:
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: /EBZ5DD3BZ06ETA_107
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse:
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:0.0.0*255(487153)
2021.12.10 14:29:55 4: OBIS (Stromzaehler) - Storing Owner for 1-0:0.0.0*255 in Cache
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg 1-0:0.0.0*255(487153) is of type Owner
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(1EBZ0101156484)
2021.12.10 14:29:55 3: OBIS (Stromzaehler) - Unknown Message: 1-0:96.1.0*255(1EBZ0101156484)
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(000873*kWh)
2021.12.10 14:29:55 4: OBIS (Stromzaehler) - Storing Counter for 1-0:1.8.0*255 in Cache
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(000873*kWh) is of type Counter
2021.12.10 14:29:55 4: OBIS (Stromzaehler) - Set total_consumption to 873
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.5.0*255(001C0104)
2021.12.10 14:29:55 3: OBIS (Stromzaehler) - Unknown Message: 1-0:96.5.0*255(001C0104)
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: 0-0:96.8.0*255(008FCE48)
2021.12.10 14:29:55 3: OBIS (Stromzaehler) - Unknown Message: 0-0:96.8.0*255(008FCE48)
2021.12.10 14:29:55 5: OBIS (Stromzaehler) - Msg-Parse: !
Gibt der Zähler den aktuellen Verbrauch nicht zurück?
Vielen Dank für eure Hilfe.
Moin,
a) Hast Du die PIN schon angefordert und reingemorsed? Eigentlich ist die Auflösung auf 0,1 Wh genau.
b) Danach könntest Du mal auf "verbose 5" stellen, dann kann ich die Verarbeitung simulieren.
Ok PIN habe ich tatsächlich nicht. Sobald ich diese habe, kann ich die über FHEM mit dem Lesekopf reinmorsen?
Ansonsten lese ich hier noch mal und Danke.
Nee, in der Regel hat Dein Messstellenbetreiber die Anleitung ins Internet gestellt, sonst halt "normales Google".
Über FHEM klappt die PIN-Eingabe nicht. Du musst tatsächlich eine Taschenlampe o.ä. nehmen und in die Schweinsnase "reinmorsen".
Hallo zusammen,
Ich habe eine Frage zu meinem neuen Iskar Zaehler. Der Zaehler wurde am 23.12 eingebaut und ich habe einen Lesekopf montiert. Es handelt sich um Photovoltaik.
Meinen Beobachtungen nach weicht der Zaehlerstand Ch2 zwischen Obis und Zaehlerdisplay extrem ab.
Aktuell hat der Zaehler 3kWh und in Fhem werden 50 angezeigt.
Anbei ein List
Internals:
CFGFN
DEF /dev/ttyUSB2@9600,8,N,1
DeviceName /dev/ttyUSB2@9600,8,N,1
FD 40
FUUID 61c98b00-f33f-8d6f-ed22-b4b519c696ffd363
MeterType SML
NAME test
NR 43996
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2021-12-27 10:45:44 1.0.0.2.0.15 20
2021-12-27 10:45:44 1.0.14.7.0.255 50.07
2021-12-27 10:45:44 1.0.81.7.1.255 120.5
2021-12-27 10:45:44 1.0.81.7.15.255 0
2021-12-27 10:45:44 1.0.81.7.2.255 239.6
2021-12-27 10:45:44 1.0.81.7.26.255 0
2021-12-27 10:45:44 1.0.81.7.4.255 206.7
2021-12-27 10:45:44 ManufID2 ZPA
2021-12-27 10:45:44 current_L1 0.346
2021-12-27 10:45:44 current_L2 0
2021-12-27 10:45:44 current_L3 0
2021-12-27 10:45:44 power -67
2021-12-27 10:45:44 power_CounterCurrent -0.067
2021-12-27 10:44:34 power_CounterDay1st -0.064
2021-12-27 10:44:34 power_CounterDayLast -0.064
2021-12-27 10:44:34 power_CounterMeter1st -0.064
2021-12-27 10:44:34 power_CounterMeterLast -0.064
2021-12-27 10:44:34 power_CounterMonth1st -0.064
2021-12-27 10:44:34 power_CounterMonthLast -0.064
2021-12-27 10:44:34 power_CounterYear1st -0.064
2021-12-27 10:44:34 power_CounterYearLast -0.064
2021-12-27 10:45:44 power_EnergyCostDay -0.001
2021-12-27 10:45:44 power_EnergyCostMeter -0.001
2021-12-27 10:45:44 power_EnergyCostMonth -0.001
2021-12-27 10:45:44 power_EnergyCostYear -0.001
2021-12-27 10:45:44 power_EnergyDay -0.003
2021-12-27 10:45:44 power_EnergyMeter -0.003
2021-12-27 10:45:44 power_EnergyMonth -0.003
2021-12-27 10:45:44 power_EnergyYear -0.003
2021-12-27 10:45:44 power_FinanceReserve 897.418
2021-12-27 10:45:44 power_L1 -67
2021-12-27 10:45:44 power_L1_CounterCurrent -0.067
2021-12-27 10:44:34 power_L1_CounterDay1st -0.064
2021-12-27 10:44:34 power_L1_CounterDayLast -0.064
2021-12-27 10:44:34 power_L1_CounterMeter1st -0.064
2021-12-27 10:44:34 power_L1_CounterMeterLast -0.064
2021-12-27 10:44:34 power_L1_CounterMonth1st -0.064
2021-12-27 10:44:34 power_L1_CounterMonthLast -0.064
2021-12-27 10:44:34 power_L1_CounterYear1st -0.064
2021-12-27 10:44:34 power_L1_CounterYearLast -0.064
2021-12-27 10:45:44 power_L1_EnergyCostDay -0.001
2021-12-27 10:45:44 power_L1_EnergyCostMeter -0.001
2021-12-27 10:45:44 power_L1_EnergyCostMonth -0.001
2021-12-27 10:45:44 power_L1_EnergyCostYear -0.001
2021-12-27 10:45:44 power_L1_EnergyDay -0.003
2021-12-27 10:45:44 power_L1_EnergyMeter -0.003
2021-12-27 10:45:44 power_L1_EnergyMonth -0.003
2021-12-27 10:45:44 power_L1_EnergyYear -0.003
2021-12-27 10:45:44 power_L1_FinanceReserve 897.418
2021-12-27 10:45:44 power_L1_MonthMeterReading 11
2021-12-27 10:45:44 power_L1_PowerCurrent 3.600
2021-12-27 10:45:44 power_L1_PowerDayAver -0.154
2021-12-27 10:45:08 power_L1_PowerDayMax 54.000
2021-12-27 10:45:09 power_L1_PowerDayMin -58
2021-12-27 10:44:34 power_L1_WFRDayMax 0
2021-12-27 10:44:34 power_L1_WFRDayMin 0
2021-12-27 10:45:44 power_L2 0
2021-12-27 10:45:44 power_L2_CounterCurrent 0.000
2021-12-27 10:44:34 power_L2_CounterDay1st 0.000
2021-12-27 10:44:34 power_L2_CounterDayLast 0.000
2021-12-27 10:44:34 power_L2_CounterMeter1st 0.000
2021-12-27 10:44:34 power_L2_CounterMeterLast 0.000
2021-12-27 10:44:34 power_L2_CounterMonth1st 0.000
2021-12-27 10:44:34 power_L2_CounterMonthLast 0.000
2021-12-27 10:44:34 power_L2_CounterYear1st 0.000
2021-12-27 10:44:34 power_L2_CounterYearLast 0.000
2021-12-27 10:45:44 power_L2_EnergyCostDay 0.000
2021-12-27 10:45:44 power_L2_EnergyCostMeter 0.000
2021-12-27 10:45:44 power_L2_EnergyCostMonth 0.000
2021-12-27 10:45:44 power_L2_EnergyCostYear 0.000
2021-12-27 10:45:44 power_L2_EnergyDay 0.000
2021-12-27 10:45:44 power_L2_EnergyMeter 0.000
2021-12-27 10:45:44 power_L2_EnergyMonth 0.000
2021-12-27 10:45:44 power_L2_EnergyYear 0.000
2021-12-27 10:45:44 power_L2_FinanceReserve 897.417
2021-12-27 10:45:44 power_L2_MonthMeterReading 11
2021-12-27 10:45:44 power_L2_PowerCurrent 0.000
2021-12-27 10:45:44 power_L2_PowerDayAver 0.000
2021-12-27 10:44:34 power_L2_WFRDayMax 0
2021-12-27 10:44:34 power_L2_WFRDayMin 0
2021-12-27 10:45:44 power_L3 0
2021-12-27 10:45:44 power_L3_CounterCurrent 0.000
2021-12-27 10:44:34 power_L3_CounterDay1st 0.000
2021-12-27 10:44:34 power_L3_CounterDayLast 0.000
2021-12-27 10:44:34 power_L3_CounterMeter1st 0.000
2021-12-27 10:44:34 power_L3_CounterMeterLast 0.000
2021-12-27 10:44:34 power_L3_CounterMonth1st 0.000
2021-12-27 10:44:34 power_L3_CounterMonthLast 0.000
2021-12-27 10:44:34 power_L3_CounterYear1st 0.000
2021-12-27 10:44:34 power_L3_CounterYearLast 0.000
2021-12-27 10:45:44 power_L3_EnergyCostDay 0.000
2021-12-27 10:45:44 power_L3_EnergyCostMeter 0.000
2021-12-27 10:45:44 power_L3_EnergyCostMonth 0.000
2021-12-27 10:45:44 power_L3_EnergyCostYear 0.000
2021-12-27 10:45:44 power_L3_EnergyDay 0.000
2021-12-27 10:45:44 power_L3_EnergyMeter 0.000
2021-12-27 10:45:44 power_L3_EnergyMonth 0.000
2021-12-27 10:45:44 power_L3_EnergyYear 0.000
2021-12-27 10:45:44 power_L3_FinanceReserve 897.417
2021-12-27 10:45:44 power_L3_MonthMeterReading 11
2021-12-27 10:45:44 power_L3_PowerCurrent 0.000
2021-12-27 10:45:44 power_L3_PowerDayAver 0.000
2021-12-27 10:44:34 power_L3_WFRDayMax 0
2021-12-27 10:44:34 power_L3_WFRDayMin 0
2021-12-27 10:45:44 power_MonthMeterReading 11
2021-12-27 10:45:44 power_PowerCurrent 3.600
2021-12-27 10:45:44 power_PowerDayAver -0.154
2021-12-27 10:45:08 power_PowerDayMax 54.000
2021-12-27 10:45:09 power_PowerDayMin -58
2021-12-27 10:44:34 power_WFRDayMax 0
2021-12-27 10:44:34 power_WFRDayMin 0
2021-12-27 10:44:32 state opened
2021-12-27 10:45:44 total_consumption 59
2021-12-27 10:45:44 total_consumption_Ch1 0
2021-12-27 10:45:44 total_consumption_Ch2 59
2021-12-27 10:45:44 total_feed 3532.3
2021-12-27 10:45:44 voltage_L1 224.58
2021-12-27 10:45:44 voltage_L2 223.78
2021-12-27 10:45:44 voltage_L3 224.03
helper:
BUFFER vbbrev
ZPAp� rbe^�c.�vbbrew
ZPAp�b
��rbe^��
w`2ZPAw`�
ZPAp�w�e b R�iNw�b R�iw�b R�iNw�b R�i��w�b,R�i�w20w`Z֊��waa�w`� w�bRY��������w$�bRY��������w8�bRYwL�bRYw
DIRECTIONSUM <
EoM 0
LastPacketTime 1640598344.34712
SPEED 5
SPEED2 5
TRIGGERTIME 1640598272.97066
Channels:
DEVICES:
-1
RULECACHE:
1-0:0.2.0*15 unknown
1-0:1.8.0*255 Counter
1-0:1.8.1*255 Counter
1-0:1.8.2*255 Counter
1-0:14.7.0*255 Channels
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:31.7.0*255 Channels
1-0:32.7.0*255 Channels
1-0:36.7.0*255 Channels
1-0:51.7.0*255 Channels
1-0:52.7.0*255 Channels
1-0:56.7.0*255 Channels
1-0:71.7.0*255 Channels
1-0:72.7.0*255 Channels
1-0:76.7.0*255 Channels
1-0:81.7.1*255 Channels
1-0:81.7.15*255 Channels
1-0:81.7.2*255 Channels
1-0:81.7.26*255 Channels
1-0:81.7.4*255 Channels
1-0:96.5.0*255 unknown
1-0:96.50.1*1 ManufID2
1-0:96.90.2*3 unknown
1-0:97.97.0*255 unknown
directions:
Attributes
Ich habe noch zwei weitere Zaehler mit Lesekoepfen in Betrieb. Das passen alle Werte zu 100%. Das neue Modell hat in der ManId ein ZPA..
Hat jemand eine Idee, wo hier der fehlerhafte Werte her kommen koennen?
Der Wert fuer power* wird korrekt uebertragen. Daher denke ich das Device an sich passt.
Viele Gruesse,
Dirk
Wenn ich Dich anhand Deiner Zählerwerte einschätze, hängt kein Haus an diesem Zähler, sondern nur eine PV-Anlage, richtig?
Relevant und direkt aus dem Zähler per OBIS-Modul stammend sind:
"power", bei Dir -67, plausibel.
"total_feed": 3532.3, = 3532,3 Wh oder 3,532 kWh = Einspeisung seit 23.12.
"total_consumption": 59 Wh = fast kein Bezug aus dem Netz.
(Das sonstige Gedöns wie Frequenz, Spannung, Phasenwerte lasse ich jetzt mal weg).
Ist das so richtig?
Korrekt. Der erzeugte Strom wird komplett eingespeist.
Dann ist in dem Fall der total_feed Wert mein Erzeugter Strom aus der Anlage.
Da muss man ja erst mal drauf kommen :D
Eine Frage der Anleitung. Ich finde auf die Schnelle diese Anleitung:
https://www.stadtwerke-velbert.de/medien/downloads/netze/Kurzanleitung-Drehstromzaehler_eBZ_DD3.pdf
Da gibt es einen Punkt "Langes Datenprotokoll". Könnte vielversprechend sein.
ich habe es mal umgestellt.
Info ON/ Off : Auf OFF - somit kurzes Datenprotokoll.
Auf den späten Blick wurden die total_consumption* Werte genullt.
Andere Änderung an sich aktiv verändernden Werten würde man erst beim Arbeiten der Anlage sehen.
Hey, der Tipp mit dem "Lang / Kurz" ging an "Che007", nicht an Dich! Bei Dir ist m.E. alles perfekt...
Bei Che007 sind die Zahlen zu den Zählerständen auf kWh ohne Nachkomma gerundet: Das macht ja keinen Spaß.
Hallo,
ich bekomme beim Auslesen meines Zählers sekündlich Fehlermeldungen in mein Log, so das mein Log über den Monat schon
allein vom Speichervolumen (im Gb Bereich) meinen Raspi nur durch Speicherplatzmangel zum Erliegen brachte!
Die Fehlermeldungen:
2021.12.28 13:29:43 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 609.
2021.12.28 13:29:43 1: stacktrace:
2021.12.28 13:29:43 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (609)
2021.12.28 13:29:43 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.28 13:29:43 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.28 13:29:43 1: main::CallFn called by fhem.pl (774)
2021.12.28 13:29:43 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.28 13:29:43 1: stacktrace:
2021.12.28 13:29:43 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.28 13:29:43 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.28 13:29:43 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.28 13:29:43 1: main::CallFn called by fhem.pl (774)
2021.12.28 13:29:43 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.28 13:29:43 1: stacktrace:
2021.12.28 13:29:43 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.28 13:29:43 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.28 13:29:43 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.28 13:29:43 1: main::CallFn called by fhem.pl (774)
2021.12.28 13:29:43 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 714.
2021.12.28 13:29:43 1: stacktrace:
2021.12.28 13:29:43 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (714)
2021.12.28 13:29:43 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.28 13:29:43 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.28 13:29:43 1: main::CallFn called by fhem.pl (774)
diese wiederholen sich jede Sekunde. Eine Prüfung mit verbose 5 ergab:
2021.12.31 16:08:49 3: OBIS (StromZaehler) - Attr interval Val 30, dopoll =
2021.12.31 16:08:52 5: OBIS (StromZaehler) - SML-Parse 1B1B1B1B0101010176050177BF5C6200620072630101760107FFFFFFFFFFFF05007D3FCA0B0A014546522102CD569A726201647D861901633E1E0076050177BF5D62006200726307017707FFFFFFFFFFFF0B0A014546522102CD569A070100620AFFFF726201647D8619F106770701006032010101010101044546520177070100600100FF010101010B0A014546522102CD569A0177070100010800FF641C0004726201647D8619621E52FF64CAB1070177070100020800FF01726201647D8619621E52FF62000177070100100700FF0101621B52005302620177070100200700FF0101622352FF6308D90177070100340700FF0101622352FF6308DD0177070100480700FF0101622352FF6308DC01770701001F0700FF0101622152FE62A20177070100330700FF0101622152FE62720177070100470700FF0101622152FE62390177070100510701FF01016208520052770177070100510702FF0101620852005300EE0177070100510704FF010162085200530160017707010051070FFF01016208520053014C017707010051071AFF01016208520053014501770701000E0700FF0101622C52FF6301F4017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E3132017707010060320404010101010304220101016388300076050177BF5E6200620072630201710163D21F001B1B1B1B1A00CA26
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Full message-> 1B1B1B1B0101010176050177BF5C6200620072630101760107FFFFFFFFFFFF05007D3FCA0B0A014546522102CD569A726201647D861901633E1E0076050177BF5D62006200726307017707FFFFFFFFFFFF0B0A014546522102CD569A070100620AFFFF726201647D8619F106770701006032010101010101044546520177070100600100FF010101010B0A014546522102CD569A0177070100010800FF641C0004726201647D8619621E52FF64CAB1070177070100020800FF01726201647D8619621E52FF62000177070100100700FF0101621B52005302620177070100200700FF0101622352FF6308D90177070100340700FF0101622352FF6308DD0177070100480700FF0101622352FF6308DC01770701001F0700FF0101622152FE62A20177070100330700FF0101622152FE62720177070100470700FF0101622152FE62390177070100510701FF01016208520052770177070100510702FF0101620852005300EE0177070100510704FF010162085200530160017707010051070FFF01016208520053014C017707010051071AFF01016208520053014501770701000E0700FF0101622C52FF6301F4017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E3132017707010060320404010101010304220101016388300076050177BF5E6200620072630201710163D21F001B1B1B1B1A00CA26
2021.12.31 16:08:52 3: 2nd TL-byte != 0, reserved according spec
2021.12.31 16:08:52 4: OBIS (StromZaehler) - MSG IS:
/
1-0:96.50.1*1(EFR)
1-0:96.1.0*255(
EFR!V)
1-0:1.8.0*255(>1328359.1*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(610*W)
1-0:32.7.0*255(226.5*V)
1-0:52.7.0*255(226.9*V)
1-0:72.7.0*255(226.8*V)
1-0:31.7.0*255(1.62*A)
1-0:51.7.0*255(1.14*A)
1-0:71.7.0*255(0.57*A)
1-0:81.7.1*255(119*var)
1-0:81.7.2*255(238*var)
1-0:81.7.4*255(352*var)
1-0:81.7.15*255(332*var)
1-0:81.7.26*255(325*var)
1-0:14.7.0*255(50*Hz)
1-0:0.2.0*0(03.00)
1-0:96.90.2*1(B)
1-0:97.97.0*0()
1-0:96.50.1*4(P1.2.12)
1-0:96.50.4*4(")
255-255:255.255.255*255()
!
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: /
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.1*1(EFR)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing ManufID2 for 1-0:96.50.1*1 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:96.50.1*1(EFR) is of type ManufID2
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.1.0*255(
EFR!V)
2021.12.31 16:08:52 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 609.
2021.12.31 16:08:52 1: stacktrace:
2021.12.31 16:08:52 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (609)
2021.12.31 16:08:52 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:52 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:52 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:52 3: OBIS (StromZaehler) - Unknown Message: 1-0:96.1.0*255(
EFR!V)
2021.12.31 16:08:52 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.31 16:08:52 1: stacktrace:
2021.12.31 16:08:52 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.31 16:08:52 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:52 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:52 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:52 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.31 16:08:52 1: stacktrace:
2021.12.31 16:08:52 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.31 16:08:52 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:52 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:52 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:52 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 714.
2021.12.31 16:08:52 1: stacktrace:
2021.12.31 16:08:52 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (714)
2021.12.31 16:08:52 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:52 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:52 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:1.8.0*255(>1328359.1*Wh)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Counter for 1-0:1.8.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:1.8.0*255(>1328359.1*Wh) is of type Counter
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Set total_consumption to 1328359.1
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Counter for 1-0:2.8.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:2.8.0*255(0*Wh) is of type Counter
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:16.7.0*255(610*W)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:16.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:16.7.0*255(610*W) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:32.7.0*255(226.5*V)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:32.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:32.7.0*255(226.5*V) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:52.7.0*255(226.9*V)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:52.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:52.7.0*255(226.9*V) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:72.7.0*255(226.8*V)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:72.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:72.7.0*255(226.8*V) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:31.7.0*255(1.62*A)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:31.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:31.7.0*255(1.62*A) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:51.7.0*255(1.14*A)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:51.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:51.7.0*255(1.14*A) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:71.7.0*255(0.57*A)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing Channels for 1-0:71.7.0*255 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:71.7.0*255(0.57*A) is of type Channels
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.1*255(119*var)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.2*255(238*var)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.4*255(352*var)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.15*255(332*var)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.26*255(325*var)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:14.7.0*255(50*Hz)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:0.2.0*0(03.00)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.90.2*1(B)
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:97.97.0*0()
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.1*4(P1.2.12)
2021.12.31 16:08:52 4: OBIS (StromZaehler) - Storing ManufID2 for 1-0:96.50.1*4 in Cache
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg 1-0:96.50.1*4(P1.2.12) is of type ManufID2
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.4*4(")
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: 255-255:255.255.255*255()
2021.12.31 16:08:52 5: OBIS (StromZaehler) - Msg-Parse: !
2021.12.31 16:08:54 5: OBIS (StromZaehler) - SML-Parse 1B1B1B1B0101010176050177BF656200620072630101760107FFFFFFFFFFFF05007D3FCD0B0A014546522102CD569A726201647D861C0163217D0076050177BF6662006200726307017707FFFFFFFFFFFF0B0A014546522102CD569A070100620AFFFF726201647D861CF106770701006032010101010101044546520177070100600100FF010101010B0A014546522102CD569A0177070100010800FF641C0004726201647D861C621E52FF64CAB10C0177070100020800FF01726201647D861C621E52FF62000177070100100700FF0101621B52005302710177070100200700FF0101622352FF6308D80177070100340700FF0101622352FF6308DD0177070100480700FF0101622352FF6308DB01770701001F0700FF0101622152FE62A30177070100330700FF0101622152FE62730177070100470700FF0101622152FE62390177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530161017707010051070FFF01016208520053014C017707010051071AFF01016208520053014501770701000E0700FF0101622C52FF6301F4017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E3132017707010060320404010101010304220101016352550076050177BF6762006200726302017101632665001B1B1B1B1A009D47
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Full message-> 1B1B1B1B0101010176050177BF656200620072630101760107FFFFFFFFFFFF05007D3FCD0B0A014546522102CD569A726201647D861C0163217D0076050177BF6662006200726307017707FFFFFFFFFFFF0B0A014546522102CD569A070100620AFFFF726201647D861CF106770701006032010101010101044546520177070100600100FF010101010B0A014546522102CD569A0177070100010800FF641C0004726201647D861C621E52FF64CAB10C0177070100020800FF01726201647D861C621E52FF62000177070100100700FF0101621B52005302710177070100200700FF0101622352FF6308D80177070100340700FF0101622352FF6308DD0177070100480700FF0101622352FF6308DB01770701001F0700FF0101622152FE62A30177070100330700FF0101622152FE62730177070100470700FF0101622152FE62390177070100510701FF01016208520052770177070100510702FF0101620852005300EC0177070100510704FF010162085200530161017707010051070FFF01016208520053014C017707010051071AFF01016208520053014501770701000E0700FF0101622C52FF6301F4017707010000020000010101010630332E30300177070100605A0201010101010342BD01770701006161000001010101030000017707010060320104010101010850312E322E3132017707010060320404010101010304220101016352550076050177BF6762006200726302017101632665001B1B1B1B1A009D47
2021.12.31 16:08:54 3: 2nd TL-byte != 0, reserved according spec
2021.12.31 16:08:54 4: OBIS (StromZaehler) - MSG IS:
/
1-0:96.50.1*1(EFR)
1-0:96.1.0*255(
EFR!V)
1-0:1.8.0*255(>1328359.6*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(625*W)
1-0:32.7.0*255(226.4*V)
1-0:52.7.0*255(226.9*V)
1-0:72.7.0*255(226.7*V)
1-0:31.7.0*255(1.63*A)
1-0:51.7.0*255(1.15*A)
1-0:71.7.0*255(0.57*A)
1-0:81.7.1*255(119*var)
1-0:81.7.2*255(236*var)
1-0:81.7.4*255(353*var)
1-0:81.7.15*255(332*var)
1-0:81.7.26*255(325*var)
1-0:14.7.0*255(50*Hz)
1-0:0.2.0*0(03.00)
1-0:96.90.2*1(B)
1-0:97.97.0*0()
1-0:96.50.1*4(P1.2.12)
1-0:96.50.4*4(")
255-255:255.255.255*255()
!
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: /
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.1*1(EFR)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:96.50.1*1(EFR) is of type ManufID2
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.1.0*255(
EFR!V)
2021.12.31 16:08:54 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 609.
2021.12.31 16:08:54 1: stacktrace:
2021.12.31 16:08:54 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (609)
2021.12.31 16:08:54 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:54 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:54 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:54 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.31 16:08:54 1: stacktrace:
2021.12.31 16:08:54 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.31 16:08:54 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:54 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:54 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:54 1: PERL WARNING: Use of uninitialized value $1 in hash element at ./FHEM/47_OBIS.pm line 698.
2021.12.31 16:08:54 1: stacktrace:
2021.12.31 16:08:54 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (698)
2021.12.31 16:08:54 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:54 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:54 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:54 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 714.
2021.12.31 16:08:54 1: stacktrace:
2021.12.31 16:08:54 1: main::__ANON__ called by ./FHEM/47_OBIS.pm (714)
2021.12.31 16:08:54 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2021.12.31 16:08:54 1: main::OBIS_Read called by fhem.pl (3896)
2021.12.31 16:08:54 1: main::CallFn called by fhem.pl (774)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:1.8.0*255(>1328359.6*Wh)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:1.8.0*255(>1328359.6*Wh) is of type Counter
2021.12.31 16:08:54 4: OBIS (StromZaehler) - Set total_consumption to 1328359.6
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:2.8.0*255(0*Wh) is of type Counter
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:16.7.0*255(625*W)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:16.7.0*255(625*W) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:32.7.0*255(226.4*V)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:32.7.0*255(226.4*V) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:52.7.0*255(226.9*V)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:52.7.0*255(226.9*V) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:72.7.0*255(226.7*V)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:72.7.0*255(226.7*V) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:31.7.0*255(1.63*A)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:31.7.0*255(1.63*A) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:51.7.0*255(1.15*A)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:51.7.0*255(1.15*A) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:71.7.0*255(0.57*A)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:71.7.0*255(0.57*A) is of type Channels
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.1*255(119*var)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.2*255(236*var)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.4*255(353*var)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.15*255(332*var)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:81.7.26*255(325*var)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:14.7.0*255(50*Hz)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:0.2.0*0(03.00)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.90.2*1(B)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:97.97.0*0()
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.1*4(P1.2.12)
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg 1-0:96.50.1*4(P1.2.12) is of type ManufID2
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 1-0:96.50.4*4(")
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: 255-255:255.255.255*255()
2021.12.31 16:08:54 5: OBIS (StromZaehler) - Msg-Parse: !
scheinbar liegt das Problem an einem Zeilenumbruch in dieser Message:
1-0:96.1.0*255(
EFR!V)
diese müsste ja eigentlich so aussehen:
1-0:96.1.0*255(EFR!V)
Hat hier jemand eine Idee wie man das abfangen oder den Zeilenumbruch entfernen kann?
Vielen Dank im Voraus
Gruß TeleDet
Ich guck's mir an - da sollte sich schnell ein Fix finden lassen.
Das wäre Super !!!
Bei dem Stromzähler handelt es sich übrigens um einen: EFR SGM-C4-4A920L
Vielen Dank schon mal für Deine Bemühung
und Gruß TeleDet ;)
Ich habe da jetzt eingebaut, alle möglichen Control-Characters zu entfernen.
Ist morgen per Update verfügbar, oder Du editierst in 47_OBIS.pm manuell in Zeile 413:
412 $str=~s/([A-F0-9]{2})/chr(hex($1))/eg;
413 $str=~s/[[:cntrl:]]//g;
414 $str=~s/[^!-~\s\r\n\t]//g;
415 }
@gvzdus
vielen lieben Dank !!! Ich habe es in meine 47_OBIS.pm übernommen und es hat super funktioniert. :)
Eine Bitte hätte ich aber trotzdem noch ::) , könntest du bei der Gelegenheit eventuell den Loglevel für den Hinweis in Zeile (jetzt dann neu) 385 von 3 auf 4 oder 5 ändern?
385 Log3 $hash, 3, "2nd TL-byte != 0, reserved according spec";
bekomme den Hinweis im gleichen Rhythmus wie vorher die Fehlermeldungen. ???
Dank im Voraus ... TeleDet
Ist es mit diesem Modul möglich den Landis+Gyr e450 mittels MBUS RJ11 auszulesen?
Ich habs mal soweit hinbekommen, dass ich mittels minicom eine ordentliche Ausgabe bekomme: (2 Pakete im Abstand von ca. 10 Sekunden)
7e a0 8b ce ff 03 13 ee e1 e6 e7 00 e0 40 00 01 00 00 77 db 08 4c 47 5a 67 73 78 1f d0 82 01 03 30 00 00 85 31 32 2f 8f a3 e0 6f ac 64 bf 81 ce dd 62 c8 f9 3c 45 da e4 de 5e 16 2a 8d 8f 37 58 fb e4 21 ef fb 8c a4 e8 93 b0 5e b7 42 53 f2 ec 23 53 bc be 13 4b eb 5f 3d bf 21 a3 1b 3c 6e 8c 53 32 0a 66 6e 17 32 1d 24 48 cd be 7c ff db 03 a1 92 5f 8a 98 18 b1 c1 d8 81 ca d5 dc a5 51 77 66 d4 8b 85 ff 49 c4 a3 f1 d5 7e c3 7e 7e a0 8b ce ff 03 13 ee e1 e0 40 00 02 00 00 7a 84 fd c2 08 94 07 69 83 cb 4e c3 81 e0 5e c8 c8 a4 80 24 57 41 cf dc 23 cd e3 0b 2a 51 50 4b db 94 5e 89 d3 00 f4 c1 78 7a f2 c4 f8 ad 1f 24 0c 69 fd 36 3e 49 bc 03 bb 28 c9 dc 32 3c 4b 7f a4 62 32 61 83 e4 84 4f 6e e6 cf c9 27 a4 92 ae 3d 17 24 0b c3 29 aa b5 f2 3f f3 37 e6 3c 4f e3 6c b6 ab 17 04 52 e2 4f 47 0e f5 6e 58 e9 e0 47 b0 92 0c 2b c9 92 63 2a fa 27 c1 84 58 7e 7e a0 30 ce ff 03 13 86 f8 e0 c0 00 03 00 00 1f 2d 52 82 c9 64 fe 26 f7 8a 0d bc 15 4d 52 18 96 04 4f 58 23 67 3f d8 44 e7 d3 ca ba 3a 5f 11 d6 d1 7e
7e a0 8b ce ff 03 13 ee e1 e6 e7 00 e0 40 00 01 00 00 77 db 08 4c 47 5a 67 73 78 1f d0 82 01 03 30 00 00 85 3a 4a 19 7a 70 ce b6 8c 89 9d 03 81 1e d9 a9 33 e1 00 12 30 26 1c 7d 6f c2 fe df b8 37 d5 d7 84 92 75 f8 31 bf 77 af c2 96 63 e8 95 73 0b 8b d9 67 f4 6a a6 e6 37 c9 36 f2 61 37 78 49 25 fe a6 8d d7 96 15 4e b0 22 4a 26 06 d2 78 a5 37 5e 5d 9b 51 44 b2 19 ea c9 93 47 e8 6e 2b c1 74 9a c6 5c 5f 4e 6e 12 a8 24 98 7e 7e a0 8b ce ff 03 13 ee e1 e0 40 00 02 00 00 7a 80 fe 5e 0e 8b 9c f6 9a 2a 70 78 c7 29 c8 93 30 03 ec f0 f1 a0 a6 d1 e3 d5 ba e3 e7 50 d3 01 c8 41 9d 10 75 fc 2d e8 e4 b7 89 95 63 9e 9a bc 96 fe 79 f4 ac 28 e6 ca ae 58 ce a6 01 ed 1f d5 d0 6d da 9e 2f c4 6c 3c 13 63 df 6a dc de 47 e4 67 81 f3 66 d5 69 0c 23 1e 6f 67 b8 ba 4b 81 bb e4 a9 f8 ed af bb 2f 77 6f 3b 08 7a b5 81 1a c1 b6 b2 8d 5b 6d 65 ff 32 d5 a1 df 2d 08 7e 7e a0 30 ce ff 03 13 86 f8 e0 c0 00 03 00 00 1f 44 59 19 56 57 67 e4 c0 a6 ad 67 49 d3 32 0a af ab a4 b4 14 af 9a 96 e2 72 9e 3c 60 46 3c 75 8b 23 7e
Stromzähler ist von Energie Steiermark, MBUS-Protokoll mit USB-MBUS-Slave Device, Serial Port Config: 8N1
Kommunikation ist verschlüsselt, Global Unicast Encryption Key (GUEK), Global Authentication Key (GAK) habe ich.
@Teledet: Ich würde vorschlagen, dass Du den Loglevel für das OBIS-Device einfach auf 2 stellst. Ich kann mal bei Gelegenheit gucken, ob da wirklich die Spec verletzt wird, es etwas Neueres gibt, oder was die Meldung verursacht. Aber sie z.B. nur einmal je Neustart zu bringen, wäre m.E. falsch.
@lichtimc: Leider nein. Ich kann mich dunkel an eine Diskussion erinnern, wo jemand schon etwas geforscht hatte, finde sie aber im Moment nicht wieder. Ihr verwendet in AT ein ganz anderes Protokoll (dafür seid Ihr aber auch Faktor 100 weiter bei SmGWs :-) ).
Hallo gvzdus,
danke für die Info und deine Bemühung :)
Werde das so übernehmen. Scheinbar verursacht es bei mir keinerlei
Einschränkungen oder Probleme, daher setze ich das OBIS-Device bei mir auf Loglevel 2. ;)
Gruß TeleDet
Hallo zusammen,
erst einmal vielen Dank gvzdus für die Entwicklung dieses tollen OBIS Moduls. Als FHEM-Anfänger komme ich bei einer Sache nicht weiter. Vieleicht kann mir ja jemand einen Tip geben.
Ich konnte meinen Zähler EMH DMTZ-XC erfolgreich in FHEM einbinden. Leider wird der für mich wichtigste Wert "Momentanwert Wirkleistung gesamt" (OBIS 1.25) von diesem Zähler nicht übermittelt.
Aber es werden Spannung, Stromstärke und der Wirkleistungsfaktor für alle drei Phasen ausgegeben. Somit könnte ich die Wirkleistung berechnen.
In den Readings finde ich auch die
Spannungen (OBIS 32.25 für L1, 52.25 für L2 und 72.25 für L3) und die
Stromstärken (OBIS 31.25 für L1, 51.25 für L2 und 71.25 für L3)
Allerdings werden die Wirkleistunsfaktoren (OBIS 33.25 für L1, 53.25 für L2, 73.25 für L3 und 13.25 für "Leistungsfaktor gesamt") nicht angezeigt.
Im Log (siehe unten) ist aber zu erkennen, dass der Zähler die Werte ausspuckt.
Wie erhalte ich diese fehlenden Werte als Reading angezeigt? Mit dem Attribut "Channels" habe ich es schon versucht. Hat nicht geklappt.
Internals:
CFGFN
DEF /dev/ttyAMA0@300,7,E,1 VSM102
DeviceName /dev/ttyAMA0@300,7,E,1
FD 10
FUUID 61ead775-f33f-b7db-e8ee-267c6e83230898a1
MeterType VSM102
NAME Stromzaehler
NR 178
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2022-01-21 23:36:35 0.1.0 66
2022-01-21 23:36:48 0.1.2.52 201101000000
2022-01-21 23:36:47 0.1.2.53 201201000000
2022-01-21 23:36:46 0.1.2.54 210101000000
2022-01-21 23:36:45 0.1.2.55 210201000000
2022-01-21 23:36:44 0.1.2.56 210301000000
2022-01-21 23:36:43 0.1.2.57 1210401000000
2022-01-21 23:36:43 0.1.2.58 1210501000000
2022-01-21 23:36:42 0.1.2.59 1210601000000
2022-01-21 23:36:41 0.1.2.60 1210701000000
2022-01-21 23:36:40 0.1.2.61 1210801000000
2022-01-21 23:36:39 0.1.2.62 1210901000000
2022-01-21 23:36:39 0.1.2.63 1211001000000
2022-01-21 23:36:38 0.1.2.64 211101000000
2022-01-21 23:36:37 0.1.2.65 211201000000
2022-01-21 23:36:36 0.1.2.66 220101000000
2022-01-21 23:36:48 0.2.0 23100000
2022-01-21 23:36:49 0.2.1.01 12070444
2022-01-21 23:36:50 0.2.1.50 9092200
2022-01-21 23:36:50 0.2.2 8
2022-01-21 23:36:51 0.9.1 233139
2022-01-21 23:36:51 0.9.2 220121
2022-01-21 23:36:52 1.8.1 897.6
2022-01-21 23:35:55 1.8.2 15668.3
2022-01-21 23:36:08 14.25 50.02
2022-01-21 23:36:09 31.25 4.799
2022-01-21 23:36:10 32.25 234.55
2022-01-21 23:36:09 51.25 0.009
2022-01-21 23:36:11 52.25 234.79
2022-01-21 23:36:10 71.25 0.008
2022-01-21 23:36:11 72.25 234.82
2022-01-21 23:36:14 C.3 0
2022-01-21 23:36:14 C.4 00A00040
2022-01-21 23:36:15 C.5 0020F4F0
2022-01-21 23:36:16 C.52.0 3
2022-01-21 23:36:16 C.7.0 6
2022-01-21 23:36:17 C.7.1 1
2022-01-21 23:36:17 C.7.2 1
2022-01-21 23:36:18 C.7.3 0
2022-01-21 23:36:16 C.86.1 0
2022-01-21 23:36:35 Serial 00-00-00-00
2022-01-21 23:36:28 Version EMH4\@01LZQJL0018E
2022-01-21 16:55:33 state opened
2022-01-21 23:35:54 total_consumption_Ch1.52 543.4
2022-01-21 23:35:53 total_consumption_Ch1.53 577.8
2022-01-21 23:35:53 total_consumption_Ch1.54 636
2022-01-21 23:35:52 total_consumption_Ch1.55 703.8
2022-01-21 23:35:51 total_consumption_Ch1.56 754.6
2022-01-21 23:35:50 total_consumption_Ch1.57 754.6
2022-01-21 23:36:59 total_consumption_Ch1.58 754.6
2022-01-21 23:36:59 total_consumption_Ch1.59 754.6
2022-01-21 23:36:58 total_consumption_Ch1.60 754.6
2022-01-21 23:36:57 total_consumption_Ch1.61 754.6
2022-01-21 23:36:56 total_consumption_Ch1.62 754.6
2022-01-21 23:36:55 total_consumption_Ch1.63 754.6
2022-01-21 23:36:54 total_consumption_Ch1.64 754.6
2022-01-21 23:36:54 total_consumption_Ch1.65 798.6
2022-01-21 23:36:53 total_consumption_Ch1.66 857.5
2022-01-21 23:36:08 total_consumption_Ch2.52 11278.7
2022-01-21 23:36:06 total_consumption_Ch2.53 11607.5
2022-01-21 23:36:06 total_consumption_Ch2.54 12066.5
2022-01-21 23:36:05 total_consumption_Ch2.55 12745
2022-01-21 23:36:04 total_consumption_Ch2.56 13268.2
2022-01-21 23:36:03 total_consumption_Ch2.57 13702
2022-01-21 23:36:02 total_consumption_Ch2.58 14034.2
2022-01-21 23:36:02 total_consumption_Ch2.59 14155.3
2022-01-21 23:36:01 total_consumption_Ch2.60 14181.8
2022-01-21 23:36:00 total_consumption_Ch2.61 14193.6
2022-01-21 23:35:59 total_consumption_Ch2.62 14221.4
2022-01-21 23:35:58 total_consumption_Ch2.63 14267.8
2022-01-21 23:35:57 total_consumption_Ch2.64 14435
2022-01-21 23:35:57 total_consumption_Ch2.65 14803.2
2022-01-21 23:35:56 total_consumption_Ch2.66 15326.8
helper:
BUFFER 1.8.1*57(00
EoM 0
LastPacketTime 1642804619.93231
SPEED 0
SPEED2 0
TRIGGERTIME 1642799546.48599
Channels:
13.25 Momentanwert Leistungsfaktor gesamt
33.25 Momentanwert Leistungsfaktor L1
DEVICES:
/?!
70
000
RULECACHE:
0.0.1 Serial
0.0.2 Serial
0.0.3 Serial
0.0.4 Serial
0.0.5 Serial
0.0.6 Serial
0.0.7 Serial
0.0.8 Serial
0.0.9 Serial
0.1.0 unknown
0.1.2*52 unknown
0.1.2*53 unknown
0.1.2*54 unknown
0.1.2*55 unknown
0.1.2*56 unknown
0.1.2*57 unknown
0.1.2*58 unknown
0.1.2*59 unknown
0.1.2*60 unknown
0.1.2*61 unknown
0.1.2*62 unknown
0.1.2*63 unknown
0.1.2*64 unknown
0.1.2*65 unknown
0.1.2*66 unknown
0.2.0 Channels2
0.2.1*01 unknown
0.2.1*50 unknown
0.2.2 Channels2
0.9.1 unknown
0.9.2 unknown
1.8.1 unknown
1.8.1*52 Counter
1.8.1*53 Counter
1.8.1*54 Counter
1.8.1*55 Counter
1.8.1*56 Counter
1.8.1*57 Counter
1.8.1*58 Counter
1.8.1*59 Counter
1.8.1*60 Counter
1.8.1*61 Counter
1.8.1*62 Counter
1.8.1*63 Counter
1.8.1*64 Counter
1.8.1*65 Counter
1.8.1*66 Counter
1.8.2 unknown
1.8.2*52 Counter
1.8.2*53 Counter
1.8.2*54 Counter
1.8.2*55 Counter
1.8.2*56 Counter
1.8.2*57 Counter
1.8.2*58 Counter
1.8.2*59 Counter
1.8.2*60 Counter
1.8.2*61 Counter
1.8.2*62 Counter
1.8.2*63 Counter
1.8.2*64 Counter
1.8.2*65 Counter
1.8.2*66 Counter
14.25 unknown
31.25 unknown
32.25 unknown
51.25 unknown
52.25 unknown
71.25 unknown
72.25 unknown
C.3 unknown
C.4 unknown
C.5 unknown
C.52.0 unknown
C.7.0 unknown
C.7.1 unknown
C.7.2 unknown
C.7.3 unknown
C.86.1 unknown
directions:
Attributes:
channels {"13.25"=>"Momentanwert Leistungsfaktor gesamt","33.25"=>"Momentanwert Leistungsfaktor L1"}
interval 70
pollingMode on
verbose 0
An den entsprechenden Stellen im Log (verbose 5) steht "DevIo_SimpleWrite Stromzaehler: 063030300d0a". Was bedeutet das?
2022.01.21 22:07:14 5: DevIo_SimpleWrite Stromzaehler: 2f3f210d0a
2022.01.21 22:07:14 4: OBIS (Stromzaehler) - Wrote /?!
2022.01.21 22:07:14 5: OBIS (Stromzaehler) - Internal timer set to 2022-01-21 22:08:54
2022.01.21 22:07:15 5: OBIS (Stromzaehler) - Msg-Parse: /EMH4\@01LZQJL0018E
2022.01.21 22:07:15 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.01.21 22:07:17 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.0(03299851)
2022.01.21 22:07:18 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.1(29400900)
2022.01.21 22:07:18 5: OBIS (Stromzaehler) - Msg 0.0.1(29400900) is of type Serial
2022.01.21 22:07:18 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.2(00267825)
2022.01.21 22:07:18 5: OBIS (Stromzaehler) - Msg 0.0.2(00267825) is of type Serial
2022.01.21 22:07:19 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.3(00000000)
2022.01.21 22:07:19 5: OBIS (Stromzaehler) - Msg 0.0.3(00000000) is of type Serial
2022.01.21 22:07:19 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.4(00000000)
2022.01.21 22:07:19 5: OBIS (Stromzaehler) - Msg 0.0.4(00000000) is of type Serial
2022.01.21 22:07:20 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.5(00000000)
2022.01.21 22:07:20 5: OBIS (Stromzaehler) - Msg 0.0.5(00000000) is of type Serial
2022.01.21 22:07:20 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.6(00000000)
2022.01.21 22:07:20 5: OBIS (Stromzaehler) - Msg 0.0.6(00000000) is of type Serial
2022.01.21 22:07:21 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.7(00000000)
2022.01.21 22:07:21 5: OBIS (Stromzaehler) - Msg 0.0.7(00000000) is of type Serial
2022.01.21 22:07:22 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.8(00000000)
2022.01.21 22:07:22 5: OBIS (Stromzaehler) - Msg 0.0.8(00000000) is of type Serial
2022.01.21 22:07:22 5: OBIS (Stromzaehler) - Msg-Parse: 0.0.9(00000000)
2022.01.21 22:07:22 5: OBIS (Stromzaehler) - Msg 0.0.9(00000000) is of type Serial
2022.01.21 22:07:23 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.0(66)
2022.01.21 22:07:23 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*66(0220101000000)
2022.01.21 22:07:24 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*65(0211201000000)
2022.01.21 22:07:25 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*64(0211101000000)
2022.01.21 22:07:26 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*63(1211001000000)
2022.01.21 22:07:27 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*62(1210901000000)
2022.01.21 22:07:28 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*61(1210801000000)
2022.01.21 22:07:28 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*60(1210701000000)
2022.01.21 22:07:29 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*59(1210601000000)
2022.01.21 22:07:30 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*58(1210501000000)
2022.01.21 22:07:31 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*57(1210401000000)
2022.01.21 22:07:32 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*56(0210301000000)
2022.01.21 22:07:33 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*55(0210201000000)
2022.01.21 22:07:33 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*54(0210101000000)
2022.01.21 22:07:34 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*53(0201201000000)
2022.01.21 22:07:35 5: OBIS (Stromzaehler) - Msg-Parse: 0.1.2*52(0201101000000)
2022.01.21 22:07:36 5: OBIS (Stromzaehler) - Msg-Parse: 0.2.0(23100000)
2022.01.21 22:07:36 5: OBIS (Stromzaehler) - Msg 0.2.0(23100000) is of type Channels2
2022.01.21 22:07:36 5: OBIS (Stromzaehler) - Msg-Parse: 0.2.1*01(12070444)
2022.01.21 22:07:37 5: OBIS (Stromzaehler) - Msg-Parse: 0.2.1*50(090922E2)
2022.01.21 22:07:37 5: OBIS (Stromzaehler) - Msg-Parse: 0.2.2(00000008)
2022.01.21 22:07:37 5: OBIS (Stromzaehler) - Msg 0.2.2(00000008) is of type Channels2
2022.01.21 22:07:38 5: OBIS (Stromzaehler) - Msg-Parse: 0.9.1(0220226)
2022.01.21 22:07:39 5: OBIS (Stromzaehler) - Msg-Parse: 0.9.2(0220121)
2022.01.21 22:07:39 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1(0000897.6*kWh)
2022.01.21 22:07:40 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*66(0000857.5*kWh)
2022.01.21 22:07:40 5: OBIS (Stromzaehler) - Msg 1.8.1*66(0000857.5*kWh) is of type Counter
2022.01.21 22:07:40 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.66 to 857.5
2022.01.21 22:07:41 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*65(0000798.6*kWh)
2022.01.21 22:07:41 5: OBIS (Stromzaehler) - Msg 1.8.1*65(0000798.6*kWh) is of type Counter
2022.01.21 22:07:41 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.65 to 798.6
2022.01.21 22:07:42 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*64(0000754.6*kWh)
2022.01.21 22:07:42 5: OBIS (Stromzaehler) - Msg 1.8.1*64(0000754.6*kWh) is of type Counter
2022.01.21 22:07:42 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.64 to 754.6
2022.01.21 22:07:43 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*63(0000754.6*kWh)
2022.01.21 22:07:43 5: OBIS (Stromzaehler) - Msg 1.8.1*63(0000754.6*kWh) is of type Counter
2022.01.21 22:07:43 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.63 to 754.6
2022.01.21 22:07:44 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*62(0000754.6*kWh)
2022.01.21 22:07:44 5: OBIS (Stromzaehler) - Msg 1.8.1*62(0000754.6*kWh) is of type Counter
2022.01.21 22:07:44 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.62 to 754.6
2022.01.21 22:07:44 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*61(0000754.6*kWh)
2022.01.21 22:07:44 5: OBIS (Stromzaehler) - Msg 1.8.1*61(0000754.6*kWh) is of type Counter
2022.01.21 22:07:44 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.61 to 754.6
2022.01.21 22:07:45 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*60(0000754.6*kWh)
2022.01.21 22:07:45 5: OBIS (Stromzaehler) - Msg 1.8.1*60(0000754.6*kWh) is of type Counter
2022.01.21 22:07:45 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.60 to 754.6
2022.01.21 22:07:46 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*59(0000754.6*kWh)
2022.01.21 22:07:46 5: OBIS (Stromzaehler) - Msg 1.8.1*59(0000754.6*kWh) is of type Counter
2022.01.21 22:07:46 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.59 to 754.6
2022.01.21 22:07:47 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*58(0000754.6*kWh)
2022.01.21 22:07:47 5: OBIS (Stromzaehler) - Msg 1.8.1*58(0000754.6*kWh) is of type Counter
2022.01.21 22:07:47 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.58 to 754.6
2022.01.21 22:07:48 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*57(0000754.6*kWh)
2022.01.21 22:07:48 5: OBIS (Stromzaehler) - Msg 1.8.1*57(0000754.6*kWh) is of type Counter
2022.01.21 22:07:48 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.57 to 754.6
2022.01.21 22:07:48 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*56(0000754.6*kWh)
2022.01.21 22:07:48 5: OBIS (Stromzaehler) - Msg 1.8.1*56(0000754.6*kWh) is of type Counter
2022.01.21 22:07:48 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.56 to 754.6
2022.01.21 22:07:49 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*55(0000703.8*kWh)
2022.01.21 22:07:49 5: OBIS (Stromzaehler) - Msg 1.8.1*55(0000703.8*kWh) is of type Counter
2022.01.21 22:07:49 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.55 to 703.8
2022.01.21 22:07:50 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*54(0000636.0*kWh)
2022.01.21 22:07:50 5: OBIS (Stromzaehler) - Msg 1.8.1*54(0000636.0*kWh) is of type Counter
2022.01.21 22:07:50 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.54 to 636
2022.01.21 22:07:51 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*53(0000577.8*kWh)
2022.01.21 22:07:51 5: OBIS (Stromzaehler) - Msg 1.8.1*53(0000577.8*kWh) is of type Counter
2022.01.21 22:07:51 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.53 to 577.8
2022.01.21 22:07:52 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.1*52(0000543.4*kWh)
2022.01.21 22:07:52 5: OBIS (Stromzaehler) - Msg 1.8.1*52(0000543.4*kWh) is of type Counter
2022.01.21 22:07:52 4: OBIS (Stromzaehler) - Set total_consumption_Ch1.52 to 543.4
2022.01.21 22:07:53 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2(0015667.3*kWh)
2022.01.21 22:07:53 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*66(0015326.8*kWh)
2022.01.21 22:07:53 5: OBIS (Stromzaehler) - Msg 1.8.2*66(0015326.8*kWh) is of type Counter
2022.01.21 22:07:53 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.66 to 15326.8
2022.01.21 22:07:54 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*65(0014803.2*kWh)
2022.01.21 22:07:54 5: OBIS (Stromzaehler) - Msg 1.8.2*65(0014803.2*kWh) is of type Counter
2022.01.21 22:07:54 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.65 to 14803.2
2022.01.21 22:07:55 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*64(0014435.0*kWh)
2022.01.21 22:07:55 5: OBIS (Stromzaehler) - Msg 1.8.2*64(0014435.0*kWh) is of type Counter
2022.01.21 22:07:55 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.64 to 14435
2022.01.21 22:07:56 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*63(0014267.8*kWh)
2022.01.21 22:07:56 5: OBIS (Stromzaehler) - Msg 1.8.2*63(0014267.8*kWh) is of type Counter
2022.01.21 22:07:56 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.63 to 14267.8
2022.01.21 22:07:57 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*62(0014221.4*kWh)
2022.01.21 22:07:57 5: OBIS (Stromzaehler) - Msg 1.8.2*62(0014221.4*kWh) is of type Counter
2022.01.21 22:07:57 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.62 to 14221.4
2022.01.21 22:07:57 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*61(0014193.6*kWh)
2022.01.21 22:07:57 5: OBIS (Stromzaehler) - Msg 1.8.2*61(0014193.6*kWh) is of type Counter
2022.01.21 22:07:57 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.61 to 14193.6
2022.01.21 22:07:59 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*60(0014181.8*kWh)
2022.01.21 22:07:59 5: OBIS (Stromzaehler) - Msg 1.8.2*60(0014181.8*kWh) is of type Counter
2022.01.21 22:07:59 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.60 to 14181.8
2022.01.21 22:07:59 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*59(0014155.3*kWh)
2022.01.21 22:07:59 5: OBIS (Stromzaehler) - Msg 1.8.2*59(0014155.3*kWh) is of type Counter
2022.01.21 22:07:59 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.59 to 14155.3
2022.01.21 22:08:00 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*58(0014034.2*kWh)
2022.01.21 22:08:00 5: OBIS (Stromzaehler) - Msg 1.8.2*58(0014034.2*kWh) is of type Counter
2022.01.21 22:08:00 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.58 to 14034.2
2022.01.21 22:08:01 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*57(0013702.0*kWh)
2022.01.21 22:08:01 5: OBIS (Stromzaehler) - Msg 1.8.2*57(0013702.0*kWh) is of type Counter
2022.01.21 22:08:01 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.57 to 13702
2022.01.21 22:08:02 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*56(0013268.2*kWh)
2022.01.21 22:08:02 5: OBIS (Stromzaehler) - Msg 1.8.2*56(0013268.2*kWh) is of type Counter
2022.01.21 22:08:02 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.56 to 13268.2
2022.01.21 22:08:03 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*55(0012745.0*kWh)
2022.01.21 22:08:03 5: OBIS (Stromzaehler) - Msg 1.8.2*55(0012745.0*kWh) is of type Counter
2022.01.21 22:08:03 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.55 to 12745
2022.01.21 22:08:03 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*54(0012066.5*kWh)
2022.01.21 22:08:03 5: OBIS (Stromzaehler) - Msg 1.8.2*54(0012066.5*kWh) is of type Counter
2022.01.21 22:08:03 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.54 to 12066.5
2022.01.21 22:08:04 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*53(0011607.5*kWh)
2022.01.21 22:08:04 5: OBIS (Stromzaehler) - Msg 1.8.2*53(0011607.5*kWh) is of type Counter
2022.01.21 22:08:04 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.53 to 11607.5
2022.01.21 22:08:05 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.2*52(0011278.7*kWh)
2022.01.21 22:08:05 5: OBIS (Stromzaehler) - Msg 1.8.2*52(0011278.7*kWh) is of type Counter
2022.01.21 22:08:05 4: OBIS (Stromzaehler) - Set total_consumption_Ch2.52 to 11278.7
2022.01.21 22:08:06 5: OBIS (Stromzaehler) - Msg-Parse: 14.25(49.96*Hz)
2022.01.21 22:08:06 5: OBIS (Stromzaehler) - Msg-Parse: 31.25(3.274*A)
2022.01.21 22:08:07 5: OBIS (Stromzaehler) - Msg-Parse: 51.25(0.010*A)
2022.01.21 22:08:07 5: OBIS (Stromzaehler) - Msg-Parse: 71.25(0.015*A)
2022.01.21 22:08:08 5: OBIS (Stromzaehler) - Msg-Parse: 32.25(234.12*V)
2022.01.21 22:08:08 5: OBIS (Stromzaehler) - Msg-Parse: 52.25(235.24*V)
2022.01.21 22:08:09 5: OBIS (Stromzaehler) - Msg-Parse: 72.25(236.17*V)
2022.01.21 22:08:09 5: OBIS (Stromzaehler) - Msg-Parse: 33.25(0.91*P/S)
2022.01.21 22:08:09 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.01.21 22:08:10 5: OBIS (Stromzaehler) - Msg-Parse: 53.25(0.00*P/S)
2022.01.21 22:08:10 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.01.21 22:08:11 5: OBIS (Stromzaehler) - Msg-Parse: 73.25(0.00*P/S)
2022.01.21 22:08:11 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.01.21 22:08:11 5: OBIS (Stromzaehler) - Msg-Parse: 13.25(0.90*P/S)
2022.01.21 22:08:11 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.01.21 22:08:12 5: OBIS (Stromzaehler) - Msg-Parse: C.3(00000000)
2022.01.21 22:08:12 5: OBIS (Stromzaehler) - Msg-Parse: C.4(00A00040)
2022.01.21 22:08:13 5: OBIS (Stromzaehler) - Msg-Parse: C.5(0020F4F0)
2022.01.21 22:08:13 5: OBIS (Stromzaehler) - Msg-Parse: C.52.0(3)
2022.01.21 22:08:14 5: OBIS (Stromzaehler) - Msg-Parse: C.86.1(00000000)
2022.01.21 22:08:14 5: OBIS (Stromzaehler) - Msg-Parse: C.7.0(0006)
2022.01.21 22:08:15 5: OBIS (Stromzaehler) - Msg-Parse: C.7.1(0001)
2022.01.21 22:08:15 5: OBIS (Stromzaehler) - Msg-Parse: C.7.2(0001)
2022.01.21 22:08:15 5: OBIS (Stromzaehler) - Msg-Parse: C.7.3(0000)
2022.01.21 22:08:16 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00000000)
2022.01.21 22:08:16 5: OBIS (Stromzaehler) - Msg-Parse: !
Hier noch eine sehr umfangreiche Dokumentation des Stromzählers: https://downloads.nzr.de/wp-content/uploads/2021/05/LZQJ-XC_PHB_Stand_072020.pdf (https://downloads.nzr.de/wp-content/uploads/2021/05/LZQJ-XC_PHB_Stand_072020.pdf)
Gruß
Hallo Zusammen,
nach langer Zeit habe ich mal wieder ein Update durchgeführt und danach leider folgende Probleme bei meinen OBIS-Zählern.
Beim Start von FHEM erhalte ich zunächst die Fehlermeldungen mit "Unknown Message: ..." und anschließend wird mir mein Log vollgeschrieben mit der Zeile: "2nd TL-byte != 0, reserved according spec".
Verbose habe ich jetzt erst einmal auf 2 gestellt, das ist aber sicher auf Dauer keine Lösung.
Danke schon mal für Unterstützung
Holger
2022.01.24 10:29:17 3: OBIS (sm.Heizungskeller) - Unknown Message: 1-0:96.1.0*255(HLYMv)
2022.01.24 10:29:17 3: OBIS (sm.Heizungskeller) - Unknown Message: 1-0:0.2.0*0(1.02.007)
2022.01.24 10:29:17 3: OBIS (sm.Heizungskeller) - Unknown Message: 1-0:96.90.2*1(A01A)
2022.01.24 10:29:17 3: OBIS (sm.Heizungskeller) - Unknown Message: 1-0:96.5.0*255(1841412)
2022.01.24 10:29:17 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:17 3: OBIS (sm.Vorratskeller) - Unknown Message: 1-0:96.1.0*255(HLYMm)
2022.01.24 10:29:17 3: OBIS (sm.Vorratskeller) - Unknown Message: 1-0:0.2.0*0(1.02.007)
2022.01.24 10:29:17 3: OBIS (sm.Vorratskeller) - Unknown Message: 1-0:96.90.2*1(A01A)
2022.01.24 10:29:17 3: OBIS (sm.Vorratskeller) - Unknown Message: 1-0:96.5.0*255(1839364)
2022.01.24 10:29:19 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:20 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:29 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:30 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:39 3: 2nd TL-byte != 0, reserved according spec
2022.01.24 10:29:39 3: 2nd TL-byte != 0, reserved according spec
Und die Definition meiner Devices:
Internals:
CRC_Errors 4
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D308BMGU-if00-port0@@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D308BMGU-if00-port0@@9600,8,N,1
FD 9
FUUID 5ef72506-f33f-30fc-feb1-50cb5737f791fd36
MeterType SML
NAME sm.Heizungskeller
NR 38
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2022-01-24 10:55:39 ManufID2 HLY
2022-01-24 10:55:39 current_L1 1.18
2022-01-24 10:55:39 current_L2 0.68
2022-01-24 10:55:39 current_L3 0.68
2022-01-24 10:55:39 power -242
2022-01-24 10:28:57 state opened
2022-01-24 10:55:39 total_consumption 6222
2022-01-24 10:55:39 total_feed 29304271.2
2022-01-24 10:55:39 voltage_L1 220.2
2022-01-24 10:55:39 voltage_L2 220.3
2022-01-24 10:55:39 voltage_L3 220.6
helper:
BUFFER
DIRECTIONSUM <
EoM 1
HLYHACK 1
LastPacketTime 1643018139.15934
SPEED
SPEED2
TRIGGERTIME 1643016537.71384
Channels:
DEVICES:
10
RULECACHE:
1-0:0.2.0*0 unknown
1-0:1.8.0*255 Counter
1-0:14.7.0*255 Channels
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:31.7.0*255 Channels
1-0:32.7.0*255 Channels
1-0:51.7.0*255 Channels
1-0:52.7.0*255 Channels
1-0:71.7.0*255 Channels
1-0:72.7.0*255 Channels
1-0:81.7.1*255 Channels
1-0:81.7.15*255 Channels
1-0:81.7.2*255 Channels
1-0:81.7.26*255 Channels
1-0:81.7.4*255 Channels
1-0:96.1.0*255 unknown
1-0:96.5.0*255 unknown
1-0:96.50.1*1 ManufID2
1-0:96.90.2*1 unknown
directions:
Attributes:
event-on-change-reading .*
event-on-update-reading .*
icon measure_power_meter
ignoreUnknown on
interval 10
pollingMode on
room Smartmeter
verbose 2
Internals:
CRC_Errors 5
DEF /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D307MAKR-if00-port0@@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D307MAKR-if00-port0@@9600,8,N,1
FD 8
FUUID 5e85ea23-f33f-30fc-325e-f2be200efd94d15b
MeterType SML
NAME sm.Vorratskeller
NR 37
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2022-01-24 10:56:20 ManufID2 HLY
2022-01-24 10:56:20 current_L1 1.29
2022-01-24 10:56:20 current_L2 2.06
2022-01-24 10:56:20 current_L3 1.96
2022-01-24 10:56:20 power 338
2022-01-24 10:28:57 state opened
2022-01-24 10:56:20 total_consumption 1983288
2022-01-24 10:56:20 total_feed 20507330
2022-01-24 10:56:20 voltage_L1 220.3
2022-01-24 10:56:20 voltage_L2 220.7
2022-01-24 10:56:20 voltage_L3 220.6
helper:
BUFFER
DIRECTIONSUM >
EoM 1
HLYHACK 1
LastPacketTime 1643018180.26624
SPEED
SPEED2
TRIGGERTIME 1643016537.70134
Channels:
DEVICES:
10
RULECACHE:
1-0:0.2.0*0 unknown
1-0:1.8.0*255 Counter
1-0:14.7.0*255 Channels
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:31.7.0*255 Channels
1-0:32.7.0*255 Channels
1-0:51.7.0*255 Channels
1-0:52.7.0*255 Channels
1-0:71.7.0*255 Channels
1-0:72.7.0*255 Channels
1-0:81.7.1*255 Channels
1-0:81.7.15*255 Channels
1-0:81.7.2*255 Channels
1-0:81.7.26*255 Channels
1-0:81.7.4*255 Channels
1-0:96.1.0*255 unknown
1-0:96.5.0*255 unknown
1-0:96.50.1*1 ManufID2
1-0:96.90.2*1 unknown
directions:
Attributes:
event-on-change-reading .*
event-on-update-reading .*
icon measure_power_meter
ignoreUnknown on
interval 10
pollingMode on
room Smartmeter
verbose 2
Hallo,
immer wenn mein wert (einspeissung) über ca. -700W geht habe ich abnormale Werte grösser als 16000W !!!???
Das - Zeichen wird auch nicht angezeigt wobei ich das mit einem Userreading hinbekommen habe.
Hier noch zum vergleich aus meine Logfile.
zuerst der extrem hohe Wert.
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: /
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(DZGx*var)
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(<8719694.2*Wh)
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(1038728.9*Wh)
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(166651.37*W)
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(166651.37*W) is of type Channels
2022.02.17 13:45:36 5: OBIS (Stromzaehler) - Msg-Parse: !
2022.02.17 13:45:37 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176052099A009620062007263010176010102310B0A01445A47000394C2787262016505228C396202639E640076052199A009620062007263070177010B0A01445A47000394C278070100620AFFFF7262016505228C397577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A47000394C2780177070100010800FF641C39047262016200621E52FF650532850E0177070100020800FF017262016200621E52FF649E7F5C0177070100100700FF017262016200621B52FE54FDEF7C01010163DD930076052299A00962006200726302017101638C9800001B1B1B1B1A010B61
2022.02.17 13:45:37 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176052099A009620062007263010176010102310B0A01445A47000394C2787262016505228C396202639E640076052199A009620062007263070177010B0A01445A47000394C278070100620AFFFF7262016505228C397577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A47000394C2780177070100010800FF641C39047262016200621E52FF650532850E0177070100020800FF017262016200621E52FF649E7F5C0177070100100700FF017262016200621B52FE54FDEF7C01010163DD930076052299A00962006200726302017101638C9800001B1B1B1B1A010B61
2022.02.17 13:45:37 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZGx*var)
1-0:1.8.0*255(<8719694.2*Wh)
1-0:2.8.0*255(1038729.2*Wh)
1-0:16.7.0*255(166419.16*W)
!
jetzt wen ich unter ca. 700W einspeissung bin.
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: /
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(DZGx*var)
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(<8719277.5*Wh)
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(1037901.1*Wh)
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(558.2*W)
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(558.2*W) is of type Channels
2022.02.17 10:59:17 5: OBIS (Stromzaehler) - Msg-Parse: !
2022.02.17 10:59:17 1: PERL WARNING: Useless use of a constant ("%.0f kWh") in void context at (eval 668) line 1.
2022.02.17 10:59:17 3: eval: "Einspeisung: ".sprintf("%.0f kWh", (ReadingsVal($name,"2.8.0_Einspeisung",0) / 1000) ) ." | Bezug: ".("%.0f kWh",(ReadingsVal($name,"1.8.0_Verbrauch",0))) . " | aktuelle Leistung: ". sprintf("%.0f W", ReadingsVal($name,"aktuelle_Leistung",0))
2022.02.17 10:59:18 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B0101010176052F24A009620062007263010176010102310B0A01445A47000394C278726201650522653D620263071C0076053024A009620062007263070177010B0A01445A47000394C278070100620AFFFF726201650522653D7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A47000394C2780177070100010800FF641C39047262016200621E52FF65053274C70177070100020800FF017262016200621E52FF649E5F030177070100100700FF017262016200621B52FE53DC0D0101016329800076053124A0096200620072630201710163C6DA0000001B1B1B1B1A023B75
2022.02.17 10:59:18 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B0101010176052F24A009620062007263010176010102310B0A01445A47000394C278726201650522653D620263071C0076053024A009620062007263070177010B0A01445A47000394C278070100620AFFFF726201650522653D7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A47000394C2780177070100010800FF641C39047262016200621E52FF65053274C70177070100020800FF017262016200621E52FF649E5F030177070100100700FF017262016200621B52FE53DC0D0101016329800076053124A0096200620072630201710163C6DA0000001B1B1B1B1A023B75
2022.02.17 10:59:18 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZGx*var)
1-0:1.8.0*255(<8719277.5*Wh)
1-0:2.8.0*255(1037901.1*Wh)
1-0:16.7.0*255(563.33*W)
!
Hat hier villeich jemand eine Idee?
Danke schonmal im vorraus.
Zitat if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) {
$tltype = 0x60;
}
Genau diese Stelle scheint sich bei Dir zu rächen: Weil es ein DZG-Zähler ist, der "signed" sagt, eine kurze Länge hat (< 4), es um das Werte-Feld und OBIS-Zahl 1.0.16.7.0 geht ("if"-Statement in Worten), macht der Code aus dem int ein unsigned int und damit die hohe Zahl.
Den Hack habe ich vor 1-2 Jahren eingebaut, findest Du früher hier im Thread. Vorschlag: Kommentiere diese 3 Zeilen mal aus, und gucke, ob Du damit definitiv glücklicher bist. (FHEM neu starten o.ä. ist natürlich nötig, damit das Auskommentieren oder Löschen wirksam wird). Sollte DZG Zähler in Umlauf gesetzt haben, die den Bug nicht mehr haben, dann würde ich den Hack nicht fest verdrahten, sondern "wegkonfigurierbar" machen.
Also: Schuld ist ein alter Fehler in den DZG-Zählern. Vielleicht ist er inzwischen behoben.
So funktioniert es bis jetzt bei mir auch habe ich dann doch nach einmal schlafen auf der Seite 90 gefunden.
Manchmal ist es halt doch besser auf der letzten Seite anfangen zu lesen ;)
Jetzt steht es m.E. 2:2 (2 DZG-Zähler mit Problem ohne Patch, 2 DZG-Zähler, die damit in Probleme kommen).
Vermutlich sollte ich den Hack als "automatisch einschaltend" ausbauen, und zu einer manuellen Option machen.
Erstmal vielen Dank für das tolle Modul und die Arbeit; als Feedback wollte ich melden, dass auch ich seit Juli 2021 einen DZG-Zähler besitze und diesen jetzt auch endlich elektronisch erfassen wollte. Auch ich hatte diese komischen Ausreißer von ca. 166 KW Bezug, wenn es in den Negativbereich rutschte bzw. positive Werte um ca. 300-500 Watt, obwohl am Zähler ca. -300 Watt standen. Mit dem Auskommentieren der 3 Zeilen ist aber jetzt alles gut :-)
Hallo,
mein Zähler wurde getauscht (ED300L).
Zähler ist der gleiche wie vorher.
Was nun fehlt ist das reading dir_total_feed.
Vorher lief das. Gibts etwas zu beachten?
Danke!
Wofür soll das nötig sein?
total_feed = Wh eingespeist
total_consumption = Wh bezogen
M.E. kann es nur so sinnvoll wie ein "Plus" bei positiven Zahlen gewesen sein. Wirklich wichtig ist ja "power" für die Steuerung von Verbrauchern bei PV, sowie eben die beiden total_-Werte als absolute Zählerstände.
Ich habe via USB einen Infrarotkopf (cp2102) an meinen Stromzähler (EFR SGM-DD (https://digimeto.de/wps/wcm/connect/digimeto/a7c0814f-550e-4387-9a73-69bd36a7296c/DIGImeto_efr_SGM-DD_Bedienungsanleitung_lang_Web.pdf?MOD=AJPERES&CVID=n2HdSYL)) angeschlossen.
Die dSS Infoschnittstelle (siehe Kap. 13.1) funktioniert. Ich bekomme die Gesamwerte für Verbrauch und Einspeisung.
Bei der D0-Dialogschnittstelle komme ich nicht weiter, wenn ich diese im Zähler anstatt dSS aktiviere. Mittels dem Tool HTerm konnte ich in Windows zu Testzwecken über die verschiedenen Baudraten senden und empfangen. Damit konnte ich z.B. die Hex-Daten "2F 3F 21 0D 0A" übertragen und bekam den Hersteller zurückgeliert. Ich würde gerne wie in der Doku 13.2 die Vorwerte nach FHEM auslesen. Irgendwie komme ich aber nicht klar und verstehe nicht, wie man die spezifischen Kommandos aus FHEM sendet und die Start- und Kommunikationsbaudraten wechselt. Muss ich da zwei Devices mit verschiedenen Spezifikationen anlegen?
Hier mein Device mit der Startbaudrate. Wie kann ich das mit dem OBIS-Modul umsetzen?
Internals:
DEF /dev/ttyUSB3@9600,7,E,1 SML
DeviceName /dev/ttyUSB3@9600,7,E,1
FD 16
FUUID 623c8b1f-f33f-8b20-8d99-ea29cd21b9dac621
MeterType SML
NAME test
NR 65494
PARTIAL
STATE opened
TYPE OBIS
READINGS:
2022-03-24 16:25:13 state opened
helper:
EoM -1
SPEED 5
SPEED2 5
TRIGGERTIME 1648135513.61469
DEVICES:
5
RULECACHE:
Attributes:
interval 5
pollingMode on
verbose 5
Die Betriebsart "dSS-Info" ist die Richtige: Einfach "Read-Only" mit 9600 Baud.
Es *sollte* auch der Momentanwert ankommen, falls das nicht der Fall ist und / oder die Zählerstände sehr ungenau sind, ist nach meiner Erfahrung die PIN noch nicht "reingemorst" worden.
Zitat von: gvzdus am 24 März 2022, 17:06:41
Die Betriebsart "dSS-Info" ist die Richtige: Einfach "Read-Only" mit 9600 Baud.
Es *sollte* auch der Momentanwert ankommen, falls das nicht der Fall ist und / oder die Zählerstände sehr ungenau sind, ist nach meiner Erfahrung die PIN noch nicht "reingemorst" worden.
Sorry, ja der Momentanwert kommt natürlich auch. Also kann OBIS mit dem D0-Mode nichts anfangen und ich kann darüber die historischen Werte nicht auslesen?
Nein! Das OBIS-Modul ist rein SML.
Hey, für Historie in DIY gibt es doch FHEM :-)
Bei mir werden z.B. in 5min, 1h und Tagesrythmen die Werte vom OBIS-Device in Dummy-Devices kopiert und per Filelog "auf Ewig" auf die "Platte" gebannt.
Vielen Dank. Die Schnittstelle mit ihren Unterschieden dSS und D0 war mir nicht bekannt. Dachte beides sendet dieses SML-Format. Du hast mich auf ein neues Level gehoben. :-)
Selbstverständlich historisiere ich mit FHEM, allerdings mit DbLog und nicht FileLog. ;-)
Hallo,
ich bräuchte Hilfe beim Auslesen von meinen Holley DTZ541 Zählern. Beide Zähler funktionieren eigentlich mit einem kleinen CRC-Hack seit Jahren. Seit letzter Woche liefert mein zweiter Zähler (2-Tarifzähler mit HT/NT) überhaupt keine Daten mehr. Der andere Zähler (normalStrom) funktioniert ohne Probleme.
Folgende Ausgabe erhalte ich beim Starten, sieht soweit gut aus:
2022.03.28 17:53:54 3: Opening normalStrom device /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DCF91-if00-port0
2022.03.28 17:53:54 3: Setting normalStrom serial parameters to 9600,8,N,1
2022.03.28 17:53:54 3: OBIS (normalStrom) - Init done
2022.03.28 17:53:54 3: normalStrom device opened
2022.03.28 17:53:54 3: OBIS (normalStrom) - Attr interval Val 30, dopoll =
2022.03.28 17:53:54 3: Opening heizungStrom device /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DD6D7-if00-port0
2022.03.28 17:53:54 3: Setting heizungStrom serial parameters to 9600,8,N,1
2022.03.28 17:53:54 3: OBIS (heizungStrom) - Init done
2022.03.28 17:53:54 3: heizungStrom device opened
2022.03.28 17:53:54 3: OBIS (heizungStrom) - Attr interval Val 30, dopoll =
Verbose natürlich auf 5 und erhalte normalerweise nur permanent diese Meldung:
2022.03.28 17:56:42 3: 2nd TL-byte != 0, reserved according spec
Ich habe mal einige Log-Statements im Modul einkommentiert:
2022.03.28 17:56:41 3: OBIS_Parse_List : Scan for 6 element
2022.03.28 17:56:41 3: OBIS_Parse_List : Scan for 2 element
2022.03.28 17:56:41 3: OBIS_Parse_List : Scan for 1 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 9999 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 6 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 2 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 6 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 6 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 2 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 7 element
2022.03.28 17:56:42 3: 2nd TL-byte != 0, reserved according spec
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 20 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 7 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 7 element
... <wiederholt sich hier immer wieder>
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 7 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 6 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 2 element
2022.03.28 17:56:42 3: OBIS_Parse_List : Scan for 1 element
2022.03.28 17:56:42 5: OBIS (heizungStrom) - OBIS_Read called, hash is HASH(0x176c5c8)
2022.03.28 17:56:42 5: OBIS (heizungStrom) - OBIS_Read gave 3
2022.03.28 17:56:42 5: OBIS (heizungStrom) - EoM is -1
Ansonsten habe ich das Device neu angelegt, Info Schnittstelle am Zähler nochmal gecheckt. Keine Ahnung was hier nicht stimmt.
Hoffe hier hat noch jemand eine Idee.
Danke und Gruß
Jaykoert
Puh, das war jetzt irgendwie mal wieder ein doofer Fehler. Bei meinem Zähler sind unten so 2 Buckel, wo man den Lesekopf aufsetzen kann, aber scheinbar liest er nur, wenn zwischen diesen Buckeln ca. 1mm Luft ist und somit der Lesekopf etwas höher sitzt.
Noch schnell einen zweiten Strich von der Seite an den Lesekopf und den Zähler gemacht, damit ich beim nächsten Mal schneller sehe wo er wirklich sitzen muss.
Könntest Du bitte:
- Nach einem Backup auf die aktuelle Version von 47_OBIS gehen
- Auf verbose 5 mir ein paar Zeilen des "Full message->" (auf verbose 5 ersichtlich) schicken? Ich habe eine Debug-Routine, die genau diese Zeilen einliest und neu verarbeitet
Hallo zusammen,
Seit kurzem besitze ich einen elektronischen Zähler DD3 2R06 DTA-SMZ1 und einen Hichi IR wifi Lesekopf mit ESP8266.
Der Lesekopf sendet die ausgelesenen Daten über WLAN in mein Heimnetz, die mittels Tasmota auf dem Bildschirm sichtbar sind. Es wird also etwas gesendet.
Diese Daten möchte ich in das Modul 47_OBIS einlesen und auswerten.
Gebe ich zur Erstellung eines Devices in die Komandozeile ein "define myOBIS OBIS 192.168.0.21:80 SML" , wird eine Verbindung zum Lesekopf aufgebaut, die aber sofort wieder getrennt wird. Das wiederholt sich ca. alle 5 Sekunden. Das DeviceOverview zeigt:
Zitat
DeviceOverview
myobis disconnected
get myobis update
Internals
CFGFN
DEF 192.168.0.21:80 SML
DeviceName 192.168.0.21:80
FUUID 6246c6b7-f33f-f2de-8741-f835ed59decfff03
MeterType SML
NAME myobis
NEXT_OPEN 1648824034.42938
NR 829
PARTIAL
STATE disconnected
TYPE OBIS
Readings
state disconnected 2022-04-01 16:39:34
attr myobis room PowerMeter
Attributes
room PowerMeter deleteattr
Das Logfile sieht so aus:
Zitat2022.04.01 16:29:55 3: Opening myobis device 192.168.0.21:80
2022.04.01 16:29:55 3: OBIS (myobis) - Init done
2022.04.01 16:29:55 3: myobis device opened
2022.04.01 16:30:00 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:00 3: OBIS (myobis) - Init done
2022.04.01 16:30:00 1: 192.168.0.21:80 reappeared (myobis)
2022.04.01 16:30:06 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:06 3: OBIS (myobis) - Init done
2022.04.01 16:30:06 1: 192.168.0.21:80 reappeared (myobis)
2022.04.01 16:30:11 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:11 3: OBIS (myobis) - Init done
2022.04.01 16:30:11 1: 192.168.0.21:80 reappeared (myobis)
2022.04.01 16:30:16 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:16 3: OBIS (myobis) - Init done
2022.04.01 16:30:16 1: 192.168.0.21:80 reappeared (myobis)
2022.04.01 16:30:21 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:21 3: OBIS (myobis) - Init done
2022.04.01 16:30:21 1: 192.168.0.21:80 reappeared (myobis)
2022.04.01 16:30:26 1: 192.168.0.21:80 disconnected, waiting to reappear (myobis)
2022.04.01 16:30:26 3: OBIS (myobis) - Init done
2022.04.01 16:30:26 1: 192.168.0.21:80 reappeared (myobis)
Welche Parameter und Befehle muß ich hinzufügen, damit ich die Daten in OBIS verarbeiten können? Gibt es irgendwo eine Beispielkonfiguration, wo ich sehen kann, wie ich mein Device einrichten kann?
Ich würde mich freuen, wenn mir jemand weiterhelfen würde. Vielen Dank im Voraus
Harald
Ich kenne jetzt Deine Tasmota-Konfiguration nicht. Grundsätzlich wird ja auf Port 80 eher HTTP gesprochen. Du brauchst aber eher eine "Dauerverbindung".
Sprich, wenn Du am Raspi:
telnet 192.168.0.21 <port>
eingibst, müsste die Verbindung stehen bleiben, und im fröhlichen Sekundentakt o.ä. der Bildschirm mit Binärblöcken zugemüllt werden. Wenn Du so weit bist, dann sollte auch der define wie Du ihn verwendet hast, funktionieren.
Hallo
Ich habe diese Woche meinen Zähler erfolgreich in Betrieb genommen, momentan muss ich jedoch den Umweg über vzlogger und HTTPMOD via JSON gehen, da das OBIS Modul m.W. leider ein Wechsel der Baudrate (noch) nicht unterstützt und die Auslesung dann zu lange dauert.
Aber erst mal vielen Dank für das Modul, es funktioniert auch direkt super, eben mit dem kleinen Einschränkung bez. des Speed's.
Ich hab mir mal versucht den Code kurz anzusehen und meine ANzeichen davon gesehen zu haben, dass ein Wechsel der Lesegeschwindigkeit nach dem initialen Pull-String senden angedacht aber wohl noch nicht fertig implementiert ist. Stimmt dem so?
Eigentlich könnte man ja fix den max. möglichen Speed welcher der Zähler auf die /?! Initialisierung antwortet verwenden anstatt einfach in der "minimalen" Geschwindigkeit weitermachen.
Leider bin ich perl-technisch nicht so versiert, dass ich direkt einen Änderungsvorschlag machen könnte...
Wenn es also möglich wäre, einen solchen speed-change einzubauen (via Attribut, automatisch oder per config/set) wäre super!!
Nochmals vielen dank und Grüsse aus der CH
STefan
Hallo gvzdus,
danke für den Hinweis, aber auf dem Tasmota-Lesekopf scheint kein Telnet zu laufen. Der Raspi kann keine Verbindung herstellen.
Hier meine Parameter auf dem Lesekopf
Sonoff Basic
Tasmota
Program Version 9.5.0(tasmota)
Build Date & Time 2021-11-08T00:56:32
Core/SDK Version 2_7_4_9/2.2.2-dev(38a443e)
Uptime 0T00:12:31
Flash write Count 12 at 0xF8000
Boot Count 4
Restart Reason Software/System restart
Friendly Name 1 Tasmota
AP1 SSId (RSSI) DK9JH (76%, -62 dBm) 11n
Hostname tasmota_0C0F99-3993
MAC Address 4C:75:25:0C:0F:99
IP Address (wifi) 192.168.0.21
Gateway 192.168.0.1
Subnet Mask 255.255.255.0
DNS Server 192.168.0.1
MQTT Host Lesekopf
MQTT Port 1883
MQTT User DVES_USER
MQTT Client DVES_0C0F99
MQTT Topic tasmota_%06X
MQTT Group Topic 1 cmnd/tasmotas/
MQTT Full Topic cmnd/tasmota_0C0F99/
MQTT Fallback Topic cmnd/DVES_0C0F99_fb/
MQTT No Retain Disabled
Emulation None
ESP Chip Id 90425 (ESP8266EX)
Flash Chip Id 0x14325E
Flash Size 1024 kB
Program Flash Size 1024 kB
Program Size 635 kB
Free Program Spac 368 kB
Free Memory 21.7 kB
Ich habe bisher viele Sachen wie MQTT, MQTT2, OBIS u.a. ausprobiert sowie verzweifelt eine Beispielkonfiguration gesucht, aber alles ohne Erfolg.
Ich habe div. Devices angelegt, die nicht funktioniert haben. Wäre toll, wenn mir jemand helfen würde, damit ich die Daten des Lesekopfes in FHEM verarbeiten könnte.
Herzlichen Dank im Voraus und viele Grüße
Harald
Moin, hoffe, dass jemand was schreibt, der Tasmota nutzt.
Mit etwas Googlen würde ich sagen: "Du musst bei Tasmota dumpf 'serial to network' konfigurieren: Das Serial-IO per TCP rausreichen - ohne jede Intelligenz oder Dekodierung". Übrigens schon eine Warnung: Bei dieser Betriebsart entsteht in FHEM ziemlich viel CPU-Last, weil wirklich jedes Byte einzeln verarbeitet wird. Es geht aber.
Dank für die Antwort,
soweit ich das bis jetzt verstehe, überträgt Tasmota die Daten mittels MQTT. In FHEM gibt es ja MQTT2. Damit sollte es eigentlich machbar sen. Ich habe nur noch nicht gefunden, wie und welches Device in FHEM erstellt werden muß, damit das klappt. Vielleicht gibt es hier ja jemand, der oder die schon so etwas laufen hat und mir Tipps geben kann?
Viele Grüße
Harald
Zitat von: Harald am 05 April 2022, 12:06:53
Dank für die Antwort,
soweit ich das bis jetzt verstehe, überträgt Tasmota die Daten mittels MQTT. In FHEM gibt es ja MQTT2. Damit sollte es eigentlich machbar sen. Ich habe nur noch nicht gefunden, wie und welches Device in FHEM erstellt werden muß, damit das klappt. Vielleicht gibt es hier ja jemand, der oder die schon so etwas laufen hat und mir Tipps geben kann?
Viele Grüße
Harald
Hallo Harald,
ich nutze zwar nicht Tasmota, aber ich versuche mal zu helfen ;o)
Du mußt einen MQTT2 Server anlegen, dieser empfängt die MQTT-Nachrichten von den Devices (z.B. Deinem Zähler) und leitet sie dann an ein MQTT2 Device weiter.
Du müsstest z.B. mit:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 globaleinen MQTT2 Server anlegen.
Damit sollte das MQTT2-Device für Deinen Zähler beim einschalten des Tasmota Lesekopfes automatisch in fhem erstellt werden.
Somit brauchst Du das OBIS-Modul gar nicht, diese Arbeit erledigt schon Tasmota ;o)
Gruß Thomas
Hallo Thomas,
vielen Dank für die Antwort. Das Device habe ich erstellt. Aber ich habe noch nicht gefunden, wie ich die vom Lesekopf gesendeten Daten dort einlesen kann. Welche Perameter sind dazu erforderlich. Die Angaben in der Commandref verstehe ich leider nicht. Kannst du mir da weiterhelfen?
So sieht das Device z.Z. aus
Vielen Dank im Voraus
Harald
Zitat von: Harald am 09 April 2022, 13:25:17
Hallo Thomas,
vielen Dank für die Antwort. Das Device habe ich erstellt. Aber ich habe noch nicht gefunden, wie ich die vom Lesekopf gesendeten Daten dort einlesen kann. Welche Perameter sind dazu erforderlich. Die Angaben in der Commandref verstehe ich leider nicht. Kannst du mir da weiterhelfen?
So sieht das Device z.Z. aus
Vielen Dank im Voraus
Harald
Hallo Harald,
der MQTT2 Server in fhem sieht schon mal gut aus.
Nur das "allowfrom" und "autocreate" mußt Du löschen, brauchst Du nicht.
Jetzt mußt Du Deinem Tasmota noch sagen, wie der MQTT-Server heißt ;o)
Da müßte es unter "Einstellungen" entsprechende Menüpunkte geben, z.B.:
"Host" hier die IP-Adresse deines FHEM-Rechners (192.168.0.xxx) eintragen, da steht bei Dir "Lesekopf"
"Port" hier den von Dir definierten Port 2883 eintragen, bei Dir steht der Standard Port 1883 drin.
"User" und "Password" bleiben leer
Gruß Thomas
Hallo Harald,
hab noch ein bischen darüber nachgedacht, vielleicht hab ich es nicht gut beschrieben, deshalb nochmal etwas anders:
Das Ganze im Überblick:
Der Lesekopf verbindet sich mit dem MQTT2-Server von fhem. Dieser wiederum leitet die Daten dann weiter an das MQTT2-Device, welches automatisch bei der ersten Verbindung des Lesekopfes erstellt wird.
In diesem neuen MQTT2-Device findest Du dann die Daten Deines Zählers.
Stand der Dinge:
Der MQTT2 Server läuft jetzt in fhem. Das bedeutet, der MQTT2-Server ist unter der IP-Adresse des fhem Servers (Raspberry Pi) mit der Port Nummer 2883 zu erreichen.
Das Reading "allowfrom" mußt Du unbedingt löschen, sonst funktioniert es nicht.
Das Reading "autocreate" stellt sich standardmäßig richtig ein, deshalb mußt Du es nicht extra angeben, also auch löschen.
Die MQTT Serverdaten mußt Du jetzt in dem Webinterface vom Lesekopf (Tasmota) eintragen. Da müßte es einen Abschnitt "MQTT-Einstellungen" geben.
Hier trägst Du die IP Adresse des MQTT2-Servers (Raspberry Pi auf dem fhem läuft) ein und die Port Nummer 2883. Benutzer und Kennwort bleiben leer.
Das Ganze speichern und evtl. den Lesekopf neu starten.
Wenn alles korrekt ist, müßte jetzt in dem MQTT2-Server von fhem unter Readings bei dem Reading "nrclients" eine "1" erscheinen, das bedeutet, daß sich Dein Lesekopf
mit dem MQTT-Server verbunden hat.
Außerdem müßte jetzt in fhem ein rotes Fragezeichen oben neben "save config" zu sehen sein. Dies bedeutet, daß ein neues MQTT2-Device angelegt wurde.
In diesem neuen MQTT2-Device empfängst Du jetzt die Daten von Deinem Zähler.
Gruß Thomas
P.S. als Anhang mal der MQTT2-Server ohne und mit verbundenem Clienten ;o)
Danke Thomas,
das ist eine tolle Erklärung! Jetzt habe ich (hoffe ich) das Prinzip verstanden. Da werde ich mich nächste Woche mal drangeben. ich werde berichten, wie es mir ergangen ist.
Nochmals vielen Dank für deine Mühe und angenehme Woche
Harald
Sehr gerne Harald, kein Problem :)
Bin gespannt, ob es klappt und was Du berichtest.
Dir auch eine angenehme Woche !
Bis dann
Thomas
So, nun bin ich dank deiner Hilfe einen Schritt weiter.
Wie bekomme ich nun die eingelesenen Daten kontinuirlich in OBIS? Hast du da auch noch einen Tipp?
Viele Grüße Harald
Hallo Thomas,
ich bin begeistert! Danke nochmals, daß du mich in die richtige Richtung geschubst hast!
Nun habe ich auch das neu angelegte Device gefunden. Es hatte sich im Room Test versteckt ;-) Da befinden sich die übertragenen Daten als Readings.
Jetzt muß der Feinschliff stattfinden, Readings u.ä. unbenennen, evtl. welche löschen wg. der Übersicht, FileLog anlegen usw. usw.
Ich freue mich sehr, daß du so nett wars und mir geholfen hast. Jetzt kann ich weiter machen.
Viele Grüße und alles Gute aus Geldern
Harald
Zitat von: Harald am 11 April 2022, 12:47:28
Hallo Thomas,
ich bin begeistert! Danke nochmals, daß du mich in die richtige Richtung geschubst hast!
Nun habe ich auch das neu angelegte Device gefunden. Es hatte sich im Room Test versteckt ;-) Da befinden sich die übertragenen Daten als Readings.
Jetzt muß der Feinschliff stattfinden, Readings u.ä. unbenennen, evtl. welche löschen wg. der Übersicht, FileLog anlegen usw. usw.
Ich freue mich sehr, daß du so nett wars und mir geholfen hast. Jetzt kann ich weiter machen.
Viele Grüße und alles Gute aus Geldern
Harald
Hallo Harald,
das sieht doch super aus, es freut mich sehr, das ich Dir helfen konnte :D
Da kommen ja mal richtig viele Daten an, zwar hauptsächlich von Tasmota selbst, aber was soll's ;o)
Hab gleich mal geschaut, was die SML Werte bedeuten:
16.7.0 - Summe momentane Wirkleistung in kW
36.7.0 - Summe momentane Wirkleistung in Phase L1 in kW
56.7.0 - Summe momentane Wirkleistung in Phase L2 in kW
76.7.0 - Summe momentane Wirkleistung in Phase L3 in kW
Alles Gute auch Dir !
Viele Grüße aus Hohen Neuendorf
Thomas
P.S.:
Hab noch was vergessen, hast Du den vierstelligen Code schon in Deinen Zähler eingegeben und den Menüpunkt "Info" auf "on" gestellt ?
Dann könnten noch mehr Daten kommen ;)
Hallo Thomas,
danke für die Infos. Die Daten die der Zähler sendet, kenne ich. Ich habe die Betriebsanleitung und die PIN von meinem EVU bekommen. Den Zähler habe ich auch schon umprogramiert, damit er mir das lange Protokoll sendet.
Kennst du dich mit Tasmota gut aus? Ich habe irgendwo gelesen, daß man ihm im Script mitteilen kann, in welchem Intervall die Daten vom Zähler abgeholt bzw. zu FHEM gesendet werden. Weißt du, welcher Befehl das ist?
Vielen Dank nochmals für die Hilfe.
Harald
Zitat von: Harald am 11 April 2022, 17:54:41
Hallo Thomas,
danke für die Infos. Die Daten die der Zähler sendet, kenne ich. Ich habe die Betriebsanleitung und die PIN von meinem EVU bekommen. Den Zähler habe ich auch schon umprogramiert, damit er mir das lange Protokoll sendet.
Kennst du dich mit Tasmota gut aus? Ich habe irgendwo gelesen, daß man ihm im Script mitteilen kann, in welchem Intervall die Daten vom Zähler abgeholt bzw. zu FHEM gesendet werden. Weißt du, welcher Befehl das ist?
Vielen Dank nochmals für die Hilfe.
Harald
Hallo Harald,
mit Tasmota kenne ich mich noch nicht aus, hab aber eine sehr gute Seite im Internet gefunden:
https://hessburg.de/tasmota-wifi-smartmeter-konfigurieren/#more-17863 (https://hessburg.de/tasmota-wifi-smartmeter-konfigurieren/#more-17863)
Dort hat jemand die Sache mit Tasmota und dem Hichi - WLAN Lesekopf sehr gut beschrieben, da findest Du, was Du suchst ...
Wenn Du dazu trotzdem noch Fragen hast, einfach hier schreiben.
Viel Erfolg beim scripten ;o)
Gruß Thomas
Hallo Thomas,
Dank deiner und der Hilfe des Kopfentwickler Hichi habe ich es nun hinbekommen, daß ich die die Daten vom Zähler so eingelesen bekomme, daß ich sie so verarbeitet und angezeigt bekomme, wie ich mir das gewünscht habe.
Ich habe das in Tasmota erforderliche Script für meine Zähler im Internet gefunden und entspechend meiner Wünsche angepasst. ich habe den Entwicker Hitchi auf Ebay angeschrieben. Er hat mir dann erklärt, warum ich die Datenflut von den aktuellen Leistungswerten nicht reduziert bekam.
Am Ende der entsprechenden Strings stand im Original ein ,16. Das besagt lt. Hitchi u.a., daß diese Daten so schnell wie möglich an den Server übertragen werden sollen. Außerdem beinhaltet die 16 auch, daß 2Stellen nach den Komma angezeigt werden sollen. Die entsprechenden Zeilen habe ich so geändert.
; Summe der Momentan-Leistungen in allen Phasen, Auflösung 0,01W (5 Vorkomma- und 1 Nachkommastellen)
1,77070100100700FF@1,Leistung,W,16_7_0,1
Damit bekomme ich eine Nachkommastelle und den gewünschren Zeitintervall (TelePeriod 300) von 5min.
Obwohl alles so klappt wie ich wünsche, strapaziere ich mir noch den Kopf über das MQTT2_Device. Dort wird das Internal STATE mit ???angezeigt.
Hast du eine Idee, warum das so ist, wie ich das ändern kann und was für Auswirkungen das hat?
Nochmals herzlichen Dank für deine Geduld und Hilfe. Ohne dich wäre ich noch längst nicht so weit.
Viele Grüße aus Geldern, alles Gute und ein schönes Osterfest
Harald
Beim Diagramm ist die Leistung P L1 vorwiegend die von der PV-Anlage kommende, eingespeiste Leistung. Auf L1 liegen keine Verbraucher, die üblicherweise genutzt werden.
Hallo Harald,
danke für die ausführliche Rückmeldung, sieht sehr gut aus, wie Du das im Endeffekt hinbekommen hast.
Sehr interessant zu wissen, wie das Tasmota Script funktioniert, werde ich demnächst bestimmt auch mal testen.
Bei mir laufen 2 Leseköpfe von Hichi, aber ohne ESP, einfach nur direkte serielle Ausgabe. Anschließend
hab ich einen Lesekopf an einem D1 mini mit ESP-easy hängen, der leitet den Datenstrom mittels ser2net an
Fhem weiter, der andere Lesekopf hängt an einem Lantronics XPort, der macht ser2net per Ethernet.
Der "neue" Lesekopf von Hichi mit WLAN ist schon sehr interessant, vielleicht sollte ich nochmal umbauen.
Der STATE ??? ist natürlich nicht so schön. Kann man aber leicht ändern. Und zwar mit dem attr stateFormat:
angenommen, das Reading "power" hat den Wert -1500
stateFormat Leistung: power W
dann erscheint oben im Status: "Leistung: -1500 W"
Oder die Readings "power" = -3000 und "verbrauch" = 5530
stateFormat Leistung: power W, Zählerstand Bezug: verbrauch kWh
dann erscheint: "Leistung: -3000 W, Zählerstand Bezug: 5530 kWh" als Status.
Das kann man sehr flexibel verwenden, einfach Text schreiben und readings als Variable einsetzen.
Freut mich sehr, daß ich Dir weiterhelfen konnte ;o)
Viele Grüße aus dem nördlichen Berliner Umland
und ebenfalls schöne Ostern
Thomas
Hallo,
bisher hat das Modul alle einwandfrei funktioniert. Seite heute Nachmittag 2022-04-15 16:43:38 wird das Reading "power" nicht mehr aktualisiert. Jemand eine Idee an was das liegen könnte und wo ich bei der Fehlersuche ansetzen könnte....?
Danke
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 9
FUUID 61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
MeterType SML
NAME ITR_Stromzaehler
NR 20
PARTIAL
STATE Aktuell: -4035.0 W, Verbrauch: 12549 kWh seit 15.4., 22:22.
TYPE OBIS
READINGS:
2022-04-15 22:21:50 1.0.96.1.0.255 ITRI@
2022-04-15 22:22:40 1.8.0_Verbrauch 12549000
2022-04-15 22:22:40 2.8.0_Einspeisung 1371000
2022-04-15 22:22:40 ManufID2 ITR
2022-04-15 16:43:38 power -4035
2022-04-15 22:20:39 state opened
helper:
BUFFER v �l��rbbrev ��L
ITRI�@r
DIRECTIONSUM >
EoM -1
LastPacketTime 1650054160.45145
SPEED 5
SPEED2 5
TRIGGERTIME 1650054039.89451
directions pwr feeding
Channels:
1-0:1.8.0*255 1.8.0_Verbrauch
1-0:2.8.0*255 2.8.0_Einspeisung
DEVICES:
10
RULECACHE:
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
Attributes:
channels {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
directions ">" => "pwr consuming", "<" => "pwr feeding"
interval 10
pollingMode on
room Stromzähler
stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }
Zitat von: karpate am 15 April 2022, 22:27:28
Hallo,
bisher hat das Modul alle einwandfrei funktioniert. Seite heute Nachmittag 2022-04-15 16:43:38 wird das Reading "power" nicht mehr aktualisiert. Jemand eine Idee an was das liegen könnte und wo ich bei der Fehlersuche ansetzen könnte....?
Danke
Internals:
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 9
FUUID 61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
MeterType SML
NAME ITR_Stromzaehler
NR 20
PARTIAL
STATE Aktuell: -4035.0 W, Verbrauch: 12549 kWh seit 15.4., 22:22.
TYPE OBIS
READINGS:
2022-04-15 22:21:50 1.0.96.1.0.255 ITRI@
2022-04-15 22:22:40 1.8.0_Verbrauch 12549000
2022-04-15 22:22:40 2.8.0_Einspeisung 1371000
2022-04-15 22:22:40 ManufID2 ITR
2022-04-15 16:43:38 power -4035
2022-04-15 22:20:39 state opened
helper:
BUFFER v �l��rbbrev ��L
ITRI�@r
DIRECTIONSUM >
EoM -1
LastPacketTime 1650054160.45145
SPEED 5
SPEED2 5
TRIGGERTIME 1650054039.89451
directions pwr feeding
Channels:
1-0:1.8.0*255 1.8.0_Verbrauch
1-0:2.8.0*255 2.8.0_Einspeisung
DEVICES:
10
RULECACHE:
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
Attributes:
channels {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
directions ">" => "pwr consuming", "<" => "pwr feeding"
interval 10
pollingMode on
room Stromzähler
stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }
Hallo karpate,
sieht ganz so aus, als wäre Dein Lesekopf "verrutscht".
BUFFER v �l��rbbrev ��L
ITRI�@rÜberprüfe mal die Positionierung des Lesekopfes.
Gruß Thomas
Hallo Thomas,
Danke.
Komisch, eigentlich kommt an den Zählerschrank niemand ran und zu besagter Uhrzeit war auch niemand daheim.
Ich habe am Lesekopf ein wenig gedreht. Der Buffer-Eintrag ist nun weg, dafür werden CRC_Errors angezeigt. Das power Reading wird leider noch nicht aktualisiert
Internals:
CRC_Errors 3
DEF /dev/ttyUSB0@9600,8,N,1 SML
DeviceName /dev/ttyUSB0@9600,8,N,1
FD 4
FUUID 61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
MeterType SML
NAME ITR_Stromzaehler
NR 20
PARTIAL
STATE Aktuell: -4035.0 W, Verbrauch: 12549 kWh seit 16.4., 00:05.
TYPE OBIS
READINGS:
2022-04-15 22:21:50 1.0.96.1.0.255 ITRI@
2022-04-16 00:05:12 1.8.0_Verbrauch 12549000
2022-04-16 00:05:12 2.8.0_Einspeisung 1371000
2022-04-16 00:05:12 ManufID2 ITR
2022-04-15 16:43:38 power -4035
2022-04-15 23:45:46 state opened
helper:
BUFFER
DIRECTIONSUM >
EoM 1
LastPacketTime 1650060312.47617
SPEED 5
SPEED2 5
TRIGGERTIME 1650054039.89451
directions pwr feeding
Channels:
1-0:1.8.0*255 1.8.0_Verbrauch
1-0:2.8.0*255 2.8.0_Einspeisung
DEVICES:
10
RULECACHE:
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
Attributes:
channels {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
directions ">" => "pwr consuming", "<" => "pwr feeding"
interval 10
pollingMode on
room Stromzähler
stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }
ergänzend ein Verbose 5 vom Sensor
2022.04.16 08:26:26 5: DevIo_SimpleWrite ITR_Stromzaehler:
2022.04.16 08:26:26 4: OBIS (ITR_Stromzaehler) - Wrote
2022.04.16 08:26:26 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2022-04-16 08:26:36
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B010101017609D16CBF05000296DD62006200726500000101760101090000000005C049C50B0A01495452000349F0407262016505C049C60163A90A007609D16CBF05000296DE6200620072650000070177010B0A01495452000349F040070100620AFFFF7262016505C049C674770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C210401621E52036900000000000031080177070100020800FF0101621E520369000000000000055B01010163003C007609D16CBF05000296DF62006200726500000201710163A6A40000001B1B1B1B1A02B11D
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B010101017609D16CBF05000296DD62006200726500000101760101090000000005C049C50B0A01495452000349F0407262016505C049C60163A90A007609D16CBF05000296DE6200620072650000070177010B0A01495452000349F040070100620AFFFF7262016505C049C674770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C210401621E52036900000000000031080177070100020800FF0101621E520369000000000000055B01010163003C007609D16CBF05000296DF62006200726500000201710163A6A40000001B1B1B1B1A02B11D
2022.04.16 08:26:27 4: OBIS (ITR_Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(12552000*Wh)
1-0:2.8.0*255(1371000*Wh)
!
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(12552000*Wh)
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(1371000*Wh)
2022.04.16 08:26:27 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
Nachtrag: nach erneuter Eingabe des Pins und Einstellung "erweiterter Datensatz" erhalte ich auch die Momentanleistung wieder. Einzigste Erklärung ist, das es gestern einen Spannungsabfall gab und der Zähler wieder begonnen hat den vereinfachten Datensatz zu übertragen.
Hallo Thomas,
danke, hab ich wieder was gelernt. Jetzt sind die 3 ? endlich weg.
Schönes Osterfest allen von schönen Niederrhein
Harald
Zitat von: karpate am 16 April 2022, 00:15:03
Nachtrag: nach erneuter Eingabe des Pins und Einstellung "erweiterter Datensatz" erhalte ich auch die Momentanleistung wieder. Einzigste Erklärung ist, das es gestern einen Spannungsabfall gab und der Zähler wieder begonnen hat den vereinfachten Datensatz zu übertragen.
Hallo karpate,
das mit dem Spannungsabfall klingt plausibel, daran hatte ich gar nicht gedacht. Wäre eine logische Erklärung ;o)
Schön das es wieder geht.
Gruß Thomas
Hi Zusammen,
@Harald
Ich habe mir auch zwei Wifi-Leseköpfe von Hichi gekauft.
Das Einrichten war grundsätzlich nicht schwer, allerdings läuft bei mir MQTT schon länger.
Was mir nicht gefällt, ist das periodische senden via mqtt der Zählerwerte. Ich habe sie zwar jetzt auf 10sek gestellt, aber ein Pushbetrieb wäre mir lieber gewesen.
Hast du dafür eine Lösung gefunden, oder stört dich das nur nicht und lebst damit :)
Gruß
rubinho
Hallo rubinho,
ich verstehe deine Frage nicht ganz. Was meinst du mit "periodischem Senden der Zählerwerte"?
Ich habe in Tasmota im Script die Sendefolge aller Werte auf 5 Minuten gesetzt (damit keine Unmengen von Daten anfallen) und mittels des voranstehenden ";" alle Werte von der Übertragung ausgeschlossen, die ich nicht haben wollte. Somit erhalte ich die Zählerstände, akttuelle Leistung der einzelnen Außenleiter, die Gesamtleistung dieser und die WLAN-Feldstärke, die im MQTT2-Device ankommen und derzeit in einem Diagramm angezeigt werden.
Viele Grüße
Harald
Zitat von: Harald am 28 April 2022, 16:22:59
Hallo rubinho,
ich verstehe deine Frage nicht ganz. Was meinst du mit "periodischem Senden der Zählerwerte"?
Ich habe in Tasmota im Script die Sendefolge aller Werte auf 5 Minuten gesetzt
Genau das ist periodisch ;D
Ich wollte grundsätzlich wissen ob man die Werte Instant (also in dem Moment wenn ein neuer Wert gemessen wird) per mqtt übermittelt werden kann und nicht nur nach einer vorgegebenen periodischen Zeit (zB. alle 5 Minuten).
Der Grund warum ich das Frage, wenn ich mal eine Steuerung mittels den Verbrauchswerten erstellen muss/will, benötige ich schnelle und genaue Werte.
Ich habe das Thema aber schon in einem anderen Post (https://forum.fhem.de/index.php/topic,127437.msg1219718.html#msg1219718) geklärt, es ist also grundsätzlich möglich.
Im Übrigen, so lange man nicht alle Daten mitloggt, ist die Menge noch überschaubar. Man muss in Fhem ja nicht alles mitloggen was man empfängt ;)
Gruß
Rubinho
Hallo rubinho,
da bist du schon viel weiter. Da muß ich mir noch Gedanken machen. Ich fange ja gerade erst mit MQTT an. Danke für die Info in deinem anderen Post.
Schönes Wochenende
Harald
Hallo,
hab ein Problem, über das viele von euch vermutlich schmunzeln. Da ich aber (immer) noch mit perl auf Kriegsfuss stehe, kriege ich einen von MQTT gesendeten String, den
ich in einem Reading eines MQTT_DEVICEs empfange, nicht in die einzelnen Inhalte zerlegt, die ich dann weiterverarbeiten könnte. MQTT wird seperat gestartet (nicht mit MQTT2_SERVER).
Es handelt sich dabei um die Werte, die dem Total_in und dem Power_curr folgen. Auch bei der Suche innerhalb fhem bin ich keinen Schritt weitergekommen.
Daher mein Hilferuf an euch.
Ich möchte die gelieferten Werte in (User-)Readings oder Dummies einstellen, die ich in einem weiteren Schritt einem Logfile zuführe und mir den aktuellen und den auf den
Tag berechneten Verbrauch anzeigen lassen kann.
2022-05-02_19:58:19 income_Strom {"Time":"2022-05-02T18:58:19","SML":{"Total_in":164.3266,"Power_curr":642}}
2022-05-02_20:03:19 income_Strom {"Time":"2022-05-02T19:03:19","SML":{"Total_in":164.3793,"Power_curr":636}}
Würde mich über eure Anregungen freuen.
####### Problem gelöst mittels expandJson ##################
Harald(2)
Hallo,
ich verwendet das OBIS-Modul seit einigen Jahren ohne Probleme.
Seit ein paar Wochen hört es jedoch immer wieder auf Daten zu empfangen.
Die Readings ändern sich einfach nicht mehr.
Ein Fhem-Neustart oder Ändern der Definition des Geräts so dass die Schnittstelle neu geöffnet wird bringt alles wieder in Gang.
Angeschlossen ist der Zähler per USB-IR-Kopf (Weidmann).
Wie kann ich das debuggen?
List:
Internals:
DEF /dev/rs232Energy2 SML
DeviceName /dev/rs232Energy2
FD 80
FUUID 5ee0b031-f33f-aef6-6ebf-f9471ae3f3afb66f
MeterType SML
NAME EMD.Haus
NR 794
PARTIAL
STATE 1.283 kW
TYPE OBIS
READINGS:
2022-05-29 20:02:48 1.0.96.1.0.255 ISK38
2022-05-29 20:02:48 ManufID2 ISK
2022-05-29 20:02:48 power 1283
2022-05-29 13:43:03 state opened
2022-05-29 20:02:48 total_consumption 27568297.5
2022-05-29 20:02:48 total_feed 0
helper:
BUFFER v L�mbbrcv
DIRECTIONSUM >
EoM 0
LastPacketTime 1653847368.96625
NETDEV 0
SPEED 5
TRIGGERTIME 1653824583.60791
Channels:
DEVICES:
-1
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
directions:
Attributes:
alias Strom-Haus
event-min-interval .*:60
group Stromzähler
icon ge_wht_steckdose
ignoreUnknown off
room Energie
stateFormat {sprintf("%s kW", ReadingsVal($name,"power",0)/1000)}
verbose 3
Bild anbei.
Gruss / vielen Dank
Stefan
Hallo Zusammen.
Vor einigen Tagen wurde mein Stromzähler gewechselt. Den alten und auch den neuen Zähler lese ich mittels IR-Lesekopf aus.
Mit der Umstellung auf den neuen Zähler bin ich auch auf das OBIS-Modul gewechselt (vorher vzlogger).
Beim alten Zähler habe ich mittels D0-Schnittstelle die Daten ausgelesen. Der neue liefert per SML.
Allerdings nur die Werte für den Bezug und ggf. Einspeisung.
Vorher (mit vzlogger) hatte ich noch den Momentanen Verbrauch in Watt.
Gibt es eine Möglichkeit diesen OBIS-Modul zu berechnen? Vielleicht brauche ich da auch nur einen "Gedanken-Schubser".
Oder es steht in diesen 95 Seiten irgendwo verborgen ;D
Hallo Stefan, hallo darkness,
da euer Problem ähnlich gelagert ist, fasse ich die Antwort hier zusammen.
Auch ich hatte anfangs das Problem, dass wie bei Stefan der Stromzähler seine Lieferung einstellte und nur durch einen Neustart von fhem reaktiviert werden konnte. Dies allerdings nur 2 Mal. Seither läuft das ganze bei mir stabil (ca. 2 Monate).
Ihr beiden habt die USB Lösung, ich habe auf die WLAN-Lösung mit einem ESP8266 gesetzt. MQTT läuft bei mir eigenständig. In fhem habe ich einen MQTT-DEVICE (tasmota_Strom) definiert. Die von MQTT gelieferten Daten enthalten geschweifte Klammern, die fhem (perl) nicht mag. Daher habe ich mich für die Variante mit expandJSON entschieden, die aus meiner Sicht perfekt läuft. Noch ein zusätzlicher notify, der durch Änderungen von [tasmota_Strom:SENSOR:.*] getriggert wird. Ich erhalte alle Daten, die ich zur Zeit benötige. Vielleicht geht es auch hier eleganter und einfacher.
Nach der Installation der PV schauen wir weiter. Vielleicht hat der Netzbetreiber bis dahin auch den zweiten Stromzähler ausgetauscht (oder auch nicht).
@darkness:
ZitatBeim alten Zähler habe ich mittels D0-Schnittstelle die Daten ausgelesen. Der neue liefert per SML.
Allerdings nur die Werte für den Bezug und ggf. Einspeisung.
Hatte ich auch als die PIN noch nicht (permanent) eingegeben war. Jeweils nach 2 Minuten fiel der Zähler wieder in den gesperrten Modus zurück.
Und nun zu meiner Umgebung:
DeviceOverview
tasmota_Strom
HHSt: aktuell: 597 W, Tag: 6.12 Kw/h, gesamt: 843.42 Kw/h
ON
OFF
tasmota_Strom
Internals
FUUID
6274df5f-f33f-f127-0b56-d9725061d9e45e85
IODev
myBroker
NAME
tasmota_Strom
NR
399
STATE
HHSt: aktuell: 597 W, Tag: 6.12 Kw/h, gesamt: 843.42 Kw/h
TYPE
MQTT_DEVICE
Readings
Heap
19
2022-06-16 12:32:06
IODev
myBroker
2022-06-10 10:04:10
Info1_GroupTopic
tasmota_Strom/cmnd/
2022-06-08 13:46:36
Info1_Module
Generic
2022-06-08 13:46:36
Info1_Version
11.0.0(tasmota)
2022-06-08 13:46:36
Info2_Hostname
tasmota-Strom-0326
2022-06-08 13:46:36
Info2_IPAddress
192.168.178.177
2022-06-08 13:46:36
Info2_WebServerMode
Admin
2022-06-08 13:46:36
Info3_BootCount
118
2022-06-08 13:46:36
Info3_RestartReason
Software/System restart
2022-06-08 13:46:36
LOGGING
12:32:06.424 MQT: tasmota_Strom/SENSOR = {"Time":"2022-06-16T12:32:06","SML":{"Total_in":843.4156,"Power_curr":597}}
2022-06-16 12:32:07
LWT
Online
2022-06-16 04:12:42
LoadAvg
19
2022-06-16 12:32:06
MqttCount
8
2022-06-16 12:32:06
RESULT
{"Time":"2022-06-08T14:56:10","SML":{"CMD":"restart"}}
2022-06-08 14:56:10
[b]SENSOR
{"Time":"2022-06-16T12:32:06","SML":{"Total_in":843.4156,"Power_curr":597}}[/b]
2022-06-16 12:32:06
SML_CMD
restart
2022-06-08 14:56:10
SML_ID
0a01484c59030001fab1
2022-06-08 13:51:40
SML_Power_curr
597
2022-06-16 12:32:06
SML_Total_in
843.4156
2022-06-16 12:32:06
SML_akt_Tag
6.1160000000001
2022-06-16 12:32:06
STATE
{"Time":"2022-06-16T12:32:06","Uptime":"7T22:45:35","UptimeSec":686735,"Heap":19,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":8,"Wifi":{"AP":2,"SSId":"Wolfsjunge","BSSId":"74:42:7F:12:DF:CE","Channel":1,"Mode":"11n","RSSI":62,"Signal":-69,"LinkCount":1,"Downtime":"0T00:00:03"}}
2022-06-16 12:32:06
Sleep
50
2022-06-16 12:32:06
SleepMode
Dynamic
2022-06-16 12:32:06
Time
2022-06-16T12:32:06
2022-06-16 12:32:06
Uptime
7T22:45:35
2022-06-16 12:32:06
UptimeSec
686735
2022-06-16 12:32:06
Wifi_AP
2
2022-06-16 12:32:06
Wifi_BSSId
74:42:7F:12:DF:CE
2022-06-16 12:32:06
Wifi_Channel
1
2022-06-16 12:32:06
Wifi_Downtime
0T00:00:03
2022-06-16 12:32:06
Wifi_LinkCount
1
2022-06-16 12:32:06
Wifi_Mode
11n
2022-06-16 12:32:06
Wifi_RSSI
62
2022-06-16 12:32:06
Wifi_SSId
Wolfsjunge
2022-06-16 12:32:06
Wifi_Signal
-69
2022-06-16 12:32:06
connect
2022-06-13 18:51:40
state
OFF
2022-05-20 03:34:40
transmission-state
incoming publish received
2022-06-16 12:32:07der expandJSON
DeviceOverview
ej3
2022-06-16 12:32:06
Internals
DEF
tasmota_Strom.*:.*:.[{].*}
FUUID
6274db21-f33f-f127-f107-b7428823e502ea25
NAME
ej3
NOTIFYDEV
tasmota_Strom.*
NR
398
NTFY_ORDER
50-ej3
STATE
2022-06-16 12:32:06
TYPE
expandJSON
s_regexp
tasmota_Strom.*:.*:.[{].*}
t_regexp
.*
version
1.13
Readings
state
active
2022-06-10 10:04:10und der zugehörige norify
Change wizard
Change the condition:
n_j2r addRegexpPart
Change the executed command:
n_j2r tasmota_Strom:Sensor:.* set
n_j2r
Internals
DEF
tasmota_Strom:Sensor:.* { ej3($NAME,$EVENT) }
FUUID
6274e79e-f33f-f127-f740-e1601dd4850edc11
NAME
n_j2r
NOTIFYDEV
tasmota_Strom
NR
400
NTFY_ORDER
50-n_j2r
REGEXP
tasmota_Strom:Sensor:.*
STATE
active
TYPE
notify
Readings
state
active
2022-06-10 10:04:10Wie aus der Zeile
tasmota_Strom/SENSOR = {"Time":"2022-06-16T12:32:06","SML":{"Total_in":843.4156,"Power_curr":597}} ersichtlich, liefert der Zähler mir nur den aktuellen und den gesamten Verbrauch. Den Tagesverbrauch berechne ich mir selbst. Soll auch aus den Daten des Zählers kommen, habe den richtigen Code noch nicht gefunden.
Füge die Console-Einstellung von TASMOTA hinzu
>D
>B
=>sensor53 r
>M 1
+1,3,s,0,9600,SML
;1,77070100010801ff@1000,Verbrauch_Tarif_1,kWh,Verbrauch_T1,7
;1,77070100010802ff@1000,Verbrauch_Tarif_2,kWh,Verbrauch_T2,7
1,77070100010800ff@1000,Verbrauch_Summe,kWh,Total_in,4
;1,77070100020800ff@1000,Einspeisung_Summe,kWh,Einspeisung_Summe,7
;1,770701000F0700ffff@1,Nummer,,,,
1,=h--
;1,77070100240700ff@1,Leistung_L1,W,Watt_L1,18
;1,77070100380700ff@1,Leistung_L2,W,Watt_L2,18
;1,770701004c0700ff@1,Leistung_L3,W,Watt_L3,18
;1,77070100100700ff@1,Leistung_Summe,W,Power_curr,16 ; der liefert ohne Nachkommastelle alle Sekunde, dann aber auch den Gesamtverbrauch
1,77070100100700ff@1,Leistung,W,Power_curr,0
;1,=h--
;1,77070100200700ff@1,Spannung_L1,V,Volt_L1,17
;1,77070100340700ff@1,Spannung_L2,V,Volt_L2,17
;1,77070100480700ff@1,Spannung_L3,V,Volt_L3,17
;1,7707010060320101@#,Hersteller-Ident,,HI,1
;1,77070100600100ff@#,Server ID,,ID,1
#Bei dem Zähler handelt es sich um einen Holleytech (siehe Link)
https://www.holleytech.de/produkte/basiszaehler-bz/stecktechnik-ehz541-i/ (https://www.holleytech.de/produkte/basiszaehler-bz/stecktechnik-ehz541-i/)
Würde mich freuen, wenn ein Schubser dabei war. Braucht ihr weitere Informationen, lasst es mich wissen.
Gruss Harald(2)
Zitat von: StefanStrobel am 01 Juni 2022, 17:34:55
Wie kann ich das debuggen? ......
List:
....
TYPE OBIS
READINGS:
2022-05-29 20:02:48 1.0.96.1.0.255 ISK38
Zum Debuggen bin ich jetzt auch nicht so fit. Die Idee hattest Du bestimmt auch schon. Ähnlich wie "tee" die serielle Schnittstelle spiegeln um zu sehen ob der Lesekopf nicht mehr sendet oder das Modul nichts mehr verarbeitet.
An sich habe ich ne Frage.
Hast Du dich schon mal mit dem OBIS Wert "1.0.96.1.0.255" = "ISK38" befasst? aus meiner Sicht scheint das (ich habe den ISK M691) die auf dem Zähler aufgedruckte ServerID zu sein. => Bei dir auch?
Die ist auch etwas länger als nur die 38 hinter dem ISK. Sind bei mir 1 + 4 Byte.
@gvzdus:Macht es Sinn solche Dinge im Modul im SML-Teil zu ergänzen. Mit den Messwerten hat das ja wenig zu tun und wer weiß was andere Zähler an der Stelle mitgeben.
Gruß Ralf
Hallo zusammen,
ich bin einen Schritt weiter:
Da ich zwei Zähler und auch zwei Leseköpfe habe, habe ich die beiden Leseköpfe mal getauscht. Jetzt bleibt die Kommunikation des anderen Zählers hängen.
Ein tail -f auf das Device zeigt dann auch keine Daten mehr. Offenbar ist es also ein Hardware-Defekt des Lesekopfes.
Den Text ISK38 habe ich übrigens nirgends auf dem Zähler gefunden, aber es klingt schon nach einer Id ...
Gruss
Stefan
Zitat von: StefanStrobel am 19 Juni 2022, 15:26:27
Den Text ISK38 habe ich übrigens nirgends auf dem Zähler gefunden, aber es klingt schon nach einer Id ...
Habe bei http:www.stefan-weigert.de/php_loader/sml.php (//http://http:www.stefan-weigert.de/php_loader/sml.php) noch Infos zur Interpretation gefunden. Nach der Lektüre denke ich, dass es die ServerID ist.
Die eigentlichen Daten zu der Kennzahl 1-0:96.1.0*255 sind 10 Byte = ServerID (nur der Text wird scheinbar korrekt dekodiert - wo die Ziffer herkommt ist unklar / bei mir steht da: ISK2).
|Liste 7 Einträge
| |7 Byte OBIS Kennzahl "1.0.96.1.0.255"
| |
| | | | | | |
77 07 01 00 60 01 00 ff 01 01 01 01 0b 0a 01 49 53 4b 00 uu vv ww xx 01
|11 Byte, ServerID = 0A 1 I S K 00 uu vv ww xx (4stellen Hex auf 8stellen Dec umgerechnet, als 8-stellige Dezimalzahl auf den Zähler gedruckt)
aufgedruckt ist:
- 10 Byte Hex als "ServerID"
- recht groß "1 ISK00 1234 5678"
- 8 Ziffern als "Nr." (Umrechnung 4 Stellen Hex auf 8 Stellen Dezimal)
es wird quasi alles aus der ServerID abgeleitet.
Ok ist jetzt ein wenig OffTopic ;)
P.S.
Doofe Frage: Du hast schon die Leseköpfe am jeweils anderen Ser-Interface angeschlossen?
Allerdings denke ich, dass "tail" nicht die richtige Methode ist um an die Daten zu kommen! Braucht man nicht eher was wie einen "Serial Sniffer"? Z.B. usbmon oder sowas?
Hallo,
ich habe die 95 Seiten hier quergelesen, aber bin noch nicht richtig auf einen grünen Zweig gekommen.
Ich habe für meinen Smartmeter ein OBIS Gerät in FHEM eingebunden. Das läuft auch, nach Tipps hier aus dem Forum perfekt.
Folgende userReadings-Definition hab ich übernommen:
kWh {sprintf("%.02f",ReadingsVal("Stromzaehler","energy_total",0)/1000)}, watt {sprintf("%.00f",ReadingsVal("Stromzaehler","power",0))}, watt_l1 {sprintf("%.00f",ReadingsVal("Stromzaehler","power_L1",0))}, watt_l2 {sprintf("%.00f",ReadingsVal("Stromzaehler","power_L2",0))}, watt_l3 {sprintf("%.00f",ReadingsVal("Stromzaehler","power_L3",0))}
Damit werden alle aktuellen Werte korrekt formatiert ausgegeben.
Was muss ich nun unternehmen, wenn ich Tages- , Monats- und Jahreswerte zur Darstellung in meiner Tablet UI bekomme?
Über einen Schubs in die richtige Richtung würde ich mich freuen...
Gruß Swen
Vielleicht hilft's:
https://forum.fhem.de/index.php/topic,120088.msg1225243.html#msg1225243
lg gho
Hallo zusammen,
ich versuche aktuell meinen Stromzähler Stromzähler vom Typ Itron ACE3000 auszulesen. Dafür habe ich mir den Weidmann Lesekopf besorgt.
Erste Tests mit dem Tool HTERM haben gut funktioniert und lieferten Daten. Dann habe ich mich nun mit FHEM beschäftigt und bin dabei auf das OBIS Modul gestoßen. Das scheinbar das ist, was mir hier helfen kann.
Sah zunächst auch vielversprechend aus. Aber dann sind mir ein paar Dinge aufgefallen, dass es doch nicht so recht klappt. Zum einen werden die Daten scheinbar nur einmal beim Anlegen des Devices gelesen. Danach findet kein Update mehr statt. Auch nicht, wenn ein Intervall gesetzt wird. Über die Funktion Get Update funktioniert es dann scheinbar wieder einmalig. Ich vermute, dass dass diese den internen Zeitzähler aushebelt. Hier mal der Auszug aus dem Log nach dem Auslesen:
2022.09.22 13:22:38 5: OBIS (Stromzaehler) - Msg-Parse: !
2022.09.22 13:22:38 5: OBIS (Stromzaehler) - Msg-Parse: 1.8.0(030126.8*kWh)
2022.09.22 13:22:37 5: OBIS (Stromzaehler) - Msg-Parse: C.5.0(00)
2022.09.22 13:22:36 5: OBIS (Stromzaehler) - Msg-Parse: C.1(1126130053729099)
2022.09.22 13:22:35 5: OBIS (Stromzaehler) - Msg-Parse: F.F(00)
2022.09.22 13:22:35 5: OBIS (Stromzaehler) - Msg-Parse: 000
2022.09.22 13:22:35 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
2022.09.22 13:22:35 5: OBIS (Stromzaehler) - Msg-Parse: /ACE0\3k260V01.19
2022.09.22 13:22:34 5: OBIS (Stromzaehler) - Msg-Parse: 000
2022.09.22 13:22:34 5: DevIo_SimpleWrite Stromzaehler: 063030300d0a
??
a
00
/
/!/?
/?!
2022.09.22 13:22:34 5: OBIS (Stromzaehler) - Msg-Parse: A/!
2022.09.22 13:22:33 4: OBIS (Stromzaehler) - Wrote /?!
2022.09.22 13:22:33 5: DevIo_SimpleWrite Stromzaehler: 2f3f210d0a
2022.09.22 13:22:20 1: /dev/ttyUSB1 reappeared (Stromzaehler)
2022.09.22 13:22:20 3: OBIS (Stromzaehler) - Init done
2022.09.22 13:22:20 3: Setting Stromzaehler serial parameters to 300,7,E,1
Und ein Listing vom Device:
Internals:
CFGFN
DEF /dev/ttyUSB1@300,7,E,1 VSM102
DeviceName /dev/ttyUSB1@300,7,E,1
FUUID 632c37ee-f33f-9c6a-1c6c-772ecafbdf18bded
MeterType VSM102
NAME Stromzaehler
NR 358
PARTIAL
STATE disconnected
TYPE OBIS
READINGS:
2022-09-22 13:22:38 1.8.0 30126.8
2022-09-22 13:22:36 C.1 1126130053729099
2022-09-22 13:22:37 C.5.0 0
2022-09-22 13:22:35 Version ACE0\3k260V01.19
2022-09-22 13:32:15 state disconnected
helper:
BUFFER J
EoM 0
LastPacketTime 1663845758.16235
SPEED 0
SPEED2 0
TRIGGERTIME 1663842286.3518
Channels:
DEVICES:
/?!
0
000
RULECACHE:
1.8.0 unknown
C.1 unknown
C.5.0 unknown
Attributes:
interval 60
resetAfterNoDataTime 300
room HWR
verbose 5
Mein Verdacht ist, dass es an dem Init liegt. Der Zähler erwartet schein jedes Mal die Zeichenfolge "/?!", bevor er Daten zurückgibt.
Ich hoffe, ihr könnt mir hier helfen, das zum Laufen zu bekommen.
Danke und Gruß
Matthias
Hi, ich würde Dir raten, mit vzlogger (Volkszähler) die Auslesung zu machen. Die Kollegen haben da ja schon eine schöne Wiki-Seite zusammengestellt:
https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/itron_ace3000_type_260
In das OBIS-Modul passt es aus 2 Gründen nicht hinein:
- Ich konnte noch nie mit einem Zähler, der erst auf "Anschubsen" nur einen Block sendet, das Zusammenspiel testen.
- Dein Zähler arbeitet ja auf ASCII-Ebene statt binär kodiertem SML - das Dekodieren ist aber die Kernaufgabe vom Modul
Daher ist es sinnvoller, wenn Du den Abfrage-Job auslagerst und mit FHEM nur die Weiterverarbeitung / Reaktion auf die Messwerte machst.
Hallo Matthias,
eigentlich müsste das genau so funktionieren, so wie's bei dir ist.
Allerdings macht mich
STATE disconnected
stutzig.
Die Verbindung sollte eigentlich offen bleiben.
Kann es sein, dass noch ein anderes Device auf die selbe Schnittstelle zugreift?
Probiers mal mit dem absoluten Pfad. Das hier ist zB meine def:
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3.1.2:1.0-port0@9600,7,E,1 VSM102
lg, Stefan
Hallo Stefan,
da hatte ich den Test glaube ich schon "abgebrochen". Der Status war die ganze Zeit über OPENED, als ich es versucht hatte.
Was ich leider nicht selber herauslesen kann, wird denn bei jedem Abruf das INIT (in diesem Fall "/?!" plus CR+LF) gesendet?
Danke und Gruß
Matthias
Hallo Leute,
Wer kann helfen?
Ist es möglich die Readings in der 47_OBIS.pm in Nummerische Werte zu ändern. Die aktuellen Werte lassen sich leider Mathematisch nicht ohne Fehler verarbeiten.
Was muss im Modul 47_OBIS.pm geändert werden damit es nur Zahlen ausgibt, die mathematisch verarbeit werden können?
Hier die Ausgabe aus der LOG:
2022.09.23 18:01:46 1: PERL WARNING: Argument "5317116.92743 Wh" isn't numeric in multiplication (*) at (eval 2357) line 2.
2022.09.23 18:01:46 1: stacktrace:
2022.09.23 18:01:46 1: main::__ANON__ called by (eval 2357) (2)
2022.09.23 18:01:46 1: (eval) called by ./FHEM/33_readingsGroup.pm (357)
2022.09.23 18:01:46 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (1445)
2022.09.23 18:01:46 1: main::readingsGroup_Notify called by fhem.pl (3961)
2022.09.23 18:01:46 1: main::CallFn called by fhem.pl (3873)
2022.09.23 18:01:46 1: main::DoTrigger called by fhem.pl (4976)
2022.09.23 18:01:46 1: main::readingsEndUpdate called by ./FHEM/47_OBIS.pm (733)
2022.09.23 18:01:46 1: main::OBIS_Parse called by ./FHEM/47_OBIS.pm (340)
2022.09.23 18:01:46 1: main::OBIS_Read called by fhem.pl (3961)
2022.09.23 18:01:46 1: main::CallFn called by fhem.pl (782)
Ich habe es selber gefunden es muss "unitReading off" definiert werden.
Der Standart ist wohl "ON".
@Matthias182
Offenbar nutzen einige dieses Modul um einen solchen Zähler auszulesen. Schau dir mal diese Beiträge an:
https://forum.fhem.de/index.php?topic=60313.0 (https://forum.fhem.de/index.php?topic=60313.0)
Bei mir ist dieser als Einspeisezähler verbaut. Deshalb wäre es für mich auch sehr interressant, ob es so möglich ist!
Gruß
Zitat von: kabanett am 25 September 2022, 15:23:06
@Matthias182
Offenbar nutzen einige dieses Modul um einen solchen Zähler auszulesen. Schau dir mal diese Beiträge an:
https://forum.fhem.de/index.php?topic=60313.0 (https://forum.fhem.de/index.php?topic=60313.0)
Bei mir ist dieser als Einspeisezähler verbaut. Deshalb wäre es für mich auch sehr interressant, ob es so möglich ist!
Gruß
Hallo kabanett,
also ich habe das ganze Wochenende probiert, aber es mit dem OBIS Modul nicht zum Laufen bekommen. Bin leider nicht so gut im Lesen von Quellcode, aber ich vermute nach wie vor, dass die vom Zähler erwartete INIT Zeichenfolge nur beim Öffnen des Ports gesendet wird und danach nicht mehr. Der Zähler wartet jedoch genau auf diese Zeichenfolge bevor er einmal seine Daten zurückgibt.
Ich habe jetzt den VZLogger installiert und damit geht das einwandfrei zusammen mit dem Modul VZLOGGER für FHEM am Laufen. Damit geht das wunderbar und ist auch nur ein klein wenig mehr Arbeit.
Gruß
Matthias
Ok Danke!!!
Sehr schade :( Noch eine externe Software um Daten mit Fhem verarbeiten zu können..... Da muss ich mal schauen.
Ich bestell mir einen Lesekopf und probier mich mal durch. ;)
Schon mal gut zu wissen dass es mit VZLogger definitiv funktioniert. :)
Gruß
Hallo,
ich habe mich durch alle Seiten durchgekämpft und keine zufriedene Lösung gefunden.
Den Lesekopf betreibe ich an einem Elster AS1440 Stromzähler über einen ESP mit easyesp.
Die Readings (es kommen viele an) bekomme ich nur eingelesen wenn ich sie über Telnet anschubse, danach wird nur noch das Reading Version ( ELS5\@V9.34) regelmäßig in FHEM eingelesen.
Telnet selber macht auch nur einen Durchlauf und hält dann an.
Kann es sein das ich den Pin-Code doch benötige ? - dachte eigentlich das ich den nicht brauche weil ich ja Readings ja einlesen kann.
Hier noch meine Config:
define haus.stromzaehler OBIS 192.168.178.85:23 AS1440
setuuid haus.stromzaehler 63396c09-f33f-8371-8ec5-ff675af7495336b8
attr haus.stromzaehler interval 30
attr haus.stromzaehler pollingMode on
attr haus.stromzaehler room Energie
attr haus.stromzaehler unitReadings on
attr haus.stromzaehler verbose 5
habe alle Variationen durchprobiert auch mit anderen Modulen (SML, Standard, VSM102, E110, AS1440)
Gruß Jürgen
Mein Zähler ist von ISKRA - keinen Schimmer was der AS1440 so verlangt...
Vielleicht hilft https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#quellen (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440#quellen) weiter. Unten sind dort Quellen angegeben.
ZitatÜber die Frontschnittstelle kann mittels IR-Schreib-Lesekopf bei 300bd, 7E1 kommuniziert werden.
Der Zähler muss erst mittels Initiaslisierungssequenz ,,/?!" angesprochen werden bevor er sendet.
Der ist wohl etwas umständlicher als ein ISKRA anzusprechen.
Gruß Ralf
Ich habe es nach Stundenlangen probieren jetzt halbwegs hinbekommen,
mit dem Elster AS 1440 Stromzähler und der ESP /Raspi Kombination.
Habe den Tipp der hier auf den ersten Seiten steht eine alte OBIS Version verwendet mit VSM102, vom Januar oder Februar 2017. - kann ich gerade nicht genau sagen, bin nicht zu Hause.
Damit bekam ich aber nicht alle Readings angezeigt, es fehlten z.b Gesamtverbrauch/Gesamteinspeisung.
Ich habe den d0 Sensor jetzt direkt über USB an den Raspi angeschlossen, das hat sofort funktioniert.
Hallo,
erstmal ein Danke, das Modul klappt super. Ich hätte nur einen vorschlag zur ergänzung bzw. sonst zur infromation.
Man kann mit einem IR-Lesekopf wenn der ganz normal mit RX/TX angeschlossen ist auch ohne viel aufwand den Pin eingeben oder den Zähler steuern.
Da es schnell gehen sollte hab ich mir ein bash script gebaut, vielleicht liese sich das in perl übertragen:
#!/bin/sh
alias pin_blink="dd if=/dev/zero of=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 count=1"
#alias pin_blink="echo \"*\""
pin_blink
sleep 4
for i in $(seq $1); do pin_blink; sleep 1; done
sleep 2
for i in $(seq $2); do pin_blink; sleep 1; done
sleep 2
for i in $(seq $3); do pin_blink; sleep 1; done
sleep 2
for i in $(seq $4); do pin_blink; sleep 1; done
sleep 2
mit
alias pin_blink="dd if=/dev/zero of=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 count=1"
alias pin_blink_l="dd if=/dev/zero of=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 count=10"
konnte dann in der shell ein kurzes oder langes blinken ausgelöst werden.
Zumindest bei meiner Kombination aus Zähler und Lesekopf hat es wunderbar geklappt. Wollte nur nicht den zähler abnehmen um dann händisch das reinzublinken (wäre schneller gegangen aber es musste auch so gehen).
Vielleicht landet es im Modul oder hilft wem den Pin bequemer einzugebe
Hallo zusammen,
ich bin dabei von einem RasPi 3+ auf einen 4er zu wechseln.
Auf beiden läuft Raspbian GNU/Linux 10 (buster), auf dem 4er habe ich fhem frisch installiert.
An meinem EasyMeter habe ich eine Eigenbau-Lesekopf auf Esp-Basis, der die Daten per esp-link zur Verfügung stellt, funktioniert seit ein paar Jahren problemlos.
Das OBIS-Modul habe ich per Raw-Definition auf den 4er umgezogen, inkl. ElectricityCalculator.
Nun werden auf dem neuen System aber keine Events mehr gefeuert. Neu Daten erhalte ich nur, wenn ich fhem neu starte.
Hat jemand eine Idee, woran das liegen könnte?
List OBIS:
Internals:
DEF 192.168.XXX.XXX:23 SML
DeviceName 192.168.XXX.XXX:23
FD 37
FUUID 6354e897-f33f-e471-a7e7-46e680b14bc1afb0
MeterType SML
NAME EasyMeter
NR 277
PARTIAL
STATE opened
TYPE OBIS
eventCount 2
Helper:
DBLOG:
total_consumption_CounterCurrent:
myDbLog:
TIME 1666515981.60782
VALUE 10013.000
total_consumption_EnergyDay:
myDbLog:
TIME 1666515981.60782
VALUE 7.000
READINGS:
2021-02-16 18:56:55 1.0.0.0.9.255 09-01-45-53-59-11-03-A9-30-5E
2021-02-16 18:56:55 129.129.199.130.3.255 ESY
2020-03-13 19:01:21 129.129.199.240.6.255 1
2022-10-23 12:01:16 Feeding 1
2022-10-23 12:01:16 ManufID ESY
2022-10-23 12:01:16 Serial 09-01-45-53-59-11-03-A9-30-5E
2021-04-02 08:15:04 Version
2022-10-23 11:06:21 state opened
2022-10-23 12:01:16 total_consumption 10013000
2022-10-23 11:06:21 total_consumption_CounterCurrent 10013.000
2022-10-22 09:23:18 total_consumption_CounterDay1st 10006.000
2022-10-22 09:23:18 total_consumption_CounterDayLast 9996.000
2022-05-01 00:27:49 total_consumption_CounterMeter1st 8916.000
2022-05-01 00:27:49 total_consumption_CounterMeterLast 8915.000
2022-10-01 01:49:47 total_consumption_CounterMonth1st 9838.000
2022-10-01 01:49:47 total_consumption_CounterMonthLast 9837.000
2022-01-01 02:22:11 total_consumption_CounterYear1st 7466.000
2022-01-01 02:22:11 total_consumption_CounterYearLast 7465.000
2022-10-23 11:06:21 total_consumption_EnergyCostDay 2.015
2022-10-22 09:23:18 total_consumption_EnergyCostDayLast 0.864
2022-10-23 11:06:21 total_consumption_EnergyCostMeter 315.826
2022-05-01 00:27:49 total_consumption_EnergyCostMeterLast 1111.772
2022-10-23 11:06:21 total_consumption_EnergyCostMonth 50.383
2022-10-01 01:49:47 total_consumption_EnergyCostMonthLast 50.095
2022-10-23 11:06:21 total_consumption_EnergyCostYear 733.281
2022-01-01 02:22:11 total_consumption_EnergyCostYearLast 1115.114
2022-10-23 11:06:21 total_consumption_EnergyDay 7.000
2022-10-22 09:23:18 total_consumption_EnergyDayLast 3.000
2022-10-23 11:06:21 total_consumption_EnergyMeter 1097.000
2022-05-01 00:27:49 total_consumption_EnergyMeterLast 3992.000
2022-10-23 11:06:21 total_consumption_EnergyMonth 175.000
2022-10-01 01:49:47 total_consumption_EnergyMonthLast 174.000
2022-10-23 11:06:21 total_consumption_EnergyYear 2547.000
2022-01-01 02:22:11 total_consumption_EnergyYearLast 4004.000
2022-10-23 11:06:21 total_consumption_FinanceReserve 392.369
2022-10-23 11:06:21 total_consumption_MonthMeterReading 6
2022-10-23 11:06:21 total_consumption_PowerCurrent 0.506
2022-10-23 11:06:21 total_consumption_PowerDayAver 0.397
2022-10-23 11:06:21 total_consumption_PowerDayMax 0.506
2022-10-23 09:07:53 total_consumption_PowerDayMin 0
2022-10-23 12:01:16 total_feed 250000
helper:
BUFFER v ESYA0^ R�bbrcvESYESYp�R� ESY�0^c��v ESYA0^ R�bbrcw
DIRECTIONSUM
EoM 0
LastPacketTime 1666519276.71967
NETDEV 1
SPEED 5
TRIGGERTIME 1666515972.5689
Channels:
129.129.199.240.6.255 Feeding
DEVICES:
0
RULECACHE:
1-0:0.0.9*255 Serial
1-0:1.8.0*255 Counter
1-0:2.8.0*255 Counter
129-129:199.130.3*255 ManufID
directions:
Attributes:
DbLogExclude .*
DbLogInclude total_consumption_CounterCurrent,total_consumption_EnergyDay,total_feed,Feeding
channels {"129.129.199.240.6.255"=>"Feeding"}
comment Neuer Zähler am 18.02.2020, Zählerstand 0
event-on-change-reading .*
mqttPublish total_consumption_EnergyDay:topic={"/SmartHome/$device/$reading"}
pollingMode off
resetAfterNoDataTime 10800
room 20_werkstatt
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
List ElectricityCalculator:
Internals:
DEF EasyMeter:total_consumption:.*
FUUID 6354e8a8-f33f-e471-68ff-92460edf74b882c0
NAME EasyMeterCalculator
NOTIFYDEV EasyMeter
NR 278
NTFY_ORDER 10-EasyMeterCalculator
REGEXP EasyMeter:total_consumption:.*
STATE active
TYPE ElectricityCalculator
READINGS:
2020-02-21 15:44:11 EasyMeter_total_consumption_CounterCurrent 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDay1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDayLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeter1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeterLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonth1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonthLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYear1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYearLast 39000.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_FinanceReserve 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_MonthMeterReading 10
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerCurrent 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerDayAver 0.000
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMax 0
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMin 0
helper:
gets:
2020-02-21 15:44:11 EasyMeter_total_consumption_CounterCurrent 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDay1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDayLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeter1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeterLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonth1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonthLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYear1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYearLast 39000.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_FinanceReserve 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_MonthMeterReading 10
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerCurrent 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerDayAver 0.000
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMax 0
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMin 0
sets:
2020-02-21 15:44:11 EasyMeter_total_consumption_CounterCurrent 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDay1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterDayLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeter1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMeterLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonth1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterMonthLast 39000.000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYear1st 39000
2020-02-21 15:44:04 EasyMeter_total_consumption_CounterYearLast 39000.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyCostYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyDay 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMeter 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyMonth 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_EnergyYear 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_FinanceReserve 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_MonthMeterReading 10
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerCurrent 0.000
2020-02-21 15:44:11 EasyMeter_total_consumption_PowerDayAver 0.000
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMax 0
2020-02-21 15:44:04 EasyMeter_total_consumption_PowerDayMin 0
system:
DecimalPlace %.3f
SiPrefixPowerFactor 1000
Attributes:
BasicPricePerAnnum 83.61
Currency €
DbLogExclude .*
DecimalPlace 3
ElectricityCounterOffset 0
ElectricityKwhPerCounts 0.001
ElectricityPricePerKWh 0.2879
MonthOfAnnualReading 5
MonthlyPayment 125.0
ReadingDestination CounterDevice
SiPrefixPower kW
comment Ab 01.11.2022 38,63 Cent/kWh
room 20_werkstatt
Hallo,
ich habe nochmal alle Definitionen bez. OBIS und dem dazugehörigen ElectricityCalculator entfernt, diesesmal auch
alle Einträge aus der fhem.save, und nach einem Neustart von fhem wieder definiert.
Jetzt scheint alles wieder wie gewohnt zu funktionieren.
Danke an alle, die sich bereits Gedanken dazu gemacht haben.
LG
ergerd
Hallo,
ich habe heute einen LOGAREX Zähler verbaut bekommen und auch gleich meinen Hichi USB Lesekopf angebracht.
In FHEM dann mittels:
defmod Zaehler_WP OBIS /dev/ttyUSB0@9600 SML
attr Zaehler_WP DbLogInclude power,total_consumption
attr Zaehler_WP event-on-change-reading power.*:2.0,total_.*:5.0
attr Zaehler_WP interval 10
attr Zaehler_WP pollingMode on
attr Zaehler_WP room Heizung
attr Zaehler_WP unitReadings off
attr Zaehler_WP verbose 2
das Device angelegt und es kommen Daten an.
Jedoch steigt meine CPU Last auf dem Raspi4 auf ~30% an, vorher ~1% (perl/fhem).
PollingMode hab ich auf On
und
Intervall auf 10
Lösche ich das verbose 2 bekomme ich im LOG eine Flut an:
2nd TL-byte != 0, reserved according spec
je nachdem wie ich Intervall einstelle.
Hat da jemand eine Idee?
Gruß
Jan
Hallo Jan,
ich hatte beim ersten Einsatz von OBIS ein ähnliches Problem, bei mir hat
pollingMode=off
Abhilfe gebracht.
Grüße
ergerd
Danke für den Tipp, leider macht es keinen Unterschied in der CPU Last.
Fühlt sich so an als ob PollingMode im Verbindung mit Interval zwar funktioniert, es jedoch keinen positiven Einfluss auf die CPU Last hat.
Hier meine Definition meines OBIS Device. Vielleicht kannst du davon etwas ableiten:
defmod EasyMeter OBIS 192.168.xxx.xxx:23 SML
attr EasyMeter userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr EasyMeter DbLogExclude .*
attr EasyMeter DbLogInclude total_consumption_CounterCurrent,total_consumption_EnergyDay,total_feed,Feeding
attr EasyMeter channels {"129.129.199.240.6.255"=>"Feeding"}
attr EasyMeter comment Neuer Zähler am 18.02.2020, Zählerstand 0
attr EasyMeter event-on-change-reading .*
attr EasyMeter mqttPublish total_consumption_EnergyDay:topic={"/SmartHome/$device/$reading"}
attr EasyMeter pollingMode off
attr EasyMeter resetAfterNoDataTime 10800
attr EasyMeter room 20_werkstatt
Hallo, danke für deine Hilfe, das verändert leider nichts. Der verbaute Zähler scheint soviel zu babbeln, dass dadurch die CPU Last hoch geht.
Nun weiß ich leider nicht wie ich das in den Griff kriegen soll. Vielleicht hat ja noch jemand eine Idee.
Hallo, nach der Installation einer Solaranlage, wurden die Zähler getauscht. Da ich zwei Tarife habe (Wärmepumpen Tarif) gibt es auch zwei Zähler.
Der Erste zählt den gesamten Strom (WP-Strom und Hausstrom) und ist wegen der Rückspeisung ein Zweirichtungszähler.
Der zweite misst nur den Hausstrom. Über die Differenz der beiden Zählen kann der WP-Strom ermittelt werden -> Kaskadenschaltung.
Der Hausstrom Zähler ist ein Iskra MT681. Das Anbinden mit dem OBIS Modul hat direkt funktioniert.
Der Gesamtstrom Zähler ist ein Iskra MT691. Da klappt das Einbinden leider nicht. Die Pin Abfrage wurde deaktiviert und inf auf on gestellt.
Laut Volkszähler Wiki überträgt er die Daten per 8N1. Ich habe aber auch irgendwo gelesen, dass das Auslesen mit 8N0 funktioniert haben soll. Bei mir geht beides nicht.
Folgende Fehler werden im LogFile gemeldet:
2022.10.27 18:12:21 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2022.10.27 18:12:21 3: TCM TCM_ESP2_2 set reset
2022.10.27 18:12:21 2: TCM TCM_ESP2_2 get reset: Bogus answer received: 051BC1BB726201650043AF00220161A06800760500CB14B7620062007263070177010B0A0149534B00051BC1BB070100620AFFFF726201650043AF41757707010060320101010101010449534B0177070100600100FF010101010B0A0149534B00051BC1BB01
2022.10.27 18:12:22 3: TCM TCM_ESP2_2 get baseID
2022.10.27 18:12:22 2: TCM TCM_ESP2_2 get baseID: Bogus answer received: 77070100010800FF65001C410401621E52FF65002E119D0177070100020800FF0101621E52FF65003F1D6B0177070100100700FF0101621B520052120101016357F600760500CB14B86200620072630201710163A7330000001B1B1B1B1A024A46A55AAB5800000000000000000003
2022.10.27 18:12:22 2: TCM TCM_ESP2_2 initialized
2022.10.27 18:12:22 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2022.10.27 18:12:22 3: Setting TCM_ESP2_2 serial parameters to 9600,8,N,1
2022.10.27 18:12:22 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2022.10.27 18:12:22 3: TCM TCM_ESP2_2 set reset
2022.10.27 18:12:23 2: TCM TCM_ESP2_2 get reset: Bogus answer received: 1C410401621E52FF65000A01080066060000020800FF0101621E52FF65003F1D6B0177070100100700FF0101621B5200521101010163308800760500CB14BB620062007263020171016314CD0000001B1B1B1B1A026440
2022.10.27 18:12:23 3: TCM TCM_ESP2_2 get baseID
2022.10.27 18:12:23 2: TCM TCM_ESP2_2 get baseID: Bogus answer received: 1B1B1B1B01010101760500CB14BC6200620072000001540000050043B1940B0A0149534B00051BC1BB726201650043AF43620163011000760500CB14BD620062007263070177010B0A0149534B00051BC1BB070100620AFFFF726201650043AF43757707010060320101010101010449
2022.10.27 18:12:23 2: TCM TCM_ESP2_2 initialized
2022.10.27 18:12:23 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2022.10.27 18:12:23 3: Setting TCM_ESP2_2 serial parameters to 9600,8,N,1
2022.10.27 18:12:23 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2022.10.27 18:12:23 3: TCM TCM_ESP2_2 set reset
2022.10.27 18:12:24 2: TCM TCM_ESP2_2 get reset: Bogus answer received: 621E52FF65003F1D6B0177050000000400FF0101621B5200521901010163712300760500CB14BE6200620072630201710163D0C60000001B1B1B1B1A0269ED
2022.10.27 18:12:24 3: TCM TCM_ESP2_2 get baseID
2022.10.27 18:12:24 2: TCM TCM_ESP2_2 get baseID: Bogus answer received: 1B1B1B1B01010101760500CB14BF6200620072630101760101050043B1950B0A0149534B00051BC1BB7262016500502B5000402C4438405710A0394570118020007263070177010B0A0149534B00051BC1BB070100620AFFFF726201650043AF44757707010060320101010101010449534B0177070100600100FF010101010B0A
Hier noch der Device List:
Internals:
CFGFN ./energie.cfg
CRC_Errors 2
DEF /dev/ttyUSB2@9600,8,N,1 SML
DeviceName /dev/ttyUSB2@9600,8,N,1
FD 52
FUUID XXX
MeterType SML
NAME myGesamtStrom
NR 1113
PARTIAL
STATE opened
TYPE OBIS
eventCount 50
READINGS:
2022-10-27 18:11:29 1.0.96.1.0.255 ISK
2022-10-27 18:11:29 ManufID2 ISK
2022-10-27 18:11:29 power -905
2022-10-27 18:11:48 state opened
2022-10-27 18:11:29 total_consumption 301915.2
2022-10-27 18:11:29 total_feed 413628.5
helper:
BUFFER v�Pbv�SbbrcvC�q
ISK��rbeC� bc �v�Tb��b
��rbeC� uw`2��b
��rbeC�!uw`2ISKw`�
ISK��w�e Qb Rv�Ybbrcv�rbeC�#bc=@v�]bbrcw
ISK��b
��rbeC�#uw`2ISKw`�
ISK��w�e yb R�e.�
DIRECTIONSUM <
EoM 0
LastPacketTime 1666887089.03251
SPEED 5
SPEED2 5
TRIGGERTIME 1666887083.38103
Channels:
DEVICES:
-1
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
directions:
Attributes:
group STROMZAELER
room Energie
verbose 3
In einem Photovoltaikforum habe ich gelesen, dass die Zähler je nach Versorger unterschiedlich programmiert bzw. konfiguriert werden. Da war auch von variabler Datenlänge die Rede. Könnte das hier auch der Fall sein und wird das vom OBIS Modul unterstützt?
Was könnte ich falsch gemacht haben?
Gruß,
Rainer
Zitat von: Jasimo am 27 Oktober 2022, 15:15:17
Danke für den Tipp, leider macht es keinen Unterschied in der CPU Last.
Fühlt sich so an als ob PollingMode im Verbindung mit Interval zwar funktioniert, es jedoch keinen positiven Einfluss auf die CPU Last hat.
Hab mal zum Test das "alte" 70_SMLUSB aktiviert, da ist komischerweise die CPU-Last bedeutend geringer.
@Icinger kannst du dir das mal ansehen?
Gruß
Jan
Hallo zusammen,
wie hier angedroht https://forum.fhem.de/index.php/topic,51948.1425.html (https://forum.fhem.de/index.php/topic,51948.1425.html)
hab ich mir einen Lesekopf besorgt um meinen Itron ACE3000 Zähler auszulesen.
Im gegesatz zu Matthias182, funktioniert es bei mir. Eine kleines Problem hab ich aber doch.
Ich würde den Zähler gern alle 10 Minuten auslesen. Stell ich den Intervall auf 600, wird mir der Log minütlich vollgemüllt bis zur nächsten Abfrage usw. usw. usw.
2022.10.29 13:55:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 139 seconds, resetting connection
2022.10.29 13:55:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:55:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:55:26 3: ESPEasy Zirkulationspumpe: set Zirkulationspumpe event anschalten
2022.10.29 13:56:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 199 seconds, resetting connection
2022.10.29 13:56:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:56:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:57:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 259 seconds, resetting connection
2022.10.29 13:57:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:57:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:57:16 1: 192.168.44.19:23 disconnected, waiting to reappear (Stromzaehler_Dachsolar)
2022.10.29 13:57:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:57:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:58:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 319 seconds, resetting connection
2022.10.29 13:58:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:58:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:58:16 1: 192.168.44.19:23 disconnected, waiting to reappear (Stromzaehler_Dachsolar)
2022.10.29 13:58:17 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:58:17 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 13:59:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 379 seconds, resetting connection
2022.10.29 13:59:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 13:59:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 14:00:00 3: ESPEasy Zirkulationspumpe: set Zirkulationspumpe event anschalten
2022.10.29 14:00:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 439 seconds, resetting connection
2022.10.29 14:00:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 14:00:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 14:00:26 3: ESPEasy Zirkulationspumpe: set Zirkulationspumpe event ausschalten
2022.10.29 14:01:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 499 seconds, resetting connection
2022.10.29 14:01:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 14:01:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 14:01:26 3: ESPEasy Zirkulationspumpe: set Zirkulationspumpe event anschalten
2022.10.29 14:02:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 559 seconds, resetting connection
2022.10.29 14:02:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 14:02:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
2022.10.29 14:05:16 3: OBIS (Stromzaehler_Dachsolar) - No data received for 139 seconds, resetting connection
2022.10.29 14:05:16 3: OBIS (Stromzaehler_Dachsolar) - Init done
2022.10.29 14:05:16 1: 192.168.44.19:23 reappeared (Stromzaehler_Dachsolar)
Bleibe ich unter diesen 139 Sekunden, habe ich das nicht!?
Was mach ich da falsch?
Zur Info ein List des Devices.
Internals:
CFGFN
DEF 192.168.44.19:23 VSM102
DeviceName 192.168.44.19:23
FD 137
FUUID 635c127f-f33f-0fc8-0534-d8d081df9f162704
MeterType VSM102
NAME Stromzaehler_Dachsolar
NR 388228
PARTIAL
STATE opened
TYPE OBIS
eventCount 2605
.attraggr:
.attrminint:
READINGS:
2022-10-29 16:28:16 1.8.0 6
2022-10-29 16:28:17 2.8.0 50840.4
2022-10-29 16:28:15 C.1 1126120053388879
2022-10-29 16:28:16 C.5.0 1
2022-10-29 16:28:13 Version ACE0\3k260V01.19
2022-10-29 14:12:17 state opened
helper:
BUFFER
EoM 1
LastPacketTime 1667053697.89545
NETDEV 1
SPEED 5
TRIGGERTIME 1667045591.85475
Channels:
DEVICES:
/?!
60
050
RULECACHE:
1.8.0 unknown
2.8.0 unknown
C.1 unknown
C.5.0 unknown
Attributes:
icon measure_power_meter@green
interval 60
pollingMode on
Zitat von: XBuschman am 27 Oktober 2022, 20:11:04
... Der Gesamtstrom Zähler ist ein Iskra MT691. Da klappt das Einbinden leider nicht. Die Pin Abfrage wurde deaktiviert und inf auf on gestellt.
Laut Volkszähler Wiki überträgt er die Daten per 8N1. Ich habe aber auch irgendwo gelesen, dass das Auslesen mit 8N0 funktioniert haben soll. Bei mir geht beides nicht.
Folgende Fehler werden im LogFile gemeldet:
....
2022.10.27 18:12:23 2: TCM TCM_ESP2_2 get baseID: Bogus answer received: 1B1B1B1B01010101760500CB14BC6200620072000001540000050043B1940B0A0149534B00051BC1BB726201650043AF43620163011000760500CB14BD620062007263070177010B0A0149534B00051BC1BB070100620AFFFF726201650043AF43757707010060320101010101010449
...
Ich habe meinen MT691 über Tasmota (auf ESP8266) angebunden. Da wird nur die Baudrate 9600 eingestellt und Parität/Stoppbits nicht (ist vermutlich bei der Definition SML vorgegeben). Klappt!
Zumindest scheinen deine Einstellungen auf dem Serial-Interface in Ordnung zu sein, da die Daten nach SML Protokoll aussehen. Sieh mal hier:
http://www.stefan-weigert.de/php_loader/sml.php (http://www.stefan-weigert.de/php_loader/sml.php)
Eventuell sind es tatsächlich veränderte Datenformate die das Modul nicht versteht.
Gruß Ralf
Zitat von: RalfRog am 30 Oktober 2022, 18:25:59
Ich habe meinen MT691 über Tasmota (auf ESP8266) angebunden. Da wird nur die Baudrate 9600 eingestellt und Parität/Stoppbits nicht (ist vermutlich bei der Definition SML vorgegeben). Klappt!
Zumindest scheinen deine Einstellungen auf dem Serial-Interface in Ordnung zu sein, da die Daten nach SML Protokoll aussehen. Sieh mal hier:
http://www.stefan-weigert.de/php_loader/sml.php (http://www.stefan-weigert.de/php_loader/sml.php)
Eventuell sind es tatsächlich veränderte Datenformate die das Modul nicht versteht.
Gruß Ralf
Da in Bezug auf das SML Protokoll zumindest Teile der Daten sinnvoll aussehen, würde ich auch vermuten, dass die Einstellungen so weit passen. Würde aber bedeuten, dass der Zähler die Daten in einem Format überträgt, welches das OBIS Modul nicht interpretieren kann.
Was habe ich denn jetzt für Möglichkeiten an weitere Infos dranzukommen? Bzw. was könnte ich tun, um der Ursache näher zu kommen?
Danke und Gruß,
Rainer
Hallo zusammen, ich bin seit Jahren ein eifriger FHEM-Nutzer und profitiere sehr stark von der Kompetenz der Forum-Autoren. Das ist mein erster eigener Beitrag, weil ich Perl nur rudimentär beherrsche und mit diesem Problem nicht weiter komme.
Ich habe seit ca. 4 Jahren einen Hauszähler von Logarex Typ LK13BE803039. Nach der Installation durch das EVU habe ich mir einen optischen Lesekopf besorgt und die Daten problemlos über das OBIS-Modul eingelesen. Nach ca. 2 Jahren gab die optische Schnittstelle des Zählers den Geist auf. Ich habe mir die RS485 des Zählers anschließen lassen. Leider werden nur sporadisch, alle paar Stunden mal Daten übertragen bei polling=on und intervall=15 s. Ich habe im OBIS-Modul die Log-Einträge etwas erweitert, um zu verstehen, wo das Problem liegt.
Das Problem stellt sich wie folgt dar:
Nach dem Senden der Init-Sequenz /?! antwortet der Zähler jedesmal mit der Versionsnummer /LOG5LK13BE8. Danach wird vom OBIS-Modul ein String mit <ACK>050 (im Modul: chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)) gesendet. Daraufhin sollte der Zähler seine Messdaten schicken. Das macht er aber nur, wenn die 19 Zeichen mit der Version in einem Schritt übertragen wurden. In der Anlage ein Auszug aus der Log-Datei. Ab 19:12:03 überträgt er den Datensatz korrekt.
Kann mir jemand einen Tipp geben, wie sich das Problem beheben lässt?
Zitat von: XBuschman am 02 November 2022, 12:54:21
Was habe ich denn jetzt für Möglichkeiten an weitere Infos dranzukommen? Bzw. was könnte ich tun, um der Ursache näher zu kommen?
Danke und Gruß,
Rainer
Tja...
Ich habe kurz mal versucht deine Daten (sind ja nur Fragmente) etwas auseinander zu nehmen
(nach http://www.stefan-weigert.de/php_loader/sml.php (http://www.stefan-weigert.de/php_loader/sml.php)).
Das ist teilweise gut aber irgenwie scheint es dann im Verlauf "kaputt" zu sein - also doch eventuell Probleme mit den seriellen Daten.
Vielleicht versucht Du mal die Daten mit etwas anderem zu lesen als dem OBIS Modul.
Bei mir triggert Tasmota nur auf ein paar Datenfelder (z.B. Leistung, Energie) , die beginnen mit 77...
z.B. (entsprechend zu Zeilen 56 bis 63 aus dem Link oben )
17:08:35.773 : 77 07 01 00 01 08 00 ff 65 00 1c 80 04 01 62 1e 52 ff 65 0f 6b 47 bf 01
==> Scaler ff = -1 entspricht 10hoch-1 = 0,1
==> Unit 1e = Wh
==> OBIS Kzahl Vorwert
==> OBIS Kzahl 01.08.00 Summe_Wirkarbeit_zum Kunden. Zählerstand.Total
==> OBIS Kzahl Kanal 0
==> OBIS Kzahl 1 = Strom
Zitat von: XBuschman am 02 November 2022, 12:54:21
Was habe ich denn jetzt für Möglichkeiten an weitere Infos dranzukommen? Bzw. was könnte ich tun, um der Ursache näher zu kommen?
Hast du, um einen Fehler der Leseköpfe auszuschließen, schon mal den Lesekopf vom MT681 auf dem MT691 probiert?
Gruß Ralf
Habe gerade mal versucht wie vorgeschlagen den Lesekopf zu tauschen. Dann ging plötzlich gar nichts mehr.
Über Logfile Einträge habe ich dann herausgefunden, dass irgendwie durch irgendwen ein TCM Device angelegt wurde, welcher auf dasselbe USB IF konfiguriert war.
Das TCM Device hat mir wohl bei der Kommunikation dazwischengefunkt. Nach dem Löschen des Devices funktioniert jetzt auch das Auslesen des MT691 :D
Was mich jetzt noch wundert, dass der Zähler nur "power" und die beiden Werte "gesamter Verbrauch" und "gesamte Einspeisung" ausgibt.
Ist der wohl durch den Versorger so "restriktiv" konfiguriert?
2022-11-06_17:13:21 myGesamtStrom ManufID2: ISK
2022-11-06_17:13:21 myGesamtStrom 1.0.96.1.0.255: ISK
2022-11-06_17:13:21 myGesamtStrom total_consumption: 382717.2
2022-11-06_17:13:21 myGesamtStrom total_feed: 445854.1
2022-11-06_17:13:21 myGesamtStrom power: 756
Meiner liefert sowieit ich mich erinnere auch nicht mehr.
Aktuelle Leistung und Gesamtverbrauch aka Zählerstand sowie eine Kennung (=ISK, kann man verschiedene Hersteller unterscheiden).
Bei dir dann noch Einspeisung, bei der natürlich die aktuelle Leistung interessant wäre. Oder (interessante Frage) werden deine Power-Werte negativ für Einspeisung
OBIS Kennnungen:
77070100010800ff Gesamt Verbrauch
77070100100700ff Aktuelle Leistung
7707010060320101 Service ID (ISK)
Es gab noch weitere Felder (wie z.B. Seriennummer etc.) die waren aber alle nicht interessant. Habe es aber auch nicht mehr im Detail parat.
Ja bei Einspeisung wird der power Wert negativ.
Hallo!
Bei mir wurde vor einiger Zeit der Zähler gewechselt, daher musste ich bisschen was anpassen, scheitere aber an einer Ausgabe etwas.
Der neue Zähler ist ein DZG DWS7410.
Wie am untenstehenden Logauszug zu erkennen ist, erhalte ich beim Wert 1-0:1.8.0*255 immer ein Sonderzeichen > oder <, das da irgendwie nicht hin gehört.
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(<353884.9*Wh)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(<353884.9*Wh) is of type Counter
...
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>354774.9*Wh)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(>354774.9*Wh) is of type Counter
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZG*var)
1-0:1.8.0*255(<353884.9*Wh)
1-0:2.8.0*255(2968092.7*Wh)
1-0:16.7.0*255(625.65*W)
!
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: /
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(DZG*var)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(<353884.9*Wh)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(<353884.9*Wh) is of type Counter
2022.11.07 21:00:01 4: OBIS (Stromzaehler) - Set total_consumption to 353884.9
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(2968092.7*Wh)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(2968092.7*Wh) is of type Counter
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(625.65*W)
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(625.65*W) is of type Channels
2022.11.07 21:00:01 5: OBIS (Stromzaehler) - Msg-Parse: !
2022.11.07 22:00:00 5: DevIo_SimpleWrite Stromzaehler:
2022.11.07 22:00:00 4: OBIS (Stromzaehler) - Wrote
2022.11.07 22:00:00 5: OBIS (Stromzaehler) - Internal timer set to 2022-11-07 23:00:00
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605F792FD02620062007263010176010102310B0A01445A4700039E91AA72620164FF34966202636C53007605F892FD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF34967577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA0177070100010800FF641C01047262016200621E52FF643622650177070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE54031AC801010163F9AB007605F992FD026200620072630201710163464E000000001B1B1B1B1A035D03
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B010101017605F792FD02620062007263010176010102310B0A01445A4700039E91AA72620164FF34966202636C53007605F892FD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF34967577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA0177070100010800FF641C01047262016200621E52FF643622650177070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE54031AC801010163F9AB007605F992FD026200620072630201710163464E000000001B1B1B1B1A035D03
2022.11.07 22:00:01 4: OBIS (Stromzaehler) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZG*var)
1-0:1.8.0*255(>354774.9*Wh)
1-0:2.8.0*255(2968100.1*Wh)
1-0:16.7.0*255(2034.64*W)
!
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: /
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(DZG*var)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>354774.9*Wh)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg 1-0:1.8.0*255(>354774.9*Wh) is of type Counter
2022.11.07 22:00:01 4: OBIS (Stromzaehler) - Set total_consumption to 354774.9
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(2968100.1*Wh)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg 1-0:2.8.0*255(2968100.1*Wh) is of type Counter
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(2034.64*W)
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg 1-0:16.7.0*255(2034.64*W) is of type Channels
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - Msg-Parse: !
2022.11.07 22:00:01 3: ABFALL Muelltermine - CALENDAR:AbfallOTR triggered, updating ABFALL Muelltermine ...
2022.11.07 23:00:00 5: DevIo_SimpleWrite Stromzaehler:
2022.11.07 23:00:00 4: OBIS (Stromzaehler) - Wrote
2022.11.07 23:00:00 5: OBIS (Stromzaehler) - Internal timer set to 2022-11-08 00:00:00
2022.11.07 23:00:00 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B01010101760524BDFD02620062007263010176010102310B0A01445A4700039E91AA72620164FF42A6620263C0F700760525BDFD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF42A67577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA0177070100010800FF641C01047262016200621E52FF643646D20177070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE5373EF010101634A3A00760526BDFD0262006200726302017101634F42001B1B1B1B1A00EBDC
2022.11.07 23:00:00 5: OBIS (Stromzaehler) - Full message-> 1B1B1B1B01010101760524BDFD02620062007263010176010102310B0A01445A4700039E91AA72620164FF42A6620263C0F700760525BDFD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF42A67577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA0177070100010800FF641C01047262016200621E52FF643646D20177070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE5373EF010101634A3A00760526BDFD0262006200726302017101634F42001B1B1B1B1A00EBDC
2022.11.07 23:00:00 4: OBIS (Stromzaehler) - MSG IS:
/
Ich hatte bereits mit dem DZG-Support Kontakt, der mir hier aber auch keine Auskunft geben konnte. Es wird vermutet, dass einen Fehler in der SML-Auswertung vorliegt.
Um das Problem zu umgehen, habe ich statt Attribut "channels" jetzt ein userReadings definiert, um die Umbenennung zu machen. Soweit funktioniert das auch für mich zufriedenstellend.
Vielleicht findet aber jemand auch den Trick oder Fehler, wie man's wieder so wie gewollt machen kann. ;)
Hier noch mein List-Auszug:
Internals:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600Q878-if00-port0@9600,8,N,1 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600Q878-if00-port0@9600,8,N,1
FD 12
FUUID 5c47807b-f33f-869f-5416-785e24fa4e565b2c
MeterType SML
NAME Stromzaehler
NEXT 2022-11-08 20:00:00
NR 365
PARTIAL
STATE opened
TYPE OBIS
eventCount 41
READINGS:
2022-11-08 19:00:01 1.0.96.1.0.255 DZG
2022-11-08 19:00:01 Einspeisung_akt 2971.9201
2022-11-08 19:00:01 ManufID2 DZG*var
2022-11-08 19:00:01 Verbrauch_akt 365.0526
2022-11-08 19:00:01 power 536.82
2022-11-07 03:59:24 state opened
2022-11-08 19:00:01 total_consumption 365052.6
2022-11-08 19:00:01 total_feed 2971920.1
helper:
BUFFER
DIRECTIONSUM <
DZGHACK 1
EoM 1
LastPacketTime 1667930401.25753
SPEED 5
SPEED2 5
TRIGGERTIME 1667934000
Channels:
DEVICES:
3600
RULECACHE:
1-0:1.8.0*255 Counter
1-0:16.7.0*255 Channels
1-0:2.8.0*255 Counter
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
directions:
Attributes:
alignTime 00:00
devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
event-on-change-reading Verbrauch_akt,Einspeisung_akt
event-on-update-reading .*
icon black_Steckdose.on
interval 3600
pollingMode on
room Keller
userReadings Verbrauch_akt { ReadingsVal("Stromzaehler","total_consumption",0)/1000},Einspeisung_akt { ReadingsVal("Stromzaehler","total_feed",0)/1000}
verbose 0
Ciao
Tom
Zitat von: parabacus am 08 November 2022, 19:25:27
.....
Vielleicht findet aber jemand auch den Trick oder Fehler, wie man's wieder so wie gewollt machen kann. ;)
....
Ciao
Tom
Das ist doch im Log-Level 5 die Ausgabe des Parsers. Das ist bestimmt so gewollt von Icinger und steht nicht in deinen Daten, die sind korrekt ohne <.
(Zeile 54 http://www.stefan-weigert.de/php_loader/sml.php (http://www.stefan-weigert.de/php_loader/sml.php))
Wichtig ist doch, dass das Ergebnis korrekt dargestellt wird:
2022.11.07 21:00:01 4: OBIS (Stromzaehler) - Set total_consumption to 353884.9So steht es doch auch bestimmt im Reading, oder?
2022.11.07 22:00:01 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605F792FD02620062007263010176010102310B0A01445A4700039E91AA72620164FF34966202636C53007605F892FD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF34967577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA01 ----> 77070100010800FF641C01047262016200621E52FF6436226501 <---- 77070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE54031AC801010163F9AB007605F992FD026200620072630201710163464E000000001B1B1B1B1A035D0377
070100
010800FF --> OBIS Kennung bezogene Energie (Zählertstand)
641C0104
72
6201
6200
62
1E --> Einheit Wh
52
FF --> Faktor 0.1
64
362265 --> Wert 3547749
01
Gruß Ralf
Hallo Ralf,
sorry, vielleicht hab ich das nicht präzise genug beschrieben.
In der Vergangenheit hab ich mit Attribut "channels" die Umbenennung gemacht. Natürlich wollte ich das mit dem neuen Zähler ebenso tun, klappt aber nicht.
Zum Test hab ich das jetzt nochmal gemacht:
channels {"1-0:1.8.0*255"=>"Verbrauch_aktuell","1-0:2.8.0*255"=>"Einspeisung_aktuell"}
Das Ergebnis ist dann im Log folgendermassen:
2022-11-14_16:00:00 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_16:00:00 Stromzaehler Einspeisung_akt: 2976.9969
2022-11-14_17:00:01 Stromzaehler Verbrauch_aktuell: <445169.9
2022-11-14_17:00:01 Stromzaehler Einspeisung_aktuell: 2980974.2
2022-11-14_17:00:01 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_17:00:01 Stromzaehler Einspeisung_akt: 2976.9969
2022-11-14_18:00:01 Stromzaehler Verbrauch_aktuell: <445175.4
2022-11-14_18:00:01 Stromzaehler Einspeisung_aktuell: 2980994
2022-11-14_18:00:01 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_18:00:01 Stromzaehler Einspeisung_akt: 2976.9969
Wie du siehst, ist auch hier das Sonderzeichen mit enthalten. Im eigentlichen Reading total_consumption, total_feed und seltsamerweise mittels Attribut "channels" erzeugtem Reading Einspeisung_aktuell passt's - nur nicht im Reading Verbrauch_aktuell.
Ich hoffe, damit kann man das Problem jetzt genauer nachvollziehen.
Wie gesagt - mit einem selbst definierten userReadings kann ich einen Workaround machen, der für mich funktioniert.
Ciao
Tom
Zitat von: parabacus am 14 November 2022, 18:52:27
....
Wie du siehst, ist auch hier das Sonderzeichen mit enthalten. Im eigentlichen Reading total_consumption, total_feed und seltsamerweise mittels Attribut "channels" erzeugtem Reading Einspeisung_aktuell passt's - nur nicht im Reading Verbrauch_aktuell.
Ich hatte das Modul bisher nur für einen schnellen Test benutzt und keine Erfahrung mit dem Attribut Channels.
Ich denke so:
wenn die Original-Readings stimmen
2022-11-08 19:00:01 total_consumption 365052.6
2022-11-08 19:00:01 total_feed 2971920.1dann kommen doch vom Zähler die korrekten Werte ohne "Sonderzeichen".
Also liegt das zusätzliche Zeichen doch eher an dem, was durch die Definition von Channels passiert und eher im Modul.
Wenn man eine Lösung hat muss man die Sache ja nicht bis ins letzte klären... andererseits wenn es tatsächlich durch das Modul verursacht ist...
OBIS Modul geht auf disconnected, wenn die Perl Pakete für den Betrieb einer Withings Körperwaage installiert werden.
--------------------------------------------------------------------------------------------------------------------------------
Hintergrund: Ich habe das Obis Modul seit ettlicher Zeit einwandfrei in Betrieb an einem MT691 Zähler. Jetzt habe ich mir eine Withings Waage zugelegt, das entsprechene 32_withings.pm Modul installiert und laut Anweisung des Modulentwicklers die dazugehörigen Perl Pakete installiert.
sudo apt-get install libjson-perl libdigest-md5-file-perl liblwp-protocol-https-perl liblwp-protocol-http-socketunix-perl && sudo reboot
Nach dem reboot des Raspis steht sofort im state des Obis-Moduls "disconnected".
Ich habe daraufhin eine 2.SD-Karte ohne die "Withings-Pakete" versuchsweise im Raspi gestarted und Obis meldet "opend".
Wieso stören diese Pakete den Obis Betrieb und vor Allem, welche Abhilfsmassnahme gibt es dafür?
Gruß aus Köln
Norbert
Es wirkt sehr danach, als ob das neue Modul den Serial-Port belegt. Die Installation der Pakete allein löst (bei mir mit Rasbian Buster) zumindest nicht das Verhalten aus. Also würde ich prüfen, welchen Serial-Port das Modul verwendet.
Willst Du ausschließen, dass ein anderer Prozess sich den Serial-Port Deines SML-Readers geschnappt hat, könnte Dir fuser weiterhelfen:
Zitatroot@sauerberry:/opt/fhem/log# fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0
/dev/ttyUSB1: 1035
root@sauerberry:/opt/fhem/log# ps -ef | grep 1035
fhem 1035 1 21 13:35 pts/0 00:01:52 perl fhem.pl fhem.cfg
fhem 1379 1035 1 13:35 pts/0 00:00:07 node /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg
root 3653 908 0 13:43 pts/0 00:00:00 grep 1035
Nachdem ich gespielt hatte, lief zwar mein SML-Gerät, dafür aber nicht mehr Homematic und der Conbee-(Zigbee)-Stick.
Ich habe das Paket "modemmanager" deinstalliert, das sich an den Serial-Ports zu schaffen machte:
sudo apt-get remove modemmanager
Nach einem Reboot schnurrten die anderen Geräte wieder.
Ich werde mich heute nachmittag mal dransetzen, aber mir vorher eine SD Karten Kopie anlegen zum probieren.
Ich melde mich dann wieder.
Vielen Dank
Norbert
Ich habe wieder die Pakete geladen und sudo reboot gemacht und es kam wie erwartet disconnected.
Dann habe mit putty versucht den Lesekopf zu finden und es folgende Antwort:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 existiert nicht
Ein Neustart von FHEM und auch ein reload brachte nichts.
Ich habe daraufhin mal die Kabelverbindung zum Zähler im Keller unterbrochen und nach dem Einstecken kam diese Antwort:
pi@raspberrypi-pi4-master:~ $ fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0
pi@raspberrypi-pi4-master:~ $
Aber nach jedem reboot des raspis ist die Verbindung wieder weg, und auch kein shutdown restart hilft.Ich müßte also immer in den Keller um die Verbindung kurzzeitig zu unterbrechen. Dann wird der Lesekopf wieder erkannt.
Leider kann ich aber im Moment nicht mehr weiter suchen, weil mir die USB Steckerverbindung kaputt gegangen ist und ich muß erst eine neues Verbindungskabel besorgen.
Dann kann ich weitere Versuche starten.
Gruß
Norbert
Ich bin kein Guru des Betriebssystems. Aber mit meinen 2Ct: Solange das Gerät nicht im /dev-Filesystem auftaucht, ist das ein Problem auf Betriebssystemebene (unwahrscheinlicher) oder - wahrscheinlicher - physikalischer Hardware.
Zu langes Kabel, kaputtes Kabel, Stromversorgung überlastet, etc.
Bin da jetzt auch nicht der Spezialist aber vielleicht hilft es ja auch mal mit "dmesg" (alternativ gibt es journalctl) auf der Konsole zu schauen ob und was beim ziehen/stecken USB-seitig ab-/angemeldet wird.
Das Device muss ja beim Reboot am gleichen USB-Port angemeldert werden. Kann man mal suchen ob es dazu während des Bootens eine (Fehler)Meldung gibt.
Ziehen/Stecken müssten solche Meldungen sein:
[202276.456883] usb 1-1.3: USB disconnect, device number 7
[202276.458073] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[202276.458196] ftdi_sio 1-1.3:1.0: device disconnected
[202276.755751] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
[202276.913346] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[202276.913370] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[202276.913384] usb 1-1.3: Product: FT232R USB UART
[202276.913397] usb 1-1.3: Manufacturer: FTDI
[202276.913409] usb 1-1.3: SerialNumber: AL00F4TK
[202276.925488] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[202276.925772] usb 1-1.3: Detected FT232RL
[202276.927907] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
Dazu gehört dann im /dev-Filesystem (FT232 am USB 1-3.1):
pi@raspi-2:/opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Sep 30 02:13 usb-FTDI_FT232R_USB_UART_AL00F4TK-if00-port0 -> ../../ttyUSB0
pi@raspi-2:/opt/fhem $ ls -l /dev/serial/by-path/
insgesamt 0
lrwxrwxrwx 1 root root 13 Sep 30 02:13 platform-3f980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
Sinnvoll ist für eine eindeutige Zuordnung der USB/Seriell-Interfaces eine Definition über die ID - wie auch in der CommandRef erwähnt:
--> "or - to avoid wrong numbering on server reboots - use the ID of the USB device, e.g. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0"
@gvzdus
Das mit der Betriebsspannung habe ich von Anfang an schon mit einem seperatem Netzteil gelöst.
Ich hatte mir in meiner Werkstatt ein Splittkabel gebaut das Daten und Versorungsspannung getrennt zusammenführt.
Die Kabellänge habe ich mit einem aktiven USB Kabel gelöst, das einen "Verstärker" im Kabel besitzt. Das ist jetzt mech.defekt und ich habe ein Neues geordert.
Das war aber auch von Anfang an ohne Probleme im Einsatz.
@RalfRog
Das mit dem direkten zuordnen des Lesekopfes über serial/by-id werde ich ,sobald das Kabel ersetzt ist, probieren. Ich meine das hätte ich irgendwann mal probiert, als Anfangs das OBIS Modul immer mal hängenblieb. Hatte in dem Fall aber kein Unterschied gemacht.
--------------------------------------------------
Wie gesagt, wenn der Lesekopf wieder Verbindung zum Raspi hat, melde ich mich.
Gruß
Norbert
Viel Erfolg :)
aufgrund dieser Anmerkung von dir:
Zitat von: cocojambo am 29 November 2022, 20:13:05
Dann habe mit putty versucht den Lesekopf zu finden und es folgende Antwort:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 existiert nicht
Ein Neustart von FHEM und auch ein reload brachte nichts.
scheint das Interface ja seitens Betriebssystem weg zu sein. Daher die Idee sich mit "dmesg" mal anzuschauen wann das Interface verschwindet bzw. ob und wie es beim Reboot erkannt wird.
Vielleicht hatte das aktive Kabel ja ne Macke (nach "stromlos" erst wieder funktioniert) und alles ist mit nem neuen Kabel gut.
Das neue Kabel ist heute gekommen. Muß es erst aber durch den Kamin durchziehen.
Übrigens, der "USB Verstärker" und der Lesekopf werden ja nicht stromlos, da sie dauerhaft mit einem seperaten Netzteil versorgt werden.
Aber du hast recht, es könnte ja auch ein Defekt am Kabel sein.
Ich melde mich.
norbert
So Kabel drin und alles wieder angeschlossen, Neustart Raspi und der Lesekopf wird tatsächlich erkannt.
2022.12.02 15:06:23 3: Opening ISKRA_MT691 device /dev/ttyUSB0
2022.12.02 15:06:23 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Init done
2022.12.02 15:06:23 3: ISKRA_MT691 device opened
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Attr interval Val 30, dopoll =
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Attr pollingMode Val on, dopoll = 1
Auch ein shutdown restart bringt OBIS nicht durcheinander. Leider kann ich das alte Kabel nicht mehr vergleichsweise anschließen um zu sehen ob es daran liegt (habe ich zum Durchziehen zerteilt)
Hoffendlich bleibt es so.
Vielen Dank für Eure Ideen und Tipps
Norbert
Danke für das OBIS-Modul,
ich verwende es, seit einiger Zeit, für zwei Zähler (WS7412.2 und SGM-C4-1A620I). Mit dem SGM-C4.. funktioniert alles problemlos. Beim WS7412.2 gibt es ein Problem.
Im Bereich von ca.:327W bis ca. 680W werden negative Leistungswerte der Momentanleistung (power_L1) ausgegeben, die Absolutleistung (total_consumption) wird aber weiterhin richtig mit positiven Werten aufaddiert.
Habe ich etwas falsch konfiguriert?
define Stromzaehler_Solar OBIS /dev/ttyUSB1@9600,8,N,1 SML
attr Stromzaehler_Solar event-on-change-reading .*
attr Stromzaehler_Solar room Energie
attr Stromzaehler_Solar stateFormat {sprintf("Leistung_absolut: %.0f kWh",ReadingsVal($name,"total_consumption",0) / 1000)}
attr Stromzaehler_Solar userReadings Power_kW {sprintf(ReadingsVal($name,"power_L1",0) / 1000)},\
Leistung_absolut {sprintf(ReadingsVal($name,"total_consumption",0) / 1000)},\
Energietagesertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar', 'D_EnergieCNTATMIDNIGHT'));;},\
Energiemonatsertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar', 'D_EnergieCNTAT1STDAYOFMONTH'));;},\
Energiejahresertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar','D_EnergieCNTAT1STDAYOFYEAR'));;}\
Danke, qualifizierter Fehlerreport!
Der DZG-Zähler ist buggy, und es gibt einen Workaround dafür, der bisher aber nur für den Gesamtwert "power" greift.
Entweder, Du patcht per Hand Zeile 423 in 47_OBIS, oder Du machst morgen ein Update, ich committe gleich diesen Change:
423c423
< if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:[1357]6\.7\.0/ && $hash->{helper}{DZGHACK}) {
---
> if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) {
Danke gvzdus,
nach dem Einfügen von:
if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:[1357]6\.7\.0/ && $hash->{helper}{DZGHACK}) {
hatte ich noch nicht viele Werte über 330W. Da waren aber die negativen Werte weg. :D
Wenn ich mir eine graphische Darstellung von "power_L1" über einen etwas längeren Zeitraum ansehe, erkennt man einen alle ca. 10min regelmäßig wiederkehrenden Werteinbruch. Das muss aber nicht vom "OBIS-Modul" ausgelöst werden. Möglich ist auch ein Fehler vom WS7412.2 . Kennt jemand dieses Phänomen oder hat jemand eine Erklärung? siehe Dateianhang.
Ich würde eine Hässlichkeit des Wechselrichters mit in Betracht ziehen.
Gut geschlussfolgert gvzdus,
ich hatte vergessen zu erwähnen, dass es sich um den Einspeisezähler einer Solaranlage handelt. Der Wechselrichter macht alle 10min eine Prüfung der Einspeiseleitung. Dadurch entsteht der Leistungseinbruch.
Die negativen Leistungswerte sind nicht mehr aufgetaucht. Danke gvzdus.
@gvzdus: Ich habe bei mir das Problem, dass aufgrund einer Netzwerkverbindung über Powerline zu meinem Zähler (bzw. Lesekopf) immer wieder (vermeintlich) die Verbindung zum Zähler abbricht. Ich hatte testweise vor einer Woche mal einen Versuch gemacht, eine kleine Änderung in der Parse-Funktion vorzunehmen und diese läuft jetzt bei mir seitdem stabil.
sub OBIS_Parse($$)
{
my ($hash, $buf) = @_;
my $name = $hash->{NAME};
# added latpackettime on any received data
$hash->{helper}{LastPacketTime} = gettimeofday if ( length($buf) > 0 ) ;
# gvz Unsure what this is for
Eingefügt habe ich nur den Kommentar und das rücksetzen von LastPackTime auch wenn nur neue Daten empfangen wurden, aber noch kein vollständiges Datenpaket erhalten wurde. Vielleicht macht es ja Sinn das ins Modul zu übernehmen, denn nach meinem Verständnis ist das durchaus korrekt so.
Anmerkung: Ein Setzen des intervalls hat bei mir nicht geholfen.
Moin, das "interval" ist ja auch was ganz anderes: Da geht es darum, statt kontinuierlich die Daten zu lesen, nur alle z.B. 15 Minuten mal einen Stand zu holen.
Ich hab' mir mal kurz den Code angesehen, und ich würde die Änderung lieber nicht übernehmen, obwohl ich eigentlich sehr offen dafür bin. Der Timer ist ja dafür da, um die Verbindung nach bestem Wissen zu resetten, wenn kein vollständiges (parseable) Datenpaket für X Sekunden (nämlich das Attribut resetAfterNoDataTime oder alternativ 90 Sekunden Default) empfangen wurde.
Meine Sorge ist jetzt: Angenommen, es kommt wegen verstellter Initialisierung (Baudrate magisch verändert, whatever) auf einmal nur noch Schrott. Dann würde Deine Codeänderung nicht resetten, weil ja *irgendwas* ankam (auch, wenn es Schrott ist). Ich habe also die Sorge, dass möglicherweise eine "Selbstheilung" bei anderen nicht greifen würde.
Andererseits verstehe ich nicht ganz, was bei Dir das Problem mit dem Reset auslöst. Ein Reset sollte vielleicht mal 2-3 Messwerte überspringen, aber eigentlich die Situation verbessern. Hilft Dir vielleicht, das Attribut resetAfterNoDataTime hochzusetzen?
Oder hast Du eine Idee, warum der "Verzicht auf Reset" bei Dir hilft statt zu Problemen zu führen?
Hallo Forum,
ich weiß nicht genau, ob ich hier richtig bin, aber immerhin geht es um SML und Auslesen des Stromzählers.
Ich habe einen EMH-eHZ-Pxxx und seit gestern einen Hichi-IR-Lese-Schreibkopf.
Die Einbindung in FHEM hat Dank des OBIS-Modules schnell geklappt.
Die Zählerstände für Verbrauch und Einspeisung passen.
Aber:
bei "power" kommt nur ein niedriger Wert (der sich ständig ändert) von +/- 5 bis 10, selten auch mal Werte um 30.
Die Grundlast des Hauses liegt allerdings bei eher 150 - 400 W..
Es kommt wohl auch nicht viel mehr Information rüber, weil der Zähler das anscheinend nicht liefert ??
Fehlt etwas in meiner Konfiguration ??
define myPowerMeter OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0038-if00-port0@9600,8,N,1 SML
attr myPowerMeter event-on-change-reading .*
attr myPowerMeter extChannels auto
attr myPowerMeter interval 60
attr myPowerMeter room Strom
# DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0038-if00-port0@9600,8,N,1 SML
# DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0038-if00-port0@9600,8,N,1
# FD 53
# FUUID 63de6b5c-f33f-93ac-3f45-75c4a1166f8f7f75
# MeterType SML
# NAME myPowerMeter
# NR 928
# PARTIAL
# STATE opened
# TYPE OBIS
# eventCount 269
# READINGS:
# 2023-02-04 22:23:01 1.0.96.1.0.255 EMHT
# 2023-02-04 22:23:01 ManufID2 EMH
# 2023-02-04 22:23:01 power -4
# 2023-02-04 22:17:06 state opened
# 2023-02-04 22:23:01 total_consumption 4221209.5
# 2023-02-04 18:03:37 total_consumption.255 4221188.9
# 2023-02-04 22:23:01 total_feed 7918129
# 2023-02-04 18:03:37 total_feed.255 7918107
# helper:
# BUFFER
# DIRECTIONSUM <
# EoM 0
# LastPacketTime 1675545781.31254
# SPEED 5
# SPEED2 5
# TRIGGERTIME 1675545426.13803
# Channels:
# DEVICES:
#
# 0
#
# RULECACHE:
# 1-0:1.8.0*255 Counter
# 1-0:16.7.0*255 Channels
# 1-0:2.8.0*255 Counter
# 1-0:96.1.0*255 unknown
# 1-0:96.50.1*1 ManufID2
# 255-255:255.255.255*255 unknown
# directions:
#
setstate myPowerMeter opened
setstate myPowerMeter 2023-02-04 22:23:01 1.0.96.1.0.255 EMHT
setstate myPowerMeter 2023-02-04 22:23:01 ManufID2 EMH
setstate myPowerMeter 2023-02-04 22:23:01 power -4
setstate myPowerMeter 2023-02-04 22:17:06 state opened
setstate myPowerMeter 2023-02-04 22:23:01 total_consumption 4221209.5
setstate myPowerMeter 2023-02-04 18:03:37 total_consumption.255 4221188.9
setstate myPowerMeter 2023-02-04 22:23:01 total_feed 7918129
setstate myPowerMeter 2023-02-04 18:03:37 total_feed.255 7918107
Gruß
Michael
Sicherheitsfrage 1: Die PIN hast eingegeben? Ohne PIN würde ich erwarten, dass die Zählerstände nur kWh-genau sind (statt um 3-4 Zehnerpotenzen genauer), und ich wüsste nicht, was bei "power" rauskäme.
Deine Definition ist hilfreich, aber zur Analyse möchte ich Dich um
attr <devicename> verbose 5
bitten. Dann werden die Rohdaten so geloggt:
2023.02.04 22:49:11 5: OBIS (MT175) - Full message-> 1B1B1B1B010101017605084CB5C962006200726301017601010502C4
3C990B090149534B00047FE6A101016374BB007605084CB5CA620062007263070177010B090149534B00047FE6A1070100620AFFFF726
2016504B5C26F7D77078181C78203FF010101010449534B0177070100000009FF010101010B090149534B00047FE6A101770701000108
00FF650001018201621E52FF59000000000304F5BD0177070100010801FF0101621E52FF59000000000304F5BD0177070100010802FF0
101621E52FF5900000000000000000177070100020800FF0101621E52FF5900000000076636DF0177070100020801FF0101621E52FF5900000000076636DF0177070100020802FF0101621E52FF5900000000000000000177070100100700FF0101621B5200550000006D0177070100240700FF0101621B520055000000110177070100380700FF0101621B5200550000001E01770701004C0700FF0101621B5200550000003E0177078181C78205FF010101018302DE94C577CEBE72E879A9B3ACC50AF06D3DC27D8AD92DC1E29AA49BFD485357E4B589E527301B2D0EA6FA4FCE325CD969010101639401007605084CB5CB620062007263020171016379A2001B1B1B1B1A00FEE4
Mit den Rohdaten kann ich gucken, ob am Parser etwas schräg ist.
Danke für die schnelle Rückmeldung !
Ja PIN habe ich hineingemorst...
Hier ein Auszug aus den letzten Einträgen im logfile:
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: /
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 1-0:96.1.0*255(EMHT)
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 1-0:1.8.0*255(>4221299.8*Wh)
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg 1-0:1.8.0*255(>4221299.8*Wh) is of type Counter
2023.02.04 22:54:53 4: OBIS (myPowerMeter) - Set total_consumption to 4221299.8
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 1-0:2.8.0*255(7918130.4*Wh)
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg 1-0:2.8.0*255(7918130.4*Wh) is of type Counter
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 1-0:16.7.0*255(530*W)
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg 1-0:16.7.0*255(530*W) is of type Channels
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: 255-255:255.255.255*255()
2023.02.04 22:54:53 5: OBIS (myPowerMeter) - Msg-Parse: !
2023.02.04 22:54:54 5: OBIS (myPowerMeter) - SML-Parse 1B1B1B1B010101017605023E42EA6200620072630101760107FFFFFFFFFFFF0500BF6BA40B0A01454D48000080540A72620165056521276201636824007605023E42EB62006200726307017707FFFFFFFFFFFF0B0A01454D48000080540A070100620AFFFF72620165056521277577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000080540A0177070100010800FF641C01047262016505652127621E52FF6502841E880177070100020800FF017262016505652127621E52FF6504B835F80177070100100700FF0101621B520053020F01010163D60D007605023E42EC62006200726302017101638930001B1B1B1B1A00A6EA
2023.02.04 22:54:54 5: OBIS (myPowerMeter) - Full message-> 1B1B1B1B010101017605023E42EA6200620072630101760107FFFFFFFFFFFF0500BF6BA40B0A01454D48000080540A72620165056521276201636824007605023E42EB62006200726307017707FFFFFFFFFFFF0B0A01454D48000080540A070100620AFFFF72620165056521277577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000080540A0177070100010800FF641C01047262016505652127621E52FF6502841E880177070100020800FF017262016505652127621E52FF6504B835F80177070100100700FF0101621B520053020F01010163D60D007605023E42EC62006200726302017101638930001B1B1B1B1A00A6EA
2023.02.04 22:54:54 4: OBIS (myPowerMeter) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHT)
1-0:1.8.0*255(>4221300*Wh)
1-0:2.8.0*255(7918130.4*Wh)
1-0:16.7.0*255(527*W)
255-255:255.255.255*255()
!
1-0:16.7.0*255(527*W)
heißt, dass er 527 Watt als Wert dekodiert. Was kommt dann als Reading bei FHEM raus?
Verrückt !!
Seit heute Nachmittag ca. 14:00 Uhr kämpfe ich damit, daß bei "power" kein vernünftiger Wert kommt.
Jetzt (nach ~8h ) verbose =5 eingeschaltet
==> Es kommen vernünftige Werte, die auch mit dem übereinstimmen, was der Wechselrichter zeigt.
Ich bin verwirrt, aber auf höchstem Niveau !!
Reading ist im Anhang ...
Ich weiß zwar nicht warum, aber jetzt kommen vernünftige Werte.
Bleibt nur noch die Frage, ob von dem Zähler wirklich nicht mehr rüberkommt
(z.B. L1,L2,L3 ..)
Danke für die Unterstützung
MIchael
Ich hatte einen EMH-Zähler, und bei dem kamen auch keine Phasenwerte rüber.
Mit dem PV-Einbau bekam ich einen ISKRA-Zähler, der liefert Phasen. Das entspricht also meinen Erfahrungen.
:-X
jetzt weiß ich auch, warum con 14:00 bis ca. 23:00 Uhr der Zähler nur niedrige power-Werte gebracht hat:
da habe ich Strom von der Sonne und aus der Batterie gehabt.
(siehe Anlage)
Erst ab ca. 23:00 Strombezug, der am Zähler angezeift werden konnte...
@Mni: Mit was malst du den Graph? Sieht toll aus.
Gruß,
Stefan
Hallo zusammen,
ich habe seit zwei Tagen einen Picus Stromzähler von Apator verbaut bekommen.
Nun versuche ich verzweifelt die Momentanleistung auszulesen, was mir aber nicht gelingt.
PIN habe ich eingegeben und im Zähler sehe ich die aktuelle Leitung auch, aber leider nicht in FHEM.
Welche Möglichkeiten gibt es an diesen Wert zu kommen?
Hier der Auszug aus dem Log bei verbose=5
2023.02.08 12:37:53 5: SW:
2023.02.08 12:37:53 4: Wrote
2023.02.08 12:37:53 5: OBIS (Strom) - Internal timer set to 2023-02-08 12:39:53
2023.02.08 12:37:55 5: OBIS (Strom) - SML-Parse 1B1B1B1B0101010176050007D4FF620162007265000001017601010500029C550B0A014150410100E525E57262016500029C570163F5000076050007D5006201620072650000070177010B0A014150410100E525E5070100620AFFFF7262016500029C5774770701006032010101010101044150410177070100600100FF010101010B0A014150410100E525E50177070100010800FF65001CE10401621E520369000000000000002D0177070100020800FF0101621E520369000000000000000101010163BB1C0076050007D50162016200726500000201710163BB000000001B1B1B1B1A0221EE
2023.02.08 12:37:55 5: OBIS (Strom) - Full message-> 1B1B1B1B0101010176050007D4FF620162007265000001017601010500029C550B0A014150410100E525E57262016500029C570163F5000076050007D5006201620072650000070177010B0A014150410100E525E5070100620AFFFF7262016500029C5774770701006032010101010101044150410177070100600100FF010101010B0A014150410100E525E50177070100010800FF65001CE10401621E520369000000000000002D0177070100020800FF0101621E520369000000000000000101010163BB1C0076050007D50162016200726500000201710163BB000000001B1B1B1B1A0221EE
2023.02.08 12:37:55 4: OBIS (Strom) - MSG IS:
/
1-0:96.50.1*1(APA)
1-0:96.1.0*255(APA%)
1-0:1.8.0*255(>45000*Wh)
1-0:2.8.0*255(1000*Wh)
!
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: /
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: 1-0:96.50.1*1(APA)
2023.02.08 12:37:55 5: OBIS (Strom) - Msg 1-0:96.50.1*1(APA) is of type ManufID2
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: 1-0:96.1.0*255(APA%)
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: 1-0:1.8.0*255(>45000*Wh)
2023.02.08 12:37:55 5: OBIS (Strom) - Msg 1-0:1.8.0*255(>45000*Wh) is of type Counter
2023.02.08 12:37:55 4: OBIS (Strom) - Set total_consumption to 45000
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: 1-0:2.8.0*255(1000*Wh)
2023.02.08 12:37:55 5: OBIS (Strom) - Msg 1-0:2.8.0*255(1000*Wh) is of type Counter
2023.02.08 12:37:55 5: OBIS (Strom) - Msg-Parse: !
Ich hoffe nicht, dass der Momentanverbrauch gar nicht ausgelesen werden kann. Das wäre eine Katastrophe.
Danke und Gruß, Matthias
So, ich denke ich kann meine Anfrage wieder zurück ziehen.
Ich müsste es selber gelöst haben.
Entscheidend bei diesem Modell war folgendes:
1) Eingabe des Pins und Deaktivierung des Schutzes (Pin off)
2) Aktivierung des erweiterten Modus für das Senden der Daten über die optische Schnittstelle.
Danach funktioniert das Auslesen des Zählers wie erwartet. Der Picus von Apator ist also auch kompatibel und kann ausgelesen werden.
Vielleicht hilft es dem ein oder anderen, bei dem das gleiche Modell verbaut wird. Scheint kein seltener Zweirichtungszähler zu sein.
Gruß, Matthias
Zitat von: fritzhugo123 am 08 Februar 2023, 14:45:46
...
1) Eingabe des Pins und Deaktivierung des Schutzes (Pin off)
2) Aktivierung des erweiterten Modus für das Senden der Daten über die optische Schnittstelle.
..
PIN Off musste ich bei meinem ISKRA auch machen, sonst zeigt er die Leistung auf dem Display nicht an.
Da ich erst danch den Zähler eingebunden habe kann ich allerdings nicht sagen, ob ohne PIN off die LEistung auch gekommen wäre.
Ich vermute aber mal nicht, da das Thema PIN ja (auch) dem Datenschutz dienen soll und damit in Mietshäusern fremde Zähler nicht ausgelesen werden (habe ich vor längerem glaube ich irgendwo in einer Zählerbeschreibung gelesen).
Mal ne ganz dumme Frage: Könnte man mit diesem Modul auch (SML-) Daten SENDEN ?
Hintergrund: Meine Zählerdatenerfassung läuft absolut probemfrei und ohne Cloud. Ich bekomme aber demnächst einen Tibber Pulse, und der blockiert mir dann ja die IR Schnittstelle meines Zählers. Ich hab jetzt die fixe Idee, den Tibber Pulse statt direkt an den Stromzähler an einen IR-Sender zu hängen und die von meiner bisherigen Lösung erfassten Daten quasi weiterzuleiten. Das würde mir auch erlauben den Pulse und den dazugehörigen Gateway irgendwo im Haus zu platzieren und mit Strom zu versorgen statt dauernd Batterien zu wechseln.
Hallo zusammen,
weiß von euch zufällig, ob man aus dem Logarex LK13BE (wurde für PV gerade eingebaut, PIN ist vorhanden und schon freigeschaltet, Einstellung PIN OFF, INF ON, sonst nichts geändert) mehr raus zuholen ist als die Zählerstände und die Gesamtmomentanleistung ? Ich hätte gerne die einzelnen Phasen in und out...
Grüße
Christian
Du wirst vermutlich irgendwo eine Anleitung finden, aber meine Erfahrung ist: Nein. Manche Zähler können und machen es (z.B. mein Iskra MT175), mein EMH-Zähler zuvor machte es nicht.
Grundsätzlich könntest Du noch mit Deinem Meßstellenbetreiber (i.d.R. der Netzbetreiber) sprechen, z.B. wenn Du jammerst, dass Du gerne eine 22 kW-Wallbox hättest (die genehmigungspflichtig ist), und dass Du die Schieflastbeachtung der Wallbox (nicht > 20 A Unterschied zwischen den Phasen) ausnutzen möchtest.
Bei mir werkelt konkret ein Logarex LK13BE606739. Der zeigt L1-L3 getrennt (voltage, current, power). Ich speise zwar nix ein, aber ich fürchte auch, der kann nicht weiter nach in/out unterscheiden.
Diese Readings bekomme ich:
| 1.0.0.2.0.0 | 6 |
| 1.0.14.7.0.255 | 50 |
| 1.0.81.7.1.255 | 120.8 |
| 1.0.81.7.15.255 | 310.9 |
| 1.0.81.7.2.255 | 0 |
| 1.0.81.7.26.255 | 314.9 |
| 1.0.81.7.4.255 | 340 |
| 1.0.96.1.0.255 | LOG|( |
| 1.0.96.90.2.1 | Jp |
| CRC-Firmware- zertifizierter LR-Teil | Jp |
| Frequenz | 50 |
| Identifizierung gem. DIN 43863-5 | LOG|( |
| LR Firmware Version | 6 |
| ManufID2 | LOG |
| Phasenwinkel I/U Phase 1 | 338.1 |
| Phasenwinkel I/U Phase 2 | 310.8 |
| Phasenwinkel I/U Phase 3 | 321.8 |
| Voltage to Voltage Angle (R-B) | 0 |
| Voltage to Voltage Angle (R-Y) | 119.9 |
| current_L1 | 0.71 |
| current_L2 | 0.88 |
| current_L3 | 1.12 |
| power | 399 |
| power_L1 | 110 |
| power_L2 | 124 |
| power_L3 | 164 |
| total_consumption | 237484.2 |
| total_feed | 0 |
| voltage_L1 | 231.6 |
| voltage_L2 | 231.4 |
| voltage_L3 | 230.1 |
Vielleicht hilft Dir die Übersicht ergänzend zu gvzdus' Infos ein wenig weiter :)
Hallo,
so hätte ich das auch gern, hast du dazu noch irgendwas mehr am Zähler eingestellt als Inf ON nach Pin-Eingabe ?
Grüße Christian
Hallo Christian.
Ich hab nur den Pin über den Taster eingegeben. Sonst nix gedrückt.
Wenn ich jetzt den Taster drücke kann ich am LCD die Info durchschalten. Z.B. Verbrauch letzte 7 Tage, was nicht über die Schnittstelle kommt.
Hast Du genau den gleichen Zähler? Hat er den PIN vielleicht nicht gefressen?
VG
rob
Hallo Rob,
doch, PIN wurde angenommen, musste ich aber mit dem Punkt PIN auf OFF stellen, sonst musste ich bei jedem Tastendruck immer wieder die PIN eingeben... Und auch die Momentanleistung wurde erst über SML ausgegeben, nachdem ich INF auf ON gestellt habe. Aber mehr kommt eben nicht, Zählerstand rein, raus und Momentanleistung. Und auch der SML-Code ist nur ein paar Zeilen lang, also wird wohl auch nicht mehr rausgeschickt. Schade, aber wohl nicht zu ändern.
Grüße
Christian
Ja, wirklich schade. Eigentlich soll man doch Strom sparen können mit den "Smart" Metern. Ohne sinnvolle Infos wohl schwierig. Ich verstehe da manchmal die Versorger nicht :-X
Ein bischen OT, aber:
Ist es nicht so?, dass erst wenn es ein SmartMeter ist (intelligentes Messsystem = moderne Messeinrichtung mME <elektronischer Zähler> plus Gateway) der Anbieter verpflichtet ist monatliche Verbrauchwerte zur Verfügung zu stellen (vermutlich aber nicht mehr als den Verbrauch) und der reine elektronische Zähler mME theoretisch nicht mehr können muss als ein Ferraris, ggfs. zwei Richtungen?
Bei meinen Eltern bleibt vom iMSys auf der Jahresrechnung lediglich ein monatlicher Verbrauch/Zählerstand. Mehr bietet der Versorger von sich aus nicht an (damit geht Energiewende nicht).
Keine Ahnung ob es online mehr gäbe - Werbung machen sie jedenfalls nicht.
Ich war mal wg. meine E-Heizung ne kurze Zeit in einem Forschungsprojekt der Rheinernergie und hatte da einen ISKRA-Zähler mit Theben Gateway.
Die Daten konnte ich mit TruDi (Sw von PTB) am Gateway auslesen. Der Netzbetrieber/Stromlieferant bekam da 15 Minuten-Werte zu Energie und Leistung übertragen. Mehr Daten können mMn am Ende nicht für den Endverbraucher zur Verfügung stehen.
Hallo rob,
Ich hab den selben Zähler und auch einen Optokopf montiert und versucht einzubinden.
Wie genau hast Du das Device definiert?
Ich bekomme absolut keine Readings angezeigt.
Zitat von: rob am 06 März 2023, 14:44:58
Bei mir werkelt konkret ein Logarex LK13BE606739. Der zeigt L1-L3 getrennt (voltage, current, power). Ich speise zwar nix ein, aber ich fürchte auch, der kann nicht weiter nach in/out unterscheiden.
Diese Readings bekomme ich:
| 1.0.0.2.0.0 | 6 |
| 1.0.14.7.0.255 | 50 |
| 1.0.81.7.1.255 | 120.8 |
| ... |
| voltage_L1 | 231.6 |
| voltage_L2 | 231.4 |
| voltage_L3 | 230.1 |
Vielleicht hilft Dir die Übersicht ergänzend zu gvzdus' Infos ein wenig weiter :)
Danke!
Hallo,
ich möchte mir einen optischen Lesekopf mit TTL Schnittstelle (hichi) zum Anschluss direkt an die gpio Ports des raspi kaufen. Auf dem raspi läuft auch fhem. Kann ich den Lesekopf direkt mit dem obis Modul einbinden oder brauche ich da noch zusätzliche Software/Treiber?
Danke
Zitat von: Alveole am 08 März 2023, 21:45:54
Wie genau hast Du das Device definiert?
Meine Anbindung schaut physisch so aus:
Hichi-Optokopf (TTL-Variante, Lötpunkte oben, Leitungsauslass unten, 5V) --> ca. 1,5m 4-pol. Kabel --> UART-Ethernet-Adapter (CH9121, 5V) --> PatchKabel --> Switch --> Patchkabel --> Raspi3
Als OBIS-Device dann so definiert:
define myPowerMeter OBIS 192.168.0.155:2000 SML
attr myPowerMeter alignTime 00:00
attr myPowerMeter channels {"1.0.0.2.0.0"=>"LR Firmware Version","1.0.14.7.0.255"=>"Frequenz","1.0.81.7.1.255"=>"Voltage to Voltage Angle (R-Y)","1.0.81.7.15.255"=>"Phasenwinkel I/U Phase 2","1.0.81.7.2.255"=>"Voltage to Voltage Angle (R-B)","1.0.81.7.26.255"=>"Phasenwinkel I/U Phase 3","1.0.81.7.4.255"=>"Phasenwinkel I/U Phase 1","1.0.96.1.0.255"=>"Identifizierung gem. DIN 43863-5","1.0.96.90.2.1"=>"CRC-Firmware- zertifizierter LR-Teil"}
attr myPowerMeter event-min-interval total_consumption:600,myTotal:600
attr myPowerMeter event-on-change-reading current.*,power.*,voltage.*,total.*,myTotal
attr myPowerMeter interval 600
attr myPowerMeter pollingMode on
attr myPowerMeter resetAfterNoDataTime 600
attr myPowerMeter stateFormat Zählerstand [$name:myTotal:i]kWh\
<br>Leistung [$name:power]W
attr myPowerMeter unitReadings off
attr myPowerMeter userReadings myTotal:total_consumption.* { ReadingsVal("myPowerMeter",'total_consumption',0)/1000 ;; }
attr myPowerMeter verbose 1
Vor Freischaltung mit PIN hatte ich es noch nicht angeschlossen und kann deshalb nur den Zustand bei mir nach Freischaltung zeigen/ nicht vergleichen.
VG
rob
Edit: RX an RX und TX an TX; NICHT gekreuzt
Zitat von: thomasg am 09 März 2023, 07:03:04
Kann ich den Lesekopf direkt mit dem obis Modul einbinden oder brauche ich da noch zusätzliche Software/Treiber?
Ich hab das nicht am Raspi direkt probiert, antworte mal trotzdem :) Folgende Überlegung:
Der Optokopf lässt sich m.E. an den gängigen UART-Interfaces betreiben. Manche machen das mit dem Esp8266 und nehmen EspEasy (serial server) oder Tasmota (dekodiert bereits selber) her und andere nehmen einen Serial-USB-Adapter usw.
Der Raspi hat ja auch UART (GPIO 14+15) mit dem Hichi u. Co. verbunden werden kann. Treiber benötigst Du imho nicht, aber ggf. musst Du den UART erst aktivieren: The Hard Way - Using Built-in UART https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/uart-serial (https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/uart-serial).
Sobald Du in Linux ein Device hast, welches den UART erreichbar macht, sollte das OBIS-Modul darauf zugreifen können. Wie es genau heißt, kann von Raspi und Betriebssystem abhängig versch. sein.
Lässt sich zunächst testen z.B. mit
cat /dev/ttyS0Da sollten bereits Daten erkennbar sein, sobald alles verbunden.
btw.: In meinem Fall remote via UART-ETH-Bridge brachte dies erste Infos:
socat - TCP4:192.168.0.155:2000Fallstricke legt ggf. dann Dein Zähler: Sendet er sporadisch, erst nach Aufforderung und welche "Sprache" spricht er?
Vielleicht kann aber jmd. hier seine konkreten Erfahrungen posten, der das schon auf diesem Weg mit dem Raspi-UART gemacht hat.
VG
rob
Da ich mir meine Antworten zum Einbinden meines Lesekopfes selber zusammengesucht habe, fass ich meinen Fall hier kurz zusammen.
Zähler ist von EHM Typ eHZ-KW (eHZ Generation K). Denn hatte ich direkt nach Einbau schon mit der PIN freigschaltet und regelmäßig manuell ausgelesen. Dieser Zähler gibt über die D0 nur aktuelle Werte aus. Über das Display lassen sich für zwei Jahre zurück auch historische Werte ablesen.
Der Lesekopf ist der "ELV Bausatz Lesekopf mit USB-Schnittstelle für digitale Zähler USB-IEC ". (EAN 4023392555237)
An der D0 wird SML "gesprochen".
Die device-ID sieht in etwas so aus
/dev/ttyUSBx oder genauer
/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-if00-port0
Übertragungsrate kann von 300-19.200Bd gewählt werden.
Das ganze define sieht das so aus
define USB_IR_Leser OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_dxxxxxxxxxxxxxxxxxxxxxxxxxxx-if00-port0@9600 SML
defmod USB_IR_Leser OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_d06ac9f5beeeec11a0062cf90f611b40-if00-port0@9600 SML
attr USB_IR_Leser event-min-interval .*:30
attr USB_IR_Leser event-on-change-reading total.*:50,power:50
attr USB_IR_Leser room 10_Vorratskeller
attr USB_IR_Leser stateFormat {ReadingsNum("USB_IR_Leser","power",0)." W ".(ReadingsNum("USB_IR_Leser","total_consumption",0)/1000)."kWh ".(ReadingsNum("USB_IR_Leser","total_feed",0)/1000)."kWh";;}
setstate USB_IR_Leser 242.6 W 19657.6797kWh 0.9187kWh
setstate USB_IR_Leser 2023-03-18 08:17:46 ManufID EMH
setstate USB_IR_Leser 2023-03-18 08:17:46 PublicKey XXX-XXX-XXXXXX-XXXXX-XXXX-XXXXX-XXXXX-XXXX-XXXX-XXX-XXXXXXX-XXXXXXX-XX-X
setstate USB_IR_Leser 2023-03-18 08:17:46 Serial xx-xx-xx-xx-xx-xx-xx-xx-xx
setstate USB_IR_Leser 2023-03-18 08:17:46 power 242.6
setstate USB_IR_Leser 2023-03-17 19:40:19 state opened
setstate USB_IR_Leser 2023-03-18 08:17:46 total_consumption 19657679.7
setstate USB_IR_Leser 2023-03-18 08:17:46 total_consumption_Ch1 19657679.7
setstate USB_IR_Leser 2023-03-18 08:17:46 total_consumption_Ch2 0
setstate USB_IR_Leser 2023-03-18 08:17:46 total_feed 918.7
setstate USB_IR_Leser 2023-03-18 08:17:46 total_feed_Ch1 918.7
setstate USB_IR_Leser 2023-03-18 08:17:46 total_feed_Ch2 0
Der Zähler schreit seine Daten lastabhängig alle 1 - 4 Sekunden raus. Um das Log nicht unnötig zuzumüllen, hab ich erstmal etwas eingeschränkt.
Beim platzieren des Lesekopfes darauf achten, dass die Rx-LED regelmäßig blinkt.
Auf Anfragen des OBIS-Moduls über Tx reagiert der Zähler nicht, deswegen schlägt wohl auch autocreate bzw. "usb scan" fehl.
Möge es dem ein oder anderen helfen.
Moin, es wird bald eine neue Version des Moduls geben, die das Auslesen des "Tibber Pulse" im lokalen LAN und damit den Parallelbetrieb von Tibber über die Cloud und das gewohnte, lokale Auslesen wie mit bisherigen IR-Leseköpfen ermöglicht. Details hier: https://forum.fhem.de/index.php?topic=133358.0
hallo zusammen,
hallo gvzdus,
ich habe ein kleines Problem anscheinend. Ich habe ein Balkonkraftwerk und einen ED300L als zähler. Habe mir dann noch den Ebay-Lesekopf für meinen Zähler gekauft und dachte das ich so rausbekomme wieviel Strom ich eingespeist habe. Leider wird bei mir das eben NICHT im total_feed angezeigt da ich das gar nicht habe bei mir im log (siehe Screenshot). Kann man das irgendwie freischalten lassen? Da das ein Balkonkraftwerk ist meinte auch schon die Bayernwerke das es da einen zweiten Zähler geben sollte. Ich bekomme den aber nicht. Muss ich den speziell Freischalten lassen? Oder gar meinen Zähler tauschen lassen?
Bei mir sehe ich nur immer in welche Richtung gespeist wird anhand eines kleinen Symbols im Zähler.
Grüße
MrB
Zitat von: mrb am 14 Mai 2023, 14:17:50Muss ich den speziell Freischalten lassen? Oder gar meinen Zähler tauschen lassen?
Wahrscheinlich musst Du einen PIN eingeben und die Details damit aktivieren (https://www.rng.de/kurzanleitung-emh-ed300l.pdfx (https://www.rng.de/kurzanleitung-emh-ed300l.pdfx)). Den PIN sollte Dir Dein Betreiber zur Verfügung stellen können.
Was der Zähler dann liefert, hängt natürlich vom Zähler selbst ab (Modell, Baureihe etc.). Eigentlich sollte er Speisung zeigen können, wenn Du einen Zweirichtungszähler hast: https://emh-metering.com/wp-content/uploads/2020/08/ED300L-G-DAB-D-2.00.pdf (https://emh-metering.com/wp-content/uploads/2020/08/ED300L-G-DAB-D-2.00.pdf) (oha, Wireless-MBUS kann er auch?!).
Schau mal bitte welches Modell Du ganz konkret hast. Ggf. über metaGer.de mal in die Suche eingeben, was andere dazu so schreiben.
ed300l
w2e8-0n-e00-d2-000002-e50/k2
laut typenschild (siehe Bild)
signal-2023-04-30-110011_002 (002).jpeg
Eine PIN wird nicht erfragt und konnte auch bis jetzt auf alle Datenzugreifen. Was ist Wireless-mbus? Kann ich das irgendwie nutzen?[attach
Schaut so aus, als hättest Du das Model "Einrichtungszähler, 2 Tarife". Damit lässt sich imho keine Speisung auslesen, da sie nicht erfasst wird (https://www.netzgesellschaft-forst.de/fileadmin/NFL/4_NFL_DownloadCenter/3_Strom_NFL/bedienungsanleitung_ED300L.pdf (https://www.netzgesellschaft-forst.de/fileadmin/NFL/4_NFL_DownloadCenter/3_Strom_NFL/bedienungsanleitung_ED300L.pdf)).
Du bräuchtest einen Zweirichtungszähler dafür.
Zitat von: mrb am 14 Mai 2023, 15:21:29Was ist Wireless-mbus? Kann ich das irgendwie nutzen?
Funk; https://wiki.fhem.de/wiki/WMBUS (https://wiki.fhem.de/wiki/WMBUS). Interessant für jmd. der sich z.B. wegen Wasserzähler schon damit beschäftigt hat und vorhandenen Krams direkt nutzen kann.
Ansonsten bleibt ein Optokopf die einfachere Variante.
Hi Rob,
da ich ja nur einen Tarif habe eher "Einrichtungszähler, 1 Tarif (2.8.0) -A mit Rücklaufsperre". Ich habe jetzt mal bei meinem Netzbetreiber angefragt ob wir den "umprogrammieren" können zu "Zweirichtungszähler, 2 Tarife (1.8.0 oder 1.8.1 und 1.8.2) jeweils +A und
1 Tarif (2.8.0) -A" Damit hätte ich ja dann meine Frage wieviel ich Eingespeist habe. Wäre gut, da ich ja soviel ich gelesen habe einen guten Zähler erwischt habe.
Mit dem Netzbetreiber reden ist sicher eine gute Idee. Ich drück die Daumen, dass er Dich auch unterstützen mag :)
hallo zusammen,
neuer Tag neues problem ::) ich habe ja zwei Zähler und da ich mit dem ersten ja so zufrieden war kaufte ich mir einen zweiten für meinen anderen Zähler. Anscheinend läuft der auch aber obis kommt nicht mit den zwei gleichen zurecht. Ja ich habe klar ind /dev/ttyUSBX die richtige Zahl anstelle des X gesetzt. auch habe ich die vermutung das es vielleicht an meinem USB-Hub liegt ausgeschlossen und genau das selbe mit meinem Windows Convertible ausprobiert und da läuft das ganze. Also bleibt für mich im Umkehrschluss das Linux (was ja aber den zweiten Lesekopf erkennt) oder halt OBIS noch übrig. Das der andere Zähler auch per IR Daten abgibt habe ich mit Windows und hterm überprüft und es werden Daten gesendet. Könnt ihr mir da helfen wie ich das hinbekomme das BEIDE und nicht nur der eine Zähler funktionieren?
Bei mir funktionieren zwei Zähler mit je einem OBIS Device. Was heißt denn ,,kommt nicht zurecht"? Fehlermeldung?
nope es zeigt den Zähler als "Connected" aber er bezieht keine werte. wie schon gesagt über mein notebook mit windows bekomme ich die werte in der konstelation
Edit: Mit "kommt nicht zurecht" meinte ich das obis nicht zwei mal das selbe device verwalten kann und durcheinander kommt, aber da es bei dir läuft denke ich eher das nicht
also nochmal überprüft da ich gedacht habe das ich vielleicht irgendwo nen fehler hatte. Notebook mit der konstellation geht. Dann USB-Kabel einfach abgezogen ohne den Lesekopf zu tangieren und das selbe in den pi rein. Das geht nicht. Dann wieder aus dem Pi raus und in das notebook rein. geht wieder (also ist auch ausgeschlossen das ich den irgendwie versehentlich doch irgendwie bewegt habe)
Die Leseköpfe funktionieren also offensichtlich beide.
Funktionieren sie denn jeweils auch einzeln am PI?
Du solltest bei der Fehlersuche vorne anfangen - also ohne FHEM und Modul.
Die erste Frage ist demnach: kennt das Betriebssystem beide Köpfe wenn sie gleichzeitig angesteckt sind.
Also im Verzeichnis /dev/serial/by-id und /dev/serial/by-path müssten zwei Dateien exitieren die auf die Devices (USB-Leseköpfe) zeigen.
In der Commandref ist ja ein Beispiel für die Definition mit /dev/serial/by-id/....
by-id oder by-path hat den Vorteil, dass die Zuordnung immer passt.
Bei ttyUSB0 & ttyUSB1 kann es bei Neustart passieren, dass die Leseköpfe vertauscht werden.
Wenn die "Treiber" stimmen würde ich (beide Leseköpfe angeschlossen und am Zähler befestigt) ohne etwas zu verändern zuerst ein OBIS Device für den ersten Zähler anlegen und schauen ob es funktioniert. Dann das Device wieder löschen und ein neues für den anderen Zähler anlegen und schauen ob es funktioniert.
Damit hättest du schon mal Gewissheit ob bei gegebener unveränderter Hardwarekonfiguration die beiden Zähler zumindest jeweils einzeln arbeiten.
Gruß Ralf
also der eine geht wenn ich ihn einzeln über /dev/serial/by-id/ betreibe der andere macht da nichts. ganz ganz komisch.
Dann hast Du doch schon einen Ansatz.
Das Problem ist nicht, dass das Modul keine 2 kann.
Du musst dich also nur mit der Einbindung des 2. Zählers beschäftigen.
habe gerade den usb-port unter verdacht da ja das ding als "stromfresser" bekannt ist und habe mir jetzt mal zum Testen ein y-Kabel bestellt das ich dann mit einem usb-ladegerät befeuer und dann sollte das ding ja genug Saft bekommen.
also y-kabel ist auch nicht die lösung.
nextstep pi mal neu installieren da der gerade sehr sehr langsam ist. werde da mal ne andere Speicherkarte (die ich auf Reserve gekauft habe) mal probieren.
Aber an den Entwickler bzw auch den Rest: Kann ich irgendwie den Zähler direkt aus zb ner putty-session ansprechen um zu überprüfen was für daten am Pi ankommen? Ich habe nämlich nach meiner Meinung alles korrekt drinnen (habe die id direkt auch aus der putty-session kopiert und nicht per hand eingegeben)
Ja ähnlich wie du es am PC auch gemacht hast.
Per Terminalprogramm mit Verbindung zum entsprechenden seriellen Interface.
Das darf aber nicht schon durch Fhem belegt sein.
Ob man PuTTY an das serielle Interface koppeln und auch die Parameter einstellen kann ich leider auswendig nicht sagen.
Edit - auf die Schnelle von unterwegs :
https://pbxbook.com/voip/sputty.html
okay da haben wir vermutlich aneinander vorbei geredet ;)
Ich möchte mich mit putty auf den Pi verbinden und darüber dann die Serielle Schnittstelle auslesen. Ich bin ehrlich mit linux bin ich nur rudimentär bewandert.
Den Lesekopf habe ich auch mal gegen nen neuen getauscht => auch nicht der Fehler.
Also Lesekopf nicht
Strom nicht (y-kabel)
Software nicht (wurde ja gesagt das das andere auch mit mehreren Zählern machen)
Zugriff auch nicht fehlerhaft (habe ja auf id umgestellt und das auch verifiziert das es läuft indem ich einfach nen anderen Port nutze)
also bleibt bei mir nur noch das System über. Daher meine Frage wie ich den vom System aus mal über putty (verbunden auf dem system) Daten auslesen kann und wie man die Verifizieren kann wäre auch gut.
Wie oben geschrieben brauchst du ein Terminalprogramm auf dem Pi z.B. minicom.
Damit hast du Zugriff auf die serielle Schnittstelle(n) - analog zu dem was du auf dem PC gemacht hast.
Allerdings fällt mir gerade auf, dass du nicht genau gesagt hast was du auf dem PC gemacht hast. Den Kopf nur eingesteckt oder auch geschaut ob er Daten schickt (mit einem Terminalprogramm).
Gruß Ralf
Ja minicom ist dafür pefekt auf dem PI.
Habe ich dort auch schon dafür verwendet.
Infos z.B. hier:
https://forums.raspberrypi.com/viewtopic.php?t=309854
Gruß,
Stefan
Guten Morgen zusammen,
Also klar hab ich ein entsprechendes Programm genutzt. War wie vom Video des Herstellers hterm
Das mit minicom probiere ich später mal. Danke
Hi,
also anscheinend geht er, jedoch vermutlich nicht nach einem reboot. Aber es läuft schon mal. Es liegt also nicht am Lesekopf und am pi bzw os des pi. Ich tippe immer noch drauf das da zu wenig spannung raus kommt oder mein pi 1 (ja so einen gibt es noch) zu schwach auf der Brust ist.
Ein Pi1 B+ mit 4 USB-Ports?
Da kannst du in der /boot/config.txt den Parameter "max_usb_current=1" setzen. Damit wird die Strombegrenzung auf den USB-Ports angehoben.
Wenn es tatsächlich daran liegen sollte, dass zwei Leseköpfe zusammen mehr als 600mA brauchen.
Google mal danach...
Einstieg: https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm
Guten Morgen,
Ne ein pi 1 ohne plus. Wirklich einer der ersten. Scheint so als müsste ich da mal nen neuen kaufen da mein windows server zwar direkt daneben steht, aber man ja nur usb sticks oder Platten durchreichen kann. Sonst könnte da mein Server die usb sticks direkt an meine vm durchreichen.
also zur info mit dem pi 3 geht es jetzt ohne irgend ein zucken.
Gibt es eine Möglichkeit, die sekündlich Werte anzuzeigen, aber nur jeden xten Wert zu loggen? Ich finde es gut, nahezu Echtzeitwerte ablesen zu können, brauche aber meine DB damit nicht zu befüllen.
Ein wenig OT, aber:
Ohne event-on-change-reading bekommst du die ständig aktualisierten Werte und in der DB kann man mit dem Attribut "DbLogInclude power:120,energy:900" (Beispiel) die Zeiten bestimmen.
Inwieweit die Sekundenwerte dein System belasten ist ne andere Frage.
Das Zeitinterval gibt ja nur vor, wann mindestens die Werte gespeichert werden sollen, falls sich keine Änderungen ergeben. Dies ist aber sekündlich der Fall. D.h. der 120s Timer wird jede Sekunde zurückgesetzt und Werte geschrieben :-(
Gehört zwar nach DBLog/DBRep aber hmmm...
Da muss ich mal schauen warum das bei mir "zufällig?" funktioniert.
Aber lt. commandRef müsste das die Lösung sein:
defaultMinInterval <devspec>::<MinInterval>[::force],[<devspec>::<MinInterval>[::force]] ...
Mit diesem Attribut wird ein Standard Minimum Intervall für devspec festgelegt. Ist defaultMinInterval angegeben, wird der Logeintrag nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat.
Ist der optionale Parameter "force" hinzugefügt, wird der Logeintrag auch dann nicht geloggt, wenn sich der Wert des Readings verändert hat.
Eventuell im Quelldevice angegebene Spezifikationen DbLogExclude / DbLogInclude haben Vorrag und werden durch defaultMinInterval nicht überschrieben.
Die Eingabe kann mehrzeilig erfolgen.
Gruß
Edit => DbLogInclude mit [:MinInterval][:force] aber auch
DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...
Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings, die mit dem regulären Ausdruck matchen, werden in der Datenbank gespeichert.
Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.
Mit dem optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.
| Modifier | innerhalb Intervall | außerhalb Intervall |
| | Wert gleich | Wert geändert | |
|----------+--------------------+-----------------+---------------------|
| <none> | ignorieren | speichern | speichern |
| force | ignorieren | ignorieren | speichern |
Ich dachte, ich hätte force ausprobiert. Ich versuchs nochmal.
[EDIT] DbLogInclude und DbLogExclude zeigen beide keine Wirkung (habs mit verschiedenen SelectionsModes versucht)
Wechsle mal besser in das Board Sonstiges.
https://forum.fhem.de/index.php?board=46.0
Edit:
(hier gab auch mal ne Diskussion: https://forum.fhem.de/index.php?topic=130251.msg1247457#msg1247457)
Hallo,
kleine Info so am Rande und vielen Dank auch an alle Mitwirkenden für dieses tolle Modul!!!!
Habe einen Zähler -> Landis+Gyr E320 und einen Sensor von Weidmann im Einsatz.
Den ersten Zähler habe ich vor etwas über einem Jahr bekommen und gleich Probleme mit dem Empfang von Daten gehabt. Das wurde ständig schlimmer und ich habe diese Probleme auf den Sensor, die USB-Schnittstelle und FHEM geschoben.
Vor einem Monat sind die Empfangsdaten komplett ausgefallen und nach langer Recherche, einem neuen Sensor, verschiedenen USB-Kabeln, etc. bin ich letztendlich darauf gekommen, die Schnittstelle des Zählers muss defekt sein.
Vor ein paar Tagen habe ich einen neuen Zähler bekommen und es funktioniert alles viel besser als vorher.
Fazit: Bevor Ihr irgendwas in FHEM diesbezüglich ändert oder am System, sollte man eine defekt Schnittstelle nicht ausschließen, da diese scheinbar nicht so ohne sind....;-)
Lieben Gruß
Hallo,
ich verwende das Modul mit Weidmann-Sensor schon sehr lange. Hat bislang super funktioniert.
Habe aber seit 14.08.23 08:54 plötzlich keine Daten mehr zu Power (Summe, saldierend):
"1.0.16.7.0.255"Total power
und
Power der 3 Phasen (einzeln):
"1.0.36.7.0.255"=>"power_L1",
"1.0.56.7.0.255"=>"power_L2",
"1.0.76.7.0.255"=>"power_L3.
Die übrigen Daten (Energie Bezug werden noch aktualisiert
Hallo,
ich verwende das Modul mit Weidmann-Sensor schon sehr lange. Hat bislang super funktioniert.
Habe aber seit 14.08.23 08:54 plötzlich keine Daten mehr zu Power (Summe, saldierend):
"1.0.16.7.0.255"Total power
und
Power der 3 Phasen (einzeln):
"1.0.36.7.0.255"=>"power_L1",
"1.0.56.7.0.255"=>"power_L2",
"1.0.76.7.0.255"=>"power_L3.
Die übrigen Daten (Energie Bezug und Energielieferung werden noch aktualisiert.
Den Sensor habe ich mittels EM_Log Software überprüft.
Am Drehstromzähler selbst (Fa. EMH, Typ SML) wird die Leistung noch angezeigt.
Was kann da passiert sein. Habe kurz vorher ein update von fhem durchgeführt.
Anbei das List und Log mit verbose 5:
Internals:
CFGFN ./FHEM/00_config_PV_Anlage.conf
CRC_Errors 3
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0
FD 43
FUUID 5cdeb683-f33f-5615-4130-9451faf6ffb17ab4
MeterType SML
NAME ZRZ
NR 1286
PARTIAL
STATE opened
TYPE OBIS
eventCount 6
OLDREADINGS:
READINGS:
2023-08-14 11:44:31 1.0.96.1.0.255 EMHr.
2021-04-14 18:25:42 Hersteller EMH
2023-08-15 22:13:24 ManufID2 EMH
2023-08-15 22:13:24 Power.av -3.000
2023-08-15 21:53:53 Power_EM initialized
2023-08-15 22:13:24 ZRZ_Status 1839364
2023-08-14 08:54:26 power -3
2023-08-14 08:54:26 power_L1 280
2023-08-14 08:54:26 power_L2 -315
2023-08-14 08:54:26 power_L3 32
2023-08-14 21:51:17 state opened
2023-08-15 22:13:24 total_consumption.255 7747000
2023-08-15 22:13:24 total_feed.255 24910000
helper:
BUFFER ␛␛␛␛␁␁␁␁v␅␆&>bbrc␁␁v␁␇������␅␂␌�␋
␁EMHr�.rb␁e ���b␁c^�v␅␆&?bbrc␇␁w␇������␋
␁EMHr�.␇␁b
��rb␁e ���uw␇␁`2␁␁␁␁␁␁␄EMH␁w␇␁`␁�␁␁␁
DIRECTIONSUM >
EoM 0
LastPacketTime 1692130404.48132
NETDEV 0
SPEED 5
TRIGGERTIME 1692005870.03786
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
1.0.96.5.0.255 ZRZ_Status
1.0.96.50.1.255 Hersteller
DEVICES:
0
RULECACHE:
1-0:1.8.0*255 Counter
1-0:2.8.0*255 Counter
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
255-255:255.255.255*255 unknown
directions:
history:
ARRAY(0x5592d37500)
ARRAY(0x559320c448)
ARRAY(0x5592d69440)
ARRAY(0x5593045bb0)
ARRAY(0x559320a328)
ARRAY(0x5593d63e40)
ARRAY(0x5592d523e8)
ARRAY(0x5592adce18)
ARRAY(0x5592e891d0)
ARRAY(0x55930725b0)
ARRAY(0x5592dbbde0)
ARRAY(0x5592cd20e0)
ARRAY(0x558acc2b60)
ARRAY(0x5592d3e2b8)
ARRAY(0x5592e847c8)
ARRAY(0x5593d642a8)
ARRAY(0x5592cd3b88)
ARRAY(0x559311b3f0)
ARRAY(0x5592d67e78)
ARRAY(0x5592d60e20)
ARRAY(0x559302f970)
ARRAY(0x5593050008)
ARRAY(0x5592d549d8)
ARRAY(0x558f8b21e8)
ARRAY(0x5593447380)
Attributes:
DbLogExclude .*
Device_dependend eHZ_History
Zaehlernummer 7513902
channels {"1.0.96.5.0.255"=>"ZRZ_Status","1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
comment Die Daten zu Energie und Leistung werden vom ZRZ im Sekundentakt übertragen.
Userreadings:
Power.av: 1-Min. Durchschnitt der bilanziellen Leistung aus allen 3 Phasen berechnet
event-on-change-reading power,Power_EM
extChannels on
group Verbrauchszähler
icon electric_meter_bidirectional
ignoreUnknown on
interval 5
room Keller,PV_Anlage
userReadings Power.av {movingAverage("ZRZ","power",60)}
userattr Zaehlernummer
verbose 1
2023.08.15 21:45:24.447 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:24.447 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:24.448 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:24.448 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:24.450 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:24.450 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:24.451 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:24.451 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:24.452 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:24.452 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:25.457 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B0101010176050006128E6200620072630101760107FFFFFFFFFFFF05000206300B0A01454D48000072A72E7262016509B6F65C6201634C2C0076050006128F62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65C621E5203631E430177070100020800FF017262016509B6F65C621E520363614E0177070100600500FF01010101641C1104010101631F02007605000612906200620072630201710163C8F100001B1B1B1B1A015917
2023.08.15 21:45:25.458 5: OBIS (ZRZ) - Full message-> 1B1B1B1B0101010176050006128E6200620072630101760107FFFFFFFFFFFF05000206300B0A01454D48000072A72E7262016509B6F65C6201634C2C0076050006128F62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65C621E5203631E430177070100020800FF017262016509B6F65C621E520363614E0177070100600500FF01010101641C1104010101631F02007605000612906200620072630201710163C8F100001B1B1B1B1A015917
2023.08.15 21:45:25.461 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:25.461 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:25.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:25.462 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:25.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:25.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:25.464 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:25.464 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:25.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:25.465 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:25.466 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:25.467 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:25.467 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:26.454 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612916200620072630101760107FFFFFFFFFFFF05000206310B0A01454D48000072A72E7262016509B6F65D620163AF200076050006129262006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65D7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65D621E5203631E430177070100020800FF017262016509B6F65D621E520363614E0177070100600500FF01010101641C110401010163F8E80076050006129362006200726302017101637B0F00001B1B1B1B1A016E19
2023.08.15 21:45:26.455 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612916200620072630101760107FFFFFFFFFFFF05000206310B0A01454D48000072A72E7262016509B6F65D620163AF200076050006129262006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65D7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65D621E5203631E430177070100020800FF017262016509B6F65D621E520363614E0177070100600500FF01010101641C110401010163F8E80076050006129362006200726302017101637B0F00001B1B1B1B1A016E19
2023.08.15 21:45:26.458 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:26.458 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:26.459 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:26.460 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:26.460 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:26.461 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:26.462 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:26.462 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:26.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:26.464 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:26.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:26.466 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:26.466 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:27.444 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612946200620072630101760107FFFFFFFFFFFF05000206320B0A01454D48000072A72E7262016509B6F65E62016344AD0076050006129562006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65E7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65E621E5203631E430177070100020800FF017262016509B6F65E621E520363614E0177070100600500FF01010101641C11040101016369DB007605000612966200620072630201710163BF0400001B1B1B1B1A012F15
2023.08.15 21:45:27.446 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612946200620072630101760107FFFFFFFFFFFF05000206320B0A01454D48000072A72E7262016509B6F65E62016344AD0076050006129562006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65E7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65E621E5203631E430177070100020800FF017262016509B6F65E621E520363614E0177070100600500FF01010101641C11040101016369DB007605000612966200620072630201710163BF0400001B1B1B1B1A012F15
2023.08.15 21:45:27.448 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:27.449 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:27.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:27.450 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:27.451 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:27.452 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:27.452 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:27.453 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:27.453 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:27.454 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:27.455 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:27.456 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:27.457 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:28.456 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612976200620072630101760107FFFFFFFFFFFF05000206330B0A01454D48000072A72E7262016509B6F65F6201631DD60076050006129862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65F7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65F621E5203631E430177070100020800FF017262016509B6F65F621E520363614E0177070100600500FF01010101641C110401010163D2B7007605000612996200620072630201710163F31800001B1B1B1B1A015864
2023.08.15 21:45:28.458 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612976200620072630101760107FFFFFFFFFFFF05000206330B0A01454D48000072A72E7262016509B6F65F6201631DD60076050006129862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65F7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65F621E5203631E430177070100020800FF017262016509B6F65F621E520363614E0177070100600500FF01010101641C110401010163D2B7007605000612996200620072630201710163F31800001B1B1B1B1A015864
2023.08.15 21:45:28.460 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:28.460 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:28.461 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:28.461 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:28.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:28.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:28.463 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:28.463 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:28.464 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:28.464 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:28.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:28.465 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:28.466 5: OBIS (ZRZ) - Msg-Parse: !
Zitat von: Homalix99 am 15 August 2023, 22:15:06Hallo,
ich verwende das Modul mit Weidmann-Sensor schon sehr lange. Hat bislang super funktioniert.
Habe aber seit 14.08.23 08:54 plötzlich keine Daten mehr zu Power (Summe, saldierend):
"1.0.16.7.0.255"Total power
und
Power der 3 Phasen (einzeln):
"1.0.36.7.0.255"=>"power_L1",
"1.0.56.7.0.255"=>"power_L2",
"1.0.76.7.0.255"=>"power_L3.
Die übrigen Daten (Energie Bezug und Energielieferung werden noch aktualisiert.
Den Sensor habe ich mittels EM_Log Software überprüft.
Am Drehstromzähler selbst (Fa. EMH, Typ SML) wird die Leistung noch angezeigt.
Was kann da passiert sein. Habe kurz vorher ein update von fhem durchgeführt.
Anbei das List und Log mit verbose 5:
Internals:
CFGFN ./FHEM/00_config_PV_Anlage.conf
CRC_Errors 3
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0 SML
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0
FD 43
FUUID 5cdeb683-f33f-5615-4130-9451faf6ffb17ab4
MeterType SML
NAME ZRZ
NR 1286
PARTIAL
STATE opened
TYPE OBIS
eventCount 6
OLDREADINGS:
READINGS:
2023-08-14 11:44:31 1.0.96.1.0.255 EMHr.
2021-04-14 18:25:42 Hersteller EMH
2023-08-15 22:13:24 ManufID2 EMH
2023-08-15 22:13:24 Power.av -3.000
2023-08-15 21:53:53 Power_EM initialized
2023-08-15 22:13:24 ZRZ_Status 1839364
2023-08-14 08:54:26 power -3
2023-08-14 08:54:26 power_L1 280
2023-08-14 08:54:26 power_L2 -315
2023-08-14 08:54:26 power_L3 32
2023-08-14 21:51:17 state opened
2023-08-15 22:13:24 total_consumption.255 7747000
2023-08-15 22:13:24 total_feed.255 24910000
helper:
BUFFER ␛␛␛␛␁␁␁␁v␅␆&>bbrc␁␁v␁␇������␅␂␌�␋
␁EMHr�.rb␁e ���b␁c^�v␅␆&?bbrc␇␁w␇������␋
␁EMHr�.␇␁b
��rb␁e ���uw␇␁`2␁␁␁␁␁␁␄EMH␁w␇␁`␁�␁␁␁
DIRECTIONSUM >
EoM 0
LastPacketTime 1692130404.48132
NETDEV 0
SPEED 5
TRIGGERTIME 1692005870.03786
Channels:
1.0.36.7.0.255 power_L1
1.0.56.7.0.255 power_L2
1.0.76.7.0.255 power_L3
1.0.96.5.0.255 ZRZ_Status
1.0.96.50.1.255 Hersteller
DEVICES:
0
RULECACHE:
1-0:1.8.0*255 Counter
1-0:2.8.0*255 Counter
1-0:96.1.0*255 unknown
1-0:96.50.1*1 ManufID2
255-255:255.255.255*255 unknown
directions:
history:
ARRAY(0x5592d37500)
ARRAY(0x559320c448)
ARRAY(0x5592d69440)
ARRAY(0x5593045bb0)
ARRAY(0x559320a328)
ARRAY(0x5593d63e40)
ARRAY(0x5592d523e8)
ARRAY(0x5592adce18)
ARRAY(0x5592e891d0)
ARRAY(0x55930725b0)
ARRAY(0x5592dbbde0)
ARRAY(0x5592cd20e0)
ARRAY(0x558acc2b60)
ARRAY(0x5592d3e2b8)
ARRAY(0x5592e847c8)
ARRAY(0x5593d642a8)
ARRAY(0x5592cd3b88)
ARRAY(0x559311b3f0)
ARRAY(0x5592d67e78)
ARRAY(0x5592d60e20)
ARRAY(0x559302f970)
ARRAY(0x5593050008)
ARRAY(0x5592d549d8)
ARRAY(0x558f8b21e8)
ARRAY(0x5593447380)
Attributes:
DbLogExclude .*
Device_dependend eHZ_History
Zaehlernummer 7513902
channels {"1.0.96.5.0.255"=>"ZRZ_Status","1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
comment Die Daten zu Energie und Leistung werden vom ZRZ im Sekundentakt übertragen.
Userreadings:
Power.av: 1-Min. Durchschnitt der bilanziellen Leistung aus allen 3 Phasen berechnet
event-on-change-reading power,Power_EM
extChannels on
group Verbrauchszähler
icon electric_meter_bidirectional
ignoreUnknown on
interval 5
room Keller,PV_Anlage
userReadings Power.av {movingAverage("ZRZ","power",60)}
userattr Zaehlernummer
verbose 1
2023.08.15 21:45:24.447 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:24.447 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:24.448 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:24.448 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:24.449 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:24.450 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:24.450 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:24.451 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:24.451 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:24.452 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:24.452 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:25.457 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B0101010176050006128E6200620072630101760107FFFFFFFFFFFF05000206300B0A01454D48000072A72E7262016509B6F65C6201634C2C0076050006128F62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65C621E5203631E430177070100020800FF017262016509B6F65C621E520363614E0177070100600500FF01010101641C1104010101631F02007605000612906200620072630201710163C8F100001B1B1B1B1A015917
2023.08.15 21:45:25.458 5: OBIS (ZRZ) - Full message-> 1B1B1B1B0101010176050006128E6200620072630101760107FFFFFFFFFFFF05000206300B0A01454D48000072A72E7262016509B6F65C6201634C2C0076050006128F62006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65C7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65C621E5203631E430177070100020800FF017262016509B6F65C621E520363614E0177070100600500FF01010101641C1104010101631F02007605000612906200620072630201710163C8F100001B1B1B1B1A015917
2023.08.15 21:45:25.461 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:25.461 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:25.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:25.462 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:25.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:25.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:25.464 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:25.464 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:25.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:25.465 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:25.466 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:25.467 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:25.467 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:26.454 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612916200620072630101760107FFFFFFFFFFFF05000206310B0A01454D48000072A72E7262016509B6F65D620163AF200076050006129262006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65D7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65D621E5203631E430177070100020800FF017262016509B6F65D621E520363614E0177070100600500FF01010101641C110401010163F8E80076050006129362006200726302017101637B0F00001B1B1B1B1A016E19
2023.08.15 21:45:26.455 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612916200620072630101760107FFFFFFFFFFFF05000206310B0A01454D48000072A72E7262016509B6F65D620163AF200076050006129262006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65D7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65D621E5203631E430177070100020800FF017262016509B6F65D621E520363614E0177070100600500FF01010101641C110401010163F8E80076050006129362006200726302017101637B0F00001B1B1B1B1A016E19
2023.08.15 21:45:26.458 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:26.458 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:26.459 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:26.460 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:26.460 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:26.461 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:26.462 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:26.462 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:26.463 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:26.464 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:26.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:26.466 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:26.466 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:27.444 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612946200620072630101760107FFFFFFFFFFFF05000206320B0A01454D48000072A72E7262016509B6F65E62016344AD0076050006129562006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65E7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65E621E5203631E430177070100020800FF017262016509B6F65E621E520363614E0177070100600500FF01010101641C11040101016369DB007605000612966200620072630201710163BF0400001B1B1B1B1A012F15
2023.08.15 21:45:27.446 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612946200620072630101760107FFFFFFFFFFFF05000206320B0A01454D48000072A72E7262016509B6F65E62016344AD0076050006129562006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65E7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65E621E5203631E430177070100020800FF017262016509B6F65E621E520363614E0177070100600500FF01010101641C11040101016369DB007605000612966200620072630201710163BF0400001B1B1B1B1A012F15
2023.08.15 21:45:27.448 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:27.449 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:27.449 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:27.450 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:27.451 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:27.452 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:27.452 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:27.453 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:27.453 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:27.454 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:27.455 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:27.456 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:27.457 5: OBIS (ZRZ) - Msg-Parse: !
2023.08.15 21:45:28.456 5: OBIS (ZRZ) - SML-Parse 1B1B1B1B010101017605000612976200620072630101760107FFFFFFFFFFFF05000206330B0A01454D48000072A72E7262016509B6F65F6201631DD60076050006129862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65F7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65F621E5203631E430177070100020800FF017262016509B6F65F621E520363614E0177070100600500FF01010101641C110401010163D2B7007605000612996200620072630201710163F31800001B1B1B1B1A015864
2023.08.15 21:45:28.458 5: OBIS (ZRZ) - Full message-> 1B1B1B1B010101017605000612976200620072630101760107FFFFFFFFFFFF05000206330B0A01454D48000072A72E7262016509B6F65F6201631DD60076050006129862006200726307017707FFFFFFFFFFFF0B0A01454D48000072A72E070100620AFFFF7262016509B6F65F7577070100603201010101010104454D480177070100600100FF010101010B0A01454D48000072A72E0177070100010800FF641C11047262016509B6F65F621E5203631E430177070100020800FF017262016509B6F65F621E520363614E0177070100600500FF01010101641C110401010163D2B7007605000612996200620072630201710163F31800001B1B1B1B1A015864
2023.08.15 21:45:28.460 4: OBIS (ZRZ) - MSG IS:
/
1-0:96.50.1*1(EMH)
1-0:96.1.0*255(EMHr.)
1-0:1.8.0*255(>7747000*Wh)
1-0:2.8.0*255(24910000*Wh)
1-0:96.5.0*255(1839364)
255-255:255.255.255*255()
!
2023.08.15 21:45:28.460 5: OBIS (ZRZ) - Msg-Parse: /
2023.08.15 21:45:28.461 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.50.1*1(EMH)
2023.08.15 21:45:28.461 5: OBIS (ZRZ) - Msg 1-0:96.50.1*1(EMH) is of type ManufID2
2023.08.15 21:45:28.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.1.0*255(EMHr.)
2023.08.15 21:45:28.462 5: OBIS (ZRZ) - Msg-Parse: 1-0:1.8.0*255(>7747000*Wh)
2023.08.15 21:45:28.463 5: OBIS (ZRZ) - Msg 1-0:1.8.0*255(>7747000*Wh) is of type Counter
2023.08.15 21:45:28.463 4: OBIS (ZRZ) - Set total_consumption.255 to 7747000
2023.08.15 21:45:28.464 5: OBIS (ZRZ) - Msg-Parse: 1-0:2.8.0*255(24910000*Wh)
2023.08.15 21:45:28.464 5: OBIS (ZRZ) - Msg 1-0:2.8.0*255(24910000*Wh) is of type Counter
2023.08.15 21:45:28.465 5: OBIS (ZRZ) - Msg-Parse: 1-0:96.5.0*255(1839364)
2023.08.15 21:45:28.465 5: OBIS (ZRZ) - Msg-Parse: 255-255:255.255.255*255()
2023.08.15 21:45:28.466 5: OBIS (ZRZ) - Msg-Parse: !
Beitrag hat sich erledigt. Der eHZ (EMH) hat sich aus unerfindlichen Gründen) in den reduzierten Modus geschalten. War jetzt mit Tschenlampe dran und alles wieder okay.
Gruß
Alex
Hi,
ich habe einen DZG Zähler (DWS7612.2).
Und er hat bei Consumption Reading Vorzeichen < oder >.
Msg-Parse: 1-0:1.8.0*255(>12528.2*Wh)
Mein Power Reading zeigt nur positive Werte an.
Ich denke diese sollten auch negativ sein je nach Vorzeichen vom consumption Reading?
Ich habe in der Doku dazu auch etwas gefunden:
directions
Manche SmartMeter senden im Statusbyte die Stromrichtung. In diesem Fall gibt es ein extra Reading "dir_total_consumption" welches standardmäßig "in" and "out" beinhaltet
Hiermit kann dieser Text geändert werden, z.B.: attr myOBIS directions {">" => "pwr consuming", "<"=>"pwr feeding"}
Ich habe aber kein Reading dir_total_consumption.
Auch das setzen des dirctions Attribut, hat leider gar nichts bewirkt.
Kann mir hier jemand auf die Sprünge helfen?
Hier mal noch 2 Readings mit unterschiedlicher Richtung (LOG Verbose 5):
2023.11.04 18:13:17 5: OBIS (walter_test) - Msg-Parse: !
2023.11.04 18:13:18 5: OBIS (walter_test) - SML-Parse 1B1B1B1B01010101760573911000620062007263010176010102310B0A01445A470003B49809726201640585F3620263F90000760574911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F37577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C49047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3450177070100100700FF017262016200621B52FE53F78201010163E0E8007605759110006200620072630201710163482900001B1B1B1B1A0105F0
2023.11.04 18:13:18 5: OBIS (walter_test) - Full message-> 1B1B1B1B01010101760573911000620062007263010176010102310B0A01445A470003B49809726201640585F3620263F90000760574911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F37577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C49047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3450177070100100700FF017262016200621B52FE53F78201010163E0E8007605759110006200620072630201710163482900001B1B1B1B1A0105F0
2023.11.04 18:13:18 4: OBIS (walter_test) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZG*var)
1-0:1.8.0*255(<12528.2*Wh)
1-0:2.8.0*255(38995.7*Wh)
1-0:16.7.0*255(633.62*W)
!
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: /
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: 1-0:96.1.0*255(DZG*var)
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: 1-0:1.8.0*255(<12528.2*Wh)
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg 1-0:1.8.0*255(<12528.2*Wh) is of type Counter
2023.11.04 18:13:18 4: OBIS (walter_test) - Set total_consumption to 12528.2
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: 1-0:2.8.0*255(38995.7*Wh)
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg 1-0:2.8.0*255(38995.7*Wh) is of type Counter
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: 1-0:16.7.0*255(633.62*W)
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg 1-0:16.7.0*255(633.62*W) is of type Channels
2023.11.04 18:13:18 5: OBIS (walter_test) - Msg-Parse: !
2023.11.04 18:13:19 5: OBIS (walter_test) - SML-Parse 1B1B1B1B01010101760576911000620062007263010176010102310B0A01445A470003B49809726201640585F4620263FDCF00760577911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F47577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C40047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3460177070100100700FF017262016200621B52FE530165010101635E34007605789110006200620072630201710163784B00001B1B1B1B1A016216
2023.11.04 18:13:19 5: OBIS (walter_test) - Full message-> 1B1B1B1B01010101760576911000620062007263010176010102310B0A01445A470003B49809726201640585F4620263FDCF00760577911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F47577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C40047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3460177070100100700FF017262016200621B52FE530165010101635E34007605789110006200620072630201710163784B00001B1B1B1B1A016216
2023.11.04 18:13:19 4: OBIS (walter_test) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZG*var)
1-0:1.8.0*255(>12528.2*Wh)
1-0:2.8.0*255(38995.8*Wh)
1-0:16.7.0*255(3.57*W)
!
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: /
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: 1-0:96.1.0*255(DZG*var)
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: 1-0:1.8.0*255(>12528.2*Wh)
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg 1-0:1.8.0*255(>12528.2*Wh) is of type Counter
2023.11.04 18:13:19 4: OBIS (walter_test) - Set total_consumption to 12528.2
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: 1-0:2.8.0*255(38995.8*Wh)
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg 1-0:2.8.0*255(38995.8*Wh) is of type Counter
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: 1-0:16.7.0*255(3.57*W)
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg 1-0:16.7.0*255(3.57*W) is of type Channels
2023.11.04 18:13:19 5: OBIS (walter_test) - Msg-Parse: !
2023.11.04 18:13:20 5: OBIS (walter_test) - SML-Parse 1B1B1B1B01010101760579911000620062007263010176010102310B0A01445A470003B49809726201640585F562026322500076057A911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F57577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C01047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3460177070100100700FF017262016200621B52FE530B0001010163CE290076057B911000620062007263020171016346C800001B1B1B1B1A017712
2023.11.04 18:13:20 5: OBIS (walter_test) - Full message-> 1B1B1B1B01010101760579911000620062007263010176010102310B0A01445A470003B49809726201640585F562026322500076057A911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F57577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C01047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3460177070100100700FF017262016200621B52FE530B0001010163CE290076057B911000620062007263020171016346C800001B1B1B1B1A017712
2023.11.04 18:13:20 4: OBIS (walter_test) - MSG IS:
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(DZG*var)
1-0:1.8.0*255(>12528.2*Wh)
1-0:2.8.0*255(38995.8*Wh)
1-0:16.7.0*255(28.16*W)
Danke und Gruß,
Stefan
Hi Stefan,
hast Du denn das reading "dir_total_consumption" ? Meines Erachtens änderst Du mit dem attr nur die Standardtexte (in/out) des readings.
Grüße
Markus
Hi Markus,
nein das habe ich nicht.
Die Readings die ich habe sind:
1.0.96.1.0.255 DZG
ManufID2 DZG*var
power 43.52
state opened
total_consumption 12528.2
total_feed 39020.1
Leider ist das power reading ohne Vorzeichen. Auf dem SmartMeter Display ist es aber Vorzeichen behaftet.
Im Verbose 5 Log (siehe oben) sehe ich, dass vor dem total_consumption reading ein < oder > kommt.
Ich denke das wäre das Vorzeichen für mein Power Reading.
Nur wie muss das ausgewertet werden, bzw. fehlt etwas im Modul oder kann ich etwas einstellen dass es geht?
Gruß,
Stefan
ZitatNur wie muss das ausgewertet werden, bzw. fehlt etwas im Modul oder kann ich etwas einstellen dass es geht?
Letzteres: Nein, Du oder der Modulmaintainer werden ins Modul eingreifen müssen. :'(
Grüße Markus
Ok Danke,
Wie oben beschrieben hat mein DZG Zähler (DWS7612.2)
3 Readings,
Power
total_consumption
total_feedin
Es gibt ein Statusbyte vor Msg 1-0:1.8.0*255 (total_consumption).
Ich denke dieses bezieht sich auf das Vorzeichen des Power Readings.
Dieses liefert bei mir nur positive Werte.
Auf dem Display des Smart Meters zeigt es aber auch negative.
Habe mal ins Coding geschaut, das ist aber nicht ganz so einfach.
Wenn ich Zeit habe schaue ich nochmal, aber wäre toll wenn sich der Modul Autor meine Logs oben mal anschauen könnte.
Habe jetzt nochmal ins Datenblatt geschaut und der Wert für Power kommt mir komisch vor. (https://www.dzg.de/fileadmin/dzg/content/downloads/produkte-zaehler/dvs76/DZG_DVS76_Datenblatt.pdf)
Er passt nicht zu den Werten meines SmartMeters viel zu hohe Werte.
Kann es sein dass da etwas anderes nicht stimmt.
Gibt es einen SML Converter indem ich mein SML mal testen könnte?
SML-Parse
1B1B1B1B01010101760573911000620062007263010176010102310B0A01445A470003B49809726201640585F3620263F90000760574911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F37577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C49047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3450177070100100700FF017262016200621B52FE53F78201010163E0E8007605759110006200620072630201710163482900001B1B1B1B1A0105F0
Danke und Gruß,
Stefan
Ok,
also es scheint doch etwas anders zu sein.
Ich habe den SML String mal durch den Tasmoto Decodierer (https://tasmota-sml-parser.dicp.net/decode) geschickt.
Da bekomme ich für den SML String dann diese Werte und der Power Wert ist negativ er sieht auch viel besser vom Wert aus.
0x0100010800ff 1.8.0 Zählerstand Total 125282 Wh 12528.2Wh (Zählerstand Total)
0x0100020800ff 2.8.0 Wirkenergie Total 389957 Wh 38995.7Wh (Wirkenergie Total)
0x0100100700ff 16.7.0 aktuelle Wirkleistung -2174 W -21.74W (aktuelle Wirkleistung)
FHEM hatte für Power 1-0:16.7.0*255(633.62*W) rausbekommen.
Da scheint irgendetwas nicht zu passen mit der Dekodierung.
Könnte sich das mal jemand der sich mit SML auskennt anschauen?
SML String aus FHEM ist:
SML-Parse
1B1B1B1B01010101760573911000620062007263010176010102310B0A01445A470003B49809726201640585F3620263F90000760574911000620062007263070177010B0A01445A470003B49809070100620AFFFF726201640585F37577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003B498090177070100010800FF641C49047262016200621E52FF6401E9620177070100020800FF017262016200621E52FF6405F3450177070100100700FF017262016200621B52FE53F78201010163E0E8007605759110006200620072630201710163482900001B1B1B1B1A0105F0
P.S.: Hier das komplette Handbuch:
https://cdn.swk.de/-/media/project/digitale-plattform/ngn-de/service/downloadcenter/broschueren/dzg_dvs76_dws76_handbuch.pdf?la=de-de&rev=06de1abc85c74942a16d3bdd44261331
Seite 20 ist die Optische Schnittstelle beschrieben.
Vielen Dank,
Stefan
Ursache ist, dass DZG-Zähler einen Bug im SML-Encoding hatten. Hierfür gibt es im Code von 47_OBIS das Erkennen von DZG-Zählern und anschließend eine vom "richtigen" Encoding abweichende Behandlung.
Ich habe jetzt eine neue Version geschrieben, bei der man das Attribut "nohacks" auf 1 setzen kann, dann wird dieser Workaround für DZG- (und Holy)-Zähler abgeschaltet.
Warte entweder auf morgen, bis die Version über "Update" bezogen werden kann, oder Du gehst in 47_OBIS in Zeile 448 und machst den Workaround kaputt, indem Du z.B. aus "DZGHACK" ein "DZGNOHACK" machst:
if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:[1357]6\.7\.0/ && $hash->{helper}{DZGNONONONOHACK}) {Dann FHEM restarten...
Wow das ging schnell.
Du willst sagen mein DZG Zähler hat den Bug nicht?
Ich habe mir die neue Version via
"wget -qO /opt/fhem/FHEM/47_OBIS.pm https://svn.fhem.de/fhem/trunk/fhem/FHEM/47_OBIS.pm"
getzogen.
Und ein
reload 47_OBIS.pm
gemacht.
Der Parameter ist da.
Da ich gerade aber nicht einspeise kann ich leider noch nicht sehen ob es wirkt.
Ich werde berichten.
P.S.: Ja tut wunderbar.
Ich danke dir vielmals.
Gruß,
Stefan
Hallo zusammen!
Ich habe einen Landis & Gyr E320 und Hichi IR USB Lesekopf, der an einem Raspberry Pi 2 mit FHEM hängt.
In der Landis E320 Anleitung steht:
ZitatDer Kommunikationskanal hat folgende Parameter:
- Bitrate 9600 Baud
- Code 8‐N‐1
In der Hichi IR USB Produkbeschreibung steht:
ZitatBaudraten: 300 Baud bis 57600 Baud
In
fhem.cfg habe ich folgendes definiert:
define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 Standard
setuuid MyObis xxxxx
attr MyObis interval 600
attr MyObis pollingMode on
attr MyObis verbose 5
attr MyObis room Strom
define FileLog_MyObis FileLog /opt/fhem/log/MyObis-%Y-%m.log MyObis
setuuid FileLog_MyObis xxxxx
attr FileLog_MyObis archivedir /opt/fhem/log/archive/
attr FileLog_MyObis createGluedFile 1
attr FileLog_MyObis nrarchive 2Ist das soweit korrekt? Vielen Dank für Eure Rückmeldung! :)
Hier noch meine Config (sorry, dass ich erst jetzt nachliefere):
define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@300,8,N,1 Standard
attr MyObis interval 600
attr MyObis pollingMode on
attr MyObis room Strom
attr MyObis verbose 5
# DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@300,8,N,1 Standard
# DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@300,8,N,1
# FD 11
# FUUID xxxxx
# MeterType Standard
# NAME MyObis
# NR 291
# PARTIAL
# STATE opened
# TYPE OBIS
# eventCount 1
# READINGS:
# 2023-11-09 14:52:17 Version jIn der "Version" Zeile stehen seltsame Zeichen, und dann folgt noch (wieder ganz normal):
# 2023-11-09 17:06:57 state opened
Nachdem ich nun schon zig Seiten, Blogs, Foren etc. zum Thema gelesen habe, stehe ich immer noch auf dem Schlauch, denn ich kann nicht erkennen, wie ich vom Hichi IR USB Lesekopf in FHEM Daten von meinem Stromzähler L&G E320 sehen kann. 🤔 Danke für Eure Hilfe! 👍
Das passt was mit den Bitraten nicht zusammen:
Zitat von: sunrise am 09 November 2023, 12:57:40define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 Standard
und
Zitat von: sunrise am 09 November 2023, 17:13:10define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@300,8,N,1 Standard
Einmal 9600 und einmal 300 Baud. Wenn der Zähler 9600 liefert musst der Hichi das auch so auslesen.
Ja, bei meinem ersten Beitrag hatte ich noch 9600, beim zweiten nur noch 300 Baud eingestellt (und im ersten Beitrag nicht aktualisiert).
Hallo
Mhh... Die anderen Landis Nutzer hier fragen das so ab: @300,7,E,1 VSM102Schonmal probiert?
Gruß
Zitat von: kabanett am 09 November 2023, 17:39:13Hallo
Mhh... Die anderen Landis Nutzer hier fragen das so ab:
@300,7,E,1 VSM102Schonmal probiert?
Gruß
Gute Idee sich da dran zu hängen wo es funktioniert ;D
Allerdings meint Volkzähler auch 9600,8,N,1 => https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/landisgyr_e320
Ich hatte mich auf die Herstellerangaben verlassen:
Zitat von: sunrise am 09 November 2023, 12:57:40Hallo zusammen!
Ich habe einen Landis & Gyr E320 und Hichi IR USB Lesekopf, der an einem Raspberry Pi 2 mit FHEM hängt.
In der Landis E320 Anleitung steht:
ZitatDer Kommunikationskanal hat folgende Parameter:
- Bitrate 9600 Baud
- Code 8‐N‐1
Falls Daten kämen, würden die mit der von mir hier zuvor gezeigten Basis-Einstellung schon als Readings erscheinen?
Ich sehe dort oben nur eine Möglichkeit für
get MyObis update:
Screenshot 2023-11-09 175458.png
Und der Inhalt von
MyObis-2023-11.log besteht fast ausschließlich aus sich wiederholenden DISCONNECTED/CONNECTED Zeilen - zwischendurch und am Ende (insgesamt 3 Mal) etwas zu 'Version':
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:29 MyObis CONNECTED
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:29 MyObis CONNECTED
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:29 MyObis CONNECTED
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:29 MyObis CONNECTED
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:29 MyObis CONNECTED
2023-11-09_13:10:29 MyObis DISCONNECTED
2023-11-09_13:10:34 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:35 MyObis DISCONNECTED
2023-11-09_13:10:35 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:36 MyObis DISCONNECTED
2023-11-09_13:10:36 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:37 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:37 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:37 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:37 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:37 MyObis CONNECTED
2023-11-09_13:10:37 MyObis DISCONNECTED
2023-11-09_13:10:42 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:25 MyObis DISCONNECTED
2023-11-09_13:18:25 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:26 MyObis DISCONNECTED
2023-11-09_13:18:26 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:27 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:27 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:27 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:27 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:27 MyObis CONNECTED
2023-11-09_13:18:27 MyObis DISCONNECTED
2023-11-09_13:18:32 MyObis CONNECTED
2023-11-09_13:18:32 MyObis DISCONNECTED
2023-11-09_13:18:32 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:33 MyObis DISCONNECTED
2023-11-09_13:18:33 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:34 MyObis DISCONNECTED
2023-11-09_13:18:34 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:35 MyObis DISCONNECTED
2023-11-09_13:18:35 MyObis CONNECTED
2023-11-09_13:18:36 MyObis DISCONNECTED
2023-11-09_13:18:36 MyObis CONNECTED
2023-11-09_13:18:36 MyObis DISCONNECTED
2023-11-09_13:18:36 MyObis CONNECTED
2023-11-09_13:18:36 MyObis DISCONNECTED
2023-11-09_13:18:41 MyObis CONNECTED
2023-11-09_13:18:41 MyObis DISCONNECTED
2023-11-09_13:18:41 MyObis CONNECTED
2023-11-09_13:18:41 MyObis DISCONNECTED
2023-11-09_13:18:41 MyObis CONNECTED
2023-11-09_13:18:41 MyObis DISCONNECTED
2023-11-09_13:18:41 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:42 MyObis DISCONNECTED
2023-11-09_13:18:42 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:43 MyObis DISCONNECTED
2023-11-09_13:18:43 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:44 MyObis DISCONNECTED
2023-11-09_13:18:44 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:45 MyObis DISCONNECTED
2023-11-09_13:18:45 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:46 MyObis DISCONNECTED
2023-11-09_13:18:46 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:47 MyObis DISCONNECTED
2023-11-09_13:18:47 MyObis CONNECTED
2023-11-09_13:18:48 MyObis DISCONNECTED
2023-11-09_13:18:48 MyObis CONNECTED
2023-11-09_13:18:48 MyObis DISCONNECTED
2023-11-09_13:18:48 MyObis CONNECTED
2023-11-09_13:18:48 MyObis DISCONNECTED
2023-11-09_13:18:53 MyObis CONNECTED
2023-11-09_13:18:53 MyObis DISCONNECTED
2023-11-09_13:18:53 MyObis CONNECTED
2023-11-09_13:18:53 MyObis DISCONNECTED
2023-11-09_13:18:53 MyObis CONNECTED
2023-11-09_13:18:53 MyObis DISCONNECTED
2023-11-09_13:18:53 MyObis CONNECTED
2023-11-09_13:18:53 MyObis DISCONNECTED
2023-11-09_13:18:53 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:54 MyObis DISCONNECTED
2023-11-09_13:18:54 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:55 MyObis DISCONNECTED
2023-11-09_13:18:55 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:56 MyObis DISCONNECTED
2023-11-09_13:18:56 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:57 MyObis DISCONNECTED
2023-11-09_13:18:57 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:58 MyObis DISCONNECTED
2023-11-09_13:18:58 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:18:59 MyObis DISCONNECTED
2023-11-09_13:18:59 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:00 MyObis DISCONNECTED
2023-11-09_13:19:00 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:01 MyObis DISCONNECTED
2023-11-09_13:19:01 MyObis CONNECTED
2023-11-09_13:19:02 MyObis DISCONNECTED
2023-11-09_13:19:02 MyObis CONNECTED
2023-11-09_13:19:02 MyObis DISCONNECTED
2023-11-09_13:19:02 MyObis CONNECTED
2023-11-09_13:19:02 MyObis DISCONNECTED
2023-11-09_13:19:07 MyObis CONNECTED
2023-11-09_13:19:07 MyObis DISCONNECTED
2023-11-09_13:19:07 MyObis CONNECTED
2023-11-09_13:19:07 MyObis DISCONNECTED
2023-11-09_13:19:07 MyObis CONNECTED
2023-11-09_13:19:07 MyObis DISCONNECTED
2023-11-09_13:19:07 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:08 MyObis DISCONNECTED
2023-11-09_13:19:08 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:09 MyObis DISCONNECTED
2023-11-09_13:19:09 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:10 MyObis DISCONNECTED
2023-11-09_13:19:10 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:11 MyObis DISCONNECTED
2023-11-09_13:19:11 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:12 MyObis DISCONNECTED
2023-11-09_13:19:12 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:13 MyObis DISCONNECTED
2023-11-09_13:19:13 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:14 MyObis DISCONNECTED
2023-11-09_13:19:14 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:19:15 MyObis DISCONNECTED
2023-11-09_13:19:15 MyObis CONNECTED
2023-11-09_13:33:05 MyObis DISCONNECTED
2023-11-09_13:33:05 MyObis CONNECTED
2023-11-09_13:33:05 MyObis DISCONNECTED
2023-11-09_13:33:10 MyObis CONNECTED
2023-11-09_13:36:17 MyObis Version: v␅␋�Ebbrc␂␁q␁cؿ␛␛␛␛␚␂��␛␛␛␛␁␁␁␁v␅␋�Fbbrc␁␁v␁␇������␅␃�␗␋
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:30 MyObis DISCONNECTED
2023-11-09_13:38:30 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:31 MyObis CONNECTED
2023-11-09_13:38:31 MyObis DISCONNECTED
2023-11-09_13:38:36 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:37 MyObis DISCONNECTED
2023-11-09_13:38:37 MyObis CONNECTED
2023-11-09_13:38:38 MyObis DISCONNECTED
2023-11-09_13:38:38 MyObis CONNECTED
2023-11-09_13:38:38 MyObis DISCONNECTED
2023-11-09_13:38:38 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:26 MyObis DISCONNECTED
2023-11-09_13:47:26 MyObis CONNECTED
2023-11-09_13:47:27 MyObis DISCONNECTED
2023-11-09_13:47:27 MyObis CONNECTED
2023-11-09_13:47:27 MyObis DISCONNECTED
2023-11-09_13:47:27 MyObis CONNECTED
2023-11-09_13:47:27 MyObis DISCONNECTED
2023-11-09_13:47:27 MyObis CONNECTED
2023-11-09_13:47:27 MyObis DISCONNECTED
2023-11-09_13:47:27 MyObis CONNECTED
2023-11-09_13:47:27 MyObis DISCONNECTED
2023-11-09_13:47:32 MyObis CONNECTED
2023-11-09_13:47:33 MyObis DISCONNECTED
2023-11-09_13:47:33 MyObis CONNECTED
2023-11-09_13:47:33 MyObis DISCONNECTED
2023-11-09_13:47:33 MyObis CONNECTED
2023-11-09_13:47:33 MyObis DISCONNECTED
2023-11-09_13:47:33 MyObis CONNECTED
2023-11-09_13:47:33 MyObis DISCONNECTED
2023-11-09_13:47:33 MyObis CONNECTED
2023-11-09_13:47:33 MyObis DISCONNECTED
2023-11-09_13:47:33 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:34 MyObis DISCONNECTED
2023-11-09_13:47:34 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:35 MyObis DISCONNECTED
2023-11-09_13:47:35 MyObis CONNECTED
2023-11-09_13:47:36 MyObis DISCONNECTED
2023-11-09_13:47:36 MyObis CONNECTED
2023-11-09_13:47:36 MyObis DISCONNECTED
2023-11-09_13:47:36 MyObis CONNECTED
2023-11-09_13:47:36 MyObis DISCONNECTED
2023-11-09_13:47:36 MyObis CONNECTED
2023-11-09_13:47:36 MyObis DISCONNECTED
2023-11-09_13:47:36 MyObis CONNECTED
2023-11-09_13:47:36 MyObis DISCONNECTED
2023-11-09_13:47:36 MyObis CONNECTED
2023-11-09_13:47:37 MyObis DISCONNECTED
2023-11-09_13:47:37 MyObis CONNECTED
2023-11-09_13:47:37 MyObis DISCONNECTED
2023-11-09_13:47:37 MyObis CONNECTED
2023-11-09_13:47:37 MyObis DISCONNECTED
2023-11-09_13:47:37 MyObis CONNECTED
2023-11-09_13:47:37 MyObis DISCONNECTED
2023-11-09_13:47:37 MyObis CONNECTED
2023-11-09_13:47:37 MyObis DISCONNECTED
2023-11-09_13:47:37 MyObis CONNECTED
2023-11-09_13:47:38 MyObis DISCONNECTED
2023-11-09_13:47:38 MyObis CONNECTED
2023-11-09_13:47:38 MyObis DISCONNECTED
2023-11-09_13:47:43 MyObis CONNECTED
2023-11-09_13:47:43 MyObis DISCONNECTED
2023-11-09_13:47:43 MyObis CONNECTED
2023-11-09_13:47:43 MyObis DISCONNECTED
2023-11-09_13:47:43 MyObis CONNECTED
2023-11-09_13:47:43 MyObis DISCONNECTED
2023-11-09_13:47:43 MyObis CONNECTED
2023-11-09_13:47:43 MyObis DISCONNECTED
2023-11-09_13:47:43 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:44 MyObis DISCONNECTED
2023-11-09_13:47:44 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:45 MyObis DISCONNECTED
2023-11-09_13:47:45 MyObis CONNECTED
2023-11-09_13:47:46 MyObis DISCONNECTED
2023-11-09_13:47:46 MyObis CONNECTED
2023-11-09_13:47:46 MyObis DISCONNECTED
2023-11-09_13:47:46 MyObis CONNECTED
2023-11-09_13:47:46 MyObis DISCONNECTED
2023-11-09_13:47:51 MyObis CONNECTED
2023-11-09_13:47:51 MyObis DISCONNECTED
2023-11-09_13:47:51 MyObis CONNECTED
2023-11-09_13:47:51 MyObis DISCONNECTED
2023-11-09_13:47:51 MyObis CONNECTED
2023-11-09_13:47:51 MyObis DISCONNECTED
2023-11-09_13:47:51 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:52 MyObis DISCONNECTED
2023-11-09_13:47:52 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:53 MyObis DISCONNECTED
2023-11-09_13:47:53 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:54 MyObis DISCONNECTED
2023-11-09_13:47:54 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:55 MyObis DISCONNECTED
2023-11-09_13:47:55 MyObis CONNECTED
2023-11-09_13:47:56 MyObis DISCONNECTED
2023-11-09_13:47:56 MyObis CONNECTED
2023-11-09_13:47:56 MyObis DISCONNECTED
2023-11-09_13:47:56 MyObis CONNECTED
2023-11-09_13:47:56 MyObis DISCONNECTED
2023-11-09_13:48:01 MyObis CONNECTED
2023-11-09_13:48:01 MyObis DISCONNECTED
2023-11-09_13:48:01 MyObis CONNECTED
2023-11-09_13:48:01 MyObis DISCONNECTED
2023-11-09_13:48:01 MyObis CONNECTED
2023-11-09_13:48:01 MyObis DISCONNECTED
2023-11-09_13:48:01 MyObis CONNECTED
2023-11-09_13:48:02 MyObis DISCONNECTED
2023-11-09_13:48:02 MyObis CONNECTED
2023-11-09_13:48:02 MyObis DISCONNECTED
2023-11-09_13:48:02 MyObis CONNECTED
2023-11-09_13:48:02 MyObis DISCONNECTED
2023-11-09_13:48:02 MyObis CONNECTED
2023-11-09_13:48:02 MyObis DISCONNECTED
2023-11-09_13:48:02 MyObis CONNECTED
2023-11-09_13:48:02 MyObis DISCONNECTED
2023-11-09_13:48:07 MyObis CONNECTED
2023-11-09_13:48:07 MyObis DISCONNECTED
2023-11-09_13:48:12 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:13 MyObis DISCONNECTED
2023-11-09_13:48:13 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:14 MyObis DISCONNECTED
2023-11-09_13:48:14 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:15 MyObis DISCONNECTED
2023-11-09_13:48:15 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:16 MyObis DISCONNECTED
2023-11-09_13:48:16 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:17 MyObis DISCONNECTED
2023-11-09_13:48:17 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:18 MyObis DISCONNECTED
2023-11-09_13:48:18 MyObis CONNECTED
2023-11-09_13:48:19 MyObis DISCONNECTED
2023-11-09_13:48:19 MyObis CONNECTED
2023-11-09_13:48:19 MyObis DISCONNECTED
2023-11-09_13:48:19 MyObis CONNECTED
2023-11-09_13:48:19 MyObis DISCONNECTED
2023-11-09_13:48:19 MyObis CONNECTED
2023-11-09_13:48:19 MyObis DISCONNECTED
2023-11-09_13:48:19 MyObis CONNECTED
2023-11-09_13:48:19 MyObis DISCONNECTED
2023-11-09_13:48:24 MyObis CONNECTED
2023-11-09_13:48:24 MyObis DISCONNECTED
2023-11-09_13:48:24 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:25 MyObis DISCONNECTED
2023-11-09_13:48:25 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:26 MyObis DISCONNECTED
2023-11-09_13:48:26 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:27 MyObis DISCONNECTED
2023-11-09_13:48:27 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:28 MyObis DISCONNECTED
2023-11-09_13:48:28 MyObis CONNECTED
2023-11-09_13:48:29 MyObis DISCONNECTED
2023-11-09_13:48:29 MyObis CONNECTED
2023-11-09_13:48:29 MyObis DISCONNECTED
2023-11-09_13:48:29 MyObis CONNECTED
2023-11-09_13:48:29 MyObis DISCONNECTED
2023-11-09_13:48:34 MyObis CONNECTED
2023-11-09_14:15:11 MyObis Version: 1␛␛␛␛␚␂�R␛␛␛␛␁␁␁␁v␅␌␌�bbrc␁␁v␁␇������␅␄␄M␋
2023-11-09_14:52:17 MyObis Version: jv␅␌&�bbrc␇␁w␇������␋
FHEM läuft bei mir bereits seit einer Weile, und ich kann damit (über das THZ-Modul) die Heizung lesen und steuern. Ein bisschen Grundverständnis bzgl. FHEM habe ich, aber zur THZ hatte ich auch auf reichhaltige Code-Schnipsel zurückgreifen können.
Bzgl. Stromzähler und Obis-Modul bin ich blutiger Anfänger, daher auch meine Frage, ob ich hier evtl. wesentliche Schritte übersehen habe.
Wenn ich auf dem RPi2 mit minicom auf USB1 lausche, kommen auch (Binär-)Daten reingerauscht, weshalb ich davon ausgehe, dass die Verkabkung an sich ok ist. Aber evtl. habe ich ja etwas anderes übersehen/vergessen?
EDIT:
Auf dem RPi2:
xyz@pi:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 6. Nov 12:56 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 8. Nov 15:33 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0 -> ../../ttyUSB1
Der 2. Adapter ist der Optokoppler (Hichi IR USB).
Die Baud-Rate steht auf 300, aber ich kann sie auch wieder auf 9600 setzen (über FHEM oder stty?):
xyz@pi:~ $ stty -F /dev/ttyUSB1
speed 300 baud; line = 0;
min = 0; time = 0;
ignbrk -brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo -echoe -echok -echoctl
Ah, jetzt kommt was! :D Nachdem ich die Baud-Rate wieder auf 9600 gesetzt hatte, fiel mir auf, dass auf der von @RalfRog verlinkten Seite erwähnt wird, dass für den L&G E320 der SML Parameter zu setzen ist. Danke für den Link! :) Eigentlich hätte ich mir das denken können, aber jeder Anfang ist etwas schwer.
Vielleicht noch dieser Hinweis zur CommandRef und MeterType:
Define
define <name> OBIS device|none [MeterType]
<device> gibt den seriellen Port oder den Hostnamen/die IP-Adresse:Port an. Für den Tibber Pulse ist stattdessen die vollständige URL im LAN anzugeben, unter der die Daten geladen werden können.
Bei seriellem Port (USB) und Linux gibt man hier entweder
als Gerät etwas wie /dev/ttyUSBx, an (x eine Zahl)
oder - um nach einem Neustart der Hardware keine geänderte Reihenfolge zu riskieren - sucht man die passende ID unter /dev/serial/by-id/, also z.B. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0
Optional: MeterType kann sein:
VSM102 -> Voltcraft VSM102
E110 -> Landis&&;Gyr E110
E350USB -> Landis&&;Gyr E350 USB-Version
MT382 -> ISKRA MT382
Standard -> Daten kommen als plainText
SML -> Smart Message Language
Ja, das kenne ich schon und hatte mit den Parametern herumgespielt. Auch SML hatte ich schon einmal in meiner Definition, aber es mangelte wohl an anderer Stelle (Problem vor dem PC ;)).
define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 SML
attr MyObis interval 600
attr MyObis pollingMode on
attr MyObis room Strom
attr MyObis unitReadings on
attr MyObis verbose 5
# DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 SML
# DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1
# FD 11
# FUUID xxxxx
# MeterType SML
# NAME MyObis
# NR 291
# PARTIAL
# STATE opened
# TYPE OBIS
# eventCount 1
# READINGS:
# 2023-11-09 18:23:55 1.x.xx.x.x.255 LGZ
# 2023-11-09 18:23:55 ManufID2 LGZ
# 2023-11-09 18:23:45 Version
# 2023-11-09 18:23:55 power x22 W
# 2023-11-09 18:24:25 state opened
# 2023-11-09 18:23:55 total_consumption xxx04.7 Wh
# 2023-11-09 18:23:55 total_feed xx9.1 Wh
#
Das Version Feld ist seltsamerweise leer.
Die L&G E320 Anleitung habe ich ja und sehe dort auch Erläuterungen für OBIS-Codes. Allerdings verstehe ich nicht, wie ich nun diesbzgl. etwas in fhem.cfg definieren muss. Z.B. las ich von diesem Beispiel (aus 2016):
attr EasymeterQ3C
channels
{"1.7"=>"Aktuelle_Leistung","21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
In meiner E320 Anleitung ist das alles so kryptisch beschrieben, dass ich nicht verstehe, was ich wie ins attr reinschreiben muss, damit ich bestimmte Werte in FHEM sehe. Kann mir dazu bitte jemand nochmal Hilfe geben? ❤️lichen Dank!
Mit dem Attribut channels kannst du den OBIS Code zu einen Text umbennen. Z.B. mit power oder total_feed verwendet das Modul schon Text anstatt des OBIS-Codes.
Z.B. dein erster Parameter "1.x.xx.x.x.255" kann umbennant werden. Allerdings kannst du nur das umbenennen was das Modul auch ausliest und als Reading darstellt.
Ich habe jetzt kein OBIS Modul im Einsatz - vermute aber, dass alle Codes die es ausliest auch in den Readings dargestellt werden.
Da bei dir dort keine weiteren Readings sind, liefert der Zähler vermutlich auch nicht mehr.
Lt.der Beschreibung:
Die optische INFO‐Schnittstelle arbeitet in zwei Modi: Standard und Erweitert. Die folgenden Daten werden periodisch jede Sekunde von der INFO‐Schnittstelle gepusht. Vielleicht kann man ja einen erweiterten Modus aktivieren und es wird dann mehr geliefert.
Die PIN vom Betreiber habe ich eingegeben, die weitere PIN-Abfrage deaktiviert und den erweiterten Datensatz (ohne PIN-Abfrage) aktiviert. Eigentlich sollte dann doch mehr kommen. Oder muss ich FHEM (oder gar den RPi2 mit dem Optokoppler dran) neu starten?
Zitat von: sunrise am 09 November 2023, 19:07:33...Oder muss ich FHEM (oder gar den RPi2 mit dem Optokoppler dran) neu starten?
Sicher nicht.
Vielleicht meldet sich ich der nächsten Zeit hier jemand mit Erfahrungen zum E320 und was da genau geht. Die drei wichtigsten Werten hast du zumindest schon mal.
https://www.landisgyr.de/product/landisgyr-e320/?download=288690&filename=https://www.landisgyr.de/webfoo/wp-content/uploads/2018/08/Benutzerhandbuch-E320.pdf
Weiss nicht ob es zu deinem Zähler passt aber dort gibt es unter 5.5.1 "Menü ID = InF" "Reduzierten Datensatz oder erweiterten Datensatz pushen"
und dann: 5.5.1.6 Datensatz auf INFO DSS mit EIN oder AUS
Gruß
Das habe ich schon gemacht, siehe Beitrag vorher:
Zitat von: sunrise am 09 November 2023, 19:07:33Die PIN vom Betreiber habe ich eingegeben, die weitere PIN-Abfrage deaktiviert und den erweiterten Datensatz (ohne PIN-Abfrage) aktiviert. Eigentlich sollte dann doch mehr kommen. Oder muss ich FHEM (oder gar den RPi2 mit dem Optokoppler dran) neu starten?
Ich kann ohne Passwort-Eingabe auch erweiterte Infos auf dem Display ablesen, und hoffe, dass auch die optische Schnittstelle diese Daten sendet, da ich ja auch den entsprechenden Punkt im Menü aktiviert habe.
Momentan weiß ich nicht, warum nicht mehr Werte kommen. Schaue ich mir später an. Gute 🌛!
Könnt Ihr mir erklären, was folgende Zeilen im FHEM-Log bedeuten?
2023.11.09 22:33:06 3: OBIS (MyObis) - Unknown Message: 1-x:xx.x.x*255(LGZ)
2023.11.09 22:33:06 3: OBIS (MyObis) - Unknown Message: 255-255:255.255.255*255()
Und wofür ist die Zeile unter "DeviceOverview > MyObis"? ([get] MyObis [update] <...>)
Screenshot 2023-11-10 120251.png
Danke!
Leider kommen immer noch nur diese Readings, obwohl ich gemäß Anleitung (5.5.2.1.6 ) "Erweiterter Datensatz" aktiviert habe (im Display steht auch unter "INFO": "InF on").
# READINGS:
# 2023-11-10 09:45:16 1.x.xx.x.x.255 LGZ
# 2023-11-10 09:45:16 ManufID2 LGZ
# 2023-11-09 18:23:45 Version
# 2023-11-09 18:47:20 energy_total xxx15.6 Wh
# 2023-11-09 18:47:20 feed_total xx9.1 Wh
# 2023-11-10 09:45:16 power x28 W
# 2023-11-10 11:59:22 state opened
# 2023-11-10 09:45:16 total_consumption xxxx63 Wh
# 2023-11-10 09:45:16 total_feed xx9.1 Wh
Weiterhin wundert mich, weshalb einige Readings so alt sind. Werden die nicht regelmäßig aktualisiert? Liegt's am Timing?
attr MyObis interval 600
attr MyObis pollingMode off
attr MyObis room Strom
attr MyObis unitReadings on
Außerdem verstehe ich nicht, weshalb einmal feed_total und einmal total_feed aufgeführt werden (gleiche Werte).
Und schließlich erscheint in der Zeile zur Version nichts. Das ist auch nicht normal, oder?
Nochmals herzlichen Dank für Eure Hilfe! :)
@gvzdus und andere Experten:
Ist es normal, dass ich im BUFFER (Type="OBIS") nur Sonderzeichen sehe?
(entschuldigt bitte, falls meine Unkenntlichmachung von Daten Unsinn oder/und hier kontraproduktiv ist 🫢)
obis 2023-11-10 at 12-33-40.png
Hier nochmal die Einstellungen dazu:
[code]define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 SML
attr MyObis interval 600
attr MyObis pollingMode off
attr MyObis room Strom
attr MyObis unitReadings on
# DEF /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1 SML
# DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@9600,8,N,1
# FD 11
# FUUID xxxxx
# MeterType SML
# NAME MyObis
# NR 291
# PARTIAL
# STATE opened
# TYPE OBIS
# eventCount 1
# READINGS:
# 2023-11-10 09:45:16 1.x.x.x.x.255 LGZ
# 2023-11-10 09:45:16 ManufID2 LGZ
# 2023-11-09 18:23:45 Version
# 2023-11-09 18:47:20 energy_total xxx15.6 Wh
# 2023-11-09 18:47:20 feed_total xx9.1 Wh
# 2023-11-10 09:45:16 power xxx8 W
# 2023-11-10 11:59:22 state opened
# 2023-11-10 09:45:16 total_consumption xxxx63 Wh
# 2023-11-10 09:45:16 total_feed xx9.1 Wh
# helper:
# BUFFER
Deine Bilder kann ich nicht sehen ::) File not found.
Zitat von: sunrise am 10 November 2023, 12:15:46Weiterhin wundert mich, weshalb einige Readings so alt sind. Werden die nicht regelmäßig aktualisiert? Liegt's am Timing?
Lösch doch einfach mal die Readings (deletereading <device <reading>), die stammen vielleicht noch aus der Zeit gestern in der du rumprobiert hast.
Die aktuellen Readings kommen ja wieder.
Zitat von: sunrise am 10 November 2023, 12:04:282023.11.09 22:33:06 3: OBIS (MyObis) - Unknown Message: 1-0:96.1.0*255(LGZ)
2023.11.09 22:33:06 3: OBIS (MyObis) - Unknown Message: 255-255:255.255.255*255()
Das sind zwei OBIS Kennungen die das Modul bei die offensichtlich nicht verarbeiten konnte. Ich weiss nicht welchem Zweck diese Kennung dient, aber 1-0:96.1.0*255 liefert mein Iskra Zähler auch. Der der Wert (LGZ) ist dein Herstellekürzel.
Hier ein Beispiel wo so etwas doch im Reading steht => https://forum.fhem.de/index.php?topic=135040.msg1287287;topicseen#msg1287287
Ist das eventuell dein ge-x-tes Reading "1.x.xx.x.x.255 LGZ"
Mit Verbose 4 oder 5 erfährst du mehr wie das Modul die Daten verarbeitet.
Zitat von: sunrise am 10 November 2023, 12:04:28Und wofür ist die Zeile unter "DeviceOverview > MyObis"? ([get] MyObis [update] <...>)
Steht vielleicht in der CommandRef etwas dazu?
Edit
Info zu den OBIS-Kennzahlen angehängt
Gruß Ralf
Zitat von: RalfRog am 10 November 2023, 13:01:17Deine Bilder kann ich nicht sehen ::) File not found.
Bei mir wird der Screenshot angezeigt. Kannst Du die Seite mit meinem Beitrag bitte nochmal neu laden?
Zitat von: RalfRog am 10 November 2023, 13:01:17Lösch doch einfach mal die Readings (deletereading <device <reading>), die stammen vielleicht noch aus der Zeit gestern in der du rumprobiert hast.
Die aktuellen Readings kommen ja wieder.
Ich habe alle MyObis Readings gelöscht. Jetzt gibt es nur das "state opened" Reading. Wie lange dauert es, bis weitere kommen?
Zitat von: RalfRog am 10 November 2023, 13:01:17Ist das eventuell dein ge-x-tes Reading "1.x.xx.x.x.255 LGZ"
Ja, sorry! 🫢
Zitat von: RalfRog am 10 November 2023, 13:01:17Mit Verbose 4 oder 5 erfährst du mehr wie das Modul die Daten verarbeitet.
Danke, mache ich (auf 5)!
Zitat von: RalfRog am 10 November 2023, 13:01:17Zitat von: sunrise am 10 November 2023, 12:04:28Und wofür ist die Zeile unter "DeviceOverview > MyObis"? ([get] MyObis [update] <...>)
Steht vielleicht in der CommandRef etwas dazu?
Schaue ich mir nachher genauer an...
Danke auch schonmal für den Link, die PDF-Datei etc.! :)
PS:
Im BUFFER kommen nach wie vor sehr viele Sonderzeichen (wie im Screenshot in meinem vorherigen Beitrag). Nur am Ende (ab EoM -1) wird es lesbar. Wenn ich die Browser-Seite neu lade, kommen neue Sonderzeichen.
Oha, seit 10.11., 09:45 Uhr kommen im MyObis-2023-11.log Logfile keine neuen Einträge mehr an, im BUFFER erscheinen aber (irgendwelche Sonderzeichen) Daten. Ich stehe auf dem Schlauch, sorry...
Zitat von: sunrise am 10 November 2023, 13:41:22Oha, seit 10.11., 09:45 Uhr kommen im MyObis-2023-11.log Logfile keine neuen Einträge mehr an, im BUFFER erscheinen aber (irgendwelche Sonderzeichen) Daten. Ich stehe auf dem Schlauch, sorry...
Wie gesagt ich habe das Modul nicht aktiv im Einsatz.
Falls der Buffer aber die Daten der Schnittstelle (Lesekopf) zeigt, ist es vielleicht ein Indiz, dass 9600,8,N,1 nicht die passenden Parameter sind. @kabanett hatte ja auch @300,7,E,1 ins Spiel gebracht (mit Meter Type VSM102, aber nicht alles gleichzeitig ändern).
Zitat von: sunrise am 10 November 2023, 13:35:26Schaue ich mir nachher genauer an...
Ist zum Verständnis aus meiner Sicht auch hilfreich. Bis "Das SML Protokoll" nach unten scrollen.
Edit:
uuups der Link fehlte: http://www.stefan-weigert.de/php_loader/sml.php
Das LogFile habe ich gelöscht und es bleibt nun leer. Leider weiß ich nicht, was dazu geführt hatte, dass dort gestern (bis heute morgens) noch ein paar Werte abgespeichert wurden. 🤔
Ich habe verschiedene Variationen bei der Verbindung ausprobiert (mit und ohne Stopbits, mit 8 und 7 Datenbits, mit SML und mit Standard). Im BUFFER kommen meist Sonderzeichen und jetzt (mit 7, E, 1 SML) so etwas (wird natürlich beim Refresh der Seite immer länger, aber das, was oben steht, bleibt unverändert):
BUFFER B{JJFvHFtB{fJFvHFdB{sJFvHNtB{>g'kH
FcB{rJFvHFdB{>g'kH
FcB{HJFvHNtB{>g'kH
FcB{JJFvHNtB{?g'kH
FcB{?g'kH
FcB{?g'kH
FcB{sJFvHFdB{?g'kH
FcB{>g'kH
FcB{>g'kH
FcB{>g'kH
FcB{>g'kH
FcB{sJFvHNdB{?g'kH
FcB{sJFvHNdB{j
FvHNtB{?g'kH
FcB{HJFvHNdB{?g'kH
FcB{dJFvHNtB{|JFvHFdB{fJFvHFdB{fJFvHFdB{qJFvHFdB{nOj␄`wS~B{qJFvHNdB{dJFvHFtB{?g'kH
FcB{HJFvHFtB{>g'kH
FcB{sJFvHFtB{dJFvHNdB{>g'kH
FcB{HJFvHFtB{>g'kH
FcB{?g'kH
FcB{?g'kH
FcB{?g'kH
FcB{?g'kH
FcB{?g'kH
FcB{dJFvHFdB{|JF
I'm lost. 😯
PS - aus dem fhem.log (verbose 5):
2023.11.10 15:25:25 5: Cmd: >define MyObis OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0@300,7,E,1 SML<
2023.11.10 15:25:25 5: Loading ./FHEM/47_OBIS.pm
2023.11.10 15:25:25 5: OBIS (MyObis) - Opening device...
2023.11.10 15:25:25 3: Opening MyObis device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0
2023.11.10 15:25:25 3: Setting MyObis serial parameters to 300,7,E,1
2023.11.10 15:25:25 3: OBIS (MyObis) - Init done
2023.11.10 15:25:25 3: MyObis device opened
2023.11.10 15:25:25 5: Starting notify loop for MyObis, 1 event(s), first is CONNECTED
2023.11.10 15:25:25 5: createNotifyHash
2023.11.10 15:25:25 5: End notify loop for MyObis
2023.11.10 15:25:25 5: Cmd: >setuuid MyObis xxxxx<
2023.11.10 15:25:25 5: Cmd: >attr MyObis interval 600<
2023.11.10 15:25:25 3: OBIS (MyObis) - Attr interval Val 600, dopoll =
2023.11.10 15:25:25 5: Cmd: >attr MyObis pollingMode off<
2023.11.10 15:25:25 3: OBIS (MyObis) - Attr pollingMode Val off, dopoll =
2023.11.10 15:25:25 5: Cmd: >attr MyObis room Strom<
2023.11.10 15:25:25 5: Cmd: >attr MyObis unitReadings on<
2023.11.10 15:25:25 5: Cmd: >attr MyObis verbose 5<
2023.11.10 15:25:25 5: Cmd: >define FileLog_MyObis FileLog /opt/fhem/log/MyObis-%Y-%m.log MyObis<
2023.11.10 15:25:25 5: Cmd: >setuuid FileLog_MyObis xxxxx<
2023.11.10 15:25:25 5: Cmd: >attr FileLog_MyObis archivedir /opt/fhem/log/archive/<
2023.11.10 15:25:25 5: Cmd: >attr FileLog_MyObis createGluedFile 1<
2023.11.10 15:25:25 5: Cmd: >attr FileLog_MyObis nrarchive 2<
2023.11.10 15:25:25 1: Including /opt/fhem/log/fhem.save
Warum auch immer Daten da waren (ob mit 9600 oder 300 Baud) - wenn Du mit dem Modul jetzt erstmal nichts siehst macht es Sinn sich mit dem Terminal (minicom) die Rohdaten anzuschauen, da kannst du ja mit den Schnittstellenparametern spielen.
Wenn sie so aussehen wie im Bild (aus dem Link in #1569) hast du die richtigen Schnittstellenparameter gefunden (ich denke 9600 oder 300 allenfalls 4800 kommen in Frage).
Edit:
Natürlich darf FHEM die Schnittstelle nicht belegen.
Zitat von: RalfRog am 10 November 2023, 13:55:02Zitat von: sunrise am 10 November 2023, 13:35:26Schaue ich mir nachher genauer an...
Ist zum Verständnis aus meiner Sicht auch hilfreich. Bis "Das SML Protokoll" nach unten scrollen.
Edit:
uuups der Link fehlte: http://www.stefan-weigert.de/php_loader/sml.php
Ah, danke, ich hatte mich schon gewundert, auf was Du Dich beziehst. ;)
In FHEM habe ich
MyObis deleted (damit es nicht ttyUSB1 belegt), und in minicom fängt es so an (anders als in dem verlinkten Artikel):
<...>
EDIT:
Bevor ich jetzt hier zig Permutationen zeige, schaue ich lieber einfach nochmal nach, ob die zu erwartende Sequenz nicht doch irgendwo noch auftaucht...
Nichts davon gleicht der im verlinkten Artikel gezeigten Sequenz.
Vielleicht habe ich es übersehen: Muss ich zuerst über minicom eine Art Initialisierung durchführen, also eine Startsequenz o.ä. senden, damit es funktioniert? Ich kenne mich überhaupt nicht mit seriellen Schnittstellen oder minicom aus.
Ein SML Paket sollte immer so starten:
1b 1b 1b 1b 01 01 01 01
Es kann natürlich sein dass du ein halbes paket am Anfang erwischst.
Aber wenn du ein paar Daten im minicom hast suche doch mal nach dem String.
Das sollte der Anfang des SML Paketes sein.
Gruß,
Stefan
300 8N1; 300 7E1; 9600 8N1; 9600 7E1 - alle Outputs enthalten auch nach längerem minicom Lauf nicht die Sequenz 1b 1b 1b 1b. Ich verstehe das nicht, denn gestern noch erhielt ich im Obis-Modul einige Werte.
Bedarf es da einer Initialisierung von mir (meinetwegen mit der Taschenlampe), damit das klappt?
Zitat von: sunrise am 10 November 2023, 18:44:05300 8N1; 300 7E1; 9600 8N1; 9600 7E1 - alle Outputs enthalten auch nach längerem minicom Lauf nicht die Sequenz 1b 1b 1b 1b. Ich verstehe das nicht, denn gestern noch erhielt ich im Obis-Modul einige Werte.
Bedarf es da einer Initialisierung von mir (meinetwegen mit der Taschenlampe), damit das klappt?
Welche Daten erhältst du denn überhaupt?
Aber die Stelle im minicom wo die Parameter eigesatellt werdn hast du gefunden - nehme ich an (wg. 00 8N1; 300 7E1; 9600 8N1; 9600 7E1)!
Irgendwelche Daten (in HEX) - soll ich sie hier posten?
Ich habe mir 4 Konfigs angelegt:
xyz@pi:/etc/minicom $ ll
insgesamt 20
-rw-r--r-- 1 root root 285 10. Nov 18:13 minirc.300_7e1
-rw-r--r-- 1 root root 285 10. Nov 18:13 minirc.300_8n1
-rw-r--r-- 1 root root 286 10. Nov 18:14 minirc.9600_7e1
-rw-r--r-- 1 root root 286 10. Nov 18:14 minirc.9600_8n1
xyz@pi:/etc/minicom $ cat *
# Machinell erzeugte Datei - Verwenden Sie "minicom -s" zum Ändern
pu port /dev/ttyUSB1
pu baudrate 300
pu bits 7
pu parity E
pu stopbits 1
pu rtscts No
pu xonxoff No
pu displayhex Yes
pu linewrap Yes
# Machinell erzeugte Datei - Verwenden Sie "minicom -s" zum Ändern
pu port /dev/ttyUSB1
pu baudrate 300
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
pu xonxoff No
pu displayhex Yes
pu linewrap Yes
# Machinell erzeugte Datei - Verwenden Sie "minicom -s" zum Ändern
pu port /dev/ttyUSB1
pu baudrate 9600
pu bits 7
pu parity E
pu stopbits 1
pu rtscts No
pu xonxoff No
pu displayhex Yes
pu linewrap Yes
# Machinell erzeugte Datei - Verwenden Sie "minicom -s" zum Ändern
pu port /dev/ttyUSB1
pu baudrate 9600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
pu xonxoff No
pu displayhex Yes
pu linewrap Yes
Und jeweils so aufgerufen, z.B.:
sudo TERM=linux minicom 9600_8n1 -C 9600_8n1.txt
Die 4 Output-Dateien (*.txt) könnte ich hier anhängen. Aber evtl. enthalten sie ja doch sensible Daten, und das wäre dann blöd.
Jedenfalls habe ich alle 4 Dateien vom Pi nach Windows geholt (scp), in Notepad++ geöffnet und nach der Sequenz gesucht - nichts.
Ich habe minicom noch nie benutzt (weiss gerade nicht welches Terminalprgramm ich zum Testen genutzt habe). Der Aufruf sieht an sich gut aus.
Ja, es können sensible Daten (nämlich die Zählernummer) enthalten sein. Aber es ist schwierig zu sagen ob du Quatsch erhältst oder richtige Daten.
Im Screenshot oben -wie von @stefanru erwähnt- wird ist ein Datenpaket innerhalb der Sequenz "1b 1b 1b 1b 01 01 01 01 ...Daten... 1b 1b 1b 1b CRC-Prüfsumme" enthalten.
Z.B. der Zählerstand (in Wh) wäre dann etwas wie "77 07 01 00 01 08 00 ff Daten". Hier erkennst du den OBIS-Code 01 08 00.
Die Datenpakete kommen dann alle paar Sekunden durchgerauscht.
Das habe ich verstanden. Aber wenn nicht einmal die Startsequenz auftritt, vermute ich, minicom nicht richtig anzuwenden oder es gibt sonst ein Problem. Gestern kamen ja ein paar Werte, also so ganz kaputt kann das Hardware- und Software-Setup nicht sein. Sehr seltsam, aber ich bleibe am Ball...
Die "Zählernummer" steht in einer Sequenz von 11 Byte, die auch das Herstellerkürzel "LGZ = 4c 47 5a" enthält. Kommt im Datenpaket ggfs. mehrmals vor.
Aber minicom hat (allein) Zugriff auf das Device und Daten kommen schon?
Nachdem ich die Obis Definition in FHEM wieder angelegt habe, kommt jetzt ganz oben das (Zahl steigend):
Internals:
CRC_Errors 50
Ganz banal - Lesekopf schlecht platziert?
Nein, der sitzt mittig mit dem Kabel nach unten, d.h. die beiden Öffnungen sitzen korrekt über der LED und Diode - soweit ich das beurteilen kann.
Ich habe nochmal MyObis entfernt (inkl. aller attr, sowie LogFile def. und sogar die Log-Datei selbst) und alles nochmal neu angelegt. Immerhin steht jetzt oben nichts mehr von CRC_Errors. Im BUFFER kommen aber wieder die bekannten Sonderzeichen. Und in den Readings gibt es nur state (opened). Entsprechend ist die Log-Datei von MyObis noch leer.
Irgendwie hatte ich es gestern (zufällig) geschafft, ein paar Werte rein zu bekommen.
Nur dass ich das nicht falsch verstehe: Es bedarf keiner channels o.ä., um weitere Readings zu erhalten, richtig?
Sorry, dass ich diesen Thread mit meinen vielen Fragen vollschreibe.
Vielleicht könnte ein Obis-Nutzer mit einem L&G E320 seine Konfig hier posten? Danke! :)
Habe mir nochmal das FHEM-Log von gestern Abend angeschaut, als ein paar Readings kamen. Da war 9600,8,N,1 und SML eingestellt:
2023.11.09 18:27:22 3: Opening MyObis device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0
2023.11.09 18:27:22 3: Setting MyObis serial parameters to 9600,8,N,1
2023.11.09 18:27:22 3: OBIS (MyObis) - Init done
2023.11.09 18:27:22 3: MyObis device opened
2023.11.09 18:27:22 3: OBIS (MyObis) - Attr interval Val 600, dopoll =
2023.11.09 18:27:22 3: OBIS (MyObis) - Attr pollingMode Val on, dopoll = 1
2023.11.09 18:27:22 1: Including /opt/fhem/log/fhem.save
2023.11.09 18:37:22 5: DevIo_SimpleWrite MyObis:
2023.11.09 18:37:22 4: OBIS (MyObis) - Wrote
2023.11.09 18:37:22 5: OBIS (MyObis) - Internal timer set to 2023-11-09 18:47:22
2023.11.09 18:37:23 5: OBIS (MyObis) - SML-Parse 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 5: OBIS (MyObis) - Full message-> 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 4: OBIS (MyObis) - MSG IS:
/
1-0:96.50.1*1(LGZ)
1-0:96.1.0*255(LGZ)
1-0:1.8.0*255(>xxx68.4*Wh)
1-0:2.8.0*255(xx9.1*Wh)
1-0:16.7.0*255(xxx5*W)
255-255:255.255.255*255()
(einige Werte habe ich unkenntlich gemacht (xx) bzw. gelöscht [redacted])
Man sieht oben auch sehr schön die zu erwartenden Sequenzen. Also sollte es doch mit 9600,8,N,1 und SML funktionieren, richtig?
Zitat von: sunrise am 10 November 2023, 20:03:56Habe mir nochmal das FHEM-Log von gestern Abend angeschaut, als ein paar Readings kamen. Da war 9600,8,N,1 und SML eingestellt:
2023.11.09 18:27:22 3: Opening MyObis device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0041-if00-port0
2023.11.09 18:27:22 3: Setting MyObis serial parameters to 9600,8,N,1
2023.11.09 18:27:22 3: OBIS (MyObis) - Init done
2023.11.09 18:27:22 3: MyObis device opened
2023.11.09 18:27:22 3: OBIS (MyObis) - Attr interval Val 600, dopoll =
2023.11.09 18:27:22 3: OBIS (MyObis) - Attr pollingMode Val on, dopoll = 1
2023.11.09 18:27:22 1: Including /opt/fhem/log/fhem.save
2023.11.09 18:37:22 5: DevIo_SimpleWrite MyObis:
2023.11.09 18:37:22 4: OBIS (MyObis) - Wrote
2023.11.09 18:37:22 5: OBIS (MyObis) - Internal timer set to 2023-11-09 18:47:22
2023.11.09 18:37:23 5: OBIS (MyObis) - SML-Parse 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 5: OBIS (MyObis) - Full message-> 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 4: OBIS (MyObis) - MSG IS:
/
1-0:96.50.1*1(LGZ)
1-0:96.1.0*255(LGZ)
1-0:1.8.0*255(>xxx68.4*Wh)
1-0:2.8.0*255(xx9.1*Wh)
1-0:16.7.0*255(xxx5*W)
255-255:255.255.255*255()
(einige Werte habe ich unkenntlich gemacht (xx) bzw. gelöscht [redacted])
Also sollte es doch mit 9600,8,N,1 und SML funktionieren, richtig?
Scheint so.
Der Start ist drin "SML-Parse 1B1B1B1B01010101" und die OBIS Kennungen für Herstellerkennung, Bezug, Einspeisung und Leistung. Also vermutlich der Reduzierte Datensatz.
Also theoretisch alles schick - aber irgendwie wackelt die Übertragung, das Interface oder sonst was.
Inzwischen habe ich meinen 2. Lesekopf am anderen Zähler angebracht und als MyObis2 angelegt. Leider hier dasselbe Bild - außer 'state' keine Readings. Das MyObis2 LogFile enthält nur:
2023-11-11_07:20:05 MyObis2 CONNECTED
Und im FHEM-Log (verbose 5):
2023.11.11 07:22:48 3: Opening MyObis2 device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0042-if00-port0
2023.11.11 07:22:48 3: Setting MyObis2 serial parameters to 9600,8,N,1
2023.11.11 07:22:48 3: OBIS (MyObis2) - Init done
2023.11.11 07:22:48 3: MyObis2 device opened
2023.11.11 07:22:48 3: OBIS (MyObis2) - Attr interval Val 600, dopoll =
2023.11.11 07:22:48 3: OBIS (MyObis2) - Attr pollingMode Val on, dopoll = 1
2023.11.11 07:26:55 5: Cmd: >define MyObis2 OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0042-if00-port0@9600,8,N,1,SML<
2023.11.11 07:26:55 5: OBIS (MyObis2) - Opening device...
2023.11.11 07:26:55 3: Opening MyObis2 device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0042-if00-port0
2023.11.11 07:26:55 3: Setting MyObis2 serial parameters to 9600,8,N,1
2023.11.11 07:26:55 3: OBIS (MyObis2) - Init done
2023.11.11 07:26:55 3: MyObis2 device opened
2023.11.11 07:26:55 5: Starting notify loop for MyObis2, 1 event(s), first is CONNECTED
2023.11.11 07:26:55 5: End notify loop for MyObis2
2023.11.11 07:26:55 5: Cmd: >setuuid MyObis2 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx<
2023.11.11 07:26:55 5: Cmd: >attr MyObis2 interval 600<
2023.11.11 07:26:55 3: OBIS (MyObis2) - Attr interval Val 600, dopoll =
2023.11.11 07:26:55 5: Cmd: >attr MyObis2 pollingMode on<
2023.11.11 07:26:55 3: OBIS (MyObis2) - Attr pollingMode Val on, dopoll = 1
2023.11.11 07:26:55 5: OBIS (MyObis2) - Internal timer set to 2023-11-11 07:36:55
2023.11.11 07:26:55 5: Cmd: >attr MyObis2 room Strom<
2023.11.11 07:26:55 5: Cmd: >attr MyObis2 unitReadings on<
2023.11.11 07:26:55 5: Cmd: >attr MyObis2 verbose 5<
2023.11.11 07:26:55 5: Cmd: >define FileLog_MyObis2 FileLog /opt/fhem/log/MyObis2-%Y-%m.log MyObis2<
2023.11.11 07:26:55 5: Cmd: >setuuid FileLog_MyObis2 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx<
2023.11.11 07:26:55 5: Cmd: >attr FileLog_MyObis2 archivedir /opt/fhem/log/archive/<
2023.11.11 07:26:55 5: Cmd: >attr FileLog_MyObis2 createGluedFile 1<
2023.11.11 07:26:55 5: Cmd: >attr FileLog_MyObis2 nrarchive 2<
2023.11.11 07:26:55 5: Cmd: >setstate FileLog_MyObis2 active<
2023.11.11 07:26:55 5: Cmd: >setstate MyObis2 opened<
2023.11.11 07:26:55 5: Cmd: >setstate MyObis2 2023-11-11 07:22:48 state opened<
Sieht hier irgendetwas unerwartet aus?
Muss ich etwas aus vzlogger.conf von dieser Webseite (https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/landisgyr_e320#beispielkonfiguration) in FHEM übernehmen (neben der bereits o.g. Parameter für die serielle Kommunikation; und auf SML habe ich ja auch schon eingestellt)? Ich nutze vzlogger nicht, sehe aber dort im Code einige auf meinen E320 zutreffenden Zähler, die ich in FHEM nirgendwo definiert/eingestellt habe, z.B. "identifier": "1-0:1.8.0". Mir ist jetzt nicht klar, ob das in FHEM bzw. im Obis Modul notwendig ist, damit in den Readings etwas erscheint. Sorry, dass ich mich so ungeschickt anstelle. 🫢
ZitatMir ist jetzt nicht klar, ob das in FHEM bzw. im Obis Modul notwendig ist, damit in den Readings etwas erscheint.
Brauchst Du nicht.
ZitatUnd in den Readings gibt es nur state (opened).
Also das serielle device OS-seitig gefunden
ZitatAlso sollte es doch mit 9600,8,N,1 und SML funktionieren, richtig?
Yes.
Bleibt dann nur
Zitataber irgendwie wackelt die Übertragung, das Interface oder sonst was.
ZitatLesekopf schlecht platziert
scheint mir auch am nahe liegendsten. Schieb den mal millimeterweise in allen Richtungen.
Boah - Asche auf mein Haupt! 🫢 Das war es!
Ich hatte - auch beim 2. Lese-Schreib-Kopf - diese kleinen "Nasen" unterhalb der optischen Schnittstelle nicht bemerkt und den Kopf so platziert wie ich es für richtig hielt (Auf- und Zuklappen des Kopfes und Checken, ob die LED/Diode beim Zuklappen dann die Schnittstelle korrekt abdecken). Offenbar war ich zu blöd dazu. Der Lese-Schreib-Kopf passt exakt über diese 2 kleinen "Nasen", so dass er dann korrekt sitzt. So habe ich vielen Mitlesern und Schreibern hier Eure Zeit gestohlen - es tut mir ehrlich leid!
Umso mehr danke ich für Eure Geduld und Hilfe! ❤️
Ich hoffe, dass ich hier weiterhin Fragen stellen darf. ;)
Jedenfalls wünsche ich Euch allen ein gutes Wochenende! :)
PS:
Zitat von: RalfRog am 10 November 2023, 19:25:40Ganz banal - Lesekopf schlecht platziert?
Zitat von: sunrise am 10 November 2023, 19:26:28Nein, der sitzt mittig mit dem Kabel nach unten, d.h. die beiden Öffnungen sitzen korrekt über der LED und Diode - soweit ich das beurteilen kann.
Von wegen - SORRY! 🫢
Jetzt sieht es (fast) ganz gut aus:
# READINGS:
# 2023-11-11 09:19:47 1.0.96.1.0.255 LGZ
# 2023-11-11 09:19:47 ManufID2 LGZ
# 2023-11-11 09:19:47 power x33 W
# 2023-11-11 09:19:48 state opened
# 2023-11-11 09:19:47 total_consumption xxxx49.4 Wh
# 2023-11-11 09:19:47 total_feed xx9.1 Wh
Obwohl auf beiden Zählern im Display bei InF "on" steht (hatte ich gemäß Anleitung, Kap. 5.5.1.6 Datensatz auf INFO DSS aktiviert), fehlen trotzdem noch die erweiterten Infos bei den Readings. Die müssten aber doch eigentlich auch automatisch kommen (sofern eben die erweiterten Infos korrekt aktiviert sind - das checke ich nochmal!), richtig?
Der Vollständigkeit halber: Die PIN-Abfrage ist auf beiden Zählern deaktiviert (dürfte aber für die erweiterten Infos an der Schnittstelle keine Rolle spielen).
Schön das es funktioniert und @KölnSolar dich zum Bewegen bewegen konnte ;D
Ich habe auf meinem ISKRA ebenfalls die PIN-Abfrage deaktiviert - nur dann zeigt der Zähler in der zweiten Displayzeile die aktuelle Leistung an. Erweiterte Daten Liefert er keine (jedenfalls ist mir keine Einstellung untergekommen), aber Leistung und Energie reicht mir auch aus - der Rest wäre nice to know.
Ein Sache würde mich interessieren:
was genau enthält denn jetzt wo es funktioniert der "Buffer" aus dem List?
BTW:
dem "1.0.96.1.0.255 LGZ" kannst du mit dem Attribut Channels einen Namen geben oder es mit ignoreUnknown (evtl kontraproduktiv für erweiterte Daten) ausblenden.
Gruß und viel Erfolg bei der Suche nach dem erweiterten Datensatz :)
Zitat von: RalfRog am 11 November 2023, 10:47:33Schön das es funktioniert und @KölnSolar dich zum Bewegen bewegen konnte ;D
Es ist mir peinlich, dass ich Deinem Hinweis nicht gleich richtig gefolgt bin. Jedenfalls danke Euch Beiden! 😊
Zitat von: RalfRog am 11 November 2023, 10:47:33Ich habe auf meinem ISKRA ebenfalls die PIN-Abfrage deaktiviert - nur dann zeigt der Zähler in der zweiten Displayzeile die aktuelle Leistung an. Erweiterte Daten Liefert er keine (jedenfalls ist mir keine Einstellung untergekommen), aber Leistung und Energie reicht mir auch aus - der Rest wäre nice to know.
Danke, das kann so auch auf den E320 zutreffen.
Kann jemand mit einem Landis+Gyr E320 bestätigen, dass über die Schnittstelle keine erweiterten Infos gesendet werden? (wobei ich mich schon frage, wozu dann die Einstellung sein soll)
Zitat von: RalfRog am 11 November 2023, 10:47:33Ein Sache würde mich interessieren:
was genau enthält denn jetzt wo es funktioniert der "Buffer" aus dem List?
Das wollte ich auch sehen, aber wenn ich auf den TYPE OBIS Link klicke, lande ich wieder auf der Seite, wo nun MyObis1 und neu MyObis2 verlinkt sind. Ich wüsste jetzt nicht, wie ich zum jetzigen Buffer komme, schaue aber nachher nochmal nach und werde berichten.
Zitat von: RalfRog am 11 November 2023, 10:47:33BTW:
dem "1.0.96.1.0.255 LGZ" kannst du mit dem Attribut Channels einen Namen geben oder es mit ignoreUnknown (evtl kontraproduktiv für erweiterte Daten) ausblenden.
Gruß und viel Erfolg bei der Suche nach dem erweiterten Datensatz :)
Nochmals herzlichen Dank! 👍
ZitatEs ist mir peinlich, dass ich Deinem Hinweis nicht gleich richtig gefolgt bin
Muss es nicht. Ist manchmal so, dass man sich zu 100% in der Sache sicher ist. Deshalb hatte ich ja auch nur Ralfs Aussagen per Zitat bekräftigt, um Dich dann doch zweifeln zu lassen. ;)
Hallo zusammen,
ich habe einen Elster AS1440. Die einzigen Daten die ich sehe sind Version und State. Wenn ich USB abstecke geht state auf "closed". Das ist die einzige Reaktion. Außer den beiden werden keine Readings angelegt. Update auf FHEM und RPi sind erfolgt. Internetrecherche war bislang erfolglos. Weiß von euch jemand woran es liegen kann? Bin ich an der Stellle überhaupt richtig? Ich verfolge das Forum immer wieder, habe aber noch nie eine Frage gestellt.
Readings
Version ELS5\@V9.36 2023-11-11 12:53:14
state opened 2023-11-11 13:23:11
Das ist ja nicht viel Information von Dir. Aber immerhin erkennt das Modul, dass der Lesekopf am USB hängt bzw. wieder abgezogen wird.
Vielleicht hilft als Einstieg zu Zählereigenheiten => https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
und eine Suche nach AS1440: bei Sonstige Systeme gibt es einige Treffer z.B. => https://forum.fhem.de/index.php?topic=86611.msg791551#msg791551
Gruß
Danke, schaue ich mir gleich an. Welche Infos hätte ich denn noch geben können, die unter Umständen zielführend wären?
=> Die beiden Seiten kannte ich schon. Der zweite Links nennt den Befehl für das define eines AS1440. Habe ich genauso gemacht. Mit dem Unterschied, dass ich das per getDeviceByID eingebunden habe.
defmod PowerMeter OBIS /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0@300,7,E,1 AS1440 9600
attr PowerMeter event-on-change-reading .*
attr PowerMeter event-on-update-reading .*
attr PowerMeter interval 120
attr PowerMeter timestamp-on-change-reading .*
attr PowerMeter verbose 5
setstate PowerMeter opened
setstate PowerMeter 2023-11-11 13:36:33 Version ELS5\@V9.36
setstate PowerMeter 2023-11-11 13:23:11 state opened
Der erste Link beschreibt den AS1440 mit der Schnittstelle. Die Befehle die da genannt werden wie z.B. "/?!\r\n" macht aber schon das Modul oder wo muss ich die eingeben?
Zitat von: SPS_ler am 11 November 2023, 16:41:32Danke, schaue ich mir gleich an. Welche Infos hätte ich denn noch geben können, die unter Umständen zielführend wären?
Das List ist schon praktisch um zu sehen was Du gemacht hast.
Welche Bedeutung hat die Zahl 9600 am Ende des define/defmod?
Die Bedienungsanleitungen die so zu finden sind schweigen sich ja ziemlich aus was die optische Schnittstelle angeht. Immerhin kann man beim Volkzähler-Link sehen, dass der Start der Kommunikation getriggert werden muss "/?!" und welche Parameter die Schnittstelle verwendet.
Zitat von: SPS_ler am 11 November 2023, 16:41:32Die Befehle die da genannt werden wie z.B. "/?!\r\n" macht aber schon das Modul oder wo muss ich die eingeben?
Ich hoffe, dass das Modul das macht sonst würde es nicht funktionieren. Von Hand kommt es dann in Betracht wenn du die Kommunikation mit einem Terminalprogramm testen würdest.
Ich bin jetzt nicht der Perl-Versteher aber im Code (47_OBIS.pm 27732 2023-07-08 10:03:12Z gvzdus) steht:
170 my %devs= (
171 # Name, Init-String, interval, 2ndInit
172 "none" => ["", -1, ""],
173 "Unknown" => ["", -1, ""],
174 "SML" => ["", -1, ""],
175 "Ext" => ["", -1, ""],
176 "Standard" => ["", -1, ""],
177 "VSM102" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
178 "E110" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
179 "E350USB" => ["/?!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
180 "AS1440" => ["/2!".chr(13).chr(10), 600, chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],
181 "MT382" => ["/?!".chr(13).chr(10), 20, chr(0).chr(0).chr(0).chr(0).chr(0).chr(0).chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)] #this line added by alkazaa
182 );Vorschlag zum TestenAls Init-String in der Zeile 180 für AS1440 wird "/2!" genutzt => das wäre verkehrt. Der Typ "VSM102" scheint eher zu passen.
Versuch es doch mal mit
defmod PowerMeter OBIS /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0@300,7,E,1 VSM102
Gruß Ralf
Hallo zusammen!
Zitat von: sunrise am 11 November 2023, 11:12:57Zitat von: RalfRog am 11 November 2023, 10:47:33Ein Sache würde mich interessieren:
was genau enthält denn jetzt wo es funktioniert der "Buffer" aus dem List?
Das wollte ich auch sehen, aber wenn ich auf den TYPE OBIS Link klicke, lande ich wieder auf der Seite, wo nun MyObis1 und neu MyObis2 verlinkt sind. Ich wüsste jetzt nicht, wie ich zum jetzigen Buffer komme, schaue aber nachher nochmal nach und werde berichten.
Als ich nur einen Lesekopf definiert hatte, erhielt ich durch Klick auf OBIS (http://pi.fritz.box:8083/fhem?cmd=list%20TYPE=OBIS&fwcsrf=csrf_xxxxx) (unten, hinter
TYPE) eine Seite, wo auch der BUFFER angezeigt wurde.
obis 2023-11-12 063341.png
Nachdem ich nun einen 2. Lesekopf definiert habe, erscheint stattdessen eine Seite, wo es nur diese beiden Links gibt, aber keine Seite zum jeweiligen BUFFER:
obis 2023-11-12 063405.png
Wenn ich auf den einen oder anderen Link klicke, lande ich wieder auf der jeweiligen Seite, die ich im 1. Screenshot zeige.
Wie kann ich nun den jeweiligen BUFFER sehen, und weshalb ist die Darstellung/Verlinkung bei zwei Leseköpfen anders als bei nur einem? Oder gibt es irgendwo anders einen Link zum BUFFER? Ich habe keinen gefunden, aber evtl. ist es nicht offensichtlich.
Wenn ich auf SML (http://pi.fritz.box:8083/fhem?cmd=list%20TYPE=SML&fwcsrf=csrf_xxxxx) klicke (hinter
MeterType) wird die FHEM Hauptseite ("SecurityCheck: ...") geladen. Soll das so sein?
Immerhin kann ich jetzt Plots erstellen, z.B. so (ist noch nicht optimiert):
obis 2023-11-12 064934.png
Die Spitzen von >4kW Leistung kann ich mir nicht erklären. Dass der Plot ab ca. 0:00 Uhr "weicher" wird, liegt daran, dass ich
intervall von 60 auf 600 erhöht hatte (und
pollingMode on belassen). Mit anderen Einstellungen wie z.B.
event-on-change-reading und
event-on-update-reading experimentiere ich noch.
Nochmal zum erweiterten Datensatz, siehe E320 Benutzerhandbuch:
Zitat5.5.2 Optische Schnittstelle: INFO DSS
Datenschübe
Die optische INFO-Schnittstelle arbeitet in zwei Modi: Standard und Erweitert. Die folgenden Daten werden periodisch jede Sekunde von der INFO‐Schnittstelle gepusht.
- Herstellerkennung
- Gerätekennung
- Zählerstand für +A (falls vorhanden)
- Zählerstand für ‐A (falls vorhanden)
- Momentanleistung (falls aktiviert)
Mir ist hier nicht klar, welche Daten beim aktivierten erweiterten Datensatz über die Schnittstelle gesendet werden. Ich habe folgende Readings:
1.0.96.1.0.255 LGZ
ManufID2 LGZ
power xx3 W
state opened
total_consumption xxxx49.4 Wh
total_feed xx9.1 WhWas davon ist "erweitert"?
Warum erscheint der Name des Parameters der Gerätekennung als "1.0.96.1.0.255" und eben nicht als "Gerätekennung"? Und weshalb gibt es noch den Parameter "ManufID2", der ebenfalls das Kürzel des Herstellers (in meinem Fall LGZ) zeigt?
Zitat von: sunrise am 12 November 2023, 07:20:35Als ich nur einen Lesekopf definiert hatte, erhielt ich durch Klick auf OBIS (unten, hinter TYPE) eine Seite, wo auch der BUFFER angezeigt wurde.
Ist nicht kriegsentscheidend, war nur neugierig.
Zitat...erhielt ich durch Klick auf OBIS...
... wo es nur diese beiden Links gibt...
MyObis1
MyObis2
Ein wenig OT aber das ist in FHEM eigentlich immer so, dass beim Klick auf den Type alle definierten Devices diesen Typs erscheinen.
Zitat von: sunrise am 12 November 2023, 07:20:35...
Nochmal zum erweiterten Datensatz, siehe E320 Benutzerhandbuch:
Zitat5.5.2 Optische Schnittstelle: INFO DSS
Datenschübe
Die optische INFO-Schnittstelle arbeitet in zwei Modi: Standard und Erweitert. Die folgenden Daten werden periodisch jede Sekunde von der INFO‐Schnittstelle gepusht.
- Herstellerkennung
- Gerätekennung
- Zählerstand für +A (falls vorhanden)
- Zählerstand für ‐A (falls vorhanden)
- Momentanleistung (falls aktiviert)
Mir ist hier nicht klar, welche Daten beim aktivierten erweiterten Datensatz über die Schnittstelle gesendet werden. Ich habe folgende Readings:
1.0.96.1.0.255 LGZ
ManufID2 LGZ
power xx3 W
state opened
total_consumption xxxx49.4 Wh
total_feed xx9.1 WhWas davon ist "erweitert"?
Warum erscheint der Name des Parameters der Gerätekennung als "1.0.96.1.0.255" und eben nicht als "Gerätekennung"? Und weshalb gibt es noch den Parameter "ManufID2", der ebenfalls das Kürzel des Herstellers (in meinem Fall LGZ) zeigt?
Vielleicht sind die fünf Werte schon der erweiterte Datensatz (kannst den ja mal abschalten und schauen was dann noch kommt). ;)
Die angegebenen fünf Werte hast Du ja als Readings
Zitat| Herstellerkennung | ManufID2 LGZ |
| Gerätekennung | 1.0.96.1.0.255 LGZ |
| Zählerstand für +A (falls vorhanden) | total_consumption xxxx49.4 Wh |
| Zählerstand für -A (falls vorhanden) | total_feed xx9.1 Wh |
| Momentanleistung (falls aktiviert) | power xx3 W |
ZitatWarum erscheint der Name des Parameters der Gerätekennung als "1.0.96.1.0.255" und eben nicht als "Gerätekennung"? Und weshalb gibt es noch den Parameter "ManufID2", der ebenfalls das Kürzel des Herstellers (in meinem Fall LGZ) zeigt?
Einem Teil der OBIS-Codes ist im Modul schon ein Text wie "power" oder "ManufID2" etc. zugeordnet, alle anderen werden als Code (1.0.96.1.0.255) mit zugehörigem Wert dargestellt.
Es gibt mehrere OBIS-Codes in denen das Kürzel des Zählers/Herstellers (bei dir LGZ) enthalten ist. Steht ja auch auf dem Zähler z.B. in der Zählernummer drin.
Wenn Du möchtest kannst du mit dem Attribut Channels {"1.0.96.1.0.255"=>"Gerätekennung"} definieren (nicht getestet).
Gruß Ralf
Danke! 👍
Hast Du eine Idee, wieso ich ein total_feed Reading habe, obwohl ich gar nichts einspeise? Ich habe keine PV-Anlage o.a. Einspeisequellen und wundere mich daher generell, dass dieses Reading erscheint, aber auch über den Wert selbst (xx9.1 Wh). Immerhin ändert er sich nicht, aber m.E. sollte er Null sein oder das Reading gar nicht erst angezeigt werden, oder irre ich mich?
Ob angezeigt oder nicht - woher die xx9.1 Wh "Einspeisung" (total_feed) herkommen sollen, frage ich mich schon. 🤔
PS:
Das mit channels funktioniert. 😊
Zitat von: sunrise am 12 November 2023, 11:13:18Hast Du eine Idee, wieso ich ein total_feed Reading habe, obwohl ich gar nichts einspeise?
Vermutlich weil Du einen Zweirichtungszähler hast. Schau doch mal auf das Display. Ich würde annehmen, dass da im Wechsel xxx.x49 kWh mit Kennung 1.8.0 und x.xx9 kWh mit Kennung 2.8.0 stehen und in der zweiten Zeile (durch die PIN-Freischaltung) eventuell die aktuelle Leistung.
Immerhin ist auch aus #1584 ersichtlicht, dass die Daten vom Zähler übermittelt werden.
Zitat von: sunrise am 10 November 2023, 20:03:562023.11.09 18:37:23 5: OBIS (MyObis) - SML-Parse 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 5: OBIS (MyObis) - Full message-> 1B1B1B1B01010101 [redacted] 29FB7
2023.11.09 18:37:23 4: OBIS (MyObis) - MSG IS:
/
1-0:96.50.1*1(LGZ)
1-0:96.1.0*255(LGZ)
1-0:1.8.0*255(>xxx68.4*Wh)
1-0:2.8.0*255(xx9.1*Wh)
1-0:16.7.0*255(xxx5*W)
255-255:255.255.255*255()
Ja, es ist ein Zweirichtungszähler. Aber woher kommen die xx9.1 Wh Einspeisung? Mein Netzbetreiber wird es wissen...
Inzwischen habe ich den Stromzähler meiner Wärmepumpe in meinen anderen Plots integriert:
https://forum.fhem.de/index.php?msg=1292894
Zitat von: RalfRog am 12 November 2023, 10:54:31Wenn Du möchtest kannst du mit dem Attribut Channels {"1.0.96.1.0.255"=>"Gerätekennung"} definieren (nicht getestet).
Ja, das klappt prima:
attr MyObis1 channels {"1.0.96.1.0.255"=>"Gerätekennung"}Macht es eigentlich Sinn und ist es möglich, auch Readings "umzubenennen", die schon eine Bezeichnung (aus dem Modul-Code) haben? Z.B. würde ich gerne wie folgt umbenennen:
- power => aktuelle Leistung
- total_consumption => gesamter Verbrauch
- total_feed => gesamte Einspeisung (auch wenn ich keine habe)
Allerdings hat entsprechend folgendes offenbar keine Wirkung (bis auf die "Gerätekennung"), d.h. die anderen Readings haben nach wie vor die englischen Bezeichnungen:
attr MyObis1 channels {"1.0.96.1.0.255"=>"Gerätekennung","ManufID2"=>"Hersteller ID","power"=>"aktuelle Leistung","total_consumption"=>"gesamter Verbrauch","total_feed"=>"gesamte Einspeisung"}
Probiere es aus.
Allerdings bist du das Thema gedanklich falsch angegangen.
Der Zähler liefert
1-0:96.50.1*1(LGZ)
1-0:96.1.0*255(LGZ)
1-0:1.8.0*255(>xxx68.4*Wh)
1-0:2.8.0*255(xx9.1*Wh)
1-0:16.7.0*255(xxx5*W)
255-255:255.255.255*255()
D.h. du musst den Quelldaten (OBIS) neue Namen geben. Die Namen der Readings erzeugt das Modul auch nur aus den OBIS-Kennungen.
Das sieht man doch ganz gut im Log.
Achso, ich dachte, man müsse die standardmäßig angezeigten Readings-Namen überschreiben! Kaum macht man's richtig, funktioniert's. ;)
Allerdings irritiert mich, dass nun zwischen den Werten und den Einheiten ein Stern dargestellt wird, wo beim 2. Zähler (für den ich die Readings nur für die Gerätekennung angepasst habe) je ein Leerzeichen steht (wie es sonst zu erwarten ist).
Zähler 1:
# Channels:
# 1.0.1.8.0.255 gesamter_Verbrauch
# 1.0.16.7.0.255 Leistung
# 1.0.2.8.0.255 gesamte_Einspeisung
# 1.0.96.1.0.255 Gerätekennung
# 1.0.96.50.1.1 Hersteller_ID
#
setstate MyObis1 opened
setstate MyObis1 2023-11-13 15:17:02 Gerätekennung LGZ
setstate MyObis1 2023-11-13 15:17:02 Hersteller_ID LGZ
setstate MyObis1 2023-11-13 15:17:02 Leistung xxx1*W
setstate MyObis1 2023-11-13 15:17:02 gesamte_Einspeisung xx9.1*Wh
setstate MyObis1 2023-11-13 15:17:02 gesamter_Verbrauch >xxxx60.4*Wh
setstate MyObis1 2023-11-13 15:17:10 state opened(Warum sind hier * zwischen dem Wert und der Einheit? Und weshalb das > beim gesamten Verbrauch?)
Zähler 2:
# Channels:
# 1.0.96.1.0.255 Gerätekennung
#
setstate MyObis2 opened
setstate MyObis2 2023-11-13 15:17:02 Gerätekennung LGZ
setstate MyObis2 2023-11-13 15:17:02 ManufID2 LGZ
setstate MyObis2 2023-11-13 15:17:02 power 0 W
setstate MyObis2 2023-11-13 15:17:10 state opened
setstate MyObis2 2023-11-13 15:17:02 total_consumption xxxx7.9 Wh
setstate MyObis2 2023-11-13 15:17:02 total_feed xx8.8 Wh(Hier sieht es ok aus, d.h. kein * und kein >.)
Hallo, weiß jemand, was es mit dieser Meldung auf sich hat? Sie kommt von beiden Leseköpfen/ Zählern und taucht immer wieder im FHEM Logfile auf:
2023.11.19 12:22:54 3: OBIS (MyObis1) - Unknown Message: 255-255:255.255.255*255()
2023.11.19 12:23:01 3: OBIS (MyObis2) - Unknown Message: 255-255:255.255.255*255()
Mir ist soweit klar, dass die Codes offenbar unbekannt sind, aber ich frage mich, ob das ein Problem bei meinem Setup bedeutet oder ich das schlicht ignorieren kann.
PS: Im OBIS Logfile sind keine Fehlermeldungen, und die o.g. Meldung taucht dort auch nicht auf.
Sorry, noch eine Frage - diesmal bzgl. event-aggregator. Für meine Zähler habe ich u.a. das definiert:
attr MyObis1 event-aggregator power:120:linear:mean,total_consumption:300:none:v
Das führt aber zu PERL Warnungen im FHEM Logfile:
2023.11.19 12:54:10 1: PERL WARNING: Argument "xxxx07.9 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 12:54:10 1: PERL WARNING: Argument "xxxx91.1 Wh" isn't numeric in addition (+) at FHEM/TimeSeries.pm line 256.
2023.11.19 12:54:10 1: PERL WARNING: Argument "xxxx91.1 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:54:10 1: PERL WARNING: Argument "xxxx07.9 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:54:10 1: PERL WARNING: Argument "xxxx91.1 Wh" isn't numeric in numeric gt (>) at FHEM/TimeSeries.pm line 362.
2023.11.19 12:54:10 1: PERL WARNING: Argument "1017 W" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:54:10 1: PERL WARNING: Argument "1017 W" isn't numeric in numeric gt (>) at FHEM/TimeSeries.pm line 362.
2023.11.19 12:54:32 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50022) line 1, <GEN3098> line 2507.
2023.11.19 12:54:32 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50028) line 1, <GEN3098> line 2534.
2023.11.19 12:54:32 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50034) line 1, <GEN3098> line 2549.
2023.11.19 12:54:32 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50040) line 1, <GEN3098> line 2574.
2023.11.19 12:54:32 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50046) line 1, <GEN3098> line 2587.
2023.11.19 12:55:10 1: PERL WARNING: Argument "xxxx20.8 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 12:55:10 1: PERL WARNING: Argument "xxxx20.8 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:55:40 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50017) line 1, <GEN3104> line 2496.
2023.11.19 12:55:40 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50023) line 1, <GEN3104> line 2523.
2023.11.19 12:55:40 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50029) line 1, <GEN3104> line 2538.
2023.11.19 12:55:40 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50035) line 1, <GEN3104> line 2563.
2023.11.19 12:55:40 1: PERL WARNING: Argument "n.a." isn't numeric in division (/) at (eval 50041) line 1, <GEN3104> line 2576.
2023.11.19 12:56:10 1: PERL WARNING: Argument "xxxx33.7 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 12:56:10 1: PERL WARNING: Argument "xxxx33.7 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:57:10 1: PERL WARNING: Argument "xxxx46.8 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 12:57:10 1: PERL WARNING: Argument "xxxx46.8 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:58:10 1: PERL WARNING: Argument "xxxx63.7 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 12:58:10 1: PERL WARNING: Argument "xxxx63.7 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 12:59:10 1: PERL WARNING: Argument "xxxx80.6 Wh" isn't numeric in division (/) at FHEM/TimeSeries.pm line 370.
2023.11.19 13:00:10 1: PERL WARNING: Argument "xxxx97.4 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 13:00:10 1: PERL WARNING: Argument "xxxx80.6 Wh" isn't numeric in addition (+) at FHEM/TimeSeries.pm line 256.
2023.11.19 13:00:10 1: PERL WARNING: Argument "xxxx80.6 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 13:00:10 1: PERL WARNING: Argument "xxxx97.4 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 13:00:10 1: PERL WARNING: Argument "xxxx80.6 Wh" isn't numeric in numeric gt (>) at FHEM/TimeSeries.pm line 362.
2023.11.19 13:01:10 1: PERL WARNING: Argument "xxxx10.3 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 13:01:10 1: PERL WARNING: Argument "xxxx10.3 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 13:02:10 1: PERL WARNING: Argument "xxxx23.2 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 13:02:10 1: PERL WARNING: Argument "xxxx23.2 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
2023.11.19 13:03:10 1: PERL WARNING: Argument "xxxx36.1 Wh" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 254.
2023.11.19 13:03:10 1: PERL WARNING: Argument "xxxx36.1 Wh" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 361.
Es liegt wohl daran, dass die Werte nicht (mehr) numerisch sind, weil ich attr MyObis1 unitReadings on gesetzt habe, also die Einheiten bei den Readings angehängt werden, wodurch aus einem numerischen Wert ein String wird.
Was kann ich tun, um die Einheiten anzuhängen (unitReadings on), aber nachher beim event-aggregator keine Warnungen zu bekommen? Wie baue ich das attr MyObis1 event-aggregator power:120:linear:mean,total_consumption:300:none:v um? Leider fehlen mir dafür die nötigen PERL Kenntnisse.
Übrigens verstehe ich nicht, woher bei den PERL Warnungen das "n.a." (not applicable - nicht zutreffend) herkommt. Die Readings enthalten doch immer irgendwelche Werte: power und total_consumption sind ja nie "leer", und sie heißen auch so in den Readings.
Danke für Eure Hilfe! :)
Zitat von: sunrise am 19 November 2023, 12:37:22Mir ist soweit klar, dass die Codes offenbar unbekannt sind, aber ich frage mich, ob das ein Problem bei meinem Setup bedeutet oder ich das schlicht ignorieren kann.
Am Setup liegt es eher nicht. Ignoriere es einfach.
An sich würde ich allerdings mit Verbose 4 o. 5 erwarten, dass dazu etwas zu finden ist. Mithin es schon so vom Zähler kommt.
Hak es ab.
Gruß
Zitat von: sunrise am 19 November 2023, 13:14:20Es liegt wohl daran, dass die Werte nicht (mehr) numerisch sind, weil ich attr MyObis1 unitReadings on gesetzt habe, also die Einheiten bei den Readings angehängt werden, wodurch aus einem numerischen Wert ein String wird.
Was kann ich tun, um die Einheiten anzuhängen (unitReadings on), aber nachher beim event-aggregator keine Warnungen zu bekommen? Wie baue ich das attr MyObis1 event-aggregator power:120:linear:mean,total_consumption:300:none:v um? Leider fehlen mir dafür die nötigen PERL Kenntnisse.
Das Attribut gehört ja nicht zum Modul. Ggfs. bemühe mal die Suche um an anderen Stellen was dazu zu finden.
Abhilfe (vermutlich gibt es elegantere Wege) ginge mit einem Userreading ohne Einheit.
Danke, ich lasse die Einheiten erst einmal weg, denn in den Plots kann ich sie ja trotzdem dranschreiben. Und falls ich das mal via MQTT generic bridge an Home Assistant durchreichen möchte, geht das ohne Einheiten eh besser, nehme ich an.
PS:
Zitat von: RalfRog am 19 November 2023, 16:33:02Das Attribut gehört ja nicht zum Modul. Ggfs. bemühe mal die Suche um an anderen Stellen was dazu zu finden.
Ich dachte, dass das Attribut
unitReadings zu OBIS (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/47_OBIS.pm#L115) gehört.
Zitat von: RalfRog am 19 November 2023, 16:28:37An sich würde ich allerdings mit Verbose 4 o. 5 erwarten, dass dazu etwas zu finden ist. Mithin es schon so
Voilà:
2023.11.19 16:48:53 4: OBIS (MyObis1) - MSG IS:
/
1-0:96.50.1*1(LGZ)
1-0:96.1.0*255(LGZ)
1-0:1.8.0*255(>xxxx99.6*Wh)
1-0:2.8.0*255(xx9.1*Wh)
1-0:16.7.0*255(xx5*W)
255-255:255.255.255*255()
!
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: /
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 1-0:96.50.1*1(LGZ)
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 1-0:96.1.0*255(LGZ)
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 1-0:1.8.0*255(>xxxx99.6*Wh)
2023.11.19 16:48:53 4: OBIS (MyObis1) - Storing Counter for 1-0:1.8.0*255 in Cache
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg 1-0:1.8.0*255(>xxxx99.6*Wh) is of type Counter
2023.11.19 16:48:53 4: OBIS (MyObis1) - Set total_consumption to xxxx99.6
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 1-0:2.8.0*255(xx9.1*Wh)
2023.11.19 16:48:53 4: OBIS (MyObis1) - Storing Counter for 1-0:2.8.0*255 in Cache
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg 1-0:2.8.0*255(xx9.1*Wh) is of type Counter
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 1-0:16.7.0*255(xx5*W)
2023.11.19 16:48:53 4: OBIS (MyObis1) - Storing Channels for 1-0:16.7.0*255 in Cache
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg 1-0:16.7.0*255(xx5*W) is of type Channels
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: 255-255:255.255.255*255()
2023.11.19 16:48:53 3: OBIS (MyObis1) - Unknown Message: 255-255:255.255.255*255()
2023.11.19 16:48:53 5: OBIS (MyObis1) - Msg-Parse: !
2023.11.19 16:49:14 3: OBIS (MyObis2) - Unknown Message: 255-255:255.255.255*255()[/pre]
Schlauer werde ich daraus (verbose 5) allerdings nicht. ;)
Zitat von: sunrise am 19 November 2023, 16:44:03Ich dachte, dass das Attribut unitReadings zu OBIS (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/47_OBIS.pm#L115) gehört.
Ja, aber Du hattest doch Probleme mit dem "event-aggregator".
Zitat von: sunrise am 19 November 2023, 13:14:20aber nachher beim event-aggregator keine Warnungen zu bekommen?
Achso, das meintest Du! ;)
Ich hab hier (https://forum.fhem.de/index.php?topic=135888.0) mal ein neues Thema aufgemacht, da aus meiner Sicht zu erwarten ist, dass zumindest die PV-Anlagen > 7 kWp dann doch "demnächst" mit einem iMsys ausgestattet werden und die Infrarotschnittstelle "überflüssig" bzw. "unmodern" werden könnte und der Zugriff per LAN erfolgen könnte/müsste.
Grüße
Markus
Hallo zusammen,
Ich habe nochmal eine Anmerkung und Frage bzgl.
total_feed (Einspeisung):
Zitat von: sunrise am 12 November 2023, 11:13:18Hast Du eine Idee, wieso ich ein total_feed Reading habe, obwohl ich gar nichts einspeise? Ich habe keine PV-Anlage o.a. Einspeisequellen und wundere mich daher generell, dass dieses Reading erscheint, aber auch über den Wert selbst (xx9.1 Wh). Immerhin ändert er sich nicht, aber m.E. sollte er Null sein oder das Reading gar nicht erst angezeigt werden, oder irre ich mich?
Ob angezeigt oder nicht - woher die xx9.1 Wh "Einspeisung" (total_feed) herkommen sollen, frage ich mich schon. 🤔
Wenn ich den Zähler im Schrank beobachte, steht dort unter 2.8.0 immer 0000000 kWh, was auch korrekt ist, da ich nichts einspeise.
Allerdings erhalte ich über das Obis-Modul in FHEM stets einen unveränderten 3-stelligen Wert (zzgl. Nachkommastelle) als
total_feed. Woher kommt das?
Vielleicht stammt der Wert von der Überprüfung im Werk / Energieversorger.
Dass auf dem Zähler 0 kWh angezeigt wird liegt eventuell an der Einheit.
Du hast 0,0091 kWh.
Gruß Ralf
Oja, klar! Danke! 👍
Hallo,
beim meinem Zweirichtungszähler (Apator Picus) habe ich ,,Inf" ,,On" gesetzt und lese mit Obis folgende Werte aus:
-Herstellerkennung
-Gerätekennung
-Entnommene Energie 1,8,0 (A+)
-Abgegebene Energie 2.8.0 (A-) - nur für Zähler A+/A-
-dreiphasige Momentanleistung
Laut Bedienungsanleitung gibt es weitere Werte (z.B. PhasenSpannung, -Strom, -Leistung) ,,je nachdem, ob das Datenregister des Herstellers aktiviert ist (EIN/AUS - über LMN-Port)"
Wie kann man das aktivieren oder geht das nur werksseitig?
Danke für Infos
Hat vielleicht jemand den Apator Picus im Einsatz?
Welche Werte werden ausgelesen?
Weitere Frage:
Bei Stromausfall werden alle Einstellungen im Apator Picus zurück gesetzt und man muss den Optokoppler abnehmen und mit Lampe ,,Inf" wieder ,,on" setzten.
Etwas lästig.
Es gibt doch sicher die Möglichkeit mit Hilfe der LED im Optokoppler Einstellungen vorzunehmen.
Hat jemand dazu Infos?
Hallo zusammen!
Habt Ihr einen Tipp, wie man am einfachsten Tageswerte des Stromverbrauchs auswertet und darstellt? Ich hörte vom statistics (https://fhem.de/commandref_DE.html#statistics) Hilfs-Modul, was aber höhere Leistungsanforderungen zu haben scheint als es mein Raspberry Pi 2 hergibt.
Wichtig ist mir, dass ich die Werte retrospektiv, wenigstens ab 01.01.2024, darstellen kann, d.h. der Weg müsste über eine Auswertung des/der Logiles gehen. Meine Daten werden monatlich in einem Logfile abgelegt:
MyObis2-2023-11.log
MyObis2-2023-12.log
MyObis2-2024-01.log
etc.
Ich benötige ja nur den täglichen Wert von total_consumption um 00:00 Uhr, weiß aber nicht so richtig, ob/wie das ohne das o.g. zusätzliche Modul funktioniert.
Herzlichen Dank für Eure Hilfe! 👍
PS:
Mit dem ElectricityCalculator (https://fhem.de/commandref_DE.html#ElectricityCalculator) Hilfs-Modul (siehe auch Wiki (https://wiki.fhem.de/wiki/ElectricityCalculator)) bekomme ich Readings, allerdings nur ab heute. Ich werde mich damit noch eingehender beschäftigen müssen und hoffe, dass auch rückwirkend etwas möglich ist.
EDIT: Das Modul ist für mich nicht brauchbar - daher teste ich dann doch das statistics-Modul.
statistics ist natürlich das richtige Mittel für Statistikdaten. Sollte auch auf einem RPi2 noch performant sein. Es sei denn Dein System ist schon relativ groß, aber dann ist ein 2B sowieso nicht mehr ausreichend.
Schau Dir alternativ das Attribut userreadings an. Damit kannst Du das Gewünschte machen. Oder mit einem at mit setreading und eigens definierten readings. Ich speichere z.B. mitdefine Daily at *00:00:15 {fhem("setreading zaehler Lasttotal_feed ".ReadingsVal("zaehler","total_feed",0).";;setreading zaehler Lasttotal_consumption ".ReadingsVal("zaehler","total_consumption",0).";;setreading PVzaehler Lasttotal_feed ".ReadingsVal("PVzaehler","total_feed",0).";;setreading PVzaehler Lasttotal_consumption ".ReadingsVal("PVzaehler","total_consumption",0).")}
die 4 Zählerstande zwischen, NACHDEM ich die Differenz verarbeitet habe. (Viele Wege führen nach Rom).
Historisch würde ich manuell vorgehen: Logfiles in Excel entsprechend aufbereiten/sortieren/ergänzen, die Tageswerte dazu mit einer simplen Formel ermitteln und schließlich als "event" zurück in die/das Logfile kopieren.
Grüße Markus
Weißt Du, ob die Hilfs-Module ElectricityCalculator und Statistics "einfach" auch historische Werte in Logfiles verarbeiten können? Der ElectricityCalculator scheint mich ja schon ein Stück weiterzubringen, aber ich bin mir anhand Doku & Wiki noch nicht sicher, ob mein Vorhaben damit auch ohne Excel und manuelle Einfügungen ins Logfile möglich sein wird.
EDIT: Das Modul ist für mich nicht brauchbar - daher teste ich dann doch das statistics-Modul.
Ein Logfile(vergangene Events) kannst Du manipulieren, um Grafiken zu "korrigieren". Auf "Hilfsmodule" haben nur aktuelle Events einen Einfluß.
Deine Fragen haben recht wenig mit OBIS zu tun. Mach doch einen eigenen Thread unter Anfängerfragen auf. Ich denke, dann antworten auch mehr.
Grüße Markus
Danke - habe ich inzwischen getan. 😊
Falls sonst noch jemand über meine Frage hier stolpert und am weiteren Verlauf interessiert ist: https://forum.fhem.de/index.php?msg=1301231
Sorry, nun wieder zurück zum eigentlich Thema - Obis ...
Ich habe vor zwei Tagen einen DZG DWS7412.2V.G2 eingebaut bekommen.
Wir betreiben eine Mini-PV und ich hatte bisher die Einspeisung am Zähler (Mit Rücklaufsperre) mittels IR Lesekopf direkt am Raspi für die Schaltung der Überschussladung verwendet wenn ein negativer Wert größer X ausgegeben wurde.
Das funktioniert nun nicht mehr, da kein Negativwert mehr gelesen wird. Wo sehe ich hier wenn die Einspeisung stattfindet? (Nicht am Display)
Pin am Zähler ist bereits deaktiviert.
define Zaehler_HS OBIS /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE266-if00-port0@9600,8,N,1 SML
attr Zaehler_HS DbLogExclude .*
attr Zaehler_HS DbLogInclude power_clear:60
attr Zaehler_HS alias Smartmeter Hausstrom (Nr.:1)
attr Zaehler_HS event-on-change-reading power,power_clear,statTotal_consumption
attr Zaehler_HS icon measure_power_meter
attr Zaehler_HS interval 5
attr Zaehler_HS nohacks 1
attr Zaehler_HS pollingMode on
attr Zaehler_HS room EG,HWR
attr Zaehler_HS stateFormat statTotal_costsMerged
attr Zaehler_HS unitReadings on
attr Zaehler_HS userReadings power_clear {\
my @val = split(/ /,ReadingsVal($NAME, "power", 0) );;;; \
sprintf(\
"%s",\
$val[0])\
}\
,\
total_consumption_clear_Wh\
{\
my @val = split(/ /,ReadingsVal($NAME, "total_consumption", 0) );;;; \
sprintf(\
"%s",\
$val[0])\
}\
,\
statTotal_costs { \
my @val = split(/ /,ReadingsVal($NAME, "statTotal_consumption", 0) );;;; \
sprintf(\
"%s %.2f € %s %.2f € %s %.2f € %s %.2f € (26,28 Ct a kWh)",\
$val[0],\
$val[1]/1000*0.2628,\
$val[2],\
$val[3]/1000*0.2628,\
$val[4],\
$val[5]/1000*0.2628,\
$val[6],\
$val[7]/1000*0.2628\
)\
}\
,\
statTotal_costsLast { \
my @val = split(/ /,ReadingsVal($NAME, "statTotal_consumptionLast", 0) );;;; \
sprintf(\
"%s %.2f € %s %.2f € %s %.2f € %s %.2f € (26,28 Ct a kWh)",\
$val[0],\
$val[1]/1000*0.2628,\
$val[2],\
$val[3]/1000*0.2628,\
$val[4],\
$val[5]/1000*0.2628,\
$val[6],\
$val[7]/1000*0.2628\
)\
}\
,\
statTotal_costsMerged {\
sprintf(\
"%.2f kWh - %.2f € (26,28 Ct a kWh)",\
ReadingsNum($NAME, "total_consumption",0)/1000,\
ReadingsNum($NAME,"total_consumption",0)/1000*0.2628\
)\
}
# CRC_Errors 109
# DEF /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE266-if00-port0@9600,8,N,1 SML
# DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_015AE266-if00-port0@9600,8,N,1
# FD 11
# FUUID 5c61c090-f33f-de9d-41b7-d9608e9cba0e3e71
# MeterType SML
# NAME Zaehler_HS
# NR 52
# PARTIAL
# STATE 10.41 kWh - 2.74 € (26,28 Ct a kWh)
# TYPE OBIS
# eventCount 719
# Helper:
# DBLOG:
# power_clear:
# DBLogging:
# TIME 1707512699.55673
# VALUE 97.6
# READINGS:
# 2018-07-25 17:20:38 0.118.7.0.10.255 0
# 2018-09-23 13:32:16 0.118.7.0.11.255 0*var
# 2020-01-19 22:19:05 0.118.7.0.12.255 0*var
# 2021-02-22 16:49:51 0.118.7.0.13.255 0*var
# 2021-03-21 23:59:55 1.0.0.0.9.255 06-45-4D-48-01-0E-15-BE-87-A4
# 2024-02-09 22:04:59 1.0.96.1.0.255 DZG*var
# 2021-03-21 23:59:55 129.129.199.130.3.255 EMH
# 2024-02-07 08:42:57 ManufID EMH
# 2024-02-09 22:04:59 ManufID2 DZG*var
# 2024-02-07 08:42:57 Serial 06-45-4D-48-01-0E-15-BE-87-A4
# 2021-03-31 06:49:54 Version
# 2024-02-09 22:04:59 power 97.6 W
# 2024-02-09 22:04:59 power_clear 97.6
# 2024-02-09 22:04:59 statPowerDay Min: 6.38 Avg: 241.07 Max: 1091.64
# 2024-02-08 23:59:55 statPowerDayLast Min: 0.01 Avg: 199.29 Max: 3039.86
# 2024-02-09 22:04:59 statPowerMonth Min: -511.50 Avg: 166.99 Max: 5240.90
# 2024-01-31 23:59:55 statPowerMonthLast Min: -530.4 Avg: 168.7 Max: 7271.4
# 2024-02-09 22:04:59 statPowerYear Min: -530.40 Avg: 168.35 Max: 7271.40
# 2023-12-31 23:59:55 statPowerYearLast Min: -1352.3 Avg: 49.4 Max: 11399.2
# 2024-02-09 22:04:59 statTotal_consumption Hour: 8.4 Day: 3411.1 Month: -8576259.4 Year: -8444931.1
# 2024-02-09 21:59:55 statTotal_consumptionLast Hour: 678.3 Day: 4305.9 Month: 131328.3 Year: 1157853.8
# 2024-02-09 22:04:59 statTotal_costs Hour: 0.00 € Day: 0.90 € Month: -2253.84 € Year: -2219.33 € (26,28 Ct a kWh)
# 2024-02-09 22:04:59 statTotal_costsLast Hour: 0.18 € Day: 1.13 € Month: 34.51 € Year: 304.28 € (26,28 Ct a kWh)
# 2024-02-09 22:04:59 statTotal_costsMerged 10.41 kWh - 2.74 € (26,28 Ct a kWh)
# 2024-02-09 21:50:27 state opened
# 2024-02-09 22:04:59 total_consumption 10408.2 Wh
# 2024-02-07 08:42:57 total_consumption_Ch1 0 Wh
# 2024-02-07 08:42:57 total_consumption_Ch2 8612085.2 Wh
# 2024-02-09 22:04:59 total_consumption_clear_Wh 10408.2
# 2024-02-09 22:04:59 total_feed 306.7 Wh
# helper:
# BUFFER
# DIRECTIONSUM >
# DZGHACK
# EoM 1
# LastPacketTime 1707512699.57481
# NOHACKS 1
# SPEED 5
# SPEED2 5
# TRIGGERTIME 1707511827.00141
# _98_statistics StatStrom_HS
# Channels:
# DEVICES:
#
# 5
#
# RULECACHE:
# 1-0:1.8.0*255 Counter
# 1-0:16.7.0*255 Channels
# 1-0:2.8.0*255 Counter
# 1-0:96.1.0*255 unknown
# 1-0:96.50.1*1 ManufID2
# directions:
#
setstate Zaehler_HS 10.41 kWh - 2.74 € (26,28 Ct a kWh)
setstate Zaehler_HS 2018-07-25 17:20:38 0.118.7.0.10.255 0
setstate Zaehler_HS 2018-09-23 13:32:16 0.118.7.0.11.255 0*var
setstate Zaehler_HS 2020-01-19 22:19:05 0.118.7.0.12.255 0*var
setstate Zaehler_HS 2021-02-22 16:49:51 0.118.7.0.13.255 0*var
setstate Zaehler_HS 2021-03-21 23:59:55 1.0.0.0.9.255 06-45-4D-48-01-0E-15-BE-87-A4
setstate Zaehler_HS 2024-02-09 22:04:59 1.0.96.1.0.255 DZG*var
setstate Zaehler_HS 2021-03-21 23:59:55 129.129.199.130.3.255 EMH
setstate Zaehler_HS 2024-02-07 08:42:57 ManufID EMH
setstate Zaehler_HS 2024-02-09 22:04:59 ManufID2 DZG*var
setstate Zaehler_HS 2024-02-07 08:42:57 Serial 06-45-4D-48-01-0E-15-BE-87-A4
setstate Zaehler_HS 2021-03-31 06:49:54 Version
setstate Zaehler_HS 2024-02-09 22:04:59 power 97.6 W
setstate Zaehler_HS 2024-02-09 22:04:59 power_clear 97.6
setstate Zaehler_HS 2024-02-09 22:04:59 statPowerDay Min: 6.38 Avg: 241.07 Max: 1091.64
setstate Zaehler_HS 2024-02-08 23:59:55 statPowerDayLast Min: 0.01 Avg: 199.29 Max: 3039.86
setstate Zaehler_HS 2024-02-09 22:04:59 statPowerMonth Min: -511.50 Avg: 166.99 Max: 5240.90
setstate Zaehler_HS 2024-01-31 23:59:55 statPowerMonthLast Min: -530.4 Avg: 168.7 Max: 7271.4
setstate Zaehler_HS 2024-02-09 22:04:59 statPowerYear Min: -530.40 Avg: 168.35 Max: 7271.40
setstate Zaehler_HS 2023-12-31 23:59:55 statPowerYearLast Min: -1352.3 Avg: 49.4 Max: 11399.2
setstate Zaehler_HS 2024-02-09 22:04:59 statTotal_consumption Hour: 8.4 Day: 3411.1 Month: -8576259.4 Year: -8444931.1
setstate Zaehler_HS 2024-02-09 21:59:55 statTotal_consumptionLast Hour: 678.3 Day: 4305.9 Month: 131328.3 Year: 1157853.8
setstate Zaehler_HS 2024-02-09 22:04:59 statTotal_costs Hour: 0.00 € Day: 0.90 € Month: -2253.84 € Year: -2219.33 € (26,28 Ct a kWh)
setstate Zaehler_HS 2024-02-09 22:04:59 statTotal_costsLast Hour: 0.18 € Day: 1.13 € Month: 34.51 € Year: 304.28 € (26,28 Ct a kWh)
setstate Zaehler_HS 2024-02-09 22:04:59 statTotal_costsMerged 10.41 kWh - 2.74 € (26,28 Ct a kWh)
setstate Zaehler_HS 2024-02-09 21:50:27 state opened
setstate Zaehler_HS 2024-02-09 22:04:59 total_consumption 10408.2 Wh
setstate Zaehler_HS 2024-02-07 08:42:57 total_consumption_Ch1 0 Wh
setstate Zaehler_HS 2024-02-07 08:42:57 total_consumption_Ch2 8612085.2 Wh
setstate Zaehler_HS 2024-02-09 22:04:59 total_consumption_clear_Wh 10408.2
setstate Zaehler_HS 2024-02-09 22:04:59 total_feed 306.7 Wh
Vorschlag: Mal die readings von den Altlasten bereinigen. Dann erkennen wir auch einfacher, was der neue Zähler liefert.
Wenn Du Dir unsicher bist, wie Du das machst, dann am einfachsten/sichersten in der Details-View in die raw-Anzeige. Alle Zeilen, die nicht zu löschende readings enthalten entfernen und dann z.B. die Zeilensetstate Zaehler_HS 2018-09-23 13:32:16 0.118.7.0.11.255 0*varüberschreiben mitdeletereading Zaehler_HS 0.118.7.0.11.255.*
Danke, hätte auch selbst drauf kommen können den Zähler einfach neu zu erstellen. Jetzt stimmen die Werte auch nachdem ich nohacks auf 1 gesetzt habe. :)
Hihi zusammen,
ich habe das OBIS Modul nun seit über zwei Jahren am laufen und es funktionierte bis jetzt ohne Probleme mit ESPeasy Selbstbau Modul und Selbstbau- Lesekopf.
Nun ist mir leider ein Fehler unterlaufen und die SD Karte im fhem Raspberry Pi ist vollgelaufen. Mit Putty konnte ich das durch löschen der größten logs lösen und die Ursache beheben. Nun habe ich das Problem dass ich die Readings alle wieder bekomme aber es fehlt natürlich die Differenz im Monat und im Jahr.
Mit setreading kann man hier wohl nicht die Historie- Werte eingeben.
Gibt es eine Möglichkeit die Differenzwerte irgendwie sonst einzugeben oder in einer Datei zu ändern?
Gruß
Franzel
Womit erstellst Du denn
Zitatdie Differenz im Monat und im Jahr.
ZitatMit setreading kann man hier wohl nicht die Historie- Werte eingeben.
Sollte eigentlich funktionieren. :-\
Ich hatte schonmal fehlende Werte direkt ins Obis Logfile des betroffenen Monats geschrieben (via WinSCP und Notepad++), und das hat funktioniert. Wenn ich es richtig erinnere, ist das vermutlich nicht die empfohlene Methode, und ich weiß auch nicht mehr, ob ich FHEM dazu temporär angehalten hatte. Aber die Plots sahen danach nahtlos aus, und ich konnte auch sonst keine Nebenwirkungen beobachten.
Hallo Leute,
die AES-Verschlüsselung wurde hier schon 2 mal angesprochen und ich möchte dieses Thema nochmals aufwärmen.
Es handelt sich um den Siemens AMIS Multifunktionszähler TD3511.
Ich möchte die Smartmeter-Werte über einen IR-Lesekopf für Stromzähler von z.B. Weidmann Elektronik welchen ich per USB an den Raspi 3b stecke auslesen.
Die Ausgabe der Schnittstelle ist mit einem AES Code verschlüsselt.
Diesen Code/Key bekommt man vom Netzbetreiber und ist somit verfügbar.
Leider ist es im Moment so, dass man entweder über die Volkszaehler Schnittstelle gehen muss, oder einen AMIS-Leser (z.B. https://www.mitterbaur.at/amis-leser.html) welcher über WiFi und MQTT arbeitet kaufen muss, um die Zählerdaten in FHEM zu bekommen.
Das OBIS-Modul bietet die perfekte Anbindung an FHEM, wenn da nicht diese blöde AES-Verschlüsselung wäre.
Wäre es möglich die AES-Entschlüsselung ins OBIS-Modul zu implementieren?
Hier sind Links, wo diese AES-Entschlüsselung über Python bzw. Javascript gelöst wurde (leider habe ich diesbezüglich überhaupt keine Ahnung).
- https://github.com/sadello/strompy
- https://github.com/Ranzig93/TD3511-IoBroker-Javascript
Danke für die Unterstützung, Robert
Hallo Robert!
Reicht es nicht, dass Du die PIN einmal am Zähler eingibst und auch am Zähler einstellst, dass die PIN dann nicht mehr abgefragt wird? So war's bei meinem Landis & Gyr Zähler. Oder habe ich Dich missverstanden? Ich verstehe nämlich nicht, weshalb ein digitaler Zähler trotz PIN-Eingabe die Daten immer noch verschlüsselt über die IR-Schnittstelle ausgibt.
Hallo sunrise,
soweit ich das verstanden haben, gibt es bei diesen Zählern keine PIN Eingabe.
Die AES-Verschlüsselung gibt der Netzbetreiber (Netz OÖ) vor - ihm gehört auch der Zähler.
Zum Entschlüsseln benötigt man einen Key, welchen man vom Netzbetreiber bekommt.
Ich erhielt eine 4-stellige PIN, die ich mittels Taschenlampe an der IR-Schnittstelle eingeben konnte. Ebenso konnte ich danach einstellen, dass keine weitere PIN-Abfrage mehr benötigt wird, wenn ich alle Daten an der Schnittstelle auslesen möchte. Sorry, dass ich Dir nicht weiter helfen kann.
Hallo Stefan,
ich habe das OBIS Modul eingesetzt aber es werden nicht alle und auch andere ID's ausgewertet als vom SmartMeter gesendet werden.
Via vzlogger bekomme ich folgende 17 Werte:
[Mar 01 12:28:23][mtr0] Got 17 new readings from meter:
ObisIdentifier:1-0:1.8.1*255 value=5350408.30
ObisIdentifier:1-0:1.8.2*255 value=8596418.00
ObisIdentifier:1-0:2.8.0*255 value=26132240.00
ObisIdentifier:1-0:16.7.0*255 value=22.00
ObisIdentifier:1-0:32.7.0*255 value=236.40
ObisIdentifier:1-0:52.7.0*255 value=235.50
ObisIdentifier:1-0:72.7.0*255 value=235.60
ObisIdentifier:1-0:31.7.0*255 value=4.04
ObisIdentifier:1-0:51.7.0*255 value=4.64
ObisIdentifier:1-0:71.7.0*255 value=3.77
ObisIdentifier:1-0:81.7.1*255 value=120.00
ObisIdentifier:1-0:81.7.2*255 value=241.00
ObisIdentifier:1-0:81.7.4*255 value=73.00
ObisIdentifier:1-0:81.7.15*255 value=99.00
ObisIdentifier:1-0:81.7.26*255 value=94.00
ObisIdentifier:1-0:14.7.0*255 value=49.90
ObisIdentifier:1-0:96.5.0*255 value=18598440.00
in Fhem bekomme ich aber:
Readings
1.0.0.2.0.0 1.02.007
1.0.14.7.0.255 49.9
1.0.81.7.1.255 119
1.0.81.7.15.255 126
1.0.81.7.2.255 239
1.0.81.7.26.255 90
1.0.81.7.4.255 306
1.0.96.1.0.255 HLY
1.0.96.5.0.255 1843460
1.0.96.90.2.1 A01A
ManufID2 HLY
current_L1 1.09
current_L2 0.76
current_L3 0.79
power 46
state opened
total_consumption_Ch1 5350429.2
total_consumption_Ch2 8596418
total_feed 26132252
voltage_L1 236.9
voltage_L2 235.6
voltage_L3 234.5
Die Werte sind zeitlich versetzt, da ich den vzlogger gestoppt habe während dein OBIS Modul läuft.
Bitte wie kann die ObisIdentifier 1.8.1, 1.8.2 und 2.8.1 mit Deinem Modul auslesen?
Viele Grüße
wollik
Stefan sorry,
ich sehe gerade das die
1.8.1 auf total_consumption_Ch1
1.8.2 auf total_consulption_Ch2
und
2.8.0 auf total_feed angezeigt wird
Bitte kannst Du eine Liste schicken, in der du das Mapping von OBIS ID's auf fhem readings beschreibst?
Viele Grüße
wollik
Hallo Stefen,
sorry again;(
ich hab das Mapping im Modul gefuden.
Ich wurdere mich nur, dass Dein Modul weitere OBIS ID's findet als der vzlogger, bitte hast du davon schon gehört oder eine Erklärung dafür?
Viele Grüße
wollik
Hallo
Vielleicht stellt der vzlogger nicht alle OBIS Codes des gesendeten SML Protokolls dar (ggfs. konfigurierbar).
Der Hersteller HLY (Holley) fehlt z.B.
In der Anleitung beispielsweise zum DTZ541 sind 21 Werte genannt (leider ohne die Kennziffern).
Gruß Ralf
Zitat von: bertl am 12 März 2024, 11:59:02Hallo Interessierte,
nachdem ich lange gesucht und nichts passendes gefunden habe, hier meine Lösung für die Integration des Siemens AMIS-Multifunktionszähler TD3511 welcher vom Energieversorgungsunternehmen (EVU) Netz Oberösterreich (Netz-OÖ) verbaut ist.
Leider funktioniert das OBIS-Modul für diesen von der Netz-OÖ speziell konfigurierten Zähler nicht und im passenden OBIS Forum (https://forum.fhem.de/index.php?msg=1304098) wurde/konnte mir leider nicht geholfen werden.
Neues Modul
98_TD3511_OOE.pm (https://forum.fhem.de/index.php?action=dlattach;attach=177010) für Siemens AMIS-Zähler vom EVU - Netz-OÖ.
Gruß, Robert
Hallo,
habe heute einen MT691-D4A52-K0y-H01 an die UART vom Zero W angeschlossen.
Screenshot 2024-04-12 161600.png
Die Power Werte stimmen recht gut mit einem EM24 (Netz -> rechte Seite) von meiner Victron Anlage überein.
Mich interssiert allerdings nur total_feed und total_consumtion.
Beim Starten des devices steht im log:
2024.04.12 15:43:28 3: OBIS (Stromzaehler_Solar) - Unknown Message: 1-0:96.1.0*255(ISK)
Ich nehme mal an, dass es sich auf das erste Reading bezieht.
Selbiges findet man bei anderen Zählern als: 1-0:96.1.0*255 Geräte-Identifikation
Evtl. kann das jemand nachpflegen?
Ich habe von meinem Zähler keine OBIS Beschreibung, aber evtl weiß jemand, ob diesem Zähler auch noch die Blindleistung zu entlocken wäre?
Dankeschön an dem Modulersteller. Sonst hätte ich mich mit dem mir vollkommen unbekannten Volkszähler quälen müssen.
Hallo
Schau dir mal das Attribut "channels" an (engl. Beschreibung). Damit kannst dem READING eine eigene Bezeichnung statt der OBIS- Kennziffer geben.
Wenn da keine weiteren Kennziffern geliefert werden kommt da vermutlich auch keine Blindleistung.
Mein MT691 macht nur Leistung und Energie (Zählerstand).
Gruß Ralf
Hallo zusammen,
ich habe ein Problem mit dem OBIS-Modul: Es funktioniert in den neueren Versionen offensichtlich nicht auf einer Fritzbox, weshalb ich aktuell immer noch die Uralt-Version vom 15.02.2019 benutzen muss (die allerdings recht instabil ist)! Die genaue Fehlermeldung bei der Verwendung des aktuellen Moduls ist
Invalid type 'q' in unpack at ./FHEM/47_OBIS.pm line 452
und führt zum Absturz vom FHEM.
Der Code im OBIS-Modul in Zeile 451 und 452 ist:
if ($len==8) {
$num = unpack($tltype = 0x50 ? 'q>' : 'Q>'
Es scheint in Perl auf der Fritzbox ein unpack mit 'q>' oder 'Q>' nicht möglich zu sein.
(Perl-Version: perl 5, version 26, subversion 1 (v5.26.1) built for mips-linux)
Falls es von Intersse ist, mein Hintergund:
Seit etwas mehr als einem Jahr verwende ich das OBIS-Modul mit dem Entwicklungs-Stand vom 15.02.2019 auf einer Fritzbox, um meinen Stromzähler vom Typ EasyMeter Q3A auszulesen und zu protokollieren. Mein Anwendungsfall für FHEM ist eben genau das Auslesen des Stromzählers sowie das Auslesen des PV-Wechselrichters. Die Fritzbox, die ich einsetze, ist eine "zusätzliche" Fritzbox (hinter dem DSL-Router), auf der ich Freetz-NG aufgespielt habe. Da diese Box im Keller ohnehin als Netzwerk-Hub im Einsatz ist, ist sie ideal geeignet, um meinen FHEM-Anwendungsfall abzudecken. Der Grund weshalb ich diesen Uralt-Stand von OBIS verwende, ist ganz einfach der, dass sämtliche Varianten seit dem Umbau von gvzdus auf der Fritzbox nicht lauffähig sind. Jedoch ist meine verwendete alte Variante recht instabil, sie hängt sich alle 7...20 Tage auf. Dabei hat dann der perl-Prozess den Staus "D" und kann auch nicht ge-killed werden. Es hilft nur ein Reboot der Fritzbox.
Da ich mittlerweile auf eine neuere Fritzbox umgezogen bin, auf der ich es auch geschafft habe, ein FHEM-Update durchzuführen, kann ich eigentlich ausschließen, dass der Fehler anderweitig zustande kommt.
Über eine Abhilfe würde ich mich riesig freuen!!!!
Viele Grüße
Gerhard