I have an ESP32-CAM module that I want to run in my greenhouse too far away for the WiFi to reach. I added a WiFi extender that gives me a new SSID of EXISTING_SSID_EXT. Things work ok when I fire the module up close to the EXISTING_SSID but when I locate it in the greenhouse it fails to connect to MQTT with the Failed with state -2 message. I know it is connected to the EXISTING_SSID_EXT because I can see the serial messages. It has multiple tries but fails every time. Is it failing because it previously connected on the EXISTING_SSID and wont let it connect under the new SSID?
So just to be clear - it works when connected to EXISTING_SSID but it does not connect to MQTT when reconnected to EXISTING_SSID_EXT
I am a bit confused about exactly what the problem is. As you describe it the problem seems to be to do with the CAM module connecting to the MQTT broker. Is that right? if so it doesn't appear to be anything to do with node-red. If so that doesn't mean no-one here can help, I just want to make sure I understand the problem.
So the sequence of events is this. Power up module in the house and it connects to the EXISTING_SSID fine. It connects to MQTT fine. I can demand photos and that's fine. All ok. Now when I move the module to the greenhouse, it now connects via the WiFi extender to EXISTING_SSID_EXT, which has the same password and it indicates what the new IP address is. So I know it connects to the WiFi ok. But, monitoring the serial output from the module, it then indicates it is trying to connect to MQTT but fails with a code -2. So, it basically sits there doing retries at connecting to MQTT. So, nothing works as regards taking pictures.
So, yes the problem is connecting to the MQTT broker.
I haven't tried cycling the power to the Pi running the MQTT broker as yet. It's at a remote location so not easy to do now that I have come away from there.
I wondered if the fact I had connected with a user name on one IP address would mean I couldn't log on via the extender with the same user name. I wondered if I had to 'disconnect' from MQTT as that user before connecting again.
Which broker are you using? Look at the broker log, that may tell you something.
Mosquitto. I don't know how to look at the log. I'll google it. Thanks.
I think I have found a way of looking at he log using
sudo tail -n20 -f /var/log/mosquitto/mosquitto.log
I have brought the module to a different location with a different SSID and I get the following
1688880762: New connection from 192.168.1.123 on port 1883.
1688880762: New client connected from 192.168.1.123 as bc_cam4 (c1, k15).
1688881794: Client bc_cam4 has exceeded timeout, disconnecting.
1688881794: Socket error on client bc_cam4, disconnecting.
That sequence repeats over and over.
I am over at the remote location tomorrow and will try it over there whilst monitoring the MQTT log.
Not sure what the (c1,k15) means in the above.
Is there a way of finding the reason for disconnect?
Thanks again
The reason is that too long has elapsed since the broker last heard from the client. Note that it does not disconnect until 17 minutes after it connected, the timestamps are in seconds. If you edit /etc/mosquitto/mosquitto.conf and add the lines
log_timestamp true
log_timestamp_format %Y-%m-%d %H:%M:%S
and restart mosquitto:
sudo systemctl restart mosquitto
then it will show human readable timestamps which may help to see what is going on.
Is 192.168.1.123 the failing device? If so then it is successfully connecting according to the broker.
If you also add to the conf file
log_type all
then I think you will get a vast amount of extra log info, which may be helpful.
- what are you using to code the esp32-cam?
- do you have code that choses the best wifi?
- do you have code that watches for an MQTT disconnect and will reconnect?
If you are using the Arduino IDE, take a look at the example at ESP32 MQTT Publish Subscribe with Arduino IDE | Random Nerd Tutorials
Thanks for that. That log is not for the problem SSID. That is what happens at home. I am going to the remote location tomorrow and will try it with the problem SSID. I now have some tools to look at what is happening. I have included some Serial.print statements to help me too. I'm using an old Samsung phone with Terminal on it to monitor the output. Should be able to get a scope on it too.
Thanks. That looks really helpful
1 Like
I'm using Arduino IDE and yes it uses WifiMulti.h. The code is based on that RandomNerdTutorials program and works for other modules on the same SSID. However, none of the other modules are connected to the _EXT SSID, so this is a first. The WiFi extender allows me to use the module down the end of the garden. I have of course included the extender SSID and Password in the ist for WiFiMulti. It connects to the WiFi but not to MQTT.
I may have confused the information by listing the log for the problem module - but connected on a different network. I will get the log for the problem network tomorrow.
Ok. Here is what happened at the remote location. First modified the mosquitto.conf file as described above. However, mosquitto would not start again because of any error. So edited it back out again. No big deal just the format. Must check on why though.
Next added the line log_type all and this was most useful. I have yet to check through the log to see what is going on.
While reprogramming the ESP32-CAM module, I added a short piece of wire to the antenna on the pcb. 6.25mm in fact. While monitoring the ESP module, situated in the greenhouse, using the serial output monitor, I noticed that there had been a considerable improvement int the signal strength of the WiFi from the router. Almost the same as from the WiFi extender at about -70dB. So, I did the easy option and turned off the extender. Then when I rebooted, it logged into the router directly and immediately managed to connect to MQTT. Sorry if this w=is the cowards way out, but I'm all for simplicity!
All I can say is that going via the extender, it did log into the router successfully but it failed multiple times to connect to MQTT. I have a log and will search through it for a clew but nothing leapt out at me.
Thank you for your interest and your assistance. I have learned yet more.
Back home again and I have had a look at the log. I can't see any reference to a request to connect from the module in question. Nor is there an entry that indicates a rejection. So puzzled.
Is there a way of seeing what clients are connected to mosquitto?
If there isn't any mention of the device in the mosquitto log then the connection messages didn't get through. Are you sure that the module can see the machine running mosquitto? Try adding some ping requests into the module code.
Can you ping the module from the machine running mosquitto?
No. But I found this in a Google search:
You can get mosquitto to log each time a subscription request is which made which you could then use to build a list. Edit the mosquito.conf file (at /etc/mosquitto/mosquitto.conf on a raspberry Pi) and add:
log_type subscribe, unsubscribe
[UPDATE]
This caused mosquito to fail on a restart but when I look at the moquitto log I see the IP's of devices.
pi@mqttpizw:~ $ sudo tail -n20 -f /var/log/mosquitto/mosquitto.log
1689011078: New client connected from 192.168.48.62 as nodered_19d0f4885bdfc1ab (c1, k60).
1689011078: New connection from 192.168.48.63 on port 1883.
1689011078: New client connected from 192.168.48.63 as nodered_b783de428beccebf (c1, k60).
1689011078: New connection from 192.168.48.63 on port 1883.
1689011078: New client connected from 192.168.48.63 as nodered_c9cfcdbe726abf5f (c1, k60).
1689011092: Client ESP8266Client-a04d has exceeded timeout, disconnecting.
1689011092: Socket error on client ESP8266Client-a04d, disconnecting.
1689011095: New connection from 192.168.48.3 on port 1883.
1689011095: New client connected from 192.168.48.3 as be3298b6-0c50-46d8-aa4d-87292e6f8121 (c1, k60).
1689011095: New connection from 192.168.48.61 on port 1883.
1689011095: New client connected from 192.168.48.61 as 1114ca6e-57cb-4430-ad96-7dcba71ddb60 (c1, k60).
1689011095: New connection from 192.168.48.221 on port 1883.
1689011095: New client connected from 192.168.48.221 as 99a87d45-111a-411c-9ab0-7ae54a73df67 (c1, k60).
1689011095: New connection from 192.168.48.70 on port 1883.
1689011095: New client connected from 192.168.48.70 as aa2a945b-f740-4288-8641-de2adab16147 (c1, k60).
1689011095: New connection from 192.168.48.62 on port 1883.
1689011095: New client connected from 192.168.48.62 as b60cfbf8-2291-4b07-be61-29f31c57ef66 (c1, k60).
1689011097: New connection from 192.168.48.63 on port 1883.
1689011097: New client connected from 192.168.48.63 as c0e2d183-95d4-408b-9312-6b0bb9dec5c8 (c1, k60).
1689011143: New connection from 192.168.48.229 on port 1883.
which might be helpful to you.
That sounds like a useful thing to be able to do - if I knew how! So I presume on the Pi running mosquitto, do I send a ping command to the ip address of the module?
Not sure what the code in the module would look like to send a ping.
All these things sound like useful things to do.
Thanks
Yes that sounds like an easy thing to try. At present I am getting pages of messages because log_type is set to all.
I can't try these things for about a week. I am told I have to go on holiday! Rats. Women don't understand these things!
Thanks guys
1 Like
Not sure if it could be related but most of the WiFi extenders I have used change the MAC address reported for connected devices.
So your DHCP server may be be allocating a different IP to the ESP or even blocking it if you have MAC filtering setup.
Thanks for the suggestion. I'll have a look.
I also have an ESP32 in my greenhouse for monitoring soil moisture levels that are sent back to node-red via MQTT. I gave up with wifi extensions as they were just too problematic and have now installed a mesh network that covers the entire property.
