No stations/devices found persistant malgré connexion cloud OK

florent71700 · Septembre 8, 2026, 7:22

D’abord merci pour le correctif, l’authentification et l’armement du mode garde fonctionnaient nickel hier après la mise à jour (testé en conditions réelles, alarme + sirènes caméras OK).

Mais depuis cette nuit (~2h du matin), nouveau souci différent : le démon se reconnecte bien au cloud, mais la liste des stations/appareils revient systématiquement vide, et ça persiste depuis des heures (encore le cas actuellement).

Vérifications faites avant de poster

Conteneur en bonne santé (healthy), pas de crash, image 3.1.0
Toutes mes caméras/HomeBase s’affichent normalement dans l’app Eufy officielle sur mon téléphone — pas un souci de compte côté Eufy
Pas encore cliqué sur « Synchroniser » dans le plugin, par prudence

Logs complets, dans l’ordre chronologique

Disconnect puis reconnexion à 2h du matin, driver connecté mais listes vides d’emblée :

[2026-09-08 02:00:04] DEBUG [handleEvent] msg received: {"source":"driver","event":"push disconnected"}
[2026-09-08 02:00:04] INFO *** Arrêt du démon eufyd ***
[2026-09-08 02:00:16] DEBUG eufy-security-ws image version: 3.1.0
[2026-09-08 02:00:16] DEBUG eufy-security-ws service online: 1
[2026-09-08 02:00:16] INFO *** Lancement du démon eufyd ***
[2026-09-08 02:00:17] DEBUG [handleResult] msg received: {"type":"result","success":true,"result":{"state":{"driver":{"version":"4.1.0","connected":true,"pushConnected":true},"stations":[],"devices":[]}}}
[2026-09-08 02:00:17] INFO [setDevicesList]
[2026-09-08 02:00:17] INFO >>> stations: []
[2026-09-08 02:00:17] INFO >>> devices: []

Toute tentative de rafraîchir un équipement précis échoue ensuite en cascade :

[2026-09-08 02:00:21] DEBUG [sendToDaemon] msg: {"messageId":"T8142T9322050E45","command":"device.get_properties","serialNumber":"T8142T9322050E45", ...}
[2026-09-08 02:00:21] DEBUG [handleResult] msg received: {"type":"result","success":false,"messageId":"T8142T9322050E45","errorCode":"device_not_found"}
[2026-09-08 02:00:21] WARNING [handleResult] unexpected error: T8142T9322050E45: device_not_found
[2026-09-08 02:00:22] DEBUG [handleResult] msg received: {"type":"result","success":false,"messageId":"T8410P31214323F6","errorCode":"station_not_found"}
[2026-09-08 02:00:22] WARNING [handleResult] unexpected error: T8410P31214323F6: station_not_found

De 4h30 à 7h10, cycle répété toutes les ~10 minutes, toujours vide :

2026-09-08 04:30:13.519 INFO eufy-security-ws:eufy-security-client [http] [HTTPApi.refreshStationData] No stations found.
2026-09-08 04:30:13.519 INFO eufy-security-ws:eufy-security-client [http] [HTTPApi.refreshDeviceData] No devices found.
2026-09-08 04:40:13.521 INFO eufy-security-ws:eufy-security-client [http] [HTTPApi.refreshHouseData] No houses found.
(... même motif répété en continu jusqu'à 07:10:13 ...)

Une tentative de commande manuelle (armement du mode garde) échoue pour la même raison :

[2026-09-08 06:17:52] DEBUG [execute] station.guardMode:set:1
[2026-09-08 06:17:52] DEBUG > send to daemon: {"messageId":"T8010T2321520725","command":"station.set_property","serialNumber":"T8010T2321520725","name":"guardMode","value":"1"}
[2026-09-08 06:17:53] DEBUG [handleResult] msg received: {"type":"result","success":false,"messageId":"T8010T2321520725","errorCode":"station_not_found"}
[2026-09-08 06:17:53] WARNING [handleResult] unexpected error: T8010T2321520725: station_not_found

Une bascule push (fermeture puis nouvel enregistrement token FCM) a eu lieu à 7h14 sans rien résoudre :

[2026-09-08 07:14:18.679] INFO [main] Push notification connection closed
Shutting down
2026-09-08 07:14:22.199 INFO [http] [HTTPApi.refreshStationData] No stations found.
2026-09-08 07:14:22.203 INFO [http] [HTTPApi.refreshDeviceData] No devices found.
2026-09-08 07:14:22.210 INFO [push] [generateFid] generateFid ew00pvjr97XWCwdtA_4Coy
2026-09-08 07:14:24.623 INFO [main] [MegaTransition.registerMegaPushToken] v6 push: FCM token registered on the eufy_mega backend
2026-09-08 07:14:24.624 INFO [main] Push notification connection successfully established
2026-09-08 07:14:24.685 INFO [main] Push notification connection closed
2026-09-08 07:14:29.958 INFO [main] [MegaTransition.registerMegaPushToken] v6 push: FCM token registered on the eufy_mega backend
2026-09-08 07:14:29.961 INFO [main] Push notification connection successfully established

Et l’erreur complète côté serveur WS quand une commande station arrive malgré tout :

2026-09-08 07:15:14.127 ERROR eufy-security-ws Message error
StationNotFoundError Station doesn't exists, [object Object], StationNotFoundError
error stack:
  • eufysecurity.js EufySecurity.getStation
        node_modules/eufy-security-client/build/eufysecurity.js:491
  • message_handler.js StationMessageHandler.handle
        dist/lib/station/message_handler.js:8
  • server.js Object.station
        dist/lib/server.js:31
  • server.js Client.receiveMessage
        dist/lib/server.js:109
  • server.js WebSocket.<anonymous>
        dist/lib/server.js:43
  • node:events WebSocket.emit
        node:events:509
  • node:domain WebSocket.emit
        node:domain:489
  • websocket.js Receiver.receiverOnMessage
        node_modules/ws/lib/websocket.js:1239
  • node:events Receiver.emit
        node:events:509
  • node:domain Receiver.emit
        node:domain:489

Dites-moi si vous voulez d’autres logs ou si je peux tester quelque chose de particulier. Merci encore pour le travail sur ce plugin !

florent71700 · Septembre 9, 2026, 7:58

Petite mise à jour utile je pense : le problème des stations/devices vides s’est reproduit une deuxième nuit d’affilée, quasiment à la même heure pile (02h00:04 puis 02h00:23) :

[handleEvent] msg received: {"source":"driver","event":"push disconnected"}

suivi d’une reconnexion automatique avec listes vides, exactement comme le premier épisode.

Ce qui est intéressant : un simple docker restart ne suffit pas à réparer (testé), mais une vraie recréation complète du conteneur répare la situation :

docker rm -f eufy
docker compose -f docker-compose.yml up -d

Après ça, toutes les commandes repassent en "success":true normalement.

Ça ressemble à une coupure côté serveur Eufy à heure fixe (peut-être liée à l’expiration d’un jeton de session sur 24h ?), mal gérée au moment du renouvellement automatique par la lib — elle se reconnecte bien, mais ne recharge pas la liste des appareils correctement.

En attendant un correctif éventuel, j’ai mis en place un cron qui refait cette recréation complète chaque nuit à 2h10 (rustine de mon côté, pas une vraie solution). Je voulais surtout signaler le motif récurrent au cas où ça aide à identifier la cause côté lib — dites-moi si un test ou des logs supplémentaires peuvent aider !

rootard · Septembre 9, 2026, 4:50

Salut

juste pour vous dire que je suis dans le même cas que vous
effectivement le token d’authentification doit avoir un lease time de qques heures, chez moi ca a fonctionné 8h mais pas toute la nuit…

pas le temps la mais je regarderai ce que je peux faire ce week-end

florent71700 · Septembre 9, 2026, 5:51

Ah ça rassure de savoir que c’est pas isolé chez moi, merci du retour !

Un détail qui pourrait aider pour le diagnostic : chez moi c’est systématiquement à 2h00 pile, deux nuits de suite, indépendamment de l’heure à laquelle le conteneur a été (re)démarré dans la journée. Ça ferait plutôt penser à une heure fixe côté serveur Eufy (genre un cycle de maintenance ou un minuit UTC + décalage) plutôt qu’à une durée de session de X heures depuis la connexion — vu que chez vous ça a tenu 8h, ce qui ne collerait pas avec une durée fixe identique pour tout le monde.

Pas de souci pour le timing, prenez le temps qu’il faut.

florent71700 · Septembre 9, 2026, 7:12

@rootard Petite découverte qui pourrait vous être utile pour le correctif.

J’ai comparé pourquoi le bouton « Redémarrer » (Setup docker) répare la situation chez moi et gialla, alors qu’un simple docker restart ou même un docker rm -f + docker compose up -d à la main ne fonctionnait pas. En regardant le code de eufyUtils::setupContainer(), j’ai trouvé la différence :

case 'start':
    ...
    self::updateYaml();
    if (file_exists($json))
            rename($json, $json . '.old');
    ...

Le bouton renomme systématiquement persistent.json avant chaque démarrage, alors que mon script maison le laissait intact. En reproduisant ce renommage dans mon script, ça déclenche immédiatement un mail Eufy « nouvel appareil connecté » (avec « Appareil / Navigateur : PHONE », intéressant au passage sur la façon dont la lib s’annonce côté Eufy), et la connexion redevient fonctionnelle dans la foulée (stations/devices repeuplés, plus de getPassportProfile en erreur).

Donc si je résume : garder le même persistent.json au redémarrage semble parfois empêcher une réauthentification propre une fois le token cassé/expiré, alors que le supprimer force un nouveau cycle d’auth complet qu’Eufy accepte (avec l’alerte sécurité au passage).

En attendant votre correctif, j’ai automatisé ça chez moi avec un script qui reproduit exactement la logique de setupContainer('start') (renommage du json + recréation du conteneur), via un cron toutes les 6h — ça tient le coup depuis.

Peut-être que ça pourrait aider à la vraie solution : détecter automatiquement l’erreur d’identité/session et déclencher ce renommage + reconnexion côté lib, plutôt que de compter sur un redémarrage manuel ? En tout cas ça confirme que le problème est bien lié à la persistance de session, pas à l’authentification elle-même.

Dites-moi si ça matche avec ce que vous observez de votre côté !

florent71700 · Septembre 10, 2026, 5:41

@rootard Dernier point avant de laisser reposer ça pour la nuit.

J’ai vérifié explicitement si l’image du captcha (le mécanisme documente driver.set_captcha avec un base64 data:image/... dans les logs) apparaissait quelque part, même en forçant la recherche :

sudo docker logs eufy 2>&1 | grep -o "data:image[^\"]*"

Rien, aucune fois. Donc soit c’est un souci de niveau de log (déjà en Debug chez moi), soit — plus probable vu tout le contexte Mega — le nouveau flux v6 n’expose pas encore ce mécanisme de résolution qui existait dans l’ancien système. Rien d’actionnable manuellement de mon côté pour l’instant, du coup.

Dans l’interface du plugin, l’état est conséquent avec ça : bloc « Démon » en rouge (NOK), « Communication » affiche OK/NOK (le conteneur répond bien en réseau, mais l’authentification cloud échoue).

J’ai désactivé complètement mon cron de recréation pour ne plus solliciter de reconnexion du tout cette nuit — dans le doute, je préfère laisser reposer plutôt que de risquer d’aggraver encore le blocage côté détection anti-fraude Eufy.

Mon compte reste sain par ailleurs (app mobile nickel). Je reste dispo pour tester dès que vous avez une piste ce week-end, bon courage pour la suite !

rootard · Septembre 11, 2026, 5:49

Salut

J’ai fait quelques tests et j’ai pas de très bonnes nouvelles malheureusement…

Effectivement la RAZ de persistent.json ne suffit plus, le captcha apparait systématiquement.

La seule solution de contournement qui semble fonctionner pour l’instant est de se logger sur l’app et de changer le password avant de relancer le container…pas très pratique et difficile à automatiser en l’état.
En plus la nouvelle session tombe en timeout au bout de 24h ou moins on sait pas bien…
Si ca vous dit je vous laisse suivre la discussion ici

Le nouvel API est en alpha et il est très différent de l’ancien donc ca va nécessiter une refonte majeure du plugin qui va prendre du temps. Si vous voulez voir ou ca en est le channel discord est la

florent71700 · Septembre 12, 2026, 10:11

@rootard Merci pour le retour, et désolé d’apprendre que ça se corse encore côté API alpha.

Petite observation qui pourrait être utile : j’ai mis en place chez moi un script qui ne renomme persistent.json que de façon ponctuelle, uniquement quand une vérification horaire détecte un vrai problème (stations/devices vides), plutôt que de le faire systématiquement à heures fixes plusieurs fois par jour comme je le faisais avant.

Sur les dernières 27h : 27 vérifications, une seule vraie panne détectée (cette nuit à 3h), une seule recréation déclenchée — et ça a marché sans déclencher de captcha cette fois, contrairement à ce que j’avais chez moi avant-hier avec des tentatives plus rapprochées. La connexion tient depuis sans souci (vérifié via ./eufy test, stations/devices bien peuplés).

Donc ça semble corroborer l’idée qu’un renouvellement de session rare et seulement quand nécessaire passe mieux auprès de la détection anti-fraude qu’un renouvellement fréquent/systématique — possible que la fréquence de vos tests de ces derniers jours ait justement fini par déclencher le captcha de façon plus systématique chez vous. Ça reste une rustine fragile en attendant la vraie refonte évidemment, mais ça tient le coup pour l’instant si ça peut aider d’autres personnes du fil en attendant.