Modul 31_Twinkly.pm - Control Twinkly Lights

[t1me2die]

Moin liebes Forum,

passend zur anbrechenden Winterzeit kam mal wieder die Twinkly Lichterkette aus dem Keller zum Vorschein.
Ich stellte mir also erneut die Frage, ob es mittlerweile ein Modul zur Steuerung der unzähligen Twinkly Produkte https://twinkly.com/de gibt.
Bisher habe ich die Steuerung immer über HTTPMOD vorgenommen, was nur sehr eingeschränkt funktionierte.

Bei meiner Recherche bin ich auf die (unofficial) RESTful API Beschreibung von https://xled-docs.readthedocs.io/en/latest/rest_api.html gestoßen.

Anhand der API habe ich nun ein erstes Modul mit dem Namen 31_Twinkly.pm entwickelt, welches ich aktuell mit folgenden Geräten betreibe:

• Strings GoldEdition (AWW auch genannt)
• Strings RGBW Edition
• Spritzer (RGB)
• Cluster (RGB)
• Festoon (RGB)

Das Modul steht zum Test in meinem git zu Verfügung / alternativ am Ende des Beitrages:
https://github.com/t1me2die/31_Twinkly.pm/blob/main/31_Twinkly.pm

Dokumentation im FHEMWiki:
https://wiki.fhem.de/wiki/Twinkly

Zu aller erst, dass Modul ist in der Entwicklungsphase und nicht alle Funktionen sind zu 100% getestet, daher gilt "Verwendung auf eigene Gefahr!".

Nachdem ihr das Modul in das FHEM Verzeichnis gepackt habt und einen:

Code: [Auswählen]

reload 31_Twinkly.pmvorgenommen habt, könnt ihr mit dem

Define fortsetzen:

Code: [Auswählen]

define <name> Twinkly <IP-Adresse / Hostname>
Beispiel:

Code: [Auswählen]

define Weihnachtskaktus Twinkly 192.168.178.100
oder
define Weihnachtskaktus Twinkly Weihnachtskaktus.fritz.box

Stellt bitte sicher, dass euer Twinkly Device im Netzwerk erreichbar ist.
Anschließend gebt dem Modul bitte 1-2Minuten um die notwendigen Informationen auszulesen.

Zuerst wird ein TOKEN vom Twinkly Device angefordert, womit man sich authentifizieren muss (Expire after ~4h).
Es werden interne Geräteinformationen in den Readings abgelegt.
Es wird versucht das Model automatisch zu ermitteln.
Es wird versucht ein Icon und das passende webCmd für eine einfache Steuerung zu setzen.

Folgende GET Befehle stehen zur Auswahl:

• Gestalt - main device informations
• Mode    - get actual mode of device
• Movies  - get all uploaded / saved movies from the device
• Name    - get internal informations of the device
• Network - get network informations of the device
• Token   - check if the token is valid or need to updated

Folgende SET Befehle stehen zur Auswahl:

• brightness - set brightness to device
• effect_id  - set a standard effect to device
• hue        - set hue color to device
• mode       - set different mode to device
• movie      - switch between uploaded /saved movies - use "get Device Movies" first!
• on         - switch device on in the movie mode
• off        - switch device off
• saturation - set saturation to device

Folgendes ATTR kann optional gesetzt werden:

• model                - will be set automatically depends on the product_code
• interval              - define the refresh interval (min: 15sec -> default: each 60sec)

Eine erste "Device specific Help" habe ich angelegt - zum Großteil zuerst auf englisch.

Falls ihr eine Gruppierung von mehreren Geräten in der Twinkly App vorgenommen habt, so müsst ihr das Main-Steuerungsgerät herausfinden.
In meinem Fall habe ich zwei AWW (400 und 250er Strings) via Join verbunden. In meinem Fall war es das erste Gerät in der Gruppierungsliste (dies war auch das Gerät, welches ich zuerst ausgewählt hatte!).
Das zweite Gerät kann man via einzeln auch steuern, jedoch kommt die Gruppierung dann ein wenig durcheinander, weswegen ich vorschlagen würde, dass ihr nur das Main-Gerät definiert. Die Funktionen sind hier identisch wie bei einem einzelnen Gerät.

Für Feedback, Code-Verbesserung und weitere Vorschläge bin ich gerne offen
Ansonsten hoffe ich, dass es vielleicht dem Ein oder Anderen hilft die Weihnachtszeit etwas stressfreier zu gestalten 

@Energieverbrauch: Ich habe soeben den Verbrauch vom Spritzer und Cluster (400 RGB) gemessen und bin ein wenig überrascht.

• Spritzer -> 18-19Watt unabhängig von der eingestellten Helligkeit, d.h. es ist egal ob man auf 1% Helligkeit oder auf 100% Helligkeit das Gerät im Modus "movie" laufen lässt. Im Modus "color" (eine einzelne Farbe), sinkt der Verbrauch geringfügig.
• Cluster -> 37-38Watt, unabhängig der Helligkeit. Im Modus "color" liegt der Verbrauch bei 100% Helligkeit -> 33Watt, 50% Helligkeit -> 36Watt, 25% Helligkeit -> 37Watt, 1% Helligkeit -> 38Watt

Gruß
Mathias

@Edit:

Code: [Auswählen]

Changelog:
* v0.1.0 fixed ct colorpicker and published to fhem forum.
* v0.1.1 message in INTERNAL if no movie(s) found on device
* v0.1.2 warning messages if no movies found and cmd 'on' sent
* v0.1.3 ability to use ct colorpicker by RGBW devices (set <name> ct 2000-6500)
* v0.1.4 added error messages for set commands
* v0.1.5 1. call json2reading if $data is not "Invalid Token"
         2. If Token is resettet -> Invalid Token -> call stateRequest to get new Token
* v0.1.6 List of "getMovies" saved with {helper} in devices to save time by the loop


[peterk_de]

Schön, dass das mal jemand in ein Modul gießt :-)

Wenn ich zwischen den zeilen lese, heißt das, die haben die Firmware/API endlich mal so geupdated, dass man jetzt mehr als eine selbstdesignte Animation auf die Kette hochladen und dann per API dazwischen wechseln kann? Das ging mit meinen Ketten in den letzten Jahren nicht und wäre ja großartig!

[t1me2die]

Mit der neusten Firmware (2.8.11) und den GEN II Sticks (welche seit einigen Jahren) ausgeliefert werden, kann man bis zu 15 eigene Effekte via Twinkly App bauen / basteln / malen / downloaden und auf dem Stick speichern / hochladen.
Diese werden dann als Effekte gespeichert.
Diese Effekte alias "Movies" kann man mit dem Modul via "get <name> Movies" vom Stick laden / auslesen.
In den Readings werden dann alle Movies gespeichert.
Jedes Movies besitzt eine ID, diese ID wird benötigt, um das jeweilige Movie anzusteuern / schalten.
Leerzeichen in den Movie-Namen werden raus gelöscht um die Movies darzustellen und via "set <name> movie <Movie-Namen>" absetzen zu können (siehe Screenshot)

Gruß
Mathias

[peterk_de]

Großartig. Das ist DIE Funktion, die mir seit erscheinen der Ketten fehlte - jetzt kann ich je nach Lichtstimmung einen anderen Effekt nehmen :-)

Dann hole ich direkt mal die Ketten aus dem Keller und teste dein Modul. Das jährliche Entheddern war eigentlich erst für nächstes WE geplant, aber das muss unbedingt nen Probelauf bekommen

[t1me2die]

Welche Ketten hast du denn im Bestand?
Achte darauf, dass du das Modul und die Twinkly App nicht gleichzeitig einsetzt!
Disable am besten das Modul / Device, wenn du eine Kette via Twinkly App steuerst!
Hintergrund ist, auch die Twinkly App fragt bei dem Device einen TOKEN an.
Da zwei Anfragen (einmal FHEM und einmal Twinkly App) bei der Kette eintreffen wird jedes Mal ein neuer Token generiert, deswegen kommt es zu Steuerungsproblemen!
Das Modul prüft / aktualisiert automatisch den Token, ggf. könnte man das prüfen / aktualisieren auch via "get <name> Token" erneut anstoßen, läuft aber im Interval alle 60Sekunden.
Dementsprechend sollte sich auch alle 60 Sekunden der Status / Readings im FHEM aktualisieren.
Ein pollen wir beim HUE Modul ist mit meinem aktuellen Wissen nicht möglich.

Gruß
Mathias

[peterk_de]

Was soll ich sagen - es geht auf Anhieb! Wenn das mal bei jedem Modul so wäre ;-)

Firmware der Kette hatte ich vor der Installation geupdatet - da war dann in der App schon die neue Möglichkeit sichtbar, mehrere Effekte hochzuladen (etwas provisorisch zwar - man kann nur den letzten hochgeladenen Effekt löschen - aber immerhin )

App hatte ich dann geschlossen, das kannte ich noch aus meinem Gebastel mit HTTPMOD. Und dann das Twinkly-Device definiert - List::MoreUtils hatte ich nicht und musste ich noch installieren. Aber dann lief es sofort! Nach ca. 2 min waren alle DeviceInfos gelesen und Steuerung ging. Und nach deinem Tipp mit get movies geht jetzt auch das direkte Ansteuern von Effekten! SUUPER!

Also das Entheddern der Kette war definitiv schwieriger Herzlichen Dank!!!

[t1me2die]

Das freut mich 
Das Gruppieren von Ketten / Geräten habe ich bisher noch nicht getestet (auch nicht in der Twinkly App).

Neue Updates / Fixes lade ich von Zeit zu Zeit im ersten Beitrag / GitHub hoch.

Gruß
Mathias

[peterk_de]

Ok, Gruppieren kann ich grad schlecht probieren, brauche ich aber für den W-Baum und teste ich baldmöglichst. Ich denke aber, wenn das in der API so geblieben ist, sollte es keine größeren Probleme machen, solang man immer nur mit der ersten Kette redet, die zweite also in FHEM nicht anfasst. Hoffe ich zumindest Ich berichte dann.

[t1me2die]

Falls Dir das Refresh INTERVAL von 60Sekunden (default) zu lange dauert, kannst du über:

Code: [Auswählen]

attr <name> interval xx
das Interval verändern (min. 15).
Der "define" kann alternativ auch mit dem Hostnamen erfolgen wie z.B.:

Code: [Auswählen]

define Weihnachtskaktus Twinkly weihnachtskaktus.fritz.box
Ich habe nun den Colortemperatur (CT) Colorpicker von ehemals AWW umbenannt auf CT, sodass man einheitlich ist.
Geräte, die z.B. RGB+W besitzen können nun via HUE (RGB) Colorpicker oder auch via CT Colorpicker gesteuert werden.
Die Set-Befehle sollten entsprechend automatisch vorhanden sein.

Gruß
Mathias

[ossi]

Hallo,
ich habe dieses Jahr erstmals eine Twinkly Kette im Einsatz und war begeistert, dass es bereits ein Modul dafür gibt. Noch begeisterter war ich, dass gleich alles im ersten Versuch geklappt hat, hatte eigentlich befürchtet, dass ich stundenlang rumbasteln müsste um irgendetwas zum laufen zu bringen. Vielen Dank dafür.

Wie immer sind die Benutzer aber natürlich nie zufrieden 

Da ich die Kette per Power Switch (gemeinsam mit dem sonstigen Weihnachtskram) automatisch abschalte wenn nicht benötigt, findet sich im FHEM Logfile natürlich für diesen Zeitraum eine nervige Fehlermeldung, dass die Kette nicht erreichbar wäre.

Nun nutzt man das Ding ja in der Regel sowieso nur für kurze Zeit, daher dachte ich es wäre vielleicht eine gute Idee, wenn man noch ein 'Disable' einbauen könnte, so dass man das Teil nach Weihnachten einfach funktionslos machen kann. Kommt das nächste Jahr kann man auf Knopfdruck wieder weiter machen.

Denkst du sowas wäre noch machbar?

[bartman121]

Dafür gibt es das Attribut disable

Du kannst das auch setzen ohne, dass es ein rotes Fragezeichen gibt, dann ist es aber nicht persistent und überlebt keinen fhem Neustart.

attr -silent $device $attrval


Das würde ich in deinem Fall auch mit deinen ats notifies setzen, wenn du Steckdose an und aus machst.

[t1me2die]

Hallo,
ich habe dieses Jahr erstmals eine Twinkly Kette im Einsatz und war begeistert, dass es bereits ein Modul dafür gibt. Noch begeisterter war ich, dass gleich alles im ersten Versuch geklappt hat, hatte eigentlich befürchtet, dass ich stundenlang rumbasteln müsste um irgendetwas zum laufen zu bringen. Vielen Dank dafür.

Wie immer sind die Benutzer aber natürlich nie zufrieden 

Da ich die Kette per Power Switch (gemeinsam mit dem sonstigen Weihnachtskram) automatisch abschalte wenn nicht benötigt, findet sich im FHEM Logfile natürlich für diesen Zeitraum eine nervige Fehlermeldung, dass die Kette nicht erreichbar wäre.

Nun nutzt man das Ding ja in der Regel sowieso nur für kurze Zeit, daher dachte ich es wäre vielleicht eine gute Idee, wenn man noch ein 'Disable' einbauen könnte, so dass man das Teil nach Weihnachten einfach funktionslos machen kann. Kommt das nächste Jahr kann man auf Knopfdruck wieder weiter machen.

Denkst du sowas wäre noch machbar?

Schön, wenn es direkt funktioniert.
Zuerst einmal gibt es die Möglichkeit

Code: [Auswählen]

attr <name> disable 1

zu setzen, dann sollte das Device auch disabled sein und keine Logmeldungen mehr erzeugen.
Außerdem könntest du mal bitte die Logmeldung posten, die immer wieder erzeugt wird.
Entweder ich habe dort ein falsches oder zu niedriges Loglevel gesetzt, worüber man gerne sprechen kann.
Ansonsten könnte man in dem Device selbst auch noch via:

Code: [Auswählen]

attr <name> verbose 0
Meldungen nahezu komplett unterdrücken 

Gruß
Mathias

[ossi]

Hallo, die Meldung im log lautet

error while requesting http://192.168.Xxxxxx/xled/v1/verify - connect to http://192.168.xxxxxx:xxxx timed out - Data ->

Mit dem disable 0 verschwindet das allerdings, danke für die schnelle Hilfe.

[t1me2die]

Moin ossi,

die Fehlermeldung erscheint, wie du schon richtig erkannt hast, wenn das Gerät im Netzwerk nicht erreichbar ist.
Es ist ein eine verbose 3 Meldung, d.h. mit:

Code: [Auswählen]

attr <name> verbose 2
taucht die Meldung nicht mehr im Log auf.
Außerdem sollte in dem INTERNAL (NETWORK_STATE) von dem Device "offline" stehen.
Die Logmeldung sollte außerdem auch in dem Reading "fullResponse" auftauchen.

Gruß
Mathias

[Borkk]

Hallo Zusammen,

Super das es nun ein Modul gibt. Bei mir klappt es leider nicht so reibungslos. Sobald das Modul zum ersten mal auf die Kette zugreift startet FHEM neu.

Code: [Auswählen]

/entry.sh: line 621: kill: (9298) - No such process
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Resource not found.") at ./FHEM/31_Twinkly.pm line 778.
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (9298) - No such process
 10/entry.sh: line 625: kill: (9298) - No such process
 9/entry.sh: line 625: kill: (9298) - No such process
 8/entry.sh: line 625: kill: (9298) - No such process
 7/entry.sh: line 625: kill: (9298) - No such process
 6/entry.sh: line 625: kill: (9298) - No such process
 5/entry.sh: line 625: kill: (9298) - No such process
 4/entry.sh: line 625: kill: (9298) - No such process
 3/entry.sh: line 625: kill: (9298) - No such process
 2/entry.sh: line 625: kill: (9298) - No such process
 1/entry.sh: line 625: kill: (9298) - No such process
/entry.sh: line 632: kill: (9298) - No such process
 0
Automatic restart ...
Es könnte an 2 Dingen liegen:
1.) Ich nutze FHEM im DOCKER Container, (u.U. fehlen Pakete)
2.) Ich habe noch eine (zu) alte Twinkly Wall (gibts leider nicht mehr) (Modell TI200SEUP07, FW 2.3.5)

Mit dem HTTPMOD Workarround konnte ich jedoch die Kette steuern.