Hi all, noob question:
I have one led strip set with 2 segments that I would turn on/off independently with 2 buttons.
Is there a (very) easy way?
Hi all, noob question:
Not without code changes. You would need to add support for more than one button.
I suspected it.
Can you point me to di right direction?
I haven’t ported my changes to the latest build (there was a bunch of refactoring since I did that change for 3 buttons and JSON) but it doesn’t look like it will be too hard (mostly mechanical changes).
If anyone else is interested I’ll get it on my do-it-sooner list – all my devices are working OK with the version from late last year and MQTT/HA. The only bug i’ve found so far is I’m setting the flag in MQTT that makes it resend the button status when the connection to the broker is redriven, this makes for some unpleasant effects when I restart the broker.
Are you going to add our usermod to the WLED “library” using a PR?
If you are asking for help on how to fix broker restart unpleasantness, maybe describe in more detail “what happens when”.
Not sure what you’re asking here. I forked WLED in late 2019 and added 3 button support and a way to run macros from the ‘filesystem’ as JSON RPC’s (so you can trigger a ‘scene’ with different json style settings for multiple segments at once from a button locally). Given how it was laid out at the time I didn’t see a way to make it a usermod, I had to change the way wled09_button.ino worked substantially and add support to set/mqtt/xml/eeprom to support the additional macro slots (for the extra buttons and modes). Look at the thread referenced above for more details.
Its all working great for me on a bunch of devices except I messed up the MQTT logic so when you send a button press on MQTT it sets the ‘retain’ flag, which causes trouble if the broker restarts and you’ve recently pressed a button that does something global (I have a long press on 1 button trigger HA to turn off all the lights in the house, so I noticed this goof when I restarted mosquitto and all the lights went off ).
I was offering to port the changes given the refactoring in wled since late last year if someone else was using them and wanted the MQTT fix. There wasn’t any interest in the multi button support/JSON scene support last year so I didn’t spend the time to clean it up for public use or a possible merge request.
I for one appreciate the offer! Since ‘filesystem’ is an actively developed branch, maybe visit there and pose the same offer?
I agree sending buttons via MQTT is a cool enhancement!
Runtime configurable multi button support is on my todo list for 0.12.0.
With that it will be easier to get this to work, but it might still take a while until I can get around to it.
As far as the refactoring goes,
button.cpp is pretty much the same
wled09_button.ino was. Functions that need to be available globally are now declared in
Are you the author of https://github.com/Aircoookie/WLED/pull/1259 by the way?
No, that’s not me. I updated my stuff to the latest master and cleaned it up this weekend. I’ll get a pull request together for it.
I wrote up some docs on what I’ve done and how to build with these features (multiple buttons at compile time, JS= API call that runs JSON API’s on button press, and MQTT button messages) here:
I’ve not done any collaboration with any of you folks so I’m probably missing some customs, I’m happy to move things around if this is worth pursuing.
The multi-button support doesn’t require the filesystem/JSON macro part (see my reply to Aircookie), though its not nearly as useful for local only control of multi-segment strips w/o it. Should I break this up into two different PRs?
I made a PR for this and cleaned it up for public consumption: pull request 1388. Happy to help if you end up using these changes.
Does this handle single and multiple presses for each button as well as the default functions across all if not set?