MPC9808 Temp Sensor Control
Actually, it is very clever, and as long as you know how to use it
And yes, your are a very clever chapie I'm sure (I was simply providing fact's based on MQTT documentation). For a connection to the broker a Last Will can be set that will comprise of a topic and payload. If an unexpected disconnect occurs the (after a time of waiting for some more client pings) the broker will publish this Last Will message. All other clients who wish to know about this disconnect need to be subscribed to the topic and, if so subscribed, will receive the LWT message.
No extra manual functions as you suggested are required, and it couldn't be any simpler
You will need to program the mqtt message callback in the receiving client program as to what action your program should take on the message receipt. (just as you would for your own home brewed functions, so those things cancel each other out, however, they were not in the scope of what the original question the OP was asking about)
Just setting up a LWT as you suggest is not sufficient. (not true, it actually addresses exactly what the OP asked about: "From OP: (Any suggestions on how to determine the operational status of the MCP9808?)", which is what I originally responded to)
If the "network" has gone down, then that has absolutely nothing to do with MQTT! That is clearly a "network" issue, and a different issue altogether - I think blind Freddy can see that!
I suggest you try the following. Set up one of your ESP32's to be a client that publishes a temperature reading and other to be a client that receives the mqtt message and prints it to a lcd gui display. Assuming you are using a local mqtt broker then shut the broker down, (pull its ethernet connection, power cord, or shut down properly, no matter). Then go look at the at the display, what do you see. Of course you still see the last temperature that was received. Any LWT message? - no there is none the broker is not sending anything, its down. Now doubt such a clever chappie like you will immediately divine your network or broker has gone down, but for the rest of us mortals a bit of code to trigger a warning that temperature reading showing is out of date will be a very useful thing to do.
How can there be any messages if you bring down the network by pulling out the power cord | etc...?
The clever chappie here is actually the MQTT protocol, I'm, merely trying to point that out to you, but you refuse to acknowledge that fact. You have mentioned the pings a couple of times, but had you understood how they work, you would realise that for every client PINGREQ (request), there MUST be a broker/server PINGRESP (response) sent back to the client, and the MQTT protocol mandates that disconnection must occur if either the client or server do not receive it within a given keep-alive timeframe, thus, from this situation, you can detect if the broker/server has lost communication from a client perspective.
Furthermore, in the loop section of your version... you would also need to manage the time interval as to when to make such checks, and then incorporate additional logic based on above function calls as to what to do and when. All this does is add ~20-30 lines of code,
As I mentioned a warning could triggered in the on-disconnect callback of the client expecting the message. You mention publishing a mqtt message in this circumstance, but of course, as the broker or network is down you would be rather wasting your time, but of course one the callback would be used to trigger some code at that point to issue the appropriate warning.
One could also choose to code up a very simple time of last reading check. Now 20 - 30 lines of code is not required to do this. If you need to see how to do this I refer you to an example I put up to blink 3 LED in a post on c++ classes. The code snipped simply blinks an LED based on elapsed time. So instead of blinking an LED call a function to issue the desired waring to the gui.
So there it is, I simply provided some feedback on the LWT to say it may not be sufficient and a good alternative could be a last time received check for a simple catch-all.
I'm sorry, but nothing in this or any other of your replies proves that coding your own solution is a better option than using the built in MQTT solution, to which I have actually provided documented (one line of code) evidence for.
You replied in a rather rude fashion. (please keep your blind Freddy insults out of your posts and try not to get another of your posts from being blocked or removed.).
I was not rude at all... that's a simple figure of speech, and I could have easily just said "you're just stating the obvious". Btw... it wasn't my post, to which you instigated it's downfall and subsequent removal.
I see in your latest post you now appear to understand that just a LWT message may not be sufficient and you now include the on-disconnect callback as I suggested. You are getting there, you just need to reduce you 20 -30 lines of code to what is really required for a time check and we may be singing from the same hymn sheet. (stranger things have happened)
Huh? I provided that code as an example of what "your self brewed version with an on-disconnect callback might look like", just to provide a comparison vs the one liner from the built in MQTT functionality, and demonstrate the difference... please read my comments carefully before making such outrageous claims.
You may have seen from some other previous posts that froggy has had his post thread locked and one recent one deleted. I find, when I offer some posts on mqtt I often get trolled by froggy who appears to want to prove something but offers up near insulting posts with incorrect assertions. Yes I have responded with my last post basically telling him he's a twat. Yes it must be tedious to read our exchanges.
Posted by: @frogandtoad
Please, lets examine the facts:
The question from the OP was:
"Any suggestions on how to determine the operational status of the MCP9808?"
I provided the following response to the OP:
No need to build in-house checking solutions, as the MQTT "QoS" and "Last Will"
messages were incorporated to do exactly that.
No trolling here - I provided factual information to the OP, based on my experience and MQTT documentation.
You on the other hand, trolled my post immediately thereafter, attempting to downplay the documented facts I presented to the OP. You have continually moved the goal posts to include network outages, broker/server outages when that wasn't even the original question from the OP to what I responded.
But fear no more, even though a few have indicated to me he has been 'reported' in the past and even has had moderator warnings (or so I'm told) these sort of posts could easily continue. So I will now bow out from the forum and post no more. Did I hear cheering 😯
At least there should be one happy frog 😀
Other than spite, I'm not sure what relevance regurgitating the past has, but for completeness, let's not forget that you were a significant player and instigator in those posts, and that you too were reported and warned!
Likewise, up until now I thought we were having a civil debate, but you feel the need to swear at me using genital names? This is exactly how you've instigated previous posts to be removed, but I won't retaliate this time so people can see for themselves.
@byron @frogandtoad Watching you two titans go at it is entertaining, but I for one am completely lost. For two guys who seem to be fairly knowledgeable about these tech matters, you both seem quite incapable of debating sensibly. I am sure you can (and if you try to engage me I will ignore you) both 'prove' you are right. WHO CARES, instead of nit picking, produce complete code examples of competing solutions if that is the case and I doubt it is. You both seem to enjoy pointing out minutiae at the expense of the bigger picture. I know from talking offline to many members, that we all really hate the nonsense you tend to get involved in, but at the same time we are saddened by the thought that this garbage may be getting in the way of the rest of us learning from the both of you. I am normally one of you, but in a moment of great clarity I can see what is happening. Gentlemen, I truly want to see you both make the huge contributions I know you are capable of, but are you a big enough man to overcome your ridiculous nit picking? I truly hope so, but I can already hear a certain fellow forum member whispering in my ear that it will not happen. Prove him wrong, I dare you.
Up until now, I thought we were having a civil debate. I've been putting forward facts according to documentation and my experiences. I would have thought it should be educational to the viewer rather than entertaining - My only goal is to provide correct information, and the best solutions possible, so as to not mislead the viewer.
Providing facts is not nit picking Ron...
Is there something wrong with having a debate to determine the best outcome?
Isn't that what debates are all about?
...or, should we just succumb to what someone says without questioning them, and letting everyone walk away believing the wrong thing?
Debates are how we learn, and any one of us could be wrong, and I love it when I'm wrong, because that means that I learnt something new. But if you're going to debate something, then you need to present a good level of evidence to prove your position, otherwise concede your position and acknowledge the opposing evidence presented before you.
You asked for an example, here is one:
That's how simple it is - What any subscribed clients do with the status message is up to them and your design, however, this code directly addresses the OP's question, and demonstrates how easy it is to implement and removes the responsibility from the programmer to manage it.
It's one extra line for the client.will_set method.
If anyone feels that they can do a better job of managing it manually, then please put forward your solution, which I can guess right now might be 30 or more lines of programming code, of which you will have to handle and manage all events yourself.
Please, lets not stifle and confuse passionate debate with censorship - There is enough of that going on in the world already!