Have a xenon running 1.5.0 that is not responding to cloud functions, or variables. I can ping the device, and sometimes signal the device, but cannot get a Particle.function , .variable, or particle.publish to work…at times they don’t appear in the console but now I can get them to show up in the console, but they don’t respond. I’ve dug around the threads and tried using Particle.keepAlive(200) in the setup function, as well as calling Particle.connect() … any ideas?
here’s the code, just trying to do a simple test of the fuel gauge to test a solar powered xenon.
/*
* Project FuelGauge
* Description:
* Author:
* Date:
*/
SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
FuelGauge fuel;
int led = D7;
double BattV = 0;
double SoC = 0;
double battC = 0;
bool testbit = FALSE;
// setup() runs once, when the device is first turned on.
void setup() {
// Put initialization like pinMode and begin functions here.
Particle.function("batt", batteryStatus);
Particle.function("led",ledToggle);
Particle.variable("BattV", BattV);
Particle.variable("Soc", SoC);
pinMode(led, OUTPUT);
Particle.connect();
waitFor(Particle.connected, 1000);
Particle.keepAlive(200);
//Particle.publish("beamStatus","intact",60,PRIVATE);
}
// loop() runs over and over again, as quickly as it can execute.
void loop() {
// The core of your code will likely live here.
fuel.reset();
fuel.quickStart();
if(testbit == FALSE){
Particle.publish("commTest","intact",60,PRIVATE);
testbit = TRUE;
}
if (!Particle.connected()){
digitalWrite(led, HIGH);
Particle.connect();
waitFor(Particle.connected,2000);
digitalWrite(led, LOW);
}
}
// Lets you remotely check the battery status by calling the function "batt"
// Triggers a publish with the info (so subscribe or watch the dashboard)
// and also returns a '1' if there's >10% battery left and a '0' if below
int batteryStatus(String command){
// Publish the battery voltage and percentage of battery remaining
// if you want to be really efficient, just report one of these
// the String::format("%f.2") part gives us a string to publish,
// but with only 2 decimal points to save space
Particle.publish("B",
"v:" + String::format("%.2f",fuel.getVCell()) +
",c:" + String::format("%.2f",fuel.getSoC()),
60, PRIVATE
);
BattV = fuel.getVCell();
SoC = fuel.getSoC();
// if there's more than 10% of the battery left, then return 1
if(fuel.getSoC()>10){ return 1;}
// if you're running out of battery, return 0
else { return 0;}
}
int ledToggle(String command) {
/* Particle.functions always take a string as an argument and return an integer.
Since we can pass a string, it means that we can give the program commands on how the function should be used.
In this case, telling the function "on" will turn the LED on and telling it "off" will turn the LED off.
Then, the function returns a value to us to let us know what happened.
In this case, it will return 1 for the LEDs turning on, 0 for the LEDs turning off,
and -1 if we received a totally bogus command that didn't do anything to the LEDs.
*/
if (command=="on") {
digitalWrite(led,HIGH);
// digitalWrite(led2,HIGH);
return 1;
}
else if (command=="off") {
digitalWrite(led,LOW);
return 0;
}
else {
return -1;
}
}
@MikeG Welcome to the Particle Community.
Using a Xenon to connect to the Particle Cloud over the Mesh network to a Gateway device has always been problematic and you have no doubt noticed that Particle has discontinued the Xenon and Mesh networking.
The latest advice from Particle is to put the registration of Particle Functions and Variables at the end of setup() and after your connection to the Cloud to give the device time to do this. I would also leave the default SYSTEM_MODE(AUTOMATIC); and remove the Particle.connect to Particle.keepAlive. You can test for whether the Variables are registered before you leave setup() like this:
if (Particle.variable("BattV", BattV) == false)
{
// variable BattV not registered!
}
Thanks very much for your help…I changed back to SYSTEM_MODE(AUTOMATIC) and removed any of the Particle.connects and it works strangely enough…I only put those in after troubleshooting and reading a few threads…I think my issue went back to adding and removing devices to and from different mesh networks…they seem to act pretty screwy if you try to change any major aspect…
I am sadly aware of the discontinued Xenon and mesh networking…however I have a box of a dozen Xenons and 4 Borons here…and a bunch of solar panels and motion detectors and sensors galore just dying to be used…figured I better start joining these devices to the network before its too late! It’s unfortunate, because the Xenon hardware is a great little package for the small remote sensor networks I’ve been building in the past. I had a bunch of NRF24 radios running on bare bones Arduinos and AT Tinys to make up a Home security system that I JUST switched over to Xenons…what a mistake! I was hoping to get some use out of these Xenons still just using the BT radios to send small packets of local info… After wasting all day on this stupid issue I can see why they decided to pull the plug…
Best course of action with ‘stranded’ Xenons is to use the BLE 5 to communicate with an Argon or Boron in your case which is the gateway to the Particle Cloud. If you are interested try looking at BLE Group - it is a library written by a Particle solutions guy that implements the same as Mesh.publish() and Mesh.subscribe() using BLE (up to 3 peripheral devices) seems to work well - I have converted my Mesh devices to this.
1 Like
Thanks for the help, I will look into the BLE Group. I realized that the only reason the Xenon could not send cloud functions were because I was trying to use the FuelGauge…Xenon doesn’t have a FuelGauge…so everytime I’d try to issue a Particle.function() it’d fail…devil is in the details…
I have a simple mesh application using a Boron and 2 xenons running for at least a year now with no issues. The Xenon is a cool little piece of hardware, it blows my arduino /nrf24 radio and AT Tiny nrf24 radio devices out of the water as far as specs goes…and all the time it took me to build those lil cheap devices vs. what the Xenon offers out of the box…I was thinking if someone could just make a simple library exposing the BLE functions, you may still be able to use the Xenons…just want to get a use out of these things besides paper weights!
Any ideas or solutions on how to connect more than 3 nodes at a time? I’ve read a few previous threads on the topic. I have 6 or 7 devices I’d like to communicate with…most of them are sleeping until being woke by external interrupt (motion sensor, prox switches, etc.)
Also wondering if I can just keep using my mesh devices as is and stick with 1.5.x…my only fear is it breaking down in the future…
You could use BLE to scan for advertising devices and send the data in the advertising data packet if there isn’t much. Particle have been asked to consider increasing the 3 limit on the BLE Group. It is a memory issue. You are correct that the Xenon offers a lot for a reasonable price - I think it is a shame that it is being discontinued but it doesn’t fit with Particle’s strategy. Future support and issue - not a big risk for you if it is just your home automation?
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.