Forum Domoticz en français

Bonjour
Suite à l'utilisation du planning semaine ou weekend dans le planning, ma fonctionnalité de désactiver un timer dans un planning ne fonctionne plus, car l'idx du switch n'est pas le même dans les 2 plannings

Mon idée est de le récupérer sur le nom de la device et After sunset afin de forcer cette désactivation
Je voudrais utiliser le OpenUrl en mode synchrone en Dzvents

• local URLGetPlanning = 'http://127.0.0.1:8080/json.htm?type=sch ... ter=device'
  RetourPlanning=domoticz.openURL(URLGetPlanning)
  local TabPlanningsJson = RetourPlanning.json.result l'erreur est ici il ne récupère rien
  for i, planning in pairs (TabPlanningsJson) do
  local deviceName = planning.DevName
  local deviceIdx = planning.TimerID
  -- Vérifie si le nom du dispositif correspond au filtre
  if filterDevices[deviceName] and filterDevices[planning.TimerTypeStr]=="After Sunset" then
  -- desactivation timer du volet
  URLPlanningOff = URLPlanningOff .. deviceIdx
  domoticz.openURL({ url = URLPlanningOff, method = 'GET' })
  end

mais lorsque je récupère la données, j'ai cette erreur
2020-12-03 13:58:23.279 Error: dzVents: Error: (3.0.2) AUTO-CLOSE-CUISINE v1.0: An error occurred when calling event handler d_auto_close_cuisine
2020-12-03 13:58:23.279 Error: dzVents: Error: (3.0.2) AUTO-CLOSE-CUISINE v1.0: ...omoticz/scripts/dzVents/scripts/d_auto_close_cuisine.lua:67: attempt to index a nil value (field 'json')

Qu'en pensez vous ?
Est ce la bonne méthode?

openURL(url/options): Function. Have Domoticz ‘call’ a URL. If you just pass a url then Domoticz will execute the url after your script has finished but you will not get notified. If you pass a table with options then you have to possibility to receive the results of the request in a dzVents script.
Source https://www.domoticz.com/wiki/DzVents:_ ... nd_methods
Tu es obligé de passer par le mode asynchrone pour récupérer le résultat.

Voilà l'exemple plutot simple fournit dans la doc

parfait j'ai respecté la structure ca marche bien, j'arrive a desactiver le timer du sunset du volet si la fenetre est ouverte
Utile pour
securité terrasse
et fenetre italienne ouverte

cerise sur le gâteau si je ferme le volet et si c'est sunset alors close volet

comment faite vous pour gérer une erreur sur le isHTTPResponse et que le timer du script est à heure fixe par exemple

idéalement il faudrait rejouer le script, avez vous implémentez ce type de traitement ou recyclage?

Du tout.
Si j'ai une erreur en réponse, le script s'arrête.
Après tout dépend du comportement voulu.
Pour interroger un capteur, une erreur sporadique n'est pas grave.
Pour un actionneur, il faut le gérer pour relancer la commande plus tard.
Et je viens de découvrir la MAJ de DzVents en 3.1.0 :
Added shell command event triggers to be used in combination with executeShellCommand. You can now execute shell commands and handle the response in your dzVents scripts ASYNCHRONICALLY. See the documentation. No more json parsing needed or complex popen() or ‘system()’ shizzle.
J'ai quelques scripts à optimiser

je reviens sur la gestion de ce isHTTPResponse lorsque celui-ci me renvoie une erreur et que le script tourne un fois par jour comme ce script aujourd'hui
2021-04-16 19:00:10.734 Error: dzVents: Error: (3.0.2) METEO GIVRE v1.1: HTTP/1.1 response: 7 ==>> Couldn't connect to server

idéalement il faudrait redéclencher un nouvelle exécution, comment avez vous gérez cela ?

faut il alimenter une variable d'erreur par script dans le cas de script non cyclique et faire un dzvent qui check et relance les cripts en erreur mais comment exécuter celui-ci sans tenir compte du timer ?

Je vois l'idée. J'ai également le même soucis, même si les appels Json ne retournent pas beaucoup d'erreur.

Dans les triggers, je mettrais every 15 minutes. Je mettrais une condition sur le timer pour vérifier qu'il est 19h00 (par exemple) ou si une deuxième condition "historique" != 0 (historique serait une persistent data).

Si tout ce passe bien, à 19h, le script s'exécute, l'appel Json est fait, l'httpResponses est ok et le script se fini normalement.
Cependant, si le httpResponses n'est pas bon, on passe la variable persistante historique à une valeur + 1.
15 minutes plus tard, le script se relance et comme historique n'est pas à 0, cela retente l'appel. Si l'httpResponses est ok : il faut remettre historique à 0 (ce qui peut être fait à chaque fonctionnement sans erreur). 15 minutes plus tard, puisque le script s'est fini et que historique est à 0, il n'y a pas de raison que l'appel soit refait. Par contre, s'il y a encore une erreur, historique passe à 2, etc.
En incrémentant historique, tu peux fixer une limite, où il est temps d'arrêter d'essayer et de t'envoyer une petite notification car il y a un problème

Je ne l'ai pas testé.

plutot bien comme solution , avec un
data = {
flag= { history = true, maxItems = 1 },
}

if (item.isHTTPResponse) then
if (item.ok) then
si dz.data.flag.getOldest().data == 0 then
dz.data.flag.add('1')
end

else
dz.data.flag.add('2')
end
en plus le data persistent etant en RAM pour ma part,cette solution est plutot bien
je vais tester ca, merci

Essaye de mettre ton script avec les balises Code (le bouton </>) : c'est plus facile pour la lecture.

Le truc qui ne me plait pas complètement c'est qu'au départ on pourrait spécifier deux timer "at 19:00" et "every 15 minutes" pour pouvoir gérer le déclenchement, mais je ne sais pas comment retrouver quel trigger est à l'origine de l'exécution.

Deux triggers de type différents, ok c'est bon, deux devices différents, c'est bon aussi. Mais deux timers différents, je n'ai pas vu

On peut utiliser item.trigger pour avoir la règle de timer ou réponse http qui a déclenché le script (où item est le deuxième paramètre de la fonction execute)