ESP8266 KNX mit ETS

[Mag Gyver]

Hallo Hendrik,

eventuell ist

   [LEFT][COLOR=#000000][FONT=Arial][SIZE=15px]SerialDBG.println("progmode on");[/SIZE][/FONT][/COLOR][/LEFT]

wohl besser.

Aber ich würde diese Meldung in die Funktion

   [LEFT][COLOR=#000000][FONT=Arial][SIZE=15px]void buttonUp()[/SIZE][/FONT][/COLOR][/LEFT]

integrieren. Aber die Entscheidung überlasse ich Thomas. Er kennt seine Library besser.

Gruß

René

[thesing]

Weil ein #include "knx/bits.h" fehlt. Dort sind die print-Funktionen deklariert. Definiert sind die Funktionen in den *_platform.cpp-Dateien.

[mumpf]

Hi,

ich fürchte, ich habe auch dumme Fragen... Im CreateKnxProd kann ich ja Parameter mit dem Typ Fließkommazahl definieren. Aber wie hole ich mir die im Coding ab? Ich habe bei bau.parameters() nur getByte(), getInt() und getWord() gefunden und kein getFloat() o.Ä., auch keine Funktion, die einen float zurück gibt.
Ist das noch nicht implementiert oder habe ich es einfach nur nicht gefunden?

Und welche DPT sollten denn bei den GroupObjects gehen? Ich habe irgendwie nur objectReadBool und objectReadFloatDpt9 (also DPT1 und DPT9) gefunden. Sehe ich das richtig, dass man sich derzeit alle anderen aus _data "rausparsen" muss (also über valueRef() den pointer auf _data holen und passend umwandeln)?

Gruß, Waldemar

[thesing]

Hallo Waldemar,
ich war an der Stelle einfach zu faul Konvertierungen für alle möglichen Datenpunkte zu definieren. Scheinbar hat es noch nicht einmal für ein readFloatDpt9() gereicht.
Letzlich muss man ja nur die Werte aus _data parsen oder dort reinschreiben. (Längenprüfung nicht vergessen. ) Ich nehme gern Pull-Requests für alle möglichen Datenpunkte an. Ursprünglich wollte ich für jeden Datenpunkt eine eigene Klasse von GroupObject ableiten, aber da die Datenpunkte nicht von ETS mitgeliefert werden (nur die Größe), sollte man wohl besser einfach pro Datenpunkt eine read und eine write Methode hinzufügen.

Bei den Parametern gibt es noch eine ähnliche Baustelle. Man könnte sich auch im CreateKnxProd eine Headerdatei mit einfacheren Zugriff auf die Parameter und KOs generieren. Dazu bin ich aber nie gekommen.

[mumpf]

Hi Thomas,

kein Problem, ich wollte nur wissen, ob ich irgendwas nicht gefunden oder anders verstanden hatte. Immerhin hast Du zum schreiben einige Methoden spendiert, deswegen dachte ich, dass ich beim Lesen vielleicht was nicht verstanden habe. Wenn ich mal so weit bin, kann ich gerne einen Pull-Request machen, derzeit erforsche ich immer noch, was alles geht.

Deswegen wollte ich mal über meine Fortschritte berichten und gleich noch Feedback/Fragen los werden:

Ich habe jetzt mal ein simples Echo-Szenario realisiert. Also man schickt einen Wert auf eine GA und bekommt den gleiche Wert, aber mit einem frei wählbaren anderen DPT zurück (derzeit nur DPT 1, 5 und 9). Ist natürlich sinnlos, erlaubt mir aber, den Stack zu testen und schon mal durchzuspielen, wie das Ganze mit KO läuft, die verschiedene DPT können.

Neben meinen Fragen von gestern ist mir noch folgendes aufgefallen (ich arbeite derzeit mit der Linux-Version auf einem Raspi und somit mit KNX-IP):

• Ich kann den Raspi nur über IP parametrieren (also ETS->Netzwerkschnittstelle->Raspi), wenn ich stattdessen meinen eibd als Router laufen lasse, dann kann ich zwar mit einem parametrierten Raspi über GA kommunizieren, aber keine Programmierung vornehmen.
• Die PA kann ich nur über IP vergeben, da streikt die ETS schon, wenn der eibd als Router parametriert ist -> das liegt wahrscheinlich am eibd, ich muss mal mit dem knxd testen.
• Nach einem erneuten parametrieren (dann eben über IP) ist das Gerät tot und antwortet auf keine GA. Ich muss den knx-linux-Prozess killen und neu starten, dann funktioniert das Gerät gemäß der neuen parametrierung. Mach ich da was falsch? Nach einer Parametrierung sollte sich das Gerät doch wie neu gestartet verhalten, oder?
• Ebenso hätte ich erwartet, dass sich das Gerät neu startet, wenn die ETS ein "Gerät zurücksetzen" schickt, Scheint aber nicht zu passieren (ich hatte einen Breakpoint beim lesen der flash.bin, ich hatte gedacht, das wird beim zurücksetzen sicherlich neu gelesen).
• Ich habe noch einen busware-TUL zu Hause, könnte ich den am Raspi dazu nutzen, Deinen Stack auch über TP auf dem RasPi zu nutzen? Ich habe leider keine Idee, wie ich das selber rausfinden kann.

Ich habe ja vor, das Ganze am Ende auf einem ESP8266 laufen zu lassen und sehe (unter anderem) einen Vorteil in Deinem Stack: Man kann unter Linux debuggen, alles schon testen und dann das Ganze auf einen Microcontroller bringen. Aber verhalten die sich gleich? Kann ich wirklich eine getestete Funktion ohne weitere Seiteneffekte einfach für den ESP kompilieren und dann geht es? Hast Du da Erfahrungen? Ich muss mir mal demnächst die Hardware bestellen...

Bisher bin ich echt begeistert, es geht vieles einfach so, sorry für meine Fragen, aber das sind Sachen, die mir "unterwegs" auffallen...

Gruß, Waldemar

[thesing]

Hallo Waldemar,

knxd bzw. eibd machen bei mir auch immer mal wieder Probleme. Bei den IP-Geräten brauchst du die aber auch nur, wenn du z.B. mit einer USB-Schnittstelle programmieren willst. "Direktes IP" im Sinn von KNX ist gar nicht implementiert. Wenn du in ETS die Netzwerkschnittstelle auswählst, schickt ETS die Telegramme als IP-Multicast. Ein eibd/knxd würde die einfach auch lesen und ins TP-Netzwerk weiterleiten. Der Raspberry-PI ist halt zufällig schon im IP-Netz und kriegt daher alles auch ohne eibd/knxd. Bei "direktem IP" würde ETS mitkriegen, dass man sich das Gerät per IP erreichen lässt und dann auch direkt IP-Pakete an das Gerät schicken.

Das Problem mit knxd/eibd beim Vergeben der PA habe ich auch. Der linux-Prozess sollte erneutes parametrieren überstehen. Der Prozess wird allerdings nicht neu gestartet. Das müsste man wahrscheinlich über einen exec*-call machen. Bisher wird einfach der alles mehr oder weniger gut neu initialisiert. Es kann durchaus sein, dass dann einiges nicht mehr richtig funktioniert. Gleiches gilt auch für "Gerät zurücksetzen".

Da das busware-TUL auch nur ein TP-UART ist, müsstest du nur die ganzen *uart*-Methode in LinuxPlatform implementieren (evtl. kann du da Code von knxd klauen). Wenn du dann die Bau07B0 nimmst, sollte schon alles funktionieren. TP-UART habe ich auf dem SAMD21 als NCN schon am laufen.
Ich finden man kann schon viel von Linux auf die anderen Platformen übertragen. Andersherum ist es schwieriger. Linux hat z.B. ein eigenes allocMemory da sonst die Speicheradressen zu groß für KNX-Memorywrite werden. (64 Bit halt). Ich programmiere übrigens meist auf einem Debian im Virtualbox.

[mumpf]

Hi Thomas,

vielen Dank für die ausführliche Antwort.

Bei den IP-Geräten brauchst du die aber auch nur, wenn du z.B. mit einer USB-Schnittstelle programmieren willst.

Ich sag es mal so: Im Finalausbau möchte ich über "irgendeine" Schnittstelle alle meine Geräte programmieren können, bei mir ist das derzeit entweder das MDT-IP-Interface (also Tunneling) oder eben der eibd. Ich will nicht für bestimmte Geräte umschalten müssen. Zusätzlich habe ich noch das Problem, dass mein Entwicklungsrecher ein Firmenrechner ist, der kein Multicast durchlässt und ich habe keinen Zugriff auf die Firewall.
Für die Entwicklung ist das OK, dass ich Schnittstellen und auch Rechner wechsle, aber final soll alles über die MDT-Schnittstelle gehen.

Wenn du in ETS die Netzwerkschnittstelle auswählst, schickt ETS die Telegramme als IP-Multicast. Ein eibd/knxd würde die einfach auch lesen und ins TP-Netzwerk weiterleiten. Der Raspberry-PI ist halt zufällig schon im IP-Netz und kriegt daher alles auch ohne eibd/knxd.

Das war mir klar, dadurch habe ich auch gelernt, dass mein Firmenrechner dafür nicht geeignet ist, hier bietet die ETS auch gar nicht die Schnittstelle zur Auswahl an.

Bei "direktem IP" würde ETS mitkriegen, dass man sich das Gerät per IP erreichen lässt und dann auch direkt IP-Pakete an das Gerät schicken.

Das ist mir neu, wusste nicht, dass es geht - aber man lernt nie aus.

Der linux-Prozess sollte erneutes parametrieren überstehen. Der Prozess wird allerdings nicht neu gestartet. Das müsste man wahrscheinlich über einen exec*-call machen. Bisher wird einfach der alles mehr oder weniger gut neu initialisiert. Es kann durchaus sein, dass dann einiges nicht mehr richtig funktioniert. Gleiches gilt auch für "Gerät zurücksetzen".

Wie kriege ich denn programmtechnisch mit, dass programmiert wurde bzw. dass das Gerät von der ETS zurückgesetzt wurde? Ursprünglich dachte ich, dass setup() nochmal aufgerufen wird, aber das passiert nicht. Müsste es nicht dafür auch einen callback geben? Ich möchte nach einem Neustart (egal ob über Stromausfall, Programmierung oder "Gerät zurücksetzen") einige Ein- bzw. Ausgänge parametrisierbar vorbelegen. Das habe ich bisher nicht gefunden. Prozess neu starten muss natürlich nicht sein... Ich muss einfach mal forschen, warum sich das Ding immer nach dem Programmieren aufhängt.

Da das busware-TUL auch nur ein TP-UART ist, müsstest du nur die ganzen *uart*-Methode in LinuxPlatform implementieren (evtl. kann du da Code von knxd klauen). Wenn du dann die Bau07B0 nimmst, sollte schon alles funktionieren.

OK, ich glaube Dir, dass es für Dich ganz einfach wäre... Du überschätzt meine Fähigkeiten hier aber deutlich. Mein letztes C/C++-Projekt liegt ca. 30 Jahre zurück, ich bin voll begeistert, wie einfach Dein Stack ist, dass sogar ich damit klar komme, aber dass ich irgendwas implementiere, dass ganz low level Richtung Kommunikation geht, das traue ich mir doch nicht zu.

TP-UART habe ich auf dem SAMD21 als NCN schon am laufen.

Dann wird das meine Zielplattform. Ich würde am liebsten exakt Deine Hardware verwenden, dann kann ich sicher sein, dass es läuft. Hättest Du da einen Link für mich? Und was für eine BCU kommt da dran?

Danke nochmal und Gruß,
Waldemar

[thesing]

Ich habe so ein Board (oder einen Klon davon) https://www.ebay.de/itm/WeMos-D1-SAM...frcectupt=true als BCU habe ich die normale MicroBCU von Konnekting.

Ich bin die Woche im Urlaub, aber danach kann ich mal schauen, dass ich dem Linux einen vernünftigen Neustart bei bringe.
Bei Linux kriegst du bisher nicht heraus, dass neu gestartet wurde. Bei den anderen Platformen würdest du wieder an setup() vorbeikommen wie du schon meinst.

[mumpf]

Hi Thomas,

ich werde mal die Hardware besorgen, danke für den Link. Ansonsten habe ich alles durch getestet, was mir wichtig war:

• 2 KO mit je 3 verschiedenen DPT können mit Deiner neuen Längenanpassung jetzt wirklich als 2 KO realisiert werden (sonst bräuchte man 6 KO), wenn man in der Firmware den passenden Parameter auswertet und so immer passend zum DPT das KO ausliest - Super! Das spart massig Speicher.
• Mehrere Parameter können sich den gleichen Speicherplatz teilen, wenn man weiß, dass nur einer der Parameter wirklich eingestellt werden kann, das funktionierte schon vorher bei Dir, trotzdem Super! Das spart nochmal Speicher!
• Wie man einen Parameter, der im CreateKnxProd als Fließkommazahl definiert wurde, dann im Coding ausliest habe ich auch rausbekommen.
• Und ich habe rausbekommen, dass sich Linux nicht nach dem Programmieren aufhängt, sondern dass die Callbacks verloren gehen. Meine Vermutung: Vor dem Programmieren initialisierst Du alle GroupObjects, damit sie dann passend mit den Längenangaben der ETS neu erstellt werden können. Dadurch sind aber alle callbacks weg, da sie ja am GroupObject hängen. Und da bei mir die callbacks im setup() gesetzt werden, das aber wie von Dir erwähnt unter Linux nicht erneut durchlaufen wird, bekommt man keine Eingangstelegramme mehr vom KNX...

Dir schon mal einen schönen Urlaub und vielen Dank für Deine Unterstützung,
Gruß, Waldemar

P.S.: Eine Frage, die ich schon immer stellen wollte: Warum heißen die Dinger eigentlich GroupObjects und nicht CommObjects?

[thesing]

Ok. Dann muss ich mal schauen wie man die callbacks über den fake-reset rettet.
Ich kann nur raten warum die GroupObjects heißen. Ich habe das nur aus der Spezifikation übernommen. Vermutlich weil man da immer mit einer Gruppe redet. Die Gruppe mit der entsprechenden Gruppenadresse. Der Begriff CommObject ist mir in der Spezifikation nicht unter gekommen. Den kenne ich nur aus der knxprod-XML. Aber ich mag mich auch irren.

[mumpf]

Ok. Dann muss ich mal schauen wie man die callbacks über den fake-reset rettet.

Muss man vielleicht nicht... Wenn es so ist, dass auf der anderen Hardware wieder setup() durchlaufen wird, dann sollte man im Linux es genau so hin bekommen. Dort kann man dann durchaus noch eigene Sachen initialisieren und wieder die callbacks setzen.

Wie gesagt, ich finde es bei Deinem Stack besonders schön, dass man alles unter Linux debuggen kann, bevor es auf andere Hardware portiert wird und bin daran interessiert, dass man möglichst ein gleiches Verhalten der Plattformen erreicht.

Dir einen schönen Urlaub und ich sehe zu, dass ich mein Logikmodul-Coding bis kommendes WE auf deinen Stack portiert bekomme.

Gruß, Waldemar

[mumpf]

Hi Thomas,

auch wenn Du im Urlaub bist, stell ich hier kurz mal meine Fragen, bevor ich sie vergesse - Du sollst ja nach dem Urlaub was zum nachdenken haben .

Ich hab jetzt mal ein bisschen gerechnet: Mit den ganzen Parameter- und Kommunikationsobjekt-Überlagerungen bekomme ich aus der ETS folgendes raus:

• Einen Parameterblock von 114 Bytes pro Kanal
• 3 Kommunikationsobjekte pro Kanal mit insgesamt 22 Bytes.

Da ich 80 Kanäle realisieren will, komme ich auf einen Parameterblock von 9120 Bytes und dann noch 1760 Bytes für die KO, macht zusammen 10880 Bytes. Zur Laufzeit brauche ich dann noch ca. 2k, so dass ich ca. 13k der vorhandenen 32k Ram vom SAMD verbrauchen würde (ich gehe davon aus dass alle Parameter beim Start ins Ram kopiert werden, oder?). Wie viel brauchst Du denn mit Deinem Framework, der Zuordnungstabelle KO zu GA (kann ja mehrere geben und ich hätte 240 KO) und die restliche Laufzeit? Reichen die verbleibenden 19k?

Wenn ich alle Boolean-Parameter von Byte auf Bit ändere und alle Enums mit weniger als 16 Werten auf Nibbles umstelle, kann ich wahrscheinlich nochmal 2k an Parametern sparen. Und wenn ich zur Laufzeit direkt die GroupObjects beschreibe (ohne zu senden), dann kann ich nochmal 1k Ram sparen, aber mehr geht dann nicht.

Aber ich würde das nur machen wollen, wenn es nötig ist, macht das Coding nämlich nicht wirklich übersichtlicher.

Und dann noch eine Frage (werde ich aber auch noch mal die Woche testen): Wenn ich die selbe GA mit einem Ausgang und einem Eingang verbunden habe und der Ausgang sendet, bekomme ich den Wert am Eingang signalisiert (wird also der callback aufgerufen)?

Gruß, Waldemar

[henfri]

Hallo,

ast du Routing als Interface in ETS gewählt?

Ja, siehe Screenshot:
ETS_routing.JPG

Sind der Rechner mit ETS und der ESP im gleichen Netz? (Manche Switche leiten Multicast nicht standartmäßig weiter.)

Ja, ich habe einen ganz dummen Switch. Nix aktives.
PC -> Kabel -> Switch -> Unifi-AP -> ESP

Hast du nach der Konfiguration vom WLAN des ESP den mal neu gestartet?

Ja.

Kann es auch am KNXD liegen?
Die Optionen, die ich nutze sind:

knxd -e 1.0.200 -E 1.0.201:8 -DTRS -c -i --send-delay=120 -B single -b ipt:192.168.177.8

Das komische ist ja auch, dass es mal funktionierte - und ich bin mir echt nicht bewusst, etwas geändert zu haben.
Und: Es kommt trotz "printHex" gar nix auf der seriellen Schnittstelle...
Was mir noch einfällt: Ich nutze ja den Sketch des BME680, aber ggf. andere Hardware (I2C adresse und NodeMCU). Kann es sein, dass der Sketch hängt, weil er die Hardware nicht initialisiert bekommt? Welche Pins benutzt du noch per Default für sda/scl?

• SDA=4 => D2.
• SCL=5 => D1

ist richtig, oder?

Wenn ich den Sketch richtig verstehe, sollte

Timestamp [ms], raw temperature [°C], pressure [hPa], raw relative humidity [%], gas [Ohm], IAQ, IAQ accuracy, temperature [°C], relative humidity [%], CO2

erst kommen, wenn KNX konfiguriert ist. Das ist es bei mir aber ja noch gar nicht. Trotzdem kommt es.

Gruß,
Hendrik

[mumpf]

Hi Thomas,

mein Grundgerüst läuft schon und ein erstes "AND" mit "nur senden, wenn Eingang 1 getriggert wurde" funktioniert auch schon. Bei diesem Test ist mir ein Bug im Framework aufgefallen: Wenn ich ein Read-Request auf eine GA sende, die einem GroupObject mit den Flags K, S und A (oder Englisch Communication, Write und Update) zugeordnet ist, antwortet das GroupObject trotzdem. Ohne L-Flat (also Read) dürfte es das aber nicht...

Ich werde am WE versuchen, da tiefer rein zu debuggen, aber vielleicht weißt Du ja auch schon so, was Sache ist.

Trotzdem als Rückfrage: Ich gehe davon aus, dass sich Dein Framework so verhält, dass die Flags, die in der ETS gesetzt werden, bei der Kommunikation berücksichtigt werden, oder? Sprich:

• Wenn kein Ü-Flag sitzt, dann führt ein objectWrite nicht zum schreiben auf den Bus
• Wenn kein Ü-Flag sitzt, kann dieses GroupObject kein ReadRequest absetzen
• Wenn kein L-Flag sitzt, kann man das GroupObject nicht per ReadRequest lesen
• Wenn kein S-Flag sitzt, kann man das GroupObject von außen nicht beschreiben
• Wenn kein A-Flag sitzt, dann wird das GroupObject durch ein ReadResponse nicht verändert.
• Wenn kein K-Flag sitzt, sollte gar keine Buskommunikation stattfinden

Das letzte ist (meiner Meinung nach) nicht wichtig, da man dann gar kein Kommunikationsobjekt bräuchte. Zumindest hatte ich noch keinen praktischen Fall, bei dem ich das K-Flag zurücksetzen wollte. Aber bei den anderen durchaus schon...

Gruß, Waldemar

[mumpf]

Hi Thomas,

leider gibt es bei mir eine Zwangspause, ich muss ungeplant für 7-10 Tage ins Krankenhaus. Werde in der Zeit nicht testen können, lese aber weiter mit...

Gruß Waldemar