I’ve just acquired a Fieldbus Gateway device and I have a coulee of questions. This device has both WiFi and wired Ethernet on it, making it a great gateway device, in theory, but … Can it really only run the same kinds of device code applications as any other imp module? It MUST talk to an upstream Agent in the imp cloud to do anything?
I’m trying to devise some demos using this device, and if it really can only run the same device code that any imp module can run, I’m having a hard time with figuring out a use-case for it. It’s in a metal enclosure, so I can’t very well attach sensors to it, and I can’t really see how I can use it to aggregate readings from other imp devices, and I can’t have it forward information directly to a backend system without going through an imp agent.
Yes, it’s an imp. This means it uses the imp device architecture (which gives you maintained device-side OS & security stack, without needing re-integration to ship updates) plus the imp cloud architecture (which gives you easy and secure code deployment, plus a cloud VM which absolutely helps you deliver quicker, higher performance integrations with cloud services).
It doesn’t need to talk to the agent to operate; it runs code locally and will do all the same sort of MCU things that any MCU can do down there. However, you’re correct in that all communications are via the TLS1.2 ECDHE channel to an imp server.
The name “fieldbus accelerator” really says it all - it’s for connecting devices sitting on fieldbuses (eg MODBUS-RTU, MODBUS-TCP, BACnet, etc) to cloud services, securely and easily. It’s not designed for sensors - the battery powered sensor node accelerator is loaded with those.
The physical manifestation of the off the shelf implementation suits who it was designed for - people who are using it to securely connect fieldbus devices to cloud services. If you have a different use case in mind, you can download the cad - it’s open source - and remove/replace/reformat the design to your requirements.
The “traditional” IoT model of edge device (incapable of talking to the internet), gateway (which can manage the internet bit) and cloud service is not necessarily a good thing. For one, it gives you more attack surface, as is regularly demonstrated with almost every linux-based gateway being hacked. Here, the fieldbus gateway is a provably secure endpoint - our platform has been through many customer pentests, plus has UL2900-2-2 certification - which bridges a variety of legacy devices securely to data services.
In the imp model, the “gateway” is essentially virtualized (that’d be the agent) - and so is free from most of the resource constraints of embedded devices. One example is that agents have no problems verifying TLS certificate chains, which is in contrast to the shortcuts that many embedded devices take (no root certs = no way to validate third party services). We have customers who do all sorts of things in the agent (up to and including XML parsing and generation for legacy backend interfacing).
Also bear in mind that if you want data to go through your own servers, that’s our private cloud offering. You get to own your DNS, your TLS CA, signing keys, and so on.
Thanks for that detailed response Hugo! It helps enormously. I guess I’ll have to go out and buy a bunch of MODBUS sensors now to build this demo. BTW, this is a join electric imp/InfluxData demo.
It’s not showing a buy now button but it should be back in stock later this week. This is loaded with sensors (plus can drive external one-wire, i2c, or 3.3v UART devices).
BTW, this is a join electric imp/InfluxData demo.