Anyone else not seeing events from their devices?

If you can whip up a test code that exhibits that issue and post it here we can check, otherwise (unless the logs give a clue) there are too many possible factors that you’d need to exclude as contributing factors before you could “prove” it’s not code related.


just seen you have :wink:

Good timing :smile:

If you have Chrome, you could use this to see the firehose

view-source:https://api.particle.io/v1/devices/events/?access_token=<your access token here>

You could also use a self-subscribe event handler to see if the device would see its own events

@ScruffR that doesn’t work for me unless I omit the view-source:

After omitting, I just get the request confirmation, but still no events:

Request

https://api.particle.io/v1/devices/events/?access_token=xxxxxxxxx

Response

:ok

I checked the public firehose (https://api.particle.io/v1/events/?access_token=xxxxxxxxx) to make sure it’s not just a communication problem on my end, and I do see the stream of public events.

To do the self subscribe test, I modified the test case sketch as follows:

unsigned old_time=0;

void handler(const char *event,const char *data) {
  Serial.print("Event: ");
  Serial.print(event);
  Serial.print(", Data: ");
  Serial.println(data);
}

void setup() {
  Serial.begin(115200);
  Serial.println("Begin");
  Particle.subscribe("test",handler);
}

void loop() {
  if(millis()-old_time > 2000) {
    Serial.println(Particle.publish("test","my-test-msg",60,PRIVATE));
    old_time = millis();
  }
}

This is the output I get:

Begin
1
1
1
1
1
Event: testDevice,1,3Phase,testMotor,Chicago,TCV,0.1.0, Data: 90,1.2,1.3,1.4,0.01,0.02
1
1
1
1
1
1
1
1
Event: testDevice,1,3Phase,testMotor,Chicago,TCV,0.1.0, Data: 90,1.2,1.3,1.4,0.01,0.02
1
1

(As before, this repeats infinitely as expected, one line every 2 secs).

That event is not mine. If you look at the public firehose (e.g. with particle subscribe test), you’ll see it every 16-17 s. So, my device picking up events from other people’s devices, just not any of mine.

Just to rule out any issues with public vs. private events, I tried listening only for events from my devices with:

Particle.subscribe("test",handler,MY_DEVICES);

The only effect this had was to exclude the testDevice events. I also tried making the event I’m publishing public by changing the Particle.publish() line as follows:

Particle.publish("test","my-test-msg")

This had no effect, no matter whether I was listening for events from all devices or my devices only.

Maybe using a less common event name than test would be an option to exclude other peoples events :wink:

Oh, sure!

But it actually serves a beneficial purpose here since it confirms that the device is operating and connected to the Particle Cloud.

Thanks for all your suggestions @ScruffR. I have to call it a night. I’ll check back tomorrow. Hopefully @jgoggins might find something informative in the logs.

I just got up an hour ago or so :wink:

I’ve tested your code - and as expected it works fine at my end.
So might be something up with your device or account or token.

How if you publish PUBLIC?

Great recon here guys, sounds like you’ve tried a number of things already, @kh90909 , a couple of questions for ya:

  1. Does this problem only occur when running on a Digistump Oak device?
  2. Could you try repeating your test case on a Photon?
  3. Could provide the exact test case code you are using so I can try to replicate it on my end (and potentially turn into an automated test)?
  4. Please PM me with particular device IDs that are exhibiting the problem.

Thanks!

-joe

1 Like

Thanks for helping out @jgoggins. Here are answers to your questions:

  1. I’ve only tried this with the Digistump Oak. Unfortunately, I don’t own any Spark/Particle devices yet. However, I have a hunch that if you unclaimed a Photon with known working code and sent me the deviceid to add to my account, the events for that device would stop getting through.

    I agree it could be some oddity in the Oak firmware, but seems unlikely since the exact same device running the exact same code worked fine before, and this happened once before, last month. I’ve seen one report on the Digistump forums that sounds similar. I’ve asked for further details and am waiting on a response.

  2. (See 1)

  3. See below

  4. PMing now.

Let me know if there’s any other testing I can do to help debug this issue. I know my way around the firmware reasonably well as I’ve contributed some fixes for the Oak. I can turn on debug messages and send the logs of the cloud interactions from the device side if that helps.

Test case 1

unsigned old_time=0;

void setup() {
  Serial.begin(115200);
  Serial.println("Begin");
}

void loop() {
  if(millis()-old_time > 2000) {
    Serial.println(Particle.publish("test","my-test-msg",60,PRIVATE));
    old_time = millis();
  }
}

Test case 2

unsigned old_time=0;

void handler(const char *event,const char *data) {
  Serial.print("Event: ");
  Serial.print(event);
  Serial.print(", Data: ");
  Serial.println(data);
}

void setup() {
  Serial.begin(115200);
  Serial.println("Begin");
  Particle.subscribe("test",handler);
}

void loop() {
  if(millis()-old_time > 2000) {
    Serial.println(Particle.publish("test","my-test-msg",60,PRIVATE));
    old_time = millis();
  }
}

As far as I can tell from the firmware sources (both Particle and Digistump), PUBLIC is the default if nothing is specified, but I tested it to be sure. Same result.

I’m working with @jgoggins to troubleshoot this problem, but if anyone else wants to try and replicate the issue on a Digistump Oak, here are instructions on how to reproduce the compiling and flashing process I have used.

I’m building the firmware using the Arduino IDE and flashing it via the Oak’s serial pins with a USB to serial adapter. This is the standard Digistump procedure for programming over serial. It involves putting the ESP8266 is serial bootloader mode and it uses esptool under the hood to flash the firmware.

I’ve tested with both the current 1.0.1 release of the Oak firmware, and the latest git. This issue occurs with both.

Here are detailed instructions:

  1. If you haven’t setup your Oak on your wifi network already, follow the instructions here to do so.
  2. Follow the instructions at this link to install Arduino 1.6.5, install the “Oak by Digistump” boards manager package, and select the “Oak by Digistump” board. Skip the remaining instructions as you’ll be uploading via serial rather than the Particle Cloud.
  3. Setup serial flashing according to the instructions here. I use the Anaconda Python distribution to provide the Python and PySerial dependencies.
  4. Compile and upload the desired code via the Arduino IDE. The code will run automatically after the upload is finished.

To use the latest git firmware instead of the 1.0.1 release, do the following after completing above steps 1-3.

  1. Clone https://github.com/digistump/OakCore.git
  2. Copy or symlink the repo in place of %APPDATA%\Arduino15\packages\digistump\hardware\oak\1.0.1
  3. Compile and upload as in step 4 above.

I think I set up my Oak the same as you described with the serial programming via a FT232 adapter to the Oak’s RX and TX pins.

At first the Oak was going on and off line very frequently, and I only got one event out of a whole lot of events that should have gone through. Now it seems the Oak won’t come online at all, according to the Particle dashboard at https://dashboard.particle.io, and thus I’m not getting any events.

Then I tried removing the serial programming jumper between P2 and GND before powering up the Oak and all the sudden it started working perfectly, publishing every 2 seconds using your most recent test case 2 example, above, unmodified! The Oak seems to have a lot of trouble accessing the Particle cloud reliably with the P2 jumper installed at boot. Once it’s running successfully you can do whatever you want with P2 and it’s fine. Once unhappy, removing the jumper doesn’t help until you power cycle the Oak, it would seem.

By any chance do you leave the P2 jumper in place while running your tests?

Rick

1 Like

I've tried it with and without, but I haven't encountered the issue you describe. It's convenient to keep the jumper in place and connect DTR on the FT232 to the RST pin. That way, the Oak gets automatically reset into bootloader mode when you upload a new sketch from the Arduino IDE. No need to connect the jumper and power cycle. And the sketch runs once the upload is complete. You just have to watch out for anything that might reset the Oak (e.g. the firmware update process), because it will go into bootloader mode on reset rather than booting into the firmware. (Alternatively, if your FT232 has CTS as well as DTR, connect as described here and you won't have this problem).

I have, however, experienced my Oaks going on and off line very frequently. I believe I've tracked this down to a bug in the firmware where the tcp transmit buffer can fill up soon after connecting to the cloud because the code doesn't give it enough time to send the packets. This results in the connection to the cloud being dropped, and this repeats over and over again. I've got a fix for the bug and I'll be working with Digistump to get it integrated into the official Oak firmware.

My fixes for this issue have now been added to the Oak firmware on GitHub by @digistump. They resolve this online-offline loop for me, but they do not resolve the original issue described in this thread.

Two more Oak users are now reporting this issue:

https://digistump.com/board/index.php/topic,2330.0.html

https://digistump.com/board/index.php/topic,2324.0.html

Hi,

I’m having the exact problem with one of my Oaks that kh is describing. It just started a few days ago. The Oak appears to still be running its code, but is not posting to the Particle Dashboard even though its status shows it coming online every ten minutes.

I’ve been checking my Oak every few days and today I rebooted it and it’s events started appearing on the Particle log again. I don’t know what fixed it, maybe there was a change on the Particle end? Have others had their problem resolved as well?

Hi @ajablu. Yes, events from my Oak have started appearing again too. I’ve been away on vacation for the past two weeks, so I can’t pinpoint the exact time it happened, but when I powered on my Oak this evening, events started coming through right away.

The same thing happened when I first had this problem in April. The events just suddenly started working again with no change on my part.