Les “devicechanged” ne répondent pas

[DomoEsp32]

Matériel = RI 3B+ / SSD / RFXCom XXL + antenne
Utilisation du CPU = 19%
HDD Boot = 55%
Dispositifs / devices = 280
script_device = 10
script_time = 8
Le RI ⇒ free
total used free shared buff/cache available
Mem: 945368 183464 439544 15396 322360 692468
Swap: 102396 0 102396

Bonjour,
j'ai tellement cherché d'où venait le problème.... Je n'en peux plus.
Ce message est long car j'ai fait beaucoup de tests et j'essaye de donner le maximum de précisions.
J'ai besoin d'aide s'il-vous-plaît, et de pistes.
==⇒ La plupart des “devicechanged” ne répondent pas ou rarement (au début, il y a 4 ans, pas de problème).
J'ai installé un SSD il y a quelques semaines. Cela a améliorer les choses mais le problème persiste.
Les amélioration ont été : moins de “ ..popo.lua has been running for more than 10 seconds”.
J'ai un script-device très long => 700 lignes, il est optimisé et fait appel surtout à des “os.execute( 'curl '”.... vers des ESP
et une ligne json = (loadfile "/home/pi/domoticz/scripts/lua/JSON.lua")();
J'ai beaucoup de mess MQTT provenant d'une passerelle OpenDTU, j'ai arrêté le “MQTT Discover” pour ces tests.
Pour le test qui suit :
Le device “Boutton-Rond-Blanc-Velux-Bureau” est un bouton “ON/OFF”, pour mes tests avec des délais d'allumage et d"exctinction à 0.
Si je change ces délais => pas de changement.
Mes tests =>
1- changement de SD par SSD => mieux mais non.
2- Arrêt des MQTT => non.
3- Arrêt de mon script_device gourmand => non, car j'ai souvent “ ..popo.lua has been running for more than 10 seconds”


Exemples de mon test : ==> Nom du script = “script _device_Test.lua”

commandArray = {}
if (devicechanged["Boutton-Rond-Blanc-Velux-Bureau"] == 'On') then
print(' ICI ICI');
print('══════ script _device_Test ********** LastUpdate '..otherdevices_lastupdate["Boutton-Rond-Blanc-Velux-Bureau"]);
end;
return commandArray

Cas n° 1 : Dans le log qui suit , en ligne 06, on voit que l'appui sur le “Boutton-Rond-Blanc-Velux-Bureau” est détecté par le RFXCom,
mais le code ne rentre pas dans la condition, je n'ai pas “ICI ICI” dans le log. C'est très souvent le cas alors que le système n'est pas trop chargé.
Ce cas est très fréquent.

01- 2023-12-10 11:07:53.097 Mon RFX: Current/Energy (Owl_Terr_Clim)
02- 2023-12-10 11:07:54.729 Mon RFX: Current/Energy (Owl_Garage)
03- 2023-12-10 11:07:57.750 Mon RFX: Temp + Humidity (Out Rubicson/IW008T/TX95)
04- 2023-12-10 11:07:58.524 Mon RFX: Current/Energy (Owl_Toit_456)
05- 2023-12-10 11:07:58.762 Status: EventSystem: Script event triggered: script_device_owl
06- 2023-12-10 11:08:00.504 Mon RFX: Lighting 4 (Boutton-Rond-Blanc-Velux-Bureau) <==============
07- 2023-12-10 11:08:01.527 Mon RFX: Energy (owl-5-CM160)
08- 2023-12-10 11:08:02.650 Mon RFX: Energy (OWL-12-3264 FU6 C.Sol)
09- 2023-12-10 11:08:04.313 Mon RFX: Temp + Humidity (Chambre WS1700)
10- 2023-12-10 11:08:05.080 Mon RFX: Temp + Humidity (Chambre WS1700)
11- 2023-12-10 11:08:05.232 Status: EventSystem: Script event triggered: script_device_owl
12- 2023-12-10 11:08:08.529 MotherBoard: General/Percentage (RI-Memory-Usage)
13- 2023-12-10 11:08:08.535 MotherBoard: General/Custom Sensor (Process Usage)
14- 2023-12-10 11:08:09.730 Mon RFX: Current/Energy (owl-1)
15- 2023-12-10 11:08:11.300 Status: EventSystem: Script event triggered: script_device_owl
16- 2023-12-10 11:08:11.375 Status: EventSystem: Script event triggered: script_time_dahua_ecran

Cas n° 2 : Dans le log qui suit, un autre appui sur le bouton => cela fonctionne, mais rarement.

2023-12-10 11:13:40.443 Mon RFX: Current/Energy (Owl_06_2023_Clim)
2023-12-10 11:13:40.623 Status: EventSystem: Script event triggered: script_device_owl
2023-12-10 11:13:44.505 Status: EventSystem: Script event triggered: script_device_owl
2023-12-10 11:13:45.844 Mon RFX: Lighting 4 (Boutton-Rond-Blanc-Velux-Bureau) <====================
2023-12-10 11:13:45.989 Status: LUA: ICI ICI
2023-12-10 11:13:45.989 Status: LUA: ══════════════════════════════════ Script _device_Test ********** LastUpdate 2023-12-10 11:10:58
2023-12-10 11:13:46.512 Mon RFX: Current/Energy (Owl_Toit_456)
2023-12-10 11:13:49.176 Mon RFX: Current/Energy (Owl_Pignon)
2023-12-10 11:13:49.630 MotherBoard: General/Percentage (RI-CPU-Usage)
2023-12-10 11:13:49.646 MotherBoard: General/Custom Sensor (Arm Clock Speed)
2023-12-10 11:13:49.669 MotherBoard: General/Custom Sensor (V3D Clock Speed)
2023-12-10 11:13:49.681 MotherBoard: General/Custom Sensor[/size]

Cas n° 3 : Dans le log qui suit, un autre appui sur le bouton => cela fonctionne, mais le “LastUpdate 2023-12-10 11:30:06” donne “11:30” ?.!.? Il y a donc un retard, parfois il est de 1 heure !

2023-12-10 11:31:58.740 Status: EventSystem: Script event triggered: script_device_owl
2023-12-10 11:32:01.524 Mon RFX: Energy (owl-5-CM160)
2023-12-10 11:32:02.149 Mon RFX: Lighting 4 (Boutton-Rond-Blanc-Velux-Bureau) <==================== 11:32
2023-12-10 11:32:02.660 Mon RFX: Energy (OWL-12-3264 FU6 C.Sol)
2023-12-10 11:32:04.611 Mon RFX: Current/Energy (OWL-B2)
2023-12-10 11:32:05.303 Status: EventSystem: Script event triggered: script_device_owl
2023-12-10 11:32:06.533 Mon RFX: Temp (Terrasse Abri LaCrosse TX3)
2023-12-10 11:32:08.115 Status: EventSystem: Script event triggered: script_time_dahua_ecran
2023-12-10 11:32:09.477 Mon RFX: Current/Energy (Owl_Toit_123)
2023-12-10 11:32:09.754 Mon RFX: Current/Energy (owl-1)
2023-12-10 11:32:11.275 Status: LUA: ICI ICI
2023-12-10 11:32:11.275 Status: LUA: ══════════════════════════════════ Script _device_Test ********** LastUpdate 2023-12-10 11:30:06
2023-12-10 11:32:13.638 Mon RFX: Energy (owl-Juin-2023)
2023-12-10 11:32:13.719 MotherBoard: General/Percentage (RI-Memory-Usage)
2023-12-10 11:32:13.727 MotherBoard: General/Custom Sensor 


Mes pauvres pistes :
1- je change de système ! lequel? (petite blague car je n'en peux plus )
2- faire des scripts Shell ? je ne sais pas vraiment de quoi je parle...
3- pour mes commandes CURL :  les réécrire-les pour utiliser openURL() ou envoyez-les en arrière-plan en ajoutant « & » à la commande.
Actuellement je les écris comme cela : os.execute( 'curl '..ESP_IP_39..'tft,rf,20,1,420,112,black,black'); (c'est un affichage sur un écran via un esp8266 (wifi) )
4- fichier log de domoticz trop gros? =>
5- Quand je “redémarrer le système”, domoticz répond mieux pendant quelques minutes => le relancer tous les jours avec un script, ou toutes les 6 heures par exemple?
6- Quand je ne relance pas le système pendant plusieurs jours => cela empire, la plupart des devicechanged ne répondent plus ou avec quelques minutes de retard, voire, 1 heure de retard.
7- un script_time trop gourmand en temps “EventSystem: Warning!, lua script Script_time_ESP has been running for more than 10 seconds” ?
8- Passé en DzEvent => cela ne devrait rien changé, car si j'aibien compris , c'est du LUA sois disant simplifié pour l'écriture.
9- Le RI ne semble pas en cause, car quand je relance Domoticz, c'est mieux.
10- Des variables “local” dans les scripts ? Pour moi, toutes les variables sont “locales” au script, donc à quoi sert ce local?


Quelles pistes pourraient-je explorer?

Merci pour votre aide.

[Keros]

Je viens de déplacer ton sujet dans la section dédiée aux scripts.

Tu as d'autres choses installées sur ton Pi autre que DomoticZ et MQTT ?

Tu es sur quelle version d'os ? Buster, Bullseye, BookWorm ?
Quel type d'OS ? light, desktop, with recommanded software ?

Quelle taille fait ta base de données de DomoticZ ?

Tu as installé quel SSD ?

En installant NetData, tu peux nous dire si les IOS sont fables ?
Quel est l'utilisation de ta ram ?

Je vois que tu as pas mal d'info dans les logs : est-ce que tu as réduits les logs au niveau de chaque plugin pour ne plus avoir les "Info" ?

[Flying Domotic]

Si tu utilises beaucoup de "curl", il est surement préférable de réécrire le script de LUA "pur" en dzVent,

L'avantage est que les requêtes http et OS passeront en asynchrones, ce qui va supprimer les blocages des scripts.

Tu gagneras probablement en temps de réponse, puisque tu pourras lancer toutes les requêtes en parallèle, si besoin.

L'idée est de commencer par celles qui sont bloquées pendant plus de 10 secondes.

[DomoEsp32]

Avant tout, merci pour ces réponses.
1- Rien d'autres n'est installé sur le PI.
2- Version OS :
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux"
VERSION_ID="10" VERSION="10 (buster)"
VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian
3- Version Desktop
4- Taille de la base => 28 Mo
5- SSD => c'est un LEXAR de 128 Go, avec le HD c'était pire.... certes.... mais LEXAR cela marche bien il me semble?
6- Utilisation de la RAM
total 923 Mi used 178 Mi free 321 Mi shared 20 Mi buff/cache 431 Mi available 660 Mi
Swap: Total 99 M i used 0 B free 99 Mi
Total total 1 Go used 187 Mi free 421 Mi
7- Réduction des infos dans les plugins :
a) Visual crossing => fait (log level info en rouge)
2023-12-13 23:55:03.413 Status: Visual-Crossing: Worker stopped...
2023-12-13 23:55:03.423 Status: Visual-Crossing: Started...
b) MQTT Discover => fait , pas eu de message (log level info en rouge)
c) Mel Cloud => c'était déjà fait (log level info en rouge)
# Author: Gysmo, 2017 Updated by nonolk 2022 # Version: 0.8.0
d) deCONZ => fait , (log level info en rouge)
2023-12-13 23:58:44.732 Status: deCONZ: Initialized version 1.0.22, author 'Smanar'
2023-12-13 23:58:52.762 Status: EventSystem: Script event triggered: script_device_owl
2023-12-13 23:58:53.080 Status: deCONZ: Firmware version: 0x26720700
2023-12-13 23:58:53.080 Status: deCONZ: Websocketnotifyall: True
2023-12-13 23:58:53.080 Status: deCONZ: You have 17 API keys memorised, some of them are probably useless, can use the API_KEY.py tool or the Front end to clean them
2023-12-13 23:58:53.129 Status: deCONZ: ### deCONZ ready
2023-12-13 23:58:53.129 Status: deCONZ: ### Found 0 Operators, 2 Sensors, 0 Groups, 0 Scenes and 0 others, with 0 Ignored
2023-12-13 23:58:53.180 Status: deCONZ: Launching WebSocket on port 8088
2023-12-13 23:58:57.139 Status: EventSystem: Script event triggered: script_device_owl
2023-12-13 23:59:00.134 Status: EventSystem: Script event triggered: script_time_dahua_ecran
e) YeeLight => fait (log level info en rouge), pas de mess dans les log
f) MQTT => fait (log level info en rouge),
2023-12-14 00:02:47.459 Status: MQTT: Worker stopped...
2023-12-14 00:02:48.461 Status: MQTT: Connecting to localhost:1883
2023-12-14 00:02:48.663 Status: MQTT: connected to: localhost:1883
g) MotherBoard => fait (log level info en rouge)
2023-12-14 00:04:41.036 Status: MotherBoard: Hardware Monitor: Stopped...
2023-12-14 00:04:41.058 Status: MotherBoard: System: Raspberry Pi
2023-12-14 00:04:41.084 Status: MotherBoard: Hardware Monitor: Started (OStype Raspberry Pi Linux)
J'ai l'impression que les réponses sont plus rapides
h) RFXCom => je laisse les log ! car sinon je ne vois plus rien ?
i) Les autres sont des DUMMY ⇒ il y en a 9 , je les laisse ! ou ?

Remarques et questions :
• Après la désactivation des logs ci-dessus, j'ai l'impression que cela répond plus vite.
• "Si tu utilises beaucoup de "curl", il est surement préférable de réécrire le script de LUA "pur" en dzVent,"
Il y a quelques heures , j'ai remplacé mon gros script de 700 lignes , qui contient beaucoup de CURL,
en ajoutant le paramètre ' &' à la fin ( il me semble que c'est pour lancement en arrière plan),
mais je n'ai pas constaté de réels changements.
exemple d'une fonction avec ce changement :
ESP_IP_39 = "http://192.168.1.39/control?cmd="

local function TFT_Text1(xx,yy,TextSTR2,color)
StrTempST77xx = 'curl '..ESP_IP_39..'tft,txz,'..tostring(xx)..','..tostring(yy)..','..url_encode(TextSTR2);
os.execute('curl '..ESP_IP_39..'tft,txc,'..color..' &');
os.execute(StrTempST77xx);
return
end;

---- dzEvent ------------------
Ré-écrire en dzEvent => Holala, j'ai pas fini !!!!!! cela risque d'être très long, non?
“L'idée est de commencer par celles qui sont bloquées pendant plus de 10 secondes.”
Pendant que je suis en train de faire les tests : je n'ai pas mes blocages de plus de 10 secondes.
Ces blocages : environ en moyenne 10 par jour, surtout en été à cause de mes devicechanged sur mes capteurs OWL ( une 15aine).
Ces capteurs OWL surveillent le changement de tension de 15 couples de panneaux solaires.

Autre info à propos de mon gros script de surveillance des panneaux solaires :
L'entrée dans le corps principal se fait comme suit , un test sur 5 capteurs.
if (devicechanged[Nom_Owl_Pignon]) or (devicechanged[Nom_Owl_PM]) or (devicechanged[Nom_Owl_Toit_123]) or (devicechanged[Nom_Owl_Toit_456]) or (devicechanged[Nom_Owl_Terr_Clim]) then


--- netdata ----
Je vais l'installer, mais je n'ai pas compris cette remarque :
“En installant NetData, tu peux nous dire si les IOS sont fables ?”
IOs = entrées / Sorties , hardware ?

Voilà mes premières remarques... et j'attends les votres
Je continue à surveiller demain.
Merci pour toutes ces infos !

[Flying Domotic]

local function TFT_Text1(xx,yy,TextSTR2,color)
StrTempST77xx = 'curl '..ESP_IP_39..'tft,txz,'..tostring(xx)..','..tostring(yy)..','..url_encode(TextSTR2);
os.execute('curl '..ESP_IP_39..'tft,txc,'..color..' &');
os.execute(StrTempST77xx);
return
end;

Ce code lance bien en arrière plan la première commande os.execute, mais pas la seconde. Il faudrait modifier en

Code : Tout sélectionner

os.execute(StrTempST77xx..' &')

ou ajouter un

Code : Tout sélectionner

..' &'

à la fin de StrTempST77xx=...

Pour info, le `;` n'a d’intérêt que si on a 2 commandes sur la même ligne.

[Keros]

Merci DomoEsp32 pour ces précisions.

La taille de la base de donnée de DomoticZ me semble normale.
La réduction des logs devraient aidé un peu.
Tu as mis tes logs dans un fichier texte ? Si oui, peut-être le désactiver pour essayer.

Les IOS ne sont pas en les entrés/sorties, c'est une indication que le processeur est en attente d'écriture sur le stockage : s'il attend, les délais pour les autres commandes augmente.

Ton utilisation de ram me semble élever comme ça. Je comparai ce soir avec le mien.

Tes OWL se rafraichissent tous les combien de temps ? Avec une quinzaine, c'est peut être ça qui sollicite beaucoup ton DomoticZ. Tu ne peux pas basculer sur un script de type time pour faire des actions seulement toutes les minutes ?

[lost]

Tu n'aurais pas plutôt un pb de réseau local (et pb de connection) ou de délai de réponse du matériel?

Si c'est le cas, ton script va bloquer l'event system de Domoticz qui, fatalement, va louper des évènements...

Sauf à empiler une tétrachiée de curl qui répondraient vite, je ne vois pas trop le besoin de les lancer en tâche de fond sur un LAN qui fonctionne bien. A mon sens le pb de base est sans doute ailleurs et je retirerais les & pour résoudre le pb réseau de base probable.

Puis, pour la fiabilité (face à un machin en face qui déconne/réponds pas), caper les temps d’exécution de curl.

Pour plus de praticité pour les tests/modif de paramètres, s'en faire une fonction locale, genre (même si dans ton cas le résultat n'est pas utilisé, on va faire générique):

Code : Tout sélectionner

local function myCurl(cmd)
        local handle = assert(io.popen('curl --retry 1 --connect-timeout 1 -m 3 \"'..cmd..'\"'))
        result = handle:read('*all')
        handle:close()
        
        return result
end

Ici, le timeout de connexion est à 1s avec un seul retry. Donc on arrête les frais si pb de connection en 2s max. Si le pb n'est pas le connect, mais autre (temps de réponse du matos appelé, le plus probablement), la commande retournera quoi qu'il arrive après 3s max.

Explications option/commande (man = pages du manuel!):
man curl

Et remplacer un (exemple):
os.execute('curl '..ESP_IP_39..'tft,txc,'..color)

Par (attention la commande curl, et ses paramètres nouveaux, est déjà incluse):
myCurl(ESP_IP_39..'tft,txc,'..color)

Affiner les 3 paramètres au besoin (voir en ajouter, à la lumière de la page man de la commande si cela parait opportun),

Ajouter au besoin une mesure de temps d'execution fin-début dans la fonction ci dessus et afficher toute commande dépassant 2s pourrait permettre de mettre un nom sur ce qui traine trop, également...

[fcBourgogne]

Bonjour,

DomoEsp32, le 'TRIGGER de ton script lua est bien sur DEVICE ?

A+

[DomoEsp32]

Bonsoir,
merci pour vos pistes et idées.
Je mets longtemps pour répondre car les tests sont longs et il faut que les panneaux solaires soient en forme!

“Keros” :
• “ Tu as mis les logs dans un fichier texte ? ” => je ne comprends pas ta question ? sous Pi/var/log , je n'ai pas de fichier domoticz.log
• le rafraichissement des OWL se fait toutes les 1 minute, mais ma condition du devicechanged teste 5 OWL, donc en 1 minute j'ai au 5 entrées dans mon script
• oui je pourrais basculer en script de type Time, mais j'ai besoin pendant plusieurs mois de savoir précisement
le maximum de données temporelles sur tous les panneaux solaires (ombrages, temps de réaction etc.....)

“Lost” :
• “...pb de réseau local, de connection”....
⇒ à priori, non.

“fcBourgogne” :
• "..le TRIGGER de ton script lua est bien sur DEVICE ?
⇒ Oui, le mon script est “script_device_owl” dans l'éditeur de Domoticz et le trigger sur DEVICE.

• Suite à la remarque de “Lost” sur un éventuel problème de réseau :
⇒ Le gros script bloquant envoi via wifi des données vers 2 ESP (ESPEasy / 82266) via http (c'est du monitoring de puissance en Watts)
Ces 2 ESP sont au même endroit pour la reception wifi (-50dBm).
Un ESP avec un écran LCD2004 et un autre avec ecran LED TFT.
Les paramètrages des controllers dans ces 2 ESPesay sont les mêmes, mais pas les écrans , donc peut-être des temps de réponse très différents
J'ai donc enlevé tout ce qui concerné l'écran LCD == 17 requetes Curl
⇒ et là, encore un sensible amélioration, le système commence à être réactif !!

“Lost” : assert(io.popen('curl --retry 1 --connect-timeout 1 -m 3 \"'..cmd..'\"'))
• j'essaye de comprendre ces parametres, peut etre que cela serait très utile si l'ESp ne répond car il est hors ligne... ?

D'après la revue "Domoticz Home Automation Workbook" (800 pages quand même).
Effectivement les DzEvent permettent d'envoyer des Curl en asynchrone , mais on peut contourner les problème
en LUA sinon on ajoute ‘ &’ à la fin des commandes Curl.
Dans mon cas, c'est pas terrible, car je pilote des écrans, certaines commandes comme le changement de taille de police, ou de couleur ne parviennent pas dans l'ordre => j'ai n'importe quoi à l'écran.... dommage.

J'ai aussi comme le suggérer cette revue, concaténer mes Curl, c'est-à-dire :
au lieu d'avoir une dizaine, voire davantage, de commandes du genre :
os.execute('curl '..ESP_IP_39..'tft,cf,'..tostring(12+Seconde_Actuelle*8)..',309,8,white,red'..EtCom);
os.execute('curl '..ESP_IP_39..'tft,rf,192,203,288,95,red,black &');
os.execute('curl '..ESP_IP_39..'tft,txc,white');

Je prépare une string, et j'envoie une seule curl :
L01 ='tft,cf,'..tostring(12+Seconde_Actuelle*8)..',309,8,white,red'
L02 = 'tft,rf,192,203,288,95,red,black'
L03 ='tft,txc,white'
os.execute('curl --retry 0 --connect-timeout 1 -m 2 '..
HTCMD..L01..
HTCMD..L02..
HTCMD..L03);
Avec cette méthode, à priori, je libère de la bande passante!

J'ai mesuré le temps dans une 10aine de points stratégique du script comme ceci :
print('script_device_owl=====V1= 31 => '..os.time()-SStart);
où SStart = os.time() est initialisé juste après :
if (devicechanged[Nom_Owl_Pignon]) or (devicechanged[Nom_Owl_PM]) or (devicechanged[Nom_Owl_Toit_123]) or ....etc

Bilan - Résumé :
• 1- tous les logs infos à = OFF (même RFXCom) => Gain de temps très conséquent!
j'ai à chaque fois laissé les "Log level" état = ON et Erreur=ON
• 2- pas d'ajouts de ‘ &’ dans les Curl
• 3- Concaténation = regroupement de plusieurs Curl en une seule commande Curl => gain conséquent
Je n'ai plus de "timeout > 10s", au maximum mon script dure 4 secondes.

Remarque “étrange” : ce script est un “device”.
Si je mets cette commande :
print(" *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*");
avant la condition :
if (devicechanged[Nom_Owl_Pignon]) or (devicechanged[Nom_Owl_PM]) or (devicechanged[Nom_Owl_Toit_123]) or ....etc

8.509 Status: EventSystem: Script event triggered: script_device_dahua_ecran
2023-12-29 00:07:17.518 Status: EventSystem: reset all events...
2023-12-29 00:07:18.613 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
2023-12-29 00:07:19.472 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
2023-12-29 00:07:19.553 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
un vingtaine de fois
2023-12-29 00:07:38.448 Status: LUA: script_device_owl=========================================================== 1 => 0
2023-12-29 00:07:38.509 Status: LUA: script_device_owl=========================================================== 2 => 0
2023-12-29 00:07:38.509 Status: LUA: script_device_owl========

Le print est executé une 20aine de fois, ou, tout le temps. Cela voudrait dire que toutes les déclarations de fonctions et initilisations de variables en tête de scipt sont executées toutes les secondes voire davantage? par exemple
Heure_Actuelle = os.date("%H") * 60 + os.date("%M");
Nom_UV_PID_ProductionTotaleInst = 'UV_PID_ProductionTotaleInst';
Nom_UV_Prod_Journaliere = 'UV_Prod_Journaliere'; -- Variable Utilisateur
HeureLeverSoleil = timeofday['SunriseInMinutes'];--30 ---- on enlève 30 min
HeureCoucherSoleil = timeofday['SunsetInMinutes'];--+30 ---- on ajoute 30 min

Autre remarque : j'ai l'impression de faire un bon dans les années 90, où, nous étions obligés d'optimiser nos programmes car nos processeurs et surtout nos périphériques (HDD) étaient très lents.
On dispose quand même d'un RI qui tourne très vite, un SSD, et sous linux.
Linux est en principe un OS temps réel, je ne comprends pas qu'un script dans domoticz bloque tout tant qu'il n'est pas terminé.
On est censé utilisé un OS multithread, mais qui à priori ne gère pas les sémaphores, non ?

Mon message est long, j'espère que vous aurez du coup d'autres pistes à explorer..
Merci pour vos aides.
Bonne soirée

[Flying Domotic]

Remarque “étrange” : ce script est un “device”.
Si je mets cette commande :
print(" *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*");
avant la condition :
if (devicechanged[Nom_Owl_Pignon]) or (devicechanged[Nom_Owl_PM]) or (devicechanged[Nom_Owl_Toit_123]) or ....etc

8.509 Status: EventSystem: Script event triggered: script_device_dahua_ecran
2023-12-29 00:07:17.518 Status: EventSystem: reset all events...
2023-12-29 00:07:18.613 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
2023-12-29 00:07:19.472 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
2023-12-29 00:07:19.553 Status: LUA: *-*-*-*-*-*-*-*-*-*-*-*-* le 28/12/2023 *-*-*-*-*-*-*-*
un vingtaine de fois
2023-12-29 00:07:38.448 Status: LUA: script_device_owl=========================================================== 1 => 0
2023-12-29 00:07:38.509 Status: LUA: script_device_owl=========================================================== 2 => 0
2023-12-29 00:07:38.509 Status: LUA: script_device_owl========

Le print est executé une 20aine de fois, ou, tout le temps. Cela voudrait dire que toutes les déclarations de fonctions et initilisations de variables en tête de scipt sont executées toutes les secondes voire davantage?

Effectivement, les scripts d'un type (ici device) sont tous lancés à chaque déclenchement (ici, chaque device change sur l'ensemble des devices). Il est donc assez efficace d'avoir un format du genre :

Code : Tout sélectionner

commandArray = {}

for deviceName,deviceValue in pairs(devicechanged) do
    if deviceName == 'xxx' then
    	-- Inclure ici les initialisations --
    end
end

return commandArray

Si on souhaite quand même intégrer des variables pour les noms des devices à tester, on peut/doit le faire avant le if, mais bien penser que chaque script (d'un type) est exécuté à chaque changement de chaque device, donc plus c'est court et peu consommateur, meilleur c'est ... donc service minimum en dehors du "if" de sélection.

Noter que la remarque est aussi valable pour les scripts dzVents (mais là, c'est le "on" qu'il faut optimiser).

Pour ceux qui penseraient que c'est un peu bête de faire comme ça, il faut réfléchir à comment on pourrait faire un système d'association entre un script et ses déclencheurs (ici nom du device modifié), souple et paramétrable. Il y a un début de réponse avec dzVents, mais il faut quand même lancer chaque script pour récupérer les devices à tester.

Le corolaire de ça, c'est qu'on est vraiment flexible sur les déclencheurs, et qu'on peut même écrire des choses qui testent les caractères d'un nom de device, récupèrent des choses dans des variables externes, on des listes à géométrie variables, ...