We’re really in the final phase of finishing moto – at least from a technical side. Our friends at SNK (Kathi) has produced an awesome arch poster which I mainly wanted to share with that post:
To recap: the main purpose of #hybrislabs moto is to figure out how BLE devices in the retail space can be connected to the internet via the employees in the retail space themselves – via an app on a smartphone. This is an interesting topology that we have not touched yet. Soe there is no hub, the smartphone apps of employees will take over that part. The things get connected based on reachability from an employees phone. While we did lot’s of things (including NFC etc) on mobile devices already, we never implemented a true BLE/MQTT gateway as a smarphone app. I am really happy we’ve fixed that.
By the way – have you discovered Bluz on Kickstarter? Same idea. The bluz hardware is connected to the Spark Cloud (which gives RESTful APIs, webhooks, data logging, etc.) via a gateway app which lives on a smartphone. Really the same idea, our implementation is a bit more narrow and probably not as generic as theirs.
Some more news:
- Namespaces: the app now operates under a namespace. So all employees of Store X can use the namespace X. That means all connected things will report/forward events/commands under the appropriate namespace to the server. The server now also has namespaced UIs, e.g. a /groups/default path will present the connected motos for that namespace.
- Webhooks: for each namespace, webhooks can be set up. A webhook is a callback mechanism for all 3rd party or harder to integrate systems that can only speak HTTP. Instead of accessing our MQTT broker directly (which requires port and protocol access, tricky in especially enterpise environments) a webhook can deliver the events from things connected via a HTTP Post request with JSON data as a payload. Works amazingly well and solves most of your integration problems.
- REST API: while webhooks solve the problem to report events to legacy or third-part HTTP-based systems, the REST API allows other systems to access the thigns, e.g. allows them to send commands down to the device. We’ve created a simple REST API that will forward the requests to the MQTT broker, which then talks to all subscribers (e.g. the smartphoen apps that finally will relay all that to the thigns via BLE).
While I am visiting ThingsCon in Berlin, I hope we’ll have some progress on the web UIs and hardware side to share soon. I expect new hardware next week, as well as an updated web UI. A few more iterations with our awesome friends at SNK and DerGrueneFisch. And we should be ready to show the final version. Enjoy.