Basic question-how to program mini remote to scenes

[mclowejr]

Hi All,

 

I've had an ISY994i for a few years, controlling the sconce lighting on my perimeter wall.  I recently added some other outdoor  lighting (flood lights) and have them controlled by a 2477D switchlinc.  I also purchased an 8 scene mini-remote, with the goal of mounting it near my upstairs door and being able to turn on/off the wall sconces and the flood lights.  After several firmware updates I finally got the ISY command module to recognize the remote as a remote but now I cannot figure out how to get the remote to control my lights.  I have searched the forum and documentation to no avail.  Sorry for the simple question but how do I go about doing this?  It seemed from what I read  that I add  the remote as a controller to the scene but beyond this I cannot find much else.  (Adding the remote as a controller is ineffective for me but I'm not even sure I did it right.)

 

Thank you for your help.  After reading some of the ideas on the forum I've got plans to automate much more of my home.

 

 

[stusviews]

If you want a button on the Mini Remote to control a scene, then you do need to add it as a controller. As with all battery powered devices, the Mini Remote needs to be placed in linking mode first.

[mclowejr]

Thank you.  I have tried placing the remote in linking mode then adding it to the scene while the remote is in linking mode but to no avail.  The remote continues to be non-functional.  It does light the led indicating it sent a signal.  Is there a way to verify that the ISY is receiving a signal (is there a way to query a remote button press)?

 

When the remote is in the scene it does indicate it is a controller for the light but does not function.

[mclowejr]

Further info: I did confirm that when I press a button on the remote the ISY light does flash indicating receipt of input.  My scene is: Backyard light switch (2477D) and Remote Button A. I have had the remote in link mode when adding to the scene and I also tried having the 2477D in link mode when adding it, all with no success.  I can control the 2477D directly from the administrative console but cannot get any function out of the remote.  Do I need to add some sort of logic program to the scene some how?  Thanks for the help.

[larryllix]

You should be able to see the button status update in the device page in the Admin Console.

 

I don't add my remotes to the scenes. I use a program to operate the scene devices from the mini Remotes though. I add them to SwitchLinc programs so they clone all the actions available from a SwitchLinc Dimmer.

So far, I have 8 different scene that operate from one SwitchLinc Dimmer and mini Remote all from one button/paddle.

 

Off = all off

Fast Off = whites off,coloured lights on then rotate through colour schemes

Dim = low whites and preset colour scheme around rook perimeter

Brighten = bright whites

On = TV mode then toggle with Reading modes.

Fast On = Whites on full and coloured on full white toggled with just perimeter coloured on full white.

 

 

If

   Control from SwitchLinc Dimmer is On

  OR

   Control from Remote.A is On

Then

   turn scene.Reading On

Else --

 

Repeat program for each different scene.

[stusviews]

Requiring a program instead of using a scene is a band-aid at best, in addition to introducing a delay between pressing a button and seeing a response. A program should not be needed. If the Mini Remote button cannot be added to a scene as a controller, then something is amiss. I'm currently using several Mini Remote buttonss as scene controllers.

 

Set the Event Viewer to Level 3, attempt to add a Mini Remote button as a controller of a scene and post the Event Viewer log.

 

BTW, you did add the Mini Remote to the ISY first, correct?

[mclowejr]

Problem solved! I've been working on this for two days. Thanks, Larryllix and Stusviews.  I realized only 2 of my buttons were registering a status (not the ones I was trying to use) in the admin console.  I did a factory reset on the remote and relinked it.  Now all buttons register and I am able to add them to scenes with control. 

[stusviews]

That's really good news

[ndfan77]

I might be missing something, but I'd like my mini remote to toggle the *current* state of a scene (not toggle whatever state the mini controller last sent).

 

From what I can tell, the mini remote has three modes:

• 4 button (the two buttons in each row act as absolute on or off -- which seems like a waste of a button).
• 8 button -- toggle (sends codes that are opposite whatever state the mini remote last issued -- which may not coincide with the state the scene is actually in)
• 8 button (always send the on code, which won't work to turn off a scene when directly linked as a controller)

So how do you get a single button on a mini remote to toggle the *current* state of the scene?  Say for instance, I have some backyard floods already controlled by an on/off switch, and a button on a 8-button dimmer.  If the flood light has been turned on by the 8-button dimmer, how do I toggle them off with a button on the mini-remote (or vice-versa) reliably with just one button push?

 

Seems like this has to be done with an ISY994i program (in order to know real time status of the scene), because when the mini remote is a controller for a scene it has no way to know what has happened to the scene other than whatever codes it has sent -- which may not be accurate when other devices are also controllers, right?  Or am I missing something?

 

Thanks in advance!

[larryllix]

First you have to mentally divorce the modes of the mini-controller with any loads you control. On/Off 8 buttons, 4 buttons, only changes what command codes the mini-remote puts out. Your ISY program can deal with any style.

 

Toggle could be used directly as the toggling is already done. Write a program to detect On, and a program to detect Off codes. You are correct. They could get out of synch if another source of control is being used with that scene or devices. It would only take a second press of that button, in that case

 

I like to use the 4 button mode and detect the signals. Each of the four buttons can now send six commands to ISY. Fast On, On, Fade up, Fade Down, Off, Fast Off.

Your programs can still control one device from one button (of eight sides), They may look a little screwy detecting an Off and turning a scene or lights On.

 

With any style command received it is easy to write two programs to toggle a load. A disabed program needs to be used to avoid oscillation detecting it's own controlled load

 

If

....Control ButtonX is Switched On

Then

....run program (if) Toggle

Else

....---

 

 

Program Toggle (DISABLED)

If

....Load is Off

Then

....Set Load On

Else

....Set Load Off

 

 

Now with my Echoes I don't use these mini-remotes anymore.

[tjkintz]

I do this a lot and suggest a refinement of what larryllix posted. The problem with testing Control is that there are too many possibilities for a key press; On, Off, Dim, Brighten, etc. I found it better to test Status for Off or Not Off. That way, any key press will run the program and that test will be True in all cases. Here is my recommended pseudo code: 

 

If

....Status ButtonX is Off

Or status ButtonX is Not Off

Then

    Enable program Toggte

....run program (if) Toggle

    Disable programTogtle

Else

....---

 

 

Program Toggle (DISABLED)

If

....Load is Off

Then

....Set Load On

Else

....Set Load Off

[tjkintz]

Continuing this thread.......

 

The whole toggle thing is problematic. For some reason, maybe because the keypad had been turned off, the first key press did not trigger a status test in my program. Subsequent ones did. Given that one of the keys is supposed to trigger a program to turn off all the devices in a scene, the missing first key press is a real problem when the devices in the scene are not visible. Did they really turn off? In my case they didn't. This really seems like a bug. 

 

I then changed the status test of Off or not Off to be a control test of On or not On (it could have been Off or not Off too). Logically this should cover all possible cases; not On implies one of the other 8 control possibilities,  Unfortunately the "not" condition never gets detected, just the test for On. Again, this seems like a bug. 

 

Is there a way to submit these to the developers for investigation or do I just hope they read the forum?

[tjkintz]

Edit. I have learned a few things from this thread, https://forum.universal-devices.com/topic/23461-do-something-if-device-is-on-for-x-minutes/ although I don't like what I learned.

 

When testing control, the program will not run unless the key or paddle press is one of the things explicitly tested for. If the program won't even run then it doesn't matter what logic is in the program.In my example of testing control to be switched On, the only thing that will even make the program run is a button or paddle click On. Any other action will simply be ignored. So a mini-remote key that is an Off will not even get the programming running because I tested for On and didn't test for Off. The Not On test will never be true therefore the Else clause will never be executed.

[lilyoyo1]

For the few remotes that I have, I use the 4 button remotes. I use programs instead of scenes. Doing it this way, allows me to double the number of functions from a single remote. I also still keep the individual on/off capability regardless of how lights are controlled. 

 

For example; i have beside lamps next to my bed. A single tap from either remote will turn on the individual lamp. A dbl tap will turn on both lamps. Hitting the off button will turn them off. 

 

Doing it this way ensures the button press (stays in sync in a round about way) always work whether my lights are turned on automatically, via keypad, app, keypad etc. 

[stusviews]

Edit. I have learned a few things from this thread, https://forum.universal-devices.com/topic/23461-do-something-if-device-is-on-for-x-minutes/ although I don't like what I learned.

 

When testing control, the program will not run unless the key or paddle press is one of the things explicitly tested for. If the program won't even run then it doesn't matter what logic is in the program.In my example of testing control to be switched On, the only thing that will even make the program run is a button or paddle click On. Any other action will simply be ignored. So a mini-remote key that is an Off will not even get the programming running because I tested for On and didn't test for Off. The Not On test will never be true therefore the Else clause will never be executed.

 

What specifically doesn't run as intended. I've been able to use either an On or an Off (my choice) to turn other devices either On or Off. So yes, I can turn devices on using an Off signal or even off using an On signal. Clearly something has to occur to turn something on or off, be it a button or paddle press, change of state of a device or variable or a schedule.

[tjkintz]

Yes, I can turn things on or off by testing control for on or off but that doesn't address all the other possibilities. What isn't obvious is that On sets the key status to be 255 and Off sets the key status to be 0. If the user holds the key down longer than a simple click (which my wife and others  habitually do), the status will be set to something between 0 and 255. A program that tests the key for On or Off will simply not run in that situation because it wasn't an On or Off key press; it was some sort of dim/brighten key press. If the program won't run then it doesn't matter what logic is in the program. Conceptually, testing Not Off would cover any status > 0 but the program:

 

If control switched Not Off

Then

do A

Else 

do B

 

Will run if, and only if, the Off key is pressed; all other key presses are ignored. Therefore only the Else clause can ever run.

 

I understand something has to happen for a program to run; my issue is with testing Control.   If I test status Not Off, my program will run for any key that changes the status to any value. I also want to view the key as a pure toggle; if the light is on then a key press will turn it off and if the light is off then a key press will turn it on. This is regardless of what kind of press it was. That is why I normally write the program as:

 

If key status is not off

then turn the lights on

else

turn the lights off

 

This works well unless ISY and the remote get their status out of synch. In that case a key press might be lost. This has actually happened once for unknown reasons. It is also a little confusing in that the color of the LED is likely to be meaningless, especially if the light is controlled by other things. So a red LED could result in the lights turning on and a green could result in the lights turning off. 

[larryllix]

Paddles or Keys do not have a status.

 

As posted elsewhere Not Off will never be true. 'Off' will be when the event happens. Not cause the Else to run because it is now False while being evaluated from the event.

 

In your case posted

• If control switched Not Off
• Then
• do A
• Else 
• do B

'do A' can never happen.  'do B' can.

[tjkintz]

Yes, I know paddles and keys don't have status. However pressing a key does change status to some value. The  point is if the program tests for control switched on and the user holds the key down longer than a tap, the status will change to something other than 255 (on). In that case the test for control switched on will be false. In fact the program will not even run because it was testing for a control switch On but it turned out to be a control switch fade up and that wasn't being tested for.

 

As posted earlier, I want a mini-remote key to be a true toggle. I don't care what they press or how long they hold it and I don't care what the value of status is other than 0 or not 0. That is why for my purposes I don't test control, I test status as follows:

 

If status is not off

then set some switch on

else 

set that switch off

 

Yes, as posted elsewhere multiple times I completely understand what you are saying in your example; when testing control do A can never happen but do B can. That is why my needs are met so much simpler by testing status and not control.

[Michel Kohanim]

tjkintz,

 

Why not use Control Fade Up/Down/Stop?

 

With kind regards,

Michel

[larryllix]

Yes, I know paddles and keys don't have status. However pressing a key does change status to some value. The  point is if the program tests for control switched on and the user holds the key down longer than a tap, the status will change to something other than 255 (on). In that case the test for control switched on will be false. In fact the program will not even run because it was testing for a control switch On but it turned out to be a control switch fade up and that wasn't being tested for.

 

As posted earlier, I want a mini-remote key to be a true toggle. I don't care what they press or how long they hold it and I don't care what the value of status is other than 0 or not 0. That is why for my purposes I don't test control, I test status as follows:

 

If status is not off

then set some switch on

else 

set that switch off

 

Yes, as posted elsewhere multiple times I completely understand what you are saying in your example; when testing control do A can never happen but do B can. That is why my needs are met so much simpler by testing status and not control.

Another thing to note is that Control switched only detects human touch sources whereas status detects any source affecting the dimmer.

 

So it depends on what you want to detect as a trigger.

 

One more - just some gottchas for down the road 

Control Switched On is good for creating retriggerable timers. Once a dimmer is at 100%, there is no detection of Paddle Tap Up any more with Status (level change) detection.

With Control Switched ON it can retrigger the Wait timer and start over each time.