Which version of node-red are you using? I notice that you have specified V5 of MQTT, the code for that is fairly new. If you are not using node-red 3.0.2 then perhaps you have not got the latest mqtt code.
If you are not actually using the facilities of MQTT V5 then drop back to V3 and see if it helps (but upgrade node red first if you are not on 3.0.2)
Node-red version is the v3.0.2, node JS v16.19.0, Mosquitto v2.0.12. So there shouldn't be a problem with MQTT 5
it's a property within the payload. Anyway, I'm setting the debug node to the console as you suggested, so I can even compare the pi that works with the one tant not, and show their logs
And yes, I put back the keepalive to 60
This looks suspect to me. MQTT disconnecting after a "job" involving file writes. I suspect you are starving the event queue and the issues you are seeing are a side effect.
How big a process is the HistSave? Does it take 2+ minutes to complete? Is the file writing synchronous?
Are you looping data / calling fs directly?
Can you show us this "history save" flow?
Can you say where these CSV files are being written to (on device? across network?)
Also, can you add something to your flows that mark the START and END of this HistSave (even something like a debug message sent to console so that we can see a timestamp and a message like "HistSave Starting" and "HistSave Finished"
I assumed that. However, you said that it is the time the message was sent to the broker. That is obviously not strictly correct. You cannot set the timestamp at the instant it is sent, it must be before it is sent. That is why I would like to see where you are setting that in relation to the MQTT node.
There is still the fact that it is new code, so it may be worth going back to 3 as an experiment if nothing else. @Steve-Mcl may well be on a more fruitful track however.
When you run top is the cpu loading always low?
Yes correct. I wanted to say that I have the timestamp of when tha data is full processed and ready to be sent to the mqtt out node. It's a simple timestamp as property within the payload, So, looking at pi node-red debug (when it leave the last node before the MQTT OUT), looking at the Debian PC node-red debug (when it is received) and knowing that it is an on the fly message (not the file), looking at these timestamp totheter with the debugnode ones, it is easy to understand that it is an old message,, Even because each 10 minutes, if the CLIENT is offline, the data are sent as file. So or the data are sent on the fly, or it is a file, That's why it is strange that I receive data on the fly older than 10 minutes, and this is why i'm wondering about the queue messages. Since I can detect thete there are times when the client is connected for node-red but it is not for the broker, in this situation what happens? where are the messages that reach the MQTT? Are fired and forgot anyway? Or it can happen that they are queued in some way and sent when the client is back really connected to the broker?
this is now an example of the debug that I'm sendng to the consol, so that it will be easy to compare with the ones received on the debain PC
It's just a node that takes data from context and writes them on a file using read, write, and csv nodes. The full process is synchronous; fs is used to check if the file already exist and delete it. It's not used for.writing. Moreover, there is a gate at the beginning of the process so that only one data per time can be processed while other incoming data are eventually dropped till the full proces is ended and message from yhe last node sent to the MQTT OUT, or stored.
Basically, if there is no MQTT connection data is directly stored on a file. In the picture you can see the line managing the gate, the one that operate on the storing file, and the last one that sends messages on the fly.
The file is written directly on the pi. The proces itself is very simple and quick, as you can see. I stopped the MQTT connection fpr more then 10 minutes so it is the real situation. The problem is that I cannot make this test on the pi that create problem since it's not easy to reach and working remotly via GUI is very slow
What is the network path between the pi and the machine running the broker?
If you connect to the pi are you able to connect (SSH) from there to the machine running the broker? If so, does it give you a terminal with a good keyboard response? Echoing characters instantly and running commands ok? I am wondering whether you have an extremely slow connection so messages are queuing up on the input to the mqtt node.
Hi, I have made more testing, even via SSH and yes, as suspected the connection is really bad and this is probably the cause. I tried using MQTT v 3.1 but haven't helped. The slow connection seems to create this huge queue into the mqtt out node. So, from the debug and the log I see the message as correctly sent, but actually it isn't, and this is why only after a while I can see the message passing through the broker. What I don't know is if this behaviour can even cause the fatal error that crash node-red. This is for the main problem.
But still there is something I don't understand, and this happens on several raspberry even with good internet connection. As shown in the previous messages, sometimes the broker sees the client disconnected and I receive the will message. But for node-red it is still connected. Only after a while (it can even reach 40-50 minutes) node-red see the client as disconnected from the broker, so it tries and gets the connection back. Now the keepalive is set to 60s.
Has someone else experienced this behaviour? I even tried with a simple flow that does nothing but send a random number each minutes. This always happens