Extremely Simple Remote Control?

I am trying to find a VERY basic and simple remote control that I can use with Vera. Nothing touch input-based will work - It will need to be just a couple of buttons that are clearly marked. All I need is to be able to get one button to trigger one scene and a second button to trigger a second scene.

Rechargeable is fine, having to use AA or AAA batteries is also fine. Nothing wall mounted. It just needs to be simple. Think along the lines of the remote from the original Firestick, but with fewer buttons. Bonus points if there’s some sort of lighted indicator to show the button was pressed, but not a hard requirement.

Does it exist?

Have you looked at the Aeotec nano mote? I have a couple of their MiniMotes (which they don’t offer anymore) that work very well.
https://aeotec.com/small-z-wave-remote-control/index.html

Update
Hmmm - Seems that I can’t find this anywhere. It’s already obsolete?

It’s touch input, I believe.

I guess I don’t understand what a remote control with buttons is that isn’t touch based.

The Aetec remotes are touch input. Nothing tactile, and no buttons to actually press. The touch devices generally end up supporting short and long touch modes to do different things, and they also tend to require you to hold your finger fairly still.

Think of something like a traditional television remote with its rubberized buttons that you actively press down causing an intermittent contact underneath / inside - THIS is the sort of operation style I am need of.

Does that help clarify?

OK, I get what you’re looking for - but the Aeotec remote I have (the MiniMote) has actual buttons. And you’re right - each button has a press and a press and hold action. I don’t know about the NanoMote. But since neither seem to be available it’s probably moot.

The MiniMote looked like it might be a viable option because it seemed to have actual press buttons. Even if there is a short and long, I could work around that. It was frustrating to have found it only to then find that it was discontinued.

I can’t use “touch screen” buttons of any kind.

I have been using 2 remote controls for several years

  • Hank HKZW-SCN04: 4 buttons and rechargeable battery
  • REMOTEC - ZRC-90: 8 buttons

Second one would be more complicated than I would want, but neither is still available for purchase any how. :frowning:

I just ordered the Hank HKZW-SCN04 here:
Hank Z-Wave Plus Four Button Scene Controller HKZW-SCN04 - The Smartest House

Guess I didn’t spend enough time looking - thanks for the link. I’ll try it and see it will do what I need.

I have had good success with the aeotek quadmote.
Four buttons/switches but very easy to work with

I have also had great luck with them. They are not buttons, though - it is a segmented touch pad. I can’t use anything that uses this kind of technology.

OK… Ordered, shipped, and arrived (super quick for me). I had trouble getting it included until I realized that there is an actual Hank device include option (I was using the generic Z-Wave option). Once included, setup was very easy and I was able to quickly create a scene to toggle a virtual switch from “any” button press. This allows any sort of button press at all to turn things on if they’re off, and turn things off if they’re on.

I’m using Switchboard, created a virtual switch, and then built a manually triggered scene that the buttons operate. No devices are controlled and this is the LUA that it runs to toggle the virtual switch:

status = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",<ID>)
if (status == "1") then
  luup.variable_set("urn:upnp-org:serviceId:SwitchPower1","Status","0",<ID>)
else
  luup.variable_set("urn:upnp-org:serviceId:SwitchPower1","Status","1",<ID>)
end

Replace “” with your device number.

The state change of the virtual switch triggers other scenes that do the actual work.

You should not use variable_set to manipulate the state variables on the virtual switch (or any switch). The correct call would be call_action() with the SetTarget action, like this (turn on shown):

luup.call_action( "urn:upnp-org:serviceId:SwitchPower1", "SetTarget", { newTargetValue="1" }, <DEVNUM> )

A) I would be interested in understanding why - I have used this methodology for years without any issue

B) Why is “variable_get” used, then? Why not a suitable “call_action” for it?

C) “call_action” has never worked for me no matter what I’ve done to try and make it work (which is why I have used and stuck with variable_set for so long)

Generally speaking, changing Status or Target directly using set_variable on a switch is the wrong thing to do. That’s because it does not actually cause action on the switch. If this was a Z-Wave switch, changing the value of Target would not change the on-off state of the switch, and in fact, when the switch is next polled or a Vera restart occurs, the value is likely to go back to the switch’s reported value. Luup’s driver and the switch itself control the value of Target and Status, and the way to ask a switch to (a) change its hardware state, and (b) simultaneously update the state of Target and Status, is to use the action. For a Z-Wave switch, the action causes the mesh dialog with the switch. During that dialog with the switch hardware, Target will be set by Luup to reflect the new desired setting. If/when the switch accomplishes that wish, it will send a report back to Luup which will then update Status accordingly. This is also the way that dimming levels work on dimmers, and similar values on other devices. To put that all in a shorter description: setting the variable will not change the associated physical device (if there is one); calling the action initiates communication with the associated physical device and updates the variables to reflect both goal and actual.

Virtual switches work the same way. If you call the SetTarget action, it will set the desired Target and Status values. In the case of a virtual switch, that may not be different, in your view, from using set_variable, because there is no associated physical device (i.e. that’s why it’s virtual), but in fact there is background logic in the Switchboard plugin (you indicated you are using it, and I wrote it so I can speak to its functions) to handle the additional features like its delay off timer, etc., that will only function when the action is used.

This model comes from UPnP, by the way. Generally in UPnP, you can get values, but you never set them; you use actions to do things and the actions do the setting of values.

If call_action has never worked for you, the most common problem is that you have the parameters incorrect. You have to be very strict with case of the parameter names, and there are some actions/parameters that have inconsistencies in case usage. The parameters also have to be passed in an object/table (as shown in my example), so the syntax is awkward and sometimes troublesome for the new players. The second most common problem I would estimate to be incorrect service ID.

You can go on using set_variable if you wish, but do not be surprised if it doesn’t work for any Z-Wave switch, or physical switches driven by other plugins, or if you decide to use some of the other switch features of virtual switches in Switchboard and they don’t work for you. But being consistent and learning to use the actions will work for both virtual and physical devices, and so that’s my recommendation.

Thanks for the comments/info.

I have used variable_set with both virtual and physical switches and it has correctly changed the state of the switch. But, I do acknowledge the bulk of my use has been against my own ‘private’ variables on devices that I have used for a variety of purposes that are separate from, but related to, the actual operational state of the switch.

The call_action function has always been problematic. What you posted in this thread, as an example, simply refused to work and actually stopped my scene from running -at all-. I was able to eventually get it to work this time by hand-typing everything that was in your original post (instead of copy and paste), but I have no way of knowing exactly what character in the string was causing the original code to fail. In other words, it isn’t just things like variable name and case being correct, but entering the code into the scene editor in Vera is very, very picky about details that apparently are invisible to the naked eye when it comes to formatting.

To be honest, though, I find that quirkiness to be just about everywhere in the UI when entering items manually - copy/paste almost always causes it to fail and manually typing out those long strings are not always easy to get right.

Don’t know if you’re still looking, but the “Zooz 700 Series Z-Wave Plus Mesh Network Remote Control & Scene Controller ZEN34” works very well. I have it and it supports single click, double click, triple click, press and hold, and release events. Works great and is available on Amazon.

Thanks for sharing… interesting idea - honestly not sure how it might have played out. Ultimately, I went with the Hank four scene controller (SCN04) as it had a singular, large, centered button that was easy to find and press and there is no dependency on orientation of the device. Rechargeable battery made it simple to keep working as well.