ESP RGBWW Wifi Led Controller - Firmware vbs

[pjakobs]

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

[Eisix]

Hallo,

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

[vbs]

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.

[pjakobs]

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

[kmxak]

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

[pjakobs]

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.

(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

[balli1187]

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

[pjakobs]

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

[vbs]

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.

[pjakobs]

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

[kmxak]

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

[kmxak]

gerade einen update all gemacht... nun spuckt das modul folgendes aus:

Code Auswählen Erweitern

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?

[vbs]

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ß 

EDIT:
Hab bei mir nochmal getestet und da ist es offenbar nicht aufgetreten und reproduzieren konnte ich es auch nicht.

[kmxak]

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

[vbs]

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