ESP8266 KNX mit ETS

[henfri]

Hallo,

danke für deine Antwort.

Ich glaube, es ist anders rum: Es gibt noch die Methode

Dann glauben wir aber -denke ich- das Gleiche.

Sobald -durch ETS oder durch "go.dataPointType(DPT(9,1))" - bekannt ist, welchen DPT go hat, muss nur noch value() genutzt werden.

Klar, noch schöner wäre es, wenn man nur an einer Stelle (ETS) den DPT setzen müsste, aber ich denke, dass der Arduino Compiler die Größe der Objekte zum Zeitpunkt des Kompilieren wissen muss, oder?


Gruß,
Hendrik

[mumpf]

Hi Thomas,

noch ein kurzes Feedback zu

Ich habe das leider schon versehentlich rausgeworfen.

Ich habe mein Coding jetzt angepasst, auf den ersten Blick sieht alles gut aus. Bin zwar noch im Krankenhaus, kann also nicht testen, aber ich hab mir mal ne Linux-VM aufgesetzt und das Ganze erstmal syntaktisch korrekt hinbekommen.

Bei der Gelegenheit: Ich arbeite inzwischen mit VS Code und hab es für Linux hin bekommen, damit zu bauen und zu debuggen. An den Arduino-Teil hab ich mich noch nicht getraut. Wären die Config-Files für VS Code irgendwie interessant für Dich? Oder erst, wenn ich es auch für den SAMD hinbekommen habe?

Gruß, Waldemar

[mumpf]

Hi Hendrik,

ich hab mir jetzt auch mal die Neuerungen von Thomas angesehen.

Das bedeutet, dass value() selbst erkennt, welcher DPT nötig ist?

Ich glaube, es ist anders rum: Es gibt noch die Methode

go.dataPointType(DPT(9,1))

Mit der setzt Du den DPT für das GroupObject, dann kann ein

go.value(125)

richtig konvertieren. So verstehe ich zumindest die neuen DPT.

thesing: Muss man immer einen DPT setzen oder bekommst Du den von der ETS mit? Eigentlich definiert man die DPT ja schon in dem knxprod file. Ob das beim Programmieren übertragen wird, weiß ich natürlich nicht.

Gruß, Waldemar

[henfri]

Hallo,

zusätzlich zu meinem vorherigen Beitrag noch eine andere Frage:
Ich versuche gerade das Sonoff Beispiel auf einen PWM Ausgang umzustellen (natürlich mit anderer Hardware).
Ist das Beispiel aktuell? Ich finde z.B. GroupObject.objectReadBool() weder im aktuellen code, noch in https://knx.readthedocs.io/en/latest/
Ist es jetzt go.value().boolValue()?

Damit ich nicht immer so doof fragen muss: Wie/wo kann ich das erlesen?
Ich finde zwar dies
https://knx.readthedocs.io/en/latest...80caf05dcf9ba7
Aber da ist nicht dokumentiert, wie ich die Funktion nutze.
Wenn ich mir das ansehe:
https://github.com/thelsing/knx/comm...63ec454ed73370
Wurde

goMin.objectWriteFloatDpt9(minValue);

zu

goMin.value(minValue);

Das bedeutet, dass value() selbst erkennt, welcher DPT nötig ist?

Hast du die Sonoff S20 eigentlich zuverlässig bei dir im Einsatz?

Gruß,
Hendrik

[henfri]

Hallo,

das Update/das Installieren der BSEC Lib ist ja jetzt echt einfach.
Den Demo Sketch hatte ich in null komma nix am laufen (musste nur die I2C Adresse anpassen). Mit deinem Demo läuft es aber nicht.
Ich denke, ich habe zwei mögliche Probleme identifiziert:
1) das bsec_config_iaq[454] und iaqSensor.setConfig(bsec_config_iaq) ist zumindest im Demo nicht mehr nötig.
2) Ich glaube du hast das Wire.begin() versehentlich entfernt. Danach bekomme ich zumindest keinen error -2 mehr

Aber programmieren klappt nicht -aber das ist ja nix neues.
Aber ich wollte das wenigstens mit dir teilen, damit du die Erkenntnis schonmal hast.

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.

[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

[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

[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

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

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]

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

[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

[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