Entwicklungsblog Beta5/Final 1.0.0

[tuxedo]

Ich hab angefangen mich mit Java9 und den damit einhergehenden Änderungen zu beschäftigen.
Es ist jetzt zwar viel Arbeit, aber das Java Ökosystem ist gerade im Umbruch. Oracle versucht die Sprache "moderner" zu machen. Für meinen Geschmack ist das nicht wirklich notwendig, aber nun ja. That's Life.

Vom Umbau betroffen ist unter anderem das Themengebiet "XML und das Parsen/Generieren von Code-Klassen daraus". Da fällt ganz gewaltig unser .kdevice.xml und .kconfig.xml rein... Im großen und ganzen läuft das wieder.
Betroffen ist auch noch das Themengebiet "Classloading". Das betrifft KONNEKTING nicht Akut. Aber für die Suite ist eine Plugin-Schnittstelle geplant. Ich erwarte nicht, dass gleich Horden an Entwicklern losziehen und Plugins für die Suite bauen. Nein. Ich will damit die Suite selbst etwas modularisieren und damit dann Features unabhängig vom Suite-Release-Zyklus ermöglichen.

Eugen liegt mir schon seit Wochen in den Ohren "wir müssen agiler releasen... Kleinere Schritte, mehr Releases".
Das Problem hierbei sind die vielen Baustellen. Klingt jetzt erstmal einfach zu lösen. Also "eins nach dem anderen". Aber so eine Baustelle wie "Protokollupdate" zieht sich eben durch alle Ebenen und durch quasi alle Teilprojekte. D.h. ich muss für so einen Umbau leider die "Straße nicht Stück für Stück aufreisen", sondern ich muss mit mehreren Bulldozern gleichzeitig in allen Stadtvierteln graben ...

Stay tuned.

[ChriD]

Wenn ich nicht gerade mit meinem Umbau beschäftigt wäre könnte ich ja helfen, aber es wär vermutlich sowieso eher hindernd.
Bis ich mich eingelesen hätte bist auch schon fertig.
Ich weiß, das hilft dir jetzt nicht weiter



Eigentlich antworte ich hier aber nur um auch mal zu sagen... Danke für deine Arbeit!

[Sonnengruesser]

Dieses "Agile" Dings wird total überbewertet - ich mach mal was und dann lassen wir den Anwender/Kunden die Probleme suchen. Eine sauber und komplett durchgeführte Änderung ist da deutlich besser, auch wenns länger dauert.
(man merkt vielleicht, dass ich beruflich in der Qualitätsabteilung unterwegs bin )
Also nur kein Stress, die meisten hier bauen jahrelang an ihrer E-Installation. Da fallen die paar Wochen/Monate nicht ins Gewicht.

[tuxedo]

Wenn ich nicht gerade mit meinem Umbau beschäftigt wäre könnte ich ja helfen, aber es wär vermutlich sowieso eher hindernd.

Sobald die grundlegenden Strukturen wieder da sind, macht das wieder Sinn.

ich mach mal was und dann lassen wir den Anwender/Kunden die Probleme suchen.

Das hat nix mit Agil zu tun. Das hat eher was von "so setzt man ein Projekt in den Sand".

Wenn wir kleinere Releases machen, dann haben eher eher das Feedback aus der Community und haben ein geringeres Risiko uns abseits des "roten Fadens" zu bewegen. Gerade dann, wenn man nicht 100%ig weiß wo der Weg hinführen soll macht das zunehemend Sinn.
Dass die Qualität zu einem Release stimmen sollte, erklärt sich von selbst. Aber gerade bei kleineren Projektteams, mit großen Projektumfang, bleibt ein testen seitens der Community nicht aus.

Das Classloading-Problem hat sich mittlerweile erledigt. Lag an der Weise wie ich die JAR Datei zusammengebaut habe. Hat nicht gereicht die Dateien in die JAR bzw. ZIP rein zu packen. Damit der Classloader die Files im Archiv findet, mussten noch Verzeichniseinträge dazu. Seltsamerweise konnte jedes Archiv-Tool die das Archiv lesen/entpacken und die getroffene Class-File hatte auch die korrekte Prüfsumme. Ergo: Das Classloading ist hier wohl sehr strikt was das interne ZIP Format anbelangt.

Das XML Thema mit Java>=9 hat sich auch weitgehend erledigt. Die Java-Entities kann ich jetzt aus dem XML heraus generieren und eine XML so einlesen, dass sie in den generierten Java-Klassen mündet. Läuft also fast wieder.

[tuxedo]

36° und es wird noch heißer ... Der Sommer ist in vollem Gange. Die Arbeit am Programmierprotokoll ist ebenfalls schweißtreibend.
Ich habe das Wiki mittlerweile um ein Draw.io Plugin erweitert. Nun können wir im Wiki schicke Diagramme malen die Vorgänge visuell verdeutlichen:

https://wiki.konnekting.de/index.php...ification_0x01

Ganz fertig ist es noch nicht. Schätze ich hab PC-seitig nun 60% implementiert. Je weiter ich in der Implementierung komme, desto eher fallen kleinere Fehler im Design auf. Da ich das nun aber einfach im Wiki darstellen und editieren kann, ist das beim Entwickeln eine echte Hilfe.

[tuxedo]

Die Suite nimmt Form an, Suite-seitig ist das Programmier-Protokoll nun implementiert. Es folgt die Arduino-Seite...

https://youtu.be/WYRVjZiZKqM

Im Video seht ihr schon mal wie der Dialog für die "mehrere GAs pro KO"-Funktion aussieht. Die Auto-Vervollständigungsdaten stammen aus einem exportierten ETS Projekt (.knxproj Datei).

Have some fun and stay tuned.

[tuxedo]

Arduino-Seite hat nun die neuen Protokoll-Funktionen drin und compiliert wieder: https://github.com/KONNEKTING/KonnektingDeviceLibrary/tree/protocol-changes
Funktionen sind aber noch nicht ausimplementiert.
Und ich habe im Zuge des "Aufräumens" die Byte-Order auf Little-Endian im Protokoll definiert/festgelegt. Bisher gab es da eine wilde Mixtur aus Big-Endian und Little-Endian. Hier wird sicher nun erstmal einiges schief gehen. Muss man halt wieder gerade biegen. Aber immerhin ist es dann einheitlich.
Little Endian:
Die ersten 8 bits ganz rechts stellen das erste Byte dar...

0000000011111111 ---> b[0] = 0xFF und b[1] = 0x00

So, genug für heute... morgen geht's wieder ein bisschen weiter.

[Eugenius]

Ein paar Infos von meiner Seite.
Ich habe Telegram-Empfang umgeschrieben.
Stand "heute": Jeder Knx.task() Aufruf liest nur ein Byte von BUS, somit muss task() sehr schnell/oft aufgerufen werden damit die Telegramme vollständig und korrekt ankommen.
Stand "morgen": wir bleiben in task() so lange drin bis alle Bytes aus Buffer gelesen werden. Dabei wurde auch Telegramm-Ende Erkennung verbessert was den sinnvollen Einsatz von Buffer erlaubt.

Noch ein Problem wurde gelöst: Unendliche INIT-Requests wenn keine Antwort von BUS erfolgt.
Stand "heute": man definiert einen KO mit INIT-Flag. Beim Device-Start werden init-Request gesendet bis jemand antwortet. In bestimmten Fällen war dann das Device nicht mehr ansprechbar. Das Problem tritt normalerweise nur ein, wenn man eine falsche GA eingeben hat.
Stand "morgen": Es wird nur eine INIT-Request gesendet. Egal ob man die Antwort bekommen hat oder nicht.

ESP8266 geht wieder Korrektur in Arduino-ESP8266-Core 2.4.2 und Telegramm-Empfang-Anpassung haben es möglich gemacht.

[ChriD]

Fein! Mein Taster liegt bereit für den neuen Kernel

[tuxedo]

Die beta5 Lib wird so langsam. Hab am WE die ersten Methoden für das neue Protokoll eingebaut und getestet. Es hakelt hier und da noch. Aber es wird.

Der schwierige Teil, nämlich die Daten nach dem neuem Format aus dem Flash/EEPROM zu holen kommt erst noch. Und dann ist da noch die Sache mit den mehreren GA pro KO. Aber auch hier wurden schon Vorbereitungen getroffen.

[tuxedo]

Und ich habe im Zuge des "Aufräumens" die Byte-Order auf Little-Endian im Protokoll definiert/festgelegt.

Muss mich hier selbst korrigieren. Im Zuge der Umstellung hat sich doch rausgestellt, dass mehr BigEndian verwendet wird als LittleEndian. Von daher wäre es quatsch gewesen auf LE zu beharren, wenn doch das meiste BE ist. Also Kommando zurück und auf BE umdefiniert :-)

Siehe auch: https://wiki.konnekting.de/index.php..._Specification

Gruß
Alex

[tuxedo]

Die notwendigen Funktionen des Protokolls sind nun implementiert. Die Suite kann aktuell ihre Daten in den Arduino schreiben. Aktuell sind wir bei 21sekunden Programmierdauert für 256 GAs, 256 KOs und 256 Verknüpfungen zwischen GA und KO, sowie (testweise) zwei Parameter.

Ich bin jedoch dabei - ähnlich wie in der ETS - eine partielle Programmierung einzuführen. Hierbei wird der zuletzt Datenstand mit dem neuen verglichen und nur noch Änderungen geschrieben. Das sollte, je nach Änderung, deutlich weniger Daten bedeuten, die geschrieben werden müssen.

Die Delay-Geschichte beim Programmieren habe ich nun auch nochmal optimiert. Das kitzelt pro Telegramm im besten Fall auch nochmal rund 500ms raus.

Da wir in beta5 auch mehrere GAs pro KO versprochen haben, wurde hierfür das Konstrukt der "ArrayList" eingeführt. Damit lassen sich Arrays dynamisch skalieren, je nachdem wie viele GAs pro KO gespeichert werden sollen. Ebenfalls hilft uns das bei der Suche nach dem passenden KO für ein eingehendes Telegramm: Hier kann es in Zukufnt ja mehrere KOs geben die sich angesprochen fühlen. Bis diese ArrayList lief, sind auch 3-4 Abende/Nächte drauf gegangen.

Gestern Nacht habe ich dann angefangen die neuen Routinen zum auslesen der GAs, KO-Konfigurationen sowie der Zuordnung der GAs zu den KOs zu schreiben. Ganz rund läuft das noch nicht. Irgendwo ist noch der Wurm drin der den Arduino zum erliegen bringt.

Kommende Woche gönne ich mir eine Woche Entwicklungspause in den Bergen. Danach geht's dann weiter.

Stay tuned ...

[Ing-Dom]

Ich bin jedoch dabei - ähnlich wie in der ETS - eine partielle Programmierung einzuführen. Hierbei wird der zuletzt Datenstand mit dem neuen verglichen und nur noch Änderungen geschrieben. Das sollte, je nach Änderung, deutlich weniger Daten bedeuten, die geschrieben werden müssen.

Die Delay-Geschichte beim Programmieren habe ich nun auch nochmal optimiert. Das kitzelt pro Telegramm im besten Fall auch nochmal rund 500ms raus.

Top! Da freu' ich mich drauf.

[andi11]

sehr cool

[Ing-Dom]

wird die "neue" Suite eigentlich abwärtskompatibel sein, also mit BETA4 Geräten zusammenarbeiten?
Oder muss ich dann 2 Suiten parallel betreiben (oder die Geräte updaten) ?