Bridge 0.3.8 — stato "unknown"

[al.exe]

Buonasera,
uso l'Home Assistant Bridge 0.3.8 su un impianto residenziale con HomePLC (pompa di calore, pavimento radiante caldo/freddo, ventilazione, fotovoltaico), circa 170 tag configurati.
Dopo ogni riavvio di Home Assistant, tutte le entità in lettura restano in stato unknown per circa 30 minuti, poi tornano corrette da sole senza che nulla sia cambiato nell'impianto. Il PLC continua a funzionare regolarmente: ho verificato fisicamente che le uscite mantengono la loro posizione.
L'effetto è più evidente sui tag stabili. Nel mio caso quattro valvole deviatrici cambiano posizione solo al passaggio tra le fasi dell'impianto, quindi possono restare immobili per ore.
Domande:

Il parametro Priority nelle proprietà del tag (30 → 0,6 s; 200 → 4 s) è l'intervallo di scansione lato PLC. Vale anche per l'invio verso HA, o l'invio segue un ciclo proprio?
I ~30 minuti corrispondono a un ciclo di refresh periodico configurabile da qualche parte?
È possibile far eseguire al ponte un refresh completo di tutti i tag alla riconnessione di HA, invece di attendere il ciclo successivo?
Grazie

[Admin_HPLC]

Il parametro Priority nelle proprietà del tag (30 → 0,6 s; 200 → 4 s) è l'intervallo di scansione lato PLC. Vale anche per l'invio verso HA, o l'invio segue un ciclo proprio?

Il tempo di scansione vale per tutte le chiamate che esegue il BMS verso il campo (esempio interrogazione di HomePLC ecc..)

I ~30 minuti corrispondono a un ciclo di refresh periodico configurabile da qualche parte?
È possibile far eseguire al ponte un refresh completo di tutti i tag alla riconnessione di HA, invece di attendere il ciclo successivo?

La prima release aggiornava tutti i valori all'avvio ma dato che HA in pratica ha un buffer ideato per applicazioni di domotica non riesce a gestire in tempo reale un refresh di centinaia o migliaia di varibili e va in overflow causando errori di sistema e blocco del refresh,
quando il dispositivo ha migliaia di risorse utilizzabili come in questo caso le variabili lato HA per limiti dell'archiettura si aggiornano solo per evento, diversamente se si utilizzasse un dispositivo con poche variabili anche un refresh iniziale non darebbe problemi apprezzabili

Questo è un limite della progettazione lato HA.
Lato BMS usando la tecnologia Memex l'aggiornamento di tutte le migliaia di variabili gestibili può avvenire in 20 mS
ovvero 100 volte piu veloce di qualsiasi database o software basato su queste tecnologie.

[al.exe]

Sul refresh all'avvio: ho capito il problema dell'overflow, e ha senso — HA non regge centinaia di variabili tutte insieme.

Mi chiedevo però se ci sia una via di mezzo: un refresh scaglionato alla riconnessione, per esempio N variabili al secondo con N configurabile. Con 10/s i miei 173 tag sarebbero coperti in meno di 20 secondi, senza picchi per HA.

Il motivo per cui insisto: ho misurato cosa succede adesso. Dopo un riavvio di HA alle 22:51, le entità sono tornate valide una alla volta — l'ultima dopo 2 ore e 15 minuti, quando il suo valore fisico è finalmente cambiato. Per le temperature si risolve da sé; per le uscite stabili (valvole, relè) può non risolversi per giorni.

Nel frattempo le automazioni leggono unknown. Ho messo una guardia, quindi da me è risolto — ma credo che chiunque abbia uscite stabili incontri lo stesso comportamento senza accorgersene.

[Admin_HPLC]

Mi chiedevo però se ci sia una via di mezzo: un refresh scaglionato alla riconnessione, per esempio N variabili al secondo con N configurabile. Con 10/s i miei 173 tag sarebbero coperti in meno di 20 secondi, senza picchi per HA.

Lato BMS sarebbe semplice, ma putroppo questo viene deciso dal plugIn di HA e adesso è unico per 1200 variabili, la soluzione sarebbe fare uno o piu PlugIn "Domotico" che esegua il refresh iniziale solo su un numero limitato di variabili.
Il numero sarebbe da verificare in modo empirico dato che non ho riferimenti esatti su questa anomalia di overflow.

Un altra soluzione è modificarsi da soli il PlugIn cosa fattibile sostituendo il valore 400 (400 x 3) delle singole risorse con un numero più mirato all'applicazione.

ps: perchè non lasciare attivo il refresh del plugIn attuale?
semplice perchè questo ha fino a 1200 variabili disponibili e se qualcuno ne utilizza una buona parte avrebbe il problema del overflow all'avvio inibendo il funzionamento del plugIn.

[al.exe]

Ho estratto la lista delle entità da HA per capire quali slot sono occupati, e ho trovato una conferma di quello di cui parlavamo.

Ho 134 entità bamse (nome server): 36 sensor, 55 number, 43 switch. Subito dopo un riavvio di HA (fatto adesso per un aggiornamento), 48 dei 55 number sono in stato unknown — sono tutti stati digitali che non cambiano da ore o giorni: valvole, termostati, relè, stagione. Le temperature invece tornano in pochi secondi, perché variano di continuo.
Sul discorso della lista, ecco il punto che rende difficile ridurre il plugIn. Nell'export di HA lo slot si vede solo per i tre tag a cui non ho ancora dato un alias:
switch;switch.bamse_variable10;off ← slot 10
switch;switch.bamse_variable39;off ← slot 39
switch;switch.bamse_variable40;off ← slot 40
Per tutti gli altri il nome ha sostituito il numero, e lo slot non è più recuperabile:
switch;switch.bamse_sw_e_vana_1;off ← slot ?
number;number.bamse_state_ev1;unknown ← slot ?
sensor;sensor.bamse_temp_acm;54,4 ← slot ?

Dal lato HA quindi non c'è modo di sapere qual è lo slot più alto usato per ogni tipo. So solo che esiste almeno uno switch sullo slot 40, perché si vede nel nome.
Senza quel dato non posso ridurre il valore 400 nel plugIn: rischio di tagliare sopra uno slot attivo e far sparire entità che uso. Ecco perché la colonna Risorsa HA nella Variable List mi servirebbe davvero — non è una comodità, è la condizione per poter applicare la soluzione che mi hai proposto.

[Admin_HPLC]

non mi torna, le variabili in HA sono numerate da 1 a 400 perchè non dovresti sapere qual'è l'ultima usata?

[al.exe]

al momento che lo crei lo sai, ansi, adesso lo scrivo , ma quando passa un può di tempo sopra, non lo sai più. Cmq. se non si può aggiungere queste informazioni alla generazione delle liste, mi arrangio.

[Admin_HPLC]

al momento che lo crei lo sai,

in HA puoi controllare la lista delle variabili attive in ogni momento, tutte quelle che non utilizzi le puoi semplicemente disabilitare e cosi è chiaro quali sono in uso e il loro limite numerico.

[al.exe]

Hai ragione, non ci avevo pensato — disabilitare quelle non usate risolve il problema di lettura. Provo così.
Il punto che sollevavo era diverso: al momento in cui creo l'associazione lo so, ma dopo qualche mese di modifiche non me lo ricordo più, e nel pannello del tag non c'è modo di risalirci. Comunque, con le entità disabilitate la lista diventa leggibile e mi arrangio.
Se un giorno la colonna si potesse aggiungere alla Variable List resterebbe comoda come documentazione dell'impianto, ma non è più bloccante. Grazie.

[Admin_HPLC]

Al momento puoi mettere sicuramente una nota sulle singole variabili del BMS indicando l'uso lato HA o qualsiasi altra informazione utile, in realtà ci sarebbe anche il riassunto delle variabili lato BMS ma al momento non riporta le risorse HA associate, basterebbe aggiarnare quello che si può anche già stampare in Pdf ecc..

[al.exe]

Ciao, ritorno con la domanda Dopo ogni modifica dei TAG il bridge si ricarica e quasi tutte le entità in Home Assistant restano "unknown" finché il valore nel PLC non cambia. Gli stati fermi (luci spente, valvole, PID a 0) restano "unknown" anche per ore. Come si forza una lettura completa di tutte le variabili dopo il riavvio del bridge? Esiste un parametro di polling periodico (es. ogni 60 s) oltre all'invio su variazione?

[Admin_HPLC]

La scelta di usare polling o di utilizzare gli eventi è nel codice del PlugIn di HA,
lato BMS si può solo far variare il valore dei tags, magari usando una strategia direttamente su HPLC oppure da BMS per simulare un evento.
La soluzione sarebbe quella di ridurre il numero di I/O usati di default dal plugIN, e introdurre un upgrade a scansione all'inizizzazione del codice del PlugIn in pratica andrebbe riprogettato.

[al.exe]

Ciao, grazie per la risposta sugli "unknown": l'ho risolto riavviando il bridge all'avvio di Home Assistant (alla ripartenza il bridge rimanda tutti i valori).

Ti scrivo tutta la storia di un problema che mi ha bloccato la ventilazione per circa un mese. Secondo me va risolto nel bridge o nel server BMS, non con soluzioni di ripiego lato Home Assistant.

1) COME FUNZIONA LA VENTILAZIONE
Il recuperatore SCHRAG ha 3 velocità comandate dalle uscite %QX6.9 / %QX6.10 / %QX6.11. Nel ladder uso il blocco FANCTRLA, che riceve una sola word, %MW2011 (tag Set_Speed_Vent):
• 0 = spento
• 1–30 = I velocità
• 31–60 = II velocità
• 61–100 = III velocità
Home Assistant decide quando ventilare (aerazione programmata, umidità, cappa della cucina) e scrive in %MW2011 i valori 0, 30, 50 o 100 tramite il bridge (PUT /setkey, variable12, tipo number). Il valore effettivo lo rileggo da %MW2013 (copia di %MW2011 nel ladder).

2) IL PROBLEMA
• Se scrivo %MW2011 dal supervisore BMS o da Test I/O, funziona SEMPRE, con qualsiasi valore.
• Se lo scrivo da Home Assistant tramite il bridge, il bridge risponde 200 OK, ma nel PLC %MW2011 non cambia. La ventilazione resta ferma o resta accesa (es. bloccata in II o in III dopo la cappa).
• Peggiorava giorno dopo giorno: il 05.10 non passava solo 25 (50 sì), il 06.10 solo 50 (25 sì), il 07.10 non passava più niente per tutto il giorno (30, 50, 100), neanche riavviando il bridge.
• I comandi a bit (switch: luci, stagione, modo ACM) passano sempre.
• A volte, per altri number (es. %MW2000 Set_T_Sera), il bridge risponde 404 "mapping not found".

3) LA SCOPERTA
Il server BAMSE girava senza riavvio dal 30 agosto: avevo disattivato un .bat che lo riavviava ogni 4 ore. Il 07.10 sera l'ho riavviato e la ventilazione è ripartita subito: da allora ogni valore passa in 3 secondi, senza errori.
Quindi qualcosa nel server o nel bridge si degrada nel tempo (memoria, coda verso XComm, cache dei valori) e le scritture di word si perdono, anche se il bridge risponde OK.

4) LA MIA RICHIESTA
Non vorrei risolvere riavviando periodicamente un server Windows: non è una soluzione stabile e con più variabili e più traffico rischia di non bastare. Ti chiedo:
1. Puoi verificare nel bridge / BMS perché dopo giorni le scritture di word non arrivano più al PLC, mentre i bit sì?
2. Il bridge dovrebbe rispondere errore (e non 200 OK) quando la scrittura non arriva al PLC: è possibile?
3. Cosa ti serve da me per trovare la causa (log del bridge, log BMS, orari esatti)? Te lo raccolgo io.

5) AGGIORNAMENTI
• Riavvio programmato: per non restare senza ventilazione ho rimesso un riavvio automatico di BAMSE ogni giorno alle 04:01. È solo una misura temporanea, finché non troviamo la causa: senza riavvio, dopo alcuni giorni le scritture di word da Home Assistant non arrivano più al PLC.
Ho notato però un effetto: a ogni riavvio il bridge invia per circa 2 secondi tutti i valori a 0 (es. la stagione passa a "estate", le temperature a 0) e solo dopo i valori veri. Per le automazioni di Home Assistant è pericoloso. Si può evitare?
• Misure: da stamattina registro ogni 10 minuti memoria, handle e thread di ActiveServer.exe, ActiveTask0.exe, Bms15BridgeHA.exe e BrokerSHM.exe (con Performance Monitor di Windows). Tra 2–3 giorni ti mando il file, così vediamo se uno dei processi cresce nel tempo.

Grazie mille, so che il bridge è un lavoro tuo e lo apprezzo molto: per me è fondamentale che sia affidabile senza riavvii.

[Admin_HPLC]

La verifica che devi fare è se variando da HA si modifica il valore sul TestIO del BMS.
I bit hanno già il loro log di sistema, si può configurare sulla pagina dei tags del BMS in alto sulla destra.

Il degrdo della memoria non è un problema del BMS è un Bug di Windows che si risolve attivando la funzione Win Restore nel setting del menu Ghost, lo avevi attivato?

[al.exe]

Ho fatto anche questa verifica qundo mandavo i valori 25 e 50 dal HA non avevano ecco nel test I/O. Il Win Restore è attivato per ogni ora.
' I bit hanno già il loro log di sistema, si può configurare sulla pagina dei tags del BMS in alto sulla destra.' Dove?

[Admin_HPLC]

bool_change.jpg

Selezionando questo flag
poi per verifica degli eventi dei booleani c'è un pulsante di lato