Wie mit sehr vielen KOs umgehen?

[andi11]

Anm. des Mods: Abgespalten aus dem Thread [https://knx-user-forum.de/forum/proj...se-kconfig-xml]

--------------------------------

Ok danke für die Infos.
Noch eine Frage zu CommObjectDependency habe ich da einen Denkfehler, oder muss ich das so machen:

über Parameter 1 kann man auswählen ob 2Kanäle einzeln verwendet werden / als Rollo / als Heizungssteuerung
Dementsprechend:
Einzeln:
CO0 Kanal1 Schalten
CO1 Kanal1 Status
Rollo:
CO2
CO3
Heizung:
CO4 Kanal1 Istwert
CO5 Kanal1 Sollwert

dementsprechend wird sehr viel programmiert oder? Eigentlich würden für diesen Fall ja 2 Comobjects reichen.

[tuxedo]

Ich versteh dein Problem nicht... Dauert dir die Programmierung zu lange, oder störst du dich daran dass KOs programmiert werden die aktuell überhaupt nicht genutzt werden?

Gerade zu letzterem: Du hast es hier mit einer BETA zu tun. Eine Beta-Version erhebt nicht den Anspruch auf "die abläufte sind optimal und können nicht weiter verbessert werden".
In Beta5 ändert sich das Programmierverhalten nochmal komplett. Die XML Struktur und große Teile der Lib bleiben für den Anwender aber gleich. Intern ändert sich das aber grundlegend.

Falls dir etwas "spanisch" oder "chinesisch" vor kommt: Bitte erstmal hier schauen:

https://github.com/KONNEKTING/Konnek...Library/issues
https://github.com/KONNEKTING/KonnektingSuite/issues

Wenn da das Problem noch nicht beschrieben ist, bitte im entsprechenden Projekt ein Issue aufmachen und detailiert beschrieben. Dann kann man sich das anschauen und abverfolgen.

Gruß
Alex

[andi11]

Wie du sagst es ist Beta, gute Arbeit, außerdem für lau => Warum sollte ich mich daran stören?
Ich frage nur ob es so ist, oder ob ich was falsch verstehe.
Ich habe in der Doku geschaut. Ich frage explizit danach, da gerade die Konfiguration den Großteil des Systems ausmacht.

Hätte sein können dass du sagst "ne ich will eh schon lange dynamisch zugewiesene KOs machen" dann hätte ich mir jetzt einen Workaround gebastelt und gewartet bis es dynamisch ist.

Ich würde nur gerne gleich von Anfang an möglichst viele Parameter und Comobjects mit in der XML einbinden, da man ja beim einfügen eines Parameters zwischen drin sonst quasi auf Werkseinstellungen zurück muss. Schau mal bei meiner Hardware 4 bzw 6 Taster. 12 bzw 16 Aktor Kanäle. Da läppert sich die Varianz in der Konfiguration sehr schnell. Wenns so ist dann isses so, aber vorher fragen schadet glaub ich nichts

[tuxedo]

Wenn du einen Parameter einfügst, dann hinten (id-mäßig). Wo er im UI auftaucht, hängt von der Gruppe der er zugeordnet ist ab.

Parameter nachträglich hinzufügen ist also weniger das Thema, und ist update-technisch auch kein Beinbruch. Und wenn es von der Sortierung her im UI gar nicht passt, können wir uns noch überlegen ob man dem Parameter in der XML noch ein Sortierungs-Atribut mitgibt. Das sollte dann nichts inkompatibel machen.

Die Anzahl der Parameter ist eigtl nur von der EEPROM-größe abhängig. Die Anzahl der KOs wird später auf 85 limitiert (das reicht aus, ist bei anderen KNX Geräten normalerweise nicht anders).

In Beta5 ist die EEPROM Aufteilung etwas anders:

Unbenannt.PNG 868 bytes (System+AddressTable+AssociationTable+CommobjTable ) sind dann schon von der Lib vorbelegt. Danach kommen die Parameter und da danach etwaige Benutzerspezifische Daten. Bei 1k EEPROM ist da nicht mehr beliebig Platz. Um genau zu sein noch 156 bytes.

Grund für diese Änderung und den damit einhergehenden Speicherverbrauch ist die möglichkeit der Zuordnung mehrerer GAs pro KO.

Ganz fertig ist das Schema noch nicht. Ist bisher die erste, etwas detailiertere Überlegung, die gerade Ansatzweise implementiert wird.

Wenn man mehr als 156 bytes für Parameter braucht, oder selbst viele Daten im EEPROM ablegen will: Per SPI oder I2C selbst einen EEPROM/Flash nachschieben. Oder den SAMD21 nutzen, der hat mehr Speicher.

Vielleicht behälst du das in der Entwicklung etwas im Hinterkopf und fragst im zweifel später nochmal nach.

[h2oundco]

Wo werden dann die Werte der Kommunikationsobjekte gespeichert?

[andi11]

Ja die KOs zu limitieren macht definitv Sinn. hab mir in ETS ein paar komplexere angeschaut, es schaut nur nach sehr viel aus, dafür verschwinden andere. Wobei ich mir das durchaus tricky vorstellen kann, da wechseln die Hersteller scheinbar sogar dynamisch die Datentypen usw.

[tuxedo]

KOs haben keine "Werte"...

In der AdressTable stehen die GAs drin. Gemäß ihrer Reihenfolge haben sie eine ID.
In der CommObjTable ist Platz für 85 Einträge. An Index 0 steht das erste, an Index 84 steht das 85. KO. In der Tabelle findet man nur die Einstellung des KOs (also z.B. dessen Flags), aber nicht die Gruppenadresse(n).

In der AssociationTable findet die Verknüpfung zwischen GA und KO statt. Jeweils mit der entsprechenden ID.

Wie gesagt, das ist bisher alles Beta5-Zeug und noch nicht einsetzbar oder oder "für einen ersten Test fertiggestellt". Bisher ist nur der Suite-Code fertig der den Speicher zum Schreiben in den Arduino fertig zusammenstellt (die Suite schreibt dan quasi direkt in den EEPROM, ähnlich wie die ETS es macht).

[andi11]

d.h. ich sollte mit Funktionen wie aus Beitrag #6 warten bis es Beta5 gibt oder?

[tuxedo]

Nein, das kannst du jetzt schon machen. Die einzige Auswirkung ist, dass jedes KO mitprogrammiert wird, auch wenn es nicht genutzt wird. Aber das macht sich maximal über die Dauer der Programmierung bemerkbar. Ohne Debug-Mode sollte das aber immer noch ratz-fatz gehen.

Behalte aber im Hinterkopf dass du mit einem 1k EEPROM ab Beta5 nur noch max. 156 bytes für Parameter und sonstiges zur Verfügung hast (sofern es bei dieser Planung bleibt). Anders lässt sich das Thema "mehrere GAs pro KO" leider nicht lösen.

[andi11]

die entscheidende Frage ist dann damit für mich, ob man 85KO haben darf, oder 85 aktive KO? Dass 1k EEPROm schnell knapp werden, kann ich verkraften ich hab 2kbyte

[tuxedo]

Du kannst 85KOs, 127 verschiedene GAs und 255 verschiedene GA->KO Zuweisungen haben. Ob die KOs dann aktiv sind oder nicht spielt keine Rolle für den EEPROM. Du kannst 0-85 aktive KOs haben.

Das sollte auch für große Dinge reichen.

[andi11]

Bei meinem Beispiel aus #6
Einzeln:
CO0 Kanal1 Schalten
CO1 Kanal1 Status
Rollo:
CO2
CO3
Heizung:
CO4 Kanal1 Istwert
CO5 Kanal1 Sollwert

Wären das 6KO pro Kanal. 16Kanäle habe ich. Obwohl realistisch vielleicht 3KO pro Kanal gebraucht werden. Wie könnte ich bei sowas dann rangehen? Wäre ein Alias in der Device XML für später eine denkbare Option? Abhängig von Parametern heist eine KO einfach anders.

[tuxedo]

Das wären in Summe 96 KOs. Hab noch nicht drüber nachgedacht wie die Konnex das im Detail macht. In der BCU SDK Doku ist mir nix bekannt wie man mit mehr als 85 KOs umgeht bzw. bzw mit aktiven/inaktiven KOs umgeht. Da ist das so gelöst wie oben dargestellt.

Die XML mit weiteren Flags oder abhängigkeiten aufbohren will ich vermeiden
Die ist jetzt schon Recht umfangreich. Und eigentlich soll es ja einfach bleiben... Das ist einer der grundlegenden Ansätze von KONNEKTING.

Das einfachste wäre es wenn man einfach mehr KOs über ein Präprozessor-Flag erlaubt. Aber das hat auch Auswirkungen auf den Speicherverbrauch im RAM.

Mein Tipp wäre, auch wenn du das nicht direkt hiren magst, die Applikationen abspecken und je nach Ausprägung verschiedene Firmwares anbieten (sofern möglich). Muss ja nicht unbedingt die eierlegende Wollmilchsau sein.

[andi11]

Ich kann dir da nur in allen Punkten zustimmen. Ich fand an Suite usw. eben richtig richtig gut "draufspielen und es geht sofort"

Allerdings brauch ich für verschiedene Firmware ne tolle Idee wie ich das aufteilen könnte. Klar nur für mein Haus ist das kein Problem sehr speziell zu coden, aber so ein bisschen generisch und damit austauschbar solls doch sein.

[tuxedo]

Naja, zuerst muss mal man schauen was das für sechs KOs sind die du da pro Kanal zur Auswahl bräuchtest. Und dann muss man schauen ob man nicht ein paar davon thematisch in eine anderen Firmware verschieben kann.
Wenn man aber ohne schwierigkeiten die ersten 8 Kanäle mit den esten drei KO-Typen belegt und die nächsten 8 Kanäle mit den anderen drei KO-typen, dann klappt das natürlich nicht.

Ich rätsel gerade ob ich nicht einen Weg finde mit mehr KOs arbeiten zu können (und davon halt nur max. 85 aktiv zu machen) und dabei nicht noch mehr Speicher zu verbrauchen.

Sagen wir mal angenommen man bräuchte 255 KOs (10KOs pro einem Gerätekanal sind nicht allzu hoch gegriffen, dann sind wir bei 16 Kanälen schon bei 160 KOs... wovon niemals alle aktiv wären, bleiben wir da mal bei max. 85 aktiven wie bisher)... Dann müsste die Lib prinzipiell mal von 255 KOs wissen. Und man müsste ihr ebenfalls sagen, welches KO nun aktiv ist und welches nicht. Und das geht nur wieder über einen Eintrag im Speicher.

Wenn ich jetzt pro KO für aktiv/inaktiv 1 bit brauche, dann sind das bei 255 KOs 255 bit. 255 Bit lassen sich auf 32byte verteilen. Gut. Also 32 bytes mehr für den Status aktiv/inaktiv.
Wenn ich jetzt aber nicht davon ausgehen kann, dass in der CommObjTabelle der Index der KO-Nummer entspricht (davon konnte ich bisher aber ausgehen), muss ich noch ein weiteres Byte spendieren um die KO-Nummer in der CommObjTabelle mit abzulegen. Also statt 85 bytes sind es dann doppelt so viele bytes.

Um also 255 statt wie geplant 85 KOs, wovon nur 85 aktiv sein können im EEPROM zu hinterlegen, brauche ich 117 (=32+85) Bytes mehr. Statt 156 Bytes für Parameter sind dann noch 39 bytes übrig. Das geht nicht. Das ist zu wenig.

Da auch 1k EEPROM Geräte zulässig sein sollten, ist das eher ein NoGo ...

Man käme wohl nicht drum herum einiges an mehr Speicher zu investieren um mit mehr KOs (von denen auch nicht mehr als 85 aktiv sind) umzugehen.

Aber vielleicht hat jemand eine grandiose Idee die a) einfach ist und b) mit 1k Speicher auskommt.