My DSB09 is running firmware 3.64 I am near certain (it was the only firmware I had on my PC). I am not sure what firmware it originally had, but I was getting wild results with ST with whatever firmware it had.
With the 3.64 firmware (all 3 can be found here : Aeotec HEM v1 Firmware ) I got consistent valid results. With Hubitat, plus the dth in post #8 (modified as per post #4), I now have two clamps reporting logical numbers per clamp.
Thanks for the link. I'll grab 3.64 and see if I can get the "wild one" working.
I found no way to detect the loaded firmware, but the install process is idiot-proof, just plug the base HEM into a PC with a USB cable, and run the exe with the firmware, and it finds the device, and loads the firmware, even blinking the little light to let you know it is happy, and then a very large and reassuring "Complete" message appears on your screen, all happening in mere seconds. So many have done this so poorly, it was pleasantly surprising to encounter such a well-crafted upgrade package.
I will be poking at the device with "Super Basic Z-Wave Tool", so maybe I can get it to reveal things like firmware mod, but it seems to be a moot point... 3.64 seems popular.
But now I seem to simply have a device that goes cataonic - see the graph of "Power One" and "Power Two" below:
The wacky single high reading is one problem, but the device simply went silent from 2:15am to 5:45am, when I messed with the graph configuration, thinking that the graph app was the problem. But I had un-commented the "parse" message in the driver, so as to also log the data reports, and the logs match the graph - it went silent, and aside from a single (silly) reading at 5:45am, it did not resume reporting.
So, how to get the Hubitat to tell me exactly when it does the maintenance reboot with a log message? Is that now happening at 2:15am?
(Please don't kill me - I take no side in the war over what time reboots should happen)
I saw that. I was going to work with it last night but, unfortunately, I'm going to have to spin up a windows machine on my Linux box. I might get some time this weekend. I really haven't done much with the HEM since moving them from ST.
I looked at my backups and they are now happening around the 2:15 mark too.
To answer a prior question , using the very aptly named "Super Basic Z-Wave Tool" temporarily configured as the HEM device driver, one can read the current firmware revision using the "version report" button on an in-service device from the comfort of one's web browser.
The version report appears in the logfile, which for a Hubitat is starting to look a lot like both stdout and stderr to me...
As it seems that there are very few users of Aeotec HEMs of the older types, a few notes "for the record" to help perhaps 2 other folks who buy one on eBay:
There are 3 verisons of hardware:
DSB09 = Home Energy Meter Generation 1
DSB28 = Home Energy Meter Generation 2
ZW095 = Home Energy Meter Generation 5
There is no wrong way to install the clamps on the older (DSB09) models, as they do not measure amps bi-directionally, as would be needed if one was generating power with a solar array, or a private backyard nuclear reactor.
Include/Exclude is triggered with a VERY brief push of the button inside the battery compartment (first model) or adjacent to the battery compartment (later models) when it includes/excludes, the red LED flashes quickly a few times, then slowly for a bit.
A solid red LED means "power is on". There is no indication from the device end that all is well, (or that anything is wrong) aside from (2) above. (I hate people who use red LEDs to indicate that all is well, how much more would a green one or white one have cost? Agggruh!)
Aeotec was very nice to my pathetic inquires, and made me much more cluefull, even though the older HEM is nowhere to be found in their website docs library.
One has to configure this device to get it to send reports in the manner expected. Out of the box, or with a factory reset, you get a single reading for power and kWh every few mins, apparently summing the readings from the two clamps.
The "AEON HEM v1" driver by jrfarrar works fine, and allows one to set the voltage on each phase, so for a 240-Volt USA 2-phase panel, one enters "120", as there is 120 on each wire, as measured to ground. What is being read here is instantaneous amps, just like a clamp ammeter (or "amp-meter"), everything else is calculated. The parameter for setting manually with the "Super-Basic Z-Wave Tool" is:
"Set parameter 1 [2 bytes] = 120"
My HEM was thrashing around until I (a) Factory reset the device, and (b) configured it to report "properly", meaning to report watts on each clamp periodically.
To factory reset, you set parameter 255 [length 4] to 0
To get periodic reports out of the thing from both clamps, you need to set the following:
Parameter 3 [1 byte] = 0 //disable selective reporting
Parameter 101 [4 byte] = 6924 //report clamp 1, clamp 2, and total, both Watts and kWh
Parameter 111 [4 byte] = 120 //report every 120 seconds
Parameter 101 has a whole long list of bits you can flip to tell it to do all kinds of fancy things like only report when a change of greater than "x" is detected in the current drawn, and this may be preferred, as it might eliminate the occasional single-point nonsense readings that clearly are "outlier" values, I dunno. But for now, the above gives me what I expected "out of box", a device that reports what it sees on a regular basis.
Big thanks to Chris in Aeotec tech support, who was patient with me, even though he was provided with little to nothing in the way of info about this "older" device.
I used the 3.64 firmware, the other two firmware loads did not seem to work on this older device, and I am not in the mood right now to mess with them.
If the occasional single-data-point high values become an annoyance, I will attempt to modify the driver to ignore them, but I need to see more of them to profile them better, as one can also easily get a single data point with a "much higher value" by heating coffee in a microwave for 1 min if one is sampling every 2 mins.
Mine is still running along happily on ST with Ver 3.60 Should I update to 3.64? Or try it as is LOL. I am only polling at 5 minute intervals which is sufficient for my dryer monitoring.
You have to ask yourself - "Is it working?"
And if it is, you should get down on your knees and thank whatever deity your parents told you was the one true God, and leave things well enough alone. 
It's working in ST just fine right now. It's one of the last two devices I have on ST and I am wanting to move it over to just get rid of the ST taste in my mouth.
That said, I am gonna leave it at 3.60 and test it out I think. The firmware update process looks to be simple enough if it doesn't work. (Firm believer on "if it ain't broke, then don't fix it" I rarely update firmwares unless it's to fix an issue or a security thing - Hubs excluded because if you get too far behind, you never know what will happen when you try to catch up. But even those, now that I have the option, are going to be done with care to wait and see what others are getting for results)
Wonder if there is a way to backup the existing firmware before/if I need to update it?
***** Edited to add****** I did notupdate the firmware from 3.60. I used the recommendations on driver (#8 in this thread HEMv1 (DSB09) Custom DTH; Which One?) and did the inclusion on battery power only. Set the report type to 1 (timed interval) and set the interval to 60 seconds,
Set up my own laundry monitor app that I ported over from ST and all appears to be working well.
@jrfarrar, like others here, I'm using your awesome HEMv1 driver for my DSB09s. Thanks for the driver!
Wonder if anyone can help me with one curious behavior. I have three of the old HEM v1's in use around the house. For a couple of them, I noticed that, even though I've set the reporting thresholds high (I.e., only report if wattage has changed a lot, in percent and in number), the device event log is still showing power events every few seconds, even when power changes < 1W and <1%. Seems odd--why would this be? It's almost as if the device's event log is ignoring the driver's parameters.
This is more than an academic pursuit -- I'm suffering from broader hub errors due to too many events in queue, so I'm on the hunt to kill event-spammers. Starting the hunt with the power devices.
The documentation for these is very sketchy.
Here's what I have configured, manually, using the "Basic Z-Wave Tool":
First, the "factory reset" settings to get the thing to shut up entirely:
Parameter 101-103 = 0
Parameter 111-113 = 0
Parameter 255 [4 byte] factory reset unit (write any value to this param to reset)
Parameter 100 [4 byte] set to any value other than zero will reset 101-103 to defaults
Now, we can tell it what to report - I just want regular reports of wattage:
Parameter 3 [1 byte] = 0 //disable selective reporting (i prefer this since it will report out of sync)
Parameter 101 [4 byte] = 6924 //report clamp 1, clamp 2, and total for kWh and Watt
Parameter 111 [4 byte] = 240 //report the above every 240 seconds
Note "Parameter 101" in the above - the "6924" decimal value maps to the binary bits to be set as follows:
6924 = 0xb 0001 1011 0000 1100
I am not at all surprised that you are getting more data than you wanted - see my post earlier in this same thread outlining the complexities I ran into.
Hahahaha first please don't thank me, these are terrible and some of the first drivers I wrote...I hacked this one for sure from old smartthings code...then tried to learn Parent/Child drivers from it. It does work...but agree these can be chatty. Especially with 3 of them (I have 4).
Take what @james.fischer has above and also look in the code in my parent driver around lines 355 in the individual clamp driver and 420 in the parent/child drivers. I actually documented everything I knew at the time about the parameters. Using the "Basic Z-Wave Tool" you can tweak them.
Now I'm going off memory...but I do remember wanting them to think they had batteries vs plugged in for this reason. I think when you joined them with batteries they set that setting. This is going from memory some years back.
lol sounds good. I'll do that. From reading a lot of history on the topic, I think the reason you wanted the device paired with batteries was so that it wouldn't repeat and bog down the mesh.
Even if you switch to mains power afterwards. I'm going to give that a try as well. So thanks!
Two things if I might ask.....
First you are welcome to try them here:
Second I do remember one of the issues being the percentage. Because if a clamp is basically sitting at 0...then it doesn't take much to change by 20%. Hence why people were using time interval.
I could not make any of that "driver button" stuff work with the older model (DBS09) I have, running the 3.64 firmware. I don't touch them, I did not attempt to "fix" the code, as the primary use for these things seems to be electric dryer monitoring (for people who haven't realized that the buzzer on the dryer is loud enough to set off a cheap vibration sensor, which can then ring the doorbell chime 4 times rapid-fire...)
So, the driver reads the data, and the Basic Z-Wave tool does the config work. Between the AC power and the batteries, I expect to have to worry about or mess with this gizmo exactly once per year to check the "battery backup"... 'cause no power being used at all is an alarm condition... my ICE CREAM is at risk!
Yeah I totally get that. And thanks for the link. Are the device drive parms combined with an AND or an OR? So, for example, if I configure to only report events if the clamp sees (1) an increase in 25W; (2) an increase in 20% of watts, is it both or either that is required to generate the event?
The reason I'm asking is I have an appliance that plugs away when not in use at ~25W. It varies from 25.2W to 25.5W and then rockets to 900W when in use. What's weird is that events are firing every few seconds without the in-use spike, just when the clamp goes from 25.2 to 25.3, for example. Even though I have the thresholds set at 25W / 20%. Weird.
Edit: oh wait, forget it. Just read your second note that you never tried to make the code work. Gotcha. I'm following your advice and going to z-wave config tool. TTYL
For power monitoring, this driver is the right one to use, but to use the v1 for appliance monitoring, I would recommend you use @mike.maxwell ‘s driver that @ogiewon ported to HE. I just posted a use case that has links to the driver and examples of how I’m using it. This is way. 
Yeah thanks. I've used that in the past, but I've found it doesn't work well for other use cases, which is why I was looking for a more generic device handler.
I am trying to use the 'Basic Z-Wave Tool' device handler to make the changes that @james.fischer had set above as I would like my HEM V1 to send regular reports of wattage. I dont think I know how this Basic Z-Wave tool works as I am not getting anything back when I click on the "Get Version Report' and no feedback that the parameters are even being changed when I try the 'Set Parameter' button. I am looking at the logs and do not see any info. Can someone please enlighten me on how this device handler is supposed to be used. Where do the Version and Parameter reports show up for viewing and how to I get confirmation of the parameter changes?
Download the Hubitat app
