henri-allauch

J'ai un relai 220V qui détecte les coupures de secteur. Il agit sur une entrée d'un smart implant ( Alimenté comme la HC3 sur un Onduleur ) Hier sur une micro-coupure (1 seconde) l'évènement n'a pas été détecté par mon QA dans les refreshstates donc son traitement d'information n'a pas abouti. Je sais que la coupure à eu lieu pour 2 raisons. Premièrement l'onduleur indépendamment de la HC3 m'a informé. Deuxièmement Comme j'ai 2 compteurs ENEDIS j'ai le même principe de détection sur un autre smart implant , l'événement sur ce ce second équipement à lui parfaitement fonctionné. Pourtant ce système à déjà fonctionné et fonctionne sur test quelques heures après l'incident. Ce qui ressort de mes traces, c'est que ma boucle refreshstates n'a pas trouvé l'évènement de ce device ... pourquoi ? Eh bien ce qui à de curieux c'est que dans le dashboard l'évènement est bien signalé sous l'icône du device du SmartImplant ( 1h 52mim il y a ... ) correspondant au moment de la coupure mais dans l'historique il n'y a pas d'évènement sur ce device ...

OK donc bien un pb de permissions. Je ne connais pas les syno et leurs outils. j'utilise bestialement mkdir et chmod ... Je suis sur serveur apache 2.4 et php8.3 sur linux, les fichiers et répertoires sont effectivement dans cet environnement serveur web puisque créés par .php C'est pour cela que j'ai indiqué au début de ce post de créer le répertoire et de donner les droits en écriture. Ce php au départ, fait pour un usage perso, aurait mérité plus de contrôles ... mais je me suis contenté d'interpréter les messages d'erreur du php. Tu as trouvé une solution, ça fonctionne c'est le principal bravo A+

Le répertoire SaveHc4 que tu as désigné pour recevoir les sauvegardes est il existant ? et a t'il les droits en écriture je pense que le problème est là

C'est peut-être une solution de contournement car sur le web plusieurs utilisateurs de Grafana cherchent une solution pour un Group by Month

Peu-être M time HH :mm :ss[.nnnnnnn] date yyyy-MM-dd

La doc DIT : Pourquoi mon chauffe-eau Linéo doit-il être alimenté en continu sans les heures creuses ? Pour un fonctionnement optimal, un chauffe-eau plat de la gamme Linéo doit être alimenté en continu, et donc ne pas être raccordé à un système couplé aux heures creuses. De la même façon que vous ne débranchez pas votre télévision, cette gamme de chauffe-eau doit rester continuellement sous tension dans leur utilisation au quotidien. En effet, si vous passez par un fonctionnement en heures creuses ou avec une horloge, l’appareil ne sera plus alimenté en continu. Vous perdez alors le bénéfice de plusieurs fonctions intégrées dans le produit : Vous n’avez plus la visualisation du nombre de douches disponibles (perte de l’affichage). En mode automatique, après chaque coupure prolongée la chauffe se fera systématiquement à la température la plus élevée et vous perdez ainsi l’optimisation de la production d’eau chaude en fonction de votre consommation qui est réalisée sur deux semaines complètes d’utilisation. Ce calcul va disparaitre à chaque coupure de courant. La capacité de production d’eau chaude reste limitée au volume de stockage et peut vous obliger à faire régulièrement des marches forcées manuelles. Sur un produit connecté avec l’application Cozytouch, lorsque l’appareil n’est plus sous tension, vous n’avez plus d’interaction possible. En particulier la fonction Boost, utile si vous souhaitez une chauffe complète de votre ballon. L’optimisation de la production d’eau chaude en fonction de votre consommation est réalisée sur deux semaines complètes d’utilisation. Le calcul va disparaitre à chaque coupure de courant. Les coupures répétées peuvent fragiliser les cartes électroniques qui ont été conçues pour un fonctionnement en continu. La consommation de ces cartes reste très faible et la relance d’une chauffe se fait en cas de besoin à partir d’une sonde en fonction de l’utilisation de l’eau chaude. A mon AVIS : C'est essentiellement la perte de l’optimisation de la production d’eau chaude pour laquelle il font une Mise en GARDE

OK c'était donc un cas particulier, le système ACI est donc prévu pour des coupures. Donc dans tous les cas les coupures de 16 heures sont donc possibles, mais pas conseillées pour les chauffe-eau "dit intelligent" qui perdent donc la mémorisation des usages quotidiens.

Le dernier jour rouge de 2024-2025 est passé. Perso je renouvelle malgré une réduction / tarif de base moins généreuse. Pour mon utilisation, ce sera tout de même un gain de 10% par rapport au tarif de base ça reste non négligeable. Jusqu'a présent j'utilise pour mon chauffe-eau "connecté" (Atlantic-Linéo 120L) la mise en absence pour la période 6-22 jour rouge. C'est une commande par le cloud cozytouc, çà fonctionne "presque toujours" . Ce chauffe-eau ne me semble pas être ACI (rien vu sur les documents) mais ils précisent de le laisser sous tension 24/24 et de couper le J/N si présent sur l'installation électrique. Je comprend puis qu'il y a une mémorisation sur une semaine qui permet de chauffer l'eau en fonction de l'utilisation habituelle et de réaliser des économies ... Mais y a t'il vraiment un risque à part de perdre la fonction "mémo-économique" de couper son alimentation 220, par un relai fermé au repos (commandé par un FGS-224) les 24 fois 18 heures rouges. J'ai bien compris ces coupures sont à proscrire avec les cumulus ACI .Mais est-ce pour éviter des charges/décharges de batteries, ou éviter des coupures sur les cartes électronique ?

ok c'est noté mais n'oublie pas de nous le rappeler ...

Quel est le status de nos finances ? Quel est le besoin financier complet pour 2025 ? Nous sommes là pour participer aux frais .

Je ne suis pas du tout spécialiste de Haproxy, mais en suivant le tutoriel de @mprinfo je suis arrivé à une configuration qui fonctionne. J'accède par: https://domlinux.MonDomaine.fr/domocharts/index.php aux graphiques ... SI cela peut t'aider .... #************************************************************************************ # Déclaration HAPROXY #************************************************************************************ global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon maxconn 2048 # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/privatte # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). This list is from: # https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ # An alternative list with additional directives can be obtained from # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 tune.ssl.default-dh-param 2048 defaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http # ------------------------------------------------------------------------ # - H T T P # ------------------------------------------------------------------------ frontend http- option http-keep-alive compression algo gzip compression type text/html text/plain text/css application/x-javascript bind *:80 mode http option httplog acl letsencrypt-acl path_beg /.well-known/acme-challenge/ #********************************** # Define hosts http MonDomaine #********************************** acl domlinux hdr(host) domlinux.MonDomaine.fr #********************************** # Forcer Redirection vers Https #********************************** redirect scheme https if !{ ssl_fc } domlinux use_backend letsencrypt-backend if letsencrypt-acl default_backend backend_DEFAULT # ------------------------------------------------------------------------ # - H T T P S # ------------------------------------------------------------------------ frontend https-in bind *:443 ssl crt /etc/haproxy/certs/ no-sslv3 mode http option httplog acl letsencrypt-acl path_beg /.well-known/acme-challenge/ #******************************************************** # Define hosts https MonDomaine #******************************************************** acl domlinux hdr(host) domlinux.MonDomaine.fr #******************************************************** # Use backend #******************************************************** use_backend backend_DOMLINUX if domlinux use_backend letsencrypt-backend if letsencrypt-acl default_backend backend_DEFAULT # ------------------------------------------------------------------------ # - Define backend # ------------------------------------------------------------------------ #--------------------- Backend pour le renouvellement du certificat letsencrypt backend letsencrypt-backend server letsencrypt 127.0.0.1:8888 #--------------------- Backend pour DOMLINUX backend backend_DOMLINUX mode http option httpchk option forwardfor except 127.0.0.1 http-request add-header X-Forwarded-Proto https if { ssl_fc } server DOMLINUX 192.168.82.8:5080 maxconn 15 #--------------------- Backend pour DEFAULT backend backend_DEFAULT http-request deny

S'il s'agit bien de Monsieur Boris D. : on peut dire qu'il à toujours été très correct, compréhensif, et compétent. Je luis souhaite plein de succès en récupérant les clients Que domotique-store à fait fuir.

Ton message est rassurant Merci beaucoup. Oui je suis d'accord en médecine c'est pareil avec les moyens actuels on trouve toujours un truc qui va pas. Je vais arrêter de me poser des questions à ce sujet et dormir sur mes deux oreilles ...

Merci moi non plus je ne connais pas les détails du réseau. Mais je suis tombé sur ce problème par hasard . Le fonctionnement global du réseau n'est pas perturbé. Je changerai bien mes centaines de mètres de câbles ... mais c'est un chantier colossal.

Effectivement j'ai des câbles installés il y a plusieurs années et il ne sont certainement pas au top. Mais je ne comprend pas : quand la machine dit X paquets dropped. C'est sur des paquets qui lui sont destinés ou sur l'ensemble des paquets du réseau. Je penche pour le cas 1 puisque ifconfig dit RX donc reçus Dans ce cas avec un cat 6 je ne devrais plus ( ou moins ) avoir d'erreur en connexion directe sur la box. ( La livebox 6 Orange peut elle être en cause ?)