Custom Component: Hubitat

Aside from my 2 temporary Rule Machine rules that I’m using to bring in location modes and HSM status, I’ve got 1 automation left between HE, ST and WebCoRe that I haven’t brought into HA, and I’m not sure if it’s possible.

I have all of my inovelli switches on HE with the custom “Advanced” driver. This let’s me change the DefaultLEDColor attribute. When the alarm or HSM arms, the led’s on the switch turn red. When they disarm the lights go back to blue.

Since this is an attribute I’m not so sure that it can be manipulated through MakerAPI. If it can’t, I can live with having 1 rule in RM. But if it can I’d love to get rid of it. I suppose I could always test the regular driver again with the updated firmware and toggling the child device for notifications. I had moved away from this because any use of the switch disabled the notification and this driver made the color change stick.

Thoughts?

You really don’t like HE do you but I feel you do them quite an injustice.

Why do you still use it, or participate in this thread ?

I don’t think I do them any injustice. Of course you are, as am I, are entitled to your opinion. My opinion is, the performance of their product is pitiful and the team at HE give two squats about that fact or the people that have supported them since inception. HE was literally useless as an automation system to me. HA on the other hand, lets me couple my own hardware solution with an ever improving software solution. I couldn’t be happier with the result.

On the other subject, I participate in this thread because there is a community of former HE users that have migrated to HA (for good reason), and I appreciate the comradery that has been built in these two communities, and the work done by people like Jason to unify these communities.

I will soon be 100% HE free, and happier for it. But I will still participate in the community of former HE users because I want to. As to why you care about where I participate or my feelings on HE, I haven’t a clue.

2 Likes

Well drat, after all that wrangling with IDs because Hubitat doesn’t make its unique ID available over the Maker API, I learn about the !#@$% diagnostic tool, which uses a separate API at http://<hub>:8081/api. One function is hubInfo, which returns all kinds of useful stuff like the ID and hardware version.

I got another 500 error tonight. Trying to issue a turn off for a group of lights. I suspect HA is sending the power off to each light regardless of whether it’s on or not, and that’s temporarily overloading HE.

I might move that automation to Node-Red and try to build an automation to find out which lights are on and only issue the power off to those. Not sure if I can do that in YAML

There’s an awesome node in node-red for exactly that. “Get Entities”.

My goodnight routine closes the garage doors, locks the doors, arms the alarm and turns off all the lights. It would take well over a minute because of all the z-wave traffic and I find the HE hub doesn’t handle tons of commands at once very well.

I created groups in HA and used the get entities node to determine which lights (and others) were actually on and send the off commands only to those devices. My goodnight routine is now fully completed in under 10s.

You can see here, instead of 30 some lights being told to turn off, only 3 were on so it only sent the off command to those 3.

Here’s the import code to give you a jumping off point. You’ll need to add a trigger and adjust to your setup.

[{"id":"7d9b910b.9eee2","type":"api-call-service","z":"a8efc4c6.6fe918","name":"Turn Off Lights","server":"94fdcfdf.a00b","version":1,"debugenabled":false,"service_domain":"light","service":"turn_off","entityId":"","data":"{\"entity_id\":\"{{payload}}\"}","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":900,"y":260,"wires":[[]]},{"id":"46e1c983.10f708","type":"join","z":"a8efc4c6.6fe918","name":"","mode":"custom","build":"string","property":"payload","propertyType":"msg","key":"topic","joiner":", ","joinerType":"str","accumulate":false,"timeout":"","count":"","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":750,"y":260,"wires":[["7d9b910b.9eee2"]]},{"id":"bef4604a.81564","type":"template","z":"a8efc4c6.6fe918","name":"Format Msg","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"{{payload.entity_id}}","output":"str","x":610,"y":260,"wires":[["46e1c983.10f708"]]},{"id":"393e066b.78413a","type":"ha-get-entities","z":"a8efc4c6.6fe918","server":"94fdcfdf.a00b","name":"Which Lights?","rules":[{"property":"entity_id","logic":"in_group","value":"group.goodnight_lights","valueType":"str"},{"property":"state","logic":"is","value":"on","valueType":"str"}],"output_type":"split","output_empty_results":false,"output_location_type":"msg","output_location":"payload","output_results_count":1,"x":400,"y":260,"wires":[["bef4604a.81564"]]},{"id":"94fdcfdf.a00b","type":"server","z":"","name":"Home Assistant","addon":true}]
3 Likes

This is awesome, thanks! Do you find that blasting 3 lock commands at once is slow? I still use “Lockdown” on HE and I just trigger Lockdown and let it handle locking the doors. I run it last in my list of night time routine stuff, since z-wave secure runs like molasses on HE.

HE’s implementation of zwave locks is terrible, and it’s always blamed on the manufacturer. I had moved my Schlage locks from ST where they were solid to HE and they worked but were very slow. I just recently moved them from HE onto my ring alarm and the speed increase is unreal.

Same 5 locks, 3 different platforms, works great on 2 slow on the 3rd… but the issue is the lock right?? LOL

So true. I wish they’d really take a look into why they perform so bad. They just bury their heads in the sand and say it’s not a problem.

This is what has me the most grumpy about my HE to HA migration. I have 6 (yeah, my house is old and has a bizarre number of exterior doors) kwikset locks that worked fine under ST. HE z-wave was so bad that pairing the locks caused the zwave radio to lock up - required a hard reset to get it working again - and was told it was well known that kwikset z-wave locks don’t work right. So, I spent a bunch of money on the zigbee modules, and sold the z-waves on ebay to recoup some cash. Now I’m on HA and my zigbee locks aren’t really supported and it looks like I’d be better having the z-waves again!

1 Like

Why not leave the zigbee locks on HE if they worked well there and bring them in using this integration?

They know what the problem is. They don’t have a complete/function Z-Wave stack. HE is not a Z-Wave Plus Certified gateway. This is documented.

Usually they say it’s a “device issue”…

Or blame someone’s custom app, behind their back, with no evidence. :upside_down_face:

That’s what I’m doing for now, but my locks are the only zigbee devices I have left on HE (so I don’t have any repeaters or anything to help that mesh), and they’re also the only “critical” devices I have left on HE, so it’s just a bit frustrating.

That part struck me right away when joining the HE community - the irony of how SmartThings staff unfairly throwing blame on Rule Machine was the entire reason HE exists, but then HE staff loudly and repeatedly do the same thing to coders on their platform.

And then of course the mild hypocrisy of using the openness of the SmartThings code to kickstart their driver support, but keeping their own drivers locked down tight (presumably so nobody ports drivers the other way) even when it would help their own customers.

2 Likes

Version 0.5.5

This release improves support for cover devices (some drivers apparently don’t follow the Hubitat spec) and fixes an issue where fan devices weren’t allowing their speed to be set.

4 Likes

Yesterday I noticed ZHA Thermostats finally made it into the main branch. I instantly migrated my Centralite Pearls.

Today, I ordered a zwave radio for one of 3 Kwikset 910 I have. I’d previously installed a zigbee radio into the other two, and purchased the 3rd as zigbee because zwave locks just didn’t work on HE. After some testing with zwave locks on HA, I’m pleased to say they work perfectly fine. So I converted back to zwave on the two locks I converted and moved them to HA. ZHA Locks are missing some services (code setting) still on HA.

When the 3rd zwave radio arrives and I’ll convert, it’ll be the last device leaving HE and the hub will be decommissioned. :tada: :confetti_ball: :sparkles: :sparkler:

1 Like

I have a question:

I went through and changed the names on a bunch of devices to better identify them as Hubitat Elevation devices.

Now I have a bunch of these ghost devices that were the devices before the name changes, what is the most proper way to get rid of them? Am I doing something wrong where those old entities aren’t getting cleaned up on their own?

Hurry up so you can sell it on the HE forum at a premium :rofl:

I have one already decommissioned.
I can’t, in good conscious, sell it to some unwitting noob. Plus I’m snarfing the radio for other use.

1 Like