WiFILight - Tuya, DEV

[GhostInTheBottle]

Ich denke, jeder kann mit seiner Freizeit machen was er will. Zeitsparend ist es natürlich für den Anwender, die Hardware zu verwenden, die vom freien Automatisierungssystem seiner Wahl per se auch wirklich unterstützt wird. Die mögliche Auswahl ust nicht wirklich so Unterschiedlich vom Umfang her und den Anpassungsmöglichkeiten ist FHEM nach wie vor führend.
Was nun die zahlreichen WiFi Light Bulbs anbetrifft, die ein grosser Versandanbieter werbewirksam mir ALexa Unterstützng anbietet, sieht es aber offenbar traurig aus. Offenbar sind diese per reverse Engeneering nicht zu knacken oder kein Entwickler möchte in seiner Freizeit sich an solchen Projekten festbeissen, wenn/weil der Hersteller die APIs nicht offenlegt. Stattdessen existiert ein Projekt, wo mir vorgeschlagen wird, die Birne auseinanderzureissen und eine eine offne Firmware für den ESP Chip zu flashen, die dann von FHEM und anderen HA Systemen unterstützt wird. Habe ich das in vereinfachter Form jetzt so richtig dargestellt? Ich habe durchaus Achtung vor den Entwicklern, die sich das ausgedacht haben, aber das werde ich nicht tun.
Man möge mir meine Unwissenheit verzeihen, aber es existiert doch ein WIFILIGHT Modul, das eine überschaubare Anzahl von Lampen unterstützt, die allerdings kaum noch auf dem Markt zu bekommen sind. Weshalb lässt sich das nicht für neuere Produkte aufbohren (z.B: Tuya, und Smart Home)? Ist das wirklich so schwierig oder ist die Hardwarebasis bei WIFILIGHT eine andere? Existiert im FHEM Projekt eine Art Wunsch-/Machbarkeitsliste?

[herrmannj]

Ich verstehe nicht genau was Du meinst. WifiLight unterstützt ganz viele und wenn Du mal schaust haben sich auch einige andere Programme bei uns bedient. 

Was Du ansprichst meint vmtl ein konkretes Thema. Wenn der Hersteller die Protokolle nicht offenlegt ist es teilweise extrem viel Arbeit (ohne Erfolgsgarantie) notwendig um die Protokolle reverse zu engineeren. Auch wenn es aus reiner user Sicht bequem ist hier anzufragen nach dem Motto "he, ich hab grad xyz ganz preisgünstig gekauft, geht da was ?" - aus meiner Sicht als dev entscheide ich ob ich davon ausgehe ob die Systeme länger am Markt sind ("länger" ist relativ bei IOT ). Oder jemand anderes muss sich die Mühe machen das reverse zu engineeren. Dann muss ich immer noch entscheiden ob ich das aufnehme, teste, debugge, supporte. Der AUfwand ist immer noch enorm. Bedeutet idR das ich mir entsprechende Hardware anschaffen muss, testen - usw.

Derzeit werden viele Controller mit, mehr oder weniger dummer API, unterstützt. Mittlerweile kommen viele Bulbs mit intelligenten Schnittstellen dazu. WifiLight baue ich gerade darauf um (fit for future).

Nichts desto trotz, Hardware kommt und geht, und ich habe schon einige Projekt gesehen wo die Umsetzung noch lief da war die hardware schon nicht mehr zu bekommen.

Tuya, Smarthome, whatever. Wenn Du möchtest das es eingebaut wird, setz Dich hin, kauf Dir die Sachen (auf Risiko) und mach das reverse engineering. Dokumentiere das vernünftig und stell es ein. Dann sehen wir weiter. *

vg
joerg

* edit: sehen wir weiter bedeutet: ich muss sehen ob das Protokoll so ist das es sich vernünftig in das Modul integrieren lässt. Wenn es das ist dann nehme ich das auf.

[GhostInTheBottle]

Ich will es mal so sagen, die Technologie Licht über WiFi zu steuern, wird nicht jeden Tag neu erfunden und wenn man versteht, was der jeweilige Hersteller 'anders' gemacht hat OHNE das Fahrrad neu zu erfinden, dann ist man sicherlich auch in der Lage das WIFILIGHT modul anzupassen. Aus meiner Sicht muss man dann aber verstehen wie und weshalb die bisher unterstützte Hardware funktioniert (z.B. LD382/LD382A). Dazu muß man 1. eben diese Hardware besitzen 2. Traces erstellen 3 und mit den Traces der (noch) nicht unterstützten Hardware vergleichen. Mir ist schon klar, dass das noch nicht alles ist ...

Es ist jetzt aber nicht so, dass ich unter Leistungsdruck stehe und andere nerven will, auch wenn ich die erwähnte nicht unterstützte HW besitze. Inzwischen kann man ja auch A****n keine Täuschung mehr vorwerfen. Die deutschen Skills sind nun endlich da und verrichten ihre Arbeit. Mit IFTTT lassen sich dann auch Dinge zusammenbringen, die eigentlich nicht zusammen gehören (sollen). Damit ist dann noch ein weiterer 'Broker' im Spiel. Einerseits toll auf der anderen Seite beängstigend. Soweit ich das verstanden habe ist es ja ein Grundgedanke bon FHEM genau das zu vermeiden.

Am 15.12.2017 ist meine berufliche Tätigkeit in der IT und überhaupt beendet und ich denke schon, dass ich mich dann auch mehr hier einbringen kann.
Wenn Teile meines Postings als 'meckern' verstanden wurden, dann war das keinesfalls so beabsichtigt.

[herrmannj]

Falsch. Die Protokolle mit denen die App mit der Lampe sprechen werden jedem Tag neu erfunden. Und ändern sich dann auch gern mal mit neuen Firmware Versionen. Und wenn Du die Protokolle des 382/382A lernen möchtest dann schau in die sourcen von WifiLight, die sind GPL.

Wenn du die Hardware hast: nicht nur schnacken, auch machen. Wireshark capture und dann das Rätsel lösen. Ich benötige genau "on" sowie (wenn es eine dumme api ist) die sequenz für set RGB. Zum Thema "ist ja ganz einfach" sprechen wir uns  wenn Du auf AES oder CRC triffst und Du rausbekommen hast welche CRC mit welchem initial Vektor. Oder den AES Key

Im übrigen könntest Du Glück haben, die App ist mglw ein clone der magic light, dann ist die API dumm. Also, ab ans sniffen, lernen, verstehen, hier berichten.

vg
joerg

[GhostInTheBottle]

Bis ich die Traces mache, möchte ich das Thema vorläufig an dieser Stelle abschliessen, denn wenn es konkret wird , ist es ja nicht mehr OT. Deshalb nur kurz ...
Dieses 15W Lämpchen (Da kommt richtig Licht raus und stylisch ist das Ding auch noch) :
Magic Hue LED Lampe WIFI Beleuchtung dimmbar Energiesparlampen mit Amazon echo Alexa Sunrise Farbige Leuchtmittel Sonnenaufgang 15W Smart E27 und E26 16 Mio Farben fuer Android und IOS
lässt sich als LD316A (und nur damit) mit WifiLight immerhin EINSCHALTEN. Mehr geht nicht - Mit der App oder Alexa darf ich dann wieder ausschalten. Jetzt mache ich aber die Traces und versuche dann mein Verständnis über die Sourcen von WifiLight zu vertiefen.
 

[herrmannj]

na denn, also dumme api.

Mach mal bitte folgende wireshark traces:

Einschalten, ROT etwa 50%, ROT 100%, (so auch B, G) sowie WHITE 50%, 100%
Dann bitte einfach hier rein stellen.
Die sourcen brauchste nicht lernen.

Ich verschiebe den thread nach "Beleuchtung".

[GhostInTheBottle]

Hallo und Guten Morgen,
hat etwas gedauert, musste alte FB (7270) mit meinem Netz gebridged und die SSID für 2,4GHz von meiner Kabelfritzbox genommen (dort natürlich deaktiviert) un dann an der eth0 der 7270 gelauscht. Dann habe ich die App auf dem iPad gestartet und versucht Deine Handlungsanleitung umzusetzen. Ich nehme an, wenn Du schreibst 50%, dann ist gemeint, den Helligkeitsschieberegler auf ungefähr die Hälfte schieben? Wenn ich von rot 100% auf blau 50% wechsle, vorher auf 50% schieben oder erst wenn ich gewechselt habe? Hoffentlich habe ich da vom Ablauf her nichts durcheinander gebracht. Meine Denkpausen sollten allerdings am Zeitstempel zu erkennen sein. An die Reihenfolge des Warbwechsels R B G W habe ich mich aber gehalten Der letzte Befehl ist dann das Ausschalten. Sollte ich doch Chaos reingebracht haben, kann ich ja auch kleinere überschaubare Sequenzen nochmals einzeln tracen.
Soweit erst mal.
Dank und Gruß
Lutz

[herrmannj]

vielen Dank. Kann man bei dem Ding warmweiß und kaltweiß getrennt einstellen ?
Ich kenn die app nicht: hat die einen Schieberegler für die Gesamthelligkeit ?

Der trace ist wirklich ein bischen durcheinander aber ich denke das passt im großen.

Mahc mal bitte noch einen wo nur 100% grün drin ist, also am besten den controller an, dann trace starten und wenn vorhanden irgendwo draufdrücken wo hundert prozent grün rauskommt.

Wenn die ww und cw getrennt regelt dann bitte da auch nochmal. Da ist noch ein byte drin wo ich unsicher bin.

Ansonsten ist das Protokoll ein clone der ld Serie, passt also.

vg
joerg

[herrmannj]

ab sekunde 72, da mchst Du wohl weiß:

31:00:00:00:05:ea:0f:0f:3e

Da bewegen sich aber zwei bytes, ich würde nur mit einem rechnen. Anhand app bzw Kenntnis der bulb: gibt es da einen Grund zwei Werte zu übetragen ? (cw, ww - ein extra regler, whatever ?)

vg
joerg

[herrmannj]

kann das Dingens nur entweder Farbe oder Weiß ? Genauer formuliert, wenn kannst Du die echte weiße LED und die zb ROTE gleichzeitig per app ?

31:00:00:00:05:ea:0f:0f:3e

[GhostInTheBottle]

Ja, ein extra Helligkeitsregler existiert sowohl bei Farbe, als auch bei den Weisstonwerten, bei weiss hat das teil eine ähnliche Funktion wie die teuren Osram ind Philips, also tunable white bze. white ambiance. Könnte das die zusätzliche Information sein?
Vg
Lutz

[herrmannj]

Ja, ein extra Helligkeitsregler existiert sowohl bei Farbe, als auch bei den Weisstonwerten, bei weiss hat das teil eine ähnliche Funktion wie die teuren Osram ind Philips, also tunable white bze. white ambiance. Könnte das die zusätzliche Information sein?
Vg
Lutz

was bewirkt diese Funktion ?

[GhostInTheBottle]

mein letztes Posting bezog sich auf Deinen vorletzten Beitrg. Zu Deiner lrtzten Frage ... Rot und weiss mischen - eher nicht. Wie dann allerdings die weiss Farbtemperatur erzeugt wird - keine Ahnunt. Evtl etwas gelb dazugemischt?

[GhostInTheBottle]

Du meinst tunable white?
Die Farbtemperatur wird geändert.kaltweiss, neutral, warmweiss.
Auch das wird über ein Farbrad eingestellt, in diesem Fall mif den entsprechenden Weisstönen.

[herrmannj]

verstehe ich richtig ?:

man kann entweder Farbe oder Weiß.
Weiß kann man in der Farbtemperatur anpassen.

Wenn ja, dann wären das die traces die ich bräuchte

100% grün (R:0, B:0)
100% weiß kalt (farbe 0)
100% weiß warm (farbe 0)

morgen reicht aber locker.

danke vg
joerg

edit: überschnitten.