jucom

Slt à tous, vu les délais entre les 1ers cas et un début de résolution qui n'est même pas encore envisagée, je pense que je vais repasser sur EEDOMUS. J'avais basculer sur Fibaro pour la stabilité et surtout le suivi des modules de la même marque sur batteries. Au final, quand les notifications de batteries faibles arrivent (quand elles arrivent) le devices est déjà tombé depuis un moment et maintenant la box plante sans raisons apparentes. Plusieurs points positifs quand même ; - j'ai réussi à refaire tout ce que je faisais avec l'ancienne box - j'ai appris à faire des requêtes net.HTTPClient - j'ai appris à faire parler Alexa à partir d'alertes générées par la box - j'ai arrêté de vouloir faire de la sécurité avec une box domotique et je suis passé sur Ajax - j'ai pu échanger avec vous qui animez ce forum et m'avais patiemment aider ! Si c'est corrigé très prochainement temps mieux sinon dès que j'ai le temps je change de box. En tout cas merci pour votre aide ! :-)

Slt, Je n'ai pas encore le courage de le faire, mais je testerai bien un reset complet pour remettre au fur et à mesure chaque catégorie d'éléments en laissant 30 jours entre chaque catégorie pour voir à quel moment ça crash.

Bonjour, de mon coté, depuis quelques mois et sans modifications de ma part la box a commencé à faire des reboot dans le meilleurs des cas ==> Le système a récupéré d'une erreur inattendue ou plantages complets. Je suis sur la 5.130.64. J'ai enlevés les quick apps les 1 apres les autres, idem avec les scenario un peu tordu mais c'est tjrs pareil. Petite évolution quand même je suis passé de 2 crash par semaine à 1 tous les 15j. J'ai principalement du zwave et je n'ai pratiquement plus de scénario. Il m'en reste une 20aine qui tournent pour allumer un module sur détections PIR ou lancer des requetes net.HTTPClient simples. pour les appareils, il doit m'e, rester une grosse 20aine. J'ai contacté Fibaro, réponse : Bonjour, Merci pour votre message, En ce qui concerne "l'erreur inattendue", nous sommes conscients de ce problème et nous l'avons déjà transmis à nos ingénieurs, qui travaillent actuellement à le résoudre le plus rapidement possible. Je suis vraiment désolé pour la gêne occasionnée mais je dois vous demander un peu plus de patience. Lorsque l'erreur se reproduit, veuillez télécharger les journaux d'événements après le crash pour analyse. Vous pouvez le faire en collant ce lien dans votre navigateur : <gateway_ip>/api/service/logsDump <gateway_ip> est l'adresse IP de la passerelle à partir de laquelle vous essayez de télécharger les journaux d'événements. Cela devrait ressembler à ceci. Ensuite, après avoir entré votre identifiant et votre mot de passe de passerelle, vous commencerez le téléchargement. Pozdrawiam/Cordialement, Je suis un peu blasé car quand la box plante sans reboot tous les périphériques restent dans leur derniers états. Autant dire que dans ces conditions, la box ne me sert plus à rien mis à part des actions futiles sans conséquences en cas de crash. Il reste à attendre et scruter chaque jour ma box pour voir si elle a planté et envoyer le Dump chez Fibaro. Henri, ton problème est il résolu ? Sommes nous beaucoup dans ce cas ? Merci,

Slt à tous, je ne sais pas si vu avez vu cette info ; Je n'ai pas trouvé + de données sur le sujet. Peut être déjà des dev en cours pour Fibaro ?

Slt, en faisant des modif sur le synology, j'ai mis en défaut la quick app sans le vouloir. Du coup à force d'essayer de se connecter, la HC3 s'est retrouvée blacklistée comme c'est le cas a chaque fois qu'il y a une indisponibilité pendant un laps de temps. Afin de corriger ce problème j'ai apporté 1 modifications dans le Synology et ma box a repris normalement la discutions. J'ai déclaré l'IP de ma HC3 comme étant fiable. le résultat : [25.10.2021] [17:46:45] [ERROR] [QA_SURVSTATION_455]: QuickApp:getSID() : Error #407 Max Tries (if auto blocking is set to true). [25.10.2021] [17:47:45] [TRACE] [QA_SURVSTATION_455]: Request new SID [25.10.2021] [17:47:45] [ERROR] [QA_SURVSTATION_455]: QuickApp:getSID() : Error #407 Max Tries (if auto blocking is set to true). [25.10.2021] [17:48:45] [TRACE] [QA_SURVSTATION_455]: Request new SID [25.10.2021] [17:48:46] [DEBUG] [QA_SURVSTATION_455]: Ready [25.10.2021] [17:48:46] [DEBUG] [QA_SURVSTATION_455]: Found 4 cameras Je précise que je suis toujours avec le code modifié pour la version=6 -- Generate new SID -- function QuickApp:getSID(callback) if debug then self:debug(tools:args("QuickApp:getSID")) end self:trace("Request new SID") self:getAPI("/webapi/"..self.pathAuth.."?api=SYNO.API.Auth&method=Login&version=6&account="..self.User.."&passwd="..self.Password.."&session=SurveillanceStation&format=sid", { success = function(response) if debug then self:debug("QuickApp:getSID() : success") A suivre..

J'ai check les log coté Synology. Les crash semblent correspondre au moment ou les quotas d'enregistrements sont atteints. A ce moment le syno fait une purge des vieux fichiers. Je pense qu'il est indispo pendant ce laps de temps pour répondre correctement aux demandes envoyées par la HC3. Les demandes s'enchainent et la HC3 se retrouve d'abord en insuffisant privilège puis black listée par le syno. (c'est l'état dans lequel ca se termine cote HC3) Apres un reboot ca passe de nouveau. Le screenshot "normal" quand les demandes arrivent normalement (il y en a bcp) Le screenshot "crash" quand les demande n'arrivent plus (juste apres la purge des vieux fichiers vidéos hors quotta) Le screenshot "roboot ok" quand ca repart apres le reboot Il faut que j'arrive a check les log des 2 cotés quand ça va se produire de nouveau

Ok, j'ai ajouté les notif sur les cameras en cas d'indisponibilité.

Je vais essayer de check tous les matins et soirs.

Oui c'est exactement ça. Je voudrai pouvoir sortir des log mais comme l'historique est limité, je n'ai pas le moment où se produit l'événement qui pose problème. Quand je check soit ça fonctionne, soit ça tourne en erreur depuis trop longtemps.

Bonsoir, y a t'il une façon de recup plusieurs jours de log ? Actuellement je les consulte depuis la console. Merci,

hello, si j'ai bien suivi et selon les info que j'ai récupéré lors de la conf avec une précédente box ; Pour que la box puisse se log sur le syno, il faut d'abord qu'elle demande et obtienne un SID. Une fois obtenu, elle peut s'identifier. Effectivement quand on reboot le syno, le sid change donc il faut que la box le demande à nouveau pour pouvoir s'identifier. Je vois dans les log que le SID est bien redemandé par la box mais elle n'arrive plus à se connecter pour une insuffisance de privilèges. En changeant le fameux "version=x", sur le moment ca ne fonctionne pas car à force d'essayer le syno la blacklist. A ce moment, quand je reboot le syno la liaison Box / Syno reprend. Je ne sais pas si mon analyse sera utile mais je me demande si il n'y a pas une autre ligne dans le code ou "version=x" serait différent ce qui expliquerai qu'a un certain moment on se retrouve de nouveau avec un insuffisant privilège. La je suis de nouveau en "version=6" sur la section ci-dessous et ça tient depuis hier. -- Generate new SID -- function QuickApp:getSID(callback) if debug then self:debug(tools:args("QuickApp:getSID")) end self:trace("Request new SID") self:getAPI("/webapi/"..self.pathAuth.."?api=SYNO.API.Auth&method=login&version=6&account="..self.User.."&passwd="..self.Password.."&session=SurveillanceStation&format=sid", {

Hello, manifestement le changement de méthode fonctionne sur le moment mais n'est pas persistant. J'ai testé plusieurs version=6 puis 7 etc.. Au bout d'un certain temps on toujours le meme message d'erreur. 06.10.2021] [13:21:31] [ERROR] [QA_SURVSTATION_455]: QuickApp:getCameras() : Error #105 Insufficient user privilege Il y a quelque chose qui varie avec le temps. -- -- Generate new SID -- function QuickApp:getSID(callback) if debug then self:debug(tools:args("QuickApp:getSID")) end self:trace("Request new SID") self:getAPI("/webapi/"..self.pathAuth.."?api=SYNO.API.Auth&method=login&version=6&account="..self.User.."&passwd="..self.Password.."&session=SurveillanceStation&format=sid", {

Content d'avoir pu aider.

Version 6 et reboot ton syno car logiquement au bout d'un nbr de tentatives il Blacklist temporairement.

et merci beaucoup pour l'info, ne n'aurai pas trouvé ! :-)

Bonsoir, je viens de pousser le quick app en faisant la modif version 7 ca n'a pas fonctionné pour moi. en revanche avec version 6 ca passe. A suivre.. -- -- Generate new SID -- function QuickApp:getSID(callback) if debug then self:debug(tools:args("QuickApp:getSID")) end self:trace("Request new SID") self:getAPI("/webapi/"..self.pathAuth.."?api=SYNO.API.Auth&method=login&version=6&account="..self.User.."&passwd="..self.Password.."&session=SurveillanceStation&format=sid", { ...

je pense qu'il faut simplement que tu remplaces tes caractères spéciaux par un code hexa dans ta requête http http://192.168.XX.XX/XXXXX/fibaro/sql.php?value= le ? et le = sont à remplacer. correspondances ici https://www.nicolas-hoffmann.net/utilitaires/codes-hexas-ascii-unicode-utf8-caracteres-usuels.php J'ai eu le même problème. Ma requête passait très bien ds un navigateur et sur mon ancienne box. J'ai cherché pendant 3 semaines.

Hello, pour ma part, j'en ai 1 sur 2 qui se sont Maj. Pourtant tous en 5.1 au départ. Le 2 eme passe en échec de maj systématiquement. Quelqu'un a déjà eu ce problème ?

Hello, si vous avancez sur le sujet ca m'intéresse. Comme vous je suis bloqué avec le panneau d'arrosage HC3 qui est inutilisable. J'ai parcouru tout le forum en vain. Merci,

Merci, je vais regarder ca dès que possible.

Hello, sur HC3 je n'ai pas la possibilité de considérer le IN1 ou IN2 comme des interrupteurs. J'arrive à les faire varier malgré tout de 0 à 10 mais le temps de réaction est très long malgré les réglages de sensibilité à 0.5V (j'ai testé 2v aussi). La seule solution que j'ai trouvé est d'interroger toutes les 5s mais je ne pense pas que ca soit idéal. Les paramètres commencent à 24., il n' y a rien avant. C'est pareil chez vous ?

Oui j'avais commencé a regarder, c'est juste que pour moi c'est une nouvelle fonction à apprendre et je ne sais pas comment l'utiliser. Du coup j'ai fait au plus simple d'abord mais plus long du coup .. Merci encore !

J'ai trouvé !! Laser tu m'a mis sur la voie avec les ". J'ai creusé pour tomber sur ce site faisant référence à Encodage-pourcent https://developer.mozilla.org/fr/docs/Glossary/percent-encoding L'HC3 avec net.HTTPClient() semble ne pas aimer du tout certain caractères spéciaux et je pense que les navigateurs modernes les interprètent tout seul. Apres vu mon niveau je me trompe peut être dans l'analyse. J'ai donc enlevé tous les ? les & et je les ai remplacés. ca donne ca https://ADRESSESYNOLOGY/webapi/entry.cgi%3Fapi=SYNO.SurveillanceStation.ExternalEvent%26method=Trigger%26version=1%26eventId=1%26eventName=This_is_external_event1%26account=LOGIN%26password=PASSWORD au lieu de ca https://ADRESSEDUSYNO/webapi/entry.cgi?api=SYNO.SurveillanceStation.ExternalEvent&method=Trigger&version=1&eventId=1&eventName=This_is_external_event1&account=LOGIN&password=PASSWORD Ca fonctionne enfin ! Un grand merci pour le temps passé !

Effectivement la commande dépouillée des " passe bien dans le navigateur https://ADRESSEDUSYNO/webapi/entry.cgi?api=SYNO.SurveillanceStation.ExternalEvent&amp;method=Trigger&amp;version=1&amp;eventId=1&amp;eventName=This_is_external_event1&amp;account=LOGIN&amp;password=PASSWORD Mais pas via la HC3 qui renvoie toujours [07.03.2021] [18:38:28] [DEBUG] [SCENE99]: OK, réponse : {"error":{"code":101},"success":false} J'ai testé avec ' juste avant et après le requête HTTPS et " aussi mais le résultat est le même. La requête https initial est générée tel quel par surveillance station avec tous ces ". Je l'utilisais dans EEDOMUS et je la teste dans un navigateur.

Je n'avais pas fait attention non plus et c'est justement ce que j'ai testé et ca ne fonctionne pas. Il y a un thermostat lié à une sonde de Tempé et un actionneur ON/OFF