Particle.unsubscribe() doesn't preserve system subscriptions

[sergeuz]

Problem

Particle.unsubscribe() clears system subscriptions to cloud events along with the application subscriptions and disrupts functioning of IOTA updates.

Solution

The list of registered event handlers is managed by the protocol layer that doesn't distinguish between system and application events. As a workaround, the system layer now re-adds system subscriptions after clearing them via the protocol's spark_protocol_remove_event_handlers().

Steps to Test

Verify that a product application based on the example code below can be updated OTA. Alternatively, add some logging to the systemEventHandler() function and verify that the system correctly receives particle/* events during handshake.

Example App

#include "application.h"

SYSTEM_MODE(SEMI_AUTOMATIC)
SYSTEM_THREAD(ENABLED)

// PRODUCT_ID(...)
// PRODUCT_VERSION(...)

namespace {

bool updatePending = false;

} // namespace

void setup() {
    System.disableUpdates();
    Particle.unsubscribe();
    Particle.connect();
}

void loop() {
    if (!updatePending && System.updatesPending()) {
        updatePending = true;
        System.enableUpdates();
    }
}

References

• [ch74478]

[technobly]

Since there is no error handling other than logging a failure, would it make sense to break these out into separate calls like they were before so spark is always attempted to be registered, even if particle fails? We could probably also change the LOG to LOG_DEBUG to keep the file size down.

[avtolstoy]

Looks good. Shame that we cannot easily trigger spark/ or particle/ event to add some kind of a test.