No, unfortunately you’ll have to install every HA device you like on Homey, just like the way you would install any device on Homey.
This is due to the way Homey handles new devices: 1 at a time.
First you need to connect HA community app to HA, as explained at the app store:
and at the app topic:
The other way round, it works like you expected: as soon as MQTT is configured and in place, all Homey devices are available in HA.
This is going to be a bit of a long post, but I have an issue and I really have no clue what to try next. Any hints would be really welcome.
My Setup
My Target
I want to expose devices like shades and lights which I have configured in Homey to HA so that I can use the with the Voice integration from HA. I have no interest in exposing devices from HA to Homey.
My Issue
Basically everything works, HA discovers the devices and I can control most of them. However, there are some for which the commands don’t make it through from HA to Homey.
It’s always the same devices which fail, but it’s not a specific kind of device which fails work. Both my Kitchen Light and my Bedroom Light are Shelly Dimmers, the Kitchen Light always works, the bedroom light fails.
The status changes from Homey to HA always works. If I toggle the Light in Homey, the correct status is always correctly reflected in HA. The issue is only when controlling a light within HA.
I am currently assuming that the issue is within MQTT Hub for the following reasons:
MQTT Hub Logs when it works:
MQTT Hub Logs when it does not work:
I am clueless on what to do next, I tried reconfiguring everything including removing all devices from home and completely re-installing the plugins on Homey
After some further hints, here are the Mosquitto Logs. Doe these say that the connection in between Homey and Mosquitto is unstable? 10.1.1.6 is HA, 10.1.1.9 is Homey.
1746980635: New client connected from 10.1.1.135:52823 as 7vOJ9ukClfOpl7aUl4dVKe (p2, c1, k60).
1746982975: Client 7vOJ9ukClfOpl7aUl4dVKe disconnected.
1746982975: New connection from 10.1.1.135:39815 on port 1883.
1746982975: New client connected from 10.1.1.135:39815 as 4d1oIeVIFqAkzVecFnNlj2 (p2, c1, k60).
1746985075: New connection from 10.1.1.135:34917 on port 1883.
1746985075: New client connected from 10.1.1.135:34917 as 3T57ldqJBJh7lHP1UZcJGt (p2, c1, k60).
1746985075: Client 3T57ldqJBJh7lHP1UZcJGt disconnected.
1746985075: Client 4d1oIeVIFqAkzVecFnNlj2 disconnected.
1746985075: New connection from 10.1.1.135:47801 on port 1883.
1746985075: New client connected from 10.1.1.135:47801 as 0ppBhTh1htYqwT5Y6qKeM9 (p2, c1, k60).
1746985081: Client 0ppBhTh1htYqwT5Y6qKeM9 disconnected.
1746985081: New connection from 10.1.1.135:47845 on port 1883.
1746985081: New client connected from 10.1.1.135:47845 as 1Kk3mRW0SHbvZsIy75pnJ5 (p2, c1, k60).
1746985731: Client 1Kk3mRW0SHbvZsIy75pnJ5 closed its connection.
1746985784: New connection from 10.1.1.135:47141 on port 1883.
1746985784: New client connected from 10.1.1.135:47141 as 5MoNONN7ryt2DCkgibBsbm (p2, c1, k60).
1746988266: Client 5MoNONN7ryt2DCkgibBsbm closed its connection.
1746988319: New connection from 10.1.1.135:33369 on port 1883.
1746988319: New client connected from 10.1.1.135:33369 as 6f9U4lmD1H0qKzNvRzfAeb (p2, c1, k60).
1746990277: mosquitto version 2.0.20 terminating
1746990325: mosquitto version 2.0.20 starting
1746990325: Config loaded from /mosquitto/config/mosquitto.conf.
1746990325: Opening ipv4 listen socket on port 1883.
1746990325: Opening ipv6 listen socket on port 1883.
1746990325: mosquitto version 2.0.20 running
1746990325: New connection from 10.1.1.9:56292 on port 1883.
1746990325: New client connected from 10.1.1.9:56292 as homey_22c18dc0 (p2, c1, k60).
1746990328: New connection from 10.1.1.9:54442 on port 1883.
1746990328: New client connected from 10.1.1.9:54442 as Homey_edf6ee (p2, c1, k60).
1746990330: New connection from 10.89.1.1:34452 on port 1883.
1746990330: New client connected from 10.89.1.1:34452 as mqttjs_cb1cf406 (p2, c1, k60).
1746990342: New connection from 10.1.1.135:51793 on port 1883.
1746990342: New client connected from 10.1.1.135:51793 as 3uJNvwDL4169WOzuHGd8k5 (p2, c1, k60).
1746991007: mosquitto version 2.0.20 terminating
1746991054: mosquitto version 2.0.20 starting
1746991054: Config loaded from /mosquitto/config/mosquitto.conf.
1746991054: Opening ipv4 listen socket on port 1883.
1746991054: Opening ipv6 listen socket on port 1883.
1746991054: mosquitto version 2.0.20 running
1746991055: New connection from 10.1.1.9:34734 on port 1883.
1746991055: New client connected from 10.1.1.9:34734 as homey_22c18dc0 (p2, c1, k60).
1746991057: New connection from 10.1.1.9:34740 on port 1883.
1746991057: New client connected from 10.1.1.9:34740 as Homey_edf6ee (p2, c1, k60).
1746991059: New connection from 10.89.1.1:45474 on port 1883.
1746991059: New client connected from 10.89.1.1:45474 as mqttjs_bf65d5de (p2, c1, k60).
1746991074: New connection from 10.1.1.135:52821 on port 1883.
1746991074: New client connected from 10.1.1.135:52821 as 3La3mEi5fQEjE8ooq3qSZ1 (p2, c1, k60).
1747031917: Client 3La3mEi5fQEjE8ooq3qSZ1 closed its connection.
1747031944: New connection from 10.1.1.135:47899 on port 1883.
1747031944: New client connected from 10.1.1.135:47899 as 5ymzk3wQOpC4QtdoYeaLh6 (p2, c1, k60).
@moderators I think this is a MQTT Hub issue. Please move to app topic: https://community.homey.app/t/app-pro-mqtt-hub-community-version/113463
@chixxi1 Is it possible to temporary run the Mosquitto MQTT Broker HA add-on, to see if the broker is the problem?
(To eliminate possible issues with Podman).
What do the Mosquitto logs of the current broker @ Podman tell?
I agree, this can be moved over. Sorry for posting in the wrong place!
Will add the Mosquitto logs to the intial post. I assumed that was not causing the issue since the MQTT Hub logs actually show the messages coming in, even when it is not working. But I’ll try.
No problem.
I’m no MQTT expert, maybe MQTT Hub dev can help pinpoint the issue.
About the broker logs, the only unusual thing is this occurring multiple times:
This possibly sounds like a restart loop?
The other “disconnected” and “new connection” entries seem to be normal for a broker.
You are right, I need to figure out if the MQTT Broker is causing any issues. Based on the logs from the MQTT Hub Plugin I was maybe a bit quick with my conclusion.
However, I can really not explain to myself how it could be that only some device are affected. My Kitchen Light is a Shelly Dimmer, my Bedroom Light is a Shelly Dimmer. The Kitchen Light always works, the Bedroom keeps breaking.
If this was about connection issues in general, I would expect all devices to be affected.
Well, that’s the hard part, when only certain devices are affected… maybe the wifi connection to the Shelly bedroom light needs some 
I hate the trouble maker Wifi, but in this case that is not the cause of the issue. I can fix it 100% reliably by checking and unchecking it in the MQTT Hub Plugin, this can not fix Wifi. All connections in between Homey, Mosquitto and HA are wired. Also it is working 100% reliably when controlled from Homey.
I meant the Shelly > router connection might be having issues 
Got that one figured out yesterday, pretty obvious now:
I started realizing that I can not make all devices work at the same time in a single room, even with my Enable/Disable device work-around in the MQTT Hub Plugin. After more testing I realized that in my Bedroom (where I have the least devices), only one device would work at a time and it was always the last one enabled MQTT Hub Plugin.
The problem was that I had multiple devices with the same name. I do not put the device type in my device name on Homey. That means my curtain, my shades and my light in the bedroom are all simply called “Bedroom”.
These all showed up as separate devices in the MQTT Hub Plugin on Homey, they also show up as separate entities in Home Assistant with unique names. But in Home Assistant these entities were assigned to the same device.
I removed the MQTT service in HA, renamed the devices in Homey, rebooted everything and re-added the devices to HA. Now everything is working.
Quick summary: Make sure your devices in Homey have unique names.
Glad you found the issue!
Uhh yes, I would never come up with the idea to name two devices the same, but it is no problem doing this @ Homey. Same goes for flow names.
Could I use this for HA to watch my Homey Pro if it crashes?
Sometimes Homey Pro crashes during backup and it would be great if HA can notice this and restart the shelly plug my Homey connects to.
Hi Marcus,
Sure. You can monitor the online state with the Ping integration
Add Homey’s IP address and you’re done
I adjusted the state change interval to 15s,
Example automation; it sends a notification to my phone, and it power cycles a zigbee plug; and it sends a persistent notification of the kind of offline state (Offline/Unavailable/Unknown):
alias: Homey2 Connection state
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.192_168_12_34
from: "on"
to: "off"
id: x
- trigger: state
entity_id:
- binary_sensor.192_168_12_34
from: "on"
to: unknown
for:
hours: 0
minutes: 0
seconds: 15
id: "??"
- trigger: state
entity_id:
- binary_sensor.192_168_12_34
from: "on"
to: unavailable
for:
hours: 0
minutes: 0
seconds: 15
id: "?"
conditions: []
actions:
- choose:
- conditions:
- condition: trigger
id:
- x
- "?"
- "??"
sequence:
- action: notify.mobile_app_phone_peet
metadata: {}
data:
message: >-
Online state: Offline, Unavailable or Unknown. A power cycle is
activated @ {{ now().strftime("%d-%m-%Y %H:%M.%S") }}
[Automation Homey2 Connection state]
title: Homey2
- type: turn_off
device_id: fe7e72a0a2e774ae05262a935ac5f886
entity_id: df33f8acca6170f3bab92b19c7e73397
domain: light
- delay:
hours: 0
minutes: 0
seconds: 15
milliseconds: 0
- type: turn_on
device_id: fe7e72a0a2e774ae05262a935ac5f886
entity_id: df33f8acca6170f3bab92b19c7e73397
domain: light
- conditions:
- condition: trigger
id:
- x
sequence:
- action: persistent_notification.create
metadata: {}
data:
title: Homey2
message: "Online state: Offline"
- conditions:
- condition: trigger
id:
- "??"
sequence:
- action: persistent_notification.create
metadata: {}
data:
title: Homey2
message: "Online state: Unknown"
- conditions:
- condition: trigger
id:
- "?"
sequence:
- action: persistent_notification.create
metadata: {}
data:
title: Homey2
message: "Online state: Unavailable"
mode: single
Notification example:
Oh, the irony of having Home Assistant restart Homey each time it crashes… 
Yep 
I call them HAmey
Offtopic, @Marcus_Bitterling now how can we restart the Homey backup creation automatically after the initial failure, I never noticed a “Start backup procedure" flow card 
But instead of using workarounds to solve the main issue: this was reported by several users, and should’ve been solved by various updates, v12.4.8 being most recent > So, when your Homey runs v12.5.x I recommend to report your issue to homey.app/support
Hi Peter,
Thanks for the workaround with ping. That’ll work. I’m new to HA so not quite up to date on all functionality.
I know about the problem in the stable versions, I was one of the reporters. However I’m running beta version 12.5.2 and the problem seems to appear now and then. I could go back to the stable version off course but if I can solve this for now with this workaround I can keep testing.
Obviously it’s impossible to start a reboot flow on Homey when it’s crashed but I’m not sure if you meant that in your last post. Thanks for your help!
YW!
I meant to automatically (re)start a backup after it failed, and Homey has been power cycled by HA.
There is no “start backup prodedure" flow card afaik. (When we request for one, Athom propably would respond with: “There’s no need, backups are created automatically each night”) 
I see what you mean. Thanks
