Lazer

J'allais te dire qu'il faut utiliser urlencode()

Je ne suis pas certain de bien comprendre... mais self.properties.xxx ne fait pas l'affaire ?

Ce n'est pas une instruction, mais c'est disponible via l'API HTTP, donc au travers de api.get() /api/settings/network

On a reçu le même email J'aime bien leurs nouvelles pubs, ils se mettent à faire un peu d'humour

Ah batterie rechargeable je suis moins fan par contre Je pensais aux Aeotec Door Window Sensor v7, j'en ai 3 comme ça, et ils sont bien à pile. Même form-factor que les Fibaro, et présence du bornier pour contact sec (je les utilise dans mes capteurs d'alarme)

Commande le 30/11, livraison le 17/12 Donc ça fait 17 jours. C'est long, mais : - j'ai commandé en sachant que c'était hors stock et qu'ils annonçaient environ 1 semaine de délai - lorsque le colis est passé chez le transitaire mailbox.de, je n'avais pas provisionné mon compte à l'avance, donc le colis n'est reparti que le lendemain alors qu'il aurait pu partir le jour même - le camion GLS a été ralenti en passant près de chez mprinfo, sérieusement il y a 1 jour de mystère dans le suivi entre l'Allemagne et la France (ils ont surement été débordés par les commandes de Noël) Donc de toute façon je suis très content, et je ne suis pas pressé, c'était surtout un achat opportuniste. Pendant ce temps là j'ai fait une commande cette semaine sur Amazon qui m'a été livrée en 15 heures ! Sachant qu'il y avait la nuit au milieu, ça carbure

Oui j'ai fusionné les sujets Pas de chance, oui ils sont de très vielle génération. Les Door Window Sensor v2 sont bien mieux : bonne tenue de la pile, capteur de T° intégré. Mais ils n'ont plus de contact sec. Ou bien l'équivalent chez Aeotec, qui eux disposent bien du contact sec (utile pour certaines utilisations détournées)

Oui l'objectif c'est de profiter de la migration à venir pour remplacer tous les modules de 1ère génération qui ne savaient pas mesurer la consommation. Donc principalement des dimmers, et quelques relais. Et les smart implant parce que la possibilité de piloter les 2 sorties, c'est juste génial, j'ai envie d'en mettre partout Et ça sera plus pratique pour le grand basculement, ça fera tout ça de modules que je pourrai inclure à l'avance, et pré-configurer les paramètres. PS : tu comprends l'intérêt de l'assurance transport à 1000€ avec GLS versus Modialrelay....

J'ai reçu ma belle commande, comme je le disais sur le topic des numéros de série, c'est du flux tendu, la HC3 a été fabriquée le 28/11, et j'ai même des modules (les Dimmer 2) qui sont du 30 novembre ! Ils doivent avoir un sacré volume de vente chez Proshop.... faut dire qu'avec les tarifs qu'ils ont fait pour le Black Friday, ils ont dû passer quelques palettes de modules. Vous avez vu, depuis fin novembre, les nouveaux modules Fibaro ont un emballage "écologique", et plus compact. Ils ont supprimé le film cellophane et le plastique, et je suppose que c'est du carton recyclé. Comme Nodon le fait depuis longtemps.

Regarde en première page, à l'époque j'avais donné la solution qui fonctionnait pour moi. Sinon.... bah.... je sais pas J'ai fini par totalement virer ces modules, ce sont les plus vieux module sur batterie de Fibaro, ils vident les piles à vitesse grand V (je n'ai jamais tenu plus de 7 mois), et le firmware buggué sur la remonté du niveau de piles, c'est bien pénible.

HC3 : 13700 Date d'achat : 30/11/2020 (commande hors stock) Date de fabrication : 28/11/2020 C'est ce qu'on appelle du flux tendu

Vieux bug.... Tente une "interrogation du module" (ou qqch comme ça dans l'onglet de propriété du module sur la HC2) puis fait un réveil du module (il faut ouvrir le capot, et triple cliquer sur le bouton)

Email de Diagral reçu ce jour : Je pressentais depuis longtemps que ça allait arriver tôt ou tard. Diagral n'a de toute évidence aucune intention de mettre à jour son site Web pour abandonner l'utilisation de Flash et utiliser HTML 5 à la place. Quant à l'application mobile, qui n'est plus maintenue depuis longtemps, elle continuera de fonctionner tant qu'une mise à jour d'Android ne rompra pas la compatibilité..... Bref, cette attitude de Diagral est lamentable, on est encore une fois face à une situation obsolescence programmée liée à tous les services dépendants du Cloud. Dites vous bien que même leur plus récente centrale e-One sera soumise à la même obsolescence d'ici quelques années. Pour ma part, je remettrai pas un centime là-dedans. Même si leur alarme fonctionne très bien en tant qu'alarme, Diagral n'est clairement plus une marque à recommander pour quelqu'un qui cherche une solution connectée pérenne, interopérable ou non avec la domotique. Le seul salut, ce sont les alarmes professionnelles, avec module d'entrée/sortie contact sec, on peut traiter l'information comme on veut, et indépendamment de tout service connecté.

Absolument, j'ai envie de dire qu'il faut "obligatoirement" vérifier l'existence éventuelle de chaque Child avant de créer le nouveau. Sinon ça va être l'horreur quand l'utilisateur va cliquer frénétiquement sur le bouton. Et faut pas espérer toucher les allocs ou la carte famille nombreuse.... Je connais un seul moyen d'identifier chaque child de manière unique : en stockant un identifiant dans ses variables. Par exemples : - pour la station Netatmo, on y stocke l'ID unique attribué par Netatmo à chaque module. - pour un IPX800 ou un EcoDevice, je stocke l'identifiant du port d'E/S : R1, R2, .... D1, D2, .... A1, A2, .... etc - pour Surveillance Station : l'ID de la caméra donné dans l'API de Syno. - etc Extrait de code : -- On veut créer un child local exist = false for _, child in pairs(self.childDevices) do -- On test si le child existe déjà (ce test est totalement dépend de chaque QuickApp qu'on développe) if pinFullName == pinNames[dev.pinName].getPin(tools.getVariable(child, "pinName"), tools.getVariable(child, "pinNumber")) then self:debug("Child device #" .. tostring(child.id) .. " <b>" .. child.name .. "</b> already exists for pin <b>" .. pinFullName .. "</b>") exist = true break end end if not exist then -- OK on peut créer le child... end En fait cet extrait s'intègre dans une autre boucle qui parcoure elle-même la liste des enfants à créer. Le tout est dans une fonction appelée lors de l'appui sur un bouton du QA.

OK donc il fallait déconnecter le capteur externe. Ah.... la magie Fibaro

Pour compléter, cette méthode push() fait un peu plus que la simple ligne présentée dans l'exemple. Elle affiche des logs, réalise des tests de validité de la variable donnée, des éventuelles transformations (par exemple 1 et 0 deviennent true et false), etc Donc en pratique, j'utilise également cette fonction push() en interne dans le QuickApp. Par exemple, à chaque interrogation régulière (Polling) du périphérique distant, la propriété du module est mise à jour au travers de cette fonction. Il suffit de l'appeler de la manière suivante : self:push(value) Ou bien encore : for _, child in pairs(self.childDevices) do child:push(value) end Mais je m'en sert également pour mettre les modules en état mort si la connexion réseau est perdue : self:push(true, "dead") On fait ce qu'on veut après.... J'ai fait un tuto, oui en question sorte. Disons qu'une longue explication reprenant les bases me semblait nécessaire tant les discussions partaient dans tous les sens, sans vraiment comprendre le pourquoi du comment.

Certes oui, mais la transmission du mot de passe est inévitable. La technique que je donne (qui n'est pas la mienne évidemment), présente les intérêts suivants : - quand le mot de passe est compromis, l'attaquant n'a accès qu'à un nombre très très limité de ressources, puisqu'on applique la politique du "rien" par défaut, et on ajoute spécifiquement les droits nécessaires - le changement du mot de passe est très simple puisqu'un seul appareil (ou humain) est impliqué, sans devoir faire la tournée de X machines pour mettre à jour le-dit mot de passe Si tu veux limiter grandement les risques, c'est là que la HC3 devient intéressante, car tu peux faire du https, donc théoriquement inviolable. Encore faut-il que l'appareil client en face le supporte. Cela semble être le cas de l'IPX800 v4 en cochant la case SSL (je n'ai pas testé) Bon après on parle d'un réseau local personnel, qui n'intéresse aucun attaquant. Et quand bien même tu aurais ta box domotique sur un réseau d'entreprise, cible d'un attaquant, il a autre chose à faire de ta domotique, ce sont les données de ton serveur qui vont l'intéresser. Toujours est-il que la box domotique ne devrait jamais être exposée en direct sur Internet via une redirection de port, http ou https cela ne change rien, si la faille se situe dans le serveur Web (Apache, Nginx, Lighthttpd, etc). Ma box est derrière un reverse proxy filtrant analysant toutes les requêtes avec un firewall applicatif (WAF), lui-même situé en DMZ. C'est déjà mieux. De toute façon vu que Fibaro ne permet plus d'attaquer l'IP des Home Centers en direct depuis les applications mobiles, j'ai envie de dire, problème résolu, il n'y a plus guère d'intérêt à accéder à la box en direct. Bon tout cela est HS, devrait être sur un topic dédié, et de toute façon ça a déjà été dit plusieurs fois sur le forum.

Alors, voici la solution que je propose (je l'utilise dans mes différents QuickApps). Soit un QuickApp (dans le parent ou bien dans les enfants) qui expose la fonction suivante : function QuickApp:push(value, attribute) -- ... self:updateProperty(attribute or "value", value) -- ... end Rappel de sécurité : on commence par créer un utilisateur dédié sur la HC3, avec un mot de passe spécifique, et on lui donne les droits d'accès à ce QuickApp. Dans cet exemple, l'utilisateur s'appellera "IPX800" et le mot de passe "Password" (c'est mal ) On va ensuite configurer l'appareil distant pour qu'il puisse accéder à l'API HTTP afin d'appeler la fonction push() en passant les arguments en paramètres. Note : la suite n'a rien de spécifique aux QuickApps ou à la HC3, c'était déjà comme cela sur la HC2 (et donc la HC-Lite) pour n'importe quel module Z-Wave, Plugin, Module Virtuel, Scène, ... bien sûr ils n'ont pas de fonction push(), mais des fonctions turnOn(), pressButton(), etc. Dans cet exemple on partira du principe que le module porte l'ID 123. Avec une requête de type GET : /api/callAction?deviceID=123&name=push&arg1=1 L'argument prend ici la valeur "1", mais ça pourrait être n'importe quel nombre, chaine de caractère, valeur binaire true/false, etc.... ce qui compte, c'est qu'on sache interpréter cette valeur, et surtout qu'elle corresponde au type de la propriété value du QuickApp. Remarque : ce n'est PAS la méthode recommande par Fibaro, et elle n'est d'ailleurs plus documentée. Elle est conservé pour des raisons historiques, car c'était l'API initialement disponible dans la v3 de la HC2 (et peut être même la v1.... j'en sais rien je n'étais pas né ) Cela dit elle nous arrange bien, car la méthode GET a l'avantage d'être totalement universelle, c'est à dire qu'elle fonctionne aussi bien dans la barre d'adresse de notre navigateur préféré, que depuis les appareils limités comme ceux proposés par GCE Electronics (malgré toutes leurs qualités) En pratique dans l'interface Web de l'IPX800 ça donne ça : on remarque qu'il y a 2 valeurs, selon si on fait un ON ou un OFF, c'est la seule différence entre les 2 requêtes : Avec une requête POST : /api/devices/132/push/1 Avec en données : {"args":[1]} Même remarque que précédemment, l'argument prend ici la valeur "1", mais ça pourrait être n'importe quel nombre, chaine de caractère, valeur binaire true/false, etc.... ce qui compte, c'est qu'on sache interpréter cette valeur, et surtout qu'elle corresponde au type de la propriété value du QuickApp. On peut aussi spécifier plusieurs arguments, séparés par des virgules. Remarque : c'est la méthode recommandée par Fibaro depuis la HC2 v4 et documentée dans le Swagger de la HC3 : /swagger?urls.primaryName=devices Inconvénient, elle est plus difficile à tester depuis un navigateur Web, car il faut utiliser une extension spécifique (Postman) En pratique ça donne ça avec une requête curl (depuis n'importe quelle ligne de commande Shell) : curl --request POST --user 'IPX800:Password' --data '{"args":[1]}' http://192.168.1.1/api/devices/123 PS : tu es vraiment trop impatient, tu ne laisses même pas le temps de rédiger la réponse....

Merci pour le retour Autre information, j'ai vu sur le forum officiel que les tous premiers firmwares de cette tête thermostatique étaient tellement buggués qu'on ne pouvait pas faire la mise à jour si la tête n'était pas elle-même associée à une sonde de température externe (celle-là même qui est optionnelle)

Oui tu as le bug identifié par @971jmd quelques message plus haut (information perdue dans une pluie de message HS qu'il a posté.... .... pourtant j'ai déjà fait un peu de ménage) Bref, met à jour en version 7.11.

Le topic du QuickApp Surveillance Station n'est pas du tout le bon endroit pour en parler, car en l'occurrence on ne Push rien vers ce QA (c'est du polling pur) La fonction push() existe belle et bien, mais pour un usage purement interne au QA (même si elle est exposée donc accessible via l'API, quel intérêt à part foutre la grouille : forcer le statut d'une caméra qui ne correspond plus à son état réel.... ) Bref je sépare ton message pour créer un nouveau topic de discussion général

Euh.... j'espère que personne ne met son mot de passe admin sur les autres appareils que la HC2/HC3 elle-même. TOUJOURS créer des utilisateurs dédiés, avec mot de passe spécifique, et droits restreints aux seuls et uniques modules pouvant être accédés en lecture/écriture. C'est bien simple, chaque appareil devant se connecter sur la box domotique dispose de son propre compte qu'il ne partage avec aucun autre. Exactement comme pour un humain (chacun son compte sur l'application mobile de son smartphone) Cette règle est valable tout le temps, pas que pour la box domotique : sur le NAS Synology/QNAP, Unifi Controller, etc... Pratique de sécurité de base Après pour les sockets, ouais .... ça fait du boulot en plus, pour un truc qui ne fonctionne qu'avec l'IPX800, ça teste un palliatif, comme dit, ça ne vaut pas les vrais Websockets standardisés.... Bref on verra plus tard, déjà faire en sorte que ça fonctionne.

Une seule bonne raison : quand tu partages un QA à la communauté, c'est un peu pénible d'aller expliquer aux gens qu'ils vont devoir aller configurer autant de règle Push sur leur IPX qu'il y a d'entrées/sorties à gérer. Mon QuickApp est compatible avec les 2 : - le pull : interrogation régulière de l'état de toutes les E/S - le push : réception du changement par le biais de l'API et de la fonction push() Ainsi, cela permet de couper la poire en 2 : je configure des Pushs pour toutes les E/S pour lesquelles j'ai besoin d'instantané : les relais, les entrées numériques Et du pull pour le reste (typiquement les capteurs analogiques, les pinces ampèremétriques, etc). Remarque que les E/S citées en Push sont également gérées par le Pull (au cas où on aurait raté un Push, on ne sait jamais) Si on pouvait avoir des WebSockets sur les produits GCE, ça résoudrait tous les problèmes de Push. La solution de @jjacques68 est un intermédiaire, par le biais de la socket TCP laissée ouverte. C'est plus léger et rapide que le protocole HTTP (qui est basé sur TCP lui aussi, mais bien bien lourd)

Oui mais non parce que le QuickApp Surveillance Station a un seul type de child : le type "com.fibaro.binarySwitch". Je n'allais quand même pas utiliser plusieurs classes différentes alors que tous les children sont du même type. @jjacques68 oui la connection via socket TCP en direct c'est plus léger que l'API HTTP. Malheureusement l'implémentation sur l'EcoDevice RT2 est totalement bugguée à la limite de l'inutilisable. Comme mon QuickApp se veut générique GCE Electronics (IPX800 v4, EDRT2, et on peut espérer l'IPX800 v5 si l'API ne change pas), j'ai donc choisi de n'utiliser que l'API HTTP. En fait ce que tu fais, c'est une sorte de WebSockets... il se trouve que la HC3 sait maintenant gérer les WebSockets, mais ce n'est pas le cas des appareils GCE. L'avantage des WebSockets c'est que c'est standardisé, et cela permet de laisser ouvert un canal de communication permanent entre 2 appareils, et la remonté instantanée d'information (changement d'état), sans nécessiter une reconnexion régulière (lourde) avec interrogation des données (le plus souvent pour rien). Les appareils proposant un serveur WebSocket sont encore relativement rares... chez moi j'ai Kodi (la prochaine version de mon QuickApp les exploitera), il y a aussi le logiciel Unifi Controller, mais l'API n'est pas officiellement documentée... bref c'est HS ici. Remarque : quand je parlais de ma fonction push() pour pousser les valeurs depuis un appareil externe, ça n'a évidemment rien à avoir avec le topic présent qui est censé parler des modules enfants. C'est générique à n'importe quel QuickApp, même sans enfant. Bon comme il se trouve que les enfants ont aussi besoin d'être mis à jour, du coup le push() a quand même sa place ici

@jjacques68 Je ne sais pas encore exactement ce que va faire @MAM78, donc je ne m'avance pas, je donnais juste des conseils sur la bonne pratique. Perso pour mon IPX, vu qu'il y a divers types de modules enfants (capteurs, actionneurs..... et que les actionneurs peuvent se subdiviser en différents types (binary, multilevel, etc), j'utilise plusieurs classes afin de coller au plus proche des spécifications Fibaro. La classe dédié à tous les capteurs est la plus basique, elle n'expose aucune fonction liée aux actions (pas de turnOn, etc) Donc basiquement, il y a uniquement le constructeur : function MyInput:__init(device) En pratique, j'ajoute une fonction perso (et c'est valable sur toutes mes classes, que ça soit un capteur, un actionneur, etc), permettant de pousser la valeur depuis un device externe. Typiquement depuis un événement Push sur l'IPX800 ou l'EcoDevice : function MyInput:push(value, attribute) En ce qui concerne la classe dédiée aux actionneurs de type binary, on va trouver les 2 méthodes décrites précédemment, plus les méthodes liées aux actions devant (=obligatoirement) être publiées via l'API : function MyDigitalOutput:__init(device) function MyDigitalOutput:push(value, attribute) function MyDigitalOutput:turnOn() function MyDigitalOutput:turnOff() Bien sûr, un programmeur faignant pourrait se dire que qui peut le plus peut le moins, et qu'il suffit d'utiliser la classe "MyDigitalOutput" de cet exemple pour tous les modules enfants, qu'ils soient de type capteur, actionneur, etc. Au pire, un capteur aura des méthodes turnOn et turnOff qui ne seront pas utilisées. Personnellement, je n'ai pas fait ce choix là, car je trouve cela "sale". Donc je sépare les types de modules dans des classes différentes. @MAM78 OK dans ce cas pour l'API, tu peux utiliser la doc officielle, pour une fois que Fibaro a parfaitement documenté son API, faut en abuser Le Swagger est accessible sur l'adresse IP de ta box /swagger Mais je t'ai déjà répondu dans mon précédent message avec l'API à utiliser. Comme tu peux le voir, c'est une requête de type POST, et l'IPX800 v4 ne permet pas cela (en fait on peut faire du POST, mais sans data c'est totalement inutile, et GCE refuse jusqu'à présent d'ajouter cette possibilité... je pense que le hardware limité de l'IPX800 v4 ne le permet pas) C'est justement la raison pour laquelle j'ai une fonction child:push() dans toutes mes classes enfants, cela me sert à double titre : - pousser la valeur depuis un appareil externe (IPX800, etc) - mettre à jour la valeur depuis le QuickApp lui-même (utilisation d'un code commun) Ma fonction push() fait quelques bricoles (que tu pourras étudier en détail quand je partagerai mon code), mais en synthèse il y a une seule ligne utile : function MyDigitalOutput:push(value, attribute) -- ... self:updateProperty(attribute or "value", value) -- ... end Tu noteras la possibilité de mettre à jour par défaut la "value" du device, mais on peut spécifier n'importe quoi, donc ça peut être batterylevel, power, energy, state, etc, etc