Script LUA executé plusieurs fois

[lmet]

Bonjour,
Une erreur ?
Sinon le tostring() est par sécurité : Permet de concaténer une valeur 'nil' dans un print

[vil1driver]

Merci pour l'info

Oui ceci

Code : Tout sélectionner

tostring(humidite_cine_capteur)

J'aurais mis juste

Code : Tout sélectionner

tostring(humidite)

Pour coller à

Code : Tout sélectionner

humidite=(otherdevices_humidity['humidite_cine_capteur'])

Ou alors plutôt ceci (au sens de ce que tu semble vouloir)

Code : Tout sélectionner

tostring(devicechanged['humidite_cine_capteur'])

[frtoto]

J'ai mis les 2 bouts de codes

Code : Tout sélectionner

print(devicechanged['humidite_cine_capteur']) 

et

Code : Tout sélectionner

if (devicechanged['humidite_cine_capteur']) then 
   local x = os.clock()
   print ("Valeur humidité : " .. tostring(devicechanged['humidite_cine_capteur']) .. " heure : " .. tostring(x))
end

et mon print est entre les 2

Code : Tout sélectionner

2018-09-08 15:05:40.124 Status: LUA: 65
2018-09-08 15:05:40.124 Status: LUA: humi = 65
2018-09-08 15:05:40.124 Status: LUA: Valeur humidité : 65 heure : 763.401471
2018-09-08 15:05:40.124 Status: LUA: vitesse 1
2018-09-08 15:05:40.125 Status: EventSystem: Script event triggered: vmc_cine_4
2018-09-08 15:05:40.160 Status: LUA: 65
2018-09-08 15:05:40.160 Status: LUA: humi = 65
2018-09-08 15:05:40.160 Status: LUA: Valeur humidité : 65 heure : 763.437952
2018-09-08 15:05:40.160 Status: LUA: vitesse 1
2018-09-08 15:05:40.161 Status: EventSystem: Script event triggered: vmc_cine_4

[vil1driver]

Je penche pour un double envoi de la part du capteur
Donc soit tu laisses en l'état soit tu oublies le type Device au profit d'un type Time qui ne se déclanchera plus à chaque envoi de mesure mais toutes les minutes (sans doublon).
A mon sens bien suffisant, le type Device etant le mode utile en cas de besoin de réactivité. Est ce vraiment important ici ?

[frtoto]

Non ce n'est pas important, par contre au niveau fréquence ce sera même plus souvent car actuellement le script se déclenche toutes les heures;
Je tente...

merci en tout cas

[frtoto]

Donc effectivement le script ne s’exécute qu'une fois par contre toutes les minutes au lieu de toutes les heures.
Vu que c'est pour la salle de cinéma, je pense que je vais repasser à 'DEVICE' et tant pis si le capteur envoie 2 fois de suite

[vil1driver]

En Time on peut ajouter une condition pour que ce ne soit que toutes les heures.
Je n'ai pas ça en tête à l'heure actuelle mais de très nombreux scripts sur ce forum utilisent cela..
Tu trouveras certainement.

Mais c'est vrai que l'on risque de rater le moment de la maj du capteur donc effectivement Device est probablement le mieux dans ton cas

[lost]

En Time on peut ajouter une condition pour que ce ne soit que toutes les heures.
Je n'ai pas ça en tête à l'heure actuelle mais de très nombreux scripts sur ce forum utilisent cela..
Tu trouveras certainement.

Mais c'est vrai que l'on risque de rater le moment de la maj du capteur donc effectivement Device est probablement le mieux dans ton cas

Je pense qu'il est possible de cumuler le meilleur des deux mondes en utilisant le last update du capteur comparé a l'heure actuelle de déclenchement du script device sur ce même capteur (après le classique test sur le device changed).

Si on la dernière mesure qui date de moins d'une seconde, le script peut retourner direct sans faire de traitement car il s'agit d'un doublon non voulu. Et on conserverait alors le moment de MAJ+ne pas de voir pooler le capteur (ce qui ne fonctionnera d'ailleurs pas forcément avec un module à piles, qui coupe son interface radio z-wave entre 2 envoi de mesures, si changement, et ne recevra donc pas les demandes du contrôleur. Ceci afin d'économiser la pile).

J'avais fait un truc dans ce genre pour relancer un ordre relais pour mon smart-meter Qubino dans mon tableau electrique: Ce module, sur la partie commande du relais filaire externe, a en effet la fâcheuse tendance à voir la couche open-zwave relancer un ordre inversé dans la seconde suivant une consigne: Tu veux "on"... l'ordre passe... puis un "off" est souvent relancé et ce sans action de ma part! Un nouvel "on" immédiat donnant alors un état stable.

D'ailleurs, en commandant le switch à la main, le problème et ce hack qui "fait tomber en marche" étaient aisément perceptibles.

Je n'avais fait qu’automatiquement cela dans un scrip device qui s'il voyait passer un ordre, puis son contre-ordre dans la seconde, évitait le désordre en relançant l'ordre initial!

Pas chez moi actuellement, je pourrais compléter par "mon" bout de code au besoin... en partie tiré du wiki, de mémoire... si le posteur d'origine ne s'en sort pas.

Pour info même si c'est un peu hors sujet, après un ticket Qubino->OZW, il était apparu que ce module était plutôt long (jusqu'a 7s! un bug firmware amha) à renvoyer son retour d'état après une commande, ce qui provoquait ce comportement d'open z-wave (mais pourquoi l'ordre inverse??)... Qubino avait reshooté le truc à OZW, sans solution a priori (ceci dit, si c'est bien le FW du module qui est en cause, c'était pas forcément à eux d'y pallier):
https://github.com/OpenZWave/open-zwave/issues/1261

Donc des modules buggués peuvent donner ce type de bégaiements.

[lost]

Je pense qu'il est possible de cumuler le meilleur des deux mondes en utilisant le last update du capteur comparé a l'heure actuelle de déclenchement du script device sur ce même capteur (après le classique test sur le device changed).

Si on la dernière mesure qui date de moins d'une seconde, le script peut retourner direct sans faire de traitement car il s'agit d'un doublon non voulu....

Ci dessous, mon exemple d'implémentation faisant tomber en marche la commande relais smart meter qubino. On peut filtrer des actions résultant de doublons sur le même principe.

Ceci suppose la création séparée d'une variable utilisateur (ici nommée timeSmartMeterRelay) pour garder d'un appel au script 'device' à l'autre l'heure du dernier déclenchement.

Code : Tout sélectionner

spuriousCmdDelaySec=1
timeDuplicateCmdSec='5'
SmartMeterSwitch='Relais Smart-Meter HP/HC Actif'
timeLastCmd='timeSmartMeterRelay'

commandArray = {}

if (devicechanged[SmartMeterSwitch]) then
    devState = devicechanged[SmartMeterSwitch]
    
    t1 = os.time()
    t0 = uservariables[timeLastCmd]
    
    -- 1st time init for user variable...
    if (t0 == 'nil') then
        t0 = t1
    end
    
    tDiff = os.difftime(t1, t0)
    
    -- Debug :
    --print(SmartMeterSwitch..' = '..devState)
    --print('t1 : '..t1..' / t0 : '..t0.. ' ; Diff = '..tDiff)
    
    -- Do we have the immediate change state spurious (buggy device?) invalidating current command ?
    if (tDiff <= spuriousCmdDelaySec) then
        if (devState == 'On') then
            commandArray[SmartMeterSwitch] = 'Off AFTER '..timeDuplicateCmdSec
        end

        if (devState == 'Off') then
            commandArray[SmartMeterSwitch] = 'On AFTER '..timeDuplicateCmdSec
        end
    end
    commandArray['Variable:'..timeLastCmd] = tostring(t1)
end

return commandArray