I recently had a Boron fail (issue discussed elsewhere in this forum). It's demise resulted in the loss of my application for several days until a replacement could be sourced, programmed and installed.
To preclude the complete loss of our application if another similar failure occurs, I am going to add a second Boron that will operate in parallel with the first.
Part of the the redundancy will be the exchange of a periodic "keep alive" message from each Boron to the other. Should one of the Borons fail to receive a keep alive from the other within a specified time window, an email will be sent to one or more humans for investigation.
Here's my question: is there any way for a single firmware file to serve both Borons? Right now, the code I am preparing is identical for both Borons with one necessary exception: the keep alive message is different for each so that incoming keepalives don't create an infinite loop. Put another way, if both Borons were to send the exact same keepalive message, each is going to react to its own. Therefore, my code for one Boron contains the line "Particle.subscribe("KeepAlive_1", myHandler, MY_DEVICES);" while the code for the other has the line Particle.subscribe("KeepAlive_2", myHandler, MY_DEVICES)". Obviously, each file also has a corresponding Boron-speciifc Particle.publish command, e.g. "Particle.publish("KeepAlive_2", String(3), PRIVATE);"
Due to the overhead required to manage two separate, often-tweaked almost identical firmware files, I'd like to find an alternate way for each Boron to differentiate between an arriving keepalive from the other Boron and a keepalive message of its own, i.e. one that it sent.
Can anyone think of a means to achieve the objective?
Hi, what if the heartbeat would get incremented in the firmware continuously?
then the firmware would be the same and if it didn't get incremented, the device knows the peer didn't reply. Warning: I only dedicated one cpu to think about this.
Well, I'll need a couple more cycles than you to digest that Gustavo, but at first glance it surely looks quite promising.
1 Like
I have devoted several more cycles to the potential solution that you propose Gustavo but I cannot figure out how to make it work. However, I did discover that there is a way for firmware to retrieve a device's unique ID: "String myID = System.deviceID();"
So I'm thinking that there is must be a way in a single version of my firmware that will run on both Borons to indentify which inbound keepalive is from which device. If Boron #1 sees its own ID, it'll ignore it. If it sees Boron #2's ID, it'll process it appropriately. Does that sound logical?
Unfortunately, when I publish a keepalive using the following code, nothing appears in the event log (code compiled successfully). Can you figure out what I am missing?
// Routine to send a keepalive every minute:
if (lastKeepalive > 60000){
Particle.publish ("Well", myID); // Send ID to log
lastKeepalive = millis();
Sorry for misleading you, seems like with Publish/Subscribe you cannot do it without something unique like the deviceID. So keep going with that idea.
Your code should look more like this:
unsigned long now = millis();
if ((now - lastTime) >= 60000) {
lastTime = now;
Particle.publish ("Well", myID); // Send ID to log
}
Cheers,
I aready had this line in my file:
unsigned long lastKeepalive = millis();
Isn't that pretty much the same thing?
Note that my code is within the loop, so it executes repeatedly, i.e. it is not dependent on anything that preceeds it. Also, I have several other "Particle.publish" commands in the loop - invoked via a variety of conditions and funtions - and all of them appear in the even log when encountered.
Fixed! changed to: if (millis() - lastKeepalive > 60000){
Of course, I'll want to concatenate that lengthy string a bit. Maybe just the last 6 characters.
1 Like
