but the new version won’t have Z2M support yet, right?
I’ve had the new one for a couple of days. There’s a custom converter available for z2m until full support is available.
I haven’t tested it fully yet, but basic functionality is there.
All of the functionality should be there, it’s effectively the same as the QT06_2 at least software wise. It has a couple of extra DP values, like temperature and smart weather, but temperature always is reporting 0 on mine so I didn’t bother adding it.
Anyway, support has now been merged into the dev version, so should make its way through into the next release of zigbee2mqtt.
I have a couple of the earlier versions, and one of them would occasionally not turn off (due to a sticking valve). The new design apparently fixes that design flaw, and it does seem a lot more robust than the previous version (and smaller).
I see. [New device support]: GiEX Water Valve GX02 · Issue #21844 · Koenkk/zigbee2mqtt · GitHub Thank you
There does seem to be an issue where if the mode is set to capacity, and the Irrigation Target set to 0, that the switch will turn off immediately, which is not how the QT06 versions work… so I’ll take a look at why, and what a work around might be.
It doesn’t happen when the mode is set to duration and target 0, and since I control it by Home Assistant and the Smart Irrigation component, I’ve set it like that and it works as expected.
Here’s the link to Aliexpress where I ordered it: https://www.aliexpress.com/item/1005006547328147.html
I just received it today. It was in a very good packaging a bit hard to open the battery lid though. The build quality feels good.
It’s currently not supported by Zigbee2MQTT. So I’m trying to add support for this new device. I’ve send a mail to @Giex and awaiting them to reply with protocol information, so I can finalise the configuration. Once I completed I’ll share with you and do a MR to the Z2M project.
Z2m support has already been done. It’s in the dev branch and should be in the next release.
Hi, I bought also this 2024 model. I got it working via ZHA and modified quirk. But it has some connection issues. After few hours it drops of from zigbee network. Does anyone else have similar issues? Is someone working on official ZHA support?
Could you please share your ZHA quirk for this device please. I’m new on this topic.
This is what I have.
Works for a while then disconnects…
"""GiEX Tuya valve devices."""
import logging
from typing import Dict
from zigpy.profiles import zha
from zigpy.quirks import CustomDevice
import zigpy.types as t
from zigpy.zcl import foundation
from zigpy.zcl.clusters.general import (
Basic,
Groups,
Ota,
PowerConfiguration,
Scenes,
Time,
)
from zigpy.zcl.clusters.smartenergy import Metering
from zhaquirks.const import (
DEVICE_TYPE,
ENDPOINTS,
INPUT_CLUSTERS,
MODELS_INFO,
OUTPUT_CLUSTERS,
PROFILE_ID,
)
from zhaquirks.tuya import (
TuyaLocalCluster,
TuyaDPType,
)
from zhaquirks.tuya.mcu import (
DPToAttributeMapping,
TuyaAttributesCluster,
TuyaMCUCluster,
TuyaOnOffNM,
TuyaPowerConfigurationCluster,
)
# info from https://github.com/Koenkk/zigbee-herdsman-converters/blob/7ecea3b807ec7643493f94614e84d0343423267d/devices/giex.js
GIEX_TUYA_VALVE_MODE_ATTR = 0xEF01 # Mode [0] duration [1] capacity
GIEX_TUYA_VALVE_START_TIME_ATTR = 0xEF65 # Last irrigation start time (GMT)
GIEX_TUYA_VALVE_END_TIME_ATTR = 0xEF66 # Last irrigation end time (GMT)
GIEX_TUYA_VALVE_NUM_TIMES_ATTR = 0xEF67 # Number of cycle irrigation times, set to 0 for single cycle, min=0 max=100
GIEX_TUYA_VALVE_TARGET_ATTR = 0xEF68 # Irrigation target, duration in seconds or capacity in litres (depending on mode), min=0, max=3600
GIEX_TUYA_VALVE_INTERVAL_ATTR = 0xEF69 # Cycle irrigation interval in seconds, min=0, max=3600
GIEX_TUYA_VALVE_DURATION_ATTR = 0xEF72 # Last irrigation duration
_LOGGER = logging.getLogger(__name__)
class TuyaValveWaterConsumed(Metering, TuyaLocalCluster):
"""Tuya Valve Water consumed cluster."""
VOLUME_LITERS = 0x0007
"""Setting unit of measurement."""
_CONSTANT_ATTRIBUTES = {0x0300: VOLUME_LITERS}
class GiexTuyaValveManufCluster(TuyaMCUCluster):
"""GiEX Tuya valve manufacturer cluster."""
attributes = TuyaMCUCluster.attributes.copy()
attributes.update(
{
GIEX_TUYA_VALVE_MODE_ATTR: ("irrigation_mode", t.Bool, True),
GIEX_TUYA_VALVE_START_TIME_ATTR: ("irrigation_start_time", t.uint32_t, True),
GIEX_TUYA_VALVE_END_TIME_ATTR: ("irrigation_end_time", t.uint32_t, True),
GIEX_TUYA_VALVE_NUM_TIMES_ATTR: ("irrigation_num_times", t.uint32_t, True),
GIEX_TUYA_VALVE_TARGET_ATTR: ("irrigation_target", t.uint32_t, True),
GIEX_TUYA_VALVE_INTERVAL_ATTR: ("irrigation_interval", t.uint32_t, True),
GIEX_TUYA_VALVE_DURATION_ATTR: ("irrigation_duration", t.uint32_t, True),
}
)
dp_to_attribute: Dict[int, DPToAttributeMapping] = {
1: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_mode",
# dp_type=TuyaDPType.BOOL,
),
2: DPToAttributeMapping(
TuyaOnOffNM.ep_attribute,
"on_off",
# dp_type=TuyaDPType.BOOL,
),
101: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_start_time",
# dp_type=TuyaDPType.VALUE,
),
102: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_end_time",
# dp_type=TuyaDPType.VALUE,
),
103: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_num_times",
# dp_type=TuyaDPType.VALUE,
),
104: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_target",
# dp_type=TuyaDPType.VALUE,
),
105: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_interval",
# dp_type=TuyaDPType.VALUE,
),
108: DPToAttributeMapping(
TuyaPowerConfigurationCluster.ep_attribute,
"battery_percentage_remaining",
# dp_type=TuyaDPType.VALUE,
),
111: DPToAttributeMapping(
TuyaValveWaterConsumed.ep_attribute,
"current_summ_delivered",
# dp_type=TuyaDPType.VALUE,
),
114: DPToAttributeMapping(
TuyaMCUCluster.ep_attribute,
"irrigation_duration",
# dp_type=TuyaDPType.VALUE,
),
}
data_point_handlers = {
1: "_dp_2_attr_update",
2: "_dp_2_attr_update",
101: "_dp_2_attr_update",
102: "_dp_2_attr_update",
103: "_dp_2_attr_update",
104: "_dp_2_attr_update",
105: "_dp_2_attr_update",
108: "_dp_2_attr_update",
111: "_dp_2_attr_update",
114: "_dp_2_attr_update",
}
async def write_attributes(self, attributes, manufacturer=None):
"""Overwrite to force manufacturer code."""
return await super().write_attributes(
attributes, manufacturer=foundation.ZCLHeader.NO_MANUFACTURER_ID
)
class GiexTuyaValve(CustomDevice):
"""Tuya valve device."""
signature = {
MODELS_INFO: [
("_TZE200_sh1btabb", "TS0601"),
("_TZE204_7ytb3h8u", "TS0601")
],
ENDPOINTS: {
# <SimpleDescriptor endpoint=1 profile=260 device_type=0x0051
# input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
# output_clusters=[0x000a, 0x0019]>
1: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
INPUT_CLUSTERS: [
Basic.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
GiexTuyaValveManufCluster.cluster_id,
],
OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
}
},
}
replacement = {
ENDPOINTS: {
1: {
DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
INPUT_CLUSTERS: [
Basic.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
TuyaOnOffNM,
TuyaPowerConfigurationCluster,
TuyaValveWaterConsumed,
GiexTuyaValveManufCluster,
],
OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
}
}
}
@pamatika you are my hero. I’m using your quirk for a while now and I have no issues. I guess your connection problems are caused by some Zigbee network or Coordinator issues. I use SkyConnect and I have the current HA version 2024.4.
I have already checked to run it with Z2m, but had some pairing issues with a TI chip based Coordinator. What is your LQI? see my Device Info below.
Nice new info! i’m on that side of users, low pressure, as i use a water tank (1m3 size) it works with less sophisticated smart valves, but not with the GiEx ones (and I’ve got 4 of them)
Unfortunately there is no info about the internals so when buying such a valve you don’t know if it is good for low pressure or not (if is ball or solenoid valve). Is the new version, maybe, a ball valve?
Nice to hear it works. But I can`t take credits from that quirk. I found that from somewhere and just added new GIEX valve types to the quirk.
My Lqi is about 160 but still disconnects randomly. And lately it has started to reconnect also… randomly. Maybe there is some interference… need to do still some testing.
I get about 25l/min with our setup. So I guess it is some solenoid valve not ball.
Battery powered devices usually require min 1 bar. The water pressure is needed to switch the valve. A Solenoid would drain the battery very fast and a full ball valve would be expensive.
Ok an update related to your issue. I have to valves and one has frequent connections too. I placed a router beside the valves but it did only help for about 24h.
The problematic valve has a weaker battery about 70% SOC.
But new batteries did not solve the problem completely. I’m in contact with GiEX support now and they are trying to find a solution. Must be related to weakness in their design which shows up in using ZHA.
Anybody tried this with NiMh rechargeable 1.2v batteries per chance? Does it work?
Has been working fine for me. Haven’t had it that long, so can’t confirm how long they’ll last yet.
That’s great info thanks.
I am looking to buy an irrigation timer, all the feedback points to LinkTap. But I just can’t get over the fact that first it’s proprietary Zigbee (which to me defeats the purpose of a zigbee device most of the time), so you need both a gateway (which apparently has mqtt integration with HA, but still) and the device.
The gateway requires Ethernet cable AND USB power. I can live with USB + WiFi, or PoE, but USB and Cable, yeah - no. They suggest to use a PoE splitter that outputs Ethernet and USB but these splitters are ugly and bulky as hell. Anyway sorry for the rant.
So I am looking for the next best thing, I guess I will try this Giex valve based on my research and see what happens.
I have bought GX02 device in Aliexp shop.
I have a few comments that may help to improve this device in the future.
- The rubber gasket is quite thin and I was not able to seal the device on my garden tap. I had to make an additional gasket myself. I am from Germany and maybe this is a specific feature of German taps. The threads are shorter than necessary.
- The connection distance between the device and the Zigbee coordinator is very short. It is possible that the metal case is shielding the signal. More powerful antenna is needed.
- In 2 weeks only 70% of batteries left.
The device works perfectly with HOME ASSISTANT via Zigbee2MQTT Bridge, but how I noticed in point 2, if coordinator is very close to it.
P.S. Pairing warning : 2024-04-17 22:42:03fzLocal.giexWaterValve: Unrecognized DP #107 with VALUE = 0
I got in touch with the GiEX support and they could verify the connection issues with ZHA. They are working on a solution, but did ask for patience. I hope in one or two weeks we could except an update.