Recently installed the SWV-ZF2 duo irrigation, first was using it via the NSPanel Pro but due to the distance it was not stable.
So I’ve bought the Dongle Max, installed it in Home Assistant ZHA and now I am missing the other entities like volume… how can I add these ones?
Just a quick note first: the eWeLink forum isn’t really the right place for this question. The SWV‑ZF2 is a Zigbee device, and once you move it to Home Assistant (ZHA or Zigbee2MQTT), it’s completely outside the eWeLink ecosystem. The forum mainly covers eWeLink/Sonoff’s cloud platform and their own Zigbee gateway, so support for HA/ZHA quirks is very limited here.
Regarding your issue: What you’re seeing in ZHA is most likely expected. The SWV‑ZF2 exposes additional Tuya datapoints for things such as flow, volume, session data, daily totals and irrigation modes, but the default ZHA device handler does not expose all of these datapoints as Home Assistant entities.
There are custom ZHA quirks available that add support for additional datapoints. In particular, these projects may be worth looking at:
The exact entities available depend on the quirk and the firmware/version of the valve, so I would check the project’s documentation to see which SWV‑ZF2 datapoints are currently supported.
If you decide to use a custom ZHA quirk, install it according to the project’s instructions and restart Home Assistant. Depending on the quirk, you may need to re‑pair or reconfigure the valve so that ZHA initializes it using the new quirk. After that, additional entities such as volume, flow and session statistics should become available if they are supported by the quirk.
Another option is Zigbee2MQTT. Since your Zigbee coordinator (e.g., Sonoff Dongle‑M) can be used with both ZHA and Zigbee2MQTT, you can switch to Zigbee2MQTT instead of using ZHA. Zigbee2MQTT generally has broader Tuya datapoint support than ZHA, so if the current Zigbee2MQTT converter for the SWV‑ZF2 already exposes the datapoints you need, those entities should appear automatically through MQTT without requiring a custom ZHA quirk. Note that this would be a migration from ZHA rather than something you can run simultaneously on the same coordinator.
The fact that the NSPanel Pro exposed more entities does not necessarily mean that it was using Zigbee2MQTT internally. It simply indicates that its Zigbee implementation was able to interpret and expose more of the device’s Tuya datapoints. The important point is that the limitation is not Zigbee itself: both ZHA and Zigbee2MQTT need a device‑specific implementation that knows how to interpret the Tuya datapoints exposed by the valve.
Although it is very limited, I have moved to Zigbee2mqtt where everything is available!
It’s great that Zigbee2MQTT feels more complete for you. Just keep in mind that having more exposed data points doesn’t always translate into fuller functionality. ZHA is the one quietly doing the real work, while Z2M is the flashy middle‑layer that makes people think their devices suddenly grew superpowers 
I know but it didn’t work properly when using ZHA, it stopped irrigating after few minutes.
Now I can program the timer on the device itself which is better.
For the time being - it is. The issue you had in ZHA wasn’t caused by ZHA itself. When the device receives an incomplete or incorrectly formatted DP, its firmware stops irrigation after a few minutes.
If irrigation stopped after a few minutes even with a quirk, that usually means the quirk didn’t fully match the device’s datapoints. Tuya valves rely on several DP values (duration, mode, start/stop, heartbeat), that are not standard Zigbee entities.
If even one of them is mapped incorrectly, the firmware starts irrigation but then stops it because the DP format doesn’t match what the device expects.
Zigbee2MQTT works simply because it already has a complete converter for this model. Once ZHA gets a proper quirk with correct DP mapping, it will behave exactly the same.
