There seems to exists lots of ways to integrate HE devices into HA but I fail to find an easy way to do the reverse. HA has a rest api, websocket api, MQTT capability and support for native app integration. (I'm not a programmer so I only know these terms means access is possible but that's about it). What I would like is to be able to:
Control HA devices from HE. NOT the other way around.
Is there a simple way to acheive this? Whitout resorting to a bunch of man in the middle.
My MQTT app will discover , track status and control HA lights, switches and some sensors and other entities using HAStatestream. It requires a couple of automation scripts to be installed on HA as HAStatestream does not natively support control (HE>HA)
The issue is that HA does not support its own MQTT discovery protocol for exposing/exporting its own devices.
You may categorise this as ‘man in the middle’ I suppose.
I know this me not be what you are looking for but I use node red to control devices in both environments. Example a motion sensor in HA turns on smart bulbs in GA.
This is something I've been looking for too. Not completely, but it can be done for binary devices pretty easily using this integration. You create virtual devices in HE, share them with HA and then sync their state using simple HA automations.
So for example, when a motion sensor triggers in HA, you can have it turn on a virtual switch in HE, and when motion stops, turn the switch off. I would really like to have sensor data into HE and simple binary devices without the need for creating HA automations, but I also am resisting adding brokers. My preference is HE, but HA has quite a lot of integrations that aren't here yet, so it's a nice to have bridge until they are.
Maybe @jason0x43 would be able to do that, but who knows if he'd want to invest the time. Doesn't sound like that's how he prefers to utilize HE. It's a very helpful integration that he did provide though. Thanks Jason!
If you want to have virtual motion sensors and virtual contact sensors trigger on the HE side, instead of a virtual switch, you can use the driver code below.
metadata {
definition (name: "Virtual motion and contact w/Switch", namespace: "logname", author: "smarthomeprimer") {
capability "Sensor"
capability "Motion Sensor"
capability "Contact Sensor"
capability "Switch"
}
}
def on() {
sendEvent(name: "motion", value: "active")
sendEvent(name: "contact", value: "open")
sendEvent(name: "switch", value: "on")
}
def off() {
sendEvent(name: "motion", value: "inactive")
sendEvent(name: "contact", value: "closed")
sendEvent(name: "switch", value: "off")
}
def installed() {
}Thank you for your answers.
@kevin I looked at your app before and I will look again more closely since I may have misunderstood its purpose the first time.
@SmartHomePrimer Your solution seems interesting but like you pointed out it would need lots of automation. I have 36 devices to control. It would mean 36 virtual devices to add. At 2 automations for each real and virtual devices, I would end up with 144 automations to make them work and I'm not sure if those could trigger an infinite loop. Not pretty.
Please corect me if I am wrong but from what I understand someone could write a driver that open a websocket connection to HA and subscribe to state change events allowing for events to be pushed to HE with all the data related to it. Would that make sense?
Edit: Also, the same connection could be used for calling any service on HA.
If 36 devices were on HA (and I'm quite curious what kind of devices do you have 36 of that cannot be moved to HE), then it would be 72 automations and 36 virtual switches. Two for open/close or motion/no motion for most sensors, and two for controlling devices. You may need a few extra automations for devices that will be physically controlled from the HA side and you also need to digitally control them from the HE side. This should be minimal though.
That's not actually that big of a deal to setup (especially in HA where the second automation can be a copy/past of yaml with a minor adjustment to the state) and no, you will not get an infinite loop. I do this same thing right now with HomeKit automations for dozens of devices. It's not that big of deal to setup once. The only thing that cannot be done with this is to get variable data into HE. I've thought about easy ways to accomplish this and there just isn't one right now. However there's also no sensor like a temp/humidity or luminance, etc. that I cannot directly connect to HE. Primary use in my mind is cloud integrations that are not available in HE, and the majority of those will be binary.
There are two simple ways that all device status/state could be fully addressed without setting up an MQTT broker or Node-Red. One would be an HA > HE integration, and that would solve the problem HA to HE only. The best simple way in my opinion would be for someone to develop the same type of integration as the HomeKit Controller integration in HA. Since all the data we need is available to devices that use the HomeKit protocol, then any device or system that can join Homebridge would also be able to share all their device data with HE using such an integration. It's pretty hard now to find a system that cannot expose devices to Homebridge, so if HE could join Homebridge to it as an accessory, just as HA is doing with HomeKit Controller, then the puzzle is pretty well complete, with very little effort from the end user.
Do have a look through the read me in the GitHub repository - the HA section . ITs a little outdated but still essentially valid. If you're still unsure ask away.
MQTT addresses all these issues with just the involvement of enabling the MQTT broker that is available as an addon to HA - and the HE app.
HA effectively utilises a similar connection to MQTT for this purpose as does HE. I use HAStateStream (the event stream from HA).
You can't do this currently as it's a HA specific feature but you may be able to able to achieve this using a variable with the service call name from HE and an (one) automation on HA to watch this and call the service.
well you could but it would be an error in your integration. The same could happen with MQTT if you do it wrong. It's quite hard to determine on an MQTT broker which client updated a topic.
You can with the mqtt app both in and out
Using HomeKit you can't get status change events out of HomeKit itself e.g back into HomeBridge or another client e.g HE when 'other' devices change state except by setting up individual follow on triggers using virtuals in HE.
In HA they reverse engineered HomeKit and so emulate a HomeKit controller and then further relay the devices from HA into HomeKit proper. AFAIK HA is the only controller that can do this but it still wouldn't get devices from HomeKit into HE or from HA into HE - you would need to link virtual devices individually to HE. You can usualy only have only one HomeKit controller practically so if this was offered on HE it wouldn't be useful on HA and vv.
MQTT really is the easy option here bar hoping that someone actually wrote a HA<>HE bi-directional app - one for HA and one for HE. Jason has a very good HE>HA app but no HA>HE.
MQTT is essentially an HE app and happens to provide features that can be used with HA or OH including discovery of devices from HA.
NodeRED would provide a solution too with the HE and OH nodes
LOL. I let that one stand.
You would if you had the exact same type of integration in HE. Yes, it doesn't just join an existing HomeKit controller and get the status. Apple blocks that for security. But it emulates one (minus the iCloud remote capabilities). If HE had the same integration like the HomeKit Controller, you wouldn't be using it on the HA side, but you would be using their HomeKit integration that publishes their devices to the HomeKit Controller type integration on HE. Same idea as what HA can do today. You would add HA to HE as a HomeKit accessory. Any change to the shared device on HE would change it in HA and any change to the device in HA would be reflected on HE. It's how Apple HomeKit hubs work right now (minus the remote access via the Home app).
LOL. It doesn't though
I am not saying MQTT is easy - its just the easiest solution to the original question
HA to HE Reverse Control
Thus the reason I would really like such a thing if it were possible. Installing two integrations and entering an 8 digit code is a heck of a lot easier than setting up and configuring MQTT or Node Red and learning the ropes of those. Thinking about the general users, not what we know or have the capacity, time and dedication to learn. 
LOL. I'll let that one stand.
Setting up MQTT , whilst a new subject to many is not overly difficult and it's an inbuilt HA add on. Discovery and selecting devices in HE is pretty visually easy. Plus you are tied to HA and HE for your integration. Anyway the MQTT option exists at least.
Being under mandatory governement curfew (covid19), I have time to waste so I tried to answer my own question.
It works!
I can control HA switchs with a simple driver I made in HE. No MQTT, no automation on either side and no addon on HA side.
If I can do it with zero programming skills, imagine what a real programmer could achieve.
Well done.. a HA to HE integration will be much appreciated I’m sure.
Ha, you've got some skills if you managed to figure anything out with the sparse developer docs Hubitat has! I actually had no idea that Home Assistant had an HTTP/REST or websocket API until you posted this, but I looked after you posted that and it looked like it might actually be do-able (what I was thinking: similar to the Hue Bridge integration except with real-time updates since the websocket eliminates the need for polling...but similar in the other direction, I suppose). Looks like you just confirmed that!
I've been playing around with some "alternative" Zigbee implementations lately and might give Home Assistant's ZHA component another look (it wasn't great the last time I tried, 2017-2018, just before Hubitat launched). I might see if I can write some sort of integration with this API, assuming you don't take yours farther, if I end up finding any use in it...though I suppose even that might not be a criterion for me since I made a mostly-working DeCONZ integration for myself even though I don't plan on using that long-term. 
That being said, I've used a couple MQTT integrations in the past, and especially now with discovery (originally I had to configure everything in YAML by hand with the exact MQTT topic...), it isn't too hard, either. However, as noted above, you'll need an MQTT broker. With Home Assistant OS or "supervised," there is an add-on you can add with a few clicks that can do this for you. This is their generally recommended installation method, but if you use the "advanced" install with your own OS instead, you're probably comfortable enough to figure something out for that regardless (again something I had to do on my own, though whether it's because this didn't exist yet or I didn't know Home Assistant well enough to tell you the difference between what was once called that versus Hassio, I don't know...though it reminds me of why I switched to Hubitat in the first place!).
Ok maybe my skills are non zero but bearely. If you had ask me 2 days ago what JSON is, I would have answered it is my nephew's first name. And I still don't know how to deal with it. What I did was a patchwork or bits and pieces I collected allover and forcebly bended them into a something more like a proof of concept then a production driver.
The point is that there is a possibility of a simple, self contained solution aimed at HE users instead of clunky use of things made for HA users.
Maybe I could manage to do it myself with a lot of pain and a endless stream of annoying questions on how to do this and that in this forum. I would probably end up with a solution only viable for my setup. In my opinion, it would be far more appropriate if a real developer like @snell or some other would take on the challenge. (sorry I'm fairly new so I don't know who's who around here).
I willing to help as much as I can...
Ha! Real developer?
Thank you for the vote of confidence but I am writing drivers as a hobby and to be helpful. There ARE some real developers in the forum though, so it never hurts to ask around.
Like I said I don't know anybody... Any suggestions?
Well @ymerj, you may not be that impressed with the proof of concept, but I don't picture myself being able to spend a day poking around and put something together that works. This would be a really nice integration to have, but if I really look at the core reason I wanted something like this, it isn't just to bring HA compatible devices into HE, it is so we could use their HomeKit Controller integration. So if we actually had an integration exactly like HomeKit Controller on HE, then we wouldn't need an HA > HE only integration because, not only would we be able to get everything that HA has into HE, but virtually any hub or device out there.
Can you think of devices and hubs that cannot either directly connect through HomeKit or connect to Homebridge via a plug-in? I can think of a few, but the list is very short. And a HomeKit Controller integration like the one HA has wouldn't require that anyone have an iOS or Mac to accomplish bringing just about anything into HE. They wouldn't even need to run HA if they didn't want to.
Ok... I'll work on it. Don't get your hopes too high.
I cleaned up my code and learn about JSON today 
It works amazingly well (It's just an on/off switch though). Not only does the driver control a switch connected to HA but when I physicaly flip it on the wall, its new state is immediately reported to HE.
Now... child devices 
