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

**Nortifer** · 22/11/2020, 18h47

Je continue mes expérimentation et comme je bloque toujours sur mes ampoules Lexman, j'ai attaqué mes modules fils pilotes Enocean.

Avec les logs j'ai sniffé ce qu'envoie ma box Leroy Merlin quand je change de mode de chauffage et j'ai déchiffré la commande envoyée :
05:15:76:E0->05:88:9D:D2 (-55 dBm): 0x01 ['0xd2', '0x8', '0x1', '0x5', '0x15', '0x76', '0xe0', '0x80'] ['0x0', '0x5', '0x88', '0x9d', '0xd2', '0x37', '0x0']

05:15:76:E0 = '0x5', '0x15', '0x76', '0xe0' = l'ID de la box leroy merlin, commun à toutes les commandes
05:88:9D:D2 = '0x5', '0x88', '0x9d', '0xd2' = l'ID du module fil pilote ciblé
'0xd2', '0x8', '0x1' = le mode sur lequel passé (0x0 = off, 0x1 = confort, 0x2 = eco, 0x3 = hors gel)
Et quelques bricoles que j'identifie pas trop

Maintenant que j'ai ces infos, comment je peux "forger" mes commandes ?
Dans la doc Enocean y a pas ce type de composants pour les déclarer dans le yaml.

EDIT : j'ai peut être une piste ici : https://forum.home-assistant.lu/t/qu...ote-zmnhjd1/77

**Daedaal** · 22/11/2020, 19h22

Lance NodeRed.

Sérieux. Tu te fais chier avec des logs.

Tu crée un flow de base qui choppe tous les events et qui les balance sur un debug.
Tu aura du log en temps réel sur tout ce qui se passe dans ton installation.

Pour chopper l'état, y'a aussi un node qui devrait te permettre de récupérer le truc.

Une fois que tu es passé dans l'écosystème NodeRed, tu devrais pouvoir manipuler ça sans trop de soucis.

Tes ampoules Lexman, c'est la marque blanche de leroy. Sans connectivité c'était déjà pas fameux, autant dire que c'est sans doute pas toi qui te foire mais ton HW. Limite j'ai envie d'en acheter une rien que pour voir les dégâts. Les Tradfri d'Ikea sont déjà du low cost mais alors je soupçonne que du lexman on va encore taper en dessous.

(désolé, c'est un dimanche "sans" pour moi. Je ne vais pas beaucoup aider plus que ça vu que je ne connais pas ton système)

**Nortifer** · 22/11/2020, 20h25

Pas de soucis ! Rien que mettre mes pensée par écrit ça me permet de mettre de l'ordre dans celles ci.
Je vais creuser node red, je pensais que c'était "que" un mécanisme de workflow graphique mais visiblement ça serait plus que ça.

Pour mes Lexman ce qui m'intrigue c'est ce topic Jeedom ou le mec dit que deconz les voit très bien.

**theclaw** · 22/11/2020, 20h38

NodeRed c'est intimidant au début, mais YT est ton ami.

Mon conseil, démarrer avec un truc ultra simple genre "j'appuie sur on, ça allume la lumière en chaud s'il est après 23H00"

**scie_sauteuse** · 23/11/2020, 09h44

Le conseil de theclaw est très bon en général : quand tu intègres un nouveau truc, que ça soit matériel ou non, commencer simple et complexifier petit à petit au fur et à mesure que la compréhension et la connaissance du bouzin progresse. Sinon c'est facile de mal partir et d'arriver à rien.

**theclaw** · 23/11/2020, 10h03

Et de paniquer

**Nortifer** · 23/11/2020, 10h12

Je me suis trouver un petit tuto : https://www.juanmtech.com/get-starte...ome-assistant/
Je vais déjà essayer de reproduire l'automatisation (qui marche) avec mon bouton : Si j'appuie sur le 0 du bouton ça allume mon ampoule 1, sur le 1 j'allume mon ampoule 2.

J'hésite un peu a voir pour revendre une partie de mon équipement existant pour reprendre des trucs plus facilement compatible. Les ampoules Lexman j'ai assez peu d'état d'ame, y en a pour 60€ en tout et c'est facilement remplaçable.
Par contre quelqu'un utilise des modules de contrôle de fil pilote pour le chauffage ? Ca j'ai déjà un peu plus d'investissement et j'ai pas vu beaucoup de choix.

**Daedaal** · 23/11/2020, 18h29

Il a l'air pas mal ce tuto.
Je peux aussi te conseiller https://diyfuturism.com/

J'abonde l'opinion des deux du dessus : Commencer simple. L'outil est très (TRES) complet et puissant, c'est viteuf de se paumer dans toutes les possibilités (je dois en connaître 5% et en utiliser 2%).

Pour moi, le premier truc à mettre en place -avant même des boutons- c'est un nœud de debug. De toute façon des noeuds débug, tu vas passer ton temps à en utiliser.

Tu peux importer directement le code ci-dessous (avec un copié/collé - fonction import de NodeRed). Il va te créer un node de captation de tous les events et les balancer dans la fenêtre de debug.

Spoiler Alert!

Ça te permettra de voir sous la jupe de NodeRed et de Hass en exposant tous les événements et leur structure.

Dans le principe :
- NodeRed fonctionne a base de messages. Un message, c'est chaque entrée que tu vois dans la fenêtre de debug.
- Ces messages contiennent de l'information. N'importe quel type d'information.
- Puisqu'on ne sait pas a priori quelle information va être dans le message, chaque info contient une clé (qui dit ce qu'elle est) et une valeur. Par exemple "couleur" = "Bleu"
- Elle est structurée de manière hiérarchique sous la forme d'une arborescence. Ça évite de se répéter. Par exemple pour la couleur bleue :

Code:

couleur RGB :
  - R = 0
  - G = 0
  - B = 255

- NodeRed te donne les outils nécessaire pour capter ces messages, les modifier et les router jusqu'à une destination qui va les exploiter.
* tu as des nodes qui génèrent un message (comme "events: all")
* tu as des nodes qui utilisent un message pour déclencher une action (comme "call service")
* tu as des nodes qui routent un message en fonction de paramètres (comme "switch")
* tu as des nodes qui modifient un message (comme "change")

L'idée c'est de partir d'un node qui génère un message et d'acheminer ce message jusqu'à un node qui va l'exploiter.
C'est très graphique (et ça correspond bien à ma manière de penser) : Tu prend un courrier (notre message), tu regardes le code postal qui te dit vers quelle ville l'envoyer, puis l'adresse qui te dit à quel facteur la distribuer, puis le facteur regarde le nom, la met dans la boîte aux lettres de destination et enfin le destinataire l'ouvre et agit en fonction du contenu.

NodeRed c'est la même chose.
C'est fondamentalement simple : Tu suis le trajet de ton message en tirant des traits entre chaque node et tu l'amène jusqu'à l'endroit kivabien.

Le plus gros problème que tu vas rencontrer n'est pas vraiment de router le message, mais de formuler ce que tu veux faire. Le reste en découlera pépouze. Tu peux remonter dans le topic pour voir a quelle vitesse notre theclaw s'est approprié le bouzin.

Si je devais former à l'utilisation de NodeRed en domotique, je commencerais certainement avec un papier et un crayon pour faire décomposer un but (allumer telle ampoule dans telle couleur à telle heure) dans les différentes étapes nécessaires :
- Chopper l'appui sur un bouton ("events: all", filtré)
- Déterminer quelle telco a été utilisée ("switch" en fonction de la telco)
- Déterminer quel bouton est appuyé ("switch" en fonction du bouton)
- Choisir la couleur en fonction de l'heure ("switch" spécifique "time range" en fonction de la valeur de l'heure)
- Envoyer l'instruction d'allumage à la bonne ampoule avec la bonne couleur ("call service")

Pour tes ampoules Lexman... Si tu arrives à les faire fonctionner, tu peux aussi les garder pour des utilisations qui ne nécessitent pas une grosse qwalitance de lumière. J'ai gardé mes Tradfri (et la restitution de couleur est une purge) pour les endroits dans lesquels je me fous de la qualité de restitution de la lumière. J0r mes chiottes (oui, theclaw ! Encore mes chiottes. Un jour tu les visitera...

), un placard, des tests...

**Nortifer** · 23/11/2020, 21h17

Merci pour le coup de main.
J4avais effectivement pas bien compris le principe du payload en premier abord.

Deux petites questions sur le noeud de debug :
- Y a moyen de filtrer les retours ? Je suis pas mal pollué par des évènements de mon routeur qu'il a détecté tout seul (bon que j'ai supprimé du coup, ça va pas me servir tout de suite)
- Il ne détecte que les évènements généré par home assistant ? Par exemple je vois bien mon bouton déjà intégré dans home assistant, mais pas les informations de changement d'état de mes fils pilotes (que je vois dans les logs de home assistant)

**Daedaal** · 23/11/2020, 21h43

Tu peux filtrer dans la captation des events en renseignant event_type. Si tu ne veux chopper que Deconz, bien tu copie colle l'event type que te donne la fenêtre de debug, en l'occurence "deconz_event"

Pour les changements d'état, tu vas utiliser un trigger: state en renseignant l'ID de l'entité que tu cherches à monitorer. Le node émettra un message à chaque changement d'état.

Ici je surveille (un de) mes capteurs de présence. Un message part quand ils sont activés (présence détectée) ou qu'ils se désactivent (pas de présence pendant 60s - retour en mode "off").

Un event c'est une action réalisée (appuyer sur un bouton). C'est envoyé au système au moment où elle arrive. Quand tu ne touche pas au bouton, ben y'a pas d'état.

Un state c'est un état (température de x°C). C'est toujours dispo, mais ça enregistre les changements et peut donc générer un truc (state changed) lorsque l'état évolue.

**Nortifer** · 23/11/2020, 22h01

Le truc c'est que mes modules fils pilotes sont pas encore déclaré comme identité dans HA.
Bon je vais déjà m'amuser avec mon bouton et une ampoule, on attaquera ce chantier plus tard

J'essaye de comprendre comment fonctionne le node "switch".
La j'ai bien un node "all event" filtré sur "button_pressed" qui détecte bien quand j'appuie sur mon bouton.
Maintenant j'essaye avec le switch de détecter quand dans cet event j'ai un "onoff: 1" ou un "onoff: 0" et en fonction allumer l'ampoule 1 ou l'ampoule 2

Je suis sur cette piste :

Spoiler Alert!

Code:

[
    {
        "id": "1e854fc5.7357a",
        "type": "switch",
        "z": "e1740332.c53fa",
        "name": "switch",
        "property": "payload",
        "propertyType": "msg",
        "rules": [
            {
                "t": "cont",
                "v": "\"onoff: 0\"",
                "vt": "str"
            },
            {
                "t": "cont",
                "v": "\"onoff: 1\"",
                "vt": "str"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 350,
        "y": 240,
        "wires": [
            [
                "a5584745.6c20b8",
                "7794e59d.e8f68c"
            ],
            [
                "80508537.307178"
            ]
        ]
    },
    {
        "id": "a5584745.6c20b8",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "Allumer hue 1",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": false,
        "service_domain": "light",
        "service": "toggle",
        "entityId": "light.hue1",
        "data": "",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 570,
        "y": 200,
        "wires": [
            [
                "7ca31e9b.0cfba"
            ]
        ]
    },
    {
        "id": "80508537.307178",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "Allumer hue 2",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": false,
        "service_domain": "light",
        "service": "toggle",
        "entityId": "light.hue_color_lamp_2",
        "data": "",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 570,
        "y": 280,
        "wires": [
            [
                "b82161e9.a3f0c"
            ]
        ]
    },
    {
        "id": "7ca31e9b.0cfba",
        "type": "debug",
        "z": "e1740332.c53fa",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 790,
        "y": 200,
        "wires": []
    },
    {
        "id": "b82161e9.a3f0c",
        "type": "debug",
        "z": "e1740332.c53fa",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 790,
        "y": 280,
        "wires": []
    },
    {
        "id": "e2e003a.30fd5",
        "type": "server-events",
        "z": "e1740332.c53fa",
        "name": "",
        "server": "5b460a6c.c0a2c4",
        "event_type": "button_pressed",
        "exposeToHomeAssistant": false,
        "haConfig": [
            {
                "property": "name",
                "value": ""
            },
            {
                "property": "icon",
                "value": ""
            }
        ],
        "waitForRunning": true,
        "x": 140,
        "y": 240,
        "wires": [
            [
                "1e854fc5.7357a"
            ]
        ]
    },
    {
        "id": "7794e59d.e8f68c",
        "type": "debug",
        "z": "e1740332.c53fa",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 390,
        "y": 120,
        "wires": []
    },
    {
        "id": "5b460a6c.c0a2c4",
        "type": "server",
        "name": "Home Assistant",
        "addon": true
    }
]

- - - Mise à jour - - -

Ah bah il me suffisait d'écrire pour piger

Spoiler Alert!

Code:

[
    {
        "id": "1e854fc5.7357a",
        "type": "switch",
        "z": "e1740332.c53fa",
        "name": "switch",
        "property": "payload.event.onoff",
        "propertyType": "msg",
        "rules": [
            {
                "t": "cont",
                "v": "0",
                "vt": "str"
            },
            {
                "t": "cont",
                "v": "1",
                "vt": "str"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 350,
        "y": 240,
        "wires": [
            [
                "a5584745.6c20b8"
            ],
            [
                "80508537.307178"
            ]
        ]
    },
    {
        "id": "a5584745.6c20b8",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "Allumer hue 1",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": false,
        "service_domain": "light",
        "service": "toggle",
        "entityId": "light.hue1",
        "data": "",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 570,
        "y": 200,
        "wires": [
            [
                "7ca31e9b.0cfba"
            ]
        ]
    },
    {
        "id": "80508537.307178",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "Allumer hue 2",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": false,
        "service_domain": "light",
        "service": "toggle",
        "entityId": "light.hue_color_lamp_2",
        "data": "",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 570,
        "y": 280,
        "wires": [
            [
                "b82161e9.a3f0c"
            ]
        ]
    },
    {
        "id": "7ca31e9b.0cfba",
        "type": "debug",
        "z": "e1740332.c53fa",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "auto",
        "x": 790,
        "y": 200,
        "wires": []
    },
    {
        "id": "b82161e9.a3f0c",
        "type": "debug",
        "z": "e1740332.c53fa",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 790,
        "y": 280,
        "wires": []
    },
    {
        "id": "e2e003a.30fd5",
        "type": "server-events",
        "z": "e1740332.c53fa",
        "name": "",
        "server": "5b460a6c.c0a2c4",
        "event_type": "button_pressed",
        "exposeToHomeAssistant": false,
        "haConfig": [
            {
                "property": "name",
                "value": ""
            },
            {
                "property": "icon",
                "value": ""
            }
        ],
        "waitForRunning": true,
        "x": 140,
        "y": 240,
        "wires": [
            [
                "1e854fc5.7357a"
            ]
        ]
    },
    {
        "id": "5b460a6c.c0a2c4",
        "type": "server",
        "name": "Home Assistant",
        "addon": true
    }
]

Je m'amuse comme un ptit fou.
Maintenant faire qu'il ne détecte que l'appui et pas appui ET relachement (niveau facile) et s'amuser à augmenter et baisser l'intensité , plutôt qu'allumer/éteindre (niveau intermédiaire)

**Daedaal** · 23/11/2020, 22h56

Envoyé par Nortifer

Ah bah il me suffisait d'écrire pour piger

Dans 99% des cas, ça se résume à ça.

Formuler le problème dans les "bons" termes. La complexité n'est que dans le fait qu'il y a souvent plusieurs manières d'arriver au même résultat.
Certaines plus flexibles, d'autres plus naturelles. Des méthodes simples, d'autres un peu plus chiadées.

Si tu regardes nos aventures avec theclaw sur les cubes, on a abordé le problème différemment. Et les deux solutions marchent.

Au final ce qui compte c'est que tu obtiennes le résultat escompté. Dans "nos" installations, ce n'est pas le flow NodeRed qui va foutre la grouille dans les perfs. Il compile en natif (enfin plutôt Hass bouffe la compil native de NodeRed) l'impact sur les perfs d'un flow plus ou moins bien optimisé c'est du flanc.

Mais exactement comme tu le dis, c'est plutôt fun à bidouiller. Rageant quand ça ne marche pas, mais ça finit toujours par marcher (merci le debug) et c'est quand même satisfaisant de résoudre un problème et de voir le résultat.

**Nortifer** · 24/11/2020, 18h17

Désolé de spammer, mais je continue mes exercices et je bloque un peu la.
Le but c'est de faire augmenter la luminosité de mon ampoule tant que je reste appuyé sur le bouton.
Pour ça je peux jouer sur le fait que mon interrupteur renvoie une variable différente sur l'appuie et le relachement du bouton (payload.event.pushed).

Je comprends que je dois partir sur un noeud type Traffic et lui dire "si payload.event.pushed == 1, on continue", si "payload.event.pushed == 0, on drop"

Spoiler Alert!

Code:

[
    {
        "id": "cb764af0.1981e8",
        "type": "server-events",
        "z": "e1740332.c53fa",
        "name": "",
        "server": "5b460a6c.c0a2c4",
        "event_type": "button_pressed",
        "exposeToHomeAssistant": false,
        "haConfig": [
            {
                "property": "name",
                "value": ""
            },
            {
                "property": "icon",
                "value": ""
            }
        ],
        "waitForRunning": true,
        "x": 240,
        "y": 780,
        "wires": [
            [
                "386c50bf.6eb54",
                "b9665b75.e33868"
            ]
        ]
    },
    {
        "id": "dd05e285.d2933",
        "type": "switch",
        "z": "e1740332.c53fa",
        "name": "switch",
        "property": "payload.event.onoff",
        "propertyType": "msg",
        "rules": [
            {
                "t": "eq",
                "v": "0",
                "vt": "str"
            },
            {
                "t": "eq",
                "v": "1",
                "vt": "str"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 2,
        "x": 950,
        "y": 760,
        "wires": [
            [
                "6a3f3f10.cde66"
            ],
            [
                "5b4507b5.435498"
            ]
        ]
    },
    {
        "id": "3bc44575.38deca",
        "type": "delay",
        "z": "e1740332.c53fa",
        "name": "",
        "pauseType": "rate",
        "timeout": "5",
        "timeoutUnits": "seconds",
        "rate": "1",
        "nbRateUnits": "1",
        "rateUnits": "second",
        "randomFirst": "1",
        "randomLast": "5",
        "randomUnits": "seconds",
        "drop": false,
        "x": 790,
        "y": 760,
        "wires": [
            [
                "dd05e285.d2933"
            ]
        ]
    },
    {
        "id": "386c50bf.6eb54",
        "type": "traffic",
        "z": "e1740332.c53fa",
        "name": "",
        "property_allow": "msg.payload.event.pushed",
        "filter_allow": "1",
        "ignore_case_allow": false,
        "negate_allow": false,
        "send_allow": false,
        "property_stop": "msg.payload.event.pushed",
        "filter_stop": "0",
        "ignore_case_stop": false,
        "negate_stop": false,
        "send_stop": false,
        "default_start": false,
        "differ": false,
        "x": 530,
        "y": 780,
        "wires": [
            [
                "3bc44575.38deca"
            ]
        ]
    },
    {
        "id": "5b4507b5.435498",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": false,
        "service_domain": "light",
        "service": "turn_on",
        "entityId": "light.cuisine",
        "data": "{\"brightness_step\":20,\"color_temp\":350}",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 1150,
        "y": 780,
        "wires": [
            [
                "386c50bf.6eb54"
            ]
        ]
    },
    {
        "id": "6a3f3f10.cde66",
        "type": "api-call-service",
        "z": "e1740332.c53fa",
        "name": "",
        "server": "5b460a6c.c0a2c4",
        "version": 1,
        "debugenabled": true,
        "service_domain": "light",
        "service": "turn_on",
        "entityId": "light.cuisine",
        "data": "{\"brightness_step\":-20,\"color_temp\":350}",
        "dataType": "json",
        "mergecontext": "",
        "output_location": "",
        "output_location_type": "none",
        "mustacheAltTags": false,
        "x": 1150,
        "y": 700,
        "wires": [
            [
                "386c50bf.6eb54"
            ]
        ]
    },
    {
        "id": "5b460a6c.c0a2c4",
        "type": "server",
        "name": "Home Assistant",
        "addon": true
    }
]

Sauf que déjà je dois mal configurer le truc puisse que mon noeud drop tous les messages, et en plus ça va pas marché parce qu'en fait j'ai deux messages qui circule, et pas un qui change à la volée.
J'essaye donc de regarder un noeud trigger:state, sauf que mon évènement n'est pas associé à un entity_id. Et la je sèche un peu sur comment faire.

**theclaw** · 24/11/2020, 18h27

Est-ce que ton inter est prévu pour envoyer un long press?

**Nortifer** · 24/11/2020, 18h46

Je pense pas d'après la doc :

EnOcean binary sensors have no state, they only generate ‘button_pressed’ events. The event data has following fields:

id: The ID of the device (see configuration).
pushed: 1 for a button press, 0 for a button release.
which: Always 0 when using the single rocket. 0 or 1 when using the dual rocket switch.
onoff: 0 or 1 for either side of the rocket.

**theclaw** · 24/11/2020, 20h28

Donc comme ça en natif tu pourras pas.

Par contre tu pourrais dire à node red d'attendre 1 sec pour voir si une autre commande est envoyée.

**mathwern** · 24/11/2020, 21h36

Y'aura pas d'autre commande si le seul truc généré c'est button_pressed?

**Daedaal** · 24/11/2020, 21h37

Envoyé par Daedaal

Un event c'est une action réalisée (appuyer sur un bouton). C'est envoyé au système au moment où elle arrive. Quand tu ne touche pas au bouton, ben y'a pas d'état.

Un state c'est un état (température de x°C). C'est toujours dispo, mais ça enregistre les changements et peut donc générer un truc (state changed) lorsque l'état évolue.

Je vais finir par le prendre personnellement quand à mes capacités pédagogiques...

Une telco ne peut pas envoyer un state. Elle n'en a pas. Son state ce serait quoi ? "on ne m'appuie pas sur le bouton" ?
[insérez ici une image NSFW]

Elle reçoit/transmet forcément des events. Des événements, ce qui lui arrive. Bouton pressé, bouton relâché, longpress, shortpress.

Ça dépend du hardware, de la manière dont elle est câblée. C'est comme pour tout. [et je vous jure que je me retiens de faire un parallèle sexiste]
Si elle n'est pas réceptive a un appui continu (c'est du HW), ben tu peux compter le nombre d'appuis comme le dit theclaw.

Dans tous les cas, ce ne sera jamais un état "bouton machin appuyé" mais un événement "on m'appuie sur le bouton (de telle ou telle manière)"

Certains inters (les classiques Hue à 4 boutons de mémoire) gèrent un appui et un relâchement. C'est à dire que tu vas avoir deux events "bouton appuyé" puis "bouton relâché". C'est gérable en créant une boucle dans NodeRed qui n'est interrompue que par l'event "bouton relâché". Ça me semble très foireux comme approche.

Par exemple, je gère des variations de luminosité avec mes cubes. C'est le fait de les tourner (donc encore une fois un event -rotation gauche/droite) qui génère un envoi de +/- x% de luminosité. L'état (state) du cube tant qu'il ne bouge pas... ben c'est... rien. Ils n'ont pas de position absolue/invariable en rotation sur eux-même. Tu peux (éventuellement) connaître la face active (c'est une valeur absolue donc un state), mais la rotation latérale n'existe que quand elle a lieu (c'est une valeur relative donc un event).

'faut que je trouve un moyen d'expliquer plus clairement la différence entre state et event. Désolé si pour le coup tu es un peu enduit d'erreur. Au fil du temps ça me parait naturel : un état (state) c'est quelque chose qui traduit ben... l'état de ton entité. C'est plus ou moins pérenne. Un événement (event) c'est quelque chose qui survient à un instant T mais "ne dure pas".

Un thermomètre affiche une température. C'est l'état. Elle change (donc captable avec trigger: state) mais elle n'est pas le résultat d'une action de ta part.
Si tu me mets un pain dans la tronche, c'est un événement (un event). Une action délimitée dans le temps. C'est captable avec un events: all. C'est l'action qui t'intéresse, pas son résultat (qui lui sera un state : Daedaal a une dent en moins).

Si vous avez d'autres idées d'explications qui n'impliquent pas de me prendre une baffe... Je suis ouvert aux suggestions.

**theclaw** · 24/11/2020, 21h40

Event: presser sur un bouton
State: lumière allumée

Merci, de rien.

**Daedaal** · 24/11/2020, 21h56

Envoyé par mathwern

Y'aura pas d'autre commande si le seul truc généré c'est button_pressed?

Non.

Les events envoyés dépendent du HW uniquement.
On peut les manipuler (type succession de button_pressed dans un timing) mais si ton entité n'envoie qu'un type d'info, tu ne peux pas lui demander d'en envoyer d'autres.

C'est valable aussi pour les états (states). Un thermomètre ne peut te renvoyer que la température. Un thermomètre/hygromètre te renverra température et hygrométrie. Un thermomètre/hygromètre/baromètre te reverra température, hygrométrie et pression atmosphérique.

Quand tu appuie sur un inter électrique physique. Il laisse passer le courant ou pas. Tu ne peux pas lui "dire" de tirer la chasse d'eau de tes chiottes à la place.

(ouais, je crois que je vais consulter pour cette histoire de fixation sur les lieux d'aisance

)

- - - Updated - - -

Envoyé par theclaw

Event: presser sur un bouton
State: lumière allumée

Merci, de rien.

Déjà tenté... Ça ne percute pas... "mais bouton appuyé c'est un state et lumière qui s'allume c'est un event alors"... Ben oui... mais non...

C'est très naturel une fois compris, mais je ne trouve pas le moyen pédagogique de le faire comprendre sans ambiguïté (ni métaphore avec mes chiottes).

Mais je soupçonne que tu aimes l'idée que je me prenne des baffes autant que celle de visiter mes chiottes. Tu viens consulter avec moi ? Je suis certain qu'on nous fera un prix de gros.

**theclaw** · 24/11/2020, 22h01

Qui est gros ?

**mathwern** · 24/11/2020, 22h28

Je voulais répendre à theclaw que comme l'event c'est button_pressed sans information de durée (les boutons Hue par exemple font la différence entre presset long_press) tu peux attendre autant que tu veux veux avec node red tu seras pas avancé pour autant

**theclaw** · 24/11/2020, 22h32

En fait si, je crois avoir vu sur une review du cube d'ailleurs, que tu peux temporiser avant d'envoyer le state change pour détecter si un autre button_pressed arrive.

**franky4xa** · 24/11/2020, 22h32

Ou alors, on l'imagine en binaire, j'appuie sur le bouton : ma variable passe à 1 (event). Je laisse mon doigt sur l'interrupteur : ma variable reste à 1 (state). Je relâche le bouton : ma variable passe à 0 (event). Je ne touche plus au bouton : ma variable reste à 0 : state. En tout cas, c'est comme ça que je me le représente.
Pour ton problème, Nortifer, mais je précise que je n'en suis pas encore là dans NodeRed, je vérifierais tous les x dixièmes de seconde si l'event "relâche le bouton" a eu lieu. S'il n'a pas eu lieu => augmentation luminosité. S'il a eu lieu : arrêt du changement de luminosité.

**theclaw** · 24/11/2020, 22h44

Non mais là vous pouvez imaginer tout ce que vous voulez, c'est pas comme ça que node red fonctionne. Donc vous allez au devant de grosses désillusions

Là le truc a 2 events possible: 1 ou 0 (push ou release).

C'est quoi comme type de matériel, j'ai pas suivi

**mathwern** · 24/11/2020, 22h51

Quand ca passe de 0 à 1 tu enregistres le timestamp dans une variable. Quand ca passe de 1 à 0 pareil et tu compares la durée entre les 2.

**theclaw** · 24/11/2020, 22h53

Ah bah je dis pas que c'est pas possible, juste que c'est plus dur de bosser avec 2 events comme ça.

**Daedaal** · 25/11/2020, 00h03

Envoyé par franky4xa

Ou alors, on l'imagine en binaire, j'appuie sur le bouton : ma variable passe à 1 (event). Je laisse mon doigt sur l'interrupteur : ma variable reste à 1 (state). Je relâche le bouton : ma variable passe à 0 (event). Je ne touche plus au bouton : ma variable reste à 0 : state. En tout cas, c'est comme ça que je me le représente.
Pour ton problème, Nortifer, mais je précise que je n'en suis pas encore là dans NodeRed, je vérifierais tous les x dixièmes de seconde si l'event "relâche le bouton" a eu lieu. S'il n'a pas eu lieu => augmentation luminosité. S'il a eu lieu : arrêt du changement de luminosité.

Oui, non mais oui. Et bienvenue ! Visiblement, on ne fait pas que des gaufres à Liège !

C'est ce que je (on) fait avec la détection de présence : Tu rentre dans ton chiotte. Pépouze, la lumière s'allume (détecteur de présence - state: detected. Tu le choppe avec un trigger_state et tu met la lumière kivabien.

Les détecteurs de présence se désamorcent au bout d'un temps (Ikea et Aqara c'est 60s) et repassent automatiquement en "non détecté". Tu choppes (toujours avec le même trigger: state) qu'il n'y a plus de présence détectée. Tu pourrais éteindre.
Sauf que t'étais en train de lire CPC sur ton trône et que t'essayais de comprendre les illustrations de Fishbone dans la partie HW. Tu n'a pas bougé pendant au moins 1min. Tu ne veux pas que ça s'éteigne... tu ne comprend pas le truc et t'essaye de trouver le rapport entre un lama qui chie sur un journal et le dernier driver Nvidia.

Au lieu d'éteindre sur le changement d'état, tu attends 1s dans ton premier flow (ou plus, là c'est une question d'usage et de transit intestinal) et tu re-teste le state de ton détecteur. Comme tu t'es facepalm en te rendant compte qu'il n'y a aucun rapport entre l'illustration et l'article, ton détecteur est passé de détecté (quand tu es rentré) à non détecté (son timeout HW) puis à détecté (ton facepalm).
Ton test sur son état -state donc- te dit qu'il y a toujours quelqu'un de vivant sur le trône.
Donc tu repars pour un cycle en gardant la lumière allumée jusqu'au prochain changement d'état.

Y'a aucun event dans le bouzin.

Dans ce que tu proposes, tu passes par une variable (c'est jouable sans soucis -j'utilise ça pour les cubes histoire de connaitre la dernière face connue, c'est juste un node "change" qui la définit. Y'a même pas besoin de la déclarer avant) qui va agir pour "transformer" ton event "j'appuie/je relâche le bouton" en state "variable = 0" ou "variable = 1".
Il faudra faire une boucle incrémentale en fonction non pas de l'event, mais du state de la variable. Et c'est le "state: change" de cette variable qui va rompre la boucle.

Oui c'est le bourdel tant que les deux choses ne sont pas comprises pour ce qu'elles sont. Dans un certain sens, elles se recoupent en permanence.
Y'a pas de state sur un bouton, mais tu peux récupérer son dernier event comme le dit mathwern. Mais le dernier event n'est pas un état. L'état c'est "appui"/"pas appui", donc limité dans le temps. Donc c'est un event.

La où je trouve que c'est foireux, ce n'est pas dans la méthode. Elle est -AMHA- tout à fait valable et cohérente. Et c'est d'autant plus cool que c'est un nouveau canard qui nous sort ça propre comme un cul de bébé, efficace. Rien à dire à part que ce topic vit et que c'est vraiment agréable ! Merci. Sincèrement.

Mais gérer la gradation progressive de la luminosité (par exemple, ça marche aussi pour le son ou toute autre variable continue) c'est chaud. Tel que je le vois, ça implique un feedback visuel. Si j'appuie en continu 5s sur le bouton, il faut qu'il se passe quelque chose pendant ces 5s. Sinon je ne sais pas quand le lâcher pour rester à la luminosité que je veux.
Je suis preneur de la méthode qui le permet (on va encore se taper du confinement donc...) et je réviserai sans doute mon opinion. Je considère le "call_service" comme un node de fin.
Sauf qu'en fait rien qu'en l'écrivant (coucou Nortifier

), je me rend compte que je dis n'imp. Tu peux le récupérer en sortie. Donc re-tester si l'appui est maintenu et boucler dessus.

Plus au prochain numéro, mais le topic a pris sa propre vie et c'est beau à voir. Les solutions seront sans doute là avant que je ne me réveille demain.

**Nortifer** · 25/11/2020, 10h00

Oui c'est clair la différence entre event et state.
La ou par contre ou je sais pas trop comment fonctionne Node Red avec plusieurs message.

La j'ai fait une boucle à la sortie du "call_service" et je vois bien mon ampoule s'allumer progressivement. Sauf que si j'essaye de l'éteindre, je la vois scintillé puisqu'il essaye alternativement de l'allumer et de l'éteindre vu qu'a aucun moment je lui ai indiqué de drop le message. J'ai donc les deux messages qui circulent.
Et c'est justement ça qui me bloque, je ne peux pas re-tester le premier message puisqu'il ne changera jamais, il faut qu'un deuxième message interrompe ma boucle
Je vais essayer avec une approche avec avant ma boucle un switch qui change une variable en 0 ou 1, et dans la boucle, mais j'ai pas vu de noeud pour stocker et lire une variable externe je vais creuser.

**scie_sauteuse** · 25/11/2020, 10h12

Pour la variable, selon ton besoin tu peux utiliser un input_boolean défini dans Hassio (pour pouvoir le manipuler dans Hassio), sinon tu peux définir des variables globales, ou locales au flow dans NodeRed, avec un noeud Change et l'action Set. Tu peux aussi te servir du noeud Change pour fixer des attributs à l'intérieur de ton message et ensuite checker ces attributs pour voir combien de fois ton message est passé par là par exemple. C'est peut-être pas le moyen de plus simple de faire une boucle mais dans certains use case ça doit pouvoir être utile.

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

Outils de la discussion

Règles de messages