Lazer

Bienvenue sur le forum

Justement non en fait. Un pro a besoin de vendre un truc qui marche, qui soit stable, et fiable dans le temps. Un truc qui ne lui plombe pas sa rentabilité en faisant du SAV à outrance chez les clients mécontents. Donc les trucs avancés, les moutons à 5 pâtes qui font papa maman, c'est bien pour les geeks qui ne comptent pas leurs heures, mais pas pour les pros. La HC3 (ou même la HC2) en fait déjà trop pour les besoins d'un pro, très clairement avec nos nombreux Modules Virtuels / Quick Apps, Scènes alambiquées, règles GEA, etc... on en fait déjà largement plus que ce que n'importe quel intégrateur va mettre en place chez un client. Et j'aimerais pas être à la place du pro qui tombe chez le client "à moitié geek", celui qui a vu qu'on pouvait connecter un module Zigbee Xiaomi ou un relai Wi-Fi Sonoff, et va demander à son intégrateur de lui fournir une solution interopérable avec tout. L'enfer du pro, se retrouver à déployer une solution qu'il ne maitrise pas, et qui va lui revenir à coup sûr dans la tronche quand le client qui a bidouillé va venir se plaindre que plus rien ne fonctionne. Mon métier c'est de l'informatique, et c'est vraiment pareil. Je déploie une solution fermée à base d'UNIX propriétaire, je sais que ça va fonctionner, le résultat est prévisible et parfaitement documenté par l'éditeur, jamais aucune surprise (sauf bug/plantage/panne, ça peut toujours arriver) Je vais déployer un Linux, c'est juste l'enfer tant les possibilités sont infinies, t'es incapable de prédire le temps que tu vas y passer, il n'y a pas 2 configurations identiques. (bon celui qui n'a jamais fait d'UNIX ne peut pas comprendre cela dit...)

Ah mais je ne dis pas le contraire, ça évolue plus vite sur les solutions open-source Je réagissais juste à ta phrase "repartir dans la même logique d'utilisateur bêta testeur pendant de longues années, avec un produit qui marchotte de version en version, avant d'avoir un truc de stable" parce que tu auras exactement la même chose sur les solutions open-source, et même, je pense à la lecture des forums, en pire : Non parce que sérieusement, en dehors des blogueurs qui font la promo de telle ou telle solution, quand tu vas fouiner sur le forums, tu te rends vite compte que l'herbe n'est pas plus verte ailleurs du point de vue de la stabilité, du support. J'ai même vu des gens en revenir pour dire que c'est plus stable chez Fibaro. Comme quoi... Après, ces solutions open-source, si tu es geek, que tu as une infra virtualisée, la possibilité de snapshoter pour revenir en arrière, là y'a moyen de s'éclater. Si tu veux piloter whatmille objets connectés aussi, tant les plugins sont nombreux. Si tu es développeur et que tu sais écrire tes propres plugins, il n'y a plus aucune limite. Bref, faut poser le pour et le contre, perso je reste chez Fibaro parce que ça marche bien (mon HC2 va fêter ses 7 ans le mois prochain), c'est bien plus stable que la lecture des forums ne le laisse croire (normal on entend toujours les râleurs, moi compris), et je maitrise la solution (la HC3 est différente en apparence, mais on retrouve beaucoup de concepts identiques). Et j'en ai rien à faire de piloter des objets connectés chinois à pas cher buggués de partout (coucou Xiaomi, Sonoff, ...). La relative "non-ouverture" de la HC3 ne me dérange pas, j'y trouve largement mon compte (elle permet déjà tellement plus que la HC2) Je suis d'accord avec tes remarques concernant Fibaro..... cependant leur stratégie est très claire, surtout depuis le rachat par NICE : offre orientée vers les pros (comprendre : les intégrateurs). Le grand public, l'utilisateur final, ils s'en moquent. De toute façon, même à l'époque de la HC2, ils n'ont jamais écouté les retours utilisateurs. On peut s'estimer heureux d'avoir la possibilité d'acheter la box en direct. En tout cas, ils ne cherchent absolument pas à concurrencer les solutions "open-sources qui savent tout faire", cela ne cible pas du tout la même population. Leur concurrent, c'est Somfy, qui pour rappel est le distributeur n°1, et de très loin, en box domotique. Sauf que quand tu compares la HC3 et une box Somfy, il y a un monde entre les deux. Il y a donc un potentiel énorme, reste à Nice d'arriver à promouvoir leur offre (au travers des intégrateurs justement... la domotique rentre en force chez les gens par l’automatisation du portail et des volets)

Oui je sais, c'est ce qui m'arrive avec l'IPX800 et l'EcoDevice RT2 Mais bon, ce n'était pas trop le sujet de ce topic à la base Autre chose quand même, je ne sais pas si tu as remarqué, les labels ne sont pas persistants. Leur valeur est perdue après le redémarrage du QuickApp (donc de la box), ce n'est vraiment pas le lieu pour y stocker une valeur, mais juste pour afficher une information pour l'utilisateur. D'ailleurs dans l'API, Fibaro a bien séparé les properties (valeur par défaut du label qui est repositionnée à chaque redémarrage) et les View (valeur courante du label).

Ose, tu nous raconteras

Ta première phrase, tu peux l'application à Jeedom, Domoticz, Home Assistant, ça sera exactement pareil. La seule différence c'est que c'est gratuit (enfin, faut quand même payer une machine pour l'héberger) Si tu veux un système stable, qui ne soit pas en développement, tu peux prendre une Somfy Box par exemple, tu pourras faire.... rien... avec. Sinon pour la logique du raisonnement de mutualisation des fonctions, je suis d'accord

OK je vois... mais je trouve surprenante ton utilisation des childs Toutes ces infos, elles devraient être dans des child "monofonction", et pas des labels. Avec le bon type, genre fibaro.multilevelsensor, etc... et la bonne unité Comme ça, c'est exploitable directement dans des scénarios (avec GEA, ou autre peu importe). Chaque child = une mesure de capteur. Et ça remonterait aussi dans Domocharts (dans la nouvelle version, j'ai supprimé les labels et les variables globales, car toutes les valeurs sont censées être dans des child, autant utiliser la HC3 comme... une HC3... et pas une HC2)

Je ne comprends pas bien.... car il n'y a rien à afficher sur un child, on ne peut pas personnaliser son affichage (boutons, labels, sliders)

C'est beau, mais..... si tu comptes passer sur HC3 : oublie les scènes qui ne sont clairement pas mises en avant : 1 seule instance maximum je n'ai pas trouvé comment passer des arguments toujours pas possible de récupérer le retour, sauf à utiliser la méthode bien lourde des variables globales les QuickApps c'est l'avenir justement, on peut maintenant définir des fichiers au sein de chaque QuickApp, super pratique pour décomposer son compte et utiliser des librairies de fonctions

Oui je suis d'accord, et je ne dis pas le contraire sur l'attention qu'il faut porter à cette instabilité. A ce sujet, je conseille de commencer par isoler le Quickapp ou la Scène qui est responsable de ce changement de comportement. Et si ça se trouve, cette recherche aboutira à désactiver tous les Quickapps/scènes pour se rendre compte que l'instabilité ne vient pas de là.... on ne sera pas plus avancé, mais on aura éliminé une piste. Quand au sleep, je ne suis pas si extrémiste, il est encore supporté, mais il faut l'utiliser avec parcimonie Pour l'instant je trouve cette HC3 très stable, pour mon usage (qui encore une fois comporte très peu de modules Z-Wave, juste pour tester, mais par contre j'ai beaucoup de QuickApps actifs) Ces discussions me rappellent celles qu'on a eu au sujet de la HC2, en v4, une fois que Fibaro avait corrigé tous les bugs de jeunesse, certains utilisateurs se plaignaient encore de plantage, et en arrivait à supprimer totalement les Main Loops de leurs modules virtuels. C'était bien selon moi un mauvais codage LUA des dites Main Loops. Dans un autre registre, dans mes codes j'ai toujours limité les écritures dans la DB (tant pour les performances, que pour l'usure de la mémoire flash). Que ce soit une variable globale, un label, etc.... je vérifie l'ancienne valeur, avant de potentiellement modifier la nouvelle valeur. Cela évite de réécrire inutilement une valeur identique. A l'époque de la HC2, à un moment donné j'avais même soupçonné que trop d'écriture simultanées dans la DB pouvaient occasionner des plantages par effet de bords de plusieurs écritures qui se télescopent (au passage en v4, Fibaro avait introduit un process au niveau de Linux par lequel étaient censées passer toutes les écritures) De même, il ne faut jamais supposer qu'une fonction va renvoyer une donnée attendue, il faut toujours la tester avant de l'exploiter dans la suite du code (tester son type, et sa valeur....) Ce sont quelques pistes, certes lourdes à mettre en place dans l’écriture de nos codes, mais qui les rendent plus robustes, et évitent bien des plantages.

Mouais... j'aurais pensé que via api.post(), donc en localhost sur 11111, ça serait passé sans auth, mais je constate une fois de plus que Fibaro modifie les API sans prévenir....

Thank you, this is exactly what I was looking for I cas see this command actually stops the code, but it doesn't restart the Quickapp, despite what its name would suggests. EDIT : Sorry, it's OK, the QuickApp actually restarts

Oui pareil pour le shutdown chez moi, je pense qu'il faut l'oublier et utiliser le suspend à la place, même si je n'ai pas trop compris la différence... Mais du coup tu utilises bien un header Authorization, c'est justement ce que je veux éviter, c'est juste aberrant quand le code tourne déjà sur la box elle-même....

Bravo Il doit également y avoir un paramètre pour lui demander de générer la page avec le thème sombre, faut que je cherche ça....

@TonyC bah justement, sur mon HC3 la première règle de GEA me signale par notification Push un redémarrage du Quickapp... et la 2nde me signale un redémarrage des services... et ce n'est justement pas le cas depuis que j'ai fait cette mise à jour Donc je ne rencontre pas ce souci, alors que vous êtes au moins deux. Donc il y a bien un souci sur vos 2 box. On a le même firmware, la différence, ce sont nos codes LUA. Et aussi les modules Z-Wave, dès fois que le problème vienne du moteur Z-Wave. Mais comme @Krikroff (qui a migré tous ses modules) n'a pas non plus de souci et que je lui fait confiance pour la qualité de ses codes LUA, je me dis que c'est vraiment là qu'il faut chercher. Dans le doute, faut désactiver les QuickApps et Scènes une par une jusqu'à identifier le fautif.... c'est fastidieux je sais. Pour en revenir aux sleep(), j'en utilise quelques-uns, mais dans des circonstances bien précises. Par exemple dans le déroulement d'un code séquentiel, je fais une action, et j'ai besoin d'attendre 1 seconde, puis de continuer. Là je le fais avec un sleep() Cela ne pose à priori pas de problème. A l'inverse, s'il s'agit d'une boucle infinie qui doit répéter une action à intervalle régulier (ou irrégulier d'ailleurs), là c'est bien le settimeout() qu'il faut utiliser.

Savez vous s'il est possible d'interrompre brutalement le déroulement du code LUA d'un QuickApp ? Sur HC2 on avait la commande fibaro:abort() qui faisait cela, je me demande s'il existe l'équivalent sur HC3 ? J'ai bien comme idée de provoquer un crash du QuickApp en appelant une fonction non définie, mais ce n'est pas vraiment propre... Note : l'utilisation de l'instruction return n'est pas adaptée à mon cas de figure car il y a plein de fonctions imbriquées les unes dans les autres

Le downgrade n'est pas une solution, ça me rappelle l'expérience de @jjacques68 qui s'en rendu compte après coup que c'était bien ses codes LUA qui faisaient crasher la box. Disons qu'un code LUA mal foutu peut donner l'impression qu'il fonctionne, mais il donnera un résultat différent au prochain firmware (modification du comportement des API, du watchdog intégré, etc)... et amènera à un plantage Un ou 2 sleep ne sont pas forcément un problème s'ils sont de très courte durée (quelques millisecondes, quelques secondes, mais pas plus) et qu'ils ont lieu occasionnellement. Cependant une boucle infinie basée sur des sleep, c'est le crash assuré. Le sleep() ne rend pas la main au système, donc il paralyse le fonctionnement du QuickApp ou de la scène.... pendant ce temps là, aucun autre événement ne peux se déclencher (typiquement l'appui sur un bouton, etc) Et c'est vicieux, car ça ne se verra ni sur le consommation de RAM, ni sur celle de CPU. Il faut utiliser des settimeout() Par contre il faut revoir tout son code, car c'est la logique asynchrone... pas évident de s'y faire au début.

fibaro.homeCenter.systemService.* c'est uniquement pour les scènes Ce qui m'intéresse ce sont les QuickApps, dans lesquels ces méthodes n'ont jamais été disponibles. C'est pour cela que je passe par l'API, comme expliqué par @Krikroff en page précédente

Le reboot automatique n'est pas nouveau, c'était déjà le cas dans les firmwares précédents, comme je l'avais déjà relaté sur le forum. Suite à un mauvais développement de ma part (une tentative de planter un QuickApp), ça avait magistralement abouti, donnant lieu à plusieurs reboots de suite et le déclenchement automatique d'un recovery avec restauration automatique de ma dernière sauvegarde. Donc si vous avez des reboots automatique, je pense que vous savez où chercher : un de vos QuickApps (ou scènes) qui fait n'importe quoi.... typiquement une boucle infinie qui ne rend jamais la main au système, et consomme tout le CPU ou la RAM. Pour rappel, il ne faut plus utiliser de sleep(), mais settimeout() à la place. Je commence à avoir pas mal de QuickApps qui tournent sur ma box, et aucun ne provoque les phénomènes que vous rencontrez (reboot automatique, brusque variation de la RAM, etc)

Dites donc, ça fonctionne encore chez vous les shutdown reboot et suspend ? Là je suis en version 5.050.13 et aucune ne fonctionne, même en faisant la requête http sur localhost, ou en passant par api.post() En passant par api.post() j'obtiens le code 501 qui équivant à "Not implemented". En passant par http:request() j'obtiens le message d'erreur "End of file" Il faut impérativement ajouter l'authentification de type Basic dans les Headers pour que ça fonctionne, ce qui est bien pénible, car je n'ai pas du tout envie de stocker mes identifiants en clair dans mes scripts LUA.

Tu as vérifié le panneau de diagnostiques, au cas où tu serais à court de RAM ?

Je parie que tu es encore sur un vieux firmware

Non non, pour ça faudra suivre le changelog des prochaines mises à jour de firmware.

Quand on utilise la nouvelle application mobile, le visuel des QuickApps n'est pas rendu par l'application elle-même, mais par la box HC3 au travers d'une "WebView". C'est à dire que c'est la HC3 qui se charge de générer le rendu visuel du QuickApp, puis l'application mobile se contente de charger et afficher la page telle quelle. L'URL appelée est la suivante : http://192.168.0.1/app/webView/devices/ID (remplacer l'adresse IP et l'ID du QuickApp) On peut donc appeler directement cette URL depuis n'importe quel navigateur. Peu d'application pratique pour l'instant, mais j'imagine : en phase de développement, permet de visualiser rapidement le rendu d'un QuickApp sans devoir recharger l'application mobile Fibaro permettra ultérieurement de réaliser des designs avancés des QuickApps par simple mise à jour de firmware de la HC3 (et de nos codes LUA) sans devoir mettre à jour l'application mobile (rien que pour l'affichage d'une jaquette d'album, c'est une grosse avancée) pour ceux qui utilisent une interface externe pour piloter leur domotique, typiquement une tablette murale, on peut récupérer directement la vue du Quickapp sans aucun codage En revanche, l'inconvénient, c'est que ça ralentit l'affichage... car quand on est sur mobile, il est plus long de charger une page Web (protocole http lourd, chargement des balises, etc), qu'une API JSON et de mettre en forme localement. Exemple de rendu WebView :

Comme @Krikroff, pas de souci non plus