jojo

Bonour, Tu parles de porte de garage, mais ton lien semble être pour un moteur de barrière.... De ce que j'ai compris, MAIS je validerait avec un multimère. Pour connaître le statut ouvert/fermé: Contacts COM-SWO et COM-SWC ou AUX1 // AUX2 pour actionner la barrière : Faire un petit pout (bref) entre +COM et PED ou +COM et STOP ou +COM et P.P. Ce que je ferais si c'était mon matos : A priori il n'y a pas de risque de griller la carte avec mes tests. faire les tests décrits ci-dessus avec un multimtère (en mode mesure de continuité) et un petit fil pour faire les ponts. Pour le pont d'actionnemnt de la porte, si déjà installée, voir où arrive le bouton poussoir et s'y connecter en //

ah ok : Les Modes sont le nom en français des Profiles en uk. Donc la sytaxe que je t'ai donnée + haut, est celle de GEA (Profiles)

à je voyais pas ce qui était mal configuré => c'était quoi le problème ? je ne suis pas sûr d'avoir bien compris ta question/ton besoin tu parles des Prfoles de la HC3 ? -- "Profile" : Teste/active un profil -- SYNTAXE : {"Profile", <id_profil>} {"Profile", <"nom_profil">}

TTS c'est via le cloud ... c'était l'argument qui me manquait pour convaincre madame que cet investissement était indispensable

merci pour les liens, qui me sont très utiles, car c'est très difficile pour moi de tout lire.

précédents posts mis dans un mauvais fil : j'espère avoir trouvé ce qui n'allait pas. En relisant et comparant ma config avec celle de ce tuto, j'ai vu que dans le bind:::80 j'avais oublié reqadd X-Forwarded-Proto:\ http et quand j'ai fait le check de ma config, j'ai eu cette erreur : [NOTICE] (25472) : haproxy version is 2.6.16-1~bpo10+1 [NOTICE] (25472) : path to executable is /usr/sbin/haproxy [ALERT] (25472) : config : parsing [/etc/haproxy/haproxy.cfg:85] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead. [ALERT] (25472) : config : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] (25472) : config : Fatal errors found in configuration. j'ai donc fait ce qui était demandé : http-request add-header X-Forwarded-Proto:\ http et du coup j'ai maintenant cette erreur : root@haproxy:~# haproxy -c -V -f /etc/haproxy/haproxy.cfg [NOTICE] (25483) : haproxy version is 2.6.16-1~bpo10+1 [NOTICE] (25483) : path to executable is /usr/sbin/haproxy [ALERT] (25483) : config : parsing [/etc/haproxy/haproxy.cfg:85] : error detected in frontend 'http' while parsing 'http-request add-header' rule : expects exactly 2 arguments. [ALERT] (25483) : config : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg qu'est ce que je dois mettre ? @mprinfo, je suppose que tu as également du modifier cette instruction => quelle est la bonne ? en mettant ceci : (espace avant le \) http-request add-header X-Forwarded-Proto: \ http la config passe et ça fonctionne! Mais est-ce bon ??? (! les instructions du premier post ne sont donc plus toutes valables pour les version HAProxy > 2.1) Le véritable verdict tombera dans 3 mois, le 13/7/2024

encore mieux car ne dépend pas du cloud ! (sauf pour les mails)

je n'ai pas encore trouvé la cause, mais je reste perplexe avec les date de modif. Car soit il récupère un certificat (et donc c'est le bon), soit il ne sait pas le récupérer (mauvaise config chez moi, ...) et alors je n'ai rien, mais ici je vois les dates de modification => ???

je ne sais pas, regarde la doc du module pour savoir quels paramètres te conviennent. As-tu vu la remarque de @Lazer qui dit que mélanger du 220V (alimentation du module et un contact sec, celà peut être dangereux ? Comme ce module peux également ^tre alimenté en 24V AVC (vérifie dans la doc du module), il serait prudent d'ajouter un petit transfo 220V -> 24V pour alimenter le module

je ne crois pas que c'est le script, car alors ça ne fonctionnerait pas chez @mprinfo. Quand je trouve, je partage ...

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>}