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 ...
There are some potential misconceptions or misunderstandings in the question that will be addressed in this post.
In Diagram 2, it shows a representation of the software "stack" that a computer (PC) would use to create, process, and send a message, across the internet, to another computer
Do all kinds of computers - smartphones/tv's/gameconsoles, ...
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 ...
Do all kinds of computers - smartphones/tv's/gameconsoles, etc use
For something to exchange on the internet, it will have to go through an IP stack somewhere.
Does the OS matter?
The IP protocol is defined by a the RFC 791, so the OS/Firmware has to comply to it, whatever it is.
(In this regard) is there any difference between ...
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 ...
I would add to the list OPC/UA
The OPC Unified Architecture (UA), released in 2008, is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework.
The Coke Machine, rather amusingly, has its own website with a bit more information on its history.
The Ancient History document explains how the original Coke Machine operated:
The final piece of the puzzle was needed to let people check Coke
status when they were logged in on some other machine than CMUA. CMUA's
Finger server was modified to run ...
If you are using an ESP8266 the built in Smart Config feature can achieve this. An example can be found here: ESP8266 Arduino WiFiSmartConfig.ino.
The important steps are to set to STA mode: WiFi.mode(WIFI_STA);
Then start looking for the smart config packets: WiFi.beginSmartConfig();
Finally check for the config to be complete: WiFi.smartConfigDone()
I would either go with RS485 or CAN because with long buses a lot of noise can be picked up. These are the most noise resistant as both of them use differential, twisted data lines.
RS485 supports distances up to ~1,200 meters with a guaranteed speed of 100 Kb/s. Max 10 Mb/s with smaller distances. It is a multi point bus with up to 32 drivers and 32 ...
In order to avoid the need to be on a network which allows inbound traffic, you need to connect outbound to a server which will relay requests from clients which also make outbound connections to it.
This in essence is like the model of a communication satellite. Both the user's computer or phone or whatever, and the IoT device, maintain links "up" to this ...
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.
The problem is essentially one of receivers and of power.
A "find my keys" type of beacon needs to be small enough to attach to your keychain and you probably don't want to have to regularly recharge the beacon (you wouldn't lose your keys if they're always in their charger) so that requires either:
a passive technology without a battery.
an active ...
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.
No, CoAP is an application layer protocol it's not dependent
Basically that's the beauty behind the OSI layers. If correctly implemented you can mostly stack them however you want. As with every thing that starts with if correctly implemented that's mostly academic and some protocols fit better together with others than others do. More or less the only ...
This is an unusual use-case where the data throughput which you require is really low - range and low power are the driving factors. This points in the direction of a low data-rate, narrow band protocol (or maybe one using a spreading code, such as GPS).
Looking for long-range through walls, etc. implies a low RF frequency too, 433 MHz would probably be ...
CoAP and MQTT have both equal RAM usage, measured in 10kbits .
Difference is in cpu and network usage: 
Every client supports TCP and holds a connection open to the broker.
So, CoAP has fewer foot print and according to the whole use case (small data once in a while) it seems to be your best choice.
As you referred, CoAP uses UDP. It does not ...
I have linked this before to another question, this kind of nails it. Quite in the beginning there is a list of protocols compared.
HTTP and MQTT are on that table and LwM2M as described on their site works on top of coap, which appears in table.
Main difference is the nature of communication: HTTP and coap provide a request and response based ...
if the MQTT IoT devices are completely different from other types
like HTTP in features, or is the difference only about communication
protocols? Can a device that marked with "MQTT" be swapped to "HTTP"
or vice versa?
This depends on the device, but HTTP and MQTT are protocols and the same device could support both. A more common situation is a ...
Latency vs Rate
a low-latency (10 Hz) type of IoT application
This is a conceptual error. Latency and Rate are largely independent. You could have a system which recorded thousands of readings per second, stored them on an SD card, and once a month someone visits the remote site, extracts the card, and mails it to you - that system would have a high ...
You could, but you'd need a radio transceiver with compatible frequency range, modulation, and data rate.
Typically radios with those capabilities are either sold as Zigbee radios, or for the underlying 802.15.4 layer. Sometimes they can do some additional custom modes of communication as well (though often available software stacks force you to pick a ...
I would like to say that Yes, Bluetooth is a good candidate for indoor positioning.
Depending on how good positioning you want, of course.
If you have Bluetooth beacons scattered over your house it will probably be as simple as cell positioning - the beacon that last saw your key chain will be in the same room as the key chain. With one beacon per room, it ...
Are you asking about the protocol or the message format? We often incorrectly use the term protocol when we mean the format of the data. I do this myself, often because the distinction isn't clear to everyone.
Messaging protocols used in IoT tend to be fairly compact, at least more so than http and offer significant features that are important in messaging (...
Sounds like a job for CoAP:
Like HTTP, CoAP is based on the wildly successful REST model: Servers make resources available under a URL, and clients access these resources using methods such as GET, PUT, POST, and DELETE.
From a developer point of view, CoAP feels very much like HTTP. Obtaining a value from a sensor is not much different from ...
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 ...
I'm going to answer your first question. I think it would be better to ask just a single question per... question :)
What makes an IoT server different from a webserver, mail server or FTP server?
A web server talks HTTP to provide web pages.
A mail server talks POP/IMAP/SMTP to exchange email.
An FTP server talks the FTP protocol for file transfer.
3GPP—the 3rd Generation Partnership Project. The project covers cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, quality of service - and thus provides complete system specifications. Interesting standards regarding IoT ...
Quantum mechanics and the blockchain
Those are two evergreens in every futuristic buzzword bingo. Thus, naturally they get mixed with the Internet of Things, which has been derisively put in the same category of futuristic stuff people half get.
So, let's sort the stuff out a bit. I'm assuming that you're referring to this article Aurora dug up. ...
Ubisys G1 seems to be a device (the only one?) that does this.
A brief description from the product page, for reference:
Our gateway links your ubisys smart home to the outside world. It establishes a link via the internet connecting the ubisys smart home App on your mobile end device with the ubisys smart home components installed in your home. Connect ...
I would recommend some sort of mesh network, as obviously plain old WiFi or BT won't cover those distances. Zigbee is as good a candidate as any.
For hardware, AdaFruit does some good wearables, although if everyone has a smartphone, you might as well use those.
And, if you can figure out how to power it by battery, take a look at my answer to this ...
A few thoughts on my experience with TCP, UDP, and MQTT as well as some additional resources to review.
With UDP I have run into the silent failure problem in which an application on one network node, the client, is seeing only some of the UDP messages that were sent. There are too many reasons why network traffic may go awry. The problem with UDP is that ...