Have Electron get variable on startup

I’m trying to understand how to get a variable into an Electron or when it starts up.

I want to have a fleet of electrons with exactly the same firmware.
I’d like the electron to fetch a variable, say its name, when it first powers up, or when it is ready to send a notification. The variable would be assigned to the ID of the electron.

Maybe it signs in and sends it’s ID somewhere, and the data it gets returned is “Electron West”. The variable won’t change often, I’d go in and reassign it if I moved the unit somewhere new.

I’ll then use this when it sends me a notification, so I know where the info is coming from.
Is there a way to do this with an integration within the Console? or within the products area of the console?


I don’t think there is a really good way to “fetch” a variable from the Electron, but you could use the Pub/Sub system to accomplish what you want. You would need a server, or another Electron or Photon to act as the central repository for the data you want to fetch. The Electrons could publish events which would include the ID in the data, to which the server (an actual server or the Electron or Photon) would subscribe. That “server” would then publish the information you want to send, and the Electron that wants to get this information would have to subscribe to this published event.


Another potential avenue is to store your device name in EEPROM. The Photon and Electron have 2047 bytes of emulated EEPROM.

Strings are a bit of a challenge.

If you don’t want to re-flash the program to update the name, you can create a Particle.function() to update the name in EEPROM.

For the device name there already is a sample that illustrates how that’d be done


Why don’t you use the imei as identificator and have a databse with id and location? This way you don’t need to get a variable from the cloud, take the variable from the device.

Great! That’s quite helpful, I’m trying to avoid having a separate server running.

1 Like

Can you clarify the intent of your post? Your title implies that you want to know how to get a variable. Are you asking about variables in general, or are you only interested in getting the name of the device?

That could definitely be of use. Does the EEPROM get erased or rewritten when new firmware is flashed? I can use the device name method below for the name, but would also like to have some unique data for each device, a phone number or two, perhaps I can use the EEPROM and a function to update the data on individual devices.

Well, I suppose it’s a bit of both. The end goal is to have a fleet with identical firmware, though different units could send a notifications to different people, based on the unit name (or number).
The name would let the receiver of the notification know where it was coming from in simple language, and the number would change to get the notification to the person concerned with that particular unit.

I may have to put a server in place somewhere so that the individual units send a web hook, and the server receiving the web hook would then figure out where to send the notification.

This is for some agricultural sensors, to send an alert to someone when conditions change at the sensor. Currently the number of sensors is small, but it has potential to grow to 10’s or even 100’s of units, hence my desire to have identical firmware.

I was hoping to avoid having another piece of equipment running to do this (remote server).

What kind of notifications are you envisioning? On what device or type of device would the people be receiving this notification? The answer to that will affect how you accomplish your goal.

1 Like

EEPROM will survive (normal) firmware updates.
The most convenient way to store per device data in EEPROM might be via a dedicated Particle.function()

1 Like

I currently have the notifications working about the way I want, the Electron sends a web hook, which sends an SMS via a service called Tropo. I’d just like to make the whole thing a bit more flexible than what I’m doing currently, which is having the notification phone number and text coded individually into the electron.

As my fleet of electrons expands, I don’t want to recode each one for a new telephone number and unit name, thereby having to manage a whole bunch of separate files.

OK, that sounds like it will be very useful, can you point me to any examples of using Particle.function() to store data in the EEPROM? I haven’t come across that as of yet.

The Particle.function() doesn’t really store the data in the EEPROM, it’s just the way to get data from where you’re sending it, into your Electron. Once you have that data, you can store it in EEPROM. There are examples in the docs (here) on how to do that.

I don’t see any way you can avoid having a remote “server” if you want to send data to a fleet of Electrons when they startup. That server could just be a Photon; that would be the simplest, and cheapest option. It needs to be something that’s up and running all the time, if you don’t know when any of the Electrons might come on line. If you use a Photon as the server, then you would have to send the data via a Particle.publish() since you can’t call a Particle.function() from a Particle device. If you want to use a Particle.function() call to send the data, then you would have to use a “real” server to do that.

1 Like

I hate to ask the obvious but why can’t you just hard code the variable into your firmware?
I have done this with a few devices I have and I just have one firmware file
When I upload it to a device I change the name in the firmware and then it’s stored as hard coded in the unit?

Yeah it requires you to change it manually before your upload code, but for just a handful of units it sounds like a much easier solution. This would obviously not scale in a large environment but it sounds like you just have a few units deployed…
KISS method?

The reason not to hardcode is to avoid repetition - especially as later versions come to be. Currently there are just a couple, so no problem, but as it scales, I don’t want to modify every one as a minor version change is implemented, no two will be exactly the same. Even as it goes into a dozen or so units it’s cumbersome and every additional edit and flash increases the risk of errors creeping in.