tobi01001 / led_stripe_dynamic_web_conf Goto Github PK

Implement a selectable "default" mode for starting up...
This would be different from saving the last state in case of resets / restarts in the sense to always start with a default configuration.

This would be useful for applications where power is supplied by e.g. a switch and parameters are rarely modified... (would enable a kind of "offline" use).

Upgrade to ArduinoJson v6.

May use e.g.

• https://github.com/xoseperez/eeprom_rotate
  or
• https://github.com/jwrw/ESP_EEPROM

to possibly increase durability of the EEPROM.

Currently, we usually try to distrbute the color palette over the complete segment. But we could also implement a value how the palette should be distributed over the segment length.
e.g.:
100 --> complete palette from beginning to end
200 --> two times the complete palette
50 --> half of the palette (could look well with mirrored segments)

Currently there are two options being parsed: One for resetting to default values and another to perform a facotry reset (also deletes WiFi config...).

Further, when no or the wrong parameter is provided, the webserver does not send an answer.

Enhancement:

• Add another else if where the current state gets saved and the device restarted (for whatever reason).
• Add a final else where a default resopnse is sent, mentioning the available options (or redirecting to the main page).

See if the setTransition(); function needs to be called:

Maybe we just modify the _blend parameter to enable smooth transition on resuming.

Currelty a mix of German and English. Would be good to have

• English only and as default

• other languages "optional" selected via complile flag.

• need to be checked how to differentiate the web page language... (i.e. button labels)

As suggested in #16 may effects look different depending on the speed selected.

Possible enhancement in there:

• set and store speed for each effect (so every effect could be individually controlled)
• speed factor for each effect (could effect dependen value which acts as parameter for the speed e.g. 1% to 200%) - benefit: global speed control still possible / effective | drawback: even more controls...

If we check the (mean?) "brightness" of the strip and start the sunset with this one (and a minimum?) this could look better....

82d4104 introduced KnobControl in the readme as well. However, it is not described at all what HW to be used, how the HW installation should look like and how to setup and compile the SW.

This needs to be done to enable other to rebuild for their personal use...

The handleStatus function needs to be repaired to reflect all the current parameters...

Currently, Arduino OTA is used. Maybe, when the system is idle we could check now and then if a new firmware is available.
Further, we could check directly during boot if a new firmware is available.

Currently, the json returning all fields with the /all call includes the current values.
As the web page does call the /allvalues afterwards anyway, one of both is rather redundant / obsolete...

Idea:

• as the /all is currently only serving a file, we could make this file rather static (only written when the crc does not match / SW was updated) and not providing the values. The /allvalues call will then return the values for all the fields

Implementation of a (configurable) hostname, also serving as name for the device (to be able distinguish between many not only on IP).

The handling when WiFi connection is lost and during re-connection seems to be not working correctly.
At least once, the ESP was locked up completely / reconnection seemed not to work.

Therefore:

• maybe add a general parameter to Knob Control to be able to disable WiFi completely.
• maybe add a "soft reboot" option
• check and correct the handling in case WiFi is lost.
• Maybe implement a increasing reconnect interval (to not try to connect too often) / complete timeout required?

The "every n millies" behaviour is only required for the flickering and related blending... Effectively we should blend to a certain value which gets updated every x milliseconds. the basecolor should apply dithering for "intermediate" steps/colors (i.e. 128.5)...

Needs to be checked how to realize this.

Sometimes I find one or the other strip as being still lid even if it should be completely off.
Missed to check the /status information from the web interface but on one of the LEDs with display, the power state was "off" and the leds still lid.

To be investigated and fixed accordingly.

As suggested in #16:

Enhancement to implement a custom palette which could be defined by the user on the web page?

Maybe with Colors in HEX-format and e.g. 8 fields...

Testing and impementing some new effects...

Add these two effects:
Pacifica Waves https://gist.github.com/kriegsman/36a1e277f5b4084258d9af1eae29bac4

• Uses three slightly different color palettes. Either check how it looks with just one or modify the base palette on the fly
• speed modification might also be "challenging"

DiscoStrobe https://gist.github.com/kriegsman/626dca2f9d2189bd82ca

• speed modification to be checked / modified

The use of this "diconnect counter" just counts upwards but gives no indication about the "quality".

We should increase by at least four at every check where WiFi is not connected and decrease by one when connected.

Like:

if (WiFi.status() != WL_CONNECTED)
    {
      DEBUGPRNT("Lost Wifi Connection. Counter is " + String(wifi_err_counter));
      wifi_err_counter+=2;
      wifi_disconnect_counter+=4;
    }
    else
    {
      if(wifi_disconnect_counter > 0)
      {
        wifi_disconnect_counter--;
      }
      if(wifi_err_counter > 0)
      {
        wifi_err_counter--;
      }
    }

Also this check is unnecessary here in the loop as this is done during WiFi-Setup:

Idea:
Finally, maybe we can also submit wifi signal strength and channel?

When the sunset is finshed all leds stay at black but the stripe is still considered switched on.
When checking from external, one would expect the state to be actually off (as nothing happens / is shown).

The expected behaviour is to have the stripe being off as well (state and parameters).

Switch to AsyncWebserver internal "edit" functionality. This works mostly in the AsyncEdit branch but needs some improvements:

• switch Async to LittleFS
• list directories
• ...
• may require a fork or local copy of the asyncWebserver library

Seer also #7

Here, code is missing for the active case. This leads to an incorrect JSON string being submitted and problems in decoding by the receiving application...

As suggested in #16 the web application could be split in more pages than just the "index".

This could make the look and feel more structured.
Challenges: Content may be required to be put on several objects or would need a flag for indicating the type of parameter.

The colorpicker and RGB sliders don't get updated on the web page. Needs to be fixed...

Du to the modification of calculating segments and writing the data in d10b14a
, there is less data in the leds array if there are more than one segment(s).

This leads to a wrong calculation of the active LEDs in the following calculation:

Idea:

1. correct by only looping through the first segment and multiplying by the number of segments.
2. provide this as function in the library in case it is needed more often (also makes the code look cleaner).

Changing the Fields to uint32_t could enable the management of setting and getting the solidColor directly. To be checked if there is a certain "tradeoff".

Hello. May be someone can tell me how I can change pixel order in this project?
I have setup, where lighting algorithm need to draw not 1-2-3-4-5-...-NUM_LEDS, but in other order (5-3-6-1-2-8-...).
May be you can say - where I need to paste order changing function?
Example:

const uint8_t otherOrder[NUM_LEDS] = { 106, 89, 209, 47, 166, 154, 50, 217, 75, 116, 200, 33} 
...

 for (uint8_t i = 0; i < NUM_LEDS; i++) {
    uint8_t j = otherOrder[i];
    leds[j] = someRenderingFunct();
  }

Thanks!

Hello! Sorry for pore English.
I think webpage is very hard to manipulate.
May be it would be great if put some settings to additional webpage? For example - there may be such settings as: Color blend type, Color temperature, Reverse, Current limit, Reset default values, FPS and may be some others.
For now - webpage is very hard, as for me.

And one more "to do": it would be great if we are able to save settings for effects. For example, if we set SPEED as 120 - it great looks with RAINBOW effect. But not good with some other.
May be make "speed_coefficient" var for each effects and we would ne able to change SPEED more "looks good" for each effect.

Also, playlist with different setting - great additional functionality, but it need too much code, as I know. But, may be someone can help witn this (I'm not programmer).

Dynamic pallete with three or four colorPIckers - great funct too.
Thanks. You make great project.

As the error counter is reset during WiFi Setup, it cannot reach 40 (which provokes a reset in

Therefore, this line needs to be removed:

Init value will still be zero:

The same should apply to the disconnect - counter in

If not reset during setupWiFi, it will correctly show the disconnects since the last reboot (and populate this via status request).

Currently, the parameters do have a "friendly label" but no friendly name (e.g. the Effect selection is just xxx./set?mo=). To create dynamic menues and readings in e.g. the fhem module, it would be better to have friendly names as well:
e.g.

• colorPalette instead of pa
• effect instead of mo
  ...

This way, the setting and status return can also be simplyfied...

As suggested in #16 there could be a playlist where effects could be selected and ordered.

Currently this is easily possible with external control (i.e. calls to the web-page).

Could be a feature for a future release.