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:
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.
4 Likes
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… 
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
Awesome that that shows up!
I see most of the gang over here now 
HE makes a good device controller.
3 Likes
Version 0.4.5
Woo, more bug fixes. This release fixes an issue where devices weren’t being created in Home Assistant for Hubitat devices that were only event emitters (i.e., push button controllers with no battery reporting or other sensors).
3 Likes
Just wanted to say I did a few quick tests last night.
Using HE as the ultimate timing log, there’s a completely negligible speed difference between a HE automation and a YAML HA automation.
From a z-wave button, to a z-wave light switch, HE is reporting ~300ms regardless of how the automation is firing.
On HE I am using “Button Controller” and on HA I was just using the quick GUI Automation creator.
Pretty impressive that it’s equally as fast using MakerAPI as it is running entirely natively.
1 Like
That pretty much mirrors my own experience. Going from a zigbee button controller to a zigbee wall switch, I’m seeing around 255ms in the HE logs when going through an HA automation, and around 300ms from a zwave contact switch to a zwave dimmer going through HA + AppDaemon.
When I had all my rules running in RuleMachine on HE, I’d routinely see delays of 3+ seconds between a trigger and the intended action (generally flipping a light switch). The delays are what prompted me to try out HA, so I guess that worked out OK. 
1 Like
To add to this… I found the same increase in response with the HomeSeer plugin and with the ISY integration. Both integrations use the HE Maker API in a similar fashion and both integrations are generally faster than HE with RM.
Mind boggling…
I’m using Node-Red for most things but I like some things to be local to HE in case I’m rebooting or something and the wife opens a door and the lights don’t come on.
Blows my mind that you’re seeing faster response time using HA automation than Rule Machine. Which is what I think you’re saying.
I saw faster with somethings and as fast with others but NEVER slower response with HomeSeer and with ISY integrations than with native RM. There’s actually several posts on the HE forum from a couple other users with the same experience.
1 Like