Correctifs de stabilité pour les déconnexions récurrentes du démon

Bonjour,

Le plugin étant marqué « non maintenu », je partage les correctifs que j’ai identifiés, appliqués et validés en conditions réelles sur mon installation, suite à des déconnexions régulières du démon Node.js (alexaapi.js) vis-à-vis d’Amazon Alexa.

Symptôme initial

Le démon perdait la connexion à Amazon de façon récurrente sans se rétablir, obligeant à redémarrer le plugin manuellement.

Série 1 — Bugs de reconnexion (28/06/2026)

  1. process.exit(-1) sur reconnexion (alexaapi.js ~L2846) — toute erreur d’init, même un problème réseau temporaire, tuait le process. → Ne quitter que si le serveur HTTP n’a jamais démarré (1er lancement réel), sinon retry auto.
  2. MQTT désactivé après refresh du cookie (alexaapi.js ~L2823) — startServer(force=true) mettait lancerOuPasMQTT = false, coupant le push Amazon → Jeedom après chaque refresh de cookie (toutes les 72h). → lancerOuPasMQTT suit désormais toujours config.useWsMqtt.
  3. Compteur d’erreurs jamais réinitialisé (alexa-wsmqtt.js ~L372) — errorRetryCounter grossissait indéfiniment sans jamais revenir à 0 après une reconnexion réussie. → Reset à réception du Pong.
  4. 2ème tentative de reconnexion sans effet (alexaapi.js ~L2947/2963) — traiteErreur() loggait « il faudrait relancer » sans jamais appeler startServer(). → Appel effectif ajouté.
  5. Surveillance d’authentification désactivée (class/alexaapi.class.php ~L479) — checkAuth() commenté depuis le 20/09/2020. → Réactivé, vérifie la connexion Amazon toutes les 6 min.

Série 2 — Effets de bord découverts en debug live (02/07/2026)

La réactivation de checkAuth() (fix n°5) a révélé un second problème plus profond : quand le cookie Amazon doit être régénéré manuellement (session expirée), le process Node quittait systématiquement au redémarrage suivant (comportement voulu du fix n°1 pour un « vrai 1er démarrage »). Résultat : le watchdog natif de Jeedom (plugin::checkDeamon(), indépendant du plugin) relançait le démon en boucle toutes les ~5 min — et chaque relance tuait au passage toute génération manuelle de cookie en cours, empêchant définitivement la reconnexion tant qu’on n’intervenait pas pendant la fenêtre de 5 min.

  1. Crash-loop + kill de la génération de cookie en cours :
  • alexaapi.js (startServer()) : suppression totale du process.exit(), même au 1er démarrage. Le démon retente désormais dans le même process avec un backoff progressif (1 min → 15 min max), et notifie Jeedom (message_add) après 3 échecs consécutifs. Le process ne meurt plus jamais → le watchdog Jeedom ne le tue/relance plus.
  • alexaapi.class.php (checkAuth()) : ajout d’un backoff (relance à chaque passage pour les 2 premiers échecs, puis 1 fois sur 3, puis 1 fois sur 10) + alerte utilisateur unique au 3ème échec, au lieu de relancer en boucle toutes les 6 min à l’infini (et de solliciter Amazon inutilement, avec un risque de flag anti-bot).
  • alexaapi.class.php (deamon_stop() / deamonCookie_start() / deamonCookie_stop()) : une génération de cookie manuelle lancée il y a moins de 5 minutes ne peut plus être interrompue par un redémarrage automatique du démon principal.

Résultat

Testé en conditions réelles : cookie expiré depuis 6 jours (259 tentatives de relance échouées en une journée), génération manuelle relancée après application des correctifs — cookie régénéré avec succès, démon stable, MQTT reconnecté, plus aucun restart depuis.

Je peux fournir un patch/diff complet si quelqu’un souhaite l’intégrer au dépôt officiel ou le proposer en fork maintenu.


Informations Jeedom

Core : 4.6.1 (master)
DNS Jeedom : non

Plugin : Alexa - API
Version : 2025-11-08 01:04:00 (stable)
Statut Démon : Démarré - (2026-07-02 16:58:02)
Santé
🟢 Matériel : RPI 4 B
🟢 Système à jour : OK
🟢 Cron actif : OK
🟢 Scénario actif : OK
🟢 Démarré : OK 2026-06-26 18:43:22
🟢 Date système (dernière heure enregistrée) : OK 2026-07-02 17:12:07 (2026-07-02 16:54:02)
🟢 Droits sudo : OK
🟢 Version Jeedom : 4.6.1
🟢 Version OS : debian 11.11
🟢 Version PHP : 7.4.33
🟢 Nombre de processus Apache : 13
🟢 Version OS : Linux RPIJeedom 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux  [11.11]
🟢 Version database : 10.5.29-MariaDB-0+deb11u1
🟢 Espace disque libre : 76 %
🟢 Connexion active/max/autorisée : 15/118/151
🟢 Taille base de données : 10.08 GB
🟢 Espace disque libre tmp : 50 %
🟢 Mémoire disponible : 40 % (Total 3793 Mo)
🟢 Mémoire suffisante : 0 
🟢 Erreur I/O : 0
🟢 Swap disponible : 57 % (Total 4096 Mo)
🟢 Swappiness : 10 %
🟢 Charge : 2.41 - 2.4 - 2.35
🟢 Configuration réseau interne : OK
🟢 Configuration réseau externe : OK
🟢 Node : v22.23.1 
🟢 Python : Python 3.9.2 
🟢 Python 3 : Python 3.9.2 
🟢 Persistance du cache : OK
🟢 Apache private tmp : OK

3 « J'aime »

Bonjour. Bravo pour ce travail. par contre en pratique et pour les non initiés, on fait comment pour appliquer tes correctifs. Merci d’avance.

La réponse est donnée en bas de son post…

En effet, je paraphrase je peux proposé une mise à jour du plugin, mais le mieux serait de l’intégrer au plugin en beta dans un premier temps.
Mais pour cela il faut m’en donner l’autorisation, ou alors se présenter pour que je fournisse les infos.

Désolé, je n’avais pas compris. En effet, le mieux serait une mise à jour du plugin …

Ce n’est pas de ma compétence de toute façon.

Bonjour
Si j’ai annoncé que le plugin n’est plus maintenus, c’est pour plusieurs raisons que j’ai expliqué à plusieurs reprises…, au risque de recommencer:

  • un code difficilement lisible et donc difficultés de maintenances ou d’interventions.
  • Une API trop anciennes et des libs Dépricated !!, notamment pour des raisons de sécurité
  • de nombreux bugs, modales obsolètes, fuites mémoire et j’en passe.
  • des plugins qui en dépondent et qui ne sont pas de mon ressort.

C’est entre autre pourquoi le développement d’un pluginV2 a été amorcé par Jexou et que j’ai fais le choix de continuer dessus.
Certes le plugin(premium) est payant, ça peut paraitre chère mais j’ai passé plusieurs centaines d’heures entre le reverse-ingegnering et le développement des différentes fonctionnalités.
En terme de travail ce plugin m’a pris plus de temps que tous mes autres plugins réunis et je vous confirme que c’est l’équivalent d’au moins 4 ou 5 plugins standards donc vous en avez largement pour votre argent.

Donc le choix alexa-Premium et le meilleur choix !

Concernant ton fix (dont le diagnostic provient visiblement d’une IA), je suis pas 100% convaincu par la solutions proposé qui est en partie farfelue même si ça fonctionne aujourd’hui pour ce souci récent mais sans corriger les problèmes à venir.

Merci

3 « J'aime »

Bonjour,

Oui, je n’ai pas les compétences pour faire un plugin complet et parfait.
J’ai mis deux ans à faire mon premier Plugin à la main.

Aujourd’hui, je ne fais plus que guider une IA. Et quand je vois les ressources personnelles que j’investis en argent et surtout en temps. Je me dis que rendre payant mes plugins seraient justifiables.

Et ceux qui ont choisi de vendre leurs travail, c’est tout à fait naturel de demander une participation. Surtout que la somme unique semble dérisoire en comparaison des produits que nous achetons tous les jours.

2 « J'aime »

Bonjour,

Je bien envie de faire le correctif que tu as fait sur ton installe. Tu peux me décrire exactement ce qu’il faut faire ?

Merci

Bonjour @Aldarande,

J”ai aussi des problèmes récurrents de génération du cookie Alexa Api V1.

Pourrais-tu mepartager les modifs que tu as réalisé ?

Merci d’avance,

JP