Adapter "smartmeter"

[wendy2702]

@ining sagte in Adapter "smartmeter":

DRT428M-2

Das wird mit dem Adapter hier nichts werden da der Zähler laut Beschreibung Modbus spricht.

RS485 Modbus RTU Datenschnittstelle

[joeflower]

Ich habe vielleicht ein Luxusproblem, aber es ärgert mich.
Ich habe einen eBZ DDR3 SMZ1 daran einen Eigenbau TTL-Impulsgeber von Volkszähler der über einen ESP8622 mit ESP Easy vom 20210223 wunderbar per Serial Server an den IOBroker sendet. Soweit so gut. Mache ich jedoch ein Update von ESP Easy geht nichts mehr. Immer nur die altbekannte Meldung "No or too long answer from Socket after last request."
Ich habe schon alle Einstellungen getestet (mit/ohne CRC). Hilft nichts. Zurück auf die "alte" Version und schon funktioniert wieder alles.
Die Version vom Feb 2021 ist die letzte welche ohne Probleme funktioniert.
Hat jemand was ähnliches oder weiß jemand woran das liegen könnte.

[brofelscher]

Hi zusammen,

ich bekomme leider den Adapter nicht vernünftig eingerichtet. Mein IR Leseschreibkopf ist über die serielle Schnittstelle des Raspberry Pi angeschlossen. Mein Zähler ist von der Firma Logarex. Der Lesekopf scheint auch grundsätzlich zu funktionieren, denn wenn ich per

screen /dev/ttyS0 9600

die Daten des Stromzählers anzeigen lasse, bekomme ich folgenden Output (die Zählernummer habe ich selber unkenntlich gemacht):

���Tj*��03039

1-0:96.1.0*255(001LOGxxxxxxxxxxx)
1-0:1.8.0*255(003265.5661*kWh)
1-0:2.8.0*255(000005.3283*kWh)
1-0:16.7.0*255(000352*W)
1-0:32.7.0*255(237.8*V)
1-0:52.7.0*255(237.3*V)
1-0:72.7.0*255(237.2*V)
1-0:31.7.0*255(000.14*A)
1-0:51.7.0*255(000.92*A)
1-0:71.7.0*255(000.86*A)
1-0:81.7.1*255(121*deg)
1-0:81.7.2*255(240*deg)
1-0:81.7.4*255(039*deg)
1-0:81.7.15*255(044*deg)
1-0:81.7.26*255(033*deg)
1-0:14.7.0*255(50.0*Hz)
1-0:1.8.0*96(00004.5*kWh)
1-0:1.8.0*97(00034.7*kWh)
1-0:1.8.0*98(00157.4*kWh)
1-0:1.8.0*99(01944.5*kWh)
1-0:1.8.0*100(03265.5*kWh)
1-0:0.2.0*255(ver.03,432F,20170504)
1-0:96.90.2*255(0F66)
1-0:97.97.0*255(00000000)
!

Mein Problem ist, dass der Adapter keine Datenpunkte anlegt und in der Instanz-Liste nur als "gelb" angezeigt wird.
Im Log finde ich nur folgendes:

smartmeter.0 2022-02-10 23:26:48.276	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:26:48.275	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:24:38.272	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:24:38.271	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:22:28.267	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:22:28.267	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:20:18.264	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:20:18.262	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:18:08.258	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:18:08.257	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:15:58.252	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-10 23:15:58.249	info	Error: No or too long answer from Serial Device after last request.

Als Protokoll habe ich in den Einstellungen "D0" ausgewählt, aber alles unverändert gelassen, da ich keine Ahnung habe was ich ändern sollte.

Vielleicht habt ihr einen Tipp für mich
Viele Grüße
Maik

[klassisch]

@brofelscher leider kenne ich den Zähler nicht und weiß nicht genau, was er sendet. Da könnte die Anleitung eine Hilfe sein. Diese sollte nach den Stichworten "Info Schnittstelle" und "SML" durchsucht werden.

Zuerst aber: Sobald ein Befehl wie

screen /dev/ttyS0 9600

abgesetz wurde, ist die serielle Schnittstelle dadurch blockiert und steht keinem anderen Prozeß mehr zur Verfügung, also auch nicht mehr dem smartmeter Adapter. Die muß also wieder freigegeben werden. Dazu würde ich (Linux Noob) den Raspi neu booten und diesen Befehl nicht mehr eingeben.

Dann würde ich im Adapter SML statt D0 auswählen. Das ist geschätzt. Kenne den Zähler nicht. Aber D0 ist -soweit ich weiß- ein bidirektionales Protokoll, bei dem man dem Zähler eine Aufforderung senden muß. Das macht aber der o.g. Befehl meines wissens nach nicht. Also gehe ich davon aus, daß der Zähler ohne Aufforderung sendet und das ist eher Info-Schnittstelle und damit SML.
Ungewöhlich ist, daß er unkomprimiertes Klartext ASCII sendet. Das macht mein itron Zähler nicht. Aber soweit ich weiß, ist auch unkomprimiertes ASCII bei SML erlaubt.

Wenn es nach diesen Veruchen noch immer nicht geht: Den Adapter auf loglevel "debug" stellen, neu starten und die Startsequenz und die Fehlermeldungen hier posten. Dann können die Experten drauf schauen.

[brofelscher]

@klassisch Der Gedanke, das der Port durch den Screen-Befehl blockiert ist, war sehr gut. Ich habe den Pi neu gestartet und direkt danach SML als Protokoll im Adapter festgelegt. Daraufhin wurden auch ein Haufen Datenpunkte angelegt:

Dann war also vorher der Port durch meine Experimente blockiert. Soweit so gut. Doch nun die nächste Herausforderung: Die Werte vom Screenshot sind von heute Mittag. Seit dem wurden keine neuen Werte gesetzt und der Adapter schreibt munter das Log voll:

smartmeter.0 2022-02-11 19:32:31.091	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:32:31.090	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:25:31.086	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:25:31.086	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:18:31.082	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:18:31.081	info	Error: No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:11:31.077	warn	No or too long answer from Serial Device after last request.
smartmeter.0 2022-02-11 19:11:31.077	info	Error: No or too long answer from Serial Device after last request.

Auch nach einem weiteren Neustart passiert nichts mehr. Die Werte von heute Mittag bleiben bestehen.

Das Ergebnis des Degus habe ich mal angehängt. Ich glaube, dass einfach viel zu schnell Daten reinkommen und der damit nicht mehr klar kommt. Mein Log ist heute auf eine Größe von über 200 MB angewachsen Das ist neuer Rekord. Hier mal ein Auszug als txt Datei: Smartmeter Log.txt

Viele Grüße
Maik

[klassisch]

@brofelscher Ist der Lesekopf richtig positioniert?
Am einfachsten kannst Du auch das durch einen Neustart des Raspi testen. Wenn dann wieder Daten reinkommen - ohne daß Du am Lesekopf was gemacht hast - Dann sitzt der wahrscheinlich richtig.
Zu Deiner These der überlasteten Seriellen Schnittstelle beim Raspi kann ich leider nichts sagen. Kenne mich mit dem Raspi nicht wirklich aus.
Wäre aber ein Armutszeugnis für den Raspi. Denn 9600 Bd ist heutzutage Schneckentempo und das wird auch noch durch den Vielleicht hats Du einen FTDI rumliegen und magst es mal über USB testen?

[klassisch]

@brofelscher sagte in Adapter "smartmeter":

Auch nach einem weiteren Neustart passiert nichts mehr. Die Werte von heute Mittag bleiben bestehen.

Ah, Dann sage ich: Lesekopf verschoben, Käbelchen gebrochen, Fremdlicht, Spannung nicht mehr versorgt / defekt (eher unwahrscheinlich)

[Idefix01]

Ich habe es auch geraume Zeit über ein Esp8266 und einem IR Lesekopf versucht. Allerdings war es noch mit einem alten Ferraris Zähler. Ich habe auch Werte erhalten aber spätestens nach 2 Tagen stimmten die Werte nicht mehr überein.
Jetzt habe ich eine komplett andere Lösung gefunden: Ich nutze den SDM630 Modbus V2 und lese diesen über den Modbus mit einem Modbus/Lan Gateway aus.
Funktioniert perfekt und meine Werte sind immer korrekt.

[klassisch]

@idefix01 sagte in Adapter "smartmeter":

SDM630 Modbus V2

Worauf bezieht sich Dein Beitrag?
Ferraris ist eine ganz andere Sache und der dort verwendete Sensor ist eine Reflex-Lichtschranke und kein IR Lesekopf.

[Idefix01]

@klassisch
Das stimmt schon. Hatte nur mal hier gelesen das auch viele Probleme haben mit einem IR Lesekopf das ganze zum laufen zu bringen und wollte nur mal meine Erfahrungen einbringen und aufzeigen wie ich es gelöst habe ohne IR Lesekopf.
Ist sicherlich etwas aufwendiger, wenn man kein Elektriker ist, aber funktioniert auf jeden Fall super.

[klassisch]

[Teil-OT]
@idefix01 Ja. vielen Dank! Ein zusätzliches ModBus Meßgerät ist sicher eine gute Lösung, die z.B. bei mir auch mehr Daten brächte, phasenselektiv z.B. Aber ich hätte den Platz incht mehr im Zählerschrank und den Einbau muß der Elektiker machen.

Die neuen Zähler mit Info-Schnitstelle sind aber mit diesem Adapter sehr gut zu integrieren.
Ich behaupte mal: 50% der Probleme hier und 80% der Probleme mit Zigbee Sticks liegen am Linux, VM, Containerund USB/serial tty mounten oder so. So auch oben: Serielle Schnittstelle bereits anderweitig blockiert.
Gerade bei Proxmox und VMs können die Systeme sehr viel - und oft mehr als die Benutzer. Ich bin da auch nicht besser, weiß das auch und deshalb bleibe ich bei Windows

Dann kommen Positionierungen Lesekopf + Kabelprobleme.

Und ein großer Batzen sind einfach alte bzw. inkompatible Zähler. Deren Varianten sind Legion. Mit der "modernen Meßeinrichtung" und deren IR SML Ausgang spielt dieser Adapter hervorragend zusammen.

Bei den Ferraris hat man meist optische Probleme und mangelnde Schwelleneinstellung. Würde man Geld für einen ordentlichen optischen Sensor in die Hand nehmen und etwas Zeit und Hirn in deren Befestigung und Einstellung investieren, käme man da auch besser hin. Aber eine einfache Reflexlichtschranke kann passen, muß aber nicht. Gleiches gilt für einen Digitaleingang eines ESP.

[Geko Eder]

Hallo zusammen, ich habe eine Frage, ich konnte keine Standard-settings für meinen Zähler Landis GYR E350 finden. Kann mir jemand sagen wie die Settings dafür aussehen müssen? Ich hab einen Weidmann IR Leser. Über die Standard App EMLog von Weidmann bekomme ich mit dem bidirektionalen Test mit baud 300 die Daten.
Es werden nacheinander die folgenden Zeilen gesendet (Test 4 mit Baud 300 7E1 bidirektional:

Sende:2F3F210D0A
Sende:063030300D0A

Es gibt auch keine Beschreibung der Kommunikation hier: https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/landisgyr_e350

Hab schon mehrere Settings ausprobiert, aber bekomme keine Daten und der Adapter bleibt gelb.
Eines meiner versucht Settings hier:

Hoffe ihr könnt mir einen Tipp geben,
Danke

[apollon77]

@geko-eder Das ist Standard D0 mit bidirektionaler Kommunikation. Entferne mal das was DU bei "Sign on" reingeschrieben hast ... und zeig mal log

[Geko Eder]

@apollon77 Danke das wars! - bekomme jetzt die meisten Werte, bis auf den aktuellen Verbrauchswert. Der fehlt aber auch über das Weidmann-Tool. Lässt sich das irgendwie konfigurieren oder überträgt Zähler den Wert einfach nicht? Tausend Dank schonmal - auch für die fixe Antwort

Hab "nur" die Werte hier:
Es fehlt der 16.7 - so heißt er zumindest wenn ich ihn im Zähler direkt anzeige.

[apollon77]

@geko-eder Ggf PIN beim Energieunternehmen erfragen und "einblinken" dann gibt vllt mehr Daten

[Geko Eder]

@apollon77 Hab ich befürchtet Danke dir

[Silversurfer 0]

@lobo
Nach langem hin und her habe ich es jetzt hinbekommen einen Ultraheat T550 (UH50) auszulesen.
Hier mal mein Weg, in der Hoffnung, daß es anderen hilft.

Ich verwende diesen Lesekopf als Bausatz (gibt es auch fertig montiert):
https://www.ebay.de/itm/184501414443
aber es scheint nicht zu sehr am IR Kopf zu liegen.

Wichtig scheint mir das "Aktivieren" mit der "Landis Ultra Assist" App aus dem Android play store.
Die App erkennt einen IR Lesekopf wenn er mittels eines OTG Adapters am Handy angeschlossen wird.
Zum Beispiel hier :
https://www.ebay.de/itm/124569931775

Außerdem scheint mir die Ausrichtung des Lesekopfes sehr entscheidend zu sein. Laßt euch nicht entmutigen und probiert ein wenig rum. Bei mir muß der USB Stecker vom Lesekopf nach unten zeigen. Wenn er nach oben zeigt hat es nicht funktioniert.

Erst danach konnte ich die Werte auch über den Smartmeter Adapter auslesen.
Jedes Auslesen der Werte verringert die Laufzeit der Batterie um ca. eine halbe Stunde. Deswegen lese ich die Werte nur einmal am Tag aus.
Hier meine Einstellungen:

[SmartHomer 0]

@klassisch
Hallo zusammen, ich wollte nicht versäumen, ein Feedback zurückzugeben:

Auch mit dem USR-W610 (Komplettmodul RS232 <-> Wifi) funktioniert die Smartmeter-Kopplung zwischenzeitlich, nachdem ich in den vielen möglichen Parameterseiten die richtigen Werte eingetragen habe.

Danke für die Unterstützung hier im Forum.

Leider hat nun schon nach kurzer Zeit die IR-Schnittstelle der mME Holley DTZ541-BDBA derart nachgelassen, dass keine Kommunikation über die INFO-Kundenschnittstelle mehr möglich ist (Einbau der mME war erst im Nov. 2021).
Auch ein Tausch des Lesekopfes gegen einen anderen Typ hat keine Verbesserung gebracht.
Die Leistung hat in kurzer Zeit immer mehr nachgelassen, einige Male konnte ich mit einer Korrektur der Lesekopf-Position noch was "rausholen" - nun geht gar nichts mehr und auch die Sende-LED ist mit der Cam nur noch zu erahnen. Zur Problematik "Nachlassende INFO-Schnittstelle bei Holley-mME" finden sich einige Beiträge.

Kontakt mit dem EVU läuft (Syna). Allerdings bin ich nicht sicher, ob die deshalb die mME austauschen bzw. ob ich darauf bestehen kann.
Ich konnte die Nutzung der INFO-Kundenschnittstelle nirgends als eine Art "zugesicherte Eigenschaft", auf die man als Kunde Anspruch hätte, finden.
Weiss jemand hier im Forum wie es sich damit verhält? Kann ich auf den Austausch bestehen?
Da müssten die EVU ja viele Holley-Zähler austauschen.

[Homoran]

@silversurfer-0 bitte den kompletten tracking-Mist aus dem Link löschen

[klassisch]

@silversurfer-0 vielen Dank für die RM udn die Anleitung für diesen spezifischen Zähler. Ja, nach den Problemen mit USB durchschleifen etc ist die korrekte und stabile Lesekopfpositionierung gefühlt auf Nr. 2 der Problemliste.