ESP8266 über WLAN an KNX

[woda]

Hab grad auch im Sekundentakt für 3 Minuten geschalten. Kein Telegrammverlust (incl. Status).
(Sonoff Basic, Enertex KNX Router, ESP Lib 2.3)
Bei 2x schalten pro Sekunde geht ca. 1 Telegramm von 15 verloren.

Solange ich also nicht schneller als 1x pro Sekunde schalte geht kein Telegramm verloren.

Für mich ist das aktuell ausreichend und auch zuverlässiger und günstiger als die alten Hager KNX-RF Teile die ich ebenfalls seit Jahren im Einsatz habe.
Ich bin auch sicher, dass die Zuverlässigkeit mit der laufenden Weiterentwicklung der Lib noch besser wird.

[OleDeluxe]

Mich hat's nun wohl auch getroffen. Im Carport der Wemos D1 reagiert nicht mehr korrekt. Ich kann sehen, dass die Befehle, die er auf den Bus sendet immer kommen (da wird der BWM ausgewertet), aber dann die Schaltbefehle die an ihn gesendet werden nicht mehr zuverlässig umgesetzt werden. Das ganze kam schlagartig. Wenn ich in 2 Wochen wieder zu Hause bin stecke ich mal neue Hardware rein um hier einen Defekt auszuschließen.
Auch der Watchdog sendet immer fleißig, was ja darauf passt, dass es evtl. mit kurz aufeinander folgenden Befehlen nur nicht klappt.

Mal schauen wie die Entwicklung da nun weiter geht. Ob es am Multicast liegt? Wenn es mit Tunnel läuft, wäre ein KNXD für die ESP ja vertretbar, der sollte genug Tunnel aufmachen können.

Gruß, Sven

[SirUli]

Ich weiss ja nicht was ihr für WLANs habt, aber generell sind heimnetzwerke was relativ zuverlässiges. Ich würde auch mal in der Ecke "Telegram verpasst" suchen, also dass beispielsweise zuviel prozessiert wurde, bis wieder auf dem Bus gelauscht (=Netzwerkinterface abgefragt) wurde. Damit man das ein bisschen umgeht, muss ab und an ein "yield()" oder "delay()" zwischenrein im loop(). Oder halt gleich voll auf https://github.com/Makuna/Task aufbauen - aber das ist etwas komplexer.

[Tulkas]

Wie schon gesagt, ich gehe nicht davon aus, dass es ein Problem im (W)LAN ist. Bei mir kam jedes Status-Telegramm vom ESP an, umgekehrt hat dieser jedoch nur auf einen kleinen Teil der Schaltbefehle reagiert, die ich manuell über die ETS abgeschickt habe (mit einem Abstand von deutlich über einer Sekunde). Der Fehler könnte überall liegen, aber insbesondere das lokale Netzwerk halte ich für am unwahrscheinlichsten. Weder Bus noch WLAN waren zum Testzeitpunkt auch nur ansatzweise ausgelastet.

[uncletom]

Ich stelle heute Abend die Tunnelinglösung über Github zur Verfügung. Sollte sich auch für ESP8266 übersetzen lassen. Dann sind Eure Probleme hoffentlich Geschichte.
Zur Arbeitsweise: Es gibt zwei Queues im Rahmen von FREERTOS. Eine enthält empfangene Pakete, in die andere werden zu Sendende eingekippt. Hier habe ich noch nicht alle Datentypen fertig, aber es geht ja erstmal um den Basisrahmen. Die Lösung kann auf einen bekannten eibd connecten oder automatisch suchen. Ich habe nur einen eibd in meinem Netz, deshalb weiß ich nicht, ob die Automatik bei mehrere entdeckten Interfaces gut arbeitet. Wäre toll, wenn da jemand Feedback geben könnte.

Was noch fehlt, ist eine Behandlung, falls die Kommunikation zum eibd abbricht. Hab ich zwar noch nicht beobachtet, aber da möchte ich noch eine Lösung bauen, die ein Re-Connect übernimmt.


Gruß,
Lars

[SirUli]

umgekehrt hat dieser jedoch nur auf einen kleinen Teil der Schaltbefehle reagiert, die ich manuell über die ETS abgeschickt habe

Das hört sich für mich danach an, als wenn der nicht genug lauschen kann. Ich würde mal ein paar yield() quer über den Code verteilen (insbesondere vor resourcen-intensiven Berechnungen oder Anweisungen) und schauen ob sich die Situation bessert. Weiter vorne im Thread war auch mal ein "delay(50)" eine Lösung - das führt zu etwas ähnlichem aber eben auch zu einer Pause (logisch).

[uncletom]

Gerne ausprobieren:
https://github.com/loddeknx/esp32knx

Gruß,
Lars

[Tulkas]

Danke Lars für Deine Implementierung! Ich muss leider gestehen, dass ich es nicht ausprobiert habe, da ich in der Zwischenzeit bereits angefangen hatte, eine eigene Lösung zu basteln. Und da es recht viel Spaß gemacht hat, habe ich es dann auch (soweit das eben bei Software überhaupt geht) fertiggestellt. Ich kommuniziere mit dem eibd auf dem Wiregate über dessen TCP/IP-Socket, die Lösung ist also nicht so generisch wie KNX-Routing oder -Tunneling, da es natürlich einen eibd oder knxd (nicht getestet) benötigt. Aber für genau meinen Anwendungsfall läuft es gut. Entwickelt habe ich mit der Arduino IDE 1.8.5 und der ESP8266-Bibliothek 2.4.1.

Direkt im Code definiert man sowohl SSID und Passwort für den WLAN-Zugang sowie drei Gruppenadressen für Schalten, Sperren und den Status. Bei der Sperre kann man noch einstellen, ob bei der (De-)Aktivierung die Steckdose geschaltet werden soll oder nicht. Der Status wird nach jedem Schaltvorgang gesendet (auch wenn dieser über die Taste erfolgt) sowie auf zugehörige Lesetelegramme geantwortet.

Zusätzlich läuft ein einfacher Webserver, über den man den aktuellen Status einsehen sowie die Steckdose schalten kann, vor allem aber können darüber direkt Updates eingespielt werden.

Vielleicht ist es ja auch für den ein oder anderen interessant, Verbesserungspotential ist natürlich reichlich vorhanden:

https://github.com/McOrvas/sonoff-knxd

Gruß
Manfred

[Harry49]

Manfred, das ist das beste Ostergeschenk in diesem Jahr! Super, vielen Dank!!!

Läuft bei mir auf Anhieb und scheint auch keine Telegramme mehr zu verschlucken. Hatte inzwischen schon angefangen, mich in MQTT und OpenHab einzuarbeiten, was jedoch einen eigenen Raspi allein für diese Aufgabe bedeutet hätte. Konnte mich mit dem Gedanken wenig anfreunden und hatte daher auch wenig Elan (besonders hinsichtlich OpenHab2).

Also, ich kann die Lösung allen Wiregate-Besitzern (bzw. allen, die einen eibd laufen haben) sehr empfehlen.
Nochmals vielen Dank!

Gruß
Stephan

PS: Falls deine Programmier-Begeisterung noch anhält, liegen bei mir noch einige "Basics" und ein "4-Channel" rum (wobei die Basics vermutlich mit dem Sketch direkt so schon laufen sollten).

[Tulkas]

Hallo Stephan,

es freut mich zu hören, dass Du den Sketch auch gebrauchen kannst, dann hat sich das Basteln ja noch mehr gelohnt als nur für mich alleine. Wie Du schon geschrieben hast, sollte er unverändert auch direkt auf einem Sonoff Basic laufen, denn bis auf die fehlende LED sollte er gleich beschaltet sein. Ich selbst habe zwar bereits einen bestellt, jedoch im Moment noch keinen zum Testen da. Also probier es doch einfach mal aus. Für den Vierkanäler kann ich den Sketch bei Gelegenheit erweitern, das Testen überlasse ich dann mangels Hardware auch Dir. Ich melde mich einfach kurz, wenn ich es eingebaut habe.

Für einen anderen ziemlich speziellen Anwendungsfall bei mir (eine Schrankbeleuchtung mit einem Kontakt an der Tür) möchte ich den Sketch auch noch dahingehend erweitern, dass der Taster nicht zur zum Umschalten (wie aktuell) dienen kann, sondern auch als direkter Ein-/Ausschalten konfiguriert werden kann (also eingeschaltet solange gedrückt, ansonsten aus) und das ganze noch mit einer Zeitbeschränkung für den eingeschalteten Modus, damit das Licht z.B. maximal 5 Minuten an ist, bevor es trotz geöffneter Tür ausgeschaltet wird.

Gruß
Manfred

[Harry49]

Hallo Manfred,

die Sonoff Basic laufen ebenfalls mit deinem Sketch (die Taste und die eingebaute LED funktionieren richtig). Habe es inzwischen auf je drei Sonoff S-20 und Basic, ohne Probleme. Zwei der Basic habe ich in Strahler eingebaut, die draußen den Hof beleuchten und rund 35 m vom Accesspoint entfernt sind. Dazwischen einige Wände, also hinsichtlich des WLAN grenzwertig. Die waren vorher mein großes Problem und ließen sich nur durch mehrfaches Senden schalten. Jetzt reagieren sie zuverlässig.

Es wäre klasse, wenn du den Sketch um den "Vierkanäler" erweitern könntest. Ich teste dann auch gerne. Möchte den zum Schalten von Magnetventilen für die Gartenbewässerung nehmen. Derzeit macht dies so eine Kiste von Hunter, die ich gerne rausschmeissen würde. Bis es warm und trocken wird, scheine ich jedoch noch etwas Zeit zu haben.

Vielen Dank nochmals!

Gruß
Stephan

[hartmut]

Hallo Manfred,
auch ich benutze das Programm, habe aber eine kleine Ergänzung eingebaut. blinkenLed() einfach in der Loop Schleife aufrufen und schon blitzt es alle Sekunde kurz auf wenn die Verbindung steht.

Hartmut

void blinkenLed(void) {
unsigned long now = millis();
if (LedStatus == 0 ) {
if (next_change < now ) {
next_change = now + 10 ;
digitalWrite(gpioLed, LOW);
LedStatus = 1 ;
}
}
else {
if (next_change < now ) {
next_change = now + 1000 ;
digitalWrite(gpioLed, HIGH);
LedStatus = 0 ;
}

}
}

[Tulkas]

Das Blinken der LED habe ich bereits eingebaut und parametrierbar gemacht. Wird die LED auch für die Anzeige des Relaisstatus verwendet, so wird das Blinken invertiert. Die Erweiterung auf die vier Kanäle folgt demnächst.

[thesing]

Das es die Leute hier im Thread interessiert will ich mal ganz schamlos Werbung für meine Thread machen:
https://knx-user-forum.de/forum/%C3%...66-knx-mit-ets

Kurz: Das gleiche wie hier auch, nur mit ETS Unterstützung.

[OleDeluxe]

...
Kurz: Das gleiche wie hier auch, nur mit ETS Unterstützung.

Hi,
Hört sich interessant an. Wie baust du die Verbindung auf, über Multicast oder Tunnel?
Bei dieser Version hier scheint die Verbindung leider nicht 100% stabil zu sein, wie schaut es da bei dir aus, gibt es hierzu schon Erfahrungen?

Gruß, Sven