Lazer

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

C'est sûr que si GEA survit à tes centaines de règles, il peut tenir toutes les charges

Suite de la discussion sur le topic dédié Xiaomi Roborock, et notamment ce message où j'ai posté le tableau comparatif et le lien vers le site officiel présentant les différents modèles :

Si tu regardes sur mon tuto : => C'est bien une string qu'il faut envoyer dans la variable data de la requête http Le JSON encodé dans ta variable body2 semble maintenant conforme (en tout cas Notepadd++ la décode proprement), mais peut être que ton sèche serviette n'aime pas les espaces dedans (le code http 400 c'est "bad request", donc tu lui envoies une requête qu'il n'aime pas) Si tu veux être certain d'avoir un JSON correctement formaté, le mieux est encore... de ne pas le faire à la main ! Donc tu prend ta variable de type table, et tu l'encode avec json.encode avant de la mettre dans data Un truc du style : local body2 = { actions = { deviceURL = "io://0810-4343-0200/13610533#1", commands = { name = "setTowelDryerTemporaryState", parameters = "boost" } } } ... data = json.encode(body2)

C'est clair, les QuickApps sont moches... il est prévu de pouvoir les personnaliser... mais quand ? GEA est dans un QuickApp, mais c'est juste un conteneur, il n'affiche absolument rien sur le QuickApp. On pourrait le faire, mais pour afficher quoi ? Si quelqu'un à une idée pertinente, je suis preneur.

Bon, il y a du monde intéressé pour faire le beta testeur de GEA sur HC3 ? J'ai une version fonctionnelle, quasi à l'identique de ce qu'on avait sur HC2 (syntaxe identique), avec une grosse simplification : plus besoin de déclarer les triggers dans l'en-tête de scène, GEA les détecte maintenant tout seul, et surveille les événements (via l'API refreshStates) J'ai testé pas mal de choses, mais j'ai une toute petite installation, donc il traine probablement des bugs.

Le JSON de ta variable body2 est mal formé (Notepad++ refuse de le décoder... donc ton sèche-serviette aussi) Je n'ai pas cherché plus loin, je te laisse décomposer les accolades et parenthèses, tu vas trouver facilement je pense.

Je ne te conseille plus d'investir dans une HC2, c'est comme la HCL, ce sont 2 produits en fin de vie, qui ne connaitront plus d'évolution. Quitte à changer, il faut partir direct sur la HC3. Ou attendre une version Lite (mais aucune rumeur en ce sens....)

Très certainement un manque de ressources matérielles (CPU et RAM) sur la HC Lite. Mon avis a toujours été que cette box est juste un produit d'appel qui surfe sur la surpuissance de la HC2 (personne ne l'ai mis à genoux celle-là). La HC Lite, est bonne à inclure des modules, à les piloter à distance depuis son smartphone, mais faut pas lui en demander beaucoup plus. Quelques scènes simples, ça passe. Trop de scène, elle surcharge et devient lente, instable, plante, etc.... Je n'ai jamais eu cette box, mais j'ai vu plusieurs personnes sur le forum qui la rebootent très régulièrement pour la conserver en bon état de marche (à l'extrême, chaque nuit) L'historisation des données de consommation, ça prend de la place dans la base de données, donc des ressources matérielles. C'est comme les modules, les scènes, etc, ça participe à la saturation du peu de ressources disponibles. Autre sujet, une alarme ça ne se fait pas avec une box domotique, quelle qu'elle soit. Mais avec une alarme. Sujet déjà largement débattu sur le forum.

Ben s'il a mis le 230V sur les lampes qui attendaient du 12V ! Son message est très confus/incomplet... Peut être tout simplement qu'il a mis le dimmer sur l'alimentation des LED et que celle ci ne supporte pas la variation, c'est souvent le cas. On ne sait pas la marque, le modèle, le branchement etc... Le mieux ça reste les LED en 230V directement.

Le problème n'est pas qu'elle supporte ou pas le CSS, car bien sûr qu'elle le supporte. C'est plutôt que Fibaro bloque la possibilité d'injecter du CSS. Sur la HC2, Fibaro ne le bloquait pas sur l'interface Web (zone de debug ainsi que le rendu du module virtuel lui-même, ce qui permettait par exemple d'afficher une jaquette d'album à la place d'un label en texte), mais ils le bloquaient déjà au niveau de l'application mobile, si bien que l'utilisation des styles CSS était inutile en dehors de colorer la zone de debug. Pour personnaliser les QuickApps de la HC3, il faudra attendre que Fibaro nous le permette. Normalement c'est prévu, mais pour quand ?

Les balises styles=... sont bloquées Ce qui passe, c'est le bon vieux HTML4 avec des balises font=... etc Je pense que c'est le problème que j'avais, car justement j'utilisais également des balises de styles sur la HC2.

Ce n'est pas du GU10, et on voit clairement 12V Du coup la grande question : la fumée était de quelle couleur ?

OK, dans ce cas plusieurs possibilité : - régler une température de confort supérieure (correspondant à celle dont tu as besoin quand il fait humide), et exploiter couramment le radiateur à sa température de confort -1°C ou -2°C. C'est en pratique ce que je fais dans la salle de bain, où elle reste à conf-2, sauf le matin au moment des douches où elle est à conf maxi (donc plus chaud que la normale) - mettre le thermostat du radiateur à fond, et utiliser le Qubino en mode Confort / Arrêt uniquement avec un thermostat externe en association directe, comme le Secure SRT321 par exemple. La régulation sera faite par le thermostat externe, le Qubino et le radiateur se contentant d'obéir bêtement aux ordres. Comme expliqué précédemment, si tu as des radiateurs anciens, c'est parfait. Si tu as des radiateurs modernes et haut de gamme, et dommage car tu auras payé cher ces radiateurs pour rien, mais en dehors du coté financier, ce n'est pas un souci, ça fonctionnera très bien avec le régulation externe En option, le choix à ne pas faire : - utiliser un thermostat logiciel dont la régulation serait faite par la box domotique : au moindre problème de plantage, tu n'as plus de chauffage du tout (ou l'inverse, chauffage bloqué à fond, je ne sais pas ce qui est pire...) Nous sommes bien d'accord pour la nécessité de piloter le chauffage individuellement par pièce La régulation par zone est un pis aller utilisé par les automatisme de chauffage vendus en grande surface de bricolage (type Delta Dore, etc), ce n'est pas au niveau de ce qu'on fait avec de la domotique.

Probablement pas. En même temps Fibaro a tellement pris les gens pour des cons avec la HC2, faut pas qu'ils s'étonnent d'avoir une mauvaise image avec leur nouvelle box. Malheureusement comme plus personne ne fait de retour sur les numéros de série sur le topic dédié, difficile de savoir si les bonnes ventes du printemps ont perduré ou pas. Quoi qu'il en soit, la stratégie de Fibaro/Nice c'est de vendre aux pros/intégrateurs, pas au grand public. Du coup les prix sur les boutiques en lignes ne sont pas forcément représentatifs de la quantité de box distribuées. Mais là encore, le suivi des numéros de série nous permet d'y voir clair (quand que Fibaro respecte une numérotation incrémentale linéaire....)

C'est surprenant, quand la HC3 est sortie avec les premiers firmwares, j'étais persuadé que Fibaro avait bloqué la possibilité d'injecter du code HTML pour mettre en forme le texte dans la zone de debug (chose qu'on pratiquait déjà courament sur la HC2) Du coup je viens de réessayer, et ça fonctionne bien, donc soit j'ai rêvé, soit Fibaro a ajouté cette possibilité entre temps. En tout cas, merci pour le tuto et d'avoir démontré que ça fonctionne Maintenant je vais pouvoir remettre plein de couleurs dans les logs de mes QuickApps