Release 25

This is starting a slow rollout now. We’ll be updating the API docs and posting release notes over the next few days. Finally, wifi off mode for everyone! :slight_smile:

The upgrade process involves a lot of green blinking, and a patch of solid green. If you got the upgrade, then this code:

try { server.log(imp.getsoftwareversion()); } catch(error) { server.log("old version! "+error); }

…will give this message:

f2f252d - Fri Jun 14 16:08:00 2013

…otherwise you’ll see this:

old version! the index ‘getsoftwareversion’ does not exist

What happened to the much anticipated release 23? Was it silently superseded by release 25?

99f6597 - jenkins-ei-release-branch-627 - Thu Jun 13 04:23:25
Do I have to stand in line ?

My imp says: 99f6597 - jenkins-ei-release-branch-627 - Thu Jun 13 04:23:25 2013
or actually, the agent says this, on the imp I get the ‘getsoftwareversion’ does not exist error. So which release number is this?

This release 25 only refers to the imp device VM then? I don’t have a clear image of versioning on the device and in the cloud (the agent). Are they always simultaneously updated, or are they independent?

Release 25 is imp-only, and has a couple of rounds of small changes from 23 based on feedback from some early testers.

If you call imp.getsoftwareversion() on an agent then you get the agent version. The agent VM is updated much more frequently than the imp.

Right now 25 is going to mac addresses that end in 0 or 1. This will be expanded to 0-7 later today if we get no problem reports.

“If you call imp.getsoftwareversion() on an agent then you get the agent version.”

Shouldn’t that be agent.getsoftwareversion() then? Makes more sense, in my opinion.

server log: “imp OS upgraded” :slight_smile:

The idea, which could possibly have been made less confusing, was that if you call imp.getsoftwareversion() in device code, you get the version of the device environment; if you call it in agent code, you get the version of the agent environment.

Peter

Where are the docs for the API functions to connect to a different Wifi network ID?

Is there an estimated completion date for the Release 25 rollout? Just curious of the time frame I should look for.

Thanks!

@physicsnole should be done by tomorrow.
@sbright33 hmm, went AWOL. See here: http://devwiki.electricimp.com/doku.php?id=electricimpapi:imp:setwificonfiguration

That’s great! Now the only thing that’s missing is to be able to scan for Networks so you know where you are located. We would also need to know the encryption type of a new Network ID. Either to connect to a new open network, or if you already know the password, you need to be able to know if you’re at home or at work. Will this be possible in the future?

Thinking about it… You wouldn’t need to scan for closed networks, because you must already have their password. I assume you can already do this by looking for them one at a time, until you find one or none. But I’d like to scan for new Open Networks, for example Starbucks. I think I can already do this if I know the Starbucks SSID and I was only interested in them. But still what if I didn’t know what Open Networks were available nearby? I’d like to scan for them like a PC or Arduino Wifly can do. Will this be possible?

If we could scan for nearby MAC addresses we could geolocate the Imp without GPS. Someday?

The wifi scan API is already in the next update :slight_smile:

This allows wifi-AP based geolocation (sort-of indoor GPS) if you have the site survey information for the location.

Starbucks is a little hard as they have a landing page…

You mean the next one coming when? What version number? How can we lookup the location of each AP?

No date - or release number - on the next release as yet, but there will be a next release :slight_smile:

For indoor GPS tracking using wifi BSSID’s/RSSI’s, see WiFiSLAM / Meridian / etc. This only works for places you build a site survey for - eg a shopping mall or office. You’d pass the visible sites and signal strengths to a remote service which would then work out your location and pass it back.

I’m still hoping that device.getipaddress() will be in the next release. This would enable ip-based geolocation, which is accurate enough to get proper timezone information for the device.
On the other hand, since several months ago my local timezone is reported in the server log timestamp (earlier it was just GMT). What is this based on? device ip address, browser ip address or clientside javascript?

Timestamp is based on clientside JS.

Not planning on having getipaddress, because of the privacy implications; we’re considering a geolocation API instead, because that provides a certain amount of anonymity.

Could you go into more detail on the privacy thing? How is knowing your IP address more of a privacy problem than knowing your actual physical location? Any Iphone app can obtain the phone’s local IP address and (if behind NAT) the corresponding routable address.

Peter