Kaenx-Creator - Erstelle KNX Produktdatenbanken mit GUI

[thewhobox]

Oder habe ich da was übersehen?

Element markieren und auf der Tastatur entfernen drücken

Gruß Mike

[mobil750]

Danke, das war's. Ich arbeite auf einem Mac und da gibt es sowas nicht explizit ...

Gruß
Helmut

[willisurf]

Falls Du die Entf Taste meinst, das ist Func + Backspace

[mobil750]

Hallo Mike,

ich bin nun seit längerer Zeit wieder mit dem Creator aktiv und bin da auf ein Problem gestoßen.

Ich will meine Anwendung erweitern und nutze bei den ComObj die Möglichkeit die Objekte zu klonen. Dann verändere ich den Namen und die ID des Klons.
Das sieht in der Liste der ComObj auch gut aus und passt.

Wenn ich nun in den dynamischen Bereich gehe, dann heißen die ComObj an der bereits vorhandenen Stelle wie die neuen Klone (!!!) und in der List der ComObj finde ich 2 mal die Namen der geklonten ComObj. Die alten ComObj sind verschwunden ....

Nachtrag: wenn ich die geänderte Version im ProdViewer ansehe, passen die ComObj IDs zu den definierten, nur eben die alten Namen nicht ...

Ich verwende noch die V1.6.0.
Dazu hab ich auch noch eine Frage. Ich habe über "Info/nach Updates suchen" die V1.6.1 gefunden und bin über den Link auf Github gegangen. Dort finde ich nur die Source Code.zip, nicht aber die kompilierte Version. Wo stellst du die zur Verfügung?

Gruß
Helmut

[thewhobox]

Hallo Helmut,

du hast für das Update schon an der Richtigen Stelle geschaut, nur hab ich vergessen die Binaries hochzuladen^^
Diese sind nun dort unter den Relases hochgeladen.

Das mit dem ComoObjects muss ich mir anschauen.
Ich verwende das klonen eig nie, da ich das noch nie wirklich gebraucht und somit es auch nicht vollumfänglich getestet ist.
Ich werde mir das bald mal anschauen.

Vielen Dank dir fürs Testen und bescheid geben!

Gruß Mike

[mobil750]

Hallo Mike,

ich belege gerade Schalter mit 2 Funktionen (kurzer und langer Tastendruck) und möchte daher einfach die ComObj verdoppeln. Das ist praktisch und reduziert die Arbeit deutlich. Es funktioniert auch, wenn ich es im ProdViewer ansehe. Alles ist wie gewünscht, nur die Namen im dynamischen Bereich sind falsch.

Ich habe noch eine andere Frage. Hier ein Auszug aus meinem Header File

#define ParamAPP_Switch_1_long knx.paramBit(431, 7)
#define APP_Switch_1L_Type 0x01B2
// Offset: 434, Size: 8 Bit (1 Byte), Text: Funktion
#define ParamAPP_Switch_1L_Type ((uint)((knx.paramByte(434))))
//!< Number: 10, Text: Schalten, Function: T1: Schalten
#define APP_KoSwitch_1 10
#define KoAPP_Switch_1 knx.getGroupObject(10)
//!< Number: 11, Text: Dimmen, Function: T1: Dim-Wert in %
#define APP_KoDim_1 11
#define KoAPP_Dim_1 knx.getGroupObject(11)
//!< Number: 12, Text: Status, Function: T1: Wert für Umschalten

Woher kommt die "APP" Abkürzung, die ich eigentlich lästig finde? Liegt das an einer meiner Angaben? Ich habe alles durchsucht, aber nichts gefunden ..
Die "Ko" Abkürzung ist von dir so programmiert, richtig?

Gruß Helmut

[thewhobox]

Hallo Helmut,

ich habe die Ursache für den Fehler bei den ComRefs nicht gefunden, konnte aber zumindest die Symptome behandeln.
Das Verhalten taucht nun nicht mehr auf.
Die neue 1.6.3 ist bereits veröffentlichen.
Die wird sogar nun wirklich eine SingleFile.

Der Prefix APP_ kommt daher, dass ich eher mit Modulen arbeite.
Dort hat jedes Modul einen anderen Prefix, damit man in mehreren Modulen den gleichen Namen eines Parameters haben kann.
Ich würde dir auch empfehlen auf Module zu gehen.
Das bietet viele Vorteile:
- Einfaches erhöhen der Kanäle
- Eine Änderung nur einmal nötig und nicht in jedem Kanal
- Einfache einbindung in Channels von OpenKnx

Auch kommt es um eine gewisse kompatibilität zum OpenKnxProducer zu haben. Deswegen auch das "Ko" davor.
So wäre es egal, aus welchem Tool die Header stammt.


Gruß Mike

[mobil750]

Hallo Mike,

ja Module würden mir wirklich helfen, so richtig klar ist mir die Anwendung allerdings noch nicht.
Um mein Projekt funktional weiterzubringen/abzuschließen arbeite ich deshalb noch nach der aufwendigeren Methode. Eine Umstellung ist dann aber auf alle Fälle geplant.

Eine Frage, kannst du ETS Fehlermeldungen beim Instanziieren eines Devices interpretieren? Ich habe meine knxprod erfolgreich aus dem Creator veröffentlicht, kann sie auch in die ETS importieren, beim Instanziieren kommt es dann zu einem Umwndlungsfehler. Ich habe dazu keine Idee was da falsch sein kann.
Kannst du da helfen? Ich habe den Fehlerreport und die anderen Dateien mal angehängt.

Danke und Gruß
Helmut

[thewhobox]

Hallo Helmut,

ja Module sind Anfangs nicht ganz leicht, erleichtern aber das Arbeiten damit ernorm.

Ich hab mir mal kurz deine KnxProd angeschaut.
Du hast im Schalter 2 bei einer Bedingung ein Leerzeichen zu viel...
image.png
Danach konnte ich es bei mir Problemlos importieren und ins Projekt einfügen.

Gruß Mike

[mobil750]

Danke Mike!

Konntest du das aus der Fehlerbeschreibung herauslesen?

Gruß
Helmut

[thewhobox]

Jain.

Das erste worauf man achten muss ist *wann* kommt die Fehlermeldung?
- Beim Import direkt? -> Dann ist etwas im Static falsch
- Erst beim Einfügen in das Projekt? -> Dann ist etwas im Dynamic falsch (oder evtl auch DPT eines KO/KOrefs)

Zusätzlich musste es eine Stelle sein, an der ein String in eine Zahl umgewandelt werden soll.
Das ist im Dynamic eig nur bei einem choose bzw dessen bedingung im when so.
Ich schau mal, ob man da iwie sinnvoll einen Check einbauen kann.

Gruß Mike

[abtools]

Hallo Mike,

arbeite mich gerade auch etwas in dein tolles Programm ein - erst einmal vielen Dank für deine Mühe dieses UI-Tool zu erstellen!

Da man ja am besten aus Beispielprojekten lernt, schaue ich mir gerade das spannende Projekt von Helmut, konkret die "UP Tastermodul mit Display und Sensoren V2 .ae-manu"-Projektdatei aus dem Beitrag
https://knx-user-forum.de/forum/proj...50#post1851350
etwas genauer an.

Dabei ist mir gleich ein - vermutlich unerwünschter - Effekt aufgefallen, den ich schon mal berichten wollte.

Folgende Vorgehensweise zur Reproduktion:

1. Verwendung von Kaenx-Creator v1.6.2
2. Öffnen der "UP Tastermodul mit Display und Sensoren V2 .ae-manu"-Projektdatei
3. Öffnen der einzigen Anwendungsversion "V 0.2 App: Taster monochromes Display Sensoren" im Projekt.
4. Überprüfung durchführen => Schließt mit einer (der oben erwähnten Float-)Warnung, aber ohne Fehler ab.
5. Nun auf "Dynamisch" und dann im Baum auf den Knoten "Auswahl Sensoren" (unter "Channel Funktionsblöcke" => "Auswahl show_Display_Modul" => "Bedingung" => Block Display" => "Auswahl Sensoren") klicken. Also wirklich nur auf dieses Baum-Element klicken, keinerlei Änderungen danach in dem Bereich rechts vornehme.
6. Stattdessen sofort wieder auf "Überprüfen" klicken und die Überprüfung erneut durchführen lassen.

Obwohl keinerlei Änderungen vorgenommen wurden, erhalte ich jetzt eine Fehlermeldung in rot:
grafik.png

Offenbar scheine ich also durch das reine "Ansehen" dieses Elements im "Dynamisch"-Bereich bereits eine Änderung verursacht zu haben, die in einem Fehler bei der Überprüfung resultiert:
Da ich davon ausgehe, dass dies nicht beabsichtigt ist, wollte ich es zumindest mal hier "berichten" - vielleicht lässt sich das ja mit einem künftigen Update korrigieren.

In der Zwischenzeit arbeite ich mich weiter ein und würde mich, wenn ich darf, ggf. bei Fragen nochmal hier melden. :-)

Viele Grüße
Andreas

[thewhobox]

Hallo Andreas,

vielen Dank für das Feedback.
Das Problem ist mir leider allerdings schon bekannt, ich konnte nur noch nicht ausfindig machen, warum es das tut und wie ich es verhindern kann.
Es tritt auch nicht immer auf, dafür aber eig nur bei den chooses.
Wenn man den chosses keine Namen vergibt ist das Suchen auch extrem schwer.

Du darfst dich gerne jederzeit bei Fragen und Problemen melden.

Darf man denn Fragen, was du damit vor hast?


Gruß Mike

[abtools]

Hallo Mike,

zunächst vielen dank für deine schnelle Antwort!

Da ich es bei mir 100 % reproduzieren kann, hab' ich's gerade mal mit Visual Studio debugged und das Problem ist diese Zeile hier:
https://github.com/OpenKNX/Kaenx-Cre...seBlock.cs#L34
Während des UI-Ladevorgangs wird auch der Setter dieser Property aufgerufen und dort setzt du "_parameterRefObject = null;" - damit ist der ParameterRef weg, jedes mal, wenn man die Node im Baum nur aufruft.

Mir ist nicht ganz klar, warum der ParameterRef an dieser Stelle dereferenziert werden muss, lasse ich dies jedoch weg, funktioniert es bei mir einwandfrei. Einen entsprechend Pull-Request habe ich erstellt:
https://github.com/OpenKNX/Kaenx-Creator/pull/26
Nun bin ich mir aber wie gesagt nicht sicher, ob es einen bestimmten Grund gibt, weswegen es wichtig ist den ParameterRef an dieser Stelle zurück auf "null" zu setzen. Bitte prüfe daher vor dem Mergen, ob mein "Fix" ggf. andere unerwünschte Nebeneffekte hat, die mir bei einem kurzen Test gerade noch nicht aufgefallen sind.

Hallo Andreas,
Du darfst dich gerne jederzeit bei Fragen und Problemen melden.

Vielen Dank, arbeite mich wie gesagt gerade ein, da kommt bestimmt noch die ein oder andere (doofe) Frage. ;-)

Hallo Andreas,
Darf man denn Fragen, was du damit vor hast?

Gerne, zum einen arbeite ich als externer Entwickler öfters mal bei Smart-House-Projekten mit, zum anderen ist nächstes Jahr ein eigener Neubau geplant, in dem ich beabsichtige eine ganze Reihe selbstentwickelter KNX-Geräte einzusetzen - bzw. auch Geräte, die selbst keine KNX-Schnittstelle haben, auf den Bus zu bringen.

Dazu gehören DormaKaba-Türantriebe, eine Siemens-Brandwarnanlage sowie ein selbstentwickeltes Mini-Touch-Display (basierend auf dem Seeed Studio Round Display), was ich vollständig in das Gira-"System 55"-Schalterprogramm integriert habe. Bzgl. Präsenzmelder teste ich das Produkt von Waldemar.

Prototypen der Anwendungsebene habe ich für die meisten Geräte fertig, bzgl. KNX habe ich für erste Tests bisher jedoch einfach direkt KNX-Telegramme geschickt, ohne die Geräte in der ETS zu registrieren. Nachdem nun jedoch dank Dominik die ersten NCN5130-NanoBCUs zur Verfügung stehen :-) , möchte ich die KNX-Integration nun "vernünftig" abschließen und die Geräte in das "OpenKNX-Universum" bringen.

Ich finde es einfach super, was ihr mit den OpenKNX-Modulen als Basis verfügbar gemacht habt, was einem den Einstieg ungemein erleichtert.
Besonders spannend finde ich auch den "OFM-Updater", mit dem ein Firmware-Update sogar über den Bus möglich ist, was bei größeren Bauprojekten (mit teils etwas "verbauten" Geräten) doch extrem nützlich ist!

An dieser Stelle gleich mal die Nachfrage:
Was muss man tun, um einen OpenKNX-Anwendungs-ID-Bereich zugewiesen zu bekommen?

Viele Grüße und nochmals danke für deine schnelle Rückmeldung und Support
Andreas

[thewhobox]

Vielen Dank fürs gleich debuggen!
Das hat tatsächlich einen Grund, damit beim andern von Lokal zu Global nicht ausversehen noch der alte ParameterRef gespeichert ist.

Werde mir was überlegen, wie ich das fixen kann.
Danke dir!

Das Display klingt sehr interessant.
Hab auch schon damit in Gedanken gespielt, aber aufgrund, dass ich einen 3d Drucker oder skills habe schnell wieder verworfen^^

Für den beitritt zu openknx muss man eig nicht viel machen.
Es sollten aber folgende Punkte erfüllt werden:
- Geräte sollten öffentlich auf Github unter der Organisation openknx veröffentlicht werden
- Interesse auch am Common mit zu entwickeln

Generell gibt es zwei Arten um openknx Geräte zu entwickeln:
- meine Version mit dem Tool hier
- oder auch Waldemars umfassender OpenKNXProducer (für die Einbindung von Logikmodul oder anderen in seine eigenen Geräte)