Notifications
Clear all
Arduino
18
Posts
4
Users
6
Likes
1,523
Views
Topic starter
2022-07-06 9:04 pm
I am using an MCP9808 temp sensor with an ESP32S3 to control devices inside my wife's rabbit shed. The sensor is working and I've tested from +100 to -20 degrees. The MCP9808 example code to start the sensor checks to see if the sensor can be found, and if not puts the program into an infinite wait state. I changed the code so if the sensor cannot be found the program will still run and will attempt to start the sensor at each temp read cycle. This will allow my wife to override the devices and turn them on with the push of a button. When I reconnect the MCP9808 (while the program is running) the program connects to the sensor and everything works. I also have this code working.
So it works when the ESP32S3 starts up and the MCP9808 is absent then reconnected. Now I would like to detect when the MCP9808 stops working once the program has started. I looked in the library and didn't see (at least that I could recognize) a function for checking status. I tried shutting down the sensor at the end of each read cycle (versus going into wait state) and then restarting at the beginning of the next read cycle. This didn't work. It would take only one reading and never update. I even hit the sensor with heat and compressed air with no change.
Any suggestions on how to determine the operational status of the MCP9808?
Thanks!
Topic starter
2022-07-07 12:25 am
Never mind....I got it working.
2022-07-07 10:09 am
You may have already thought of this but, for an extra safety margin, a comparison of the current temperature reading with the previous one to see if it varies by more than an expected range will enable a warning to be raised or another reading to be taken as a double check etc.
Another thing I do with my central heating program is to record the time a temperature reading is received (the temperature reading being received from remote temperature sensors). A periodic check is then made on the time elapsed from the last reading received to issue warnings if required.
Ron reacted
Topic starter
2022-07-07 8:33 pm
@byron Yes, I track current and previous temperatures and save them. I am also capturing the date and time of each reading. Really don't do much with the data since this is a rabbit shed and running fans can only cool so much. When it gets too hot the rabbits have a enclosed outside area then can go to. They have shade and burrows where then can keep cool. I did program that there needs to be a 2 degree difference before there will be a change in the device operation. This prevents the devices from cycling as the temp varies around the trigger point.
The only failures I am trapping is a temp sensor failure and a comm link failure (ESP-NOW) between the shed and the house. I do like the idea of checking when updates are received in the house to also identify a system or comm link failure.
Thanks for the comment.
Mike
2022-07-11 1:04 pm
[snip]
I do like the idea of checking when updates are received in the house to also identify a system or comm link failure.
Thanks for the comment.
Mike
No need to build in-house checking solutions, as the MQTT "QoS" and "Last Will" messages were incorporated to do exactly that.
Topic starter
2022-07-11 6:35 pm
@frogandtoad Very true, I used MQQT in the current system. I wanted to try something new in the updated version so I am using ESP-NOW. I wanted an implementation that did not require WIFI (for no particular reason). I am using ESP-NOW between the shed and the house (both ESP32S3) and then serial communications between the ESP32S3 and the Raspberry Pi4 (the Pi4 give my wife a graphical interface to monitor and change settings if she wants).
2022-07-11 9:29 pm
The amusingly named 'Last Will and Testimony' mqtt message only works in the situation where a mqtt client has, for some reason, become disconnected to the broker and the broker will publish the 'Last Will' (after a timeout) for all the other clients who may be listening to receive to take appropriate action.
It does not help if, say, the wifi network has gone down and the broker communication ceases to all clients. Depending on the mqtt client library, a 'on-disconnect' callback can be monitored for this. If the network goes down and (mqtt client library dependant) the client will keep trying to re-establish a connection to the broker according to the connection time-out setting before the on-disconnect callback is issued.
For the situation where a temperature reading is expected on a regular basis then it may be simpler to just to put in a last time received check. It just amounts to a simple function call in the loop that checks the millis time elapsed against the constant 'elapsed time allowed' (no magic numbers 😀 ). Compare that to coding up a 'Last Will' message check, plus a 'on-disconnect check. Admittedly I always look to keep my code as sweet and simple as I can and others milage may vary. Certainly circumstances where a 'Last Will' can be useful, but it is not the catch-all that seems to be implied.
Of course all of this is of no relevance to your ESP-NOW comms infrastructure and I only mentions it for anyone else chancing on this post.
But how is the ESP-NOW working out in practice for you? Has it proved to give more reliable comms for your set up? I did not get around to testing this as a ESP-NOW micropython library is about to be put into the main release and I thought I would await that development.
Topic starter
2022-07-11 10:38 pm
But how is the ESP-NOW working out in practice for you? Has it proved to give more reliable comms for your set up?
@byron My original system is WiFi based and used Arduino IoT Cloud. It seems to drop the link to the Arduino IoT Cloud at least once a day (not sure if that is a WiFi issue or Arduino IoT Cloud issue) and the only way we can monitor and change setting is via the cloud. I am tending to believe the WiFi signal is strong enough because we have a Wyze camera in the shed and it works reliability. I decided to use ESP-Now after watching Bill's video.
I completed some initial testing to make sure the ESP32S3s could talk across ~200 feet between the shed and the house using ESP-NOW, and that was successful. I need to make a few changes to the data structure before I integrate into the larger project yet. I have been jumping around the project and have completed the following:
1. Code that reads the temp and controls the devices is completed and tested (based off the original project)
2. Code to save the temp trigger values in the ESP32S3 memory (in case of restart) is completed, tested and integrated
3. Code to pass messages between the ESP32S3 and Pi4 is completed and tested.
4. Pi4 GUIs completed and tested. Additional features need to be added.
All the pieces appear to working so the next step is to get them integrated and tested. I plan to run the new system in parallel with the old system for awhile as part of testing.
Inst-Tech reacted
2022-07-12 11:33 am
@frogandtoad Very true, I used MQQT in the current system. I wanted to try something new in the updated version so I am using ESP-NOW. I wanted an implementation that did not require WIFI (for no particular reason). I am using ESP-NOW between the shed and the house (both ESP32S3) and then serial communications between the ESP32S3 and the Raspberry Pi4 (the Pi4 give my wife a graphical interface to monitor and change settings if she wants).
Indeed, I remember your previous post stating that you wanted to use ESP-NOW between your shed and then another ESP-NOW, then connecting to an Rpi with the screen using MQTT.
Why serial communication thereafter?
I think I mentioned last time that the ESP32 can be set up as both a station and a soft AP... if you need to know how to set it up as both, let me know.
In any case, the last will testament (LWT) message is perfectly suited to your situations, that's what it was designed for!
Please let us know if you have any questions.
Cheers
huckOhio reacted
2022-07-12 12:21 pm
The amusingly named 'Last Will and Testimony' mqtt message only works in the situation where a mqtt client has, for some reason, become disconnected to the broker and the broker will publish the 'Last Will' (after a timeout) for all the other clients who may be listening to receive to take appropriate action.
The LWM (aka: Last Will Message), was designed to work whenever a client disconnects "ungracefully" - No ifs, no buts!
It does not help if, say, the wifi network has gone down and the broker communication ceases to all clients. Depending on the mqtt client library, a 'on-disconnect' callback can be monitored for this. If the network goes down and (mqtt client library dependant) the client will keep trying to re-establish a connection to the broker according to the connection time-out setting before the on-disconnect callback is issued.
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!
For the situation where a temperature reading is expected on a regular basis then it may be simpler to just to put in a last time received check. It just amounts to a simple function call in the loop that checks the millis time elapsed against the constant 'elapsed time allowed' (no magic numbers
). Compare that to coding up a 'Last Will' message check, plus a 'on-disconnect check. Admittedly I always look to keep my code as sweet and simple as I can and others milage may vary. Certainly circumstances where a 'Last Will' can be useful, but it is not the catch-all that seems to be implied.
Let us address some of these claims:
"For the situation where a temperature reading is expected on a regular basis then it may be simpler to just to put in a last time received check. It just amounts to a simple function call in the loop that checks the millis time elapsed" (said byron)
... or is it easier to just add "LWT" details to the constructor of your connection call (incorporated by default)? As far as MQTT goes, there is NO NEED to code up any separate functions to do any checking, as it is all done for you automatically upon constructor initialisation / setup!
Please elaborate on the following claim:
"Compare that to coding up a 'Last Will' message check, plus a 'on-disconnect check." (said byron)
No example provided to compare "Last Will" message...
Cheers
2022-07-12 2:15 pm
As far as MQTT goes, there is NO NEED to code up any separate functions to do any checking, as it is all done for you automatically upon constructor initialisation / setup!
Please elaborate on the following claim:
"Compare that to coding up a 'Last Will' message check, plus a 'on-disconnect check." (said byron)
No example provided to compare "Last Will" message...
Jolly clever that MQTT, it seemingly knows just what the user would want to do when the client providing the temperature readings fails to ping the broker without any user code.
If you would like to see example coding of a Last Will message check, and when an on-disconnect is invoked, then there are plenty of examples to be found with a google.
I suggest, out of respect to the OP, who is clearly not currently using mqtt, to put any questions you may have in a separate post.
2022-07-14 1:27 pm
Jolly clever that MQTT, it seemingly knows just what the user would want to do when the client providing the temperature readings fails to ping the broker without any user code.
Actually, it is very clever, and as long as you know how to use it, you tell it how to handle an "ungraceful" disconnection via its built in functionality, then it will abide by the rules you set - The key here is that it does it for you autonomously, based on a few simple arguments passed to it during construction and setup - No extra manual functions as you suggested are required, and it couldn't be any simpler - For example:
The "client.will_set" line of code is "the only additional line of code you need" to implement a last-will message, and it handles everything for you!
After establishing a client connection, you then publish (python code)...
client.publish("rabbit_shed_temp/status", payload = "Online", qos = 1, retain = True)
Then set the LWT message for the server to report upon...
client.will_set("rabbit_shed_temp/status", payload = "Offline", qos = 1, retain = True)
The keep_alive argument == the appropriate value for your sensor and design...
client.connect(server, port, keep_alive)
As we can see, the first and third line are common setup and connection calls... the only new line required is the .will_set method call! ...as opposed to your manual version of somehow being simpler, coding up a 'Last Will' message check, AND a subsequent 'on-disconnect check as you suggest, which would look something like this (python code):
def last_will_message_check() # conditional if/else statement to understand condition (3 or 4 lines of code) # publish status to topic (at least another line of code) def on_disconnect_check() # conditional if/else statement to understand condition (3 or 4 lines of code) # publish status to topic (at least another line of code)
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, and puts the responsibility back on to you, to make sure you do all the necessary checks and balances, and in turn notify interested clients accordingly, rather than using the protocol as it was designed to handle this automatically for you.
If you would like to see example coding of a Last Will message check, and when an on-disconnect is invoked, then there are plenty of examples to be found with a google.
I am quite familiar how it works, but I do suggest you purchase a good book on MQTT to understand the protocol in detail, rather than relying on google to teach you.
I suggest, out of respect to the OP, who is clearly not currently using mqtt, to put any questions you may have in a separate post.
I recall that (from a previous post on his project), the OP was originally using MQTT, hence my comment and suggestion towards that. The OP has since indicated that he was originally using MQTT, and is now trying something different which is not a problem at all... experimenting with different solutions is never a bad thing!
2022-07-14 3:57 pm
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. 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 setting up a LWT as you suggest is not sufficient.
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.
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. 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 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)
2022-07-14 4:50 pm
@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.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
2022-07-14 5:42 pm
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.
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 😀
Page 1 / 2
Next