I am interested in having EoN Nodes publish and receive messages through the Eclipse Hono MQTT broker. In reading the documentation it seems that the standard MQTT adapter in Eclipse Hono forces the device to publish to either a 'telemetry' topic or an 'event' topic.
This topics do not work with the standardised Sparkplug topic namespaces defined in the Sparkplug specification.
Does Eclipse Hono work "out-of-the-box" with the Sparkplug topics or would a specific MQTT adapter need to be written?
If a specific adapter needs to be written, is there clear documentation on how to do this?
Thank you.
You are right in assuming that Hono's standard MQTT adapter supports the telemetry and event topics for publishing data only. Consequently, Hono does not work out-of-the-box with the Sparkplug topics. Given that Sparkplug is also an Eclipse standardization effort, it might be worth considering adding native support for Sparkplug to the standard MQTT adapter. Otherwise, implementing a dedicated Sparkplug adapter might be an option as well. There are no detailed instructions for how to implement a protocol adapter. However, the MQTT adapter in particular can serve as a blue print for doing so. It is already split up into a (generic) base class which provides means to forward messages from devices to downstream applications and vice versa.
The Kura adapter simply extends this base MQTT adapter class and implements a different Kura-specific topic scheme on top of it. So, in general, this might be a good approach to take for a Sparkplug adapter as well.
An alternative to a new protocol adapter could be a Protocol Gateway, depending on the use case. The Hono Extras repository contains a template for creating custom MQTT protocol gateways and a sample implementation of this template.
Related
I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.
I’m using the custom gatt package found in movesense-device-lib/samples/bin/release/Movesense-custom_gattsvc_app_w_bootloader.zip for my project. I can't create my own package since there's a bug in the mac compiler.
I really need to the service and characteristic UUIDs for ECG (in fact if I could get the services/characteristics of the other features in the package that’d be great too)
There're links to a sites that give the uuid for certain characteristics and services, such as these ones:
GATT Services
GATT Characteristics
Unfortunately, since the movesense package is custom made, it uses different UUIDs. I tried backtracing them by writing a function on my client that pulls an arraylist of the services and the characteristics, but no luck :(
The custom_gattsvc_app is a sample app that shows how to use Movesense CustomGATTService to implement your own (or someone elses) GATT service. The sample shows how to do that by implementing the (partial) "Medical Thermometer" GATT service, nothing else.
To access all of the Movesense API over BLE you'll need to use the movesense-mobile-lib or implement your own protocol over your own GATT service. I'm not aware of any 3rd party ECG GATT service specifications.
The movesense-device-lib release 2.0 will include a sample that provides access to most of the Movesense API services and easy expansion over a simple GATT protocol.
Full Disclosure: I work for the Movesense team
node-red-contrib-homekit is a slick way to create virtual HomeKit devices in Node-RED, providing a bridge to non-HomeKit-aware hardware.
When it is time for my Node-RED flows to talk to real HomeKit devices, however, it seems to get messy.
To control a HomeKit device (thermostat, outlet, bulb, occupancy sensor, etc.) from a Node-RED flow, the most elegant solution I know of is to install Homebridge and something like homebridge-mqtt alongside Node-RED, which feels to me like a big, awkward hammer.
I feel like I'm missing something--is there a more direct approach? Or am I doing it in an advisable way?
As far as I know, there is no way to talk from Node-RED to HomeKit enabled devices using the HomeKit protocol. Apple only publish the specs for client devices and services, but the HomeKit server, and therefore UI, can only be iOS device. You can think of HomeKit as the Apple alternative to Node-RED. And the control can only be one way - from Homekit to Node-RED. You can make the data flow both ways though. For instance you can create virtual HomeKit switch in Node-RED, that the Home app can control using automation (like turning on when you're home). Thus you can have binary communication between them.
The protocol actually specifies a set of predefined accessories with their options and capabilities, and each manufacturer should provide API for the selected accessory. One physical device can have multiple virtual accessories - like temp and humidity sensors, that are shown as two items in Home app, but might be one actual device.
You need to use your iPhone/iPad to add and control the bridge/accessories, that you can create in Node-RED or are licensed HomeKit devices. But they are not able to talk to each other using that protocol. You'd have to find alternative way for doing this by looking for another API by the manufacturer. For instance Hue is certified as HomeKit and you can add it to your Home app directly, but if you want to control it with Node-RED you'd need their other API as the HomeKit server is proprietary.
Also for Node-RED use the updated node-red-contrib-homekit-bridged that can simplify your management.
I’m in the process of changing my setup from the node-red Homekit node to a separate Homebridge with the MQTT plugin myself. Not only because it is more elegant but also more flexible HomeKit-wise, provides a “separation of concerns” between processes running, and also let’s me just add one bridge to Home app.
There’s also a websocket plugin for Homebridge which also plays nice with node-red but as I have a mosquitto MQTT broker running anyway I might as well use the “language of IoT”.
I am in the process of connecting Homekit related devices and services with Node-RED using Homebridge. Both Homebridge and Node-RED can be installed on the same machine (a Pi).
There are several plugins available to connect Homebridge with Node-RED and maybe you can create a flow that then controls your devices for which you also have to find a plugin in Node-RED. It may be a bit over engineered as there are tons of plugins available for Homebridge directly but using Node-RED is much more fun. The MQTT way is also a good start but I didn't want to mess with protocols and stuff.
AllJoyn and MQTT are both open source projects for Internet of Things interoperability, both provide an event bus and a router/broker to connect devices. What is the difference? Are they compatible? Which standard should I use to implement my future-proof IoT device?
AllSeen Alliance's AllJoyn project is open source proximal IoT. It is usually a mesh topology.
MQTT is open source cloud IoT that works well on mobile and satellite networks. It is pub/sub with topics.
They are complementary, in fact IBM is working on a MQTT plug-in for AllJoyn's gateway agent.
You can read about that in AllJoyn Adds Human Touch to the Internet of Things. However, it seems that AllJoyn to be younger that MQTT, so for the second protocol is possible to found more documentation and frameworks.
We are building a windows-ce (6.0R3) based device that requires guaranteed and audit-ready message delivery (including store & forward) up to and down from the cloud.
I have been looking for choices beyond:
MSMQ
a proprietary solution (what our
prototype device is using)
AMQP (I have not found any RabbitMQ clients for CE, by example)
... are there any others?
We will be transporting sensitive data (who isn't?!?!) over a public network, and large scale options are required. Anything running on an embedded device will be performance sensitive too.
Apache Qpid (http://qpid.apache.org) has a C++ client that I ported to Windows; it could also be ported to CE without much trouble. Apache Qpid C++ runs AMQP 0-10; if you require interop with RabbitMQ broker (AMQP 0-8?), this may be a problem.