The list of currently supported HA device types is shown on line 84 of the App Code. If your device type is listed, it could/should be worth a shot.
1 Like
Thanks for the thorough report. Post back when you are ready to test again. Meanwhile we will look into it.
I made a PR to add some additional binary sensors.
@tomw - I haven't checked this error out but it could be what is causing the app to stop after selecting the additional logging - maybe the parameter typing is wrong or something.. java.util.HashMap
An unexpected error has occurred trying to load the app. Check Logs for more information.
Error: No signature of method: java.lang.String.call() is applicable for argument types: (java.util.HashMap) values: [[runDiscovery:true]] Possible solutions: wait(), any(), wait(long), take(int), each(groovy.lang.Closure), any(groovy.lang.Closure)
1 Like
Thanks for continuing to share info for debugging.
I'm not able to reproduce this, unfortunately. Are you using http or https with your HA instance? Are you sure that your HA instance is routable from HE and that you are using the right port (I assume so, but just have to check).
Edit: I can strip that runDiscovery part to see if that helps. I'll send you some code via PM to try.
I’ve seen this thread when it was created but didn’t want to go back to HA again, so I ignore it. 
But now after being on vacation for a week I need something new to do. I have a spare Raspberry Pi and a few devices/services not supported by HE. This app/driver seems to be a perfect match and I can’t wait for the family to go to bed so I can start playing around.
Thank you @SmartHomePrimer for creating and sharing!
3 Likes
I’m just the messenger. The creators and contributors to the code are @ymerj , @tomw , @ogiewon , and @stephack.
Happy New Year! Be sure to enjoy the family first, the hobby second.
6 Likes
I have everything up and running and the setup was a super easy and smooth. 
The first thing I wanted to do was to get my alarm system (Verisure) working through HE.
Unfortunately, the Verisure app/driver we have only works (at least for me) for showing the status,
not to arm, arm home or disarm.
Verisure was easy to setup in HA and works well so I thought I create a virtual switch in HA and control that through HE. Unfortunately HA doesn't have virtual devices afaik so I created a Helper (switch), but that one dont show up in HE.
How do you guys set up virtual devices in HA that HE can control and trigger automatons in HA?
Use this integration to go the opposite direction.
Create your virtual switches in HE and they will show up in HA. Then you can create an automation in HA that controls your device when the virtual switch is operated in HE.
2 Likes
Thank you for pointing out the HE integration. Worked like a charm on the first try.
1 Like
So, any changes made at the device (mode, setpoint, etc.) appear to be updating successfully in HA and HE. The same can't be said for changes made in HE/HA being correctly sent to the device. As noted earlier, mode changes made in HA are correctly received by my device, and my device's setpoints change to the programmed values based on the active program (Home, Away, etc.). These updated temperature setpoints are not "pushed" back to HA and the "old" setpoint remains. Making a setpoint change at the thermostat does not trigger an update within HA, but changing them in HA does. Once the mode AND setpoints are back "in sync" everything begins to behave normally again. Until the HA side of this integration gets worked out, I don't expect that the HADB driver can be expected to work properly. At least not using the same setup I've got (Ecobee <-> HomeKit Controller <-> HADB). I'm curious to know how well it works with other thermostats connected to HA.
And because I generally let the Ecobee do what it wants, and only use HA to monitor what my Ecobee is up to, the current state still meets my needs.
I’ve never been a fan of messing with the Ecobee outside of manually override when we were not comfortable. It does its job very well without intervention, but you do you!
You can quite easily make HE mode changes trigger a virtual switch on HE, and using the reverse integration posted just above, you can make the change to that HE virtual switch trigger a Home Assistant automation, thus controlling the thermostat the way you want.
It sounds like HA is not refreshing the ecobee state regularly. Which is weird especially when the change is made from the HE side and affects the thermostat, since those commands definitely go through HA.
How does HA eventually get back in sync?
To be clear, when I was testing to see how well changes at the hub were sent to the device, I was ONLY using HA. I figured if the HA <-> Ecobee portion wasn't working, that HE/HADB couldn't be properly evaluated. TO get back in sync, a simple setpoint change within HA will make the change at the device and then "force" an update of the HA setpoint attributes.
Indeed it does. I was really just testing out the control fucntions because they are included in the HADB driver update and should to be tested before being included in the "released" version of the code. As I mentioned, I typically just monitor the Ecobee and use it's actions to trigger other automations. For example, the Ecobee can ignore "unoccupied" spaces, but it can't close my HVAC dampers that serve those spaces. As long as I can "See" what the Ecobee is doing, I can use HE to coordinate and augment Ecobee's smarts.
Ah, got it. I misunderstood before.
Will you try a setpoint setting from HE to see if HADB is sending it correctly? I assume that would have the same effect as setting it in HA directly.
Keeping in mind that HADB does not communicate with the device directly but only to HA, we should focus on making sure HA and HE are in sync. Reading your post, It seems that most go through ok. Can you pinpoint what is not?
Maybe I misunderstand your posts, Are you saying temperature in mode change are wrong? If it is the case, I have a code change for you to try.
1 Like
Sorry I haven't gotten back to this yet. So far I've been spending most of my available "hobby time" rewriting rules that currently use MQTT to versions using devices created by this driver. Hopefully tomorrow will provide an opportunity.
1 Like
What are the thoughts on adding some additional Generic Component drivers that are lacking in Hubitat? I was able to very easily make a Generic Battery that reports % from HA correctly, just by copying and modifying the capability in the illuminance sensor. Hubitat has several of these where the capability exists here for things that also exist in HA, but there just isn't a driver available.
2 Likes
We had erred on limiting custom Generic Component drivers just to avoid creating confusion by duplicating drivers that Hubitat may eventually add. @SmartHomePrimer led the charge on requests for adding several new Generic Component drivers in past Hubitat platform releases.
Do you have a list of those that you think would be particularly useful, @BrenenP?
After comparing HE capabilities with basic device classes, I think I found eleven device types that can be added. With this, binary_sensor is just yes/no reporting, sensor is reporting of a value with a unit, cover is for controlling doors/windows/blinds, and media player controls media players.
Binary Sensor
- HA device_class = HE capability
- gas = GasDetector
- sound = SoundSensor
- tamper = TamperAlert
Sensor
- aqi = AirQuality
- battery = Battery
- carbon_dioxide = CarbonDioxideMeasurement
- current = CurrentMeter
- signal_strength = SignalStrength
Cover
- blind = WindowBlind
- shade = WindowShade
Media Player
- media_player = MusicPlayer (?)
As for what is useful, I think that's subjective and varies person to person. I think covering the binary sensors and sensors would be a good place to start, I've already got Battery working. Again I'm unsure of your scope with this project, but it seems like it would be relatively easy to add some of these if you'd like.
2 Likes
