OpenKNX-Modbus RTU Gateway

[mpl1337]

Wie kann ich ein Bitmaskiertes Register abfragen bzw. darstellen?

Ich benötige nur die Bits1,2,8,9,10

Muss ich für jedes Bit einen eignen Kanal anlegen?

image.png

image.png

[Masifi]

Wenn du es direkt haben möchtest, dann geht das nur so. Ein weiterer Weg könnte das Logikmodul sein, damit sollte das auch gehen.

[mpl1337]

Ich habe es auf dem direkten weg hinbekommen.

image.png

Was wäre der weg über das Logikmodul?

Was mir eben noch aufgefallen ist:

image.png

Ich nutze Modbus jedoch leuchtet die MBus LED grün, die MOD nicht. Die Zuordnung der Error LED passt jedoch. Ich hatte vorhin einen Fehler beim testen und da ist mir das erst aufgefallen. Kann es sein das die LEDs für Mbus und Modbus in der Software vertauscht sind? Stört mich jetzt nicht, wollte es nur mal erwähnt haben

[mpl1337]

Masifi

wie bekomme ich auf das KO20 "Fehler Modbus..." einen Status?

image.png

Leider ist das KO immer leer, egal welchen Fehler ich habe (Error LED ist Rot, KO ist leer)

[Masifi]

Da ist noch nichts drauf, sorry. Wenn das Modbus Modul mal mehr als 100CH bekommt, dann muss ich das auch noch anpassen, dann geht Bit0..6 nicht mehr und ich brauche alle 7 bits.

Falls ich mal noch etwas Zeit finde, dann versuche ich das reinzuschieben, aber gerade ist es nicht so einfach dafür Zeit zu finden.

[Masifi]

Ich habe die letzten Wochen genutzt um die Firmware noch einmal "fast" komplett neu aufzusetzen. D.h. die Firmware ist jetzt wieder auf dem aktuellen Stand von OpenKNX. Dazu ist sie auch noch updatefähig in der ETS.

Große Neuerungen:

• 200 Modbus CH anstatt 100
• Diagnose KO implementiert. 2Byte (LSB = Kanal-Nr & MSB = Error Codes)

Dazu gibt es jetzt noch eine weitere HW-Variante. Es wird keine zusätzliche Versorgungsspannung benötigt und trotzdem ist der Modbus-Teil galv. getrennt.
Die schon bestehende 2TE Einheit wird auch noch einmal komplett überarbeitet.

Des Weiteren wird auch noch eine Outdoorversion im IP-Gehäuse kommen. Damit kann man später Bodenfeuchtesensoren wie den SMT100 betreiben, oder den ein oder anderen Regen, Wind, Temperatursensor.


Modbus_1TE.jpg


Ich habe die Firmware jetzt parallel mit zwei Zählern und einem Display getestet. Es gibt sicher noch sehr viel mehr Varianten die man noch abprüfen könnte.
Falls jemand Interesse und Zeit hat, die neue Firmware mit der neuen HW zu testen, der darf sich gerne bei mir melden.

[Ing-Dom]

Dazu gibt es jetzt noch eine weitere HW-Variante. Es wird keine zusätzliche Versorgungsspannung benötigt und trotzdem ist der Modbus-Teil galv. getrennt.
Die schon bestehende 2TE Einheit wird auch noch einmal komplett überarbeitet.

schön das du meine Innovation aus dem UP1-RS-485 übernommen hast

Falls jemand Interesse und Zeit hat, die neue Firmware zu testen

ja hätte ich - aber der branch https://github.com/OpenKNX/OAM-Modbu...New_HW_Version bekomme ich nicht zum laufen?
Ist da schon dein aktueller Stand gepsuhed?

[himself]

Hi Masifi,

hab gerade gesehen das du fleissig warst. Konntest du das 64 Bit Thema mit integrieren?, Konnte den Dateien nichts entnehmen. Die neue FW läuft auch auf dem alten Gateway?

[Masifi]

schön das du meine Innovation aus dem UP1-RS-485 übernommen hast

Innovation? Du hattest nur die billigere Variante, ich wollte eigentlich einen von Analog Device einsetzen, aber der war 4x so teuer. Mein bestehendes 2TE Gateway war ja immer gedacht, dass es auch parallel MBUS kann, daher kam man um ein externes PWR nicht herum. MBus werde ich nicht mehr weitermachen, daher braucht es auch keine 2TE Breite mehr.

ja hätte ich - aber der branch https://github.com/OpenKNX/OAM-Modbu...New_HW_Version bekomme ich nicht zum laufen?
Ist da schon dein aktueller Stand gepsuhed?

Nein die Firmware gibt es aktuell nur bei mir und das wird auch solange bleiben bis ich denke jetzt passt alles. Die Version ist geeignet um zu testen, ob die Registerabfragen alle funktionieren, da fehlt aber noch etwas Fehlerhandling. Vor allem wenn mal ein kompletter Slave aussteigt und dieser viele Register abfragen implementiert hat. Dann wird bei jeder Abfrage immer gewartet bis das Timeout zu schlägt. Das blockiert den Bus unter umständen sehr lange. Das Feature ist in der bestehenden Firmware drin, ob ich es so übernehme oder noch anpasse, muss ich schauen.

Im Moment suche ich jemand, der mehr als nur einen Modbus RTU Slave hat und auch von KNX->Modbus Befehle schreiben kann.

Ich habe schon viel getestet, mit unterschiedlichen Aufbauten und unterschiedlichen Baudraten. Es war teilweise total verrückt. Mit einer Baudrate ging es und mit einer anderen nicht. Mit dem Logik-Analyser gemessen und gesehen, mein Gateway schickt alles richtig raus, aber es kam einfach nichts zurück. Keine Ahnung warum sich die Zähler nicht mehr gemeldet haben. Dann habe ich zwischen den Abfragen Delays eingefügt und dann wurde es besser.

Wenn du hier was testen willst, lass es mich wissen. Bei nur einem Slave hatte ich aber so gut wie keine Probleme, der Aufbau müsste schon etwas "größer" sein.

hab gerade gesehen das du fleissig warst. Konntest du das 64 Bit Thema mit integrieren?,

Ich habe es mir angeschaut: Wie gehe ich mit 64Bit Werten um, wenn die meisten DPTs aber nur 32Bit können. 64Bit DPTs, da gibt es glaube ich nur den DPT29, oder?
Daher die Frage noch einmal zurück, die stellst du dir die 64Bit Implementierung vor?

Die neue FW läuft auch auf dem alten Gateway?

Noch nicht, aber später dann ja. Wichtig ist nur: Es geht nur auf den Modbus-Gateways(Rp2040) die es seit Anfang 2023 gibt. Alles davor ist noch mit dem SAMD-Mikrocontroller und der hat leider nicht mehr die Ressourcen um die aktuelle OpenKNX-Version aufzunehmen.

Ich werde es daher erst veröffentlichen, wenn alles soweit fertig ist.

[IPv6]

Ich bin leider mit dem Haus noch nicht weit genug zum Modbus testen, hätte aber im kommenden Jahr großes Interesse an dem Projekt.
Im Technikraum wollen zumindest ein paar Datenpunkte von der Lüftungsanlage, der Wärmepumpe und dem PV Wechselrichter ins KNX übergeben werden. Modbus sprechen die alle von Haus aus, KNX Erweiterungsplatinen sind entweder nicht verfügbar (Wärmepumpe, WR) oder sündhaft teuer (Lüftung, exakt die selben Datenpunkte wie per Modbus).

Problem:
Alle drei Geräte haben unterschiedliche Konfigurationen was Baudraten, Parity und Stopbits angeht, teilweise nicht einstellbar. Sprich es gibt keine Einstellung, mit der ich alle drei Geräte abfragen kann.
Wäre es möglich, für unterschiedliche Modbus Adressen unterschiedliche Buseinstellungen anzubieten? Oder einfach drei Gateways verbauen? Das wäre etwas mit Kanonen auf Spatzen geschossen, da jeweils nur etwa 10 Datenpunkte benötigt werden, aber wenns nicht anders geht...

[Ing-Dom]

Du hattest nur die billigere Variante

achso, dann nimmst du gar nicht den "billigen" Chipanalog den ich gefunden und getestet hatte?

[Masifi]

achso, dann nimmst du gar nicht den "billigen" Chipanalog den ich gefunden und getestet hatte?

Jetzt ist der drin. Ich glaube der ist sogar Pin-Kompatibel zum Analog Device. Das 1TE Gehäuse ist viel billiger, ich brauche jetzt nur noch 3PCBs statt 4, keine Kabel mehr. Jetzt ist es deutlich billiger und einfacher aufzubauen.

Wäre es möglich, für unterschiedliche Modbus Adressen unterschiedliche Buseinstellungen anzubieten?

Das habe ich sogar schon ausprobiert, nur wieder hinten angestellt, weil es beim Testen mit einer Einstellung schon Probleme gab. Das scheint jetzt behoben zu sein, dann könnte man das auch wieder aufnehmen. Eine KNXprod dafür gibt es schon, in der kann man 10 Slaves definieren und für jeden Slave eigene Settings.
Ich will nichts versprechen, aber die Zeichen stehen soweit gut, dass das klappen könnte.

Aber setzt erst einmal die Basics fertig machen und dann kann man darüber reden

[IPv6]

Ich will nichts versprechen, aber die Zeichen stehen soweit gut, dass das klappen könnte.

Das klingt sehr gut - genau das sind Funktionen, die man bei Geräten der großen Hersteller vergeblich sucht. Ich bin gespannt!

Jetzt ist der drin. Ich glaube der ist sogar Pin-Kompatibel zum Analog Device.

Mich würde mal interessieren wie sich die Chipanalog ICs EMV technisch verhalten. Schon die iCoupler von ADI sind da nicht ganz unproblematisch, da gibt es gute AppNotes rund um den nötigen Aufwand beim Layout um gewisse EMV Grenzwerte einzuhalten. Um das wirklich ruhig zu bekommen sind da schon ein paar Klimmzüge erforderlich. Bei Chipanalog fällt die Doku dazu wesentlich weniger umfangreich aus, die grundlegenden Probleme sind aber die gleichen.

Das könnte in der Anwendung durchaus relevant sein, da es neben den abgestrahlten Störungen noch auf beiden Seiten des Isolators lange Kabelstrecken und weitere (möglicherweise empfindliche) Busteilnehmer gibt.

[mpl1337]

Ich hab ein Gateway von 2024 mit mehreren Slaves (Lüftung R/W, Zähler R, Belimo Stellantriebe R/W, Temperatursensoren R) ich würde mich trauen ...