Hi, I'm running a C5 HE @v2.4.2.119 for lighting automation. I'm interested in tracking ON/OFF cycles of a heat pump & well pump. eMylo/Tuya clamp-on wifi energy monitors look interesting but they aren't on the compatible devices list. Can they integrate directly with Elevation or are other apps or services necessary?
If they had a Zigbee version, that might integrate assuming it has a driver built for it.
Thanks, Sebastien. It seems they do make a Zigbee version & it costs “only” (rolling my eyes out loud)…70% more than the base model. Still gotta wonder about a driver.
Yea, they do tend to charge more for the Zigbee models. Z-Wave (not available for that specific product) tends to be even more expensive.
Zigbee connects locally. The Wifi versions tend to connect to cloud servers, so the driver would need to be able to connect to the same. Some devices can be updated/upgraded to Tasmota which, while still Wifi, is totally local. Not sure about this one…
Check this post where he modified an existing community driver to make it work with this device and 2 clamps, but this is for the Zigbee version of course…
Thank you, Nelson. That may be exactly what I'm after.
I actually didn't reference the community driver at all, Google Gemini built that from scratch, with me just giving it the info from the bottom of the device page.
1st Prompt:
Can you write a Hubitat elevation groovy driver for a Tuya Zigbee Energy monitor with clamp?
It shows up in hubitat like this: In Clusters 0004,0005,EF00,0000,ED00 Manufacturer _TZE284_81yrt3lo Model TS0601 Out Clusters 0019,000A It has two sets of terminals to attach clamps in a power panel.
2nd Prompt for child devices:
Gemini: " Would you like assistance in expanding this driver to create virtual child devices for Clamp A and Clamp B so they show up as independent entities on your Hubitat devices list?"
Yes, I would like each clamp to show up as child devices
3rd Prompt was about the attributes not staying in the child device, since Gemini used the Hubitat generic component driver. It then wrote a custom child device driver.
4th Prompt: Attributes now stayed in child devices, but would only update when device sent a change. Last prompt was to add a refresh to parent and child to allow data polling to populate the attributes from current device values.
"The corrected active reporting query frame (0x02) will force the unit to transmit. Once it lands, the live metrics will overwrite the placeholders on your child device"
That is where I left it. I will note that it uses the "power" attribute for watts, where the community driver reported that as "energy".