SebDel

Bonjour à tous, Ce matin à 8h15, sans prévenir et alors que tout fonctionnait parfaitement depuis plusieurs jours, voir semaine, tous mes périphériques ont été mise à jour automatique par la box. Est ce que c'est une procédure habituelle ? Après le balayage complet, plus aucun périphérique ne répond et de plus les périphériques "type alarme" ce sont mis en alarme ! C'est un peu surprenant... Je n'ai pas trouvé de documentation sur le phénomène et comment l'éviter. Séb

Bonjour Steven, Mon projet tourne maintenant comme une horloge et j'attend encore un peu avant de passer à la version 4.xx. GEA.add({"Sensor-", id["BUR_ORDI_CONSO"], 50}, 5*60, "Arret Ordinateurs #value#", {{"Days","Weekday"}, {"Time", "18:00", "9:00"}, {"turnOff", id["BUR_ORDI_SW1"]},{"If", {{"Value+", id["BUR_ORDI_SW1"], 0}}}}) GEA.add({"Sensor-", id["BUR_ORDI_CONSO"], 50}, 5*60, "Arret Ordinateurs #value#", {{"Days","Weekend"}, {"turnOff", id["BUR_ORDI_SW1"]},{"If", {{"Value+", id["BUR_ORDI_SW1"], 0}}}}) Sur le code ci-dessus, qui fonctionne très bien habituellement j'ai remarqué la chose suivante : Sur la partie des jours de la semaine, j'ai noté de 18h00 à 9h00. Quand la consommation, lors du passage à 18h et à 200w par exemple et qu'il passe ensuite à 15w, après 18h le script capte bien le sensor et fait le travail. Par contre si la consommation est à 15w avant 18 et qu'elle ne bouge plus par la suite, alors l’événement n'est pas vu car j'imagine qu'il n'y a pas de changement et donc la règle n'est pas revu. Je précise que le module envoie son rapport toutes les 30s. Comment puis je faire pour qu'à partir de 18h dans mon cas, le système reprenne la consommation même si elle est stable. Merci à toi. Amicalement Séb

Bonjour à tous, Je reviens sur mon affaire de reboot de la box automatique pour faire part de mon retour d'expérience. Après les explications de Krifroff et le croisement que j'ai pu faire avec des échanges de mail avec AEON sur les DSC17, HEM3 j'ai pu faire des modifications de paramétrages et stabiliser la situation à ce niveau. En fait la communication entre mes modules et la box utilisait des rapports qui se marchaient sur les pieds et les nombreuses collisions devaient poser problème aux uns et aux autres. Concrètement, les déclenchements de rapport de consommation peuvent se faire de 3 manières. Soit périodiquement, soit par un écart en watt positif ou négatif ou soit en pourcentage. Par précaution, j'utilisais les 3 et cela à l'air de provoquer des surcharges. D'autant plus que la box , elle même devait solliciter le module de son coté... Je viens de paramétrer l'ensemble pour que les rapports ce fassent uniquement en fonction du temps (toutes les 30s) et depuis plus de problèmes . Si vous avez besoin des paramètres que j'ai utilisé dans mon cas, je peux les poster dans un sujet plus approprié. Merci à tous. Séb

@Krikroff : Bon pour le cable ca me rassure avec mes modules. Je pense que mes problèmes sont dues effectivement à la partie Z-Wave qui se met en vrille le week end (jours des lessives et autres joyeusetées...), j'ai encore 7 autres modules DSC17 a ajouter, je vais voir si le maillage va aider ou si au contraire les modules supplémentaires souffrent de la même pathologie. Affaire à suivre...

@Steven : Bonjour Steven. Ce que tu dis m'intéresse beaucoup ! Quel est l'impact du réseau LAN sur la gestion de la box et du Z-wave ? Y'a-t-il un rapport direct entre la partie net (linux je crois) et les modules ? Chez moi, j'ai 4 réseaux imbriqués et je n'imaginais pas que le Z-Wave pouvait être dépendant de l’Ethernet... Merci pour tes précisions et ta documentation si je peux aller faire ma culture àce niveau. Sur le plan de la sécurité cela m'interpelle aussi… Seb

Je vais aussi donc attendre et mes projets de cam resteront dans le carton pour l'instant. je préfère charger en devices, pour les cams je pense que la v4 va apporter des plus significatifs. Une bonne journée àtous. Séb

En fait je pense que tu as raison sur le fond. Concrètement je n'utilise qu'une scène qui tourne avec GEA de Steven et mes périphériques virtuels font des requêtes http vers des arduinos pour le reste (volets, vmc, chaudière et solaire). Je ne pense pas que les requêtes http posent problèmes, ça tient sur 3 lignes. Après GEA tourne aussi comme une horloge. Reste donc plus que les wakeups que je suis obligé de faire sur les modules AEON pour qu'il remonte la consommation en temps réel. Même avec les bons paramétrages, sans les wakeups, ils restent muets. Est ce que trop de wakeup tue le wakeup... Ceci étant dit ce sont ces mes modules qui posent problèmes ensuite. J'attend des nouvelles d'AEON pour ces problèmes de configuration. Une fois résolu je pense qu’après je n'aurai plus besoin de faire de wakeup et ça ne plantera plus. Je garde donc mes reboot comme soin palliatif et ne programme pas de reboots automatiques qui seront donc certainement inutiles. Encore merci Séb

Bonjour Krikroff, Merci pour ton retour. Je suis aussi certain que la machine a de forts potentiels et que tu as réussi à stabiliser ta configuration (certainement pas du premier coup j'imagine...) Je pense que les anomalies que je peux déceler proviennent d'une communication qui ne se fait pas entre certains modules et la box. Qui dit communication, dit au minimum deux intervenants. Dans mon cas la HC2 et un DSC17 d'aeon. Je n'ai pas pu obtenir encore tous les paramétrages pour mon module DSC17. J'en connais les principaux mais pour les fameux paramètres 101 et 80, ca bloque encore. Ce qui se passe c'est que le module doit être coupé (turnOff). Le module "cliquette" est donc un relais fonctionne mais ce n’est pas le SW1 mais le SW2 qui coupe. Après la consommation est à 0 alors que le module fourni encore 180W. Quand je reboot la box, le module se coupe enfin. Comme je n'ai aucun outil pour voir ce qu'il se passe, je ne peux pas diagnostiquer le problème. Z-Wave, le module, la box... Quand je coupe l'alimentation du module, il revient dans son faux état. La seule solution que j'ai trouvé, reboot de la box. Après comme je t'ai expliqué je suis preneur de tous les outils me permettant d'analyser, de comprendre et de corriger ce qui se passe. J'ai bien compris que nous étions tous au début d'une nouvelle aventure qui risque d'aller très loin et je ne désarçonne pas. Pour l'instant je n'ai pas installé de chose cruciale sur mon projet et je ne le ferai pas, en tout cas pas avant la V6 Pour le reste elle tourne comme une horloge, c'est vrai. Amicalement Séb

Bonjour Nico, En fait j'ai 82 devices sur 30 noeuds physiques et 22 virtual devices. Le tout est gérer par le GEA de Steven et aujourd'hui j'ai exactement 54 taches (id) qui tourne avec un rythme de 30s. Les devices qui boguent sont en général des AEON DSC17 qui ne remontent plus les consommations ou qui ne répondent plus aux ordres turnOff ou turnOn. J'ai un HEM d'AEON aussi qui ne bronche pas sauf de temps en temps qui passe en Lux Quand les consommations ne remontent plus, les mobiles connectés en WIFI en interne ne passent plus sur la box. Je garde l'accès extérieur mais plus en direct sur le routeur. Quand je reboot, tout reviens dans l'ordre. Je suis incapable de savoir pourquoi ça plante. Si il existe des outils, je suis preneur. Je n'ai pas encore mis de caméra, mais pour l'instant j'attend que tout cela ce stabilise. A la fin je dois a peu près tripler le nombre, sans compter les caméras. Au niveau des ID j'en suis à 121. Merci pour tes conseils. Séb

Bonjour Krikroff, Merci pour ton retour rapide. Je suis entierement d'accord avec toi. Par contre j'ai remarqué la chose suivante, quand il y a une charge de travail importante, beaucoup de monde à la maison qui fait varier la consommation des modules, il arrive un moment ou la box arrête de faire son boulot sur certains modules. Pas forcément les plus solicité mais bien au contraire, elle a l'air de se concentrer sur ceux qui bouge beaucoup au détriment des autres au point de ne plus les interroger. C'est en tout cas ce qu'il me semble d'après les quelques observations que j'ai pu faire lors des blocages de la box. Je pense que les améliorations de la V4, qui portent sur le multithread, doit certainement pallier aux inconvénients dont je suis victimes aujourd'hui. Quand tu dis par précaution, est ce que l'opération de reboot est dangereuse ou elle ne permet elle pas, comme sur beaucoup de système, de remettre "les cases" en place (je pense au garbage-collector et compagnie). Merci encore. Séb

Bonjour à tous, Comme vous avez pu le constater par la "newbie attitude" de mes questions, je découvre depuis peu l'univers de la box Fibaro HC2 et des joies du paramétrages des modules... En fait au début j'ai interprété certaines anomalies comme étant celles des modules, par exemple un module qui doit remonter la consommation ne le fait plus, mais je me suis aperçu qu'en rebootant la HC2 alors tout rentre dans l'ordre. Idem concernant les connexions par les applications android vers la HC2, les connexions perdues reviennent par miracle dès que l'on reboot la hc2. Il me vient donc, naturellement, la question suivante : Est ce que pour le fonctionnement optimale de la box il serait intéressant de la rebooter régulièrement, pas forcément toutes les heures mais au moins 2 fois par jour par exemple ? Quels sont vos habitudes à ce niveau ? Après si la V4 est plus stable, alors on peut imaginer le faire moins souvent, mais d'après ce que j'ai lu il faudra en parler plus tard... Merci d'avance pour le partage de vos expériences. PS : pour l'instant j'ai 18 devices réels, je dois en mettre à terme un peu plus de 50. Amicalement Séb

Merci Steven, Ma problématique est résolu. Le jour où nous serons en EJP tous mes WallPlug seront en rouge dans toutes les pièces. Bon quand je lance le script, dans la fenêtre de notification des messages zwaves ca travaille dur mais au bout de quelques instants (c'est pas instantané) les configurations sont mis à jour. Je vais essayé de mettre en résolu le post. C'est reparti pour de nouvelles aventures... Seb

Voila je viens de voir, en fait l'auteur a fait un "search and replace" sur les paramètres 61 et 62 plutôt que de s'aventurer avec le json. Je trouve cela très malin... Bon pour le reste, le fait d'envoyer le gros paquet à chaque fois par http + l'authentification et tout le toutim c'est vrai que ça n'est pas des plus économes. Pour l'instant j'utiliserai la hache... Je vais donc faire un module virtuel dans le même esprit est un petit appel de GEA lorsqu'on est en EJP et un autre quand on en sort... avec les bons critères. En espérant des avancés avec la v4 sur la config et les plugins. Encore merci Séb

Merci je jette un oeil... même les deux

Bonjour Steven, Merci pour ta réponse, en fait je suis tombé la dessus : HC2 = Net.FHttp("192.168.XXX.XXX") HC2:setBasicAuthentication("admin", "ton mot de passe") response ,status, errorCode = HC2:GET("/api/virtualDevices?id="..deviceID) fibaro:debug("status = " .. status) fibaro:sleep(1000) jsonTable = json.decode(response) fibaro:debug(response) fibaro:debug(jsonTable.properties.rows[1].elements[1].caption) fibaro:debug(jsonTable.properties.rows[1].elements[1].name) jsonTable.properties.rows[1].elements[1].caption = NewCaption jsonTable.properties.rows[1].elements[1].name = NewName json = json.encode(jsonTable); response2 ,status2, errorCode2 = HC2:PUT("/api/virtualDevices?id="..deviceID, json)* Sur ce lien https://plus.google.com/102429223700201895244/posts/CEpskCGAKEz J'ai réussi à recevoir tout le paquet des propriétés du Wall Plug : [DEBUG] 13:03:39: {"id":18,"name":"Multimédia","roomID":5,"type":"binary_light","properties":{"UIMessageSendTime":"0","classConfigure":"0,2,2,2,2,0,0,2,2,0,0","classGeneric":"37","classSupport":"37,49,50,112,114,115,122,133,134,142,239","classVersion":"1,2,2,1,1,1,1,2,1,1,1","color":"off","dead":"0","deviceControlType":"20","deviceIcon":"2","disabled":"0","emailNotificationID":"0","emailNotificationType":"0","endPoint":"0","isBatteryOperated":"0","isLight":"0","liliOffCommand":"éteindre chambre","liliOnCommand":"allumer chambre","log":"","logTemp":"","meterSupport":"{\"vMeterSupport\":[{\"meterType\":1,\"sMeterType\":\"kWh\",\"meterScale\":0,\"sMeterScale\":\"\",\"value\":0,\"enable\":true,\"lastPolling\":1409930025,\"configuration\":true,\"retryConfig\":0},{\"meterType\":1,\"sMeterType\":\"W\",\"meterScale\":2,\"sMeterScale\":\"\",\"value\":0,\"enable\":true,\"lastPolling\":1409930025,\"configuration\":true,\"retryConfig\":0}]}","needConfigure":"5","nodeID":"7","parametersTemplate":"225","parentID":"1","pollingRetryError":"0","pollingTime":"","pollingTimeNext":"","pollingTimeSec":"0","productInfo":"1,15,6,0,16,0,24,24","pushNotificationID":"0","pushNotificationType":"0","requestNodeNeighborState":"0","requestNodeNeighborStateTimeStemp":"0","saveLogs":"1","sensorSupport":"","showChildren":"1","showEnergy":"1","smsNotificationID":"0","smsNotificationType":"0","sortOrder":"999","unit":"","unitMeter":"kWh","unitSensor":"W","useTemplate":"1","userDescription":"","value":"0","valueMeter":"2.41","valueSensor":"0","zwaveCompany":"Fibar Group","zwaveInfo":"3,3,52","zwaveVersion":"2.4, (24.24)","parameters":[{"id":1,"size":1,"value":1,"lastSetValue":1},{"id":16,"size":1,"value":1,"lastSetValue":1},{"id":34,"size":1,"value":63,"lastSetValue":63},{"id":35,"size":1,"value":0,"lastSetValue":0},{"id":39,"size":2,"value":600,"lastSetValue":600},{"id":40,"size":1,"value":80,"lastSetValue":80},{"id":42,"size":1,"value":15,"lastSetValue":15},{"id":43,"size":1,"value":30,"lastSetValue":30},{"id":45,"size":1,"value":10,"lastSetValue":10},{"id":47,"size":2,"value":3600,"lastSetValue":3600},{"id":49,"size":1,"value":0,"lastSetValue":0},{"id":50,"size":2,"value":300,"lastSetValue":300},{"id":51,"size":2,"value":500,"lastSetValue":500},{"id":52,"size":1,"value":6,"lastSetValue":6},{"id":60,"size":2,"value":25000,"lastSetValue":25000},{"id":61,"size":1,"value":1,"lastSetValue":1},{"id":62,"size":1,"value":8,"lastSetValue":8},{"id":63,"size":1,"value":1,"lastSetValue":1},{"id":70,"size":2,"value":65535,"lastSetValue":65535}],"associationView":[{"groupID":1,"devices":[1]},{"groupID":2,"devices":[1]},{"groupID":3,"devices":[1]}],"associationSet":[{"groupID":1,"devices":[1]},{"groupID":2,"devices":[1]},{"groupID":3,"devices":[1]}]},"actions":{"firmwareUpdate":1,"pollingTimeSec":1,"requestNodeNeighborUpdate":0,"resetMeter":0,"turnOff":0,"turnOn":0},"created":1411661331,"modified":1411661331,"sortOrder":16} La j'essaye de modifier dans la json table la valeur du parametre 61 et 62 et j'ai des nil quand j'essaye d'y accéder. Si j'arrive à modifier les bons paramètres et avec un PUT crois tu que je puisses y arriver. Bon ce n'est pas très "SIOUX" mais si ca marche 22 fois dans l'année je serai ravi pour l'instant. Merci à toi Séb

Bonjour à tous, J'avance très bien dans mon projet semer de cailloux et de grosses briques... mais ça avance. J'ai la chance de faire parti des abonnées EDF qui bénéficie du tarif EJP et je viens d'asservir mon système EJP à la HC2 et donc en théorie elle saura quand le tarif EJP est en cours. J'aimerai, quand l'EJP est actif, mettre tous les WALLs PLUG en ROUGE quand ils sont en OFF ou ON afin d'avertir les utilisateurs du jour EJP. En fait j'ai vu qu'il y avait deux méthodes. Soit on change les statuts des LED quand la prise est ON ou OFF avec le paramètre 61 et 62, soit on utilise un message alarme 63, mais c'est un peu plus compliqué car j'ai d'autres modules qui vont réagir alors que je ne le veux pas. Donc l'idée serait d'avoir un script qui permet de charger certains modules avec des paramètres qui vont bien (pour les walls plugs) et juste envoyé une modification sur le 61 et 62. J'ai eu l'impression que pour faire cela il fallait utiliser l'API/DEVICES par le HTTP et que mon idée était de faire un "get" des paramètres, modifier ceux qui m'intéresse et de renvoyer le paquet. J'aurais en fait préféré avoir une commande qui n'affecte que le 61 et 62 pour faire plus light. Quelles sont vos expériences dans ce genre d'opération ? Merci d'avance Amicalement Séb

Bonjour moicphil, Je suis resté bien sagement sur la version 3.59 pour l'instant. Pour le problème que j'ai eu, on va mettre ca sur le compte de "pas de chance". Concernant AEON, j'ai eu des conseils de paramétrage qui n'ont rien changé aux informations qui doivent être remontées. Quand on va voir avec HC2 Toolkit les propriétés, la consommation instantanée des pinces individuelles ne sont pas indiqués dans les zones concernées. J'espère en effet que dans la V4 les choses vont évoluer, mais d'après le retour de Fibaro sur les questions que j'ai posé, ils ont pris ma requête et je n'ai plus eu de nouvelle. Il est certain que, vu la jeunesse de ce petit marché, les uns et les autres ont tout intérêt à travailler le plus vite possible ensemble pour que tout cela marche correctement. Je garde espoir et espère qu'à la prochaine coupure secteur le matériel restera configuré. Amicalement Séb

Bonjour, Je reviens au sujet de ce module HEM3 G2 avec 3 pinces pour les ampères et 3 paires pour le voltage et le déphasage... Après quelques aller retour avec AEON et Fibaro, pour l'instant j'en suis avec ma consommation cumulé sur les trois pinces + total correct. Pour la consommation instantanée, elle ne figure uniquement sur la totale et malgré les paramètres indiqués pour avoir le détail en watt sur chaque pince il n'y a rien qui s'affiche. Avec le HC2 Toolkit on peut voir aussi que les slaves n'ont pas la valueSensor que la master instancie bien. Il m'est arrivé une mésaventure : lors d'une coupure du disjoncteur principal, je me suis retrouvé avec une sonde en LUX complètement bloquée. Après une exclusion, inclusion elle est revenu en % (sonde d'humidité). J'ai du refaire un reset complet du module puis exclusion, reset, inclusion, tout ça en mode sport compte tenu de l'installation en tête de ligne, très loin de l'emplacement de la box Bon après les manipulations habituelles pour "enabler" les modules invisibles, j'ai fini par retrouver, 8 modules plus tard la bonne config. Tout cela est encore loin d'être très stable et j'avoue commencé à appréhender la prochaine coupure EDF... Bonne journée à tous.

Merci Steven, je vais essayé de déclencher un "boost" comme tu me l'a indiqué pour les actions nécessitant des réveils rapides.

Merci Steven pour tes précisions. En fait, sur le plan événementiel, 30s c'est très bien, pour l'action immédiate c'est bien aussi, mais il y a certains cas où en fait le module dors et je dois le réveiller rapidement pour qu'il donne ensuite son état. Par exemple un détecteur de mouvement agit de suite mais j'ai besoin de savoir si la luminosité extérieure est élevé ou pas. Dans un cas j'allume une lampe, dans l'autre j'ouvre un peu le volet. C'est un exemple mais le capteur en question dehors à besoin d'un wakeup pour retourner la valeur et plus vite il est fait, plus vite l'action prochaine à lieu. Ton idée d'avoir deux scripts qui tourne est bien et je me demande si, une fois le script lancer, on peut modifier la valeur des 30s à la volée. Comme ca 99% du temps il tourne à 30s et selon les besoins on donne un petit coup d'accélérateur. Il faudrait changer la valeur de ta variable checkEvery mais cela posera peut être un problème dans ton "TOTALRUNS" qui ne sera juste que pour la première valeur. Dans tous les cas avoir un deuxième script pour les actions plus nerveuses me convient parfaitement. Séb

Ca y'est ca marche, j'ai donc fini la vmc, je passe à la consommation d'eau ... Je ne vois pas trop comment j'aurais pu faire sans GEA... J'ai vu que dans la version 4 il y avait des "magic scenes" mais je n'ai pas vu si elles étaient centralisées et si l'implémentation est aisé. Concernant le rythme des 30s qui est par défaut dans GEA, est ce que tu as déjà essayé de mesurer l'impact sur la charge de travail du HC2 quand on augmente la fréquence, genre 15s ou 10s ? Comme la version 4 est multi taches, peut être qu'il sera plus aisé d'accélérer le rythme dans certains cas. Séb

Bonjour, Oups, effectivement, juste en dessous... Je ne savais pas que différent s'écrivait "~=", j'avais l'habitude du "!=" ou "<>". Instinctivement j'avais d'ailleurs mis le "~" au lieu du "!" que tu as utilisé pour ta syntaxe. Par contre dans tes conditions autorisés il n'y a pas "Global!" et pour cette raison je n'ai pas poussé la recherche : Conditions autorisées : <Id module> -- Identifiant du module * {"Global", <nom variable>, <valeur>} -- Si la variable global X contient la valeur Y {"Sensor+", <id module>, <valeur max>} -- Si la valeur du sensor X est supérieur à Y {"Sensor-", <id module>, <valeur max>} -- Si la valeur du sensor X est inférieur à Y {"Value+", <id module>, <valeur max>} -- Si la valeur du module X est supérieur à X {"Value-", <id module>, <valeur max>} -- Si la valeur du module X est inférieur à X {"Global+", <nom variable>, <valeur>} -- Si la valeur de la variable globale X est supérieur à X {"Global-", <nom variable>, <valeur>} -- Si la valeur de la variable globale X est inférieur à X {"Slider-", <id_vd>, <nom slider>, <valeur>} -- Si la valeur du slider est inférieur à X {"Slider+", <id_vd>, <nom slider>, <valeur>} -- Si la valeur du slider est supérieur à X {"Label", <id_vd>, <nom label>, <contenu>} -- Si la valeur du label est égale à X {"Battery", <id module>, <valeur max>} -- Si l'état de la pile du module X est inférieur ou égale à X {"Batteries", <valeur max>} -- Si l'état de la pile des 350 premiers ont une pile inférieur ou égale à X {"Dead", <id module>} -- Si le module X ne répond plus {"Group", <numéro du groupe>} -- Si le groupe X est valable {"SceneActivation", <id module>, <id scene>} -- Si la scene X du module Y est le déclencheur du script * Si seul l'Identifiant du module le script considère qu'il doit vérifier si le module est activé. Je change mes événements de suite... Amicalement Séb

Bonjour Steven, Toujours dans le cadre de la gestion de la VMC j'ai le code suivant : GEA.add({"Global+", "VMC_Co2", 475}, 15*60, "VMC 1", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 1}, {"If", {{"Global-", "VMC_Co2", 600}}}}) GEA.add({"Global+", "VMC_Co2", 600}, 15*60, "VMC 2", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 2}, {"If", {{"Global-", "VMC_Co2", 700}}}}) GEA.add({"Global+", "VMC_Co2", 700}, 15*60, "VMC 3", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 3}, {"If", {{"Global-", "VMC_Co2", 800}}}}) GEA.add({"Global+", "VMC_Co2", 800}, 15*60, "VMC 4", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 4}, {"If", {{"Global-", "VMC_Co2", 900}}}}) GEA.add({"Global+", "VMC_Co2", 900}, 15*60, "VMC 5", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 5}, {"If", {{"Global-", "VMC_Co2", 1000}}}}) GEA.add({"Global+", "VMC_Co2", 1000}, 15*60, "VMC 6", {{"Time", "07:00", "23:00"}, {"VirtualDevice", id["VMC"], 6}}) Cela fonctionne bien mais si les conditions de CO2 bougent dans la fourchette, il est possible que l'action se répète. C'est normal. Par contre je voudrais que GEA fasse l'action en ayant un test du type Global~ qui est le test "différent de". En effet je voudrais faire passer la VMC à l'étage 2 que si elle n'est pas déjà à 2. Si j'utilise {"Global-", "VMC_ETAGE", 2},{"Global+", "VMC_ETAGE", 2} La condition ne sera jamais vrai. Après je pense qu'avec un group et inverse cela peut marcher, mais compte tenu du pavé que j'ai pour les différentes vitesses ca va devenir un peu chaud ! Si le <> ou != existait ça ferait un truc du genre : {"Global~", "VMC_ETAGE", 2} Dans ton source il y a elseif (type(id) == "table" and id[1] == "Global+" and #id > 2) then GEA.log("isActivate", entry, "type : Global+", false) result = tonumber(fibaro:getGlobalValue(id[2])) > tonumber(id[3]) --mainid = tonumber(id[2]) if (main) then entry[GEA.keys["VALUE"]] = fibaro:getGlobalValue(id[2]) end elseif (type(id) == "table" and id[1] == "Global-" and #id > 2) then GEA.log("isActivate", entry, "type : Global-", false) result = tonumber(fibaro:getGlobalValue(id[2])) < tonumber(id[3]) --mainid = tonumber(id[2]) if (main) then entry[GEA.keys["VALUE"]] = fibaro:getGlobalValue(id[2]) end est ce qu'un test du type <> ou != serait possible ? Un grand merci pour tes conseils. Amicalement Séb

Bonjour, Je propose que l'on ouvre une section pour les "Sébastiens" pour essayer de canalaliser ce flux soudain. Je propose aussi de nommer Saint Sébastien le patron de la domotique vu les circonstances Séb XIV

Bonjour à tous, Pour faire avancer le schmilblic, j'ai trouvé une solution en m'appuyant sur une variable calculée, mais c'est assez barbare puisqu'il faut allez dans la fonction qui gère la mise à jour de la variable pour comprendre la condition. Mais sinon ca marche. Amicalement Seb (l'autre qui n'est pas encore bien bien)