Did you change anything in your network recently? Are the ST and HE devices on the same subnet? Any VLAN or IOT rules preventing the two hubs from communicating?
When Mira starts (or you hit refresh by swiping down on the Mira device itself), it will attempt to register its IP address and port with HE (the value you see in the Maker API). HE will then use that IP and port to send event updates as they happen back to ST.
You can try using the CLI to log what Mira is doing, although it sounds like outbound of ST is working, just inbound from HE is not. You’d need to debug it on the HE side then.
Looking on reddit i saw a few posts from others having similar problems over the years. I tried fixing it by deleting the mira device and recreating it but that didnt do it either. Had to delete it, unenroll, reboot, re enroll before it worked again.
I spent most of the weekend moving my devices and routines over to hubitat. Now i just export my most used rules to ST as i like the interface better and for wear os support.
Despite enrolling, installing all drivers from the invite page, and seeing the device listed in my hub’s drivers, I cannot locate it using the “add nearby device” feature. It is not being discovered. Any ideas? I’ve already tried unenrolling and re-enrolling.
Since the Edge update occurred years ago (around the time I transitioned to Hubitat), could my SmartThings Hub be in a state requiring a complete reset and re-configuration?
I’m currently on Firmware 000.056.00011. With automatic updates enabled.
I am attempting this remotely through the app without my phone being nearby. I was hoping the hub would find it without my phone. I’ll reboot the hub and attempt it again once I get home from work.
UPDATE: Rebooting the hub and re-enrolling, added the mira hub into my devices page. Never showed a confirmation it was found or created.
I think I’ve mentioned this before but some of this helps to understand how data flows.
If you’re able to get data by refreshing a device on the ST side, then ST is able to open a socket to Hubitat, ask for the current state of the data, and then update. It uses the URL listed on the Mira device configuration for your Hubitat device/Maker API.
If data isn’t auto populating when it changes in Hubitat, that means that Hubitat isn’t able to communicate with ST. It does this by using the IP/port that Mira registered with Maker API when it started. You can see this value by looking at your Maker API for Mira and viewing the “URL to POST device events to” field. That should be the IP address and random port number that Mira started listening to when it started or when the Mira “device” itself was last refreshed.
When Mira starts (or you hit refresh by swiping down on the Mira device itself), it will attempt to register its IP address and port with HE (the value you see in the Maker API). HE will then use that IP and port to send event updates as they happen back to ST.
You can try clearing out the “URL to POST device events to” on Hubitat, saving, then trying to refresh the Mira device. It should repopulate with the current value of the ST hub and the port that its listening on.
Appreciate the response @csstup. Previously everything worked flawlessly for a couple of years, instanteanously in fact, and zero comments on this thread for 6 months got me very confused with some of the “misfires”. As the integration has been rock solid. My only assumption is that the ST engineers have been playing with stuff they shouldn’t be. In fact I’m certain of it. Single devices respond as before, but when I group 3 Mira devices together, on the ST side they no longer reliably update their status, invariably one stays stuck on the incorrect position, when dealing with Mode devices, this can be problematic. I started to separate multiple Mira device calls with 2 or 3 second intervals inbetween, and I’m seeing more reliable results now. Not ideal. I have no hard memory limits on the hub. I wish ST could let you stay on a working firmware.
So in 2026 I’m reflecting on projects and what could still be done with Mira to move it forward or at least fix some of the issues. I’m curious if anyone is even still using it at this point.
I have a version in alpha testing now that resolves a few issues, one of which is the one where devices aren’t created/migrated on a refresh of the Mira device, only on a hub reboot. This was caused by the thread that handles that getting wedged. I also fixed a few other small issues that might have been causing updates to not replicate from HE to ST, but more testing is needed. I added some metrics available on a HTTP address so you can see how much work its doing. And some additional data to help debug any issues.
One thing that I’ve found while testing a few other configurations is that if Maker API on the Hubitat side has a bunch of updates to POST over (the number seems to be 4 or more) within a small window of time, some are simply discarded and never reach ST/Mira. I duplicated this behaviour without Mira even in the loop and posted it over on the HE forums but so far no movement on that. So if you have a config where a bunch of devices all change state at once, perhaps you’re using virtual switches to replicate modes and a bunch all change at once, then definitely some of those updates can be discarded. There may also be some rate limiting happening on the ST hub side, but i’ve not quite gotten there yet.
Anyway, if Mira is actually still useful in 2026 with more features than what I need it for (simple replication of a few devices on HE’s side) then I’m interested in looking more into a Mira 2.0 design where MakerAPI is removed from the loop and a custom Mira app would be installed on HE to facilitate the communication between the two. Other enhancements to 1.x or 2.0 could be things like replicating modes across or HSM state, etc. All dependent on need/interest. Maybe Mira served a need during transition and thats really it. Maybe Hubithings is a better option and supports more features.
Finding the issue where updates are simply dropped between the two explains a lot though. Picture this:
You have 5 devices that all change state due to something (say its presence). 3 of them replicate across but 2 don’t. You try refreshing but sometimes that fails as well. If you then try and change one of the devices thats out of sync on the MIra side, that update will post to HE but if the device is already in that state then it won’t do anything, including not posting BACK to Mira of the correct state. Binary devices are worse with this since the state-space is so tiny.
The last I left it, i had determined that Hubitat will throw POST updates via MakerAPI away if too many of them happen in a short window of time. Doesn’t have to do anything with Mira specifically. I posted on the Hubitat forums for someone to look into it or at least provide some sort of direction but didn’t get any traction.
Did you have issues where things would get out of sync due to a bunch of devices all updating at once? Often its a bunch of virtuals that all fire at the same time for mode/state/presense changes.
Yes, I was having random sync problem with my metering sockets (I know metering is not supported by Mira), and a refresh would normally show the correct state.
I guess, as you’ve reported in Hubitat forum, maybe my power sockets were generating too many events and some events were discarded?
Anyway, I’ve decided to create a Hubitat App (with help from ChatGPT) with similar functions to Maker API, but with some improvements, see screenshots below.
I’ve only created it today, but so far it looks promising!
