Question about local network traffic (maybe this needs an FAQ entry?)
  • First off, this hardware looks awesome, and the imp's way of loading code makes many things much simpler. However, the project I have in mind doesn't appear to be possible with the imp's software, and I'm curious to know the likelihood of that changing in the future.

    First off, let me recap what I think I know, and someone can correct me if I'm wrong:
    - Most of the Squirrel code is running on the imp hardware itself, and keeps running if Wifi/internet goes out.
    - Some of the Squirrel code has to use the ec2 webservice to do heavy lifting, including anything involving a network connection.
    - There's no way to send a UDP or TCP packet to a local IP on the same network as the imp.
    - Round-trip time from an imp to a local PC may be in the 500ms range.
    - The imp's OS code is closed, probably due to WiFi firmware, thus if anyone were to reprogram their imp, they'd have an ARM with no WiFi driver.

    So, is there likely to ever be a way to send local packets from the imp?
    If not, I completely understand - do you guys have a favorite embedded WiFi module (perhaps one of Microchip's)?

    (If anyone is interested, my application uses xPL, a lightweight UDP-based home-automation protocol. Having my lights stop working when the internet goes out, as well as a 500ms delay, won't work for me).

    Thanks,
    -Scott

  • Just correcting a couple of bits:

    - All the squirrel runs on the imp. The HTTP nodes you see in the planner run on the server. Soon, there will be agents that are separate squirrel programs that you write, that run on the server too. These allow you to do much more advanced things with HTTP.

    - When wifi goes away, squirrel doesn't run. Though the squirrel is cached locally, it's currently very tightly bound to the network connection. This restriction goes away in the next release (dev builds already have iT)

    - Correct, there's no way to send UDP or TCP locally.

    - Round trip time depends on where you are relative to the servers. Currently, they are in amazon west coast, so if you're in California, your round trip can be under 100ms. We will be spinning servers up in Europe and Asia in the coming months and hence latency for people in those areas will improve significantly.

    - OS code is closed, because that's (along with the server) is where we've done man-years of work. We sell hardware, but that's not where we add the most value; some of our customers will end up building their own hardware and running our software.

    We have no plans to implement local networking on the imp. Never say never, obviously, but "no plans" means just that. We have other plans to ensure things work if your network connection goes down.

    Personally I don't really have a favorite embedded wifi module - it was because they all sucked to some extent that electric imp was started. I've not used the microchip ones, but they are the most "open source" that I'm aware of. Roving networks modules are solid, but don't seem to get great range, ditto for gainspan. Have not tried any others...
  • When wifi goes away, squirrel doesn't run. Though the squirrel is cached locally, it's currently very tightly bound to the network connection. This restriction goes away in the next release (dev builds already have iT)


    WOW really?! I do wish things like that might be documented somewhere — like perhaps the FAQ, because that is one major limitation, No one wants a toaster oven that stops working if your internet goes out.

    The things I want to build that use the IMP need to be able to operate if the network goes out, and no network is 100% reliable (remember the 1st rule of network computing). Additionally people take their consumer electronics with them to use on the train, or on vacation, or the park, or lots of other places where there is no wifi available.

    I really really want your product to succede, and I am very glad this specific issue is being addressed; but please document these kinds of assumptions and make sure you can accomodate a network that comes and goes.

    Even the chromebook — a device that is intrinsically dependent on a network connection — can operate to some degree without a stable network.
  • It is documented, and has been since release: http://devwiki.electricimp.com/doku.php?id=whatisntthere

    ...it's always been in the plan, just not first on the list - back at release time, the squirrel was ram-loaded from the server and not even cached locally! We've been on the path to this for a long while now.

    We're fully aware that some products absolutely require this!
  • Forgive me, I am sure this is just me just missing it, but I don't see where in that linked document it says that if there is no wifi squirrel doesn't run. I see where it says that it contacts the server on powerup/wakeup but not that the squirrel code doesn't run.

    I read that section before I ordered my imp, and just assumed that it was reffering to the fact that the startup would be slower if no network was present, not that it would not run at all.
  • Hugo - thanks for your answer. That's exactly what I needed to know, and I appreciate the honest answer on Wifi modules. I've already had to agree to an NDA and apply for a user ID on one company's site just to try to read the product brief for their Wifi module.

    Just to reiterate - even with no local networking, this thing is a whole lot of neat-o crammed into a really small package.
  • @jockm: Sorry if that was clearer to us than to you! However, the restriction will be gone shortly...
  • Just to chime in after a short time running through the modules and playing - this is a great system, and the burden it takes off the developer/tinkerer to have the backend built and robust is considerable. The comment about a toaster oven going out if the internet is out is a little off base - in an appliance like that the Imp would be used to monitor working status or toubleshoot remotely (or something else we haven't thought of yet). Doubtful the internet is necessary to make toast.

    There are other solutions out there for local control of all data gathering and sensing - Xbee, Bluetooth, other WiFi chips - but even those will give out if the power or connectivity goes off. You pick the Imp for its suitability and ease, not its ability to be everything to everybody.

    Look forward to the new features to come!
  • Has there been any update to this? Will squirrel now run without a network connection? Additionally: Will it run without wifi? Will it run without a connection to the imp cloud, as these are completely different scenarios.
  • there is an additional distinction that should be made: at boot, or once the program is running. and 'with / without wifi' is the same as 'with / without imp cloud'.

    At the moment, an imp does need a wifi connection to the cloud at startup. once its running, it can continue to function without wifi or a connection to the cloud.
  • @joevitale I would love to know the answer to that too. I was very excited about the Imp when it first came out, but the various restrictions, arbitrary limits, and uncertain nature of the service fees simply made it too hard to bet on.

    I have yet to meet someone who owns an Imp based product, let alone even see one in a store. It is still comparatively early, but I can't help but wonder if their vision were a bit less all encompassing and rigid, if things would be different.

    I want a small wireless microcontroller that is easy to configure, and ideally helps me avoid the fees with FCC Intentional Radiator certification. Though that last item isn't a requirement, just a nice to have. There is a real market for this, and the Imp folk are leaving money on the table by not addressing it.

    Then we have the utter lack of transparency on pricing, the glacial pace of communication, and the lack of follow up on questions like this. Its been months since I was last here, but there was a lot of "trust us" and "we are working on that" but not a lot of results.

    I can't build a product, nor base my business on that on that. Which is a shame, because the Imp is a great piece of kit.
  • There are imp based products at Home Depot (USA). The Quirky line.

    I think they would answer your questions if you email them. I think this forum is only supporting the hobby market that use the Developer Edition cards and are not mass producing a product. For those cards the service is free after you purchase the hardware.
  • I have yet to run into the Quirky line at my local Home Depot (at least as of last month). I am not saying they are not out there, my point is that there isn't much out and I personally have yet to encounter them.

    I did email about technical question I raised and got no different answers. As for the business questions, my point wasn't that you can't get the information, but that there is no transparency. I have no assurance that I am getting anything near the same deal as anyone else. There is no need for that level of obscurity.

    I also have no assurance they won't cancel my app for any reason (they reserve that right), there is (or was) no appeals process. And if their servers go down, they go out of business, or change focus of their business then my products stop working.

    The Imp is an interesting solution for the hobby market, and may be interesting if you are large company and willing to license the right to run your own servers. But if you are a small or medium size organization, the Imp carries with it a large number of down sides.



  • indeed you do make good points. The products showed up at Home Depot just in the last few weeks. They are prominently displayed on the endcap of the aisles - two different stores that I visited in Wisconsin.

    I guess the other issues might be just standard practices in business. Nobody ever knows the price that others pay for a service. Apple likely gets huge discounts for mass purchases of parts but we and others will not hear about this.

    It is an interesting point that there is sort of a donut-hole in their service. A company willing to run their own servers might also be big enough to do all the hardware and network infrastructure themselves. (for example the company I work for). Smaller companies may rightly be worried about the risks of the imp company service suddenly not being available and this being out of their control.
  • Some companies believe in obscuring prices for enterprise services (because that is what Imp is offering) but that is far from a rule. And it is a practice — the lack of transparency in pricing — I find unuseful and try and discourage.

    There are plenty of small and medium sized companies that are willing to host their own servers. Indeed I have to for the web based components of the services anyway. My tiny little venture is more than happy to, but their prices are far out of line with what I can spend. So much to that it is easier and cheaper for me to just use other options.

    But here is the other thing, half of the things I am working on don't even need their servers, but if you use the Imp you are forced to. All traffic goes through there servers and there is no way around this.

    I just need a web capable module, and an easy way to configure the wifi info. This is what I mean when I said that their vision is too all encompassing. If I want to base a product on the Imp, I have to pay them a per user per month fee, I have to use their servers, I have to run all my users data though it, I have to trust they won't cancel my apps for any reason (because the last time I checked they had that right), etc.

    It is all or nothing for Imp, and my private conversations with them have included statements that I don't need to worry what would happen if they go out of business because they won't fail.

    The Imp would have been a brilliant product if they sold it as a hardware product you could use with your own servers, and then could have an optional service component. Most people would still have gone for their services, but it would answer the problems of people who don't need them or can't use them for other reasons.

    These days, I use a mix of technologies based on what I need. For localize wireless I mostly use ZigBee or Nordic's Bluetooth LE solution, and for wifi I have been using Hi-Link's Router modules with a customize distro.

    They aren't solutions for everyone, but I don't have to pass on monthly fees to my customers for servers I don't need (or want). I have clarity in pricing. And most importantly, if my suppliers go out of business, my customer's products keep working.
  • To be clear - nobody is running their own imp servers. The products you see in Best Buy and Home Depot are running on our servers, and there are now *hundreds of thousands* of imp-enabled products built, and it's very early days in terms of product availability.

    These customers believe in our solution, and believe that we'll be around to support it. Obviously, you don't have to believe in us, and that's your prerogative, but classing us or our service as hobbyist is, fortunately for us, significantly off-base.

    On pricing: we have a standard price sheet, which sales will send you if you ask them. It's not posted on our website, but it's a standard sheet. If you're an huge customer, or need something out of the ordinary, then yes there can be flexibility - but it would be most unusual (I've never, ever, seen it) for any company to perform negotiations with significant customers in public.

    As I've noted many times before, electric imp is not in the business of making wifi modules. We make a connectivity service, which just happens to go right from hardware to the cloud. It's tightly integrated, with really easy messaging between the two VMs. Do we make the most kick-ass wifi module out there? Why, yes we do. But no, we're not selling it to you on its own because we're not a hardware company.

    The imp does run code without a network (=server) connection. This has been the case since release 25.2, which is what everyone has been running from ~July. You can turn wifi on and off under program control. The only remaining hole here is that it needs to talk to the server on every boot to check for new firmware - this is addressed in release 27 which is due out very shortly, it's been in testing with various customers for the last month. This release will run code from a cold boot even if the network (=server) connection is not available.

    Not sure about "the glacial pace of communication". The offline mode has been discussed extensively in many threads on the forum recently - just not this one. Our new website has more information about everything from new APIs to factory processes, too.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID