MQTT is a "messenger" between devices:
your device measures at time T a temperature of X degrees
it connects (itself or via the zwave hub) to the MQTT broker
it create a message with the topic /domotics/myplace/mydevice/temperature
within the message it just puts X (as the "payload")
Elsewhere in your house:
your Raspberry Pi is connected to the MQTT ...
MQ Telemetry Transport Protocol known as MQTT is designed for devices which run on low power and low bandwidth. It is a lightweight publish/subscribe messaging protocol which means any other device can subscribe to a particular topic.
HTTP/HTTPS is designed as a request-response protocol for client-server computing which never bother about power usage and ...
MQTT (Message Queue Telemetry Transport) seems to be well suited for the proposed application.
It is lightweight both with respect to bandwidth (smallest packet size with a header of just 2 bytes) and client code footprint (enabling it to run on thin clients like the ESP8266, typical IoT client). Reduced transmitted data is beneficial to longer battery life ...
SSL/TLS works well when the "server" is at known location (a fixed hostname) that can match the CN of the certificate it presents.
This doesn't work well for device on home networks (e.g. most IoT devices) because they tend to get IP addresses issued from RFC1918 blocks and do not have DNS entries. This means they can not be issued with certificates (well ...
You mention a solar panel and battery as part of the device, so you probably want to minimise the power usage during transmissions to make sure your device doesn't run out of power completely.
Therefore, you might want to consider CoAP, the Constrained Application Protocol, which is specifically designed for constrained devices in the Internet of Things.
If you are storing data, simply stick with HTTP. HTTP is just a one way signal.
If your server or any other "thing" should react to a specific signal (low temperature,...) then use MQTT. Like this many devices can subscribe to your temperature signal and immediately react without using your server.
If the service you use can tolerate some latency, routing the traffic of your device through the TOR network would make the destination address impossible to determine for your ISP, and the source address (home IP) impossible to determine for the ISP of the server your device is communicating with.
If you have only one device in your home, traffic patterns ...
I'm not sure MQTT would really fit your needs well. MQTT has the concept of 'retained messages', kept by the server and sent to clients as soon as they connect. But you can only have one retained message for each topic; not a queue of messages.
If the client is connected to the broker, you can send packets in order and the order is generally preserved (in ...
Here I wrote an article which shows and evolution in communications system we had in our project. It about micro-services, but you can consider any sensor to be micro-service with its job to gather and publish any kind of telemetry data.
So most important conclusion is that it is better to use MQTT when you just need to send event somewhere and you know ...
Parameters to an HTTP GET request are key/value pairs, separated by an ampersand &
The key and value are separated by an equals sign.
Your use of DeviceData=T=<value> breaks this rule.
See this page, which explains that you need to use %3D for the = which is part of the value.
But, ask yourself if you really ...
From what you're asking, I believe you should use MQTT protocol, it seems to fit your architecture. You'll need to have a mqtt server/broker that will receive the data from the device and then send them to the app.
Simply put in MQTT protocol you'd have "topics" that the client (your app) will subscribe to. The device will push it's data to the topic and ...
For devices which are particularly sensitive, a good way to prevent someone from snooping the connection pattern is to generate spoof data, or intentionally skew the connection times (if data need not be uploaded as soon as it is generated).
Importantly, you would need to use static payload sizes, or generate plausibly sized payloads for the dummy data too.
Neither IRC nor HTTP are really optimised for usage as IoT protocols (though they could, in theory, be used).
What makes a protocol suitable for usage in the Internet of Things?
It's difficult to say something meaningful about a huge class of devices, but many IoT devices are small, power-constrained microcontrollers. In order to reduce resource usage (power,...
One possible option is to use HTTPS and ship a real certificate on the device:
Since you control the access point you presumably control the DHCP server on the access point, so you can have it provide a DNS server address at the same time.
This DNS server can be on the AP and can resolve a fully qualified hostname to point to it's self.
You can then ...
What are the steps to the privacy leak described?
Basically there are three parts in getting the information described in the paper.
An interested party recording the outgoing traffic (2)
Said party being able to split the traffic streams (4.1)
Analyzing the different traffic streams
Identifying device (type) (4.2)
Analyzing device pattern (5)
While I like the use of TOR, you might not be able to configure every device to use it.
The simplest way would be to do something at the router, where all traffic, from all devices, enters and exits your house.
I would recommend a VPN router. This will encrypt all data leaving your home, so that no one, even you ISP, can see its destination. Data travels, ...
I would recommend NodeRed .Simple drag and drop visual programming by IBM based on Nodejs .NodeRed can be installed easily using npm (package manager in Nodejs sililar to pip for python).Please read offficial documentation for installation and usage.You can install mqtt broker like mosquitto and add mqtt capability to NodeRED.
Thinger.io is also quiet ...
I agree to Aurora's answer—there may be better solutions to implement queue instead of MQTT, but still in MQTT it is absolutely possible.
You need MQTT broker and clean=false (in MQTT 3.x) or with appropriate expiration period (MQTT 5.0). Then, the logic is pretty straightforward.
You have persistent(but not connected) client session, that is subscribed ...
Yes, it is possible. I have done it before, and there are a few (but not many) situations where using IRC is a good idea.
An example deployment I have done many years ago was a monitoring system for an old factory (nothing critical though). Around 30 sensors were installed and deployed across the buildings, and each sensor was simply dumping the data into a ...
To generalise a little more, IoT has a few general constraints/characteristics which will apply to many but not all use cases:
Potentially many endpoints
Communicate over an insecure or snoopable transport layer
Need to handle deployment and firmware upgrades
Often handling valuable/sensitive data
Automated messaging, frequently small and rapid payloads
Regarding to your quote MQTT is the "protocol of Internet of Things":
Yes, there is a great amount of developers using this protocol (see IoT Developer Survey 2018) but CoAP (it's HTTP adjusted for IoT, based on UDP) provides an alternative for HTTP in case you want to use a lightweight Request/Response functionality within your application.
MQTT on the ...
Another option is ThingSpeak: https://thingspeak.com/
This platform allows you to send data using http request and visualise in graphic yous sensors. Besides, you can create 'alerts' to send a message when some sensor reach an exact value.
You've not said if you want to do client authentication via certificate as well as the usual server validation.
Assuming just server validation then you need to include the Certificate Authority chain to be able to validate the certificate presented by the HTTP server. In this case it would the Lets Encrypt chain which is available from here: https://...
Assuming your Arduino has Wi-Fi, you can send the image using HTTP to a Web Server running on your own computer.
So you would need:
a Wi-Fi shield (or an Arduino with built-in Wi-Fi)
an HTTP client library running on the Arduino
a Web Server running on your computer (I recommend python's Flask)
As for how to encode the image, my suggestion is base64 + ...
You need a bridge/gateway.
From what little I remember from looking at LPWAN Zigbee networks a LONG time ago and assuming I've not got the wrong end of the stick...
Something that will change the physical layer of the network (Zigbee to probably ethernet/wifi) and possibly do NAT (link-local IPv6 to either global unique IPv6 or IPv4)
I also used to run ...
Yes, in many cases pub/sub protocols that are initiated from the device to the cloud (like MQTT) are used.
With things like persistent subscriptions and message queuing for offline clients it means that updates/commands will reach when it comes back online and it provides a way for the device to also publish it's state and any sensor readings back up to the ...
there are several IoT platform that can visualize data in real time and historical information. Almost all support MQTT and HTTP so they match your needs.
They are platforms that are not free while others provide a free account you can use to experiment with your project.
Just to name a few:
Generally, TLS is good for much more than x.509, but many implementations limit it to only x.509.
x.509 is a technique for a secure indirect trust. "A" trusts "B", if "B" has a certificate, which is signed by "C" and "C" is trusted by "A". That works also in real life; you trust someone you don't know, if a letter is presented signed by a person you trust. ...