I’m having an issue where the Mira driver seems to go to sleep on the Smartthings side after about 36-48 hrs.
Sending state changes from Smartthings isn’t making it to HE.
Rebooting the Smartthings device resolves the matter, for a day or two, then I have to reboot again.
Rebooting the HE doesn’t fix it, it has to be ST.
This looks like the driver version?
Mira 2023-01-23T 16:17:25.89603874
Any idea what’s going on?
I guess Mira isn’t really supported anymore. I’ve been having a lot of problems with the devices in ST losing functionality. Often daily lately. And I’m having to delete the Mira device then create a new token and bring everything over to ST again. Then redo all my routines. It’s becoming routine in and of itself.
See my reply to Virtualwave below. Sorry I didn’t see your post but I’m having the same issues. I’m looking around for a different solution
It is still supported, I’m just not sure what I can do to help. You’ll probably need to look at the logs (use the cli with logcat) to see whats going on.
I use Mira on two different systems daily and rock solid. Same version as what’s in production. And it hasn’t changed in months and months.
Can you possibly point me to a URL where I can read how to do that
I have to say this is a great piece of software, lightweight, and just works. The only time devices get out of sync is obviously when the ST hub gets rebooted.
Overall this is a very useful driver, so thank you. I do have a recurring issue where the initial setup works fine and all Hubitat devices I select are seen in Smartthings, but after awhile if I add a device on the Hubitat side and update (pull screen down) on the Smartthings side they do not show up. I’ve tried hub reboots, creating new tokens, etc… but the only way to get the new Hubitat device to be seen on the Smartthings side is to delete Mira, then rescan to create a new Mira device in Smartthings. That isn’t difficult, but I have to reattach devices to routines which is a pain. Any suggestions on how to address this?
I’m unable to duplicate this behaviour. Since you seem to have a replicable issue, could you use the CLI to attach to your hub and capture the logs while performing a refresh on the Mira device? The forum has details on how to use the CLI for logging if you’ve never done it before.
In this case I added the device called “Water Softener” in the Hubitat app “Maker API for Smartthings 3”, Pressed Update, then Pressed done. Then I updated in Smartthings Mira (by pulling down) and this is the partial log around the event. But, the device “Water Softener (Hubitat)” does not show up in Smartthings.
.
.
.
2025-01-21T21:18:37.148367062Z PRINT Mira device id: 44 ‘WT Lower Bath Toilet’
2025-01-21T21:18:37.148913062Z PRINT Mira cap: ‘WaterSensor’ supported
2025-01-21T21:18:37.149456187Z PRINT Mira cap: ‘Sensor’ supported
2025-01-21T21:18:37.150145062Z PRINT Mira cap: ‘Battery’ supported
2025-01-21T21:18:37.151050145Z PRINT Mira {battery=“100”, dataType=“NUMBER”, water=“dry”}
2025-01-21T21:18:37.152329353Z PRINT Mira device 44 exists, device: Leak Sensor
2025-01-21T21:18:37.162594978Z PRINT Mira skipping migration for profile hubitat-leak
2025-01-21T21:18:37.163173895Z PRINT Mira device id: 236 ‘Water Softener’
2025-01-21T21:18:37.163830562Z PRINT Mira cap: ‘Configuration’ unknown
2025-01-21T21:18:37.164402478Z PRINT Mira cap: ‘Battery’ supported
2025-01-21T21:18:37.164967228Z PRINT Mira cap: ‘TamperAlert’ unknown
2025-01-21T21:18:37.165871770Z PRINT Mira cap: ‘ContactSensor’ supported
2025-01-21T21:18:37.166506145Z PRINT Mira cap: ‘Sensor’ supported
2025-01-21T21:18:37.167075478Z PRINT Mira {battery=“20”, contact=“closed”, dataType=“ENUM”, tamper=“clear”, values={“closed”, “open”}}
2025-01-21T21:18:37.167639187Z TRACE Mira create_device_with_throttle(): {action=“create”, deviceData={attributes={battery=“20”, contact=“closed”, dataType=“ENUM”, tamper=“clear”, values={“closed”, “open”}}, capabilities={“Configuration”, “Battery”, “TamperAlert”, “ContactSensor”, “Sensor”}, commands={{command=“configure”}, {command=“resetTamper”}, {command=“testTamper”}}, date=“2025-01-13T18:00:40+0000”, id=“236”, label=“Water Softener”, name=“Generic Zigbee Contact Sensor”, nameSuffix=" (Hubitat)", room=“Garage”, type=“Contact Sensor Reversed”}, modelName=“Contact Sensor”, parentId=“852cb3d5-32cf-411d-a2f4-2f11b5bb8f8d”, profileName=“hubitat-contact”}
2025-01-21T21:18:37.168624562Z TRACE Mira THROTTLE: Device create throttled: 24 entries pending
2025-01-21T21:18:37.169332812Z PRINT Mira device id: 47 'Sue Garage ’
2025-01-21T21:18:37.169890187Z PRINT Mira cap: ‘ShockSensor’ unknown
2025-01-21T21:18:37.170431020Z PRINT Mira cap: ‘Battery’ supported
2025-01-21T21:18:37.170977228Z PRINT Mira cap: ‘ContactSensor’ supported
2025-01-21T21:18:37.171519978Z PRINT Mira cap: ‘Sensor’ supported
2025-01-21T21:18:37.172054270Z PRINT Mira {battery=“100”, contact=“closed”, dataType=“NUMBER”}
2025-01-21T21:18:37.172874312Z PRINT Mira device 47 exists, device: Contact Sensor
2025-01-21T21:18:37.178362270Z PRINT Mira skipping migration for profile hubitat-contact
2025-01-21T21:18:37.178941895Z PRINT Mira device id: 48 ‘Third Stall Garage’
2025-01-21T21:18:37.179501020Z PRINT Mira cap: ‘ShockSensor’ unknown
.
.
.
At the end of the trace the following entries were made (in case they were important in your debugging):
.
.
.
2025-01-21T21:18:37.272171103Z PRINT Mira cap: ‘PushableButton’ supported
2025-01-21T21:18:37.272794645Z PRINT Mira cap: ‘DoubleTapableButton’ supported
2025-01-21T21:18:37.273346562Z PRINT Mira {battery=“34”, dataType=“NUMBER”, doubleTapped=“1”, held=“1”, numberOfButtons=“1”, pushed=“1”, temperature=“73.80”}
2025-01-21T21:18:37.274681478Z PRINT Mira attr: ‘numberOfButtons’ supported, set to 1
2025-01-21T21:18:37.275266562Z PRINT Mira device 252 exists, device: Button 1
2025-01-21T21:18:37.279359228Z PRINT Mira skipping migration for profile hubitat-button-one
2025-01-21T21:18:37.279931937Z TRACE Mira <Device: 852cb3d5-32cf-411d-a2f4-2f11b5bb8f8d (Mira - Hubitat Hub)> sync_with_hubitat() register post url
2025-01-21T21:18:37.280462770Z TRACE Mira Making GET call to http://192.168.1.58/apps/api/292/postURL/http%3A%2F%2F192.168.1.241%3A43629%2FdeviceUpdate?access_token=
2025-01-21T21:18:37.765772145Z DEBUG Mira Mira - Hubitat Hub device thread event handled
I redacted the “access_token” value for possible security reasons. I can provide more of the log if needed, it’s just very long.
The ‘24 entries pending’ is odd. Its saying that its trying to create the device, but the queue to do creates is 24 entries long (likely from all your refreshes) Something starved/killed the task that is trying to create devices. Mira has to use a queue to create new devices because ST will ignore too many device creates if they happen too quickly.
This gives me something to go on, I’ll see if a change in the ST platform has caused it to kill this task or theres some other bug.
Could the 24 pending entries somehow be related to the number of devices I’m syncing with Hubitat? I have 25 devices working with the new Mira device in my new initial instantiation, and that included 1 that I just tried for the Water Softener device. Something to think about.
Its a convenient coincidence if not, I’ll dig into the code sometime today/tomorrow and see what I can figure out. Any pre-existing device would just be skipped.
You could test the theory - do another refresh with your log running. Does the THROTTLE debug line show the count going up by the number of new devices each time?
I added another device and it went to 26, hmmm.
You don’t even need to add another device on the HE side. Every refresh its trying to add the same ones that it hasn’t added yet since it doesn’t see them.
So yeah the queue task stalled at some point and the refresh routine just keeps adding new entries to the end hoping they’ll eventually get submitted for add.
So, is there something I can do in this case? Is there anyway I can help to diagnose this?
Couple things:
I have a test version you can move to. Just need to join my alpha test channel, I can send you a link.
It doesn’t have a specific fix for this, but it does have reconnect logic in it that should take care of the case of when Hubitat/ST reboot and they are not in sync with each other on power up.
I also looked a little closer at the code, the queue length count that is reported is including both the “create new device” and the “migrate existing device” in its counts. I’m curious which it actually is, so I may enhance that logging.
An interesting thing to do may be to have you join the alpha test channel, and then enable logging on that new alpha driver. Then switch your existing Mira device over to it. That would capture the logs on startup and maybe show why the first devices to create/migrate are stalling the queue.
OK, how do I join?
I have migrated from Smartthings to HA and then decided to use Hubitat for z-wave devices as I gave up on setting up HA to Alexa and Google Home integrations without paying and got the Hubitat for cheap. I noticed the Google Home integration in Hubitat is hit or miss and was now wating to expose all the Hubitat devices to Smartthings for using it’s Google Home integration as that worked very well for me, and in my search I landed on this amazing work, but unfortunately when I am trying to add Mira device to Smartthings, the local scan doesn’t show anything in smartthigns app. Tried from iOS app as well as Android and with mobile device on same Subnet as both Hubitat and ST. What am I doing wrong?
TLDR: I am trying to expose Hubitat devices to Smartthings using this Mira integration but when I scan nearby after enrolling in Mira channel, Smartthings app doesn’t show anything. What could I be doing wrong?
Not sure. Other people don’t seem to have this issue. I can’t replicate it here.
After working fine for a couple months, MIRA has suddenly stopped working for me.
Events from ST → Hubitat seem to work, but state changes from Hubitat to ST does not.
If I try to connect to the event posting URL shown in the Hubitat Maker API, I’m getting a connection refused:
http://172.16.2.102:57633/deviceUpdate
telnet 172.16.2.102 57633
Trying 172.16.2.102…
telnet: connect to address 172.16.2.102: Connection refused
So it looks like the MIRA driver on the ST hub has stopped listening. I have rebooted and power cycled the ST hub but it’s still not connecting.
I have unenrolled and re-enrolled the driver with no affect.
What else can I try?