Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Warum so kompliziert? Man muss doch nur die neue Firmware in die knxprod packen und dort die LoadProcedure entsprechend anpassen. So machen es die Hersteller doch auch. Ein ETS-Plugin würde ich nicht mehr machen. Wer weiß ob das in der nächsten ETS-Version noch geht. Und von der ETS-Inside ganz zu schweigen.
Ich hab heute einfach mal mit bisschen rumgespielt.
Mein AddIn kann bisher nur die Seriennummer auslesen und wenn das Gerät nicht antwortet stürzt die ETS ab xD (hab den Fehler gefunden)
Generell ist es nur eine Klassenbibliothek in C# mit dem .net Framework 4
Darin sind dann Benutzer Steuerelemente (WPF).
Gruß Mike
P.s.: Und ja man hat zugriff auf das ETS Projekt und auch auf das selektierte Gerät.
könntest Du? Ich könnte nämlich mit meinem derzeitigen Wissen kein ETS-Plugin schreiben. Ich würde gerne in der ETS ein Plugin haben, dass es erlaubt, die Parameter meiner Logikkanäle oder 1-Wire-Kanäle zu exportieren und wieder zu importieren. Damit könnte man dann auch eine Visualisierung der Logik machen etc.
Die Frage ist: Wie schreibt man so ein Addin? Und hat das dann Zugriff auf die in der ETS gepflegten Eigenschaften des Gerätes?
mir käme zum Update per ETS eine Idee.
Man könnte ja ein ETS AddIn machen, der die Daten rüber schickt.
Man müsste sich dann natürlich noch ein Schema einfallen lassen, dass man keine falsche Firmware drauf laden kann.
Und eine Abfrage ob das Gerät das überhaupt unterstütz.
Aber theoretisch hat man ja im APCI von 1011111000 bis 1011111110 Platz für Herstellespezifische Anweisungen.
Zum Ausbau von Geräten: Ich weiß ja nicht, was Du machst, ich habe die Geräte in Berker-Sensormodulen in einer UP-Dose drin sitzen. Ich nutze zum Debuggen den Segger J-Link mini, der kann ja auch über SWD programmieren. Jetzt habe ich die alle mit so einem 15-cm SWD-Flachbandkabel in der UP-Dose versenkt. Zum programmieren brauche ich den J-Link nur an das SWD-Kaben anzuschließen und spare mir so den Ausbau.
Hi Waldemar,
ich habe bisher Geräte für die Hutschiene (Easymeter Stromzähler auslesen und 8-fach Relay mit Extrasensoren für die Gartenbewässerung) und LED-Dimmer gebaut. Da ist der ESP32 gesockelt und ich kann ihn einfach ausbauen und flashen. Mit OTA geht das eigentlich auch sehr gut ohne Ausbau aber bei Änderungen am Stack die KNX Parameter im Flash (stimmt, nicht EEPROM...) betreffen muss alles gelöscht werden. Entladen und Neuprogrammieren würde auch gehen aber das hatte letztes Mal nicht funktioniert. Das muss ich mir nochmal angucken.
Viele Grüße
Julius
PS: Ich habe jetzt die beiden Pull Requests für Seriennummer und Partielles Programmieren erstellt.
- Telegrammgröße: Für knx-ip (und evtl. auch RF) passt die so. Ich denke auch eher, dass es am Stack und nicht am Buffer des seriellen Port hängt. Ich schlage vor mal auf der Geräteseite die empfangenen Bytes mit printHex() auszugeben und zu schauen, ob die Telegramme bis zum Stack kommen. Falls ja liegt es am Stack und nicht am Buffer. Sonst kann man auch ein #define für die Telegrammgröße hinzufügen.
danke fürs Feedback. Um den Punkt kümmere ich mich... ich hätte ja auch auf die Idee kommen können, das im Stack zu überprüfen.
Melde mich, wenn ich was gefunden habe,
Gruß, Waldemar
Nur kurz ein paar Anmerkungen:
- Telegrammgröße: Für knx-ip (und evtl. auch RF) passt die so. Ich denke auch eher, dass es am Stack und nicht am Buffer des seriellen Port hängt. Ich schlage vor mal auf der Geräteseite die empfangenen Bytes mit printHex() auszugeben und zu schauen, ob die Telegramme bis zum Stack kommen. Falls ja liegt es am Stack und nicht am Buffer. Sonst kann man auch ein #define für die Telegrammgröße hinzufügen.
- Partielle Programmierung/Seriennummern etc: immer her mit den Pull-request. Neue Features sind immer gut.
- Firmwareupdate über die Gruppenkommunikation entspricht überhaupt nicht der Spezifikation. Dafür gibt es andere Möglichkeiten. Spontan würde ich da an ein weiteres Objekt (wie Adresstabelle, Assoziationstabelle usw. ) denken. Das würde für die ETS die Firmware darstellen und könnte dann auch darüber geschrieben werden. Man müsste die Firmware dann in der knxprod wahrscheinlich als "baggage" mitgeben. Schaut einfach mal in die knxprods der Hersteller wie die das lösen.
- RP2040: Warum nicht einfach beides? Da die Arduino-Version wahscheinlich on-top des anderen Sdks gebaut wird, kann man auch einfach jetzt die Platform ohne arduino erstellen und später für eine Rp2040arduine-Version zusätzlich erstellen. (Gleiches gilt für die anderen Platformen auch: wer eine Portierung für sein Lieblings-RTOS machen möchte: immer her damit.)
habe auch die Seriennummer bei meinen Modulen aktiviert, scheint wirklich keine Nebeneffekte zu haben. Zumindest funktioniert es bei 3 Modulen ohne weiteres. Für den SAMD funktioniert Julius Coding auf jeden Fall.
Wenn man genug Flash hat (2*Nutzgröße), könnte man ja immer in den Bereich schreiben, der gerade nicht genutzt wird und dann müsste man nur nach dem Reset einen Dispatcher haben, der in den "richtigen" Bereich springt, der andere stünde dann wieder zum Überschreiben zur Verfügung.
Als ich mit dem Ganzen anfing, war ich noch idealistisch und dachte, bei 256k Flash im SAMD bekommt man das locker hin, ich brauch ja nicht mehr als 50k für meine Firmware. 80k knx-Stack und dann 2 x 50k bekommt man schon irgendwie hin. Dummerweise bin ich jetzt schon bei ca. 100k Firmware und 10k Parameterblock, das war es dann.
Aber interessieren würde es mich schon, wie Du das machst. BT low power kann ich mir noch vom Bus vorstellen, aber WLAN nicht mehr...
... wenn es jetzt die Möglichkeit eines Firmwareupdates über den Bus gäbe... (das darf ja auch gerne etwas länger dauern...)
Weil ein paar meiner Geräte ebenfalls schlecht zu erreichen sind habe ich bewusst den NANO 33 IoT mit dem WLAN/Bluetooth Modul gewählt. Das „OTA“ Update klappt ziemlich gut, allerdings habe ich das noch nicht mit dem knx-Stack getestet (antriggern würde ich das ganze über ein KO auf dem Bus).
Mit der Stromaufnahme des ublox NINA-W102 (ist ein ESP32) könnte es im Low Power Mode sogar komplett über den Bus versorgt klappen (aber das ist alles noch nur theoretisch überlegt).
nach allem, was ich über die Seriennummer weiß, liegt das daran (habe aber nur hier im Forum angelesenes Wissen). Deswegen wäre es auch besser, wenn die Default-Seriennummer im Stack einfach 0 wäre statt 0x01020304. Die 0 wird in der ETS als Ausnahme behandelt, für all die alten Geräte, die keine Seriennummer hatten. In meinem Stack hatte ich das so gemacht.
Ich habe inzwischen auch Dein Coding drin, beim ersten Gerät gab es (noch) keine Probleme, noch 20 todo .
Zum Ausbau von Geräten: Ich weiß ja nicht, was Du machst, ich habe die Geräte in Berker-Sensormodulen in einer UP-Dose drin sitzen. Ich nutze zum Debuggen den Segger J-Link mini, der kann ja auch über SWD programmieren. Jetzt habe ich die alle mit so einem 15-cm SWD-Flachbandkabel in der UP-Dose versenkt. Zum programmieren brauche ich den J-Link nur an das SWD-Kaben anzuschließen und spare mir so den Ausbau.
Warum EEPROM? Der Flash von ESP32 ist doch groß genug?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
.
Einen Kommentar schreiben: