Firmware version confusion

[JP]

Hello,

After finding on more than one occasion that my GameFrame suddenly turns itself on, I’ve decided to try upgrading the firmware…

I found the following versions on various forum posts, and can assume the last is the latest?
gameFrameWifi_20161201.bin
gameFrameWifi_20161211.bin
gameFrameWifi_20170116.zip which has photon_firmware_1484621449826.bin inside

I am doing the upload via this page:
https://www.ledseq.com/manager.html
In the device dropdown I pick “tasty_station” (no idea where that name comes from)

However, when visiting my GameFrame’s IP, it always ends up saying “System version 0.6.0”
Is the firmware not taking? or am I doing something wrong. I am guessing that my particle ID is the same email address I used to register here, but not 100% confident that’s the email I used when setting up the particle account when I got the WiFi adapter.

I consider myself a techie, and have written many aurdino programs, but I’m sorta underwhelmed by the “documentation” on the WiFi adapter, and what is a seemingly “magic” dependence on Particle.io – is there somewhere else I should be looking/reading to learn about this?

Appreciate any advise here.

[Jeremy Williams]

Hey JP–

Sorry for your confusion and the underwhelming docs. Let’s try to clear things up.

As far as the firmware goes, Github hosts the most recent “official” release. (The one from January you saw in the forum has no additional features.) So, yes, just grab gameFrameWifi_20161211.bin. Make sure you’re downloading properly from Github though (i.e. click the download button on this page).

You’re using the right page for managing your firmware. As for “tasty_station,” that is probably the temporary name given to your Photon when you registered it with Particle and made that account. You should have been given the opportunity to rename it then. You can change it by logging in here and clicking on the name. You can also access and play with functions that control aspects of Game Frame from there.

System version 0.6.0 is the Particle firmware version, not Game Frame firmware. To see whether the firmware uploads successfully, go to http://www.your-game-frame-ip/help and see it listed there. It should say 20161211. (It’s also very easy to tell simply using the Game Frame remote because a third mode is added (FX) in addition to Gallery and Clock.)

As for the dependence on Particle.io, you’re welcome not to use the exposed functions. You don’t even need to login to their server to update your firmware if you want to use DFU mode. I just find it’s much easier to do so. The built-in web backend (your-game-frame-ip.com) doesn’t rely on their services. That said, I’ll probably end up abandoning the web server (or making it opt-in) because it’s too buggy and causes the Game Frame to hang if it loses connection to the Internet. I run a watchdog that reboots the Game Frame in this case, which may be the root of your original problem where it suddenly turns itself on.

Can you describe what happens when it randomly boots? Does it reboot from an off state (powered down using the IR remote)? I may not have considered that case and can add a check during boot to see if it’s recovering from a hang AND was powered down, in which case it would return to an off state. I know this is a workaround, but the web server hang bug is deep in the Particle.io source and I don’t see them fixing it anytime soon. The best solution is probably to drop the web server and expand the firmware manager to have the same features as the back end, populated by exposed functions and variables. At least these don’t crash.

[JP]

Hey thanks for all the info, so I did get it to Game Frame Firmware: 20161211 successfully.

As far as the random turn on issue, I never use the IR remote, only the web interface (cause I link to it from my other home automation controls which all run from my own webserver inside the house)

Why does it randomly turn on, I’m not sure. I have a suspicion it has to do with WiFi disconnects, as a few other LED controllers and Aurdino WiFi shield based things in my house also get disconnected on occasion. I think I might have discovered the reason why last night, apparently my AP was trying to use a defunct NTP server, thus never adjusting it’s time skew properly, which can cause issues with the key refresh interval, or so I believe, but this is unproven/could be totally off base.

In any case I am pleased to know it’s not so dependent on particle.io, because honestly I feel that’s just another a) single point of failure b) planed obsolescence when the dot-com bubble bursts (again?) and particle.io goes belly up and c) IoT hacking is a thing and really getting out of hand.

After looking at the source of the /help page I determined I can send it HTTP commands for directly, which is cool, cause I can send /set?power /set?menu /set?next from the back-end from my own webpages and that’s all I really need.

I do notice when loading the root / (pretty menu) it takes awhile and sometimes crashes, requiring a power cycle.

[Jeremy Williams]

If you want to track whether the Game Frame is turning on or completely rebooting, you can visit this page and login with your Particle credentials.

https://console.particle.io/logs

Then reboot the Game Frame. You should see the log start to tick by. You can leave that up for a couple days and see what you see. If it actually crashes/reboots you’ll see it in the logs with “recover” in the data column. It says “boot” if it boots normally. That’s a little event that’s published on startup to try to troubleshoot this very issue.

I’m glad you found the HTTP commands, but as I said (and you’ve discovered) the web server is unstable and poorly supported by Particle. You’re much better off using the exposed functions to achieve the same things. They’re rock solid (independent of the web server), and just as fast, but you are using the Particle infrastructure.

You can call the functions via http, post commands, or javascript. I’ll try to update the docs in the next 24 hours with more details and followup here.

[JP]

Thanks!

For now, HTTP direct to the GameFrame IP is most efficient – but I am quite curious about the post/javascript options (although these are still going to dependent on the webserver right?)

I do realize I can accomplish the below via particle.exe command line tool (but again that requires my Internet connection and particle.io servers to be up, just to control something already inside my LAN) so, I do really wish…
– there was a /set?off option instead of just power toggle, because as part of my “leave the house” script I’d like to ensure GameFrame gets turned off (as I do with lights and the TV and whatnot) whereas if I send /set?power and it was already off, now I’ve only turned it on 🙁
– there was a /set?[filename] where it would automatically turn on and play that animation, for example when my kid mario logs that he’s home off the bus, show the mario graphic for fun. I could also get crazy & appreciate other “digital signage” style options to this, for example /set?[filename]&play?20&next?off for play that animation for 20 seconds then go off, or &next?random might mean leave it on and proceed through the list randomly.
– there was an option to have animations present in memory (for calling direct per the above example) but excluded from the normal random display, or when someone advances with /set?next

Optionally, if the webserver stable/un-stable-ness proves to be an issue, then I can always control power to the GameFrame via my own relay/controllable power socket feeding the AC adapter (this would let me reboot it if crashed, or ensure it’s off) but in this case I would appreciate a baked in option like you alluded to, something like “power applied state” and/or “auto-reboot state” with choices being a) turn-on b) stay-off c) last-state

[Jeremy Williams]

I added an Advanced section to the bottom of the underwhelming WiFi docs. 🙂

Granted, it’s really just an introduction to using the Particle cloud API and SDKs. I understand you’re averse to them, but I encourage you to try them out in some respect for a trial period and see what you think. In my experience they’re rock solid, and infinitely more reliable then the built-in web server.

And, no, the Particle cloud API is not reliant on the web server. The web server is an application level library that hasn’t been updated in 3 years. Particle’s entire business model is based on enterprise scale cloud services for their family of microcontrollers.

To be honest, the reason I included the web server was because I share some of your feelings about an isolated LAN. Unfortunately the web server library is just a worse experience. You can do a lot of what you want using the exposed Command function. Maybe give it a shot and see what think?

I have added a check for restoring from an off state. It will be in the next release.

[JP]

Very cool, will be playing with the exposed Command functions – thanks for all the info, much appreciated!

[Author]

Posts