Sunricher SR 2820 Wifi

Begonnen von mike1992, 23 Februar 2015, 17:06:33

Vorheriges Thema - Nächstes Thema

szerb

Die wichtigste Sache ist, den Controller über das Web-Interface des Controller ins eigene W-Lan zu bringen und nicht mit der Mobil-App.
Deine Vermutung mit 0x01 und 0x02 klingt auf jeden Fall plausibel.
Weil den Sniff habe ich nach einem Reset des Controllers in dem von ihm aufgespannten Netz gemacht.

Markus

peterk_de

#151
So ... ich komme gerade mit einem Lead-Dynamic SDCW 5m RGB-WW Streifen frisch vom Baumarkt :-D Mir hat der Spaß so gut gefallen, ich konnte nicht widerstehen, zumal die Qualität von den Teilen auch 1a ist - kein Flimmern, FHEM-Support reibungslos .... ach was red ich mich raus, es war ein Impulskauf :-D

Jedenfalls kann ich nun bestätigen, dass im WLAN der Lampe aus der Zieladresse 0x0200 eine 0x0100 wird. Aber 0x0200 klappt auch hier prima - allerdings nur zum Ausschalten, zum einschalten schon nichtmehr. Das erklärt das Verhalten der Lampe bei Szerb. 0xFF geht auch nicht.

Sehr interessant auch: Die Absenderadresse muss in dem WLAN der Lampe stimmen (Bytes 1-3)! Ändert man nur eines der Bytes gegenüber welchen, die ich mitgesnifft habe, egal welches, nimmt die Lampe den Befehl nicht mehr an. Der Trick mit 00 00 00  funzt hier nicht!

Der Algorithmus, nach dem sich diese 3 Bytes valide zusammensetzen lassen, ist mir schleierhaft - da ist aber nur irgendne Checksumme drin, ich kann schließlich über mein Notebook (andere MAC+IP als das Handy) dessen kopierte Befehle nutzen. Man müsste das aber verstehen, um das lampeneigene WLAN zu supporten. Es wird aber niemand, der das mit FHEM zusammenknüppern will, tun, von daher würde ich sagen, ist das egal, oder!?

Von daher, Fazit: So lassen wie es ist, also mit 0x0200 und Absenderadresse 0x000000.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

turi

Ich bin gerade dabei, mit der aktuellen Version zu testen, aber momentan geht außer einschalten nichts (Standard-RGBW-Controller Sunricher). Ob das an den 3x 00 liegt?

Ich hatte noch bei meinem Händler bzgl. den LEAD-Teilen angefragt, aber keine plausible Antwort bekommen. Ich gehe davon aus, dass die auch da gefertigt werden, aber wahrscheinlich nur im Kundenauftrag, denn das Web-Interface ist anders als bei mir. Inhaltlich ist es sehr ähnlich, optisch aber anders und auch mit erweiterten Funktionen. Also wird es kleine Unterschiede geben, wie wir ja schon festgestellt haben.

Ich teste mal weiter ...

peterk_de

Ich hab ihn jetzt eben mal in FHEM reingenommen und er geht teilweise. An Klappt, Farbe setzen klappt manchmal, dimmen irgendwie gar nicht - insgesamt alles irgendwie noch nicht richtig. Ich gehe der Sache mal auf den Grund.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

herrmannj

Ist das der mit 0-ff oder der mit 0-80

peterk_de

FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

turi

Das ist der bis 0x7F bzw. 80, aber ich habe gerade auch schon mal die 00 in die vom Sniff geändert, brachte auch nichts :-(
so sieht es aus, müsste passen:

### LK35-Controller
define LK35_1 WifiLight RGBW Sunricher:172.xx.xx.xx
attr LK35_1 colorCast 0, -20, -20, -25, 0, -10
attr LK35_1 room LED-Studien
attr LK35_1 whitePoint 1, 1, 1
attr LK35_1 devStateIcon {Color_devStateIcon(ReadingsVal($name,"RGB","000000"))}
define FileLog_LK35_1 FileLog ./log/LK35_1.log LK35_1

turi

Habe nochmal ein Update gemacht und es kam auch nochmal eine neue Version ... zumindest kann ich jetzt die Farben wieder bedienen, ein/aus geht nicht.

Da suche ich mal weiter. Unabhängig davon, könntest Du noch einzelne Farben steuerbar machen, also setR, setG, setB und vor allem setW. Dann kann man auch slider einbauen. Würde vielleicht teilweise jetzt auch gehen, es würde dann halt immer RGB gesendet. Aber speziell für Weiß wäre es gut, das einzeln steuern zu können.

peterk_de

turi ... ich glaub da ist das Konzept des Moduls/FHEMs ein anderes :) R, G, B einzeln zu steuern macht vielleicht bei DIESEN Lampen sinn, aber bei anderen möglicherweise nicht ... was aber pauschal bei allen Sinnvoll wäre, ist ein separater Regler für W bei RGBW-Leuchtmitteln ... bei meinen neuen Strip haben die sehr viel mehr Wumms als die R,G und B-Chips und sind da sicher schwer mit einzugliedern!?
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

turi

Na mit einem einzelnen Weiß bin ich schon sehr zufrieden. Es macht auch kaum Sinn zu versuchen, dass mit in das HSV einzubauen. Normal hat man bei RGB eine Farbe und kann dann mit weiß noch Pastelltöne erzeugen. Wenn man aber z.B. eine indirekte Beleuchtung hat, wird man i.d.R. nur über weiß die Helligkeit einzustellen.

Hängt eben immer vom Einsatz und der Art der Bedienung ab. Aber es gibt noch einen Einsatzfall, wor man die Regler schon einzeln nehmen würde, wenn man nämlich statt RGB die einzelnen Ausgänge als Zonen betrachtet und so verschiedene Bereiche im Raum mit weißen Streifen regeln kann. Ich habe immer mal solche Anforderungen und ist halt billliger, als 4 solcher Controller.

peterk_de

Jörg, langsam glaube ich zu verstehen, warum sich das RGBW-Teil völlig merkwürdig verhält:

- Lampe ist aus, setzen einer beliebigen Farbe wo alle Werte > 0 sind - klappt:

2016.01.09 20:37:00.778 5: stube.rgbstrip prepare start hsv transition (is actual) hsv 60, 0, 0, 1452368220.77813
2016.01.09 20:37:00.779 4: stube.rgbstrip current HSV 60, 0, 0
2016.01.09 20:37:00.779 3: stube.rgbstrip set HSV 214, 98, 100 with ramp: 0, flags:
2016.01.09 20:37:00.780 4: stube.rgbstrip hsv transition without ramp routed to direct settings, hsv 214, 98, 100
2016.01.09 20:37:00.781 4: stube.rgbstrip high level cmd queue add hsv/ctrl 214, 98, 100, ctrl , targetTime 1452368220.77813, qlen 1
2016.01.09 20:37:00.781 5: stube.rgbstrip high level cmd queue exec dropper delay: -0.00357198715209961
2016.01.09 20:37:00.782 4: stube.rgbstrip high level cmd queue exec hsv 214, 98, 100, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.09 20:37:00.783 4: stube.rgbstrip RGBW Sunricher set h:214, s:98, v:100
2016.01.09 20:37:00.898 5: stube.rgbstrip low level cmd queue add 5500000002ff08180526aaaa5500000002ff08197193aaaa5500000002ff0820ff28aaaa, qlen 1
2016.01.09 20:37:00.899 5: stube.rgbstrip low level cmd queue qlen 1, send 5500000002ff08180526aaaa5500000002ff08197193aaaa5500000002ff0820ff28aaaa
2016.01.09 20:37:00.900 5: stube.rgbstrip low level cmd queue add 00, qlen 2
2016.01.09 20:37:00.901 4: stube.rgbstrip high level cmd queue ask next 1452368221.0013
2016.01.09 20:37:00.905 5: stube.rgbstrip | stube.rgbstrip unlock queue 0


Nun schalten wir die Lampe aus - das klappt nicht und auch die Kommandos stimmen nicht (es müssten ja alle 3 Farben gesendet werden, es wird aber nur eine abgeschickt - rot)! Was da falsch ist, konnte ich im Source leider nicht erblicken....

2016.01.09 20:39:15.918 3: stube.rgbstrip RGB SUNRICHERA set off 0
2016.01.09 20:39:15.920 3: stube.rgbstrip RGBW LD382 dim 0 0
2016.01.09 20:39:15.921 5: stube.rgbstrip prepare start hsv transition (is actual) hsv 214, 98, 100, 1452368355.92097
2016.01.09 20:39:15.921 4: stube.rgbstrip current HSV 214, 98, 100
2016.01.09 20:39:15.922 3: stube.rgbstrip set HSV 214, 98, 0 with ramp: 0, flags:
2016.01.09 20:39:15.922 4: stube.rgbstrip hsv transition without ramp routed to direct settings, hsv 214, 98, 0
2016.01.09 20:39:15.923 4: stube.rgbstrip high level cmd queue add hsv/ctrl 214, 98, 0, ctrl , targetTime 1452368355.92097, qlen 1
2016.01.09 20:39:15.924 5: stube.rgbstrip high level cmd queue exec dropper delay: -0.00290703773498535
2016.01.09 20:39:15.924 4: stube.rgbstrip high level cmd queue exec hsv 214, 98, 0, delay 100, hl qlen 1, ll qlen 0, lock 0
2016.01.09 20:39:15.925 4: stube.rgbstrip RGBW Sunricher set h:214, s:98, v:0
2016.01.09 20:39:16.050 5: stube.rgbstrip low level cmd queue add 5500000002ff08180021aaaa, qlen 1
2016.01.09 20:39:16.051 5: stube.rgbstrip low level cmd queue qlen 1, send 5500000002ff08180021aaaa
2016.01.09 20:39:16.052 5: stube.rgbstrip low level cmd queue add 00, qlen 2
2016.01.09 20:39:16.053 4: stube.rgbstrip high level cmd queue ask next 1452368356.15312
2016.01.09 20:39:16.057 5: stube.rgbstrip | stube.rgbstrip unlock queue 0


... das Modul denkt nun aber natürlich, dass R,G und B Null sind - und du hast ja ordentlich herausgefiltert, dass die dann nochmal gesetzt werden. Ab diesem Zeitpunkt geht dann natürlich gar nix mehr richtig, bis man mal wieder alle Kanäle ziemlich hell stellt.

Vorschlag: Sicherheitshalber immer alle Farbkanäle senden. Auf die paar Bytes kommt es nicht an, und es erhöht die Zuverlässigkeit sicher immens.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

peterk_de

#161
Nachtrag: Das Define ist RGB SunricherA:192.168.178.13 (ich hab den weißen Kanal erstmal bewusst weggelassen, da der mich zusätzlich irritiert hat ... komischerweise behandelst du aber im Sunricher-RGB-Teil (ohne W) alle Kanäle gleich ... ich steh mal wieder aufm schlauch, wie das mit dem nur einen Farbe setzen statt 3 passieren kann ^^)

Nachtrag2: Whitepoint ist 1,1,1 und ColorCast 0,0,0,0,0,0 - der Einfachheit halber und weil es eh meilenweit daneben lag, ist dann meine nächste Baustelle das von den Werten her schön zu machen ;)

Nachtrag3: Gamma ist 1.0.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

herrmannj

Schau ich mir an. Danke. Dann fokusieren wir vorerst auf RGB und A

vg
joerg

peterk_de

Ich hab den Fehler + sie läuft jetzt prima ... ich bau dir nen Patchfile für RGB + RGBW (Typ A), nur noch 2 Minuten testen ;) ... du hattest die Falschen Kommandos für R, G,B und W (vermutlich aus dem anderen Sniff für den Wertebereich bis 80)- die funktionieren mit den Lead-Lampen auch, aber komischerweise nicht reproduzierbar unzuverlässig!)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

peterk_de

#164
So hier ... RGB und RGBW (Typ A) ausführlich getestet und für prima befunden. colorCast-Werte, Gamma und Whitepoint liefere ich später.

Edit: Noch ein Fehler gefunden, Zeile 1498 sollte noch raus, also die hier in WifiLight_RGBWSunricherA_setHSV(@):


$rr *= 0x80 / 0xFF;
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...