Thank you, I was able to find one one git hub and loaded it up. I was able to rejoin the device with this and get it working again. Let’s see what happens wit Smarthings over the next few days.
1 Like
Thanks, Gino. I was able make this work as well. I had some struggles, though, so I want to get this out there in case anyone else has similar issues.
First off, I recommend getting a full charge on all your minimotes before you start the processes below. More detail on that later.
For the minimote that I never force removed from the network, I did exactly what Gino described and everything worked fine: excluded the minimote using general exclusion, loaded the old device handler in Gino’s post, and re-assign the buttons (those still existed in Automations, which was unexpected but nice).
For the minimotes that I force removed from the network during troubleshooting (before finding this thread), it was a different story. I could get them to generally exclude from the network easily enough, but I could not get them to pair at all. I’m not sure which of the following worked, but I eventually got them to pair and they now work flawlessly. First, after troubleshooting for so long, I suspect I ran the batteries down. I’m guessing pairing takes a lot more juice than simple button pushes, and I kept trying that over and over. So I gave them both a full charge. The second thing I did was hard reset the actual minimotes: press and hold the top two buttons (+ and - on V1 under the slide cover) for 10 or 11 seconds until both red and blue LED’s hold steady. I then generally excluded them again, and after that, they both paired just fine.
All that said, I have no idea if any of that worked because of something I did, or if Smartthings did something on the backend. But I’m back up and running and my wife is happy she doesn’t have to go her phone to turn the lights on.
1 Like
Odd - I have 8 v1 Minimotes that I use and all are functioning fine. (I had better not jinx myself saying this!) Hopefully this issue won’t spread, my family relies heavily on the Minimotes!
In fact, I reprogrammed five of them today (moved them from the Button Controller smart app to webCore so I can manage multiple remote programming in one place) and the reprogramming worked fine and they are functioning normally.
I added this old device type version and then just switched the device type for each device and they each started working… switched it back to standard, they stopped working immediately and switched them back to the old version and they started working again immediately… tried to compare versions… looks like new one adds device health code… perhaps that’s where the issue lies…
Yeah, I am having the same Issue, along with several others with both the minimote i just purchased and the 4 button key fob.
I put a ticket in last night, hopefully it gets resolved.
For those still waiting for a fix for Minimotes, you could try Kyse’s DTH to see if it makes any difference (it’s a cool Minimote DTH regardless of whether it solves this problem:
Don’t be afraid to msg me on that topic if you need something updated also. Looks like there have been a lot of changes I haven’t kept up with.
1 Like
I’ll have to take a look at that once I can add mine to my network. Thanks!
Agreed Kyse’s handler will get you going again while we wait. Thanks Jared!
Any reason you wouldn’t just keep using Kyse’s DTH?
The stock DTH runs locally making it a great backup device for controlling things when the internet or ST cloud goes out.
2 Likes
Did not remember that, thanks!
1 Like
Dana,
Theoretically the only reason to switch back is protection against what has already happened. The native device handler should be regression tested wiht updates and would be less prone to a failure. Did not work in this case and it calls into question the regression testing of the platform.
Darren
1 Like
One additional comment relates to what SteveWhite’s comment about the cloud aspect. As far as I know for v1 of the hub everything runs in the cloud so the “runs locally” should only be relevant to v2 of the hub. I am still using V1.
3 Likes
Why are there always issues w/ these MiniMotes? They haven’t change in a long time, I don’t understand why these seem to keep having issues.
Just received a note from support this afternno 1/19 at 1:46pm saying the issue has been resolved. I have not tried yet but plan to this weekend.
Nate (SmartThings)
Jan 19, 11:45 AM MST
Hey there,
I just wanted to check in with you and let you know that the issues you were experiencing connecting or using certain devices should be fixed. Would you mind letting us know if you’re still seeing any similar issues?
If there’s anything else at all we can help you with, or if you’re still seeing this issue, absolutely let us know!
All the best,
Nate
SmartThings Lead Support Engineer
1 Like
Smartthings changed the official device type handlers for most of the button type devices over the last few months as they wanted to change everything to the parent device/child device paradigm which was not being used for the older devices.
So since I was reminded that the stock minimote DTH provides local execution, I put several of my Minimotes back on that handler.
However, it’s been forever since I’ve used that DTH, and the device UI on the Things page is very confusing…can either of you provide some additional info, I don’t “get” this DTH’s UI/settings from the Things screen at all. Appreciate any help w/how this is supposed to work.
:slight_smile
- What is the purpose of the Button 1, Button 2, Button 3, Button 4 listing on the device page - they aren’t active/tappable, and don’t provide any status info. They do show the device has four buttons, which is presumably obvious from the device itself. I haven’t found any way to edit the list, or make this screen in any way helpful. Am I missing something?
- What is the purpose (and source of the info) displayed if you tap the settings (gear) icon for the device? This appears to be related to the push and hold settings of the buttons, but for at least one of my minimotes it does not display what the device is currently programmed to manage. And the order of the items on the screen is very odd, in one case it shows, in this order: Hold 3, Push 2, Hold 1, Hold 2, Push 3, Hold 4, Push 1, and Push 4, and on another I just looked at it has a completely different order of the push/hold buttons.
Also, If you tap the “X” the field clears and has no label or info as to its push/hold button assignment, what to put there, etc. What is this screen for, and how is it supposed to be used?
1 Like
In my personal opinion, they are using the wrong paradigm for this device. But that’s just my opinion, and I’m probably wrong. 
They decided to change it and use the parent/child model, as I mentioned above.
To me, that model makes perfect sense for a device like the zooz power strip, were each individual outlet is individually switchable.
Again, speaking just for myself, I don’t understand why buttons on the remote, where the individual buttons cannot be actuated, would use the same model for exactly the reasons you brought up.
But I was told at the time of the change that it made architectural sense, so there it is. Since it’s an officially supported device and a stock device handler, you can ask support about the UI. I’m sure I’ve missed something, but I just found it confusing.
1 Like
Thanks, JD. It looks like a WIP, frankly, so maybe they just had time to get the underlying parent/child architechure in place, and the UI/interfaces aren’t done.
The parent/child implementation for this results in a very cluttered selection screen when setting up the minimotes, and in one instance I accidentally selected the “button 1” device for one of my Minimotes rather than the device, and that took me a few minutes to figure out why I was only being allowed to program the push/hold for one button!
I’ll see what I can find out, but will wait bit in case someone has figured this out and chimes in. 
1 Like