[DEV 0.5.15 - 269b0fb] Auffälligkeiten bzw. Issues

[fila612]

Hallo zusammen,

ich habe mir eben aus dem dev-branch die letzte Version gebaut (esp8266-release) und auf meinem Testsystem installiert.
Folgendes ist mir aufgefallen:

1. Get Firmware-Info
   Zu Beginn hatte ich keinen MQTT-Server hinterlegt. Firmware via Button angefragt und wurde dann in Klammern angezeigt (10010).
   Um dann aber weitere Details zu sehen, habe ich meine MQTT-Broker hinterlegt und die FW-Infos dort geprüft.
   .
   nun stehen da ganz anderen Werte drin und auf der Index Seite ist die Firmware mit (1) nun angegeben.

2. bei der Version erhalte ich in durchgehend diesen Eintrag in der Seriellen Konsole, andere Infos sind nicht mehr erkennbar:
   [...]
   08:00:42.214 > I: subscribe to /devcontrol/#
   08:00:42.224 > I: subscribe to /devcontrol/#
   08:00:42.232 > I: subscribe to /devcontrol/#
   08:00:42.240 > I: subscribe to /devcontrol/#
   08:00:42.247 > I: subscribe to /devcontrol/#
   [...]

3. die ALARM_MES_ID stieg bei Nutzung des Testsystems (0.5.15) rasant an, von unter 20 auf über 80 innerhalb weniger Minuten. Ich muss daher davon ausgehen, dass es mit der Version zusammenhängen könnte, ggf. mit Punkt 2?

ich bin mir nicht sicher, ob diese Auffälligkeiten works as designed sind, Fehler im Code selbst oder aber anderes Ursachen haben könnten.

[HorstG-57]

Die Meldungen mit dem Subscribe sind mir auch schon aufgefallen.

Soweit ich das nachvollziehen konnte, werden die von einer Stellen in der app.cpp Zeile 193 ausgelöst.

Hier wird die Funktion mqtt.isConnected(true) aufgerufen.
Soweit wie sich der Code für mich erschließt, ist das an dieser Stelle überhaupt nicht notwendig.

Jedes mqtt.sendMsg mach sowieso eine connect Überprüfung.

[fila612]

zusätzlich ist grad noch aufgefallen, dass nach jeder Änderung bzgl. der Verbindung zum WR das PowerLimit neu gesetzt wird. zumindest erhalte ich dann immer eine Hinweis ob der WR dies akzeptiert oder nicht.
evtl. müsste man die Häufigkeit des Senden PowerLimit ggf. noch mal Prüfen, es würde ja reichen nur zu schicken, wenn es Änderungen daran gegeben hat, oder?

[HorstG-57]

Im Codeteil app::loadEEpconfig in den Zeilen 855 - 863 wird das PowerLimt schon sehr früh im Programlauf zur Aussendung an de WR gesetzt ( quasi noch bevor die Verbindung zum WR aufgebaut wurde ).

Ich meine das ist an dieser Stelle viel zu früh.
Eigentlich darf das PowerLimit erst gesendet werden,
nachdem das erste mal eine Komunikation ( eine Abfrage der Werte ) mit dem WR stattgefunden hat.

[stefan123t]

@fila612 danke für das issue:

1. vermutlich wurde die HW Info nochmals überschrieben. Ohne TX/RX Logging (DEBUG in dbg.h) werden wir das nicht einfach eingrenzen können. Bitte nochmal versuchen das zu reproduzieren. Danke!
2. die zu häufigen Topic subscribe zum MQTT Server / Broker sollten eigentlich durch den PR Das subscribe in der Reconnect Procedure sollte doch nur nach einem conect ausgeführt werden und nicht bei jedem Duchlauf #138 von @HorstG-57 behoben sein. Dh das Issue Das subscribe in der Reconnect Procedure sollte doch nur nach einem conect ausgeführt werden und nicht bei jedem Duchlauf #139 ist leider noch nicht gelöst. Ich mache es nach diesem Hinweis wieder auf. Wenn ihr da noch Änderungsbedarf seht bitte einen neuen PR gegen development stellen. Danke!
3. eine Auswertung der AlarmData / AlarmUpdate Commands mit den letzten 10-20 Fehlern des WR ist als Teilaufgabe von 145 geplant. ich habe einen Subtask Feature Request: DevInform AlarmData/AlarmUpdate Parser #177 speziell für AlarmData / AlarmUpdate aufgemacht.

[fila612]

Danke @stefan123t,
ich schau das ich das nochmal reproduziere, wenn dafür ein debug build baue, sollte das ausreichen oder braucht es dafür noch darüber hinaus code Anpassungen?

Was mir grad noch aufgefallen ist:
ich habe 2 Ahoys: 1xProd & 1xTest, das Testsystem läuft nur, wenn ich neue FW prüfe/teste.
Das habe ich heute morgen gemacht und die o.g. Punkte identifiziert. Was ich jetzt erst bemerkt habe ist, dass die MQTT-Messages aus dem ProdSystem seit der temporären Nutzung des Testsystem mit 0.5.15 heute Morgen inaktiv waren. D.h. ich habe in meinem HA keinerlei Daten von AHOY von 8-12 heute.
Nachdem ich Prod rebootet habe, läuft es wieder.

[stefan123t]

Hallo @fila612 das kann mit der gleichen DTU ID zusammenhängen aber auch damit dass der WR von zwei DTUs mit Kommandos abgefragt / bestürmt wird.
Eventuell wäre es sinnvoll die DTU ID für den Debug Build anzupassen um das Risiko derartiger Kommando Kollissionen zumindest etwas zu minimieren.
Für das TX/RX Debug muss man mW direkt in dbg.h den DEBUG Level auf DEBUG oder sogar VERBOSE setzen. Das sollte eigentlich auch noch in ein Issue / Feature damit man dazu nicht immer neu bauen muss.

[fila612]

hm, okay,
ich hab gerade mit dem defug release probiert -ist eher suboptimal, da massive folgende Meldung erscheint:
12:10:16.030 > http-server loop: conn=1 avail=0 status=wait-close
da fallen die interessanten Punkte schnell raus und man hat keine Chance das zu lesen.

komischerweise: zeigt er nun valide Werte als FW an:

[fila612]

Hallo @fila612 das kann mit der gleichen DTU ID zusammenhängen aber auch damit dass der WR von zwei DTUs mit Kommandos abgefragt / bestürmt wird.
Eventuell wäre es sinnvoll die DTU ID für den Debug Build anzupassen um das Risiko derartiger Kommando Kollissionen zumindest etwas zu minimieren.
Für das TX/RX Debug muss man mW direkt in dbg.h den DEBUG Level auf DEBUG oder sogar VERBOSE setzen. Das sollte eigentlich auch noch in ein Issue / Feature damit man dazu nicht immer neu bauen muss.

ja, das ist blöd. da kann ich nicht so einfach 2 System parallel laufen lassen. Ich merke auch grad, dass es besser wäre den Autodiscover für HA im Setup zu deaktivieren. Der spuckt mir dann auch in die Suppe und mein HA kommt da durcheinander.

[HorstG-57]

für Autodiscover gibt es einen Schalter in der app.h, damit man den abschalten kann.

Ich meine das mehfache subscribe / isConnedet kann an der von mir beschiebene Stelle ( app.cpp Zeile 193 ) einfach weggenommen werden.

Ich habe mir das noch mal angeschaut.
In der mqtt.connect Prozedur wird da nichts weiter ausgeführt,
da hier festgestellt wird, das die MQTT-Verbindung vorhanden ist.

Es wird halt nur die Meldung auf der Konsole ausgegeben.

[stefan123t]

@fila612 das HTML debuggen ist nur im debug build aktiv, das sind die ESP_DEBUG Optionen in der platformio.ini wenn Du willst kannst Du einfach ein normales Release bauen oder die Zeile mit ; auskommentieren.

@HorstG-57 wäre es nicht sinnvoll das Home Assistant Autodiscovery generell nur auf Anfrage (Knopf in Setup UI oder Save Settings) auszuführen ? Oder macht es Sinn das jedes Mal wenn der ESP rebootet oder so erneut zu senden ?

[HorstG-57]

Und Ja, das mit der MQTT-ID ist eine schöne Falle in die man reintappen kann.

Bei mehreren DTUs umbedingt den Device-Namen ändern, sonst läuft das beim MQTT-Broker durcheinander.

[tastendruecker123]

Hab den MQTT Code in PR #179 etwas angepasst.

[HorstG-57]

Die Frage hatte ich auch schon mal so ähnlich gestellt.

Ich meine es sollte eine Möglichkeit geben, das im Setup wenigsten ein und abschaltbar zu machen.

Ich habs halt erst mal mit einem Schalten so gelöst, damit es sich einfacher abschalten läst
( für die die das dann selber bauen und für Test ).

Da ich mich mit den HTML Seiten überhaupt noch nicht beschäftigt habe,
sollte das jemand einbauen, der da schon mal Schalter eingebaut hat
incl. dem speichern und zurücklesen des Schaltern in und von Eeprom.

Wenn man es so Einbaut, das man auf Anforderung die Discover Daten zum MQTT schreiben läst,
werden die ja als Permanent im MQTT abgelegt.
Dann sollte man gleichzeitig auch die Möglichkeit schaffen die aus dem MQTT wieder rausnehmen zu können,
ev. noch mal zu schreiben aber als nicht Permanent .
Dann müssten die nach der Gültigkeitszeit auf dem MQTT Broker ja automatisch vom Broker gelöscht werden.

[aschiffler]

@tastendruecker123 Ist im development drin.

@HorstG-57

Im Codeteil app::loadEEpconfig in den Zeilen 855 - 863 wird das PowerLimt schon sehr früh im Programlauf zur Aussendung an de WR gesetzt ( quasi noch bevor die Verbindung zum WR aufgebaut wurde ).

Ich meine das ist an dieser Stelle viel zu früh. Eigentlich darf das PowerLimit erst gesendet werden, nachdem das erste mal eine Komunikation ( eine Abfrage der Werte ) mit dem WR stattgefunden hat.

Sehr guter Hinweis. Hat mich selbst gestört.
Das Powerlimit wird nun NICHT mehr nach dem booten an den WR gesendet.

1. Wenn es persistent hinterlegt ist bzw. durch den User das letztemal z.B. vor einem dtu reboot als persistent gesendet hat, kennt der WR es ja noch
2. Wenn der Nutzer es als temporär gesetzt hat ist es nun "by-design" dass nach einem dtu reboot es nicht mehr erneut gesetzt wird.