MQTT compatibility confirmation

[joyride1176]

Hi Lorenzo

I'm up and running since last week I've an MQTT network at home and this is the only project using esphome api I've read is possible enable mqtt on esp board and disable esphome api: https://esphome.io/components/mqtt.html

Do you believe there is any drawback changing the protocol?

Thanks

Stefano

PS last question if there is an intrusion in progress I can check it using "stato sirena"?

[lorenzo-deluca]

Hello Stefano, good question, I never use ESPHome with MQTT. I think it use something like mqtt discovery to create automatic topic, etc... I would ask you to try it out and let me know is there're any drawback issues. I don't know, for example, how the service calls works.

Regarding the "stato sirena" status, with that you can trigger the actual activation of the alarm. So yes, you can check it 👍

[lcavalli]

Ciao. Io tempo fa avevo usato mqtt con esphome e siccome gestivo sempre un allarme usavo un link protetto con ssl. Però poi una delle librerie usate da esphome ha smesso di fornire alcuni componenti richiesti e usare mqtt con ssl non era più possibile. Avevo aperto una issue https://github.com/esphome/issues/issues/2660. È ancora aperta e penso che il problema sia ancora presente.

[lorenzo-deluca]

Ciao. Io tempo fa avevo usato mqtt con esphome e siccome gestivo sempre un allarme usavo un link protetto con ssl. Però poi una delle librerie usate da esphome ha smesso di fornire alcuni componenti richiesti e usare mqtt con ssl non era più possibile. Avevo aperto una issue esphome/issues#2660. È ancora aperta e penso che il problema sia ancora presente.

Grazie del feedback ;) Ok, quindi sembra essere problematico usare MQTT over SSL, per MQTT pulito invece potrebbe funzionare?

Onestamente se uno usa ESPHome solo con Home Assistant mi sfugge il vantaggio di passare per MQTT, però ci sta.. chiamate ai servizi, etc... vengono mappate automaticamente e richiamabili tramite servizi da Home Assistant allo stesso modo dell'API?

[lcavalli]

No, che io sappia i servizi sono usabili solo via API nativa.

[lorenzo-deluca]

No, che io sappia i servizi sono usabili solo via API nativa.

Ok, infatti immaginavo, sarebe stato notevole esporre i servizi tramite MQTT. Mah, onestamente allora non capisco il vantaggio di andare con MQTT su HA.

Effettivamente però fuori da HA almeno esporre i sensori tramite MQTT senza dover modificare nulla potrebbe essere interessante. Inizialmente questo firmware l'avevo fatto nativo "arduino" con integrazione solo tramite MQTT, poi passato allo standard MQTT Discovery ed è stato comodo passare da un sistema di domotica all'altro.. ora però HA mi sembra talmente comodo e completo che uscire mi fa già pensare a scomodità 🗡️

[joyride1176]

Ciao Lorenzo

Ho fatto qualche progresso, ho fermato l add on di esphome fatto un reboot del sistema e le entità dell' allarme sono comunque esposte e funzionanti in HA. Riesco tranquillamente ad armare e disarmare le aree.

Quindi le api sono integrate nei core components di home assistant e l add on serve solo per la costruzione di un nuovo firmware che nel mio caso faccio dal PC. Leggo che Senza l addon comunque ha scopre il device e ti chiede le encryption Key

Dalla documentazione leggo comunque che il passaggio api mqtt è supportato faccio una prova entro settimana prossima anche se spegnendo l add on credo di aver risparmiato la memoria A me non serve che mqtt sia criptato

Stefano

Il Ven 5 Gen 2024, 19:15 Lorenzo @.***> ha scritto:

No, che io sappia i servizi sono usabili solo via API nativa.

Ok, infatti immaginavo, sarebe stato notevole esporre i servizi tramite MQTT. Mah, onestamente allora non capisco il vantaggio di andare su MQTT su HA. Effettivamente però fuori da HA almeno esporre i sensori tramite MQTT senza dover modificare nulla potrebbe essere interessante. Inizialmente questo firmware l'avevo fatto nativo "arduino" con integrazione solo tramite MQTT, poi passato allo standard MQTT Discovery ed è stato comodo passare da un sistema di domotica all'altro.. ora però HA mi sembra talmente comodo e completo che uscire mi fa già pensare a scomodità 🗡️

— Reply to this email directly, view it on GitHub https://github.com/lorenzo-deluca/espkyogate/issues/45#issuecomment-1879080290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUADZU7HJZUX3YYD4IQPJDYNA7MTAVCNFSM6AAAAABBOEFOAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGA4DAMRZGA . You are receiving this because you authored the thread.Message ID: @.***>

[lorenzo-deluca]

Ciao Stefano, ok, ora ho capito l'esigenza..!

Si, l'addon serve solo per gestire tutti i dispositivi ESPHome, aggiornare la configurazione, upload firmware etc... Volendo per risparmiare memoria puoi non metterlo in start automatico ed avviarlo solo quando devi aggiornare la configurazione di qualche dispositivo, effettivamente è comodo poter fare tutto da Home Assistant, ma anche da PC è uguale.

La comunicazione tra dispositivo esphome e home assistant avviene tramite API o MQTT, non serve l'addon come hai già visto anche tu. L'unico dubbio che avevamo sia io che Luca è che a livello di lettura degli stati problemi non ce ne sono anche via MQTT ma per chiamare i servizi di armo/disarmo/reset allarmi, etc.. onestamente non so come funzioni.. non vorrei che vada modificato qualcosa anche nella mia integrazione per esporre in qualche modo la chiamata ai metodi interni anche via MQTT, con passaggio parametri, etc... Effettivamente sarebbe interessante come implementazione alternativa così l'integrazione diventa utilizzabile anche senza Home Assistant, come in realtà era in passato prima della migrazione a ESPHome.

Tengo aperta la issue, quando hai aggiornamenti facci sapere 😄

[joyride1176]

Ciao Lorenzo

ho fatto una prova non si riesce a compilare il binario per una serie di errori come il seguente Ho comunque disabilitato l'addon esphome risparmiando ram quindi non serve ulteriore supporto

Grazie

Stefano

Compiling .pioenvs\allarme\lib9d6\ESPAsyncTCP-esphome\ESPAsyncTCPbuffer.cpp.o In file included from src\main.cpp:137: src\bentel_kyo32.h:23:88: error: 'api' has not been declared 23	class Bentel_Kyo32 : public esphome::PollingComponent, public uart::UARTDevice, public api::CustomAPIDevice {

               ^~~

On Sat, Jan 6, 2024 at 9:22 AM Lorenzo @.***> wrote:

Reopened #45 https://github.com/lorenzo-deluca/espkyogate/issues/45.

— Reply to this email directly, view it on GitHub https://github.com/lorenzo-deluca/espkyogate/issues/45#event-11407583503, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUADZS6ZV3NIXTUXERAKATYNECS3AVCNFSM6AAAAABBOEFOAKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGQYDONJYGM2TAMY . You are receiving this because you authored the thread.Message ID: @.***>

[lorenzo-deluca]

Mmmh, capito, effettivamente il mio codice eredita una classe dal namespace API, se lo togli non compila. Se non ricordo male serve proprio per registrare i servizi che vengono chiamati da Home Assistant.. quindi mi sa che non è possibile toglierla senza rivedere completamente il funzionamento dell'integrazione.