Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added a usermod for interacting with BLE Pixels Dice. #4093

Merged
merged 4 commits into from
Aug 19, 2024
Merged

Added a usermod for interacting with BLE Pixels Dice. #4093

merged 4 commits into from
Aug 19, 2024

Conversation

axlan
Copy link
Contributor

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
Copy link
Collaborator

@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?

Copy link
Contributor Author 

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
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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
blazoncek reviewed Aug 11, 2024
View reviewed changes
Copy link
Collaborator

@blazoncek blazoncek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

wled00/FX.cpp Show resolved Hide resolved
wled00/FX.cpp Outdated Show resolved Hide resolved
wled00/FX.h Outdated Show resolved Hide resolved
@blazoncek blazoncek added enhancement usermod usermod related labels Aug 13, 2024
@blazoncek
Copy link
Collaborator

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

Copy link
Contributor Author

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

@blazoncek Tested everything is still working. Thanks.

@blazoncek blazoncek merged commit 8a1df1e into Aircoookie:0_15 Aug 19, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@blazoncek blazoncek blazoncek left review comments

Assignees
No one assigned
Labels
enhancement usermod usermod related
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@softhack007 @blazoncek