GiExperience Smart Water Valve

[BEskandari]

Hello Erik,

I am trying to make a Smart Water Valve working with Homebridge Deconz. BabaIsYou provided me with a DDF that have /sensors of type ZHAConsumption. The results through Homekit are not so convincing GiExperience Smart Water Valve.

Do you have any idea how we can adapt the DDF so through Homebridge Deconz we see it correctly?

[ebaauw]

Not sure I appreciate the full features of the device, but this looks like a dirty hack, abusing existing API attributes to mean something completely different. No API client is going to understand that, without whitelisting the device and treating it special. I won’t be doing that in Homebridge deCONZ. In fact I just introduced the capabilities and config you /lights to get rid of whitelisting lights.

Looks like you’d need a new device type and new attributes to support the device properly. That cannot be done in a DDF alone, you’d need changes to the C++ code. I’m happy to support a new device type in Homebridge deCONZ if it’s well-defined.

[BEskandari]

Erik, by setting the new proposal I get the below error:

[04/05/2023, 19:49:02] [deCONZ] Water Valve: error: TypeError: Cannot read properties of undefined (reading 'rpath')
    at Light.<anonymous> (/usr/local/lib/node_modules/homebridge-deconz/lib/DeconzAccessory/index.js:79:51)
    at Light.emit (node:events:513:28)
    at Light.emit (/usr/local/lib/node_modules/homebridge-deconz/node_modules/homebridge-lib/lib/Delegate.js:173:13)
    at Gateway.analyseFullState (/usr/local/lib/node_modules/homebridge-deconz/lib/DeconzAccessory/Gateway.js:1079:34)
    at Gateway.poll (/usr/local/lib/node_modules/homebridge-deconz/lib/DeconzAccessory/Gateway.js:932:18)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Gateway.heartbeat (/usr/local/lib/node_modules/homebridge-deconz/lib/DeconzAccessory/Gateway.js:338:9)

I presume that this would not be a way to go, if I read your previous message?

[ebaauw]

The error is probably because you changed the resources deCONZ uses to expose the device, while Homebridge deCONZ was already exposing it. Homebridge deCONZ doesn't yet recognise and handle this case. Do you still get the error if you un-expose and re-expose the device?

[BabaIsYou]

Hi Erik,

I completly agree,. The liberty that Tuya has taken from Zigbee specification leads to this kind of tweak ! ;-/ It rejoins another topic we already discuss about ZHAMeasurement or other kind of generic items. But third party apps are not ready for that too. Zigbee specification are referencing cluster 0x0702 Metering for that kind of Electric, Gas or Water metering devices, that's why I choose $TYPE_CONSUMPTION_SENSOR in the DDF. But we only considered this as Current value.

[BEskandari]

The error is probably because you changed the resources deCONZ uses to expose the device, while Homebridge deCONZ was already exposing it. Homebridge deCONZ doesn't yet recognise and handle this case. Do you still get the error if you un-expose and re-expose the device?

Thanks Eric, unexpose & expose worked. But not much more options.

[ebaauw]

But not much more options.

ZHAOpenClose is supposed to be a contact sensor with state/open. Homebridge deCONZ won't understand the resource for this device.

Zigbee specification are referencing cluster 0x0702 Metering for that kind of Electric, Gas or Water metering devices, that's why I choose $TYPE_CONSUMPTION_SENSOR in the DDF. But we only considered this as Current value.

Fair enough, but in that case we should have exposed the Metering Device Type and Unit of Measure (but still normalise the values, so API clients won't have to deal with binary vs BCD and the Multiplier nor Divisor). I don't think I've seen any smart plug actually supporting Metering Device Type with a value other than 0x00.

HomeKit doesn't support any sort of metering standard. Eve uses custom attributes for electricity measurement (for their Eve Energy smart plugs), incl. history. For my Homebridge P1 plugin, I've mapped DSMR gas and water meters to these, but the Eve app displays gas total and current consumption in kWh and W instead of m³ and l/h.

HomeKit does support Valves, with a set duration and remaining duration (not to be confused with the occupied to unoccupied delay) no presence delay, but I don't have much experience with these. Homebridge Hue supports these, though a resource link, indicating with /lights resources should be exposed as Valve. I don't know if Eve shows consumption for these; never got my hands on an Eve Aqua. Haven't yet implemented this for Homebridge deCONZ.

The issue with remaining duration is that you cannot query the Zigbee device for that, since there's no way to force reading the device from a GET in the API. It simply returns the cached value, rather than the actual value on the device. That's why we never exposed On Time over the API. I actually keep track of the remaining time in Homebridge Hue, turning the device off from Homebridge Hue, rather than relying on On with Timed Off. HomeKit also counts down autonomously, after reading the value from the accessory.

Bottom line: I think we should properly expose valves in deCONZ, using an identified type (as for Window Covering or Warning Device). We probably need to look at some proper Zigbee valves, before trying to map this Tuya stuff.

[BabaIsYou]

Bottom line: I think we should properly expose valves in deCONZ, using an identified type (as for Window Covering or Warning Device)

Once more I agree.

[BEskandari]

indicating with /lights resources should be exposed as Valve

Is there a way to modify the DDF to expose /lights as a Valve?

Just for the sake information

printscreen from EVE AQUA

printscreen for GiEXperience Smart Water Valve

[ebaauw]

Not currently. As I mentioned above, that needs C++ changes as well.

And it needs changes in Homebridge deCONZ as well. Afaik, they still haven't reverse engineered the Eve Aqua, and without that info, I won't be able to expose the valve like an Eve Aqua.