ok, @herrmanj, mir wird langsam klar,
was da passiert, aber noch nicht
warum.
mein test-Statement:
set LED_Sc off;
set LED_Sc hsv 240,50,0 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
set LED_Sc val 100 1 q;set LED_Sc val 0 1 q;
im Anhang Log und Packet Trace, beide am gleichen Host gezogen, die Zeiten sind also vergleichbar.
Was auffällt:
- die Abarbeitung der Befehlsliste beginnt im Log um 10:15:42.224
- der erste API Call wird um 14:15:42.234 abgeschickt (will sagen: es wird HttpUtils_NonblockingGet aufgerufen)
- die erste Response message taucht im Log um 10:15:48.264 auf
gleichzeitig sehe ich im Packet Trace
- der erste Request erscheint um 10:15:48.238 (sprich: in diesem Moment wird er vom fhem Server über das Interface übertragen)
- die Antwort darauf kommt um 10:15:48.263
- der nächste Request kommt um 10:15:48.386
es ist also imho offensichtlich, dass, warum auch immer,
HttpUtils_NonblockingGet($param);
die Requests erst vier Sekunden später versendet, also nachdem die Queue völlig übermittelt wurde.
Bei diesem Test stand übrigens davor noch ein
usleep(2000);
um ggf. dem Stack ein bisschen Zeit zu geben.
Seltsam...
pj
Ich bin da noch nicht so ganz überzeugt.
Unser logging ist auch sch....e, da müssen wir was tun.
Zitatder erste API Call wird um 14:15:42.234 abgeschickt (will sagen: es wird HttpUtils_NonblockingGet aufgerufen)
Yepp, sehe ich auch so.
Zitatder erste Request erscheint um 10:15:48.238
yepp, gehe mit.
Zitat(sprich: in diesem Moment wird er vom fhem Server über das Interface übertragen)
Das muss nicht so sein.
Weil der controller die Verbindung nach jedem req beendet ist der erste Schritt von HttpUtils_NonblockingGet ein connect (non-blocking). Wenn der connect 6 Sekunden benötigt bekommst Du genau dieses Bild. (Achtung: Arbeitshypothese!).
Ich habe da tatsächlich auch das "Problem" das der erste connect einige Sekunden braucht. Ich denke aber ich habe doof gelötet oder so.
Was passiert denn wenn Du das noch, sagen wir 10 Sekunden, nochmal machst. Gleiches timing ?
btw, ich würde beim ersten "off" das "q" rausnehmen.
vg
joerg
upps... jetzt hatte ich den Beitrag doch glatt erstmal neu geschrieben, weil ich mir das Verschwinden nicht erklären konnte, aber - ist besser hier!
Wenn Du in den Trace schaust (wireshark) dann siehst Du auch den zugehörigen tcp Verbindungsaufbau, der beginnt sofort:
10:15:42.239181 fhem->controller [syn]
10:15:42.246483 controller->fhem [syn, ack]
10:15:42.245545 fhem->controller [ack]
damit steht die tcp Session, danach dauert es ziemlich genau sechs Sekunden bis der POST request kommt.
10:15:48.238021 fhem->controller POST
Grüße
pj
hmm. Mysteriös.
Wenn der connect sofort kommt stimmt der AUfruf seitens des moduls.
Stell mal bitte den globalen loglevel auf 5 und schreibt in den (alle) param hash zusätzlich "loglevel => 5,", dann schriebt httputils auch was ins log.
vg
joerg
Zitatupps... jetzt hatte ich den Beitrag doch glatt erstmal neu geschrieben, weil ich mir das Verschwinden nicht erklären konnte, aber - ist besser hier!
sorry. Ja , musste getrennt werden sonst werden wir ja verrückt :)
Zitat von: herrmannj am 28 Juni 2016, 11:36:33
hmm. Mysteriös.
Wenn der connect sofort kommt stimmt der AUfruf seitens des moduls.
Stell mal bitte den globalen loglevel auf 5 und schreibt in den (alle) param hash zusätzlich "loglevel => 5,", dann schriebt httputils auch was ins log.
mach ich gleich mal
Zitat von: herrmannj am 28 Juni 2016, 11:36:33
vg
joerg
sorry. Ja , musste getrennt werden sonst werden wir ja verrückt :)
vor allem verwässern wir Patricks nächste Sammelbestellung, das ist so schon besser. Danke
pj
Wenn ich euch noch irgendwie unterstützen kann, dann sagt Bescheid. Ich werde immer mal wieder in den Thread gucken, falls ich etwas nicht sofort sehe oder ihr Feedback braucht, am besten per PN/Mail bescheid geben, dann geht es nicht verloren
Das ist super, Danke! "solid" hätte imho Prio, der endpoint mit den Infos über die queue Prio 2.
vg
joerg
leider gibt mir HttpUtils nicht so schrecklich viel Log Info raus:
Aufruf:
2016.06.28 13:12:02.637 5: LED_Sc send API Call $VAR1 = {
'callback' => sub { "DUMMY" },
'data' => '{"hsv":{"v":"0","ct":"2700","h":"120","s":"40"},"q":"false","t":"0","cmd":"solid","d":"1"}',
'hash' => {
'.triggerUsed' => 0,
'CFGFN' => '/opt/fhem/conf.d/MiLight.cfg',
'CL' => {
'Authenticated' => 0,
'BUF' => '',
'CD' => bless( \*Symbol::GEN227, 'IO::Socket::INET' ),
'FD' => 24,
'FW_ID' => '1581',
'LASTACCESS' => 1467112322,
'NAME' => 'WEB_192.168.29.43_58505',
'NR' => 373,
'PEER' => '192.168.29.43',
'PORT' => 58505,
'SNAME' => 'WEB',
'SSL' => undef,
'STATE' => 'Connected',
'TEMPORARY' => 1,
'TYPE' => 'FHEMWEB',
'canAsyncOutput' => 1
},
'DEF' => '192.168.29.58',
'DEVICEID' => '14063373',
'FIRMWARE' => '0.3.0',
'Helper' => {
'DBLOG' => {
'ct' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '2700'
}
},
'hsv' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '120,40,0'
}
},
'hue' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '120'
}
},
'rgb' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '000000'
}
},
'sat' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '40'
}
},
'state' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => 'off'
}
},
'val' => {
'logdb' => {
'TIME' => '1467112227.75171',
'VALUE' => '0'
}
}
}
},
'IP' => '192.168.29.58',
'MAC' => '18fe34d6970d',
'NAME' => 'LED_Sc',
'NR' => 129,
'NTFY_ORDER' => '50-LED_Sc',
'READINGS' => {
'ct' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => '2700'
},
'hsv' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => '120,40,0'
},
'hue' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => '120'
},
'rgb' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => '000000'
},
'sat' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => '40'
},
'state' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => 'off'
},
'val' => {
'TIME' => '2016-06-28 13:10:27',
'VAL' => 0
}
},
'STATE' => 'off',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem^M
Accept: application/json',
'loglevel' => 5,
'method' => 'POST',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.29.58/color?mode=HSV'
};
HttpUtils log Output:
2016.06.28 13:12:02.640 5: HttpUtils url=http://192.168.29.58/color?mode=HSV
und dann
2016.06.28 13:12:09.078 5: HttpUtils http://192.168.29.58/color?mode=HSV: Got data, length: 16
2016.06.28 13:12:09.079 4: LED_Sc: got HSV color response
- das natürlich für jedes Setting.
Ich habe den Verdacht, dass zumindest Teile des Systems hier single threaded sind.
Zitat
PERL-Ausdrücke und FHEM-Kommandos werden im Haupt-"thread" ausgeführt
damit blockieren wir den Haupt Thread so lange, bis das gesamte Kommando ausgeführt ist.
hierzu passend auch dies (http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Ausf.C3.BChrung_von_Modulen)
Zitat
FHEM führt Module normalerweise nicht parallel aus. Daher wäre es ungünstig wenn Module Werte von einem Gerät abfragen und dann auf die Antwort des Geräts warten. In dieser Zeit wäre der Rest von FHEM blockiert. Die Ein- und Ausgabe sollte ohne Blockieren erfolgen und die Verarbeitung mehrerer Ein- und Ausgabekanäle quasi parallel ermöglichen.
dies scheint aber für fhem Kommandos nicht zu gelten.
Ich meine: so lange wir die Kommandozeile auswerten bleibt der fhem Hauptthread im LedController Modul, zwischenzeitlich werden die http calls innerhalb von HttpUtils oder LWP gequeued und erst, wenn wir den Hauptthread freigeben, weil das Kommando abgearbeitet ist geht's weiter.
Ich beginne zu glauben, dass das ein Verhalten ist, dass wir nicht ändern können.
pj
PS: ich konnte keinen Weg finden, dem fhem-Hauptthread kurzfristig die Kontrolle zurückzugeben (also sowas wie ein "sleep" in kooperativen Multitasking Systemen oder ein "relinquish control" damals bei NetWare (ok, jetzt wisst Ihr wie alt ich bin :D ) ) - ich sage wir akzeptieren das einfach.
In der Doku sollten wir dann kurz was dazu schreiben, à la "wenn die Beleuchtung direkt auf ein Ereignis reagieren soll, dann ist es ggf. sinnvoll die set Befehle für die animation einzeln abzusetzen
Dieses Problem spricht sehr für Patricks Idee vom "Animationset", denn das könnte man ggf. mit einem einzigen Call übertragen und dann ausführen.
Für die Zukunft gibt es ja noch weitere Lösungsmöglichkeiten: MQTT und Websockets 8) - braucht zwar noch etwas Zeit bis das ganze umgesetzt werden kann, eine einfache Testversion für z.B. MQTT oder Websockets lässt sich die Woche sicher zusammenschustern bevor die komplette Implementierung angepasst wird
Zitat von: herrmannj am 28 Juni 2016, 12:36:11
Das ist super, Danke! "solid" hätte imho Prio, der endpoint mit den Infos über die queue Prio 2.
Solid steht weit oben auf der Liste - die Queue Geschichte wird evtl etwas dauern da ich mir noch nicht sicher bin, in welcher Schnitstelleebene ich eingreife, oder ob ich sogar die Queue aus der LED Library rausnehme und auf Anwendungsebene verschiebe
Oh, immer langsam mit den jungen Pferden ;)
A: Generell ist fhem ein thread (fast ;) - dasss System ist kooperatives Multitasking.
B: Deswegen machen wir die ganzen calls ja asynchron, da klemmt auch nix
C: Klar bekommen wir das in den Griff (!!!)
Da es keinen "Hauptthread" gibt sind auch Konzepte wie Kontrolle an anderen thread geben obsolet.
Lass uns auf die Ursache fokusieren. Zwischen dem call und der response liegen ja wieder 6 Sekunden, da müssen wir suchen.
Ich schlage vor das testen wir mal so:
temporär nehmen wir das HttpUtils mal raus und bilden das Händisch mit inet (dann blockierend) nach. Da messen wir mal die Zeiten. Ich muss heute Abend aber erst mal isländisch essen ;)
vg
joerg
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
Oh, immer langsam mit den jungen Pferden ;)
A: Generell ist fhem ein thread (fast ;) - dasss System ist kooperatives Multitasking.
B: Deswegen machen wir die ganzen calls ja asynchron, da klemmt auch nix
C: Klar bekommen wir das in den Griff (!!!)
ich bin gespannt.
Hier braucht's jetzt mehr fhem Kenntnis als ich habe
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
Da es keinen "Hauptthread" gibt sind auch Konzepte wie Kontrolle an anderen thread geben obsolet.
der wird aber, z.B. der Doku, immer wieder erwähnt. Verwirrend.
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
Lass uns auf die Ursache fokusieren. Zwischen dem call und der response liegen ja wieder 6 Sekunden, da müssen wir suchen.
was wir wissen:
- diese Zeit steckt nicht in unsrem Modul sondern irgendwo in HttpUtils
- der Controller antwortet innerhalb von 25ms und das Paket geht auch beim Linux IP Stack ein (siehe tcpdump capture)
- HttpUtils http://192.168.29.58/color?mode=HSV: Got data, length: 16 kommt erst nachdem das letzte "set" abgeschickt wurde
Ich wette, wenn wir die Abfolge in einzelne fhem Kommandos zerlegen passt das alles.
Die fhem Doku sagt, dass Kommandozeilen (ich interpretiere: alles, was ich auf einen Schlag z.B. über das GUI Kommandoformularfeld absende) im "Haupt-Thread" ausgeführt werden - ich vermute: blocking.
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
Ich schlage vor das testen wir mal so:
temporär nehmen wir das HttpUtils mal raus und bilden das Händisch mit inet (dann blockierend) nach. Da messen wir mal die Zeiten.
ich schau mir mal HttpUtil ein bisschen an, mal sehen, wie asynchrone Events dort gehandhabt werden.
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
Ich muss heute Abend aber erst mal isländisch essen ;)
Brexit feiern? ;)
Zitat von: herrmannj am 28 Juni 2016, 14:39:07
vg
joerg
Zitat von: mrpj am 28 Juni 2016, 14:33:15
Für die Zukunft gibt es ja noch weitere Lösungsmöglichkeiten: MQTT und Websockets 8) - braucht zwar noch etwas Zeit bis das ganze umgesetzt werden kann, eine einfache Testversion für z.B. MQTT oder Websockets lässt sich die Woche sicher zusammenschustern bevor die komplette Implementierung angepasst wird
Ja, aber nicht verrennen bitte.
Hier gibt es genau zwei Möglichkeiten:
- es ist auf fhem Seite falsch (anders, komisch, linksdrehend, whatever) implementiert. Danan kann und wird es dort gelöst.
- der Webserver im sming macht Mist. Dann muss es da gelöst werden (bzw wir schauen wo work arounds liegen).
Lass uns das mal in Ruhe und systematisch eingrenzen ohne jetzt neue Baustellen aufzumachen. Ist doch immer so das Herrausforderungen in der Umsetzung auftauchen. Suchen, finden, beseitigen. Ganz easy !
Zitat
Solid steht weit oben auf der Liste - die Queue Geschichte wird evtl etwas dauern da ich mir noch nicht sicher bin, in welcher Schnitstelleebene ich eingreife, oder ob ich sogar die Queue aus der LED Library rausnehme und auf Anwendungsebene verschiebe
Ja, das wäre super. Soweit ich lese steht ja Dein echtes Leben im Augenblick sehr im Mittelpunkt. Passt. Solid wäre schön.
vg
joerg
Zitat von: herrmannj am 28 Juni 2016, 14:55:15
Ja, aber nicht verrennen bitte.
Hier gibt es genau zwei Möglichkeiten:
- es ist auf fhem Seite falsch (anders, komisch, linksdrehend, whatever) implementiert. Danan kann und wird es dort gelöst.
- der Webserver im sming macht Mist. Dann muss es da gelöst werden (bzw wir schauen wo work arounds liegen).
das halte ich, anhand des Packet Trace, für ausgeschlossen.
Wie gesagt: die Antwortpakete kommen beim fhem Server an, der kann sie nur nicht zeitig verarbeiten.
Zitat von: herrmannj am 28 Juni 2016, 14:55:15
Lass uns das mal in Ruhe und systematisch eingrenzen ohne jetzt neue Baustellen aufzumachen. Ist doch immer so das Herrausforderungen in der Umsetzung auftauchen. Suchen, finden, beseitigen. Ganz easy !Ja, das wäre super. Soweit ich lese steht ja Dein echtes Leben im Augenblick sehr im Mittelpunkt. Passt. Solid wäre schön.
das unterschreib ich - also Leben & Solid ;-)
Zitat von: herrmannj am 28 Juni 2016, 14:55:15
vg
joerg
pj
Zitat von: pjakobs am 28 Juni 2016, 14:49:20
ich bin gespannt.
Hier braucht's jetzt mehr fhem Kenntnis als ich habeder wird aber, z.B. der Doku, immer wieder erwähnt. Verwirrend.was wir wissen:
- diese Zeit steckt nicht in unsrem Modul sondern irgendwo in HttpUtils
- der Controller antwortet innerhalb von 25ms und das Paket geht auch beim Linux IP Stack ein (siehe tcpdump capture)
- HttpUtils http://192.168.29.58/color?mode=HSV: Got data, length: 16 kommt erst nachdem das letzte "set" abgeschickt wurde
Ich wette, wenn wir die Abfolge in einzelne fhem Kommandos zerlegen passt das alles.
Die fhem Doku sagt, dass Kommandozeilen (ich interpretiere: alles, was ich auf einen Schlag z.B. über das GUI Kommandoformularfeld absende) im "Haupt-Thread" ausgeführt werden - ich vermute: blocking.
ich schau mir mal HttpUtil ein bisschen an, mal sehen, wie asynchrone Events dort gehandhabt werden.Brexit feiern? ;)
Schau ich mir an und mache einen synchronen POC. Dann sehen wir das ganz genau. Ist auch kein rocketscience ;)
Zu "Haupt-thread": fhem ist primär singlle threaded. Es gibt Ausnahmen (fork) daher nicht ganaz schwarz weiß. Aber im Prinzip schon.
Ergo führt jedes sleep (und co) dazu das der haupptthread (aka fhem ;) blockiert. Alle guten Module implementieren daher Mechanismen um eventbasiert zu arbeiten. Httputils ist eines der Mittel. Dort wird eben nicht gesendet und auf die Antwort gewartet. Dort wird gesendet und dann die Controlle an den "Hauptthread" (aka fhem) zurückgegeben.
Wenn die Antwort kommt sorgt eine sllelect schleife in fhem.pl dafür das sie HTTPUtils die Antwort verarbeitet, die Callbacks geben dann die Ergebnisse in das aufrufende Module zurück.
Das alles hat aber überhauot nichts damit zu tun das zwischen Frage und Antwort 6 Sekunden vergehen ;) Ind er Theorie kommen da DNS bzw gethostbyname und co in Frage. Aber: wir werden das eingrenzen und lösen. versprochen ! ;)
vg
joerg
so, gerade nochmal schnell getestet, mit doppelt so langer Kommandozeile.
16:52:03.133670 fhem->controller [SYN]
16:52:03.207991 controller-fhem [SYN, ACK]
16:52:03.208139 fhem->controller [ACK]
16:52:15.076211 fhem->controller POST /color?mode=HSV HTTP/1.0
Host: 192.168.29.58
User-Agent: fhem
Accept: application/json
Content-Length: 90
Content-Type: application/x-www-form-urlencoded
{"cmd":"solid","d":"1","hsv":{"v":"0","ct":"2700","s":"50","h":"240"},"q":"false","t":"0"}
16:52:15.105670 controller-fhem HTTP/1.1 200 OK
Connection: close
Access-Control-Allow-Origin: *
Content-Length: 16
Content-Type: application/json
{"success":true}
also: doppelte Anzahl set Befehle führt inetwa zu doppelter Zeit.
pj
Ich habe jetzt mal bei mir nen mitschnitt von wireshark gemacht:
Die Befehle gehen von dem von mir geposteten python script raus - OS Win10
Script wurde als "coldstart" ausgeführt - sprich seit gestern Abend hat der Controller keine Befehle erhalten
No. Time Source Destination Protocol Info
1 0.000000 192.168.2.193 192.168.2.65 TCP 65274 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
2 0.004700 192.168.2.65 192.168.2.193 TCP 80 → 65274 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
3 0.004778 192.168.2.193 192.168.2.65 TCP 65274 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
4 0.004820 192.168.2.193 192.168.2.65 TCP [TCP segment of a reassembled PDU]
5 0.004885 192.168.2.193 192.168.2.65 HTTP POST /color HTTP/1.1
6 0.024562 192.168.2.65 192.168.2.193 HTTP HTTP/1.1 200 OK (application/json)
7 0.025308 192.168.2.193 192.168.2.65 TCP 65274 → 80 [FIN, ACK] Seq=256 Ack=139 Win=64102 Len=0
8 0.027191 192.168.2.193 192.168.2.65 TCP 65275 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
9 0.029994 192.168.2.65 192.168.2.193 TCP 80 → 65274 [FIN, ACK] Seq=139 Ack=257 Win=5584 Len=0
10 0.030040 192.168.2.193 192.168.2.65 TCP 65274 → 80 [ACK] Seq=257 Ack=140 Win=64102 Len=0
11 0.030774 192.168.2.65 192.168.2.193 TCP 80 → 65275 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
12 0.030875 192.168.2.193 192.168.2.65 TCP 65275 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
13 0.030925 192.168.2.193 192.168.2.65 TCP [TCP segment of a reassembled PDU]
14 0.030998 192.168.2.193 192.168.2.65 HTTP POST /color HTTP/1.1
15 0.057500 192.168.2.65 192.168.2.193 HTTP HTTP/1.1 200 OK (application/json)
16 0.059548 192.168.2.193 192.168.2.65 TCP 65275 → 80 [FIN, ACK] Seq=254 Ack=139 Win=64102 Len=0
17 0.065818 192.168.2.193 192.168.2.65 TCP 65276 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
18 0.085182 192.168.2.65 192.168.2.193 TCP 80 → 65275 [FIN, ACK] Seq=139 Ack=255 Win=5586 Len=0
19 0.085321 192.168.2.193 192.168.2.65 TCP 65275 → 80 [ACK] Seq=255 Ack=140 Win=64102 Len=0
20 0.085681 192.168.2.65 192.168.2.193 TCP 80 → 65276 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
21 0.085884 192.168.2.193 192.168.2.65 TCP 65276 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0
22 0.086094 192.168.2.193 192.168.2.65 TCP [TCP segment of a reassembled PDU]
23 0.086487 192.168.2.193 192.168.2.65 HTTP POST /color HTTP/1.1
24 0.105384 192.168.2.65 192.168.2.193 HTTP HTTP/1.1 200 OK (application/json)
25 0.106537 192.168.2.193 192.168.2.65 TCP 65276 → 80 [FIN, ACK] Seq=256 Ack=139 Win=64102 Len=0
26 0.109797 192.168.2.193 192.168.2.65 TCP 65277 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
27 0.110137 192.168.2.65 192.168.2.193 TCP 80 → 65276 [FIN, ACK] Seq=139 Ack=257 Win=5584 Len=0
Der Rest ist im Anhang - scheint mir entweder am OS bei euch zu liegen oder doch leider an Perl+FHEM(?) :(
Kann ich noch irgendwie unterstützen?
Zitat von: mrpj am 28 Juni 2016, 18:49:24
Der Rest ist im Anhang - scheint mir entweder am OS bei euch zu liegen oder doch leider an Perl+FHEM(?) :(
Dein Capture sieht aus wie ich es erwartet hätte.
Wie gesagt: meine Vermutung ist, dass wir den asynchronen Teil von fhem einfach aushungern, weil die Befehlszeile mit 50 set Befehlen "in einem Rutsch" bearbeitet wird.
Das ist aber eigentlich ein Randgruppenproblem.
Deine Idee mit den Animationsets wird das sowieso beheben, denn ich denke, die wird man vorab hochladen und dann nur noch aktivieren?
Ich hab den Verdacht, dass das Problem (für uns) verschwindet, wenn Jörg den synchronen Funktionsaufruf einbaut. Alles Andere, was in der Zeit passieren will / soll fällt dann immer noch flach.
Ich überlege gerade was eigentlich mit DOIFs / NOTIFYs passiert, die in diesen Sekunden auftreten. Abgearbeitet werden sie mit ziemlicher Sicherheit nicht. Ich denke, das ist eine Designschwäche von fhem und möglicherweise wäre es sogar leicht zu lösen, wenn man bei jedem ";" in der Befehlskette kurz die Kontrolle an den Dispatcher abgibt.
Grüße
pj
Zitat von: uniqueck am 28 Juni 2016, 19:58:50
Kann ich noch irgendwie unterstützen?
Wenn Du magst, schau doch mal durch den Code des aktuellen -queue branches bzw. fork Dir den, da sind sicher noch ein paar parameter bounds checks zu machen und so'n Kleinkram.
Was ich auch noch gerne machen würde ist: ich fänd's gut, wenn das Readings Zeug irgendwo zentral wäre.
Da gibt's auch zweierlei aus meiner Sicht:
1. die Readings, wie das Modul sie sieht (gerade, wenn eine queue aufgebaut wird, dann sind die entsprechenden Farbwerte ja "in der Zukunft", sprich: folgen der queue wie sie entsteht)
2. aktuelle Readings
Ich würde eigentlich auch gerne zum Initialisationszeitpunkt den Controller nach seinem Zustand fragen, und die rgb/hsv Readings entsprechend setzen.
Auch noch zu machen wären die set / get commands für RAW
und ne tolle Baustelle, an die ich mich noch nicht rangetraut habe ist: können wir die gazen System Sachen des Controllers machen? OTA wäre sicher das interessanteste.
Ich könnte mir aber auch vorstellen, dass mein RaspberryPi einen zweiten WLAN Stöpsel bekommt, der den AP des Controllers joined und den dann automatisch für das eigentliche Netzwerk konfiguriert. (bei 35 Stück wird das langsam interessant ;D)
Aber wie gesagt: zentrales OTA fänd ich klasse.
Ideen gibt's noch viele, denk ich.
ich fürchte, dass ich beim mergen mit develop ganz fürchterlich Chaos produzieren werden... git ist nicht so meine Stärke... :-)
Hi,
ich habe das Modul eingebunden und es funktioniert auch so weit ich das beurteilen kann.
Ich habe in einem anderen Blog eine andere WebCmd-Anzeige gesehen die mir sehr gut gefallen würde. Weiß jemand wie ich das konfigurieren kann? Es wurde das Modul WifiLight verwendet. Ich denke aber es sind nur ein paar zusätzliche Attribute die für WebCmd gesetzt werden müssen.
Link zum Blog ... http://www.meintechblog.de/2014/05/die-hue-alternative-preiswert-die-lichtstimmung-im-smart-home-pimpen/ (http://www.meintechblog.de/2014/05/die-hue-alternative-preiswert-die-lichtstimmung-im-smart-home-pimpen/)
Die Möglichkeit per Slider zu dimmen, und vordefinierte Farben als Button zu haben hat was. Siehe angehängte Grafik.
Kann mir jemand auf die Sprünge helfen? Vielleicht gibt es irgendwo eine Doku oder ein Beispiel.
Danke schon mal.
Hallo kadettilac89
sehr schön wenn sich das modul für Dich schon als nützlich erweist.
Der Entwicklungsstand ist noch sehr früh. Bitte Themen wie GUI / Slider noch ignorieren. Die Entwicklung des Moduls ist noch nicht an diesem Punkt. Es werden sich intern noch so viele Sachen ändern das es zu früh ist sich damit zu beschäftigen.
vg
joerg
Zitat von: kadettilac89 am 29 Juni 2016, 12:13:59
Hi,
ich habe das Modul eingebunden und es funktioniert auch so weit ich das beurteilen kann.
Ich habe in einem anderen Blog eine andere WebCmd-Anzeige gesehen die mir sehr gut gefallen würde. Weiß jemand wie ich das konfigurieren kann? Es wurde das Modul WifiLight verwendet. Ich denke aber es sind nur ein paar zusätzliche Attribute die für WebCmd gesetzt werden müssen.
Link zum Blog ... http://www.meintechblog.de/2014/05/die-hue-alternative-preiswert-die-lichtstimmung-im-smart-home-pimpen/ (http://www.meintechblog.de/2014/05/die-hue-alternative-preiswert-die-lichtstimmung-im-smart-home-pimpen/)
Die Möglichkeit per Slider zu dimmen, und vordefinierte Farben als Button zu haben hat was. Siehe angehängte Grafik.
Kann mir jemand auf die Sprünge helfen? Vielleicht gibt es irgendwo eine Doku oder ein Beispiel.
Danke schon mal.
Du kannst den fhem colorpicker mittels
attr LED_Wo webCmd rgb
attr LED_Wo widgetOverride rgb:colorpicker,rgb
einbinden - der allerdings kennt keine vordefinierten Farben.
Wenn Du mehr als einen Controller einbindest solltest Du dafür imho sowieso über "lightscenes" nachdenken, dann könntest Du die Farben bzw. Farbstimmungen mehrerer Stripes in einer Lightscene konfigurieren und die per Button / Event etc schalten.
Ich verwende heute zur Steuerung ein billiges Lenovo Tablet (hat 60EUR gekostet), das am Schrank hängt und über TabletUI alle Elemente steuert. Die Lampen nutzen folgendes Widget:
<div class="row container round bg-gray">
<div data-type="switch" data-device='LED_Wo' data-on-background-color="LED_Wo:rgb" data-get-on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="small col-1-4"> </div>
<div class="col-1-2">Wohnzimmer Couch</div>
<div data-type="symbol" id="ST_Wo" data-device='LED_Wo' data-get="" data-off-color="LED_Wo:rgb" data-off-background-color="LED_Wo:rgb" data-icon="fa-ellipsis-h" data-background-icon="fa-circle- thin" class="small">
</div>
<div data-type="popup" data-height="320px" data-width="320px" data-mode="animate" data-starter="#ST_Wo" class="col-1-6">
<div class="dialog">
<header>RBG COLOR</header>
<div data-type="colorwheel" data-device='LED_Wo' data-get="rgb" data-set="rgb" class="big roundIndicator">
</div>
</div>
</div>
Grüße
pj
btw, ich "rupf" gerade im Modul rum. Ich habe mich gegen synchron entschieden sondern mach gleich einen (hoffentlich) besseren asynchron.
vg
joerg
Zitat von: herrmannj am 29 Juni 2016, 12:52:06
btw, ich "rupf" gerade im Modul rum. Ich habe mich gegen synchron entschieden sondern mach gleich einen (hoffentlich) besseren asynchron.
vg
joerg
ich bin gespannt!
pj
Na ich erst :-D
ZitatDu kannst den fhem colorpicker mittels
....
einbinden - der allerdings kennt keine vordefinierten Farben.
Indirekt falsch :D Colorpicker kenn wirklich keine, aber FHEM-WEB kanns trotzdem gg
So gibts auch vordefinierte Farben:
attr LED_Wo webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb 000000
attr LED_Wo widgetOverride rgb:colorpicker,rgbUnd sogar ein "Schwarz=Aus" ist mit dabei :D
lg, Stefan
Zitat von: Icinger am 29 Juni 2016, 13:39:08
Indirekt falsch :D Colorpicker kenn wirklich keine, aber FHEM-WEB kanns trotzdem gg
So gibts auch vordefinierte Farben:
attr LED_Wo webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb 000000
attr LED_Wo widgetOverride rgb:colorpicker,rgb
Und sogar ein "Schwarz=Aus" ist mit dabei :D
lg, Stefan
super! Wieder was gelernt!
Danke
pj
Zitat von: herrmannj am 29 Juni 2016, 12:46:08
Hallo kadettilac89
sehr schön wenn sich das modul für Dich schon als nützlich erweist.
Der Entwicklungsstand ist noch sehr früh. Bitte Themen wie GUI / Slider noch ignorieren.
War nicht als Kritik gedacht sondern ging davon aus, dass es irgendwie mit webcmd im Default geht.
Zitat von: Icinger am 29 Juni 2016, 13:39:08
Indirekt falsch :D Colorpicker kenn wirklich keine, aber FHEM-WEB kanns trotzdem gg
So gibts auch vordefinierte Farben:
attr LED_Wo webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb 000000
attr LED_Wo widgetOverride rgb:colorpicker,rgb
Und sogar ein "Schwarz=Aus" ist mit dabei :D
lg, Stefan
Vielen Dank! Das meinte ich ... Slider warte ich bis herrmannj soweit ist.
ZitatWar nicht als Kritik gedacht sondern ging davon aus, dass es irgendwie mit webcmd im Default geht.
Oh - Alles gut. Das hatte ich auch keinesfalls so aufgefasst. Ich wollte Dich vor dem Frust bewahren jetzt alles einzurichten und dann in einigen Tagen alles wieder neu, evtl sogar anders, machen zu müssen. Alles jut :)
vg
joerg
Zitat von: herrmannj am 29 Juni 2016, 15:01:13
Oh - Alles gut. Das hatte ich auch keinesfalls so aufgefasst. Ich wollte Dich vor dem Frust bewahren jetzt alles einzurichten und dann in einigen Tagen alles wieder neu, evtl sogar anders, machen zu müssen. Alles jut :)
vg
joerg
aktuell hab ich allles was ich brauch. Dimmen erstmal über Color-picker. Sogar endloser Farbwechsel funktioniert :)
Zitat von: herrmannj am 29 Juni 2016, 15:01:13
Oh - Alles gut. Das hatte ich auch keinesfalls so aufgefasst. Ich wollte Dich vor dem Frust bewahren jetzt alles einzurichten und dann in einigen Tagen alles wieder neu, evtl sogar anders, machen zu müssen. Alles jut :)
vg
joerg
na ja, mal abgesehen von groß/KLEINschreibung sollte das Interface doch mehr oder weniger gleich bleiben, ich würde es jedenfalls versuchen wollen. Bei Readings (und m.E. damit automatisch bei Settings) hatten wir uns auf Kleinschreibung geeinigt, oder?
@kadettilac89 ich denke, Du kannst hsv und rgb auf alle Fälle verwenden.
Die erweiterten Möglichkeiten werden sich sicher hie und da noch ändern, und so ein paar Dinge sind gewiss noch buggy, aber ich habe jetzt einen Teil meiner täglich genutzten Beleuchtung darauf umgestellt - habe also durchaus ein Interesse immer eine funktionsfähige Version zu liefern :-)
Grüße
pj
Hallo ihr,
ich hab heute mal mich mit dem "solid" Bug auseinander gesetzt und den Fehler behoben. Bevor ich die auf Github pusche, dachte ich mir, ich lass euch das mal testen. Im Anhang ist also das aktuellste rom.
Folgender python code läuft bei mir einwandfrei:
- fade von schwarz nach HSV(0, 100, 100) in 1 Sekunde
- bleibe bei HSV(0, 100,100) für 2 Sekunden
- fade auf HSV(60, 100, 100) in 1 Sekunde
- bleibe bei HSV(60, 100, 100) für 4 Sekunden
- fade auf HSV(210, 100, 100) in 10 Sekunden
- bleibe bei HSV(210, 100, 100) für 10 Sekunden
- schwarz
import requests
import json
import time
solid1 = {"hsv":{"h":0.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":2000, "q": 1}
solid2 = {"hsv":{"h":60.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":4000, "q": 1}
solid3 = {"hsv":{"h":210.0,"s":100.0,"v":100.0,"ct":0},"cmd":"solid", "t":10000, "q": 1}
fade1 = {"hsv":{"h":0.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}
fade2 = {"hsv":{"h":60.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}
fade3 = {"hsv":{"h":210.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":10000, "q": 1}
black1 = {"hsv":{"h":0.0,"s":100.0,"v":0.0,"ct":0},"cmd":"solid", "t":20, "q": 1}
black3 = {"hsv":{"h":210.0,"s":100.0,"v":0.0,"ct":0},"cmd":"solid", "t":20, "q": 1}
if __name__ == '__main__':
r = requests.post(url, data=json.dumps(black1))
r = requests.post(url, data=json.dumps(fade1))
r = requests.post(url, data=json.dumps(solid1))
r = requests.post(url, data=json.dumps(fade2))
r = requests.post(url, data=json.dumps(solid2))
r = requests.post(url, data=json.dumps(fade3))
r = requests.post(url, data=json.dumps(solid3))
r = requests.post(url, data=json.dumps(black3))
PS:
Das Update führt noch eine Erweiterung für /color ein: es ist nun möglich von einer definierten Farbe auf die Endfarbe zu Faden:
Beispiel:
{
"hsv": {
"h": 200.0,
"s": 100.0,
"v": 100.0,
"ct": 2700,
"from": {
"h": 10.0,
"s": 100.0,
"v": 100.0,
"ct": 2700,
}
},
cmd: "fade",
"t": 600,
"q": false,
"d": 1
}
Ist z.B. Hilfreich beim faden von einem "Aus" (schwarz) Zustand auf einen "An" Zustand wenn sich der H Wert ändern würde. Z.b. wenn man der alte Wert im Controller noch HSV(60, 100, 0) ist - man nun aber eigentlich auf die Farbe HSV(210, 100, 100) "anschalten" möchte. Zuvor würde der Controller von dem alten Hue Wert faden - nun ist es einfach möglich zu sagen, fade von HSV(210, 100, 0) auf HSV(210, 100, 100)
Ich hab es nur schnell getestet - Feedback und eigene Erfahrung gerne gesehen
klasse! ich hab heute eh gerade einen neuen Controller gelötet, ich werd das morgen testen.
danke & Grüße
pj
@mrpj: super, Danke!
@pjakobs
Der Umbau am modul ist so etwas umfangreicher.
Der asynchrone call ist soweit angelegt. Als nächtes queue ich die set, parametriere die api call (gehen jetzt statisch auf /info) und bau den parser für die Antworten rein.
Ein call sieht jetzt so aus:
2016.06.30 00:54:42.521 4: led: API call init
2016.06.30 00:54:42.525 4: led: connected
2016.06.30 00:54:42.525 4: led: send 49 from 49 chars
2016.06.30 00:54:42.539 4: led: recv 464 chars
2016.06.30 00:54:42.539 4: led: response code is 200
2016.06.30 00:54:42.539 4: led: response length is 341
2016.06.30 00:54:42.539 4: led: close connection
damit bin ich sehr zufrieden.
vg
joerg
Zitat von: herrmannj am 30 Juni 2016, 01:00:48
@mrpj: super, Danke!
@pjakobs
Der Umbau am modul ist so etwas umfangreicher.
Der asynchrone call ist soweit angelegt. Als nächtes queue ich die set, parametriere die api call (gehen jetzt statisch auf /info) und bau den parser für die Antworten rein.
Ein call sieht jetzt so aus:
2016.06.30 00:54:42.521 4: led: API call init
2016.06.30 00:54:42.525 4: led: connected
2016.06.30 00:54:42.525 4: led: send 49 from 49 chars
2016.06.30 00:54:42.539 4: led: recv 464 chars
2016.06.30 00:54:42.539 4: led: response code is 200
2016.06.30 00:54:42.539 4: led: response length is 341
2016.06.30 00:54:42.539 4: led: close connection
damit bin ich sehr zufrieden.
vg
joerg
wenn ich das richtig sehe, hast Du die Queue jetzt auf der Kommando, nicht mehr der API Ebene angelegt?
pj
Zitat von: pjakobs am 30 Juni 2016, 09:20:47
wenn ich das richtig sehe, hast Du die Queue jetzt auf der Kommando, nicht mehr der API Ebene angelegt?
pj
Wie jetzt ?
Das log sind api calls. Knapp 200msec, trotzdem async. Zwischen jedem Eintrag ist "Platz".
vg
joerg
Gibt es von euch beiden Feedback zur Firmware? Wenn es keine Probleme mehr gibt pushe ich am Wochenende den neuen Release :)
sorry, konnte niich nicht testen.
Kann ich die eigentlich auch schon ota aufspielen ?
Danke vg
joerg
Ja - muss nur auf nem eigenen server gehostet werden ;).
Python tool dazu ist im git repository:
https://github.com/patrickjahns/esp_rgbww_firmware/tree/master/tools
Rom und Spiffs (von der vorherigen Firmware) in das selbe Verzeichnis wie das Python script und der updateserver ist dann unter http://computerip/version.json erreichbar.
Zitat von: mrpj am 01 Juli 2016, 16:14:02
Ja - muss nur auf nem eigenen server gehostet werden ;).
Python tool dazu ist im git repository:
https://github.com/patrickjahns/esp_rgbww_firmware/tree/master/tools
Rom und Spiffs (von der vorherigen Firmware) in das selbe Verzeichnis wie das Python script und der updateserver ist dann unter http://computerip/version.json erreichbar.
hmm.. ich bekomme zwar die Dateien angezeigt, aber nicht die Versionen - was fehlt mir?
{"rom": {"fw_version": "unknown", "url": "http://192.168.29.15:88/rom0.bin"}, "spiffs": {"url": "http://192.168.29.15:88/spiff_rom.bin", "webapp_version": "unknown"}}
pj
so, OTA vom lokalen Server hat funktioniert. Ich hab im fhem Modul den "pause" Befehl wieder auf "solid" umgebaut und - jetzt scheint das auch zu funktionieren. Das Timing ist noch etwas unvorhersagbar, aber ich bin mir nicht sicher, ob das am Queueing liegt, ich warte mal, was Jörg in der Hinterhand hat.
[edit]
ich hab mir auch gerade das Verhalten, beim Disconect / Reconnect des konfigurierten Netzwerkes angesehen.
WLAN Verbindung geht verloren: AP wird gestartet
WLAN wieder verfügbar: AP Wird abgeschaltet, Verbindung wieder hergestellt.
top!
Danke für's Update, Patrick!
pj
Zitat von: pjakobs am 02 Juli 2016, 10:16:53
hmm.. ich bekomme zwar die Dateien angezeigt, aber nicht die Versionen - was fehlt mir?
{"rom": {"fw_version": "unknown", "url": "http://192.168.29.15:88/rom0.bin"}, "spiffs": {"url": "http://192.168.29.15:88/spiff_rom.bin", "webapp_version": "unknown"}}
Das updateserver tool ist einfach gehalten und daher parst es weder die ROM noch das SPIFFS nach Versionsnummern, sondern gibt direkt unknown aus.
Wenn das Tool die Versionsnummer auslesen würde, wäre das sicher "nice to have", aber nötig zum updaten ist es nicht. ;)
Zitat von: pjakobs am 02 Juli 2016, 10:37:41
so, OTA vom lokalen Server hat funktioniert. Ich hab im fhem Modul den "pause" Befehl wieder auf "solid" umgebaut und - jetzt scheint das auch zu funktionieren. Das Timing ist noch etwas unvorhersagbar, aber ich bin mir nicht sicher, ob das am Queueing liegt, ich warte mal, was Jörg in der Hinterhand hat.
Nutze doch als Vergleich das python script von mir. Wenn es bei dem einfachen script einwandfrei funktioniert, dann liegt es noch an dem queueing in fhem.
So am Rande:
Ich hatte nicht gedacht dass die Anbindung an FHEM so kompliziert sein kann.
Auch die Verarbeitungszeit von 20ms im Controller ist etwas hoch - ein Teil davon sind die Debug Nachichten via Serial - das ist leider blocking
Zitat von: mrpj am 02 Juli 2016, 13:50:07
Nutze doch als Vergleich das python script von mir. Wenn es bei dem einfachen script einwandfrei funktioniert, dann liegt es noch an dem queueing in fhem.
ich sehe ja am Log / Trace, dass das immer noch das Verhalten der ersten Queue Implemenation ist.
Zitat von: mrpj am 02 Juli 2016, 13:50:07
So am Rande:
Ich hatte nicht gedacht dass die Anbindung an FHEM so kompliziert sein kann.
ich denke, @herrmanj kann dazu mehr sagen, mein Verständnis ist:: fhem ist darauf angewiesen, dass eine Zentralschleife häufig genug aufgerufen wird. Das Parsen einer einzelnen Kommandozeile läuft aber in einem Stück, alles, was darin passiert muss also durchlaufen werden, bevor wieder andere Aufgaben erledigt werden. Andere Aufgaben sind eben auch alles asynchrone. Ist wohle in bisschen unglückliches Design.
Zitat von: mrpj am 02 Juli 2016, 13:50:07
Auch die Verarbeitungszeit von 20ms im Controller ist etwas hoch - ein Teil davon sind die Debug Nachichten via Serial - das ist leider blocking
um 20ms mach ich mir erstmal keine Sorgen - wenn es asynchron ist.
pj
Ich greife diesen Punkt aus dem anderen Thread (https://forum.fhem.de/index.php/topic,48918.msg469425.html#msg469425) mal auf:
Zitat
eventuell ein HSV+WW/CW? Damit ließe sich theoretisch die dreifache Weiß-Helligkeit erreichen, auf Kosten der Farbqualität. Im Grunde wäre das nur eine Abwandlung des RAW Modes
Dieses Feature fände ich sehr gut, da ich damit mit nur einem Controller einen RGB und einen getrennten WW Stripe steuern könnte. Die möchte ich unabhängig von einander ansteuern.
Bisher geht das ja nur mit zwei unabhängigen Controllern.
Zitat von: kaihs am 05 Juli 2016, 21:31:20
Ich greife diesen Punkt aus dem anderen Thread (https://forum.fhem.de/index.php/topic,48918.msg469425.html#msg469425) mal auf:
Dieses Feature fände ich sehr gut, da ich damit mit nur einem Controller einen RGB und einen getrennten WW Stripe steuern könnte. Die möchte ich unabhängig von einander ansteuern.
Bisher geht das ja nur mit zwei unabhängigen Controllern.
Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.
Dazu müsste ich dann ansich auch 10 Bit Readings einbauen, das könnte etwas unübersichtlich werden:
h [0-255]
s [0-255]
v [0-255]
rgb [0x000000-0xffffff]
r10 [0-1023]
g10 [0-1023]
b10 [0-1023]
ww10 [0-1023]
cw10 [0-1023]
rgb10 [0x000000000-0x03ff03ff03ff]
ziemlich unelegant, finde ich, zumal die Werte nicht mehr eineindeutig sind. Der worauf sollte sich der hsv Wert beziehen, wenn ich r10, g10, b10, ww10, cw10 gesetzt habe? Nur auf rgb? oder auch auf hsv?
Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.
pj
hoffentlich ist @herrmannj nicht der Himmel auf den Kopf gefallen!
Nö, alles jut.
War auch einer doch recht anstrengenden Geschäftsreise - ich konnte aber schon ein wenig weitermachen. Bin dabei den async call noch schöner zu machen, inkl dns und so. Auch mit fw update und co. Ist state-of-the-art. Das POC modul äuft ja soweit, brennt doch nix an - oder. ?
vg
joerg
och, war nur verwundert.
magst Du nicht mal einen Zwischenstand pushen? Ich bin so außenvor, und würde nebeinbei gerne testen, ob pause (bzw. solid) jetzt auch in längeren queues funktioniert.
pj
yepp gern. Der Umbau bedingt das im Augenblick ausser viel logging nix passiert. Ich stell die nächste die Funktion bieten rein. Wird aber eher gegen WE
vg
joerg
Zitat von: pjakobs am 06 Juli 2016, 22:03:42
Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.
Dazu müsste ich dann ansich auch 10 Bit Readings einbauen, das könnte etwas unübersichtlich werden:
h [0-255]
s [0-255]
v [0-255]
rgb [0x000000-0xffffff]
r10 [0-1023]
g10 [0-1023]
b10 [0-1023]
ww10 [0-1023]
cw10 [0-1023]
rgb10 [0x000000000-0x03ff03ff03ff]
ziemlich unelegant, finde ich, zumal die Werte nicht mehr eineindeutig sind. Der worauf sollte sich der hsv Wert beziehen, wenn ich r10, g10, b10, ww10, cw10 gesetzt habe? Nur auf rgb? oder auch auf hsv?
Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.
pj
Hi Pjakobs,
ich denke was du vorhast ist die eierlegende Wollmilchsau wie es so schön heißt. Ich denke das ist nicht bedienbar abzubilden.
Meine Empfehlung wäre das hier der Controller durch das Modul 2 Funktionen bekommt
- reiner RGB wie jetzt schon abgebildet
- reiner Weiß-Modus
So ähnlich ist es auch bei HUE gelöst wenn ich mich nicht irre. Das RGB hat schon 3 Dimensionen. Wenn jetzt auch noch die CW/WW mit Helligkeit eingearbeitet werden soll ... gäbe es dann noch weitere Farbflächen und Schieberegler hinter dem RGB-Picker?
Wie ich mir das vorstellen könnte
- wie beim RGB-Picker ein Quadrat das hier nur CW/WW hex abgreift. x-Achse ist links CW, rechts WW. Y-Achse ist Helligkeit.
- beim Umschalten zwischen RGB und Weißmodus wird kein Fading durchgeführt da es der Controller nicht implementiert hat
- Parameter der angibt ab wieviel Prozent CW/WW gefadet wird
-- Bei 100 Fading wäre die Helligkeit immer gleich
-- Bei 50 Fading würde erst bei Schieberegler 50% abnehmend die Helligkeit reduziert. Dadurch kann maximale Helligkeit erzielt werden. Helligkeitsunterschiede müssen dann akzeptiert werden.
Ist schwer zu erklären. Habe eine Grafik erstellt, vielleicht ist es besser verständlich. 0-100% ist mit einem Schieberegler zu verglichen. 0% wäre 100% CW, 50% ist die Mitte, 100% wäre 100%WW.
Wie das intern abgebildet wird ist dann zweitrangig. Hex mit 256, 100% oder in wie vielen bit auch immer.
Man könnte die WebCmd eine RGB-Picker, CW/WW-Picker, Ein-Aus verpassen dann wäre das aus Sicht Usability verständlich. Durch 2 separate Picker ist auch vom Ablauf ersichtlich dass hier 2 verschiedene Dinge dahinter liegen.
Zitat von: pjakobs am 06 Juli 2016, 22:03:42
Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Ich hatte eher an unterschiedliche Modi gedacht:
RGB/CW/WW, Einstellungen beziehen sich auf alle Kanäle, Farben werden aus allen Kanälen gemischt (geht ja aktuell schon)
nur RGB (geht auch schon)
RGB CW WW, die drei Bereiche sind getrennt steuerbar, d.h. Farbeinstellungen gehen nur auf RGB, CW und WW lassen sich getrennt aber nur in der Helligkeit steuern.
Zitat von: pjakobs am 06 Juli 2016, 22:03:42
Ich hab bei mir schon ne Version mit RAW support laufen, allerdings hab ich noch keine klare Idee, wie ich die Readings abbilde.
Momentan verwenden wir ja hsv und rgb mit 8-Bit Werten und die sind immer äquivalent, weil wir rgb in hsv umrechenen.
Bei RAW habe ich 1. 10 Bit rgb Werte und 2. zusätzlich bis zu 2x 10 Bit weiß. Daraus einen vernünftigen hsv Wert zu rechnen mag mir gerade nicht einfallen. Vielleicht frage ich einfach den Controller, was er errechnet hat.
Aus RAW errechnet der Controller keine weiteren Werte. RAW bedeutet übersetzt: direkte Steuerung der Ausgangsleistung des Kanals - der Nutzer dieses Modus ist selbst für seine Ansteuerung verantwortlich und der Controller hält sich dabei raus.
Einzig bietet der Controller noch die Möglichkeit, statt den Wert direkt zu setzen, den Wert per Fade über t zu setzen.
Ich habe mir wirklich lange den Kopf zerbrochen und überlegt, wie man ein Berechnungsmodell erweitern kann, damit 5 Kanäle wieder in HSV inklusive Kelvin Wert umgerechnet werden können. Es ist mit den reinen Werten einfach nicht möglich, ohne Gewisse Vorannahmen zu treffen, oder weitere Informationen zu haben.
Zitat von: pjakobs am 06 Juli 2016, 22:03:42
Eigentlich denke ich, ich möchte den RAW Modus ganz unabhängig vom hsv Modus halten.
Genau so war es von meiner Seite aus gedacht - RAW und HSV funktionieren getrennt voneinander. Es gibt zwar die Möglichkeit nach einem HSV Wert die Ansteuerung der Kanäle (RAW) auszulesen, weil es eine Umrechnungsbasis gibt - dies gilt aber nicht in die andere Richtung.
Sprich wer einmal mit RAW anfängt, sollte vor der Benutzung mit HSV einen gültigen Wert für HSV als Startpunkt setzen - sonst wird es schlichtweg einfach nix ;)
Hallo mrpj
ZitatEinzig bietet der Controller noch die Möglichkeit, statt den Wert direkt zu setzen, den Wert per Fade über t zu setzen.
Ich bin sichtlich nicht up-to-date. Magst Du das kkurz erklären bitte ?
ZitatSprich wer einmal mit RAW anfängt, sollte vor der Benutzung mit HSV einen gültigen Wert für HSV als Startpunkt setzen - sonst wird es schlichtweg einfach nix ;)
Dito, angenommen ich setzte ra ff,ff,ff,ff,ff,ff und für danach ein set hsv 0,100,0 aus. Was würde passieren (nicht im detail)
a: garnichts (Befehl geht ins nirvana)
b: irgendwas (unpredictable)
Danke vg
joerg
Zitat von: herrmannj am 08 Juli 2016, 11:54:13
Ich bin sichtlich nicht up-to-date. Magst Du das kkurz erklären bitte ?
Wie bei HSV kann der Controller bei RAW den neuen Wert "faden". Sprich mann kann von RAW(0,0,0,0,0) auf RAW(100,20,30,0,0) faden über Zeit t.
Hier verhält sich der Controller gleich zu HSV - nur werden keine HSV Werte berechnet, sondern eben die einzelnen Kanal Werte erhöht/verringert
(Der Wechsel von HSV -> RAW ist dabei möglich - da jeder HSV Wert einen Ausgangswert (RAW) erzeugt)
Zitat von: herrmannj am 08 Juli 2016, 11:54:13
Dito, angenommen ich setzte ra ff,ff,ff,ff,ff,ff und für danach ein set hsv 0,100,0 aus. Was würde passieren (nicht im detail)
a: garnichts (Befehl geht ins nirvana)
b: irgendwas (unpredictable)
b ;)
Bzw. der Controller nimmt den letzten ihm genannten HSV Wert als Startpunkt für den HSV Fade (wenn keiner bekannt ist es HSV(0,0,0)).
Andernfalls empfiehlt es sich, zuerst einen HSV Wert ohne Übergang zu setzen (solid) und danach seinen Fade zu starten.
Oder direkt dem Controller den Befehl übergeben: Fade von HSV(X,Y,Z) zu HSV(A,B,C)
ich denke fast, es ist am Besten, wenn wir das Modul entweder als raw oder als hsv betreiben. Es gibt keinen sinnvollen Übergang zwischen den Modi und vermutlich sind es auch unterschiedliche Installationen, was also spricht dagegen, von vornherein entweder ein rgb oder ein hsv API anzubieten?
Viele der Funktionen im aktuellen hsv-Mode sind im raw-Mode so oder so hinfällig, set hue, sat, val, rotate ergeben kein definiertes Ergebnis, dim, on und off müssten ganz anders implementiert werden.
Ich denke, ein attr, das zwischen hsv und raw betrieb unterscheidet wäre eine ganz elegante Lösung.
pj
Hi,
eine Unterscheidung zwischen RAW und HSV mittels Attribut würde mir nicht gefallen: ich möchte den Controller vorrangig im HSV-Modus einsetzen, aber wenn ich mal richtig Licht brauche, wünsche ich mir per RAW die Möglichkeit, alles einzuschalten...
Ronny
@RoBra81 das wäre imho kein Widerspruch, denn Du könntest das attr ja setzen, der Controller würde dann den Modus wechseln (und z.B. einen vordefinierten hsv / rgbww Wert setzen) und gut is.
Natürlich würde das die entsprechenden Widgets stören, aber die sind so oder so nicht brauchbar, wenn Du raw Werte setzt.
pj
Ich denke aber, dass es nicht FHEM-Standard ist, ein Attribut zu setzen um etwas zu schalten...
Man könnte beim Define angeben, ob es als "RAW" oder als "HSV"-Device werkeln soll.
Dann kann man parallel immer noch ein zweites device mit der selben Adresse anlegen als gegenpart dazu, oder?
lg, Stefan
@Icinger
hmm...
es gibt zwei Dinge, die ich da behandeln möchte:
1. in den beiden Modi gibt es unterschiedliche gültige Readings. Idealerweise sind nur die jeweils gültigen sichtbar
2. ein Wechsel von einem Modus in den anderen führt nicht in allen Fällen zu einem definierten Startpunkt wie vom @mrpj beschrieben (raw->hsv hat keine gültige Einstellung)
1. könnte man mit zwei unabhängigen Devices abbilden, aber 2.? Da wäre eine Modusumschltunge ideal. Wobei das natürlich auch das Problem hat, dass ich die ungültigen Readings nicht einfach verschwinden lassen kann.
Hallo,
ich hatte ab und an den Fall, dass ein Controller sich aufgehangen hat. Daher frage ich mich, ob man in das Modul einen Health-Check einbauen kann, also alle x Minuten/Stunden automatisch geprüft werden kann, ob der Controller erreichbar ist und dies in einem Reading dargestellt werden kann. Dies ist ja z.B. bei yowsup, Sonos, HM oder der Fritzbox und bestimmt vielen anderen Devices auch üblich. Man könnte dann z.B. auch eine Schaltsteckdose, an der der Controller hängt aus und wieder einschalten, um ihn neu zu starten.
Gruß
Torben
Ja, gute Idee. Ist hiermit auf to-do
vg
joerg
hoi Jörg,
hast Du was neues zum queueing?
pj
In Arbeit. Bin aber erst September wieder in de.
VG
Jörg
Guten Morgen.
Gibt es zum Modul schon etwas neues?
Gerade die Möglichkeit der Farbwahl oder das direkte schalten von WW oder CW wären mir sehr wichtig.
Hi Olli,
ich habe meine Controller so in fhem eingebunden:
define LED_Wo LedController 192.168.29.55
attr LED_Wo colorTemp 2700
attr LED_Wo defaultColor 0,10,80
attr LED_Wo defaultRamp 6000
attr LED_Wo room Licht,Wohnzimmer
attr LED_Wo verbose 5
attr LED_Wo webCmd rgb:rgb ffdb4a:rgb ff0000:rgb 80eeff:rgb 00ff00:rgb 0000ff: rgb 000000
attr LED_Wo widgetOverride rgb:colorpicker,rgb
Damit kann ich sie über den colorpicker oder einige Farbschalter ansprechen.
Hast Du RGBWWCW Strips am Controller? Ich hatte die Farbtemperatur als attr, nicht als Setting angelegt, weil ich davon ausgehe, dass man grundsätzlich eine Farbtemperatur vorgibt.
Als Workaround würde ich vorschlagen, dass Du das attr "colorTemp" setzt und dann mit einer kleinen Änderung der Helligkeit aktivierst.
Aber: die Farbtemperatur hat imho nur Bedeutung, wenn warmweiß und kaltweiß LED dran hängen.
pj
Hi.
Danke für deine Antwort.
Kann es sein, dass du ein anderes Modul benutzt, als das auf GitHub?
Ich habe nämlich als einziges Attribut, welches ich setzen kann defaultRamp ???
32_LedController.pm 0 2016-05-01 12:00:00Z herrmannj
Hi Oli,
pull mal dev-pj, das ist meine aktuelle Version, die tatsächlich ein bisschen mehr Funktionen bietet.
pj
Danke.
Scheint zu laufen!
Heute Abend mal testen, aber bereits jetzt geht mehr als zuvor ;)
Allerdings habe ich nun auch ein paar Warnings:
PERL WARNING: Use of uninitialized value $a in concatenation (.) or string at /opt/fhem/FHEM/32_LedController.pm line 199.
2016.09.27 15:37:26 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at /opt/fhem/FHEM/32_LedController.pm line 199.
2016.09.27 15:37:26 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at /opt/fhem/FHEM/32_LedController.pm line 212.
2016.09.27 15:37:26 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at /opt/fhem/FHEM/32_LedController.pm line 213.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 91.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at /opt/fhem/FHEM/32_LedController.pm line 93.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 95.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 101.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 114.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 127.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 140.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 149.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 158.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 167.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 178.
2016.09.27 15:38:05 1: PERL WARNING: Use of uninitialized value $cmd in string eq at /opt/fhem/FHEM/32_LedController.pm line 190.
das sieht aus, wie ein Aufruf mit ohne Kommando (also nur ein set <devicename> )
seltsam.
Passierte nach "set RGBWW.o off"
merkwürdig.
Möglicherweise hab ich nicht die neueste Version gepusht....
Die Fehler kommen aus der Funktion "ArgsHelper", die die erweiterten Argumente Queue (q), Long (l) und Time (numerisch) auswertet.
Du könntest ja schreiben
set RGBWW.o off 1000 q
was bedeuten würde, dass der Controller über 1000ms auf null dimmt und dass dies an die bestehende Command queue angehängt wird.
In meinem Code hier checke ich, ob die Parameter überhaupt existieren, dass scheint bei Dir nicht zu passieren
Ich push mal meinen Stand, aber das wird, fürchte ich, ein bisschen dauern, weil ich einen neuen Rechner habe, und meine git Umgebung dort noch nicht drauf ist.
Lass dir ruhig Zeit. Bin der Version kann ich erstmal weiter testen und wenn du soweit bist, aktualisiere ich.
Danke auf jeden Fall!
bis ich dazu komme, nimm mal die Version im Anhang.
Beware: there be Dragons!
Vor allem die "set <devicename> raw" Funktion ist mit Vorsicht zu genießen, weil sie überhaupt nicht in den Rest integriert ist.
pj
Modul habe ich getauscht.
Sehr redselig das ganze ;)
2016.09.28 08:53:47 4: RGBWW.u: get config request
2016.09.28 08:53:47 5: RGBWW.u send API Call {
'callback' => sub { "DUMMY" },
'hash' => {
'DEF' => '192.168.100.76',
'IP' => '192.168.100.76',
'NAME' => 'RGBWW.u',
'NR' => 388,
'STATE' => '???',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'method' => 'GET',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.100.76/info'
}
2016.09.28 08:53:47 4: RGBWW.u attrib colorTemp set 2700
2016.09.28 08:53:47 4: RGBWW.u attrib defaultColor set 0,10,80
2016.09.28 08:53:47 4: RGBWW.u attrib defaultRamp set 6000
2016.09.28 08:53:47 4: RGBWW.u attrib event-on-change-reading set hsv
2016.09.28 08:53:47 4: RGBWW.u attrib room set 07_Wohnzimmer
2016.09.28 08:53:47 4: RGBWW.u attrib userReadings set hsv {ReadingsVal($name,'hue','0').','.ReadingsVal($name,'sat','100').','.ReadingsVal($name,'bri','100')}
2016.09.28 08:53:47 4: RGBWW.o: get config request
2016.09.28 08:53:47 5: RGBWW.o send API Call {
'callback' => sub { "DUMMY" },
'hash' => {
'DEF' => '192.168.100.78',
'IP' => '192.168.100.78',
'NAME' => 'RGBWW.o',
'NR' => 389,
'STATE' => '???',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'method' => 'GET',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.100.78/info'
}
2016.09.28 08:53:47 4: RGBWW.o attrib colorTemp set 2700
2016.09.28 08:53:47 4: RGBWW.o attrib defaultColor set 0,10,80
2016.09.28 08:53:47 4: RGBWW.o attrib defaultRamp set 6000
2016.09.28 08:53:47 4: RGBWW.o attrib event-on-change-reading set hsv
2016.09.28 08:53:47 4: RGBWW.o attrib room set 07_Wohnzimmer
is ja auch direkt von meinem developer System und wir haben noch immer ein Problem mit der Serialisierung von Queues.
sorry wenn ich hier so zwischen quatsche, ich such einfach ein RGBWW system welches sinnvoll über alle 5 Kanäle in fhem integriert ist.
Ist dieser ESP8266 chip die Zukunft in fhem? Die anderen (LD686 oder Milight) hat man wohl fallen lassen?!
gruß
Andre
Zitat von: ischgucke am 02 Oktober 2016, 14:19:04
sorry wenn ich hier so zwischen quatsche, ich such einfach ein RGBWW system welches sinnvoll über alle 5 Kanäle in fhem integriert ist.
Ist dieser ESP8266 chip die Zukunft in fhem? Die anderen (LD686 oder Milight) hat man wohl fallen lassen?!
gruß
Andre
Achtung, Du bringst da Sachen durcheinander.
Hier geht es um den von mprj entwickelten (saugeilen 8)) RGBWW controller für den auch bereits ein ersten fhem modul existiert.
Für die milight existieren separate module. Die ld Serie wird von WifiLight unterstützt, der ld868 ist dort jedoch noch nicht enthalten weil das wifilight modul (noch nicht) über ww/cw ctrl verfügt.
vg
joerg
Zitat von: herrmannj am 02 Oktober 2016, 14:46:53
Achtung, Du bringst da Sachen durcheinander.
Hier geht es um den von mprj entwickelten (saugeilen 8)) RGBWW controller für den auch bereits ein erstes fhem modul existiert.
Für die milight existieren separate module. Die ld Serie wird von WifiLight unterstützt, der ld868 ist dort jedoch noch nicht enthalten weil das wifilight modul (noch nicht) über ww/cw ctrl verfügt.
vg
joerg
Zitat von: herrmannj am 02 Oktober 2016, 14:46:53
Achtung, Du bringst da Sachen durcheinander.
Hier geht es um den von mprj entwickelten (saugeilen 8)) RGBWW controller für den auch bereits ein ersten fhem modul existiert.
Für die milight existieren separate module. Die ld Serie wird von WifiLight unterstützt, der ld868 ist dort jedoch noch nicht enthalten weil das wifilight modul (noch nicht) über ww/cw ctrl verfügt.
vg
joerg
ich denke ich habe das alles schon richtig verstanden. Milight und Ld habe ich ja auch mit den anderen Modulen (wifiLight und MilightBridge/Device) getestet nur kein Modul kann rgb ww/cw also 5 Kanäle sinnvoll ansteuern. Euer Projekt mit dem ESP8266 sieht doch viel versprechend aus und es ist ja auch in anderen Foren schon sehr gut gehackt und dokumentiert. Ich hoffe das euer Modul hier was wird oder schon ist.
Ich suche halt eine Hardware mit der ich nun endlich meine Led Lampen ausstatten kann, die dann auch in fhem getrennt nach rgb und ww/cw gesteuert werden können.
Darum die Frage ob euer Modul wohl möglich die Zukunft für Rgbww und fhem sein wird.
Wenn möglich möchte ich gerne mit helfen, mit test oder so. Nur Proggen kann ich halt nicht wirklich.
vg andre
Edit:
es geht doch um diesen Controller/Board ? https://de.aliexpress.com/item/rgb-strip-WiFi-controller-1-port-control-15-rgb-lights-communicate-with-Android-phone-to-dim/32301423622.html (https://de.aliexpress.com/item/rgb-strip-WiFi-controller-1-port-control-15-rgb-lights-communicate-with-Android-phone-to-dim/32301423622.html)
Edit2:
Ok sorry, sehe es geht um ein selbst entwickeltes PCB https://forum.fhem.de/index.php/topic,48918.0.html (https://forum.fhem.de/index.php/topic,48918.0.html). Wo bei das von Ali doch auch sehr cool ist, wie ich finde.
Hallo,
ich nutze aktuell einen Controller (mehr oder weniger) produktiv ein - da es eine neue Zusatzbeleuchtung ist, deren Einschaltkriterium aktuell recht selten greift, habe ich mich zwar gewundert, aber nie genauer untersucht, warum das Licht fast nie an war. Nun habe ich einen Zusatzschalter hinzugefügt, mit welchem das Licht manuell zu schalten geht und musste feststellen, dass der Controller nach längerer Inaktivität nicht auf den ersten Einschaltbefehl reagiert - das Modul ist zwar der Meinung, das Licht sei an, aber erst ein erneutes Aus- und Wiedereinschalten für dann zum gewünschten Ergebnis. Ich meine, mich zu erinnern, dass es dazu schonmal etwas gab, weiß aber die Lösung (?) nicht mehr und finde es auch nicht.
Gab es dazu eine Lösung?
Vielen Dank
Ronny
Moin Ronny,
es gab in einer der älteren Controller Firmware Versionen das Problem, dass, wenn das wlan wegbrach, der Controller in den AP Modus wechselte und sich nicht mit dem wlan verbunden hat, auch wenn es wieder da war. Das soltle allerdings mit der neuesten Firmware behoben sein - check mal, ob ein neues OTA Update für Dich verfügbar ist. (aktuell sind: Firmware 0.3.1, Web Interface 0.3.3, RGBWW 0.8.1, SMING 2.1.0)
Was Du beschreibst klingt allerdings irgendwie anders.
Damit ich das richtig verstehe, definiere doch bitte mal "längere Inaktivität" (Tage? Wochen? Monat?) Ich habe hier in drei Räumen LED Strips mit dem RGBWW Controller über das fhem Modul und solange die Infrastruktur passt (also fhem Server, WLAN) funktionieren die auch, selbst, als ich neulich nach 2 1/2 Wochen aus dem Urlaub zurück kam.
Wenn Du Zusatzschalter sagst, dann gehe ich davon aus, dass Du damit etwas in fhem meinst?
Es wäre gut, wenn Du die Zustände mal per Screenshot im Fhem-UI dokumentieren und mir gleichzeitig den Log Output mit verbose=5 posten könntest.
Außerdem wäre es vermutlich sinnvoll, das fhem Modul auf den Branch "dev-pj" im git repository upzudaten, "master" ist einfach viel zu alt mittlerweile.
Grüße
pj
Hallo,
da ich zur Zeit nicht zu Hause bin, kann ich Details erst heute Nachmittag/Abend liefern, aber hier schon einmal ein paar Eckdaten:
- ich kann "längere Inaktivität" nicht genau definieren, aber es handelt sich dabei maximal um Stunden
- mit Zusatzschalter meine ich eine Homematic Fernbedienung, welche das Licht dann via FHEM einschaltet. Das erste "set xxx on" verläuft wie gesagt ins leere, jedes weitere Schalten wird dann jedoch erkannt.
- das FHEM Modul habe ich aus einem der letzten Posts aktuell gezogen, da ich vorher eine ziemlich alte Version hatte
- im FHEM Modul steht die Firmware 0.3.1 als Internal
Schaltversuche und Logs kann ich wie gesagt erst später liefern...
Vielen Dank schonmal
Ronny
Hi
Ich kenn das, komm aber im Augenblick auch nicht dazu das seriös zu untersuchen.
Der erste Befehl nach Stunden läuft nicht ins Leere (bei mir ). Der braucht ca30 Sekunden, dann kommt erst die Reaktion des Controllers. Da läuft das Modul in den timeout
Vg
Joerg
seltsam, wie gesagt, ich habe hier drei Räume, die ich ausschließlich auf diesem Weg erleuchten kann und das Problem ist mir hier unbekannt.
wobei: es gab mal die Probleme mit verlorenen ARP Einträgen und einem möglichen Fehler im ESP ip Stack... Da hatte ich dann allerdings das Problem, dass die Controller garnicht mehr erkannt wurden.
Idealerweise hätte ich dann gerne einen Packet Trace (wireshark oder tcpdump)
pj
Hallo zusammen,
vielen Dank für die Entwicklung des Moduls. Klappt soweit alles sehr zuverlässig bei mir.
Jedoch habe ich festgestellt, dass sich über Homebridge/Homekit die Lampen lediglich ein- und ausschalten lassen. Dimmen funktioniert nicht. Hat das schon jemand zum laufen gebracht?
Ich habe es über das homebridgeMapping versucht
attr Wz_Deckenlampe homebridgeMapping Brightness=val,cmd=dim
doch leider klappt das auch nicht. Eventuell ist das aber auch so falsch?
Danke für jegliche Hilfe vorab!
Viele Grüße
Jonas
Moin Jonas,
ich hab leider noch nie was mit Homebridge gemacht, weiß also nicht, wie das funktionieren soll.
Das LedController Modul kennt die beiden Befehle val und dim, und erwartet jeweils einen Float Wert zwischen 0 und 100 (Zehntel können tatsächlich ungesetzt werden, da der Controller 10Bit pwm verwendet).
Ein "set <device> val 50" stellt also 50% Helligkeit ein und lässt alles andere (also Sättigung und Farbe) wie es ist.
"dim" ist lediglich ein Synonym für "val" und wird intern vom gleichen Code abgearbeitet.
Welche Version des LedController Moduls verwendest Du? Nimm mal das aus dem dev-pj Zweig, da ist zwar viel Debug drin, aber das funktioniert bei mir seit langem einwandfrei, und es behebt ein paar Bugs, die in den anderen Zweigen noch drin sind.
Wenn Du das hast, dann poste doch bitte mal den Log Output, daraus kann man zumindest gut ablesen, was das Modul sieht. (verbose 5)
Grüße
pj
[edit]
ok, jetzt hab ich mal nachgelesen, was Homebridge ist. Bei mir gibt es schon seit über 15 Jahren keine Apple Geräte mehr, ich habe also keine Möglichkeit, das zu testen. Wenn Homebridge allerdings mit WifiLight funktioniert, dann sollte es an und fürsich auch mit LedController kein Problem haben. Obwohl die Groß/Kleinschreibung an manchen stellen anders ist, ist das Interface weitestgehend an WifiLight angelehnt.
Hey pj,
hatte die aktuelle Version aus dem Master-Ordner. Jetzt hab ich es mit deiner dev Version versucht, doch es ist genauso. Im Log hab ich nun erkannt, dass bei dem übertragenen val Wert wohl irgendwas schiefgeht. Ich hänge es mal an.
Mit WifiLight macht es tatsächlich keine Probleme bei mir. Lässt sich also auch über Homebridge dimmen.
2016.10.15 14:35:46 5: Wz_Deckenlampe (Set) called with on, busy flag is 0
name is Wz_Deckenlampe, args
2016.10.15 14:35:46 3: Wz_Deckenlampe (Set) called with on, busy flag is 0
2016.10.15 14:35:46 5: Wz_Deckenlampe defaultColor: 0
2016.10.15 14:35:46 5: Wz_Deckenlampe setting VAL to 100, SAT to 0 and HUE 0
2016.10.15 14:35:46 5: Wz_Deckenlampe args[0] = , args[1] =
2016.10.15 14:35:46 5: Wz_Deckenlampe extended args raw: a=, b=
2016.10.15 14:35:46 5: Wz_Deckenlampe t= 0
2016.10.15 14:35:46 5: Wz_Deckenlampe extended args: t = 0, q = false, d = 1
2016.10.15 14:35:46 5: Wz_Deckenlampe: called SetHSVColor 0, 0, 100, 2700, 0, solid, false, 1)
2016.10.15 14:35:46 4: Wz_Deckenlampe: encoded json data: {"q":"false","cmd":"solid","t":"0","hsv":{"h":"0","s":"0","ct":"2700","v":"100"},"d":"1"}
2016.10.15 14:35:46 4: Wz_Deckenlampe: set HSV color request
HASH(0x1588bf0)
2016.10.15 14:35:46 5: Wz_Deckenlampe send API Call $VAR1 = {
'callback' => sub { "DUMMY" },
'data' => '{"q":"false","cmd":"solid","t":"0","hsv":{"h":"0","s":"0","ct":"2700","v":"100"},"d":"1"}',
'hash' => {
'.triggerUsed' => 0,
'CL' => {
'Authenticated' => 1,
'BUF' => '',
'CD' => bless( \*Symbol::GEN711, 'IO::Socket::INET' ),
'FD' => 26,
'LASTACCESS' => 1476534946,
'NAME' => 'WEB_127.0.0.1_47740',
'NR' => 278,
'PEER' => '127.0.0.1',
'PORT' => 47740,
'SNAME' => 'WEB',
'SSL' => undef,
'STATE' => 'Connected',
'TEMPORARY' => 1,
'TYPE' => 'FHEMWEB'
},
'DEF' => '192.168.178.24',
'DEVICEID' => '9180977',
'FIRMWARE' => '0.3.1',
'IP' => '192.168.178.24',
'MAC' => '5ccf7f8c1731',
'NAME' => 'Wz_Deckenlampe',
'NR' => 23,
'NTFY_ORDER' => '50-Wz_Deckenlampe',
'READINGS' => {
'HSV' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '0,0,0'
},
'RGB' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '000000'
},
'ct' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 2700
},
'hsv' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => '0,0,0'
},
'hue' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
},
'rgb' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => '000000'
},
'sat' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
},
'state' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 'off'
},
'val' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
}
},
'STATE' => 'off',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'loglevel' => 5,
'method' => 'POST',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.178.24/color?mode=HSV'
};
2016.10.15 14:35:46 5: Wz_Deckenlampe: calculated RGB as ffffff
2016.10.15 14:35:46 4: Wz_Deckenlampe: begin Readings Update
hue: 0
sat: 0
val:100
ct : 2700
HSV: 0,0,100
RGB: ffffff
2016.10.15 14:35:46 4: Wz_Deckenlampe: got HSV color response
2016.10.15 14:35:46 5: Wz_Deckenlampe: HSV color response data {"success":true}
2016.10.15 14:35:47 5: Wz_Deckenlampe (Set) called with dim, busy flag is 0
name is Wz_Deckenlampe, args $VAR1 = '292929';
2016.10.15 14:35:47 3: Wz_Deckenlampe (Set) called with dim, busy flag is 0
2016.10.15 14:35:47 5: Wz_Deckenlampe setting VAL to 292929, keeping HUE 0 and SAT 0
2016.10.15 14:35:47 5: Wz_Deckenlampe extended args raw: a=, b=
2016.10.15 14:35:47 5: Wz_Deckenlampe t= 0
2016.10.15 14:35:47 5: Wz_Deckenlampe extended args: t = 0, q = false, d = 1
2016.10.15 14:35:47 5: Wz_Deckenlampe: called SetHSVColor 0, 0, 292929, 2700, 0, solid, false, 1)
2016.10.15 14:35:47 4: Wz_Deckenlampe: encoded json data: {"q":"false","cmd":"solid","t":"0","d":"1","hsv":{"h":"0","s":"0","v":"292929","ct":"2700"}}
2016.10.15 14:35:47 4: Wz_Deckenlampe: set HSV color request
HASH(0x2e15518)
2016.10.15 14:35:47 5: Wz_Deckenlampe send API Call $VAR1 = {
'callback' => sub { "DUMMY" },
'data' => '{"q":"false","cmd":"solid","t":"0","d":"1","hsv":{"h":"0","s":"0","v":"292929","ct":"2700"}}',
'hash' => {
'.triggerUsed' => 0,
'CL' => {
'Authenticated' => 1,
'BUF' => '',
'CD' => bless( \*Symbol::GEN714, 'IO::Socket::INET' ),
'FD' => 26,
'LASTACCESS' => 1476534947,
'NAME' => 'WEB_127.0.0.1_47746',
'NR' => 280,
'PEER' => '127.0.0.1',
'PORT' => 47746,
'SNAME' => 'WEB',
'SSL' => undef,
'STATE' => 'Connected',
'TEMPORARY' => 1,
'TYPE' => 'FHEMWEB'
},
'DEF' => '192.168.178.24',
'DEVICEID' => '9180977',
'FIRMWARE' => '0.3.1',
'IP' => '192.168.178.24',
'MAC' => '5ccf7f8c1731',
'NAME' => 'Wz_Deckenlampe',
'NR' => 23,
'NTFY_ORDER' => '50-Wz_Deckenlampe',
'READINGS' => {
'HSV' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '0,0,0'
},
'RGB' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '000000'
},
'ct' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 2700
},
'hsv' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => '0,0,100'
},
'hue' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 0
},
'rgb' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 'ffffff'
},
'sat' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 0
},
'state' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 'on'
},
'val' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 100
}
},
'STATE' => 'on',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'loglevel' => 5,
'method' => 'POST',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.178.24/color?mode=HSV'
};
2016.10.15 14:35:47 5: Wz_Deckenlampe: calculated RGB as b65d9b65d9b65d9
2016.10.15 14:35:47 4: Wz_Deckenlampe: begin Readings Update
hue: 0
sat: 0
val:292929
ct : 2700
HSV: 0,0,292929
RGB: b65d9b65d9b65d9
2016.10.15 14:35:47 4: Wz_Deckenlampe: got HSV color response
2016.10.15 14:35:47 5: Wz_Deckenlampe: HSV color response data {"success":true}
Zitat von: johns am 15 Oktober 2016, 14:48:27
Hey pj,
hatte die aktuelle Version aus dem Master-Ordner. Jetzt hab ich es mit deiner dev Version versucht, doch es ist genauso. Im Log hab ich nun erkannt, dass bei dem übertragenen val Wert wohl irgendwas schiefgeht. Ich hänge es mal an.
Mit WifiLight macht es tatsächlich keine Probleme bei mir. Lässt sich also auch über Homebridge dimmen.
2016.10.15 14:35:46 5: Wz_Deckenlampe (Set) called with on, busy flag is 0
name is Wz_Deckenlampe, args
2016.10.15 14:35:46 3: Wz_Deckenlampe (Set) called with on, busy flag is 0
2016.10.15 14:35:46 5: Wz_Deckenlampe defaultColor: 0
2016.10.15 14:35:46 5: Wz_Deckenlampe setting VAL to 100, SAT to 0 and HUE 0
2016.10.15 14:35:46 5: Wz_Deckenlampe args[0] = , args[1] =
2016.10.15 14:35:46 5: Wz_Deckenlampe extended args raw: a=, b=
2016.10.15 14:35:46 5: Wz_Deckenlampe t= 0
2016.10.15 14:35:46 5: Wz_Deckenlampe extended args: t = 0, q = false, d = 1
2016.10.15 14:35:46 5: Wz_Deckenlampe: called SetHSVColor 0, 0, 100, 2700, 0, solid, false, 1)
2016.10.15 14:35:46 4: Wz_Deckenlampe: encoded json data: {"q":"false","cmd":"solid","t":"0","hsv":{"h":"0","s":"0","ct":"2700","v":"100"},"d":"1"}
2016.10.15 14:35:46 4: Wz_Deckenlampe: set HSV color request
HASH(0x1588bf0)
2016.10.15 14:35:46 5: Wz_Deckenlampe send API Call $VAR1 = {
'callback' => sub { "DUMMY" },
'data' => '{"q":"false","cmd":"solid","t":"0","hsv":{"h":"0","s":"0","ct":"2700","v":"100"},"d":"1"}',
'hash' => {
'.triggerUsed' => 0,
'CL' => {
'Authenticated' => 1,
'BUF' => '',
'CD' => bless( \*Symbol::GEN711, 'IO::Socket::INET' ),
'FD' => 26,
'LASTACCESS' => 1476534946,
'NAME' => 'WEB_127.0.0.1_47740',
'NR' => 278,
'PEER' => '127.0.0.1',
'PORT' => 47740,
'SNAME' => 'WEB',
'SSL' => undef,
'STATE' => 'Connected',
'TEMPORARY' => 1,
'TYPE' => 'FHEMWEB'
},
'DEF' => '192.168.178.24',
'DEVICEID' => '9180977',
'FIRMWARE' => '0.3.1',
'IP' => '192.168.178.24',
'MAC' => '5ccf7f8c1731',
'NAME' => 'Wz_Deckenlampe',
'NR' => 23,
'NTFY_ORDER' => '50-Wz_Deckenlampe',
'READINGS' => {
'HSV' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '0,0,0'
},
'RGB' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '000000'
},
'ct' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 2700
},
'hsv' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => '0,0,0'
},
'hue' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
},
'rgb' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => '000000'
},
'sat' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
},
'state' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 'off'
},
'val' => {
'TIME' => '2016-10-15 14:35:19',
'VAL' => 0
}
},
'STATE' => 'off',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'loglevel' => 5,
'method' => 'POST',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.178.24/color?mode=HSV'
};
2016.10.15 14:35:46 5: Wz_Deckenlampe: calculated RGB as ffffff
2016.10.15 14:35:46 4: Wz_Deckenlampe: begin Readings Update
hue: 0
sat: 0
val:100
ct : 2700
HSV: 0,0,100
RGB: ffffff
2016.10.15 14:35:46 4: Wz_Deckenlampe: got HSV color response
2016.10.15 14:35:46 5: Wz_Deckenlampe: HSV color response data {"success":true}
Das war ein Aufruf mit "on" und soweit ich das erkennen kann leuchtet die Lampe damit jetzt 100% weiß, korrekt? (in der jetztigen Version kannst Du die Farbe bei "on" übrigens mit dem Attribut "defaultColor h,s,v" konfigurieren)
Zitat von: johns am 15 Oktober 2016, 14:48:27
2016.10.15 14:35:47 5: Wz_Deckenlampe (Set) called with dim, busy flag is 0
name is Wz_Deckenlampe, args $VAR1 = '292929';
Das Modul selbst macht noch kein Parameter Checking deshalb mal so manuell:
ERROR: parameter out of bounds.
dim ist, wie oben gesagt, ein Synonym von val und nimmt als Parameter einen Float Prozentwert, also 0,0 bis 100,0. 292929 ist deutlich größer.
Ich kenne wie gesagt Homebridge garnicht, aber für mich sieht das nach einem rgb Tupel aus, zumindest wenn ich davon ausgehe, dass es hex ist. Kannst Du Homebridge sagen, dass es eben
genau nur einen Prozentwert übergeben soll?
Den Rest können wir uns damit schenken, da kann nix sinnvolles dabei rauskommen.
Eigentlich direkt ein Glück, dass fhem dabei nicht mit irgendeinem Parameterüberlauf abstürzt :o
Zitat von: johns am 15 Oktober 2016, 14:48:27
2016.10.15 14:35:47 3: Wz_Deckenlampe (Set) called with dim, busy flag is 0
2016.10.15 14:35:47 5: Wz_Deckenlampe setting VAL to 292929, keeping HUE 0 and SAT 0
2016.10.15 14:35:47 5: Wz_Deckenlampe extended args raw: a=, b=
2016.10.15 14:35:47 5: Wz_Deckenlampe t= 0
2016.10.15 14:35:47 5: Wz_Deckenlampe extended args: t = 0, q = false, d = 1
2016.10.15 14:35:47 5: Wz_Deckenlampe: called SetHSVColor 0, 0, 292929, 2700, 0, solid, false, 1)
2016.10.15 14:35:47 4: Wz_Deckenlampe: encoded json data: {"q":"false","cmd":"solid","t":"0","d":"1","hsv":{"h":"0","s":"0","v":"292929","ct":"2700"}}
2016.10.15 14:35:47 4: Wz_Deckenlampe: set HSV color request
HASH(0x2e15518)
2016.10.15 14:35:47 5: Wz_Deckenlampe send API Call $VAR1 = {
'callback' => sub { "DUMMY" },
'data' => '{"q":"false","cmd":"solid","t":"0","d":"1","hsv":{"h":"0","s":"0","v":"292929","ct":"2700"}}',
'hash' => {
'.triggerUsed' => 0,
'CL' => {
'Authenticated' => 1,
'BUF' => '',
'CD' => bless( \*Symbol::GEN714, 'IO::Socket::INET' ),
'FD' => 26,
'LASTACCESS' => 1476534947,
'NAME' => 'WEB_127.0.0.1_47746',
'NR' => 280,
'PEER' => '127.0.0.1',
'PORT' => 47746,
'SNAME' => 'WEB',
'SSL' => undef,
'STATE' => 'Connected',
'TEMPORARY' => 1,
'TYPE' => 'FHEMWEB'
},
'DEF' => '192.168.178.24',
'DEVICEID' => '9180977',
'FIRMWARE' => '0.3.1',
'IP' => '192.168.178.24',
'MAC' => '5ccf7f8c1731',
'NAME' => 'Wz_Deckenlampe',
'NR' => 23,
'NTFY_ORDER' => '50-Wz_Deckenlampe',
'READINGS' => {
'HSV' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '0,0,0'
},
'RGB' => {
'TIME' => '2016-10-14 22:18:31',
'VAL' => '000000'
},
'ct' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 2700
},
'hsv' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => '0,0,100'
},
'hue' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 0
},
'rgb' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 'ffffff'
},
'sat' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 0
},
'state' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 'on'
},
'val' => {
'TIME' => '2016-10-15 14:35:46',
'VAL' => 100
}
},
'STATE' => 'on',
'TYPE' => 'LedController',
'helper' => {
'cmdQueue' => [],
'isBusy' => 1
}
},
'header' => 'User-Agent: fhem
Accept: application/json',
'loglevel' => 5,
'method' => 'POST',
'parser' => sub { "DUMMY" },
'timeout' => 30,
'url' => 'http://192.168.178.24/color?mode=HSV'
};
2016.10.15 14:35:47 5: Wz_Deckenlampe: calculated RGB as b65d9b65d9b65d9
2016.10.15 14:35:47 4: Wz_Deckenlampe: begin Readings Update
hue: 0
sat: 0
val:292929
ct : 2700
HSV: 0,0,292929
RGB: b65d9b65d9b65d9
2016.10.15 14:35:47 4: Wz_Deckenlampe: got HSV color response
2016.10.15 14:35:47 5: Wz_Deckenlampe: HSV color response data {"success":true}
Grüße
pj
Zitat von: pjakobs am 15 Oktober 2016, 17:37:06
Das war ein Aufruf mit "on" und soweit ich das erkennen kann leuchtet die Lampe damit jetzt 100% weiß, korrekt?
Danke das war der Hinweis, der mich zu einem Ergebnis geführt hat. Das ganze ist scheinbar ein Problem von Apple HomeKit und hat nichts mit diesem Modul zu tun. Siehe https://forum.fhem.de/index.php?topic=56618.0
Es wird also immer einmal 100% und dann der eigentliche Dimmwert übermittelt. Das ist natürlich ziemlich dämlich .. :/
Außerdem musste ich die Homebridge Funktion neu starten, damit
attr Wz_Deckenlampe homebridgeMapping Brightness=val,cmd=dim angenommen wird (ein FHEM restart genügt nicht!). Dadurch stimmen jetzt auch die übermittelten Parameter im Logfile. Vielleicht braucht es ja irgendjemand nochmal.
Hmm... ich kann die Logik verstehen, homekit geht also offenbar davon aus, dass das Gerät die grundsätzlichen Zustände "on" und "off" kennt und schaltet es erst einmal ein, damit es dann dimmen kann.
Solltest Du das nicht abschalten können, dann kannst Du ja die defaultColor auf 0,0,0 stellen. Wobei, das ist natürlich auch irgendwie blöd, denn dann würde ein "set on" das Licht ausschalten.
hmm...
pj
Hi,
ich habe mehrfach RAW modus gelesen. Ist es im Modul möglich per RAW Befehl sowohl CW als auch WW 100% zu aktivieren? Ohne Fading oder Farbübergang. Einfach nur volle Helligkeit beider Weiß-Kanäle?
Wenn es nicht per Modul möglich ist, gibt es einen HTTP-Befehl oder irgend etwas anderes was ich über Fhem absetzen kann um das zu aktivieren?
Danke!
Zitat von: kadettilac89 am 31 Oktober 2016, 15:44:19
Hi,
ich habe mehrfach RAW modus gelesen. Ist es im Modul möglich per RAW Befehl sowohl CW als auch WW 100% zu aktivieren? Ohne Fading oder Farbübergang. Einfach nur volle Helligkeit beider Weiß-Kanäle?
Wenn es nicht per Modul möglich ist, gibt es einen HTTP-Befehl oder irgend etwas anderes was ich über Fhem absetzen kann um das zu aktivieren?
Danke!
zieh dir die Version aus dem dev-pj Branch, da kannst Du mit
set <device> raw r10,g10,b10,ww10,cw10 den 10 Bit (0-1023) Wert für jeden Kanal setzen.
Nicht staunen, die Version erzeugt abstrus viel Debug Output
Grüße
pj
Zitat von: pjakobs am 31 Oktober 2016, 21:15:16
zieh dir die Version aus dem dev-pj Branch, da kannst Du mit
set <device> raw r10,g10,b10,ww10,cw10
den 10 Bit (0-1023) Wert für jeden Kanal setzen.
Nicht staunen, die Version erzeugt abstrus viel Debug Output
Grüße
pj
Danke dir
Ich hab mal meine aktuelle Version auf github gepusht, branch dev-pj
- neue Funktionen: dimup / dimdown - tun, was der Name beschreibt. Ich brauchte die für up/down Taster als Dimmer-Trigger (über ein Notify)
- experimentelle Funktion: raw - nachdem mehrfach danach gefragt wurde: set <device> raw r10,b10,g10,cw10,ww10 (x10 ist dabei ein 10Bit Wert, also 0-1023) gibt volle Kontrolle über die einzelnen Kanäle.
- Dokumentation wieder eingefügt - irgendwann ist mir die html Dokumentation im devel Tree verloren gegangen, ich hab sie hier wieder eingebaut, allerdings stimmt imho irgendwas noch nicht, weil immer de und en angezeigt werden?
Diese Version erzeugt noch jede Menge Debug. Bisher habe ich keine Rückmeldung über Bugs bekommen, ich denke, wenn das so bleibt, werde ich den Debug Kram rausnehmen und sie zum Master promoten (orr... dazu fehlt mir imho ein rebase, mal sehen. git-Schmerzen ;-) )
Was noch fehlt:
- Ordentliches Seuqencing der Requests - wenn viele Sets in einer Befehlszeile abgesetzt werden (also z.B., mit fhem("set LED on, set LED off, set LED on");), dann schickt das Modul diese nicht auf einmal an den Controller, sondern wartet jeweils darauf, dass der vorhergegangene Befehl abgearbeitet ist. Wer im Moment Sequenzen programmieren will, der tut gut daran, die getrennt ( fhem("set LED on");fhem("set LED off");) zu senden.
- Ich suche noch nach einem vernünftigen Weg die verschiedenen Modi des Controllers abzubilden. Es gibt ja
- den "normalen" hsv Modus, den das Modul zumeist verwendet. Hier wird die Berechnung der LED Helligkeit für die einzelnen Kanäle der Firmware überlassen
- den raw Modus, hier übernimmt fhem komplett die Steuerung des Controllers, es wird kein hsv Wert bestimmt (und das ist, zumindest ohne größeren Aufwand, auch nicht möglich)
- zumindest die Möglichkeit, die Kanäle nicht as RGBWWCW sondern als fünf unabhängige Kanäle zu betrachten. Diese würde ich gerne als fünf Devices in FHEM abbilden. Dazu habe ich mir bisher nur ein paar Gedanken gemacht
Wer sich berufen fühlt, hier etwas beizutragen: nur zu!
Grüße
pj
Ich möchte mich an dieser Stelle mal bedanken - und meckern.
Bedanken für den super gemachten und recht gut durchdachten RGBWW Controller incl. des FHEM-Moduls.
Und meckern, weil... naja, weil ich mir ein ESP8266 Board gekauft habe und direkt die Idee hatte "Mensch, damit bauste nen RGB-WiFi-Dimmer". Also flugs mal einen kleinen REST-Service draufgeworfen und per Colorpicker angesteuert. War ein Abend Arbeit und funktionierte schonmal prima. Dann suchte ich nach ner besseren Möglichkeit zur Ansteuerung als über den normalen Colorpicker und stolperte über... das hier.
Was soll ich sagen? Meine Eigenentwicklung ist eingemottet, denn um an den Funktionsumfang und die Qualität dieser Implementierung ranzukommen bräuchte ich Monate - und da siegte die Faulheit.
Und da ich von Perl eher gar keinen Plan habe (Java schon eher, aber... :D ) finde ich das passende Modul auch super!
Ich muss sagen: Chapeau! Ich ziehe meinen Hut!
Da ich FHEM-Neuling bin kämpfe ich allerdings derzeit mit dem FHEM-Modul. Ich krieg's einfach nicht hin, was anderes als nen on/off switch in der WebGUI angezeigt zu bekommen.
Könnte bitte mal jemand seine komplette Definition für das LedController Modul hier posten damit ich ein wenig spicken kann?
Das hat sich erledigt... ;)
Was nicht zu funktionieren scheint ist das Fading von einer Farbe zur anderen. Geht das nicht automatisch per colorpicker irgendwie? o0
Danke und macht weiter so, der Controller ist ziemlich geil! ;)
Ich habe heute früh mal das git aufgeräumt, der devel und der master branch sind jetzt auf dem gleichen, getesteten und voll funktionalen Stand (zumindest nach meinem Empfinden).
@Shuzz hat sich die Mühe gemacht, den Code aufzuräumen und lesbarer zu gestalten. Zudem gibt es jetzt für alle Parameter range checks, so dass das Modul insgesamt robuster geworden sein dürfte.
Zudem haben wir die "on" Funktion ein bisschen verändert:
- wenn die Helligkeit ungleich null ist (val!=0), dann tut on nichts.
- wenn ein default Farbwert vorgegeben ist, dann setzt on diesen
- defaultColor ist deprecated zugunsten von defaultHue, defaultSat und defaultVal
- beim Abschalten wird der letzte val Wert in einem internal gespeichert, wenn kein Default vorgegeben ist, wird dieser beim Einschalten verwendet
- wenn weder ein Default noch ein letzter Wert vorhanden ist, wird die Helligkeit auf 100% gesetzt
Damit hoffen wir ein paar Fliegen mit einer Klappe geschlagen zu haben:
- Kompatibilität mit homekit/homebridge: es ist schonmal beobachtet worden, dass sich homekit ein wenig seltsam verhält, indem es erst den Farbwert setzt und dann ein on Kommando hinterher sendet. Im bisherigen Zustand hätte der Farbwert zwar das Modul korrekt auf die gewünschte Farbe geschaltet, das nachfolgende on aber sofort auf die defautt-Farbe oder, wenn diese nicht konfiguriert ist, auf 0,0,100. Da das Modul ein on jetzt ignoriert, wenn val != 0 sollte das jetzt nicht mehr vorkommen.
- Viele China Controller interpretieren "on" als "aktiviere das letzte Setting" sprich: sie schalten auf die Lichtfarbe, die vor dem Ausschalten aktiv war. Das Controller-Modul hat bisher stattdessen auf eine Default Farbe geschaltet. Die neue Version erlaubt nun beides: ist ein Default gesetzt, wird es verwendet, ist kein Default gesetzt, wird der letzte Zustand wieder hergestellt. Da nun die Default Werte in einzelne Attrs aufgeteilt sind, kann auch eine default Farbe konfiguriert werden, die Helligkeit und die Sättigung werden dann aber z.B. vom letzten mal übernommen bzw. jeder andere Kombination hieraus.
Zudem ist jetzt endlich der master Zweig wirklich up to date, wer noch mit einer der alten dev-pj oder gar der ganz alten master Versionen sollte jetzt updaten :-)
Grüße
pj
Abend,
ich versuche mit dem LED Controller ein Wakeup light zu erstellen mit Codeauszügen aus dem Forum:
# Sonnenaufgangssimulation für bis zu 4 Devices
# Author : Sandra Ohmayer (http://www.animeschatten.net)
# Aufruf: wakeUpSun(<Zeit in Minuten>,"<Devicename>"),wakeUpSun(<Zeit in Minuten>,"<Devicename1>","<Devicename2>") ...
sub
wakeUpSun {
# Dauer in Minuten (minimum 4 min)
local $dauer = $_[0];
# Initialisiern des Lichterarrays
local @lichter = ($_[1],$_[2],$_[3],$_[4]);
local @farben = (
["240,100,2",1],
["240,100,1",1],
["240,100,2",20],
["240,100,5",20],
["240,100,8",20],
["210,100,6",30],
["190,100,8",1],
["90,100,14",1],
["70,100,16",1],
["10,100,34",2],
["30,100,40",30],
["40,100,60",30],
["45,100,80",30],
["50,100,100",30],
["50,19,75",3],
["50,0,100",30]
);
local $gesamtdauersek = $dauer*60;
local $dauerfarben = 0;
foreach my $farbe ( @farben ) {
$dauerfarben+=$farbe->[1];
}
local $anteiligedauer = $gesamtdauersek/$dauerfarben;
Log3 (undef, 3, "wakeUpSun: start, angegebene Gesamtdauer in Sekunden $gesamtdauersek, Dauer Farben $dauerfarben, Anteil $anteiligedauer");
# Ausschalten der Lampen (Schalter - off)
foreach my $licht ( @lichter ) {
if(defined $licht) {
fhem("set $licht off");
}
}
# Durchlauf der Farbsimulation
my $i = 0;
foreach my $farbe ( @farben ) {
foreach my $licht ( @lichter ) {
if(defined $licht) {
if($i == 0) {
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
} else {
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
}
}
}
$i++;
}
}
Leider muss ich feststellen das folgende Fehler bei mir vorliegen:
1) Farbablauf bei jedem Aufruf unterschiedlich
2) egal welche dauer ich in Min. angebe, der Farbverlauf läuft zu schnell
3) Bleibt manchmal in einer Farbe stehen
Ich beschäftige mich mit der Programmierung und Fhem erst seit kurzem, daher würde ich mich freuen wenn mir jemand helfen könnte.
Vielen Dank im voraus.
Sg,
Kamilo
Hi Kamillo,
ich hab das gerade mal getestet (nicht sehr ausgiebig, gebe ich zu) und bei mir schaut das auf den ersten Blick sehr ok aus.
Ich habe den Code ganz leicht abgewandelt (die "local" Definition der Variablen oben mit "my" ersetzt, zusätzliche Logausgabe):
# Sonnenaufgangssimulation für bis zu 4 Devices
# Author : Sandra Ohmayer (http://www.animeschatten.net)
# Aufruf: wakeUpSun(<Zeit in Minuten>,"<Devicename>"),wakeUpSun(<Zeit in Minuten>,"<Devicename1>","<Devicename2>") ...
sub
wakeUpSun {
# Dauer in Minuten (minimum 4 min)
my $dauer = $_[0];
# Initialisiern des Lichterarrays
my @lichter = ($_[1],$_[2],$_[3],$_[4]);
my @farben = (
["240,100,2",1],
["240,100,1",1],
["240,100,2",20],
["240,100,5",20],
["240,100,8",20],
["210,100,6",30],
["190,100,8",1],
["90,100,14",1],
["70,100,16",1],
["10,100,34",2],
["30,100,40",30],
["40,100,60",30],
["45,100,80",30],
["50,100,100",30],
["50,19,75",3],
["50,0,100",30]
);
my $gesamtdauersek = $dauer*60;
my $dauerfarben = 0;
foreach my $farbe ( @farben ) {
$dauerfarben+=$farbe->[1];
}
my $anteiligedauer = $gesamtdauersek/$dauerfarben;
Log3 (undef, 3, "wakeUpSun: start, angegebene Gesamtdauer in Sekunden $gesamtdauersek, Dauer Farben $dauerfarben, Anteil $anteiligedauer");
# Ausschalten der Lampen (Schalter - off)
foreach my $licht ( @lichter ) {
if(defined $licht) {
fhem("set $licht off");
}
}
# Durchlauf der Farbsimulation
my $i = 0;
foreach my $farbe ( @farben ) {
foreach my $licht ( @lichter ) {
if(defined $licht) {
if($i == 0) {
Log3(undef,3,"wakeUpSun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
} else {
Log3(undef,3,"wakeUpSun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
}
}
}
$i++;
}
}
Was mir aufgefallen ist: einige der Farbverläufe sind bis zu 30 mal schneller definiert als andere. Die Zahl nach dem Komma in den einzelnen Elementen des @farben Array gibt die relative Dauer an. Das Array im Code definiert 250 Zeiteinheiten, die dann einfach auf die angegebene Gesamtdauer gestreckt werden. Auf fünf Minuten gestreckt zieht sich der Übergang von 30,100,40 zu 50,100,100 (relativ dunkles Orange zu Sonnengelb) über 3x36s also fast zwei Minuten, von dort geht es dann allerdings innerhalb von vier Sekunden nach Weiß. Die Übergänge bzw. die Zeit dafür kannst Du ändern, indem Du den Zeitparameter in der jeweiligen Zeile des @farben Arrays änderst. Zu beachten ist dabei allerdings, dass die Gesamtzeit in Sekunden offenbar nicht kleiner sein darf als die Summe der angegebenen Zeiteinheiten.
Nimm doch bitte mal die Version der Routine, wie ich sie oben reingepostet habe und poste den LOG Output, der sich daraus ergibt hier. Der sollte inetwa so aussehen:
2016.12.06 08:53:03 3: wakeUpSun: start, angegebene Gesamtdauer in Sekunden 300, Dauer Farben 250, Anteil 1.2
2016.12.06 08:53:03 3: wakeUpSun: set LED_Sc hsv 240,100,2 2
2016.12.06 08:53:04 3: wakeUpSun: set LED_Sc hsv 240,100,1 2 q
2016.12.06 08:53:04 3: wakeUpSun: set LED_Sc hsv 240,100,2 24 q
2016.12.06 08:53:05 3: wakeUpSun: set LED_Sc hsv 240,100,5 24 q
2016.12.06 08:53:05 3: wakeUpSun: set LED_Sc hsv 240,100,8 24 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 210,100,6 36 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 190,100,8 2 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 90,100,14 2 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 70,100,16 2 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 10,100,34 3 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 30,100,40 36 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 40,100,60 36 q
2016.12.06 08:53:08 3: wakeUpSun: set LED_Sc hsv 45,100,80 36 q
2016.12.06 08:53:08 3: wakeUpSun: set LED_Sc hsv 50,100,100 36 q
2016.12.06 08:53:09 3: wakeUpSun: set LED_Sc hsv 50,19,75 4 q
2016.12.06 08:53:09 3: wakeUpSun: set LED_Sc hsv 50,0,100 36 q
(diese Zahlen sind für fünf Minuten).
Zudem: welche Version des LedController Moduls verwendest Du? Es gibt seit gestern eine brandneue, aufgeräumte, wenn Du noch eine der älteren hast - zumal vielleicht die aus dem alten master branch, dann kann dort viel merkwürdiges drin sein. "here be dragons" steht irgendwo im Code ;-)
Zieh Dir auf alle Fälle die neueste von github: https://github.com/patrickjahns/esp_rgbww_fhemmodule
Grüße
pj
Super besten Dank. Probiere es gleich mal. Kannst du mir nochmal deinen Programmaufruf zum test sagen.
Langsam hinterfrag ich schon alles.
32_LED_controller.pm grade drauf geschoben.
melde mich gleich nochmal.
Kleiner Nachtrag von mir zu meinem vorgehen:
1.deine Code habe ich per Notepad abgesspeichert in MywakeUpSun.pm. Diese Datei per ftp an den Rasp pi geschoben nach /home/pi.
Anschließen per sudo mv /home/pi/MywakeUpSun.pm /opt/fhem/Fhem.
2. analog mit der 32_LED_Controller.pm
3. in FHEM -> define LED_WoWakeUp LedController 192.168.178.71
4. in FHEM -> {wakeUpSun(4,"LED_WoWakeUp")}
Falls ich was falsch mache bitte ich um Korrektur.
Ein reload 32_LED_Controller.pm und reload MywakeUpSun.pm fehlt.
Du solltest für eigene Module (Nachtrag: welche Du nicht veröffentlichen möchtest/die nur lokal Sinn machen) möglichst das Namensschema 99_my[ModuleName].pm einhalten, z.B. 99_myWakeUpSun.pm.
Gruß,
Mario
Tatsächlich. Nun geht es. Ich danke euch für eure Unterstützung.
Freue und Bendanke mich über die Hilfsbereitschaft hier im Forum.
SG,
Kamilo
Danke für das Wakeuplight, das gefällt mir prima.
Ich glaube, das installiere ich im Schlafzimmer! ;)
Nutze 2 von den Controlern seit geraumer Zeit mit FHEM. Danke nochmal an die Macher (Hard- + Software)!
Vieleicht kann mir ja jemand einen Tip geben? Suche eine Möglichkeit, einen unendlichen Colorloop mit dem Controler zu realisieren.
Das ist derzeit nicht 100% möglich.
Du könntest zwar nen Colorloop per FHEM einmalig im Controller queuen, aber das Ding zu wiederholen wird ein Problem.
Theoretisch kannste zwar den Loop zyklisch an den Controller schicken (z.B. per at), aber das wirst Du nicht 100% synchron hinkriegen.
D.h. mit der Zeit läuft Dir entweder die Queue im Controller voll (weil Du eben einen Ticken zu früh sendest) ODER Dein Loop wird kurz unterbrochen (weil der neue Rutsch Kommandos von FHEM einen Ticken zu spät kommt).
Den letzten Fall könnte man noch geschickt kaschieren indem man die Loop auf einer festen Farbe enden lässt so dass es nicht auffällt wenn diese Farbe für ein paar Sekunden "stehen bleibt".
Danke! Muss ich mal testen. Kann man so eine Funktion (ähnlich wie bei Hue) nicht in die Firmware oder hier im Modul einbauen? Wenn möglich mit frei wählbaren Farben, zwischen denen zyklisch gefadet wird?
Ich hab gerade heute nen Vorschlag im Github eingestellt.
Problem ist nur, dass der Entwickler der Firmware derzeit ziemlich viel Leben um die Ohren hat und nicht dazu kommt was an der FW zu tun.
Ein solches Feature wäre super, aber halte lieber nicht die Luft an beim Warten. ;)
Zitat von: Shuzz am 07 Dezember 2016, 14:24:17
Ich hab gerade heute nen Vorschlag im Github eingestellt.
Problem ist nur, dass der Entwickler der Firmware derzeit ziemlich viel Leben um die Ohren hat und nicht dazu kommt was an der FW zu tun.
Ein solches Feature wäre super, aber halte lieber nicht die Luft an beim Warten. ;)
Patrick hatte "stored animations" sowieso auf der Liste, von daher denke ich, das ist Wasser auf seine Mühlen. Nur mahlen die halt leider gerade anderswo ;-)
pj
Ist ja nicht so dringend und eher ein Luxusproblem :) Ich werde das mal über at testen. Soll ein sehr langsamer Loop (ca. 15 Minuten per Farbwechsel) als Nachtlicht für meinen Sohn werden. Da sollte die Synchronisation nicht so das Problem darstellen.
Zitat von: SalvadoreXXL am 07 Dezember 2016, 15:05:56
Ist ja nicht so dringend und eher ein Luxusproblem :) Ich werde das mal über at testen. Soll ein sehr langsamer Loop (ca. 15 Minuten per Farbwechsel) als Nachtlicht für meinen Sohn werden. Da sollte die Synchronisation nicht so das Problem darstellen.
Wenn ich's richtig im Kopf habe dann verwaltet der Controller intern eine Queue mit bis zu 50 Einträgen.
Bei einem 15min dauernden Farbwechsel solltest Du auch mit einer einfachen Abfolge von "set <Device> hsv <H,S,V> 900 q" über die Runden bzw. die Nacht kommen.
Für den Anwendungsfall braucht's at gar nicht, das sollte so klappen. :)
Grüße,
Christian
Zitat von: Shuzz am 09 Dezember 2016, 10:24:04
Wenn ich's richtig im Kopf habe dann verwaltet der Controller intern eine Queue mit bis zu 50 Einträgen.
Bei einem 15min dauernden Farbwechsel solltest Du auch mit einer einfachen Abfolge von "set <Device> hsv <H,S,V> 900 q" über die Runden bzw. die Nacht kommen.
Für den Anwendungsfall braucht's at gar nicht, das sollte so klappen. :)
Denke ich auch. Mal sehen, ob ich am WE dazu komme das mal zu testen. Eine Funktion in der FW wäre einfacher 8) Momentan "frisst" Alexa einen erhebllichen Teil meiner Freizeit.
Zitat von: SalvadoreXXL am 09 Dezember 2016, 13:19:52
Momentan "frisst" Alexa einen erhebllichen Teil meiner Freizeit.
Du Glücklicher... ;)
Zitat von: Shuzz am 09 Dezember 2016, 15:48:07
Du Glücklicher... ;)
Ist ein Echo mit Migrationshintergrund
Thema Alexa: Bei mir hat nun auch ein Echo Einzug gehalten.
Natürlich gleich mal alles aufgesetzt damit Alexa auch mit meinem FHEM reden kann.
Ich war ein wenig enttäuscht, das Einstellen der Lichtfarbe geht mit dem Standard-SmartHome Skill nicht.
Aber wenigstens kann man den Controller ein- und ausschalten.
Hat da jemand von euch bereits Erfahrungen gesammelt was den Custom-Skill angeht? Kriegt man damit die Farbe (und ggf. Sättigung sowie Helligkeit) geregelt?
Hi, Alexa kenne ich noch nicht, aber bei Home/Eve. Muss ich mich auch mittels Szenen (wie z.B. "Blaues Wohnzimmer") behelfen. Da wird die Farbe hinterlegt und "Ich möchte ein blaues Wohnzimmer" funktioniert dann.
Gruß Arnd
Gesendet von iPhone mit Tapatalk
@Shuzz ich denke, @RaspiLED ist auf der richtigen Fährte, schau Dir mal LightScenes an anstatt direkt den LEDController steuern zu wollen.
Ich hab ein paar Feature Vorschläge, Funktionen, die ich momentan extern gelöst habe, die aber im Modul eleganter und sauberer zu machen wären.
Nur haben sie irgendwie auch im Modul nix zu suchen, weil sie ziemlich spezifisch sind.
Ich hätte gerne mal Input von Euch, was Ihr davon haltet.
- Automatisches Einschalten / Dimmen / Ausschalten per twilight
twilight liefert einen errechneten Helligkeitswert, abhängig von Wetter(vorhersage), Ort und Zeit. Dieser Wert liegt zwischen 0 (finster) und 100% (maximale Helligkeit an diesem Tag). Ich werwende dies schon seit geraumer Zeit, um meine Lichter automatisch einzuschalten und sie, bei einer bestimmten Helligkeit außen, ein konfiguriertes Maximum erreichen zu lassen.
- Funktion:
set <device> dimTwilight <twilight%>
stellt die Helligkeit der LED abhängig vom gegebenen Prozentwert ein. Diese Funktion muss aus einem NOTIFY auf twilight aufgerufen werden
bei mir tut das define NO_Twilight_Tick notify myTwiLight:twilight_weather:.* {if(Value("DU_homestatus") eq "home") {twilightDim($EVTPART1)}}
(in diesem Fall noch eine Routine in meiner 99_myUtils).
set <device> dimTwilightReset
setzt den internen Twilight Status zurück. Muss einmal während der "off" Phase passieren, wenn das Licht manuell abgeschaltet wurde. - Attribute
twilightDimOn [0|1] - Schalter, über den die Funktion für dieses Gerät an oder aus geschaltet werden kann
twilightDimHighThreshold [0-100] - Helligkeitswert, ab dem die Beleuchtung eingeschaltet wird
twilightDimLowThreshold [1-100] - Helligkeitswert, bei dem die Beleuchtung den vorgegebenen Wert erreichen soll
twilightDimHSV [0-359,0-100,0-100] - vorgegebener Wert, der bei twilightDimLowThreshold erreicht werden soll
twilightDimOffIsTwilight [0|1] - Schalter, der wählt, ob ein "set <device> off" das Gerät abschaltet, oder auf den twilight Wert zurücksetzt (nicht sicher, wie sinnvoll der ist)
- Automatisches Dimup/Dimback
Ich nutze gerne eine Funktion, in der einige LED als Nachtlicht / Orientierungslicht / Dekolicht bei Dunkelheit mit geringer Helligkeit leuchten (z.B. über das oben beschriebene twilightDim auf v=20% gesetzt) und dazu einen Bewegungssensor. Wenn eine Person den Raum betritt, sollte die Leuchte für eine gegebene Zeit auf einen definierten Farbwert gesetzt werden und danach wieder auf den vorherigen Wert abfallen. Diese Funktion ist der on-for-timer Funktion ähnlich, ich nenne sie erstmal genauso
- Funktion:
set <device> on-for-timer <time> - Attribute
Theoretisch sind hierfür keine neuen Attribute nötig, denn in der "on" Funktion haben wir bereits vernünftige Defaults.
Beide Funktionen würden einige Daten in Internals speichern (letzte Helligkeit vor einem on-for-timer, twilight Status etc.) Das sollte aber transparent sein.
Bei mir haben die beiden Funktionen momentan fast vollständig die Lichtschalter ersetzt und funktionieren prima. Wie gesagt, ich denke, im Modul wären sie ein bisschen hübscher aufgehoben und vielleicht auch für andere nutzbar.
Grüße
pj
Zitat von: pjakobs am 25 Dezember 2016, 13:15:05
@Shuzz ich denke, @RaspiLED ist auf der richtigen Fährte, schau Dir mal LightScenes an anstatt direkt den LEDController steuern zu wollen.
Ja, LightScenes sind eine Möglichkeit.
Mitterweile bin ich aber auch einen Schritt weiter: Mit dem Custom Skill funktioniert das Setzen von Farben direkt, Helligkeit ebenso.
Bin soweit erstmal zufrieden... ;)
Hi Shuzz,
Magst Du uns Dein Custom Skill in einem anderen Thread zeigen?
Bei Homebridge klappt mit das direkte setzen der Farbe mit der aktuellen Version und der Eve App oder Sprache jetzt auch direkt.
npm -g list homebridge
homebridge@0.4.16
npm -g list homebridge-fhem
homebridge-fhem@0.2.67
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Noch ein Gedanke zur Erweiterung des Moduls:
ich habe ein oder zwei Projekte, in denen ich die einzelnen Kanäle nicht als RGBWWCW Farbraum ansprechen will, sondern als einzelne Weißkanäle, quasi einzelne Devices. Das geschieht sinnvollerweise über den RAW Modus.
Die ursprüngliche Idee war, einen separaten Modus für diese Funktionsweise einzubauen, das ist mir momentan aber zu viel Aufwand.
Ein einfacherer Gedanke ist: die fünf "Devices" sind Dummies, die ihren Wert jeweils an einen definierten Kanal des LedController Moduls weitergeben. Damit das machbar ist, würde ich einen optionalen "mask" Wert oder eine Kanalnummer in den "set raw" Befehl einfügen.
Ich könnte mir also entweder
set <device> raw 512,512,512,512,512 5 vorstellen, was bedeuten würde setze die Kanäle, die über die binäre Maske (in diesem Fall 5=0b10001) gesetzt sind auf den Wert 512 - das ist ein bisschen aufwendig, da die Maske und die Position der Werte davor korrespondieren müssen, dafür könnte man mehrere Werte auf ein mal setzen.
oder, einfacher zu nutzen:
set <device> raw 512 4 was simplerweise wäre: setze den vierten Kanal auf 512.
Die erste Variante hätte den Charme, dass sie weitestgehend zur aktuellen Implementation von "set raw" kompatibel wäre, es käme halt nur die Maske dazu - die allerdings müsste sich ggf. von der Transition Zeit, die ja auch als freilaufender Skalar übergeben wird unterscheiden lassen. Ich wäre allerdings hier durchaus der Meinung, dass ich bei RAW eine inkompatible Lösung akzeptabel fänd, so viele dürften das nicht verwenden.
Damit das alles funktionieren kann, muss ich natürlich auch die aktuellen RAW Werte im Device vorhalten. (Es ist vielleicht sogar möglich, dem API nur partielle Werte zu übergeben, also z.B. explizit nur den Wert für den blauen Kanal zu setzen und alle anderen unverändert zu lassen, das muss ich mir ansehen)
Die Kernfrage ist aber: sollen die RAW Werte im Device als Readings sichtbar sein? Wir haben es schon ein paar mal diskutiert, es gibt zwischen RAW und HSV nicht immer ein sinnvolles bidirektionales Mapping (HSV kann immer auf RAW gemappt werden, nicht aber umgekehrt).
Wenn ich also RAW Werte setze, was soll dann mit den HSV Readings passieren? Ideen irgendwer?
Grüße
pj
Ohne direkte Unterstützung im Controller wird das glaube ich nicht sauber möglich sein.
Man könnte theoretisch den momentanen Betriebszustand (RGB/RGBW/RGBWWCW) des Controllers auslesen und dementsprechend die "ungenutzten" Kanäle per RAW ansprechen.
Je nach Betriebsmodus könnte man auch die Umrechnung RAW->HSV machen.
Als "korrekte" Umrechnung würde ich bezeichnen, wenn bei Umwandlung RAW->HSV->RAW der Input identisch zum Output ist.
- RAW nach HSV zurückrechnen geht nur für RGB problemlos. Modus "RGB" geht also.
- Ein Weißkanal wird kniffliger. Man kann einfach den Weißanteil auf RGB aufaddieren bis eine der drei Farben bei 0xFF steht ODER der Weißanteil noch "rein passt". Ist der Weißanteil "zu hoch" bekommt man einen Fehler rein. Als Näherung aber denke ich brauchbar, speziell wenn der Controller ansonsten nur per HSV angesteuert wird (dann sollte nämlich alles "passen").
Beispiele:
RAW 180/90/0/50 kann in HSV umgerechnet werden - RGBW 180/90/0/50 --> RGB 230/140/50 --> HSV 30/78.3/90.2
RAW 180/90/0/120 kann NICHT sauber umgerechnet werden: RGBW 180/90/0/120 --> RGB 255/165/75 Rest 45 --> HSV 30/70.6/100
- Zwei Weißkanäle laufen analog dem einen, es werden nur die beiden Weißwerte aufaddiert. Zu den Fehlern von oben kommt nun noch dazu, dass ggf. die Farbtemperatur nicht mehr stimmt. Der Fall ist aber eher akademisch, denn in diesem Modus ist ja gar kein Kanal mehr "frei" den man noch für andere Dinge verwenden könnte.
Was mir noch als Problem einfällt: Wie "rettet" man die RAW-Kanäle bei HSV Ansteuerung? Muss man das überhaupt? Oder lässt der Controller die entsprechenden Kanäle einfach in Ruhe?
(Beispiel: RGBW-Strip oben auf dem Schrank, der "freie" Kanal soll für Beleuchtung von Glasregalen im Schrank verwendet werden. Bei Änderung der Farbe des RGBW-Strips per "set hsv" soll die Beleuchtung der Regale nicht einfach ausgehen...)
Grüße,
Shuzz
Hi Shuzz,
an einen Mischbetrieb hatte ich da auch garnicht gedacht, der müsste ja tatsächlich in der Firmware hinterlegt sein. (hmm... nachher mal Patrick fragen).
Ich dachte wirklich an den einfachen Fall: fünf unabhängige LED Bänder, die aber eben auch völlig unabhängig voneinaner angesprochen werden können, d.h. wenn ich den dritten Kanal auf irgendeinen Wert setze, dann ändert das nichts an den anderen. Das lässt sich, wenn man strikt im RAW Mode bleibt, im Modul abfangen.
Ich überleg mal noch ein bisschen und wenn ich Zeit hab, bau ich vielleicht mal was.
pj
Ach so, ja.
Einzelne Bänder sollten sich so ansprechen lassen.
Da würde ich ggf. beide Varianten unterstützen, ja nach Anwendungsfall mag man nur einen oder mehrere Werte setzen.
Noch ne Idee dazu: set <DEV> raw 255,128,,0,0
Werte, die nicht verändert werden sollen lässt man einfach weg und fertig. Sind dann halt ggf. ein paar Kommata mehr, aber dafür spart man sich das maskieren.
Was den Mischbetrieb angeht: Solange der Controller beim setzen eines HSV Wertes die unbenutzten RAW-Kanäle in Ruhe lässt könnte man das schon machen. Da wäre ggf. auch nicht viel Arbeit in der FW für notwendig...
Grüße!
Zitat von: Shuzz am 10 Januar 2017, 22:23:22
Ach so, ja.
Einzelne Bänder sollten sich so ansprechen lassen.
Da würde ich ggf. beide Varianten unterstützen, ja nach Anwendungsfall mag man nur einen oder mehrere Werte setzen.
Noch ne Idee dazu: set <DEV> raw 255,128,,0,0
Werte, die nicht verändert werden sollen lässt man einfach weg und fertig. Sind dann halt ggf. ein paar Kommata mehr, aber dafür spart man sich das maskieren.
Was den Mischbetrieb angeht: Solange der Controller beim setzen eines HSV Wertes die unbenutzten RAW-Kanäle in Ruhe lässt könnte man das schon machen. Da wäre ggf. auch nicht viel Arbeit in der FW für notwendig...
Grüße!
ich glaub, Patrick wäre nicht undankbar, wenn jemand sich in die FW einarbeitet und da ein paar Dinge vorantreibt ;-)
pj
Zitat von: pjakobs am 10 Januar 2017, 22:42:32
ich glaub, Patrick wäre nicht undankbar, wenn jemand sich in die FW einarbeitet und da ein paar Dinge vorantreibt ;-)
pj
Aber... Aber... Aber... Die ist so kompliziert! :-\
;)
Zitat von: Shuzz am 11 Januar 2017, 10:18:34
Aber... Aber... Aber... Die ist so kompliziert! :-\
;)
ich glaube, sowas hab ich von Softwareentwicklern schonmal gehört ;-)
Zitat von: pjakobs am 11 Januar 2017, 11:10:11
ich glaube, sowas hab ich von Softwareentwicklern schonmal gehört ;-)
*seufz*
Ich bastel mir mal ein kleines Testbett zusammen und spiel' mal ein wenig herum...
Werde nur in nächster Zeit nicht all zu viel Freiraum dafür haben, mal sehen was bei rumkommt...
Zitat von: Shuzz am 11 Januar 2017, 19:29:14
*seufz*
Ich bastel mir mal ein kleines Testbett zusammen und spiel' mal ein wenig herum...
Werde nur in nächster Zeit nicht all zu viel Freiraum dafür haben, mal sehen was bei rumkommt...
nu mach mir kein schlechtes Gewissen, sonst hab ich am Ende noch das Gefühl, ich dräng Dich zu irgendwas ;-)
Softwareentwicklung ist Vergüngen - non?
pj
Zitat von: pjakobs am 11 Januar 2017, 21:04:30
Softwareentwicklung ist Vergüngen - non?
Mais oui. Nur die liebe Zeit ist derzeit knapp. Aber zumindest mein Testplatinchen läuft seit gestern, nun kann ich lokal damit spielen was die Sache schonmal sehr vereinfacht... ;)
Moin.
Ich hatte da mal eine Idee wo ich hier ein wenig gelesen habe.
Wenn auf dem Controller 5 Leistungskanäle enthalten sind, könnte man in dem Fhem-Modul einen Umschalter auf "Single Weiß Ansteuerung" implementieren? Somit bis zu 5 einzeln ansteuerbare Kanäle für nur-Weiß-Stripes vorhanden wären?
Das könnte ich bei mir an verschiedensten Stellen verwenden: Fußleistenbeleuchtung im Flur (nur 1 Controller statt 5), Terrassenbeleuchtung, Weihnachtsbeleuchtung, etc.
Sollte das zu abwegig sein, dann einfach sagen...
Gruß
AlexSchei
Zitat von: AlexSchei am 19 Januar 2017, 19:02:08
Moin.
Ich hatte da mal eine Idee wo ich hier ein wenig gelesen habe.
Wenn auf dem Controller 5 Leistungskanäle enthalten sind, könnte man in dem Fhem-Modul einen Umschalter auf "Single Weiß Ansteuerung" implementieren? Somit bis zu 5 einzeln ansteuerbare Kanäle für nur-Weiß-Stripes vorhanden wären?
Das könnte ich bei mir an verschiedensten Stellen verwenden: Fußleistenbeleuchtung im Flur (nur 1 Controller statt 5), Terrassenbeleuchtung, Weihnachtsbeleuchtung, etc.
Sollte das zu abwegig sein, dann einfach sagen...
Gruß
AlexSchei
Hi Alex,
ja, das ist eine Funktion, die ich von Anfang an im Kopf hatte. Ich habe nur noch keine gute Idee, wie ich das implementiere - eigentlich würde ich dafür gerne fünf einzelne fhem-Geräte haben, dazu kommt, dass wir vielleicht auch die Möglichkeit schaffen wollen, nur einen oder zwei Kanäle getrennt zu aktivieren, z.B. wenn Du RGBW benutzt und dazu den fünften Kanal gesondert verwendest.
Kommt bestimmt noch, die Frage ist nur - wann ;-)
pj
Hey Super!
Dann werde ich mal abwarten. Parallel schaue ich mir mal das vorhandene Modul mal an. Kenne zwar perl, aber fhem interna noch nicht. Vielleicht hab ich ja ne idee, ohne die Firmware des Controllers ändern zu müssen.
Ich hätte 2 Ansätze als idee.
1: Ein Fork des Moduls nur halt mit anderen Bedienelementen und Einstellungen.
2: Umschalter im aktuellen Modul auf andere Arbeitsweise.
Den Umschalter als Attribute.
attr <gerät> RGBW <kanal rot>,<kanal grün>,<kanal blau>,<kanal weiß>
Z.B. attr licht RGBW 2,4,3,0
Rot kanal 2
Grün kanal 4
Blau kanal 3
Weiß nicht verwendet.
attr <gerät> extraKanal1 <auswahl vorhandener kanäle>
Z.B. attr licht extraKanal1 1
Daraus erzeugt sich ein extra Gerät: z.B. licht.1
Insgesamt 5 extrakanäle
Das könnte sehr flexibel sein, allerdings auch sehr komplex.
Gruß Alex
Zitat von: AlexSchei am 19 Januar 2017, 23:25:16
Hey Super!
Dann werde ich mal abwarten. Parallel schaue ich mir mal das vorhandene Modul mal an. Kenne zwar perl, aber fhem interna noch nicht. Vielleicht hab ich ja ne idee, ohne die Firmware des Controllers ändern zu müssen.
Ich hätte 2 Ansätze als idee.
1: Ein Fork des Moduls nur halt mit anderen Bedienelementen und Einstellungen.
2: Umschalter im aktuellen Modul auf andere Arbeitsweise.
Den Umschalter als Attribute.
attr <gerät> RGBW <kanal rot>,<kanal grün>,<kanal blau>,<kanal weiß>
Z.B. attr licht RGBW 2,4,3,0
Rot kanal 2
Grün kanal 4
Blau kanal 3
Weiß nicht verwendet.
attr <gerät> extraKanal1 <auswahl vorhandener kanäle>
Z.B. attr licht extraKanal1 1
Daraus erzeugt sich ein extra Gerät: z.B. licht.1
Insgesamt 5 extrakanäle
Das könnte sehr flexibel sein, allerdings auch sehr komplex.
Gruß Alex
Ganz so einfach wird es nicht, da der Controller das Farbmanagement selbständig macht und dazu alle fünf Kanäle verwendet.
pj
Gesendet von meinem HTC 10 mit Tapatalk
Zitat von: pjakobs am 07 November 2016, 10:52:19
Ich hab mal meine aktuelle Version auf github gepusht, branch dev-pj
development branch:
Zitat
This branch is 10 commits ahead, 4 commits behind master.
Ich frage mich gerade welchen branch ich zur Mit- bzw. Weiterentwicklung auschecken sollte. master oder develop?
Zitat von: dev0 am 24 Januar 2017, 08:51:53
development branch:Ich frage mich gerade welchen branch ich zur Mit- bzw. Weiterentwicklung auschecken sollte. master oder develop?
ich *glaube*, dass die Commits, die Master voraus ist nur darin bestehen, dass ich das fhem update File dort extern upgedatet habe - es gibt also einen Commit, der direkt gegen master ging und ein paar Dateien außerhalb von 32_LedController.pm geändert hat.
In dem Fall war das nötig, damit der Update-Mechanismus für master funktioniert. Nachdem ich denke, dass develop jetzt seit ner ganzen Weile problemlos läuft, werd ich den einfach nach Master mergen, dann sollte das Problem behoben sein. Zumindest so lange, bis ich wieder irgendwas am Master drehe. Git treibt mich zuweilen in den Wahnsinn.
pj
Zitat von: pjakobs am 24 Januar 2017, 09:13:59
Git treibt mich zuweilen in den Wahnsinn.
Kenne ich ;) Und wenn man in dann der Github Online Hilfe sucht, dann wird man in einigen Fällen doch wieder auf die command line Variante verwiesen. Vielleicht sollte man grundsätzlich nur die command line Variante verwenden...
Ich habe den/die Threads zum Controller noch nicht komplett gelesen. Gibt es zZ. konkrete Baustellen oder Featurewünsche für das Modul, die angegang werden könnten?
Zitat von: dev0 am 24 Januar 2017, 10:07:33
Kenne ich ;) Und wenn man in dann der Github Online Hilfe sucht, dann wird man in einigen Fällen doch wieder auf die command line Variante verwiesen. Vielleicht sollte man grundsätzlich nur die command line Variante verwenden...
Ich habe den/die Threads zum Controller noch nicht komplett gelesen. Gibt es zZ. konkrete Baustellen oder Featurewünsche für das Modul, die angegang werden könnten?
@Shuzz hat neulich das Modul ziemlich aufgeräumt und was drin ist, funktioniert im Moment prima.
Zwei große Baustellen sind offen:
- Auftrennen von Kanälen (daran wird gerade auch in der Firmware gearbeitet). Die Idee ist: man kann den Controller, so wie es heute implementiert ist, als ein Vollfarb-Gerät verwenden und alles weitere passiert in der Firmware, aber: Viele nutzen nur einen Weiß-Kanal (RGBWW) und der zweite bleibt ungenutzt. Außerdem gibt es Anwendungen, in denen es interessant wäre, einen Controller als fünf verschiedene Geräte anzusprechen, ähnlich wie die Milight Controller mit WifiLight.
- Alles, was die Konfiguration und OTA des Controllers angeht.
- das API unterstützt Over The Air update, das Modul derzeit noch nicht
- das API kann, wenn ich es richtig gesehen habe, logging einschalten und ggf. die Logdaten zurückmelden (da bin ich nicht ganz sicher)
- wlan Konfiguration (wobei ich mir nicht sicher bin, ob das wirklich sinnvoll ist)
Es gibt sicher noch ein paar weitere Ideen, aber für einige brauchen wir Firmware Änderungen (gespeicherte Fades, seperate Fades für Kanäle etc)
pj
Danke Dir für die Infos, ich werde am Wochenende einen ESP auf einem Steckbrett verkabeln und dann weiter sehen.
Eine weitere Baustelle die mir gerade noch einfällt:
- Im Modul ein Interface zu schaffen um mehrere Fades in ein FHEM-Kommando zu packen. Das könnte zunächst in einzelne Requests aufgebrochen und verschickt werden. Wenn die Firmware später einmal direkten Support für Animationen bietet dann könnte man's darauf umbiegen.
Grüße,
Christian
Es ist aus meiner Sicht nicht empfehlenswert, Funktionen, die in den Controller gehören, im Modul (temporär) abzubilden. Ich habe mich auch schon dazu hinreißen lassen und mich im Nachhinein geärgert es gemacht zu haben. Es verkompliziert mMn den Modulcode unnötig und ist schwer wieder zu entfernen ohne dass der Anwender etwas umstellen muss. Neben diesen Umstellunen schleichen sich auch gerne wieder Fehler ein...
Wenn allerdings abzusehen ist, dass es nicht ein den Controller Code einfließen wird, dann ist es natürlich etwas anderes.
Zitat von: vbs am 18 März 2017, 11:47:15
Oje, ist etwas länger geworden, sorry schonmal dafür :-X
das wird noch mehr :D
Zitat von: vbs am 18 März 2017, 11:47:15
Ich denke, dass sich damit Fades nicht ohne weiteres abbilden lassen, oder?
Also vorweg: ich sehe da eigentlich weder mit der FHEM-Methode noch mit MQTT Probleme bzgl. der Latenz.
Bist du sicher wegen der FHEM-Queue? Ich hab nochmal drüber nachgedacht und ich bin jetzt eigentlich der Meinung, dass Befehle, die ein Modul per fhem() absetzt gar nicht durch die Event-Queue gehen, sondern direkt synchron ausgeführt werden.
fades sind, im aktuellen Zustand der LedController Firmware so oder so ein Problem, denn:
Der Controller kann ja eine ganze Folge von Fades (eben maximal 50 iirc) im lokalen Speicher haben, und die über eine lange Zeit hinweg abfahren (Minuten bis Stunden).
Die Idee mit einem "Output" MQTT Endpoint würde imho genau dieses Problem lösen: das Modul weiß nicht, was die
tatsächliche RAW/hsv Einstellung des Controllers zu einem bestimmten Zeitpunkt ist, es könnte aber MQTT nutzen, um diese Information zu bekommen. Dann ist es aber egal, ob ich das erst dem Modul übergebe oder gleich den Input eines (oder mehrerer) Controller damit füttere. Nicht die Fades würden so abgebildet, sondern der jeweilige Zustand des Master Controllers, was also auch ungleich laufende Uhren in den Controllern egalisieren würde.
Zitat von: vbs am 18 März 2017, 11:47:15
Außerdem, wenn man mal vergleicht, was in beiden Szenarien passiert wenn man einen Befehl an einen Master und einen (oder mehr Slaves) schicken möchte:
FHEM:
-> FHEM sendet nacheinander die HTTP-Requests non-blocking an alle Master und Slaves (ich denke sogar ohne Event-Queue dazwischen) -> fertig
MQTT:
-> FHEM sendet an den Master -> Master prozessiert Nachricht -> Master sendet an MQTT-Broker -> MQTT-Broker prozessiert Nachricht -> MQTT-Broker sendet an alle Slaves -> fertig
Ich kann mir nicht vorstellen, dass man mit dem MQTT-Ansatz kleinere Latenzen erreicht. Bitte korrigier mich, wenn ich etwas falsch dargestellt bzw. falsch verstanden habe.
s.o. - der MQTT Ansatz ist grundlegend anders als der, den Du gewählt hast.
Zitat von: vbs am 18 März 2017, 11:47:15
Darüberhinaus finde ich es im FHEM-Umfeld nicht so gut, Logik und/oder Konfiguration vom zentralen FHEM-Server in die Endgeräte zu verschieben, aber das mag Geschmackssache sein. Ich hab da Logik/Config gerne zentral im Zugriff.
Ich denke, da ist eine sinnvolle Balance gefragt. Die Architektur von fhem ist derart, dass man die Bearbeitungszeit in Modulen so kurz wie möglich halten sollte, wenn ich Aufgaben so in Geräte auslagern kann, dass sie sich sinnvoll verhalten, und ich dieses Verhalten auch von fhem aus kontrollieren kann, dann ist das imho durchaus sinnvoll.
In LedController wäre das z.B. ein "stop" Befehl, der jeden Fade sofort anhält und den aktuellen Farbwert beibehält. Das ist aktuell im Modul rudimentär umgesetzt und müsste eigentlich in die Firmware, damit wir nur noch ein "stop" Kommando an den Controller senden müssten.
Zitat von: vbs am 18 März 2017, 11:47:15
Ahh ok, verstehe. So einen Fall mit mehr als 3 Befehlen hatte ich bei mir noch nicht, aber klar, man kann auch 50 Befehle absetzen. Aber wenn man für den Fall optimieren will, wäre es dann nicht besser im Modul eine Schnittstelle zu schaffen, so dass man direkt mit einem set-Befehl mehrere LED-Befehle einliefern kann? So in der Art "set myLed HSB 100,100,100 4:150,20,100 4:50,100,100 2"? Ist vermutlich auch nicht sooo aufwendig. Da würde man schonmal den ganzen FHEM-Drumrum Overhead sparen. Im Idealfall könnte das Modul dann auch direkt an den Controller per API (HTTP/MQTT) mehrere Befehle absetzen.
Was schon länger für die Firmware geplant ist, sind gespeicherte Folgen von Fades. Sobald das da ist, werden wir es im Modul einbauen, da kannst Du dann eine Folge vorbereiten, im Controller ablegen und mit einem einzigen Kommando starten. (z.B. "set myLED run Sonnenaufgang")
Über die Idee, eine ganze Folge, wie Du es vorschlägst, in einem Kommando zu übergeben werd ich mal nachdenken, das gefällt mir...
Zitat von: vbs am 18 März 2017, 11:47:15
Außerdem kann man in FHEM längere Befehlskette aufbrechen, in dem man ein "sleep 0" einstreut. Damit baut ja FHEM ein internes "at" welches dann über die Event-Queue abgearbeitet wird. Damit könnten dann auch andere Events zwischendurch zum Zuge kommen (so als yield-Ersatz). Hatten das Thema hier neulich erst:
https://forum.fhem.de/index.php/topic,68350
oh, das hatte ich noch nicht gesehen. Das Problem in unserem Fall war:
die callback Events der asynchronen http messages wurden nicht ausgelöst, solange das Modul selbst noch mit dem cracken der Befehlszeile beschäftigt war, wenn aber noch ein NonBlockingGet in flight ist, wird offenbar kein neues ausgelöst, d.h. das http interface hängt, bis die ganze Zeile zerlegt und in neue Requests umgesetzt ist, dann wird die erste Response Message abgeholt und der Rest läuft durch.
----
Zitat von: vbs am 18 März 2017, 11:47:15
Ich denke, ich hab jetzt ganz gut verstanden, wie du dir das vorstelltst mit dem Auslagern in ein eigenes Modul, also danke erstmal für die Erklärung!Hm weiß nicht, ich denke schon, dass das zumindest schon recht modul-spezifisch sein wird (s.u.).
Also ich denke, dass man damit aber viele Sachen nachbauen würde, die es in FHEM sowieso schon gibt. Und auch recht grundlegende Funktionen dazu. Im Prinzip ist gibt es ja das, was dir vorschwebt schon ziemlich genau so in Form von "structure" (jedoch ohne die Transformationsschicht). Deinen ersten Punkt ("alle Slave Devices sollen das gleiche tun und verstehen die gleiche "Sprache") deckt das bestehende structure jetzt schon ab, denk ich.
Für die anderen Fälle müsste man es aufbohren und hätte dann mMn eine Art "structure 2.0" :) Wenn man das jedoch so bauen würde und da sehr generisch Befehle an mehrere verschiedenartige Geräte absetzen möchte, dann würde man das doch momentan in FHEM auch schon per notify/DOIF bauen können, oder?
Mir ist noch nicht ganz klar welche konkreten Einsatzszenarien es überhaupt dafür gibt, aber wenn ich, sagen wir, die Raumtemperatur auf 20°C schalten möchte, wenn jemand die LED auf "rot" setzt, dann ginge das doch schon mit einem notify recht einfach:
define nty notify wl_led:hsv 0,.* set wz_temp 20
(bitte mich nicht drauf festnageln, mag genau so evtl. nicht funktionieren, aber ich hoffe man versteht die Idee:))
Structure kannte ich noch garnicht (shame on me!) - ich hab ja nur auf Deinen Vorschlag hier reagiert.
Persönlich habe ich zwei Terassenlampen (leider MiLight über WifiLight), eigentlich einfache 220V Lampen, ausgestattet mit MiLight "Glühbirnen". Die Lampen haben zusätzlich einen Kranz von LED, die leuchten, sobald die Lampe "Strom hat" - logisch, sie ist ja auch dafür gedacht, über einen Schalter ein- und ausgeschaltet zu werden.
Ich hab sie also hinter einen unterputz HomeMatic 433MHz Schalter gehängt.
Im Grunde ist vieles, was wir hier gerade an Diskussion führen hier abgebildet:
define LED_Te dummy
attr LED_Te room Licht
attr LED_Te userReadings HSV, RGB
attr LED_Te webCmd RGB:RGB FFFFFF:RGB AFAFAF:RGB 7F7F7F:RGB 3F3F3F:RGB 000000:RGB 7f0000:RGB 007f27:RGB 0000ff
attr LED_Te widgetOverride RGB:colorpicker,HSV
define NO_Li_Te notify LED_Te.* {fhem("set LED_T1 $EVENT");;;;fhem("set LED_T2 $EVENT")}
attr NO_Li_Te room Licht,Regeln,Terasse
define NO_Li_Te_SW notify LED_T1:brightness:.*|LED_T2:brightness:.* {if($EVTPART1 != 0 and ReadingsVal("SW_Licht_Aussen", "state
attr NO_Li_Te_SW room Licht,Regeln
- Über den Dummy und NO_Li_Te kann ich beide Lampen gleichzeitig steuern
- Über die beiden individuellen Devices kann ich noch immer jede Lampe für sich steuern
- Der NO_Li_Te_SW kümmert sich darum, dass der 433MHz Schalter ein- und ausschaltet, abhängig vom status der Lampen
Das ließe sich vermutlich eleganter mit einem entsprechenden Master Modul konfigurieren, zumal ich immer wieder das Problem habe, dass der Schalter ja erst in Folge der Änderung an den Lampen geschaltet wird, die Controller der Lampen vorher ja aber keine Änderung empfangen können und deshalb zumindest der erste Befehl damit in's Leere läuft.
Ein Master / Slave könnte da ggf. eine sinnvollere Abfolge einhalten.
Zitat von: vbs am 18 März 2017, 11:47:15
Und das halte ich eigentlich für einfacher, also dafür ein Master-Modul zu definieren und dann per Attribut (vermutlich) recht komplexe Transformationsausdrücke zu definieren. Ich fürchte, dass die recht komplex sein müssen, weil das Modul ja sehr generisch sein soll und zwischen beliebigen Devices transformieren können soll. Damit geht mMn eine gewisse Komplexität einher. Dieser Ansatz mit dem notify wiederum klappt bei dem LedController mMn eben nicht so gut, nämlich wieder wegen den Fades. Man kann eben nicht auf hsv-Events lauschen (per notify) und diese dann 1:1 auf ein anderes LED-Gerät übertragen. Man muss das wirklich auf Befehlsebene machen, denk ich. Und darum denke ich, dass es doch irgendwie modulspezifisch ist.
Ein anderer Punkt sind die Readings: um mit dem LedController sinnvolle Logiken zu basteln, braucht man Zugriff auf die Readings. Wenn man nun ein separates Master-Modul baut, dann müsste man sich irgendwie auch überlegen, wie man den Zugriff auf Readings abbilden will. Wenn das dann auch entsprechend generisch sein soll, wird man da auch nochmal einiges an Transformationslogik reinstecken müssen.
Hmmm... Die Readings zu bekommen ist ja kein Problem, aber Du hast schon recht, sie generisch zu "verstehen" (also korrekt zu interpretieren) ggf. schon.
Zitat von: vbs am 18 März 2017, 11:47:15
Ich glaube der Aufhänger für diesen generischen Ansatz ist, dass LedController per Slave in der Lage ist WifiLight zu steuern, oder? Ich vermute, wenn das WifiLight da nicht vorgekommen wäre, hätte es sich für dich weniger unpassend angefühlt? Da würde ich dir teilweise zustimmen. LedController sollte eigentlich nicht das Interface von anderen Modulen kennen und die steuern können. Wenn man da konsequent wäre, könnte man diese Funktion auch wieder rausnehmen, so dass LedController nur andere LedController steuern könnte. Andererseits ist es auch ganz schick, dass man damit WifiLight mit abdeckt mMn. Bin unschlüssig :)
Der Aufhänger war: ich mag die Idee, ich habe tatsächlich, s.o., ein ähnliches Problem schon "mit Bordmitteln" gelöst, aber ich finde, dass das Problem selbst zu generisch ist, als dass man es in einem so spezifischen Modul wie 32_LedController lösen sollte.
Zitat von: vbs am 18 März 2017, 11:47:15
Oh mann, vermutlich mein längster Post ever :) Sorry, dass ich da an den meisten Stellen unterschiedlicher Meinung bin :( Ich finde die Diskussion jedoch an beiden Ecken sehr interessant!
Is völlig ok, Entschuldigungen fangen erst bei persönlichen Beleidigungen an, gutes Software Design ist eben nicht immer völlig simpel und hat viele Seiten.
Ich hätte ja auch einfach Deinen Pull Reqest akzeptieren können, aber ... ich bin da halt anderer Meinung ;-)
Grüße
pj
Zitat von: vbs
Zitat von: pjakobs am 19 März 2017, 10:56:16
Die Idee mit einem "Output" MQTT Endpoint würde imho genau dieses Problem lösen: das Modul weiß nicht, was die tatsächliche RAW/hsv Einstellung des Controllers zu einem bestimmten Zeitpunkt ist, es könnte aber MQTT nutzen, um diese Information zu bekommen. Dann ist es aber egal, ob ich das erst dem Modul übergebe oder gleich den Input eines (oder mehrerer) Controller damit füttere. Nicht die Fades würden so abgebildet, sondern der jeweilige Zustand des Master Controllers, was also auch ungleich laufende Uhren in den Controllern egalisieren würde.
Aber wie würden Fades dann in der Praxis funktionieren? Der Master gibt regelmäßig (mehrmals pro Sekunde?) seinen Zustand aus und die Slaves schalten dann immer "hart" auf diesen um? Ich finde es eigentlich sehr elegant, dass momentan die Fades innerhalb des Controllers ausgeführt werden.
Sorry, wenn ich nochmal "nachnerve", aber ich interessiere mich wirklich für diesen MQTT-Master-Slave-Ansatz. Hast du Lust, da nochmal 1-2 Sätze zu zu schreiben, wie du dir das vorstellst? Vielleicht werde ich dann auch bald MQTT-User :)
Argh ach du grüne Neune! Jetzt hab ich meinen letzten Post editiert und dadurch sozusagen gelöscht... wollte eigentlich nur einen unten dranhängen :'(
Ich hab die Diskussion nicht vergessen, im Moment hab ich nur ne Menge andere Dinge an der Backe, kommt noch 😉
Gesendet von meinem HTC 10 mit Tapatalk
ich hab mal ne Frage:
Im Video habt Ihr gesehen, dass ich bei einigen Controllern unterschiedliche Terminal Blocks liefern müsste - würde Euch das stören?
Die blauen bekomme ich als 3er Block nicht vor Ende April gelieferrt, die grünen zweier-Blocks könnte ich nachbestellen, allerdings zu einem Schweinepreis (fast 50ct pro Stück also 1,50 pro Controller)
Legt Ihr Wert darauf, dass die einheitlich sind, oder ist das Euch eher egal?
Grüße
pj
Nö .. mir ist das egal ... verschwindet eh in einem Gehäuse.
Mir ist das egal.
Hi, ist so doch so egal - Im Gegenteil DIY! ;-) Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Mir auch egal, Hauptsache billig ;D
PS.
Ich glaube, jetzt sind wir aber falsche hier im FHEM-Modul-Thread, oder? :)
Ja, die Verwirrung im Alter
Gesendet von meinem HTC 10 mit Tapatalk
Zitat von: vbs am 20 März 2017, 15:25:07
Aber wie würden Fades dann in der Praxis funktionieren? Der Master gibt regelmäßig (mehrmals pro Sekunde?) seinen Zustand aus und die Slaves schalten dann immer "hart" auf diesen um? Ich finde es eigentlich sehr elegant, dass momentan die Fades innerhalb des Controllers ausgeführt werden.
Sorry, wenn ich nochmal "nachnerve", aber ich interessiere mich wirklich für diesen MQTT-Master-Slave-Ansatz. Hast du Lust, da nochmal 1-2 Sätze zu zu schreiben, wie du dir das vorstellst? Vielleicht werde ich dann auch bald MQTT-User :)
ich hab's nicht vergessen, lass uns die Tage mal mit pf@nne zusammen schauen, wie wir das voran bringen können.
Ich hatte mit ihm darüber gesprochen und ich glaube, so problematisch wird das nicht werden. Im Moment ist mein Hauptproblem, dass ich keine Umgebung habe, in der ich die Firmware bauen kann, die müsste erstmal an das neue SMING Framework angepasst werden, und dazu verstehe ich sie noch nicht gut genug.
Grüße
pj
(BTW: Du hast ja einen Sack voll Controller bestellt, ich hoffe, dass ich die nächste Woche raus bekomme)
Klasse, freut mich!
Hier ist ein Stand der Firmware, der mit Sming 3.1.2 funtktioniert (falls das hilft):
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/sming_3.1.2
Zitat von: vbs am 06 April 2017, 15:11:25
Klasse, freut mich!
Hier ist ein Stand der Firmware, der mit Sming 3.1.2 funtktioniert (falls das hilft):
https://github.com/verybadsoldier/esp_rgbww_firmware/tree/sming_3.1.2
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware# make
C+ app/application.cpp
In file included from include/RGBWWCtrl.h:60:0,
from app/application.cpp:23:
include/config.h:44:17: error: 'DEFAULT_UDP_PORT' was not declared in this scope
int port = DEFAULT_UDP_PORT;
^
include/config.h:49:16: error: 'DEFAULT_TCP_PORT' was not declared in this scope
int port = DEFAULT_TCP_PORT;
^
In file included from /workspace/Sming/Sming/system/include/esp_systemapi.h:22:0,
from include/user_config.h:29,
from include/RGBWWCtrl.h:55,
from app/application.cpp:23:
/workspace/Sming/Sming/system/include/debug_progmem.h:36:13: error: expected identifier before numeric constant
#define ERR 0
^
include/networking.h:31:2: note: in expansion of macro 'ERR'
ERR = 3
^
/workspace/Sming/Sming/system/include/debug_progmem.h:36:13: error: expected '}' before numeric constant
#define ERR 0
^
include/networking.h:31:2: note: in expansion of macro 'ERR'
ERR = 3
^
/workspace/Sming/Sming/system/include/debug_progmem.h:36:13: error: expected unqualified-id before numeric constant
#define ERR 0
^
include/networking.h:31:2: note: in expansion of macro 'ERR'
ERR = 3
^
In file included from include/RGBWWCtrl.h:62:0,
from app/application.cpp:23:
include/networking.h:32:1: error: expected declaration before '}' token
};
^
/workspace/Sming/Sming/Makefile-rboot.mk:552: recipe for target 'out/build/app/application.o' failed
make: *** [out/build/app/application.o] Error 1
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware#
hmm...
welchen Branch schlägst Du vor?
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware# git branch -a
* (HEAD detached at origin/feature/mqtt-client)
develop
feature/mqtt-client
master
remotes/origin/HEAD -> origin/master
remotes/origin/arduino-framework-deprecated
remotes/origin/develop
remotes/origin/feature/mqtt-client
remotes/origin/gh-pages
remotes/origin/master
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware#
pj
Haben uns da scheinbar missverstanden, du bist ja offenbar auf "(HEAD detached at origin/feature/mqtt-client)". Der Branch, den ich meinte, heißt "sming_3.1.2" aus meinem Repo.
Das Sming 3.2.1 inklusive der RGBWW-Library hast du schon gebaut?
Zitat von: vbs am 06 April 2017, 17:11:55
Haben uns da scheinbar missverstanden, du bist ja offenbar auf "(HEAD detached at origin/feature/mqtt-client)". Der Branch, den ich meinte, heißt "sming_3.1.2" aus meinem Repo.
Das Sming 3.2.1 inklusive der RGBWW-Library hast du schon gebaut?
ah, ich hatte Dein Repo geforked, aber weil ich schon einen eignen, direkten Clone von Patrick hatte, hat github das wohl nicht gemacht. Wieder was gelernt.
Jetzt hab ich Deines direkt gecloned, stoße jetzt aber wieder auf den Fehler, den ich neulich schon hatte...
Switched to a new branch 'sming_3.1.2'
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware# make
C+ app/application.cpp
C+ app/ledctrl.cpp
C+ app/mqtt.cpp
C+ app/otaupdate.cpp
app/otaupdate.cpp: In member function 'void ApplicationOTA::start(String, String)':
app/otaupdate.cpp:50:80: error: 'otaUpdateDelegate' was not declared in this scope
otaUpdater->setCallback(otaUpdateDelegate(&ApplicationOTA::rBootCallback, this));
^
/workspace/Sming/Sming/Makefile-rboot.mk:552: recipe for target 'out/build/app/otaupdate.o' failed
make: *** [out/build/app/otaupdate.o] Error 1
Ich hab's nicht ganz ergründet, aber wenn ich das richtig verstanden habe, dann hat sich im aktuellen Sming framework etws an den Delegates geändert.
pj
Kann es sein dass du das repo geclonet hast, aber nicht in den branch gewechselt bist?
Edit
Doch hast, übersehen... Gucke gleich nochmal. Gerade an ner bahnschienen
Zitat von: vbs am 06 April 2017, 17:56:31
Kann es sein dass du das repo geclonet hast, aber nicht in den branch gewechselt bist?
Edit
Doch hast, übersehen... Gucke gleich nochmal. Gerade an ner bahnschienen
Bahnschiene???? :o
Ja, stand an einem Bahnübergang ;)
Nur zur Sicherheit: du baust wirklich gegen Sming 3.1.2, hast das einmal durchgebaut und hast das auch als SMING_HOME gesetzt, oder?
Zitat von: vbs am 06 April 2017, 18:17:04
Ja, stand an einem Bahnübergang ;)
Nur zur Sicherheit: du baust wirklich gegen Sming 3.1.2, hast das einmal durchgebaut und hast das auch als SMING_HOME gesetzt, oder?
Ich hab einen SMING Docker Container von https://github.com/SmingHub/Sming/tree/develop/docker in dem, wenn ich das richtig sehe, eine funktionierende Build Umgebung liegt.
Und wenn ich das richtig sehe baut er ja zumindest die sming rboot Klamotten...
Wenn ich SMING_HOME falsch setze, dann failt er auch gleich übelst:
9e4db335c4c9:/workspace/RGBWW/esp_rgbww_firmware# make
Makefile:43: /workspace/Sming/Makefile-rboot.mk: No such file or directory
make: *** No rule to make target '/workspace/Sming/Makefile-rboot.mk'. Stop.
pj
Guck mal bitte in dieses File:
vbs@ubuntu:~/Projects/Sming$ cat Sming/SmingCore/Network/rBootHttpUpdate.h
/*
* rBootHttpUpdate.h
*
* Created on: 2015/09/03.
* Author: Richard A Burton & Anakod
*/
#ifndef SMINGCORE_NETWORK_RBOOTHTTPUPDATE_H_
#define SMINGCORE_NETWORK_RBOOTHTTPUPDATE_H_
#include "HttpClient.h"
#include <Timer.h>
#include <rboot-api.h>
#define NO_ROM_SWITCH 0xff
class rBootHttpUpdate;
//typedef void (*otaCallback)(bool result);
typedef Delegate<void(rBootHttpUpdate& client, bool result)> otaUpdateDelegate;
struct rBootHttpUpdateItem {
String url;
uint32_t targetOffset;
int size;
};
Ob dort otaUpdateDelegate definiert ist:
typedef Delegate<void(rBootHttpUpdate& client, bool result)> otaUpdateDelegate;
Patrick hat seinerzeit ein paar Änderungen an Sming gemacht. Ich hab seine Änderungen hier auch auf 3.1.2 rebaset:
https://github.com/verybadsoldier/Sming/commits/rgbwwdev_sming_3.1.2
Aber bauen sollte es auch mit dem original 3.1.2.
//typedef void (*otaCallback)(bool result);
typedef Delegate<void(rBootHttpUpdate& client, bool result)> OtaUpdateDelegate;
errmm.. ja, soweit war ich auch schonmal, das eine ist ota, das andere Ota, wenn ich mich recht entsinne gab's kurz danach einen parameter error :/
pj
Sieht mir dann nach einem seltsamen Stand von Sming aus. Im "echten" Sming 3.1.2 heißt es auch "otaUpdateDelegate":
https://github.com/verybadsoldier/Sming/blob/3.1.2/Sming/SmingCore/Network/rBootHttpUpdate.h#L21
Zitat von: vbs am 06 April 2017, 18:49:23
Sieht mir dann nach einem seltsamen Stand von Sming aus. Im "echten" Sming 3.1.2 heißt es auch "otaUpdateDelegate":
https://github.com/verybadsoldier/Sming/blob/3.1.2/Sming/SmingCore/Network/rBootHttpUpdate.h#L21
hmf.. SmingCore.h behauptet
#define SMING_VERSION "3.1.2" // Major Minor Sub
but what do I know.
Du scheinst auf dem develop-Branch von Sming zu sein. Also neuer als 3.1.2. Dort wird es groß geschrieben:
https://github.com/verybadsoldier/Sming/blob/develop/Sming/SmingCore/Network/rBootHttpUpdate.h#L21 (https://github.com/verybadsoldier/Sming/blob/develop/Sming/SmingCore/Network/rBootHttpUpdate.h#L21)
Zitat von: vbs am 06 April 2017, 19:06:48
Du scheinst auf dem develop-Branch von Sming zu sein. Also neuer als 3.1.2. Dort wird es groß geschrieben:
https://github.com/verybadsoldier/Sming/blob/develop/Sming/SmingCore/Network/rBootHttpUpdate.h#L21 (https://github.com/verybadsoldier/Sming/blob/develop/Sming/SmingCore/Network/rBootHttpUpdate.h#L21)
Dann wäre es ja wohl sinnvoll, damit weiter zu machen?
Gesendet von meinem HTC 10 mit Tapatalk
Meiner Meinung nach eigentlich nicht so sehr, da der develop-Branch eben der tagesaktuelle Entwicklungsstand ist. Da können täglich Änderungen reinkommen die die API verändern (wie wir gerade am eigenen Leib erfahren haben :) ) oder sogar Bugs, die das ganze Framework instabil/unbrauchbar machen in dem Moment. Daher bin ich sehr dafür, sich an die getaggten, freigegebenen Versionen zu halten.
Hat das dann eigentlich noch geklappt mit dem Sming 3.1.2?
Zitat von: vbs am 09 April 2017, 11:40:07
Hat das dann eigentlich noch geklappt mit dem Sming 3.1.2?
Ich kämpfe noch daran.
Gesendet von meinem HTC 10 mit Tapatalk
Sag Bescheid, falls man irgendwie helfen kann.
Also zu dem MQTT/Broadcast-Ansatz:
Wie würdet ihr das machen wollen? Der Master schickt seinen Zustand an die Slaves und die Slaves schalten darauf um oder gibts da noch andere Ansätze?
Wenn man das genau so machen würde, dann müssten alle Slaves (während Fades) permanent 20 Nachrichten pro Sekunde empfangen, damit sie genau so sauber faden wie der Master.
Aus dem Sammelbestell-Thread übernommen:
Mehrere Controller direkt synchronisieren zu können wäre ein tolles Feature! MQTT oder eine andere zentrale Vermittlung ist, ans meiner Sicht, dafür aber der falsche Ansatz, da
- kein standanlone Betrieb (ohne 24/7 Server)
- unnötiger single point of failure
- aufwendiger einzurichten
- zusätzliche Latenz
Eine Alternative, ohne den Umweg über einen Server (zB. MQTT) zu gehen, wäre UDP Broadcasts zu nutzen. Im ESPEasy Framework findet man diese Lösung bereits in umgesetzter Form. Wäre das nicht vielleicht der elegantere Weg?
Zitat von: pjakobs am 11 April 2017, 07:49:20
Das Argument "Server nötig" verstehe ich nicht. Bei mir läuft der MQTT Broker auf dem gleichen RaspberryPi wie fhem selbst. Mir wäre MQTT gerade deshalb sympathisch, weil es sich in die vorhandene Landschaft, die wohl viele fhem Nutzer so haben, prima einfügt.
Es geht mir nicht nur um den zusätzlich Broker Dienst, sondern darum, dass es (wie zB. bei Homematic) unabhängig von einem Server/FHEM funktioniert.
Zitat von: vbs am 11 April 2017, 09:16:27
Also zu dem MQTT/Broadcast-Ansatz:
Wie würdet ihr das machen wollen? Der Master schickt seinen Zustand an die Slaves und die Slaves schalten darauf
Ich dachte eher daran, dass der Sollzustand bzw. das selbe Kommando das der Master empfangt geschickt wird. Das Faden bspw. sollte der Slave dann selbst dürchführen.
Zitat von: dev0 am 11 April 2017, 09:25:02
Ich dachte eher daran, dass der Sollzustand bzw. das selbe Kommando das der Master empfangt geschickt wird. Das Faden bspw. sollte der Slave dann selbst dürchführen.
dann hast Du, zumindest theoretisch, das Problem, dass die Fades auseinanderlaufen können, wenn die ESPs nicht synchron laufen. Wenn ein Master mehrere Slaves mit *aktuellen* Kanalwerten versorgt, fällt das weg.
Was Du suchst hat @vbs in einem experimentellen FHEM Modul implementiert, allerdings bin ich nicht überzeugt, dass es dahin gehört.
Wie nutzt Du denn die Controller, wenn Du nicht irgendeinen Server einsetzt? Direkt über die Firmware Oberfläche?
Ich bin durchaus interessiert daran, andere Nutzungsmöglichkeiten zu eröffnen (Mobiltelefon App, openHAB, nodeRED etc) und auch dort glaube ich, dass MQTT in vielen Fällen der einfachere Weg ist (ok, nicht für die Mobiltelefone).
pj
Zitat von: pjakobs am 11 April 2017, 09:33:35
dann hast Du, zumindest theoretisch, das Problem, dass die Fades auseinanderlaufen können, wenn die ESPs nicht synchron laufen. Wenn ein Master mehrere Slaves mit *aktuellen* Kanalwerten versorgt, fällt das weg.
Ich kann mir im Moment nicht vorstellen warum die beiden Varianten mehr/weniger auseinander laufen sollten. Ob der Steuerbefehl oder die aktuellen Daten verzögert ankommen wirkt sich doch gleich aus. Wenn man nur den Steuerbefehl schickt, ist der Traffic zumindest geringer, der verarbeitet werden muss.
Zitat
Wie nutzt Du denn die Controller, wenn Du nicht irgendeinen Server einsetzt? Direkt über die Firmware Oberfläche?
Hauptsächich natürlich über FHEM, allerdings wäre der nächste Schritt ein (Touch-)Wandschalter, der direkt mit dem RGBWW Controller spricht um die gleiche Unhabhängigkeit von FHEM zu erreichen wie zB. mit Homematic: alles geht auch ohne FHEM, nur eben nicht automatisiert.
Zitat von: dev0 am 11 April 2017, 09:44:45
Ich kann mir im Moment nicht vorstellen warum die beiden Varianten mehr/weniger auseinander laufen sollten. Ob der Steuerbefehl oder die aktuellen Daten verzögert ankommen wirkt sich doch gleich aus. Wenn man nur den Steuerbefehl schickt, ist der Traffic zumindest geringer, der verarbeitet werden muss.
Geht dabei weniger um die Netzwerklatenz, sondern um die Clocks der Geräte. Wenn zwei Geräte einen langen Fade synchron ausführen sollen (sagen wir 6h lang), dann müssen die Quarze halt einen sehr guten Gleichlauf haben.
Das Problem hat man tatsächlich gar nicht, wenn die Master regelmäßig ihren Zustand posten und alle Slaves hart darauf umschalten. Dann steckt praktisch keine Logik mehr in den Slaves. Bin da aber auch kein Freund von u.a. wegen dem genannten Konfigurationswissen, was dann in den Controllern verteilt wird. Außerdem finde ich es unschön, dass die Slaves permanent mit 20 NAchrichten pro Sekunde "gefüttert" werden müssten.
Man sollte mMn erstmal rausfinden, wie ungleich die Controller in der Praxis wirklich laufen. Ansonsten zerbricht man sich evtl. den Kopf über ungelegte Eier. ISt auch die Frage welche Länge an Fades man bedienen will. Will man wirklich 3-Tages-Fades supporten oder reichen 3 Stunden? Man könnte dann einfach nach 3 Stunden den Fade neu anstoßen und damit neu synchronsieren.
Hi,
das Problem hat doch eigentlich zwei Komponenten.
a) Kurze Fades (<1 Minute):
Keine Synchronisation notwendig, nur der Set Befehl muss verteilt werden
b) Lange Fades:
Hier könnte man:
1) An einem Master den gesamten Fade rechnen und jede Minute einen Set Befehl an Slaves versenden (Mein Favorit)
2) ein Master rechnet und gibt jedem Zustand weiter -》Viel Funkverkehr
3) alle bekommen Set Befehl und laufen über lange Zeit auseinander. Meine Lösungsidee: Synchronisation zwischen Controllern ermöglichen (Entweder über Master Slaves Ansätze: mqtt oder udp oder einfach über fhem reading?) aber noch besser wäre dass alle Controller gleichberechtigt sind, selbstständig als Broadcast nach Status fragen können und Antworten von anderen Controllern hören und sich dann anpassen. (Analog zu DHCP Anfragen)
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: RaspiLED am 11 April 2017, 10:46:47
Hi,
das Problem hat doch eigentlich zwei Komponenten.
a) Kurze Fades (<1 Minute):
Keine Synchronisation notwendig, nur der Set Befehl muss verteilt werden
b) Lange Fades:
Hier könnte man:
1) An einem Master den gesamten Fade rechnen und jede Minute einen Set Befehl an Slaves versenden (Mein Favorit)
2) ein Master rechnet und gibt jedem Zustand weiter -》Viel Funkverkehr
3) alle bekommen Set Befehl und laufen über lange Zeit auseinander. Meine Lösungsidee: Synchronisation zwischen Controllern ermöglichen (Entweder über Master Slaves Ansätze: mqtt oder udp oder einfach über fhem reading?) aber noch besser wäre dass alle Controller gleichberechtigt sind, selbstständig als Broadcast nach Status fragen können und Antworten von anderen Controllern hören und sich dann anpassen. (Analog zu DHCP Anfragen)
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Fades werden in der Firmware ja mit 50Hz berechnet uns ausgeführt, und da die ESP 10Bit PWM verwenden ist ein Fade maximal 1023 Schritte lang, d.h. der "schlimmste" Zustand ist ein 20 Sekunden Fade über den gesamten Helligkeitsbereich eines Kanals, der dann etwa 20s lang 50 Messages pro Sekunde erzeugt. Bei schnelleren Fades kommen zwar immer noch 50MQTT Updates pro Sekunde, aber die Schrittweite ist größer, das heißt insgesamt sind es weniger Nachrichten, bei längeren Fades wäre es natürlich sinnvoll, nur für Änderungen eine Message rauszusenden. Bei 20 Minuten wäre das nur noch etwas weniger als eine Nachricht pro Sekunde.
Und zur Konfiguration: die würde man natürlich sinnvollerweise im FHEM Modul unterbringen und dort ein- und ausschaltbar machen, so dass die Konfiguration zwar auf den Controllern umgesetzt, aber zentral verwaltet werden würde.
pj
Zitat von: pjakobs am 11 April 2017, 10:52:34
Fades werden in der Firmware ja mit 50Hz berechnet uns ausgeführt, und da die ESP 10Bit PWM verwenden ist ein Fade maximal 1023 Schritte lang, d.h. der "schlimmste" Zustand ist ein 20 Sekunden Fade über den gesamten Helligkeitsbereich eines Kanals, der dann etwa 20s lang 50 Messages pro Sekunde erzeugt.
Das stimmt zwar, aber nur für einen einzelnen Fade. Wenn der Controller aber z.B. einfach den Hue immer durchrotiert (z.B. Discomodus), dann hast du einfach permanent die 50 Nachrichten pro Sekunde (richtigerweise 50 und nicht wie ich schrieb 20 :) ).
Zitat von: vbs am 11 April 2017, 11:00:28
Das stimmt zwar, aber nur für einen einzelnen Fade. Wenn der Controller aber z.B. einfach den Hue immer durchrotiert (z.B. Discomodus), dann hast du einfach permanent die 50 Nachrichten pro Sekunde (richtigerweise 50 und nicht wie ich schrieb 20 :) ).
Das ist aber auch schwierig, wenn der gleiche Befehl zentral abgesetzt wird, denn dann musst Du ja auf ein Synchronisationssignal der Controller warten (bzw. der loop / predefined animatio Mode muss implementiert sein).
pj
Guten Tag zusammen,
ich möchte mich gern wieder zurück melden... ;)
Hatte die letzten Wochen/Monate privat einiges um die Ohren und hatte keine Zeit mehr für den Controller (FHEM und FW).
Nach allem was ich so lese hat sich der Status seit Januar aber nicht gravierend geändert oder?
Gut finde ich die FW auf dem 3.1.2er Sming Framework. Ich werde die Tage mal versuchen, das nachzuvollziehen und zu bauen.
Kurzer Hinweis zu den "vordefinierten" Animationen: Die wird es so nicht geben laut Patrick Jahns.
Seine Idee ist, einen kompletten Fade in einen einzigen HTTP POST zu packen - mehr aber auch nicht.
Auf den Controllern soll nichts gespeichert werden weil er der Meinung ist, das gehöre dort nicht hin sondern soll im FHEM Modul (oder sonstwo, jedenfalls nicht im Controller) verbleiben.
Sonst müsste man ja schließlich die Animationen immer auf allen Controllern synchron halten usw. usf.
Das war jedenfalls der Stand als ich das letzte Mal Kontakt zu ihm hatte, iwann Ende Januar.
Zumindest sollen diese Animationen dann aber loopen können, was ja schonmal etwas wäre.
Den MQTT Ansatz zur Synchronisierung finde ich eigentlich sehr schnuckelig, und viel effizienter als per Publish/Subscribe kriegt man viele Geräte eh nicht synchronisiert.
Selbst wenn da 50 Nachrichten pro Sekunde und Controller über's WLAN gehen - wäre das schlimm?
Ist ja nicht wie bei den 433/868MHz Standards, dass man nur eine gewisse Anzahl an Telegrammen senden darf...
Ich denke, selbst bei relativ großen Installationen sollte ein handelsübliches Home-Wifi da locker mithalten können.
Beste Grüße,
Shuzz
Zitat von: Shuzz am 11 April 2017, 19:28:07
Guten Tag zusammen,
ich möchte mich gern wieder zurück melden... ;)
Hatte die letzten Wochen/Monate privat einiges um die Ohren und hatte keine Zeit mehr für den Controller (FHEM und FW).
Nach allem was ich so lese hat sich der Status seit Januar aber nicht gravierend geändert oder?
Gut finde ich die FW auf dem 3.1.2er Sming Framework. Ich werde die Tage mal versuchen, das nachzuvollziehen und zu bauen.
Kurzer Hinweis zu den "vordefinierten" Animationen: Die wird es so nicht geben laut Patrick Jahns.
Seine Idee ist, einen kompletten Fade in einen einzigen HTTP POST zu packen - mehr aber auch nicht.
Auf den Controllern soll nichts gespeichert werden weil er der Meinung ist, das gehöre dort nicht hin sondern soll im FHEM Modul (oder sonstwo, jedenfalls nicht im Controller) verbleiben.
Sonst müsste man ja schließlich die Animationen immer auf allen Controllern synchron halten usw. usf.
Das war jedenfalls der Stand als ich das letzte Mal Kontakt zu ihm hatte, iwann Ende Januar.
Zumindest sollen diese Animationen dann aber loopen können, was ja schonmal etwas wäre.
Den MQTT Ansatz zur Synchronisierung finde ich eigentlich sehr schnuckelig, und viel effizienter als per Publish/Subscribe kriegt man viele Geräte eh nicht synchronisiert.
Selbst wenn da 50 Nachrichten pro Sekunde und Controller über's WLAN gehen - wäre das schlimm?
Ist ja nicht wie bei den 433/868MHz Standards, dass man nur eine gewisse Anzahl an Telegrammen senden darf...
Ich denke, selbst bei relativ großen Installationen sollte ein handelsübliches Home-Wifi da locker mithalten können.
Beste Grüße,
Shuzz
hey Shuzz, welcome back!
wir nehmen gerade wieder Fahrt auf! Mit pf@nne und @vbs hatte ich ein paar Firmware Enhancements besprochen.
Mal sehen, wie wir das koordiniert bekommen!
Dein Karton war heute schon fast fertig, dann fehlte aber noch ein Controller, sollte vielleicht noch vor Ostern klappen!
pj
Hey Leute,
ich muss nun hier nochmal die Frage stellen, da grad wieder Schwung in die FW/Modul-Entwicklung kommt.
Welchen Aufwand würde die Implementierung eines neuen Befehls "stop" in die Firmware bedeuten? Ziel sollte sein, eine aktuell laufende Animation zu stoppen, den Zustand zu halten und die Werte der Kanäle zu publishen um z.B. in FHEM die Farbwerte aktuell zu halten.
VG funclass
Mal eine Frage:
In dem Modul kommt an mehreren Stellen vor "( $fadeTime == 0 ) ? 'solid' : 'fade'". Also ob Modus 'solid' oder 'fade' gewählt wird, wird nur implizit über die fadeTime geregelt. Das verstehe ich nicht so richtig, da man ja dadurch gar keine solid-Time nutzen kann, oder? Also ich kann nicht sagen "HSV xyz für 20 Sekunden halten" (als solid), da durch die Angabe "20 Sekunden" immer ein _Fade_ auf xyz (anstelle von solid) ausgeführt würde, oder?
Zitat von: vbs am 12 April 2017, 08:06:59
Mal eine Frage:
In dem Modul kommt an mehreren Stellen vor "( $fadeTime == 0 ) ? 'solid' : 'fade'". Also ob Modus 'solid' oder 'fade' gewählt wird, wird nur implizit über die fadeTime geregelt. Das verstehe ich nicht so richtig, da man ja dadurch gar keine solid-Time nutzen kann, oder? Also ich kann nicht sagen "HSV xyz für 20 Sekunden halten" (als solid), da durch die Angabe "20 Sekunden" immer ein _Fade_ auf xyz (anstelle von solid) ausgeführt würde, oder?
Wenn ich mich recht entsinne, dann habe ich aber auch ein 'pause' kommando eingebaut das eigentlich 'solid' verwenden sollte, damals gab es aber noch einen Bug in der Firmware weshalb ich das erst mit minimalem fade gelöst hatte...
Ich muss mal wieder reinschauen.
pj
Gesendet von meinem HTC 10 mit Tapatalk
Ok danke, verstehe. Wobei sich die solid/fade-Frage eigentlich durch alle Befehle zieht: hsv,rgb,raw,on,off,rotate,dimup,dimdown,hue,... Das lässt sich mMn wohl nicht immer durch pause ersetzen. Ich bin jetzt mit der FW erstmal für den Moment durch und mache mich nun über das FHEM-Modul her... hab jetzt für 'solid' erstmal ein neues Flag 's' eingeführt, ansonsten ist 'fade' default.
Wie würdest Du 'solid' bei rotate, dimup, dimdown etc interpretiertieren?
Gesendet von meinem HTC 10 mit Tapatalk
Hi,
Wäre solid 20 sec nicht eigentlich ein on-for-timer 20 sec?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.
ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s
dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s
rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s
rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s
(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)
Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.
So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut :o
Gute Frage, ich hätte solid immer nur im Kontext einer Queue gesehen, eben im Sinne von 'pause'. On-for-timer würde ich immer mit fhem Bordmitteln machen. Zudem ich mir nicht sicher bin, ob die maximale fade Zeit des Controllers dafür genügt, denn intern zählt der Millisekunden und ich weiß nicht, ob das 32Bit sind. Wenn ja, dann wäre das maximum allerdings ausreichend mit ca. 4 Millionen Sekunden...
Gesendet von meinem HTC 10 mit Tapatalk
Zitat von: vbs am 12 April 2017, 09:16:48
Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.
ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s
dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s
rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s
rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s
(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)
Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.
So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut :o
im fhemmodule hatten wir das so gelöst:
elsif ($cmd eq 'pause'){
# For use in queued fades.
# Will stay at the current color for $fadetime seconds.
# NOTE: Does not make sense without $doQueue == "true".
# TODO: Add a check for queueing = true? Or just execute anyway?
my $val = InternalVal($hash->{NAME}, "valValue", 0);
my $hue = InternalVal($hash->{NAME}, "hueValue", 0);
my $sat = InternalVal($hash->{NAME}, "satValue", 0);
if ($fadeTime eq 0 || $doQueue eq 'false'){
Log3 ($hash, 3, "$hash->{NAME} Note: pause only makes sense if fadeTime is > 0 AND if queueing is activated for command!");
}
LedController_SetHSVColor($hash, $hue, $sat, $val, $colorTemp, $fadeTime, 'solid', $doQueue, $direction);
auf diese Weise lässt sich das, was Du willst stets mit zwei Befehlen lösen
set <light> hsv 10,70,50 0
set <light> pause 20 q
set <light> rotate 70 10 q
ich selbst finde das verständlicher, aber es stimmt schon, ein weiteres Flag wäre vermutlich näher an der API.
pj
[update]
ich hab gerade nochmal in's Modul reingeschaut, wenn Du das "s" (oder lieber "h" für "hold" wegen der Verwechslung mit Sekunden) in die ArgsHelper Routine integrierst, dann wäre das für das ganze Interface erstmal kompatibel und böte die entsprechende Funktionalität.
pj
Verstehe, ok, so geht's sicherlich auch! Die Option hab ich jetzt aber nicht mehr, da es den pause-Befehl so nicht mehr gibt bei mir :-X (warum gibts eigentlich hier keinen Smiley mit ausgeschlagenen Zähnen?)
EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!
Zitat von: vbs am 12 April 2017, 09:46:06
Verstehe, ok, so geht's sicherlich auch! Die Option hab ich jetzt aber nicht mehr, da es den pause-Befehl so nicht mehr gibt bei mir :-X (warum gibts eigentlich hier keinen Smiley mit ausgeschlagenen Zähnen?)
EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!
warum gibt's den 'pause' Befehl nicht mehr? Der ist doch nichts anderes als "setze die Werte, die aktuell sowieso schon gesetzt sind und warte (solid)" .
Ich verstehe, dass das ggf. bei fünf unabhängig laufenden Queues/Fades global erstmal mist ist, aber dann muss man pause halt optional um eine channel map erweitern.
Es wäre halt schon schön, wenn wir das Modul API auf der fhem Seite stabil halten könnten und neue Funktionen einführen, ohne alte zu brechen.
pj
ps: wenn ich gerade mal über die gestern diskutierte Version mit allokierten Kanälen und einem "cookie" nachdenke - da könnte man die Komplexität, welche Channel denn nun pausieren müssen sogar im Controller verstecken.
Hm, also ich hab nicht gesagt das es 'pause' nicht mehr gibt. Das gibt es so (in der Form) nicht mehr. ;)
Ich würde die Diskussion gerne auf einen etwas späteren Zeitpunkt verschieben, ehrlich gesagt. Ich bin da erstens selbst noch nicht an allen Stellen gedanklich mit durch und einige Änderungen machen dann auch erst in Zusammenhang mit anderen Änderungen Sinn (bzw. sehen für sich alleine betrachtet seltsam aus im Kontext des alten FW-Standes).
Ich hab schon versucht, so gut es geht, die alte API beizubehalten. Aber es ist tatsächlich so, dass ich an einigen Stellen mit der alten Logik breche (möglicherweise ist es sogar nur die pause-Sache). Sorry dafür schonmal, aber hielt ich unterm Strich für besser...
Zitat von: vbs am 12 April 2017, 09:46:06
EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!
vielleicht sollten wir mal einen Wettbewerb im "wer baut den Controller am schnellsten auf" ausschreiben. Ich denke, ich komme auf etwa 20 Minuten pro Controller, wenn ich dabei nicht sabbeln muss!
pj
Neue, eigene Threads für Firmware, Hardware und (länger schon) das fhem Modul
Nachdem die diversen Threads langsam unübersichtlich werden habe ich mal neue, separate Threads für die einzelnen Themen angelegt.
Firmware:
https://forum.fhem.de/index.php/topic,70456.0.html
Hardware:
https://forum.fhem.de/index.php/topic,70455.0.html
fhem Modul:
https://forum.fhem.de/index.php/topic,55065.0.html
Sammelthread nächste Bestellung:
https://forum.fhem.de/index.php/topic,69740.0.html
ein paar der alten Threads (vor allem der erste Sammelbestellungsthread) sind mittlerweile etwas unübersichtlich geworden, da ist es vermutlich besser, neu anzufangen!
Grüße
pj
Ähm, wärt ihr evtl. mal für einen Plausch am Abend zu haben?
z.B. in Discord oder sowas.
Mit pj hatte ich das schonmal gemacht, bin nur nicht sicher ob er das Trauma bereits überwunden hat oder nicht. ;) :D
Ich finde einfach, wenn nun vier Leute an dem Projekt arbeiten (wollen) ist so'n kurzes "Meeting" hilfreich.
Grüße,
Shuzz
Zitat von: Shuzz am 12 April 2017, 19:16:55
Ähm, wärt ihr evtl. mal für einen Plausch am Abend zu haben?
z.B. in Discord oder sowas.
Mit pj hatte ich das schonmal gemacht, bin nur nicht sicher ob er das Trauma bereits überwunden hat oder nicht. ;) :D
Ich finde einfach, wenn nun vier Leute an dem Projekt arbeiten (wollen) ist so'n kurzes "Meeting" hilfreich.
Grüße,
Shuzz
Gern, wobei ich ja nur Wünsche äußern würde und irgendwelche komischen Vorschläge haben...
Gesendet von meinem HTC 10 mit Tapatalk
Ich muss gestehen, dass ich gerne erstmal meinen aktuellen Stand fertig machen würde. Also testen, stabilisieren, dokumentieren etc. Weiß nicht, ob ich da jetzt an der Stelle direkt die nächste Baustelle für mich aufmachen will.
Dann muss ich mal gucken, wie es damit weitergeht. Also ob ich das dann erstmal für mich nutze/pflege oder ob ich euch das so verkauft bekomme, dass ihr alles oder Teile davon in die offizielle Firmware übernehmen wollt. Dann mal sehen, auf welchem Stand man dann ist.
Ganz davon zu schweigen, dass ich (hoffentlich) in den nächsten Tagen auch mal wieder etwas löten werde (und Eier suche) :)
@vbs lass uns doch einfach mal quatschen und sehen, ob wir ein paar gute Ideen in den Topf werfen können
Kurz da auf dem Telefon getippt
Ok ok, würde euch Freitag nachmittag passen? Keine Ahnung so 15/16h?
Hmmm, kann ich derzeit noch nicht sagen...
Sofern meine besser Hälfte mich da nicht auf ner Wanderung durch den Taunus schleift gern. :D
@vbs: Naja, uns musst Du erstmal nicht viel verkaufen sofern es die Firmware betrifft. Die hat patrick jahns noch in der Hand, wobei ich mich frage ob er die nicht irgendwann mal abgeben mag da er selbst ja keine Zeit hat sich zu kümmern. Aber wie pj sagt: Soll eher so ne Art Brainstorming werden, ggf. Abstimmung was man machen kann/will/soll/mag/... ;)
lasst uns die Firmware Diskussion mal hier (https://forum.fhem.de/index.php/topic,70456.0.html) führen.
Ein paar Ideen zum fhem Modul:
- Autoconfig
ich denke schon seit einiger Zeit darüber nach, dass es eigentlich möglich sein müsste, Controller, die neu in's Netz kommen automatisch zu konfigurieren.
- Controller wird eingeschaltet, öffnet den Accesspoint "ESP_0"
- RaspberryPi Server hat ein "freies" WLAN interface, dass auf die Netzwerk ID "ESP_0" konfiguriert ist
- Sobald dieses Interface eine ip-Adresse hat, triggert ein Script ein fhem notify, das das Modul veranlasst, den Controller unter 192.168.4.1 zu konfigurieren
- Das fhem Modul braucht natürlich die Zugangsdaten zum "echten" Netzwerk (ein bisschen kritisch, denn der Schlüssel muss ja im Klartext verfügbar sein
- Wenn der Controller konfiguriert ist, meldet er sich kurz mit der neuen IP Adresse zurück, das Modul kann dann einen Config Eintrag erzeugen
Vorteil: man bräuchte nicht länger einen PC mit WLAN den man in die beiden unterschiedlichen Netze umschalten muss
- OTA Update
Ich habe langsam so viele Controller, dass der Gedanke, an alle zu gehen, und die Software upzudaten nervig wird. Eleganter wäre es, wenn das Modul zentral (vielleicht sogar über den fhem update Befehl) das OTA Update aller ihm bekannten Controller steuern könnte. Ich hab noch keine genau Idee, wie das gehen könnte, außer, dass das API die Update Funktion hergibt. - Konfiguration der neuen Firmware Optionen
Wenn wir uns darauf einigen sollten, etwas wie Master/Slave Syc in der Firmware einzubauen, dann muss das natürlich zentral von fhem, also vom Modul aus, konfiguriert werden können. Ich stelle mir das inetwa so vor:
- Attribute:
- Master (IP Addr oder MQTT Endpoint)
- Slave Mode (hsv, rgb, raw)
- Slave Transformation
Das könnte ein String sein, z.B. "h+10;v/2" (also: rotiere hue um 10° positiv und verwende die halbe Helligkeit)
Was darin gültig ist hängt natürlich vom Slave Mode ab. Wenn ich mich auf RAW subscribe, dann kann ich keine hsv Transformation machen.
Die Transformation selbst müsste natürlich auf dem Slave Controller ablaufen, was ggf. ziemliche Komplexität ergäbe.
- API
- set <xyz> enable/disable Slave
Ein- oder Ausschalten der Slave Funktionalität, Wert wird in einem Internal gespeichert. Auf diesem Wege lässt sich für ein Device eine Slave Konfiguration definieren und diese ohne Änderung aktivieren und deaktivieren. Der aktuelle zustand würde in einem INTERNAL gespeichert und als READING dargestellt
[li]
Multi Device SupportWenn wir die Funktion der Kanalallokation in die Firmware einbauen, dann kann das Modul für mehrere DEFINES für die selbe IP Adresse aufgerufen werden und jedesmal testen, ob für die aktuelle Definition genügend und die richtigen Kanäle frei sind.
[/list]
define RGBWW_LED LedController 192.168.112.20 RGBWW
# definiert ein Device, das die Kanäle R,G,B und WW verwendet, setzt damit automatisch den Colormode RGBWW für diese vier Kanäle
define CW_LED LedController 192.168.112.20 WHITE
# definiert ein Device, das versucht einen einzelnen Kanal als Weiß Kanal (oder was auch immer dran hängt) zu belegen.
define another_LED LedController 192.168.112.20 WHITE
# müsste in diesem Fall fehlschlagen, da keine Kanäle mehr frei.
Elegant dabei: wenn die Firmware das flexibel implementiert, dann wäre das eine gute Basis für den möglichen modularen ESP32 Controller, den @mrpj und ich mal ideenhalber diskutiert hatten, der hätte nämlich möglicherweise bis zu 15 Kanäle!
Komplex dabei: Eigentlich wird die feste Zuordnung der Kanäle an Farben damit zum Hindernis, denn wenn ich zuerst einen Weiß Kanal (also Kanal 0) alloziere, dann wäre es danach nicht mehr möglich, ein RGBWW zu allozieren. Es sei denn, wir allozieren einzelne Kanäle von oben nach unten.[/li]
Zitat von: pjakobs am 13 April 2017, 10:01:50
Ein paar Ideen zum fhem Modul:
[...]
Elegant dabei: wenn die Firmware das flexibel implementiert, dann wäre das eine gute Basis für den möglichen modularen ESP32 Controller, den @mrpj und ich mal ideenhalber diskutiert hatten, der hätte nämlich möglicherweise bis zu 15 Kanäle!
Komplex dabei: Eigentlich wird die feste Zuordnung der Kanäle an Farben damit zum Hindernis, denn wenn ich zuerst einen Weiß Kanal (also Kanal 0) alloziere, dann wäre es danach nicht mehr möglich, ein RGBWW zu allozieren. Es sei denn, wir allozieren einzelne Kanäle von oben nach unten.
D.h. ein RGBWW-Farbmodell kann nicht mit den Kanälen 2,3,4,5 "erzeugt" werden sondern nur mit 1,2,3,4? Vielleicht kann man da ansetzen und das abstrahieren?
EDIT: Das würde ja auch für einen Controller mit deutlich mehr Kanälen benötigt werden
Das ist aktuell korrekt, und ich denke, dass das vermutlich auch gut so ist, weil es eine sehr logische Regel zum Anschluss der Strips ist. Mal sehen. Wirklich bedeutsam wird das wohl erst, wenn viele Kanäle zur Verfügung stehen und man z.B. zwischen 3xRGBWWCW und 5xRGB wählen könnte. Für die aktuelle Hardware ist es Imho kein Problem.
Kurz da auf dem Telefon getippt
Hmm, "logische Regel" klingt nach "starrem Schema" und beißt sich an der Stelle IMHO mit der gewünschten Flexibilität. 8)
*meinjanur*
Flexibilität in der Software ja, aber verkabeln willst Du doch nur einmal, oder?
Kurz da auf dem Telefon getippt
Hallo.
Habe versucht das Fhem Modul zu laden bekomme aber dieser Fehlermeldung.
2017.04.13 12:27:48 1: PERL WARNING: Bareword found where operator expected at ./FHEM/32_LedController.pm line 23, near "<title>esp_rgbww_fhemmodule"
2017.04.13 12:27:48 1: PERL WARNING: (Missing operator before esp_rgbww_fhemmodule?)
2017.04.13 12:27:48 1: PERL WARNING: Bareword found where operator expected at ./FHEM/32_LedController.pm line 23, near "32_LedController"
2017.04.13 12:27:48 1: PERL WARNING: (Missing operator before LedController?)
2017.04.13 12:27:48 1: reload: Error:Modul 32_LedController deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 61 at ./FHEM/32_LedController.pm line 23.
2017.04.13 12:27:48 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 61 at ./FHEM/32_LedController.pm line 23.
wie hast Du das heruntergeladen?
Ich bin mir relativ sicher, dass die Datei, die diese Fehler wirft nicht die wirkliche Datei ist, sondern (wenn ich das richtig interpretiere) eine html Datei.
Hast Du den update Mechanismus verwendet?
pj
Hatte die Datei direkt aus dem git.
funktioniert jetzt aber. Habe sie gelöscht und den update Mechanismus genommen.
Zitat von: gNomeX am 13 April 2017, 12:53:39
Hatte die Datei direkt aus dem git.
funktioniert jetzt aber. Habe sie gelöscht und den update Mechanismus genommen.
github packt eine Datei in html code ein, es sei denn, Du klickst auf den "raw" button. Die Update Funktion ist wesentlich praktischer, zumal Du so aktuelle Updates bekommst. (ich habe Dir allerdings den Link auf den devel Branch gegeben, der könnte zuweile auch ... interessate ... Funktionen beinhalten ;-) )
pj
Zitat von: vbs am 12 April 2017, 09:16:48
Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.
ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s
dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s
rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s
rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s
(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)
Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.
So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut :o
Ist es nicht so, dass "solid" nix anderes ist als eine Rampe mir Steigung 0?
Also z.B.
dimup 20 (0)
dimup 0 10
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s
Zitat von: Per am 13 April 2017, 15:01:53
Ist es nicht so, dass "solid" nix anderes ist als eine Rampe mir Steigung 0?
Hm, mit einer Steigung von 0 könnte man doch aber den aktuellen Wert nie verlassen oder?
Zitat von: Per am 13 April 2017, 15:01:53
Also z.B.
dimup 20 (0)
dimup 0 10
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s
Ja, theoretisch könnte man "solid" händisch so nachbauen, denk ich. In der Praxis ist es aber so, dass ein dimup vom FHEM-Modul auf ein normales HSV-Kommando mit "fade" umgesetzt wird (wenn ramp > 0). Aber wenn eine Fade-Animation startet und merkt, dass der Zielwert identisch mit dem aktuellen Wert ist (also das Ziel schon erreicht ist), dann bricht sie sofort ab und ignoriert die Ramp-Time (https://github.com/patrickjahns/RGBWWLed/blob/master/RGBWWLedAnimation.cpp#L75). Das ist mMn nicht ganz sauber bzw. halte ich für inkonsistent, da dabei die Ramp-Time nicht eingehalten wird.
Du kannst aber das zweite dimup durch eine pause von 10 ersetzen, da eine pause immer als "solid" geschickt wird.
Ich fände es einfacher, dass ganze in einem Befehl zu machen, dem man das "solid"-Flag direkt mitgibt, aber das mag Geschmackssache sein.
Zitat von: thorwin am 13 April 2017, 11:11:26
D.h. ein RGBWW-Farbmodell kann nicht mit den Kanälen 2,3,4,5 "erzeugt" werden sondern nur mit 1,2,3,4? Vielleicht kann man da ansetzen und das abstrahieren?
EDIT: Das würde ja auch für einen Controller mit deutlich mehr Kanälen benötigt werden
Ich hatte mal überlegt, ob man die Kanalzuteilung bzw. deren Konfiguration nicht komplett aufheben könnte.
Für jedes Kommando würden dann sowohl der Farbmodus (RGB, RGBW, RGBWW) als auch die Kanäle für den Modus mit übertragen.
Vorteil: Keine Konfiguration auf den Controllern selbst mehr notwendig, abgesehen von Dingen wie Netzwerk.
Nachteil: Könnte schwierig werden mit Slave-Mode bzw. MQTT-based Synchronisierung.
mrpj war von der Idee gar nicht begeistert. Was haltet ihr davon?
Andere Frage bzgl. Sming-Update: Müssen wir das wirklich durchführen? Soweit ich das überblicke läuft die FW mit dem "alten" Sming ja soweit zufriedenstellend, d.h. die Lowlevel-Funktionalitäten sind stabil und zuverlässig. Die Änderungen die hier diskutiert werden beziehen sich ja eher auf ne Ebene darüber, d.h. quasi auf die API die von der FW bereitgestellt wird.
Daher die Frage: Ist ein Sming-Update hierfür notwendig? Bringt es irgendwas?
Zitat von: pjakobs am 13 April 2017, 12:43:14Hast Du den update Mechanismus verwendet?
Also im "normalen" Fhem-Update kommt es nicht mit.
Könnte man im Post 1 (der ja irgendwoher kopiert wurde) nicht die übliche Übersicht anbringen?
Tante Edit hat zumindest die Anleitung (https://forum.fhem.de/index.php/topic,48918.msg619924.html#msg619924) für das Update gefunden...
Also, wie sieht's heute aus mit nem Plausch?
15-16 Uhr wird bei mir knapp, 16-17 wäre mir als Startzeit angenehmer.
Als Tool der Wahl würde ich Discord vorschlagen, ihr findet mich dort als ShuzzDE#8538
Discord hab ich noch nie von gehört, später wäre auch mir lieber, weil ich nochmal raus muss. Ich kann eine Reise web basierte (OK, Chrome) Videotelefonie anbieten
Kurz da auf dem Telefon getippt
Discord ist was für die junge Gamer Jugend ;D
Naja, mit 39 Lenzen zähle ich da wohl nicht mehr in die Zielgruppe, aber praktisch ist das Tool trotzdem. :D
Wenn's heute nicht klappt macht auch nix, morgen is ja auch noch ein Tag (und übermorgen und überübermorgen und...). ;)
Also ich hab jetzt Discord (vbs) am Laufen (das Argument mit der Gamer Jugend hat mich gepackt). 16h würde bei mir passen.
Zitat von: vbs am 14 April 2017, 14:27:56
Also ich hab jetzt Discord (vbs) am Laufen (das Argument mit der Gamer Jugend hat mich gepackt). 16h würde bei mir passen.
Errm... Gibt's das für Linux? Und wieso überhaupt ein Client, sowas geht doch im Browser....
Versteh einer die Jugend.
Kurz da auf dem Telefon getippt
https://discordapp.com/api/download?platform=linux&format=deb
oder
https://discordapp.com/api/download?platform=linux&format=tar.gz
So, ich denke das ich hier nun richtig bin, danke an vbs für den Hinweis.
Ich bekomme das Modul nicht zum laufen und habe keine Idee mehr was ich noch machen könnte.
Zu Testzwecken habe ich zwei ,,blanke" Controller definiert, einen als ,White".
Bei beiden bekomme ich im Log folgende Meldungen:
2017.04.18 23:10:08 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.18 23:10:08 5: CW_LED (Set) called with on, busy flag is 0
name is CW_LED, args
2017.04.18 23:10:08 3: CW_LED (Set) called with on, busy flag is 0
2017.04.18 23:10:08 5: CW_LED extended args raw: a=, b=
2017.04.18 23:10:08 5: CW_LED t= 0
2017.04.18 23:10:08 5: CW_LED extended args: t = 0, q = false, d = 1
2017.04.18 23:10:08 5: CW_LED setting VAL to 100, SAT to 0 and HUE 0
2017.04.18 23:10:08 5: CW_LED args[0] = , args[1] =
2017.04.18 23:10:08 5: CW_LED: called SetHSVColor 0, 0, 100, 2700, 0, solid, false, 1)
2017.04.18 23:10:08 2: CW_LED: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.
2017.04.18 23:11:48 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.18 23:11:48 5: LED_Test (Set) called with rgb, busy flag is 0
name is LED_Test, args $VAR1 = 'c9c9c9';
2017.04.18 23:11:48 3: LED_Test (Set) called with rgb, busy flag is 0
2017.04.18 23:11:48 5: LED_Test extended args raw: a=, b=
2017.04.18 23:11:48 5: LED_Test t= 1800
2017.04.18 23:11:48 5: LED_Test extended args: t = 1800, q = false, d = 1
2017.04.18 23:11:48 5: LED_Test raw: c9c9c9, r: 201, g: 201, b: 201
2017.04.18 23:11:48 5: LED_Test: called SetHSVColor 0, 0, 79, 2000, 1800, fade, false, 1)
2017.04.18 23:11:48 2: LED_Test: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.
Ich denke das ich alle erdenklichen Seiten über diesen Controller nun durchgeackert habe, finde aber leider keine Lösung.
Gibt es irgendwo, ergänzend zu der Modul-Hilfe, ein HowTo in dem die richtige Vorgehensweise erläutert ist.
Welche Voraussetzungen gibt es softwareseitig um das Modul zum laufen zu bekommen?
JSON ist eigentlich installiert:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
libjson-perl ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 6 nicht aktualisiert.
Würde evtl. jemand eine funktionierende Konfiguration mit mir teilen in der ich mich auf die Suche nach Fehler begeben kann?
Vielen vielen Dank im Voraus für mögliche Unterstützung.
moin Kuse,
sorry, ich hatte Deinen Post gestern Abend schon gesehen, aber leider war mein fhem raspi an defekter SD-Karte gestorben und ich konnte nichts nachsehen...
versuche doch mal bitte (gilt für raspbian, andere Distros ggf. abweichend)
dpkg-query -l|grep -i json|grep perl
das Ergebnis ist die Liste der installierten perl json Pakete. Bei mir sieht das so aus:
ii libjson-any-perl 1.38-1 all wrapper class for the various JSON classes
ii libjson-perl 2.61-1 all module for manipulating JSON-formatted data
ii libjson-xs-perl 2.340-1+b2 armhf module for manipulating JSON-formatted data (C/XS-accelerated)
Das Modul importiert json-xs, ich vermute, dass es das ist, dass bei Dir fehlt.
Grüße
pj
Ich möchte noch einmal auf das Problem beim Flashen einsteigen:
Mit dem FTDI-Adapter wurde das dritte file nicht fertiggestellt.
Das habe ich hier
ZitatZitat von: MacReiner am 14 April 2017, 18:20:10
Den LED Controller habe ich an 12V 100W. Den USB - Seriell Umsetzer habe ich auf 3,3V gejumpert.
Die ersten beiden files klappen:
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Flash params set to 0x0040
Wrote 4096 bytes at 0x0 in 0.4 seconds (85.7 kbit/s)...
Leaving...
Beim dritten files klappt es nicht. Auch nicht mit einer langsameren Baudrate:
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x100000 spiff_rom.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Writing 786432 @ 0x100000... 229376 (29 %)
A fatal error occurred: Timed out waiting for packet header
Das genügt auf dem ersten Blick.
Hab so jetzt zwei Controller in mein WLan und in FHEM eingebaut und kann sie ansprechen.
schon dargestellt.
Jetzt habe ich mir den CP2104 gekauft,
dann unter OSX den Treiber dafür geladen
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-driversund installiert.
Jetzt hat es auf Anhieb funktioniert.
sh-3.2# esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -fm qio 0x100000 spiff_rom.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 32m
Running Cesanta flasher stub...
Wrote 786432 bytes at 0x100000 in 68.2 seconds (92.3 kbit/s)...
Leaving...
das ist echt ein bisschen merkwürdig. Ich hab jede Menge der FTDI Adapter und kein Problem. Vielleicht sind die unterschiedlichen flash-Tools mit unterschiedlichen Chips mehr oder weniger kompatibel.
Probleme hatte ich immer nur, wenn ich die 3,3V Versorgung aus dem Adapter ziehen wollte, da braucht der ESP einfach marginal zu viel Strom.
pj
Zitat von: pjakobs am 18 April 2017, 23:28:52
moin Kuse,
sorry, ich hatte Deinen Post gestern Abend schon gesehen, aber leider war mein fhem raspi an defekter SD-Karte gestorben und ich konnte nichts nachsehen...
versuche doch mal bitte (gilt für raspbian, andere Distros ggf. abweichend)
dpkg-query -l|grep -i json|grep perl
das Ergebnis ist die Liste der installierten perl json Pakete. Bei mir sieht das so aus:
ii libjson-any-perl 1.38-1 all wrapper class for the various JSON classes
ii libjson-perl 2.61-1 all module for manipulating JSON-formatted data
ii libjson-xs-perl 2.340-1+b2 armhf module for manipulating JSON-formatted data (C/XS-accelerated)
Das Modul importiert json-xs, ich vermute, dass es das ist, dass bei Dir fehlt.
Grüße
pj
Ich habe nun nochmal alles entfernt und neu definiert.
Die Meldung von JSON kommt immer noch.
2017.04.19 12:02:05 0: Server started with 19 defined entities (fhem.pl:14001/2017-04-15 perl:5.020002 os:linux user:fhem pid:4815)
2017.04.19 12:02:05 2: LED_Stripe_CW: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 12:02:05 3: LED_Stripe_CW DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 12:02:05 2: LED_Stripe_WW: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 12:02:05 3: LED_Stripe_WW DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 12:02:05 2: LED_Stripe_RGB: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 12:02:05 3: LED_Stripe_RGB DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 12:02:34 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.19 12:02:34 5: LED_Stripe_RGB (Set) called with rgb, busy flag is 0
name is LED_Stripe_RGB, args $VAR1 = 'ffffff';
2017.04.19 12:02:34 3: LED_Stripe_RGB (Set) called with rgb, busy flag is 0
2017.04.19 12:02:34 1: PERL WARNING: Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 945.
2017.04.19 12:02:34 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 945.
2017.04.19 12:02:34 5: LED_Stripe_RGB extended args raw: a=, b=
2017.04.19 12:02:34 5: LED_Stripe_RGB t= 1800
2017.04.19 12:02:34 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 958.
2017.04.19 12:02:34 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 959.
2017.04.19 12:02:34 5: LED_Stripe_RGB extended args: t = 1800, q = false, d = 1
2017.04.19 12:02:34 5: LED_Stripe_RGB raw: ffffff, r: 255, g: 255, b: 255
2017.04.19 12:02:34 5: LED_Stripe_RGB: called SetHSVColor 0, 0, 100, 2700, 1800, fade, false, 1)
2017.04.19 12:02:34 2: LED_Stripe_RGB: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.
Bei mir hatte das Paket 'libjson-any-perl' gefehlt, wurde nun aber installiert und FHEM neu gestartet und das Modul neu geladen.
dpkg-query -l|grep -i json|grep perl
ii libjson-any-perl 1.38-1 all wrapper class for the various JSON classes
ii libjson-perl 2.61-1 all module for manipulating JSON-formatted data
ii libjson-xs-perl 2.340-1+b2 armhf module for manipulating JSON-formatted data (C/XS-accelerated)
Danke & LG
hmm... ich kann nicht sagen, dass ich das verstehe...
Ich schau mal alle json packages durch:
dpkg-query -l|grep -i json
ii libjson-any-perl 1.38-1 all wrapper class for the various JSON classes
ii libjson-c2:armhf 0.11-4 armhf JSON manipulation library - shared library
ii libjson-glib-1.0-0:armhf 1.0.2-1 armhf GLib JSON manipulation library
ii libjson-glib-1.0-common 1.0.2-1 all GLib JSON manipulation library (common files)
ii libjson-perl 2.61-1 all module for manipulating JSON-formatted data
ii libjson-xs-perl 2.340-1+b2 armhf module for manipulating JSON-formatted data (C/XS-accelerated)
ii libyajl2:armhf 2.1.0-2 armhf Yet Another JSON Library
ii php5-json 1.3.6-1 armhf JSON module for php5
ii syslog-ng-mod-json 3.5.6-2 armhf Enhanced system logging daemon (JSON plugin)
also möglicherweise brauchst Du noch die libjson-c2 und libjson-glib Pakete, wobei ich vermuten würde, dass die von apt-get automatisch installiert werden.
Wie hast Du die Pakete nachinstalliert? Normalerweise tut's imho ein
apt-get install libjson-any-perl libjson-xs-perl
wobei mich auch wundert, dass Du den Fehler erst beim Aufruf des new bekommst und nicht beim include...
Worauf betreibst Du das? Ist das ein Raspberry? Mit Raspbian?
pj
Ja, ist ein Raspi...
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
Folgendes ist nun installiert, Rspi wurde neu gebootet:
ii libjson-any-perl 1.38-1 all wrapper class for the various JSON classes
ii libjson-c2:armhf 0.11-4 armhf JSON manipulation library - shared library
ii libjson-glib-1.0-0:armhf 1.0.2-1 armhf GLib JSON manipulation library
ii libjson-glib-1.0-0-dbg:armhf 1.0.2-1 armhf GLib JSON manipulation library (debug symbols)
ii libjson-glib-1.0-common 1.0.2-1 all GLib JSON manipulation library (common files)
ii libjson-perl 2.61-1 all module for manipulating JSON-formatted data
ii libjson-xs-perl 2.340-1+b2 armhf module for manipulating JSON-formatted data (C/XS-accelerated)
ii libyajl2:armhf 2.1.0-2 armhf Yet Another JSON Library
ii php5-json 1.3.6-1 armhf JSON module for php5
Hier wieder das Log nach einem Restart:
2017.04.19 13:00:02 0: Server started with 19 defined entities (fhem.pl:14001/2017-04-15 perl:5.020002 os:linux user:fhem pid:1058)
2017.04.19 13:00:02 2: LED_Stripe_RGB: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 13:00:02 3: LED_Stripe_RGB DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 13:00:02 2: LED_Stripe_WW: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 13:00:02 3: LED_Stripe_WW DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 13:00:02 2: LED_Stripe_CW: error decoding config response Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 428.
2017.04.19 13:00:02 3: LED_Stripe_CW DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.04.19 13:00:10 4:
global LogLevel: 3
module LogLevel: 5
compound LogLevel: 5
2017.04.19 13:00:10 5: LED_Stripe_RGB (Set) called with rgb, busy flag is 0
name is LED_Stripe_RGB, args $VAR1 = 'ff0000';
2017.04.19 13:00:10 3: LED_Stripe_RGB (Set) called with rgb, busy flag is 0
2017.04.19 13:00:10 1: PERL WARNING: Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 945.
2017.04.19 13:00:10 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 945.
2017.04.19 13:00:10 5: LED_Stripe_RGB extended args raw: a=, b=
2017.04.19 13:00:10 5: LED_Stripe_RGB t= 1800
2017.04.19 13:00:10 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 958.
2017.04.19 13:00:10 1: PERL WARNING: Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 959.
2017.04.19 13:00:10 5: LED_Stripe_RGB extended args: t = 1800, q = false, d = 1
2017.04.19 13:00:10 5: LED_Stripe_RGB raw: ff0000, r: 255, g: 0, b: 0
2017.04.19 13:00:10 5: LED_Stripe_RGB: called SetHSVColor 0, 100, 100, 2700, 1800, fade, false, 1)
2017.04.19 13:00:10 2: LED_Stripe_RGB: error encoding HSV color request Can't locate object method "new" via package "JSON" at ./FHEM/32_LedController.pm line 554.
Hilft es evtl. wenn ich die Konfiguration des Controllers poste?
Kannst du schon machen, schadet sicherlich nicht, aber ich kann mir echt nicht vorstellen, dass das was mit deiner Config zu tun hat.
Ich würde jetzt mal versuchen, das Problem etwas einzugrenzen. Zum Beispiel mal ein einfaches Beispiel-Perl-Script laufen lassen, dass JSON::XS benutzt.
ZB sowas hier:
http://stackoverflow.com/questions/14291605/jsonxs-usage-croak
Also:
use JSON::XS;
my $array = ['foo', 'bar'];
print encode_json($array);
Weitere Ideen:
- liegen die Module im Dateisystem wirklich da, wo Perl sie sucht?
- stimmen die Rechte?
- wird die richtige Perl-Binary verwendet oder liegt evtl. noch eine andere (alte) irgendwo im Pfad?
Das sieht alles gut aus.
Ich kann es gerade nicht testen, magst Du mal folgendes versuchen bitte?
In der Datei
/opt/fhem/FHEM/32_LedController.pm
such Dir mal folgende Zeilen:
31 use Time::HiRes;
32 use Time::HiRes qw(usleep nanosleep);
33 use Time::HiRes qw(time);
34 use JSON::XS;
35 use Data::Dumper;
(die Zeilennummern bekommst Du in vi, wenn Du :set number eingibst)
und füge vor "use JSON::XS;" eine Zeile "use JSON" ein. etwa so:
31 use Time::HiRes;
32 use Time::HiRes qw(usleep nanosleep);
33 use Time::HiRes qw(time);
34 use JSON;
35 use JSON::XS;
36 use Data::Dumper;
Danach sollest Du fhem neu starten.
Ich habe den Eindruck, dass das vielleicht ein Bug ist. Fhem ist ja ein monolithisches System und im gesamten Kontext muss ein Modul nur einmal eingebunden sein, damit es gefunden wird. Wenn jetzt in meinem - recht kompelxen - Setup json schon irgendwo anders definiert ist, dann braucht ich das nicht mehr und es ist mir nie aufgefallen.
@herrmanj kannst Du da ggf mal drauf sehen? Wie gesagt, ich kann wegen Datenbank Migration gerade nicht testen.
grüße
pj
Aha...sieht schon mal anders aus!
Folgende Ausgabe im Log:
2017.04.19 14:48:10 5: LED_Stripe_RGB: calculated RGB as ff0000
2017.04.19 14:48:10 4: LED_Stripe_RGB: begin Readings Update
hue: 0
sat: 100
val:100
ct : 2700
HSV: 0,100,100
RGB: ff0000
2017.04.19 14:48:10 4: LED_Stripe_RGB: got HSV color response
2017.04.19 14:48:10 2: LED_Stripe_RGB: error decoding HSV color response malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<H2 color='#444'>401...") at ./FHEM/32_LedController.pm line 670.
2017.04.19 14:48:10 4: LED_Stripe_RGB: begin Readings Update
hue: 0
sat: 100
val:100
ct : 2700
HSV: 0,100,100
RGB: ff0000
2017.04.19 14:51:11 3: LED_Stripe_CW (Set) called with on, busy flag is 0
2017.04.19 14:51:11 3: LED_Stripe_CW DEBUG: Internal hue - helper: 0 and direct: 20
2017.04.19 14:51:12 2: LED_Stripe_CW: error decoding HSV color response malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<H2 color='#444'>401...") at ./FHEM/32_LedController.pm line 670.
2017.04.19 14:51:16 3: LED_Stripe_WW (Set) called with dimup, busy flag is 0
2017.04.19 14:51:16 1: PERL WARNING: Use of uninitialized value $dim in addition (+) at ./FHEM/32_LedController.pm line 274.
2017.04.19 14:51:16 3: LED_Stripe_WW DEBUG: Internal hue - helper: 0 and direct: 0
2017.04.19 14:51:16 2: LED_Stripe_WW: error decoding HSV color response malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<H2 color='#444'>401...") at ./FHEM/32_LedController.pm line 670.
Folgendes wurde geändert...
Berechtigungen geprüft:
-rw-r--r-- 1 fhem dialout 50787 Apr 19 14:46 32_LedController.pm
Code-Zeile in '/opt/fhem/FHEM/32_LedController.pm' eingefügt:
34 use JSON;
FHEM neu gestartet:
Modul-Definition:
defmod LED_Stripe_RGB LedController 192.168.2.40 RGB
attr LED_Stripe_RGB alias LED_260
attr LED_Stripe_RGB colorTemp 2700
attr LED_Stripe_RGB defaultRamp 1800
attr LED_Stripe_RGB defaultSat 100
attr LED_Stripe_RGB defaultVal 20
attr LED_Stripe_RGB group Aquarium
attr LED_Stripe_RGB icon black_FS20.on
attr LED_Stripe_RGB room Wohnzimmer
attr LED_Stripe_RGB verbose 5
attr LED_Stripe_RGB webCmd rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb
attr LED_Stripe_RGB widgetOverride rgb:colorpicker,rgb
setstate LED_Stripe_RGB on
setstate LED_Stripe_RGB 2017-04-19 14:48:10 ct 2700
setstate LED_Stripe_RGB 2017-04-19 14:48:10 hsv 0,100,100
setstate LED_Stripe_RGB 2017-04-19 14:48:10 hue 0
setstate LED_Stripe_RGB 2017-04-19 14:48:10 rgb ff0000
setstate LED_Stripe_RGB 2017-04-19 14:48:10 sat 100
setstate LED_Stripe_RGB 2017-04-19 14:48:10 state on
setstate LED_Stripe_RGB 2017-04-19 14:48:10 val 100
defmod LED_Stripe_CW LedController 192.168.2.40 WHITE
attr LED_Stripe_CW alias LED_ColdWarm
attr LED_Stripe_CW colorTemp 2700
attr LED_Stripe_CW defaultRamp 1800
attr LED_Stripe_CW defaultSat 100
attr LED_Stripe_CW defaultVal 20
attr LED_Stripe_CW group Aquarium
attr LED_Stripe_CW room Wohnzimmer
attr LED_Stripe_CW stateFormat state
attr LED_Stripe_CW webCmd dimup:dimdown:on:off
setstate LED_Stripe_CW on
setstate LED_Stripe_CW 2017-04-19 14:51:11 ct 2700
setstate LED_Stripe_CW 2017-04-19 14:51:11 hsv 0,100,20
setstate LED_Stripe_CW 2017-04-19 14:51:11 hue 0
setstate LED_Stripe_CW 2017-04-19 14:51:11 rgb 330000
setstate LED_Stripe_CW 2017-04-19 14:51:11 sat 100
setstate LED_Stripe_CW 2017-04-19 14:51:11 state on
setstate LED_Stripe_CW 2017-04-19 14:51:11 val 20
(before "<H2 color='#444'>401...")
da kommt irgendwo ein Stück html rein?
Welchen Befehl rufst Du auf?
ich schau gerade mal auf Deine Definitionen... ok, Du bist uns voraus!
Wir wollen, für die Zukunft, die Möglichkeit schaffen, einen Controller auf mehrere fhem-Devices aufzuteilen, aktuell kann das weder die Firmware noch das fhem Modul. Ich fürchte, wir haben Dich mit unserer Entwickler-Diskussion da verwirrt.
die korrekte Definition aktuell wäre:
defmod LED_Stripe_RGB LedController 192.168.2.40
attr LED_Stripe_RGB alias LED_260
attr LED_Stripe_RGB colorTemp 2700
attr LED_Stripe_RGB defaultRamp 1800
attr LED_Stripe_RGB defaultSat 100
attr LED_Stripe_RGB defaultVal 20
attr LED_Stripe_RGB group Aquarium
attr LED_Stripe_RGB icon black_FS20.on
attr LED_Stripe_RGB room Wohnzimmer
attr LED_Stripe_RGB verbose 5
attr LED_Stripe_RGB webCmd rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb
attr LED_Stripe_RGB widgetOverride rgb:colorpicker,rgb
Wenn Du einen RGBCW Strip daran hängen hast, dann musst Du auf der Oberfläche des Controllers selbst noch das Farbmodell auf "RGBCW" umstellen, danach kannst Du von Fhem aus mit
set LED_Stripe_RGB hsv 0,100,100
zum Beispiel voll gesättigtes rot in maximaler Helligkeit produzieren.
set LED_Stripe_RGB hsv 0,50,100
hingegen würde die Rot und Weiß LED jeweils zu 50% betreiben.
Aber ich denke, die JSON Sache ist auf alle Fälle ein Bug, den ich flink mal beheben werden. Danke für's Troubleshooten :d
pj
[edit]
Was versuchst Du mit den
setstate Kommandos zu erreichen? Ich hab das noch nie benutzt und wenn ich die Doku nicht falsch verstehe, setzen die nur den STATE ...?
Zitat von: pjakobs am 19 April 2017, 15:21:32
(before "<H2 color='#444'>401...")
da kommt irgendwo ein Stück html rein?
Welchen Befehl rufst Du auf?
Ich habe ehrlich gesagt keinen Plan wo das herkommt, bin wie gesagt noch FHEM-Beginner.
Zum posten der Logdatei habe ich nur eine der vordefinierten Schaltflächen gedrückt.
siehe ,WebCMD / rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb'
Zitat von: pjakobs am 19 April 2017, 15:21:32
ich schau gerade mal auf Deine Definitionen... ok, Du bist uns voraus!
Wir wollen, für die Zukunft, die Möglichkeit schaffen, einen Controller auf mehrere fhem-Devices aufzuteilen, aktuell kann das weder die Firmware noch das fhem Modul. Ich fürchte, wir haben Dich mit unserer Entwickler-Diskussion da verwirrt.
Irgendsowas hab ich mir schon fast gedacht. Da hab ich mir aus den 236 Seiten zu dem Controller wohl ,,etwas" zu viel rauskopiert. ::)
Zitat von: pjakobs am 19 April 2017, 15:21:32
die korrekte Definition aktuell wäre:
defmod LED_Stripe_RGB LedController 192.168.2.40
attr LED_Stripe_RGB alias LED_260
attr LED_Stripe_RGB colorTemp 2700
attr LED_Stripe_RGB defaultRamp 1800
attr LED_Stripe_RGB defaultSat 100
attr LED_Stripe_RGB defaultVal 20
attr LED_Stripe_RGB group Aquarium
attr LED_Stripe_RGB icon black_FS20.on
attr LED_Stripe_RGB room Wohnzimmer
attr LED_Stripe_RGB verbose 5
attr LED_Stripe_RGB webCmd rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb
attr LED_Stripe_RGB widgetOverride rgb:colorpicker,rgb
Danke, schau ich mir an.
Zitat von: pjakobs am 19 April 2017, 15:21:32
Wenn Du einen RGBCW Strip daran hängen hast, dann musst Du auf der Oberfläche des Controllers selbst noch das Farbmodell auf "RGBCW" umstellen, danach kannst Du von Fhem aus mit
set LED_Stripe_RGB hsv 0,100,100
zum Beispiel voll gesättigtes rot in maximaler Helligkeit produzieren.
set LED_Stripe_RGB hsv 0,50,100
hingegen würde die Rot und Weiß LED jeweils zu 50% betreiben.
Ich möchte an dem Controller einen RGB-Stripe, einen Warm-Weiß-Stripe und einen Kalt-Weiß-Stripe betreiben.
Die Stripes möchte ich jeweils getrennt ansteuern können. Ziel ist es eine Sonnenaufgang bzw. -untergang sowie Mondlicht zu simulieren.
Geht das dann so überhaupt?
Zitat von: pjakobs am 19 April 2017, 15:21:32
Aber ich denke, die JSON Sache ist auf alle Fälle ein Bug, den ich flink mal beheben werden. Danke für's Troubleshooten :d
Freut mich das ich durch mein Unwissen etwas beitragen konnte. ;D
Zitat von: pjakobs am 19 April 2017, 15:21:32
[edit]
Was versuchst Du mit den setstate Kommandos zu erreichen? Ich hab das noch nie benutzt und wenn ich die Doku nicht falsch verstehe, setzen die nur den STATE ...?
Eigentlich möchte ich über DOIF steuern.
z.B.
DOELSEIF ([10:00]) (set LED_RGB RGB FFFFFF 1800)
DOELSEIF ([10:01]) (set LED_Stripe_CW pct 10 q; set LED_Stripe_WW pct 10)
die ,setstate' habe ich nicht aktiv gesetzt sondern aus der Definition des Buttons ,Raw definition' kopiert.
Nur zur Sicherheit...
Der Contoller in FHEM muss so definiert werden:
- 'define LED_Stripe_RGB LedController 192.168.X.XXX RGB' oder
- 'define LED_Stripe_RGB LedController 192.168.X.XXX RGBCW' oder
- 'define LED_Stripe_RGB LedController 192.168.X.XXX RGBCWWW'
Wenn ich direkt am Controller in den ,Color Setting' das Output-Model auf ,RGBWWCW' umstelle kommt folgende Meldung nachdem ich den Haken zum Bestätigen gedrückt habe.
,something went wrong while saving the configuration'
Ihr seht schon...schwierig mit mir! :-\
Also vorneweg:
nein, aktuell kannst Du unterschiedliche Leuchtmittel an einem Controller nicht aufteilen.
Aber: Du kannst alle fünf Farben (R,G,B,WW,CW) als eine einzige Leuchte betreiben und ziemlich frei nutzen.
Ein Beispiel:
define LED_Wo LedController 192.168.29.55
attr LED_Wo colorTemp 2700
attr LED_Wo defaultColor 0,10,80
attr LED_Wo defaultRamp 6000
attr LED_Wo room Licht,Wohnzimmer
attr LED_Wo verbose 2
attr LED_Wo webCmd rgb:rgb FFFFFF:rgb AFAFAF:rgb 7F7F7F:rgb 3F3F3F:rgb 000000:rgb 401020
attr LED_Wo widgetOverride rgb:colorpicker,HSV
das ist mein Wohnzimmerlicht.
Wie Du siehst hat die "define" Zeile erstmal, außer der IP-Adresse, keine Parameter. (Was Du geschrieben hattest ist zwar angedacht, aber noch nicht umgesetzt, wir sind da noch am diskutieren, wie wir das sinnvollerweise machen).
Ich habe an meinen Controllern RGBWW Streifen dran, also nur Warmweiß. Für Wohnräume genügt das völlig.
ein
set LED_Wo 30,50,80
schaltet das Licht ein und zwar mit einer Gesamthelligkeit von 80%, einem leicht gelben Farbton (rot+grün) und einer Farbintensität von 50%, die restlichen 50% Helligkeit kommen von den warmweiß LEDs.
Wenn Du nun WW und CW dran hängen hast, dann wird die colorTemp relevant, denn diese bestimmt das Mischungsverhältnis zwischen den beiden.
Sonnenauf- und Untergänge mache ich hiermit: der Code sollte dann in Deiner 99_myUtils.pm liegen.
sub
sun(@) {
# Dauer in Minuten (minimum 4 min)
my $dauer = $_[0];
my @farben;
# Initialisiern des Lichterarrays
my @lichter = ($_[2],$_[3],$_[4],$_[5]);
if($_[1] eq "Sunrise"){
@farben = (
["240,100,2",1],
["240,100,1",1],
["240,100,2",20],
["240,100,5",20],
["240,100,8",20],
["210,100,6",30],
["190,100,8",1],
["90,100,14",1],
["70,100,16",1],
["10,100,34",2],
["30,100,40",30],
["40,100,60",30],
["45,100,80",30],
["50,100,100",30],
#["50,19,75",3],
["50,0,100",30]
);
} elsif ($_[1] eq "Sunset"){
my $val = ReadingsVal($_[2],"val",50);
@farben = (
# ["60,70,".$val,60],
# ["0,50,".$val*0.8,360],
# ["200,50,".$val*0.5,600],
# ["240,100,".$val*0.2,600],
# ["240,100,0",900]
# sunset in blue
# ["220,12,".$val*0.95,60],
# ["228,12,".$val*0.94,60],
# ["230,44,".$val*0.88,60],
# ["220,60,".$val*0.79,60],
# ["223,65,".$val*0.62,60],
# ["218,66,".$val*0.19,120],
# ["219,44,".$val*0.06,60],
# ["219,40,".$val*0.05,60],
# ["219,50,0",60]
["360,45,".$val*0.93,5],
["360,48,".$val*0.96,5],
["360,59,".$val*0.79,5],
["355,63,".$val*0.74,5],
["350,57,".$val*0.57,5],
["310,22,".$val*0.16,10],
["237,26,".$val*0.07,5],
["219,31,0",10]
);
}
my $gesamtdauersek = $dauer*60;
my $dauerfarben = 0;
foreach my $farbe ( @farben ) {
$dauerfarben+=$farbe->[1];
}
my $anteiligedauer = $gesamtdauersek/$dauerfarben;
Log3 (undef, 3, "Sun: start $_[1], angegebene Gesamtdauer in Sekunden $gesamtdauersek, Dauer Farben $dauerfarben, Anteil $anteiligedauer");
# Durchlauf der Farbsimulation
my $i = 0;
foreach my $farbe ( @farben ) {
foreach my $licht ( @lichter ) {
if(defined $licht) {
if($i == 0) {
Log3(undef,3,"Sun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
} else {
Log3(undef,3,"Sun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
}
}
}
$i++;
}
}
Teile des Codes stammen von Sandra Ohmayer (http://www.animeschatten.net)
In meinem Fall triggere ich Sonnenaufgang und Sonnenuntergang per Tasker von meinem Mobiltelefon abhängig von meinem Schlafphasenwecker.
Du kannst noch über das Kommando "raw" alle Kanäle direkt einzeln ansteuern, dann musst Du Dich aber auch vollständig um die Farbmischung kümmern.
Wie gesagt, mehr Funktionalität ist angedacht aber noch nicht umgesetzt. Ich vermute aber, dass das, was Du willst, schon jetzt funktioniert.
Grüße
pj
Vielen herzlichen Dank für die Erläuterungen, klasse Support.
Ohne das wäre ich echt am Verzweifeln gewesen.
Ich bau das jetzt mal nach und hoffe das alles so funktioniert.
Edith:
Die Modifikation im Modeul zwecks JSON lass ich vorerst so bis eine neue Version kommt, oder?
Muss ich mir nun noch Gedanken zwecks dem HTML-Fragment machen?
Grüße
Kuse
Zitat von: Kuse am 19 April 2017, 22:28:55
Vielen herzlichen Dank für die Erläuterungen, klasse Support.
Ohne das wäre ich echt am Verzweifeln gewesen.
Ich bau das jetzt mal nach und hoffe das alles so funktioniert.
Edith:
Die Modifikation im Modeul zwecks JSON lass ich vorerst so bis eine neue Version kommt, oder?
yo
Zitat von: Kuse am 19 April 2017, 22:28:55
Muss ich mir nun noch Gedanken zwecks dem HTML-Fragment machen?
nö
Zitat von: Kuse am 19 April 2017, 22:28:55
Grüße
Kuse
Hey Peter
nachdem das flashen mit dem CP2104 gut gelaufen ist, ist einer der Controller mausetot.
Nach dem Anlegen von 12V blinkt die eine blaue LED wunschgemäß auf. Insoweit ist die Welt in Ordnung.
Die 3,3V werden auch erzeugt.
Per WLan ist er nicht erreichbar. Weder macht er sein ursprüngliches WLan auf, noch geht die 192.168..4.1.
Auch die von mir vergebene 192.168.1.102 ist nicht erreichbar.
Neu flashen geht auch nich:
sh-3.2# esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Invalid head of packet ('\x16')
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Invalid head of packet ('\x00')
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
Mir gehen die Ideen aus.
Gibt es vielleicht einen Reset durch Drücken der beiden Tasten auf dem Controller?
Hab schon probiert, aber der Kollege schaltet auf stur...
Zitat von: MacReiner am 19 April 2017, 23:26:52
Hey Peter
nachdem das flashen mit dem CP2104 gut gelaufen ist, ist einer der Controller mausetot.
Nach dem Anlegen von 12V blinkt die eine blaue LED wunschgemäß auf. Insoweit ist die Welt in Ordnung.
Die 3,3V werden auch erzeugt.
Per WLan ist er nicht erreichbar. Weder macht er sein ursprüngliches WLan auf, noch geht die 192.168..4.1.
Auch die von mir vergebene 192.168.1.102 ist nicht erreichbar.
Neu flashen geht auch nich:
sh-3.2# esptool.py --p /dev/tty.SLAB_USBtoUART -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Invalid head of packet ('\x16')
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Invalid head of packet ('\x00')
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
sh-3.2# esptool.py --p /dev/tty.usbserial-A50285BI -b 115200 write_flash -fm qio 0x00000 rboot.bin
esptool.py v1.3
Connecting...................
A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
Mir gehen die Ideen aus.
Gibt es vielleicht einen Reset durch Drücken der beiden Tasten auf dem Controller?
Hab schon probiert, aber der Kollege schaltet auf stur...
clr+rst löscht die Konfiguration des Controllers aber nicht den Flash Speicher, aber einen Versuch wäre es wert, vielleicht macht er danach den AP auf.
Dass er sich nicht mehr flashen lässt hab ich noch nicht gesehen. Bist Du sicher, dass alle Verbindungen richtig sind (TR/TX getauscht), dass die Spannung des USB converters auf 3,3V steht? (5V könnte den ESP8266 zerstören).
Du kannst mal ein Terminal aufmachen und schauen, ob Du Boot messages bekommst.
pj
Kurz da auf dem Telefon getippt
Bist du 24h online?? 8)
Die Anschlüsse habe ich richtig gesteckt, mehrfach neu gesteckt...
5V hat er nicht gesehen.
Reset ist erfolglos.
Einen anderen Controller kann ich flashen, ich stecke nur die vier Leitungen um...
Er mag mich nicht mehr...
Moin,
kleine Info noch zu der Aussage "5V beschädigt den ESP":
https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/ (https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/)
Die Eingänge des ESP sind wohl doch tolerant gegenüber Spannungen bis fast 6V.
(Ich hatte (bisher) auch noch keine Probleme mit USB->Seriell-Wandlern, welche zwar ne Umschaltung zwischen 3,3V und 5V haben, allerdings dann auf den RX/TX Pins munter mit 5V-Pegel weiter arbeiteten)
Zitat von: MacReiner am 19 April 2017, 23:49:48
Bist du 24h online?? 8)
Die Anschlüsse habe ich richtig gesteckt, mehrfach neu gesteckt...
5V hat er nicht gesehen.
Reset ist erfolglos.
Einen anderen Controller kann ich flashen, ich stecke nur die vier Leitungen um...
Er mag mich nicht mehr...
Seltsam. Glaubst Du, Du kannst den ESP8266 wieder auslöten? Dann schick ich Dir Ersatz. Oder Du schickst mir den Controller und ich schau mal drauf.
Aber einmal konntest Du den flashen, oder?
Kurz da auf dem Telefon getippt
Das wäre äußerst nett von dir.
Das Auslöten versuche ich morgen vormittag.
Ansonsten schicke ich ihn dir gerne zu.
Geflasht habe ich erstmalig mit dem Abbruch bei 30% beim dritten file, wo er ja dennoch funktionierte.
Dann geflasht mit dem CP2104 (ohne Fehler), danach aber nicht mehr ansprechbar und auch nicht mehr flashbar.
Zitat von: MacReiner am 20 April 2017, 00:03:51
Das wäre äußerst nett von dir.
Das Auslöten versuche ich morgen vormittag.
Ansonsten schicke ich ihn dir gerne zu.
Geflasht habe ich erstmalig mit dem Abbruch bei 30% beim dritten file, wo er ja dennoch funktionierte.
Dann geflasht mit dem CP2104 (ohne Fehler), danach aber nicht mehr ansprechbar und auch nicht mehr flashbar.
Schick ihn mir gleich zu, vielleicht kann ich ja herausfinden, wo's klemmt, auslöten ist vermutlich destruktiv.
pj
Kurz da auf dem Telefon getippt
Hallo Zusammen,
in dem fhemmodul espeasy von dev0, gibt folgende Darstellung.
Könnte man so eine auch für dieser Modul umsetzen?
Gruß
lewej
Zitat von: lewej am 20 April 2017, 21:43:39
Hallo Zusammen,
in dem fhemmodul espeasy von dev0, gibt folgende Darstellung.
Könnte man so eine auch für dieser Modul umsetzen?
Gruß
lewej
das macht ja bei einem HSV Modul wenig Sinn, das ist ja nur Warmweiß/Kaltweiß (aber natürlich könnte man einen entsprechenden Regler für den ct Wert bauen).
Bei mir sieht es halt so aus. Der Code dazu:
attr LED_Be webCmd rgb:rgb FFFFFF:rgb AFAFAF:rgb 7F7F7F:rgb 3F3F3F:rgb 0
- Erweiterte Optionen...
Bei neuen Antworten benachrichtigen Thema schließen Zum Thema zurückkehren00000:rgb 401020
attr LED_Be widgetOverride rgb:colorpicker,HSV
Ich _glaube_ das geht nicht, weil der ct Wert derzeit als attr auf dem Device gesetzt wird und nicht als Reading.
Wenn Du auf's Device gehst und dann unten bei attr die colorTemp auswählst kannst Du nen Regler anzeigen lassen, aber in der Raumansicht hab' ich das nicht hinbekommen.
Aber ich mag mich hier gern irren, falls jemand einen Weg kennt wüsste ich den ebenfalls gerne... ;)
Zitat von: ComputerZOO am 19 April 2017, 23:52:31
Moin,
kleine Info noch zu der Aussage "5V beschädigt den ESP":
https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/ (https://ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/)
Die Eingänge des ESP sind wohl doch tolerant gegenüber Spannungen bis fast 6V.
(Ich hatte (bisher) auch noch keine Probleme mit USB->Seriell-Wandlern, welche zwar ne Umschaltung zwischen 3,3V und 5V haben, allerdings dann auf den RX/TX Pins munter mit 5V-Pegel weiter arbeiteten)
Jo, klar, mit Reihenwiderstand geht das sicherlich, darf halt nur nicht zu groß werden. 10k halte ich für zu viel an der Stelle.
1k sollte dicke reichen, dann müssen die Clamping-Dioden auch nur ca. 1.6mA abführen.
Zitat von: Shuzz am 22 April 2017, 00:39:30
Ich _glaube_ das geht nicht, weil der ct Wert derzeit als attr auf dem Device gesetzt wird und nicht als Reading.
Um den colortemp slider (aus color.pm) nutzen zu können, muß das Modul den ct Befehl unterstützen. Die Verwendung ist simpel, ein "set <dev> ?" muß dann nur folgendes für den ct Befehl zeigen:
ct:colorpicker,CT,<min_ct>,<step>,<max_ct>
Der ct Befehl wird am sinnvollsten auch direkt vom Controller verarbeitet. Wenn bspw. ww und cw Stripes vorhanden sind, dann reicht es nur die beiden weißen Kanäle anzusteuern. Hue Lampen arbeiten mWn auch so. Ergebnis ist dann ein "ordentliches" Weiß.
Wenn nur ein oder kein Weußkanal vorhanden ist, dann kann man aus der Farbtemperatur (ct) auch die nötigen RGB/HSV Werte berechnen:
http://www.tannerhelland.com/4435/convert-temperature-rgb-algorithm-code/
Was davon schon in Firmware/Modul umgesetzt weiß ich nicht, da ich noch nicht dazu kam es mir näher anzusehen, ich kämpfe noch mit dem Sming Framework...
Zitat von: dev0 am 22 April 2017, 08:20:31
Um den colortemp slider (aus color.pm) nutzen zu können, muß das Modul den ct Befehl unterstützen. Die Verwendung ist simpel, ein "set <dev> ?" muß dann nur folgendes für den ct Befehl zeigen:
ct:colorpicker,CT,<min_ct>,<step>,<max_ct>
Der ct Befehl wird am sinnvollsten auch direkt vom Controller verarbeitet. Wenn bspw. ww und cw Stripes vorhanden sind, dann reicht es nur die beiden weißen Kanäle anzusteuern. Hue Lampen arbeiten mWn auch so. Ergebnis ist dann ein "ordentliches" Weiß.
Wenn nur ein oder kein Weußkanal vorhanden ist, dann kann man aus der Farbtemperatur (ct) auch die nötigen RGB/HSV Werte berechnen:
http://www.tannerhelland.com/4435/convert-temperature-rgb-algorithm-code/
Was davon schon in Firmware/Modul umgesetzt weiß ich nicht, da ich noch nicht dazu kam es mir näher anzusehen, ich kämpfe noch mit dem Sming Framework...
Ich schau mir das mal an, sollte kein Problem sein. Ich hab nur noch nie darüber nachgedacht, dass das ein dynamischr Parameter sein könnte.
Stay tuned
pj
Kurz da auf dem Telefon getippt
Update: ich habe mal eine Version gebaut, die das Kommando "set <devicename> ct [2000-10000]" beherrscht. Damit sollte ein colorTemp Slider möglich sein. Das Modul hab ich im branch "feature_set_ct" eingecheckt. Testet das bitte mal.
Grüße
pj
Zitat von: dev0 am 22 April 2017, 08:20:31
Um den colortemp slider (aus color.pm) nutzen zu können, muß das Modul den ct Befehl unterstützen. Die Verwendung ist simpel, ein "set <dev> ?" muß dann nur folgendes für den ct Befehl zeigen:
ct:colorpicker,CT,<min_ct>,<step>,<max_ct>
Der ct Befehl wird am sinnvollsten auch direkt vom Controller verarbeitet. Wenn bspw. ww und cw Stripes vorhanden sind, dann reicht es nur die beiden weißen Kanäle anzusteuern. Hue Lampen arbeiten mWn auch so. Ergebnis ist dann ein "ordentliches" Weiß.
Wenn nur ein oder kein Weußkanal vorhanden ist, dann kann man aus der Farbtemperatur (ct) auch die nötigen RGB/HSV Werte berechnen:
http://www.tannerhelland.com/4435/convert-temperature-rgb-algorithm-code/
Was davon schon in Firmware/Modul umgesetzt weiß ich nicht, da ich noch nicht dazu kam es mir näher anzusehen, ich kämpfe noch mit dem Sming Framework...
Klar, kann man so implementieren.
Derzeit ist es halt im Modul anders gelöst.
Zitat von: Shuzz am 22 April 2017, 10:36:03
Derzeit ist es halt im Modul anders gelöst.
Ich komme derzeit leider nicht zum Testen, daher sei die Frage erlaubt, wie es zZ. gelöst ist, wenn ich beispielsweise einen ww Stripe mit 2000k und einen cw mit 6000k habe. Welcher Befehl stellt dann die Farbtemperatur auf 4000k ein, so das beide Stripes mit 50% (bzw. 100% wenn man die maximale Helligkeite haben möchte) leuchten und keine der RGB Leds angeht.
Zitat von: Shuzz am 22 April 2017, 10:36:03
Klar, kann man so implementieren.
Derzeit ist es halt im Modul anders gelöst.
wie gesagt, das Modul unterstützt (seit halb neun) 'ct' als Set Kommando. (vielleicht magst Du mal drüber sehen)
Eigentlich fänd ich ein RGB Mix-in garnicht verkehrt, wenn keine zwei Weiß Kanäle vorhanden sind, aber ich fürchte, das ist ziemlicher Rechenaufwand. Das sollten wir uns bei Gelegenheit mal ansehen. (es stellen sich dabei ja Fragen wie: welche Farbtemperatur hat der vorhandene Weiß Strip, wie verändert sich die wahrgenommene Farbtemperatur beim Zumischen welcher RGB Anteile - wir verändern hier ja nicht die tatsächliche Farbtemperatur, sondern lediglich die wahrgenommene, was viel schwerer zu fassen ist. Man müsste mal suchen, ob es dazu überhaupt vernünftige Formeln gibt).
Was ich gerade feststelle: wie es aussieht geht nur ein WidgetOverride (was eigentlich auch logisch ist) und ich kann nicht den hsv und den ct Colorpicker zur selben Zeit aktiv haben.
pj
Zitat von: dev0 am 22 April 2017, 10:53:06
Ich komme derzeit leider nicht zum Testen, daher sei die Frage erlaubt, wie es zZ. gelöst ist, wenn ich beispielsweise einen ww Stripe mit 2000k und einen cw mit 6000k habe. Welcher Befehl stellt dann die Farbtemperatur auf 4000k ein, so das beide Stripes mit 50% (bzw. 100% wenn man die maximale Helligkeite haben möchte) leuchten und keine der RGB Leds angeht.
Bis heute früh um halb neun war das ein mehr oder weniger statisches Attribut, jetzt per "set <LED> ct 4000"
Die Farbtemperatur der einzelnen Stripes musst Du noch in der Oberfläche des Controllers selbst setzen, das muss ich mal in's Modul überführen.
pj
Zitat von: dev0 am 22 April 2017, 10:53:06
Ich komme derzeit leider nicht zum Testen, daher sei die Frage erlaubt, wie es zZ. gelöst ist, wenn ich beispielsweise einen ww Stripe mit 2000k und einen cw mit 6000k habe. Welcher Befehl stellt dann die Farbtemperatur auf 4000k ein, so das beide Stripes mit 50% (bzw. 100% wenn man die maximale Helligkeite haben möchte) leuchten und keine der RGB Leds angeht.
Die Firmware unterstützt derzeit keinen "White-Mode".
Aber selbst wenn sie es täte wäre Dein Szenario vermutlich nur über den RAW Mode machbar, denn:
Bei einem White-Mode mit einstellbarer Farbtemperatur würde ich erwarten, dass die Helligkeit bei "100%" immer gleich bleibt, egal welche ct ich einstelle.
Beide White-Strips auf 100% gäbe zwar die korrekte Farbtemperatur von 4000K, aber die doppelte Helligkeit.
Anders gesagt: Die Helligkeit von beiden Strips auf 100% lässt sich dann eben nur mit 4000K Farbtemperatur erreichen, aber bei 2000K bzw. 6000K ginge dann nur "50%".
Was heute funktioniert:
Modus RGBWWCW
attr <DEV> colorTemp 4000
set <DEV> hsv 0,0,100
Edit: Oder seit heute früh die Erweiterung von pjakobs, die hab ich mir noch nicht angesehen.
Allerdings geht die Firmware derzeit von minimal 2700K und max 6000K aus.
Grüße,
Shuzz
Zitat von: pjakobs am 22 April 2017, 10:59:22
Eigentlich fänd ich ein RGB Mix-in garnicht verkehrt, wenn keine zwei Weiß Kanäle vorhanden sind, aber ich fürchte, das ist ziemlicher Rechenaufwand.
Das hält sich mMn in Grenzen. ct2rgb() aus der ./FHEM/Color.pm kennst Du? Oder auch in C hier: https://github.com/ddtlabs/ESPEasy-Plugin-Lights/blob/master/_P123_LIGHTS.ino#L742
Basiert beides auf dem oben geposteten Link.
Zitat
Was ich gerade feststelle: wie es aussieht geht nur ein WidgetOverride (was eigentlich auch logisch ist) und ich kann nicht den hsv und den ct Colorpicker zur selben Zeit aktiv haben.
WidgetOverride brauchst Du nur, wenn der "set <dev> ?" Befehl nicht die nötige Syntax liefert. Wenn sowohl für rgb/hsv,ct,pct die entsprechende Ausgabe kommt, dann geht ct/pct/rgb (bzw. hsv/hsvp) gleichzeitig. Leider lassen sich die Widgets (zur Zeit) noch nicht untereinander in FHEMWEB darstellen.
Zitat von: dev0 am 22 April 2017, 11:18:28
Das hält sich mMn in Grenzen. ct2rgb() aus der ./FHEM/Color.pm kennst Du? Oder auch in C hier: https://github.com/ddtlabs/ESPEasy-Plugin-Lights/blob/master/_P123_LIGHTS.ino#L742
Basiert beides auf dem oben geposteten Link.
kannte ich nicht, schau ich mir an. Allerdings will ich, wenn möglich, nicht anfangen Dinge im Modul zu machen, die nach der Architektur in die Firmware gehören.
Zitat von: dev0 am 22 April 2017, 11:18:28
WidgetOverride brauchst Du nur, wenn der "set <dev> ?" Befehl nicht die nötige Syntax liefert. Wenn sowohl für rgb/hsv,ct,pct die entsprechende Ausgabe kommt, dann geht ct/pct/rgb (bzw. hsv/hsvp) gleichzeitig. Leider lassen sich die Widgets (zur Zeit) noch nicht untereinander in FHEMWEB darstellen.
Hmm... dann schau Dir doch mal den neuen Branch von heute früh an.
pj
Zitat von: Shuzz am 22 April 2017, 11:06:14
Aber selbst wenn sie es täte wäre Dein Szenario vermutlich nur über den RAW Mode machbar, denn:
Bei einem White-Mode mit einstellbarer Farbtemperatur würde ich erwarten, dass die Helligkeit bei "100%" immer gleich bleibt, egal welche ct ich einstelle.
Beide White-Strips auf 100% gäbe zwar die korrekte Farbtemperatur von 4000K, aber die doppelte Helligkeit.
Anders gesagt: Die Helligkeit von beiden Strips auf 100% lässt sich dann eben nur mit 4000K Farbtemperatur erreichen, aber bei 2000K bzw. 6000K ginge dann nur "50%".
Wenn man eine gleichbleibende Helligkeit über die möglichen Farbtemperaturen haben möchte, dann sind natürlich max 50% pro Strip möglich.
Damit verschenkt man aber zb. bei 3000k x Prozent der maximal möglichen Helligkeit. Wenn man eine Helligkeitsschwankung in kauf nimmt, dann könnte man das auch weiter "hochregeln" im mittleren ct Bereich. Ist auch nicht so schwiegig umzusetzen, da man mMn nur das Verhältnis zwischen den beiden Stripes beachten muß. So zumindest habe ich das im EPSEasy Lights Plugin für den reinen ww/cw Betrieb umgestezt.
Zitat von: pjakobs am 22 April 2017, 11:22:01
Allerdings will ich, wenn möglich, nicht anfangen Dinge im Modul zu machen, die nach der Architektur in die Firmware gehören.
Sehe ich auch so. Deshalb auch der Link zu der C/Arduino Variante ;)
Das Modul schaue ich mir gerne an, sobald ich dazu komme.
Zitat von: dev0 am 22 April 2017, 11:37:07
Wenn man eine gleichbleibende Helligkeit über die möglichen Farbtemperaturen haben möchte, dann sind natürlich max 50% pro Strip möglich.
Damit verschenkt man aber zb. bei 3000k x Prozent der maximal möglichen Helligkeit. Wenn man eine Helligkeitsschwankung in kauf nimmt, dann könnte man das auch weiter "hochregeln" im mittleren ct Bereich. Ist auch nicht so schwiegig
das kannst Du jederzeit mit dem "raw" Kommando machen. Als "Alltagsbeleuchtung" sind mir an der Stelle die einfache Bedienung und das erwartete Ergebnis wichtiger als die letzten paar Features.
Zitat von: dev0 am 22 April 2017, 11:37:07
umzusetzen, da man mMn nur das Verhältnis zwischen den beiden Stripes beachten muß. So zumindest habe ich das im EPSEasy Lights Plugin für den reinen ww/cw Betrieb umgestezt.
Sehe ich auch so. Deshalb auch der Link zu der C/Arduino Variante ;)
Das Modul schaue ich mir gerne an, sobald ich dazu komme.
Zitat von: dev0 am 22 April 2017, 11:37:07
Wenn man eine gleichbleibende Helligkeit über die möglichen Farbtemperaturen haben möchte, dann sind natürlich max 50% pro Strip möglich.
Damit verschenkt man aber zb. bei 3000k x Prozent der maximal möglichen Helligkeit. Wenn man eine Helligkeitsschwankung in kauf nimmt, dann könnte man das auch weiter "hochregeln" im mittleren ct Bereich. Ist auch nicht so schwiegig umzusetzen, da man mMn nur das Verhältnis zwischen den beiden Stripes beachten muß. So zumindest habe ich das im EPSEasy Lights Plugin für den reinen ww/cw Betrieb umgestezt.
Ist halt die Frage, wo man hin will.
Mir persönlich ist die Variante mit konstanter Helligkeit lieber, für "volle Möhre" gibt's ja immer noch den RAW-Modus.
Geschmacksache.
Grüße,
Shuzz
Zitat
Als "Alltagsbeleuchtung" sind mir an der Stelle die einfache Bedienung und das erwartete Ergebnis wichtiger als die letzten paar Features.
War auch nur als Vorschlag gedacht, wobei es von der Bedienung her keinen Unterschied machen muß, wenn man es als optionales Feature in die Firmware integriert. Ich hatte es bei mir mal eingebaut, da mir die 50% Helligkeit an 2 Stellen im Haus nicht ausreichte. Es ist aber auch kein wichtiges Feature, da gebe ich Euch völlig recht.
Vergessen zu schreiben: zu den verschiedenen Colorpickern gibt es auch ein Wiki (von Andre?): https://wiki.fhem.de/wiki/Color
Dort ist auch erklärt wie die Rückgabe des "set <dev> ?" Befehls aussehen muß.
Hallo,
Ich möchte an dieser Stelle auch mal meinen Senf dazu geben. Erstmal ein großes Lob an alle, die diesen tollen Controller und die Software entwickelt haben/weiter entwickeln! Zum Thema gleichbleibende Helligkeit vs. maximale Helligkeit: ich kann mir vorstellen, dass es außer mir noch andere gibt, die ein Szenario in der Art haben, dass sie sich die zum Ambiente passende Farbtemperatur einstellen und diese dann per Dim von 0 bis max einstellen wollen - da wäre es schade, wenn man im ungünstigsten Fall 50% Helligkeit "verschenkt". Vielleicht könnte man es wirklich über ein Einstellungsbit lösen?!
Ronny
Gesendet von meinem SM-G935F mit Tapatalk
Das Empfinden des Menschen für Absolute Helligkeit ist extrem tolerant. Zum ersten ist es exponentiell (sprich 2x LED != doppelte Helligkeit) zum zweiten gleicht die Pupille das einfach aus (öffnet oder schließt wie die Blende einer Kamera). In der Regel kann man problemlos die CW/WW mixen um auf die CT zu kommen ohne das es zu (empfundenen) Helligkeitsschwankungen kommt. Klar, messen kann man das. Sehen aber eben kaum.
vg
joerg
Vielleicht kann man es ja durch "Überdimmen" lösen: Dim auf 100% entspricht maximaler Helligkeit bei Mischung mit gleichbleibender Helligkeit, dim auf 200% entspricht CW und WW auf 100% und dim auf 300% heißt CW, WW und RGB auf je 100%. Dazwischen würde jeweils die letzte Stufe dazu gedimmt: z. B. 250% entspricht 100% WW, 100% CW und je 50% R, G und B...
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: RoBra81 am 22 April 2017, 12:44:52
Vielleicht kann man es ja durch "Überdimmen" lösen: Dim auf 100% entspricht maximaler Helligkeit bei Mischung mit gleichbleibender Helligkeit, dim auf 200% entspricht CW und WW auf 100% und dim auf 300% heißt CW, WW und RGB auf je 100%. Dazwischen würde jeweils die letzte Stufe dazu gedimmt: z. B. 250% entspricht 100% WW, 100% CW und je 50% R, G und B...
Gesendet von meinem SM-G935F mit Tapatalk
Mal die Kernfrage: lösen wir damit ein wichtiges, dringendes Problem?
Aktuell diskutieren wir ziemlich weitreichende Änderungen an der Firmware, die z.B. die Aufteilung eines Controllers in mehrere FHEM Geräte einfach machen würde.
Reden wir bei "maximaler Helligkeit" von einem Feature, ohne das der Controller für Euch unsinnig wäre oder von einem Feature, wo man sich einfach denkt "Mist, ich hab da zwei LED aber bekomme nur den Output von einer, es ist nicht hell genug"?
Ich habe auch eine Anwendung, bei der ich meine Strips hier jenseits der "normalen" Farbmischung treibe und das ist, wenn ich im Sommer Videokonferenzen habe und es hinter mir sehr hell ist.
ein
set LED_Bu raw 511,511,768,1023,1023
sorgt dann a) für maximale Helligkeit und b) für ein relativ kühles Licht, das mit dem Sonnenlicht im Hintergrund ganz gut passt.
Könnt Ihr mit sowas leben oder müssen wir hier sofort ran?
pj
(ps: Enhancement Requests zu priorisieren gehört zu meinem normalen Job, also nu, raus mit der Business Justification!)
Zitat von: pjakobs am 22 April 2017, 12:49:44
Reden wir bei "maximaler Helligkeit" von einem Feature, ohne das der Controller für Euch unsinnig wäre
Von meiner Seite aus, auch wenn ich das Thema aufgebracht habe: definitiv nicht nicht Prio 0 ;) Nice to have, someday...
Auch aus meiner Sicht Nice to have - zumal die Aufteilung der Kanäle für meinen Anwendungsfall schon (fast) die Lösung bringen würde: ich möchte den Controller mit RGBWWCW-Streifen für die Terrassenbeleuchtung einsetzen. Da möchte ich zum einen einen sanften Farbwechsel eventuell mit einer weißen Grundhelligkeit kombinieren und zum anderen zum aufräumen nach dem Grillabend auf maximale Helligkeit schalten - beides wäre nach dem aufteilen möglich...
Ronny
PS: ich würde den Controller NIEMALS als unsinnig bezeichnen - zum einen, weil ich ihn sonst nie gekauft hätte und zum anderen habe ich großen Respekt für eure Arbeit!
Gesendet von meinem SM-G935F mit Tapatalk
Also ich kann pjakobs nur beipflichten. Das aktuelle Modul arbeitet perfekt mit der jetzigen Firmware zusammen und läuft (zumindest in meinen Anwendungsfällen) fehlerfrei und zuverlässig.
Nicht, dass ich was gegen ein paar zusätzliche Features hätte aber die aktuellen Diskussionen sind für mich schon extrem speziell. Wir müssen dran denken, dass die Hardware bereits hundertfach im Einsatz ist und ich denke vielen ist Stabilität mind. genauso wichtig wie Berge an Features.
vbs baut ja auch grad fleißig an der Software und ich unterstütze gern, soweit ich kann. Aber dabei merke ich auch wie perfekt es aktuell schon läuft.
Kurz gesagt: Respekt für die Professionalität aber bitte verliert euch nicht zu sehr im Detail.
Zitat von: RoBra81 am 22 April 2017, 13:22:16
PS: ich würde den Controller NIEMALS als unsinnig bezeichnen - zum einen, weil ich ihn sonst nie gekauft hätte und zum anderen habe ich großen Respekt für eure Arbeit!
war ja auch nicht ganz ernst gemeint, aber manchmal muss ich halt mal provokant reinfragen, denn man verrennt sich gerne mal in ein Feature, das schön und praktisch erscheint und eigentlich garnicht sooo bedeutsam ist. Ob es das aber ist oder nicht, das könnt nur ihr mir sagen.
pj
Zitat von: funclass am 22 April 2017, 13:27:15
(...) Das aktuelle Modul arbeitet perfekt mit der jetzigen Firmware zusammen und läuft (zumindest in meinen Anwendungsfällen) fehlerfrei und zuverlässig. (...)
Danke, sowas freut einen immer. :)
Hmm,
ich hab heute seit längerem mal wieder ein Update gemacht, seither bekomm ich das Log vollgemüllt:
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in string ne at ./FHEM/32_LedController.pm line 788.
Hat bis davor einwandfrei funktioniert.
Mein Device (eines, die anderen sind aktuell alle ausgeschaltet):
NR 449
NTFY_ORDER 50-TerassenLed
STATE on
TYPE LedController
Readings:
2016-06-24 16:00:00 HSB 0,0,0
2016-06-24 16:00:00 RGB 000000
2016-06-24 16:00:00 bri 0
2017-04-23 20:43:05 ct 2700
2017-04-23 20:43:05 hsv 213,100,99
2017-04-23 20:43:05 hue 213
2017-04-23 20:43:05 rgb 0072fc
2017-04-23 20:43:05 sat 100
2017-04-23 20:43:05 state on
2017-04-23 20:43:05 val 99
Helper:
isBusy 0
oldVal 0
cmdQueue:
Attributes:
DbLogExclude .*
comment FF0000
defaultColor 120,20,80
group Licht
room Garten
verbose 2
webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb 000000
widgetOverride rgb:colorpicker,rgb
Jemand ne Idee?
lg, Stefan
PS: Ist mir grade aufgefallen: Das LedController wurde ja gar nicht geupdated......Hat sich da in letzter Zeit irgendwas in FHEM geändert, von dem ich nix mitbekommen habe? o_O
Zitat von: Icinger am 23 April 2017, 20:44:01
Hmm,
ich hab heute seit längerem mal wieder ein Update gemacht, seither bekomm ich das Log vollgemüllt:
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $a in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 793.
Use of uninitialized value $a in pattern match (m//) at ./FHEM/32_LedController.pm line 794.
Use of uninitialized value $b in concatenation (.) or string at ./FHEM/32_LedController.pm line 780.
Use of uninitialized value $b in string ne at ./FHEM/32_LedController.pm line 788.
Hat bis davor einwandfrei funktioniert.
Mein Device (eines, die anderen sind aktuell alle ausgeschaltet):
NR 449
NTFY_ORDER 50-TerassenLed
STATE on
TYPE LedController
Readings:
2016-06-24 16:00:00 HSB 0,0,0
2016-06-24 16:00:00 RGB 000000
2016-06-24 16:00:00 bri 0
2017-04-23 20:43:05 ct 2700
2017-04-23 20:43:05 hsv 213,100,99
2017-04-23 20:43:05 hue 213
2017-04-23 20:43:05 rgb 0072fc
2017-04-23 20:43:05 sat 100
2017-04-23 20:43:05 state on
2017-04-23 20:43:05 val 99
Helper:
isBusy 0
oldVal 0
cmdQueue:
Attributes:
DbLogExclude .*
comment FF0000
defaultColor 120,20,80
group Licht
room Garten
verbose 2
webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:rgb 000000
widgetOverride rgb:colorpicker,rgb
Jemand ne Idee?
lg, Stefan
PS: Ist mir grade aufgefallen: Das LedController wurde ja gar nicht geupdated......Hat sich da in letzter Zeit irgendwas in FHEM geändert, von dem ich nix mitbekommen habe? o_O
Hi Stefan, das ist ein kleiner Bug, der sich in der master Version eingeschlichen hatte. Ich sollte mal den develop Zweit promoten, der ist mittlerweile viel besser.
Ganz gelöst ist es, wenn Du Dich mal probehalber auf den feature_set_ct setzt, da warte ich nur noch auf Feedback und gehe dann davon aus, dass der der nächste master wird.
Grüße
pj
@dev0 @RoBra81 könnt Ihr mir mal Feedback geben, ob das Setzen der Weißtemperatur im Branch feature_set_ct funktioniert? Ich hab keinen Controller mit CW dran.
Grüße
pj
Zitat von: pjakobs am 23 April 2017, 21:40:48
@dev0 @RoBra81 könnt Ihr mir mal Feedback geben
Na klar, ich werde aber voraussichtlich nicht vor nächstem WE dazu kommen, da ich nicht zu Hause bin.
Muss mich mal mit ner blöden Frage outen: das mit der einstellbaren Farbtemperatur geht nur, wenn man CW _und_ WW gleichzeitig anschließt und dann den Controller auf RGBWWCW stellt, oder? (bzw. nur RGB) Da würde der Controller die gewünschte Farbtemperatur dann aus Kalt- und Warmweiß zusammenmischen?
Wenn WW/CW vorhanden ist, dann ergibt das mMn das beste Ergebnis (wie zB. bei den Philips Hue Leuchten). Darum geht es mir persönlich, ist leicht umzusetzen und würde MIR reichen.
Wenn kein weißer Stripe vorhanden ist, dann kann man das Weiß auch recht einfach berechnen (Beispiel-Link hatte ich gepostet). Wenn nur ein ww oder cw Stripe vorhanden ist, dann wird es etwas schwieriger (glaube ich), dann muß man neben dem Rausrechnen den Weißanteils auch die Farbtemperatur des Stripes berücksichtigen und ggf. noch wie es das menschliche Auge wahrnimmt. Das Ergebnis wird aber immer noch natürlicher aussehen, als nur aus RGB gemischt.
Edit: WW/CW Typo im ersten Satz korrigiert.
Zitat von: dev0 am 24 April 2017, 15:14:44
Wenn WW/CW vorhanden ist, dann ergibt das mMn das beste Ergebnis (wie zB. bei den Philips Hue Leuchten). Darum geht es mir persönlich, ist leicht umzusetzen und würde MIR reichen.
Wenn kein weißer Stripe vorhanden ist, dann kann man das Weiß auch recht einfach berechnen (Beispiel-Link hatte ich gepostet). Wenn nur ein ww oder cw Stripe vorhanden ist, dann wird es etwas schwieriger (glaube ich), dann muß man neben dem Rausrechnen den Weißanteils auch die Farbtemperatur des Stripes berücksichtigen und ggf. noch wie es das menschliche Auge wahrnimmt. Das Ergebnis wird aber immer noch natürlicher aussehen, als nur aus RGB gemischt.
Edit: WW/CW Typo im ersten Satz korrigiert.
Ich hab am Samstag das Modul ein bisschen erweitert, noch funktioniert's aus Gründen die ich nicht verstehe nicht, aber wenn's denn mal tut, sollte ich die Konfiguration des Controllers von fhem aus steuern können - also auch RGB/RGBWW/RGBCW/RGBWWCW.
Wenn ich die weiß, dann kann ich mir ggf. sogar Gedanken darüber machen, wie ich Farbtemperatur durch Zumischung von RGB im Modul regeln kann. Wobei mir Autokonfiguration auch wichtig wäre. So many Enhancement Requests, so little time...
pj
Zitat von: pjakobs am 24 April 2017, 16:17:12
Ich hab am Samstag das Modul ein bisschen erweitert, noch funktioniert's aus Gründen die ich nicht verstehe nicht, aber wenn's denn mal tut, sollte ich die Konfiguration des Controllers von fhem aus steuern können - also auch RGB/RGBWW/RGBCW/RGBWWCW.
Hab sowas auch schonmal gebaut, vielleicht ist da was für dich dabei:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
Ergibt dann solche Readings in FHEM:
Readings:
2017-04-23 23:27:11 config-color-brightness-blue 100
2017-04-23 23:27:11 config-color-brightness-cw 100
2017-04-23 23:27:11 config-color-brightness-green 100
2017-04-23 23:27:11 config-color-brightness-red 100
2017-04-23 23:27:11 config-color-brightness-ww 100
2017-04-23 23:27:11 config-color-colortemp-cw 6000
2017-04-23 23:27:11 config-color-colortemp-ww 2700
2017-04-23 23:27:11 config-color-hsv-blue 0
2017-04-23 23:27:11 config-color-hsv-cyan 0
2017-04-23 23:27:11 config-color-hsv-green 0
2017-04-23 23:27:11 config-color-hsv-magenta 0
2017-04-23 23:27:11 config-color-hsv-model 0
2017-04-23 23:27:11 config-color-hsv-red 0
2017-04-23 23:27:11 config-color-hsv-yellow 0
2017-04-23 23:27:11 config-color-outputmode 0
2017-04-23 23:27:11 config-events-color_interval_ms 500
2017-04-23 23:27:11 config-events-server_enabled 1
2017-04-23 23:27:11 config-general-device_name wz_lightLedCouch
2017-04-23 23:27:11 config-network-ap-secured 0
2017-04-23 23:27:11 config-network-ap-ssid RGBWW390952
2017-04-23 23:27:11 config-network-connection-dhcp 1
2017-04-23 23:27:11 config-network-connection-gateway 0.0.0.0
2017-04-23 23:27:11 config-network-connection-ip 0.0.0.0
2017-04-23 23:27:11 config-network-connection-netmask 0.0.0.0
2017-04-23 23:27:11 config-network-mqtt-enabled 1
2017-04-23 23:27:11 config-network-mqtt-port 1883
2017-04-23 23:27:11 config-network-mqtt-server minion
2017-04-23 23:27:11 config-network-mqtt-topic_base home/
2017-04-23 23:27:11 config-network-mqtt-username
2017-04-23 23:27:11 config-ota-url http://rgbww.dronezone.de/release/version.json
2017-04-23 23:27:11 config-security-api_secured 0
2017-04-23 23:27:11 config-sync-clock_master_enabled 0
2017-04-23 23:27:11 config-sync-clock_master_interval 5
2017-04-23 23:27:11 config-sync-clock_slave_enabled 1
2017-04-23 23:27:11 config-sync-clock_slave_topic home/wz_lightLedTv/clock
2017-04-23 23:27:11 config-sync-cmd_master_enabled 0
2017-04-23 23:27:11 config-sync-cmd_slave_enabled 1
2017-04-23 23:27:11 config-sync-cmd_slave_topic home/wz_lightLedTv/command
2017-04-23 23:27:11 config-sync-color_master_enabled 0
2017-04-23 23:27:11 config-sync-color_master_interval_ms 0
2017-04-23 23:27:11 config-sync-color_slave_enabled 0
2017-04-23 23:27:11 config-sync-color_slave_topic home/wz_lightLedCouch/color Müsste (eigentlich?) auch so 1:1 mit der Original-FW funktionieren. Sonst für Mutige mal die FW von hier mal ausprobieren: https://forum.fhem.de/index.php/topic,70738.0.html
Zitat von: vbs am 24 April 2017, 14:46:12
Muss mich mal mit ner blöden Frage outen: das mit der einstellbaren Farbtemperatur geht nur, wenn man CW _und_ WW gleichzeitig anschließt und dann den Controller auf RGBWWCW stellt, oder? (bzw. nur RGB) Da würde der Controller die gewünschte Farbtemperatur dann aus Kalt- und Warmweiß zusammenmischen?
Korrekt. RGBWWCW
Theoretisch kannst Du RGB sogar weglassen und den Controller einfach auf Sat=0 stellen, dann werden auch nur die weißen Strips angesteuert.
Zitat von: vbs am 24 April 2017, 16:48:21
Hab sowas auch schonmal gebaut, vielleicht ist da was für dich dabei:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
Ergibt dann solche Readings in FHEM:
Readings:
2017-04-23 23:27:11 config-color-brightness-blue 100
2017-04-23 23:27:11 config-color-brightness-cw 100
2017-04-23 23:27:11 config-color-brightness-green 100
2017-04-23 23:27:11 config-color-brightness-red 100
2017-04-23 23:27:11 config-color-brightness-ww 100
2017-04-23 23:27:11 config-color-colortemp-cw 6000
2017-04-23 23:27:11 config-color-colortemp-ww 2700
2017-04-23 23:27:11 config-color-hsv-blue 0
2017-04-23 23:27:11 config-color-hsv-cyan 0
2017-04-23 23:27:11 config-color-hsv-green 0
2017-04-23 23:27:11 config-color-hsv-magenta 0
2017-04-23 23:27:11 config-color-hsv-model 0
2017-04-23 23:27:11 config-color-hsv-red 0
2017-04-23 23:27:11 config-color-hsv-yellow 0
2017-04-23 23:27:11 config-color-outputmode 0
2017-04-23 23:27:11 config-events-color_interval_ms 500
2017-04-23 23:27:11 config-events-server_enabled 1
2017-04-23 23:27:11 config-general-device_name wz_lightLedCouch
2017-04-23 23:27:11 config-network-ap-secured 0
2017-04-23 23:27:11 config-network-ap-ssid RGBWW390952
2017-04-23 23:27:11 config-network-connection-dhcp 1
2017-04-23 23:27:11 config-network-connection-gateway 0.0.0.0
2017-04-23 23:27:11 config-network-connection-ip 0.0.0.0
2017-04-23 23:27:11 config-network-connection-netmask 0.0.0.0
2017-04-23 23:27:11 config-network-mqtt-enabled 1
2017-04-23 23:27:11 config-network-mqtt-port 1883
2017-04-23 23:27:11 config-network-mqtt-server minion
2017-04-23 23:27:11 config-network-mqtt-topic_base home/
2017-04-23 23:27:11 config-network-mqtt-username
2017-04-23 23:27:11 config-ota-url http://rgbww.dronezone.de/release/version.json
2017-04-23 23:27:11 config-security-api_secured 0
2017-04-23 23:27:11 config-sync-clock_master_enabled 0
2017-04-23 23:27:11 config-sync-clock_master_interval 5
2017-04-23 23:27:11 config-sync-clock_slave_enabled 1
2017-04-23 23:27:11 config-sync-clock_slave_topic home/wz_lightLedTv/clock
2017-04-23 23:27:11 config-sync-cmd_master_enabled 0
2017-04-23 23:27:11 config-sync-cmd_slave_enabled 1
2017-04-23 23:27:11 config-sync-cmd_slave_topic home/wz_lightLedTv/command
2017-04-23 23:27:11 config-sync-color_master_enabled 0
2017-04-23 23:27:11 config-sync-color_master_interval_ms 0
2017-04-23 23:27:11 config-sync-color_slave_enabled 0
2017-04-23 23:27:11 config-sync-color_slave_topic home/wz_lightLedCouch/color
Müsste (eigentlich?) auch so 1:1 mit der Original-FW funktionieren. Sonst für Mutige mal die FW von hier mal ausprobieren: https://forum.fhem.de/index.php/topic,70738.0.html
Oh, kannst Du die Werte auch setzen? Mal sehen, wie ich Deinen und meinen oder consolidieren kann.
Ich würde auch gerne eine Funktion zur Erstkonfiguration einbauen sowie endlich OTA Updates unterstützen. Hast Du da zufällig auch schon was?
pj
Kurz da auf dem Telefon getippt
Ja, setzen der Config geht, zB:
set wz_lightLedTv config config-color-brightness-red 99
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
OTA-Updates aus FHEM heraus sind auch drin:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-firmware-updates
Zitat von: vbs am 25 April 2017, 12:39:02
Ja, setzen der Config geht, zB:
set wz_lightLedTv config config-color-brightness-red 99
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-configuration
OTA-Updates aus FHEM heraus sind auch drin:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#controller-firmware-updates
Aber... Warum sagst Du das erst jetzt 😱
Kannst Du gegen den aktuellen Stand Pull Requests machen? Schau Dir mal das feature-set-ct an en rebase ggf dagegen.
pj
Kurz da auf dem Telefon getippt
Ich hatte dir doch schon den Link zu dem Wiki geschickt, da sind eigentlich alle Änderungen dokumentiert. :)
Meinst du Pull Request für das OTA-Update oder für alles? Nur OTA-Update habe ich nicht einzeln und Pull Request für alles würde ich nicht empfehlen, da viele Sachen nur zusammen mit meinen FW-Änderungen funktionieren.
Zitat von: vbs am 25 April 2017, 12:52:49
Ich hatte dir doch schon den Link zu dem Wiki geschickt, da sind eigentlich alle Änderungen dokumentiert. :)
Meinst du Pull Request für das OTA-Update oder für alles? Nur OTA-Update habe ich nicht einzeln und Pull Request für alles würde ich nicht empfehlen, da viele Sachen nur zusammen mit meinen FW-Änderungen funktionieren.
OTA und config wären super.
Und ja ich hab im Moment ein bisschen runtergefahren, weil ich noch ein paar andere Baustellen hab
[emoji46]
Kurz da auf dem Telefon getippt
Beim Versuch eine Updates bekomme ich folgende Fehlermeldung:
ledcontroller
2017.04.25 19:01:07 1 : UPD FHEM/32_LedController.pm
2017.04.25 19:01:07 1 : Got 50803 bytes for FHEM/32_LedController.pm, expected 50793
2017.04.25 19:01:07 1 : aborting.
Stimmt da was nur bei mir nicht, oder liegt es an der controll-Datei?
Gruß
Thomas
Zitat von: Papaloewe am 25 April 2017, 19:03:10
Beim Versuch eine Updates bekomme ich folgende Fehlermeldung:
ledcontroller
2017.04.25 19:01:07 1 : UPD FHEM/32_LedController.pm
2017.04.25 19:01:07 1 : Got 50803 bytes for FHEM/32_LedController.pm, expected 50793
2017.04.25 19:01:07 1 : aborting.
Stimmt da was nur bei mir nicht, oder liegt es an der controll-Datei?
Gruß
Thomas
da stimmt die Control Datei nicht. Ist das master oder devel?
[edit]
ich hab das für develop gerade mal korrigiert, versuch's bitte nochmal.
pj
Danke, jetzt hat es funktioniert.
Der kleine Nerv mal wieder :D
Mittels dem Zeit-Parameter
set [dev] val 0 [Zeit]
kann ich ja in einer festem Zeit auf 0 runterfahren.
Wie kann ich das aber mit einer festen Steigung machen, also dass er aus 100% doppelt so lange braucht wie aus 50%. Außer natürlich mit Berechnung (Endwert - Ausgangswert)* Faktor ;) ?
Geht das über die defaultRamp?
Zitat von: Per am 02 Mai 2017, 14:59:53
Der kleine Nerv mal wieder :D
Mittels dem Zeit-Parameter
set [dev] val 0 [Zeit]
kann ich ja in einer festem Zeit auf 0 runterfahren.
Wie kann ich das aber mit einer festen Steigung machen, also dass er aus 100% doppelt so lange braucht wie aus 50%. Außer natürlich mit Berechnung (Endwert - Ausgangswert)* Faktor ;) ?
Geht das über die defaultRamp?
hmm... ist so nicht implementiert, könnte man aber mal machen. Die default Ramp ist allerdings einfach eine Zeit, die generell für jeden fade gilt.
pj
Finde die Idee ziemlich interessant! Gehört mMn aber eher in die Firmware. Also entweder gibt man bei einem Fade die Ramp-Time oder die Geschwindigkeit an.
Zitat von: vbs am 02 Mai 2017, 15:14:44
Finde die Idee ziemlich interessant! Gehört mMn aber eher in die Firmware. Also entweder gibt man bei einem Fade die Ramp-Time oder die Geschwindigkeit an.
an der Stelle hätte ich jetzt auch kein Problem, es im Modul unterzubringen, aber in der FW wäre es natürlich noch besser untergebracht.
Die Frage, die sich mir stellt ist: wie würde denn das definiert?
Wir haben drei Parameter, die einen Fade bestimmen: Hue, Saturation und Value.
So wie ich es verstehe würden wir sagen: für 100% der Gesamtänderung sollen z.B. 10s vergehen.
Wenn ich jetzt einen Fade von h1,s1,v1 nach h2,s2,v2 mache, dann wäre die Zeit max(abs(h2-h1)/360*10s,abs(s2-s1)/100*10s,abs(v2-v1)/100*10s), richtig?
Das Modul müsste dafür ein zusätzliches flag bekommen, vielleicht "r" für "relative (speed)"...
Das ließe sich imho relativ leicht abbilden.
pj
Hab damit schon ein bisschen rumgespielt und habe das jetzt in der FW so gemacht, dass man entweder wie bisher den Parameter "t" im JSON-Befehl mitgeben kann oder den Parameter "s" für Speed. Der Speed ist (erstmal) definiert als "Prozentpunkte/Hue-Grad pro Minute" als double-Wert.
Im Modul bin ich gerade am überlegen, wie man unterscheidet zwischen Fade-Time und Fade-Speed. Variante A wäre so, dass man ein Präfix oder Suffix an die Zeit selbst schreibt, wenn man Speed meint: z.B. "50s" oder "s50". Variante B wäre, dass man ein weiteres Flag einführt, z.B. "s".
Ich pack es mal hier mit rein, obwohl es eigentlich eine Anfängerfrage :-[ bzgl. Perl ist.
Wie frage ich den Hex-RGB-Wert ab, ob z.B. nur Grün (00XX00, mit XX > 0) beliebiger Helligkeit an ist?
Klar kann ich mit Division und Rest und so was machen, wie ich Perl kenne, geht das aber eleganter.
Zitat von: Per am 05 Mai 2017, 11:07:50
Ich pack es mal hier mit rein, obwohl es eigentlich eine Anfängerfrage :-[ bzgl. Perl ist.
Wie frage ich den Hex-RGB-Wert ab, ob z.B. nur Grün (00XX00, mit XX > 0) beliebiger Helligkeit an ist?
Klar kann ich mit Division und Rest und so was machen, wie ich Perl kenne, geht das aber eleganter.
Du brauchts drei Dinge:
* hex to integer (hex())
* binäres und (&)
* bit shift (>>/<<)
my $hex="7f3c25"; #irgendwas mit hex
my $int=hex($hex);
# Blau ist das dritte Byte, also die niederwertigsten 8 bit
my $b=$int&0xff;
# Grün sind die Bits 8-15, also muss die Maske um acht Stellen nach links und das Ergebnis danach um acht Stellen nach rechts verschoben werden
my $g=($int&0xff<<8)>>8;
# Rot analog nur noch acht bits weiter "links"
my $r=($int % 0xff<<16)>>16;
printf ("r: %i, g: %i, b: %i",$r,$g,$b);
das ganze kannst Du Dir in eine Subroutine gießen:
my $hex="7f3c25"; #irgendwas mit hex
my ($r,$g,$b)=RGBs2i($hex);
printf ("r: %i, g: %i, b: %i",$r,$g,$b);
sub
RGBs2i($){
my ($rgb)=@_;
my $i=hex($rgb);
return(($i&0xff<<16)>>16,($i&0xff<<8)>>8,$i&0xff);
}
Grüße
pj
Reicht nicht sowas, um zu prüfen ob grün an ist? Kann man natürlich auch auf die anderen Kanäle erweitern.
my $hex="7f3c25"; #irgendwas mit hex
if (hex(substr($hex, 2, 2)) > 0) {
print "ich bin gruen";
}
:o
Das sieht doch nicht so elegant aus wie erwartet :(. Aber du gibst ja auch die genauen Werte zurück, so "granular" brauche ich es gar nicht.
Geht da nicht was in Richtung bitweise-Und und dann > 0?
([LED:rgb] & 0x00ff00) and !([LED:rgb] & 0xff00ff)
ergab zumindest bei ideone (https://ideone.com) das gewünschte Ergebnis.
Zitat von: Per am 05 Mai 2017, 12:25:33
:o
Das sieht doch nicht so elegant aus wie erwartet :(. Aber du gibst ja auch die genauen Werte zurück, so "granular" brauche ich es gar nicht.
Geht da nicht was in Richtung bitweise-Und und dann > 0?
([LED:rgb] & 0x00ff00) and !([LED:rgb] & 0xff00ff)
ergab zumindest bei ideone (https://ideone.com) das gewünschte Ergebnis.
vielleicht habe ich Dich missverstanden, denn ich wollte Dir tatsächlich genau das an die Hand geben. Die Zeile, die Du da stehen hast liefert TRUE wenn grün und nur grün. Funktioniert. Wobei ich mir grad nicht ganz sicher bin, ob LED:rgb einen Zahlenwert oder einen String liefert, ggf. musst Du noch ein hex() drumrum setzen.
pj
Gibt es eigentlich eine Übersicht, welche Befehle aktuell gehen und was nicht?
Wie ist z.B. der aktuelle Status von "pause"?
Habe mir zwei weisse Streifen angeschlossen, wie bekomme ich die aktiviert? Mit rgb ja schon mal nicht und rgbww (oder rgbwwcw o.ä.) gibt es nicht.
Zitat von: Per am 23 Mai 2017, 11:54:47
Gibt es eigentlich eine Übersicht, welche Befehle aktuell gehen und was nicht?
Wie ist z.B. der aktuelle Status von "pause"?
elsif ($cmd eq 'pause'){
347
348 # For use in queued fades.
349 # Will stay at the current color for $fadetime seconds.
350 # NOTE: Does not make sense without $doQueue == "true".
351 # TODO: Add a check for queueing = true? Or just execute anyway?
352 my $val = InternalVal($hash->{NAME}, "valValue", 0);
353 my $hue = InternalVal($hash->{NAME}, "hueValue", 0);
354 my $sat = InternalVal($hash->{NAME}, "satValue", 0);
355 if ($fadeTime eq 0 || $doQueue eq 'false'){
356 Log3 ($hash, 3, "$hash->{NAME} Note: pause only makes sense if fadeTime is > 0 AND if queueing is acti
357 }
358 LedController_SetHSVColor($hash, $hue, $sat, $val, $colorTemp, $fadeTime, 'solid', $doQueue, $direction);
359
also: ein Pause führt zu einem "solid" für $fadeTime sekunden.
Zitat von: Per am 23 Mai 2017, 11:54:47
Habe mir zwei weisse Streifen angeschlossen, wie bekomme ich die aktiviert? Mit rgb ja schon mal nicht und rgbww (oder rgbwwcw o.ä.) gibt es nicht.
Du hast zwei weiße Streifen und nur zwei weiße Streifen angeschlossen und möchtest die als unabhängige Devices benutzen?
Das wird aktuell von der Firmware noch nicht so unterstützt, wie wir uns das vorstellen - und daher auch noch nicht vom Modul. Du kannst da mit "raw" arbeiten, dann macht der Controller aber garnichts, als nur den 10 Bit Wert zu setzen (also 0-1023)
set LED raw 1023,511,0,0,0
aktuell übernimmt das Modul *alle* Werte und pusht sie an den Controller, also wenn Du folgendes machst:
set LED raw 0,255,0,0,0
set LED raw 511,0,0,0,0
dann geht der zweite Kanal mit dem zweiten Kommando wieder aus.
raw unterstütz auch aktuell keine Fades.
Es gibt von @vbs eine Test Firmware, ich hab selbst leider noch keine Zeit gehabt, mir das anzusehen, aber die geht schon deutlich in die Richtung , die ich mir vorstelle
Grüße
pj
Zitat von: pjakobs am 23 Mai 2017, 12:10:45
also: ein Pause führt zu einem "solid" für $fadeTime sekunden.Du hast zwei weiße Streifen und nur zwei weiße Streifen angeschlossen und möchtest die als unabhängige Devices benutzen?
Also ich kann kein "Pause" auswählen,
update behauptet aber, bei
73_LEDcontroller (richtig geschrieben? Habe gerade keinen Zugriff) nix tun zu müssen.
Zitat von: pjakobs am 23 Mai 2017, 12:10:45Du hast zwei weiße Streifen und nur zwei weiße Streifen angeschlossen und möchtest die als unabhängige Devices benutzen?
Nein, ich habe rgb + 2x weiss angeschlossen. Auch wenn letztere nur zum Testen und zwei identische, optisch wird das Ergebnis also eher "mau" aussehen.
Aber wenn es mit raw r,g,b,ww,cw geht, reicht mir das fürs Erste. Hoffe ich.
Nach meinen ersten Spielereien mit rgb-Streifen wird das Ganze in Zukunft eher auf 5x weiss hinauslaufen. Ist aber keine Folge des "schlechten Moduls" oder so, ich habe nur festgestellt, das Farbe noch mehr "Spielerei" als Fhem an sich ist ;D.
Zitat von: Per am 23 Mai 2017, 12:54:22
Also ich kann kein "Pause" auswählen, update behauptet aber, bei 73_LEDcontroller (richtig geschrieben? Habe gerade keinen Zugriff) nix tun zu müssen.
pause ist auch wirklich nur im queue Modus sinnvoll. Dies hier ergibt z.B. ein 10s Grün:
set LED_Bu hsv 60,100,80 0; set LED_Bu pause 10 q;set LED_Bu off 0 qZitat von: Per am 23 Mai 2017, 12:54:22
Nein, ich habe rgb + 2x weiss angeschlossen. Auch wenn letztere nur zum Testen und zwei identische, optisch wird das Ergebnis also eher "mau" aussehen.
Aber wenn es mit raw r,g,b,ww,cw geht, reicht mir das fürs Erste. Hoffe ich.
Nach meinen ersten Spielereien mit rgb-Streifen wird das Ganze in Zukunft eher auf 5x weiss hinauslaufen. Ist aber keine Folge des "schlechten Moduls" oder so, ich habe nur festgestellt, das Farbe noch mehr "Spielerei" als Fhem an sich ist ;D.
Mein Wunsch ist es, dass wir Firmware und Modul so erweitern, dass Du die Kanäle sehr flexibel als RGB, RGBW, RGBWW oder W nutzen kannst, und dafür einzelne Devices definierst, das ist dann glaubich genau das, was Du brauchst.
pj
Moin!
Zitat von: pjakobs am 23 Mai 2017, 18:55:23
... oder W nutzen kannst, und dafür einzelne Devices definierst, ...
Die Funktion wäre der Hammer! Genau das bräuchte ich - dann hätte ich 5-6 Controller weniger im Einsatz!
Gruß
Alex
Zitat von: pjakobs am 23 Mai 2017, 18:55:23pause ist auch wirklich nur im queue Modus sinnvoll.
Also gehen tut
pause, nur im Menü ist es nicht drin?! Habe mir aktuell mit
DOIF wait geholfen.
Mit
raw konnte ich die weissen Streifen ansprechen, ich hatte nur mal was gelesen von automatischer Mischung und so und war verwundert, dass das bei mir nicht passiert.
Das das mit dem "weiss" aktuell noch nicht geht, ist für mich verkraftbar, da ja abzusehen ist, dass es kommt. Und solange kann ich einen zweiten entbehren (weiss muss ich nicht faden, da kann ich 5x weiss dranhängen), hab ja auf Vorrat gekauft ;).
Guten Abend,
gibt es die Möglichkeit den Controller per Fernbedienung mit verschiedenen Farben einzuschalten?
Ich denke da an eine einfache Möglichkeit für z.B. Kinderzimmer.
mit dem Befehl set LEDController on wird er ja mit den attr defaultColor und anderen Vorgaben eingeschalten
kann ich dem on Befehl eine andere als defaultColor Farbe zufügen?
wenn ja könnte ich eine 8 Tasten Fernbedienung verwenden und 7 verschiedene Farben einschalten + eine Taste für aus.
Gibt es für den Controller auch Szenarien wie z.B Sonnenaufgang / Sonnenuntergang / oder andere Farbkombinationen?
Danke im Voraus
Die beiden weiß Kanäle sind ja als Warmweiß und Kaltweiß definiert, ihre relative Helligkeit kannst Du mit dem colortemp Parameter setze. Die absolute gemeinsame Helligkeit über den val Wert.
Und ja, pause funktioniert.
Kurz da auf dem Telefon getippt
Zitat von: peble am 23 Mai 2017, 22:24:23
Guten Abend,
gibt es die Möglichkeit den Controller per Fernbedienung mit verschiedenen Farben einzuschalten?
Ich denke da an eine einfache Möglichkeit für z.B. Kinderzimmer.
mit dem Befehl set LEDController on wird er ja mit den attr defaultColor und anderen Vorgaben eingeschalten
kann ich dem on Befehl eine andere als defaultColor Farbe zufügen?
wenn ja könnte ich eine 8 Tasten Fernbedienung verwenden und 7 verschiedene Farben einschalten + eine Taste für aus.
Gibt es für den Controller auch Szenarien wie z.B Sonnenaufgang / Sonnenuntergang / oder andere Farbkombinationen?
Danke im Voraus
Du kannst den Kontroller statt mit "on" einfach mit "set LED hsv..." einschalten und so den Farbwert direkt einstellen. Und auch Sonnen auf- und Untergänge sind leicht gemacht, Du kannst ja mehrere fades mit dem "q" flag zu einer Animation zusammenfügen.
pj
Kurz da auf dem Telefon getippt
Hallo pj
Danke für die Antwort
funktioniert.
mir ist aufgefallen nach einem Neustart kommen bei mir folgende Einträge im LOG
ist das problematisch oder kann man das ignorieren?
2017.05.24 00:24:57 3: LED_Controller_1 DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.05.24 00:24:57 3: LED_Controller_1 DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.05.24 00:24:57 3: LED_Controller_1 DEBUG: doInternalReadingsUpdate: no hsv in cmd hash.
2017.05.24 00:26:08 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 00:26:08 3: LED_Controller_1 DEBUG: Internal hue - helper: 236 and direct: 50
2017.05.24 00:26:08 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 00:26:08 3: LED_Controller_1 DEBUG: Internal hue - helper: 236 and direct: 50
2017.05.24 00:26:14 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 00:26:14 3: LED_Controller_1 DEBUG: Internal hue - helper: 194 and direct: 50
2017.05.24 00:26:20 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 00:26:20 3: LED_Controller_1 DEBUG: Internal hue - helper: 125 and direct: 50
2017.05.24 00:26:21 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 00:26:21 3: LED_Controller_1 DEBUG: Internal hue - helper: 125 and direct: 50
2017.05.24 00:27:15 3: LED_Controller_1 (Set) called with off, busy flag is 0
2017.05.24 00:27:15 3: LED_Controller_1 DEBUG: Internal hue - helper: 125 and direct: 0
2017.05.24 00:27:15 3: LED_Controller_1 (Set) called with off, busy flag is 0
2017.05.24 00:27:15 3: LED_Controller_1 DEBUG: Internal hue - helper: 125 and direct: 0
auch wenn ich per Fernbedienung schalte kommt:
2017.05.24 22:35:44 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 22:35:44 3: LED_Controller_1 DEBUG: Internal hue - helper: 161 and direct: 50
2017.05.24 22:35:44 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 22:35:44 3: LED_Controller_1 DEBUG: Internal hue - helper: 161 and direct: 50
2017.05.24 22:35:48 3: LED_Controller_1 (Set) called with hsv, busy flag is 0
2017.05.24 22:35:48 3: LED_Controller_1 DEBUG: Internal hue - helper: 194 and direct: 50
2017.05.24 22:35:49 3: LED_Controller_1 (Set) called with hsv, busy flag is 1
2017.05.24 22:35:49 3: LED_Controller_1 DEBUG: Internal hue - helper: 194 and direct: 50
mein FHEM läuft auf einem Cubietruck mit Igor Image von 2014
Soweit ich sehe, hast Du die verbosity auf 5 stehen (entweder am LED device oder global), dreh das mal runter auf 2.
Kurz da auf dem Telefon getippt
Danke
Hatte global verbose auf 3
hab mal auf 2 runtergestellt jetzt sind die Einträge weg.
Kann das also ignoriert werden
Ich habe eine Übergangslösung für die Farbtemperatursteuerung zwischen alle RGB LEDs bis hin zu rein WW LEDs.
Ich verwende den Kontroller mit einem RGBW 4in1 LED Streifen mit einer Warmweißen LED. Ich kann die Farbtemperatur über folgendes cmdalias steuern:
set RGBW_.* ct .* AS {
my $A = 1023-$EVTPART2;
my $B = $EVTPART2;
fhem("attr $EVTPART0 comment raw $A,$A,$A,$B,$B -- $EVENT");
fhem("set $EVTPART0 raw $A,$A,$A,$B,$B");
}
Ein Wert von 550 entspricht in etwa einem Wert von 6500K (im Vergleich zu Philips Hue) und ein Wert von 1023 in etwa 3000 K (Herstellerangabe). Wenn man noch die roten LED maximal dazu mischt erreicht man einen Wert von ca 2000K (ebenfalls im Vergleich zu Hue).
Eine exakte Berechnung der Farbtemperatur braucht sicherlich eine Kalibrierung der jeweiligen Leuchtmittel aber es wäre bestimmt ein schönes Feature des FHEM-Moduls, an welchem vielleicht noch andere Interesse hätten. Vielleicht kommt dann auch ein einfacheres "Alexa, mach das Licht im Wohnzimmer warmweiß" ;)
Vielleicht hat ja noch jemand Interesse daran.
Grüße
Fabian
Sicherlich in keiner Weise Farbtechnisch korrekt, aber es funktioniert. Die Funktionen lassen sich nach eigenen Bedrüfnissen anpassen.
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");
}
Gibt es eine Möglichkeit bei dem Controller vordefinierte Farben mit einem Schalter durchzuschalten?
Das sollte doch mit DOIF möglich sein
ich habe folgendes versucht haut aber noch nicht hin evtl. hat jemand schon sowas am laufen oder eine andere Möglichkeit dafür
Was ich will: an einem Schalter (TRX_HOMEEASY) mehreren Farben nacheinander durchschalten bzw. auswählen
define LED_2 DOIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:000000])
(set LED_Controller_4 rgb 2ed400)
DOELSEIF ([LedController LED_Controller_4 rgb:2ed400])
(set LED_Controller_4 rgb 00c9d4)
DOELSEIF ([LedController LED_Controller_4 rgb:00c9d4])
(set LED_Controller_4 rgb 0027d4)
DOELSEIF ([LedController LED_Controller_4 rgb:0027d4])
(set LED_Controller_4 rgb bb00d4)
DOELSEIF ([LedController LED_Controller_4 rgb:bb00d4])
(set LED_Controller_4 rgb d40000)
DOELSEIF ([LedController LED_Controller_4 rgb:d40000])
(set LED_Controller_4 rgb off)
Du musst den Schalter [TRX_HOMEEASY:"on"] and in jedem Zweig triggern:
define LED_2 DOIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:000000])
(set LED_Controller_4 rgb 2ed400)
DOELSEIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:2ed400])
(set LED_Controller_4 rgb 00c9d4)
DOELSEIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:00c9d4])
(set LED_Controller_4 rgb 0027d4)
DOELSEIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:0027d4])
(set LED_Controller_4 rgb bb00d4)
DOELSEIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:bb00d4])
(set LED_Controller_4 rgb d40000)
DOELSEIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:d40000])
(set LED_Controller_4 rgb off)
Und du sollst Code-Tags verwenden!
Wenn du das Licht bei jedem Zwischenschritt ausschalten willst, musst du die Farben Zwischenspeichern, weil er ja sonst immer bei 000000 anfängt.
Außerdem solltest du noch einen Zweig dafür nutzen, was passiert, wenn keine "glatten" Werte anliegen.
Hallo,
jetzt habe ich mich auch mal mit dem Controller beschäftigt und mir sind zwei Dinge aufgefallen.
- Der Controller erscheint immer disconnected. Ist das normal? Warum?
- Das Device wird in FHEM nicht automatisch aktualisiert. Wenn ein Farbwerte gesetzt wird, bleibt das reading unverändert. Somit ist auch eine verlässliche "ist" Anzeige in der UI nicht möglich.
Hier ist die Definition meines Controllers
defmod gang.sideboard.light LedController gang-dim
attr gang.sideboard.light event-on-change-reading 1
attr gang.sideboard.light room Beleuchtung,Gang
attr gang.sideboard.light webCmd on:offKönnt Ihr mir einen Tip geben, was ich falsch mache?
Vielen Dank im Voraus
Zitat von: peble am 25 Oktober 2017, 22:45:30
Gibt es eine Möglichkeit bei dem Controller vordefinierte Farben mit einem Schalter durchzuschalten?
Das sollte doch mit DOIF möglich sein
ich habe folgendes versucht haut aber noch nicht hin evtl. hat jemand schon sowas am laufen oder eine andere Möglichkeit dafür
Was ich will: an einem Schalter (TRX_HOMEEASY) mehreren Farben nacheinander durchschalten bzw. auswählen
define LED_2 DOIF ([TRX_HOMEEASY:"on"] and [LedController LED_Controller_4 rgb:000000])
(set LED_Controller_4 rgb 2ed400)
DOELSEIF ([LedController LED_Controller_4 rgb:2ed400])
(set LED_Controller_4 rgb 00c9d4)
DOELSEIF ([LedController LED_Controller_4 rgb:00c9d4])
(set LED_Controller_4 rgb 0027d4)
DOELSEIF ([LedController LED_Controller_4 rgb:0027d4])
(set LED_Controller_4 rgb bb00d4)
DOELSEIF ([LedController LED_Controller_4 rgb:bb00d4])
(set LED_Controller_4 rgb d40000)
DOELSEIF ([LedController LED_Controller_4 rgb:d40000])
(set LED_Controller_4 rgb off)
@peble: mit Each kannst du das elegant lösen. Das hier ist mein DEF des Notify:
Taster4.3_sKurzerLangerDruck:partial_1 set LEDStripes_Schlafzimmer {(Each("LEDStripes_Schlafzimmer","on/RGB 9E5058/RGB 5E395C/RGB 4D330B/RGB ED8E00/RGB 56DB2E/RGB ED6002/RGB 753612/RGB 61A4AB/RGB 76ADA6/RGB 111461/RGB 4D1B46/RGB E3280B/RGB 46187A/HSV 60,62,100/HSV 180,62,100/HSV 300,62,100","/"))}Gruß Sascha
guten abend :-)
ich bin gerade am verzweifeln, ich versuche seit ca. 2 Monaten den dritten Anlauf zu starten, ich schaffe es nicht den LED-Streifen blinken zu lassen.
Habe etliche Seiten hier im Forum vom ESP-rgbww durch.
Ich habe z.b. ein Dash-Button als Türklingel.
Wenn der gedrückt wird, soll der LED-Streifen bis zu 10 mal blinken in Rot, kann auch "weiß-rot-weiß-rot" sein, wenn er fertig ist soll er sich wieder abschalten, oder auf vorheriger Einstellung gehen.
mein letztes Beispiel klappt noch immer nicht
dash:50-f5-da-ce-ed-c5..short
{fhem("set Fritzbox ring 610;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB blink r;
set LED_Stripe_RGB hsv 0,100,100 r;
set LED_Stripe_RGB off 0 q;
set LED_Stripe_RGB hsv 0,0,0 r;
set pushmsg msg 'FHEM' 'Es klingelt an der Haustüre'")}
kann mir evtl. jemand helfen ??
Gruß Werner
Moin Werner,
Benutzt Du die 'original' Firmware oder die vbs Version?
Das fhem Modul, das ich für die ursprüngliche Firmware geschrieben habe unterstützt kein 'blink'.
Das wäre aber nicht ganz schlimm, Du könntest es z. B. mit folgenden befehlen versuchen:
set <LED> on 1;
set <LED> off 1 q;
set <LED> on 1 q;
set <LED> off 1 q;
set <LED> on 1 q;
set <LED> off 1 q;
Die 1 ist die Dauer des Übergangs von "aus" nach "an" in Sekunden, das heißt in diesem Fall würde der Streifen nicht blinken, sondern pulsieren.
Möchtest Du ihn blinken lassen, dann sieht der Code ein bisschen anders aus:
set <LED> on 0;
set <LED> pause 1 q;
set <LED> off 0 q;
set <LED> pause 1 q;
set <LED> on 0 q;
set <LED> pause 1 q;
set <LED> off 0 q;
set <LED> pause 1 q;
set <LED> on 0 q;
set <LED> pause 1 q;
set <LED> off 0 q;
Hier wird der Controller jeweils ohne Fade (Ramp =0) ein und ausgeschaltet. Die Pause dauert jeweils eine Sekunde. Das q bewirkt, dass der Befehl an das aktuelle "Programm" angehängt wird. Ohne q würde jeder Befehl sofort ausgeführt werden.
Wenn ich mich recht entsinne, kannst Du für die Pause auch Dezimalbrüche verwenden (0.5 z. B.)
Statt 'on' und 'off' kannst Du in beiden Beispielen natürlich auch jeden anderen Farbbefehl (rgb, hsv, dim, rotate, hue, val etc) verwenden.
Grüße,
pj
Kurz da auf dem Telefon getippt
moin pj,
hier ein Auszug vom Controller reading
info-firmware vbs312018-03-14 20:28:28
info-sming_version 3.5.0 2018-03-14 20:28:28
info-uptime 12780 2018-03-14 20:28:28
info-webapp_version 0.3.3-shojo7 2018-03-14 20:28:28
lastFwUpdate Update successful - Restarting device... 2018-03-14 16:55:09
Werde es nachher mal versuchen
vielen Dank
hab einen sonnigen Tag
Gruß Werner
ah, ok, ich hab's eben mit der vbs firmware und dem zugehörigen Modul versucht
1. scheint "blink" damit (noch) nicht zu funktionieren
2. das erste Snippet (ohne pause) funktioniert damit
3. das zweite Snippet funktioniert nicht
pj
ich hab's gerade nochmal getestet, "blink" funktioniert mit der Kombi vbs Modul/vbs Firmware nicht, die Leuchte geht aus und wieder an und das war's. Vielleicht kann sich @vbs das mal ansehen?
pj
Hallo,
es scheint zu funktionieren, im Moment noch in weiß aber ok ;)
Allerdings funktioniert es nur wenn die LED-Leiste vorher off ist.
Ist die Leiste eingeschaltet und es wird geklingelt, dann geht die leiste nur auf "off"
Drücke ich dann nochmal auf den Knopf, blinkt es wieder
dash:50-f5-da-ce-ed-c5..short
{fhem("set Fritzbox ring 610;
set LED_Stripe_RGB on 1;
set LED_Stripe_RGB off 1 q;
set LED_Stripe_RGB on 1 q;
set LED_Stripe_RGB off 1 q;
set LED_Stripe_RGB on 1 q;
set LED_Stripe_RGB off 1 q;
set LED_Stripe_RGB on 1 q;
set LED_Stripe_RGB off 1 q;
set LED_Stripe_RGB on 1 q;
set LED_Stripe_RGB off 1 q;
set LED_Stripe_RGB on 1 q;
set LED_Stripe_RGB off 1 q;
set pushmsg msg 'FHEM' 'Es klingelt an der Haustüre'")}
Gruß Werner
Zitat von: pjakobs am 15 März 2018, 11:27:21
ich hab's gerade nochmal getestet, "blink" funktioniert mit der Kombi vbs Modul/vbs Firmware nicht, die Leuchte geht aus und wieder an und das war's. Vielleicht kann sich @vbs das mal ansehen?
Klingt aber erstmal korrekt. Was hast du getestet und was hätte passieren sollen?
also ich habe einmal im eingeschalteten Zustand =Leiste ist "ON" Weiß
Klingel drücken = Leiste schaltet sich nur auf "OFF" = kein blinken
Leiste ist auf "OFF"
Klingel drücken = Leiste = "blinkt"
Ich hoffe das ist Verständlich :)
Gruß Werner
Kannst du mal konkret einen Befehl sagen, den du abgesetzt hast? Also vermutlich sowas wie "set myLed blink 5" (als das Aufblinken wird für 5 Sekunden gehalten)?
häää, jetzt verstehe ich dich nicht ;)
oben im Post ist ein list vom notify Dash_Button.
das wird ausgeführt
Gruß Werner
Ich denke, ihr redet aneinander vorbei: vbs hat auf den Beitrage von pjakobs geantwortet, dass der blink-Befehl nicht funktioniert.
Zitat von: vbs am 15 März 2018, 15:34:34
Kannst du mal konkret einen Befehl sagen, den du abgesetzt hast? Also vermutlich sowas wie "set myLed blink 5" (als das Aufblinken wird für 5 Sekunden gehalten)?
Das was du und pjakobs beschreiben klingt für mich eher nach on-for-timer - laut commandref ist blink jedoch ein wiederholtes blinken und das scheint (nicht durch mich getestet) nicht zu funktionieren.
Aus der commandref:
blink <anzahl> <blink-periode>
Das Gerät wird mit "on" für die <blink-periode> eingeschaltet, und das wird nach <blink-periode> wiederholt. Um das Blinken vorzeitig zu stoppen spezifiziert man "0 0" als Argument.Ronny
ja sorry, bin vom lesen und probieren. schon völlig durcheinander :D
ich mach erstmal pause
Ok, versuchen wir es anders: Mach mal bitte "set LED_Stripe_RGB blink" und berichte mal, ob der Streifen einmal *kurz* sichtbar blinkt. Ich hatte Peter so verstanden, dass "blink" generell nicht funktionieren würde.
Dann mal ein "set LED_Stripe_RGB blink 2", was zu einem langen 2-Sek-Blinker führen sollte. Ist evtl. einfach ein Missverständnis, was bei einem "blink" passieren soll?
Wenn sich das erstmal so verhält wie beschrieben, dann gucken wir weiter.
Ja ich glaub Ronny hat Recht. Etwas verwirrend, da es eigentlich um das geänderte FHEM-Modul zur vbs-Firmware geht wir uns hier aber im Thread zum Original-Modul befinden. Die Funktionsweise von "blink" hat sich in meiner Variante geändert. Die Doku ist hier:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/wiki#blink
Wahrscheinlich aber auch nicht eindeutig, wenn man die "alte" Funktionsweise erwartet. Sorry für die Konfusion.
hallo @vbs,
wenn ich gemeint bin ;)
Also bei "set LED_Stripe_RGB blink" einmal kurz Rot
und bei "set LED_Stripe_RGB blink 2 " etwas länger Rot
Gruß Werner
PS. Das war jetzt mein 500 ster Beitrag den ich geschrieben habe, bekomme ich jetzt einen Preis ??? ( Raspi3+) hahaha
@vbs was Du sagst ist: Blink blinkt genau ein mal, nicht n mal, denn "set <LED> blink 5" hatte ich als "5x blinken" verstanden und ich glaube, @intruder1956 auch.
pj
Ja genau.
aber hast Du ne Idee, warum mein zweites Beispiel (mit ramp=0 und pause 1) nicht auf den -vbs Dingern funktioniert? Im Log hab ich nichts erkennen können.
Zitat von: pjakobs am 15 März 2018, 17:15:48
aber hast Du ne Idee, warum mein zweites Beispiel (mit ramp=0 und pause 1) nicht auf den -vbs Dingern funktioniert? Im Log hab ich nichts erkennen können.
Ich denke, dass das 'pause'-Kommando nicht das macht, was du wünscht:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#channel-animation-control
Probiert mal sowas, das müsste gehen (kann natürlich entsprechend abgewandelt werden, aber das Prinzip sollte klar werden):
set wz_lightLedCouch on 0;
set wz_lightLedCouch on 2 q;
set wz_lightLedCouch off 0 q;
set wz_lightLedCouch off 2 q;
set wz_lightLedCouch on 0 q;
set wz_lightLedCouch on 2 q
Man bräuchte in der FW am besten einen Befehl "stay" oder ähnlich, der das macht, was du dir mit "pause" gewünscht hast. Damit könnte man es noch etwas vereinfachen.
Ach, ich Trottel. Geht sogar jetzt schon pippi-einfach mit solid-Flag... ::)
set wz_lightLedCouch on 0;
set wz_lightLedCouch on 2 sq;
set wz_lightLedCouch off 2 sq;
set wz_lightLedCouch on 2 sq;
set wz_lightLedCouch off 2 sq;
Anstelle eines dedizierten Kommandos "stay", kann man einfach ein relatives Kommando zusammen mit solid-Flag nutzen. Ist zugegebenermaßen nicht ganz so elegant wie ein eigener Befehl. :-[
Hält die (dann) aktuelle Farbe für 5 Sekunden:
set wz_lightLedCouch hsv +0,+0,+0 5 sq;
Wie bei allen Befehlen, kann man den Befehl auch nur auf bestimmte Kanäle beziehen.
Das würde nur den Hue-Kanal anhalten:
set wz_lightLedCouch hsv +0,, 5 sq;
Beispiel:
set wz_lightLedCouch hsv 180,100,100 5 q;
set wz_lightLedCouch hsv +0,+0,+0 8 sq;
set wz_lightLedCouch hsv 0,30,30 q;
Fade vom aktuellen Zustand mit einer Ramp von 5-Sek zu 180,100,100. Dann für 8 Sek. den Status halten und dann zu 0,30,30 switchen.
Konntet ihr das schonmal testen? Klappt das jetzt bei euch bzw. verhält es sich erwartungsgemäß? Würde es gerne beheben andernfalls.
Tag zusammen,
Nachdem ich mit der Suche, auf den ersten Seiten des Thread und im Github nichts gefunden habe frage ich doch mal nach.
Wie kann ich denn das FHEM Modul installieren?
Danke & Grüße
Frank
EDIT: kaum gepostet hab ichs gefunden. im Firmware Thread... :)
Zitat von: Frank_Huber am 26 April 2018, 16:12:10
EDIT: kaum gepostet hab ichs gefunden. im Firmware Thread... :)
Moin Frank,
ja, ich glaube, die Doku könnte noch besser werden. Aktuell gibt es zwei Firmware Versionen, die originale, die im Firmware Thread verlinkt ist und die von @vbs, die neben Bugfixes einige Verbesserungen enthält. Für beide brauchst Du auch unterschiedliche fhem-Module, sonst funktioniert es nicht. Ich hoffe, wir können das in Zukunft zusammenführen.
Grüße
pj
Dann hatte ich wohl Glück, die zwei Controller (HW 1.5) die ich über den Marktplatz erstanden habe kommunizieren mit dem FHEM Modul.
woran erkenne ich denn als RGBWW Laie welc der FW Versionen drauf ist?
Wenn Du die Adresse des Controllers aufrufst, kommst du auf die WEB-GUI. Da gibt es ganz rechts einen Reiter "System-Settings", und dort eine Abteilung "Firmware". Da steht alles drin.
Gruß vom Blauhorn
Hallo vbs,
darf ich dich um eine Prüfung bei dir und ggf. Korrektur im Modul bitten?
Es geht um meinen Post im Firmware-Thread ... https://forum.fhem.de/index.php/topic,70738.msg796458.html#msg796458
Ich habe etwas analysiert und getestet. Die Aussage "geht nicht" lautet nun konkreter, Fading dauert viel zu lange :)
Aufruf "set hue +359 l 5" ... ganzer Farbkreis (-1) dauert 5 Sekunden. Log sagt das hier aus
2018.04.27 15:29:29.835 5: LED3_new setting HUE to +359
2018.04.27 15:29:29.835 5: LED3_new: encoded json data: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"d":0,"q":"single"}
2018.04.27 15:29:29.836 5: LED3_new: set HSV color request: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"d":0,"q":"single"}
Selber Aufruf mit zusätzlichem Parameter "r" für Re-Queue (set hue +359 l 5 r)
2018.04.27 15:36:16.479 5: LED3_new setting HUE to +359
2018.04.27 15:36:16.480 5: LED3_new: encoded json data: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"q":"single","d":1,"r":"true"}
2018.04.27 15:36:16.480 5: LED3_new: set HSV color request: {"hsv":{"h":"+359"},"cmd":"fade","t":5000,"q":"single","d":1,"r":"true"}
--> Warum ist ... "d":1 ... gesetzt? Es sollte der Wert 0 sein.
Dieses wird in sub EspLedController_ArgsHelper gesetzt. Habe eine kleine Korrektur gemacht und es sieht so aus, als würde es damit richtig funktionieren.
Zeile 1329ff
$requeue = 'true' if ( $flags =~ m/r/i );
#$d = ( $flags =~ m/l/ ) ? 0 : 1; <--- dein Code
$d = 0 if ( $flags =~ m/l/i ); <--- mein Test
$transitionType = 'solid' if ( $flags =~ m/s/i );
Wenn die Prüfung auf das r-Flag erfolgreich war, wird das d-Flag zurückgesetzt, warum auch immer. Habe nicht weiter analysiert, auf den ersten Blick komisch, es ist kein continue, exit o. ä. drin das die weitere Verarbeitung abbricht. Ohne r-Flag passt es ja.
Mein Setup:
- R3 mit Raspbian stretch
- Perl .... perl5 (revision 5 version 24 subversion 1)
danke dir!
Noch eine Frage:
Kann ich diese Meldungen unterdrücken? Verbose ist global 1
2018.04.28 17:14:25.342 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:13:05.327 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:13:05.315 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:13:04.611 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:13:04.590 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:59.916 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:59.896 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:54.709 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:54.689 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:49.512 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:49.491 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:46.376 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:46.355 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:43.809 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:43.784 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:39.730 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:38.368 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:12:18.211 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:12:18.184 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:11:47.670 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:11:47.649 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:11:29.679 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:11:29.653 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:11:18.235 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:11:18.185 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:11:01.669 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:11:01.649 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:10:18.211 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:10:18.184 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:10:10.944 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:10:10.923 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:09:40.495 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:09:40.474 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:09:27.688 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:09:27.667 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:09:18.218 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:09:18.184 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:08:49.652 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:08:49.632 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:08:18.223 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:08:18.186 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:07:58.937 1: 192.168.0.60:9090 reappeared (LED2)
2018.04.28 17:07:58.914 1: 192.168.0.60:9090 disconnected, waiting to reappear (LED2)
2018.04.28 17:07:52.013 1: 192.168.0.60:9090 reappeared (LED2)
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 ;)
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.
Hallo,
ich bin mir nicht sicher, ob mein Problem mit dem fhem-Modul oder dem Controller zu tun hat.
Ich verwende einen Bewegungssensor mit Helligkeit um abhängig von der Tageszeit den LED-Controller zu schalten. Das hat bis vor ca. 2 Wochen monatelang funktioniert. Nach einem Update von Fhem und dem LED-Controller (vbs32) aber nicht mehr. Das Notify kommt zwar im Controller an, schaltet den Controller aber nicht mehr an.
Das notify:
defmod Bewegungsmelder_Bad_On notify HM_Bad_Motion:motion:.on.* { \
\
my $brightness = ReadingsVal("HM_Bad_Motion", "brightness", "0");;\
my $rgb = ReadingsVal("Bad_Led_Dummy", "RGB", "3D4018");;\
Log 1, "brightness - $brightness : $rgb";;\
Log 1, "hour - $hour";;\
\
if ($brightness < 130 ){\
if($hour < 5)\
{\
fhem("set LedController2 hsv 13.02,100,7.04");;\
fhem("set LedController3 hsv 13.02,100,7.04");;\
}else {\
fhem("set LedController2 hsv 42.00,96.00,97.00");; \
fhem("set LedController3 hsv 42.00,96.00,97.00");;\
}\
}\
\
fhem("delete LedControllerBad_Off");;\
fhem("define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off");;\
}
Im Log-File sehe ich aber nur noch:
2018.05.09 00:26:40 5: Triggering Bewegungsmelder_Bad_On
2018.05.09 00:26:40 4: Bewegungsmelder_Bad_On exec {
my $brightness = ReadingsVal("HM_Bad_Motion", "brightness", "0");;
my $rgb = ReadingsVal("Bad_Led_Dummy", "RGB", "3D4018");;
Log 1, "brightness - $brightness : $rgb";;
Log 1, "hour - $hour";;
if ($brightness < 130 ){
if($hour < 5)
{
fhem("set LedController2 hsv 13.02,100,7.04");;
fhem("set LedController3 hsv 13.02,100,7.04");;
}else {
fhem("set LedController2 hsv 42.00,96.00,97.00");;
fhem("set LedController3 hsv 42.00,96.00,97.00");;
}
}
fhem("delete LedControllerBad_Off");;
fhem("define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off");;
}
2018.05.09 00:26:40 1: brightness - 71 : F7B00A
2018.05.09 00:26:40 1: hour - 0
2018.05.09 00:26:42 2: LedController2: EspLedController_ParseBoolResult error: http://ledcontroller2.fritz.box/color: empty answer received
2018.05.09 00:26:44 2: LedController2: EspLedController_ParseBoolResult error: http://ledcontroller2.fritz.box/color: empty answer received
2018.05.09 00:26:44 3: LedController2: EspLedController_RGB2HSV: 990.905882352941 - 706.070588235294 - 40.1176470588235
2018.05.09 00:30:30 3: LedController2: EspLedController_RGB2HSV: 990.905882352941 - 706.070588235294 - 40.1176470588235
Den Fehler EspLedController_ParseBoolResult verstehe ich nicht, es geht:
pi@fhem /opt/fhem/log $ curl http://ledcontroller2.fritz.box/color
{"raw":{"r":72,"g":15,"b":0,"ww":0,"cw":0},"hsv":{"h":13.02,"s":100.00,"v":7.04,"ct":2700}}
Setze ich den Befehl:
set LedController2 hsv 13.02,100,7.04 in fhem direkt ab, schaltet der LED-Controller ganz normal.
Mir fällt gerade auf, dass es das gleiche Verhalten ist, wenn ich den Befehl 2x hintereinander ausführe. Könnte es wirklich sein, dass der Controller auf http://ledcontroller2.fritz.box/color zuerst nichts bekommt und daher auch nicht schaltet?
Vielleicht DNS Problem?
Update: Kann ich ausschliessen:
2018.05.09 09:00:15 2: LedController2: EspLedController_ParseBoolResult error: http://192.168.0.25/color: empty answer received
Update: verbose 5
2018.05.09 09:10:22 5: LedController2 raw: F7B00A, r: 247, g: 176, b: 10
2018.05.09 09:10:22 3: LedController2: EspLedController_RGB2HSV: 990.905882352941 - 706.070588235294 - 40.1176470588235
2018.05.09 09:10:22 5: LedController2: called SetHSVColor
2018.05.09 09:10:22 5: LedController2: encoded json data: {"t":"1000","hsv":{"v":97,"s":96,"h":42},"q":"single","cmd":"fade","d":"1"}
2018.05.09 09:10:22 5: LedController2: set HSV color request: {"t":"1000","hsv":{"v":97,"s":96,"h":42},"q":"single","cmd":"fade","d":"1"}
2018.05.09 09:10:23 5: LedController2: EspLedController_ParseBoolResult
2018.05.09 09:10:23 2: LedController2: EspLedController_ParseBoolResult error: http://192.168.0.25/color: empty answer received
Noch ein Update: curl von Hand geht auch:
curl --header "Content-Type: application/json" --request POST --data '{"t":"1000","hsv":{"v":97,"s":96,"h":42},"q":"single","cmd":"fade","d":"1"}' http://192.168.0.25/color
{"success":true}
Ich werde daraus nicht schlau. :-/
VG Thomas
Zitat von: Tom71 am 09 Mai 2018, 08:48:34
defmod Bewegungsmelder_Bad_On notify HM_Bad_Motion:motion:.on.* { \
\
my $brightness = ReadingsVal("HM_Bad_Motion", "brightness", "0");;\
my $rgb = ReadingsVal("Bad_Led_Dummy", "RGB", "3D4018");;\
Log 1, "brightness - $brightness : $rgb";;\
Log 1, "hour - $hour";;\
\
if ($brightness < 130 ){\
if($hour < 5)\
{\
fhem("set LedController2 hsv 13.02,100,7.04");;\
fhem("set LedController3 hsv 13.02,100,7.04");;\
}else {\
fhem("set LedController2 hsv 42.00,96.00,97.00");; \
fhem("set LedController3 hsv 42.00,96.00,97.00");;\
}\
}\
\
fhem("delete LedControllerBad_Off");;\
fhem("define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off");;\
}
Ist das so, dass du das Device ständig löscht und neu anlegst? Und dann direkt nach dem Anlegen den set-Befehl absetzt? Kann mir gut vorstellen, dass das nicht klappt, da direkt nach dem Anlegen erstmal 2 oder 3 Befehle hin- und her gehen, mit denen die Config usw. eingelesen wird. Warum das aber in "empty answer received" resultieren sollte, ist mir unklar.
@vbs
Nein ich lösche nur das Off-Notify und lege es neu an: LedControllerBad_Off, damit das Licht nach 10 min wieder ausgeht. Ich wollte nicht das off vom Motion Detect benutzen.
Ich sehe aber in meinem Log-File öfter ein:
/opt/fhem/log/fhem-2018-05.log:2018.05.09 09:44:38 2: LedController2: error http://192.168.0.25/info?: empty answer received retrieving info
/opt/fhem/log/fhem-2018-05.log:2018.05.09 09:45:04 2: LedController2: error http://192.168.0.25/config?: empty answer received retrieving config
/opt/fhem/log/fhem-2018-05.log:2018.05.09 09:45:08 2: LedController2: EspLedController_ParseBoolResult error: http://192.168.0.25/config?: empty answer received
/opt/fhem/log/fhem-2018-05.log:2018.05.09 09:45:09 2: LedController2: error http://192.168.0.25/config?: empty answer received retrieving config
Achso ok, verstehe. Also ich hab das durchaus sporadisch auch schon erlebt, aber konnte mir darauf bisher noch keinen Reim machen. Ein Wireshark/tcpdump von dem Fall wäre mal interessant, ob es wirklich so passiert wie es sich anhört und der Controller eine komplett leere HTTP-Antwort liefert. Ich kann es bei mir aber nicht gezielt reproduzieren.
Hallo, mal eine Frage die indirekt mit dem Thema was zu tun hat.
Was benutzt ihr eigentlich alles zur Steuerung/zum manuell schalten ausser Tablet und Smartphone?
Gibt es irgend eine rgb wlan Fernbedienung,...?
Hätte gerne für meine Terassenbeleuchtung einen zusätzlichen Taster, Schalter, Touchpad,...
Einfachste Variante zum rein ein und ausschalten ohne viel Basteln wäre wohl ein Amazon Dash button.
Gibt es sonst irgendetwas, um relativ simpel meinen in FHEM eingebundenen ESP RGBWW Controller anzusteuern, vielleicht sogar mit Touchpad,...?
Danke,
crispyduck
Hi,
Du könntest diese Fernbedienung benutzen:
http://s.aliexpress.com/zayIFBz2
Die kann man über a-culfw oder Signalduino als 4 IT Devices hören und dann auf den Controller umsetzen.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Danke, okay, von denen habe ich eh ein paar daheim.
Würde aber gerne irgendetwas einsetzen was direkt wlan kann.
Klar, könnte auch einen ESP her nehmen, paar Taster dran,... ist vielleicht mal ein Projekt für den Winter, eine Fernbedienung mit ESP8266 für alles mögliche im Haus.
Suche jetzt aber ersteinmal was einfaches ohne viel Basteln was ich neben die Balkontüre an die Wand kleben kann um zumindest ein und aus zu schalten oder vielleicht noch mehr.
Wollte mir dafür jetzt schon einen Dash button bestellen, aber dachte jetzt ich frage mal wie andere das so umgesetzt haben.
Lg,
crispyduck
@vbs
Es ist kompliziert. Es hat auf alle Fälle mit meinem notify-Code zu tun. Ich habe ihn ändern müssen zu:
fhem 'set LedController3 rgb F7B00A; set LedController2 rgb F7B00A';
Damit werden beide Kommandos ausgeführt. Mein alter Code mit:
fhem("set LedController2 rgb $rgb ");;;; \
fhem("set LedController3 rgb $rgb ");;;;\
funktionierte nicht mehr. Es sah im tcp-Dump so aus, als ob der Befehl nicht richtig ausgeführt worden ist:
09:18:22.549733 IP fhem.fritz.box.38616 > ledcontroller3.fritz.box.http: Flags [S], seq 324373229, win 29200, options [mss 1460,sackOK,TS val 290342989 ecr 0,nop,wscale 7], length 0 E..<..@.@......&.......P.U........r.............NHM........
09:18:22.552686 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38616: Flags [S.], seq 38711, ack 324373230, win 5560, options [mss 1390], length 0 E..,.y....9........&.P.....7.U..`...4u.....n..
09:18:22.552889 IP fhem.fritz.box.38616 > ledcontroller3.fritz.box.http: Flags [.], ack 1, win 29200, length 0 E..(..@.@......&.......P.U.....8P.r.....
09:18:23.856948 IP fhem.fritz.box.38616 > ledcontroller3.fritz.box.http: Flags [P.], seq 1:247, ack 1, win 29200, length 246: HTTP: POST /color HTTP/1.0 E.....@.@......&.......P.U.....8P.r.....POST /color HTTP/1.0
Host: 192.168.0.21
Accept-Encoding: gzip,deflate
User-Agent: fhem
Accept: application/json
Content-Type: application/json
Content-Length: 75
{"d":"1","t":"1000","hsv":{"h":42,"s":96,"v":97},"cmd":"fade","q":"single"}
09:18:23.863191 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38616: Flags [F.], seq 1, ack 247, win 5314, length 0 E..(.z....9........&.P.....8.U..P...K.........
09:18:23.864789 IP fhem.fritz.box.38616 > ledcontroller3.fritz.box.http: Flags [F.], seq 247, ack 2, win 29200, length 0 E..(..@.@......&.......P.U.....9P.r.....
09:18:23.869308 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38616: Flags [.], ack 248, win 5313, length 0 E..(.{....9........&.P.....9.U..P...K.........
Na. Egal. Jetzt geht es wieder und ich muss nicht im dunkeln tappen.
Gruss Thomas
Ok, danke dir! Was ist denn der maßgebliche Unterschied bei dem notify-Code? Die Reihenfolge der Geräte? Der Rest sieht ja erstmal inhaltlich gleich bzw. hinreichend ähnlich aus.
Der HTTP-Request sieht jetzt erstmal ok aus, bin ich der Meinung. Ist der Dump komplett? Also gab es daraufhin vom Controller überhaupt keine Antwort (abgesehen von ACK-Paketen)?
Richtig, da kam nichts weiter. Ein Vollständiger Aufruf, z.B. über curl sah so aus:
09:19:46.181168 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [S], seq 2307447724, win 29200, options [mss 1460,sackOK,TS val 290351353 ecr 0,nop,wscale 7], length 0 E..<.U@.@......&.....^.P..........r.............Nh.........
09:19:46.183573 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38750: Flags [S.], seq 42171, ack 2307447725, win 5560, options [mss 1390], length 0 E..,.}....9........&.P.^........`..._x.....n..
09:19:46.183859 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [.], ack 1, win 29200, length 0 E..(.V@.@......&.....^.P........P.r.....
09:19:46.240583 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [P.], seq 1:247, ack 1, win 29200, length 246: HTTP: POST /color HTTP/1.0 E....W@.@......&.....^.P........P.r.....POST /color HTTP/1.0
Host: 192.168.0.21
Accept-Encoding: gzip,deflate
User-Agent: fhem
Accept: application/json
Content-Type: application/son
Content-Length: 75
{"q":"single","cmd":"fade","d":"1","t":"1000","hsv":{"v":97,"h":42,"s":96}}
09:19:46.265940 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38750: Flags [.], seq 1:170, ack 247, win 5314, length 169: HTTP: HTTP/1.1 200 OK E....~....9........&.P.^........P...FP..HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 16
Connection: keep-alive
Server: HttpServer/Sming
{"success":true}
09:19:46.266110 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [.], ack 170, win 30016, length 0 E..(.X@.@......&.....^.P.......eP.u@....
09:19:47.576295 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38750: Flags [F.], seq 170, ack 247, win 5314, length 0 E..(......9........&.P.^...e....P...vE........
09:19:47.620395 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [.], ack 171, win 30016, length 0 E..(.Y@.@......&.....^.P.......fP.u@....
09:19:47.624752 IP fhem.fritz.box.38750 > ledcontroller3.fritz.box.http: Flags [F.], seq 247, ack 171, win 30016, length 0 E..(.Z@.@......&.....^.P.......fP.u@....
09:19:47.629024 IP ledcontroller3.fritz.box.http > fhem.fritz.box.38750: Flags [.], ack 248, win 5313, length 0 E..(......9........&.P.^...f....P...vE........
Ich hatte vorher im notify-Code mehrere Aufrufe in der Form:
fhem("set LedController2 rgb F7B00A");
fhem("set LedController3 rgb F7B00A");
Da ist nach einem Fhem-Update vor ca. 3 Wochen dann nichts mehr passiert. Bis dahin funktionierte der Aufruf. Zum Vergleich nochmal der alte Code:
define Bewegungsmelder_Bad_On notify HM_Bad_Motion:motion:.on.* { \
if($hour < 5)\
{\
fhem("set LedController2 rgb 130400");;;;\
fhem("set LedController3 rgb 130400");;;;\
}else {\
fhem("set LedController2 rgb F7B00A");;;; \
fhem("set LedController3 rgb F7B00A");;;;\
}\
\
fhem("delete LedControllerBad_Off");;;;\
fhem("define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off")\
}
Wenn ich jetzt im notify mehrere einzelne fhem-Commands absetze, passiert eben der Fehler. Finde ich irgendwie komisch. Ich bekomme es aber nicht so einfach in eine Zeile. :-(
Und jetzt geht auch auch schon wieder nicht mehr. Ich bin am verzweifeln:
define Bewegungsmelder_Bad_On notify HM_Bad_Motion:on.* { \
if($hour < 5) {\
if (defined("LedControllerBad_Off")) {\
fhem 'set LedController3 rgb 130400;; set LedController2 rgb 130400;; delete LedControllerBad_Off;; define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off ';;\
} else {\
fhem 'set LedController3 rgb 130400;; set LedController2 rgb 130400;; define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off ';;\
}\
} else {\
if (defined("LedControllerBad_Off")) {\
fhem 'set LedController3 rgb F7B00A;; set LedController2 rgb F7B00A;; delete LedControllerBad_Off;; define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off ';;\
} else {\
fhem 'set LedController3 rgb F7B00A;; set LedController2 rgb F7B00A;; define LedControllerBad_Off at +00:10:00 set LedController2 off;;;; set LedController3 off ';;\
}\
}\
}
Es wird wieder nur ein Request rausgeschickt, aber keine Response bekommen. Führe ich nur einen Befehl aus, klappt es.
Update: Es scheint mit dem at-Timer zusammen zuhängen. Ich habe den erst einmal gelöscht und mich an den OFF-Notify vom Bewegungsmelder gehangen.
Schöner wäre es aber mit einem on-for-timer. So geht es auch:
fhem 'set LedController2,LedController3 rgb F7B00A';
fhem 'set LedController2,LedController3 on-for-timer 300';
Zitat von: crispyduck am 10 Mai 2018, 09:10:01Wollte mir dafür jetzt schon einen Dash button bestellen, aber dachte jetzt ich frage mal wie andere das so umgesetzt haben.
WLAN ist suboptimal, weil zu energieintensiv. Schau, welches System du bereits verbaut hast (HM, IT o.ä.) oder welches dir sympathisch erscheint und besorg dir dafür Wandtaster und/oder Fernbedienungen. Ich bin dabei, auf EnOcean umzustellen, braucht nie wieder Batterien!
WLAN und (Deep-)Sleep spart zwar auch Strom, aber dann hast du keine prompte Rückmeldung, weil beim Schalten erst das Netz aufgebaut wird.
Interesseant wäre ne FB, die im Liegen "sleept" und beim Anheben schon Netz aufbaut. Die würde auch quasi sofort reagieren.
Hi,
Danke, ich habe allerdings keine anderen Funk Komponenten. Das meiste ist bei mir via LAN oder Modbus RTU angebunden, oder eben direkt an den GPIO Ports der Raspi.
Habe es übrigens auch schon gelöst, habe einen ESP8266 den ich ohnehin rum liegen hatte in das Gehäuse der ursprünglichen Fernbedienung meiner RGB Leuchte verbaut.
Anfangs habe ich die Schaltung noch komplett stromlos geschalten Energie zu sparen (Selbsthaltung mit P MOSFET), habe dann aber auf deep sleep gewechselt da es so nur etwas länger als 500ms dauert bis Verbindungsaufbau und Schaltbefehl durch sind.
Um alle 10 Tasten der Fernbedienung nutzen zu können habe ich diese teilweise mittels Dioden auf die GPIO ports geschalten, so werden z.B. bei Taste 8 und 9 zwei GPIO ports auf high geschalten.
Für meine Anwendung vollkommen ausreichend. Meine Leuchte kann ich damit ein und ausschalten, dimmen und durch die Farben schalten.
Mit den restlichen Rasten wird dann noch die Gartenbewässerung angesteuert.
Mit 2 AA Batterien die in das Gehäuse passen, sollte das eigentlich mindestens ein Jahr laufen.
Lg
Crispyduck
Zitat von: crispyduck am 16 August 2018, 06:26:20Mit 2 AA Batterien die in das Gehäuse passen, sollte das eigentlich mindestens ein Jahr laufen.
Halt uns dazu mal auf dem Laufenden!
Hi,
kurzes Anliegen zum Modul,
Ich habe versucht mir ein "presence" UserReading anzulegen mit present/absent, aber da der Verbindungsstatus nur im Reading state steckt scheint das nicht zu funktionieren.
attr ESP_RGBWW_2 userReadings presence {ReadingsVal("$NAME","state","") eq "disconnected" ? "absent" : "present"}
wäre es daher eventuell möglich das "presence" reading direkt im Modul mit zu integrieren?
Oder mache ich mit dem UserReading etwas falsch?
in anderen Geräten (nicht auf "state") funktioniert es.
Danke & Grüße
Frank
Hi Frank, kannst du genauer sagen, was nicht funktioniert? Reading wird nicht geupdatet? Und ein List vom Device bitte.
Ja, Das Userreading wird nicht aktualisiert, es ging einmal auf "present" und ist seither stumm.
List:
Internals:
DEF 192.168.12.17
DeviceName 192.168.12.17:9090
FUUID 5edd50b4-f33f-b480-b0bc-6c0243e04cd56c2e
IP 192.168.12.17
LAST_RECV 1595934828.57405
NAME ESP_RGBWW_2
NEXT_OPEN 1595934895
NR 224
NTFY_ORDER 50-ESP_RGBWW_2
PARTIAL
PORT 9090
STATE disconnected
TYPE EspLedController
OLDREADINGS:
READINGS:
2020-07-26 22:44:25 colorMode hsv
2020-07-28 11:22:37 config-color-brightness-blue 100
2020-07-28 11:22:37 config-color-brightness-cw 100
2020-07-28 11:22:37 config-color-brightness-green 100
2020-07-28 11:22:37 config-color-brightness-red 100
2020-07-28 11:22:37 config-color-brightness-ww 100
2020-07-28 11:22:37 config-color-colortemp-cw 6000
2020-07-28 11:22:37 config-color-colortemp-ww 2700
2020-07-28 11:22:37 config-color-hsv-blue 0
2020-07-28 11:22:37 config-color-hsv-cyan 0
2020-07-28 11:22:37 config-color-hsv-green 0
2020-07-28 11:22:37 config-color-hsv-magenta 0
2020-07-28 11:22:37 config-color-hsv-model 0
2020-07-28 11:22:37 config-color-hsv-red 0
2020-07-28 11:22:37 config-color-hsv-yellow 0
2020-07-28 11:22:37 config-color-outputmode 3
2020-07-28 11:22:37 config-color-startup_color last
2020-07-28 11:22:37 config-events-color_interval_ms 500
2020-07-28 11:22:37 config-events-color_mininterval_ms 500
2020-07-28 11:22:37 config-events-server_enabled 1
2020-07-28 11:22:37 config-events-transfin_interval_ms 1000
2020-07-28 11:22:37 config-general-device_name ESP_RGBWW_2
2020-07-28 11:22:37 config-general-pin_config 13,12,14,5,4
2020-07-28 11:22:37 config-network-ap-password rgbwwctrl
2020-07-28 11:22:37 config-network-ap-secured 0
2020-07-28 11:22:37 config-network-ap-ssid RGBWW10982360
2020-07-28 11:22:37 config-network-connection-dhcp 1
2020-07-28 11:22:37 config-network-connection-gateway 0.0.0.0
2020-07-28 11:22:37 config-network-connection-ip 0.0.0.0
2020-07-28 11:22:37 config-network-connection-netmask 0.0.0.0
2020-07-28 11:22:37 config-network-mqtt-enabled 0
2020-07-28 11:22:37 config-network-mqtt-password
2020-07-28 11:22:37 config-network-mqtt-port 1883
2020-07-28 11:22:37 config-network-mqtt-server mqtt.local
2020-07-28 11:22:37 config-network-mqtt-topic_base home/
2020-07-28 11:22:37 config-network-mqtt-username
2020-07-28 11:22:37 config-ota-url http://rgbww.dronezone.de/release/version.json
2020-07-28 11:22:37 config-security-api_secured 0
2020-07-28 11:22:37 config-sync-clock_master_enabled 0
2020-07-28 11:22:37 config-sync-clock_master_interval 30
2020-07-28 11:22:37 config-sync-clock_slave_enabled 0
2020-07-28 11:22:37 config-sync-clock_slave_topic home/led1/clock
2020-07-28 11:22:37 config-sync-cmd_master_enabled 0
2020-07-28 11:22:37 config-sync-cmd_slave_enabled 0
2020-07-28 11:22:37 config-sync-cmd_slave_topic home/led1/command
2020-07-28 11:22:37 config-sync-color_master_enabled 0
2020-07-28 11:22:37 config-sync-color_master_interval_ms 0
2020-07-28 11:22:37 config-sync-color_slave_enabled 0
2020-07-28 11:22:37 config-sync-color_slave_topic home/led1/color
2020-07-28 11:22:37 ct 0
2020-07-28 11:22:37 hsv 271.96,100,0
2020-07-28 11:22:37 hue 271.96
2020-07-28 11:22:37 info-connection-dhcp 1
2020-07-28 11:22:37 info-connection-gateway 192.168.12.254
2020-07-28 11:22:37 info-connection-ip_address 192.168.12.178
2020-07-28 11:22:37 info-connection-mac 840d8ea793d8
2020-07-28 11:22:37 info-connection-netmask 255.255.255.0
2020-07-28 11:22:37 info-connection-ssid W12_IoT
2020-07-28 11:22:37 info-current_rom_slot 1
2020-07-28 11:22:37 info-deviceid 10982360
2020-07-28 11:22:37 info-event_num_clients 1
2020-07-28 11:22:37 info-firmware vbs35
2020-07-28 11:22:37 info-heap_free 22032
2020-07-28 11:22:37 info-sming_version 3.5.1
2020-07-28 11:22:37 info-uptime 0
2020-07-28 11:22:37 info-webapp_version 0.3.3-shojo7
2020-07-28 11:22:37 pct 0
2020-07-28 11:22:37 presence present
2020-07-28 11:22:37 raw_blue 0
2020-07-28 11:22:37 raw_cw 0
2020-07-28 11:22:37 raw_green 0
2020-07-28 11:22:37 raw_red 0
2020-07-28 11:22:37 raw_ww 0
2020-07-28 11:22:37 rgb 000000
2020-07-28 11:22:37 sat 100
2020-07-28 13:13:55 state disconnected
2020-07-28 11:22:37 stateLight off
2020-07-26 22:42:51 tranisitionFinished Rainbow,requeued
2020-07-28 11:22:37 val 0
helper:
isBusy 0
oldVal 100
cmdQueue:
lastCall:
NAME
addr http://192.168.12.17:80
auth 0
displayurl http://192.168.12.17/config?
errno 113
header User-Agent: fhem
Accept: application/json
Content-Type: application/json
host 192.168.12.17
loglevel 4
method GET
path /config?
protocol http
redirects 0
timeout 30
url http://192.168.12.17/config?
hash:
sslargs:
Attributes:
DbLogExclude .*
group Hardware
icon light_led_stripe_rgb
room ESP_RGBWW
stateFormat R=raw_red | G=raw_green | B=raw_blue | CW=raw_cw | WW=raw_ww
userReadings presence {ReadingsVal($NAME,"state","") eq "disconnected" ? "absent" : "present"}
userattr room_map structexclude
verbose 0
webCmd rgb:on:off:pct
Sorry, kriege es auch nicht hin mit "state".
Sowas hier funktioniert:
Zitatpresence {ReadingsVal("$NAME","pct","") > 50 ? "absent" : "present"}
Keine Ahnung, was bei state so besonders ist.
state wirft wohl keine Events aus, triggert damit das UserReading nicht. (Vermutung)
Daher der Gedanke ob es nicht für das Modul generell sinnvoll wäre "presence" anzubieten. :-)
In meinem Fall erzeugt state ein Event. Aber es hängt ja nicht an state, da das UserReading auf jegliche Änderungen reagiert.
presence extra erzeugen würde ich ungern. Sehe da ehrlich gesagt keinen Mehrwert, die gleiche Information nochmal mit anderen Namen händisch zu pflegen. Ist das irgendein "Standard", dass es ein Reading "presence" geben sollte? Die existierenden state/STATE werden allesamt von DevIo erzeugt und verwaltet. Würde eher fragen, ob es nicht sinnvoll wäre, den UserReading-Mechanismus zu fixen (oder zu verstehen, was wir falsch machen). ;)
Oder wer auch immer "presence" benötigt, könnte ja auch "state" einlesen, was wegen DevIo mMn so eine Art DIN-Norm ist.
Ich kenne eher "presence" als Standart für die Erreichbarkeit. :-)
Dafür habe ich eine "Sammel-Benachrichtigung" sobald bei einem beliebigen Gerät das presence auf absent geht bekomme ich eine Benachrichtigung mit Geräte Namen.
Aber gut, wenn das UserReading funktionieren würde wäre das auch OK.
momentan habe ich ein extra LAN-Ping Gerät angelegt um den Controller zu überwachen.
Ja tut mir leid, würde ich nicht so gerne einbauen :-\
Mache momentan nicht viel im FHEM-Umfeld, aber würde mich überzeugen lassen mit weiteren Quellen, dass "presence" ein Reading ist, das jedes brave Modul bereit stellen sollte.
so auf Anhieb die Module die ich kenne:
- ESPEasy
- Presence
Dann lebe ich mal mit dem extra Gerät zur Überwachung. :-)
Hi,
ich habe seit gestern folgenden Fehler im Log und Module reagieren, wenn überhaupt nur verzögert.
ZitatLED_Kueche: EspLedController_ParseBoolResult error: http://192.168.136.61/color: empty answer received
Kann manchmal passieren. Evtl. hängt das mit zu schlechtem Wlan Empfang zusammen.
Moinsen!
Nach heutigem FHEM Update aktualisieren die Readings nicht mehr.
Damit funktioniert meine Steuerung nicht mehr da ich "stateLight" auswerte.
am RGBWW Modul hat sich nichts geändert, da sehe ich dass es die Version von Juni 2020 ist.
Ein Restore holt mir folgende Dateien zurück:
restore ./CHANGED
restore ./FHEM/01_FHEMWEB.pm
restore ./FHEM/10_CUL_HM.pm
restore ./FHEM/32_SYSSTAT.pm
restore ./FHEM/49_IPCAM.pm
restore ./FHEM/59_Twilight.pm
restore ./FHEM/73_AutoShuttersControl.pm
restore ./FHEM/90_at.pm
restore ./FHEM/98_DOIF.pm
restore ./FHEM/98_HTTPMOD.pm
restore ./FHEM/98_Modbus.pm
restore ./FHEM/98_ModbusAttr.pm
restore ./FHEM/98_SVG.pm
restore ./FHEM/DevIo.pm
restore ./FHEM/HttpUtils.pm
restore ./FHEM/controls_fhem.txt
skipping ./fhem.cfg
restore ./lib/FHEM/Automation/ShuttersControl/Helper.pm
restore ./lib/FHEM/Automation/ShuttersControl/Shutters.pm
restore ./lib/FHEM/HTTPMOD/Utils.pm
restore ./lib/FHEM/Modbus/TestUtils.pm
skipping ./log/fhem.save
restore finished
dannach läuft alles wieder.
Moin!
Hm, ja ist blöd. Hab mein FHEM lange nicht mehr upgedatet und scheue etwas, das jetzt bei mir zu machen, um das nachzustellen.
Also von den Modulen, die sich bei dir geändert haben, kommen *eigentlich* nur DevIo und HttpUtils in Frage. Vlt. magst du die beiden mal einzeln updaten/downdaten und gucken, ob man das eingrenzen kann?
Und auch ein verbose-Log von dem Fehlerfall wäre mal interessant.
Wenn wir damit nicht weiter kommen, dann schauen wir mal...
Zitat von: vbs am 17 März 2021, 17:12:21Vlt. magst du die beiden mal einzeln updaten/downdaten und gucken, ob man das eingrenzen kann?
Und auch ein verbose-Log von dem Fehlerfall wäre mal interessant.
Wenn wir damit nicht weiter kommen, dann schauen wir mal...
Klar, gerne. Mach ich morgen wenn ich wieder am Computer bin.
Hab mich zwischenzeitlich doch mal an ein Update bei mir gewagt... Klappt offenbar alles noch. Warte noch auf Probleme ::)
Aber das Problem hier dem ESP konnte ich so erstmal nicht nachstellen. Reading inkl. stateLight funktionieren.
EDIT: muss alles nochmal testen.
Bei RAW Kommandos wird das stateLight nicht gesetzt. Alle Teste heute umsonst...
EDIT 2:
So, ich kann auch keinen Fehler mehr nachstellen. *grrrr*
Ich erzähl mal was passiert ist.
am 15ten nen Update gemacht. die kurzen Tests haben nichts auffälliges gezeigt. den RGBWW hab ich natürlich nicht getestet...
Nachts konnte der Controller nicht abgeschalten werden, also vormittags dann die Ursache gesucht.
Dabei hab ich aber mit den RAW Kommandos getestet und die setzen den stateLight nicht auf "on"
Es hatte also in der Nacht andere Gründe die ich jetzt nicht mehr nachvollziehen kann.
Update heute zeigt, funktionioert wie vorher.
Ich würde das aber als Bug ansehen dass der stateLight nicht bei RAW Befehlen gesetzt wird.
kannst Du das evtl mal anschauen und evtl mit einbauen?
Der betreffende Stripe ist am Kopfteil vom Bett.
Ein Lichttaster lässt einen RGB fade starten und schaltet aus.
Da das funktioniert war mir das mit dem stateLight nie vorher aufgefallen.
Die anderen Stripes steuere ich direkt ohne ein Toggle DOIF.
Ok, hab eingebaut, dass stateLight auch im Raw-Modus geupdatet wird. War damals möglichweise sogar Absicht, das nicht zu tun, aber heute finde ich es auch sinnvoll.
Zitat von: vbs am 18 März 2021, 23:07:07
Ok, hab eingebaut, dass stateLight auch im Raw-Modus geupdatet wird. War damals möglichweise sogar Absicht, das nicht zu tun, aber heute finde ich es auch sinnvoll.
Danke! :-)
Empfinde ich auch richtig so. Wobei das damals bestimmt auch seine Gründe hatte.
Gerade getestet, so 100%ig passt es noch nicht.
RAW Kommandos: stateLight wird gesetzt, löst allerdings kein Event aus. wird erst nach Browser Refresh angezeigt.
HSV Kommandos:
Bei Kommando set ESP_RGBWW_1 hsv 0,0,40 wird stateLight mit Event auf "off" gesetzt.
Bei Kommando set ESP_RGBWW_1 hsv 240,100,40 wird stateLight mit Event auf "on" gesetzt.
???
Mein "Fehler" ist damit aber behoben. Danke!
Also du sagst bei HSV löst stateLight ein Event aus, aber Raw nicht? Hm könnte ich mir nicht erklären. Ob ein Event gefeuert wird, oder nicht, hängt soweit ich weiß nur von den event-on-*-Attributen ab.
Kannst ja mal ein list vom Device posten, aber spontan würde ich sagen, dass das nicht am Modul selbst liegen kann.
event-on-change steht auf .*
Aber ich teste das nochmal. vielleicht lag es am Kaffeemangel. ;-)
Was hältst Du davon:
Bei Kommando set ESP_RGBWW_1 hsv 0,0,40 wird stateLight mit Event auf "off" gesetzt.
Bei Kommando set ESP_RGBWW_1 hsv 240,100,40 wird stateLight mit Event auf "on" gesetzt.
Zitat von: Frank_Huber am 19 März 2021, 11:17:14
Bei Kommando set ESP_RGBWW_1 hsv 0,0,40 wird stateLight mit Event auf "off" gesetzt.
Das fände ich falsch. Versuche das mal zu reproduzieren.
Ok, danke. Hab es verstanden. Das Raw-stateLight hat auch nicht korrekt funktioniert... Sollte nun behoben sein.