ACHTUNG:
Name und Update-URL für das FHEM-Modul hat sich geändert. Bitte folgende URL benutzen:
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txtName ist nun "EspLedController". Devices in FHEM müssen entsprechend umgestellt werden.
Es handelt sich hier um einen Fork von Patrick's (mrpj) Firmware für die Selbstbau-ESP-RGBWW-Controller von hier:
https://forum.fhem.de/index.php?topic=48918.0
Da ich die Firmware jetzt einige Wochen auf mehreren Controller bei mir betrieben habe und auch keine weiteren Problem aufgetaucht sind, würde ich die Firmware jetzt aus dem Status "experimentell" entlassen, da ich sie jetzt für ausreichend stabil halte.
Die Änderungen bzw. neuen Features an Firmware bzw. FHEM Modul sind hier zu finden:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#modifications
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#modifcations
FirmwareIch hab hier mal versucht, die Firmware zu beschreiben:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki)
Die URL zum Installieren der Firmware (über Webinterface) ist diese:
https://rgbww.dronezone.de/release/version.json (https://rgbww.dronezone.de/release/version.json)
Es gibt auch eine "Testing"-Variante mit evtl. noch nicht so gut erprobten Features (Tester willkommen!):
https://rgbww.dronezone.de/testing/version.json (https://rgbww.dronezone.de/testing/version.json)
Nach der Erstinstallation kann die Firmware später in FHEM mit dem Befehl "fw_update" aktualisiert werden:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-firmware-updates
FHEM ModulIch hab auch das FHEM-Modul angepasst, so dass die Features (alle?) auch direkt aus FHEM heraus verwendet werden können. Auch dazu hier ein bisschen Dokumentation:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki (https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki)
Um diese Version des Moduls von der Original-Version "32_LedController" unterscheiden zu können und damit beide Version auf einem System parallel betrieben werden können, heißt diese Version hier "32_EspLedController".
Das Modul kann als FHEM-Repository eingebunden und upgedatet werden:
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txtWer möchte, kann auch den develop-Kanal nutzen (neuer, aber weniger getestet):
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txtAchtung:
Bis Dez. 2017 hieß das Modul ebenfalls "32_LedController" und wurde nachträglich in "32_EspLedController" umbenannt. Der alte existiert im Git momentan noch, wird jedoch nicht mehr gepflegt. Also bitte auf den neuen Namen umstellen.
HinweiseDie Firmware und das FHEM-Modul sind als Einheit gedacht. Also es wird nicht bzw. schlecht funktionieren, die neue Firmware mit dem alten FHEM-Modul oder umgekehrt zu benutzen.
Wenn etwas nicht klappt, bitte Bescheid geben. Bitte dazu sagen, was genau gemacht wurde, was das erwartete Ergebnis war und Logausgaben posten.
Updateshttps://github.com/verybadsoldier/esp_rgbww_firmware/wiki#overview-of-modifications
Mit diesem Befehl können alle Controller upgedatet werden:
set TYPE=EspLedController fw_updateNach einem Upgrade von der Original-FW wird noch die alte Update-URL im Controller hinterlegt sein. Mit diesem Befehl lassen sich einmalig alle Controller auf die neue Update-URL setzen:
set TYPE=EspLedController config config-ota-url http://rgbww.dronezone.de/release/version.json
FlashenSeriell flashe ich mit folgendem Befehl:
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 out/firmware/rboot.bin 0x01000 /home/vbs/Projects/esp-open-sdk/sdk/bin/blank.bin 0x02000 out/firmware/rom0.bin 0x100000 out/firmware/spiff_rom.binDie Dateien (bis auf blank.bin) liegen auf der (fast) gleichen URL wie die version.json. Einfach den Dateinamen austauschen. Die blank.bin kann weg gelassen werden wenn nicht verfügbar.
SupportanfragenBei Supportanfragen bitte den Fehler bzw. die Umgebung ein bisschen beschreiben. Ich weiß, das macht etwas Arbeit, aber erleichtert die Analyse unheimlich. Hat es früher schonmal funktioniert? Seit wann tritt es auf? Was wurde am System geändert? Tritt es bei anderen Controllern evtl. nicht auf?
Bitte mindestens Folgendes angeben:
- Firmwareversion und Modulversion (bitte mit der neuesten Version gegenprüfen)
- list des Devices in FHEM
- verbose5-Log aus FHEM (hinreichend lang, bitte mehr als nur ein paar Sekunden)
- Beschreibung wie man das Problem reproduzieren kann
Man kann jetzt auch Firmware-Updates direkt aus FHEM heraus anstoßen.
Ich habe jetzt mal das geänderte FHEM Modul runtergeladen und das vorhandene mit dem neuen überschrieben. Nach einem Reload des Moduls konnte ich dann erfolgreich die Firmware des RGBWW Controllers auf die Entwicklerversion updaten. Prima!
Nach einem Neustart von FHEM, weil die ON/OFF Funktion via Lampensymbol in der FHEM Oberfläche nicht mehr ging (schaltete immer nur ein, aber nie aus und zeigte auch immer eine ausgeschaltete Birne) war dann allerdings mein LEDController Device ganz weg und ich bekam nur mehrere Fehlermeldungen beim Start, dass ich das Gerät doch bitte erst definieren soll. Das kam wohl von diversen NOTIFYs, die sich auf den jetzt verschwundenen Controller bezogen.
Es stellte sich nach Sichtung des Quelltextes heraus, dass das Moodul jetzt eine andere Definition des Devices verlangt. Entgegen der Fehlermeldung, die ich zunächst beim Versuch das Device wieder anzulegen erhielt, lautet die Syntax nicht "<name> LedController <type> <IP>" sondern es muss "<name> LedController <IP> <port>" sein und es müssen auch alle Parameter angegebn werden.
Damit konnte ich das Device dann wieder anlegen. Jetzt gibt es allerdings die vorher vorhandene ON/OFF Funktion via Glühbirnensymbol gar nicht mehr. Ist das so gewollt? Ich habe jetzt einfach eine Schaltfläche mit der Farbe Schwarz zum Abschalten hinzugefügt.
Mehr habe ich jetzt noch nicht ausprobiert, Farbe direkt setzen und einige Fades haben aber schon funktioniert.
Fernziel für mich ist es, den Controller für mein Aquarium einzusetzen. Dazu muss ich aber RGB und zwei Weißkanäle getrennt bedienen können, weshalb diese Firmware für mich interessant ist. Wie mir scheint, könnte ich das damit wohl umsetzen. Sonnenaufgang mit den RGB LEDs, dann langsam die beiden Weißkanäle aufdimmen und abends umgekehrt. Oder so ähnlich. Idealerweise kann ich den gesamten Tagesablauf einmal morgens auf dem Controller starten und muss danach nicht mehr eingreifen bis spät abends das Licht wieder aus ist.
Die Aquarienleuchte einfach als normale RGBWWCW Leuchte zu definieren geht nicht, weil ich für volle Helligkeit im Becken alle Kanäle gleichzeitig auf voller Leistung benötige, die normale Vorgehensweise die Helligkeit über alle Farben und Farbtemperaturen konstant zu lassen ist da nicht brauchbar. Für Wohnraumbeleuchtung ist das natürlich das richtige Verhalten, da erwartet man, dass die Helligkeit nicht von der Farbtemperatur abhängt.
Grüße
Markus
Zitat von: Mafi am 19 April 2017, 22:27:02
Es stellte sich nach Sichtung des Quelltextes heraus, dass das Moodul jetzt eine andere Definition des Devices verlangt. Entgegen der Fehlermeldung, die ich zunächst beim Versuch das Device wieder anzulegen erhielt, lautet die Syntax nicht "<name> LedController <type> <IP>" sondern es muss "<name> LedController <IP> <port>" sein und es müssen auch alle Parameter angegebn werden.
Danke für den Hinweise! Ich hab die Hilfe korrigiert und werde das auch im Wiki erwähnen.
EDIT:
War im Prinzip ein Bug... der Port war optional gedacht und sollte dann auf 9090 "defaulten"... also eigentlich keine Änderungen an der Defintion notwendig
/EDIT
Zitat von: Mafi am 19 April 2017, 22:27:02
Damit konnte ich das Device dann wieder anlegen. Jetzt gibt es allerdings die vorher vorhandene ON/OFF Funktion via Glühbirnensymbol gar nicht mehr. Ist das so gewollt? Ich habe jetzt einfach eine Schaltfläche mit der Farbe Schwarz zum Abschalten hinzugefügt.
Also die Befehle on/off sind vorhanden und sollten hoffentlich weiter funktionieren. Ich kann nicht genau sagen, was bei deinem Glühbirnensymbol passiert. Kannst du auf Befehle bezogen sagen, was nicht funktioniert bzw. das einmal mit Befehlen nachvollziehen? Ich vermute, dass ein Kommando "toggle" benötigt wird (oder eine andere Definition von webCmd). Werde ich mal hinzufügen bei Gelegenheit.
Zitat von: Mafi am 19 April 2017, 22:27:02
Fernziel für mich ist es, den Controller für mein Aquarium einzusetzen. Dazu muss ich aber RGB und zwei Weißkanäle getrennt bedienen können, weshalb diese Firmware für mich interessant ist. Wie mir scheint, könnte ich das damit wohl umsetzen. Sonnenaufgang mit den RGB LEDs, dann langsam die beiden Weißkanäle aufdimmen und abends umgekehrt.
Ich fürchte, da muss ich die enttäuschen: die hardwareseitigen Ausgänge sind genau so verknüpft wie mit der original Firmware. Also du kannst leider nicht die CW/WW-Kanäle getrennt von RGB steuern.
Was jetzt möglich ist, ist zB den Hue-Kanal zu kommandieren während zB der Helligkeitskanal einen Fade ausführt. Aber ich fürchte, dass dich das nicht wirklich weiter bringen wird.
Moin,
werden diese Fehlermeldungen in dem (neuen) Modul nun abgefangen?
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 958.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 959.
Vielleicht :) Ist wirklich einiges umgebaut und mir ist bisher nix aufgefallen. Wenns auftritt wirds gefixt ;)
Hey vbs,
da du derzeit viel Zeit mit der Firmware verbringst möchte ich hier die (vielleicht penetrante) Frage nach nem einfachen "stopp-Kommando" nochmal stellen.
Ich würde es wirklich schick finden, wenn ich eine laufende Animation einfach via stopp anhalten könnte.
Kannst du den Aufwand hierfür grob einschätzen? Hab mir die Firmware noch nicht so detailliert angesehen, außer damals zum Erstellen der Modul-Doku.
Gruß funclass
Jau, stop ist drin. Gibt auch pause, continue etc.:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#channel-animation-control (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#channel-animation-control)
Die Befehle können auch auf einzelne Kanäle beschränkt werden. Also du kannst zB auch nur den Fade des Hue-Kanals stoppen und den Helligkeitsfade weiterlaufen lassen.
Zitat von: vbs am 19 April 2017, 22:59:01
Danke für den Hinweise! Ich hab die Hilfe korrigiert und werde das auch im Wiki erwähnen.
EDIT:
War im Prinzip ein Bug... der Port war optional gedacht und sollte dann auf 9090 "defaulten"... also eigentlich keine Änderungen an der Defintion notwendig
/EDIT
Super!
Zitat von: vbs am 19 April 2017, 22:59:01
Also die Befehle on/off sind vorhanden und sollten hoffentlich weiter funktionieren. Ich kann nicht genau sagen, was bei deinem Glühbirnensymbol passiert. Kannst du auf Befehle bezogen sagen, was nicht funktioniert bzw. das einmal mit Befehlen nachvollziehen? Ich vermute, dass ein Kommando "toggle" benötigt wird (oder eine andere Definition von webCmd). Werde ich mal hinzufügen bei Gelegenheit.
Da müsste ich erst einmal nachsehen. Bisher war beim Anlegen eines LEDControllers diese ON/OFF Funktion mit dem Glühlampensymbol automatisch vorhanden, ich habe da nichts angelegt. Vermutlich löst das einen Toggle Befehl aus. Im Moment habe ich anstelle der Glühbirne "opened" da stehen und witzigerweise ist das anklickbar und schaltet das Licht ein. Nur aus geht es so nicht mehr. Da muss irgendwas durcheinander in meiner Definition sein...
Zitat von: vbs am 19 April 2017, 22:59:01
Ich fürchte, da muss ich die enttäuschen: die hardwareseitigen Ausgänge sind genau so verknüpft wie mit der original Firmware. Also du kannst leider nicht die CW/WW-Kanäle getrennt von RGB steuern.
Was jetzt möglich ist, ist zB den Hue-Kanal zu kommandieren während zB der Helligkeitskanal einen Fade ausführt. Aber ich fürchte, dass dich das nicht wirklich weiter bringen wird.
:( Schade. Dann hatte ich unter "Kanal" etwas falsches verstanden, nämlich die Hardwarekanäle und nicht die HSV Werte. Aber das Auftrennen und getrennt ansteuern der Hardwarekanäle ist ja in einem anderen Thread auch schon ein Thema gewesen, deshalb gebe ich Hoffnung nicht auf, dass es das irgendwann geben wird :)
Grüße
Markus
Zitat von: Mafi am 20 April 2017, 10:29:05
Da müsste ich erst einmal nachsehen. Bisher war beim Anlegen eines LEDControllers diese ON/OFF Funktion mit dem Glühlampensymbol automatisch vorhanden, ich habe da nichts angelegt. Vermutlich löst das einen Toggle Befehl aus. Im Moment habe ich anstelle der Glühbirne "opened" da stehen und witzigerweise ist das anklickbar und schaltet das Licht ein. Nur aus geht es so nicht mehr. Da muss irgendwas durcheinander in meiner Definition sein...
Früher hat das Reading "state" den Zustand on/off wiedergegeben. Jetzt nutzt das Modul DevIO zur Kommunikation mit dem Controller. DevIO nimmt implizit das Reading "state" in Beschlag und schreibt dort "openend" "disconnected" usw. rein. Ich vermute mal, dass das Lampensymbol "off" sendet, wenn es "on" entdeckt als state. Aber da es jetzt stattdessen "opened" entdeckt, wird es vermutlich einfach ein "toggle" schicken. Den Befehl "toggle" hab ich jetzt eingebaut, sollte dann also funktionieren.
Achso, hier ist die Modul-Dokumentation zu pause/stop/continue:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#new-commands (https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#new-commands)
Ist wahrscheinlich praxisrelevanter als die Firmware-Doku.
Hi,
kann ich das fhem Modul, über das FHEM Interface mit einem update add einbinden, wenn ja könntest welchen Befehl muss man absetzen(URL ??).
Gruß und Danke
Super Job
lewej
Hi,
ich hatte das bereits in dem Thread Modul (original) gefragt, im Webinterface ist MQTT als Reiter da, jedoch kann ich diesen nicht aktivieren. Muss ich da eine andere Firmware nutzen?
Gruß
lewej
Zitat von: lewej am 20 April 2017, 19:07:56
kann ich das fhem Modul, über das FHEM Interface mit einem update add einbinden, wenn ja könntest welchen Befehl muss man absetzen(URL ??).
Sorry, gibt es leider (noch) nicht.
Zitat von: lewej am 20 April 2017, 19:11:09
ich hatte das bereits in dem Thread Modul (original) gefragt, im Webinterface ist MQTT als Reiter da, jedoch kann ich diesen nicht aktivieren. Muss ich da eine andere Firmware nutzen?
MQTT ist bisher nicht implementiert. Ich hab aber in den letzten Tagen ziemlich viel damit rumgespielt und ausprobiert. An einigen Stellen leider mit recht ernüchternden Ergebnissen. Wofür würdest du MQTT bei dem Controller nutzen wollen?
Hi,
ich muss in der Küche drei Stück verbauen, dann welche im Wohnzimmer, jetzt ist unser EG sehr offen, deshalb muss ich die Controller irgendwie synchron bekommen. Man könnte jetzt zwar mit fhem mit notifys rum spielen, aber das ist zu langsam und damit schwindet der WAF :(.
Am liebsten wäre mir auch noch eine Variante, wo die Controller sich ohne FHEM oder MQTT mit einander unterhalten könnten (Multicast).
PS. Ich habe deine Firmware drauf und werde berichten.
Hi,
soweit funktioniert momentan alles.
Aus dem Wiki, das funktioniert:
set myLed hue 80 10 q:setHueAnim
set myLed hue 120 10 :setHueAnim
Aus dem Wiki, das funktioniert nicht:
set myLed +40,, 30 r
Unknown argument +40,,30, choose one of hsv rgb state update hue sat stop val dim dimup dimdown on off toggle raw pause continue blink skip config restart fw_update
Die Meldung ist ja klar, nur welchen Parameter muss man den da setzen?
Was mir auch nicht ganz klar ist, wie ich eine Disco animation setzen kann.
Sowas zum Beispiel:
- Fade von Farbraum blau bis rot
- Blinke einmal
- Fade anderen Farbraum
- blinke zweimal
- fade wieder
Ich habe noch milights momentan verbaut und die können verschiedene Disco und FADE Modes:
https://www.youtube.com/watch?v=ksm7ajNff3I (https://www.youtube.com/watch?v=ksm7ajNff3I)
Ich meine die Stelle 0:54min
Gruß
lewej
Firmware aus dem Develop Branch habe ich nun OTA auf einem meiner Controller drauf. Das angepasste FHEM-Modul lade ich grad in meine Testinstanz und dann probiere ich mal ein Wenig. Die Befehle im WiKi sehen auf jeden Fall extrem interessant aus. Ich werde berichten...
EDIT: hab grad bemerkt, dass das "original" FHEM-Modul mit der neuen Firmware nicht mehr so richtig sprechen will. Damit muss ich erstmal wieder die stable draufspielen und für die Tests einen "unkritischen" Controller aus der letzten Lieferung verwenden. Sonst kann ich meine Beleuchtung im Schlafzimmer nicht mehr ordentlich bedienen.
Zitat von: lewej am 20 April 2017, 19:51:58
ich muss in der Küche drei Stück verbauen, dann welche im Wohnzimmer, jetzt ist unser EG sehr offen, deshalb muss ich die Controller irgendwie synchron bekommen. Man könnte jetzt zwar mit fhem mit notifys rum spielen, aber das ist zu langsam und damit schwindet der WAF :(.
Versuch doch mal die vorhandene Slave-Funktion:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#slave-sync
Klappt mMn soweit gut. Nur bei langen Fades können die Controller anfangen auseinander zu laufen.
Zitat von: lewej am 20 April 2017, 19:51:58
Am liebsten wäre mir auch noch eine Variante, wo die Controller sich ohne FHEM oder MQTT mit einander unterhalten könnten (Multicast).
Wie würdest du in dem Fall die Controller steuern? Dann ausschließlich über das Webinterface?
Zitat von: funclass am 20 April 2017, 21:10:21
EDIT: hab grad bemerkt, dass das "original" FHEM-Modul mit der neuen Firmware nicht mehr so richtig sprechen will.
Bin ich gerade unsicher, was genau klappt denn da nicht? Mag aber durchaus so sein. Ich hätte aber gedacht, dass zumindest die Grundfunktionen noch kompatibel sein sollten.
Ich teste heute Abend mal etwas intensiver.
Umgekehrt scheint es problemlos zu klappen. Hab in meiner FHEM-Testinstanz dein develop-Modul eingebunden. Das kann die Controller mit Originalfirmware gut steuern.
Wie gesagt, mit nem Versuchsaufbau weiß ich später mehr.
Moin,
habe das Ganze nun auf einem Test-Controller an einem "Neben-FHEM" hängen. Scheint zu funktionieren, ABER:
2017.04.21 09:30:20.694 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:22.693 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1054}
2017.04.21 09:30:22.694 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:24.693 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1055}
2017.04.21 09:30:24.694 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:26.692 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1056}
2017.04.21 09:30:26.694 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:28.693 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1057}
2017.04.21 09:30:28.695 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:30.695 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1058}
2017.04.21 09:30:30.697 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:32.693 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1059}
2017.04.21 09:30:32.694 3: LedController_ProcessRead: Unknown message type: color_event
2017.04.21 09:30:34.693 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":263.99,"s":61.00,"v":17.99,"ct":2700},"id":1060}
2017.04.21 09:30:34.694 3: LedController_ProcessRead: Unknown message type: color_eventHabe ich noch irgendetwas vergessen?
Internals:
CFGFN
DEF 192.168.0.41
DeviceName 192.168.0.41:9090
FD 17
IP 192.168.0.41
LAST_RECV 1492759962.63104
NAME LED_Stripe_RGB
NR 45
NTFY_ORDER 50-LED_Stripe_RGB
PARTIAL
PORT 9090
STATE opened
TYPE LedController
Readings:
2017-04-21 09:17:40 config-color-brightness-blue 100
2017-04-21 09:17:40 config-color-brightness-cw 100
2017-04-21 09:17:40 config-color-brightness-green 100
2017-04-21 09:17:40 config-color-brightness-red 100
2017-04-21 09:17:40 config-color-brightness-ww 100
2017-04-21 09:17:40 config-color-colortemp-cw 6000
2017-04-21 09:17:40 config-color-colortemp-ww 2700
2017-04-21 09:17:40 config-color-hsv-blue 0
2017-04-21 09:17:40 config-color-hsv-cyan 0
2017-04-21 09:17:40 config-color-hsv-green 0
2017-04-21 09:17:40 config-color-hsv-magenta 0
2017-04-21 09:17:40 config-color-hsv-model 0
2017-04-21 09:17:40 config-color-hsv-red 0
2017-04-21 09:17:40 config-color-hsv-yellow 0
2017-04-21 09:17:40 config-color-outputmode 2
2017-04-21 09:17:40 config-network-ap-secured true
2017-04-21 09:17:40 config-network-ap-ssid RGBWW390730
2017-04-21 09:17:40 config-network-connection-dhcp false
2017-04-21 09:17:40 config-network-connection-gateway 192.168.0.1
2017-04-21 09:17:40 config-network-connection-ip 192.168.0.41
2017-04-21 09:17:40 config-network-connection-netmask 255.255.255.0
2017-04-21 09:17:40 config-network-mqtt-enabled false
2017-04-21 09:17:40 config-network-mqtt-port 0
2017-04-21 09:17:40 config-network-mqtt-server
2017-04-21 09:17:40 config-network-mqtt-username
2017-04-21 09:17:40 config-ota-url http://patrickjahns.github.io/esp_rgbww_firmware/release/version.json
2017-04-21 09:17:40 config-security-api_secured false
2017-04-21 09:29:15 info-deviceid 390730
2017-04-21 09:29:15 info-firmware 0.3.1-vbs1b
2017-04-21 09:29:15 info-mac a020a605f64a
2017-04-21 09:17:40 state opened
2017-04-21 09:32:16 tranisitionFinished
Helper:
isBusy 0
oldVal 0
cmdQueue:
Attributes:
room Flur
webCmd rgb
widgetOverride rgb:colorpicker,rgb Firmware auf dem Controller:
Zitat
Firmware: 0.3.1-vbs1b (v0.3.1-20-gd100-dirty)
Web Interface: 0.3.3
RGBWW Version: 0.8.1-vbs1b
SMING Version: 3.1.2
Zitat von: ComputerZOO am 21 April 2017, 09:36:59
Habe ich noch irgendetwas vergessen?
*knirsch* sorry, mein Fehler. Ich hab das FHEM-Modul upgedatet, aber die Firmware (auf der Update-URL) ist noch die alte. Darum kennt das FHEM-Modul die Nachricht nicht. Werde ich mal zeitnah updaten.
Also Workaround kannst du im FHEM-Modul in der Funktion "LedController_Read" die Zeilen:
# do stuff
if ( $obj->{method} eq "hsv_event" ) {tauschen gegen:
# do stuff
if ( $obj->{method} eq "color_event" ) {Also im Endeffekt nur "hsv_event" in "color_event" umbennen, dann sollte es wieder gehen.
Danke, schon besser.
2017.04.21 10:26:45.010 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2890}
2017.04.21 10:26:47.010 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2891}
2017.04.21 10:26:48.710 3: LED_Stripe_RGB: called SetHSVColor 150, 82, 37, 2700, 0, fade, single, 1, false, )
2017.04.21 10:26:48.963 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"transition_finished","params":{"name":""},"id":2892}{"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2893}{"jsonrpc":"2.0","method":"transition_finished","params":{"name":""},"id":2894}{"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2895}{"jsonrpc":"2.0","method":"transition_finished","params":{"name":""},"id":2896}
2017.04.21 10:26:49.012 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2897}{"jsonrpc":"2.0","method":"transition_finished","params":{"name":""},"id":2898}
2017.04.21 10:26:49.934 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":220.00,"s":83.97,"v":37.05,"ct":2700},"id":2899}{"jsonrpc":"2.0","method":"color_event","params":{"h":150.03,"s":82.01,"v":37.05,"ct":2700},"id":2900}
2017.04.21 10:26:51.010 3: LedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"h":150.03,"s":82.01,"v":37.05,"ct":2700},"id":2901}
Liegt das an der dev-Version? Ich würde sonst einfach den verbose auf 2 setzen, dann ist ja auch Ruhe ;)
Genau, das sind einfach Debugausgaben. Bei Bedarf entweder verbose runtersetzten oder bei der entsprechenden Zeile im Code den Level raufsetzen.
Zitat von: lewej am 20 April 2017, 21:08:01
Aus dem Wiki, das funktioniert nicht:
set myLed +40,, 30 r
Sorry ja, muss heißen:
set myLed
hsv +40,, 30 r
Ist im Endeffekt ein normaler hsv-Befehl, der einerseits einen relativen Wert verwendet (+40) und andererseits den sat- und val-Kanal auslässt (darum die beiden "leeren" Kommas).
Kann man auch schreiben als:
set myLed hue +40 30 r
(ist etwas eleganter direkt "hue" zu verwenden, wenn man sowieso nur vorhat, hue zu verändern)
Zitat von: lewej am 20 April 2017, 21:08:01
Was mir auch nicht ganz klar ist, wie ich eine Disco animation setzen kann.
Sowas zum Beispiel:
- Fade von Farbraum blau bis rot
- Blinke einmal
- Fade anderen Farbraum
- blinke zweimal
- fade wieder
Blinken kann momentan nocht nicht gequeuet werden, bin ich aber dran. Dann prinzipiell so (blink wegdenken):
set myLed hue 0 120 qr
set myLed blink qr
set myLed hue 120 120 qr
set myLed blink qr
set myLed blink qr
set myLed hue 180 120 qr
Das würde also in 120 s auf rot faden, dann blinken, dann in 120 s auf 120 (?) faden, dann zweimal blinken, dann in 120 s auf 180 faden und dann das Ganze wieder von vorn.
"q" bewirkt wie gewohnt, dass die Befehle in die Queue eingereiht werden (hinten). Das "r" ist neu und bewirkt, dass die Animation nach Beendigung wieder erneut in die Queue gepackt werden und damit loopen.
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#requeue-flag
Hi,
@VBS: Könntest du wie im Original fhem Modul, die normalen Readings wieder rein bringen, dann braucht man an seiner FTUI nichts ändern und man kann immer beide testen.
Diese Readings meine ich:
Gruß
lewej
Das ist ja ein Screenshot von der neuen Version. Welche Readings fehlen denn? Sollte eigentlich identisch sein bis auf ein paar Verwaltungssachen wie Firmwareversion etc.
Test 1:
FHEM-Modul aus develop Branch <-> LED-Controller mit aktuellster Original-FW
Ich bin mir nicht sicher ob diese Kombination überhaupt funktionieren soll, da einiges nicht so richtig läuft aber ein paar Dinge laufen.
Befehle on, rgb, hsv funktionieren. Die restlichen Befehle laufen nicht, vor allem lässt sich die LED nur per rgb 000000 oder hsv x,y,0 ausschalten. Off klappt nicht und toggle schaltet nur ein.
State bleibt immer bei disconnected und die üblichen Readings (val, hue, sat, hsv, rgb etc.) aktualisieren sich nur beim Setzen via hsv. RGB steuert zwar, lässt die Readings aber nicht aktualisieren. Update klappt auch nicht.
Die Kombi ist also nicht wirklich brauchbar.
Test 2:
FHEM-Modul aus develop Branch <-> LED-Controller mit Experimental-FW
Steuern klappt soweit ganz gut. Auch die neuen Befehle wie stop etc. Außer: ausschalten per off bzw. toggle geht bei mir nicht (echt seltsam, genau umgekehrt ggü. original-FW).
State steht sauber auf opened. Die üblichen Readings (val, hue, sat, hsv, rgb etc.) aktualisieren sich für mich jedoch nicht nachvollziehbar. Manchmal ändern sich die Werte, aber nicht beim Absetzen von Steuerbefehlen. Update klappt eben so wenig. Einziges Reading was sich zuverlässig aktualisiert ist tranisitionFinished (finde ich übrigens extrem cool).
Diese Kombi ist für den produktiven Einsatz also auch noch nicht zu empfehlen.
Test 3:
aktuelles master FHEM-Modul <-> LED-Controller mit Experimental-FW
Steuern des LED-Controller klappt gar nicht :(
Kann ihn weder ein, noch ausschalten geschweige denn irgendwelche Farben setzen. Die Readings werden zwar fleißig beim senden gesetzt, den Controller beeindruckt das jedoch herzlich wenig.
Außerdem habe ich bemerkt, dass im überarbeiteten FHEM-Modul die Werte für hsv (auch die Einzelwerte) als Gleitkommazahlen dargestellt werden z.B.: hsv 290.03,74.98,50.05.
EDIT: OK, hab gesehen, dass es beim Originalmodul auch schon der Fall ist.
Klasse, danke fürs testen. Es ist eigentlich so gedacht, dass man die Firmware auch mit dem neuen FHEM-Modul verwendet. Wobei es mich wundert, dass das alte Modul mit neuer FW (Test 3) gar nicht klappt. Hätte erwartet, dass das meiste geht. Hab es aber nie getestet. Wenn du magst, kannst du mal ein Log posten. Entweder finde ich noch nen Bug oder verstehe dann, warum es nicht klappen kann.
Test 2 ist natürlich relevant. Kannst du mal bitten ein Log posten, wie du eine Farbe setzt, wo dann die Readings nicht aktualisiert werden? Es ist jetzt nicht mehr so, dass das Modul schon selbst beim Absenden des Befehls das Reading auf den (hoffentlich) zukünftigen Wert setzt, sondern wirklich nur den Befehl an den Controller schickt. Der schickt dann von sich aus neue HSV-Werte, wenn sie sich tatsächlich ändern (sollten :D).
Mal händisch ein "update" absetzen wäre auch interessant.
Klar, mache ich nachher mal und poste die Logs. Den Update-Befehl hatte ich vorhin auch gesendet, leider ohne Effekt.
Zitat von: funclass am 21 April 2017, 19:20:43
Den Update-Befehl hatte ich vorhin auch gesendet, leider ohne Effekt.
Ja stimmt, hattest du ja auch geschrieben. Ich wollte eigentlich sagen, dass dazu ein Log auch super wäre.
Moin,
mir ist da auch etwas aufgefallen:
Ich betreibe gerade Testweise einen Controller mit einem RGB-Strip, das Outputmodel habe ich auf RGB gesetzt. Jetzt habe ich erwartet, das in diesem Fall die Farbmischung für die Farbe "weiß" FFFFFF ist, also alle drei Kanäle auf jeweils FF. Allerdings sind dann alle LEDs aus und es wird der CW-Kanal für die Ausgabe verwendet.
Hab nun mein Test-FHEM mal komplett leer gemacht und wollte den Controller neu anlegen. Nun schmiert FHEM direkt nach dem define immer mit folgender Meldung im Log ab:
Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 198.
Mehrfach getestet, ohne Erfolg. Selbst bei Verwendung der ursprünglichen FHEM-Config (wo das Testdevice schon drin war) schmiert FHEM beim Start ab.
Wenn ich das Original-Modul lade, kann ich das Device anlegen.
Zitat von: funclass am 21 April 2017, 20:55:00
Hab nun mein Test-FHEM mal komplett leer gemacht und wollte den Controller neu anlegen. Nun schmiert FHEM direkt nach dem define immer mit folgender Meldung im Log ab:
Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 198.
Mehrfach getestet, ohne Erfolg. Selbst bei Verwendung der ursprünglichen FHEM-Config (wo das Testdevice schon drin war) schmiert FHEM beim Start ab.
Wenn ich das Original-Modul lade, kann ich das Device anlegen.
Hilft dir evtl. das? https://forum.fhem.de/index.php/topic,55065.msg622835.html#msg622835
Zitat von: ComputerZOO am 21 April 2017, 20:28:38
Ich betreibe gerade Testweise einen Controller mit einem RGB-Strip, das Outputmodel habe ich auf RGB gesetzt. Jetzt habe ich erwartet, das in diesem Fall die Farbmischung für die Farbe "weiß" FFFFFF ist, also alle drei Kanäle auf jeweils FF. Allerdings sind dann alle LEDs aus und es wird der CW-Kanal für die Ausgabe verwendet.
Tritt bei mir so nicht auf. Du müsstest bitte mal sagen, wie genau du das gemacht hast.
Es wird immer seltsamer. Nun habe ich mein Test-FHEM komplett neu aufgesetzt (docker sei Dank mit recht wenig Aufwand).
Jetzt bekomme ich bereits beim Versuch das Modul zu laden folgende Meldung:
Too many arguments for main::RemoveInternalTimer at ./FHEM/32_LedController.pm line 120, near ""LedController_Check" )"
Ich werd wohl für heute erstmal abschließen. Ist irgendwie der Wurm drin.
@vbs: sobald ich wieder ein device angelegt bekomme, mache ich mich mal dran ein paar logs zu erzeugen.
Zitat von: vbs am 21 April 2017, 21:13:08
Tritt bei mir so nicht auf. Du müsstest bitte mal sagen, wie genau du das gemacht hast.
...später...
Mir ist da gerade ein ähnliches Problem wie von funclass in Post #35 aufgefallen:
- Device in FHEM angelegt -> funktioniert 1a.
- Nach einem shutdown restart von FHEM (oder auch nem kompletten Reboot des Pi) startet FHEM nicht mehr.
- Das in FHEM neu angelegte Device in der fhem.cfg händisch gelöscht -> FHEM startet wieder.
- Device wieder in FHEM angelegt -> Das Device funktioniert und lässt sich ansteuern.
- Neustart von FHEM -> Fehlanzeige, FHEM funktioniert nicht.
Zitat von: ComputerZOO am 21 April 2017, 21:33:08
...später...
Mir ist da gerade ein ähnliches Problem wie von funclass in Post #35 aufgefallen:
- Device in FHEM angelegt -> funktioniert 1a.
- Nach einem shutdown restart von FHEM (oder auch nem kompletten Reboot des Pi) startet FHEM nicht mehr.
- Das in FHEM neu angelegte Device in der fhem.cfg händisch gelöscht -> FHEM startet wieder.
- Device wieder in FHEM angelegt -> Das Device funktioniert und lässt sich ansteuern.
- Neustart von FHEM -> Fehlanzeige, FHEM funktioniert nicht.
Jupp, kann ich nun auch bestätigen. Hab mein "altes" Test-FHEM durch den Hinweis von thorwin wieder zum Laufen bekommen. Kann das device auch anlegen und nutzen. Aber nach shutdown leider kein restart... Gleicher Ablauf.
Logfiles sollte damit aber hinbekommen, jedoch nicht mehr heute.
Kein Problem, Hauptsache ist ja, dass du es bei dir direkt nachvollziehen kannst.
Zu meinem anderen Problem: die Firmware auf dem Controller speichert das geänderte Farbmodell nicht, dadurch ist das Verhalten des FHEM-Moduls wahrscheinlich korrekt.
Kann es sein, dass das etwas hiermit https://forum.fhem.de/index.php/topic,70882.0.html (https://forum.fhem.de/index.php/topic,70882.0.html) zu tun hat, das es nur beim Neustart passiert, weil im Ablauf des Starts von FHEM etwas nicht stimmt?
Zitat von: ComputerZOO am 21 April 2017, 21:46:31
Zu meinem anderen Problem: die Firmware auf dem Controller speichert das geänderte Farbmodell nicht, dadurch ist das Verhalten des FHEM-Moduls wahrscheinlich korrekt.
Hm, das ist ja unschön und ist dann zumindest ein Firmware-Thema. Klappt das bei dir denn mit der Original-Firmware? Kannst du mal bitte im Browser die Developer-Ansicht öffnen (F12) und dann das Speichern-Häkchen drücken? Dann sollte in der Netzwerk-Ansicht ein HTTP-Post auf "http://<IP>/config" zu sehen sein. Darauf die Antwort des Controllers wäre interessant zu sehen. Offenbar will der ja nicht speichern.
Zu dem FHEM-Restart kann ich leider nix sagen, da es bei mir funktioniert. Bitte mal Logausgaben posten. Kann sich ja wirklich um ein das verlinkte Problem handeln. Ich hab zumindest heute FHEM nicht geupdatet.
Zitat von: vbs am 21 April 2017, 22:33:18
Hm, das ist ja unschön und ist dann zumindest ein Firmware-Thema. Klappt das bei dir denn mit der Original-Firmware? ...
Ups, funktioniert mit der Original Firmware auch nicht :(
Dort ist es (scheinbar) (auch) nicht möglich das Farbmodell zu ändern (Firmware 0.3.1)
Doch, das sollte eigentlich gehen. Meins steht nämlich auf rgbww. Ich hatte bisher keine Probleme mit den "lokalen" Settings.
Zitat von: funclass am 21 April 2017, 23:07:14
Doch, das sollte eigentlich gehen. Meins steht nämlich auf rgbww. Ich hatte bisher keine Probleme mit den "lokalen" Settings.
Oha, noch nen Bug (Original-FW):
Stell doch mal bitte auf dem Controller unter System Settings -> Secure Settings Access an. Das dann mit Change und dem roten Button zum Speichern bestätigen. Dann in Color Settings -> Color das Output Model ändern und wieder versuchen zu speichern. Ich bekomme folgende Antwort:
{
"error": "missing password to secure settings"
}(mit der oben im Bild schon gezeigten Toast-Message)
Scheint wirklich ein Feature zu sein, was auch in der Original-FW nicht (bzw. noch nie) funktioniert hat. Hat offenbar auch bisher niemand vermisst bzw. habe ich bisher nicht mitbekommen.
Ich würde mich gerne erstmal darauf konzentrieren, die Änderungen rund zu machen. Also Bugs, die auch schon in der Original-FW bestanden haben, würde ich erstmal nach hinten stellen wollen...
Gab es schon Neuigkeit bzgl. des Verschwindens von Devices?
Werd heute aufgrund Geb. der Frau nicht zum Testen kommen. Ich finde auch, dass die Features so weit fit gemacht werden sollten bis es annähernd wie mit der org. FW läuft. Bisher hatte ich nämlich sehr stabilen Betrieb (wie viele Andere vermutlich auch).
Bugs die jetzt schon vorhanden sind scheinen nicht Priorität zu haben.
Moin,
die beiden experimentellen Controller laufen bei mir bisher auch ohne Probleme.
Etwas umständlich ist es gerade nur, wenn ich nen Neustart des FHEM mache, an dem diese beiden Devices hängen.
Vor dem shutdown restart die beiden Devices löschen, FHEM neu starten, Devices per Raw Definition per C&P wieder erstellen.
Hast du nicht mal Lust ein Log zu posten? Ohne Log bzw. konkrete Fehlermeldung sind mir ziemlich die Hände gebunden.
Zitat von: vbs am 22 April 2017, 18:35:33
Hast du nicht mal Lust ein Log zu posten? Ohne Log bzw. konkrete Fehlermeldung sind mir ziemlich die Hände gebunden.
Welches Log denn? Beim shutdown restart mit Verbose 5?
Am besten mal FHEM auf der Konsole starten. Wenn es dann abstürzt, dann sollte da irgendwas zu sehen sein. Falls im normalen Log etwas erwähnt wird, dann das natürlich auch gern.
Hmm, jetzt muss ich mal blöd fragen, welches Log?
sudo /etc/init.d/fhem stop
sudo /etc/init.d/fhem start
Und dann den Inhalt von hier:
./log/fhem.save ?
Das normale Logfile gibt folgendes aus:
2017.04.22 21:06:24.197 1: Logfile cleared
2017.04.22 21:06:34.822 0: Server shutdown
2017.04.22 21:06:40.666 1: Including fhem.cfg
2017.04.22 21:06:40.752 3: telnetPort: port 7072 opened
2017.04.22 21:06:41.105 3: WEB: port 8083 opened
2017.04.22 21:06:41.338 2: eventTypes: loaded 765 events from ./log/eventTypes.txt
2017.04.22 21:06:41.392 3: WEBintern: port 8085 opened
2017.04.22 21:06:42.281 2: ESPEasy sys.doorpi.esp.bridge: Opening bridge on port tcp/8383 (v1.03)
2017.04.22 21:06:42.283 3: sys.doorpi.esp.bridge: port 8383 opened
2017.04.22 21:06:42.309 1: PERL WARNING: Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66, <$fh> line 240.
2017.04.22 21:06:42.309 1: PERL WARNING: Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66, <$fh> line 240.
2017.04.22 21:06:42.332 1: PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 409, <$fh> line 240.
2017.04.22 21:06:42.333 1: PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 413, <$fh> line 240.
Undefined subroutine &main::DevIo_OpenDev called at ./FHEM/32_LedController.pm line 91, <$fh> line 240.
2017.04.22 21:08:37.273 1: Including fhem.cfg
2017.04.22 21:08:37.357 3: telnetPort: port 7072 opened
2017.04.22 21:08:37.707 3: WEB: port 8083 opened
2017.04.22 21:08:37.938 2: eventTypes: loaded 765 events from ./log/eventTypes.txt
2017.04.22 21:08:37.993 3: WEBintern: port 8085 opened
2017.04.22 21:08:38.697 2: ESPEasy sys.doorpi.esp.bridge: Opening bridge on port tcp/8383 (v1.03)
2017.04.22 21:08:38.698 3: sys.doorpi.esp.bridge: port 8383 opened
2017.04.22 21:08:38.723 1: PERL WARNING: Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66, <$fh> line 240.
2017.04.22 21:08:38.724 1: PERL WARNING: Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66, <$fh> line 240.
2017.04.22 21:08:38.747 1: PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 409, <$fh> line 240.
2017.04.22 21:08:38.747 1: PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 413, <$fh> line 240.
Undefined subroutine &main::DevIo_OpenDev called at ./FHEM/32_LedController.pm line 91, <$fh> line 240.
Ich glaube ich schreibe mir nen Notify, welches die Devices bei nem Shutdown löscht und beim Restart wieder neu anlegt :-)
Mit den Scripten wird FHEM als Service im Hintergrund gestartet. Beende FHEM bitte mal und dann starte es direkt in einer Konsole im Vordergrund. Irgendwie so:
perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
Pfade musst du evtl. für dich anpassen.
Wie sieht denn das Logfile aus, wenn das passiert? Normalerweise ist da auch eine entsprechende Meldung zu sehen.
Sehr eigenartig:
Das Logfile ist definitiv vorhanden!
Ohne es getestet zu haben wird sich FHEM beim Neustart beenden, weil ein "use DevIo" fehlt. Das tritt wohl nur beim Neustart auf, weil ein Modul, das später geladen wird, es importiert.
I have no f**king clue ?
PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 409, <$fh> line 240.
PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 413, <$fh> line 240.
Undefined subroutine &main::DevIo_OpenDev called at ./FHEM/32_LedController.pm line 91, <$fh> line 240.
Und nun?
Super Erklärung, macht total Sinn! Das isses bestimmt. Hatte ich gar nicht dran gedacht. Ich dachte irgendwie, dass DevIo standardmäßig geladen wird. Großes Dankeschön!
Anbei mal eine Version zum Testen bitte.
:-*
LÄUFT !!!!!
Gerne. Die Warnung bzgl. LedController_Set Prototype wird verschwinden, wenn Du sie am Anfang des Moduls einmal mit "sub LedController_Set(@);" deklarierst. Ebenfall ungestet.
Da stehe ich jetzt schon wieder auf'm Schlauch ???
Zitat von: dev0 am 22 April 2017, 21:52:33
Gerne. Die Warnung bzgl. LedController_Set Prototype wird verschwinden, wenn Du sie am Anfang des Moduls einmal mit "sub LedController_Set(@);" deklarierst. Ebenfall ungestet.
Wo und vor allem wie soll ich das deklarieren?
Ist das hier gemeint, was dann verschwindet?:
2017.04.22 21:52:10.681 1: PERL WARNING: Use of uninitialized value $requeue in concatenation (.) or string at ./FHEM/32_LedController.pm line 1326.
2017.04.22 21:52:10.682 1: PERL WARNING: Use of uninitialized value $doRequeue in concatenation (.) or string at ./FHEM/32_LedController.pm line 1011.
2017.04.22 21:52:10.682 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/32_LedController.pm line 1011.
PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 409, <$fh> line 240.
PERL WARNING: main::LedController_Set() called too early to check prototype at ./FHEM/32_LedController.pm line 413, <$fh> line 240.
Diese Meldung meinte ich und wollte eigentlich vbs mit meinem Kommentar ansprechen.
Edit: Formatierung korrigiert, blödes Tablet ;)
Klasse, macht Sinn, nochmals danke an dev0!
Mir ist da noch etwas aufgefallen, im RGB-Colorpicker wird die Farbe nicht mehr aktualisiert, wenn ich sie setzte (z.B. über ne LightScene)
Es dauert bis zu einer Minute bis sich das Modul mit dem Controller verbindet, erst dann bekommt es die Color-Events (state=opened). Du sagst der Colorpicker aktualisiert sich nicht. Heißt das, dass der Rest (zB die RGB-Glühbirne und die normale Readingsanzeige) sich aber aktualisiert?
Internals:
DEF 192.168.0.41
DeviceName 192.168.0.41:9090
FD 14
IP 192.168.0.41
LAST_RECV 1492893098.93892
NAME fl.esp.rgb.decke.1
NR 35
NTFY_ORDER 50-fl.esp.rgb.decke.1
PARTIAL
PORT 9090
STATE on
TYPE LedController
Readings:
2017-04-22 21:58:00 colorMode raw
2017-04-22 21:58:00 config-color-brightness-blue 100
2017-04-22 21:58:00 config-color-brightness-cw 100
2017-04-22 21:58:00 config-color-brightness-green 100
2017-04-22 21:58:00 config-color-brightness-red 99
2017-04-22 21:58:00 config-color-brightness-ww 100
2017-04-22 21:58:00 config-color-colortemp-cw 6000
2017-04-22 21:58:00 config-color-colortemp-ww 2700
2017-04-22 21:58:00 config-color-hsv-blue 0
2017-04-22 21:58:00 config-color-hsv-cyan 0
2017-04-22 21:58:00 config-color-hsv-green 0
2017-04-22 21:58:00 config-color-hsv-magenta 0
2017-04-22 21:58:00 config-color-hsv-model 0
2017-04-22 21:58:00 config-color-hsv-red 0
2017-04-22 21:58:00 config-color-hsv-yellow 0
2017-04-22 21:58:00 config-color-outputmode 0
2017-04-22 21:58:00 config-network-ap-secured false
2017-04-22 21:58:00 config-network-ap-ssid RGBWW390730
2017-04-22 21:58:00 config-network-connection-dhcp false
2017-04-22 21:58:00 config-network-connection-gateway 192.168.0.1
2017-04-22 21:58:00 config-network-connection-ip 192.168.0.41
2017-04-22 21:58:00 config-network-connection-netmask 255.255.255.0
2017-04-22 21:58:00 config-network-mqtt-enabled false
2017-04-22 21:58:00 config-network-mqtt-port 0
2017-04-22 21:58:00 config-network-mqtt-server
2017-04-22 21:58:00 config-network-mqtt-username
2017-04-22 21:58:00 config-ota-url http://patrickjahns.github.io/esp_rgbww_firmware/release/version.json
2017-04-22 21:58:00 config-security-api_secured false
2017-04-22 21:58:00 ct 2700
2017-04-22 21:58:00 hsv 300,100,100
2017-04-22 21:58:00 hue 300
2017-04-22 21:58:00 info-deviceid 390730
2017-04-22 21:58:00 info-firmware 0.3.1-vbs1b
2017-04-22 21:58:00 info-mac a020a605f64a
2017-04-22 21:58:00 rgb ff00ff
2017-04-22 21:58:00 sat 100
2017-04-22 21:58:00 state opened
2017-04-22 21:58:00 stateLight on
2017-04-22 22:32:03 tranisitionFinished
2017-04-22 21:58:00 val 100
Helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
alias RGB-Strip 1
cmdIcon on:taster_ch_an_gruen off:taster_ch_aus_rot pause:rc_PAUSE stop:rc_STOP continue:rc_PLAY
defaultRamp 500
devStateIcon off:light_light_dim_00:on on:light_light_dim_100@green:off
icon light_led_stripe_rgb
lightSceneParamsToSave rgb
room Flur
stateFormat stateLight
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
verbose undefined
webCmd pause:continue:stop:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ff00ff:rgb ffffff
widgetOverride rgb:colorpicker,rgb
Der Controller wurde zuvor per set fl.esp.rgb.decke.1 rgb 0000ff auf blau gesetzt, rgb im Reading steht aber weiterhin auf ff00ff
Kann es sein, dass das wieder diese hsv_event-Sache ist von gestern?
https://forum.fhem.de/index.php/topic,70738.msg623833.html#msg623833
Hast ja jetzt das 32_LedController.pm neu aufgespielt, also da heißt es wieder "hsv_event". Müsstest du nochmal anpassen. Könnte man im Log sehen, ob das das Problem ist.
Du könntest auch die Firmware nochmal updaten, dann passt wieder alles zusammen. Hab vorhin nochmal eine neue hochgeladen, kann jetzt auch MQTT.
set fl.esp.rgb.decke.1 fw_update http://rgbww.dronezone.de/testing/version.json
Nabend,
so ganz rund läuft die Kombi aus der neuen FW und dem Modul (mit geändertem do stuff (hsv_event -> color_event)) noch nicht:
Internals:
CFGFN
DEF 192.168.0.41
DeviceName 192.168.0.41:9090
IP 192.168.0.41
NAME fl.esp.rgb.decke.1
NEXT_OPEN 1492898642.70163
NR 69
NTFY_ORDER 50-fl.esp.rgb.decke.1
PARTIAL
PORT 9090
STATE on
TYPE LedController
Readings:
2017-04-23 00:04:12 colorMode raw
2017-04-23 00:04:12 ct 2700
2017-04-23 00:04:12 hsv 120,100,100
2017-04-23 00:04:12 hue 120
2017-04-23 00:04:01 info-deviceid 390730
2017-04-23 00:04:01 info-firmware 0.3.1-vbs3b
2017-04-23 00:04:01 info-mac a020a605f64a
2017-04-23 00:04:12 raw_blue 0
2017-04-23 00:04:12 raw_cw 0
2017-04-23 00:04:12 raw_green 1023
2017-04-23 00:04:12 raw_red 0
2017-04-23 00:04:12 raw_ww 0
2017-04-23 00:04:12 rgb 00ff00
2017-04-23 00:04:12 sat 100
2017-04-23 00:03:02 state disconnected
2017-04-23 00:04:12 stateLight on
2017-04-23 00:04:12 val 100
Helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
alias RGB-Strip 1
cmdIcon on:taster_ch_an_gruen off:taster_ch_aus_rot pause:rc_PAUSE stop:rc_STOP continue:rc_PLAY
defaultRamp 500
devStateIcon off:light_light_dim_00:on on:light_light_dim_100@green:off
icon light_led_stripe_rgb
lightSceneParamsToSave rgb
room Flur
stateFormat stateLight
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
verbose undefined
webCmd pause:continue:stop:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb ff00ff:rgb ffffff
widgetOverride rgb:colorpicker,rgb
Controller funktioniert und lässt sich über FHEM ansteuern, zeigt aber im state disconnected an, und die Farbe stimmt auch nicht.
Zitat von: ComputerZOO am 23 April 2017, 00:16:10
so ganz rund läuft die Kombi aus der neuen FW und dem Modul (mit geändertem do stuff (hsv_event -> color_event)) noch nicht:
Wenn du jetzt die aktuelle Firmware (vbs3b) und das aktuelle FHEM-Modul hast, dann darfst du die "hsv_model"-Änderung nicht machen (sonst passt das ganze wieder nicht) ;)
Solange state auf disconnected steht, wird nix gehen :( Evtl. ist der Event-Server deaktiviert. Mach mal bitte ein "get fl.esp.rgb.decke.1 config" und "get fl.esp.rgb.decke.1 info". Du solltest dann in FHEM eine ganze Reihe Readings bekommen, die mit "config-" anfangen (bzw. "info-") (bitte mal posten). Da gibts dann "config-events-server_enabled". Wenn der auf "0" stehen sollte, dann liegts daran. Falls das so ist, dann einschalten mit "set fl.esp.rgb.decke.1 config config-events-server_enabled 1". Danach restarten mit "set fl.esp.rgb.decke.1 restart".
Du musst immer mindestens 1 Minute warten, damit sich FHEM connectet, aber das hast du sicherlich gemacht oder?
Sorry, wird wohl heute nix mehr, Loredo hat mir den Feierabend nach nem FHEM-Update etwas versüßt >:(
Was ich aber jetzt schon sagen kann ist, das da etwas beim Firmware-Update des Controllers in die Hose gegangen ist. In der WebApp des Controllers sind z.B. die Felder für Calculation und Output Model leer, wenn ich sie befülle und dann versuche das ganze zu speichern, dann passiert nix und der Controller hängt sich auf und startet neu. Ne andere FW via OTA funktioniert auch nicht. Muss die Controller wohl ausbauen und neu Flashen.
Hm ist ja blöd, scheint der Wurm drin zu sein...
Kopf hoch, wird schon werden. Ich baue die Controller aus, Flashe die Originalversion drauf und probiere es dann noch mal. Nur kann ich nicht versprechen, ob das heute noch etwas wird. Der Witz ist ja, dass sich der Controller ansprechen lässt, bloß das er (fast) keine Readings liefert, geschweige denn diese aktualisiert. Bei get info, bzw. get config schmiert die Controller-Software scheinbar auch ab und macht nen Neustart, weil die LEDs kurz ausgehen, und dann wieder mit der letzen Farbe starten.
Sorry für die Mehrarbeit, aber keine Eile. Doof, dass ich das hier nicht nachstellen kann bzw. nicht selbst analysieren kann :/ Ich hab in den letzten zwei Wochen fast täglichen dutzende Male geflasht und nie Probleme gehabt :( hilft dir natürlich auch nicht weiter, ich weiß :/
Kannst ja sonst noch einmal aus FHEM heraus flashen und die Logs posten. Das sieht im Gutfall ungefähr so aus:
.
.
.
2017.04.23 18:04:39.197 3: wz_lightLedCouch: LedController_ParseFwUpdateProgress. status: 1
2017.04.23 18:04:40.350 3: wz_lightLedCouch: LedController_ParseFwUpdateProgress. status: 1
2017.04.23 18:04:42.347 3: wz_lightLedCouch: LedController_ParseFwUpdateProgress. status: 1
2017.04.23 18:04:43.370 3: wz_lightLedCouch: LedController_ParseFwUpdateProgress. status: 2
2017.04.23 18:04:43.370 3: wz_lightLedCouch: LedController_ParseFwUpdateProgress - Update successful - Restarting device...
Kleines Update:
Die Mehrarbeit scheint sich gelohnt zu haben.
- Ich habe die Controller weder ausgebaut, noch vom Strom getrennt. ;)
- Die aktuellste 32_LedController.pm hier aus dem Forum ins FHEM gepackt.
- Auf beiden Test-Controllern per WebApp nen Reset gemacht und neu eingerichtet.
- Beide Devices in FHEM gelöscht und neu angelegt.
= Resultat: funktioniert wie gewünscht mit allen Readings ("and all bell's and whistles attached").
Edit: shutdown restart funktioniert ebenfalls :) :)
Klasse, danke für die Rückmeldung! Ein bisschen bitterer Beigeschmack bleibt dennoch zurück :-\ Mal beobachten...
In den nächsten Tagen werde ich den nächsten Controller umflashen auf die
0.3.1-vbs3b (vbs2b-1-g80f0) hast du nen speziellen Wunsch, wie ich vorgehen soll und was ich für dich mitloggen sollte?
Also besondere Wünsche hab ich da erstmal nicht, danke. Mach wie du magst :)
Die Firmware kann jetzt MQTT nutzen, um mehrere Devices zu synchronisieren und um den aktuellen Status zu posten:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#mqtt
Die Devices können auch ihre Uhren synchronisierung per MQTT, um auch bei langen Fades synchron zu bleiben. Da sollten dann keine Abweichungen mehr auftreten (höchstens im Bereich von max. 50 ms). Also falls du da Interesse dran hast, dann gern einmal testen.
Ich bin ansonsten feature-mäßig erstmal durch so weit und würde jetzt erstmal eine Stabilisierungsphase einlegen. Das FHEM-Modul auf github im develop-Branch ist die aktuellste und die würde ich empfehlen zu testen.
Werde auch bald nochmal eine neue Firmware hochladen, aber die wird dann nur ein paar Bugfixes enthalten. Werde ich jetzt bei mir erstmal noch ein bisschen laufen lassen, um die ganz groben Schnitzer abzufischen ;)
Update vbs4b mit verbesserter Clock Synchronization
Hi,
wäre es möglich, in das Modul ein paar Disco une Lichtspiele hinterlegen zu lassen, das man nur noch
set device discomode1 30min sagen könnte.
Evtl. Direkt in den Kontroller, dann könnte man das Teil auch ohne Fhem betreiben.
Das wäre echt genial!
Gruss
Lewej
Kauf Dir besser eine Discokugel, einen Laser oder einen WS2812 Stripe.
Würde vorschlagen, solche Befehlsketten in 99_myUtils abzulegen. Oder einen alias zu benutzen (wobei dann wohl in dem alias das Device fest drin wäre).
Zitat von: dev0 am 26 April 2017, 16:47:38
Kauf Dir besser eine Discokugel, einen Laser oder einen WS2812 Stripe.
Meine Stripe sind in einer abgehängten Decke verbaut, meine Frage ist daher gerechtfertig.
Was ist mit langen Fades?
Oder wie könnte ich das am besten lösen?
Ich müsste ja irgendwo Zeiten hinterlegen, wie lange der Fade noch dauert, das ich den nächsten hinterher schicken könnte.
Nein, Befehl können "gequeuet" (geiles Wort) werden: https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#queueing-policy
Back queues konnte auch bereits die "reguläre" Firmware.
Hier im Wiki auch ein Beispiel für ein Farbspiel-Loop per Requeue-Flag:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#requeue-flag
Hi,
Hier mal das Foto:
(https://uploads.tapatalk-cdn.com/20170426/dd933fc3999a5a791756351880166fe9.jpg)
Links SMD
Einmal fertig, einmal alle Teile ausser CC1101 und Arduino
Rechts Konventionell
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 26 April 2017, 18:46:14
Hi,
Hier mal das Foto:
(https://uploads.tapatalk-cdn.com/20170426/dd933fc3999a5a791756351880166fe9.jpg)
Links SMD
Einmal fertig, einmal alle Teile ausser CC1101 und Arduino
Rechts Konventionell
Hmm, und was hat das jetzt mit dem RGBWW-Controller zu tun?
Sorry, mein Tapatalk war in der falschen Lasche. Bitte ignorieren!
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: vbs am 25 April 2017, 20:44:44
Update vbs4b mit verbesserter Clock Synchronization
Das habe ich, zusammen mit der aktuellen 32_LedController.pm, installiert und bis auf ein kleines Problem funktioniert alles gut:
Sobald ich das Web-Interface starte, rebootet der Controller in kurzen Abstaenden, ungefaehr alle 13 Sekunden.
-------------------------------
***** Software Watchdog Reset
================================================================
3ffff5c0: 3ffebb3f 00000020 0000ff00 4023fc79
[...]
timeout updating: 70 -> 65535
Server timeout updating: 40 -> 90
timeout updating: 70 -> 65535
RGBWW Controller v 0.3.1-vbs4b
Application::init - normal boot
-------------------------------
Das war, meine ich, bei Firmware-Version 0.3.1-vbs1b noch nicht der Fall; aber mit Sicherheit kann ich es nicht mehr sagen.
Gruss Helmut
Hm, passiert bei mir erstmal nicht. Abrufen der Webseite ist eigentlich nur eine Datei vom Controller runterladen. Also ich vermute, dass das SPIFFS Dateisystem einen weg hat... Hast du es per OTA oder seriell geflasht?
Heißt das, dass der Controller lief und dann hast du einmal im Browser die Seite angesteuert und seitdem bootet er im Kreis? Auch nach Power-Cycle? Was hat der Browser angezeigt? Kam die Seite noch?
Ich würde mal probieren nochmal neu zu flashen, evtl. auch mal seriell. Bei seriell drauf achten, dass hinterher der Bootloader auch den Boot-Slot startet, den du gerade geflasht hast.
Zitat von: vbs am 28 April 2017, 16:51:46
Hm, passiert bei mir erstmal nicht. Abrufen der Webseite ist eigentlich nur eine Datei vom Controller runterladen. Also ich vermute, dass das SPIFFS Dateisystem einen weg hat... Hast du es per OTA oder seriell geflasht?
Ich hatte per OTA geflasht und das sicherheitshalber zweimal wiederholt.
Zitat von: vbs am 28 April 2017, 16:51:46
Heißt das, dass der Controller lief und dann hast du einmal im Browser die Seite angesteuert und seitdem bootet er im Kreis?
Ganz genau.
Zitat von: vbs am 28 April 2017, 16:51:46
Auch nach Power-Cycle?
Nein, danach lief er wieder normal.
Zitat von: vbs am 28 April 2017, 16:51:46
Was hat der Browser angezeigt? Kam die Seite noch?
Die Seite kam noch, aber danach ging natuerlich nichts mehr.
Zitat von: vbs am 28 April 2017, 16:51:46
Ich würde mal probieren nochmal neu zu flashen, evtl. auch mal seriell.
Ich habe jetzt die rom0.bin und spiff_rom.bin seriell geflasht und seitdem ist die Welt wieder in Ordnung. Merkwuerdig, da es dieselben Dateien sind, die auch beim OTA mit Erfolgsmeldung drauf gekommen sind. Das habe ich allerdings nicht aus fhem heraus gemacht, sondern ueber das Web-Interface.
Ausserdem ist das nicht reproduzierbar. Ein zweifaches erneutes Flashen ueber das Web-Interface hinterlaesst auch einen funktionsfaehigen Controller.
Leider habe ich versaeumt, vor dem seriellen Flashen ein verify_flash zu machen.
Zitat von: vbs am 28 April 2017, 16:51:46
Bei seriell drauf achten, dass hinterher der Bootloader auch den Boot-Slot startet, den du gerade geflasht hast.
Du meinst diese Meldungen beim Booten?
"Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432"
Also alles wieder in Ordnung; da muss etwas beim ersten OTA schiefgegangen sein. Vielen Dank fuer Deine Hilfe.
Gruss Helmut
Zitat von: helmut am 29 April 2017, 18:32:03
Leider habe ich versaeumt, vor dem seriellen Flashen ein verify_flash zu machen.Du meinst diese Meldungen beim Booten?
"Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432"
Genau, der Controller hat ja zwei Boot-Slots. Welcher momentan verwendet wird, steht in der Config vom rboot (welche beim Flashen normalerweise unangetastet bleibt). Der übliche Flash-Befehl flasht aber immer in Slot 0. D.h. wenn gerade Slot 1 aktiv ist, dann wird das neue ROM nicht gebootet. Bei jedem OTA-Flash wird der aktive Bootslot immer einmal geswitcht.
Gut dass es erstmal geht... mal weiter beobachten...
Hallo Zusammen,
ich habe per OTA das Update eingespielt, danach rebootet. Nach dem Update ließ sich auf der Seite(webapp) nichts mehr speichern, also habe ich versucht, den ESP wieder mit der Original Firmware zu bespielen, das klappt auch, jedoch wird kein AP mehr aufgemacht. Hat jemand eine Idee, was ich noch machen kann?
esptool.py v2.0-beta2
Connecting.......................
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Flash params set to 0x0040
Compressed 2752 bytes to 1930...
Wrote 2752 bytes (1930 compressed) at 0x00000000 in 0.2 seconds (effective 124.5 kbit/s)...
Hash of data verified.
Compressed 339952 bytes to 239964...
Wrote 339952 bytes (239964 compressed) at 0x00002000 in 21.4 seconds (effective 126.9 kbit/s)...
Hash of data verified.
Compressed 786432 bytes to 218606...
Wrote 786432 bytes (218606 compressed) at 0x00100000 in 19.5 seconds (effective 322.6 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting...
Zitat von: lewej am 02 Mai 2017, 19:14:01
Hat jemand eine Idee, was ich noch machen kann?
Was bekommst Du denn mit einem Terminalprogramm wie screen o. ae. beim Booten des Controllers zu sehen?
Gruss Helmut
Zitat von: helmut am 02 Mai 2017, 19:29:07
Was bekommst Du denn mit einem Terminalprogramm wie screen o. ae. beim Booten des Controllers zu sehen?
Gruss Helmut
Hi ganz viel HEX und dann das
3fffff40: 3fffdc80 3fff4b38 3fff5790 4022797d
3fffff50: 3ffef1b0 0000019d 00000000 00000033
3fffff60: 00000002 0000001a 40215763 3fff03c0
3fffff70: 3ffef1a4 3fffdcc0 3ffec9c8 3ffec9c8
3fffff80: 402156d6 3fff03c0 00000000 3fff5c58
3fffff90: 3fffdc80 00000000 3fff4b38 402072cf
3fffffa0: 40000f49 3fffdab0 ffffff01 55aa55aa
================================================================
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 1948, room 16
tail 12
chksum 0x37
ho 0 tail 12 room 4
load 0x3ffe8000, len 772, room 12
tail 8
chksum 0x6c
csum 0x6c
rBoot v1.3.0 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: RTC data
Booting rom 0.
▒▒▒n▒{▒▒o|▒l$ld`▒▒r▒▒timeout updating: 70 -> 65535
Server timeout updating:0
5
b
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 0
AppWIFI::init dhcp
Application::startServices
APPLedCtrl::start
AppWIFI::_STAConnected reason - 1
Application::onWifiConnected
APPLedCtrl::onAnimationFinished
APPLedCtrl::colorSave
APPLedCtrl::onAnimationFinished
APPLedCtrl::colorSave
APPLedCtrl::onAnimationFinished
APPLedCtrl::colorSave
APPLedCtrl::onAnimationFinished
APPLedCtrl::colorSave
AppWIFI::_STAGotIP
Hi,
nach ca. 10 resets über die WEBUI, hat sich der Controller jetzt zurück gesetzt und speichert wieder die Einstellungen.
Was mich wundert, ist das er Updaten möchte?
Current
Firmware 0.3.1-vbs4b
Web Interface 0.3.3
OTA
Firmware 0.3.1-vbs4b
Web Interface 0.3.3
Die Versionsstände sind doch gleich, oder schaue ich falsch?
Zitat von: lewej am 02 Mai 2017, 20:08:51
nach ca. 10 resets über die WEBUI, hat sich der Controller jetzt zurück gesetzt und speichert wieder die Einstellungen.
Was mich wundert, ist das er Updaten möchte?
Die Versionsstände sind doch gleich, oder schaue ich falsch?
Hauptsache, er laeuft wieder. vbs hatte mir geraten, einfach nochmal seriell zu flashen - mit Erfolg.
Das "Update" mit gleichem Versionsstand sehe ich als Moeglichkeit, eine defekte Installation zu reparieren, aber da weiss vbs ganz sicher mehr zu sagen.
Gruss Helmut
Hallo,
@VBS
Könntest du evtl, im developer Brunch, die controls anpassen, dann könnte man sich die .pm Datei per Update ziehen. Momentan kommt die Meldungs die bytes nicht passen.
Got 61371 bytes for FHEM/32_LedController.pm, expected 50777
saving it to FHEM/32_LedController.pm.corrupt .
Gruß
lewej
Zitat von: lewej am 02 Mai 2017, 19:14:01
Hallo Zusammen,
ich habe per OTA das Update eingespielt, danach rebootet. Nach dem Update ließ sich auf der Seite(webapp) nichts mehr speichern, also habe ich versucht, den ESP wieder mit der Original Firmware zu bespielen, das klappt auch, jedoch wird kein AP mehr aufgemacht. Hat jemand eine Idee, was ich noch machen kann?
esptool.py v2.0-beta2
Connecting.......................
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Flash params set to 0x0040
Compressed 2752 bytes to 1930...
Wrote 2752 bytes (1930 compressed) at 0x00000000 in 0.2 seconds (effective 124.5 kbit/s)...
Hash of data verified.
Compressed 339952 bytes to 239964...
Wrote 339952 bytes (239964 compressed) at 0x00002000 in 21.4 seconds (effective 126.9 kbit/s)...
Hash of data verified.
Compressed 786432 bytes to 218606...
Wrote 786432 bytes (218606 compressed) at 0x00100000 in 19.5 seconds (effective 322.6 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting...
Hatte ich auch bei zwei von zwei Controllern, habe danach direkt einen Reset durchgeführt, danach liefen die Controller normal.
Greetz
Eldrik
Moin,
die Probleme hatte ich ebenfalls, dass der Controller nicht mehr speichern wollte, siehe hier im Thread ab Post #70 ff. Da hat auch nur nen Reset geholfen, ausbauen brauchte ich die Controller zum Glück nicht.
Sorry, ich kann leider nicht genau sagen, warum das passiert. Offenbar geht aber manchmal die Konfiguration zu Bruch. Vermutlich nur beim Updaten von Original-FW auf diese FW, kann es aber nicht versprechen. Werde es am WE nochmal versuchen zu reproduzieren.
Das Resetten der Konfiguration sollte eigentlich auch über den Clear-Button am Controller funktionieren. Einfach gedrückt halten und währenddessen einmal resetten. Dann sollte alles weg sein.
Zitat von: lewej am 02 Mai 2017, 20:08:51
Was mich wundert, ist das er Updaten möchte?
Current
Firmware 0.3.1-vbs4b
Web Interface 0.3.3
OTA
Firmware 0.3.1-vbs4b
Web Interface 0.3.3
Die Versionsstände sind doch gleich, oder schaue ich falsch?
Kommt drauf an :) Mir ist nicht so ganz klar, wo diese Ausgaben herkommen bzw. woher du weißt, dass er updaten möchte? Der Controller updatet eigentlich nie von sich aus, sondern immer nur nach dem update-Befehl.
Zitat von: vbs am 02 Mai 2017, 21:30:57
Sorry, ich kann leider nicht genau sagen, warum das passiert. Offenbar geht aber manchmal die Konfiguration zu Bruch. Vermutlich nur beim Updaten von Original-FW auf diese FW, kann es aber nicht versprechen. Werde es am WE nochmal versuchen zu reproduzieren.
Das Resetten der Konfiguration sollte eigentlich auch über den Clear-Button am Controller funktionieren. Einfach gedrückt halten und währenddessen einmal resetten. Dann sollte alles weg sein.
Kommt drauf an :) Mir ist nicht so ganz klar, wo diese Ausgaben herkommen bzw. woher du weißt, dass er updaten möchte? Der Controller updatet eigentlich nie von sich aus, sondern immer nur nach dem update-Befehl.
Das kommt wenn ich Update check ausführe.
Achso ok, das ist aber das normale Verhalten: man drückt "Update Check" und es werden einfach die beiden Versionsstände angezeigt. Wenn man möchte, kann man das dann aufspielen. Es gibt da aber keine Logik, die die Versionen vergleicht und ein Update empfiehlt. Bin mir recht sicher, dass das bei der Original-FW genauso ist.
Den Check gibt es nur wenn du über das FHEM-Modul per "fw_update" ein Update anstößt. In dem Fall wird es nur ausgeführt, wenn sich die Versionsstrings unterscheiden (oder force-Flag benutzt wurde):
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-firmware-updates
@VBS.
Ich versuche gerade synchron blinking lights zu machen, mit der normalen sync Methode kommt FHEM nicht hinter her. Jetzt würde ich das gerne mit der MQTT METHODE versuchen.
Wie bekomme ich die -vbs2b runtergeladen bzw. geflasht.
Oder hast eine IDee, wo ich was drehen könnte, damit da auch so funktioniert?
Gruß
lewej
Mit normaler Methode meinst du das Attribut slaves in FHEM? Ist eigentlich die schnellere Variante ggü. MQTT, da nicht erst wieder eine Nachricht zum Broker und dann zum zweiten Controller geschickt werden muss. Zeig doch mal Logs von FHEM inkl. Millisekunden, wenn du einen Befehl absetzt. Ist bei mir nur um ~2 ms verzögert. Ist jedoch auch ein i3 mit 3 GHz. Kann nicht sagen, wie groß die Latenz zB auf RPi ist. Wenn du einen Broker dazwischen setzt, wird die Latenz aber tendenziell eher größer.
Ansonsten kannst du MQTT versuchen, ist eigentlich auch schnell genug. Aber warum willst du dafür auf vbs2b zurück? Die Version findest du hier, aber ich würde vbs4b empfehlen:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/cce99b3e535a4c6c9bc663ecce0c69fb9ce2a161/testing
Zitat von: vbs am 02 Mai 2017, 22:03:36
Mit normaler Methode meinst du das Attribut slaves in FHEM? Ist eigentlich die schnellere Variante ggü. MQTT, da nicht erst wieder eine Nachricht zum Broker und dann zum zweiten Controller geschickt werden muss. Zeig doch mal Logs von FHEM inkl. Millisekunden, wenn du einen Befehl absetzt. Ist bei mir nur um ~2 ms verzögert. Ist jedoch auch ein i3 mit 3 GHz. Kann nicht sagen, wie groß die Latenz zB auf RPi ist. Wenn du einen Broker dazwischen setzt, wird die Latenz aber tendenziell eher größer.
Ansonsten kannst du MQTT versuchen, ist eigentlich auch schnell genug. Aber warum willst du dafür auf vbs2b zurück? Die Version findest du hier, aber ich würde vbs4b empfehlen:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/cce99b3e535a4c6c9bc663ecce0c69fb9ce2a161/testing
Hi,
ich habe hier einen NUC Atom mit einer SSD, ist sicherlich nicht so schnell wie ein I3, aber laut htop langweilt sich der Server.
Ich versuche folgende blinking light zu machen, ich weiß macht wenig Sinn, ich versuche nur heraus zu finden, wo die grenze liegt.
set WZTV_LED_Stripe hsv 0,, 10 r
set WZTV_LED_Stripe blink 0.3 qr
set WZTV_LED_Stripe hsv 240,, 30 qr
set WZTV_LED_Stripe hsv 300,, 20 qr
set WZTV_LED_Stripe hsv ,80, 40 r
set WZTV_LED_Stripe hsv ,20, 40 qrDer erste Controller blinkt wie verrückt :), der zweite macht nichts.
Das filelog vom fhem wächst im sekunden takt:
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER sat: 87.68
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER val: 100
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER ct: 2700
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER hsv: 272.38,87.68,100
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER rgb: 971fff
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER stateLight: on
2017-05-02_22:42:20 EG_KUECHE_SCHRANK_LEDCONTROLER colorMode: hsv
2017-05-02_22:42:21 WZTV_LED_Stripe hue: 275.95
2017-05-02_22:42:21 WZTV_LED_Stripe sat: 87.98
2017-05-02_22:42:21 WZTV_LED_Stripe val: 100
2017-05-02_22:42:21 WZTV_LED_Stripe ct: 2700
2017-05-02_22:42:21 WZTV_LED_Stripe hsv: 275.95,87.98,100
2017-05-02_22:42:21 WZTV_LED_Stripe rgb: a21fff
2017-05-02_22:42:21 WZTV_LED_Stripe stateLight: on
2017-05-02_22:42:21 WZTV_LED_Stripe colorMode: hsv
2017-05-02_22:42:21 WZTV_LED_Stripe hue: 275.72
2017-05-02_22:42:21 WZTV_LED_Stripe sat: 87.98
2017-05-02_22:42:21 WZTV_LED_Stripe val: 0
2017-05-02_22:42:21 WZTV_LED_Stripe ct: 2700
2017-05-02_22:42:21 WZTV_LED_Stripe hsv: 275.72,87.98,0
2017-05-02_22:42:21 WZTV_LED_Stripe rgb: 000000
2017-05-02_22:42:21 WZTV_LED_Stripe stateLight: off
2017-05-02_22:42:21 WZTV_LED_Stripe colorMode: hsv
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER hue: 269.38
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER sat: 87.49
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER val: 100
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER ct: 2700
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER hsv: 269.38,87.49,100
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER rgb: 8c20ff
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER stateLight: on
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER colorMode: hsv
2017-05-02_22:42:21 WZTV_LED_Stripe hue: 272.73
2017-05-02_22:42:21 WZTV_LED_Stripe sat: 87.78
2017-05-02_22:42:21 WZTV_LED_Stripe val: 0
2017-05-02_22:42:21 WZTV_LED_Stripe ct: 2700
2017-05-02_22:42:21 WZTV_LED_Stripe hsv: 272.73,87.78,0
2017-05-02_22:42:21 WZTV_LED_Stripe rgb: 000000
2017-05-02_22:42:21 WZTV_LED_Stripe stateLight: off
2017-05-02_22:42:21 WZTV_LED_Stripe colorMode: hsv
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER hue: 266.39
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER sat: 87.19
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER val: 100
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER ct: 2700
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER hsv: 266.39,87.19,100
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER rgb: 8121ff
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER stateLight: on
2017-05-02_22:42:21 EG_KUECHE_SCHRANK_LEDCONTROLER colorMode: hsv
Mit so einer QUEUE funktioniert es auf beiden Controllern, very happy, top.
set WZTV_LED_Stripe hsv 0,, 10 r
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv 240,, 20 qr
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv 300,, 20 qr
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv ,80, 40 r
set WZTV_LED_Stripe hsv ,20, 40 qr
Die Queue im oberen Thread scheint zu extrem zu sein, da ist wohl die Latenz Zeit vom WLAN ins spiel zu kommen, oder?
Gruß
lewej
Zitat von: vbs am 02 Mai 2017, 22:03:36
Mit normaler Methode meinst du das Attribut slaves in FHEM? Ist eigentlich die schnellere Variante ggü. MQTT, da nicht erst wieder eine Nachricht zum Broker und dann zum zweiten Controller geschickt werden muss. Zeig doch mal Logs von FHEM inkl. Millisekunden, wenn du einen Befehl absetzt. Ist bei mir nur um ~2 ms verzögert. Ist jedoch auch ein i3 mit 3 GHz. Kann nicht sagen, wie groß die Latenz zB auf RPi ist. Wenn du einen Broker dazwischen setzt, wird die Latenz aber tendenziell eher größer.
Ansonsten kannst du MQTT versuchen, ist eigentlich auch schnell genug. Aber warum willst du dafür auf vbs2b zurück? Die Version findest du hier, aber ich würde vbs4b empfehlen:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/cce99b3e535a4c6c9bc663ecce0c69fb9ce2a161/testing
Hi,
ich habe momentan die vbs4b installiert, aber der MQTT Reiter lässt sich nicht aktivieren, deshalb dachte ich mir, das wäre nur in der vbs2b drin.
Gruß
lewej
Zitat von: lewej am 02 Mai 2017, 22:50:17
Der erste Controller blinkt wie verrückt :), der zweite macht nichts.
...
Die Queue im oberen Thread scheint zu extrem zu sein, da ist wohl die Latenz Zeit vom WLAN ins spiel zu kommen, oder?
Wenn das Problem ist, dass der Slave-Controller einfach nix macht, dann kann das eigentlich nicht an der Latzen liegen.
Du müsstest mal sagen, was du eigentlich wie konfiguriert hast bzw. mal die Listings der Devices posten. Außerdem bitte mal Logs (inkl. Millisekunden). Das andere war nur der Event-Monitor.
Zitat von: lewej am 02 Mai 2017, 22:50:17
ich habe momentan die vbs4b installiert, aber der MQTT Reiter lässt sich nicht aktivieren, deshalb dachte ich mir, das wäre nur in der vbs2b drin.
Die Sache ist, dass ich einfach für die ganzen neuen Settings die Webseite (noch?) nicht angepasst habe. Einerseits weil ich es als sehr mühsam empfinde, HTML zu tippen und andererseits weil ich Probleme mit dem Webinterfach hatte, wenn ich es selbst "kompiliert" hatte. Evtl. findet sich ja jemand, der Lust die Webseit mal auf den neuesten Stand zu bringen.
In der vbs2b hatte ich mal einen wenig erfolgreichen Versuch drin.
Momentan würde ich empfehlen, sämtliche Konfiguration über FHEM vorzunehmen. Da sieht man alle Settings und kann auch alle ändern. Mit entsprechender devspec auch für mehrere Devices auf einmal:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
Hi,
was müsste ich einstellen, das die logs in millisekunden geschrieben werden?
Du musst das Attribut hier setzen:
https://fhem.de/commandref_DE.html#mseclog
Hi,
@vbs: Ich hab mal mit geschnitten.
2017.05.03 19:42:56.280 4: LedController_CheckConnection: Connection still alive. Last data received 30.0118491649628 s ago
2017.05.03 19:42:56.280 4: LedController_CheckConnection: Connection still alive. Last data received 30.0074088573456 s ago
2017.05.03 19:43:02.819 3: LedController_CheckConnection: Connection lost! Last data received 70.022078037262 s ago
2017.05.03 19:43:02.826 3: LedController_CheckConnection: Connection lost! Last data received 70.0191738605499 s ago
2017.05.03 19:43:02.849 3: LedController_CheckConnection: Connection lost! Last data received 70.0256350040436 s ago
2017.05.03 19:43:02.852 4: LedController_CheckConnection: Connection still alive. Last data received 10.0033299922943 s ago
2017.05.03 19:43:02.989 4: LedController_CheckConnection: Connection still alive. Last data received 10.0152819156647 s ago
2017.05.03 19:43:02.993 5: LedController_ArgsHelper: Time: | Q: front_reset | RQ: true | Name: | trans: solid | Ch:
2017.05.03 19:43:03.010 5: LedController_ArgsHelper: Time: | Q: front_reset | RQ: true | Name: | trans: solid | Ch:
2017.05.03 19:43:03.168 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:03.168 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:03.216 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:03.216 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:06.282 4: LedController_CheckConnection: Connection still alive. Last data received 40.014543056488 s ago
2017.05.03 19:43:06.283 4: LedController_CheckConnection: Connection still alive. Last data received 40.010146856308 s ago
2017.05.03 19:43:12.859 4: LedController_CheckConnection: Connection still alive. Last data received 20.0102500915527 s ago
2017.05.03 19:43:12.991 4: LedController_CheckConnection: Connection still alive. Last data received 20.0170228481293 s ago
2017.05.03 19:43:12.992 4: LedController_CheckConnection: Connection still alive. Last data received 9.99950194358826 s ago
2017.05.03 19:43:13.017 4: LedController_CheckConnection: Connection still alive. Last data received 10.0071079730988 s ago
2017.05.03 19:43:16.286 4: LedController_CheckConnection: Connection still alive. Last data received 50.0180032253265 s ago
2017.05.03 19:43:16.286 4: LedController_CheckConnection: Connection still alive. Last data received 50.0132670402527 s ago
2017.05.03 19:43:22.863 4: LedController_CheckConnection: Connection still alive. Last data received 30.0142939090729 s ago
2017.05.03 19:43:22.993 4: LedController_CheckConnection: Connection still alive. Last data received 30.0185618400574 s ago
2017.05.03 19:43:22.993 4: LedController_CheckConnection: Connection still alive. Last data received 20.0007889270782 s ago
2017.05.03 19:43:23.019 4: LedController_CheckConnection: Connection still alive. Last data received 20.0087168216705 s ago
2017.05.03 19:43:24.606 5: LedController_ArgsHelper: Time: 10000 | Q: single | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.615 5: LedController_ArgsHelper: Time: 10000 | Q: single | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.631 5: LedController_ArgsHelper: Time: 300 | Q: back | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.632 3: WZTV_LED_Stripe LedController_ForwardToSlaves: set EG_KUECHE_SCHRANK_LEDCONTROLER blink 0.3,qr
2017.05.03 19:43:24.633 5: LedController_ArgsHelper: Time: 300 | Q: single | RQ: | Name: | trans: fade | Ch:
2017.05.03 19:43:24.637 5: LedController_ArgsHelper: Time: 30000 | Q: back | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.640 5: LedController_ArgsHelper: Time: 30000 | Q: back | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.644 5: LedController_ArgsHelper: Time: 20000 | Q: back | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.646 5: LedController_ArgsHelper: Time: 20000 | Q: back | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.650 5: LedController_ArgsHelper: Time: 40000 | Q: single | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.651 5: LedController_ArgsHelper: Time: 40000 | Q: single | RQ: true | Name: | trans: fade | Ch:
2017.05.03 19:43:24.681 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:24.681 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:24.694 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:24.694 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:24.709 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:24.709 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:24.725 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:24.725 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:24.738 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:24.738 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:24.756 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:24.756 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:24.771 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:24.771 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:24.786 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:24.786 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:24.800 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:24.800 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:24.817 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:24.818 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:26.287 4: LedController_CheckConnection: Connection still alive. Last data received 60.0195360183716 s ago
2017.05.03 19:43:26.288 4: LedController_CheckConnection: Connection still alive. Last data received 60.0146899223328 s ago
2017.05.03 19:43:32.866 4: LedController_CheckConnection: Connection still alive. Last data received 40.0171129703522 s ago
2017.05.03 19:43:32.994 4: LedController_CheckConnection: Connection still alive. Last data received 40.020457983017 s ago
2017.05.03 19:43:32.995 4: LedController_CheckConnection: Connection still alive. Last data received 30.0031199455261 s ago
2017.05.03 19:43:33.020 4: LedController_CheckConnection: Connection still alive. Last data received 30.0100429058075 s ago
2017.05.03 19:43:36.291 3: LedController_CheckConnection: Connection lost! Last data received 70.0228161811829 s ago
2017.05.03 19:43:36.294 3: LedController_CheckConnection: Connection lost! Last data received 70.0209989547729 s ago
2017.05.03 19:43:42.709 5: LedController_ArgsHelper: Time: | Q: front_reset | RQ: true | Name: | trans: solid | Ch:
2017.05.03 19:43:42.718 5: LedController_ArgsHelper: Time: | Q: front_reset | RQ: true | Name: | trans: solid | Ch:
2017.05.03 19:43:42.868 4: LedController_CheckConnection: Connection still alive. Last data received 50.0187819004059 s ago
2017.05.03 19:43:42.894 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult
2017.05.03 19:43:42.894 4: EG_KUECHE_SCHRANK_LEDCONTROLER: LedController_ParseBoolResult success
2017.05.03 19:43:42.901 4: WZTV_LED_Stripe: LedController_ParseBoolResult
2017.05.03 19:43:42.901 4: WZTV_LED_Stripe: LedController_ParseBoolResult success
2017.05.03 19:43:42.996 4: LedController_CheckConnection: Connection still alive. Last data received 50.022057056427 s ago
2017.05.03 19:43:42.996 4: LedController_CheckConnection: Connection still alive. Last data received 40.0040709972382 s ago
2017.05.03 19:43:43.021 4: LedController_CheckConnection: Connection still alive. Last data received 40.0110709667206 s ago
Gruß
lewej
Moin.
Ich hab da ein Problem und ich hoffe hier richtig zu sein.
Ich habe die aktuelle master firmware auf den Controllern drauf. Funktionieren super! Vielen Dank für das Projekt!!
Allerdings stürzt mein WLAN öfter mal ab. Und die Controller verbinden sich erst nach einen Stromlos machen wieder neu. Gibt es einen reconnect in der firmware? Oder ist sowas nicht vorgesehen?
Kann ich irgendwo ein logfile auslesen der das Problem näher eingrenzt?
Gruß Alex
Zitat von: lewej am 03 Mai 2017, 19:45:12
@vbs: Ich hab mal mit geschnitten.
Danke, ich glaub ich hab da was gefunden. Sollte in der nächsten Version gefixt sein.
@AlexSchei
Würde das hier gerne erstmal auf Features bzw. Bugs im Umfeld der Firmwaremodifikation hier beschränken. Also für Bugs in der Original-FW bitte im normalen FW-Thread nachfragen.
Zitat von: vbs am 04 Mai 2017, 08:08:15
Danke, ich glaub ich hab da was gefunden. Sollte in der nächsten Version gefixt sein.
@AlexSchei
Würde das hier gerne erstmal auf Features bzw. Bugs im Umfeld der Firmwaremodifikation hier beschränken. Also für Bugs in der Original-FW bitte im normalen FW-Thread nachfragen.
Hi,
kannst du schon ein Release Datum nennen, würde gerne es wieder testen.
Gruß
lewej
Kannst mal diese Version hier probieren. Sollte eigentlich auch mit der (noch) aktuellen Firmware funktionieren.
Bei längeren Fades würde ich übrigens empfehlen, die Clock Synchronization per MQTT zu nutzen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#clock-synchronization
Zitat von: vbs am 04 Mai 2017, 19:49:39
Kannst mal diese Version hier probieren. Sollte eigentlich auch mit der (noch) aktuellen Firmware funktionieren.
Bei längeren Fades würde ich übrigens empfehlen, die Clock Synchronization per MQTT zu nutzen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#clock-synchronization
HI,
also es blinken jetzt beide, der SLAVE hat aber eine Verzögerung bei mir, von ca. 400ms
2017-05-04_21:11:28.483 WZTV_LED_Stripe hue: 313.14
2017-05-04_21:11:28.483 WZTV_LED_Stripe sat: 20.14
2017-05-04_21:11:28.483 WZTV_LED_Stripe val: 100
2017-05-04_21:11:28.483 WZTV_LED_Stripe ct: 2700
2017-05-04_21:11:28.483 WZTV_LED_Stripe hsv: 313.14,20.14,100
2017-05-04_21:11:28.483 WZTV_LED_Stripe rgb: ffccf4
2017-05-04_21:11:28.483 WZTV_LED_Stripe stateLight: on
2017-05-04_21:11:28.483 WZTV_LED_Stripe colorMode: hsv
2017-05-04_21:11:28.664 WZTV_LED_Stripe hue: 314.37
2017-05-04_21:11:28.664 WZTV_LED_Stripe sat: 20.14
2017-05-04_21:11:28.664 WZTV_LED_Stripe val: 0
2017-05-04_21:11:28.664 WZTV_LED_Stripe ct: 2700
2017-05-04_21:11:28.664 WZTV_LED_Stripe hsv: 314.37,20.14,0
2017-05-04_21:11:28.664 WZTV_LED_Stripe rgb: 000000
2017-05-04_21:11:28.664 WZTV_LED_Stripe stateLight: off
2017-05-04_21:11:28.664 WZTV_LED_Stripe colorMode: hsv
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER hue: 313.72
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER sat: 20.14
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER val: 100
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER ct: 2700
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER hsv: 313.72,20.14,100
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER rgb: ffccf4
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER stateLight: on
2017-05-04_21:11:28.819 EG_KUECHE_SCHRANK_LEDCONTROLER colorMode: hsv
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER hue: 314.72
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER sat: 20.14
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER val: 0
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER ct: 2700
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER hsv: 314.72,20.14,0
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER rgb: 000000
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER stateLight: off
2017-05-04_21:11:28.962 EG_KUECHE_SCHRANK_LEDCONTROLER colorMode: hsv
Ich bräuchte wie gesagt Logfiles und Listings der Device um dazu was sagen zu können.
Zitat von: vbs am 05 Mai 2017, 10:02:39
Ich bräuchte wie gesagt Logfiles und Listings der Device um dazu was sagen zu können.
Hi,
set WZTV_LED_Stripe hsv 0,, 10 r
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv 240,, 30 qr
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv 300,, 30 qr
set WZTV_LED_Stripe blink r
set WZTV_LED_Stripe hsv ,80, 80 r
set WZTV_LED_Stripe hsv ,20, 80
FD 13
IP ledcon-tvled.fritz.box
LAST_RECV 1494013281.54847
NAME WZTV_LED_Stripe
NR 128
NTFY_ORDER 50-WZTV_LED_Stripe
PARTIAL
PORT 9090
STATE opened
TYPE LedController
Readings:
2017-05-05 21:41:51 colorMode hsv
2017-05-05 21:41:19 config-color-brightness-blue 100
2017-05-05 21:41:19 config-color-brightness-cw 100
2017-05-05 21:41:19 config-color-brightness-green 100
2017-05-05 21:41:19 config-color-brightness-red 100
2017-05-05 21:41:19 config-color-brightness-ww 100
2017-05-05 21:41:19 config-color-colortemp-cw 6000
2017-05-05 21:41:19 config-color-colortemp-ww 2700
2017-05-05 21:41:19 config-color-hsv-blue 0
2017-05-05 21:41:19 config-color-hsv-cyan 0
2017-05-05 21:41:19 config-color-hsv-green 0
2017-05-05 21:41:19 config-color-hsv-magenta 0
2017-05-05 21:41:19 config-color-hsv-model 0
2017-05-05 21:41:19 config-color-hsv-red 0
2017-05-05 21:41:19 config-color-hsv-yellow 0
2017-05-05 21:41:19 config-color-outputmode 0
2017-05-05 21:41:19 config-events-color_interval_ms 500
2017-05-05 21:41:19 config-events-server_enabled true
2017-05-05 21:41:19 config-general-device_name WZTV_LED_Stripe
2017-05-05 21:41:19 config-network-ap-secured false
2017-05-05 21:41:19 config-network-ap-ssid RGBWW1501144
2017-05-05 21:41:19 config-network-connection-dhcp true
2017-05-05 21:41:19 config-network-connection-gateway 0.0.0.0
2017-05-05 21:41:19 config-network-connection-ip 0.0.0.0
2017-05-05 21:41:19 config-network-connection-netmask 0.0.0.0
2017-05-05 21:41:19 config-network-mqtt-enabled true
2017-05-05 21:41:19 config-network-mqtt-port 1883
2017-05-05 21:41:19 config-network-mqtt-server nuc.fritz.box
2017-05-05 21:41:19 config-network-mqtt-topic_base home/
2017-05-05 21:41:19 config-network-mqtt-username
2017-05-05 21:41:19 config-ota-url http://rgbww.dronezone.de/testing/version.json
2017-05-05 21:41:19 config-security-api_secured false
2017-05-05 21:41:19 config-sync-clock_master_enabled true
2017-05-05 21:41:19 config-sync-clock_master_interval 5
2017-05-05 21:41:19 config-sync-clock_slave_enabled false
2017-05-05 21:41:19 config-sync-clock_slave_topic home/led1/clock
2017-05-05 21:41:19 config-sync-cmd_master_enabled true
2017-05-05 21:41:19 config-sync-cmd_slave_enabled false
2017-05-05 21:41:19 config-sync-cmd_slave_topic home/led1/command
2017-05-05 21:41:19 config-sync-color_master_enabled true
2017-05-05 21:41:19 config-sync-color_master_interval_ms 30
2017-05-05 21:41:19 config-sync-color_slave_enabled false
2017-05-05 21:41:19 config-sync-color_slave_topic home/led1/color
2017-05-05 21:41:51 ct 2700
2017-05-05 21:41:51 hsv 0,0,0
2017-05-05 21:41:51 hue 0
2017-05-05 21:41:19 info-deviceid 1501144
2017-05-05 21:41:19 info-firmware 0.3.1-vbs4b
2017-05-05 21:41:19 info-mac a020a616e7d8
2017-05-05 21:41:19 raw_blue 0
2017-05-05 21:41:19 raw_cw 0
2017-05-05 21:41:19 raw_green 0
2017-05-05 21:41:19 raw_red 0
2017-05-05 21:41:19 raw_ww 0
2017-05-05 21:41:51 rgb 000000
2017-05-05 21:41:51 sat 0
2017-05-05 21:41:19 state opened
2017-05-05 21:41:51 stateLight off
2017-05-05 21:41:51 val 0
Helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
DbLogExclude .*
slaves EG_KUECHE_SCHRANK_LEDCONTROLER
userReadings HSV, RGB
verbose 5
webCmd rgb:rgb FFFFFF:rgb AFAFAF:rgb 7F7F7F:rgb 3F3F3F:rgb 0
widgetOverride rgb:colorpicker,HSV
FD 14
IP LEDCON-KUECHE2.fritz.box
LAST_RECV 1494013401.61176
NAME EG_KUECHE_SCHRANK_LEDCONTROLER
NR 131
NTFY_ORDER 50-EG_KUECHE_SCHRANK_LEDCONTROLER
PARTIAL
PORT 9090
STATE opened
TYPE LedController
Readings:
2017-05-05 21:43:44 clockCurrentInterval 19939
2017-05-05 21:43:44 clockSlaveOffset 1
2017-05-05 21:42:09 colorMode hsv
2017-05-05 21:41:21 config-color-brightness-blue 100
2017-05-05 21:41:21 config-color-brightness-cw 100
2017-05-05 21:41:21 config-color-brightness-green 100
2017-05-05 21:41:21 config-color-brightness-red 100
2017-05-05 21:41:21 config-color-brightness-ww 100
2017-05-05 21:41:21 config-color-colortemp-cw 6000
2017-05-05 21:41:21 config-color-colortemp-ww 2700
2017-05-05 21:41:21 config-color-hsv-blue 0
2017-05-05 21:41:21 config-color-hsv-cyan 0
2017-05-05 21:41:21 config-color-hsv-green 0
2017-05-05 21:41:21 config-color-hsv-magenta 0
2017-05-05 21:41:21 config-color-hsv-model 0
2017-05-05 21:41:21 config-color-hsv-red 0
2017-05-05 21:41:21 config-color-hsv-yellow 0
2017-05-05 21:41:21 config-color-outputmode 0
2017-05-05 21:41:21 config-events-color_interval_ms 500
2017-05-05 21:41:21 config-events-server_enabled true
2017-05-05 21:41:21 config-general-device_name EG_KUECHE_SCHRANK_LEDCONTROLER
2017-05-05 21:41:21 config-network-ap-secured false
2017-05-05 21:41:21 config-network-ap-ssid RGBWW1656767
2017-05-05 21:41:21 config-network-connection-dhcp true
2017-05-05 21:41:21 config-network-connection-gateway 0.0.0.0
2017-05-05 21:41:21 config-network-connection-ip 0.0.0.0
2017-05-05 21:41:21 config-network-connection-netmask 0.0.0.0
2017-05-05 21:41:21 config-network-mqtt-enabled true
2017-05-05 21:41:21 config-network-mqtt-port 1883
2017-05-05 21:41:21 config-network-mqtt-server nuc.fritz.box
2017-05-05 21:41:21 config-network-mqtt-topic_base home/
2017-05-05 21:41:21 config-network-mqtt-username
2017-05-05 21:41:21 config-ota-url http://rgbww.dronezone.de/testing/version.json
2017-05-05 21:41:21 config-security-api_secured false
2017-05-05 21:41:21 config-sync-clock_master_enabled false
2017-05-05 21:41:21 config-sync-clock_master_interval 5
2017-05-05 21:41:21 config-sync-clock_slave_enabled true
2017-05-05 21:41:21 config-sync-clock_slave_topic home/WZTV_LED_Stripe/clock
2017-05-05 21:41:21 config-sync-cmd_master_enabled false
2017-05-05 21:41:21 config-sync-cmd_slave_enabled true
2017-05-05 21:41:21 config-sync-cmd_slave_topic home/WZTV_LED_Stripe/command
2017-05-05 21:41:21 config-sync-color_master_enabled false
2017-05-05 21:41:21 config-sync-color_master_interval_ms 0
2017-05-05 21:41:21 config-sync-color_slave_enabled true
2017-05-05 21:41:21 config-sync-color_slave_topic home/WZTV_LED_Stripe/color
2017-05-05 21:42:09 ct 2700
2017-05-05 21:42:09 hsv 357.3,1.76,0
2017-05-05 21:42:09 hue 357.3
2017-05-05 21:41:21 info-deviceid 1656767
2017-05-05 21:41:21 info-firmware 0.3.1-vbs4b
2017-05-05 21:41:21 info-mac a020a61947bf
2017-05-05 21:41:22 raw_blue 0
2017-05-05 21:41:22 raw_cw 0
2017-05-05 21:41:22 raw_green 0
2017-05-05 21:41:22 raw_red 0
2017-05-05 21:41:22 raw_ww 0
2017-05-05 21:42:09 rgb 000000
2017-05-05 21:42:09 sat 1.76
2017-05-05 21:41:19 state opened
2017-05-05 21:42:09 stateLight off
2017-05-05 21:42:09 val 0
Helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
DbLogExclude .*
userReadings HSV, RGB
webCmd rgb:rgb FFFFFF:rgb AFAFAF:rgb 7F7F7F:rgb 3F3F3F:rgb 0
widgetOverride rgb:colorpicker,HSV
Hast du im Prinzip richtig konfiguriert, jedoch mit einem kleinen Haken: du nutzt alle drei Methoden zur Synchonisierung gleichzeitig, was so nicht funktionieren kann. Ich würde empfehlen nur MQTT-Command-Sync zu nutzen (mit Clock Sync). Also bei EG_KUECHE_SCHRANK_LEDCONTROLER config-sync-color_slave_enabled auf false setzen und bei WZTV_LED_Stripe das Attribut "Slaves" löschen. Danach einmal rebooten.
Habe rausgefunden, warum diese Probleme/Abstürze aufgetreten sind nach dem initialen Wechsel von der originalen FW auf diese hier. Sollte dann in der nächsten Version behoben sein.
Firmware und Modul aktualisiert auf vbs5b im ersten Post.
Sollte jetzt nicht mehr crashen und ein paar kleinere Features/Verbesserungen...
Zitat von: vbs am 06 Mai 2017, 14:06:14
Firmware und Modul aktualisiert auf vbs5b im ersten Post.
Servus,
habe gestern einen weiteren Controller samt LEDs verbaut und war so im Spieltrieb, dass ich das hier ausprobieren wollte ;D
Über die OTA URL (http://rgbww.dronezone.de/testing/version.json) wird noch vbs4b angeboten, oder ich weiß nicht, wie ich aktualisieren kann :o
Das Fhem Modul habe ich per update geladen - aber auch hier keine Ahnung, ob ich nun das aktuellste habe oder nicht. Die Version könnte hinkommen :-[
32_LedController.pm 0 2016-05-01 12:00:00Z herrmannjDanke fürs Weiterentwickeln :) :)
Grüße und Schönen Sonntag allen,
Andy
edit: mit dem oben gezeigtem Fhem Modul und der vbs4b Firmware bleibt der state bei mir auf jeden Fall dauerhaft auf disconnected. Muss ich noch irgendwas auf meinem Pi installieren, damit das funktioniert?
Zitat von: Andy89 am 07 Mai 2017, 10:48:13
Über die OTA URL (http://rgbww.dronezone.de/testing/version.json) wird noch vbs4b angeboten, oder ich weiß nicht, wie ich aktualisieren kann :o
Danke für den Hinweis! Habe ich doch glatt vergessen auf den Server zu pushen ^^ Sollte jetzt vbs5b kommen... sorry...
Zitat von: Andy89 am 07 Mai 2017, 10:48:13
Das Fhem Modul habe ich per update geladen - aber auch hier keine Ahnung, ob ich nun das aktuellste habe oder nicht. Die Version könnte hinkommen :-[
32_LedController.pm 0 2016-05-01 12:00:00Z herrmannj
edit: mit dem oben gezeigtem Fhem Modul und der vbs4b Firmware bleibt der state bei mir auf jeden Fall dauerhaft auf disconnected. Muss ich noch irgendwas auf meinem Pi installieren, damit das funktioniert?
Kannst du einmal das Modul händisch runterladen bitte? Oder einmal deine aktuelle Dateigröße angucken vorher, sollte eigentlich ~62162 Byte groß sein.
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/FHEM/32_LedController.pm
Evtl. klappt da was mit diesem FHEM-Update per controls.txt noch nicht...
Zitat von: vbs am 07 Mai 2017, 11:06:07
Danke für den Hinweis! Habe ich doch glatt vergessen auf den Server zu pushen ^^ Sollte jetzt vbs5b kommen... sorry...
Kannst du einmal das Modul händisch runterladen bitte?
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/FHEM/32_LedController.pm
Evtl. klappt da was mit diesem FHEM-Update per controls.txt noch nicht...
ja jetzt hab ich auch vbs5b ;D ;D
ähm jetzt habe ich mit vbs5b auch direkt eine Verbindung und die Updates kommen durch und der state steht auf opened ;) soll ich es trotzdem händisch nachladen?
andere Frage zu vbs5b: Die WebApp direkt im Browser zeigt "404 not found". Hat sich an dem Aufruf "http://192.168.xxx.xxx/webapp#" etwas geändert?
edit:
im Log steht noch relativ viele Dinge, die glaube ich nicht gewollt sind:
2017.05.07 11:11:06 3: WC_LED: encoded json data: {"hsv":{"h":"+0","v":"0","s":"+0"},"q":"single","d":"1","cmd":"fade","t":"700"}
Use of uninitialized value $time in concatenation (.) or string at ./FHEM/32_LedController.pm line 1360.
Use of uninitialized value $speed in concatenation (.) or string at ./FHEM/32_LedController.pm line 1360.
Use of uninitialized value $requeue in concatenation (.) or string at ./FHEM/32_LedController.pm line 1360.
Use of uninitialized value $name in concatenation (.) or string at ./FHEM/32_LedController.pm line 1360.
Use of uninitialized value $channels in concatenation (.) or string at ./FHEM/32_LedController.pm line 1360.
Use of uninitialized value $colorTemp in concatenation (.) or string at ./FHEM/32_LedController.pm line 1036.
Use of uninitialized value $doRequeue in concatenation (.) or string at ./FHEM/32_LedController.pm line 1036.
Use of uninitialized value $name in concatenation (.) or string at ./FHEM/32_LedController.pm line 1036.
2017.05.07 11:11:09 3: WC_LED: called SetHSVColor +0, +0, 0, , 700, fade, single, 1, , )
Zitat von: Andy89 am 07 Mai 2017, 11:08:49
andere Frage zu vbs5b: Die WebApp direkt im Browser zeigt "404 not found". Hat sich an dem Aufruf "http://192.168.xxx.xxx/webapp#" etwas geändert?
Nee, eigentlich nicht, aber da ist beim Bauen was schief gegangen... nochmals sorry :/ sollte nun behoben sein. Bitte nochmal Firmware updaten (man muss aber nun einmal mit force-Flag updaten, da die Version weiterhin vbs5b ist):
set TYPE=LedController fw_update 1Zitat von: Andy89 am 07 Mai 2017, 11:08:49
edit:
im Log steht noch relativ viele Dinge, die glaube ich nicht gewollt sind:
Ok danke, werde ich mal umbauen. Ist aber nix inhaltliches, sondern wird nur beim Erzeugen der Logausgaben ausgeprintet. Sollte natürlich trotzdem nicht im Log erscheinen.
kein Problem. Es ist eine Test-Firmware, also brauchst du dich auch für nichts entschuldigen! ;) :D Danke aber für das schnelle beheben des Fehlers! :)
Ich habe nun 4 Controller geupdatet, 3 davon sind auf opened, 1 bleibt leider auf disconnected. Update war bei allen auf jeden Fall erfolgreich. Bei dem, der nicht opened ist, habe ich es sogar nochmal manuell versucht, aber kein Erfolg. Es ist auf jeden Fall auch der Controller, der den schlechtesten Empfang hat und evtl sogar nen Wackler hat, da er ab und zu Mal kurz "blitzt". Meinst du, dass das disconnected evtl daher kommen könnte?
edit: und das ist auch der einzige Controller, bei dem die Configs nicht geladen werden ???
edit2:
2017.05.07 12:53:33 3: WZ_LED_Wohnwand: got config response
2017.05.07 12:53:33 2: WZ_LED_Wohnwand: error read from http://192.168.2.204:80 timed out retrieving config
Wenn er ab und zu kurz blinkt, dann vermute ich mal, dass er in einer Reboot-Schleife gefangen ist. Also bootet, direkt abstürzt und dann nach ein paar Sekunden das ganze von vorne.
Geht denn das Webinterface? Kannst du ihn aus FHEM heraus steuern? Mal probieren, ob ein ping längere Zeit stabil durchläuft.
Lief der vorher (mit der alten FW) stabil?
Zitat von: vbs am 07 Mai 2017, 13:03:27
Wenn er ab und zu kurz blinkt, dann vermute ich mal, dass er in einer Reboot-Schleife gefangen ist. Also bootet, direkt abstürzt und dann nach ein paar Sekunden das ganze von vorne.
Geht denn das Webinterface? Kannst du ihn aus FHEM heraus steuern? Mal probieren, ob ein ping längere Zeit stabil durchläuft.
Lief der vorher (mit der alten FW) stabil?
also das blinken ist nicht dauerhaft, eher ab und zu mal. steuern ist kein Problem, egal ob über FHEM oder das Web-Interface. Dadurch, dass ich den Controller länger nicht mehr anhatte, kann ich jetzt nicht genau sagen, ob er da auch schon evtl ab und zu mal geblinkt hat. Kann aber schon sein. Ich versuch mal den Ping Test.
edit: ok stabil läuft der auf jeden fall nicht:
103 packets transmitted, 93 packets received, 9.7% packet loss
round-trip min/avg/max/stddev = 4.267/21.079/1006.176/102.956 ms
Jedes mal wenn er blinkt, macht er vermtl. einen Reboot. Versuch mal einen Config-Reset, also CLR gedrückt halten und dann dabei einmal RESET drücken. Oder einmal seriell flashen.
Zitat von: vbs am 07 Mai 2017, 13:33:13
Jedes mal wenn er blinkt, macht er vermtl. einen Reboot. Versuch mal einen Config-Reset, also CLR gedrückt halten und dann dabei einmal RESET drücken. Oder einmal seriell flashen.
ich glaub es lag am ESP und meinen Lötkünsten. Das war einer der ersten LED Platinen noch aus der ersten Charge. Ich hab ihn nun durch eine von den neuen schwarzen Platinen ersetzt und das Flackern ist weg und er ist vom Status her direkt auf opened. Ich löt bei dem alten den ESP nach und werde es dann seriell flashen, sobald ich weiß, wo ich noch LEDs haben will ;D
Trotzdem danke!!!
Hab eine Version vbs6 gemacht. Enthält nur einen kleinen Fix, der vertauschte CW/WW-Kanäle behebt.
Hab mir mal erlaubt, dass "b" aus der Versionsbezeichnung zu streichen. Läuft bei mir jetzt seit längerem recht stabil.
Läuft seit längerem stabil bei mir und ich hab die Firmware jetzt mal dem experimentellen Status enthoben.
Hallo
recht vielen Dank für dieses tolle Modul, die Firmware und die viele Arbeit, die drin steckt.
Ich hab jetzt nach einiger Bastelarbeit und ein paar Experimenten das gesamte Konstrukt zum Laufen bekommen. Hab zwischen Original-FW/FHEM-Modul und der vbs-Version ein paar mal hin und her gewechselt.
Frage: wie genau bekomme ich MQTT enabled auf "true" gesetzt? Über die WebUI des Controllers geht es ja nicht, wegen inaktiv.
Aus FHEM heraus?: set ledrgbwwcontroller config <und dann?>
Alle Versuche sind bisher gescheitert, das Reading bleibt stur auf "0" stehen.
Kann mich mal bitte jemand vom Schlauch schubsen?
Gruß
blauhorn
Sollte funktionieren wie hier beschrieben:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
Die Config-Readings stellen immer auch den Namen dar, den man bei "get/set config" angeben kann. Also in deinem Fall:
set ledrgbwwcontroller config config-network-mqtt-enabled 1
Direkt danach einmal "get config" machen, dann solltest du den neuen Wert schon in den FHEM-Readings sehen:
get ledrgbwwcontroller config
Damit MQTT gestartet wird, dann allerdings noch einmal rebooten:
set ledrgbwwcontroller restart
Sehr toll, vielen Dank. Das hat geholfen.
Ich pack es mal hierrein, weil die Variante aus "Bestellung 2.5" keinen eigenen Firmware-Thread hat.
Ich habe öfter das Problem, dass mein WLAN schwach, gestört oder was auch immer ist. Oder der Router rebootet. Dann setzt sich der Controller zurück und spielt wieder AP. Reboote ich den Controller, hängt er sich wieder brav ins richtige Netz.
Besteht die Möglichkeit, im (automatischen, also nicht durch Reset erzwungenen) AP-Modus zu testen, ob das Netz wieder da ist und dann wieder automatisch zurückzukehren? Durch den aktuellen Bug in der ESP-Arduino IDE (der mich einige Nerven gekostet hat!) weiss ich, dass der ESP in der Lage ist, AP UND Client gleichzeitig zu sein. Ich weiss aber nicht, ob es programmtechnisch beherrschbar und vom Speicherplatz her möglich ist.
Moin.
@per: ich hab das selbe Problem. Meine Fritzbox macht das WLAN immer wieder mal aus. Dann ist der Controller nicht mehr verfügbar. Nur nach einem Stromlos machen ist er wieder da. Da leidet der WAF sehr dolle... ich hab mir zurzeit mit einem anderen Router geholfen. Mit dem 2.WLAN funktioniert das echt gut.
@vbs: den reconnect könnte ich auch gut brauchen. Eilt aber bei mir nicht, weil läuft mit dem 2. WLAN.
Geiles Projekt! Weiter so!
Viele Grüße
Alex
Also ich hatte bisher keine Problem. Aber es gibt durchaus einen Thread zur Original-FW. Ist hier zu finden:
https://forum.fhem.de/index.php/topic,70456.0.html (https://forum.fhem.de/index.php/topic,70456.0.html)
Zitat von: vbs am 17 Juni 2017, 11:15:11Aber es gibt durchaus einen Thread zur Original-FW.
Danke. Ich war mir sicher, dass es den gab, hatte ihn aber nicht wiedergefunden.
Hi,
@vbs: Ich habe die aktuelle Firmware drauf und das LedController ist aktuell. Bei mir stehen die Controller immer wieder mit STATE: disconnected, obwohl diese an sind und sich über Befehle steuern lassen.
Ist das Problem bekannt?
Gruss
lewej
Hm, nee ist mir eigentlich nicht bekannt. Kannst du bitte einmal per Telnet prüfen ob Port 9090 auf dem Controller Verbindungen annimmt? Und bitte einmal ein Device Listing posten. Danke!
Hallo,
also telnet geht!
list vom device:
Internals:
CFGFN /opt/fhem/fhem_wohnzimmer.cfg
DEF ledcon-tvled.fritz.box
DeviceName ledcon-tvled.fritz.box:9090
IP ledcon-tvled.fritz.box
NAME WZTVLEDSTRIPE
NEXT_OPEN 1499710241
NR 600
NTFY_ORDER 50-WZTVLEDSTRIPE
PARTIAL
PORT 9090
STATE disconnected
TYPE LedController
READINGS:
2017-07-11 20:15:43 colorMode raw
2017-07-11 20:23:49 config-color-brightness-blue 100
2017-07-11 20:23:49 config-color-brightness-cw 100
2017-07-11 20:23:49 config-color-brightness-green 100
2017-07-11 20:23:49 config-color-brightness-red 100
2017-07-11 20:23:49 config-color-brightness-ww 100
2017-07-11 20:23:49 config-color-colortemp-cw 6000
2017-07-11 20:23:49 config-color-colortemp-ww 2700
2017-07-11 20:23:49 config-color-hsv-blue 0
2017-07-11 20:23:49 config-color-hsv-cyan 0
2017-07-11 20:23:49 config-color-hsv-green 0
2017-07-11 20:23:49 config-color-hsv-magenta 0
2017-07-11 20:23:49 config-color-hsv-model 0
2017-07-11 20:23:49 config-color-hsv-red 0
2017-07-11 20:23:49 config-color-hsv-yellow 0
2017-07-11 20:23:49 config-color-outputmode 2
2017-07-11 20:23:49 config-events-color_interval_ms 500
2017-07-11 20:23:49 config-events-server_enabled 1
2017-07-11 20:23:49 config-general-device_name WZTV_LED_Stripe
2017-07-11 20:23:49 config-network-ap-secured 0
2017-07-11 20:23:49 config-network-ap-ssid RGBWW1501144
2017-07-11 20:23:49 config-network-connection-dhcp 1
2017-07-11 20:23:49 config-network-connection-gateway 0.0.0.0
2017-07-11 20:23:49 config-network-connection-ip 0.0.0.0
2017-07-11 20:23:49 config-network-connection-netmask 0.0.0.0
2017-07-11 20:23:49 config-network-mqtt-enabled 0
2017-07-11 20:23:49 config-network-mqtt-port 1883
2017-07-11 20:23:49 config-network-mqtt-server
2017-07-11 20:23:49 config-network-mqtt-topic_base home/
2017-07-11 20:23:49 config-network-mqtt-username
2017-07-11 20:23:49 config-ota-url http://rgbww.dronezone.de/testing/version.json
2017-07-11 20:23:49 config-security-api_secured 0
2017-07-11 20:23:49 config-sync-clock_master_enabled 1
2017-07-11 20:23:49 config-sync-clock_master_interval 5
2017-07-11 20:23:49 config-sync-clock_slave_enabled 0
2017-07-11 20:23:49 config-sync-clock_slave_topic home/led1/clock
2017-07-11 20:23:49 config-sync-cmd_master_enabled 1
2017-07-11 20:23:49 config-sync-cmd_slave_enabled 0
2017-07-11 20:23:49 config-sync-cmd_slave_topic home/led1/command
2017-07-11 20:23:49 config-sync-color_master_enabled 1
2017-07-11 20:23:49 config-sync-color_master_interval_ms 30
2017-07-11 20:23:49 config-sync-color_slave_enabled 0
2017-07-11 20:23:49 config-sync-color_slave_topic home/led1/color
2017-07-11 20:15:43 ct 2700
2017-07-11 20:15:43 hsv 0,0,25.02
2017-07-11 20:15:43 hue 0
2017-07-11 20:23:54 info-deviceid 1501144
2017-07-11 20:23:54 info-firmware 0.3.1-vbs6
2017-07-11 20:23:54 info-mac a020a616e7d8
2017-07-11 20:15:43 raw_blue 0
2017-07-11 20:15:43 raw_cw 256
2017-07-11 20:15:43 raw_green 0
2017-07-11 20:15:43 raw_red 0
2017-07-11 20:15:43 raw_ww 0
2017-07-11 20:15:43 rgb 404040
2017-07-11 20:15:43 sat 0
2017-07-10 20:09:41 state disconnected
2017-07-11 20:15:43 stateLight on
2017-07-11 20:15:43 val 25.02
helper:
isBusy 0
oldVal 25.02
cmdQueue:
Attributes:
group LEDCONTROLLER,TV
room System,Wohnzimmer
userReadings HSV, RGB
verbose 1
webCmd rgb:rgb FFFFFF:rgb AFAFAF:rgb 7F7F7F:rgb 3F3F3F:rgb 0
widgetOverride rgb:colorpicker,HSV
Versuch mal bitte eine IP anstelle des Hostnamen anzugeben.
Zitat von: vbs am 12 Juli 2017, 17:40:53
Versuch mal bitte eine IP anstelle des Hostnamen anzugeben.
Mit der IP, scheint es zu funktionieren, ich beobachte das Mal.
Gruß
lewej
Ja wird, daran liegen. Ist im Wiki auch so dokumentiert (https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#defining-the-fhem-device). Ich werde es aber nochmal deutlicher machen. Ist evtl. missverständlich.
Zitat von: lewej am 12 Juli 2017, 18:29:25
Mit der IP, scheint es zu funktionieren, ich beobachte das Mal.
Gruß
lewej
Hi,
@vbs: auch mit IP steht irgendwann disconnect, konnte es noch nicht engrenzen, wann es passiert.
Gruss
Lewej
Stell mal bitte auf verbose 4 und dann einmal die Definition ändern (damit er sich erstmal neu verbinden). Also zB. einmal auf DEF klicken und mit "modify" bestätigen. Und dann mal Log posten nachdem du so 10-15 Minuten hast laufen lassen.
Ich hab bereits unter dem Original FHEM-Modul meinen Vorschlag gepostet, will den aber auch hier noch unterbringen.
Ich hab eine Möglichkeit gefunden einen 4in1 RGB + WW LED Stripe ähnlich wie bei Philips Hue in der Farbtemperatur zu variieren. Meine aktuelle Umsetung ist Farbtechnisch sicherlich nicht korrekt aber sie funktioniert. Mit ein wenig Feintuning der Kurven würde man sicherlich ein noch besseres Ergebniss erzielen. Meine LEDs haben bei 100% WW laut Hersteller 3000 K. Ich habe nun eine Kurve für die Roten LEDs die bis 2000 K auf maximale Helligkeit eingestellt werden und eine zweite Funktion, welche bis 7000K alle RGB LEDs auf maximale Helligkeit einstellen. Zusätzlich wird die Helligkeit der WW LEDs von 3000 K - 7000 K um die Hälfe reduziert. Die Werte sind allerdings rein empirisch aufgenommen und entspricht somit nicht den exakten Werten. Ich verwende das ganze unter Anderem in Kombination mit den neuen Alexa Funktionen für die Farbtemperatur. Das ganze ist als cmdalias definiert.
set RGBW_.* ct .* AS {
my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;
if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};
if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);
fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}
Vielleicht kann damit ja jemand etwas anfangen oder es findet sich sogar ein Entwickler, welcher das in das FHEM Modul einbaut. Der Übergang zu Kaltweiß sieht m. M. nach sehr gut aus, in den wärmeren Bereich wird es bei direkter Betrachtung irgendwann etwas rotstichig.
Hab mal kleinere Verbesserungen am FHEM Modul vorgenommen (auch ein Crash-Fix dabei). Ich hoffe, dass die controls.txt passt! Sonst bitte Bescheid geben, danke!
Ohja, ich habe etwas, und zwar nen dickes Problem mit dem Update:
Illegal division by zero at ./FHEM/32_LedController.pm line 1203.
...danach stürzt FHEM ab.
Oh ja, sorry, passiert wenn man RGB #000000 setzt. Ist behoben, bitte nochmal updaten.
Zitat von: Pythonf am 13 Juli 2017, 18:42:52
Ich hab bereits unter dem Original FHEM-Modul meinen Vorschlag gepostet, will den aber auch hier noch unterbringen.
Ich hab eine Möglichkeit gefunden einen 4in1 RGB + WW LED Stripe ähnlich wie bei Philips Hue in der Farbtemperatur zu variieren. Meine aktuelle Umsetung ist Farbtechnisch sicherlich nicht korrekt aber sie funktioniert. Mit ein wenig Feintuning der Kurven würde man sicherlich ein noch besseres Ergebniss erzielen. Meine LEDs haben bei 100% WW laut Hersteller 3000 K. Ich habe nun eine Kurve für die Roten LEDs die bis 2000 K auf maximale Helligkeit eingestellt werden und eine zweite Funktion, welche bis 7000K alle RGB LEDs auf maximale Helligkeit einstellen. Zusätzlich wird die Helligkeit der WW LEDs von 3000 K - 7000 K um die Hälfe reduziert. Die Werte sind allerdings rein empirisch aufgenommen und entspricht somit nicht den exakten Werten. Ich verwende das ganze unter Anderem in Kombination mit den neuen Alexa Funktionen für die Farbtemperatur. Das ganze ist als cmdalias definiert.
set RGBW_.* ct .* AS {
my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;
if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};
if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);
fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}
Vielleicht kann damit ja jemand etwas anfangen oder es findet sich sogar ein Entwickler, welcher das in das FHEM Modul einbaut. Der Übergang zu Kaltweiß sieht m. M. nach sehr gut aus, in den wärmeren Bereich wird es bei direkter Betrachtung irgendwann etwas rotstichig.
Moin,
das würde ich mir gern für WifiLight ausleihen, allerdings bin ich nicht sicher ob ich verstehe.. EVTPART2, was ist K ?
Danke vg
joerg
das würde ich mir gern für WifiLight ausleihen, allerdings bin ich nicht sicher ob ich verstehe.. EVTPART2, was ist K ?
$EVTPART2 entspricht dem eingegebenen Wert in [K] (Kelvin, der Farbtemperatur) also 2000 bis 7000.
Das ganze wird mit 3 Geraden berechnet und beruht im Grunde auf folgender Zeichnung https://photos.app.goo.gl/u7OPmjihyZymkEXD3 (https://photos.app.goo.gl/u7OPmjihyZymkEXD3) (Die Formeln sind hier allerdings nicht korrekt, bitte die aus dem vorherigen Post verwenden).
Eventuell komm ich mal dazu, das ganze farbtechnische korrekter umzusetzen, dann würde ich das hier anfügen. Da ich gerade aber etwas im Prüfungstress bin kann das noch etwas dauern.
Grüße
Fabian
ah verstehe. Du mischst nicht einfach blau dazu sondern die "blaue" RGB Mischung im Tausch gegen Weiß. Clevere Idee!
Danke, vg
Joerg
Hallo,
wollte das fhem modul mit der entsprechenden firmware testen.
Wenn ich das modul entsprechend anleitung in fhem lade erhalte ich:
syntax error at ./FHEM/32_LedController.pm line 1203, near "= if"
kann mir hier jemand helfen.
Danke.
SG,
kamilo
Hi, zeig uns mal ein
list
mit den Versionen Deiner Module.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich vermute, dass du irgendwie nicht das richtige Modul hast. Eigentlich müsste es das hier sein, kannst du ja mal prüfen:
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/aa2fab3770bafb0d97aec1392ff808cf79e4a28d/FHEM/32_LedController.pm
Hallo zusammen,
vielen dank für die Rückmeldung.
EIch habe die Datei aus dem Link runtergeladen und nach ../../opt/fhem/FHEM kopiert. Rechte und Benutzer wurden aktualisiert.
Fehlerbild ist weiter das gleiche.
Gruß,
kamilo
Au weia, da muss ich mich schon wieder entschuldigen... :(
War einfach noch ein Fehler drin. Keine Ahnung warum das hier nicht direkt aufgefallen ist bzw. bis eben bei mir problemlos lief... muss ich wohl selber ein reload vergessen haben...
Bitte jetzt nochmal normal updaten, muss jetzt gehen! Sorry!
kein Problem :)
Upgedated auf vbs7
Zitat von: vbs am 06 August 2017, 12:21:53
Upgedated auf vbs7
Hallo VBS,
wollte gerade fhem updaten, aber die control.txt passt nicht zur der Datei, Bytes ist ungleich.
Wäre super wenn du es fixen könntest.
gruss
lewej
Oh sorry! Habs gerade gefixt, müsste jetzt gehen.
Zitat von: Pythonf am 13 Juli 2017, 18:42:52
Ich hab bereits unter dem Original FHEM-Modul meinen Vorschlag gepostet, will den aber auch hier noch unterbringen.
Ich hab eine Möglichkeit gefunden einen 4in1 RGB + WW LED Stripe ähnlich wie bei Philips Hue in der Farbtemperatur zu variieren. Meine aktuelle Umsetung ist Farbtechnisch sicherlich nicht korrekt aber sie funktioniert. Mit ein wenig Feintuning der Kurven würde man sicherlich ein noch besseres Ergebniss erzielen. Meine LEDs haben bei 100% WW laut Hersteller 3000 K. Ich habe nun eine Kurve für die Roten LEDs die bis 2000 K auf maximale Helligkeit eingestellt werden und eine zweite Funktion, welche bis 7000K alle RGB LEDs auf maximale Helligkeit einstellen. Zusätzlich wird die Helligkeit der WW LEDs von 3000 K - 7000 K um die Hälfe reduziert. Die Werte sind allerdings rein empirisch aufgenommen und entspricht somit nicht den exakten Werten. Ich verwende das ganze unter Anderem in Kombination mit den neuen Alexa Funktionen für die Farbtemperatur. Das ganze ist als cmdalias definiert.
set RGBW_.* ct .* AS {
my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;
if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};
if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);
fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}
Vielleicht kann damit ja jemand etwas anfangen oder es findet sich sogar ein Entwickler, welcher das in das FHEM Modul einbaut. Der Übergang zu Kaltweiß sieht m. M. nach sehr gut aus, in den wärmeren Bereich wird es bei direkter Betrachtung irgendwann etwas rotstichig.
Hallo,
Ich steuere meine leds auch über die Hue, sprich wenn die Farbe sich an der hue,
ändert dann wird über ein notify das ändern der leds getriggert.
Ich würde jetzt gerne deine Lösung nutzen wollen, brauche ich dafür nur den oberen
Code, oder noch mehr?
Gruss
lewej
Der obere Code als "cmdalias" sollte reichen. Wenn was nicht geht einfach mal die Readings in einem Dummy testen und natürlich muss gelten, dass deine Devices mit "RGBW_" beginnen. Die Farbberechnung ist wie gesagt nicht exakt, da nicht logarithmisch etc.. aber dafür find ich sieht es recht gut aus.
Beste Grüße
Fabian
Zitat von: Pythonf am 04 Oktober 2017, 20:47:50
Der obere Code als "cmdalias" sollte reichen. Wenn was nicht geht einfach mal die Readings in einem Dummy testen und natürlich muss gelten, dass deine Devices mit "RGBW_" beginnen. Die Farbberechnung ist wie gesagt nicht exakt, da nicht logarithmisch etc.. aber dafür find ich sieht es recht gut aus.
Beste Grüße
Fabian
Ich versteh gerade nicht, wie ich das nutzen kann. Ich hab mehrere Stripes, die heissen alle LEDCON_n+1.
Wenn ich jetzt am LEDCON1 die Farbe ändere, wo muss ich jetzt den cmdalias aufrufen.
Könntest du evtl. eine exemplarische definition von zwei LED Controllern, hier anhängen?
gruss
lewej
Du musst nur das alias entsprechen ändern:
set LEDCON_.* ct .* AS
und dann mit "set LEDCON_n+1 ct 5000" eine Farbtemperatur setzen.
Zitat von: vbs am 04 Oktober 2017, 23:36:15
Du musst nur das alias entsprechen ändern:
set LEDCON_.* ct .* AS
und dann mit "set LEDCON_n+1 ct 5000" eine Farbtemperatur setzen.
Ok, aber ich dachte genauso das sollte automatisch gehen.
Ich ändere ja die Farben nicht in Fhem, sondern über die hue app an der hue bloom. Fhem pollt alle 5s die Readngs der Hue Bridge.
Dann werden per notify die anderen leds angpasst, das funktioniert erstmal.
Jedoch passen die Farben nicht immer, jetzt wollte ich diese funktion nutz n.
Weiss aber nicht an welcher Stelle und diese aufgerufen werden soll.
Ich will ja nicht jedes Mal die Farbtemperatur raussuchen.
Oder denke ich an dieser Stelle zu kompliziert?
Gruss
Lewej
Du erstellt ein neues Device
define LECOND_ct_cmdalias cmdalias set LEDCON_.* ct .* AS {
my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;
if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};
if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);
fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}Damit wird der "set LEDCON_.* ct .." bei allen Geräten dessen Namen eben so anfängt
überschrieben und der Code nach dem AS ausgeführt. Damit funktioniert eine grobe Steuerung der Farbtemperatur ähnlich wie bei HUE Geräten. Allerdings ist das ganze nicht exakt, da es auf auf 3 geraden basiert, die ich kurz mal gezeichnet und mit qtiplot gefittet habe. Eventuell werd ich mir mal anschaun, wie das korrekt geht. Damit du nun deine HUE und die RGBWW (! nur für RGB + WW sinnvoll !) synchroniesieren kannst würde ich ein einfache notify verwenden:
notify HUEDevice.:ct:.* {my $temp = $EVTPART2;
$temp =~ tr/0-9//dc; fhem("set LEDCON_.* ct $temp "); }[EDIT]
Ich hab es gerade getestet, es funktioniert in einem gewissen Farbbereich ganz gut aber spätestens in den extremen Bereichen zeigt sich stark die Abweichung. Ich kann dir aber anbieten, dass du ein paar Messwerte aufnimmst und ich dir die Funktion so anpasse, dass es farblich ganz gut passen sollte. Dazu müsstest du an den HUEGeräten verschiedene Farbtemperaturen druchtesten und zu jedem Wert über den RAW Befehl die RGB und die WW LEDs entsprechend einstellen, und dann am besten im folgendem Format posten. Im optimalfall bleibt G bei 0
-----
| HUE color | R | G | B | WW |
| 6500 K | 1023 | 0 | 0 | 1023 |
| 2000 K | 0 | 0 | 1023 | 1023 |
----------
Je mehr Werte desto besser, damit sollte sich das ganze recht gut interpolieren lassen und ich komm drum herum, mir die exakte Berechnung anzusehen. Am besten noch die Farbtemperatur deiner WW Streifen mit angeben.
--------------------------------------------------------------------------------------
Wünsche zum Modul/FirmwareIch fände es praktisch, wenn man die Pins, die für RGB WW CW verwendet werden in den Einstellungen konfigurieren könnte. Ich hab kein Board aus dem Forum sondern alles selbst zusammen gelötet und dabei allerdings nur 4 FETs installiert und leider teilweise WW und CW vertauscht - gab es hier mal eine andere Konfiguration im GIT? - und möchte nicht neu löten ;D .
Beste Grüße
Fabian
@vbs:
Ich habe mein fhem Modul auf die neueste dev Version upgedatet, seit dem ist wieder das Problem mit dem disconnectd da.
2017-10-07 12:57:58 state disconnected
Das Modul ist an und lässt sich auch bediedenen.
Ich hab mal die funktionierende noch mal angehangen, evl. könntest du mal schauen, ob da was in der neuen Version abhanden gekommen ist :).
Gruß
lewej
@vbs
Wenn ich die LEDStripes auf on oder off setze, dann wird das Reading stateLight nicht direkt umgesetzt, könnte man das ändern?
Gruß
lewej
Hm, mit welcher Firmware benutzt du das Modul denn? Passt da evtl. etwas nicht? Habe gerade Version vbs8 hochgeladen, also bitte noch einmal updaten. Es hätte aber eigentlich auch mit vbs7 funktionieren müssen.
Steht das Modul dauerhaft auf disconnect? Oder erst opened und später disconnect? Kannst du bitte mal ein verbose5-Log machen und posten?
Zitat von: lewej am 07 Oktober 2017, 17:13:22
Wenn ich die LEDStripes auf on oder off setze, dann wird das Reading stateLight nicht direkt umgesetzt, könnte man das ändern?
Das wird einfach daran liegen, dass dein Modul auf "disconnected" steht und du daher keine Zustandsänderungen mitbekommst.
@vbs:
Bin gestern von Original-Modul&FW auf deinen Stand umgestiegen. Migration an sich hat gut geklappt. Vielen Dank dir für die tolle Arbeit!
Ein kleines Problem habe ich aber doch:
Ich hatte bisher über Timer bzw. DOIF gesteuert einen "rotate" abgesetzt, den kenn das neue Modul nicht mehr.
Das wäre noch nicht so schlimm, aber leider funktioniert auch das relative reduzieren von "hue" nicht mehr. Es schlägt eine Validierung im Modul zu, die keine neg. Werte erlaubt.
Damit funktioniert das so im Wiki beschriebene Vorgehen nur noch für "+" aber nicht mehr für "-".
Zitat
Relative Values
Instead of absolute target values it is also possible to use positive or negative relative values. Prepend color values either with + or with -.
Wäre super, wenn du das im Modul wieder "freischalten" könntest. Für "Umsteiger" wäre es vielleicht auch hilfreich, das "rotate" noch zu implementieren.
Viele Grüße,
weini
Zitat von: vbs am 07 Oktober 2017, 17:37:38
Hm, mit welcher Firmware benutzt du das Modul denn? Passt da evtl. etwas nicht? Habe gerade Version vbs8 hochgeladen, also bitte noch einmal updaten. Es hätte aber eigentlich auch mit vbs7 funktionieren müssen.
Steht das Modul dauerhaft auf disconnect? Oder erst opened und später disconnect? Kannst du bitte mal ein verbose5-Log machen und posten?
Das wird einfach daran liegen, dass dein Modul auf "disconnected" steht und du daher keine Zustandsänderungen mitbekommst.
@VBS: Alles auf den neusten Stand upgedatet:
Momentan funktioniert der Status von openend und disconnected. Jedoch wird
stateLight off 2017-10-07 19:26:13
der nächste aufruf war erst um
stateLight on 2017-10-07 19:28:46
Ich habe die Led bereits um 19:27 eingeschaltet.
Gruß
lewej
@lewej
Hm, also state ist "opened" und normale Reading-Updates funktionieren, nur "stateLight" nicht? Der Controller schickt regelmäßig seinen Status und daraufhin werden alle entsprechenden Readings wie hue, sat, val und eben auch stateLight upgedatet. Deshalb würde es mich wundern, wenn es generell jetzt funktioniert, aber nur stateLight nicht funktionieren würde.
Das einzige, was mir einfallen würde, wäre, dass das Update um 19:28:46 durch ein händisches "set update" getriggert wurde (was bedeuten würde, dass die Echtzeit-Updates bei dir nicht funktionieren).
Poste doch bitte mal ein Log. Die Chancen stehen ganz gut, dass ich da sehen kann, was da bei dir passiert...
@weini
Danke für den Hinweis, im Anhang eine Version mit geänderter Plausibilitätsprüfung. Sah bei mir jetzt gut aus. Könntest du das mal testen bei dir?
Über das "rotate" denke ich mal nach... Verstehe einerseits, dass es kompatibler wäre aber andererseits möchte ich nicht so gerne redundante Funktionen haben... mal schauen... ;)
@VBS:
Also ich war etwas ungeduldig, der Status wird aktualisiert, jedoch braucht es lange, bis die events reinkommen.
Ausgeschalatet:
2017-10-07_22:00:43 WZTVLEDSTRIPE off
2017-10-07_22:01:17 WZTVLEDSTRIPE stateLight: off
Das sind 34s, das macht den WAF Effekt zur nichte :(.
Kann dieses Reading direkt aktualisiert werden, wenn man on oder off drückt?
Anbei auch das log:
Man sieht im Logfile, dass das Modul disconnectet, weil es der Meinung ist, keine Daten mehr empfangen zu haben. Erst dann beim erneuten Verbindungsaufbau kommen wieder Daten und du bekommst die stateLight-Änderung mit. Ist etwas komisch, aber man sieht, dass da irgendwas ziemlich schief läuft:
2017-10-07_22:00:43 WZTVLEDSTRIPE off
2017.10.07 22:00:43.618 5: WZTVLEDSTRIPE: LedController_ParseBoolResult
2017.10.07 22:00:43.619 5: WZTVLEDSTRIPE: LedController_ParseBoolResult success
2017.10.07 22:00:46.257 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 40.2304549217224 s ago
2017.10.07 22:00:47.857 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 20.8056139945984 s ago
2017.10.07 22:00:56.926 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 50.8998129367828 s ago
2017.10.07 22:00:57.859 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 30.8069970607758 s ago
2017.10.07 22:01:06.929 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 60.9031128883362 s ago
2017.10.07 22:01:07.862 4: WZTVLEDSTRIPE: LedController_CheckConnection: Connection still alive. Last data received 40.8103330135345 s ago
2017.10.07 22:01:16.932 3: WZTVLEDSTRIPE: LedController_CheckConnection: Connection lost! Last data received 70.9056839942932 s ago
2017.10.07 22:01:16.933 1: 192.168.10.97:9090 disconnected, waiting to reappear (WZTVLEDSTRIPE)
Normalerweise muss das "LedController_CheckConnection" alle 10 Sek. kommen. Bei dir laufen offenbar zwei getrennte Timer, einmal immer xx:xx:56 und einmal xx:xx:57. Das sollte eigentlich nie passieren, aber ich weiß nicht, ob das das eigentliche Problem ist.
Bitte probier mal die Variante aus dem Anhang. Die Meldungen sollten dann sauber alle 10 Sek. kommen. Etwa so:
2017.10.07 22:35:13.001 4: wz_lightLedCouch: LedController_CheckConnection: Connection still alive. Last data received 20.4050650596619 s ago
2017.10.07 22:35:23.001 4: wz_lightLedCouch: LedController_CheckConnection: Connection still alive. Last data received 30.4054992198944 s ago
2017.10.07 22:35:33.001 4: wz_lightLedCouch: LedController_CheckConnection: Connection still alive. Last data received 40.4057521820068 s ago
Im Zweifel falls möglich bitte einmal FHEM neu starten.
Und bitte mach mal einen etwas längeren Log von mindestens 4-5 Minuten.
@vbs:
Der Patch aus Post #174 funktioniert super. Danke dir!
Habe jetzt auch noch meine DOIFs entschlackt, in dem ich die "repeat" Funktion des Moduls verwendet habe. Läuft alles so, wie es soll. Tolle Sache!!!
Freut mich, das ist gut! In der Version aus dem letzten Post ist übrigens auch "rotate" drin wenn mich meine Erinnerung nicht täuscht :)
@lewej
Klappt jetzt die Verbindung bei dir stabil mit der Version?
@VBS:
Ich habe es erst jetzt eingespielt und teste es jetzt.
gruß
lewej
Zitat von: lewej am 10 Oktober 2017, 20:20:23
@VBS:
Ich habe es erst jetzt eingespielt und teste es jetzt.
gruß
lewej
Hi,
@vbs: mit der angefügten Datei, ist der Status bis jetzt immer richtig. Jedoch habe ich noch eine anmerkung. Wenn der Controller auf disconnected steht, dann steht bei stateLight noch immer on.
Könnte man es so ändern, das wenn es disconnected ist, dann ist ja der Controller automatisch off.
Gruss
lewej
gibt es auch fertige bin datein für deine fw version?
Ja findest du hier:
http://rgbww.dronezone.de/testing/rom0.bin
http://rgbww.dronezone.de/testing/spiff_rom.bin
Hallo VBS,
ich habe eine etwas ungewöhnliche Anfrage, ich nutze fhem nur noch als Backend für mein Loxone.
Ich habe mir eine Funktion gebaut die die Loxone RGB Farbe in fhem rgb umrechnet.
Würdest du das evtl. in deine Firmware/ Fhem Modul einbauen?
Dann wäre der Controller einen Eierlegendewollmilchsau :).
Loxone RGB in HEX-RGB umrechnen
sub percent2rgb($)
{
my($percent) = @_;
# my($r,$g,$b) = ($percent =~ m/(\d\d\d)(\d\d\d)(\d\d\d)/);
my $r = substr $percent, -3;
my $g = substr $percent, -6, 3;
my $b = substr $percent, -9, 3;
return sprintf( "%02X%02X%02X", $r*2.55+0.5, $g*2.55+0.5, $b*2.55+0.5 );
}
Gruss
lewej
Ohne vbs vorgreifen zu wollen: Das ist so speziell, dass es in (d)einer 99_myUtils.pm besser aufgehoben wäre.
Ja sorry, sehe ich auch so. Außerdem müsste man ja die FHEM-Schnittstelle erweitern an allen Stellen, wo man Werte angeben kann, um das überhaupt nutzen zu können. Ist ja nicht damit getan, den Code irgendwo in die Firmware zu packen.
Wenn sich noch ein paar andere Leute melden, die das brauchen, denke ich nochmal drüber nach ;)
Ok, vielleicht finden sich noch welche.
Kann ich an die Controller direkt einen GET oder POST schicken?
Ich würde gerne folgenden Befehl absetzen.
val 100
val 0
Ich habe im Wiki nichts dazu gefunden.
Gruss
Lewej
Ja, gleiches Prinzip wie bei der originalen Firmware:
https://github.com/patrickjahns/esp_rgbww_firmware/wiki/2.1-JSON-API-reference
Die Erweiterungen sind hier beschrieben:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki
Hallo VBS,
ich habe an einem Controller nur einen CW Streifen und nutze den Controller nur zum Dimmen. Auf der Konfigurations Seite kann man nur RGB, RGBww oder RGBCW oder RGBwCw auswählen.
Ist eine Konfig für nur CW oder WW geplant?
Gruss
Lewej
Nutze doch einfach nur die Kanäle, die auch angeschlossen sind. Warum brauchst du einen eigenen Modus dafür?
so alle meine controller auf deine fw geflashed und das modul geupdatet.
Nun wollte ich deine controller update url eintragen und mqtt aktivieren aber ich kann die readings nicht verändern.
Wie schaffe ich das?
Alle Config-Parameter können aus FHEM heraus per "set config" gesetzt werden:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#mqtt
Also MQTT einschalten wäre dann:
set config wz_lightLedTv config-network-mqtt-enabled 1
moin, schnelle antwort hatte es selber gerade entdeckt ;D
Aber ich bekomme noch folgende meldung
mqtt.0 2017-12-03 18:20:56.771 warn Client [Controller_3] has invalid password(undefined) or username(undefined)
Im Webinterface habe ich nochmal alles gegen gecheckt da ist alles korrekt
Edit: ohne pw geht es
allerdings sendet der controller keine topics sehe nur das er sich verbindet
Zitat von: vbs am 03 Dezember 2017, 18:14:54
Also MQTT einschalten wäre dann:
set config wz_lightLedTv config-network-mqtt-enabled 1
Hast du dich verschrieben oder?
set wz_lightLedTv config config-network-mqtt-enabled 1 das wäre richtig ne?
Ansonsten gibt es auch einen befehl zum mqtt pw? weil im webinterface scheint er es nicht zu übernehmen
Au weia, MQTT mit Name/Passwort hab ich wohl noch nie benutzt und das war nicht fertig implementiert... :-\
Ich hab das aber gerade mal kurz reingehackt, hoffentlich klappts. Kann es hier spontan nicht testen, weil mein Broker hier kein Name/Passwort erwartet. Vielleicht kannst du es mal bei dir probieren und mit ein bisschen Glück klappt das spontan? Ansonsten muss ich da mal tiefer einsteigen...
Ein Reading für MQTT-Passwort sollte dann auch in FHEM erscheinen.
FW im Anhang.
MQTT user und pw funzt! 8)
Leider kommen aber immer noch keine Topics an.
Muss man diese manuell anlegen?
Schonmal gut... Genau, von sich aus schickt der erstmal nix.
Du musst erst eines der Sync-Modi aktivieren:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#device-synchronization--slave-mode
Z.B. als Cmd-Master konfigurieren:
set <dev> config config-sync-cmd_master_enabled 1
Dann solltest du alle Befehle sehen, die der Controller ausführt (ein Slave kann sich dann darauf synchronisieren).
Um andere Controller als Slave zu synchronisieren, musst du bei diesen Controllern den Cmd-Slave aktivieren und das Topic des Masters angeben:
config-sync-cmd_slave_enabled 1
config-sync-cmd_slave_topic home/wz_lightLedTv/command
Um die beiden Controller wirklich 100% synchron zu halten, würde ich noch empfehlen, die clock-Master/Slave-Funktionalität zu aktivieren (gleiches Vorgehen). Dann gleichen alle Slaves ihre Taktung mit dem Master per MQTT ab.
In diesen Readings sieht man die aktuelle Taktung des Controllers und den Offset zum Master (der im Idealfall 0 beträgt):
clockCurrentInterval 19988
clockSlaveOffset 1
jo ok jetzt legt er ein command an.
Also ich verstehe das nun so das das MQTT quasi in erster linie für die sync funktion der controller gedacht ist?
Wenn man einen Controller als Master hat und einen als Slave ist es dann noch möglich diese einzeln per Farbe anzusteuern?
Quasi ein Dummy Device was das mit dem Sync macht und die 2 Controller einzeln kann man einzeln regeln.
Hoffe man versteht was ich fragen will ::)
Ansonsten stellst du die neue FW noch per OTA update zur verfügung?
Und bislang läuft sonst alles mit deiner FW perfekt. Einen Dank dafür 8)
Ja momentan wird MQTT nur zur Synchronisierung verwendet.
Hm, naja, es ist so:
Du kannst den Slave immer noch getrennt steuern und er wird reagieren. Aber sobald der nächste Befehl vom Master kommt, wird der Slave auch darauf reagieren.
So ein "Hybrid"-Sync-Modus wäre wahrscheinlich recht schwierig umzusetzen, da auch relative Befehle unterstützt werden und in diesem Falle der Slave im schlimmsten Fall nie wieder farblich synchron zum Master wird, wenn man einmal manuell eingegriffen hat. (zb. Befehle wie "hue +15")
Neue Firmware mit MQTT Name/Passwort kommt bald...
vbs9 mit MQTT username/password.
Reminder: alle Controller mit einem FHEM-Befehl auf die aktuelle Firmware updaten:
set TYPE=LedController fw_update
Zitat von: vbs am 03 Dezember 2017, 21:16:33
vbs9 mit MQTT username/password.
Reminder: alle Controller mit einem FHEM-Befehl auf die aktuelle Firmware updaten:
set TYPE=LedController fw_update
aber doch auch nur wenn man die richtige update url eingetragen hat oder nicht?
Wenn man dem Befehl keine explizite URL mitgibt, dann wird die URL aus dem Reading
config-ota-url
verwendet.
Der Default-Wert ist "http://rgbww.dronezone.de/testing/version.json".
Sprich: Wenn man den Wert nicht verändert hat, dann braucht man keine URL mitgeben und es wird der hinterlegte Standard benutzt. :)
ich hatte vorher die andere version drauf und bei mir hat er nicht zu deiner version geändert.
Ist dann wohl sehr seltsam. Firmware-Updates über FHEM gibt es in der Original-FW nicht (geschweige denn ein Reading "config-ota-url"). Und die Update-URL steckt in der Firmware. Wüsste also nicht, wo da irgendein anderer Wert herkommen könnte.
hatte vorher die andere fw drauf daher vielleicht
Ich kann das bestätigen. Hatte vorher auch die Original Firmware drauf, und bin irgendwann(ich glaube so um die vbs5er Version rum) gewechselt.
Im Reading config-ota-url steht der Link zur Original Firmware von pjakobs.
Gruß
Ok, danke für den Hinweis. Hab nochmal reingeguckt: Das ist so, dass es den Parameter früher zwar nicht als Reading gab aber schon intern in der Firmware als Parameter. Nach dem Updaten der Firmware ist es offenbar so, dass er alle Parameter aus der alten Konfiguration übernimmt (und damit auch die URL). Bin mir gerade nicht sicher, ob ich das gut oder schlecht finden soll. Scheint ja aber immerhin keine Probleme zu machen.
Wie dem auch sei: Mit diesem Befehl lassen sich alle Controller auf die neue Update-URL ändern (einmalig ausführen):
set TYPE=LedController config config-ota-url http://rgbww.dronezone.de/testing/version.json
Hallo Zusammen,
wenn ich diese Firmware hier einsetzte, muss ich dann auch zwingend das Modul in FHEM austauschen? Ich verwende zur Zeit drei Controller mit der "originalen" Firmware und würde die ungerne umflashen bis ich nicht alles getestet habe.
Gruß
Markus
Moin vbs,
hast Du Lust und Zeit den Code so anzupassen das ich auch einen ESP-12-E verwendet werden kann?
(GPIO 4 und 5 sind dort vertauscht)
Gruß
Dennis
Zitatwenn ich diese Firmware hier einsetzte, muss ich dann auch zwingend das Modul in FHEM austauschen? Ich verwende zur Zeit drei Controller mit der "originalen" Firmware und würde die ungerne umflashen bis ich nicht alles getestet habe.
Ja, du brauchst in jedem Fall auch das passende FHEM-Modul. Sonst kannst du auch die Funktionen gar nicht nutzen (manches mag funktionieren, aber sicher nicht alles).
Ich hatte ursprünglich mal gehofft, dass die Änderungen mal in den Original-Zweig von Peter zurück fließen könnten, aber leider hatte er bisher noch keine Gelegenheit, sich die Firmware mal anzuschauen. Darum führt sie so eine "Parallel-Existenz" :)
Was du machen könntest, wäre das Modul in "32_LedController2.pm" oder so umzubenennen. Musst dann jedoch auch alle Funktionen innerhalb der Datei umbenennen. Dann könnte man das alte und das neue parallel betreiben als getrennte Module. Etwas unschön, aber sollte eigentlich machbar sein.
Vielleicht mache ich den Schritt irgendwann auch mal selber, wenn ich die Hoffnung auf die Rückführung komplett aufgegeben habe, :)
Zitat von: Shojo am 04 Dezember 2017, 22:06:51
hast Du Lust und Zeit den Code so anzupassen das ich auch einen ESP-12-E verwendet werden kann?
(GPIO 4 und 5 sind dort vertauscht)
Ja, kann ich sicherlich machen. Sollte recht einfach sein.
Zitat von: vbs am 04 Dezember 2017, 22:17:26
Ja, kann ich sicherlich machen. Sollte recht einfach sein.
Habe nämlich grade das Platinen Layout auf eine SingleLayer PCB portiert um diese besser fräsen zu können...
Und da viel mir das auf das ich ja so meine ESP-12-E nicht verwenden könne.
Kannst Du den Chip erkennen und im Code darauf reagieren?
Ich wüsste nicht wie, was aber nicht heißen muss, dass es nicht geht :)
Ich würde das erstmal als Config-Schalter einbauen. Falls jemand weiß, wie man das zur Laufzeit abfragen kann, dann bitte Bescheid gaben.
Zitat von: vbs am 04 Dezember 2017, 22:09:43
Ja, du brauchst in jedem Fall auch das passende FHEM-Modul. Sonst kannst du auch die Funktionen gar nicht nutzen (manches mag funktionieren, aber sicher nicht alles).
Ich hatte ursprünglich mal gehofft, dass die Änderungen mal in den Original-Zweig von Peter zurück fließen könnten, aber leider hatte er bisher noch keine Gelegenheit, sich die Firmware mal anzuschauen. Darum führt sie so eine "Parallel-Existenz" :)
Was du machen könntest, wäre das Modul in "32_LedController2.pm" oder so umzubenennen. Musst dann jedoch auch alle Funktionen innerhalb der Datei umbenennen. Dann könnte man das alte und das neue parallel betreiben als getrennte Module. Etwas unschön, aber sollte eigentlich machbar sein.
Vielleicht mache ich den Schritt irgendwann auch mal selber, wenn ich die Hoffnung auf die Rückführung komplett aufgegeben habe, :)
Also wenn ich dich richtig verstehe müsste ich nur die Funktionen innerhalb der Moduldatei umbenennen und die Firmware selber bleibt? Oder muss ich das in der Firmwaredatei ändern? Ich glaube dann müsste ich passen :'(
Gruss
Markus
Genau, die Firmware kann so bleiben wie sie ist. Du musst nur dafür sorgen, dass die beiden FHEM-Moduldateien friedliche koexistieren können und von FHEM als zwei unterschiedliche, eigenständige Module wahrgenommen werden. So aus dem Bauch heraus würde ich sagen, dass nur die Funktionsnamen geändert werden müssen.
Hallo VBS,
nochmal für Programieranfänger... ;-)
Ich hole mir deine 32_LedController.pm benenne diese um in z.B. 32_LedController02 und ändere innerhalb der Datei alles was "Led_Controllerxxxx..." ist in z.B. "Led_Controller02xxxx..." ?!
Alle Subs usw..
Sowie hier..
sub LedController02_Initialize(@) {
my ($hash) = @_;
$hash->{DefFn} = 'LedController02_Define';
$hash->{UndefFn} = 'LedController02_Undef';
$hash->{ShutdownFn} = 'LedController02_Undef';
$hash->{SetFn} = 'LedController02_Set';
$hash->{GetFn} = 'LedController02_Get';
$hash->{ReadyFn} = 'LedController02_Ready';
$hash->{AttrFn} = 'LedController02_Attr';
$hash->{NotifyFn} = 'LedController02_Notify';
$hash->{ReadFn} = 'LedController02_Read';
$hash->{AttrList} = "defaultRamp slaves" . " $readingFnAttributes";
require "HttpUtils.pm";
Das wäre es dann ?...
Gruß
Markus
Ja genau, aber natürlich auch die Funktionen innerhalb der Datei umbenennen.
mmh glaube ich steh ein wenig auf dem Schlauch...
Innerhalb welcher Datei? Dachte nur im Modul selber..
Sorry für die blöde Frage aber ich hab mich noch nicht so tief mit dem "Modul-Krims-Krams" beschäftigt...
Gruß
Markus
Kein Problem...
Ja ich meine auch die Modul-Datei. Die ganze Datei besteht aus einer Reihe von Funktionen. Du siehst dort reihenweise Inhalte wie z.B.
sub LedController_RemoveTimerCheck($) {
Die musst du dann entsprechend auch ändern in
sub LedController02_RemoveTimerCheck($) {
Evtl. kannst du einfach ein Text-Replace auf die gesamte Datei machen und "LedController_" ersetzen durch "LedController02_".
ahhh dann war ich also doch nicht auf dem Holzweg, genau so hatte ich es auch gemeint.
Habe alles mit search and replace gemacht und Datei umbenannt. werds nachher mal testen..:-)
Muss im html Teil auch noch was geändert werden?
Viiiielen dank nochmal !!
Gruß
Markus
Sehr geil ;)
https://github.com/verybadsoldier/esp_rgbww_firmware/commit/5b5c3ebee74c49beda681876bcd6ebfcf016fed8
Ich Danke Dir!
Na gern doch. Anbei mal eine Firmware mit der Pin-Config. Kannst du ja vielleicht mal testen, ob das bei dir zu funktioniert wie erwartet :). Mit der Firmware solltest du ein FHEM-Reading "config-general-pin_config" vorfinden. Defaultmäßig passend für den ESP12-F ("13,12,14,5,4").
Über diesen Config-Parameter kann man die Pins beliebig frei zuordnen. Also um Pin 4 und 5 zu vertauschen müsstest du eben config-general-pin_config setzen auf ""13,12,14,4,5".
Hier die Beschreibung im Wiki dazu:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#output-pin-configuration
Finde ich echt super!
Ich tue mich doch immer recht schwer mit C++ ...
Bin halt so ein verwöhnter C# Futzi :)
Zitat von: vbs am 05 Dezember 2017, 18:29:15
Kannst du ja vielleicht mal testen, ob das bei dir zu funktioniert wie erwartet :).
Ja werde ich tun ,habe aber die Platine noch nicht fertig :)
So, Hab jetzt meine zwei Controller auch mal mit dieser Firmware versorgt :-)
Und hab direkt mal ne blöde Frage... wie bekomme ich denn meine Glühlampe wieder angezeigt neben dem Opend ?? :o
Gruß
Markus
Ich hab als Attribut "devStateIcon" bei mir
{Color_devStateIcon(ReadingsVal($name,"rgb","000000"))} eingetragen.
danke dir :-)
funzt bisher alles super gut !!!
Ich hab mal das Modul aus dem Dev in update eingetragen
update add https://github.com/verybadsoldier/esp_rgbww_fhemmodule/blob/develop/controls_ledcontroller.txt
hoffe das ist richtig so...?
Gruß
Markus
wie stellt ihr das denn mit Szenen an?
Doif erstellen und dann irgendwie starten?
Wäre klasse wenn jemand mal ein Beispiel posten würde ;-)
Habe zur Zeit ein RGB Stripe und zwei WW am Controller. Ist es eigentlich richtig, wenn ich den Calculation Mode auf normal habe, das nur ein weißer Kanal angesteuert wird? Bei Rainbow und Spectrum laufen die beiden weißen immer syncron.
Gruß
Markus
Zitat von: Markus. am 06 Dezember 2017, 19:06:36
update add https://github.com/verybadsoldier/esp_rgbww_fhemmodule/blob/develop/controls_ledcontroller.txt
Nee die URL stimmt nicht. Guck mal hier ganz oben :)
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Kann es sein, das Settings wie config-network-mqtt-topic_base bei einem Firmwareupdate gelöscht werden?
In den Readdings des devices ist nach dem vb11 fw update wieder der default eintrag.
Gruß
Markus
Wäre nicht so gewollt, aber kann natürlich sein. Wäre dann ein Bug. Kannst du sagen, welche Parameter das bei dir betrifft?
Ist sogar noch viel besser: "topic_base" wird einfach generell nicht persistent gespeichert (also gespeichert schon, aber nicht geladen) und ist nach jedem Reboot futsch, also unabhängig vom FW-Update...
Ups gut zu wissen. Aufgefallen ist mir das nur bei dem erwähnten setting. Die anderen sind alle noch default.
Gruß
Markus
Sollte jetzt in vbs12 behoben sein...
klasse :-)
Vielen Dank!!
Gruß
Markus
Um das Modul besser von dem Original-Modul unterscheiden zu können und damit auch beide parallel laufen können, hab ich dieses Modul jetzt in "32_EspLedController" umbenannt. Die alte Version existiert erstmal weiterhin, wird jedoch nicht mehr gepflegt. Man kann nun also auch problemlos testweise mal einen Controller auf diese FW umziehen, ohne dass man sich Konflikte einhandelt.
Also bitte auf folgende Update-URL umstellen:
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt
Außerdem müssen die Definitionen der vorhandenen Devices von "LedController" auf "EspLedController" umgestellt werden (hab ich direkt in der .cfg gemacht).
Top deine Arbeit, ich versuche morgen einen meiner Platinen fertigzustellen und deine FW zu testen 8)
Hallo Zusammen,
glaube die Frage ist, bei meinen viiiielen Fragen nicht verwunderlich, irgendwie untergegangen... :-)
Und zwar würd ich gerne diverse Beleuchtungsszenarios definieren und die dann Eventgesteuert, Dummy oder so, starten.
Hat sowas schon jemand gemacht? Stehe da irgendwie ein wenig auf dem Schlauch. Wäre klasse wenn jemand ein Beispiel posten könnte.
Gruß
Markus
Weiß nicht genau was du meinst, aber ich mach es so, dass ich eine Funktion habe ("updateLights"), die alle für die Beleuchtung relevanten Eingangszustände abfragt und dann die Beleuchtung entsprechend setzt. Dann hab ich ein notify, das auf alle relevanten Eingänge triggert und die Beleuchtungsfunktion aufruft. Also immer wenn sich eine für die Beleuchtung relevante Eingangsgröße ändert, wird updateLights aufgerufen.
Gibt sicher auch 100 andere Wege...
Naja halt so "Farbwechsel-Endlos-Loops" meine ich eigentlich.
Gruß
Markus
Beschreibung der Befehle findest du im Wiki. Ein paar Beispiele sind da auch dabei. Hier z.B.: https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#function-demonstrations
Zitat von: vbs am 05 Dezember 2017, 18:29:15
Anbei mal eine Firmware mit der Pin-Config. Kannst du ja vielleicht mal testen, ob das bei dir zu funktioniert wie erwartet :).
So getestet und rennt ;) ;D
So nun noch eine Frage, da ich mehrere bekannte habe die mit dem Lötkolben nicht so geübt sind hatte ich gedacht vielleicht noch eine Platine mir einen Wemos D1 zu erstellen.
Man sollte dort ja auch die Firmware drauf nutzten können ... Oder?!
Gruß
Freut mich, dass es funktioniert. Kann leider zu diesem Wemos D1 nix sagen, sorry :-X
Zitat von: vbs am 11 Dezember 2017, 18:18:49
Kann leider zu diesem Wemos D1 nix sagen, sorry :-X
So eben mal einfach draufgebügelt scheint ohne Probleme darauf zu laufen! :)
Na klasse, umso besser ;)
Kannst du mir sagen, welche Pin-Konfiguration man da braucht? Würde ich dann gerne hier mit ins Wiki eintragen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#output-pin-configuration
Das muss ich erst testen da ich den so auf dem blanken Wemos gespielt habe.
Kommt dann halt auf das Platinen Layout an.
(https://wiki.wemos.cc/products:d1:d1_mini)
Mir geht immer die WlanConfig flöten, nachdem er nach erfolgreichen Wlan Login neustartet.
Hast Du ein Tipp?
Nee, so aus dem Bauch erstmal nicht. Betrifft das wirklich nur die WLAN-Config oder sogar die komplette Config? Nur WLAN fände ich noch seltsamer...
Passiert das nur auf dem Wemos D1? Hast du einen "normalen" ESP12-F da, um zu gucken ob es mit der anderen Hardware zusammen hängt?
Aktuell habe ich leider keinen ESP12-F mehr da , und ja die komplette Config ist weg
Aber um welchen Chip gehts denn? Reden wir immer noch von dem Wemos D1? Der hat ja offenbar einen ESP-8266EX drauf.
Das Datenblatt (https://cdn-shop.adafruit.com/product-files/2471/0A-ESP8266__Datasheet__EN_v4.3.pdf) sagt zum Thema Flash-Speicher:
ZitatThere is no programmable ROM in the SoC, therefore, user program must be stored in an
external SPI flash.
So wie ich das verstehe, würde das erklären, warum der keine Config speichert.
Das kann nicht sein da ich schon unzählige Projekte mit den Wemos D1 mini durch habe, und fast alle mindestens den Wifimanager drauf haben.
Und der läuft ohne Probleme.
Und es sollte ein ESP-12S verbaut sein
https://wiki.wemos.cc/_media/products:d1:mini_new_v2_2_0.pdf
https://cdn.hackaday.io/files/255091091377056/ESP-12S_User_Manual.pdf
Edit:
Habe nun mal die "alte" FW aufgespielt und mit der geht es...
Sobald ich aber auf deine OTA Version update geht es wieder nicht.
Edit2:
Übersteht aber auch kein Reboot...
da kann wohl wirklich was nicht in den SPIFF geschrieben werden.
Hatte eben noch mal ein Projekt von mir Probiert da klappt das ohne Probleme
Sorry, dann kann ich da glaube ich nix zu sagen. :-\
Bin etwas verwirrt, dass hier von einem ESP-8266EX die Rede ist aber parallel das Bild von einem ESP12-S:
https://wiki.wemos.cc/products:d1:d1_mini
Hab gedacht, dass müsste entweder oder sein...
Kann es daran liegen das ich den Wemos Di mini mit den SPI Mode DIO flashen muss?
Edit:
Japp das ist es, das ist nun natürlich blöd QIO ist nicht kompatible zu DIO.
So, wenn ich es nun richtig verstanden habe ist QIO --> DIO nicht kompatibel.
Aber DIO --> QIO soll kompatibel sein, wäre es möglich es den SPI Mode auf DIO zu ändern um eine höhere Kompatibilität zu erreichen?
Da ich nun nicht weiß wie das gute Stück bei dir kompiliert wird :)
Gruß
Also das Problem ist, dass der Modus, den er benutzt, wenn er das OTA-Update durchführt? Aber wenn du es händisch per seriell flasht, dann geht es?
Die einzige Stelle, die ich gefunden habe, wo man den Modus umstellen kann ist in diesem Makefile:
https://github.com/verybadsoldier/Sming/blob/develop/Sming/Makefile-rboot.mk#L58
Ich fürchte jedoch, dass sich der Parameter nur auf den "make flash"-Aufruf bezieht und nicht auf das OTA-Update. Kann man einfach mal ausprobieren. Zum OTA-Update habe ich so erstmal nix finden können.
Nein auch "Seriel" geflasht geht das dann nicht,
Da die Firmware mit QIO kompiliert wurde, die leider nicht von allen ESP´s unterstützt wird.
DIO hingegen kann wohl jeder (wie ich es bis jetzt erlesen habe).
Denke das hier https://github.com/verybadsoldier/Sming/blob/develop/Sming/Makefile-rboot.mk#L58 die Änderung ausreichen würde
Also als Compile-Switch habe ich da beim besten Willen nichts finden können. Glaube auch eigentlich nicht, dass man das mit einkompilieren muss/kann. Aber im Anhang mal eine Version mit dem o.g. Flag.
Kann es daran liegen das ich den Wemos Di mini mit den SPI Mode DIO flashen muss?
Edit:
Japp das ist es, das ist nun natürlich blöd QIO ist nicht kompatible zu DIO.
Bin ziemlich überrascht, dass du es dann hier doch schon am Laufen hattest? (zumindest hatte ich das so interpretiert)
Ja ich kann die FW mit dem DIO Flag (also beim Flashvorgang) so auf dem Wemos flashen aber halt nicht speichern über ein Reboot hinweg.
Und das soll daran liegen das (soweit ich das erlesen habe) das er dann nicht auf den SPIFF zugreifen kann da das rboot den FLAG QIO gesetzt hat was der Wemos nicht kann.
Zitat von: vbs am 12 Dezember 2017, 21:17:54
Aber im Anhang mal eine Version mit dem o.g. Flag.
Hat leider nicht gewünschten Effekt gehabt :(
Dann habe ich auch keine Idee mehr er nicht speichern kann.
Danke für deine Mühe!
Hm, zu schade. :( Kannst du irgendwie verifizieren, ob das Flag da jetzt wirklich gesetzt ist?
Probier nochmal die Version im Anhang, ich hab eine noch "richtigere" Stelle gefunden, um es zu setzen. Ich fürchte aber, dass es aufs gleiche rauskommt, wie beim ersten Versuch :(
Hab dann leider auch keine weitere Idee, sorry.
Nein leider auch nicht.
Sobald er rebooten will ist schluß.
Sag mal hast Du irgend ein Link für eine brauchbare Einführung ins Sming Framework?
Welche IDE nutzt man dafür?
Ich bin ja eigentlich in Visual Studio zuhause....
Edit:
Uiuiui grade gefunden https://github.com/brunnels/ESP8266-VisualStudio :)
Nee, ich kenne da leider auch keine gute Doku. Quellcode lesen war bisher der Weg :o
Bin auch großer Freund von Visual Studio, aber hauptsächlich wegen dem Debugger. Für die ESP-Sachen benutze ich Eclipse in einer VM. Ich hatte schonmal etwas RemoteDebugging auf dem ESP am Laufen mit Eclipse, aber leider auch nicht hinreichend stabil um nützlich zu sein. Außerdem debuggen sich Schleifen >10 Hz so schlecht :P
Für Arduino und ESP Zeugs hatte ich bisher erfolgreich http://www.visualmicro.com/ eingesetzt.
Kann es nur empfehlen !
So nachdem ja nun die Firmware auf den Wemos D1 Mini läuft ::) ;D
Habe ich mal eine relativ einfach zu lötende und auch zu fräsende Platine auf ein Layer gebaut.
Die config-general-pin_config wäre hier 2,4,5,14,12
Hallo,
ich habe vor ein paar Tagen die Version vbs12 geflasht, seit dem habe ich alle 2min folgendes im log:
2017.12.14 16:13:38 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"xxxxxxxx1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"xxxxxxxxxxxxx"}}
Hab jetzt erstmal auf verbose 0 gesetzt.
Du musst vermutlich mal das FHEM-Modul updaten.
Hallo Zusammen,
mit einem Controller habe ich ein komisches Problem und zwar lässst er sich einwandfrei flashen, macht aber dann nach dem reset keinen AP auf. Bevor ich den geflasht habe, habe ich ihn wie die anderen gelöscht.
das Log sieht wie folgt aus.
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
Kann es sein das der ESP einen "weg" hat? was kann ich denn da noch versuchen ?
Gruß
Markus
Zitat von: vbs am 14 Dezember 2017, 18:01:06
Du musst vermutlich mal das FHEM-Modul updaten.
letztes Update: 2017-12-09_21:05:00 61047 FHEM/32_EspLedController.pm
Hab "update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt"
eingetragen und aktuell wird mir kein Update angeboten.
Zitat von: hanswerner1 am 14 Dezember 2017, 18:33:14
letztes Update: 2017-12-09_21:05:00 61047 FHEM/32_EspLedController.pm
Hab "update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt"
eingetragen und aktuell wird mir kein Update angeboten.
Passt soweit, das ist dann schon die neuste Version.
Die Meldung kommt immer unter folgenden Umständen:
- jemand ruft "get info" auf
- ein neues EspLedController-Device wird definiert
- das Modul hat gerade die Verbindung zum Controller aufgebaut
Also wenn du nicht selbst "get info" zyklisch aufrufst, dann würde ich vermuten, dass FHEM regelmäßig die Verbindung zum Controller verliert und dann neu aufbaut. Bei jedem Neuaufbau siehst du dann diese Meldung. Guck doch mal, ob im gleichen Intervall auch state irgendwie sich ändern. Funktioniert der Controller denn sonst ordnungsgemäß? Bekommst du Farb-Änderungen usw. in FHEM mit?
Ist im Log noch mehr zu sehen evtl.?
Zitat von: Markus. am 14 Dezember 2017, 18:24:47
Hallo Zusammen,
mit einem Controller habe ich ein komisches Problem und zwar lässst er sich einwandfrei flashen, macht aber dann nach dem reset keinen AP auf. Bevor ich den geflasht habe, habe ich ihn wie die anderen gelöscht.
das Log sieht wie folgt aus.
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
Kann es sein das der ESP einen "weg" hat? was kann ich denn da noch versuchen ?
Gruß
Markus
Ich habe jetzt mal testweise Patricks Firmware geflasht und die läuft. Das ist ein ESP 12-E aus einer anderen Quelle. Könnten die irgendwie unterschiedlich sein? Für die anderen Controller habe ich auch ESP12-E verwendet und die funktionierten auf anhieb.
Gruß
Markus
Zitat von: vbs am 14 Dezember 2017, 18:45:03
Passt soweit, das ist dann schon die neuste Version.
Die Meldung kommt immer unter folgenden Umständen:
- jemand ruft "get info" auf
- ein neues EspLedController-Device wird definiert
- das Modul hat gerade die Verbindung zum Controller aufgebaut
Also wenn du nicht selbst "get info" zyklisch aufrufst, dann würde ich vermuten, dass FHEM regelmäßig die Verbindung zum Controller verliert und dann neu aufbaut. Bei jedem Neuaufbau siehst du dann diese Meldung. Guck doch mal, ob im gleichen Intervall auch state irgendwie sich ändern. Funktioniert der Controller denn sonst ordnungsgemäß? Bekommst du Farb-Änderungen usw. in FHEM mit?
Ist im Log noch mehr zu sehen evtl.?
Ich habe jetzt mal FHEM neu gestartet und bisher ist der Eintrag nicht mehr ins Log geschrieben worden. Funktioniert hat alles, auch die Verbindung wurde nicht verloren. Werde das mal weiter beobachten ob's nochmal vorkommt.
Zitat von: Markus. am 14 Dezember 2017, 20:06:50
Ich habe jetzt mal testweise Patricks Firmware geflasht und die läuft. Das ist ein ESP 12-E aus einer anderen Quelle. Könnten die irgendwie unterschiedlich sein? Für die anderen Controller habe ich auch ESP12-E verwendet und die funktionierten auf anhieb.
Gruß
Markus
Nur um Verständnis: du hast mehrere 12-Es und auf allen bis auf einen läuft die vbs-FW. Aber die Original-Firmware funktioniert auf diesem?
Hab ich leider keine Idee zu sorry :( finde es aber sehr seltsam, da mMn die Chips identisch sein sollten. Und ich wüsste auch keinen unterschied zwischen den beiden Fw-varianten bzgl. Bootverhalten (kann mich aber irren).
Evtl doch beim Flashen oder so irgendwas anders gewesen?
Gesendet von meinem SM-G950F mit Tapatalk
Soo, erste Platine fertig und läuft ;D
https://youtu.be/k8JTCJB42MM
Zitat von: vbs am 14 Dezember 2017, 22:02:59
Nur um Verständnis: du hast mehrere 12-Es und auf allen bis auf einen läuft die vbs-FW. Aber die Original-Firmware funktioniert auf diesem?
Hab ich leider keine Idee zu sorry :( finde es aber sehr seltsam, da mMn die Chips identisch sein sollten. Und ich wüsste auch keinen unterschied zwischen den beiden Fw-varianten bzgl. Bootverhalten (kann mich aber irren).
Evtl doch beim Flashen oder so irgendwas anders gewesen?
Gesendet von meinem SM-G950F mit Tapatalk
Ja habe nun insgesamt 3 Controller. Die zwei ersten konnte ich einwandfrei flashen beim letzten, der halt von einem anderen Lieferanten war, habe ich dieses Problem. Vorgegangen bin ich eigentlich immer gleich. Mit esptool gelöscht und dann mit dem flashtool neu geflasht. Settings siehe Bild. Sind alles ESP12-E.
Die Settings waren immer gleich.
Kann man eigentliich Deine Firmware zum OTA update der anderen Firmware verwenden? Ich meine wenn ich die OTA URL einfach austausche?
Gruß
Markus
Muss der Crystal nicht mit 40 MHZ laufen ?!
Ich habe nicht einen mit dem Tool geflasht bekommen. Nutze nur noch so ein ESP Python flasher. Und die Einrichtung dann mit richtiger Stromversorgung sonst hatte ich teilweise auch Probleme das der ap immer weg war
Gesendet von meinem SM-G930F mit Tapatalk
Zitat von: Shojo am 15 Dezember 2017, 08:25:05
Muss der Crystal nicht mit 40 MHZ laufen ?!
Habe ich auch getestet, macht aber irgendwie keinen Unterschied.
Zitat von: kmxak am 15 Dezember 2017, 09:59:07
Ich habe nicht einen mit dem Tool geflasht bekommen. Nutze nur noch so ein ESP Python flasher. Und die Einrichtung dann mit richtiger Stromversorgung sonst hatte ich teilweise auch Probleme das der ap immer weg war
Gesendet von meinem SM-G930F mit Tapatalk
Kannst Du mal die Befehlszeile posten? Benutze den Python flasher eigentlich nur zum löschen..
Gruß
Markus
Ja allerdings erst heute Abend wenn ich daheim bin.
Gesendet von meinem SM-G930F mit Tapatalk
Kannst ja sonst hiermit mal probieren, den nutze ich recht gerne.
https://github.com/nodemcu/nodemcu-flasher
Ist schon komisch... wie immer er bisher auch geflasht hat, bei allen anderen Exemplaren scheint es ok gewesen zu sein ???
Ja das ich echt seltsam, vielleicht hat einen defekten Speicher, da deine FW etwas mehr vom Speicher braucht wie die "Orig." FW....
Ist aber echt an den Harren herbeigezogen!
Ich versuchs nachher nochmal mit 40
Vielleicht hab ich ja wirklich irgendwie Mist mit den Settings gebaut gestern...
Hmmm....
Haben wir hier Jemanden der Druckbare Gehäuse zeichnen kann?
Falls wer dazu Lust und Zeit hat hätte ich hier mal ein groben Platinen Dummy ;D
Zitat von: vbs am 14 Dezember 2017, 18:45:03
Passt soweit, das ist dann schon die neuste Version.
Die Meldung kommt immer unter folgenden Umständen:
- jemand ruft "get info" auf
- ein neues EspLedController-Device wird definiert
- das Modul hat gerade die Verbindung zum Controller aufgebaut
Also wenn du nicht selbst "get info" zyklisch aufrufst, dann würde ich vermuten, dass FHEM regelmäßig die Verbindung zum Controller verliert und dann neu aufbaut. Bei jedem Neuaufbau siehst du dann diese Meldung. Guck doch mal, ob im gleichen Intervall auch state irgendwie sich ändern. Funktioniert der Controller denn sonst ordnungsgemäß? Bekommst du Farb-Änderungen usw. in FHEM mit?
Ist im Log noch mehr zu sehen evtl.?
Bis heute Mittag war ruhe im LOG dann ging es wieder los
Der Controller hat wohl kurz die WLAN Verbindung verloren, aber sofort wieder aufgebaut:
Log aus Present:
2017-12-15_12:39:24 Wohnwand presence: absent
2017-12-15_12:39:58 Wohnwand presence: present
Log:
2017.12.15 12:39:24 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 82.8916912078857 s ago
2017.12.15 12:39:24 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.15 12:39:24 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.15 12:39:25 3: Bel_Wohnwand: got info response
2017.12.15 12:39:25 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"xxxxxxx","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"xxxxxxxxxxxxx"}}
2017.12.15 12:40:44 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.0432350635529 s ago
Seit dem ist im Log wieder alle 1.5 min der Eintrag im Log.
Kannst du bitte mal auf verbose 4 stellen und mal ein Log über 3-4 Minuten posten?
Sollte ungefähr so aussehen:
2017.12.15 15:26:43.663 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 13.8649671077728 s ago
2017.12.15 15:26:53.665 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 23.866378068924 s ago
2017.12.15 15:27:03.667 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 33.8685741424561 s ago
2017.12.15 15:27:13.670 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 43.8710811138153 s ago
2017.12.15 15:27:23.671 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 53.8727090358734 s ago
2017.12.15 15:27:29.801 4: wz_lightLedCouch: EspLedController_Read: keep_alive received
2017.12.15 15:27:33.673 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 3.8721239566803 s ago
2017.12.15 15:27:43.674 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 13.8734450340271 s ago
2017.12.15 15:27:53.676 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 23.8749530315399 s ago
2017.12.15 15:28:03.678 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 33.8769500255585 s ago
2017.12.15 15:28:13.680 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 43.8787150382996 s ago
2017.12.15 15:28:23.681 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 53.8803429603577 s ago
2017.12.15 15:28:29.800 4: wz_lightLedCouch: EspLedController_Read: keep_alive received
2017.12.15 15:28:33.683 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 3.88260912895203 s ago
2017.12.15 15:28:43.684 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 13.8842971324921 s ago
2017.12.15 15:28:53.686 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 23.8861629962921 s ago
2017.12.15 15:29:03.688 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 33.8884429931641 s ago
2017.12.15 15:29:13.690 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 43.8902831077576 s ago
2017.12.15 15:29:23.692 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 53.8920471668243 s ago
Also alle 60 Sekunden sollte sich der Controller melden, was im Log als "keep_alive received" auftaucht. Wenn das nicht auftaucht, dann ist das die Ursache.
ok, mach ich. Allerdings hab ich in der Zwischenzeit FHEM neu gestartet, muss also waren bis die Verbindung wieder verloren geht. Das scheint aber regelmäßig zu passieren.
Zitat von: Markus. am 15 Dezember 2017, 07:41:16
Kann man eigentliich Deine Firmware zum OTA update der anderen Firmware verwenden? Ich meine wenn ich die OTA URL einfach austausche?
Ja, der Update-Mechanismus ist gleich geblieben. Also du kannst OTA beide Firmwares hin- und her flashen (nach bestem Wissen und Gewissen).
dann werde ich das mal versuchen.
Habe jetzt noch mal mit Python geflasht
esptool.py --port COM8 --baud 115200 write_flash -ff=40m -fm=qio -fs=32m 0x00000 vbs10_rboot.bin 0x02000 vbs10_rom0.bin 0x100000 vbs10_spiff_rom.bin
Selbes Problem, ESP macht keinen AP auf :-(
Gruß
Markus
python esptool.py -p COM3 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.bin
Zitat von: kmxak am 15 Dezember 2017, 18:31:36
python esptool.py -p COM3 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.bin
Ja, sieht in etwa so aus wie bei mir. Ich nutze das Python esptool nur unter Windows.
Glaube der ESP hat wirklich einen "weg" :-(
Muss ihn wohl irgendwie auslöten...heul
Gruß
Markus
Ich auch.. was sagt der serielle Monitor? Kannst ja mit arduino schauen was er macht beim booten
Gesendet von meinem SM-G930F mit Tapatalk
also das Log mit der vbs Firmware sieht wie folgt aus.
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf_cal[0] !=0x05,is 0xFF
rf cal sector: 1019
rf[112] úXÖ`ÓRGBWW Controller v 0.3.1-vbs10
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AppWIFI:: DNS enable
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - ri#hardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: QIO
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
BoOting rom 0.
rf_cal[0] !=0x05,is 0xFF
Da macht er ja überhaupt keinen AP auf. Die FW von Patrik macht er einen AP auf und verbindet sich mit der SSID. Das OTA update auf vbs funktioniert auch nach mehreren Versuchen. Aber da fängt er auch schon an zu zicken wenn man irgendwas speichern will.
Dann verliert er auch öfters die Netzwerkverbindung.
Muss nur mal sehen wie ich den ESP da wieder runter bekomme :-(
Gruß
Markus
Heißluftfön ggf. Sehr komisch. Geht nur die eine Version nicht alles andere läuft?
Gesendet von meinem SM-G930F mit Tapatalk
bei der "originalen" Firmware zickt er auch rum wenn man was speichern will. Aber die Kanäle werden ganz normal angesteuert.
Wie gesagt bei beiden Versionen verliert er, neben dem Speicherproblem, ab und zu die Netzwerkverbindung und bei der vbs Firmware macht er gar keinen AP auf.
Gruß
Markus
================================================================
3ffffaa0: 00000001 00000004 4023f816 00000000
3ffffab0: 4023f816 00000004 00000000 00000000
3ffffac0: 3ffec110 60000e00 3fff36b0 402029d0
3ffffad0: 3fff3688 00001000 3ffec132 4010076e
3ffffae0: 000003fd 60000200 000000ee 40001100
3ffffaf0: 00000001 3fff3730 00000001 401006af
3ffffb00: ffffffff ffffffff ffff0001 00000000
3ffffb10: 00000000 00000000 00000000 00000000
3ffffb20: 00000000 00000000 00000000 00000000
3ffffb30: ffffffff 00ffffff 00000000 00000000
3ffffb40: 00000000 00000000 00000000 00000000
3ffffb50: 00000000 00000000 00000000 00000000
3ffffb60: 00000000 00000000 00000000 00000000
3ffffb70: 00000000 ff000000 ffffffff ffffffff
3ffffb80: ffffffff ffffffff ffffffff ffffffff
3ffffb90: ffffffff ffffffff ffffffff ffffffff
3ffffba0: ffffffff ffffffff ffff00ff ffffffff
3ffffbb0: 0000000a 5f505345 37343638 00004341
3ffffbc0: 00000000 00000000 00000000 00000000
3ffffbd0: 00000000 00000000 00000000 00000000
3ffffbe0: 00000000 00000000 00000000 00000000
3ffffbf0: 00000000 00000000 00000000 00000000
3ffffc00: 00000000 00000000 00000000 00000000
3ffffc10: 00000000 ffffffff ffffffff ffffffff
3ffffc20: ffffffff ffffffff ffffffff ffffffff
3ffffc30: ffffffff 000001ff ffffff04 ffffff01
3ffffc40: ffffffff ffffffff ffffffff ffffffff
3ffffc50: ffffffff ffffffff ffffffff ffffffff
3ffffc60: ffffffff ffffffff ffffffff ffffffff
3ffffc70: ffffffff ffffffff ffffffff ffffffff
3ffffc80: ffffffff ffffffff ffffffff ffffffff
3ffffc90: ffffffff ffffffff ffffffff ffffffff
3ffffca0: ffffffff ffffffff ffffffff ffffffff
3ffffcb0: ffffffff ffffffff ffffffff ffffffff
3ffffcc0: ffffffff ffffffff ffffffff ffffffff
3ffffcd0: ffffffff ffffffff ffffffff ffffffff
3ffffce0: ffffffff ffffffff ffffffff ffffffff
3ffffcf0: ffffffff ffffffff ffffffff ffffffff
3ffffd00: ffffffff ffffffff ffffffff ffffffff
3ffffd10: ffffffff ffffffff ffffffff ffffffff
3ffffd20: ffffffff ffffffff ffffffff ffffffff
3ffffd30: ffffffff ffffffff ffffffff ffffffff
3ffffd40: ffffffff ffffffff ffffffff ffffffff
3ffffd50: ffffffff ffffffff ffffffff ffffffff
3ffffd60: ffffffff ffffffff ffffffff ffffffff
3ffffd70: ffffffff ffffffff ffffffff ffffffff
3ffffd80: ffffffff ffffffff ffffffff ffffffff
3ffffd90: ffffffff ffffffff ffffffff ffffffff
3ffffda0: ffffffff ffffffff ffffffff ffffffff
3ffffdb0: ffffffff ffffffff ffffffff ffffffff
3ffffdc0: ffffffff ffffffff ffffffff ffffffff
3ffffdd0: ffffffff ffffffff ffffffff ffffffff
3ffffde0: ffffffff ffffffff ffffffff ffffffff
3ffffdf0: ffffffff ffffffff ffffffff ffffffff
3ffffe00: ffffffff ffffffff ffffffff ffffffff
3ffffe10: ffffffff ffffffff ffffffff ffffffff
3ffffe20: ffffffff ffffffff ffffffff ffffffff
3ffffe30: ffffffff ffffffff ffffffff ffffffff
3ffffe40: ffffffff 00000003 ffffffff ffffffff
3ffffe50: ffffffff ffffffff ffffffff ffffffff
3ffffe60: ffffffff ffffffff ffffffff ffff0064
3ffffe70: 00000000 00000000 ffffffff ffffffff
3ffffe80: ffffffff ffffffff ffffffff ffffffff
3ffffe90: ffffffff ffffffff ffffffff ffffffff
3ffffea0: ffffffff ffffffff ffffffff ffffffff
3ffffeb0: ffffffff ffffffff ffffffff ffffffff
3ffffec0: ffffffff ffffffff ffffffff ffffffff
3ffffed0: ffffffff ffffffff ffffffff ffffffff
3ffffee0: ffffffff ffffffff ffffffff ffffffff
3ffffef0: ffffffff ffffffff ffffffff ffffffff
3fffff00: ffffffff ffffffff ffffffff ffffffff
3fffff10: ffffffff ffffffff ffffffff ffffffff
3fffff20: ffffffff ffffffff ffffffff ffffffff
3fffff30: ffffffff ffffffff ffffffff ffffffff
3fffff40: ffffffff ffffffff ffffffff ffffffff
3fffff50: ffffffff ffffffff ffffffff ffffffff
3fffff60: ffffffff ffffffff ffffffff ffffffff
3fffff70: ffffffff ffffffff ffffffff ffffffff
3fffff80: ffffffff 00000000 00000000 00000000
3fffff90: ffff0000 40234e80 40235b28 4023a498
3fffffa0: 400002e9 4023b0b4 ffffff00 55aa55aa
================================================================
Also das ist ein Absturz des Controllers, bin ich mir sicher. Diese Buchstaben-Suppe ist vermtl. ein Memory-Dump.
Ich denke, dass er, wie du ja auch schon vermutet hast, einfach einen "weg" hat. Nimm doch einfach einen neuen :)
Oder die Spannungsversorgung bricht ein, das sieht dann genau so aus!
Das mit der Spannungsversorgung teste ich mal mit einem 3,3 V. Netzteil. Kann dann aber nur sein das der DC/DC Wandler einbricht. Messen konnte man aber nichts, war immer konstant auf 3,3 Volt am Ausgang. Hatte die ganze Zeit ein Messgerät dran.
Mit dem einfach einen neuen nehmen ist so eine Sache, muss den alten erst mal runter bekommen. :o :'(
Zitat von: Markus. am 15 Dezember 2017, 21:48:26
Mit dem einfach einen neuen nehmen ist so eine Sache, muss den alten erst mal runter bekommen. :o :'(
Ja das ist in der Tat sehr bescheiden, daher jetzt auch meine Idee der NoSMD Variante ....
An dem "wieder Runterbekommen" bin ich auch schonmal total verzweifelt nachdem ich ca. 1 Stunde mit Entlötpumpe und -litze hantiert hatte. Dann hat mir ein Kollege den Tipp gegeben, dass man "einfach" eine Seite des ESPs komplett mit Zinn benetzt, so dass die ganze Seite flüssig wird (an einem Stück). Die kann man dann anheben. Dann das gleiche auf der zweiten Seite.
Mit der Methode hatte ich das Ding dann innerhalb von 3 Minuten runter. Da war ich total begeistert...
Mit einem Heißluftföhn? Naja den hab ich nicht... :–(
Muss mal sehen ...
Zitat von: Markus. am 16 Dezember 2017, 07:07:50
Mit einem Heißluftföhn? Naja den hab ich nicht... :–(
Muss mal sehen ...
Nein, ich meinte Lötkolben dran halten :)
Gesendet von meinem SM-G950F mit Tapatalk
Ich hab hier noch was anderes:
Und zwar hab ich mal die Firmware auf Sming 3.5.0 upgedatet. Hatte eh schon länger mal vor, das Sming zu updaten und ich dachte jetzt, es könnte evtl. auch für die Probleme mit dem Wemos D1 helfen (der jetzt aber eh schon läuft ;)).
Jedenfalls hab ich mal eine FW gebaut mit Sming 3.5.0 und vielleicht hat mal jemand Lust, die auch mal bei sich testweise laufen zu lassen. Eigentlich erwarte ich keine Probleme, aber man weiß ja nie ;)
Also gerne Bescheid geben, wenn seltsames Verhalten auffällt, danke! Bei mir sieht hier aber erstmal alles ok aus.
Update über diesen Link per OTA:
http://rgbww.dronezone.de/sming35/version.json
Bitte auch das FHEM-Modul auf den neuesten Stand updaten (ist in beide Richtung kompatibel).
Ist dann Version "vbs13b".
Werde ich gleich mal Update, wegen den Wemos und so :D ;)
Hast Du eigentlich für dich schon mal paar Lichtspiele gebaut ?
Das OTA funktioniert anscheinend nicht nach dem Reboot habe ich noch die "Alte" drauf.
Probier nochmal... das Symptom hatte ich auch aber beim 2. mal hat er es dann genommen
Sorry mein Fehler, ich hatte die Version. Json noch nicht geändert. Dachte es merkt keiner... Ist behoben, sry
Gesendet von meinem SM-G950F mit Tapatalk
Scheint alles sauber zu laufen :)
Edit:
Na doch nicht 100%ig, wenn man auf dem Controller direkt mit der Farbe spielt stützt er ab und rebootet.
Zitat von: Shojo am 16 Dezember 2017, 14:47:48
Scheint alles sauber zu laufen :)
Edit:
Na doch nicht 100%ig, wenn man auf dem Controller direkt mit der Farbe spielt stützt er ab und rebootet.
Das konnte ich nicht feststellen. Hab gerade mal einen versorgt mit der Firmware und auch über den Controller konnte ich die Farben einstellen ohne Absturz.
Gruß
Markus
Zitat von: Markus. am 16 Dezember 2017, 16:26:44
Das konnte ich nicht feststellen.
Habe es jetzt nochmals probiert, das Webif hat sofort immer wieder die Verbindung zum Controller verloren und dann irgendwann reboot.
Hm, ich kann das hier auch erstmal so nicht reproduzieren, unschön :-[
Danke, dass ihr das gleich aufgespielt und getestet habt!
Ja ich habe nicht viel gemacht, einfach schnell mehrmals die Farben hin und her gestellt (über das Webif)
und schon hing er.
nicht das es was damit zu tun hat, das ich ursprünglich Patricks Firmware drauf hatte und dann die VBS FW per OTA installiert habe.
Komischerweise hatte ich bei einem neuen den ich heute gebaut habe (ESP12 F) wieder das Problem das kein AP auf gemacht wurde.
Habe dann mit Patricks FW die WLAN Konfig gemacht und per OTA die VBS FW drauf. Seit dem läuft er ohne zu zicken...
Gruß
Markus
stop... stimmt... wenn man ihn übers WebIf richtig stresst mit Farbenwechsel bekommt man ihn zum reboot....
Kann ich eigentlich die Update URL irgendwie dauerhaft auch im webif ändern?
Ja musst Du nur eintragen und unten recht auf dem Button drücken ;)
Ich habe Das gute Stück nun so eingebunden.
Wie mache ich das am besten wenn ich weich und langsam die Farben im endlos Loop wechseln lassen möchte?
Hat da wer schon mal was gemacht? (Habe heute eine Feier, und wollte bissel posen ;) )
Internals:
DEF 192.168.0.125
DeviceName 192.168.0.125:9090
FD 13
IP 192.168.0.125
LAST_RECV 1513441822.72347
NAME WZ.Licht.RGB.Fensterfront
NR 412
NTFY_ORDER 50-BU.EspLedController
PARTIAL
PORT 9090
STATE on
TYPE EspLedController
READINGS:
2017-12-16 16:43:50 colorMode hsv
2017-12-16 17:30:23 config-color-brightness-blue 100
2017-12-16 17:30:23 config-color-brightness-cw 100
2017-12-16 17:30:23 config-color-brightness-green 100
2017-12-16 17:30:23 config-color-brightness-red 100
2017-12-16 17:30:23 config-color-brightness-ww 100
2017-12-16 17:30:23 config-color-colortemp-cw 6000
2017-12-16 17:30:23 config-color-colortemp-ww 2700
2017-12-16 17:30:23 config-color-hsv-blue 0
2017-12-16 17:30:23 config-color-hsv-cyan 0
2017-12-16 17:30:23 config-color-hsv-green 0
2017-12-16 17:30:23 config-color-hsv-magenta 0
2017-12-16 17:30:23 config-color-hsv-model 0
2017-12-16 17:30:23 config-color-hsv-red 0
2017-12-16 17:30:23 config-color-hsv-yellow 0
2017-12-16 17:30:23 config-color-outputmode 1
2017-12-16 17:30:23 config-events-color_interval_ms 500
2017-12-16 17:30:23 config-events-server_enabled 1
2017-12-16 17:30:23 config-general-device_name WZ.Licht.RGB.Fensterfront
2017-12-16 17:30:23 config-general-pin_config 2,4,5,14,12
2017-12-16 17:30:23 config-network-ap-password rgbwwctrl
2017-12-16 17:30:23 config-network-ap-secured 0
2017-12-16 17:30:23 config-network-ap-ssid WZ.Licht.RGB.Fensterfront
2017-12-16 17:30:23 config-network-connection-dhcp 0
2017-12-16 17:30:23 config-network-connection-gateway 192.168.0.254
2017-12-16 17:30:23 config-network-connection-ip 192.168.0.125
2017-12-16 17:30:23 config-network-connection-netmask 255.255.255.0
2017-12-16 17:30:23 config-network-mqtt-enabled 0
2017-12-16 17:30:23 config-network-mqtt-password
2017-12-16 17:30:23 config-network-mqtt-port 1883
2017-12-16 17:30:23 config-network-mqtt-server mqtt.local
2017-12-16 17:30:23 config-network-mqtt-topic_base home/
2017-12-16 17:30:23 config-network-mqtt-username
2017-12-16 17:30:23 config-ota-url http://rgbww.dronezone.de/testing/version.json
2017-12-16 17:30:23 config-security-api_secured 0
2017-12-16 17:30:23 config-sync-clock_master_enabled 0
2017-12-16 17:30:23 config-sync-clock_master_interval 30
2017-12-16 17:30:23 config-sync-clock_slave_enabled 0
2017-12-16 17:30:23 config-sync-clock_slave_topic home/led1/clock
2017-12-16 17:30:23 config-sync-cmd_master_enabled 0
2017-12-16 17:30:23 config-sync-cmd_slave_enabled 0
2017-12-16 17:30:23 config-sync-cmd_slave_topic home/led1/command
2017-12-16 17:30:23 config-sync-color_master_enabled 0
2017-12-16 17:30:23 config-sync-color_master_interval_ms 0
2017-12-16 17:30:23 config-sync-color_slave_enabled 0
2017-12-16 17:30:23 config-sync-color_slave_topic home/led1/color
2017-12-16 17:30:23 ct 0
2017-12-16 17:30:23 hsv 303.87,55.03,100
2017-12-16 17:30:23 hue 303.87
2017-12-16 17:30:23 info-deviceid 3766092
2017-12-16 17:30:23 info-firmware 0.3.1-vbs12
2017-12-16 17:30:23 info-mac 60019439774c
2017-12-16 17:30:23 raw_blue 526
2017-12-16 17:30:23 raw_cw 0
2017-12-16 17:30:23 raw_green 0
2017-12-16 17:30:23 raw_red 563
2017-12-16 17:30:23 raw_ww 460
2017-12-16 17:30:23 rgb ff73f8
2017-12-16 17:30:23 sat 55.03
2017-12-16 17:30:22 state opened
2017-12-16 17:30:23 stateLight on
2017-12-16 17:30:23 val 100
helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
group Licht
icon light_led_stripe_rgb
room 1.1_Wohnzimmer
stateFormat stateLight
webCmd rgb:on:off
widgetOverride rgb:colorpicker,HSV
Am einfachsten ist, wenn du sowas machst:
set wz_lightLedCouch hue +90 10 r
Also hue um 90 Grad faden über einen Zeitpunkt von 10 Sekunden und das Ganze mir "r" requeuen, läuft dann also in einer Schleife.
Sowas?
EDIT:
Für Extra-Kudos kannst du auch parallel dazu die Sättigung immer zwischen 20 und 100 faden:
set wz_lightLedCouch sat 20 10 qr;set wz_lightLedCouch sat 100 10 qr
Ja das schon Geil! 8)
Ich kann diese Reboots bei euch irgendwie nicht reproduzieren :(
Was ich mache:
Im WebIf auf Seite "Start" bewege ich die Maus hoch und runter auf der vertikalen Hue-Leiste und drücke dabei wie irre (so 6-7 mal pro Sekunde). Das halte ich so 30 Sekunden durch. Leider passiert nix (also nur Farbwechsel halt).
Hat jemand noch Tipps? Und ist das wirklich so, dass das bei der vbs12 funktioniert und nur bei vbs13b auftritt?
also habs auch nur einziges mal hin bekommen. Keine Ahnung wie ich das gemacht habe.
beide vbs12 habe ich es noch garnicht getestet.
Gruß
Markus
Neuer Tag neues Glück...
Jetzt stürzt der Controller anscheinend nicht mehr ab! :)
Aber das Modul hat ein Komisches verhalt und scheint auch die Verbindung dann zu verlieren.
Hier mal ein kleines Video dazu:
https://youtu.be/_ZNpVprI6vM (https://youtu.be/_ZNpVprI6vM)
Zitat von: vbs am 15 Dezember 2017, 15:33:34
Kannst du bitte mal auf verbose 4 stellen und mal ein Log über 3-4 Minuten posten?
Sollte ungefähr so aussehen:
Also alle 60 Sekunden sollte sich der Controller melden, was im Log als "keep_alive received" auftaucht. Wenn das nicht auftaucht, dann ist das die Ursache.
Letzte Nacht hat der Controller wieder die Verbindung kurz verloren und die Logeinträge waren sofort wieder da. Mit verbose 4 kommt:
2017.12.17 13:00:17 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:00:17 3: Bel_Wohnwand: got info response
2017.12.17 13:00:17 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:01:37 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.0365588665009 s ago
2017.12.17 13:01:37 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:01:38 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:01:38 3: Bel_Wohnwand: got info response
2017.12.17 13:01:38 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:02:58 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.155298948288 s ago
2017.12.17 13:02:58 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:02:58 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:02:58 3: Bel_Wohnwand: got info response
2017.12.17 13:02:58 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:04:18 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.2375869750977 s ago
2017.12.17 13:04:18 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:04:18 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:04:19 3: Bel_Wohnwand: got info response
2017.12.17 13:04:19 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:05:05 4: Bel_Wohnwand attrib verbose set 4
2017.12.17 13:05:08 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 50.1994290351868 s ago
2017.12.17 13:05:18 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 60.2091879844666 s ago
2017.12.17 13:05:29 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 70.2702670097351 s ago
2017.12.17 13:05:39 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.2763390541077 s ago
2017.12.17 13:05:39 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:05:39 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:05:39 4: Bel_Wohnwand: got config response
2017.12.17 13:05:39 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:05:39 4: Bel_Wohnwand: got config response
2017.12.17 13:05:39 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:05:39 3: Bel_Wohnwand: got info response
2017.12.17 13:05:39 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:05:39 4: Bel_Wohnwand: got color response
2017.12.17 13:05:49 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 10.0048401355743 s ago
2017.12.17 13:05:59 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 20.0107982158661 s ago
2017.12.17 13:06:09 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 30.0170300006866 s ago
2017.12.17 13:06:19 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 40.0200161933899 s ago
2017.12.17 13:06:29 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 50.0254080295563 s ago
2017.12.17 13:06:39 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 60.0324761867523 s ago
2017.12.17 13:06:49 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 70.1154930591583 s ago
2017.12.17 13:06:59 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.1221740245819 s ago
2017.12.17 13:06:59 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:06:59 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:06:59 4: Bel_Wohnwand: got config response
2017.12.17 13:06:59 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:07:00 4: Bel_Wohnwand: got config response
2017.12.17 13:07:00 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:07:00 3: Bel_Wohnwand: got info response
2017.12.17 13:07:00 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:07:00 4: Bel_Wohnwand: got color response
2017.12.17 13:07:09 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 10.0052890777588 s ago
2017.12.17 13:07:19 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 20.0092520713806 s ago
2017.12.17 13:07:29 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 30.0126061439514 s ago
2017.12.17 13:07:39 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 40.0163061618805 s ago
2017.12.17 13:07:49 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 50.0199720859528 s ago
2017.12.17 13:07:59 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 60.0305690765381 s ago
2017.12.17 13:08:09 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 70.0370740890503 s ago
2017.12.17 13:08:19 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 80.0439720153809 s ago
2017.12.17 13:08:19 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.17 13:08:19 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.17 13:08:20 4: Bel_Wohnwand: got config response
2017.12.17 13:08:20 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:08:20 4: Bel_Wohnwand: got config response
2017.12.17 13:08:20 4: Bel_Wohnwand: config response data {"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW_Wohnz"},"mqtt":{"enabled":false,"server":"","port":0,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":1,"hsv":{"model":0,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":0,"green":0,"blue":0,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"server_enabled":true},"general":{"device_name":"Bel_Wohnwand","pin_config":"13,12,14,5,4"}}
2017.12.17 13:08:20 3: Bel_Wohnwand: got info response
2017.12.17 13:08:20 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"Home TS 1","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"2c3ae814d232"}}
2017.12.17 13:08:20 4: Bel_Wohnwand: got color response
2017.12.17 13:08:29 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 10.0048580169678 s ago
2017.12.17 13:08:39 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 20.0273439884186 s ago
2017.12.17 13:08:49 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 30.034460067749 s ago
2017.12.17 13:08:59 4: Bel_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 40.0387399196625 s ago
Das passiert sobald der Controller einmal die Verbindung verliert. Da ich ihn über einen dLan AP betreibe passiert das leider so 1 bis 3 mal am Tag.
Wenn ich jetzt FHEM neu starte sind die Meldungen bis zum nächsten Verbindungsverlust weg.
Steuern kann ich den Controller aber weiterhin über FHEM.
Hm, hab eine Theorie. Ich konnte so ein Szenario auch nachstellen.
Hast du evtl. versehentlich irgendwo in FHEM ein zweites Device angelegt, welches mit demselben Controller verbunden ist? Wenn man das nämlich macht, dann sieht das genauso aus, weil dann einer von den beiden die KeepAlive-Nachrichten nicht bekommt:
2017.12.17 14:52:40.806 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 10.0029561519623 s ago
2017.12.17 14:52:50.812 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 20.0082631111145 s ago
2017.12.17 14:53:00.811 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 30.0078921318054 s ago
2017.12.17 14:53:10.816 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 40.0130181312561 s ago
2017.12.17 14:53:20.821 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 50.0175440311432 s ago
2017.12.17 14:53:30.823 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 60.0200531482697 s ago
2017.12.17 14:53:40.827 4 : led2: EspLedController_CheckConnection: Connection still alive. Last data received 70.0240700244904 s ago
2017.12.17 14:53:50.820 3 : led2: EspLedController_CheckConnection: Connection lost! Last data received 80.0164501667023 s ago
2017.12.17 14:53:50.820 1 : 192.168.2.44:9090 disconnected, waiting to reappear (led2)
Gehe ich richtig in der Annahme, dass du den Controller zwar steuern kannst, aber keine Echtzeit-Farbupdates bekommst?
@Shojo
Bin am Grübeln... kann aber leider auch das erstmal so nicht nachstellen. Melde mich wieder ;)
Zitat von: vbs am 17 Dezember 2017, 14:56:01
Hast du evtl. versehentlich irgendwo in FHEM ein zweites Device angelegt, welches mit demselben Controller verbunden ist? Wenn man das nämlich macht, dann sieht das genauso aus, weil dann einer von den beiden die KeepAlive-Nachrichten nicht bekommt:
Gehe ich richtig in der Annahme, dass du den Controller zwar steuern kannst, aber keine Echtzeit-Farbupdates bekommst?
Ich habe zwar 3 Devices in FHEM, aber die beiden anderen haben andere IP's, die Controller sind aber zur Zeit nicht eingeschaltet.
Farbupdates bekomme ich mit ca. 30 sec Verspätung.
Hm, wie ich es drehe und wende, ich finde keine andere Erklärung. Ein Bug ist mir aber aufgefallen: der Controller soll eigentlich bis zu 4 TCP-Verbindungen verwalten können. Nun ist es aber so, dass offenbar nur die erste Verbindung mit Daten versorgt wird. Weitere werden zwar aufgebaut, aber sehen nie Daten. Ich werde versuchen, das zu fixen.
Also meine beste Erklärung ist weiterhin, dass irgendwer bzw. irgendwas auch eine Verbindung auf den Controller hat. Geht um Port 9090. Wenn sich dann FHEM (als zweite Verbindung) auch verbindet, ergibt das genau deinen Effekt.
Versuch mal bitte, dem Controller eine andere IP zu geben und dann diese IP nur bei dem einen Device in FHEM anzugeben, so dass hoffentlich niemand anders eine Chance hat, sich auch zu verbinden. Und dann sag mal bitte, ob es dann immer noch auftritt.
Ich hab mal das Handling der TCP-Verbindungen des Event-Servers gefixt. Es werden jetzt bis zu 5 Verbindungen korrekt verwaltet (denke ich!). Ich denke, dass es dein Problem beheben wird, ABER ich glaube weiterhin, dass irgendjemand auch auf dem Controller hängt.
Hab das erstmal hier mit in diesen Stand reingebaut (vbs14b):
http://rgbww.dronezone.de/sming35/version.json
Da sind auch ein paar neue Readings drin:
info-current_rom_slot 0
info-event_num_clients 3
info-sming_version 3.5.0
Also "info-event_num_clients" zeigt die Anzahl der verbundenen TCP-Clients (Port 9090). Sollte im Normalfall 1 sein (das FHEM-Modul). Du kannst ja mal gucken, ob das bei dir irgendwas größer 1 ist. Die Readings muss man aber händisch per "get info" updaten.
Dazu ist das neueste FHEM-Modul auch nötig.
Zitat von: vbs am 17 Dezember 2017, 18:43:30
Da sind auch ein paar neue Readings drin:
info-current_rom_slot 0
info-event_num_clients 3
info-sming_version 3.5.0
Die tauchen bei mir nicht auf.
bin von der 12er auf die aktuelle sming...
nun wird bei mir nur noch dauerhaft weiße seite angezeigt
Gebe mal http://<Deine IP>/webapp ein.
ja du hast recht... es geht aber die weiterleitung geht nicht mehr auf /webapp
Zitat von: kmxak am 17 Dezember 2017, 20:03:02es geht aber die weiterleitung geht nicht mehr auf /webapp
ja das kann ich bestätigen.
Sorry, hatte das FHEM-Update mal wieder falsch bedient. Wir beiden werden wohl keine Freunde mehr...
Bitte nochmal FHEM-Modul updaten, dann sollte es da sein.
Ja die Weiterleitung ist hinüber leider (schon länger). Ich kann die Webapp nicht neu bauen im Moment. Das ist noch 1:1 die aus der Original-FW.
was ist denn daran kaputt? ist das nur html?
Das ist eine Angular-App. Doku dazu von Patrick ist hier: https://github.com/patrickjahns/esp_rgbww_webinterface
Das ist nicht so ganz meine Welt und ich hatte es dann recht schnell aufgegeben. Das läuft über den Paket-Manager npm. Mein Problem war irgendwie, dass einige Pakete auf einem neueren Stand waren (ggü. Patrick's Original-Bau) und dann passte irgendwas nicht mehr zusammen. Soweit ich das verstehe, kann man das alles unabhängig von der Firmware bauen. Also wenn da jemand mit etwas mehr Ahnung mal einen Versuch starten möchte, wäre das natürlich super.
Das muss aber nichts mit dem Weiterleitungs-Problem zu tun haben. Ich weiß nicht, woran das liegt im Moment.
Was soll den an der Webapp gemacht werden ?
Ich glaub der Redirect funzt jetzt in vbs15b 8)
Da fehlte einfach nur ein entsprechender HTTP status code. Hab jetzt 308 genommen, ich hoffe das war eine gute Wahl...
EDIT:
Bei der Webapp könnte man theoretisch Einstell-Seiten für die neuen Konfigurationsoptionen machen zum Beispiel. Aber ehrlicherweise gesagt, benutze ich selbst die Webapp nur zur Erstinbetriebnahme. Den Rest mache ich dann unter FHEM. Daher fehlt mir da persönlich nichts. Aber es mag sicherlich Leute geben, die das anders betreiben.
Japp läuft 8)
Ich hab mal die Struktur in den OTA-URLs bzw. die Varianten etwas aufgeräumt. Die aktuelle 'testing' ist jetzt 'release' geworden und 'sming35' ist 'testing' geworden. 'release' ist damit ab sofort die "normale" Version (war ja vorher 'testing').
Also ab jetzt:
http://rgbww.dronezone.de/release/version.json -> vbs12
http://rgbww.dronezone.de/testing/version.json -> vbs15b
Was hat das eigentlich mit den Calculation Model auf sich ?
Kann ich im Detail nicht sagen. Scheinen verschiedene Methoden zu sein, um HSV zu RGB umzurechnen:
https://github.com/verybadsoldier/RGBWWLed/blob/master/RGBWWLedColor.cpp#L197
Zitat von: vbs am 17 Dezember 2017, 20:50:17
Bei der Webapp könnte man theoretisch Einstell-Seiten für die neuen Konfigurationsoptionen machen zum Beispiel.
Ja das HTML und JS wäre jetzt kein Problem, bloß ich bin zu blöd das zu kompilieren :-X
Hm, habs gerade noch einmal probiert und doch, bauen tuts bei mir, aber hinterher war das auf dem Controller irgendwie einiges buggy. Aber bauen sieht so aus:
vbs@ubuntu:~/Projects/esp_rgbww_webinterface$ npm run release
> rgbww-webapp@0.3.3 release /home/vbs/Projects/esp_rgbww_webinterface
> npm run init && grunt release
> rgbww-webapp@0.3.3 init /home/vbs/Projects/esp_rgbww_webinterface
> npm install && npm install bower && bower install
npm WARN deprecated bower@1.8.2: ...psst! Your project can stop working at any moment because its dependencies can change. Prevent this by migrating to Yarn: https://bower.io/blog/2017/how-to-migrate-away-from-bower/
rgbww-webapp@0.3.3 /home/vbs/Projects/esp_rgbww_webinterface
└── bower@1.8.2 extraneous
npm WARN deprecated bower@1.8.2: ...psst! Your project can stop working at any moment because its dependencies can change. Prevent this by migrating to Yarn: https://bower.io/blog/2017/how-to-migrate-away-from-bower/
rgbww-webapp@0.3.3 /home/vbs/Projects/esp_rgbww_webinterface
└── bower@1.8.2 extraneous
Running "ngAnnotate:app" (ngAnnotate) task
>> 1 file successfully annotated.
Running "string-replace:dist" (string-replace) task
3 files created
Running "concat:dist" (concat) task
Running "uglify:dist" (uglify) task
File build/app.min.js.map created (source map).
File build/app.min.js created: 2.72 MB → 624.93 kB
>> 1 sourcemap created.
>> 1 file created.
Running "cssmin:target" (cssmin) task
>> 1 file created. 371.58 kB → 367.54 kB
Running "compress:main" (compress) task
>> Compressed 4 files.
Running "version" task
Done, without errors.
Ich bin immer noch nicht dahinter gekommen, was da mit dem FHEM-Modul in deinem Video passiert. 0 gute Ideen leider :( Könntest du vielleicht das nochmal machen und dazu mal ein verbose4-Log machen? Video ist vermutlich nicht nochmal notwendig, wenn man den Reconnect im Log sieht.
Ich hab nicht verstanden, warum dein Icon im Webinterface von FHEM dann manchmal kurz auf "opened" springt. Du hast doch einfach stateFormat auf stateLight gesetzt, oder? Ich dachte stateLight wäre immer nur "on" oder "off".
Diese neuen Readings wie smingVersion und so klappen jetzt, vermute ich mal?
Zitat von: vbs am 18 Dezember 2017, 15:46:04
Ich bin immer noch nicht dahinter gekommen, was da mit dem FHEM-Modul in deinem Video passiert. 0 gute Ideen leider :( Könntest du vielleicht das nochmal machen und dazu mal ein verbose4-Log machen? Video ist vermutlich nicht nochmal notwendig, wenn man den Reconnect im Log sieht.
Ich hab nicht verstanden, warum dein Icon im Webinterface von FHEM dann manchmal kurz auf "opened" springt. Du hast doch einfach stateFormat auf stateLight gesetzt, oder? Ich dachte stateLight wäre immer nur "on" oder "off".
Ja habe alles (Led Controller) nochmal neu eingerichtet, und der Fehler schein weg zu sein.
Zitat von: vbs am 18 Dezember 2017, 15:46:04
Diese neuen Readings wie smingVersion und so klappen jetzt, vermute ich mal?
Ja das läuft auch alles :)
Zitat von: vbs am 17 Dezember 2017, 18:43:30
Ich hab mal das Handling der TCP-Verbindungen des Event-Servers gefixt. Es werden jetzt bis zu 5 Verbindungen korrekt verwaltet (denke ich!). Ich denke, dass es dein Problem beheben wird, ABER ich glaube weiterhin, dass irgendjemand auch auf dem Controller hängt.
Hab das erstmal hier mit in diesen Stand reingebaut (vbs14b):
http://rgbww.dronezone.de/sming35/version.json
Da sind auch ein paar neue Readings drin:
info-current_rom_slot 0
info-event_num_clients 3
info-sming_version 3.5.0
Hab jetzt die Version vbs15b und auch die neueste FHEM EspLedController Version, aber die Info Readings tauchen bei mir nicht auf.
Hast du das FHEM-Modul upgedatet?
EDIT:
Sorry, lesen und so...
Hast du mal versucht, "get info" manuell aufzurufen? Danach noch mit F5 die Browserseite refreshen.
Hab update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt eingetragen.
Beim update sage er immer er wäre auf den neusten Stand. Hab jetzt mal 32_EspLedController.pm aus dem FHEM Verzeichnis gelöscht und dann nochmal ein update gemacht. Jetzt scheine ich eine andere Version zu haben, die Infos sind da.
info-current_rom_slot 0
info-deviceid 1364530
info-event_num_clients 1
Mal sehen was beim nächsten Verbindungsabbruch passiert.
Nabend,
eine Frage, gibt es für das Board jetzt zwei unterschiedliche Firmware Versionen? Ich hab die originale drauf (mrpj) zusammen mit dem LedController Modul, was aber irgendwie nicht funktioniert, also es geht schon aber viel mehr als an und aus ist nicht möglich.
Ist das jetzt hier die Fortsetzung oder ein neuer Zweig? Ich sehe gerade nicht ganz durch, daher wollte ich mal nachfragen.
/Daniel
Zitat von: ext23 am 19 Dezember 2017, 18:01:38
eine Frage, gibt es für das Board jetzt zwei unterschiedliche Firmware Versionen?
Ja genau, das ist eine weiterentwickeln der "Originalen" Firmware.
Zitat von: ext23 am 19 Dezember 2017, 18:01:38
Ist das jetzt hier die Fortsetzung oder ein neuer Zweig?
Das ist eine gute Frage, keine Ahnung wie das geplant ist :)
Danke für den Hinweis. Ich werde das im ersten Posten nochmal klar stellen. Manchmal sieht man den Wald vor lauter Bäumen nicht ;)
Ist das jetzt hier die Fortsetzung oder ein neuer Zweig?
Die FW basiert auf der Original-FW von Patrick, aber hat im Laufe der Zeit einige Änderungen/Erweiterungen erfahren. Ursprünglich hatte ich gehofft, dass die Änderungen evtl. zurück in die Original-FW fließen könnten. Ich hab aber von Peter (dem aktuellen Maintainer?) bisher keine Rückmeldung zu den Änderungen bekommen können (was völlig ok ist, wenn er beschäftigt ist oder warum auch immer). Jedenfalls ist es daher jetzt ein richtiger Fork geworden.
OK gut, naja macht ja Sinn sich für eine zu entscheiden.
Mittlerweile geht mit der original Firmware auch etwas mehr, da habe ich vermutlich was falsch gemacht bei meinen ersten Versuchen. Aber ich würde gerne automatisierte Farbverläufe erstellen etc.
Wenn ich das also richtig sehe macht es Sinn auf deine Version zu wechseln, da hier im Moment mehr Arbeit rein gesteckt wird. (Ohne da jetzt Peter auf den Schlips zu treten)
/Daniel
Zitat von: hanswerner1 am 18 Dezember 2017, 21:33:26
Hab update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt eingetragen.
Beim update sage er immer er wäre auf den neusten Stand. Hab jetzt mal 32_EspLedController.pm aus dem FHEM Verzeichnis gelöscht und dann nochmal ein update gemacht. Jetzt scheine ich eine andere Version zu haben, die Infos sind da.
info-current_rom_slot 0
info-deviceid 1364530
info-event_num_clients 1
Mal sehen was beim nächsten Verbindungsabbruch passiert.
Hatte bisher noch keinen Verbindungsabbruch, wenn mann darauf wartet passiert es natürlich nicht. :)
Melde mich sobald ich sagen kann ob die Meldungen noch kommen.
Hallo,
EDIT: es wäre besser gewesen, ich hätte die Suche schon eher benutzt... Es hat sich wohl erledigt, da man mqtt nur über Fhem aktivieren kann: set config xy config-network-mqtt-enabled 1
Werde das morgen ausprobieren.
kann mir jemand helfen, warum ich mqtt nicht aktivieren kann? Das Feld zum aktivieren ist ausgegraut und lässt sich nicht aktivieren.
Ich habe es mit dem Chrome und IE Browser versucht. Der Import Settings Button ist ebenso ausgegraut, sonst hätte ich es darüber aktiviert.
Kann es evtl. an der rboot.bin liegen? Ich hatte die von patrickjahns verwendet, da ich eine rboot.bin von vbs nicht gefunden habe.
Ich habe folgende Firmware (stable & testing) ausprobiert:
Firmware
0.3.1-vbs12
(vbs8-6-g1632-dirty)
Web Interface
0.3.3
RGBWW Version
0.8.1-vbs4
SMING Version
3.1.2
Firmware
0.3.1-vbs15b
(vbs8-12-ge62d-dirty)
Web Interface
0.3.3
RGBWW Version
0.8.1-vbs4
SMING Version
3.5.0
Grüße
Mark
Zitat von: hanswerner1 am 21 Dezember 2017, 09:55:43
Hatte bisher noch keinen Verbindungsabbruch, wenn mann darauf wartet passiert es natürlich nicht. :)
Melde mich sobald ich sagen kann ob die Meldungen noch kommen.
Heute hatte ich wieder 3 Verbindungsabbrüche und die Meldung kam nur noch einmal nachdem die Verbindung wieder aufgebaut war.
2017.12.24 11:50:37 3: Bel_Wohnwand: EspLedController_CheckConnection: Connection lost! Last data received 81.5917930603027 s ago
2017.12.24 11:50:37 1: 192.168.0.67:9090 disconnected, waiting to reappear (Bel_Wohnwand)
2017.12.24 11:50:38 1: 192.168.0.67:9090 reappeared (Bel_Wohnwand)
2017.12.24 11:51:03 3: Bel_Wohnwand: got info response
2017.12.24 11:51:03 3: Bel_Wohnwand: info response data {"deviceid":"1364530","current_rom":"1","firmware":"0.3.1-vbs12","git_version":"vbs8-6-g1632-dirty","git_date":"2017-12-07","sming":"3.1.2","rgbww":{"version":"0.8.1-vbs4","queuesize":100},"connection":{"connected":true,"ssid":"xxxxxxxxx","dhcp":true,"ip":"192.168.0.67","netmask":"255.255.255.0","gateway":"192.168.0.10","mac":"xxxxxxxxx"}}
Ich glaube das Problem lang nicht an der Controller FW, hab aktuell die vbs12 drin, lang eher am FHEM Plugin. Nachdem ich händisch das Plugin gelöscht habe und per update die neue Version eingespielt hab scheint es zu laufen.
Ok, komisch, aber was soll's :)
@Shojo:
Hat sich bei dir noch etwas ergeben bzgl. deiner sporadischen Reboots oder sind die jetzt Geschichte? Würde trotzdem ein ungutes Gefühl hinterlassen, da ich weiterhin keine Ahnung habe, was da los war :(
Ich würde gerne die aktuelle Testing-Variante zur Stable erklären (inkl. Sming 3.5.0). Bei mir läuft's stabil und ansonsten hab ich auch keine weiteren Beschwerden gehört. Ist das ok eurer Meinung nach?
Wünsche euch allen schonmal ein frohes Fest! :)
Zitat von: vbs am 24 Dezember 2017, 15:16:36
@Shojo:
Hat sich bei dir noch etwas ergeben bzgl. deiner sporadischen Reboots oder sind die jetzt Geschichte?
Die scheinen nun Geschichte zu sein :)
Zitat von: vbs am 24 Dezember 2017, 15:16:36
Bei mir läuft's stabil und ansonsten hab ich auch keine weiteren Beschwerden gehört. Ist das ok eurer Meinung nach?
Denke schon :)
Zitat von: vbs am 24 Dezember 2017, 15:16:36
Wünsche euch allen schonmal ein frohes Fest! :)
Das wünsche ich Dir auch!
Hallo Zusammen,
ist denn jetzt die OTA URL
http://rgbww.dronezone.de/release/version.json (http://rgbww.dronezone.de/release/version.json)
mit SMING 3.5 ?
Gruß
Markus
Ja, jetzt schon. :) Hab eine vbs16 in dem "release"-Pfad gemacht. "testing" ist auch erstmal diese vbs16.
habs gerade gesehn...;-)
Vielen Dank für die klasse Arbeit!!
Gruß
Markus
Danke dir! :)
Hallo VBS,
wenn ich dem controller aus fhem per set ein off sende, passiert nichts, wenn ich ein val 0 sende, dann gehen die Stripes aus.
Ist der Befehl off für was anderes gedacht?
Fhem und Controller ist auf der neuesten Version vbs16.
gruss
lewej
Nee, ist eigentlich wie du vermutest. Klingt dann wie ein Bug. Hast du schon auf "EspLedController" gewechselt? Mach doch bitte mal ein verbose5-Log sowohl von dem off-Command als auch vom val0-Command.
Zitat von: vbs am 29 Dezember 2017, 13:04:18
Hast du schon auf "EspLedController" gewechselt?
Muss man irgendwas beachten wovon ich nichts mitbekommen habe?
Zitat von: vbs am 18 April 2017, 09:26:13
FHEM Modul
Ich hab auch das FHEM-Modul angepasst, so dass die Features (alle?) auch direkt aus FHEM heraus verwendet werden können. Auch dazu hier ein bisschen Dokumentation:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki (https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki)
Um diese Version des Moduls von der Original-Version "32_LedController" unterscheiden zu können und damit beide Version auf einem System parallel betrieben werden können, heißt diese Version hier "32_EspLedController".
Das Modul kann als FHEM-Repository eingebunden und upgedatet werden:
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt
Achtung:
Bis Dez. 2017 hieß das Modul ebenfalls "32_LedController" und wurde nachträglich in "32_EspLedController" umbenannt. Der alte existiert im Git momentan noch, wird jedoch nicht mehr gepflegt. Also bitte auf den neuen Namen umstellen.
Moin,
klasse Arbeit von allen Beteiligten, sowohl bei der Hardware als auch der entsprechenden Software.
Habe das ganze bei mir vor rund einer Woche installiert (mit vbs12) , sowie dem EspLedcontroller-Modul und vorgestern erfolgreich OTA-Update (auf vbs16) gemacht.
Bei mir läuft bisher (habe noch nicht alle features durch) alles stabil.
Die Problematik "set off" tritt bei mir nicht auf, soll heißen funktioniert.
Gruß
Andreas
Hallo,
nach dem Update habe ich den Controller durchlaufen lassen, auf set off hat der controller nicht reagiert. Nach dem ich den Controller Stromlos gesetzt hatte, erst danach ging es. Bei mir ist das Stromlos setzen, sehr umständlich, muss hinter Möbel und Fernseher klettern :( :).
Falls jemand nach einem Update Probleme hat, versucht erstmal den Controller Stromlos zu setzen.
Gruß
lewej
Zitat von: lewej am 29 Dezember 2017, 12:31:17
Hallo VBS,
wenn ich dem controller aus fhem per set ein off sende, passiert nichts, wenn ich ein val 0 sende, dann gehen die Stripes aus.
Ist der Befehl off für was anderes gedacht?
Fhem und Controller ist auf der neuesten Version vbs16.
gruss
lewej
Ein Reboot hatte auch nicht geholfen?
Guten Jahresstart euch allen :)
Ich war bisher nur passiv unterwegs, von daher: vielen Dank, macht Spaß.
Ich habe einen LED Streifen: RGBW (Cold-White, 5m 60leds/m 5050 RGBW). Ich habe diesen auch entsprechend angeschlossen, wie auf der Platine (und in der der LED Doku) spezifiziert. Leider kann ich nur mit den RGB LEDs arbeiten. Die weißen LEDs bekomme ich nicht angesteuert. Das Reading "raw_cw" steht auf 0.
Ich habe schon recht viel gelesen, momentan raff ich das aber noch nicht ganz oder ggf. ist auch der Streifen am Ende.
Danke
Das Output Model ist sonst auch noch im Webinterface zu setzten.
Zitat von: Shojo am 01 Januar 2018, 21:02:45
Das Output Model ist sonst auch noch im Webinterface zu setzten.
Ja, das hatte ich bereits gesehen. Leider funktioniert es nicht. Die Seite behält auch nie den angegebenen Wert. Sobald ich die Seite neu lade, steht es wieder auf RGB. Oder gibt es da noch einen Persistenz/Speicher-Schalter?
Ja unten rechts der Harken ;) ;D
Ohhh. ::)
Schon etwas peinlich. Größer hätte das Zeichen ja gar nicht sein können. Es funktioniert.
Danke Dir vielmals!
Zitat von: dmq am 01 Januar 2018, 21:28:24
Schon etwas peinlich. Größer hätte das Zeichen ja gar nicht sein können
War mir auch das erste mal nicht aufgefallen ;)
Zitat von: dmq am 01 Januar 2018, 21:28:24
Danke Dir vielmals!
Immer gerne!
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
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.
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.
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
Klasse, gerne ;)
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!
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 :)
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.
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?
Das Reading config-network-ap-password enthält das Passwort im Klartext. Kann man das irgendwie ändern?
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?
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).
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?
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.
<versehentlichen Post gelöscht> :o
Kurze Frage dazu: kann ich mein "originales", über die Sammelbestellung (https://forum.fhem.de/index.php/topic,48918.0.html) gekauftes und bisher nicht weiter geflashtes Modul mittels neuen Modul und neuer Update-URL OTA auf den aktuellen Stand bringen? Oder muss ich einmalig die dazugehörige Firmware "online" aufspielen?
@vbs schau mal, da hat noch einer auf mein Blog ein Tipp gehabt für noch eine sehr günstige Hardware!
https://www.bastelbunker.de/esp-rgbww-wifi-led-controller-vbs-edition/#comment-43093
Zitat von: Per am 05 Januar 2018, 13:56:41
Kurze Frage dazu: kann ich mein "originales", über die Sammelbestellung (https://forum.fhem.de/index.php/topic,48918.0.html) gekauftes und bisher nicht weiter geflashtes Modul mittels neuen Modul und neuer Update-URL OTA auf den aktuellen Stand bringen? Oder muss ich einmalig die dazugehörige Firmware "online" aufspielen?
Das "müsste eigentlich"™ gehen, ich hab es aber länger nicht getestet.
Mit "online" meinst du über das Webinterface des Controllers, oder? Genau, das wäre dann die Alternative.
Zitat von: Shojo am 05 Januar 2018, 14:00:50
@vbs schau mal, da hat noch einer auf mein Blog ein Tipp gehabt für noch eine sehr günstige Hardware!
https://www.bastelbunker.de/esp-rgbww-wifi-led-controller-vbs-edition/#comment-43093
Ja das ist schick! Von diesem H801 hab ich hier im Forum auch schon mal gelesen. Sicher eine gute Alternative. Es gab "damals" auch schon Berichte, dass Leute die Firmware darauf zum Laufen gebracht haben (mit geänderte Pin-Config).
Aber mal ehrlich: nichts leuchtet schöner als selbst gelötet, oder? ;)
Zitat von: vbs am 05 Januar 2018, 14:24:06
Aber mal ehrlich: nichts leuchtet schöner als selbst gelötet, oder? ;)
Ohja, wie recht Du hast! :D
Aber schon cool zu sehen was dein "kleines" Feature general-pin_config alles so möglich macht :)
Ist aber nicht mein Verdienst! Das ist schon eine Weile her (noch auf der Original-FW) durch Verändern der Pins im Code. Hab es gefunden:
https://forum.fhem.de/index.php/topic,48918.msg524270/topicseen.html#msg524270
Ist jetzt nur einfacher geworden :)
Ach noch was....
Ich habe testweise über vier Controller eine Farbspiel laufen
set WZ.Licht.RGB.Fensterfront hue +90 5 r;
set WZ.Licht.RGB.Fensterfront sat 50 5 qr;
set WZ.Licht.RGB.Fensterfront sat 80 5 qr;
davon ist einer in Master Mode und die restlichen drei im Slave Mode.
Es wird über MQTT nur der Clock und die CMD gesync, nun laufen das schon 36 Stunden, und es sind noch alle Controller synchron.
Nicht einer läuft aus dem Ruder!
Zitat von: vbs am 05 Januar 2018, 14:21:25Mit "online" meinst du über das Webinterface des Controllers, oder?
Eigentlich meinte ich damit die serielle Schnittstelle des Controllers. Aber wenn es über das Webinterface geht, umso besser!
Zitat von: Shojo am 05 Januar 2018, 14:42:48
Es wird über MQTT nur der Clock und die CMD gesync, nun laufen das schon 36 Stunden, und es sind noch alle Controller synchron.
Nicht einer läuft aus dem Ruder!
Freut mich! An dem Feature hab ich tatsächlich ziemlich lange rumgedoktort und einige Sachen probiert, die nicht funktioniert haben... ::) Das Feature war auch der eigentliche Auslöser, warum ich angefangen hatte, an der Firmware rumzuspielen.
Die Controller haben ja weder eine gemeinsame Uhrzeit noch laufen die Quarze perfekt synchron. Die Farbanimationen laufen mit 50 Hz (also 20 ms Intervalle). Das läuft nun so, dass alle Controller permanent mitzählen, wie viele Intervalle sie bisher durchlaufen haben. Der Master schickt dann als Referenz regelmäßig per MQTT wie viele Intervalle er selbst bisher durchlaufen hat. Die Slaves vergleichen dann und passen permanent minimal (im Mikrosekundenbereich) ihre eigene Intervalldauer an, um etwas zu beschleunigen oder abzubremsen, so dass dann alle Controller immer gleich viele Intervalle durchlaufen.
Das kannst du bei den Slaves in den Readings "clockCurrentInterval" und "clockSlaveOffset" sehen. Das erste gibt die aktuelle Intervallänge an in Mikrosekunden, normal ist eben 20000 (us). Werte kleiner 20000 bedeuten, dass der Controller gerade etwas schneller als normal läuft (und umgekehrt). Das "clockSlaveOffset" ist die Anzahl an Intervallen, die der Slave dem Master hinterherhinkt bzw. ihm voraus ist. Sollte also im Idealfall 0 bzw. nicht weit davon entfernt sein. Eine 7 würde bedeuten, dass der Master dem Slave 140 ms voraus ist (7 * 20 ms).
Zitat von: vbs am 05 Januar 2018, 15:39:55
Der Master schickt dann als Referenz regelmäßig per MQTT wie viele Intervalle er selbst bisher durchlaufen hat.
Wir oft ca.? Ich mach mir da ein bissel Sorgen über mein WLAN.
/Daniel
Zitat von: ext23 am 05 Januar 2018, 16:15:43
Wir oft ca.? Ich mach mir da ein bissel Sorgen über mein WLAN.
Kann man alles einstellen, hier mal die List meines Master Device.
Internals:
DEF 192.168.0.30
DeviceName 192.168.0.30:9090
FD 64
IP 192.168.0.30
LAST_RECV 1515165655.71894
NAME WZ.Licht.RGB.Fensterfront
NR 412
NTFY_ORDER 50-WZ.Licht.RGB.Fensterfront
PARTIAL
PORT 9090
STATE on
TYPE EspLedController
READINGS:
2018-01-05 16:21:34 colorMode hsv
2018-01-05 13:22:12 config-color-brightness-blue 100
2018-01-05 13:22:12 config-color-brightness-cw 100
2018-01-05 13:22:12 config-color-brightness-green 100
2018-01-05 13:22:12 config-color-brightness-red 100
2018-01-05 13:22:12 config-color-brightness-ww 100
2018-01-05 13:22:12 config-color-colortemp-cw 6000
2018-01-05 13:22:12 config-color-colortemp-ww 2700
2018-01-05 13:22:12 config-color-hsv-blue 0
2018-01-05 13:22:12 config-color-hsv-cyan 0
2018-01-05 13:22:12 config-color-hsv-green 0
2018-01-05 13:22:12 config-color-hsv-magenta 0
2018-01-05 13:22:12 config-color-hsv-model 0
2018-01-05 13:22:12 config-color-hsv-red 0
2018-01-05 13:22:12 config-color-hsv-yellow 0
2018-01-05 13:22:12 config-color-outputmode 1
2018-01-05 13:22:12 config-events-color_interval_ms 500
2018-01-05 13:22:12 config-events-server_enabled 1
2018-01-05 13:22:12 config-general-device_name WZ.Licht.RGB.Fensterfront
2018-01-05 13:22:12 config-general-pin_config 14,4,5,15,12
2018-01-05 13:22:12 config-network-ap-password rgbwwctrl
2018-01-05 13:22:12 config-network-ap-secured 0
2018-01-05 13:22:12 config-network-ap-ssid WZ.Licht.RGB.Fensterfront
2018-01-05 13:22:12 config-network-connection-dhcp 0
2018-01-05 13:22:12 config-network-connection-gateway 192.168.0.254
2018-01-05 13:22:12 config-network-connection-ip 192.168.0.30
2018-01-05 13:22:12 config-network-connection-netmask 255.255.255.0
2018-01-05 13:22:12 config-network-mqtt-enabled 1
2018-01-05 13:22:12 config-network-mqtt-password
2018-01-05 13:22:12 config-network-mqtt-port 1883
2018-01-05 13:22:12 config-network-mqtt-server 192.168.0.251
2018-01-05 13:22:12 config-network-mqtt-topic_base Haus/Wohnzimmer/
2018-01-05 13:22:12 config-network-mqtt-username
2018-01-05 13:22:12 config-ota-url http://rgbww.dronezone.de/testing/version.json
2018-01-05 13:22:12 config-security-api_secured 0
2018-01-05 13:22:12 config-sync-clock_master_enabled 1
2018-01-05 13:22:12 config-sync-clock_master_interval 10
2018-01-05 13:22:12 config-sync-clock_slave_enabled 0
2018-01-05 13:22:12 config-sync-clock_slave_topic home/led1/clock
2018-01-05 13:22:12 config-sync-cmd_master_enabled 1
2018-01-05 13:22:12 config-sync-cmd_slave_enabled 0
2018-01-05 13:22:12 config-sync-cmd_slave_topic home/led1/command
2018-01-05 13:22:12 config-sync-color_master_enabled 0
2018-01-05 13:22:12 config-sync-color_master_interval_ms 0
2018-01-05 13:22:12 config-sync-color_slave_enabled 0
2018-01-05 13:22:12 config-sync-color_slave_topic home/led1/color
2018-01-05 16:21:34 ct 2700
2018-01-05 16:21:34 hsv 279.3,63.05,100
2018-01-05 16:21:34 hue 279.3
2018-01-05 13:22:12 info-current_rom_slot 1
2018-01-05 13:22:12 info-deviceid 3766092
2018-01-05 13:22:12 info-event_num_clients 1
2018-01-05 13:22:12 info-firmware 0.3.1-vbs18b
2018-01-05 13:22:12 info-mac 60019439774c
2018-01-05 13:22:12 info-sming_version 3.5.0
2018-01-02 16:09:57 lastFwUpdate Update successful - Restarting device...
2018-01-05 16:21:34 raw_blue 645
2018-01-05 16:21:34 raw_cw 0
2018-01-05 16:21:34 raw_green 0
2018-01-05 16:21:34 raw_red 422
2018-01-05 16:21:34 raw_ww 378
2018-01-05 16:21:34 rgb c75eff
2018-01-05 16:21:34 sat 63.05
2018-01-05 13:22:07 state opened
2018-01-05 16:21:34 stateLight on
2018-01-05 16:21:34 val 100
helper:
isBusy 0
oldVal 100
cmdQueue:
Attributes:
group Licht
icon light_led_stripe_rgb
room 0.0_Test_Zimmer,1.1_Wohnzimmer
stateFormat stateLight
webCmd toggle:on:off:rgb ff73f8:rgb 8ff2ff:rgb
widgetOverride rgb:colorpicker,HSV
Genau, danke Shojo. Das ist in dem Fall der Parameter "config-sync-clock_master_interval". Default ist 30, wird also normalerweise alle 30 Sekunden versendet.
Ich hab es bei mir mit 30 laufen und bisher keine Probleme. Könnte mir denken, dass durchaus auch deutlich größere Werte gut funktionieren. Wobei die Nachrichten aber klein sind und hoffentlich keine Probleme im WLAN machen.
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#clock-synchronization
(Hab gerade gesehen, dass im Wiki noch "10" als Default steht. Das stimmt aber nicht mehr, habs korrigiert...)
Hallo Robin,
ich würde gerne die Serielle Schnittstelle des ESP nutzen, um die einzelnen PWM Kanäle darüber EIN bzw. AUS zu schalten.
Der Hintergrund ist, dass ich ein Bussystem (openHCAN) mit ATMega Prozessoren habe, an dem ich die Controller betreiben möchte.
Die Prozessoren haben eine UART Schnittstelle integriert, die ich dazu verwenden könnte.
Somit hätte ich die Grundfunktionalität (EIN/AUS) über den Bus, und die Gimmicks (Dimmen, Farbtemperatur...) über FHEM realisiert.
Der erste Gedanke war, die Spannungsversorgung des Controllers zur Steuerung ein und aus zu schalten.
Jedoch ist die Sache mit der seriellen Schnittstelle eleganter und zudem wäre auch das gezielte Schalten einzelner Kanäle möglich.
Das die Firmware für die Kommunikation über RS232 so nicht ausgelegt ist, ist mir bekannt.
Siehst Du irgend welche Gründe, warum man die Firmware diesbezüglich nicht anpassen könnte?
Vielen Dank
Guido
P.S. Ich kann auf Deinem github Accout keinen Stable Branch Deiner Firmware-Version finden. Gibt es nur den Develop-Branch?
Hi Guido,
da seh ich technisch jetzt erstmal keine Probleme. Wenn ich ich richtig verstehe, müsstest du die Firmware so erweitern, dass auch Befehle über die serielle Schnittstelle entgegen genommen werden können. Entweder eben nur für ein/aus oder evtl. schickst du die gleichen JSON-Befehle, wie sich auch per HTTP reinkommen.
Und ja, gibt nur den devel-Branch. Ich pflege momentan keine Trennung. Ein guter Ansatzpunkt wäre vermutlich die letzte stabile Release-Version:
https://github.com/verybadsoldier/esp_rgbww_firmware/commit/b26742452ee19e6b6a63aad4b78e311024a6fb4e
Aber da passiert im Moment nicht viel. Versuche momentan nur etwas auf RAM zu optimieren.
Nabend,
ich würde dann auch von der originalen auf die vbs FW springen. Kann ich das direkt via OTA machen oder sollte ich es lieber per ISP machen?
/Daniel
Kannst du über das normale Webinterface des Controller machen. Nicht vergessen auch das FHEM-Modul "EspLedController" zu benutzen. Folgende FW-Updates kannst du dann direkt über FHEM machen.
Mhh
OTA failed
OTA failed - please restart the controller and try again
Aktuell ist:
Firmware
0.3.1
(v0.3.1)
Web Interface
0.3.3
RGBWW Version
0.8.1
SMING Version
2.1.0
Aber egal, mache ich es via ISP.
/Daniel
Seltsam, ich hab es gerade nochmal selbst probiert: einen Controller hier auf die Original-FW zurück geflasht. Danach konnte ich problemlos im Webinterface auf die vbs16 flashen mit dieser URL:
http://rgbww.dronezone.de/release/version.json
Zitat von: Shojo am 05 Januar 2018, 14:42:48
Es wird über MQTT nur der Clock und die CMD gesync, nun laufen das schon 36 Stunden, und es sind noch alle Controller synchron.
Getsernabend ist mir ja noch glatt einer raus gelaufen ein Slave Controller ging vor.
Vielleicht doch mal alle x Minuten die Color abgleichen?
Zitat von: Per am 05 Januar 2018, 13:56:41
Kurze Frage dazu: kann ich mein "originales", über die Sammelbestellung (https://forum.fhem.de/index.php/topic,48918.0.html) gekauftes und bisher nicht weiter geflashtes Modul mittels neuen Modul und neuer Update-URL OTA auf den aktuellen Stand bringen?
Das klappt bei mir auch: ein FHEM-Device "EspLedController" für einen Controller mit der Original-FW einrichten und dann aus FHEM heraus über "set fw_update" die neue FW flashen.
Zitat von: Shojo am 06 Januar 2018, 10:59:51
Getsernabend ist mir ja noch glatt einer raus gelaufen ein Slave Controller ging vor.
Ist ja schrecklich :( :o Wie lange lief das denn jetzt?
Eine Idee wäre, dass evtl. Master oder Slave rebootet hat zwischendurch, so dass die Unterschiede zustande kommen? Eine Lücke im Konzept ist, dass wenn beide Controller frisch gebootet sind haben sie ja erstmal potentiell unterschiedliche (Farb-)Zustände. Wenn man dann nur relative Kommandos verwendet (z.B. "hue +90"), dann bleibt dieser Unterschied bestehen.
Weißt du ob da ein Reboot stattgefunden haben könnte? Ich könnte mal eine "uptime"-Info einbauen, so dass man in FHEM sehen kann, wie lange ein Controller schon läuft.
Hab erstmal keine gute Idee sonst. Ich war eigentlich der Meinung, dass das ansonsten wasserdicht wäre :( Evtl. könnte noch irgendein Variablen-Überlauf alle x Stunden möglich sein...
Zitat von: Shojo am 06 Januar 2018, 10:59:51
Vielleicht doch mal alle x Minuten die Color abgleichen?
Hm, ein harter Abgleich ist nicht so ohne weiteres möglich. Das funktioniert nur sauber, wenn gerade keine Animation läuft. Falls gerade eine läuft, dann gibt es immer leichte Verschiebungen beim Abgleich wegen Latenzen.
EDIT:
Achso, irgendwelche Auffälligkeiten bei "clockCurrentInterval" oder "clockSlaveOffset" zu sehen? Ein "uptime" hab ich jetzt mal eingebaut. Ist sicherlich eh gut zu haben...
Zitat von: vbs am 06 Januar 2018, 10:49:04
Seltsam, ich hab es gerade nochmal selbst probiert: einen Controller hier auf die Original-FW zurück geflasht. Danach konnte ich problemlos im Webinterface auf die vbs16 flashen mit dieser URL:
http://rgbww.dronezone.de/release/version.json
Selbst bei der originalen Firmware ging das bei mir nie, er erkennt zwar die neue Version, also das JSON läd er aber er flashed nicht... Ich hab es bis jetzt immer mit ISP gemacht, keine ahnung warum das OTA bei mir nicht geht, liegt vielleicht an meiner Firewall. Die ESP sind mir alle etwas gesprächig vor allem die aus China mit fertiger Firmware und da habe ich die etwas eingeschränkt.
Ich sehe aber nicht das die was blockt, also mhh ka, vielleicht ein anderes Problem, aber egal, ich brauch kein OTA, es sei denn er zieht sich das vom lokalen FHEM server, nach außen ist dann alles geblockt wenn es verbaut ist. Ich find es besser wenn man es selber hochladen kann über die GUI.
/Daniel
Zitat von: ext23 am 06 Januar 2018, 12:02:00
es sei denn er zieht sich das vom lokalen FHEM server, nach außen ist dann alles geblockt wenn es verbaut ist. Ich find es besser wenn man es selber hochladen kann über die GUI.
Oder du setzt einfach einen kleinen http Service auf, wo du dann die OTA´s drüber verteilst...
Die URL kann du nach belieben ändern.
Japp so mache ich es momentan auch. Aber es ging trotzdem nicht, aber egal, ich hab hier keine 20 Stück im Einsatz wo man es bräuchte.
So FW läuft, hab gleich die Beta genommen, mal schauen ;-) Für mich eigentlich am interessantesten ein Farbverlauf der schön langsam und ohne irgend welche Sprünge läuft.
/Daniel
Zitat von: ext23 am 06 Januar 2018, 14:12:01
ich hab hier keine 20 Stück im Einsatz wo man es bräuchte.
Was ?! :o Unmöglich! :P
Ne mal ernsthaft, ich habe paar mehr nun laufen bin daher ganz dankbar das es die OTA gibt :)
Jupp naja dann braucht man das, aber wichtiger wäre dann für mich die WPA Keys zu ändern. Da der ESP kein Enterprise WLAN kann sind das meine größeren Sorge da ich mein WPA Key sehr oft ändere habe ich immer eine Menge Spass dabei ;-) Da ist das Firmware Update bei mir eher Nebensache ^^
Also Farbverlauf geht super, ich hab dummerweise nur ein Board, also werd ich mal ein paar ESPs zusammenfrickeln und dann schau ich mal wie daqs mit dem sync läuft.
Eins stört mich ein bissel, die Readings werden ja im Sekundentakt aktualisiert, das ballert das WLAN ganz schön zu, vor allem wenn man mehr als einen in Betrieb hat. Ist das durch die Beta oder kann man das irgendwo abstellen?!?
/Daniel
Kannst du konfigurieren:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#json-rpc-event-server
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#color-status-message
Zitat von: ext23 am 06 Januar 2018, 14:51:58das ballert das WLAN ganz schön zu
Naja sooo schwach ist das WLAN ja auch nicht auf der Brust!
Ahh, super, naja dann stell ich das mal ab. Ich hatte das so verstanden das es für das Sync ist. Aber gut ich hab das ehrlich gesagt auch alles nur überflogen.
Nee schwach isses nicht, aber man merkt es schon, ist eben ein shared medium und eine collision domain. Anders als bei LAN. Naja und ich heize noch gerne meinen Schädel mit nem Heizkörper auf, ich weiß, moderne Menschen leben gerne in einer Mikrowelle ^^
/Daniel
Zitat von: ext23 am 06 Januar 2018, 15:23:32
Ahh, super, naja dann stell ich das mal ab. Ich hatte das so verstanden das es für das Sync ist. Aber gut ich hab das ehrlich gesagt auch alles nur überflogen.
Wenn du "color_interval_ms" auf "0" setzt, dann wird werden die Color-Nachricht komplett ausgeschaltet. Du musst dann nicht den ganzen Event-Server ausschalten und kannst zumindest die anderen Features nutzen, die am Event-Server hängen. Muss ich offenbar im Wiki mal nachpflegen...
Zitat von: Shojo am 06 Januar 2018, 10:59:51
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 :o
Kann das bei dir möglicherweise so ähnlich gewesen sein?
;D ;D ;D ;D ;D ;D
Boahhhhh.... wadde mal..... ne mein MQTT-Brocker ist save!
Der läuft saubääär ;)
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 ?
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
Zitat von: hanswerner1 am 07 Januar 2018, 08:20:06
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
Zitat von: ext23 am 07 Januar 2018, 09:09:35
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?
Ä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
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.
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
Zitat von: vbs am 07 Januar 2018, 10:39:57
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.
Zitat von: ext23 am 07 Januar 2018, 16:12:36
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?
Zitat von: vbs am 07 Januar 2018, 18:33:15
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
Jo mach mal, sag Bescheid falls es irgendwo klemmt.
@Shojo:
Hab es gefunden (glaub ich) 8)
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:
#!/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:
{"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.
Zitat von: vbs am 06 Januar 2018, 16:15:50
Wenn du "color_interval_ms" auf "0" setzt, dann wird werden die Color-Nachricht komplett ausgeschaltet.
Das geht jetzt mit "-1" anstatt "0".
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
Zitat von: vbs am 07 Januar 2018, 18:33:15
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?
Ich habe jetzt nochmal ein paar Sachen ausprobiert.
Ich habe eine neue Scene angelegt und dort nur den Controller auf "off" geschaltet. Das hat dann auch funktioniert, allerdings funktionierte dann die scene womit ich den Controller einschalte nicht mehr. Ich konnte direkt über das Device des Controllers wieder einschalten und dann über die Scene auch wieder ausschalten nur nicht mehr einschalten. Dann habe ich wieder eine neue Scene angelegt womit ich den Controller einschalte, dann ging plötzlich nur noch einschalten und nicht mehr ausschalten. Es sieht so aus als ob nur immer ein Zustand geschaltet werden kann.
Ich denke hier gibt es eine Inkompatibilität zwischen LightScene und dem EspLedController aber erst nach Version 14 der Controller FW. Bis dahin hat alles funktioniert. Ich behelfe mir jetzt indem ich über LightScene ein Dummy schalte, das wiederum über ein doif dann den EspLedController schaltet. Nicht ideal aber funktioniert.
Zitat von: ext23 am 08 Januar 2018, 18:21:44
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.
Gibt da einen Bug in der vbs18b bzgl. des RTC-Speichers (der auch von rboot genutzt wird). Eigentlich ein Sming-Bug, da deren RTC-Code und deren rboot die gleiche Adresse verwenden. Kann sein, dass der sich beim OTA-Update aufhängt. Probier mal bitte mit der jetzt aktuellen vbs21b, da hab ich das behoben.
Zitat von: ext23 am 08 Januar 2018, 18:21:44
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.
Ok, das werde ich mal ausprobieren bei Gelegenheit. rboot.bin liegt übrigens immer neben den anderes Files:
http://rgbww.dronezone.de/testing/rboot.binZitat von: hanswerner1 am 08 Januar 2018, 20:38:29
Ich denke hier gibt es eine Inkompatibilität zwischen LightScene und dem EspLedController aber erst nach Version 14 der Controller FW. Bis dahin hat alles funktioniert.
Rein vom Code her habe ich da nichts gefunden, was sich in Richtung Schnittstelle geändert hätte. Ich kenne LightScene nicht, aber wenn auch du sagst, dass ein normaler "set off"-Befehl an das Modul funktioniert, dann müsste man tatsächlich mal rausfinden, was LightScene da eigentlich macht.
Moin zusammen
Da ich denke, dass dies ja nun die Firmware fuer den LED-Controller werden wird, frage ich hier auch mal um Hilfe.
Ich habe letztes Jahr noch mal eben schnell zwei Controller zusammengeloetet. Eigentlich wollte ich nur einen neuen fertigstellen, aber der liess sich nicht flashen. Da sich dann aber der Zweite auch nicht flashen liess habe ich den User als Fehler angenommen und einfach erstmal fuer Sylvester den Alten weiterbenutzt.
Da nun wieder etwas Zeit ist, wuerde ich doch gerne an dieser Stelle weitermachen. Wenn ich das Flashtool mit dem Controller verbinde, sehe ich seltsamerweise die MAC und den QR-code gar nicht. Ein Tauschen von RX/TX aendert letztendlich nur das die LED nicht mehr blinkt, so dass ich davon ausgehe, dass die Verbindung korrekt ist. Muss ich zum Flashen noch irgendeinen PIN auf GND ziehen, oder wie bekomme ich die FW auf den ESP?
Danke und Gruss
Christoph
Ja der eine Pin muss noch gebrückt werden (GPIO0) der ist bei dem Board raus geführt. Den kannst du aber mit dem DTR verbinden vom UART USB Adapter. Dann das Tool starten und Flash drücken und dann nochmal reset beim Board und dann sollte es losgehen.
/Daniel
Hallo Daniel
Ja Danke! Ich hatte gerade eben im Wiki was gesucht, und da auch gelesen, dass der PIN auf GND gezogen werden muss. Wollte gerade hier reinschreiben! Mal sehen, ob ich heute abend einen fertig mache.
Gruss Christoph
Hallo zusammen
Kann erstmal Erfolg vermelden. Manchmal ist es so einfach! Mal sehen, am Samstag tausche ich den aus, vorher leider keine Zeit!
Danke erstmal und Gruss
Christoph
Zitat von: ext23 am 08 Januar 2018, 18:21:44
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.
Hm, konnte ich so erstmal nicht nachstellen. Achtest du drauf, dass du denjenigen ROM-Slot flasht, den du hinterher auch bootest?
Könntest du mal deine komplette Kommandozeile posten, die du zum Flashen verwendest?
Mhh ich nutze das grafische Tool, aber das sollte ja kein Unterschied machen oder.
Schau dir mal die Screenshots kann, kann natürlich sein, das ich ja irgendwo einen generischen Fehler habe. Aber ich werd es nochmal mit deiner rboot versuchen.
/Daniel
irgendwas stimmt da nicht.
Wollte gerade meine 16er per ota auf 19 flashen... failed immer wieder.
nochmal testweise die 16er geflasht.. die geht sofort.
Edit: nachdem ich die 16er nochmals aufgespielt habe ging die 19er im anschluss... komisch
Zitat von: kmxak am 10 Januar 2018, 20:09:37
Wollte gerade meine 16er per ota auf 19 flashen... failed immer wieder.
nochmal testweise die 16er geflasht.. die geht sofort.
Ja, vermutlich bekannt. Hatte ich weiter oben schonmal beschrieben. Ich hatte auch gestern schon eine vbs21b eingecheckt, aber vergessen auf den Server pushen (hab ich gerade nachgeholt). Die sollte wieder rund laufen.
Zitat von: ext23 am 10 Januar 2018, 16:28:57
Schau dir mal die Screenshots kann, kann natürlich sein, das ich ja irgendwo einen generischen Fehler habe. Aber ich werd es nochmal mit deiner rboot versuchen.
Bin da jetzt auch nicht der Mega-Experte, aber hier ist das Standard-Kommando von Sming:
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 out/firmware/rboot.bin 0x01000 /home/vbs/Projects/esp-open-sdk/sdk/bin/blank.bin 0x02000 out/firmware/rom0.bin 0x100000 out/firmware/spiff_rom.binWichtig ist, dass hier an die Adresse 0x1000 4096mal 0xff geflasht wird (blank.bin). Dort liegt die rboot-Konfiguration. Ohne Config bootet rboot das nächste mal auf jeden Fall Slot 0. Wenn man das nicht macht, dann kann es sein, dass die Config zufällig auf Slot 1 zeigt (alterniert bei jedem OTA-Flash) und man zwar Slot 0 flasht aber dann trotzdem weiterhin das alte ROM aus Slot 1 gebootet wird.
Muss man ja ein bissel umdenken, bei Atmels ist der Bootloader immer am Ende des Flash ;-)
OK, sprich bei mir steht eventuell misst in der rboot config ja? Kannst du mir die blank.bin mal anhängen, dann flash ich das mal bei 1000 mit rein.
Der Flash ist also zweigeteilt (halbiert) und beim OTA wird dann der jeweils andere Speicherbereich beschrieben, ok.
/Daniel
Nee da wird kein Mist bei dir stehen. Man muss einfach nur aufpassen, dass man auch das bootet, was man geflasht hat. Sonst kommt es evtl. zu seltsamen Beobachtungen.
Anbei die blank.bin. Adresse ist 0x1000 (nicht 0x10000!!)
Naja nur wie kann ich das denn beeinflussen was gebootet wird?!?
Naja ich warte auf die 21 und dann flashe ich das alles nochmal komplett durch, mit der blank und dann schau ich mal ob das OTA bei der nächsten Version funktioniert wenn es denn die 22 gibt...
/Daniel
Zitat von: vbs am 10 Januar 2018, 20:32:39
Wichtig ist, dass hier an die Adresse 0x1000 4096mal 0xff geflasht wird (blank.bin). Dort liegt die rboot-Konfiguration. Ohne Config bootet rboot das nächste mal auf jeden Fall Slot 0.
Indem du die blank.bin an Adresse 0x1000 flasht :)
OK, naja ich bin ESP blond was das angeht, ich kenne nur Atmels bzw. AVRs. Ich muss mich da aber mal einarbeiten, nützt ja alles nichts.
Ich ich bügel das alles über wenn die 21 aufm server liegt und dann schauen wir mal.
/Daniel
Argh sorry verdammt, liegt da, hatte vergessen die version.json anzupassen... :/
Kein Thema, hab das jetzt alles geflasht auf beiden, aber keine WLAN Verbindung und komischerweise auch kein AP.
Durch das löschen von 1000-2000 ist die ganze config runter vom Controller? Also nicht nur BootLoader spezifisches?
/Daniel
Sorry, keine Idee. Kann das bei mir nciht nachstellen, das kein AP aufgemacht wird.
Bitte flash mal die FW aus dem Anhang und boote mit gedrücktem CLR.
Das muss dann so aussehen:
RGBWW Controller v 0.3.1-vbs22b
Application::init - normal boot
Application::mountfs rom slot: 0
Application::mountfs trying to mount spiffs at 100000, length 786432
fs.start: size:768 Kb, offset:0x100000
mount res: 0
CLR button low - resetting settings
AppWIFI::forget_wifi
Station configuration is:
ApplicationOTA::checkAtBoot
ApplicationOTA::loadStatus
Application::init - first run
APPLedCtrl::init
APPLedCtrl::setup
H: 0 | s: 0 | v: 0 | ct: 2700
sleep disable
AppWIFI::init initial run - setting up AP
SSID:
AppWIFI::init no AP to connect to - start own AP
AppWIFI::startAp
Enabling AP and DNS server
AppWIFI:: WifiAP enable
AP configuration loaded
AppWIFI:: DNS enable
UDP listen port 53
'*' registered
'/' registered
'/webapp' registered
'/config' registered
'/info' registered
'/color' registered
'/animation' registered
'/networks' registered
'/scan_networks' registered
'/system' registered
'/update' registered
'/connect' registered
'/generate_204' registered
'/ping' registered
'/stop' registered
'/skip' registered
'/pause' registered
'/continue' registered
'/blink' registered
mode : sta(5c:cf:7f:8c:0c:03) + softAP(5e:cf:7f:8c:0c:03)
add if0
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
Application::startServices
APPLedCtrl::start
+TCP connection
Starting event server
Server timeout updating: 40 -> 120
+TCP connection
f r0, APPLedCtrl::onAnimationFinished:
APPLedCtrl::onAnimationFinished:
APPLedCtrl::onAnimationFinished:
APPLedCtrl::onAnimationFinished:
Saving ColorStorage to file...
scandone
AppWIFI::scanCompleted. Sucess: 1
scan completed: 25 found
Poste mal deinen kompletten Output bitte. Bin gespannt..
Durch das löschen von 1000-2000 ist die ganze config runter vom Controller? Also nicht nur BootLoader spezifisches?
Nein das löscht nur die Bootloader-Config.
Darf ich mal nachfragen welche Esps ihr benutzt wenn diese Probleme mit dem AP auftauchen? Hatte mal ähnlichen Zirkus mit den F. Dann hab ich E verwendet und damit gings. Keine Ahnung ob das Zufall ist oder ob da irgendwelche unterschiede sind.
Gruß
Markus
Ich habs jetzt unter Linux mit dem esptool gemacht, dann geht es. Irgendwie ist dieser NodeMCU Firmware Programmer nicht die beste Wahl gewesen, der scheint ein Problem zu haben die Speicherbereiche in nicht aufsteigender Reihenfolge zu beschreiben oder ka...
Jetzt laufen jedenfalls beide mit der 21. Wenn eine neue Version kommt checke ich das mit dem OTA nochmal.
Jetzt möchte ich aber endlich das Sync ausprobieren, irgendwie kam immer etwas dazwischen ^^
Update: Ich habe auch ein E, daran liegt es nicht, das ist das Tool gewesen, oder ich hab mich zu blöde angestellt, ka, ein Pils zu viel oder so...
/Daniel
Ich nutze auch den NodeMCU Firmware Programmer ohne Probleme aber ich nutze auch einen Wemos D1 Mini...
Zitat von: ext23 am 10 Januar 2018, 22:31:33
Ich habs jetzt unter Linux mit dem esptool gemacht, dann geht es. Irgendwie ist dieser NodeMCU Firmware Programmer nicht die beste Wahl gewesen, der scheint ein Problem zu haben die Speicherbereiche in nicht aufsteigender Reihenfolge zu beschreiben oder ka...
Mich würde trotzdem gerne mal die serielle Ausgabe sehen, wenn du mit dem NodeMCU geflasht hast und er kein AP aufmacht. Falls du das nochmal posten könntest, wäre super.
Kann ich mal schauen ja, aber da wird vermutlich nicht viel kommen, der zieht auch nur 0,12W in dem Status, der ist also nicht wirklich gerannt. Ich nehme mal an der hat den Einsprung gar nicht geschafft in dem Status.
/Daniel
vbs24b:
- Fixed MQTT clock sync drift
- Added "uptime" in info message
- Better handling of clock syncs when clock master reboots
- Fixed webclient crash when SSIDs with non-ASCII characters appear (SSID will be ignored!)
- Fixed rboot config conflicting with Sming RTC
- Removed custom version string. Solely use Git version string now for consistent versioning (looks a bit odd in webclient)
Werde ich jetzt ein paar Tage testen und das wäre dann der Release Candidate für die nächste stable.
Das ist aber nicht so gewollt oder?
Hallo zusammen,
Ich hab da mal eine Frage:
Ich habe von der Originalen Firmware per Weboberfläche auf diese hier (http://rgbww.dronezone.de/release/version.json) geupdatet. Unter ,,System settings" bei Firmware stehen jetzt folgende Angaben:
Firmware 0.3.1-vbs16 (vbs8-16-gb267-dirty)
Web Interface 0.3.3
RGBWW Version 0.8.1-vbs4
SMING Version 3.5.0
Ist das so richtig? Ist das die stable version? Mache ich irgendwas falsch? Muss ich eine vbs-firmware direkt flashen?
Weshalb ich nachfrage: MQTT lässt sich nicht aktivieren. Laut dem was ich hier lese sollte es aber funktionieren. Habe auch das aktuelle FHEM Modul drauf und als define angelegt.
Über einen Hinweis würde ich mich sehr freuen!
Gruß
Alex
Hi Alex,
ja das ist die richtige und die ist auch stable.
MQTT lässt sich aktuell nur über das FHEM Modul EspLedController konfigurieren.
Gruß
Zitat von: Shojo am 11 Januar 2018, 19:45:27
Das ist aber nicht so gewollt oder?
Naja, nicht schön, aber in Kauf genommen, da ich im Webclient nix verändern kann :( Daher der Hinweis oben:
- Removed custom version string. Solely use Git version string now for consistent versioning (looks a bit odd in webclient)Es gab bisher zwei Versionsstrings. Einmal "fw_version" und einmal "fw_git_version". Fand ich irgendwo redundant. Außerdem musste ich "fw_version" manuell pflegen. Jetzt gibt es nur noch "fw_git_version", welche die komplette FW eindeutig automatisch korrekt identifiziert, da jetzt sowohl Sming als auch die RGBWW-Library Teil des Repos sind, da es Submodule sind.
Langfrisitg wäre es schon super, wenn man den Webclient funktionierend neu bauen könnte. Dann könnte man auch entweder die neuen Optionen hinzufügen oder zumindest die nicht funktionierenden rausschmeissen :/
Also das OTA möchte bei mir einfach nicht funktionieren. Ich habe aktuell die:
Firmware
0.3.1-vbs21b
(vbs18b-14-gf798)
Web Interface
0.3.3
RGBWW Version
0.8.1-vbs5
SMING Version
3.5.0
Wenn ich jetzt auf der UART schaue (9600) und ein Reset mache sehe ich dort nur ein paar Zeichen Matsch, soll das so? Wenn ich jetzt auf OTA Update drücke geht das Fenster auf und OTA - updating steht da, auch nach 10 Minuten noch. Die Stromstärke steigt ab und an mal an zwischen 20 und 30 mA. Auf der UART kommt keinerlei Ausgabe. Rufe ich den URL neu auf steht nur "OTA in progress" da.
Ich meine so viel kann man doch gar nicht falsch machen?!?
/Daniel
Zitat von: vbs am 11 Januar 2018, 22:50:21
Naja, nicht schön, aber in Kauf genommen, da ich im Webclient nix verändern kann :( Daher der Hinweis oben:
- Removed custom version string. Solely use Git version string now for consistent versioning (looks a bit odd in webclient)
Ja stimmt voll überlesen ::)
Ja ich habe mir gestern schon paar Stunden mit Angular beschäftigt, hoffe das wir das dann mal bald mit den Webclient auf die Reihe bekommen.
Zitat von: ext23 am 12 Januar 2018, 00:01:29
Wenn ich jetzt auf der UART schaue (9600) und ein Reset mache sehe ich dort nur ein paar Zeichen Matsch, soll das so? Wenn ich jetzt auf OTA Update drücke geht das Fenster auf und OTA - updating steht da, auch nach 10 Minuten noch. Die Stromstärke steigt ab und an mal an zwischen 20 und 30 mA. Auf der UART kommt keinerlei Ausgabe. Rufe ich den URL neu auf steht nur "OTA in progress" da.
Also erstmal: ich versteh es auch nicht :(
Ein paar Punkte:
- Baudrate 9600 ist falsch, du brauchst 115200,8,N,1
- du sagtest ja mal, dass du zwei Controller hast. Ist das bei beiden identisch so? Wäre interessant zu wissen, ob "nur" einer der Controller in einen "exotischen" Zustand gekommen ist oder ob das irgendwie System hat
- du flasht jetzt auch mit der Kommandozeile, die ich neulich mal gepostet hatte, oder? Falls nicht, dann das bitte mal probieren. Ich sage nciht, dass das der einzig richtige Weg ist, aber bei dem Befehl weiß ich einfach, dass er prinzipiell funktioniert
- flashe bitte mal die FW von hier https://forum.fhem.de/index.php/topic,70738.msg746407.html#msg746407. Die hat Debug-Ausgaben. Wenn du die drauf hast, dann bitte mal OTA starten und den seriellen Output posten.
- Interessant wären auch die HTTP-Antworten von der Webseite während da "OTA in progress" steht. Das machen wir dann mal im Anschluss...
Dann sehen wir weiter...
OK, dann eben 115200, hatte weiter vorne was von 9600 gelesen. Aber egal, irgendwie scheint TeraTerm ein Problem zu haben, ich sehe nur Matsch und wenn ich verbunden bin hängt der ESP fest. Das erklärt warum ich so ein Verhalten hatte das nichts ging. Aber ok, ich hab jetzt den Serial Monitor der Arduino IDE genommen, das klappt auch und ich sehe jetzt was. Ich weiß nicht warum sich TeraTerm nicht mit dem ESP verträgt, alle andere Verbindung liefen damit bis jetzt immer und besser als mit Putty, komisch.
Geflashed habe ich jetzt wieder mit dem Windows GUI Tool.
Im Anhang die Debug Ausgabe beim OTA, der dreht irgendwie im Loop... musst mal schauen.
/Daniel
Erste Vermutung: der Controller kann die Firmware-Files nicht runterladen und hängt. Denk bitte nochmal scharf nach, ob du irgendwas im Router o.ä. laufen hast, was da Probleme machen könnte (Firewall, MAC-Filter, DNS-Filter, Routen usw.). Sollte natürlich trotzdem nicht zu so einem Zustand kommen.
Was du da als Loop siehst, ist sehr wahrscheinlich der Webclient der zyklisch nachfragt, ob das Update fertig ist.
Ich baue nachher nochmal ein paar mehr Logausgaben ein, um das noch stärker einzugrenzen.
Naja an der Firewall sollte es nicht liegen. Das json file kann er ja auch ziehen. Protokoll ist doch immer gleich, Port auch. Ich sehe auch nicht das irgend etwas geblockt wird. mhhh
/Daniel
Zitat von: ext23 am 12 Januar 2018, 17:34:45
Naja an der Firewall sollte es nicht liegen. Das json file kann er ja auch ziehen. Protokoll ist doch immer gleich, Port auch. Ich sehe auch nicht das irgend etwas geblockt wird. mhhh
Also wie ich es drehe und wende, für mich sieht es so aus, als könne der Controller zwar eine HTTP-Verbindung aufbauen, aber dann kommen keine Daten durch. Und nein, der Controller hat das version.json nicht runtergeladen. Das macht der Webclient, also dein Browser, und schickt dann den Inhalt an den Controller.
Im Anhang nochmal ein FW mit mehr Logausgaben, aber ich bin mir einigermaßen sicher, dass dort auch nur zu sehen sein wird, dass eine Verbindung zu Stande kommt, aber dann keine Daten eintreffen.
Ist deine Infrastruktur irgendwie besonders? Proxy? Oder einfach ein Wald&Wiesen-Consumer-Router?
Du kannst mal probieren, bei dir im Netzwerk lokal einen HTTP-Server laufen zu lassen und von dort zu updaten. Mal sehen, was da passiert.
Oder mal den Controller über einen Hotspot auf deinem Handy ein Update versuchen lassen. Also über eine völlig andere Verbindung ins Inet.
Hab sonst leider keine gute Idee, sorry :( Ich tippe auf Netzwerk...
Zitat von: vbs am 12 Januar 2018, 21:26:43
Also wie ich es drehe und wende, für mich sieht es so aus, als könne der Controller zwar eine HTTP-Verbindung aufbauen, aber dann kommen keine Daten durch. Und nein, der Controller hat das version.json nicht runtergeladen. Das macht der Webclient, also dein Browser, und schickt dann den Inhalt an den Controller.
Achso, naja dann sieht die Sache schon ganz anders aus. Da ich keine IP sehe, hier ist nur alles 0.0.0.0 kann es natürlich sein, das ihm dann der DNS fehlt. Ich dachte das json zieht sich der Controller. Mhh das sollte man aber mal ändern dann, bzw. ein Fehler ausspucken.
Und nein ich habe kein Standard Netzwerk ;-)
Ich schau mal im DHCP was ich da für ein misst eingestellt habe.
Man sieht in deinem Log, dass er DNS hat, kann daran eigentl. niht liegen:
DNS record found: rgbww.dronezone.de = 151.101.13.147
Bin voll bei dir, dass es eine Fehlermeldung geben sollte. Leider nicht so einfach, da er offenbar erfolgreich eine Verbindung aufbaut, aber dann keine Daten kommen. Also die Datenübertragung ist unendlich langsam ^^
Evlt. könnte man einen Mechanismus bauen, der das Update abbricht, wenn es nicht nach 5 Minuten oder so zu einem Ergebnis gekommen ist... finde ich aber auch nicht unbedingt super schön.
Boa danke jetzt geht es, voll drauf verlassen, dass es nicht am DHCP liegen kann. Das ging über den Transparenten Proxy, da habe ich mich bei der GW IP vertan. Jetzt geht es auch.
Aber mit der seriellen gibt es ein paar Probleme, der bootet öfters nicht richtig wenn die serielle vorm Reset verbunden ist. Aber das liegt vermutlich am DTR der auf dem Board ja mit dem gpio0 verbunden ist. Sollte man natürlich nicht machen ;-)
Puh so haben wa das auch geklärt. Naja also ein paar mehr Informationen wären schon ganz gut auf der Seite, so für Deppen wie mich.
Also hier das meine ich mit 0.0.0.0, FHEM zeigt da leider nichts:
config-network-connection-gateway
0.0.0.0
2018-01-12 22:05:42
config-network-connection-ip
0.0.0.0
2018-01-12 22:05:42
config-network-connection-netmask
0.0.0.0
2018-01-12 22:05:42
/Daniel
Ja, das ist die statische Netzwerk-Konfiguration des Controllers, also wenn man kein DHCP benutzt (config-network-connection-dhcp). Ist aber kein Rückkanal für die aktuelle vergebene DHCP-Config. Wäre evtl. aber auch nett zu haben...
Moin
@Shojo
Zitat von: Shojo am 11 Januar 2018, 21:28:58
MQTT lässt sich aktuell nur über das FHEM Modul EspLedController konfigurieren.
Ich hab es geschafft. DANKE! War etwas knifflig, da ich keine Anleitung gefunden hatte.
Set devicename config config-network-mqtt-enabled 1
Jetzt ergibt sich daraus für mich eine weitere Frage:
Als color master sendet der Controller kontinuierlich einen String. Wenn ich den Controller auf color slave setze, und ich den selben String per MQTT Client dann an den Controller sende, passiert nichts. Kann ich den Controller irgendwie über MQTT steuern? Ohne FHEM. Quasi als Slave. Und den command String direkt senden. Geht sowas? Oder über einen anderen Weg?
Gruß Alex
Hast du die Beschreibung schon gesehen?
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#direct-color-sychronization
Ansonsten geht das theoretisch. Du musst Slave aktivieren, und vor allem auch color_slave_topic konfigurieren. Und an das Topic dann die Farb-Befehle schicken. Hab es aber ehrlich gesagt länger nicht getestet, da ich es nur begrenzt sinnvoll finde. Was genau hast du vor? Ich denke es ist meist sinnvoller, den cmd-Sync zu verwenden:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#command-synchronization
Moin!
ich schreibe grad eine kleine Anwendung die ich auf einem alten (also so richtig alt) laufen lassen will, wo einfach nur ein paar buttons drauf sind. diese sollen per MQTT Sachen steuern. Das ist die Idee dahinter.
Ich hab es jetzt zum Laufen bekommen. Soweit ich das nachvollziehen kann ist wichtig den Topic bei den MQTT Einstellungen anders als den Standard einzustellen. Seit ich den geändert habe, geht es.
Richtig genial! Danke für die Mühe @vbs
Gruß
Alex
Gibt jetzt in FHEM Readings zum aktuellen Netzwerkstatus:
info-connection-dhcp 1
info-connection-gateway 192.168.2.1
info-connection-ip_address 192.168.2.22
info-connection-mac 5ccf7f8c0c03
info-connection-netmask 255.255.255.0
info-connection-ssid myWifi
@Alex:
Sehr gut! Aber das Standard-Topic muss/sollte genauso funktionieren wie jedes andere. Da ist nix besonderes dran... komisch...
Shojo war so gut, sich mal die WebApp vorzunehmen und dort ein paar Sachen auf den neuesten Stand zu bringen (besten Dank)!
Ich hab daraus eine vbs26b gemacht:
20.01.2018 - vbs26b
- webapp updated to shojo3 (thanks
- improved stability
- uptime only updated every 60 seconds
Hauptaugenmerk liegt auf dem geänderten Webinterface und auf Stabilität. Ich hatte mit den letzten Versionen beobachtet, dass sich die Controller mal alle paar Stunden/Tage rebootet haben. Wäre klasse, wenn ihr verstärkt drauf achten könntet, ob das weiterhin passiert (zu sehen am uptime-Reading, oder am Zeitstempel des state-Readings).
Achso wenn sich der Controller jetzt von HTTP-Requests überlastet fühlt, dann beantwortet er Requests direkt mit 429 (too many requests) und "Retry-After"-Header, der den Client auffordert, den Request in x Sekunden zu wiederholen. Die neuste Version vom FHEM-Modul beachtet diesen Header und verhält sich entsprechend. Das ganze ist eine Maßnahme, um Crashes zu verhindern.
So, habe gestern mal bissel mit dem Controllern gespielt:
https://youtu.be/_axMsUs4uPE
set WZ.Licht.RGB.Fensterfront hue +90 0.1 r;
set WZ.Licht.RGB.Fensterfront sat 50 0.1 qr;
set WZ.Licht.RGB.Fensterfront sat 100 0.1 qr;
Da hast sich glatt FHEM verabschiedet...
Kann es sein das der Controller das FHEM Modul "geddost" hat?
Zitat von: Shojo am 21 Januar 2018, 16:47:13
So, habe gestern mal bissel mit dem Controllern gespielt:
Hm, ich glaube nicht, dass der Controller als "Discolicht" missbraucht werden sollte. Aber als Test, was so alles machbar ist, bzw. wann was wie ausfällt (falls Du das herausbekommst) ist das ok ;)
Gruß PeMue
Zitat von: PeMue am 21 Januar 2018, 17:04:17
Hm, ich glaube nicht, dass der Controller als "Discolicht" missbraucht werden sollte.
Das war ja auch nur ein Test (6 Std. lang) ob die Controller auseinander driften!
Und nein das machen sie nicht :)
Sehr geil!
:D Pass mal auf, dass die Nachbarn nicht die Feuerwehr rufen ^^
Nach welcher Zeit hat sich denn dann FHEM verabschiedet? Steht etwas im Log? Ist das reproduzierbar? Controller aber stabil?
Der reine Farbwechsel sollte keine Probleme machen, der Controller sollte nicht öfter schicken als in config-events-color_interval_ms angegeben. Bin mir aber mit dem "tranisitionFinished"-Event unschlüssig. Das muss nach jeder fertigen Animation kommen. Also bei dir immer 2 Stück alle 100 ms :)
Zitat von: vbs am 21 Januar 2018, 17:45:20
Nach welcher Zeit hat sich denn dann FHEM verabschiedet? Steht etwas im Log? Ist das reproduzierbar?
Ja ist reproduzierbar, FHEM verabschiedet sich auch nicht wirklich (etwas blöd von mir ausgedrückt) 100% CPU load ist das Problem ^^
Zitat von: vbs am 21 Januar 2018, 17:45:20
Controller aber stabil?
Ja die laufen und laufen und laufen.... ;)
Versuch mal bitte die FW im Anhang. Da sind die animationFinished-Events ausgeschaltet. Wenn es daran liegt, bau ich dafür noch nen Filter ein.
Kann es hier gerade nicht testen, da ich hier auf allen Controllern gerade noch Langzeittest laufen habe ;)
Ja, mache ich heute Abend ;D
Guten Morgen,
zuerst einmal vielen Dank für die viele Arbeit und die schnelle Kommunikation. Ich versuche gerade die Informationen des Controllers über JSON-RPC mit einer anderen Software ohne FHEM zu nutzen. Wie ich das aus dem Wiki verstanden habe sendet der Controller auf Port 9090 die Infos. Jetzt muss ich gestehen, dass ich damit noch keine Erfahrung habe. Kann ich einen Client mit CURL oder einer anderen Software z.B. REST Client (nicht programmieren) simulieren, damit ich verstehe, was hier passiert? Ich habe zwar jetzt schon einiges über JSON-RPC gelesen, aber ich finde noch nicht den richtigen Zugang dazu.
Vielen Dank schon einmal.
Du kannst einfache eine TCP-Verbindung auf den Port aufmachen und dir die Daten ansehen, die dann reinkommen. Sind einfach Text-Nachrichten. Du kannst z.B. auf der Konsole einfach ein "telnet <IP> 9090" machen, um zu sehen, wie es aussieht.
Dann nimmst du am besten eine JSON-Library deiner Wahl um die Daten zu parsen.
Zitat von: vbs am 22 Januar 2018, 13:07:33
Du kannst einfache eine TCP-Verbindung auf den Port aufmachen und dir die Daten ansehen, die dann reinkommen. Sind einfach Text-Nachrichten. Du kannst z.B. auf der Konsole einfach ein "telnet <IP> 9090" machen, um zu sehen, wie es aussieht.
Dann nimmst du am besten eine JSON-Library deiner Wahl um die Daten zu parsen.
Vielen Dank. Das hat geholfen. Irgendwie sieht man manchmal den Wald vor lauter Bäumen nicht.
Zitat von: vbs am 21 Januar 2018, 18:04:17
Versuch mal bitte die FW im Anhang. Da sind die animationFinished-Events ausgeschaltet.
Jo, daran lag es, jetzt steht der Disco nichts mehr im Wege :D :D :D
Zitat von: Shojo am 22 Januar 2018, 20:05:12
Jo, daran lag es, jetzt steht der Disco nichts mehr im Wege :D :D :D
Hm, irgendwie seltsam: ich hab es jetzt bei mir mal getestet und ich bin jetzt eigentlich der Meinung, dass das transitionFinished-Event sowieso nur kommt, wenn man der Animation einen Namen gegeben hat. Kann also eigentlich daran nicht liegen (hattest ja keine Namen).
Aber es können doch öfter Color-Events kommen als 500 ms. Nämlich es wird auch immer ein Color-Event außerhalb der Reihe geschickt, wenn eine Animation fertig geworden ist. Das wird vermutlich der Grund sein. Dafür gibt es jetzt den Config-Schalter "config-events-color_mininterval_ms", der generell ein Mindestintervall zwischen zwei Color-Events festlegt (default 500 ms).
Außerdem noch "config-events-transfin_interval_ms", der das gleiche für die TransitionFinished-Events macht (auch wenn es jetzt offenbar an denen gar nicht lag).
Das Ganze zu finden in "vbs27b"...
Achso: und ich hab festgestellt, dass offenbar gar nicht die FW instabil ist, sondern einfach einer meiner Controller einen Wackelkontakt hatte... wenn man ihm zu nahe gekommen ist, hat das auch einen Reboot ausgelöst :o
Beim Ausprobieren, wo denn der Wackler steckt hat dann offenbar der ESP den Geist aufgegeben, jedenfalls ging bei dem dann kein WLAN mehr. Auslöten und einen neuen Einlöten hat wieder Spaß gemacht... >:(
Ich hab außerdem einen Bug im FHEM-Modul festgestellt. Der trat bei mir reproduzierbar auf wenn ich die DEF eines bestehenden Devices geändert habe. Da liefen dann beide Devices (alte und neue DEF) parallel weiter sozusagen. Könnte auch das Problem von @hanswerner1 von vor ein paar Tagen erklären. Wobei da eigentlich nicht die Rede war von DEF ändern...
Naja ist jetzt jedenfalls behoben im Modul, denke ich...
Die Dinger sind allesamt sehr empfindlich wenn man den Schirm etwas zu stark drückt, irgendwie gibt es da ein Kurzen. Ich hab da auch schon einen eingebüßt. Bestimmt irgend eine Charge wo die China Toleranz etwas abgedriftet ist ;-)
Und ich hab bei meinen immer noch ein kleinen Abblockkondensator zwischen, schadet nicht. Die DCDC Wandler haben teilweise eine miese Restwelligkeit.
/Daniel
Zitat von: vbs am 23 Januar 2018, 18:21:11
Achso: und ich hab festgestellt, dass offenbar gar nicht die FW instabil ist, sondern einfach einer meiner Controller einen Wackelkontakt hatte... wenn man ihm zu nahe gekommen ist, hat das auch einen Reboot ausgelöst :o
Beim Ausprobieren, wo denn der Wackler steckt hat dann offenbar der ESP den Geist aufgegeben, jedenfalls ging bei dem dann kein WLAN mehr. Auslöten und einen neuen Einlöten hat wieder Spaß gemacht... >:(
Danke für den Tipp, werde ich mal ausprobieren.
Hab gemerkt, dass die Schwellwerte für den Heap-Check in vbs27b etwas zu hoch waren und daher gelegentlich Verbindungen abgelehnt wurden. Hab nochmal eine 28b gemacht, wo das behoben sein sollte, sorry. Ich hoffe, das wärs jetzt erstmal...
Shojo hat wieder zugeschlagen und das Webinterface etwas erweitert (shojo5). Zu finden in der neuen Firmware vbs29b...
Vielleicht kann er noch etwas dazu sagen, welche Änderungen da eingeflossen sind. Danke dafür schonmal!
Zitat von: vbs am 25 Januar 2018, 08:10:41
Vielleicht kann er noch etwas dazu sagen, welche Änderungen da eingeflossen sind.
Sicher doch :)
In der shojo5 ist eigentlich nur eine erwähnenswerte Änderung.
Man hat nun die Möglichkeit die Variable "general.pin_config" zu beschreiben.
Es sind aktuell 3 möglich Einstellung vorhanden:
-
mrpj PCB (ESP-12)--diese Option ist für die "Originale" PCB. (für die meisten passend und daher auch default)
-
Shojo PCB (WemosD1 mini)--diese Option ist für meine fräsbare PCB.
-
Custom Pin Config--und hier kann man seine eigene Pin Config hinterlegen, um eine grösstmögliche Menge an Hardware zu bedienen.
Hallo,
aktuell läuft bei mir die stable v16. Ich kann immer wieder beobachten, dass die Netzwerkverbindung abreißt. Im Webinterface wechselt dann immer "connected" und "lost connection". Die WLAN Verbindung ist hervorragend, da vom Router nur 1m entfernt. Keine Firewall oder sonstiges im Einsatz.
Irgendeine Idee, an was das liegen könnte. Darunter leidet dann natürlich auch die Steuerbarkeit über Schnittstelle.
Vielen Dank im Vorraus.
Ich würde empfehlen erstmal auf die aktuelle testing-Version zu gehen (steht eh kurz davor die stable-Variante zu werden) und vor allem auch das FHEM-Modul auf den neusten Stand zu bringen. Evtl. ist das Problem dann schon weg. Falls nicht, dann bitte mal Logs posten.
Dann auch mal "get info" machen und im Reading "info-uptime" gucken, ob das Reading im Fehlerfall wieder auf 0 spring (der Controller also wirklich rebootet hat).
So, nach viel Fummelei und vielen Optimierung hab ich jetzt mal wieder ein Stable-Release gemacht ("vbs30"). Liegt sowohl auf dem release- als auch auf dem testing-Pfad.
Speziellen Dank nochmals an Shojo, der das aktuelle Webinterface (shojo6) beigesteuert hat, mit dem schon viele der neuen Config-Settings bedient werden können!
Änderungen von vbs30 (ggü. vbs16):
Feature: webapp updated to shojo6 (thanks!)
Feature: Added "uptime" in info message
Improvement: Better handling of clock syncs when clock master reboots
Improvement: Removed custom version string. Solely use Git version string now for consistent versioning
Improvement: improved stability
Improvement: compiled with SMING Release settings (no serial debug output)
Bugfix: Fixed webclient crash when SSIDs with non-ASCII characters appear (SSID will be ignored!)
Bugfix: Fixed MQTT clock sync drift
so mein fhem crashed seit dem ich es updated habe andauernd. und habe mehrere hundert mb große log datein :o
update nun alle controller und füge die neu ein und dann mal sehen.
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/info?: empty answer received retrieving info
2018.02.02 17:40:27 2 : Kueche2: LedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/color?: empty answer received retrieving color
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: EspLedController_ParseBoolResult error: http://192.168.2.121/config?: empty answer received
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
2018.02.02 17:40:27 2 : Kueche2: error http://192.168.2.121/config?: empty answer received retrieving config
Kann ich erstmal so nix zu sagen. Da ist offenbar irgendwas in einer Zeitschleife gefangen :) Bring doch mal alles auf den neusten Stand und dann FHEM einmal durchstarten sicherheitshalber. Klingt ja nach einem Update-Problem.
Weiß nicht ob es sinnvoll, jetzt Inkompatibilität nach Update von Modul-Version X auf Y in Verbindung mit Controller-Firmware Z zu untersuchen.
ich hatte einen controller der nicht mehr wollte... ich weiß nicht genau was mit dem los war aber der hatte noch die 12er (oder 13) version drauf und mit dem alten ledcontroller modul.
Alles mal geupdatet und werde es beobachten.
Hallo,
Da ich eine RGBW Deckenleuchte habe bei der wohl der Funk Empfänger was hat, min ich auf der Suche nach Wlan EGB Controller jetzt auf diese tolle Projekt gestossen.
Leider habe ich aber jetzt irgendwie Pribleme mit dem ESP.
Der Einfachheithalber habe ich mir als erstes mal ein AZDelivery D1 Mini NodeMcu Lua ESP8266 ESP-12E Entwicklerboard bestellt.
Hatte erst mal meine Probleme beim flashen, ging dann aber mit einer neueren Version des Upload Tools auch.
Problem ist das er sich die config nicht merkt. Ich kann.mich mit dem AP verbinden, SSID und passwort konfigurieren und er verbindet sich auch mit meinem WLAN, aber sobald dann der Reboot ausgeführt wird ist wieder alles weg.
2 mal ging es komischerweise, aber nach einem erneuten Reboot war wieder alles weg.
Wer eine Idee was ich falsch mache?
Danke
Crispyduck
Der Pin D0 muss auf High!
Also einfach den Pin D0 auf 3,3Volt und dann sollte er auch die Config speichern bzw. nicht gleich wieder verwerfen :)
(Hier auch mit einen Wemos D1 https://www.bastelbunker.de/esp-rgbww-wifi-led-controller-vbs-edition/)
Das wars; perfekt!
Danke!
Hallo,
danke nochmal, für die tolle Arbeit!
Noch eine Frage, wäre es möglich, noch etwas energie einzusparen, so wie es auch Tasmota mit sleep macht?
https://github.com/arendst/Sonoff-MQTT-OTA-Arduino/issues/272 (https://github.com/arendst/Sonoff-MQTT-OTA-Arduino/issues/272)
Mit der aktuellen testing FW habe ich standby ca. 0,35W mit der Tasmota FW und sleep 100 komme ich auf 0,2 runter.
Ich weiß, das ist so gut wie nichts, habe jetzt aber nur mal alle anderen möglichkeiten (ESPEasy, Tasmota) auch mal ausprobiert und da ist mir die Möglichkeit bei Tasmota aufgefallen.
Danke,
crispyduck
Ist nach meinem Verständnis ein anderer Andwendungsfall. Die lassen offenbar den Controller nur alle max. 500 ms mal aufwachen, um dann bei Bedarf mal ein Sonoff zu schalten?
Die RGBWW-Firmware läuft ja in einer 50 Hz-Schleife, um flüssige Animationen abzuspielen. Also da kann man nicht ohne weiteres ein Sleep von 500 ms reinsetzen. Wäre sicherlich möglich, an einigen Stellen zu optimieren, so dass solche Sleeps dynamisch ausgeführt werden, wenn gerade keine Animation läuft. Die Sleeps bedeuten aber in jedem Fall eine verzögerte Reaktion auf Befehle, die reinkommen, was irgendwie unschön ist (fände ich bei dem Sonoff auch nicht schön). Müsste man also dann konfigurierbar machen, damit dass der Benutzer je nach Geschmack/Anforderung einstellen kann.
Hallo,
Anscheinend nicht den ganzen Controller, das wäre dann ja der deep sleep mode. Wenn ich das richtig verstanden habe, dann wird wenn wifi_set_sleep_type(LIGHT_SLEEP_T); gesetzt ist bei jedem delay das wifi modul schlafen geschickt.
Klar kommt es dabei zu einer leichten Verzögerung und verspätete Reaktion des Controllers, bei Animationen,... natürlich sehr schlecht, aber im standby wäre es vermutlich egal und man würde die paar ms wohl gar nicht mit bekommen wenn man es nicht weiß.
Hatte das vorhin mir der Tasmota FW ausprobiert.
Aber ja, wenn man Animationen hat bei denen die LEDs auch ganz ausgehen, dürfte das dort nicht sein und man bräuchte somit wohl einen extra standby mode bei welchem dann ein konfigurierbarer delay von 0-250ms in Kraft tritt.
Wie gesagt, war nur eine Idee, und ist wohl auch nicht wirklich nötig. Die aktuelle FW verbraucht ausserdem sogar so schon etwas weniger als ESPEasy. :)
Bin mal froh das ich mit recht geringem Aufwand unsere Deckenleuchte wiederbeleben und endlich smart machen konnte.
THX,
crispyduck
Ich finde die Idee mit dem Sleep auch nicht schlecht, da hatte ich auch schon mal drüber nachgedacht....
Wenn man es Konfigurieren könne wäre es auf jeden Fall eine Option.
Man muss aber auch aufpassen, da es sich erst ab ein gewissen Sleep lohnt, denn der Aufbau der WLAN-Verbindung eine sehr hohe Stromaufnahme produziert.
Weniger Verbrauch ist natürlich immer nett. Und solange es konfigurierbar ist, tut es ja auch niemanden weh. Was denkt ihr, wie viel man da einsparen könnte? Weiß jemand wie viel Leistung das Ding momentan (genau) zieht?
Ich werde mich da voraussichtlich nicht mit befassen (können), aber eine Idee wäre, dass man diesen Sleep-Modus aktiviert, immer wenn die Animation-Queues aller 5 Kanäle leer gelaufen sind. Im Master-/Slave-Modus will man das evtl. lieber nicht aktivieren.
Shojo war so nett, das Webinterface noch weiter aufzubohren (shojo7). Zu finden in der neuen Firmware vbs31.
Besten Dank an Shojo dafür!
Ich hab Sming auf die neue Version 3.5.1 upgedatet. Die haben den Heap etwas optimiert, so dass bei uns ca. 2 kB mehr zur Verfügung steht. Vielleicht hat ja jemand Lust, mit zu testen :)
Hab es mal auf den testing-Kanal gelegt (http://rgbww.dronezone.de/testing/version.json)...
hi,
habs mal getestet und rein funktionell kein Problem endeckt..bis auf eins ;-)
Ich kann keine Änderung im WebIf mehr speichern. Wenn ich zum Beispiel die Update URL neu eintrage und auf speichern klicke kommt eine Fehlermeldung "..somthing went wrong...". Das selbe wenn ich das Farbschema von RGBwwcw auf RGB stellen will.
Aus diesem Grund nun ich zurück auf die Stable, da funzt das.
Gruß
Markus
Danke für den Hinweis. Scheint ein Sming-Bug zu sein, der auftritt bei HTTP-Bodys größer 1024 Byte. Hab es behoben in vbs33b. Bitte einmal testen.
EDIT:
Jetzt upstream behoben:
https://github.com/SmingHub/Sming/pull/1349
Also ich habe jetzt eine handvoll Controller seit 10 Tagen ohne Absturz am Laufen. Also die Reboots, die (offenbar nur) bei mir alle paar Tage aufgetreten sind, sind damit für mich behoben. Würde dann aus der Firmware eine stable vbs33 machen wollen, wenn nicht irgendjemand noch Einwände hat. @Shojo z.B.?
Moin,
ich musste auf die Stable zurück, da ich bei mir viel mit Licht Animationen mache und die neue FW irgendwie dann doch mein Fhem zugeballtert hat.
Hatte allerdings noch nicht die Zeit finden können das mir genau ansehen zu können.
Hm komisch, Verhalten sollte eigentlich das gleiche sein, nur neueres Sming. Kannst ja berichten wenns was neues gibt. Solange belasse ich es dann erstmal wie es ist.
kannst du bitte nochmal die letzten Bins der stable posten ?
Bin irgendwie zu blöd die auf Github zu finden... :-(
Hab da nämlich ein seltsames Problem mit einem ESP12F. Flashen lässt er sich einwandfrei. Nur macht er mit der VBS Firmware kein AP auf. Bügele ich dahingegen dann ESP_Easy drauf funzt das Ding einwandfrei...
Gruß
Markus
Schau mal hier rein ;)
http://rgbww.dronezone.de/release/version.json
{
-rom: {
fw_version: "0.3.1-vbs31",
url: http://rgbww.dronezone.de/release/rom0.bin
},
-spiffs: {
webapp_version: "0.3.3",
url: http://rgbww.dronezone.de/release/spiff_rom.bin
}
}
Fehlt aber die Boot... Oder.
Gibt's davon auch irgendwie eine komplette Bin die alle drei Teile beinhaltet? Oder geht das garnicht wegen den jeweiligen speicheradressen? Schon seltsam das Problem mit dem AP
Gruß
Markus
Die kompletten Dateien sind immer hier zu finden:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/gh-pages/release
Das Problem mit dem fehlenden AP war hier schon mehrfach Thema. Leider ohne Lösung. Falls du was rausfinden kannst wäre es super. Wenn ich raten müsste, würde ich tippen, dass es irgendwie an der Art des Flashes liegt? Wüsste gar nicht, was es sonst noch sein kann (Hardware identisch, Firmware identisch)...
Ich flashe immer so:
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 out/firmware/rboot.bin 0x01000 /home/vbs/Projects/esp-open-sdk/sdk/bin/blank.bin 0x02000 out/firmware/rom0.bin 0x100000 out/firmware/spiff_rom.bin
ja schon seltsam...Okay manchmal hat der ESP auch eine Macke. Aber das teste ich dann indem ich ESPEasy drauf flashe und teste. Ist hier auch der Fall. Bei der RGBW FW macht er keinen AP auf. Bei EasyESP läufts... :-(
Gruß
Markus
vergessen.....
in der Konsole kommt nur folgendes..
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2544, room 16
tail 0
chksum 0xef
load 0x00000000, len 0, room 8
tail 0
chksum 0xef
csum 0xef
csum err
ets_main.c
mmh ...egal wie ich und womit ich flashe, ich bekomme in der Seriellen Konsole nur das oben angezeigt.
esptool unter Windows - mit und ohne blank.bin auf 0x1000
esptool unter Linux - mit und ohne blank.bin auf 0x1000
und halt die diversen anderen "Flash-Helferleins" für ESP.
Gibt es irgendwie die Möglichkeit das als eine einzige Bin zu verpacken?
So langsam gehen mir die Ideen aus :-(
Gruß
Markus
Moin, versuche doch mal https://github.com/nodemcu/nodemcu-flasher/tree/master/Win32/Release
mit den folgenden Werten:
rboot.bin 0x00000
rom0.bin 0x02000
spiff_rom.bin 0x100000
selbes Problem :-(
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2544, room 16
tail 0
chksum 0xef
load 0x00000000, len 0, room 8
tail 0
chksum 0xef
csum 0xef
csum err
ets_main.c
Zitat von: Markus. am 10 April 2018, 11:13:17
vergessen.....
in der Konsole kommt nur folgendes..
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2544, room 16
tail 0
chksum 0xef
load 0x00000000, len 0, room 8
tail 0
chksum 0xef
csum 0xef
csum err
ets_main.c
Der bootet ja gar nicht richtig. Also nicht nur ein Problem mit dem AP. Ich denke weiterhin, dass da das Flashen schief geht.
Bist aber nicht der einzige mit dem Problem:
https://www.letscontrolit.com/forum/viewtopic.php?t=3071
https://github.com/esp8266/Arduino/issues/435
https://forum.sparkfun.com/viewtopic.php?t=46042
etc.
Moin
Irgendwie sieht die erste Adresse auch komisch aus!
load 0x40100000, len 2544, room 16
Wenn das denn eine Adressangabe ist!?
Gruss Christoph
so habs hin bekommen....
Anscheinend muss man bei den ESPs mit dem "AP Problem" einen anderen Flashmode verwenden.
Anstatt QIO den DOUT einstellen und fertig.
Hier mal was er nun anzeigt beim Starten...sieht viiiiel besser aus und macht AP jetzt brav auf.
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2544, room 16
tail 0
chksum 0xb1
load 0x3ffe8000, len 888, room 8
tail 0
chksum 0x9c
csum 0x9c
rBoot v1.4.2 - richardaburton@gmail.com
Flash Size: 32 Mbit
Flash Mode: unknown
Flash Speed: 40 MHz
rBoot Option: Big flash
rBoot Option: GPIO skip mode (16)
rBoot Option: RTC data
Booting rom 0.
rf[112] : 03
rf[113] : 00
rf[114] : 01
Unten mal Bilder von den Settings die ich verwendet habe. Und ich Depp wollte den ESP schon in die Tonne knallen.
Was ich nur nicht verstehe ist die Tatsache, das die Dinger sich so unterschiedlich verhalten.
Vielleicht kanns ja einer gebrauchen :-)
Gruß
Markus
Klasse, sehr interessant.
Ich hab nochmal etwas gegoggelt bzgl. der Hintergründe und einen Post im esp32-Forum gefunden, der genau die Frage stellt, warum manche "faulty" Chips nur per DOUT flashbar sind:
https://www.esp32.com/viewtopic.php?p=6949&sid=4321cd3aaa568c0d214e41fbf680c995#p6949
Antwort:
ZitatThere are two factors for which SPI flash modes work, but they don't depend on the ESP8266/ESP32 chip (the ESP8266/ESP32 chip itself will support all modes):
*The PCB or module design (in this case the ESP-01 design, by whoever did this.) It may not have the QIO/QOUT pads routed to the flash chip. Or maybe one is not soldered properly.
*The flash chip model. You can find this with "esptool.py flash_id" and then looking up the hex ID, or by reading the SPI flash chip. Not all SPI flash chips support all modes, the SPI flash datasheet explains the commands it supports.
ja, da muss ein Unterscheid der Flash-Chips sein. Mit "faulty" hat das eigentlich nichts zu tun. Die Chinamänner verwenden halt
anscheinend manchmal andere Flash-Chips die dann halt einen anderen SPI-Mode verlangen...
Flashen konnte man die Dinger auch einwandfrei und ohne Abbruch oder Fehler.. Nur beim booten ging nix mehr.
Hab das auch irgendwo im Zusammenhang mit Sonoff gelesen.
Aber das Problem hatte ich nur bei ESP12F und nie bei ESP12E.. aber wie auch immer funzt nun. Ich wäre nur mal besser früher drauf gekommen, hätte mir einiges an vermeidlich geschrotteten ESP12F's gespart..
Gruß
Markus
Zitat von: Shojo am 28 März 2018, 15:25:04
ich musste auf die Stable zurück, da ich bei mir viel mit Licht Animationen mache und die neue FW irgendwie dann doch mein Fhem zugeballtert hat.
So habe das "Problem" nicht nur mit der Testing, durch die ganzen Farbendehrungen in kurzer Zeit hat Fhem doch schon eine Menge mit dem Readings der Controllern zu tun.
Eine gute Lösung fällt mir da aber auch nicht ein :(
Also freie Bahn für das Testing Release :)
Zitat von: Markus. am 10 April 2018, 15:57:05
Hab das auch irgendwo im Zusammenhang mit Sonoff gelesen.
Hallo Markus,
mit meinen Sonoffs bin ich auch in diese Falle gelaufen. Meinst Du diesen Beitrag?
"20170714 - Tasmota needs compile Flash Mode option DOUT on all devices"
https://github.com/arendst/Sonoff-Tasmota/wiki/Theo's-Tasmota-Tips (https://github.com/arendst/Sonoff-Tasmota/wiki/Theo's-Tasmota-Tips)
In der Begruendung geht es zwar um den ESP8285, aber das Problem mit der Anbindung der SPI
flash chips ist wohl dasselbe.
Gruss Helmut
Zitat von: Shojo am 10 April 2018, 16:10:38
So habe das "Problem" nicht nur mit der Testing, durch die ganzen Farbendehrungen in kurzer Zeit hat Fhem doch schon eine Menge mit dem Readings der Controllern zu tun.
Eine gute Lösung fällt mir da aber auch nicht ein :(
Und dem ist auch nicht beizukommen mit den verschiedenen interval/mininterval-Config-Schaltern? Beschreib doch mal genauer unter welchen Umständen das passiert. Vielleicht muss ich irgendwo noch eine Drossel einbauen.
Zitat von: Shojo am 10 April 2018, 16:10:38
Also freie Bahn für das Testing Release :)
Ok, ich mach da mal ein Stable draus. Bei mir jetzt 5 Controller knapp 4 Wochen Dauerlauf ohne Reboot! Stabilste Firmware ever! ;)
nee ehrlich... wieder alle Controller updaten? ;D ;D ;D ;D ;D ;D ;D
Spass beiseite... Schon geil wie schnell auf irgendwelche Softwareprobleme hier reagiert wird !!!
Viiiiiielen Dank !
Gruß
Markus
Hab jetzt aus der testing vbs32b eine release vbs32 gemacht.
Zitatnee ehrlich... wieder alle Controller updaten? ;D ;D ;D ;D ;D ;D ;D
Wenn du in Eile bist, kannst du mit einem Befehl alle Controller updaten: :P
set TYPE=EspLedController fw_update
Zitat von: vbs am 10 April 2018, 19:25:48
Wenn du in Eile bist, kannst du mit einem Befehl alle Controller updaten: :P
set TYPE=EspLedController fw_update
Genau so mache ich das auch immer, das wäre sonst echt übel :D
so mache ich es nun auch.. :-)
ist schon eine geniale Funktion..
Gruß
Markus
Hab mal ein kleines Problem:
Meine beiden ESPController laufen auf der vbs32 Firmware.
Jetzt möchte ich sie WLan-Mäßig an eine andere Fritzbox anbinden. Dazu habe ich mir das Web-Interface aufgerufen und unter Network settings "forget" gedrückt.
Das klappt auch wunderbar. Der Controller ist jetzt unter 192.168.4.1 erreichbar. Der Name im Netzwerk ist erhalten geblieben.
Trage ich nun die neue SSID ein und versuche, die neuen Einstellungen auf den Controller zu übertragen, ist das iPad mit dem Controller angeblich nicht verbunden. Ich habe es mit drei Geräten versucht, immer dasselbe.
Die neuen Einstellungen lassen sich einfach nicht übertragen.
Übersehe ich da etwas?
Ein erneutes Flachen dürfte keinen Sinn machen, glaube ich...
Kannst du nochmal genauer beschreiben, was du gemacht hast und welche Fehler du dann siehst (im Wortlaut)? Kannst du evtl. in deinem Browser die Developer-Ansicht aktivieren und Screenshots von den Requests posten?
(https://uploads.tapatalk-cdn.com/20180415/d85d500f38ebac31858deadffb955745.jpg)
Controller Menü ,,Network settings"
Knopf ,,forget" gedrückt
Danach ist die IP 192.168.1.104 nicht mehr gültig, sondern die 192.168.4.1
Das erwarte ich auch so.
Dann lasse ich mir die verfügbaren WLans anzeigen und suche das richtige aus.
In meinem Fall von Tschabbobox auf Kabelbox24.
Die manuelle IP Vergabe bleibt bestehen.
Drücke ich jetzt unten auf ,,connect", kommt immer diese Meldung:
(https://uploads.tapatalk-cdn.com/20180415/9e243475285c6f7b57572b5caa648cba.jpg)
Kannst du die denn noch an deine alte Fritzbox verbinden? Umd hast du sie nach dem Forgett mal stromlos gemacht ? Wenn du sie neu flashst solltest du vorher ein erase_flash machen. Hilft manchmal wahre Wunder...
Ich würde auch mal die Ssid umd so manuell eingeben umd eventuell anderen browser testen. Bei mir funktioniren die am besten mit chrome.
Gruß
Markus
Der Request sagt:
Failed to load resource: the server responded with a status of 400 (Bad Request)
Die alte Fritzbox kann ich nicht mehr verbinden, die Daten sind wohl überschrieben mit dem default.
Ja, stromlos hab ich gemacht, kein Erfolg.
Probier mal mit chrome und ssid manuell eingeben. Hast du die ip fest vergeben?
Chrome verhält genauso. Dieselbe Fehlermeldung.
SSID händisch eingetragen und die IP manuell vergeben.
Fritzbox ist auch offen für neue Geräte, aber das ist ja erst ein Schritt weiter dran.
Seltsam... würde mal neu flashen umd vorher mit esptool ein flash_erase machen.
Hm, hab es gerade mal ausprobiert und einen Controller "forgetten" lassen und dann neu ins WLAN eingebunden. Hat erstmal geklappt.
Hast du evtl. "sehr seltsame" Sonderzeichen im Passwort? Ich kann mich erinnern, dass ich da auch mal Probleme hatte.
Wäre interessant zu wissen, ob das erase_flash hilft. Dann würde es bedeuten, dass der Controller irgendwie in einem seltsamen Zustand war. Aber sollte generell nicht die Lösung sein, weil das dann ja kein OTA mehr wäre.
Das WLan PW besteht nur aus Buchstaben.
Ich habe jetzt mal den zweiten Controller forgetten lassen, der muss auch rüber ins andere WLan.
Der verhält sich identisch zum ersten.
Also werde ich wirklich neu flashen, das schaffe ich jetzt aber nicht mehr.
Ich gebe Rückmeldung, was daraus wird.
Habt erst einmal vielen Dank für eure Unterstützung!
Aber denke an das Flash_erase vorher..;-)
Gruß
Markus
Sooooo, hab jetzt mal den ersten Controller geflashed.
Im ersten Versuch ganz bewußt ohne den erase vorweg zu schicken.
Das hat schon funktioniert. Die original Firmware hat sich erwartungsgemäß gemeldet.
Hab dann mein Netzwerk eingetragen, connected und alles ist gut.
Dann noch OTA die vbs Version 32 hinterher.
Top! Geht wieder.
Soll ich trotzdem den Speicher löschen?
Hab ja noch alles am "Flasher" dran...
Also ich kanns mir nicht erklären, was das nochmalige Flashen der FW verändert haben soll. Wie hast du denn geflasht? Wirklich nur die FW, sonst nix?
Nö, wirklich nur die Firmware.
Verstehen kann ich das Verhalten nicht.
Zumal sich der zweite Controller genauso verhält...
Sorry, aber die für mich einzig sinnvolle Erklärung wäre, dass du doch (unbeabsichtigt) beim Flashen irgendwas anderes mit geändert hast?
Kann mir sonst nicht erklären, wie es irgend etwas verändern kann, wenn man an die exakt gleiche Stelle im Flash die exakt gleichen Bits nochmal reinschreibt.
Beim Flashen schreibe ich doch diese drei Dateien.
So wie es in der Anleitung geschrieben steht.
Bin jetzt grad bei der Arbeit, sonst würde ich dir den Befehl kurz posten.
Aber erstmal bin ich froh, es so wieder zum Laufen bekommen zu haben.
Eventuell anderer FlashMode?!
Gruß
Markus
Ist der ESP nicht in der Lage seinen eigenen Flash zu überschreiben während der Laufzeit? Sonst würde ja OTA nicht gehen. Also ich kann mir schon vorstellen das durch irgend welche Fehler in der Software sowas passiert bzw. auch bei unstabiler Spannung unkontrolliert... Der ESP macht ja viel scheiss wenn es darum geht...
Können denn die neu geflashten Controller "forgetten" und dann wieder neu angemeldet werden?
Jetzt mal den vollständigen Werdegang:
Controller 1:
Fehlermeldung wie oben im Bild: Connection failed beim Versuch, die geänderten WLan Einstellungen zu schreiben.
Controller geflashed mit:
esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.bin
Controller meldet sich mit eigenem WLan "RGBWW1560..." unter 192.168.4.1
WLan Eintragung geändert, übertragen, funktioniert.
Controller 2:
Wie bei Controller 1 die Fehlermeldung
Wie bei Controller 1 geflashed
Unterschied: Controller 2 meldet sich mit seinem alten AP-Namen "StubeDecke", nicht mit "RGBWW15..."
Beim Versuch, die geänderten WLan Einstellungen zu schreiben, wieder die Fehlermeldung wie oben.
Also den Löschtip angenommen:
esptool.py --port /dev/tty.SLAB_USBtoUART erase_flash
Danach neu geflashed und siehe da, er meldet sich mit "RGBWW15603934" und lässt sich wunderbar beschreiben.
Ich hoffe, ihr könnt durchsteigen... 8)
Zitat von: MacReiner am 16 April 2018, 14:13:11
esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.bin
Mit dem Befehl (über)schreibst du ja auch das Dateisystem (spiff_rom.bin). Also den Teil, in dem die gesamte Konfiguration des Controllers (außer WLAN) gespeichert ist. Das wäre mMn am ehesten ein Kandidat, der für eine Änderung im Verhalten verantwortlich sein könnte.
Hab jedoch weiterhin 0 Ideen, was dazu führen könnte, dass ein Config-Request mit HTTP-400 beantwortet werden sollte.
Mal ne Frage..
Sind das 100% die selben ESPs auf den Controllern?
Also ich meine ESP12E oder F?
Unterscheiden kann man die an dem "Antennenprint"
https://blog.thomasheldt.de/esp8266-module-uebersicht/ (https://blog.thomasheldt.de/esp8266-module-uebersicht/)
Gruß
Markus
Das wäre durchaus eine Möglichkeit.
Durch Verpolen hab ich mal zwei Controller gehimmelt.
Da musste ich die ESP's über eBay nachkaufen.
Bin jetzt wieder bei der Arbeit, somit sehe ich morgen Nachmittag nach.
wenn das "F's" sind versuche die mal mit DOUT direkt mit der VBS-Firmware zu flashen.
Ich hatte bei manchen Fs das Problem nach dem Flashen, das die keinen AP aufgemacht haben. Auch hatte ich schon welche, die ich dann mit der "originalen" FW geflasht habe und nach einem OTA auf die VBS-FW ständige reboots gemacht haben wenn man im WEB-IF oder per FHEM was gesteuert hat. Dann habe ich ein Flash_erase gemacht und die VBS FW mit DOUT geflasht und alles war gut. Mit E's hatte ich das Problem noch nicht. Irgendwie verrückt da ja die Hardware eigentlich identisch ist. Aber anscheinend gibt es da Unterschiede in den verbauten Flash-Chips
Gruß
Markus
Ich glaube eher, dass es da einen ganz rationalen Grund gibt. Der Controller verhält sich ja nicht irgendwie komisch oder undefiniert, sondern liefert ja ganz gezielt ein HTTP-400 als Antwort. Ich hab mal (für die nächste Version) die HTTP-Error-Responses mit einem Fehlertext angereichert, der einen Hinweis geben soll, was genau denn das Problem war... Vielleicht hat man dann eine Chance herauszufinden, was das Problem ist (beim nächsten Auftreten).
Ja, ein wenig Klartext ist immer hilfreich.
Das Flashen mit der Option dout würde ich mir gerne aufsparen.
Im Moment machen beide Controller, was sie sollen.
In der Beschreibung des Flashens steht, dass da etwas 50% langsamer wird.
Hat das für uns eine Bedeutung?
Mir ist nicht so klar, was jetzt ein erneutes Flashen mit DOUT überhaupt bringen würde, da es doch jetzt eh funktioniert?
Weiß jemand, ob diese DOUT/QIO Geschichte auch das OTA-Flashen betrifft?
Es sind beides die F Typen...
Hi,
ich habe Fragen, wahrscheinlich auch ein Problem ...
Ich dachte ich teste mal die neuere Firmware und das Modul.
Das einzige was funktioniert ist "blink", "on" und "off". Sonst kann ich über das Modul nichts schalten oder steuern. Über das Web - auf dem Controller selbst - kann ich Farben auch setzen. Zurücksetzen mit den Buttons auf der Platine und neues Einhängen in das Wlan brachte auch keine Änderung.
Zurückflashen auf die alte Firmware und test mit dem alten Modul sind weiterhin problemlos möglich. Defekt am Controller schließe ich damit erstmal aus.
Geflasht bis jetzt ausschließlich über OTA.
Altes Modul 32_LedController durch 32_ESPLedController ersetzt. Version glaub von Januar.
Nutze ich eine Kombination die nicht supportet wird, oder woran könnte es liegen?
Danke im Voraus!
Mein Setup:
Firmware
vbs32
Web Interface
0.3.3-shojo7
RGBWW Version
0.8.1-vbs5
SMING Version
3.5.1
Update Firmware
Be sure to only apply updates from trusted sources. Official Firmware updates are available via Github
OTA URL
http://rgbww.dronezone.de/release/version.json
List in Fhem
Internals:
CFGFN
DEF 192.168.0.60
DeviceName 192.168.0.60:9090
FD 20
IP 192.168.0.60
LAST_RECV 1524253120.87087
NAME LED2
NR 18728
NTFY_ORDER 50-LED2
PARTIAL
PORT 9090
STATE opened
TYPE EspLedController
OLDREADINGS:
READINGS:
2018-04-20 21:38:54 colorMode hsv
2018-04-20 21:16:38 config-color-brightness-blue 100
2018-04-20 21:16:38 config-color-brightness-cw 100
2018-04-20 21:16:38 config-color-brightness-green 100
2018-04-20 21:16:38 config-color-brightness-red 100
2018-04-20 21:16:38 config-color-brightness-ww 100
2018-04-20 21:16:38 config-color-colortemp-cw 6000
2018-04-20 21:16:38 config-color-colortemp-ww 2700
2018-04-20 21:16:38 config-color-hsv-blue 0
2018-04-20 21:16:38 config-color-hsv-cyan 0
2018-04-20 21:16:38 config-color-hsv-green 0
2018-04-20 21:16:38 config-color-hsv-magenta 0
2018-04-20 21:16:38 config-color-hsv-model 0
2018-04-20 21:16:38 config-color-hsv-red 0
2018-04-20 21:16:38 config-color-hsv-yellow 0
2018-04-20 21:16:38 config-color-outputmode 0
2018-04-20 21:16:38 config-events-color_interval_ms 500
2018-04-20 21:16:38 config-events-color_mininterval_ms 500
2018-04-20 21:16:38 config-events-server_enabled 1
2018-04-20 21:16:38 config-events-transfin_interval_ms 1000
2018-04-20 21:16:38 config-general-device_name LED2
2018-04-20 21:16:38 config-general-pin_config 13,12,14,5,4
2018-04-20 21:16:38 config-network-ap-password rgbwwctrl
2018-04-20 21:16:38 config-network-ap-secured 0
2018-04-20 21:16:38 config-network-ap-ssid RGBWW1265235
2018-04-20 21:16:38 config-network-connection-dhcp 0
2018-04-20 21:16:38 config-network-connection-gateway 192.168.0.1
2018-04-20 21:16:38 config-network-connection-ip 192.168.0.60
2018-04-20 21:16:38 config-network-connection-netmask 255.255.255.0
2018-04-20 21:16:38 config-network-mqtt-enabled 0
2018-04-20 21:16:38 config-network-mqtt-password
2018-04-20 21:16:38 config-network-mqtt-port 0
2018-04-20 21:16:38 config-network-mqtt-server
2018-04-20 21:16:38 config-network-mqtt-topic_base home/
2018-04-20 21:16:38 config-network-mqtt-username
2018-04-20 21:16:38 config-ota-url http://rgbww.dronezone.de/release/version.json
2018-04-20 21:16:38 config-security-api_secured 0
2018-04-20 21:16:38 config-sync-clock_master_enabled 0
2018-04-20 21:16:38 config-sync-clock_master_interval 30
2018-04-20 21:16:38 config-sync-clock_slave_enabled 0
2018-04-20 21:16:38 config-sync-clock_slave_topic home/led1/clock
2018-04-20 21:16:38 config-sync-cmd_master_enabled 0
2018-04-20 21:16:38 config-sync-cmd_slave_enabled 0
2018-04-20 21:16:38 config-sync-cmd_slave_topic home/led1/command
2018-04-20 21:16:38 config-sync-color_master_enabled 0
2018-04-20 21:16:38 config-sync-color_master_interval_ms 0
2018-04-20 21:16:38 config-sync-color_slave_enabled 0
2018-04-20 21:16:38 config-sync-color_slave_topic home/led1/color
2018-04-20 21:38:54 ct 4406
2018-04-20 21:38:54 hsv 227.21,88.95,98.04
2018-04-20 21:38:54 hue 227.21
2018-04-20 21:16:44 info-connection-dhcp 0
2018-04-20 21:16:44 info-connection-gateway 192.168.0.1
2018-04-20 21:16:44 info-connection-ip_address 192.168.0.60
2018-04-20 21:16:44 info-connection-mac 5ccf7f134e53
2018-04-20 21:16:44 info-connection-netmask 255.255.255.0
2018-04-20 21:16:44 info-connection-ssid MySSID
2018-04-20 21:16:44 info-current_rom_slot 1
2018-04-20 21:16:44 info-deviceid 1265235
2018-04-20 21:16:44 info-event_num_clients 1
2018-04-20 21:16:44 info-firmware vbs32
2018-04-20 21:16:44 info-sming_version 3.5.1
2018-04-20 21:16:44 info-uptime 300
2018-04-20 21:16:44 info-webapp_version 0.3.3-shojo7
2018-04-20 21:38:54 pct 98.04
2018-04-20 21:38:54 raw_blue 877
2018-04-20 21:38:54 raw_cw 55
2018-04-20 21:38:54 raw_green 0
2018-04-20 21:38:54 raw_red 14
2018-04-20 21:38:54 raw_ww 55
2018-04-20 21:38:54 rgb 1c4cfa
2018-04-20 21:38:54 sat 88.95
2018-04-20 21:13:49 state opened
2018-04-20 21:38:54 stateLight on
2018-04-20 21:38:54 val 98.04
helper:
isBusy 0
oldVal 98.04
bm:
EspLedController_Attr:
cnt 12
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:36:11
max 0.000284910202026367
tot 0.00115776062011719
mAr:
del
LED2
defaultRamp
EspLedController_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:13:49
max 0.00571703910827637
tot 0.00571703910827637
mAr:
HASH(0x8ad1050)
LED2 EspLedController 192.168.0.60
EspLedController_Get:
cnt 13
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:16:44
max 0.00232195854187012
tot 0.011648416519165
mAr:
HASH(0x8ad1050)
LED2
info
EspLedController_Notify:
cnt 115
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:14:43
max 0.000245094299316406
tot 0.0061957836151123
mAr:
HASH(0x8ad1050)
HASH(0x8ad1050)
EspLedController_Read:
cnt 1077
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:32:05
max 0.0120728015899658
tot 4.46697115898132
mAr:
HASH(0x8ad1050)
EspLedController_Set:
cnt 108
dmx -1000
dtot 0
dtotcnt 0
mTS 20.04. 21:22:56
max 0.00518608093261719
tot 0.168472528457642
mAr:
HASH(0x8ad1050)
LED2
rotate
1
120
l
q
cmdQueue:
lastCall:
NAME
addr http://192.168.0.60:80
auth 0
buf
code 200
compress 1
conn
data {"hsv":{"h":"+1"},"q":"back","t":120000,"d":1,"cmd":"fade"}
displayurl http://192.168.0.60/color
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host 192.168.0.60
httpheader HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 16
Connection: keep-alive
Server: HttpServer/Sming
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
loglevel 5
method POST
path /color
protocol http
redirects 0
timeout 30
url http://192.168.0.60/color
cmd:
cmd fade
d 1
q back
t 120000
hsv:
h +1
hash:
sslargs:
Attributes:
DbLogExclude .*
devStateIcon on:ios-on-blue:off off:ios-off:on
group LED
room Wohnzimmer
mir ist aufgefallen, dass irgend etwas in der Queue in Schleife läuft. Nochmal komplett geflasht und ich kann Farbe setzen.
Muss morgen oder die nächsten Tage nochmal genauer nachsehen. Parameter "q" funktioiert bei mir nicht. Bin aber schon einen Schritt weiter.
Klingt so, als würde die neue Modulversion nicht greifen oder irgendwie vermischt mit der alten laufen. Ich würde in jedem Fall erstmal Modul und Firmware auf den neuesten Stand bringen. Das ist dann die Kombination, die funktionieren muss.
Ansonsten bitte einmal FHEM neu starten, um sicher zu gehen, dass da nicht noch alte Timer oder alte Devices rumschwirren.
Wenn alles nicht hilft, dann bitte mal ein Log mit verbose 5 des Devices posten. Dann kann man da hoffentlich sehen, was da vor sich geht.
Hab eine vbs33b auf testing gelegt. Man kann eine feste Farbe konfigurieren, auf die beim Booten geschaltet wird, anstelle der gespeicherten letzten Farbe (hatte sich Peter gewünscht):
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#startup-color--vbs33
Zitat von: vbs am 21 April 2018, 10:15:20
Klingt so, als würde die neue Modulversion nicht greifen oder irgendwie vermischt mit der alten laufen. Ich würde in jedem Fall erstmal Modul und Firmware auf den neuesten Stand bringen.
Modul: https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
==> UPD 2018-01-23_12:00:00 62792 FHEM/32_EspLedController.pm
Firmware: http://rgbww.dronezone.de/testing/version.json
==> OTA wird fehlerfrei ausgeführt. Im Anschluss wird die installierte und die verfügbare Version nicht identisch angezeigt. Kann es sein, dass hier im Flash zwar die richtige Version ist, die Bezeichnung aber nicht angepasst wurde?
Lt. Readings ... ich weiß, gestern hast du vbs33 released. Die hab ich noch nicht drin.
info-firmware vbs32
info-sming_version 3.5.1
info-webapp_version 0.3.3-shojo7
Ich denke, ich habe die richtige Updatequelle und alles aktuell.
Die Hilfe sagt .... set <name> rotate <angle> [ramp] [l|q]
Ist somit set LED2 rotate 1 120 l q nicht möglich? [l|q] -> optional, und als Wert in der Liste "l" ODER "q"? Ich denke, beides sollte möglich sein?
Ich habe die Rorate so in der alten Version von Firmware und Modul 2 Jahre genutzt.
Was ich bezwecke: Eine LED die permanent den Farbkreis abarbeitet, Dauer dafür ca. 2 Minuten. Das habe ich als AT alle 2 Minuten abgefeuert.
Gibt es eine bessere Option? In der Firmare gibt es die Möglichkeit, ein automatischer restart direkt in der Firmware ohne erneuter Flash. Ist das im Modul möglich, oder müsste ich da einen REST-aufruf machen?
Dieser Thread ist eigentlich Firmware. Wenn es besser im Modul-Thread aufgehoben ist, kann ich das auch dort posten. Ich wusste / weiß nicht genau, ob es mein Fehler im Aufruf ist, oder ein Verständnisproblem.
Was ich durch Starten von "rotate" mit und ohne "q"-Option jetzt 2mal hatte ... Laut Modul wird die Farbe gewechselt, jedoch glimmt die LED nur ganz leicht, wechselt aber nicht die Farbe. On, off, Farbe setzen funktioniert nicht mehr. CLR / reset und komplett neu konfigurieren bringt den Controller wieder zum Leben. Dann funktioniert auch schalten wieder. Wie ich das nun geschafft habe weiß ich nicht. Hab durch rumtesten zu viel gemacht. Bewusst nachstellen konnte ich es aber nicht mehr.
Edit: .... ach ja, Fhem war / ist aktuell, wurde vor den Tests durchgestartet, ...
Zitat von: vbs am 21 April 2018, 14:10:41
Hab eine vbs33b auf testing gelegt. Man kann eine feste Farbe konfigurieren, auf die beim Booten geschaltet wird, anstelle der gespeicherten letzten Farbe
Oh wieder Arbeit für mich :)
Zitat von: kadettilac89 am 22 April 2018, 22:03:56
Die Hilfe sagt .... set <name> rotate <angle> [ramp] [l|q]
Sorry die commandref ist lange nicht gepflegt. Sollte ich am besten mal rausnehmen. Ich mag nicht so gern HTML tippen... :(
Versuche die Doku hier zu pflegen:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Zitat von: kadettilac89 am 22 April 2018, 22:03:56
Ich habe die Rorate so in der alten Version von Firmware und Modul 2 Jahre genutzt.
Was ich bezwecke: Eine LED die permanent den Farbkreis abarbeitet, Dauer dafür ca. 2 Minuten. Das habe ich als AT alle 2 Minuten abgefeuert.
Gibt es eine bessere Option? In der Firmare gibt es die Möglichkeit, ein automatischer restart direkt in der Firmware ohne erneuter Flash. Ist das im Modul möglich, oder müsste ich da einen REST-aufruf machen?
Hier findest du Beispiele für sowas:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#function-demonstrations
@Shojo
Yay! :)
Zitat von: vbs am 23 April 2018, 14:03:26
Sorry die commandref ist lange nicht gepflegt. Sollte ich am besten mal rausnehmen. Ich mag nicht so gern HTML tippen... :(
Versuche die Doku hier zu pflegen:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
....
Ich werde es mal testen. Der r-Parameter im Modul sieht vielversprechend aus. Thx
So wollte mich heute mal an die testing ran machen.
Nach update ist bei mir der Controller in einer Bootschleife, hatte das wer auch?
Zitat von: Shojo am 26 April 2018, 20:41:57
Nach update ist bei mir der Controller in einer Bootschleife, hatte das wer auch?
Ok, hatte das nur bei einen Controller :)
Hast du neue Testing noch nicht auf github eingecheckt oder bin ich blind?
Ja schei*e, hab ich offenbar vergessen zu pushen... sorry hol ich nachher oder spätestens morgen nach...
Zitat von: vbs am 29 April 2018, 11:52:13
Geht es um die vbs-Variante oder um das Original-Modul? Wenn vbs, dann lass uns das lieber in dem vbs-Thread besprechen, sonst kriegt Peter bestimmt hier ne Krise, wenn wir ihn mit meinen Problemen belästigen ;)
Ich antworte im Firmware-Thread wie gewünscht. Hatte im Modulbereich geschrieben da es um das Modul geht. Aber OK. Ggf. eigener Thread? .... Link https://forum.fhem.de/index.php/topic,55065.msg797750.html#msg797750
Zitat von: vbs am 29 April 2018, 11:52:13
Hatte dir ja neulich schonmal geantwortet (https://forum.fhem.de/index.php/topic,70738.msg796026.html#msg796026), dass ich vermute, dass deine Installation irgendwie in einem komisch Zustand ist. Hast du da etwas rausfinden können? Alle anderen Effekte könnten dann einfach Folgefehler sein.
Ich hatte hierauf auch geantwortet.
Post im Modulbereich sollten weitere Informationen sein um einzugrenzen.
Mein Modul ist das aktuelle vom Update-Link bzw. deinem Github. ... war es von Beginn an. Stand des Moduls ist Januar.
Firmware des Controllers war vbs32, jetzt vbs33
"git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1"
Das von mir gemeldete Verhalten ist unabhängig von der Firmware. Habe eine andere IP eingetragen, dann gibt es keinen LED-Controller der gefunden werden kann. Dennoch wertet das Modul an der gemeldeten Stelle Parameter falsch aus, und setzt d:1 statt d:0.
Ich habe das auch in 2 VM, einmal Debian 7, einmal Debian 9 getestet. Komplett neue, nackte Fhem-Installation + alle Updates. Nachstellbar.
Testfall:
Name des Devices LED3_new ... Devicename entsprechend ändern
set LED3_new hsv 0,100,100 .... (rot, volle helligkeit, volle Sättigung).
Ohne requeue
set LED3_new hue +359 l 5
Auszug aus dem Log
LED3_new: encoded json data: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"d":0,"q":"single"}
--> Verhalten wie gewünscht. Voller Farbkreis in 5 Sekunden
set LED3_new hue +359 l 5 r
Auszug aus dem Log
LED3_new: encoded json data: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"q":"single", ----> "d":1 <----,"r":"true"}
"d:1" ist falsch. Dadurch wird nur 1 Grad des Farbkreises gemacht statt 359 wie oben
Hoffe das war verständlich. Mit der geposteten Änderung läuft es bei mir richtig.
Ich denke du hast RGB-Leds ... bitte mal bei dir testen, wenn es nachstellbar ist, siehst du sofort was ich meine, wenn nicht ... Perl-Version? Hardware? ...
Zitat von: kadettilac89 am 29 April 2018, 15:34:56
set LED3_new hue +359 l 5 r
Die Flags gelten als ein Parameterblock. Du musst das so schreiben:
set LED3_new hue +359 lr 5
Zitat von: vbs am 29 April 2018, 15:56:18
Die Flags gelten als ein Parameterblock. Du musst das so schreiben:
set LED3_new hue +359 lr 5
Damit gehts, kommt es hier auf die Reihenfolge der Parameter an?
Hast du noch eine Idee wie ich die Meldunden weg bekomm? Ggf. erst auf Level verbose3.
2018.04.29 17:00:01.464 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:00:01.438 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:56.244 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:56.213 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:51.038 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:50.999 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:45.793 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:45.765 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:40.262 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:40.237 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:35.023 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:35.003 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:29.822 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:29.792 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:24.619 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:24.585 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:19.404 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:19.362 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:14.023 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:13.987 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
Habe die Event-Zeiten runtergeschraubt damit nur noch alle 5 Sekunden die Farbwerte übertragen werden. SCheinbar gefällt das FHEM nicht da der Eintrag auch alle 5 Sekunden da ist.
Zuerst hatte ich nicht nur "config-events-color_interval_ms" gesetzt. Zum Test auch die beiden anderen obwohl die für die Farbwerte nicht nötig sind ... zumindest mein Verständnis. Auch bei allen 3 gestetzen Werten bleiben die Einträge.
config-events-color_interval_ms 5000
config-events-color_mininterval_ms 5000
config-events-server_enabled 1
config-events-transfin_interval_ms 5000
Zitat von: kadettilac89 am 29 April 2018, 17:07:42
Damit gehts, kommt es hier auf die Reihenfolge der Parameter an?
Hm nee, der Flags-String ist einfach
einParameter. Der kann nicht aufgespalten werden in mehrere Flags-Parameter.
Zitat von: kadettilac89 am 29 April 2018, 17:07:42
Hast du noch eine Idee wie ich die Meldunden weg bekomm? Ggf. erst auf Level verbose3.
2018.04.29 17:00:01.464 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:00:01.438 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:56.244 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:56.213 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:51.038 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:50.999 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:45.793 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:45.765 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:40.262 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:40.237 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:35.023 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:35.003 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:29.822 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:29.792 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:24.619 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:24.585 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:19.404 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:19.362 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 16:59:14.023 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 16:59:13.987 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
Das Problem ist mMn eher, dass die Meldungen überhaupt kommen :o Das Device wird alle paar Sekunden als disconnected erkannt. Sollte so nicht sein. Poste doch mal ein verbose5-Log.
Zitat von: vbs am 29 April 2018, 17:20:15
Das Problem ist mMn eher, dass die Meldungen überhaupt kommen :o Das Device wird alle paar Sekunden als disconnected erkannt. Sollte so nicht sein. Poste doch mal ein verbose5-Log.
Ich habe mal einen Teil gepostet, wiederholt sich dann immer wieder.
Edit: wie prüftst du ob der Controller "disappeared" oder "reappeared"? Ich habe eine Firewall aktiv.
Habe nun mal die rules geflusht, sehe die Meldungen nicht mehr. Werde es beobachten.
":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:15.388 4: LED2: got color response
2018.04.29 17:30:20.000 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:20.000 5: LED2: No PARTIAL buffer
2018.04.29 17:30:20.005 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":215,"g":0,"b":142,"ww":0,"cw":0},"hsv":{"h":306.33,"s":100.00,"v":35.00,"ct":4406}},"id":432}
2018.04.29 17:30:20.006 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":215,"g":0,"b":142,"ww":0,"cw":0},"hsv":{"h":306.33,"s":100.00,"v":35.00,"ct":4406}},"id":432}
2018.04.29 17:30:20.007 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 167 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":215,"g":0,"b":142,"ww":0,"cw":0},"hsv":{"h":306.33,"s":100.00,"v":35.00,"ct":4406}},"id":432}
2018.04.29 17:30:20.038 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:20.038 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:20.049 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:21.002 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:21.010 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:21.183 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:21.183 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:21.227 4: LED2: got config response
2018.04.29 17:30:21.227 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:21.308 4: LED2: got config response
2018.04.29 17:30:21.308 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:21.358 3: LED2: got info response
2018.04.29 17:30:21.358 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22064,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:21.396 4: LED2: got color response
2018.04.29 17:30:25.224 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:25.224 5: LED2: No PARTIAL buffer
2018.04.29 17:30:25.228 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":255,"g":0,"b":102,"ww":0,"cw":0},"hsv":{"h":321.29,"s":100.00,"v":35.00,"ct":4406}},"id":433}
2018.04.29 17:30:25.228 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":255,"g":0,"b":102,"ww":0,"cw":0},"hsv":{"h":321.29,"s":100.00,"v":35.00,"ct":4406}},"id":433}
2018.04.29 17:30:25.229 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 167 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":255,"g":0,"b":102,"ww":0,"cw":0},"hsv":{"h":321.29,"s":100.00,"v":35.00,"ct":4406}},"id":433}
2018.04.29 17:30:25.253 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:25.253 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:25.264 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:25.399 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:25.407 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:25.573 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:25.573 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:25.614 4: LED2: got config response
2018.04.29 17:30:25.614 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:25.672 4: LED2: got config response
2018.04.29 17:30:25.672 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:25.722 3: LED2: got info response
2018.04.29 17:30:25.722 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22064,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:25.754 4: LED2: got color response
2018.04.29 17:30:30.426 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:30.430 5: LED2: No PARTIAL buffer
2018.04.29 17:30:30.430 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":295,"g":0,"b":62,"ww":0,"cw":0},"hsv":{"h":336.19,"s":100.00,"v":35.00,"ct":4406}},"id":434}
2018.04.29 17:30:30.430 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":295,"g":0,"b":62,"ww":0,"cw":0},"hsv":{"h":336.19,"s":100.00,"v":35.00,"ct":4406}},"id":434}
2018.04.29 17:30:30.431 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 166 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":295,"g":0,"b":62,"ww":0,"cw":0},"hsv":{"h":336.19,"s":100.00,"v":35.00,"ct":4406}},"id":434}
2018.04.29 17:30:30.458 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:30.458 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:30.469 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:31.001 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:31.009 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:31.178 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:31.179 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:31.219 4: LED2: got config response
2018.04.29 17:30:31.219 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:31.299 4: LED2: got config response
2018.04.29 17:30:31.299 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:31.357 3: LED2: got info response
2018.04.29 17:30:31.358 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22064,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:31.389 4: LED2: got color response
2018.04.29 17:30:31.942 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:31.942 5: LED2: No PARTIAL buffer
2018.04.29 17:30:31.942 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":305,"g":0,"b":52,"ww":0,"cw":0},"hsv":{"h":340.35,"s":100.00,"v":35.00,"ct":4406}},"id":435}
2018.04.29 17:30:31.942 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":305,"g":0,"b":52,"ww":0,"cw":0},"hsv":{"h":340.35,"s":100.00,"v":35.00,"ct":4406}},"id":435}
2018.04.29 17:30:31.943 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 166 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":305,"g":0,"b":52,"ww":0,"cw":0},"hsv":{"h":340.35,"s":100.00,"v":35.00,"ct":4406}},"id":435}
2018.04.29 17:30:31.957 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:31.957 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:31.967 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:32.000 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:32.006 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:32.303 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:32.304 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:32.345 4: LED2: got config response
2018.04.29 17:30:32.346 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:32.426 4: LED2: got config response
2018.04.29 17:30:32.426 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:32.496 3: LED2: got info response
2018.04.29 17:30:32.496 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22016,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:32.535 4: LED2: got color response
2018.04.29 17:30:35.997 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:35.997 5: LED2: No PARTIAL buffer
2018.04.29 17:30:35.997 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":335,"g":0,"b":22,"ww":0,"cw":0},"hsv":{"h":351.38,"s":100.00,"v":35.00,"ct":4406}},"id":436}
2018.04.29 17:30:35.998 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":335,"g":0,"b":22,"ww":0,"cw":0},"hsv":{"h":351.38,"s":100.00,"v":35.00,"ct":4406}},"id":436}
2018.04.29 17:30:35.999 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 166 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":335,"g":0,"b":22,"ww":0,"cw":0},"hsv":{"h":351.38,"s":100.00,"v":35.00,"ct":4406}},"id":436}
2018.04.29 17:30:36.025 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:36.025 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:36.026 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:36.026 5: LED2: No PARTIAL buffer
2018.04.29 17:30:36.026 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"transition_finished","params":{"name":"Rainbow","requeued":true},"id":437}
2018.04.29 17:30:36.026 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"transition_finished","params":{"name":"Rainbow","requeued":true},"id":437}
2018.04.29 17:30:36.027 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 101 Content: {"jsonrpc":"2.0","method":"transition_finished","params":{"name":"Rainbow","requeued":true},"id":437}
2018.04.29 17:30:36.028 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:36.029 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:40.988 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:40.989 5: LED2: No PARTIAL buffer
2018.04.29 17:30:40.989 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":341,"g":16,"b":0,"ww":0,"cw":0},"hsv":{"h":6.33,"s":100.00,"v":35.00,"ct":4406}},"id":438}
2018.04.29 17:30:40.989 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":341,"g":16,"b":0,"ww":0,"cw":0},"hsv":{"h":6.33,"s":100.00,"v":35.00,"ct":4406}},"id":438}
2018.04.29 17:30:40.991 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 164 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":341,"g":16,"b":0,"ww":0,"cw":0},"hsv":{"h":6.33,"s":100.00,"v":35.00,"ct":4406}},"id":438}
2018.04.29 17:30:41.019 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:41.019 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:41.033 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:42.002 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:42.010 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:42.180 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:42.180 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:42.222 4: LED2: got config response
2018.04.29 17:30:42.222 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:42.305 4: LED2: got config response
2018.04.29 17:30:42.305 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:42.373 3: LED2: got info response
2018.04.29 17:30:42.373 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22064,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:42.411 4: LED2: got color response
2018.04.29 17:30:46.203 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:46.204 5: LED2: No PARTIAL buffer
2018.04.29 17:30:46.207 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":301,"g":56,"b":0,"ww":0,"cw":0},"hsv":{"h":21.29,"s":100.00,"v":35.00,"ct":4406}},"id":439}
2018.04.29 17:30:46.207 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":301,"g":56,"b":0,"ww":0,"cw":0},"hsv":{"h":21.29,"s":100.00,"v":35.00,"ct":4406}},"id":439}
2018.04.29 17:30:46.209 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 165 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":301,"g":56,"b":0,"ww":0,"cw":0},"hsv":{"h":21.29,"s":100.00,"v":35.00,"ct":4406}},"id":439}
2018.04.29 17:30:46.242 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:46.243 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:46.254 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:47.002 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:47.012 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:47.182 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:47.182 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:47.223 4: LED2: got config response
2018.04.29 17:30:47.224 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:47.310 4: LED2: got config response
2018.04.29 17:30:47.311 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
2018.04.29 17:30:47.375 3: LED2: got info response
2018.04.29 17:30:47.375 3: LED2: info response data {"deviceid":"1265235","current_rom":"1","git_version":"vbs33b","git_date":"2018-04-21","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":2,"uptime":2100,"heap_free":22064,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"MYSSID","dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1","mac":"5ccf7f134e53"}}
2018.04.29 17:30:47.406 4: LED2: got color response
2018.04.29 17:30:51.418 5: LED2: EspLedController_ProcessRead
2018.04.29 17:30:51.425 5: LED2: No PARTIAL buffer
2018.04.29 17:30:51.426 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":262,"g":95,"b":0,"ww":0,"cw":0},"hsv":{"h":36.25,"s":100.00,"v":35.00,"ct":4406}},"id":440}
2018.04.29 17:30:51.426 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":262,"g":95,"b":0,"ww":0,"cw":0},"hsv":{"h":36.25,"s":100.00,"v":35.00,"ct":4406}},"id":440}
2018.04.29 17:30:51.427 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 165 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":262,"g":95,"b":0,"ww":0,"cw":0},"hsv":{"h":36.25,"s":100.00,"v":35.00,"ct":4406}},"id":440}
2018.04.29 17:30:51.453 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 17:30:51.453 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 17:30:51.464 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.29 17:30:52.001 5: HttpUtils url=http://192.168.0.60:9090/
2018.04.29 17:30:52.009 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.29 17:30:52.179 5: LED2: EspLedController_ParseBoolResult
2018.04.29 17:30:52.180 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 17:30:52.230 4: LED2: got config response
2018.04.29 17:30:52.230 4: LED2: config response data {"network":{"connection":{"dhcp":false,"ip":"192.168.0.60","netmask":"255.255.255.0","gateway":"192.168.0.1"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW1265235"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":3,"startup_color":"last","hsv":{"model":2,"red":0.00,"yellow":0.00,"green":0.00,"cyan":0.00,"blue":0.00,"magenta":0.00},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/testing/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":5000,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":5000},"general":{"device_name":"LED2","pin_config":"13,12,14,5,4"}}
FHEM macht eine TCP-Verbindung auf Port 9090 auf und darüber reden sie dann JSON-RPC. FHEM schickt dann gelegentlich einen Ping.
Sieht aber in deinem Fall ganz seltsam aus. Normalerweise sagt FHEM sowas wie "Seit 60 Sekunden keinen Ping gesehen, Gerät muss weg sein". Bei dir passiert das ohne Meldung und schon nach 5 Sekunden... sehr strange...
Irgendwas ist bei dir speziell, denk ich. Kann es sein, dass du noch andere Sachen nebenbei laufen hast? In deinem Log sieht man zB irgendwas mit HTTP.
Zitat von: vbs am 29 April 2018, 19:44:21
FHEM macht eine TCP-Verbindung auf Port 9090 auf und darüber reden sie dann JSON-RPC. FHEM schickt dann gelegentlich einen Ping.
Sieht aber in deinem Fall ganz seltsam aus. Normalerweise sagt FHEM sowas wie "Seit 60 Sekunden keinen Ping gesehen, Gerät muss weg sein". Bei dir passiert das ohne Meldung und schon nach 5 Sekunden... sehr strange...
Irgendwas ist bei dir speziell, denk ich. Kann es sein, dass du noch andere Sachen nebenbei laufen hast? In deinem Log sieht man zB irgendwas mit HTTP.
"irgendwas mit HTTP" meinst du das? - HttpUtils url=http://192.168.0.60:9090/ ... kann es sein, dass es von verbose5 kommt da hier Informationen vom Controller abgerufen werden? HttpUtils nonblocking ist ein paarmal im Modul.
Fhem hat etliche Devices. Habe auch freezemon laufen ... Ansonsten läuft auf dem Raspberry einiges, NGINX Reverse Proxy, IPTABLES, KODI, SPOTIFY-Connect, MySQL und halt FHEM. Aber Systemlast ist gering, läuft nicht am Anschlag.
Der LED-Controller wird nur mit dem ... set hue +359 120 lrq ... gestartet und läuft dann ohne weitere Aktion von Fhem.
Ich habe jetzt verbose 0 gesetzt. Ohne Firewall waren es jetzt nur ein paar Meldungen. Solang der Controller läuft ist es erstmal egal. Hab auch wenig Zeit dem näher nachzugehen.
Hi vbs,
wird's lästig wenn ich schon wieder was frage oder melde?
Wie du mitbekommen hast, habe ich meinen Controller in Loop laufen. Farbkreis in Schleife.
Mir ist nun aufgefallen, dass die Led kurz flackert wenn es den roten Teil durchläuft. Habe das analysiert ... wenn hue den Wert 359.88 annimmt wird in RGB gerechnet der Rote Kanal auf 682, und blau auf 341 gesetzt. Richtig wäre Rot 1022 und Blau Wert 0. Ich denke da ist ein Feldüberlauf o. ä. Ob es in der "alten" Firmware auch so ist kann ich nicht sagen, mir ist es nicht aufgefallen.
Ist nicht wichtig, wenn du willst kannst es in einer späteren Firmware mal prüfen.
Kann ich mit .... set <device> hue 359.88 ... nachgestellen. DAnn ist die Farbe magenta statt knallrot. Wahrscheinlich auch bei anderen Controllern. Ich habe aktuell nur einen mit RGB laufen.
Ich meine das hier ... :{"r": ----> 682 <----- ,"g":0,"b": -----> 341 <----- ,"ww":0,"cw":0},"
Hier siehst du den Farbübergang von Hue 359.65 --> 359.88 --> 0.00
{"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1023,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":100.00,"v":100.00,"ct":4406}},"id":247}
{"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.88,"s":100.00,"v":100.00,"ct":4406}},"id":246}
{"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1021,"g":0,"b":2,"ww":0,"cw":0},"hsv":{"h":359.65,"s":100.00,"v":100.00,"ct":4406}},"id":245}
Mehl Log auf Level 5 und FArbmeldungen 500ms ...
2018.04.29 22:09:47.767 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 22:09:47.767 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 22:09:47.730 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 168 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.94,"s":100.00,"v":100.00,"ct":4406}},"id":248}
2018.04.29 22:09:47.729 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.94,"s":100.00,"v":100.00,"ct":4406}},"id":248}
2018.04.29 22:09:47.729 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.94,"s":100.00,"v":100.00,"ct":4406}},"id":248}
2018.04.29 22:09:47.728 5: LED2: No PARTIAL buffer
2018.04.29 22:09:47.728 5: LED2: EspLedController_ProcessRead
2018.04.29 22:09:47.021 4: LED2: EspLedController_CheckConnection: Connection still alive. Last data received 17.5145478248596 s ago
2018.04.29 22:09:47.020 5: LED2: EspLedController_ParseBoolResult success
2018.04.29 22:09:47.019 5: LED2: EspLedController_ParseBoolResult
2018.04.29 22:09:46.978 5: LED2: set HSV color request: {"hsv":{"h":"359.88"},"d":"1","t":"2000","cmd":"fade","q":"single"}
2018.04.29 22:09:46.978 5: LED2: encoded json data: {"hsv":{"h":"359.88"},"d":"1","t":"2000","cmd":"fade","q":"single"}
2018.04.29 22:09:46.978 5: LED2: called SetHSVColor
2018.04.29 22:09:46.977 5: LED2 setting HUE to 359.88
2018.04.29 22:09:38.224 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 22:09:38.223 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 22:09:38.186 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 165 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1023,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":100.00,"v":100.00,"ct":4406}},"id":247}
2018.04.29 22:09:38.185 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1023,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":100.00,"v":100.00,"ct":4406}},"id":247}
2018.04.29 22:09:38.185 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1023,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":100.00,"v":100.00,"ct":4406}},"id":247}
2018.04.29 22:09:38.185 5: LED2: No PARTIAL buffer
2018.04.29 22:09:38.184 5: LED2: EspLedController_ProcessRead
2018.04.29 22:09:37.723 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 22:09:37.723 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 22:09:37.687 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 168 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.88,"s":100.00,"v":100.00,"ct":4406}},"id":246}
2018.04.29 22:09:37.685 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.88,"s":100.00,"v":100.00,"ct":4406}},"id":246}
2018.04.29 22:09:37.685 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":682,"g":0,"b":341,"ww":0,"cw":0},"hsv":{"h":359.88,"s":100.00,"v":100.00,"ct":4406}},"id":246}
2018.04.29 22:09:37.685 5: LED2: No PARTIAL buffer
2018.04.29 22:09:37.684 5: LED2: EspLedController_ProcessRead
2018.04.29 22:09:37.205 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 22:09:37.205 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 22:09:37.185 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 167 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1021,"g":0,"b":2,"ww":0,"cw":0},"hsv":{"h":359.65,"s":100.00,"v":100.00,"ct":4406}},"id":245}
2018.04.29 22:09:37.184 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1021,"g":0,"b":2,"ww":0,"cw":0},"hsv":{"h":359.65,"s":100.00,"v":100.00,"ct":4406}},"id":245}
2018.04.29 22:09:37.184 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1021,"g":0,"b":2,"ww":0,"cw":0},"hsv":{"h":359.65,"s":100.00,"v":100.00,"ct":4406}},"id":245}
2018.04.29 22:09:37.184 5: LED2: No PARTIAL buffer
2018.04.29 22:09:37.183 5: LED2: EspLedController_ProcessRead
2018.04.29 22:09:37.020 4: LED2: EspLedController_CheckConnection: Connection still alive. Last data received 7.51322484016418 s ago
2018.04.29 22:09:36.703 5: LED2: EspLedController_ProcessRead: PARTIAL:
2018.04.29 22:09:36.703 5: LED2: EspLedController_ProcessRead: Tail:
2018.04.29 22:09:36.684 5: LED2: EspLedController_ProcessRead: Decoding JSON message. Length: 167 Content: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1019,"g":0,"b":4,"ww":0,"cw":0},"hsv":{"h":359.41,"s":100.00,"v":100.00,"ct":4406}},"id":244}
2018.04.29 22:09:36.684 5: LED2: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1019,"g":0,"b":4,"ww":0,"cw":0},"hsv":{"h":359.41,"s":100.00,"v":100.00,"ct":4406}},"id":244}
2018.04.29 22:09:36.683 5: LED2: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"color_event","params":{"mode":"hsv","raw":{"r":1019,"g":0,"b":4,"ww":0,"cw":0},"hsv":{"h":359.41,"s":100.00,"v":100.00,"ct":4406}},"id":244}
Hm, interessanter Fund, würde ich gerne verstehen.
Ich kann das leider aber so erstmal nicht nachstellen.
set <device> hue 359.88
Gibt bei mir erstmal knallrot.
Auch bei nem Fade konnte ich weder einen Farbsprung sehen noch Unregelmäßigkeiten bei den RGB-Werten.
Hast du noch Tips wie ich das nachstellen kann? Kannst ja mal ein list vom Device posten, vielleicht kann man da noch was sehen.
Zitat von: vbs am 30 April 2018, 00:59:07
Hm, interessanter Fund, würde ich gerne verstehen.
Ich kann das leider aber so erstmal nicht nachstellen.
set <device> hue 359.88
Gibt bei mir erstmal knallrot.
Auch bei nem Fade konnte ich weder einen Farbsprung sehen noch Unregelmäßigkeiten bei den RGB-Werten.
Hast du noch Tips wie ich das nachstellen kann? Kannst ja mal ein list vom Device posten, vielleicht kann man da noch was sehen.
Ich habe noch irgendwo einen Ersatzcontroller, wenn ich Zeit finde werde ich den mal flashen und vergleichen. Vielleicht flashe ich den aktuellen auch mit Kabel incl. ERASE Flash oder wie der Befehlt heißt.
Ich starte .... set hue +359 120 ... und da fiel es mir wieder auf. Habe dann rumgetestet und Log angesehen. Im Anschluss konnte ich es mit ... set hue 359.88 ... permanent reproduzieren. Auch mit .... set hue 358 ... anschließend ... set hue +3 120 ....
Mit Log kann ich das nicht belegen, aber ich glaube dass nicht jeder Durchlauf flackert.
Wenn es bei dir nicht nachstellbar ist, ist es nicht Wert zu viel Zeit zu investieren.
Hier das List ...
Internals:
DEF 192.168.0.60
DeviceName 192.168.0.60:9090
FD 17
IP 192.168.0.60
LAST_RECV 1525067236.49574
NAME LED2
NR 712
NTFY_ORDER 50-LED2
PARTIAL
PORT 9090
STATE opened
TYPE EspLedController
OLDREADINGS:
READINGS:
2018-04-30 07:43:45 colorMode hsv
2018-04-30 07:46:08 config-color-brightness-blue 100
2018-04-30 07:46:08 config-color-brightness-cw 100
2018-04-30 07:46:08 config-color-brightness-green 100
2018-04-30 07:46:08 config-color-brightness-red 100
2018-04-30 07:46:08 config-color-brightness-ww 100
2018-04-30 07:46:08 config-color-colortemp-cw 6000
2018-04-30 07:46:08 config-color-colortemp-ww 2700
2018-04-30 07:46:08 config-color-hsv-blue 0
2018-04-30 07:46:08 config-color-hsv-cyan 0
2018-04-30 07:46:08 config-color-hsv-green 0
2018-04-30 07:46:08 config-color-hsv-magenta 0
2018-04-30 07:46:08 config-color-hsv-model 0
2018-04-30 07:46:08 config-color-hsv-red 0
2018-04-30 07:46:08 config-color-hsv-yellow 0
2018-04-30 07:46:08 config-color-outputmode 0
2018-04-30 07:46:08 config-color-startup_color last
2018-04-30 07:46:08 config-events-color_interval_ms 500
2018-04-30 07:46:08 config-events-color_mininterval_ms 500
2018-04-30 07:46:08 config-events-server_enabled 1
2018-04-30 07:46:08 config-events-transfin_interval_ms 1000
2018-04-30 07:46:08 config-general-device_name LED2
2018-04-30 07:46:08 config-general-pin_config 13,12,14,5,4
2018-04-30 07:46:08 config-network-ap-password rgbwwctrl
2018-04-30 07:46:08 config-network-ap-secured 0
2018-04-30 07:46:08 config-network-ap-ssid RGBWW1265235
2018-04-30 07:46:08 config-network-connection-dhcp 0
2018-04-30 07:46:08 config-network-connection-gateway 192.168.0.1
2018-04-30 07:46:08 config-network-connection-ip 192.168.0.60
2018-04-30 07:46:08 config-network-connection-netmask 255.255.255.0
2018-04-30 07:46:08 config-network-mqtt-enabled 0
2018-04-30 07:46:08 config-network-mqtt-password
2018-04-30 07:46:08 config-network-mqtt-port 1883
2018-04-30 07:46:08 config-network-mqtt-server mqtt.local
2018-04-30 07:46:08 config-network-mqtt-topic_base home/
2018-04-30 07:46:08 config-network-mqtt-username
2018-04-30 07:46:08 config-ota-url http://rgbww.dronezone.de/release/version.json
2018-04-30 07:46:08 config-security-api_secured 0
2018-04-30 07:46:08 config-sync-clock_master_enabled 0
2018-04-30 07:46:08 config-sync-clock_master_interval 30
2018-04-30 07:46:08 config-sync-clock_slave_enabled 0
2018-04-30 07:46:08 config-sync-clock_slave_topic home/led1/clock
2018-04-30 07:46:08 config-sync-cmd_master_enabled 0
2018-04-30 07:46:08 config-sync-cmd_slave_enabled 0
2018-04-30 07:46:08 config-sync-cmd_slave_topic home/led1/command
2018-04-30 07:46:08 config-sync-color_master_enabled 0
2018-04-30 07:46:08 config-sync-color_master_interval_ms 0
2018-04-30 07:46:08 config-sync-color_slave_enabled 0
2018-04-30 07:46:08 config-sync-color_slave_topic home/led1/color
2018-04-30 07:46:04 ct 4406
2018-04-30 07:46:04 hsv 245.98,100,35
2018-04-30 07:46:04 hue 245.98
2018-04-30 07:45:59 info-connection-dhcp 0
2018-04-30 07:45:59 info-connection-gateway 192.168.0.1
2018-04-30 07:45:59 info-connection-ip_address 192.168.0.60
2018-04-30 07:45:59 info-connection-mac 5ccf7f134e53
2018-04-30 07:45:59 info-connection-netmask 255.255.255.0
2018-04-30 07:45:59 info-connection-ssid MYSSID
2018-04-30 07:45:59 info-current_rom_slot 1
2018-04-30 07:45:59 info-deviceid 1265235
2018-04-30 07:45:59 info-event_num_clients 1
2018-04-30 07:45:59 info-firmware vbs33b
2018-04-30 07:45:59 info-sming_version 3.5.1
2018-04-30 07:45:59 info-uptime 540
2018-04-30 07:45:59 info-webapp_version 0.3.3-shojo7
2018-04-30 07:46:04 pct 35
2018-04-30 07:46:04 raw_blue 358
2018-04-30 07:46:04 raw_cw 0
2018-04-30 07:46:04 raw_green 0
2018-04-30 07:46:04 raw_red 35
2018-04-30 07:46:04 raw_ww 0
2018-04-30 07:46:04 rgb 070059
2018-04-30 07:46:04 sat 100
2018-04-30 07:36:38 state opened
2018-04-30 07:46:04 stateLight on
2018-04-29 21:25:07 tranisitionFinished Rainbow,finished
2018-04-30 07:46:04 val 35
helper:
isBusy 0
oldVal 98.92
bm:
EspLedController_Attr:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 29.04. 22:12:07
max 0.000875949859619141
tot 0.0016777515411377
mAr:
del
LED2
verbose
EspLedController_Get:
cnt 57
dmx -1000
dtot 0
dtotcnt 0
mTS 30.04. 07:46:02
max 0.00248098373413086
tot 0.0209565162658691
mAr:
HASH(0x3772e30)
LED2
update
EspLedController_Notify:
cnt 9958
dmx -1000
dtot 0
dtotcnt 0
mTS 29.04. 21:58:04
max 0.000527143478393555
tot 0.406681776046753
mAr:
HASH(0x3772e30)
HASH(0x3772e30)
EspLedController_Read:
cnt 4496
dmx -1000
dtot 0
dtotcnt 0
mTS 29.04. 21:57:59
max 1.00497102737427
tot 146.238315343857
mAr:
HASH(0x3772e30)
EspLedController_Ready:
cnt 56824
dmx -1000
dtot 0
dtotcnt 0
mTS 30.04. 02:04:47
max 0.0115718841552734
tot 21.7458181381226
mAr:
HASH(0x3772e30)
EspLedController_Set:
cnt 7151
dmx -1000
dtot 0
dtotcnt 0
mTS 30.04. 07:40:31
max 0.00461196899414062
tot 4.93971586227417
mAr:
HASH(0x3772e30)
LED2
hue
359.88
cmdQueue:
lastCall:
NAME
addr http://192.168.0.60:80
auth 0
buf
code 200
compress 1
conn
displayurl http://192.168.0.60/config?
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host 192.168.0.60
httpheader HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 1145
Connection: keep-alive
Server: HttpServer/Sming
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
loglevel 4
method GET
path /config?
protocol http
redirects 0
timeout 30
url http://192.168.0.60/config?
hash:
sslargs:
Attributes:
DbLogExclude .*
defaultRamp 2000
devStateIcon on:ios-on-blue:off off:ios-off:on
group LED
room Wohnzimmer
verbose 5
webCmd hsv:hsv ff0000:rgb 00ff00:rgb 0000ff:rgb ffffff:rgb 000000
widgetOverride hsv:colorpicker,HSV,hue,0,1,360,sat,0,1,100,val,0,1,100
Ich glaube schon, dass du da etwas gefunden hast. Ich hab jetzt nochmal weitere Einstellungen von dir übernommen (ct, pct, colormode...), aber verhält sich bei mir (leider) weiter unauffällig. :(
Muss ja wohl irgendwie mit den Umrechnungen in der Firmware zu tun haben.
Verstehe halt nicht, unter welchen Umständen das passiert. Vielleicht hat ja von euch noch jemand Ideen, dann sehe ich es mir gerne an.
Konnte man nicht in der Firmware den Berechnungsmodus für die Farbe auswählen? Vielleicht habt ihr da ja verschiedene eingestellt - an gerade nicht nachsehen, aber ich meine, bei einer Einstellung hatte es unter gewissen Umständen geflackert...
Gesendet von meinem SM-G935F mit Tapatalk
Danke guter Hinweis!
Also ich hatte es halt versucht, mit der Einstellung zu reproduzieren, wie in dem Listing von kadettilac89 zu sehen: "config-color-hsv-model" auf 0, also "Normal". Ich kann es jedoch jetzt reproduzieren, in dem ich das Model auf "Rainbow" stelle. "set wz_lightLedTv hue 359.88" erzeugt dann bei mir ein Magenta.
Jetzt frage ich mich dementsprehcend, ob das Listing von kadettilac89 evtl. nicht dem Zustand entspricht, bei dem das Problem wirklich aufgetreten ist? kadettilac89 kannst du das bitte nochmal verifizieren? Also mit Model "Normal" und "Spektral" passiert es bei mir nicht, mit "Rainbow" aber schon.
Abgesehen davon: ich habe diese Modi ehrlich gesagt, noch nie verstanden. Mir ist nicht klar, was die machen bzw. wozu man das braucht bzw. wann man das umstellt. Mir fällt es dementsprechend schwer, den Code zu maintainen. Ich könnte momentan noch nicht mal mit Sicherheit sage, ob es sich überhaupt um einen Bug handelt, dass ein Hue von "359.88" im Modus "Rainbow" zu einem Magenta führt :o
Ich kann da gucken ob ich da einfach einen offensichtlichen Bug in den Kalkulationen bei "Rainbow" sehe, aber ich bin auch etwas versucht, die Sachen einfach rauszuschmeißen.
Wäre etwas schade, weil die sicherlich einen Sinn habe, aber ich bin einfach zu doof offenbar. :(
Ich hab auch Google bemüht, aber konnte da auch nix Erhellendes finden. Also die Bitte an euch: wer benutzt einen anderen Modus als "Normal" oder wer kann mir in einfachen Worten erklären, wozu die gut sind? :) Freue mich auch über Links zu Thema, wo ich nachlesen kann.
EDIT:
Hab hier doch was gefunden zum Thema, ist ein Link im Code:
https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors#color-map-rainbow-vs-spectrum
Richtig, ich habe rainbow eingestellt. Hatte nachts noch etwas getestet und nochmal den Controller zurückgesetzt. Da hab ich dann HSV-Model nicht mehr geändert. Dadurch ist das Listing nicht mehr korrekt.
Es gab mal ein Problem, dass die weißen Kanälge geflackert haben wenn HSV auf normal waren. Da wurde empfohlen auf Rainbow zu setzen. Ich hatte damals auch Problem und ich glaube mit Rainbow war es dann auch weg. Post s. u.
https://forum.fhem.de/index.php/topic,48918.msg500288.html#msg500288
Ich habe meine LEDs umgebaut, und auch in Fhem umgestellt. Habe mit meinen Farb-Reglern jetzt etwas rumgespielt und konnte kein Flackern auf CW / WW nachstellen. Damals gab es keine Ramp-Einstellung. Dadurch ist das auch nicht mehr direkt vergleichbar.
Wahrscheinlich hat keiner was dagegen wenn der HSV-Teil auf ein Model reduziert wird. Ich zumindest hätte kein Problem damit.
Zitat von: vbs am 29 April 2018, 19:44:21
FHEM macht eine TCP-Verbindung auf Port 9090 auf und darüber reden sie dann JSON-RPC. FHEM schickt dann gelegentlich einen Ping.
Sieht aber in deinem Fall ganz seltsam aus. Normalerweise sagt FHEM sowas wie "Seit 60 Sekunden keinen Ping gesehen, Gerät muss weg sein". Bei dir passiert das ohne Meldung und schon nach 5 Sekunden... sehr strange...
Irgendwas ist bei dir speziell, denk ich. Kann es sein, dass du noch andere Sachen nebenbei laufen hast? In deinem Log sieht man zB irgendwas mit HTTP.
Ich habe gestern durch das Firmwaretesten den Controller neu geflasht, Fhem auch mit den letzten Updates versehen, und auf OS liefen heute Nacht auch ein paar Updates rein.
--> Keine Meldungen mehr im Log zu sehen. Auch mit aktivierter Firewall nicht. Port 9090 war vorher schon offen.
Was es letztendlich war ... keine Ahnung. Fhem hatte ich auch vorher durchgestartet als ich mit den Queue-Flag rumgetestet hatte. Zum Fehler suchen ungünstig, aber das updaten läuft automatisch ... Updates hatte ich nicht auf dem Radar.
Erstmal erledigt.
Ich habe 2 im täglichen Einsatz und diese fallen alle paar Tage aus. Weboberfläche nicht mehr erreichbar. Wie lese ich die Logs aus?
Gesendet von meinem SM-G930F mit Tapatalk
Es gibt kein Logfile. Über die serielle Schnittstelle macht der Controller ein paar Ausgaben, aber die sind auch sehr spärlich. Kannst trotzdem mal schauen, was dort zu sehen ist im Fehlerfall.
Hab nun auf verbose 5 gestellt. Es schien (noch mit verbose 2 ) als ob meine beiden gleichzeitig ausgefallen sind lt. Fhem Log. Über serielle geht es nicht die sind fest verbaut um die an den pc zu bekommen muss der Strom weg und danach gehen die ja wieder. Ggf WLAN Problem? Aber sitzen beide 5m vom ap weg.
Gesendet von meinem SM-G930F mit Tapatalk
Hi,
Du könntest eine ESP8266 (z.B. Wemos D1 Mini oder NodeMCU) mit ESPLink Firmware nehmen und damit die serielle an Ort und Stelle anzapfen!?
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Ok das wusste ich nicht. Hast du einen Link mit Details? Brauche ich noch was außer einem d1? Danke für die info
Gesendet von meinem SM-G930F mit Tapatalk
Hi,
Google nach HowTo ESP-Link !?
https://jeelabs.org/article/1618a/
Aber im Kern: ESP-Link auf den D1 und den Rx/TX gekreuzt und Power und Gnd verbinden.
Danach ESP ins eigene WLAN hängen
Danach Telnet auf ESP-IP:23 und voila.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
hab mir das ganze mal angesehen aber leider bekomme ich keine Anzeige.
Mit einem anderen Wemos D1 klappt es aber beim RGBWW Controller bekomme ich aber keine Ausgabe.
Hi,
Was bedeutet keine Anzeige?
Keine Ausgabe auf dem Debug Serial vom RGBWW? TX/RX mal getauscht?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
ja genau ich habe alles exakt gleich angeschlossen. Einmal der Controller und einmal einen neuen wemos. Beim Wemos bekomme ich sofort die Daten ausgegeben beim Controller nicht.
RX TX schon getauscht. Auch habe ich gerade einen 2. Controller probiert leider das gleiche. Keinerlei Anzeige.
Kann es gleich nochmal mit IDE am PC über USB probieren. Aber es funktioniert ja.. zumindest mit einem anderen Wemos.
Hi,
Und hast Du im ESP-Link die richtige Baudrate für den Sketch des RGBWW eingetragen? Und bevor Du fragst: Nein ich kenne die nicht auswendig, also entweder im Source nachsehen, alle durchprobieren oder auf ein anderes Forumsmitglied hoffen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi,
Oder doch ich ;-)
Serial.begin(SERIAL_BAUD_RATE); // 115200 by default
Serial.systemDebugOutput(false); // don`t show system debug messages
Bzw.
#define SERIAL_BAUD_RATE 115200
aus
https://github.com/patrickjahns/esp_rgbww_firmware/blob/master/app/application.cpp
bzw. aus
https://github.com/patrickjahns/esp_rgbww_firmware/blob/master/include/user_config.h
Sieht aber schlecht aus mit Debug Infos w/ zweiter Zeile ;-(
Bei OTA sollte aber eine Menge kommen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Also ist es einfach ausgestellt?
Gesendet von meinem SM-G930F mit Tapatalk
Hi,
Mach mal ota mit einem falschen File und Du wirst etwas sehen schätze ich.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Im Fehlerfall sollte im Falle eines Crashes ein Memory-Dump zu sehen sein.
Hi,
hätte auch eine Frage, hoffe ich habe es nicht überlesen.
Ist es möglich in der Firmware auch die defaultRamp Zeit zu beeinflussen?
Also dass eine Änderung im WebInterface des RGBWW auch langsamer / schneller ausgeführt wird?
Gruß,
Stefan
Wirf doch bitte mal einen Blick in die commandref, ist dort beschrieben.
Hi,
klar das hatte ich gemacht :-)
Den defaultRamp kenne ich ja auch und hab ihn in FHEM gesetzt.
Das wirkt auch für die Steuerung von FHEM aus.
Ich meine aber den defaultRamp in der WEB app. Also in der Firmware, nicht in FEHM.
Zumindest ist es bei mir so dass aus FHEM die befehle nun ein fefaultRamp von 5 sekunden haben.
In der WEB app geht es aber viel schneller wenn ich etwas verstelle.
Gruß,
Stefan
Achso sorry, jetzt hab ichs verstanden. ::)
Gibt es aber mWn nicht. Soweit ich mich erinnere, wird eine Ramp mit 0.0 gemacht, wenn in dem Befehl kein Wert für Ramp explizit mitgeschickt wird. Jetzt weiß ich aber nicht genau, ob das WebIf etwas mitschickt. Ich vermute mal nein.
Also theoretisch könnte man den Default-Wert von "0.0" in der Firmware konfigurierbar machen. Vielleicht guck ich da mal rein bei Gelegenheit, aber kann nix versprechen momentan. Und dann dürfte das WebIf selbst keine Ramp mitschicken.
Ok,
das hatte ich mir schon gedacht.
Ist nicht dringend, nur ein nice to have.
Leider habe ich noch eine Frage. Ich habe Probleme die testing Firmware per OTA aufzuspielen.
Er lädt sie hoch resettet sich und hängt dann in einer bootloop. Nur durch CLR bekomme ich ihn wieder zu leben, aber ohne neue Firmware.
Also dachte ich mir ich flashe ihn neu.
Leider klappt das nicht.
Ich habe eine ftdi232. Habe RX und TX über kreuz angeschlossen.
Mit und ohne GND. Auch mit externer Stromquelle oder der vom FTDI.
Alles scheitert mit:
init finished
_COM: 6
ESP_ROM_BAUD : 115200
crystal : 0
test offset : 0 0x0
case ok
test offset : 8192 0x2000
case ok
test offset : 1048576 0x100000
case ok
test check all res: (True, [[u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\rboot.bin', 0], [u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\rom0.bin', 8192], [u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\spiff_rom.bin', 1048576]])
(True, [[u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\rboot.bin', 0], [u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\rom0.bin', 8192], [u'D:\\Benutzer\\Stefan\\Downloads\\ESP_RGBWW_Firmaware\\spiff_rom.bin', 1048576]])
size_speed : 0
mode : speed:
write bin : D:\Benutzer\Stefan\Downloads\ESP_RGBWW_Firmaware\_temp_by_dltool\rboot.bin_rep
test running : False
serial port opened
Connecting...
chip sync error.
com closed
Dann dachte ich machst du mal den seriellen Monitor vom Arduino Studio auf, aber dort bekomme ich nur Müll.
⸮⸮⸮⸮³.⸮⸮ "⸮r⸮"⸮۲⸮⸮⸮)⸮⸮⸮E?B⸮⸮⸮"⸮⸮aP⸮#⸮⸮+⸮⸮^⸮/T⸮⸮⸮/⸮⸮^2⸮aκS⸮C⸮⸮⸮⸮ ⸮⸮⸮⸮#d⸮⸮ 9 ⸮⸮E⸮⸮ڞB⸮
Habe am COM Port 115000 und in der Console eingestellt.
Habe auch mit allen möglichen anderen experimentiert.
Leider immer das selbe.
Und eine Frage was ist G0 auf der Platine neben Rx?
Kann mir jemand mal auf die Sprünge helfen? Ich verzweifle langsam :-(
Danke und Gruß,
Stefan
P.S.: Sehr seltsam OTA ging jetzt :-) Keine Ahnung warum.
Wäre nett wenn mir trotzdem noch jemand erklären könnte was ich beim Flashen per FTDI falsch mache.
Moin Stefan
Der G0 muss beim Spannung anlegen mit GND verbunden sein, um den ESP in den Flashmodus zu setzen. Wenn Du gebrueckt hast und Reset drueckst, geht es, glaube ich, auch. Dann die Bruecke entfernen und du kannst flashen.
Gruss Christoph
Zitat von: stefanru am 31 Mai 2018, 16:46:53
Wäre nett wenn mir trotzdem noch jemand erklären könnte was ich beim Flashen per FTDI falsch mache.
Sorry falls ich überlesen habe, aber wie flasht du denn?
Ich mach das so:
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 out/firmware/rboot.bin 0x01000 /home/vbs/Projects/esp-open-sdk/sdk/bin/blank.bin 0x02000 out/firmware/rom0.bin 0x100000 out/firmware/spiff_rom.bin
Ok, danke.
Wie gesagt es ging ja jetzt per OTA.
Ich hatte es wie in der Anleitung mit dem flash_download_tool_v0.9.6_150419.exe versucht.
Außerdem habe ich auch nochmal ESP8266Flasher.exe versucht mit dem ich normal meine Wemos flashe.
Seltsam ist auch das ich in der seriellen konsole vom Arduino studio nur murks bekommen habe, egal welche Baudrate.
Werde es das nächste mal mit dem esptool.py probieren.
Vielen Dank für die Tips.
Gruß,
Stefan
Da ich nicht weiss, wieviel Platz noch im Speicher ist, stelle ich die Idee einfach mal so vor:
Wäre es möglich, ein TV-Simulator (https://forum.fhem.de/index.php/topic,71424.0.html), also einen einfachen Zufallsgenerator zu implementieren? Ginge zwar auch über FHEM, aber der Traffic und Logging wäre nicht ohne.
Ist sicherlich möglich, finde ich aber recht speziell für eine Implementierung in FW. Würdest du nicht damit auskommen, entsprechende Queues zu definieren und die vom Controller ausführen zu lassen?
Zitat von: Per am 04 Juni 2018, 11:40:04
Da ich nicht weiss, wieviel Platz noch im Speicher ist, stelle ich die Idee einfach mal so vor:
Wäre es möglich, ein TV-Simulator (https://forum.fhem.de/index.php/topic,71424.0.html), also einen einfachen Zufallsgenerator zu implementieren? Ginge zwar auch über FHEM, aber der Traffic und Logging wäre nicht ohne.
Ich wäre auch interessiert an sowas. Optimal wäre es wenn man,
Queues als attr hinzugefügt werden könnten.
attr ledcontroller tvsimulation 2,4,5...
Und diese dann über set Befehle aktiviert werden könnten.
Gruss
Hi,
ich habe eine Frage.
Was kann der Grund sein das mein RGBWW ziemlich oft von allein rebooted.
Spannung habe ich geprüft und von 3.3 mal auf 3.36 gestellt.
Daran liegt es wohl auch dass ich kein OTA update durch bekommen hab. Sobald ich das versuche rebootet er auch so gut wie immer.
Hoffe jemand hat einen Tip für mich.
Gruß,
Stefan
Hi,
Also aus meiner Erfahrung sind immer wieder von alleine robootende ESPs auf
A) nicht stabile Stromversorgung
B) Software nicht richtig/vollständig geflasht
C) watchdog reset w/ Fehler im Sketch
zurückzuführen.
Ich würde in der Reihenfolge auch testen.
A)Vielleicht ist Dein DC/DC Wandler nicht stabil? War das vor dem ersten Flashvetduch auch schon so? Entweder mal mit anderer Stromquelle testen oder Stützkondensator nahe am Modul anbringen?
B) Ist nach den abrechenden Flash Vorgängen wahrscheinlich. Daher würde ich den ESP per Kabel vollständig löschen und neu flashen.
C) schließe ich aus, da der Sketch (welcher ist drauf) bei uns anderen ja läuft :-)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: RaspiLED am 07 Juni 2018, 06:19:41
A) nicht stabile Stromversorgung
Da stimme ich zu, das ist sehr oft die Ursache bei abstürzende ESP´s.
Die sind da sehr empfindlich!
Daher setzte ich eigentlich immer einen Stützkondensator ein um den Problem vorzubeugen.
ich hatte ja gerade das Problem, dass eine ganze Charge partout nicht stabil arbeiten wollte. Beste Erfahrungen habe ich mit den ESP12E/F mit "Ai" Logo gemacht. Es gibt offenbar durchaus signifikante Unterschiede.
pj
Hi,
ich habe es auch im Betrieb gemessen. Spannung sah gut aus.
Ich habe das Board von VBS gekauft.
Gehe davon aus dass es bei ihm keine Probleme gab.
Ist der Kondensator auf dem Board kein Stützkondensator?
Habe gestern nochmal geflashed.
Werde heute abend nochmal testen.
Gibt es eine Möglichkeit den ESP remote zu beobachten?
Bei ESP Easy gibt es z.B. mit dem Arduino studio die Möglichkeit über http an die seriellen ausgaben zu kommen.
Würde ihn gern im eingebauten zustand beobachten.
Gruß,
Stefan
die RGBWW Firmware hat keine Funktion, um über das Netz zu loggen / zu debuggen.
Du kannst natürlich einen USB UART Converter dranhängen, die Debug - Daten kommen da raus.
Wenn Du aber das Problem hast, dass der konstant re-bootet, dann wirst Du auch nur genau das dort sehen.
Ich weiß nicht, welches Board Du hast und welche Version (bzw welcher Hersteller) des ESP12 darauf ist.
wie schon gesagt, ich hatte mit einer Charge Probleme.
Gut funktioniert hat immer
Ai (https://ae01.alicdn.com/kf/HTB14KqKbHYI8KJjy0Faq6zAiVXa1/10Pcs-ESP8266-ESP-12F-Serial-WIFI-Model-ESP-12E-Upgrade-Remote-Wireless-Module-ESP12F-ESP12-Authenticity.jpg_220x220.jpg)
auch mit diesen ist mir kein systemisches Problem bekannt: https://ae01.alicdn.com/kf/HTB1rgEVl98YBeNkSnb4q6yevFXaK/I74-5PCS-Esp8266-WiFi-series-of-model-ESP-12-ESP-12F-esp12F-esp12-authenticity-guaranteed.jpg_640x640.jpg
diese allerdings haben bei mir in manchen Applikationen zu 100% das Reboot-Problem: https://ae01.alicdn.com/kf/HTB1p.TjlBTH8KJjy0Fiq6ARsXXa5/1PCS-Esp8266-WiFi-series-of-model-ESP-12-ESP-12F-esp12F-esp12-authenticity-guaranteed-esp-12f.jpg_640x640.jpg
Grüße
pj
Zitat von: stefanru am 07 Juni 2018, 12:46:13
Ich habe das Board von VBS gekauft.
Gehe davon aus dass es bei ihm keine Probleme gab.
Öhm bist du sicher? Bin mir eigentlich gerade gar nicht bewusst, dass ich eins verkauft hätte? Evtl. doch von jemand anderem?
Stimme aber generell zu, dass es dann ja wohl schon mal funktioniert haben muss (oder eben genau deswegen verkauft wurde :-X)
Oh,
hab gerade geschaut habe sie von Marcus. gekauft aus der Verkaufsecke hier im Forum https://forum.fhem.de/index.php/topic,85500.0.html.
Soweit ich weiß ist es ein ESP12E. Ich schaue heute Abend mal nach dem AI Zeichen und poste mal ein Bild.
Vielen Dank schon mal.
Gruß,
Stefan
Hast du mal ein Flash erase gemacht und neu geflasht?
Poste mal deine Settings wie Du geflasht hast. Was ich festgestellt habe bei manchen F Modulen, ist das DOUT als flashmode verwendet werden sollte. Reboots sollten eigentlich nicht sein, wenn das Ding von mir war, hat es einwandfrei funktioniert.
Also mal Flasherase machen und VBS Firmware mit DOUT flashen und testen.
Gruß
Markus
Ok vielen Dank, für die Hilfe.
War auf keinen Fall ein Vorwurf.
Ich werde es versuchen.
Das letzte mal hatte ich schon Probleme den ESP über meinen FTDI zu flashen.
Ich berichte sobald ich es ausprobiert habe.
Gruß und Danke,
Stefan
also wenn es einer von denen auf dem Foto ist: das sind,optisch, genau die ESP12en, mit denen ich auch Probleme hatte.
Ich habe den Eindruck, dass die intern einen erstaunlichen Spannungsverlust haben, wenn ich ne ESPEasy Software mit VCC Feature darauf installiert habe, dann war die chip-eigene Messung der Versorgungsspannung immer signifikant (0,2V oder so) geringer als das, was außen anlag.
Das kenne ich von den anderen beiden "Brands" so nicht. Ich habe aber ehrlich gesagt keine Ahnung, ob das tatsächlich ein zusammenhang ist. Ich müsste mal welche aufmachen.
Aktuell vermeide ich aber einfach welche zu kaufen, die nur dieses kleine "wifi" Marking haben.
[edit] die Controller stammen auch nicht aus der Sammelbestellung des vergangenen Jahres, die hatte schwarzen Lötstopplack.
pj
Hier noch ein Photo.
Ob ich es vor dem Urlaub schaffe ihn nochmal per Tool neu zu flashen weiß ich nicht.
Gebe aber bescheid sobald ich mich nochmal dran mache und eventuell etwas herausfinde.
Dank und viele Grüße,
Stefan
Hier nochmal was ich mal ergoogelt hatte bzgl. dieses DOUT-Flashens:
https://forum.fhem.de/index.php/topic,70738.msg792663.html#msg792663
Zitat von: stefanru am 08 Juni 2018, 12:49:04
Hier noch ein Photo.
Ob ich es vor dem Urlaub schaffe ihn nochmal per Tool neu zu flashen weiß ich nicht.
Gebe aber bescheid sobald ich mich nochmal dran mache und eventuell etwas herausfinde.
Dank und viele Grüße,
Stefan
Mit den Controller mit diesem Logo hatte ich keine übermäßigen Probleme. Also will sagen: keine, die mir aufgefallen wäre.
pj
Hi,
hab mich nun doch nochmal ans Flaschen gemacht.
Was kann es bedeuten wenn das Flashen immer abbricht bei verschiedenen Prozent Zahlen, mit Error:Write flash timeout?
Meist im 0x02000, manchmal schaffe ich es auch bis 0x100000 aber spätestens dann.
Habe DOUT und DIO versucht, mit den verschiedensten Geschwindigkeiten.
Auch mit externer Spannung und mit der Spannung vom USB. Leider kein Unterscheid.
Habe nun mal die teile einzeln geflashed.
0x00000 geht
0x02000 geht
0x100000 geht nicht, da komme ich nicht über ein paar %
Endet immer sehr schnell mit:
Note:Serial port connected.
Note:Begin find ESP8266.
Note:ESP8266 ACK success.
Note:ESP8266 ACK success.
Note:Set base address success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Note:Program flash success.
Error:Write flash timeout.
Habe es nun noch mehrmals versucht. Es ist eindeutig immer das selbe. Beim 0x100000 geht er auf die Bretter.
Heißt das der Flash ist defekt?
Habs nochmal mit esptool versucht, leider auch mit Fehler:
D:\Benutzer\Stefan\Downloads\ESPEasy_mega-20180606>esptool.exe -vv -cd nodemcu -cp COM6 -ca 0x100000 -cf D:\Benutzer\Stefan\Downloads\ESP_RGBWW_Firmaware\spiff_rom.bin
esptool v0.4.12 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
setting board to nodemcu
setting port from to COM6
setting address from 0x00000000 to 0x00100000
espcomm_upload_file
espcomm_upload_mem
setting serial port timeouts to 1000 ms
opening bootloader
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
Uploading 786432 bytes from D:\Benutzer\Stefan\Downloads\ESP_RGBWW_Firmaware\spiff_rom.bin to flash at 0x00100000
erasing flash
size: 0c0000 address: 100000
first_sector_index: 256
total_sector_count: 192
head_sector_count: 16
adjusted_sector_count: 176
erase_size: 0b0000
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
setting serial port timeouts to 15000 ms
setting serial port timeouts to 1000 ms
espcomm_send_command: receiving 2 bytes of data
writing flash
................................................................................ [ 10% ]
read 0, requested 1
warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
warning: espcomm_send_command: wrong direction/command: 0x01 0x03, expected 0x01 0x04
closing bootloader
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
error: espcomm_upload_mem failed
Hat jemand noch eine Idee?
Gruß,
Stefan
Bist du dir sicher das dein ftdi adapter in ordung ist?
Und hast du vorher mal ein flasherase gemacht?
Hi Markus,
eigentlich schon. Habe damit schon mehrere STM's geflashed.
Seltsam ist ich bekomme es nun mit Linux und esptool.py geflashed.
esptool.py --port /dev/ttyUSB5 --baud 115200 write_flash --flash_size=detect 0x100000 ./spiff_rom.bin --verify
esptool.py v2.0.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 786432 bytes to 218606...
Wrote 786432 bytes (218606 compressed) at 0x00100000 in 20.0 seconds (effective 315.2 kbit/s)...
Hash of data verified.
Leaving...
Verifying just-written flash...
(This option is deprecated, flash contents are now always read back after flashing.)
Verifying 0xc0000 (786432) bytes @ 0x00100000 in flash against ./spiff_rom.bin...
-- verify OK (digest matched)
Hard resetting...
Nur danach macht er kein Netz auf.
Mache ich da etwas verkehrt? Ich flashe mit:
esptool.py --port /dev/ttyUSB5 --baud 115200 write_flash --flash_size=detect 0x00000 ./rboot.bin --verify
esptool.py --port /dev/ttyUSB5 --baud 115200 write_flash --flash_size=detect 0x02000 ./rom0.bin --verify
esptool.py --port /dev/ttyUSB5 --baud 115200 write_flash --flash_size=detect 0x100000 ./spiff_rom.bin --verify
Zwichen den einzelnen flashes muss ich immer RST drücken. Sonst verbindet er sich fürs nächste nicht.
Gruß,
Stefan
Auweia....
Aber setz mal den flashmode Schalter in deine command lines. Das geht aber aber in einer command line und nicht für jeden Teil extra. Mach mal Flash Mode dout..
Hab jetzt nicht die ganze Befehlszeile da.
Aber was verwendest du denn für ein OS bei dem es immer abbricht? Eventuell Virenscanner oder so ein Mist?
Hi, verwende Windows.
Da brach es immer ab.
Mit esptool.py auf dem Raspberry geht es nun.
Netzwerk wird auch aufgemacht aber er rebootet wieder ständig.
Werde mal versuchen mit DOUT zu flashen.
Ok benutze nun:
esptool.py --port /dev/ttyUSB5 write_flash --flash_mode dout --flash_size=detect 0x00000 ./rboot.bin 0x02000 ./rom0.bin 0x100000 ./spiff_rom.bin
Sollte so passen oder?
esptool.py --port /dev/ttyUSB5 write_flash --flash_mode dout --flash_size=detect 0x00000 ./rboot.bin 0x02000 ./rom0.bin 0x100000 ./spiff_rom.bin
esptool.py v2.0.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0340
Compressed 2752 bytes to 1930...
Wrote 2752 bytes (1930 compressed) at 0x00000000 in 0.2 seconds (effective 114.9 kbit/s)...
Hash of data verified.
Compressed 339952 bytes to 239964...
Wrote 339952 bytes (239964 compressed) at 0x00002000 in 22.0 seconds (effective 123.8 kbit/s)...
Hash of data verified.
Compressed 786432 bytes to 218606...
Wrote 786432 bytes (218606 compressed) at 0x00100000 in 20.1 seconds (effective 312.9 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting...
Netz ist da... :-)
Mal schauen ob es stabil ist...
Gruß,
Stefan
hier..
esptool.py -p COM8 -b 115200 write_flash -ff 40m -fm dout -fs 32m 0x00000 test/rboot.bin 0x01000 test/blank.bin 0x02000 test/rom0.bin 0x100000 test/spiff_rom.bin
aber wichitg.... Flah erase vorher...
esptool.py.exe --port COM11 erase_flash
Gruß
Markus
Nach dem Flashen sah es gut aus.
Aber sobald ich OTA einspiele ist er wieder im Bootloop.
Kommt gar nicht mehr hoch.
Sehr seltsam.
Was könnte das noch sein? Strom kommt zur Zeit vom USB.
@Markus:
Braucht man das blank.bin? Das habe ich nicht...
Gruß,
Stefan
Lad mal die letzte Stable und Flash die mal
Und dann erstmal testen ohne ota. Hab zwar noch nie ein Problem mit ota gehabt aber hab ich schon Pferde kotzen gesehen. Was heisst Spannung über USB? 5v? Kommen da noch 3,3 aus dem dcdc Wandler? Dein Netzteil hast du aber als Fehlerquelle ausgeschlossen?!
Und vor dem neu flashen... Flash erase!!
Tja FTDI und die Windowstreiber! Welche Version zeigt Dein Gerätemanager an?
http://www.eevblog.com/forum/microcontrollers/ftdi-gate-2-0/
Kurzfassung: Neuer Win FTDI Treiber + China Clone FTDI = Zufälliger Müll in Kommunikation
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hi,
nochmal vielen Dank für die Hilfe.
Ich werde beim Linux flashen bleiben.
Ich flashe die letzte Version von Patricks Firmware.
Meinst du das mit letzter stable?
Das geht dann auch. Wie stabil es dann läuft muss ich mal testen.
Sobald ich dann OTA auf vbs mach gehts auf jeden fall los mim rebooten.
Ok er macht auch schon reboots mit der original firmware.
Mit Strom von USB meinte ich die 3,3v vom FTDI.
Also Fehler am Netzteil ist im moment ausgeschlossen, da er nur über FTDI am strom hängt.
Gruß,
Stefan
Stop.... Welche Firmware Flashst du denn manuell? Ich gehe davon aus die letzte Stable der VBS Firmware??!! Nicht die "ältere von Patrick?
Ja mit Stable meine ich die von der normalen Vbs ota url.
Du hast aber auch ein 12v Netzteil angeschlossen bei deinen Versuchen?? Und nicht nur den ftdi?
Zur Zeit habe ich nur den FTDI.
Hatte vorher aber auch mit 12V netzteil versucht.
Letzte stable vbs zum flashen? Wo bekomme ich die her?
Ich dachte der weg wäre immer Patricks und dann die vbs per OTA?
Ich montore gerade per ping den ESP mit patricks firmware.
Habe bisher nur 1 mal ein reboot am anfang beobachtet.
Ok hab die Firmware unter gh-pages gefunden:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/gh-pages
Gruß,
Stefan
Mach die Spannungsversorgung über Netzteil und nicht den ftdi Adapter!
Ok versuche ich nochmal.
Nach ein paar reboots gings jetzt dann doch. Ich beobachte es jetzt mal.
Habe jetzt die letzte stable drauf geflashed
Ab und an hab ich aber leider immer noch nen reboot.
Kann man noch was am flashen ändern / ausprobieren?
Gruß,
Stefan
Bei welcher Aktion kommt denn der Reboot?
Machst du was im webif oder fhem? Oder garnichts also einfach nur ping drauf?
Mach nur ping drauf damit ich sehe wann er rebootet.
Fhem läuft aber eventuell macht das Modul etwas?
Habe die passende vbs version im FHEM.
Nach etwas beobachten rebootet er sporadisch.
Hat aber nichts mit FHEM oder WEBif anfragen zu tun.
Zumindest kann ich es damit nicht forcieren.
P.S.:
Das ist alles zum verrückt werden.
Habe den RGBWW nun wieder eingebaut.
Seit dem läuft er ohne Probleme.
Das ist mir ein absolutes Rätsel.
Habe die Selbe Spannungsquelle beim Flashen und nun in Betrieb verwendet.
Bin ertsmal zufrieden. Mal sehen obs so bleibt.
Heute Abend nochmal getestet. Ich glaub es nicht. Es läuft jetzt einwandfrei.
Keine Ahnung aber das Flashen mit Dout hats wohl doch gebracht.
Warum ich am Anfang noch Probleme hatte nach dem Flashen ist mir ein Rätsel.
Ich danke noch mal allen für Ihre Hilfe. Das mit dem Windows Treiber ist echt Müll.
Ich werde nur noch per linux und dem esptool.py flashen. Das funktioniert super.
Und immer schön die letzte stable vom vbs nehmen.
Das war mir am Anfang auch nicht ganz klar.
Gruß und nochmals vielen Dank,
Stefan
Zitat von: Shojo am 07 Juni 2018, 08:22:34
Daher setzte ich eigentlich immer einen Stützkondensator ein um den Problem vorzubeugen.
Hallo Dennis,
vielen Dank fuer den Hinweis. Wie es bis jetzt aussieht, habe ich damit einen Sonoff Basic Schalter gerettet.
Der ist nach dem Flashen immer ein paar Stunden gelaufen um dann ungefaehr im Minutentakt zu rebooten.
Nun laeuft er immerhin schon vier Tage anstandslos durch.
Gruss Helmut
Moin zusammen.
Ich war so dreist und habe nicht den ganzen Thread gelesen. Sorry.
Ich habe folgendes Problem:
FHEM aktualisiert auf die neuste Version. Heute (26.06.2018)
Modul: 32_EspLedController.pm aus dem Git (per FHEM-Update / auch Heute)
Firmware: die aktuellste per OTA-Update.
Die Verbindung zu den Controllern wird hergestellt (opened) aber alle Anfragen an den Controller enden in einer "empty answer". Siehe auch Log-Auszug.
Was ist das und was kann ich dagegen tun? Gab es eine signifikante Änderung in FHEM? Mit einer FHEM-Version von vor einem Jahr läuft es (Keine Ahnung wie alt... brauche aber das Update für meine Hardware)
2018.06.26 14:29:41 2: wz_gardine: error http://192.168.1.8/config?: empty answer received retrieving config
2018.06.26 14:29:41 2: wz_glas1: error http://192.168.1.10/config?: empty answer received retrieving config
2018.06.26 14:29:41 2: wz_glas2: error http://192.168.1.11/config?: empty answer received retrieving config
2018.06.26 14:29:41 2: wz_sofa: error http://192.168.1.9/config?: empty answer received retrieving config
2018.06.26 14:29:41 2: sz_nachtlicht: error http://192.168.1.12/config?: empty answer received retrieving config
2018.06.26 14:29:44 3: sz_nachtlicht: got info response
2018.06.26 14:29:44 2: sz_nachtlicht: error http://192.168.1.12/info?: empty answer received retrieving info
2018.06.26 14:29:44 3: wz_gardine: got info response
2018.06.26 14:29:44 2: wz_gardine: error http://192.168.1.8/info?: empty answer received retrieving info
2018.06.26 14:29:44 3: wz_glas1: got info response
2018.06.26 14:29:44 2: wz_glas1: error http://192.168.1.10/info?: empty answer received retrieving info
2018.06.26 14:29:44 3: wz_sofa: got info response
2018.06.26 14:29:44 2: wz_sofa: error http://192.168.1.9/info?: empty answer received retrieving info
2018.06.26 14:29:44 3: wz_glas2: got info response
2018.06.26 14:29:44 2: wz_glas2: error http://192.168.1.11/info?: empty answer received retrieving info
2018.06.26 14:29:47 2: wz_glas1: error http://192.168.1.10/color?: empty answer received retrieving color
2018.06.26 14:29:47 2: wz_sofa: error http://192.168.1.9/color?: empty answer received retrieving color
2018.06.26 14:29:47 2: wz_glas2: error http://192.168.1.11/color?: empty answer received retrieving color
2018.06.26 14:29:47 2: sz_nachtlicht: error http://192.168.1.12/color?: empty answer received retrieving color
2018.06.26 14:29:47 2: wz_gardine: error http://192.168.1.8/color?: empty answer received retrieving color
2018.06.26 14:30:40 3: wz_gardine: got info response
2018.06.26 14:30:40 2: wz_gardine: error http://192.168.1.8/info?: empty answer received retrieving info
Grüße^^
Kannst du sagen, wann das bei dir auftritt? Tritt das evtl. bei jedem FHEM-Start auf?
Ja genau. Bei jedem Start und wenn eine Verbindung zum Controller wieder hergestellt wird, falls er mal aus'm WLAN geflogen ist.
Steuern lassen Sie sich aber auch nicht.
Hm, ich werde mir das irgendwann mal in Ruhe anschauen müssen. Ich kann das hier auf jeden Fall auch reproduzieren.
Passiert bei mir nur wenn der komplette Rechner rebootet (und dann eben auch FHEM neu startet). Wenn ich nur FHEM neu starte, dann passierts nicht. Wenn ich einen Controller reboote, dann passierts auch nicht.
Dadurch dass ich den Rechner rebooten muss, ist das Debuggen entsprechend aufwendig. Hätte gerne mal den Traffic im Fehlerfall mit tcpdump mitgeschnitten...
Zitat von: vbs am 27 Juni 2018, 21:40:47
Hätte gerne mal den Traffic im Fehlerfall mit tcpdump mitgeschnitten...
Ich hänge mich da am Wochenende nochmal ran und versuche das zu loggen.
Bei mir tritt es bei jedem FHEM-Start auf. Insbesondere fällt es ins Auge bei dem "shutdown restart" nach dem Update, weil er deutlich länger braucht.
Aktuell bleibe ich mal bei der alten Version. Die aktuelle bremst alles ganz schön aus... kann natürlich auch davon kommen. Das aktualisierte Modul welches ich brauche läuft in der alten auch.
Grüße^^
Da waren beim Start 2 Anfragen doppelt. Könnte der Grund gewesen sein. Könntest du bitte mal die Version im Anhang bei dir testen?
Kanns sein, dass die Ansteuerung der White-LED´s fehlerhaft ist? Ich hab heute den RGBWW-Controller verbaut mit der vbs-firmware darauf. Hatte vorher den LD382, und mir kommt stark vor, dass die weißen LED´s heller geworden sind als jetzt. Ich müsste das morgen nochmal vergleichen indem ich nochmals den LD382 anschließe, aber ich bin mir fast sicher, dass es heller ging... (hsv 0,0,100). Das verwendete NT ist in beiden Fällen dasselbe.
Bissl komisch :o
Klar, kann sein. Kann aber gar nicht genau sagen, ob alle Controller per Definition den gleichen Strom abgeben bzw. gleich hell sein sollten?
Hi,
ich weiß jetzt gar nicht wie der aktuelle Sketch ist, aber am Anfang hatten wir diese Diskussion auch mal.
Da gab es dann unterschiedliche Zielwerte der Variablen des PWMM von 0-1024 bzw. 0-768.
Wie ist das heute im Sketch?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Problem scheint gelöst zu sein. Man muss im Webinterface des Controllers den Slider WW----CW ganz nach links zu warmweiß stellen. Erst dann bekommen die (warm)weißen LED´s die volle Leistung. Helligkeit ist dann dieselbe als mit dem LD382, sollte also passen. ;D
Edit: Noch einfacher wärs, wenn ich einfach den richtigen Output Type, nämlich "RGBWW" gewählt hätte. ::) ::)
Gibt das Modul denn keinen State zurück? In der andFhem App für Android steht 'Zustand' immer auf 'on', wenn ich auf 'off' klicke, wird der Befehl zwar ausgeführt, die Buttons bleiben trotzdem gleich. (Also keine Farbänderung der Buttons).
Es gibt die Readings "state" und "stateLight". Ersterer ist der Verbindugnsstatus und letzterer der Beleuchtungsstatus. Guck dir das doch mal in FHEM an, da kann man alle Readings sehen.
Ok, danke. Und wie schaffe ich es dann das mir statt "opened" eben "on:off" bzw. die Glühbirne angezeigt wird?
Attribut stateFormat
Zitat von: masked__rider am 03 Juli 2018, 00:21:45
Ok, danke. Und wie schaffe ich es dann das mir statt "opened" eben "on:off" bzw. die Glühbirne angezeigt wird?
Gesendet von meinem Doogee S60 mit Tapatalk
Gefunden im commandref, danke. Hab nicht genau gewusst wonach ich suchen muss.
Hi,
ich habe einen RGB WW CW strip dran.
Wie kann ich denn die WW CW Kanäle gezielt ansteuern?
RGB ist jekein Problem über "set XXX rgb xxxxxx" aber die WW CW?
danke!
Zitat von: Frank_Huber am 15 August 2018, 18:17:07
Hi,
ich habe einen RGB WW CW strip dran.
Wie kann ich denn die WW CW Kanäle gezielt ansteuern?
RGB ist jekein Problem über "set XXX rgb xxxxxx" aber die WW CW?
danke!
Mein Verständins ist, dass CW / WW in RGB für Weißanteile eingemischt wird.
Zum Setzen kenn ich nur die "set LED_rgb raw 0,0,0,$ww,$cw" Möglichkeit. Es gab mal die Überlegung CW / WW mit einzubauen, aber ich glaube das ist (noch) nicht drin.
Zitat von: kadettilac89 am 15 August 2018, 18:37:33
Zum Setzen kenn ich nur die "set LED_rgb raw 0,0,0,$ww,$cw" Möglichkeit. Es gab mal die Überlegung CW / WW mit einzubauen, aber ich glaube das ist (noch) nicht drin.
Ah, danke. Das raw ist in der doku noch nicht drin, das werd ich nachher testen. [emoji3][emoji3][emoji3]
Gesendet von meinem Doogee S60 mit Tapatalk
SUPER! DANKE! das geht! :-)
set DEVICE raw r,g,b,ww,cv
pro Farbe sind (soweit ich das testen konnte Werte von 0 bis 1024 möglich.
Zitat von: Frank_Huber am 15 August 2018, 19:00:23
Ah, danke. Das raw ist in der doku noch nicht drin, das werd ich nachher testen. [emoji3][emoji3][emoji3]
Vielleicht hilfts dir ... ich habe mir für die Weißtöne 2 Dummy als Slider angelegt. dummy1 Helligkeit, dummy2 für Farbton ... Siehe Bild.
Notify sieht dann so aus ...
defmod ntf_Dimmer notify (dy_Dimmer|dy_Dimmer2):* {\
my $farbwert = ReadingsVal("dy_Dimmer","state","100");;\
my $helligkeit = ReadingsVal("dy_Dimmer2","state","100")/100;;\
my $cw = 0;;my $ww = 0;;\
if ($farbwert < 50 ) {\
$ww = $farbwert * 20.46 * $helligkeit;;\
$cw = 1023 * $helligkeit;; \
} else {\
$cw = (100 - $farbwert) * 20.46 * $helligkeit;;\
$ww = 1023 * $helligkeit;;\
};;\
fhem ("set LED_rgb raw 0,0,0,$ww,$cw");;\
#Log 1,"farbwert: ".$farbwert."cw:".$cw." ww:".$ww;;\
}
Erklärung 20.46 --> bei 50% (Slider Farbton in der Mitte) sollen beide Farben - CW + WW - zu 100% leuchten. 20.46 * 50 = 1023 (Maximum bei RAW).
Dummy1 (Dummy2 identisch, nur Alias ist anders)
defmod dy_Dimmer dummy
attr dy_Dimmer alias Weißton
attr dy_Dimmer group Dimmer
attr dy_Dimmer room Wohnzimmer
attr dy_Dimmer setList state:slider,0,1,100
attr dy_Dimmer userReadings helligkeit { ReadingsVal("LED_rgb","val",0);; }
attr dy_Dimmer webCmd state
Zitat von: Frank_Huber am 15 August 2018, 19:09:04
pro Farbe sind (soweit ich das testen konnte Werte von 0 bis 1024 möglich.
Ich denke 1023 ist Maximum, habe das in der obigen Logik drin. Müsste nachlesen. 0 - 1023 = 1024 Werte ...
Zitat von: kadettilac89 am 15 August 2018, 19:15:43
Ich denke 1023 ist Maximum, habe das in der obigen Logik drin. Müsste nachlesen. 0 - 1023 = 1024 Werte ...
Ja, ist auch logisch. 0 bis 1023 ergibt 1024 Werte.
Das wäre dann eine 11 Bit Auflösung.
RGB geht mit seinen je 8 Bit ja auch von 0 bis 255.
War vorhin bein schreiben nicht ganz klar. [emoji23][emoji23][emoji23]
Danke für den notify, wie ich es mal WAF freundlich ansteuere weiß ich grad noch nicht.
Denke momentan über 3 Taster nach. Einer zum Farben toggeln, zwei für dimup /dimdown.
Aber das ist nur mal die erste Idee.....
Gesendet von meinem Doogee S60 mit Tapatalk
So, hab noch bißchen getestet.
Dimup/dimdown scheint nicht mit raw zusammenzuspielen. Schade.
Werde dann Wohl deine Lösung kopieren. Will es dann nur um 4 slider und ein weiteres notify erweitern. (R/g/b/pct)
Wozu ist eigentlich das userReading in den dummys?
Das wertet du nicht aus.
Für heute ist aber erstmal Schluss.
Danke nochmal!
Gesendet von meinem Doogee S60 mit Tapatalk
das UserReading kannst weg lassen, das nutze ich in einer anderen Funktion zum Faden ... bzw. hatte das mal vor um weniger Referenzen in der Sub rumschleppen zu müssen.
Kennst das, s. Link ... vielleicht was brauchbares dabei. Ansonsten ... readingsGroup
https://wiki.fhem.de/wiki/Slider_f%C3%BCr_HM-Rollladensteuerung_anzeigen
denke ich hab was ich will (für das back-End):
Hardware:
define ESP_RGBWW_1 EspLedController 192.168.112.139
attr ESP_RGBWW_1 DbLogExclude .*
attr ESP_RGBWW_1 group Hardware
attr ESP_RGBWW_1 room ESP_RGBWW
attr ESP_RGBWW_1 stateFormat R=raw_red | G=raw_green | B=raw_blue | CW=raw_cw | WW=raw_ww
Dummys: (wie deine, nur 6 Stück)
define D_ESP_RGBWW_1_White_Dimmer dummy
attr D_ESP_RGBWW_1_White_Dimmer alias 1_Weiß_Dimmer
attr D_ESP_RGBWW_1_White_Dimmer group Dimmer
attr D_ESP_RGBWW_1_White_Dimmer room ESP_RGBWW
attr D_ESP_RGBWW_1_White_Dimmer setList state:slider,0,1,100
attr D_ESP_RGBWW_1_White_Dimmer webCmd state
define D_ESP_RGBWW_1_White_Color dummy
attr D_ESP_RGBWW_1_White_Color alias 2_Weiß-Farbton
attr D_ESP_RGBWW_1_White_Color group Dimmer
attr D_ESP_RGBWW_1_White_Color room ESP_RGBWW
attr D_ESP_RGBWW_1_White_Color setList state:slider,0,1,100
attr D_ESP_RGBWW_1_White_Color webCmd state
define D_ESP_RGBWW_1_RGB_Dimmer dummy
attr D_ESP_RGBWW_1_RGB_Dimmer alias 3_RGB-Dimmer
attr D_ESP_RGBWW_1_RGB_Dimmer group Dimmer
attr D_ESP_RGBWW_1_RGB_Dimmer room ESP_RGBWW
attr D_ESP_RGBWW_1_RGB_Dimmer setList state:slider,0,1,100
attr D_ESP_RGBWW_1_RGB_Dimmer webCmd state
define D_ESP_RGBWW_1_RGB_R dummy
attr D_ESP_RGBWW_1_RGB_R alias 4_Rot
attr D_ESP_RGBWW_1_RGB_R group Dimmer
attr D_ESP_RGBWW_1_RGB_R room ESP_RGBWW
attr D_ESP_RGBWW_1_RGB_R setList state:slider,0,1,100
attr D_ESP_RGBWW_1_RGB_R webCmd state
define D_ESP_RGBWW_1_RGB_G dummy
attr D_ESP_RGBWW_1_RGB_G alias 5_Grün
attr D_ESP_RGBWW_1_RGB_G group Dimmer
attr D_ESP_RGBWW_1_RGB_G room ESP_RGBWW
attr D_ESP_RGBWW_1_RGB_G setList state:slider,0,1,100
attr D_ESP_RGBWW_1_RGB_G webCmd state
define D_ESP_RGBWW_1_RGB_B dummy
attr D_ESP_RGBWW_1_RGB_B alias 6_Blau
attr D_ESP_RGBWW_1_RGB_B group Dimmer
attr D_ESP_RGBWW_1_RGB_B room ESP_RGBWW
attr D_ESP_RGBWW_1_RGB_B setList state:slider,0,1,100
attr D_ESP_RGBWW_1_RGB_B webCmd state
Logik per DOIF:
define DOIF_ESP_RGBWW_1 DOIF (["^D_ESP_RGBWW"])\
{\
my $w_dim = ReadingsVal("D_ESP_RGBWW_1_White_Dimmer","state","0")/100;;\
my $w_col = ReadingsVal("D_ESP_RGBWW_1_White_Color","state","0");;\
my $rgb_dim = ReadingsVal("D_ESP_RGBWW_1_RGB_Dimmer","state","0")/100;;\
my $rgb_r = ReadingsVal("D_ESP_RGBWW_1_RGB_R","state","0");;\
my $rgb_g = ReadingsVal("D_ESP_RGBWW_1_RGB_G","state","0");;\
my $rgb_b = ReadingsVal("D_ESP_RGBWW_1_RGB_B","state","0");;\
my $raw_r = 0;;my $raw_g = 0;;my $raw_b = 0;;my $raw_cw = 0;;my $raw_ww = 0;;\
\
$raw_r = ($rgb_r * 10.23) * $rgb_dim;;\
$raw_g = ($rgb_g * 10.23) * $rgb_dim;;\
$raw_b = ($rgb_b * 10.23) * $rgb_dim;;\
\
if ($w_col < 50 ) {\
$raw_ww = $w_col * 20.46 * $w_dim;;\
$raw_cw = 1023 * $w_dim;; \
} else {\
$raw_cw = (100 - $w_col) * 20.46 * $w_dim;;\
$raw_ww = 1023 * $w_dim;;\
\
};;\
fhem ("set ESP_RGBWW_1 raw $raw_r,$raw_g,$raw_b,$raw_ww,$raw_cw");;\
}
attr DOIF_ESP_RGBWW_1 DbLogExclude .*
attr DOIF_ESP_RGBWW_1 do always
attr DOIF_ESP_RGBWW_1 group Logik
attr DOIF_ESP_RGBWW_1 room ESP_RGBWW
jetzt muss ich mir Gedanken machen wie ich das als Frontend hinbekomme.
mal schauen was es an ESPs gibt die 6 analoge Eingänge haben. damit müste sich was basteln lassen.
Zitat von: Frank_Huber am 16 August 2018, 13:38:41
jetzt muss ich mir Gedanken machen wie ich das als Frontend hinbekomme.
Ich habe meine Slider schon vor Langem gebaut, sehe grad dass sich im Colorpicker einiges getan hat ... ggf. kannst du die Colorpicker von hue (als dummy) verwenden und daraus die Raw-Werte abgreifen und mit denen per notify oder doif schalten
https://wiki.fhem.de/wiki/Color
Zitat von: Frank_Huber am 16 August 2018, 13:38:41
mal schauen was es an ESPs gibt die 6 analoge Eingänge haben. damit müste sich was basteln lassen.
Was willst du damit schalten? Der Controller macht ja genau die 5 Kanäle, oder ist das ein anderes Projekt?
Zitat von: kadettilac89 am 16 August 2018, 15:39:00
Ich habe meine Slider schon vor Langem gebaut, sehe grad dass sich im Colorpicker einiges getan hat ... ggf. kannst du die Colorpicker von hue (als dummy) verwenden und daraus die Raw-Werte abgreifen und mit denen per notify oder doif schalten
https://wiki.fhem.de/wiki/Color
Was willst du damit schalten? Der Controller macht ja genau die 5 Kanäle, oder ist das ein anderes Projekt?
Frontend = etwas was an der Wand hängt. Denke da s war vorher nicht klar.
d.h. ich will die Dummys über Hardware füttern. ein ESP32 mit Fadern z.B.
das Backend in FHEM steht ja jetzt.
Es muss halt etwas sein was ohne Handy / Tablet / sonstwas einfach zu bedienen ist. Also tauglich für Frau und Kinder. :-)
Hab da jetzt nen kleines 6-Kanal DMX Pult im Auge, das dann ausschlachten und nen ESP32 rein. mittels ESPEasy anbinden und fertig sind die Hardware-Fader.
Morgähn,
besteht in des vbs Firmware die Möglichkeit Einschalt Settings zu definieren?
Also nach Power Up gewisse raw Werte einzustellen?
Geht mW leider nicht, fände ich aber auch ein sinnvolles Feature.
Im Moment ist es so, dass beim Booten die zuletzt eingestellte Farbe wieder eingestellt wird. Aber auch das geht soweit ich weiß nur für HSV (nicht für RAW). Also da müsste man eigentlich mal einiges umbauen...
OK, danke für die Info.
dann versuche ich mich mal mit einem Presence und DOIF zu behelfen.
EDIT:
presence Modul anlegen für den Controller,
den Code aus dem DOIF in die myUtils auslagern,
neues DOIF anlegen:
defmod ESP_RGBWW_1_startup DOIF ([ESP_RGBWW_1_presence:"^present$"]) {esp_rgbww_1} (set ESP_RGBWW_1_presence overrideInterval 60)\
DOELSEIF ([ESP_RGBWW_1_presence:"^absent$"]) ((set ESP_RGBWW_1_presence overrideInterval 5))
attr ESP_RGBWW_1_startup do always
dauert paar Sekunden, aber nach Startup werden die Dimmer-Dummys abgefragt und der Controller eingestellt.
Besteht da allgemeines Interesse an einem besser kontrollierbaren Bootup-Verhalten? Also feste Farbe und Wahl zwischen HSV und Raw?
Ja klar ;-) Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Alternativ zur festen Boot Farbe wäre es auch denkbar dass sich der Controller im Modul "anmeldet"
Damit könnte FHEM schneller die Ereichbarkeit feststellen und direkt darauf reagieren.
Oder der Controller könnte sich einfach die letzte Einstellung merken.
Zitat von: vbs am 21 August 2018, 11:03:41
Besteht da allgemeines Interesse an einem besser kontrollierbaren Bootup-Verhalten? Also feste Farbe und Wahl zwischen HSV und Raw?
Ich hätte Interesse an einem loopenden Programm (set LED_rgb hue +359 120 lqr:Rainbow) beim Start :) Aber fester Startwert ist auch schon interessant.
Haha ich bin offenbar etwas zerstreut:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#startup-color--vbs33
Aber die Doku wird offenbar auch nicht so gut angenommen ;)
Zitat von: vbs am 21 August 2018, 16:45:44
Haha ich bin offenbar etwas zerstreut:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#startup-color--vbs33
Aber die Doku wird offenbar auch nicht so gut angenommen ;)
Uuups. :)
vielleicht in der Modul-Doku verlinken?
aber btw: Das OTA Update liefert die vbs32.
Das OTA Update auf die testing Version hat ihn wohl erstmal getötet.
Er kommt nicht mehr online.
Gesendet von meinem Doogee S60 mit Tapatalk
Hm ist hier auch passiert. Muss ich mir ansehen.
Wollte den aus der ersatzteilkiste gerade auf die Release Version ziehen um den neuen zu ersetzen: scheinbar auch tot.
Gesendet von meinem Doogee S60 mit Tapatalk
Ja sorry, hatte zwischenzeitlich eine vbs34 gemacht. Da ist es bei mir passiert. Ist jetzt beides wieder vbs32.
Na toll... Mein letzter funktionierender Controller is im Büro am Testsystem. [emoji23][emoji23][emoji23]
Gibt es eben heute nur kaltweis per LED Röhre.
Mal sehen ob ich das mit dem flashen hinbekomme.
[emoji849]
Gesendet von meinem Doogee S60 mit Tapatalk
Hi,
habe das gerade verfolgt und bin total erstaunt von diesem Befehl:
set LED_rgb hue +359 120 lqr:Rainbow
Könnt ihr mir bitte sagen wo man die syntax nachlesen kann? Wusste garnicht das sowas geht.
Habe schon gegoogelt. Aber unter RGBWW und rainbow finde ich nichts außer den Farbraum.
Danke schonmal und gruß,
Stefan
Meine sind ja momentan zum Backstein degradiert, was macht dieser Befehl denn?
Gesendet von meinem Doogee S60 mit Tapatalk
Doku zu den Befehlen gibts hier:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Muss wohl wirklich mal einen Link in die FHEM-doku einbauen... ???
Den hier:
set LED_rgb hue +359 120 lqr:Rainbow
Finde ich aber auch in der doku nicht. [emoji6]
Zitat von: vbs am 21 August 2018, 21:27:39
Doku zu den Befehlen gibts hier:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Muss wohl wirklich mal einen Link in die FHEM-doku einbauen... ???
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 21 August 2018, 21:32:19
Den hier:
set LED_rgb hue +359 120 lqr:Rainbow
Finde ich aber auch in der doku nicht. [emoji6]
Das führt einen permanenten Farbkreis aus. Farbwechsel 2 Min. Die einzelnen Teile des Befehls sind irgendwo im github beschrieben
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#function-demonstrations
Habe aber im Forum Hilfe bekommen.
https://forum.fhem.de/index.php/topic,70738.msg796648.html#msg796648
Vielleicht steht für dich was brauchbares drin :)
Ok, vielen Dank!
So langsam verstehe ich etwas.
q und r sind klar, was ist l?
Ich wollte aber auch nicht vom Thema ablenken, hatte mich nur interessiert.
Danke.
Gruß,
Stefan
Zitat von: Frank_Huber am 21 August 2018, 21:32:19
Den hier:
set LED_rgb hue +359 120 lqr:Rainbow
Finde ich aber auch in der doku nicht. [emoji6]
Hm was fehlt denn? Ist halt eine Kombination aus folgenden Features:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#relative-values
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#new-flags
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#named-animations
Das "l" gab es schon in der Original-FW und ist in der FHEM-Doku beschrieben. Bewirkt einfach, dass bei Hue-Änderung der lange Web (auf dem Farbkreis) genommen wird (default ist der kurze).
Hi,
kann es sein dass mit der 32er auch etwas nicht stimmt?
versuche gerade meine Controller zu flashen, mit den aktuellen Dateien die in der json verlinkt sind bootet er nicht.
flashe ich die "originalen" Datein bootet er.
Flashanleitung und Dateien von hier:
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
Wenn ich dann OTA auf deine 32er gehen will ist er auch wieder tot.
Also OTA auf 32 zu flashen ging mir gestern zig Mal. Es ist aber immer so eine Sache mit der Konfiguration. Bin mir nicht sicher, ob es nicht Probleme geben kann, wenn man von einer sehr alten Firmware auf eine neue geht. Ich könnte mir denken, dass da die Konfiguration (die ja weiter verwendet wird) nicht immer kompatibel ist. Ist vermtl. auch der Grund des Problems mit der vbs33b. Muss ich mir mal anschauen bei Gelegenheit.
Hab im ersten Post mal ergänzt, wie ich bei mir seriell flashe. Vielleicht hast du damit mehr Glück
hast du es seit dem datei-tausch gestern 34/32 nochmal gemacht?
wie gesagt, wenn ich die im json verlinkten Dateien per Flasher (nach löschen des ESP) versuche geht es auch nicht.
Ich arbeite allerdings unter Windows. müsste es mir auf einem Raspi erstmal einrichten.
Ja, habe von meiner Dev-Version auf die offizielle OTA-URL (v32) geupdatet. Bestimmt 10 mal.
Zitat von: vbs am 22 August 2018, 13:55:15
Hab im ersten Post mal ergänzt, wie ich bei mir seriell flashe. Vielleicht hast du damit mehr Glück
könntest Du bitte die hierfür benötigten Dateien verlinken?
rboot.bin --> hab ich von der json
blank.bin --> ???
rom0.bin --> ???
spiff_rom.bin --> hab ich von der json
Würde das dann mal auf deinen Weg versuchen.
Habs jetzt nochmal versucht.
Flash gelöscht, neu geflasht wie in der verlinkten Anleitung oben.
in der webapp den OTA Pfad geändert und OTA Update gestartet.
--> tot.
Hier der Outcome der seriallen Konsole: (ca 5min nach "OTA successful" habe ich ihn neu gestartet.)
rlS+TCP connection
timeout updating: 70 -> 65535
Server timeout updating: 40 -> 90
RGBWW Controller v 0.3.1
sleep disable
mode : sta(60:01:94:2b:96:b5)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
cnt
connected with Huber, channel 1
dhcp client start...
ip:192.168.8.103,mask:255.255.255.0,gw:192.168.8.1
pm open,type:0 0
Starting OTA ...
OTA successful
dannach nur noch Hyroglyphen... (Anhang)
bin jetzt echt ratlos. Hatte ja vor paar Tagen all 3 OTA auf die 32 hochgezogen.
Würde als nächstes deinen Flash-Weg ausprobieren.
EDIT:
einen konnte ich jetzt OTA auf die TESTING Version (ebenfalls vbs32) updaten.
config-ota-url http://rgbww.dronezone.de/testing/version.json 2018-08-22 16:19:06
info-firmware vbs32 2018-08-22 16:19:09
info-sming_version 3.5.1 2018-08-22 16:19:09
info-uptime 120 2018-08-22 16:19:09
info-webapp_version 0.3.3-shojo7 2018-08-22 16:19:09
lastFwUpdate Update successful - Restarting device... 2018-08-22 16:16:30
EDIT2:
Der zweite der geschossenen hat das selbe Update nicht überlebt.
Also das Problem mit vbs33b konnte ich nachvollziehen und hoffentlich beheben. Hab jetzt eine vbs35b gemacht:
http://rgbww.dronezone.de/testing/version.json
Zu deinen Problemen hab ich leider keine konkrete Idee, bin aber der Meinung, dass das prinzipiell funktionieren muss. Die rom0.bin findest du unter der gleiche URL (z.B. http://rgbww.dronezone.de/testing/rom0.bin), die blank kannst du erstmal weglassen.
Ich hab jetzt den übrig gebliebenen vbs32er vom Testsystem für das Licht draussen installiert, durch die 24V Strips reicht da zum Glück einer für die 168W. [emoji3]
Werd dann morgen mein Glück versuchen über deine Flash Methode.
Ich gebe Bescheid!
Gesendet von meinem Doogee S60 mit Tapatalk
Danke vbs!
Die beidet leben wieder mit der 35er FW.
esptool.py -p /dev/ttyUSB1 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 /home/pi/Documents/vbs_FW/rboot.bin 0x02000 /home/pi/Documents/vbs_FW/rom0.bin 0x100000 /home/pi/Documents/vbs_FW/spiff_rom.bin
war dann der Flash-Befehl.
Nur den Parameter "Startup Color (>= vbs33)" finde ich auch in der 35er nicht,
auch über FHEM kann ich ihn nicht schicken.
set TYPE=EspLedController config color/startup_color last
liefert "Invalid config parameter name!"
In FHEM musst du Config-Parameter immer in dieser Form angeben:
config-color-startup_color
Bitte drauf achten, dass der Wert immer dem Format "x,y,z" oder "x,y,z,c" entspricht. Da fehlte ein return-Statement, so dass ein falscher Eintrag vermtl. in einer Boot-Schleife endet (in vbs35b). Aber "0,100,100" macht bei mir was es soll. Das wird dann in der finalen vbs36 behoben sein.
Ich hätte eine kurze Frage zur Konfiguration, dazu finde ich in der Doku nichts. Habe Platine in Version 1.5 bestellt und bestückt. Die Firmware seriell geflashed (nodemcuflasher). Danach geresettet. Leider Finde ich das Teil nicht als wlan access Point. Bzw. Wie kann ich darauf zugreifen.
Der Controller muss einen AP aufmachen, wenn alles gut gegangen ist. Name ist irgendwie "RGBWW" oder ähnlich.
Zitat von: tunguskar am 24 August 2018, 12:53:45
Die Firmware seriell geflashed (nodemcuflasher). Danach geresettet. Leider Finde ich das Teil nicht als wlan access Point.
wie hast ihn denn geflasht und mit welcher firmware?
Zitat von: Frank_Huber am 24 August 2018, 13:17:20
wie hast ihn denn geflasht und mit welcher firmware?
Laut Jason File: ROM 0.3.1 Webapp: 0.3.3
Zitat von: tunguskar am 24 August 2018, 13:27:55
Laut Jason File: ROM 0.3.1 Webapp: 0.3.3
Flashanleitung:
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
oder über Linux wie von vbs ein paar posts weiter oben beschrieben.
esptool.py -p /dev/ttyUSB1 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 /home/pi/Documents/vbs_FW/rboot.bin 0x02000 /home/pi/Documents/vbs_FW/rom0.bin 0x100000 /home/pi/Documents/vbs_FW/spiff_rom.binDateien:
http://rgbww.dronezone.de/testing/rboot.bin
http://rgbww.dronezone.de/testing/rom0.bin
http://rgbww.dronezone.de/testing/spiff_rom.bin
anstatt "testing" kannst auch "release" nehmen.
Hat jemand das Ganze auf einem China-801-Controller zum laufen bekommen?
Problem ist wohl das zu kleine EEprom, aber es wäre eine sehr günstig zu bekommende Hardware-Alternative
Viele Grüße
Klaus
Zitat von: Frank_Huber am 24 August 2018, 13:35:27
Flashanleitung:
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
oder über Linux wie von vbs ein paar posts weiter oben beschrieben.
esptool.py -p /dev/ttyUSB1 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 /home/pi/Documents/vbs_FW/rboot.bin 0x02000 /home/pi/Documents/vbs_FW/rom0.bin 0x100000 /home/pi/Documents/vbs_FW/spiff_rom.bin
Dateien:
http://rgbww.dronezone.de/testing/rboot.bin
http://rgbww.dronezone.de/testing/rom0.bin
http://rgbww.dronezone.de/testing/spiff_rom.bin
anstatt "testing" kannst auch "release" nehmen.
Läuft jetzt, danke für den Hinweis!
Leider noch eine Frage zu dem FHEM Modul.
Ich habe wie in der Anleitung in FHEM folgendes getan:
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt
Danach:
update
Danach:
restart
Wenn ich jetzt z.B. folgendes device anlegen will:
define testLed EspLedController 192.168.1.18
kommt:
Unknown module 32_EspLedController
Was läuft da noch falsch?
wenn ich z.B. update all eingebe führt fhem die module auch auf:
2018.08.24 22:09:45 1 : espledcontroller
2018.08.24 22:09:46 1 : nothing to do...
Entweder hast du das Modul nicht oder es kann nicht geladen werden (evtl. weil Abhängigkeiten fehlen). Schonmal ins Log geguckt?
Zitat von: vbs am 24 August 2018, 22:14:15
Entweder hast du das Modul nicht oder es kann nicht geladen werden (evtl. weil Abhängigkeiten fehlen). Schonmal ins Log geguckt?
Dank dir.
Ich habe mal in das FHEM Verzeichnis geschaut. Das Modul muss erst in den Ordner kopiert werden. Das wusste ich noch nicht. Bzw. sollte das durch den update Befehl nicht automatisch dort hinkopiert werden? Wenn nicht sollte man das, für user wie mich, in das Wiki mit aufnehmen.
Ich bin mir da nicht ganz sicher. Gibt offenbar Fälle (wie bei dir) bei denen es nicht passiert. Wenn du magst, kannst du gerne im Wiki einen Hinweis ergänzen.
Zitat von: vbs am 25 August 2018, 15:52:42
Ich bin mir da nicht ganz sicher. Gibt offenbar Fälle (wie bei dir) bei denen es nicht passiert. Wenn du magst, kannst du gerne im Wiki einen Hinweis ergänzen.
Ich hab im Wiki mal ein paar Anmerkungen gemacht.
Danke dir!
Hi vbs,
Ne Frage zum Speichern der letzten Kanalzustände,
Mein Controller mit der vbs35 hat die Einstellung auf "last"
Ist aber nach dem Einschalten immer aus.
Kann es sein dass er bei RAW nicht speichert?
Andere Ideen?
Hatte zum Test die Einstellungen ca ne halbe Std nicht geändert, dann den Controller ausgeschaltet, nach paar Min wieder an.
Gesendet von meinem Doogee S60 mit Tapatalk
Ja der Bootup-Code kennt momentan nur HSV.
Zitat von: vbs am 20 August 2018, 10:05:55
Im Moment ist es so, dass beim Booten die zuletzt eingestellte Farbe wieder eingestellt wird. Aber auch das geht soweit ich weiß nur für HSV (nicht für RAW). Also da müsste man eigentlich mal einiges umbauen...
OK, danke. Dann funktioniert das also wie es soll. Bleibt also erstmal das Konstrukt aus DOIF und presence aktiv.
Funktioniert ja auch. [emoji3]
Gesendet von meinem Doogee S60 mit Tapatalk
Mit presence und doif ist der WAF zu gering.
Dauert zu lange bis Licht angeht. [emoji849]
Und presence mit unter 5sek will ich nicht machen.
Da pingt sich der PI tot...
Kann ich irgendwie rgbwwcw zu HSV wandeln?
Im Grunde möchte ich dann einen Mix aus cw und ww mit definierter Helligkeit beim booten.
Gesendet von meinem Doogee S60 mit Tapatalk
Hast du schonmal probiert, die Farbtemperatur im Webinterface zu konfigurieren? Da kannst du WW und CW mischen. Hab aber keine CW/WW-Stripes darum konnte ich es nie testen.
Versucht ja, aber da kommen die weißen LEDs nur auf gefühlte 30% bei ganz hochgezogenen Reglern.
Muss mit dem HSV mal experimentieren. Das is für. Ich Neuland...
Gesendet von meinem Doogee S60 mit Tapatalk
So, mal schnell bißchen Wikipedia zu HSV gelesen.
HSV 0,0,100 ergibt bei den raw Werten für cw und ww jeweils 511.
Geht also auf knapp 50%
Denke für das schnellere Einschalten ist das erstmal OK.
Kann dann ja nachregeln. Wichtig ist dass es erstmal schneller Licht gibt.
Im Webif der cw / ww Regler bewirkt erstmal gar nichts.
Egal wie er steht, beide LEDs leuchten gleich.
Danke.
Gesendet von meinem Doogee S60 mit Tapatalk
ich hol das Thema mal noch mal hoch:
Hat jemand die Firmware schon mal aif einem HS801 mit kleinerem EEPROM zum laufen gebracht?
Hallo,
ich gebe nun entnervt auf.
Seit gut 3 Stunden versuche ich die VBS Firmware auf einen Wemos D1 mini zum laufen zu bekommen.
Stand nun ist:
Der Wemos macht einen offenen AP auf. Ich stelle meine WLan SSID und meine Passwort ein, der Wemos meldet das er sich erfolgreich mit meiner Fritzbox verbunden hat und teilt mir seine neue IP mit. Ich wechsel wieder in mein standard Wlan und rufe die IP auf und nix passiert.
Im Log meiner Fritze steht das sich der Wemos angemeldet hat und ca 5 sek später steht ein Eintrag das er sich wieder abgemeldet hat.
Ich bin verzweifelt. Warum baut er keine stabile Verbindung zu meinem Fritz Wlan auf. Kann ich noch was tun, oder ist die Firmware einfach nicht für Wemos gedacht.
Das Wlan 5Ghz hab ich auch schon weggeschaltet.
Ich bin sehr interessiert an den Möglichkeiten der VBS FW.
Beim Querlesen des Threats ab ich auch keinen zündenden Tip gefunden.
Kann jemand helfen ???
Moin,
hier habe ich einmal festgehalten wie das auf einen Wemos D1 mini beschaltet werden muss...
https://www.bastelbunker.de/esp-rgbww-wifi-led-controller-vbs-edition/
D0 muss du auf 3,3V gebrückt haben, sonst wird der Reset durchgeführt! ;)
Zitat von: Shojo am 15 September 2018, 19:55:03
Moin,
hier habe ich einmal festgehalten wie das auf einen Wemos D1 mini beschaltet werden muss...
https://www.bastelbunker.de/esp-rgbww-wifi-led-controller-vbs-edition/
D0 muss du auf 3,3V gebrückt haben, sonst wird der Reset durchgeführt! ;)
@Shojo
Ohhhh mann ! Hätte ich mal eher hier nach Hilfe geschrien. Ich habe Deine Seite auch schon studiert, habe mir aber den Hardware Aufbau nur kurz angesehen. Nun wollte ich mal eben schnelle einen Wemos flashen um mal mit dem Fhem Modul zu spielen.
Nun die richtige Brücke gemacht und alles funkt.
Nun kann ich endlich heute mal die Hardware zusammenbasteln. Der Sonntag ist gerettet.
Vielen Dank für den Tipp und grüße nach Stuhr :-)
Zitat von: Skusi am 16 September 2018, 09:44:24
Ohhhh mann ! Hätte ich mal eher hier nach Hilfe geschrien.
Ja das kenne ich!
Und das beste ist ich hatte "damals" selbst genau den gleichen Fehler gemacht, als ich versucht hatte die Firmware auf den Wemos D1 mini zu portieren :D
Und einen schönen Gruß zurück nach Ottersberg ;)
Zu dem Resettaster hab ich noch eine Frage:
Ist der beim Bau der Hardware notwendig ? Der Wemos D1 mini hat ja schon einen an Board. Kann ich den D0 dauerhaft auf high legen und den Reset über den eingebauten Taster auslösen ?
Der Reset bezieht sich auf die Settings der Firmware, daher ist der schon nötig wenn man auf dieses Feature nicht verzichten möchte.
So, nun hab ich die Hardware mal auf dem Breedboard zusammengesteckt und etwas mit dem Fhem Modul gespielt.
Läuft wirklich schön sauber.
@vbs: Gute Arbeit ! Danke !
Sehr gut gefällt mir das die Farbübergänge per ramp im Wemos abgewickelt werden. Vorher mit meinen Ufos war das immer so eine ruckelige Geschichte.
Leider vermisse ich aber ein Feature das dringend benötige.
Ich habe keine Möglichkeit gefunden den cw und den ww Kanal separat anzusteuern. Hintergrund ist, das ich in meinem Heimkino einen RGB Strip und 2 weiße Deko - Beleuchtungen über das Modul steuern möchte. Das derzeitige Ufo kann das über das Wifilight Mod Modul zwar, aber eben auch nicht sauber. Und völlig unabhängig geht das auch nicht. Deshalb dachte ich das die VBS FW das ggf. bietet.
Hab ich was übersehen, oder kann ich die beiden Weiß Kanäle wirklich nicht unabhängig dimmen.
Wenn nicht verfügbar, könnte man das in die FW mit einbauen ? Am Besten als zusätzliches Output Model Mode und im Fhem Modul als Attribut mit 2 zusätzlichen dim_cw dim_ww Befehlen.
Könnt Ihr mir da Hoffnung machen, oder muß mir 2 mal die Hardware zusammenlöten ?
Müsstest du mit RAW-Modus machen können!
Kann man definitiv mit raw.
Ich hab dazu dummys pro Farbe und zwei Master Dimmer.
Dazu ein doif das bei dummy Änderung den Controller ansteuert.
Zitat von: vbs am 16 September 2018, 18:16:35
Müsstest du mit RAW-Modus machen können!
Gesendet von meinem Doogee S60 mit Tapatalk
Hallo,
ich habe mir eine WLAN-Lampe mit RGB-LEDs gebaut, die ich gerne mit den Stripes Syncen würde.
Der Einfachheit halber habe ich Neopixel verwendet.
Besteht die Möglichkeit, alternativ zu PWM Neopixel zu unterstützen?
Alles andere wäre ja kompatibel denke ich :)
Viele Grüße,
Kuzl
So, hab ein wenig mit raw probiert.
Es ist zwar etwas unkomfortabel, aber über die raw Kommandos komme ich ans Ziel.
Leider werden scheinbar die readings im Raw Mode nicht aktualisiert. So kann man den aktuellen Status nicht in FTUI darstellen. Und man darf auch nicht zwischen raw Befehlen und den normalen hin und her springen. Ich habe den Controler auf Output Model RGB gestellt, damit die beiden weiß Kanäle nicht mit gesetzt werden. Wenn ich dann per rgb den Strip in eine Farbe tauche, kann ich per raw ,,,1024, 10 den einen weiß Kanal hochdimmen ohne die Fraben zu ändern. Wenn ich dann aber per rgb die Farbe des Strips ändere, fällt der hoch gedimmte Weiß Kanal natürlich wieder auf 0 runter.
Vielleicht wird das ja nochmal in der Firmware eingebaut. Aber für den Moment finde ich das schon sehr hilfreich. Endlich kann ich vernünftig sauber die Übergänge laufen lassen. Und das auch noch in 1024 Schritten.
Super ist das man im raw Befehl auch Kanalangaben fehlen lassen kann um nur einen Kanal zu ändern, und das auch noch mit Fadetime und Que.
Ich werde das Ding nun mal zusammenlöten und damit das Ufo im Heimkino ersetzen.
Vielen Dank bis hierher...
Ich werde gespannt die Entwicklung verfolgen.
Also die raw-Readings werden normalerweise aktualisiert. Liegt evtl. an FHEM?
Ja stimmt, dass man Raw und HSV nicht mischen kann. Wobei dein Fall mit HSV-nur-RGB und CW/WW per Raw sogar technisch machbar wäre mMn.
Ich habe jetzt ein Device angelegt und bekomme im Log folgende Fehlermeldung:
licht.kueche.unterschrank: Can't connect to 192.168.1.23:9090: 192.168.1.23: Connection refused
2018.09.27 22:22:36 3: licht.kueche.unterschrank: got info response
2018.09.27 22:22:36 3: licht.kueche.unterschrank: info response data {"deviceid":"1146135","current_rom":"0","firmware":"0.3.1","git_version":"v0.3.1","git_date":"2016-06-29","config_version":"1","sming":"2.1.0","rgbww":{"version":"0.8.1","queuesize":100}}
2018.09.27 22:22:53 3: licht.kueche.unterschrank: error EspLedController_ParseBoolResult: {"error":"missing param"}
Habe zu dem Fehler leider nichts richtiges gefunden kennt das jemand? Mit dem browser kann ich ganz normal auf das device zugreifen.
Sieht aus als hättest du nicht die modifizierte Firmware drauf.
Moin,
gibt es eigentlich eine Möglichkeit, dass nach Spannungsversorgung des Controllers das LED Band mit der letzten Farbe eingeschaltet wird? Also ohne ein notify über FHEM oder dergleichen?
Greetz
Eldrik
Zitat von: eldrik am 29 September 2018, 14:48:00
Moin,
gibt es eigentlich eine Möglichkeit, dass nach Spannungsversorgung des Controllers das LED Band mit der letzten Farbe eingeschaltet wird? Also ohne ein notify über FHEM oder dergleichen?
Greetz
Eldrik
Ja, das haben wir vor kurzem hier im Thread besprochen.
Les mal bißchen den Thread. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Naja der Thread hat 50 Seiten... 8)
Kannst du hier konfigurieren:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#startup-color--vbs33
"last" sollte aber eigentlich Standard sein.
Würde schätzen es sind nur 3 max. 4 Seiten zurück. [emoji16]
Standart ist "last" ab FW vbs33. Die ist doch noch im testing branch. Standart die 32. Oder?
Gesendet von meinem Doogee S60 mit Tapatalk
Ja richtig. Guter Hinweis danke: Habe jetzt aus der vbs35b eine vbs35 auf release gemacht.
Aber: die Funktion zum Wiederherstellen des letzten Zustands gabs schon immer.
Zitat von: Frank_Huber am 29 September 2018, 14:52:29
Ja, das haben wir vor kurzem hier im Thread besprochen.
Les mal bißchen den Thread. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Hi,
Hmm hatte eigentlich gehofft gehabt, es so geschrieben zu haben, das deutlich wird, dass ich nicht meine den Controller per on Befehl einzuschalten und das bei gesetzter config von last "ja hab ich bereits gesetzt" dann die letzte Farbe gewählt wird, sondern das die LEDs direkt eingeschaltet werden wenn ich den Controller in die Steckdose stecke oder per Aktor bestrome.
Oder muss ich dafür noch mehr als last setzen?
Habe die vbs35b geflashed.
Greetz
Eldrik
Benutzt du evtl. Raw? Das ganze funktioniert nur für HSV.
Hmm ne nicht wissentlich :D, wähle die Farben bisher ausschließlich per Colorpicker.
In fhem sagt er mir zwar colormode hsv, aber ich habe gerade einfach mal ein set hue 118.01 abgesetzt, den Controller vom Strom genommen, etwas gewartet, das Netzteil wieder eingesteckt, die LEDs werden daraufhin aber nicht automatisch eingeschaltet.
Mach ich etwas falsch oder versteh ich die Funktion von last einfach anders?
Greetz
Eldrik
Hm ist komisch. Poste doch mal ein list. Glaube aber nicht, da viel sehen zu können.
Gern,
Internals:
DEF 10.0.83.220
DeviceName 10.0.83.220:9090
FD 33
IP 10.0.83.220
LAST_RECV 1538239096.72533
NAME rgb_espledcontroller_1
NR 1364
NTFY_ORDER 50-rgb_espledcontroller_1
PARTIAL
PORT 9090
STATE opened
TYPE EspLedController
OLDREADINGS:
READINGS:
2018-09-29 17:47:24 colorMode hsv
2018-09-29 17:43:54 config-color-brightness-blue 100
2018-09-29 17:43:54 config-color-brightness-cw 100
2018-09-29 17:43:54 config-color-brightness-green 100
2018-09-29 17:43:54 config-color-brightness-red 100
2018-09-29 17:43:54 config-color-brightness-ww 100
2018-09-29 17:43:54 config-color-colortemp-cw 6000
2018-09-29 17:43:54 config-color-colortemp-ww 2700
2018-09-29 17:43:54 config-color-hsv-blue 0
2018-09-29 17:43:54 config-color-hsv-cyan 0
2018-09-29 17:43:54 config-color-hsv-green 0
2018-09-29 17:43:54 config-color-hsv-magenta 0
2018-09-29 17:43:54 config-color-hsv-model 0
2018-09-29 17:43:54 config-color-hsv-red 0
2018-09-29 17:43:54 config-color-hsv-yellow 0
2018-09-29 17:43:54 config-color-outputmode 2
2018-09-29 17:43:54 config-color-startup_color last
2018-09-29 17:43:54 config-events-color_interval_ms 500
2018-09-29 17:43:54 config-events-color_mininterval_ms 500
2018-09-29 17:43:54 config-events-server_enabled 1
2018-09-29 17:43:54 config-events-transfin_interval_ms 1000
2018-09-29 17:43:54 config-general-device_name rgb_espledcontroller_1
2018-09-29 17:43:54 config-general-pin_config 13,12,14,5,4
2018-09-29 17:43:54 config-network-ap-password rgbwwctrl
2018-09-29 17:43:54 config-network-ap-secured 0
2018-09-29 17:43:54 config-network-ap-ssid RGBWW9180849
2018-09-29 17:43:54 config-network-connection-dhcp 1
2018-09-29 17:43:54 config-network-connection-gateway 0.0.0.0
2018-09-29 17:43:54 config-network-connection-ip 0.0.0.0
2018-09-29 17:43:54 config-network-connection-netmask 0.0.0.0
2018-09-29 17:43:54 config-network-mqtt-enabled 1
2018-09-29 17:43:54 config-network-mqtt-password
2018-09-29 17:43:54 config-network-mqtt-port 1883
2018-09-29 17:43:54 config-network-mqtt-server 10.0.81.55
2018-09-29 17:43:54 config-network-mqtt-topic_base home/
2018-09-29 17:43:54 config-network-mqtt-username
2018-09-29 17:43:54 config-ota-url http://rgbww.dronezone.de/testing/version.json
2018-09-29 17:43:54 config-security-api_secured 0
2018-09-29 17:43:54 config-sync-clock_master_enabled 0
2018-09-29 17:43:54 config-sync-clock_master_interval 30
2018-09-29 17:43:54 config-sync-clock_slave_enabled 0
2018-09-29 17:43:54 config-sync-clock_slave_topic home/led1/clock
2018-09-29 17:43:54 config-sync-cmd_master_enabled 0
2018-09-29 17:43:54 config-sync-cmd_slave_enabled 0
2018-09-29 17:43:54 config-sync-cmd_slave_topic home/led1/command
2018-09-29 17:43:54 config-sync-color_master_enabled 0
2018-09-29 17:43:54 config-sync-color_master_interval_ms 0
2018-09-29 17:43:54 config-sync-color_slave_enabled 0
2018-09-29 17:43:54 config-sync-color_slave_topic home/led1/color
2018-09-29 17:47:24 ct 0
2018-09-29 17:47:24 hsv 118.01,90.03,0
2018-09-29 17:47:24 hue 118.01
2018-09-26 20:17:47 info-connection-dhcp 1
2018-09-26 20:17:47 info-connection-gateway 10.0.83.1
2018-09-26 20:17:47 info-connection-ip_address 10.0.83.220
2018-09-26 20:17:47 info-connection-mac 5ccf7f8c16b1
2018-09-26 20:17:47 info-connection-netmask 255.255.255.0
2018-09-26 20:17:47 info-connection-ssid iot_homeautomation_eg
2018-09-26 20:17:47 info-current_rom_slot 1
2018-09-26 20:17:47 info-deviceid 9180849
2018-09-26 20:17:47 info-event_num_clients 2
2018-09-26 20:17:47 info-firmware vbs35b
2018-09-26 20:17:47 info-heap_free 19360
2018-09-26 20:17:47 info-sming_version 3.5.1
2018-09-26 20:17:47 info-uptime 457800
2018-09-26 20:17:47 info-webapp_version 0.3.3-shojo7
2018-09-29 17:47:24 pct 0
2018-09-29 17:47:24 raw_blue 0
2018-09-29 17:47:24 raw_cw 0
2018-09-29 17:47:24 raw_green 0
2018-09-29 17:47:24 raw_red 0
2018-09-29 17:47:24 raw_ww 0
2018-09-29 17:47:24 rgb 000000
2018-09-29 17:47:24 sat 90.03
2018-09-26 20:17:29 state opened
2018-09-29 17:47:24 stateLight off
2018-09-23 00:28:22 tranisitionFinished Rainbow,finished
2018-09-29 17:47:24 val 0
helper:
isBusy 0
oldVal 100
cmdQueue:
lastCall:
NAME
addr http://10.0.83.220:80
auth 0
buf
code 200
compress 1
conn
data {"d":"1","t":700,"q":"single","cmd":"fade","hsv":{"s":"+0","h":"+0","v":0}}
displayurl http://10.0.83.220/color
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host 10.0.83.220
httpheader HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 16
Connection: keep-alive
Server: HttpServer/Sming
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
loglevel 5
method POST
path /color
protocol http
redirects 0
timeout 30
url http://10.0.83.220/color
cmd:
cmd fade
d 1
q single
t 700
hsv:
h +0
s +0
v 0
hash:
sslargs:
Attributes:
room Wohnzimmer
webCmd rgb:on:off
widgetOverride rgb:colorpicker,rgb
Greetz
Eldrik
Moin. Einer meiner Controller verweigert sich strikt dem ota update. @ VBS würdest du mit fettige Flash datein für den 35er release erstellen können? Danke
Gesendet von meinem SM-G930F mit Tapatalk
Alle fettigen Dateien liegen auf dem Webserver neben der version.json.
Haha scheiß textkorrektur. Ok Top danke.
Gesendet von meinem SM-G930F mit Tapatalk
@eldrik
Sorry, hab da erstmal keine gute Idee zu deinem Problem. Der Mechanismus ist eigentlich recht simpel. Keine Ahnung was da schief gehen soll. Vermutlich entweder etwas extrem einfaches (um nicht zu sagen blödes), oder etwas sehr komplexes xD
Wohin werden denn die "last" values geschrieben?
Evtl gibt es ja da einen Schreibschutz oder dergleichen.
Gesendet von meinem Doogee S60 mit Tapatalk
Das wird ganz normal wie die restliche Config im SPIFFS Dateisystem abgelegt. Ist alles eine Config-Datei. Da die restliche Config offenbar korrekt gespeichert wird (IP und so), scheint das grundsätzlich zu funktionieren. :-\
Hi,
sehr kurios, aber ich glaube den Kniff gefunden zu haben.
Wenn ich via fhem ein off an den Controller sende, den Netzstecker ziehe und wieder einstecke, bleiben die LEDs aus.
Wenn ich den Controller per fhem auf eine Farbe einstelle, das Netzteil ziehe und wieder einstecke starten die LEDs mit der letzten Farbe :o
Wahrscheinlich total einleuchtend? Ich hätte aber irgendwie ein anderes Verhalten erwartet ???
Wie macht ihr das oder setzt ihr eine default Farbe und verwendet keiner last in Kombination mit fhem?
Greetz
Eldrik
Hmpf ja, meiner Meinung nach tatsächlich ziemlich logisch das Verhalten...
Passt leider irgendwie nicht zu deiner Beschreibung von gestern, oder?
Zitat von: eldrik am 29 September 2018, 17:52:45
In fhem sagt er mir zwar colormode hsv, aber ich habe gerade einfach mal ein set hue 118.01 abgesetzt, den Controller vom Strom genommen, etwas gewartet, das Netzteil wieder eingesteckt, die LEDs werden daraufhin aber nicht automatisch eingeschaltet.
Hätte ich mir vermtl einiges an Sucherei sparen können. :o
Zitat von: vbs am 01 Oktober 2018, 19:29:24
Hmpf ja, meiner Meinung nach tatsächlich ziemlich logisch das Verhalten...
Passt leider irgendwie nicht zu deiner Beschreibung von gestern, oder?
Hätte ich mir vermtl einiges an Sucherei sparen können. :o
Das einzige was ich zwischen diesem expliziten Set hue Beispiel (vorher hatte ich immer per Colorpicker gewählt und das Netzteil aus und wieder eingesteckt) und dem jetzt erfolgreichen Test noch gemacht habe ist, dass ich einmal den clr Button des Controllers gedrückt und den Controller neu ins Netzwerk aufgenommen habe.
Danach scheint es nun tatsächlich zu funktionieren.
Ich habe noch einen zweiten Controller, der das gleiche Verhalten zeigt, mit diesem werde ich das ganze erneut testen.
Greetz
Eldrik
Zitat von: eldrik am 01 Oktober 2018, 18:33:16
Wahrscheinlich total einleuchtend? Ich hätte aber irgendwie ein anderes Verhalten erwartet ???
Was hättest du denn erwartet wenn nicht das?
Gesendet von meinem Doogee S60 mit Tapatalk
Als Endanwender hätte ich das gleiche Verhalten erwartet wie bei einem manuellen on, dass der Controller dann die letzte von mir gewählte Farbe wiedergibt und diese Funktion nicht dadurch beeinträchtigt/limitiert wird, dass man den Controller vorher sanft per off ausgeschaltet hat.
Softwareseitig mag das ja durchaus nachvollziehbar sein als Endanwender schaltet man den Controller einfach aus und übermittelt dabei gedanklich keine neue Farbe.
Greetz
Eldrik
Naja, der Controller hat kein off.
Das ws du mit off meinst ist alle Farben auf Null ziehen.
Und so startet er dann auch wieder.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 02 Oktober 2018, 06:20:26
Naja, der Controller hat kein off.
Das ws du mit off meinst ist alle Farben auf Null ziehen.
Und so startet er dann auch wieder.
Gesendet von meinem Doogee S60 mit Tapatalk
Ja genau an dem Punkt bin ich dann ja Softwaretechnisch auch gelandet und konnte es mir erklären ;) der Endanwender sieht aber weiterhin nur das off.
@vbs wäre es denn nicht möglich dies abzufangen? Sprich wenn last gesetzt und off bzw "schwarz" als Aktion erfolgt dann behalte den zuletzt gespeicherten Farbwert (der scheint ja auch noch vorhanden zu sein wenn man den Controller per on ansteuert)?
Greetz
Eldrik
Ich glaube, du denkst zu kompliziert. Es ist ziemlich straightforward: der Controller stellt einfach beim Booten den zuletzt bekannten Zustand wieder her. Mehr ist es nicht.
Kann man natürlich alles ändern, aber ich höre tatsächlich zum ersten Mal, dass da jemand ein anderes als das z.Zt. implementierte Verhalten erwartet.
Ich vor allem leider immer noch nicht Verstanden, was jetzt die Lösung für das anfängliche Problem war...
Zitat von: vbs am 02 Oktober 2018, 09:51:18
Ich glaube, du denkst zu kompliziert. Es ist ziemlich straightforward: der Controller stellt einfach beim Booten den zuletzt bekannten Zustand wieder her. Mehr ist es nicht.
Kann man natürlich alles ändern, aber ich höre tatsächlich zum ersten Mal, dass da jemand ein anderes als das z.Zt. implementierte Verhalten erwartet.
Mag ja auch sein, dass wenn der Controller anderweitig betrieben wird, man ihn z.B ausschließlich mit einem Schalter ein und ausschaltet und sonst auf eine Steuerung und das explizite ausschalten via fhem verzichtet man nicht in dieses Verhalten hineinläuft.
Ist für mich auch kein Problem an den meisten Controllern werde ich wohl eine feste Farbe eintragen und auf last verzichten.
Ich habe von der Parameterbeschreibung "startup-color" halt etwas anderes erwartet und mich davon in die Irre führen lassen. :)
Zitat von: vbs am 02 Oktober 2018, 09:51:18
Ich vor allem leider immer noch nicht Verstanden, was jetzt die Lösung für das anfängliche Problem war...
Das kann ich dir nicht sagen, den Test mit Farbauswahl tätigen, Stecker ziehen und Wiedereinstecken habe ich diverse Male ausprobiert ohne, dass der Controller mit der Farbe gestartet ist.
Nach dem drücken von clear ist der Controller jedoch das allererste Mal direkt mit der Farbe gestartet und danach dann auch weiterhin.
Ich werde das gleich mal mit meinem zweiten Exemplar ausprobieren!
Edit: der zweite Controller funktioniert wie erwartet!
Greetz
Eldrik
So, melde mich auch mal wieder.
Vorweg eins, es gibt kein Problem. Der produktive Controller läuft stabil mit der vbs35. [emoji1360]
Was ich aber nicht hinbekomme ist ein dauerhafter Farbwechsel. Quasi nen Party-Modus.
Hab das Wiki der Firmware und des Moduls paar mal gelesen, krieg es aber nicht hin. [emoji45]
Von daher wäre nen Schubs in die richtige Richtung sehr willkommen.
Gesendet von meinem Doogee S60 mit Tapatalk
Es ist immer das gleiche, kaum gepostet kommt der Geistesblitz...
Wenn ich von "HSV 0,0,100" aus kommend den "HUE +359 120 lqr:Rainbow" absetze passiert natürlich nichts. Bin ja bei saturation Null. Nur weis. *facepalm*
Geh ich zuerst auf 0,100,100 und dann in den Wechsler geht es wie es soll. Hätte ich früher drauf kommen sollen. [emoji56]
Danke! [emoji16][emoji16][emoji16]
Gesendet von meinem Doogee S60 mit Tapatalk
Ich frag noch mal ganz doof - warum selber löten wenn es fertige H801 RGB Controller gibt;
Kann man die Firmware so weit verkleinern das sie auf einem 1Mb EEPROM läuft?
Hi,
weil die Verarbeitung besser ist
weil man etwas selbst erstellt hat
weil man open source lebt
weil man die Hardwareentwicklung hier im Forum supporten will
weil ... ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Und weil der H801 nur 96W kann.
Gesendet von meinem Doogee S60 mit Tapatalk
Moin,
Es gibt auch H801 mit 512k, da muss man schon reinschauen ;-)
Ich meine es gab mal einen Port auf 1024k und H801, such mal im Forum.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Nabend,
gibt es eigentlich irgend eine Möglichkeit die Sache auch auf eine LAN Version zu portieren? Also ein AVR mit LAN. Oder könnte man ein ein Adapter bauen der das von LAN auf die serielle des ESP umsetzt? (Gibt es ja auch schon fertig solche Terminal Adapter)
Nicht nur das ich kein Funk in meinem Schafzimmer haben möchte, aber auch WPA2 gebe ich nicht mehr all zu lang. Da würde ich schon gerne auf der sicheren Seite sein.
Wurden da schon mal Gedanken geführt? Ich hatte das glaube schon mal angesprochen aber so richtig war das da nicht aktuell.
/Daniel
Hab mich damit noch nicht beschäftigt, aber ich vermute, dass du einen größeren Aufwand für solch einen Wechsel der Plattform einplanen müsstest, da einfach viele Sachen an der Sming-API hängen.
Achso und das ist so ein ESP Thema ja?
OK dann kann man das ja schon mal vom Tisch wischen. Wie schaut es dann mit der UART aus? Wenn man das transparent durchreichen könnte an FHEM (Wo ich technisch kein Problem sehe), geht da was? Also ESP seitig und FHEM Modul seitig? Wie würdest das einschätzen?
Aber ich bin vermutlich der einzige mit solch einer Idee. Aber mit PoE zusammen spart man sich an der ein oder anderen Stelle dann auch das Netzteil.
/Daniel
Du müsstest die HTTP-Kommunikation auf beiden Seiten von TCP auf Seriell umbiegen. Könnte mir vorstellen, dass das möglich ist.
Ich habe bei mir für meine Controller mit RGB+WW 4in1 LED-Stripe ein cmdalias geschrieben, welches mit Hilfe einer Kalibrationskurve sehr exakt einen Farbtemperaturverlauf in einem beliebigen Intervall durchführen kann. Soweit ich weiß, unterstützt der Controller in seiner aktuellen Form nur einen Temperaturwechsel wenn WW + CW Leuchtmittel vorhanden sind.
Das cmdalias habe ich hier beschrieben: https://forum.fhem.de/index.php/topic,91967.0.html (https://forum.fhem.de/index.php/topic,91967.0.html)
Was dort bisher noch nicht funktioniert ist das update des "ct" readings des Moduls.
Ich würde mich freuen, wenn man das ganze auf dem Controller durchführen könnte. Eventuell könnte man die Parameterberechnung in FHEM durchführen und sie dem Controller übergeben, um die vermutlich nicht signifikante Rechenarbeit auszulagern. Die Kalibrierung könnte über 4 Komma-getrennte Attribute für jeden Kanal realisiert werden.
Ich kenne mich leider nur begrenzt mit Perl bzw der Sming-API aus, würde aber so weit mir möglich ist gerne dabei helfen.
Zumindest bei mir kann die Farbwiedergabe sehr gut mit Philips HUE E27 Leuchtmitteln mithalten und sogar über deren Temperaturbereich hinaus Weißtöne wiedergeben.
Lg
Fabian
Zitat von: vbs am 16 Oktober 2018, 14:57:59
Du müsstest die HTTP-Kommunikation auf beiden Seiten von TCP auf Seriell umbiegen. Könnte mir vorstellen, dass das möglich ist.
Und wie schaut es mit einem LAN Chip aus? Beim ESP8266 könnte man ja mit einem "ENC28J60" ein LAN hinzufügen.
Würde deine Firmware auch auf dem ESP32 laufen? Dieser hat nämlich LAN schon mit drin bis auf den physical layer (http://s.click.aliexpress.com/e/JyrF2zB). Könnte man das über diesen Weg eventuell realisieren?
https://hackaday.com/2017/04/18/enabling-ethernet-on-the-esp32/
/Daniel
@Pythonf
Finde ich eine sehr interessante Sache. Irgendjemand hatte sowas vor einiger Zeit auch schonmal gepostet (warst evtl. auch du).
Ich glaube zu verstehen, wie deine Variante die Farbtemperatur für ein reines Weiß setzt. Aber wie würdest du dir die Integration in die bestehende Firmware vorstellen? Normalerweise arbeitet die FW im HSV-Modus eben um auch Farben dar zu stellen.
@ext23
Soweit ich weiß, läuft Sming momentan nicht auf Esp32:
https://github.com/SmingHub/Sming/issues/1333
Zu der LAN-Integration kann ich ansonsten nciht viel sagen, sorry...
Zitat von: vbs am 17 Oktober 2018, 12:45:18
Soweit ich weiß, läuft Sming momentan nicht auf Esp32:
https://github.com/SmingHub/Sming/issues/1333
Mhh hat das Sming auch irgend welche Vorteile ;-)
Aber gut, es scheint ja auch schon der Gedanke da zu sein es auf ein Arduino zu portieren. Das ist ja schon mal was.
/Daniel
Ich schätze, das war auch ich. Ich finde das Thema Farbtemperatur irgendwie sehr spannend.
Für die Farbübergänge von bsp. Rot nach Weiß würde ich alles belassen wie es ist.
Sollte dann die Farbtemperatur, welche nur bei der ausschließlichen Darstellung von weißem Licht interessant sein dürfte, per "set <name> ct ...." geändert werden, dann könnte man vielleicht intern den Modus von RGBWW auf RGB ändern, die berechneten Werte für RGB in hsv umrechnen und den Wert für die WW-LED parallel nur an den WW Kanal senden.
Diese Umstellung wäre ja auch nur interessant wenn RGBWW oder RGBCW ausgewählt sind, denn hier hat der "set <name> ct ...." bislang ja keinen Effekt. Bei RGB wäre die Änderung der Farbtemperatur in der Theorie zwar auch möglich, erscheint mir aber wenig sinnvoll und bei RGBWWCW würde ich ebenfalls alles belassen wie es ist.
Man müsste im Reading nicht mal festlegen, ob es sich um WW, NW oder CW handelt.
Ich stell mir das in etwa so vor:
attr dev cal_r comma seperated list of measured values for the red led in cooperation with measured values for blue, green and white LEDs (attributes cal_b, cal_g, cal_w).
attr <name> cal_r <1st color_temp_in_Kelvin><1st Value for raw_red or value for red>,<1nd color_temp_in_Kelvin><1nd Value for raw_red or value for red>, ... ,<n color_temp_in_Kelvin><n Value for raw_red or value for red>
attr dev cal_r 2000:1023,3000:768,4000:512,5000:256
Lg
Fabian
Zitat von: Pythonf am 17 Oktober 2018, 13:20:30
Für die Farbübergänge von bsp. Rot nach Weiß würde ich alles belassen wie es ist.
Sollte dann die Farbtemperatur, welche nur bei der ausschließlichen Darstellung von weißem Licht interessant sein dürfte, per "set <name> ct ...." geändert werden, dann könnte man vielleicht intern den Modus von RGBWW auf RGB ändern, die berechneten Werte für RGB in hsv umrechnen und den Wert für die WW-LED parallel nur an den WW Kanal senden.
Die Farbtemperatur spielt mMn nicht nur bei komplett "weißem" Licht eine Rolle, sondern immer dann wenn Sättigung <100% ist. Das sind ja fließende Übergänge. Z.B. ich hab reines Weiß und gebe dann 5 % rot dazu. Was würde dann passieren im Rahmen des aktuellen HSV-Modells?
Wie erstellt man eigentlich diese Kalibrationstabelle? Ich muss ja z.B. meine RGBWW-Werte ermitteln, die dann z.B. 2675 Kelvin ergeben, richtig? Und das mache ich für mehrere Stützstellen und lege eine Kurve da durch. Aber wie ermittle ich 2765 Kelvin?
Zitat von: vbs am 18 Oktober 2018, 09:24:17
Wie erstellt man eigentlich diese Kalibrationstabelle? Ich muss ja z.B. meine RGBWW-Werte ermitteln, die dann z.B. 2675 Kelvin ergeben, richtig? Und das mache ich für mehrere Stützstellen und lege eine Kurve da durch. Aber wie ermittle ich 2765 Kelvin?
Ich habe in meinem Fall eine Philips HUE als Referenz genommen und dort verschiedene Farbtemperaturen angegeben und die LEDs dem jeweiligen Weißton angepasst. Wenn das nicht geht, dann könnte man aber auch einfach einen Wert bei beispielsweise 2000K für warmes Licht, 4000K für neutral und 7000K für kaltes Licht nach persönlichem Wohlbefinden, annehmen. Die Berechnung von beispielsweise 3000K erfolgt dann durch einsetzten in die die vier generierten Funktionen vom Typ 'a + b * x + c * x^2' mit x = ct für jeden Kanal, welche mir dann die RGB + W Werte liefert.
Das die Farbtemperaturwerte mehr eine Schätzung sind, stört m. M. nach nur wenig. Ich seh weder bei den HUE noch bei den LEDs einen wirklich sichtbaren Unterschied zwischen 3100 K und 2900 K. Und wenn ich ein ramping durch die Farbtemperatur bei den HUE bzw. bei den LEDs mache, lässt sich für mich an keiner Stelle (2000 < ct < 6500) ein Unterschied ausmachen
Zitat von: vbs am 18 Oktober 2018, 09:24:17
Die Farbtemperatur spielt mMn nicht nur bei komplett "weißem" Licht eine Rolle, sondern immer dann wenn Sättigung <100% ist. Das sind ja fließende Übergänge. Z.B. ich hab reines Weiß und gebe dann 5 % rot dazu. Was würde dann passieren im Rahmen des aktuellen HSV-Modells?
Im Moment fällt mir dazu keine Lösung ein. Ich hätte angenommen, dass komplett weißes Licht ausschließlich die WW LEDs sind.
Wie sieht denn hier die Berechnung im RGBWWCW Modus aus? Was wird als komplett weißes Licht festgelegt? Weil hier kann ich ja auch Unterscheiden zwischenem "reinem" CW oder WW ?
Zitat von: Pythonf am 18 Oktober 2018, 10:00:21
Im Moment fällt mir dazu keine Lösung ein. Ich hätte angenommen, dass komplett weißes Licht ausschließlich die WW LEDs sind.
Da ist richtig: bei komplett weißem Licht (Sättigung = 0%) leuchten nur die WW-LEDs im (RGBWW-Modus). Aber eben sobald man die Sättigung erhöht, spielen auch die RGBs mit.
Zitat von: Pythonf am 18 Oktober 2018, 10:00:21
Wie sieht denn hier die Berechnung im RGBWWCW Modus aus? Was wird als komplett weißes Licht festgelegt? Weil hier kann ich ja auch Unterscheiden zwischenem "reinem" CW oder WW ?
Ich hab da noch nie reingeschaut, aber ich denke, dass da je nach Farbtemperatur die Intensität zwischen WW und CW aufgeteilt wird. Sprich wenn du 2700k einstellst bist du bei 100% WW und 0% CW und bei 4500k bei 50% CW und 50% WW (oder ähnlich).
Ich hab mir das ganze mal bei Philips Hue angeschaut:
Wenn ich dort rgb 00FF00 und dann ct 6500 setzte, dann ändert er logischerweise die Farbe zu kaltem weiß. Wenn ich dann die Sättigung reduziere ändert sich aber die Farbe nicht wieder zurück zum rgb Wert, was ich so nicht wirklich schön finde.
Ich würde also, auch wenn es eventuell nicht viel besser erscheint, zwischen ct ausschließlich für Farbtemperatur und hsv für alles andere unterscheiden.
Es wäre auch merkwürdig, wenn ich die ganze Zeit ein schönes Grün gewöhnt bin, dann ändere ich einmal die Farbtemperatur und wenn ich das nächste mal Grün einstelle sieht es ganz anders aus.
Der harte Übergang, der leider nicht ausbleibt wäre dann, wenn ich per ct 2000 K einstelle und dann sage sat 0. Dann würde der Wert vom berechneten Wert für die Farbtemperatur auf RGB = 000000, WW = 255 springen.
Zitat von: Pythonf am 18 Oktober 2018, 11:08:08
Wenn ich dort rgb 00FF00 und dann ct 6500 setzte, dann ändert er logischerweise die Farbe zu kaltem weiß. Wenn ich dann die Sättigung reduziere ändert sich aber die Farbe nicht wieder zurück zum rgb Wert, was ich so nicht wirklich schön finde.
Hm, ist für mich erstmal nicht unbedingt logisch: die Farbtemperatur ist mMn unabhängig vom Rest bzw. von der Sättigung. Darum finde ich es nicht logisch, dass er beim Setzten von ct zu weiss springt. Und ich verstehe nicht warum die Sättigung dann offenbar >0 ist und du sie dann noch reduzieren kannst.
Ich verstehe dich so, dass für dich das Setzen einer Farbtemperatur auch immer implizit das Leuchtmittel auf ein reines Weiß setzt? Ist offenbar bei der Hue so. Wenn das so ist, dann passt das nicht so gut zu der Logik int der FW bzw. so wie zumindest ich das Konzept einer Farbtemperatur verstehe.
Zitat von: vbs am 18 Oktober 2018, 13:55:53
Ich verstehe dich so, dass für dich das Setzen einer Farbtemperatur auch immer implizit das Leuchtmittel auf ein reines Weiß setzt?
Die Farbtemperatur resultiert ja aus der Schwarzkörperstrahlung. Daher impliziert das setzten der Farbtemperatur die Ausgabe von weißem Licht.
https://commons.wikimedia.org/wiki/File:BlackbodySpectrum_loglog_de.svg (https://commons.wikimedia.org/wiki/File:BlackbodySpectrum_loglog_de.svg) Hier wird schön gezeigt, welcher Bereich des sichtbaren Lichtes bei welcher Temperatur emittiert. Die Farbtemperatur der weißen LEDs wiederum sind aber festgelegt auf einen spezifischen Wert. Ein Mischen von einer gesetzten Farbtemperatur für die weißen LEDs mit farbigem Licht würde darin resultieren, dass die Farbtemperatur einer rein weißen Lichtquelle durch beimischen variiert wird und anschließend diese Farbtemperatur/ weißes Licht mit rgb gemischt würde.
Die Logik des Controllers ist mir an dieser Stelle zwar nicht bekannt, aber es scheint mir deutlich zu kompliziert, die Änderung der Farbtemperatur der verbauten weißen LEDs über set ct zum Mischen per hsv zu implementieren ???
Schade eigentlich... wäre schon eine super Feature, aber lässt sich mMn nicht sauber integrieren, solange wir nicht raus finden, wie man das mit dem HSV-Model kombinieren kann :( Der einzige Weg wäre einen dritten Modus einzuführen, der völlig unabhängig läuft und dann eben nur reines Weiß unterstützt... gefällt mir aber nicht so richtig :-X
Falls jemand Lust hat, dort einzusteigen: die momentane Implementierung ist hier zu finden:
https://github.com/verybadsoldier/RGBWWLed/blob/master/RGBWWLedColor.cpp
Ein kurze Frage zu dem Dimmer von Tablet UI
Ich wollte diesen nutzen um das ESP Modul zu dimmen. Schaut dann so aus:
<div data-type="dimmer"
data-device="licht.kueche.unterschrank"
data-dim="hsv 0,0,"></div>
Es wird dann folgendes gesendet wenn ich z.B. auf 10 Prozent Dimme:
set licht.kueche.unterschrank hsv 0,0, 10
Problem ist bei der 10 am Schluss, dass ein Leerzeichen eingefügt wird und ich glaube dann funktioniert das Ganze nicht. Weiss jemand wie ich das umgehen kann?
Ist vermutlich eher eine Tablet-UI-Frage. Kann ich nicht viel zu sagen, aber ich hab gestutzt über
data-dim="hsv 0,0,"Die Tablet-UI Doku sagt dazu (https://wiki.fhem.de/wiki/FTUI_Widget_Dimmer):
Zitatdata-dim Name des Readings, das für den DIM-Wert zuständig ist
Ich würde es dementsprechend mal versuchen mit:
data-dim="val"
Irgendwie mach ich da was falsch.
Was ich bräuchte:
Aktueller Status:
Mit dem Befehl 192.168.1.xx/color?mode im Browser bekomme ich z.B. das:
{"hsv":{"h":0.00,"s":0.00,"v":49.95,"ct":0}}
Das ist aber nicht in den Userreadings vorhanden. Wie bekomme ich das in das reguläre device in FHEM? Bzw. in den state um stateFormat anwenden zu können. Der STATE in den INTERNALS liefert auch nur 1.
Weiterhin mache ich wohl bei dem DIM Befehl etwas falsch. Wenn ich diesen über die Maske in FHEM auswähle und zw. 100 eingebe passiert nichts. Wenn ich das Ganze. Z.B. mit dem Befehl hsv 0,0,100 teste geht die Lampe auf 100%
Weiss hier jemand weiter?
Du musst mich mal irgendwo abholen, ich kann nicht so recht folgen, fürchte ich.
Zitat von: tunguskar am 28 Oktober 2018, 22:55:30
Aktueller Status:
Mit dem Befehl 192.168.1.xx/color?mode im Browser bekomme ich z.B. das:
{"hsv":{"h":0.00,"s":0.00,"v":49.95,"ct":0}}
Das ist aber nicht in den Userreadings vorhanden. Wie bekomme ich das in das reguläre device in FHEM?
Also es gibt u.a. die Readings "hsv" und "ct". Userreadings musst du immer selbst erzeugen.
Zitat von: tunguskar am 28 Oktober 2018, 22:55:30
Bzw. in den state um stateFormat anwenden zu können. Der STATE in den INTERNALS liefert auch nur 1.
Hm, was meinst du? Hast du evtl. selbst schon stateFormat gesetzt und damit selbst die 1 erzeugt? state sollte normalerweise "opened" sein.
Zitat von: tunguskar am 28 Oktober 2018, 22:55:30
Weiterhin mache ich wohl bei dem DIM Befehl etwas falsch. Wenn ich diesen über die Maske in FHEM auswähle und zw. 100 eingebe passiert nichts. Wenn ich das Ganze. Z.B. mit dem Befehl hsv 0,0,100 teste geht die Lampe auf 100%
Hm, Dim sollte funktionieren. Hast du aktuelles Modul? aktuelle Firmware? Ist was im Log zu sehen? Poste mal list und Log bitte.
Zitat von: vbs am 29 Oktober 2018, 16:27:31
Du musst mich mal irgendwo abholen, ich kann nicht so recht folgen, fürchte ich.
Also es gibt u.a. die Readings "hsv" und "ct". Userreadings musst du immer selbst erzeugen.
Hm, was meinst du? Hast du evtl. selbst schon stateFormat gesetzt und damit selbst die 1 erzeugt? state sollte normalerweise "opened" sein.
Hm, Dim sollte funktionieren. Hast du aktuelles Modul? aktuelle Firmware? Ist was im Log zu sehen? Poste mal list und Log bitte.
Also meine Version/en:
2018.10.29 21:30:56 3: licht.kueche.unterschrank: got info response
2018.10.29 21:30:56 3: licht.kueche.unterschrank: info response data {"deviceid":"xxxxxxxx","current_rom":"0","firmware":"0.3.1","git_version":"v0.3.1","git_date":"2016-06-29","config_version":"1","sming":"2.1.0","rgbww":{"version":"0.8.1","queuesize":100},"connection":{"connected":true,"ssid":"homeBase","dhcp":false,"ip":"192.168.1.xx","netmask":"255.255.255.0","gateway":"192.168.1.1","mac":"xxxxxxxxxxxxxx"}}
Komisch ist, dass STATE immer disconnected anzeigt. Obwohl ich mit dem Device reden kann.
Ich habe mir jetzt schon zig Einträge zu den userReadings durchgelesen. Wie würde z.B. ein UserReading aussehen wenn ich nur den Zustand ein/aus und den Dimmstatus über das hsv reading haben möchte?
Zitat von: tunguskar am 29 Oktober 2018, 21:40:30
Also meine Version/en:
2018.10.29 21:30:56 3: licht.kueche.unterschrank: got info response
2018.10.29 21:30:56 3: licht.kueche.unterschrank: info response data {"deviceid":"xxxxxxxx","current_rom":"0","firmware":"0.3.1","git_version":"v0.3.1","git_date":"2016-06-29","config_version":"1","sming":"2.1.0","rgbww":{"version":"0.8.1","queuesize":100},"connection":{"connected":true,"ssid":"homeBase","dhcp":false,"ip":"192.168.1.xx","netmask":"255.255.255.0","gateway":"192.168.1.1","mac":"xxxxxxxxxxxxxx"}}
Komisch ist, dass STATE immer disconnected anzeigt. Obwohl ich mit dem Device reden kann.
Ich habe mir jetzt schon zig Einträge zu den userReadings durchgelesen. Wie würde z.B. ein UserReading aussehen wenn ich nur den Zustand ein/aus und den Dimmstatus über das hsv reading haben möchte?
Verbose 5 und ein Set Dim auf 20
2018.10.29 21:45:55 5: HttpUtils url=http://192.168.1.40:9090/
2018.10.29 21:45:55 4: licht.kueche.unterschrank: unable to connect to LedController: 192.168.1.40: Connection refused
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with dim, busy flag is 0
name is licht.kueche.unterschrank, args $VAR1 = '20';
2018.10.29 21:46:03 5: licht.kueche.unterschrank setting VAL to 20
2018.10.29 21:46:03 5: licht.kueche.unterschrank: called SetHSVColor
2018.10.29 21:46:03 5: licht.kueche.unterschrank: encoded json data: {"hsv":{"v":"20"},"q":"single","cmd":"fade","d":"1","t":"3000"}
2018.10.29 21:46:03 5: licht.kueche.unterschrank: set HSV color request: {"hsv":{"v":"20"},"q":"single","cmd":"fade","d":"1","t":"3000"}
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank: EspLedController_ParseBoolResult
2018.10.29 21:46:03 3: licht.kueche.unterschrank: error EspLedController_ParseBoolResult: {"error":"missing param"}
2018.10.29 21:46:04 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 0
name is licht.kueche.unterschrank, args
Zitat von: tunguskar am 29 Oktober 2018, 21:47:41
Verbose 5 und ein Set Dim auf 20
2018.10.29 21:45:55 5: HttpUtils url=http://192.168.1.40:9090/
2018.10.29 21:45:55 4: licht.kueche.unterschrank: unable to connect to LedController: 192.168.1.40: Connection refused
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with dim, busy flag is 0
name is licht.kueche.unterschrank, args $VAR1 = '20';
2018.10.29 21:46:03 5: licht.kueche.unterschrank setting VAL to 20
2018.10.29 21:46:03 5: licht.kueche.unterschrank: called SetHSVColor
2018.10.29 21:46:03 5: licht.kueche.unterschrank: encoded json data: {"hsv":{"v":"20"},"q":"single","cmd":"fade","d":"1","t":"3000"}
2018.10.29 21:46:03 5: licht.kueche.unterschrank: set HSV color request: {"hsv":{"v":"20"},"q":"single","cmd":"fade","d":"1","t":"3000"}
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:46:03 5: licht.kueche.unterschrank: EspLedController_ParseBoolResult
2018.10.29 21:46:03 3: licht.kueche.unterschrank: error EspLedController_ParseBoolResult: {"error":"missing param"}
2018.10.29 21:46:04 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 0
name is licht.kueche.unterschrank, args
Nun das Ganze Off schalten:
2018.10.29 21:48:51 5: licht.kueche.unterschrank (Set) called with off, busy flag is 0
name is licht.kueche.unterschrank, args
2018.10.29 21:48:51 5: licht.kueche.unterschrank: called SetHSVColor
2018.10.29 21:48:51 5: licht.kueche.unterschrank: encoded json data: {"cmd":"fade","q":"single","hsv":{"h":"+0","s":"+0","v":0},"t":"3000","d":"1"}
2018.10.29 21:48:51 5: licht.kueche.unterschrank: set HSV color request: {"cmd":"fade","q":"single","hsv":{"h":"+0","s":"+0","v":0},"t":"3000","d":"1"}
2018.10.29 21:48:51 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:48:51 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:48:51 5: licht.kueche.unterschrank (Set) called with ?, busy flag is 1
name is licht.kueche.unterschrank, args
2018.10.29 21:48:51 5: licht.kueche.unterschrank: EspLedController_ParseBoolResult
2018.10.29 21:48:51 5: licht.kueche.unterschrank: EspLedController_ParseBoolResult success
2018.10.29 21:48:57 5: HttpUtils url=http://192.168.1.40:9090/
2018.10.29 21:48:58 4: licht.kueche.unterschrank: unable to connect to LedController: 192.168.1.40: Connection refused
Zitat von: tunguskar am 29 Oktober 2018, 21:40:30
2018.10.29 21:30:56 3: licht.kueche.unterschrank: info response data {"deviceid":"xxxxxxxx","current_rom":"0","firmware":"0.3.1","git_version":"v0.3.1","git_date":"2016-06-29","config_version":"1","sming":"2.1.0","rgbww":{"version":"0.8.1","queuesize":100},"connection":{"connected":true,"ssid":"homeBase","dhcp":false,"ip":"192.168.1.xx","netmask":"255.255.255.0","gateway":"192.168.1.1","mac":"xxxxxxxxxxxxxx"}}
Du hast ja gar nicht die Alternativ-Firmware drauf, sondern offenbar die "klassische" Original-FW 0.3.1. Darum werden alle erweiterten Funktionen hier aus dem Thread nicht funktionieren. Ist das Absicht? Update doch mal, ansonsten werden die Funktionen hier aus dem Thread nicht funktionieren.
Oh man jo das wars, Asche auf mein Haupt. Dank dir!
Hallo,
ich hab mal eine Frage (ich habe gesucht, soweit ich konnte, hab aber auch nicht den ganzen Thread durchgelesen...):
Ich hab die Hardware mit einem NodeMCU auf dem Steckbrett nachgebaut, als reiner RGB-Controller. Soweit funktioniert es auch (Pinbelegung musste angepasst werden). Nun die Frage: Ist es normal, dass nach dem Einschalten der Spannungsversorgung immer 1,2 verschiedene Farben aufblinken, bevor die zuletzt eingestellte wieder hergestellt wird? Oder kann das an meiner abweichenden Hardware liegen?
Den Effekt habe ich bei mir so nie beobachtet.
Ich habe die erste Version des Moduls.
Hm nee, normal ist das auf jeden Fall nicht. Klappt denn der Rest?
Danke für die Antworten. Ich bin noch am Anfang des Testens. Farbeinstellung über das Webinterface klappt - beim Farbpicker direkt und bei den Reglern, sobald man mit dem Häkchen bestätigt.
Dann mache ich mich noch mal auf die Suche. Vielleicht hab ich einen Fehler bei den Pulldown-Widerständen und er fängt sich erstmal irgendeine Spannung, solange der ESP noch nicht läuft...
Hallo,
ich bin auf der Suche nach einem neuen/besseren LED-Controller auf dieses Projekt gestoßen und würde gern ein paar Fragen stellen, bevor ich wirklich welche bestelle. Sorry alls die Fragen schon mal beantwortet wurden aber dieser Thread hier ist mit 50+ Seiten noch einer der kürzesten zu dem Controller.... Daher mea culpa dass ich nicht alles gelesen hab.
Aktuell hab ich ein LED-Ufo im Zusammenspiel mit dem WifiLightmodul im Einsatz und dieses tut auch seinen Job. Allerdings sind ein- und ausdimmen sehr grob. Das LED-Band beleuchtet meine TV-Ecke indirekt und reagiert auf das Einschalten des TV. das Hochdimmen kommt mir aber eher vor wie ein Schalten in 4 Stufen und nicht wie ein schöner, weicher gleichmäßiger Übergang.
Geht sowas mit dieser Geräte-Modul-Kombination besser? Gleiche Frage habe dann nachher zu Farbwechselprogrammen. Für mich wäre das das Hauptkriterium mir einen neuen Controller zuzulegen.
Eine Frage zu den WW-Kanälen: Werden diese auch gedimmt oder ist das "nur" ein/aus. Einen zweiten Controller würde ich in einer abgehängten Decke verbauen und dort einen der WW-Ausgänge nutzen um über ein Relais die normale Beleuchtung ein zuschalten. Die RGB-Ausgänge sind dann wiederum für die indirekte Beleuchtung.
Grüße, Stephan
Alle Kanäle werden gleichberechtigt behandelt. Also es wird da kein Unterschied zwischen Weiß- oder Farb-Kanälen gemacht. Und ja, die Übergänge sind für mein Empfinden sehr weich. Sprünge konnte ich da noch keine feststellen.
Sehr weiches fading. Und ist einstellbar. Ist top
Gesendet von meinem SM-G930F mit Tapatalk
ZitatEinen zweiten Controller würde ich in einer abgehängten Decke verbauen und dort einen der WW-Ausgänge nutzen um über ein Relais die normale Beleuchtung ein zuschalten
Könnte man so machen, aber warum nicht einfach einen anderen GPIO des ESP nutzen?
Die Firmware regelt ja auch zwischen farbig / also RGB, und Weiss, in Deinem Fall eher nur RGB einstellen und das normale Licht über einen getrennten GPIO
Grüße
Klaus
Kann ich nur bestätigen.
Butterweiches und sauberes fading. Ob dimmen oder Farbwechsel. Auch über sehr lange Zeiträume in einer CueList.
Ich habe auch schon drei gebaut und als UFO Upgrade eingesetzt.
Das schöne ist eben auch das die fadings in der Hardware abgearbeitet werden und nicht jede Dimmstufe von Fhem neu gesendet werden muß wie beim UFO.
Großes Lob
@Skusi:
super genau das wollte ich hören. Freu mich schon drauf die Controller bei mir im Einsatz zu haben.
@Klaus0815:
Könnte man natürlich auch machen aber ehrlich gesagt ist es eine Aufwands-nutzen-Abwägung.
Nehme ich den Controller mit RGBWW brauche ich nur das zusätzliche Relais und muss aufpassen, dass ich den entsprechenden Kanal nicht dimme.
Nehme ich einfach einen anderen Pin muss ich an der Firmeware rumpfuschen und ggf. auch am FHEM-Modul was ändern. Den Aufwand dafür kann ich aktuell überhauptnicht abschätzen, da ich beides bisher nicht kenne. Die Möglichkeit des einfachen Updates geht mir möglicherweise auch verloren, da ich die Anpassungen dann jedes Mal wieder machen müsste.
Hardware-seitiges gewinne ich auch nichts - im Gegenteil. Ich benötige extren das Relais+Seitenbeschaltung und den Mosfet+Seitenbeschaltung, wobei letzteres ja schon auf der Platine vorhanden ist.
Ich sehe da keinen Vorteil bei der Pin-Variante - nur zusätzlich Arbeit.
Gesendet von iPhone mit Tapatalk
ZitatNehme ich einfach einen anderen Pin muss ich an der Firmeware rumpfuschen
Nein, genau das musst Du nicht :-)
Ich verstehe es so das Du RGB als Effektlicht willst und zusätzlich über Relais das vorhandene Licht steuern?
Du willst jetzt einfach den WW-Kanal nutzen um das Relais zu steuern?
Du kannst mit dem Sketch hier WW nicht getrennt steuern, schwer zu erklären, bau es Dir am Besten mal mit einem Stück RGBW LED-Strip auf
Wenn Du von z.B. rot auf weiss wechselst werden die RGB-LEDs immer dunkler, die WW immer heller
Du musst da auch nichtsin FHEM oder sonst wo ändern, das eine ist dann halt der RGBWW-Controller für Dein LED-Strip, das andere ist der GPIO für Licht, Kaffeemaschine, ....
Zitat von: Klaus0815 am 22 November 2018, 22:54:38
Nein, genau das musst Du nicht :-)
Ich verstehe es so das Du RGB als Effektlicht willst und zusätzlich über Relais das vorhandene Licht steuern?
Genau - so war mein Plan. Effektlicht und "normale" Deckenbeleuchtung - getrennt geschalten.
ZitatDu willst jetzt einfach den WW-Kanal nutzen um das Relais zu steuern?
Du kannst mit dem Sketch hier WW nicht getrennt steuern,
Hm... okay. Dann habe ich die Antwort von vbs falsch interpretiert. Ich hatte angenommen, das "gleichberechtigt" auch unabhängig heißt.
ZitatDu musst da auch nichtsin FHEM oder sonst wo ändern, das eine ist dann halt der RGBWW-Controller für Dein LED-Strip, das andere ist der GPIO für Licht, Kaffeemaschine, ....
Heißt das, dass grundsätzlich alle GPIOs über das Modul geschaltet werden können? Wie gesagt ich habe noch keinen Controller hier, um mich tiefer damit zu befassen.
Gesendet von iPhone mit Tapatalk
ZitatHeißt das, dass grundsätzlich alle GPIOs über das Modul geschaltet werden können?
Ja, es ist ein ganz normales ESPEasy, halt mit dem RGBWW Plugin
Du könntest z.B. auch einen Temperatursensor, Display, Servomotor,... zusätzlich anschließen, musst es halt im Webinterface definieren
ZitatWie gesagt ich habe noch keinen Controller hier, um mich tiefer damit zu befassen.
Bastle erst mal so mit einem rum, um ein besseres Verständniss dafür zu bekommen, Du wirst geschockt sein wie viele Möglichkeiten Du damit hast :-)
Zitat von: Klaus0815 am 22 November 2018, 23:18:46
Ja, es ist ein ganz normales ESPEasy, halt mit dem RGBWW Plugin
Du könntest z.B. auch einen Temperatursensor, Display, Servomotor,... zusätzlich anschließen, musst es halt im Webinterface definieren
Bastle erst mal so mit einem rum, um ein besseres Verständniss dafür zu bekommen, Du wirst geschockt sein wie viele Möglichkeiten Du damit hast :-)
Nunja, ich wusste nicht, dass die hier beschriebene Firmware eigentlich ESPEasy ist. Ich dachte es wäre eher ein eigens geschriebener Sketch.
Ich komme zwar eher aus der Tasmota-Ecke aber da ergeben sich natürlich völlig neue Möglichkeiten.
Danke fürs Aufschlauen [emoji6]
Gesendet von iPhone mit Tapatalk
Die Firmware hier hat mit ESPEasy nichts zu tun.
Du kannst den Controller entweder mit HSV-Daten füttern, die dann automatisch auf die RGBWW/CW-Kanäle umgerechnet werden. Aber du kannst den Controller auch im Raw-Modus nutzen und damit alle fünf Kanäle völlig frei ansteuern.
Die Firmware ist ein Fork von hier:
https://github.com/patrickjahns/esp_rgbww_firmware
Zitat von: vbs am 22 November 2018, 23:42:39
Die Firmware hier hat mit ESPEasy nichts zu tun.
Okay.... dann also doch Custom-firmware.
ZitatDu kannst den Controller entweder mit HSV-Daten füttern, die dann automatisch auf die RGBWW/CW-Kanäle umgerechnet werden. Aber du kannst den Controller auch im Raw-Modus nutzen und damit alle fünf Kanäle völlig frei ansteuern.
Die Firmware ist ein Fork von hier:
https://github.com/patrickjahns/esp_rgbww_firmware
Ist ein Mischbetrieb möglich?
Also Effektlicht per RGB-Betrieb und das schalten des WW- oder CW-Kanals per RAW-Befehle?
Gesendet von iPhone mit Tapatalk
oh, sorry, hab das gerade total verwechselt, wohl zu viele verschiedene Themen abonniert
Hatte jetzt an das hier gedacht:
https://forum.fhem.de/index.php?topic=63622.0 (https://forum.fhem.de/index.php?topic=63622.0)
nichts für ungut
Klaus
Zitat von: balli1187 am 22 November 2018, 23:50:36
Ist ein Mischbetrieb möglich?
Also Effektlicht per RGB-Betrieb und das schalten des WW- oder CW-Kanals per RAW-Befehle?
Bin mir nicht sicher, ob ich genau verstehe was du meinst, aber du kannst z.B. aus FHEM heraus so *nur* die RGB-Kanäle steuern:
set myLed raw 367,368,369,,Setzt R auf 367, G auf 368 und B auf 369. Beachte die Auslassung der letzten beiden Kanäle durch die beiden leeren Kommas -> WW- und CW-Kanal bleiben unverändert.
set myLed raw ,,,1023,1023Setzt WW und CW auf 1023 und lässt die Kanäle R, G und B unverändert.
Der Controller kann jedoch immer nur komplett im HSV- _oder_ im Raw-Modus sein.
Zitat von: vbs am 22 November 2018, 23:59:12
Der Controller kann jedoch immer nur komplett im HSV- _oder_ im Raw-Modus sein.
Das war die Frage. Ich nehme mal an, dass im RAW-Modus die Funktionen wie fade und Programme nicht unterstützt werden, da die Kanäle separat angesprochen werden, oder geht das trotzdem?!
Wird das bei der Definition oder gar direkt im Controller festgelegt oder beschränkt es sich auf das absetzen von befehlen?
Gesendet von iPhone mit Tapatalk
RAW ist nur ein Weg, über die API mit dem Controller zu sprechen. Dabei werden alle Mechanismen der Firmware (Farbmodell, fading etc) umgangen und direkt der Wert der PWM Kanäle gesetzt, weshalb die Wert für RAW auch zwischen 0 und 1023 sein müssen.
pj
Zitat von: balli1187 am 23 November 2018, 06:41:30
Das war die Frage. Ich nehme mal an, dass im RAW-Modus die Funktionen wie fade und Programme nicht unterstützt werden, da die Kanäle separat angesprochen werden, oder geht das trotzdem?!
Wird das bei der Definition oder gar direkt im Controller festgelegt oder beschränkt es sich auf das absetzen von befehlen?
Fast alle Features (u.a. Fades, Queues) stehen im Raw-Modus genau so zur Verfügung. Der Unterschied ist eben, dass du dich im RGB-Farbraum befindest und keine Farbraumkonvertierung statt findet. Die Weiß-Kanäle musst du entsprechend auch händisch selbst bedienen.
Der Controller wechselt sofort in den gewünschten Modus, wenn ein HSV- oder ein Raw-Befehl abgesetzt wird. Oder anders gesagt: du bist immer im Modus des zuletzt abgesetzten Befehls.
Hier nochmal die Links zur Doku:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Zitat von: vbs am 23 November 2018, 11:39:08
Fast alle Features (u.a. Fades, Queues) stehen im Raw-Modus genau so zur Verfügung. Der Unterschied ist eben, dass du dich im RGB-Farbraum befindest und keine Farbraumkonvertierung statt findet. Die Weiß-Kanäle musst du entsprechend auch händisch selbst bedienen.
Der Controller wechselt sofort in den gewünschten Modus, wenn ein HSV- oder ein Raw-Befehl abgesetzt wird. Oder anders gesagt: du bist immer im Modus des zuletzt abgesetzten Befehls.
Hier nochmal die Links zur Doku:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
oh, dann hast Du da ja das verhalten zur alten Firmware komplett geändert! Ich hab mit der neuen FW nie einen Controller im RAW Modus genutzt.
pj
Hm, bin ich mir ehrlich gesagt jetzt gar nicht so bewusst. Was meinst du genau? Queues z.B. gab es ja vorher nicht und Fades z.B. waren bei Raw früher auch möglich, bin ich der Meinung.
Sorry aber so ganz hab ich's noch nicht durchdrungen....
Aktuell würde ich sagen mein Effektlicht und die zimmerbeleuchtung werden nicht parallel betrieben.
Könnte ich dann den Controller
- einmal als RGB-Variante anlegen und dann den Farbraum per HSV-Raum schalten
- und einmal als RGBW-Varianten anlegen und nur den W-Kanal per RAW schalten?
Funktioniert diese Dopplung?
Gesendet von iPhone mit Tapatalk
Nee der Modus im Controller ist immer global und gilt für alle Kanäle. Kannst also nicht drei Kanäle als HSV betreiben und zur gleichen Zeit zwei Kanäle als Raw.
Zitat von: vbs am 24 November 2018, 14:57:01
Nee der Modus im Controller ist immer global und gilt für alle Kanäle. Kannst also nicht drei Kanäle als HSV betreiben und zur gleichen Zeit zwei Kanäle als Raw.
Nicht zu gleichen Zeit, das ist klar.
Aber nach einander?
Also wenn ich (ausschließlich) Effektlicht haben möchte, setze ich ein Kommando per HSV-Befehlssatz ab und wenn ich (ausschließlich) Zimmerbeleuchtung haben möchte, setze ich einen RAW-Befehl ab, bei dem ich den WW-Kanal auf 100% stelle.
Gesendet von iPhone mit Tapatalk
Naja so klar ist das gar nicht... wurde schon mal gewünscht und ist auch technisch möglich, kann die FW aber einfach nicht.
Ja, du kannst jederzeit und so oft du willst zwischen den Modi umschalten. Jedoch gibt es beim Umschalten von Raw -> HSV einen harten Sprung, da nicht jeder Raw-Zustand als HSV abgebildet werden kann. HSV -> Raw wird gefadet.
Ich meinte eher für mich war es klar aus seiner vorherigen Beschreibung.
Wäre aber aus meiner Sicht und mit meinem Anwendungsfall auch wünschenswert, wenn man den WW- und CW-Kanal auch im HSV-Modus separat schalten könnten, wenn man nur RGB-Stripes angeschlossen hat -
Aber ich will nich unverschämt sein [emoji6]
Ich denke ich werd schon ne Möglichkeit finden, um den Controller für meine Zwecke zu vergewaltigen [emoji6]
Gesendet von iPhone mit Tapatalk
wäre es in der Theorie möglich den Controller für ein ws2812b Stripe zu verwenden oder würde das mit der FW gar nicht gehen?
Der Ausgang würde ja dann nur für die Datenleitung dienen. Oder ggf einen anderen Ausgang direkt am ESP.
Zitat von: kmxak am 24 November 2018, 21:07:52
wäre es in der Theorie möglich den Controller für ein ws2812b Stripe zu verwenden oder würde das mit der FW gar nicht gehen?
Der Ausgang würde ja dann nur für die Datenleitung dienen. Oder ggf einen anderen Ausgang direkt am ESP.
Kurz und knapp
Nein
Gruss Christoph
P.S.: Hatte ich auch schon mal gefragt, und macht auch keinen Sinn, da technisch voellig anders!
Ich wollte noch kurz berichten:
Mein Aufblinken der Farben beim Einschalten kam von einem Pulldownwiderstand, den ich im Breadboard falsch gesteckt hatte und der somit eigentlich gar nicht da war einerseits, und einem defekten ESP-Board andererseits. Was jetzt letztlich ausschlaggebend war, weiß ich nicht, aber nun funktioniert es, wie es soll :)
Danke für die Hilfe und die Software im Allgemeinen!
Grüße, Gunnar
Mal ne Frage, besonders an @Shojo:
Ich steh gerade auf dem Schlauch bzgl. Farbtemperatur im Webinterface: Das "White Temperatur (Kelvin)" ist bei mir "ausgegraut" (bzw. nicht veränderbar). Wann darf man da denn was verändern? Ich hatte irgendwie gedacht, dass es zugänglich sein müsste, wenn man "RGBWWCW" wählt, aber das ist offenbar nicht so. Der WW-CW-Regler im Start-Tab wird dann zugänglich.
Ist das widersprüchlich/falsch oder verstehe ich da gerade etwas nicht?
Hallo zusammen, hallo vbs,
das hier ist mein erster Post, bei dem ich, so gut ich kann, versuche, die Regeln zu befolgen. Natürlich bin ich offen für Hinweise und Belehrungen!
Im Augenblick scheitere ich bei Bereitstellen des Moduls "32_EspLedController.pm" im Verzeichnis ./FHEM.
Zunächst folgte ich den Anweisung für den Weg über "update". Das WIKI auf GitHub möchte zunächst ..
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/controls_espledcontroller.txt
... ausgeführt haben. Diese Datei scheint allerdings nicht mehr zu existieren. Also das Ganze noch einmal mit ...
update add https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
... was soweit funktionierte. Beim anschließenden Ausführen von "update" allerdings erscheint folgende Meldung:
2018.12.17 13:15:29 1 : espledcontroller
2018.12.17 13:15:29 1 : UPD FHEM/32_EspLedController.pm
2018.12.17 13:15:30 1 : Got 55018 bytes for FHEM/32_EspLedController.pm, expected 57344
2018.12.17 13:15:30 1 : aborting.
In einigen Beiträgen hier im Forum wird zum Update von "HTTPUtils" sowie "98_update" geraten. Das habe ich bereits getan, leider ohne Erfolg.
Der Versuch per FTP endet nach dem Neustart von FHEM und dem Befehl (laut entsprechendem WIKI ...
define esp EspLedController 192.168.2.180
... stets mit der Meldung ...
Cannot load module EspLedController
Die Datei "32_EspLedController.pm" befindet sich im Verzeichnis ./FHEM zwischen den ganzen anderen Modulen, ist allerdings etwa 550kB groß, was mir in Anbetracht des Inhalts viel vorkommt.
Ich wäre super dankbar für jedweden Wink mit dem Zaunspfahl.
Vielen Dank
mtb
Gute Hinweise, danke. Größe sollte ~55 kB sein, wenn du 550 kB hast, dann ging da etwas schief. Hab jetzt das Update gefixt (und den Link im Wiki angepasst). Probier bitte nochmal per URL (wie du schon richtig selbst rausgefunden hast):
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
Sollte jetzt tun ;)
Falls er das weiterhin nicht laden kann, dann einmal ins FHEM-Log gucken, da ist mit etwas Glück etwas mehr Info zur Ursache zu sehen.
Hatte neulich ein paar Sachen im Modul angepasst. Damit sollte der Controller jetzt out-of-the-Box mit der Google Home Integration von hier funktionieren:
https://forum.fhem.de/index.php/topic,93814.0.html
(Kurzfassung: gibt jetzt den set-Befehl "white <ct>", der die Sättitung auf 0 dreht und gleichzeitig die optionale Farbtemperatur einstellt.)
Benötigt momentan jedoch dafür diesen Branch von ghome-fhem:
https://github.com/verybadsoldier/ghome-fhem/tree/development
Hallo vbs,
als kurzes Feedback:
Nach der Korrektur der UPD-Daten ging das "update" problemlos. Vielen Dank!
VG Tim
moin @vbs, sag mal, ich hab ein ausgesprochen merkwürdiges Problem, und das immer wieder mal, zur Zeit extrem:
Die Web Oberfläche des Controllers (also a.b.c.d/webapp) wird partout nicht angezeigt.
Das interessante daran ist: der html content wird komplett übertragen, aber nicht gerendert.
Der Browser zeigt mir im debug panel zwei Fehler an:
Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH webapp:1 und
Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH app.min.css:1
das passiert auf mehreren Geräten und mit allen üblichen Browsern, unter Linux, Android und Windows.
a) bin ich der einzige mit dem Problem?
b) hast Du ne mögliche Erklärung dafür?
Grüße
pj
wenn ich so rein sehe, dann haben wir da sowieso irgendwie ne Menge Mist im SPIFFS...
app.min.css kann ich im Browser laden, aber nur, wenn das ?rel= nicht in der URL steht, app.min.js funktioniert nachvollziehbar nicht.
was tun die ganzen anderen .html files? Die scheinen meines Erachtens nach zu einem Framework zu gehören, werden aber nicht genutzt, oder?
Hi Peter, ist komisch, das ist nicht normal und kommt mMn auch nicht aus der Firmware. Die html-Seiten werden ja bei dir offenbar von jquery nachgeladen. Interessant, da jquery mW in der Firmware nicht genutzt wird. Hast du evtl. irgendwelche Browser-Extensions laufen, die sowas machen könnten? Oder Proxy oder VPN?
"onloadfwff.js" kommt angeblich von "LastPass". Hast du das zufällig? Bitte mal ausschalten, wenn ja.
https://www.solvusoft.com/en/files/error-missing-download/js/windows/lastpass/lastpass/onloadwff-js/
Ah, Browser Extension war schonmal gut, da kamen die merkwürdigen zusätzlichen html Seiten her.
Aber: immer noch bekomme ich "failed" für app.min.css?rel=0.3.3-shojo 7 und app.min.js?rel=0.3.3-shojo7
General
Request URL: http://192.168.29.53/app.min.js?rel=0.3.3-shojo7
Request Method: GET
Status Code: 200 OK
Remote Address: 192.168.29.53:80
Referrer Policy: no-referrer-when-downgrade
Response Headers
Cache-Control: public, max-age=86400, must-revalidate
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 187324
Content-Type: text/javascript
ETag: "00f-2-2dbbc0-d"
Server: HttpServer/Sming
Reuqest Headers
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Host: 192.168.29.53
Pragma: no-cache
Referer: http://192.168.29.53/webapp
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Query String Parameters
rel: 0.3.3-shojo7
Nach 2s bricht die Verbindung dann ab.
Lastpass hatte ich mal disabled und ich hab's auch auf Browsern ohne versucht. Ich glaube nicht, dass das ein Faktor ist.
pj
Ich hab ehrlich gesagt immer noch deinen Browser im Verdacht. Evtl. blockt immer noch irgendwas den Request.
Mach mal bitte folgendes:
Lad mal curl für ein OS deiner Wahl runter (https://curl.haxx.se/download.html) und mach den Request mal auf der Kommandozeile. Mal gucken, was da passiert.
Wenn es gut läuft, sieht es so aus wie bei mir:
C:\Users\vbs\Desktop\curl-7.63.0-win64-mingw\bin>curl.exe -v http://192.168.2.53/app.min.js?rel=0.3.3-shojo7 --output test.js
* Trying 192.168.2.53...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 192.168.2.53 (192.168.2.53) port 80 (#0)
> GET /app.min.js?rel=0.3.3-shojo7 HTTP/1.1
> Host: 192.168.2.53
> User-Agent: curl/7.63.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: public, max-age=86400, must-revalidate
< Content-Encoding: gzip
< Content-Type: text/javascript
< ETag: "00f-2-2dbbc0-d"
< Content-Length: 187324
< Connection: keep-alive
< Server: HttpServer/Sming
<
{ [2553 bytes data]
100 182k 100 182k 0 0 154k 0 0:00:01 0:00:01 --:--:-- 154k
* Connection #0 to host 192.168.2.53 left intact
Hinterher hab ich da eine 183 kB große Datei test.js.
Ich glaube, wir kommen der Sache näher.
Ich habe hier zwei Netze, eines für alle IoT devices und eines für alles andere.
Das IoT Netz ist üblicherweise etwas schwächer, weil es mir da nicht auf Performance ankommt, deshalb gibt es nur eine Basisstation, das Netz ist aber üblicherweise von überall aus sichtbar. (wenn ich hier "Netz" sage, dann meine ich die WLAN SSID, IP-mäßig ist es ein flaches Netz)
Ich habe jetzt zwei Controller
192.168.29.57 im IoT Netz
192.168.29.53 im Büronetz
und siehe da, der Fehler tritt nur im IoT Netz auf. Ich vermute mal, es hat etwas mit der geringeren Übertragungsqualität zu tun. Offenbar bricht die Übertragung der (längeren) .js Datei vorzeitig ab und es gibt kein Retransmit...
Draußen auf der Terasse stehen übrigens noch sieben Lampen mit dem gleichen Controller, die sind 10m weiter weg als dieser und durch eine Außenwand getrennt. Manche zeigen das Verhalten, andere nicht. Insgesamt ist das strange.
$ curl.exe -v http://192.168.29.57/app.min.js?rel=0.3.3-shojo7 --output test.js
* Trying 192.168.29.57...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 192.168.29.57 (192.168.29.57) port 80 (#0)
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0> GET /app.min.js?rel=0.3.3-shojo7 HTTP/1.1
> Host: 192.168.29.57
> User-Agent: curl/7.55.1
> Accept: */*
>
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0< HTTP/1.1 200 OK
< Cache-Control: public, max-age=86400, must-revalidate
< Content-Encoding: gzip
< Content-Type: text/javascript
< ETag: "00f-2-27a570-d"
< Content-Length: 162391
< Connection: keep-alive
< Server: HttpServer/Sming
<
{ [17843 bytes data]
* transfer closed with 144548 bytes remaining to read
10 158k 10 17843 0 0 3568 0 0:00:45 0:00:05 0:00:40 4063
* Closing connection 0
curl: (18) transfer closed with 144548 bytes remaining to read
$ curl.exe -v http://192.168.29.53/app.min.js?rel=0.3.3-shojo7 --output test.js
* Trying 192.168.29.53...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 192.168.29.53 (192.168.29.53) port 80 (#0)
> GET /app.min.js?rel=0.3.3-shojo7 HTTP/1.1
> Host: 192.168.29.53
> User-Agent: curl/7.55.1
> Accept: */*
>
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0< HTTP/1.1 200 OK
< Cache-Control: public, max-age=86400, must-revalidate
< Content-Encoding: gzip
< Content-Type: text/javascript
< ETag: "00f-2-2dbbc0-d"
< Content-Length: 187324
< Connection: keep-alive
< Server: HttpServer/Sming
<
{ [65309 bytes data]
100 182k 100 182k 0 0 93662 0 0:00:02 0:00:02 --:--:-- 73116
* Connection #0 to host 192.168.29.53 left intact
ich werd mich wohl nochmal um meine Netzwerk-Infrastruktur kümmern müssen :/
Hallo zusammen,
Ich weiss nicht ob ich hier richtig bin, ich würde den Controller gerne mit Tasmota und hue emulation nutzen wollen, bzw ist eine hue emulation für die vbs firmware geplant.
Ich habe viele hue Lampen und die hue app ist halt ein WAF.
Gruss
Zitat von: lewej am 04 Januar 2019, 19:00:35
Hallo zusammen,
Ich weiss nicht ob ich hier richtig bin, ich würde den Controller gerne mit Tasmota und hue emulation nutzen wollen, bzw ist eine hue emulation für die vbs firmware geplant.
Ich habe viele hue Lampen und die hue app ist halt ein WAF.
Gruss
Moin
Coole Idee, wuerde die Vorbestellungen total in die Hoehe treiben! Tasmota wuerde aber die ganze Funktionalitaet des Controllers vernichten. Und wie einfavh eine HUE-Emulation zu implementieren ist, kann ich nicht beurteilen!
Gruss Christoph
Also von meiner Seite aus ist da nichts geplant.
Ich denke es wäre besser, in FHEM ein Hue-Gateway-Modul zu implementieren, welches dann beliebige Geräte aus FHEM heraus als Hue-Geräte bereit stellt. Dann muss man die Hue-Emulation nicht in alle Geräte implementieren.
Hallo,
ich bin neu im Thema esprgbww und hab mal eben ein Modul mit der aktuellsten Firmware in Betrieb genommen zum Testen (0.8.1-vbs5).
Wahrscheinlich habe ich das in der Fülle der Postings überlesen (sorry), aber ich hab da ein Verständnisproblem (denke ich zumindest).
Habe hier so einen RGBWW-LED-Stripe, R,G und B sind eh klar, den WW habe ich an den WW-Pin der Platine gegeben, extra Plus haben diese Stripes für WW ja nicht.
Wenn ich nun in Fhem per rgb einen Farbwert setze, der nicht nur reines R, B oder G ist, leuchten die weissen LEDs mit.
Irgendwie verstehe ich das nicht - ich würde denken, daß diese Farben nur die farbigen LEDs ansteuern. Wenn ich FFFFFF setze, dann schalten sich die Farb-LEDs ab und die WW-LEDs knallen voll rein - das verstehe ich schon ;-)
Habe ich hier ein Verständnis-Problem des Farbmodells - oder gibt es eine Möglichkeit, die WW-Leds quasi bei der Farbmischung auszuschalten?
Warum mich das stört: Ich hab meine Stripes in Profilen mit ziemlich kleinem Abstand zum Milchglas verbaut, sodaß man die einzelnen LED-Punkte sieht...
Cheers,
Pula
Guck dir mal den HSV-Farbraum an. Das ist für einen Mensch normalerweise wesentlich einfach nachvollziehbar.
Weiß wird immer dann reingemischt, wenn die Sättigung unter 100% liegt. Also wenn du Weiß ausschalten möchtest, dann musst du einfach beim Mischen immer Sättigung auf 100% lassen.
Ah - danke für die aufschlussreiche Antwort :-)
Denke halt Farben seit jeher in RGB, aber hier scheint sich ein Umdenken zu lohnen...
Cheers,
Pula
Hi @Pula,
es gibt mittlerweile viele Strips, die auf LED aufbauen, die vier oder gar fünf "Farben" auf einem Träger integrieren (R,G,B,WW, CW) damit sind zumindest dann alle Punkte gleich, also immer die Lichtmischung, die Du willst.
Die alten Strips, auf denen sich RGB und Weiß-Chips abwechseln sind tatsächlich nicht besonders geeignet.
Beispiel hier: https://www.aliexpress.com/item/Newest-LED-RGBW-Strip-SMD-5050-chip-12V-flexible-light-RGB-White-warm-white-4-color/32575020716.html?spm=a2g0s.9042311.0.0.27424c4dPUN014
Grüße
pj
Hi pj,
danke für Deine aufschlussreiche Antwort!
Vielleicht sollte ich echt einige der stripes austauschen....
weisst du zufällig, wie die "neuen" stripes sich in der bezeichung von den "alten" abgrenzen?
ali ist mein freund, aber die suche....
cheers,
Pula
Zitat von: pula am 11 Januar 2019, 22:16:44
Hi pj,
danke für Deine aufschlussreiche Antwort!
Vielleicht sollte ich echt einige der stripes austauschen....
weisst du zufällig, wie die "neuen" stripes sich in der bezeichung von den "alten" abgrenzen?
ali ist mein freund, aber die suche....
cheers,
Pula
am einfachsten erkennbar ist das daran, dass drei Chips zwischen je zwei Trennstellen sind.
hier zum Beispiel: https://www.aliexpress.com/item/Newest-LED-RGBW-Strip-SMD-5050-chip-12V-flexible-light-RGB-White-warm-white-4-color/32575020716.html?spm=a2g0s.9042311.0.0.27424c4dPUN014
Oft steht auch "4 color per chip" o.ä. dabei.
pj
Mal ein etwas größeres Update:
Ich hab auf Sming 3.7.0 upgedatet und bin dabei auf das ESP SDK 3.0.0 gegangen. Es wird jetzt nicht mehr die PWM-Implementierung aus dem ESP SDK benutzt, sondern eine alterrnative, in Sming integrierte Implementierung ("new_pwm"). Die bisher verwendete (aus dem espressif SDK) hat u.a. das Problem, dass prinzipbedingt nie 100% Duty-Cycle möglich war (war so auf 90-95% begrenzt). So sieht dann ein Fade von 70% auf 100% auf einem Oszi aus (vbs35):
https://streamable.com/tdj5s
Mit der neuen Implementierung (4.0.0-rc1) sieht das so aus:
https://streamable.com/fwz1v
Ich hab außerdem das Versionsschema auf semver (https://semver.org/) umgestellt, so daß jetzt wieder sinnvolle Versionsbezeichnungen möglich sind.
Die Sache hat aber einen Haken: Der Wechsel des SDK von 2.0.0 auf 3.0.0 ist formell nicht OTA möglich, da Initialisierungsdaten des SDKs in den Controller geschrieben werden müssen. Die Firmware muss jetzt einmal klassisch über den Serial-Bootloader aufgespielt werden. Ich weiß, ist nicht so schön. Ich hab hier das Vorgehen per esptool.py dokumentiert:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/1.1-Flashing#precompiled-rom-and-filesystems
Im Endeffekt das hier:
esptool.py -p /dev/COMPORT -b 115200 erase_flash
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x3fc000 esp_init_data_default.bin 0x3fe000 blank.bin 0x100000 blankfs.bin
esptool.py -p /dev/ttyUSB0 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.binDie Files liegen hier:
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/88723a95a329b5c98759252d229a2869acb6f3fc
Aber: Ein Einspielen der Firmware per OTA funktioniert unter Vorbehalten. Man kann die Firmware einspielen, muss dann aber einmal powercyclen. Ansonsten funktioniert die PWM nicht. Jedoch fehlt dann die SDK-Initialisierung, wobei nicht klar ist, welches Auswirkung das hat. Aber mir ist spontan nichts aufgefallen.
Also wäre klasse, falls ein paar Leute Lust hätten ein bisschen zu testen. Insbesondere interessant wäre ein Auge auf das PWM-Verhalten und Stabilität zu legen. Ich bin der Meinung, bei mir aber recht subtile kurze Blitze/Aussetzer sehen zu können wenn Fades laufen. Wenn sich das bei euch auch bestätigt, dann würde ich wieder zurück auf das SDK-PWM. Wäre aber schade eigentlich :(
Ein Wechsel zurück auf vbs35 ist jederzeit problemlos regulär per OTA möglich.
Komplettes Changelog für 4.0.0-rc1
- Upgrade auf Sming 3.7.0
- ESP SDK 3.0.0
- new_pwm-Implementierung (anstelle von espressif SDK-PWM)
- neues Versionierungsschema
- Fix: Bootup-Fade und Fade-Time auf 2 Sek. erhöht
PS.
Falls irgendwann nochmal jemand eine neue Hardware designen sollte: Wünschenswerte wäre ein beliebiger GPIO an dem Reset-Pin, um softwaregesteuert einen echten Reset auslösen zu können. Und zweitens wäre Hardware-PWM evtl. eine Überlegung wert.
Moin
Das kommt jetzt irgendwie "unpassend"! Rein theoretisch sind wir kurz davor die Bestellung auszuloesen.
Was meinst Du mit HW-PWM? Der Reset, koennte evtl. noch einfliessen (pjakobs?), wenn Du denn auch den Vorteil erklaerst!
Gruss und Danke
Christoph
@vbs: Gibt es auch Updates bezüglich ESP32 und LAN?
Das mit dem HW PWM, mhh dann landet man früher oder später doch wieder beim guten alten µC der sowas gelangweilt nebenbei erledigt ^^ Diese ESP sind eben leider keine echten µC durch den ganzen OS kram der da mitläuft.
/Daniel
Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Das kommt jetzt irgendwie "unpassend"! Rein theoretisch sind wir kurz davor die Bestellung auszuloesen.
Tut mir leid, hab es mir aber auch nicht ausgesucht. Die Überlegungen dazu entstanden erst jetzt mit den Arbeiten an der neuen Firmware. Sind aber aus meiner Sicht aber auch nur "nice-to-have" und evtl. sogar gar nicht sinnvoll.
Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Was meinst Du mit HW-PWM?
Na beim Hardware-PWM wird das Signal von einem dedizierten Hardware-Bauteil erzeugt. Also entsprechend robust und unabhängig von anderen Abläufen. Beim Software-PWM wird die PWM-Logik in Software nachgebildet (evtl. wie bei uns unterstützt durch Hardware-Timer). Die Software-Variante ist entsprechend belastend für den Prozessor und steht in Konkurrenz zu anderen Abläufen. In Hardware sind dann auch höhere Frequenzen möglich. Google kann es bestimmt auch noch besser erklären als ich jetzt auf die schnelle.
Aber: wie wir wissen klappt das bei uns eigentlich sehr gut mit dem Software-PWM. Das Software-PWM im ESP-SDK hat den Nachteil, dass damit nur 90% Duty-Cycle realisiert werden können. Die LEDs können also nicht voll ausgesteuert werden. Ob man das wirklich sieht? Keine Ahnung.
Gibt aber hier eine alternative Implementierung:
https://github.com/StefanBruens/ESP8266_new_pwm
Habe aber eben festgestellt, dass die (zumindest in unserer HW-Konstellation) das Problem hat, manchmal kaum merklich zu flackern/blitzen. Ist minimal, aber finde ich blöd.
Daher kam der Wunsch nach Hardware-PWM auf, von der ich erwarten würde, ein 100% robustes und unabhängiges PWM-Signal bereitstellen zu können. Natürlich brauchen wir aber unsere 5 Kanäle. Das schöne bei der Software-Variante ist aber, dass man jederzeit volle Kontrolle über Fades, Animationen usw. hat. Evtl. ist das mit einer Hardware-Variante gar nicht so schön möglich wie jetzt bei dem ESP.
Aber wie gesagt: ist erstmal nur laut gedacht. Die PWM in Hardware zu machen ist generell wünschenswert. Kenn mich da hardwaremäßig nicht so aus, was es da gibt. Und evtl. hat man da andere Nachteile wie z.B. weniger Kontrolle.
Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Der Reset, koennte evtl. noch einfliessen (pjakobs?), wenn Du denn auch den Vorteil erklaerst!
Der Grund steckt im vorherigen Post: Beim OTA-Update von einer SDK2- zu einer SDK3-Firmware funktioniert PWM dann erst nach einem echten Powercycle (Soft-Restart reicht nicht). Zwar ist eigentlich OTA-Update für den Fall nicht vorgesehen, aber die Erkenntnis ist, dass Soft-Restart != Hard-Reset. Evtl wäre es daher evtl. mal wünschenswert, die Möglichkeit zu haben einen Hard-Reset per Software auslösen zu können. Just in case. Ist sicherlich ja recht leicht zu realisieren.
Zitat von: ext23 am 16 Januar 2019, 21:48:13
@vbs: Gibt es auch Updates bezüglich ESP32 und LAN?
Tut mir leid, keine Neuigkeit von meiner Seite. Sming unterstützt mW kein ESP32 und auch kein LAN (da aber unsicher):
https://github.com/SmingHub/Sming/issues/1333
Man müsste also die FW auf was anderes portieren... etwas eigenes oder Arduino oder so. Kann aber nicht beurteilen, ob das eine gute Idee ist. Kenne mich da zu wenig aus.
Zitat von: ext23 am 16 Januar 2019, 21:48:13
Das mit dem HW PWM, mhh dann landet man früher oder später doch wieder beim guten alten µC der sowas gelangweilt nebenbei erledigt ^^ Diese ESP sind eben leider keine echten µC durch den ganzen OS kram der da mitläuft.
Ganz genau. Hat eben Vor- und Nachteile. Super wäre es, wenn man evtl. beides kombinieren könnte? Also den ESP für Wifi, Webserver und API und co. und zusätzlich einen kleinen 5-Kanal-PWM-Controller. Aber ganz ehrlich: ich hab da wenig Erfahrung. Ist vlt. auch Quatsch...
sag mal, @VBS, wie aufwendig wäre es eigentlich, für die beiden GPIO 0 und 16 (also PRG und CLR) mqtt topics zu definieren? Ich denke gerade darüber nach, die für die zu produzierende Version vielleicht noch auf einen Header zu bringen. Das hätte den riesen Vorteil, dass man, wenn der Controller in einer Lampe verbaut ist, noch zwei Taster dran hängen und die Lampe, via mqtt und fhem, lokal schalten könnte.
pj
Zitat von: pjakobs am 04 Februar 2019, 10:22:19
wenn der Controller in einer Lampe verbaut ist, noch zwei Taster dran hängen und die Lampe, via mqtt und fhem, lokal schalten könnte.
Bin nicht sicher, ob ich verstanden habe, was du machen willst. Wie bzw. warum MQTT, wenn man die Lampe lokal schalten will?
Zitat von: vbs am 05 Februar 2019, 22:54:50
Bin nicht sicher, ob ich verstanden habe, was du machen willst. Wie bzw. warum MQTT, wenn man die Lampe lokal schalten will?
Ich will ja nicht festlegen, was passiert, ich fände es praktisch, wenn man einfach eine mqtt message verschickt weil einer der gpios auf gnd gezogen wurde. (es sind übrigens potentiell 0, 2 und 16)
Was der server dann daraus macht is nicht unser ding.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hm, ich finde die Idee mit der Bedienung am Gerät generell gut. Bin aber noch nicht überzeugt davon, dass man dafür einen MQTT-Server und ein laufendes FHEM braucht. Empfinde ich für einen Ein/Aus-Schalter am Gerät als etwas Overkill um ehrlich zu sein.
Man könnte ja auch z.B. lokal im Gerät den Ein-Zustand konfigurierbar machen, der eingenommen wird, wenn der lokale Ein-Schalter betätigt wird (ähnlich der Startup-Color). Wäre dann auch ausfallsicher falls FHEM mal streikt. Die MQTT-Message könnte man aber natürlich zusätzlich machen, so dass im Prinzip auch deine Variante möglich wäre. Die damit mögliche Flexibilität ist ja auch super.
aloha community
ich kann mal meine hardwarelösung als inspiration anbieten.
beim ESP8266 ist nicht nur die soft-PWM das problem sondern z.b. auch die undefinierten pin-states (high-z/high-level) während des boots (power on).
beides kann unschönes flackern erzeugen und ist damit bezogen auf die ansteuerung der fets leider sehr "unsauber".
als schulungsexperiment mag das reichen. daher gibts wohl auch überall den soft-PWM ansatz für den ESP.
die grenzbereiche der PWM sind dabei am auffälligsten. (z.b. 0-5% bzw. 95%-100%).
da die helligkeit von leds stark nichtlinear bezogen auf die PWM ist, ist der untere bereich jedoch relevant wenn man z.b. "stark gedimmtes" licht haben will.
der (software) jitter ist immer vorhanden und wirkt sich im grenzbereich einfach massiver aus. (= "sichtbarer")
es gibt zwar PWM ansätze die das problem leicht entschärfen da optimierter code verwendet wird, rein konzeptionell ändert das aber nichts.
zum schematic:
bei der gezeigten lösung ist es nicht nötig ein PCB zu ätzen, da sowieso nur 3 "flightwires" nötig sind.
ich verwende die schaltung in verschiedenen setups mit verschiedenen power-fets - für (analog) LED strips und echte lampen (24V) mit mehreren kanälen.
die firmware des AVR ist ein "10-zeiler". und damit fehlerfrei und robust. (serial clock/data to pwm).
die firmware auf ESP8266-seite wird dadurch auch simpler, da timing-unkritisch.
gruss
lou
@pjakobs
Kannst du etwas bzgl. des Hard-Reset-Pins aus meinem letzten Post sagen?
Warum benutzt du ein AVR und nicht ein PWM Chip?
/Daniel
Zitat von: ext23 am 06 Februar 2019, 11:41:08
Warum benutzt du ein AVR und nicht ein PWM Chip?
/Daniel
der ATTINY24 ist günstig, DIL (2.54 rastermaß), flexibel und meine schublade ist voll davon :) ("verfügbarkeit").
ausserdem kann man dann das DA/CL interface beliebig (einfach) selbst implementieren. SPI o.ä. ist nicht nötig.
zusätzlich mache ich noch eine linearisierung per mini-lookuptable im avr. die kann somit leuchtenspezifisch sein.
folge: ESP8266 firmware ist immer die selbe und damit sinkt die komplexität auf ESP-seite / web/lan-backend zusätzlich.
OK ;-)
Naja ich mag die ESP ehe nicht, das sind eben keine echten µC. Im Prinzip müsste man alles auf den AVRs machen, dann würde vieles besser laufen. Und wer unbedingt WLAN oder LAN braucht kann sich ja immer noch ein ESP ran hängen als Brücke zu UART. Aber gut es ist eben wie es ist ja. Übrigens der Tiny macht ja auch 5V, dann könnte man auch gleich bessere MOSFETS nehmen die sauber im Arbeitsbereich liegen und nicht sone 3,3V "Krücken". Zumindest für die interessant die hinten 300W dran haben...
/Daniel
Wir würdet ihr euch bei so einer AVR-Lösung die Umsetzung einer akkuraten Synchronisierung mehrerer Controller per Wifi vorstellen? Mir geht es da um Fragen bzgl. der genauen Taktung der Controller.
Zitat von: ext23 am 06 Februar 2019, 11:54:05
OK ;-)
Naja ich mag die ESP ehe nicht, das sind eben keine echten µC. Im Prinzip müsste man alles auf den AVRs machen, dann würde vieles besser laufen. Und wer unbedingt WLAN oder LAN braucht kann sich ja immer noch ein ESP ran hängen als Brücke zu UART. Aber gut es ist eben wie es ist ja. Übrigens der Tiny macht ja auch 5V, dann könnte man auch gleich bessere MOSFETS nehmen die sauber im Arbeitsbereich liegen und nicht sone 3,3V "Krücken". Zumindest für die interessant die hinten 300W dran haben...
/Daniel
Einspruch!! :) :) die ESPs sind super :) nur viele verstehen die komplexität hinter wifi z.b. nicht, oder haben noch nie per osci gesehen was alles so passiert wenn der ESP nur "lauscht" im netz :)
will man wirklich timingkritische dinge machen MUSS man sich an SPI und konsorten halten. Das ist dann auch 100% timingstabil.
theoretisch könnte man den ESP 100% "raw/bare" betreiben. dann hat man halt die schönen wifi-libs nicht.. auch blöd ;)
*philosophie-modus-ende* :)
@vbs: kann nicht ganz folgen. was meinst du genau mit sync. bzw controller ? den avr? der wird in der beschriebenen lösung 100% über CK/DA per ESP8266 synchronisert (bei mir z.b. 200us per data-frame + 50ms deadzone, also maximale updaterate grob 50ms...). alles andere per MQTT/websockets o.ä.
Zitat von: lou am 06 Februar 2019, 12:00:12
Einspruch!! :) :) die ESPs sind super :) nur viele verstehen die komplexität hinter wifi z.b. nicht, oder haben noch nie per osci gesehen was alles so passiert wenn der ESP nur "lauscht" im netz :)
will man wirklich timingkritische dinge machen MUSS man sich an SPI und konsorten halten. Das ist dann auch 100% timingstabil.
theoretisch könnte man den ESP 100% "raw/bare" betreiben. dann hat man halt die schönen wifi-libs nicht.. auch blöd ;)
*philosophie-modus-ende* :)
Wenn du das OS ersetzt ja, aber es ist ein SoC und ein µC, bleib ich bei. Das Ding kann keine echten Counter und nichts, also Grütze. Es ist eben mehr ein raspberryPi... Mit dem Ding kann man nicht mal 800 kHz sauber messen.
/Daniel
Zitat von: vbs am 06 Februar 2019, 11:57:54
Wir würdet ihr euch bei so einer AVR-Lösung die Umsetzung einer akkuraten Synchronisierung mehrerer Controller per Wifi vorstellen? Mir geht es da um Fragen bzgl. der genauen Taktung der Controller.
Sowas kann man auch via 433 MHz oder 868 MHz machen, das sollte auch besser gehen als mit WIFI ^^ Oder aber wenn alles im selben raum ist auch gleich über das Licht.
Aber wie gesagt das ist alles ein komplett neues Thema, hier geht es ja um den ESP, von daher kein Gedanken dran verschwenden.
/Daniel
Zitat von: ext23 am 06 Februar 2019, 12:04:20
Wenn du das OS ersetzt ja, aber es ist ein SoC und ein µC, bleib ich bei. Das Ding kann keine echten Counter und nichts, also Grütze. Es ist eben mehr ein raspberryPi... Mit dem Ding kann man nicht mal 800 kHz sauber messen.
/Daniel
stimme zu. der ESP ist kein realtimesystem. aber sackrisch schnell gegenüber einem "echten" lowend uC :) espressif hat damit definitiv eine lücke gefüllt. darum der hype.
ach übrigens.. bei mir war mal die hauptmotivation für einen eigenen controller der fakt, das die meisten china-mit-dabei-controller nach kürzester zeit (z.b. ein jahr) spinnen oder hopps gehen (tote fets, schlechte firmware etc). und die einzelnen IR-sender sind auch nicht wirklich elegant.
für echte digitalstrips/matrix (z.b. WS2812b), ist dagegen der ESP8266 ohne zusätzliche fets oder uC perfekt (per SPI).
wer "nur" ledstrips steuern will sollte hier zugreifen. diese strips sind mittlerweile sehr leuchtstark und auch mit hoher leddichte/m sehr günstig.
@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.
Die Synchronisierung basiert momentan darauf, dass alle Controller sehr akkurat ihre durchlaufenen Steps zählen und dann mit dem Master abgleichen:
https://forum.fhem.de/index.php/topic,70738.msg742959/topicseen.html#msg742959
Könnte man mit der AVR-Variante etwas ähnliches/gleichwertiges machen?
Zitat von: vbs am 06 Februar 2019, 12:29:36
@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.
Die Synchronisierung basiert momentan darauf, dass alle Controller sehr akkurat ihre durchlaufenen Steps zählen und dann mit dem Master abgleichen:
https://forum.fhem.de/index.php/topic,70738.msg742959/topicseen.html#msg742959
Könnte man mit der AVR-Variante etwas ähnliches/gleichwertiges machen?
der avr macht (bei mir) nur etwas extrem simples. er sorgt für 100% stabile pwm. die leuchten/strips die ich damit ansteuere hängen an der decke oder unter der theke etc.
es geht also nur um das richtige "statische" licht. sonst nix :) (dimmen per handy / tablet).
das ist wichtig wenn man z.b. eine grosse led-leuchte mit recht viel power hat. => hauptanspruch: flackerfreiers licht.
die frage ist welche ansprüche du an "synchron" stellst. ms range? us range?
für das von dir angesprochene ziel würde ich auf JEDEN fall digitale ledstrips verwenden (WS2812b etc).
dafür ist der ESP8266 (ohne alles) perfekt per SPI. die synchronisierung findet "on-strip" statt. von led zu led....
ich hab eine etwas grössere matrix so gebaut. klappt super. und prinzipiell kann man beliebig verlänger (=synchronisieren).
gesteuert wird per websockets. die daten könnte man also im lan-backend synchronisieren wenn man will (sync latenz ~ ms range). oder eben per "hardwire" seriell von strip zu strip, plus buffer je nach länge. (sync latenz sub us range).
es gibt sowohl sehr gute strips als auch kaskadierbare matrixdisplays mit dem gleichem onled-controller recht günstig.
Zitat von: lou am 06 Februar 2019, 12:12:35
für echte digitalstrips/matrix (z.b. WS2812b), ist dagegen der ESP8266 ohne zusätzliche fets oder uC perfekt (per SPI).
wer "nur" ledstrips steuern will sollte hier zugreifen. diese strips sind mittlerweile sehr leuchtstark und auch mit hoher leddichte/m sehr günstig.
Da würde ich kein ESP nehmen sondern richtige TP2 Player, der Sinn dieser Stripes ist ja nicht ein schönes Licht, sondern Animationen bzw. Videowände.
Zitat von: vbs am 06 Februar 2019, 12:29:36
@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.
Das ist ja der Sinn eines sync ;-) Da gibt es mehrere Ansätze. Ein Takt übertragen via 433 MHz ist ja ein leichtes und mehr brauchst du ja nicht außer ein Takt. Ansonsten kannst du ja auch auf das PWM Takten, wenn die Controller im selben Raum sind zum Beispiel. Und wenn der Takt nicht reicht, du statt dessen auch Farbinformationen (oder Zeitstempel) als zusätzlichen Sync übertragen musst, kann man das ja in das PWM einarbeiten so das es optisch nicht merkbar, für ein Lichtsensor aber auswertbar ist. Diese Ansätze werden ja schon benutzt um über Licht auch Daten zu übertragen.
Da gibt es durchaus interessante Ansätze.
/Daniel
Zitat von: ext23 am 06 Februar 2019, 13:12:39
Da würde ich kein ESP nehmen sondern richtige TP2 Player, der Sinn dieser Stripes ist ja nicht ein schönes Licht, sondern Animationen bzw. Videowände.
für ein mittelgrosses matrix-display das schönes licht macht UND auch die uhrzeit/email-count/aktienticker mal anzeigt "reicht" der esp8266 zu 100% :)
natürlich nur wenn man lust hat sich um die software zu kümmern ;) mehr aufwand - aber auch flexibler. altes lied...
die aktuell erhältlichen digitalstrips/matrix sind durchaus attraktiv da sie wirklich ordentlich licht machen.. nicht nur "leuchten".
der unterschied zwischen lampe und display wird also immer weniger...
Die sind sogar sehr hell. Hab ne Weihnachtsanimation mit 1024 LED Matrix ins Fenster gehangen, das lief auf 10% und war trotzdem noch zu hell ;-)
/Daniel
Zitat von: ext23 am 06 Februar 2019, 13:49:16
Die sind sogar sehr hell. Hab ne Weihnachtsanimation mit 1024 LED Matrix ins Fenster gehangen, das lief auf 10% und war trotzdem noch zu hell ;-)
/Daniel
bei 5% hats geflackert ? :) spass muss sein.... ;)
Zitat von: lou am 06 Februar 2019, 13:52:42
bei 5% hats geflackert ? :) spass muss sein.... ;)
Nö da flackert nichts, aber die Farben weichen dann einfach zu sehr ab. Hab das nur mit Jinx gemacht.
Hi vbs,
habe deine Testversion geflashed.
Leider nur die RC1 die du verlinkt hattest.
Dachte ich könnte dann per OTA auf RC3 die es ja auf github gibt.
Die option gibt es aber leider nicht.
Kann ich RC3 irgendwie flashen?
Klar ich könnte jetzt selbst kompilieren.
Vielleicht kannst du die testing Firmware bei Gelegenheit mal updaten.
Erstmal hat alles super geklappt. Flashen ging Problemlos, sonst hatte ich mit der alten Firmware öfters Probleme.
Scheint auch stabil zu laufen, hatte öfter mit resets zu kämpfen, konnte auf die schnelle keine feststellen.
Der OTA Screen zeigt bei der Firmware Version etwas komische Werte an:
Current 4.0.0-rc1
OTA 0.4.0-rc1
Siehe Screenshot.
Ich berichte über weitere Erfahrungen.
Danke,
Stefan
Ich hatte auf meinem Testcontroller mit der RC1 und der neuen PWM-Implementierung sporadisch beim Dimmen sehr kurze und sehr subtile Blitzer/Flackereien. Die RC3 ist zwar mit dem neuen Sming aber wieder mit der alten PWM-Implementierung. Hatte ich im Prinzip nur mal für mich gemacht um zu gucken, ob damit das Flackern auch auftritt.
Kannst du ja vlt. mal drauf achten, ob es bei dir auch vorkommt. Ich fürchte, dass ich dann mittelfristig wieder zum alten PWM zurück gehen werde, da ich nicht sehe, dass das Problem zeitnah gelöst werden wird.
Danke fürs Testen! Werde mir auch anschauen, was da mit den Versionsnummern los ist!
Ok, ich werde das mal genau anschauen.
Gestern bei einem schnellen Test ist mir nichts aufgefallen.
Ich werde heute mal etwas hin und her dimmen :-)
Gruß,
Stefan
Ich meine ich hatte zum Testen eine 5 Sekunden-Rampe immer von 0% auf 100% und dann wieder zurück in einer Schleife. Evtl. war dann die Unregelmäßigkeit immer beim 50%-Übergang.
Versionsnummern müssten jetzt passen. Danke für den Hinweis.
Ich habe mal etwas hin und her gedimmt und habe extra drauf geachtet.
Ja es flackert etwas, besonders gut bei unter 10% erkennbar. Z.b. von 5% auf 3%.
Man merkt es auch von 0% auf 100%.
Ich muss aber sagen ich habe vorher nie so genau drauf geachtet und es wäre mir wohl auch nicht aufgefallen.
Mich stört es nicht sonderlich, aber ich verstehe schon wenn man das perfekt haben will ;D
Ansonsten kommt es mir bisher stabiler vor.
Ist vielleicht auch Einbildung, oder ich habe es noch nicht lang genug drauf.
Mit der vorherigen Version hatte ich so 1x am Abend ein reboot des ESP.
P.S.: Versionsanzeige passt jetzt auch.
Das flashen war auf jedenfall super, es hat einfach alles auf Anhieb geklappt.
Vorher waren meine Erfahrungen beim Flashen etwas durchwachsen :-)
Gruß und Danke,
Stefan
Zitat von: stefanru am 07 Februar 2019, 21:45:47
...Mit der vorherigen Version hatte ich so 1x am Abend ein reboot des ESP....
noch ein gedanke:
ein robustes system das den ESP8266 verwendet MUSS zwingend alle möglichen states von WIFI und CPU im betrieb abdecken/abfangen.
d.h. es muss möglich sein dass der ESP reconnects oder reboots ausführt und sporadisch hohe (lan) latenzen o.ä. handhabt, ohne dass der "normale" betrieb des systems drastisch beeinflusst wird.
das liegt in der natur von wifi/lan, und wird z.b. auch von jedem android OS so gehandhabt (modem-restarts etc).
hat man z.b. eine high-power deckenlampe, will man natürlich nicht daß die PWM bei einem wifi reconnect o.ä. gestört wird.
ein weiteres argument für einen dedizierten (hardware) PWM chip.
der ESP kann so autark im wlan werkeln, und auch mal 1-2 sekunden reconnecten/rebooten, ohne dass es die (aktuelle) PWM beeinflusst.
bei "stimmungslicht" mag das nicht besonders relevant sein. bei "beleuchtung" schon eher.
der obige anspruch wird auch erfüllt wenn die PWM/RGB daten
IN den strips gespeichert werden. (z.b. digital strips = langes digitales schieberegister)
Zitat von: lou am 08 Februar 2019, 10:02:00
der obige anspruch wird auch erfüllt wenn die PWM/RGB daten IN den strips gespeichert werden. (z.b. digital strips = langes digitales schieberegister)
Richtig, aber wie gesagt, die wird niemand um sein Bett wickeln, dafür sind die einfach viel zu teuer. Das ist ja wie wenn ich mir ein LED TV hole und das als weißes Lichtpanel an die Decke nagel ;-)
/Daniel
Zitat von: ext23 am 08 Februar 2019, 10:14:45
Richtig, aber wie gesagt, die wird niemand um sein Bett wickeln, dafür sind die einfach viel zu teuer. Das ist ja wie wenn ich mir ein LED TV hole und das als weißes Lichtpanel an die Decke nagel ;-)
/Daniel
SCHÖNES beispiel! ich hab ein bett mit zwei RGB strips links und rechts am unterboden :) ... ich sage nur "intimate mode" ;)
sehr gute WS2812 strips in 5m (300leds) kosten grob E30 (so seit 2-3 jahren). also bitte....
in meinem statement oben ging es um den relevanten übergang zwischen "asynchron,nonrealtime" (lan/wifi) und "synchon,realtime" (pwm).
die digital strips waren nur ein beispiel. dort ist der "übergang" in den strips... die pwm wird "on-led-chip" generiert. (jedes LED-device hat 3 LEDS + mini PWM controller = smart)
bei neukauf haben die analog strips keinerlei berechtigung mehr, da technisch in jeder hinsicht extrem überholt.
Zitat von: lou am 08 Februar 2019, 10:20:07
bei neukauf haben die analog strips keinerlei berechtigung mehr, da technisch in jeder hinsicht extrem überholt.
Wenn ich mich nicht täusche, gibt es WS2812 nicht mit separatem Warmweiss. Das ist je nach Anwendung schon ein wichtiger Unterschied.
Zitat von: swhome am 08 Februar 2019, 11:06:31
Wenn ich mich nicht täusche, gibt es WS2812 nicht mit separatem Warmweiss. Das ist je nach Anwendung schon ein wichtiger Unterschied.
Doch, mittlerweile gibt es diese auch, sowohl mit warm weißen LEDs als auch mit neutral weißen LEDs. Und aus Warmweiß + RGB lassen sich problemlos alle anderen Farbtemperaturen erzeugen ;)
Zitat von: swhome am 08 Februar 2019, 11:06:31
Wenn ich mich nicht täusche, gibt es WS2812 nicht mit separatem Warmweiss. Das ist je nach Anwendung schon ein wichtiger Unterschied.
das stimmt sicher. oder zumindest schwer erhältlich.
bei einer decken/leselampe o.ä. würde ich auch keine RGB strips verwenden. egal ob analog oder digital.
leds/lampen die dediziert für beleuchtung sind, sind da sicher die bessere wahl.
ich hab z.b. eine "sculli" leuchte. da steuer ich nur die helligkeit der "arme". der controller war da nötig weil die lampe "unmodifiziert" viel zu hell ist.
Zitat von: ext23 am 08 Februar 2019, 10:14:45aber wie gesagt, die wird niemand um sein Bett wickeln
"Analoge" RGB-Strips ums Bett zu wickeln passt aber auch in diese Kategorie. Außer du braucht da unbedingt Rot ;)
Vieles hier im Forum ist Spielerei nur um der Machbarkeit willen.
Ich kenne da eine lustige Treppenbeleuchtung mit 8212...
Zitat von: Pythonf am 08 Februar 2019, 11:10:10
Doch, mittlerweile gibt es diese auch, sowohl mit warm weißen LEDs als auch mit neutral weißen LEDs. Und aus Warmweiß + RGB lassen sich problemlos alle anderen Farbtemperaturen erzeugen ;)
2812b ? wie sind die dann verschaltet?
Zitat von: lou am 08 Februar 2019, 11:13:04
das stimmt sicher. oder zumindest schwer erhältlich.
bei einer decken/leselampe o.ä. würde ich auch keine RGB strips verwenden. egal ob analog oder digital.
leds/lampen die dediziert für beleuchtung sind, sind da sicher die bessere wahl.
ich hab z.b. eine "sculli" leuchte. da steuer ich nur die helligkeit der "arme". der controller war da nötig weil die lampe "unmodifiziert" viel zu hell ist.
richtig, aber aus einem anderen Grund. Weil das Ra besser ist und 5 Meter 2812 für 30€ ist billiger China Abfall den ich überhaupt nicht nehmen würde...
UND ein anderer Grund ist die PWM Frequenz. Viele nehmen 500Hz und das ist zu wenig weil es das Gehirn stresst.
Zitat von: ext23 am 08 Februar 2019, 11:28:55
2812b ? wie sind die dann verschaltet?
Ich muss mich korrigieren, es handelt sich dabei dann um SK6812.
Zitat von: ext23 am 08 Februar 2019, 11:31:51
richtig, aber aus einem anderen Grund. Weil das Ra besser ist und 5 Meter 2812 für 30€ ist billiger China Abfall den ich überhaupt nicht nehmen würde...
UND ein anderer Grund ist die PWM Frequenz. Viele nehmen 500Hz und das ist zu wenig weil es das Gehirn stresst.
ach. und 15E für analoge ist also super? merkwürdige logik. der preis war doch dein kriterium.
kauf dir mal teure und billige. und vergleiche dann.
manchmal ist wissen besser als raten.
500hz nehmen die, die nicht mehr "schaffen" per controller oder einen FILTER/integrator am PWM ausgang haben.
ich kann die empfehlen. bisher 8 geordert. alle okay. sehr gute quali für "home usage".
https://www.amazon.de/Streifen-Traumfarbe-Individuell-Adressierbar-Wasserdicht/dp/B0744C1ZMG
ich vermute die meisten defekte tauchen auf weil leute da zuviel rumbiegen und damit die kupferlayer/kontakte zerstören oder halt nicht löten können. oder noch schlimmer: diese superdämlichen schneideclips verwenden.
Zitat von: lou am 08 Februar 2019, 11:55:06
ach. und 15E für analoge ist also super? merkwürdige logik. der preis war doch dein kriterium.
Ka, meine haben 175 Euro gekostet, 5 Meter. Osram. Sind aber auch Industrie-Bänder die eben für Lichttechnik benutzt werden. Bin mit denen sehr zufrieden und kein Vergleich zu den billigen Abfall. Wenn man weiß wie das in China läuft weiß man auch was man bei Ali Express und Co bekommt. Osram kommt auch aus China, eventuell auch aus demselben Werk. Aber wie gesagt da steck ja was hinter. Auch in China ist die ISO 9001 schon angekommen.
Und da reden wir bei WS2811 Controller basierten nicht mehr von 175 Euro pro 5 Meter sondern von dem 3 fachen ;-) Das was man zu den Preisen bekommt die wir kennen ist eben der Abfall. Der natürlich für Laien auch funktioniert bzw. im Hobby-Bereich erst recht.
Die WS2811 basierten Bänder egal ob billig oder teuer haben den Vorteil, dass die in der Regel mit 5V versorgt werden. Da ist die Verlustleistung etwas geringer als bei den normalen 12V Varianten. Natürlich muss man dann alle paar Meter neu einspeisen sonst ist der Spannungsabfall zu groß.
Wegen den 500Hz ist glaube nicht weil sie nicht mehr können, die können locker alle mehr. Aber dann braucht man auch eine gute EMV, und das vergessen viele bzw. wissen nicht wie man das berechnet. Ist ja auch nicht so einfach. Wenn das Signal zu eckig ist, bekommt man schnell Probleme.
/Daniel
Zitat von: ext23 am 08 Februar 2019, 12:05:35
1)
...Natürlich muss man dann alle paar Meter neu einspeisen sonst ist der Spannungsabfall zu groß...
2)
...dann braucht man auch eine gute EMV, und das vergessen viele bzw. wissen nicht wie man das berechnet...
/Daniel
1) nö braucht man nicht. habs schon öfter gemessen. die digitalen haben sogar systematisch mehr stromtragfähigkeit da mehr kupfer/mm. vergleiche die leiterbahnen! es sind weniger = fetter :)
2) je lokaler die pwm/dac ist desto weniger emission. (siehe oben, filter etc). bei digital "ballert" eben nicht der ganze strip !!
beispiel für ein paar 100 leds die mit 20A angesteuert werden:
analog: der GANZE strip wird komplett im GLEICHTACKT mit x kHz ausgesteuert. = 20A "sendeantenne" mit 5 meter. nur kHz, aber fette leistung.
digital: die leds werden LOKAL (sub-mm bereich) ASYNCHRON per pwm/dac ausgesteuert. = viele kleine, lokale, unkorrelierte emissonen mit 10-20mA typisch
was "emittiert" spektral wohl mehr ? :)
und das netzteil freut sich auch wenn der strom asynchron/zeitmässig verteilt gezapft wird....
der trick ist zu verstehen, dass die leds zwar digital/synchron programmiert werden (Hz), aber die effektive, lokale ansteuerung asynchron ist (kHz). denn die lokalen oszillatoren in den WS2812 controllern sind NICHT synchronisiert. (warum auch)
oder anders: die analogen strips erzeugen scharfe, starre phasen per pwm, die digitalen eine verteilte phasenwolke.
Zitat von: lou am 08 Februar 2019, 12:18:51
1) nö braucht man nicht. habs schon öfter gemessen. die digitalen haben sogar systematisch mehr stromtragfähigkeit da mehr kupfer/mm. vergleiche die leiterbahnen! es sind weniger = fetter :)
2) je lokaler die pwm/dac ist desto weniger emission. (siehe oben, filter etc). bei digital "ballert" eben nicht der ganze strip !!
Naja hängt vermutlich vom Stripe ab, bei vielen ist nach 2 Metern schon Schluss mit 3%. Die Helligkeit ist dann schon sehr inhomogen verteilt am Ende.
Und wegen dem PWM, "Jain", aber du hast ja studiert da weißt du das sicher wo das Problem ist ;-) Davon mal abgesehen die WS2811er haben auch unter 500Hz... da gibt es noch keine merklichen EMV Probleme. Deswegen würde ich die auch nicht unbedingt nehmen für Wohnzimmer/Schlafzimmer. Und schon gar nicht bei Babys. Wie dem auch sei, bei einigen Bastel Sachen hier im Forum kann man nur hoffen das nie die Behörde vor der Tür steht ^^
Aber ist ja auch egal, Fakt ist ja die kann man natürlich nehmen, man nimmt die Last aus dem Controller. Dennoch bin ich der Meinung wenn man keine Animationen macht, ist das mit Kanonen auf Spatzen schießen. Da sollte man das lieber programmiertechnisch sauber lösen bzw. extra Hardware nehmen so wie du es gemacht hast.
Viel wichtiger ist es auf gute Qualität zu achten. Wenn die einzelnen R G B LED Dies zu weit auseinander sind nützen einem die besten Stripes nichts. Dann muss man mit Diffusor arbeiten und das ist auch nicht der Hit, und ich persönlich bekommt eine Kriese wenn ich Prisma Schatten sehe.
>Ich muss mich korrigieren, es handelt sich dabei dann um SK6812.
Wie? Der ist doch auch nur 3 Kanal ?!? Wenn man RGB + W (WW) haben möchte, braucht man ein 4 Kanal chip oder man setzt 3 Kanal und dahinter einen der die nächsten 3 W LEDs bedient. Aber das ist ja dann schon eine Sonderlocke in der Ansteuerung. Ich dachte da eher ein an single chip LED mit RGB+W... aber das gibt es noch nicht oder?
/Daniel
Zitat von: ext23 am 08 Februar 2019, 12:59:37
Wie? Der ist doch auch nur 3 Kanal ?!? Wenn man RGB + W (WW) haben möchte, braucht man ein 4 Kanal chip oder man setzt 3 Kanal und dahinter einen der die nächsten 3 W LEDs bedient. Aber das ist ja dann schon eine Sonderlocke in der Ansteuerung. Ich dachte da eher ein an single chip LED mit RGB+W... aber das gibt es noch nicht oder?
/Daniel
Einfach mal Google befragen: Der erste Link bei Amazon führt zu diesen https://www.amazon.de/BTF-LIGHTING-Nat%C3%BCrliches-Individuell-adressierbar-nicht-wasserdicht/dp/B01N5ATQZT (https://www.amazon.de/BTF-LIGHTING-Nat%C3%BCrliches-Individuell-adressierbar-nicht-wasserdicht/dp/B01N5ATQZT)
Wie sie angesteuert werden kann ich nicht sagen, aber ich hab sie schon gesehen und sie funktionieren!
Ich würde an dieser Stelle gerne auch mal den "billige[n] China Abfall " verteidigen! Man hat bei den LEDs zwar häufig Probleme was den CRI angeht, aber für eine indirekte Beleuchtung ist man mit einem Bruchteil von dem was man für Osram, Hue oder andere Fachhändler bezahlt unterwegs und erhält eine angenehme Ausleuchtung. Sollte dabei wirklich mal ein Kanal an einer LED kaputt gehn, dann kann man günstig das Segment austauschen. Wie schon geschrieben kommen die LEDs häufig sogar aus den selben Werken und werden zum Teil nur vorsortiert. Wenn man die Abweichungen softwareseitig korrigiert ist man meiner Meinung teilweise sogar farblich besser dabei als bei teureren Markenprodukten (man denke an die RGB-Farbgenauigkeit der E27 HUE RGBWW)!
Zitat von: Pythonf am 08 Februar 2019, 19:50:54
Einfach mal Google befragen: Der erste Link bei Amazon führt zu diesen https://www.amazon.de/BTF-LIGHTING-Nat%C3%BCrliches-Individuell-adressierbar-nicht-wasserdicht/dp/B01N5ATQZT (https://www.amazon.de/BTF-LIGHTING-Nat%C3%BCrliches-Individuell-adressierbar-nicht-wasserdicht/dp/B01N5ATQZT)
Wie sie angesteuert werden kann ich nicht sagen, aber ich hab sie schon gesehen und sie funktionieren!
Naja da findet man ja 3 Kanal ;-) Aber das sind eben auch China Chips und es gibt wohl eine spezielle Version die 4 Kanäle hat, wird SK6812 genannt, ist aber keiner. Naja, gut China eben, da hat also eine Firma was adaptiert. Aber die Dinger haben in der Tat ein Vorteil, die laufen mit reichlich 1,2kHz. Also mehr als das Doppelte von den WS2811 Serien. Aber leider wieder sehr weit auseinander die Dies, man wird also sicher Schatten sehen, sprich Diffusor nötig.
Ansonsten wie gesagt richtet sich alles an den Anwendungsfall. Bäume etc. ist billig OK, Wohnbereich und auch gerade indirekte Beleuchtung bevorzuge ich lieber Qualität als billig. Gibt immer welche die den Unterschied nicht sehen, da ist es natürlich egal, aber sonst finde ich schon das ist zu sehen. Und wer Schlafstörungen hat, sollte sich da auch mal Gedanken drüber machen und nicht gleich die Pillenbox öffnen ^^
Achso kleiner Nachtrag zum Kanal Ausfall: Ausfälle sind eher selten, und die liegen dann auch an der falschen Montage. LED Stripes MÜSSEN auf Metall geklebt werden, eloxiert oder isoliert. Macht natürlich niemand, ich auch selten. Aber die sterben leider oft den Hitzetot. Ist in den Datenblättern der Namenhaften Herstellern auch beschrieben. Vielleicht sogar in den Chinesischen nur übersetzt das unwichtige ja niemand.
Ich hab die in Alu U-Profile mit Diffusor, das macht eigentlich ordentlich Licht und der Schattenwurf passt auch. Gibt es auch in klein, sone 1,5 cm Profile, die finde ich nicht so gut aber zur Not geht das auch, ist mehr was für Sparfüchse. Sieht bei Stripes echt besser aus, egal wo. Da kann man auch die günstigen LEDs nehmen um den Lokus zu beleuchten oder den Flur, Treppen was auch immer.
Zitat von: ext23 am 08 Februar 2019, 20:15:50
Und wer Schlafstörungen hat, sollte sich da auch mal Gedanken drüber machen und nicht gleich die Pillenbox öffnen ^^
Sehr interessant, hab ich nicht gewusst. Hast du dazu belastbare Links? Habe spontan nichts gefunden.
Mit den Schlafstörungen ist eigene Erfahrung, aber Problematik ist dieselbe dahinter. Da gibt es etliche Sachen zu, ob das jetzt im Netz zu finden ist weiß ich nicht, ich bevorzuge bei solchen Sachen Bücher aus Uni Bibliotheken als verlässliche Quellen. Ist in der Regel etwas glaubwürdiger, denke ich zumindest. Es geht im Prinzip immer um dasselbe, den Einfluss von Flackern im Licht auf das Gehirn etc. Das geht los bei 50/100Hz, ergo billig Lichterketten wo die Gleichrichter/Glättung gespart wurde hin zu Anzeigeleuchten in Kraftwerken und heutzutage natürlich generell LED Beleuchtung in Haushalten und hier natürlich auch das Thema PWM und ab welcher Frequenz das Gehirn es "angeblich" nicht mehr mitbekommt. Zumindest wurde das mittels MRT und Gehirnströme belegt. Eigentlich ganz interessante Sachen die man da so liest. War mir vorher auch nicht bewusst, dass das Gehirn das Flackern sehr wohl verarbeitet auch wenn es das Auge scheinbar nicht sieht. Mit den Schlafstörungen gabs aber auch ein Buch, da ging es zwar auch um Flackern aber eigentlich mehr um die Farbanteile die man abends nicht nutzen sollte, also mischen ohne Blau etc. das ging auch über Aquarienbeleuchtung wo das angeblich auch ne rolle spielt und und und.
Ich hatte halt im Schlafzimmer auch LEDs die ich abends zum Einschlafen gedimmt habe, manchmal auch mit Farbwechsel. Und das eben mit billig Schrott bzw. billig Controllern. Ich hatte dann mal mein Ossi rangehangen und es waren zwischen 200 und 400Hz. Ich hab es dann mit eigenem Controller mit 1500Hz betrieben, ich meine es war wirklich besser aber ich habe mich dann doch gegen das Licht entschieden und mein Schlaf ist wesentlich besser. Also wer da Probleme hat, sollte dran denken. Vielleicht ist das ja auch einfach nur die Einbildung wenn man sich damit beschäftigt hat, da spielt einem das Gehirn ja auch oft ein Streich.
Aber Literatur und Studien gibt es eigentlich genug dazu.
Zitat von: ext23 am 08 Februar 2019, 22:51:03
[...]ich bevorzuge bei solchen Sachen Bücher aus Uni Bibliotheken als verlässliche Quellen. Ist in der Regel etwas glaubwürdiger, denke ich zumindest.
ZitatThe fundamental retinal response can be recorded at frequencies greater than 100 Hz and the second and higher harmonic responses have measurable response frequencies as high as 200 Hz.
Aus Analysis of Nonlinearities in the Flicker ERG
Kreitz et. al. https://www.ncbi.nlm.nih.gov/pubmed/1584559 (https://www.ncbi.nlm.nih.gov/pubmed/1584559)
Allerdings sehe ich den Zusammenhang zu günstigen LED-Stripes nicht? Soweit ich das beurteilen kann befinden sich auf diesen doch neben den LEDs an elektrischen Bauteilen nur noch die Widerstände?
In jedem Fall finde ich das Thema spannend! Und bisher habe ich über die PWM-Frequenz im Zusammenhang mit gesundheitlichen Problemen noch nicht nachgedacht.
Zitat von: Pythonf am 08 Februar 2019, 23:15:18
Allerdings sehe ich den Zusammenhang zu günstigen LED-Stripes nicht? Soweit ich das beurteilen kann befinden sich auf diesen doch neben den LEDs an elektrischen Bauteilen nur noch die Widerstände?
In jedem Fall finde ich das Thema spannend! Und bisher habe ich über die PWM-Frequenz im Zusammenhang mit gesundheitlichen Problemen noch nicht nachgedacht.
Richtig, nur Widerstände und LEDs, nee das ist auch nicht so, das sind zwei paar Schuhe. Zumindest was die Stripes angeht macht das kein Unterschied (Es sei denn wir reden von den digitalen Stripes weil da gibt es schon Unterschiede in der Frequenz, aber unabhängig vom Preis). Die normalen Stripes ohne weitere aktive Elektronik haben da kein Einfluss drauf, eher die Controller die sich dann in billig und teuer Unterscheiden. Billig und teuer macht bei den Stripes nur den Unterschied des Farbwiedergabeindex und Schattenwurf etc. Willst du das deine Wurst nicht grün aussieht wie bei billigen Energiesparlampen dann solltest auf ein hohen Farbwiedergabeindex achten etc. Und da trennt sich die Spreu vom Weizen. Hat aber nichts mit Schlafstörungen und so zu tun. Das wird eher im Alter interessant wenn man nicht mehr so gut sehen kann. Das schweift hier ab, aber ich hatte meiner Oma mal eine "damals noch" Energiesparlampe gekauft, Modell Aldi... sie meinte immer sie sieht nichts, alles so dunkel. Dann bin ich zu Obeta und hab da eine gekauft nach Empfehlung und ausführlicher Erklärung der Problematik vom Personal (natürlich der 10 fache Preis), viel besser sagt sie...Ich hab kein Unterschied gesehen, meine Oma schon.... Uns haben aber 62 Jahre getrennt... Aber vergesst das mal, das muss jeder selber erfahren, egal ob billig oder teuer, leuchten tun alle. Da kann sich ja jeder kaufen was er will, nach eigenem Gusto und Einkommen. Ich geb da gerne etwas mehr für aus, aus Erfahrung.
Das Thema mit der Frequenz ist aber schon heikel. Nach dem Abgang der alten CRT Bildschirme alles etwas untergegangen. Und ich bin jemand der keine Globulies frisst oder zum Heilpraktiker geht oder Yoga macht, sprich ich glaub an diesen ganzen Blödsinn nicht, aber ich kann wieder besser pennen, ich kann also bestätigen da ist was dran am Flackern ;-)
So Off-Topic ende ;-) Falsches Forum, falscher Thread.
Zitat von: ext23 am 08 Februar 2019, 22:51:03
... Aber Literatur und Studien gibt es eigentlich genug dazu ...
bevor man nur "sucht" um vermutungen, meinungen oder gar "gefühle" bestätigt zu bekommen,
sollte man die grundlegende technik erstmal verstehen.
es ist technisch absolut irrelevant wie viel geld du ausgibst oder welche tolle marke hinter etwas steckt,
wenn led-cluster (=viel strom) mit
phasenstarrer pwm angesteuert werden hat man immer den gleichen prinzipiellen effekt:
mehr physikalische emission kann man nicht erzeugen. egal ob die per auge, hirn oder auf dem elektrischen stuhl aufgenommen werden.
eine EINKOPPLUNG funktioniert am besten wenn man mit hoher, phasenstarrer amplitude RESONANZ erzeugt.
die grobe frequenz ist also relevant (d.h. eine änderung wirkt sich aus), aber viel wichtiger ist die phase und die amplitude (höherer einfluss).
verwendet man nur ZWEI aktuatoren (z.b. LEDS),
ist der unterschied zwischen starr=synchron (z.b. analogstrip) und unkorreliert=asynchron (z.b. digitalstrip) spektral schon faktor 2.
bei 100 LEDS also systematisch faktor 100 unterschied in der spektralen emission, egal ob "chinamüll" oder "superosram".
es geht also ums schaltungskonzept.
ein unterschied im konzept hat meist erheblich
mehr auswirkungen als einzelne parameter von einzelnen devices in einer schaltung.
wer z.b. dafür sorgen will daß sein multichannel PWM controller möglichst niedere spektrale emissionen hat, sollte darauf achten das die PWMs nicht phasenstarr gekoppelt sind. (sondern z.b. relevant zueinander driften).
ein "low headache/bio mode" wäre also durchaus machbar per firmware/hardware PWM :) (vbs tut mir jetzt schon leid...)
bei digital strips gibts das "for free", rein durchs konzept der schaltung.
das ganze lässt sich übrigens recht einfach messen wenn man sich den strom über zeit/im spektrum anschaut. (z.b. oszi + fourier, oder speci).
(seeing is believing)
bei weitem viel "schlimmer" ists jedoch wenn der dutycycle der PWM instabil ist, dann flackerts halt.
das mag weder opa noch baby, logisch.
der grund sind systematische jitter/noise durch hardware (z.b. schlechte güte des ozillators) oder software (z.b. ESP8266 soft-PWM).
dreht man die PWM frequenz runter bleibt der jitter gleich gross aber die SNR steigt => weniger geflacker. aber immer noch schlechtes konzept.
ein weiterer wichtiger punkt ist es zu verstehen, dass eine supplydomain wie beim esp8266 systematisch verseucht ist. ("digital").
wird die PWM
direkt per esp-pins erzeugt,
mischt man den kompletten noise-floor der supply
direkt in die flanken der PWM.
die powerfets verstärken das nur, da sie "analog" funktionieren.
ein dedizierter PWM chip dazwischen (mit eigenem supplyblocking) entkoppelt diesen effekt maximal.
geschichte zum schmunzeln;
Prototype in: dos.h
Remarks:
Turns the speaker off after it has been turned on by a call to sound.
Was perusing the different functions this morning in my
Borland c++ compiler and ran across this tidbit in the "sound"
function description:
/* Emits a 7-Hz tone for 10 seconds.
True story: 7 Hz is the resonant frequency of a chicken's skull
cavity. This was determined empirically in Australia, where a new
factory generating 7-Hz tones was located too close to a chicken
ranch: When the factory started up, all the chickens died.
Your PC may not be able to emit a 7-Hz tone. */gruss,
lou
PS: wer meint, leds mit integriertem controller seien "kanonen auf spatzen", darf eigentlich generell keine hochintegrate verwenden in seinem leben :)
(allemeine bezeichnung: "ICs"). ich mag kerzen. kann man ohne handy oder alexa einschalten :)
Zitat von: lou am 09 Februar 2019, 07:00:04
bei digital strips gibts das "for free", rein durchs konzept der schaltung.
Die Überlagerung stand auch in einem Buch beschrieben, und wie man das Kompensieren kann etc. Da gab es aber noch keine richtigen Studien zu, aber es wurde einige andere Probleme aufgezeigt die dann wirken. Also wie du schon schreibst, manchmal ist ne Kerze mehr... Diese ganze theoretische Schei** den ich im Studium gelernt habe, da vertraue ich wenig drauf ;-)
/Daniel
Zitat von: vbs am 05 Februar 2019, 22:54:50
Bin nicht sicher, ob ich verstanden habe, was du machen willst. Wie bzw. warum MQTT, wenn man die Lampe lokal schalten will?
Ich bin mir nicht sicher, ob ich Dir geantwortet hatte.
Wenn ich lokal sage, dann meine ich durch eine lokale Interaktion, nicht notwendigerweuse durch eine lokale Regel o.ä.
Aber wenn ich über Taster ein Signal (z. B. MQTT) auslöse, dann kann jeder selbst entscheiden, was passieren soll.
Grüße,
pj
Gesendet von meinem HTC U11 mit Tapatalk
@VBS:
Kurze Rückmeldung.
Ich habe es nun mehrere Tage beobachtet. Die Testversion läuft super. Konnte keine resets beobachten.
Mit der normalen Version hatte ich die alle paar Tage mal.
Hast du dafür eine Erklärung?
Das flackern stört mich nicht.
Danke und Gruß,
Stefan
Also ein Grund für Resets ist das zu Neige gehen des Heap-Speichers. Der wiederum schwankt z.B. mit der Anzahl der TCP-Verbindungen. Ich hab jedoch keine Erklärung, warum das bei dir so häufig vorgekommen ist (1mal pro Tag). Bei mir lief auch die alte Version recht stabil und hat, wenn überhaupt, alle paar Wochen mal rebootet (Reading info-uptime gibt ja Auskunft in Sekunden).
Die haben bei Sming in den letzten Monaten sehr viel optimiert hinsichtlich Stabilität und auch bzgl. Speichernutzung. Also ich denke daher ist die aktuelle FW einfach robuster. Schön, dass sich das in deinem Fall auch so deutlich bemerkbar macht.
Die neue PWM werde ich voraussichtlich zurück drehen dann. Ist auch kein Faktor für die Stabilität. Ist für dich sichtbar, dass bei 100% Dimmstufe die LEDs jetzt heller sind? Das wäre im Prinzip der Hauptvorteil der neuen PWM. Ich kann aber nicht behaupten, es gehen zu haben.
Hi Vbs,
ok das mim Heap versteh ich und macht Sinn.
Also an der max Helligkeit (100%) konnte ich nichts feststellen. Hab aber auch nicht so vorher drauf geachtet.
Hab die 60 Leds pro Meter und hab die eigentlich immer bei 30% laufen ;-)
Gruß,
Stefan
Freier Heap ist übrigens im Reading "info-heap_free" zu sehen (die info-Struktur muss man aber händisch mit "get info" updaten). Bei der alten Firmware lag der bei ungefähr 20 kB frei, jetzt mit der neuen sind es ca. 25 kB.
Ah ok, super, das checke ich mal.
Danke!
Zitat von: vbs am 12 Februar 2019, 16:32:38im Reading "info-heap_free"
Evtl. den Controller beim Ausschalten gleich mit booten, wenn der Heap zu knapp wird?
Hm, wäre ein Hack mMn. Stand jetzt gibt es da meines Wissens erstmal kein Problem mit dem Heap. Falls das nochmal hochkommen sollte, dann würde ich mir lieber wieder anschauen, was da den Heap frisst und das entsprechend versuchen zu lösen.
Zitat von: ext23 am 08 Februar 2019, 22:51:03
... Ich hatte dann mal mein *Ossi* rangehangen ...
hör mal! Das grenzt aber an Diskriminierung ;D (das muss genderneutral formuliert werden) ;D ;D ;D
Zitat von: herrmannj am 19 Februar 2019, 13:45:28
hör mal! Das grenzt aber an Diskriminierung ;D (das muss genderneutral formuliert werden) ;D ;D ;D
*lol* Entschuldigung, Asche über mein Haupt, aber ich bin ja selber einer, ich darf das. Wessis wissen doch eh nicht was das ist *lol* So jetzt haben wa alle Gender wieder inner Waage ^^
Ossi-Gender ^^
Zitat von: vbs am 13 Februar 2019, 17:07:41
Hm, wäre ein Hack mMn. Stand jetzt gibt es da meines Wissens erstmal kein Problem mit dem Heap. Falls das nochmal hochkommen sollte, dann würde ich mir lieber wieder anschauen, was da den Heap frisst und das entsprechend versuchen zu lösen.
ohne "nerven" zu wollen, ein kleiner kommentar: :)
es fühlt sich zwar erstmal an wie ein "hack", ist aber die einzige möglichkeit bei ESPs für wirklich stabilen betrieb zu sorgen.
grund:
1) ESP8266 heap-ram kann (sehr) stark fragmentiert werden durch: router reconnects, pings (ICMP), client/master port-open/close etc. das ganze ist auch abhängig und nicht 100% systematisch vorhersehbar durch die typen der WIFI libs die verwendet werden. egal ob sync oder async. bei einfachen (client) tests sieht man das erstmal nicht. daher sind aggressive stress-tests empfehlenswert. (z.b. 100x open/close consecutive). dabei geht es nicht darum ob die firmware das kann, sondern schwachstellen zu finden, die im normalen betrieb definitiv sporadisch auftreten können.
2) ESP8266 wifi states lassen sich nicht 100% detektieren/handlen. es gibt states in denen zwar "connected" reported wird (RSSI ok etc), das wifi modul ist aber offline. es muss also wirklich die effektive verbindung (port) gecheckt werden. (z.b. mit ping-timeout)
werden diese states nicht abgedeckt ist es nur eine frage der zeit bis der ESP in einen deadlock fällt. (permanent "offline"). manchmal 3x am tag. manchmal nur alle 5 tage etc. (je nach lan traffic etc)
beide states/modi kann man mit einem simplen "desaster check" kontinuierlich erfassen (z.B. alle 1000ms) und so bei bedarf automatisch rebooten.
exceptions (z.b. low heap) sind zu 100% zu vermeiden, da der (automatische) reboot hier niemals zuverlässig funktioniert. (verständlich)
mache ich so schon sehr lange für meine ESP devices und erreiche damit 100% uptime (= zero deadlocks) seit >1 Jahr. (leuchten, powermeter, etc)
gruss,
lou
if ( DESASTER_CHECK_ACTIVE ) // check every 1000ms
{
DESASTER_BYTE = ((micros() - WS_EVT_T) / 1e6 > 5/*sec*/) << 7 // DESASTER 0x80 = LAST WS event > 5 sec
|
(HEAP < 10000) << 6 // DESASTER 0x40 = HEAP RAM < 10k
;
if ( DESASTER_BYTE && !wantReboot )
{
logf_P(PSTR("DESASTER %02X ############### \n"), DESASTER_BYTE);
{
SPIFFS_MOUNT = SPIFFS.begin();
SPIFF_F0 = SPIFFS.open("/boot.info", "w");
log_head(); logf_P(PSTR("LOG SPIFF WRITE FILE ... %s\n"), SPIFF_F0.name());
SPIFF_F0.printf_P(PSTR("DESASTER %02X"), DESASTER_BYTE);
SPIFF_F0.close();
wantReboot = true; // IN MAIN LOOP (1Hz): if (wantReboot) { delay(200); ESP.restart(); }
}
}
}
Hi Lou,
hast Du Code Schnipsel für uns? Hört sich sinnvoll an!
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: RaspiLED am 21 Februar 2019, 11:55:03
Hi Lou,
hast Du Code Schnipsel für uns? Hört sich sinnvoll an!
Gruß Arnd
... gerade noch angehängt ... ist natürlich nicht direkt kompatibel zu der firmware die hier verwendet wird, aber die variablen-namen & kommentare sollten halbwegs verständlich sein. I hope :)
ich verwende bei mir websockets (WS) für den "ping/alive-check". würde natürlich auch mit anderen verbindungstypen gehen.
Daran wäre ich auch interessiert.
Gesendet von iPhone mit Tapatalk
Klingt schon schlüssig und aber auch recht dramatisch. Bin noch nicht so sicher, wie ich das einordnen soll. Man müsste das wohl mal im Kontext der Firmware bzw. Controller hier bewerten. Ich alleine bin da wohl nicht repräsentativ, aber ich kann mich bei mir an keinen Fall erinnern, bei dem der Controller rebooten wollte und nicht wieder kam. Ich hoffe, ich habe nix unterschlagen, aber ich hab da auch von Usern keine Beschwerden gehört.
Das Problem betrifft dann ja wohl sämtliche ESP-Firmwares. Hab da mal etwas gegoogelt zu dem Thema, aber eigentlich nichts greifbares gefunden. Was nicht heißen soll, dass es da nichts gibt. Vielleicht hast du ein paar Links zum Thema?
Zitat von: vbs am 22 Februar 2019, 13:05:45
1) ... Ich alleine bin da wohl nicht repräsentativ...
2) ... Das Problem betrifft dann ja wohl sämtliche ESP-Firmwares...
3) ... Vielleicht hast du ein paar Links zum Thema?
1) darum die stress-test-empfehlung. bei "echter" entwicklung wird testing oft irgendwann wichtiger als die hard/software entwicklung selbst.
2) würde ich nicht so bewerten. das "problem" ist vielmehr die inhärente challenge von wifi ansich. es geht auch immer um die komplette infrastruktur. niemals nur um ein device selbst.
das sieht man z.b. wenn man die gleichen devices an qualitativ stark unterschiedlichen routern betreibt.
robuste devices (z.b. eine fritzbox oder ein handy) führen definitiv reboots/restarts von bestimten submodulen aus (uCs). nur "sieht" das der user nie.
wifi hat viele komplexe layer. die idee die firmware so gut zu machen daß sie auf jeder ebene in jedem use case (z.b. einem "RX-frame-abriss") alles robust abfängt ist ziemlich aussichtslos.
darum hat jeder uC - egal wie simpel - auch einen watchdog, brown-out detector, etc. (beim ESP z.b. der LOOP-WDT).
diese mechanismen sind nicht (nur) für "schlampige programmierer"... auch wenns erstmal so scheint ;)
3) infos im internet zu systeme wie raspberry oder ESP8266 stammen zu 99% von enthusiasten wie schülern, studenten oder eben hobbyisten.
da geht es so gut wie nie um 100%ige verfügbarkeit sondern eher um machbarkeit und "education".
im "kollektiven bewusstsein" (= google) tauchen echte details dazu so gut wie nie auf. grund:
a) - systeme die derlei probleme haben zeigen diese nur sporadisch z.b. alle paar monate. eine wirkliche analyse und ein nachweis ist also komplex bis unmöglich mit normalen mitteln.
b) - systeme die ein gutes konzept verwenden funktionieren unauffällig. der
grund für die robustheit ist aber nicht sichtbar nach aussen oder grossartig dokumentiert.
https://github.com/arendst/Sonoff-Tasmota/issues/1760
tasmota 10-sec-WD ("safe mode System Restart procedure")
https://community.home-assistant.io/t/watchdog-device-using-sonoff-with-tasmota/83587
"If a device crashes randomly every 3 or 6 months, my life is too short to start debugging it."
du hast recht. es "klingt" dramatisch. aber im kern macht der "desaster mode" nur eines. er verwendet
"heap-schwelle" und "alive-ping" zusätzlich als kriterium.
der grund ist, daß der WD standardmässig (arduino libs) viel abfängt, aber eben nicht alle states in jeder beliebigen firmware-implementierung. (feature set)
rein technisch gehören dazu auch die wifi-libs selbst. und deren quali schwankt auch von release zu release.
noch ein beispiel aus erfahrung:
jeder "port open" kann so grob 400 bytes from heap abzwacken. wie limitiere ich das?
natürlich denkt man erstmal daran die anzahl der möglichen ports zu limitieren. macht auch sinn.
die meisten libs geben ports/heap ja auch wieder frei wenn länger nix passiert.... (je nach fragmentierung / timing)
aber diese funktion hat eine gewisse latenz / benötig cpu-zeit und ist stark abhängig von den ref-libs. im schlimmsten falls sinkt die robustheit dadurch sogar.
der (zusätzliche) heap-check ist für beide punkte erheblich effizienter. (schnell, zuverlässig, unabhängig von den (wifi)libs)
Ok, danke dir, ist schon interessant.
Nur so richtig Handlungsbedarf sehe ich da ehrlich gesagt (noch) nicht, da es zumindest bei mir wenig/nie auftritt. Wenn es Leute gibt, die da konkret Probleme an der Ecke haben, dann bitte Bescheid sagen. Dann muss man da weiter sehen.
Zitat von: vbs am 26 Februar 2019, 20:41:41
Ok, danke dir, ist schon interessant.
Nur so richtig Handlungsbedarf sehe ich da ehrlich gesagt (noch) nicht, da es zumindest bei mir wenig/nie auftritt. Wenn es Leute gibt, die da konkret Probleme an der Ecke haben, dann bitte Bescheid sagen. Dann muss man da weiter sehen.
sag mal @vbs, hatten wir eigentlich irgendwann mal Maßnahmen zur Verringerung der Flash Schreibzyklen getroffen? Mein Sorgen-Controller (der regelmäßig über den Bewegungsmelder getriggert wird) hat mal wieder den Geist aufgegeben und ich vermute, er braucht einen neuen ESP bzw. Flash Chip.
pj
hallo vbs - vielen Dank erstmal für deine Mühen und Einsatz für das schöne Stück Software! :- )
ich hab mit einem der Controller oft das Problem, dass er sich nicht per fhem steuern lässt - beim manuell verbinden klappt es dann eigentlich immer. Im Log sehe ich folgendes:
2019.03.14 21:51:28 3: S.Bett: EspLedController_CheckConnection: Connection lost! Last data received 86.0636839866638 s ago
2019.03.14 21:51:28 1: 192.168.178.90:9090 disconnected, waiting to reappear (S.Bett)
2019.03.14 21:52:35 1: 192.168.178.90:9090 reappeared (S.Bett)
2019.03.14 21:53:06 2: S.Bett: EspLedController_ParseBoolResult error: connect to http://192.168.178.90:80 timed out
2019.03.14 21:53:37 2: S.Bett: error read from http://192.168.178.90:80 timed out retrieving config
2019.03.14 21:53:56 3: S.Bett: EspLedController_CheckConnection: Connection lost! Last data received 81.6138591766357 s ago
2019.03.14 21:53:56 1: 192.168.178.90:9090 disconnected, waiting to reappear (S.Bett)
2019.03.14 21:54:08 2: S.Bett: error read from http://192.168.178.90:80 timed out retrieving config
2019.03.14 21:54:08 3: S.Bett: got info response
2019.03.14 21:54:08 3: S.Bett: info response data {"deviceid":"13028322","current_rom":"0","git_version":"vbs35","git_date":"2018-08-22","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":0,"uptime":532560,"heap_free":16808,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"xxxx","dhcp":true,"ip":"192.168.178.90","netmask":"255.255.255.0","gateway":"192.168.178.1","mac":"xxxx"}}
Ist das am ehesten ein wifi-Problem!?
Dank und Gruß,
Michael
Zitat von: mike.d am 15 März 2019, 07:23:26
Ist das am ehesten ein wifi-Problem!?
Dank und Gruß,
Michael
Moin Michael,
ich hab hier bald 20 Controller am laufen und hatte bisher für die Leuchten auf der Terasse auch immer mal wieder das Problem.
Ein zweiter Wifi Hotspot/Repeater für 19EUR hat es gelöst.
pj
Von hier aus schwer zu sagen, ob es ein Wifi-Problem ist. Wenn der WLAN-Empfang am Controller generell schlecht sein sollte wegen z.B. drei Wänden dazwischen, dann fände ich die Erklärung plausibel.
Kannst ja mal ein Dauer-Ping laufen lassen und gucken, ob da auch Pakete verloren gehen... oder gucken, ob sich der Controller am AP regelmäßig neu anmeldet oder sowas.
Zitat..Von hier aus schwer zu sagen, ob es ein Wifi-Problem ist...
Das lässt sich einfach nachvollziehen, wenn man im Syslog des Raspis (/var/log) zum betreffenden Zeitpunkt nachschaut ...
Jürgen
Zitat von: juergs am 15 März 2019, 18:10:25
Das lässt sich einfach nachvollziehen, wenn man im Syslog des Raspis (/var/log) zum betreffenden Zeitpunkt nachschaut ...
Jürgen
darin siehst Du aber nicht, ob die LED Controller ein WiFi Problem haben, und darum geht es ja.
pj
Hallo PJ,
wenn Du sicher bist, dass es ein Controller-WiFi Problem ist....
Wollte nur eine weitere Diagnosemöglichkeit anzeigen, da ich auch Probleme mit Verbindungs-Abrissen habe ...
z.B.:
https://raspberrypi.stackexchange.com/questions/62932/avahi-seems-to-stop-publishing-refreshing-services-after-a-while (https://raspberrypi.stackexchange.com/questions/62932/avahi-seems-to-stop-publishing-refreshing-services-after-a-while)
https://raspberrypi.stackexchange.com/questions/79359/ethernet-interface-interrupts-connection (https://raspberrypi.stackexchange.com/questions/79359/ethernet-interface-interrupts-connection)
Kann das aber noch nicht sauber beurteilen, habe aber zeitliche Übereinstimmungen mit dem avahi-daemon unter Stretch und den Abrissen.
In meinem Fall allerdings UDP und da gebe ich Dir recht, muss nicht mit Eurem Problem koherent sein ;)
J.
Dass da überhaupt ein Raspberry beteiligt ist, ist aber nur eine Vermutung oder hab ich was übersehen?
Da ich jetzt einen WW/CW-Stripe hier habe, habe ich gemerkt, dass im WWCW-Modus beim Interpolieren der gewünschten Farbtemperatur überhaupt nicht die konfigurierten Werte für WW und CW verwendeten wurden, sondern hart kodierte (2700 und 6000). Auch der Range-Check im FHEM-Modul war nicht korrekt.
Also WW/CW müsste in der 4.0.0-rc4 jetzt funktionieren wie ursprünglich gedacht.
http://rgbww.dronezone.de/testing/version.json
Zitat von: vbs am 18 April 2017, 09:26:13
Die URL zum Installieren der Firmware (über Webinterface) ist diese:
http://rgbww.dronezone.de/release/version.json (http://rgbww.dronezone.de/testing/version.json)
Kleiner Hinweis: Auf der ersten Seite ist der Link zum release falsch. Er zeigt auf testing.
Hallo,
Bald wird ja wieder eine Großbestellung der Controller ausgelöst und in der neuen Version sind die nicht genutzten Pins auf einen Header gelegt.
Besteht seitens der Firmware/FHEM-Moduls die Möglichkeit diese Pins zu nutzen? Ließ sich das einbinden, falls nicht?
Ich würde gern noch ein Relay darüber schalten, um neben den RGB-Streifen auch eine "normale" Lampe schalten zu können.
Grüße, Stephan
Gesendet von iPhone mit Tapatalk
Sowas ähnliches war ja schonmal Thema hier im Thread vor ein paar Wochen. Da ging es um Taster am Controller, wenn ich mich richtig erinnere. Sowas ist im Moment nicht implementiert, aber ist möglich. Die Anforderung daran sind vielfältig (Input, Output, Events, MQTT etc.). Kann da nichts versprechen, da im Moment die Zeit für private Projekte ziemlich dünn ist.
Zitat von: balli1187 am 28 März 2019, 19:46:46
Hallo,
Bald wird ja wieder eine Großbestellung der Controller ausgelöst und in der neuen Version sind die nicht genutzten Pins auf einen Header gelegt.
Besteht seitens der Firmware/FHEM-Moduls die Möglichkeit diese Pins zu nutzen? Ließ sich das einbinden, falls nicht?
Ich würde gern noch ein Relay darüber schalten, um neben den RGB-Streifen auch eine "normale" Lampe schalten zu können.
Grüße, Stephan
Gesendet von iPhone mit Tapatalk
Das kann ich schnell beantworten:
Die verfügbaren pins sind: GPIO 0, 2 und 16 sowie RX und TX. Vcc ist nicht auf dem Header verfügbar. Die GPIO 0 und 2 sind üblicherweise als Ausgang eher ungeeignet, weil sie zum Boot Zeitpunkt auf definierten Potentialen liegen müssen, für die RGBWW Firmware gilt das gleiche für GPIO 16 (CLR).
Wenn Du Tasmota nutzt kannst Du GPIO 16 sowie RX und TX fast völlig frei verwenden.
Ich denke, der Einfachheit halber sollten wir für die Standard - Firmware dabei bleiben, die drei pins als Eingänge (Button 0-3) zu nutzen.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Okay, dann werde ich mal schauen mit welcher Firmware ich am ehesten and Ziel komme
Bedarf an zusätzlichen Tastern besteht bei mit nicht aber ein weiterer Ausgang wäre halt super.
Ich hätte auch schon überlegt den WW oder CW-Kanal für zu nutzen, da ich an besagter Stelle eh nur RGB nutzen werde.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 30 März 2019, 11:50:19
Okay, dann werde ich mal schauen mit welcher Firmware ich am ehesten and Ziel komme
Bedarf an zusätzlichen Tastern besteht bei mit nicht aber ein weiterer Ausgang wäre halt super.
Ich hätte auch schon überlegt den WW oder CW-Kanal für zu nutzen, da ich an besagter Stelle eh nur RGB nutzen werde.
Gesendet von iPhone mit Tapatalk
schau Dir mal Tasmota an, damit kannst Du sowas ganz flexibel konfigurieren.
Wenn Du die MOSFETS für die beiden Weiß Kanäle nicht bestückst, kannst Du die natürlich auch verwenden. Wenn Du sie bestückst bedenke, dass die Last zwischen +12V und dem Eingang hängen muss, der MOSFET also gegen Masse schaltet.
pj
Zitat von: pjakobs am 31 März 2019, 18:46:26
schau Dir mal Tasmota an, damit kannst Du sowas ganz flexibel konfigurieren.
Wenn Du die MOSFETS für die beiden Weiß Kanäle nicht bestückst, kannst Du die natürlich auch verwenden. Wenn Du sie bestückst bedenke, dass die Last zwischen +12V und dem Eingang hängen muss, der MOSFET also gegen Masse schaltet.
pj
Werd ich mir dann anschauen, wie der Controller mit Tasmota läuft. Der Hauptgrund zum Wechsel auf euren Controller sind die Weichen farbwechsel und dimm-ups/down. Wenn das mit Tasmota zufriedenstellend geht, klasse.
Das Potential ist kein Problem. Meine Standardremais werden eh mit 12V betrieben, also sollte das passen, aber auch hier Danke für den Hinweis.
Gesendet von iPhone mit Tapatalk
Zitat von: pjakobs am 30 März 2019, 11:17:56die drei pins als Eingänge (Button 0-3) zu nutzen.
Ein Programmierer zählt am Flughafen seine Koffer: "Null, Eins, Zwei. Mist, einer fehlt!"
Zitat von: Per am 01 April 2019, 11:42:16
Ein Programmierer zählt am Flughafen seine Koffer: "Null, Eins, Zwei. Mist, einer fehlt!"
orr :D
0,1,10,11,100
nachdem mir gestern wieder einer meiner älteren Controller gestorben ist ein Tip:
In der Default Einstellung schreibt sowohl die Original, als auch die VBS Firmware den aktuellen Farbwert in den FLASH Speicher des ESP. Bekanntermaßen ist der Speicher aber in der Anzahl Schreibzyklen beschränkt, was dazu führt, dass irgendwann die Daten nicht mehr korrekt geschrieben und / oder gelesen werden können.
'Aufgrund des Software Designs unseres Controllers führt das dann dazu, dass das Dateisystem nicht mehr korrekt geladen werden kann. Das Symptom ist, dass der Controller in seinen Default Zustand zurück fällt, denn auch die Konfiguration, die man über das Web Interface vornimmt landet im FLASH. Am ehesten erkennt man das daran, dass Weiß nun nicht mehr mit den LED am Warm/Kaltweiß Kanal gebildet wird, sondern durch die RGB LED. Meistens ergibt das eine Verschiebung nach blau, ein "metallisches" Weiß.
Um das Problem hoffentlich dauerhaft zu beheben kann man in der VBS Firmware eine Default Startup Color konfigurieren. Das geht folgendermaßen:
set <LED Name> config config-color-startup_color 0,0,30
Wann immer der Controller netzseitig (oder, bei den neuen, auch durch Öffnen des "Disable" Jumpers) eingeschaltet wird, wird er nun auf die eingestellte Farbe gehen (hier: hsv 0,0,30).
Gleichzeitig wird er den aktuellen Zustand nicht mehr speichern.
Da meine Controller sowieso immer am Netz sind und über fhem gesteuert werden, ist mir der default on Zustand relativ egal. Weil ich aber z.B. meine Lichter anhand eines "twilight" devices dimme, habe ich relativ viele Änderungen und somit, im Normalfall, viele Schreibzyklen.
Ich würde diese Änderung auch allen empfehlen, die Controller z.B. über Präsenz / Bewegungssensoren steuern.
Eigentlich schadet sie für niemanden außer für die, die die Controller extern schalten.
Grüße
pj
Löst das denn das eigentliche Problem was du mit "In der Default Einstellung schreibt sowohl die Original, als auch die VBS Firmware den aktuellen Farbwert in den FLASH Speicher des ESP. Bekanntermaßen ist der Speicher aber in der Anzahl Schreibzyklen beschränkt,..." beschrieben hast? Das macht er doch trotzdem noch oder?
/Daniel
Zitat von: ext23 am 07 April 2019, 19:08:29
Löst das denn das eigentliche Problem was du mit "In der Default Einstellung schreibt sowohl die Original, als auch die VBS Firmware den aktuellen Farbwert in den FLASH Speicher des ESP. Bekanntermaßen ist der Speicher aber in der Anzahl Schreibzyklen beschränkt,..." beschrieben hast? Das macht er doch trotzdem noch oder?
/Daniel
@vbs sagte, dann wird nix geschrieben.
pj
Genau, ist im Zweifel auch hier nachzulesen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#startup-color--vbs33
Ich habe seit einiger Zeit Probleme mit meinen drei LedControllern. Diese reagieren gar nicht oder nur sehr verzögert auf Änderungen die durch das 32_EspLedController.pm:?/2019-03-21 Modul ausgelöst werden. Das hat schon mal einwandfrei funktioniert.
Direkte Steuerung über die Weboberfläche funktioniert ohne Verzögerung. Ping Zeiten sind <4 ms.
Im Log steht z. B. nach einem set LEDController-WZ off auf das der Controller nicht reagiert:
2019.04.23 22:00:00.269 4: wz_led_TV: EspLedController_CheckConnection: Connection still alive. Last data received 1.44699788093567 s ago
2019.04.23 22:00:00.481 5: wz_led_TV (Set) called with ?, busy flag is 0
name is wz_led_TV, args
2019.04.23 22:00:12.047 4: wz_led_TV: EspLedController_CheckConnection: Connection still alive. Last data received 13.225152015686 s ago
2019.04.23 22:00:14.938 5: wz_led_TV (Set) called with off, busy flag is 0
name is wz_led_TV, args
2019.04.23 22:00:14.941 5: wz_led_TV: called SetHSVColor
2019.04.23 22:00:14.943 5: wz_led_TV: encoded json data: {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
2019.04.23 22:00:14.944 5: wz_led_TV: set HSV color request: {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
2019.04.23 22:00:15.091 5: wz_led_TV (Set) called with ?, busy flag is 1
name is wz_led_TV, args
2019.04.23 22:00:17.409 5: wz_led_TV: EspLedController_ParseBoolResult
2019.04.23 22:00:17.410 2: wz_led_TV: EspLedController_ParseBoolResult error: http://LEDController-WZ/color: empty answer received
Auffallend ist 'EspLedController_ParseBoolResult error: http://LEDController-WZ/color: empty answer received
Wenn ich den Aufruf per wget vom Rechner auf dem fhem läuft durchführe erhalte ich sehr wohl eine Antwort:
{"raw":{"r":0,"g":0,"b":0,"ww":0,"cw":0},"hsv":{"h":0.00,"s":0.00,"v":0.00,"ct":2700}
[code]
Hier noch ein list des Devices:
[code]
nternals:
DEF LEDController-WZ
DeviceName LEDController-WZ:9090
FD 80
FUUID 5c432751-f33f-a4cf-e124-efe08f8001ea45af
FVERSION 32_EspLedController.pm:?/2019-03-21
IP LEDController-WZ
LAST_RECV 1556050198.46122
NAME wz_led_TV
NR 402
NTFY_ORDER 50-wz_led_TV
PARTIAL
PORT 9090
STATE opened
TYPE EspLedController
OLDREADINGS:
READINGS:
2019-04-23 21:33:18 colorMode hsv
2019-04-23 21:58:42 config-color-brightness-blue 100
2019-04-23 21:58:42 config-color-brightness-cw 100
2019-04-23 21:58:42 config-color-brightness-green 100
2019-04-23 21:58:42 config-color-brightness-red 100
2019-04-23 21:58:42 config-color-brightness-ww 100
2019-04-23 21:58:42 config-color-colortemp-cw 6000
2019-04-23 21:58:42 config-color-colortemp-ww 2700
2019-04-23 21:58:42 config-color-hsv-blue 0
2019-04-23 21:58:42 config-color-hsv-cyan 0
2019-04-23 21:58:42 config-color-hsv-green 0
2019-04-23 21:58:42 config-color-hsv-magenta 0
2019-04-23 21:58:42 config-color-hsv-model 0
2019-04-23 21:58:42 config-color-hsv-red 0
2019-04-23 21:58:42 config-color-hsv-yellow 0
2019-04-23 21:58:42 config-color-outputmode 0
2019-04-23 21:58:42 config-color-startup_color last
2019-04-23 21:58:42 config-events-color_interval_ms 500
2019-04-23 21:58:42 config-events-color_mininterval_ms 500
2019-04-23 21:58:42 config-events-server_enabled 1
2019-04-23 21:58:42 config-events-transfin_interval_ms 1000
2019-04-23 21:58:42 config-general-device_name wz_led_TV
2019-04-23 21:58:42 config-general-pin_config 13,12,14,5,4
2019-04-23 21:58:42 config-network-ap-password rgbwwctrl
2019-04-23 21:58:42 config-network-ap-secured 0
2019-04-23 21:58:42 config-network-ap-ssid RGBWW10676753
2019-04-23 21:58:42 config-network-connection-dhcp 1
2019-04-23 21:58:42 config-network-connection-gateway 0.0.0.0
2019-04-23 21:58:42 config-network-connection-ip 0.0.0.0
2019-04-23 21:58:42 config-network-connection-netmask 0.0.0.0
2019-04-23 21:58:42 config-network-mqtt-enabled 0
2019-04-23 21:58:42 config-network-mqtt-password
2019-04-23 21:58:42 config-network-mqtt-port 1883
2019-04-23 21:58:42 config-network-mqtt-server mqtt.local
2019-04-23 21:58:42 config-network-mqtt-topic_base home/
2019-04-23 21:58:42 config-network-mqtt-username
2019-04-23 21:58:42 config-ota-url http://rgbww.dronezone.de/release/version.json
2019-04-23 21:58:42 config-security-api_secured 0
2019-04-23 21:58:42 config-sync-clock_master_enabled 0
2019-04-23 21:58:42 config-sync-clock_master_interval 30
2019-04-23 21:58:42 config-sync-clock_slave_enabled 0
2019-04-23 21:58:42 config-sync-clock_slave_topic home/led1/clock
2019-04-23 21:58:42 config-sync-cmd_master_enabled 0
2019-04-23 21:58:42 config-sync-cmd_slave_enabled 0
2019-04-23 21:58:42 config-sync-cmd_slave_topic home/led1/command
2019-04-23 21:58:42 config-sync-color_master_enabled 0
2019-04-23 21:58:42 config-sync-color_master_interval_ms 0
2019-04-23 21:58:42 config-sync-color_slave_enabled 0
2019-04-23 21:58:42 config-sync-color_slave_topic home/led1/color
2019-04-23 21:33:18 ct 2700
2019-04-23 21:33:18 hsv 0,0,0
2019-04-23 21:33:18 hue 0
2019-04-23 15:18:49 info-connection-dhcp 1
2019-04-23 15:18:49 info-connection-gateway 192.168.2.1
2019-04-23 15:18:49 info-connection-ip_address 192.168.2.41
2019-04-23 15:18:49 info-connection-mac 5ccf7fa2ea11
2019-04-23 15:18:49 info-connection-netmask 255.255.255.0
2019-04-23 15:18:49 info-connection-ssid Husen
2019-04-23 15:18:49 info-current_rom_slot 0
2019-04-23 15:18:49 info-deviceid 10676753
2019-04-23 15:18:49 info-event_num_clients 1
2019-04-23 15:18:49 info-firmware vbs35b
2019-04-23 15:18:49 info-heap_free 22120
2019-04-23 15:18:49 info-sming_version 3.5.1
2019-04-23 15:18:49 info-uptime 1275540
2019-04-23 15:18:49 info-webapp_version 0.3.3-shojo7
2019-04-23 21:33:18 pct 0
2019-04-23 21:33:18 raw_blue 0
2019-04-23 21:33:18 raw_cw 0
2019-04-23 21:33:18 raw_green 0
2019-04-23 21:33:18 raw_red 0
2019-04-23 21:33:18 raw_ww 0
2019-04-23 21:33:18 rgb 000000
2019-04-23 21:33:18 sat 0
2019-04-23 21:58:37 state opened
2019-04-23 21:33:18 stateLight off
2019-04-23 21:33:18 val 0
helper:
isBusy 0
oldVal 0
cmdQueue:
lastCall:
NAME
addr http://LEDController-WZ:80
auth 0
buf
compress 1
conn
data {"q":"single","t":"500","d":"1","cmd":"fade","hsv":{"v":0,"s":"+0","h":"+0"}}
displayurl http://LEDController-WZ/color
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host LEDController-WZ
hu_blocking 0
hu_port 80
hu_portSfx
loglevel 5
method POST
path /color
protocol http
redirects 0
timeout 30
url http://LEDController-WZ/color
cmd:
cmd fade
d 1
q single
t 500
hsv:
h +0
s +0
v 0
hash:
sslargs:
Attributes:
alias LED Fernseher
defaultRamp 500
icon light_led_stripe_rgb
room HUEDevice,Multimedia,Wohnzimmer
userattr structexclude wohnung wohnung_map wz_led wz_led_map
verbose 5
webCmd hsv:toggle:on:off
widgetOverride hsv:colorpicker,HSV,hue,0,1,360,sat,0,1,100,val,0,1,100
wohnung struc_wohnung_aus_schlafen
wz_led struc_wz_leds
Hat jemand eine Idee was die Ursache sein könnte?
Zitat von: kaihs am 23 April 2019, 22:19:11
Ich habe seit einiger Zeit Probleme mit meinen drei LedControllern. Diese reagieren gar nicht oder nur sehr verzögert auf Änderungen die durch das 32_EspLedController.pm:?/2019-03-21 Modul ausgelöst werden. Das hat schon mal einwandfrei funktioniert.
moin, kannst Du mal untersuchen, ob die Verzögerung innerhalb FHEM auftritt oder ob der Controller verzögert reagiert?
Ich hab das auch manchmal und in meinem Fall habe ich deutlich FHEM im Verdacht. Bestärkt wird das dadurch, dass auch andere Devices (z.B. Sonoff) nur verzögert schalten.
pj
Genau, wäre auch meine Vermutung.
Mach doch mal eine Minimal-FHEM-Config mit nur einem RGB-Controller drin und prüfe, ob das dann weiterhin auf tritt. Falls nicht, dann mal mit apptime prüfen, welche Geräte in deiner normalen Config die Delays verursachen.
hey, @vbs, nachdem ich heute den Produktionsauftrag für die 1000 Controller gegeben habe, können wir nochmal kurz über die freien GPIOs reden?
0, 2 und 16 sind jetzt auf den Header rausgezogen mit der Idee, dass man da Taster ran hängen kann.
Man könnte damit natürlich einerseits lokale Events auslösen (Licht an/aus, dimmen etc - das geht in Tasmota) aber ich fänd es besser, wenn das einfach einen Event im FHEM Device auslösen könnte, den man dann per Notify / Doif abfangen kann.
Siehst Du einen Weg, das sauber und ohne großen Aufwand zu implementieren? Du hast ja eh schon einen aktiven push event server eingebaut, der könnte doch auch Events für diese Pins liefern, oder?
pj
Zitat von: pjakobs am 24 April 2019, 09:22:06
moin, kannst Du mal untersuchen, ob die Verzögerung innerhalb FHEM auftritt oder ob der Controller verzögert reagiert?
Ich hab das auch manchmal und in meinem Fall habe ich deutlich FHEM im Verdacht. Bestärkt wird das dadurch, dass auch andere Devices (z.B. Sonoff) nur verzögert schalten.
pj
Danke für die Hinweise. Es war ein LacrosseGateway das disconnected war und dadurch hohe Last erzeugte.
Hatten da ja schon ein paar Mal drüber geredet, wenn ich mir recht erinnere... Gab da auch schon einen anderen User, der gerne die GPIOs auch als Ausgänge nutzen wollte. Das alles unter einen Hut zu bringen, ist machbar, aber macht schon etwas Arbeit. Es müsste dann per Config recht flexibel konfigurierbar sein. Die Firmware läuft außerdem ja auch auf anderer Hardware. Ich kann da momentan nichts versprechen.
Ein anderes Problem, das ich habe ist, dass die letzte "stable" Firmware über 6 Monate her ist. Seitdem hat sich in der "RC"-FW einiges getan (inkl. größerem Sming-Update). Ich hab die RC bei mir laufen aber es gab noch nicht genug Rückmeldungen, dass ich mich trauen würde, den Stand als "stable" zu deklarieren. Ich würde da in dem jetzigen Zustand ungern noch weitere Baustellen aufmachen.
Zitat von: vbs am 26 April 2019, 13:25:20
Hatten da ja schon ein paar Mal drüber geredet, wenn ich mir recht erinnere... Gab da auch schon einen anderen User, der gerne die GPIOs auch als Ausgänge nutzen wollte.
Ich glaube, dass bei der gegebenen Hardware die IOs aus Ausgänge wenig sinnvoll sind.
Zitat von: vbs am 26 April 2019, 13:25:20
Das alles unter einen Hut zu bringen, ist machbar, aber macht schon etwas Arbeit. Es müsste dann per Config recht flexibel konfigurierbar sein. Die Firmware läuft außerdem ja auch auf anderer Hardware.
Wie aufwendig wäre es denn, den Status "einfach" in Form von drei boolschen Readings darzustellen?
Zitat von: vbs am 26 April 2019, 13:25:20
Ich kann da momentan nichts versprechen.
Ein anderes Problem, das ich habe ist, dass die letzte "stable" Firmware über 6 Monate her ist. Seitdem hat sich in der "RC"-FW einiges getan (inkl. größerem Sming-Update). Ich hab die RC bei mir laufen aber es gab noch nicht genug Rückmeldungen, dass ich mich trauen würde, den Stand als "stable" zu deklarieren. Ich würde da in dem jetzigen Zustand ungern noch weitere Baustellen aufmachen.
Ich hab die 4.0 jetzt auf die beiden Sampels gepackt und werde die mal ausgiebig testen.
pj
Für mich wäre das Hauptfeature eines lokalen Tasters, das man das Device noch schalten kann, wenn FHEM/MQTT ausfällt. Um da flexibel zu sein, müsste man am besten einen JSON-Befehl (gemäß API) einem Taster zuweisen können. Ist als JSON-Befehl wiederum etwas sperrig. Einfacher wäre es in Form eines FHEM-Befehls. Die Syntax versteht der Controller wieder aber nicht von sich aus... :o
na ja, ein Schritt nach dem anderen.
Mit einer Schleife über FHEM (oder von mir aus auch gerne einem MQTT topic) ließe sich das jetzt schonmal remote lösen und später dann richtig machen.
pj
[edit]
noch ein Gedanke: ein Taster könnte ja einfach eine ein/aus Funktion haben und dann die gleiche Helligkeit/Farbe aktivieren, wie beim normalen Schalten über FHEM - zumindest wenn eine default Farbe vorgegeben ist. Wenn das Teil über FHEM ausgeschaltet ist und den aktuellen Zustand speichert, dann geht das natürlich nicht.
Diese Funktion müsste natürlich deaktivierbar sein, wenn ich über ein NOTIFY schalten will.
und mal zum rc: ich hab jetzt mal acht meiner Controller auf den Testing Pfad gesetzt. Ich werde Bericht erstatten.
pj
Moin, im github steht auch was von udp Verbindung aber leider nichts genaueres. Ist da schon etwas in der Richtung eingebaut? Multicast wäre nett für meine Zwecke.
Aus Interesse worüber kommuniziert der der fhem mit dem Controller? (tcp/json?)
Mqtt war ja nur für device Sync untereinander richtig?
Gruß Alex
Gesendet von meinem SM-G930F mit Tapatalk
Zitat von: kmxak am 21 Mai 2019, 10:02:11
Moin, im github steht auch was von udp Verbindung aber leider nichts genaueres. Ist da schon etwas in der Richtung eingebaut? Multicast wäre nett für meine Zwecke.
Hm, habe im Github nichts zu UDP gefunden gerade. Hast du einen Link? Sowas ist momentan nicht implementiert und auch eigentlich ncihts geplant in der Richtung.
Zitat von: kmxak am 21 Mai 2019, 10:02:11
Aus Interesse worüber kommuniziert der der fhem mit dem Controller? (tcp/json?)
Im Normalfall wird JSON geredet (über HTTP/TCP). Der Event-Server redet auch JSON aber direkt auf TCP (ohne HTTP). Und es gibt eben noch MQTT anstelle von HTTP aber dann auch wieder mit JSON-Inhalten.
Zitat von: kmxak am 21 Mai 2019, 10:02:11
Mqtt war ja nur für device Sync untereinander richtig?
Genau. Jedoch ist der Controller ein "MQTT-Slave" in dem Moment. Ihm ist eigentlich egal, ob die MQTT-Steuerkommandos von einem anderen Controller kommen oder von etwas anderem. Also du kannst auch selbst die MQTT-Master-Kommandos per Hand versenden und der Controller wird drauf reagieren.
Ja in deiner Wiki steht tcp/udp mit einer leeren Seite. Dachte da gäbe es evtl etwas. Aber gut das bringt mich schon mal ein gutes Stück vorwärts.
Gesendet von meinem SM-G930F mit Tapatalk
@vbs: Habe jetzt einen Controller mit deiner FW + Modul seit 2 Tagen laufen. Funktioniert soweit gut, Danke für die Arbeit.
Was mir aufgefallen ist:
- mein Device behält das attr Room nicht. Habe mich erst gewundert und dachte ich hätte es vergessen aber beim dritten mal muss es an was anderem liegen?
- mein Device habe ich nach dem ersten testen umbenannt und unter config-general-device_name ist immer noch der ursprüngliche Namen. Ist das so gewollt oder egal?
- Wäre es möglich das Modul mit basic auth kompatibel zu machen? Ich weiß es schützt nur bedingt aber zumindest kann nicht jedes Spielkind in meinem Netz am Licht basteln.
Gruß
Eisix
Zitat von: Eisix am 17 Juni 2019, 20:39:54
- mein Device behält das attr Room nicht. Habe mich erst gewundert und dachte ich hätte es vergessen aber beim dritten mal muss es an was anderem liegen?
Hm, keine Idee. Hab ich nichts mit zu tun, denk ich.
Zitat von: Eisix am 17 Juni 2019, 20:39:54
- mein Device habe ich nach dem ersten testen umbenannt und unter config-general-device_name ist immer noch der ursprüngliche Namen. Ist das so gewollt oder egal?
Das FHEM-Modul weist automatisch beim Verbinden den FHEM-Namen zu. Passt das für dich nicht? Wäre vermtl. wenig Aufwand, das einstellbar zu machen.
Zitat von: Eisix am 17 Juni 2019, 20:39:54
- Wäre es möglich das Modul mit basic auth kompatibel zu machen? Ich weiß es schützt nur bedingt aber zumindest kann nicht jedes Spielkind in meinem Netz am Licht basteln.
Ja, ist vermutlich machbar. Würde aber vermtl. so enden, dass das Passwort in FHEM als normales Attribut im Klartext sichtbar wäre. Ist das problematisch?
Beim verlorenen Attribut tippe ich ja auf ein rereadcfg bevor alles gespeichert wurde. Meine Controller laufen seit bald drei Jahren und ich hatte das Problem noch nicht.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hallo,
Zitat
- mein Device behält das attr Room nicht. Habe mich erst gewundert und dachte ich hätte es vergessen aber beim dritten mal muss es an was anderem liegen?
Hm, keine Idee. Hab ich nichts mit zu tun, denk ich.
Denke auch nicht das es am Modul liegt, vielleicht an mir. Werde es im Auge behalten.
Zitat
Zitat von: Eisix am Gestern um 20:39:54
- mein Device habe ich nach dem ersten testen umbenannt und unter config-general-device_name ist immer noch der ursprüngliche Namen. Ist das so gewollt oder egal?
Das FHEM-Modul weist automatisch beim Verbinden den FHEM-Namen zu. Passt das für dich nicht? Wäre vermtl. wenig Aufwand, das einstellbar zu machen.
Stört mich erstmal nicht. Was passiert wenn ich den nächsten mit dem gleichen temporären Namen einbinde und dann umbenenne? Vermute mal nichts da die Kommunikation ja eh über IP/MQTT erfolgt und der Name wahrscheinlich nicht relevant ist.
Zitat
Zitat von: Eisix am Gestern um 20:39:54
- Wäre es möglich das Modul mit basic auth kompatibel zu machen? Ich weiß es schützt nur bedingt aber zumindest kann nicht jedes Spielkind in meinem Netz am Licht basteln.
Ja, ist vermutlich machbar. Würde aber vermtl. so enden, dass das Passwort in FHEM als normales Attribut im Klartext sichtbar wäre. Ist das problematisch?
Das würde mir reichen. Wenn jemand es in Fhem lesen kann, kann er so oder so noch viel mehr machen als am Licht spielen.
Gruß
Eisix
Ich hab mal eine Firmware 4.1.0-rc1 hochgeladen (Testing-Kanal):
* Secured API jetzt lauffähig
* Custom Device Name
* Sming 3.8.0
Docs:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#secured-api--410
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#device-name
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#secured-api
Sming hat wieder mal ziemlich viele API-Änderungen seit 3.7.1 eingebaut. Ich hoffe, ich hab alles korrekt angepasst. Wer mag kann gerne mal testen (vor allem die Secured API). Bin dankbar für Rückmeldungen.
cool, danke für die schnelle Implementation!
Ich geh davon aus, dass für 4.0/4.1 fhem-Modul und Firmware kreuzweise kompatibel sind, solange die neuen Features nicht genutzt werden?
Und auf die Gefahr hin, dass ich nerve: lass uns nochmal darüber reden, wie wir die zusätzlichen GPIOs verwenden ;-)
pj
Was sind denn die "neuen" Features? Gpio pins nutzen ist wohl echt für die meisten das wichtigste. Hätte auch gerne welche genutzt :) (auch wenn ich es nicht nutze und unabhängig vom fhem würde auf dem Controller auch tasmota/espeasy laufen incl. Lichtsteuerung die funktioniert?)
Gesendet von meinem SM-G930F mit Tapatalk
Zitat von: kmxak am 21 Juni 2019, 09:28:21
Was sind denn die "neuen" Features? Gpio pins nutzen ist wohl echt für die meisten das wichtigste. Hätte auch gerne welche genutzt :)
Na das, was @vbs oben beschrieben hat: password secured API und custom names. Ich gehe davon aus, dass das "alte" Modul problemlos mit der neuen testing Firmware läuft, die Features aber nicht nutzen kann und dass das "neue" Modul damit umgehen kann, wenn es auf 3.x oder 4.0 Firmware trifft.
Zitat von: kmxak am 21 Juni 2019, 09:28:21(auch wenn ich es nicht nutze und unabhängig vom fhem würde auf dem Controller auch tasmota/espeasy laufen incl. Lichtsteuerung die funktioniert?)
Jo, Tasmota läuft, da kannst Du gpio0, 2 und 16 auch konfigurieren und ihnen sowohl lokal als auch über die Hausautomation Funktionen zuordnen. Allerdings ist Tasmota wirklich erstaunlich schlecht, wenn es um Fades geht. Ich glaube, die machen nur sehr grobe PWM control.
pj
Zitat von: pjakobs am 21 Juni 2019, 09:19:06
cool, danke für die schnelle Implementation!
Ich geh davon aus, dass für 4.0/4.1 fhem-Modul und Firmware kreuzweise kompatibel sind, solange die neuen Features nicht genutzt werden?
Und auf die Gefahr hin, dass ich nerve: lass uns nochmal darüber reden, wie wir die zusätzlichen GPIOs verwenden ;-)
pj
Ich würde es nach wie vor herausragend finden, wenn man die freien GPIOs als Ausgang nutzen könnte, um bspw. eine weitere Lampe unabhängig von den Led-Stripes zu schalten.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 21 Juni 2019, 09:39:09
Ich würde es nach wie vor herausragend finden, wenn man die freien GPIOs als Ausgang nutzen könnte, um bspw. eine weitere Lampe unabhängig von den Led-Stripes zu schalten.
Verstehe ich, ist aber nicht im Scope für dieses Projekt. Tasmota erlaubt Dir das heute schon.
Die GPIOs sind ja nicht frei, ich will sie lediglich sehr limitiert als Tasteingänge zur Verfügung stellen. Wenn dahinter irgendwas hängt, was sie mit weniger als 10k gegen GND belastet, dann hab ich jede Menge Support mit Controllern, die nicht mehr funktionieren. Taster dran, fertig. Das ist alles, wofür es gedacht ist.
pj
Könnten sich evtl. mal diejenigen, die gerne einen Taster am Controller verwenden würden, kurz hier melden und kurz beschreiben, was sie damit vorhaben bzw. was sie sich darunter vorstellen? Einfach um die Anforderungen besser abschätzen zu können.
Zitat von: vbs am 21 Juni 2019, 13:59:06
Könnten sich evtl. mal diejenigen, die gerne einen Taster am Controller verwenden würden, kurz hier melden und kurz beschreiben, was sie damit vorhaben bzw. was sie sich darunter vorstellen? Einfach um die Anforderungen besser abschätzen zu können.
wie schonmal gesagt: ich würde damit einfach nur ein Notify starten wollen.
pj
Ich habe auch Controller an Orten ohne Smart Home. Keller z.b. die muss ich immer per App am handy an schalten wenn ich dort bin . Ein taster/Schalter geht da deutlich schneller. Oder abends am Bett will ich auch nicht mehr zum Handy greifen. Dort wäre ein Schalter am Nachttisch besser. Thats it.
Gesendet von meinem SM-G930F mit Tapatalk
gerade einen update all gemacht... nun spuckt das modul folgendes aus:
2019.06.21 18:12:40 1 : espledcontroller
2019.06.21 18:12:41 1 : PERL WARNING: Use of uninitialized value $r[0] in string eq at ./FHEM/98_update.pm line 315.
2019.06.21 18:12:41 1 : PERL WARNING: Use of uninitialized value $r[0] in string ne at ./FHEM/98_update.pm line 325.
einer eine idee?
Die Meldung kommt ja aus dem Update-Modul. Ein klein bisschen mehr Infos wären super. Wann kommt das denn? Einmalig? Regelmäßig? Kannst du das reproduzieren? Hat er denn erfolgreich geupdatet? Sagt mir so erstmal nichts. Stehe mit dem Update-Mechanismus von FHEM aber auch etwas auf Kriegsfuß :o
EDIT:
Hab bei mir nochmal getestet und da ist es offenbar nicht aufgetreten und reproduzieren konnte ich es auch nicht.
beim update all...
habe auch schon das modul probiert zu löschen und neu laden zu lassen auch per wget direkt aus deinem github habe ich es in das FHEM Verzeichnis gezogen... aber nix geht mehr.
wenn ich ein define ... mache kommt auch immer Unknown module EspLedController
ich kenne mich leider null mit fhem aus und nutze es nur für homeconnect und die ledcontroller.
wenn ich reload 32_EspLedController.pm mache kommt. Excessively long <> operator at ./FHEM/32_EspLedController.pm line 21.
mehr habe ich noch nicht.
Edit:
FHEM purge + ordner gelöscht neu installiert und config wieder rein kopiert nun rennt es wieder.... crazy
Hab mal ein Bugfix-Release 4.1.1-rc1 gemacht:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#change-history
Mann mann... irgendwie sind Sming-Updates auch ne Beschäftigungstherapie...
Ich hab den Controller im Schlafzimmer und würde auch gerne die Beleuchtung über einen Taster ein und Ausschalten. Mir reichts wenn über den Taster einfach geschalten werden kann, die Farbe oder Helligkeit will ich damit nicht ändern.
Tobi
Hi Ihr, hab mal die Buttons eingebaut. Durch Betätigung kann man damit ein-/aus schalten.
Beschreibung gibt's hier:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#hardware-push-buttons--420
Falls wer testen mag, wär es super.
Zitat von: pjakobs am 21 Juni 2019, 09:44:20
Verstehe ich, ist aber nicht im Scope für dieses Projekt. Tasmota erlaubt Dir das heute schon.
Tasmota kommt für mich in diesem Fall nicht in Frage, da gerade die farbübernge und Queue dort nicht so gut sein soll. Das war der Hauptgrund für mich auf dieses Projekt statt auf einen kommerziellen Kontrolleur zu setzen.
ZitatDie GPIOs sind ja nicht frei, ich will sie lediglich sehr limitiert als Tasteingänge zur Verfügung stellen. Wenn dahinter irgendwas hängt, was sie mit weniger als 10k gegen GND belastet, dann hab ich jede Menge Support mit Controllern, die nicht mehr funktionieren. Taster dran, fertig. Das ist alles, wofür es gedacht ist.
pj
Sorry aber das verstehe ich nicht. Was meinst du mit "nicht frei"? An den GPIOs kann doch nichts hängen, sondern würde das auch mit den Tastern nicht funktionieren oder übersehe ich da was?
Das mit der Belastung leuchtet mir zwar halbwegs ein aber wer an seinen Controller was dran hängt, wofür dieser nicht gemacht ist, der ist auch selber Schuld! Wir reden ja in dem Fall nicht von einer Plug-&-Play-Lösung die DAU-kompatibel sein muss. Wer ein Projekt mit einem Eigenbau-Kontroller umsetzt und dann noch weiter an die GPIOs auf der Pinleiste geht, dem würde ich zutrauen, dass er dort nicht mal soeben ohne zu überlegen eine 100W-Glühnbirne dranhängt.
Gesendet von iPhone mit Tapatalk
Kann es sein, dass das OTA Update nicht funktioniert? Irgendwie läuft das bei mir ins leere. Nach dem Update ist vor dem Update
Ist schon korrekt, du bist ja auf dem Kanal "release". Die vbs35 ist die neuste stable FW. Den "testing"-Kanal findest du unter URL: http://rgbww.dronezone.de/testing/version.json
Btw, kmxak ist aufgefallen, dass auf github nicht der neueste Quellcode verfügbar war (bzw. lange kein neuer Quellcode hochgeladen wurde). Sorry, war mein Verschulden und nicht so beabsichtigt. Ist nun korrigiert. Danke für den Hinweis.
Da hab ich glatt im Nachhinein etwas Schweißperlen auf der Stirn, wenn ich bedenke, dass der Quellcode die ganze Zeit nur auf meiner VM rum lag. Reiner Zufall, dass ich die nicht zum Beispiel zwischendurch mal neu aufgesetzt habe oder sowas :o
hi,
2019.06.30 13:20:19 1 : espledcontroller
2019.06.30 13:20:19 1 : UPD FHEM/32_EspLedController.pm
2019.06.30 13:20:19 1 : Got 57556 bytes for FHEM/32_EspLedController.pm, expected 59242
2019.06.30 13:20:19 1 : aborting.
2019.06.30 13:20:30 1 : *** EN FHEM/32_EspLedController.pm: =end html: missing
liegt das an mir oder ist da was anderes schief gelaufen? :o
Zitat von: kmxak am 30 Juni 2019, 13:21:34
hi,
2019.06.30 13:20:19 1 : espledcontroller
2019.06.30 13:20:19 1 : UPD FHEM/32_EspLedController.pm
2019.06.30 13:20:19 1 : Got 57556 bytes for FHEM/32_EspLedController.pm, expected 59242
2019.06.30 13:20:19 1 : aborting.
2019.06.30 13:20:30 1 : *** EN FHEM/32_EspLedController.pm: =end html: missing
liegt das an mir oder ist da was anderes schief gelaufen? :o
das sieht so aus, als ob der Dokumentationsteil des Moduls abgeschnitten sei.
pj
Zitat von: kmxak am 30 Juni 2019, 13:21:34
liegt das an mir oder ist da was anderes schief gelaufen? :o
Ja, mein Fehler... Bin wieder mal über die controls.txt gestolpert. Ist mir nicht klar, warum man eine handgeklöppelte txt-Datei braucht in der man byte-genau die Größen aller Files eintragen muss... Wenn dann noch git eine automatische NewLine-Konvertierung vornimmt und man dann auch noch aufpassen muss, dass man das entsprechend berücksichtigt, wenn man die Größe einträgt, dann kommt richtig Freude auf... ::)
muss heute nochmal schreiben... wo zum teufel finde ich general/buttons_config? ??? bin ich blind? Firmware und Modul habe ich aktuell gerade aktualisiert auf testing.
Habs! Muss die Hitze sein 8)
Aber dann doch noch eine Frage. Beziehen sich die "Pins" auf die Pinbelegung oder auf die GPIO? -- GPIO sind es!
Habe die Buttons nun kurz getestet und es scheint erstmal zu funktionieren.
Mal eine Noobie Frage zur Sicherheit:
Nach meinem Verständnis hat der ESP interne Pull-Ups an den GPIO-Pins (die ich in der Firmware auch aktiviert habe). Daher meine ich, dass man an dem GPIO für den Taster-Betrieb keinen einen 10k-Widerstand zusätzlich hängen muss. Ist das so korrekt oder braucht man den externen Pull-Up trotzdem?
EDIT:
Beim Entwickeln hatte ich keinen externen Widerstand dran und immer nur den Pin per Jumper-Kabel auf GND gezogen und es hatte funktioniert.
Zitat von: vbs am 04 Juli 2019, 10:54:00
Mal eine Noobie Frage zur Sicherheit:
Nach meinem Verständnis hat der ESP interne Pull-Ups an den GPIO-Pins (die ich in der Firmware auch aktiviert habe). Daher meine ich, dass man an dem GPIO für den Taster-Betrieb keinen einen 10k-Widerstand zusätzlich hängen muss. Ist das so korrekt oder braucht man den externen Pull-Up trotzdem?
EDIT:
Beim Entwickeln hatte ich keinen externen Widerstand dran und immer nur den Pin per Jumper-Kabel auf GND gezogen und es hatte funktioniert.
Mit dem ESP habe ich jetzt keine Erfahrung, aber ich würde das ähnlich zu den GPIOs vom Raspi sehen: Die haben auch einen internen, den man softwareseitig aktivieren kann - aber das kann mal auch gerne mal vergessen. IMHO macht man mit einem externen nix falsch und geht damit eher auf Nummer sicher.
bei meinen Test's musste ich mehrfach feststellen das er beim Ein Schalten manchmal die Led's zwar an gemacht hat aber nicht auf die letzte Stärke sondern nur glimmend.
Das Aus ging soweit gut.
Mit einem etwas höherem debounce ging es dann besser.
Ich habe aber keinerlei weitere Details da müsste ich weiter schauen.
Vielleicht war da ja auch was mit dem ESP chip falsch da ich ja auch den externen Widerstand benötigte. Das will ich auch nicht ausschließen.
Müsste ich die Tage nochmal genau anschauen.
Ja, das wird sehr wahrscheinlich am Debouncing liegen. Versuch mal einen höheren Wert. Evtl. sollte ich den Default erhöhen.
moin @vbs und @shojo
Wir haben ja in der Sammelbestellung einige Fälle, in der statt der Webapp nur eine leere Seite gezeigt wird. Wenn ich mir das mit dem Chrome Debugger ansehe, dann sind es immer app.min.css und app.min.js, die, meist mit einem "content length mismatch" nicht geladen werden können. Ich denke, das geht auf eine nicht ideale WLAN Verbindung zurück, die Frage ist aber: lässt sich da auf Software-Ebene was machen? Ich weiß, der Code steckt erst in der app.min.js, aber vielleicht lässt sich das Nachladen da irgendwie rauslösen? Habt Ihr ne Idee?
Der Fehler tritt wirklich häufig auf und es wäre zumindest super, da ne Message zu bekommen, idealerweise natürlich ein Weg, das Problem zu lösen. (kleinere Chunks? Retry? sowas)
pj
Hi,
Vielleicht erst eine statische Seite ,,Check WLAN Güte..." dann ein reload der js?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
@vbs: ich kann jetzt zwar mit einem Button die LED an und ausschalten, aber verstanden hab ich das noch nicht.
a) kann ich festlegen, was die einzelnen Buttons tun? (sinnvoll wäre an/aus, dim up, dim down)?
b) erzeugen die Buttons Events, die ich im fhem abfangen kann? MQTT?
pj
Zitat von: vbs am 04 Juli 2019, 10:54:00
Mal eine Noobie Frage zur Sicherheit:
Nach meinem Verständnis hat der ESP interne Pull-Ups an den GPIO-Pins (die ich in der Firmware auch aktiviert habe). Daher meine ich, dass man an dem GPIO für den Taster-Betrieb keinen einen 10k-Widerstand zusätzlich hängen muss. Ist das so korrekt oder braucht man den externen Pull-Up trotzdem?
EDIT:
Beim Entwickeln hatte ich keinen externen Widerstand dran und immer nur den Pin per Jumper-Kabel auf GND gezogen und es hatte funktioniert.
In den Controllern aus meinem / Patricks Design liegen GPIO0 und GPIO16 ja jeweils auf den Tastern für PRG und CLR und sind über 10k HIGH gezogen. Der GPIO2 ist auch über 10k auf HIGH, allerdings gibt es hier halt keinen Taster.
Laut Espressif Forum (https://bbs.espressif.com/viewtopic.php?t=1079) liegt der Wert der internen Pullups zwischen 30 und 100kOhm, was also zusammen mit den externen 10k Widerständen mindestens 7,5kOhm oder einen Strom von 440µA pro Pin ergibt.
Damit der Controller funktioniert darf keiner der GPIOs beim Start auf GND gezogen sein! (es sei denn, der ESP soll neu geflasht werden, dann gilt natürich PRG->GND)
die RGBWWCW Ausgänge haben übrigens 10k Pulldowns, da wäre es kontraproduktiv, die internen Pullups einzuschalten.
Ich kann auf die Schnelle nicht herausfinden, welche Treiber-Topologie Espressif gewählt hat, aber da sie sowohl für sink als auch für source einen maximalen Strom von 12mA angeben und der Ausgang auf High Impedance gesetzt werden kann, gehe ich von einem push/pull (Totem Pole) Output aus, so dass man sich im Betrieb die pullup/pulldown Widerstände sogar komplett sparen könnte.
pj
Zitat von: pjakobs am 08 Juli 2019, 11:04:55
Wir haben ja in der Sammelbestellung einige Fälle, in der statt der Webapp nur eine leere Seite gezeigt wird. Wenn ich mir das mit dem Chrome Debugger ansehe, dann sind es immer app.min.css und app.min.js, die, meist mit einem "content length mismatch" nicht geladen werden können.
Wo siehst du den Fehler bzw. wer meldet den? Geht es um einen bestimmten Browser? Bin noch nicht so sicher, ob dass wirklich an der WLAN-Verbindung liegt. Da würde ich eigentlich ein anderes Fehlerbild erwarten. Kannst du einen tcpdump bereit stellen?
gerade arbeite ich dran! :-)
[ohhh, Wireshark 3!]
so wie ich das sehe, geht da mindestens ein Paket verloren (59516) aber das wird dennoch ACK'd, der Server wiederholt das Paket und schickt danach ein [FIN]
Vielleicht hat der sming webserver / die http Implementation ein Problem mit Retransmits?
pj
[edit] noch ein zweites pcap File angehängt
Danke, das ist gut. Muss ich mir mal in Ruhe ansehen wenn Zeit ist.
Zitat von: pjakobs am 09 Juli 2019, 12:14:56
Vielleicht hat der sming webserver / die http Implementation ein Problem mit Retransmits?
Hm, HTTP arbeitet eigentlich da drüber. Betrifft wenn dann den TCP/IP Stack im Sming. Soweit ich weiß, wird LWIP eingesetzt (https://savannah.nongnu.org/projects/lwip/). Ist eigentlich recht verbreitet, darum würde es mich eher wundern, wenn es da einen so gravierenden Bug gäbe im Retransmission-Handling. Aber natürlich trotzdem möglich.
Um welche Software-Version geht es eigentlich?
Zitat von: pjakobs am 08 Juli 2019, 13:45:55
@vbs: ich kann jetzt zwar mit einem Button die LED an und ausschalten, aber verstanden hab ich das noch nicht.
a) kann ich festlegen, was die einzelnen Buttons tun? (sinnvoll wäre an/aus, dim up, dim down)?
b) erzeugen die Buttons Events, die ich im fhem abfangen kann? MQTT?
Genau, leider geht nur toggle.
Zitat von: vbs am 09 Juli 2019, 12:57:31
Danke, das ist gut. Muss ich mir mal in Ruhe ansehen wenn Zeit ist.
Hm, HTTP arbeitet eigentlich da drüber. Betrifft wenn dann den TCP/IP Stack im Sming. Soweit ich weiß, wird LWIP eingesetzt (https://savannah.nongnu.org/projects/lwip/). Ist eigentlich recht verbreitet, darum würde es mich eher wundern, wenn es da einen so gravierenden Bug gäbe im Retransmission-Handling. Aber natürlich trotzdem möglich.
Um welche Software-Version geht es eigentlich?
könnte ich mir aber gut vorstellen.
Vor vielen Jahren hatten wir unter NetWare (ich hab lang für Novell gearbeitet) mal einen Bug im tcp retransmit code, dessen Ursache darin lag, dass die Entwickler Speicher sparen wollten. Will sagen: gut möglich, dass der tcp Code nur eine kleine Anzahl Segmente puffert und dann verwirft und beim zweiten Retransmit einfach die Daten nicht mehr hat und deshalb einen RST schickt?
Die Ebene weiß ja nichts mehr von der Datei, aus der die Daten neu gelesen werden könnten.
pj
[update] das hier sieht sehr ähnlich aus (retransmit und double ACK) http://lwip.100.n7.nabble.com/TCP-spurious-Retransmission-and-Dup-Ack-issue-td28322.html
Zitat von: pjakobs am 09 Juli 2019, 13:51:40
Vor vielen Jahren hatten wir unter NetWare (ich hab lang für Novell gearbeitet) mal einen Bug im tcp retransmit code, dessen Ursache darin lag, dass die Entwickler Speicher sparen wollten. Will sagen: gut möglich, dass der tcp Code nur eine kleine Anzahl Segmente puffert und dann verwirft und beim zweiten Retransmit einfach die Daten nicht mehr hat und deshalb einen RST schickt?
Die Ebene weiß ja nichts mehr von der Datei, aus der die Daten neu gelesen werden könnten.
Also naiv hätte ich gedacht, dass man einfach die gesendeten Pakete aus dem TCP out Buffer so lange vorhalten MUSS bis sie entsprechend mit ACK bestätigt worden sind. Wenn man sie schon vorher verwirft, hat man natürlich keine Chance auf ein Retransmit. Würde ich dann aber kaum noch Bug nennen wollen, sondern eher einen TCP-Stack ohne Retransmit Support? Aber was weiß ich schon, hab ich noch nie implementiert sowas.
Kannst du noch sagen, um welche Version es gerade geht?
Zitat von: vbs am 09 Juli 2019, 16:04:06
Also naiv hätte ich gedacht, dass man einfach die gesendeten Pakete aus dem TCP out Buffer so lange vorhalten MUSS bis sie entsprechend mit ACK bestätigt worden sind. Wenn man sie schon vorher verwirft, hat man natürlich keine Chance auf ein Retransmit. Würde ich dann aber kaum noch Bug nennen wollen, sondern eher einen TCP-Stack ohne Retransmit Support? Aber was weiß ich schon, hab ich noch nie implementiert sowas.
Kannst du noch sagen, um welche Version es gerade geht?
Das tritt bei allen Versionen auf, von Anbeginn der Zeit bis (hier) 4.2
pj
Gesendet von meinem HTC U11 mit Tapatalk
Ist es richtig, dass das immer nur genau bei der initialen Inbetriebnahme auftritt jedoch nie danach noch im regulären Betrieb?
Zitat von: vbs am 09 Juli 2019, 16:15:56
Ist es richtig, dass das immer nur genau bei der initialen Inbetriebnahme auftritt jedoch nie danach noch im regulären Betrieb?
Nein, das habe ich bei verschiedenen Controllern immer wieder erlebt. Es hängt wohl eher damit zusammen, dass die beiden Dateien (Script und CSS) so groß sind, dass eine relativ hohe statistische Wahrscheinlichkeit besteht, dass etwas verloren geht.
pj
Was mich am meisten wundert, ist das FIN-Flag seitens des Controllers direkt nach der Retransmission.
Zitat von: vbs am 09 Juli 2019, 16:30:18
Was mich am meisten wundert, ist das FIN-Flag seitens des Controllers direkt nach der Retransmission.
ich schätze mal, auf der Applikationsebene sehen wir die Fehler der LwIP Schicht nicht?
LwIP scheint, was Memory Handling angeht, ziemlich mächtig zu sein, vielleicht lässt sich da was tunen? Ich weiß nicht, wie viele Buffer da angelegt sind.
pj
Stimme dir schon zu, dass ich das Problem auch irgendwo in der Ecke vermuten würde. Allerdings k.A. was genau.
Entweder muss man sich da in das lwip soweit selbst einarbeiten, dass man das analysieren kann oder eben das Problem so als Testfall reproduzierbar machen, dass man das entweder an Sming oder anlwip adressieren kann.
Zitat von: vbs am 09 Juli 2019, 18:12:04
Stimme dir schon zu, dass ich das Problem auch irgendwo in der Ecke vermuten würde. Allerdings k.A. was genau.
Entweder muss man sich da in das lwip soweit selbst einarbeiten, dass man das analysieren kann oder eben das Problem so als Testfall reproduzierbar machen, dass man das entweder an Sming oder anlwip adressieren kann.
Wie aufwendig wäre es denn, eine minimale Testapp zu schreiben, von der man einfach nur einen großen Blob immer wieder herunterladen kann?
Oder anders: ich versuche mal, den Script Blob x mal per wget zu ziehen, vielleicht lässt sich ja etwas reproduzieren.
pj
Gesendet von meinem HTC U11 mit Tapatalk
ich hab mir den Trace nochmal angesehen und es ist immer der gleiche Ablauf:
Irgendwann (nach nicht reproduzierbarer Zeit) fehlt offensichtlich auf der Client Seite ein Paket, der Client hat das zuvor versandte Paket ge ACK'd
28 0.701941384 192.168.29.80 192.168.29.88 TCP 54 55510 > http [ACK] Seq=139 Ack=16681 Win=63940 Len=0
und schickt jetzt, wo er ein out-of-sequence Paket bekommen hat das gleiche ACK nochmal, diesmal allerdings mit einem Window update
30 1.027907165 192.168.29.80 192.168.29.88 TCP 54 [TCP Window Update] 55510 > http [ACK] Seq=139 Ack=16681 Win=65330 Len=0
Der Server schickt sein Retransmit
31 1.745984284 192.168.29.88 192.168.29.80 TCP 1444 [TCP Retransmission] [TCP segment of a reassembled PDU]
der Client ACK'd dann das zuvor gesendete Paket, die Retransmission wird nie geACK'd denn der Server schließt die Verbindung
32 1.746221581 192.168.29.80 192.168.29.88 TCP 54 55510 > http [ACK] Seq=139 Ack=19461 Win=65330 Len=0
33 2.299577586 192.168.29.88 192.168.29.80 TCP 60 http > 55510 [FIN, ACK] Seq=19461 Ack=139 Win=5422 Len=0
für mich sieht das wie ein Bug / ein merkwürdiges Verhalten im TCP Stack aus.
[edit] im Anhang noch ein capture file, diesmal auch mit einigen Übertragungen, bei denen es zwar zu Retransmissions, aber nicht zum Abbruch kam (streams 6, 8 und 9)
pj
Hab die OTA-URLs umgestellt, so dass die Updates ab sofort nur noch über HTTPS ausgeliefert werden.
Zitat von: vbs am 13 Juli 2019, 21:41:06
Hab die OTA-URLs umgestellt, so dass die Updates ab sofort nur noch über HTTPS ausgeliefert werden.
ich hab's nicht getestet und mach's mir mal einfach: hast Du eine Umleitung auf der non-ssl url oder müssen die Nutzer die ota url manuell ändern?
pj
Ja, die war drin, aber ist jetzt wieder raus, also jetzt geht momentan beides parallel. Ich war etwas voreilig: der Update-Prozess ist ja zweistufig. Der Browser/FHEM lädt die version.json (gerne per HTTPS) und gibt die enthaltenen URLs an den Controller weiter. Das Problem ist, dass der kein SSL kann momentan. Also dürfen diese URLs momentan kein HTTPS sein. Vorraussetzungen dafür ist u.a. ein eingerichteter NTP-Server, damit er eine Chance auf die Zertifikatsprüfung hat...
Zitat von: vbs am 14 Juli 2019, 11:19:22
Ja, die war drin, aber ist jetzt wieder raus, also jetzt geht momentan beides parallel. Ich war etwas voreilig: der Update-Prozess ist ja zweistufig. Der Browser/FHEM lädt die version.json (gerne per HTTPS) und gibt die enthaltenen URLs an den Controller weiter. Das Problem ist, dass der kein SSL kann momentan. Also dürfen diese URLs momentan kein HTTPS sein. Vorraussetzungen dafür ist u.a. ein eingerichteter NTP-Server, damit er eine Chance auf die Zertifikatsprüfung hat...
hmm... hinter jedem Eichhörnchen versteckt sich ein Elefant.
pj
moin @vbs, ich hab hier einen seltsamen Effekt, den ich so noch nicht kannte.
Einer der reparierten Controller, ich konnte ihn, mit neuem ESP, problemlos mit der vbs35 Firmware flashen und darauf zugreifen.
Dann habe ich ein OTA auf den Testing Pfad (4.2.0 rc1) gemacht und danach bekomme ich im Browser einen "error bad content encoding" und auf der Seriellen Konsole des Controllers folgendes:
114713 fs.start: size:768 Kb, offset:0x300000
130621 mount res: 0
sleep disable
161826 SSID: IoT
162080 '*' registered
162293 '/' registered
162519 '/webapp' registered
162745 '/config' registered
162975 '/info' registered
164239 '/color' registered
166587 '/animation' registered
169262 '/networks' registered
171866 '/scan_networks' registered
174911 '/system' registered
177342 '/update' registered
179804 '/connect' registered
182264 '/generate_204' registered
185241 '/ping' registered
187504 '/stop' registered
189762 '/skip' registered
192014 '/pause' registered
194359 '/continue' registered
196965 '/blink' registered
199313 '/toggle' registered
mode : sta(cc:50:e3:2b:26:2c)
add if0
215651 mode: 0 -> 3
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with IoT, channel 11
dhcp client start...
455605 connect to ssid IoT, channel 11
ip:192.168.29.110,mask:255.255.255.0,gw:192.168.29.1
1177861 ip:192.168.29.110,mask:255.255.255.0,gw:192.168.29.1
1178173
6771497 read errno -10017
6772829 read errno -10017
pm open,type:0 0
Der Trace ist schon nach komplettem, und erfolgreichem, zurückflashen auf vbs35
Ich werd mal das Flash komplett löschen und dann neu flashen, aber vielleicht kannst Du mit der Fehlermeldung was anfangen?
Grüße
pj
[edit] nach erase_flash und neu flashen, wie erwartet kein Problem. Danach wieder Update über OTA und selber Fehler.
Hm, nee sagt mir nicht viel. Errno 10017 bedeutet "Cannot roll back specified object."... Was auch immer da gemeint ist.
Ich hab nochmal etwas gelesen bzgl. TCP Retransmission und ich hab eine Theorie:
89 2.305896567 192.168.29.88 192.168.29.80 TCP 1444 80 → 44978 [ACK] Seq=63941 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
90 2.345534159 192.168.29.80 192.168.29.88 TCP 54 44978 → 80 [ACK] Seq=139 Ack=65331 Win=65330 Len=0
91 2.403617188 192.168.29.88 192.168.29.80 TCP 1444 [TCP Previous segment not captured] 80 → 44978 [ACK] Seq=66721 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
Also hier ist ja offenbar ein Paket verloren gegangen und der Empfänger mahnt das Paket mit dem folgenden ACK an (TCP Dup)
92 2.403643063 192.168.29.80 192.168.29.88 TCP 54 [TCP Dup ACK 90#1] 44978 → 80 [ACK] Seq=139 Ack=65331 Win=65330 Len=0
Der Sender schickt das Paket dementsprechend nun nochmal - alles gut soweit
93 3.678099064 192.168.29.88 192.168.29.80 TCP 1444 [TCP Retransmission] 80 → 44978 [ACK] Seq=65331 Ack=139 Win=5422 Len=1390
94 3.678217286 192.168.29.80 192.168.29.88 TCP 54 44978 → 80 [ACK] Seq=139 Ack=68111 Win=65330 Len=0
Der Empfänger hat das Paket offenbar auch empfangen und bestätigt nun alle Bytes bis 68110 (also das gerade neu empfangene Paket und auch das darauf folgende, welches er ja auch schon empfangen hat).
95 3.992078748 192.168.29.88 192.168.29.80 TCP 1444 [TCP Spurious Retransmission] 80 → 44978 [FIN, ACK] Seq=66721 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
Jetzt ist das interessant, dass der Sender einfach die Verbindung schließt. Eine Vermutung wäre, dass der Sender das ACK (#94) nicht empfangen hat un daher davon ausgeht, dass auch das Retransmission-Paket verloren gegangen ist. Vielleicht hat er nach zwei Versuchen die Nase voll und gibt auf.
96 4.031683650 192.168.29.80 192.168.29.88 TCP 54 [TCP ACKed unseen segment] 44978 → 80 [ACK] Seq=139 Ack=68112 Win=65330 Len=0
Es gibt eine LWIP-Option "TCP_MAXRTX: Maximum number of retransmissions of data segments." (https://github.com/esp8266/Arduino/blob/master/tools/sdk/lwip/include/lwipopts.h#L922). Vielleicht steht die auf 1?
Bei anderen Retransmission, die nicht zum Abbruch führen, sieht das alles ja ähnlich aus, aber dann geht's brav weiter:
135 14.822232074 192.168.29.80 192.168.29.88 TCP 54 45102 → 80 [ACK] Seq=139 Ack=13901 Win=58380 Len=0
136 14.950282560 192.168.29.88 192.168.29.80 TCP 1444 [TCP Previous segment not captured] 80 → 45102 [ACK] Seq=15291 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
137 14.950396019 192.168.29.80 192.168.29.88 TCP 54 [TCP Window Update] 45102 → 80 [ACK] Seq=139 Ack=13901 Win=61160 Len=0
138 15.650729830 192.168.29.88 192.168.29.80 TCP 1444 [TCP Retransmission] 80 → 45102 [ACK] Seq=13901 Ack=139 Win=5422 Len=1390
139 15.650827703 192.168.29.80 192.168.29.88 TCP 54 45102 → 80 [ACK] Seq=139 Ack=16681 Win=63940 Len=0
140 15.715762673 192.168.29.88 192.168.29.80 TCP 1444 80 → 45102 [ACK] Seq=16681 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
141 15.715864714 192.168.29.80 192.168.29.88 TCP 54 45102 → 80 [ACK] Seq=139 Ack=18071 Win=65330 Len=0
142 15.733607172 192.168.29.88 192.168.29.80 TCP 1444 80 → 45102 [ACK] Seq=18071 Ack=139 Win=5422 Len=1390 [TCP segment of a reassembled PDU]
jetzt, wo Du's sagst, es ist natürlich auch denkbar, dass das ACK nach der Retransmission verloren geht. Ich capture ja nur auf der Client Seite.
allerdings würde ich *vermuten*, dass das "in flight" Retransmissions sind, also Segments die gleichzeitig zur neuen Übertragung anstehen.
Wenn es tatsächlich ein verlorenes ACK wäre, dann müssten wir ja ein relativ stabiles Timing zum FIN sehen, oder?
Ich hänge mal noch einen Satz Traces vom Freitag an (vielleicht hab ich das schon da mal angehäng?).
Interessant ist Stream 10, denn da passieren zwei Retransmits die problemlos funktionieren. Ich denke, Du bist auf dem richtigen Weg.
pj
Hast du schonmal versucht, das Problem mit wget zu reproduzieren? Z.b. einfach das CSS-File in einer endlosen Schleife runterladen? Ist die Frage, wie wget sich bei dem gleichen Fehler verhalten würde bzw. ob er das melden/loggen würde. Im Zweifel müsste man noch händisch die Länge des runtergeladenen Files prüfen.
'--ignore-length'
Unfortunately, some HTTP servers (CGI programs, to be more precise) send out bogus Content-Length headers, which makes Wget go wild, as it thinks not all the document was retrieved. You can spot this syndrome if Wget retries getting the same document again and again, each time claiming that the (otherwise normal) connection has closed on the very same byte.
With this option, Wget will ignore the Content-Length header—as if it never existed.
Klingt so als würde es wget einfach nochmal probieren bis die Länge stimmt, so dass man den Fehler nciht mitbekommen würde. Also --ignore-length und dann selbst prüfen? :-\
Zitat von: vbs am 15 Juli 2019, 14:31:21
Hast du schonmal versucht, das Problem mit wget zu reproduzieren? Z.b. einfach das CSS-File in einer endlosen Schleife runterladen? Ist die Frage, wie wget sich bei dem gleichen Fehler verhalten würde bzw. ob er das melden/loggen würde. Im Zweifel müsste man noch händisch die Länge des runtergeladenen Files prüfen.
'--ignore-length'
Unfortunately, some HTTP servers (CGI programs, to be more precise) send out bogus Content-Length headers, which makes Wget go wild, as it thinks not all the document was retrieved. You can spot this syndrome if Wget retries getting the same document again and again, each time claiming that the (otherwise normal) connection has closed on the very same byte.
With this option, Wget will ignore the Content-Length header—as if it never existed.
Klingt so als würde es wget einfach nochmal probieren bis die Länge stimmt, so dass man den Fehler nciht mitbekommen würde. Also --ignore-length und dann selbst prüfen? :-\
ich hab's auch mit wget, allerdings ohne das --ignore-length flag. Nur: der Fehler geschieht ja auf TCP Level, nicht HTTP, also dürfte der an dieser Stelle nichts ausmachen, oder?
pj
Doch doch, ist mMn relevant: Die TCP-Verbindung wird ja regulär geschlossen (FIN) und dadurch wird auch der HTTP-Request (erfolgreich) beendet. Dem Client fällt dann nur auf (wie deinem Browser ja auch), dass die Anzahl der übertragenen Bytes nicht zu der erwarteten Anzahl der Bytes aus dem HTTP-Header passt (Content-Length).
Ich finde es halt noch nach wie vor seltsam, dass das Problem zu keinem fehlgeschlagenen HTTP-Request führt, sondern offenbar wie ein normaler, erfolgreicher Request aussieht bei dem nur reale Datenlänge und "Content-Length"-Header nicht zusammen passen... Bug oder Feature? ???
Und von wget hätte ich eine Logmeldung erwartet, wenn Datenlänge und Header nicht zusammen passen:
Zitat"...claiming that the (otherwise normal) connection has closed on the very same byte..."
hier mal drei captures - eines ohne "--ignore-length" - da versucht wget immer wieder die Datei zu übertragen
wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 15:18:16-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7« gespeichert.
app.min.css?rel=0.3.3-shojo7 74%[============================================> ] 28,29K 13,8KB/s in 2,1s
2019-07-15 15:18:19 (13,8 KB/s) - Verbindung bei Byte 28972 geschlossen. Erneuter Versuch.
--2019-07-15 15:18:20-- (Versuch: 2) http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7« gespeichert.
app.min.css?rel=0.3.3-shojo7 77%[==============================================> ] 29,65K 7,94KB/s in 3,7s
2019-07-15 15:18:24 (7,94 KB/s) - Verbindung bei Byte 30362 geschlossen. Erneuter Versuch.
--2019-07-15 15:18:26-- (Versuch: 3) http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7« gespeichert.
app.min.css?rel=0.3.3-shojo7 31%[==================> ] 12,00K 3,08KB/s in 3,9s
2019-07-15 15:18:31 (3,08 KB/s) - Verbindung bei Byte 30362 geschlossen. Erneuter Versuch.
--2019-07-15 15:18:34-- (Versuch: 4) http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7« gespeichert.
app.min.css?rel=0.3.3-shojo7 100%[============================================================>] 38,19K 13,2KB/s in 2,9s
2019-07-15 15:18:38 (13,2 KB/s) - »app.min.css?rel=0.3.3-shojo7« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 15:18:57-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.1« gespeichert.
app.min.css?rel=0.3.3-shojo7.1 100%[============================================================>] 38,19K 15,7KB/s in 2,4s
2019-07-15 15:19:00 (15,7 KB/s) - »app.min.css?rel=0.3.3-shojo7.1« gespeichert [39107/39107]
danach ein erfolgloser Anlauf mit --ignore-length
wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7 --ignore-length
--2019-07-15 15:19:58-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: übergangen [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.2« gespeichert.
app.min.css?rel=0.3.3-shojo7.2 [ <=> ] 3,86K 3,32KB/s in 1,2s
2019-07-15 15:20:00 (3,32 KB/s) - »app.min.css?rel=0.3.3-shojo7.2« gespeichert [3952]
und zuletzt ein Anlauf, in dem es funktionierte:
wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7 --ignore-length
--2019-07-15 15:21:23-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: übergangen [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.3« gespeichert.
app.min.css?rel=0.3.3-shojo7.3 [ <=> ] 38,19K 9,96KB/s in 3,8s
2019-07-15 15:21:34 (9,96 KB/s) - »app.min.css?rel=0.3.3-shojo7.3« gespeichert [39107]
Ich hätte erwartet in "esprgbww-wget-content-header.pcapng" mindestens eine Retransmission und mindetens 2 HTTP-Requests zu finden. Sieht aber für mich nach einem einzelnen sauberen HTTP-Request aus?
Zitat von: vbs am 15 Juli 2019, 15:50:52
Ich hätte erwartet in "esprgbww-wget-content-header.pcapng" mindestens eine Retransmission und mindetens 2 HTTP-Requests zu finden. Sieht aber für mich nach einem einzelnen sauberen HTTP-Request aus?
Mist, ja, das ist offenbar eine falsche Datei. Argh!
Wie simuliere ich denn mal den schlechten WLAN-Empfang um das Problem mal selbst zu sehen? Hab gerade ohne Erfolg naiv mit Alufolie rumhantiert :(
Ich kann das Problem nicht nachstellen, aber ich hab mal eine Firmware gebaut mit verschiedene TCP-Debug-Ausgabe für LWIP. Vielleicht kannst du das mal laufen lassen:
http://rgbww.dronezone.de/unstable/version.json
Bau: https://travis-ci.org/verybadsoldier/esp_rgbww_firmware/builds/559090765
("unstable" ist ein neuer Kanal. Da landen alle Tags, die "-alpha" im Namen haben (andere mit "-..." gehen nach "testing" und alle ohne Kürzel nach "release").)
Es gibt noch viele andere Ausgabe-Optionen, aber das ist einfach mal ein erster Schuss... Ich werde das hier nachstellen müssen, um damit sinnvoll arbeiten zu können :/
das sieht sehr hilfreich aus
aktuell spielt allerdings der Controller bzw. das Netz mit. bzw nicht mit. also - es funktioniert alles :D
pj
ok drei test Runs, die ersten beiden jeweils mit mehreren wget runs (ohne --ignore-length). Beim -1 lief die Webapp noch im Browser, den Stream musst Du filtern.
In -2 sind mehrere (fünf oder sechs) Attempts drin, -3 ist nur ein einziger Lauf.
Interessante Beobachtung: es treten immer noch Retransmits auf, aber: die Verbindung wird nicht mehr abgebrochen.
Die Downloadzeiten für app.min.css liegen zwischen 2.6 und 27s, aber immer wird die Datei fehlerfrei geladen.
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:12:01-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.8« gespeichert.
app.min.css?rel=0.3.3-shojo7.8 100%[============================================================>] 38,19K 14,6KB/s in 2,6s
2019-07-15 22:12:03 (14,6 KB/s) - »app.min.css?rel=0.3.3-shojo7.8« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:12:06-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.9« gespeichert.
app.min.css?rel=0.3.3-shojo7.9 100%[============================================================>] 38,19K 8,90KB/s in 4,3s
2019-07-15 22:12:10 (8,90 KB/s) - »app.min.css?rel=0.3.3-shojo7.9« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:12:12-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.10« gespeichert.
app.min.css?rel=0.3.3-shojo7.10 100%[============================================================>] 38,19K 8,72KB/s in 4,4s
2019-07-15 22:12:18 (8,72 KB/s) - »app.min.css?rel=0.3.3-shojo7.10« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:15:12-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.11« gespeichert.
app.min.css?rel=0.3.3-shojo7.11 100%[============================================================>] 38,19K 3,26KB/s in 12s
2019-07-15 22:15:25 (3,26 KB/s) - »app.min.css?rel=0.3.3-shojo7.11« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:15:28-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.12« gespeichert.
app.min.css?rel=0.3.3-shojo7.12 100%[============================================================>] 38,19K 1,75KB/s in 27s
2019-07-15 22:15:56 (1,42 KB/s) - »app.min.css?rel=0.3.3-shojo7.12« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:17:44-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.13« gespeichert.
app.min.css?rel=0.3.3-shojo7.13 100%[============================================================>] 38,19K 1,55KB/s in 24s
2019-07-15 22:18:14 (1,62 KB/s) - »app.min.css?rel=0.3.3-shojo7.13« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:18:19-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.14« gespeichert.
app.min.css?rel=0.3.3-shojo7.14 100%[============================================================>] 38,19K 4,77KB/s in 8,0s
2019-07-15 22:18:28 (4,77 KB/s) - »app.min.css?rel=0.3.3-shojo7.14« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:18:32-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.15« gespeichert.
app.min.css?rel=0.3.3-shojo7.15 100%[============================================================>] 38,19K 3,32KB/s in 12s
2019-07-15 22:18:44 (3,32 KB/s) - »app.min.css?rel=0.3.3-shojo7.15« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:18:46-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.16« gespeichert.
app.min.css?rel=0.3.3-shojo7.16 100%[============================================================>] 38,19K 4,86KB/s in 7,9s
2019-07-15 22:18:55 (4,86 KB/s) - »app.min.css?rel=0.3.3-shojo7.16« gespeichert [39107/39107]
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.css?rel=0.3.3-shojo7
--2019-07-15 22:20:00-- http://192.168.29.99/app.min.css?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 39107 (38K) [text/css]
Wird in »app.min.css?rel=0.3.3-shojo7.17« gespeichert.
app.min.css?rel=0.3.3-shojo7.17 100%[============================================================>] 38,19K 4,04KB/s in 9,5s
2019-07-15 22:20:09 (4,04 KB/s) - »app.min.css?rel=0.3.3-shojo7.17« gespeichert [39107/39107]
Wenn das debug log wirklich die einzige Änderung ist, dann haben wir es wohl mit einem Timing Problem zu tun.
pj
ich hab noch einen run gemacht, diesmal mit der .js Datei und --ignore-legnth:
[pjakobs@linux ~]$ wget 192.168.29.99/app.min.js?rel=0.3.3-shojo7 --ignore-length
--2019-07-15 22:31:41-- http://192.168.29.99/app.min.js?rel=0.3.3-shojo7
Verbindungsaufbau zu 192.168.29.99:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: übergangen [text/javascript]
Wird in »app.min.js?rel=0.3.3-shojo7.3« gespeichert.
app.min.js?rel=0.3.3-shojo7.3 [ <=> ] 182,93K --.-KB/s in 30s
2019-07-15 22:32:11 (6,17 KB/s) - »app.min.js?rel=0.3.3-shojo7.3« gespeichert [187324]
debug-run-5
dauert ewig, aber bricht nicht mehr ab.
blöd ist nur, ich kann die ACK sequenzen zwischen Trace und Log nicht übereinander bringen - sind das im Log wirklich die ACK nummer?
pj
Hm, ich vermute, dass die ACK-Nummern in Wireshark um die ISN bereinigt sind. Wireshark nennt sich auch "relative ack number". Die LWIP-Logs zeigen vermutlich die Roh-ACK-Nummern. Ist aber mindestens halb geraten...
Ich hab nochmal eine Verison gepusht ohne Logausgaben:
https://travis-ci.org/verybadsoldier/esp_rgbww_firmware/builds/559127016
Erstmal rausfinden, ob wirklich das Logging das Verhalten verändert hat. Was ich nicht glaube/hoffe, weil ich dann echt schlechte Laune kriege :-X
Genau, hier steht's:
https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers
Ich find's überraschend, dass der Controller ~800 ms braucht, um auf die Retransmission zu reagieren und das fehlende Paket nachzusenden:
221 20.781577023 192.168.29.99 192.168.29.101 TCP 1444 [TCP Previous segment not captured] 80 → 46826 [ACK] Seq=151511 Ack=163 Win=5398 Len=1390 [TCP segment of a reassembled PDU]
222 20.781653453 192.168.29.101 192.168.29.99 TCP 54 [TCP Dup ACK 220#1] 46826 → 80 [ACK] Seq=163 Ack=150121 Win=65535 Len=0
223 21.613624850 192.168.29.99 192.168.29.101 TCP 1444 [TCP Retransmission] 80 → 46826 [ACK] Seq=150121 Ack=163 Win=5398 Len=1390
224 21.613729177 192.168.29.101 192.168.29.99 TCP 54 46826 → 80 [ACK] Seq=163 Ack=152901 Win=65535 Len=0
Das Verfahren nennt sich ja eigentl. "Fast Retransmission"... :o
EDIT:
Hier sogar 1,4 s: :o :o
189 18.532154501 192.168.29.99 192.168.29.101 TCP 1444 [TCP Previous segment not captured] 80 → 46826 [ACK] Seq=129271 Ack=163 Win=5398 Len=1390 [TCP segment of a reassembled PDU]
190 18.532216966 192.168.29.101 192.168.29.99 TCP 54 [TCP Dup ACK 188#1] 46826 → 80 [ACK] Seq=163 Ack=127881 Win=65535 Len=0
191 19.946226440 192.168.29.99 192.168.29.101 TCP 1444 [TCP Retransmission] 80 → 46826 [ACK] Seq=127881 Ack=163 Win=5398 Len=1390
wtf macht der Controller zwischendurch?
Zitat von: vbs am 15 Juli 2019, 23:03:27
wtf macht der Controller zwischendurch?
Pakete nach China schicke? scnr
aber egal was: ich kann mit der 'unstable' das Problem nicht reporduzieren. Es dauert manchmal lange, die Seite zu laden aber sie wird geladen. im anhängenden Trace sind wieder ein paar Retransmits, aber kein vorschnelles FIN.
Whatever you changed: keep that :o
pj
ich hab mal meine beiden WLAN Repeater neu gestartet und das Netz komplett miserabel gemacht, und selbst in der Situation liefert die "unstable" Firmware das File korrekt und vollständig aus - wenn auch in gemächlichen 88s.
[edit] so ganz nebenbei hab ich auch ne Ahnung, was an meinem IoT WLAN so grottig schlecht ist. Aber das Problem löse ich jetzt noch nicht sonst haben wir kein Testbed ;-)
Gefällt mir nicht :'(
Könntest du das zur Absicherung noch einmal getestet gegen die 4.2.0-rc1 bitte? Gerne auch beide nochmal identisch per seriell aufspielen oder so.
Die unstables sind halt nicht mehr von mir gebaut, sondern von Travis. Eigentlich der gleiche Quellcode. Ein Unterschied ist, dass ich bei Travis eine fertige Binary-Toolchain aus dem Nodemcu-Projekt benutze und ich mir hier die Toolchain irgendwann mal selbst kompiliert habe... sollte aber *eigentlich* keinen Unterschied machen... :-X
EDIT:
Was noch viel besser wäre: eine Idee, wie ich das Problem hier bei mir provozieren könnte? Metalldose um den Controller oder sowas?
gerade sehe ich dass beim *ganz extrem schlechten* wlan doch zwei Übertragungen vorab abgebrochen wurden.
Allerdings unter krass üblen Bedingungen. (ich glaube dass der Access Point ein Problem hat, möglicherweise auch seine Netzanbindung)
jetzt hab ich mir das Netz ganz zerschossen - also zumindest für die 29.99 :D
Aktuell ist er zwar mit irgendeinem AP des WLAN verbunden, aber der Client schickt wie blöd ARP Requests. Ich glaub, ich mach mal für heut Feierabend.
Wenn Du sagst, der Travis Build unterscheidet sich primär durch die ESP toolchain - da sind aber doch die libraries und rtos binaries auch mit compiliert - ob das einfach nur andere Versionen sind? Ich vermute ja, dass LwIP in SMING steckt und deshalb als Teil Deines Builds daher kommt?
Es ist schon wieder viel zu viel Software auf so nem Controller. Ich hab mal damit angefangen, weil ich die Tatsache mochte, dass es kein Betriebssystem gibt, das überall reinfummelt.
also: schluss für heut.
Danke erstmal
pj
Hm, aus deinem WorstCase werde ich nciht so ganz schlau... sieht ziemlich wild aus...
Die maximale Anzahl an Retransmissions liegt bei 12. Bin immer noch nicht ganz sicher, was denn im Normalfall passiert, wenn man die 12 erreicht. Wird wirklich die Verbindung ganz regulär per FIN beendet? Würde halt bedeuten (wie es bei uns ja auch ist), dass der Client gar nicht mitbekommt, dass die Verbindung aufgrund eines Fehler vorzeitig geschlossen wurde und er könnte denken, dass alle Daten wie gewünscht fertig übertragen worden sind. Bei HTTP rettet einen da eben der Content-Length-Header vor dieser Schlussfolgerung...
Nach wie vor wäre interessant, ob sich wirklich der Travis-Bau anders verhält als mein Bau. Wenn ja dann würde ich auch mal mit der Binary-Toolchain bauen bei mir (wie Travis) und dann gucken, ob es sich dann identisch verhält.
Wenn Du sagst, der Travis Build unterscheidet sich primär durch die ESP toolchain - da sind aber doch die libraries und rtos binaries auch mit compiliert - ob das einfach nur andere Versionen sind? Ich vermute ja, dass LwIP in SMING steckt und deshalb als Teil Deines Builds daher kommt?
Das ESP SDK besteht eigentlich aus Toolchain + SDK. Den SDK-Teil bringt Sming jedoch selbst auch mit und den benutzen wir auch (identisch bei mir und bei Travis). Nur die Toolchain unterscheidet sich zwischen meinen Builds und den Travis-Builds.
Zitat von: pjakobs am 15 Juli 2019, 23:28:16
Pakete nach China schicke? scnr
aber egal was: ich kann mit der 'unstable' das Problem nicht reporduzieren. Es dauert manchmal lange, die Seite zu laden aber sie wird geladen. im anhängenden Trace sind wieder ein paar Retransmits, aber kein vorschnelles FIN.
Whatever you changed: keep that :o
pj
Aber die Pakete kommen doch aus China!
Wenn man lange genug wartet.
Gruss Christoph
Ich krieg das einfach nicht reproduziert... ich hab mir ein Stück Alufolie an die Antenne des ESP gebaut und der Empfang ist jetzt richtig mies. Übertragung bricht auch mal ab, aber in den Fällen dann nachvollziehbar nach einer ganzen Reihe von Retransmits. Dass die Verbindung unerwartet nach einem einzelnen Retransmit abgebrochen wird, passiert einfach nicht.
Ich hab das Problem heute einmal gesehen: total zufällig auf einem anderen Controller, den ich gerade frisch gebootet hatte und dann das WebIf im Browser geöffnet habe. Ist das evtl. ein Problem, was gerne kurz nach einem Reboot auftritt? Macht der Controller evtl. gerade was anderes und kann das Netzwerk nicht bedienen für eine gewisse Zeit?
Ich teste auf der 4.2.0-rc1 und die läuft bzgl. Retransmits erstmal zuverlässig. Ich glaube nicht mehr, dass das einfach nur ein Problem des TCP-Handlings bei schlechtem Wifi-Empfang ist. Irgendwie muss da noch mehr hinter stecken...
Hab auch noch einiges an LWIP-Code gelesen und verstehe jetzt einigermaßen, wie das Ding funktioniert. Da könnte man jetzt sicherlich recht zielgerichtet per Debugausgaben rausfinden, warum der Controller die Verbindung schließt. Ich kann da nur leider nicht wirklich was machen, wenn ich das Problem hier nicht nachstellen kann.
Hast du noch Ideen/Hoffnung Peter oder sollen wir es erstmal dabei belassen?
Zitat von: vbs am 20 Juli 2019, 16:27:12
Hast du noch Ideen/Hoffnung Peter oder sollen wir es erstmal dabei belassen?
Hi, sorry, die Woche war ein bisschen hektisch.
Das Problem ist halt, dass ich nicht wirklich einen stabilen Reproducer habe. Nach dem ganzen Rumprobieren hab ich erstmal mein IoT WLAN komplett zerlegt und erneuert, das war ja grottenschlecht.
Was wir festhalten können ist:
- die Controller sind anfällig bei schlechter WLAN Qualität
- irgendwas im TCP retransmit Verhalten ist merkwürdig.
Ich muss mal schauen, ob es sowas wie einen definiert "lossy router" gibt, also irgend ein Stück Linux, das gezielt Fehler in einen TCP Strom einbauen kann.
pj
Kein Problem, eilt ja nicht.
Hab auch schon überlegt, wie man gezielt so eine TCP-Kommunikation faken kann, aber ich kenn da leider nix :(
Was wir festhalten können ist:
- die Controller sind anfällig bei schlechter WLAN Qualität
- irgendwas im TCP retransmit Verhalten ist merkwürdig.
Jein, ich seh das auch als sehr wahrscheinlich an, aber so richtig 100% ist das für mich noch nicht... also bei ganz schlechtem WLAN wiederum scheint es ja nicht aufzutreten und gefühlt tritt es bei einer Erstinbetriebnahme häufiger auf als im regulären Betrieb. Mag mich aber auch irren.
Aber es hängt momentan echt am Reproduzieren... Sming bringt übrigens 3 verschiedene LWIP-Stände mit, die man umschalten kann. Könnte man also auch einfach mal ausprobieren... wenn man es denn reproduzieren könnte ;D
Moin,
habe seit einigen Tagen ein Problem beim Update von FHEM.
Es bricht beim Update des Moduls ab.
2019.08.02 19:41:07 1 : nothing to do...
2019.08.02 19:41:07 1 :
2019.08.02 19:41:07 1 : espledcontroller
2019.08.02 19:41:07 1 : UPD FHEM/32_EspLedController.pm
2019.08.02 19:41:07 1 : Got 56965 bytes for FHEM/32_EspLedController.pm, expected 57556
2019.08.02 19:41:07 1 : aborting.
Vielleicht hat ja jemand einen Tip.
Vielen Dank (auch für dieses tolle Projekt)
Gruß
Andreas
Da hat wohl vbs vergessen die controls Datei nach der letztens Änderung anzupassen.
Die erwartete Dateigröße stimmt somit nicht mehr der tatsächlichen überein. Das wird er nach dem Hinweis sicherlich in Kürze tun.
Danke,
etwas derartiges habe ich auch vermutet.
Gruß
Andreas
Ja so ähnlich. Es geht offenbar um den develop-Kanal, oder? Den gab es ja einige Zeit nicht und ich hatte ihn erst neulich wieder angelegt, weil ich etwas testen wollte. Aber ihr könnte natürlich auch gerne mittesten ^^
Also hab es gefixt, danke für den Hinweis.
Danke, Update läuft jetzt wieder durch.
Wenn ich jetzt noch wüßte, ob ich nun den develop- oder den master-Kanal vor vielen Monaten per update add hinzugefüht habe.
Gruß
Andreas
Kannst du mit "update list" sehen. Aber wird develop sein ziemlich sicher.
Tja, ergibt bei mir eine leere Seite, dürfte aber eher ein Problem meines Systems sein. Was mir aber noch auffiel ist, dass der Befehl version bei Deinem Modul eine fehlende id bemängelte.
55_DWD_OpenData.pm 19336 2019-05-05 18:26:34Z jensb
99_DWD_OpenData_Weblink.pm 201500 2018-02-23 19:56:00Z jensb
64_ESA2000.pm 7243 2014-12-17 13:04:32Z stromer-12
34_ESPEasy.pm 18608 2019-02-16 09:03:52Z dev0
No Id found for 32_EspLedController.pm
72_FB_CALLMONITOR.pm 19517 2019-06-01 12:18:45Z markusbloch
93_FHEM2FHEM.pm 17361 2018-09-17 11:44:10Z rudolfkoenig
Habe eben noch einmal ein fw-update erfolgreich durchgeführt. Funktioniert soweit einwandfrei.
Gruß
Andreas
So, im dritten Anlauf hat jetzt update list funktioniert. Du hast Recht, hatte den develop-Kanal vor Jahren angegeben.
Vielen Dank für Deine Hilfe und Arbeit.
Bin gerne bereit, es so zu belassen und zu testen wenn es Dir hilft.
Gruß
Andreas
Klar, kannst du gerne machen, danke dir. Der Unterschied in develop ist das Attribut "disable".
Hallo VBS,
ich brauch mal deine Hilfe. Ich habe mir einen Haufen H801 gekauft, die haben aber nur 1MB Speicher. Die Firmware ist leider größer. Wenn ich selber compile, wäre es möglich nicht notwendige Teile wie z.B. MQTT zu deaktivieren in der Hoffnung dass es dann passt?
Gruß Florian
Ist zumindest einen Versuch wert. Aber deaktivieren kannst du das nicht einfach im Code. Du musst die entsprechenden Code-Stellen tatsächlich rausnehmen, so dass der Linker die nicht in die fertige Binary packt. Du kannst theoretisch auch ein Define in der Art ENABLE_MQTT usw. einbauen, so dass man das jederzeit später auch wieder so kompilieren kann. Wirst aber eh rausfinden müssen, wie viel Code du rausschmeißen musst, damit das passt.
Zitat von: vbs am 09 August 2019, 21:01:47
Ist zumindest einen Versuch wert. Aber deaktivieren kannst du das nicht einfach im Code. Du musst die entsprechenden Code-Stellen tatsächlich rausnehmen, so dass der Linker die nicht in die fertige Binary packt. Du kannst theoretisch auch ein Define in der Art ENABLE_MQTT usw. einbauen, so dass man das jederzeit später auch wieder so kompilieren kann. Wirst aber eh rausfinden müssen, wie viel Code du rausschmeißen musst, damit das passt.
Wie groß ist die Firmware aktuell eigl.?
Du könntest versuchen, das SPIFFS kleiner zu machen. Das liegt irgendwie bei 750 kB. Da liegt die Weboberfläche und dann später zur Laufzeit die Config drin. Könnte mir denken, dass man da auch mit 400 kB hinkommt.
Sieht momentan so aus:
Section| Description| Start (hex)| End (hex)|Used space
------------------------------------------------------------------------------
data| Initialized Data (RAM)| 3FFE8000| 3FFE8578| 1400
rodata| ReadOnly Data (RAM)| 3FFE8580| 3FFEA354| 7636
bss| Uninitialized Data (RAM)| 3FFEA358| 3FFF1698| 29504
text| Cached Code (IRAM)| 40100000| 401075F6| 30198
irom0_text| Uncached Code (SPI)| 40202010| 4026787F| 415855
Total Used RAM : 38540
Free RAM : 43380
Free IRam : 2588
E2 out/firmware/rom0.bin
Checking for spiffs files
webapp directory exists. Creating out/firmware/spiff_rom.bin
Creating rom 'out/firmware/spiff_rom.bin' of size 0xc0000 (786432) bytes.
Adding files in directory 'webapp'.
Added 'index.html.gz' to spiffs (6532 bytes).
Added 'app.min.js.gz' to spiffs (187324 bytes).
Added 'app.min.css.gz' to spiffs (39107 bytes).
Added 'VERSION' to spiffs (13 bytes).
Added 'init.html.gz' to spiffs (2660 bytes).
Hallo,
nochmal zu dem Problem dass nach einem
Zitatcontrol-general-buttons_config 2,9
in FHEM der Controller abstürzt und in einer Bootloop hängt..
Firmware ist die 4.2.0-rc1, ich habe bevor ich etwas geändert habe das erste Backup erstellt.
Wenn ich die Buttons (egal welche, habs auch schon mit einem oder drei probiert) mit FHEM in die Config des Controller schreibe und anschließend auf Get Config klicke, dann zeigt Fhem mir auch die gewünschten Buttons an (config-general-buttons_config 2,9). Hier habe ich jetzt das zweite mal die Settings exportiert (rgbwwsetting_Button).
Anschließend soll man den Controller ja neustarten, also einmal Spannung weg und nach kurzem warten wieder einschalten. Danach passiert dann wieder nichts mehr, die Blaue LED auf dem ESP blinkt nur noch ca alle 10s. Das selbe passiert auch auf dem zweiten Controller den ich hier habe.
Ein Brücken von GND mit G16 und anschließendes Reset drücken macht den Controller wieder erreichbar, allerdings sind dann alle Einstellungen gelöscht und es ist wieder die Firmware
vbs35 drauf (Settings File rgbwwsetting_NachReset).
Ich habe mir das hochladen der Settings gespart, da alle drei Dateien gleich waren. Falls es etwas bringt kann ich sie aber noch hochladen. Sie sehen alle so aus:
{
"network": {
"mqtt": {
"enabled": false,
"server": "mqtt.local",
"port": 1883,
"username": "",
"password": "",
"topic_base": "home/"
}
},
"color": {
"outputmode": 0,
"startup_color": "last",
"hsv": {
"model": 0,
"red": 0,
"yellow": 0,
"green": 0,
"cyan": 0,
"blue": 0,
"magenta": 0
},
"brightness": {
"red": 100,
"green": 100,
"blue": 100,
"ww": 100,
"cw": 100
},
"colortemp": {
"ww": 2700,
"cw": 6000
}
}
}Gruß Tobi
Ich kann mir da erstmal keinen Reim drauf machen und ich kann es hier auch nicht reproduzieren. Aber meiner Meinung nach, ist deine Beschreibung nicht schlüssig (oder dein Problem wirklich sehr exotisch): erstens ist deine gepostete Config sehr lückenhaft. Da sind ja überhaupt nur zwei Blöcke drin (MQTT und Color). Der komplette Rest fehlt. Wenn das wirklich so sein sollte, dann ist das sehr komisch und ich würde mich wundern, dass bei dir überhaupt irgendwas funktioniert. Andererseits sagst du, dass FHEM aber die Button-Config korrekt anzeigt ("config-general-buttons_config 2,9"). Das spricht auch dafür, dass die Config eigentlich doch nicht so ist, wie gepostet, weil dann könnte FHEM die Werte ja auch nicht kennen.
Ich habe mir das hochladen der Settings gespart, da alle drei Dateien gleich waren. Falls es etwas bringt kann ich sie aber noch hochladen. Sie sehen alle so aus:
Mir ist hier nicht klar von welchen drei Dateien/Settings du sprichst. Falls bei dir auch schon die Config von vbs35 so aussieht wie gepostet, dann passt da schon etwas nicht. Liest du die Config im Browser über die /config-URL aus oder wie machst du das? Das wäre auf jeden Fall der beste Weg.
EDIT:
Ich glaub, ich kann es doch reproduzieren... Zumindest das mit den Reboots nach dem Setzen (nicht das mit deinem Config-Inhalt).
Das liegt mMn einfach an Pin 9. Es funktioniert mit nur Pin 2, aber wenn Pin 9 umkonfiguriert wird, dann führt das zu einem Reboot. Auch alleine Pin 9 geht nicht. Kann dir nicht genau sagen warum. Evtl. kann Peter was dazu sagen: ist Pin 9 evtl. speziell beschaltet?
Hast du es schon mal mit irgendeiner anderen Pinkombination (oder vielleicht sogar erstmal nur einem Pin) versucht?
EDIT:
Mit nur Pin 16 funktionierts auch... offenbar gehen einfach nicht mehrere Pins?
EDIT2:
Mann mann mann... bin irgendwann gedanklich auf diesen Pin 16 abgebogen. Keine Ahnung warum. Also Pin 9 ist der Punkt.
Pin 9? Wieso Pin 9? Der ist als Eingang doch garnicht verfügbar? 0,2 und 16 sind verfügbar. 9 ... muss ich nachsehen, aber ... hmm... GPIO9 ist doch auf einem ESP12 einer der Pins für den FLASH Chip, da wundert's mich nicht, wenn das Teil re-bootet, der kann dann auf seinen Code nicht mehr zugreifen.
Die Pins entlang der kurzen Kante des ESP12 sind auf der Platine aus gutem Grund nicht verbunden, "no user servicable parts inside"
pj
Zitat von: pjakobs am 11 August 2019, 13:11:59
Pin 9? Wieso Pin 9? Der ist als Eingang doch garnicht verfügbar? 0,2 und 16 sind verfügbar. 9 ... muss ich nachsehen, aber ... hmm... GPIO9 ist doch auf einem ESP12 einer der Pins für den FLASH Chip, da wundert's mich nicht, wenn das Teil re-bootet, der kann dann auf seinen Code nicht mehr zugreifen.
Pin 9 weil das eben einer der beiden Pins ist, auf dem der "Bug" gemeldet wurde über den wir seit ein par Wochen reden. Hatte dich irgendwie so verstanden, dass unklar ist, warum das nicht funktioniert und dass wir jetzt deswegen hier die Firmware-Seite analysieren.
Zitat von: pjakobs am 11 August 2019, 13:11:59
Die Pins entlang der kurzen Kante des ESP12 sind auf der Platine aus gutem Grund nicht verbunden, "no user servicable parts inside"
Du meinst deine letzte Variante der Platine, oder? Sind ja auch andere Hardwaren in Benutzung bzw. User basteln sich was zu recht. Sprich: ich kann nicht davon ausgehen, dass nur diese Platine in Benutzung ist und nur die beiden von dir vorgesehenen Pins verwendet werden. Daher kann man beliebige Pins konfigurieren und der Benutzer muss eben wissen, was er tut.
Zitat von: vbs am 11 August 2019, 13:32:31
Pin 9 weil das eben einer der beiden Pins ist, auf dem der "Bug" gemeldet wurde über den wir seit ein par Wochen reden. Hatte dich irgendwie so verstanden, dass unklar ist, warum das nicht funktioniert und dass wir jetzt deswegen hier die Firmware-Seite analysieren.
Du meinst deine letzte Variante der Platine, oder? Sind ja auch andere Hardwaren in Benutzung bzw. User basteln sich was zu recht. Sprich: ich kann nicht davon ausgehen, dass nur diese Platine in Benutzung ist und nur die beiden von dir vorgesehenen Pins verwendet werden. Daher kann man beliebige Pins konfigurieren und der Benutzer muss eben wissen, was er tut.
OK, aber GPIO9 und GPIO10 plus MISO, MOSI, CMD und CLK sind nie verfügbar, wenn der ESP im QIO Mode konfiguriert ist.
Das ist eine Einschränkung der ESP12 Hardware, nicht des Boards außen rum.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Zitat von: pjakobs am 11 August 2019, 13:52:37
OK, aber GPIO9 und GPIO10 plus MISO, MOSI, CMD und CLK sind nie verfügbar, wenn der ESP im QIO Mode konfiguriert ist.
Das ist eine Einschränkung der ESP12 Hardware, nicht des Boards außen rum.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hier steht ein bisschen was dazu https://tech.scargill.net/esp8266-dio-mysteries-solved/
Gesendet von meinem HTC U11 mit Tapatalk
Zitat von: pjakobs am 11 August 2019, 13:52:37
OK, aber GPIO9 und GPIO10 plus MISO, MOSI, CMD und CLK sind nie verfügbar, wenn der ESP im QIO Mode konfiguriert ist.
Soweit ich weiß, ist das aber nicht immer der Fall und hängt von dem verbauten Flash ab. Ich lasse mich aber gern korrigieren.
Zitat von: vbs am 11 August 2019, 14:18:04
Soweit ich weiß, ist das aber nicht immer der Fall und hängt von dem verbauten Flash ab. Ich lasse mich aber gern korrigieren.
Ja, soweit ich weiß, werden die Pins bei QIO verwendet, und die guten ESP12 (also die von ai thinker oder espressif selbst) nutzen eben QIO.
Es gibt immer mal wieder billige Module, die meist schlechtere Flash Chips verwenden. Da geht dann meist auch nur DOUT. [emoji2369]
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hallo,
Ich habe über Settings -> Export Settings die Einstellungen exportiert, ich dachte das sei der richtige Weg..
Jetzt gehts bei mir auch, ich dachte dass GPIO9 beim RGBWW-Controller mit auf die Stiftleiste geführt ist, aber da habe ich mich verlesen / getäuscht ???
Jetzt habe ich nur noch das Problem dass wenn ich die LEDs über einen Eingang ausschalten will und anschließend wieder einschalte, dann werden sie kurz hell und faden dann gleich wieder aus. Ich denke mal dass sich der Controller da den letzten wert gemerkt hat, dann muss ich eben eine feste Farbe als Startwert vorgeben.
Vielen Dank! :)
Gruß Tobi
Guck an, stimmt die Export-Funktion gibt's da ja... hab ich noch nie benutzt. Das müsste man wohl nachpflegen @Shojo :)
Ich vermute dein Problem ist das Prellen. Versuch mal config-general-buttons_debounce_ms hochzudrehen (200 oder so).
Top funktioniert!
100 ms fürs Entprellen war wohl doch noch zuwenig :D
Danke :)
Zitat von: vbs am 12 August 2019, 19:24:57
Das müsste man wohl nachpflegen @Shojo :)
Ja da hast Du leider recht (https://github.com/o0shojo0o/esp_rgbww_webinterface/blob/0d5e458d02ad01e3cf09defef75a48be8cc6869e/src/js/controller.main.js#L169-L182)
Dort werden nur gewisse Elemente exportiert.
Allerdings muss ich erstmal dafür eine Entwicklungsumgebung wieder am laufen bekommen um das Webif wieder zu kompilieren ;)
Hallo,
kann man mit dem Modul inzwischen den WW-Kanal getrennt von RGB schalten? Um die Farbtemperatur regeln können ist das erforderlich. D.h. Die weißen LEDs sind an und mit den RGB-LEDs wird die Farbtemperatur eingestellt.
Gruß, Sascha
WW-Kanal kann im Raw-Modus getrennt geschaltet werden. Ich hab noch nirgends ein Verfahren finden können, um die Farbtemperatur per RGB sinnvoll zu verändern, so dass es zum bisherigen Modell passt. Eine händische Kalibration wird ebenfalls nötig sein.
Falls du so ein Verfahren kennst, kannst du es gerne verlinken, dann schau ich es mir an. PRs sind natürlich auch gerne gesehen.
Zu dem Raw-Modus kann ich leider keine Doku finden. Allerdings habe ich hier ich Forum gelesen, daß der Max-Wert wohl 1023 ist. Entspicht der Raw-Wert dann quasi immer dem vierfachen des eigentlichen RGB-Wertes (1023->255/ 512->127/ etc.)?
Ja genau, so ist das.
Doku ist hier:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/HTTP-Interface#get-color (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/HTTP-Interface#get-color)
Ich habe es nun auch mal geschafft einen Controller in Betrieb zu nehmen.
Nach kurzem rumspielen hab ich als erstes über das fhem-Modul ein Update per "set <device> fw_update" angestoßen.
Jetzt habe ich seit mehr als 30min "OTA in progress". Ist es normal, dass das Update dermaßen lange dauert?
Edit: ist es richtig, dass es zum fhem-Modul keinen thread oder commandref-Eintrag gibt? Ich suche nach einer vollständigen Übersicht der Befehle/Attribute und möglicher Werte.
Gesendet von iPhone mit Tapatalk
Nee ist nicht normal. Dauert normalerweise ~30 Sek. Hatte irgendwann auch schon mal einen Fall, wo es nicht fertig wurde.
Doku ist im ersten Post verlinkt.
Zitat von: vbs am 04 Oktober 2019, 15:59:54
Nee ist nicht normal. Dauert normalerweise ~30 Sek. Hatte irgendwann auch schon mal einen Fall, wo es nicht fertig wurde.
Doku ist im ersten Post verlinkt.
Und was kann man dagegen tun?
Ich hab den Controller (nach mittlerweile 2h) spannungsfrei geschalten und es anschließend über die weboberfläche neu versucht.... bisher selbes Ergebnis. Er hängt seit 10min fest.
Sorry falls ich dermaßen blind bin aber ich finde keine Übersicht, was in FHEM in den einzelnen Kommandos angegeben werden kann/muss um irgendetwas zu erreichen....
Gesendet von iPhone mit Tapatalk
So aus der Ferne ohne weitere Infos schwer zu sagen. Kannst noch etwas ausprobieren, ob externe Einflüsse (z.B. Parallelzugriffe) das irgendwie auslösen. Als permanenten Zustand hatte ich das noch nicht. Letztendlich kann es dann auf ein serielles Flashen hinaus laufen.
Doku zum Modul findest du hier:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki
Hast du dem Controller eine feste IP Adresse gegeben?
Bei mir ging es mit fester IP anfangs auch nicht. Habe dann bemerkt, dass die Subnetmask nicht übernommen wurde und auf 0.0.0.0 gesetzt war.
@vbs: Könntest du dir das bitte mal anschauen: Das Problem tritt auf, wenn bei der Ersteinrichung (im Accesspoint Modus), direkt eine statische IP eingetragen wird.
Das kann ich so bestätigen. Also war bei mir das selbe vorgehen: anschließen, einloggen, feste ip vegeben. Subnet-Maske steht bei mir aber auf 255.255.255.0
@vbs: danke für den Doku-Link. Vom kurzen Überfliegen fehlen dort doch aber einige Dinge, oder? Welche Parameter kann ich denn bei "set <device> config" angeben und was bewirken sie? Sowas hab ich eigentlich gesucht.
Gesendet von iPhone mit Tapatalk
Ahh ok, wichtige Information mit der statischen IP. Bin leider momentan nicht arbeitsfähig und auf anderen Baustellen unterwegs, aber werde es versuchen im Hinterkopf zu behalten.
Die verfügbaren Config-Parameter sind nicht spezifisch für das FHEM-Modul und daher wenn dann im Wiki zur Firmware zu finden. Aber du kannst in FHEM eine Liste der verfügbaren Parameter sehen. Viele davon (die meisten? alle?) sind dann im Wiki auf den entsprechenden thematischen Unterseiten dokumentiert. Bspw. die MQTT-Parameter hier: https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/MQTT
Zitat von: vbs am 04 Oktober 2019, 22:54:07
Die verfügbaren Config-Parameter sind nicht spezifisch für das FHEM-Modul und daher wenn dann im Wiki zur Firmware zu finden. Aber du kannst in FHEM eine Liste der verfügbaren Parameter sehen. Viele davon (die meisten? alle?) sind dann im Wiki auf den entsprechenden thematischen Unterseiten dokumentiert. Bspw. die MQTT-Parameter hier: https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/MQTT
Naja das war jetzt nur ein Beispiel. Um ehrlich zu sein bin ich gerade etwas deprimiert, da es gerade für Anfänger mit dem Controller ziemlich aufwendig/anstrengend ist sich die Möglichkeiten des Controllers/Moduls über verschiedene Wikis zusammen zu suchen. Vielleicht findet sich ja irgendwann mal Zeit oder ein User, der eine übliche Commandref erstellen könnte.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 04 Oktober 2019, 23:14:05
Naja das war jetzt nur ein Beispiel. Um ehrlich zu sein bin ich gerade etwas deprimiert, da es gerade für Anfänger mit dem Controller ziemlich aufwendig/anstrengend ist sich die Möglichkeiten des Controllers/Moduls über verschiedene Wikis zusammen zu suchen. Vielleicht findet sich ja irgendwann mal Zeit oder ein User, der eine übliche Commandref erstellen könnte.
Naja, ganz so dramatisch wie du das sagst, ist es ja nun nicht ;D. "Verschiedenen Wikis" klingt erstmal viel, aber sind es nur zwei. Btw. wenn man die commandref aufmacht, dann stehen da als aller erstes die beiden Links zu den Wikis. Hast du die evtl. übersehen?
Da die Firmware mit dem FHEM-Modul erstmal nichts zu tun hat, macht es mMn Sinn, das in zwei Teile zu trennen.
Ich persönlich würde eigentlich am liebsten die commandref dort sogar komplett entfernen, da ich die weder als übersichtlich noch als zeitgemäß empfinde. Aber falls du das anders siehst und sogar Lust hast, das zu pflegen, dann übernehme ich es gerne.
Aber wie gesagt, eine Dokumentation der Controller-FW gehört mMn halt einfach dort nicht hin.
Zitat von: vbs am 05 Oktober 2019, 00:28:28
Naja, ganz so dramatisch wie du das sagst, ist es ja nun nicht ;D. "Verschiedenen Wikis" klingt erstmal viel, aber sind es nur zwei. Btw. wenn man die commandref aufmacht, dann stehen da als aller erstes die beiden Links zu den Wikis. Hast du die evtl. übersehen?
Da die Firmware mit dem FHEM-Modul erstmal nichts zu tun hat, macht es mMn Sinn, das in zwei Teile zu trennen.
Ich persönlich würde eigentlich am liebsten die commandref dort sogar komplett entfernen, da ich die weder als übersichtlich noch als zeitgemäß empfinde. Aber falls du das anders siehst und sogar Lust hast, das zu pflegen, dann übernehme ich es gerne.
Aber wie gesagt, eine Dokumentation der Controller-FW gehört mMn halt einfach dort nicht hin.
Naja aber auch in den beiden Wikis gibt es keine Übersicht aller Befehle (auch wenn diese vielleicht auf einer Vielzahl an Unterseiten versteckt sind). Das macht es einem neulingsehr schwer herauszufinden, was über die einzelnen kommunikationskanäle (webapp, MQTT, ....) möglich ist und welche Kommandos dafür benötigt werden. Hier liegt dann doch der große Vorteil der commandef.
So wirklich losgelöst sind ja Modul und Firmware auch nicht voneinander. In einem thread mit kleinen FAQ schreibt ihr/du sogar selbst, dass beides als Einheiten zu betrachten.
dich dabei zu unterstützen macht für mich nur wenig Sinn. Da müsste ich erstmal das gesamte Wiki lesen, interpretieren und verstehen. Und auch dann muss man nach jedem Firmware-Update erstmal herausfinden was angepasst wurde (steht dann womöglich auch noch nicht gleich im wiki), um die commandref aktuell zu halten.
Nicht falsch verstehen: bisher hat sich die Umstellung wirklich gelohnt. Ich hab nur das Gefühl, dass noch sehr viel mehr drin schlummert.
Gesendet von iPhone mit Tapatalk
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
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
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.
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
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.
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
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
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.
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.
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
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 ...
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.
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
Das entspräche dann meiner zweiten Variante?
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
Ich würde es so versuchen, dass die Scannerei aufhört, sobald sich ein Client mit dem AP verbindet. Finde es ansonsten nicht schön, wenn man verbunden ist zum AP und dann der Controller dem User das Netz "unterm Arsch" wegzieht und sich wieder zum normalen WLAN verbindet.
Zitat von: vbs am 09 Oktober 2019, 22:08:11
Ich würde es so versuchen, dass die Scannerei aufhört, sobald sich ein Client mit dem AP verbindet. Finde es ansonsten nicht schön, wenn man verbunden ist zum AP und dann der Controller dem User das Netz "unterm Arsch" wegzieht und sich wieder zum normalen WLAN verbindet.
Deshalb meinte ja "wenn kein Client verbunden ist" - ich würde es allerdings nicht ganz aufgeben, sondern einfach nur unterbrechen. Es ist ja z. B. denkbar, dass sich ein Telefon kurzfristig verbindet, weil das Netz dort konfiguriert ist, aber dann der Controller nicht konfiguriert wurde.
M. E. gibt es keinen Grund, wenn ein Netz konfiguriert ist, nicht immer wieder mal nachzusehen.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Sobald ein Benutzer dann händisch eingreift, sollten dann mMn die Automatismen aufhören. Der Benutzer ist dann ja offenbar bewusst aktiv und damit würde ich dann nicht mehr kollidieren wollen. Aber den Rest seh ich auch so.
Zitat von: pjakobs am 09 Oktober 2019, 19:06:55
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.
Ich wollte damit auch nicht sagen, dass es keine Netzwerkprobleme sein können. Es ging nur um die hintergrundinfo, dass zum ein etwas höherwertiger AP im Einsatz ist und zum anderen keine anderen Anzeichen vorliegen, die mir als Nutzer die Vermutung nahe legen. Es war als reine Info zur besseren Eingrenzung gemeint.
Den arping werde ich morgen mal ausführen. Da ich mein FHEM vor kurzem in die Container Station (aka Docker) meines QNAP umgezogen habe, nur noch die Frage ob es direkt auf dem Host oder im FHEM-Container ausgeführt werden soll?
Das weitere Vorgehen mit DHCP usw. würde ich angehen, wenn der Controller ein weiteres Mal aussteigt. Bisher ist es ja ein einmaliges Ereignis.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 09 Oktober 2019, 23:30:07
Ich wollte damit auch nicht sagen, dass es keine Netzwerkprobleme sein können. Es ging nur um die hintergrundinfo, dass zum ein etwas höherwertiger AP im Einsatz ist und zum anderen keine anderen Anzeichen vorliegen, die mir als Nutzer die Vermutung nahe legen. Es war als reine Info zur besseren Eingrenzung gemeint.
Den arping werde ich morgen mal ausführen. Da ich mein FHEM vor kurzem in die Container Station (aka Docker) meines QNAP umgezogen habe, nur noch die Frage ob es direkt auf dem Host oder im FHEM-Container ausgeführt werden soll?
Das weitere Vorgehen mit DHCP usw. würde ich angehen, wenn der Controller ein weiteres Mal aussteigt. Bisher ist es ja ein einmaliges Ereignis.
Gesendet von iPhone mit Tapatalk
Ich denke, das ist direkt auf der Maschine besser aufgehoben.
Allerdings sind viele Linuxe auf solchen NAS Systemen stark eingeschränkt und können keine Pakete nachinstallieren. Du kannst das auch von jedem anderen Linux System im Netz ausführen.
pj
Gesendet von meinem HTC U11 mit Tapatalk
naive Frage, das UFO kann ich mit dieser Firmware aber nicht flashen? 8)
Zitat von: f-zappa am 10 Oktober 2019, 13:19:21
naive Frage, das UFO kann ich mit dieser Firmware aber nicht flashen? 8)
Ich hab meins am we mal aufgemacht und auf den ersten Blick sah das dort auch wie ein ESP aus..... müsste man mal schauen welches Modell und ob man den geflasht bekommt. Die firmeware gibt ja eigentlich die Möglichkeit die Pins zu konfigurieren.
Gesendet von iPhone mit Tapatalk
Zitat von: pjakobs am 09 Oktober 2019, 19:06:55
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.
Ich habe alle Devices mit händisch konfigurierten IP im Einsatz. Hatte noch nie Probleme. Sowohl mit den Platinen der ersten Marge als auch mit der aktuellen Platine. Ich war damals Beta-Tester und hatte auch so Zeugs wie Wlan aus, wieder an ... mit statischer IP getestet, hat immer sauber verbunden. Was nach dem 10ten Reconnect passiert hab ich aber vermutlich nicht probiert.
@pjakobs
Zitat von: pjakobs am 09 Oktober 2019, 18:05:21
Bei exzessiven Retransmissions kommt lwip irgendwie zu Blocks.
Bist du eigentlich zwischenzeitlich nochmal dazu gekommen, das bei dir zu testen? Wir hatten ja vor ein paar Monaten mal verschiedenste Ideen dazu und ich hatte auch im Code von lwip noch einige Stellschrauben ausfindig gemacht.
Ich würde auch gern nochmal ein "älteres" Thema wieder ansprechen:
Die Pins auf dem Header sollten ja als zusätzlich Eingänge verfügbar gemacht werden... ich glaube das absetzen eines MQTT-Topics war die bevorzugte Lösung?!?
Ist das im versandten Controller schon implementiert?
Gibts dazu eine Doku (topics)?
Gesendet von iPhone mit Tapatalk
Ja gibts, jedoch nur ein/ausschalten: https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Hardware-Push-Buttons
Sorry für das lästige nachfragen... verstehe ich das so richtig:
- ausschließlich Buttons (keine switches)
- es ist nur lokales Ein/Ausschalten möglich
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 16 Oktober 2019, 11:29:52
Sorry für das lästige nachfragen... verstehe ich das so richtig:
- ausschließlich Buttons (keine switches)
korrekt, bewusst keine Schalter, weil Schalter, die in der falschen Position belassen würden an diesen Eingängen zu unerwünschten Nebeneffekten führen. (siehe auch FAQ im Support Thread)
Zitat von: balli1187 am 16 Oktober 2019, 11:29:52
- es ist nur lokales Ein/Ausschalten möglich
das ist der Zustand der aktuellen Firmware. Mein Wunsch war, dass jeder der Taster einen Event auslöst, auf den fhem reagieren kann. Mal sehen, wann @vbs dazu kommt, sowas zu implementieren.
pj
Zitat von: pjakobs am 16 Oktober 2019, 12:20:24
das ist der Zustand der aktuellen Firmware. Mein Wunsch war, dass jeder der Taster einen Event auslöst, auf den fhem reagieren kann. Mal sehen, wann @vbs dazu kommt, sowas zu implementieren.
Okay, genau das hatte ich auch noch im Hinterkopf. Dann warte ich darauf, dass vbs nochmal etwas Freizeit erübrigen kann ;-)
Gesendet von iPhone mit Tapatalk
Zitat von: vbs am 09 Oktober 2019, 21:07:51
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 muss mich korrigieren: Wenn die 10 Versuche erreicht sind, dann macht er zwar den AP auf, aber im Hintergrund versucht er weiterhin sich zum normalen Wifi zu verbinden. Also eigentlich genau so, wie es Peter sich gewünscht hat.
Zitat von: vbs am 18 Oktober 2019, 14:09:23
Ich muss mich korrigieren: Wenn die 10 Versuche erreicht sind, dann macht er zwar den AP auf, aber im Hintergrund versucht er weiterhin sich zum normalen Wifi zu verbinden. Also eigentlich genau so, wie es Peter sich gewünscht hat.
Hmmm... Strange, irgendwas funktioniert dann bei mir nicht, denn wie schon gesagt: ich hatte eine Menge Controller, die nach einem Komplettausfall nicht wieder in's Netz laben bis ich sie wieder resettet hab.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Zitat von: vbs am 18 Oktober 2019, 14:09:23
Ich muss mich korrigieren: Wenn die 10 Versuche erreicht sind, dann macht er zwar den AP auf, aber im Hintergrund versucht er weiterhin sich zum normalen Wifi zu verbinden. Also eigentlich genau so, wie es Peter sich gewünscht hat.
Bei mir war gestern auch kurz der Strom weg und der Controller hat sich (selbst nach Stunden) nicht von alleine neu verbunden.
Da half nur aus-/einschalten. :(
Möglicherweise ist aber auch folgendes passiert:
Der FI war raus, alles war dunkel. FI wieder rein, alles startet....
Der Controller kommt relativ schnell hoch, ebenso der Devolo mit Wifi, aber die Fritze, die die IP-Adressen verwaltet, braucht ein wenig länger.
Der Controller hat zwar eine Wifi-Verbindung zum Devolo, aber der DHCP-Request geht ins Leere....
...wieviele Requests werden denn wie lange gesendet?
Kann ich nicht sagen. Das passiert irgendwo innerhalb des espressif SDKs. Müsste man wohl selbst untersuchen für belastbaren Aussage.
Ich bin mir recht sicher, dass der DNS Server eine Macke und hat den Controller zum Absturz bringt. Hab auch das Gefühl, dass er nicht richtig funktioniert. So wie ich den Code verstehe, sollte er jede beliebige Domain in die IP des Controllers umwandeln. Sprich: man muss nicht 192.168.4.1 eingeben, sondern kann auch irgendeinen Domain-Namen eingeben. Klappt bei mir aber irgendwie nicht.
@pjakobs @micky0867
Ich hätte da eine Idee, die evtl. bei euren Wifi-Problemen helfen könnte. Könntet ihr das bei euch testen, wenn ich damit mal eine entsprechende FW zusammen basteln würde?
Jepp, ich habe noch einen in Reserve. ;D
Zitat von: Pythonf am 13 Juli 2017, 18:42:52
Ich hab bereits unter dem Original FHEM-Modul meinen Vorschlag gepostet, will den aber auch hier noch unterbringen.
Ich hab eine Möglichkeit gefunden einen 4in1 RGB + WW LED Stripe ähnlich wie bei Philips Hue in der Farbtemperatur zu variieren. Meine aktuelle Umsetung ist Farbtechnisch sicherlich nicht korrekt aber sie funktioniert. Mit ein wenig Feintuning der Kurven würde man sicherlich ein noch besseres Ergebniss erzielen. Meine LEDs haben bei 100% WW laut Hersteller 3000 K. Ich habe nun eine Kurve für die Roten LEDs die bis 2000 K auf maximale Helligkeit eingestellt werden und eine zweite Funktion, welche bis 7000K alle RGB LEDs auf maximale Helligkeit einstellen. Zusätzlich wird die Helligkeit der WW LEDs von 3000 K - 7000 K um die Hälfe reduziert. Die Werte sind allerdings rein empirisch aufgenommen und entspricht somit nicht den exakten Werten. Ich verwende das ganze unter Anderem in Kombination mit den neuen Alexa Funktionen für die Farbtemperatur. Das ganze ist als cmdalias definiert.
set RGBW_.* ct .* AS {
my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;
if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};
if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);
fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}
Vielleicht kann damit ja jemand etwas anfangen oder es findet sich sogar ein Entwickler, welcher das in das FHEM Modul einbaut. Der Übergang zu Kaltweiß sieht m. M. nach sehr gut aus, in den wärmeren Bereich wird es bei direkter Betrachtung irgendwann etwas rotstichig.
das wäre schon eine sinnvolle Erweiterung... :-X
Gruß, Sascha
Fänd ich auch toll. Problem ist, dass niemand weiß wie (bzw. ob!) man das machen kann.
Zitat von: vbs am 21 Oktober 2019, 18:33:23
@pjakobs @micky0867
Ich hätte da eine Idee, die evtl. bei euren Wifi-Problemen helfen könnte. Könntet ihr das bei euch testen, wenn ich damit mal eine entsprechende FW zusammen basteln würde?
pjakobs hat sich bisher nicht gemeldet, aber ich hoffe mal stark, dass er das noch tut und bei sich auch noch testen kann:
Ich hab mal eine Firmware gemacht auf dem RC von der neuen Sming 4 Version. Ich hab da drin auch einen Bug gefixt, der mMn zu einem Crash führen kann, wenn die Wifi-Verbindung abbricht (z.B. der AP rebootet). Ich denke, dass könnte ein Grund sein, warum sich der Controller dann in diesen Fällen nicht korrekt wieder beim AP anmeldet.
Wäre super, wenn die Betroffenen (also pjakobs und micky0867 und evtl. weitere) das mal testen könnten, ob es in ihren Fällen das Problem behebt:
http://rgbww.dronezone.de/sming-3.9.x/version.json
Da das Ganze auf einer neuen Sming-Version basiert, ist es auch möglich, dass andere/neue Bugs reingekommen sind. Bei mir verhält sich die FW jedoch bisher unauffällig.
Hallo,
ich habe die neue FW ausprobiert.
Es scheint, als würde kein reconnect probiert, sobald der Controller erstmal in den AP-Mode gegangen ist.
Ich sehe zumindest kein zyklisches retry.
Gruß
Micky
Hm das blöd...
Zitat von: micky0867 am 27 Oktober 2019, 21:07:32
Es scheint, als würde kein reconnect probiert, sobald der Controller erstmal in den AP-Mode gegangen ist.
Kann ich dann daraus umgekehrt schließen, dass der Reconnect bei dir zuverlässig funktioniert, wenn der Verbindungsabbruch so kurz ist, dass er noch nicht in den AP-Mode gegangen ist?
Zitat von: micky0867 am 27 Oktober 2019, 21:07:32
Ich sehe zumindest kein zyklisches retry.
Guckst du in deinem AP oder im Log des Controllers? Hast du die Möglichkeit an das Log des Controllers zu kommen und hier zu posten (115200,8,N,1)? Wobei ich mir nicht ganz sicher bin, ob die Release-FW überhaupt etwas loggt :/ Da müsste ich im Zweifel mal forschen...
War irgendwas Spezielles an deinem testen oder einfach den Controller mit einem AP verbunden und den dann für eine gewisse Zeit abgeschaltet?
sorry Jungs, ich kann mich an der Fehlersuche hier gerade nicht beteiligen, weil ich a) ein anderes Projekt am Wickel hab und b) meine fhem Installation gerade auf einen anderen Host umgezogen habe, und da noch ein paar Dinge nicht ganz koscher sind.
pj
Ich habe nochmal alles mögliche getestet.
Ich habe eine Fritze mit Wifi, an der sich der Controller normalerweise per Wifi anmeldet und von der er seine IP bekommt.
Ausserdem habe ich einen Wifi-Router (mit LEDE drauf) mit der gleichen SSID und dem gleichen Passwort wie die Fritze, nur ein anderer Kanal. Dieser Router leitet DHCP-requests an die Fritze weiter.
Normaler Boot an der Fritze (Wifi-Router ist aus)
mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 13
cnt
connected with FRITZ!Box 7330, channel 11
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
Im Normalbetrieb die MAC des Controllers auf der Fritze gesperrt (Wifi-Router ist aus)
state: 5 -> 2 (6c0)
rm 0
pm close 7
reconnect
state: 2 -> 0 (0)
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
mode : sta(84:0d:8e:a7:53:0d) + softAP(86:0d:8e:a7:53:0d)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
scandone
Danach passiert nichts mehr
Wifi-Router aktiviert, aber Ethernet abgezogen --> DHCP-Request wird nicht weitergeleitet
mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with FRITZ!Box 7330, channel 1
dhcp client start...
pm open,type:0 0
---> nach 5 Minuten Ethernet angestoepselt <---
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
Interessant!
Ich war ja davon ausgegangen (siehe Post #1112), dass mein hängender Controller vllt im DHCP-Request festhing, weil die Fritze relativ lange braucht, um zu booten.
Controller auf Fritze gesperrt, WIFI-Router aktiviert
nach dem Boot WIFI für einige Sekunden auf WIFI-Router deaktiviert und wieder aktiviert
mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
no FRITZ!Box 7330 found, reconnect after 1s
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (29)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
---> Reconnect nach kurzer Unterbrechung funzt
Connect an WIFI-Router, WIFI ausgeschaltet und länger aus gelassen
Nachdem der Controller seinen AP aufgespannt hat WIFI wieder eingeschaltet
--> Controller bleibt im AP-Modus
mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
no FRITZ!Box 7330 found, reconnect after 1s
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
mode : sta(84:0d:8e:a7:53:0d) + softAP(86:0d:8e:a7:53:0d)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
scandone
Beide WIFIs abgeschaltet und Controller gebootet
mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
mode : sta(84:0d:8e:a7:53:0d) + softAP(86:0d:8e:a7:53:0d)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
scandone
Ich habe dem Controller immer mehrere Minuten Zeit gelassen, um sich vllt doch noch mit einem AP zu verbinden.
Ui, super! Vielen Dank für die Mühen! Werde ich mir mal in Ruhe zu Gemüte führen und versuchen rauszufinden, warum sich das bei dir anders verhält. Zu dem MAC-Filter kann ich nciht viel sagen, da mir nicht klar ist, was da technisch genau passiert, aber die Reconnects würde ich gerne verstehen.
Könntest du bitte nochmal ein list des Devices anhängen? Danke
Hallo Forum, hallo @vbs,
soweit ich das alles mitgelesen habe, bietet die Firmware (zur Zeit) keine Möglichkeit, einen GPIO "frei" zu beschalten. Die Hardware Push Buttons gehen ja schon in die Richtung, aber die schalten ja "nur" den Controller aus, oder? Ich hätte gerne einen Ausgang, über den ich meinen LED-Stripe (via MOSFET) vom "Dauerplus" trennen kann. Wenn ich es dann noch schaffe, ihn immer dann abzuschalten, wenn die Helligkeit 0 ist, dann wäre alles perfekt.
Warum ich das machen möchte? Ich kämpfe bei meinem LED-Stripe mit nachglimmen, möchte aber keine Lösung à la Widerstand parallel schalten oder so.
Ist so etwas in absehbarer Zukunft geplant? Oder gibt es schon eine Lösung, die ich nur übersehen habe?
Gruß Rainer
Zitat von: vbs am 29 Oktober 2019, 18:28:45
Könntest du bitte nochmal ein list des Devices anhängen? Danke
Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?
Zitat von: dora71 am 01 November 2019, 09:25:36
Hallo Forum, hallo @vbs,
soweit ich das alles mitgelesen habe, bietet die Firmware (zur Zeit) keine Möglichkeit, einen GPIO "frei" zu beschalten. Die Hardware Push Buttons gehen ja schon in die Richtung, aber die schalten ja "nur" den Controller aus, oder? Ich hätte gerne einen Ausgang, über den ich meinen LED-Stripe (via MOSFET) vom "Dauerplus" trennen kann. Wenn ich es dann noch schaffe, ihn immer dann abzuschalten, wenn die Helligkeit 0 ist, dann wäre alles perfekt.
Warum ich das machen möchte? Ich kämpfe bei meinem LED-Stripe mit nachglimmen, möchte aber keine Lösung à la Widerstand parallel schalten oder so.
Ist so etwas in absehbarer Zukunft geplant? Oder gibt es schon eine Lösung, die ich nur übersehen habe?
Gruß Rainer
Das verstehe ich nicht, wohin soll denn der LED Streifen "nachglimmen"? Wenn der Controller kein PWM macht, dann gibt es von den LED keinen Pfad zur Masse und dementsprechend kein (nach)Leuchten.
Sind da noch irgendwelche anderen Komponenten in Deiner Schaltung? Ich hab bald 20 Controller im Betrieb und fast meine gesamte Beleuchtung hier ist darüber realisiert und ich habe sowas noch nicht beobachtet.
Grundsätzlich bin ich aus zwei Gründen kein Freund davon, dem Controller hier mehr Fähigkeiten einzubauen:
- gab es schon die Frage nach diesem oder jenem Sensor. Wieviel zusätzliche Funktion bauen wir ein und haben wir dann am Ende nicht einfach ein anderes Tasmota? Ich denke, wir tun gut daran, den Controller das sein zu lassen, was er am besten kann.
in dem Moment, wo wir anfangen an den drei herausgeführten Pins zusätzliche, über einen Taster hinausgehende Hardware zu unterstützen fürchte ich, dass wir von Problemen überhäuft werden. Die drei Pins, die da zur Verfügung stehen sind GPIO2, GPIO0 und GPIO16 - alle haben zum Boot Zeitpunkt spezifische Bedeutung, ganz besonders GPIO16, der den Controller auf "Werkseinstellung" zurücksetzt. Daran irgendeine externe Schaltung, die, gewollt oder ungewollt, einen LOW Pegel herbeiführt und wir bekommen hier Fehler ohne Ende.
pj
Zitat von: dora71 am 01 November 2019, 09:25:36
Warum ich das machen möchte? Ich kämpfe bei meinem LED-Stripe mit nachglimmen, möchte aber keine Lösung à la Widerstand parallel schalten oder so.
Das ist mit ziemlicher Sicherheit ein Hardwareproblem. Ich hab hier 4 von den neuen Controllern, aber nur einen in Betrieb bisher. Bei dem ging auch erst ein Kanal nicht, den ich dann nachgelötet habe. Bei dem hatte ich danach jedenfalls auch das Problem, dass der noch geglimmt hat, auch wenn alle Kanäle aus waren. Also irgendwo fließt da offenbar ungewollter Weise noch Strom.
Zitat von: micky0867 am 01 November 2019, 09:52:33
Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?
Ahh ok, nee nicht so konkret tatsächlich. Wollte nur grob vergleichen, ob ich mit einer ähnlichen Config teste. Also mehr so als Paranoidmodus ^^
Falls du die Möglichkeit hast, könntest du alternativ die Ausgabe der URL "http://<IP>/config" posten.
Ich hab mal ein paar Sachen ausprobiert bzgl. Reboot-Probleme und ich hab es evtl. etwas verbessert, aber gefühlt wird das nicht 100% helfen. Da passiert recht viel unter der Haube im SDK, worauf man nicht viel Einfluss hat.
Zitat von: vbs am 01 November 2019, 12:04:09
Das ist mit ziemlicher Sicherheit ein Hardwareproblem. Ich hab hier 4 von den neuen Controllern, aber nur einen in Betrieb bisher. Bei dem ging auch erst ein Kanal nicht, den ich dann nachgelötet habe. Bei dem hatte ich danach jedenfalls auch das Problem, dass der noch geglimmt hat, auch wenn alle Kanäle aus waren. Also irgendwo fließt da offenbar ungewollter Weise noch Strom.
ah, das kann natürlich sein. Wir hatten bei der Charge, die von Elecrow gefertigt wurde (also der letzten Sammelbestellung) ein bisschen Probleme mit zu viel Lot auf den Pads des ESP12 auf der äußeren Seite. Wenn Du ein Multimeter hast, schau doch mal, ob nebeneinander liegende Pads dort zueinander kurzgeschlossen sind. Das sollten sie nicht sein.
Wenn doch, dann kommt es zu merkwürdigen Effekten.
pj
Zitat von: micky0867 am 01 November 2019, 09:52:33
Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?
Ich hab die FW nochmal geupdatet. Wenn du nochmal Gelegenheit hättest zum Testen, wäre es super:
http://rgbww.dronezone.de/sming-3.9.x/version.json
Ich glaube, ich konnte mindestens eines deiner Probleme nachstellen. Bei mir verhält sich ein normaler Disconnect anders als eine MAC-Sperre. Der normale Disconnect funktioniert mit der aktuellen Version zuverlässig (bei mir). Ich teste mit einem mobilen Hotspot auf einem Android-Device, den ich dann ein- und ausschalte.
Da das Testen sicherlich zeitaufwendig ist, können wir uns gerne erstmal auf den "normalen" Disconnect konzentrieren (anstelle des MAC-Filters. Sofern es wirklich unterschiedlich ist).
(sind auch ein paar andere Bugs bzgl Sming 4.x gefixt)
Der normale disconnect ist mit
Connect an WIFI-Router, WIFI ausgeschaltet und länger aus gelassen
Nachdem der Controller seinen AP aufgespannt hat WIFI wieder eingeschaltet
abgebildet.
Der MAC-Filter ist nur auf der Fritze. Das habe ich auch nur gemacht, damit ich meine APs nicht umkonfigurieren, bzw das WiFi an der Fritze ganz abschalten muss. An der Fritze hängen etliche Clients, am Wifi-Router normalerweise keiner.
Ich werd's mal testen.
Auf Grund von einigen Anleitungen im Internet glaube ich aber, dass man den Station-Modus immer wieder aktivieren muss, weil er es sonst nach einem Timeout nie wieder von selbst probiert...
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Meiner Erfahrung nach klappt der Reconnect generell schon, aber ein Problem ist, dass oft (aber nicht immer) die Reconnects aufhören, wenn man deinen Wifi-Scan startet (das passiert im Zuge der AP-Aktivierung). Ich weiß nicht, ob das ein Bug oder so gewollt ist. Ich triggere jetzt jedenfalls händisch ein Connect nach dem Wifi-Scan. Kann aber nicht sagen, ob das in allen Konstellationen hilft.
Zitat von: vbs am 02 November 2019, 11:36:31
Meiner Erfahrung nach klappt der Reconnect generell schon, aber ein Problem ist, dass oft (aber nicht immer) die Reconnects aufhören, wenn man deinen Wifi-Scan startet (das passiert im Zuge der AP-Aktivierung). Ich weiß nicht, ob das ein Bug oder so gewollt ist. Ich triggere jetzt jedenfalls händisch ein Connect nach dem Wifi-Scan. Kann aber nicht sagen, ob das in allen Konstellationen hilft.
Cool, jetzt funktioniert es!
Man kann sehen, dass er auch im AP-Modus immer wieder einen Connect versucht und sobald er eine Verbindung hat, den AP-Modus verlässt.
Die /config (warum wird die OTA-URL immer wieder zurück gesetzt?)
{"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW10965773"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":0,"startup_color":"last","hsv":{"model":0,"red":0,"yellow":0,"green":0,"cyan":0,"blue":0,"magenta":0},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/release/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":1000},"general":{"device_name":"","pin_config":"13,12,14,5,4","buttons_config":"","buttons_debounce_ms":50}}
Die Version
Firmware 4.1.1-rc1-58-gc695-dirty
Web Interface 0.3.3-shojo7
RGBWW Version 0.9.0
SMING Version 4.0.0-rc2
Das Log.
Connect an den Wifi-Router, dann dort Wifi abgeschaltet und nach einigen Minuten wieder eingeschaltet.
connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
no FRITZ!Box 7330 found, reconnect after 1s
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
mode : sta(84:0d:8e:a7:53:0d) + softAP(86:0d:8e:a7:53:0d)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
scandone
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
.
.
usw.usw.usw......
.
.
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (29)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt
connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
bcn 0
del if1
pm open,type:0 0
mode : sta(84:0d:8e:a7:53:0d)
Ein weiterer Test.
Der Wifi-Router ist aus, der Controller wird aus/eingeschaltet, danach wird der Wifi-Router auch eingeschaltet.
Vermutlich ist das ähnlich wie bei einem Stromausfall, der Controller ist schneller oben, als ein Wifi-Router.
Hiervon habe ich kein Log, kann aber sagen, dass es sehr lange dauert, bis ein Reconnect funktioniert.
Meine Beobachtung dazu:
Meine APs laufen auf Kanal 11 bzw. Kanal 1.
Wenn der Controller einen Connect zu einem der APs hatte und ihn wieder verliert, spannt er seinen eigenen AP unter dem zuletzt verwendeten Kanal auf.
Das ist sehr gut, weil er damit auch in der Lage ist, den ursprünglichen AP beim Scannen schnell wieder zu finden, weil sich dieser auf dem gleichen Kanal befindet.
Kann der Controller sich allerdings direkt nach einem Boot nicht mit einem AP verbinden, benutzt er standardmäßig den Kanal 7.
(https://github.com/SmingHub/Sming/blob/develop/Sming/Platform/AccessPoint.h, Zeile 60)
Daher von mir noch eine Bitte:
Es wäre super, wenn der Controller seinen AP mit dem Kanal der gespeicherten Verbindung aufspannen könnte (sofern diese Info irgendwo abgespeichert ist).
Danke Dir!
Micky
Ok, danke nochmal, klingt schon ganz gut.
Zitat von: micky0867 am 02 November 2019, 15:15:31
Die /config (warum wird die OTA-URL immer wieder zurück gesetzt?)
Es gibt in der Config die Default-URL für OTA (ota->url). Kann man bei Bedarf (wie andere Parameter auch) auf eine andere URL ändern.
Zitat von: micky0867 am 02 November 2019, 15:15:31
Meine Beobachtung dazu:
Meine APs laufen auf Kanal 11 bzw. Kanal 1.
Wenn der Controller einen Connect zu einem der APs hatte und ihn wieder verliert, spannt er seinen eigenen AP unter dem zuletzt verwendeten Kanal auf.
Das ist sehr gut, weil er damit auch in der Lage ist, den ursprünglichen AP beim Scannen schnell wieder zu finden, weil sich dieser auf dem gleichen Kanal befindet.
Hm, das ist komisch. Das ist eigentlich nicht der Fall. Du hast ja schon gesehen, dass Kanal 7 default ist laut Code und es wird auch nie ein anderer Kanal gesetzt. Ich hab es hier ausprobiert und bei mir ist mein Standard-Wifi ebenfalls Kanal 11/1. Nach dem Disconnect hat der Controller trotzdem seinen AP auf Kanal 7 aufgespannt. Bist du sicher, dass das bei dir anders war/ist?
Zitat von: micky0867 am 02 November 2019, 15:15:31
Kann der Controller sich allerdings direkt nach einem Boot nicht mit einem AP verbinden, benutzt er standardmäßig den Kanal 7.
(https://github.com/SmingHub/Sming/blob/develop/Sming/Platform/AccessPoint.h, Zeile 60)
Daher von mir noch eine Bitte:
Es wäre super, wenn der Controller seinen AP mit dem Kanal der gespeicherten Verbindung aufspannen könnte (sofern diese Info irgendwo abgespeichert ist).
Ja, wäre schon machbar. Ich bin aber noch nicht so recht überzeugt, dass das nötig ist, muss ich gestehen. Wie lange hat denn der Reconnect gedauert und bist du sicher, dass das mit dem Kanal zusammen hängt? Ich hab es hier getestet und da ging der Reconnect sofort. Also entweder mache ich hier irgendwas anders oder es liegt evtl. doch an etwas anderem.
Also ich hab den Controller gebootet (ohne externen AP) und dann macht er irgendwann seinen AP auf (auf Kanal 7). Dann hab ich den externen AP (Kanal 1) aktiviert und der Controller verbindet sich sofort (3-4 Sek.).
Zitat von: vbs am 03 November 2019, 13:18:09
Es gibt in der Config die Default-URL für OTA (ota->url). Kann man bei Bedarf (wie andere Parameter auch) auf eine andere URL ändern.
Ich war mir ziemlich sicher, beim Ersatzcontroller erst die URL gespeichert und dann das Update gemacht zu haben.
Danach war die URL wieder auf dem default :-X :-[ ???
Habe gerade den anderen Controller genauso umkonfiguriert und da bleibt die URL so, wie ich sie eingestellt habe.
Keine Ahnung, wie ich das geschafft habe.
Zitat von: vbs am 03 November 2019, 13:18:09
Hm, das ist komisch. Das ist eigentlich nicht der Fall. Du hast ja schon gesehen, dass Kanal 7 default ist laut Code und es wird auch nie ein anderer Kanal gesetzt. Ich hab es hier ausprobiert und bei mir ist mein Standard-Wifi ebenfalls Kanal 11/1. Nach dem Disconnect hat der Controller trotzdem seinen AP auf Kanal 7 aufgespannt. Bist du sicher, dass das bei dir anders war/ist?
Mit dem Kanal bin ich mir absolut sicher. Ich habe das mit dem Wifirouter (Lede) abgefragt.
Habe das auch mal mit der Fritze probiert, aber da war mir aufgefallen, dass die Fritze die Daten nur on demand aktualisiert und dabei immer die angemeldeten Stationen rausschmeisst.
Ich lese das auch hier so:
https://bbs.espressif.com/viewtopic.php?t=324
Und gefühlt hat es eine halbe Ewigkeit gedauert.
Mein Workaround: Ich habe den zugehörigen AP auf Kanal 7 konfiguriert ;D
Zitat von: micky0867 am 03 November 2019, 14:45:03
Ich war mir ziemlich sicher, beim Ersatzcontroller erst die URL gespeichert und dann das Update gemacht zu haben.
Danach war die URL wieder auf dem default :-X :-[ ???
Habe gerade den anderen Controller genauso umkonfiguriert und da bleibt die URL so, wie ich sie eingestellt habe.
In einer der Versionen von letzter Woche hatte ich noch einen Bug, wodurch die Config nicht korrekt gespeichert wurde. Vielleicht hattest du so eine Variante erwischt.
Zitat von: micky0867 am 03 November 2019, 14:45:03
Keine Ahnung, wie ich das geschafft habe.
Mit dem Kanal bin ich mir absolut sicher. Ich habe das mit dem Wifirouter (Lede) abgefragt.
Habe das auch mal mit der Fritze probiert, aber da war mir aufgefallen, dass die Fritze die Daten nur on demand aktualisiert und dabei immer die angemeldeten Stationen rausschmeisst.
Ich lese das auch hier so:
https://bbs.espressif.com/viewtopic.php?t=324
Ich habe das so verstanden, dass der Controller für den AP den gleichen Kanal wie für Station verwendet, wenn beide *gleichzeitig* verbunden sind (weil der Controller hardwaremäßig nur einen Kanal bedienen kann). Den Fall gibt es bei uns aber nie, da der AP abgeschaltet wird, sobald der Controller sich erfolgreich zum regulären AP verbunden hat. Er *versucht* zu verbinden während der AP aktiv ist, aber es ist nie beides wirklich aktiv.
Und ich hab es gerade mal getestet, indem ich das Abschalten des AP raus genommen habe:
1. Controller bootet (kein externer AP vorhanden) und schaltet dann irgendwann seinen AP ein (auf Kanal 7)
2. ich aktiviere externen AP
3. Controller verbindet sich mit externem AP auf Kanal 1
4. Durch die Modifikation schaltet er seinen AP nicht aus, aber switcht seinen AP ebenfalls zu Kanal 1 (!) <- ich denke, dass ist in der Doku gemeint
Also dass sich der Controller den Kanal der letzten erfolgreichen Verbindung speichert und dann für den AP-Modus nachnutzt, hab ich da so nicht raus gelesen und kann das auch in meinen Tests nicht bestätigen.
Zitat von: vbs am 03 November 2019, 15:17:56
Also dass sich der Controller den Kanal der letzten erfolgreichen Verbindung speichert und dann für den AP-Modus nachnutzt, hab ich da so nicht raus gelesen und kann das auch in meinen Tests nicht bestätigen.
Sorry, war vllt missverständlich.
Ich meine, wir haben bei Verlust einer vorhandenen Verbindung den Fall
Zitat
Case 1.
(1) If user connect ESP8266 station to a router(e.g. router is in channel 6).
(2) Then set ESP8266 softAP by wifi_softap_set_config.
(3) The API may return true, but channel will always be channel 6. Because we have only one hardware channel.
wifi_softap_set_config ist letztlich die Funktion, die den Soft-AP ermöglicht.
Diese bekommt einen Kanal (7) vorgegeben, ignoriert ihn aber, weil auf der Physik bereits ein Kanal gewählt/eingestellt ist bzw. war.
Der Controller probiert ja im Falle eines Verbindungsverlustes weiter, bleibt also eigentlich im Station-Mode, damit haben wir beides gleichzeitig.
Und die API meldet true zurück, obwohl der Kanal 7 bei der Konfiguration gar nicht berücksichtigt wurde...
Im Gegensatz dazu ist ein Boot des Controllers ohne Verbindung zu einem AP zu sehen.
Da wird dann für den SoftAP erstmal 7 benutzt....bis eine Verbindung zu einem bereits konfigurierten AP hergestellt wird.
Aber dazu muss der Controller u.U. den Kanal wechseln und schmeisst damit ggf bereits angemeldetete Stationen wieder raus.
Zitat
Case 2.
(1) If user set ESP8266 softAP a channel number(e.g. channel 5) by wifi_softap_set_config.
(2) Some stations connected to ESP8266 softAP.
(3) Then connect ESP8266 station to a router of which channel number is different (e.g. channel 6).
(4) ESP8266 softAP has to adjust its channel to be as same as ESP8266 station, in this case, is channel 6.
(5) So the stations that connected to ESP8266 softAP in step 2 will be disconnected because of the channel change.
Und wo ich jetzt nochmal darüber nachdenke:
Wenn der Kontroller im Fall 2 für einem Reconnect-Versuch sowieso selbstständig verschiedene Kanäle probiert, hat es auch wenig Zweck, diesen beim SoftAP vorzugeben.
Schlimmstenfalls dauert ein Reconnect einen kompletten Kanal-Zyklus oder wie auch immer das heissen mag, bzw. der Algorithmus dafür aussehen mag.
Zitat von: micky0867 am 03 November 2019, 16:15:54
Sorry, war vllt missverständlich.
Ich meine, wir haben bei Verlust einer vorhandenen Verbindung den Fall
wifi_softap_set_config ist letztlich die Funktion, die den Soft-AP ermöglicht.
Diese bekommt einen Kanal (7) vorgegeben, ignoriert ihn aber, weil auf der Physik bereits ein Kanal gewählt/eingestellt ist bzw. war.
Mmn ist das hier nicht so: da der AP erst aufgemacht wird, *nachdem* die normale Verbindung verloren wurde, kann dann für den AP durchaus der im Code übergebene Kanal 7 genutzt werden. Das passt auch zu dem, was ich beim Testen sehe.
Zitat von: micky0867 am 03 November 2019, 16:15:54
Der Controller probiert ja im Falle eines Verbindungsverlustes weiter, bleibt also eigentlich im Station-Mode, damit haben wir beides gleichzeitig.
Und die API meldet true zurück, obwohl der Kanal 7 bei der Konfiguration gar nicht berücksichtigt wurde...
Nochmal in anderen Worten:
Da der AP erst aufgespannt wird, nachdem die "normale" Verbindung verloren wurde, ist dann der AP-Modus auch nicht mehr an Kanal der vorherigen, "normalen" Verbindung gebunden. Du kannst das ja mit Wifi Analyzer Apps für Android/Windows/iOS/whatever auch recht leicht sehen, welchen Kanal der Controller-AP gerade verwendet.
Ich hoffe, wir reden nicht irgendwie aneinander vorbei.
Zitat von: micky0867 am 03 November 2019, 16:15:54
Im Gegensatz dazu ist ein Boot des Controllers ohne Verbindung zu einem AP zu sehen.
Da wird dann für den SoftAP erstmal 7 benutzt....bis eine Verbindung zu einem bereits konfigurierten AP hergestellt wird.
Aber dazu muss der Controller u.U. den Kanal wechseln und schmeisst damit ggf bereits angemeldetete Stationen wieder raus.
Seh ich auch so (bis auf den Gegensatz).
Zitat von: micky0867 am 03 November 2019, 16:15:54
Und wo ich jetzt nochmal darüber nachdenke:
Wenn der Kontroller im Fall 2 für einem Reconnect-Versuch sowieso selbstständig verschiedene Kanäle probiert, hat es auch wenig Zweck, diesen beim SoftAP vorzugeben.
Schlimmstenfalls dauert ein Reconnect einen kompletten Kanal-Zyklus oder wie auch immer das heissen mag, bzw. der Algorithmus dafür aussehen mag.
Ich kenne mich technisch nicht genug mit dem Wifi-Connect-Mechanismus aus, aber meinen Beobachtungen zufolge muss der Controller bei den Connect-Versuchen nicht die Kanäle "durchschalten". Da er das ständig macht, müssten doch ebenso ständig alle Clients vom AP fliegen?
EDIT:
ZitatCase 1.
(1) If user connect ESP8266 station to a router(e.g. router is in channel 6).
(2) Then set ESP8266 softAP by wifi_softap_set_config.
(3) The API may return true, but channel will always be channel 6. Because we have only one hardware channel.
Mein Punkt ist: Zwischen Schritt 1) und 2) ist ja nicht die Rede davon, dass die Verbindung aus 1) wieder verloren wird. Die haben hier wirklich beide Verbindungen gleichzeitig.
Da stimmt wohl beides....obwohl es seltsam ist.
Ich habe den Wifi-Analyzer bemüht.
Den Wifi-Router habe ich jetzt doch umkonfiguriert, damit ich eine andere Umgebung habe.
Die SSID lautet esptest.
Im ersten Screenshot sieht man den Controller und den Wifi-Router zusammen auf Kanal 13.
Im zweiten sieht man den Controller auf Kanal 7.
Zwischen den beiden Screenshots liegt ca. 1 Minute.
Vermutlich wird erst der AP aktiviert und dann der Kanal gesetzt.
Ich hab eine Firmware 4.3.0-rc1 auf den "testing"-Kanal gestellt:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Release-History
Vielen Dank nochmal an micky0867 fürs Testen!
Hi,
ich hab auf die neue 4.0.3-rc1 4.3.0-rc1 aktualisiert, bisher läuft diese. Soll man auf was bestimmtes achten vbs ? :)
Ronny
Zahlendreher von mir: Version ist "4.3.0" und nicht "4.0.3". Aber das nur am Rande... 8)
Version basiert auf dem neuen Sming 4, was ein recht großes Update war. Also da kann generell alles passieren :) Aber bei mir bisher unauffällig.
Ansonsten ist das Reconnect-Verhalten bei Wifi-Verlust (hoffentlich) deutlich verbessert. Also das könnte man gezielt im Auge behalten.
Da hab ich ja Glück gehabt, und gleich alle Controller auf die neueste Version gehoben. Bisher keine Klagen
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hoi,
bei mir bisher auch alles Top, kein nix negatives berichten. Rennt wie immer :D
Ronny
habe auch mal ein update gemacht.
Hatte 2 Controller damals in mein ioBroker mqtt eingebunden weiß nicht mehr warum aber mit der neuen fw kommen extrem viele nachrichten.
mqtt.0 2019-11-19 23:04:05.540 info (31098) Client [Kueche2] connected with secret
mqtt.0 2019-11-19 23:04:05.375 info (31098) Client [Kueche1] connection closed: Error: Invalid messageId
mqtt.0 2019-11-19 23:04:05.365 warn (31098) Client [Kueche1] Message undefined deleted after 1317 retries
weiß nicht ob das von relevanz ist. habe mqtt erstmal aus gemacht.
Hoffe aber das das MQTT an sich zur Sync der Module noch geht. Habe ich aber nicht getestet gehabt.
Hm, das ist interessant. Sagt mir aber ehrlich gesagt nicht viel.
Vielleicht eine dumme Frage aber was benötigt die Firmware an minimaler Hardware?
Ich brauche nur einen Kanal (Warmweiße stripes) - reicht dafür ein ESP01 und der entsprechendem Zuordnung zu einem GPIO oder müssen zwingend alle Kanäle auf einen GPIO gemapped werden?
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 24 November 2019, 21:22:48
Vielleicht eine dumme Frage aber was benötigt die Firmware an minimaler Hardware?
Ich brauche nur einen Kanal (Warmweiße stripes) - reicht dafür ein ESP01 und der entsprechendem Zuordnung zu einem GPIO oder müssen zwingend alle Kanäle auf einen GPIO gemapped werden?
Gesendet von iPhone mit Tapatalk
der ESP01 wird eher nicht funktionieren, aber nicht so sehr wegen der Ausgangs-Kanäle, sondern aufgrund der Tatsache, dass die FW einen CLR Eingang auf GPIO16 erwartet. Wenn der beim Start LOW ist, wird die lokale Konfiguration gelöscht und der Controller startet wieder seinen AP. Du müsstest den GPIO16 über einen Pullup Widerstand HIGH ziehen, dann funktioniert dieser Teil.
Allerdings glaube ich, dass auf den beiden GPIO des ESP01 PWM nicht richtig funktioniert, jedenfalls hat das in meinen Tests nie wirklich geklappt.
Dazu kommt, dass der ESP01 nur 1MB Flash hat, und Du erst den Flash Chip gegen einen 32MBit Typen tauschen musst. Das allerdings ist keine schwierige Aufgabe.
tl;dr: ESP01 geht eher nicht.
pj
Okay, danke für die Antwort. ESP01 hätte ich halt noch liegen und da ich nur einen Kanal brauche....
Aber bevor ich da anfange den Flash zu tauschen, kann ich mir auch einfach nen esp12 bestellen ;-)
Gesendet von iPhone mit Tapatalk
Hab auch die neuste "Testing" seit 3 Tagen drauf, geht einwandfrei.
Danke!
Das ist vielleicht ne blöde Frage aber welche Software empfehlt ihr zum flashen der Firmware vom Windows PC aus?
Tasmota Flasche ich via Atom aber wie läuft das hier mit den unterschiedlichen Binaries?
Gesendet von iPhone mit Tapatalk
Ich flashe mit esptool (im ersten Post beschrieben). Sollte auch unter Windows funktionieren.
Zitat von: vbs am 28 November 2019, 22:24:35
Ich flashe mit esptool (im ersten Post beschrieben). Sollte auch unter Windows funktionieren.
Hm.... bei command line denk ich irgendwie nicht an Windows [emoji28]
Werd's mal probieren.... Danke!
Gesendet von iPhone mit Tapatalk
Esptool... die ganzen flasher haben bei mir nie funktioniert. Wenn du weitere Hilfe brauchst sag Bescheid
Gesendet von meinem SM-G930F mit Tapatalk
Ich hab mir jetzt Python for Windows installiert und versucht mit dem esptool zu flashen. Leider krieg ich immer die Fehlermeldung, dass der COM-Port nicht geöffnet werden kann.
Mit dem nodeMCU-Flasher kann ich die drei binaries aus dem wiki flashen aber hi tether sehe finde ich kein entsprechendes Netzwerk für die weitere Konfiguration. Der Controller sollte doch im AP-Modus starten oder?
P.S.: sorry für die off-topic newbie-Fragen ....
Gesendet von iPhone mit Tapatalk
direkter Hardwarezugriff --> esptool "als Admin" starten.
das ist zumindest ne häufige Ursache wenn COM Port Zugriff nicht geht.
Zugriff auf COM-Port geht mW ohne Admin-Rechte. Ich würde ansonsten vermuten, dass der COM-Port schon von jemand anderem geöffnet ist. Evtl. mal mit zB. ProcessExplorer nach offenen Handles auf den Port suchen.
Habe es sowohl als User als auch als Admin probiert - kein Unterschied.
Das ein anderes Programm bereits darauf zugreift, kann ich mir nicht so recht vorstellen, da ich sonst nichts weiter gestartet hatte und ich auch immer wieder versucht habe den FTDI abgezogen und neu angesteckt hab. Aber werds trotzdem mal probieren.
Gesendet von iPhone mit Tapatalk
In einer DOS Box "Mode com1"
So bekommst heraus ob der Port aktuell belegt ist.
Kommt eine Liste Werte ist der Port frei.
Ansonsten kommt eine belegt Meldung.
Gesendet von meinem S60 mit Tapatalk
Moin,
Mit mode COM2 erhalte ich den Status mit Baudrate, etc. daher gehe ich mal davon aus, dass derPort nutzbar ist.
Ich habe es jetzt auch mal mit dem anderen Befehl unter dem Hinweis "<4.0.0" versucht und nach leichter Anpassung (esptool.PY statt nur esptool) fängt er an zu flashen und es sieht soweit gut aus.
Leider aber auch dann hinterher kein entsprechendes WLAN. Mit einem Wemos D1 Mini das gleiche Verhalten.
Gesendet von iPhone mit Tapatalk
Hast Du mal die Stromversorgung am ESP nachgemessen?
Zitat von: Frank_Huber am 30 November 2019, 12:07:29
Hast Du mal die Stromversorgung am ESP nachgemessen?
Nachgemessen hab ich bisher nicht. Es werden ja beide auch bei einem erneuten flash-Versuch erkannt.
Auf dem Wemos war vorher Tasmota - hat auch funktioniert am usb-Kabel.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 30 November 2019, 12:54:38
Nachgemessen hab ich bisher nicht. Es werden ja beide auch bei einem erneuten flash-Versuch erkannt.
Auf dem Wemos war vorher Tasmota - hat auch funktioniert am usb-Kabel.
Gesendet von iPhone mit Tapatalk
Kannst Du mal ein paar Details liefern?
Welchen Chip hast Du da? Steckt da ein esp12 drauf?
Welchen Flash Mode verwendest Du? (DIO/DOUT/QIO?)
Wenn Du eine serielle Konsole auf den Port öffnest (Baudrate 115200) - siehst Du beim Start des Controllers lesbaren Text?
pj
Gesendet von meinem HTC U11 mit Tapatalk
Zitat von: pjakobs am 30 November 2019, 14:01:13
Kannst Du mal ein paar Details liefern?
Welchen Chip hast Du da? Steckt da ein esp12 drauf?
Welchen Flash Mode verwendest Du? (DIO/DOUT/QIO?)
Wenn Du eine serielle Konsole auf den Port öffnest (Baudrate 115200) - siehst Du beim Start des Controllers lesbaren Text?
pj
Gesendet von meinem HTC U11 mit Tapatalk
Ich versuche alles an Informationen mitzugeben aber mein Wissen ist leider begrenzt... sorry.
Auf dem Wemos steckt ein esp12 soweit ich weiß. Beschriftet ist er mit ESP8266MOD.
Die Platine um die es mir eigentlich geht, steckt in einem Lagute LW12. Dort sitzt ein ESP8266EX drauf. Anbei 2 Fotos ... ich hoffe es ist zu erkennen.
Zum flashen nutze ich folgenden Befehl aus dem Wiki
esptool.py -p COM2 -b 115200 write_flash -ff 40m -fm qio -fs 32m 0x00000 rboot.bin 0x02000 rom0.bin 0x100000 spiff_rom.binWenn ich das richtig verstehe ist der flash-Mode QIO....
Gesendet von iPhone mit Tapatalk
Wenn ich die Kennung auf dem Winbond Chip richtig lese, dann ist das ein 8MBit flash (250800) das ist für die esp_rgbww Firmware zu klein, Du brauchst die 32MBit Variante (253200) - die chips kannst Du einzeln kaufen und verlöten, oder Du kaufst gleich ein 32MBit Modul (die ESP12 haben alle 32MBit).
Now, warum Du da nicht schon beim Flashen ne fette Fehlermeldung bekommst (schließlich gibst Du ja mit -fs 32m den Speicherbedarf mit) weiß ich nicht.
Grüße,
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hm.... okay. Herzlichen Dank für die Hilfe.
Parallel hatte ich auch versucht Tasmota auf den LW12 zu flashen, was auch funktionierte.
Hast du eine Idee weshalb es auch beim Wemos nicht klappt? Der müsste doch genug Flash haben?!
Gesendet von iPhone mit Tapatalk
ich meine, je nach build Options, kannst Du mit Tasmota mit 8MBit auskommen.
und - wenn Du sagst, dass es "auch beim Wemos nicht klappt" - sei so gut und poste doch mal folgendes:
- die Konsolenausgabe des Flash Prozesses
- die Ausgabe an der Seriellen Schnittstelle beim Starten des ESP
und nebenbei: warum machst Du Dir das Leben so schwer?
Ich meine, klar, wir haben alle mal angefangen und Versuch macht kluch, aber wäre es nicht einfacher, wenn Du Dir einen der fertigen Controller nehmen würdest? Drüben im Sammelbestellungsthread bahnt sich gerade wieder was an und ich könnte auch noch einen hergeben.
Nicht falsch verstehen, ich will Dich nicht davon abhalten, aus gelösten Problemen zu lernen, aber vielleicht ist der Weg ja einfacher, wenn es nicht unbedingt diese, doch eher komplexe Firmware sein muss.
danke
pj
Da hast du natürlich recht, ich könnte auch einen eurer Controller nehmen. Hab bei der letzten Bestellung auch 5 geordert....
Ich hatte den LW12 (genauso wie ein Ufo) einfach noch hier liegen und eigentlich brauche ich auch nur einen Kanal für warmweiße stripes. Dafür sind mir eure Controller bisschen zu schade und ich dachte ich versuche mal den LW12 doch noch nutzen zu können...
Die Fades find ich bei dieser Firmware hervorragend aber ich werd jetzt mal versuchen ob mir Tasmota in diesem Fall nicht auch ausreicht....
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 30 November 2019, 17:52:18
Da hast du natürlich recht, ich könnte auch einen eurer Controller nehmen. Hab bei der letzten Bestellung auch 5 geordert....
Ich hatte den LW12 (genauso wie ein Ufo) einfach noch hier liegen und eigentlich brauche ich auch nur einen Kanal für warmweiße stripes. Dafür sind mir eure Controller bisschen zu schade und ich dachte ich versuche mal den LW12 doch noch nutzen zu können...
Die Fades find ich bei dieser Firmware hervorragend aber ich werd jetzt mal versuchen ob mir Tasmota in diesem Fall nicht auch ausreicht....
Gesendet von iPhone mit Tapatalk
ah, verstehe.
na ja, "zu schade" ist halt so'n Ding, die kosten ja auch nicht die Welt.
Ich hab ja jetzt etliche in diese Iidl Lampen verbaut, und kann Dir sagen:
alles, was Die Firmware braucht ist
- ein ESP12 (32MBit Flash)
- ein Pullup an GPIO 16
- die anderen üblichen ESP8266 pullups und pulldowns (CH_PD, GPIO2, GPIO0, GPIO15)
- ein bis fünf PWM Ausgänge
Wenn Du LED Strips treiben willst und *keinen* externen PWM fähigen Controller hast, dann brauchst Du halt noch die n-Channel MOSFETS, die die Kathode der LEDs gegen Masse schalten. (Getestet sind AOD2910, AOD4806 und IRLZ44N, aber es sollten im Grunde alle funktionieren, die mit 3.3V VGS durchschalten)
Eigentlich kein Hexenwerk.
pj
Zitat von: pjakobs am 30 November 2019, 18:45:09
Getestet sind AOD2910, AOD4806 und IRLZ44N, aber es sollten im Grunde alle funktionieren, die mit 3.3V VGS durchschalten.
AOD2810 sollten doch auch gehen, 100 V V
DS sollten ja nicht nötig sein, oder? Zumindest habe ich diese zum Testen da ...
Gruß Peter
Zitat von: PeMue am 02 Dezember 2019, 08:07:28
AOD2810 sollten doch auch gehen, 100 V VDS sollten ja nicht nötig sein, oder? Zumindest habe ich diese zum Testen da ...
Gruß Peter
Die 2810 waren meine erste Wahl, die konnte ich aber nicht in vernünftiger Stückzahl kaufen und deshalb hab ich den 2910 genommen.
pj
Gesendet von meinem HTC U11 mit Tapatalk
Hallo vbs, ein herzliches Dankeschön für diese coole Software. Sie veredelt meine neueste Bastelei, nämlich den uralten aber geliebten Philips LivingColors Lampen ein zeitgemässes Innenleben zu verpassen ;)
Hallo,
ich schalte meine LEDs abends per at-Befehl und on-for-timer für einige Stunden an.
Gestern abend habe ich fhem neu gestartet und die LEDs gingen nicht von alleine aus.
Jetzt liegt die Vermutung nahe, dass der Timer nicht im Aktor selbst, sondern im FHEM-Modul hinterlegt ist.
Bisher habe ich gedacht, ich könnte Perl (und sogar fremden Perlcode) ganz gut lesen, aber hier stehe ich voll auf dem Schlauch.
Kann mich jemand erleuchten, wie on-for-timer implementiert ist?
Ich schnalle es einfach nicht.
Micky
on-for-timer ist, wie die anderen on-for und off-for settings, ein Teil von Set Extensions (https://forum.fhem.de/index.php?topic=10642.0)
Von daher ist Deiner Vermutung korrekt: die zugehörigen Timer sind Teil von fhem. Ob allerdings diese nach einem Restart korrekt aus dem statefile neu geladen werden weiß ich nicht. Nach Deiner Beschreibung scheinbar nicht.
pj
Danke, das hatte ich überlesen! :-[
Und hier steht auch, warum das Licht nicht augegangen ist:
https://fhem.de/commandref.html#set
Zitaton-for-timer <seconds>
Issue the on command for the device, and after <seconds> the off command. For issuing the off command an internal timer will be scheduled, which is deleted upon a restart. To delete this internal timer without restart specify 0 as argument.
Hi,
ich habe jetzt meine 2 Controler auf die vbs-FW aktualisiert. Soweit funktioniert auch alles gut - großes Danke an VBS :)
Zwei Fragen habe ich dazu:
Habe an einem Controler einen RGBWW-Stripe dran und habe mit einem RAW-Kommando (alte FW) alle LEDs auf Maximum geschalten. Mit der neuen FW gehen dabei alle LEDs aus. Inwieweit wurde hier etwas geändert? Habe auf Anhieb nichts dazu gefunden.
Ich würde gern einen Stripe in der Küche für die Frau eine Stunde leuchten lassen. Das wird in einer Szene gestartet. Funktioniert leider mit on-for-timer irgendwie nicht. Bin davon ausgegangen das set Arbeitslicht hsv xxxxxxx on-for-timer 3600 das eine Stunde brennen läßt - geht leider nicht. Entweder Fehlermeldung oder es leuchtet einfach weiter. Hab den ganzen Abend nach einer Lösung hier im Forum gesucht, aber leider nichts brauchbares gefunden. Vermutlich habe ich diese Funktion nicht richtig verstanden - hab das erstemal damit Berührung. Kann mir da jemand weiterhelfen?
Hi,
mach doch
set Arbeitslicht hsv 50,,100
set Arbeitslicht on
define MeineAktion at +01:00:00 set Arbeitslicht off
Oder alles in einer Zeile mit ; oder ;; getrennt. Probier doch mal.
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Zitat von: SalvadoreXXL am 14 Januar 2020, 13:30:10
Bin davon ausgegangen das set Arbeitslicht hsv xxxxxxx on-for-timer 3600 das eine Stunde brennen läßt - geht leider nicht.
Syntax ist auch nicht korrekt so. Probier mal "set Arbeitslicht on-for-timer 3600". Doku in der commandref: https://fhem.de/commandref_DE.html#set
Zu dem anderen Problem bitte Hinweise im ersten Post beachten und mehr Informationen liefern, was du genau gemacht hast. Guck ich mir dann an, wenn da was nicht funktioniert.
Zitat von: vbs am 14 Januar 2020, 15:22:24
Syntax ist auch nicht korrekt so. Probier mal "set Arbeitslicht on-for-timer 3600". Doku in der commandref: https://fhem.de/commandref_DE.html#set
Das hatte ich schon ausprobiert und funktioniert auch. Allerdings möchte ich eine Farbe und Helligkeit mitgeben. Dann funktioniert das nicht.
Zitat von: vbs am 14 Januar 2020, 15:22:24
Zu dem anderen Problem bitte Hinweise im ersten Post beachten und mehr Informationen liefern, was du genau gemacht hast. Guck ich mir dann an, wenn da was nicht funktioniert.
da schaue ich heute Abend mal zuhause nach. Hab das nicht im Kopf :)
Zitat von: SalvadoreXXL am 14 Januar 2020, 15:35:15
Das hatte ich schon ausprobiert und funktioniert auch. Allerdings möchte ich eine Farbe und Helligkeit mitgeben. Dann funktioniert das nicht.
Ja, das "on-for-timer" kann wirklich nur einen reinen "on"-Befehl soweit ich weiß.
Aber du kannst es mit einem Workaround trotzdem nutzen, in dem du mit einem Befehl erst die gewünschte Farbe setzt (ohne die LED einzuschalten) und dann on-for-timer nutzt:
set Arbeitslicht hsv 50,56,;set Arbeitslicht on-for-timer 3600(das klappt, weil der "on" Befehl die Farbe nicht ändert, sondern wirklich nur die Helligkeit anpasst)
Kannst es aber auch wie von Arnd vorgeschlagen machen. Ist mMn eine ebenso gute Variante. Nur andere Schreibweise.
Danke für eure Hilfe. Ich hatte die Timerfunktion dann doch falsch verstanden. Mangels Zeit konnte ich gestern nur kurz testen. Irgendwie werden die Kommandos aus der Lichtszene unterschiedlich gehandhabt. Hatte das Gefühl, das hier einzelne Kommandos "verschluckt" werden. Muß mich da mal intensiver drum kümmern. Zumindst habe ich jetzt einen Ansatz.
Das RAW-Kommando hat gestern nun doch funktioniert. Merkwürdig, da ich nichts anders gemacht habe.
Hi,
das hängt doch nur von der Queue policy ab, oder? ,,Verschlucken" ist eben ein reset.
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Queue-Policies
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Wenn ich die Kommandos nacheinander sende, sollten die doch in gleicher Reihenfolge "abgearbeitet" werden. Hier handelt es sich doch um keine Animation. Zuerst setze ich hsv ... (inkl. Helligkeit), dann schalte ich off und dann mit on-for-timer an. Funktioniert leider nicht so. Habe eher das Gefühl, das der erste Befehl nicht ausgeführt wird. Muss ich mir dann mal in den Logs anschauen.
Konnte jetzt nochmals kurz testen. Folgendes möchte ich nacheinander ausführen um 20 Sekunden Nachtlicht zu schalten:
set LED_Controller_2 hsv 240,100,1 2 ;set LED_Controller_2 off ;set LED_Controller_2 on-for-timer 20
Lasse ich das so ausführen, geht für 20 Sekunden irgeneine Lichtfarbe bei voller Helligkeit an.
Gebe ich das nacheinander zeilenweise ein
set LED_Controller_2 hsv 240,100,1 2
set LED_Controller_2 off
set LED_Controller_2 on-for-timer 20
funktioniert das wie gedacht. Wo ist mein Denkfehler
Im Prinzip ist jedes Farb-Kommando eine Animation (normalerweise mit Default-Ramp). Bei deinem ersten Befehl gibst du ja eine 2-Sekunden Ramp mit. Wenn du dann sofort den off-Befehl hinterher schiebst, dann wird die erste Animation abgebrochen, da du kein Queue-Flag benutzt (z.B. "q"). Also die Beschreibung aus Arnd's Link ist relevant. Die Hintergründe sind da aber zugegebenermaßen nicht gut erklärt.
Vielleicht magst du ja mal eine der Lösungen probieren, die wir weiter oben gepostet hatten :)
irgeneine Lichtfarbe bei voller Helligkeit an.
Du kommandierst ja einen Fade vom aktuellen Hue zu Hue 240 mit 2 Sekunden, den du sofort abbrichst. Also je nachdem wo er startet, fadet er nur wenige Millisekunden Richtung Hue 240 und bleibt dann stehen.
@vbs - früher gab es ja eine null ramp, a.k.a. "pause" - die ist dann aber in der neueren Version wegrationalisiert worden, oder?
Sowas könnte man natürlich auch schreiben als "set hsv 0,0,80 2 ;set pause 20 q; set hsv 0,0,0 2 q"
Ich hab das in einer Animation mal umgesetzt als "set hsv 0,0,80 2;set hsv -0,-0,-0 20 q;set hsv 0,0,0 2 q" - damit geht das Licht für 20s an und automatisch wieder aus, ohne, dass fhem was tun müsste.
Ich halte aber die "Animation" um -0 in allen Kanälen für ein bisschen getrickst.
pj
Hab mich mit den Queues noch nicht beschäftigt, da ich davon ausgegangen bin das alles nacheinander abgearbeitet wird. So passt das allerdings genau zu dem Verhalten. Mal sehen, ob ich heute Abend noch ein wenig Zeit finde zu testen.
Zitat von: pjakobs am 16 Januar 2020, 14:55:41
@vbs - früher gab es ja eine null ramp, a.k.a. "pause" - die ist dann aber in der neueren Version wegrationalisiert worden, oder?
Sowohl Funktion als auch den Befehl "pause" gibt es weiterhin. Der Befehl hat jedoch jetzt eine andere Bedeutung, da die alte Variante mMn semantisch nicht mit dem Konzept der getrennten Kanäle vereinbar war. Hat jetzt zusammen mit "continue" aber eine neue Daseinsberechtigung gefunden.
Inhaltlich geht das z.B. wie von dir beschrieben. Wenn du sagst, dass das "-0" aber nicht so schön zu schreiben/lesen ist, dann bin ich bei dir. Man könnte als "Syntatic Sugar" noch sowas spendieren wie "p" (mit der gleichen Bedeutung wie "-0"), aber wenn man die Flexibilität der einzelnen Kanäle haben möchte, dann kann man das nicht komplett vermeiden mMn.
Hallo,
mal eben ne Zwischenfrage:
Ist es möglich die Firmware auf einen ESP-01 zu flashen um damit einen einzigen Kanal für einen weißen Strip zu steuern.
Ich hab das eben mal frech probiert. Flashen läuft auch durch, aber der AP öffnet sich nicht.
Wahrscheinlich passt das Pin Layout ja auch nicht. Kann man das auf die beiden verfügbaren IO1 und IO0 anpassen ?
Wo muß dann die Brücke zum Resetsignal gesetzt werden ?
Hat das schon jemand probiert ?
Oder ist das nicht machbar ?
Zitat von: Skusi am 02 Februar 2020, 19:18:37
Hallo,
mal eben ne Zwischenfrage:
Ist es möglich die Firmware auf einen ESP-01 zu flashen um damit einen einzigen Kanal für einen weißen Strip zu steuern.
Ich hab das eben mal frech probiert. Flashen läuft auch durch, aber der AP öffnet sich nicht.
Wahrscheinlich passt das Pin Layout ja auch nicht. Kann man das auf die beiden verfügbaren IO1 und IO0 anpassen ?
Wo muß dann die Brücke zum Resetsignal gesetzt werden ?
Hat das schon jemand probiert ?
Oder ist das nicht machbar ?
Nein das funktioniert nicht. Der ESP01 hat wohl zu wenig Speicher. Ich hatte es auch mal probiert, bin dann aber auf Tasmota ausgewichen.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 02 Februar 2020, 19:44:35
Nein das funktioniert nicht. Der ESP01 hat wohl zu wenig Speicher. Ich hatte es auch mal probiert, bin dann aber auf Tasmota ausgewichen.
Gesendet von iPhone mit Tapatalk
Das ist nicht der einzige Grund, die Firmware erwartet auch einen pull-up an gpio16, und der ist am esp-01 nicht herausgeführt
pj
Gesendet von meinem HTC U11 mit Tapatalk
Die Software könnte man sicherlich flexibel bzw. konfigurierbar gestalten. Wenn sie natürlich nicht in den Flash passt, dann ist es ein größeres Problem.
Neue Firmware im testing-Kanal: 4.3.1-rc1
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Release-History
Tja, schade. Hab nochmal nachgesehen, der ESP-01 hat wohl nur 1 MB Flash. Das Reicht leider gerade so nicht aus.
Da hab ich mir doch eine schönen kleinen Led Controler auf ESP-01 basis fürs Aufwachlicht im Schlafzimmer gebaut, und nun muß ich den leider mit Tasmota betreiben.
Die VBS Firmware kann aber vieel schöner und feiner Dimmen. Nun ist die kleinste Dimmstufe bei Tasmota schon zu Hell.
Abgesehen davon das das langsame Hoch dimmen in sichtbaren schritten passiert. Eben leider nur in 8 Bit.
Wen ich nun auf einen Wemos D1 mini mit VBS umsteige könnte ich dann die Led´s weiter runter dimmen ? Oder ist der kleinste PWM Pulse gleich wie bei Tasmota ?
Ich hab Tasmota noch nicht gesehen für LEDs, aber diese Firmware hier dimmt mMn ohne sichtbare Stufen und linear bis ganz runter bzw. aus.
Nur fürs Protokoll: das ist nicht unbedingt meine Firmware. Ich habe lediglich eine Reihe von Funktionen hinzugefügt und pflege sie momentan. Die ganzen Grundlagen und die Urfassung der Firmware stammen von Patrick Jahns (https://github.com/patrickjahns). Sollte man ab und zu mal wieder erwähnen, um keinen falschen Eindruck zu erwecken :)
Zitat von: Skusi am 05 Februar 2020, 19:48:02
Tja, schade. Hab nochmal nachgesehen, der ESP-01 hat wohl nur 1 MB Flash. Das Reicht leider gerade so nicht aus.
Da hab ich mir doch eine schönen kleinen Led Controler auf ESP-01 basis fürs Aufwachlicht im Schlafzimmer gebaut, und nun muß ich den leider mit Tasmota betreiben.
Die VBS Firmware kann aber vieel schöner und feiner Dimmen. Nun ist die kleinste Dimmstufe bei Tasmota schon zu Hell.
Abgesehen davon das das langsame Hoch dimmen in sichtbaren schritten passiert. Eben leider nur in 8 Bit.
Wen ich nun auf einen Wemos D1 mini mit VBS umsteige könnte ich dann die Led´s weiter runter dimmen ? Oder ist der kleinste PWM Pulse gleich wie bei Tasmota ?
Du kannst auf einen ESP 01 ja einen 32MBit flash chip auflöten - dann bleibt aber immer noch das Problem, dass Du GPIO16 auf high ziehen musst und dass GPIO0 und 2 iirc irgendwie schwierig als pwm output sind
pj
Gesendet von meinem HTC U11 mit Tapatalk
Ich habe Controller mit der Hardware 1.5 (die schwarze Platine) die auch schon mal komplett funktionierten.
Bei einigen ist die Weboberfläche nicht mehr erreichbar, über das Fhem Modul ließen sie sich noch ansprechen.
Ich wollte sie daher mal komplett auf die neueste Version aktualisieren.
Dazu habe ich die neueste Version 4.3.1-rc1 seriell geflashed wie unter https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Flashing-&-Compiling (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Flashing-&-Compiling) beschrieben für Version >= 4.0.0.
Der Controller macht dann auch sein WLAN auf mit dem ich mich verbinden kann aber das Problem bleibt bestehen. Beim Versuch auf http://192.168.4.1/webapp (http://192.168.4.1/webapp) zuzugreifen bleibt der Browser hängen. Ich habe es mit verschiedenen Browsern auf verschiedenen Geräten probiert.
http://192.168.4.1/info (http://192.168.4.1/info) funktioniert aber wie erwartet:
{"deviceid":"10677735","current_rom":"0","git_version":"4.3.1-rc1","git_date":"2019-11-30","webapp_version":"0.3.3-shojo7","sming":"4.0.0","event_num_clients":0,"uptime":60,"heap_free":24280,"rgbww":{"version":"0.9.0","queuesize":100},"connection":{"connected":false,"ssid":"","dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0","mac":"5ccf7fa2ede7"}}
Ausgabe auf der seriellen Schnittstelle:
sleep disable␊
mode : sta(5c:cf:7f:a2:ed:e7) + softAP(5e:cf:7f:a2:ed:e7)␊
add if0␊
add if1␊
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)␊
bcn 100␊
scandone␊
add 1␊
aid 1␊
station: 70:c9:4e:79:10:e9 join, AID = 1␊
Ich habe es noch mit anderen Versionen der Firmware probiert aber das Verhalten bleibt das selbe.
Woran kann das liegen?
siehst Du eine Meldung, dass das SPIFFS gemountet werden konnte?
Ich hab es bei älteren Controllern manchmal gesehen, dass das Flash aufgab, weil die Firmware bei jeder Helligkeitsänderung den Wert in's Flash schreibt.
Außerdem gibt es immer mal wieder Probleme mit Retransmissions, wenn das WLAN nicht ganz optimal ist.
Wir haben mal versucht, das zu debuggen, haben aber keine wirklich guten Daten bekommen.
pj
Nein, keine Meldung zu spiffs, nur das was ich oben geschrieben habe.
Ich weiß aber auch nicht, ob die vbs Version der Firmware dazu Meldungen ausgibt.
Welche Version meldet denn sicher, ob spiffs gemountet wurde?
Der Controller hat recht viele Farbwechsel gemacht. Wäre schade, wenn dadurch die Hardware kaputt gegangen wäre.
Zitat von: kaihs am 02 März 2020, 12:05:50
Nein, keine Meldung zu spiffs, nur das was ich oben geschrieben habe.
Ich weiß aber auch nicht, ob die vbs Version der Firmware dazu Meldungen ausgibt.
Welche Version meldet denn sicher, ob spiffs gemountet wurde?
eigentlich alle. Denk ich. Müsste ich aber selbst mal nachsehen.
Zitat von: kaihs am 02 März 2020, 12:05:50
Der Controller hat recht viele Farbwechsel gemacht. Wäre schade, wenn dadurch die Hardware kaputt gegangen wäre.
im schlimmsten Fall tauschst Du den ESP aus und flashst den halt neu.
In meinem Fall hat es mal vorübergehend geholfen, das Flash mit "erase_flash" (als Kommando für esptool.py) komplett zu löschen. Bei Controllern, die viele Farbwechsel machen, kann es sinnvoll sein, eine fixe "config-color-startup_color" zu setzen, dann wird nicht nach jedem Farbwechsel das Flash beschrieben.
Grüße
pj
Probier mal bitte direkt eine URL wie z.B. abzurufen:
http://<ip>/app.min.css
Bei einer anderen sollte 404 kommen, z.B.:
http://<ip>/foobar.min.css
Guten Abend,
irgendwas mache ich falsch. Ich habe heute seit langem einen Controller in Betrieb genommen, aber seitdem startet mein FHEM Docker Container ständig neu.
Das ist der Auszug aus Portainer zum Zeitpunkt des Neustartens:
2020.03.20 22:19:38.204 5: WZ_LED_Wohnwand (Set) called with ?, busy flag is 0
name is WZ_LED_Wohnwand, args
2020.03.20 22:19:41.001 4: WZ_LED_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 55 s ago
2020.03.20 22:19:46.175 5: WZ_LED_Wohnwand: EspLedController_ProcessRead
2020.03.20 22:19:46.175 5: WZ_LED_Wohnwand: No PARTIAL buffer
2020.03.20 22:19:46.176 5: WZ_LED_Wohnwand: EspLedController_ProcessRead: Incoming data: {"jsonrpc":"2.0","method":"keep_alive","id":46}
2020.03.20 22:19:46.176 5: WZ_LED_Wohnwand: EspLedController_ProcessRead: Current processing buffer (PARTIAL + incoming data): {"jsonrpc":"2.0","method":"keep_alive","id":46}
2020.03.20 22:19:46.176 5: WZ_LED_Wohnwand: EspLedController_ProcessRead: Decoding JSON message. Length: 47 Content: {"jsonrpc":"2.0","method":"keep_alive","id":46}
2020.03.20 22:19:46.176 4: WZ_LED_Wohnwand: EspLedController_Read: keep_alive received
2020.03.20 22:19:46.176 5: WZ_LED_Wohnwand: EspLedController_ProcessRead: Tail:
2020.03.20 22:19:46.176 5: WZ_LED_Wohnwand: EspLedController_ProcessRead: PARTIAL:
2020.03.20 22:19:51.029 4: WZ_LED_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 5 s ago
2020.03.20 22:19:51.097 1: 192.168.2.49:8080 reappeared (WZ_KODI)
2020.03.20 22:20:01.204 4: WZ_LED_Wohnwand: EspLedController_CheckConnection: Connection still alive. Last data received 15 s ago
2020.03.20 22:20:01.854 5: WZ_LED_Wohnwand (Set) called with ?, busy flag is 0
name is WZ_LED_Wohnwand, args
2020.03.20 22:20:01.861 5: WZ_LED_Wohnwand (Set) called with ?, busy flag is 0
name is WZ_LED_Wohnwand, args
2020.03.20 22:20:03.356 5: WZ_LED_Wohnwand (Set) called with ?, busy flag is 0
name is WZ_LED_Wohnwand, args
2020.03.20 22:20:03.361 5: WZ_LED_Wohnwand (Set) called with ?, busy flag is 0
name is WZ_LED_Wohnwand, args
Undefined subroutine &main::EspLedController_IsDisabled called at ./FHEM/32_EspLedController.pm line 713.
/entry.sh: line 621: kill: (17891) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (17891) - No such process
Meine FVERSION: 32_EspLedController.pm:?/2020-02-07
Meine Controller Version:
Firmware 4.3.1-rc1
Web Interface 0.3.3-shojo7
RGBWW Version 0.9.0
SMING Version 4.0.0
Was mache ich falsch? Kann mir jemand helfen?
Danke!
Beste Grüße
Andy
Zitat von: Andy89 am 20 März 2020, 22:25:34
Meine FVERSION: 32_EspLedController.pm:?/2020-02-07
Ich denke, das ist das in der letzten Version behoben. Die ist jedoch vom 30.11.2019. Also vom 2020-02-07 gibt's eigenlich nix. Solltest du mal downgraden ;)
Zitat von: vbs am 20 März 2020, 22:41:40
Ich denke, das ist das in der letzten Version behoben. Die ist jedoch vom 30.11.2019. Also vom 2020-02-07 gibt's eigenlich nix. Solltest du mal downgraden ;)
danke! was auch immer da passiert ist.... der Fehler ist auf jeden behoben.
Danke dir!
Schönes Wochenende :)
Zitat von: vbs am 20 März 2020, 22:41:40
Ich denke, das ist das in der letzten Version behoben. Die ist jedoch vom 30.11.2019. Also vom 2020-02-07 gibt's eigenlich nix. Solltest du mal downgraden ;)
Hallo,
nochmal ich. also das Datum, was im Device angezeigt wird, ist scheinbar das Datum, wann ich den Docker Container das letzte Mal gestartet habe.
Leider ist der Fehler immer noch vorhanden.
Undefined subroutine &main::EspLedController_IsDisabled called at ./FHEM/32_EspLedController.pm line 713.Wenn ich mir Zeile 713 anschaue, steht da folgendes drin:
if (EspLedController_IsDisabled($hash)) {Wie der Fehler schon sagt, ist "EspLedController_IsDisabled" nirgends definiert und das finde ich auch im Code tatsächlich nicht.
Ist das die aktuelle Version?
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/blob/master/FHEM/32_EspLedController.pmVielen Dank und bleibt gesund!
Beste Grüße
Andy
edit: wenn ich EspLedController_IsDisabled durch die FHEM Abfrage IsDisabled austausche, funktioniert das disabled wie es gewollt ist. ist da evtl. der Fehler? Falls nein lösche ich nachher diesen Satz, um niemanden zu verwirren.
Ja, im Prinzip richtig. Die aktuelle Version war/ist eigentlich die hier (develop Branch):
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/develop/FHEM/32_EspLedController.pm
Hab den master jetzt aber auch dahin gesetzt. Ist sowieso gut... Danke für den Hinweis.
danke. Dann wechsel ich demnächst mal auf den Develop Pfad.
Mein Fhem stürtz nun nicht mehr ab :)
Danke!
Ok, das ist gut. Aber master sollte jetzt der gleiche Stand sein.
brauche hilfe beim erstellen von farbanimationen
folgendes soll geschehen: von schwarz(aus) ein 3sek. fade auf rot - das soll 10min. stehen - dann 3sek. auf blau - soll auch 10min. stehen - 3sek. fade auf grün -
das soll ebenfalls 10min. stehen - 3sek.fade auf rot und das in schleife
bei meinen versuchen (zum testen mit verkürzten zeiten) laufen die fades kontinuierlich durch, die farben bleiben nicht stehen, und dann laufen die fades immer das komplette spektrum durch, ich hätte aber gern den direkten wechsel (wie wenn ich an einem analogen lichtmischer die regler bediene)
ich hoffe ich konnte mich verständlich ausdrücken
also ich bin nicht so der programmierprofi, aber ich bemühe mich, nur habe ich dazu leider nichts finden können
aber ich habs wenigstens geschafft, das ganze mit quick-fhem vom handy zu steuern, nur fehlen mir dazu noch diese animationen
So geht eine Animation, die den Hue Kanal verändert mit einer Ramp von 5 Sek. Dann 5 Sek. hält (+0) und dann nochmal weiter fadet:
set wz_lightLedTv hue +70 5 q;set wz_lightLedTv hue +0 5 q;set wz_lightLedTv hue +70 5 qZitat von: tomm am 29 März 2020, 22:17:02
und dann laufen die fades immer das komplette spektrum durch, ich hätte aber gern den direkten wechsel (wie wenn ich an einem analogen lichtmischer die regler bediene)
Bin mir hier nicht sicher, was du meinst. Generell ist es so, dass es gemäß Farbkreis nicht immer eine direkte Verbindung gibt (z.b. Orange zu Blaue geht nur über Rot oder Grün):
https://de.wikipedia.org/wiki/HSV-Farbraum
Schreib doch sonst mal genau, was du gemacht hast.
danke für die schnelle antwort, das mit dem + hab ich nicht gewusst bzw.gefunden
set CT03 hue 1 10 q; set CT03 hue 120 10 q; usw. oder
set CT03 hsv ... das sind die Sachen, die ich probiert habe,
mit diesen direkten farbwechseln bin ich von den ws2812 uä., gesteuert mit nem arduino verwöhnt, ich weiß, das ist was anderes
wäre es zb. machbar, die farbe nach der standzeit mit der helligkeit auf 0 zu fahren(in max. 1-2sek.) und dann das gleiche von 0 zu 100 helligkeit mit der
nächsten farbe usw.? um das durchfahren des spektrums zu vermeiden!?
es soll eine nachtbeleuchtung werden, die so von 22 bis 4uhr läuft, eben mit längeren standzeiten und kurzen wechseln
hab das ganze erst mit nem alten w7 rechner angefangen, hat bis hierher dann auch funktioniert, bin gestern auf einen raspi3 umgestiegen, hat auch bis
hierher gut geklappt und nun häng ich an diesem problem, das nur kurz zu meinem werdegang mit den controllern. hatte das forum um fhem durch zufall zum zeitpunkt der sammelbestellung letztes jahr gefunden und mich eingeklinkt.
Zitat von: tomm am 29 März 2020, 23:46:25
danke für die schnelle antwort, das mit dem + hab ich nicht gewusst bzw.gefunden
set CT03 hue 1 10 q; set CT03 hue 120 10 q; usw. oder
set CT03 hsv ... das sind die Sachen, die ich probiert habe,
mit diesen direkten farbwechseln bin ich von den ws2812 uä., gesteuert mit nem arduino verwöhnt, ich weiß, das ist was anderes
Na, ich hoffe mal, das kriegen wir hiermit auch hin ;) Was du halt machen kannst, ist den RAW Modus zu verwenden. Da hast du volle Kontrolle über die einzelnen Farbkanäle. Du kannst dann aber eben nicht die Vorteile von der HSV-Farbmischung nutzen, sondern musst dir die Farben selbst mischen. Z.B.
set wz_lightLedTv raw 1023,0,0,0,0 5 q(setzt den Rot-Kanal auf 100% und den Rest auf "aus")
RAW ist aber ein ganz eigener, getrennter Zustand im Controller (ggü. HSV). Bei nächsten HSV-Befehl wird automatisch auf HSV zurück geschaltet.
Zitat von: tomm am 29 März 2020, 23:46:25
wäre es zb. machbar, die farbe nach der standzeit mit der helligkeit auf 0 zu fahren(in max. 1-2sek.) und dann das gleiche von 0 zu 100 helligkeit mit der
nächsten farbe usw.? um das durchfahren des spektrums zu vermeiden!?
Klar, kannst du dir so bauen. Alternativ würde es reichen nur die Sättigung für die Zeit des Farbverlaufs runter zu drehen.
Guten Morgen,
nach dem update von DevIO gestern startet mein FHEM nicht mehr. Im Portainer und Log findet sich folgende Zeile:
Can't use string ("EspLedController_OnConnect") as a subroutine ref while "strict refs" in use at ./FHEM/DevIo.pm line 237.
Danach stürzt FHEM ab und bootet neu - und das in Schleife.
Ich habe habe nun das update zurückgespielt und die Daten aus dem restore Ordner wieder eingebunden. Dann läuft zumindest mein FHEM wieder.
Ich bin mir jetzt nicht sicher, ob dass das Modul "Schuld" ist oder vielleicht doch das DevIO Modul.
Kannst du mehr dazu sagen?
Vielen Dank!
Beste Grüße
Andy
So wie ich es momentan verstehe, war das ein ungewollter Nebeneffekt seitens DevIo. Wenn du jetzt nochmal FHEM updatest, sollte es eigentl. schon wieder laufen?
ok - was auch immer schief lief, aber ja nun geht es!
Danke!
Gibt es eigentlich ein paar Beispiel Animationen irgendwo, an denen man zum Starten ein bischen rum frickeln kann?
Bzw. ein Thread in den User Ihre Animationen einstellen können, so daß man die per Copy Paste ausprobieren kann?
Viele Grüße
In der Doku, die auf der ersten Seite verlinkt ist, sind auch ein paar Beispiele drin:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#function-demonstrations
Hi,
ich habe den esp_rgbww_controller mal mit der WLED Firmware bestückt:
https://github.com/Aircoookie/WLED/pull/954
Ggf. ist das ja für den einen anderen interessant.
Funktionieren da alle Kanäle und Funktionen? Oder gibt es da Einschränkungen?
Gesendet von meinem SM-G960F mit Tapatalk
Ich hab nen rgbw dran, Farbe und Helligkeit für rgb und n regler für weiß funktioniert. Einige Effekte kommen auch ganz cool.
Ok cool muss ich mal testen. Wie installierst das? Wled aktuelle Version compolieren und dann ne config oder wie stelle ich mir das da vor?
Gesendet von meinem SM-G960F mit Tapatalk
Du kannst entweder selbst (mit pio) bauen oder einfach das bin file von mir zb mit esoptool.py flashen.
Oh sorry sie bin hatte ich übersehen. Danke dir
Gesendet von meinem SM-G960F mit Tapatalk
wollte die bin gerade flashen aber der flasht bei mir nicht.
Finde auch nirgends das Pinlayout für die 6 Pins.
Habe VCC manuell am ESP, Ground habe ich neben G0 und G0 auch an Masse. RX TX gedreht angeschlossen. esptool.py arbeitet und der esp blinkt auch im takt zu den connecting versuchen aber er connected nicht.
Was übersehe ich da gerade :o
Edit: auch ein zweiter blinkt nur weiß aber nicht wieso :-\
Edit 2: Direkt am ESP geflashed und da ging es direkt... strange!
Edit 3: Habe WLED nun eingerichtet. Etwas schwierig zu konfigurieren finde ich aber es funktioniert. Nur noch eine Frage ich kann in den Configs nur 4 Led auswählen der Controller supportet aber 5led. Eine Idee?
Der Controller wird wie üblich an iwas über ca 5V angeschlossen. Der ftdi (oder halt jeder beliebige USB uart) wird an den OBEREN 3 pins der 3x2 pim Header angeschlossen. Rechts ist gnd. Links und Mitte ist tx/rx (oder anders rum, weiß ich gerade nicht). Rx und tx müssen ggü usb uart gedreht sein. Dann hält man prog (mittleren Taster) gedrückt und gleichzeitig kurz auf reset. Prog noch ein paar Sekunden halten, dann ist der esp im Flash mode und esoptool.py kann loslegen. Dann wieder reset und es sollte ein WLED AP erscheinen. Passwort war glaube ich wled1234
Guten Morgen, muss nochmal fragen.
5 Kanal kann ich nirgends konfigurieren und steuern. Eine Idee?
Kannst du das ganze per App oder wie in meinem fall json api steuern? RGB geht aber sobald weiß separat gesteuert werden soll fängt es an zu spinnen. Einzig über das Webinterface kann ich es steuern wie ich es möchte.
Ich hatte bislang nur RGBW kurz ausprobiert und das ging per MQTT und WebUI soweit wie erwartet.
Zitat von: kmxak am 30 Mai 2020, 10:03:20
Guten Morgen, muss nochmal fragen.
5 Kanal kann ich nirgends konfigurieren und steuern. Eine Idee?
Kannst du das ganze per App oder wie in meinem fall json api steuern? RGB geht aber sobald weiß separat gesteuert werden soll fängt es an zu spinnen. Einzig über das Webinterface kann ich es steuern wie ich es möchte.
Darüber hatten wir es vor 2 Wochen:
https://forum.fhem.de/index.php?topic=101240.msg1054100.msg#1054100
Kurz, Einzelkanalsteuerung über Dummys, ein DOIF und einen kleinen MyUtils Code.
Der MyUtils Code könnte auch ins DOIF und anstatt des DOIF könnnte man auch ein Notify nehmen.
Gesendet von meinem S68Pro mit Tapatalk
Hi PSI,
das mit WLED interessiert mich da ich es sonst überall im Haus verwende.
Ich würde das gern mal probieren.
Habe mir deinen link angesehen.
Kannst du mir kurz erklären was ich dazu machen muss?
Muss ich irgendetwas anpassen wenn ich den WLED Master nehme?
Gruß und Danke,
Stefan
Du kannst natürlich die Firmware selbst bauen, dazu habe ich in dem pio env folgende build_flags mit angegeben:
-D WLED_USE_ANALOG_LEDS
-D WLED_USE_PLJAKOBS_PCB
-D WLED_USE_5CH_LEDS
Ansonsten hab ich mal versucht den JSON-Branch zu mergen da ich kein XML-Fan bin. FW häng ich diesem Post an.
Ok danke, werd ich mal probieren.
Gruß,
Stefan
hat den controller schon mal einer mit tasmota zu laufen bekommen?
Led's leuchten aber steuerbar ist was anderes. :o
Moin,
na klar, läuft ohne Probleme mit folgendem Tasmota-Template:
{"NAME":"RGBWW","GPIO":[0,255,255,255,40,41,0,0,38,37,39,255,17],"FLAG":0,"BASE":34}
mh vielleicht hat mein controller auch einfach eine macke. ich kann den ersten kanal rot nicht regeln der ist dauhaft an.
Edit: Ok der 2. geht mit der Vorlage. Dann scheint der erste einen knick weg zu haben. Kein Wunder das es nicht geht ;D
Mal aus reinem Interesse: warum ziehst du Tasmota dieser Firmware hier vor?
Hardware und Software sind doch bestens auf einander abgestimmt und noch dazu funktioniert das Dimmen/Faden wesentlich besser.
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 06 Juni 2020, 09:43:54
Mal aus reinem Interesse: warum ziehst du Tasmota dieser Firmware hier vor?
Hardware und Software sind doch bestens auf einander abgestimmt und noch dazu funktioniert das Dimmen/Faden wesentlich besser.
Gesendet von iPhone mit Tapatalk
Vielleicht Einzelkanalsteuerung?
Gesendet von meinem S68Pro mit Tapatalk
Zitat von: Frank_Huber am 06 Juni 2020, 10:14:06
Vielleicht Einzelkanalsteuerung?
Gesendet von meinem S68Pro mit Tapatalk
Geht das nicht auch über den RAW-Modus?
Gesendet von iPhone mit Tapatalk
Zitat von: balli1187 am 06 Juni 2020, 10:15:41
Geht das nicht auch über den RAW-Modus?
Gesendet von iPhone mit Tapatalk
Im RAW musst immer alle Kanäle mitgeben.
Das geht indirekt mit Dummys und bißchen Code.
Vielleicht kann das die Tasmota direkt.
Kenn die nicht. Hab Mqtt noch nie wirklich genutzt.
Gesendet von meinem S68Pro mit Tapatalk
moin, bin schon länger auf der suche nach eine alternativen firmware. Ich nutze FHEM aktuell nur noch für 2 RGBWW Controller da macht das leider wenig sinn.
Weiß einer ob sich die Pinbelegung zwischen den Hardware Versionen mal geändert hatte?
Zitat von: kmxak am 06 Juni 2020, 10:48:38
moin, bin schon länger auf der suche nach eine alternativen firmware. Ich nutze FHEM aktuell nur noch für 2 RGBWW Controller da macht das leider wenig sinn.
Weiß einer ob sich die Pinbelegung zwischen den Hardware Versionen mal geändert hatte?
nein, das Pinout ist immer gleich geblieben. Die Firmware ist ja auch über alle Versionen hinweg kompatibel.
Du kannst natürlich Tasmota verwenden, aber da sind die Fades bei weitem nicht so angenehm, und auch die Farbberechnung ist schlechter, dafür kannst Du leichter alle fünf Kanäle unabhängig voneinander nutzen.
Aber: Da die Firmware ja neben json/http auch json/mqtt spricht: was spricht dagegen, die Controller so in andere Systeme wie z.B. Home Assistant einzubinden?
pj
Bin da leider nicht so im Thema. Mqtt war doch in erster Linie für das sync zwischen mehreren Devices gedacht oder nicht? Nutze iobroker. Über den fhem Adapter funktioniert das auch super. Mit json müsste ich mir was basteln und da hört es dann bei mir auf, da kenne ich mich nicht genug mit aus.
Nach meiner Vorstellung sind in der FW alle Kanäle im Raw-Modus einzeln steuerbar. Fehlt da etwas?
Zitat von: vbs am 26 Juni 2020, 10:58:03
Nach meiner Vorstellung sind in der FW alle Kanäle im Raw-Modus einzeln steuerbar. Fehlt da etwas?
zumindest über FHEM muss man aber immer alle Kanäle angeben was es etwas schwierig mit der Einzelkanalsteuerung macht.
Nee nee, du kannst Kanäle im Kommando einfach leer lassen:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#color-commands
Also für ein Raw-Kommando:
set myLed raw ,,345,,
Setz zB nur den dritten Kanal.
Zitat von: vbs am 26 Juni 2020, 11:10:24
Nee nee, du kannst Kanäle im Kommando einfach leer lassen:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#color-commands
Also für ein Raw-Kommando:
set myLed raw ,,345,,
Setz zB nur den dritten Kanal.
:o :o :o :o :o :o :o :o
seit wann das?
Das ging völlig an mir vorbei.
Also in der Firmware-Variante hier so ziemlich schon immer, ehrlich gesagt. Das war ja so mit *die* Hauptmotivation für die gemoddete FW, die Kanäle unabhängig zu machen.
Hallo zusammen,
ich habe an meinen Controller einen CCCW Strip angeschlossen und bin mir nicht sicher, ob das so richtig Funktioniert?
Das läuft auf dem Controller:
Firmware
vbs35
Web Interface
0.3.3-shojo7
RGBWW Version
0.8.1-vbs5
SMING Version
3.5.1
Ich habe den Strip als RGBWWCW definiert.
Wenn ich die Farbtemperatur 2700k, oder 6000k einstelle leuchtet der Strip am hellsten. Wenn ich allerdings auf 4000k einstelle werden die Farben gemischt und der Strip dimmt sich deutlich runter.
Warum kann er nicht bei voller Leistung dimmen?
Ich denke, das Problem ist, dass die Helligkeitskurven der LEDs nicht linear sind bzw. sich nicht linear addieren. Sprich: eine LED (CW oder WW) auf 100% wirkt heller als CW und WW beide jeweils auf 50%. Könnte man wahrscheinlich mit geeigneten Kennlinien entgegenwirken.
Ok, verstehe und wie genau kann ich dem entgegen wirken. Es kommen bei jedem Kanal dann auch keine 24V mehr an, wenn ich mische.
Andere Frage noch:
Meine Stripes können 2800-7000k kann ich das von den 2700-6000 auf 2800-7000K umstellen?
Beide Kanäle voll aussteuern kannst du nur im Raw-Modus. Da hast du volle Kontrolle über die Kanäle. Entgegenwirken meinte ich, mit einer rein theoretischen Firmwareänderung :)
Temperatur kannst du mit config-color-colortemp-cw und config-color-colortemp-ww konfigurieren.
Ok, gibt es eine Beschreibung für dir RAW-Befehle, oder wie läuft das mit dem Modus?
Die Temperatur habe ich wie folgt geändert
set LED_Kueche config config-color-colortemp-cw 7000
Hat er auch zuerst übernommen, aber ansteuern konnte ich das nicht. Nur 6000k.
Nach einem Neustart ist der Wert auch wieder auf 6000k
Zitat von: holzwurm83 am 15 Juli 2020, 18:47:50
Ok, gibt es eine Beschreibung für dir RAW-Befehle, oder wie läuft das mit dem Modus?
Einfach wie bei hue kommagetrennt fünf Werte von 0-1023.
Zitat von: holzwurm83 am 15 Juli 2020, 18:47:50
Die Temperatur habe ich wie folgt geändert
set LED_Kueche config config-color-colortemp-cw 7000
Hat er auch zuerst übernommen, aber ansteuern konnte ich das nicht. Nur 6000k.
Nach einem Neustart ist der Wert auch wieder auf 6000k
Prinzipiell richtig, aber ich hab gesehen, dass das mindestens Version 4.0.0-rc4 benötigt.
Zitat von: vbs am 15 Juli 2020, 19:02:29
Prinzipiell richtig, aber ich hab gesehen, dass das mindestens Version 4.0.0-rc4 benötigt.
Ich dachte ich hätte schon die aktuellste Firmware drauf. Ich kann auch keine andere Laden.
Muss ich dann die Adresse änder und wenn ja auf was?
http://rgbww.dronezone.de/release/version.json
kurze Frage, was hat es denn mit den Schiebereglern in den Farbeinstellungen auf sich?
Werte von -30 bis 30 können eingestellt werden.
Das ist die Farbkalibration. Sollte normalerweise alles bei 0 stehen. Du kannst da halt händisch Offsets für bestimmte Kanäle definieren.
Ah, ok. Quasi das gleiche wie drunter die rgbww Werte, nur für die Berechnung.
Solange alle gleich sind ists egal, aber man kann mit plus minus die farbmischung anpassen. Verstanden.
Danke! 👍🏻
Hat sich noch jemand anderes schon mal an dem Problem gestört, dass sich die Helligkeit verändern kann, wenn man die Farbtemperatur verändern bei Nutzung von CWWW-Stripes?
https://forum.fhem.de/index.php/topic,70738.msg1071984.html#msg1071984
Nö, Kaltweis ist gefühlt ja eh heller. von daher ist das Jacke wie Hose. :-)
Wenn ich die Temp ändere und es zu hell oder dunkel ist regle ich nach.
@vbs ...
Hallo vbs,
ich habe heute mit einem User des Moduls MSwitch und dieses Moduls ein Problem zu lösen.
kurzer hintergrund:
es geht darum eine Liste von Befehlen an dein Modul per button o.Ä. durchzuschalten.
bei diesem durchschalten soll der gegenwärtige status etc. pp. berücksichtigt werden.
Aus diversen Gründen kann er die Befehle nur per raw senden.
Das ist mit MSwitch sehr komfortabel machbar, würde aber ein reading im device benötigen , das den letzten erhaltenen rawbefehl enthält. ( siehe anhang ).
Wäre es evtl. möglich , das in dein Modul entsprechend einzubauen ( ist ja im grunde ein einzeiler )?
... es wäre schade , wenn er daher ein modifiziertes Modul nutzen müsste.
Zum testen habe ich nur mal auf die schnelle folgende Zeile ( ab zeile 512 ) eingebaut :
elsif ( $cmd eq 'raw' ) {
my ( $red, $green, $blue, $ww, $cw ) = split ',', $args[0];
$red = undef if ( length($red) == 0 );
$green = undef if ( length($green) == 0 );
$blue = undef if ( length($blue) == 0 );
$ww = undef if ( length($ww) == 0 );
$cw = undef if ( length($cw) == 0 );
readingsSingleUpdate( $hash, "lastIncomingRaw", "$args[0]", 1 );
EspLedController_SetRAWColor( $hash, $red, $green, $blue, $ww, $cw, $colorTemp, $fadeTime, $transitionType, $doQueue, $direction, $doRequeue, $fadeName );
}
eine kurze rückmeldung wäre super.
danke und gruss
thomas
edit: alternativ könnte das benötigte reading ggf. auch über ein userreading gebaut werden ... ein standartreading wäre aber irgendwie einfacher.
Denke auch, dass das gut in ein UserReading passt.
Zitat von: vbs am 31 August 2020, 17:52:55
Denke auch, dass das gut in ein UserReading passt.
hab's mir fast gedacht, trotzdem danke.
gruss thomas
Hey,
Ich beschäftige mich zur Zeit etwas mit MQTT und wollte an dieser Stelle fragen, wie ich den Controller über MQTT an/aus/toggle schalten kann.
Über /home/led1/command {"jsonrpc":"2.0","method":"color","params":{"hsv":{"h":"0.00","s":0.00,"v":0,"ct":2700},"cmd":"fade","t":700}} beispielsweise, kann ich die Farbe ja einfach wechseln, aber wie verhält sich das bei toggle?
Beste Grüße
Fabian
Verschiedene Ideen, um sowas abzugreifen:
- den Verbose-Mode des Moduls aktivieren. Dann siehst du die JSON-Nachrichten, die das Modul per HTTP an den Controller schickt. Die gleichen Nachrichten kannst du auch per MQTT versenden.
- du aktivierst im Controller den cmdMaster-Modus. Dann schickt der Controller alle Befehle, die er erhält, per MQTT weiter. Wenn du dann per FHEM ein toggle auslöst, wird er z.B. das toggle per MQTT schicken und du kannst es sehen (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Device-Synchronization#command-synchronization)
Hallo Zusammen,
ich benutzt die Controller noch mit dem fhem led controller Modul, würde gerne aber auf MQTT umsteigen. Es gibt ja zahlreiche shelly mqtt templates.
Hat jemand eins für den esp controller?
Gruß und Danke.
Hallo, irgendwie hab ich Probleme auf die neuste FW, die im Git beschrieben ist heben. Ich hänge immer noch auf einer Version 0.3.1. Müsste es nicht lt. GIT die 4.3.1-rc1 sein ?
Auszug Logfile beim Update
2020.12.03 20:39:13 1: Downloading https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
2020.12.03 20:39:13 1: nothing to do...
2020.12.03 20:42:06 3: RGBWohnzimmer: Updating firmware now. Current firmware: vbs35 New firmare: 0.3.1-vbs35
2020.12.03 20:42:07 3: RGBWohnzimmer: EspLedController_ParseFwUpdateProgress. status: 1
...
2020.12.03 20:42:19 3: RGBWohnzimmer: EspLedController_ParseFwUpdateProgress. status: 2
2020.12.03 20:42:19 3: RGBWohnzimmer: EspLedController_ParseFwUpdateProgress - Update successful - Restarting device...
Meine 32_EspLedController.pm ist aktuell.
Als OTA Url ist "https://rgbww.dronezone.de/release/version.json" eingetragen.
info-firmware vbs35 2020-12-03 20:43:34
info-heap_free 22256 2020-12-03 20:43:34
info-sming_version 3.5.1 2020-12-03 20:43:34
info-uptime 60 2020-12-03 20:43:34
info-webapp_version 0.3.3-shojo7
Hab ich vielleicht irgendwas in den 85 Thread-Seiten überlesen ?
Oder funktioniert das OTA hier nicht korrekt und ich muss direkt Flashen ?
Falls jemand helfen kann schon mal vielen Dank vorab.
Guck mal im ersten Post direkt unter "Firmware". Da ist die URL für die testing-Variante angegeben.
Danke, das war's. Tomaten auf den Augen gehabt, bzw. wahrscheinlich nicht angenommen, dass 3 Jahre nach dem Post das noch immer im Test ist.
Und da man nie genug loben kann: Gute Arbeit von Dir und natürlich vielen Dank an die anderen, die das Projekt ständig erweitern.
cu
Vielleicht kann jemand helfen - ich war langezeit nicht mehr an meiner EspLedController Installation dran, heute waren aber auf einmal die Farben verstellt und ich merkte, dass die WebApp nicht mehr zugänglich ist. Ich kann über FHEM noch Parameter ändern, ich komme auch an das System mit den Parametern $URL/config? etc., aber eben nicht an die Webapp.
GET /webapp HTTP/1.1
Host: 172.23.21.195
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de-DE,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
HTTP/1.1 404 Not Found
Content-Length: 0
Connection: keep-alive
Server: HttpServer/Sming
Ist ggf. die Partition / SPIFFS mit den Webseiten beschädigt?
Ich brauche das Webinterface im Endeffekt gar nicht - ich will nur ein kaltweiß mit dim auf 23 einstellen - dafür bin ich aber scheinbar zu blöd, oder es stimmt etwas nicht.
Welche Einstellungen müsste ich hsv seitig einsetzen?
Ich würde nur ungerne wieder neu flashen :)
Ach - mach doch mal. Einmal neu flashen sollte helfen 8)
set led fw_update 1
Danke.
Das habe ich gestern schon gemacht / machen (normal und testing) wollen. Mit flashen meinte ich esptool ;-)
set TYPE=EspLedController config config-ota-url http://rgbww.dronezone.de/release/version.json
Im Log erscheint nun leider folgendes:
2021.01.06 08:25:41 3: mqtt.light.espled: Updating firmware now. Current firmware: vbs35 New firmare: 0.3.1-vbs35
2021.01.06 08:25:42 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:43 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:44 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:45 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:46 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:47 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:48 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:49 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:50 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:51 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:52 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
2021.01.06 08:25:53 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 1
durchgehend.
Nach einer Zeit kommt dann:
mqtt.light.espled: EspLedController_ParseFwUpdateProgress error: http://172.23.21.195/update?: empty answer received
und es befindet sich in einer Schleife.
Kannst sonst noch mal die testing-FW ausprobieren.
Wenn das weiterhin besteht, dann bitte mal ein komplettes Log und Devicelisting.
Das "empty answer" hat möglicherweise mit schlechtem WLAN-Empfang zu tun.
Habe testing gesetzt.
Pakete gehen raus:
> 185.199.111.153.80: Flags [P.], seq 1:172, ack 1, win 229, options [nop,nop,TS val 259913825 ecr 880356342], length 171: HTTP: GET /testing/version.json HTTP/1.0
0x0000: 4500 00df 0021 4000 3f06 12a3 5de2 a112 E....!@.?...]...
0x0010: b9c7 6f99 9b34 0050 1d96 f7c2 9a44 6274 ..o..4.P.....Dbt
0x0020: 8018 00e5 d6d7 0000 0101 080a 0f7d f861 .............}.a
0x0030: 3479 2bf6 4745 5420 2f74 6573 7469 6e67 4y+.GET./testing
0x0040: 2f76 6572 7369 6f6e 2e6a 736f 6e20 4854 /version.json.HT
0x0050: 5450 2f31 2e30 0d0a 486f 7374 3a20 7267 TP/1.0..Host:.rg
0x0060: 6277 772e 6472 6f6e 657a 6f6e 652e 6465 bww.dronezone.de
0x0070: 0d0a 4163 6365 7074 2d45 6e63 6f64 696e ..Accept-Encodin
0x0080: 673a 2067 7a69 702c 6465 666c 6174 650d g:.gzip,deflate.
0x0090: 0a55 7365 722d 4167 656e 743a 2066 6865 .User-Agent:.fhe
0x00a0: 6d0d 0a41 6363 6570 743a 2061 7070 6c69 m..Accept:.appli
0x00b0: 6361 7469 6f6e 2f6a 736f 6e0d 0a43 6f6e cation/json..Con
0x00c0: 7465 6e74 2d54 7970 653a 2061 7070 6c69 tent-Type:.appli
0x00d0: 6361 7469 6f6e 2f6a 736f 6e0d 0a0d 0a cation/json....
Im Log:
2021.01.06 12:14:11 3: mqtt.light.espled: Updating firmware now. Current firmware: vbs35 New firmare: 4.3.1-rc1
2021.01.06 12:14:13 2: mqtt.light.espled: EspLedController_ParseBoolResult error: http://172.23.21.195/update?: empty answer received
2021.01.06 12:14:13 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 4
2021.01.06 12:14:13 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress - Update failed!
Das WLAN Signal ist aber in Ordnung.
Hier das list
Internals:
DEF 172.23.21.195
DeviceName 172.23.21.195:9090
FD 97
IP 172.23.21.195
LAST_RECV 1609932746.26542
NAME mqtt.light.espled
NR 234
NTFY_ORDER 50-mqtt.light.espled
PARTIAL
PORT 9090
STATE opened
STILLDONETIME 0
TYPE EspLedController
OLDREADINGS:
READINGS:
2021-01-05 23:45:01 colorMode hsv
2021-01-06 12:13:45 config-color-brightness-blue 100
2021-01-06 12:13:45 config-color-brightness-cw 100
2021-01-06 12:13:45 config-color-brightness-green 100
2021-01-06 12:13:45 config-color-brightness-red 100
2021-01-06 12:13:45 config-color-brightness-ww 100
2021-01-06 12:13:45 config-color-colortemp-cw 6000
2021-01-06 12:13:45 config-color-colortemp-ww 2700
2021-01-06 12:13:45 config-color-hsv-blue 0
2021-01-06 12:13:45 config-color-hsv-cyan 0
2021-01-06 12:13:45 config-color-hsv-green 0
2021-01-06 12:13:45 config-color-hsv-magenta 0
2021-01-06 12:13:45 config-color-hsv-model 0
2021-01-06 12:13:45 config-color-hsv-red 0
2021-01-06 12:13:45 config-color-hsv-yellow 0
2021-01-06 12:13:45 config-color-outputmode 0
2021-01-06 12:13:45 config-color-startup_color last
2021-01-06 12:13:45 config-events-color_interval_ms 500
2021-01-06 12:13:45 config-events-color_mininterval_ms 500
2021-01-06 12:13:45 config-events-server_enabled true
2021-01-06 12:13:45 config-events-transfin_interval_ms 1000
2021-01-06 12:13:45 config-general-device_name mqtt.light.espled
2021-01-06 12:13:45 config-general-pin_config 13,12,14,5,4
2021-01-06 12:13:45 config-network-ap-password
2021-01-06 12:13:45 config-network-ap-secured
2021-01-06 12:13:45 config-network-ap-ssid
2021-01-06 12:13:45 config-network-connection-dhcp true
2021-01-06 12:13:45 config-network-connection-gateway 0.0.0.0
2021-01-06 12:13:45 config-network-connection-ip 0.0.0.0
2021-01-06 12:13:45 config-network-connection-netmask 0.0.0.0
2021-01-06 12:13:45 config-network-mqtt-enabled false
2021-01-06 12:13:45 config-network-mqtt-password
2021-01-06 12:13:45 config-network-mqtt-port 1883
2021-01-06 12:13:45 config-network-mqtt-server mqtt.local
2021-01-06 12:13:45 config-network-mqtt-topic_base home/
2021-01-06 12:13:45 config-network-mqtt-username
2021-01-06 12:13:45 config-ota-url http://rgbww.dronezone.de/testing/version.json
2021-01-06 12:13:45 config-security-api_secured false
2021-01-06 12:13:45 config-sync-clock_master_enabled false
2021-01-06 12:13:45 config-sync-clock_master_interval 30
2021-01-06 12:13:45 config-sync-clock_slave_enabled false
2021-01-06 12:13:45 config-sync-clock_slave_topic home/led1/clock
2021-01-06 12:13:45 config-sync-cmd_master_enabled false
2021-01-06 12:13:45 config-sync-cmd_slave_enabled false
2021-01-06 12:13:45 config-sync-cmd_slave_topic home/led1/command
2021-01-06 12:13:45 config-sync-color_master_enabled false
2021-01-06 12:13:45 config-sync-color_master_interval_ms 0
2021-01-06 12:13:45 config-sync-color_slave_enabled false
2021-01-06 12:13:45 config-sync-color_slave_topic home/led1/color
2021-01-06 08:57:26 ct 2700
2021-01-06 08:57:26 hsv 221.99,46.04,0
2021-01-06 08:57:26 hue 221.99
2021-01-06 08:57:25 info-connection-dhcp true
2021-01-06 08:57:25 info-connection-gateway 172.23.21.254
2021-01-06 08:57:25 info-connection-ip_address 172.23.21.195
2021-01-06 08:57:25 info-connection-mac a020a605f743
2021-01-06 08:57:25 info-connection-netmask 255.255.255.0
2021-01-06 08:57:25 info-connection-ssid
2021-01-06 08:57:25 info-current_rom_slot 1
2021-01-06 08:57:25 info-deviceid 390979
2021-01-06 08:57:25 info-event_num_clients 1
2021-01-06 08:57:25 info-firmware vbs35
2021-01-06 08:57:25 info-heap_free 22408
2021-01-06 08:57:25 info-sming_version 3.5.1
2021-01-06 08:57:25 info-uptime 0
2021-01-06 08:57:25 info-webapp_version 0.3.3-shojo7
2021-01-06 12:14:13 lastFwUpdate Update failed!
2021-01-06 08:57:26 pct 0
2021-01-06 08:57:26 raw_blue 0
2021-01-06 08:57:26 raw_cw 0
2021-01-06 08:57:26 raw_green 0
2021-01-06 08:57:26 raw_red 0
2021-01-06 08:57:26 raw_ww 0
2021-01-06 08:57:26 rgb 000000
2021-01-06 08:57:26 sat 46.04
2021-01-06 08:57:24 state opened
2021-01-06 08:57:26 stateLight off
2021-01-06 08:57:26 val 0
helper:
fwUpdateForce 1
isBusy 0
oldVal 22.97
cmdQueue:
lastCall:
NAME
addr http://172.23.21.195:80
auth 0
buf
code 200
compress 1
conn
displayurl http://172.23.21.195/update?
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host 172.23.21.195
httpheader HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 12
Connection: keep-alive
Server: HttpServer/Sming
hu_blocking 0
hu_filecount 1
hu_port 80
hu_portSfx
loglevel 4
method GET
path /update?
protocol http
redirects 0
timeout 30
url http://172.23.21.195/update?
hash:
sslargs:
Attributes:
alias espled
devStateIcon {Color_devStateIcon(ReadingsVal($name,"rgb","000000"))}
group Stripes
icon light_light
room Licht
Was ist nicht verstehe ist, dass ich kein gewöhnliches weiß mehr einstellen kann (RGB, HSV) - sobald ich das mache kommt gar kein Licht. Rot, Blau, Grün funktioniert. Ich hatte das damals im Webinterface auch nur über einen anderen Modus umstellen können. Alles merkwürdig. Zur Not muss ich halt neu per esptool flashen.
edit: die Einstellung auf weißes Licht hat mittlerweile wieder gegriffen.
Hallo Zusammen,
ich probiere einen RGBWWCW-Streifen mit dem Controller so einzurichten, dass beim Einschalten (bei mir 230-V-PowerOn auf dem Netzteil und somit dem Controller) alle Kanäle volle Leistung bringen (also set BA.Licht raw 1023,1023,1023,1023,1023). Manuelles Einstellen geht, aber nach PowerOff / PowerOn ist wieder ein anderer Wert (und somit ein anderes Licht) eingestellt.
Daten:
config-color-startup_color = last
config-ota-url = http://rgbww.dronezone.de/testing/version.json
info-firmware = 4.3.1-rc1
info-sming_version = 4.0.0
info-webapp_version = 0.3.3-shojo7
lastFwUpdate = Update successful - Restarting device...
Version vom FHEM-Modul bringt :
No Id found for 32_EspLedController.pm
Zitat von: dmq am 06 Januar 2021, 12:16:19
2021.01.06 12:14:11 3: mqtt.light.espled: Updating firmware now. Current firmware: vbs35 New firmare: 4.3.1-rc1
2021.01.06 12:14:13 2: mqtt.light.espled: EspLedController_ParseBoolResult error: http://172.23.21.195/update?: empty answer received
2021.01.06 12:14:13 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress. status: 4
2021.01.06 12:14:13 3: mqtt.light.espled: EspLedController_ParseFwUpdateProgress - Update failed!
Hm ist komisch. Verhält sich aber anders als beim ersten Versuch (da hat er ja zunächst noch relativ lange geflasht). Ist das Verhalten jetzt stabil so, auch wenn du es mehrfach probierst? Möglicherweise klappt es nach ein paar Versuchen. Habe ansonsten keine sinnvolle Idee mehr. Zumindest keine, die weniger Arbeit macht als seriell neu zu flashen ^^
Zitat von: Thomas03 am 06 Januar 2021, 20:03:21
ich probiere einen RGBWWCW-Streifen mit dem Controller so einzurichten, dass beim Einschalten (bei mir 230-V-PowerOn auf dem Netzteil und somit dem Controller) alle Kanäle volle Leistung bringen (also set BA.Licht raw 1023,1023,1023,1023,1023). Manuelles Einstellen geht, aber nach PowerOff / PowerOn ist wieder ein anderer Wert (und somit ein anderes Licht) eingestellt.
Das "config-color-startup_color" funktioniert momentan nur im HSV-Farbraum. Ich vermute, dass du bei dir die zuletzt gesehene HSV-Farbe bekommst beim Booten.
Danke Dir - ich werde bei Zeiten (kommen bst. noch ein paar Geräte dazu) flashen :)
Eine Frage noch - ich setze im RAW Modus die Einstellung, die ich gerne setzen möchte mit:
set mqtt.light.espled raw 0,0,0,223,223
Also alle Farben aus und WarmWhite und ColdWhite gedimmt.
Das "config-color-startup_color" geht ja nur für den HSV Raum - wie bekomme ich obigen Wert dahin übersetzt? Ich würde mir nur ungern was basteln, dass ich ein set Kommando immer automatisch abschicke. Das geht doch bestimmt, oder?
Man kann nicht unbedingt jeden Raw-Zustand 1:1 auf HSV abbilden (jedoch HSV->Raw geht immer), aber in diesem Fall schon.
Wenn du in HSV irgendwelche Werte einstellst, dann siehst du ja in den Raw-Readings immer die aktuellen Raw-Werte. Intern werden halt die HSV-Werte dann auf Raw umgerechnet, aber es gibt da keinen mir bekannten rechnerischen Rückweg (wird sicherlich aber iwie möglich sein).
Also du müsstest so lange an den HSV-Werte drehen, bis du die gewünschten Raw-Werte siehst. Wichtig ist:
* Controller als CW/WW konfigurieren
* Sat auf 0
* Hue auf 0
* Farbtemperatur auf genau die Hälfte deines CW und WW setzen (willst ja bei beiden gleichverteilt 223)
* val so lange hochdrehen, bis du als Raw-Werte deine 223 siehst
Zitat
Controller als CW/WW konfigurieren
Komme ja leider nicht mehr auf das WebInterface. Geht das auch per FHEM?
Zitat
* Sat auf 0
* Hue auf 0
Ist gesetzt.
Zitat
* Sat auf 0
* Hue auf 0
Zitat
* Farbtemperatur auf genau die Hälfte deines CW und WW setzen (willst ja bei beiden gleichverteilt 223)
Also hier entsprechend 112 auf config-color-colortemp-ww und config-color-colortemp-cw?
Das funktioniert leider bei mir nicht. Vermutlich ist der Controller nicht im CW/WW Modus. Wenn ich unter den Werten config-color-brightness-blue|red|green nicht einen Wert über 0 angebe, geht gar nichts. Es sei denn ich gebe die raw Werte direkt an.
CWWW kannst du setzen mit:
set led config-color-outputmode 3Zitat von: dmq am 08 Januar 2021, 19:54:54
Also hier entsprechend 112 auf config-color-colortemp-ww und config-color-colortemp-cw?
Hm nee, die beiden Werte musst du ja auf die Farbtemperaturen deiner beiden LEDs setzen. Also die warmen vermtl. irgendwie um 2700 und die kalten um 6000?
Und dann die Farbtemperatur (ct) auf die Mitte davon. Wenn du dann ein reines Weiß einschaltest, wird dass 50/50 auf den CW- und den WW-Kanal verteilt.
Ok, das sieht besser aus ;)
Hallo VBS,
bist Du eigentlich schon mit der Belegung der ESP Eingänge weiter gekommen?
Wenn ich es richtig in Erinnerung habe, war u.a. angedacht diese als Tastereingänge zum direkten Ein/Ausschalten nutzbar zu machen.
Gibts da was neues?
Viele Grüße & vielen Dank
Guido
Hi Guido,
ja, ein bisschen was gibt es dazu. Beschreibung findest du hier:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Hardware-Push-Buttons
Hi vbs,
das ist klasse. vielen Dank für die Info. :)
Zitat von: vbs am 21 Juli 2020, 15:42:12
Hat sich noch jemand anderes schon mal an dem Problem gestört, dass sich die Helligkeit verändern kann, wenn man die Farbtemperatur verändern bei Nutzung von CWWW-Stripes?
https://forum.fhem.de/index.php/topic,70738.msg1071984.html#msg1071984
Hi, ich habe wir das nochmal angeschaut und ausprobiert. In Max ist das ein Verlust von 50% der Helligkeit. Der Sinn sollte ja allerdings sein die Helligkeit separat zu dimmen, was ja auch möglich ist.
Du hast auch geschrieben das man die Kanäle mit RAW-Befehlen direkt ansteuern kann. Die Befehle dazu habe ich nur nicht finden können. Kannst du mir dabei noch mal helfen.
Kann ich eigentlich bei CCCW Strips zwei Stück anschließen und diese getrennt voneinander steuern? Kanäle sind es ja genug. Ich habe mal irgendwo gelesen das es geplant war, aber wurde das auch umgesetzt?
Mit den Raw-Befehlen kannst du alle Kanäle völlig getrennt steuern. Mit allen Vor- und Nachteilen.
Ein Raw-Befehl geht z.B. so:
set myDevice raw 1023,0,0,0,0
Wertebereich 0 - 1023
Damit kannst du auch mehrerr Stripes an einen Controller anschließen und steuern.
Hallo,
ich plane 2 LED Aquariumleuchten an eine Controller anzuschließen (CW, WW) und damit jeweils die Helligkeit einzustellen. Als Dimmer sozusagen.
Wie spreche ich dann die Kanäle mit dem raw Befehl an?
set Device:raw_cw raw 1023,0,0,0,0
und
set Device:raw_ww raw 1023,0,0,0,0
Korrekt?
Gruß
Eisix
Moin
Nein, das ist nicht korrekt! Der Controller hat 5 Kanaele, und jede Zahl steht fuer einen Kanal! Bedenke, 0 (Null) ist auch eine Zahl! Also war das Beispiel von vbs fuer den 1. Kanal 100% und die restlichen 4 Kanaele 0%.
Gruss Christoph
Ja, genau. Sorry, hätte ich dazu sagen sollen...
Steuerung einzelner Kanäle ohne die anderen zu ändern:
https://forum.fhem.de/index.php/topic,70738.msg1067780.html#msg1067780
Hallo zusammen,
ich habe seit längerer Zeit zwei Controller im Einsatz und eigentliche funktionieren die sehr gut. Per Master/Slave DOIF habe ich die Controller so verbunden, dass C_2 immer genau das macht, was C_1 tut.
define di_RGBWW_ControllerMasterSlave DOIF ([RGBWW_Controller_1:rgb]) (set RGBWW_Controller_2 rgb [RGBWW_Controller_1:rgb])
attr di_RGBWW_ControllerMasterSlave do always
Bei folgendem Punkt komme ich jedoch aktuell nicht weiter. Bei einem Neustart der Controller oder auch des WLAN-Routers (z.B. bei Stromausfall) gehen die LED beider Controller standardmäßig an. Das ist ungünstig, wenn man mal nicht zu Hause ist. Daher würde ich das gerne unterbinden. Jetzt wollte ich das eigentlich mit einem DOIF über ["^RGBWW_Controller:^stateLight:.on$"] und dann (set $DEVICE off) abfangen. Leider habe ich jedoch bei jedem Schalten der Controller mind. drei Events mit stateLight, so dass die Befehlskette komplett durcheinander kommt. Hat jemand eine Idee?
Es gibt in der Konfig die startupcolor. Damit müsstest du das in den Griff bekommen.
Zum zweiten können die Controller auch per mqtt synchronisieren so ganz ohne doif.
Hallo alle,
erst mal danke an vbs - Respekt für die gute Arbeit, und dass du auch supportest!
Dann: Ich bin immer noch auf dem release-Channel - ist geplant den testing-Stand in naher Zukunft nach "Release" zu heben ? weil da ist ja doch schon einiges weiterentwickelt worden..
Aus eurer Erfahrung: könnte ich ansonsten bedenkenlos auf den testing-Channel wechseln, läuft die Version aktuell ziemlich stabil ?
Will mir den hart erarbeiteten WAF nicht zerstören.. ;D
Danke,
Chris
Also bei mir läuft testing stabil. Aber ich nutze eigentlich auch nur Basisfunktionen.
Heute ist an meinen Controler scheinbar die Firmware gestorben.
Mit dem WLAN Verbindet sich das Teil noch, aber geht man auf die webadresse erscheint eine leere Seite.
K.a. was da passiert ist, aber muss ich das teil jetzt zerlegen und neu Flashen ?
Der typische Fehler ist, dass der Flash Chip aufgibt.
Ich schätze, Du wirst den ESP ersetzen müssen.
Grüße,
pj
Bei mir reicht normalerweise ein Neuflashen aus FHEM.
ich hab auch schon welche gehabt, bei denen ich den chip einmal genullt und dann neu geflasht habe und es funktionierte.
Das Problem ist halt, dass wir dadurch, dass per default der aktuelle Zustand gespeichert wird, wir die Schreibzyklen des Flash Chips aufbrauchen (ich glaub, die sind nur mit 1000 Zyklen spezifiziert). Leider macht ffs da kein (oder zumindest kein gutes) wear levelling.
also: neu flashen kann helfen, sonst muss halt der Chip raus und ein neuer rein.
pj
also irgendwie reagiert da noch etwas, zumindest kann ich mit fhem noch ein wenig etwas steuern, nur der modus auf rgbww lässt sich nicht mehr umstellen aber zumindest RAW die Kanäle steuern.
Und es ist wohl genau das Thema mit dem ständigen write auf dem Chip. Wird ja täglich auch ein und ausgeschaltet vom Strom.
Ich habe ja einige esp am laufen die seit jahren im dauerbetrieb sind, ok mit espeasy drauf, da scheint es das Problem nicht zu geben.
Kann man das beschreiben parametrisieren um das zu verhindern ?
Moin, ja, das Problem ist, dass der Schreibzugriff ja auf eine Datei im Flash Filesystem passiert und je nachdem, wohin da geschrieben wird, kann es sein, dass die Struktur des Filesystems kaputt geht und der Controller es beim nächsten Start nicht mehr mounten kann. Dann fehlt vor allem eines: die Daten für das User interface. Das HTML API (also der Zugriff über das fhem Modul etwa) funktioniert meist weiter.
Manchmal kannst Du darüber auch noch neu flaschen und den rgb Modus konfigurieren.
Und das ganze komplett zu verhindern kannst Du den Controller auf eine fixe startup Farbe einstellen:
config-color-startup_color
Das ist vor allem bei Leuchten hilfreich, die etwa über einen Bewegungsmelder oft angesteuert werden.
Tägliches elektrisches ein/ausschalten sollte eher kein Problem sein.
pj
ok musste mit seriel neu flashen.. dummerweise ota war von der fritzbox geblockt.. aber erst gemerkt nachdem das ding resettet war.
Bei dem startup color wie muss ich das setzen ? ich nutze meist raw 0,0,0,1023,1023
set <name> config config-color-startup_color 0,0,0,1023,1023
das klappt so nicht, die ww cw kanäle gehen so nicht mit an der modus ist wohl nur rgb, wie kann man das so setzen ?
ok nochmal edit :-) habs kappiert, es geht nur <hue>,<sat>,<val> or <hue>,<sat>,<val>,<ct>
schade, weil ich so nie ww und cw auf max power bringe
Hi!
mal eine ganz andere frage. hat jemand für die platinen aus den sammelbestellungen eine hutschienen-halterung? auf thingiverse wurde ich auf die schnelle nicht fündig...
cheers,
Pula
Für den 3d drucker? Könnte ich dir machen. Hab ein paar vorlagen da das ich es schnell konstruieren könnte
Danke für das Angebot!
mir war gestern abend langweilig, da hab ich mir selber was zusammengeschustert.
falls es jemand braucht, einfach melden...
Cheers,
Pula
Hi,
anschauen würde ich es mir schon gerne, wäre cool, wenn Du es hier oder besser bei Thingoverse hochladen könntest ?
Ronny
Hi,
ok :-)
https://www.thingiverse.com/thing:5012912/files (https://www.thingiverse.com/thing:5012912/files)
Nicht besonders schön, aber funktioniert. Nur das entfernen der supports ist ein wenig fummelig...
Cheers,
Pula
Hoi,
danke. Ich habe es mir mal auf meine Liste gesetzt. Schönheit ist nicht so wichtig, Funktion ist wichtiger, sieht ehh kaum einer :)
Ronny
Hab meine Designs auch überarbeitet.
Habe nun die Voron Hutschienenhalter an das Gehäuse gebaut.
https://www.thingiverse.com/thing:4497711
Falls Halterv2 nicht angezeigt wird die zip laden da ist die Datei drin.
Super, danke!
könntest du bitte ein stl auch noch machen davon?
hab nix zum öffnen deiner files...
Cheers,
Pula
Was für einen Slicer nutzt du denn?
Heutzutage sollte jeder Slicer 3mf beherrschen.
Die F3d ist für Fusion360.
Habe die V2 als Stl mal hier hochgeladen.
Ist aber nicht ausgerichtet also muss noch drehen und am besten mit ganz ganz wenig support das bricht sich frei.
Könnt ja mal rückinfo geben ob das so passt. sollte gut fest sitzen.
Dein Entwurf sah etwas wackelig filigran aus und man konnte ihn nur von der Seite draufschieben. ;D
Super, danke!
ach so - ich kannte das 3mf-Format noch nicht. Bin eigentlich davon ausgegangen, daß das ein proprietäres Format irgend eines Herstellers von CAD-Software ist. Man lernt nie aus :-)
Danke für die Erklärung und für das neue Design - ist auf jeden Fall besser als meines. War auch eins meiner ersten ^^
Werde in den nächsten Tagen mal einen Druck machen und dann rückmelden...
Cheers,
Pula
achso was ich noch erwähnen sollte.
den halter am besten aus petg.
da der flexibel sein muss ist pla nicht empfehlenswert.
Hallo,
nochmal danke für das Design.
Habs das heute mal gedruckt in PET. Leider ist das SO starr, dass es sich unmöglich einklinken läast (roheste gewalt wollte ich auch nicht anwenden, um die hutschiene nicht zu beschädigen). man müsste das irgendwie anders machen.
aber du hast mich auf eine idee gebracht mit der "grundplatte"... ich werd mal die nächsten tage schauen, ob ich nicht eine solche "grundplatte" mit verschraubung für dein original-gehäuse (das wirklich wahnsinn ist) hinkriege....
Cheers,
Pula
Könntet ihr bitte die Gehäuse Diskussion in den Gehäuse Thread verschieben? 😉
mh das ist komisch.
lässt sich das mittelteil denn verschieben?
gut ich habe 2 von den haltern genommen vielleicht ist das etwas zu viel für das kleine gehäuse.
Aber ich habe die Halter schon mehrfach verwendet und hat immer gut gepasst.
Wichtig ist das sich das Mittelteil bewegen kann. Dann kann man es mit dem Flexiblen Teil anfangend und etwas druck eigentlich leicht über die schiene klicken.
Ansonsten etwas vergrößern so das man mit einem kleinen schraubendreher die "federn" entspannen kann zum einklicken?
hm. möglicherweise hab ich da was falsch verstanden?
bei mir ist das ein ding, fast ein block mit diesen schlangenförmigen inlays (federn)... muss man evtl nach dem druck etwas herausarbeiten oder so?
Hallo zusammen,
ich habe vor einiger Zeit Platinen von pjakobs v3.0 angefertigt.
Nun habe ich des Öfteren Anwendungen, wo ein Hardware ON OFF Toggle super wäre.
Ein Beispiel:
Reedkontakt an einem Badschrank, welcher eine Ambientebeleuchtung Ein- bzw. Ausschalten soll.
Aktuell hängt der Reedkontakt einfach auf den DISABLE Pins. Der Disable ist bestimmt nicht dafür gedacht, denn nach ca. zwei Wochen ist die Firmware futsch.
Dann heißt es: Controller ausbauen und neu flashen. Ein Badschrank ist natürlich ein Extrembeispiel, so oft wie der auf und zu gemacht wird. ;D
Ist so ein ON OFF Toggle an den bestehenden Pins GPIO2 / GPIO15 geplant oder gibt es eine Idee, wie man das auf schöne Weise anderweitig umsetzen kann?
In einer anderen Anwendung war der Plan, einen Controller mit einem Busch-Jäger Taster zu schalten. https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Hardware-Push-Buttons (https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Hardware-Push-Buttons)
Das hat leider nicht immer funktioniert und manchmal gab es auch echt komische und bizarre Effekte. (Ein Controller ging auf unerklärliche Weise auch flöten)
Ist es generell zu empfehlen lieber auf Hardware-Entkopplung zu setzen oder spielt das keine Rolle?
Zur Info, für andere Bastler: general/buttons_debounce_ms muss bei mir immer >1000ms sein, damit ein Busch-Jäger Taster ordentlich durchgeschaltet wird.
Danke und Grüße
Hallo,
ich habe heute einen Controller in betrieb genommen mit der Version 1.5.
Die LEDs glimmen leider nur, wenn diese über den Controller angesteuert werden. Ich habe einen CW WW Strips angeschlossen.
Der Strip selbst ist ok.
Ich vermute das eine Einstellung nicht passt?
Zitat von: holzwurm83 am 12 November 2021, 21:01:04
Die LEDs glimmen leider nur, wenn diese über den Controller angesteuert werden. Ich habe einen CW WW Strips angeschlossen.
Der Strip selbst ist ok.
Ich vermute das eine Einstellung nicht passt?
Hm, sollte mMn dann nicht "nur glimmen". Ich würde dann doch eher auf etwas hardwareseitiges tippen.
Ich würde gern auf tasmota wechseln. Hat das jemand von euch schon ausprobiert?
Hallo,
ich habe einen der Controller im Einsatz und habe aktuell ein bisschen Probleme mit meinem WLAN. Es fällt regelmäßig für einige Sekunden/Minuten aus und erscheint dann wieder - liegt am Access Point.
Der Controller verbindet sich nach Rückkehr des WLANs wieder ordnungsgemäß damit, ist aber dann grundsätzlich eingeschaltet, sprich die LEDs leuchten in der jeweils letzten Konfiguration. Lässt sich das irgendwie umgehen?
Es ist zwar ein guter Indikator um zu sehen wann mein WLAN spinnt aber die Beleuchtung muss auch nicht die ganze Nacht an sein, im ungünstigsten Fall.
Ich würde erstmal auf die Doku verweisen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Startup-Color
Zitat von: vbs am 20 Juni 2022, 13:11:33
Ich würde erstmal auf die Doku verweisen:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Startup-Color
Sorry kannte ich nicht.
Leider macht es aber nicht so ganz das, was ich mir wünschen würde.
Nach dem Setzen dieser Config auf 0,0,0 schaltet sich der Controller ab, wenn er zwischendurch das WLAN verliert.
Eigentlich sollte die Einstellung 'last' schon passen, denn so wie ich es verstehe, soll er dann den letzten Zustand beibehalten - also wenn an, dann an bleiben und wenn aus, dann aus bleiben.
Es scheint aber so zu sein, dass er nur den letzten Wert vom 'an' speichert, nicht aber 0,0,0 wenn der Controller aus war.
Kann man das ändern oder ist das so gewollt?
Das ist eigentlich nicht so gewollt und verhält sich mW normalerweise auch nicht so. Zumindest nicht bei einem normalen Power-On. Ich vermute, dass der Controller bei dem WLAN-Verlust nicht regulär neu bootet und damit dieser Mechanismus nicht in der Form greift. Ich kann leider nicht genau sagen, was stattdessen passiert. Offenbar... irgendwas anderes...
Hallo vbs,
ich habe sporadisch immer mal wider soetwas in meinem Logfile:
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $red in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $green in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $blue in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $warmWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $colorTemp in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $red in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $green in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $blue in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $warmWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $coldWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.04 06:54:55 1: PERL WARNING: Use of uninitialized value $coldWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
Ich habe 4 von diesen Controllern laufen, und alles funktioniert seit langer Zeit auch recht gut.
Trotzdem würde mich mal interessieren warum diese Warnungen auftretet und ob ich da helfen kann.
Außerdem noch eine Frage zur Firmwareversion:
Ich steige nicht so richtig durch. Ist das auf dem Foto der Aktuelle Stand den man haben kann ???
Also die Warnings können eigentlich nur auftreten, wenn du einen Raw-Befehl ausführst. Kannst du sagen, welchen Befehl/e du benutzt? Ist vermutlich eine schlechte Parameterbehandlung im Code, die ich dann gern korrigiere.
Ja vbs35 ist die aktuellste.
EDIT:
Ach, ich glaube, ich seh schon und ich kann es auch selbst reproduzieren, danke.
Also, ja ich verwende auch RAW Befehle, aber zu dem Zeitpunkt der Logeinträge waren das sicher keine.
Ich kann nicht genau nachvolziehen welcher Controller zu der Zeit bedient wurde.
Hier mal ein paar Zeilen die ich in verschiedensten DOIF´s an die Controller schicke:
set LED_Schlafzimmer dim 20 600
set LED_Schlafzimmer off
(set LED_Ankleide hsv 0,100,1 5),
(set LED_Ankleide hsv 40,100,100 600 q),
(set LED_Ankleide hsv 80,100,100 1800 q))
((set LED_Kueche hsv 40,100,{(100 - ([LUX] * 10))} 10))
(set LED_Kino raw 1023,652,0,1023,1023 10),
(set LED_Kino raw 1023,299,0,, 600 q)
((set LED_Kino raw ,,,,1023 4),
(set LED_Kino raw ,,,200, 4 q),
(set LED_Kino raw 1023,652,0,, 4 q)
Aus den verschiedenen DOIF´s in loser Folge kopiert.
Vielleicht hilfts...
Zitat von: Skusi am 05 Januar 2023, 14:50:45
Also, ja ich verwende auch RAW Befehle, aber zu dem Zeitpunkt der Logeinträge waren das sicher keine.
Hm, bisschen komisch dann... also laut Code passiert das nur bei einem Raw-Set-Befehl...
Aber probier mal die Version im Anhang. Ansonsten hab ich erstmal keine Idee...
Ok, Danke.
Hab das Modul ausgetauscht und per reload aktiviert.
Im Log gabs dann das:
2023.01.06 15:26:36 1: PERL WARNING: Prototype mismatch: sub main::encode_json ($;$) vs ($) at /usr/share/perl/5.28/Exporter.pm line 66.
2023.01.06 15:26:36 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($;$$) vs ($) at /usr/share/perl/5.28/Exporter.pm line 66.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Initialize redefined at ./FHEM/32_EspLedController.pm line 23.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Connect redefined at ./FHEM/32_EspLedController.pm line 42.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Define redefined at ./FHEM/32_EspLedController.pm line 47.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Undef redefined at ./FHEM/32_EspLedController.pm line 79.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_OnInit redefined at ./FHEM/32_EspLedController.pm line 86.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_OnConnect redefined at ./FHEM/32_EspLedController.pm line 99.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_RemoveTimerCheck redefined at ./FHEM/32_EspLedController.pm line 107.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_QueueIntervalUpdate redefined at ./FHEM/32_EspLedController.pm line 112.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Check redefined at ./FHEM/32_EspLedController.pm line 122.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_CheckConnection redefined at ./FHEM/32_EspLedController.pm line 132.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Ready redefined at ./FHEM/32_EspLedController.pm line 155.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Read redefined at ./FHEM/32_EspLedController.pm line 166.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseMsg redefined at ./FHEM/32_EspLedController.pm line 242.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Get redefined at ./FHEM/32_EspLedController.pm line 275.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ColorRangeCheck redefined at ./FHEM/32_EspLedController.pm line 298.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Set redefined at ./FHEM/32_EspLedController.pm line 317.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SendConfig redefined at ./FHEM/32_EspLedController.pm line 608.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SendSystemCommand redefined at ./FHEM/32_EspLedController.pm line 650.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Cleanup redefined at ./FHEM/32_EspLedController.pm line 664.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_GetConfig redefined at ./FHEM/32_EspLedController.pm line 670.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SetChannelCommand redefined at ./FHEM/32_EspLedController.pm line 678.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Attr redefined at ./FHEM/32_EspLedController.pm line 697.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_Notify redefined at ./FHEM/32_EspLedController.pm line 720.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_GetInfo redefined at ./FHEM/32_EspLedController.pm line 727.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_IterateConfigHash redefined at ./FHEM/32_EspLedController.pm line 738.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseConfig redefined at ./FHEM/32_EspLedController.pm line 751.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseInfo redefined at ./FHEM/32_EspLedController.pm line 784.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_FwUpdate_GetVersion redefined at ./FHEM/32_EspLedController.pm line 834.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_QueueFwUpdateProgressCheck redefined at ./FHEM/32_EspLedController.pm line 853.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_FwUpdateProgressCheck redefined at ./FHEM/32_EspLedController.pm line 868.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseFwVersionResult redefined at ./FHEM/32_EspLedController.pm line 876.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseFwUpdateProgress redefined at ./FHEM/32_EspLedController.pm line 927.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_GetHttpParams redefined at ./FHEM/32_EspLedController.pm line 978.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_GetCurrentColor redefined at ./FHEM/32_EspLedController.pm line 993.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseColor redefined at ./FHEM/32_EspLedController.pm line 1004.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_fixHueCircular redefined at ./FHEM/32_EspLedController.pm line 1029.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_GetQueuePolicyFlags redefined at ./FHEM/32_EspLedController.pm line 1039.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SetHSVColor_Slaves redefined at ./FHEM/32_EspLedController.pm line 1047.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_EncodeJson redefined at ./FHEM/32_EspLedController.pm line 1085.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SetHSVColor redefined at ./FHEM/32_EspLedController.pm line 1096.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_UpdateReadingsHsv redefined at ./FHEM/32_EspLedController.pm line 1156.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_UpdateReadingsRaw redefined at ./FHEM/32_EspLedController.pm line 1184.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_SetRAWColor redefined at ./FHEM/32_EspLedController.pm line 1198.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ParseBoolResult redefined at ./FHEM/32_EspLedController.pm line 1227.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_addCall redefined at ./FHEM/32_EspLedController.pm line 1257.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_doCall redefined at ./FHEM/32_EspLedController.pm line 1281.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_callback redefined at ./FHEM/32_EspLedController.pm line 1299.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_RGB2HSV redefined at ./FHEM/32_EspLedController.pm line 1329.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_HSV2RGB redefined at ./FHEM/32_EspLedController.pm line 1365.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_ArgsHelper redefined at ./FHEM/32_EspLedController.pm line 1406.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_isNumeric redefined at ./FHEM/32_EspLedController.pm line 1451.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_isNumericRelative redefined at ./FHEM/32_EspLedController.pm line 1455.
2023.01.06 15:26:36 1: PERL WARNING: Subroutine EspLedController_rangeCheck redefined at ./FHEM/32_EspLedController.pm line 1459.
Ich denke das hat mir dem Reload zutun und ist normal.
Dabei ist mir noch folgendes im Log aufgefallen:
2023.01.05 18:52:08 1: PERL WARNING: Use of uninitialized value $colorTemp in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 18:52:08 1: PERL WARNING: Use of uninitialized value $warmWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 18:52:08 1: PERL WARNING: Use of uninitialized value $coldWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 18:52:08 1: PERL WARNING: Use of uninitialized value $warmWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.05 18:52:08 1: PERL WARNING: Use of uninitialized value $coldWhite in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.05 18:52:08 1: PERL WARNING: Argument "Unknown argument brightness, choose one of " isn't numeric in numeric lt (<) at FHEM/Color.pm line 508.
2023.01.05 18:54:16 2: set_BA_Kino: set Gigablue_Kino on: wake-up command sent to MAC 00:00:de:ad:be:ef
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $red in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $green in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $blue in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1206.
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $red in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $green in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
2023.01.05 19:10:18 1: PERL WARNING: Use of uninitialized value $blue in concatenation (.) or string at ./FHEM/32_EspLedController.pm line 1232.
Das gab es wohl gestern als ich mein Heimkino benutzt habe. Funktionierte aber alles einwandfrei. Nur zur weiteren Info...
Gruß Skusi
Das ist ja immer noch die gleiche Codezeile in der Warning. Bist du sicher, dass du das Modul korrekt neu geladen hast ("reload 32_EspLedController")? Im Zweifel mal FHEM neu starten.
Ähh, hast Du gesehen das die beiden Logfile Auszüge zeitlich falsch in meinem Post stehen ?
Also das untere ist vor dem oeren Block gewesen. Also vor dem reload.
Gestern Abend hab ich übrigens die "Kino" Routine wieder benutzt, und heute finde ich nix verwerfliches im Logfile.
Ich beobachte weiter.
Ist denn die Version die ich nun von Dir habe nicht im Update ? Also bei nächstem update per Fhem wieder weg ?
Werden Deine Änderungen eingecheckt ?
Zitat von: Skusi am 07 Januar 2023, 13:40:53
Ähh, hast Du gesehen das die beiden Logfile Auszüge zeitlich falsch in meinem Post stehen ?
Also das untere ist vor dem oeren Block gewesen. Also vor dem reload.
Nein, ich hatte nicht damit gerechnet, dass du den gleichen Fehler nochmal reportest ;D
Zitat von: Skusi am 07 Januar 2023, 13:40:53
Ist denn die Version die ich nun von Dir habe nicht im Update ? Also bei nächstem update per Fhem wieder weg ?
Werden Deine Änderungen eingecheckt ?
Nein, ist noch nicht im Update. Kommt aber, wenn du sagst, dass es jetzt ok ist. Kannst du bis dahin auf ignore im Update setzen wenn du möchtest.
ZitatNein, ist noch nicht im Update. Kommt aber, wenn du sagst, dass es jetzt ok ist. Kannst du bis dahin auf ignore im Update setzen wenn du möchtest.
Kurzes Update: Bis jetzt mit der geänderten Version alles in Ordnung !
Ok, danke für die Rückmeldung. Ist jetzt im Update.
Versuche schon den ganzen Abend über den Controller zu flashen und bekomme es einfach nicht hin :(
Habe, wenn ich nicht komplett daneben liege Version 3 der Platine. Bootloader Mode aktivieren klappt:
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
ESPTool bekommt dann aber einfach keine Antwort.
esptool.py v4.4
Serial port /dev/tty.usbserial-A1017XTA
Connecting......................................
A fatal error occurred: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Hab schon versucht das Ganze mit ext. Energieversorgung zu flashen, wie auch nur den ESP8266 mit Strom versorgt. Macht aber alles keinen Unterschied. Nur zur Sicherheit die PINs:
a) mit ext. Stromversorgung: TX->RX, RX->TX, GND->GND
b) ohne: TX->RX, RX->TX, GND->GND, VCC->direkt an den VCC PIN des ESP8266 (3,3V)
Jmd. eine Idee?
Neben dem 3,3V Pin ist ein GND PIN. Den habe ich auch immer mit 0V belegt.
Und GND extern ist mit GND Platine verbunden?
Bei mir hat auch kein Connect stattgefunden, da war der USB - Serial Umsetzer defekt. Hab einen neuen bestellt, dann ging es wieder.
Hattest du das RGBWW Controller Board separat mit Strom versorgt oder nur den ESP12 per Serial Umsetzer?
Angeschlossen hatte ich:
Serial Umsetzer - Controller
GND - GND
3,3V - 3,3V
TX - RX
RX - TX
Serial Umsetzer selbst habe ich gerade mit einer Sonoff Steckdose mit ESP8266 getestet, da hat das Flashen sofort geklappt.
Das Controller Board hatte ich separat versorgt, dann festgestellt, dass die 3.3V am ESP genügen.
Seitdem versorge ich nur noch den ESP.
hab mal wieder totalausfall gehabt. Aber jetzt ist mir so alles abhanden gekommen an wissen... ja man kann sich nicht alles merken.
RGBWWCW hab ich im Einsatz.
Damals hatte ich doch beim startup das hier
config-color-startup_color 0,0,100
Aber beim starten dimmt das nicht hoch
Ich finde einfach nicht das setting für das hochdimmen beim starten
EDIT:
habs gefunden, es ist nicht in der relase sondern in der testing: https://rgbww.dronezone.de/testing/version.json
da ist das mit dem fading beim einschalten mit drin
@VBS vielleicht im git überarbeiten
Relevant zum Thema:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki/Startup-Color
Da du nicht verraten hast, welche FW du verwendest, hatte ich eh gedacht, wir reden von testing. ;) Startup-Color gibts aber auch in release.
Ich hab noch nicht so ganz verstanden, was dir jetzt gefehlt hat, aber umso besser, dass du schon fündig geworden bist.
Was soll ich im git überarbeiten?
Mir hat gefehlt wenn ich einschalte, das mit dem startup color das ganze hochdimmt.
Da ich scheinbar immer die testing hatte.
Was ich im git bzw. website meinte, das man nach 4 jahren vielleicht die testing zur letzten release macht.
Ich dachte das wäre dann die released.
Der Link http://rgbww.dronezone.de/release/version.json/spiff_rom.bin geht auch ins leere.
Zitat von: laserrichi am 29 April 2023, 00:45:38Mir hat gefehlt wenn ich einschalte, das mit dem startup color das ganze hochdimmt.
Da ich scheinbar immer die testing hatte.
Wie gesagt, bin eigentlich der Meinung, dass das auch in release funktioniert.
Zitat von: laserrichi am 29 April 2023, 00:45:38Was ich im git bzw. website meinte, das man nach 4 jahren vielleicht die testing zur letzten release macht.
Ich dachte das wäre dann die released.
Ja, geb ich dir recht. Vielleicht mach ich das mal in ner ruhigen Minute.
Zitat von: laserrichi am 29 April 2023, 00:45:38Der Link http://rgbww.dronezone.de/release/version.json/spiff_rom.bin geht auch ins leere.
Ja, das ist auch korrekt so, weil der Link so nicht stimmt. Wo hast du den her? Wenn du mal in die version.json guckst, sieht du den korrekten Link "http://rgbww.dronezone.de/release/spiff_rom.bin" und der funktioniert auch.
https://rgbww.dronezone.de/index.html
bei Fileystem steht der Link
Danke, habe es angepasst.
Hat den Controller schonmal jemand per MQTT verbunden, sei es Fhem oder auch HA?
Ich hab noch einige Controller hier, und bin seit ein paar Wochen auf HA, da Fhem für mich nicht mehr relevant ist, und nur noch läuft, um die Controller zu bedienen. Allerdings hab ich Probleme, den Controller in HA per mosquitto broker zu erkennen.
Bringt dir vermutlich nicht viel, aber hab ich damals bei der Entwicklung gemacht und ansonsten bei mir den Sync-Modus per MQTT tagtäglich problemlos im Einsatz.
Zitat von: masked__rider am 29 Mai 2023, 16:33:15Hat den Controller schonmal jemand per MQTT verbunden, sei es Fhem oder auch HA?
Ich hab noch einige Controller hier, und bin seit ein paar Wochen auf HA, da Fhem für mich nicht mehr relevant ist, und nur noch läuft, um die Controller zu bedienen. Allerdings hab ich Probleme, den Controller in HA per mosquitto broker zu erkennen.
Hi, hast du das in HA umgesetzt?
Hi,
ich wollte und habe mich wirklich bemüht eine Lösung zu finden.
Wurde leider ziemlich rüde von einem "erfahrenen user" ziemlich rüde abgeblockt, der sich anscheinend nicht einmal die Mühe machte, mein Anliegen zu verstehen:
https://community.home-assistant.io/t/mqtt-light-template-add-color-mode/666700/8 (https://community.home-assistant.io/t/mqtt-light-template-add-color-mode/666700/8)
Der von mir eingeschlagene Weg, über das sog. template-schema zu gehen, hat leider nicht funktioniert, weil der "color mode" da nicht unterstützt wird - und das json-Format vom rgbww-controller doch ein wenig exotisch ist.
Ich muss zugeben, daß das meine Begeisterung für HA einigermassen gebremst hat.
Denn auch im fhem-forum habe ich des öfteren "dumme" Fragen gestellt, aber irgendwie wurde mir immer geholfen.
Letzten Endes "fahre" ich derzeit noch zweigleisig. Ich werde aber trotzdem mal versuchen, einen der Controller mit esphome zu flashen (getestet habe ich es bereits, sh oben), aber bisher noch ohne angeschlossene stripes...
Cheers,
Pula
Hi pula,
hmm, ja, die Reaktion des Typen in dem anderen forum war wenig hilfreich. Schade eigentlich.
Kann home assistant wirklich keine HSV Leuchten ansteuern? Und - inwiefern findest Du das json-rpc Format exotisch?
Ich hab mich noch nie mit home assistant auseinandergesetzt. Hast Du mal ein Beispiel, wie das normalerweise Leuchten ansteuert?
Wenn es nicht zu viel Aufwand ist, würde ich das ggf. als Feature request für die Version 5 aufnehmen.
pj
Hi pjakobs,
danke schön :-)
Naja, die Reaktion des Typen war wirklich grottig - und sonst kam in dem Forum nichts. Leider.
Es scheint mir so, als ob die HSV-Integration in HA ziemlich stiefmütterlich wäre.
Geben tuts zwar schon was, aber so richtig wieder auch nicht (zumindest über mqtt).
Es ist jetzt schon wieder eine Weile her, seit ich mich damit beschäftigt habe. Aber soweit ich mich erinnere, hätte man RGB aus den color pickern dann in hs umrechnen müssen und den value extra (als brightness) setzen.
Aber so weit bin ich gar nicht gekommen, weil ich die Konzepte von HA noch immer nicht zu 100% begriffen habe, denke ich.
Die genaue Doku ist hier:
https://www.home-assistant.io/integrations/light.mqtt/ (https://www.home-assistant.io/integrations/light.mqtt/)
Das Ganze _könnte_ mit dem sog json-scheme ( https://www.home-assistant.io/integrations/light.mqtt/#json-schema (https://www.home-assistant.io/integrations/light.mqtt/#json-schema) ) funktionieren (oder auch nicht).
Dann würde HA das json in der Art brauchen:
{
"state": "ON",
"color_mode": "hs",
"color": {
"h": 24.0,
"s": 100.0
}
}Aber das ist natürlich reine Mutmassung von mir, ob es wirklich funktioniert, müsste man testen. Und ich weiß auch nicht, obs die Mühe wert ist.
Sprich: Ob das ausser mir und holzwurm83 noch jemand braucht.
Zumal es ja eine Abkehr von dem eigentlich unglaublich tollen fhem ist.
Mein Hauptgrund für das Interesse an HA ist übrigens ein oft recht starkes "Laggen" von fhem, dem ich einfach nicht auf die Spur komme. Oder anders ausgedrückt: Es ist ein wenig öde, wenn man auf den Licht-Button drückt und erst nach 2-3 Sekunden tut sich was. Nicht immer, aber zu oft.
Und leider ist die gesamte Oberfläche von fhem doch schon ziemlich angestaubt (trotz ftui etc). Ziemlich schade, daß sich da (zumindest
meines Wissens) noch nix wirklich modernes und trotzdem einfaches tut. Auch für Android. Leider fehlt es mir an der Zeit, hier selber aktiv zu werden (zumal ich dafür noch einiges zu lernen hätte).
Ich habe doch auch wie viele andere 8 oder 9 Jahre mit fhem verbracht und auch viel Hirnschmalz und Herzblut reingesteckt.
Und das Forum hier ist um Längen hilfreicher als bei HA.
Cheers,
Pula
Zitat von: pula am 10 April 2024, 19:21:34Das Ganze _könnte_ mit dem sog json-scheme ( https://www.home-assistant.io/integrations/light.mqtt/#json-schema (https://www.home-assistant.io/integrations/light.mqtt/#json-schema) ) funktionieren (oder auch nicht).
Hi, so habe ich das auch verstanden. Ich denke das es so funktionieren sollte. Habe damit auch schon mal letzte Woche rumgespielt, nur leider ohne erfolg, da ich in dem Thema leider auch nicht wirklich firm bin.
Zitat von: pjakobs am 10 April 2024, 18:48:52Wenn es nicht zu viel Aufwand ist, würde ich das ggf. als Feature request für die Version 5 aufnehmen.
Wo genau finde ich letzte Version? Ich habe aktuell bei mir diesen Link in der Konfiguration:
http://rgbww.dronezone.de/release/version.json
Zitat von: holzwurm83 am 12 April 2024, 19:55:49Zitat von: pula am 10 April 2024, 19:21:34Das Ganze _könnte_ mit dem sog json-scheme ( https://www.home-assistant.io/integrations/light.mqtt/#json-schema (https://www.home-assistant.io/integrations/light.mqtt/#json-schema) ) funktionieren (oder auch nicht).
Hi, so habe ich das auch verstanden. Ich denke das es so funktionieren sollte. Habe damit auch schon mal letzte Woche rumgespielt, nur leider ohne erfolg, da ich in dem Thema leider auch nicht wirklich firm bin.
Zitat von: pjakobs am 10 April 2024, 18:48:52Wenn es nicht zu viel Aufwand ist, würde ich das ggf. als Feature request für die Version 5 aufnehmen.
Wo genau finde ich letzte Version? Ich habe aktuell bei mir diesen Link in der Konfiguration:
http://rgbww.dronezone.de/release/version.json
die neueste Vesion ist aktuell noch nicht feature complete, aber ich arbeite daran. Wenn Du einen Controller zum testen hast und testen willst, gibt es die Updates auf http://lightinator.de/vesion.json aber achtung: das sind nightly builds und die Wahrscheinlichkeit, dass immer mal was nicht funktioniert und Du von Hand flashen musst ist groß
Ich mach bei Gelegenheit mal einen eigenen Thread zur V5 auf.
pj
Zitat von: masked__rider am 29 Mai 2023, 16:33:15Hat den Controller schonmal jemand per MQTT verbunden, sei es Fhem oder auch HA?
Ich hab noch einige Controller hier, und bin seit ein paar Wochen auf HA, da Fhem für mich nicht mehr relevant ist, und nur noch läuft, um die Controller zu bedienen. Allerdings hab ich Probleme, den Controller in HA per mosquitto broker zu erkennen.
Warum über MQTT wenn du HA benutzt? Mit der Erweiterung ESPHome sollten diese Controller sofort laufen...
MfG
Zitat von: M.Schulze am 15 April 2024, 18:41:05Zitat von: masked__rider am 29 Mai 2023, 16:33:15Hat den Controller schonmal jemand per MQTT verbunden, sei es Fhem oder auch HA?
Ich hab noch einige Controller hier, und bin seit ein paar Wochen auf HA, da Fhem für mich nicht mehr relevant ist, und nur noch läuft, um die Controller zu bedienen. Allerdings hab ich Probleme, den Controller in HA per mosquitto broker zu erkennen.
Warum über MQTT wenn du HA benutzt? Mit der Erweiterung ESPHome sollten diese Controller sofort laufen...
MfG
Ich wundere mich ein bisschen, klar kann man eine andere Firmware auf die Controller packen, aber die meisten alternativen Firmwares können halt nur acht bit pwm und damit bei weitem keine so guten Fades und meist auch keine lineare Helligkeit bei wechselnder Farbe.
Nach dem, was ich so gelesen habe ist home assistant etwas eingeschränkt, was die Ansteuerung von Leuchten angeht (primär RGB, wie das halt Computermenschen so machen). Das ist schade, denn das heißt dann ja eben, dass vieles was die Controller können verloren geht.
Ich hab dieser Tage mal versucht, Home Assistant zu installieren, um zu sehen, ob das leicht lösbar ist, oder ob ich sinnvollerweise was an der Firmware mache, aber das ist hinreichend kompliziert, wenn man nicht deren vorbereitetes Image benutzt (ich würde es auf einer VM installieren und normalerweise benutze ich auch podman und nicht Docker und und..)
Die etwas arrogante Haltung der community dort motiviert mich auch nicht gerade, mich darum zu kümmern, auch wenn scheinbar viele Nutzer dorthin abwandern.