Adapter "smartmeter"

[SmartHomer 0]

@smarthomer-0
Leider bin ich trotz der super-engagierten und geduldigen Unterstützung von @klassisch und @apollon77 mit dem USR-W610 seit November überhaupt nicht weitergekommen (vorstehend Beiträge 2280ff).

Ich habe jetzt mein Setup wie folgt auf einen USR-TCP232-306 umgestellt, weil der auch im Super-Guide von @klassisch als "getestet" aufgeführt ist:

Erfassung:
mME SmartMeter Holley DTZ541-BDBA
(Info-Schnittstelle = aktiviert)
Lesekopf Hager EHZ 001K (TxD von RS232 angeschlossen an RxD vom neuen USR-TCP232-306)
RS485/RS422 nicht angeschlossen
Stromversorgung 5V DC für USR und EHZ 001K
LAN-Port direkt im Netzwerk
kein WLAN

ioBroker:
PlatformBetriebssystem:linux
Architektur:x64
CPUs:4
Geschwindigkeit:1501 MHz
Modell:Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
RAM:7.6 GB
System-Betriebszeit:2 T. 14:57:14
Node.js:v14.18.3
NPM:6.14.15
Datenträgergröße:251.9 GB
Festplatte frei:201.4 GB
Adapter-Anzahl:386
Betriebszeit:2 T. 14:53:43
Aktive Instanzen:19
Pfad:/opt/iobroker/
smartmeter-Adapter v3.2.1

ioBroker läuft auf einer Synology DS918+ in einem Docker mit dem buanet-Image

Der USR ist in meinem LAN, ich kann auf sein Web-Interface zugreifen.
Der Adapter greift auch zyklisch auf den USR zu, das sieht man sehr schön in der USR-Oberfläche :

Ping aus dem Docker-Terminal der Syno auf den USR ist ebenfalls möglich, ich denke, Netzwerk-Probleme können damit ausgeschlossen werden.

Log (Debug-Mode):

smartmeter.0
2022-02-01 15:02:45.516	debug	SET MESSAGE TIMEOUT TIMER: 120000

smartmeter.0
2022-02-01 15:02:45.515	debug	SOCKET RESUME

smartmeter.0
2022-02-01 15:02:40.514	debug	SCHEDULE NEXT RUN IN 5s

smartmeter.0
2022-02-01 15:02:40.512	debug	Transport Reset!! Restart = true

smartmeter.0
2022-02-01 15:02:40.511	debug	Error: No or too long answer from Socket after last request.

smartmeter.0
2022-02-01 15:02:40.511	warn	No or too long answer from Socket after last request.

smartmeter.0
2022-02-01 15:02:40.509	debug	Error: No or too long answer from Socket after last request.

smartmeter.0
2022-02-01 15:02:40.508	debug	MESSAGE TIMEOUT TRIGGERED

smartmeter.0
2022-02-01 15:00:40.597	debug	connected set to false

smartmeter.0
2022-02-01 15:00:40.597	debug	connected set to false

smartmeter.0
2022-02-01 15:00:40.507	debug	SET MESSAGE TIMEOUT TIMER: 120000

smartmeter.0
2022-02-01 15:00:40.507	debug	SOCKET RESUME

smartmeter.0
2022-02-01 15:00:40.504	debug	SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"TCPTransport","requestInterval":"5","anotherQueryDelay":"1000","transportTcpHost":"192.168.1.153","transportTcpPort":"4196","protocolSmlIgnoreInvalidCRC":true}

smartmeter.0
2022-02-01 15:00:40.507	debug	SET MESSAGE TIMEOUT TIMER: 120000

smartmeter.0
2022-02-01 15:00:40.507	debug	SOCKET RESUME

smartmeter.0
2022-02-01 15:00:40.504	debug	SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"TCPTransport","requestInterval":"5","anotherQueryDelay":"1000","transportTcpHost":"192.168.1.153","transportTcpPort":"4196","protocolSmlIgnoreInvalidCRC":true}

smartmeter.0
2022-02-01 15:00:40.474	info	starting. Version 3.2.1 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v14.18.3, js-controller: 3.3.22

smartmeter.0
2022-02-01 15:00:40.474	info	starting. Version 3.2.1 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v14.18.3, js-controller: 3.3.22

smartmeter.0
2022-02-01 15:00:40.241	debug	Plugin sentry Initialize Plugin (enabled=true)

smartmeter.0
2022-02-01 15:00:40.241	debug	Plugin sentry Initialize Plugin (enabled=true)

smartmeter.0
2022-02-01 15:00:39.977	debug	statesDB connected

smartmeter.0
2022-02-01 15:00:39.977	debug	statesDB connected

smartmeter.0
2022-02-01 15:00:39.976	debug	States connected to redis: 127.0.0.1:9000

smartmeter.0
2022-02-01 15:00:39.976	debug	States connected to redis: 127.0.0.1:9000

smartmeter.0
2022-02-01 15:00:39.926	debug	States create User PubSub Client

smartmeter.0
2022-02-01 15:00:39.926	debug	States create User PubSub Client

smartmeter.0
2022-02-01 15:00:39.924	debug	States create System PubSub Client

smartmeter.0
2022-02-01 15:00:39.924	debug	States create System PubSub Client

smartmeter.0
2022-02-01 15:00:39.913	debug	Redis States: Use Redis connection: 127.0.0.1:9000

smartmeter.0
2022-02-01 15:00:39.911	debug	objectDB connected

smartmeter.0
2022-02-01 15:00:39.913	debug	Redis States: Use Redis connection: 127.0.0.1:9000

smartmeter.0
2022-02-01 15:00:39.911	debug	objectDB connected

smartmeter.0
2022-02-01 15:00:39.903	debug	Objects connected to redis: 127.0.0.1:9001

smartmeter.0
2022-02-01 15:00:39.903	debug	Objects connected to redis: 127.0.0.1:9001

smartmeter.0
2022-02-01 15:00:39.888	debug	Objects client initialize lua scripts

smartmeter.0
2022-02-01 15:00:39.887	debug	Objects create User PubSub Client

smartmeter.0
2022-02-01 15:00:39.885	debug	Objects create System PubSub Client

smartmeter.0
2022-02-01 15:00:39.888	debug	Objects client initialize lua scripts

smartmeter.0
2022-02-01 15:00:39.887	debug	Objects create User PubSub Client

smartmeter.0
2022-02-01 15:00:39.885	debug	Objects create System PubSub Client

smartmeter.0
2022-02-01 15:00:39.883	debug	Objects client ready ... initialize now

smartmeter.0
2022-02-01 15:00:39.883	debug	Objects client ready ... initialize now

smartmeter.0
2022-02-01 15:00:39.852	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

smartmeter.0
2022-02-01 15:00:39.852	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

Leider kommt beim smartmeter-Adapter die Meldung "connected set to false" und der Adapter verbindet sich nicht:

In den Objekten werden keine Datenpunkte angelegt (der Lesekopf hängt derzeit noch nicht an der Holley-mME:

Hier noch meine Einstellungen des USR:

Edit:
Hier noch meine Einstellungen des smartmeter-Adapters:

Habt ihr noch Ideen oder Info, ob ihr bei Euch den USR-TCP232-306 anders eingestellt habt?

Ich wäre Euch verbunden, Danke im Voraus.

[klassisch]

@smarthomer-0 sagte in Adapter "smartmeter":

In den Objekten werden keine Datenpunkte angelegt (der Lesekopf hängt derzeit noch nicht an der Holley-mME:

Das muß er aber. Sonst sendet er keine Daten zum USR und der sendet nichts zum ioBroker, weil er nichts zum Senden hat. Und der ioBroker smartmeter Adapter wartet auf neue Daten. Die bekommt er aber nicht und läuft in einen Timeout. Und das schreibt er auch im Log, soweit ich es interpretiere

[SmartHomer 0]

@klassisch
Vielen Dank für Deine erneut schnelle Antwort. Dann wäre ich jetzt am Punkt, dass meine Holley IR-Schnittstelle evtl. zu schwach ist (s. November).

Im Log bzw. in den USR-Einstellungen fällt Dir nichts mehr auf? - das sollte jetzt netzwerk-seitig alles so passen, oder ?

Grüße

[klassisch]

@smarthomer-0 Beim Log, insbes. beim Aufstarten bin ich nicht der Experte. Was isch sehe ist der Timeout, der verständlich ist, wenn keine Signale kommen.

Ansonsten
Beim USR habe ich KEINEN Haken bei "SML: CRC-Prüfsummenfehler ignorieren"

Mein USR hat kein Expanded Menue.
Aber er zeigt connected und listet die anzahl der gesndeten bytes.

[klassisch]

@smarthomer-0 Habe jetzt mal

• meinen Lesekopf abgeklemmt
• smartmeter Adapter aud INFO gestellt
• und gesartet

Mein log

smartmeter.0
	2022-02-01 15:46:42.647	info	CONNECTED TO TCP SOCKET
smartmeter.0
	2022-02-01 15:46:42.645	warn	No or too long answer from Socket after last request.
smartmeter.0
	2022-02-01 15:46:42.644	info	Error: No or too long answer from Socket after last request.
smartmeter.0
	2022-02-01 15:44:42.642	info	CONNECTED TO TCP SOCKET
smartmeter.0
	2022-02-01 15:44:42.625	info	starting. Version 3.2.1 in C:/Program Files/iobroker/ioBrMain036/node_modules/iobroker.smartmeter, node: v14.18.2, js-controller: 3.3.22
host.DESKTOP-EJL69IT(ioBrMain036)
	2022-02-01 15:44:38.952	info	instance system.adapter.smartmeter.0 started with pid 1844

Da ist also noch ein CONNECTED TO TCP SOCKET
drin. Das sollte bei Dir auch erscheinen, zumindest im info mode. Fahre normalerweise im Warn mode

Edit: Sorry, Info mode, nicht debug.

[Matis]

@smarthomer-0
Hast denn deinen 001k auch mit Spannung versorgt? Sonst kommt das nix raus und das scheint mir fast so.
Es reichen auch keine 5V, der braucht 12V.

Ich habe den USR-N540 und haben die 12V Spannungversorgung auf RS232-Pin4 an den ehz001k durchgeschleift.

[SmartHomer 0]

@klassisch
Hallo @klassisch - vielen Dank, dass Du das für mich getestet hast (Log mit abgeklemmtem Lesekopf).
Mit Deinem Ergebnis habe ich meine Installation nachvollzogen und bin zu einem vergleichbaren Info-Log gekommen. Somit also Einrichtung Modul und Netzwerk ok.

Dann noch den Haken wie von Dir beschrieben rausgenommen:

Was soll ich sagen: mit dem Ergebnis dann (mit langem LAN-Patchkabel) mit dem Modul zum Zählerkasten, den Lesekopf auf dem Holley-IR-Fenster hin- und hergeschoben - RxD-LED auf dem USR blinkt - USR und smartmeter-Adapter empfangen Daten - smartmeter-Adapter wird "grün" - es funktioniert!

Folgende Datenpunkt-Objekte werden für mME SmartMeter Holley DTZ541-BDBA angelegt:

Wahrscheinlich würde er noch mehr übertragen:

smartmeter.0
2022-02-02 10:07:11.407	debug	SML MESSAGE: START SML-File START SmlMessage Transaction-ID: 
 (000001) Group-No: 0 Abort On Error: 0 Message-Body: SmlPublicOpenResponse Codepage: undefined Client-ID: undefined Req-FileId: f· (00000066ce87) Server-ID: 0a02984c5345000cabce (Sec-Index): 6737543 Sml-Version: undefined CRC 16: valid END SmlMessage START SmlMessage Transaction-ID:  (000002) Group-No: 0 Abort On Error: 0 Message-Body: SmlGetListResponse Client-ID: ������ Server-ID: 
HLY�� List-Name: 
b �� Act-Sensor-Time: (Sec-Index): 6737543 ValList: [ Obj-Name: 1-0:96.50.1*1 Status: undefined Val-Time: Unit: undefined Scaler: undefined Value: HLY / 484c59 Value-Signature: undefined , Obj-Name: 1-0:96.1.0*255 Status: undefined Val-Time: Unit: undefined Scaler: undefined Value: 
HLY�� / 0a02984c5345000cabce Value-Signature: undefined , Obj-Name: 1-0:1.8.0*255 Status: 1c0104 Val-Time: (Sec-Index): 6737543 Unit: 30 Scaler: -1 Value: 13211062 Value-Signature: undefined , Obj-Name: 1-0:16.7.0*255 Status: undefined Val-Time: Unit: 27 Scaler: 0 Value: 386 Value-Signature: undefined , ] List-Signature: undefined Act-Gateway-Time: CRC 16: valid END SmlMessage START SmlMessage Transaction-ID:  (000003) Group-No: 0 Abort On Error: 0 Message-Body: SmlPublicCloseResponse Global Signature: CRC 16: valid END SmlMessage END SML-File

Mit diesem Stand gehe ich es jetzt nochmal mit dem ursprünglich vorgesehenen USR WLAN-Fertiggerät an, vielleicht bekomme ich es doch noch ans Laufen.
Sonst eben ein AVM-Powerline-Modul in die Steckdose vom Zählerkasten und den USR-232TCP-306 per LAN-Kabel auf das Powerline - das läuft ja nun

@Matis
Danke für Deinen Hinweis - elektrisch hat's gepasst, ich war nur mangels WLAN mit dem Sensor noch nicht vor Ort an der Info-Schnittstelle der mME.
Die Sensor-Versorgung habe ich quasi "aussen rum ums USR-Modul" in den EHZ001K eingespeist. Bei mir funktioniert der übrigens prima mit den 5V DC vom USR-Steckernetzteil (klassisch hat ihn lt. Guide sogar mit 2,8V am Laufen).

Wie hast Du denn den Pin 4 mit 12V beschaltet? - USR-Modul aufgeschraubt und eine Ader von +12V auf den Sub-D-Stecker angelötet - Modul wieder zugeschraubt?

Danke Euch und LG

[klassisch]

@smarthomer-0 sagte in Adapter "smartmeter":

Was soll ich sagen: mit dem Ergebnis dann (mit langem LAN-Patchkabel) mit dem Modul zum Zählerkasten, den Lesekopf auf dem Holley-IR-Fenster hin- und hergeschoben - RxD-LED auf dem USR blinkt - USR und smartmeter-Adapter empfangen Daten - smartmeter-Adapter wird "grün" - es funktioniert!

prima, das klingt doch schon mal gut

Folgende Datenpunkt-Objekte werden für mME SmartMeter Holley DTZ541-BDBA angelegt:

Du solltes aber noch tiefer in der Hierarchie absteigen können, bis Du die Daten als Zahlenwerte siehst, also so:

Wahrscheinlich würde er noch mehr übertragen:

smartmeter.0
2022-02-02 10:07:11.407	debug	SML MESSAGE: START SML-File START SmlMessage Transaction-ID: 
 (000001) Group-No: 0 Abort On Error: 0 Message-Body: SmlPublicOpenResponse Codepage: undefined Client-ID: undefined Req-FileId: f· (00000066ce87) Server-ID: 0a02984c5345000cabce (Sec-Index): 6737543 Sml-Version: undefined CRC 16: valid END SmlMessage START SmlMessage Transaction-ID:  (000002) Group-No: 0 Abort On Error: 0 Message-Body: SmlGetListResponse Client-ID: ������ Server-ID: 
HLY�� List-Name: 
b �� Act-Sensor-Time: (Sec-Index): 6737543 ValList: [ Obj-Name: 1-0:96.50.1*1 Status: undefined Val-Time: Unit: undefined Scaler: undefined Value: HLY / 484c59 Value-Signature: undefined , Obj-Name: 1-0:96.1.0*255 Status: undefined Val-Time: Unit: undefined Scaler: undefined Value: 
HLY�� / 0a02984c5345000cabce Value-Signature: undefined , Obj-Name: 1-0:1.8.0*255 Status: 1c0104 Val-Time: (Sec-Index): 6737543 Unit: 30 Scaler: -1 Value: 13211062 Value-Signature: undefined , Obj-Name: 1-0:16.7.0*255 Status: undefined Val-Time: Unit: 27 Scaler: 0 Value: 386 Value-Signature: undefined , ] List-Signature: undefined Act-Gateway-Time: CRC 16: valid END SmlMessage START SmlMessage Transaction-ID:  (000003) Group-No: 0 Abort On Error: 0 Message-Body: SmlPublicCloseResponse Global Signature: CRC 16: valid END SmlMessage END SML-File

Dieses Log verstehe ich nicht, weil es noch (CRC-)Fehler etc. ausweist. Ist der Lesekopf wirklich optimal positioniert?

Was diese Fehler genau bedeuten, weiß ich allerdings nicht. Ich habe sie bei mir noch nicht beobachtet, da kann wahrscheinlich @apollon77 gelegentlich etwas dazu sagen.

Mit diesem Stand gehe ich es jetzt nochmal mit dem ursprünglich vorgesehenen USR WLAN-Fertiggerät an, vielleicht bekomme ich es doch noch ans Laufen.

Sollte im Prinzip gehen, wenn das WLAN Netzwerk gutmütig ist.

Sonst eben ein AVM-Powerline-Modul in die Steckdose vom Zählerkasten und den USR-232TCP-306 per LAN-Kabel auf das Powerline - das läuft ja nun

Kenne ich mich nicht mit aus. Als Funkamateur mag man diese Teile aber nicht wirklich. "Dreckschleudern"

(klassisch hat ihn lt. Guide sogar mit 2,8V am Laufen).

Das ist aber ausserhalb der Spezifikation und keine allgemeine Empfehlung. Kann funktionieren, muß aber nicht. Ich nehme in meinem Fall 3.3V von einem RS485 <-> serial Modul ab und speise dann über eine 20m dünne Telefonleitung den Lesekopf damit. Bei mir funktioniert es, ansonsten hätte ich auch die 5V genutzt, die ich in meinem Fall (Modul, kein Fertiggerät) ohnehin im Gehäuse habe.

An Deiner Stelle würde ich es Schritt für Schritt machen. Also erst mal die Spannungsversorgung vom eHz so lassen wie sie ist und gerade funktioniert. Erst wenn alles ein paar Tage stabil funktioniert zuerst die LAN -> WLAN Sache und erst danach - falls überhaupt - die Versorgung umbauen und optimieren. Schritt für Schritt und dazwischen immer die Stabilität überwachen.
Bei Eingriffen in Dein USR Fertiggerät können auch Fehler passieren und den eHz oder USR killen. Inklusives Oder.

[SmartHomer 0]

@klassisch
Ja, die eigentlichen Werte für diese 4 Datenpunkte kommen eine Ebene tiefer, die verwende ich schon in History und Flot, ich hatte beim Screenshot die Ordner nicht aufgeklappt.

Das mit dem Log / CRC ist erneut ein guter Hinweis, ich versuche mal den Lese-Kopf noch etwas zu optimieren. Vielleicht hat ja ein anderer "Forums-Mitleser" auch den Holley im Einsatz und kann mal kurz berichten, welche Datenpunkte sie/er empfängt (?).

Schöne Grüße

[klassisch]

@smarthomer-0 Der KANN viel mehr liefern, wenn der Meßstellenbetreiber ihn läßt. Es gibt hier im Forum Berichte von Kunden der Bayernwerke, bei denen er alle Phasen berichtet. Einfach mal die große Suchmaschine befragen. Wird Dir aber nichts helfen, wenn Dein Betreiber sich auf das verpfilchtete Minimum zurückzieht.

Zum Einstellen mal Wiederholungsrate von 1 Sekunde einstellen und Log auf dem Smartphone/Tablet/Laptop anschauen. Dann verschieben und an den 4 "Enden", bei denen die Fehler auftauchen, jeweile eine Markierung anzeichnen/ankleben. Danach den Kopf vermitteln.

[Matis]

Wie hast Du denn den Pin 4 mit 12V beschaltet? - USR-Modul aufgeschraubt und eine Ader von +12V auf den Sub-D-Stecker angelötet - Modul wieder zugeschraubt?

Ja, genau so, an alle vier Ports. So hab ich nur ein Kabel und Spannung direkt per Dsub auf allen Ports.
Ich denke dass die 001k auch mit weniger Spannung auskommen, ich hab teilweise auch 001, die brauchen sicher >=8V

Per Optokoppler kann man niemals den ehz schrotten,
das ist Blödsinn.

[INing]

Nachdem mir der Thread bereits bei meinem Verbrauchszähler und PV Zähler weitergeholfen hat, brauche ich nun Hilfe für einen Zwischenzähler.
Es handelt sich um eine DRT428M-2 der per RS485 mit meinem PI kommuniziert.
Es handelt sich um eine QITA USB RS485 Konverter am PI.
Den Treiber habe ich nicht installiert, da er erfolgreich erkannt wurde (?!?).
CH341SER: https://github.com/SoldierJazz/CH341SER-Driver-For-ch340-ch341

Meine Einstellungen sehen aktuell wie folgt aus:

Ich habe bereits einige Einstellungen ausprobiert aber die Verbindung gelingt nicht.
Hat jemand einen Tipp für mich?

[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.