Lazer

Sur le forum officiel des gens se plaignent également d'un reboot aléatoire, mais aucune solution n'est apportée non plus, si ce n'est de vérifier les QuickApps un par un... : https://forum.fibaro.com/topic/54191-fibaro-services-seem-to-crash-every-x-days/

Il ne faut pas mettre /api dans la fonction api.get() Donc : api.get("/alarms/v1/partitions/" .. id)

Ah OK, merci du retour. Je suis toujours sur le contrôleur en version logiciel dans une VM de mon coté, donc je n'ai pas eu de genre de problème.

Ce n'est pas mon cas, mais j'ai très peu de modules Z-Wave, donc pas forcément représentatif d'une box normale. Cela dit j'ai pas mal de QuickApps, et au début, j'avais eu des reboots automatique, à cause d'un QuickApp qui faisait n'importe quoi. Il y a un Watchdog intégré dans la box, qui le redémarre automatiquement si elle le juge nécessaire.... donc peut être as-tu un QuickApp qui fout la grouille ? Pas évident à détecter... Sinon il faudrait demander au support Fibaro, en analysant les logs ils peuvent peut être déterminer la cause du problème.

Héhé... joyeux anniversaire @Steven

Les scènes en mode bloc, je n'y connais rien, trop compliqué pour moi, c'est plus lisible en LUA Déjà je vois qu'en trigger tu as coché la sirène elle-même, je pense que c'est une erreur. Attendons qu'un expert passe par là. Mais comme je t'ai dit plus haut, tu n'as pas besoin de cette scène, normalement le panneau d'alarme peut activer lui-même ta sirène, à configurer dans les actions (mesures). Je n'ai pas de sirène (enfin si, mais une vraie, avec mon alarme, mais rien à voir avec la domotique). Par contre le panneau déclenche bien le clignotement des lumières, l'envoi de snapshots des caméras, etc, tout cela sans scène dédiée.

ça fait longtemps que je n'utilises plus la HC2 tu sais.... Bref j'avais oublié, c'est encore un truc à l'envers. Il faut que tu ailles dans les paramètres, onglet avancé, de chaque capteur. Là tu devrais voir un champ permettant d'inclure ou d'exclure le capteur du panneau d'alarme (sachant qu'ils ont inclus par défaut) Après, quand tu retourneras sur ton panneau d'alarme, dans la listes des capteurs (sur ton screenshot), tu ne devrais voir que ceux que tu as laissé (donc ceux que tu as exclus ne doivent pas apparaitre) Ensuite tu pourras écrire tes 2 scènes pour armer/désarmer les capteurs.

Sur HC2, il faut utiliser le panneau d'alarme. Il faut ajouter tous les capteurs d'ouverture que tu veux dans le panneau d'alarme, et choisir les moyens de réaction (lumière, sirène, etc) Pas besoin de scène pour ça. Ensuite à l'usage, il te faudra une scène pour armer tous les capteurs le soir, puis une autre scène pour les désarmer le matin. Pour le WAF, il te faudra une télécommande placée par exemple dans la chambre, pour lancer les scènes facilement sans devoir sortir le téléphone à chaque fois. Et oui c'est bizarre la logique sur HC2, ce n'est pas la panneau d'alarme qu'on arme, ce sont chaque capteur individuellement. D'ailleurs sur HC3 ça a été remis dans la logique des choses, puisque ce sont les zones d'alarmes que l'on arme, comme une vraie alarme en fait. EDIT : si tu veux aller plus loin, chercher le module virtuel "alarme avancée" sur le forum.

Rigolons un peu

@Gazous je suis retombé par hasard là dessus, ça pourrait t'aider pour le callGroupAction :

Bienvenue sur le forum

J'ai vu passer des problèmes sur le forum officiel, mais de mon coté je n'ai rien remarqué. J'ai 4 zones de climat, et les températures sont bien envoyées aux thermostats. Avec GEA tu peux piloter soit les zones de climats, soit directement les thermostats.

Il est chiffré pour des raisons de sécurité (comme les backups)

Cool Oui exact pour la propriété "batteryLevel", copier/coller trop rapide de ma part .

Étrange Essaye peut être l'un de ces 2 syntaxes : /api/callAction?deviceID=269&name=addInterfaces&arg1=%7B%22battery%22%7D /api/callAction?deviceID=269&name=addInterfaces&arg1=%7Bbattery%7D Sinon il faudra le faire en LUA, comme @tinman a expliqué sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/8/?tab=comments#comment-202936 Dans la fonction QuickApp:onInit() de ton QA, il faut ajouter quelque chose comme ça (non testé, donc tu devrais être débugger un peu) : function QuickApp:onInit() self:debug("onInit") -- add battery interface once local function checkInterface(param) thisdev = api.get('/devices/'.. plugin.mainDeviceId) for e,i in ipairs(thisdev.interfaces) do -- print(i) if i == param then return 1 end end return 0 end if checkInterface("battery") == 0 then self:addInterfaces({"battery"}) -- reinit once, might be necessary to change already battery in onInit self:onInit() end self:updateProperty("battery", 100) end Et si ça fonctionne après tu peux enlever ce code, ce n'est pas la peine de le conserver, une fois que le device a une interface, il la conservera toujours.

Tout est possible. Effectivement, ces 2 QA sont de la même "famille", mais la température n'est pas le parent de l'humidité, en fait dans la logique Fibaro, ils sont tous les 2 frères et soeurs, et ils devraient avoir pour device parent un QA générique de type "device controler". Cela est expliqué sur ce topic : Mais attention, c'est largement plus compliqué que ce que tu as fait ici, et nécessite pas mal de lignes LUA.... Si tu veux mon avis, pour ton cas à toi, l'intérêt de te lancer là dedans est nul, car tu as 2 QA ultra simples qui ne font rien (aucune ligne de code LUA), donc : - simple à réaliser (aucune ligne de LUA, pas de programmation, juste la mise à jour de la value via l'API HTTP) - consomme peu de ressource CPU/RAM car tu n'as pas de code LUA qui tourne en boucle Je te suggère donc de conserver tes 2 QA tous simples et indépendants tels quels. Pour la batteryLevel, tu peux l'ajouter, c'est une "interface" supplémentaire. Normalement ça se fait en LUA, mais tu devrais pouvoir le faire via l'API une bonne fois pour toute. Essaye quelque chose comme cela : /api/callAction?deviceID=131&name=addInterfaces&arg1=battery Tu devrais voir apparaitre la propriété batteryLevel dans son JSON, que tu mettras à jour de la même façon que la value : /api/callAction?deviceID=131&name=setProperty&arg1=batteryLevel&arg2=100

Cela ressemble effectivement à un cœur saturé, mais dans mon cas, la box fonctionnait parfaitement. Lors du prochain plantage (j'espère pas, mais bon...) il serait intéressant de relever le résultat de : /api/service/servicesStatus Exemple sur un système sain, tous les services sont Ok / true : { "HCServer": { "running": true, "status": "Ok", "devicesStatus": { "disconnected": 0, "directRoute": 5, "indirectRoute": 2, "unknownRoute": 1, "batteryEmpty": 0, "batteryLow": 1, "batteryMedium": 0, "batteryHigh": 1 } }, "Zwave": { "running": true, "status": "Ok" }, "FibaroServices": { "running": true, "status": "Ok" }, "RemoteAccess": { "running": true, "status": "Ok" } } Je n'ai pas eu de plantage de mon HC3, donc je peux pas encore développer de watchdog, mais c'est la technique que j'utilise sur HC2 pour la redémarrer en cas de crash (ce watchdog tourne sur le NAS) L'augmentation de la mémoire Cache au moment du backup c'est normal, c'est le fichier backup qui est mis en mémoire cache et conservé tant qu'il y a de la place. C'est le principe même du cache, un OS (quel qu’il soit, Linux, Windows, etc.... va toujours chercher à remplir la mémoire au maximum avec du cache... .c'est la façon de le montrer qui diffère) Pour rappel le fichier backup c'est un dump de la DB, des icônes, etc... le tout zippé dans un fichier chiffré. C'est bien pour cette raison que la vraie mémoire libre (au sens : disponible pour les applications), c'est la somme de Free + Cache. Le Buffer lui est toujours à peu près constant (et à une valeur très faible) On voit bien la génération du fichier backup sur mon graph, le 10 avril à 3h :

Non tu prends un humiditySensor Il n'y a pas de graph en standard, mais tu en auras si tu installes DomoCharts. Et dans tous les cas, tu auras la bonne icône, etc C'est très simple, il faut faire comme Fibaro, donc s'inspirer des modules Z-Wave qu'on a inclus, et faire pareil avec les QA.

Non pas de multilevelsnesor, tu n'as toujours pas compris le principe de Fibaro. Donc là ça te faut 2 QA : un temperatureSensor et un humiditySensor (ils sont tous 2 basés sur le type multilevelSensor, mais avec la bonne unité, la bonne icône, etc... bref l'intégration propre et native dans la box) J'insiste : OUBLIE LA HC2

Et du coup pour mettre la température 21°C dans le QuickApp ID 131, l'appel à l'API devient tout simplement : /api/callAction?deviceID=131&name=setProperty&arg1=value&arg2=21.0 Hop, terminé.

Ah oui, mais alors tu te bases effectivement sur des vieilleries D'ailleurs, là encore tu restes trop dans l'esprit HC2, il faut oublier tout ça. Complètement Totalement Intégralement ... Bref, la "bonne" méthode (au sens HC3) c'est de créer des QuickApps nativement typés comme il faut. Par exemple capteur de température (que tu choisis au moment de sa création dans la liste déroulante) Puis tu affectes directement sa valeur dans le champ properties.value Et terminé. Pas besoin de label, variable, json, et autre trucs compliqués Je n'arrête pas de le dire sur ce forum, mais oubliez la HC2 les gars, la HC3 reprend tout proprement dès la base : chaque device, a un type, et une value => Intégration native dans l'interface

Pour moi updateProperty n'est pas la bonne action à appeler => il faut appeler l'action setVariable Par ailleurs, ta variable est pour le moins curieuse. Déjà son nom... "ui.Json.value" mais pourquoi un truc aussi compliqué ? J'ai l'impression que tu raisonnes HC2 et que tu confonds avec les anciens Labels des VD historiques. Ensuite son contenu... tu mets un tableau dans le string, avec un id et une value... mouais, là aussi pas fan, tu vas t'ennuyer à json.encoder et json.decoder ça à chaque usage, avec un risque de plantage au passage (les fonctions json.encode() et json.decode() plantent dès que le JSON est mal formaté) En plus ça fait utiliser des cycles CPU pour rien, il est plus efficace de stocker une variable dont la valeur est directement utilisable. Et pour finir quand tu fais tes requêtes sur l'API tu es obligé d'url-encoder la string à cause des caractères spéciaux (accolades, guillemets) Je te propose de simplifier tout ça, en mémorisant tes 2 valeurs dans 2 variables distinctes : - id - value (tu les nommes différemment si tu préfères) Du coup pour la mise à jour via l'API : /api/callAction?deviceID=267&name=setVariable&arg1=id&arg2=131 /api/callAction?deviceID=267&name=setVariable&arg1=value&arg2=21.0 Keep it simple....

Oui d'ailleurs pas la peine de redéclarer une variable arg, tu peux utiliser directement la pseudo variable {...} Exemples : local function une_autre_fonction(...) for k, v in pairs({...}) do end end local function fonction_principale(...) une_autre_fonction(table.unpack({...}) end

La variable prédéfinie args existait dans les anciennes versions de LUA il me semble... je ne sais plus en détail. Sur HC2, c'était genre LUA 5.2 dans les scènes, et LUA 5.1 dans les VD... il me semble. Mais sur HC3 on est en LUA 5.3, ça c'est sûr, et il faut bien utiliser la syntaxe avec les accolades {...}

La concaténation d'un string avec un number donne toujours un string (le LUA fait automatiquement le tostring() sur le number), donc c'est normal. Si par contre tu faisais ça : local IdDevice = 258 self:setVariable(IdDevice) Alors c'est bien un number qui serait stocké dans la variable du QuickApp. Même si là encore, ça ne pose aucun souci à l'API qui le gère très bien, à l'inverse l'interface Web n'aime pas.