Not sure if this is the ideal place to put this. Hopefully someone from Particle will see it!
Simply, I’d like to be able to reboot a device from the Console. Occasionally we have a device in the field that gets wonky (yes that is a technical term 
and just a reboot would do the trick. Today, the only way I can do that without a human actually there is to reflash it!
Should be simple enough to add.
Best,
Tahl
What’s wrong with having a Particle.function with the System.reset call?
@Moors7 what if my product has no user interface?
You can call functions from the console though, so I’m not sure what you’d need a UI for? (assuming the proposed console feature would suffice)
If you can define what "wonky" does then you could use code to cause a software reset, including the software watchdog or software timers. Do note however, that doing a software reset won't also reset your possibly wonky peripherals. This is where an external hardware watchdog would be used.
Thanks for all the responses.
I had one Proton which was returning a value in a var which was basically impossible. (At least I could find no place in the code where it would have been possible.) It was just one device and it happened a couple of times. However, it occurred to me that this would be a good feature in the console.
I hadn’t thought to do a remote function call. I guess I’m imagining the system firmware would have a higher availability than my code in case my firmware goes into a hard loop or something.
That brings me to a nice-to-have feature which I can’t really do on my end: the amount of time since a device was last on-line. Currently I do have a cloud script which polls all devices – Proton and Electron – but it does so every 6 hours (mainly to keep my Electron bytes down). That’s not a lot of resolution. The console could get to the minute or second. Would help in debugging.
Tahl
If networking is compromised due to malfunctioning code, there won't be much of a difference of what comes through or not.
The console does have a "last connection" column?
This is what the software or external watchdog can help with!
@Moors7 I’m glad you brought that up. That column doesn’t make any sense to me. For example, user N shows “last connection” at 4/12 (yesterday) at 8:23pm yet I’ve polled his device several times, including reading vars, since then. The console shows breathing cyan but based on the datetime, the user has been down for like 17 hours. In fact, I can find no pattern on the time of “last connection”. I have other on-line devices which have a time of a few minutes ago. Unfortunately, it’s not useful in the current configuration.
Thanks for any light you can shed.
Tahl
@peekay123, it’s probably a good idea for us to get a software watchdog in our firmware anyway. An external (cum hardware) watchdog isn’t possible for now as the first devices are already in the wild.
Tahl
Is this particular device an Electron? That would be normal for an Electron and very strange for a Photon. This is due to the data usage saving features and use of UDP communications on Electron.
@bko It is a Photon. All have the latest system firmware too. I can try to estimate whether it is certain Photons but I’ve largely ignored the data until now since it makes no sense to me.
Tahl
@Moors7 and @peekay123,
What timing. I have a situation right now where a Photon device appears to be “dead”; i.e., I get no var value when I poll the device. When I go to the console, it says “no functions found on the device” and “no variables found on the device”. However, the user reports that it is breathing cyan and if I ask the user to push a switch, which results in a webhook to our cloud, it works. So at least in this case, neither a function call to boot it nor a watchdog would work. Literally my only option at this point would be to ask the user to power cycle it or I reflash it – unless I had a remote reboot. (I suppose this might be the case for an external watchdog but the devices are in the field already.)
FYI.
Tahl
This vanishing of functions and variables may be a timing issue, since you only got a short window to register these after the cloud connection got established.
Hence you should register functions, variables and subscriptions as early as possible - e.g. first lines in setup().
Once you missed that timeframe - e.g. because some other prior actions took longer than expected - you’d need to Particle.disconnect(), wait a bit and Particle.connect() again to trigger a re-registration.
But there is an open issue for Particle to allow late registration.
@ScruffR, all my functions and variables are registered first thing in the setup() function.
I’ve only had two devices go “zombie” on me and then only a couple of times. What I mean by zombie is that they appear on the console as breathing cyan and the user can use the device including webhooks but we cannot read variables or execute functions anymore. One of the devices in question had been on-line and in use for a couple of weeks and another for a couple of months before it went zombie. SO, I don’t think it is late registration…
The other issue (that could have been cured with a reboot) was a var had a crazy high number in one part of the string and seemed stuck on that number.
In both the case of the zombie and the bad number, a watchdog wouldn’t really work and a reboot would have done the trick. Obviously if we find bugs with our firmware, we’ll fix them and reflash the field. A reboot is just to keep things moving along.
Agreed, having a way to remotely reboot would be very nice for us right now. I had to build it in via a Particle Function, but it’s not the same. The Particle Cloud can have intelligence to hold off on sending a reboot command until a device comes online, whereas clicking the button in the left column really only works if you get lucky that your device is awake and online at that moment.