Argon and mesh breathing cyan, but can't ping them or signal

Troubleshooting
1

They look like they’re all connected, but can’t ping them or signal them. Just about ready to give up for a while. All week tinkering with these things and nothing really useful yet. The console says they keep disconnecting. The firmware is the latest 0.8.0-rc.26

2

I’ve had similar issues but it seems to have improved.

One thing I’ve noticed in the past few days is that I stop getting the console events periodically, and often, it seems to only get resolved with a log out and back in to the console. It seems much more frequent with the mesh devices than the gen 2 devices, and is very frustrating, especially when I also see my devices go unresponsive and reboot themselves frequently, it’s hard for me to know which issue I am having at any moment. It is much worse in Safari than it is in Chrome, I’m using a Mac with latest OS…

So what I’m getting at is sometimes when I think I can’t ping them, the device is fine but I’ve lost the ability to receive the ping, other times the device has gone unresponsive, and I’ll typically, but not always see it restart shortly after

3

I just finished flashing the new firmware using cli, so we'll see if they've gotten better. I had done it by way of the Web IDE earlier today, so I went back and redid it by way of the CLI..Don't know if that makes it any better, but we'll see.
thanks

1 Like
4

I think when you do it via IDE it doesn’t give you one part of the process that flashing the hybrid .bin gives you. Fingers crossed. Might have done this myself with a couple of devices, I’ve sort of lost track. When I get back to them next week I may have to reflash them all to be sure.

5

Yeah I don’t get this back and forth stuff. Use the IDE for this and the CLI for that. doesn’t make sense. ONE SOFTWARE TO RULE THEM ALL!!!

1 Like
6

I also have problems with losing the ability to flash or signal my devices. The mobile app also starts to return errors when I view particle.variable values. It seems to fail sometime after 8+ hours of being left to it’s own devices.

What I’ve found so far:
I’ve got an argon gateway and 2 xenon ‘slaves’ connecting through it.
After 8+ hours, I have to reboot my argon (power cycle). The slave xenons then flash green while they reconnect, and then I can signal and flash them after that - with no need to reboot the xenons, so the problem appears to be the gateway.
Another random data point, I’m using the mesh.subscribe and mesh.publish to communicate between the two xeonons, and that continues to work even when in this funky state where I can’t signal them.

7

@PatrickWilkinson, have you applied the latest rc26 to all your devices?

8

Yes, that was with rc26 on all 3 devices. One other interesting point is that I can still signal the Argon when it gets in this funky state (just tried this morning). This implies the Argon is connected to the internet just fine, and since I can communicate between my xenons, the mesh network is fine which would conclude me to think the problem appears to be with routing packets between the mesh network and the internet. I’m curious if the gateways are sensitive to the code running on them. On this particular Argon, I’ve got one of the samples running that continuously reads the light sensor from the Loop() function with no calls to Delay(). Seems like it should be a benign amount of work, but I have no idea how robust the MeshOS is to giving other processes the time they need. One of the particle reps sent me a link to debug firmware that I’m going to be trying out to get some more information.

2 Likes
9

Are you using SYSTEM_THREAD(ENABLED)?
Are you dropping out of loop() or running in a tight loop inside loop()?
What sensor? Depending on the way the communication with the sensor works it might not be as benign as one might think - some communication can be time consuming even if it's only a single library function call. Also some sensors don't take it well when they are polled more frequently than they'd be able to acquire their internal readings.

10

The code on the Argon is trivial:

void loop() {
// check to see what the value of the photoresistor is and store it in the int variable analogvalue
analogvalue = analogRead(photoresistor);
}

I’m not calling SYSTEM_THREAD in anyway. Is this something I need to do?

Clearly my Argon is only reading one of it’s analog inputs continuously, however one of the 2 xenons is reading the grove temperature sensor, and I have lowered it’s delay to 100 vs the 1000 in the demo. Not sure if that’s relevant or not to the Argon ultimately failing. The temperature sensor libraries look like they just return early if you call them more than once per 2 seconds, so it doesn’t seem like much of a problem. I’ve got a debug firmware running for tonight on my Argon, with it’s output being captured, so it will be interesting to see if it exhibits the same problem tomorrow morning.

11

No need, but worth a try to see whether that helps with the inavailability of the serial interface.

It wouldn't solve the issue with your connection tho'

If this is the DHT11 sensor then it's not recommended to read it more frequently than once per second, with a DHT22 that would be once every two seconds.
That's also what the DHT11 datasheet says

Hence adverse effects are to be expected if you still do.

I'd do away with blocking delay() completely and go with something like this

void loop() {
  static uint32_t lastAction = 0;
  if (millis() - lastAction < 1000) return;  // bail out when not completed one second since last action
  lastAction = millis();
  // take whatever action needs to be taken once per second
}
3 Likes
12

Will do, thanks!