Lazer

Ah bah justement, un petit article récent à ce sujet : [Cnews] Cambriolages : attention, ces méthodes de hacking d'alarme se répandent Par contre, aucune statistiques chiffrées, si ce n'est une source qui s'avère être un vendeur d'alarmes... m'enfin venant de ce site "d'informations", une information fiable aurait été étonnante Sinon oui : la geekerie, c'est la vie ! (la prochaine fois faudra faire ce poème en alexandrin)

Cool le concert, c'est sympa d'avoir un chanteur sous la douche dans ton jardin

OK je comprends... de mon coté j'ai pris le réflexe de toujours regarder le log, d'ailleurs c'est une des améliorations de GEA sur HC3, le log coloré, l'affichage des triggers qui ont été détectés, etc. Et j'attends 5 minutes pour être certain qu'il affiche justement le message dont je parlais. Le label je l'avais ajouté suite à des demandes ici-même, mais comme dit, il ne peut pas t'indiquer le fonctionnement réel de GEA. Seulement le fonctionnement théorique. Perso je n'ai pas besoin d'interrompre le fonctionnement de GEA volontairement.

Oui effectivement, encore un truc qu'on pourrait préciser dans la doc. Bon à la base c'était une doc de syntaxe des options de GEA, afin de servir de référence en complément du forum, mais peu à peu ça se transforme en doc universelle ! Sinon le label Running, bah... c'est juste un label ! Si GEA plante, le label conserve sa dernière valeur connue... ce n'est certainement pas GEA qui va mettre à jour le label, vu qu'il a planté. Et je rappelle que ce label en particulier permet de savoir si GEA fonctionne ou bien s'il a été suspendu temporairement avec les boutons dédiés, pas de savoir si GEA a planté (ce qui n'est pas censé arriver...) Détecter le plantage d'un script LUA, c'est loin d'être aussi trivial. Tu ne te souviens peut être pas sur HC2, mais les VD avaient une fâcheuse tendance à planter fréquemment... raison pour laquelle j'avais développé un Watchdog. Et la seule solution fiable de détection de plantage que j'avais trouvé, c'était de surveiller le log des VD.... tant qu'un message préformaté apparait à intervalle régulier, alors le VD est toujours en vie. Si le message n'apparait plus, alors il est planté, donc on force le redémarrage. C'est le principe d'un "heartbeat" en informatique. Et bien sur HC3, c'est pareil... si tu veux détecter le plantage d'un QuickApp, il faut un heartbeat, et là encore, le meilleur moyen à mon avis c'est d'analyser le log. Il se trouve que j'avais porté mon Watchdog sur HC3 au début, mais je l'ai abandonné car les QuickApp sont très stables. GEA ne plante jamais en pratique. Là tu es dans un cas particulier où GEA plante dès le premier cycle (à cause d'une erreur de syntaxe de l'une de tes règles). Plantage que tu peux immédiatement détecter de visu dans le log. Une fois que tu as corrigé ta règle, le plantage devrait disparaitre, et les cycles de GEA s'exécutent normalement. Et sans activité (aucun déclenchement de règles), tu verras le message "GEA fonctionne depuis " apparaitre à intervalle régulier (toutes les 5 minutes)

La voie officielle c'est l'email : support@fibaro.com Sur le forum officiel, les équipes ne participent que quand ils ont le temps... c'est un espace communautaire.

Dommage. Demande au support, ça ne coute rien, et tu n'auras pas de regret de tout réinclure s'ils ne peuvent pas le faire une migration.

Ce n'est pas un bug, mais une erreur de syntaxe. Tu ne peux pas donner un tableau d'ID à ta condition "TurnOff", il te faut utiliser 4 conditions distinctes.

Alors autant le Z-Wave est très facile à brouiller (voir mon retour d'expérience), autant une alarme l'est beaucoup plus, surtout si elle est bi-fréquence. Je ne sais pas si tu te rends compte de la taille d'un brouilleur nécessaire pour couvrir un volume de 4 maisons. Le jour où tu vois une camionnette avec 10 grandes antennes sur le toit et une caisse qui frotte sur les pneus à cause du poids des batteries contenues dans le coffre tu auras une petite idée. Du coup, t'avertir par email sera la dernière de tes préoccupations car les mecs auront le niveau CIA++ pour rentrer où ils veulent Mon propos, c'est qu'un brouilleur qui tient dans la main couvre une toute petit surface. Pour une alarme, il faut qu'il soit littéralement collé au capteur à brouiller (et que lui). Pour du Z-Wave, je n'ai pas poussé assez loin mes tests pour déterminer la distance de couverture.... mais si ça couvre la moitié de la maison c'est déjà bien. En pratique, est-ce que des cambrioleurs ont déjà utilisé ce mode opératoire ? Ou est-ce un simple fantasme de geek ? EDIT : attention aussi à gérer les fausses alertes. Je n'ai pas testé le RFPlayer donc je ne sais pas comment il se comporte en pratique, mais il ne s'agirait pas de t'envoyer une alerte parce que le gamin d'à coté joue avec la télécommande de son drone ou que le voisin a laisser appuyé le doigt sur la télécommande de sa télécommande de portail. Car ce sont des cas de figure basiques qui peuvent entrainer une fausse détection de brouillage.

Que veux tu dire par "sécuriser" la bande des x MHz ? Parce que là comme ça, j'ai envie de te répondre : non. Ce n'est pas un appareil magique, tel les pierres cosmiques et autres patches anti-ondes.... Il va détecter un brouillage. Jusque là OK. Mais ensuite, comment le traiter ? Il faut remonter l'information en filaire (forcément) vers la box domotique, et ensuite il faut que celle-ci aie un moyen filaire 'également) de déclencher des moyens de dissuasion (sirène filaire, flash filaire, etc...) et de communication (on oublie Internet, car si le cambrioleur est suffisamment équipé pour venir avec un brouilleur, on se doute bien qu'il aura coupé le fil téléphonique/fibre) En fait, je crois que j'ai résumé la raison pour laquelle je n'ai jamais mis en oeuvre ce RFPlayer. Au delà de l’exercice "amusant", en pratique c'est difficile de monter un système cohérent de bout en bout. D'autant plus que je suis déjà équipé d'une alarme NFA2P, donc elle-même protégée contre le brouillage. Et que comme mentionné dans mon expérience, elle est relativement complexe à brouiller. Je mets ici la chaine d'un Youtubeur qui teste beaucoup d'alarme, c'est une vraie mine d'or tant les informations sur la VRAIE sécurité des alarmes sont inexistantes sur le Web. https://www.youtube.com/@choisir-son-alarme Je n'ai pas tout regardé, mais il en ressort que Diagral semble être l'alarme la mieux protégée contre les brouillages, mais qu'elle n'est pas parfaite pour autant (notamment la sirène extérieure). Et ce qui est très intéressant, c'est que suite à ses vidéos, Diagral a sorti un nouveau modèle de sirène corrigeant la problème. Alors là chapeau. Chapeau à @choisir-son-alarme, et chapeau aussi à Diagral. Tout cela a un prix... élevé ! Tu en trouveras toujours sur le Web pour te dire qu'ils ont réussi à faire aussi bien avec un Arduino, Home Assistant, un fer à souder, un bout de scotch, et un code pondu par ChatGPT, et tout cela pour 10 à 100x moins cher. J'aimerais bien voir en vrai le résultat. Si on est pragmatique, on en revient aux problèmes de bases : qu'y a-t-il à protéger chez moi, contre quoi je veux me protéger, quelle prix je donne à ma sérénité, etc car finalement on n'a pas tous les mêmes besoins. Par contre, on est tous voisins les uns des autres, et chaque été en août, ceux qui ont posé une alarme à 2 balle à l'arrache avant de partir, qui se met à sonner non-stop le lendemain, et cela pendant 3 jours d'affilée (parce qu'après il n'y a plus de piles ) c'est irritant, et surtout inutile car les cambrioleurs ne sont pas des idiots (enfin si un peu sinon ils auraient une autre activité... )

Que je l'ai justement acheté pour tester cet usage, et qu'il est dans sa boite depuis X années car je procrastine...

Ah oui OK. Alors c'est facile, c'est interdit. Ton circuit de prises électriques est protégé par un disjoncteur de 16 ou 20A. Si tu installes un modules qui ne supporte que 10A, alors il y a danger d'incendie. Car le module sera invisible (puisque encastré), qu'est ce qui te garantie que personne ne viendra jamais brancher un gros appareil dessus ? Bon après tu fais ce que tu veux, on en a vu pas mal sur les forums le faire.... mais il faut juste rappeler le danger. Ensuite, un FGS, si on fait abstraction du risque d'incendie, techniquement ça fonctionne, puisque c'est un relai mécanique, qui laisser passer le courant ou le coupe. Mais un FGD, qui est un dimmer (gradateur en bon français), l'appareil branché dessus ne va pas aimer du tout.... le FGD non plus d'ailleurs, qui risque fort de griller en même temps que l'appareil. Accessoirement, on en revient au problème initial, le FGD-212 ne supporte que 1.1 A... (250W) seulement.

Ben, je viens de te dire.

Fibaro Wall Plug ou Walli Outlet Selon si la pose en applique te convient, ou si tu as besoin de quelque chose d'encastré. La Walli a en outre l'avantage de supporter 16A.

Ok merci. Effectivement ça refonctionne ce matin

Depuis ce jour, le 13 juin 2023 à 22h, mon QuickApp Netatmo a perdu la connexion, code HTTP 503, indiquant un "Service non disponible". Chez vous aussi ? Serait-ce lié à la suppression de l'ancienne API ?

Sans log c'est compliqué.... - relance-le - supprime des règles - allume un cierge - achète un chien

Non pas de raison que le relai change d'état en cas de brouillage. Simplement, la domotique ne pourra plus changer l'état du relai, donc activer ou désactiver l'alarme pendant toute la durée du brouillage. Mon petit retour d'expérience :

Welcome to the forum

Un brouilleur, non, tout ce qu'il fera, c'est brouiller les ondes radio, donc empêcher les communications de la domotique, ou de l'alarme, ou de tes claviers/souris sans fil, ou de ton téléphone, casque Bluetooth, etc... ou bien tout ça en même temps. Si l'alarme est auto-protégée (NFA2P), alors elle réagira au brouillage en déclenchant les moyens de protection... dans une certaine limite, voir l'excellente chaine Youtube : https://www.youtube.com/@choisir-son-alarme

Effectivement Je crois avoir vu un topic à ce sujet sur le forum officiel, dans la section liée à ce firmware beta. EDIT : ici : https://forum.fibaro.com/topic/65977-aeotec-multisensor-6-no-longer-working-after-soft-reconfig-reconfig/

Le fait d'avoir changer d'usage de ce PC ne met pas forcément en évidence le problème. Exemples de pannes très fréquentes sur les ordinateurs : - alimentation sous-dimensionnée (par design, ou par fatigue des composants) : si on a un usage trop intense de la machine (vidéo, jeu, etc), on tire sur l'alim, qui ne suis plus, le PC manquant de courant va planter/rebooter. Je l'ai constaté très fréquemment à l'époque où j'étais plus jeune, on montait des PC avec de gros composants (la course aux MHz...), mais avec l'alim la moins cher possible. Plus récemment, sur le forum, à chaque fois que l'alimentation d'une HC2 fatigue, ça occasionne des reboots intempestifs, voire l'impossibilité de booter tout court quand l'alim est vraiment HS. La tension à vide mesurée est OK, mais dès qu'on tire un peu dessus, l'alimentation s'effondre. - barrette RAM défectueuse... là aussi ce sont des pannes intermittentes, tant qu'on n'utilise pas la case mémoire concernée, pas de souci. Mais plus on va charger la mémoire, plus on risque de tomber dessus (raison pour laquelle les serveurs et stations de travail haut de gamme sont équipés de barrettes à correction d'erreur) Finalement le mieux (ou le pire c'est selon) ce sont les pannes de stockage (disque, SSD), car là c'est généralement clair et net, des pannes bien franches. Le pire, c'est les données perdues si on n'a pas fait un backup préalable.

ça semble ressembler à une panne matérielle de l'ancienne box quand même... corroborée par certains retours sur le forum officiel.

Tout ça c'est pareil, après tu choisis l'écriture qui te convient le plus : local ma_variable_test = json.decode(apiResult).production[2].wNow local ma_variable_test = json.decode(apiResult).production[2]["wNow"] local ma_variable_test = json.decode(apiResult)["production"][2].wNow local ma_variable_test = json.decode(apiResult)["production"][2]["wNow"] Perso j'aime la simplicité et la lisibilité, je préfère la première syntaxe. J'évite les crochets autant que possible, avec nos clavier Azerty c'est l'enfer... Dans une précédente vie j'ai eu l'occasion de travailler avec un clavier Qwerty, c'est le bonheur pour programmer ! Toutes les touches sont au bon endroit !!! Idem pour les accolades, antislash, arobase, etc... toutes ces touches "cachées" derrière la touche Alt-Gr de nos claviers Azerty. A la place, on a des accents... on n'a pas gagné au change Pour Enphase, tu as toujours l'URL "/production.json" ? Je croyais qu'elle avait été supprimée, raison pour laquelle je n'ai pas partagé mon QuickApp.... Si ça fonctionne toujours, je vais le partager, ça te fera gagner du temps, et pas qu'à toi.

C'est possible : - Un clic simple (99% des usages) => le volet s'ouvre ou se ferme à fond - Un autre clic simple pendant la manœuvre => le volet s’arrête en cours de route Après ça dépend des usages, perso je ne manœuvre jamais un volet à mi-course manuellement. Quand ça arrive, c'est sur scénario géré automatiquement par la box. Exemple typique : en été pour limiter les effets du soleil. C'est aussi ça la domotique

Au lieu de ["1"], utilise [2] car c'est le 2nd élément du tableau indexé (en LUA les index numériques commencent à 0... contrairement à beaucoup d'autres langages de programmation) Dans l'absolu, ça serait plus propre de parcourir les éléments du tableau pour identifier celui qui concerne la production, car rien ne garanti qu'il sera toujours à l'index 2, cela peut être interverti avec les inverters. Exemple (la variable response contient le tableau JSON décodé) : for _, v in ipairs(response) do if type(v.measurementType) == "string" and v.measurementType == "production" then -- Traitement... end end