I'm using Maker in HE along with the Hubitat integration in HA to share the devices into HA - and HADB to share the opposite. I've used it for a couple of years in and this is the only (potential) example of a conflict of a device or entity struggling to be controlled between the two.
This is not a log produced by a HADB child device:
I don't think HADB has anything to do with your problem unless you shared back the thermostat to HE which would certainly cause a confict.
For helping my understanding...
If switches and other commandable devices are created in HE and control is shared back and forth using the two methods in the above post, are you able to share more why changing a state in a Thermostat would cause a problem?
I have hundreds of devices working this way and don't see any other conflicts
I've just checked - the device is not being shared back in via HADB and my list of these where it is is very limited.
To prevent the examples which I think you are referring to.
Thanks for kicking my tires 
If you want to control HA devices from HE, use HADB.
If you want to control HE devices from HA, use the Hubitat integration from HA.
But do not share back and forth the same device with both integration. This is completely useless and prone to cause conflicts since either integration allow for a device to be available in both platform.
1 Like
The problem is most likely in the HA integration. I cannot help with that.
3 Likes
small but probably painful feature request.
HADB is working really well for me. While checking driver versions on somethings I note that there is a naming issue that munges my listings.
Some drivers from HABD come over as 'Generic ....' some come as 'HABD Generic ...' . This makes my listing messy with my other Generic drivers.
Personally, the HABD prefix works better for me to ID them visually.
The Ask:
Could the Generic Components be updated in the name fields so all begin with 'HABD Generic ...'?
Nope - what I wrote was incorrect.
I'm aware of the confusion. I started to name the newer child drivers as they were introduced for that reason. I could rename the older one with the HADB prefix but users would end up with two copies of the same driver with different names. Newly created devices would use the new named drivers but older devices would still use the original ones.
The same goes for the parent device. I would like to rename it HADB parent but It would probably create a mess.
I don't think there is an automated way to clean that up.
I'm open to clever suggestions
4 Likes
It’s just a case of some people being OCD. It’s fine as it is, in my opinion.
2 Likes
Silly question..... (or maybe not)
Currently running HA in Docker on a raspberry pi 4. I am considering moving that to a VM on Synology and restoring everything from a backup.
So, the question is, will I need to reconfigure everything in HADB on the HE side from the ground up? Or, can I just update to the new location and keep everything else in tact
Any reason you don't want to move it to a Docker container on the Synology?
Well, that is an option as well. I was actually wanting to get out of manual updates of HA and the custom addons. But, I am still on the fence on that. I currently just would like to get it off of the PI as that is just my "toy" device and HA has become a little more now.
However, in either case, the IP will change. I was just asking if the HADB settings change would require me to delete and readd all the devices? Or if can I just update the IP and keep it running seemlessly. I could always go the FAFO method. But, I like to know ahead of time if I am gonna spend a weekend redoing things, or an hour just logging in again.
HADB only care about the IP address and the access token for connection. As for the devices, if they keep the same entity name, they will be bridged as they were before.
2 Likes
That is what I was hoping for.
VMs have add-on capability. Docker container does not.
4 Likes
There seems to be a problem with a shared button from HA being able to trigger automations in Rule Machine, or I don't know what I'm doing....
I generally use HA for all my dashboards and statistics and HE for automations. As such, I created a virtual button, or "Helper device", in Home Assistant, and then used HADB to share that button to Hubitat to trigger an automation.
When the "button" is pressed in Home Assistant, the button device page in Hubitat correctly shows a "press" on button 1, and the Hubitat log also shows a press on button 1. Great, all should be working right?
Then I created an automation in Hubitat to beep my keychain when button 1 is pressed. However, despite the fact that Hubitat seems to recognize that button 1 was pressed, the automation from Rule Machine simply will not trigger. What am I doing wrong?
Here's a screenshot of the Rule Machine automation in question, and a short log post showing that Hubitat does recognize the button press, but for whatever reason the rule is not being triggered.
Log:
Rule Machine:
Device Page:
Fix is on the way
2 Likes
Amazing, thanks!
Version 2.12:
- add support for select entity (used by ecobee).
- add input source to media_player.
- add mode selection by name for options (select), presets (climate), input source (media_player) and humidity.
- fix button event. (save preferences on the child device after updating)
- some code tweaking.
5 Likes
