I think HSV (or really just hue + saturation) could be more useful than RGB for specifying the color of a lamp, because the 'V' (value/brightness) is going to vary according to a brightness setting and therefore the overall brightness of a color isn't really relevant, but only the hue and saturation. The RGB value of a pixel would then only be determined just before writing it out to the pixels. Since most people are much more familiar with RGB values, we could allow colors to originally be specified as RGB values, but then convert them to HSV for use internally.

Note This only effects the circuit when using ESP32 module (not ESP32 Devkit)

Problem

ESP32 module is missing several connections on the PCB.

5V signal on EN pin, This should go through a resistor and have a capacitor to ground (as is done on the Devkit circuit).

Workaround

1. Solder a 10K resistor from 3.3 to En pin.

Additional Hardware desires:

• level shifter circuit does not seem to be working. It is not needed and should be removed
• esp32 header pin connections need labels
• the side t esp32 dev kits are attached should be clearly labeled

Lamp network names are restricted to lower case strings with no option for numbers. We should allow more options for more valid lamp names

Discussion:
https://github.com/Lamprichauns/lamp-os/pull/29/files/9334819fc7beebc007373cef4fb56c67c796091c#diff-427528d2c651f4045137088d67fb19caf9eed9556dc9b9875b373aca8cb356d4R12

404

During testing, we've found the multiple behaviors can kick off at once all trying to write pixel values. Without explicit pipelines and methods of organizing animations, this can lead to some fairly jarring, glitchy behaviors. This issue is to look into some control mechanisms for the entire lamp without having to make the code a lot more complicated. Provide an example of a lamp that successfully:

• Fades the lamp in first without interruption
• Runs a long running animation that can be paused and resumed
• Allows for glitch behaviors at any time
• Allows a timed behavior to run on a schedule

As we get more developers creating lamps and animations, we should have a good, simple English example of how to use the animation system in our Readme or contribution docs

high level: Lamps should scan for a specificly named wifi hotspot on occasion (maybe every half hour?). If they find it, they should connect and we should have a way to initiate a update of the core lamp code.

things to consider; we probably want some kind of hashed handshake so people can't use this to brick or hack lamps.