Aller au contenu
MAM78

HC2 - Version 4.11x - Fonction figaro:args() - passage de paramètres pour les scènes

Recommended Posts

Pour simuler le retour de la fonction, il faut faire une boucle While qui lit la variable globale et n'en sort que quand le retour est celui attendu. En n'oubliant pas de mettre un timeout au cas où la scène plante et ne met jamais à jour la variable globale.

J'ai déjà un VD (jamais partagé car spécifique à mon usage) qui fonctionne sur ce principe.

 

Exemple :

local debug = true -- or false
local sceneID = 20
local returnVGname = "variable_globale_de_retour"
local expectedReturnValue = "OK"
local Max_Elapsed_Time = 60 -- seconds

-- Call scene
figaro:startScene(sceneID, {{vg = returnVGname}, {param1 = "Valeur 1"}, {param2 = "Valeur 2"}})

-- Wait scene execution
local startTime = os.time()
while true do
	if debug then
		Message("gray", "Waiting...")
	end
	local returnVG = fibaro:getGlobalValue(returnVGname)
	if returnVG == expectedReturnValue then
		Message("green", "Scene finished with success")
		break
	elseif returnVG == "Fail" then
		Message("red", "Scene failed")
		fibaro:abort()
	end
	local elapsedTime = os.difftime(os.time(), startTime or 0)
	if debug then
		Message("gray", "Elapsed time : " .. elapsedTime)
	end
	if elapsedTime > Max_Elapsed_Time then
		Message("red", "Scene timeout")
		fibaro:abort()
	end
	fibaro:sleep(30*1000) -- Wait 30 seconds
end

 

A customiser pour vos besoins, mais c'est une trame de départ.

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, Nico a dit :

Du coup comme JJ du 68, le passage de paramètre fonctionne aussi depuis l'API ?

Certainement, faudrait trouver l'API en question.

Mais ça doit être faisable, vu que quasiment toutes les fonctions LUA appellent l'API http

Partager ce message


Lien à poster
Partager sur d’autres sites

Effectivement watchdog, c'est ce à quoi j'ai pensé au moment ou j'ai validé ma question ;)

 

Il n'est pas possible d'écrire sur la clef USB de sauvegarde dans un fichier dédié aux log. Avec en parallèle une scène qui s'occuperait d'envoyer des notifications sur la détection de messages les plus critiques mais également de faire des purges pour éviter de saturer la clef ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Très mauvaise idée d'écrire sur la clé, tu vas la tuer, ce n'est pas fait pour écrire des logs.... pour info, les logs de Linux Raspbian sont ce qui tue les cartes SD sur les Raspberry PI.

 

De toute façon, tu ne peux pas car :

- la clé est démontée en temps normal depuis plusieurs firmware

- il faut être root pour y accéder

 

La meilleure solution est d'envoyer les logs sur un serveur externe.

Si t'es motivé, tu crées une scène qui génère des logs au format standard syslog, et tu pourras envoyer vers n'importe quel Linux (y compris les Synology). Là c'est propre et professionnel.

Partager ce message


Lien à poster
Partager sur d’autres sites

Merci @Lazerpour la suggestion. J'ai installé sur mon synology le paquet Centre des journaux qui permet de consulter les logs de mon syno.

 

Etant encore très novice en LUA, je veux bien essayer mais je vais avoir besoin d'aide notamment sur la partie écriture du code LUA qui permettrait d'écrire dans la log de mon syno.

 

Est-ce que tu pourrais m'orienter sur un exemple de code LUA pour me connecter et écrire dans la log du syno ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Franchement je n'ai pas le temps, car ça représente pas mal de travail à mon avis.

Il faut trouver les spécifications du protocole Syslog, pour voir à quoi ressemble les trames, et ensuite coder cela en LUA.

Partager ce message


Lien à poster
Partager sur d’autres sites

j'espère ne pas être hors sujet.

Avant j'écrivais directement "Réveil écran" dans une variable globale, une scène triggée par la globale se chargeait d'envoyer le message contenu dans  la VG vers impérihome : qui disait bien "Réveil écran"

Pour utiliser le transfert d'arguments dans les scènes, maintenant j'appelle la scène avec "Réveil écran" comme argument. La scène réceptrice, decode l'argument et l'envoi vers  impérihome : qui trébuche manifestement sur les accents.

j'ai donc regardé dans le try it de  (ImperiHome Control API - Documentation) pour récupérer la chaine, qui devient : "R%C3%A9veil %C3%A9cran"

Ce qui voudrait dire que dans ma première version avec la Variable Globale,  soit  fibaro:getGlobalValue soit  fibaro:setGlobal faisait la conversion des accents ???

Existe t'il une fonction de conversion en lua ?

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 13 heures, Lazer a dit :

Franchement je n'ai pas le temps, car ça représente pas mal de travail à mon avis.

Il faut trouver les spécifications du protocole Syslog, pour voir à quoi ressemble les trames, et ensuite coder cela en LUA.

 

 

@Lazer : C'est fait, voir mon Tuto ci-dessous. En fait, pas si compliqué que ça.

 

Merci de m'avoir motivé et challengé :D pour me lancer dans la création d'une scène (un VD en l'occurence pour le moment) qui génère des logs au format standard syslog, qui pourrait être envoyer vers n'importe quel Linux (y compris les Synology). Là c'est propre et professionnel.

 

 

Modifié par MAM78
  • Upvote 2

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 22 heures, Lazer a dit :

Certainement, faudrait trouver l'API en question.

Mais ça doit être faisable, vu que quasiment toutes les fonctions LUA appellent l'API http

 

Je confirme, voici les infos :

 

URL à appeler en POST :

/scenes/123/action/start

Données à envoyer en POST :

{["args"]=args})

 

 

@MAM78 je pense que tu peux ajouter cette info dans le premier message, ça peut être utile pour ceux qui désirent lancer la scène depuis un appareil externe, tel qu'un IPX800 ou autre.

  • Upvote 1

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, Lazer a dit :

Je confirme, voici les infos :

 

URL à appeler en POST :


/scenes/123/action/start

Données à envoyer en POST :


{["args"]=args})

 

oui mais marche pô avec une requette http envoyé par un ipx... :(

Partager ce message


Lien à poster
Partager sur d’autres sites

tu peux développer ? c'est quoi le problème ?

je pensais justement à l'IPX, j'avais édité mon message entre temps

Partager ce message


Lien à poster
Partager sur d’autres sites

j'ai essayé avec

 

/api/sceneControl?id=147&action=start&args=MonArgument1

/api/sceneControl?id=147&action=start&args={args=MonArgument1}

 

Mais rien...

Partager ce message


Lien à poster
Partager sur d’autres sites

Je vous laisse débuguer ;)

 

Dès que c'est bon, vous pouvez me formaliser un exemple succinct afin que je l'ajoute en début de Tuto.

Partager ce message


Lien à poster
Partager sur d’autres sites

rassure moi, tu fais bien du POST comme je l'ai indiqué ?

Car là tu me présentes des requêtes GET, donc forcément, ça ne va pas marcher....

 

j'ai un doute, je crois que l'IPX ne sait pas faire de POST, mais que du GET et du PUT. Tu confirmes ?

Partager ce message


Lien à poster
Partager sur d’autres sites

@MAM78 tu peux mettre en premier message, l'info est fiable car extraite des sources de Fibaro.

C'est Jacques qui se trompe dans la config de l'IPX je pense, à cause de la limitation de l'IPX.

Partager ce message


Lien à poster
Partager sur d’autres sites

je pense que je me trompe, en effet l'ipx ne permet pas grand chose...

après si c'est du post, put ou get, je ne saisi pas :)

voilà ma config sur l'ouput concernée :

 

ipx.png.ef0e2067d51d04fe059a4945e8530655.png

Partager ce message


Lien à poster
Partager sur d’autres sites

Si il ne précise rien, c'est que c'est du GET par défaut, donc tu ne pourras pas démarrer une scène avec des arguments directement depuis l'IPX.

Tu as une v3 ?

 

Je viens de vérifier sur mon IPX800 V4, on peut bien faire du GET et du POST, mais il ne permet pas d'insérer le champs de données, donc le POST ne sert à rien..... pfff dommage, faudrait remonter l'info à GCE

Partager ce message


Lien à poster
Partager sur d’autres sites

j'ai  16 scènes pour les notifiactions push (on/off sur chaque sorties) sur mon tél.

 

Avant la mise à jour qui nous obligeait à passer le login du superuser en adresse mail, je pouvais envoyer la commande suivant :

/api/callAction?deviceID=62&name=sendPush&arg1=blablabla

 

Mais maintenant, le champs login des paramètre push setting de l'ipx ne permet pas de saisir autant de caractères.

J'ai donc créer un autre user avec moins de caractères pour pouvoir entrer dans ce champs de l'ipx.

Mais cette commande sendPush ne fonctionne pas avec un user autre que superUser... !

J'avais contacté le support fibaro, mais ils ont pas tout compris, je crois.

 

bon là je m'écarte du sujet, mais cette histoire d'arguments m'aurait arrangé, comme ça j'aurai eu juste une scène avec les bonne infos envoyées par arguments...

 

 

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Dommage effectivement sur les IPX. j'ai bien fait d'attendre vos tests ;)

 

Sinon c'est faisable avec d'autres solutions qui utilise l'API ? @Lazer tu aurais un autre exemple à donner pour illustrer la chose ?

Modifié par MAM78

Partager ce message


Lien à poster
Partager sur d’autres sites

Tu peux mettre à jour le premier post avec les infos de l'URL ?

 

Les exemples ? Facile, n'importe quel appareil externe (sauf l'IPX donc, en attendant que GCE ne fasse évoluer son firmware)

Cela peut être une box domotique utilisée en passerelle (au hasard, Jeedom, FHEM, Zibase, etc), des scripts Shell (CURL), des pages Web (PHP), etc, la liste est infinie. Mais tu n'as pas à préciser ces infos, c'est aux utilisateurs de faire en fonction de leurs besoins, le premier post est juste là pour donner la syntaxe de l'API, et c'était la demande initiale de Nico je crois.

Partager ce message


Lien à poster
Partager sur d’autres sites

Qu'on puisse ajouter le champ de données quand on envoie une requête de type POST (après tout, ça sert justement à ça le POST, contrairement au GET qui est conçu pour uniquement recevoir des données)

Par la même occasion, ça ne couterait rien qu'il ajoutent la possibilité de faire des requêtes PUT.

Partager ce message


Lien à poster
Partager sur d’autres sites

×