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

Es gibt 117 Antworten in diesem Thema, welches 57.430 mal aufgerufen wurde. Der letzte Beitrag () ist von GOETSCHHOFER.

  • Hallo,


    bin neu hier als aktiver Nutzer. Bisher habe ich das Forum nur passiv genutzt. Komme aber mit der UVR16x2 und Modbus nicht weiter.

    Jede Hilfe wäre der Hit!


    Ausgangslage: PV-Überschuss wird im ioBroker auf Raspberry 4 ermittelt und soll von dort via ModbusSlave-Adapter an das C.M.I. übertragen werden.

    Ich bekomme lt. ioBroker-Adapter eine Verbindung, allerdings wird der Wert im C.M.I nur einmal eingelesen und ändert sich dann nicht mehr.

    Kann hier jemand helfen?

    Hier die Screenshots der Konfiguration auf beiden Seiten. Weil ich mir nicht sicher bin, habe ich sowohl eine Größe auf dem Holding Register als auch am Input-Register angelegt und mit derselben Variable (Counter) aus ioBroker befüllt.


    Bin für jeden Hinweis dankbar!!!


    Sonnige Grüße in düsteren Zeiten


    Matthias

  • Hallo Matthias,


    habe deinen Beitrag erst jetzt gelesen.

    Anbei meine Einstellungen und die dazugehörigen Screenshots.

    Ich lese testweise die Außentemperatur vom iobroker in das CMI-Modbus-TCP-Eingang aus, welche ich vorher mit dem CMI über Modbus-TCP-Ausgang an den iobroker gesandt habe.



    Sonnige Grüße



    Karl


  • Hallo Karl,


    danke für die Rückmeldung. Mein ioBroker hat sich komplett verabschiedet. Daher konnte ich erst jetzt nochmals testen... leider ohne Erfolg. Bin echt mit meinem Latein am Ende. Die Einstellungen müssten passen.


    Ich sende die Raumtemperatur vom CMI an den IOBroker und den PV-Überschuss vom ioBroker an das CMI... leider kommt da nach wie vor nichts an (0).


    Das Empfangen der übersschüssigen PV-Leistung wird einmalig empfangen, dann aber am CMI nicht mehr aktualisiert...


    :(


    Bin echt am Verzweifeln... Hier noch ein die Infos zu meinen Einstellungen.


    Bin für JEDEN Hinweis Dankbar!


    Sonnige Grüße


    Matthias


  • Hallo Matthias,


    schalte mal den Debug/Info Modus beim Modbus Adapter ein, dann siehst du in den Protokollen, was wer macht.


    LG



    Karl


      

  • Hallo Karl,


    super, tausend Dank für den Tipp.

    Leider sieht das bei mir nicht so aus wie bei Dir (siehe unten)...


    Hast zufällig noch eine Idee? Muss ja dann schon am ioBroker liegen...

    Am CMI kommt nach Reset einmalig ein Wert vom ioBroker an. Der Wert vom CMI wird aber kein einziges Mal eingelesen...


    Ich habe echt schon viel in ioBroker und mit den Produkten der TA umgesetzt, aber das Thema kostet mich den letzten Nerv...


    Jeder Input hochwillkommen!


    Viele Grüße


    Matthias


  • Hallo Karl,


    was mir gerade noch einfällt: Kann es sein, dass andere Geräte am selben Netzwerk hier Ärger machen? Es hängt noch die PV-Anlage incl. Batterie und die OpenWB Wallbox im selben TCP-Netzwerk und nutzen Modbus...


    Habe gerade nochmals allerlei Einstellungen geprüft und geändert... leider ohne Erfolg :(


    Viele Grüße und Danke für jeden Tipp


    Matthias

  • Die Lösung ist eine Umgestaltung des Skripts. Schreibt dieses (in Blockly nicht sichtbar, aber in Javascript) die Werte mit dem Attribut true, so wird nur einmalig ein Wert an das CMI übergeben. Mit false klappt es dann problemlos!

  • Hallo,


    alle meine Geräte mit Modbus-Schnittstelle, wie Victron-Cerbo oder Victron-Venusgx usw. funktionieren fehlerfrei, nur die CMI Modbus-Schnittstelle zickt rum.

    Aus dieser Problematik der Modbus-Direktverbindungen zum CMI und vielen Experimenten kam dieser Thread zustande.


    In diesem Thread versuche ich eine von vielen Alternativ-Lösungen ohne Direktverbindung ( CMI--> IoBroker ) zu beschreiben und mit Erfahrungswerten anzureichern,

    weil bei mir und vielen anderen die Direktverbindung vom CMI zum IoBroker garnicht oder sehr unzuverlässig funktioniert.


    Warum das mit der Modbus-Direktverbindung zum CMI nicht 100%ig funktioniert, kann nur TA selber erklären, denn die Modbus-Schnittstelle im CMI ist proprietär (herstellerspezifisch).

    Der Einsatz proprietärer Schnittstellen führt häufig zu weniger "Reibungsverlusten" aus Sicht des Herstellers.

    Gründe gibt es viele: Man will fremde Produkte vom eigenen System fernhalten, denn TA erweitert seit Jahren die eigene Produktpalette mit neuen Geräten und Ideen.


    Dabei nimmt das Datenvolumen auf dem CAN-Bus, dem Hauptbus (Backbone) immer mehr zu. Man kann aber nur in einem TA-System mit neuen x2-Geräten die Can-Bus-Geschwindigkeit von 50kbit/s auf 500kbit/s

    erhöhen um den Datendurchsatz des Gesamtsystems zu verbessern. Verständlicherweise stören da alle fremden Datenquellen die über den Modbus von externen Systemen reinkommen.

    Ein echtes Nadelöhr ist nunmal die Modbus-Schnittstelle im CMI, denn nur über diesen Weg können fremde Daten von Aussen übers CMI ins TA-System überhaupt erst reinkommen.


    Viele TA-System-User sind dabei ein eigenes Energiemanagement-Sytem aufzubauen. Das besteht nunmal aus vielen einzelnen Systemen die man z.B. bei TA über die Modbus-Schnittstelle verheiraten muss.

    Da kommt eine Wallbox vom E-Auto dazu, da kommt ein Wechselrichter dazu, da kommt ein Heizstab für PV-Überschuss dazu, oder eine Wärmepumpe, oder ein Energie-Zähler

    oder eine Steuerung zur Null-Einspeisung usw.

    Verhindern kann man diesen Fortschritt nicht, aber ausbremsen mit einer herstellerspezifischen Modbus-Schnittstellenverarbeitung sehr wohl.

    Zu erwähnen wären da Blockzeiten, Timeoutzeiten, Prioritäten und schwankende Antwortzeiten von 2 Sekunden bis zu einigen Minuten über Modbus-Schnittstelle beim CMI.


    Das bremst natürlich die Euphorie und die Motivation mit TA-Produkten sowas komplexes aufzubauen.

    Immer unter der Prämisse es gibt sowas überhaupt nicht fertig zu kaufen.

    Deshalb muss man entweder warten bis es genausowas Fertiges gibt, dann wieder warten auf Firmware-Verbesserungen bis alles richtig läuft

    oder halt selber machen und gemeinsam Lösungen zu finden oder zu erarbeiten, und ein skalierbares Energiemanagement-System selber nach eigenen Vorstellungen aufbauen.


    Und genau deshalb sind Foren wichtig, um Erfahrungen, Ideen und Wissen (Schwarmwissen) auszutauschen.


    Meine Forschungen sind nur ein ganz kleiner Beitrag zu dem Gesamtsystem

    und beschreiben einen Verbindungsweg vom IoBroker zum CMI über einen Hilfs-Server (CMI --> diagslave --> iobroker), also keine Direktverbindung!!


    Modbus-Master-Server-CMI <--> Modbus-Slave-Server-diagslave <--> Modbus-Master-Server-iobroker

    ................................................................................................................<--> Modbus-Master-Server-NodeRed

    ................................................................................................................<--> Modbus-Client-python-Script


    bild1 Modbus-Canbus Datenfluss von meinem Modbus-CMI Stresstest


    Mit einem Modbus/TCP-Slave Server z.B. ("diagslave"), der separat läuft, lässt sich z.B eine UVR16xx, RSM610, UVR610x oder CANIOxx über CMI über Modbus/TCP übers Netzwerk mit der Aussenwelt verbinden.


    Mein Test-Scenario um Modbusverbindungen von und zu einem CMI intensiv zu untersuchen und auszutesten:

    Mit einem einfachen ping wie im Netzwerk oder ping-pong von Daten von einem python-Script über diagslave zum CMI und wieder zurück und dabei die gemessene Laufzeit in einer Datei protokolliert,

    habe ich einen Stress-Test mit einem python-Script aufgebaut.


    Ich könnte das ganze auch mit mehreren Raspis aufbauen Raspi1 für diagslave-Slave-server, Raspi2 für iobroker-Master-server usw.

    Weil ich inzwischen mit meinem kleinen Intel-NUC Mini-PC mit Proxmox-VM sehr zufrieden bin, habe ich für diesen Testaufbau meine Proxmox-VM Umgebung verwendet.


    ...

    Auszug vom python-Script:

    if c.is_open():

    print("is open --> to connect to "+SERVER_HOST+":"+str(SERVER_PORT))

    if c.write_single_register(111, xwert):

    print(" write ok ")

    else:

    print(" write error")


    regs = c.read_holding_registers(110, 4)

    if regs:

    print(sfi+" reg ad #110-111: "+str(regs))

    afzeile = sfi+" reg ad #110-111: "+str(regs)+"\n"

    fout=open(fn,"a+")

    fout.write(afzeile)

    fout.close()


    # sleep 2s before next polling

    xwert = xwert+2

    time.sleep(2)

    ...

    Auszug terminal-Ausgabe vom python-Script:

    is open --> to connect to 192.168.15.194:502

    Tx

    [AC A6 00 00 00 06 01] 06 00 6F 00 F0

    Rx

    [AC A6 00 00 00 06 01] 06 00 6F 00 F0

    write ok

    Tx

    [75 04 00 00 00 06 01] 03 00 6F 00 04

    Rx

    [75 04 00 00 00 0B 01] 03 08 00 F0 00 00 00 E6 00 00

    17:09:31 reg ad #110-111: [240, 0, 230, 0]-----------wert1 240 wurde 17:09:31 gesendet ins Holding-Register 111

    is open --> to connect to 192.168.15.194:502

    Tx

    [A6 84 00 00 00 06 01] 06 00 6F 00 F2

    Rx

    [A6 84 00 00 00 06 01] 06 00 6F 00 F2

    write ok

    Tx

    [0C 8D 00 00 00 06 01] 03 00 6F 00 04

    Rx

    [0C 8D 00 00 00 0B 01] 03 08 00 F2 00 00 00 F0 00 00

    17:09:33 reg ad #110-111: [242, 0, 240, 0]-----------wert2 240 wurde 17:09:33 empfangen vom Holding Register 110

    is open --> to connect to 192.168.15.194:502

    Tx

    [78 86 00 00 00 06 01] 06 00 6F 00 F4

    Rx

    [78 86 00 00 00 06 01] 06 00 6F 00 F4

    write ok

    Tx

    [D8 65 00 00 00 06 01] 03 00 6F 00 04

    Rx

    [D8 65 00 00 00 0B 01] 03 08 00 F4 00 00 00 F0 00 00

    17:09:35 reg ad #110-111: [244, 0, 240, 0]

    ...



    Hierbei wird alle zwei Sekunden ein neuer Wert (in einer Schleife hochgezählt) ins Modbus-Register 111 vom diagslave geschrieben

    und automatisch über Modbus/TCP zum CMI mit der Funktion (03-read holding register) ins Modbus-Eingangs-Register 111 zum CMI übertragen.


    Intern im CMI vom TA-System gehts dann vom Modbus-Eingangsregister 111 vom Modbus über den CAN-Bus Ausgang1 auf den CAN-Bus im CMI (Knoten56).


    Das über Can-Bus angebundene UVR610S-Gerät (Knoten32) nimmt den Wert über CAN-Bus Eingang1 vom CAN-Bus herunter

    und übertragt den Analog-Wert vom CAN-Bus Eingang1 im UVR610S mit einer AnalogFunktion-MaxWert direkt

    wieder über einen CAN-Bus Ausgang2 vom UVR610S (Knoten32) zurück auf den CAN-Bus für den Rückweg.


    Parallel dazu wird im UVR610S mit einer Garadienten-Funktion die Wert-Änderung (positive Flanke) erkannt und ein Timer angestossen der den UVR-Ausgang3 ca. 3 Sekunden einschaltet.

    Das dient zur Kontrolle (optisch und akustisch), wann eine Wertänderung in der UVR610S angekommen ist und der genaue übertragene Wert wird auch im Display der UVR610S angezeigt.

    Die Garadienten-Funktion und den Timer mit Ausgang3 kann man auch weglassen, damit der laufende Betrieb nicht gestört wird.

    Ist bei mir aber optional möglich, da Ausgang3 nicht belegt war.


    bild2 uvr-programm


    Dann gehts wieder rückwärts über den CAN-Bus zum CMI (Knoten 56) und wird dort mit einem CAN-Bus Eingang vom CAN-Bus herunter genommen.

    Dann gehts im CMI vom CAN-Bus Eingang mit der Funktion (06-preset single register) zum Modbus Ausgang ins Register 110 und per Modbus/Tcp übers Netzwerk zum diagslave zurück ins Register 110.


    Von dort werden ja alle 2 Sekunden die Register 110 und 111 im python-Script ausgelesen und alle 2 Sekunden eine Ergebniszeile

    in eine Datei fortlaufend protokolliert.


    bild3 Anzeige von UVR610-Steuerung



    Im Netzwerk hängt noch ein iobroker und NodeRed, die lesen natürlich auch automatisch die beiden Register 110 und 111 mit und zeigen die gleichen Ergebnisse wie im python-Script und im UVR610S-Display an.

    Den gleichen Stress-Test kann man auch im iobroker mit einem Blockly-Script oder mit einem Javascript-Script ausführen.



    bild4 blockly script



    Wenn man später die aufgezeichnete Datei mit den gespeicherten Ergebniszeilen von Register 110 und 111 anschaut,

    wird man sehen, dass die Antwortzeiten im Bereich zwischen 2 Sekunden und mehreren Minuten schwanken.


    Zeitkritische Steuerungsaufgaben werden über Modbus-Kommunikation etwas schwieriger zu realisieren sein.

    Fehlende zeitkritische Informationen müssen dann mehr simuliert (kompensiert) werden, wie z.B. beim PID-Regler usw.

    Aber bei Temperaturwerten für Heizungs- oder Solarsteuerungen wird es wohl nicht auf die Sekunde ankommen.


    Das UVR610S-MODB Gerät hat zusätzlich eine Modbus-RTU485 Draht-Schnittstelle. Darüber sind die Verarbeitungszeiten und Antwortzeiten auch unterschiedlich wie bei Modbus/Tcp übers Netzwerk.


    Gruß

    Jürgen

  • Hallo Jürgen,


    besten Dank nochmals, dass du uns hier an deinem Expertenwissen teilhaben lässt, ist schon eine ausgefeilte Sache, welche du hier umgesetzt hast.


    Weiß jemand, wann nun endlich das neue CMI von TA kommt um hier einen wesentlichen Fortschritt im Bereich Home-Automatisierung und vor allem Home-Visualisierung umsetzen zu können ?



    Sonnige Grüße




    Karl

  • Hallo Karl


    folgende Info hatte ich zum Nachfolger eingestellt:


    Hallo an alle, die auf den Nachfolger des CMI´s im Frühjahr 2022 hoffen:


    Ich habe den Newsletter von TA bekommen.

    Da wurde ich um ein Feedback gebeten.

    Das habe ich getan und gleich den Kontakt zu TA genutzt, um Infos über den Nachfolger des CMI´s zu bekommen.


    Es ist ein Nachfolger geplant, er wird nicht im neuen Katalog (März 2022) sein und 2023 kann auch nicht sicher zugesagt werden.

    Von wegen Chipmangel und was ansonsten noch alles passieren kann.



    Da müssen wir also leider noch warten.

    Ich habe mir deshalb 2 x UVR610 Modbus gekauft, denn mit der Modbus Schnittstelle vom CMI lief meine Kommunikation gar nicht konstant !!!


    mfg Cord

  • Hallo Jürgen


    Respekt für deinen Testaufbau und Ausführungen. :!:


    Wenn ich lese: 2 Sek bis mehrere Minuten wird mir bei meiner Projektumsetzung einiges klar. =O


    Fakt ist an dieser Schnittstelle muss TA wirklich ganz erheblich nachbessern .


    angenehmen Wochenstart .... mfg Cord


  • Hallo


    Ich habe ja eine UVR610 Modbus und lese je 10 Werte aus insgesamt 2 Growatt Wechselrichter aus.

    Einige Werte werden nur alle 10 Sekunden "gezogen", andere alle 2 Sekunden.


    In meiner Winsol Aufzeichnung musste ich nun feststellen, dass 15 Min lang die PV Leistung vom Growatt 2 nicht übertragen wurde.

    Damit kann ich meine Nulleinspeisung nicht realisieren. :(


    Habe es dann auch nochmal direkt an den Modbus Eingängen überprüft und ständig mit F5 aktualisiert.

    Nach 2 Min ohne Änderung sollte klar sein, das es nicht an Winsol /Canbus liegt.


    Insgesamt 20 Werte ...von 2 Teilnehmern, das sollte doch mit 9600 kbit funktionieren ...


    Gibt es sonst noch einen Trick 17 um die Performance zu verbessern ?

    mit 38.400 kbit probieren ? aber ich kann mir nicht vorstellen das die Geschwindigkeit das Problem sein soll ....


    PS: In der UVR610 Modbus passiert ansonsten nichts ...

    Nur Modbuseingänge einlesen und dem Canbus übergeben

    Die je 2 Modbusausgänge sind momentan deaktiviert, da ich den Growatt noch davon überzeugen muss auf meine Nulleinspeisung zu reagieren.


    mfg Cord

  • hier mal eine Aufzeichnung:


    blau die Spannung vom Growatt 1

    schwarz ist die Leistung vom Growatt 1

    ocker die Spannung vom Growatt 2

    grün die Leistung vom Growatt 2


    da kommt ganz lange keine Änderung ....

  • Hallo,


    damit würde ich mal direkt mit TA in Verbindung setzten.

    Sonnige Grüße Reiner

    ETA BK 15 mit Saugzuggebläse und Lambdasonde geregelt mit UVR16x2

    3 X 800 l PS zwei mit Solarwendel und 14 m2 FK mit einem CTC 265 EM als

    Backup und LUVANO 10kW geregelt mit zwei UVR16x2, UVR610 mit CAN-I/O45

    CAN-MTx2 und CMI für eine DHH mit Anbau und 110m2 Heizfläche

  • Hallo Cord,


    ja mit deinen Beobachtungen bist am CMI zu ähnlichen Ergebnissen gekommen beim Aufzeichnen von Werten mit WINSOL.


    Hab mir nochmal Gedanken gemacht und einen neuen Stresstest speziell für das UVR610S-MODB Gerät aufgebaut.

    Mein Datensender/Empfänger ist wieder ein python-script, anstelle von einem Wechselrichter.


    Das UVR610S-MODB Gerät hat eine Modbus-RTU485 2-Draht-Schnittstelle.

    Diesmal starte ich mit den Eingaben auf dem 2-Draht-Bus, dem RS485-RTU-Modbus.


    Von dort gehts ja direkt zu den Modbus-Ein/Ausgängen und dann gleich ins UVR-Programm rein.

    Dieser Weg ist im Datenfluss wesentlich kürzer, denn es entfällt der CAN-Bus-Übergang.


    Hierbei wird wieder alle zwei Sekunden ein neuer Wert (in einer Schleife hochgezählt) ins Modbus-Register 3 vom diagslave geschrieben und automatisch über RS485-RTU-Modbus mit der Funktion (03-read holding register) ins Modbus-Eingangs-Register 3 vom UVR610S-MODB übertragen.


    Dann ins UVR-Programm vom UVR610S mit einer AnalogFunktion-MaxWert direkt

    wieder zurück ins Modbus-Ausgangs-Register 4 geschickt für den Rückweg.


    Mit der Funktion (06-preset single register) vom Modbus Ausgang4 über 2-Draht-Bus, RS485-RTU-Modbus zum diagslave zurück ins Register 4. Dort werden ja alle 2 Sekunden die Register 3 und 4 mit dem python-Script ausgelesen.


    bild 1 UVR610S-MODB-Test-Programm


    Wenn man im python-script die Ergebniszeilen von Register 3 und 4 anschaut, oder den Schalt-Ausgang4 im UVR610S-MODB Gerät beobachtet oder Relais ein/aus hört, wird man sehen, dass die Antwortzeiten fast alle im Bereich bei 2 Sekunden liegen, also fast ohne Verzögerung und ganz wenige mehrere Sekunden (timeout) brauchen.


    Also der Weg über 2-Draht-Bus, RS485-RTU-Modbus zum UVR610S-MODB Gerät ist der performante Weg und läuft superschnell.


    Zeitkritische Steuerungsaufgaben können also im UVR-Programm vom UVR610S-MODB Gerät durchaus realisiert werden.

    Wer hätte das gedacht, dass das kleine UVR610S-MODB Gerät so ein Modbus-Renner ist.


    Also Cord, wenn deine Nulleinspeisung im UVR610S-MODB Gerät programmierst, dann sollte es klappen.

    Mit deinem Gespür und den Erfahrungen mit Steuerungen hast ja mit dem 2-Drahtanschluss, RS485-RTU-Modbus den richtigen Anschlussweg gewählt.


    Der weitere Weg der Daten vom UVR610S-MODB über CAN-Bus zum CMI und WINSOL oder über CAN-Bus zu einem anderen Gerät wie UVR16x2 dauert manchmal etwas länger.


    Gruß

    Jürgen

    Dateien

    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

  • Hallo Jürgen,


    meine Frage passt zwar nicht in diesen Thread und ich wollte deswegen nicht einen eigenen Thread aufmachen, aber ich bin überzeugt, dass du mir diese Frage rasch beantworten kannst.


    Da ich nach 10 Jahren meinen WR Kostal Piko-5.5, wegen Fehlermeldung Fehlerstrom0315 in einen Fronius Gen24-6.0 tauschen musste, habe ich auch die Bezeichnung im Modbus.0 Adapter im Holdingregister im iobroker geändert.

    Das Ergebnis ist, dass er mir das bis dato existierende Objekt jetzt nicht mehr anzeigt.

    Was habe ich hier falsch gemacht ?


    Habe jetzt wieder die alte Bezeichnung vom WR-Kostal eingetragen, aber hilft auch nichts mehr, das alte Objekt erscheint nicht mehr.


    Vielen Dank für die Hilfe.


    Sonnige Grüße



    Karl



  • Hallo Jürgen,


    vielen Dank.


    Mein Problem hat sich gelöst, ich habe im iobroker rechts oben einen Filter (InfluxDb) eingestellt gehabt, damit hat er mir nur einen Teil der Objekte angezeigt.


    LG



    Karl

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!