You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we send available = true over mqtt for every state update we get. We also subscribe to all mqtt messages. This got me thinking a bit.
Mqtt has the option to use QoS (quality of service) and set 1 - "at least once" or 2 - "exactly once" delivery (we currently use 0 "at most once", or "fire and forget") https://github.com/mqttjs/MQTT.js#qos. To me it seems like the QoS 1 would be a good default for us (guaranteed delivery).
There is also the option to retain messages if no client (HA) receives them which seems like a good idea to avoid issues if the HA mqtt client is unavailable for some reason. This, though, requires us to nl = true (no local) or rap = true (retain as published) when subscribing (which I think we should either way). nl = true should remove receiving a copy of sent messages back which I think is a bit redundant.
Finally we could think about if we should set devices as unavailable when BLE is not connected. For the version on the way for 0.7.0, #169, the write queue is kept if the BLE connection goes down meaning shorter outages are handled quite gracefully. For longer outages it might be nice to communicate to HA that devices are unavailable, however that would mean that things such as time-based scenarios might fail instead of being much delayed (which would be the case currently if BLE eventually reconnects).
Finally I wonder if we could start up the addon earlier during the HA lifecycle, at least in my installation it starts quite late.
Any other suggestions on mqtt/lifecycle improvements?
The text was updated successfully, but these errors were encountered:
Currently we send
available = true
over mqtt for every state update we get. We also subscribe to all mqtt messages. This got me thinking a bit.Mqtt has the option to use QoS (quality of service) and set
1
- "at least once" or2
- "exactly once" delivery (we currently use0
"at most once", or "fire and forget") https://github.com/mqttjs/MQTT.js#qos. To me it seems like the QoS1
would be a good default for us (guaranteed delivery).There is also the option to retain messages if no client (HA) receives them which seems like a good idea to avoid issues if the HA mqtt client is unavailable for some reason. This, though, requires us to
nl = true
(no local) orrap = true
(retain as published) when subscribing (which I think we should either way).nl = true
should remove receiving a copy of sent messages back which I think is a bit redundant.Finally we could think about if we should set devices as unavailable when BLE is not connected. For the version on the way for 0.7.0, #169, the write queue is kept if the BLE connection goes down meaning shorter outages are handled quite gracefully. For longer outages it might be nice to communicate to HA that devices are unavailable, however that would mean that things such as time-based scenarios might fail instead of being much delayed (which would be the case currently if BLE eventually reconnects).
Finally I wonder if we could start up the addon earlier during the HA lifecycle, at least in my installation it starts quite late.
Any other suggestions on mqtt/lifecycle improvements?
The text was updated successfully, but these errors were encountered: