I am running @ninjatill 's marco polo mesh test on an argon + 3 xenon that I just received.
My xenon’s eventually always go from breathing cyan to fast flashing green and then stay that way.
EDIT: WORKAROUND FOUND
In my case and others with various routers not just xfiniity and not just with ip6 enabled…
It has been found that argon’s attached to several different brands of router fail to keep the mesh connected to the cloud.
The fast flashing green means that xenon node can not communicate with particle cloud. They are still connected to the mesh and executing code so you can pass data such as the Marco Polo heartbeat to an argon gateway but these mesh nodes can’t pass data directly to the cloud and can’t be flashed with updates until you reset the gateway and try flashing during the brief cycle that the mesh xenon node starts breathing cyan.
If your mesh nodes regularly start fast flashing green after breathing cyan (or just always fast flash green) then try a different router (until particle finds a cure for the argon router allergy ).
Yes, all 5 of my Xenons stay flashing green 24/7. It means that the Xenon nodes do not have access to the Particle cloud so you can’t use any of the cloud functions directly from them and this is not right.
I have a Argon as my main unit and it stays connected and breathing cyan just fine. The Argon requires a manual reset when the WiFi is lost and them comes back on. The Argon will reconnect and breathe cyan but it will not publish any data until it’s reset.
They do not work as they should at this point in time.
On both of my mesh Networks, my devices rarely go to blinking green. They only go to blinking green when I reboot the Gateway. However, they do go to fast blinking cyan a lot. They fast blink cyan when the Gateway is reset, an individual endpoint is reset, cloud is lost, Etc. Sometimes they come back to breathing cyan sometimes they don’t.
Ok, I thought anything but breathing cyan was bad.
I don’t know what fast flashing green is but all of my xenon’s do it within a minute of breathing cyan and they can still pass info to the argon gateway and the gateway still has connectivity to particle.io. (I do know I can’t PROGRAM FLASH once they fast flashing green - so for (re)programming I have some work and learning to do still).
So what is fast flashing green?
(I know medium flashing green - that’s what xenon does when it starts up and it is looking for the mesh gateway).
By the way, I find that my 3 xenon’s connect and send / respond to the gateway within 1 second.
I saw reports elsewhere that they took a long time - not for me.
I also thought the mesh distance and reliability was poor because I though that fast flashing green and not breathing cyan meant they were disconnected. It does not. They are still connected to the Argon gateway and after reset they are again flashing green immediately and (which this morning I though meant BAD but it doesn’t) and sending responding in less than 1 second (maybe much less than a second - I’m not there yet).
I get mesh distances approximately the same as wifi - without any extra antenneas on the xenon or mesh side of gateway - just stock.
So I can get almost from the bottom east-most corner of a 3 story, 4500 sq ft house to the upper west-most room through 2 floors including tile, a couple drywall walls. I didn’t multi-day test it yet but my early impression is much better distance. I got 30 feet line of sight and ran out of room.
I bet outdoor line of site we should get 100 feet or more - at least. (I know, except noise and what not).
Maybe everyone else, like I was, is assuming that if you aren’t breathing cyan things are bad.
So what is with fast flashing green and why do all my xenon’s end up there in a minute - instead of breathing cyan?
@rickkas7 can probably explain the details better… but according to the docs, fast blinking green is “Looking for the Internet”. There is only one mention of mesh network status in any of the device modes and that is in the breathing green mode where it states: “When your Xenon is connected to mesh but not to the cloud, it will be breathing green.” From some of the other status modes, you can infer mesh status. Obviously, connected to cloud infers that mesh is up and ready. The only 3 modes I have really seen after setup was complete is breathing cyan (all is well), blinking cyan (happens a lot on endpoints when gateway is reset) and blinking green (when gateway is in a reboot or powered down).
I just tried moving an endpoint in my house to another floor. At first I get blinking green for a about 30 seconds. Then blinking cyan with intermittent single red or orange blinks. I waited a bit but it didn’t breath cyan. Eventually I disconnected it and moved it again so I know is was directly above the gateway (on the lower floor). Then the endpoint breathed cyan very quickly. Then I moved it back to the original upper floor location (my bed stand) and it went quickly to breathing cyan. I’m learning that the status LED is not a good indicator of mesh status but rather, like the Gen 2 devices, it is a status of cloud connectivity. Still, endpoint re-connections seem finicky… both when the endpoint is reset or the gateway.
Flashing green is bad, they should all also be breathing cyan like the Argon is but they are not working like they should.
The Xenons are supposed to have access to the Particle cloud so you can have them Particle publish and do other cloud based features without having to rely on the Argon code to do this work.
The Xenons are communicating via the local Mesh network and this is why they still have access to the Argon which does have Particle cloud access which allows you to get data out to the web. Your supposed to be able to have cloud functions available directly from the Xenons when the Argon or Boron is in a breathing cyan state which means they have Particle cloud access.
So even though you have Mesh communication working , if you keep an eye on it you will see they come and go back online randomly and sometimes do not comeback online without a manual reset. Sometimes I see them doing the Red SOS crash flashing and then they recover back to flashing green.
If you cut the Argon WiFi Access on my unit and then give it WiFi access again the Argon will start breathing Cyan again but it will not publish anything to the Particle cloud unless you manually reset it.
You can chime in on this thread with you testing feedback. We are all going to provide real world experience feedback and work together to push this all forward to something more stable.
Yep. The one at my office stopped publishing events at about 19:17 EST tonight. I won't be able to reset it until I get to the office tomorrow. Interesting to note: I added a reset to my Marco-Polo code when the cloud connection is down for 10 minutes. Since it isn't back online, I can only assume that the Particle.connect() returns true and it never resets... I guess it thinks it has a cloud connection but it won't publish.
And when I got to my office this morning, the Xenon gateway was breathing cyan but still no publishes since 19:17 last night (13 hours without a publish). I pressed reset on the gateway and it came back to life immediately, went to breathing cyan quickly, and began publishing like it should be.
Both endpoints were fast blinking cyan during the outage. After the gateway reset, both endpoints went to breathing cyan fairly quickly and there were “online” events posted for each endpoint. I’m now getting all the console events like I should and Losant is showing the data points.
From the above mentioned discussion, X1 is the only device now running in threaded mode and this has no bearing on the following.
I did some more testing last night with a heartbeat signal originating on X3 endpoint and counted on X1 endpoint, setup is roughly linear as follows. X=Xenon, A=Argon, X1 cannot hear X3 inferred because removing X2, X3 never connects to the mesh, constantly flashing rapid green with intermittent yellow/orange/red. Put X2 back and X3 immedately breaths cyan.
X1-----15ft----A-----20ft-----X2-----15ft-----X3
Heartbeat (X3) is once a second using mesh.publish which includes a count as data and flashing the blue LED. X1 counts the number of received publishes and displays this and the count from the published data on the OLED display.
Started running with all units breathing cyan last night around 9pm. At 5am this morning the display is no longer counting, all units are breathing cyan but X3 is no longer sending publishes but worse than that it is no longer running the application code as the blue led is no longer flashing. Code is Tinker with a 1 second millis() counter to publish and flash the LED. X1 is running the OLED example with the extra counter code, everything else is running Tinker.
This morning the display on X1 was still counting seconds but heartbeat counts had stopped. Seconds counter read 33115, a bit more than 9 hours, Heartbeat count was 25185 and heartbeat data was 25322. The discrepancy shows some hearbeat publishes were missed but the heartbeat data shows X3 stopped sending heartbeats after 7hrs and 2 minutes.
As a second weirdness last night, when I went to OTA flash X3 I kept getting failed to flash from the web IDE. I moved X3 to within a foot or so of the Argon and still nothing after 5 tries, no response from X3. I opened the phone app to try tinker, it said it was on line but no response from trying to use tinker, could not set any pin to read or write. I thought maybe I don't have the right device. Opened the console and X3 is online, since it's running the latest firmware I tried running diagnostics which came back success. Then I signaled the device, X3 responded and the console immediately showed device came online, strange since it didn't go offline and passed diagnostics. Right after this OTA flashing was successful. This behaviour may be related to X3 no longer running the application code this morning but still showing as being online. Just tried now and it is also not responding to tinker. Tried diagnostics and it is passing as well. I'll have to try the signalling option when I get home tonight so I can observe what is happening and see if that magically makes it start sending heartbeats again. I'll report the results tonight.
The heartbeat code is as follows, simply added to tinker. I don't think I've done anything to cause it to stop running after 7hrs. only added variables and a few lines to loop()
unsigned long heartbeatTimer = millis();
uint32_t heartbeatCounter = 0;
bool ledState = FALSE;
/* Function prototypes -------------------------------------------------------*/
int tinkerDigitalRead(String pin);
int tinkerDigitalWrite(String command);
int tinkerAnalogRead(String pin);
int tinkerAnalogWrite(String command);
/* This function is called once at start up ----------------------------------*/
void setup()
{
//Setup the Tinker application here
//Register all the Tinker functions
Particle.function("digitalread", tinkerDigitalRead);
Particle.function("digitalwrite", tinkerDigitalWrite);
Particle.function("analogread", tinkerAnalogRead);
Particle.function("analogwrite", tinkerAnalogWrite);
pinMode(D7, OUTPUT);
}
/* This function loops forever --------------------------------------------*/
void loop()
{
if (millis() - heartbeatTimer >= 1000) {
ledState = !ledState;
digitalWrite(D7, ledState);
heartbeatCounter++;
Mesh.publish("BunnyHop", String(heartbeatCounter));
heartbeatTimer = millis();
}
//This will run in a loop
}
/*******************************************************************************
* Function Name : tinkerDigitalRead
* Description : Reads the digital value of a given pin
* Input : Pin
* Output : None.
* Return : Value of the pin (0 or 1) in INT type
Returns a negative number on failure
*******************************************************************************/
int tinkerDigitalRead(String pin)
{
//convert ascii to integer
int pinNumber = pin.charAt(1) - '0';
//Sanity check to see if the pin numbers are within limits
if (pinNumber< 0 || pinNumber >7) return -1;
if(pin.startsWith("D"))
{
pinMode(pinNumber, INPUT_PULLDOWN);
return digitalRead(pinNumber);
}
else if (pin.startsWith("A"))
{
pinMode(pinNumber+10, INPUT_PULLDOWN);
return digitalRead(pinNumber+10);
}
return -2;
}
/*******************************************************************************
* Function Name : tinkerDigitalWrite
* Description : Sets the specified pin HIGH or LOW
* Input : Pin and value
* Output : None.
* Return : 1 on success and a negative number on failure
*******************************************************************************/
int tinkerDigitalWrite(String command)
{
bool value = 0;
//convert ascii to integer
int pinNumber = command.charAt(1) - '0';
//Sanity check to see if the pin numbers are within limits
if (pinNumber< 0 || pinNumber >7) return -1;
if(command.substring(3,7) == "HIGH") value = 1;
else if(command.substring(3,6) == "LOW") value = 0;
else return -2;
if(command.startsWith("D"))
{
pinMode(pinNumber, OUTPUT);
digitalWrite(pinNumber, value);
return 1;
}
else if(command.startsWith("A"))
{
pinMode(pinNumber+10, OUTPUT);
digitalWrite(pinNumber+10, value);
return 1;
}
else return -3;
}
/*******************************************************************************
* Function Name : tinkerAnalogRead
* Description : Reads the analog value of a pin
* Input : Pin
* Output : None.
* Return : Returns the analog value in INT type (0 to 4095)
Returns a negative number on failure
*******************************************************************************/
int tinkerAnalogRead(String pin)
{
//convert ascii to integer
int pinNumber = pin.charAt(1) - '0';
//Sanity check to see if the pin numbers are within limits
if (pinNumber< 0 || pinNumber >7) return -1;
if(pin.startsWith("D"))
{
return -3;
}
else if (pin.startsWith("A"))
{
return analogRead(pinNumber+10);
}
return -2;
}
/*******************************************************************************
* Function Name : tinkerAnalogWrite
* Description : Writes an analog value (PWM) to the specified pin
* Input : Pin and Value (0 to 255)
* Output : None.
* Return : 1 on success and a negative number on failure
*******************************************************************************/
int tinkerAnalogWrite(String command)
{
//convert ascii to integer
int pinNumber = command.charAt(1) - '0';
//Sanity check to see if the pin numbers are within limits
if (pinNumber< 0 || pinNumber >7) return -1;
String value = command.substring(3);
if(command.startsWith("D"))
{
pinMode(pinNumber, OUTPUT);
analogWrite(pinNumber, value.toInt());
return 1;
}
else if(command.startsWith("A"))
{
pinMode(pinNumber+10, OUTPUT);
analogWrite(pinNumber+10, value.toInt());
return 1;
}
else return -2;
}
@Jseiler, Argon as a gateway has always given me issues. Your application is really testing two things - mesh and cloud connectivity. Cloud connectivity is setup by the Tinker Particle.function() calls and the fact that you are running defacto SYSTEM_MODE(AUTOMATIC).
One thing you can do is to NOT use String in your Mesh.publish() and instead use a char array string and snprintf():
Thank you @peekay123 for the advice and the example.
I didn’t think the cloud connectivity was an issue as the mesh should continue to work and certainly not stop the application code. Since the device (Xenon) is breathing cyan I’m thinking it’s not blocking the application code by trying to connect to the cloud in non-threaded mode. The blue LED should continue to flash. Do you think something is blocking the application code or it is crashed in some way? Breathing seems to indicate it is running something in an orderly fashion and not totally running amok.
I have to admit, I’ve been playing with particle devices and programming for 3 or four years now and I still haven’t wrapped my head around char arrays and pointers. They seem like simple concepts but somehow I always end up messing them up.
If I may ask, I’ve seen the aversion to strings in many places, is it because it’s code intensive or clock cycle intensive or fraught with other hidden dangers?
I’ll make the changes tonight and see if that makes a difference.
@Jseiler, Arduino Strings use dynamic memory allocation. The memory is allocated from a memory "heap". As Strings get created and destroyed, they can leave fragments of free memory in the heap. C++ doesn't "clean-up" these fragments. When memory is allocated, the allocator looks for a contiguous block of heap memory of the size requested. With the heap fragmented into lots of small free pieces, the allocator will eventually fail and the application will most likely fail with it.
@peekay123 thank you for the concise explanation. That makes total sense to me and gives me a reason to apply myself a bit more to learning and applying other methods.
I am now having my first experience with a Xenon in fast blinking green. I put a Xenon endpoint one floor down in my office/warehouse. It is sitting in a room below my office which is about a distance of about 25 feet (~8 meters) but going through a 4" concrete floor with steel trusses and a drop ceiling (not to mention all the other stuff sitting around in my office. At first, it took about 30 minutes to connect to the mesh then it started breathing cyan and responding to heartbeats without any intervention… just had to be patient. Randomly, it stopped responding and when I go check on it, it had fast blinking green. I hit reset and it went to breathing cyan fairly quickly and was again responding to heartbeats. Then 15-17 minutes later, it stops responding again and sitting with fast blinking green. While it is responding, it has fairly good latency (<80ms) but fails to report intermittently. It seems that this issue might arise when an endpoint is on the fringe of the mesh network and may be subject to lost packets. I have a few external antennas (3 different models) on order but I won’t be able to test those until next week.
I think I’m going to put some serial debugging statements into my MarcoPolo code for the endpoint and hook it up to a laptop with serial monitor to see what’s going on.
It appears patience is key during this debugging process.
I have had the flashing green as well except I didn’t push reset. It takes a few minutes, sometimes 10, 15, 20, or as @ninjatill said, 30 but it eventually, after flashing the intermittent yellow/orange/red, goes back to breathing cyan.
I have not seen breathing green yet, Has anyone else? Is that supposed to be particle.disconnect() with the mesh active?
For what I’m describing, patience isn’t working any more. In the screen cap, I have 2 places (circled in blue) where I reset the endpoint to get it back to breathing cyan. After a few minutes it drops to fast blinking green again. On this latest drop, it has been down for almost 2 hours:
Which indicates an OS lockup or that the loop() isn’t being processed. But the endpoint code is so simple. I don’t see how that’s happening. If anything should be locking up, it’s the gateway… which I though I might have too much processing going on in the subscribe callback function.
Here’s hoping for an RC26 release sooner than later!
