HEMv1 (DSB09) Custom DTH; Which One?

[jrfarrar]

@mluck

@jrfarrar, like others here, I'm using your awesome HEMv1 driver for my DSB09s. Thanks for the driver!

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.

[mluck]

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.....

1. I assumed (from your comments about this driver in another thread) that the parent/child twin-set of drivers wasn't even working. So I just use the individual "AEON HEM v1" driver--the one that has powerOne and powerTwo, and then lean on RM to extract those attributes to synch a virtual power device. Kinda like your use of WATO, if I understand correctly. You think I'm making a mistake not to install the parent and child drivers? Am I missing something....
2. Also, just so I'm clear, do the driver parameters (copied below) do anything? In and of themselves, they don't seem to change event behavior, even though they are set to prevent all but the biggest events, I think.
   

[jrfarrar]

First you are welcome to try them here:

jrfarrar/hubitat

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.

[james.fischer]

@mluck

Also, just so I'm clear, do the driver parameters (copied below) do anything? In and of themselves, they don't seem to change event behavior, even though they are set to prevent all but the biggest events, I think.

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!

[mluck]

@jrfarrar

Because if a clamp is basically sitting at 0...then it doesn't take much to change by 20%.

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

[SmartHomePrimer]

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.

[mluck]

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.

[Levahj]

@james.fischer

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

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?

[james.fischer]

@ Levahj
Each successful setting should create an log entry.

You fill in each of the blanks under "Set Parameter" - "parameterNumber", "size", and "value", then you click "Set Parameter" up top to set the parameter. The log, which you can have open in another tab or window, should confirm what you just did in plan English.

Then, when you are done, switch back to the device driver of your choice.

I should also add that setting Parameter 101 (4 byte) to 768 will give you only the two wattages from each coil, and forego the total watts reporting, which makes for less Z-Wave traffic.

[Levahj]

@james.fischer

Each successful setting should create an log entry.

Wasn't getting any log entries until I moved the device from the laundry room to the desk where the hub is. Then I was receiving the logs. I was able to make the changes and all is good. What is not so good is that in the Zwave details page it shows the device in the laundry room as working with no abnormalities that I could tell. I have since moved the device up the wall away from the dryer as much as possible and have done a zwave repair so all is looking good.

Thanks for the tip on parameter 101 to create less traffic! I am getting kwh energy readings every minute. Do you know which parameter is used for that reading? I would like to change it to every hour or two if possible as I dont require it .

[james.fischer]

@Levahj

Set param 111 (4 bytes) 3600

This is the time, in seconds, between reports of wattage, so "3600" would be one hour.

[kampto]

Have had my HEM v1 for a while, Ported over the ST DTH from "jrfarrar" almost a year ago to hubitat, Haven/t really paid much attention to it till lately when I noticed the total power has been stuck on 505.2 for days or even longer. Checked device with the toaster oven running and the clamps appear to be reporting properly individually. Is this a DH issues or a HEM reporting issue? I want to monitor the total power.

[james.fischer]

Have you tried going to the device page, and clicking refresh?
What about the logs - what do they say?

Mine seems to be reporting as expected, showing the sum of energyOne and energyTwo:

• energyOne : 258.42
• energyTwo : 541.86
• power : 880.2

[kampto]

I got it working by doing a Z-Wave repair on the device and switched to the HE native HEM driver which basically just reports every 5min.

[james.fischer]

@kampto Where is there a NATIVE hubitat driver for the HEM?

[Levahj]

@james.fischer

Where is there a NATIVE hubitat driver for the HEM?

I'll jump in on this one, just because this thing has been a pain since I first installed it. The built in Device Handler would not set all the parameters and I just wanted power level to be sent every 30seconds and nothing else. Finally went with the custom DTH which changed the parameters and timing of them but then the Power all of a sudden would not send data. Only PowerOne and PowerTwo but not the Power paramater. Anyways.... finally went back to the built in Device handler and now it is sending Power every 30sec like I want it to with the parameter changes I had made in the custom Handler which seemed to have carried over. this stuff (zwave devices in general) just acts so weird sometimes...

Hubitat could sure help things be a lot smoother if they didnt just throw out Device Handlers with no ability to change parameters or with just a small subset of what the device can actually do. Device handlers that are native should be tested and confirmed with the manufacturer that the parameters that are meant to be set and adjusted can be before any driver is published.

That would go a long way in making the Hubitat ecosystem a much more user-friendly one for the community and would make it much more adaptable for the larger DIY crowd that is not as software savvy as many of the current users are.

Native Driver:

[james.fischer]

The problem here is that the manufacturers introduce and then quickly obsolete devices, leaving them orphans, with inadequate documentation.

If you search my posts on this device, I uncovered a set of register settings to satisfy just about any reporting need and timing of reports. But, I did not bother to try to modify the driver, as the Z-Wave tool allows me to manually set these parameters, and the battery in the HEM means that even if power goes out, the settings remain, as the device would "never go down".

But think that there is only a handful of us using these things, so we can't expect much support. The vendor certainly isn't much help, and the Hubitat folks are likely swamped as it is with "new toys" to support.

[Levahj]

@james.fischer

If you search my posts on this device, I uncovered a set of register settings to satisfy just about any reporting need and timing of reports. But, I did not bother to try to modify the driver, as the Z-Wave tool allows me to manually set these parameters

You and I corresponded earlier on this thread and you helped me ID the correct Parameters, size, etc to use the Zwave tool. It worked for a while, then the 'power' event decided to not get sent any longer. It was strange...

@james.fischer

But think that there is only a handful of us using these things, so we can't expect much support. The vendor certainly isn't much help, and the Hubitat folks are likely swamped as it is with "new toys" to support.

I agree with this statement. But until things become more plug and play so the more 'average' DIY'er can implement them, the smart home world will continue to be more niche and less mainstream. I just think that if Hubitat puts out a Native Driver for a part then it should be full featured and nothing less. If they feel the device is too niche then they should not put one out at all and let the community that uses the device and/or the mfg create a driver

The big guys certainly know this world is not yet user friendly enough for the masses:

Amazon, Apple, and Google’s open-source smart home standard is on track for a...

[james.fischer]

Yes, I am sure that Amazon, Apple and Google will "make it easier", but only for those who drink the Kool-Aid of "cloud support", and are willing to let these companies monitor activity in residences.

One of the beauties of Hubitat is that it runs just fine behind a firewall with no connection at all to the outside world other than the specific ones you overtly allow.

Call me paranoid, but East Germany and much of the Soviet Block had a habit of installing microphones in homes, but they at least did not make those they were spying on pay for the microphones (I'm looking at you, Google Assistant and Alexa ! ).

Yes, Hubitat is a pain at times, but it was ALSO a bit of work to configure my LG CX-series OLED TV so that it would not present its many "smart-TV" options, but simply be a "dumb" display for the Roku, FireStick, and local broadcast channels, and set up the router to block the TV's ad-and-spy attempts.

So, assuming that one does not want to live in a goldfish bowl, which is more work - making an inherently "private" device do what you want, or engaging in a never-ending battle for privacy with a manufacturer who very much wants to monetize our every activity, rather than do things we want done, triggered by our activities? And more important, what of things to be done when we are AWAY? My main application for hubitat is to support and monitor residences that I am not currently visiting, so having a residence that "springs to life" when we arrive, and "sleeps" when we are gone, saves money, and avoids problems inherent in "caretakers" who don't take care.

Ray Bradbury wrote a short story long ago - "There Will Come Soft Rains", which stressed the crucial importance of motion and presence detection in home automation, and the need to address pet care as a part of the daily processes to be automated. The story is read aloud here - https://youtu.be/QbOL33Kirdw

[Levahj]

@james.fischer

Ray Bradbury wrote a short story long ago - "There Will Come Soft Rains", which stressed the crucial importance of motion and presence detection in home automation, and the need to address pet care as a part of the daily processes to be automated. The story is read aloud here - https://youtu.be/QbOL33Kirdw

LOL... or Yikes....

@james.fischer

Yes, I am sure that Amazon, Apple and Google will "make it easier", but only for those who drink the Kool-Aid of "cloud support", and are willing to let these companies monitor activity in residences.

I agree with you on this. I am in the Hubitat ecosystem and think it is set up better from a security perspective, etc, than the big guys will be in a year or two. My comment is more related to Hubitat being able to compete long term with the bigger players. They are gong to have to be more user friendly to attract the amount of people to sustain their business model. GadgetGeeks like us are not a large enough subset of the population.
One of the (many?) things they could do is somehow work closer with the mfg's to create device handlers that work, and work with a full set of their capabilities. They could start a mfg feedback setup were if the mfg wants to have a built in Hubitat driver, they have to test the first code and make recommendations or whatever. Or maybe force the mfg's to fill in a sheet of parameters that should be built into the device drivers. Or write the code. Something!
It only takes time and money.

But without better productization it becomes a vicious circle - not enough resource to productize correctly. Not enough new customers to pay for the correct productization. They seem to be a bit in this rut and need to figure out a way to get out of it.