Not sure if this is an ABC question or a Lutron question, or both.
I have a button I named when I added it to the Lutron hub. It now has that name in the ABC app of course.
I'd like to rename it, but not break anything I've setup, is that possible? Rename in Lutron app and ABC button app will get the rename automagically, or ?
Hubitat doesn't care what you have the device named in Lutron or vice versa--they're totally separate. You can rename it in Hubitat (which will use "Device Label" as the display name if specified, which it is by default for Picos with whatever you put into the Lutron app) with no effect. Some people like to rename it in Hubitat's Lutron integration app, at least if they used the "manual"/list set up method, but I've always just done it directly on the device (I don't think changing it in the Lutron app will actually change the device, but some people like to keep the names in sync).
Then there's the app name. ABC by default will put the name of your button device as part of the app name, but (with or without changing the button device name) you can re-name the ABC child app to anything just by changing the "Assign a label:" input in the app.
Great, thanks much. Happy to hear I can muck about and not blow things up. 
Got 'em all fixed, including the Lutron app. If I leave even slightly confusing breadcrums, it always ends up causing me problems later. I'm not good w/the "I'll remember" part. 
Really appreciate your help, in so many areas since I've moved to HE, just fantastic.
I only name them the same so I can keep the dozens of devices straight. Other than that, do whatever makes you happy! 
It is confusing (to me anyway) to have a "living room" Pico in on Hubitat, and a "family room" Pico on the Lutron, and an app that is called "den" all referring to the same device. So I would think some consistency would be good.
Agree, this would be a great addition to HPM. I often recommend this app VS the built in button controller.
I will probably do it eventually.
My concern is that HPM would be another layer to troubleshoot if there are issues. Since I do not use HE anymore and do not have much time to dedicate to coding in general, this would only make any needed fixes or updates take that much longer. In other words..not really a priority for me right now.
Cheater...
Thanks very much, though. I haven't gotten into RM yet, as only moved my devices over to HE today, but will have to dip my toes in.
what did you switch to instead out of curiosity?
Home Assistant
Question about fan control. I'm using the Bond integration for my fans in my home. Those fans have three speeds avaialble on the remotes that came with them, and three speeds are also available in the Bond Home app.
The ABC app offers four speeds, Low, Medium-Low, Medium, and High.
I can select discrete speeds w/out issue - set my fan to low/med/high.
What isn't working is cycling through speeds. that fails. Here's what happens as I send each cycle command:
I'm wondering if the cycle command is working for others, either using or not using the Bond integration for their fans.
Also wondering if everyone else sees those same four speed options in the ABC app regardless of which fan they are using, or if the speeds are supposed to vary depending on the fan.
Thanks!
I responded in the other thread. ABC follows the fancontrol capability as documented. The driver would need to confirm to the capability.
@stephack is there a way to have the ABC app unlock a lock?
the standard button controller can do this, but it looks like this app can only lock?
It was intentionally left off at the time as it was a security concern and the standard for most apps. I wl consider adding this if it is now available on the built in app. Are there any secondary checks using the built in button controller (passcode, etc)?
There are not.
Sounds good, thank you !
Brought this up previously but is it possible to implement StartLevelChange() and StopLevelChange() as separate events based on button pushes?
Context:
I use Inovelli switches and dimmers and currently. their implementation of button presses isn't intuitive.
When the "up" paddle of the switch is held, one would expect that to translate to a "held" button event of button 1. However, it translates to a "pushed" button event of button 6!
When the "up" paddle is released, it should translate to a "released" button event of button 1. However, it translates to a "pushed" button event of button 8!
As you can see, this isn't logical. To fix this and to standardize it with HE, I have had to edit the device driver code each time an update is released to change the button events. However, updates are released often and this is becoming painful to do.
Please would it be possible to change the app so that Ramp Up/Down (StartLevelChange()) can be activated on button "pushed" event (instead of only on button "held" events) and stop Ramping (StopLevelChange()) can be activated on button "pushed" events (instead of only automatically on button "released" events)?
Thanks!
I think it would be "possible" to add this functionality but I have concerns.
I built the changeLevel() functionality based on my understanding of Hubitat's implementation at the time. I tried to make it in a way that the users wouldn't get themselves in trouble setting it up which is why certain options (pushed/released/etc) are hidden based on the capabilities the device's driver exposes. I might be able to code around this but since I haven't used HE in over a year, it would be very difficult for me to test the MANY scenarios of button configs to ensure I don't break anything for existing users.
I know this seems like a simple request (and it just might be) so I will look it over again but my limited time may prevent me from taking the risk. I will also look at the Inovelli driver and try to wrap my head around how they have implemented the changeLevel() capability. I know it's not the best answer at this point, but it's the best I can give.
Would love to understand why Inovelli is not implementing the changeLevel() capabilities like other drivers.
Stephan
Inovelli is--their dimmers respond to startLevelChange() and stopLevelChange() as expected. The problem is really with their scene/button devices (LZW30-SN switch, LZW31-SN dimmer, and probably soon to be more and possible even their old NZW line), where they've (ab)used Hubitat button event naming to use "button 1-5 pushed" events for 1-5 taps on the "up" paddle and "button 1-5 held" events for 1-5 taps down on the paddle. Holds and releases on these paddles are...weird events that I can't remember above but the poster mentioned above, but no case an actual "released" event and also not a "held," at least not with the same button number, since they've already taken those events for other purposes.
Personally, I used to do what the OP did--modify the Inovelli driver to report sensible events from the buttons/Z-Wave Central Scene events instead. 
(To make ABC work with the Inovelli drivers as-is, you'd need the ability to basically choose "Stop Level Change" as its own action instead of assuming that it should happen for the "released" event of a corresponding-button-number "pushed" or "held," so pretty much what you said you're hesitant to do since someone could mess up that setup. RM or BC could do this if the OP wanted, since both the "Start..." and "Stop..." actions are available separately to assign to whatever button event you wanted.)
I really wish Inovelli would change this. I kind of understand why, in that the Hubitat driver seems to have begun as a port of the ST DTH, and STH has fewer button events, plus no matter how you do it there's some disadvantage (including doing it Hubitat's built-in-driver way where you max out at double taps but all the events and numbers make sense) ... but I can't help but feel like this still isn't the best way on Hubitat...
@yototogblo is testing a quick mod I made doing pretty much what you mentioned. I added another option and edited the description of the original ramp option. You now have 2 ramp options:
Option 2 would give all 3 Ramp options (up/down/stop) and allow configuration of all events (push/held/etc)
Download the Hubitat app
