Même symptôme que le sujet de NIK44fr (« identity rejected », code 4404, « get identity error »), mais apparemment une cause différente chez moi — je vous partage mon diagnostic au cas où ça aide à isoler le problème.
Config
Plugin Eufy, mode docker local
eufy-security-ws version 3.1.0 (image bropat/eufy-security-ws:latest)
eufy-security-client interne : 4.1.0 à l’origine
Ce que j’ai testé, sans succès
Mise à jour manuelle de la lib eufy-security-client de 4.1.0 → 4.1.1 (celle qui corrige #939, transport v6/legacy pour FCM) via npm install eufy-security-client@4.1.1 dans le conteneur, puis redémarrage. Version confirmée active après coup. Aucun changement : erreur identique immédiatement après reconnexion.
Vérifié que mon compte Eufy n’est pas bloqué / ne demande pas de 2FA ou captcha : l’app officielle sur mon téléphone se connecte sans aucun souci.
Suppression/renommage de persistent.json (le fix qui a débloqué NIK44fr sur son fil) : testé, sans effet chez moi. L’erreur revient à l’identique dès la première tentative de connexion après redémarrage du conteneur, sans même passer par une phase de token en cache.
Logs (extrait, après suppression de persistent.json et redémarrage)
MegaHTTPApi.signedPost] MegaApi identity rejected — evicting cached identities to force re-handshake { code: 4404 }
[MegaTransition.loginMega] v6 login failed { code: 4404, msg: 'get identity error' }
[HTTPApi.getPassportProfile] Get passport profile - Response code not ok { code: 200, ... }
[MegaTransition.runConnect] connect: neither v6 nor legacy login succeeded — not signalling connected
Conséquence concrète : plus aucune commande ne passe (armement du mode garde depuis un scénario Jeedom notamment), pas seulement les notifications push.
Dites-moi si un autre test ou des logs plus détaillés peuvent aider. Merci pour votre travail sur ce plugin !
oui malheureusement le probleme est confirmé coté Eufy
Les devs de eufy-security-client preparent une nouvelle lib mais c’est une reecriture quasi complète donc ca va prendre du temps…
En attendant si ca vous arrive vous pouvez essayer le script proposé sur le thread (pas encore testé de mon coté)…
Une précision si possible : quand vous dites « passant le node en 2.4 », vous parlez de quoi exactement ?
La version du conteneur eufy-security-ws (l’image Docker) ?
La version de Node.js à l’intérieur du conteneur ?
Autre chose ?
J’ai regardé les tags disponibles sur Docker Hub pour bropat/eufy-security-ws et je ne vois pas de version 2.4 (ça passe de 2.1.0 à 3.0.0 directement), du coup je ne sais pas trop quelle commande reproduire exactement. Si vous avez la commande utilisée sous la main, ça m’aiderait énormément à tester la même chose de mon côté.
J’ai regardé de plus près chez moi avant de tenter la même chose, et ça confirme ma prudence : mon Node.js système (actuellement en v22.23.1) est utilisé activement par deux autres plugins critiques — le démon mqtt2 (process en continu depuis des semaines) et surtout Zigbee2MQTT (z2m), qui pilote toute ma cinquantaine d’appareils Zigbee via des modules compilés nativement pour cette version précise (serialport bindings, zigbee-herdsman, etc.). Passer en Node 24 sur le système risquerait donc de casser tout mon réseau Zigbee pour un bénéfice non confirmé sur Eufy — du coup je préfère ne pas reproduire cette étape chez moi sans en avoir la certitude.
D’où ma question précédente : est-ce que vous auriez reçu un mail/alerte de sécurité Eufy à peu près au moment où ça s’est remis à fonctionner chez vous ? Si c’est le cas, ça orienterait plutôt vers un déblocage côté compte/sécurité Eufy que vers Node.js lui-même — et ça éviterait à d’autres lecteurs du fil de prendre le même risque sur leur Node.js système pour rien.
Merci encore pour votre retour, ça aide à avancer même si ça reste mystérieux !
