jjacques68 Posté(e) le 8 avril 2020 Signaler Posté(e) le 8 avril 2020 (modifié) 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é le 8 avril 2020 par jjacques68
Krikroff Posté(e) le 8 avril 2020 Signaler Posté(e) le 8 avril 2020 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
jjacques68 Posté(e) le 8 avril 2020 Auteur Signaler Posté(e) le 8 avril 2020 Il y a 6 heures, Krikroff a dit : à l’aide d’un cleartimeout c’est quoi que ça ? 1
Krikroff Posté(e) le 8 avril 2020 Signaler Posté(e) le 8 avril 2020 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
jjacques68 Posté(e) le 8 avril 2020 Auteur Signaler Posté(e) le 8 avril 2020 ok d’accord... merci c’est sympas !
Krikroff Posté(e) le 8 avril 2020 Signaler Posté(e) le 8 avril 2020 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...
jjacques68 Posté(e) le 9 avril 2020 Auteur Signaler Posté(e) le 9 avril 2020 mouai c’est ce que je craignais... bon ben ok... va pour cette solution... merci !!
jjacques68 Posté(e) le 9 avril 2020 Auteur Signaler Posté(e) le 9 avril 2020 (modifié) 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é le 9 avril 2020 par jjacques68
jjacques68 Posté(e) le 11 avril 2020 Auteur Signaler Posté(e) le 11 avril 2020 (modifié) 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é le 11 avril 2020 par jjacques68
Sowliny Posté(e) le 10 août 2021 Signaler Posté(e) le 10 août 2021 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 ?
Lazer Posté(e) le 10 août 2021 Signaler Posté(e) le 10 août 2021 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 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)
Sowliny Posté(e) le 10 août 2021 Signaler Posté(e) le 10 août 2021 (modifié) 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é le 10 août 2021 par Sowliny
Lazer Posté(e) le 10 août 2021 Signaler Posté(e) le 10 août 2021 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.
jjacques68 Posté(e) le 10 août 2021 Auteur Signaler Posté(e) le 10 août 2021 y aurait pas une histoire aussi de clearTimeout() ? pour annuler un setTtimeout() en cours...
Lazer Posté(e) le 10 août 2021 Signaler Posté(e) le 10 août 2021 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. 1
jjacques68 Posté(e) le 10 août 2021 Auteur Signaler Posté(e) le 10 août 2021 ah oui oui tout à fait !! désolé, avais mal lu la question initiale
Messages recommandés