ESP RGBWW Wifi Led Controller - Firmware vbs

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

Vorheriges Thema - Nächstes Thema

vbs

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.

pjakobs

#841
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

pjakobs

ich werd mich wohl nochmal um meine Netzwerk-Infrastruktur kümmern müssen :/

lewej

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

pc1246

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
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

vbs

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.

pula

#846
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
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

vbs

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.

pula

Ah - danke für die aufschlussreiche Antwort :-)
Denke halt Farben seit jeher in RGB, aber hier scheint sich ein Umdenken zu lohnen...
Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

pjakobs

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

pula

#850
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
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

pjakobs

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

vbs

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.bin


Die 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.

pc1246

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
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

ext23

@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
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)