[Frage] Wie Fehlercode-Mapping abbilden?

[starwarsfan]

Hallo miteinander,

bei der Profilerstellung bin ich an dem Punkt, das Fehlercode-Mapping abzubilden. Mein erster Test sieht so aus:

2021-02-27_ErrorcodeMapping1.png

Ich habe also für das Register 39040 im Mapping-Dialog eine Equals-Condition auf den Wert 0 angelegt und setze den Ausgang in diesem Fall auf ein Fixed value mit dem Wert Kein Fehler.

Dann habe ich das Register nochmal angelegt, dort jedoch die Condition auf den Wert 10 gesetzt und den Ausgang auf Aussenfühler.

In der Ansicht sieht das jetzt so aus:

2021-02-27_ErrorcodeMapping2.png

Wenn ich da wirklich alle 492 Errorcodes erfasse, dann ist davon ein Register ok und 491 invalid. Dazu kämen dann noch 270 Statuscodes. Ist das wirklich the-way-to-go oder muss ich das anders machen?

Zusatzfrage: Wann wird ganz unten der Duplicate-Button aktiv?

[StefanW]

Hallo Yves,

Wenn ich da wirklich alle 492 Errorcodes erfasse, dann ist davon ein Register ok und 491 invalid.

Genaug genommen sind nicht die Register ok oder invalid sondern die mit dem (einen) Register verknüpften Applikation (nur damit wir künftig den gleichen Sprachgebrauch haben). Eine eigene Bezeichnung war nötig, weil man das gleiche Register mehrmals anlegen kann. Wir haben uns hier ein wenig an den Namensgebrauch bei KNX angelehnt, auch weil man das letztlich mit anderen Objekten und deren Funktionalität und Logik verknüpft.

Dazu kämen dann noch 270 Statuscodes. Ist das wirklich the-way-to-go oder muss ich das anders machen?

Ich denke, für solche umfangreiche Auswertung von Enumerierungen muss man entweder die Logik bemühen oder es wird in der Modbus Implementierung noch eine Erweiterung wie ein solches Mapping durchgeführt werden kann.

Wir hier auch etwas angedacht, das nennen wir "Sub-Applikation", also die Möglichkeit eine Applikation um gruppierte Auswertungen zu erweitern, über welche solche Dekodierungen vorgenommen werden und insbesondere auch darauf geachtet wird, dass es hier eine Logik gibt, welche dafür sorgt, dass dann auch nur EIN Wert pro Gruppe gesendet wird und im Geräte Manager auch nur eine Verknüpfung pro Sub-Applikations Gruppe vorgenommen werden kann.

Das KÖNNTE so aussehen (das ist nur eine UI-Studie):

2021-02-03_Subapplikation_Planung_V2.png

Allerdings ist das aufwändig zu programmieren, insbesondere wenn jemand seitenweise Codes abtippen will. Wir wollten das Modbus-Leistungsmerkmal für normale Funktionen ausrollen, damit wir hier im Frühjahr 2021 auch zur Auslieferung kommen.

Ich kann Dir noch nicht sagen, wann wir die Auswertung von solchen Enummerierungen direkt in der Modbus-Engine unterstützen werden können.

Zusatzfrage: Wann wird ganz unten der Duplicate-Button aktiv?

Zunächst wollen wir den Modbus Geräte Manager zur Verfügung stellen, damit das Leistungsmerkmal Modbus durch die damit verfügbaren Objektverknüpfungen auch im Timberwolf Server nutzbar ist.


Rückfrage: Willst Du wirklich die Auswertung von ein paar hundert Status- und Fehlercodes anlegen?

lg

Stefan

[gbglace]

Du Applikationen sind dann natürlich schon der richtige Komfort-Schritt um eben auch nicht 492 Leseprozesse zu haben. Bis dahin lässt sich das Mailing dann nur im LE machen, in dem der Fehlercode ausgelesen wird und dann einmal übersetzt und ggf weitere Aktionen binär ausgelöst werden je Code.


Naja für.ein umfangreiches Anlagenmonitoring ist das schon was feines. Als Techniker genügt einem womöglich schon der Fehlercode selbst, weil die wohl aus Erfahrung die üblichen Verdächtigen auswendig gelernt haben. Als detailverliebter Endkunde will man sich dann aber schonmal das Blättern im Handbuch sparen und das direkt angezeigt bekommen.

Aber schonmal interessant das da überhaupt so ein Register existiert wo man sowas geliefert bekommt.

[StefanW]

Hallo Göran,

Aber schonmal interessant das da überhaupt so ein Register existiert wo man sowas geliefert bekommt.

Ja, die Modbus Implementierungen bei manchen Wärmepumpen und Wechselrichtern sind außerordentlich gesprächig.

Wenn man sich mal die Datenblätter von SMA oder auch Siemens usw. ansieht, dann ertrinkt man geradezu in Möglichkeiten. Das liegt wohl auch daran, dass diese Hersteller die Kommunikation deren Produkte für Admin-Tools und Benutzeroberflächen ebenfalls über diese Modbus-Implementierung abbilden, daher auch die vielen Fehler- und Statuscodes.

Im Vergleich zu KNX Schnittstellen für solche Produkte (sofern überhaupt verfügbar) sind die Möglichkeiten per Modbus vervielfacht. Dürfte auch daran liegen, weil das KNX Zertifizierungsverfahren jede einzelne abgebildete Funktion teuer macht, weil jede einzeln geprüft wird und man sich im Umfang auch zusammenreißen muss, weil die ETS sonst mit zuvielen Objekten überlastet wird.

Bei Modbus könnte man auf einer einzelnen Geräteadresse bis zu 262.000 einzelne Register abbilden mit - im Vergleich - geringen Implementierungskosten.

Diese neue Größenordnung bei der Auskunftsfreude der großen Modbus-Geräte war dann auch der Grund dafür, dass wir uns zu dem (sehr aufwändigen) Leistungsmerkmal der Profile entschieden haben, damit durch den damit möglichen Austausch der Profile der Definitionsaufwand nach Möglichkeit nur noch eine Person in der Community trifft und damit der Anschluss dieser Geräte für alle einfacher wird.

Weil für nachfolgende Nutzer heißt das dann nur noch: Modbus Geräte Manager aufrufen, Gerät anlegen, Profil auswählen, Namen vergeben, Adresse angeben und schon ist das Modbus Gerät Online. Nun noch die Applikationen verknüpfen und schon hat man die Daten, wohin auch immer man diese nutzen möchte. Einfacher geht das nicht mehr.

Es wäre toll, wenn sich diese Erleichterung in Verbindung mit dem Timberwolf Server herumsprechen würde, weil Modbus wird erst damit richtig leicht handhabbar und die Zeitersparnis ist enorm.

lg

Stefan

[starwarsfan]

Genaug genommen sind nicht die Register ok oder invalid sondern die mit dem (einen) Register verknüpften Applikation (nur damit wir künftig den gleichen Sprachgebrauch haben). Eine eigene Bezeichnung war nötig, weil man das gleiche Register mehrmals anlegen kann. Wir haben uns hier ein wenig an den Namensgebrauch bei KNX angelehnt, auch weil man das letztlich mit anderen Objekten und deren Funktionalität und Logik verknüpft.

Klar. Das was jeweils "links rein geht", ist ja in dem Fall überall gleich und wird unterschiedlich bewertet.

Ich denke, für solche umfangreiche Auswertung von Enumerierungen muss man entweder die Logik bemühen oder es wird in der Modbus Implementierung noch eine Erweiterung wie ein solches Mapping durchgeführt werden kann.

Zunächst mal finde ich es genial, das Thema überhaupt auf diesem Level zu besprechen!

Weiteres weiter unten...

Wir hier auch etwas angedacht, das nennen wir "Sub-Applikation", also die Möglichkeit eine Applikation um gruppierte Auswertungen zu erweitern, über welche solche Dekodierungen vorgenommen werden und insbesondere auch darauf geachtet wird, dass es hier eine Logik gibt, welche dafür sorgt, dass dann auch nur EIN Wert pro Gruppe gesendet wird und im Geräte Manager auch nur eine Verknüpfung pro Sub-Applikations Gruppe vorgenommen werden kann.

Sounds like a plan!

Das KÖNNTE so aussehen (das ist nur eine UI-Studie):

Wow, da bin ich glatt sprachlos. Selbst wenn's nur ein Entwurf ist, muss man das erstmal setzen lassen...

Allerdings ist das aufwändig zu programmieren, insbesondere wenn jemand seitenweise Codes abtippen will. Wir wollten das Modbus-Leistungsmerkmal für normale Funktionen ausrollen, damit wir hier im Frühjahr 2021 auch zur Auslieferung kommen.

Ich kann Dir noch nicht sagen, wann wir die Auswertung von solchen Enummerierungen direkt in der Modbus-Engine unterstützen werden können.

Ich habe mich aus gutem Grund erstmal nur daran gemacht, von den verschiedenen Möglichkeiten jeweils nur einige umzusetzen um zu prüfen, ob das dann in Gänze so passt oder anders gelöst werden kann/soll/muss. Das hier ist nun genau so ein Punkt da ich mir ungern die Arbeit mache und dann hinterher feststellt, dass das nicht im Sinne des Erfinders ist.

Zunächst wollen wir den Modbus Geräte Manager zur Verfügung stellen, damit das Leistungsmerkmal Modbus durch die damit verfügbaren Objektverknüpfungen auch im Timberwolf Server nutzbar ist.

Vollkommen klar, kein Problem.

Rückfrage: Willst Du wirklich die Auswertung von ein paar hundert Status- und Fehlercodes anlegen?

Nun, ich werde die sicher nicht händisch abtippen. Aber da ich die Unterlagen digital habe, werde ich die Generierung des json scripten.

Um das für diesen Fall zu konkretisieren: Ich habe in meiner Wärmepumpe (WP) von CTA eine Steuerung von Siemens. Dazu habe ich die Modbus-Doku vom Hersteller der WP, in welcher die von der WP verwendeten Datenpunkte (DP) beschrieben sind. Das ist schon eine gute Menge. Dann habe ich mittlerweile aber auch die vollständige Doku von Siemens und festgestellt, dass bei meiner WP nur ein Subset der DP verwendet wird, welche die Steuerung tatsächlich kennt. Selbiges gilt auch für die Error- und Statuscodes. Wenn ich nun aber ein Profil für diese Steuerung erstelle, dann würde ich schon gern ein komplettes Profil anlegen. Das könnte dann überall dort verwendet werden, wo eine Siemens RVS21- oder RVS61-Steuerung drin steckt und das sind bei weitem nicht nur die WP von CTA.

[Sun1453]

Hallo Stefan,

also auch ich bin von der UI-Studie geplättet. Also das hebt die ganze Sache in Zukunft nochmal auf eine ganz andere Ebene. Aber ich verstehe das ihr jetzt erstmal in gänze mit der ModBus Implementierung raus möchtet. Aber so als Upgrade und Sahne Häubchen für die Zukunft ist das echt Mega.

Also so einfach wie man aktuell mit dem Profil Editor die Applikationen baut ist echt genial. Das gibt es einfach nicht am Markt. Die Live Analyse ist dann der Kracher oben drauf. So sieht man sofort Fehler und kann diese noch bevor diese irgendwo angeliefert werden, korrigieren. Man hat dadurch auch keinen Datenmüll in der Zeitserie oder auch irgendwo anders.

[eib-eg]

Hallo Michael @Sun1453

Auch hier meine Frage an dich aber nur als link
viewtopic.php?f=80&t=2723#p30769

[starwarsfan]

Hallo miteinander

Nun, ich werde die sicher nicht händisch abtippen. Aber da ich die Unterlagen digital habe, werde ich die Generierung des json scripten.

Wen es interessiert: Hab' jetzt eben mal mit einem Bash-Einzeiler zählen lassen, wieviele Register es denn tatsächlich sind:

Code: Alles auswählen

while IFS=, read a b c register readWrite f g comment parameter j ; do if [ -n "$register" ] ; then echo $register ; fi ; done < ModbusParameterlist_Datapoints.csv | wc -l
1287

Gibt dann also ein Profil mit 1287 Registern.

Der tatsächliche Inhalt stellt sich für die ersten paar Register so dar:

Code: Alles auswählen

while IFS=, read a b c register readWrite f g comment parameter j ; do printf "%10s: %-30s (%s)\n" "${register}" "${comment}" "${parameter}" ; done < ModbusParameterlist_Datapoints.csv
      1024: Operating Mode                 (0: Protection)
          :                                (x 1: Automatic)
          :                                (2: Reduced)
          :                                (3: Comfort)
      1025: Comfort setpoint               ()
      1026: Reduced setpoint               ()
      1027: Frost protection setpoint      ()
      1028: Heating curve slope            ()
      1029: Heating curve displacement     ()
      1030: Summer/winter heating limit    ()

Dabei ist die erste Spalte das Register, die zweite Spalte der entsprechende Kommentar dazu und die dritte Spalte die Parameter bei R/W-Registern.

Stay tuned!

[starwarsfan]

Hallo @StefanW,

die Vorbereitungen für den Profil-Import machen Fortschritte. Ich möchte ungern die Kommentare aus der Dokumentation unterschlagen, die Länge des Eingabefeldes der Description ist aber nur 127 Zeichen lang. Für den allergrössten Teil der Profile wird das wohl ausreichend sein, aber dennoch an dieser Stelle die Frage, ob es dafür einen bestimmten Grund gibt. Zudem sind nur ca. 32 Zeichen direkt sichtbar. Habt ihr noch Verbesserungen in der Queue?

Es ist mir klar, dass das nicht vom Himmel fällt aber bspw. wäre das hier:

Code: Alles auswählen

x 0: No test / 1: Everything off / 2: Relay output QX1 / 3: R. o. QX2 / 4: R. o. QX3 / 5: Output QX4/ZX4 / 6: R. o. QX5 / 7: R. o. QX6 / 8: R. o. QX7 / 9: R. o. QX8 / 10: R. o. QX9 / 11: R. o. QX10 / 12: R. o. QX11 / 13: R. o. QX12 / 14: R. o. QX13 / 15: R. o. QX31 / 16: R. o. QX32 / 17: R. o. QX33 / 18: R. o. QX34 / 19: R. o. QX35 / 20: R. o. QX21 module 1 / 21: R. o. QX22 module 1 / 22: R. o. QX23 module 1 / 23: R. o. QX21 module 2 / 24: R. o. QX22 module 2 / 25: R. o. QX23 module 2 / 26: R. o. QX21 module 3 / 27: R. o. QX22 module 3 / 28: R. o. QX23 module 3

... wesentlich besser so zu lesen (bspw. als Popup oder Tooltip):

Code: Alles auswählen

x 0: No test
1: Everything off
2: Relay output QX1
3: R. o. QX2
4: R. o. QX3
5: Output QX4/ZX4
6: R. o. QX5
7: R. o. QX6
8: R. o. QX7
9: R. o. QX8
10: R. o. QX9
11: R. o. QX10
12: R. o. QX11
13: R. o. QX12
14: R. o. QX13
15: R. o. QX31
16: R. o. QX32
17: R. o. QX33
18: R. o. QX34
19: R. o. QX35
20: R. o. QX21 module 1
21: R. o. QX22 module 1
22: R. o. QX23 module 1
23: R. o. QX21 module 2
24: R. o. QX22 module 2
25: R. o. QX23 module 2
26: R. o. QX21 module 3
27: R. o. QX22 module 3
28: R. o. QX23 module 3

Ganz davon abgesehen, dass es mit nur 127 Zeichen sowieso nicht komplett abgebildet werden kann.

Wie gesagt, ich möchte nur die Möglichkeiten abklopfen, bevor ich mir hier irgendetwas verbaue. Es wäre aber auch kein Problem, dort einfach RTFM abzufüllen.

[StefanW]

Hi Yves,

Welche Description? Die des Profiles oder die der Applikationen?

Stefan