ESP RGBWW Wifi Led Controller - Firmware vbs

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

Vorheriges Thema - Nächstes Thema

jojoja

Mahlzeit und gutes Neues erstmal!

Habe gerade auf vbs16 und das aktuelle Modul upgedated. Seitdem nimmt der Controller aus fhem heraus keine Befehle mehr entgegen, es gibt keine Reaktion in fhem oder auf dem Controller.
Wenn ich allerdings auf dem Controller direkt etwas ändere, kommt das auch in fhem an, die Readings bekommen Updates.
Ein anderer Controller mit vbs7 funktioniert tadellos.

Hier ein Auszug aus dem Log (die vorletzte Zeile ist vermutlich interessant):

2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: No PARTIAL buffer
2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":0,"g":0,"b":0,"ww":1023,"cw":0},"hsv":{"h":0.00,"s":0.00,"v":100.00,"ct":0}},"id":20}
2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":0,"g":0,"b":0,"ww":1023,"cw":0},"hsv":{"h":0.00,"s":0.00,"v":100.00,"ct":0}},"id":20}
2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ProcessRead: Decoding JSON message. Length: 159 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":0,"g":0,"b":0,"ww":1023,"cw":0},"hsv":{"h":0.00,"s":0.00,"v":100.00,"ct":0}},"id":20}
2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ProcessRead: Tail:
2018.01.02 14:20:07 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ProcessRead: PARTIAL:
2018.01.02 14:20:08 4: rgbw_JohannesSchlafBettbeleuchtung: LedController_CheckConnection: Connection still alive. Last data received 24.8633069992065 s ago
2018.01.02 14:20:09 5: rgbw_JohannesSchlafBettbeleuchtung: called SetHSVColor
2018.01.02 14:20:09 5: rgbw_JohannesSchlafBettbeleuchtung: encoded json data: {"t":"333","q":"single","d":"1","cmd":"fade","hsv":{"h":"+0","v":0,"s":"+0"}}
2018.01.02 14:20:09 5: rgbw_JohannesSchlafBettbeleuchtung: set HSV color request: {"t":"333","q":"single","d":"1","cmd":"fade","hsv":{"h":"+0","v":0,"s":"+0"}}
2018.01.02 14:20:09 5: rgbw_JohannesSchlafBettbeleuchtung: LedController_ParseBoolResult
2018.01.02 14:20:09 3: rgbw_JohannesSchlafBettbeleuchtung: error LedController_ParseBoolResult: {"error":"no body"}
2018.01.02 14:20:18 4: rgbw_JohannesSchlafBettbeleuchtung: LedController_CheckConnection: Connection still alive. Last data received 34.8665800094604 s ago


Und die Definition:

defmod rgbw_JohannesSchlafBettbeleuchtung LedController 192.168.178.81
attr rgbw_JohannesSchlafBettbeleuchtung DbLogInclude stateLight
attr rgbw_JohannesSchlafBettbeleuchtung alias Bettbeleuchtung
attr rgbw_JohannesSchlafBettbeleuchtung defaultRamp 333
attr rgbw_JohannesSchlafBettbeleuchtung devStateIcon Aus:general_aus@grey:Hell Ein:general_an@yellow:off
attr rgbw_JohannesSchlafBettbeleuchtung eventMap /on:Ein/off:Aus/rgb ffffff:Hell/
attr rgbw_JohannesSchlafBettbeleuchtung group Steuerung
attr rgbw_JohannesSchlafBettbeleuchtung icon scene_sleeping_alternat
attr rgbw_JohannesSchlafBettbeleuchtung room 1.3 Johannes Schlaf
attr rgbw_JohannesSchlafBettbeleuchtung stateFormat stateLight
attr rgbw_JohannesSchlafBettbeleuchtung webCmd rgb:Aus:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ffffff
attr rgbw_JohannesSchlafBettbeleuchtung widgetOverride rgb:colorpicker,rgb



Habe ich da in der letzten Vergangenheit was verpasst?

Viele Grüße,
Johannes
FHEM 6.0 @ IntelNUC6CAYH;  Unifi USG, Switch, AP AC Pro; HM-MOD-UART;  Sonos Play 1 & 3, One, Beam; Philips Hue

vbs

Hi Johannes,

ja der Name und die URL des FHEM-Moduls haben sich geändert. Heißt jetzt "EspLedController". Die alte Variante wird nicht mehr gepflegt. Habe es im ersten Post nochmal hervorgehoben. Probier bitte mal, ob das dein Problem löst. Ich vermute schon! Ansonsten nochmal Bescheid geben!

Ich glaube, ich werde die alte Variante jetzt einfach löschen, so dass man als User zumindest eine Fehlermeldung bekommt.

vbs

Spannend: habe gestern auf einmal sehr viele Crashes/Reboots des Controller reproduzieren können. Tritt auf, wenn man mehrere HTTP-Anfragen parallel sendet. Ist mit ziemlicher Sicherheit der Effekt, den auch Shojo schonmal beklagt hatte (jeder Bug kommt irgendwann zurück, immer ;)).

Habe heute ziemlich viel gefummelt und ich denke, dass der RAM des kleinen ESP einfach am Ende ist. Wenn mehrere Anfragen parallel reinkommen geht der freie Heap-Speicher zu neige (das kann man auch sehen) und dann gibt's den Reboot.
Habe eine vbs17 gemacht, bei der keine HTTP-Anfragen angenommen werden, wenn weniger als 10kB Heap frei ist. Damit hatte ich jetzt keine Reboots mehr. Kann dann aber eben passieren, dass einzelne Anfrage nicht bearbeitet werden. Das Szenario sollte aber im Normalbetrieb eigentlich nicht auftreten. Aber bitte Bescheid geben, wenn jemandem in dieser Hinsicht (oder jeder anderen natürlich) etwas auffällt.

jojoja

Hi vbs,

da habe ich hart gefailed. Das habe ich sehr wohl mitbekommen, Das neue Modul ist längst installiert, nur sollte man auch die Definitionen umstellen :D
Jetzt tuts!

Vielen Dank :D
FHEM 6.0 @ IntelNUC6CAYH;  Unifi USG, Switch, AP AC Pro; HM-MOD-UART;  Sonos Play 1 & 3, One, Beam; Philips Hue

vbs


Shojo

Zitat von: vbs am 02 Januar 2018, 14:49:31
Habe eine vbs17 gemacht, bei der keine HTTP-Anfragen angenommen werden, wenn weniger als 10kB Heap frei ist. Damit hatte ich jetzt keine Reboots mehr.

OK, werde dann heute meine Devices update und testen Danke Dir!
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

vbs

Sorry, ich glaube das war verfrüht mit der vbs17. Hatte gestern ein paar Reboots mit der Version :(

Ich habe aber heute den Code durchgeflöht und alle Debug-Strings vom RAM in den Flash-Speicher verschoben, was über 2 kB RAM frei gemacht hat. Außerdem SMING_RELEASE aktiviert und Debug-Logging komplett deaktiviert. Sollte evtl. etwas besseres Laufzeitverhalten und etwas RAM bringen.

Habe erstmal die Release-URL zurück auf vbs16 gedreht.
Auf der Testing-URL liegt jetzt eine vbs18b mit den o.g. Änderungen. Die hab ich bisher nicht zum Absturz bringen können. Hab ein gutes Gefühl :)

Per

Zitat von: vbs am 03 Januar 2018, 14:38:27alle Debug-Strings vom RAM in den Flash-Speicher verschoben
Wenn ich das richtig verstanden habe, hat der ESP eh nur zwei Speichertypen, ggü. den "älteren" Modellen mit 3. Ein Umlagern in den "Programmspeicher", um "Flash" zu sparen, kann also kontraproduktiv sein.

vbs

Zitat von: Per am 03 Januar 2018, 15:14:30
Ein Umlagern in den "Programmspeicher", um "Flash" zu sparen, kann also kontraproduktiv sein.
Geht ja im Gegenteil darum, RAM zu sparen und dafür mehr Flash zu nutzen. Inwiefern kontraproduktiv?

Blauhorn

Das Reading config-network-ap-password enthält das Passwort im Klartext. Kann man das irgendwie ändern?
1xBananaPi; 1x FB7490; 1xCUL433; 1x CC2530+CC2591; OpenMiLight-Gateway; 1xHMUART; HM-LC-Sw4-DR; Sonoff* mit TASMOTA, LEDController; MySensors; zigbee2mqtt;

vbs

Nein, momentan nicht. Bin da aber offen für Vorschläge. An welcher Ecke, siehst du denn da Probleme bzw. was genau möchtest du verhindern?

Blauhorn

Die Fhemweb-Oberfläche ist ja im Moment bei mir ungeschützt, so dass potenziell von jedem Device jedes Reading eingesehen werden kann, wenn man im WLAN  ist und den URL kennt. Nu will ich den Familienmitgliedern ja irgendwie eine Möglichkeit geben, die Devices (so Heizung, RGBW-Streifen usw.) in den eigenen Zimmern auch per Smartphone zu steuern. Ein Tablet mit Tablet-UI ist zwar denkbar, aber noch nicht über die Bedenkungsphase hinweg. Deswegen will ich hier entweder das Reading ausblenden können oder ich muss für die EspLedController und Sonoff-Schalter insgesamt ein anderes Passwort nehmen (admin und root-PWs waren bis hierhin alle gleich).
1xBananaPi; 1x FB7490; 1xCUL433; 1x CC2530+CC2591; OpenMiLight-Gateway; 1xHMUART; HM-LC-Sw4-DR; Sonoff* mit TASMOTA, LEDController; MySensors; zigbee2mqtt;

vbs

Hm, ok, da sehe ich verschiedene Punkte:

  • Das Reading "config-network-ap-password" enthält ja "nur" das Passwort für den AP, den der Controller aufspannt, wenn er sich nicht in dein normales Netz einwählen kann. Daher doch eigentlich in der Praxis nicht so kritisch, oder?
  • Ich bzw. man könnte das Reading ausblenden. Aber jeder mit FHEM-Zugriff kann aber auch per "set config" ein beliebiges anderes Passwort setzen (was er dann ja auch kennt).
  • Solange der Controller ungeschützt ist, kann jeder im Netzk (ohne FHEM) den Controller konfigurieren bzw. auch das Passwort ändern (über das Webinterface). Oder eben auch einfach das Passwort vom Controller erfragen.

Wenn du das wirklich absichern möchtest, müsstest du sowohl den Controller selber absichern als auch FHEM (mit Benutzerrollen o.ä.). Oder versteh ich etwas falsch?


Blauhorn

ZitatAber jeder mit FHEM-Zugriff kann aber auch per "set config" ein beliebiges anderes Passwort setzen (was er dann ja auch kennt).
Auweia, naklar, aber soweit war ich gedanklich ja noch gar nicht.

Zitat...müsstest du sowohl den Controller selber absichern als auch FHEM (mit Benutzerrollen o.ä.)
Ja, das wird die Lösung sein. Werd' dazu mal auf die Suche gehen.

Danke.
1xBananaPi; 1x FB7490; 1xCUL433; 1x CC2530+CC2591; OpenMiLight-Gateway; 1xHMUART; HM-LC-Sw4-DR; Sonoff* mit TASMOTA, LEDController; MySensors; zigbee2mqtt;

vbs

#389
<versehentlichen Post gelöscht>  :o