DDP Schemes for Light (5) and WS2812 (15) with USE_NETWORK_LIGHT_SCHEMES

[tony-fav]

Description:

Related issue (if applicable): fixes #

This PR adds new Schemes that has the Light or WS2812 strip listen to a DDP stream (UDP on port 4048). This allows the light to be controlled by external sources like xLights, LEDFx, WLED, etc. In my testing (8x8 matrix attached to ESP32C3 12F devkit) this implementation works for, as expected, ~20 FPS effects smoothly. Folks wanting higher frame rates should obviously use a dedicated firmware as has been suggested in prior feature requests related to DMX/E131, but I am able to achieve quite satisfying effects with this on bulbs (which I prefer to keep on Tasmota due to recovery features) as well as addressable panels to add to existing setups.

To prevent the breaking change in scheme numbering and reduce space use in general, the entire change is wrapped in requiring USE_NETWORK_LIGHT_SCHEMES which when enabled added 1100 bytes to tasmota.bin

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works with Tasmota core ESP32 V.2.0.1.1
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[s-hadinger]

Thanks. My first thought was to reuse Tasmota groups on udp multicast. I didn't know about DSP, if it's standard let's use it.

[tony-fav]

Thanks. My first thought was to reuse Tasmota groups on udp multicast. I didn't know about DSP, if it's standard let's use it.

Standard is here http://www.3waylabs.com/ddp/#Packet%20Format as I mentioned because it's so lightweight, it's gaining traction. xLights support, LedFX support, and can use DDP to have virtual strips in WLED.

[github-actions]

This PR has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[tony-fav]

@s-hadinger was there any holdup on your end for this PR? I know you recently added some UDP functionality to Berry, but these features are broadly useful on 8266s and 32s.

[s-hadinger]

Absolutely not. I suppose this PR was just stuck there for no reason. Let me check with Theo if we can merge it.

Unrelated, there is a need for a pure unspecialized UDP API anyways in Berry. It could be used for more sophisticated animations, but the code would need to be written anyways.

[tony-fav]

Thanks all!