ESP8266 KNX mit ETS

[henfri]

Hallo,

ich habe es jetzt mit knx-demo versucht.

Die PA kann ich programmieren.
Die Applikation nicht. Es endet mit "inkompatible BCU-Version 57B0, benötigt 07B0".

Anbei die Logs.

Zur i2c Adresse:

Die setze ich so:

#define i2cAdress  0x77
    iaqSensor.begin(i2cAdress, Wire);
    //iaqSensor.begin(BME680_I2C_ADDR_SECONDARY, Wire);
    checkIaqSensorStatus();

Ich habe auch in Erinnerung, dass eine fehlerhafte Konfiguration des BME die KNX-Kommunikation verhinderte. Ich habe auch tatsächlich irgendwann ein Update vom Github gezogen. Dabei kann ich meine Anpassungen verloren haben.

Betreffen kann das ja die I2C Adresse und die Konfiguration der I2C Pins...
Wie kann ich denn erkennen, ob die Kommunikation mit dem BME das Problem ist?

Aber wir können ja auch erstmal mit dem example weiter machen..

Gruß,
Hendrik

[thesing]

henfri
Ob die die Kommunikation mit den BME ein Problem ist kann man schlecht direkt sehen. Es ist aber wirklich besser erstmal mit dem Demo weiter zu machen.
Bei aktuellen Problem hast du wahrscheinlich die falsche knxprod importiert. Du must die knx-demo-ip.knxprod nehmen.

mumpf :
Die Daten werden alle erst in den RAM geladen dann dort verarbeitet.

 bau.readMemory();

macht genau das. Geschrieben wird implizit vor einem Neustart oder durch

 bau.writeMemory();

Man kann auch weitere Objekte registrieren deren Zustand vom Flash gelesen/geschrieben werden soll mit

void addSaveRestore(SaveRestore* obj);

. Das habe ich z.B. auch beim BME680-Beispiel gemacht: https://github.com/thelsing/knx/blob...bme680.ino#L75 (über den Umweg der KnxFacade)

[henfri]

Hallo,

ja, du hast recht.... Kaum macht man es richtig, schon funktioniert es.
Allerdings ist die Programmierung auch damit zweimal fehlgeschlagen (siehe Anhang), ist dann aber auch geglückt.

Nun da das funktioniert hat, ist natürlich die Frage, warum der BME-Sketch nicht funktioniert.
Magst du einen Blick auf meine Variante werfen?

Es kann ja eigentlich nur an den Pins und an der i2c Adresse liegen.
IMG_20190531_174438.jpg
Gruß,
Hendrik

[henfri]

Hallo,

noch eine Frage zum BME:
Ich möchte als nächstes meine Lüftung mit deiner Bibliothek steuern. Dabei soll ein PWM Ausgang und zwei BME zum Einsatz kommen. Die Hardware ist schon eine Weile fertig. Ich möchte aber verhindern, dass Probleme mit der Kommunikation mit dem BME die PWM Funktion behindern. Aktuell ist es ja scheinbar so, dass die Probleme mit dem BME die KNX-Kommunikation behindern, richtig?

Gruß,
Hendrik

[thesing]

Das Log sieht eigentlich ganz gut aus. Es gehen bei dir nach wie vor Pakete verloren, es wird aber richtig darauf reagiert. Evtl. funktioniert das besser, wenn ich mal die Programmierung direkt über IP (nicht über IP-Routing) implementiert habe. Ich kann gerade nicht prüfen, welche Pins ich nehme, da meine Frau schon schläft und das Breadboard im Schlafzimmer steht. Ich mach morgen mal ein Foto.
Im BME-Beispiel wird der Sketch bei einem Fehler angehalten:

 [TABLE]
 	 		[TR]
 			[TD]for (;;)[/TD]
 		[/TR]
 		[TR]
 			[TD] [/TD]
 			[TD]errLeds(); /* Halt in case of failure */[/TD]
 		[/TR]
 	 [/TABLE]

Solche Abschnitte gibt es ein paar. Die kannst du natürlich raus nehmen. Das wäre in unserem Falls sicher auch besser. Wenn du das Bme-Beispiel so angepasst hast, dass es sich auch ohne Sensor programmierten lässt, freue ich mich auf einen Pull-Request. Evtl. gibt es auch schon wieder eine neue Version der Bsec-Lib.

Die ganzen Sketche müssten auch mal auf die neue value()-Api angepasst werden. Wenn jemand Lust hat würde ich mich auch über einen Pull-Request freuen. Dann könnte ich die alte Api ( objectWrite(...) ) entfernen.

Ich habe übrigens inzwischen den Neustart für Linux eingebaut.

[henfri]

Hallo,

danke für deine Antwort.
Ich kann einen kleinen Erfolg vermelden:
Ich habe die Zeile

    iaqSensor.begin(i2cAdress, Wire);

(und oben war ein #define i2cAdress 0x77) in ein

    iaqSensor.begin(0x77, Wire);

geändert.

Damit habe ich jetzt auf Anhieb (d.h. ohne Programmierung durch die ETS) wieder die Werte des BME gesehen.

Ich habe dann nochmal programmiert und den ESP dabei zurückgesetzt. Das Programmieren der PA hat danach funktioniert. Das Programmieren der Applikation nur teilweise. Siehe Anhang. Der Fehler: "Adress is not valid 4294967221".

Wie kann ich denn meine Paketverluste diagnostizieren?

Zum update auf die neue Api: Das sehe ich mir gerne an -sobald ich etwas Selbstvertrauen gewonnen habe...

Gruß,
Hendrik

[mumpf]

Dann könnte ich die alte Api ( objectWrite(...) ) entfernen.

Hi Thomas,

bevor Du das entfernst - könntest Du noch etwas warten (ich meine etwa 1 Monat)? Ich kann ja leider erst weitermachen, wenn ich wieder zu Hause bin und fände es besser, wenn ich einen Pull vom aktuellen Stack machen könnte ohne dass alles, was bisher ging, nicht mehr läuft. Ich würde gerne die beiden Varianten nebeneinander ausprobieren, um ein Gefühl zu bekommen, welche wirklich besser geeignet ist für KO, die verschiedene DPT haben können. Zuerst hatte ich gedacht, dass Dein bisheriges API eher Low-Level ist, das neue dann eben High-Level und dass Du beide koexistieren lassen willst. Dass es nicht so ist, ist auch OK für mich, ich wäre nur für eine Übergangsphase und eine Vorwarnung dankbar...

Gruß, Waldemar

[mumpf]

Hi Thomas,

weil es mir gerade einfällt und ich es noch eine Weile nicht ausprobieren kann, frage ich einfach mal: Unterstützt Dein Stack auch erweiterte Gruppenadressen? Sprich: Die Hauptgruppen 16 bis 31?

Gruß, Waldemar

[thesing]

henfri Ich bin kein Wlan-Spezialist. Vielleicht kannst du den Kanal wechseln? Ich würde an deiner Stell nichts weiter machen und damit Leben, dass man mehrmals probieren muss. Vielleicht wird es mir dem direct-IP-Zeug besser. Oder möglicherweise implementiere ich mal das "zuverlässige Verbindung"-Zeug von Gira. Aber das würde auch nur mit einem Gira-Router funktionieren. Oder man bringt das knxd bei oder schreibe einen eigenen Router mit meinem Stack.

mumpf Ich habe das leider schon versehentlich rausgeworfen. Wenn du es unbedingt brauchst, könnte ich die alten Methoden noch mal hinzufügt und die neue Api im Hintergrund benutzen lassen. Die ganzen GA-Schemas sind eine reine ETS-Sache. Auf dem Bus und für die Geräte ist eine GA einfach nur eine 16-Bit-Zahl. Wie man die in einen String wandelt weiß bei freien Gruppenadressen eben nur noch die ETS. Aber das reicht ja eigentlich auch.

[mumpf]

Hi,

Ich habe das leider schon versehentlich rausgeworfen.

Meinst Du hier das alte objectWrite-API? Dann ist das eben so, dann stelle ich eben sofort um (sobald ich zu Hause bin). Ich dachte nur, ich könnte einen "sanfteren" Übergang haben. Ist aber kein Ding. Ich habe hier ja nur einen Prototypen laufen, Du brauchst keine Schritte zurück zu machen. Trotzdem danke für das Angebot.

Die ganzen GA-Schemas sind eine reine ETS-Sache. Auf dem Bus und für die Geräte ist eine GA einfach nur eine 16-Bit-Zahl.

Meine Frage bezog sich nicht auf irgendein GA-Schema. Mir ist klar, dass aus den 16 Bit dann das GA-Schema für die Anzeige abgeleitet wird. Mir geht es um das MSB. Es gibt Geräte, die das höchste Bit maskieren und alle GA ignorieren, die dieses Bit gesetzt haben (z.B. Geräte von Lingg & Janke). In der ETS äußert sich das dann so, dass man nur die Haupgruppen 0-15 benutzen kann, 16-31 werden vom Gerät ignoriert. Ich wollte wissen, ob in Deinem Stack alle 16 Bit für die GA zur Verfügung stehen, aus Deiner Antwort schließe ich, dass es so ist...

Gruß, Waldemar

[thesing]

Das mit dem höchsten Bit kannte ich nicht. Laut https://knx-user-forum.de/forum/öffe...564#post608564 sollten Geräte das i.d.R. können. Bei mir werden jedenfalls die vollen 16 Bit der GA genutzt.

[mumpf]

Super, dass wollte ich hören.

Habe im Februar ein neues produkt von lingg & janke erworben (2019 neu rausgekommen) und war tierisch enttäuscht, als ich feststellen musste, dass die immer noch nur 15 bit für GA nutzen.

Gruß Waldemar

[mumpf]

So, wollte mal wieder einen Zwischenstand bringen:

Habe jetzt ein kleines Programm geschrieben, dass mir das xml für einen Kanal beliebig vervielfacht. Mit 80 Kanälen wird das ein xml mit fast 90.000 Zeilen, aber sowohl Dein CreateKnxProd wie auch die ETS schlucken das ohne Probleme. Der Parameterblock hat dann 8804 Byte und ich nutze 240 KO. Sobald ich wieder aus dem Krankenhaus raus bin, muss ich dann nur noch alle Prameterkombinationen implementieren und dann testen, testen, testen.

Wie lange dauert eigentlich das Programmieren von 8k mit der ETS?

Ich bin echt froh, dass ich das durchgezogen habe, man lernt echt viel über die ETS und den Aufbau der Parameter-Seiten. Wofür so ein langer Krankenhaus-Aufenthalt nicht alles gut ist.

Mal schauen, wie weit ich nach Pfingsten komme.

Gruß, Waldemar

[henfri]

thesing Ok, dann konzentrieren wir uns mal auf den BME, wo der Demo-Sketch einigermaßen geht.

Ich habe jetzt einmal frisch vom Github gestartet.
Es scheint aber, als hättest du die BSEC Lib aktualisiert. ( .Iaq statt .IaqEstimate).
Kannst du mir sagen, welche Version/Woher du die Lib genommen hast? Das war letztes Mal solch ein Chaos, dass ich mir eigentlich geschworen habe, die nicht mehr anzurühren.
Ich glaube, die Quintessenz war, alles von der Bosch-Seite und nix vom Bosch-Github zu nehmen...


Gruß,
Hendrik

[thesing]

mumpf Es hängt davon ab, welche Telegrammgröße verwendet werden kann. Mein Stack kommt mit der Maximalgröße klar. Je nachde was die Router oder Koppler dazwische können, könnte die Zeit also erträglich sein.

henfri Ich habe diesmal alles vom github repository vom Bosch genommen. Die haben inzwischen auch die Binärdateien eingecheckt. Du brauchst also nur das Repository klonen und die Linker-Skripte ändern wie in der Readme beschrieben. Ich habe die Lib aber noch nicht getestet.