Argon - Particle.subscribe won't respond to public events

[drlaw]

Hi all,

I’m moving over from the Photon and I’m trying to get one Argon (Argon A) to respond to another one (Argon B) using the Publish and Subscribe method.

Argon A

int myLED = 7;

void setup()
{    
    Particle.subscribe("drlaw_PCL_LED", lightLED);    
    
    pinMode(myLED, OUTPUT);
}

void loop()
{   
	// does nothing
}

void lightLED(const char *event, const char *data)
{
      // Blink D7 five times
	for ( int i = 0; i < 5; i++ )
	{
		digitalWrite(myLED, HIGH);
		delay(250);
		digitalWrite(myLED, LOW);
		delay(250);
	}	
}

From Argon B’s Particle account, I’ve been sending the event name as a public event:

Nothing happens. Argon A never responds.

When I publish the event from Argon A’s console, as public or private, the Argon does respond and calls the handler and the LED flashes like it’s supposed to.

As I mentioned, I’m moving from using a Photon for the last few years and the above source code used to work on the Photon. The last time I tested this was in October, 2019. Has something changed since then? Why does the above source code no longer work? I did look through the reference docs but I can’t figure out what’s wrong.

[ScruffR]

What device OS version are you targeting?

[drlaw]

Ver 1.5.2 on all accounts.

[ScruffR]

I have seen this behaviour before and was sure I had filed a GitHub issue about it, but I cannot find it anymore

I guess I have to retest and report again

[drlaw]

Thanks ScruffR. Let me know if there’s anything I can do to help test.

I pulled out a Photon here too. Neither the Photon or Argon will respond to a public event from an different Particle account.

I discovered this issue today when I tried to have my class (I’m a HS teacher) test their brand new Argons. None of their Argons could “hear” my publish. I’ve used Photons in my classes for the last 4 years and this is a brand new issue for me. I just assumed it would work. Should have known better.

[drlaw]

The above clipping is about Particle.subscribe, If I’m understanding that correctly, if I omit the third parameter, the device shouldn’t respond to private publishes at all.

Right now, the devices are responding to private and public events from my own account. It should only be responding to public events, correct?

Since you’re doing some testing that seems to be another error.

[ScruffR]

@drlaw

if I omit the third parameter, the device shouldn’t respond to private publishes at all.

That is correct.

The issue might be with the console rather than device OS.
You can try CLI to issue test events public and private and see whether that behaves differently.

---

Update:
I have now tested with this code with on Photons running 2.0.0-rc.2 owned by two independent accounts

void setup() {
    Particle.subscribe("scruffyPrivate", privCallback, MY_DEVICES);
    Particle.subscribe("scruffyPublic", pubCallback, ALL_DEVICES);
    Particle.subscribe("scruffy", defaultCallback);
}

void loop() {
    static int i = 0;
    if (!digitalRead(BTN)) {
        switch ((++i) % 3) {
          case 0:
            Particle.publish("scruffyPrivate", String(i), PRIVATE);        
            break;      
          case 1:
            Particle.publish("scruffyPublic", String(i), PUBLIC);        
            break;      
          case 2:
            Particle.publish("scruffy", String(i));        
            break;      
          default:
            i = 0;
        }
        Serial.printlnf("Sent: %d", i);
        while(!digitalRead(BTN)) Particle.process();
    }
}

void privCallback(const char* event, const char* data) {
    Serial.printlnf("Private: %s: %s", event, data);
}

void pubCallback(const char* event, const char* data) {
    Serial.printlnf("Public: %s: %s", event, data);
}

void defaultCallback(const char* event, const char* data) {
    Serial.printlnf("Default: %s: %s", event, data);
}

And see that the device OS indeed does not react to public events.
Monitoring the events via CLI particle subscribe --all scruffy, particle subscribe scruffyPrivate and particle subscribe --all scruffyPublic on the other hand does work as expected.

@no1089, is this an acknowledged bug? I know I have reported that at least four months ago, but unfortunately cannot find the issue or support ticket for it.

Just a side note, as it seems when subscribing without scope both PUBLIC and PRIVATE events get caught (which is different to what used to be true and what's documented)

[no1089]

I’m looking into it - the ticket is in my queue.
Changes have been made to Public events to avoid DOS attacks, and I’m trying to understand how this is affecting @drlaw’s implementation.

Do you have any idea where you reported it? Github or via a ticket?

[ScruffR]

I think I first addressed it via the Slack Elite channel and then filed a support ticket - but the slack channel got archived, so I cannot search it anymore.

[no1089]

Ok, I’ll dig a little.

[drlaw]

Thanks for doing so much to help @ScruffR.

Thanks for helping as well @no1089.

[no1089]

I have asked the excellent @mstanley to take a look at your ticket, they have the best context surrounding this issue.

[danb0b]

Thank you, I am experiencing the same issue… Again from two separate accounts nothing gets passed, even with public scope explicitly flagged and all_devices flagged on the subscription.

For teaching purposes, all my students have different accounts and shouldn’t have access to each other’s photons.

I was going to add a question about whether I needed to group photons within a common “product” to get this feature working in 2020

[ScruffR]

As it seems Particle has quietly removed the ability to send/receive public events for security concerns as too many users just opted for the default PUBLIC scope without even thinking about the implications.

An additional factor may have been that the public event stream just got too crowded to handle with all the unintentional publishes.

However, I’m still convinced this feature should not have been killed but rather changing default to PRIVATE/MY_DEVICES or make the scope parameter compulsory in all cases.

@danb0b, grouping the devices in a product won’t work either since there is no special way for product devices to communicate internally unless they are owned by the same account (also a decision I never understood really).

[danb0b]

Confirmed. Killed off without a change to documentation. Now that explains why I was following previously working examples to no avail! I guess my time is not valuable.

It seems there is a solution, though it isn't necessarily workable in all situations. Requires paying for a "product", and then takes some setup that might be hard if, as in my case, you have already distributed the devices to users.

Here's the response I got from my support ticket:

Particle's public event stream was recently deprecated due to security concerns. By nature of the public event stream, devices in these streams were at risk of malicious outside actors sending events to customer devices--sending either unintended events or causing excess data consumption.

Particle is working toward a more secure alternative. This solution is the implementation of Product event streams, where all devices within a Particle Product will be able to communicate with one another. Currently, this is being investigated for Device OS v2.0.0.

I recognize you may require a shorter term solution. As such, I am happy to offer you a temporary solution. Create a Particle product and add all of your devices to this Product. Once this is done, I will have my engineering team set a special flag for this Product to re-enable access to the public event stream.

Devices in this configuration will be able to communicate with one another through the public event stream until Device OS v2.0.0 and product event streams go live. At that time, this feature flag will be disabled and all public events will be channeled to Product events. Because your devices will already be configured in a Product, this change should have no impact on your implementation.

For users to be able to interact with these devices, it is important that they also claim these devices to their own developer accounts.

Please do bear in mind that, with this interim provision, any other customers with access to the public event stream will also technically have access to the same event stream you are using. This re-opens the security holes that were addressed by deprecation of the public event stream.

Do let me know if you would like to make use of this near term provision. If so, please create a Particle product for these devices and provide me with the device ID. I will work with my engineering team to enable public events for this Product.

Happy to answer any other questions or concerns that you have.

[ScruffR]

@danb0b

Requires paying for a “product”

Having your devices assigned to a product does not automatically mean you'd have to pay any more than you already do.

@danb0b

takes some setup that might be hard if, as in my case, you have already distributed the devices to users.

What kind of extra setup are you thinking of?
You can add devices to your product even after they were deployed as long they are update-able OTA

[danb0b]

I currently pay $0 for the free acct.

I don’t have the hardware ids or API keys of the devices I sent to users, nor thier individual usernames; with public messages that would have been avoided and only code would have been directly distributed. Now I have to retrieve that information from the users. I’m dealing with a userbase who are novices to particle world, so I will have to train and cajole to get the information I need to set up the product, times about ~90 users/devices