Have you considered the possibility of using a local mosquitto broker and configuring it to bridge the relevant topics across to the master when it is connected.
Bridging with mosquitto is trivial to setup and works perfectly for me.
http://www.steves-internet-guide.com/mosquitto-bridge-configuration/
I've seen this thread pop up several times & mostly skipped it as there were some of the regulars replying.
I wonder if it is indeed it is due to network outage & eventually crashing due to memory exhaustion?
According to the info on mqtt.js...
queueQoSZero: if connection is broken, queue outgoing QoS zero messages (defaulttrue)
... so in other words, it looks like not only QoS 1/2 but also QoS 0 messages are buffered by default (this setting is not exposed by the MQTT config node and is not set/reset in the code)
@juntiedt I could show you what to edit in the mqtt node source file if you want to try disabling this QoS 0 buffering and seeing if it improves matters?
Thanks for the input.
At the moment my system runs without any problem.
However, reading through your posts and the MQTT reference was very interesting and I will try to test it with different qualities of service.
Due to polling of my one wire sensors I reduced the amount of messages for temp sensors, analog in and relay status (unipi board) to about 12/minute. This means about 60 messages within a typical router disconnect. Not very much to buffer.
fyi here a screenshot of my solar heating system using one wire sensors connected to unipi board.
from left to right : external temp, room temp, solar in, solar out, delta in out
below 12 h temp
below 24 h temp
red solar in, green solar out, yellow room temp, blue external temp
many thanks for all your input on this threat!
1 Like
