Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Major
-
Resolution: Done
-
Component/s: SOUL-FI
-
Labels:None
Description
Hi Fi-Ware help,
Our Soul-Fi Phase B application has recently been accepted for funding
and we are now looking for a suitable IoT hardware development
environment. We have significant programming and electronic design
capability, but no practical hands on experience with the Internet of
Things and Fi-Ware.
Our project will require us to interface with an electromechanical
device, camera, microphone, speaker and a number of sensors. We will
obviously also want to communicate and store data to the Fi-Ware cloud
and utilise Fi-Ware enablers in our configuration.
Currently we are looking at Raspberry Pi, Arduino, Netduino and
Microsoft Gadgeteer to set up our first prototype breadboard system. At
this stage price is not the main consideration, what is important is
that the system we choose provides a fast-track into IoT and gets a
prototype up and
running quickly so that we can confirm the feasibility of the design. We
only have six months to achieve a result after we finalised the
contracts and get a start date for the project. We don't want to
reinvent the wheel, so to speak, and so any advice you can give us in
choosing the best hardware to build our prototype and interface with
Fi-Ware would be most gratefully received.
With Kind Regards
Bernie Butler.
_______________________________________________
Fiware-lab-help mailing list
Fiware-lab-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-lab-help
[Created via e-mail received from: bernie@mallorcamyplace.com]
Issue Links
- relates to
-
HELP-4560
FIWARE.Request.Tech.IoT.IDAS.[Fiware-lab-help] Choosing a hardware environment to work with Fi-Ware
-
- Closed
-
Activity
Thank you for your help.
Best Regards
Bernie Butler
The issue has been emailed:
HELC-864) [Fiware-lab-help] Choosing a hardware environment to work with Fi-Ware *Hi,
In order to connect things to FIWARE you need first to decide which IoT communication protocol you will use from the following 4 options:
1) UL2.0. Pros: It is very simple itself and easy for coders as it is based on HTTP POST simple interactions. Cons: UL2.0 is not a standard per-se but an open specification of a simplification of SensorML used by FIWARE ecosystem/platforms.
2) MQTT. Pros: It is a full standard, widely used in many platforms and solves quite well bidirectionality when behind NATed networks. Cons: all MQTT implementations have minor propietary definitions (so it is portable from platform to platform but needs a minimum work) and it is more complex.
3) OMA LWM2M/CoAP. Pros: a full standard, widely used by many platforms, the only one suitable for really constrained devices. Cons: more complex and uses REST over UDP so programmers might be less aware.
4) SIGFOX protocol. Pros: commercial very cheap devcies. Cons: locked to SIGFOX technology.
The decision above will determine the hardware options to some extend:
A) For instance, if you decide to go for UL2.0 (the most simple and widely used by FIWARE beginners) you actually can use almost any HW able to send very simple HTTP requests.
That includes Arduino but you will have to code the HTTP calls yourself.
With RaspberryPI and any other python-capable system you may use the FIGWAY scripts that will make your life quite simple.
I like RaspberryPI for prototyping but I cannot say it is better other siwht similar computing capacity are worse.
FIGWAY is at:
https://github.com/telefonicaid/fiware-figway/tree/master/python-IDAS4
If you are using a system not able to run python or you want to do it yourself, the following .pptx has all necessary HTTP requests:
http://www.slideshare.net/FI-WARE/fiware-iotidasintroul20v2
B) If you choose MQTT then I would personally not use Arduino but something more powerful and with an existent MQTT client (I know RaspberryPI has MQTT clients).
C) If you choose LWM2M, you may use even the most simple (constrained) devices and there is a guide here:
http://www.slideshare.net/dmoranj/fiware-developers-week-iot-advanced (LWM2M is at the Backup Slides)
Given all the information above. I would try first to prototype with RaspberryPI as a gateway for your devices. Default option should be then to use FIGWAY python scripts that later you can modify on your own (remember also that they will work also in any other hw system able to run python so raspberryPI is just a personal preference from my side for prototyping).
If bidirectionality is key and UL2.0 polling mode is not enough then consider MQTT. If you want to connect really constraint devices too in a very standard way think on LWM2M/CoAP.
Arduino is not a bad option if you really think it fits your needs and you are considering UL2.0 or LWM2M.
I hope all this helps.
Thanks for sing IDAS!