Webpages on Photon / SoftAP

Page to show the current Particle variables and functions. Could provide very fast refresh if you need to see live data.


Wi-Fi configuration
Ability to add and remove connections and also change the connection attempt order.

Firmware and updates page


Custom Page on the device

2 Likes

Really up for something along these lines - would make implementing Photon in products for end customer set-up much more do-able. When can we have it?

Well I think there are some technological hurdles which need to be resolved by Spark :spark: Particle first.

Some of the functions needed are not available yet, such as reading and managing the list of SSID’s currently stored in the Photon.

Also, I think a function to retrieve the wireless networks currently available to the Photon would be helpful.


(ScruffR: Edited Spark to Particle :wink: )

1 Like

I have seen quite a number of forum posts along the lines of my Photon is flashing xyz color and I dont know what it means. I think that having webpages available directly on the Photon out-of-the-box would allow for much more detailed information about what is going on, such as “No Keys Found” etc.

What do you think @mdma / @nexxy / @avidan ?

This is a really interesting idea. Seems like a combination of dashboard and dev with a wifi config thrown in.

We actually do have some pages that give detailed info about “what is my photon doing, it’s colors are so weird!” in the new docs. I still need to add video and visibility to some of these.

I just wanted to throw out the idea of using a web application that is hosted elsewhere (eliminating the need for special firmware on the Photon itself).

Once SoftAP HTTP support is available (coming soon™), you should be able to manage your Photon from any web application that can access the Particle API with your access tokens.

Unless I’m missing something, it seems like this could be a more reliable/flexible approach.

2 Likes

The problems I was hoping to solve with this I think would be difficult to achieve with an externally hosted website.

  1. Managing Wi-Fi connections. For example giving the Photon to your friend and saying the Photons website password is this. They take the photon home and with no additional info can access it and connect it to their own network. You cant do this with an externally hosted website since it would not be accessible at the persons house. You could achieve this by unclaiming, claiming, reclaiming but I think this solution is simpler.

  2. What do these breathing / blinking leds mean ? The Photon hosted website could be accessed before there is even a Wi-Fi connection established to the internet and provide an explicit error message. You could also access detailed information like the firmware loaded / mac addresses which is useful. This also helps the 8% of men who are color blind.

  3. Custom Apps / Particle variables. This would enable very fast viewing of data (every couple of seconds). This could allow realtime data viewing without needing to build a screen into your hardware. I have found that with network latency it is pretty difficult to get realtime data on an external website, also once you have a bunch of devices the load on the external website can get high just due to the volume of requests.

Ah, yeah I see what you mean.

An embedded app would definitely be sweet for that kind of use case!

HI there @Rockvole! This is an interesting idea, but I must admit I’m not sold on this. Sorry!

  1. managing WiFi connections - that’s the most pertinent use case here, but doesn’t require a web app UI implemented in the Photon - simply exposing the softAP setup controls via HTTP will make it possible to launch a local http server (such as part of particle setup wifi) to provide a setup UI. Keeping the UI out of the firmware will make iteration and development much faster, and updates simpler, and the UI would undoubtedly be more refined, being able to use more resources than the 100Kbytes available in the Photon plus leverage existing webapp frameworks in Node.

  2. I feel information on the LEDs is best maintained in the documentation where we can more easily update resources and provide better resources than there is room for in the Photon, such as high quality images and videos.

  3. Custom apps/particle variables. You can already do this by rolling your own web server using the Webserver library, but of course not having to roll our own and instead use a tested solution would be better. So, to make this simpler for application devs, I would instead put the functionality in a new library that provides a ready-built solution for exposing variables via HTTP.

The system firmware has about 100K of free space, which we plan to use for features such as multithreading, AP/WiFI Direct, TLS sockets, UDP cloud protocol. Adding a webapp in there could easily use up all of that space and even then the UI might not be as refined as we’d like it to be.

I wish I could be more upbeat about this. :wink: On the face of it is seems like a great idea, but digging deeper, I feel there are better ways of solving the problem of Photon AP setup than embedding a webapp in the photon, at least for the cases outlined here.

Cheers :smile: ,
mat.

4 Likes

Hi @mdma,

  1. Having a local Http server wouldnt help in my situation - none of my friends which I pass the device to are running a local Http server. Also connecting to the local server would require getting the WiFi password into the Photon somehow.

  2. I wasnt suggesting any documentation on the Photon regarding flashing LEDs, but the precise message which the flashing LEDs refer to such as “lost connection to the Particle cloud”.

  3. Yes you can roll your own server, but if Particle provided a template then it would be simpler to plug your custom page into that template and provide the wifi connection tab etc to anyone you give your Photon to.

I didnt imagine this would be custom firmware, but it would be installed much like tinker is now. Then the user can choose to flash their own firmware as before or link in the Particle template if they want those features.

The Photon webpages template would reduce the problems I had lending the core to my friends.

Friend 1 problem :
Met him in a restaurant to pass the core to him. He had a blackberry so couldnt run the app.
Solved by : Buying a Dlink DIR-505 and pre-connecting the core to that router to let him have that also.

Friend 2 problem :
I took the core to his house and tried connecting my phone to his WiFi network. It didnt work because his WiFi password was 7 digits long which was not permitted by my Samsung phone. (8 chars minimum). He didnt want to change his WiFi password on all his devices since the router was owned and installed by the local telco.
Solved by : Providing him with another Dlink DIR-505
This also allowed him to pass the device to his neighbour.

Friend 3 problem :
Meet him in a restaurant. I dont want to buy a third Dlink DIR-505.
Plan to solve by :
I am getting a laptop for my birthday so I plan to put the Spark toolchain on that and then I can program it in the restaurant with him typing his Wifi details into Particle cli.

Friend 4 problem :
He lives overseas and is very non-technical.
So I will see if he will give me his wifi connection details. If that doesnt work out I will have to unclaim the core so he can type in his connection details. If I need to update the firmware I guess the trouble will start then since he definitely wont be able to install the Spark toolchain etc.

I believe that Particle have solutions for larger deployments, I think that may be a lot of work for just a handful of devices for testing.

Some of these issues could be overcome relatively easily I think:

Friend 1&2: what was he planning on doing with the device? Was it a finished product, or were you lending it to him to try it out and program with it? If his intentions were to reprogram it, I think it’s reasoable to assume he can get a serial connection up and running (use putty). No CLI or app needed for the wifi credentials.

Friend 3: I like to think of the tool chain as everything that’s needed to build locally. The CLI isn’t nessecarily part of that. Neither are needed to configure wifi credentials, like I mentioned above. Any serial terminal will do just fine.

Friend 4: I’m not sure why you’d have to unclaim it so he can insert his credentials, if you could just put it in listening mode as well.
Also, I’m not sure what your non-technical friend would want the toolchain for? He could just use the web IDE?

I know there are some solutions in the works to make it easier to setup and manage devices, that will be part of the dashboard. Hopefully they’ll make your life a bit easier in that regard. But personally I don’t see the advantage of running a webpage from the photon, it’s way too resource intensive, and really doesn’t pay off. With the upcoming http softAP, you should be able to simply open a webpage and manage the credentials. This way, all efforts are being made outside the photon, leaving more room for more useful features.

I am just lending them sensor devices so they can view the results of the sensors.
None of my friends want to get into programming this, even if some of them are
capable they just want to try the sensors out.

Friend 4 : Are you saying that anyone can install the Spark App and they will be able to
put the device in listening mode and change the wifi credentials ? I assumed
the device would not allow anyone except the person who owns the cores to
change the credentials ?

Fair enough :smile:

Yes, that's possible. I wasn't entirely sure myself, but I just tried it with a different account on both the Core and the photon, and it seems to work just fine :smile:

It works for the Core too, although it doesn't have those fancy messages.

How exactly would you imagine that to be possible? You can reset the credentials using your finger, there's no way to really verify that's the true owner. Also, you add the credentials when it hasn't yet got an internet connection. It's bit hard to verify with a server that you're the owner if the exact purpose of the change is to reach that very server...?

1 Like

Oh I see, my knowledge is out of date. This is the way I thought it still worked with security measures to jump through :

But once the new owner claims it I would no longer be able to update it over-the-air for them, or change any of the Particle functions / variables for them ?

I thought the Photon was around 10x faster than the core so running web-pages on it would be possible. My current code doesn't do much, just loop around reading sensors and sending them every 10 mins so I think I would have plenty of remaining space for webpages. It also would have been nice to run webpages so that I don't have to integrate a screen for faster sensor readings every couple of seconds.

Yes, but they can only claim them if you have unclaimed them. For updating the credentials there's no need to claim anything. You're only giving it new information so it can get online, nothing more. That's what the seconds screenshot says. "We managed to give it credentials, but since it isn't yours, we can't connect with it to check if that was successful."
Long story short: you stay the owner, they just feed it new credentials. Nobody gets hurt :wink:

It's not that it isn't possible, but that it would eat so much resources, while providing so little additional benefit. It's great that you can log in from a webpage on the device, but is that really necessary (considering the app will work, as will a serial connection, as will the CLI, as will Particle Dev, as will HTTP softAP in the future)?

Like MDMA suggested in point 3, you can do that. But, rather than cooking it into the firmware, use a library which will allow you to do that. That way, the Photon stays 'clean', but you can still have your desired webpage.

"every couple of seconds" isn't really 'fast'. A roundtrip to the server and back takes less than 500ms on average. That would allow you to updates things twice a second, which is already faster than "every couple of seconds" :wink:
Not having to integrate a screen is a bit questionable, since you'll still need a screen to see that page. Rather than the page being hosted on a micro controller, which main purpose is to control things (as the name suggests), I'd rather host that page on a webserver, made for that very purpose. A simple raspberry pi would suffice for that, or a NAS server, and would all provide so much more functionality than the Photon could ever hope to offer.
I personally have a raspberry which I intend to use to collect, store, analyse, and visualise data with, from my particle devices. That's something I can't, and rather not, do on the Particles themselves.

Hi Rockvole, I can't agree more about this being an essential feature for and unsophisticated end-user. Maybe I'm missing something, but any company that would require a user to run a local http server to set up credentials rather than through a photon based website is at a severe disadvantage (Imagine if Nest was to do this). Although it is resource intensive on the photon, is it safe to say it will be possible to provide wifi credentialling website like the Dlink DIR-505?


I have to disagree here. It does provide that much benefit, if I am understanding everything correctly. If an end-user of a commercial product can not set up the wifi in 10 minutes with simple instructions (i.e. a webpage that doesn't require an app download or 10 additional menus), their first experience with the product will be awful. From a business standpoint, this is likely a necessity and would be worth the extra resources.

Here is a link to someone experiencing a similar issue

@Moors7 Ok sounds like getting the credentials in is better than I realized.

I only need to graph data remotely every 10 mins, anything higher than that is not
needed in my case to get a good idea of sensor readings in a room.

I tried sending the data faster which was troublesome and I had to use a faster http client for it to work
at 1 min intervals (on the core).
I dont need to store/graph the “live” data, just have the option to view it in the case of
trying to find something with the sensor and wandering around (like a Geiger counter).

Even if I did get very fast interval sending to work, it would become a problem for the server in time
with dozens of devices reporting every second. I’m planning to try one of the 1.3" OLED screens anyway to
see how that looks since they are only $5, but it would have been nice to use the local
cellphone screen to view it on a webpage.

"The free Nest app lets you set up your Nest products" ~Nest

So, for Nest it's okay to ask people to download an app, but for Particle it's not?
This is also Nest:

If you don’t have a supported phone or tablet, you won’t be able to connect your Nest Protect to your Wi-Fi network nor associate it with your Nest Account.

The similarities aren't by accident, the Nest Protect and the Photon actually use the same wifi chip.

Tell that to the guys who sold their company for $3.2B :wink:

Enough about Nest, their products are probably awesome and all that. But so is the Photon. If I'm not mistaken (okay, I know they are), they are working on getting softAP to work through a browser. What this would mean is that you'd go to an (externally) hosted webpage, and follow the steps to set up your Photon. You wouldn't have to host it yourself. Now, I think we can agree that that's more convenient than having to host it from the photon itself?

You can still create a user app in which you host a webpage through which you can manage credentials. I just don't feel like that should be put in the system firmware, wasting useful space/resources.


@Rockvole

A 10 minute resolution should be highly doable! 1 minute intervals as well (I'm currently doing that with a Core). I personally like the SSEs for sending the data in JSON format. I then have that picked up by my server which parses and stores it. Seems to work really well. You can send SSEs at a rate of 1p/s, so your resolution could go up accordingly.

If you want to do any serious representation of data on a webpage, you should really not want to do that on the device itself. If you use SSEs you don't need anything other than a device which can access the web. If you go to this page in a browser, it shows you your SSEs with having to host anything, anywhere: https://api.particle.io/v1/devices/events?access_token=ACCESS_TOKEN

Depending on your server and the amount of devices, you should be okay. Node.js is actually very good at handling a lot of concurrent events, and is generally being used for scenarios like that.

With a bit of HTML/CSS/javascript, you should be able to make a rather decent webpage which will allow you to monitor your device. For that reason, amongst others, I've set up this page. You can easily see the functions/variables/status of your devices and can trigger them accordingly. Feel free to use it if it's helpful :wink:

1 Like