Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 989
  • Inscription

  • Dernière visite

  • Jours gagnés

    1 280

Tout ce qui a été posté par Lazer

  1. Oui pour modifier le champ enabled, que ça soit par le GUI ou par l'API, dans les 2 cas ça fait la même requête PUT, qui redémarre obligatoirement le QuickApp. Donc passage obligé par la fonction onInit() Mais ce que je voulais dire, c'est que le QA sera toujours actif, donc il recevra les sollicitations de l'utilisateur, les appels de fonctions, etc. Donc si on veut faire les choses proprement, il faudrait tester son état enabled au début de chaque fonction. Un peu lourd... Oubli de la part de Fibaro, ou simple héritage de ce champ depuis les modules Z-Wave ? Je ne sais pas, mais en tout cas je suis content qu'on aie accès à cette valeur, ça permet de simplement bloquer l'exécution d'un QA.... Je me souviens sur HC2 d'avoir dû vider des main loop de leur contenu, ou d'avoir mis un fibaro:abort() en première ligne, et d'avoir oublié de l'enlever par la suite... "Mais pourquoi ce c.. de VD ne fonctionne plus ???"
  2. C'est exactement pour cela que j'en ai parlé, je me doutais que ça allait faire réagir les développeurs Et effectivement, c'est à nous de coder la logique de désactivation. L'équivalent de getSelfID() est tout simplement self.id (accessible uniquement depuis une fonction de QuickApp, puisqu'on utilise self), ou bien de façon plus générale plugin.mainDeviceId qui est accessible de n'importe où dans le code LUA du QA) fibaro.getValue(347, "enabled")) ne te retourne rien car enabled n'est pas une propriété du device (= elle ne fait pas partie de la sous-table properties dans son JSON) Perso j'utilise ce genre code, vers le début de la fonction QuickApp:onInit() : -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then self:updateProperty("log", "Disabled") for _, child in pairs(self.childDevices) do child:updateProperty("log", "Disabled") end self:updateView("LabelDebug", "text", "❌ " .. (self.trad.quickapp_disabled or "QuickApp disabled") .. " ❌") self:warning("Device", self.name, "is disabled => QuickApp stopped") return end C'est le return à la fin du bloc de test qui stoppe l'exécution du QuickApp (en réalité ça ne le stoppe pas, ça empêche juste l'exécution de la suite du code de onInit(), et notamment le setTimeout() un peu plus loi qui est censé lancer la boucle infinie)
  3. A ce sujet, dans tous mes QuickApps, j'ajoute maintenant la possibilité de désactiver facilement chaque QA, simplement en cochant la case qui va bien dans l'onglet de ses propriétés avancées :
  4. étrange ça, pourquoi il n'y a pas 2 robots qui se comportent de la même façon ? C'est pénible... Il faudra que je prenne le temps d'étudier les logs plus en détail....
  5. Oui voilà !
  6. Euh, tu es certain d'avoir fait la mise à jour des fichiers LUA ?
  7. Lazer

    Joyeux anniversaire @Domodial

    Distanciation sociale, le forum est COVID Compliant
  8. tient c'est marrant, ce message apparait de temps en temps aussi sur le miens, mais très rarement, environ 1 ou 2 fois par semaine. Dans tous les cas, si tu veux avancer, il faudra me partager les logs complets avec debug = true
  9. @Sakkhho je ne suis pas certain, mais regarde aussi si tu trouves le S5 Max à bon prix, je crois qu'il dispose aussi des fonctions de cartographie/navigation avancée. Ils sortent tellement vite des nouvelles gammes, chaque année, qu'on se demande parfois quelle est la différence entre 2 générations.
  10. Lazer

    Joyeux anniversaire @Domodial

    Bon anniv @Domodial
  11. Oui m'enfin tu sais comment c'est dans l'industrie, le dernier modèle sorti n'est pas forcément mieux. D'ailleurs ça permet souvent aux plus malins de faire de bonnes affaires, chopper le haut de gamme des générations précédentes moins cher, et qui reste dans les tous les cas supérieur au dernier modèle "entrée de gamme". C'est pareil pour les téléphones, et absolument tous les produits manufacturés. Surtout les voitures d'ailleurs, tellement le cout est élevé. Le S6 MaxV est supérieur au S7, c'est clair et net. Le seul avantage du S7 (outre sa nouvelle numérotation lol) c'est comme dit, la serpillère vibrante. Et comme ils n'ont pas sorti le S7 Max, .... le S6 MaxV reste leur haut de gamme (et plus ou moins au même prix que le S7 en plus, donc chacun fait ce qu'il veut, mais le meilleur choix reste le S6 MaxV) D'ailleurs, je me demande si cette serpillère vibrante est réellement mieux. Je veux dire, la fonction serpillère actuelle est un gadget à la limite de l'inutile, donc est-ce que la serpillère vibrante la rend réellement utile ? Ou est-ce qu'il faudra attendre le S12 avec le balai-brosse ?
  12. Hum, je viens de comprendre, tu as la version du tuto, qui n'est pas compatible avec les vieux aspirateurs. En attendant que je fasse la mise à jour, tu peux chercher dans le topic, j'ai partagé une version corrigée.
  13. Ah bah voilà Pour cette erreur, c'est plus gênant... tu es certain de ton token ?
  14. OK... étrange.... mais tu as quand même un problème de communication entre la HC3 et le Xiaomi, le message "Operation canceled" est très clair (enfin dans le langage Fibaro.... faut être amateur !). EDIT : si l'IP est correcte, peut être que le port ne l'est pas.
  15. Problème réseau, ton aspirateur semble déconnecté. Peut-être qu'il est hors de la couverture Wi-Fi ?
  16. Dommage, je suppose qu'il ne baissera guère tant qu'il ne sera pas remplacé. Et vu que c'est toujours largement moins cher que le Roomba i9 chez le grand concurrent d'en face, il n'y a surement pas urgence à faire baisser les tarifs. Peut être aussi que la pénurie de composants électroniques est à prendre en compte.
  17. Bienvenue sur le forum
  18. Version : 1.0 Type Z-Wave : 3 Version Z-Wave : 7.12 Du coté de la HC3, tous mes autres modules ont une mesure de batterie cohérente, ça ne fait cela que pour ce module. Du coup j'ai acheté une pile neuve d'avance, pour être prêt, vu que ça sera imprévisible pour ce module.
  19. Super
  20. J'ai ce module a l'extérieur (sous abri non exposé au soleil) depuis quelques temps. Une fois correctement paramétré, il est bien précis et remonte la température au changement de 0.1°C près. Ci-dessous comparatif avec le module Netatmo (en cyan) et YR Weather (orange). Le Aeotec est en noir : La météo YR Weather est complètement à l'ouest, mais c'est normal, c'est un service cloud, qui va chercher la météo à la station la plus proche, celle de Paris Montsouris, donc en pleine ville. On note quelques petits différences légères avec la station Netatmo.... on mettra cette différence sur le compte de la précision approximative de ces capteurs grands publics. Je note un delta exceptionnel jusqu'à 1.1°C, même si c'est généralement inférieur à 0.5 °C. Cela dit de si petites différences n'ont aucun impact sur nos scénarios domotiques (gestion du chauffage en fonction de la température extérieure). L'énorme avantage de ce module, c'est bien évidemment d'être Z-Wave natif, donc totalement indépendant du Cloud et de la connexion Internet. En revanche, la gestion de la batterie, c'est complètement folklorique, je n'ai jamais vu un délire pareil sur tous mes autres modules, ça fait le yoyo depuis 1 mois :
  21. Hum oui tu as raison, le type rainSensor n'est pas disponible dans l'interface Web lors de la création d'un nouveau QA Comme je t'ai dit dans mon message précédent, tu ne peux pas modifier le type d'un QA existant (ou plutôt je n'ai pas trouvé, c'est peut être possible via un hack spécial) Je vois 2 solutions : - méthode officielle : un QA parent qui crée ses enfants (child device), il n'y a pas de restriction, on peut utiliser n'importe quel type lors de la création d'un enfant) => C'est ce que fait le QA Netatmo par exemple. - méthode bidouille : une méthode un peu moins standard : créer un QA d'un type quelconque (multilevelSensor), l'exporter, modifier son type dans le JSON dans un éditeur de texte, puis le réimporter comme un nouveau QA, qui aura d'office le bon type. Je ne l'ai pas testé mais en théorie ça devrait fonctionner. D'ailleurs c'est intéressant, car en vérifiant la liste officielle des types supportés pour les QA : /api/quickApp/availableTypes Je me rend compte que le type rainSensor n'apparait pas. Pourtant, ça fonctionne très bien, puisque c'est utilisé par le QA Netatmo. Du coup je te propose cette autre URL, qui est plus complète car elle est censé lister TOUS les types de modules supportés par la HC3, et leur hiérarchie : /api/devices/hierarchy On peut sans problème créer des QuickApps avec l'un de ces types, on y retrouve bien le rainSensor (qui est un enfant de multilevelSensor, au même titre que temperatureSensor et tous les autres)
  22. Ah oui pour les chambres d'enfants, clairement le S6 MaxV s'en sortira largement mieux. Attention quand même, le miens avale les tous petits objets, genre pièces de Lego, chaussure de Barbie, etc... je les retrouve dans le bac au moment de le vider. C'est clairement annoncé par le fabricant, donc pas vraiment de surprise (je suppose que ça sera une amélioration du futur hypothétique S7 max) Par contre pour les chaussettes etc, là c'est royal, il contourne. Fini le robot bloqué par la chaussette enroulée dans la brosse ! 489€ chez Rueducommerce (donc avec vraie garantie), c'est assez cher, mais c'était le moins cher à ce moment là depuis son début de commercialisation. Donc un vrai bon plan... Je n'ai pas suivi depuis, si le prix a baissé ou non.
  23. Lazer

    QA Multilevel sensor

    C'est un compliment pour Fibaro de dire que le doc est succincte. Car ça veut dire qu'elle existe ! Je me souviens d'une certaines HC2 qui n'avait pas de doc.... Je ne suis pas certain de comprendre ta question. Les QuickApps, on en parle en long en large et en travers sur ce forum. Cela permet aux utilisateurs de créer n'importe quel module qui s'intègrera parfaitement dans la box, exactement comme un vrai module Z-Wave natif. Chaque module (qu'il soit physique ou virtuel) a un type, genre capteur d'ouverture, mouvement, température, humidité, etc Le multilevel c'est juste le fourre tout, pour les modules qui n'ont pas de type prédéfini (température, humidité, luminosité, etc... ) A ce sujet, la liste des types est disponible via l'API : /api/quickApp/availableTypes
  24. Pour moi le S7 c'est le même que le S6, mais avec la serpillère vibrante en plus. Donc ça reste le modèle d'entrée de gamme. Le S6 maxV a tout mieux que le S6, c'est leur haut de gamme : la caméra (qui permet la reconnaissance donc l'évitement des objets), meilleure cartographie, batterie plus importante, plus grand réservoir d'eau, gestion électronique de la quantité d'eau, etc. Le site officiel est très pauvre et contient trop peu de détails je trouve, j'étais tombé sur des comparatifs plus complets sur Internet (PS : surtout pas Youtube pour ce genre de produit, 100% des tests sont sponsorisés par la marque) Le modèle qui mettra tout le monde d'accord, ça sera le S7 Max (ou quelque soit son nom), mais il n'a même pas été annoncé... En tout cas, j'étais bien content quand ils ont annoncé le S7 plusieurs mois avant sa sortie officielle, car le peu de nouveauté (la serpillère vibrante) et l'absence du modèle HDG m'ont fait préférer le S6 maxV. Surtout que c'était juste avant le Black Friday. Pour @Sakkhho qui parle d'étage, finalement le choix sera facile à faire, s'il souhaite utiliser la serpillère, ou bénéficier de la cartographie avancée. Ou aucun des 2, le S6 de base étant encore trouvable en stock je pense.
  25. Les UV, ce n'est pas géré par DomoCharts. Pour ton capteur de pluie, il faut qu'il soit de type "com.fibaro.rainSensor" et il sera pris en compte. PS : tu ne peux pas changer le type d'un module existant, il faut le supprimer et le recréer avec le bon type.
×
×
  • Créer...