I sent data to IoT Hub using Mosquitto:
mosquitto_pub <..> -m "mensaje" <..>
I have tested that this message arrive to IoT Hub with "device explorer twin" and also with the CLI
But after that, when I create a stream analytics jobs, the input fail
input
I have tried all kind of formart: CSV, JSON, AVRO and also all king of string format with -m "mensaje" like: {"mensaje":"adios"}
There is no way to do this from the CMD with the command mosquitto_pub?
You can not send the message in JSON/CSV/AVRO format from Mosquitto to Azure so I had to change to other Mosquitto broker and that work without problem
Related
I'm trying to use Seq, which is a tool for logging management, mostly supported in .NET.
There are also tools like seqcli for sending logs to a seq server as shown here:
https://docs.datalust.co/docs/
The thing is, I'm using a springboot App, and according to the docs, I'm using GELF and Seq deployed as docker containers in a remote server. Everything is on Linux.
I managed to send some logs from a file using this command:
./seqcli ingest ../spring-boot-*.log
and I can see them on the remote server, but I'm not able to send logs in realtime. the docs says that I can send logs in real time from STDIN but no more details about it, I have no idea how can I achieve this.
https://docs.datalust.co/docs/command-line-client#extraction-patterns
Any suggestion?
I was digging a little more throughout the docs and I found this:
tail -c 0 -F /var/log/syslog | seqcli ingest
which I converted to this:
tail -c 0 -F ../spring-boot-app.log | ./seqcli ingest
If someone runs into the same problem, look some more here:
https://blog.datalust.co/parsing-plain-text-logs-with-seqcli/
I am sending data stream to AWS kinesis service and want to check if the kinesis received the data. What I expect is real-time output on shell console like redis does:
Wonder if AWS CLI supports features like that.
I have created a topic using node.js and mapped to Message Hub using prototype MessageHub.prototype.topics.create(topic). I want to add an existing Message Hub topic to node.js and consume data from it. Is there any function for this?
#rajeswari
I guess you're using the node.js module that uses Message Hub REST API.
Feel free to have a look at an example using a native Node.js client for Kafka,
https://github.com/ibm-messaging/message-hub-samples/tree/master/kafka-nodejs-console-sample
#rajeswari the topics.create(topicName) call simply requests the topic is created in MessageHub and when its Promise returns the json output response of that request is available.
If you want to retrieve messages from an existing topic, you can just skip that step and proceed directly to creating a ConsumerInstance via MessageHub.prototype.consume and then call MessageHub.ConsumerInstance.prototype.get(topicName) on the returned ConsumerInstance.
I have successfully connected my ESP8266 Arduino project to the Azure IoT hub by following the steps outlined here:
https://azure.microsoft.com/en-gb/documentation/articles/iot-hub-mqtt-support/
The MQTT library that I am using is the following library:
https://github.com/Imroy/pubsubclient
Using the code I have been able to publish events to azure. The problem starts when trying to read the messages that are passed to the device.
Here is the code:
http://pastebin.com/7AVLQfFh
When I sue the Azure Device Explorer to send a message to the device the I get the following results:
As you can see the payload length is the same as the number of characters in the message but the characters are not the same. And also if I vary the string sent then the vales in the result are the same.
As a sanity check I have tried the code against a different MQTT service (Adafruit IO) and the results are as to be expected (here the message is 'ON' or 'OFF'):
The Azure MQTT service must be doing something different when it sends the messages to the device, what I needs to know is what it does differently.
Just a couple of hours ago I managed to get the messages flowing from Azure IoT hub to my ESP8266 using the original PubSubClient - link here. You are using the fork of that library that has been made more object oriented and probably has more enhancements.. but if you aren't very hooked on using the newer version I'd recommend getting the original one and trying it out.
I have my code on github if you need some reference: link
One important mention: the PubSubClient.h needs changing the #defineMQTT_MAX_PACKET_SIZE 128 to #defineMQTT_MAX_PACKET_SIZE 256 or more if you work with big packets
Also, I haven't tried to send any messages so I don't know how that'll work.
Update: I've also written a short blog post on how to set it up: link
According to this documentation page, property_bag is RFC2396 encoded.
RFC 2396-encoded(<PropertyName1>)=RFC 2396-encoded(<PropertyValue1>)&RFC 2396-encoded(<PropertyName2>)=RFC 2396-encoded(<PropertyValue2>)…
But isn't ABCD the same in plain text vs URI encoded you ask... Well, yes.
Install stunnel (https://www.stunnel.org/index.html), open a TLS 1.2 connection to IoT Hub on 8883/TCP and then point MQTT.fx or Paho to it and sniff the traffic with Wireshark, see what you get.
I was able to read all messages in plain ASCII text while talking to IoT Hub over REST, so whatever this is i think it's MQTT specific.
If you haven't done so already you should open an issue on their GitHub. They seem to be quite responsive: https://github.com/Azure/azure-iot-sdks/issues
I have the following situation in Azure IOT Hub:
Script sends message to device queue. Listening with device explorer: Succes
Script listens for message to device queue. Sending with device explorer: Succes
This problem arises:
Script listens for message to device queue. Other script sends message to device queue: Listener does not receive the message.
So, it works well using the device explorer tool. But with the scripts only, the listener does not receive.
I hope someone might be able to help me with this issue.
There might be two possible problems on your side:
a) Device Explorer shows messages only from one device. If you have two separate device clients, you have to select another one.
b) But it's possible that you send and receive on two separate scripts with one deviceId (clientId) - it might be the problem.