For the benefit of others... (MQTT on a Core)

Firmware
1

I resolved my MQTT on a Core problems myself (for once!!)

I inserted the dreaded delay() (quite a long one) into the connection startup sequence and I guess that must have just given the Core enough time to connect to the MQTT broker. Without it, it wasn’t happening. It’s interesting because the Photon doesn’t need this delay at all, so I was tearing my hair out trying to figure out what was going wrong.

if (init) {
        delay(10000);
        client.connect("core_one", "", "", "home-assistant/heartbeat/", MQTT::QOS1, 0, "DEAD!", true);
        delay(500);
        setMqtt();
        delay(200);
        init = false;
        delay(200);
    }
    if (client.isConnected()) {
        client.loop();
    } else if (millis() - lastConnect > RECONNECT) {
        lastConnect = millis();
        delay(1500);
        init = true;
    }
2 Likes
2

congrats on the fix and for not giving up!!! :champagne:

2 Likes
3

Thanks Gus. So, an update on this…it MOSTLY works…but every coupla days I need to reset the Core. At random (but it’ll usually go a coupla days before this is necessary) I find things have silently stopped working and when I look at the Core it’s either flashing green or breathing blue (think I’ve got that breathing/flashing distinction correct!)

In any event Particle seem to have done that annoying thing IoT companies do where they’ve hidden/deleted the Core docs relating to the LED error codes because they seem to want to pretend the Core never existed. Humph!!

4

The Core colour codes are just the same as the Photon's
https://docs.particle.io/tutorials/device-os/led/photon/

While the Photon may have more, you won't need to know them for the Core as it wouldn't present them to you after all :wink:

The rest of the Core docs has been moved into the "discontinued" section
https://docs.particle.io/reference/discontinued/firmware-core/

The issue you describe sounds like a memory leak/heap fragmentation issue.

5

Thanks, Scruff.

A new error today when trying to use the CLI to introduce a system.reset heartbeat check.
Screenshot 2020-04-13 at 23.41.34

as far as I can see I’m not doing anything different to normal…??

6

This seems to be something for @jvanier

7

Have submitted a ticket. The Mac CLI is quite unstable but all the same I checked, double checked and triple checked my command thinking it must be something I was doing! :laughing:
Thanks Scruff

8

Thanks for letting us know. This will be fixed in the next CLI release.

2 Likes
9

Thanks. Is there anyway I can downgrade to a previous non-buggy release? Would quite like to try to fix my MQTT problem soonish. On the other hand if the next CLI release is imminent please just say :slight_smile:
Thanks

10

Hi Dane,

I’m told that there will be a new CLI release in the near-term, but I don’t have a specific date I can offer. We don’t believe that a CLI downgrade will resolve the issue, unfortunately, as it’s likely this issue has been around for quite some time.

11

If it helps @jvanier and @marekparticle, the issue was not present on the 11th of March. This year.

12

Thanks, Scruff, I guess it could be but it seems unlikely because I've got lots of more or less identical code running on Photons with no (major) issues. This is my first attempt at getting it working on a Core and it's a fair bit more difficult. The time at which the Core starts flashing green or breathing blue varies, can be days can be hours, can be seconds. Can I use the wifi.on and wifi.off in fully automatic mode as standalone commands to try to repair a faulty connection? Something (?) seems to go wrong between the broker and the Core and the connection never seems to repair itself as the Photons seem able to do. I'm wondering if I was able to detect a lost connection to the broker if I could cycle the wifi and cloud connection (and thus the MQTT broker connection) just by calling wifi.off - delay - wifi.on ?
Thanks!

Just wondering...could it be SYSTEM_THREAD(ENABLED) which the Core doesn't like ?

13

@daneboomer, the Core firmware doesn NOT run FreeRTOS like the Photon does due to memory limitations. As such, you can assume that SYSTEM_THREAD() is not a factor. The Core uses entirely different WiFi hardware than the Photon, has a LOT less available RAM and Flash. In addition, IMO, the last reliable firmware version for the Core is V0.7.0.

Given that the Core runs as a single threaded application, you need to ensure that your code runs a non-blocking loop() as much as possible, and when delayed, try calling Particle.process() as often as possible (which happens when loop() ends). The delay() function will also call Particle.process() for delays longer than one second I believe.

14

Ah. @jvanier and @marekparticle - I see what’s happened. The Core hasn’t been catered for. The same command works for the Photon. I would REALLY like to go back to a version of the CLI when the Core hasn’t been written out of Particle’s back catalog, please!! :slight_smile:

15

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.