Minimotes..... ideas?

Hello community! I got 4 minimote’s in the mail today and so far I’m very happy with them.

I’m looking for ideas… what have all of you done with them?

I’m even more excited by the fact that they are locally running devices!

1 Like

They only run locally if they’re used in smartapps that run locally. So not, for example, with Rule Machine.

1 Like

Yeah, I understand that. That goes for all of my other locally running devices as well.

I didn’t realize they ran local until I connected one and checked. That just means some of the things I’m planning to do with them will work even without the internet.

2 Likes

I use them in my car to run routines when I leave and arrive.
I have one in my living room to activate lights, fans, unlock doors - sadly not turn on my fireplace due to challenges doing so.
I have one in my room that I can use to run night routines, morning routines, control bedroom lights, fans, disable sirens if need be, etc.

3 Likes
2 Likes

We love our bedside Minimotes, one each for my wife and I. She knows what her buttons do, and uses them. This is for turning lights down, stopping motion control, and then ultimately all-off at bedtime.

2 Likes

I’ve already programmed one for the wife’s nightstand. I got the Fire TV stick with voice so she could have a voice remote too. I have the Echo remote on my side. She decided to tell me after I got the fire tv stick that she doesn’t like talking to the Echo in the bedroom… so now she gets the minimote and I’ll put the Fire TV stick somewhere else. :neutral_face:

Just a heads up. There are known issues with Smart Lighting and Minimotes. They work, just with a few quirks.

3 Likes

Also a heads up, until they fix the issues, in the thread linked by jsulliweb above there’s an easy workaround to those quirks if you use Simple Rule Builder to check whether the light (or other device) is on or off at the time you press the button and then send the correct ON or OFF command based on that. I think Rule Machine by @bravenel now also works as a more powerful workaround due to the recent addition of triggering a rule on a button press, but I haven’t had time to check it out yet.

I did notice that some of the button presses didn’t do anything. They registered in live logging but the light didn’t respond.

I also noticed that it did it if the second press was within about a second of the first press. So, I just pressed the button slower and it works just fine.

Watching the live logging it seems that based on the fact that ST will not send an on/off command to a device that is currently already in that state, there is no quirk.

Meaning, if the light switch status is on, then ST will not tell the switch to turn on again. So pushing the button once tells the light to turn on, pushing it again tells it to turn off. If the second push occurs before the switch state changes to on in st, then st thinks the switch is still off, thus it ignores off command.

I’m sure this has already been figured out, but I didn’t see it anywhere.

1 Like

Button Controller is also a simple work around since it will toggle the lights correctly. I actually use it for my Iris Smart Fob.

I am just sticking with the SmartLighting for my Minimotes because I like the local running on the V2 hub.
Dealing with the “odd” behavior isn’t that bad, if the light doesn’t come on just click it again.

2 Likes

Gosh this is undesirable behavior (and not to spec per SmartThings Developer documentation!!!).

SmartThings cannot know the current State of a Switch because of non-instant reporting by compatible controllers (including the physical switch itself).

Therefore, if I send an Off Command to a Switch, SmartThings is obligated to send the ZigBee or Z-Wave packet regardless of what it thinks the State already is!

Interesting. I’ve had many discussions of synch issues with support early in the year because ST didn’t broadcast a message if the account had the device recorded as already being in that status. This was particularly an issue I had with the lock that was not reporting status correctly all the time, and I couldn’t get it to lock from a routine because I kept getting the notification that the lock was already in that status. But maybe that only applied to routines?

After your post I went and tested this, and it is working exactly as you describe now.

Back in January, which was the last time I had a conversation with support about it, I was told that if multiple commands were sent, a lot of the motion detector logic would generate dozens of commands, with some really unpredictable results. (It’s the same justification they give for why a routine won’t run if it’s already in the mode it’s going to change to.)

But in any case, regardless of whether it used to only apply to routines or not, you’re obviously right that it doesn’t apply now. So my bad.

1 Like

Bullcrap.

Per documentation:
. http://docs.smartthings.com/en/latest/architecture/index.html

Our basic methodology towards executing a command, such as turning a light switch on, is “fire and forget”. This means that you execute a command, and assume it will turn on in due time, without any sort of follow up.

You cannot be guaranteed that your command has been executed, because another SmartApp could interact with your end device, and change its state. For example, you might turn a light switch on, but another app might sneak in and turn it off.

If you needed to know if a command was executed, you can subscribe to an event triggered by the command you executed and check its timestamp to ensure it fired after you told it to. You will, however, still have latency issues to take into consideration, so it’s impossible to know the exact current status at any given time.

The SmartApps platform follows eventually consistent programming, meaning that responses to a request for a value in SmartApps will eventually be the same, but in the short term they might differ.

And… At least in the Device Handler for Z-Wave Switch; the “State” of the Switch is not checked before sending any Commands. It send the command and gets the result.

def on() {
	delayBetween([
		zwave.basicV1.basicSet(value: 0xFF).format(),
		zwave.switchBinaryV1.switchBinaryGet().format()
	])
}

def off() {
	delayBetween([
		zwave.basicV1.basicSet(value: 0x00).format(),
		zwave.switchBinaryV1.switchBinaryGet().format()
	])
}

I think there’s confusion here between events and commands. ST does not post events unless the state changes (or state change option is true in the sendEvent). This prevents a ton of motion sensor commands because once motion is active, ST doesn’t care until it goes inactive. This prevents SmartApps from triggering without a state change and overloading the system.

As far as I’ve seen, ST will send an ‘on’ command to a device that is already ‘on’. I think you can see this in live logs as long as there is a log statement because you won’t see the event since it’s already ‘on’. Then again the only real confirmation is with a sniffer or if the device sends a response that you log.

3 Likes

Interesting. Thanks for the correction. I ran a test, and you’re definitely right. But I do have support conversations of routines not running from
January 2015 with notifications saying “the device is already…” And no command being issued. This caused difficulties correcting out of synch conditions, particularly for locks.

But obviously at some point this was changed. And perhaps it was only ever an issue with routines, I don’t know.

I’ll fix my post above. :sunglasses:

1 Like

One reason that Button Controller can’t “toggle” 100% reliably is if you use any other method to change the State of the light and that State may not be immediately reflected in the Device Object instance that the Button Controller reads to determine if the light is on or off so it can send the opposite command.

I’ve theorized that if the Device Handler for Switch had a built in additional Command called “toggle()” then it might be useful and more accurate, since the Device Object instance is more likely to know the current accurate state of the Switch … it could send a refresh() to read the current state of the physical Device, for example.

But getting a Capability like Switch considered for enhancement is hopeless around here.

Hey y’all, I’m just now reading this.

Before I got my garage door opener I was concerned that the for would open if it was told to close twice in a row. When I connected the device (nutone gd00z) sure enough if the door was closed and I told Alexa to close the door, the door would open.

At that point I set up a virtual switch and some routines to work around this issue.

Not long after that someone else posted about an issue with their door opener. So, I started digging into mine again. Mostly because I like things streamlined, and virtual switches and routines to open and close a for seemed inefficient.

Well, I deleted all that fancy stuff and was left with the stock device type.

I tested the door and the problem was gone. So, I did more digging. And this is what the live logging tells me when I try to close a door that is already closed.

74c373ce-6611-4c66-af7d-75294a4ef4ce 2:13:02 AM: debug "zw device: 0D, command: 9881, payload: 00 66 03 00 " parsed to [[‘name’:‘contact’, ‘value’:‘closed’, ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Garage Door’, ‘descriptionText’:Garage Door contact is closed], [‘name’:‘switch’, ‘value’:‘off’, ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Garage Door’, ‘descriptionText’:Garage Door switch is off], [‘name’:‘door’, ‘value’:‘closed’, ‘isStateChange’:false, ‘displayed’:false, ‘linkText’:‘Garage Door’, ‘descriptionText’:Garage Door door is closed]]
74c373ce-6611-4c66-af7d-75294a4ef4ce 2:13:02 AM: debug encapsulated: BarrierOperatorReport(barrierState: 0)
74c373ce-6611-4c66-af7d-75294a4ef4ce 2:13:02 AM: debug off() was called treat like Close

EDIT:
But, unless I’m reading this wrong, the behavior is different for lights. I turned on a light, waited a bit, and tried to turn it on again. ST sent the on command to the light… Not sure why? And I’m not totally sure I’m reading it right… here it is…

2:18:17 AM: debug Turn on Sink Light
67baacfc-71ce-4d3f-8882-10748f99e70d 2:18:17 AM: debug update, params: [theAccessToken:f2b9679d-7233-4543-9822-77b10eda4bf6, appId:67baacfc-71ce-4d3f-8882-10748f99e70d, param1:switches, param2:7f644c2f-0e3b-443a-9b27-a53b3d95ce04, param3:TURN_ON, action:[GET:executeSmartAppGet, POST:executeSmartAppPost, PUT:executeSmartAppPut, DELETE:executeSmartAppDelete, OPTIONS:executeSmartAppOptions], controller:smartAppApi, deviceType:switches, id:7f644c2f-0e3b-443a-9b27-a53b3d95ce04, command:TURN_ON], request: [:], devices: [0ae6eacb-51d7-4936-93c8-965800ee4168, 35fcedec-de79-4b68-99f7-e55371c0d3f2, 7845c57f-9cfc-4ef2-9e24-1e0fdad6c737, 7f644c2f-0e3b-443a-9b27-a53b3d95ce04, a3cf380d-feaa-4e8d-bcbb-e4b26829efec, b02a1bbb-142a-4b86-a809-b12bcfc9bc19, e49223be-be62-4446-a483-55e1a33e8d42, 7e2d21ff-d5e6-45b7-bc86-0364bcda012c, 06e1675f-9051-40b2-b49e-a5d22004b81d, d75a4ffa-9ff8-4a37-a548-35863a1964c4, 8c14d7d0-45b0-43fa-86fa-6373c71858b2, 5ceb87fb-f9e0-4c73-8d2e-7e833ce8aca0, 82b69792-2b0d-43fe-ac40-e4526d2d2c4f, 999abf78-b243-47cc-b82d-b37a602d9884, 7d3ade28-2db9-4139-861c-4cf5a69ea4cd, 52ac02c2-0e99-45b1-908d-78743572b867, 66625e4f-0b41-450f-88f0-59f24001aa83, 870d6ed5-0c28-406b-8dcf-cf35b5d0500c, c3fdf493-ec15-40c7-94e7-c08aca0cd05e, 74c373ce-6611-4c66-af7d-75294a4ef4ce, c1e940a1-a8a3-4e37-9acc-8cd4f29a3d33, 6189a2f1-7a20-4221-b178-652f2c8a5e25, 8fdd5844-75c9-4a1c-a558-bf2742473657, 44a7b052-51bd-4e9a-8219-3c708ed04097, bcb9db70-0f3a-4732-8121-0abcf4b6683e, d9a6548d-6e76-4160-b37d-ae3b1b905ee9, 8dbe9da9-3f94-4a0f-86c3-be365328c82c, 40408e3c-eda8-4865-b5ae-7d554548a6eb, 0696f158-a875-459e-afee-ed4d80c924b8, 5db437f0-3c34-40b2-b518-b9c222f49889, 831fc6c1-b287-405c-b8b5-023aca13b2d4, adf24134-92d9-4ef5-a847-9b8e04d1b35f, 434805b6-6075-492c-8a67-c3081ab23287, 2199884b-82a9-49bb-92c5-8e57159908a6, b471c4fc-a7ad-41ab-9aa9-c520d85cba8c] params.id: 7f644c2f-0e3b-443a-9b27-a53b3d95ce04 params.command: TURN_ON

Another EDIT:
The garage door is not running local, but the lights are… Pretty much the every thing I have runs local except for the garage door and a couple of door/window sensors.

I’m not sure if that makes any difference at all… but maybe it does.

Here’s my guesses:

1, lights (Devices of Capability “Switch”) must offer Commands on, off… Not push (that’s Capability Momentary Button)

  1. You can send on to a Switch as many times as you want and it will never make it turn off and vice versa.

  2. A Garage door control, however shou should also just take specific and unmistakable open and close commands, but most garage door physical switches are only Moment Buttons (there isn’t a separate and down button. Just one button that cycles from off to up to stop to down…). So if you press it twice, the second command is very different from the first… So the Device Handler can’t send 2 or 3 Pushed commands a time and know what to get…

  3. Garage door must have a sensor so the Device Handler can tell if open or closed, because then it knows what the push event will change the state.

1 Like

These decisions can be made by an app, irrespective of these other issues. In other words, a Routine certainly could have logic that tested the state of a switch or lock or mode, and didn’t send a command if it thought the device was already in that state. Such an app could be WRONG, due to lag (or other problems), and would tend to FAIL with such logic. ST has had apps that failed from this, including the old Lights & Switches. My impression is that at one point in time, someone in ST thought this was a good way to do things. They were wrong.

The set it and forget it architecture pretty much means what you said above Terry, that you can’t ever know the true state of a device at any particular moment. There is one way to mostly overcome this, and that is with a dedicated app that has 100% control over a device (i.e., no other app touches the device, and the device itself is not touched). In this one case, the app knows the state of the device. However, even this has problems, because the app doesn’t know anything about lag. But, for lighting applications this approach works quite well. Not taking this approach is what created a big bug in Lights & Switches concerning motion activated lights (where they were testing currentValue instead of knowing the value), and may explain some early on reported bugs in Smart Lighting.

Oddly, this is the reverse case problem of toggle(), because it is based on a toggle-like device – the z-wave virtual momentary button used for the relay. With that as a core, even with an open/closed sensor, errors are going to occur due to lag. If we think the door is closed, and we want to open it, we push the button. It may, in fact, have been open, and we just closed it, or stopped its movement. No way out of this one unless you have a true garage door device type with open/close for the door.

1 Like