MQTT messages - feasability question

(I know: stupid question. But here goes.)

I'm double checking myself as I am still not 100% sure.

I have (or will have) devices connected which will want to know the time.
They may not need to know it every second but at ..... intervals. Or maybe a one off, every now and then.

So, I set up a MQTT channel listening for 'time requests'. At this stage the message will be formatted so: --IP address-- --interval--
(Sorry formatting didn't like my use of < and >)

This is so the time message can be sent to that device rather than a broadcast.

But the nature of MQTT it doesn't really matter, does it.

I can just set up a MQTT TIME channel and when ever a period has passed, the time gets published.

There is no savings in overheads sending it to a specific device on a specific channel because it will go everywhere all the same.

So really the IP address is redundant. Needed only if that request is no longer needed and the interval can be removed from the list of publishes.

Right?
(Just wanting a sanity check.)

Yes the "one to many" aspect of of MQTT publish/subscribe model is one of its major benefits. Its essentially a broadcast sent only to subscribers who care about the message

There will be a real time time skew among the subscribers when they actually receive the message, which could be a showstopper for some applications, in which case MQTT is the wrong transport protocol.

The transmission of the TIME is only to say update the wall clock to the "right" time.

It doesn't need microsecond accuracy.

So, say, every day the clock would send out a message asking for the time.
It would be sent out via MQTT and received.

Other things may require more frequent publications, but since asking the question, I realised that rather than having "hap-hazard" times published......
If the device wants the time it asks. It gets a ONE OFF reply and that's that.

No, it gets the time when the time is PUBLISHED.

Yes, and that is fair enough.

So - now - the idea is this:
Device is doing what it needs to.
(blah blah)
It decides it needs to know what time it is.
It published a time request to MQTT.

That message is received and the time is published on a channel. The time "now".

The device receives that public message and is happy.

(space for separation)

My original idea was to try and cut down on un-needed traffic.
But that can't happen with MQTT and I realised that shortly after posting, but just wanted to be sure I wasn't missing anything.

Thanks.
Yes, I understand it gets the time when the time is PUBLISHED.
That's all I need.

Yep, why are you worried about the amount of traffic?

Honestly: I don't know.

I guess I just don't like "useless traffic"?
(or I'm anal? OCD?)

Its a small network and excessive (unneeded) traffic is not a good practice.

(just another thought)

It was originally going to be a whole timed time publishing system, where devices would queue time intervals of how often the time was to be published.

But that just became too complicated when I was going through the concept of how it would work and I had the a-ha! moment to do it where the device would request the time and a one off time stamp would be sent.

What you have described should be implementable just fine. Use one publish to trigger the time to be published back.
Or the "server" could just send the time every 10 minutes, the clients aren't likely to drift too far in that time.

Or use NTP which is the actual internet protocol designed for syncing clocks, but is nothing to to with Matt and Node-RED, so is a whole new rabbithole to explore

1 Like

I would be interested to know what are the devices need to ask for the time occasionally.

The whole idea is just more testing the water for sending messages.

I was messing about with an Arduino who is doing something else, and I got this idea in my head to have it display the time.

Just a rough time, so it would only need the accurate time every ..... 30 minutes if it needs to be nice.

Again: It was just an idea.

It has been resolved that if something wants the time, it asks.

Adding NTP to the Arduino may be a bit too much overhead for the available memory.

arduino NTP - well yes if it already has MQTT on it anyway - stick with that.
But also - no need for it to ask... as long as it has subscribed to the time then the server could send it every 10 mins or so... but yes that could mean a 9:59 second wait at start if it just missed one.

An alternative would be a RTC module. This one is based on the DS3231, which is very accurate and has battery backup:

I already have a RPI with RTC as my NTP server. Alas it is an early version RPI.

Raspberry Pi Model B Rev 2

But the recent application of sub-flows has somehow reduced the CPU load a bit.

I am working on getting a GPS working on an Arduino but that is still future work.

I use NTP on all of my devices without any issues at all. You only should be reading NTP no more than once an hour anyway - usually once every 24 hours (+ on initial start of course) is plenty. Why reinvent the wheel when NTP is tried, trusted and very stable. If you want to avoid your devices talking to the Internet, you can easily implement your own NTP time server locally on a Pi or similar.

I've never found a need for this on any of my IoT devices - nor on my Pi's for that matter. NTP works well and very reliably.

I can't think of many cases where you would need the accuracy (or cost) of an RTC?