Aller au contenu
jjacques68

API - supprimer une action retardée

Recommended Posts

Hello tout le monde

 

alors suite à une discussion dans un autre sujet, j'ai ouvert celui-ci pour ne pas polluer le précédent...

 

Nous avons vu que l'on pouvait, sur la HC3, retarder une action sur un device, avec cette méthode

api.post("/devices/"..id.."/action/turnOff", {delay = 60})

 

et la commande ci-dessus nous renvoie ceci :

{"id":22,"timestamp":1586330337}

il s'agit de l'ID de l'action (retardée) ainsi que son timestamp où elle se déclenchera.

ATTENTION : ce n'est pas l'ID du device !!

 

ET dans mon cas, je souhaite pourvoir supprimer cette enregistrement, afin de ne plus exécuter cette action en attente !!

 

En effet, J'ai dans la salle de bain, un PIR qui me déclenche la lumière et la VMC.

Quand je quitte la SDB, au bout de 30 secondes la lumières s'éteint, mais la VMC reste allumée pendant 1 minute.

d'où ce retard que j'ai mis.

Mais si je rentre a nouveau dans la SDB, dans l'interval de la minute, je souhaite que le précédent timestamp de fin soit supprimé pour être remplacé par le nouveau!

logique non :) 

Mais là, tel quel, si je re rentre dans la salle de bain, il se peut que la VMC  se coupe, car la première minute a été atteinte.

Bref si vous avez pas compris c'est pas grave...

 

Alors il existe clairement une commande DELETE dans l'API permettant de supprimer l'action retardée !!

Il suffit de saisir l'ID de l'action et son timestamp !!!  super !!!

 

sauf que !! 

comment je peux savoir que qu'il y a une action retardée pour ce device ?

il manque une info !

si je souhaite supprimer une action retardée d'un device, il faut que je puise au moins la retrouver via l'ID du device qui en est à l'origine !

 

Sinon je sens bien qu'il va falloir stocker quelque part l'ID du device émetteur et le mettre en relation avec l'ID de l'action retardée et le timestamp de fin !!!

du style :

{"idTrigger":256, "id":22, "timestamp":123456789}

Mais alors pffffffffffff, faire ça soit même !!!! c'est pénible !!!!!

C'est obligé que dans l'API, cette information y soit !!!

Sinon, comment la HC3 sait, qu'à ce moment là précis, c'est le device (ici 256) qu'elle doit éteindre !!!??,

 

je suis passé à côté de quelque chose ?

 

Modifié par jjacques68

Partager ce message


Lien à poster
Partager sur d’autres sites

Je n’ai pas vérifié mais à première vue je dirais qu’il s’agit d’un ID timer, comme celui renvoyé par en SetTimeout... Enfin pas le SetTimeout Fibaro mais celui sur lequel il est basé

 

si mon intuition est bonne alors tu devrais pouvoir annuler l’action en attente à l’aide d’un cleartimeout

Partager ce message


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

à l’aide d’un cleartimeout

c’est quoi que ça ? :) 

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Cela permet d’interrompre un interval ou un timer en cours avant son exécution...

Je vais faire quelques tests dans la soirée


Envoyé de mon iPhone en utilisant Tapatalk

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui pas le choix tu vas devoir faire une table de mapping afin de faire correspondre un device avec un ID de timer pour suppression...

Partager ce message


Lien à poster
Partager sur d’autres sites

mouai c’est ce que je craignais...

bon ben ok... va pour cette solution...

 

merci !!

Partager ce message


Lien à poster
Partager sur d’autres sites

Je dois certainement m'y prendre mal, pourtant j'ai l'impression de faire les choses bien... mais ça marche pas...

 

J'ai l'impression que api.delete ne fonctionne pas

 

voici le code

 

la VG DelayVmc est une table en fait : [{"API":{"timestamp":1586419043,"id":130},"VMC":226}]

où on retrouve l'ID de la VMC ainsi que les infos nécessaires pour l'API.

 

--récupère le contenu de la VG
ListeDelay = fibaro.getGlobalVariable("DelayVmc")
ListeDelay = json.decode(ListeDelay)

--supprime un(ou les) précédent delay si trouve                        
for index,value in pairs(ListeDelay) do
  if value.VMC == v.id then	--v.id vient d'une boucle plus haut dans le code, et contient l'ID de la VMC
    res = api.delete(string.format("/devices/action/%s/%s",value.API.timestamp,value.API.id))
    print(json.encode(res))
    table.remove(ListeDelay, index)
  end
end

--mémorise la VG modifiée
ListeDelay = json.encode(ListeDelay)           
fibaro.setGlobalVariable("DelayVmc", ListeDelay)

 

pas de message d'erreur, rien, ...

Les valeurs dans la VG sont tout a fait cohérente

Mais l'enregistrement du OFF n'est pas supprimée, la VMC s'éteint au bout du temps définit lors du premier OFF

 

si quelqu'un a une idée ?

Modifié par jjacques68

Partager ce message


Lien à poster
Partager sur d’autres sites

alors j'ai fini par y arriver !

 

mais je comprends pas pourquoi cela ne marche pas

 

res = api.delete(string.format("/devices/action/%d/%d",timestamp,id))
print(json.encode(res))

----> réponse : nil

mais ça c'est ok :

local http = net.HTTPClient({ timeout = 20000 })
http:request(string.format("http://127.0.0.1:11111/api/devices/action/%d/%d",timestamp,id), {
	options = {
		method = "DELETE",
	},        
	success = function(status) print(status.status) end,
	error = function(error) print(status.status) end
})

-----> réponse : 200 (ou 404 si inexistant) comme décrit dans l'API

 

???????

Modifié par jjacques68

Partager ce message


Lien à poster
Partager sur d’autres sites

Je pense être dans le bon post (?),

 

Voici ma question

 

Dans le cas d'un .setTimeout utilisé dans une scène triggée (par un FGMS par exemple), est-ce qu'un nouveau déclenchement de ladite scène ANNULE le .setTimeout ?

 

A moins que ce .setTimeout soit un "thread" autonome ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Je n'utilise que très peu les scènes, mais la réponse à ta question semble être ce paramètre :

 

Autoriser le redémarrage de la scène en cours d'exécution: Oui/Non

 

image.thumb.png.a4f3e004df181386f3ccadba9d655261.png

 

 

Donc si tu choisis "Oui", alors la scène sera redémarrée de force, donc l'instance précédente stoppée (et donc forcément l'éventuel setTimeout qui était dedans)

 

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est bien la configuration de cette scène.

 

L'info que je recherchais est bien le fait que le setTimeout sera stoppé.

 

Un grand merci !

 

PS : je sais que je devrais me lancer dans les QA, mais la réno de ma maison en rondins me bouffe tout mon temps (question de WAF également dans ce cas ;)).

Modifié par Sowliny

Partager ce message


Lien à poster
Partager sur d’autres sites

Précision : le setTimeout ne fonctionne pas dans un Thread autonome, car tous les QA et Scènes sont mono-threadés sur la HC3 (comme sur la HC2)

Le setTimeout fait donc partie du process de la scène en cours d'exécution.


Quand une nouvelle instance de scéne démarre, c'est à dire un nouveau processus (au sens Linux) est démarré, donc le précédent est tué, afin de ne pas laisser plusieurs instances (= processus) de scènes s'exécuter en parallèle.

Et ça c'est une différence fondamentale avec la HC2, sur laquelle on pouvait avoir jusqu'à 10 instances (processus) de scènes s'exécuter en parallèle.

Partager ce message


Lien à poster
Partager sur d’autres sites

y aurait pas une histoire aussi de clearTimeout() ?

pour annuler un setTtimeout() en cours...

Partager ce message


Lien à poster
Partager sur d’autres sites

oui mais le clearTimeout() c'est pour interrompre un timeout en attente dans un process (instance) de scène/QA en cours d'exécution.

 

Si le process/instance est tué parce que la scène/QA a été redémarré, alors peu importe le cleartimeout, puisque de toute façon le process précédent n'existe plus, et avec lui le timeout en attente.

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

ah oui oui tout à fait !!

désolé, avais mal lu la question initiale ^_^

:74:

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×