ESP RGBWW Wifi Led Controller - Firmware vbs

[vbs]

Getsernabend ist mir ja noch glatt einer raus gelaufen ein Slave Controller ging vor.

Also eine Erklärung Ausrede hätte ich jetzt im Angebot: Ich habe das heute versucht nachzustellen. Also zwei Controller über einen längeren Zeitraum synchron einen Fade durchlaufen lassen. Und es ist bei mir tatsächlich auch passiert, dass sie irgendwann nicht mehr synchron waren. Jedoch anders als gedacht: wie es der Zufall so wollte, hat zwischendurch meine Windows-Maschine (da drin läuft Linux-VM mit MQTT-Broker) neu gebootet. D.h. die Controller verlieren dann die MQTT-Verbindung und dann geht auch die Clock-Synchronisierung nicht mehr und die Controller fangen an, auseinander zu laufen. Das bekommt man so aber erstmal auch nicht mit. Gibt dann auch keinen Reconnect im Moment.

TLDR:
MQTT-Broker Neustart während Controller connectet sind: Controller nicht mehr synchron und müssen auch neu gestartet werden :/

EDIT:
Simmt gar nicht: es gibt eigentlich einen Reconnect... funktioniert aber offenbar nicht 
Kann das bei dir möglicherweise so ähnlich gewesen sein?

[Shojo]

 

Boahhhhh.... wadde mal..... ne mein MQTT-Brocker ist save!

Der läuft saubääär 

[hanswerner1]

Hallo vbs,

ich habe das Problem, das mit der aktuellen Version V18b das Ausschalten über das Modul LightScene nicht funktioniert.
Ich habe es mit off, dim 0 und auch val 0 versucht. Komisch ist, das es über das EspLedController Device selbst funktioniert.
Bis Version 14 klappte das auch noch wunderbar über LightScene, bei V18b und auch V16 leider nicht mehr.
Einschalten funktioniert, aber das Auschschalten nicht. Hab den Controller bereits mehrfach neu gestartet, auch über Spannung aus.

Gibt es eine Möglichkeit wieder auf V14 zu flashen ?

[ext23]

Moin,

weil ich das gerade lese, nochmal kurz zum Verständnis, den Broker braucht man für das Sync? Ich dachte die Dinger sprechen untereinander mit dem Master?!?

/Daniel

[vbs]

Gibt es eine Möglichkeit wieder auf V14 zu flashen ?

Ich denke, dass dein Problem eher nicht an der Firmware liegt, aber du kannst natürlich dir aus dem Git jegliche alte Firmware ziehen und ausprobieren. Hier die vbs14b:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/231256f1362056ed4c4aaefea92b9eb902975cd5/sming35

weil ich das gerade lese, nochmal kurz zum Verständnis, den Broker braucht man für das Sync? Ich dachte die Dinger sprechen untereinander mit dem Master?!?

Ja, stimmt beides. Ist das ein Widerspruch?

[ext23]

Ähh mhh, ich muss nochmal meine Frage lesen

Also Broker läuft doch auf einem Server, der Master sendet seine "Daten" an den Server und die Clients holen sich die Info vom Server, alles via MQTT.

Ich dachte jetzt, die Clients holen sich das vom Master, ohne das man ein Broker benötigt.

Oder geht beides, oder wie jetzt?!? Hintergrund meiner Frage ist, ich hab kein Broker installiert und warum soll man solche Daten Zentral sammeln, das ist doch meshed viel besser oder? Wobei meshed auch falsch ist weil es geht ja zumindest alles über den WLAN AP.

/Daniel

[vbs]

Also du willst MQTT ohne Broken machen? Oder einfach keine MQTT?

Es gibt ja einen Master und n Slaves. Darum ist es erstmal gut, dass der Master seine Daten nur einmal verschicken muss. Der Broker kümmert sich dann per Subscriptions um alles weitere.

[ext23]

Na ich möchte erst mal gar nichts, außer es verstehen. Von MQTT habe ich keine Ahnung da ich das nicht nutzte. Es ist also erst mal ein Verständnisproblem gewesen. Natürlich wäre es besser wenn die Clients direkt mit dem Master sprechen ohne einen Broker (Einen Rechner) als Durchlauferhitzer dazwischen. Aber ich richtig mich nach dem wie es derzeit läuft

/Daniel

[hanswerner1]

Ich denke, dass dein Problem eher nicht an der Firmware liegt, aber du kannst natürlich dir aus dem Git jegliche alte Firmware ziehen und ausprobieren. Hier die vbs14b:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/231256f1362056ed4c4aaefea92b9eb902975cd5/sming35

Kann ich die Version auch OTA downgraden ?
Hab den Kontroller hintern Schrank.

Komisch ist, das es bis zu der 14 Version klappt. Hatte schon mal auf die 16er geupdatet und das Problem festgestellt, konnte aber wieder zurück da unter Release noch die 14er war. Ich dachte das da bestimmt noch ein Bug drin ist. Bin dann vorgestern auf die 18b gegangen und da war das Problem direkt wieder. Bin dann wider auf Release 16 zurück und da ist das Problem auch. Irgendwas muss sich zwischen 14 und 16 geändert haben womit Lightscene beim Ausschalten nicht zurecht kommt.

[vbs]

Natürlich wäre es besser wenn die Clients direkt mit dem Master sprechen ohne einen Broker (Einen Rechner) als Durchlauferhitzer dazwischen.

Ist halt immer die Frage, in welcher Hinsicht "besser". Wenn man Kriterien wie Robustheit, Wartbarkeit oder Flexibilität dazu nimmt, ist es evtl. mit MQTT ganz gut.

@hanswerner1
Ja kannst du. Kannst du irgendwie rausfinden, welche Befehle genau sich jetzt bei dir anders verhalten? Im Endeffekt wird ja dein LightScene auch nur FHEM-Befehle aufrufen, oder?

[ext23]

Ist halt immer die Frage, in welcher Hinsicht "besser". Wenn man Kriterien wie Robustheit, Wartbarkeit oder Flexibilität dazu nimmt, ist es evtl. mit MQTT ganz gut.

Echt? Gerade deswegen doch nicht, mhh ich muss mir das mal anschauen, irgend was habe ich noch nicht ganz verstanden ^^

Ich werd mir jetzt erst mal so ein Broker installieren und dann schau ich mir das mit dem sync mal an. Hab mir erst mal noch schnell ein zweites Board zusammen gebraten.

/Daniel

[vbs]

Jo mach mal, sag Bescheid falls es irgendwo klemmt.

[vbs]

@Shojo:
Hab es gefunden (glaub ich) 
Ziemlich blöde Sache... signed/unsigned Fehler, der den Mechanismus getriggert hat, der dafür gedacht ist, zu bemerken wenn der Clock-Master neu gestartet wurde im Betrieb...

Hab eine vbs19b auf testing gelegt... bin mir ziemlich sicher, dass bei der das Syncing wasserdicht ist. Könntest du das nochmal testen bei dir?

Ich hab jetzt den Sync immer mit einem kleinen Script getestet weil das mit bloßem Auge irgendwie schwierig zu sehen ist:

Code Auswählen Erweitern

#!/bin/sh
wget -q -O - http://192.168.2.48/color;echo "" &
wget -q -O - http://192.168.2.49/color;echo "" &
wget -q -O - http://192.168.2.22/color;echo "" &


Sieht dann so aus:

Code Auswählen Erweitern


{"raw":{"r":0,"g":149,"b":267,"ww":40,"cw":0},"hsv":{"h":206.39,"s":87.00,"v":30.01,"ct":0}}
{"raw":{"r":0,"g":154,"b":267,"ww":40,"cw":0},"hsv":{"h":205.28,"s":87.00,"v":30.01,"ct":0}}
{"raw":{"r":40,"g":189,"b":307,"ww":0,"cw":0},"hsv":{"h":206.39,"s":87.00,"v":30.01,"ct":2700}}

"h" sollte dann eben recht ähnlich sein.  Bei 5 Sekunden pro 90° bewegt sich Hue mit 1,8° pro 100 ms. Also ein bisschen Abweichung bei den Werten ist ok imo.

[vbs]

Wenn du "color_interval_ms" auf "0" setzt, dann wird werden die Color-Nachricht komplett ausgeschaltet.

Das geht jetzt mit "-1" anstatt "0".

[ext23]

Nabend,

zwei Sachen:

Das mit dem OTA habe ich jetzt nochmal versucht von der vbs18b, da bleibt der stehen und hängt. Also da OTA Fenster geht nicht mehr weg.

Dann habe ich mein anderes Board was nackig war geflashed mit der rboot.bin der 0.3.0 (Da ich bei der vbs keine rboot gefunden habe)und der rom0.bin und spiff_rom.bin der vbs18b.
Danach wird der AP aber nicht aufgespannt, auch clr und reset hat nicht geholfen. Dann habe ich jetzt alles von der 0.3.0 genommen dann geht es. Damit werde ich den jetzt konfigurieren und dann auf die vbs flashen.

Liegt das mit dem OTA eventuell an der rboot? Habe ich da die falsche?

/Daniel