Lazer

Dans tes 2 exemples de règles, c'est strictement identique. Il y a quelques cas où l'ordre des conditions importes, c'est quand on utilise les attributs #value# #name# #room# etc, car par défaut il prendra la 1ère condition. Et sur la HC3 tu peux renommer les profils de base s'ils ne te plaisent pas, et en créer d'autres.

Je n'ai pas ce souci Tu as bien sélectionné "Obtenir l'heure du serveur NTP" ? Pour l'adresse, j'ai toujours utilisé directement pool.ntp.org, je pense qu'il y a plus de serveurs derrières et moins de chance de panne que d'utiliser fr.pool.ntp.org, forcément plus limité.

Tous les animaux. Chats, chiens, renards, oiseaux, pour l'instant je n'ai pas eu de souci chez moi. Je n'ai pas de cerf, mais vu que c'est aussi haut qu'un homme, ça pourrait poser problème.... J'ai expliqué le fonctionnement sur le topic Diagral, il doit même trainer un schéma des rayons IR, ça permet de bien se figurer le fonctionnement.

Exact c'est vrai, je l'utilise aussi pour surveiller ma fille quand elle joue seule dehors Les détecteurs d'alarme extérieurs sont prévus pour fonctionner avec les animaux, double faisceau IR, donc c'est pas trop un souci en pratique, ça marche vraiment bien. C'est en intérieur que c'est infernal, il y a 1 seul rayon IR, du coup n'importe quel animal les déclenche, le pire ce sont les chats qui montent partout. Je n'ai jamais essayé les bi-technos, je ne sais pas si ça se comporte mieux.

Voilà, tu devrais avoir un tableau vide dans la (ou les) répétitions suivantes.

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.