[EJB] Mqtt client

[aleskandro]

EJB Singleton, istanziato allo startup.

https://www.eclipse.org/paho/clients/java/

Topic:

• [x] /sensors/zones/${i}/

• [x] /actuators/zones/${i}/

In futuro per la seconda iterazione

• [x] /sensors/zones/${i}/sectors/${j}/

• [x] /actuators/zones/${i}/sectors/${j}

E' un publisher per /actuators/* : viene triggerato dall'ejb orchestrator.

E' un listener per /sensors/* : primo test, alla ricezione la callback fa solo stampa su schermo; appena sara' pronto l'EJB Monitor lo chiamera' per salvare i dati.

Espone un metodo pubblico

void publish(String topic, float val)

con topic che e' il sottopattern a partire dai comuni: si pubblisca su:

"/actuators/zones" + topic

[aleskandro]

                 MQTT
                  |
           /            \  
         /                \
       /                    \
     /                        \ 
 subscribe                  publish
      |
 1) sub. @init              1) Actuator @ ActuatorSessionBean #4
 2) arr. handling           2) Publishing di genericvalue con reflection

4

[aleskandro]

Ordine dei payload per sensori a attuatori delle vasche

ogni vasca pubblica periodicamente un messaggio con il seguente payload

• private float capacity;
• private float inputFlowRate;
• private float outputFlowRate;
• private float valve;
• private bool schmidtTrigger;

1

[aleskandro]

@eMarco da discussione su skype con @CursedLondor abbiamo deciso il payload ottimale per la comunicazione verso/da java. Speriamo che in matlab questo sia possibile, ovvero concatenare in quell'ordine quei valori della singola vasca

1

[eMarco]

• Zones subscribe to /sensors/zones/${i}/

• Zones publish to /actuators/zones/${i}/. Payload:

  • float % (input to tank)
  • boolean (output switch)

[eMarco]

Append al payload della vasca:

• float counter;

[aleskandro]

In base a cio' che abbiamo fatto ieri nel modello e al doc iniziale, nell'applicazione ho aggiunto:

• Modello del settor (Sector): ogni vasca ha piu' settori
• Sistemato leggermente l'MQTTClient per poter pubblicare GenericValue (instanceof Tank => pubblica una Tank come prima, instanceof Sector => pubblica un sector)
• Fatto un po' di codice dell'orchestrator (probabilmente da sistemare), che usando un altro timer:

1. prende le ultime letture dei settori
2. fa la differenza sector.flowRate - sector.CountedFlowrate per ogni sector
3. se la differenza per un settore e' > dell'errore (ho usato flowRateError() che non usavamo piu', ma bisogna metterci sempre il valore corretto) stacca il trigger della settore.

La pubblicazione (orchestrator => simulink), come sopra, avviene su /actuators/zones/${i}/sectors/${j}

La lettura (simulink => orchestrator), per come modificato nei giorni scorsi dovrebbe avvenire su /sensors/zones/${i}/sectors/${j}/

Il problema e' che: ogni vasca potrebbe avere piu' settori, quindi ogni settore dovrebbe avere un trigger e un amperometro PRIMA del parallelo perdita-utilizzatore.

TODO: sistemare il modello per avere l'amperometro e il trigger prima del parallelo. #1 (Done)

TODO2: nel MQTTClient java, la lettura del settore sul path sopra, deve creare un Sector e fare put come per il tank su MonitorSessionBean

[aleskandro]

Il modello del settore e' costituito dai seguenti field:

• private float flowRate; // La corrente che passa per il settore, c'e' un blocco ad hoc adesso nel modello, sopra il parallelo tra utilizzatori di settore e perdite
• private float flowRateCounted; // La corrente che passa per l'amperometro interno all'utilizzatore del modello (ora utilizzatori): rappresenta la somma delle correnti delle case servite dal settore;
• private int ownerTankId; // l'id della tank cui appartiene lo specifico settore
• private int sectorId; // l'id del settore (come gia' fatto per la tank)
• private final SchmidtTrigger trigger; // il trigger del singolo settore (come gia' fatto per la tank).

TODO3: mandare email se avviene perdita #6 (Done)