Bebitoo

Bonjour, Pour compléter ce qui est dit plus haut, pour ceux qui tomberaient sur ce thread : pour contrôler son Thermostat Netatmo depuis une Fibaro HC3, en l'absence d'un QA ad 'hoc, et plutôt que de s'en créer un, on peut passer par un Home Assistant intermédiaire. En effet, il existe une intégration Netatmo pour Home Assistant. En quelques clics, j'ai vu remonter sous HA mon thermostat Netatmo (avec ses programmes de chauffe) et (en bonus) ma station météo Netatmo. Et HA expose une API. Test OK depuis Bruno : interactions sur le thermostat via l'API HA. "Plus qu'à" faire ces appels depuis la HC3 (et faire un QA simple ?). Bien sûr, créer un QA (directement) client de l'API Netatmo semble également possible (et préférable) : l'authentification sur l'API Netatmo est en OAuth2 maintenant, mais sauf erreur c'est aussi le cas pour la station météo, et il existe au moins 2 QA opérationnels pour la station météo. --- David

C'est fait. @Sankotronic, Thanks for sharing your insights. I agree Fibaro is very good at what it does. I wish it does more Like: the zigbee soon-to-come support was part of my incentives to upgrade my HC2. There's plenty Zigbee devices on the market, often cheaper as their Z-Wave siblings, I and was/am liking the idea of having more choice (I would have more smart plugs on for instance, on lower contraints and non mandatory use cases, if they weren't 60€ each). And almost 4 years later, I'm still not using the (few) Zigbee capabilities of the HC3...

Hi @Sankotronic, I started with an HC2 10 years ago, and got an HC3 4 years ago. I switched slowly (like: within a year or so), and HC2 is now shut down (ready to be reset to the factory presets, and put for sale... but never managed to do it ). I think that's awesome that you (and others) are developing for HC3. I think HC2 remains a great box, so think/hope there's still some (lower?) demand for HC2. To address my calendar-to-heating-schedule project mentionned above, out of curiosity, I just gave a try to Home Assistant (on a Proxmox box for now). The Netatmo "integration" exists and is quickly set up: got both weather station and thermostat on HA! I also integrated (quite as quickly) my iCloud calendar. Now ready to start developing something (I mean: as soon I as understand how it can/should be done on Home Assistant). Also integrated my HC3 into HA: many (if not all) of my HC3 stuff seem available within HA. Don't know yet if I should: stick to HC3, try developing a Netatmo Thermostat QA (using your weather station QA as a source of inspiration, on the OAuth part), and if I success, the Lua scenario should be quick (I've got some experience), start learning scenarios on HA, then develop one for my need... and if it's a success : keep both boxes, HA complementing HC3 (and the other way around)? start migrating to HA, and retire the HC3 if I can get everything working on HA (which I probably can)? Advice appreciated

Hi @Sankotronic, Thanks for your answer. My home heating installation is as simple as possible . Several hot water radiators, a gas boiler, and a Netatmo thermostat. No connected valves on radiators ; all (regular) valves always fully opened. And the thermostat located on the main room drives it all. Got a main heating planning set up on the Netatmo Energy app / website, tailored to my family needs. Looking to integrate the Thermostat into my HC3, to automatically adapt to the unusual days ans situations. For instance: - confort feature: switch back to the confort temperature sooner, when one child gets back home earlier than usual, because of a professor being missing, - economy feature: turn the heating off every day I work from my company headquarters, when I was supposed to work from home. Any clue why a Netatmo thermostat QA doesn't exist yet? Thanks -- David

En français J'utilise un thermostat Netatmo, et ne trouve pas de QA me permettant de l'intégrer sur ma HC3 (comme j'ai pu le faire précédemment avec un VD sur ma HC2). D'après mes recherches : en Octobre 2022 Netatmo a changé de manière conséquente la méthode d'authentification à ses APIs (Passage à l'OAuth2), changement qui a nécessité que les développeurs fassent évoluer leur applications (et QA) pour les rendre compatibles. Ce travail a été fait pour la station météo Netatmo (par @Sankotronic, @GSmart, @Lazer notamment - merci), mais pas pour le thermostat. Et je ne vois pas de différences sur les APIs de Netatmo, entre station météo et thermostat, pouvant expliquer cela (Cf. par exemple ici : https://dev.netatmo.com/apidocumentation/oauth). Je suis également tombé sur un QA Legrand BTcino (=> Netatmo ?) annoncé compatible uniquement avec la Yubii Pro, et non la HC3 (Cf. https://marketplace.fibaro.com/items/bticino-connect). Ma question est : pourquoi n'existe-t-il pas de QA HC3 pour le thermostat Netatmo ? La demande est insuffisante ? Ou bien est-ce que le thermostat impose un prérequis supplémentaire, impossible à réaliser sur la HC3 ? Ou bien est-ce simplement que j'ai raté ce QA que je recherche ? Merci d'avance.

Hi, I use a Netatmo Thermostat, and can't find any QA to integrate it into my HC3 (as I did previously with a VD on my HC2). From my readings: Netatmo did a big change in October 2022 in order to increase the security of their APIs (they moved to OAuth2 authentication), big change which required developers to go back to coding and update their (Quick)Apps accordingly. The job has been done for the Weather Station (see quoted message above, for instance - and thanks @Sankotronic, @GSmart, @Lazer, and others), but not for the Thermostat. And authentication on Netatmo APIs, be it for the Weather Station or the Thermostat, look the same to me (see here: https://dev.netatmo.com/apidocumentation/oauth). And I also came across a Legrand BTcino (=> Netatmo ?) QA said to work only on the Yubii Pro, not the HC3 : see https://marketplace.fibaro.com/items/bticino-connect. My question is: why is there no HC3 QA available for the Netatmo Thermostat? No demand? Does the Thermostat requires something more, which can't be done on a HC3? Or am I simply missing the QA I'm looking for?

Bonjour sebueno, Sur ta photo, on vois que les gonds sont (alignés et) très proches du bord. Trop proches, je pense. Il écarter les gonds, et allonger les pentures (les ferrailles plates fixées sur les volets). "60 mm" c'est la préco du vendeur de moteurs (me souviens plus) ? Je sais que moi, je suis un peu en dessous des précos, et on a galérer à cause de ça : mes murs sont en briques, et la brique cassait jusque dans l'angle. Par contre, si tu écarte les gonds du bas, faut écarter pareil les gonds du haut : sinon, les volets ne pourront pas s'ouvrir (ce sont là les dures lois de la physique ).

Bonjour, J'avais raté cette portion de la doc Si ça peut en aider d'autres, la voici (en v7.36) : -- "Time" : Teste l'heure courante -- SYNTAXE : {"Time", <from>, <to>} -- CONDITIONS : GEA.add( {"Time", "22:00", "23:00"} , 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes dans la tranches horaires \\ Check only if in schedule GEA.add( {"Time", "07:00", "08:00"}, {"Time", "22:00", "23:00"}, 30, "", {ACTIONS} ) -- Ne vérifie QUE si nous sommes dans LES tranches horaires \\ Check only if in THE schedule GEA.add( {"Time", "Sunrise+30", "Sunset-15"} , 30, "", {ACTIONS} ) -- Si tranche horaire : lever du soleil + 30 mins, coucher du soleil - 15 minutes \\ Check only if Sunrise more than 30 mins and sunset less 15 mins GEA.add( {"Time", "Sunrise>07:30", "Sunset<21:00"} , 30, "", {ACTIONS} ) -- Si tranche horaire : AU lever du soleil SI après 7h30, sinon à 7h30; Au coucher du soleil SI AVANT 21h SINON à 21h \\ Check if Sunrise is after 7:30 otherwise 7:30 ; check if Sunset is before 21:00 otherwise 21:00 GEA.add( {"Time", "Sunrise-10>07:30", "Sunset+10<21:00"} , 30, "", {ACTIONS} ) -- Si tranche horaire : AU lever du soleil moins 10 minutes SI après 7h30, sinon à 7h30; Au coucher du soleil plus 10 minutes SI AVANT 21h SINON à 21h \\ Check if Sunrise less 10 minutes is after 7:30 otherwise 7:30 ; check if Sunset more 10 minutes is before 21:00 otherwise 21:00 GEA.add( {"Time", "22:00"} , 30, "", {ACTIONS} ) -- Équivaut à {"Time", "22:00", "22:00"} \\ Idem to {"Time", "22:00", "22:00"} -- ACTIONS : Ne peut pas être utilisé comme ACTION Et j'ai bien aimé la proposition de nasp, en exprimant l'horaire de fin également avec Sunrise, et un test. Du coup, j'ai ça : {"Time", "Sunrise - 15 > 07:00", "Sunrise > 07:15"} et cela fonctionne bien depuis quelques jours, avec actuellement (en hiver) une ouverture des volets vers 7:45. A confirmer (mais y'a pas de raisons) que cela continuera de fonctionner cet été, avec une ouverture à 7:00 seulement, bien que le le soleil se lève bien avant . Et il n'y a que sur les 15 minutes suivant l'ouverture des volets qu'un redémarrage de la box ou de GEA provoquerait une (nouvelle) ouverture des volets : ça va (et rien ne m'empêche de réduire cette durée). Merci pour ces aides collectives

Bonsoir, Oui, mais comment comprendre ce test dans l'heure de début et/ou de fin ? Je comprends qu'ainsi j'obtiendrais une ouverture des volets si je relance GEA entre 7:00 et 10:00, ou entre Sunrise et 10:00, mais comme tu le proposes dojo, je verrais cette partit plus tard. J'essaie. J'essaie aussi NB : d'après mes précédents tests, les espaces n'influent pas. J'ai d'ailleurs les règles suivantes, qui fonctionnent très bien : -- gestion de la variable globale Soleil GEA.add({"Time", "Sunrise - 15", "Sunrise" }, 0, "", {"Global", "Soleil", "levant" }, "Soleil : [levant] levé couchant couché ") GEA.add({"Time", "Sunrise" , "Sunset" }, 0, "", {"Global", "Soleil", "levé" }, "Soleil : levant [levé] couchant couché ") GEA.add({"Time", "Sunset" , "Sunset + 15"}, 0, "", {"Global", "Soleil", "couchant"}, "Soleil : levant levé [couchant] couché ") GEA.add({"Time", "Sunset + 15", "Sunrise - 15"}, 0, "", {"Global", "Soleil", "couché" }, "Soleil : levant levé couchant [couché]") Mais j'essaie sans espaces désormais. Résultats des tests demain matin

Bonjour, Je rencontre une difficulté à la mise en oeuvre d'une condition qui me parait totalement prévue et supportée par GEA. Je dois rater quelque chose. Je sollicite votre aide. Je souhaite ouvrir mes volets, le matin, lorsque les 2 conditions suivantes ont remplies : il est l'heure le soleil se lève (NB : ma traduction de "soleil levant", en GEA, est : Sunrise - 15) Par exemple, un jour de semaine, l'heure qui me va est 7h. Eh bien, je souhaite que : l'été, les volets s'ouvrent à 7h seulement - bien qu'il fasse jour depuis 6h30 par exemple (pour ne pas être réveillé en avance), l'hiver, les volets s'ouvrent au lever du soleil, vers 7h30 par exemple - pour préserver l'intimité (volets ouverts, lumière allumée, mes voisins voient super chez moi) le tout sans qu'une relance de GEA ou de la box, en journée, n'ouvre ou ne ferme les volets* (GEA est en autostart), et sans changer la condition entre les saisons, bien sûr * j'ai une règle similaire, pour fermer les volets le soir : dès qu'il fait nuit (l'hiver) ou à 21h Il y a quelques mois (c'était quand je testais GEA sur ma HC3, et avait encore toute ma domotique sur la HC2), j'avais testé avec succès (pour autant que je me souvienne), la condition suivante : {"Time", "07:00", "Sunrise - 15 > 07:00"} mais actuellement, elle m'ouvre les volets à 7h00 J'avais un peu galéré à aboutir à cette condition, et étais noté : -- NB : ne semblent pas fonctionner ou produire le résultat attendu -- les syntaxes sans heures de début et de fin - ex : {"Time", "Sunrise - 15 > 07:00"} -- les créneaux horaires sans test sur l'heure de levé/couché du soleil - ex : {"Time", "Sunrise - 15", "07:00"} Qu'est-ce que je rate ?

Bonjour, C'est fait. Merci de m'avoir fourni l'adresse

Bonjour, Pour info, idem chez moi : HC3 depuis février, mais seulement (je dirais) 5% de la bascule effectuée (quelques modules et un peu de code), pour essayer, mais la HC2 est toujours en service, car j'ai des reboot intempestifs de temps en temps.

@Lazer, en faisant une passe pour remettre les photos qui avaient disparues de mes messages, j'ai réalisé que je n'avais pas répondu à cette question, désolé. Les moteurs à l'arrêt sont assez forts : - pour garder les volets en position ouverte, sans devoir les attacher avec les loquets, - et les garder en position fermée, sans devoir verrouiller avec la crémone. Mais ils ne sont pas verrouillés "aussi fort" qu'avec une crémone (bien ajustée). Un voleur réussira probablement à glisser ses doigts derrière la partie en recouvrement, pour tirer un grand coup... et tout arracher. Bon, ce faisant, il fera du bruit. Avec la crémone verrouillée il devrait casser quelques lamelles (mes volets sont persiennés) pour glisser une main et déverrouiller la crémone. Ce serait bruyant également (plus ? moins ?). Lors d'absence plus longues (incluant une nuit d'absence), je verrouille les crémones, et obtient ainsi (j'ai l'impression) une meilleure sécurité : crémone + moteurs. Et (dispositif de sécurité imparable) : je continue de croiser les doigts

Bonjour @ablyes, Oui J'ai vu que les photos de mes précédents posts ne s'affichaient plus (sauf à cliquer dessus), donc peut-être n'a-tu pas lu tout ce fil de discussion. Je viens de prendre le temps de modifier tous mes messages pour ré-inclure les photos. Je te conseille à minima la lecture du message suivant : Le montage est simple (surtout, maintenant qu'il est connu à l'époque je questionnais le fabriquant des motorisations, qui disait ne pas connaitre et pouvoir s'engager sur la domotique, et posait des questions sur ce forum et à Fibaro directement, où personne ne connaissais mes motorisations). Il est durable aussi : ça fait maintenant 7 ans qu'il fonctionne. Et voir le massage de @Lazer ci-dessus : Mes doubles switch Fibaro sont alimentés en 24V ! Je pense aussi qu'il n'y a pas de 230V au niveau du bouton filaire : sans domotique, et n'est branché qu'au module de gestion des 2 volets (que tu appelles switch dans ton message précédent), qui est alimenté en 24V, et avec domotique, il est branché sur le double switch Fibaro, lui-même branché sur le module de gestion et le 24V. Moi je n'ai pas placé le double switch Fibaro derrière l'interrupteur, mais dans une boite étanche placée dans les combles perdus, au dessus de la paire de volets. - Cette boite contient le double switch Fibaro et le mode de gestion des volets (et le câblage entre les deux). - En entrée de cette boite : 2 fils qui apportent le 24V. - En sortie de cette boite : les 3 fils qui descendent vers l'interrupteur (et éventuellement un repiquage des 2 fils d'entrée pour amener le 24V à la boite suivante).

Bonjour, Je ne suis pas sûr de comprendre la question Si c'est pourquoi pas des Qubino, au lieu des Fibaro... je ne connais pas les Qubino, ne sait pas quels avantages ils peuvent avoir sur les Fibaro. Les Qubino existaient déjà à l'époque ? Je suis partis sur des Fibaro, après avoir fait le choix de Fibaro pour la box (une HC2). Et les modules fonctionnent très bien encore aujourd'hui (7 ans après), et je devrais pouvoir les basculer sur ma nouvelle HC3 sans problèmes. Donc plutôt content de mon choix. Si c'est pourquoi pas des 24v... mes modules (Fibaro) sont alimentés en 24V. J'ai 1 transfo (1 seul) pour alimenter mes 5 motorisations de volets, et mes 5 modules Fibaro. Si c'est pourquoi pas uniquement des Qubino 24V sans les modules des moteurs des volets battants... chaque paire de moteur (1 moteur par volet battant) est fourni avec 1 (et un seul) module qui gère le timing d'ouverture des 2 battants (le volet avec recouvrement s'ouvre en premier et se ferme en dernier, une fois la procédure d'apprentissage/initialisation réalisée). Ils étaient inclus ; je ne pense pas qu'on puisse acheter les moteurs sans. Il "suffit" de brancher des relais double switch dessus pour lancer les commandes d'ouverture et fermeture, en gardant les interrupteurs d'origine fonctionnels. Un montage sans les modules des moteurs ne diminue probablement pas les coûts, et ajoute des em...m3rd3s (à supposer que c'est possible). C'est sans intérêt je pense. Si j'ai répondu à côté, précises la question SVP.

Excellent merci ! Je regardais de mon côté en parallèle, et : API OpenWeatherMap : la version gratuite de l'API semble permettre d'obtenir le volume de précipitations de la veille... mais pas pour ma géolocalisation (pas de champ current.rain dans la réponse, lors de mon test) Weatherbit : sauf erreur, les données historiques sont soumises à souscription (et c'est pas donné). AccuWeather : le endpoint get24HoursConditionsByLocationKey semble être là pour ça (une fois sa "location key" récupérée, par requête sur un autre endpoint), mais n'ai pu tester encore : je me suis inscrit, mais n'ai pas reçu ma clé d'usage de l'API. Modification du QA Un fork de la toute version 1.2, en utilisant pour J-1 le volume de précipitation prévisionnel obtenu la veille pour J (et ainsi de suite pour J-2) ? Ou bien (nouvelle idée) : création un autre Quick App simulant le pluviomètre Netatmo - valorisé à partir de l'une des méthodes ci-dessus, et indiquer son ID dans les paramètres du QA Arrosage ? Comme ça, pas de motif / fork du QA arrosage Je continue de fouiller dès que possible. --- David

Bonjour, Un peu la même question que un peu plus haut : faute de pluviomètre (Netatmo), que conseilleriez-vous ? Une API Web qui donne la quantité d'eau sur les deniers jours (en mm/jour) ? Modifier le QA pour mémoriser, chaque jour, la prévision WeatherBit du lendemain ? Merci d'avance. --- David PS : je télécharge et installe en parallèle

En effet Et je viens de les enlever. Ce Quick App en l'état est bien pour des ouvertures et fermetures totales, pour éclairer / assombrir la pièce lorsqu'on en ressent le besoin. Mais il reste basique. Le slider ne fonctionne pas (sauf si positionné à 0 ou 100), et il semble mal réagir sur des enchainements de commandes (c'est peut-être à cause des mes setTimeout pour mettre à jour les icônes seulement à la fin des ouvertures/fermetures). J'y reviendrais...

Bonjour, C'est une super idée l'interrupteur branché sur le double relais lui même branché sur le KLF-050 du vélux : c'est aussi pratique que la télécommande (qu'on laisse toujours au même endroit), et les "retours d'état" deviennent fiables. Mais j'ai tout ce petit matériel dans les combles perdus, donc ça demanderait un peu de travail à passer des câbles. Sinon, pour le QA volet, je me suis lancé, et j'ai fais quelque chose de très simpl(ist)e. J'utilise le modèle Fibaro d'un roller shutter. Le Quick App est ainsi listé comme un volet dans les IHM Fibaro (cool), et l'icône est bien mis à jour. Alexa le reconnait, et le rideau obéit aux commandes "Alexa, ouvre/ferme le rideau du vélux". Un retour d'état (ou plus exactement une mémorisation de la dernière commande reçue, ou de la position actuelle du rideau) est facilement réalisable. Par contre je ne gère pas les positions intermédiaires pour le moment (je n'en ai pas besoin, mais il le faut pour que les IHM avec les sliders fonctionnent), et sauf erreur les boutons que j'ai créé... ne servent à rien -- Roller shutter type should handle actions: open, close, stop -- To update roller shutter state, update property "value" with integer 0-99 function QuickApp:open() fibaro.call(self.openDeviceId, "turnOn"); fibaro.setTimeout(self.openDelay, function() self:debug("roller shutter opened") self:updateProperty("value", 99) end) end function QuickApp:close() fibaro.call(self.closeDeviceId, "turnOn"); fibaro.setTimeout(self.closeDelay, function() self:debug("roller shutter closed") self:updateProperty("value", 0) end) end function QuickApp:stop() fibaro.call(self.openDeviceId, "turnOff"); fibaro.call(self.closeDeviceId, "turnOff"); self:debug("roller shutter stopped ") end -- Value is type of integer (0-99) -- NB : bizaremment, cette méthode elle celle invoquée par Alexa, avec les valeurs : -- 0 sur "Alexa, ferme le rideau du vélux", et -- 99 sur "Alexa, ouvre le rideau du vélux" function QuickApp:setValue(value) if (value <= 0) then self:close() elseif (value >= 99) then self:open() else self:debug("roller shutter set to: " .. tostring(value)) self:updateProperty("value", value) end end -- To update controls you can use method self:updateView(<component ID>, <component property>, <desired value>). Eg: -- self:updateView("slider", "value", "55") -- self:updateView("button1", "text", "MUTE") -- self:updateView("label", "text", "TURNED ON") -- This is QuickApp inital method. It is called right after your QuickApp starts (after each save or on gateway startup). -- Here you can set some default values, setup http connection or get QuickApp variables. -- To learn more, please visit: -- * https://manuals.fibaro.com/home-center-3/ -- * https://manuals.fibaro.com/home-center-3-quick-apps/ function QuickApp:onInit() self:debug("onInit") -- Les id des devices déclenchant l'ouverture et la fermeture du rideau de vélux, -- et les délais d'ouverture et fermeture sont des variables de ce Quick App ; -- on récupère leur valeurs... self.openDeviceId = tonumber( self:getVariable("openDeviceId" ) ) self.closeDeviceId = tonumber( self:getVariable("closeDeviceId") ) self.openDelay = tonumber((self:getVariable("openDelay" ) - 2)*1000) self.closeDelay = tonumber((self:getVariable("closeDelay" ) - 2)*1000) end -- Release Notes -- 03/05/2021 -- Première version d'un Quik App "rideau vélux" -- de type Roller Shutter => il apparait bien en tant que volet dans les IHM Fibaro -- ToDo : gérer les positions intermédiaires ?

@Lazer, Tu listes (vous listez ?) en première page, dans la catégorie "à faire" : Je suis fortement et doublement intéressé - "doublement", parce que j'ai cet exact besoin (1 volet roulant sur un vélux avec un KLF-050 et un double-switch), mais aussi des volets battants motorisés avec également des double-switch, - "fortement" parce que c'est la fonctionnalité majeure en domotique chez moi : la gestion des volets (5 battants, 2 roulants, et 1 rideau de vélux). J'ai envie de me lancer dans la création de QA ad'hoc, et me demandais si tu pouvais me conseiller en amont - histoire que j'arrive plus rapidement et plus facilement à un bon résultat, et qui serait pour pour toi au moins, je l'espère, une v1. Es-tu d'accord ? Perso, j'en suis à prendre connaissance de la HC3 et des QA, mais par la pratique (autrement dit : je me suis amusé, jusque maintenant, avec ma HC3 toute neuve). Prochaine étape : lire les documentations qui vont bien sur les QA, comprendre le fonctionnement et l'intérêt de QA enfants, et décider si c'est utile dans ce cas (pour la télécommande de centralisation ?). Ce que j'ai aujourd'hui, sous HC2 : des modules virtuels comme celui-ci : Autrement dit, pour chaque volet battant et pour le rideau du vélux : - Un bouton Ouvrir (respectivement Fermer) qui fait simplement un call "turnOn" sur l'entrée du double switch qui ouvre (resp. ferme). - Notez l'icône du VD lui-même : volets ni ouverts ni fermés avec un point d'interrogation par dessus. C'est pour l'init, il n'est affiché qu'au redémarrage de la box, le temps d'ouvrir ou de fermer. - Et notez l'icône des boutons : volets mi-ouverts mi-fermés. - Et j'ai également une scène (unique) qui surveille les ouvertures et fermetures de ces volets battants, et (entre autres) change l'icône du VD pour un icône représentant les volets ouverts (respectivement : fermés) à l'ouverture (resp. fermeture). - Enfin, je cache les doubles switch de l'interface. Au final, j'obtiens : - Non pas un retour d'état au sens strict du terme, mais une mémorisation de la dernière commande réalisée (ouverture ou fermeture) - ce qui correspond, quasi systématiquement, à la position réelle des volets. - Une animation assez cool (raison d'être des icônes) : pour des volets ouverts par exemple (l'icône représente les volets ouverts), lorsque je clique le bouton Fermer, l'icône change d'abord pour les volets mi-ouverts mi-fermés (c'est l'icône du bouton) puis par l'icône représentant les volets fermés (une fois que la scène s'est déclenchée) . Ce qu'il manque : - La possibilité de "typer" ces VD comme des volets, pour bénéficier des avantages inhérents dans les IHM Fibaro : voir en un coup d'oeil si tous les volets sont fermés, pouvoir les ouvrir tous d'un coup, etc. Chose qui devrait être possible avec les QA, n'est-ce pas ? - Pour le rideau du vélux, un icône (et une mémorisation de la position) qui ne correspond pas toujours avec la réalité, car l'utilisation de la télécommande d'origine ne me mets par à jour l'icône du VD (contrairement à l'usage des boutons des volets battants et roulants). Mais là, c'est lié au montage double switch et KLF-050, rien de mieux n'est possible (sauf erreur). @Lazer, comment vois-tu la conversion en QA de tels VD ? Merci d'avance. --- David

Bonjour @Lazer Et désolé pour la réponse tardive (je n'ai pas été notifié, pour une raison que j'ignore). J'ai moi aussi très peu de charge sur cette HC3, étant au tout début de la migration depuis la HC2 : 3 devices Z-Wave, 2 de plus encore sur la HC2 et "simulés" par QA, 2 caméras, et 5 QA, trouvés ici principalement, parfois bruts (uniquement paramétrés), parfois customisés : GEA, Karotz, Jour Férié, iCalendar, Onduleur. Pas de reboot depuis mon post initial, il y a une semaine (comme quoi ). Pourtant, aucun changement ces derniers jours (par manque de temps). Je reste attentif, et poste ici les nouveaux éléments. N'hésitez pas à en faire autant --- David

Bonjour @manuxenon, Oui, j'ai résolu ce point pour moi, en même temps que j'ai un peu modifié le QA de @Dragoniacs pour le prendre en main et le mettre "à ma sauce" (et du coup, les noms des méthodes et variables du code ci-dessous ne correspondent peut-être pas au QA original - mais ce sont les principes qui importent). Comme le dit @Dragoniacs, le cas d'usage n°1 est d'appeler le code TTS depuis... n'importe où . Pour cela, le QA du lapin expose une fonction Parler qui prend en argument la phrase à prononcer : function QuickApp:Parler(phrase) self:setVariable("TTS", phrase) -- mémorisation de la phrase à prononcer self:openKarotzTTS(phrase) end et que l'on appelle, depuis GEA par exemple, avec : GEA.add(true, 0, push, {"QuickApp", id["Lapinou"], "Parler", "G.E.A. est actif sur votre HC3"}, "Démarrage GEA") Et pour les tests ou vérification de bon fonctionnement (cas d'usage n°2), le QA du lapin dispose d'un bouton configuré pour appeler une fonction onParler lorsque relâché, dont le code est : function QuickApp:onParler() -- on récupère le contenu de la variable TTS, pour la faire prononcer... phrase = self:getVariable("TTS") self:Parler(phrase) end J'ai donc : cas d'usage n°2 = clic sur bouton du QA : onParler, qui récupère la valeur courante de la variable TTS, pour la passer en argument de Parler. cas d'usage n°1 = TTS depuis n'importe où : Parler qui, pour info ou analyse/debug si besoin, mémorise la phrase passée en argument dans la variable TTS (oui, c'est ridicule dans le cas d'usage 2 : elle y est déjà ), puis appelle la fonction "interne" pour faire prononcer la phrase au lapin sous OpenKarotz (nécessite la construction de l'URL tts de OpenKarotz, raison pour laquelle je l'ai nommé OpenKarotzTTS). Le code de OpenKarotzTTS (largement inspiré de celui de @Dragoniacs - encore merci ) : function QuickApp:openKarotzTTS(text2speech) tools:Message("trace", text2speech) -- voice voice = "1" -- text text = text2speech text = string.gsub(text, "\n", "\r\n") text = string.gsub(text, "([^%w %-%_%.%~])", function (c) return string.format("%%%02X", string.byte(c)) end) text = string.gsub(text, " ", "+") -- cache nocache = 0 -- ToDo: utiliser le cache ? -- URI local URI = "tts?voice="..voice.."&text="..text.."&nocache="..nocache -- appel self:openKarotz(URI) end

Bonjour, J'ai une HC3 depuis quelques semaines, et monte en compétence et bascule mes modules de la HC2 à la HC3, doucement. L'une de mes premières scènes déployée est celle de @mprinfo (merci :)) notifiant du démarrage de la HC3. Eh bien... cette scène me permet de m'apercevoir que ma box redémarrage parfois... toute seule. Je dirais que ça m'arrive 1 fois ou 2 par semaines. Est-ce que d'autres possesseur de HC3 sont dans le même cas ? Merci d'avance.

HC3-00015897 Commandée le 28/01/2021 (hors stock - expédiée le 05/02)

Bonjour, Sauf erreur, le bouton TTS (qui doit faire prononcer au lapin le texte de la variable TTS du QA) ne fonctionne pas, et fait crasher le QA, qui se relance ensuite (et le lapin fait faire un tour à ses oreilles). Je vois dans la console : [09.03.2021] [19:03:55] [TRACE] [QA_KAROTZ_31]: UIEvent: {"elementName":"btnTTS","values":[],"eventType":"onReleased","deviceId":31} [09.03.2021] [19:03:55] [DEBUG] [QA_KAROTZ_31]: ./include/main.lua:65: attempt to concatenate a table value (field 'TTS') [09.03.2021] [19:03:55] [ERROR] [QUICKAPP31]: QuickApp crashed [09.03.2021] [19:03:55] [ERROR] [QUICKAPP31]: Unknown error occurred: handleJsonRpc [09.03.2021] [19:04:00] [TRACE] [QA_KAROTZ_31]: QuickApp OpenKarotz - Initialization [09.03.2021] [19:04:01] [DEBUG] [QA_KAROTZ_31]: onAction: {"deviceId":31,"args":[],"actionName":"onReset"} [09.03.2021] [19:04:01] [DEBUG] [QA_KAROTZ_31]: onAction: {"deviceId":31,"args":[],"actionName":"onSPEED"} Par contre, aucun soucis pour le faire parler depuis le QA GEA, avec la ligne suivante : GEA.add(true, 0, "test TTS OpenKarotz", {"QuickApp", id["MonOpenKarotz"], "onTTS", "Bonjour. Je suis la voix de votre HC3 !"}, "test TTS OpenKarotz") Suis-je le seul ? Bon, après rien de très grave, parce que l'usage principal (voire unique) est depuis d'autre QA ou scènes Edit: le code qui pose problème : function QuickApp:onTTS(message) self.TTS = self:getVariable("TTS") if message ~= nil then self.TTS = message end tools:Message("debug","Enonciation de la phrase : "..self.TTS) local voice = "1" self.TTS = string.gsub(self.TTS, "\n", "\r\n") self.TTS = string.gsub(self.TTS, "([^%w %-%_%.%~])", function (c) return string.format("%%%02X", string.byte(c)) end) self.TTS = string.gsub(self.TTS, " ", "+") local URL = "http://"..self.IP_KAROTZ.."/cgi-bin/tts?voice="..voice.."&text="..self.TTS:gsub(" ", "+").."&nocache=0" if (self.TTS ~= "") then self:sendKarotz(URL) end end Sauf erreur, l'idée est que ce soit le même code qui soit exécuté lorsque appelé depuis l'extérieur, ou lors d'un clic sur le bouton interne du QA (avec l'usage de la variable TTS). Mais dans le cas interne, le self:getVariable("TTS") renvoie une table (et non un string) qui pose problème à la concaténation avec "Enonciation de la phrase : " pour le message de debug, et pour le gsub 2 lignes après, etc...