Uploaded image for project: 'Help-Coaches-Desk'
  1. Help-Coaches-Desk
  2. HELC-864

FIWARE.Request.Coach.SOUL-FI.Choosing a hardware environment to work with Fi-Ware

    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

          Activity

          Hide
          fw.ext.user FW External User added a comment -

          Thank you for your help.
          Best Regards
          Bernie Butler

          Show
          fw.ext.user FW External User added a comment - Thank you for your help. Best Regards Bernie Butler
          Hide
          ralli Carlos Ralli Ucendo added a comment -

          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!

          Show
          ralli Carlos Ralli Ucendo added a comment - 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!

            People

            • Assignee:
              sergg Sergio Garcia Gomez
              Reporter:
              fw.ext.user FW External User
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: