MQTT, messages from offline devices

[Colin]

@Trying_to_learn

It is a birth CERTIFICATE

Where have you seen it referred to as a certificate? I don't remember seeing that, but my memory is not good so you are likely correct.

@Trying_to_learn

Topics:

Ah, I see, you meant they are each sent to one of two topics. Not that they are all sent to two topics.

Personally I would send them all to the same topic, but there is no reason why you shouldn't send them to different topics. My logic is that it is telling you the state (online or offline) so the topic identifies that it is the on/offline state and the payload tells you which it is.

[Trying_to_learn]

On the second part... Well... horses for courses. Sorry.

When I did this I didn't think like that. I wanted one to send "I am alive" and one to send "I am dead".

Putting both on the same topic didn't seem the right thing to do.

On the first part:

I think you/we are getting hung up on the term used.

Looking at the Official MQTT home page they call it a Last Will and testament
To me that is a death CERTIFICATE.
I'm not meaning to confuse the meaning with a certificate of authenticity.
But that's how I call it.
Likewise there is a Birth Certificate - which of course now I looking for it I can't find.
It has the word CERTIFICATE in it too.

I think we are going to have to chalk that up to Lost in translation.

[Colin]

@Trying_to_learn

I wanted one to send "I am alive" and one to send "I am dead".

If you had a door with a contact switch on it would you send "Open" and "Closed" to one topic or would you send "I am open" and "I am closed" messages to two separate topics? Either method would be perfectly valid.

[Trying_to_learn]

Again, I agree. But this is NOW and I did a lot of this stuff THEN.

THEN and NOW are very different. Right or wrong.

Could we concentrate on how/why I am (or at this stage WAS) getting message from devices which are not connected and turned off?

It was determined (or suspected) that leaving the RETAIN box blank for the LWT and BS blank could have been contributing to the problem More testing is needed.

Maybe it wasn't a good idea to do - but that was brought on by erroneous memory usage message from a node - I upgraded from a RasPi 2 to a 3B+ for more memory.

That happened yesterday. I'm having teething problems with it.

Until now I haven't seen any of these messages. So I can't say - one way or another - what is going on.

But the retain flag I mentioned.... Did that apply ONLY to THOSE messages or ALL messages?

I'm confused.

[jbudd]

@Trying_to_learn

And with the BS messages the machine sends out a few IFF messages and gets their replies.

Why/how are machines that are NOT CONNECTED and even POWERED OFF reply to this?

A computer that is powered off cannot send a message.

A message that appears to come from a device that is powered off was either
a) sent earlier and retained by the mqtt broker
or
b) sent by a different device but contains false information.

That's why I suggested that your IFF response messages should include the timestamp (to show when it was actually sent) and the IP address (to show the originating device).

Can you show us actual examples of these messages (topic and payload) that are "bunched together"?

[Colin]

@Trying_to_learn

the retain flag I mentioned.... Did that apply ONLY to THOSE messages or ALL messages?

The retain flag only applies to the topics that it is set for.

[Trying_to_learn]

Thanks both....

Not that I was to seem like I am avoiding what you are saying, but just now an interesting thing is happening.

This is the routine on all machines.

There are some foreign nodes. A subflow (timestamp) and a gate node used to control what is going on.
You can basically ignore them for now.
(Oh sorry and a queue node....)

[{"id":"9aaa840a.131cf8","type":"subflow","name":"Time Stamp","info":"**3 outputs.  1 - msg.payload holds the time. 2 - msg.time holds the time in a way to be used for reading time in a log file. 3 - outputs nsg.time in a format usable for file names**","category":"","in":[{"x":80,"y":100,"wires":[{"id":"6e2f05f9.3d8634"}]}],"out":[{"x":660,"y":180,"wires":[{"id":"6e2f05f9.3d8634","port":0},{"id":"df2d30dc.4a8ea","port":0}]},{"x":660,"y":230,"wires":[{"id":"6e2f05f9.3d8634","port":0},{"id":"4c048d86.0f87a4","port":0}]},{"x":660,"y":280,"wires":[{"id":"6e2f05f9.3d8634","port":0},{"id":"ebdb6996.ecdbd8","port":0}]}],"env":[],"color":"#FF8888","outputLabels":["For logging use","msg.time","For filename use"],"icon":"node-red/timer.svg"},{"id":"df2d30dc.4a8ea","type":"moment","z":"9aaa840a.131cf8","name":"","topic":"","input":"","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-MM-DD HH:mm:ss","locale":"en_AU","output":"","outputType":"msg","outTz":"Australia/Sydney","x":400,"y":180,"wires":[["ebdb6996.ecdbd8","c91e62d1.fa5ce"]]},{"id":"ebdb6996.ecdbd8","type":"string","z":"9aaa840a.131cf8","name":"","methods":[{"name":"replaceAll","params":[{"type":"str","value":":"},{"type":"str","value":""}]}],"prop":"payload","propout":"payload","object":"msg","objectout":"msg","x":450,"y":280,"wires":[[]]},{"id":"c91e62d1.fa5ce","type":"change","z":"9aaa840a.131cf8","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":230,"y":230,"wires":[["4c048d86.0f87a4"]]},{"id":"820c4f44.982f38","type":"change","z":"9aaa840a.131cf8","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":230,"y":140,"wires":[["8ebff2c7.232ed"]]},{"id":"4c048d86.0f87a4","type":"change","z":"9aaa840a.131cf8","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":230,"wires":[[]]},{"id":"6e2f05f9.3d8634","type":"switch","z":"9aaa840a.131cf8","name":"check topic","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"TIMESTAMP","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":210,"y":100,"wires":[[],["820c4f44.982f38"]]},{"id":"8ebff2c7.232ed","type":"change","z":"9aaa840a.131cf8","name":"TimeStamp","rules":[{"t":"set","p":"payload","pt":"msg","to":"","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":210,"y":180,"wires":[["df2d30dc.4a8ea"]]},{"id":"eeec424a.f9c66","type":"subflow:9aaa840a.131cf8","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","x":4370,"y":1503,"wires":[[],["a6f3614b.c96338"],[]]},{"id":"52487feb.6471b","type":"switch","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"X","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":4350,"y":1450,"wires":[["eeec424a.f9c66"]]},{"id":"a6f3614b.c96338","type":"function","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","func":"var IP = global.get(\"MY_IP\");\nvar name = global.get(\"myDeviceName\");\n\nvar a = '\"WIFI_DEVICE\":\"' + name;\nvar b = '\"IP_Address\":\"' + IP;\nvar c = '\"Sent\":\"' + msg.time;\n\nmsg = {\"topic\":\"STATUS/WIFIDEVICEID\",\"payload\":\"{\" + a + '\",' + b + '\",' + c + '\"}'};\n\n//msg.topic = \"STATUS/WIFIDEVICEID\";    // not needed.  See line above.\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":4520,"y":1450,"wires":[["d5e03328.bb55d","7750417a75475da5"]]},{"id":"25c53629.625d42","type":"inject","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"ID","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"X","payloadType":"str","x":4220,"y":1500,"wires":[["52487feb.6471b"]]},{"id":"fbdd582e.8e13b","type":"gate","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","controlTopic":"CONTROL","defaultState":"open","openCmd":"GO","closeCmd":"STOP","toggleCmd":"toggle","defaultCmd":"default","persist":false,"x":4220,"y":1450,"wires":[["52487feb.6471b"]]},{"id":"d5e03328.bb55d","type":"mqtt out","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"Device ID","topic":"STATUS/WIFIDEVICEID","qos":"","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"bbf26a6c.b7922","x":4830,"y":1450,"wires":[]},{"id":"7750417a75475da5","type":"json","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","property":"payload","action":"","pretty":false,"x":4530,"y":1500,"wires":[["cf7b95ba.9dc48","cc90213c.09dd6"]]},{"id":"a2f5ce51.4a3ac","type":"mqtt in","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"IFF","topic":"IFF","qos":"2","broker":"bbf26a6c.b7922","inputs":0,"x":4080,"y":1450,"wires":[["19092b5a.4d260d","fbdd582e.8e13b"]]},{"id":"38e6f85c.2eb788","type":"inject","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"Stop","repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"CONTROL","payload":"STOP","payloadType":"str","x":4080,"y":1370,"wires":[["fbdd582e.8e13b"]]},{"id":"9e5458e4.650f88","type":"inject","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"Go","repeat":"","crontab":"","once":true,"onceDelay":"1","topic":"CONTROL","payload":"GO","payloadType":"str","x":4080,"y":1410,"wires":[["fbdd582e.8e13b"]]},{"id":"cf7b95ba.9dc48","type":"debug","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"IFF message reply","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":4790,"y":1400,"wires":[]},{"id":"cc90213c.09dd6","type":"q-gate","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"qgate","controlTopic":"CONTROL","defaultState":"queueing","openCmd":"Go","closeCmd":"Stop","toggleCmd":"toggle","queueCmd":"queue","defaultCmd":"default","triggerCmd":"trigger","flushCmd":"flush","resetCmd":"reset","peekCmd":"","dropCmd":"","statusCmd":"","maxQueueLength":"100","keepNewest":true,"qToggle":false,"persist":false,"x":4670,"y":1500,"wires":[["b222f58f.2c302"]]},{"id":"19092b5a.4d260d","type":"debug","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":4360,"y":1410,"wires":[]},{"id":"6700dc4a.f6812c","type":"inject","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"RESET","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"CONTROL","payload":"reset","payloadType":"str","x":4520,"y":1590,"wires":[["cc90213c.09dd6"]],"icon":"font-awesome/fa-eject"},{"id":"17358a28.5cbbd6","type":"inject","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"Next","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"CONTROL","payload":"trigger","payloadType":"str","x":4520,"y":1550,"wires":[["cc90213c.09dd6"]],"icon":"node-red/trigger.svg"},{"id":"b222f58f.2c302","type":"debug","z":"675e227d.d158b4","g":"eff2cce4.08f878","name":"IFF requests","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":4820,"y":1500,"wires":[]},{"id":"bbf26a6c.b7922","type":"mqtt-broker","name":"TIMEPI MQTT","broker":"192.168.0.99","port":"1883","clientid":"","autoConnect":true,"usetls":false,"compatmode":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"SOM","birthQos":"0","birthRetain":"false","birthPayload":"BedPi Comms UP","birthMsg":{},"closeTopic":"EOM","closeQos":"0","closeRetain":"false","closePayload":"BedPi Shutting DOWN","closeMsg":{},"willTopic":"EOM","willQos":"0","willRetain":"false","willPayload":"BedPi COMMS FAILURE","willMsg":{},"sessionExpiry":""}]

It listens to the IFF topic.

If it receives an X it broadcasts its message - which includes a timestamp of WHEN it was sent.

I send an X out on the IFF channel.

I get back three replies from one machine.
All timestamped at the same time and when I look at the queue node, there is only ONE occurrence shown.

Pictures say 1000 words.
Comments are BELOW the pictures.

Nothing queued.

IFF list is empty.

I inject an IFF message. (The X is seen on the right of the picture and you see the debug node just below the MQTT node.)

2 messages/replies from BedPi

Only 1 event queued.

Where's the second one coming from?

[jbudd]

Unfortunately there is no evidence in your images to identify which of the messages 1, 2, 3 in your debug panel relates to the messages a, b, c, d shown in your dashboard.

The debug panel for BedPi doesn't show any messages at all so we can't see if two messages were sent.

The dashboard doesn't show msgid so we can't see if two messages were received or if one message gets displayed twice.

[Trying_to_learn]

Fair enough.

The messages 1 2 and 3 are from other parts of the machine.
They are (kind of) valid, but also not.

The RAW nodes are monitoring (basically) the RAW IFF message coming in elsewhere on the machine.
You see them because the machine where I inject the Identify yourself message is on one of the machines that handles the messages.

Opening them all up you simply see the messages coming into the machine.

For the sake of putting the cards on the table:

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"7a25e48ae8b2d29b","settings":{"input":"2022-03-03T23:09:59.069Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"TelePi","IP_Address":"192.168.0.93","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"59df2f10e9321a3d","settings":{"input":"2022-03-03T23:09:59.090Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"BedPi","IP_Address":"192.168.0.83","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"ecf0cf5236471c1c","settings":{"input":"2022-03-03T23:09:59.090Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"BedPi","IP_Address":"192.168.0.83","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

Given only ONE X was sent, why does BedPi have multiple replies?

Then we progress down the chain and there are these messages:

Leaving WiFI monitor

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"7a25e48ae8b2d29b","settings":{"input":"2022-03-03T23:09:59.114Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","_event":"node:50ca570c.c6f29","payload":"2022-03-04 10:09:59 192.168.0.93 Sent at 2022-03-04 10:09:59 >TelePi<","filename":"/home/pi/.node-red/public/events/IFF.db"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"59df2f10e9321a3d","settings":{"input":"2022-03-03T23:09:59.142Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","_event":"node:50ca570c.c6f29","payload":"2022-03-04 10:09:59 192.168.0.83 Sent at 2022-03-04 10:09:59 >BedPi<","filename":"/home/pi/.node-red/public/events/IFF.db"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"0c2697d6a49d36db","settings":{"input":"2022-03-03T23:10:02.235Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:10:02","_event":"node:50ca570c.c6f29","payload":"2022-03-04 10:10:02 192.168.0.155 Sent at undefined >GPS<","filename":"/home/pi/.node-red/public/events/IFF.db"}

But to me this is only the same message/s with different formatting so they can be seen in/on the lists.
Yes, this way you see more information.

But again: Why is BedPi replying/responding multiple times to ONE message?

I've checked MQTT Explorer.... The topics are empty.

[Trying_to_learn]

Going back to basics... (ok, wrong words. Vocabulary failure)

All machines don't reply to the IFF message.
There is an arduino (aka GPS - which is a kind of wrong name, but ....)

This is the state of things:

MQTT explorer shows me this:

You can see this is NOT retailed.

But/and I am only getting ONE message. Though that is to be expected.

One of the RasPies allowed to respond:

Ok, 2 seconds time delay between them replying, but no love lost and things are good.

I'll wipe the list and send another X.

All good. Only 2 replies as before.

Activate another RasPie..

TWO messages from BEDPI and nothing from the other machine (shown) which isn't BedPi.

But going to that machine and looking in its queue I see this message - sent:

{"topic":"STATUS/WIFIDEVICEID","payload":{"WIFI_DEVICE":"TelePi","IP_Address":"192.168.0.93","Sent":"2022-03-04 10:47:02"},"_msgid":"3c72848b9619c1a1"}

10:47:02 But look at the name... Different.

And - adding insult to injury - it is TelePi's list at which we are looking on the GUI side of things.

So you would think it's own message would get through.

[jbudd]

@Trying_to_learn

For the sake of putting the cards on the table:

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"7a25e48ae8b2d29b","settings":{"input":"2022-03-03T23:09:59.069Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"TelePi","IP_Address":"192.168.0.93","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"59df2f10e9321a3d","settings":{"input":"2022-03-03T23:09:59.090Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"BedPi","IP_Address":"192.168.0.83","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

{"topic":"STATUS/WIFIDEVICEID","qos":0,"retain":false,"_msgid":"ecf0cf5236471c1c","settings":{"input":"2022-03-03T23:09:59.090Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2022-03-04 10:09:59","payload":{"WIFI_DEVICE":"BedPi","IP_Address":"192.168.0.83","Sent":"2022-03-04 10:09:59"},"_event":"node:628072fd.2be434"}

Given only ONE X was sent, why does BedPi have multiple replies?

Yes this shows two messages, two different msgids, from a device named BedPi and IP address 192.168.0.83.

The device name and IP address come from two global variables

var IP = global.get("MY_IP");
var name = global.get("myDeviceName");

Is it possible that you copied the code which sets these variables from one device to another but failed to change the values - so two devices are claiming to be BedPi?

[Trying_to_learn]

I really hope not.

But in the mean time I was populating the flow with debug nodes.

This is not looking good.
Order of the debug nodes:
RAW IFF
After JSON
Reformatted1
Reformatted2

RAW IFF 11:22:49 TimePi
RAW IFF 11:22:49 BedPi

After JSON 11:22:50 TimePi
After JSON 11:11:50 BedPi

RAW IFF 11:22:50 TelePi

After JSON 11:22:50 TelePi sent 11:22:49

To here it looks good.
3 devices sent their replies. All different messages out of the JSON node.

Reformatted1 11:22:50 TelePi sent 11:22:49
Reformatted1 11:22:50 TelePi sent 11:22:49

Reformatted2 11:22:50 TelePi sent 11:22:49
Reformatted2 11:22:50 TelePi sent 11:22:49

This is a worry. Suddenly I have TWO TelePi messages of which one didn't exist a second ago.

Reformatted1 11:22:50 TelePi sent 11:22:49

Reformatted2 11:22:50 TelePi sent 11:22:49

RAW IFF 11:22:53 GPS

After JSON 11:22:53 GPS

Reformatted1 11:22:53 GPS

Reformatted2 11:22:53 GPS

On the GUI side of things I have/see this:

This is the actual flow.
So there isn't really anywhere the messages can be corrupted.

[Trying_to_learn]

Ok, light bulb moment..

Can you check this subflow I use a lot.

Make sure I haven't left any elephants in it.

[{"id":"98a12d23.4caf","type":"subflow","name":"Time Stamp","info":"**3 outputs.  1 - msg.payload holds the time. 2 - msg.time holds the time in a way to be used for reading time in a log file. 3 - outputs nsg.time in a format usable for file names**","category":"","in":[{"x":80,"y":100,"wires":[{"id":"b51453d8.f777"}]}],"out":[{"x":640,"y":180,"wires":[{"id":"537f67d0.440958","port":0},{"id":"b51453d8.f777","port":0}]},{"x":640,"y":230,"wires":[{"id":"b51453d8.f777","port":0},{"id":"436ec434.1175cc","port":0}]},{"x":640,"y":280,"wires":[{"id":"c77ad598.3b98e8","port":0},{"id":"b51453d8.f777","port":0}]}],"env":[],"color":"#FF8888","outputLabels":["For logging use","msg.time","For filename use"],"icon":"node-red/timer.svg"},{"id":"537f67d0.440958","type":"moment","z":"98a12d23.4caf","name":"","topic":"","input":"payload","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-MM-DD HH:mm:ss","locale":"en_AU","output":"payload","outputType":"msg","outTz":"Australia/Sydney","x":390,"y":180,"wires":[["c77ad598.3b98e8","9a6e708b.c8249"]]},{"id":"c77ad598.3b98e8","type":"string","z":"98a12d23.4caf","name":"","methods":[{"name":"replaceAll","params":[{"type":"str","value":":"},{"type":"str","value":""}]}],"prop":"payload","propout":"payload","object":"msg","objectout":"msg","x":440,"y":280,"wires":[[]]},{"id":"9a6e708b.c8249","type":"change","z":"98a12d23.4caf","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":220,"y":230,"wires":[["436ec434.1175cc"]]},{"id":"204888d7.8b194","type":"change","z":"98a12d23.4caf","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg","dc":true}],"action":"","property":"","from":"","to":"","reg":false,"x":220,"y":140,"wires":[["93239165.b7976"]]},{"id":"436ec434.1175cc","type":"change","z":"98a12d23.4caf","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":440,"y":230,"wires":[[]]},{"id":"b51453d8.f777","type":"switch","z":"98a12d23.4caf","name":"check topic","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"TIMESTAMP","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":200,"y":100,"wires":[[],["204888d7.8b194"]]},{"id":"93239165.b7976","type":"change","z":"98a12d23.4caf","name":"TimeStamp","rules":[{"t":"set","p":"payload","pt":"msg","to":"","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":200,"y":180,"wires":[["537f67d0.440958"]]},{"id":"87a8a491.9b6fa8","type":"subflow:98a12d23.4caf","z":"c56bddee.ca0a18","name":"","x":780,"y":3020,"wires":[[],["1b15d15.3819a2f"],[]]}]

I'll do the same, but would really appreciate an external set of eyes on it.

[Trying_to_learn]

I won't tell you what I am seeing. I don't want to bias what you see.

(Not that I just want to drop it on you.)

However, I am getting inconsistent results with testing it at my end.

[Trying_to_learn]

Colin, would you mind casting an external set of eyes on this problem I have just noticed?

(Not sure if you have been reading the recent posts.)

There is something weird happening and I've asked @jbudd to look, but I'm guessing the more eyes (maybe) the better the outcome.

Look at post 51 of mine and move on from there.

[jbudd]

I cast a suspicious eye over your subflow earlier but I don't use subflows, I like my flow all visible in the same place, so I can't really comment on it.

Can we see the code for your function which feeds the Reformatted2 debug?

[Trying_to_learn]

The three outputs are for different types of use.

The first one is for use in logging file use. Time/date formatted nicely for use in a text file.
The second one gives you the timestamp (formated) as/in msg.time. You can then use it for what ever.
The third output is for use if you want to use it to make a file name.
So no /'s in it.