Mehrere GAs pro KO?!

[tuxedo]

Moin,

was mir gestern Abend siedend heiß aufgefallen ist:

KONNEKTING kann aktuell nicht meherer GAs pro KO verwalten... In der ETS ist das ja kein großes Thema... Einfach mehrere GAs einem KO zuweisen. Das KO reagiert dann auf alle zugewiesenen GAs.

KONNEKTING hat hier aber eine 1-zu-1 Beziehung zwischen GA und KO. D.h. es kann aktuell nur eine GA pro KO geben...

Das zu ändern hätte strukturelle Änderungen im Device Lib Code zur folge... Ganz einfach ist das sicher nicht.

Hab mal ein Ticket aufgemacht damit das Thema nicht in Vergessenheit gerät:
https://github.com/KONNEKTING/KonnektingSuite/issues/11

Da wir uns langsam aber sicher einer stabilen Version 1.0 nähern, sollten wir uns

a) im klaren sein ob wir dieses Feature brauchen (oder einfach definieren dass es sowas nicht gibt/geben wird)
und ggf.
b) das Protokoll schon mal soweit formen, dass es ohne Protokolländerungen möglich wird (auch wenn am Device-Lib Code erstmal keine großen Strukturellen Änderungen gemacht werden)

Meinungen hierzu sind willkommen....

Gruß Alex

[Eugenius]

Ich brauche es aktuell nicht, deswegen noch nie aufgefallen. Evtl. liegt es daran, dass wir bis jetzt nur senden und nicht "zuhören"

[tuxedo]

Spätestens mit Masifi 's LED Dimmer "könnte" das Problem akut werden. Denn da geht es ja um "zuhören".
Ich muss mal ins Protokoll schauen ob sich das dort bereist abbilden lässt, oder ob wir da noch etwas aufbohren müssen.

Device-Lib seitig wird die Sache sicherlich etwas "unschön". Denn bei eingehenden Write-Telegrammen wird die Liste mit KOs durchgegangen, und geschaut ob da ein KO dabei ist, dessen GA zum Telegramm passt.
Um jetzt mehrere GAs pro KO abbilden zu können, müsste man das KO in der Lib aufbohren, so dass es mehrere GAs halten kann. Das wird dann schnell auf ein Array hinaus laufen.. Und mit denen steh ich in C irgendwie auf Kriegsfuß :-)

[Eugenius]

Spätestens mit Masifi 's LED Dimmer "könnte" das Problem akut werden.

Nicht nur Dimmer, bei einem Aktor könnte es noch schlimmer werden.
Ich sehe das locker: Wir entscheiden wie die Firmware aussieht und können die immer anpassen => mehrere KOs definieren. Ist zwar nicht so bequem wie in ETS gelöst, aber machbar.
Wenn man mehrere GAs zu einem KO zuordnet, dann sind die praktisch per ODER verknüpft => mehrere zuschalbare Logiken in Sketch vorsehen und so das Problem lösen.

Das wird dann schnell auf ein Array hinaus laufen.. Und mit denen steh ich in C irgendwie auf Kriegsfuß :-)

nicht nur du

[tuxedo]

Hmm, wenn wir uns auf max 3 GA's pro KO festlegen würden, würde das ohne große Protokolländerung reinpassen:

https://github.com/KONNEKTING/Konnek...ritecommobject

Wir haben Byte 2-13 zur Verfügung. Also 11 bytes in Summe.
Pro GA brauchen wir 3 bytes (GA-lo, GA-hi, GA-settings). Bei drei GAs, wären das dann 9 bytes in Summe. Blieben zwei Bytes noch übrig (da könnte man reinschreiben wieviele GAs dem KO genau zugeordnet sind oder andere Meta-Daten noch mit reinpacken.

Aber ob es eine gute Idee ist nur 3 GAs zuzulassen?! Wäre in jeder Hinsicht eine Limitierung die der eine oder andere wohl schnell erreicht.
Aber limitieren müssen wir's irgenwie. Nicht aus Lust und Laune, sondern weil uns sonst irgendwann der EEPROM Platz ausgeht.

Die Frage ist dann halt: Wo liegt das sinnvolle Limit?

Bei dreamy1 's Sensor haben wir glaub ich über 30 Parameter. Die meisten davon sind 1 byte lang/groß. Gehen wir mal von einem mittelgroßen Gerät aus, das 50 Parameter hat. Dann schätzen wir Größe der Parameter auf 70 bytes.

Dann gehen wir mal von 30 KOs aus. Nicht jedes KO hat mehr als eine GA. Sagen wir mal wir landen am Ende bei 50 GAs (ist vllt. hochgegriffen, aber bleiben wir mal dabei).

50GAs * 3 bytes (GA-hi, GA-lo, GA-settings) = 150 bytes.

Zusammen mit den 70 bytes der Parameter, haben wir dann 220 bytes.

Da wir dann im EEPROM nicht an einer festen Stelle nach der GA suchen können, sondern eine Art frei definierbare Tabelle abbilden müssen, kommen nochmal mind. 60 Bytes für den KO-Index (1 byte für KO ID und 1 byte für Anzahl GAs) dazu.

Macht 280 bytes.

Dann kommen noch eine Hand voll Meta-Daten dazu, sagen wir nochmal 10 byte und wir landen bei 290 bytes von 1024 möglichen bytes.

Da ist also noch Luft nach oben...


Kurz um: Der EEPROM macht uns da das leben nicht schwer. Viel schwieriger wird, das sauber und strukturiert im EEPROM abzulegen. Da muss ich mir entweder

a) eine neue Datenstruktur überlegen
oder
b) mal schauen wie das andere Geräte machen

Ich sehe das locker: Wir entscheiden wie die Firmware aussieht und können die immer anpassen => mehrere KOs definieren. Ist zwar nicht so bequem wie in ETS gelöst, aber machbar.
Wenn man mehrere GAs zu einem KO zuordnet, dann sind die praktisch per ODER verknüpft => mehrere zuschalbare Logiken in Sketch vorsehen und so das Problem lösen.

Klar, das geht. Aber das ist weit entfernt von "praktikabel". Willst du dann jedes KO in x-facher Ausführung in der XML anlegen, nur um mehr als eine KO zuweisen zu können? So lapidare Dinge wie "ein LED Ausgang soll mit 5 unterschiedlichen GAs angesteuert werden können" wird dann unheimlich schnell zum KO-Monster.
5GAs pro KO und 9 LED Ausgänge (wie bei Matthias' Dimmer), machen dann gleich 45 KOs die du in der XML definieren musst... statt nur 9 KOs (wenn man einem KO mehr als eine GA zuweisen kann). Und das sind jetzt nur die Auswirkungen bei 9KOs ... Was wenn ein Gerät normalerweise 30KOs hat?

Und zuguter letzt soll die Suite ja noch bedienbar bleiben...

Je länger ich darüber nachdenke, desto mehr Bauchschmerzen bekomm ich.

[bernsen]

Hallo,
sehe das ein wenig wie Eugenius.
Würde es erstmal lassen wie es ist und zur Not mit externer Logik abbilden.

[tuxedo]

Das Problem mit "erstmal lassen" und "ggf. später nachrüsten" wird unheimlich schnell "sau blöd" wenn sich die ersten Geräte erstmal etabliert haben.

Könnte gut sein, dass das eine Änderung ist, die nicht abwärtskompatibel ist :-(

Ich schau gerade nochmal im Detail wie das in der BCU implementierung implementiert ist...

Die Datenstruktur im EEPROM sehen jedenfalls schon mal nicht soo verkehrt aus. Sollte sich bei uns umsetzen lassen:

Jede GA wird erstmal zusammenhangslos im EEPROM abgespeichert. Ab einem bestimmten Index, einfach fortlaufend. DAVOR steht wieviele GAs es gibt.

Die GAs sind dann der Reihenfolge nasch durchnummeriert. Dadurch dass man weiß wieviele es sind, weiß man wo die nächste freie Stelle im EEPROM ist.

Und an dieser ist eine "Verknüpfungstabelle" abgelegt:

Zuerst wieder die "länge" der Tabelle, gefolgt von den Verknüpfungsdaten.

Ein Datum besteht aus zwei byte... das erste byte ist die Nummer der GA (Nummer aus der Reihenfolge der GAs), und das zweite byte ist die ID des zugewiesenen KO.

Damit kann man beliebig viele GAs einem KO zuordnen.

----

Wie die Daten im EEPROM am besten Platz finden hat sich nun geklärt. Die Implementierung dessen ist nicht so schwer. Ist noch die Frage:

- Wie sieht die Codeänderung aus die die KOs in der Device-Lib um (beliebig) viele GAs erweitert?
- Wie machen wir das Protokollseitig


Die BCU und die ETS machen das wohl auf Seite des PCs. Sprich: Die Konfiguration eines Geräts mit Parametern und KOs wird auf dem PC zu einem zusammenhängen Binärdaten-Paket für den EEPROM zusammengestellt. D.h. nicht die KOs und Params werden zum µC übertragen und der trägt die dann nach einem bestimmten Muster in den EEPROM ein, sondern das wird alles auf Seite des PC vorbereitet und die Daten dann ohne weitere "Datenstrukturlogik" in den EEPROM des µC geschrieben ("memory write"). Das Protokoll weiß also quasi nix von KOs und Parametern, sondern kann nur X bytes an eine Position Y in den EEPROM schreiben. Der µC muss dann wissen wie er die EEPROM-Daten zu verstehen hat.

Das ist natürlich super flexibel. Passt aber nicht so doll in unser Konzept. Warum?
Unser Protokoll lässt sich ohne große Schwierigkeiten im Gruppenmonitor der ETS mitlesen. Github-Seite mit der Protokoll-Doku daneben legen und man kann direkt sehen welches Telegramm was genau macht/schreibt.

Entweder wir legen uns Protokollseitig erstmal auf 3 GAs pro KO fest (dann ändert sich das Protokoll nur minimal), oder wir erfinden ein neues Telegramm zum programmieren das das ganze besser abbildet.

Ich muss mir da mal meine Gedanken machen....

[Masifi]

Wenn das jetzt noch "einfacher" geht, dann würde ich jetzt mal auf die 3GA auf ein KO gehen. Und mit 3 kann man auch gut leben, denke ich mal.
Ich gebe Tuxedo recht, nachher sowas zu ändern kann unter umständen wehtun, oder es wird irgendwie alles unkompatibel.

[Eugenius]

Ich würde auf jeden nicht alle 11 Bytes dafür ausnutzen, ein paar Bytes Sicherheit lassen (man weiß ja nie was uns noch einfallen kann).

[tuxedo]

Hab gestern Abend auf den Heimfahrt vom Büro noch etwas gegrübelt...
Hier nochmal das angedachte EEPROM-Schema für GA + KO:

schema.png

Nochmal der Vergleich zu bisher:
Bisher gab es pro KO eine GA. D.h. die Anzahl der GAs war bekannt, bzw. der Platz den man im EEPROM dafür vorsehen musste war bekannt.

Das heißt, die Stelle an denen dann die Parameter im EEPROM stehen, hat sich aus der Anzahl KOs ergeben.

Mit dem neuen Schema gibt es keine festen Stellen mehr im EEPROM die sich aus der Anzahl der KOs oder Parameter ergeben.
Hinzu kommt, dass die bisherigen Programmier-Telegramme KO+GA enthalten haben. Auch wenn ich da jetzt 3 GAs in ein Telegramm stecke (weil noch Platz im Telegramm ist), dann hab ich das Problem dass ich erst _alle_ GAs in den EEPROM schreiben muss, diese mir mit einer fortlaufenden Nummer versehen und diese Nummern im RAM halten muss, und dann erst die Zuordnung der GA-ID zusammen mit der KO-ID in den EEPROM speichere.

Das riecht nach aufwendigem Code seitens des Arduino.

Ich denke ich muss hier in sofern umbauen, als dass das ganze auseinanderdröseln der vielen GAs und KOs auf Rechner-Seite mache und, wie es die ETS auch macht, dort den EEPROM-Inhalt vorbereite. Dort hab ich nämnlich per RAM und Ressourcen zur Verfügung (und kann das bequem in Java machen ) und muss dann nur noch die EEPROM-Daten in Telegramme verpacken. Der Arduino muss dann nix weiter tun als die Daten 1:1 ab einer bestimmten Stelle in den EEPROM schreiben.


An der Sache "stört" mich (ein klein wenig) nur folgendes:

* Ich baue damit teilweise eine BCU nach
* Dann könnte man ggf. auch gleich schauen ob man nicht das korrekte "property write" Telegramm implementiert
* der Verlauf der Programmierung ist dann im ETS Gruppenmonitor nichtmehr so ohne weiteres "lesbar" (aber wer hat das schon gemacht?!).

Einziger Vorteil wäre: Man spart jede Menge overhead und das programmieren dürfte ein wenig schneller ablaufen.

Ich muss da nochmal ein wenig drüber schlafen/philosophieren... vllt. fällt mir noch was anderes ein.

[Northman]

Wie es so schön neudeutsch heißt: just my 2 cents:

Die Änderung der Datenspeicherung bedingt jetzt Änderungen an drei Stellen:
1. Suite
2. Arduino EEPROM schreiben
3. Arduino EEPROM lesen

Wenn die nächste Änderung kommt, müssen wieder diese drei Stellen geändert werden. Und die nächste Änderung wird kommen :-)
Wenn das Schreiben im Arduino ein reines Durchreichen ist, müssen nur zwei Stellen geändert werden. Und das ein oder andere Byte RAM wird auch noch gespart :-)

* der Verlauf der Programmierung ist dann im ETS Gruppenmonitor nichtmehr so ohne weiteres "lesbar" (aber wer hat das schon gemacht?!).

Was genau bringt die Ansicht in der ETS? Also mir als Nutzer und nicht als Entwickler der Suite und Library? Gibt es Fälle in denen es für einen "Endanwender" hilfreich wäre?

* Dann könnte man ggf. auch gleich schauen ob man nicht das korrekte "property write" Telegramm implementiert

Bei der Gelegenheit bitte auch gleich ein "property read" :-) Mir kam vorhin der Gedanke, daß ein Vergleich zwischen Suite und Device hilfreich wäre.
Fiktives Beispiel: man programmiert sich eine eigene Temperaturregelung (Raum, Aquarium, Badewanne, ...) mit angeschloßenen 1-Wire-Sensoren. Im kdevice.xml hat man einen Defaultwert für die Zieltemperatur eingetragen. Im Betrieb entscheidet man sich für einen anderen Wert und stellt diesen über eine Visu ein. Dieser Wert soll nach einem Reset (Stromausfall?) des Arduinos erhalten bleiben. Ich könnte den über eine eigene Routine im EEPROM speichern, aber es wäre noch besser, diesen per Tools.setUNIT..Param(x) an die richtige Stelle im EEPROM schreiben zu können.
Wenn die Suite das auslesen, geänderte Werte anzeigen und bei Bedarf übernehmen könnte, wäre das ein echter Mehrwert.

[tuxedo]

Was genau bringt die Ansicht in der ETS? Also mir als Nutzer und nicht als Entwickler der Suite und Library? Gibt es Fälle in denen es für einen "Endanwender" hilfreich wäre?

Die als reiner Nutzer bringt das gar nix. Aber wer ein Gerät entwickelt oder die Suite/Lib "verbessert", der ist da sehr schnell dankbar wenn er da was quasi im "klartext" rauslesen kann. Vor allem kann man, wenn was schief geht, dem Nutzer sagen: Mach doch mal einen Screenshot in der ETS... Das reicht dann für die schnelle Analyse schon aus. Da muss man weder Taschenrechner bedienen, noch die Struktur zerpflücken um etwaige Fehler zu sehen.

Im kdevice.xml hat man einen Defaultwert für die Zieltemperatur eingetragen. Im Betrieb entscheidet man sich für einen anderen Wert und stellt diesen über eine Visu ein. Dieser Wert soll nach einem Reset (Stromausfall?) des Arduinos erhalten bleiben. Ich könnte den über eine eigene Routine im EEPROM speichern, aber es wäre noch besser, diesen per Tools.setUNIT..Param(x) an die richtige Stelle im EEPROM schreiben zu können.

Mal kurz nach Parallelitäten bei existierenden Produkten überlegen ...
Beispiel Heizungsaktor von MDT. Da stellst du über die ETS eine Soll-Temperatur für einen Raum ein. z.B. 21,5°C
Im Betrieb entscheidest du dich, dass du es 1°C wärmer haben willst.

Im Heizungsaktor von MDT ist das über einen Offset geregelt. Den kann man z.B. über eine Visu oder einen Taster an der Wand anpassen. Der Aktor merkt sich die 21,5°C die quasi fest im EEPROm durch die Suite veranktert sind, sowie den Benutzerspezifischen Offset.
Bei Stromausfall wird der Offset durch den EEPROM erhalten. Nach dem wiedereinschalten bzw. der Busspannungsrückkehr, wird alles wieder geladen... Die Solltemperatur und der Offset.

Wozu würdest du jetzt in der Suite den Offset auslesen wollen?

Finde aktuell kein Szenario wo ich tatsächlich durch eine Benutzereingabe im laufenden Betrieb einen Wert überschreiben soll.

Was aber Sinn macht: Die Werte die mit der Suite eingestellt wurden auslesbar machen. Damit könnte man sich eine bestehende Installation "rekonstruieren".

-----

Zum geplanten Umbau ist mir noch keine Alternative eingefallen. Im Gegenteil... man könnte beinahe alle bestehenden Programmiernachrichten abschaffen und durch einzige Nachricht zum programmieren des EEPROMs ersetzen.

Das einzige das ich noch nicht gelöst habe:

Was wenn ich nur die Parameter neu schreiben will, oder ein GA für ein bisher unbenutztes KO dazu kommt? Dann würde sich im EEPROM alles verschieben... D.h. man müsste immer den ganzen EEPROM beschreiben, was dessen Lebensdauer unnötigerweise etwas reduziert, und auch in Summe länger dauert.

Ich denke in beta4 wird dieser Umbau sicherlich nicht kommen. Wenn überhaupt dann kommt da eine fixe limitierung auf max. 3GAs und der EEPROM wird für 3GAs pro KO vorstrukturiert. Ansonsten wird es beta5 oder später werden bis die multiplen GAs pro KO implementiert werden.

[tuxedo]

Hab da jetzt nochmal ein paar Nächte drüber geschlafen. Ich denke wirklich wir sollten das wie beschrieben umbauen und direkt in den Speicher schreiben.

Aber das Problem mit dem partiellen Schreiben steht immer noch im Raum. Mag hier jemand mitüberlegen wie man das am besten löst?