Hi All,
I am trying to flash a new firmware onto my RPi 3. I've installed particle agent and the Tinker program works perfectly now.
Then I tried to use this tutorial to blink a LED (D0 and D7) that I got from here: https://docs.particle.io/guide/getting-started/examples/raspberry-pi/
I managed to flash the LED blinking program as well. I got the following output:
$ particle flash Pi-3 photon_firmware_1525802783151.bin
Including:
photon_firmware_1525802783151.bin
attempting to flash firmware to your device Pi-3
Flash device OK: Update started
However, on my Particle phone app, it still shows that my Pi-3 is still running Tinker and I can still control it using the Tinker program. I am using the particle CLI environment on my Ubuntu 16.04 machine. It works flawlessly with the actual Photons.
Anyone has any idea?
I've got the answer. I forgot that I used
particle compile photon
instead of
particle compile raspberry-pi
Could the particle CLI team please add error checking/handling for this in the future releases? 
Because right now it's not throwing any error message.
How would you intend to check for this kind of error?
I think the best way is to throw an error when someone tries to do "particle flash " and the binary file isn’t meant for that device type. For example, in my case, I was trying to do “particle flash” on a Raspberry Pi but using a binary that’s for Photon.
When sending the binary to the device CLI is not aware of the platform the provided name or device ID belongs to. Not even the cloud does care about the platform, it just forwards your request to send that particular binary to the device you referenced without ever needing to know which kind of device it is - that’s the beauty of a standardised (one for all) API.
There are APIs to request the particular platform for a given device, but the lookup does require extra time and effort.
BTW, the default file name produced by particle compile does provide the user with the actual info what platform that binary would target 
I understand. 
However, I am convinced that there would be more people that would not be aware of this kind of mistake. I am just saying that this is like the case when we try to run a binary for ARM on a x86 machine. It should throw an error. And I believe we can’t just say that the file name should give a hint of what it meant to run on. Please kindly take my suggestion and think about how to handle it properly if you would. This kind of mistake would just happen easily after 10-15 hours of programming.
The only practical way I could imagine to handle that would be to have the device issue an event in case an intended update would not be accepted (providing the device is still connected to the cloud after the update) that provides some indication about the reason.
AFAIK there are some new status reports planned for the update of mesh enabled devices, maybe some of these new reports will also find their way back to the “legacy” devices.
Maybe @jeiden could add a related “feature request” to the list.
However, as a dev myself, I’m usually rather looking at my own contribution to some misbehaviour first and maybe even take a break to get a fresh look at the issue before asking someone to fix my own lapses