Dimmer commence à router avant la connexion à la sonde Dallas

[brenard]

En version 20240603 (SSR ZC), le dimmer commence à router avant la connexion à la sonde Dallas. Quand on a des soucis de connexion avec la sonde dallas, cela peut conduire à une surchauffe. Ce serait mieux pour moi que le dimmer attende d'avoir une première remontée de température avant de commencer à chauffer.

Vu que le dimmer doit aussi pouvoir fonctionner sans sonde dallas, on pourrait imaginer que lorsqu'on saisit une adresse de sonde dans le champ Adresse sonde DALLAS maitre, le dimmer s'attende à avoir une sonde et de ce fait, ne commence à chauffer qu'une fois la sonde connectée. Je ne sais pas si c'était l'idée de ce champ et je vois pas trop à quoi il pourrait servir autrement :smile:

PS : je m'en suis rendez-compte après des soucis de connexion des sondes qui ont pourtant fonctionné des mois avant sans souci. J'ai eu beau refaire les raccords plusieurs fois, un des dimmers finissait toujours par perdre la connexion avec sa sonde après quelques heures/jours. Au final, je viens de souder les sondes sur les cartes en espérant que sa règle définitivement ces problèmes de connexion. Je me dis d'ailleurs qu'un connecteur JST serait plus fiable à ce niveau (comme pour le SSR).

[xlyric]

Salut, c'est un fonctionnement normal comme la dallas n'est pas obligatoire pour fonctionner. Cependant , (même si ça reste une bonne idée) :

• si la dallas est reconnue puis se déconnecte, le dimmer se met en sécurité et se coupe
• le champs sert dans le cas où l'on met plusieurs dallas ( actuellement jusqu'a 8 ) et ça permet de définir la dallas maitre qui controlera le dimmer, les autres ne servent qu'a faire des remontés HA ( MQTT )

pour les dallas, le pb c'est qu'elles ne sont pas vendu en version JST et donc une contrainte pour l'utilisateur si il doit souder sa sonde.

[brenard]

OK, je vois. Mais du coup, il faudrait une sécurité équivalente au boots du dimmer. Aujourd'hui, c'est tout de même un vrai danger ! Si la sonde se déconnecte, au moindre reboot, le ballon va chauffer indéfiniment jusqu'au déclenchement d'une sécurité extérieur en espérant qu'il y en a une 😬

Si c'est pas l'adresse le point déterminant, il faudrait peut être une option qui précise que la chauffe est conditionnée à la présence d'une sonde de température ?

[xlyric]

c'est pas déconnant, ça sonne bien, faut que je vois comment faire le truc sans que ça impacte trop tout le monde. en gros par defaut à l'upload une valeur de la master à null et si une fois il y a une dallas, alors la valeur prends et garde automatiquement l'adresse de la dallas et du coup reste configuré au prochain reboot...

[brenard]

c'est pas déconnant, ça sonne bien, faut que je vois comment faire le truc sans que ça impacte trop tout le monde. en gros par defaut à l'upload une valeur de la master à null et si une fois il y a une dallas, alors la valeur prends et garde automatiquement l'adresse de la dallas et du coup reste configuré au prochain reboot...

Ça aurait effectivement l'avantage d'être automatique comme solution. Pour moi, tant qu'on peux avoir une sécurité sur ce cas de risque de surchauffe, c'est top !

[brenard]

Je viens de tomber sur un nouveau cas de risque de surchauffe : je viens d'avoir une coupure de courant chez moi et quand le courant est revenu, le ballon s'est rallumé mais pas ma machine qui héberge le MQTT. Tant que les dimmers n'ont pas réussi à contacter le MQTT, leur sonde de température n'était pas détectée et ils ont commencé à router "à l'aveugle". J'ai tenté des reboot des dimmers, mais rien à faire, les sondes ne montaient pas et les logs bouclaient sur les tentatives de connexion MQTT. Dès que mon service MQTT était à nouveau dispo, les dimmers s'y sont connectés et ils ont récupéré leurs sondes de température immédiatement ensuite.

Ça laisse penser que si le dimmer n'arrive pas à se connecter au service MQTT, il ne tente pas de se connecter à sa sonde dallas. La même situation, si je n'avais pas été chez moi pour relancer mon MQTT, aurait pu conduire à une surchauffe.

[xlyric]

étrange, mais intéressant, je vais tester ce genre de cas spécifique,

[xlyric]

je viens de tester et je vois bien dans la console serial, la sonde dallas être reconnu, elle est aussi reconnu coté web, et j'ai tenté une mise en sécurité, ça fonctionne bien, ça a coupé le dimmer, même si dans les logs ça hurle à la mort comme quoi le MQTT n'est pas connecté :

Connecting to MQTT...dimmer-0788 Connecting to MQTT...dimmer-0788 Dimmer2 Off dimmer 1: 0% dimmer 2: 0% dimmer 3: 0% Connecting to MQTT...dimmer-0788 Connecting to MQTT...dimmer-0788

[brenard]

Mon problème était lors du boot du dimmer alors que mqtt n'était pas dispo. C'est bien ce que tu as testé ? Dans le logs, j'avais des tentatives de connexion mqtt (infructueuses) mais rien au niveau des sondes. Elles ont été détectées qu'une fois la connexion mqtt établie.

[xlyric]

oui, c'est ça, j'ai changé l'ip par une bidon, sauvé et rebooter. dans mon sérial, j'ai bien vu la détection et la dallas marche et apparait dans l'interface. j'ai mis une temps max à 30° avec puissance à 100% et mis la dallas dans la main. ça a coupé arrivé à 30° et oui, pas de mqtt donc rien d'indiqué dans les logs. ( je vérifierais si au moins ça affiche certains trucs )

[brenard]

Étrange, je viens de tester à nouveau chez moi et je reproduis bien le problème avec le même test que toi.

J'ai également testé de laisser la bonne IP, mais de stopper mosquitto avant de lancer un reboot. Le dimmer boucle sur ses échecs de connexion MQTT et dès que je relance mosquitto, il s'y connecte et la sonde est détectée :

Au passage, comment fonctionne la reconnexion MQTT, car j'ai vu que mes dimmers ne s'y reconnectait pas automatiquement après un plantage de mon serveur MQTT (son SSD à trinquer lors de la coupure de courant d'hier…). Je suis obligé de les rebooter manuellement pour qu'il se reconnecte au service MQTT.

Edit : j'avais saisi l'adresse de ma sonde Dallas dans le champ Adresse sonde DALLAS maitre. Je viens de tester de la supprimer pour voir si cela avait un rapport, mais non, je reproduis toujours le problème avec un arrêt de mosquitto avant reboot :

[xlyric]

étrange, c'est comme si la dallas n'avais pas le temps de répondre pendant cette période. encore des dallas pourries ? je retesterais lundi

[brenard]

étrange, c'est comme si la dallas n'avais pas le temps de répondre pendant cette période. encore des dallas pourries ? je retesterais lundi

Difficile à dire, mais je dirais que non... J'en ai changé un qui posait problème ces derniers jours et celui que j'ai remis est neuf, d'une commande différente des deux autres, et n'a posé aucun soucis jusque là. L'autre ne pose pas de problème non plus. Les deux sont soudés aux dimmers pour éviter tout problème de connexion. Quand le service MQTT est dispo au boot, les sondes se connectent rapidement au démarrage. Je reproduit le problème sur mes deux dimmers. Il y a un timeout fixe pour la connexion aux Dallas ?

[xlyric]

Je viens de faire les modifs si dimmer présent une 1er fois, alors il est automatiquement déclaré master. ensuite si à un reboot ou autre la sonde disparait, alors il y a une remontée MQTT et sur le site web. Ensuite pour les dallas pourrie je pense que certaines dallas sont perturbées par des interférences et répondent un peu plus lentement. j'ai corrigé qq trucs la dessus aussi.

faut test

[brenard]

Salut, j'ai déployé le dernier firmware dispo sur le site et mes dimmers ont détectés leurs sondes Dallas rapidement. C'était même un peu trop rapide pour que je puisse voir s'ils se mettaient en chauffe avant que la température remonte, mais, je n'ai pas l'impression. À voir sur le long terme, mais je penses que c'est pas mal du tout ! Merci !

[brenard]

Salut, ayant toujours des soucis de problème de reconnexion MQTT après coupure de courant et/ou indispo de mon service MQTT, j'ai tenté un màj du firmware (&FS) de mes dimmers et un des deux n'arrivent plus à trouver sa sonde Dallas. Dans les logs, des fois j'ai quelque chose du genre :

-- Reason for reset: 4 --
-- Version 20240701 --
Start filesystem 
FS version Ok
Load config 
Load config MQTT
Start Wifiautoconnect 
mDNS responder started 
dimmer-B128.local 
0 DALLAS detected
Alerte Dallas non trouvée
Attempting MQTT connexion 
Connecting to MQTT...dimmer-B128 
Connected to MQTT.
Connected to MQTT.
MQTT connected 
Connected to MQTT.
Connected to MQTT.
MQTT connected 
fin du demarrage: 01:01:05   
1 DALLAS detected
Dallas sensor 0 found. Address : 0000000000000000
01:01:29     Dallas0 : échec 1
01:01:38     Dallas0 : échec 2
01:01:46     Dallas0 : échec 3
01:01:53     Dallas0 : échec 4
01:02:01     Dallas0 : échec 5
01:02:10     Dallas0 : échec 6
Dallas0 : 0.00
01:02:10     Dallas perdue !!!
01:02:17     Dallas0 : échec 1
01:02:25     Dallas0 : échec 2
01:02:34     Dallas0 : échec 3
01:02:41     Dallas0 : échec 4
01:02:50     Dallas0 : échec 5
01:02:58     Dallas0 : échec 6
Dallas0 : 99.90
01:02:58     Dallas perdue !!!
01:03:06     Dallas0 : échec 1
01:03:14     Dallas0 : échec 2
01:03:21     Dallas0 : échec 3
01:03:30     Dallas0 : échec 4
01:03:37     Dallas0 : échec 5
01:03:46     Dallas0 : échec 6
Dallas0 : 99.90
01:03:46     Dallas perdue !!!

ou encore :

-- Reason for reset: 6 --
-- Version 20240701 --
Start filesystem 
FS version Ok
Load config 
Load config MQTT
Start Wifiautoconnect 
mDNS responder started 
dimmer-B128.local 
0 DALLAS detected
Alerte Dallas non trouvée
Attempting MQTT connexion 
Connecting to MQTT...dimmer-B128 
Connected to MQTT.
Connected to MQTT.
MQTT connected 
Connected to MQTT.
Connected to MQTT.
MQTT connected 
fin du demarrage: 01:05:58   
Alerte Dallas non trouvée
Alerte Dallas non trouvée
Alerte Dallas non trouvée

Je précise que je n'avais aucun souci avec la précédente version du firmware que j'utilisais (celui d'il y a trois semaines). Aurais-tu fait depuis des changements qui pénaliseraient les dallas un peu long à être détectés ?

Je laisse tourner pour voir s’il finit par la trouver, mais j'ai déjà pas mal attendu et fait des tests de reboot, sans succès pour le moment. L'autre dimmer lui n'a pas de souci, même si la sonde est peut-être un peu plus longue qu'avant à être détectée.

[xlyric]

j'ai effectivement remis la détection des dallas comme conseillé dans la librairie officielle. ( et pas une tambouille crade comme il y avait avant. le coup des Dallas sensor 0 found. Address : 0000000000000000

Remontre effectivement que la dallas, n'as pas communiqué en temps et en heure. ( et c'est souvent le cas avec des copies des dallas officielle. ) je vais rajouter un peu de temps entre la requete et la lecture

[xlyric]

je viens de pousser un correctif, j'ai rajouté des tempos .

[brenard]

je viens de pousser un correctif, j'ai rajouté des tempos .

Top merci. Je viens de tester et la sonde s'est connectée immédiatement. Pour info, elle avait finis par se connecter dans la nuit après quelques heures.

[brenard]

Salut, J’ai à nouveau des soucis au niveau de la connexion à une sonde dallas après un reboot d'un de mes dimmers. J'ai tenté d'augmenter la limite de 1500ms hard-codée au niveau du timeout de connexion à la sonde (& reset one-wire ensuite), mais j'arrive pas à construire ensuite le firmware à cause de l'erreur suivante :

Processing StandAlone (platform: espressif8266; board: d1_mini; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/d1_mini.html
PLATFORM: Espressif 8266 (1.3.0) > WeMos D1 R2 & mini
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES: 
 - framework-arduinoespressif8266 @ 1.20300.1 (2.3.0) 
 - tool-esptool @ 1.409.0 (4.9) 
 - toolchain-xtensa @ 1.40802.0 (4.8.2)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 38 compatible libraries
Scanning dependencies...
Dependency Graph
|-- ESP Async WebServer @ 3.0.6
|-- ArduinoJson @ 7.1.0
|-- PubSubClient @ 2.8.0
|-- ESPAsyncWiFiManager @ 0.31.0
|-- OneWire @ 2.3.8
|-- DallasTemperature @ 3.11.0
|-- RBDdimmer @ 0.0.0+sha.c3f1e99
|-- ElegantOTA @ 3.1.4+sha.ecdf53f
|-- Uptime Library @ 1.0.0+sha.fa29a94
|-- TaskScheduler @ 3.8.5
|-- NTPClient @ 3.2.1
|-- Time @ 1.6.1
|-- ESP8266-ping @ 2.0.1+sha.a9ab808
|-- ESP8266HTTPClient @ 1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS
|-- Ticker @ 1.0
|-- Wire @ 1.0
Building in debug mode
Compiling .pio/build/StandAlone/src/main.cpp.o
Compiling .pio/build/StandAlone/lib2a2/ESP8266WiFi/ESP8266WiFi.cpp.o
Compiling .pio/build/StandAlone/lib2a2/ESP8266WiFi/ESP8266WiFiAP.cpp.o
Compiling .pio/build/StandAlone/lib2a2/ESP8266WiFi/ESP8266WiFiGeneric.cpp.o
In file included from src/main.cpp:88:0:
.pio/libdeps/StandAlone/ElegantOTA/src/ElegantOTA.h:47:24: fatal error: LittleFS.h: No such file or directory

******************************************************************
* Looking for LittleFS.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:LittleFS.h"
* Web  > https://registry.platformio.org/search?q=header:LittleFS.h
*
******************************************************************

   #include "LittleFS.h"
                        ^
compilation terminated.
*** [.pio/build/StandAlone/src/main.cpp.o] Error 1

J'ai vu que tu avais fait des changements au niveau de l'OTA dernièrement, c'est potentiellement lié j'imagine (dépendance ou version de dépendance manquante?). Une idée ?

Sinon, serait-il possible d'augmenter la limite de 1500ms à quelques choses de bien plus important (genre 5000ms) ? J'ai vu que tu augmentais le timeout de connexion progressivement par pas de 100ms, donc en soit, cela ne devrait pas poser de souci pour les sondes dallas plus rapide.

Par ailleurs, sur ce dimmer, la chauffe débutait à nouveau avant la connexion du dallas alors que cela avait normalement été corrigé. J'ai dû le sortir de la configuration du routeur pour éviter toute surchauffe. Je précise que je suis en version 20240705 sur mes dimmers mais qu'ils affichent toujours 20240701 (même après une mise à jour avec le firmware dispo sur le site).

[brenard]

Sinon, serait-il possible d'augmenter la limite de 1500ms à quelques choses de bien plus important (genre 5000ms) ? J'ai vu que tu augmentais le timeout de connexion progressivement par pas de 100ms, donc en soit, cela ne devrait pas poser de souci pour les sondes dallas plus rapide.

À force de faire des mises à jours de mes dimmers lors de mes tests, j'ai fini par bloquer mes deux dimmers qui n'arrivaient plus à se connecter à leur sensor. J'ai eu beau faire des reboots soft et hard, rien à faire, ils ne voulaient pas se connecter. J'ai donc testé ce point en augmentant la limite du timer_dallas à 4000 :

if ( timer_dallas < 4000 )  { timer_dallas = timer_dallas + 100;  } // on augmente le timer pour la prochaine lecture

Ça a été radical : ils se sont tout de suite reconnecté tous les deux. Tu vois un problème à augmenter cette limite, car visiblement, 1500ms c'est trop peu pour des sondes comme les miennes…