Access via IP rather than through agent.electricimp.com

In the getting started there is the example of turning the led on and off by placing this in your browser.
https://agent.electricimp.com/xxxxxxxxxxxxxxx?led=1
https://agent.electricimp.com/xxxxxxxxxxxxxxx?led=0

Is there another way around using https://agent.electricimp.com to directly talk to the device.
such as taking the device IP address and using that. such as:
https://192.168.0.11?led=1
https://192.168.0.11?led=0

I’m afraid not. The device communicates only with its agent, which acts as a go-between (though it can do a whole lot more). This is primarily for security: in part, it ensures that compromised systems behind the firewall can’t access the device. Only a device’s unique, personal agent can talk to it.

I understand. To bad for me though as all of my customers that we have will not allow outbound and inbound communication to the internet. Their LAN is private for security reasons. Darn it! This was such a cool device too.

Well, in that case the imp would not have worked at all for them - it needs to talk to the servers to get code. Agent URLs would have been a second order problem :slight_smile:

The imp does not require ports opened in the firewall though. It will tunnel outbound to the internet, and then use that to transfer data in both directions. This is usually supported by networks, otherwise it’s, well, rather hard to use the internet at all.

it needs to talk to the servers to get code
well ya, but since the product is not developed on site, which it usually never is is not a problem.

It’s absolutely a problem if you want to manage the code when deployed, which is one of our main selling points. You can remotely manage all the devices in the field, push upgrades, monitor performance, etc.

If you’re putting something behind a firewall that allows zero internet access, and are quite happy with having no remote management, then there are a lot of generic wifi solutions that will work for you - and they’ve existed for many years.

Hugo, when you start getting into large corporations you will discover rather quickly that remote updates are forbidden. For us this is not a perk, its a vulnerability. I do also see that for many others this is a great advantage as well. Not all situations are the same.

I think that there is a tradeoff here. Forbidding remote updates has the advantages of a more robust product and confidence that it won’t change. But, it also carries the disadvantages of a slower development cycle and often less functionality, because extra functionality equals extra risk.

However, you forget the value of feedback. In our case, the imp devices we use constantly stream back diagnostic info. This helps us to monitor and rapidly improve the product. We wouldn’t get that if the devices were behind walls.

Corporations that lock everything down sacrifice responsiveness for peace of mind.

Don’t get me wrong guys, I am not saying that the IMP is bad in any way or has a disadvantage. In the 30 years I have been developing embedded hardware/software I never had the need for remote updates. Many devices I use have this feature, and before shipping to customer this feature is disabled.

Not that what I say here will sway your customers of course, @seulater, but we are well aware of this and architected the Electric Imp Platform’s security very specifically so that remote updates don’t need to be disabled just prior to shipping. If you ever need material from us to help you convince a customer of this, let us know. @Hugo’s your man if you need to know more now.

No company ever wants to be faced with a mass product recall due to some software malfunction. I believe this is one of the drivers behind IOT and why IOT has grabbed the attention of CTO’s is that it now provides a reliable connectivity platform for devices and it will save the business money by having the means to deploy firmware updates remotely and with much fewer (upload) problems.

I believe what you see already happening with smartphone apps will soon migrate to “things” where firmware updates for devices/things will happen on an ongoing and very regular basis. It will allow products to get to market much quicker than ever before.

@smittytone, I will keep that in mind. It’s just that all of my customers with the exception of 2 have no access to the internet. In that it’s more than just behind a firewall, there is no actual cable connection. The internal LAN is totally isolated from outside world. Should some device need to get an update, or something of this nature, then its unplugged, brought to a tech room on a whole different lan which does have internet. It gets updated, then brought back to isolated lan.

If they’re physically disconnected, that’s clearly that. I’d assumed they’d just firewalled it shut. How anyone does business/research/whatever in this day and age without at least web access is beyond me. You have my sympathy!

@smittytone.

To be honest, I like it to work with customers in these environments.
May sound silly at first I know. It did to me too many years ago.
I’ll give you one example. Take for instance a 911 center. All the equipment that is in there is quite impressive. Not to mention all the 2-way radio’s systems in there to talk to all the firehouses. All that part of the building and it equipment has its own LAN disconnected from the internet which is what makes it secure. The other side of the building where supervisors and so on have their own LAN which does have internet access. It would be a nightmare if the equipment side had access and someone hacked it.

The other reason why I like it this way is that you never have to be concerned that someone will run attack on your device and bring it down, or screw with it.

@gerriko, I have to humbly disagree with this statement.

I believe this is one of the drivers behind IOT and why IOT has grabbed the attention of CTO's

Almost every device that is either Wi-Fi or Ethernet cable enabled has the ability to get a firmware update. It has been like this for many, many years. IoT brought nothing to the table to help in this regard. What IoT did bring to the table that made it explode is the compact size, low power & Wi-Fi / bluetooth / cellular.

It been my experience that far to many software developers spend more time testing it’s functionality than trying to break it. After one gets it working the way they want the next focus should be trying to break it by doing things out of the norm from what anyone would do, or anything that typically would happen. This is where most software guys fail. Once they get it working, they are so dam excited to get it out that they never try to break it. This is why there is so much crappy software out there today that breaks all the time.

What I think @seulater may be describing is typical of an industrial SCADA setup where you never allow any outside access to a LAN. As to whether the so called Industrial IOT will change this is anyones guess as it is a very real risk.

I believe in these types of industrial network setup it is very difficult to handle firmware upgrades as my experience has found that when trying to do this using manual plugins such as usb sticks, flash drives etc. do not prevent virus / malware from causing havoc.

So I don’t think there is an easy answer other than very strong authentication methods combined with hardware encryption chips for verification (as imp have done to a degree using ATSHA chip) or do not allow access at all.

IOT in my view is more about 24/7 connectivity, than the enablers which you correctly described as

What IoT did bring to the table that made it explode is the compact size, low power & Wi-Fi / bluetooth / cellular.

So in response to @seulater’s comment I do not believe this is IOT

Almost every device that is either Wi-Fi or Ethernet cable enabled has the ability to get a firmware update.
as the device is not connected centrally and user intervention is always required to manually seek out the firmware to upload (more often than not the firmware has to be downloaded onto a computer / flash drive before it uploads onto the device). This is the big change.

I concur with @seulater that in the effort save money (or more typically when the budget has run out) products are more often than not rushed out to market even though they do not work very well. Stress testing is often over looked.

Now this is where I believe IOT will make a difference and where systems such as Imp really help in that the developer / the business can now monitor things out in the field continually (using server logs and other data uploads) to catch errors before hopefully the customer does and to at least get a head start on fixing these on the fly with a quick firmware update… no doubt there will be terms and conditions to handle this sort of thing but I think it will make it so much easier as it no longer requires customers to send support tickets to make the developer aware of the problem in the first place (yes I know IT departments have been doing this for years using SNMP etc. but this is now expanding to other markets).

I think the critical thing here is IoT = connected to “the internet”. The imp is an IoT device. If you’re doing LAN stuff, then it’s not IoT; it may be networking, even internetworking, but it’s not “the internet”.

This explains why the imp doesn’t fit into your usage models - it was never intended to.

We’re in quite a few large corporations already, and more and more of them are moving to cloud-hosted services, but there are always some applications where this doesn’t work (like factories who cannot be dependent on any external resources). For those, we are working on our enterprise server product, which allow enterprises to host locally where required.

@hugo, IoT is not defined by its connection means.
One can use Wi-Fi, cable, or even Cellular. For instance, I can wire up a WIZnet W5100 IC to my IMP to give me a cabled Ethernet connection. Huh… this just idea just gave me my way out of my situation :wink:

I disagree on the definition of IoT; in my mind, IoT is the combination of networked devices and cloud services (usually via RESTful APIs). This is what makes it more powerful and indeed different from what has come before, which was generally devices on local networks talking proprietary protocols to bespoke backends.

…but obviously, not everyone agrees with me on that :slight_smile: