Indice
[TOC]

---

# Tranferencia Thingsboard

###### tags: `epec_gc` `epec` `tranferencia`

## Día 1

- [ ] ver cuantos ambientes tenemos
- [ ] EPEC-GC: nombres de refencia: (Martin Arrieta)
- [ ] EPEC-Residenciales: Lucia
- [ ] EDELAP: Lucia
- [ ] SGC: Lucia
- [ ] EPEC-Residenciales v2: Lucia
- [ ] Preventa: Lucia
- [ ] proyectos de deploy
- EPEC-GC: Manual (se esta re-acomodando)
- link: [epec-deploy](https://gitlab.ascentio.com.ar/teleco/epec/epec-deploy)
- EPEC-Residenciales: Ansible
- link: [epec-residenciales-deploy](https://gitlab.ascentio.com.ar/teleco/epec/epec-residenciales-deploy)
- Preventa:
- link: [epec-residenciales-deploy](https://gitlab.ascentio.com.ar/teleco/epec/epec-residenciales-deploy)

## Dia 2

### Dudas

- [ ] Bugs y Workarounds conocidos:
- el gateway tiene un bug que al desconectarse del brocker no se reconecta al thingsboard:
- opcion a: lo que se me ocurre es que actualicen los gateways a la implememtacion de GC y que puedan hacer el fix de este error en ese proyecto.
- opcion b: implementar el fix en el proyecto gateway que usa residenciales, esto tambien deberia ser replicado en el gateway de GC porque lso medidores circutor tienen la misma arquitectura.
- Las extensiones de mqtt-gateway tienen un limite de variables para mapear. Alcanzando ese limite(que no es definido en ningun lado) es imposible modificar ningun mapeo y que el gateway sincronice nuevamente.
- opcion a: se puede intentar separar las variables en base a los tipos de lectura.
- opcion b: en el caso que se tenga un modo de lectura con muchas variables y se supere el limite: en este caso se puede dividir el mapeo entre dos gateways. en este punto hay que tener cuidado que las variables mapeadas en los gateways se guarden con el mismo timestamp.
- opcion c: mejorar la implementacion del gateway.
- [ ] Proyectos gateways:
- gateway de GC : [thingsboard-gateway](https://gitlab.ascentio.com.ar/teleco/epec/thingsboard-gateway)
- gateway (tiene poco mantenimiento) : [thingsboard-gateway](https://gitlab.ascentio.com.ar/thingsboard/thingsboard-gateway)
- [ ] Pro y contra de migracion de gateway
- es una cuestion de riesgos.
- [C] en el caso de GC, habria que reimplementar todas las extenciones customizadas.
- [P] tiene menor uso de recursos (RAM)
- no se puede dar una evaluacion hoy muy clara por las cambian ya que el proyecto de gateway en python esta en desarrollo.
- Si la idea es seguir con thingsboard, habria que planificar este upgrade.
- para tener una mejor evaluacion habria que hacer pruebas con las cosas que ya tenemos.
- [ ] Limitaciones de uso de DB y su seleccion
- el uso de DB depende de la version. En la version 2.3 (la actual) soporta Postgres y Casandra. En la verison 3 soporta Postgres, Casandra y TimescaleDB.
- la seleccion de la DB depende de la infraestructura que se tenga.
- Nota: Thingsboard te recomienda usar postgres en pruebas de concepto o en pequeña escala. Para produccion te recomienda formas hibridas: Hybrid1 (PostgreSQL + Cassandra) o Hybrid2 (PostgreSQL + TimescaleDB)
- Un camino de mejora, puede ser:
- paso 1: actualizar la plataforma a thingsboard 3.
- paso 2: (en un ambiente de test) hacer pruebas de performance con postgres
- paso 3: comparar la performance entre tb2 y tb3
- paso 4: migracion de postgres
- paso 5: evaluar la platforma con el modo Hybrid2 (PostgreSQL + TimescaleDB). Y luego repetir los pasos 2,3 y 4 en esta nueva arquitectura.

## Dia 3

- [ ] Limitaciones en el mapping de variables en la extencion MQTT
- Ticket de jira: https://jira.ascentio.com.ar/browse/EPEC-1061
- El gateway tiene un cliente MQTT que se configura con los mapping y hace el procesamiento (creo) en una libreria interna de thingsboard
- [ ] Apis: Rest, MQTT
- MQTT
- HTTP
- swagger
- java lib: tiene una version comunity y PE
- python lib: tiene una version comunity y PE

- [ ] se rompe kafka
- suele darse cuando regeneramos los containers
- lo veo en los logs, es que las particiones de kafka tienen un ID que lo genera cada servicio. Cuando se vuelven a conectar los ID de los servicios cambiaron y se comunicacion con las particiones de kafka
- solución: **borrar todos los servicios (con sus volumenes) y regenerar de nuevo**.

        sudo docker-compose stop
        sudo docker-compose rm -v
        sudo docker-compose up -d

### temas

- [ ] Backup DB

- [ ] Mantenimientos
- borrar telemetria de las bases de datos.
-
- [ ] jenkins
- link: [epec-gc-taskforce](https://gitlab.ascentio.com.ar/teleco/epec/tools/epec-gc-taskforce)
-
- [ ] ver los componentes de thingsboard

- [ ] demos

## Dia 4

- [ ] backup
- **creo que esta** en 100% de los deploys, queda pendiente revisar cada ambiente.
- hoy tenemos:
- imagen docker usada para generar los backups: https://github.com/prodrigestivill/docker-postgres-backup-local
- la consiguracion esta en el docker compose, por lo generan donde esta la base de datos
- para el restore (yo no lo he ejecutado) se tiene las siguientes opciones:
- [restauración local](https://github.com/prodrigestivill/docker-postgres-backup-local#restore-locally): `zcat backupfile.sql.gz | docker exec --tty --interactive $CONTAINER psql --username=$USERNAME --dbname=$DBNAME -W`
- [restauración remota](https://github.com/prodrigestivill/docker-postgres-backup-local#restore-to-a-remote-server): `zcat backupfile.sql.gz | docker run --rm --tty --interactive postgres:$VERSION psql --host=$HOSTNAME --port=$PORT --username=$USERNAME --dbname=$DBNAME -W`
- ejemplo de backups: `ls /opt/thingsboard/backups/*/`

administrator@pocepec:/opt/thingsboard$ ls /opt/thingsboard/backups/*/
/opt/thingsboard/backups/daily/:
thingsboard-20200504-000000.sql.gz  thingsboard-20200507-000000.sql.gz  thingsboard-20200510-000000.sql.gz  thingsboard-20200513-000000.sql.gz  thingsboard-20200516-000000.sql.gz
thingsboard-20200505-000000.sql.gz  thingsboard-20200508-000000.sql.gz  thingsboard-20200511-000000.sql.gz  thingsboard-20200514-000000.sql.gz
thingsboard-20200506-000000.sql.gz  thingsboard-20200509-000000.sql.gz  thingsboard-20200512-000000.sql.gz  thingsboard-20200515-000000.sql.gz

/opt/thingsboard/backups/monthly/:
thingsboard-202004.sql.gz  thingsboard-202005.sql.gz

/opt/thingsboard/backups/weekly/:
thingsboard-202015.sql.gz  thingsboard-202016.sql.gz  thingsboard-202017.sql.gz  thingsboard-202018.sql.gz  thingsboard-202019.sql.gz  thingsboard-202020.sql.gz
administrator@pocepec:/opt/thingsboard$ 

- ejemplo de una configuración en epec GC:

  pgbackups:
    image: prodrigestivill/postgres-backup-local:11
    restart: always
    volumes:
      - "${BACKUPS_DIR:-.}/backups:/backups"
    depends_on:
      - postgres
    environment:
      - POSTGRES_HOST=postgres
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${SPRING_DATASOURCE_USERNAME}
      - POSTGRES_PASSWORD=${SPRING_DATASOURCE_PASSWORD}
      - POSTGRES_EXTRA_OPTS=-Z9 --schema=public --blobs
      - SCHEDULE=@daily
      - BACKUP_KEEP_DAYS=7
      - BACKUP_KEEP_WEEKS=4
      - BACKUP_KEEP_MONTHS=6
      - HEALTHCHECK_PORT=80

- [ ] Escalado vertical y horizontal de TB
- depende de la arquitectura
- hay que ver la arquitectura de thingsboard 
- el escaldo del lado de los gateways, por defecto se pueden escalar, pero hay que revisar los servicios implementados por ASC. Por ejemplo: el server de circutor se conecta a los medidores y hace las lecturas, hay que ver si este server se puede escalar horizontalmente.
- [escenarios de deploy](https://thingsboard.io/docs/reference/iot-platform-deployment-scenarios/)
- [ ] thingsboard 3
- [ ] los widgets personalizados son incompatibles con los implementados en la version 2.3
- [widgets-development-before-3.0](https://thingsboard.io/docs/user-guide/contribution/widgets-development-before-3.0/)
- [widgets-development](https://thingsboard.io/docs/user-guide/contribution/widgets-development/)
- [ ] La gestion de los mapping desde la UI ya no existe (seguramente en una version futura vuelve). Ahora los mapping tienen que estar en los archivos de deploy de los gateways.
- [ ] Los mapping usados para la tranformación de datos, son incompatibles con los nuevos gateways.
- Esta es la doc para conectar los gateways nuevos [link](https://thingsboard.io/docs/iot-gateway/config/mqtt/)
- Notar que esto no nos sirve, a excepcion si el gateway que estamos integrando sea el nuevo (hecho en python)

## Dia X

- [ ] dudas
- [ ] planes futuros: repasemos idea de mejoras y buenas practicas

# Mejoras y recomendaciones

- [R] mantener 1 solo proyecto gateway, para que los fix se puedan aplicar a todos los ambientes de deploy
- [R] lo ideal seria que se tenga un solo proyecto gateway,
- con los fix internos que hagamos.
- con las extenciones compartidas.
- [R] Re-definir la forma en la que llamamos a los proyectos, gateway, deberia ser un solo proyecto y se corresponde al de thingsboard.