Lazer

Pour info : tarif de lancement annoncé de l'IPX Air à 199€ TTC Source : https://forum.gce-electronics.com/t/la-doc-de-lipxair-est-en-ligne/12648/20

Welcome to the forum

Je ne sais pas... je suppose que oui Après le transfert la box source est réinitialisée complètement, comme une box neuve, donc dans la théorie tu peux faire le transfert dans l'autre sens. Je n'ai jamais testé perso, ma box d'origine fonctionne toujours.

Oui, moi j'y crois à moitié (à moitié car j'ai envie d'y croire bien sûr, et l'autre moitié parce que les précédentes tentatives ont été un échec car les enjeux commerciaux et la volonté de garder les clients captifs dans un écosystème propriétaire sont trop fortes) Donc on verra. En attendant, d'ici à ce que ça sorte, et que Fibaro l'implémente, il va se passer très longtemps. Depuis quelques temps je vois que tu ne postes que sur ces sujets... on dirait que Z-Wave ne te plait pas, du coup je me demande ce que tu fais encore chez Fibaro ? Dans ce cas tu trouverais surement plus chaussure à ton pied avec une autre box domotique, non ?

Pas de souci Je précise que le copyright fait référence à une vieille blague, je ne sais même plus de qui, on va dire que c'est collectif à tout le forum. Cette phrase est la réponse type depuis des années qu'on répète 10x sur chaque topic de chaque firmware de chaque box depuis la V3. Un running gag quoi (mais qui est sérieux quand même, c'est un vrai conseil et un réflexe à avoir pour chaque mise à jour)

Orange, la boite qui est totalement larguée, qui a changé au moins 3 fois de protocole domotique, tu parles d'une référence Leur métier, ce sont les télécoms, et ils le font très bien. Pour tout le reste, ils sont totalement à la rue Concernant Fibaro on en a parlé récemment, ils attendent de voir ce que CHIP va donner avant de s'y mettre, mais en tout cas ils surveillent de près, quitte à laisser tomber Zigbee du coup. Reste à savoir si CHIP sortira vraiment, et quand. Puis ajouter pas mal de temps pour que Fibaro embauche un stagiaire développeur à mi-temps

Vide ton cache ® EDIT : grillé, c'est le temps de chercher le symbole copyright ça

Héhé, quand on se prend au jeu, on a vite fait d'installer plein de modules Si tu achètes une HC3 plus tard, tu pourrais effectivement mettre la HC3L en mode passerelle derrière la HC3, et tout piloter de façon unifiée depuis la HC3. Ou bien la revendre et tout piloter avec la HC3 qui en a les capacité. C'est surtout la distance physique avec le local piscine qui guidera le choix. Mais si ton réseau est bien maillé, théoriquement tu peux couvrir de grandes surfaces avec un seul réseau Z-Wave (donc 1 seule box) Pour ton problème d'accès distant, là je sais pas trop.... tu peux tenter de demander au support Fibaro : support@fibaro.com

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