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.
Related
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.
I'm making a temperature, humidity and moisture sensor system where data should be sent over to Iot hub (Cloud) every second. I have used an Arduino and Ethernet shield.
I'm able to create sensor data every second. It sends this data to the IoT hub directly from Arduino without a Raspberry Pi or PC|VS Studio. I have already created a job stream on Azure as well. Is there any mechanism with which I could send this data to Azure IoT hub directly? Thanks in advance.
You can look at the libraries for IoT Hub here:
Azure IOT SDK for C
A Quick search on the Arduino site also contains lots of examples of devices connecting to the IoT hub. I imagine you can use both AMQP and also MQTT protocols for this directly from your Arduino. I'm using MQTT in my ESP8266's without VS involved, all written in the Arduino IDE.
You can also find the Azure IoT Arduino libraries here.
Note that required libs (AzureIoTHub, AzureIoTUtility, AzureIoTProtocol_HTTP and AzureIoTProtocol_MQTT) are all published in the Arduino IDE lib manager, so you can just install them from there (no need to clone the repos).
The docs and the samples are not quite up to date (which we'll fix real soon) but you can find an MQTT sample in the MQTT lib repository.
What technologies are recommended when we want to do Device-to-device communication in an IoT Scenario? Does Windows 10 IoT Core have support for this type of communication? Could I use AMQP connections for this?
Device to device communication can happen on multiple levels. Setting up an AMQP server might be feasible using implementations like Apache QPid but this doesn't seem like a responsibility device should be bothered with. You could run an API server on a W10 IoT Core device for other devices to communicate with.
There are specific standards like AllJoyn that lets us communicate device with eachother and Windows IoT Core has native support for this. Take at look at the samples to find out if this fits your scenario: https://developer.microsoft.com/en-us/windows/iot/win10/samples/alljoynjs
I have an Arduino loaded with sensors connected to a Raspberry Pi. The Arduino passes all the data from the sensors to Raspberry.
Now I want to push all of these data in real-time over a socket to a server in the backend, and upload the data into a database.
I'm looking for the most optimal solution for this. Socket.io seems like a popular solution and relies on WebSockets and NodeJS.
Pusher seems like a decent API service that can easily integrate into iOS and Android devices.
What is the best solution out here? It seems like WebSocket is the way to go, but is there a better protocol to use for this purpose?
Check out the MQTT protocol as well. It's becoming widely used for this kind of purpose. You can find both open-source and commercial, as well as cloud-based and self-hosted, MQTT brokers.
so im working on a my bachelor thesis and for that i need to implement, in a smarthome, d2d communication between IoT devices. So i want to implement the usuall server work, like noticing if a device connects/ disconnects etc. to the IoT devices, so no server/hub is needed at home.
But I can't find good solutions for it, for websockets i need a server, for mqtt a broker and so on, but all need a server.
I found that d2d is done with "LTE" similar technology but i would like to do it with web-protocols.
So my question:
Is there a way to let IoT devices talk to each other over the network?
My IoT devices (raspberry pis) currently use nodejs with typescript but I'm not starting a server, they only have a mqtt connection to publish there sensor data to the users.
Thanks in advance.
And if im understanding something wrong, please say it. :)