This page last changed on Jun 02, 2014 by atamariya.

The technology landscape is changing fast and for good. With HTML5 becoming standard and protocols for M2M like MQTT getting wider acceptance, it's about time OR was redesigned. I've done a PoC with these components and am excited with the outcome.

The framework consists of the following:

  • Lightweight HTML5 client with only MQTT JS library dependency. This allows easy customization of UI with simple HTML and CSS. It uses Websockets to communicate with broker.
  • MQTT broker. I used HiveMQ (27 MB). Any other MQTT broker supporting websockets, even cloud based, would do.
  • Device client based on MQTT API. I used Java API. However, C API is also available which can be used to run the logic in low-powered microcontroller; or Python API running on RPi. This involves two Java classes:
    • SerialClient - Interacts with device implementing device specific calls for 0 , 1 and range messages
    • TestDevice - Interacts with broker and SerialClient

This design allows limiting the amount of code deployed on a resource starved device instead of using one-size fits all approach which is bulky and difficult to customize.

Also, the framework supports the idea of hierarchy of devices. So if a device is published at topic/home/room1/lights1 (A) and another at topic/home/room1 (B), then turning off B in the UI would turn off both A AND B.

Let me know if anybody is interested in taking this forward.

Code: https://github.com/atamariya/iot
Video: http://youtu.be/yqLjVDUZzhA

How does your "redesigned" OR relate to existing installations of e.g. KNX, X10, Z-Wave ?

Posted by pz1 at Jun 02, 2014 09:33

OR has existing implementation for almost all the protocols out there. With little bit of modification (pick the protocols you need), generate a JAR and one is ready with the setup. But that is only if OR team wants to go this route.

Posted by atamariya at Jun 02, 2014 14:36

Nothing stopping an HTML5 client at the moment. The controller/console API is well documented and uses long polling (as apposed to websockets). There is a web client but I believe it relies on GWT. The OR controller could probably be easily modified to support websockets. Problem is that all devices don't support websockets (think older mobile devices).

Personally, I use the OR consoles (android, iphone) and the designer (very nice!) but I made my own backend with Perl & XMPP (pubsub) to replace the controller. It is pretty custom so not really for general use. Some might argue XMPP is way too heavyweight for this, but I like it.
a) Server to server connections (think cloud vs local). I can have data grabbers in the cloud that communicate to a local XMPP server.
b) presence (I known when a data grabber fails).
c) runs over TCP (less worries about data loss). Also has auto-retry if a link fails and comes back up.
d) My data grabbers are small. For example: one script would grab temperatures via OWFS and send the results via XMPP. Of course, these are run on full fledged linux boxes and not on microcontrollers.

XMPP is certainly not for small devices as the XML processing is large. That said, some of the IoT devices out there have pretty hefty processors. For example, Belkin WeMo lineup uses UPnP which would have similar processing requirements as XMPP.

Posted by mdarwin at Jun 02, 2014 18:24

Martin, that's some good thought. Of course there are multiple ways of doing this and people with programming knowledge can always come up with their own solution. However, I just wanted to put up some ideas for discussion which use widely accepted standards so that we have minimal need for customization and do not re-invent the wheel.

I see that we do need a multi-tier architecture.

  • OR designer is indeed nice. However, for simplistic scenarios, it's an overkill. If I am just starting up and have only couple of devices, I'd like them to appear in the controller without doing any work (auto-discovery). Switching on/off or sensor readings is basic functionality; adding scenes will involve work.
  • Your data grabbers are an example of how I'd describe my device clients - they are small and provide the API to interact with devices.
  • A backend with server to server communication capability (XMPP/MQTT based).
Posted by atamariya at Jun 03, 2014 05:08
Document generated by Confluence on Jun 05, 2016 09:37