oracle7

@StéphanH Bonjour, C'est peut-être cela la solution : paramétrer un planning d'allumage, en fait d'extinction la nuit. Cela dit, sans lampes IR actives la nuit, l'image résultante risque d'être très sombre voire inexploitable. Il faut faire un compromis, ne rien voir ou voir les évènements de la nuit et éliminer tous les matins les enregistrements de mouvements "parasites". C'est un choix. Cordialement oracle7😉

@StéphanH Bonjour, Regardes si par hasard tu n'aurais pas un paramètre lié à l'Infra Rouge (IR). Par exemple, dans le logiciel constructeur de gestion/paramétrage des caméras chez HIKvision (accessible via un navigateur), on peut désactiver la lampe IR. Foscam étant aussi "une grande marque", il serait étonnant qu'il n'y ait pas aussi ce type de paramétrage. Par ex chez moi c'est dans "Paramètres système/Maintenance" donc par similitude, peut-être que ... Autre piste, regardes aussi si tu ne peux pas paramétrer "les mouvements brefs" i.e. inférieurs à 1 à 2 sec. Sinon, rassures-toi tu n'est pas le seul à avoir des soucis avec les papillons et autres insectes volants, le pire ce sont les araignées qui sont immanquablement attirées par la lampe IR et qui génèrent pléthore de faux évènements de mouvements sur la caméra. Voilà en espérant que cela pourra t'aider. Cordialement oracle7😉

@kroumi Pour compléter les explications précédentes, en général, je dis bien en général car il peut y avoir des exceptions/variantes, les plages d'@IP locales/privées suivantes sont utilisées pour : 10.0.0.0/255.0.0.0 : ce sous-réseau est plutôt utilisé en conjonction d'un réseau VPN (serveur VPN sur le NAS et client VPN sur un périphérique externe). Il devient le réseau local et ton NAS a alors par exemple l'@IP 10.8.0.1 si on utilise le protocole OpenVPN ou 10.2.0.0 si on utilise le protocole L2PT/IPSec. 172.16.0.0/255.240.0.0 : ce sous réseau est utilisé lorsque par exemple on gère des applications en conteneurs sous le logiciel "docker" mais pas que ... 192.168.0.0/255.255.255.0 : ce sous réseau est le plus communément utilisé comme réseau local. Cordialement oracle7😉

@kroumi Bonjour, Pour compléter le propos, la seule solution pour supprimer l’information HSTS du navigateur lors d'une activation par erreur de HSTS sur le NAS, il faut vider le cache HSTS du navigateur, pour réaliser cela : Dans Chrome, taper chrome://net-internals/#hsts Entrer le nom de domaine dans le champ texte de la section "Delete domain security policies" Cliquer sur le bouton Delete Entrer le nom de domaine dans le champ texte de la section "Query HSTS" Cliquer sur le bouton Query La réponse doit être "Not found" (non trouvé) Avec Safari, commencer par fermer le navigateur Effacer le fichier ~/Library/Cookies/HSTS.plist Rouvrir Safari Avec Firefox, fermez tous les onglets Ouvrir le menu de Firefox et cliquer sur Historique / Afficher l’historique. Rechercher la page dont vous voulez supprimer les préférences HSTS Effectuer un clic droit sur une des entrées lui correspondant Choisir Oublier ce site Cordialement oracle7😉

@mery Bonjour, Je ne suis basé sur ton profil et "Trouvé son contenu" et là : pas de présentation. Mais c'est pas grave, saches qu'il est plus facile d'adapter une réponse quand on sait qui on a en face, c'est tout. Sans garantie, essaies ceci : "rtsp://login:password@adresse_ip:554/onvif1" OU "rtsp://login:password@adresse_ip:554/live/ch00_1" Cordialement oracle7😉

@kroumi Bonjour, Pas de soucis, saches que t'a démarche d'analyse, compréhension des notions avant mise en œuvre est à mon sens excellente. Beaucoup d'autres, malheureusement, n'ont pas cette vision des choses. Cela dit, pour le HSTS saches que c'est une option pas du tout recommandée (voir le TUTO ReverseProxy) car c'est le navigateur qui enregistre cette information et il ne laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé (HSTS coché puis décoché). Si tu veux forcer le https, il vaut mieux passer par le fichier .htaccess via web station comme indiqué dans le TUTO. Cordialement oracle7😉

@mery Bonjour Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... As-tu regardé ici. Essaies à tout hasard avec l'option [Défini par l'utilisateur] au lieu de [ONVIF]. Cordialement oracle7😉

@kevin67130 Bonjour, ????? décidément j'ai du mal à te suivre .... ton écriture a du mal à traduire ta pensée. As-tu utiliser le logiciel WinNUT (sur Windows) pour piloter ton onduleur ? Si Oui, pour mieux comprendre ce qui se passe, peux-tu faire une copie d'écran de WinNUT? et fournir ton fichier "C:\Program Files (x86)\WinNUT\upsmon.conf" (t'inquietes pas il n'y a rien de secret dans ce fichier !). Cordialement oracle7😉

@kevin67130 Bonjour, Fait la somme en Watt des puissances consommées actuellement (à la vue de ta photo) de chacun de tes équipements branchés sur ton onduleur donne 126 Watt (ce qui est très peu !), donc tu divises ces 126 W par 0,66 et tu obtient l'équivalent en VA soit 190 VA. Compares ces 190 VA à tes 1600 VA de ton onduleur et tu te rendras compte que cela correspond en gros à une barre sur ton indicateur. Donc au final tout est normal !!! Pas la peine de te prendre plus la tête. Là il faut que tu reformules ta phrase car je ne comprends pas du tout ce que tu veux dire 🤔 Cordialement oracle7😉

@kroumi Bonjour, Si je peux me permettre, ton jugement sur le TUTO en question est bien sévère. Un très grand nombre de membres ont mis en œuvre ce TUTO sans aucun problème aussi je le défendrai ici. Au moins lui, a l'avantage d'être complet, ce n'est pas le cas de celui que tu cites. Malheureusement, bon nombre des problèmes rencontrés par certains ont bien souvent pour origine d'autres paramétrages dans DSM qui viennent à l'encontre de la mise en place correcte du reverse proxy (cela passe par du NAT mal fait dans la box/routeur, du changement de ports standards, des ouvertures/fermetures de ports mal appropriées et j'en passe et des meilleures ...). Avant de se jeter sur le TUTO, il faut a minima se renseigner sur les notions mises en oeuvre et parfaitement les assimiler sinon on fait des choses sans en comprendre les tenants et aboutissants et là, c'est la porte grande ouverte vers toute sorte de déboires, déceptions et jugements hâtifs. Cordialement oracle7😉

Bonjour, @pierre1331 et @brunaliax Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassurez-vous il n'est pas trop tard pour bien faire ... @brunaliax Ne te serais-tu pas trompé en saisissant l'@MAC de tes caméras et inversé les choses lors de la création du bail statique DHCP ? De plus, via le logiciel constructeur de tes caméras, sont-elles bien déclarées en DCHP automatique ? @pierre1331 Ta caméra fonctionne certainement comme beaucoup d'autres, soit en 100 Mbits, aussi le port de ta bbox (malgré qu'il soit Gbits) s'adapte à ce périphérique et le signale en clignotant ou s'allumant en fixe orange. C'est donc normal ! Pas de voyant orange allumé lorsque le port fonctionne en Gbits avec des périphériques eux mêmes en Gbits. Cordialement oracle7😉

@TuringFan Bonjour, Si j'étais toi (en supposant que tes 3 clés OVH sont bien sauvegardées) : AVANT toutes choses ! Vérifier qu'il n'y a pas d'usage de caractères "exotiques" dans les identifiants et MdP sinon à corriger impérativement. Pas la peine de réinstaller acme.sh. Faire éventuellement un update et sauf si vraiment tu as un doute, alors désinstalles (cf google) et réinstalles acme.sh selon le TUTO. Nettoyer avec le script et l'option "-c" (acme.sh doit être opérationnel). Supprimer dans DSM le certificat et toutes les anciennes instances de celui-ci après avoir sauvegarder les fichiers "*.pem" correspondants pour le cas où. Supprimer aussi les répertoires "ndd.tld" et "Acme_renew" dans "/volume1/Certs". On conserve les répertoires "/volume1/Certs" et "/volume1/Scripts". Reprendre le processus au début sauf la partie chez OVH (§ 3.1 uniquement) MAIS ne pas omettre l'exportation des variables d'environnement (à tous les niveaux du processus !). Si certaines actions semblent avoir déjà été faites dans les tentatives précédentes, bien s'assurer qu'elles sont conformes aux attendus. Voilà j'espère ne rien avoir oublié. Cela peut paraître radical mais après, cela devrait le faire normalement si tu es très attentif à tes actions. Prends ton temps et assures-toi de chaque action avant de passer à la suivante. Si besoin lis et relis le TUTO... Je ne peux te dire mieux. Cordialement oracle7😉

@TuringFan Bonjour, Il y a un retour à la ligne en trop. Vérifies ce répertoire. Pas ce caractères "exotiques" dans les identifiants et MdP ainsi que les noms de fichiers : UNIX n'aime pas du tout ... Lors de ta dernière tentative le certificat avait été renouvelé (voir le premier log où je m'était "planté") donc la prochaine date de renouvellement annoncée est normale et il est normal qu'il te dise "Inutile de renouveler le certificat". Toutefois, le processus de cette tentative qui avait renouvelé le certificat, ayant avortée avant la fin, certaines opérations de déploiement n'ont pas été prise en compte et ton NAS indique certainement toujours la date de l'ancien certificat. Attention aussi au nombre de tentatives de renouvellement déjà effectuées pour la présente semaine ! Le max autorisé est de 5, au delà tu seras bloqué pour une semaine par LetsEncript. Donc utilises l'option "-f" avec parcimonie ... Cordialement oracle7😉 @TuringFan Bonjour Le script Python ne modifie pas le fichier account.conf, il ne fait que le lire par contre seul acme.sh lui le modifie. D'où ton erreur est franchement bizarre ... A moins que @bruno78 n'ai une idée ? Cordialement oracle7😉

@TuringFan Bonjour, Commence par vérifier que tu n'utilises pas de caractères "exotiques" dans ton Id et MdP. Regardes le contenu du fichier "/volume1/Certs/ndd.tld/ndd.tld.conf" et vérifie la cohérence des données. Tu devrais avoir notamment ces lignes : SAVED_SYNO_DID n'est présente que si tu as activé la double authentification SAVED_SYNO_Certificate ici est un exemple Tout cela couplé aux autres définitions de variables d'environnement contenues dans le fichier "/usr/local/share/acme.sh/account.conf" dont il te faut vérifier la cohérence. Cordialement oracle7😉

@TuringFan Bonjour Une fois connecté SSH sous root tu tapes simplement "python3 /volume1/Scripts/acme_renew.py -c ndd.tld" pour effectuer un nettoyage. Cordialement oracle7😉

@TuringFan Bonjour, Tu as dû relancer le processus à un moment ou un autre, je ne vois que cela comme explication en première approche. Normalement oui mais au cas où sauvegarde la clé. Normalement, ta connexion SSH avec PuTTY doit se faire avec le vrai 'root' et pas autre chose sinon tu auras d'autres problèmes. C'est expliqué dans le TUTO et cela été un des premiers problèmes découverts avec celui-ci. Cordialement oracle7😉

@TuringFan Bonjour Sauf erreur de ma part, à la vue du log acmelog, tu as mis le doigt dessus, le message est clair. Donc ton problème semble venir du fait que dans le processus de création du certificat, tu as dû omettre d'exporter la variable d'environnement OVH_CK (voir §3.2 du TUTO) : $ export OVH_CK="votre consumer key" Regardes dans le fichier "/usr/local/share/acme.sh/account.conf" où elle est normalement sauvegardée par le système, tu devrais avoir une ligne du type : où 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' est la clé 'Consumer Key' que tu as générée au § 3.1 du TUTO et que tu as normalement sauvegardée précieusement par ailleurs sur ton PC/Mac. S'il cette ligne n'existe pas, alors ajoutes là au fichier account.conf (attentionà la syntaxe : "simples cotes" et pas de guillemets !) et enregistres le fichier. Relances alors la procédure de renouvellement. Cordialement oracle7😉

@TuringFan Bonjour Comme d'habitude : ndd.tld, @IP externe, éventuelles clés OVH, Identifiant, MdP, etc ... Cordialement oracle7😉

@TuringFan Bonjour Et moi qui t’invites à relire attentivement le TUTO ! 😟 Désolé, je suis confus, j'ai analysé bien trop rapidement ton Log. J'ai en fait focalisé sur les options utilisées et sur "-- Le certificat n'a pas ete renouvele." . Heureusement que @bruno78 est passé par là pour remettre les pendules à l'heure !!! Grand merci à lui. 👍 Par ailleurs, je n'ai pas percuté vis à vis du fichier "acmelog" car comme il y a pas mal de temps j'ai fait le ménage, ce fichier n’apparaissait plus dans mon répertoire "Acme_renew" et trop rapidement j'ai basé ma réponse sur cette absence. Effectivement, maintenant il faut examiner en détail ce fichier "acmelog" pour trouvé l'origine de ce non renouvellement. Envoies le nous STP ... Cordialement oracle7😉

@TuringFan Bonjour et bon retour Pas grave mais STP ne postes pas deux fois la même réponse dans deux posts différents. Un seul suffit ... Supprimes l'autre. Manifestement tu as lancé le script manuellement avec juste le paramètre "-l". Ton certificat n'a pas été renouvelé justement parce que la date de renouvellement n'est pas encore atteinte. Si tu veux vraiment le renouveler avant cette date (mais ce n'est pas utile à mon avis) utilises l'option "-f". Pour le problème Python si tu lances le script avec la commande "python acme_renew.py - l ndd.tld" c'est la version 2.7.X de Python qui est utilisée MAIS si tu exécute la commande "python3 acme_renew.py - l ndd.tld" c'est la version 3.x de Python qui sera utilisée. Tu as lu trop vite le TUTO .... 🤪 Si tu as installé la dernière version v1.44 du script : Non il n'y a plus de concaténation des logs et Oui il n'y a plus qu'un log par exécution du script. Le log de la dernière exécution est dans le fichier "/volume1/Certs/Acme_renew/acme_renew_python.log.1" . Tu as dû consulté une ancienne version du fichier log. Je t'invites donc pour éviter toutes confusions à lancer le script avec l'option "-c" afin de faire un bon nettoyage de tous les fichiers inutiles (dans une console PuTTY et surtout pas dans une console WinSCP -> voir avertissement dans le TUTO à ce propos). Dans tous les cas, je t'invites à relire le TUTO intégralement et attentivement pour bien prendre en compte toutes les modifications qui y ont été apportées depuis la version initiale. Cordialement oracle7😉

@cotp Bonjour, Si tu ne maitrises pas ces notions, il est peut-être plus sage de partir sur du "standard" soit SHR-BTRFS. Perso, j'ai cela et cela me convient très bien pour une utilisation courante du NAS. Mais ce n'est que mon avis ... Cordialement oracle7😉

@.Shad. Bonjour, Bah Oui, effectivement cela marche tout de suite mieux en mettant dans agent l'@IP du NAS sur le réseau bridge. En tout cas Merci. Maintenant je continue de me battre avec les requêtes grafana. Pas simple, même quand on connait SQL ... Cordialement oracle7😉

@.Shad. Bonjour, Oui, j'ai mis à un moment cela : afin d'afficher des infos de mes deux NAS en regard l'une de l'autre (pour avoir tout dans un même écran quoi ...) puis j'ai supprimé pour le second NAS mais même punition : toujours seul les infos du second sont récoltées. Pb de droits quelque part sur le premier NAS ? J'ai revérifié le fichier "telegrah.conf" que j'ai "allégé" au passage, je te le joins pour avis : telegraf.conf Mais toutes mes requêtes grafana me revoient toujours les infos liées à mon second NAS en 192.168.2.11. Le premier (et support de docker and co) n'apparait même pas lors que je sélection le champ "sysName" tout simplement et j'ai toujours cette erreur qui boucle (journal telegraf) : Pour le coup je suis complètement perdu. Est-ce que je réinitialise tout ? cela fera jamais que le n ième fois ... Edit : A ce propos, à chaque réinitialisation je perd les règles docker dans le pare-feu, c'est normal docteur ? Cordialement oracle7😉

@.Shad. Bonjour, Pour commencer à m'initier à grafana et voir comment cela s'articule, j'ai installé la dashbord préconisée (celle de Yann Bizeul). Là un truc qui va pas : sans rien avoir modifié dans la requête qui donne de N°de serie du NAS (en principe l'hôte ou est installé docker and cie) en fait il m'est retourné le N° de série de mon second NAS sur le réseau local. J'ai pourtant bien renseigné le telegraf.conf avec "agents = [ "@IPduNAS" ]" dans la partie INPUT PLUGINS. Par ailleurs dans le log de influxdb (détail conteneur sous docker) je suis envahi d'erreur elles que : et dans le log de telegraf j'ai ceci : D'où mon incompréhension. Une idée peut-être car je ne sais pas décrypter ces messages ? Cordialement oracle7😉

@Jura39 Bonjour, Sauf erreur de ma part, je serais étonné que ton application multiroom fonctionne sur ton smartphone. Alors que DSAudio, au même titre de DSFiles te permet (depuis l'extérieur ou en local) d’accéder à tes fichiers stockés sur ton NAS, te permet, elle, d'accéder à ta musique stockée sur ton NAS et ainsi de l'écouter sur ton smartphone. Voilà l'avantage de DSAudio. Maintenant peut-être que ton application multiroom est capable de se connecter à ton NAS via ton réseau local. A voir et lire la doc de celle-ci pour la configurer. Cordialement oracle7😉