ToDo.md

To-Do

• Permitir indicar en los downlinks cómo es el schedule (replace, first o last). Parece que ChirpStack no admite first.
• Los parámetros que se configuran mediante downlinks individuales deben ser excluyentes para que se envíe un único downlink. Si hay operaciones que requieren el envío de varios downlinks deberán tratarse de otro modo. He derivado el envío de downlinks de configuración a la cadena de cada tipo de dispositivo. El widget envía la acción de configuración al dispositio de control, que la envía a la cadena de configuración, que gestiona directamente los atributos con guión doble (__), pero envía a la cadena del tipo de dispositivo los atributos con guión triple (___), que los gestiona almacenando los atributos necesarios y enviando los downlinks que sean precisos.
• Trasladar la rama "Tomar posesión" de la cadena raíz a la cadena de reglas de cada tipo de nodo. Debería estar en el panel Configuración, pero como es muy dependiente del tipo de dispositivo no podría manejarse en la cadena configurarEntidad directamente, sino que habría que pasarla a la cadena del nodo en particular. raiz --> configurarEntidad --> V02_001 --> raiz nuevamente (para enviar los downlinks). También convendría agrupar todo el tema de donwlinks (actualmente en la cadena raíz, pero probablemente requiera su propia cadena a medida que vayamos creando integraciones con más plataformas).
• Permitir que un dispositivo pueda delegar en otro de un cliente diferente. Al delegar se preaprovisiona un nuevo dispositivo delegado vinculado al original mediante una relación de tipo [id del dispositivo delegado]. El propietario podrá indicar qué telemetrías, parámetros de configuración configurables por downlink y canales de downlink quiere delegar.
• ¿Qué pasa si 2 dispositivos/activos tienen el mismo nombre? El sistema no lo permite, pero debería porque, por ejemplo, podríamos tener 2 activos Casa y Casa vacaciones, cada uno con un sub-activo salón. Afecta también a la siguiente. Habría que valorar almacenar en el customer un atributo incremental, que se incluyese en el nombre (00000001+128_Salon).
• Al crear una delegación con un mismo nombre que ya se ha utilizado anteriormente, puede producirse un error al crear la relación auxiliar de la regla crearDelegado (habría que buscar alguna forma de que los nombres de las delegaciones fueran únicos). Como en el caso anterior, podría recurrirse a un atributo incremental.
• Explorar cómo se gestionan las plantillas de los dashboards (dashboard.directive.js y src/app/components/dashboard.tpl.html) con la intención de que sólo se muestren los widgets correspondientes a las telemetrías/canales de downlink que tenga concedidos. Se ha resuelto en el LHT65 enviando un mensaje desde un widget, y suscribiendo a los demás widgets a este mensaje para que se vuelvan copmpletamente transparentes/opacos y cambien de posición según convenga.
• Integración con Everynet
• Encapsular las alarmas típicas (cambio de estado y umbral) para que resulten más sencillos los bloques de configuración. Añadir también alarmas de tipo delta.
• Explorar la posibilidad de que el dispositivo Control actúe como un gateway que permita integrar varios dispositivos a través de él. Por ejemplo, en TTN las integraciones son a nivel de aplicación, pero en ThingsBoard las telemetrías llegan a nivel de dispositivo; podríamos usar el dispositivo Control para recibir todas las telemetrías de una aplicación y redirigirlas al dispositivo correspondiente; y en sentido contrario, es decir, dirigir los downlinks de los dispositivos hacia el dispositivo Control para que los envíe (en realidad, una vez creado el dispositivo, para los downlinks podría usarse el método ya existente). Sería algo similar al gateway de ThingsBoard. Permitiría por ejemplo, crear dispositivos automáticamente con la primera telemetría (en realidad no podríamos crear los dispositivos automáticamente porque no conocemos su tipo). El distribuidor de dispositivos lo dará de alta en una app propia de TTN que tendrá una integración a su propio dispositivo de control. Además, el distribuidor, solicitará el pre-aprovisionamiento del dispositivo en myIoT indicando el devEUI. El propietario final del dispositivo usará las credenciales de reclamación. Al reclarmarlo se creará una relación de tipo [devEUI] del cliente_patron hacia el dispositivo. Cuando el dispositivo control del distribuidor reciba una telemetría, comprobará si trae un campo devEUI (su nombre variará: en TTN se llama hardware_serial, en ChirpStack se llama devEUI, y en Everynet se llama device); en caso afirmativo cambiará el originador al cliente patrón, y éste a su vez al dispositivo destinatario, y reenviará la telemetría a la cadena de reglas principal. De este modo el usuario final se evita tener una cuenta en TTN. En principio tenemos control sobre los devEUI porque sólo se pueden introducir a través de pre-aprovionamiento (que está auditado por la autoridad correspondiente). ¿Qué pasa si el propietario quiere tomar control total del dispositivo? ¿El distribuidor tendría que borrarlo de su cuenta o cederle la propiedad al propietario, o el propietario tendría que cambiar el devEUI del dispositivo?
• Skill de Alexa
• Modificar el dashboard del RAK7204 para que muestre la evolución del IAQ, y para que al mostrar el card de IAQ a pantalla completa escale el tamaño de la imagen.
• Evitar que se pueda indicar un token que comience por cero al crear un delegado (ThingsBoard los elimina e intenta convertirlo en un número)
• Cuando un customer reclama un dispositivo, asignarle el dashboard correspondiente si no lo tiene ya asignado.
• En el widget personalizado de IoT PuertaABIERTA_CERRADA, hacer que en cada actualización adquiera el parámetro delegación en lugar de usar el recibido en los parámetros al abrir el widget
• ¿Cómo se van a desplegar las nuevas versiones de config, delegate y dashboards a los clientes? Podrían comprobarse las versiones (de config, delegate y dashboard) al recibir cada telemetría, y actualizarlas si fuera necesario. Ahora mismo disponemos de las reglas actualizarCustomers_for y actualizarCustomers_next que copian atributos en todos los clientes y les asignan dashboards (usa el atributo accounting del cliente_patron para obtener un listado de todos los customers del sistema)
• Al reclamar un dispositivo subordinado o al configurar su delegación, deberían actualizarse ciertos parámetros como ___heartbeat en el caso del V02_001. Además, si un usuario cambia un atributo de bería actualizarse en los demás. Por último, al delegador debería mostrársele el estado de la delegación (reclamada o no).
• En las cadenas de reglas específicas para cada tipo de dispositivo podría explorarse que a los subordinados (no a los principales, en los que la recomendación sigue siendo usar el formato RAW porque algunos proveedores como Everynet no ofrecen conversores de cargas de pago) les llegase la telemetría en formato procesado (Cayenne), para evitar repetir la misma operación en cada uno de ellos.
• Impedir que los nombres de dispositivos y activos puedan contener el carácter guión bajo.
• Permitir alternar fácilmente entre los paneles Configuración y Control... o estudiar unificarlos en uno solo.
• Permitir que la notificación de una alarma sea el envío de una telemetría un comando (dependiendo del tipo de dispositivo podría ser a través de un downlink, una telemetría, un atributo compartido...) a otro dispositivo. De este modo podríamos, por ejemplo, cerrar una válvula de agua cuando un sensor de suelo detecte una fuga. Cada dispositivo debería publicar de algún modo (otro atributo de configuración?) los comandos que puede admitir.
• En los dispositivos LoRaWAN, permitir al usuario indicar el devEUI. Al hacerlo se creará una relación de su dispositivo SYSTEM a este dispositivo, de modo que el dispositivo SYSTEM pueda hacer entregas de telemetrías/downlinks en nombre del propio dispositivo (con el objeto de poder tener muchos dispositivos en una sola integración en sistemas en los que la integración es a nivel de aplicación, como The Things Network).
• Explorar la posibilidad de que una delegación pueda ser pública, de forma que un usuario pueda compartir públicamente un dashboard parcial de sus dispositivos (podría ser una forma de superar la imposibilidad de crear vistas de entidad desde las reglas)
• Integración con https://api.spontit.com/ o pushed
• Valorar usar esta librería para leer códigos QR (https://blog.minhazav.dev/HTML5-QR-Code-scanning-launched-v1.0.1/)
• Valorar que haya dispositivos de coste nulo (por ejemplo, estaciones de medición de CO2 para colegios) que se puedan crear incluso aunque el crédito sea nulo (ésta es la parte crítica). Por ejemplo, podrían tener el sufijo _FREE en el nombre. Podrán delegarse, pero no podrá cambiarse su tipo.
• Valorar que haya dispositivos reclamados que vayan a costa del proveedor mientras se mantenga el devEUI original para entregar a través de él. Esto va unido al hecho de que un usuario decida desvincularse de su proveedor, pero no sepa o tenga los medios para cambiar el devEUI de su dispositivo.
• Evaluar integración con matrix.org. El usuario crearía una sala en matrix.org e invitaría a participar en ella al usuario @myiot:matrix.org. Después añadiría el id de la sala (que está en las opciones avanzadas de Element) en su panel de configuración.
• Posibilidad de habilitar/deshabilitar las notificaciones temporalmente (limitación horaria/semanal/mensual).
• Delegación pública de activos. Es interesante, por ejemplo, para compartir públicamente un mapa en el que se muestren distintos dispositivos. Cuestiones: ¿delegar el activo debe incluir la delegación de todos los dispositivos que contiene, o la delegación de activos y dispositivos debe mantenerse desvinculada (por si solo se quieren hacer públicos algunos de los dispositivos que contien)? Desvinculada porque facilita mucho el procedimiento (al crear la delegación pública de un dispositivo podemos crearle la relación Contains con el activo al que pertenece, si éste es también público, o cuando se haga público el activo ¿podemos recorrer todos los dispositivos con los que mantiene relación Contains? creando la relación en los correspondientes delegados públicos) y además aporta flexibilidad. ¿Y si un activo contiene otros activos (hasta que nivel de anidamiento)? En principio podría intentarse sin límite porque en realidad todo se basa en relaciones Contains.
• Traducción (requiere recompilación). Podría enfocarse creando dashboards para los distintos idiomas.
• Extraer de las reglas de dispositivos la homogeneización de información común procedente de diferentes redes (TTN, CS, Everynet...) como payload_raw, informacionDownlink...
• Valorar incluir en los tipos de dispositivos LoRaWAN widgets en el dashboard (o un estado) con información sobre la transmisión (contador, RSSI, número de gateways...)
• Permitir configurar los mensajes de texto de las alarmas
• Permitir que los créditos se puedan recargar automáticamente con una donación en Open Collective. Cada usuario podrá indicar su Slug de Open Collective, y se creará una relación a él, de tipo el propio slug, desde el cliente patrón. El cliente patrón tendrá asignado un dispositivo de tipo Stripe, que será el que reciba las telemetrías por webhook del evento charge.succeeded desde Stripe y actualice los créditos.
• Si se borra un dispositivo en myIoT, luego no se puede acceder a él en myIoTlegram, ni siquiera para borrarlo. Lo hemos resuelto borrando también el registro de myIoTlegram.
• En el dispositivo CONTROL de cada usuario es necesario disponer de un atributo root_asset_ID que permita auto-aprovisionar los tipos de dispositivos conocidos (actualmente sólo TTNMAD_DOOR). Para los usuarios nuevos ya se crea automáticamente en el registro... pero para los antiguos ¿cómo lo hacemos? Lo he hecho manualmente con una consulta de este estilo insert into public.attribute_kv (entity_type,entity_id,attribute_type,attribute_key,str_v,last_update_ts) VALUES ('DEVICE','xxx','SERVER_SCOPE','root_asset_ID','xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx',1655572812792)