ESP8266 KNX mit ETS

[OutOfSync]

OutOfSync hat netterweise schon eine Portierung meiner Lösung auf den aktuellen Stack gemacht. Hier sind die Änderung primär in table_object.cpp. Vielleicht kann seine Lösung in den Stack einfließen, damit die Sachen nicht noch weiter auseinanderlaufen. Ich bin nicht stolz darauf, auf einem Fork zu arbeiten, aber weiß einfach nicht, wie ich die von mir genutzte Flash-Implementierung in den Originalstack bringen soll. Zumindest versuche ich auf diesem Weg, meine Erfahrungen zu teilen und Anregungen zu geben.

Hallo zusammen,

ich bereite gerade zwei Pull Requests für die Seriennummer und den Support für partielles Programmieren auf dem aktuellen Stack vor. Erstmal musste ich mich mit git beschäftigen damit das auch übersichtlich verläuft denn bisher habe ich noch keinen PR gemacht. Ich hoffe ich komme heute Abend dazu die branches zu erstellen und den request zu starten.

Viele Grüße, Julius

[mumpf]

Hi Julius,

danke für die Info. Ich habe inzwischen auch im Originalstack (https://github.com/thelsing/knx/blob...bject.cpp#L60) gesehen, dass das mit PID_MAX_APDU_LENGTH auch ganz anders als bei mir aussieht, aber die Länge immer noch auch 254 steht. Hast Du eventuell eine Idee, wie bzw. ob man das für den SAMD plattformabhängig auf 56 implementieren könnte?

Oder alternativ die Frage an alle: Spräche was dagegen, den Wert plattformunabhängig auf 56 zu setzen? Ich weiß nicht, ob der Wert bei KNX-IP eine Rolle spielt. Bei KNX-TP und dem Arduino-Framework würde ich behaupten, dass die 254 dazu führt, dass effektiv mit APDU=15 programmiert wird. Da wäre eine APDU=56 deutlich besser und auch klar merkbar.

Gibt es hier jemanden, der mit dem Originalstack KNX-TP und nicht SAMD nutzt?

Gruß, Waldemar

[keil]

Hallo zusammen,

zu allererst: ein großes Lob dafür, was ihr ausgehend von Thomas exzellenter Vorarbeit hier noch an neuen Funktionalitäten in den Stack gebracht habt.

Ich habe schon 2 Anläufe hinter mir, mich mit dem Thema zu beschäftigen, aber über einen Test mit der knx-demo (und so machen Problemen) bin ich aus Zeitmangel nie hinausgekommen.

Jetzt beim 3. Anlauf soll alles besser werden und ich habe bereits nochmal den kompletten Thread gelesen, sämtliche Sachen installiert und die knx-demo sendet auch schon fröhlich auf einem Arduino NANO 33 IoT über eine MicroBCU2 von SirSydom vor sich hin (Programmierung sowohl über die Arduino "IDE" sowie Visual Studio Code und PlatformIO).

Ich fände es schön wenn das bei dir Julius mit dem Pull Request klappt (falls Du Unterstützung benötigst sag Bescheid), denn gerade die Sache mit der Seriennummer finde ich super (das partielle Programmieren von Dir Waldemar wird bei mir wahrscheinlich nicht so einen großen Effekt haben, da ich für die von mir geplanten Geräte eher relativ wenige Parameter und KOs benötigen werde).

Wenn ich mit dem SAMD halbwegs sattelfest bin, würde ich mich auch an eine Unterstützung des Raspberry Pi Pico RP2040 machen (bisher habe ich auf dem Teil nur ein paar Sachen in MicroPython getestet, aber gerade die Sache mit dem zweiten Kern ist schon klasse... auf einem könnte der KNX Stack laufen, auf dem anderen die eigentliche Applikation).


Viele Grüße,
Michael

[mumpf]

Hi,

apropos Seriennummer: Weiß jemand, was die ETS mach, wenn ein bereits im Projekt eingefügtes und parametriertes Gerät plötzlich eine neue Seriennummer meldet? Denn genau das würde ja passieren, wenn ich die Änderung von Julius übernehme...

Wahrscheinlich werde ich derjenige sein, der das testet und dann hier informiert, aber ich dachte, ich könnte zuerst mal fragen. Vielleicht gibt es ja schon Informationen, was dann passieren könnte - und ich spare mir kaputte Projekte oder ähnliches Chaos .

Gruß, Waldemar

[OutOfSync]

apropos Seriennummer: Weiß jemand, was die ETS mach, wenn ein bereits im Projekt eingefügtes und parametriertes Gerät plötzlich eine neue Seriennummer meldet? Denn genau das würde ja passieren, wenn ich die Änderung von Julius übernehme...

Wahrscheinlich werde ich derjenige sein, der das testet und dann hier informiert, aber ich dachte, ich könnte zuerst mal fragen. Vielleicht gibt es ja schon Informationen, was dann passieren könnte - und ich spare mir kaputte Projekte oder ähnliches Chaos .

Hi,

also ich habe keine Probleme gesehen als ich damit rumgespielt habe. Dazu war ein Testgerät angelegt und ich habe munter neuprogrammiert. Die Seriennummer kann dann ausgelesen werden.

Ich muss aber sagen dass ich in der ETS eh ein paar komische Effekte habe wenn mehrere Geräte (ESP32) desselben oder unterschiedlichen Typs (Ordernumber) mit gleicher Seriennummer vorhanden sind. Bei Neuprogrammierung eines Geräts werden die grünen Häkchen an den anderen wieder deaktiviert. Das habe ich mal auf die identische Seriennummer in allen Geräten zurückgeführt, aber noch nicht getestet wie es aussieht wenn überall der Seriennummer Code eingebaut ist. Erstmal muss ich alle Geräte auf die develop Version updaten, dazu muss leider EEPROM gelöscht werden und d.h. alle Geräte physisch ausbauen und neu flashen

Bin gespannt ob das wirklich an der Seriennummer liegt...

Viele Grüße, Julius

[mumpf]

Hi Julius,

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?

Gruß, Waldemar

[keil]

... 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).

[mumpf]

Wie machst Du Dein OTA?

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...

Gruß, Waldemar

[mumpf]

Hi,

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.

Gruß, Waldemar

[Ing-Dom]

würde ich mich auch an eine Unterstützung des Raspberry Pi Pico RP2040

dafür Daumen hoch !

mit Arduino oder ohne? Arudino Support kommt ja, nur fertig ist er noch nicht.
Ich würde *mit* bevorzugen.

[thesing]

Hallo allerseits,

schön wie sich das alles entwickelt:

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.)

Viele Grüße,
Thomas

[mumpf]

Hi Thomas,

- 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

[OutOfSync]

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.

[thewhobox]

Hallo,

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.


Gruß Mike

[mumpf]

Hi Mike,

Man könnte ja ein ETS AddIn machen,

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?

Gruß, Waldemar