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 Karl,


    danke für dein "Mut machen".

    Ich finde das CMI:= {TCP.Master(=Modbus.Client)} und Raspi:= {TCP.Slave(=Modbus.Server)} ziemlich verwirrend!


    Es stellt sich mir die Frage, warum ich den Raspi nicht gleich als TCP.Slave einrichten und dann als Modbus.Server direkt mit dem CMI kommunizieren/arbeiten lassen kann. Wenn sowohl CMI als auch Raspi (nur) TCP.master sein können braucht es natürlich ein Koppelglied (:= Brücke) zwischen den beiden.


    Grundsätzlich finde ich es ärgerlich dass TA seine Schnittstellen so "ungenau" veröffentlicht, dass Leute wie du bzw. Jürgen sich einen abbrechen müssen, um das Ganz zum Laufen zu bringen. So gut mir im Moment die UVR gefällt - ist das vielleicht auf lange Sicht der falsche Weg .... mal sehen....


    Zur Vorgeschichte:

    Da Ferienhaus steht in Österreich wurde 1978 von meinem Vater gebaut. Es wird ausschließlich von Familienmitgliedern genutzt. Seit dem Tod meines Vaters betreue ich das Haus im Auftrag meiner inzwischen neunzigjährigen Mutter.
    In 2020 sollte die alte Heizung saniert und auf ein System mit regenerativer Energiequelle (Pellets oder Wärmepumpe) + Solarthermie umgebaut werden. Der Heizungsbauer hatte eine eine Erdwärmepumpe vorgeschlagen. Die Solarthermie wollte ich selbst aufbauen (hatte vor 15 Jahren eine Fortbildung zum Solarteur) und den Umbau der Heizung durch den Fachbetrieb ausführen lassen.
    Leider hat der Heizungsbauer nach der Lieferung diverser Komponenten (Kollektoren, Solar-Pumpenmodul, Solarleitung + 1000l Link3-Pufferspeicher) im Herbst 2019 die Segel wg. Überlastung gestreckt und die Montage auf unbestimmt verschoben.

    Und dann kam Covid.

    Die Montage der Solarkollektoren habe ich im Sommer 2020 selbst ausgeführt und die gewonnenen Wärme (erst einmal provisorisch) über einen Plattenwärmetauscher in das Heizungssystem eingespeist.

    Um das Verhalten des Systems aus der Ferne verfolgen zu können habe ich einen Raspi3 dafür eingerichtet (OpenVPN, Python-Script, div. DS18B20)
    Mit einigem Erstaunen stellte ich fest dass dort ein Einrohr-HeizungsSystem vorliegt und dieses auch noch extrem ungünstig/falsch aufgebaut wurde: es fehlen die Drosseln bei den jeweiligen Heizkörperanbindungen. So wird erst ab einem VL von min. 20°K über der Raumtemperatur überhaupt eine Heizwirkung messbar und die RL-Temperatur beträgt meistens nur ca. 3-4 °K weniger als die VL-Temperatur. Außerdem ist die Installation so ungünstig verlegt, dass man zur Abänderung auf ein Zweirohrsystem die Fußböden fast vollständig herausreißen müsste.


    Die Solaranlage hat bis heute sinnvoll funktioniert und geholfen, dass die Haustemperatur bei ausgeschaltetem Ölkessel von Oktober 2020 bis Mai 2021 (wg. Covid unbewohnt) nie unter 12°C gesunken ist. Da auch in 2021 der Heizungsinstallateur nicht zur Verfügung stand (Covid) habe ich im August 2021 den Kessel an seine neue Stelle umgezogen, die Installation im Heizraum für den Pufferspeicher + UVR umgebaut und das Ganze in Betrieb genommen. (Wurde vom Kaminkehrer inzwischen abgenommen).


    Dabei habe ich folgende Ergänzungen zur Verbesserung der Einrohrheizung vorgenommen:
    die Heizkreise EG und KG können nun wahlweise einzeln / parallel (wie bisher)/ oder in Reihe geschalten werden (=> das RL-Delta steigt auf ca 6-8°K)
    Die Richtung der Durchstömung kann umgedreht werden ( statt der Wohnräume werden erst die innen liegenden Bäder beheizt)

    Beides hat sich als wirkungsvoll herausgestellt.


    Erst habe ich versucht, die Messstellen soweit zu reduzieren, dass ich mit den 16 UVR-Eingängen zurecht komme. Leider hat sich das nicht als ausreichend zur Beurteilung der Situation im Haus erwiesen. Insbesondere benötige ich 4 weitere TempEingäng für den Pufferspeicher.


    Um nicht ständig auf mehreren Geräten die Auswertungen fahren zu müssen und auch damit ich die Anlage bald auf die zukünftigen Eigentümer (Enkel meiner Mutter - ich bin inzwischen 67! ) übertragen zu können wollte ich die unterschiedlichen Erfassungs- und Ansteuerungssysteme zusammenführen. Dazu sollte das Ganze möglichst wenig "gebastelt" (Eigenbau) bzw. für Andere gut nachvollziehbar(reparierbar) sein.


    Ob in diesem Sinn die Koppelung UVR <=> Raspi sinnvoll ist oder dann zu kompliziert wird muss ich erst noch für mich herausfinden....
    .. oder doch alles rein mit TA-Komponenten realisieren.


    Vermutlich werde ich (jetzt) ein "AI5-DL" für die Sensoren am Pufferspeicher besorgen und dann (in Ruhe und großer Neugierde) mich der Verbindung zum Raspi widmen. Auch der Frage, ob eine direkte Kommunikation über CAN besser /eifacher wäre.


    ist nun doch ne Menge Text geworden - sorry
    solong ... euch einen schönen Sonntag

    ein grübelnder Stefan

  • Hallo Stefan,


    ja, verwirrend ist es nur am Anfang, aber da musst du durch.

    Man muss hier schon festhalten, dass wir uns ab CMI Richtung Modbus TCP/IP hier bereits im Bereich der Netzwerktechnik befinden und natürlich als Laien, wie ich und du gerade am Anfang ein hartes Brot ist.

    Du kannst auf einem RSP oder IntelNUC schon Master oder Slave verwenden, nur dann musst du am RSP iobroker installieren, anschließend den Modbus Adapter und hier kannst du unbegrenzt viele Slave direkt mit dem CMI kommunizieren lassen.

    Mit dem iobroker sind wir aber schon wieder eine Ebene tiefer (Smarthome).


    Das CMI gibt es seit ca. 2016 und hat glaube ich sicherlich seinen Zweck erfüllt, aber stoßt halt leider, wie auch Jürgen treffend festgestellt hat, mittlerweile auch an seine Grenzen.

    Vor allem, wenn es in Richtung Smarthome geht. Dafür wurde es ja auch nicht konzipiert.

    Ich kenne keine Firma im Bereich der Heizungstechnik, welche um Euro 210,-- einen Fernzugang, eine App u. ein Visualisierungsprogramm auf die Heizungssteuerung zur Verfügung stellt.

    Es hast sich eben in den letzten 4 - 5 Jahren extrem viel im Bereich Smarthome getan, siehe z. B. iobroker, fhem etc.


    Ab Frühjahr soll es ja auch einen Nachfolger zum CMI geben, vielleicht, löst es alle hier diskutierten Probleme auf einen Schlag, ich hoffe.


    So gut mir im Moment die UVR gefällt - ist das vielleicht auf lange Sicht der falsche Weg .... mal sehen....

    Wenn du eine bessere frei programmierbare Heizungssteuerung kennst, lass es mich wissen.... :)


    Bei mir ist das Thema etwas anders gelagert, wie bei dir.

    Ich habe ja kein Master/Slave Problem, sondern ein Port: (502) Problem, d. h. ich benützte den Port 502-CMI um mir einerseits vom Smartfox Pro (Energiemanagementsystem) sämtliche Stromwerte zu holen und um im Schema zu visualisieren, gleichzeitig läuft vom CMI eine Verbindung zum iobroker, läuft auf INTEL-NUC, und kann natürlich nicht gleichzeitig den Port 502 Richtung diagslave verwenden, da ja das CMI nur Master kann und nicht multi-connectfähig ist. Ich bräuchte im CMI einen zusätzlichen Port, das CMI kann aber nur mit einem Port arbeiten.


    Erst habe ich versucht, die Messstellen soweit zu reduzieren, dass ich mit den 16 UVR-Eingängen zurecht komme. Leider hat sich das nicht als ausreichend zur Beurteilung der Situation im Haus erwiesen. Insbesondere benötige ich 4 weitere TempEingäng für den Pufferspeicher.

    Ich habe zuerst alles in der TA-Welt aufgebaut und anschließend meinen digitalen Zwilling, RSPPi3+ und jetzt INTELNUC aufgesetzt, aber nur aus Interesse.

    Zum Schalten, verwalten etc. bleibe ich natürlich in der TA-Welt, dies würde ich dir auch dringend empfehlen.

    Mach dir keine zusätzlichen Probleme, ich denke du hast genug an der Zahl.

    Zur grafischen Online-Visualisierung kann man sich in die RSP oder INTELNUC-Welt begeben.


    Ich habe eine UVR16x2 und 2 zusätzliche RSM610 eingesetzt, aber habe es nicht bereut anstatt eines AI5L ein RSM610 eingesetzt zu haben.

    Es geht hier finanziell nicht um Welten, daher spare nicht bei den Komponenten, es wird meist mehr als man vorher plant.


    Bin überzeugt, dass sich in der TA-Umgebung mit TA-Komponenten mit Fernzugriff auf die Hardware schnell jemand zurecht findet.

    In der RSP-Welt ? Da tust du deiner Verwandtschaft keinen gefallen, die werden dich verfluchen. :)

    Meine Frau hat mit Heizungssteuerung wirklich nichts am Hut, bedient aber alles notwendige über das Schema.


    Die Montage der Solarkollektoren habe ich im Sommer 2020 selbst ausgeführt und die gewonnenen Wärme (erst einmal provisorisch) über einen Plattenwärmetauscher in das Heizungssystem eingespeist.

    Finde ich eine gute Idee, mache ich seit 10 Jahren auch so und ist für mich die effizienteste Form der Solar-Heizung.

    Habe selbst keinen Pufferspeicher sondern nur einen 500 l WW-Solar-Speicher.


    Solarthermie-Direktheizung über Plattenwärmetauscher:

    holzheizer-forum.de/attachment/29699/



    LG




    Karl

  • Hallo Karl und hallo Jürgen,


    hmmm ....

    Das das Ganze doch so komplex ist hatte ich mir nicht vorgestellt ....da war ich doch recht naiv!


    eigentlich hatte ich mich dem Thema UVR<=>Raspi zugewendet weil es mich

    a) das Thema grundsätzlich interessiert hatte und ich

    b) diverse Messwerte auf beiden Seiten nutzen wollte.

    Dabei übernimmt UVR+CMI die Standardfunktionalität und der Raspi ist die Spielwiese für "zu klären", "interessant", "Zukunfstmusik" ...


    Dabei will ich gar kein "Wasserkopf" (z.B. FHEM) auf dem Raspi installieren, da das die "Familie" (:= nächste Generation) eh nie betreuen würde oder warten könnte und ich mich demnächst in den Ruhestand zurückziehen will. Die Bedienung soll möglichst einfach über ein noch zu gestaltendes Schema auf dem CMI erfolgen. Programmierungen und/oder Anpassungen kann dann ich (oder einer der "Kinder") per direktem Login ausführen.

    Auf jeden Fall werde ich mit dem Raspi noch untersuchen, ob/wie wir ohne großen Umbau die deutlichen Mängel des verbauten Einrohr-Heizsystems abfangen bzw. reduzieren/optimieren können.


    Für die reine Heizungssteuerung reicht aller Voraussicht nach eine Erweiterung mit ein/zwei Zusatzmodulen von TA. Was dann das richtig Modul ist (RSM610 oder TDI5-DL oder ....) wird sich noch zeigen. Das aktuelle Provisorium funktioniert ja gar nicht so schlecht ... Mal sehen wie viel Aufwand/Zeit/Energie ich da noch investieren will ... Vermutlich schieße ich da mit Kanonen auf Spatzen aber ... es soll ja auch etwas Spaß bereiten :)


    Möglichst bald sollte die Puffertemperatur bzw. das Temperaturverhalten des Puffers auf mehren Ebenen erfassen werden (UVR),
    und (mit dem Raspi) das Antwortverhalten der Heizkörpern auf Veränderung/Niveau der jew. Vorlauftemperatur...


    Irgendwann zu realisierende Aufgaben sind:
    den Heizölvorrat erfassen (ESP32+Ultraschallsensor => DAC => UVR => CMI => Schema),
    Vorbereitungen für ein anstehenden Wechsel des Primärenergieträgers (Endwärmepumpe oder Pellets - ist noch nicht entschieden), ...


    Zum Thema Wärmetauscher/Pufferspeicher: Der Pufferspeicher kam, weil ursprünglich eine Wärmepumpe vorgesehen war. Erst durch die Messungen (nach der Installation) stellte sich heraus, dass in dem augenblicklichen Zustand eine Wärmepumpe ungeeignet wäre. Der dort verbaute Solarwärmetauscher ist leider nicht der Hit - also wird im Sommer den Wärmetauscher wieder eingebaut und in das System integriert.


    Erst mal soviel von mir,

    herzliche Grüße und ein dickes DANKE!


    Stefan (z'Minka)

  • Hallo Stefan,


    ja, Remote-Projekte sind schon eine Herausforderung. Ich betreibe auch einiges Remote. Glücklicherweise hast eine Fritzbox am anderen Standort.

    Da würde ich bei allen wichtigen Komponenten einen fernsteuerbaren Restart vorsehen. Z.B. das Raspi-Netzteil in eine schaltbare FritzDECT-Steckdose reinstecken.

    Dann kannst im Notfall oder bei Verbindungsabbruch den Raspi wieder restarten, indem kurz den Strom über die Dect-Steckdose remote abschaltest und wieder einschaltest.


    Das Linux-Filesystem auf dem Raspi ist entweder ext3 oder ext4. Das sind journaled Filesysteme, die können sich im Fehlerfall, beim Wiedereinschalten meistens selber wiederherstellen, weil alle Systemaktivitäten (file-aktivitäten) parallel mitgespeichert (journaled) werden und im Fehlerfall zur File-Wiedherstellung wieder verwendet (gelesen) werden.

    Das passiert sehr schnell fast unsichtbar im Hintergrund beim Bootvorgang, ist aber sehr wichtig zu wisssen, das es sowas gibt.


    Dann misst die Dect-Steckdose auch den Stromverbrauch und misst die Umgebungstemperatur und zeichnet diese automatisch in der Fritzbox auf.

    Zur Fehleranalyse können diese beiden Messwerte zusätzlich noch hilfreich sein.





    "Ist es richtig, dass es schwierig ist eine direkte Koppelung Raspi - CMI per Modbus funktional zu gestalten."


    Ja, genau mit pyModbusTCP python-script (Modbus-Client) hab ich keine Direktverbindung zum CMI geschafft.

    Deshalb habe ich den diagslave (als Modbus-Slave-Server) direkt hinter dem CMI dazwischengeschaltet.


    Der diagslave ist ein ModBus-Slave-Server (Installation=Programm starten in einem Terminal-Fenster, oder als service im systemd), braucht sehr wenig Speicher und belastet den Raspi sehr wenig, kaum messbar.


    Man sendet die Modbus-Daten mit dem python-script nicht direkt zum CMI, sondern zum diagslave, ist nur eine andere Ip-Adresse. Und im CMI trägt man in den ModBus-Eingängen die IP-Adresse vom diagslave ein, damit eine Verbindung vom CMI zum diagslave aufgebaut werden kann, das wars auch schon.


    Datenfluss vom Raspi zur UVR16x2

    (DS18S20)raspi-python-script(Adresse100,101) --> (Adresse100,101)diagslave(Adresse100,101) --> (Adresse100,101)CMI-Modbus-Eingang 1,2 --> CMI-CANbus-Ausgang 1,2 --> UVR16x2-CANbus-Eingang 1,2


    Datenfluss von UVR16x2 zum Raspi

    (S8 T.Aussen)UVR16x2-CANbus-Ausgang 1 --> CMI-CANbus-Eingang 3 --> CMI-Modbus-Ausgang 3 (Adresse110) --> (Adresse110)diagslave(Adresse110) --> (Adresse110)raspi-python-script(Ausgabe)


    Wenn dann die Theorie der Modbusverbindung verstanden ist, dann gehts ans Umsetzen/Eingemachte, und dann fehlen oft die Linux-Kenntnisse.

    Also das drumherum wird dann plötzlich zum Hindernis, welches es zu überwinden gilt.

    Bei Linux landet man doch viel schneller auf der Kommandozeile wie bei den Windows-Systemen im Dos-Fenster.


    Der Modbus ist ein Industrie-Standard und wird dort sehr häufig eingesetzt. Ich vermute dass der Modbus-Einsatz in den Konsumerprodukten nicht immer genau der industriellen Norm entspricht.

    Ich hab jedenfalls in keinem Handbuch vom CMI oder von meiner Victron-Steuerung einen verbindlichen Hinweis auf eingehaltene DIN-Normen gelesen.

    Und durch die hauseigenen Protokolle die an den Aussengrenzen der Systeme dann irgendwie zum Rest der Welt passen müssen, entsteht dann doch die eine oder andere Qualitätslücke.


    Aber als Endverbraucher hast da wenig Chancen auf Einhaltung von DIN-Normen einzuwirken. Beweis das mal, dass da irgendwas im Argen liegt.

    Und dann Recht haben und Recht bekommen..usw...


    Ich als Optimist/Forscher/Pragmatiker mit vielen Grundkenntnissen und Mut zur Lücke ausgestattet, hab bis jetzt immer eine Lösung gefunden oder manchmal auch selber gebaut.

    Ist wie bei vielen Dingen des Lebens, ist nicht immer drin was draufsteht...


    Damit ein Erfolgserlebnis haben kannst, hab ich in meiner Bastelkiste gekramt und einen DS18S20 Sensor gefunden und hab mit deiner *tdw-Datei und einem Raspi einen Testaufbau gemacht, der deinem Vorhaben ungefähr entspricht.


    Im Dateianhang habe ich das ganze zum nachvollziehen dokumentiert.


    Den DS18S20 hab ich an den Raspi an GPIO-21 (pin40), die Stromversorgung 3,3V an (pin17) und Masse an (pin39) an der 40-poligen GPIO-Leiste am Raspi angeschlossen.

    im /boot -Verzeichnis die datei config.txt mit sudo nano config.txt zum editieren geöffnet, man braucht root-Rechte dazu.

    Dann so ziemlich am ende die zeile dtoverlay=w1-gpio suchen und mit dtoverlay=w1-gpio,gpiopin=21 erweitern und abspeichern.


    danach den Raspi neu booten mit reboot

    dann sudo modprobe w1-gpio pullup=1

    und sudo modprobe w1-therm eingeben.


    mit cd /sys/bus/w1/devices/ ins Verzeichnis wechseln und mit ls erscheinte bei mir dann das 10-000801ff7e40 device-Verzeichnis mit den Daten.

    mit cd 10-000801ff7e40 ins device-Verzeichnis wechseln und mit cat w1_slave werden die DS18S20-Daten angezeigt, so wie sie später im python-script auch gelesen werden.


    pi@raspi4red:/sys/bus/w1/devices/10-000801ff7e40 $ cat w1_slave

    30 00 4b 46 ff ff 0b 10 83 : crc=83 YES

    30 00 4b 46 ff ff 0b 10 83 t=24062


    Dieses device-Verzeichnis muss in deinem python-script angepasst werden, weil jeder DS18S20-Sensor hat eine eindeutige ROM-Adresse und diese eindeutige ROM-Adresse ist Bestandteil des device-Verzeichnisses.


    t=24062 muss durch 1000 geteilt werden, um die Temperatur 24,062 °C zu erhalten, das mach ich später im CMI mit scalierung.


    Wenn man die DS18S20 Daten aus dem "/sys/bus/w1/devices/10-000801ff7e40/w1_slave"-Verzeichnis ausliest kommen da Werte von -50000 bis +120000.

    Das wäre der Wertebereich der Daten die vom Raspi über diagslave zum CMI über Modbus/TCP tranportiert werden muss.


    Ich habe int32 signed mit big-endian gewählt und dann am Modbus-Eingang im CMI die Scalierung angepasst,

    damit ein positiver Temperaturbereich weiter zur UVR16x2 übertragen werden kann.


    Das python-script hab ich um das lesen der DS18S20 Daten erweitert.


    Du musst nur deine ip-Adressen im CMI bei den Modbus-Eingängen/Ausgang richtig eintragen, dann sollte das auch bei dir möglich sein Werte vom Raspi ins CMI rein und raus zu bringen.


    Mein Test-Aufbau:

    CMI = Knoten56, UVR16x2 = Knoten3

    CMI-IpAdresse = 192.168.15.130

    Raspi-IpAdresse = 192.168.15.121

    Modbus-Adresse 100 --> mit Wert 777

    Modbus-Adresse 101 --> mit Wert von DS18S20

    Modbus-Adresse 110 --> mit Wert von UVR16x2 S8-T.Aussentemperatur


    Beim Testen ist mir aufgefallen, dass in deinem Tapps2 Programm zwei Fehler drin sind.

    Bei den beiden CAN-Eingängen in der UVR16x2 muss als Quelle die Knoten-Nr. vom CMI eingetragen werden.

    Du willst ja über den CAN-Bus Daten vom CMI-CAN-Ausgang1 zum UVR16x2-CAN-Eingang1 und CMI-CAN-Ausgang2 zum UVR16x2-CAN-Eingang2 übertragen.


    Das muss noch in deiner *.tdw-Datei geändert werden, sonst kommen keine Daten vom CMI zur UVR16x2.

    Erst dann siehst in der UVR16x2 die Raspi-Daten in der Liste der CAN-Analog-Eingänge.


    Viel Spass und gutes Gelingen


    Gruß

    Jürgen

  • Hallo Jürgen,


    DAS nenne ich selbstlosen Support - einfach irre, was du dir für mich Mühe gemacht hast.


    zum DS18B20:
    ich (als ehemaliger Messtechnik-Ingenieur - vor 30 Jahren ;) ) habe/hatte schon diverse Applikationen Raspi3+DS18B20 unter Python am laufen - unter Anderem die Verfolgung der Hausdaten seit Sommer 2020.


    zu TAPPS2: das war eine mit heißer Nadel gestirckte "Kopie" des laufenden Systems. Die ganez Struktur (Hydraulik, Elektrik, Programm) wird im Frühjahr noch einmal überarbeitet und die Dokumentation nachgezogen werden.. und soll dann übergeben werden.


    ABER - mit Bussystemen hatte ich mich nur sehr rudimentär befasst - eher nur um Messdaten von A nach B zu bekommen .
    HIER muss ich nun lernen wie die Modbus-Struktur funktioniert - Neuland für mich. Da sind deine Ausführungen sehr hilfreich.


    Den Tipp mit der DECT-Schaltdose ist prima und wird baldmöglichst umgesetzt.
    Was ich nicht verstehe ist, wie ich (im Mess-Raspi) für diagslave eine eigene/andere IP einrichten kann - oder läuft der diagslave auf einem anderen Gerät?
    Bisher hatte ich beides (diagslave, pyModbus.py) auf dem selben Gerät (bisher mein heimischer PC unter Ubuntu 20.04) am laufen - diagslave hatte die Verbindungen aufgezeigt ... aber ?...?...?


    Da bin ich doch viel zu sehr Laie was die Elektronik von heute betrifft...

    Den Rest sollte ich nach deiner sehr ausführlichen Antwort eigentlich hinbekommen ...


    Vielleicht noch interessant:
    trotz - oder gerade wegen meiner Technikbegeisterung - ich bemühe mich, so wenig wie möglich Daten im Web herum zu senden -
    das soll alles lokal bleiben und nur per gut geschütztem VPN erreichbar sein. Jedes der "Familienmitglieder" bekommt einen eigenen VPN-Zugang über einen OpenVPN-Server vor Ort - der VPN-Zugang über die Fritzbox soll als Rückfallsicherung Notzugang dienen...
    Ich bin da leider etwas komisch :/ - und vielleicht auch altmodisch ;) ... naja, mti 66 darf man das auch sein 8) - finde ich :S


    Herzlichen Dank & Gruß,
    Stefan


    PS. yep - läuft alles unter Ext4 - hatte keine Ahnung dass das die von dir geschilderten Vorteile hat - SUPER + DANKE!


    Noch ne Frage zu deiner Grafik - die ich sehr anschaulich finde - speziell zum Bereich "Raspi":

    dort steht bei "Raspi" die IP "192.168.15.21" ... und beim diagslave (auch) "192.168.15.21" - ich vermute, dass du beim "Raspi" das Python-Prog meinst, auf dem a) die Datenerfassung der Sensoren und b) pymodbus läuft. Bei mir wird das Lesen der DS18B20 in jeweils eigenen Threads je Sensor umgesetzt. pModbus würde nun einen eigenen Thread im selben Programm bekommen - oder sollten die beiden Programmteile neben einander eigenständig laufen?


    so ähnlich hatte ich es bei meinem Laptop auch - bekam im diagslave-Terminal die VerbindungsIP zum Raspi(:=pyModbus) und zum CMI angezeigt. Die testDaten von PyModbus erschienen, die vom CMI nicht. Hmmmm....


    Ich denke ich werde dein Übertragungsbeispiel einfach mal nachbilden ... versuchen ... die Fragen kommen dann ganz von alleine.

  • Hallo Jürgen und Karl,


    nach diverem herumprobieren klappt nun die Kommunikation Laptop <(VPN)>CMI<=> UVR


    Probleme waren,
    dass ich beim CMI.Ausgang,Modbus Feld "Funktion" nichts hinterlegt hatte. Mit der Änderung auf ... => diagslave zeigt Dateneingang an...

    und dass die Übertragung nur funktioniert, wenn ich in CMI.Ausgang,Modbus das "Gerät" auf "1" stelle.


    Ich vermute die Ursache darin, dass im Diagslave die Python-Kommunikation unter "slave 1" erkannt wird und CMI die selbe Gerätenummer haben sollte.
    Dann wird er im diagslave auch als "slave1" erkannt und ERST dann klappte bei mir die Datenübertragung. Übrigens dann auch in beiden Richungen!
    Wo ich im pymodbus die Gerätenummer definieren/voreinstellen kann habe ich noch nicht gesucht ... wäre vll auch interessant!


    Für mich ist dabei die Bezeichnung "Gerät" irreführend - denn da würde ich jedem Gerät(=slave) eine unterschiedliche Nummer geben.
    So verstehe ich die Angabe eher als eine Arte "KommunkaktionsKanal" in dem dann diverse Register angesprochen werden können.


    Auch finde ich es auffallend, dass der Datenaustausch doch mit einer erheblichen Zeitverzögerung erfolgt ... geschätzt irgend etwas so um 1 Minute - also nur für sich sehr langsam ändernde Sensoren bzw. ablaufende Prozesse geeignet ist.


    Nur so aus Interesse - Frage: wäre eine direkte Kommunikation Raspi <=> UVR per CAN schneller?


    Jetzt erst einmal ein dickes DANKE an euch..

    LG Stefan


    PS. auch musste ich erst einmal suchen gehen wie ich "64485" wieder in eine VorzeichenZahl umrechnen kann ... hatte ich schon sehr lange nicht mehr 8o

  • Hallo Stefan,


    ja super, vielen Dank für die erfreuliche Rückmeldung, und dass es wieder einmal einer geschafft hat

    die UVR16x2 erfolgreich mit der Aussenwelt über den Modbus zu verbinden.


    Ich wollte auch keine unnötige Verwirrung stiften mit der expliziten Angabe der IPadresse vom diagslave.


    Aber es ist wichtig dass du genau weisst welche IPadresse der diagslave hat, um ihn auch richtig vom CMI aus gesehen anzusprechen.

    In jedem CMI-Modbus-Eingang kannst leider nur eine IPadresse eintragen. Ein CMI-Modbus-Eingang kann also nur mit einer IPadresse (diagslave) Verbindung aufnehmen.

    Also gedanklich sollte immer nur ein diagslave aktiv sein.


    Du hast durch deinen Remotebetrieb im Moment zwei Rechner (Raspi remote und Notebook lokal). Auf jedem läuft ein diagslave und ein python-script.

    Also insgesamt zwei diagslaves und zwei python-scripte und ein CMI.

    Deshalb musst da höllisch aufpassen dass die IPadressen des diagslave zur Verbindung im CMI und im verwendeten python-script richtig eingetragen werden.


    Das DS18S20-Modbus-python-script ist nur ein funktionierendes einfaches Beispiel.

    Wenn mal alles am laufen hast, dann würde mich deine finale Version vom python-script interessieren.

    Ich lerne immer wieder gerne dazu.


    Der DS18S20 Teil im python-script ist nur ein funktionierendes Beispiel. Es gibt bestimmt viele andere Versionen wie man die DS18S20-Sensoren einlesen kann.

    Ich wollte nur sehen, was der Raspi da einliest um den Wertebereich zu kennen und damit den richtigen Datentyp zur Datenübertragung zu ermitteln.

    Wie du siehst, wenn man was selber macht hat man sehr viel mehr Freiheitsgrade, als wenn man irgeneiner Doku hinterherhecheln muss.


    Dein zukünftiges Projekt "den Heizölvorrat erfassen (ESP32+Ultraschallsensor => DAC => UVR => CMI => Schema)"

    interessiert mich auch. Wenn das mal läuft wäre ich an einer Doku oder Vorstellung hier im Forum sehr interessiert.

    Mit deinem Fachwissen und deiner beruflichen Erfahrung kannst damit hier bestimmt auch den einen oder anderen damit begeistern.


    Nachdem schon mehrfach nach CAN-Bus gefragt hast, kann ich nur über meine Erfahrungen erzählen.

    Ich habe auch einen Beitrag wie man den UVR1611-CAN-Bus mit einem Raspi lesen kann, geschrieben.

    Aber im CAN-Bus von TA passieren deutlich mehr Änderungen/Erweiterungen, weil fast alle Geräte von TA über diesen CAN-Bus verbunden sind und permanent weiterentwickelt werden.


    Mein damaliges Raspi-Projekt bezog sich auf die alten Geräte (UVR1611 usw.), die arbeiten mit 2 Datenrahmen und mit CAN-Open scheinte das zu klappen.

    Die neuen Geräte mit x2-Technologie arbeiten mit erweiterten Datenrahmen also deutlich mehr und grösseren Datenstrukturen und Busgeschwindigkeiten >= 50 kbit/s.

    Öffentliche Dokumentation gibts da nicht viel und ich hatte meine Forschungen auch nicht weiter vertieft, weil mir der Weg über den Modbus zum Daten in die Steuerung

    reinbringen trotz der sonstigen Schwierigkeiten ausgereicht hat. Restriktion beim Modbus die Intervall-Abfrage-Zeit leider nur alle 10 Sekunden.


    Mein Backbone von meinen Daten im ganzen Haus, und da hab ich mich relativ früh dazu entschieden, ist MQTT.

    Ich teile deine Ansichten zum Datenschutz, nicht nur weil ich im ähnlichen Alter bin, sondern weil ich der Meinung bin es sind meine Daten und die sollen auch bei mir bleiben.


    Gruß

    Jürgen

    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,2kW EEG; VIctron PV-Insel 6kW mit 8xPylontech LiFePO4 Speicher 48V;

    Edited once, last by SolarEngel ().

  • Hallo Jürgen,


    danke für deine Antwort. Ich muss aber da noch ein wenig korrigieren.


    Ich setzte im Moment NUR meinen Laptop ein - habe alles NUR dort eingerichtet und gespielt.
    Wenn das alles klappt wird es dann auf den Raspi (vor Ort) übertragen. Also keine zwei diagslave + PyProgramm im Remotebetrieb.


    Zusatzfrage:
    hast du auch Geräte im DS-Bus in Betrieb bzw. Erfahrung damit ?.... wie langsam sind die denn?
    Wenn sich das zum Modbus nix gibt würde ich doch das Modell "Raspi+Modbus" einsetzen -
    auch wenn es eigentlich ...irgendwie doch ne Bastellösung ist/bleibt .....und mir beim Thema "Übergabe" nicht so gut gefällt....


    Hintergrund:

    Ich habe vor VIELEN Jahren im Bereich Messtechnik gearbeitet ... da aber eher als Projektant und nicht selbst entwickelt ... also nich so wahnsinnig viel mit Fachwissen ... eher von Vielem immer nur ein klein wenig. Das kam erst sehr viel Später - mit dem Erscheinen vom Raspi.

    Mit ESP32 war ich noch gar nicht zugange - mache aber gerade meine ersten Schritte - auch weil ich mich für Micropython interessiere und immer wieder Ideen für Lösungen hätte.... und bisher lässt es sich ganz gut an ... auch dank dem Internet ... so wie HIER


    Das Thema Heizlölstand kommt daher, dass wir seit 2020 , da ursprünglich (2020) auf Wärmepume (oder Pellets) umrüsten wollten - der Budeuskessel ist inzwischen 20 Jahre alt - und deshalb seither mit sehr geringen Öl-Reserven fahren. Durch Covid (keine vor Ort Präsenz) könnte das plötzlich ziemlich eng werden ... und da MessFreak ... warum nicht messen und online nachvollziehen... ( ist aber zur Zeit Pio B)


    Mit der Solaranlage - der Handwerker wollte in 2020 plötzlich nicht mehr - wollte ich nicht warten und habe sie dann selbst montiert.
    Nur war ich mir nicht sicher über die tatsächliche Funktionalität - also habe ich mein früheres Wissen heraus gekramt und zur Nachverfolgung eine Messtruktur aufgebaut. Anfangs mit 6 Sensoren ... viel gestaunt ... auf letztendlich 20 Sensoren erweitert ... bin immer noch am staunen und fluchen.
    Das "wo sinnvoll wie" messen verlernt man ja nicht wirklich.
    Leider wurde durch die Messungen schnell klar, dass da einiges ziemlich "ungut" verbaut wurde ... auch kaum umzurüsten ist und ... DA sind wir heute.

    Also weitere Messtechnik ... Raspi vorhanden und erweiterbar ... aber wie ins UVR bringen => Modbus ....


    Dabei entstand auch das Python-Messprogramm - ziemlich "mit der Hand am Arm" gestrickt und immer wieder umgebaut und erweitert ...
    Ist aber trotzdem alles eine Bastellösung ... ??? Übergabe an nächste Generation ... ???


    Da sowohl Modbus wie auch CAN bisher für mich ziemlich unbekanntes Terrain ist , bin ich über deine Hilfe sehr dankbar!


    Wenn ich die Tage mal Zeit habe schreibe ich detailliert meinen Weg vom DS18B20 über Raspi+Modbus+CMI zum UVR und stelle es hier herein..
    wird aber noch dauern, da viele andere Baustellen ....


    so long - und TOLL dass es Leute wie dich (und auch Karl) gibt .. und dieses Forum

    Stefan

  • Zur Info:


    Habe bei TA wegen den Antwortszeiten vom TDI5-DA (DA-Bus) nachgefragt .... Antwort: ca. 2 s


    => ich werde die Sensoren über den DA-Bus + TDI5-DA einbinden...

    => Modbus wird aus Spaß an der Freude weiter verfolgt ....


    LG Stefan

  • Hallo Stefan,


    vielen Dank für die Info bzgl. der Intervall-Abfragezeiten (2 Sekunden) vom TDI5-DL (DL-Erweiterungsmodul für 5 Eingänge)


    Du schreibst da DA-Bus, du meinst sicher den DL-Bus, den gibts bei TA Produkten.


    laut Produktbeschreibung von TDI5-DL:

    DL-Erweiterungsmodul für 5 Eingänge

    Das Modul verarbeitet PT1000 Temperaturwerte und digitale Signale und gibt diese am DL-Bus auf entsprechenden Indizes aus.

    Aufgrund der geringen Übertragungsraten ist der DL-Bus nicht zum Schalten von Licht geeignet.


    Der TDI5-DL (Temperature and Digital Input) übersetzt bis zu fünf Signale für die Datenleitung (DLBus),

    diese können entweder ein Digitalsignal (Ein/Aus) oder der Messwert eines PT1000-Sensors

    sein. Digitalsignale müssen potentialfrei sein.

    Achtung: Wegen der Trägheit des DL-Busses ist dieses Modul nicht für zeitkritische Verwendungen

    geeignet (z.B. Digitaleingänge als Taster).


    Also deine DS18B20 ...1-wire Digital-Sensoren können daran nicht angeschlossen werden.

    Ich hoffe daß es da keine Missverständnisse bzgl. der Begriffs-Definition von digital

    gegeben hat.


    Mit digital wird "ein Digitalsignal (Ein/Aus)" also fünf einzelne Bits

    die an den 5 digitalen Eingängen angeschlossen werden können gemeint. An jeden Eingang ein Bit.

    Und an den 5 analogen Eingängen werden PT1000 Temperaturwerte (analoge Widerstandswerte) eingelesen.


    Index:

    Der TDI5-DL gibt Werte über 11 Indizes auf die Datenleitung weiter. Diese entsprechen den Eingangszuständen.

    Index Einheit Quelle/Wert

    1-5 Ein/Aus Externes Digitalsignal Eingänge 1-5

    6-10 Temperatur °C PT1000-Sensor Eingänge 1-5

    11-12 nicht verwendet

    13 Dimensionslos Dimensionslose Zahl von 0-31, die alle Eingangszustände binär ausgibt. Siehe Kapitel „Binärdecoder“.

    14 Dimensionslos Seriennummer des Moduls

    15 Dimensionslos Softwareversion (ohne Komma)


    Hast bei deiner Anfrage bei TA auch wegen dem Erscheinen vom neuen CMI nachgehakt und Infos zum neuen CMI bekommen ?


    Gruß

    Jürgen

    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,2kW EEG; VIctron PV-Insel 6kW mit 8xPylontech LiFePO4 Speicher 48V;

  • Hallo Jürgen,


    stimmt - ich meinte den DL-Bus von TA.

    und klar - der digital-Eingang kennt nur ein AN/AUS und ist kein OneWIre-Bus...
    Deshalb werde ich über das TDI5-DL sich langsam ändernde PT1000-Signale auflegen. Für schnellere kann ich dann die freiwerdenden Ports der UVR nutzen.
    Nach aktuellem Überschlag habe ich dann genug Eingänge und auch noch genug freie PT1000...

    Für sonstige Spielereien kann ich dann immer noch den Raspi + DS18B20 nutzen und falls notwendig (und Zeitunkritisch) per Modbus ins UVR übertragen.


    Habe bei TA nicht wegen dem neuen Release vom CMI nachgefragt ... nicht daran gedacht.... sorry!


    Jetzt sind erst einmal andere Themen hier vorrangig - da muss auch das Öltank-Messen per Ultraschall+ ESP32 noch etwas warten... Sobald ich da mehr habe, werde ich mich hier wieder melden....

    Nochmals herzlichen Dank und viele Grüße
    Stefan

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!