ESP8266 KNX mit ETS

[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,

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

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

[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 Thomas et al,

ich wollte euch mal Feedback über 2 Anpassungen im Stack berichten, die meiner Meinung nach große Auswirkungen haben und den Stack weiterbringen würden. Das eine adressiert den eigentlich schon lange vorhandenen "Longframe-Support", und zwar in device_object.cpp:

        case PID_MAX_APDU_LENGTH:
            pushWord(56, data);
            break;

Da steht im Original 254 bzw, 0xFE und ist zwar die maximale Telegrammlänge, die der Stack kann, aber zumindest auf der SAMD-Plattform habe ich es nicht hin bekommen, die serielle Schnittstelle zu mehr als 64 Bytes zu überreden. Und dann sind da wohl noch 10 Byte "Verwaltungsdaten", so dass 56 für die APDU übrig bleiben.. Was also unter dem SAMD beim programmieren passiert, ist folgendes (eine Schnittstelle vorausgesetzt, die APDU-Längen > 15 unterstützt):

• ETS fragt PID_MAX_APDU_LENGTH ab, bekommt 254
• Sie bildet das Maximum aus APDU der Schnittstelle und APDU des Stacks, das ist bei meiner Schnittstelle 66.
• Dann wird mit der Länge versucht zu programmieren, das geht schief.
• Die ETS versucht es noch ein 2. mal, geht natürlich auch schief.
• Dann macht sie mit APDU 15 weiter

Faktisch gewinnt man nichts mit dem Setting, es dauert sogar länger, da die beiden Versuche der ETS das Programmieren um ca. 10 Sekunden verzögern. Der Stack hat also einen Long-Frame-Support, der aber nicht genutzt werden kann. Meiner Meinung nach sollte das auch bei der knx secure implementierung probleme verursacht haben, habe aber keine Erfahrung damit.

Das blöde ist, dass PID_MAX_APDU_LENGTH eigentlich plattformabhängig ist und im Stack eigentlich so implementiert werden sollte. Dazu sehe ich mich nicht in der Lage, vor allem weil ich den Stack ja so nicht verwende und es somit nicht testen kann. Aber vielleicht kann ja jemand den Default-Wert von 254 auf 56 setzen, ich vermute, das würde auf den meisten Plattformen laufen und bringt schon mal einen Faktor 2 bei allen Programmierungen. Letzteres kann ich natürlich auch als Pull-Request machen, das würde ich noch schaffen .

Das 2. ist der Support fürs partielle Programmieren. Das ist - meiner Meinung nach - der Hammer schlechthin!!! Die Diskussion dazu hatten wir ja hierhin (https://knx-user-forum.de/forum/%C3%...-programmieren) ausgelagert, es war schon toll, was nach nur 2 Wochen "rumprobieren" rausgekommen ist. Inzwischen nutze ich das produktiv in allen meinen Modulen und bin begeistert. Ich hatte bei der Änderung von einem 1-Byte-Parameter folgende Programmierzeiten (bei einem Parameter-Block von 8651 Byte):

• ohne Longframe, ohne partiell-Support (also der aktuelle Stand vom Stack):
  • Ganze Applikation: ca. 3 - 3.5 Minuten
  • Partiell (in der ETS ausgewählt): ca. 3 Minuten (hier wurde immerhin die KO und GA Übertragung von der ETS weggelassen)
• mit Longframe (also mit APDU=56), ohne partiell-Support:
  • Ganze Applikation: ca. 1.5 - 2 Minuten (bringt somit etwa Faktor 2)
  • Partiell (in der ETS ausgewählt): ca. 1.5 Minuten (da auch hier wieder KO und GA Übertragung wegfällt)
• ohne Longframe (alte Schnittstelle mit APDU=15), mit partiell-Support vom Stack:
  • Ganze Applikation: ca. 60 Sekunden (hier werden alle 0x00 nicht übertragen)
  • Partiell: ca. 10-15 Sekunden (hier wird neben den ganzen Verwaltungsinformationen und Zustandsübergängen wirklich nur das 1 Byte übertragen)
• mit Longframe (also mit APDU=56), mit partiell-Support vom Stack (hier nochmal der Faktor von ca. 2 gegenüber der Variante ohne Longframe):
  • Ganze Applikation: 25-30 Sekunden
  • Partiell: etwa 5-7 Sekunden (es wird auch nur das 1 Byte übertragen, die Verwaltungsinformationen aber in größeren Frames)

Ich finde das beachtlich und möchte es nicht mehr missen. Immerhin geht es hier um eine Steigerung von bis zu Faktor 36 (Idealfall, von 3 Minuten auf 5 Sekunden), häufig noch Faktor 25 (normalfall, von 3 Minuten auf 7 Sekunden). Natürlich verschwindet der Vorteil von partieller Programmierung, je weniger Parameter man hat und je mehr man bei einer Programmierung ändert/ändern muss.

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.

Gruß, Waldemar

[Ing-Dom]

man, vergesst die atmegas... die sind aus dem letzten Jahrtausend ...

[mumpf]

Nee, vergiss es. Wenn ich das eben richtig gesehen habe, sind das 8-Bit, 32k Flash und 2,5k Ram.

Wenn ich nur den Stack compiliere, braucht der schon um die 50k Flash und 5k Ram. Und dann ist da noch keine Firmware drauf und kein Parameter der Applikation.

Für so was ist der nicht gemacht. Nimm irgenein SAMD21 Board, damit geht das super! Da die MicroBCU dran und es läuft 1A.

Gruß, Waldemar

[thewhobox]

Das mit dem TP Anschluss wäre kein Problem. Hab die MicroBCU.
Wollte sowas auch bei nem Kumpel einbauen.
Hab auch nur ne IP-Schnittstelle.

Vll kann ich ja mal nen Port machen für atmel, wenn ich wieder mehr Zeit habe.

Gruß Mike

[mumpf]

Hi Mike,

Läuft der Stack eig auch auf einem Atmega?

das würde ich bezweifeln. Ich kenne mich aber nicht so in der Arduino-Welt aus... Aber wenn es nur ums das Ausprobieren vom Stack geht, solltest Du das auf einem Raspi machen, mit der Linux-Variante. Dann kannst Du auch über einen Router programmieren und brauchst keinen TP-Anschluss.

Gruß, Waldemar

[thewhobox]

OutOfSync wow sehr geil!

Arbeite bei der Kaenx auch viel mit der Seriennummer (zum finden neuer Geräte oder Adresse überschreiben).
Läuft der Stack eig auch auf einem Atmega?
Hab davon daheim noch einige rumliegen.

Gruß Mike

[mumpf]

Hi Julius,

cool, das werde ich auch noch in meinen Stack übernehmen. Dann kann ich die Geräte auch noch über die Seriennummer programmieren, falls ich mal den Prog-Knopf bräuchte und zu faul bin, die auszubauen...

Gruß, Waldemar

[OutOfSync]

Hi,

ich habe mich mit der Seriennummer der Geräte etwas auseinandergesetzt. Bisher war die ja fix programmiert auf 0x01020304 was Probleme macht wenn mehrere Geräte in der Installation sind (https://github.com/thelsing/knx/issues/90).

Die Lösung ist eine unique ID zu nutzen. Das habe ich testweise eingebaut (https://github.com/OutOfSync1/knx/commit/4018d98d0e5e65d536bc14ef5239fb3827058862). Ich hoffe dass ich das in KnxFacade() an der richtigen Stelle setze, direkt nach dem Überschreiben der Manufacturer Id.

Ausprobiert habe ich das nur auf dem ESP32, ESP8226 und STM32/SAMD sind "ins Blaue" rein programmiert. CC1310 und Linux fehlen ganz, da ist der Fallback auf 0x01020304. Vielleicht finden sich noch ein paarTester

Gruß, Julius

[Ing-Dom]

ich wollte hier nochmal nachfragen, ob Du noch eine andere Idee hast?

nein, ich denke das passt. Ich hätte auch noch eine Überprüfung empfohlen, direkt an der Stelle worauf aus ankommt, bzgl. Präprozessor kann man da nicht vorsichtig genug sein

[mumpf]

Hi,

wie hast du denn SERIAL_BUFFER_SIZE auf 256 erhöht? Welche Änderung genau in welchem File ?

ich wollte hier nochmal nachfragen, ob Du noch eine andere Idee hast? Ich habe inzwischen verifiziert, dass im RingBuffer.h der Wert aus meiner Compiler-Option genommen wird. Deswegen gehe ich auch davon aus, dass es im Uart.h genommen wird. Gibt es bei der Arduino-Plattform noch andere Files? Ich frage nur, weil Tante Google auch keine neuen Erkenntnisse gebracht hat.

Wobei es mit den aktuellen 53 Byte Nutzdaten auch schon toll läuft (Faktor 2.5). Und meine Schnittstelle scheinbar auch nur 63 Byte Nutzdaten kann. Aber ich würde gerne den Stack auf das Maximum setzen, falls andere Leute Schnittstellen haben, die mehr können.

Gruß, Waldemar