Bonjour,
j’ai une erreur qui remonte en log et dont je ne parviens pas a resoudre malgres la lecture de plusieurs posts sur deconz !
[00212EFFFF06D4F9] Error on backup : Echec de la requête HTTP : 192.168.1.36:8484/api/6FAB4DA903/config/export cURL error : Operation timed out after 2000 milliseconds with 0 bytes received
j’ai tenter de remplacer 127.0.0.1 par l’ip de mon jeedom… idem
j’ai aussi remplacer dans « nom » username par phoscon mais idem
si je tente de cliquer sur le bouton telechargement, j’ai « 401 - Accès non autorisé »
je sait faire la sauvegarde manuellement en ouvrant la fenetre du conbee
Pour info:
Rasberry pi 3b+ + µsd (pour le moment)
Conbee 2 FW 26680700
Bonjour j’ai le même problème de « 401 - Accès non autorisé »
J’ai essayé de relancer les dépendances, réinstaller Déconz, relancer le démon : toujours pareil
Je saisi l’opportunité de thread : j’ai moi aussi un soucis de backup deconz.
Je suis sous sous RPI, Jeedom à jour.
J’ai eu des problèmes de Deconz suite à MAJ manuelle en 2.24.2 + flash dernier firmware conbee2.
J’ai downgradé ma conbee2
j’ai re-inclus mes devices (après un bref essai de jeeZigBee entre temps, mais trop compliqué pour moi).
tout fonctionne à l’exception d’un inetrrupteur que je n’arrive pas à appairer.
J’ai en tout une douzaine de devices zigbee (capteurs, lumières, prises).
En tenant de solutionner mon soucis d’intégration d’interrupteur, j’ai exporté / importé plusieurs fois ma config zigbee en faisant différents essais, et maintenant je ne peux plus faire d’export ni depuis Deconz (ipjeedom:8484), ni en export depuis jeedom (erreur 401).
Qqun aurait une idée pour me permettre un export ? Cela cache-t-il une erreur plus compliquée?
Je me loggue sans soucis sous ip:8484 (c’est l’adresse que ça lance, idem que quand je me loggue à la main. Par contre je dois entrer le mdp de deconz/phoscon.
Mais quand je veux faire une sauvegarde, ça mouline puis : La création de la sauvegarde a échoué.
Ça a fonctionné. Y-t-il un nbre de sauvegarde ? Un rep à purger à tout hasard?
Merci
Si tu fais une sauvegarde depuis Phoscon il faut ensuite choisir le répertoire de chargement de cette dernière. Sinon elle reste dans un fichier temporaire sur la box.
Tu peux éventuellement voir s’il y a un manque d’espace disque dans la page santé de ta box Jeedom.
Une sauvegarde Phoscon de configuration zigbee fait quelques 100 de ko guère plus. Donc je ne pense pas que le pb vienne de là mais plutôt d’une base de données potentiellement corrompue. A force de charger/décharger une configuration entre plusieurs machines il se peut que la base ait été restaurée alors que pas complètement finie d’écrire .
Effectivement RAS côté santé Jeedom.
J’ai rebooté, juste par acquis de conscience, mais je ne peux pas faire de backup. Tout le reste est fonctionnel.
C’est pas inquiétant quand même de ne pas pouvoir faire de backup? un bdd corrompue c’est plutôt pas bon non ?
Un conseil ?
merci
Je viens de regarder dans mes sauvegardes jeedom, je n’ai plus rien dans l’archive Deconz depuis le 4 Janvier.
Dans .\plugins\deconz\data\ , dans l’achive tar.gz qui contient la deconz.tar il devrait y avoir 3 fichiers :
deConz.conf
session.default
zll.db
Là je n’ai rien.
Donc mes sauvegardes de Jeedom n’embarquent plus ma config Deconz.
Y-a-til un moyen d’éditer la base actuellement en place dans mon RPI pour voir ce qui est corrompu ?
Si oui qqun saurait me guider pour cela?
Je pourrais reloader ma dernière archive correcte, mais cela risque d’avoir des conséquences sur mes devices en place. Une particulièrement qui est maintenant dans une boite dans un mur, sous du silicone… et que je ne souhaite pas démonter pour la réveiller.
Si ta base de données zigbee a été supprimée tu n’auras hélas pas d’autre solution que :
restaurer la base à une date antérieure
refaire les appairages qui seraient postérieurs à cette restauration
Pas de moyen de modifier la base zigbee « simplement » manuellement càd d’ajouter dans les tables de la BdD zigbee les items absents ou corriger ceux erronés.
Très bizarre tout ça : je viens de vérifier en SSH : je trouve ma base zll.db sous root, pas sous le user PI avec lequel je m’identifie en SSH.
Du coup je l’ai copié vers home/pi pour pouvoir la télécharger par winSCP.
Je l’ai maintenant ouverte dans DB Browser for SQLite
Donc ma base existe… gérée par le user root.
Je vais essayer de la remplacer par une ancienne zll.db pour voir ce que ça donne (si je peux ensuite par exemple faire une sauvegarde) : dans ce cas cela me démontrera que la base en corrompue.
Si je ne peux pas créer de sauvegarde ce sera peut-être signe d’un soucis de droits.
@Yves19 ton avis stp?
Je raisonne de manière empirique, je n’ai pas de connaissances sur ce sujet…
le process deconz tourne peut être sous root ce qui peut expliquer que la base soit sous root et pas ton user.
S’il n’y avait aucune base de donnée le plug-in Deconz devrait remonter un erreur lors de chaque synchronisation , puisqu’il accède à cette base pour afficher les équipements zigbee ou gérer le réseau (appairage, retrait, …).
Tu peux sinon remplacer la base zigbee par la copie d’une ancienne sauvegarde. Au pire tu en seras quitte pour tout ré appairer en cas de pb.
J’avais en son temps fait une réponse sur un sujet similaire ici :
Merci. J’ai effectivement trouvé ce post en cherchant pourquoi je ne trouvais pas la bdd.
Je vais essayer de remplacer la bdd. Ensuite j’aviserai
(La suite ce weekend)
merci pour ton temps
J’ai ouvert les 2 sauvegardes que j’ai : celle, obsolète, qui une fois chargée permet de créer des sauvegardes, et celle, une fois chargée, qui déclenche une erreur lors de la tentative de création d’une sauvegarde.
J’ai comparé les 2 fichiers de configuration deconz.conf, et au tout début du fichier :
{“apsAck”:false,“apsUseExtPanId”:“0x0”,“curChannel”:11,“deconzVersion”:“2242”,“deviceType”:0,
le « apsUseExtPanId » n’était pas « 0x0 » mais la valeur qui se trouve sur « extPanId » plus loin dans le fichier.
J’ai donc modifié la configuration à l’intérieur de l’archive pour 0x0, chargé la sauvegarde soi-disant défectueuse, et surprise… j’ai pu créer une nouvelle sauvegarde (après avoir redémarré les services, bien sûr).
Tous mes appareils (à l’exception de ce @#!{@ d’interrupteur) fonctionnent correctement.
J’ai juste dû réveiller quelques capteurs, mais pas besoin de les appairer.
Je n’ai aucune idée de pourquoi ce fichier de configuration s’est soudainement corrompu, mais maintenant j’ai une solution qui fonctionne.
Ce n’était pas la zll.db
je peux créer une sauvegarde depuis jeedom (plus d’erreur 401) ou depuis phoscon.
C’est excellent !
Edit : j’ai donné une dernière chance à mon interrupteur, qui s’est réveillé en 3 secondes. Là encore le soucis venait de conf défectueuse.
en cherchant pourquoi je ne trouvais pas la bdd.