To edit the top label, just click / tap on the location where it would appear. It’s the same for the LED.
I am having a layout problem on the display. This may actually be a firmware issue and not an app issue.
Button+ app: v0.7.44
Button+ V2 with firmware 3.1.8-V2
This is what I have configured, there is a slight alignment issue already here:
The cell for “Lämmitys” is placed at X=0, Y=19 with width 30%, font 2
The cell next to it on the same line is at X=34, Y=19 with width 30%, font 2
This is the same, just changed the cells to have “Standard box with line”.
Now on the physical display (didn’t save the with line box):
Looks to me like the display will now render the box to the Y=19 without the top label instead of with an empty top label.
I think this was fine with V1 Button+, but I upgraded to V2.
Thank you for your help, Adrian. The new layout of the app takes a bit of getting used to, but it’s definitely more practical to work with than before.
Hi Adrian, I have button+ v1 running on 2.0.1. Every time homey restarts the buttons the bottom of my display become unavailable. I need to log in into the web environment to manually add the buttons again. Is this a known issue ?
for some reason I’m also unable to update the firmware…
If you add the buttons via the Button+ web page, Homey will know nothing about them. Then when Homey restarts, it will send the configuration and that will overwrite the manual setup. You need to configure everything via the Homey app as hybrid settings are not possible.
Hi, I think this question was rised here before, but I was not able to locate it, or that may be just a bug in the lates Homey App 0.7.44. I am running Button+ V2 3.1.6, and want to use a single click for on/off and dimm up/down for a long press.
I cannot build up a proper Advanced flow for this as Single click is always firing first and my lights either turn off or go on straight way.
I know that possible the solution is to setup an AND state with either to check if the lights are already on or off. But this adds a much of a complexity and I have 20+ buttons to program.
The other solution that presumably can work is a “Short Press” State (for a single click) in the Flow Cards but look like despite it is stated, it is not available for selection in the dropdown menu
i that in homey, when selecting the display I have no option to modify the buttons of the display. the other button setup works fine
That is a limit of the Button+.
They can provide click events in Flows but that’s all.
I would ask for several things to implement if possible.
-
Sequential repeat “Click” action, when button physically held. You already did this for “long press”, where it even counts the number of repeats. Or
-
Possibility to set Actual delay in ms of how often “long press” button sends the repeated action + possibility to send first event with zero delay from initial physical button touch.
Or at least
- a repeated action tag for the Flow Card “When button [left/right] on [configuration number] was [long pressed]”
Right now “When button [left/right] on [configuration number] was [long pressed]” send just a single non repeated event.
I am trying to build response pattern like it is made on Fibaro Dimmers or Hue Wall Modules where single button operates for everything at once, dimming up/down and on/off.
I am replacing these dimmers with Button+. Right now I am dealing with two flow cards one is “long press” and the other one “released”. These flow card lead to the HomeyScript that interacts with Hue Bridge and responsible for dimming reverse on the second long press . Usage of two flow cards runs multiple instances of the Script and generate unnecessary fuzzy logic.
You probably know that these complex software dimming/on/off logic was not really possible on Homey before and were hardcoded and handled by button’s hardware. “released” event always had a long turnaround time to process. “Ticking” long hold is a dealbreaker
can you try the new test version. It seems the long press repeat was accidentally broken in one of the UI updates. So the check box in the UI should enable the repeat trigger of the the long press card.
Wow that was incredibly fast. But looks like it ruined everything, I am not 100% sure as it is late in the night, but it doesn’t work correct
I did set the Long Press Repeat in the configuration (the one you say was broken), and I didn’t touch standard Delays of 750 and 500ms
Long press for 3-4 seconds using Flowcard "When the [Left button] on the [connector] on [page] long pressed
AND
Long press for 3-4 seconds using Flowcard "When button [left/right] on [configuration number] was [long pressed]” -
sent 40+ events and even caused Homey to Disable the flow as faulty.
I tried rebooting Homey - same behavior
Probably the problem that in the backend “500ms” in treated as 50ms or just doesn’t exit a loop.
I ma using Telegram messages to monitor what is going on with the output
It seems V3 firmware ignores the repeat delay and always send the events every 20ms. I have now published a new test version that handles the timing in the app.
App at 0.7.44 was not sending such burst of “long press” for the Flowcard When the [Left button] on the [connector] on [page] long pressed. But that was on Button+ v2 with 3.1.6 firmware
0.7.44 had blocked the repeat events completely, so I fixed that in 0.7.45. But the V3 firmware was ignoring the repeat delay parameter and firing an event every 20ms, which flooded the Flow cards.
0.7.46 now controls the rate the Flow cards are triggered internally.
Looks like I opened pandora box
On latest 0.7.46
-
buttons are either not reporting State Tag on most of flow cards or reporting Yes on both positions
-
I realized that tags for “When [button] on [configuration] was [state]” just represent just Page and State. So these cannot be directly routed to THEN “turn the button On the [controller] on [page]” this causes a discrepancy between two types of configuration possibilities. (Via page/ controller number and via Cofiguration number)
Actually I would suggest to drop one of the configuration type branches as they are confusing even for advanced users.
Right now there are:
-
MQTT
-
configuration via configuration in the app
-
configuration via address matrix to the controller and Page
I wouldn’t say for all button+ owners and understanding the limitations, but I was really expecting that Pages would simultaneously allow to edit all buttons at once, not breaking them into button configuration lines.
As i spent like 4 days trying to find the best way to set a single button+ in the way that configuration could be quickly moved to other 4 buttons I bought. And I basically wanted
Page 1 - on/off dimming. Page 2 - smart scenes Page 3 - curtains Page 4 - AC controls Page 5 - Heating controlsPage 6 - Audio controls. And setting this up grew into a huge mess with even without state reporting back to button+
Sorry, I don’t understand you requests.
I’m not sure what configurations you are referring to in your number list?
As for the buttons, not everyone has the same number of button bars on their panels and the amount of space provided by Homey for the UI is very limited, even on the web app.
Also, when I first created the app, Button+ didn’t support pages, so I provided that feature via the app.
Maybe one day, now I have cracked the WYSIWYG style, I will have a complete redesign.
From some of your comments, I wonder if you have made use of the device/capability options or if you are trying to drive it completely by Flows?
Instead of building a huge easy to forget “what is what” Flows, I tried to make a virtual multifunctional “Button+ Clone” with virtual 6 buttons and 6 virtual dimmers via Device Capabilities App. And tried to assign these buttons via Button+ App configuration, it didn’t work. Device capabilities in Configuration understands just First Button and First Dimming device out of 6.
I wish could control everything via Capabilities in Button+ but most of them are not discovered in Device Capabilities in Button+ App:
My ACs - Button+ Device capabilities reads only “on/off”, missing: Modes, Fan Up/Down, Swing etc
No Capabilities for my Zemismart Thread and Ikea Zigbee curtains, I am aredy used to have a single button control. When long press activated rolling up/down and single press stops the movement. This can be only achieved via flow or script.
No Capabilities for my Heat it Thermostat - just on/off
No capabilities for my Philips Hue Devices, I have over like over hundred of bulbs that are Integrated via Hue App.
In Hue app there several Global Flowcards with capability to control light Groups where you choose the Room you are controlling from the dropdown menu. This one also cannot be added to Capabilities as this is not a Device - but rather a control pattern. So everything here have to be routed by an endless flows 
I do not know how you extract Device Capabilities from homey to your App, but I thought that asking you to add specific devices capabilities request by a single user is a strange request.
So I just tried to make everything silent via flows and than faced the trouble that I can set controllable long press working anyhow.
And the problem, I cannot suggest how to properly implement long press as there a bunch of options:
Going from 0% to 100% and than reversing, going from 0% to 100% and revesing on the second long press. Going inIncrement or decrement, the step value, the actual value range. This would be collapse in internal of the app.
For the number list. To be short.
I am suggesting to remove options with the control matrix - that are referenced as Controller/Page.
Leave just - Configuration/Page option
The buttons only support boolean and dim capabilities.
However, you have made me wonder if I could add list type capabilities and each button press could cycle through the options. I would need to think about the timing of display updates V capability updates so devices don’t get confused by cycling through options.
Never hold back with requests as often they are things I haven’t thought about. I won’t guarantee I will add everything, but if you don’t ask, I won’t know what users want.
The connector based cards were in the original version when the app was Flow driven, before I thought about configurations.
I will investigate the other issues.
