Lazer

La détection de mouvement avec une caméra c'est de plus en plus populaire, de plus en plus de gens, comme toi, veulent utiliser cette fonctionnalité, en bonne partie parce que les fabricants en font de plus en plus la publicité. Mais dans la réalité, ce n'est pas fiable du tout. La technologie n'est pas encore mature, il faut une puissance de calcul considérable embarqué dans la caméra pour réaliser une analyse précise de l'image. On trouve ces fonctions sur les caméras à plusieurs centaines d'euros, et encore, ça resta très approximatif, il y a encore pas mal de loupés. Cela va évoluer dans les années qui viennent, mais je considère qu'on est aux prémices de la technologie. Certains fabricants (Synology) proposent même de déplacer l'intelligence dans le NVR plutôt que dans les caméras... mais bon, à 2000€ le NVR, il faut avoir pas mal de caméras pour le rentabiliser. Et je n'ai pas encore vu de retour d'expérience réel sur ce produit, est-ce vraiment aussi fiable qu'ils le disent ? Bref : - Si ton scénario est juste d'allumer une lumière, ce n'est pas grave si tu as des faux positifs, au pire la lumière s'allumera 1 minute pour rien. - Si en revanche tu souhaites déclencher des scénario de sécurité, tels que notification sur ton téléphone, sirène, ou que sais-je, tu vas vite déchanter. Après, tout dépend de ce que tu recherches. D'abord tu établis ton cahier des charges, l'architecture de ton système, et ensuite tu verras pour trouver un produit compatible avec la HC3, ou pas, auquel cas tu chercheras un moyen de les faire communiquer (via un enregistreur NVR par exemple) Pour te donner une idée, voici ce que j'ai chez moi : - détecteurs de mouvement basiques (type PIR) avec détecteur crépusculaire sur les lampes (ce qu'on trouve en Grande Surface de Bricolage GSB) => parfait pour allumer les lumières automatiquement la nuit. Attention, plusieurs faux positifs chaque nuit, s'allume au moindre passage de chat, lorsqu'il y a trop de vent dans les arbustes, et même parfois quand il pleut fort => totalement inutilisable en scénario de sécurité (même si l'allumage auto des lumières, outre la fonction confort, est déjà un scénario de sécurité en lui-même, car les intrus n'aiment pas être vus) - détecteurs d'alarme évolués (technologie double-faisceau PIR) => ultra fiable, et ultra cher (compter 200€ pièce), parfait pour les scénarios de sécurité et détecteur l'intrusion avant qu'elle n'ait lieu : faire sonner une sirène à faible puissance, fermer les volets, allumer des lumières, notification sur smartphone, etc => j'ai dû avoir 2 faux-positifs en 10 ans. Et j'ai évité plusieurs cambriolages, ils n'ont même pas eu le temps de s'attaquer aux fenêtres, même pas de déclaration d'assurance à faire. - caméras IP alimentés en POE, et branchés sur un NAS Synology pour l'enregistrement des images => la détection d'image n'est pas fiable, plus ou moins au même niveau que les détecteurs PIR simple. L'enregistrement des images sur le disque dur se fait sur détection de mouvement, donc au pire j'ai des images en trop sur les disques, ça ne pose pas de souci, puisque ça ne déclenche pas d'alerte. Et puis il vaut mieux avoir trop d'images que pas assez. Au final, il faut bien comprendre que les caméras sont avant tout un moyen de lever de doute, et d'analyse post-incident, que de prévention (pas mal de cambrioleurs se moquent des caméras, car ils savent que les forces de l'ordre ne les exploitent pas bien souvent) Du coup dans mon système, les caméras forment un réseau d'enregistrement sur NAS qui est indépendant de la domotique, donc je n'ai pas eu à me préoccuper de la compatibilité des caméras avec la box domotique. Au final, j'ai quand même une compatibilité entre les 2, en passant par le NAS/NVR (Surveillance Station) via un QuickApp dédié qui assure la remonté d'information. Pour info il s'agit de caméras Hikvision (il y a un sujet dédié sur le forum), une marque chinoise, l'un (ou le ?) leaders mondiaux du domaine, avec un large catalogue pour tous les besoins (et toutes les bourses). Les derniers modèles permettent même d'enregistrer en couleur la nuit, la qualité d'image est juste incroyable par rapport à ce qui existait il y a quelques années. Les fonctions de reconnaissance de mouvement, présence, visage, etc sont de plus en plus évoluées, mais comme dit précédemment, ça ne reste pas suffisamment fiable pour de vrais scénarios de sécurité, à mon avis. Je précise qu'il s'agit de mon avis, parce que sur les forums ou blogs, tu verras des avis des gens qui en sont pleinement satisfaits, parce qu'ils trouvent qu'un faux positif 1 fois par jour, ou mieux, 1 fois par mois, ça reste acceptable. Ce n'est pas mon cas, je trouve que ça reste d'un niveau inacceptable. Mais comme tu l'as vu, je suis habitué aux alarmes (les vraies, sérieuses) où on est plutôt de l'ordre d'un faux positif tous les 5 ans, voire moins.

Lol, désolé, faute de frappe, je vais corriger

Euh... désolé de te dire ça avec ces mots là, mais.... tu as complètement pété les plombs, ton texte du dessus, c'est de la folie totale. Bref. EDIT : je vais pas citer le message complet, mais c'était en réponse à Sebcbien, pas Fredmas qui a répondu entre temps. Ah ben oui là je suis bien d'accord, c'est justement ce que je dis plus haut.

Ah en fait tu voulais faire un débat open-source close-source ? Non désolé je n'entrerai pas dans ce débat là, je l'ai déjà fait 100x, ça tourne en rond, car au final les 2 cohabitent très bien dans le monde, il n'y a que ceux qui ont des certitudes sectaires que ça dérange. Perso j'utilise les 2, tout comme à peu près toutes les entreprises que je connais, et ça va très bien comme ça.

Tu vois, tu prends encore la mouche Personne n'a dit que Fibaro c'est le top (bon OK, sauf Nico ), d'ailleurs un petit Ctrl+F et personne n'a cité Fibaro sur cette discussion (et même Nico du coup ) C'est marrant, tu parles de certitude sectaire... mais lol alors Dommage ta réaction... EDIT Du coup, je ne sais pas ce que tu attendais, qu'on se désole avec toi que Z-Wave est mort et que Home Assistant c'est l'avenir ? Ben désolé, mais ça, personne n'en sais rien... tout ce qu'on fait c'est alimenter des discussions de comptoir.

Ah oui très bien ça l'utilisation d'un thermostat autonome. Je n'ai jamais testé le Heatit (mais j'ai un Secure SRT-321), je suppose que tu vas donc faire une association directe entre le thermostat et le module. Du coup, tu donnes une consigne au thermostat depuis la box, et ensuite le thermostat se débrouille pour réguler tout seul. C'est donc très fiable. Dans ce cas, tu n'as effectivement aucun besoin de mettre un interrupteur sur le module. Je te conseille même de ne pas en mettre, car si tu as des locataires, ils pourraient jouer avec, et perturber le bon fonctionnement de la régulation (puisque le thermostat ne comprendra pas ce qui se passe)

C'est marrant à chaque fois qu'on parle de Jeedom.... c'est comme remettre une pièce dans la machine Je n'ai pas dit que Jeedom était mort, c'est on coté fanboy qui te fait bondir mais clairement la mode est passée, y'a beaucoup de gens qui ont quitté Jeedom pour aller sur Hass. Il n'y a qu'à aller sur les forum (les autres bien sûr, pas ici) pour s'en rendre compte. Après, est-ce qu'on a des chiffres mesurables des différents solutions ? Je n'en sais rien... je n'ai jamais vu en tout cas. Et on ne peut pas se fier au nombre d'installation, car ça ne reflète pas le parc en cours d'utilisation. Cela dit que Jeedom continue d'évoluer, j'espère bien, le contraire serait malheureux. Et puis ils vont dominer le monde avec l'Atlas Et tu fais une fixation sur open-source, c'est marrant, mais alors pour le coup je ne suis pas vraiment d'accord. Le Wi-Fi n'est pas open-source, pourtant c'est devenu un standard de fait, utilisé par 100% des appareils connectés au réseau IP sans fil. Matter sera Open-Source, tant mieux (parce que ça permettra son adoption par les solutions open-sources telles que HA ou Jeedom) Mais les box open-source, telles que HASS ou Jeedom resteront des trucs de geek comme nous. Le grand public (soit environ 99% des utilisateurs), il ira utiliser des produits fermés (qui utilisent le protocole open-source Matter (et son pendant Thread)) pour utiliser sa domotique.... les écosystèmes Apple, Google, Amazon, etc... et certainement plein d'autres startup à venir qui vont proposer des solutions innovantes pour apporter de l’intelligence à le domotique, et dépasser enfin le stade du module avec un scénario programmé de façon statique pour réaliser telle ou telle action. Par exemple, simulation de présence, apprentissage des habitudes des gens pour chauffer au bon moment, etc. Des choses qu'on fait déjà, mais à la main.

Le module est plutôt très fiable, surtout pour alimenter un radiateur électrique, c'est du résistif pur, très peu de chance de coller le contact du relai. La solution de secours c'est l'interrupteur connecté au module justement, pour pouvoir le piloter en local en cas de panne de la box... car dans ton système, la box c'est de loin l'élément le moins fiable (plantage système, erreur de programmation du scénario, coupure électrique, panne d'internet, etc.... les raisons de panne potentielle sont nombreuses)

Ah oui ? Et ils utilisent quoi comme contrôleur ? Parce que de ma compréhension du marché, le réseau Z-Wave en lui-même est suffisamment fiable pour être proposé de façon professionnelle, mais pas les contrôleurs.... c'est toujours plus ou moins du bidouillage, mais manque de maturité pour être installé de façon pérenne (qui ne nécessite pas X heures de maintenance par an)

Le module n'est pas raccordé à la Terre, mais il faut quand même que tu raccordes bien le radiateur à la terre (en direct donc), avec un domino/Wago

Bienvenue sur le forum

Bienvenue sur le forum

Je suis 100% d'accord avec mes 2 compères au dessus Home Assistant, c'est gratuit (et même moins cher que Jeedom qui fait payer ses plugins et son support), la cible c'est plus ceux qui n'ont pas un gros budget, ou bien qui souhaitent se mettre à la domotique et tester quelques modules dans un coin. Et dans ces 2 cas de figure, Z-Wave n'est pas vraiment adapté. Après c'est sûr, on trouve des gens qui veulent une grosse installation en Z-Wave avec HASS, c'est peut être ton cas, mais surement pas la majorité.... et même surement une très faible minorité.... et pour cela, tu peux ajouter Z-Wave via une clé USB, donc il y en a pour tous les gouts finalement Mais bon... on s'en fout un peu de HA, c'est un contrôleur domotique parmi tant d'autre, ce n'est pas lui qui va orienter le marché d'un coté ou d'un autre. On a l'impression de revivre les discussion d'il y a quelques temps, quand Jeedom était à la mode, à lire les utilisateurs on avait l'impression que c'était l'avenir. Non, c'est juste la solution à la mode à un moment donné. Après, est-ce que Z-Wave va survivre ou pas, il est encore un peu tôt pour le dire. Ce qu'on sait maintenant, c'est qu'il vivra plus longtemps que Zigbee, ce qui est assez amusant quand on repense aux discussions des dernières années où les aficionados de Zigbee présageaient le contraire. Ce qui me désole, c'est que Thread est majoritairement basé sur Zigbee, avec cette foutue fréquence 2.4 GHz encombrée (Wi-Fi et Bluetooth pour ne citer que les 2 plus fréquents).... donc ça va pas mieux marcher que Zigbee. Le coté positif, le protocole Matter qui viendra chapeauter tout ça, ne propose Thread comme n'étant que l'une des solutions pour les modules sans fils. Il est tout à fait ouvert aux autres protocoles comme Z-Wave, mais aussi les protocole propriétaires des différents fabricants membres de l'alliance (IO, etc). Du coup, Z-Wave peut continuer à perdurer techniquement parlant. Mais pour cela, il faut qu'il y ait un marché. D'un coté tu as les installateurs pros qui ne font pas de Z-Wave (plutôt du KNX), et de l'autre le grand public qui va se ruer en masse sur le moins cher (Thread).... il ne reste que les quelques geeks comme nous... pas sûr que ça suffise à justifier la conception et la vente de modules Z-Wave... Bon après, tant que mes modules Z-Wave fonctionnent, je ne me fais pas de souci. C'est tellement fiable qu'on peut les garder 10 ans, et même bien plus... on verra. Aucune raison de les remplacer par du Thread.

Le 500 c'est effectivement du VPN IPSec, mais pour pour le VPN vers les serveurs de Fibaro, mais pour la communication entre plusieurs box HC3/HC3L en mode Gateway (Passerelle) Le 9999 également, pour le même usage. Il s'avère que c'est un port pour des communications WebSocket Source : https://forum.fibaro.com/topic/55619-local-access-can-this-be-used-for-port-forwarding/?do=findComment&comment=236330

Le problème des 2 pages de manuels de Fibaro, c'est qu'elles ne sont pas du tout didactique, donc il faut relire plusieurs fois, tester, bidouiller, et ça force de galérer ça finit par rentrer dans la tête Et aussi, ne pas oublier de chercher sur Google, ce qui nous ramène souvent sur ce forum, ou le forum officiel de Fibaro. Si on regarde le JSON d'un QuickApp (pour rappel : /api/devices/ID), on voit que les labels comme les boutons ont un attribut visible, donc théoriquement on doit pouvoir agir dessus avec les valeurs true/false. Cela dit je n'ai jamais essayé, donc on est en plein dans le cas de figure de ma 1ère ligne : tu testes avec updateView(), et si ça fonctionne, tant mieux Sinon.... tant pis Ou alors il faudra trouver une autre méthode. Il n'y a pas de propriété enable/disable, donc comme le suggère @Fredmas il faut coder sa propre logique en LUA dans le code du bouton... et agir (ou pas) en conséquence. Ce qui est sympa pour l'utilisateur, c'est de mettre un label qui sert juste à afficher une information, par exemple pour dire que l'action demandée est impossible pour telle ou telle raison. En effet, un bouton qui ne réagit pas sans donner de raison, ce n'est guère agréable.

I think it's best to serialize http requests, as @jang suggested. You can use the same name for success() arguments, the LUA compiler will use the last one. But it can be dangerous because it can lead to confusion. A best practice is to use different names.

L'heure courante récupérée avec os.time(), c'est celle du système (gérée par la carte mère avec son propre quartz) En tâche de fond, le démon NTP permet d'aller chercher l'heure à intervalle régulier sur les serveurs de référence sur Internet, et de remettre à le bonne heure l'horloge de la carte mère (qui dérive plus ou moins vite) C'est ainsi que ça fonctionne sur tous les ordinateurs. Les horaires de lever et coucher du soleil sont calculés par Fibaro en fonction de la localisation de la box (coordonnées latitude et longitude configurées dans les paramètres) Quel algorithme de calcul ils utilisent, je n'en sais rien.... Concernant la météo, il y a celle du système (/api/weather) qui est mise à jour à partir de la source configurée dans les paramètres : Dont soit YR Weather par défaut, soit un autre QA importé ou de notre création. Le bout de code que tu as donné, c'est pour mettre à jour les propriétés du module météo (un QA donc visible via /api/devices/ID), pas du système. Pour cela, il faut paramétrer ledit QA comme source de météo comme indiqué dans la capture d'écran juste au-dessus. Donc non, si on veut être précis, ton bout de code ne permet pas de "modifier les sources d'information du contrôleur", mais seulement d'ajouter une nouvelle source.... pour modifier la source, là encore, capture d'écran ci-dessus Bref, la météo, tu peux modifier la source à ta convenance. L'heure système et les horaires de coucher/lever du soleil, tu ne peux pas. Encore heureux. Ou alors tu modifies ton fuseau horaire et ta localisation, mais en réalité tu n'as pas changé les heures, mais juste "déplacé" la box dans l'espace.

En pratique aucune. Si ce n'est que dans #3, ta variable http est globale. Perso j'ai tendance à utiliser la solution #1 avec self.

Non.... !!! Parce que même si net.HTTPClient() est une fonction, ce qu'elle retourne n'est pas une fonction (mais une table), donc elle n'est pas publiée et aucun risque qu'elle soit exécutée depuis l'extérieur du QA. Donc ta variable self.http reste interne au QA. Elle est de type "table", et quand tu veux l'utiliser tu exécutes l'un de ses éléments appelé "request", qui est de type "function" => self.http:request(...)

En fait le principe de base est relativement simple, puisque ça consiste à appeler une fonction en lui donnant un paramètre, ce paramètre est une variable de type "function" (pour rappel en LUA, les fonctions sont des variables au même titre que les autres type : string, table, number, etc) La fonction appelée s'exécute... puis à un moment elle va exécuter la fonction qui lui a été donnée en paramètre (le paramètre que j'ai appelé "callback" dans mon exemple) Une fois que tu as compris ça, il n'y a plus de limite, tu peux enchainer les rappels de fonctions à volonté.

Bienvenue dans le monde merveilleux de l'asynchronisme Il faut utiliser une fonction de rappel (callback) : function QuickApp:onInit() self:debug("onInit") end local function currentData(callback) print("This function is checking regularly current meteo") local http = net.HTTPClient() http:request("http://...", { success = function() --blabla local jsonTableCurrent = json.decode(response.data) callback(true, jsonTableCurrent) end, error = function(msg) --blabla callback(false, msg) end, } end function mainCode(self) self:debug("This function is checking regularly the meteo for prevision") currentData( function(success, data) if success then self:debug(data.name) else self:error("ça s'est pas bien passé :", data) end end ) end Tu constates qu'il y a une première fonction de rappel lors du retour de http:request..... celle-ci en appelant une seconde, la tienne. C'est ultra puissant, mais pas évident à maitriser au début. Maintenant tu peux aller approfondir avec le sujet suivant : Et aussi celui-ci qui va prendre de l'importance à mesure que tu utilises des fonctions réputées pour planter de temps en temps (httprequest et json.decode) : Remarque : définir http à chaque passage de boucle n'est pas judicieux. Il vaut mieux le définir une seule fois à l'initialisation du QA, donc dans onInit, et l'utiliser par la suite. A ce sujet, voir la page 2 de 1er tuto dont j'ai donné le lien ci-dessus, on a abordé cette problématique.

C'est ça. Enfin dans la limite du courant supporté par le relai quand même. Mais pour tout ce qui est éclairage LED par exemple, ça sera ok.

ça a déjà été discuté avec @jjacques68 et une astuce donnée par @jang pour importer / mettre à jour automatiquement un fichier dans les QA. Mais perso je ne suis pas fan du tout, car ça empêche de partager facilement ses QA sur le forum (à cause des dépendances, le QA n'est plus autonome). Et une mise à jour du fichier pourrait très bien casser la compatibilité avec tous les QA existants. En effet, une évolution d'une fonction de la librairie pourrait par exemple prendre des arguments différents ou retourner des valeurs différentes et faire planter un QA qui utilisait une précédente version. Après si vous êtes rigoureux, dans le principe la solution est bonne. @jjacques68 avait fait un tuto :

Sur le forum officiel (indisponible là tout de suite...) dans la section dédiée à cette version du firmware. En ce moment, ils sont à l'écoute. EDIT : voilà le forum est de retour : https://forum.fibaro.com/forum/1279-update-5080/

Ouais je peux pas résister à la dernière nouveauté Et puis si la gestion des relais est réellement améliorée, avec protection contre les courants de démarrage et mesure de consommation, ça me permettra de retirer quelques contacteurs de puissance et pinces ampèremétriques, donc simplifier mon installation et faire de la place dans le tableau