The issue has been emailed:
- Time sent: 28/Aug/15 11:52 AM
- To: bernie@mallorcamyplace.com
- with subject: *(
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!
extRequest
Major
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!