ebusd enhanced mit ebusd-esp auf Wemos

[john30]

Hattest du meine Logs vom 7. November gesehen?

ja habs gesehen, hatte aber noch keine Zeit, mir das anzuschauen

[Sven77]

Ich muss das Thema "enhanced" mal wieder hochholen...

Gibt es außer mir noch jemanden, der die ebusd-esp Firmware nutzt?
Der einzig brauchbare Modus scheint ja aktuell der normale (also nicht "enhanced") und über WiFi zu sein. Leider kommt es da bei mir immer mal wieder zu Verbindungsabbrüchen - ich kann leider nicht sagen, ob diese vom WLAN oder Ebus kommen.
Beispiele:

Code Auswählen Erweitern

2019-04-03 08:17:21.099 [bus error] send to 15: ERR: wrong symbol received, retry
2019-04-03 08:17:23.855 [bus notice] arbitration won in invalid state skip
2019-04-03 08:17:25.040 [bus error] signal lost
2019-04-03 08:17:25.041 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.041 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.310 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.310 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.580 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:25.581 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:25.850 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:25.850 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:26.120 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:26.120 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:26.392 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:26.392 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:30.710 [bus error] send to 15: ERR: no signal, give up
2019-04-03 08:17:30.711 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:41.240 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:41.240 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:43.670 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:43.671 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.020 [bus error] send to 0a: ERR: no signal, give up
2019-04-03 08:17:45.020 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.290 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:45.291 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:45.560 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:45.560 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:46.640 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:46.641 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:52.040 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:52.041 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:53.931 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:53.931 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:54.201 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:54.201 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:55.280 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:55.281 [bus error] send message part 0: ERR: no signal
2019-04-03 08:17:56.090 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:17:56.090 [bus error] send message part 0: ERR: no signal
2019-04-03 08:18:01.760 [bus error] send to 08: ERR: no signal, give up
2019-04-03 08:18:01.760 [bus error] send message part 0: ERR: no signal
2019-04-03 08:18:03.387 [bus notice] signal acquired

Oder auch:

Code Auswählen Erweitern

2019-04-03 08:34:30.323 [bus error] send to 15: ERR: SYN received, retry
2019-04-03 08:34:30.560 [bus error] send to 15: ERR: read timeout, retry
2019-04-03 08:34:31.116 [bus error] send to 15: ERR: wrong symbol received
2019-04-03 08:34:31.116 [bus error] send message part 0: ERR: wrong symbol received
...
2019-04-03 08:35:17.306 [bus error] send to 08: ERR: wrong symbol received, retry
2019-04-03 08:35:18.003 [update notice] sent read bai CounterStartattempts1 QQ=31: 0
2019-04-03 08:35:18.188 [bus error] send to 08: ERR: SYN received, retry
2019-04-03 08:35:19.220 [bus error] send to 08: ERR: read timeout, retry

Nun sehe ich auf Github zwar einige Commits im Branch enhanced_device, aber diese scheinen eher kosmetischer Natur bzw. die Übernahme vom master Branch. Im ebusd-esp sieht es ähnlich ruhig aus...
Gibt es irgendetwas, wie ich eventuell helfen könnte? Ich wäre sehr an einer Lösung interessiert, die von der Latenz dichter an die Ebus-Spezifikation herankommt!

[john30]

Der einzig brauchbare Modus scheint ja aktuell der normale (also nicht "enhanced") und über WiFi zu sein. Leider kommt es da bei mir immer mal wieder zu Verbindungsabbrüchen - ich kann leider nicht sagen, ob diese vom WLAN oder Ebus kommen.
...
Nun sehe ich auf Github zwar einige Commits im Branch enhanced_device, aber diese scheinen eher kosmetischer Natur bzw. die Übernahme vom master Branch. Im ebusd-esp sieht es ähnlich ruhig aus...
Gibt es irgendetwas, wie ich eventuell helfen könnte? Ich wäre sehr an einer Lösung interessiert, die von der Latenz dichter an die Ebus-Spezifikation herankommt!

mir fehlt es hier einfach an Zeit, um das weiter zu pushen.
Um die Latenzprobleme endgültig los zu werden gibt es eigentlich nur die Variante, das enhanced Protokoll noch weiter zu treiben und auf ganze Messages umzustellen, d.h. der wemos macht das ganze eBUS Protokoll Handling und tauscht nur noch ganze Nachrichten (bzw. ganze master/slave Teile) mit ebusd aus. Damit wären dann WIFI Latenzen auch mehrerer 100 ms völlig egal.
Aber das ist wieder ein enormer Umbau im ebusd und auch dafür fehlt die Zeit leider.
Ein anderer Ansatz wäre die jetzigen Latenzprobleme zu debuggen, was ebenfalls sehr zeitintensiv und zudem schwierig ist, da im Wemos debuggt werden muss. Ist also reichlich umständlich.
Wenn es hilft kann ich ohne großen Zeitaufwand noch den WIFI Status inkl. Signalstärke in die ebusd-esp Statusseite reinnehmen, vielleicht ist auch einfach die Strecke bei dir außergewöhnlich schlecht.
Ich habe bei meinen Tests aber auch schon mal gesehen, dass derleit Probleme bspw. auftreten wenn jemand anders im gleichen Netz ein Videostreaming am Laufen hat. Insofern ist mein Gefühl (ohne Beweis), dass das WIFI Handling im Wemos nicht besonders stabil ist. Hier könnte evtl. ein erneutes Update der Buildumgebung auf den aktuellen Stand Verbesserung bringen, mal schauen ob sich am WIFI Stack hier etwas getan hat.

[john30]

Im ebusd-esp sieht es ähnlich ruhig aus...

ich habe jetzt mal SDK und Arduino Core aktualisiert und RSSI eingebaut. Mit dabei ist auch ein lwIP Update, was auch helfen könnte.
Schau doch mal, ob es dadurch besser wird.
Parallel lasse ich auch mal einen Wemos permanent laufen, um disconnects zumindest mal mengenmäßig zu erfassen.

[Sven77]

Hallo John,
ja - das mit der Zeit ist mir völlig klar, daher habe ich ja auch lange nicht mehr nachgefragt.
Das mit den Störungen im WLAN würde ich ja am liebsten komplett ausklammern, indem ich den Wemos seriell anbinde - nur das klappt ja bei mir im enhanced_mode irgendwie gar nicht!
Und selbst ohne enhanced_mode kann ich eine direkte serielle Verbindung mit dem Wemos überhaupt nicht nutzen (s. Post vom 07.11.2018).

Mir geht es also in erster Linie gar nicht um Weiterentwicklungen, sondern in der korrekten Nutzung des vorhandenen.
Ich probiere auf jeden Fall mal die neue Firmware aus - aber klappt denn bei dir eine serielle Verbindung zum Wemos??


UPDATE: Nur zur Info, die RSSI steht bei mir auf "100% (-40dBm)" - der Wemos liegt schließlich auch nur ca. 50cm vom AccessPoint entfernt.

[john30]

Ich probiere auf jeden Fall mal die neue Firmware aus - aber klappt denn bei dir eine serielle Verbindung zum Wemos??

das hatte ich jetzt nicht mehr auf dem Schirm und insofern auch überhaupt nicht mehr getestet.

UPDATE: Nur zur Info, die RSSI steht bei mir auf "100% (-40dBm)" - der Wemos liegt schließlich auch nur ca. 50cm vom AccessPoint entfernt.

bei mir ist die Empfangsstärke auch recht gut und insofern keine Erklärung für die bisherigen Probleme.
Aber das core/sdk/SoftwareSerial Update hat bei mir im Dauertest zumindest deutliche Verbesserung gebracht.

[Sven77]

Mein Update-Check meckert ständig, dass es schon eine Version 3.3 gibt...
Macht es Sinn, sich mit dem Thema "enhanced_mode" weiter zu beschäftigen, oder ist das erstmal ganz vom Tisch?

Mir würde schon daran liegen, eine latenzfreiere Lösung zu haben - gebe aber auch zu, dass ich bisher noch nie den modifizierten Raspi-Kerneltreiber probiert habe (weil ich schlichtweg aktuell keinen Raspi, sondern ein anderes embedded device im Einsatz habe).

In der aktuellen Implementierung hat jedenfalls meine Vaillant Steuerung immer mal wieder (ca. 2x pro Monat) Schwierigkeiten den Ölbrenner nach der Außentemperatur zu befragen und geht dann in einen Notfallmodus und nimmt -40°C an. Ist natürlich selten dämlich implementiert, aber Vaillant kann/will/darf daran offenbar nichts ändern.

[john30]

Mein Update-Check meckert ständig, dass es schon eine Version 3.3 gibt...
Macht es Sinn, sich mit dem Thema "enhanced_mode" weiter zu beschäftigen, oder ist das erstmal ganz vom Tisch?

auf welchem Stand bist du denn? ich nehme an, du hast selbst gecloned und compiliert?
enhanced ist für mich nicht vom Tisch, insbesondere da das in Verbindung mit dem ebusd-esp nur eine erste quasi beispielhafte Implementierung war. Da soll es künftig noch eine weitere Hardware Variante geben, die direkt das enhanced Protokoll spricht. Aber da ale extrem beschäftigt sind, geht hier nicht viel vorwärts. Vielleicht wieder eher was für den Winter

[Sven77]

auf welchem Stand bist du denn? ich nehme an, du hast selbst gecloned und compiliert?

Ja, nach meinem Kenntnisstand war/ist das nötig, um überhaupt den enhanced_mode zu bekommen.
Und auch Github sagt "This branch is 20 commits ahead, 51 commits behind master."

Okay - das es eine Hardwarevariante geben soll, die dann das Protkoll spricht, war mir neu - naja, ich hatte mir gerade 2 Stück von der aktuellen zugelegt, aber warten wir ab, was sich da noch tut. Es wäre jedenfalls sicher auch für alle anderen sinnvoll, eine halbwegs spezifikationstreue Lösung zu bekommen. 

[john30]

Und auch Github sagt "This branch is 20 commits ahead, 51 commits behind master."

ah stimmt, im ebusd-esp ist es im Hauptbranch und im ebusd noch nicht. Die muss ich mal wieder zusammenführen.

Okay - das es eine Hardwarevariante geben soll, die dann das Protkoll spricht, war mir neu - naja, ich hatte mir gerade 2 Stück von der aktuellen zugelegt, aber warten wir ab, was sich da noch tut.

bis dahin wird es sicher noch eine gute Weile dauern, weil alle sehr beschäftigt sind.

Es wäre jedenfalls sicher auch für alle anderen sinnvoll, eine halbwegs spezifikationstreue Lösung zu bekommen. 

wir jammern ja alle auf hohem Niveau (im Vergleich zu vor ein paar Jahren)