Bonjour,
Non je veux juste que tu me transmettre les logs (le daemon + le plugin) où tu as fait ce constat.
Merci
Bonjour,
Les logs sont ceux de mon post du 5 Avril mais je suis désolé je n’ai plus ceux du plugin que j’avais oublié de transmettre.
J’ai refait la même manip et voici les 3 logs :
scenario2.log (44,4 Ko)
reolink.log (23,4 Ko)
reolink_daemon.log (11,3 Ko)
Démarrage du daemon avec l’adresse à 10:29:02. J’ai généré des détections qui remontent bien jusqu’au scénario.
A 10:32:10, j’ai redémarré le daemon avec le nom d’hôte (« camera-test.lan »). J’ai généré des détections que l’on voit dans le log du daemon mais qui n’apparaissent ni dans le plugin, ni dans le scénario.
Je répète, j’ai peut-être oublié de faire quelque chose étant novice sur Jeedom.
OK je viens de mettre la main sur la correction à effectuer.
Tu peux mettre à jour avec la dernière version.
Merci pour ta rapidité mais malheureusement il y a eu une régression car avec l’adresse IP les webhooks n’apparaissent que dans le log du daemon mais plus dans le plugin et bien entendu ça ne remonte plus au scénario.
En revanche, le comportement est identique entre IP et hostname.
J’ai oublié les log… désolé. Là c’est uniquement avec le hostname.
reolink_daemon2.log (8,1 Ko)
reolink2.log (22,9 Ko)
Oups… 
erreur d’inattention !
C’est corrigé
Merci ! Ca marche avec le hostname maintenant 
1 « J'aime »
bonjour a tous et toutes,
suite à la mise à jour des nouveaux firmwares 3.1.0.95x, une nouvelle option a été développé sur les cameras Reolink et disponible avec ces versions : Illegal Login Lockout.
Afin de la rendre possible dans le plugin de @Jezza34000, j’aurais besoin de votre aide pour identifier le paramètre qui gère cette fonctionnalité. Pour cela, j’aurais besoin du GetAbility (et GetDevInfo) de cameras en firmware version 3.1.0.95x ou sup
UPDATE : Suite a la reponse de Reolink que j’ai eu finalement tres rapidement a ce sujet, la fonctionnalite n’est pas encore pris en charge via une information du GetAbility,
Pour information, cette donnee est necessaire dans le plugin pour filtrer les commandes suivant les possibilités (fonctionnalites) des cameras
Si vous etes dans ce cas, voici les lignes de commandes a executer afin de generer les resultats :
commande -GetDevInfo- :
curl -s -k -X POST -H "Content-Type : application/json" -d "[{\"cmd\":\"GetDevInfo\",\"action\":1,\"param\":{\"channel\":#id#}}]" "https://#IP#/cgi-bin/api.cgi?user=#username#&password=#password#"
Remplacer #IP#, #username# et #password# par vos propres valeurs; Pour la valeur #id# de l’argument channel, mettre 0 (camera en standalone)-
Test 2 commande -GetAbility- :
curl -s -k -X POST -H "Content-Type : application/json" -d "[{\"cmd\":\"GetAbility\",\"action\":1,\"param\":{\"channel\":#id#,\"User\":{\"userName\":\"admin\"}}}]" "https://#IP#/cgi-bin/api.cgi?user=#username#&password=#password#"
Remplacer #IP#, #username# et #password# par vos propres valeurs; Pour la valeur #id# de l’argument channel, mettre 0 (camera en standalone)-
si vous êtes sous Windows, télécharger l’exécutable curl pour Windows et remplacer dans la commande curl par curl.exe
Merci d’avance de votre aide pour le développement du plugin. Me faire suivre vos résultats directement en MP
Bien cordialement
Elle sert à quoi cette option ? 
Hello. C’est pour quelle caméra ce firmaware ? J’ai une E1 Zoom et je ne vois pas de nouveau firmware Download Center – Reolink
Salut,
il s’agit de la fonctionnalité de blocage des comptes au bout de plusieurs tentatives d’identification infructueuses.
Cette fonctionnalité a été développé depuis le firmware 3.1.0.951 et supérieur. Ces firmwares sont actuellement déployés prioritairement sur les cameras AI POE.
Un nouveau couple de commandes a été crée pour sa gestion : GetSysCfg / SetSysCfg. J’ai pu avoir de la doc sur ces commandes
Par contre, je cherchai à savoir si un parametre du GetAbility avait été crée pour cela.
je viens d’avoir la reponse de Reolink aujourd’hui : ce n’est pas le cas
Message à tous ceux qui ont une (des) caméra(s) dont la commande d’action « Démarrer la calibration » est visible dans le plugin -cameras PTZ ayant la fonctionnalité PtzCheck supportée (E1Outdoor, RLC-823A ou RLC-523WA)-.
NB : la caméra E1Zoom ne supporte pas cette fonctionnalité PtzCheck.
En fin de calibration, la commande information « Etat calibration » -visible également- doit basculer de REQUISE → TERMINEE.
Par défaut, cette bascule d’état ne se fait pas.
Pour visualiser ce changement d’état, il est nécessaire de faire un refresh de la tuile de la caméra.
Afin que ce refresh soit fait en fin d’action de calibration, il faut ajouter à cette dernière, une action de refresh, positionnée en fin de l’action de calibration. Pour cela :
- Éditer la commande d’action « Démarrer la calibration » de la caméra (cliquer sur la roue crantée de la commande)
- Cliquer sur l’onglet Configuration
-
Dans la partie « Action après exécution de la commande », cliquer sur le bouton « +Ajouter »
-
Cliquer sur l’icône
-
Recherche la commande d’action de refresh (Rafraichir) de la caméra concernée et Valider
-
Sauvegarder la configuration
-
1 « J'aime »
Bonsoir Jezza,
Je suis désolé de t’embêter encore mais je constate un nouveau bug. Si j’ai une coupure d’électricité et que les caméras ainsi que la RPI s’arrêtent puis redémarre automatique dès que le courant revient, ton pluggin démarre bien mais mais aucune détection ne remonte. Pourtant, le démon est bien démarré et le redémarrer ne résout pas le problème.
Autant les dernières fois il me semblait que le redémarrage du démon avait résolu le problème mais cette fois-ci, impossible de revenir à un état nominal où les webhook remontent au scénario. Entre temps, la seule chose que j’ai faite est de mettre à jour Jeedom à la dernière version. Voici les logs :
reolink.log (281,7 Ko)
reolink_daemon.log (109,6 Ko)
Si tu as une idée ça serait super !
Merci !
Hello,
à quelle heure a eu lieu la coupure de courant ?
car sur les logs ci dessus tout est ok, le daemon est démarré, et il transmet bien les détections au plugin, il y a des traces de détections envoyés (daemon) et réceptionner (plugin)
La coupure de courant a eu lieu le 06/05 et visiblement le LOG n’a pas une rétention suffisante. J’ai demandé à Jeedom de garder l’historique des détections au niveau des commandes dans ton pluggin et je n’avais plus rien depuis cette date. Comme pour l’instant c’est une installation test qui n’allume qu’une LED, je ne m’en suis rendu compte que hier soir.
Ca donne ça :
J’avais activé initialement le reboot du démon tous les dimanches (valeur par défaut je crois). Hier, j’ai changé pour un reboot du démon tous les jours à 4H du matin et ce matin ça semble fonctionner de nouveau mais j’ai eu ceci comme warning :
et voici les nouveaux logs :
reolink.log (311,0 Ko)
reolink_daemon.log (63,2 Ko)
Malheureusement plus comme déjà évoqué, et comme on peux aussi s’apercevoir sur les forum de HA. Cette marque n’est pas super fiable niveau API. (Err 502 c’est le serveur web de la caméra qui plante, et « Réponse vide », c’est un grand mystère…)
Ce pourquoi je vais faire le MAX pour que ce plugin fonctionne du mieux, mais de toute évidence, je n’apporterai pas d’amélioration au plugin car je ne rachèterai plus de cette marque…
1 « J'aime »
je pense qu’il faut faire des reboots des cameras au moin une fais par semaine, de plus pour info, mes zoom fonctionne corectement, il y a que la rlc 810a ou le push fonctionn pas
C’est déjà fous ce que tu as fait. Mes E1 Zomm fonctionnement au poil avec ton plugin maintenant. Merci encore pour le travail.
Que prendrais-tu comme marque/modèle du coup ?
Je comprends ton choix.
Je te le concède, Reolink ne nous aide pas pour avoir une API clairement définie, documentée et stable. Ton plugin est vraiment un réel plus (perso, il est top) pour la communauté qui compte pas mal de possesseur de cameras de cette marque. Je te remercies pour tout le travail que tu as fait et ne souhaite pas qu’il soit abandonné.
Pour ma part, je continuerai à y apporter mes modestes améliorations si tu ne vois pas d’objection.
Forza @Jezza34000
Rassure toi je n’abandonnerai pas la projet, je m’occuperai de maintenir.
Mais il est difficile de concevoir un système visio de sécurité fiable sur des caméras qui ont des souci au niveau de leur stabilité.
Je possède d’autres marques de caméra tel que la marque « blanche » SERCOMM (plus connue sous les système visio des FAI français) et pour le moment j’ai à ce jour malgré mes nombreux bidouillage et autres tests jamais eu de plantage dessus.
Alors après certes SERCOMM à une API bien moins développé, mais là est la question :
Vaut-il mieux :
-Une pléthore de fonctions et options bugués ?
-Peu de fonction mais qui fonctionnent parfaitement bien ?
Dans le cas d’un système de sécurité c’est clairement la réponse 2 qui prévaut…