Lazer

Oui voilà... entre cette complexité, et le fait qu'un jour ça s'arrêtera de fonctionner (comme tout service cloud), perso j'ai choisi de passer mon chemin. Mais si tu veux absolument faire du TTS, tu n'as guère de choix, les solutions 100% locales et autonomes sont pour ainsi dire inexistantes.

Le transfert de box se fait obligatoirement par le Cloud de Fibaro (fichier de backup chiffré que tu ne peux pas transférer en direct)

OK et bien utilise le tuto de @jojo alors

ça veut dire quoi émuler Google Home ? je suppose que tu veux dire le faire parler ? Moi j'en suis resté au classique : Google Home c'est fermé, impossible de lui faire dire ce qu'on veut. Cela dit @jojo a partagé un tuto pour le faire parler de façon détourner, tu es surement déjà tombé dessus dans tes recherches sur le forum. Perso je trouve ça bien trop compliqué. NEST c'est fermé aussi, l'API a été supprimé il y a quelques années. Google quoi. Les méchants GAFA. Qui te font croire que c'est ouvert, sauf qu'en fait ils ne sont ouverts qu'avec eux mêmes Bref pas de solution simples à part d’horribles bidouilles, qui vont être complexes à maintenir, et arrêteront de fonctionner quand Google décidera encore de changer sa politique. PS : C'est mon avis à moi, rien qu'à moi, il y a des millions de gens qui sont heureux avec un Google Home et un NEST dans leur maison.

Les QA avec Child devices, c'est un peu complexe au début à mettre en place, faut comprendre comment ça marche. Mais après c'est puissant, avec en effet un code unique pour tous les QA enfants, la maintenance est simplifiée, la consommation mémoire aussi, et également la conso CPU si c'est correctement codé (une seule boucle de mise à jour) après tu peux aussi faire des child "idiots", c'est à dire sans code particulier (uniquement la fonction _init() requise), puis les mettre à jour comme tu faisais avec les Fake, c'est à dire en passant par l'API.

Ah voilà, tu vois ! Tant mieux, m'enfin tu aurais utilisé la fonction urlencode() que je t'ai proposé d'utiliser depuis ce matin ça aurait été plus vite

oui ça fonctionne très bien En GET avec callAction et setProperty : /api/callAction?deviceID=259&name=setProperty&arg1=power&arg2=370 Normalement tu peux modifier n'importe quelle propriété de cette façon.

oui OK mais il faut toujours que tu fasses un urlencode() A vue de nez, rien que les espace dans ton message "This is external event" ne sont pas valides dans une requête function urlencode(str) if str then str = string.gsub(str, "\n", "\r\n") str = string.gsub(str, "([^%w %-%_%.%~])", function(c) return string.format("%%%02X", string.byte(c)) end) str = string.gsub(str, " ", "+") end return str end Puis : local url = urlencode("https://ADRESSEDUSYNO/webapi/entry.cgi?api=SYNO.SurveillanceStation.ExternalEvent&method=Trigger&version=1&eventId=1&eventName=This_is_external_event1&account=LOGIN&password=PASSWORD") http:request(url, { -- la suite ...

Ouh là là, poubelle c'est pas écolo ça Idée de réutilisation : vu que le FGK-101 a un bornier pour contact sec, le module peut servir pour domotiser n'importe quel capteur, interrupteur sans fil, etc.

"minor bugfixes"

Ah trop fort, merci @TonyC A ma décharge, c'est sur la 2nde ligne, moi j'arrête la lecture à la 1ère (en fait je cherchais dans les panneaux de configuration... donc pas au bon endroit... c'était tout simplement dans les ajouts de "dispositifs")

Oh les beaux Discus En effet pour la sonde du Secure, j'avais oublié ce détail d'importance ! Dans ce cas, je chercherais du coté de Qubino, ils ont un micro-module ZMNKID1 Flush On/Off Thermostat 2 avec sonde déportée. Je pense qu'il ne fera pas de PID, mais si tu peux régler un hystérésis de 0.2°C, tu auras le résultat que tu voulais. A chercher dans la doc. https://www.domadoo.fr/fr/peripheriques/4971-qubino-micromodule-thermostat-encastrable-z-wave-zmnkid1-flush-onoff-thermostat-2-3830062071710.html https://qubino.com/products/flush-on-off-thermostat-2-2/

Détecter les erreurs et protéger l'exécution d'un script LUA avec pcall() Il existe déjà un vieux sujet de @Shad, mais je vais essayer d'être un peu plus exhaustif, en prenant en compte les nouveautés apportées par les scènes sur HC2 puis les QuickApp sur HC3 : l"utilisation de la librairie net.HTTPClient() et l'exécution asynchrone du code LUA. Autre sujet détaillant l'utilisation de net.HTTPClient() à lire au préalable : Durant l'exécution d'un script LUA, une erreur peut survenir, susceptible de planter le script, celui-ci s'arrête alors brutalement et la suite du code n'est jamais exécutée. Je paraphrase l'explication de @Krikroff : Pour faire simple: La fonction pcall() permet l’exécution du code en mode "protégé" ou "encapsulé", c'est à dire qu'il ne lèvera pas d' erreur dans le processus de votre box si jamais le code provoquait une erreur. Ainsi, le fil d'exécution des Scènes et des QuickApps est protégé. Aussi à savoir: pcall() retourne true ou false en fonction de la réussite du code mais peut aussi retourner un résultat issu de la fonction en utilisant la méthode interne error(). La fonction pcall() peut-être utilisée pour faire en LUA l'équivalent du try...catch pour ceux qui connaissent. Des exemples ici pour comprendre : Programming in LUA : 8.4 - Error Handling and Exceptions Programming in LUA : 8.5 – Error Messages and Tracebacks Exemple n°1 : protection de http:request() Le premier usage de pcall() est pour protéger l'exécution de la fonction http:request() car celle-ci peut planter, par exemple si l'URL est mal formée : local http = net.HTTPClient() local url = "http://192.168.1.1/chemin/page?argument=valeur" local status, err = pcall(function() http:request(url, { success = function(response) -- Suite des traitements... end, error = function(err) -- Gestion de l'erreur (connexion impossible) end, options = { -- options éventuelles... } }) -- http:request() end) -- pcall() if not status then -- Gestion de l'erreur attrapée par pcall() print(err) end Exemple n°2 : protection de json.decode() De plus, pcall() est également très utile (voire indispensable) pour une autre fonction qui a la fâcheuse habitude de planter : json.decode() si le JSON donné en argument est mal formaté. Exemple : local status, jsonTable = pcall(function() return json.decode(response.data) end) if status then -- Suite des traitements... else print(jsonTable or "json.decode() failed") end Dans cet exemple, la variable jsonTable contiendra soit le tableau décodé (résultat de json.decode()), soit le message d'erreur (résultat de pcall()) Exemple n°3 : protection complète de http:request() et json.decode() Par ailleurs, il faut noter que dans le premier exemple avec http:request(), les fonctions success() et error() sont des fonctions de callback appelées après l'exécution de la requête, donc elles sont asychrones. De ce fait, leur contenu n'est plus protégé par la fonction pcall(). Par conséquent, si on combine les 2 exemples précédents, à savoir la requête HTTP, puis le décodage du résultat JSON, cela donne une structure de code comme suit : local http = net.HTTPClient() local status, err = pcall(function() http:request(url, { success = function(response) local status, jsonTable = pcall(function() return json.decode(response.data) end) if status then -- Suite des traitements... else print(jsonTable or "json.decode() failed") end end, error = function(err) -- Gestion de l'erreur (connexion impossible) end, options = { -- options éventuelles... } }) -- http:request() end) -- pcall() if not status then -- Gestion de l'erreur attrapée par pcall() print(err) end De cette façon, le code LUA est parfaitement protégé. Exemple n°4 : interruption conditionnelle de l'exécution avec assert() La fonction assert() permet de tester une condition. Si la résultat est false, dans ce cas elle déclenche l'erreur qui sera attrapée par pcall() : local http = net.HTTPClient() local status, err = pcall(function() -- Ici mon code s'exécute et effectue plein d'actions... local device = api.get("/devices/127") assert(type(device) == "table", "Le module 127 est introuvable") -- Suite du code si tout se passe bien... end) -- pcall() if not status then -- Gestion de l'erreur attrapée par pcall() print(err) end Dans cet exemple j'ai testé si le résultat d'un appel à api.get() s'est bien passé, mais on pourrait tester n'importe quel autre cas de figure. Exemple n°5 : interruption inconditionnelle de l'exécution avec error() La fonction error() permet de forcer le déclenchement d'une erreur qui sera attrapée par pcall() : local http = net.HTTPClient() local status, err = pcall(function() -- Ici mon code s'exécute et effectue plein d'actions... if ma_condition then error("Un message d'erreur") end -- Suite du code si tout se passe bien... end) -- pcall() if not status then -- Gestion de l'erreur attrapée par pcall() print(err) end J'espère que ce petit tutoriel sera utile, vous pouvez maintenant utiliser pcall() dans vos code, combiner les différents exemples ci-dessus, etc.

Et bien le Secure SRT 321 (je crois que la nouvelle version Z-Wave+ c'est SRT 322) Il a une régulation PID qui sera beaucoup plus précise que ton hystérésis de 0.2°C que tu décris dans ton expression de besoin. Car si tu as un tel hystérésis, avec l'inertie, tu risques d'avoir des variations de températures beaucoup plus importantes... surtout avec un aquarium, ça a une grosse inertie (quelle capacité d'ailleurs par curiosité ? J'avais un 450 litres avant de me mettre à la domotique) Le Secure, tu fais une association directe avec un module type relai (ils vendent le leur, mais on peut utiliser un micro-module Fibaro FGS 213 ou 214), et il va réguler la température tout seul, avec l'algorithme PID qui prend en compte l'inertie. Remarque : je n'ai jamais refait mon aquarium, mais si un jour je m'y remet, j'avais plutôt envisagé de le domotiser avec un IPX800 installé dans le meuble en dessous, dédié à cet usage. A la place des bons vieux programmateurs mécaniques sur prise 230V. Avec ses capteurs et actionneurs, il pourrait piloter en tout autonomie l'aquarium, de façon totalement autonome et super fiable : - capteur de température => régulation de température - gestion des éclairages en fonction des horaires - mesure PH - etc

Netatmo, le script n'est pas de moi, j'ai juste ajouté quelques bricoles supplémentaires (les niveaux de batteries), mais bon, ça n'a jamais posé problème, et il fait un appel http toutes les 10 minutes, donc rien de méchant, ça ne posera jamais de problème. Pour Network Monitor, il faudra en effet que je fasse une nouvelle version... plus tard

Je pense qu'il n'aime pas les doubles quotes dans l'URL, il faudrait que tu fasses un urlencode() de ta chaine avant de la donner à http:request() Mais je suis surpris quand même, est-tu certain de la nécessité de mettre des guillemets ? J'utilise l'API Synology pour d'autres usages, et je n'ai jamais eu besoin... et c'est même carrément pas standard comme pratique, en général on utilise uniquement des caractères classiques dans les URL, autant que possible.

Ah ouais, très étrange comme comportement. En premier lieu assure toi d'avoir un backup (local et en cloud). Ensuite, tu pourrais tenter un recovery afin de réinstaller proprement le système, puis restaurer ta dernière sauvegarde. Peut être que ça remettra les choses d'aplomb

@jjacques68 j'ai l'impression que tu n'as pas compris ce que j'ai écris. Moi je parlais des différences que tu trouves à partir du test n°2. Le test n°1, tout va bien, donc il n'y a rien de plus à en dire

Merci, petit update du graph

Sans certitude, mais je me demande si cette différence entre les route réellement empruntée et la route stockée dans l'API, ne serait pas dû à la différence entre la route dans le sens Contrôleur => Module, et la route dans le sens Module => Contrôleur. Il faudrait tester les 2 cas de figure : - envoi d'un ordre depuis la box - envoi d'un retour d'état depuis le module Ainsi tu verrais si la route empruntée est la même dans les 2 cas. Et sinon, tu sauras à quelle direction de route correspond l'information stockée dans l'API.

Quand tu dis "Plus aucun moyen d'accéder à l'interface PC ou Smartphone", concrètement il se passe quoi ? Tu voir la mire de login, aucune connexion possible, un code d'erreur genre 503, les boules bleues ? Est-ce que la box répond au ping quand elle est plantée ?

Maintenant que tu le dis... Je viens de tilter En janvier j'ai eu une panne d'Internet (fibre coupée pendant quelques jours) Donc Network Monitor ne pouvais plus joindre Google, et faisait plusieurs tentatives, avant de me notifier. Ce que je ne comprenais pas, c'était pourquoi de temps en temps, aléatoirement pendant toute cette période, Network Monitor me signalait également des machines sur mon LAN en erreur (alors que tout fonctionnait parfaitement en local). Donc maintenant c'est clair, il faut avoir un seul self.http = net.HTTPClient() dans tout le QuickApp, il gère parfaitement la situation lorsque de nombreuses requêtes sont exécutées pseudo-simultanément. Ce qui n'est pas le cas lorsqu'on a plusieurs instances de HTTPClient dans des variables différentes. Voilà, là on a appris un super truc

Faut bien comprendre que le fonctionnement sans neutre est un hack inventé à l'époque des lampes à incandescences.... et ça n'a jamais bien fonctionné avec les LED. Au mieux, ça "marchote", au pire ça ne fonctionne pas du tout J'insiste, d'autant plus si tu veux domotiser toute ta maison, il faut que tu passes le maximum de neutre dans les gaines existentes. Il en restera bien quelques unes pour lesquelles il y a un coude trop prononcé empêchant de passer le fameux fil de neutre, tant pis pour celles-ci, mais au moins du auras la majorité de tes ampoules qui fonctionneront bien en LED. Ou alors tu fais comme moi, un gros stock d'ampoules à incandescence / halogènes, et tu en profites (en fait je mixe avec des LED, mais le moins possible, et uniquement là où j'ai le neutre) Ta lampe témoin ça ne n'en sais rien, elle est intégrée à ton interrupteur, tu l'as soue les yeux, pas moi.... ça diffère d'un modèles à l'autre. Chez Legrand elle se clipse et se retire, chez d'autres je ne sais pas.

Essaie d'enlever la lumière témoin de l'interrupteur, elle n'aime pas le courant de fuite imposé pour retourner vers le neutre. Sinon, la meilleure solution c'est de passer un fil de neutre pour t'affranchir de tous ces problèmes... mais pas simple à mettre en œuvre (aiguille en nylon, lubrifiant, et pas mal d'huile de coude)

Oui et non... ça dépend... Si seulement 2 fonctions ont besoin de se partager la table, autant la passer en paramètres Si par contre toutes les fonctions d'un même QuickApp sont susceptibles d'utiliser cette même table, alors autant l'attribuer au QuickApp (self.xxx) Je ne saurais dire quelle méthode est meilleure que l'autre, mais c'est plus du bon sens et de l'organisation logique du code.