Funny...I went to turn on logging, and found that battery events showed up for one device that I had tried to get battery info for previously but it hadn't shown up. What I did for that device was:
Clicked on the Battery option in the list below for the device:
The "Stove Right Rear Burner Battery child didn't show up for quite a while so I figured I was barking up the wrong tree. But I guess it just too, a long time to report...if this is the way it should work, then I'll just do the others as well. If there is a way that the battery info can show up in the same child details that has the open/close info that would be preferred, of course.
Checking for understanding... You were saying that giving it that name and saving had the effect of enabling the battery entity, correct? It wasn't that it was always enabled but the name change caused it to start working somehow?
Because we use the generic component virtual devices, there isn't really a possibility to add the battery info to the same child as contact state
Thanks...and yes, giving it the name and saving seemed to allow it to show up in HE as a device (at least none of the other contact sensor's battery info has appeared).
Ah, wait...when I set up Home Assistant Device Bridge, two entries showed up from each contact sensor in addition to the entities based on the name I used when I added the sensors to HA:
Looking at this again, I think I'm understanding it better now. It seems like providing a name at device discovery only names the "contact" part of the device, while the power (battery) and temperature reporting entities don't also get named for the device name I entered. Hope that makes sense. So I have three entries for each device:
The contact sensor aspect of the device, using the name I provided at discovery in HA
The power and temperature aspects of the device, which retain the lovely "gobble-di-gook" naming that HA uses...
One of the devices, 8d8dec07 only has a temperature entry in the upper section, because I had renamed the power entity for that device to "Right Rear Burner Battery."
Yeah, I know it's a bit of a crap shoot, but it gives me at least an approximate idea of how things are going w/the battery and when I should be watching it more closely. Over time I'll know better from change dates, which I track, how often I need to change.
Absolutely. Thanks for asking the questions - they made me think about this more and differently than I had been thinking about it. Off to do some more renaming...
Ok so how do I know which HA devices are able to be imported?
I got my Twinkly lights straight to show up on Hubitat side. I also have Xiaomi robot vacuum cleaners and I'm able to control them from HA side but they do not import to Hubitat side. Same thing with Yale August lock.
There has to be an entity on the HA side, and a matching Generic Component Device type in the list of drivers on the HE side.
Depends on what device type entities are available from your vacuum. There are other ways to control a vacuum from HE. What else do you want to get from it besides control?
All I wanted was possibility to control robots from Hubitat and see status (docked, cleaning, etc.) . When that happens in Hubitat I'm able to add robot vacuum tiles to SharpTools dashboard and control those from there. Or add robots to webcore rules.
Actually I was able to add robots to SharpTools (thanks to Sharptools and HA intergration) but my "home automation policy" is to (has been) use Hubitat as main hub for the automations. All other hubs are secondary (like ST and HA) and all information from devices connected those secondary hubs goes through Hubitat and after that for example to SharpTools. Same logic with webcore too..
We really only intended to support very simple devices and sensors with HADB. Locks and thermostats were really painful to get working reliably, and it emphasized how specialized or complicated devices need a more direct integration that the HADB architecture isn't really intended to support.
So, you either need to get a direct integration into Hubitat for more specialized devices, or you should go direct from the primary integration (like your HA->Sharptools setup).
I do not have Wallbox yet installed but now I'm wondering if Wallbox can be imported to Hubitat side at all. It should be way more difficult than robot vacuums and like you wrote.. even locks and thermostats were painful.
Ah, cool. I am not familiar with Wallbox. I'll take a quick look to see what the prospect of bringing it in to HADB or even porting directly to Hubitat would be.
I see. Well you can probably do something simple like use virtual switches to control and show status. I understand keeping the automation in Hubitat. This is what I do as well, but when I run into something that can't be brought into Hubitat via HADB, or I just don't want to bother anyone with a one-off integration, I instead share virtual switches the other direction using this integration from @jason0x43. I then just create very simple automations in HA that change my Hubitat virtual switch state in response to the device status on HA, or activate the device on HA in response to my activating the virtual switch on Hubitat (the virtual switch auto-off feature works particularly well for this).
Sometimes if I want a particular device type to be activated on Hubitat, I'll just write my own very simple driver that includes the device type and a switch capability. That way I can have HA turn on a switch via a simple Automation, and it will result in a different device type responding on HE, such as a contact sensor closing for example.
I just checked in v0.1.46, which adds a few advanced configuration options. Thank you to @dan-edge for their suggestions and help with testing.
From the Configure advanced options page in the Home Assistant Device Bridge app:
Only pass through user-selected and manually-added entities?
** This option disables all filtering of entities. This essentially passes through all HA entity updates, so it would be a good way to disable all filtering either permanently or temporarily for testing. Keep in mind that this will create new child devices for any events on supported entity types.
Manually add an entity to be included
** This section allows you to manually add (or remove) an entity to be filtered by entity ID. This may be a quicker option for expert users compared to scrolling and checking boxes on the main configuration page. You can use either method of adding devices -- they have the same effect.
Remove all child devices that are not currently either user-selected or manually-added
** This is a cleanup method. Use it carefully. It will remove all child devices that do not appear in either filtered list (checkboxes on the main config page and manually-added list on the advanced page). It will remove child devices regardless of the state of the "Only pass through..." switch described above.
Suggestion how to use this page when you're adding a new device to HA and having trouble setting it up in HADB:
Add the entity manually, if you know its entity ID.
If not, just disable the "Only pass through..." switch. This will result in creation of new child devices, hopefully including the one you want and possibly including others that you don't.
Once you confirm it is working, add the new one you want to one of the filtered lists -- either by using the checkbox method on the main device discovery page or manually adding it on the advanced page.
Once your lists of devices to pass through are correct, re-enable the "Only pass through..." switch and then execute the "Remove all child devices that are not..." step.
@SmartHomePrimer
A question about this bridge:
I would like to spin up a RPI without any zwave/zigbee dongles. I would like to reflect a number of ziwave/zigbee devices from Hubitat in Home Assistant, so that I can use their dashboard.
The client would use that dashboard, and all button presses would be reflected into real actions on Hubitat.
Is that your bridge, or is it the reverse bridge from @jason0x43 ?
