Communication between two photons

Hello,
Please forgive me if I have raised a repeated topic. I understand from example and tutorial that particle cores can communicate using publish and subscribe. I tested the publish function and found that it works with string. If I want to send an integer variable from photon A and retrieve the variable i integer in photon B, is it possible?
Can the syntax below work:

Photon A
Particle.publish(“Temperature”, analogue);
Where analogue is an integer variable in Photon A firmware

Photon B
Particle.Subscribe(“Temperature”, analogue);
Where analogue is an integer variable in Photon B firmware

How to publish private and public event?
If Temperature is a public event, I would think that many people has used the event name.

Thanks for pointing me to the right direction.

@leechuching, the quick answer is no, you can’t send the “raw” integer value. You can, however, convert it to a string, publish it to the other Photon which then takes the string and converts it back to an integer. There are plenty of examples for using sprintf() to print to a char array (like a String but better with RAM) and atoi() to convert back to an integer. :smile:

Thanks peekay. That’s work.

One more question. For sending a variable of boolean type from one photon to another, the data will also be send as string. I can use atoi in the receiving photon to convert string back to integer, is there any similar function to convert string to boolean?

Regards
Will

In C (and most other languages) booleans are not really that different to numeric values with 0 indicating false and any non-zero value being interpreted as true.
So you’d just send your boolean as number (which is the standard way to translate bools) and then you can just use atoi() to convert back.

Have you ever tried to print a boolean like this?

  boolean b = true;
  Serial.println(b);

You can also write this

  int x = 1;
  int y = true;
  if(x || y) { ... }

Thanks. I have not programmed in C++ for more than 20 years. Take a while to refresh. I am a PLC and SCADA engineer and used to ladder, function block and sequential flow chart type of programming.

I have a project that uses this for the publish photon.

  Particle.publish("TempCpub : ", String (bmeTemperature), 60, PRIVATE);

And the subscribe photon

bool gotHumidity = false; // a global semaphore to set true when you get a new temperature value from master Particle.subscribe() function

int gotMessage;


  Particle.variable("HumidPub", &hum, DOUBLE);
  Particle.subscribe("HumidPub", myHandler, MY_DEVICES);


void myHandler(const char *event, const char *data)
{
    hum = atof(data);  // convert the incoming string literal to float and put the value in the global variable
    gotMessage = true; // a global semaphore to set true when you get a new temperature value from master Particle.subscribe() function
    Particle.publish("GotHum", String(hum));

}

Hi Peekay,

There is a limit to the number of events per photon something like not more than 4. If we have more than 4 events, what is the best way to handle it i.e.

  1. Pack in a big string and decode at the other end.
  2. Is there a function that can convert an array into string and another function that convert string back to array?
  3. Us thing speaks or google cloud.

What is the most efficient way?

Regards

The limit is a limit over time.
Which is 1 publish per second with a burst of 4 (requiring a 4sec “cool-down” phase).
If you keep your publish rate below 1/sec on average you’ll be allowed to publish as many events as you like.

If you need more than 1/s, can you elaborate what for? What kind of data is that?

1 Like

Hi ScruffR, can you elaborate on 1 publish per second with a burst of 4?
In example below:
Particle.publish(“M40001_S”, String(M40001));
delay(100);
Particle.publish(“M40002_S”, String(M40002));
delay(100);
Particle.publish(“M40003_S”, String(M40003));
delay(100);
Particle.publish(“M40004_S”, String(M40004));
delay(100);
I am publishing 4 events within 400ms. What is the limitation for publishing 5 or more events?
I tried to get two PLCs communicate to each other via two photons. Each PLC is paired with a photon. The PLC is a Modbus slave and the Photon is a Modbus master which polled the PLC through a RS485 transceiver. The Modbus part is tested and work well. I would like to know the limitation of the Photons and how to configure them to work correctly under this circumstances.

Someone else might have a better way, YMMV.

If you have 4 events to publish, make a new function IE:

void ppub(){

    Particle.publish("ONEpub : ", String (bmeTemperature), 60, PRIVATE);
    Particle.publish("TWOpub : ", String (bmeTemperature), 60, PRIVATE);
    Particle.publish("THREEpub : ", String (bmeTemperature), 60, PRIVATE);
    Particle.publish("FOURpub : ", String (bmeTemperature), 60, PRIVATE);
    delay(5000);


}

then call that function in your loop.

void loop(){

  ppub();

}

That should publish all 4 variables at once every 5 seconds.

Yup, @Cloud’s example shows what’s possible. You could even decrease the delay to delay(4000) which would be the 4sec “cool-down” and then you can shoot another burst of four.
Or you just do one per second.

Hi Guys, Thanks for your explanation. Now I can publish an event every seconds.
My next question is any limitation to subscribe? Am I only can subscribe up to 4 events and need 4 seconds cool down time or I can do the same as publish. e.g. subscribe an event every second?

Hey! I worked with PLCs a long time ago too. I find that the way your firmware runs on a Particle is pretty similar conceptually to the way the PLC’s programs run!
have fun!
Gustavo.

In control system engineering, we use RTU (Remote Telemetry Unit) for wide area data communication. The medium is usually radio or 3G mobile. We do have to limit data transmission to not overload the communication network and remote telemetry is done via DNP3 protocol. I am investigating whether the cloud technology can be potentially used.

You can subscribe to up to four “event types”.
The fist parameter in Particle.subscribe() is a prefix filter. So as long all your events start with one of up to four prefixes, you can receive as many events (starting with one of these) with speed only limited by the connection - but I’d go for max. 1 event per milli second (do to the FreeRTOS time slices).

Not enough?

For publishing, you only need 4 sec “cool-down” after a publish burst. If you keep steadily publishing once every second, you won’t “overheat”.

Hi ScruffR,

I didn’t get your meaning your events start with one of up to four prefixes. I tried the following:

Particle.subscribe(“M40001_S”, ReadAnalog1);
delay(1000);
Particle.subscribe(“M40002_S”, ReadAnalog2);
delay(1000);
Particle.subscribe(“M40003_S”, ReadAnalog3);
delay(1000);
Particle.subscribe(“M40004_S”, ReadAnalog4);
delay(1000);
Particle.subscribe(“M40005_S”, ReadAnalog5);
delay(1000);
Particle.subscribe(“M40006_S”, ReadAnalog6);
delay(1000);

Found that the last two subscribes are not working i.e. always read 0. The first four subscribes are good.

Let me know if that is what shall be.

You’re not subscribing to prefixes, you’re subscribing to the full name of the event. What happens if you just do one subscribe with the common prefix of all your events ( “M4000”)?

Particle.subscribe("M4000", readAnalog);

void readAnalog(const char *event, const char *data) {
    String eventName = String(event);
    if (eventName.endsWith("1_S")) {
        // do stuff appropriate for that event
    }else if (eventName.endsWith("2_S")) {
        // do stuff appropriate for that event
    } etc...
1 Like

Hi Ric,

Thanks it work now.

That’s what I meant with pre (before) fix (unaltered/the same for all) which can be followed by interchangeable endings :wink:

BTW, there is no need for delays before/after Particle.subscribe()
And Particle.subcribe() for a given event filter should only be called once.

1 Like