Photon install instructions don't work

The instructions say to install the “Windows CLI Installer” and then it says to open the “command prompt”. With Windows 10, the command prompt is power shell. NPM doesn’t seem to work in Power Shell. I had to install NPM manually and then use the “Node.js command prompt”.

These package installers are a hot mess and nothing ever works this way. Also, there’s SO many assumptions in the community that what was designed to simplify has made things more complex or impossible.

Anyway… The basic Photon instructions are incorrect at best. I needed to install the Windows CLI Installer because while I could connect my Photon to the internet and get the pulsing blue LED and the “Signal” worked, it can’t flash any code (Which will be reported in a different topic).


Is the Photon breathing cyan?

Are you sure?

Though it might not have worked for you, it has worked for a lot of people just fine, so please try to generalize a bit less. Also, that ‘hot mess’ of an installer is much less of a hassle than installing all the packages separately, though there’s no-one stopping you from doing that :wink:

If you could point those out, we can have a look at them to see if things can be improved.

If the former two work, then the latter should as well. Did you give Safe Mode a try to make sure user code wasn’t interfering?

Maybe you were making things to difficult?
It’s a one step process… (Maybe you needed a reboot :smiley:)

1 Like

Sure is! And the “Signal” button works too.

Right click the windows logo (or Windows + X). With the latest release of Windows 10, command prompt was replaced with PowerShell (where Command Prompt was, now is PowerShell. Anyway, if there’s a Node.js shell, maybe that’s what the instructions should say to select. Or better yet, just have the Photon work out of the box without having to jump through all these ambiguous hoops.

Package installers are fine on Linux, but on Windows? What a step backwards! If something needs to be installed, just supply an EXE like it should be on Windows.

One would think but I can’t flash, which is why I’ve had to resort to jumping through these hoops. Blue pulse is fine, signal works, code verifies just fine (even tried test blink sketch). Cycled power, reset, doesn’t help. Since I’ve never been able to flash, not sure what Safe Mode would do. But, I tried doing it and I have no idea what it should be doing. The manual explains how to get into Safe Mode, and how useful it is, but doesn’t say WHAT it is doing or HOW it is useful. It pulses purple, how is that useful exactly? The manual on Safe Mode only says how to get into it, not what to do with it. Pulsing purple is not helpful.

Cycled power probably 50 times. Reset probably 50 times, tried going into Safe Mode probably 20 times. Blue pulse and signal works, but nothing else.

Not only EXE is the way things should be installed - MSI is just as acceptable.
After all many EXEs are just entry points for the default setup.exe or a runnable-zip which actually just install an embedded MSI.

And on my Win10 machines PS works just as well as cmd still does - just because it’s not present in the Windows context menu, you can still add your own Start link. After all that’s a Windows thing, not exactly a shortcoming of Particle.

BTW, I haven’t found your other thread yet

Safe Mode is useful as a safe base to start off of as it runs an empty loop() preventing potentially interfering user firmware from messing with the cloud tasks (e.g. OTA update). So when your device is breathing magenta, you should be able to flash OTA.


Does your windows version now show the same thing as my screenshot? If it does, you can reflash AND configure your device with it. I suggest try DFU mode, holding the two buttons, a while, release one of the two buttons until you get green (details escape my mind) reflash tinker, and than try manual setup all using cli.

I’ve got the same Windows (creators update), hence the screenshot still clearly showing the command prompt. Pressing Windows + R gives you the Run menu, in which you can enter ‘cmd’ to open the command prompt as well. Yes, Microsoft would like to make PowerShell the default, but that doesn’t mean that the command prompt is gone, or that that’s somehow Particle’s fault.
For most people, the Photon does work out of the box. Either the App or the online setup should suffice to get it connected. If not, there’s the CLI. An installer has been made available since people were unhappy with the lack of an installer. It has improved the process a lot.

I don’t really see the problem with a package manager to be honest. You’re going to be programming an embedded microcontroller, not installing an app on your phone. A bit of interaction isn’t unreasonable I think. Again, there’s an installer available for Windows already.

Just to make sure, but you’re mentioning ‘blue pulse’. Is that dark (pure) blue, or cyan? Any other colors/patterns visible?
As to what Safe mode is, does, and how to get into it, the docs describe that nicely:
Could you make a screenshot of the Web IDE with the device drawer open, and your device ‘expanded’?

As for setting it up using the CLI, you need to be in listening mode, not DFU mode.

1 Like

Thanks for the browsing, I would have let him search myself :smiley::imp:

The problem with package managers is that there seems to be a new one every week. Every day I hear of another one. Every time I turn around, a different project uses a different package manager, which needs to be installed. Package manager install inception. I spend more time installing package managers than I do packages.

The instructions imply using any shell. This one says: "open a command prompt or terminal"

While this one says: "You’ll need to open the command prompt for this next part. You can also use Powershell or a similar command line tool if that is what you are used to."

So I hope you can understand the confusion when it wasn’t working. This type of ambiguous instructions often leads to these types of problems.

Back to the problem on hand. I was getting the correct blue breathing light as it was connected to the Internet. In the IDE, it would show it was online with a breathing blue “light” as well. Signal work work, but not flash. In the mobile app, it would show as not connected, even though I used my phone to connect the Photon to WiFi. I didn’t know what Tinker was at this point either as I couldn’t connect from my phone to my Photon as it showed off-line. So, I never even had the option to flash Tinker. I also tried 3 different WLANs (as I thought maybe it was a port forwarding issue). Two WiFi SSIDs at home (one is public one private) and a public one at work with the same results.

Finally, I jumped through enough hoops, installed Particle’s favorite package manager, guessed at using the correct shell, and figured out what I needed to do to upgrade the Photon firmware. Then, everything started working just fine! My guess is that because my Photon was part of the original Kickstarter and this was the first time it was used, the firmware on it wasn’t compatible with the latest communication protocol, as it would simply not flash (but everything else seemed to be working just fine).

So maybe this problem is unique to me as I’m the only one who was running the original firmware? But, I would have no idea that it would no longer work without being upgraded, and those instructions led me on this ambiguous path.

I’m glad you got things working. However, what other package managers, besides npm, did you install during your struggles? I am curious because I don’t know of any others, and I want to avoid stumbling onto them.

A new package manager that I just needed to install this week was Composer. I miss the good old days when people wrote things on their own that didn’t rely on 500 other libraries so we had no need for package installers.

And at the same time, development took much longer because everybody had to reinvent the wheel all over again.:wink:

1 Like

Or worse everyone packaged a slightly different version of the same library and relied on hideous deprecated or undocumented feature in that library that wasn’t in any other version resulting in conflicts and confusion.
The time you miss never existed, they have been less visible to the end user when everything was packed up as one binary hardlinked package, but the libraries were still there and still being used and there was more chance something just wouldn’t work.
One of the golden rules of programming as I was taught, "Do NOT reinvent the wheel."
Others include “Keep functions as small and well defined as possible”
“Keep global variables to an absolute minimum” (Something that seems to be frequently ignored in the embedded world)

I would 100% disagree. I would much rather build something on my own that I can rely on rather than use a bloated library which could break at any time and be totally out of my control.

Yet, you’re using 3rd party hardware and software, which seems to contradict that notion.
Sharing is what makes programming a lot easier, and better as well. Having good systems to share that code, and/or collaborate on that is then vital.
If you want to be ‘in control’, then download that library, pick the pieces you need, and move on. That’s not to say that the concept of those libraries is a bad thing.

This statement seems to be based on a misconceptual premiss that these two options are the only ones with nothing in between.
How about having the option to rapidly writing slim working code that incorporates well designed and reliable libraries? I was told that’s actually happening more often than not.

There are use cases for building from scratch but also to reuse well written third party libraries.

BTW, as Jordy mentioned, with an absolutistic 100% statement, you’d have to steer clear of any any graphically bloated OS and dev tool too and maybe even compilers and go pure binary machine code :wink: