Plugin Twinkly: toujours maintenu?

Hello !

Ramené ici grâce à @iPapy, je confirme que le plugin fonctionne (j’ai une Guirlande V2 250 leds)

Comme je ne sais pas ce qui est sensé fonctionner ou pas voici quelques retours

Pas eu de détection automatique, pourtant renseignée manuellement (ip et mac) tout fonctionne
Je n’ai pas le numéro de version PRODUIT qui remonte (mais bien la version matériel)
La partie animation ne me montre rien, ajouter permet de charger un fichier, supprimer tourne en boucle (normal y a rien dans la liste :))

Côté Widget, cela fonctionne sauf la playlist active qui ne s’affiche pas (et qui est pourtant en cours dans la Twinkly)

Encore merci pour votre super boulot !


1 « J'aime »

Merci pour les retours.

Les playlists ne sont pas encore gérées pour l’instant, ça va venir.

Pour l’instant, la partie « animation » est à gérer manuellement en chargeant les fichiers binaires correspondant. Je suis en train de travailler sur un process de capture simplifié (merci à @mguyard pour les pistes)

Je n’ai pas non plus retravaillé le widget par défaut, je m’en occupe ensuite (il y a eu quelques ajouts ce matin pour remonter correctement le niveau de luminosité et le mode courant).

Les informations affichées sur l’équipement (versions, etc.) sont un peu en vrac. J’ai le numéro de version produit sur ma v1, mais pas ma v2, je vais voir ce qui est pertinent ici (nom du wifi, version de firmware).

J’essaye d’ajouter un maximum de choses avant de passer en bêta.

K.

1 « J'aime »

Bonjour,

Je n’ai fait que t’orienter vers l’excellent travail fait par @kimagure et que même si je n’est plus de petit enfant à la maison en cette période de fête j’aimerais que @kimagure puisse débuguer au max son plugin afin que tous les utilisateurs de Twinkly soit content et passe de très belle fêtes de fin d’année.

Bravo à toi @kimagure pour cette belle initiative ainsi qu’a @mguyard qui semble aussi t’aider.

1 « J'aime »

Le sapin, c’est pas pour les « petits enfants »: tout le monde y a droit s’il en a envie :grin:
Pas de raison que les adultes, qui ne restent pas moins que des grand enfants, n’aient pas aussi les yeux pleins qui brillent ! :wink:

2 « J'aime »

Tu as tout a fait raison :slight_smile:

@kimagure , merci, cela fonctionne très bien, et surtout, il faut désactiver l’ancien plugin avant, sinon cela plante l’objet dans lequel on le place (Salon par exemple).
Nickel, car c’était dommage de ne plus pouvoir utiliser Agenda et la planification On/Off que j’avais mise en place (plus complète avec Jeedom pour jour de semaine, jour férié, we…)
Encore merci et tiens nous au jus pour une stable, car je ne suis pas fan du beta sur ma machine de prod :wink:

Et je confirme, si tu reprends la main avec l’apps Twinkly, tu perds celle de jeedom. Pour la récupérer, il faut faire recherche dans le plugin.

Tu entend quoi par recherche ?
Le refresh ne reprend pas la main automatiquement ?

Il n’y aura pas de solution miracle pour que l’app mobile et le plugin cohabitent.
Même Twinkly prévient qu’on ne peut utiliser l’application sur 2 smartphones simultanément…

En fait, le contrôleur ne gère qu’une seule authentification simultanée. Dès qu’un nouvel access token est généré, l’ancien est invalidé, donc c’est la dernière application qui se connecte qui « a raison ».

De mon point de vue, une fois les guirlandes configurées et les animations capturées, on pourra tout faire depuis Jeedom, donc l’appli n’est pas indispensable. Il est toujours possible de désactiver temporairement le plugin le temps de faire une opération particulière sur l’app (upgrade du firmware, nouvelle analyse, etc.)

Voici comment je vois les choses:

  • il faut que je gère un peu mieux les codes retour de l’API, et en cas d’erreur d’authentification lors de l’appel de l’une des APIs, je regénère un nouveau token (ce qui invalide les éventuels autres clients connectés)
  • pour éviter les conflits pour les personnes qui veulent garder l’app mobile utilisable sans trop de soucis, je rend optionnel le refresh automatique (fonction pas encore dispo sur github, juste sur ma dev locale pour l’instant) pour ne pas générer un nouveau token toutes les x secondes et donc déconnecter l’app. Du coup, j’ajoute aussi une nouvelle commande « refresh » pour le faire à la demande (par exemple dans un scénario).
    => Question : faut-il que la désactivation du refresh se fasse par équipement (checkbox dans la page de l’équipement) ou pour le plugin complet (checkbox dans la page de configuration générale du plugin) ?

Pour les animations, je me suis rendu compte que les API étaient différentes entre mes guirlandes v1 et v2. La v1 n’a pas l’air de gérer la partie « playlist » (probablement à cause d’une mémoire insuffisante sur le controleur). Ca dépend peut être de la version du firmware aussi, je ne crois pas que les playlists existaient sur ma v2 l’année dernière. Il faut que je regarde comment pouvoir gérer les 2 cas, donc ça va me prendre un peu plus de temps.

J’avance aussi sur la fonctionnalité de capture des animations, avec une idée proposée par @mguyard. Si je m’en sors comme prévu, la mise en place du proxy pour la capture sera faite depuis l’application, il faudra juste temporairement paramétrer le smartphone avec l’adresse et le port du proxy sur la machine Jeedom.

Edit: j’ai effectivement trouvé dans l’APK les versions minimales de firmware supportées pour les différentes fonctionnalités, et notamment:

  • version minimale 2.3.0 pour le réglage de la luminosité
  • version minimale 2.5.5 pour la gestion des playlists (et donc le nouveau mode d’upload)

Ma guirlande v1 est en 2.3.8, donc effectivement pas de support des playlists.

K.

Très bonne idée.

Optionnel c’est bien. Idéalement choisir le délais entre 2 refresh serait top, comme ca on peut espacer si on le souhaite et ca laisse le temps de faire un truc par l’application avant que Jeedom reprenne la main.

Top

Pour plus de flexibilité, je le mettrait par Equipement. Mais ce n’est que mon humble avis.

Cool tu sais que je suis là au besoin :wink:

En tout cas, merci. Il me tarde de recevoir ma Twinkly 400 Gen2 :slight_smile:

J’avance toujours, je vais essayer de publier une nouvelle version d’ici demain soir.

Le rafraichissement automatique est donc désactivable par équipement, et la fréquence de rafraichissement est configurable.

La capture des animations directement depuis Jeedom est désormais possible : un proxy démarre sur la machine jeedom sur un simple clic, on configure le proxy dans le smartphone, on lance une série de chargement d’animations vers la guirlande, on ferme le proxy, et le plugin récupère les fichiers.

C’est quasi finalisé pour les guirlandes « gen1 », et je suis en bonne voie pour les « gen2 » également, sachant qu’il faut que j’adapte un peu ma classe « Twinkly » pour gérer l’upload en v2 (et les playlists par la suite)

K.

Pour ceux qui hésitent pour l’installation, vous pouvez l’installer en utilisant le type de source Github et mettant les paramètres suivants :


ou en clair :
ID logique du plugin : kTwinkly
Utilisateur ou organisation du dépôt : kimagurefr
Nom du dépôt : jeedom_kTwinkly
Branche : unstable

Hello

J’avais promis une mise à jour aujourd’hui, la voilà.
Bon, techniquement on est déjà « demain »…

Grosse update, je ne garantis pas d’avoir tout testé à fond, je rappelle qu’on est encore sur une branche « unstable » :slight_smile:

Il y a encore beaucoup (trop) de logs de debuggage et il faudra refaire une passe de nettoyage du code (factorisation, commentaires, etc.)

Comme je l’avais dit dans mon précédent message, il est possible d’interrompre la mise à jour automatique (état, luminosité, etc.) équipement par équipement en décochant la case dans les paramètres de l’équipement (sous l’IP et la mac address. Ca permet d’utiliser l’application mobile pendant ce temps sans risque de se faire déconnecter (note pour plus tard : prévoir une désactivation du refresh auto pendant la phase de capture)
La fréquence de refresh est également paramétrable dans les paramètres globaux du plugin (c’est donc commun à tous les équipements).

L’image de l’équipement devrait s’afficher en fonction du produit. J’utilise les images et le fichier de mapping issue de l’appli mobile Android officielle, donc ça devrait correspondre.

Gros changement dans la gestion des fichiers d’animation pour pouvoir gérer simultanément les « gen1 » et les « gen2 » : maintenant, une animation est systématiquement un fichier zip contenant le binaire de l’animation elle même, ainsi qu’un fichier json de description.

Lors de l’upload, je génére un nom unique (guid), c’est pas super sexy, donc à voir comment faire évoluer ça. Il est possible de télécharger le zip depuis la liste des animations associées à l’équipement pour la sauvegarder et la réuploader plus tard. Lors de l’upload, il y a quelques tests basiques pour vérifier que le zip correspond au bon type de guirlande (génération et nombre de leds).

La grosse nouveauté, pas encore tout à fait sèche, c’est la possibilité de capturer directement les animations, aussi bien pour les guirlandes gen1 que gen2.

En appuyant sur le gros bouton « Démarrer la capture », on lance un proxy « mitmdump » sur le serveur jeedom (port 14233, fixe pour l’instant).
Il suffit ensuite de configurer ce proxy dans les paramètres wifi du smartphone, de lancer l’appli Twinkly, et de télécharger des animations vers l’équipement en cours.
On clique ensuite sur « Arrêter la capture » et les animations capturées sont remontées dans la liste.

Pour les gen1, il n’y a pas de nom, donc il faut le mettre à la main.
Pour les gen2, le nom de l’animation est dans les métadonnées, donc il est récupéré directement dans la liste.

Attention : j’utilise pour l’instant un mitmdump « tout en un » pour éviter d’avoir à gérer les dépendances. Malheureusement, cet executable n’existe que pour processeur x86 64 bits, donc le process de capture ne marchera que sur cette plateforme. Pour devenir multiplateforme, il va falloir que je passe par les packages python, donc c’est un peu plus impactant…

Evidemment, une fois l’animation chargée, il est possible de l’envoyer vers la guirlande, aussi bien pour les gen1 que les gen2. Pour ces derniers, c’est une toute première version du code qui date de ce soir, mais ça semble marcher sur mon sapin :slight_smile: Je ne gère toujours pas les playlists, donc un envoi d’animation effacera la playlist en cours. Il faut d’ailleurs que j’ajoute une nouvelle commande « playlist » en plus de on et off.

J’espère avoir assez avancé sur le debug et le nettoyage de code d’ici la fin du week-end pour passer en beta…

K.

1 « J'aime »

Nouvelles mises à jour poussées sur github.

Le port du proxy est désormais paramétrable.

Comme je l’ai dit plus haut, le projet mitmproxy ne fournissant des binaires linux « tout en un » que pour l’archi x86_64, je suis passé sur une installation via les dépendances, en utilisant la version dispo sur les repos debian. On passe sur une version plus tout à fait à jour de mitmdump (4.0.4 sur ma Debian 10 au lieu de la 5.3 précédemment, mais ce n’est pas impactant pour l’utilisation ici).

Du même coup, la taille du plugin a fortement diminué, donc ce n’est finalement pas plus mal.
J’aurais bien voulu me passer de dépendances externes, mais tant pis.

Je suppose que ça doit marcher avec Raspbian également, je n’ai pas encore pu tester sur un Raspberry PI.

K.

Simple, fonctionnel et efficace, bravo @kimagure pour le travail fourni et merci à @iPapy de m’avoir ramené ici depuis le discord @Domotech pour me faire découvrir ce projet !
Bonne journée

1 « J'aime »

Bonjour
Super le plugin !! toptop
Pour information cela fait planter le plugin Google Smarthome
Voici le message « Call to undefined method Twinkly::getId() »

Encore bravo

J’ai regardé, je ne vois nulle part dans mon code d’appel à Twinkly::getId
La classe Twinkly est ma classe « utilitaire » d’origine que j’utilisais via script, et est différente de la classe du plugin (kTwinkly).

Je n’ai malheureusement pas le plugin gsh (même s’ai j’ai un google home mini qui traine dans un tiroir), donc pas de moyen simple de tester…

Est-ce que le fait de ma classe Twinkly soit dans le dossier class pourrait provoquer une erreur d’une sorte de découverte automatique par le plugin gsh ?

Je peux la déplacer sans souci dans le dossier resources si c’est le cas.

K.

désolé aucunes idées

Bonjour à tous, j’ai créé un nouveau sujet, plus visible, pour discuter du plugin : Plugin kTwinkly - Guirlandes connectées Twinkly

Je vous invite à poser vos questions et vos retours/remarques à cet endroit…

J’ai mis à jour la documentation du plugin, qui devrait être accessible depuis le lien « Documentation ».

Maintenant que le plugin est en beta, je vais essayer d’alimenter le changelog.

Je vais renommer ma classe de contrôle (Twinkly) pour éviter d’éventuels conflits avec l’ancien plugin.
Je vais également continuer le nettoyage du code (préparation des traductions, suppression de logs debug, meilleure gestion des erreurs).

Je me pencherai ensuite sur la gestion des playlists, mais c’est un gros morceau et je n’ai pas encore étudié à fond l’API.

Au sujet de l’API, j’essayerai également de documenter tout ce que j’ai capturé. Une grosse partie est déjà visible sur la documentation du projet xled, mais toutes les nouveautés n’y figurent pas encore.

J’ajouterai sans doute une section sur la partie MQTT. C’est un peu hors sujet du plugin, mais c’est un autre moyen simple de communiquer avec la guirlande pour les fonctionnalités de base, hors chargement des animations.

Merci pour vos encouragements. C’est mon premier plugin, je découvre un certain nombre de choses au passage…

K.

4 « J'aime »

Un message a été fusionné à un sujet existant : Plugin kTwinkly - Guirlandes connectées Twinkly