I have also found that the subscribe is a bit fragile at this time. Network problems can cause a core’s subscribes to stop working. @Dave mentioned that it is on their list to fix in upcoming firmware, but nothing so far. My work around is to detect a timeout in receiving data from the subscribe and do a System.reset() to restart the whole thing. It then works for awhile until it doesn’t - then reset again. Not ideal, but I am living with it. Beware…
Hi @Muskie,
Good point! There are some firmware improvements as well on the roadmap, and the rate limits / filters can be confusing. We’ll keep working on making it better! 
Thanks,
David
Hi @Dave, given what @Muskie has said about unreliability with subscribe/publish - am I better off using some other means of communicating between my cores?
Hi @daneboomer
Publish is very reliable (but the internet is a big place). Subscribe has trouble when you lose the cloud connection or WiFi you would have to re-subscribe and currently there is not a good way to know that you have to do this (but it is on the list). There are a few work-arounds that a less severe than reseting.
That's interesting. So if you operate in Manual mode, then you would be able to detect if you have lost your cloud connection and just reconnect + resubscribe? Would that do the trick?
Hi @mtnscott
I think it depends on when you lose the cloud–if you lose it while connected you can’t tell when it reconnects since that code blocks the user code. There is a way to peek into the Spark.subscribe data structures, I’m sure.
@bko According to the documentation when using SYSTEM_MODE(MANUAL) the cloud connection does not automatically attempt reconnection. The documentation suggests that after a few calls to Spark.process() to (I assume) allow the flags to properly update and then Spark.connected() should return false after which you can enter your recovery code. I have not tried this, but It should work.
Hi @bko, is there any change yet to whether or not the core can recover from a loss of connectivity? I can’t quite believe the core (surely a device built from the ground up to be internet enabled?) can’t cope with a brief WiFi dropout? Thank you! 
Hi @daneboomer
I am not sure I understand what you mean by recover from a loss of connectivity. Of course it recovers, but you have to decide which of the three modes you want to be in and how it recovers.
Trying to connect to the Particle cloud is a blocking operation today and your code does not run until you connect or fail, if you want to connect to the cloud. If set up your code to start in MANUAL mode, you have full control over if and when to connect to WiFi and if and when to connect to the cloud.
If this does not answer your question, please ask it in a more specific way, like a use-case scenario so we can figure out what you are trying to do.
sorry @bko. I’m running this code and I have found a couple of times that if a core drops a connection, when it refinds the WiFi, it no longer responds to input from the other core it was previously talking to, nor does it send information to the other core. I don’t how to alter this behaviour but will happily read up on it if if there is a help page somewhere on this topic.
OK @daneboomer , now I get it. You are running into the problem that subscribing to events on a Core currently depends on the TCP connection to cloud being continuous. Interruptions in that connection cause the subscription to be lost. You can call subscribe again but only upto four times.
Please see this thread:
Some people have taken to reseting their core on a timer to work-around this but that seems a bit extreme.
Hi @bko. Is it extreme because there are other, better ways to handle this bug? For me this is a massive issue - or maybe it’s only massive because I don’t know of other ways to do what I want to do. particle publish/subscribe seemed like the perfect solution for this use case but now it seems to be crippled?
Hi @daneboomer
What others have done is to have a heart-beat event and have your code notice that you are not getting that event for some period and take action.
The action can be to re-subscribe if there are less than four subscriptions or restart the core otherwise.
I think this bug will be fixed eventually so this would just be a work-around.