Strip Controller

strip_controller.md

Strip Controller

strip_controller_1.md

Ideas for the whole system

• Send broadcast messages from sc-master to detect available devices so users don't need to know IP addresses and ports.
• Multiple devices.
• Device and master (sc-master) metrics:
  • Measure how much time takes to change color for all lights:
    • Considering sc-web-sc-master-sc-rpi and/or sc-master-sc-rpi
    • It should be 60 FPS ( no more than 1/60 seconds).
  • CPU, memory, network, request/response times, etc.
  • Investigate best approach:
    • Implemented as sc-master RESTful endpoints (disadvantage: coupled to sc-master, advantage:maybe easier to implement).
    • Separated from web server provided by DRF (advantage: decoupled from sc-master, see PCP).
  • Displayed as graphics in sc-web or separated (see RabbitMQ)
• Deploy all with Docker. For example, sc-master and sc-web in the same container. It may be specially useful to dockerize it when implementing metrics in a decoupled way as mentioned above, the metric system may run in a different container.
• Different modes, specially useful when having multiple devices:
  • FUSIONED: all strips are viewed as one, so for example instead of controlling two strips each one with 300 leds, it can be viewed as one strip of size 600 working as one.
  • SEPARATED: almost the opposite of FUSIONED.
• Improve README.md for all components:
  • Summarize and separate specific content in smaller markdown files.
  • Provide a short description of what SC is (the same description for all components) in addition to current description of what the component is intended for and how to run it, no much more than this.
• Allow section editions which changes the order. For instance, having sections [4, 8] and [9, 10], allow editing the second section to [1, 2] (analyze if it could generate future issues before doing code changes).
• Provide a mechanism to synchronize sc-master with sc-rpi. For instance, if for sc-master leds are turned off and for sc-rpi they are turned on (for instance sc-master lost connection with sc-rpi just after turning leds off leading to the missmatch). This could be managed, with a periodic process to coordinates the state of both components, or just after sc-master try to invoke a specific command on sc-rpi.

strip_controller_2.md

sc-rpi

• Use MyPy for type checking.
• Implement a function to load configurations and avoid duplicated code (see init method in src/controllers/hardware_controller.py and src/controllers/section_controller.py).
• Modify help command to return a description of each command (extracted from docstring).
• Allow Home Assistant to set brightness when invoking turn_section_on command (see https://chatgpt.com/c/692ce137-fc98-8331-9fe8-a511b0de6db0).
• Consider implementing request/response pattern (MQTT 5).
• Improve errors by capturing and processing exceptions from mashumaro in order to return more descriptive errors, for instance, when some field is missing.
• Investigate how to exclude fields for serialization with mashumaro in order to avoid exposing _config and other attributes in Command.
• Use device discovery mechanism to group entities into one device (more information in https://www.home-assistant.io/integrations/mqtt/#device-discovery-payload).
• Extract metrics using well-known tools.
• Send logs to Grafana Loki
• Use YML for configurations instead of .ini files.
• Upgrade to Python > 3.8.

strip_controller_3.md

sc-rpi-client (DISCONTINUED)

• Consider adding a new attribute type in responses to make easier to decode them, for instance using mashumaro discriminators (see "Subclasses distinguishable by a field" on mashumaro official documentation).

strip_controller_4.md

sc-ha (Home Assistant custom integration) (DISCONTINUED)

TODOs

• Add back button on config flow to correct sections.

• Support new types of color modes in homeassistant/components/strip_controller/light.py :

  self._attr_supported_color_modes = {ColorMode.RGB, ColorMode.BRIGHTNESS}

  Try to avoid this warning:

  2024-06-17 21:21:39.256 WARNING (MainThread) [homeassistant.components.light] None (<class 'homeassistant.components.strip_controller.light.Section'>) sets invalid supported color modes {<ColorMode.BRIGHTNESS: 'brightness'>, <ColorMode.RGB: 'rgb'>}, this will stop working in Home Assistant Core 2025.3, please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+strip_controller%22
  

• Implement unloading device and/or entities in order to avoid error like this:

    2024-06-17 19:44:54.054 ERROR (MainThread) [homeassistant.config_entries] Error unloading entry asd for strip_controller
    Traceback (most recent call last):
    File "/Users/brunopiaggio/git/ha-core/homeassistant/config_entries.py", line 809, in async_unload
    result = await component.async_unload_entry(hass, self)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/Users/brunopiaggio/git/ha-core/homeassistant/components/strip_controller/__init__.py", line 81, in async_unload_entry
    hass.data[DOMAIN].pop(entry.entry_id)
    KeyError: '01J0KFV6RXM6685D42PZWB7WB1'
  ``
  

• Set custom icon/logo upgrade HA version to 2024.x and set icon (more info: https://developers.home-assistant.io/blog/2024/01/19/icon-translations/).

• Create OptionsFlow to edit sections (check homeassistant/components/met/config_flow.py).

strip_controller (AppDaemon application)

• Actualmente solo se puede prender o apagar toda la tira. Buscar la forma de hacerlo por secciones. Para esto hay que buscar la forma de mantener el inicio y fin de cada sección. Algunas opciones son: como parámetro de aplicación de AppDaemon o como atributo de cada entidad que se crea publicando un mensaje a un tópico de MQTT.

strip_controller_5.md

sc-master (DISCONTINUED)

• Avoid using the prefix System for error classes.
• Avoid using the prefix System for error classes.
• Provide a mechanism to obtain DRF logs, for example DRF file logs can be exposed with an nginx server.
• Give devices a name defined by user.
• Write automatic test.
• In order to support different modes as mentioned in "Ideas for the whole system", use adapter pattern, for instance having three classes : DeviceController, SectionController and StaticModeController which will play the role of adapter between DeviceController and SectionController.

commands/urls.py

• Move commands in the {{baseUrl}}/commands/system/* path to just {{baseUrl}}/commands/*

sc_master/controllers/device_controller.py

• Try to avoid repeating the final return cls._build_result() in all methods
• Evaluate not using class methods. First thing to take into account is concurrency requirements, It means, if Python and Django Rest Framework capabilities (when and how It start new threads in order to support concurrency), It may be bad idea to use class methods. On the other hand, and if the system is intended to support only one user, It won't matter.
• Avoid using the prefix System for error classes.
• Currently the code is intended for controlling one device, so when extending the system to control more than one device, the handle_device_client_errors decorator could handle errors from any of these devices. For example, if an error occurs on device d1 (considering devices d1 and d2), this method could identify from which device the error comes from and set an specific attribute on the final Result object indicating that d2 continues working as expected but d1 had an error on the last operation.
• Currently, in case of error when sending commands to a device, an error response will be returned. After extending the system as mentioned above, this approach may not be appropiated. Think the scenario that you have two devices d1 and d2 and only one of them fails. From the API perspective, it can be viewed as a request that should return HTTP 207 code (MULTI-STATUS) with the corresponding JSON instead of an error response like {"code": xxxx, "message": "error"} with status 500.
• After catching BrokenPipe, for instance after abtuptly disconnecting sc-rpi, and trying to send another command, the connected device remains inconsitently on sc-master. A good approach may be to run a periodic task with Django which cleans resources on this situations.

sc_master/utils/decorators.py

• Use logger.error(ex) instead of logger.error(ex.traceback()) to avoid logging too much error info. DONE

File: sc-master/commands/serializers/sections/add.py:

• The sections attribute is not being validated when it's an empty list or even when it is not present on endpoint body:

{
  "sections": []
}

The same situations may be happening for all endpoint (serializers) which uses lists for request body.

strip_controller_7.md

sc-web (DISCONTINUED)

• Traduction file

• Improve font-size definition to avoid issues with em and rem units (for example define font-size in html tag and use only rem).

• Display sc-master server logs (generated by DRF) on the frontend. It may be better to include more attributes on sc-master command responses. For example when executing a /turn_on command on sc-master, the output could be something like this :

  {
    "code": "SC_RPI_ERROR",
    "device_name": "raspberry",
    "command": "turn_on"
    "status": 400
  }

  where the 400 indicates the status returned by raspberry after executing the turn_on (sc-rpi) command (think of trying to turn on more than one device, raspberry and raspberry2 by executing the turn_on for both devices).

• Send raw commands (as stringified JSONs) directly to sc-rpi.

src/stores/RootStore.ts

• Scan stores in all src/pages/* instead of manually adding them as instance attributes in RootStore class.