ESP8266 KNX mit ETS

[metaneutrons]

Moin Waldemar,

momentan erstmal nur Wifi. Mein nächstes Ziel ist die Nutzung des LAN8710 (ich habe ein Olimex ESP32-EVB mit Ethernet). Dann könnte das Ding im meinem Rack verschwinden und wäre sauber als flexibler Controller (Zeitserver, Zeitschaltuhr, Brandmelder, Klingelsteuerung, SMS-Gateway) per Ethernet angebunden.

Zwischen LAN/Wifi und TP wechseln ist aber auch auf meinem Wunschzettel. Das könnte man im Moment am einfachsten mit konditionaler Kompilierung lösen, direkt über die Library wäre es aber eleganter. Das schaue ich mir aber sicher noch mal an.

Nutzt hier jemand überhaupt den ESP32?

Herzliche Grüße, Fabian

[mumpf]

Hi Fabian,

Ist der ESP32 über WLAN oder über TP angebunden? Ich wollte mal den ESP8266 über TP ohne WLAN nutzen, aber da bin ich nicht der richtige, das zu schaffen...

Gruß, Waldemar

[metaneutrons]

Moin zusammen,

da ich zwischenzeitlich nahezu vollständig auf den ESP32 umgestiegen bin, habe ich mir erlaubt, den Stack um die Platform ESP32 zu erweitern. Falls das von allgemeinem Interesse ist, kann ich gerne auch einen PR machen. Den Fork mit ESP32 Unterstützung findet ihr unter https://github.com/metaneutrons/knx.

Herzliche Grüße, Fabian

[mumpf]

Hi Thomas,

Das mit dem zwei Instanzen auf dem gleichem Rechner...

ich brauche das nicht wirklich, Linux ist für mich primär Entwicklungs- und Testumgebung. Beim Restart hatte ich aber erstmal 2 Instanzen gestartet und versucht, mit der einen die andere neu zu starten - und das hat nicht geklappt. Hab dann ewig den Fehler bei mir gesucht, bis ich auf die Idee kam, es mal mit einem anderen (TP) Gerät zu testen... sollte somit eher eine Info für andere sein.

Die Anwendung macht einfach ein knx.restart(PA). Das geht zu BauSystemB::restart(PA).
Dort wird geschaut, ob es zur PA schon eine Verbindung gibt. Wenn ja einfach restartRequest senden. Sonst ConnectRequest. und den Restartrequest erst senden, wenn das ConnectConfirm kam.

Dann werde ich das mal so machen. Um aber eine queue zu vermeiden, werde ich ein   bool knx.restart(PA)  machen. Falls das Gerät nämlich bereits mit einem anderen Gerät verbunden ist und gar kein Connect abgesetzt werden kann, wird ein false zurückgeliefert. Und selbst wenn das Gerät mit der Ziel-PA bereits verbunden ist, sollte man wirklich einfach ein restart senden? Nehmen wir mal den hypothetischen Fall, dass dieses Zielgerät gerade programmiert wird? Da würde ein restart zwischendurch wirklich stören . Ich würde beim restart dazu neigen, den nur zuzulassen, wenn man die Sequenz Connect->Restart->Disconnect komplett machen darf.
Den Rest dann so wie Du es sagst.

Schön, dass Du wieder da bist, ich bin auch gerade auf dem Rückweg vom Urlaub...

Gruß, Waldemar

[thesing]

Ich habe gerade zwei Änderungen gemacht:
- mdelay und millis wurden aus der Platform entfernt. Unter Linux gibt es linux_platform.cpp delay und millies als normale Funktionen.
- KnxFacade ist nun eine Template-Klasse. D.h. Man kann durch knx.bau() sich die richtige Bau und mit knx.platform() die richtige Platform holen. Damit kann man z.B. bei Samd21 auf die genutzte SamdPlatform-Instanz zugreifen. ( Bernator damit kannst du z.B. den gewünschten Serial setzen an dem der TPUART hängt.)

mumpf Das mit dem zwei Instanzen auf dem gleichem Rechner liegt wahrscheinlich an https://github.com/thelsing/knx/blob...tform.cpp#L132
Wenn man das auf 1 setzt wird es wahrscheinlich gehen. Aber dann bekommt jede Instanz auch die selbst verschickten Muticast-Pakete. (AFAIR)

Mit dem Restart hab ich mir das in etwa so vorgestellt:

Die Anwendung macht einfach ein knx.restart(PA). Das geht zu BauSystemB::restart(PA).
Dort wird geschaut, ob es zur PA schon eine Verbindung gibt. Wenn ja einfach restartRequest senden. Sonst ConnectRequest. und den Restartrequest erst senden, wenn das ConnectConfirm kam.
Wenn das geht, könnte man den Stack perspektivisch auch nutzten um damit andere Geräte zu programmieren. (quasi als ETS-Ersatz.)

Den Rest deines Posts muss ich noch prüfen.

[mumpf]

Hi Thomas,

ich möchte nochmal auf das hier zurückkommen (ist lange her) - aber bitte erst nach Deinem Urlaub(!) lesen:

restart: Das ist nicht soo einfach. Du musst erste eine mit TransportLayer.connectRequest eine Verbindung zum Ziel aufmachen. Die steht sobald das ApplicationLayer::connectConfirm kommt. Danach kannst du den restartRequest schicken. Bisher ist der der Stack noch nicht so ganz darauf vorbereitet. Ich muss mal schauen wie man das ansynchrone Zeug in C++ am besten macht.

Ich hab da was versucht... Letztendlich war ich erfolgreich und bin auch daran interessiert, dass die Realisierung auf die eine oder andere Weise im Stack einzieht, da mir die Funktion wichtig ist. Folgendes habe ich gemacht:

• Ich habe connect und disconnect in der knx_facade verfügbar gemacht (analog zu restart)
• Ich setze in meinem Coding im Abstand von 500ms (geht wahrscheinlich auch schneller, muss ich mal testen) die Befehle connect, restart, disconnect ab
• Der connect wird auf dem applicationLayer zu einem transportLayer->connectRequest gefolgt von einem deviceDescriptorReadRequest, da der connect selbst nicht beantwortet wird und erst der deviceDescriptorReadRequest einen ACK bekommt. Ob das so notwendig ist, weiß ich nicht, aber die ETS macht es genau so.
• Im transportLayer hab ich dann lange gebraucht (vor allem, weil ich bis zur KNX-Spec musste, um halbwegs zu verstehen, was da abgeht), da der Connect nie abgesetzt wurde. Letztendlich fehlt da in der StateEngine im A12 ein
  

  _networkLayer->dataIndividualRequest(AckRequested, _connectionAddress, NetworkLayerParameter, SystemPriority, tpdu)

  steht auch so in der Spec 3.3.4 S. 20 bei A12: „send N_Data_Individual.req with T_CONNECT_REQ_PDU“.
  Im ApplicationLayer::ConnectConfirm fehlt ein
  

  if (status) _connectedTsap = destination

An sich war es das und es funktioniert. Ist ja auch das, was Du damals geschrieben hast, nur brauchen normale Menschen etwas länger, um das zu verstehen und noch länger, um es zu realisieren.
Ich werte in der Anwendung nicht aus, ob der connect geklappt hat, aber wenn nicht, wird auch der reset nicht verschickt. Die Kommunikation ist identisch zu der von der ETS und die Geräte reagieren auch darauf. Meine Änderungen stören auch an keiner Stelle die Gruppen-Kommunikation oder die ETS-Programmierung – zumindest ist mir nichts aufgefallen.

Wenn man die Implementierung so lässt, dann würde man es der Applikation, die Deinen Stack nutzt, überlassen, die Reihenfolge und das Timing einzuhalten und auch sicherzustellen, dass nicht 2 connects parallel abgesetzt werden. Da ich wahrscheinlich der einzige Nutzer bin, ist die Frage, ob das für Dich OK wäre, es so zu lassen.

Eine andere Möglichkeit wäre natürlich, das Ganze auf dem ApplicationLayer zu realisieren und nur ein Kommando RestartDevice nach oben zu geben, aber dann bräuchte man eine Queue und müsste sauber auf die Connects/Disconnects reagieren und auf jeden Fall in loop() eingreifen. Wenn Du das unbedingt willst, würde ich mich daran wagen, aber lieber wäre mir die aktuelle Lösung. Ich verhindere konkurrierende Resets derzeit über ein if – ein konkurrierender Reset wird einfach um 2 Sekunden verzögert ausgeführt.

Ich kann gerne einen Pull-Request mit den Änderungen zusammenstellen (diesmal in einem neuen branch), ich hab das Coding ja da, ich wollte das aber prinzipiell vorher mit Dir geklärt haben und den anderen Beteiligten die Möglichkeit geben, auch was dazu zu sagen. Vielleicht gibt es auch andere Ideen...

Gruß, Waldemar

P.S.: Was mir beim testen noch aufgefallen ist: Wenn 2 Linux-Instanzen auf dem selben Rechner laufen, dann hören die sich gegenseitig nicht. Beide können senden und empfangen (werden z.B. von der ETS gehört und die ETS kann GA senden), aber nicht der eine zum anderen. Auf dem NetworkLayer kommen die Pakete gar nicht an. Da ich keine Idee habe, woran das liegen könnte, habe ich hier nicht weiter geforscht.

[mumpf]

Hi Thomas,

Linkable flag.

werde ich testen, danke für den Tipp. Mir geht es nicht um genau eine knxprod, das war blöd ausgedrückt. Mir geht es um eine einfache Debug-Umgebung. Ich denke eben an mein Logikmodul mit 50 Kanälen (SAMD, über TP angebunden), aufwändig parametrisiert und potentiell über längere Zeit bereits laufend. Nun stelle ich doch ein unerwartetes Verhalten fest, dass ich auch reproduzieren kann.

Einfach: Ich ziehe jetzt genau dieses Gerät von der TP auf die IP-Linie, programmiere mein Linux-basiertes IP-Gerät mit der ETS, schaue ob da der Fehler auch passiert und wenn ja, debugge ich komfortabel unter Linux bis ich den Fehler gefunden habe.

Kompliziert: Ich versuche, alle Parameter auf ein gleichartiges IP-Gerät (passende Version, aber eben nicht die gleiche) in der ETS zu übertragen (fehleranfällig) und versuche es dann unter Linux zu reproduzieren.

Noch komplizierter: Ich instrumentiere die firmware mit print-Ausgaben und versuche so den Fehler auf dem SAMD zu finden.

Ich versuche somit nur, den Komfort für mich zu erhöhen. Und dazu brauche ich eine Applikation, die unter TP und IP läuft. Nicht umsonst machst Du Deine Entwicklung vom Stack ja auch unter Linux. Ich kann damit leben, dass ich die MaskVersion für bau57B0 lokal bei mir anders zurück gebe als im allgemeinen Stack und verstehe auch, dass es nicht in den Stack rein gehört.

Gruß, Waldemar

[mumpf]

Hi,

ich gebe zu, ich habe meine Änderungen zu DPT9 nur unter Linux getestet, sollte aber auf der Ebene unabhängig von der Plattform sein. Den BME kann ich mangels Hardware nicht testen...

Gruß, Waldemar

[jorues]

Hab die Änderungen mal kurz mit dem BME Sketch getestet, dieser liefert leider immer noch nur die 0-Werte.
Weiß jemand was für einen Datentyp die iaqSensor Lib liefert? Ich denke es liegt daran.
Grüße

[thesing]

Ich habe den Pull-Request zu Dpt 16 gemergt. Wenn du längere Texte brauchst könntest du Dpt 24.001 implementieren.

[thesing]

Ich denke es ist am besten wenn man für den Pull-Request immer einen eigenen Branch macht. Immer wenn du auf den Branch einen neuen Commit machst, wird der automatisch dem Pull-Request hinzugefügt.

Zu den knx-Prods: Wenn du einfach nur eine knxprod haben willst, kannst du auch einfach mehrere Applikationsprogramme und Produkte in die knxprod packen. Dann muss man in ETS zwar immer noch das richtige auswählen, aber sollte ja kein Problem darstellen, oder? Es schein für das Appliationsprogramm noch ein Linkable Flag zu geben:

Linkable flag. Specifies that the application program may be loaded not only in devices with the specifies mask version, but also in compatible ones. See also Fixup.

Vielleicht reicht das ja schon.

[mumpf]

Hi Thomas,

ich habe noch einen Pull-Request für DPT16 nachgeschoben, bisher wurde das nur vom Bus gelesen, konnte aber nicht geschrieben werden (https://github.com/thelsing/knx/pull/28/files). Ich habe das Gefühl, dass ich da was falsch mache, denn es sind 5 commits in dem pull request, obwohl ich vorher mein Repository auf den selben Stand wie Dein Repo gemerged habe. Es ist aber nur 1 File unterschiedlich, das ist soweit korrekt.

Bin für Hinweise dankbar, was man hier besser machen kann, denn ich wollte nochmal (nach Absprache mit Dir) noch eine größere Änderung rein bringen, die den "Restart device" Befehl realisiert - den habe ich jetzt mal erfolgreich realisieren können, allerdings noch experimentell.

Aus meiner Sicht hat das alles Zeit, genieße Deinen Urlaub, ich habe das nur hier festgehalten, damit ich es nicht vergesse.

Gruß, Waldemar

[mumpf]

Hi Thomas,

ich nochmal... ich habe jetzt zwar eine Datei mit den korrekten CRLF hochgeladen, aber da github immer den diff zum letzten commit anzeigt, wird dieses File natürlich auch vollständig als diff angezeigt. Ich habe aber folgende Möglichkeit im github entdeckt:
hideWhitespaces.PNG
Damit kannst Du die Changes meines ersten commit sehen und auch sehen, dass der 2. commit keine programmrelevanten Änderungen enthält. Ich werde in Zukunft genauer drauf achten. Für mich ist es auch neu, dass alle meine commits automatisch zu einem pull request werden? Das hätte ich nicht erwartet...

Gruß, Waldemar

[mumpf]

Hi Thomas,

ich hab das mal untersucht, ich habe 3 Linux Maschinen, auf 2 davon geht git clone ohne probleme, auf meinem Entwicklungsrechner sind aber direkt nach dem clone gleich 18 files "modified", und es sind doch die mit CRLF. Es liegt an .gitattributes, da der Eintrag text = auto. Wenn ich den auskommentiere, dann klappt es. Warum das nur auf dem einen Linux-Rechner so ist und nicht auf den anderen beiden, weiß ich nicht. Der einzige weitere Unterschied ist, dass die beiden funktionierenden unter Debian, der Entwicklungsrechner auf Ubuntu läuft.

Hat hier sonst noch jemand solche Probleme? Und wie habt ihr sie gelöst?

Ich werde jetzt nochmal versuchen, eine bereinigte Version zu pushen, damit der Pull-Request besser aussieht.

Gruß, Waldemar

[mumpf]

Hi Thomas,

danke für die Antwort - trotz Urlaub. Sorry, das war mein erster Pull-Request, und schon ging es schief. Ich habe eigentlich nur die Änderung für DPT9 in den Pull-Request gepackt, der 2. change danach sollte noch nicht rein, weil ich auch gesehen habe, dass da alle Zeilen im diff sind. Ich habe aber noch nicht rausfinden können, warum, der erste Verdacht LF statt CRLF oder umgekehrt ist es wohl nicht. Eigentlich wollte ich den change zurücknehmen, aber wie gesagt, ich dachte, das wäre alles lokal bei mir...

Ich bin auch im Urlaub , werde aber morgen gleich schauen. Ich hab eigentlich auch noch DPT16 fertig gemacht, will das aber nicht pushen, solange ich das mit den full file changes nicht im Griff habe...

Genieße erstmal Deinen Urlaub, das mit dem Pull ist nicht eilig.

Gruß, Waldemar