Passa ai contenuti principali

Post

Visualizzazione dei post da 2021

Monitoraggio Produzione e consumo elettrico con Home Assistant

Home Assistant dalla 2021.8 in poi ha un modulo "Energy" per il monitoraggio dei consumi e della produzione di energia elettrica. Questa componente può risultare utile per calcolare quanto si immette in rete, a quanto ammontano i propri consumi, quali sono i livelli di produzione del proprio impianto fotovoltaico e quanto aspettarsi come rimborso da GSE. Con le automazioni offerte da Home Assistant è possibile anche ricevere una notifica al superamento di alcune soglie oppure se "c'è il sole e l'impianto fotovoltaico sta producendo 0". Cosa serve Per monitorare produzione e consumi serve un sensore su queste linee. La produzione dell'impianto fotovoltaico può essere monitorare anche chiedendo direttamente questa informazione all'inverter. Nel caso di SolarEdge tutte le informazioni sono disponibili mediante restApi ed esiste un plugin apposito per HA. Per misurare i consumi, e la produzione se non si dispone di un inverter che fornisce queste informa

Soluzione multi-nodo per applicazioni web

Soluzione multi-nodo per applicazioni web Introduzione Un servizio online se invocato da un numero molto alto di richieste sull'unità di tempo può "andare in sofferenza" e dare tempi di risposta troppo alti. In questo caso si può intervenire a livello sistemistico per ottimizzare le risorse coinvolte o aumentarle. Se ciò non dovesse bastare si possono accendere più istanze del servizio in modo che il carico di lavoro venga ripartito su queste e non su una singola istanza. Ogni istanza viene detta "nodo". Architettura Lo scenario con una singola istanza di una classica applicazione web composta da Gateway (GW - front-end), Servizio (SR - back-end) e Database (Db): Lo scenario con un Servizio (SR) replicato in più nodi ma con il Database (DB) ed il Gateway (GW) in comune, quello che punto a costruire: Implementazione Per l'implementazione prevediamo che le componenti del sistema siano tutte dockerizzate e supponiamo che siano le seguenti: - Gateway = Nginx - S

Portainer - Dal codice al container in esecuzione

Portainer - Dal codice al container in esecuzione Istallazione docker run -d -p 8000:8000 -p 9443:9443 --name portainer \     --restart=always \     -v /var/run/docker.sock:/var/run/docker.sock \     -v portainer_data:/data \     portainer/portainer-ce:latest Da Eclipse 1) Build dell'immagine con jib (vedi qui  per i dettagli) 2) Upload dell'immagine: dalla sezione "Images" selezionare "Import" e caricare il file dell'immagine. Dopo questa operazione risulterà fra le immagini disponibili e non usate. 3) Creare il container collegato all'immagine precedentemente caricata dalla sezione "Containers" selezionando "Add container": e specificare nel form successivo il nome da dare al container, l'immagine da usare, le impostazioni di rete ed eventuali variabili d'ambiente o volumi: Dopodiché basterà cliccare su "Deploy the container" per avviare il container. Quest'opera è distribuita con Licenza  Creative Commons

Testare massivamente servizi Rest-API

Testare massivamente servizi Rest-API E' facile e comodo usare Postman per testare e prototipare servizi REST/API ma come si progettano ed effettuano dei test per mettere sotto stress uno o più servizi ? Configurare una collection ad-hoc Il concetto di test massivo, quantomeno, in postman è collegato all'entità "Collection". Quindi bisogna creare una collection ad-hoc che contenga, clonandole, tutte le richieste che si vogliono testare massivamente. All'interno di questa collection vanno raccolte tutte le variabili "statiche". Queste variabili sono i parametri che NON cambiano ad ogni iterazione. Per le variabili che cambiano ad ogni iterazione useremo un file apposito. Configurare l'authorization a livello di collection Nel caso di servizi con un sistema di autenticazione bisogna configurare questo sempre a livello di collection. Una volta configurata l'autenticazione a livello di collection e magari testata isolatamente si passa all'autenti

HAPI FHIR - HL7 Java Implementation

HAPI FHIR - HL7 Java Implementation Introduzione Il protocollo FHIR si sta accreditando come soluzione standard per la gestione delle risorse e la comunicazione nell'ambito del software sanitario. Qui fornisco alcuni concetti teorici di base e qualche esempio d'uso generico. HL7 HL7, Health Level 7 (HL7) è un'associazione non profit internazionale che si occupa di gestire standard per la sanità. HL7 è riferito anche ad alcuni degli specifici standard creati da questa associazione (es. FHIR v2.x, v3.0, CDA, ecc.). Fondata nel 1987 e riconosciuta dall'American National Standards Institute nel 1994, riunisce organizzazioni affiliate da oltre 40 paesi. FHIR In riferimento al protocollo, FHIR è uno standard che descrive lo scambio in forma elettronica di dati in ambiente sanitario per favorire l'interoperabilità nell'ambiente clinico di software diversi . Descrive le interfacce tra applicazioni, la definizione dei dati, dei tempi e gli errori da scambiare fra applica