Lazer

Tant mieux. J'avais eu un souci similaire, une inclusion compliquée (obligé de m'y reprendre à plusieurs fois) avait corrompu la base de données, dont les effets de sont fait sentir 15 jours plus tard : box instable ou je ne sais plus quoi précisément. Je crois qu'elle avait crashée lors de l'inclusion suivante. Heureusement que je fais un backup chaque semaine et que je les garde longtemps.

Ah oui tient, pourquoi ? Je voulais surtout limiter la pression dans mon ballon. L'arrivée d'eau générale, pour l'instant je n'ai pas osé y toucher (et j'ai eu raison vu ma mauvaise expérience... C'est jamais sympa de devoir démonter)

De mémoire il y a effectivement une espèce de gros filtre, mais vu l'épaisseur de la grille, faudrait y aller pour le boucher. Perso j'avais eu une baisse de pression sur le circuit d'eau chaude, c'était à cause du réducteur de pression... un modèle de grande surface de bricolage. S'il y a un bien truc que j'ai retenu, à part pour les tuyaux, tous les équipements "actifs" (réducteurs de pressions, manomètres, mitigeurs, etc), il ne veut JAMAIS les acheter en GSB, c'est de l'argent perdu (et du temps). En tout cas tu es bon pour un démontage de ton circuit.

Ah voilà une nouvelle intéressante : le prix de l'IPX800 v5 est annoncé entre 290 et 340€ avec tarif préférentiel pour les préventes. Donc ça monte, et pas qu'un peu, mais c'était prévisible. Source : https://forum.gce-electronics.com/t/la-doc-de-lipxair-est-en-ligne/12648/20

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.