Alarmes decomptadors venen en batches que poden venir molt tard.
+unsupported ara mateix
+pseudocode-ish idea: Energy last 24h is 0 -> alarm
+select sum(energy) from + select lag(energy, partition by device order by date desc) from (select * from registry where device1 and date > last_date_1 or device2 and date > last_date_2) +group
+on last_date = select max(date) from processed group by device
+select '' as lectura_date, '' as device, '' as alarm
+calculated_alarms:
+{% foreach row in meters%} +UNION +opció 2 +select max(energy) > 0 from registry +where + device = row['device'] and + date > row['date'] - 24h
+select from {{ this }} order by date desc limit 1
+materialitzada: +select max(date) from calculated_alarms group by device
+{{ config(materialized='incremental') }}
+select date, max(energy) > 0 from registry --> caldrà un lag o algo
+from raw_app_data.events
+{% if is_incremental() %} + where event_time > (select max(event_time) from {{ this }})
+quan entri un device nou hem de comprovar que where event_time > NULL torna totsels resultats
+Chosen option: triem l'opció 2. per suportar calcular alarmes en el passat
+Technical Story: [description | ticket/issue URL]
+Les alarmes de comptadors s'han de notificar.
+coberts: +* moxa ens arriben les lectures cada 24h +* hi ha comptadors sense lectures durant temps +* la notificació diuen que la volen un cop al dia al llegir del moxa
+podem
+ho farem amb un pandas/sql fàcil per no posar dbt a producció encara
+--> ho acabarà fent dbt a mig termini
+Technical Story: [description | ticket/issue URL]
+[Podem fer un spine amb un left join sense condició contra plant i meter per tenir el carret buit i després fer un left join amb les lectures
+dbt_spine +left join plant +left join meter on plant.id = meter.plant
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+Technical Story: [description | ticket/issue URL]
+Necessitem alertes d'incidències dels diferents dispositius de les plantes. +Cada dispositiu té especificitats: granularitat temporal de les lectures, lag natural en al càrrega de lectures i casuístiques concretes que es consideren errors.
+Dispositius: +- Meter ip +Granularitat lectura: 1 hora +Cada quan arriben les lectures: 20 min (però ERP sincronitza cada 2 hores) +Valors historics updatable: No actualment (a l'erp sí) +Poden aparèixer lectures antigues: No actualment (a l'erp sí)
+Meter moxa +Granularitat lectura: 1 hora +Cada quan arriben les lectures: 20 min (però ERP sincronitza cada 24 hores) +Batch: 24h +Valors historics updatable: No actualment (a l'erp sí) +Poden aparèixer lectures antigues: No actualment (a l'erp sí)
+Inverter +Granularitat lectura: 5 minuts +Cada quan arriben les lectures: 5 minuts +Valors historics updatable: No +Poden aparèixer lectures antigues: Rarament
+String +Granularitat lectura: 5 minuts +Cada quan arriben les lectures: 5 minuts +Valors historics updatable: No +Poden aparèixer lectures antigues: Rarament
+Plant
+Casuística: Meter és variable enla cadència d'enviar lectures (sovint tarda a reconnectar)
+Hem decidit atacar la opció HI i veure si podem reduir a 5 minuts d'execució amb incremental. +Probablement no serà possible i necessitarem un fast-track (opció RL) per les alertes real-time.24h
+Aquest fast track s'executarà cincminutalment o podem veure si es podria fer en streaming EL -> T -> N(otificació) +Serà exclusiu per alertes i amb poca consolidació a base de dades i no revisitarà el passat. Només NOW()-ish.
+[example | description | pointer to more information | …]
+DAG:
+(production_inverter) -> (alarm) -> (alrm2)
+
+with ( Taula production_inverter (registry gapfilled, clean, alarms )) as foo
+
+time | inverter_id | energy | n_readings | alarm_no_reading | alarm_zero_daylight
+10:00:00 16 34 1 FALSE FALSE
+09:55:00 16 0/NULL 0 TRUE NULL
+09:50:00 16 0 1 FALSE TRUE
+
+select last row of foo where alarm = TRUE
+[example | description | pointer to more information | …]
+RT:
+real-time, per les alarmes que necessiten notificació immediata, i per cada tipus d'alarma +
with foo as (
+select
+ count(energy),
+ max(energy)
+from registry
+where NOW() - device.alarm_offset < time
+group by device
+)
+select
+ now() as time,
+ count = 0 as no_reading_alarm,
+ max = 0 as no_energy_alarm
+from foo
+històric: +com tenim ara, al final del dia o d'una setmana, re-calcular les alarmes històricament
+Technical Story:
+Com serà la obt? horaria calculada un cop cada hora? I quan passem a comptadors 15-minutals, segurem amb dbt run 15-minutal? Quina frescor de les dades cal? --> posem-ho a un adr diferent
+Si les dades cincminutals són horaries, la obt de tots els indicadors també?
+Passarem a comptadors 15minutals en algun moment proper.
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+Technical Story:
+https://trello.com/c/rmCTOJrH/205-decidir-com-farem-lobt-i-el-cincminutal-r%C3%A0pid
+Passem a una macrotaula de dades llargues clau-valor per a les dades cincminutals?
+Com serà la obt? horaria calculada un cop cada hora? I quan passem a comptadors 15-minutals, segurem amb dbt run 15-minutal? Quina frescor de les dades cal? --> posem la discussió de la obt a un adr diferent
+Ara que sabem molt més dbt i que incorporarem un proveïdor de dades cincminutals amb dades llargues que deprecarà l'esquema antic, ens plantegem si hauríem de basar en una macrotaula de dades llargues per les dades cincminutals.
+Chosen option: opció 3
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+En el seu moment vam triar redash perquè podia tenir apis com a sources i el dev és molt més còmode perquè no està tant layeritzat (dataset/query - chart - dashboard).
+A la pràctica no hem fet servir mai la lectura directa de les apis perquè les autèntificacions no estaven suportades, ens agradava tenir una còpia, t'obligava a treballar en queries de l'sqlite de redash.
+A més a més, redash delega la gestió d'usuaris a la db, cosa que implica que no pots limitar que un usuari pugui veure uns valors d'una query i no uns altres, per exemple filtrar per plantes la producció, els permisos es fan a nivell de db.
+La macrofase de plantmonitor i l'evolució de l'equip de dades cap a superset amb els altres equips ens porta a replantejar-nos-ho.
+Iniciem un spike de superset per a fer els nous dashboards.
+Chosen option: ?
+👍
+mustache
+definir parametres a nivell de default de charts, de chart especific o dashboard
+👎
+no apte per heavy duty (cache regular)
+👍
+cohesió cooperativa -- tota la cooperativa fa servir superset
+👎
+No pots fixar filtres a nivell de chart al dashboard, cal fer-ne una còpia. Implica que +si volem canviar com s'ensenya un chart de planta, els haurem de canviar tots un a un.
+El jinja és funky. No és clar com fer servir el "filter_values" a dins d'una query. +Les queries dinàmiques són molt menys directes de fer que al redash.
+ + + + + + +^-- [short title of solved problem and solution]
+[ADR-0005](0005-example.md)] Technical Story: [description | ticket/issue URL]
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+[example | description | pointer to more information | …]
+