Added a usermod for interacting with BLE Pixels Dice.

[axlan]

The purpose of this mod is to support controlling effects from Pixels Dice. The board acts as a BLE central for the dice acting as peripherals. While any ESP32 variant with BLE capabilities should be able to support this usermod, in practice I found that the original ESP32 did not work (see the README for more details).

The only other ESP32 variant I tested was the ESP32-S3, which worked without issue. While there's still concern over the contention between BLE and WiFi for the radio, I haven't noticed any performance impact in practice. The only special behavior that was needed was setting noWifiSleep = false; to allow the OS to sleep the WiFi when the BLE is active.

High level features:

• Several LED effects that respond to die rolls
  • Effect color and parameters can be modified like any other effect
  • Different die can be set to control different segments
• An optional GUI on a TFT screen with custom button controls
  • Gives die connection and roll status
  • Can do basic LED effect controls
  • Can display custom info for different roll types (ie. RPG stats/spell info)
• Publish MQTT events from die rolls
  • Also report the selected roll type
• Control settings through the WLED web

The only modification I made outside of the usermod and constants, was a small change to WS2812FX::addEffect() to allow getting the index of the value added with the 255 wildcard. It wasn't entirely clear to me what the behavior should be once the mode vectors pass 255 elements, so I didn't change the current behavior.

[softhack007]

@axlan thanks for your contribution.
I haven't looked into the details of your code yet, so just a few points that I noticed at first glance:

1. you propose a custom platformio_override.ini as part of your usermod. This is fine. But please avoid overwriting the standard build environments (like [env:esp32s3dev_8MB_qspi]). it's better to use a fresh name, for example [env:esp32s3dev_8MB_qspi_dice]. Also you could leverage on the extends = keyword, that allows you to "derive" your entries from one of the standard build envs.

2. you're adding a new partition file which has only 64kb for filesystem. I know that bluetooth features increase program size. We already have a partition file with 256KB filesystem, would this also work? Because 64kb for files is very small, and users with more than a handful of presets would run into problems with 64kb only.

More comments in the next few weeks, as I'm very busy in real life these days.

@blazoncek what's your opinion on changing addEffect?

[axlan]

2. you're adding a new partition file which has only 64kb for filesystem. I know that bluetooth features increase program size. We already have a partition file with 256KB filesystem, would this also work? Because 64kb for files is very small, and users with more than a handful of presets would run into problems with 64kb only.

The 256KB FS partition did not fit this build for 4MB flash chips. Due to the alignment requirements for the app partitions, 64KB was the most FS that could be allocated. However, it's not actually used for the working builds since I only had 8MB ESP32-S3 boards to test. I used it to test the 4MB ESP32 boards I had, but there were other issues documented in the README that cause problems there. I'll add a disclaimer in the README about that partition size.

[blazoncek]

I've experimented with 64kB FS and it is useless except for testing. 128kB on the other hand will work unless user starts creating a lot of presets and uploads various ledmaps or other JSON files.

Regarding addEffect(): I am not a huge fan of proposed change though it seems logical. If you depend on the effects (i.e. call setMode()) then fix effect ID using constants and do not use wildcard 255. Of course that may clash with further additions to built in effects but let's worry when that happens. My suggestion would be to use presets instead and create necessary presets on first run, or let users create them on their own.

Adding BT or BLE has always been controversial due to its size. IMO it is pointless to provide BLE support for anything with less than 8MB flash. Especially for usermods which will require custom compilation anyway.

[axlan]

Regarding addEffect(): I am not a huge fan of proposed change though it seems logical. If you depend on the effects (i.e. call setMode()) then fix effect ID using constants and do not use wildcard 255. Of course that may clash with further additions to built in effects but let's worry when that happens. My suggestion would be to use presets instead and create necessary presets on first run, or let users create them on their own.

For sure using fixed IDs is the easiest way to handle this. That's what I had done initially before I cleaned this up for a PR.

Presets don't totally fit for the use case here, since I want to still be able to use presets to control multiple segments, and setting the effects through the menu is intended only for the currently selected segment. It would also make tracking the state between the web UI and the usermod pretty messy.

At the end of the day, this just needs to be able to detect if the current mode matches one of the usermods "die" modes. Technically, the easiest way to do that without this mod would be to check WS2812FX::getModeData() to see if the pointer matches the name strings for the effect (since it's the same pointer I wouldn't need to do a string comparison). This seems a bit more convoluted though.

[blazoncek]

Presets don't totally fit for the use case here, since I want to still be able to use presets to control multiple segments,

Why not? Preset can have anything form JSON API. Including effect on a single segment or just partial setting.

It would also make tracking the state between the web UI and the usermod pretty messy.

How or why? What makes you think so? Effects are reflected automatically and presets are tracked as well.

At the end of the day, this just needs to be able to detect if the current mode matches one of the usermods "die" modes.

You can do that by using SEGMENT.mode or did you have something else in mind?

[blazoncek]

If you can adjust according to my comments, I have no other objection.

[blazoncek]

@axlan please verify if the usermod and WLED are still working after the conflict resolution.

[axlan]

@axlan please verify if the usermod and WLED are still working after the conflict resolution.

@blazoncek Tested everything is still working. Thanks.