HUE, LIFX, Osram Lightify, (lumières connectées, domotique, Google Home / assistant)

[theclaw]

Bon, il est minuit, grmbl. Je sais pas s'il faut utilser MQTT, ni s'il est setup comme il faut. Ca parle de "topics" dans MQTT mais je vois pas comment les trouver nulle part.

C'est.
La.
Merde.

[Daedaal]

Pas besoin de MQTT pour ce que tu veux faire, c'est un autre système de messages qui n'a pas vraiment à voir avec ça.

Les messages dans NodeRed sont ceux qui transitent d'un node à l'autre.

Si ta telco est dans Hass, elle est dans NodeRed.
Ce dont tu as besoin c'est d'un point d'entrée des événements de Hass.

Tu crée ce flow :



Tu ignores le WARING, je doute que ton install (pas plus que la mienne d'ailleurs) sature les capacités de ton Pi4.

Tu le déploies, tu affiches le débug et tu verra s'afficher TOUS les event de ton système en temps réel.
('faudra peut-être activer le node de debug en cliquant dessus, 'chais plus si il est ON par défaut. )
Quand t'en a marre que ça s'affiche, tu clic sur le node de debug pour le désactiver.

Chacune des entrées représente un message qui passe de Events_all vers le debug.

Un message est structuré. C'est à dire qu'il contient des objets (qui sont des sous catégories) qui eux mêmes peuvent en contenir d'autres. Ce ne sont que des tiroirs qui permettent de ranger les infos par catégorie. Ces infos sont toujours sous la forme clé-valeur. La clé indique ce à quoi s'applique la valeur qu'elle contient.

Transposé à l'explorateur de fichier, un message serait un dossier et les objets des sous-dossiers. Les clefs le nom des répertoires et la valeur leur contenu.

Extrait de l'appui sur le gros bouton rond de la même telco que la tienne :



J'ai déployé le message de la telco.

Dans l'ordre tu as un objet qui décrit l'event

event_type => c'est la catégorie de l'event comme son nom l'indique. C'est la valeur que tu peux mettre en configurant le node events_all pour ne filter que ceux qui t'intéressent.

Puis l'event lui-même qui est à son tour un objet qui décrit la nature de ce qui s'est passé :

id => Le nom en clair de ce qui est à l'origine de l'event
unique_id => le nom unique du même
event => le contenu de l'event. Ici le code qui correspond au bouton que j'ai pressé.

"Évidement" le contenu de l'event peut contenir d'autres choses selon ce qui s'est passé et ce à quoi il se rapporte.

J'ai un flow qui allume une ampoule lorsqu'on appuie sur ce bouton de cette telco.

Donc après la description de l'event, on trouve un message qui décrit la commande qui a été envoyée. Ici un call_service pour allumer l'ampoule avec ses paramètres :



Et ensuite, un message qui décrit qu'une ampoule a changé d'état. Heureusement sinon c'est que mon flow n'a pas marché.



On va y retrouver les caractéristiques de l'entité qui a changée, les anciennes valeurs et les nouvelles. Toujours avec cette structure en arborescence pour qu'on s'y retrouve "facilement".

Donc voilà ce qu'est un message dans NodeRed.


Le principe de NodeRed c'est de chopper le message qui t'intéresse (ici l'appui sur le bouton de la telco) et de le router jusqu'à un node d'action (le call service que tu as défini pour allumer ta lampe).

Pour ça, tu as des noeuds qui te permettent de filtrer en disant par exemple que si la valeur de mon event est 1002 tu envoies le message sur une branche et si c'est 1003 sur une autre.
En fonction, ton message va suivre un trajet pour finir par déclencher ce que tu veux.

Limite c'est du railroad tycoon ou du factorio. C'est aussi simple (ou complexe) que ça.


Une fois que ce sera un peu plus clair (j'espère) et si il y a besoin, on verra les filtres un peu plus en détail.

[theclaw]

Merci d'avoir pris le temps

Je vais dérouler ça et je reviens (ça va pas être long avant que je revienne )

- - - Mise à jour - - -

Tu sais comment virer un module de la palette alors qu'il est listé "in use" ? :D

- - - Mise à jour - - -

Ah et j'ai des trillions de trucs sensor.eole_packets_received, c'est quoi EOLE ?

- - - Mise à jour - - -

OK, donc je vois effectivement la télécommande quand j'appuie sur Power On (ou un autre bouton)




Et donc la lampe qui a changé:




First step done

- - - Mise à jour - - -

Ah tiens ça m'amène une question: je ne vois pas dans Hass où on trouve l'id de l'entité. Si je cherche Lampe Salon, bah je ne vois pas l'entité. Et dans entité je ne vois pas la lampe...ah si, lol.

- - - Mise à jour - - -

OK donc j'ai compris le principe, c'est plus clair une fois qu'on sait qu'il faut un events:state + debug pour choper les messages.

Donc mon souci now, c'est que je ne sais pas comment "définir" un node qui soit associé à Telco1 par exemple. Quelle étiquette dois-je choisir ? Je vais continuer à bidouiller donc entre ce msg et ta réponse avec du bol j'aurai trouvé

[Daedaal]

Oh mais je suis confiant, tu aura trouvé avant que je ne finisse ce post.

Continuons donc.

Déjà, en haut de la fenêtre de debug, tu as une dropdown pour choisir ce que la fenêtre va afficher. Par défaut elle balance tous ce qui sort de tous les noeuds de debug que tu as dans tous tes flows. C'est pas forcément idiot de la mettre sur "this flow". Si tu n'as qu'un debug c'est pas critique, c'est quand il y en a plusieurs que ça commence à être la merde.


Première étape, tu définis un filtre "deconz_event" dans ton node "events_all"
Il va chopper tous les events deconz (obvious) et que ceux-ci. Ça fera un peu de ménage et c'est là que débute le tri.



Ensuite tu fous un noeud conditionnel "switch" dans lequel tu routes chacun des messages selon l'ID de l'entité qui l'a généré :



L'idée c'est que tu testes un élément du message (que tu indiques dans "property") et en fonction de sa valeur tu l'envoie sur l'une ou l'autre sortie.

Pour accéder à un élément du message (ici l'ID) et le comparer aux valeurs que tu mets en place, ben c'est comme avec l'arborescence de fichiers. Tu remplaces simplement les "" par des points.
En utilisant la fenêtre de debug, tu peux cliquer sur l'item qui t'intéresses, et tu as une option "copy path".

Ça ressemble parfois à des trucs zarb parce que tu as des éléments et sous-élements qui ont le même nom. Donc tu peux te trouver avec un "msg.payload.event.event.id"

Et voilà !

Ici, je balance chaque élément sur un node qui renvoie à un autre flow parce que dans un seul flow (c'est chaque onglet dans NodeRed) si je fous la gestion de 15 telco et autres... Il me faudra un écran 8K et des yeux bioniques pour visualiser...

[Daedaal]

J'oubliais. Tu peux tirer plusieurs "routes" pour un même message.

Dans le screenshot, tu vois que ce qui est capté par events_all est envoyé à la fois sur un noeud de debug ET sur le noeud switch. Les deux reçoivent le même message en même temps.

Tu peux aussi ne pas tirer de route et ton message part dans le vide.

Là on a fait la manip du switch sur l'ID pour savoir de quelle telco ça vient.

Tu en mets un autre qui va tester la valeur de l'event sur la route de la telco sélectionnée et faire la même chose sur chaque param qui t'intéresse pour amener tranquillou ton message jusqu'au node d'action qu'il déclenchera.

Genre comme ça :



(comme avant, le node gris c'est un lien. Ici depuis le flow qui sépare les telco vers chacune des telco)

[theclaw]

si je peux me permettre c'est un peu con de pas pouvoir voir les events juste de x trucs. Typiquement deconz_event marche pour la remote, mais pas pour la lumière quand je la met on/off avec ma mini automation nodeRed citée page avant

Bon, non j'ai pas trouvé, mais j'ai une bonne raison, aspirateur duty

[Daedaal]

Ben en fait, si... Tu peux.

En utilisant d'autres nodes d'entrée que events_all.
Ou en travaillant directement le contenu du message avec du code.
Ou en allant chercher la valeur que tu veux au passage.

J'essaie de faire simple. Le duo "events_all" -> "debug", c'est le meilleur moyen que j'ai trouvé pour montrer comment marche la logique du truc sans rentrer dans des choses comme les "state_changed", "trigger_state" ou "event:state".

Je te ferai un topo sur comment faire un truc qui va réagir à l'appui sur ton bouton, ensuite tester l'état d'une autre entité puis envoyer une instruction à une troisième.

Ça reste sensiblement toujours le même principe. Ton petit message qui se promène sur la route que tu lui a tracé en fonction des aiguillages.

[theclaw]

Ben en fait, si... Tu peux.

En utilisant d'autres nodes d'entrée que events_all.
Ou en travaillant directement le contenu du message avec du code.
Ou en allant chercher la valeur que tu veux au passage.

J'essaie de faire simple. Le duo "events_all" -> "debug", c'est le meilleur moyen que j'ai trouvé pour montrer comment marche la logique du truc sans rentrer dans des choses comme les "state_changed", "trigger_state" ou "event:state".

Je te ferai un topo sur comment faire un truc qui va réagir à l'appui sur ton bouton, ensuite tester l'état d'une autre entité puis envoyer une instruction à une troisième.

Ça reste sensiblement toujours le même principe. Ton petit message qui se promène sur la route que tu lui a tracé en fonction des aiguillages.

En fait j'ai fait 2 events_all un pour state_changed et un pour deconz_event

Oui c'est grosbill

[Daedaal]

Tant que ça marche, fait toi plaiz.

[theclaw]

Oh mais je suis confiant, tu aura trouvé avant que je ne finisse ce post.

Continuons donc.

Déjà, en haut de la fenêtre de debug, tu as une dropdown pour choisir ce que la fenêtre va afficher. Par défaut elle balance tous ce qui sort de tous les noeuds de debug que tu as dans tous tes flows. C'est pas forcément idiot de la mettre sur "this flow". Si tu n'as qu'un debug c'est pas critique, c'est quand il y en a plusieurs que ça commence à être la merde.


Première étape, tu définis un filtre "deconz_event" dans ton node "events_all"
Il va chopper tous les events deconz (obvious) et que ceux-ci. Ça fera un peu de ménage et c'est là que débute le tri.

https://i.ibb.co/3hW78pL/Screenshot-...-03-114734.png

Ensuite tu fous un noeud conditionnel "switch" dans lequel tu routes chacun des messages selon l'ID de l'entité qui l'a généré :

https://i.ibb.co/3krYzjY/Screenshot-...-03-112901.png

L'idée c'est que tu testes un élément du message (que tu indiques dans "property") et en fonction de sa valeur tu l'envoie sur l'une ou l'autre sortie.

Pour accéder à un élément du message (ici l'ID) et le comparer aux valeurs que tu mets en place, ben c'est comme avec l'arborescence de fichiers. Tu remplaces simplement les "" par des points.
En utilisant la fenêtre de debug, tu peux cliquer sur l'item qui t'intéresses, et tu as une option "copy path".

Ça ressemble parfois à des trucs zarb parce que tu as des éléments et sous-élements qui ont le même nom. Donc tu peux te trouver avec un "msg.payload.event.event.id"

Et voilà !

Ici, je balance chaque élément sur un node qui renvoie à un autre flow parce que dans un seul flow (c'est chaque onglet dans NodeRed) si je fous la gestion de 15 telco et autres... Il me faudra un écran 8K et des yeux bioniques pour visualiser...

Si je regarde ton schéma avec le Switch Route Remote, ce que je comprends c'est:

Events_All capte tous les events, quand c'est une identity_id qui correspond à une des tes multiples remotes ça pard dans le Switch et suivant le point de sortie tu balances sur..un link out ? Mais y'a quoi dans le link out ? :D

[Daedaal]

C'est exactement ça.

Alors comme je n'avais pas créé ce flow pour illustrer, on ne le voit pas mais chaque link_out est unique (j'ai juste pas mis de label) et renvoie sur un link_in spécifique.

Un link_out par principe, il renvoie simplement sur un link_in ailleurs, dans un autre onglet (donc techniquement un flow différent mais à ce stade OSBLC) par exemple. Un raccourci qui transfère juste le message vers une autre page quoi.

Le link_in ce sont les nodes gris dans le second screen que j'ai appelé "remote 1", "remote 2".

Ça n'a pas d'intérêt pour toi pour l'instant. Tu peux tranquillou les ignorer et tu chaînes tes switchs tranquille dans ta page.

[theclaw]

Je dois être teubé mais comment ton link out peut(il renvoyer ailleurs, il n'a pas de sortie ? Et son seul paramètre c'est Name.

Ah ouais on peut le link, mais je fais de la merde ça marche pas

Attention WTF incoming:



A noter que quand j'active le On/off, ça marche, ça toggle, et ça m'affiche l'event state_changed. ET activer la remote bah ça m'affice bien le deconz_event

[Daedaal]

L'idée c'est que tu captes ce qui se passe (all_events), tu routes selon l'objet à l'origine de l'event (mon switch route_remote). Une fois que tu as aiguillé ton message, tu gère les autres paramètres comme quel bouton a été pressé (le switch "button press" d'un autre screen), ce qui te permet ensuite d'envoyer l'instruction que tu veux (study toggle par exemple).

Au final c'est simplement des petits pas pour d'abord sélectionner le périph, ensuite ce qu'il fait et enfin agir en conséquence. C'est très décomposé, mais ce sont des choses que j'ai fait en apprenant, exactement comme toi. Je ne me suis pas amusé à les optimiser pour faire avec le moins de nodes possible.

Pour le fun, ça doit être faisable avec 3 ou 4 nodes à coup de programmation en comparant non pas simplement un élément du message avec des valeurs prédéfinies mais en gérant tout d'un bloc ("telle telco+tel bouton => instruction"). Je ne vois pas l'utilité dans un processus pédagogique à part montrer qu'on peut faire des trucs très chiadés. Mais en même temps, ça marche pareil en décomposant.

Autre image peut-être plus parlante :

C'est une succession de IF j0r :

10 If A=1 Then goto 100
20 If A=2 Then goto 200
...
100 If B=1 then goto 1001
...
200 If B=2 then goto 2002
...
1001 print "coucou"
...

C'est absolument et totalement sub-optimal, mais OSEF à ce stade (le drain de perf est négligeable dans le cas qui nous concerne).

Mais oui, y'a moyen de faire un SELECT CASE à la place... Et plein d'autres choses.

Tout comme tu peux remplacer ton events_all filtré sur "state_changed" par un node trigger: state (utile pour les capteurs) ou un events: state...


NodeRed est un outil TRES puissant et TRES complet.
Il permet de faire des choses simples de manière graphique et d'accéder à des choses un peu plus complexes que les outils intégrés d'Hass. Tu peux faire les mêmes choses basiques en YAML, mais bon courage pour repérer que t'as un espace de trop dans une déclaration dans un fichier autre...

La raison pour laquelle je recommande toujours de l'installer et de l'utiliser c'est qu'il te permet de visualiser assez simplement ce que tu fais et de faire des trucs plutôt sympa sans taper de la prog trop complexe.

Derrière, le truc qui tourne reste l'IDE (environnement de développement) qu'IBM développe pour l'IOT. C'est un machin conçu pour gérer absolument n'importe quoi. De la lumière de tes chiottes à la conduite autonome de ta caisse (je plaisante à peine).
Je dois connaître 2% du bouzin et en utiliser 1%... D'où aussi une certaine difficulté à présenter les choses de manière pédagogique, et je suis navré de vous imposer ces pavés.

C'est simplement que JE pense que c'est le meilleur moyen d'aborder le sujet et un truc qui est facile à assimiler. C'est graphique, ça repose sur une logique relativement simple (aiguiller des messages comme des trains).
Y'a plein de gens qui n'utilisent pas cet outil et seulement ceux intégrés à Hass pour faire des trucs au delà de mes capacités.

- - - Updated - - -

Vire moi ces liens. Ils ne servent à rien dans ton cas. Juste à rendre le truc plus complexe pour le plaisir. (dans le link_in/link_out il faut spécifier la destination/respectivement la source. Cases à cocher.) Tire directement de ton switch à l'instruction. Ça marchera.

Le debug affiche les messages qui lui arrivent.
Relie le à tes sorties de switch, tu pourra voir ce qui passe par l'une ou par l'autre.

- - - Updated - - -

Si ton switch ne marche pas vérifie bien qu'il est sur le bon type de comparaison (le petit bouton avec marqué 1..2 ou a...z) Si tu compares en mode numérique deux textes, tu n'aura aucune chance que ça passe.

[Daedaal]

Ayé... il est lancé...

Qui arrêtera theclaw ?

[theclaw]

Mme theclaw:-)

[blueray]

Ok, j'ai trouvé cette video, d'un mec probablement du Kentucky

https://www.youtube.com/watch?v=o-vNCObJ4dM

Mais ça m'a vachement aidé

J'arrive à faire un node qui allume/éteint la lampe, un node qui dim+ de 10%, un qui dim- de 10%

\o/

- - - Mise à jour - - -

https://i.imgur.com/m4L4vuA.jpg

https://i.imgur.com/o1NtiTr.jpg

https://i.imgur.com/YcfHPXk.jpg

https://i.imgur.com/BeUeWZ7.jpg

Parfait ! Merci

[Daedaal]

Mme theclaw:-)

Avec la bonne comparaison, ça marche alors ?

[theclaw]

Avec la bonne comparaison, ça marche alors ?

Je pense qu'elle sera plus open minded lorsque j'arriverai à trigger l'aspirobot quand on est absents depuis plus de 10'

- - - Mise à jour - - -

L'idée c'est que tu captes ce qui se passe (all_events), tu routes selon l'objet à l'origine de l'event (mon switch route_remote). Une fois que tu as aiguillé ton message, tu gère les autres paramètres comme quel bouton a été pressé (le switch "button press" d'un autre screen), ce qui te permet ensuite d'envoyer l'instruction que tu veux (study toggle par exemple).

Au final c'est simplement des petits pas pour d'abord sélectionner le périph, ensuite ce qu'il fait et enfin agir en conséquence. C'est très décomposé, mais ce sont des choses que j'ai fait en apprenant, exactement comme toi. Je ne me suis pas amusé à les optimiser pour faire avec le moins de nodes possible.

Pour le fun, ça doit être faisable avec 3 ou 4 nodes à coup de programmation en comparant non pas simplement un élément du message avec des valeurs prédéfinies mais en gérant tout d'un bloc ("telle telco+tel bouton => instruction"). Je ne vois pas l'utilité dans un processus pédagogique à part montrer qu'on peut faire des trucs très chiadés. Mais en même temps, ça marche pareil en décomposant.

Autre image peut-être plus parlante :

C'est une succession de IF j0r :

10 If A=1 Then goto 100
20 If A=2 Then goto 200
...
100 If B=1 then goto 1001
...
200 If B=2 then goto 2002
...
1001 print "coucou"
...

C'est absolument et totalement sub-optimal, mais OSEF à ce stade (le drain de perf est négligeable dans le cas qui nous concerne).

Mais oui, y'a moyen de faire un SELECT CASE à la place... Et plein d'autres choses.

Tout comme tu peux remplacer ton events_all filtré sur "state_changed" par un node trigger: state (utile pour les capteurs) ou un events: state...


NodeRed est un outil TRES puissant et TRES complet.
Il permet de faire des choses simples de manière graphique et d'accéder à des choses un peu plus complexes que les outils intégrés d'Hass. Tu peux faire les mêmes choses basiques en YAML, mais bon courage pour repérer que t'as un espace de trop dans une déclaration dans un fichier autre...

La raison pour laquelle je recommande toujours de l'installer et de l'utiliser c'est qu'il te permet de visualiser assez simplement ce que tu fais et de faire des trucs plutôt sympa sans taper de la prog trop complexe.

Derrière, le truc qui tourne reste l'IDE (environnement de développement) qu'IBM développe pour l'IOT. C'est un machin conçu pour gérer absolument n'importe quoi. De la lumière de tes chiottes à la conduite autonome de ta caisse (je plaisante à peine).
Je dois connaître 2% du bouzin et en utiliser 1%... D'où aussi une certaine difficulté à présenter les choses de manière pédagogique, et je suis navré de vous imposer ces pavés.

C'est simplement que JE pense que c'est le meilleur moyen d'aborder le sujet et un truc qui est facile à assimiler. C'est graphique, ça repose sur une logique relativement simple (aiguiller des messages comme des trains).
Y'a plein de gens qui n'utilisent pas cet outil et seulement ceux intégrés à Hass pour faire des trucs au delà de mes capacités.

- - - Updated - - -

Vire moi ces liens. Ils ne servent à rien dans ton cas. Juste à rendre le truc plus complexe pour le plaisir. (dans le link_in/link_out il faut spécifier la destination/respectivement la source. Cases à cocher.) Tire directement de ton switch à l'instruction. Ça marchera.

Le debug affiche les messages qui lui arrivent.
Relie le à tes sorties de switch, tu pourra voir ce qui passe par l'une ou par l'autre.

- - - Updated - - -

Si ton switch ne marche pas vérifie bien qu'il est sur le bon type de comparaison (le petit bouton avec marqué 1..2 ou a...z) Si tu compares en mode numérique deux textes, tu n'aura aucune chance que ça passe.

Bon, tu m'as totalement perdu.

Déjà quand je vais sur Entities dans Hass, j'ai ça



Donc l'entity de la remote ça devrait être remote_judith_bedroom, ce que je vois dans le debug.

Donc du coup dans mon switch j'ai ça en 1 et une autre (remote_office) en 2.

J'ai mon service call pour faire juste toggle:



Donc mon flow donnne ça et évidemment c'est pas bon vu que la pression on/off donne rien, vu que, je pense, je dis pas ce qui doit déclencher le service call.



Du coup, ben je suis perdu

[Daedaal]

Balance les parms de ton switch.

C'est là que ça foire à mon avis.

[theclaw]

Param du Switch



- - - Mise à jour - - -

J'ai compris

payload.event.id...

- - - Mise à jour - - -

YES !!

- - - Mise à jour - - -

Bon, faut piger le changement de couleur maintenant

Et les dims up etc...

- - - Mise à jour - - -

Putain c'est beau

[Daedaal]

Quand je dis que c'est simple...

Regarde ce que tu as fait en quoi 2j ?
Aspi, t'occuper de ta fille, de ta compagne, la vaisselle (j'espère hein !). Le reste c'est du bonus temps libre...

- - - Updated - - -

Il y a de grandes chances que nous concluions ici les bases d'Hass et de NodeRed.

Notre ami theclaw aura montré la voie [insert Lotus Bleu] et j'ai comme un pressentiment qu'il va nous pondre des machins improbables comme les miens (et ceux des familiers déjà confortables avec l'outil) avant la fin du WE.

Que du bonheur et des lumières qui clignotent.

(Et un Daedaal égoïstement content d'avoir aidé et qui en a profité pour réviser un peu sa propre compréhensions du truc et se rendre compte qu'il est assez mauvais sur la pédagogie online sur un média j0r forum)

Que du bonheur je te dis !

[theclaw]

Ouais bon là j'ai pas fait des masses :-)

Il me faut un dimmer pour faire cycler les couleurs ?

[Daedaal]

Il me faut un dimmer pour faire cycler les couleurs ?

Nope, c'est dans les paramètres du mesage que tu envoie au "call service". Tu le gères comme tu veux avec tes events.

J0r

{"service":"turn_on","data":{"brightness_pct":1,"rgb_color":[255,5,5]}}

Même raisonnement qu'avant. Tu as un déclencheur, il suit le chemin prévu et prend les params que tu veux. Contente toi de les modifier dans le node d'action (service call).

Ne tente pas de courir avant de savoir marcher. Un pas après l'autre et tu fera des 100m à la Hussein Bolt avant même de t'en rendre compte. T'en fais pas vu ce que tu as déjà assimilé

[theclaw]

Donc ca c'est le code json ?

Je le pige pas entièrement

[Daedaal]

On reprendra demain après tes tests.
Y'a de grandes chances que le sujet décante pépouze.

[theclaw]

Un truc que je ne pige pas: là avec mon switch, quel que soit le bouton que je fasse ça toggle. Je pense savoir pourquoi: j'ai pas spécifié d'utiliser le bouton principal. Du coup quand je presse power on, je regarde ce qui sort au débug mais je ne sais pas quoi copier où

[theclaw]

TADAAA !!

https://i.ibb.co/6ZZygYz/Judith-Main.png

Alors c'est mochito en terme de prog, doit y'avoir moyen de faire plus propre avec des fonctions et tout, MAIS:

J'ai pour l'instant configuré la remote de la chambre de ma fille pour:

Power: toggle on/off.
Dim up et down: ça dim up et down de 10%
Flèche gauche: ça lui met du Pink
Flèche droite: ça lui met un vert qu'elle a appelé bamboo green

\o/

Seul hic, le vert ne marche pas bien:

On devrait avoir ça:

https://i.ibb.co/zfLnc1K/green.png

Et on a un espèce de jaune pisseux alors que l'autre jour quand je contrôlais depuis le même widget ou depuis Deconz c'était nickel (edit: du moins il me semble, je suis plus sur maintenant après une recherche google). Ca pourrait être la saturation mais je ne pense pas, toutes les autres couleurs rendent nickel (edit: sauf les light blue).

Autre chose: impossible d'identifier l'event lié à long press, sur n'importe quel bouton. Ca ne me sort que l'event du press (1002, 2002, 3002, 4002, 5002). Je vais tester 1003 (1xxx = bouton, xxx2 = comment on appuie). C'est chiant car je peux pas reset à blanc, ni cycler les couleur.

Edit: réglé le problème de revenir à blanc, j'ai ajouté un {"hs_color":[45,0]} dans le champ Data du on/off

Mais j'ai besoin des long press quand même. Voir double press, mais ça je pense qu'il faut mettre bout à bout 2 switches j'imagine (c'est mochito aussi )

[Daedaal]

Je t'avais dit que ça décanterait.

Pour ton vert, les ampoules couleur Ikéa sont assez merdiques dans leur rendu de cette couleur. Pas au point d'obtenir du jaune, mais il me semble que pour des raisons de coût ils travaillent en YCMK au lieu de RGB, donc pas de led verte c'est la combinaison de leds jaunes et cyan. Enfin c'est ce que j'en ait déduit d'une discussion avec un vendeur.



Sinon, tu peux aussi tenter de passer ta couleur en rgb_color: [0,255,0] au lieu d'utiliser hue/saturation (hs_color). Je trouve ça plus parlant.



Pour les appuis longs ou doubleclic, tout dépend de ce qui est implémenté dans ta telco.
Certaines n'envoie que le button press, d'autres un press et un release ou même un appui long (telco hue de mémoire). Si tu n'as que le press, tu peux gérer les clics multiples mais l'appui long...

En tout cas, encore une fois féloches (et condoléances ) : On est au milieu du WE et tu bidouilles pépouze pour obtenir le résultat que tu veux. J'ai hâte de voir ce que tu vas créer !

[franky4xa]

Bonjour à vous

Je vous lis avec intérêt depuis quelque jours, je regarde aussi un peu partout sur le net pour voir ce que je pourrais faire chez moi, et je me pose une question dont je ne trouve nulle part la réponse (certainement pas les bons mots clés dans ma recherche). Dans ma maison, tous les interrupteurs sont des interrupteurs classiques (aucun dimmer). Est-ce que les ampoules smart+ de Ledvance/Tradfri de IKEA/etc. intègrent le variateur dans le culot de l'ampoule, et peuvent être branchées sur ces interrupteurs classiques et commandées via hass.io, ou est-ce que je dois soit remplacer les interrupteurs, soit mettre un module dimmer entre l'interrupteur et l'ampoule? Je pense que c'est la première solution, et que je n'ai besoin de rien d'autre que l'ampoule connectée et de hass.io, mais avant de faire les investissements, je préfère être sûr.

Merci d'avance pour l'aide

[theclaw]

Ma solution :

Tu prends un ampoule chez ikea, tu testes, si ça va pas tu la retourne :-)