I have an external MQTT broker and I would like Google IoT cloud platform to subscribe to the broker.
Most of Google IoT examples are written around the Google IoT platform broker, but my broker is external on another platform.
What Google Iot code, methods can you suggest.
I can already verify with MQTT FX program the external broker is working.
You don't.
If you want to send data to the Google IoT platform that is already being published to your broker, then you need to set up a bridge from that broker to the Google IoT platform.
This will need to have the bridge authenticate to the Google IoT platform.
How you set up the bridge will be specific to the type of broker you are already using. E.g. instructions for setting up a bridge with mosquitto are here
Related
I have some devices connected in the AWS IoT-Core MQTT broker that I want to use the QoS 2 flag.
It seems that the AWS documentation probably is not updated yet. Here we see that QoS 2 is not available yet.
AWS IoT and the AWS IoT Device SDKs support the MQTT Quality of Service (QoS) levels 0 and 1. The MQTT protocol defines a third level of QoS, level 2, but AWS IoT does not support it. Only the MQTT protocol supports the QoS feature. HTTPS supports QoS by passing a query string parameter ?qos=qos where the value can be 0 or 1.
By the most recent (3 weekes ago) IoT AWS training, we can see that the QoS 2 messages is assured delivery:
My question is if the message is assured delivery and the receptor is a Lambda or any other service in the cloud, and let's say that for some moment the service is out, do qe have a guarantee that the message will be consumed when the lambda or the service is available?
There is a kafka connect connector for iothub. This is available from the confluent website (https://www.confluent.io/hub/microsoft/kafka-connect-iothub). However, the iothub connector in kafka connect is archived (see https://github.com/Azure/toketi-kafka-connect-iothub) and the last commit dates from 2018-03-19.
In the meantime the plugin does not work with the current version and needs to be updated.
Is there an alternative repo available. Did microsoft stop supporting this? Is there a plan?
The Kafka connector project for communicating with IoT devices is indeed retired.
If only one-way is desired, Event Hubs does have a Kafka compatibility layer and IoT Hub message routing can be used to take advantage of that scenario.
You can reach out via Azure Support Request if you are looking for other alternatives and we can share our roadmap under NDA. When you open the Azure Ticket, reference this SO thread.
I am trying to send data to Azure IoT Hub from Apache NiFi. Using Publish MQTT processor I am trying to publish data. Is this a right approach to send a data from NiFi to IoT Hub? Is there any other way?
You can use the MQTT protocol directly (as a device) to send and receive data from Azure IoT Hub - like described here: https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support#using-the-mqtt-protocol-directly-as-a-device
As long as you can connect over TLS/SSL you should be fine.
I collect data from the LoRa node, and then gateway forward to lora server, at last, the data to the lora app server. but i cannot find the following interface.
(https://docs.loraserver.io/lora-app-server/integrate/data/)
enter image description here
You need to implement a MQTT client (or user a command-line one, like mosquitto_sub, as suggested in https://docs.loraserver.io/lora-app-server/integrate/data/) and then subscribe to the receiving topic for the specified node. The image you posted is not an interface but an example message a node will send through the topic. For the case given, appID is "123" and devEUI is "0202020202020202", so you need to subscribe to the following topic to get messages from the node:
application/123/node/0202020202020202/rx
As said, you may consume the messages through a MQTT client (there are plenty of clients for different languages), or from the command line.
Just updating from current versions.
Global integrations
Global integrations are configured through the lora-app-server.toml configuration file and are globally enabled. This means that for every application configured, the application will be published using this / these integration(s).
The following integrations are available:
MQTT
AWS Simple Notification Service
Azure Service Bus
Google Cloud Platform Pub/Sub
Application integrations
Additional to the globally enabled integrations, it is also possible to set up integrations per application.
The following integrations are available:
HTTP
InfluxDB
From: loraserver.io
I have a regular cloud server set up, I have a mobile app talking to the server via HTTP requests. I also have a Wifi device that I need to send messages and I want to do that over MQTT. When some change happens on the mobile app, I want the cloud server to publish a topic via MQTT so that the wifi device can receive the message. Can a broker also be a client? Am I understanding it wrong?
I'm going to attempt an answer based on my understanding; sorry if I misunderstood your question.
The way I understand it, you will have three/four pieces of software:
HTTP Server / MQTT Broker (these two services could run in the
same application or in separate ones)
Mobile application (communicates over HTTP)
Wifi Device (communicates using MQTT protocol)
Scenario:
The Wifi device will open a connection to the MQTT Broker and subscribe to a well defined topic. You can use a subscription with a QoS of 1 if you cannot afford to lose the messages. Any messages published prior to adding the subscription will not be received by your client. It might also be useful to open an MQTT connection using a non-clean session if your wifi connection is unstable (again, if you don't want to lose any messages).
After a specific event, the mobile application which communicates with the HTTP server will send it information.
Upon reception of the information, the HTTP server will then send an MQTT message to the MQTT Broker on the predefined topic (a topic that will match the Wifi Device's subscription).
The MQTT broker will relay the message from the HTTP Server to the Wifi Device (and any other MQTT clients with a matching subscription).
I hope this clarifies, let me know if anything is unclear.
"Can a broker also be a client?" Not really, although I'm certain some specific brokers will publish messages to special subscriptions based on special events, it only acts as a broker. It receives messages from publishers and forwards messages to any client who has shown interest in that message using a subscription (the message could potentially be dropped by the broker if no subscriber (client) is interested in that message).