Lazer

Mouais... non... en fait l'assurance elle s'en fout, c'est avant tout notre problème. Dans le meilleur des cas elle remboursera la valeur des biens volés et les dommages causés, mais bien souvent moins.... sans compter le traumatisme. Et puisque tu parles de cambriolage, le rôle de la caméra n'a jamais été de les éviter, mais uniquement de faire de la lever de doute, et de l'analyse post-événement (= ce dont il est question dans notre discussion) Perso aucune intrusion n'a donné lieu à un cambriolage jusqu'à présent, merci les lumières automatiques du jardin, et l'alarme extérieure Les caméras m'aident à comprendre le mode opératoire des intrus et à améliorer la pré-détection et les scénarios de dissuasion active.

Oui mais tout est bon là, c'était @henri-allauch qui avait des événements en double, à cause de sa première écriture qui relançait les requêtes avec setInterval()

last=lastResfresh peut arriver par exemple si aucun nouvel événement durant la temps d'attente de la requête le problème n'est pas d'avoir last=lastResfresh mais d'avoir des événements en double, ce qui n'est pas censé arriver EDIT : bon bah voilà @jjacques68 tu fais les questions/réponses tout seul

Même, ça ne change rien. En journée, même une définition en 2K, ou intermédiaire en 4MP (donc à mi-chemin entre 2K et 4K.... ouais faut pas confondre les pixels et la définition horizontale), est suffisante pour identifier l'individu quand tu vas porter plainte et qu'on te montre une planche de photos. Par contre, la nuit, le gain de sensibilité est indispensable pour identifier correctement. Essaye d'identifier le mec quand tu as une bouillie de pixels, tous les détails sont mangés par le bruit numérique du capteur.... c'est pas simple. Les Megapixels ne t'apportent aucune aide dans cette situation (et justement c'est l'inverse, c'est le surplus de pixels qui est responsable de la mauvaise qualité d'image) Ma préférence est claire : une meilleure sensibilité en basse lumière est plus importante qu'une définition élevée, car elle permet de répondre à tous les cas de figure. Et puis, on est en train de comparer un capteur 4MP avec un capteur 8MP (4K), en pratique ça fait une très faible différence sur les détails de l'image (et ne pas oublier les défauts de l'optique qui n'est pas parfaite). Par contre ça fait une grosse différence sur la perte de sensibilité. C'est pas comme si on comparait avec une image 720p (soit 1MP environ) des vieilles caméras (ma Foscam dans la maison est encore comme ça !) Autre truc tout con, mais finalement pas si con que ça, la ColorVu permet de garder les couleurs (absence d'éclairage infra-rouge), et dans mon cas, le capuche orange du gars était un des éléments supplémentaires qui a été spécifié sur le PV, et ça faisait une concordance de plus dans le signalement qui correspond à l'individu attrapé plus tard dans la même nuit par les flics.

Merci Bon j'ai encore du mal à identifier les fonctionnalités présentes sur chaque aspirateur, idéalement il faudrait que je complète ma collection de logs, si quelqu'un a un autre modèle (par exemple S5 Max, S6, S6 Pure, S7, ...) je veux bien le log détaillé, merci. Ah oui et aussi il faut que je t'ajoute le nettoyage des zones et le Goto, c'est ça ? Comment tu avais fait pour calculer les coordonnées ? Tu as utilisé la méthode de @ADN182 ? Il n'y a pas plus simple ?

Elles existent les ColorVu en 4K (enfin je ne sais pas si elles sont dispos à la vente), mais comme j'expliquais, la sensibilité est inférieure (raison physique, et confirmé par la datasheet) Après tout dépend ta priorité : - tu veux un max de définition en pleine journée => 4K - tu veux une meilleure qualité d'image la nuit => 2K Perso mon choix est fait, les malfrat s'introduisent majoritairement la nuit, c'est à ce moment là que j'ai besoin de reconnaitre les visages. J'ai relaté il y a quelques pages la difficulté que j'ai eu à identifier un individu au commissariat, malgré que l'image de ma précédente caméra était déjà supérieure à 99% des caméras des gens. Parce que la tête du livreur Amazon / La Poste / Sushi en haute résolution, je m'en cogne un peu... M'enfin vous faites comme vous voulez, cette discussion me rappelle furieusement les débats stériles en photo (d'abord les appareils photos, puis maintenant les smartphones), des partisans du plus gros chiffre est forcément le meilleur.

Cool Tu pourrais m'envoyer le log détaillé depuis l'initialisation STP ? Dans cette versions spéciale, j'ai mis un getFeatures, je veux voir quelles sont les valeurs, l'idée à terme ça serait, si possible, de faire un QA qui s'adapte aux capacités de l'aspirateur (serpillère, etc)

J'ai dû louper l'univers dans lequel Z-Wave est très bien implanté. Dans le miens, Z-Wave (comme Zigbee d'ailleurs) est une techno confidentielle pour geeks barbus, qui n'est vendu que dans les boutiques spécialisées. Si CHIP abouti, les fabricants n'auront aucun mal à l'intégrer dans leurs produits commercialisés dans tous les supermarchés, grandes surfaces de bricolages, et autres magasins divers et variés. Le marché sera inondé et Z-Wave comme Zigbee resteront des technos ultra confidentielles pour gens déjà équipés ou qui ont des besoins ultra spécifiques... et encore, si on de la change, car ça pourrait tout aussi bien disparaitre. Puce dédiée, logiciel, tout ça, on ne sais pas encore....ils parlent de base open-source, donc il faut espérer que ça ne soit pas verrouillé, et que n'importe quel fabricant qui ne fasse pas partie de l'alliance puisse utiliser ce protocole. De toute façon c'est à cette seule condition que CHIP a un avenir, sinon il restera cantonné à un univers de geeks comme les Z-Wave, Zigbee, EnOcean, etc actuels. On verra bien...

Nickel, merci J'étudierai ça... plus tard (dans quelques jours), j'espère que ça n'est pas trop urgent pour toi.

Il faudrait le formater pareil pour en être certain.... mais en tout cas je l'ai testé chez moi et ça fonctionne (sur HC3, ce qui confirme que la syntaxe est la même que pour HC2)

Welcome to the forum

Non parce que ça va remettre lastRefresh = 0 C'est bien loop() qu'il faut appeler dans l'exemple du dessus.

Merci... mais euh.... compliqué à reproduire là... trop de règle, et la lecture du log est d'autant plus ardue. Est-ce que tu pourrais isoler le bug avec 1 seule règle dans ta config, afin de m'aider à comprendre, et je tenterai de produire chez moi.

Ouais mais c'est compliqué parce que le développeur a fait n'importe quoi, s'il avait bien fait son boulot dès le 1er coup, ça fonctionnerait tout seul Ou alors vous n'avez qu'à acheter le même modèle que le miens @Dragoniacs Tu peux essayer de remplacer les 2 fichiers main et Xiaomi par les fichiers ci-joints STP ? ça ne sera surement pas 100% fonctionnel, mais ça devrait aller mieux...enfin j'espère ! Xiaomi Roborock Vacuum v2.01.lua Library - Xiaomi v1.01.lua

Ah mais clair, la vitesse c'est génial. Je suis retourné sur mon HC2 la semaine dernière pour préparer ma migration, identifier les devices, etc... punaise les boules ! C'est le cas de le dire

C'est vrai ça... bien vu @jjacques68 @henri-allauch Du coup je suppose que tu utilises setInterval(), à mon avis ce n'est pas la bonne méthode. Car si le http.request() met plus de temps à répondre que ton intervalle => tu as les événements en double Perso je fais un setTimeout() dans les callbacks de http.request() (success() et error()) qui se rappelle lui-même à chaque boucle (avec un délai de 100 ms paramétrable). Normalement impossible d'avoir des events en double avec cette technique, car on est certain à la prochaine exécution de http.request() qu'on a bien pris en compte la dernière valeur connue de states.last Remarque de fond : d'où l'intérêt quand on demande de l'aide sur le forum de donner un maximum d'information, à savoir tout le code qui entoure la fonction qui pose problème, car c'est souvent le contexte qui pose problème plus que la syntaxe en elle-même. EDIT : @henri tu as répondu entre temps et tu confirmes exactement ce que je dit

Autant de changement => perso je trouve ça très bien, même si j'aurais aimé encore plus de changements Sans pouvoir switcher facilement => ça oui, il faut tout refaire, aucune reprise possible des VD, scènes, scénarios....

C'est bizarre, on dirait qu'il y a des trames qui se mélangent. On va allonger un peu les délais... dans le fichier main, à la ligne 276, tu peux modifier comme suit : fibaro.setTimeout(10000, function() loop(self, refreshInterval) end) Ainsi le 1er refresh du statut se fera 10 secondes après la découverte de l'aspirateur (au lieu de seulement 1s)

Oui effectivement, j'ai raconté n'importe quoi hier, désolé.... je me suis un peu emmêlé les pinceaux. Une meilleure lecture du log et je comprend mieux. Voici ce que je te propose : En ligne ligne 528 tu vas remettre comme à l'origine : self:command("get_status", nil, function(result) return type(result[1]) == "table" end, type(callback) == "table" and { Et en ligne 805 tu vas modifier comme suit : params = params or {} Et relancer le test.

Normal, c'était même annoncé dans ses spécifications lors de sa sortie. En pratique ce n'est pas un souci, on ne fait pas passer de trafic réseau important par une box domotique. Et puis 100 Mbps en Ethernet, ça reste plus rapide que la majorité des débits atteints en pratique avec du Wi-Fi.

CHIP Connected Home over IP MATTER Je n'ai pas trouvé de topic unique sur le forum, l'information étant disséminée ça et là, alors ce nouveau topic sera la lieu unique de discussion autour de ce futur nouveau protocole CHIP (es espérons le dernier, l'ultime, le définitif... un protocole pour les gouverner tous) Article intéressant d'Hervé sur son blog Abavala : Projet CHIP: agenda, protocoles et… blockchain! On a enfin quelques informations concrètes à se mettre sous la dent.... jusqu'à présent je ne comprenais pas comment CHIP allait s'interfacer avec les protocoles domotiques existants, le monde IP, et une passerelle de haut niveau. En fait, CHIP est censé répondre à toutes ces problématiques : Intéressant de retrouver Thread, que j'ai cru mort et enterré à jamais... : Ah en voilà une info intéressante : Très bien aussi la sécurité : Donc là je vois venir ce que je pressens depuis que Fibaro a annoncé abandonner Zigbee pour attendre CHIP : ils ajouteront CHIP dans la box afin de faire passerelle avec les modules Z-Wave, car il ne faut pas rêver, les modules Z-Wave existants ne seront jamais Thread natif : Et là on comprend que Zigbee n'est pas plus à un protocole d'avenir que Z-Wave, ça me fait bien marrer quand je repense à quelques discussions ici ou là... : Bref, rendez-vous fin 2021 / début 2022 pour les tous premiers produits certifiés CHIP.... il faudra du temps avant que ça se démocratise, mais on voit enfin la lumière au bout du tunnel... allez, on y croit ! D'ici là, je pense qu'on aura de plus en plus d'informations techniques détaillées.

Sérieux ? Mince alors, je ne fais pas la mise à jour alors.... @BenjyNet au contraire, s'ils pérennisent une plateforme en la déclinant sur plusieurs modèles / marques commerciales, ça lui donne plus d'avenir qu'une seule box dans un coin ? Surtout que Fibaro est totalement inconnu en dehors des geeks, alors que NICE a déjà bonne réputation dans le grand public (face à Somfy); et surtout est déjà distribué largement. Pour moi ça sent très fort l'abandon plus ou moins rapide de la marque Fibaro.

OK merci, par contre je vois que tu as remplacé "get_status" par "miIO.info" dans la fonction Xiaomi:getStatus() d'après le log : [21.04.2021] [14:33:45] [DEBUG] [QA_ROBOROCK_195]: Xiaomi:command("miIO.info", nil, function(), table[2]) Dans cette même fonction, en ligne 528, je te propose de remplacer comme suit, c'est à dire ajouter un tableau vide {} à la place de nil, ce qui permettra d'envoyer params=[] dans la trame vers le robot (en parcourant les forums, j'ai l'impression que c'est ce qu'il faut) : self:command("miIO.info", {}, function(result) return type(result[1]) == "table" end, type(callback) == "table" and {

Certes, mais je n'ai pas trouvé comment mettre à jour le firmware de ce vieux modèles chinois sans la bricker, donc j'ai laissé tomber. Et puis la nouveauté technologique, c'est bien appréciable... et c'est geek aussi Le nombre de pixels, c'est qui voit. C'est comme sur un appareil photo, à taille de capteur identique, plus il y a de pixels, plus la qualité d'image se dégrade (moins de photons sur chaque photosite composant le capteur, donc image plus bruitée la nuit). Et ça prend plus de ressource CPU pour l'analyse d'image, et plus de place sur le disque. Et plus de bande passante réseau, ce qui n'est pas un souci en Ethernet, mais devient un souci dès lors qu'on consulte le flux à distance depuis son mobile. Perso je suis resté fidèle à 4 Megapixels, c'est un bon compromis dans l'immédiat. D'ailleurs c'est la seule, mes autres caméras (les Darkfighter) sont en 2K (1920*1080) et c'est largement suffisant car elles ne filment pas de loin. Pour le varifocale... finalement j'ai appris à m'en passer, même si c'était bien pratique (mais pas simple à régler) J'ai déjà bien calculé l'angle, je suis arrivé à une lentille de 4mm, qui cadre un peu plus large que ce dont j'ai besoin. J'ai légèrement orienté l'angle afin de limiter la vue du voisin/de la rue. Mais sinon, ce n'est pas interdit d'avoir un coin de l'image qui donne sur un lieu public ou privé, il faut dans ce cas le masquer (zone à configurer dans la caméra ou dans le logiciel d'enregistrement)

Je ne maitrise pas du tout le RestartTask, j'ai bien 1 ou 2 règles qui en utilise sur mon GEA v6 existant sur HC2, mais on m'avait donné la syntaxe sur le forum, que j'ai appliqué sans trop chercher à creuser le sujet. Si tu pense qu'il s'agit manifestement d'un bug de GEA v7 sur HC3, tu peux aller poster sur le topic dédié, en donnant les logs détaillés après avoir préalablement activé debug=true et lldebug=true