Particle.subscribe unique device ID not returning correct values

I’m using the following command and the values returned are not correct when using the device ID :

Particle.subscribe(“Humidity”, myHandler1, “2d002…xx…3230”);

The values returned are somewhat random integers. Examples:

Soil Humidity1:29.00

Soil Humidity1:50.00

Soil Humidity1:50.00

While using:

Particle.subscribe(“Humidity”, myHandler1, MY_DEVICES);

does return the correct value from the unique device (my only device with the event “Humidity”):

Soil Humidity1:55.82

Is my use in the 1st example correct or am I missing a parameter?


Seems ok… though you might want to post the handler code so that we can see what’s going on

Here is the relevant code. As I mentioned previously, when I use the MY_DEVICES parameter vs the device ID, the data is correct. When using MY_DEVICES, I need to have unique output variables for each subscription (which I am tying to avoid). I want to subscribe to the Humidity variable in a per device, per handler basis.

#include "stdlib.h"
#include "TimeAlarms/TimeAlarms.h"
#include "elapsedMillis/elapsedMillis.h"

//  Define names for the Digital pins On the Photon D0, D1
//  These data pins link to Relay board pins IN1, IN2

#define RELAY1  D0                        
#define RELAY2  D1                       

//Set the timer for the void loop function
elapsedMillis timeElapsed; //declare global if you don't want it reset every time loop runs
unsigned int interval = 3600000; //This is the delay in ms. 3,600,000=1hr

// Declare the variables
float totalPrecip;
float totalPrecipMin = 5.08; //Values are reported in mm, 5.08 is .2in.
float soil_humidity = 80; //This is the soil moisture minimum
int relay_duration = 420000;  //Duration in ms.  420,000=7mins
float humidity_a1 = 100; //Initially sets humidity at 100% so relays do not switch on when no value exists for humidity
float humidity_a2 = 100;

//Define the Handlers
void myHandler1(const char *event, const char *data)
humidity_a1 = atof (data);

void myHandler2(const char *event, const char *data)
humidity_a2 = atof (data);

void setup()
  // create the alarms 
  Alarm.alarmRepeat(5,30,0, MorningAlarm);  // 5:30am every day

  // Listen for the hook response
  Particle.subscribe("hook-response/CLD_precipitation", gotWeatherData, MY_DEVICES);

// Initialize the Photon data pins for OUTPUT
  pinMode(RELAY1, OUTPUT);       
  pinMode(RELAY2, OUTPUT);

  Particle.subscribe("Humidity", myHandler1, "123456789ABCDEF");
  Particle.subscribe("Humidity", myHandler2, "ABCDEF123456789");

  digitalWrite(RELAY1,HIGH);          // Turns Relay Off
  digitalWrite(RELAY2,HIGH);          // Turns Relay Off
void loop(){
  if (timeElapsed > interval)
  Serial.print("Soil Humidity1:");
  Serial.print("Soil Humidity2:");
  Serial.println("Requesting Precipitation!");
  timeElapsed = 0;

When using the CLI: particle subscribe Humidity 123456789ABCDEF ,the correct data is returned as well.

Any help is appreciated. Thanks!

Just to try… can you use 2 unique event name like:

Particle.subscribe("Humidity1", myHandler1, "123456789ABCDEF");
Particle.subscribe("Humidity2", myHandler2, "ABCDEF123456789");

and see if the problem persists?

Does not work, although, the below works.

Particle.subscribe("Humidity1", myHandler1, MY_DEVICES);
Particle.subscribe("Humidity2", myHandler2, MY_DEVICES);

I am performing a copy/paste on the ID numbers, so there are not typos and when I run it in the CLI (particle subscribe Humidity 123456789ABCDEF), the correct values are returned. I guess a workaround is that I'll manage variables in my code and mini deployment, but I believe that is going to make overall device management much more difficult.

I think we should ping @Dave here and see if the deviceID subscribe endpoint is working in the cloud yet. I seem to recall this was delayed before and I don’t know the state now.


Could you also show the Particle.publish() commands the should trigger the subscriptions?
There is a still open issue

Here are the publish commands:

Particle.publish(“Humidity1”, String(humidity), 60, PRIVATE);

Particle.publish(“Humidity2”, String(humidity), 60, PRIVATE);

These are issued from two different devices (not two sensors on one Particle device), right?

As mentioned in the linked issue and in more detail in the closed issue #371 you could try to publish publicly (just to test) - it used to work (counter-intuitively) that way with 0.4.5 and I guess it hasn’t really changed since.
Hopefully it will be with 0.4.9 (0.4.8 seems to only be internal/develop).

Yes. Two different particle devices. I’ll try to publish publicly and I’ll let you know if that works. Thanks!

It appears to work when published publicly. Thanks!

Yup, as I thought - still no change :weary:, but we can still hope for 0.4.9+ :wink:

Get or get not, there is no hope.

The issue is milestoned for 0.4.9 (since 0.4.8 will not go public :wink: )


So just to clarify that I understand this issue correctly; if I want to Particle.subscribe() to a unique device_id, I want to Particle.publish() that event as PUBLIC instead of PRIVATE ?

Thank you!

EDIT: Also, if I Particle.publish(“myvar”, myDat, PUBLIC) and subscribe to “myvar” on the same Photon, will I essentially be creating a recursive event, or will it ignore publish events coming from itself?

Basically, I have 2 photons that will be publishing a touch event with color data and subscribing to each others event - should I just use 2 seperate, unique “myvar” with different names or will the Photon ignore publish’s from it self?

This behaviour that you have to publish publicly to subsribe to a device ID is not intended and should get corrected.

About a possible “recursion”: If you intend to publish from a subscribe handler you should add some info about the origin to either even or data and check in the handler to prevent this situation.