Wie mit sehr vielen KOs umgehen?

[tuxedo]

Wäre ein Alias in der Device XML für später eine denkbare Option? Abhängig von Parametern heist eine KO einfach anders.

Zuerst dachte ich noch ein Alias wäre keine gute Idee, aber ich habe eben mal in diversen Handbüchern zu KNX Geräten geschaut... Dabei ist mir aufgefallen, dass ein KO mit ein und derselben KO-Nummer je nach Parametereinstellung anders genutzt wird.

Wenn man mal davon aus geht, dass die KO-Flags gleich bleiben, dann ist die einzige Unterscheidung eigentlich nur noch der Name des KOs. Oder hab ich was übersehen?

Damit könnte man bei ein und derselben KO-Anzahl bleiben, und die KOs nur unterschiedlich nutzen. Bis auf den Namen geht das eigentlich jetzt schon.

Jetzt müsste man nur mal schauen ob es einen eleganten und möglichste einfachen Weg gibt das KO entsprechend der Parametereinstellung von der es abhängt zu benennen. Aber was richtig gutes ist mir auf die schnelle noch nicht eingefallen.

[andi11]

Ich kann nicht einschätzen wie ernst das mit den 1k EEPROM ist. Aber sollten nicht gerade Geräte die soviel Variationsmöglichkeit haben (und nur die betrifft es ja) etwas Puffer haben? Immer nur wenn man viel verstellen kann und/oder viele Kanäle hat die man unterschiedlich konfigurieren kann.
Ich vermute ehr du willst die Library komplett generisch halten oder?

Würde es etwas helfen wenn die KO erst beim starten des Controllers im Array angelegt werden? Also das was jetzt der praktische Creator aus dem XML erzeugt, dass genau das erst zur Laufzeit erzeugt wird.

[tuxedo]

Du kannst das nicht erst zur Laufzeit erzeugen. Das Array trägt ein "const" davor... :-( Das umzubauen ist enorm. Hab ich schon mal Ansatzweise versucht, es dann aber wieder gelassen.

Gerade für sehr kleine Geräte (wie z.b. die UUPS) ist es praktisch wenn man die kleinen AVRs (32u4...) nehmen kann. Und die haben nur 1k EEPROM. Noch sind die zu weit verbreitet und finden eine hohe Akzeptanz als dass ich da gleich einen externen EEPROM oder dergleichen vorschreiben will/kann. Der braucht ja auch wieder Platz und Pins...

Die Lib sollte schon generisch bleiben. ich könnte zwar tatsächlich durch ein Präprozessor-Flag mehr als 85 KOs einräumen. Aber der das bläst alles noch weiter auf. Und das ziemlich unnötig.

Die Idee mit dem Alias ist aktuell mein Favorit. Einer der gründe ist, dass die Konnex das wohl auch so macht/vorschlägt. Der Arduino-Code bleibt der gleiche. Man müsste nur die XML entsprechend gestalten. Und hier ist eigentlich nur die Frage wie man das sauber abbildet.
Ein wenig bauschmerzen hab ich mit der "umbenennerei" der KOs auch. Denn jetzt ist noch alles in einer Sprache gehalten. Es ist aber nur eine Frage der Zeit bis der Ruf nach Multi-Language Gerätedefinitionen kommt. Und dann könnte es schnell hässlich werden.
Sich ganz allgemein auf die schnelle was zu überlegen das jetzt funktioniert ist nicht das Problem. Das so zu gestalten dass es mitwachsen kann ohne dass man alles über den haufen werfen muss ist die wahre Kunst. Da geht schon einiges an Hirnschmalz drauf.

[andi11]

Ja ich habe vorgeschlagen ohne abschätzen zu können, wieviel Aufwand das ist.
Das mit dem mitwachsen ist so ziemlich das schwierigste finde ich.

Ich denke im ersten Moment wäre das alias im Bereich Dependencies gut aufgehoben. Mehrsprachigkeit schiebe ich gerne immer auf die Leute ab, die was wünschen also "übersetz das mal bitte" damit erledigt sich das meistens sehr schnell. => Je sprache ein komplett autarkes xml?

[tuxedo]

Ja, je Sprache ein komplett eigenes XML... So war die anfängliche Idee. Aber das zu pflegen wird auch doof. Da wäre es schöner man würde nur noch mit Referenzen zu Texten arbeiten und je nach Sprache eben in einem anderen XML-Unterelement den entsprechenden Text nachschlagen. Auf sowas wird's hinaus laufen.


Bin aktuell dran zu schauen wie das in einer ETS Produktdatenbank mit der Mehrfachnutzung von KOs abgebildet ist.

Wie hast du dir das bei den Dependencies denn vorgestellt?

[andi11]

<CommObjectAliasDependency CommObjId="1" Alias="Schalten" Test="eq" TestParamId="5" TestValue="01"/>
<CommObjectAliasDependency CommObjId="1" Alias="Dimmen" Test="eq" TestParamId="5" TestValue="02"/>
ist zwar nicht die kompakteste und cleverste Lösung bleibt aber der Linie treu dass die XMLs einfach bleiben.

[tuxedo]

Erste grobe zusammenfassung wie es die ETS in der XML gelöst hat:



Es gibt eine "Tabelle" in der XML mit KOs. Da gibt es keine Nummernbegrenzung. Hier kann die Nummerierung locker in den Hunderter-Bereich gehen.
Jedes KO ist hier eindeutig mit seinem Namen versehen. Hier findet man also, noch ohne weitere KO-ID die ganzen "doppelbelegungen" der KOs wie man sie dann in der ETS je nach Parameter zur Auswahl hat.

Ein Beispiel (jede Zeile enthält noch Beschreibung, DPT und sonstiges, hab ich der Übersicht wegen aber weggelassen):

Nr. 1 - Funktion A
Nr. 2 - Funktion B
Nr. 3 - Funktion C

Dann gibt es eine Tabelle die KO-Referenzen beinhaltet. Hier findet eine 1:1 Zuordnung zwischen der tatsächlichen KO-ID und der Nummerierung der KOs aus der ersten Tabelle statt.

KO ID 0 - Ref1, Name A ---> KO Nr. 1
KO ID 0 - Ref2, Name B ---> KO Nr. 2
KO ID 1 - Ref3, Name C ---> KO Nr. 3

Man sieht hier schon die doppelte Vergabe der KO-ID, aber auch die eindeutige Referenz-ID dieser KO-Ausprägung.

Soweit ist das in der Produktdatenbank.

Im KNX Projekt ist dann die Ref-ID auf eine GA verknüpft. Fertig.

Kurzum: Es wird lediglich in die GA<->KO Beziehung eine weitere Beziehung eingebaut: GA<->Ref<->KO

Sowas ließe sich sicher bei uns auch machen. Aber bevor ich noch eine weitere Element-Gruppe einführe 8deren integration in das Gesamtsystem aufwendig wäre), mache ich das lieber in etwa so in Form eines weiteren ID-Attributs:

           <CommObject Id="0" CommObjId="1">
               <Name>My Second Com Object</Name>
               <Function>Test-Function #2</Function>
               <DataPointType>1.001</DataPointType>
               <Flags>42</Flags>
           </CommObject>
           <CommObject Id="1" CommObjId="1">
               <Name>My Second Com Object, but different</Name>
               <Function>Another Test-Function #2</Function>
               <DataPointType>1.001</DataPointType>
               <Flags>42</Flags>
           </CommObject>

Und über die Dependency schaltet man dann die eine oder andere "Id" ein oder aus. Für die Programmierung zählt dann aber die CommObjId.

So kann man mehrere verschiedene KOs haben, die alle auf die gleiche KO-Nummer abzielt. Ich muss dann nur einen Check einbauen (zur Sicherheit) dass es unter den aktivierten KOs keine Dubletten bzgl. der CommObjId gibt.

Oder fällt jemandem was besseres ein?

[andi11]

die Idee ist super schlank und schick

[tuxedo]

D.h. aber auch: Der Sketch muss anhand der Parameter wissen wie er ein KO zu benutzen hat. Das wird unter Umständen spaßig das übersichtlich und wartbar zu gestalten :-)

Aber immerhin wäre diese Lösung weitgehend abwärtskompatibel. Muss mir noch überlegen ob, wenn "CommObjId" fehlt, ich dann einfach den Wert von "Id" übernehme, oder ob ich das neue Attribut verpflichtend vorschreibe.. Tendiere eher zu letzterem, was zur Folge hätte, dass man die bisherigen XMLs alle nochmal anfassen muss. Aber da könnte man ggf. ein Update-Script bauen das das Attribut nachrüstet.

[andi11]

Ja das wird bescheiden Ich befürchte auch das man da viel erst sieht wenn man wirklich am programmieren ist. Genau deswegen hab ich da schon im Vorfeld so nervig nachgefragt....

[andi11]

Ich habs jetzt mal zusammengeschrieben. Für meinen 16fach Aktor bräuchte es wenn er Einzeln / Rollo / Heizung kann:
160 Parameter und 144 Comobjects
Wenn mehrfach Verwendung möglich ist 88Comobjects

[tuxedo]

88KOs sind immer noch zu viel. Das Maximum sind 85KOs...

Ich würde, wenn ich du wäre, 2-3 Firmwares machen. Sprich: Die grundlegend verschiedenen Funktionen in separate Sketches trennen:

Schaltaktor <-> Rolladenaktor <-> Heizungsaktor

Das macht den Code auch einfacher und sicher lesbarer.
Niemand hat was davon wenn man für die Konfiguration nen halben Doktortitel braucht oder die Software mit ihren vielen If/Else dermaßen komplex ist, dass du zwar vielleicht den Schaltaktor-Teil weitgehend bug-frei hast, der Rest aber noch ne Krücke ist.

[andi11]

Ich mach jetzt für meine Anwendung eine Variante mit 5xRollo/Jalousie und 6xHeizungsaktor. Für meine Anwendung passt das, und dann schaue ich was sich mit der Library tut, wie generisch ich das machen kann. Soviele if/else braucht man ja nicht wenn man komplett unterschiedliche Funktionen hat. Das kann man ja ganz gut kapseln.

[tuxedo]

Da das Thema in einem anderen Thread (https://knx-user-forum.de/forum/proj...ng-suite/page2) auch mal wieder hoch kam, grabe ich diesen Thread mal wieder aus.

Ich hab etwas recherchiert und geschaut, was aktuelle KNX Geräte denn so können und machen:

Man unterscheidet wohl verschiedene "Profile". Das derzeit wohl gängige Profil ist das "System 7" (früher wohl BIM M 112 genannt). Diversen Quellen zufolge unterstützt dieses Profil bis zu

255 KOs
und 254 GAs

Dafür geht rechnerisch schon einiges an Speicher drauf (man muss die Sache ja in Form von Tabellen oder dergleichem im EEPROM und Co. abbilden).

255 KOs brauchen dann im EEPROM 256Bytes.
254 GAs brauchen, je nachdem wie man's genau abbildet, rund 510 bytes

Und dann braucht man noch eine Tabelle, die die GAs einem oder mehreren KOs zuordnet. Wenn man hier so viele Zuordnungen wie GAs erlaubt, hat man nochmal rund 510bytes.

D.h. wir wären bei 1276 Bytes und hätten noch keinen einzigen Parameter oder sonst etwas im EEPROM gespeichert.

Da wir sowieso die Entwicklung in Richtung SAMD21 Mikrocontroller schieben/drücken, und hier der Speicher weniger das Problem ist, steht folgende Idee im Raum:

Wir werden wohl, wie die offiziellen KNX Geräte, verschiedene "Profile" (vllt. nennen wir's auch anders, mal sehen) definieren.

Für die Controller wie dem SAMD mit ausreichend RAM und Speicher (Flash oder halt externen I2C EEPROM oder dergleichen), wird es das "Normale Profil" geben, das die Limits aus dem System7-Profil widerspiegelt. Hierfür sind dann rund mind. 1536 Bytes Speicher angeraten. 2048 wären natürlich besser.

Für Controller wie den 328p und 32u4 mit ihrem internen EEPROM der nur 1024 Bytes beherbergen kann, wird es ein "Abgespecktes Profil" geben. Dort wird dann nur eine Teilmenge vom Normalen Profil unterstützt. Wieviel muss man mal sehen. Aber die Rechnung mit 85KOs und 127GAs und 127 GA-KO-Verknüpfungen scheint realisierbar zu sein.
Es ist einem natürlich frei gestellt statt des internen EEPROMs einen externen EEPROM anzubinden und dadurch theoretisch mit den "kleinen µCs" doch wieder auf das "Normale Profil" zu gelangen. Allerdings muss man bedenken, dass man dafür auch mehr RAM benötigt. Man kann beim Empfang eines Telegramms nicht jedesmal 255 KOs und GAs live aus dem EEPROM holen. Das dauert zu lange und bringt das KNX Timing gehörig durcheinander.

Ergo: Neuere µC haben kein Problem damit, ältere kann man nach wie vor benutzen.

Evtl. wird es in Zukunft dann noch ein "Advanced Profil" geben, wo man deutlich mehr KOs und GAs verwenden kann (Weinzierl nennt das System B mit bis zu 65535KOs und GAs). Das wird aber wohl bis auf weiteres sehr potenten System vorbehalten sein. Beispielsweise einem Gerät das auf sowas wie einem RaspberryPi Zero oder dergleichen basiert (das wäre mein persönlicher Traum: KNX Geräte mit Java statt C/C++ ;-) ).


Das nur mal so als ausblick. Das alles in nur ein erster, etwas durchdachterer Gedanke der noch nicht in Stein gemeißelt ist. Aber mit beta5 sollte sich in der Richtung schon einiges tun.

[andi11]

"sounds like a dream" => Top