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
Well, this pretty much proves what we all assumed already; There is something in the HE software that causes the delays and slowdowns. Be it RM, ML, or SL, there is something there that doesn’t seem to affect the MakerAPI that slows the hub down to an unmanageable crawl.
Are you guys that are using HE as a simple Zigbee/Z-Wave radio seeing any slow downs in the UI portions of HE while using this method? I’m REALLY considering putting my HE back into play and removing my Nortek stick from my HA instance.
1 Like
At least in my case, I assumed the slowdown was due to the hub being overloaded vs an inherent problem in the software. At the same time I moved most of my functionality over to HA, I also disabled or removed almost everything from HE. It’s quite possible that if I’d left everything on HE, there would still be slowdowns. The HE devs have said a number of times that the hardware is more than capable of running a bunch of apps, but…I’m doubtful.
The UI has gotten much snappier for me. When I still had it loaded down with apps, pages in the UI would routinely take multiple seconds to load. Now that it’s just managing devices, I sometimes see a delay when loading the UI for the first time (I’m guessing it’s warming up a renderer or something), but once it’s up, moving around in it is quite snappy.
2 Likes
Hubitat has been as snappy as it is after a reboot for me sine I’ve been using @jason0x43 's custom component, which has been about 3 weeks now.
2 Likes
Interesting bullet point from the Hubitat 2.1.9.114 release notes:
- A change was made to the event processor in the hub. It was found that some hubs can send so many events that the processor is overloaded and the hub will stop processing events. This processor has been reworked and there is now a limit to the number of events that can be sent to the processor at one time (1024), if the event queue goes over the limit an error message will be thrown and the system will log an error “Limit Exceeded Exception, Event Queue is Full”.
3 Likes
I saw that as well… I also noticed how it was at the VERY bottom of the list of things and wasn’t really called out. There’s also a (to me) tremendous amount of actual details NOT included. Yet the telling point of processor overflow and everything stops working… sound familiar?
1 Like
I don’t know how I feel about that change if I’m being honest.They aren’t really addressing the core issue beyond limiting the number of events and throwing an error. So, what happens in the case when the queue fills up? Are users still supposed to try to troubleshoot what is sending so many events? I honestly feel like this is just more of the same old “disable everything and then see if that fixes it” mentality.
BTW @jason0x43 You were asking about HE nodes for NodeRed?
1 Like
Mixed feelings on this myself, but based on the responses in the forum and in the Beta channel, I know they are doing their best to track down the issue. I don’t know enough about these things to say whether they are focusing on the right things or not, but I believe they are doing their best with the resources they currently have. Progress of any kind is a good sign in my books and at least I have hope that I could put one of my hubs back into production.
I reset my dev hub a couple of weeks back but still haven’t had the time reconfigure it yet. With all these new ways to integrate it with HA, I’m keeping my eyes open for the one with the most potential. We now have Mqtt, Node-Red and an HA Custom Component…I only have the time to play with one…decisions, decisions. 
5 Likes
I’m wanting to take a look at the MQTT integration. I have a RTI system coming Monday that I’m anxious to start integrating things with.
I’ve been using HA Custom Component just because it uses MakerAPI on the HE side which is native. I figure as much I can keep native the better on the HE side. My HomeAssistant installation is powerful enough to handle the HA Custom Component side of things. It’s been great so far.
2 Likes
Version 0.4.6
This release fixes a regression introduced in v0.4.5 that would prevent first-time installation from working.
1 Like