ESP8266 KNX mit ETS

[thesing]

Hallo Nanosonde ,

es sollte funktionieren. Es wird für ein SmarthomeNG Plugin von mir genutzt:
https://knx-user-forum.de/forum/supp...en#post1315402
bzw. https://github.com/thelsing/knx_ets

Mehr Beispiele als dort gibt es nicht.
Einschänkungen:
- nur Linux
- keine Parameter
- keine DPT-Konvertierungen (nur Raw Wert)

Das kann natürlich gern erweitert werden. Das Moduls gibt es übrigens auch auf pypi

VG Thomas

[mumpf]

Hi,

Bernator: Ich glaube, ich habe einen Fehler in Deiner Implementierung der SAMD asyc Kommunikation gefunden... Es geht um das T_Connect Kommando. Du schickst

=>[COLOR=#FF0000]29[/COLOR] 00 B0 60 10 [COLOR=#00FF00]06[/COLOR] 10 73 00 80 [COLOR=#FFA500]DA[/COLOR]

Die ETS schickt

->[COLOR=#FF0000]2E[/COLOR] 00 B0 60 10 [COLOR=#00FF00]FA[/COLOR] 10 73 00 80

Die roten Bytes sind das Problem (denke ich), die grünen sind OK, da die ETS ja ne andere PA hat als der SAMD. Und das orangene Byte ist wohl eher ne Prüfsumme, die Du ausgibst und das man in der ETS nicht sieht. Den selben Unterschied sieht man auch beim T_Disconnect, Du sendest

=>[COLOR=#FF0000]29[/COLOR] 00 B0 60 10 [COLOR=#00FF00]06[/COLOR] 10 73 00 81 [COLOR=#FFA500]DB[/COLOR]

und die ETS:

->[COLOR=#FF0000]2E[/COLOR] 00 B0 60 10 [COLOR=#00FF00]FA[/COLOR] 10 73 00 81

Ich habe auch im Coding folgendes gefunden (in tpuart_data_link_layer.cpp)

    if (_waitConfirm) {
        if (millis() - _waitConfirmStartTime > CONFIRM_TIMEOUT) {
            println("L_DATA_CON not received within expected time");
            uint8_t cemiBuffer[MAX_KNX_TELEGRAM_SIZE];
[COLOR=#FF0000]            cemiBuffer[0] = 0x29;
            cemiBuffer[1] = 0;[/COLOR]
            memcpy((cemiBuffer + 2), _sendBuffer, _sendBufferLength);
            dataConBytesReceived(cemiBuffer, _sendBufferLength + 2, false);
            _waitConfirm = false;
            delete[] _sendBuffer;
            _sendBuffer = 0;
            _sendBufferLength = 0;
            if (_loopState == RX_WAIT_DATA_CON)
                _loopState = IDLE;
        }
    }

Da weist Du die beiden Werte konstant zu. Das scheint die Problemstelle zu sein.

Ich muss aber sagen, dass das alles reine Vermutung meinerseits ist, ich habe mich mit vielen print-Ausgaben bis zu dieser Stelle vorgearbeitet und kann nicht behaupten, dass ich durch Dein Coding hier durchsteige. Deswegen habe ich auch keine Ahnung, wie ich das korrigieren soll. Ich bräuchte da irgendwie Hilfe...

Fakt ist, diese Protokolle erscheinen nicht im Gruppenmonitor der ETS, ich habe aber in meiner Anlage ein Gerät gefunden (BEG PM), dass auch auf dieses "falsche" T_Connect reagiert. Aber auch ein anderes Gerät (Temperatursensor), dass nicht darauf reagiert. Also denke ich, dass es so nicht korrekt ist... Wo müsste man reingreifen und woran erkennt man, ob ein 2E oder eine 29 im frame stehen muss?


Gruß, Waldemar

[thesing]

Hallo mumpf,

die stelle die du gefunden hast hat nichts mit deinem Problem zu tun. Die gefundene Stelle ist für den Empfang da. Die beiden Bytes sind die ersten Bytes von einem Cemi-Frame vom Typ L-Data.ind mit (0x29) mit 0 Bytes an "Additional Information" (Siehe 3/6/3)

Es aber wirklich das erste Byte das Problem zu sein. Bit 2+3 kann du durch dir Priorität beeinflussen. 0+1 sollten eigentlich immer 0 sein. Hab auch die Schnelle nicht gefunden, wo die gesetzt werden. Probiert mal bei CemiFrame::fillTelegramTP(uint8_t* data) zu schauen ob da schon data[0] falsch gefüllt wird. Wenn ja muss es schon ein Problem beim Erstellen des CemiFrames geben.(Evtl. nicht initialisierter Speicher?). Ich glaube nicht, das es ein Problem vom tp-uart-Datalinklayer ist. Solltest du also unter Linux debuggen können.

Edit: Ok. Falsch. Unter Linux wird ja IP genutzt. Da müssen die Bits wahrscheinlich nicht unbedingt 0 sein.

VG Thomas

[mumpf]

Hi Thomas,

unter Linux funktioniert es. Da kommen die Bytes exakt so wie in der ETS. Es muss somit schon was mit der TP implementierung zu tun haben.

Die gefundene Stelle ist für den Empfang da.

Das dachte ich beim Namen der Methode auch. Aber ich habe ein Telegramm von 1.0.6 an 1.0.115 gesendet. Warum wird genau dieses Telegramm in einer Empfangs-Methode zusammengebaut? Da würde ich ja Telegramme erwarten, die entweder eine GA als Ziel haben oder 1.0.6 als Ziel und nicht als Quelle. Deswegen kam ich drauf, dass es da passiert. Das war zumindest mein Gedankengang...

Vielleicht weiß ja Bernator mehr und kann einen Tipp geben.

Gute Nacht,
Waldemar

[Bernator]

Die Codestelle oben behandelt nur das TX timeout, also wenn der TPUart nicht mit einem etnsprechenden Echo auf ein Frame vom Stack reagiert wird hier der Schicht darüber signalisiert das beim Senden was schief ging, ich denke also nicht das dies hier dein Problem ist. Aber es stimmt das alle ankommenden Frames in ein CEMI Frame beginnend mit den beiden Konstanten 0x29 0x00 gepackt werden, warum das so ist müsste Thomas wissen denn das hat er bei der alten Variante auch so gemacht, hab ich nur übernommen.
Das CEMI Frame scheint nur ein Container für höhere Schichten zu sein, der TPUart kennt das nicht un empfängt/sendet nur blanke Frames ohne CEMI Header.
Von deinem oben genannten CEMI Frame:

=>29 00 [COLOR=#FF0000]B0 60 10 06 10 73 00 80 DA[/COLOR]

wird also nur der rot markierte Teil tatsächlich auf den Bus gesendet, ich denke die Gegenstelle wird dann wieder einen entsprechenden CEMI Header dazubauen?

[Bernator]

Warum wird genau dieses Telegramm in einer Empfangs-Methode zusammengebaut? Da würde ich ja Telegramme erwarten, die entweder eine GA als Ziel haben oder 1.0.6 als Ziel und nicht als Quelle.

Der TPUart sendet jedes TX Telegramm vom Stack kommend auch als Echo wieder zurück um zu signalisieren ob alles funktioniert hat, d.h. jedes TX Telegramm wird auch erstmal als normales RX Telegramm behandelt bis es als Echo erkannt wurde, erst wenn das passiert heißt das für den Stack das als nächstes die Confirm information für das Frame (welches ja eigentlich ein TX Frame war) folgt.

[mumpf]

Hi,

erstmal vielen Dank für Deine ausführliche Antwort. Dann muss ich mal weiter analysieren. Und bevor ihr euch den Kopf macht, muss ich gestehen, dass ich eine Sache nicht gemacht habe, die eigentlich offensichtlich ist: Mit dem Busmonitor nachschauen, was über den Bus geht (Ist mir leider jetzt erst eingefallen). Ich war irgendwie so im Coding und Testen drin, dass ich da nicht dran gedacht habe.

Ich untersuche das erstmal (bin aber nicht zu Hause, wir erst nächste Woche was) und melde mich dann. Wie gesagt, das restartDevice funktioniert bei mir unter Linux bereits, kann also nicht mehr viel sein, es auch auf dem SAMD hin zu bekommen.

Ich melde mich kommende Woche,
Danke für die Rückmeldung und Gruß, Waldemar

P.S.: Eine Frage habe ich doch noch... kann man denn irgendwo in Deiner Implementierung ein printHex setzen, um zu sehen, was wirklich auf den Bus gesendet wird? Das habe ich nirgendwo gefunden. Ich habe in TpUartDataLinkLayer::addFrameTxQueue eine Ausgabe rein gemacht, aber da wird nur der von Dir oben rot markierte Teil ausgegeben, die ersten beiden Bytes fehlen... Im Linux-Stack gab es eine von Thomas auskommentierte Stelle, die war leicht zu finden.

[Bernator]

TpUartDataLinkLayer::addFrameTxQueue ist richtig, die ersten beiden Bytes fehlen weil wie vorher beschrieben diese bei TP eben NICHT auf den Bus gesendet werden.

frame.fillTelegramTP(tx_frame->data);

schmeißt die ersten beiden Bytes raus, wenn du das gesamte cemi frame sehen willst musst du über "frame" loopen und nicht über "tx_frame", auf _data vom cemi frame kannst du aber nicht direkt zugreifen soweit ich weiß, du musst es wie im ip_data_link_layer in einen buffer kopieren und diesen buffer dann ausgeben:

memcpy(buffer + KNXIP_HEADER_LEN, frameData(frame), frame.totalLenght());

[mumpf]

Hi,

bei TP eben NICHT auf den Bus gesendet werden.

irgendwie fehlt mir noch was, damit es "click" macht... Ich habe mir die Kommunikation in der ETS angeschaut (leider nur im Gruppenmonitor, ich hole den Busmonitor noch nach ). Da kann man ja auch zu jedem Telegramm in Hex sehen, was alles übertragen wird. Bei einem Programmiervorgang werden ja vom SAMD haufenweise Antworten gesendet, und die fangen alle mit 0x2900 an. Und da das ein Protokoll vom SAMD an die ETS war, ging ich immer davon aus, dass die 0x2900 entsprechend mitgesendet wurde. Woher kommt das, wenn nicht vom SAMD? Wenn ich ein "resetDevice" mit der ETS mache, sehe ich auch eine bestimmte Telegrammabfolge im Gruppenmonitor, einige Frames fangen aber mit 0x2E00 an. Wenn ich "resetDevice" mit dem SAMD mache, sehe ich NICHTS im Gruppenmonitor, es gibt aber (TP-)Geräte, die auf dieses Reset reagieren und welche, die es nicht tun (ok, bisher nur jeweils 1 gefunden und nicht weiter gesucht).

Wie findet man jetzt raus, warum die ETS das nicht im Gruppenmonitor anzeigt? Du schreibst ja, dass bei TP diese Bytes nie gesendet werden, dann kann es an den ja nicht liegen. Das Telegramm ist aber ansonsten korrekt... Ist für mich noch nicht schlüssig.

Wie gesagt, ich schaue kommende Woche mal in den Busmonitor, vielleicht sehe ich da die Unterschiede und es kommt die große Erleuchtung. Danke euch erstmal.

Gruß, Waldemar

[mumpf]

Jetzt mal was Positives...

Ich habe vergangene Woche mal meine Logikmodul-Firmware erweitert, die Möglichkeit zur Sensorabfrage eingefügt und das Ganze auf das Sensormodul https://knx-user-forum.de/forum/proj...-sensoreinsatz von Masifi portiert (derzeit nur mit dem BME280). Das hat überraschend problemlos funktioniert und ergibt ein schönes und sehr kompaktes Gerät mit Sensorik, Logik und per ETS parametrierbar.

Da ich sowieso darüber nachdenke, meine 1-Wire Sensorik zu ersetzen, könnte ich auch dieses Modul in allen Räumen einsetzen und so meinem Traum näher kommen, in jedem Raum die passenden Logikfunktionen für eben diesen Raum zu realisieren. Dann hat man wieder den Vorteil der verteilten Logik (kein Zentralgerät).

Ich werde ab und zu berichten, wie es da weiter geht und was ich noch für Features bei dem Modul entdecke...

Gruß, Waldemar

[mumpf]

Hi,

vielleicht hat jemand einen Tipp für mich. Folgende Situation:

• Ich programmiere eine Applikation auf einen SAMD (normales devel board) mit der ETS, alles funktioniert prima
• Ich programmiere die selbe Applikation auf das neue Sensormodul (genau so ein SAMD-Board, aber eben von Masifi aufgebaut), es funktioniert immer noch alles genau so, nur ist das Modul nach dem Programmieren der Applikation im Programmier-Modul (so als ob ich den Prog-Button gedrückt hätte)

Irgendein Tipp, wo ich mal ne Debug-Ausgabe setzen sollte, um das näher einzukreisen? Nach dem Programmieren der Applikation passiert ja ein Restart, ich weiß nicht, ob das einem Reset gleich zu setzen ist, aber nach einem manuellen Reset über den Reset-Button landet das Modul nicht im Programmier-Modus.

Gruß, Waldemar

[mumpf]

OK, Antwort gefunden, irgendwas ist anders mit dem Pullup/Pulldown des Programmiertasters. Zumindest ist das der Unterschied zwischen den 2 Boards.

Gruß, Waldemar

[jeff25]

was baust du denn da genau?

[Masifi]

Welche Ehre das du meinen Berker Sensoreinsatz dazu verwendest :-) bei mir liegt er gerade etwas verstaubt in der Schublade.

Falls dir das hilft, so sieht meine Beschaltung des ProgButtons aus:
Unbenannt.png
D.h. es ist ein Pullup Widerstand der über den Taster auf LOW gezogen wird. Daher musst du mumpf den Interrupt auf eine fallende Flanke setzen.
R2 und C1 dienen zum Entprellen des Tasters damit man das nicht in SW machen muss. Man kann hier also direkt den µC-Pin auf einen Interrupt legen.
Da ich keine Ahnung habe wie ihr das hier im Code macht, hilft euch vielleicht diese Aussage/Übersicht. Da ihr das Entprellen wohl direkt in der SW macht, oder !? könnte es vielleicht sein, das es darin liegt.

Haltet mich mal auf dem Laufenden damit, bin gespannt was daraus wird.

[mumpf]

Hi,

eigentlich nichts besonderes, es wird ein Temperatur/Luftfeuchte/Luftdruck (und in Zukunft hoffentlich noch CO2)-Sensor mit einigen Logikkanälen (so an die 40-50, je nachdem wieviele noch in den Speicher passen). Mit dem Sensormodul von Masifi passt das Ganze in einen Berker-Sensoreinsatz und mit dem KNX-Stack von Thomas kann es über die ETS programmiert werden. Das finde ich derzeit spannend. Ich glaube, da sagen ein paar Bilder mehr als Worte. Derzeit sieht das so aus:

- Grundeinstellung für das Modul selbst
Sensormodul-Allgemein.PNG

Beispielhaft Parameter für einen Sensor: Sensormodul-Luftfeuchte.PNG

Logik, die einen Schwellwertschalter definiert... Sensormodul-LogikMain.PNG

... der Eingang wird dann mit dem Luftfeuchtesensor verbunden ...Sensormodul-LogikEingang.PNG

... und der Ausgang sendet dann als DPT1, ob es zu feucht ist oder nicht. Hier noch die Zusatzfunktion, dass "zu feucht" (also das EIN-Signal) zyklisch alle 5 Minuten gesendet wird, das AUS-Signal aber nicht. Sensormodul-LogikAusgang.PNG

Und dann noch die KO der obigen Definition, die dann natürlich entsprechend mit passenden GA verbunden werden müssen. Sensormodul-KO.PNG

Ist noch nicht perfekt, ein paar Texte und Formulierungen sind noch verbesserungswürdig, aber soweit läuft es schon und ich versuche jetzt alles abzurunden, weitere Sensoren anzuschließen und die Features von dem Sensormodul zu erkunden. Da kann steckt noch einiges drin, dass ich noch gar nicht ausprobiert habe.

Ich habe mir eben in den Kopf gesetzt, dass das alles per ETS programmierbar sein muss, bevor ich es bei mir im Haus produktiv verwende.

Gruß, Waldemar