Raspberry als ModBus/TCP SLAVE-Server: C.M.I über ModBus/TCP mit Raspi verbinden und analoge/digitale Ein-und Ausgänge von UVR16xx über ModBus lesen und schreiben

    Du hast Probleme beim Login? Schreibe uns im Forum "Probleme mit der Registrierung".
      • 1

      • # 162439

      Raspberry als ModBus/TCP SLAVE-Server: C.M.I über ModBus/TCP mit Raspi verbinden und analoge/digitale Ein-und Ausgänge von UVR16xx über ModBus lesen und schreiben

      Hallo,

      um externe Messwerte in die UVR16xx reinzubekommen, habe ich den Weg über den Modbus vom C.M.I gewählt.
      Mit einem Modbus/TCP-Slave Server z.B. ("diagslave"), der auf dem Raspi läuft, lässt sich z.B eine UVR16xx, RSM610 oder CANIOxx über C.M.I über Modbus/TCP übers Netzwerk mit der Aussenwelt verbinden.

      Ich hab mir inzwischen eine C.M.I für meine UVR16xx Steuerungen zugelegt und bin fleissig am erkunden der vielen Schnittstellen, Busse und Protokolle.
      Das übertragen der Funktionsdaten von TAPS2 in die Steuerung und vieles andere ist mit der C.M.I sehr komfortabel geworden
      und die meisten Programme dazu sind auch in Linux verfügbar.

      Im C.M.I arbeitet ein ModBus/TCP-Master-Server, der über die ModBus-Eingänge 64 analoge und 64 digitale Werte einlesen kann.
      Über die ModBus-Ausgänge können die analogen und digitalen Werte ausgegeben werden.

      Für meine Solar und Heizungssteuerung hab ich zum Testen die Werte vom Lamdacheck in die UVR16xx übertragen. Damit können in der UVR die Werte vom
      Abgassensor, Restsauerstoff usw. des Lambdachecks verwendet werden, obwohl z.B. kein Abgassensor an der UVR hängt, man spart sich doppelte Sensoren durch
      Mehrfachverwendung von Sensordaten.

      Eine weitere wichtige Anwendung ist für mich das Versorgen von meinen Test-UVR16xx im Testumfeld mit Echtdaten, also mit Sensorwerten vom produktiv-System vom produktivem CAN-Bus.
      Das Testumfeld mit eigenem CAN-Bus kann ich wie ein Simulator mit Echtwerten betreiben. Z.B wenn ich im Testumfeld einen bestimmen Wert benötige, den mir die Prod-Anlage grad nicht liefert,
      dann überschreibe ich zum testen auf dem Raspi im Modbus/TCP-Slave Server einfach das entprechende Modbus-Register mit dem benötigten Wert für den Testfall (ist wie ein digitales Simboard).
      Mein Ziel wird sein: Mit einem Python-Script gespeicherte produktiv-Werte von einem ganzen Tag im Zeitraffer im Test-UVR16xx durchzuspielen.
      Damit kann z.B ein ganzer Tag im Testsystem simuliert, mit gespeicherten Logdaten beliebig oft nachgefahren werden, um z.B. einen Programmfehler zu finden
      oder komplexe Funktionsbausteine besser zu verstehen.

      Weiterhin hab ich zum testen an den Modbus/TCP-Slave Server der auf dem Raspi läuft den iobroker angeschlossen, um dort die UVR-Werte weiter zu verarbeiten,
      oder von dort Werte zur UVR zu schicken.

      Bevor die externen Werte von den ModBus-Eingängen über die C.M.I zur UVR16xx übertragen werden können,
      ist ein sorgfältiges Mapping der C.M.I Ein- und Ausgänge vom Modbus zum CAN-Bus und zu den Netzwerkeingängen der UVR16xx notwendig.
      Diese Arbeit ist sehr aufwendig, muss aber nur einmal gemacht werden und sollte dokumentiert werden um später noch einen Überblick zu haben
      woher oder wohin die vielen Werte von und zum Modbus ihren Weg zur UVR16xx nehmen. Bei der Fehlersuche ist eine Dokumentation dieses Mappings auch sehr hilfreich.

      Da die über den Modbus übertragbaren C.M.I Werte nur einen kleinen Teil der zur Verfügung stehenden Modbus-Register belegen,
      habe ich bei mir grosszügig die Adressen der verwendeten Modbus-Register im ModBus/TCP SLAVE-Server auf dem Raspi ausgewählt.

      C.M.I Modbus-Ausgang-Analog Adresse 1-64 für Analog Ausgänge unit 1 zur Adresse 101-164 Modbus-HoldingRegister schreiben mit Funktion 06
      C.M.I Modbus-Eingang-Analog Adresse 1-64 für Analog Eingänge unit 1 von Adresse 201-264 Modbus-HoldingRegister lesen mit Funktion 03
      C.M.I Modbus-Ausgang-digital Adresse 1-64 für digital Ausgänge unit 1 zur Adresse 301-364 Modbus-Coils schreiben mit Funktion 05
      C.M.I Modbus-Eingang-digital Adresse 1-64 für digital Eingänge unit 1 von Adresse 401-464 Modbus-Coils lesen mit Funktion 01

      Wenn der "diagslave" auf dem Raspberry Pi im TCP-Mode gestartet ist und das Mapping im C.M.I fehlerfrei ist, beginnt der C.M.I sofort mit der Datenübertragung (schreiben und lesen)
      der Modbus-Register und coils) zum ModBus/TCP-Slave-Server auf dem Raspberry Pi.

      Ich habe zum Testen und Programmieren auf dem Raspberry Pi die Python Modbus Pakete pyModbus und pyModbusTCP installiert.
      Dazu gibt es eine pyModbus.console mit der man sich als Client an den ModBus/TCP-Slave-Server auf dem Raspberry Pi connecten kann und Modbus-Register lesen und schreiben kann
      oder man programmiert sich mit einem Python-script einen Python Client zum individuellen auslesen und schreiben der Modbus-Register.

      Der ModBus/TCP-Slave-Server auf dem Raspberry Pi lässt sich mehrfach connecten.
      Z.B. lassen sich auch SmartHome-Systeme, wie iobroker direkt an den "diagslave" anschliessen.

      Im iobroker muss dazu der Master-Mode im modbus-adapter gesetzt werden und die ipadresse vom "diagslave" eingetragen werden
      und ein mapping (konfigurieren) der verwendeten Modbus-Register auf die Adressen im iobroker durchgeführt werden.
      Dann beginnt der iobroker nach start der modbus-Instanz auch sofort mit der Datenübertragung der UVR16xx-Werte. Die Objektstruktur für die Modbus-Register
      Werte wird intern angelegt und steht sofort zur Verfügung. Wenn man diese Struktur aufklappt, dann sieht man sofort die aktuell übertragenen Werte
      und kann durch farbliche Markierung der einzelnen Felder ein Update der einzelnen Werte verfolgen.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 2

      • # 162452
      Hallo Jürgen,

      dein Projekt zum Thema Verbindung UVR16x2k über CMI mit Modbus/TCP-IP über Netzwerk mit der Aussenwelt und Visualisierung im Schema interessiert mich brennend.

      Ich habe mir zwar vor ca. 2 Jahren einen Rasperry-pi gekauft, bin aber aber aufgrund meiner fehlenden technischen Kenntnisse bei der Realisierung nicht weiter gekommen.

      Mich würde interessieren, ob man mit dem Raspi auch Json-Abfragen mit einem Jsonparser machen kann und diese Werte vielleicht dann über den genannten Modbus/TCP-Slave Server z.B. ("diagslave")

      in die UVR16x2k übernehmen kann.

      Ich habe den Smartfox eingesetzt und mein Ziel wäre Bezug/Einspeisewerte Gesamt und je Phase im Schema zu visualisieren.
      Ebenso die Leistungs- und Ertragsdaten meines Wechselrichters Piko 5.5.

      Der alte Smartfox kann noch nicht Modbus TCP-IP. Der neue SmartfoxPro schon.

      Herzlichen Dank im Voraus für deine Info.


      Sonnige Grüße



      Karl
      Files
      • 3

      • # 162463
      Hallo Karl,

      mit dem Raspi kannst natürlich auch Json-Abfragen machen, je nach Programmiersprache die verwendet werden soll.

      Meine Erfahrungen mit Json-Abfragen habe ich bisher mit einem javascript im iobroker und dem C.M.I gemacht.
      Das C.M.I hat leider nur zum auslesen der Daten eine Json-API.
      Über diese Json-API. habe ich mit einem javascript testweise Daten von der UVR1611 über C.M.I direkt in den iobroker eingelesen und dort Datenpunkte erzeugt.
      Das geht aber bestimmt mit fast allen Programmiersprachen auf dem Raspi unter linux.

      Und nun wieder zu Modbus:
      Ich habe inzwischen meine gesammelten Daten von allen meinen Geräten in MQTT Messages mit entsprechenden topics am laufen.
      Zum Schreiben der externen Werte in den ("diagslave") ModBus/TCP SLAVE-Server hinein hab ich ein python-script (client) verwendet.

      z.B. der Datenrahmen1 von der UVR1611 ist eine Message mit topic uvr1
      Beispiel-Message der uvr1611 vom prod-System über BL-NET ausgelesen:
      set UVR uvr1: 21.0 83.8 30.4 47.4 25.7 58.9 82.8 81.1 36.2 34.8 28.7 16.4 28.1 23.0 31.6 0.0 0 0 1 27 0 0 0 0 0 0 0 0 0 0 0 1 0 0.0 32414.8 8.1 103458.1

      Im nachfolgenden python-script lese (subsribe) ich die MQTT Messages und filtere das topic uvr1 gezielt raus und zerlege dann die message in die einzelen Werte
      und schreibe dann jeden Wert (S1-S16) einzeln in einer Schleife in die Modbus-Register.

      #!/usr/bin/env python3
      import paho.mqtt.client as mqtt
      from pyModbusTCP.client import ModbusClient
      import time

      SERVER_HOST = "localhost"
      SERVER_PORT = 502
      c = ModbusClient()
      c.debug(True)
      c.host(SERVER_HOST)
      c.port(SERVER_PORT)

      def write_modbus_Hregister(hregister, wertr):
      if not c.is_open():
      if not c.open():
      print("unable to connect to "+SERVER_HOST+":"+str(SERVER_PORT))

      if c.is_open():
      if c.write_single_register(hregister, wertr):
      print(" write ok ")
      else:
      print(" write error")

      def topic1(p_topic, p_payload):
      if p_topic == "uvr1":
      s_payload = str(p_payload)
      l_dr1 = s_payload.split()
      for sx in range(1, 16):
      write_modbus_Hregister(sx+200, int(float(l_dr1[sx+2])*10))

      def on_connect(client, userdata, flags, rc):
      print("Connected with result code " + str(rc))
      client.subscribe("#")

      def on_message(client, userdata, msg):
      topic1(msg.topic, msg.payload)

      def on_log(client, obj, level, string):
      print(string)

      client = mqtt.Client()
      client.on_connect = on_connect
      client.on_message = on_message
      client.on_log = on_log
      client.connect("localhost", 1883, 60)
      client.loop_forever()


      Ich hab ein bisschen gegoogelt und für den Kostal Piko eine interessante Webseite gefunden:

      h t t p s://wiki.volkszaehler.org/hardware/channels/solar_inverters/kostal_pico?redirect=1

      Kostal Piko
      Diese Wikiseite zeigt zwei Ansätze zur Einbindung von Kostal Wechselrichtern an den Volkszähler durch Auslesen des Webfrontends der Wechselrichter.
      Die Wechselrichter zeigen sowohl die aktuelle Leistung als auch den gesamten Stromertrag über das Webfrontend an.
      Diese Daten werden per script ausgelesen und in die Volkszähler-Datenbank geschrieben.

      Das script zum Auslesen des Webfrontends, wenn es für deine Zwecke brauchbar ist, müßte so geändert werden, dass nur die ausgelesenen Daten weiter verarbeiten kannst.
      Ich habe leider keinen Kostal Piko Wechselrichter, deshalb kann ich hier nichts testen und nichts zu den scripten sagen und Ferndiagnosen sind mir zu aufwendig.

      Meine PV Anlage arbeitet mit SMA Wechselrichter, den ich über bluetooth und SBFspot auslesen kann.

      Jeder hat so seine Infrastruktur und ein Konzept für die Datenquellen.
      Bei mir hab ich die Daten von den verschiedensten Geräten ausgelesen und in MQTT-Messages eingepackt
      und somit eine einheitliche Datenquelle (Mosquitto-Message-Broker) zum weiterverarbeiten.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 4

      • # 162467
      Hallo Jürgen,

      vielen Dank für die Info.

      Aktuell habe ich in meinem UVR-Schema einen Hyperlink auf die Json-Abfrage. Pfeil von links nach rechts. Die Daten sind somit mit einem Link auf der 2. Ebene sichtbar.

      Aktuell geht es vom CMI bezüglich Daten nur hinaus und hinein nur über Modbus-TCP-Master - Slave. Oder siehst du dies anders ?

      Die andere von mir bereits angedachte Variante wäre einen CAN-EZ3 mit einer zusätzlichen Wandlermessung einzusetzen, obwohl ich schon eine sehr genau Wandlermessung über den Smartfox habe.

      Damit könnte man die Visualsierung der Stromdaten auf der 1. Ebene im Schema darstellen.

      Der neue WR Kostal Plenticore Plus und der neue SamrtfoxPro können Modbus-TCP-IP schon und somit wäre die Visualisierung über das CMI und Modbus-TCP-Master realisierbar.


      LG



      Karl
      Files
      • 5

      • # 164255
      Hallo Karl,

      ich antworte auf deine mail im Forum, da es zum Thema Modbus-TCP noch nicht so viele Erfahrungen gibt und ich bin der Meinung dass man die Infos
      zu diesem Thema teilen sollte, damit der Erfahrungsschatz langsam grösser wird.

      Ich habe mich in letzter Zeit mit ähnlichen Problemstellungen beschäftigt. Dabei bin ich bei der Suche nach gültigen Modbusregistern und deren Werte zweistufig vorgegangen.
      Zuerst habe ich im Gerät über den ganzen Modbus-Adressrange mit einem Modbus-Sim-Tool wie z.B. ananas64 (windows10) nach gültigen Registeradressen gesucht.

      In der Ergebnisliste waren bisher 3 verschiedene Ergebnistypen zu finden.

      1. z.B. Register 840, value: 501, Poll: OK --> Treffer, gültiges Modbusregister mit gültigem Wert
      2. z.B. Register 259, Gateway path unavailable --> Treffer, gültiges Modbusregister aber falsche unit (mit verschiedenen units nochmal suchen bis gültiger Wert kommt)
      3. z.B. Register 838, Illegal data address --> kein Treffer, kein gültiges Modbusregister in diesem Gerät

      Danach eine vorhandene Doku zur Hand nehmen und aufgrund der beschriebenen Doku die gefundenen gültigen Modbus-Register hoffentlich zuordnen können und
      mit den entsprechenden Datentypen dann die richtigen Werte ermitteln.

      Das hat bei mir bisher mit meinen Geräten die eine Modbus-TCP Schnittstelle hatten sehr gut funktioniert.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 6

      • # 164258
      Hallo Jürgen,

      vielen Dank für deine rasche Antwort.

      Ich hätte dieses Thema anschließend sowieso mit all seinen Facetten und Problemen, natürlich mit deinem Input, hier veröffentlicht.

      Habe dies so gemacht, wie du dies beschreibst.

      Werte auslesen mit Modbus Simulator. Freeware: 1. Radzio! Modbus Master Simualtor und auch zum 2. Mal mit QModMaster.
      Anschließend mit der Registerliste abstimmen.

      Von 23 Werten konnte ich 22 verknüpfen. Bei 2 bekomme ich irgendwelche Werte ! ?

      Die fehlerhaften Werte haben einen Typ uint64 (=unsigned integer 64). Ich kann aber im CMI nur maximal unsigned integer 32 einstellen.
      Vielleicht liegt es an diesem Problem ?

      Möglich Einstellungen im CMI bei Datentyp:
      8-bit signed, 8-bit unsigned, 16-bit signed, 16-bit unsigned, 32-bit signed, 32-bit unsigned, 32-bit floating point.
      Byte-Reihenfolge: überall big-endian außer bei % habe ich little-endian eingestellt.

      Mit diesen Einstellungen kommen alle 21 Werte lt. beiliegendem Modbus Register korrekt an.

      2 Fehlerhafte Adressen ?
      41000 - 41003 Energy from grid-kumuliert: uint64: Hier kommt irgend die Zahl 263782400. Obwohl der korrekte Wert 53463 wäre. Siehe Bild 7.
      41004 - 41007 Energy into grid-kumuliert: uint64: Dieser Wert kommt korrekt mit 4021 Wh an.
      41008 - 41011 Energy smartfox-kumuliert: uint64: Hier kommt dieser Wert 263782400. Obwohl der korrekte Wert 28225 Wh wäre. Siehe Bild 7.

      Ich vermute mal, dass hier ein Softwarefehler oder ein Einstellungsfehler bei den Parametern vorliegt.

      Wie siehst du dies Jürgen ?


      Herzlichen Dank im Voraus für deine Hilfe.


      LG


      Karl
      Files
      • 7

      • # 164264
      Hallo Karl,

      auf den ersten Blick mysteriös, zumal einer von den drei uint64 Werten, der mittlere Wert Energy into grid 41004-41007 richtig eingelesen wird.

      laut der exel-tabelle von Smartfox Pro Modbus V16E:
      Start...End...Size..RW....Function codes..Name...Type..Units
      41000 41003 4 RW 0x03 0x10 Energy from grid uint64 Wh
      41004 41007 4 RW 0x03 0x10 Energy into grid uint64 Wh --> eingelesener Wert ist ok !!
      41008 41011 4 RW 0x03 0x10 Energy Smartfox uint64 Wh

      40010 40011 2 R 0x03 SW-Version uint32
      40012 40013 2 R 0x03 Wlan-Modul SW-Version uint32
      40014 40016 3 R 0x03 MAC-Adresse LAN uint8[6]
      40017 40017 1 R 0x03 Modbus Protocol Version uint16

      Kannst die Hex-Werte ( 3 * 4 Bytes ) von den eingelesenen Modbus-Registern der Adressen 41000-41003, 41004-41007, 41008-41011 einstellen ?
      Vielleicht erkennt man ein Muster im Vergleich zum richtigen Wert von 41004-41007

      41000 41003 4Bytes 0x00 0x00 0x00 0x00
      41004 41007 4Bytes 0x00 0x00 0x00 0x00
      41008 41011 4Bytes 0x00 0x00 0x00 0x00

      Hast auch mal die SW-Version 40010-40011 und die Modbus Protocol Version 40017-40017 ausgelesen, nicht das sich da was in der Doku geändert hat.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 8

      • # 164283
      Hallo Jürgen,

      danke für die ausführliche Antwort.

      Was ich noch nicht richtig verstanden habe ist folgendes:

      Es gibt eine Start und Ende Adresse. Bsp.: Power total-Watt: 41018 - 41019 2 R 0x03 int32, die richtige Adresse ist aber 41017: Hier kommt der korrekte Wert retour.
      41018 minus 1, da Offset-1.
      Welche Aufgabe hat dann nun die Adresse 41019 ?

      Beim Auslesen 40011 kommt die aktuelle Wlan-Softwareversion 190502. Wert ist korrekt.

      Frage von dir:
      Kannst die Hex-Werte ( 3 * 4 Bytes ) von den eingelesenen Modbus-Registern der Adressen 41000-41003, 41004-41007, 41008-41011 einstellen ?

      Was meinst du mit 3 * 4 Bytes ?

      Bei den Adressen Modbus-Registern der Adressen 41000-41003, 41004-41007, 41008-41011 bekomme ich als korrekten Wert nur 41005 Energie into grid-kumuliert retour.

      Anbei einen Link zu einem Projekt mit rasperry-pi und CMI.

      punktwissen.at/2019/03/10/rasp…ersetzer-fur-die-uvr16x2/

      Könnte es sein, dass die Zahlen zu lang sind ?

      Welche Einstellungen sind bei energy from grid - 41000 41003 4 RW 0x13 uint64 Wh vorzunehmen. Der Wert ist seit letzter Woche ca. 60.300 Wh ?

      Wie geht das CMI (CAN-BUS) und Modbus TCP mit Zahlen größer 32.768 um ? 8 x 8 x 8 x 8 x8

      LG



      Karl
      • 9

      • # 164296
      Hallo Karl,

      mit Hex-Werte ( 3 * 4 Bytes ) von den eingelesenen Modbus-Registern der Adressen 41000-41003, 41004-41007, 41008-41011
      meinte ich dass in deinem sim-tool wie auf bild11 (6. TEST REGISTERADRESSEN) nicht dezimal einstellst, sondern hexadezimal einstellst.
      Dann werden für die 50 Adressen hex-werte angezeigt. Davon könntest wieder ein screenshot machen und hier einstellen.

      Die Hexwerte von den 50 Adressen könnte ich dann auch als Testfall in mein diagslave einstellen und hätte somit auch die original-werte
      der Modbus-Register von deinem Smartfox-Pro, so wie bei dir (eine Kopie deiner Modbus-Register).
      Ich könnte auch selber so ein Testfall erzeugen, aber du hast ja die Original-Werte, die finde ich zum nachvollziehen besser.

      Warscheinlich kann das CMI nur (uint32) einlesen und nicht (uint64).
      Und dass es mit dem Energy into grid-kumuliert funktioniert hat, hängt nur damit zusammen, dass der Wert ziemlich klein war... 4021 Wh.

      Ich stelle mir die Modbus-Schnittstelle als definierten Speicherbereich mit festgelegten Adressen und Adressbereich vor.
      Hinter jeder Adresse verbirgt sich ein Byte. Dieser Adressbereich kann einmal von aussen (z.B CMI, sim-tool oder sonst. Client) angesporochen werden
      und das Gerät (Smartfox-Pro) selber muss diesen Adressbereich intern versorgen und lesen.
      Eigentlich nur ein ein paar Bytes gemeinsam genutzter Speicher zum kommunizieren.
      Ich bin kein Lehrer, aber das mit den Wertebereichen und die Darstellung in Bits und Bytes werden wir noch hinbekommen.

      Im nächsten Schritt müssen wir uns dann überlegen wie wir die 4 Bytes (uint64) von deinem Smartfox-Pro ins CMI reinbekommen.
      Als 4 Bytes (uint32) oder als 4 mal 1 Byte und dann im TAPPs umrechnen.. usw.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 10

      • # 164342
      Hallo Karl,

      ich muss mich korrigieren, im letzten Beitrag habe ich von einem Byte hinter jeder Registeradresse erzählt. Das stimmt nicht. An jeder Registeradresse steht ein Wert von einem
      Register. Und die Register sind 16-bit breit, also 2 Bytes pro Register und nicht 1 Byte.. sorry. Ist mir erst beim testen aufgefallen.
      Wenn man nicht so genau hinschaut, dann sieht man das nicht, passiert viel automatisch unsichtbar im Hintergrund.
      Ich habe bei meinen bisherigen Modbus-Verbindungen auch noch keine so grossen Werte übertragen müssen.
      Habe alle Debug und Trace-Möglichkeiten eingeschaltet um jedes Byte zu sehen beim testen.

      Zum testen habe ich den iobroker verwendet, denn dort kann ich auch ein unit64 Modbus-HoldRegister definieren.
      Ich hab zwei Testfälle erzeugt mit dem iobroker, dort kann man Werte in unit64 Modbus-Register eingeben.
      Vom iobroker(master) gehts bei mir über den diagslave(slave) zum CMI(master).

      Testfall 1 im iobroker ein unit64 HoldRegister (206 size=4) mit dem Wert 2147483647 gefüllt.
      Testfall 2 im iobroker ein unit32 HoldRegister (16 size=2) mit dem Wert 2147483647 gefüllt.
      Danach habe ich im CMI (die genannten Register im CMI-Eingang sind mit unit32 definiert) geschaut was von Register 206 und Register 16 dort im Eingang ankommt.

      Zusätzlich hab ich mit einem python script im debug-modus die HoldRegister 206,207,208,209 im diagslave vom Testfall 1 ausgelesen und
      die HoldRegister 16,17,18,19 im diagslave vom Testfall 2 ausgelesen.

      Testfall 1 unit64, lesen Register 206-209 vom digislave mit python script
      Tx
      [E9 D2 00 00 00 06 01] 03 00 CE 00 04 --------------------> Anfrage: Funktion (03) start adresse 206 (00 CE) Anzahl Register 4 (00 04)
      Rx
      [E9 D2 00 00 00 0B 01] 03 08 7F FF FF FF 7F FF FF FF --> Antwort: Funktion (03) Byte-Zählung (08) Register 206 (7F FF) Register 207 (FF FF) usw ...
      ---------------------------------- 206---207---208---209-- Hier sieht man es wird zwei mal uint32 hintereinander übertragen!!
      hex(7F FF FF FF) = dez(2147483647)

      Testfall 2 unit32, lesen Register 16-19 vom digislave mit python script
      Tx
      [65 08 00 00 00 06 01] 03 00 10 00 04 --------------------> Anfrage: Funktion (03) start adresse 16 (00 10) Anzahl Register 4 (00 04)
      Rx
      [65 08 00 00 00 0B 01] 03 08 7F FF FF FF 00 00 00 00 --> Antwort: Funktion (03) Byte-Zählung (08) Register 16 (7F FF) Register 17 (FF FF) usw ...
      ---------------------------------- 16----17----18----19---

      Mit dem Test-Sim ananas64 in Win10 war das gleiche in den genannten HoldRegistern im hex-mode zu sehen.

      Mein diagslave-Server kann auch keine unit64 Werte übertragen.
      Er hat im Testfall 1 immer nur 2 mal unit32 hintereinander übertragen anstatt ein unit64. (warum das so ist, weiss ich nicht, bin kein Modbus-Spezialist)
      Und wenn ich im iobroker im unit64 Register ein Wert der grösser als 32-bit (int32), also grösser 2147483647 eingegeben habe,
      dann kam nix mehr richtiges über den digislave rüber und im CMI auch nix an... leider.

      Fazit: Werte die kleiner als 2147483647 sind, können bei mir fehlerfrei vom iobroker über diagslave zum CMI übertragen werden und kommen alle sauber im CMI Eingang an.
      Die Übertragung geht somit von uint64 auf uint32 (Testfall 1) als auch von uint32 nach uint32 (Testfall 2) mit diesen grossen Werten.

      Wenn deine Energy from grid-kumuliert Werte nicht grösser als 2147483647 werden, dann sollte die Übertragung von uint64 auf uint32 noch funktionieren und im CMI was ankommen.
      2147483647 Wh wären > 2.147.483 KWh oder > 2.147 MWh, ist eigentlich schon ein sehr grosser Wert, das sollte schon ein paar Jahre bei dir funktionieren.

      Das CMI kann nur (uint32) einlesen und nicht (uint64).
      Und dass es mit dem Energy into grid-kumuliert funktioniert hat, hängt nur damit zusammen, dass der Wert ziemlich klein war... 4021 Wh.

      Wenn die Screenshots dazu benötigst, dann kann ich sie noch einstellen. Ist ganz schön umfangreich geworden, so ein kleiner Test. Ich hab dabei auch einiges dazugelernt.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 11

      • # 164357
      Hallo Jürgen,

      vorerst einmal vielen herzlichen Dank, dass du dir die Mühe machst mit mir diese Nuss zu knacken.

      Ich komme ja mit dem Lesen nicht mehr nach. :)

      Meine Vermutung ist, dass es eher ein Adressenproblem ist, als ein Übertragungsproblem, da von 25 Werten ca. 20 o.k. sind und die Zahlen maximal 50.000 betragen und damit unter deinen genannten
      Zahlen sind.

      Anbei einen Screenshot nochmals mit Echtdaten, Modbus-Sim in hexadecimal, decimal und integer wie von dir gewünscht.

      pdf-Dokument ist leider auf 3 Seiten verteilt, da nicht anders möglich.

      Danke im Voraus.


      LG




      Karl
      Files
      • 12

      • # 164366
      Hallo Karl,

      ich bin auch der Meinung, dass es ein Adressenproblem ist.

      Wenn ich die Adressen der Register von deinen Echtdaten in hexadezimal anschaue, dann siehst sofort,
      dass die Adressen der 3 uint64 Register (41000, 41004, 41008) um +1 erhöht werden müssen im Modbus-Eingang vom CMI.

      41000 41003 4 RW 0x03 0x10 Energy from grid uint64 Wh --> im CMI modbus input Adresse 41001 eingeben
      41004 41007 4 RW 0x03 0x10 Energy into grid uint64 Wh --> im CMI modbus input Adresse 41005 eingeben
      41008 41011 4 RW 0x03 0x10 Energy Smartfox uint64 Wh --> im CMI modbus input Adresse 41009 eingeben

      Ich habe die Werte der 3 uint64 Register Echtdaten bei mir im iobroker eingegeben und dann erschienen die korrekten Werte sofort im CMI-Eingang.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 13

      • # 165086
      Hallo Karl,

      bist inzwischen weitergekommen? Kannst mit dem CMI inzwischen alle Daten von deinem Smartfox-Pro über Modbus-TCP einlesen?

      Ich bin es gewöhnt, dass keine Antwort eine gute Antwort ist.
      Dieses Verhalten ist in grossen Firmen durchaus an der Tagesordnung, heisst aber noch lange nicht dass ich es gut finde.

      Zum Thema deiner mail, Raspberry Pi Passwort vergessen, gibts natürlich auch eine Lösung:

      Entnehmen Sie zuerst die SD-Karte aus Ihrem Raspberry Pi und legen Sie diese anschließend in einen Kartenleser ein.
      Auf dem angeschlossenen Computer sollten Sie nun auf dem Datenträger einen Ordner namens „boot“ finden.
      Öffnen Sie die Datei „cmdline.txt“. Dazu dürfen Sie nicht den Standard-Editor nutzen, sondern müssen einen umfangreicheren Text-Editor installiert haben.
      Am Ende der ersten Zeile fügen Sie folgenden Teil ein: „init=/bin/sh“. Achten Sie darauf, dass diese Passage nicht in einer eigenen Zeile steht.
      Legen Sie nun die SD-Karte erneut in Ihren Raspberry Pi ein und starten Sie diesen.
      Geben Sie die Befehle „mount – o remount, rw /“ und anschließend „passwd pi“ ein.
      Nun können Sie in neues Passwort festlegen.
      Schließen Sie den Vorgang mit den Befehlen „sync“ und „exec /sbin/init“ ab.

      Den Raspi kann man auch so configuriern, daß er ohne Passwortabfrage hochfährt. Ist in manchen Fällen sinnvoll, aber das muss jeder für sich selbst entscheiden.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 14

      • # 165097
      Hallo Jürgen,

      bin gerade vor ca. 1 Stunde wider einen wesentlichen Schritt weiter gekommen und habe einige Aufgaben gelöst.

      Ich kommuniziere Lösungen auch im Beruf (Rechnungswesen/Steuern/Controlling) erst dann, wenn ich ein halbwegs brauchbares Ergebnis habe.

      Habe Anfang letzte Woche eine lange Fehlerliste und Fragen an DAFI gesandt und mir wurde per Mail mitgeteilt, dass im Jänner 2020 ein neues Update-V1.39 für den Smartfox-Pro kommt und
      hier die Registerwerte Type: uint64 auf 2 uint32 aufgeteilt werden, damit der Smartfox-Pro die Registerwerte korrekt auslesen kann.

      Habe heute einen neuerlichen Versuch gestartet und siehe da, offenbar arbeiten die schon meine Liste der Programmierfehler ab. -

      Siehe jetzt korrekter cos-phi. War vor kurzem noch von L1-L3 gleich. Ist jetzt korrekt.

      Interessanterweise bekomme ich jetzt auch die kumul. Werte Bezug. Einsp., SF-Heizstab. Siehe Schema.

      Das Problem ist nur, dass man über CMI maximal eine Zahl bis 32768 (8 hoch 4) übertragen kann. 1 Byte hat 8 Bit. Lt. tel. Info Technische Alternative heute Morgen.

      D. h. man muss eine Zahl größer 32768 zuerst herunterskalieren (z. B. Faktor 0,01 und dimensionslos-1). Der Nachteil ist, dass man an Genauigkeit verliert.

      Das Problem ist nicht der Modbus TCP-Eingang und der CAN-Ausgang, sondern anschließend der CAN-Eingang lt. Info TA.

      Beispiel: PV-Erträge aktueller kumulierter Stand seit 12/2012 44.882 kWh, anzeigen kann ich nur in ganzen 10er Zahlen sprich 44.880 lassen, wegen Begrenzung beim Übertrag von CAN-Ausgang auf CAN-Eingang.
      Anschließend muss man die herunterskalierte Zahl wieder mit einer Mathematikfunktion (Faktor) hochskalieren.
      Faktor 0,0001, dimenstionslos-1 und anschließend Faktor 10.

      Es fehlen jetzt nur noch Bezug u. Einspeisung je Tag, kumuliert passt mittlerweile. Aber die ausgelesenen Registerwerte für TAG-Bezug u. TAG-Einspeisung sind meines Erachtens immer noch Programmierfehler,
      da die ausgelesenen Werte mit der direkten Json-Abfrage nicht übereinsimmen.

      Werde Euch auf dem Laufenden halten, sobald ich auch die restlichen 2 Punkte geklärt habe, Bezug-TAG, Einspeisung-TAG.

      Vielen Dank Jürgen für die aktive Unterstützung und vor allem auch für den Tipp mit dem Raspi.


      LG



      Karl
      Files
      • 15

      • # 165181
      Hallo Jürgen,

      ich habe mal Schritt 1 und 2 bezüglich Passwort-Reparatur gemacht.

      Nur kann ich den Befehl: "mount - o remount, rw" bei Verbindung zum Raspi mit Putty nicht eingeben.

      Ist es richtig, dass nur der Text einzugeben ist oder auch die Gänsefüßchen ?

      Danke für die Info.

      Habe heute eine Mail vom Programmierer von DAFI bezüglich Registerwerte Modbus TCP/IP für Bezug-Tag und Einspeisung-Tag bekommen, dass dies ein Programmierfehler ist.
      Wird umgehend korrigiert.


      LG


      Karl
      Files
      • 16

      • # 165193
      Hallo Karl,

      alles richtig,
      diese Reparaturmaßnahme geht nur auf der root-console, also direkt am Raspi und nicht remote.
      Mit putty kommst nicht ohne Anmeldung auf die console.
      Hab selber noch kein Problem damit gehabt..nur gegoogelt, und mindestens 10 mal denselben Tip, dann sollte es auch funktionieren.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 17

      • # 165443

      New

      Hallo Karl - Jürgen

      Wie ich das recht verstehe kann man über den CMI über Lan und einen entsprechenden Gerät (Raspi, Smartfux) entsprechende Mod Bus Signale auslesen.
      Da ja das CMI keine direkte Mod Busschnittstelle verfügt.

      Habe heute mir heute einen CAN BC2 bestellt um meine 2 Can Busleitungen über die 2 CMI zu verbinden ,dieser verfügt über eine Mod Bus Schnittstelle (Master) und es direkt Mod Bussignale eingelesen werden .
      Pro BC2 können 4 M Buszähler (Sklaves) paraell angeschlossen werden ,die dann je 32 Werte je Buskonverter auslesen können.

      Bin ja schon gespannt wie das gesamt System dann funktioniert .

      mfg Glutgeist
      Die wichtigste Erfindung der Menschheit ist:
      Bleistift und Papier

      v.T.A.Edison
      • 18

      • # 165454

      New

      Hallo Ludwig,

      ich habe beim CMI die ModBus/TCP-Schnittstelle gewählt, weil es für mich die einfachste Möglichkeit ist, Daten in das CMI,
      und an die angeschlossenen Geräte reinzubekommen.
      Viele Wege führen nach Rom. Natürlich gibt es noch andere Wege, so wie du es realisiert hast z.B. mit CAN BC2.

      Mir ist aufgefallen, dass das CMI nur eine Modbus/TCP-Server zu Modbus/TCP-Server Verbindung aufbauen kann.
      Mit einem Modbus/TCP-Client bin ich nicht direkt ins CMI reingekommen.

      Deshalb habe ich dann den Umweg über einen Hilfs-Server(diagslave) auf dem Raspi verwendet, der eine Server(master) zu Server(slave) Verbindung aufbauen kann.
      An den Hilfs-Server(diagslave) kann ich dann wieder alles mögliche anschliessen,
      wie einen weiteren Modbus/TCP-Server(iobroker) oder viele Modbus/TCP-Clients(python-scripte), mehr brauche ich nicht.

      Was mir besonders daran gefällt, ist dass ich über die 64 Modbus-Register im CMI auch Daten zu und von den den alten Geräten, wie CAN-IO44 und UVR1611
      übertragen kann, also alte und neue Geräte über Modbus/TCP mit der Aussenwelt verbinden kann. Diese Abwärtskompatibilität muss man TA
      sehr hoch anrechnen, denn viele andere Firmen lassen die alten Produkte sterben und man wird manchmal gezwungen sich neue Geräte anzuschaffen.

      Gruß
      Jürgen
      Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44 und BL-NET,CMI ;
      2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; PV 3,2kW; Wasserenthärtung
      • 19

      • # 165618

      New

      Hallo Jürgen, hallo Ludwig,

      der Programmierer von DAFI hat jetzt doch relativ rasch auch die letzten beiden Registeradressen richtiggestellt.
      Damit habe ich auch korrekte Tageswerte von Bezug und Einspeisung vom Smartfox-Pro über Modbus TCPIP und CMI im Schema.

      Jürgen Danke nochmals für deine Unterstützung.


      LG



      Karl
      Files

    Webutation