ESP8266 KNX mit ETS

[evolution]

Danke, ist ein komplizierter Beinbruch, werde demnächst viel Zeit zu Hause verbringen müssen/dürfen...

Autsch. Gute Besserung!

[mumpf]

Naja, die "main exec pipeline" für asynchrone Sachen wie Ein- und Ausschaltverzögerungen steht schon. Die Logikfunktionen und Verarbeitung des Ausgangssignals auch. Bei den Eingängen brauche ich noch (und jetzt logischerweise länger), da sollten noch für Eingänge mit DPT > 1 Intervall- und Hysterese-Funktionen rein. Und ich muss noch rausfinden, wie ich mit dem Stack DPT 16 schreibe.

Aber die große Herausforderung wird es, das auf den SAMD zu bringen, das hab ich einfach noch nie gemacht.

Find ich super spannend...

Gruß Waldemar

[henfri]

Na dann geht es mit dem Logikmodul ja bestimmt erstmal langsam, danach aber um so schneller voran ;-)
Sag Bescheid, wenn dir langweilig wird. Uns fällt bestimmt noch was ein. ;-)

[mumpf]

Danke, ist ein komplizierter Beinbruch, werde demnächst viel Zeit zu Hause verbringen müssen/dürfen... Geistig bleibe ich aber dabei!

Gruß Waldemar

[henfri]

Ui. Gute Besserung!

[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

[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

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

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

[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

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

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]

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,

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]

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.