Sponsored Content
Top Forums Programming Wuhan Coronavirus Status for China - Rapid Prototype Blynk App with ESP8266 Post 303043594 by Neo on Saturday 1st of February 2020 12:07:24 PM
Old 02-01-2020
The mistake I made in this humanitarian crisis situation was to use Blynk to build a public service app to help others.

I will not make that mistake again.

In addition, I also read the Blynk privacy policy and according to their privacy policy, they can provide the data we use on the Blynk network to third parties, for example Google and FB-like behavioral analytics, where they can partner with data miners and other third parties and user our "behavioral exhaust" without our express written consent.

From Blynk Terms of Use (TOS) policy:

Quote:
By using the [Blynk] Service, you are granting us (and any service providers or Providers used by us) permission to access your account and those messages, data, information, text, graphics, audio, video or other material and content of any kind posted/uploaded/transmitted to or through the Service using your account, to process and submit said material to End Users.
That is a very "radical" TOS statement, to say the least.......

Update:

After looking into this, I found some promising iPhone apps which do not share your data with third parties (in contrast to Blynk) and will test the mosquitto broker to set up a private pub/sub network to send and receive messages to and from these ESP8266 and ESP32 devices.

Quote:
Eclipse Mosquitto is an open source (EPL/EDL licensed) message broker that implements the MQTT protocol versions 5.0, 3.1.1 and 3.1. Mosquitto is lightweight and is suitable for use on all devices from low power single board computers to full servers.

The MQTT protocol provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for Internet of Things messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers.

The Mosquitto project also provides a C library for implementing MQTT clients, and the very popular mosquitto_pub and mosquitto_sub command line MQTT clients.
I have already set up a mosquitto broker on Ubuntu, the basic security authentication and can send a message from my ESP32 device to the remote Linux server. Will discuss this in another post.
This User Gave Thanks to Neo For This Post:
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Function prototype declaration

Hi All, I have the script as below #!bin/bash let k=9 if then echo "Start" Hello echo "End" else echo "failed" fi function Hello() { echo "hello !!!!" } I got the below error : (4 Replies)
Discussion started by: Balasankar
4 Replies

2. Programming

Embarcadero Rapid SQL query for dependency

Team I am using Embarcadero Rapid SQL V8 . When we right click on any procedure/table/view and open the contents. It has dependencies tab, which tell what all are the dependents used . My question is how does this information captured in backend to retrieve the dependency objects in... (0 Replies)
Discussion started by: Perlbaby
0 Replies

3. What is on Your Mind?

Major Changes in New UserCP (v0.63) Prototype

Regarding the latest version of the UserCP prototype (version 0.63) I have made a lot of major changes, including Added a "Posts Timeline" table for the recent posts, complimenting the non-table version earlier, which has been moved off the main menu (link at the bottom of the table). Added a... (4 Replies)
Discussion started by: Neo
4 Replies

4. Programming

NodeMCU ESP8266 Blynk SSL Application for Linux Server Load Averages

Here is a useful SSL (HTTPS) application for anyone with a remote Linux server they want to keep an eye on using Blynk and the NodeMCU ESP8266. This little app also works (have tested as well) on the WeMos D1 ESP8266 Arduino board. The NodeMCU setup could not be easier, just find a... (8 Replies)
Discussion started by: Neo
8 Replies

5. Programming

Wuhan Coronavirus Status App for China - Rapid Prototype using MQTT and the IoT OnOff IOS App

With a little bit of work, was able to build a nice "Wuhan Coronavirus Status" app using MQTT and the IoT-OnOff app. More on this technique here: ESP32 (ESP-WROOM-32) as an MQTT Client Subscribed to Linux Server Load Average Messages The result turned out nice, I think. I like the look and... (10 Replies)
Discussion started by: Neo
10 Replies

6. Programming

A Slightly Better NTP Client for the ESP8266

Was not really happy with the NTP clients for the ESP8266 because, after a few years of game engine programming, I am not a fan of a lot of code and delays in the main loop, so here is a "slightly better NTP client" for the ESP8266. In a nutshell, instead of having a delay in the main loop as a... (1 Reply)
Discussion started by: Neo
1 Replies
mosquitto_sub(1)														  mosquitto_sub(1)

NAME
mosquitto_sub - an mqtt version 3.1 client for subscribing to topics SYNOPSIS
mosquitto_sub [-c] [-d] [-h hostname] [-i client_id] [-I client id prefix] [-k keepalive time] [-p port number] [-q message QoS] [--quiet] [-v] [ -u username [-P password] ] [ --will-topic topic [--will-payload payload] [--will-qos qos] [--will-retain] ] -t message topic ... DESCRIPTION
mosquitto_sub is a simple mqtt version 3.1 client that will subscribe to a topic and print the messages that it receives. OPTIONS
-c, --disable-clean-session Disable the 'clean session' flag. This means that all of the subscriptions for the client will be maintained after it disconnects, along with subsequent QoS 1 and QoS 2 messages that arrive. When the client reconnects, it will receive all of the queued messages. If using this option, it is recommended that the client id is set manually with --id -d, --debug Enable debug messages. -h, --host Specify the host to connect to. Defaults to localhost. -i, --id The id to use for this client. If not given, defaults to mosquitto_sub_ appended with the process id of the client. Cannot be used at the same time as the --id-prefix argument. -I, --id-prefix Provide a prefix that the client id will be built from by appending the process id of the client. This is useful where the broker is using the clientid_prefixes option. Cannot be used at the same time as the --id argument. -k, --keepalive The number of seconds between sending PING commands to the broker for the purposes of informing it we are still connected and func- tioning. Defaults to 60 seconds. -p, --port Connect to the port specified instead of the default 1883. -P, --pw Provide a password to be used for authenticating with the broker. Using this argument without also specifying a username is invalid. This requires a broker that supports MQTT v3.1. See also the --username option. -q, --qos Specify the quality of service desired for the incoming messages, from 0, 1 and 2. Defaults to 0. See mqtt(7) for more information on QoS. The QoS is identical for all topics subscribed to in a single instance of mosquitto_sub. --quiet If this argument is given, no runtime errors will be printed. This excludes any error messages given in case of invalid user input (e.g. using --port without a port). -t, --topic The mqtt topic to subscribe to. See mqtt(7) for more information on mqtt topics. This option may be repeated to subscribe to multiple topics. -u, --username Provide a username to be used for authenticating with the broker. This requires a broker that supports MQTT v3.1. See also the --pw argument. -v, --verbose Print received messages verbosely. With this argument, messages will be printed as "topic payload". When this argument is not given, the messages are printed as "payload". --will-payload Specify a message that will be stored by the broker and sent out if this client disconnects unexpectedly. This must be used in con- junction with --will-topic. --will-qos The QoS to use for the Will. Defaults to 0. This must be used in conjunction with --will-topic. --will-retain If given, if the client disconnects unexpectedly the message sent out will be treated as a retained message. This must be used in conjunction with --will-topic. --will-topic The topic on which to send a Will, in the event that the client disconnects unexpectedly. WILLS
mosquitto_sub can register a message with the broker that will be sent out if it disconnects unexpectedly. See mqtt(7) for more informa- tion. The minimum requirement for this is to use --will-topic to specify which topic the will should be sent out on. This will result in a non- retained, zero length message with QoS 0. Use the --will-retain, --will-payload and --will-qos arguments to modify the other will parameters. EXAMPLES
Note that these really are examples - the subscriptions will work if you run them as shown, but there must be something publishing messages on those topics for you to receive anything. Subscribe to temperature information on localhost with QoS 1: o mosquitto_sub -t sensors/temperature -q 1 Subscribe to hard drive temperature updates on multiple machines/hard drives. This expects each machine to be publishing its hard drive temperature to sensors/machines/HOSTNAME/temperature/HD_NAME. o mosquitto_sub -t sensors/machines/+/temperature/+ Subscribe to all broker status messages: o mosquitto_sub -v -t $SYS/# BUGS
mosquitto_sub bug information can be found at http://launchpad.net/mosquitto SEE ALSO
mqtt(7) mosquitto_pub(1) mosquitto(8) libmosquitto(3) AUTHOR
Roger Light <roger@atchoo.org> 5 February 2012 mosquitto_sub(1)
All times are GMT -4. The time now is 04:14 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy