[RELEASE] Home Assistant Device Bridge (HADB)

It sometimes pays to think about what you want to do the other way around. If your intent is relatively simple then setup a device in HE that is mirrored into HA (using another integration) or use a HA device like a binary switch with a paired HE virtual. Now change the state of the device within HE as wanted and setup an automation in HA triggered on state change that will do what you want like ‘erase track’.

Alternatively .. I am not sure if this integration supports HA automation script triggering from a virtual device in HE but if it does you could do it that way too.

I know you’re very new to HA and probably shy of writing an automation script there but it’s fairly easy. Holding out for support within this integration for media players is a big request as it’s one of the most complex devices

1 Like

I get this error when trying to save the updated driver code...

 expecting '}', found ']' @ line 410, column 129.

fix underway...

1 Like

It should be fine now

1 Like

Was just playing with this - I have two HA instances so I installed two apps with different HA IP's and tokens.

Log shows
java.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI on line 137 (method updated)

I have altered the code now so it uses the last octet of the HA IP appended to the DNI. Maybe that will break something elsewhere

Also if I turn on 'Enable Debug Logging; in the app the discovery never completes. With it turned off it runs OK and I find a ton of devices (probably >500) . If I select all it only creates 12 child devices in HE. Maybe this is because they have to change state to be created

Get a lot of these too
WebSocket error, reconnecting.

The first thing I tested was changing modes. I saw that HA uses the string 'heat_cool' rather than the more more common 'auto.' The modes heat/cool/off all worked fine, but auto didn't work. This is what the log showed.

 dev:742 2021-12-29 09:13:53.895 pm debug parse(): description = {"id": 3, "type": "result", "success": false, "error": {"code": "unknown_error", "message": "'auto'"}}
 dev:742 2021-12-29 09:13:53.876 pm debug messUpd = {"id":3,"type":"call_service","domain":"climate","service":"set_hvac_mode","service_data":{"entity_id":"climate.ecobee_main_local","hvac_mode":"auto"}}
 dev:742 2021-12-29 09:13:53.873 pm info received setThermostatMode request from My Ecobee (HADB)     

I'll try to get more testing done, but the next few days will be tough.

I f you want them all, you could use the driver without the app.

The child devices are created only when their status changes.

Yes - I noticed that now and updated my post - I'm sure there's a reason why but it means a non changing value never creates a device to display that value. I'll see how it evolves

What behavior do you see? Just nothing shows up in the selection list? Or the page fails to load at all? I'd like to track this down. Do you see anything in the logs when it fails?

Turning on this does not show a 'done' button so I assume it's just applied - when I then click 'Discover and Select Devices' the apps activity spinning circle just spins but never finishes. So I guess the next page doesn't load. No extra log messages seem to be added. Maybe turning this on is when I'm seeing those websocket errors and because of those it's not able to complete discovery.. not sure why that might be precipitated by turning logging on.

Can you show me the log for the other mode?

I'm going to try to replicate and debug this. Thank you for the summary.

@ymerj Stanby...I think I'm running into the same problem I did with some previous testing. I may be looking at the wrong logs.

I guess your debug log went off (30 min delai)

You did hit "initialise" after changing the driver code?

The driver should not send "auto" to HA. I have to check how this is possible.

My previous log posts were from the device using the previous driver. This is the log from the current development version you posted. It appears that none of the setThermostatMode functions are working. This is likely the last time I'll get to try anything until Sunday. Sorry for the previous "wild goose chase."

dev:804 2021-12-29 10:15:14.964 pm errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.util.LinkedHashMap#plus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
	[interface java.util.Collection]
	[interface java.util.Map] on line 613 (method componentSetThermostatMode)
dev:804 2021-12-29 10:14:56.960 pm errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.util.LinkedHashMap#plus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
	[interface java.util.Collection]
	[interface java.util.Map] on line 613 (method componentSetThermostatMode)
dev:804 2021-12-29 10:14:44.652 pm errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.util.LinkedHashMap#plus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
	[interface java.util.Collection]
	[interface java.util.Map] on line 613 (method componentSetThermostatMode)

Ok thanks, I know now what is causing it.

Shoul be fix now... I guess we will wait for sunday to know the result.

Unless someone else is testing.

Allright...one last report. The mode changes are working. I can cycle between auto, heat, cool, and off. The only issue is the heating and cooling setpoints are not populating properly when switching modes. For example, my ecobee currently has a heat setting of 60, a cool setting of 76. When switching modes from heat to cool, the value for thermostatSetpoint remains at 60. When switching to auto, the heating sepoint populated as 59 and the cooling as 78. I'm not sure where these numbers came from, but they may have been "cached" or stale values from within HA. In all cases, the HE attributes match those shown in HA, but they do not match the settings on the actual thermostat. If you use the setHeatingSetpoint (or cooling) functions to change the setpoints, they are successfully changed across the device, HA, and HE. I see this same behavior when using the HA interface to make mode changes, and strongly suspect this is a limitation/bug on the HA side.

Using the setFanMode funtion to turn on the fan does change the HE attribute to ON, but there is no equivalent within HA and the fan does not actually turn on. Turning on the fan at the thermostat does indeed start the fan, but there is no attribute with HA to indicate that only the fan is running, and thus no update into HE. The HE log entry is below.

dev:804 2021-12-29 11:03:38.269 pm debug parse(): description = {"id": 19, "type": "result", "success": true, "result": {"context": {"id": "b3e725e5fb8b0cfc714aacf0c2c6a927", "parent_id": null, "user_id": "4cd8629fdacc42d483e9724fc535170f"}}}
dev:804 2021-12-29 11:03:38.251 pm debug messUpdStr = {"id":19,"type":"call_service","domain":"climate","service":"set_fan_mode","service_data":{"entity_id":"climate.ecobee_main_local","fan_mode":"on"}}
dev:804 2021-12-29 11:03:38.248 pm info received fanmode request from OpLava Ecobee
1 Like

I have now thought harder about the media player functionality and also checked what HA is actually capable of.

Play/pause: yes absolutely and play pause would be necessary for morning/night.
Volume: controls the speed. neat party trick but I usually always have it on 50% so not really practical or needed
Next/previous track doesn't appear to work and I think I understand why. I guess this one isn't a big deal either
Calling a track by name doesn't appear to be possible so running an erase track at night doesn't seem like that could be a thing anyway.

None of this is actually needed in my view. This is only my second time firing up a HA and my first time using this driver so I had limited knowledge of what it actually did until now.

I understand from another user that media player is not supported with the bridge and I'm ok with that. This definitely isn't a deal breaker. For the focus of this bridge, I think I'd like to focus only on connecting the on/off/dim of the light.

Ok,

Perhaps I'm being too impatient with each of the steps but I know I searched for the device twice while refreshing in-between and it was only showing the bridge as a device. Just now, when I went to respond to the post with my findings, the child device is in there and it's very responsive. It works exactly as I would expect.

Thank you for the heads up on the media player. I looked deeper into the functionality and that's not a necessity for me to automate the table so I won't need to pursue that.

I have one more integration that I am going to attempt to get running on HA for my blinds but I know that's going to be an uphill battle. I'd like to at least get close enough to it this week to know what I'm looking at to make the connection (even if I need a series of virtual switches to make it work).

I have nexx garage that's not compatible with HE. Is a garage door binary enough for this application?

Edit: I've already automated the sisyphus light and connected it to Alexa. This is great! one more integration/automation checked off the list.