KONNEKTING: Public Beta - Infos, Links und Downloads

[Eugenius]

Wird sind ja genau dafür da
Jetzt steht nix der Lernfunktion im Weg

[tuxedo]

Den Beispiel-Sketch in der Doku hab ich auch entsprechend angepasst, so dass man ihn jetzt als Grundlagenskelett verwenden könnte.

[tuxedo]

Kleines Update bzgl. der Beta-Phase:

Beta 3 ist gerade in der Entwicklung. Vieles wurde schon umgesetzt, ein paar Dinge fehlen noch. Die aktuelle Liste findet sich hier:

https://github.com/KONNEKTING/Konnek...es/1.0.0-BETA3

Einer der Hauptpunkte in der Beta wird sein:

* Man muss im Sketch nun keine GA für die einzelnen KOs angeben. Das ganze sieht dann wie folgt aus:

Also statt bisher:

// Definition of the Communication Objects attached to the device
KnxComObject KnxDevice::_comObjectsList[] = {
    /* don't change this */ Tools.createProgComObject(),

    // Currently, Sketch Index and Suite Index differ for ComObjects :-(

    /* Sketch-Index 1, Suite-Index 0 : */ KnxComObject(G_ADDR(0, 0, 1), KNX_DPT_9_001, COM_OBJ_SENSOR), // Temperatur Messwert
    /* Sketch-Index 2, Suite-Index 1 : */ KnxComObject(G_ADDR(0, 0, 2), KNX_DPT_1_001, COM_OBJ_SENSOR), // Temperatur unterer Meldewert
    /* Sketch-Index 3, Suite-Index 2 : */ KnxComObject(G_ADDR(0, 0, 3), KNX_DPT_1_001, COM_OBJ_SENSOR), // Temperatur oberer Meldewert

};

dann nur noch:

// Definition of the Communication Objects attached to the device
KnxComObject KnxDevice::_comObjectsList[] = {
    /* don't change this */ Tools.createProgComObject(),

    // Currently, Sketch Index and Suite Index differ for ComObjects :-(

    /* Sketch-Index 1, Suite-Index 0 : */ KnxComObject(KNX_DPT_9_001, COM_OBJ_SENSOR), // Temperatur Messwert
    /* Sketch-Index 2, Suite-Index 1 : */ KnxComObject(KNX_DPT_1_001, COM_OBJ_SENSOR), // Temperatur unterer Meldewert
    /* Sketch-Index 3, Suite-Index 2 : */ KnxComObject(KNX_DPT_1_001, COM_OBJ_SENSOR), // Temperatur oberer Meldewert

};

Hintergrund ist folgender: In der bisherigen Variante _musste_ eine GA angegeben werden. Das war bei Franck's Lib eben so. Dadurch waren aber per-se immer alle KOs aktiv und haben Telegramme empfangen und Änderungen auf den Bus gesendet.
Jedoch nutzt man unter Umständen in der Suite nur ein Subset an Funktionen, womit dann das eine oder andere KO gar keine GA programmiert bekommt. Im Hintergrund wäre aber noch die im Sketch vordefinierte Adresse aktiv.

Zum einen verwirrt es den Sketch-Entwickler warum er da eine Dummy-Adresse angeben muss, und zum anderen führt es zu unvorersehbarem Verhalten wenn die Dummy-Adresse anderweitig im KNX System im Einsatz sein sollte.

Ergo: Weg damit.
Sobald in der Suite eine gültige GA für ein KO angegeben wurde, wird auch das KO im Sketch aktiv. Löscht man die GA wieder in der Suite, wird das KO im Sketch inaktiv.

* Man kann feingranularer sagen was programmiert werden soll:

Bisher gab es zwei Programmierknöpfe:
rot: Alles programmieren, inkl. physikalische Adresse
orange: Nur KOs und Parameter programmieren (damit spart man sich das Prog-Knopf drücken, sofern eine PA schon im Gerät ist)

Neu hinzugekommen:
gelb: Nur KOs programmieren
grün: Nur Parameter programmieren

Gerade bei größeren Geräten/Sketches macht das Sinn. Vor allem um Zeit zu sparen. Aktuell arbeite ich am Sketch für Stefans 2.0 HW die Temperatur, rel. Luftfeuchte und VOC misst. Da sind bereits über 30 Parameter und ca. 10 KOs zusammen gekommen. Da immer alles zu programmieren kostet unnötig Zeit. Gerade wenn man in der Entwicklung ist und schnell mal eine kleine Änderung macht.

Nächster Schritt für eine zukünftige Version wäre: Nur das Programmieren das sich ggü. dem letzten Programmieren geändert hat (macht die ETS auch so).



Daneben gibt es noch ein paar kleinere Änderungen, meist unter der Haube.

Bedingt durch einen Hardwareausfall (das 3 Monate alte Mainboard meines Entwicklungsrechners hat den Geist aufgegeben) pausiert die Entwicklung ein wenig. Ende März wird es aber voraussichtlich soweit sein mit dem Release der Beta3.

Wenn dann nix mehr gravierendes auffällt gibt's das 1.0.0 Stable Release.

Gruß
Alex

[Haka]

Hallo zusammen,

vermutlich steh' ich grade nur wie der Ochs vor dem Berg - ich bekomme die Lib aber einfach nicht ans laufen, sondern bekomme stets folgende Fehlermeldung:

In file included from /Volumes/SuperNussDrive/hanskeller/Documents/Arduino/libraries/KonnektingDeviceLibrary-1.0.0-BETA2/KnxDevice.h:36:0,
                 from DemoSensor_Temp_RH.ino:11:
/Volumes/SuperNussDrive/hanskeller/Documents/Arduino/libraries/KonnektingDeviceLibrary-1.0.0-BETA2/KnxTools.h:32:20: fatal error: EEPROM.h: No such file or directory
 #include <EEPROM.h>
                    ^
compilation terminated.
Fehler beim Kompilieren.

Die Libraries liegen in meinem Arduion-Library-Verzeichnis, und EEPROM.h gibt's natürlich auch.

Für jeden Hinweis dankbar

Viele Grüße
Hans

[tuxedo]

Deutet auf ein Problem in deiner Arduino IDE hin. Er findet die eeprom lib nicht, welche in der IDE als Standard hinterlegt ist. Welche Version hast du im Einsatz? Probier ggf mal ein Update oder eine Neuinstallation. Gruß Alex

Siehe auch: https://knx-user-forum.de/forum/proj...996#post925996

[Haka]

Servus Alex,
das war mit der IDE 1.7.8 von arduino.org. Nach obigem Hinweis habe ich auf die 1.6.8 von arduino.cc gewechselt und es funktioniert.
Etwas verwirrend, aber jetzt tut es.

Was anderes, kann man schon auf die BETA3 wechseln? Mein Projekt braucht ziemlich viele GAs, und irgendwie wäre es nett, wenn es diese erst nach Inbetriebnahme durch die GUI richtig allokierte; bei mir sind zwischen 0/0/0 und 15/0/100 schon ziemlich viele GAs belegt.

Viele Grüsse

Hans

[tuxedo]

Die Beta3 ist noch in der Entwicklung. Wird wohl noch 1-2 Wochen dauern.

[tuxedo]

So, die Beta3 schreitet voran... weitere Änderungen:

* Ändert sich ein Parameter, wurde bisher alles neu gespeichert, alle Geräte, alle Files. Jetzt wird nur noch gespeichert wenn bedarf dazu da ist (d.h. es eine Änderung gab), und zwar nur die File deren Inhalt sich geändert hat
* Es gibt neue Parametertypen: raw1...raw11. Damit kann man RohDaten in der Suite angeben. Von Länge 1 byte (raw1) bis 11 byte (raw11). In der Suite gibt man die Daten dann als Hex-String an. Gefordert war dieses Feature für 1-Wire wenn man eine 1-Wire-ID als Parameter eingeben will. Ein echten String-Typ gibt's also noch nicht, weil bisher noch nicht benötigt.

Noch offen:

* Update des Splash-Screens auf das neue Logo
* Eintrag der Device-Lib in das Arduino IDE Verzeichnis (dann kann man die Lib direkt aus der IDE heraus updaten)
* Ergebnis der internen SW-Tests

Dann gibt's das Release der Beta3.

[tuxedo]

Splash-Screen ist nun komplet neu und somit abgehakt.

[tuxedo]

Beta3 wird es diese Woche geben. Änderungen wie gehabt.
Statt nach Beta3 gleich zum Final Release 1.0.0 zu schreiten, wird es doch noch eine Beta4 geben, die die Suite "internationalisiert", bzw. dafür vorbereitet.

[tuxedo]

KONNEKTING Device Library: https://github.com/KONNEKTING/Konnek...ag/1.0.0-BETA3
KONNEKTING Suite: https://github.com/KONNEKTING/Konnek...ag/1.0.0-BETA3

Änderungen seit Beta2:

Suite:
* Mehr Programmieren-Knöpfe
* Mehrsprachig (I18N). Bisher nur deutsch und englisch
* Raw-Datentypen, 1 bis 11 byte Länge. Praktisch für 1-Wire wenn man die Adresse/Seriennummer des Buttons/Sensors als Parameter hinterlegen will
* neuer Splash-Screen, neu hinzugekommene "About"-Box, neue Logos/Anwendungsicons

Lib:
* Raw-Datentypen
* KOs müssen im SKetch nicht mehr mit einer GA versehen werden. Das wird ab sofort nur noch über die Suite programmiert.
* KOs können nun aktiv/nicht-aktiv sein (muss man nix für tun, geht automatisch basierend auf den Einstellungen in der Suite)
* Neuer Beispielsketch
* Eintragung in den Arduino Library Manager (läuft noch): Damit kann man die Lib direkt aus der Arduino IDE heraus auswählen und muss sie nicht mehr von Hand runterladen und installieren

Viel Spaß damit...

P.S. Nicht direkt auf Github gehen und "Download ZIP" anklicken (--> https://github.com/KONNEKTING/KonnektingDeviceLibrary). Bitte nur obige Beta-Release Links benutzen. Ansonsten erwischt man Code der a) noch in der Entwicklung steckt, b) nicht getestet ist und c) unter Umständen gar nicht funktioniert.

[tuxedo]

Unsere Anfrage in den Arduino Lib-Manager rein zu kommen wurde angenommen: https://github.com/arduino/Arduino/i...vent-624183933

Ab Arduino 1.6.9 ist es wohl soweit ...

[tuxedo]

Die beta3 der Suite hat noch ne kleine Macke... Der Programmieren-Dialog geht nicht auf. Ich arbeite dran.

[update]
Gefixt. Upload zu Github läuft gerade. Einfach nochmal runterladen. Hab davon abgesehen eine beta4 dafür zu erstellen. Bis dato gab es ja noch fast keinen download von (der defekten) beta3 so wie ich das sehe.

Gruß
Alex

[tuxedo]

Bis zur Beta4 wird es eine ganze weile dauern.

Da immer mehr die Lib anfangen zu benutzen, stoßen auch immer mehr auf kleinere Fehler. Hier macht es sich langsam bemerkbar dass die Lib noch nicht ganz ausgereift ist. Nicht weil sie nicht funktioniert, sondern weil eine Fehler-Ursachenanalyse kompliziert wird. Bis dato sind in der Lib selbst keine Fehler aufgetreten. Aber "drum herum" gibts immer wieder kleinere Probleme.

Deshalb wird in Beta4 nun Wert auf ein besseres Debugging gelegt. Hierzu ist es aber notwendig intern in der Lib einiges umzubauen, was leider auch Auswirkungen auf die Sketch-Kompatibilität hat: Wer einen Sketch für Beta3 der Lib geschrieben hat, kann die Lib nicht ohne Anpassung des Sketches auf Beta4 updaten. An der Programmierung hat sich nichts geändert. D.h. eine Beta4 Suite kann einen Beta3 Sketch programmieren.

Ich habe damit bereits begonnen und einen Beispielsketch an diese Änderungen angepasst:

https://github.com/KONNEKTING/Konnek...rogramming.ino

So ganz grob die äußerlichen Änderungen:
* Nach der definition der KOs und der Parametergrößen musste man noch eine "const ..." Zeile im Sketch haben. Die fällt weg
* Das erste KO musste das KO zum programmieren sein (createProgComObj())... Das fällt weg und wird intern automatisch angelegt
* Durch diesen Wegfall ist die irritierende Nummerierung der IDs bei den KOs nun besser gelöst: KO #0 in der Suite entspricht nun KO #0 im Sketch
* KOs und Parametergrößen werden jetzt beim init() Aufruf mit übergeben. Damit ist das ganze expliziter als vorher. Der ganze statische, implizite Aufbau ist weggefallen.
* Es heißt nicht mehr "KnxDevice", sondern "KonnektingDevice" (in anlehnung an den Namen der lib)
* KnxTools gibt es so nicht mehr. Dafür gibt es eine "KonnektingProg" Klasse, welche für die Programmierung zuständig ist
* Das Abfragen der Parameter richtet man nicht mehr an KnxTools, sondern man frägt das KonnektingDevice nach seiner Programmierung und diese dann nach dem Parameter.
* Debug-Angaben (SoftSerial/HardwareSerial, Baudrate, welche Pins...) macht man nicht mehr in jeder Datei einzeln, sondern legt das einmal zentral im eigenen Sketch fest. Das daraus resultierende "Serial Objekt" wird dann einfach in die Lib reingesteckt und diese nutzt das so wie es ist.

Aber das ist alles noch in der Entwicklung. Bisher compiliert zwar alles, aber ob das auch funktioniert muss ich erst noch zusammen mit der Hardware testen. Der bisherige Umbau umfasst einige hundert Zeilen. Ist also nicht ganz ohne. Gefühlt hab ich bereits 60% des gesamten Codes umstrukturiert und umgestellt. Da sind sicher noch viele Fehler drinnen.

Stay tuned ...

[tuxedo]

Kleines Update:

Der Code compiliert zwar, er er crashed. Da ein Großteil unserer Lib "statisch" ist (d.h. automatisch eine Instanz davon angelegt wird), ist es schwer bis unmöglich den Fehler über Log-Ausgaben zu finden.
Ich hab mir deshalb einen Hardwaredebugger (knapp 70EUR) angeschafft um der Sache auf den Grund zu gehen. Mittlerweile ist dieser auch eingetroffen, aber ich muss mich da erst einarbeiten. Richtig weit bin ich noch nicht gekommen. Erschwered kommt hinzu, dass ich aktuell für's debuggen den Code in Atmel Studio importieren muss, und da dann irgendwie ohne Bootloader gearbeitet wird, was wieder andere Seiteneffekte hervorrufen "könnte".
Aktuell suche ich noch nach einem Weg den Debugger mit dem zu benutzen was ich mit der Arduino IDE programmiere. Läuft sicher auf Kommandozeilen-Debugger-Lösung hinaus, aber solange es funktioniert... Problematisch ist da nur, dass der Hardwaredebugger von den gängigen Tools (außer Atmel Studio) wohl noch nicht ganz unterstützt wird.

Wenn jemand sich hier in dem Umfeld auskennt: Hilfe ist erbeten.