jojo

je ne les ais pas renouvelés manuellement, car j'avais le script de @mprinfo qui fait les renouvellements automatiquement. Chez lui ça fonctionne nickel. Je ne me suis pas inquiété, car je voyais que mes dates de modif étaient ok, et je croyais donc que c'était liés à mon ancienne configuration ... Mais je vais regarder encore plus en détail pour comprendre ...

oui, j'en suis certain ! Mais je cherche pourquoi chez moi ça merdouille. Les 2 copies d'écran sont ok ? Je devrais chercher ailleurs ?

c'est tous les ans ... Il faudrait progrmmer une routine avec IFTTT

qu'ais-je mal fait ? Depuis le 8/4/2024 (c'est juste 3 mois après l'installation initiale de mes certificats) mes certificats ne fonctionne plus, et je ne comprends pas pourquoi. J'ai reçu des mails d'avertissement de LetsEncript, mais je croyais que c'était normal. Et quand je vais voir les certifs sur linux : et dans le dossier LetsEncrypt : une idée ?

....

Sorry, je ne l'avais pas précisé, car pour moi c'était évident de suivre tes instructions ...

J'ai implémenté ta nouvelle version, et pas de chauffage ce matin. Mais je ne comprends rien, car pas d'erreur au niveau de ton régulateur : Mais je vois ceci dans l'historique de la HC3 : alors que je (crois) n'ai rien demandé et ne vois rien à propos du régulateur.  ???

??

pour les modules z-wave c'est hub.wakeUpDeadDevice(<DeviceId>) C'est ce que j'utilise dans mon QA ...

ok, je comprends. Donc comme GEA-Deads me servait de déclencheur pour mon QA Deads, je ferai tourner mon QA en boucle toutes des heures et il sera 100% indépendant.

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