Custom Component: Hubitat

Just a thought on buttons.
imo creating a binary_sensor that fires when the button is pressed is much easier than what people were trying to explain to me is typically done with buttons in HA.
I still don’t understand the event system, and I don’t have to because the Tasmota button on my outlet that I use to trigger creates a binary_sensor that triggers my automations when I press it.

The people who like events are very loud about it, but coming from SmartThings then Hubitat the binary_sensor is so much easier for me to monitor, it’s a known entity that I don’t have to look on some advanced page to see what the name of the event even is, let alone try to figure out how to get into Node-Red.
Do with this opinion what you will, since currently I just made a virtual switch in Hubitat that monitors button presses, so I’m not depending on you making binary_sensors, it just might be more in line with how us hub people think. :wink:

Personally, for single button devices, it makes sense. But, for devices with 2 or more buttons, it makes the binary_sensor approach a bit more difficult to manage. Do you have a binary_sensor for each button? What about double-presses or holds? Would those trip the binary_sensor?

Yes

Yes

All the entities! :rofl:
Just easier to see.

1 Like

I can definitely see the draw of using sensors for buttons. I was also initially confused about how they worked (particularly from a coding perspective) in HA. Stateful devices, like sensors, are more approachable and visible than event emitters in Home Assistant. The internal APIs around them are easier to work with, too.

However…buttons aren’t actually stateful devices, so I can see why Home Assistant treats them as event emitters. When you push a button, you haven’t changed the state of the button controller, you’ve just caused a “pushed” event. Hubitat does treat button devices as stateful, which doesn’t really make a lot of sense. If you look at the state of a button device in Hubitat, it will have a ‘pushed’ property set to the number of the last pushed button. What’s that telling you, though? The button isn’t currently pushed (even in Hubitat, the state change happens after a button event). It was pushed at some point in the past, but that’s not terribly useful to know.

You can make a sensor to expose button presses in Hubitat or Home Assistant easily enough, but, as @code-in-progress mentioned, it’s going to be pretty limited. You’d have to make a separate sensor for each button, and for each type of operation (push, hold, double-tap), which could get out of hand pretty quickly. Plus, the sensors should reset themselves after some arbitrarily short amount of time, so they’d need a bit of logic attached (I’ve used virtual momentary switches for that sort of thing in Hubitat in the past).

Home Assistant actually makes using device events pretty easy through the UI. You create an automation, choose Device as the trigger type, pick your device, and pick the trigger. It’s not much different from triggering on a sensor value change.

As far as using events in external apps like Node-RED or AppDaemon, there’s only one event type to listen to from the Hubitat integration – hubitat_event, which will look like

{
    "event_type": "hubitat_event",
    "data": {
        "device_id": "180",
        "attribute": "pushed",
        "value": "1"
    },
    ...
}

All of that said, I’m not opposed to adding an option to generate binary sensors for all the button events, but it might be more worthwhile (and less messy) to make a visualizer card for Lovelace that would show button presses.

2 Likes

I get it, tallying button presses is rather useless.
I guess my only concern is that I’ve been using HA for a while now and still don’t understand events, possibly because I haven’t had to.
It’d be interesting to see if more users who are used to thinking like SmartThings or Hubitat conditions us to think will be able to pick it up.

Thanks to some of our back and forth previously I understand what the device_id is, but as new user, where would I find that?

1 Like

Screw it. @jason0x43 create binary_sensors for ALL THE THINGS! ALL…OF…THEM!!!

LMFAO I missed you crazy people!

2 Likes

I agree that events can seem a bit weird, particularly the APIs. HA mostly hides them from you, because the only thing (that I know of) that uses them in the API is device triggers, and those don’t specifically mention “event” anywhere. They’re actually pretty similar to states when used externally, though, at least in AppDaemon (I haven’t used Node-RED with HA). You just listen for events instead of state changes.

Regarding device_id, it’s the Hubitat device ID, so one way to find it is from the URL when you’re viewing a device in Hubitat:

https://10.0.1.99/device/edit/180

Hmmm…I could see about adding the device’s label to the event, too, which would probably be easier to work with (although a bit more fragile) than an ID.

2 Likes

Honestly, I had the same problem. After doing so much with RM4, it was a weird concept at first.

1 Like

Makes me appreciate all Hubitat does.
Too bad you can’t just run it on powerful hardware to overcome whatever slowdown issue they have.

1 Like

NodeRed uses the same model (listening for events versus state changes), but it kind of abstracts that concept and allows you to target device states or event domains (events: state node versus events: all node).

At the rate they are bleeding users, I wonder if they will eventually move to a model similar to HA. I doubt it, but I’d jump back on in a heartbeat if they released an OS image I could run on anything besides their hub.

1 Like

You wouldn’t get the nice selection like you do with entities here:

image
That Basement Button Pushed is a switch I made in HE.
I guess I’d have to know exactly what to listen for, and maybe format it so match the event above…

I like the hub, and I like that the maker API exists. Really, if they just focused on that, they could have a very solid product, basically a Hue hub for generic Z-Wave/Zigbee devices which could be more stable than trying to deal directly with z-wave and zigbee meshes in HA. Clean up the mobile apps and only expose RM (giving it a snazzier UI) through the UI, and flesh out the REST API, and you’d have something that would be great for both consumers and enthusiasts.

Moving custom code off the hub is nice both because the hub apparently can’t handle much, and because the software stack isn’t terribly developer friendly. Groovy doesn’t have the best tooling, and the fact that you can’t use external libraries makes code sharing and updating painful. That is, I’m sure, part of why Smartthings moved away from that stack.

3 Likes

Nice insight.
I’ve heard Groovy gets rather un-groovy after a certain point.
Before WebCoRE came out I was all about creating my own SmartApps in SmartThings.
It was difficult being restricted to event driven programming.

I work in Industrial Automation, where we poll devices every couple of milliseconds…

1 Like

This is how I do button events in NodeRed. I listen to zha_event, then I switch based upon the device_ieee address and then switch based upon the command that comes in.

image

image

image

4 Likes

@jason0x43 Seriously could not have put it any better. +1,000,000 upvotes.

That’s how it should work with Hubitat events, too. You’d listen for hubitat_event and look for something like payload.data.device_id.

I agree with @keithcroshaw that it’s not quite as friendly, though. If someone ambitious wanted to create a Hubitat node that would understand the event structure and could autocomplete device IDs and/or names, I could add any necessary functionality to the integration to make that work… :smile:

2 Likes

Oh I see you filter it through a switch.
I think I’ll stick to my Hubitat virtual switch for now.

They even have the auto-off functionality built in, which is nice.

Version 0.4.3

This release fixes an issue where double-tap events weren’t showing labels during automation creation.

2 Likes

Version 0.4.4

This release fixes an issue where button events other than "pushed’ weren’t being emitted. Events now also include the Hubitat device name as device_name.

1 Like