Since this request closed - [FEATURE REQUEST] - Virtual Button Number Names - I am starting another one to allow others (hopefully) to weigh in. I use buttons extensively to manage states and having to check back to the app each time to see which button does what is quite cumbersome. Having the ability to name a virtual button would be fantastic.
1 Like
I must not understand the question.
In devices, I add a device and name it anything I want.
The example devices that come preloaded even have named virtual devices, including buttons.
Reading your linked original request, I think what you are asking for is to give a text label to the virtual button state? So when you double tap up, and that reports as "Button 1" you would like to replace "1" with text?
I know enough about this to get into ALOT of trouble, but my understanding is the virtual button states on devices are by the device manufacturer. So one switch might return 1 when you double tap up, while another switch might return a 2 when you double tap up.
1 Like
@simon4
I used to used switches and complicated rules to do what I think you want to do.
I recently wrote this to make it more reliable.
1 Like
Kind of... (I submitted the linked topic). I hadn't really thought about how I would like to see it represented in the state of the button device, but maybe button 1, or maybe the name I choose... The bigger thing I was looking for was when I was choosing or having the buttons displayed in say, a rule editor like RM, I would like to see the buttons presented as a list using the names I give them. In the same way on an old-school TV remote you know the buttons as play/pause, stop, fast forward, etc, not button 2, button 6, etc. So if I create a virtual button I would prefer to be able to select them by a logical name that I provide.
Similarly for some situations with physical button devices, where, in some circumstances it may make sense to give each button a name. I take your point about single and double taps and long-holds potentially being very different things, but having the option to name them when it makes sense could be useful.
With virtual buttons I don't ever use the double taps, holds, releases, etc. Since there is no physical device behind it then it doesn't make sense to utilize these - just create another button.
I use the virtual button to create a multi-valued device. For example, I have a button controller setup for each audio zone in the house 1-12 to control the source. The source is 1-6. So when I call it in rules, etc. it is really easy to use because button 1 is source 1 and so on.
But I also have a button controller setup for presets on that zone. For example Button 1 is source 3, volume 35%. And button 2 is source 2, volume 25% and so on. I call these buttons all of the time depending on the time of day, etc. Quiet classical music in the morning and rowdier alternative during the day. When programming rules I select the zone button preset controller and then have to guess what button 1, 2, and so on are.
I just had to do it now and had to open the app window twice so I could setup the rule and figure out which preset I needed.
Admittedly this is not necessarily what virtual buttons were created for, although I am not sure what they were created for. I thought of doing this all with rules and just calling the rule when I needed it. But the buttons are much cleaner.
So naming the button
Your description of needing to open another screen to remember what scene/activity a button number represents, that was exactly what I had in mind when I made my original request.
I also understand what you mean when you talk about not using the double-tap and hold options for a virtual button, another button number makes perfect sense.
With both of those points in mind, the reason I was entertaining the impacts for physical buttons with @calinatl was that I would expect any change like we are suggesting would be a change available for any button not just virtual one's. When you are presented the option to select a button device in an automation, it is looking for devices that implement the appropriate button capabilities, regardless of the driver involved. The naming of the buttons could, I expect, be made to be an optional configuration that could default to the current button 1, 2, etc. The point being, I do not expect changes to Apps like RM and Button Controller are likely to include code that behaves differently depending on the driver used for the button device, rather, allow any button device to record button names as an optional setup... If we get our request 
1 Like
Thanks - I think this is a good way to get around the issue of not being able to label buttons. I will give it a try.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
