jojo

suite au redémarrage de GEA cette nuit (backup hebdo), le règle "Deads" m'a bien envoyé une notif => cool. Cela m'a fait pensé à un truc du coup. GEA n'exécute les actions que s'il y a modification dans les conditions (normal). => pour "Deads", il va regarder s'il y a un json de généré, mais, question, regarde-t-il si les id retournés sont différentes ? Cela expliquerait que si ids 100 et 101 sont rapportés comme morts, si ces ids deviennent 101 et 102, il ne voit pas de modif, donc pas d'actions ? une piste ?

salut, Je te confirme que dans ma config j'ai bien HMCF.turnOffNoTemp = false Dans cette version dois-je encore préciser le wekaUp time ?£ Merci et bon dimanche ensoleillé

dans mon post de ce matin, c'était du direct : pas de notif, et le json que j'ai posté ... Que dois-je faire de plus ?

ok, mais alors pourquoi il n'a pas réagit à un des 5 modules parents qu'il a détecté comme mort ? (dans mon message initial, je parlais en effet d'un child, mais GEA aurait du réagir pour les autres parents vus comme mort. En effet, je suis le premier surpris d'un tel bug, mais pourquoi n'ai-je pas de notif pour les autres ?)

1) Merci de te pencher sur le problème. Le module qui était mort hier avait une interface z-wave n'était pas parent, mais je suppose que son parent était mort également était enable mais maintenant, il s'est réveillé tout seul ... Mais j'ai d'autres modules morts, donc j'ai pu tester ta requête: http://192.168.x.y/api/devices?property=[dead,true]&enabled=true&interface=zwave&parentId=1 dont voici le json : array [5] 0 {19} 1 {19} 2 {19} 3 {19} 4 {19} id : 701 name : FGS223_Circulateurs roomID : 239 view [0] type : com.fibaro.zwaveDevice baseType : com.fibaro.device enabled : true visible : false isPlugin : false parentId : 1 viewXml : false hasUIView : false configXml : false interfaces [6] 0 : polling 1 : zwave 2 : zwaveAssociation 3 : zwaveConfiguration 4 : zwaveMultiChannelAssociation 5 : zwaveSlaveRouting properties {42} categories [1] configured : true dead : true deadReason : power deviceControlType : 1 deviceIcon : 28 deviceRole : Other deviceSpecificData : h'0000000000000c16 deviceSpecificIdType : Serial Number deviceState : Configured endPointId : 0 icon {0} lastWorkingRoute [0] lastWorkingRouteRequestStatus : ok lastWorkingRouteRequestTimestamp : 0 lastWorkingRouteResponseTimestamp : 1712044837 log : logTemp : manufacturer : markAsDead : true model : neighborList [4] neighborListRequestStatus : ok neighborListRequestTimestamp : 0 neighborListResponseTimestamp : 1712044837 nodeId : 89 parameters [36] parametersTemplate : 781 pollingInterval : -1 pollingTimeSec : 0 productInfo : 1,15,2,3,16,0,3,4 saveLogs : true securityLevel : securitySchemes [0] serialNumber : h'0000000000000c16 supportedDeviceRoles [1] useTemplate : true userDescription : 33\nCirculateurs chaufferie\nChaufferie\nON = On / OFF = Off\n20 40 41 42 43\nen fait installé avec 224\n zwaveCompany : Fibargroup zwaveInfo : 3,4,5 zwaveSoftwareVersion {0} zwaveVersion : 3.4 actions {7} created : 1661610677 modified : 1702381061 sortOrder : 427 J'espère que cette info t'aidra. => merci N.B. quand je teste si un module spécifique (même s'il n'est pas parent) est mort, ca fonctionne avec {"Dead", <id module>}

Salut, Je me demande s'il n'y a pas un petit bug avec l'instruction "Deads". Voici ma règle GEA.add ({"Deads"}, 0, "", {{"QuickApp", id["DEADS"], "Deads"}, {"Email", "admin", "Réveil des noeuds morts via QA\nle #date# à #time#.", "Réveil des noeuds morts via QA"}}) or j'ai un nœud mort, confirmé par le json object {19} id : 1140 name : Chauf_SdBRdC_Vanne roomID : 224 view [2] type : com.fibaro.hvacSystem baseType : com.fibaro.device ... properties {62} ... configured : true dead : true deadReason : unknown ... et je ne reçois pas le mail...

j'ai fait c'est quelques mofifw dans le code, en espérant que ce soit ok vers ligne 1590 : maxWakeUp = 46800, -- max duration (sec) of wakeUp (Default: 46800 = 13 h) vers ligne 620 : if abortOnErr and item.wakeUp > self.HMCF.maxWakeUp then vers ligne 718 : if item.wakeUp then checkRange("wakeUp", item.wakeUp, 0, self.HMCF.maxWakeUp) end et du coup ma config HM:addHeater({id=162, wakeUp = 43200}) est acceptée. Je verrai demain matin si mon radiateur chauffe.

oups, je viens de voir ma faute de frappe (car je me disais bien qu'il ne pouvait pas s'agir d'une erreur) C'est 'wakeUp' et pas 'wakeup' ... Mais du coup où puis-je modifier les limites, car j'aimerais bien 43200 ? Merci

Bonjour Maître J'avais fait quelques tests rapides avec la régulation de mon bureau. Fort de cette expérience positive, je l'ai mis dans la salle de bains, et là j'ai du à nouveau faire preuve d'imagination vis-à-vis de ma femme. Voici la description des soucis: 1) malgré une modification de la température mesurée j'avais une erreur qui arrivait : [WARNING] Chauf_SdBRdC_Radiateur : No temp. update since 8h 00m et le radiateur ne fonctionnait plus sur la solution de replis que tu as mise en place (d'où les explications fumeuses que j'ai du trouver ...) Comme la sonde de température est une AeonTec aerq, je me suis dit que cela devait être le wakeup ... 2) par défaut le wakeup est de 43200s (=12h) - c'est long mais ça me va. et, le régulateur passe sur OFF (ce serait cool que l'on puisse passer en solution de replis pour des erreur "compatibles") Voici le message d'erreur: En fait, le messaage d'eereur devrait être adapté. Dans ce cas, il faudrait : addHeater : 'wakeup'is out of lange [MinRange, MaxRange] et pour la seconde ligne : 'wakeup' set to MaxRange sec Ce ne sont que des suggestions, tu auras peut-être une autre/meilleure idée ?

je crois qu'ils y a un paramètre dans le module pour lui dire qu'il fait on/ (100%off(0%) Regarde dans la doc. N'ayant pas ce module, je ne peux pas t'en diire plus.

sorry, j'avais mal lu ... je n'ai jamais utilisé cette fonctionnalité, ni sur la HC2, ni sur la HC3 : mon anneau a une couleur fixe dès qu'il est allumé.

???? ce sont des paramètres du module => indépendants de la box. Les 2 versions du module ont toujours la possibilité de configurer la couleur de l'anneau via le template.

non pour mes pinces c'est encore tout juste bien passé, mais quand je te lis et je lis les autres expériences relatées ici, je suis outré

merci pour le lien, je viens d'y déposer un avis ...

C'était quoi le problème ? Comment l'as-tu réglé ? Partager ta solution pourrait être utile pour d'autres ... Reset = retour aux paramètres d'usine

tu es trop gentile : pas incorrects, mal-honnete

Est-ce que le paramètre 1 (Always On) de ton FGWP102 est bien à 0 ? Sinon, je ferais : exclusion du device reset (cfr mode d'emploi) du device ré-inclusion, et donc nouvel ID.

Peut-être pas tant que ça vu que tu as reçu ta commande.

ah ok, je comprends mieux maintenant, c'est très logique en fait. Mais du coup, je ne comprends pas "d'un autre circuit". "un autre circuit" = un autre disjoncteur ? Car je croyais qu'on ne pouvais pas mélanger sur un même appareil différents disjoncteurs. J'avais donc +/- bien compris quand je disais que si on alimentait le FGS224 en 24V (= TBT) il pouvait commander un contact sec (= TBT). J'utilisais donc de manière risquée (pour ce qui était commandé par le contact sec) depuis des années des FGS221/2/4 alimentés en 220V (=BT) pour piloter des contacts secs (=TBT). Ceci va donc accélérer la migration de mes FGS224 vers les OUT1/2 des FGBS222.

nos messages s'étaient croisés ... S'ils ont prévu un IN séparé du L (alimentable lui en 230VAC ou 24 VDC) c'est pour pouvoir y mettre une autre tension, sinon inutile. Alors d'un point de vue sécurité, si on veut mettre du 0 ou 12 V sur le IN, il serait plus prudent d'alimenter le module en 24VDC. Perso, j'utilise depuis TRES longtemps un FGS224 (alimenté en 220V) pour faire un contact sec sur le moteur de ma barrière (idem pour le volet et l'éclairage de ma piscine). Mais depuis qu'on a expliqué ici comment commander les OUT indépendamment des IN du FGBS-222, je vais tout faire avec un FGBS-222.

je n' connais RIEN en télérupteur, donc je ne dirai rien sur tes photos, car je ne souhaite pas être responsable de l'incendie de ta maison ... Mais sur le IN du FGS224, tu mes la tension que tu veux ...

les FGS223 sont exclusivement 230V Avec les FGS224, il y a une entrée IN qui te permet d'y mettre la tension que tu veux, donc du 12V

je ne connais rien aux télérupteurs (pas utilisés en Belgique), mais ce que j'ai lu sur ce forum, c'est que les FGS les remplaçaient

thank you ! it does (of course) works ! This is EXACTLY what I needed.

I said to myself :"Let's keep it simple and standard". So I tried this hub.call(20, "updateProperty", "userDescription", "FWPP1") And it does not work. I do not understand why ...