Commande http depuis un NAS pour la MAJ d'une variable dans un QuickApp

[manuxenon]

Bonjour.

Je cherche à mettre à jour une variable intégrée dans un QuickApp depuis mon NAS :

- j'ai essayé la commande :

http://192.168.0.120/api/callAction?deviceID=267&name=updateProperty&arg1=ui.Json.value&arg2=%22{%27id%27:131,%27value%27:21.0}%22

J'ai bien un retour avec " message": "Accepted" " dans le navigateur.

Dans le debug de la HC3, j'ai bien :

[16.04.2021] [14:46:28] [DEBUG] [QUICKAPP267]: onAction: {"args":["ui.Json.value","{'id':131,'value':21.0}"],"actionName":"updateProperty","deviceId":267}

 

Mais la mise à jour de la variable ne se fait pas.

 

 

Merci de votre aide.

[Lazer]

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....

[manuxenon]

Merci Lazer.

Avec setVariable, ca fonctionne.

 

Je suis en train de mettre à jour (dans HC3) ma récupération de mes sondes Zibase qui sont envoyé pour le moment à ma HC2.

J'avis utilisé cette méthode :

 

 

Je vais essayer d'avancer.

Encore merci.

[Lazer]

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

 

[Lazer]

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é.

[manuxenon]

Ah oui. Là, c'est encore plus simple.
Je teste de ce pas avec un QuickApp en multilevelSensor : il me faut la température et l'humidité.

Merci Lazer.

[Lazer]

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

 

[manuxenon]

Plutôt de type "Temperature Sensor" : il y a les graphs d'intégrer dans l'onglet "Avancé : trop lent (voir réponse ci-dessus).

Pour l'humidité "Humidity Sensor", il n'y a pas de graphs. Je pense que je peux prendre un "Temperature Sensor" même pour celui-là ?

 

Modifié le 16 avril 2021 par manuxenon

[Lazer]

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.

 

 

 

Modifié le 16 avril 2021 par Lazer

[manuxenon]

Ok, merci Lazer. Je suis tes conseils pour les capteurs.

 

J'avais vu pour DomoCharts. Mais je remets tout en place, avant dans HC3, avant de l'installer.

 

Merci.

Modifié le 16 avril 2021 par manuxenon

[manuxenon]

C'est impeccable comme solution et bien plus facile que sur la HC2.

 

Une dernière chose Lazer, comment faire pour que le "Temperature Sensor" soit le parent et le "Humidity Sensor" soit l'enfant (car il s'agit de la même sonde Oregon).

Je ne vois rien dans les réglages de chaque QA ?

Si c'est possible, est-ce un bon choix ?

 

Peut-on gérer aussi les "batteries" de ces QA (avec la Zibase je peux savoir si la batterie est faible) ? Je n'ai pas vue de "batteryLevel" dans les propriétés des QA.

 

Merci.

Modifié le 16 avril 2021 par manuxenon

[Lazer]

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

 

[manuxenon]

Ok, je ne touche rien pour les 2 QA. C'était pour éviter de tout reprendre, j'ai une vingtaine de QA à créer.

 

Concernant le niveau de batterie pour mon nouveau "Temperature Sensor", l'ajout de l'interface avec le code ci-dessous:

/api/callAction?deviceID=269&name=addInterfaces&arg1=battery

Donne ces messages dans les logs :

[16.04.2021] [18:20:44] [DEBUG] [QUICKAPP269]: onAction: {"actionName":"addInterfaces","deviceId":269,"args":["battery"]}

[16.04.2021] [18:20:44] [DEBUG] [QUICKAPP269]: /usr/share/lua/5.3/common/device.lua:113: assertion failed!

[16.04.2021] [18:20:44] [ERROR] [QUICKAPP269]: QuickApp crashed

[16.04.2021] [18:20:44] [ERROR] [QUICKAPP269]: Unknown error occurred: handleJsonRpc

[16.04.2021] [18:21:00] [DEBUG] [QUICKAPP269]: onInit

 

Modifié le 16 avril 2021 par manuxenon

[Lazer]

É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.

[manuxenon]

Les 2 lignes en http n'ont pas fonctionné.

 

Par contre, c'est ok en lua, avec une modif sur l'avant dernière ligne (car la batterie était sur 0%) : "battery" remplacé par "batteryLevel".

 

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("batteryLevel", 100)
end

C'est parfait.

Merci Lazer.

Modifié le 16 avril 2021 par manuxenon

[Lazer]

Cool

 

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

[pilou87]

Bonjour #Lazer
trés bonnes explications sur les variables des QA, mais pourrais-tu avoir la gentillesse de me dire ce qu'il en est pour toucher
à distance une variable globale défini dans la HC3. D'avance merci

[Lazer]

Tout ce que tu fais sur la HC3 via l'interface Web, tu peux le faire en passant par l'API HTTP de type Restful.
Pour découvrir les API utilisées, dans ton navigateur du tapes (gentiment) la touche F11 pour afficher les outils de développement, puis onglet "Réseau", et ainsi tu verras toutes les requêtes effectuées sur l'API pendant que tu réalises l'action voulue dans l'interface. Attention il peut y avoir du monde, car il y a le chargement des images, etc, donc il faut isoler la requête utile.

Une fois que tu as cette requête, tu peux t'en servir aussi bien directement depuis la box en LUA, ou à distance avec le langage de ton choix.

 

Autre source d'information, officielle cette fois-ci, le Swagger intégré sur ta box qui documente la plupart des API (mais pas toutes, d'où la méthode F11 plus générique)

 

 

 

[pilou87]

#Lazer

Merci pour cette explication très claire et très utile.