ESP8266 KNX mit ETS

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

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

[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

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

[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 Es ist sicher sinnvoll die x.* Typen direkt zu unterstützen. Ich hab den Code ja auch nur von knxd geklaut. Kann gern geändert werden.
Ich habe man defines für die ganzen Dpt aus der knx-spec hinzugefügt. Die sind natürlich nicht alle implementiert. Die richtig hohe Schule wäre ja die Dpt aus der knx_master.xml zu parsen und den gesamten Code zur Konvertierung der Dpt daraus zu generieren. Aber wahrscheinlich muss man sich dann überlegen wie man verhindert, dass man den Konvertierungscode für nicht benutzte Dpt nicht mit kompiliert. Bestimmt nimmt die ganze Konvertierung eh schon viel zuviel Platz weg. Wenn da jemand eine Idee hat, her damit.

VG Thomas

[mumpf]

Hi Masifi,

Falls dir das hilft, so sieht meine Beschaltung des ProgButtons aus:

noch eine Verständnisfrage eines technisch interessierten:
Ich lese immer, dass der/die Arduinos an den PIO schon eingebaute Pullup-Wiederstände haben, man setzt ja auch den Pin auf INPUT_PULLUP. Ich hätte erwartet, dass da nur der Prog-Button dran hängt und den Eingang auf Masse zieht und alles ist gut. Eventuell noch ein Kondensator zum Entprellen dran... Oder ist der (externe) Pullup wegen dem Kondensator nötig? Wie Du siehst, ich habe keine Ahnung... Ich mach mal weiter mit Software, das kann ich besser...

Gruß, Waldemar

[mumpf]

Es ist sicher sinnvoll die x.* Typen direkt zu unterstützen.

Hi Thomas,

dummerweise sind das c++-Bereiche, an die ich mich (noch) nicht traue. Aber wer weiß, vor 2 Monaten hätte ich auch nicht gedacht, dass ich irgendwo im data_link_layer debugge. Und mir war nicht klar, dass das Coding portiert ist (hört sich besser an als "geklaut").

Und den 2. Absatz Deiner Aussage hab ich noch nicht mal verstanden, geschweige denn, dass ich da Ideen entwickeln könnte. Ich habe aber auch noch nie in die knx_master.xml rein geschaut...

Gruß, Waldemar

[Masifi]

ch hätte erwartet, dass da nur der Prog-Button dran hängt und den Eingang auf Masse zieht und alles ist gut. Eventuell noch ein Kondensator zum Entprellen dran... Oder ist der (externe) Pullup wegen dem Kondensator nötig?

Wenn du sowas machst, dann hast du kein Entprellfilter mehr, da zwischen dem Taster und dem Kondensator kein Widerstande sich mehr befindet. Der Taster schließt den Kondensator einfach kurz und daher ist dieser Wirkungslos.
In meinem Foto etwas weitern vorne im Thread ist das der Widerstand R2, dieser ist zwingend erforderlich zum Entprellen und damit sich der Kondensator nur "langsam" entladen kann.
Hier ist es eigentlich ganz gut beschrieben: https://www.mikrocontroller.net/articles/Entprellung

[Nanosonde]

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

thesing

Könntest Du einen Hinweis geben, was genau beim Python C++ Binding gemacht werden müsste, um Parameter zu unterstützen?
Wo würdest Du ansetzen?

[thesing]

Nanosonde Zuerst solltest du die Doku zu pybind11 lesen. Int-Parameters sollte man z.B. mit :

m.def("ParamInt", [](int addr)
{
   return bau->parameters().getInt(addr);
});

in knxmodule.cpp
als knx.ParamInt(addr) verfügbar machen können.

Es gab auch mal ein Beispiel (https://github.com/thelsing/knx/blob...Python/main.py) das aber nicht mehr ganz funktioniert. Aber im interaktiven Modus vom Python kannst du ja nach "import knx" schauen, welche Methoden das Modul bietet.

[mumpf]

Ich wede jetzt mal einen I2C EEPROM "24AA256" besorgen und damit testen. Dies sollte das Speicherplatzproblem eim SAMD deutlich entspannen

Hallo Sebastian,

hast Du da schon irgendwelche Erfahrungen gemacht? Ich habe soeben festgestellt, dass bei meinem neuen Spielzeug (Sensormodul) auch so ein EEPROM verbaut ist. Man könnte da dann zwar die ETS-Parameter speichern und muss so nicht nach jeder Firmware-Änderung das Gerät neu per ETS programmieren, aber dass es Speicher sparen würde, sehe ich (noch) nicht. Aber ich kann nicht behaupten, dass ich den Durchblick habe. Ich wollte erstmal das EEPROM zum speichern von Werten nutzen, die nicht beim Flashen gelöscht werden sollen, mal schauen, was noch möglich wird. Wenn Du neue Infos hast, würde es mich freuen.

Zu Deinem Speicherplatzproblem im allgemeinen: Du kannst übrigens massig Parameter-Speicher sparen, wenn Du die ETS-Möglichkeiten nutzt, die Parameter nur in der benötigten Bitbreite anzulegen und dann in den Parameter-Speicher zu übertragen. Hat bei mir pro Kanal von voher 230 Bytes (alles 4-Byte-Ints) auf 110 Bytes (teilweise 8 1-Bit-Parameter in einem Byte). Das kann aber CreateKnxProd nicht, da musst Du ins xml...

Und noch ein Tipp: Auch bei KO kann man Speicher sparen, wenn man so was hat, dass ein KO nur in einem Fall gilt, und ein anderes nur in einem anderen. Dann kann man die als "union" betrachten, beide nehmen nur den Speicher des größten ein. Ich habe z.B. 7 verschiedene KO für den Ausgang, alle haben die KO-Nummer 3, das längste KO ist 14 Bytes und alle zusammen sind auch nur 14 Bytes, weil nur eines davon aktiv ist.

Über einen Erfahrungsbericht mit externem Speicher würde ich mich freuen,
Waldemar

[Sisamiwe]

Über einen Erfahrungsbericht mit externem Speicher würde ich mich freuen,
Waldemar

Vielleicht kann Masifi hier beitragen. Ich glaube das im KONNEKTING 1w Gateway auch mit EEPROM gearbeitet wird

[mumpf]

Sisamiwe: Danke für den Tipp, aber es ist eben KONNEKTING, also ein anderes Framework. Mir ging es um Erfahrungen mit Thomas Framework und externem Speicher, speziell auch darum, ob man damit RAM sparen kann bzw. was man machen muss, damit die ETS-Daten nicht im Programm-Flash landen.

Gruß, Waldemar

[jeff25]

Hallo zusammen,

wenn ich das ganze unter Arduino IDE complilieren will muss ich dann eine bestimmte Version haben und was muss ich zusätzliches noch laden? Bei mir kommen seltsame Fehlermeldungen mit Version 1.8.9

Gruß
RObert

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:381: undefined reference to `bsec_update_subscription'

libraries\BSEC-Arduino-library-master\bsec.cpp.o.text._ZN4Bsec8getStateEPh+0x0): undefined reference to `bsec_get_state'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::getState(unsigned char*)':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:381: undefined reference to `bsec_get_state'

libraries\BSEC-Arduino-library-master\bsec.cpp.o.text._ZN4Bsec8setStateEPh+0x0): undefined reference to `bsec_set_state'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::setState(unsigned char*)':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:381: undefined reference to `bsec_set_state'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::Bsec()':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:69: undefined reference to `bsec_do_steps'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::readProcessData(long long, bsec_bme_settings_t)':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:293: undefined reference to `bsec_do_steps'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::getTimeMs()':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:424: undefined reference to `bsec_sensor_control'

libraries\BSEC-Arduino-library-master\bsec.cpp.o: In function `Bsec::run()':

C:\Users\r\Documents\Arduino\libraries\BSEC-Arduino-library-master\src/bsec.cpp:164: undefined reference to `bsec_sensor_control'

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Generic ESP8266 Module.