Lazer

Dis donc tu es certain du calcul du CPU ? Car ça me parait super élevé tes valeurs, parce que si ton CPU est chargé à 20% pendant 1 minutes sur une box neuve qui ne fait rien, il y a un gros problème. Je suis à moins de 5% chez moi (sans utiliser ton QA, c'est ma version de DomoCharts en cours de développement qui m'indique ça)

Intercom Fibaro en reconditionné à 508 € chez Domadoo : https://www.domadoo.fr/fr/reconditionne/4466-reconditionne-fibaro-portier-video-connecte-fibaro-intercom-5902701701109.html Avec la promo supplémentaire de 20% valable ces jours-ci, ça devrait amener le prix à 406 €, plutôt un bon prix je pense pour qui veut se lancer.

eBay ou le Bon Coin, faut surveiller les annonces, et en chopper une soit d'occasion, soit neuve sortie d'un stock (beaucoup d'admins systèmes en entreprise ne s'en servent pas et les revendent pour arrondir leurs fins de mois)

Oui en effet

La box de Krikroff est bien arrivée chez TonyC qui a tenté de l'inclure en esclave sur son installation, mais ça ne fonctionne pas. Du coup tu la retrouveras demain matin sur le petit coin....

Mais au final pourquoi tu n'as pas mis ces boutons dans le QA Diagnostique ? L'idée de base, c'était que si on voit que la RAM est saturée, alors on reboote. PS : version 57 bien joué

Ah oui OK, c'est ce qu'on disait plus haut. Patience, donc, ça va venir.

Bienvenue sur le forum

Comment ça "définitivement pas supporté" ? Tu parles de quoi là ???

Je n'ai pas étudié en détail, mais ça me parait pas mal comme code Bravo et merci du partage

Ok merci Non clairement ça a été prévu, ça marchera, faut leur laisser le temps de debugger... Une fois de plus. C'est une fonction indispensable sur les grosses installations. C'est le support des HC2 qui doit arriver plus tard... Et ça va leur faire perdre du temps aussi, mais bon faut bien penser à ceux qui veulent migrer en douceur. Où juste réutiliser une vieille box déjà amortie en passerelle sans intelligence. Ça fait jamais qu'un (gros) bug de plus sur cette HC3, qui est encore trop jeune.

Quand tu crées ton application sur https://dev.netatmo.com/apps/ Il faut bien remplir tous les champs entourés en rouge, puis cliquer sur le bouton Save. Puis il te donne un ID et un Secret entourés en bleu : Ensuite tu donnes les infos dans les variables du Quick App : @ tous je suis en train de préparer une nouvelle version de ce Quick App, avec toutes les mesures de pluie et de vent, ainsi que la remonté de l'état de batterie des modules, la surveillance de la connectivité, et 2/3 bricoles.

Non on ne le savais pas, relis bien ce que TonyC a écris... il parle bien d'intégrer une HC3 en passerelle, pas une HC2 Et puis c'est la première fois que quelqu'un a 2 HC3 chez lui ! @TonyC Je pense que tu pourrais mettre un screenshot de ta tentative d'intégration pour qu'on voit à quoi ça ressemble. Parce que moi quand je vais dans le panneau adéquat, il ne me liste rien du tout (il liste pas les HC2, logique puisque là on sait bien que ce n'est pas supporté)

Attention à ne pas confondre les variables globales au sens de la HC2 et de la HC3. Et les variables globales au sein d'un script/programme (donc une scène, un VD, un QA) La confusion est facile. Mais ma remarque reste valable dans tous les cas : Un programmeur doit normalement restreindre le plus possible la portée de ses variables, à son strict nécessaire : bloc, fonction, classe.

L'API Unifi remonte le timestamp de la dernière fois qu'il a vu l'appareil sur le réseau. Donc c'est à toi de déterminer la période à partir de laquelle tu décides qu'il est absent. Ce n'est pas le contrôleur Unifi qui le décide. C'est toi. Enfin le programmeur. Moi j'avais justement mis un intervalle hyper long de 10 heures de mémoire, car je ne voulais pas avoir de fausse détection chaque nuit quand je met mon téléphone ne mode avion (bon je ne dors jamais 10h, mais j'ai prévu large). Mais aussi les cas où le téléphone n'a plus de batterie, ou que je désactive volontairement le Wi-Fi pour passer en 4G (ce qui arrivait très souvent quand je n'avais que l'ADSL... beaucoup moins voire jamais depuis que j'ai la fibre) Le problème ce n'est pas Unifi, ni même le script LUA, c'est la façon dont on utilise notre téléphone.

Bienvenue sur le forum

Les variables globales, c'est le mal, il n'y a quasiment jamais besoin de les utiliser. Un programmeur doit normalement restreindre le plus possible la portée de ses variables, à son strict nécessaire : bloc, fonction, classe. @mprinfo désolé pas le courage de relire ton code maintenant.... et ni même demain car je n'ai jamais su lire de code sans couleur, tu pourrais au moins mettre le champ LUA quand tu codes le code sur le forum, ça aide

oui tout à fait. Enfin pas avec "self" parce que c'est ce que j'ai fait au début comme un c.. et ça a immédiatement ajouté une batterie sur le module parent ! Pas bon (puisqu'il est alimenté sur secteur USB) Donc il faut le faire sur child: juste après sa création. En même temps qu'on lui ajoute des setVariable, qu'on lui définie son unité, etc etc. Bon bah voilà, les noeud morts ça fonctionne, c'est juste génial Simulation de panne de l'anémomètre : Et vue sur la page principale : PS : les 0.1mm de pluie c'est quand je suis allé bouger le pluviomètre pour faire remonter au moins une valeur, car sinon c'est un peu la sècheresse en ce moment. Et le vent n'est produit que par ma bouche sur l'anémomètre, car il est sur mon bureau. On fait ce qu'on peut pour tester.... Évidemment le retour à la vie du module est tout aussi instantané avec l'opération inverse : child:updateProperty("dead", false) J'arrête là pour ce soir

60 secondes dans le screenshot de mprinfo, puisque c'est la variable "frequency" réglable par l'utilisateur.

Non je ne suis pas d'accord Si tu joues avec les Child Devices (ce que je n'arrête pas de faire avec IPX800 et Netatmo) tu verras que c'est totalement faux et peu induire en erreur. En parlant de Netatmo, ma version modifiée avec plus de valeurs météos remontées depuis l'API officielle, et surtout le statut des batteries des modules. Ce qui m'a permis de jouer avec l'injection d'interfaces dans les devices, merci @tinman sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/?do=findComment&comment=202936 Regardez les petites icônes de jauge de batterie : Donc c'est intégré proprement, nativement dans l'interface, avec les notifications par email et remonté dans DomoCharts, comme si c'était un module Z-Wave natif : Fantastique les QuickApps, j'adore Vite vite vite la suite Je vais tenter de mettre les modules en "dead" (nœud mort) quand ils sont injoignables par la station ou en batterie HS

non plutôt comme une variable globale. Enfin pas tout à fait, pour être précis la portée est celle de tout l'objet instancié. Donc accessible depuis n'importe quelle fonction de ta classe QuickApp dans ton cas.

Ah ben j'avais pas suivi les mises à jour.... " Liquidation judiciaire le 24-04-2020 " Cette-fois ci c'est bel et bien terminé Quel dommage....

Mouais, désolé mais je suis pas fan... ce n'est pas comme ça que j'aurais fait. Pourquoi utiliser setvariable() ? C'est moche, ça fait des écritures inutiles dans la DB, l'utilisateur va le voir en regardant les propriétés du QA, etc... Y'a tellement plus simple et plus rapide, il suffit d'utiliser une variable interne, self.doubleClic = os.time() et c'est réglé. Tu t'es compliqué la vie.

Nous sommes d'accord Allez, on y crois...

Je ne pense pas non plus, ils ont juste oublié d'ajouter le bouton dans l'interface Web pour ajouter une icone. Tout est comme ça dans la HC3, l'interface n'est pas du tout finie, mais quand tu vois la liste de choses faisables via l'API, c'est juste hallucinant, on peut faire exactement ce qu'on veut de cette HC3, moi je m'éclate en programmation. Ça change de la HC2 toute limitée Je le disais déjà avant de l'acheter, mais j'en suis en plus en plus persuadé, le potentiel de la HC3 est énorme.