ESP8266 KNX mit ETS

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

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

[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

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

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

[mumpf]

Ja es sollte nur an ein ReadRequest zur ersten GA geschickt werden. Ausprobiert habe ich das wahrscheinlich nie.

Kein Ding, das werde ich dann testen...

Ansonsten geht das ja ab hier... und ich kann damit nicht "rumspielen"... Aber nach Pfingsten (dann komm ich raus aus dem Krankenhaus) geht es dann los!

Danke schon mal.

Noch mal ne Frage, die oben untergegangen ist: Wenn ich zur Laufzeit mit   bau.parameters().getXXX()   parameter lese, kommen die dann aus dem Flash oder RAM? Ich hab noch keine praktische Erfahrung mit Mikrocontroller-Programmierung, hatte aber irgendwo gelesen, dass Lesen aus dem Flash schlecht fürs Timing (also langsam) ist und man sich vorher alle benötigten Daten auf einmal ins RAM kopieren sollte. Ich ging bisher davon aus, dass   bau.readMemory();   genau das macht, wollte mich nur vergewissern. sonst würde ich meine Programmstruktur etwas anders aufbauen...

Gruß, Waldemar

[thesing]

Ja es sollte nur an ein ReadRequest zur ersten GA geschickt werden. Ausprobiert habe ich das wahrscheinlich nie.

Ich habe nun bei der neuen KO-Wert-Api Dpt1 und Dpt9 getestet und ins Linux-Beispiel (https://github.com/thelsing/knx/blob...linux/main.cpp) eingebaut.

Im wesentlichen gibt es am GroupObject jetzt folgende neue Methoden:

Man kann nun mit

    Dpt dataPointType();
    void dataPointType(Dpt value);

den Datenpunkttyp festlegen oder abfragen.

Wenn man einen festgelegt hat man mit

    void valueNoSend(const KNXValue& value);
    KNXValue value();
    void value(const KNXValue& value);
    bool tryValue(KNXValue& value);

Den Wert abfragen oder setzen. dabei schreibt die *NoSend Variante den Wert zwar in das Gruppenobjekt, sendet ihn aber nicht auf den Bus. Die try* Variante sagt einem ob die Zuweisung geklappt hat. (Wenn bei Dpt 9.1 (Temperatur °C) z.B. ein Wert < -273 zugewiesen wird erhält mal false. Der Wert des GroupObjects wird nicht verändert)

Man kann auch den Datenpunkttyp bei anderen Varianten direkt angeben:

    KNXValue value(const Dpt& type);
    void value(const KNXValue& value, const Dpt& type);
    void valueNoSend(const KNXValue& value, const Dpt& type);
    bool tryValue(KNXValue& value, const Dpt& type);

Die KNXValue Klasse ist eine Art Union und kann je nach Kontext verschiedene Typen präsentieren:

KNXValue foo = 4; // (int) 4 reinschreiben
int i = foo;  // i hat nun den Wert 4
foo = 2.0; // foo hat nun den Wert (double) 2.0
double d = foo; // d hat nun den Wert 2.0
i = foo;  // FEHLER: i hat nun eine "zufälligen" Wert
i = foo.doubleValue(); // i hat nun den Wert (int) 2

Der Vorteil ist dass man nun sowas schreiben kann wie

temp.value(24.3)

und

double wert = temp.value()

. Dafür muss man aber auch immer an eine Variable vom richtigen Typ zuweisen. Ein Gruppenobjekt von Datenpunkttyp 9 liefert eben double-Werte. Wenn man die an ein int zuweist erhält man Müll. Im Zweifel kann man auch

temp.value().doubleValue()

schreiben um explizit den double-Wert aus dem Objekt zu kriegen.
Ich bin mir nicht sicher ob das so gut ist. Wie seht ihr das? Wahrscheinlich ist das eh nicht verständlich genug geschrieben.

Die KNXValue-Klasse befindet sich übrigens hier: https://github.com/thelsing/knx/blob...tconvert.h#L58 falls jemand genau drauf schauen möchte.

Der Code für sämtliche Konvertierung der Datenpunkttype ist in https://github.com/thelsing/knx/blob...dptconvert.cpp zu finden.

So das reicht erstmal für heute

[mumpf]

Ah, das stimmt. Hmm, ich werde mal einfach beides bestellen und dann testen, wie ich mit dem Speicher klar komme. 2 SAMD Module a 40-50 Kanäle würden ja auch gehen.

Ich konzentriere mich erstmal auf die Funktionalität.

@Thomas: Danke für die korrektur mit den flags. Das mit dem ReadRequest ist ja unkritisch. Testen kann ich allerdings erst, wenn Ich zu Hause bin... Wird ein Read Request eigentlich nur an die erste GA eines KO oder an alle geschickt? Da weiß ich noch nicht mal, wie s sein sollte... Erwarten würde ich aber nur die erste, sonst bekommt man wieder mehrere unterschiedliche Antworten und muss damit klar kommen.

Gruß Waldemar

[henfri]

Der ESP32 geht dann aber nur noch mit externer Stromversorgung, vermute ich...

[mumpf]

Hi,

Wer mag kann ja schon mal testen.

Das mache ich gerne, zumindest für DPT 1,2,5,5.001,6,7,8,9,16,17,232 - das sind die, die ich unterstützen will.

Allerdings "darf" ich noch bis zum 7.6. (oder gar den Montag drauf) im Krankenhaus bleiben, dauert also noch etwas... Gut Ding will Weile haben.

Dann also ESP32... Verstehe ich das richtig? Du willst sowieso noch coding spendieren, damit der ESP32 über microBCU mit KNX kommunizieren kann. Das könnte ich dann nutzen. Hört sich gut an. Bei 512k könnte ich noch ein paar Kanäle mehr machen... Bis die ETS platzt...

Danke für die Genesungswünsche... Hoffe, du hattest einen schönen Urlaub.

Gruß Waldemar

[thesing]

Ich habe mal Code für die Datenpunktkonvertierung von knxd zum GroupObject hinzugefügt. Der ist ungetestet und noch nicht C++isiert. Damit sollte man dann Werte von/zu den meisten Datenpunkten konvertieren können. Wer mag kann ja schon mal testen.

[thesing]

henfri Ich glaube dein BME hatte eine andere I2C-Adresse. Kannst du erst mal probieren ob es mit dem knx-demo geht?

mumpf Erwischt. Das hatte gefehlt. Die Flags sollten eigentlich gemäß https://support.knx.org/hc/de/articl...03188089-Flags funktionieren. Also fast so wie du geschrieben hast. Nur kann man auch ohne Ü-Flag ReadRequests absetzen. (Jetzt auch bei mir Den Speicherbedarf habe ich nicht konkret analysiert. Da müsste man mal ausgehend von der KnxFacade die Größe der Klassen analysieren. Dazu gibt es bestimmt Tools. Dazu kommen (Anzahl zugewiesender GA + 1)*2 (Anzahl GA/KO Kombinationen + 1) + ca. 20 Byte pro KO. Alles nur geschätzt. Das kommt auch ziemlich darauf ob der Code für 64 Bit oder 32 Bit ist. Das sollte aber letztlich egal sein. Zur not kannst du auch einen ESP32 nehmen. Der hat dann 512KB RAM. Ich habe den Code dafür zwar noch nicht geschrieben, aber schon so ein Board hier.

P.S.: Auch von mir gute Besserung. Wenn du zu Hause einen PC hast kannst du doch jetzt prima Zeit zum programmieren.

[mumpf]

Danke euch allen, aber ich wollte den thread nicht kapern, ist ziemlich OT...

Gruß Waldemar

[Mag Gyver]

Du machst Sachen,

auch von mir gute Besserung.


Gruß René

[mumpf]

Danke, Frank!

wusste gar nicht, dass Du hier mit liest...

Gruß, Waldemar