Release 30 (Monday Aug 25th)

The long awaited impOS 30 will be released on Monday Aug 25th!

This is a huge release, and we are very excited about it. Some of the really great things in this release are listed below, but you’ll definitely want to checkout the complete Release Notes (if you haven’t already):

  • Better support for BlinkUp
  • Better support for when the WiFi driver crashes (should resolve the ‘Device Restarted: WiFi Error’ bug)
  • Support for imp003
  • Improvements to the UART class to let you read blobs rather than individual bytes

Complete Release Notes:

NOTE: Your device will be automagically updated - you are not required to take any action!

Automatic firmware/OS updates are part of the secret sauce that makes Electric Imp so great :slight_smile:

Monday has passed, nothing ‘automagically’ happened with my two active devices!?

I’m waiting for the impOS 30 release to be able to debug my I2C problem using i2c.readerror()… :-S (sorry for being impatient).

You are correct! We discovered an important bug in the 11th hour that we were working to resolve.

We have pushed the update and the next time you Build and Run (or power cycle) your imp should get the update!

If people hadn’t noticed, this is out in the wild now :slight_smile:

Just had my devices updated, thanks! :wink:

Two of my devices have gone offline after the “firmware update triggered.” Looks like I’ll need to power cycle those to see if they come back online. All others seemed to come back up just fine. These two (along with others that did not experience problems) are on cellular connections. If the firmware update is large enough, they may have had problems getting the update completed without interruption.

One of a couple of mockups in the field stopped running after a power cycle. According to the log it repeats this behavior continuously:

2014-08-27 15:42:26 UTC+2 [Status] Device Booting; 2.44% program storage used
2014-08-27 15:42:42 UTC+2 [Exit Code] imp restarted, reason unknown
2014-08-27 15:42:42 UTC+2 [Status] Device Booting; 2.44% program storage used
2014-08-27 15:42:59 UTC+2 [Exit Code] imp restarted, reason unknown

New sketches download fine. I have reduced the code to the following. If I comment out the code line with hardware.uart57.configure, then it runs, otherwise the above behavior.

It seems in accordance with the updated documentation. Something incompatible with the new firmware?

// IMP001 based mockup with led on pin 2 and RX RF module serial on pin 7

state <- 0;

// Call back function for serial data
function readSerial() {
local result = 0;
result =;

// Hellow world blink example
function blink() {
state = 1-state;
imp.wakeup(0.5, blink);

// Configure and start
hardware.uart57.configure(2400, 8, PARITY_NONE, 1, NO_TX, readSerial);
led <- hardware.pin2;
server.log(“Started …”);

I’ve tried that code in an imp001 here and it seems to be fine. Are you sure there isn’t some hardware reason why this unit dies after about 15s? Are both of your mockups running the same Squirrel code on the same hardware?


I have a SolderCore connected to a CradlePoint router via Ethernet and an imp001 connected via WiFi to the same router. The router is connected via USB to a MiFi device. This configuration has been in production for months. Historically, the imp001 performed extremely well–passing data nearly every minute of the day. However, that has gotten worse since the firmware update. The SolderCore is passing data most of the time and missing data is an indicator of acknowledged intermittent cellular issues. The imp is now restarting about every 12 minutes or so and reporting “imp restarted, reason: wifi outage”. It’s odd – it seems the device does an agent.send() and then disconnects soon thereafter. I’ve never seen this pattern. BTW, the imp001/imp002 have always outperformed the SolderCore–one of the reasons we switched to the EI platform.

I haven’t read of any WiFi code changes in the update that would cause this, but I may be overlooking something. My code has not changed other than adding a startup function to log the firmware version.

(side note – the imp001 did have trouble getting the firmware update, so I had to bring it to the office and let the update take place over our Internet service).


did you set imp.setpowersave() true?

I get this with my imp001 only with powersave set to true.

I think the “wifi-outage”-reboots started after release-30.6.

I have done nothing with imp.setpowersave() – quite honestly, I wasn’t even aware of it!

I have other imps in the same configuration, so I’m going to “assume” it’s a poor cellular connection for some reason that may be presenting itself as “wifi outage”. I’m off to change the cellular modem.

(Updated 20140828 11:00 EDT) I believe the part of the problem had to do with the cellular connection. However, I had to do a Blink-up to get the imp001 to come back online after returning it to the site (the SSID and credentials had not changed).

Thanks Peter. Hardware reason yes and no. It appears the new firmware is sensitive to a hardware reason, that has been there for a long time.

Similar code has been running on 4 mockups on and off in a period of a couple of months now. The 2 currently active mockups dropped off today. And on 2 breadboards with April boards running for 1-2 years - they also stopped working today. Last heard from the units at these times (CEST):

20140827 at 13:08 Mockup
20140827 at 09:07 Mockup
20140827 at 09:55 Breadboard
20140827 at 09:34 Breadboard

On a breadboard unit I have located the offending hardware wire as the RF module data out connected to imp001 pin7 (pictures). The RF module is this one:

It is a 5V signal (and the imp is not 5V tolerant). It appears it has worked for 1-2 years for mockup demo purposes, until the firmware update rolled out?

A real product is being designed, and there is of course already a level shifter in it.

Found a software workaround by changing NO_TX to NO_CTSRTS. Was able to push it into the units in the field.

Tri-stating the pins or configure as analog in before hardware.uart57.configure did not have any effect.

Wondering if the imp with the new firmware is trying to sink pin7 during a hardware.uart57.configure with NO_TX as parameter …

I have the same problem with my Imp (231e9f4dead3dbee) since yesterday. Code looks like this:

`DistanceSensor <- hardware.uart12;
MatrixDisplay <- hardware.uart57;
DoorController <- hardware.pin1;

DistanceSensor.configure (9600,8,PARITY_NONE,1,NO_TX,DistanceSensorEvent);
MatrixDisplay.configure (115200,8,PARITY_NONE,1,NO_CTSRTS);
DoorController.configure (DIGITAL_OUT);

DoorController.write (0); // Set initial state to low

GarageClosedSensor <- ReedSwitch (hardware.pin9, DIGITAL_IN_PULLUP, GarageClosedEvent, GarageOpeningEvent)
GarageOpenSensor <- ReedSwitch (hardware.pin8, DIGITAL_IN_PULLUP, GarageOpenEvent, GarageClosingEvent)`

with the log showing:

2014-08-28 19:18:21 UTC+1 [Status] Device Booting; 12.94% program storage used
2014-08-28 19:18:22 UTC+1 [Device] Server Online
2014-08-28 19:18:29 UTC+1 [Exit Code] imp restarted, reason unknown

every 7 secs. Any thoughts

nb. It’s been running the code above flawlessly for months 24/7

After some investigation it seems that the line causing the issue is this:

DistanceSensor.configure (9600,8,PARITY_NONE,1,NO_TX,DistanceSensorEvent);

If I comment it out everything is ok, and if I leave it in with an empty function for a handler it restarts. I can’t really remove the NO_TX like @ThermIT as I need the other pin (RX) as a DIGITAL_OUT.

I have 5 imps with different projects and have been working flawlessly for months now even year+ some of them. Since the new update 4 out of 5 of them show me a [Status] Device disconnected after a while.
Is there anyway to revert to an older Release?

The network also should not be the issue. I have 3 of theses devices into one location and 2 in another. Also most of them are connected to different access points, and devices connected to these access points seem to work without problems. But I did restart all networks in both locations just in case but i still have issues.

All 3 imps here updated flawless here, thx imp team

2014-08-22 10:40:38 UTC+2 [Device] Sending data to Imp Agent 2014-08-22 10:42:09 UTC+2 [Status] Device disconnected 2014-08-27 00:23:34 UTC+2 [Status] firmware update triggered 2014-08-27 00:24:10 UTC+2 [Status] firmware update triggered 2014-08-27 00:24:45 UTC+2 [Status] firmware update triggered 2014-08-27 00:25:22 UTC+2 [Status] firmware update triggered 2014-08-27 00:25:58 UTC+2 [Status] firmware update triggered 2014-08-27 00:26:34 UTC+2 [Status] firmware update triggered 2014-08-27 00:27:09 UTC+2 [Status] firmware update triggered 2014-08-27 00:27:45 UTC+2 [Status] firmware update triggered 2014-08-27 00:28:21 UTC+2 [Status] firmware update triggered 2014-08-27 00:29:40 UTC+2 [Exit Code] imp OS upgraded 2014-08-27 00:29:40 UTC+2 [Status] Downloading new code; 6.00% program storage used

My imps updated to the latest code as well with no issues. But i still keep losing them.
ElectricImp engineering please fix this again, i had a piece of mind before, now i keep on losing my imps :frowning: