Je rencontre un comportement étrange avec ma nouvelle vanne d’arrosage Zigbee Sonoff SWV-ZFE intégrée sous JeeZigbee (z2m) dans Jeedom.
Le problème : Quelle que soit la durée ou le volume que je programme (via scénario ou manuellement), la vanne se coupe systématiquement après exactement 10 minutes de fonctionnement. Si je la relance immédiatement, elle repart pour 10 minutes, puis coupe à nouveau.
Ce que j’ai déjà testé :
J’ai essayé de modifier les curseurs (fail_safe, irrigation_duration et irrigation_amount) sur le Dashboard.
Les curseurs semblent revenir à 0 ou à leurs valeurs par défaut dès que je quitte la page (probablement lié au fait que la vanne est en mode « Sleepy End Device »).
J’ai vérifié les logs du scénario : Jeedom envoie bien l’ordre ON et ne coupe pas l’eau avant la fin, c’est bien la vanne qui se coupe physiquement de son côté.
J’ai accédé à l’interface Zigbee2MQTT (z2m) pour tenter de forcer les paramètres dans le bloc manual_default_settings.
Informations techniques :
Vanne : Sonoff SWV-ZFE
Plugin : JeeZigbee (z2m)
Jeedom : v4.5.3
J’ai l’impression qu’une sécurité matérielle d’usine (Fail Safe) est bloquée à 10 minutes, mais je n’arrive pas à rendre cette valeur persistante dans la mémoire interne de la vanne.
Est-ce que l’un d’entre vous a déjà rencontré ce blocage de 10 minutes sur ce modèle de vanne Sonoff et a réussi à le lever définitivement ?
When setting the state to ON, it might be possible to specify an automatic shutoff after a certain amount of time. To do this add an additional property on_time to the payload which is the time in seconds the state should remain on. Additionally an off_wait_time property can be added to the payload to specify the cooldown time in seconds when the switch will not answer to other on with timed off commands. Support depends on the switch firmware. Some devices might require both on_time and off_wait_time to work Examples : {"state" : "ON", "on_time": 300}, {"state" : "ON", "on_time": 300, "off_wait_time": 120}.
Il y a un paramètre par défaut qui coupe la vanne au bout de 30 minutes (j’ai vu 10 minutes dans ton cas mais cela peut tout de même valoir le coup de regarder) si elle ne détecte pas suffisamment d’eau “auto_close_when_water_shortage”. Il suffit donc d’afficher la commande “auto_close_when_water_shortage off” et de cliquer dessus pour désactiver ce paramètre (attention le module doit être en version 1.0.4, dans mon cas il a fallu faire une mise à jour OTA).
Je viens d’acheter la même vanne et j’avais le même problème. Et impossible de modifier les valeurs des commandes d’arrosage manual. Par exemple, si je modifiais la valeur de manual_irrigation_mode, j’avais des erreurs côtés Z2M :
Du coup j’ai créé une commande qui envoi des valeurs pour toutes les options nécessaire (récupérées via les messages d’erreurs côté Z2M) et qui allume la vanne (pas indispensable d’allumer la vanne en même temps je pense) :
L’arrosage a démarré et s’est bien arrêté au bout de 30 minutes après avoir lancé cette commande. Et je me suis rendu compte qu’une fois cette commande lancée, je pouvais maintenant envoyer chaque commande unitairement et elles étaient bien prise en compte côté Z2M. J’ai pigé après coup que pour que l’envoi de commande fonctionne, il faut que le bloc manual_default_settings soit initialisé avec toutes ces options (on peut le voir dans l’onglet Etat sur Z2M une fois qu’on a lancé la commande). J’imagine que par défaut fail_safe est réglé sur 10 minutes, d’où la coupure au bout de 10 minutes.
Ce problème est en fait présent pour tous les autres blocs car si j’essaye de modifer la valeur de irrigation_plan_interval_duration, j’ai l’erreur “zhc:sonoff: irrigation_plan_settings invalid enable_date, expected local date in YYYY-MM-DD format.” côté Z2M. J’imagine qu’il faut envoyer une commande json pour initaliser le bloc irrigation_plan_settings avec enable_date et interval_duration pour que cette commande fonctionne.
Je ne sais pas si ce problème des blocs pas initialisés vient de Z2M qui n’arrive pas à récupérer ces valeurs par défaut ou de la vanne qui ne les envoie jamais à Z2M.