Plantage Jeedom systématique sur lancement d'un scénario

[ThierryJ]

Bonjour,
J’ai un plantage Jeedom systématique suite au lancement du scénario fermeture des volets le soir ou à l’ouverture le matin
Je suis sur une box Atlas, pourriez vous m’aider et orienter mes recherches ?
En vous remerciant,

0000|2026-01-23 18:29:58 30 variation(s) on previous 20 message(s) suppressed by --mute
0001|2026-01-23 18:30:01 [server] Inactivity timeout (--ping-restart), restarting
0002|2026-01-23 18:33:15 SIGUSR1[soft,ping-restart] received, process restarting
0003|2026-01-23 18:33:29 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
0004|2026-01-23 18:34:04 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
0005|2026-01-23 18:36:03 TCP/UDP: Preserving recently used remote address: [AF_INET]57.128.63.222:1196
0006|2026-01-23 18:36:06 UDP link local: (not bound)
0007|2026-01-23 18:36:08 UDP link remote: [AF_INET]57.128.63.222:1196
0008|2026-01-23 18:37:31 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
0009|2026-01-23 18:37:32 TLS Error: TLS handshake failed
0010|2026-01-23 18:38:53 SIGUSR1[soft,tls-error] received, process restarting
0011|2026-01-23 18:39:01 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
0012|2026-01-23 18:39:28 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
0013|2026-01-23 18:42:30 TCP/UDP: Preserving recently used remote address: [AF_INET]51.159.177.9:1196
0014|2026-01-23 18:43:02 UDP link local: (not bound)
0015|2026-01-23 18:43:25 UDP link remote: [AF_INET]51.159.177.9:1196
0016|2026-01-23 18:44:44 [UNDEF] Inactivity timeout (--ping-restart), restarting
0017|2026-01-23 18:46:17 SIGUSR1[soft,ping-restart] received, process restarting
0018|2026-01-23 18:46:48 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
0019|2026-01-23 18:47:17 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
0020|2026-01-23 18:55:05 TCP/UDP: Preserving recently used remote address: [AF_INET]51.159.170.131:1196
0021|2026-01-23 18:55:05 UDP link local: (not bound)
0022|2026-01-23 18:55:05 UDP link remote: [AF_INET]51.159.170.131:1196
0023|2026-01-23 18:55:05 VERIFY OK: depth=1, C=FR, ST=IDF, L=Paris, O=jeedom.com, OU=jeedom.com, CN=jeedom.com CA, name=jeedom, emailAddress=postmaster@jeedom.com
0024|2026-01-23 18:55:05 VERIFY OK: depth=0, C=FR, ST=IDF, L=Paris, O=jeedom.com, OU=jeedom.com, CN=server, name=jeedom, emailAddress=postmaster@jeedom.com
0025|2026-01-23 18:55:06 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 1024 bit RSA
0026|2026-01-23 18:55:06 [server] Peer Connection Initiated with [AF_INET]51.159.170.131:1196
0027|2026-01-23 18:55:06 Data Channel: using negotiated cipher 'AES-256-GCM'
0028|2026-01-23 18:55:06 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
0029|2026-01-23 18:55:06 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
0030|2026-01-23 18:55:06 Preserving previous TUN/TAP instance: tun0
0031|2026-01-23 18:55:06 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
0032|2026-01-23 18:55:06 Closing TUN/TAP interface
0033|2026-01-23 18:55:06 net_addr_ptp_v4_del: 10.11.42.218 dev tun0
0034|2026-01-23 18:55:07 TUN/TAP device tun0 opened
0035|2026-01-23 18:55:07 net_iface_mtu_set: mtu 1300 for tun0
0036|2026-01-23 18:55:07 net_iface_up: set tun0 up
0037|2026-01-23 18:55:07 net_addr_ptp_v4_add: 10.11.41.218 peer 10.11.41.217 dev tun0
0038|2026-01-23 18:55:07 Initialization Sequence Completed`

[Aurel]

Salut,

Quelques remarques :

• Le titre est beaucoup trop long et mériterait d’être dans le corps du message
• Le log que tu as mis c’est le log de quoi ?
• Dans la page santé on voit que visiblement des process ont été killés par manque de mémoire, ça peut quand même être un indice
• Quand tu dis que jeedom plante c’est à dire ? le site web ne répond plus ? tu as une page blanche ? un message d’erreur ?
• Tu indiques que ça vient d’un scénario, ça serait bien de nous le montrer

[Tonio16]

Et la charge à 7…

[Aurel]

Oui j’ai vu Mais j’allais y venir après

[ThierryJ]

Bonjour,
Je te remercie de bien vouloir considérer le problème que je rencontre :
1- le titre … ok c’est noté
2- le log … c’est celui de openvpn_dns_jeedom. Alors que tous les log sont vides c’est celui qui se remplit lorsque le plantage se produit.
3- page santé … oui je vois bien des process killés mais je ne sais pas comment corriger
4- jeedom plante : plus d’accès sur le réseau local, les scén.arios ne s’exécutent plus, les tempo en cours sont perdues et ça dure de 20 à 30 mn et ça remonte tout seul
5- voir les photos du scénario, jointe, celà concerne la fermeture des volets au nombre de 15. Je n’ai aucun message d’erreur. mon installation est en knx et j’utilise le plugin EIBD qui fonctionne bien sans messages ni log non plus

[rennais35000]

Bonjour,
As tu mis une pause de 1s entre chaque action volet ?
4.5.2 étant plus rapide que les autres versions que nous avions, le core exécute mais le reste ne suit plus. J’ai été obligé de faire ça, à tester chez toi.
Cordialement

[ThierryJ]

Merci pour ton retour,
comment fais tu une pause de 1s avec un sleep ou avec Dans ?
Tu peux voir par exemple que j’ai mis un sleep de 60 s entre la fermeture des fenêtres velux éventuellement ouvertes avant l’envoi de la commande de fermeture des volets

La commande Maison(ALL VR)Fermé a pour objectif en principe d’envoyer une seule commande au réseau knx de la maison, qui gère l’envoi des commandes vers les 15 volets, Jeedom "n’a plus qu’à gérer " les retours d’état normalement.

Je ne sais pas ou tracer les anomalies pour les présenter ici
Merci

[rennais35000]

Oui j’ai juste mis un sleep. (il faut mieux mettre un slip avant d’ouvrir les volets )

Je ne sais pas si c’est l’origine de ton pb, juste le vécu que j’ai eu en passant en 4.5

[ThierryJ]

Ok, je te remercie, je vais essayer cette solution !

[Bison]

Salut,

Essai par étape en désactivant ce qui serait le plus susceptible de poser problème et avance suivant les résultats.

Désactives l’action pour faire parler Alexa et désactive l’exécution du scénario que tu appelles depuis ce scénario.

Exécutes le scénario et vois ce que ça donne.

Si c’est OK, active le fait de faire parler Alexa (laisse l’action du lancement du scénario décoché) et recommence…

[ThierryJ]

Merci Bison, pour cette procédure pas à pas,
j’ai corrigé le scénario de fermeture des volets avec des sleep après chaque commande de volet comme suggéré par rennais35000 que je teste ce soir,
et si pas concluant j’enchaine avec le pas à pas, et je ferai un retour ici
Merci !