ESP RGBWW Wifi Led Controller - Firmware vbs

Begonnen von vbs, 18 April 2017, 09:26:13

Vorheriges Thema - Nächstes Thema

balli1187

Moin,

Nach etwas mehr als einer Woche im Betrieb ist gestern der eine Controller, den ich momentan einsetze einfach ausgestiegen.
Es ließ sich dann weder per FHEM etwas steuern, noch war die weboberfläche erreichbar.
Ein Neustart (strom weg, Strom dran) des Controllers hat nicht wirklich geholfen. Webapp war wieder erreichbar aber in FHEM keine Besserung.

Im Log kam etwa minütlich diese Meldung:
2019.10.08 21:08:45.006 1: 192.168.17.11:9090 disconnected, waiting to reappear (Wz_Ambilight)
2019.10.08 21:08:45.584 1: 192.168.17.11:9090 reappeared (Wz_Ambilight)
2019.10.08 21:08:46.400 3: Wz_Ambilight: got info response
2019.10.08 21:08:46.401 3: Wz_Ambilight: info response data {"deviceid":"10981491","current_rom":"0","git_version":"vbs35","git_date":"2018-08-22","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":1,"uptime":356220,"heap_free":22400,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"<WLAN>","dhcp":false,"ip":"192.168.17.11","netmask":"255.255.255.0","gateway":"192.168.17.1","mac":"840d8ea79073"}}


Eine echte Fehlermeldung kann nicht erkennen aber vielleicht seht ihr was.


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

pjakobs

Zitat von: balli1187 am 09 Oktober 2019, 08:41:01
Moin,

Nach etwas mehr als einer Woche im Betrieb ist gestern der eine Controller, den ich momentan einsetze einfach ausgestiegen.
Es ließ sich dann weder per FHEM etwas steuern, noch war die weboberfläche erreichbar.
Ein Neustart (strom weg, Strom dran) des Controllers hat nicht wirklich geholfen. Webapp war wieder erreichbar aber in FHEM keine Besserung.

Im Log kam etwa minütlich diese Meldung:
2019.10.08 21:08:45.006 1: 192.168.17.11:9090 disconnected, waiting to reappear (Wz_Ambilight)
2019.10.08 21:08:45.584 1: 192.168.17.11:9090 reappeared (Wz_Ambilight)
2019.10.08 21:08:46.400 3: Wz_Ambilight: got info response
2019.10.08 21:08:46.401 3: Wz_Ambilight: info response data {"deviceid":"10981491","current_rom":"0","git_version":"vbs35","git_date":"2018-08-22","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":1,"uptime":356220,"heap_free":22400,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"<WLAN>","dhcp":false,"ip":"192.168.17.11","netmask":"255.255.255.0","gateway":"192.168.17.1","mac":"840d8ea79073"}}


Eine echte Fehlermeldung kann nicht erkennen aber vielleicht seht ihr was.


Gesendet von iPhone mit Tapatalk

hmm... also die Messeg "connected" weist darauf hin, dass der Controller für fhem wieder erreichbar war und auch geantwortet hat. An der stelle *sollte* er auf Änderungen innerhalb fhem reagieren - ich hab allerdings schon erlebt, dass das ne Weile (ein paar Minuten) dauern kann.

Grundsätzlich glaube ich, es gibt nicht viele, die die Teile mit statischen IP Adressen betreiben, ich könnte mir vorstellen, dass das zum Problem beiträgt.
Gibt es einen besonderen Grund, warum Du statische Adressen vergibst? Ich habe z.B. dem dhcp Server meiner Fritz box gesagt, dass die Controller immer die gleiche Adresse bekommen sollen. Das hat im Grunde den gleichen Effekt, spart mir aber die Verwaltungsarbeit und minimiert das Risiko, dass zwei Geräte mit der gleichen Adresse im Netz sind. Zudem habe ich dann für die Controller namen vergeben und spreche sie aus fhem über den dns namen an, also selbst wenn die Adresse sich mal ändern sollte, bleibt die Konfiguration korrekt.

Ansonsten habe ich solche Probleme eigentlich immer nur als Folge von Netzwerkproblemen, und ich hab hier über 20 Controller im Einsatz.

Grüße

pj

vbs

Controller sieht für mich erstmal ok aus, wenn du sagst, dass die Weboberfläche funktioniert. FHEM kann sich ja auch verbinden und die Info abfragen. Guck doch mal, ob das Problem evtl. mit der aktuellen testing-FW gelöst ist.

pjakobs

Du @vbs, mal am Rande, hast Du gerade im Kopf, wie der Code zum Reconnect nach verlorenem WLAN ist?
Ich hatte hier vor ner Weile den Fall, dass mein FI rausflog (fragt nicht, nur soviel: mit dem Hochdruckreiniger über der Außensteckdose die Wand zu reinigen ist nur dann ne gute Idee, wenn man sie wirklich ausgeschaltet hat)
Nach dem Wieder Einschalten sind die Controller schneller wieder da als das WLAN und ich hab etliche resetten müssen, indem ich mich an deren AP verbinde und sie über das UI neu starte. Danach finden sie das WLAN zuverlässig.

Ich fänd es schön, wenn der Controller, wenn er ein konfiguriertes WLAN hat sich aber erstmal nicht verbinden konnte, vielleicht so alle fünf Minuten mal nachsieht, ob er es finden kann und, wenn er es findet, sich damit verbindet oder ggf. neu startet.

Ich weiß, wir haben den Code vor vielleicht zwei Jahren mal angefasst, aber ich weiß nicht, wie er aktuell ist.

Grüße

pj

balli1187

Zitat von: pjakobs am 09 Oktober 2019, 11:19:23
hmm... also die Messeg "connected" weist darauf hin, dass der Controller für fhem wieder erreichbar war und auch geantwortet hat. An der stelle *sollte* er auf Änderungen innerhalb fhem reagieren - ich hab allerdings schon erlebt, dass das ne Weile (ein paar Minuten) dauern kann.

Grundsätzlich glaube ich, es gibt nicht viele, die die Teile mit statischen IP Adressen betreiben, ich könnte mir vorstellen, dass das zum Problem beiträgt.
Gibt es einen besonderen Grund, warum Du statische Adressen vergibst? Ich habe z.B. dem dhcp Server meiner Fritz box gesagt, dass die Controller immer die gleiche Adresse bekommen sollen. Das hat im Grunde den gleichen Effekt, spart mir aber die Verwaltungsarbeit und minimiert das Risiko, dass zwei Geräte mit der gleichen Adresse im Netz sind. Zudem habe ich dann für die Controller namen vergeben und spreche sie aus fhem über den dns namen an, also selbst wenn die Adresse sich mal ändern sollte, bleibt die Konfiguration korrekt.

Ansonsten habe ich solche Probleme eigentlich immer nur als Folge von Netzwerkproblemen, und ich hab hier über 20 Controller im Einsatz.

Grüße

pj
Hallo,

connected war er ja immer nur für eine kurze Zeit. Ich hab es nicht auf die sekunde genau ausgezählt aber diese Meldung kam im Abstand von ca. eienr Minute immer weider. Ich würde daher vermuten, dass er dann für FHEM nicht erreichbar war, ws ja auch gleich zum ersten Eintrag (disconnected, waiting to reappear) passt. So lief es dann scheinbar ein ganze Weile, da ich es erst gegen 23:00 mitbekommen hab, da das Licht nciht ausging ;-)

Die Webapp war wie gesagt erst nach einem hardreset des controllers wieder erreichbar.

Die statische IP kann man wohl meinem inneren Monk zuschreiben. "Feste" Geräte bekommen bei mir halt eine statische IP und bisher war das noch nirgends ein Problem. In einem der Threads war in den FAQs auch zu lesen, dass Hostnamen nicht mehr untestützt werden.

@vbs: da kommt dann wieder as Problem mit dem gescheiterten Update zum Vorschein. Da ich den Controller jetzt schon hinterm Fernseher verbaut habe, ist das nciht ganz so schnell gemacht und cih würde vorher gern andere mögliche Ursachen ausschließen bevor ich auf Verdacht eine testing-FW falshe.
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

pjakobs

Zitat von: balli1187 am 09 Oktober 2019, 17:40:36
Hallo,

connected war er ja immer nur für eine kurze Zeit. Ich hab es nicht auf die sekunde genau ausgezählt aber diese Meldung kam im Abstand von ca. eienr Minute immer weider. Ich würde daher vermuten, dass er dann für FHEM nicht erreichbar war, ws ja auch gleich zum ersten Eintrag (disconnected, waiting to reappear) passt. So lief es dann scheinbar ein ganze Weile, da ich es erst gegen 23:00 mitbekommen hab, da das Licht nciht ausging ;-)

Die Webapp war wie gesagt erst nach einem hardreset des controllers wieder erreichbar.

Die statische IP kann man wohl meinem inneren Monk zuschreiben. "Feste" Geräte bekommen bei mir halt eine statische IP und bisher war das noch nirgends ein Problem. In einem der Threads war in den FAQs auch zu lesen, dass Hostnamen nicht mehr untestützt werden.

@vbs: da kommt dann wieder as Problem mit dem gescheiterten Update zum Vorschein. Da ich den Controller jetzt schon hinterm Fernseher verbaut habe, ist das nciht ganz so schnell gemacht und cih würde vorher gern andere mögliche Ursachen ausschließen bevor ich auf Verdacht eine testing-FW falshe.
Ich wüsste nicht, an welcher Stelle der Hostname nicht unterstützt sein sollte.
Ich glaube es gibt oder gab ein Problem, dass der auf dem Controller vergebene Name nicht als DHCP Name geschickt wird, aber ich hab die Namen halt gleich an der Fritzbox konfiguriert, dann gibt es auch keinen Stress mit der DNS DHCP Konfiguration.

Ich hab zwei Dinge im Verdacht: möglicherweise wirklich was mit der fest konfigurierten IP Adresse oder, imho wahrscheinlicher, schwaches WLAN, besonders, wenn das Gerät hinter dem Fernseher verbaut ist. Bei exzessiven Retransmissions kommt lwip irgendwie zu Blocks.
Das passiert allerdings primär bei der Übertragung großer Datenmengen, also beim Laden des UI oder eben beim Firmware Update.

pj

Gesendet von meinem HTC U11 mit Tapatalk


balli1187

Zitat von: pjakobs am 09 Oktober 2019, 18:05:21
Ich wüsste nicht, an welcher Stelle der Hostname nicht unterstützt sein sollte.
Ich glaube es gibt oder gab ein Problem, dass der auf dem Controller vergebene Name nicht als DHCP Name geschickt wird, aber ich hab die Namen halt gleich an der Fritzbox konfiguriert, dann gibt es auch keinen Stress mit der DNS DHCP Konfiguration.

Ich hab zwei Dinge im Verdacht: möglicherweise wirklich was mit der fest konfigurierten IP Adresse oder, imho wahrscheinlicher, schwaches WLAN, besonders, wenn das Gerät hinter dem Fernseher verbaut ist. Bei exzessiven Retransmissions kommt lwip irgendwie zu Blocks.
Das passiert allerdings primär bei der Übertragung großer Datenmengen, also beim Laden des UI oder eben beim Firmware Update.

pj

Gesendet von meinem HTC U11 mit Tapatalk
Okay, vielleicht habe ich das mit den Hostnamen falsch verstanden oder mich verlesen.

Der controller sitz zwar hinter dem Fernseher aber ziemlich weit an der Seite und ist Luftlinie vielleicht  6...7m von einem Unifi AP Pro mit lediglich einer holztür dazwischen entfernt. Seitdem ich das Ding habe, hatte ich eigentlich keine Probleme mehr mit schlechtem WLAN.

Der alte Controller (LED-Ufo) saß an selber stelle und hat sich in den 2 Jahren nicht am WLAN gestört.


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

pjakobs

#1087
Also: wir haben derzeit über 1300 der Controller, die irgendwo benutzt werden. Irgendwas muss bei Dir anders sein, denn die Fehler kenne ich so nur bei Netzwerkproblemen.

Ich würde Dich um folgendes bitten:

auf dem fhem Host (hoffend, dass der unter Linux läuft) versuche mal folgendes:


arping -c 5 -D -I <ethernet device> <controller ip>


und poste den Output hier.

wenn der Controller gerade mal nicht erreichbar ist,  versuch das nochmal (Du kannst auch, indem Du den Parameter -c auf 1000 oder so setzt, den ping einfach länger laufen lassen und hoffen, dass es mal abbricht)

Ansonsten würde ich Dich bitten, dem Controller mal eine Adresse vom DHCP Server zuweisen zu lassen. Wie gesagt, mir ist sonst niemand bewusst, der eine fixe IP benutzt und ich vermute mal, dass der Pfad auch in lwip weniger getestet ist.

pj

[edit] vermutlich wirst Du arping mit sudo apt install arping erstmal installieren müssen.

vbs

Zitat von: pjakobs am 09 Oktober 2019, 13:34:05
Du @vbs, mal am Rande, hast Du gerade im Kopf, wie der Code zum Reconnect nach verlorenem WLAN ist?
Ich hatte hier vor ner Weile den Fall, dass mein FI rausflog (fragt nicht, nur soviel: mit dem Hochdruckreiniger über der Außensteckdose die Wand zu reinigen ist nur dann ne gute Idee, wenn man sie wirklich ausgeschaltet hat)
Nach dem Wieder Einschalten sind die Controller schneller wieder da als das WLAN und ich hab etliche resetten müssen, indem ich mich an deren AP verbinde und sie über das UI neu starte. Danach finden sie das WLAN zuverlässig.
Soweit ich weiß, läuft es so, dass der Controller sich beim Wifi-Verlust 10mal wieder versucht zu verbinden. Danach gibt er aus Verzweiflung auf und spannt wieder sein eigenes Netz auf. Ich kann nicht sagen, wie lange ein Versuch dauert. Also evtl. haben in deinem Fall (ich hatte auch schon mal sowas) die 10 Versuche einfach nicht gereicht. Ich könnte erstmal anbieten, diese Anzahl konfigurierbar zu machen.
Aber ich bin da momentan nicht dran an der FW und kann es aber für eine eventuelle nächste Session vormerken.
Oder hast du noch andere Ideen? Swoeit ich weiß, kann man nicht im AP-Modus nach anderen Netzen scannen, bin aber nicht sicher.

PeMue

Zitat von: vbs am 09 Oktober 2019, 21:07:51
Ich kann nicht sagen, wie lange ein Versuch dauert.
Wenn ich mich recht erinnere, hat HCS bei der LGW Firmware sowohl eine Verzögerung beim ersten Versuch (nach z.B. Stromausfall) drinnen bzw. zwischen den einzelnen Versuchen eine Wartezeit. Ersteres ist konfigurierbar, zweiteres meine ich fest eingestellt (mit 2 s oder so). Dies als Anregung ...

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

AxelSchweiss

Zitat von: vbs am 09 Oktober 2019, 21:07:51
Oder hast du noch andere Ideen? Swoeit ich weiß, kann man nicht im AP-Modus nach anderen Netzen scannen, bin aber nicht sicher.
Ich meine bei der Tasmota Firmware geht das ...
Du verbindest dich zuerst auf den AP und scannst dann nach WLAN's.
Das gibt dann eine Liste aus der du dein WLAN auswählst.
Hope that helps ...

vbs

Ja danke, hast natürlich recht. Das muss ja gehen...  ::)

@Peter
Ja auch gut, man könnte auch die Wartezeiten zwischen den Versuchen sukzessive erhöhen oder so.


Was wäre denn ideal? AP aufspannen und trotzdem weiter scannen und wenn das Original-Netz wieder verfügbar ist, dann verbinden? Kann dann passieren, dass man gerade mit dem AP verbunden ist und dann der Controller mittendrin umswitcht.

pjakobs

ich denke, zumindest in meinem Fall wäre es auch ausreichend, wenn ein Netz konfiguriert aber nicht erreichbar ist, alle fünf Minuten mal danach zu sehen. Dann dauert es halt im Zweifel mal fünf Minuten und dazwischen wäre der ESP AP erreichbar

pj

vbs

Das entspräche dann meiner zweiten Variante?

pjakobs

Zitat von: vbs am 09 Oktober 2019, 21:39:37
Das entspräche dann meiner zweiten Variante?

das kann ich offen gesprochen im Moment garnicht sagen, ich hab die Varianten nicht durchgezählt.
aber wäre nicht sinnvoll, sagen wir mal in den ersten 10 Sekunden 10 Verbindungsversuche zu machen (oder von mir aus in 30s 10)
Wenn danach keine Verbindung zustande kommt den AP aufspannen und, sagen wir alle fünf Minuten, wenn kein Client verbunden ist, nochmal zu versuchen, sich mit dem konfigurierten Netz zu verbinden. Irgendwas in der Art.
Wenn man scannen kann, während der AP offen ist (ich meine, zumindest mit dem Arduino API geht das), dann lässt es sich ja noch eleganter machen.

pj