HEMv1 (DSB09) Custom DTH; Which One?

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

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 .

@Levahj

Set param 111 (4 bytes) 3600

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

1 Like

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.

image

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

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.

@kampto 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:

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.

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

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:

1 Like

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

LOL... or Yikes....

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.

I think that there is always room for boutique high-end products. For example my Walsh Ohm 2 speakers still make my living room look like Easter Island, and are still supported, even though I bought them in 1981 - 40 years ago. I can get parts and service here: Ohm Walsh 2 | Legacy Products | Ohm Speakers | Custom Audiophile Speakers for Music & Home Theater

Open source also keeps things "alive" longer. Linksys/Netgear WRT-1200 series routers sell used for good prices even though the manufacturer hasn't updated the code for years - everyone runs DD-WRT, OpenWRT, or a forked variant on the hardware, and we enjoy 5Ghz WiFi, and NAS drives directly connected to USB3 and eSATA ports on the router.

In comparison, can I sell my Smarthings v2 Hub? At ANY price? See my point?

But can they make enough money at $130/ea to survive long term with a boutique hobbyist customer base? I just think they need to become a bit more mainstream rather than boutique to survive long term. Time will tell...

Great for the buyer, but not sure how it helps the seller long term?

It seems like many (most?) of us here are ST refugee's. The owners are too right? The Smartthings business case almost became an impossibility for us hobbyist's once Samsung purchased them. They are a consumer electronics and appliance behemoth that bought Smartthings to connect their products to each other. Why would anyone think long term they would want to cater to the pain in the butt hobbyists and tinkerers we are when they need to connect millions of refrigerator's to their TV's? I have two V2 Hub's I think I will just need to give away lol

1 Like