Hello
J’ai un soucis sur le retour d’état de l’ouverture de la vanne en pourcentage … il reste bloqué à 25% … la vanne a l’air de fonctionner car je l’entend fonctionner et parce que l’info binaire d’état d’ouverture de la vanne (open ou closed) se met bien à jour.
Si je refais une calibration l’état en pourcentage va fonctionner qq jour puis bloquer à 25%
Avez vous le meme comportement avec cet équipement ?
@chris94440
Info => Zigbee2mqtt en version 1.28.4
Update:
D’apres le code de z2m (tuya.js et fromZigbee.js) … le dp a écouter pour maj de cette donnée est le 104
fromZigbee.js
case tuya.dataPoints.moesSreset:
return {running_state: value ? 'idle' : 'heat', valve_state: value ? 'CLOSED' : 'OPEN'};
case tuya.dataPoints.moesSwindowDetectionFunktion_A2:
return {window_detection: value ? 'ON' : 'OFF'};
case tuya.dataPoints.moesSwindowDetection:
return {window: value ? 'CLOSED' : 'OPEN'};
case tuya.dataPoints.moesSchildLock:
return {child_lock: value ? 'LOCK' : 'UNLOCK'};
case tuya.dataPoints.moesSbattery:
return {battery: value};
case tuya.dataPoints.moesSboostHeatingCountdownTimeSet:
return {boost_heating_countdown_time_set: (value)};
case tuya.dataPoints.moesSvalvePosition:
return {position: value};
tuya.js
moesSreset: 7,
moesSwindowDetectionFunktion_A2: 8,
moesSwindowDetection: 9,
moesSchildLock: 13,
moesSbattery: 14,
moesSschedule: 101,
moesSvalvePosition: 104,
moesSboostHeatingCountdownTimeSet: 103,
J’ai mis en place le niveau de log debug herdsman
Line 133: Zigbee2MQTT:debug 2022-12-08 13:38:05: Received Zigbee message from 'Z2M_Moes_Vanne_Thermostatique_SalleDeDouche', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,13],"type":"Buffer"},"datatype":2,"dp":2}],"seq":0}' from endpoint 1 with groupID 0
Line 167: Zigbee2MQTT:debug 2022-12-08 13:38:05: Received Zigbee message from 'Z2M_Moes_Vanne_Thermostatique_SalleDeDouche', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":4,"dp":7}],"seq":256}' from endpoint 1 with groupID 0
Line 341: Zigbee2MQTT:debug 2022-12-08 13:38:12: Received Zigbee message from 'Z2M_Moes_Vanne_Thermostatique_SalleDeDouche', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,29],"type":"Buffer"},"datatype":2,"dp":2}],"seq":1}' from endpoint 1 with groupID 0
Line 363: Zigbee2MQTT:debug 2022-12-08 13:38:12: Received Zigbee message from 'Z2M_Moes_Vanne_Thermostatique_SalleDeDouche', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":4,"dp":7}],"seq":257}' from endpoint 1 with groupID 0
Line 484: Zigbee2MQTT:debug 2022-12-08 13:38:20: Received Zigbee message from 'Z2M_Moes_Vanne_Thermostatique_SalleDeDouche', type 'commandDataResponse', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,18],"type":"Buffer"},"datatype":2,"dp":2}],"seq":2}' from endpoint 1 with groupID 0
Seuls les dp 2 et 7 sont présents … logique car j’ai touché à la consigne (dp 2 → moesSheatingSetpoint: 2) et cela a agit sur le dp7 (moesSreset: 7) qui indique si la vanne est ouvert et chauffe
case tuya.dataPoints.moesSreset:
return {running_state: value ? 'idle' : 'heat', valve_state: value ? 'CLOSED' : 'OPEN'};
Je vais voir en refaisant une calibration si le dp 104 (moesSvalvePosition: 104) est renvoyé par la vanne …
J’ai quand meme l’impression que c’est un soucis de firmware plus qu’un soucis dans z2m
