Beiträge von SolarEngel

    Hallo,


    bei der Umstellung auf fixe Ip-Adressen musste auch das in die Jahre gekommene SPI-Slave-Konzept

    neu erforscht werden und wurde durch ein schnelles DMA(DirectMemoryAccess)-Konzept ersetzt.


    Bei dieser Überarbeitung ist noch ein kleiner Webserver lokal auf dem ESP32 hizugekommen


    Bild 1


    Auf der Webseite sind alle Informationen und Parameter vom A25 Brenner auf einen Blick angeordnet,

    und mit 4 Push-Buttons können die Tasten direkt am Brenner übers Web ferngesteuert werden.


    Das linke A25-LCD Fenster zeigt die gleichen Informationen an, wie wenn ich direkt vor dem Brenner stehe und auf die LCD-Anzeige schaue.


    Die bisherigen MQTT-Ausgaben und MQTT-Fernsteuerung und Tropföler-Steuerung ist natürlich noch vorhanden.



    Das SPI-Slave-Konzept mit DMA ist inzwischen so präzise und schnell geworden, dass ich jeden

    Ein-Ausschaltvorgang (Sternchen ganz links in der 2.ten Zeile vom LCD-Display) von der Förderschnecke

    sichtbar machen kann und anhand der Zeitstempel der MQTT-Ausgaben den gesamten

    Förderzyklus eingestellt mit Parameter T4 und T6 anschauen, prüfen und dokumentieren kann.


    MQTT -Log-Auszug zur Analyse eines Ein-Aus-Zyklus von der Förderschnecke


    Mit diesem Web Update wurde der A25-Brenner bei mir wieder informativ aufgewertet,

    nachdem er schon über 13 Jahre ohne Probleme läuft und hoffentlich noch lange Wärme erzeugt.


    Über den Winter hab ich mich nicht nur mit der Arduino-IDE sondern auch mit Visulal Studio Code mit PlatformIO und dem herstellerspezifischen ESpresso-IDF beschäftigt.

    Visulal Studio Code gefällt mir am besten, denn es beherrscht mit den jeweiligen Extensions

    den Umgang mit allen Programmiersprachen die ich so kenne und verwende.

    Somit stehen für mich 3 verschiedene Programmier-Werkzeuge (Umgebungen) für den ESP32 zur Verfügung.


    Das Hochladen von externen Dateien (in diesem Projekt das JPEG-Bild vom A25-Brenner)

    in den separaten Flash-Speicher vom ESP32 (mit Filesystem LittleFS) ist mit wenigen Klicks

    in der Tool-Leiste zu erledigen. Damit kann man nicht nur im kleinen EEPROM-Speicher

    sondern im grossen Flash-Speicher vom ESP32 Daten persistent ablegen und ins Programm wieder einlesen.


    Der riesige Speicherplatz im Vergleich zu den Arduinos oder Atmels eröffnet mit dem ESP32-Mikrocontroller

    sehr viel mehr Spielraum beim Programmieren, sodaß eigentlich kein Speicher Engpass entsteht

    und man nicht zum speicherplatzsparenden Assembler-Programmieren genötigt wird.


    Der ESP32-Mikrocontroller ist im Vergleich zu einem Raspi viel kleiner und braucht weniger als ein zehntel Strom und ist deutlich betriebssicherer, denn hier laufen schon einige ESP32 jahrelang ohne Absturz fehlerfrei.


    Bei mir sind viele ESP32 im Einsatz. (A25-Brenner, LamdaCheck, CO-Messgerät, EnBW-Stromzähler, PylonBatterieBMS, UVR610-ModbusRTU-MQTT-Gateway, KAMO-FWS, AECONVERS-WR, HOYMILES-WR usw.)


    Die hängen alle über WLAN und einer MQTT-Verbindung am Mosquitto-MQTT-Broker und erledigen dezentralen Informationsaustausch und Steuerungsaufgaben.


    Mit einem ESP32-Mikrocontroller kann man auch alten Geräten die keine LAN- oder WLAN Schnittstelle haben auf die Sprünge helfen und deren Daten ins Energiemanagement vom Haus integrieren.


    Die 3 angehängten .ZIP Dateien mit einem UNZIPPER Programm entpacken.

    Anschliessend in ein Visulal-Studio-Code Projekt einlesen, kompilieren und auf den ESP32 hochladen.


    Gruß

    Jürgen

    Hallo,


    letzte Woche war der Schornsteinfegermeister zur Messung da. Hier meine Messwerte von 02/2024.


    Mit meinen zwei Messgeräten, Lambdacheck und Co-Messer hatte ich die Verbrennung optimal eingestellt

    und durch loggen der Messwerte auch dokumentiert.

    Für Feinstaub und Abgastemperatur sind die Rauchgasbremsen ausreichend.


    Mein Pellet-Kessel ist inzwischen 13 Jahre in Betrieb und der Schorni ist mit den Werten sehr zufrieden, absolut top.

    In den letzten Jahren wurde bei mir immer zuerst gekehrt und danach der abgekühlte Kessel manuell gestartet und gemessen.


    Wir verglichen während der 15 Minuten Messzeit einigemale seine Werte von CO, Rest-O2 und Feinstaub sogar mit Historie,

    so konnte ich online einen Vergleich mit meinen Messwerten machen.


    Die Messwerte wurden jedes Jahr immer mit besseren Werten übertroffen.

    Also so wie ich das sehe, sind sogar die aktuellen Grenzwerte bei mir auch weiterhin zu erreichen.

    Dank gleichbleibender Pelletsqualität, denn wir haben seit einigen Jahren ein Pelletswerk im Ländle gefunden

    von dem wir direkt beziehen.


    Bei dem Plausch während der Messung erfuhr ich dass nicht nur der Bezirksschornsteinfegermeister,

    sondern auch andere zertifizierte Fachleute die Messungen durchführen dürfen.

    Nur die Feuerstättenschau muss der Chef selber machen.


    Im nächsten Jahr (2025) wird es spannend und stressig meinter er, denn da werden viele fast 20jährige Kessel

    zum erstenmal gemessen. Trend und Ergebnisse noch unbekannt, aber unser Schorni ist optimistisch.


    Gruß

    Jürgen




    <Link zur Tabelle mit allen Messwerten>#36
    Betreiber (Nickname im Forum)SolarEngel
    Kessel (Hersteller/Typ/Leistung)ATMOS D15P 15kW
    Datum der Errichtung der Anlage12/2011
    Stufe der Messung nach 1.BImSchV vom 26.10.2010Stufe-1
    Datum der Messung20.02.2024
    Kosten der Messung98,41 Euro (Netto)


    MessparameterMesswertEinheit
    1. Wärmeträgertemperatur72°C
    2. Abgastemperatur132°C
    3. Sauerstoffgehalt9,2%
    4. Druckdifferenz-18Pa
    5a. CO Grenzwert0,8g/m³
    5b. CO bezogen auf 13% O20,05g/m³
    5c. CO abzgl. Messunsicherheit0,0g/m³
    6a. Staubgehalt Grenzwert0,06g/m³
    6b. Staubgehalt gemessen0,013g/m³
    6c. Staubgehalt abzgl. Messunsicherheit0,01g/m³
    7. Primärluft-mm
    8. Sekundärluft-mm
    9. BrennstoffPellets5a

    Hallo Alfred,


    Drainback hört sich auf den ersten Blick gut an.


    "Ein entleerter Kollektorkreislauf kann weder im Sommer überhitzen, wenn der Speicher voll ist,

    noch im Winter einfrieren, da in diesen Fällen gar kein Wasser im System ist."


    Aber wenn mal ehrlich drüber nachdenkst, dann kannst auch später selber die aufgezeichneten Kollektortemperaturen

    von den beiden leergepumpten Solarkollektoren im Sommer anschauen, wenn den ganzen Tag die Sonne draufgebruzelt hat.


    Da liegen so max. um die 200 Grad am Sammlerrohr im Sammlergehäuse innen den ganzen Nachmittag an

    und das schadet langfristig ganz sicher den Dichtungen an den Schraubanschlüssen.

    Dann bilden sich bestimmt auch immer ganz kleine Rückstände von der abtrocknenden

    Solarflüssigkeit im Kollektor im Sommer beim täglichen aufheizen.


    Wenn Pech hast, dann verzundern die Anschlüsse der einzelnen Röhren die in den Kollektor reingesteckt sind

    bei diesen hohen Temperaturen die jeden Tag im Sommer entstehen können.


    Ich will damit sagen, dass die Hitze den aufgeheizten leergepumpten Drainback-Kollektoren im Sommer

    genauso materialschädlich ist wie bei einer Stagnation bei Steamback-Kollektoren.


    Bei Solarthermie am sichersten keine überhöhten Temperaturen entstehen lassen.

    Dafür gibt es zwei wesentliche Aspkte:

    Entweder eine geignete Wärmeabführmöglichkeit für den Sommer schaffen oder den Aufstellwinkel so optimieren,

    dass eine Überhitzung vermieden werden kann.


    In heutiger Zeit, bei den aktuell sehr günstigen PV-Modulpreisen ( 1 kWp kostet ca. 250 Euro )

    würde ich mir eher einen oder mehrere Heizstäbe in den Pufferspeicher verbauen ( 1 kWp PV ein 1 kWp Wärme)

    oder wenn ich Effizienz will, dann eine WW-Wärmepumpe anstreben (1 kWp PV bis 5 kWp Wärme).


    Vor 15 Jahren hab ich für 1 kWp PV um die 5000 Euro bezahlt, heute sind die Kosten um ein zigfaches gesunken, sodaß

    die PV-Kosten nicht mehr ins Gewicht fallen.


    Gruß

    Jürgen

    Hallo Karl,


    wie schon gesagt ich bin mit Forschen und Testen mit dem Wave-Share Serieller RS485-zu-Ethernet-Server RS485 TO POE ETH (B) noch nicht fertig, aber schon ein Stück weitergekommen.


    Aber ich kann dir jetzt schon sagen, für meine Zwecke ist das Gerät nicht geeignet.

    Ich bin nur an der Umsetzung von Modbus-RTU direkt nach MQTT interessiert.

    So wie ich das sehe ist das hier eine technische Umsetzung von Modbus-Befehlen von Modbus-RTU nach Modbus-TCP und nach MQTT.


    Die Modbus-Befehle sind in Modbus-RTU mit CRC. In Modbus-TCP ohne CRC aber in TCPIP-Pakete eingebaut.

    In MQTT werden die Modbus-Befehle in MQTT-Pakete mit einem festen globalen topic davor eingebaut.


    Beispiele von den MQTT-Daten die vom Waveshare-MQTT-Gateway an den Mosquitto-Broker gesendet werden:

    ...

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x04\x00\x00\x00\t'

    zlanpub b'\x00\x00\x00\x00\x00\x15\x01\x04\x12&DB\x9cl4n\xa9\x1b\xe9\x18\x1c7\xaei\x0c\x0e\xd9'

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x06\x00\x01`\xcd'

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x06\x00\t\x1e\x05

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x04\x00\x00\x00\t'

    zlanpub b'\x00\x00\x00\x00\x00\x15\x01\x04\x12&D,`8c\x13qOx3\xc2\x00\xf6=\x1c\x10C'

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x06\x00\x01j\x80'

    zlanpub b'\x00\x00\x00\x00\x00\x06\x01\x06\x00\t\x08w'

    ...


    Die MQTT-Daten müssen anschliessend noch veredelt, in eine brauchbare Form gebracht werden.

    Und da hat jeder eine andere Vorstellung davon, wie das aussehen sollte.


    Bei dieser Fertiglösung hat man wenig Spielräume zum gestalten.

    Hier kann ich beim MQTT-Gateway nur die zwei topics (publish-topic und subscribe-topic) verändern

    und noch die ip-adresse und den port vom MQTT-Server.


    Weiter stört mich dass es zwei unterschiedliche Config-Tools gibt. Das wichtigere ist das serielle Config-Tool.

    Das ist ein Windows-Programm und ich arbeite in der Smart-Home-Umgebung fast nur noch mit Linux.

    Weiterhin musste ich öfters die MQTT-Definitionen auf den WaveShare-Server übertragen,

    weil die MQTT-Verbindung zum Mosquitto-Broker weg war.


    Das was mir auf Anhieb am besten gefallen hat ist das Gehäuse. Das passt wunderbar neben die UVR610S-MODB Steuerung.

    Ich werde wahrscheinlich das Gehäuse leer machen und mein ESP32 reinbauen und gut ist.


    Gruß

    Jürgen

    Hallo Karl,


    man könnte meinen du kannst Gedanken lesen.

    Ich bin tatsächlich am Tüfteln im Thema "MQTT to MODBUS-RTU CONVERTER" allerdings mit der UVR610S-MODB Steuerung.


    Bis es irgendwann den Nachfolger vom CMI geben wird, habe ich mir zusätzlich eine Schnittstelle

    mit einem ESP32 zum UVR610S-MODB mit MQTT-Anschluss gebaut.


    Bild1 Übersicht UVR-Welt


    Es ist nur ein RS485-Bus-Transceiver notwendig, der die RTU-Modbus-Signale in die für den ESP32

    notwendigen 3,3V TTL-Signale (rx und tx) umwandelt. Den Rest kann der ESP32 und ein bisschen Software.

    Es gibt dafür sehr preisgünstig Fertigmodule.

    Ich habe ein MAX485-Modul für ca. 1,95 EURO von WaveShare bei Eckstein gefunden, das genau diesen Zweck erfüllt.


    Mit einem Steckbrettaufbau kann man sogar aufs Löten verzichten,

    denn das RS485-Modul passt mit den Anschlüssen genau vor die ESP32 Pins.


    Bild2 ESP32 mit RS485-Modul


    Die UVR610S-MODB Steuerung hat 64 Modbus-Eingänge und 64 Modbus-Ausgänge.

    Im Modbus-RTU werden zum Datentransport Register und Adressen zur Programmierung verwendet.


    Ich habe jedem Ein/Ausgang(16-Bit-Register) die Adresse der Ein/Ausgang-Nr zugeordnet.

    Also eine 1:1 Beziehung von 16-Bit-Register zu Adressen.

    z.B. Eingang1=In-Register1 mit Adresse1 und Ausgang1=Out-Register1 mit Adresse1


    Die 64 Modbus-Ausgänge von der UVR610S-MODB Steuerung werden mit einem einzigen Modbus-Befehl readInputRegisters(1, 64) vom ESP32 gelesen.

    Die 64 Modbus-Eingänge von der UVR610S-MODB Steuerung werden in einer Schleife mit dem Modbus-Befehl writeSingleRegister(j, holdingRegisters[j]) vom ESP32 beschrieben.


    Die Daten der Ein/Ausgänge werden in zwei Arrays mit jeweils 64 Elementen (uint16_t) zwischengespeichert.


    Jedem Eingang ist ein generisches MQTT topic z.B. UVR610-32/E-1 ... UVR610-32/E-64 zugeordnet.

    Jedem Ausgang ist ein generisches MQTT topic z.B. UVR610-32/A-1 ... UVR610-32/A-64 zugeordnet.

    Die 32 im (UVR610-32/A-1) topic ist bei mir die Knotennummer von der UVR610S-MODB Steuerung um eindeutig im MQTT zu bleiben.


    Weil im Moment noch nicht Daten für alle 64 Ein/Ausgänge in meiner UVR610S-MODB Steuerung vorgesehen sind,

    habe ich zum Testen im Sekundentakt mit einem Zufallsgenerator 64 Zufallszahlen für die einzelnen Eingänge erzeugt.


    Die UVR610S-MODB Steuerung arbeitet mit Modbus-RTU im Slave-Modus mit 115200 Baud.

    Damit hat der ESP32 genug Zeit zum Umsetzten der Modbus-RTU-Daten in MQTT-Pakete und umgekehrt.

    Ein optimaler Datenaustausch im Sekundentakt, wie Wechselrichter und Energiezähler das können,

    ist bei mir somit über Wlan in die TA/UVR-Welt möglich.


    Bild3 Wave-Share-Server mit UVR610S-MODB


    Weiterhin bin ich auch mit einem industriellen Wave-Share Serieller RS485-zu-Ethernet-Server

    RS485 TO POE ETH (B) am Forschen und Testen.


    Hierbei handelt es sich um einen RS485-Gerätedatensammler/IoT-Gateway,

    der speziell für die industrielle Umgebung entwickelt wurde

    und seriellen Server,Modbus-Gateway, MQTT-Gateway, RS485 zu JSON und andere Funktionen kombiniert.

    Es verfügt über eine RS485-Schnittstelle und eine Ethernet-Schnittstelle

    Das Gerät kostet so um die 30 Euro bei Eckstein, also sehr preiswert.


    Ich hab noch nicht alle Funktionen ergründet und zum laufen gebracht. Die Umsetzung von Modbus-RTU nach

    Modbus-TCP und umgekehrt läuft sehr stabil. Das MQTT-Gateway und JSON läuft noch nicht zufriedenstellend.

    Da bin ich noch am Forschen. Es stehen zwei Konfigurations Möglichkeiten zur Verfügung.

    Einmal übers Netzwerk und einmal über den seriellen Weg (Modbu-RTU). Beide sind sehr unterschiedlich

    und irgendwie schwer zu durchschauen. Chinesisch ist noch nicht meine Lieblingssprache, es kommt mir manchmal nur so vor.

    Also da brauchts noch eine Menge Geduld. Aber früher oder später wird das Ding schon richtig zum Laufen kommen.


    Den Wave-Share-Server kann man direkt neben der UVR610S-MODB Steuerung auf eine Schiene klemmen und mit den

    12Volt von der UVR610S-MODB Steuerung verbinden, brauchst kein extra Netzteil, das gefällt mir sehr gut.


    Gruß

    Jürgen

    Hallo Sven,


    die Idee klingt gut mit einem 32ch RS 485 Modbus RTU Relais Bord die TA-Steuerung um 32 Ausgänge zu erweitern.


    Theoretisch wird das auch mit Mod-Bus-Befehlen funktionieren.


    Nur ob an den geplanten 32 Modbus-Ausgängen vom CAN-EZ3 genau die Modbus-Befehle rauskommen um die Relais so anzusteuern

    wie gewünscht, das gilt es herauszufinden.


    Also einfach auf gut Glück das RTU Relais Bord an den RTU-Modbus vom CAN-EZ3 anschliessen und dann mit Tapps2 die 32 Modbus-Ausgänge

    ein und ausschalten, das wird bestimmt nicht sofort funktionieren.


    Ich bin Waveshare-Fan und hab ein Protokollhandbuch für Modbus RTU-Relais gefunden.

    Protocol Manual of Modbus RTU Relay - Waveshare Wiki


    Die meisten Programmier-Beispiele für Modbus RTU-Relais die man so im Internet findet,

    verwenden Modbus-Befehle, die dort beschrieben sind.


    Welche Informationen/Unterlagen waren beim Board dabei?

    Was hast schon alles probiert?

    Mit welchen Tools oder Anwendungen hast geforscht?


    Mehr Infos über dich und deinen Wissensstand wären wünschenswert.


    Das Thema interessiert bestimmt viele,

    denn wer hatte nicht schonmal den Wunsch sehr viele Ausgänge zum Steuern zur Verfügung zu haben.


    Gruß

    Jürgen

    Hallo Karlheinz,


    vielen Dank für die Reparaturanleitung. Sowas kann man immer brauchen, denn nach 10Jahren oder später kommt man sehr

    schwer an Ersatzteile oder Informationen zu den dann veralteten Teilen ran.

    Hab mir das verlinkte Video gleich lokal abgespeichert, damit wenn der Fall der Fälle eintritt das ich auch gleich anschauen kann.


    Bei mir läuft schon 14 Jahre im Heizkreis nach dem Mischer auch so eine Grundfos Alpha2 (Modell-A)

    mit 5 Watt im Automatik-Modus.

    Sie läuft seit Jahr und Tag ohne Probleme. Bin mit der Qualität von der damals teueren Grundfos-HE-Pumpe sehr zufrieden.


    Gruß

    Jürgen

    Hallo jeanpv,


    es sind ja nur 3 Leitungen auf die es ankommt. RX an pin2, TX an pin3 und Masse an pin5 am SUB-D9 Anschluss.

    Das einzige was man vertauschen kann ist rx mit tx. Mehr gibts nicht zu vertauschen.


    Dafür gibt es auch fertige (RS232 cross-over oder Nullmodem) Kabel mit SUB-D9 Anschlüssen,

    da werden die beiden Leitungen rx und tx von der einen zur anderen Seite gekreuzt.

    Früher, in der Zeit wo es noch keine USB-Anschlüsse gab,

    hat man das öfters zum Anschliessen von RS232-Modems oder Direktverbindungen über RS232 zwischen zwei Computern gebraucht.


    An meinem seriell-to-USB Adapter mit Kabel sind 2 LED's für tx und rx Signal dran,

    da kann ich schon optisch sehen wenn sich Daten (rx,tx) auf der Leitung bewegen.


    Zum testen kannst ja anstatt dem Gender Changer(1:1) ein RS232 cross-over oder Nullmodem-Kabel

    hinter dem seriell-to-USB Adapter zum Kessel anschließen.


    Wenn ich mir nicht sicher bin, ob die Signale richtig oder überhaupt am Interface ankommen,

    dann muss ich halt messen mit einem Messgerät das digitale Signale anzeigen kann.


    Ein Logikanalyser, ein Oszi(galv. entkoppelt) oder ein Multimeter mit Digital-Funktionen(oszi).

    Solche Messgeräte sind inzwischen für jedermann erschwinglich.


    Wenn der RS232 Hardware Anschluss geklärt ist und die Signale rx und tx und Masse richtig am Interface ankommen,

    dann geht’s erst am Rechner weiter.


    UART-Einstellungen von Lambdatronic 3200 laut Handbuch mit Baudrate: 57600

    Wenn die Schnittstelle permanent ohne Aufforderung Daten liefert,

    dann kannst mit einem Terminal-Programm wie minicom oder cutecom oder PuTTY Daten vom ttyUSB0-Anschluss direkt einlesen.

    oder kannst in einem Terminal-Fenster den ttyUSB-Anschluss testen


    aktuellen Status von ttyUSB anzeigen

    sudo stty -F /dev/ttyUSB0 -a


    ttyUSB0 auf 57600 Baud einstellen

    sudo stty -F /dev/ttyUSB0 speed 57600


    64 Bytes von ttyUSB0 einlesen und im Hex-Format anzeigen

    sudo hexdump -C -n 64 /dev/ttyUSB0


    Daten von ttyUSB0 einlesen und in eine Datei schreiben

    sudo cat /dev/ttyUSB0 > daten.txt

    mit ctrl-c speichern beenden...


    Inhalt von Datei daten.txt anzeigen

    cat daten.txt

    oder mit jedem anderen editor anzeigen lassen, geht natürlich auch.


    Wenn Daten im Rechner angekommen sind, dann gehts weiter mit Linux und - P4-Daemon (p4d)

    Der USB-Seriell-Konverter muss an COM1 des Fröling-Mainboards angeschlossen sein.


    Gruß

    Jürgen

    Hallo @fabiiiiii,


    hier ein paar Fehlercodes zu den Modbus-Befehlen:


    // Modbus-Return-Codes

    //Success = 0x00; = 0 --> Return-Code = ok

    //IllegalFunction = 0x01;

    //IllegalDataAddress = 0x02;

    //IllegalDataValue = 0x03;

    //SlaveDeviceFailure = 0x04;

    //BInvalidSlaveID = 0xE0; = 224

    //BInvalidFunction = 0xE1; = 225

    //ResponseTimedOut = 0xE2; = 226

    //InvalidCRC = 0xE3; = 227


    Mit einem rs232 shield wird das ganze nicht funktionieren.

    Du mußt ein RS485 Shield verwenden.


    Gruß

    Jürgen

    Hallo Cord,


    habe die V132BetaA auf UVR610 draufgespielt und mit Modbus-RTU getestet.


    Den Testfall mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe,

    konnte ich mit einem python-script erfolgreich beliebig oft durchführen.


    Mit Node-Red lief die Übertragung zur Adresse 71 (grösser 64), zum Modbus-Eingang-11 ebenfalls erfolgreich.


    ...

    DEBUG:pymodbus.transaction:SEND: 0x1 0x6 0x0 0x47 0x25 0x81 0xe3 0x2f

    DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - 1704986351.923675, Current Time stamp - 1704986351.926693

    DEBUG:pymodbus.framer.rtu_framer:Waiting for 3.5 char before next send - 4.01 ms

    DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'

    DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'

    DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'

    DEBUG:pymodbus.transaction:RECV: 0x1 0x6 0x80 0x54 0x52 0x6c 0xef 0xfe

    DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'

    ...


    Gruß

    Jürgen

    Hallo EFH56,


    mein A25-Brenner feiert dieses Jahr sein 14 Jähriges, und lebt wahrscheinlich so lange,

    weil er gut gepflegt/gereinigt wird.


    Im Brennermenü (Informationen) werden auch die Lüfterdrehzahlen von den verschiedenen Brennerphasen angezeigt.

    An möglichen Drehzahländerungen könnte man auch ein mögliches Problem ableiten.

    Mein Datensammler zeichnet alle Brennerdaten und auch die Lüfterdrehzahlen auf, so dass ich mit einer

    Analyse der Datenaufzeichnungen aus der Vergangenheit der Lüfterdrehzahlen auf die Spur kommen könnte.


    A25 ==>AN 74/ 41 C * * *

    A25 ==>Parametern

    A25 ==>Information

    A25 ==>Photozelle 100%

    A25 ==>untere Temp. 41,2 C

    A25 ==>oberer Temp. 73,9 C

    A25 ==>Ventilator 2850rpm

    A25 ==>Forderschnecke OFF

    A25 ==>Schneckestorung OK OK

    A25 ==>Gluhspirale 1:OFF 2:OFF

    A25 ==>Spiralestorung 1: OK 2: OK

    A25 ==>Ausgangsreserve 1-OFF


    Den A25-Brenner schraube ich am Ende der Heizperiode, also vor den Sommerferien zur grossen Reinigung

    einmal im Jahr vom Kessel weg und zerlege und reinige alle Teile.


    Der Lüftermotor im A25-Brenner wird mit Druckluft gut durchgeblasen und vom Staub befreit.

    Das hat bisher sehr gut so funktioniert.


    Allerdings habe ich nach Ablauf der Garantie (nach 5 Jahren) alle stark beanspruchten Teile,

    wie Heizspiralen, Lüftermotor vom A25, Laddomatpatrone, Ersatzpumpenkopf für Laddomat-Pumpe, Getriebemotor für Pelletsschnecke

    und auch anderes als Ersatzteile wie diverse Keramiken vom Brennraum im Regal bereitgelegt, falls etwas sofort benötigt wird.


    183 Euro in 10 Jahren für einen Ersatzlüfter sollten die Vorsorgeaufwendungen für die Heizung schon wert sein.

    Ansonsten sparst an der falschen Stelle.


    Gruß

    Jürgen

    Hallo Cord,


    frohes neues Jahr, wie man bei uns sagt.



    Sind die Effekta Hybridwechselrichter über USB-RS232 an die Batterien angeschlossen?

    Das wäre dann BMS-auslesen. Kein CAN-Anschluss von Batterien zu den Effekta Hybridwechselrichtern?


    Über welches Daten-Protokoll kommen Daten von Effekta Hybridwechselrichtern zu Solarassistant? (MQTT, Modbus oder RS232?)


    Solarassistant liest von Effekta Hybridwechselrichtern und Batterien Daten ein. Hast dann zweimal USB-RS232 an den Batterien angeschlossen?

    Einmal USB-RS232 von Batterie zu den Effekta Hybridwechselrichtern und dann nochmal USB-RS232 von Batterie zu Solarassistant?


    Kannst vielleicht das Umfeld von den Effekta Hybridwechselrichtern etwas beleuchten, damit mir das ganze etwas klarer wird und ich den danzen Datenfluss verstehen kann? (Fotos oder sonstige Bilder von den Anschlussverbindungen Hybridwechselrichter und Batterien)


    Mich interessiern die Effekta Hybridwechselrichter und deren Konnektivitäten auf jedenfall, denn inzwischen gibt es einige Hybridwechselrichter,

    aber die Internas stehen nicht ganz vollständig in den Handbüchern.


    Gruß

    Jürgen

    Hallo Cord,


    den Testfall mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe,

    konnte ich auch mit einem python-script ausserhalb von Node-Red wiederholen.


    Gleich nach starten des python-scripts macht das UVR610 sofort einen Reset und pfeift.

    Das kann ich mit dem python-script beliebig oft wiederholen.

    Also das Modbus-Adressproblem in UVR610 hat also nichts mit Node-Red zu tun.



    Das kannst bestimmt auch mit jedem Modbus-Master-Simulator durchführen wenn einen solchen Testfall aufbaust.


    Wie schon gesagt, bei mir ist das bisher nicht aufgefallen, weil ich bei meinen UVR610 Programmen immer Adressen unterhalb 64 verwendet habe.


    Beim programmieren mit Tapps ist mir schon aufgefallen, dass automatisch das Adressfeld mit einem Wert gefüllt war.

    Den hatte ich aber so wie du auch überschrieben.


    Wahrscheinlich bleibt der Automatismus der Adressvergabe beim Arbeiten mit Tapps im Adressbereich innerhalb der Grenze bis 64.


    Gruß

    Jürgen

    Hallo Cord,


    super, so wie es aussieht hast den Fehler gefunden.


    Ich bekomme jetzt auch einen Absturz vom UVR610 fertig.

    Hab einen Test gemacht mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe.


    Mit Tapps kann man das ganze kompilieren, das Programm läuft auch im UVR610.

    Aber wenn ich über den Modbus einen Schreibbefehl mit Adresse 71 losschicke, dann macht das UVR610 sofort einen Reset und pfeift.

    Das kann ich beliebig oft wiederholen.


    Ein weiteres Problem ist, wenn ich eine Adresse von einem Modbus-Eingang in einem Schreibbefehl verwende,

    der in Tapps noch undefiniert (noch nicht verwendet wurde) dann gibts auch Probleme und eine Fehlermeldung:


    msg : error

    "Error: Modbus exception 2: Illegal data address (register not supported by device)"


    Bei meinen Experimenten hab ich immer den Modbus mit dem angeschlossenen Oszi überwacht.

    Im Fehlerfall ist dann die Ausgabe am Modbus-Interface (/dev/ttyUSB0) einfach weggeblieben, es war plötzlich kein Signal mehr da.

    Im Node-Red-Debug Monitor sind aber immer noch Modbus-Fehlermeldungen ausgegeben worden.


    Nach Korrektur des Fehlers war die Ausgabe am Modbus-Interface (/dev/ttyUSB0) immer noch weg.

    Erst nach Neustart von Node-Red kamen wieder Siganale auf dem Modbus.


    Bei meinen bisherigen UVR610 Programmen habe ich intuitiv immer automatisch eine Adresszuordnung zum Modbus-Eingang/Ausgang 1:1 gemacht.

    Mit 64 Ein- und Ausgängen hat man ja genügend Adressen. Wenn ich keine 1:1 Zuornung mache, dann muss ich zusätzlich auch noch eine Mapping-Liste pflegen.


    Im Handbuch steht: "Die Adresse des Moduls wird automatisch vergeben und abhängig von der Eingangsnummer und des Typs hinaufgezählt."


    Gruß

    Jürgen

    Hallo Cord, Frohe Weihnachten,


    die ganzen Tests habe ich diesmal mit einem Node-Red Generator (flow) ausgeführt, damit man das mit Node-Red Kenntnissen besser nachvollziehen kann.

    Meine Test mit Modbus RTU an die UVR 610 Modbus liefen bisher sehr erfolgreich, ohne Fehlermeldungen und ohne Abbrüche vom UVR610 über viele Wochen fehlerfrei durch.

    Bin total begeistert über die Geschwindigkeit, Stabilität und Robustheit vom UVR610 RTU-Modbus.


    Ich habe immer im Sekundentakt 10 verschiedene Werte von einem Zufallsgenerator erzeugt gleichzeitig mit 10 einzelnen Schreibfunktionen (fc-6) auf den Modbus geschrieben

    und dann sofort wieder mit einer Multi-Register Abfrage-Lesefunktion (fc-3) ausgelesen.


    Das UVR610-Programm hat die Modbus-Eingänge eingelesen und sofort wieder über eine Analog-Funktion an die Modbus-Ausgänge und an die CanBus-Ausgänge weitergegeben.

    Ich bekam immer innerhalb einer Sekunde vom UVR610 RTU-Modbus die zehn Zufallszahlen-Werte fehlerfrei zurück, die ich gesendet hatte.


    Ich habe mit meinem Batterie-Oszi (galvanisch entkoppelt) den MODBUS direkt angeschaut und die Pegel der einzelnen

    Interfaces als auch von UVR610 anschauen und vergleichen können. Die Pegel waren alle ähnlich hoch, keine Ausreisser.

    Dann habe ich alle Geschwindigkeiten bis hoch auf 115200 Baud getestet. Kein Problem und keine Signalverzerrungen.

    Die 9600 Baud sind völlig ausreichend gewesen. Gleiches Ergebnis wie bei 115200 Baud.

    Es gibt noch keinen Grund die Baudrate wegen der Datenmengen zu erhöhen.


    Erst wenn ich unter einer Sekunde, im 0,5 oder 0,2 Sekundentakt gesendet habe, dann haben Werte in der Antwort gefehlt,

    aber bei allen Busgeschwindigkeiten auch bei 115200 Baud haben dann Werte in der Antwort gefehlt.

    Das hat also nichts mit der Busgeschwindigkeit zu tun.

    Egal, ich wollte nur mal sehen, wie schnell man den UVR610 RTU-Modbus fehlerfrei abfragen kann.


    Später habe ich eher mehr zufällig ähnliche Fehlermeldungen wie du geschrieben hast, auf dem RTU-Modbus produziert.


    Node-Red kann man in unterschiedlichen Konstellationen installieren:

    - native normal alleine als einziges smart-home-system

    - als container einer docker-installation

    - als subsystem von iobroker oder HomeAssistant

    - virtuelle Maschine oder container in einer proxmox-Umgebung

    usw.


    Bei meinen Tests habe ich mehrere verschiedene interfaces (mehrere USB-RS485, Raspi-Aufsteckmodul, ESP32-Steckmodul) verwendet

    auf dem gleichen RTU-Modbus an dem auch an einem Ende das UVR610-Gerät als Modbus-Slave hängt.


    Bei einem Test mit zwei verschieden Node-Red installationen und gleichem flow, hatte ich tatsächlich eine

    Kollision von zwei gleichen Sendern(master) die gepollt haben und sich dabei gestört haben produziert.


    Dabei kamen ähnliche Fehlermeldungen wie bei dir zustande.

    "Modbus Failure On State sending Get More About It By Logging"


    Nachdem ich den zweiten Sender (RTU-Server) wieder abgeschaltet hatte, war das Problem sofort beseitigt.


    Beim meinem Sender-Server, RTU-Server habe ich den Verbindungstyp RTU-Bufferd verwendet.


    Kannst mal überprüfen ob es bei dir in den flows mehr als einen aktiven RTU-Sender gibt?


    In den Server-Einstellungen wird immer eine Referenzanzahl angezeigt, wie oft das Objekt verwendet wird.

    Wenn man die Anzahl der Sender und Empfänger mit den Schreib und Lese-Objekten abgleicht, könnte man so

    auch ein mögliches Problem erkennen.


    Bei zb. Geräteadresse 1.

    Es darf anscheined immer nur ein RTU-Server(Master) pollen. Alle anderen müssen zuhören(Slave).


    Ein paar Screen-Shots von deinen Node-Red Einstellungen (alles was mit RTU zu tun hat) wären auch nicht schlecht.

    Bei Timing-Problemen kann man an einigen Stellschrauben drehen, aber dazu später mehr.


    Gruß

    Jürgen

    Hallo Cord,


    super, wenn den Fehler gefunden hast und wieder alles funktioniert so wie es soll.

    Vielen Dank für die Rückmeldung. Denn damit hapert es noch hier im Forum.


    Du warst sicher der Meinung, wenn du mit jedem der zwei UVR610 einen getrennten Modbus betreibst,

    dann wird das wohl nicht stören, da die Modbusdaten sich auf den ersten Blick nicht in die Quere kommen.


    Weisst ja nachher ist man immer schlauer.

    Aber wenn man genauer drüber nachdenkt, dann weiss man, dass die beiden UVR610 zwar über die beiden Modbusse nicht miteinander verbunden sind,

    aber sehr wohl im Hintergrund über den gemeinsamen Can-Bus (TA-Backbone).


    Du machst das zwar nicht, aber wenn du z.B. Daten vom Modbus-Eingang1 von der UVR610-1(Geräteadresse1) zum Modbus-Ausgang1 von der UVR610-2(Geräteadresse1)

    über den Can-Bus im Hintergrund übertragen möchtest, dann gibts schon ein Geräte-Adressen Konflikt,

    weil beide einen Modbus-Eingang1/Ausgang1 mit der gleichen Geräte-Adresse 1 besitzen würden.

    Vielleicht wäre mit so einem Beispiel der Geräte-Adressen Konflikt schon früher aufgefallen?


    Mit TAPPS kann man das nicht so einfach rausfinden, denn du programmierst ja damit immer nur eines von vielen UVR610-Geräten.

    TAPPS weiss ja nicht, dass du nochmal ein UVR610 mit der gleichen Geräteadresse1 im Modbus betreibst.


    Inzwischen werden die TA-Systeme durch das Verknüpfen von Heizung mit PV zu Energiemanagementsystemen immer grösser mit immer mehr Geräten.

    Aber von TA sollte so ein mögliches Problem erkannt worden sein. Die testen ja alles auf Herz und Nieren.

    Du hast ja ausführlich dein Problem dort geschildert.


    Beim MODBUS-SLAVE im UVR610 "Man kann neuerdings auch einen "gemeinsamen Adressbereich" einstellen ..."

    Das hat nichts mit der Geräteadresse zu tun, sondern mit den Speicheradressen der verschiedenen 16-Bit Modbus-Registeradressen.

    Gemeinsam nutzen heisst auch überschreiben von einzelnen 16-Bit Modbus-Registeradressen ermöglichen, damit kann man auch Programmieraufwand sparen/optimieren.


    Ein Frage noch zu deinem Energiemanagementsystem:

    Bei der Datenübertragung vom Hybridwechselrichter Effekta werden auch Batteriedaten von den Pylons über Homeassiatent oder Node-Red eingelesen.

    Wie sind die Batterien mit dem Hybridwechselrichter verbunden? Über Pylon-Can-Bus?

    Werden die Batterie/Hybridwechselrichter-Daten über Homeassiatent mit Interface-Modul oder direkt mit Node-Red-flow eingelesen?

    Welche Batteriedaten werden von den Pylons eingelesen?


    Kannst ja auch einen eigenen Thread mit deinem Energiemanagementsystem aufmachen, dann weichen wir hier nicht allzusehr vom Firmware-Thema ab.


    Gruß

    Jürgen

    Hallo Michael,


    vielen Dank für den Hinweis,

    Deine präzise Analyse ist natürlich nicht zu überbieten.


    In dem Video werden auch die Entlüftung vom alten und auch vom neuen Modell erläutert.


    Es ist halt ein sehr umfangreiches Video, das auch die vielen Jahre Erfahrung von Michael Rentsch

    mit vielen Service Anfragen beinhaltet.


    Gruß

    Jürgen

    Hallo Walter,


    ... Istt es möglich das die Patrone nicht richtig im Laddomat sitzt ?

    ja, wenn die Patrone nicht richtig eingesetzt wurde, dann können Fehlfunktionen auftreten.

    Ich habe bei meinem Kessel zu Beginn dieser Heizperiode auch die 72Grad Patrone vom Laddomat21(alt) zum erstenmal gewechselt.


    Meine grössten Bedenken waren eher, dass ich die grosse Schraube nach über zehn Jahren Betrieb nicht aufbekomme, aber mit der grossen Rohrzange und dem grossen Hebel damit, war das überhaupt kein Problem.


    Nach dem präzisen einsetzen der Patrone und sorfältigem zusammenbauen der Einheit lief

    der Laddomat21 wie gewünscht und alle drei Temperatuen am Laddomat21(alt) sind bei mir so wie es sein sollte.

    (oben Kessel-VL=80, unten rechts Puffer-RL=30, unten links Kessel-RL=72)


    Es gibt ein sehr informatives Video von Michael Rentsch (ATMOS-Zentrale).

    Laddomat - die Rücklaufanhebung und somit das wichtigste Bauteil am Heizkessel

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    In diesem Video werden Laddomat21 alt und neue Version vorgestellt. Die Funktionsweise und Unterschiede werden erläutert.

    Beispielhaft wird eine Patrone ausgebaut, in zerlegtem Zustand werden alle wichtigen Teile gezeigt, erklärt

    und anschlissend wird die Patrone wieder eingebaut und alle wichtigen Fallstricke erläutert und gezeigt.


    Nach diesem Viedeo sollte ein Austausch der Laddomat-Patrone möglich sein.


    Gruß

    Jürgen

    Hallo Cord,


    vielen Dank für die Übersichten.

    Ohne diese wären die Übertragungswege zum Knoten 39 nicht nachvollziehbar gewesen.


    Ich teste mit UVR610S Modb mit den Firmwareversionen V.121 , V1.27 und V1.31


    Einen Absturz der UVR610S Modb konnte ich leider noch nicht produzieren mit der Firmwareversion V1.31

    Ich habe auch einige MQTT-Broker im Einsatz und die kann ich zum Dateneinspeisen sehr gut verwenden, brauche nur die Namen der topics ändern

    dann kann ich deine Flows und deine Programmierung vom Knoten 39 im Original verwenden.


    Da hast inzwischen ein großes heterogenes Umfeld geschaffen, das es zu beherrschen gilt.


    Wenn wieder zu Hause bist, kannst dich melden, dann können wir in Zeitlupe die Abstürze und ein paar wichtige Daten davon genauer anschauen

    und analysieren. In der Heizperiode würde ich aus der grossen Entfernung keine Experimente und keine elemtaren Updates durchführen.


    Gruß

    Jürgen