Skip to content
Iotivity client package for Dart
Dart
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
bin Dart 2.0 updates Sep 6, 2018
configuration Dart 2.0 updates Sep 6, 2018
example
lib Dart 2.0 updates Sep 6, 2018
test Dart 2.0 updates Sep 6, 2018
.gitignore
AUTHORS Prep for 0.0.1 release, pubspec, AUTHORS Oct 5, 2015
CHANGELOG.md Dart 2.0 updates Sep 6, 2018
LICENSE Initial commit Aug 28, 2015
README.md Prep for 0.1.0 release Dec 14, 2015
analysis_options.yaml Dart 2.0 updates Sep 6, 2018
pubspec.yaml Dart 2.0 updates Sep 6, 2018

README.md

Dartivity

An Iot client package for Dart.

Dartivity is a server side IOT client for Dart that wraps various existing IOT clients and uses Googles pub/sub service as a messaging backbone to allow IOT device discovery, control and reporting.

The intention is that the package provide a common interface to as many IOT clients as possible, allowing reporting and control of these clients through a web site that simply listens to and generates pub/sub messages ie it has nor needs any knowledge of how many Dartivity clients exist, where they are or what devices they control. This information is garnered from the Dartivity clients using a simple ARP like whohas/ihave protocol.

Currently the package supports the Iotivity IOT client, however other IOT clients will be supported, e.g MQTT support will be added in a later release. Also, currently only device discovery is supported, device control(PUT/GET) will be added in a later release.

The package depends on an async native extension that binds to the C/C++ API's of these clients where needed, this extension is developed separatley and can be found here.

The package also depends on other members of the dartivity suite such as dartivity_messaging for the messaging component and dartivity_database for the database and resource management component.

Design

The client is designed to run all the time, i.e. it is an active client with its own housekeeping heartbeat, the only interface to the outside world from the platform the client runs on is through the Google pub/sub service. This gives a system design whereby a(or many) web site(s) can listen to the pub/sub messages to provide control and monitoring facilities to operators. Clients can run on any supported platforms, multi-client per platform is also supported.

The messaging protocol is as simple as possible, using an ARP like whohas/ihave protocol, a simple example would be as follows :-

  1. A Dartivity web site is running on a webserver and is listening to Dartivity client messages, in initial releases the clients are not active in that they will only respond to requests, not generate information asynchronously, however this facility will be added in later releases.

  2. An operator wishes to see all thermostat IOT devices and issues a 'whoHas' message, all the clients recieve this message and perform local device discovery, any clients that find the requested devices reply with a 'Ihave' message containing the device details

  3. The web site then populates a web page/database backend with this information either from the received messages(live mode) or form the database(historic mode).

  4. Once devices have been discovered control operations can be performed, such as set temperature, switch on/off etc. (Not yet, see above). Also platform information is harvesetd, what the client id is(unique to the client), what platform it is running on etc.

This gives a highly decoupled structure, the web site is not dependant on any specific clients, the clients themselves do not need a built in webserver, the clients are standalone, they neither know of nor expect any other clients to be present, nor indeed do they require any web sites to be present.

Testing

The test directory provies unit tests and standalone test for messging only, client IOT device only and both modes. To run the IOT device tests suitable IOT servers need to be present such as the Iotovity projects 'simpleserver'' somewhere on your test network. Also, you need a working pub/sub 'pull' account. Please inspect the various files in the test directory for API usage and client configuration.

Roadmap

Next to do is a simple web site to show the IOT devices and allow on demand device discovery, its then a simple!! matter of expanding the client facilities to add other IOT interfaces(MQTT et al), control and finally device observability and presence monitoring. Also documentation is needed on client usage and configuration.

You can’t perform that action at this time.