Real problems with WiFi dropping out for some reason

My WiFi router is really quite close to my Particle devices. The router is running in ‘G’ mode only. The channel is not congested. There’s barely any other WiFi devices attempting to use the network at the moment. Yet I’m still getting LOADS of this type of thing the past few days.

Any idea what more I can do to troubleshoot?

I’m slightly concerned that the Core, Kitchen, and a couple of other Cores nearby may somehow have got themselves connected to the AP a few floors up with the same SSID - but obviously different BSSID.

Wouldn’t they at some point ‘figure out’ that the SSID upstairs is not a winner and resume connecting to the nearby AP? Is there a way of managing all this? Have tried a forum search.

I have an issue (or I thought I did until I found out about this WiFi issue) with the MQTT library on
a Core which keeps giving me hard faults, panics (and shows as a socket error on the broker) but until I can get to the bottom of the WiFi error I can’t rule that out as the underlying cause of the MQTT errors.

Any help appreciated! Thanks

  • Have you tested the stability of the connection with a simple test application (e.g. tinker)?
  • How many devices are connected to the AP, and how many DHCP IPs does it allow for?
  • What system version are you using?
  • What SYSTEM_MODE are you using?
  • Have you considered using Photons instead of Cores?
  • Can we see the code of your most stubborn device?
1 Like

Hi Scruff

  • Not yet, but I will now you mention it.
  • I will check, at first I thought I’d be well within maximum clients, but then I started adding up and thought maybe not…
  • System version SYSTEM_THREAD(ENABLED) on one of the affected devices and DEFAULT on another.
  • I’ve thought about it…but at the moment (been spending quite a bit on this stuff recently!) budget doesn’t allow for the upgrade. It will eventually.

As requested, the code from my most stubborn Core, which is either dropping out, or giving hard faults (seen in Console ‘events’ view) or giving Panic, 11 code.

It’s worth mentioning here that I’ve just ordered a replacement WiFi Router. I’m not convinced that the router isn’t the cause of my woes. Using the @hirotakaster MQTT library and some Particle to Particle code ‘borrowed’ from elsewhere on this forum.

#include "MQTT.h"

constexpr char * DEVICE_NAME = "NETPEX";
constexpr char * BELL_MSSG = "BELL!";
constexpr char * KDS_MSSG = "warehousedoor shut";
constexpr char * KDO_MSSG = "warehousedoor open";
constexpr char * KDB_MSSG = "warehousedoor bolted.";
constexpr char * KDU_MSSG = "warehousedoor unbolted";
constexpr char * FDL_MSSG = "sales locked";
constexpr char * FDUL_MSSG = "sales unlocked";
constexpr char * FDO_MSSG = "sales open";
constexpr char * FDS_MSSG = "sales shut";
constexpr char * NETPEXHOME_MSSG = "NetPex Home!";
constexpr char * MGRHOME_MSSG = "Manager Home!";

void eventHandler(const char * event,
        const char * data);

void callback(char * topic, byte * payload, unsigned int length);

byte server[] = {192,168,0,110};
MQTT client(server, 1883, callback);

// recieve message
void callback(char * topic, byte * payload, unsigned int length) {
        char p[length + 1];
        memcpy(p, payload, length);
        p[length] = NULL;

        if (!strcmp(p, "netpexhome"))
                 //Particle.publish(DEVICE_NAME, NETPEXHOME_MSSG, 60, PRIVATE);
        else if (!strcmp(p, "mgrhome"))
                //Particle.publish(DEVICE_NAME, MGRHOME_MSSG, 60, PRIVATE);
        else if (!strcmp(p, "BLUE"))
                RGB.color(255, 255, 255);

void setup() {

        Particle.subscribe(DEVICE_NAME, eventHandler, MY_DEVICES);
        if (client.isConnected()) {

void loop() {
        if (client.isConnected())
        else {

void reconnect() {
        while (Particle.connected() == false) {
                RGB.color(0, 0, 0);
        RGB.color(0, 0, 0);

void eventHandler(const char * event,
        const char * data) {
        if (strcmp(data, KDB_MSSG) == 0) {
                client.publish("home-assistant/warehouse/lock", "ON");
        else  if (strcmp(data, KDU_MSSG) == 0) {
                client.publish("home-assistant/warehouse/lock", "OFF");
        else  if (strcmp(data, KDO_MSSG) == 0) {
                client.publish("home-assistant/warehouse/door", "ON");
        else  if (strcmp(data, KDS_MSSG) == 0) {
                client.publish("home-assistant/warehouse/door", "OFF");
        else  if (strcmp(data, FDL_MSSG) == 0) {
                client.publish("home-assistant/sales/lock", "ON");
		else  if (strcmp(data, FDUL_MSSG) == 0) {
                client.publish("home-assistant/sales/lock", "OFF");
        else  if (strcmp(data, FDO_MSSG) == 0) {
                client.publish("home-assistant/sales/door", "ON");
		else  if (strcmp(data, FDS_MSSG) == 0) {
                client.publish("home-assistant/sales/door", "OFF");
        else  if (strcmp(data, BELL_MSSG) == 0) {
                client.publish("home-assistant/bell", "ON");


@ScruffR, I’ve done a forum search for “MQTT” and “reset” or “disconnects” and it looks like many others before me have had major problems with running an MQTT client on a Particle device in the past.

At the moment, the only change I’ve made is “refactor” my code to use @edwintam’s / @jpmens’s code*, so dropping the use of system.reset and the default system mode in favour of system mode manual and switching the WiFi off and on then reconnecting to the MQTT broker if a connection gets dropped.

So far, not only is that device (on which the MQTT client is running) a lot more stable but other nearby Particle devices seem more stable too. Something I can’t quite understand but am happy to observe.

  • Not sure who originally came up with the “Sum Ting Wong” code!
1 Like