Aeon Minimote Configuration OH 1.8.2?

zwave
Tags: #<Tag:0x00007f51dbb58798>

(Chris Jackson) #6

There’s no real timing requirements - other than the binding needs to be running , and it’s best to leave it a minute or so at least to make sure things are settled down…

@TheKorn might be able to help since he’s got a bunch of these… Remotes tend to be a bit problematic…


(The Korn) #7

Rich I’d be happy to walk you through it. It was a bit of a knock down drag out fight to get these working with openhab 1.8.x, but they can be made to with no problem. Only hitch is I’m traveling through Monday, and I don’t remember it well enough to walk you through it without it in front of me. (Plus writing replies on my phone sucks. :wink: ) So let me get back home and I’ll pick the ball back up.

(What doesn’t help is that they changed the text on the buttons but the underlying hardware didn’t change, so any directions you read have a 50-50 shot of making no sense whatsoever!)


(Rich Koshak) #8

That would explain why the Aeontech manual talks about a Learn button. There is not learn button. :expressionless:

Thanks for the help! I was initially hesitant to try out one of these zwave remotes because I feared they wouldn’t be easy to configure with OH. But when I saw this one for $20 I decided I could take the risk and try.


(The Korn) #9

I’m going to write this up in stupid levels of detail, not because I think you’re an idiot but for people who search and run across this thread. (Plus when it inevitably comes up in the future, I can link back here and say “do that”. :wink: )

There are at least four variants of this remote, possibly more. They all seem to have identical hardware and report identically via zwave as far as device IDs go, and react the same way when you push the buttons despite them being labeled very differently. Version one has the buttons labeled 1,2,3,4. Version two has each button labeled with a square. (Very helpful, Aeon. /s) White/black versions of both exist, etc.

We need a common nomenclature for the buttons. I’m going to go with the original white remote’s button numbering, since writing “hit the lower left square button” is a lot more ugly than saying hit button 3. With the door closed, upper-left is button 1, upper-right button 2, lower left button 3, lower right button 4. If you then open the door, the numbering pattern continues; 5-6, then lower left is 7 and lower right is button 8.

You will need a version of the z-wave binding later than what shipped with 1.8.2. (Any of the 1.9 snapshots after late March 2016 should be fine.)

A complete reset of the device back to factory (and forget any zwave pairing) is done by holding down buttons 7 and 8. The blue and red lights will start blinking faster and faster indicating the safety countdown timer. Once they both go on at the same time, it’ll reset itself to factory.

To pair, throw the controller in pairing mode in habmin. Tap button 8 once. The blue light should be blinking, then once pairing starts blue and red go nutso for a while. (If you just get the red light blinking once, then again a few seconds later, try again.)

Once it’s paired in habmin, you need to wake the device up so that it completes initialization. Hold button 8. The red light will briefly flash, then the blue light will come on. Keep holding button 8 until the blue light is extinguished. If you have the zwave binding in debug mode, you should see NIFs go by and that the node number for your remote has woken up.

Now go into habmin, open up the minimote, and change configuration parameter 250. You want to set it to scene mode instead of blank or group mode.

Finally you need to wake the remote up one more time, so that it fetches the new config.

Congratulations! Now if you tap buttons 1-4, you should see scene info going into the zwave log if you have debugging on. (Or possibly warning messages complaining about unbound events if you don’t. :wink: )

For completeness sake, here’s my item configurations for one of my remotes:

Switch BEDROOM_REMOTE_S1 "Bedroom Remote Short Button 1" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=1, state=1"}
Switch BEDROOM_REMOTE_S3 "Bedroom Remote Short Button 2" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=3, state=1"}
Switch BEDROOM_REMOTE_S5 "Bedroom Remote Short Button 3" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=5, state=1"}
Switch BEDROOM_REMOTE_S7 "Bedroom Remote Short Button 4" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=7, state=1"}

Switch BEDROOM_REMOTE_S2 "Bedroom Remote Long Button 1" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=2, state=1"}
Switch BEDROOM_REMOTE_S4 "Bedroom Remote Long Button 2" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=4, state=1"}
Switch BEDROOM_REMOTE_S6 "Bedroom Remote Long Button 3" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=6, state=1"}
Switch BEDROOM_REMOTE_S8 "Bedroom Remote Long Button 4" (Group_Remotes) { zwave="4:command=SCENE_ACTIVATION,scene=8, state=1"}

And the corresponding housekeeping rule:

rule "turn off any bedroom remote scene button"
when
	Item BEDROOM_REMOTE_S1 changed to ON or
	Item BEDROOM_REMOTE_S2 changed to ON or
	Item BEDROOM_REMOTE_S3 changed to ON or
	Item BEDROOM_REMOTE_S4 changed to ON or
	Item BEDROOM_REMOTE_S5 changed to ON or
	Item BEDROOM_REMOTE_S6 changed to ON or
	Item BEDROOM_REMOTE_S7 changed to ON or
	Item BEDROOM_REMOTE_S8 changed to ON
then
	{
		postUpdate (BEDROOM_REMOTE_S1,OFF)		
		postUpdate (BEDROOM_REMOTE_S2,OFF)		
		postUpdate (BEDROOM_REMOTE_S3,OFF)		
		postUpdate (BEDROOM_REMOTE_S4,OFF)		
		postUpdate (BEDROOM_REMOTE_S5,OFF)		
		postUpdate (BEDROOM_REMOTE_S6,OFF)		
		postUpdate (BEDROOM_REMOTE_S7,OFF)		
		postUpdate (BEDROOM_REMOTE_S8,OFF)		
	}
end

I’m thinking you might be able to get away with using autoupdate=false in the item definition and then skip having a rule entirely. But this works 100% and really doesn’t have a downside I can see, so I’ve had little reason to optimize it.


Repeated z-wave scene activation in rules engine?
Zwave Scene Number - Command or Update?
(Rich Koshak) #10

I’ve never done that before. :stuck_out_tongue_winking_eye:

I never would have figured out the middle part on my own. Thanks a million for posting this. I’ll report back when I have success.


(Rich Koshak) #11

It works!

A few things to note/emphasize for future readers of this post.

I had to make sure the Minimote was in the same room as the Controller for the initial pairing. I tried it from the next room and it just sat there blinking its light.

However, once it paired, this time it completed the full initialization without my needing to wake it up like described above. Clearly YMMV.

When I changed Configuration Parameter 250 to Scene Mode Habmin (and an older still works with OH 1 Habmin2) both still showed the change as pending even though the logs said that there were no messages to send. So watch the logs (I found it useful to tail -f /var/log/openhab/zwave.log | grep "NODE 15").

I also want to emphasize a few things about the Items and the rules.

Odd numbers are short press and even numbers are long press so this four button remote can actually control up to eigtht things! Not bad for $20.

In rules you MUST use the changed to ON as your trigger. If you use received update your rules will trigger more than once. I was seeing three updates for each short button press.

If you use received command your rule will never trigger.

Because the rules trigger on the change, you must clear the Item back to OFF once it changes to ON. However, beware of timing. I thought I was going to be clever and use a Group to make my reset rule easier to write and expand later. However it was resetting the Item back to OFF before all of the ON updates were processed causing the Switch to turn ON twice per button press. A nice little Thread::sleep(500) fixed that.

My Items:

Group gMinimote
Switch Minimote1_Button1_Short (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=1,state=1"}
Switch Minimote1_Button1_Long  (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=2,state=1"}
Switch Minimote1_Button2_Short (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=3,state=1"}
Switch Minimote1_Button2_Long  (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=4,state=1"}
Switch Minimote1_Button3_Short (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=5,state=1"}
Switch Minimote1_Button3_Long  (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=6,state=1"}
Switch Minimote1_Button4_Short (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=7,state=1"}
Switch Minimote1_Button4_Long  (gMinimote) {zwave="15:command=SCENE_ACTIVATION,scene=8,state=1"}

Usage rule (you can see my failed attempt to get Dash buttons working, the lambda is ommited):

rule "Trigger Garage Door Opener 1"
when
        Item T_D_Garage1 received command or
        Item Minimote1_Button1_Short changed to ON
//      Item T_D_Dash_Tide received update or
//      Item T_D_Dash_Bounty received update
then
        openGarage.apply("1")
end

rule "Trigger Garage Door Opener 2"
when
        Item T_D_Garage2 received command or
        Item Minimote1_Button2_Short changed to ON
then
        openGarage.apply("2")
end

The reset rule:

rule "Reset minimote switches"
when
        Item gMinimote received update
then
        gMinimote.members.forEach[ button |
                if(button.state == ON) button.postUpdate(OFF)
        ]
end

With this approach when/if I add more of these all I have to do is add the new one’s Switches to the gMinimote group and they will automatically be reset without the need to change any of the code.

Thanks so much for posting this!


Having trouble getting fibaro keyfob working
(The Korn) #12

Huh, interesting. I paired mine both sitting a few feet away and one floor up (but directly above). In both cases I had to manually wake up the remotes before any of them would complete initialization.

YMMV indeed! None of mine auto completed initialization; they all required being woken up manually.

Oh yeah, sorry… forgot to mention that the configuration on these things is write only. So while habmin can change the config on them, it can’t ever verify that the config was successfully changed by reading the value back. (That was part of what @chris had to accommodate in the binding.) So until you reboot it’ll always show as a pending change for that remote.

All in all it’s a pretty hot little remote for $20! Very tiny, very lightweight, and even with heavy use I get about two months between charges. Since it’s zwave it doesn’t need line of sight and is happy jumping through the mesh to get back to the controller. Only bad thing I’ve found is that the numbers eventually wear off the buttons. (Along with the printing on the back that says what it is!) Maybe that’s why they went to squares eventually. :smile:

Huh, interesting that you ran into this and I didn’t. Then again thinking about it the way I have my rules set up I don’t think I’d notice if they were executed twice in a row quickly. I’ll poke around into this and see if I’m getting doubles when I get a chance.

Happy to help!


(Rich Koshak) #13

I think it may be a bit flakey when it pairs. The three other times I tried to pair it while in the same room it never woke up to generate the node.xml file. Maybe starting the pair from the other room then walking into the room with the controller was the difference.

Ahhhh, OK that makes some sense. I was worried about it not taking the config change so I was watching the logs like a hawk and noticed the Minimote was waking up and no messages were pending so I went for it and it worked.

Indeed. I’m going to test the range when I get home this evening. I’m actually using it as a garage remote control so as long as it works from the driveway I’m golden. $20 is WAY better than $200 for a new garage door opener or even $40 for a new controller, assuming it would work with my opener which in my case it won’t because the opener is too old. I might get another couple for the lights and such and with the eight equivalent scenes one can control a lot with them.

I usually write my rules so they can handle multiple triggers for one “event” too but in this case I am opening the garage. So when turning on the light it doesn’t care if it gets turned on twice, but turn the garage on twice and it stops opening. That immediately made it apparent what was going on.

I should also note that when I initially wrote my resetting rule similar to how you did I did not see the timing issue. It was only when I moved to using that group that I started to see the problem and had to add the sleep.


(Colin) #14

Thank you TheKorn for the detailed write-up and rlkoshak for your tips and examples. From your posts I was able to get my Minimote up and running on the first try, frustration free. Thanks!

Also, if you have access to a 3D printer, I found a few designs out there for a wall mount.


(Ingo) #15

THANK YOU!!!

I’ve been fighting with mine for months, stubbornly refusing to give up… Well, actually, I gave up 20+ times.

Following your procedure (except for having to do two wake-ups instead of one each time) worked! I can finally convert this thing from a paper-weight to something useful!


(AG) #16

Is anyone using this with MIOS binding? Trying to figure it out…


(tcgerhard) #17

I’m also trying to get the MiniMote working. The binding is recognizing it - if I wake it up by pressing and holding the learn button, zwave.log shows packets being received from the controller; it also updates the last packet received time that’s visible in habmin.
When I press any of the top 4 buttons, however, there is no indication by OpenHab that anything has happened - nothing at all in zwave.log, busevents.log, or the stdout log.

I’m using the 1.8.3 version of the zwave binding on the 1.8.1 runtime.


(tcgerhard) #18

It looks like the problem I’m having is with the remote – I stopped OH and cat’ed the tty port for the stick; when I press buttons 1-4, nothing is received; when I press and hold button 8 to wake the remote up, I see data.


(Nick) #19

@tcgerhard – I got stuck in the same place that your described, am also using Openhab 1.8.1 with the 1.8.3 zwave binding. This may have just been my lack of Habmin knowledge, but I was experiencing the same behavior you described and narrowed my issue down to getting the parameter 250 update to stick. Ultimately, what worked for me was waking up the remote (hold button 8), making the parameter update in Habmin (double click off to the right of the parameter and select scene mode from the dropdown, the fields turns yellow), then waking the remote up again. After I did that - everything worked as @TheKorn and @rlkoshak described above, thanks to them for all of the detailed info on this remote!


(tcgerhard) #20

Hmm, still no luck. I’ve tried waking it up several times, including a few times right next to the controller, which does seem to add a time of blinking the blue LED after waking up.
When I press a Scene button, both the blue and red LEDs light – is that the expected behavior?
I also tried setting the individual buttons to scene mode (params 241-4).

I will borrow my wife’s PC tomorrow and try reloading the firmware; hopefully that will help.


(Nick) #21

Yep, I get the red and blue lights when I press a button.


(The Korn) #22

Just out of curiosity, did you ever get this to work?


(tcgerhard) #23

I did not. I just migrated everything except ZWave to OH2, so I’ll config that and try again soon.


(The Korn) #24

Ahhh. I was going to say from your description it sounded as though option 250 never got set. If it’s not set then the minimote will try and talk to associated devices directly (…of which there are none) rather than send scene info to the controller.


(tcgerhard) #25

I have zwave up and running on 2.0 and still having the same difficulty. I agree that it sounds like 250 is not getting set. I’ve tried multiple times, and OH seems to be trying to send it, but the behavior doesn’t change.