ESP8266 KNX mit ETS

[mumpf]

Hallo Robert,

Da hast du was ganz tolles hinbekommen.

Vielen Dank für die Blumen. Wie ich schon geschrieben habe, es ist noch nicht fertig, aber ich komme voran.

jeff25 ; thesing : Die xml hat bestimmt >200 Revisionen hinter sich (und ich bin immer noch nicht zufrieden). Es begann normal mit CreateKnxProd, dadurch war der Rahmen gegeben, der einen Import in die ETS erlaubt hat. Dann habe ich mit CreateKnxProd ein paar Sachen verändert und ergänzt und mir die Diffs angeschaut. Dann wurde ziemlich schnell klar, wie die Sachen zusammen hängen. Und dann habe ich angefangen, mir andere knxprod anzuschauen und so gelernt, was man noch machen kann. Dann hab ich mir ein Tool geschrieben (übrigens auch in C#), dass mir meine Kanalanzahl generiert (sind ja immer gleiche Teile) und den Rest hab ich per Hand geschrieben. Dann musste das Tool auch noch ein paar Sanity-Checks machen (Id-Eindeutigkeit, RefId müssen auf existierende Id zeigen, ParamRefId auf existierende ParamRefRef usw.). Inzwischen macht es auch den CreateKnxProd-Export und generiert ein Header-File mit allen KO- und Parameter-defines.

Nachteil: Es ist überhaupt nicht generisch, sondern sehr an meine Anwendung angepasst, deswegen kann ich es auch nicht sinnvoll Teilen... Aber für die ca. 67.000 Zeilen XML, die ein Sensormodul mit 50 Logikkanälen braucht, habe ich nur 2000 Zeilen XML händisch geschrieben. Rest wird generiert.

Ich hatte ursprünglich angenommen, dass ich bei CreateKnxProd mehr Pull-Request bekomme als für die knx-lib

Das ist einfach erklärt, denke ich: Ein UI zu schreiben, dass auch halbwegs die komplexen Editiermöglichkeiten der ETS abdeckt, die im knxprod drin stecken, ist eine Höllenarbeit. Im xml zu editieren hingegen ist einfach. Und wenn man so vorgeht wie ich, dann nutzt man CreateKnxProd letztendlich nur noch für den knxprod-Export. Deswegen gibt es da keine pull-Requests. Und um die Firmware, also Deine knx-lib, kommt man nicht herum und die ist es Wert, verbessert bzw. erweitert zu werden.

Ich habe übrigens das BME680 Beispiel gefixt. Die Lösung ist einfach: Es gibt keine Dpt *.0. Wenn man ganz normal den Dpt 9.1 nutzt geht alles.

Das ist schon mal SUPER , dann hab ich was zum abgucken, ich will eigentlich auch mit dem Sensormodul vom Masifi auf den BME680 gehen... zumindest wollte ich mal gucken, ob die Anbindung schwer ist.
Und zu DPT *.0: Ich fände es gar nicht schlecht, wenn es die gäbe, also z.B. DPT 9.0 (in der ETS als DPT 9.*) als 2-byte-float ohne weitere checks und Semantik. Manchmal hat man Werte zum Ausgeben, die wirklich nicht in irgendeinen existierenden DPT passen. Oder ich hatte mal DPT 9.001 genommen und mich gewundert, warum -1000 nicht empfangen bzw. gesendet wurde und später im Coding gesehen, dass Du auf den absoluten Nullpunkt prüfst. Hut ab - gehört zur Vollständigkeit der Semantik vom "Temperatur", aber ich wollte einfach nur einen Float transportieren. Ging dann eben mit 9.002...

Und um zu "belegen", dass es auch "offiziell" in der ETS geht: Ich kann einem KO ein DatapointType="DPST-9-1" geben, aber auch ein DatapointType="DPT-9", der hat keinen Subtype, wird aber normal akzeptiert.

Gruß, Waldemar

[thesing]

mumpf
Sieht sehr gut aus. Hast du die xml per Hand geschrieben?
Ich hatte ursprünglich angenommen, dass ich bei CreateKnxProd mehr Pull-Request bekomme als für die knx-lib, aber scheinbar entwickeln alle lieber C++

Ich habe übrigens das BME680 Beispiel gefixt. Die Lösung ist einfach: Es gibt keine Dpt *.0. Wenn man ganz normal den Dpt 9.1 nutzt geht alles.

[jeff25]

Hallo Waldemar,

danke für diese ausführliche Zusammenfassung. Das ist mehr als ich mir vorstellen konnte. Da hast du was ganz tolles hinbekommen. Da flammt mein Elektroniker Herz gleich richtig auf. Die KNXPROD FIles hast du per Hand erstellt? Das Tool kann das ja nicht so mit den vielen Unterteilungen und Formatierungen usw...

Gruß
RObert

[mumpf]

Welche Ehre das du meinen Berker Sensoreinsatz dazu verwendest :-)

Was soll ich sagen? Es hat genau das, was ich mir erträumt habe: Klein, passt in den Berker-Sensoreinsatz, ist direkt an KNX anschließbar und läuft auf der Plattform, die direkt von Thomas Framework unterstützt wird. Außerdem bietet es mir neben meiner Hauptanwendung (Logik) auch noch ein paar Sensoren. Das passt perfekt - ich muss nur noch eine Debug-Lösung dafür finden. Aber PlatformIO wartet schon...

Gruß, Waldemar

[mumpf]

@Masifi: Danke für Deine Info, genau daran hat es gelegen. Ich hatte bei meiner Testschaltung einen Pulldown zur Masse und den Taster mit Plus verbunden. Und auch noch ein C zum entprellen. Im Code wird auch auf ein "RAISING" reagiert und deswegen das Verhalten. Ich habe den Interrupt mal testweise auf FALLING gesetzt und schon klappt es (ok, es war bisher nur ein kurzer und rudimentärer Test).

@Thomas: Ich werde noch in der knx_facade.h ein    void knx.ledPinActiveOn(uint32_t value);   einfügen, damit man das passend im setup() konfigurieren kann. Kommt dann mit dem nächsten Push-Request (ich muss noch üben, ob das mit nem branch problemlos klappt, bevor ich das Ganze "restartDevice"-Zeug pushe)... .

Gruß, Waldemar

[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

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

[jeff25]

was baust du denn da genau?

[mumpf]

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

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]

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,

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

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

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]

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.