HADB allready mapped it to a contact sensor. It is fully working as a contact sensor right now. You don't have to do anything.
The "intrusion" bit is only a name. You can rename it "Grandma medication drawer" or leave it as is if you wish. It does not matter.
This is what HADB report for that device allready.
That’s the thing, it isn’t coming into hubitat as a contact sensor or a known sensor. It’s showing up as this.
In HA when it was first added it was added as an intrusion sensor. When the gate would open and close it would show safe /unsafe instead of open / closed. I went in after the fact and changed the entity from intrusion to door.
It’s not showing any contact status of open/closed.
I changed the device type to generic component contact sensor. I’ll see what happens when I open / close the gates when I get home from
Work today and see if it adds it as a value.
This information was not included in your original post.
According to HA docs, there is no such device_class as intrusion. Indeed HADB in this case will map an unkwown sensor which will reflect whatever value HA is reporting (in this case "on" or "off"). You could have used it like this.
The fact you change it to door in HA is ok too but this will not automatically change the device type in HE. Manually changing it to contact sensor in HE is the correct action in this case.
ratgdo32 disco integrated with HA and working perfectly:
I selected the Light, Obstruction, and Vehicle
detected from the HADB device list:
I toggled the Light and it showed up in Hubitat but when Obstruction or Vehicle detected are toggled, they don't appear under the HADB Device parent and an error is thrown:
Solution:
I added genericComponentUnknownSensor.groovy to Drivers code, the error disappeared, and both Obstruction and Vehicle detected appeared under the HADB Driver parent after being triggered.
I have upgraded to the HADB v2 and i a missing a component for my reolink camera which is the Siren:
Shown here in HA:
I messaged you a follow up to our March discussion.
Just a heads up for those that use the HADB for local control of their Ecobee thermostats. There are more reports of thermostat fields not updating in Home Assistant. Only reason I found this is was because I was thinking about going to native local Hubitat Ecobee integration and doing some research.
In this thread at the end there is a post to github where they asked for a fix to the stuck data fields and the developers have stated that the Home Kit integration in Home Assistant is unreliable and not likely being fixed. There are other posts dealing with sensors and other things.
Interestingly, I had not looked at the temerature in long while. The device was responding to automations just fine (for holds and away, etc).
However, looking at the history, there was a full week where no temperature data appears to have been collected (looks like it came back up for me around the 10th of this month)
Also, to be fair, we have had a LOT of brown out/power interuptions, the last of which was the date that the communication appears to have stopped. So, I might have chalked it up to that and pulled the units to reboot them if I had noticed the reporting issue. But, the devices were responding to hold commands and I never had a reason to look any further.
Edited to add, I went to the link you had in your comment. The last comment in that post stated that they had reported it in Github and the developers had stated that Homekit was unreliable and it is not likely to be fixed in the near future. HOWEVER, in searching through all of the reported issues in the github core page, I see no such issue listed or response made. So, I would love to see the actual exchange with the developer.
I wish they would have linked to the git comment also. I have to take their word on it but I too have seen "stuck" values such as humidity but it doesn't effect any of my Hubitat automations either.
FWIW, updating to HAOS 16.2 fixes this issue.
I suspect that the changes in temperature seen at the right hand of your temp graph correspond to when your system was updated. I know the two coincide perfectly for my system.
No, they just conincendentally occured when the outside temps dropped to low enough that my thermostat changed to my "moderate" settings. I have a rule that changes the set point based on the outside temperatures. If the expected high is over 80 (F) or expected low is below 30, I have a hard hold on the temperature to prevent certain areas of the house from getting to a temperature that the HVAC takes too long to recover from. Just happened that the outside temps dropped below 80 for the first time in a month at the same time as my temperatures started reading again (OR the change in hold settings triggered communication to start again)
I just did the HAOS update this morning. I like to give it time and read the issues before I do any updates.
So, I am all for giving a little deference to contributors. But when I see someone comment that a developer is just effectively shrugging their shoulders, I would like to see evidence. in this particular case, ~ 2 days ago, there was a post in the github that a homekit sync setting for stale values at startup (which might be related) was actually pushed in an update. (which is conincendentally, the same day the other person said a fix wasn't likely).
Same. And my temp/hum updates correlate exactly with the 16.2 update.
I have a ecobee in HA, exposed to Hubitat as a thermostat. All seems to work but one issue I have is I can't get the fan back to auto. FanOn will turn it on, but FanAuto won't switch it back to auto. I don't see anything in the logs of hubitat or HA when calling FanAuto from hubitat.
Something I'm doing wrong, or a hiccup with the HADB thermostat driver?
Edit, looking at HA logs it looks like by setting fan to auto in hubitat, it's really sending HVAC mode auto.
2025-10-04 11:01:36.697 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140021687339104] HVAC mode auto is not valid. Valid HVAC modes are: off, heat, cool, heat_cool
My guess is you are using the device page dropdown menu to control your thermostat. These are generic and cannot be modified to the particulars of the thermostat. It means unsupported commands could be requested from there.
To further troubleshooting your issue, I would need to see the debug logs. Enable debug logging in the preference section of the parent driver and activate the offending command. Then post or PM me the relevant logs.
I'll pm ya the logs.
But I was trying to get back to fan auto via rule machine. When it wouldn't work I tried from the device page directly and no dice.
Long story short, I'm trying to go away from the ecobee cloud API. Had to pair it to HA and use HADB since I don't have a c8 pro for native homekit devices.
Everything works great except getting the fan back to auto.
Forget about that. I found the problem. I will publish a fix tomorrow.
Version 2.18:
hank you for all your help. I sorted that issue; however, I now have another one. I have set up a Bossch alarm integration with HA, and the HADB integration moves 99% of the sensors and activities across; however, it doesn't matter how I change things, I cannot get the ARM/DISARM function to be seen in the HOME ASSISTANT DEVICE BRIDGE on HE. it simply doesnt alow me to check the box to add to HE as it is not present.
It is as if the alarm_control_panel.aaa ID is not compatible.
Any assistance would be appreciated.
Download the Hubitat app
