I have known they were repeating devices since I first set them up. They have never had batteries. The more interesting thing is that there are multiple Plus devices with direct unobstructed paths to route through. The image is a chunk of Zwave network traffic captured the other day. Device 6 is the HEM. The first line is the energy report.
1 Like
Good to know for other 300 series devices. I made the wrong assumption. Thanks for correcting me. 
So, I finally got around to installing 3 random Zooz switches I've had for 3 years. I wonder if their firmware is just so old, they're being a PITA, or if it's this HEM. Regardless, in hindsight, I am not buying any more ZWave devices.
I wonder: when this HEM is powered by USB, it probably acts as a repeater (possibly causing issues). However, if I instead wire up the battery ports with a wall wart, would this disable the repeating, and allow the device to simply run as a battery powered device? This is how my LeakSmart valve works, and seems logical that's how all dual-power devices would work.
If so, that'd be an easy enough fix.
That's what is appears. You can do what you're saying, yes. But there's probably a Z-Wave parameter you can just set instead.
Here's the basic Z-Wave too for that.
For some devices there is no parameter to tell it to repeat or not since that is not something that you can typically change on a device after it is joined and other devices know about it. Instead, if you join it while it is mains-powered it repeats. If you join it while it is battery-powered it doesn't.
So... if you don't find a parameter you would have to battery-power it and join it again.
If you DO find a parameter, will you please point me to the documentation? I would love to see the actual documentation for the parameters that the most current firmware of the G1 supports. Online documentation for that device is sparse and I don't feel like opening a ticket with Aeotech support.
2 Likes
If joining it with batteries installed actually stops the repeating, that would be great. Where I have this device, it will never need to repeat anything, so it would be nice to have this feature disabled "permanently" (or, until I re-join it).
I never finished the work on it and was looking for someone to help create the child devices a few years ago. If anyone wants to work on it I'll be glad to merge the changes in for everyone.
1 Like
Yep, I looked through the parameters of the v5 (couldn't find them for the old v1) and it doesn't appear to exist on the newer, so it most likely doesn't on the older either.
Good point about joining with batteries first. That means that @ChubChub and others should be able to join via battery and then just remove them and switch back to the adapter. It will stay non-repeating. That was pointed out to me about the Homeseer Flex in the past and I just totally forgot about that.
I'll look into what that even means, since I'm slowly running out of stuff to do at home, I might as well learn how to program properly in Groovy/Hubitat.
1 Like
Lilttle update on this. It's been a long time since I looked at it and I even forgot that I DID get the child devices working...kind of. Working in that they do have a power value passed down to them for each individual clamp. I see there are a few errors getting thrown and it was having updating "total" power. If anyone wants to fix up some things I posted the latest version I have. I think with a few tweaks it could be pretty good.
Also to note...ALL parameters that I could find about the Unit years ago when I was on smartthings are documented with notes at the bottom of the parent code.
3 Likes
I personally have no need for the child devices. I'm just so thankful for the work you've done. Much appreciated.
I did find the parameters with a search by parameter number. Nothing about adjusting the repeating function by parameter. My assumption was wrong.
Yeah, then, if these are the parameters for the G1 it is very similar to the G2 and Gen5 and my driver may work with very little change. This may be the PDF I found in the other thread as the suspected G1 parameters but I thought somebody said the parameters weren't right.
Side note, I didn't implement child devices on the G2 or Gen5 driver because you can use custom attributes in RM now. I guess I could have to maintain compatibility with some app that wants a power meter for each clamp but are there any apps like that?
1 Like
I am not aware of any. As long as I can get them via custom attributes, I'm happy.
1 Like
Never that I saw. Always just joined with batteries.
Nope, I started this way before the custom attributes were a thing. I could rip out all the child stuff and really just have 1 driver that covers both clamps and individual clamps.
I have just ordered one of these DSB09 units, and I was wondering if anyone has tried using BOTH batteries and the USB power supply at the same time so that the unit can report a power failure to the Hub. Obviously, if USB-powered, it will be silent if power goes down.
It is meant to be used with both battery and USB AFAICT. USB goes down, batteries take over.
If you wanted to use it in the way you mentioned, you could do it by NOT installing the batteries, and trigger a wait on every reported power event. If (say) 65s passes and you get no new power reports since the last one, power is probably out.
I would expect there would be an easier way to do this, like pinging something that is normally always on (router), and if no answer back, power is out.
I have an interesting anomaly - my DSB09 arrived, but it has no markings on the clamps to tell the user which way to orient them, yet the docs speak about a "K" vs "L" side to the clamps, and instruct the installer to place one one way, and the other the other way on each phase of a 240 Volt USA power feed.
And I may not have guessed right, as the numbers I am getting are nonsense - see the screenshot.
There is no way that I am using anything near a single Kw, yet the "power" values are sky high. Can anyone suggest a possible solution?
I am using this driver (hubitat/HEMv1 Individual Clamp.groovy at master · jrfarrar/hubitat · GitHub)
Update - after letting the DSB09 sit and collect data all night, I have silly high readings, per the attached screenshot:
And this graph from the amazingly good "Hubigraphs" package:
I need to buy a vowel !
Update - The Aeotec HEM v1 seems to have 3 different firmware loads available:
- Home Energy Meter V3_61 US 2_phase 20110314.exe
- Home Energy Meter V3_64 US_200A 2_phase 20120615.exe
- Home Energy Meter V3_67 US 2_phase 20120210.exe
#2 is the one that works for me, the others don't, as follows:
#1 results in a HEMv1 that can be included and recognized as a device, but never displays any data on the Hubitat "device" page.
#3 "works, but reports the nonsense values and very high values described in my post above.
But #2 only gives one a total power, and reports nothing for the individual clamps on the individual phases. It also seems to not permit the creation of child devices, logging the following error:
groovy.lang.MissingMethodException: No signature of method: user_driver_jrfarrar_AEON_HEM_v1_482.createChildDevices() is applicable for argument types: () values: [] on line 151 (updated)
Is anyone else using a HEMv1 any more?
I actually have 2. Using the stock HE driver one of them appears to display power usage correctly. At least on a freezer using only 1 clamp on one leg. The other, in the same environment, displays wildly high readings. If memory serves me correctly, in the neighborhood of 10x what I think they should be.
How did you determine which firmware you are using? It's been a long time now but I thought I updated both to the latest when they were on ST but could be mistaken.
Is there a way to tell which version of the firmware is flashed?
