refactor/deprecate - hardware module

[JarbasAl]

the hardware module was ported from the mycroft mark 2 in order to implement the mk2 enclosure, but it has some problems

• unlike everything else in this package, this does not provide a plugin class to be used in a downstream entry point, it's just fully optional helper classes, conceptually I'm not sure they belong here or elsewhere
• colors is a minimal implementation with hardcoded color values, it should use the color utils from lingua-franca, or at least we should not have 2 classes with same name in official ovos packages, makes code ambiguous and hard to import at same time
• switches is not a abstract switch at all, it represents only the mk2 switch combination, this should be fully deprecated IMHO
• fan is similar to switches, i could see an argument to keep it but dont feel the cpu_temperature doesnt really belong here, this should be fully deprecated IMHO
• they all refer to "capabilties" which was a mark2 rewrite branch concept, it doesnt apply to ovos and that is dead code
• they all ignore base event handlers from the PHAL base class, if we introduce methods for specific actions then those should be used in default event listeners from base class

i believe the LED class is useful since it is common across many plugins, so that one should be modernized and everything else dropped.

[NeonDaniel]

I'm not sure this should drag Lingua Franca and language parsing into a hardware interface; minimally I think the interface should include methods to accept and translate hex/hsl/rgb values to whatever the particular LED object wants.

I think the hard-coded values should be kept for primary/secondary colors and black/white only (red, orange, yellow, green, blue, violet, black, white). A plugin/skill could use LF externally to determine a hex/hsl/rgb value to pass to the LED object.

Switches and fan I am less worried about, but I do believe some abstraction is helpful so each plugin doesn't need to implement pull_up/pull_down setup and can just set config and get a binary "on"/"off" value to work with.

The fan I likewise think is helpful since there is common logic for how to manage fan speed based on CPU temp, but it may not be used in practice since ideally that would be controlled by the system.

[NeonDaniel]

Releated LED animation issue https://github.com/OpenVoiceOS/ovos-plugin-manager/issues/94

[builderjer]

Right now, the animations are coded to use the Color class from OPM https://github.com/OpenVoiceOS/ovos-plugin-manager/blob/09482f93729b1452279b6ea15bb9a188b0edad5d/ovos_plugin_manager/hardware/led/animations.py#L32 If this was loosened to use a tuple instead, plugins could use Lingua Franca for colors and still use these animations.

Edit:

This isn't quite right. There are several places where the colors from OPM are hard coded into the animations. It makes it impossible to use Lingua Franca for color choice and these animations at the same time.

[builderjer]

Perhaps a separate ovos-PHAL-plugin-leds is in order? Then it can accommodate for several different types?