Ich möchte gern einen Wärmemengenzähler in IPS einlesen (Sharky 773 - Kommunikationsbeschreibung siehe Anlage).
Mit dem IPS-M-Bus Gateway/Konfigurator komme ich nicht weiter, da m.E. die Initialisierung der optischen Schnittstelle (2,2 sec 0-1 senden) nicht implementiert ist.
Mit der Lorus Free Software kann ich den Zähler erfolgreich einlesen (siehe Snapshot)
Hat jemand eine Lösung oder zumindest Tipps für mich?
Guten Morgen Herbert,
in dem verlinkten PDF steht, dass der Zähler 3 Schnittstellen hätte. Optisch, M-Bus und RS-232.
Ist das bei deinem Model auch so? Da wäre es sehr einfach die M-Bus Schnittstelle zu verwenden, da du ja scheinbar auch schon eine Leitung zum Zähler hast, sonst wäre ja auch der optische Lesekopf nicht möglich.
Ja, ich denke auch das ist das Problem. Weil das MbusGateway ist ja eigentlich für eine elektrische MBus vorgesehen.
Du könntest aber versuchen diese Initialisierungsseqeunz einfach auszuprogramieren, und direkt an die Schnittstelle zu senden. Dann die Schnittstelle wieder an das Gateway zu übergeben. Experimentel und aufwändig aber ggfls. möglich.
Oder du setzte einen Arduino/NodeMCU dazwischen welche die Initialsierung durchführt. hab bei mir so etwas ähnliches laufen. Der WMZ hat eine elektrische MBus Schnittstelle welche über eine NudeMCU auf WLAN umgesetzte wird und dann an einem ServerSocket in IPS landet. Funktioniert tadellos. Sollte kein großes Problem sein der NodeMCU beizubringen die Initialisierung voranzustellen.
Ich habe jetzt mal die Com-Initialisierung angesehen (siehe Anlage). Die ersten Einträge sind von IPS, hier wird „01 00 00 …“ gesandt. Bei meinen zwei weiteren Tests mit zwei funktionierenden Programmen wird jeweils „ff ff ff ff 00 …“ am Anfang gesandt.
ich habe jetzt sowohl von IPS als auch von einem der beiden funktionierenden Programme jeweils die Logs beim Öffnen der COM-SS erstellt (nix weiteres - nur geöffnet). Bei IPS wird in der TABLE-View in Zeile 30 das Timeout auf (01 00 …) gesetzt, beim anderen Programm in Zeile 38 (FF FF FF …).
Alles auf dem gleichen PC und ich habe logischerweise nicht parallel in den Windows-Einstellungen rumgespielt
Aus meiner Sicht liegt zumindest die Vermutung nahe, dass die Timeout-Fehler daher kommen könnten.
PS: Die Dateien sind alle *.html, nur für das Hochladen im Forum habe ich sie als *.txt umbenannt.
Ich glaube nicht, dass es daran liegt. Ich konnte in deinen Debugs nirgends die echt gesendeten Daten sehen. Da muss irgendwo das Startzeichen 0x68 auftauchen. Ich habe es aber nicht gefunden. Laut Doku brauchst du 480 Bytes senden als Init. D.h. du kannst ja mal versuchen 480 mal 01010101b = 85 (Binary Code | Binary: 01010101 | Decimal: 85 | Bits: 8) zu senden, um das Gerät zu wecken. (Das müsste per SPRT_SendText gehen direkt am M-Bus Modul vorbei). Und danach schön im Standard per MBUS_UpdateValues im Skript anfragen. (Den Timer in der Instanz natürlich deaktivieren!)
Das wäre so mein Tipp - natürlich vollkommen ohne Gewähr
also vom Raspi kann ich die Kommunikation aufbauen (Log vom M-Bus-Gateway sieht m.E. gut aus). Leider werden die ankommenden Daten nur „buffer in“ und nicht weitergeleitet …(siehe Anlage)??
Ich habe auch noch ein Problem mit „MBUS_UpdateValues“ - dies rufe ich am Ende meines „Aufrufscripts“ auf und bekomme immer ein TimeOut …??
ich komme hier nicht weiter und habe mit bbernhards Hilfe folgenden Stand:
Könntest Du vielleicht aml testen ob wenigstens der HEX-String passt?
Ich stehe scheinbar auf dem Schlauch.
Positiv ist: ich kann ziemlich zuverlässig nach dem Auwecken des Zählers über die optische Schnittstelle, ein aus meiner Sicht gültiges Telegramm empfangen. Den ganzen Echo-Müll (optisch) filtere ich m.E. über Registervariable und Splitter/Cutter weg. So dass ich m.E. einen gültigen HexString habe:
Ich habe mir jetzt auch das von euch empfohlene „M-Tool“ von der NZR-Seite geholt - tolles Teil! In dieses Tool kann ich folgenden String als Rohdaten erfolgreich einlesen:
BBernhard hat aus meiner Sicht die brilliante Idee, diesen String per SSCK_SendText(12169, $String); an ein ServerSocket vom M-Bus-Gateway zu senden. Leider wird dieser nicht verabeitet siehe:
Ich gehe davon aus, dass ihr die gleiche Spec benutzt wie NZR, dann müsste doch auch das Einlesen der Rohdaten bei IPS funktionieren???
Wie kann ich denn den String (die Rohdaten) zum IPS-Gateway senden? Ich würde wirklich sehr ungern das Telegramm bzw. die Rohdaten nochmals dekodieren müssen, wenn ihr dies doch schon getan habt.
Servus Herbert.
Ich fürchte du hast mich missverstanden. Das Datenpaket geht nicht von IPS an IPS.
Meine Konfiguration sieht so aus:
WMZ <->Pegelwandler<->NodeMCU<->WLAN<->IPS
Der Pegelwandler macht mir aus den MBUS Pegeln ein 3V TTL Signal. Die NodeMCU reicht mir dieses dann 1:1 transparent an den IPS ClientSocket durch. Die arbeitet quasi nur als TTL<->Wifi Gateway.
d.h. das im Endeffekt IPS direkt mit dem WMZ spricht.
Aber schau mal, ich habe dir hier nochmals ein Debug des MBus Client Socket angehängt.
Die Reihenfolge ist etwas anders als in deinem Screenshot.
Hmm, direkt über mein Gateway wird das schwierig, ich könnet aber mal versuchen dein Setup nachzustellen.
So wie ich dich verstanden habe empfängst du über RS232, und schickst die daten dann an einen IPS Socket weiter, richtig ?
Also wenn ich unsere Screenshots vergleiche ist der Ablauf aber anders.
Erst sendet IPS diesen kurzen 17 Byte langen String. → den sehe ich bei dir nicht
Darauf antwortet mein WMZ mit „E5“
Dann schickt IPS die 5 Byte
Und dann kommt vom WMZ der lange Datenstring
Ich versuche mal dein Sache nachzubauen, dann sehen wir weiter.
greez
bb
Nach meinem Verständnis sollte es schlicht egal sein, welcher Befehlsstring gesendet wurde, der Antwort-String vom „Mess-Gerät“ sollte in jedem Fall korrekt interpretiert werden.
Tut mir leid, habs auch nicht geschafft. Irgendwas klemmt da.
Es scheitert schon am bei der ersten Anfrage.
Nachdem ich mit ‚E5‘ antworte sollte eine leer „Result“ Zeile kommen.
Danach dann noch das ‚10 7B FD…‘
Tut aber nicht.
Sendet man den Daten String trotzdem so passiert nichts, er wird nicht dekodiert.
Hab das MBUS Gateway am ClientSocket, and dann einen ServerSocket (gleicher Port natürlich) mit dem ich per Script kommuniziere. Die Daten die ich aus dem Script sende kommen so wie bei dir bis zum MBUS Gateway durch. Dort ist dann Schluß. Keine Ahnung warum das nicht läuft.
siehe:
das Telegramm bzw. die Rohdaten nochmals dekodieren müssen, wenn ihr dies doch schon getan habt.
