General information and limitations on the transmission of sensors readings
You can transfer sensors readings via TCP/UDP (in most cases) or HTTP (S) GET/POST (for beginners or with encryption), as well as MQTT (for devices with feedback) and JSON for simultaneous data transmission of several devices and integration with other monitoring systems.
Maximum data packet size is 4 KB for TCP/POST, 2 KB bytes for GET, 512 bytes for UDP (MTU limitation).
If 10 seconds have passed since the TCP connection (except for MQTT), then such connections are closed forcibly, so we strongly recommend that you first poll all sensors on your device, record their readings in a buffer, and only then establish a connection and transmit data packet to the server.
The data is processed and loaded into the database in batches 1 time per minute (MQTT commands immediately), respectively, and the sensor readings are also updated every minute. When sending readings more than 1 time per minute, the device is banned until the problem is eliminated by its owner.
Allowable interval for recording sensor readings into history (for building graphs, uploading to external systems and CSV) is 5 minutes and can be reduced for partners and donators.
It is forbidden to disclose your unique MAC-addresses of devices and sensors on third-party resources, and when publishing source codes for transmitting readings to narodmon.com, they should be masked to avoid problems of blind copying of someone else's code among beginners and, as a result, conflicts uniqueness of MAC in the Project.
If there are errors in the device protocol, its IP is blocked for 15 minutes. This is a necessary measure because the vulnerability scanner bots are tired and their activity is growing.
How to debug (check for errors and activity) data from the device
In the process of developing new devices, it is often necessary to debug its Protocol for transmitting readings in order to detect and correct errors in it, but what if the limit of devices in the project does not allow you to do this ?
1. If your device is located in your home/office network and therefore has the same public IP address as your browser, you can use the Profile \ Data from my IP section of the website for debugging (after authorization) or use a short link narodmon.com/me
2. If you are debugging a device connected to the mobile Internet (i.e. its public IP does not match your browser), you can use a link like this: narodmon.com/dev/DEVICEMAC
* Replace DEVICEMAC on your device's MAC (without : and -) in any case. If the device is already registered in the project, then read item 3 below.
3. For successfully registered devices, the debugging information can be found in section of the website Sensors \ Configure \ data received from the device.
PS The debug information contains data about all data packets received by the server in the last couple of hours from your device, as well as errors in its Protocol (if any). If this data is not available, then either the IP / MAC of the device differs from the one you specified, or the device does not have Internet access (incorrectly configured or not paid for).
List of typical errors in the server response:
* INTERVAL...<5m - the device transmits data more often than it is allowed (5 minutes by default).
* Sensor...invalid value... - the sensor sent an invalid reading to the server (for example, letters instead of numbers).
* Sensor...out of range... - the sensor transmitted a reading outside the acceptable range for its data type.
* ...is too big - the sensor has transmitted too large value.
* UnixTime > NOW - the specified time in UnixTime (UTC+0) is no longer than the current time.
* MAC_MISSED - missed sensor metric or MAC (serial number) of the device.
* Device MAC...is invalid - invalid MAC (serial number) of the device.
* ##_MISSED_AT_THE_END - there is no sign of the end of the data packet ## (the packet was cut off when sending).
* BANNED - the device is blocked by the owner or administrator.
* IP binding enabled. Data from...is ignored - the device has IP binding enabled, but the data comes from a different IP and is therefore ignored (perhaps the provider has changed Your IP or a conflict of uniqueness OF the Mac devices is detected).
Data required for transmission to the Project server
Field MAC (ID) - unique identifier of the Device in the Project
Most often consists of 12-18 characters A-Z and 0-9 sometimes separated by '-' or ':'.
It is intended for identifying the device (and the supplier by prefix) in the Project and linking it to the owner and to the map in the Sensors section.
Device developers are encouraged to use a personal prefix for their devices to ensure uniqueness in the project and establish authorship, and to avoid frequently repeated characters as in the example below.
TCP/UDP:
#00:00:00:00:00:00
...
##
GET/POST:
id=00:00:00:00:00:00&...
Field NAME - name of monitoring devices
It is optional parameter "name of the monitoring device" in UTF-8 or ANSI(CP1251) encoding. Transmit in TCP / UDP in the 1st line after the MAC of device and delimiter #, in GET/POST transmit separate parameter NAME. Recommended for devices with web-based configuration or with utility, in which you can specify the alias (name).
TCP/UDP:
#MAC#DeviceNAME
...
##
GET/POST:
ID=MAC&NAME=DeviceNAME
Field OWNER - device owner in the Project
An optional field (can be: USER, LOGIN, OWNER) containing the username or e-mail or mobile number of the device owner in the Project Participant Profile for automatic registration of the device. Passed as a separate virtual sensor metric with a text value. It is counted once for automatically linking unused devices to an account in the Project and is not suitable for changing the current owner of the device.
TCP/UDP:
#MAC
#OWNER#UserName
...
##
GET/POST:
ID=MAC&OWNER=UserName&...
Fields LAT,LON,ALT - latitude, longitude, altitude of the location of the monitoring device (optional)
Geographic coordinates are optional location parameters of the monitoring device in decimal form!
Are transmitted by separate metrics of virtual sensors LAT, LON, ALT.
Can be useful for mobile monitoring devices with GPS/GLONASS and sensors connected to them.
TCP/UDP:
#MAC
#LAT#39.962502
#LON#-83.006104
#ALT#407
...
##
GET/POST:
ID=MAC&LAT=39.962502&LON=-83.006104&ALT=407...
For GSM and WiFi devices, you can use special AP * and BS * metrics for an approximate location on cell towers and/or WiFi access points. The average error of 100m is 10km, which is much more accurate than GeoIP.
The more such metrics you pass in the data packet, the more accurate the location is.
TCP/UDP:
WiFi BSSID = 00:00:00:00:00:00 и RSSI = -70:
#AP:00:00:00:00:00:00#-70
GSM MCC(000h) + MNC(000h) + LAC(0000h) + CID(0000000h) и RSSI = -50:
#BS:000:000:0000:0000000#-50
Fields mac1..macN - unique metrics of sensors connected to the device
This is used to identify sensors and linking their readings to the devices.
All sensors connected to the device are registered automatically when their readings are first sent to narodmon.com.
For the DS18x20 family of temperature sensors, the metric(serial number) is 16 digits 0-F.
For other sensors, we recommend using the following metrics to automatically determine the data type (* - any number):
* Temperature: T\d+, TEMP*, BMPT*, DHTT*, DSW*, DS18T*, BATTEMP
* Humidity: H\d+, RH, RH*, DHTH*, HUM, HUMID*
* Pressure: BMPP*, MMHG, HPA, PRESS, BAROM*
* Precipitation: RAIN, RAIN*
* Speed(wind): WS, WS*, *KMH, *MPH, *SPD, WIND
* Azimuth(direction): DEG, DIR
* Voltage: U*, V*, VOLT, VCC, UACC, VBAT, BATVOLT
* Current: I*
* Power: P, P*, W, W*
* Electricity: WH, KWH, WH*, KWH*
* Water meters: WM, WM*, CWM, HWM
* Illumination: L*, LUX, LIGHT
* Radiation: R*, RAD
* Logic(relay): S*, RL*, GPIO*, OUTPUT*, SIM*, RELAY
* Network traffic: RX, TX, RX*, TX*
* Concentration: CO, CO*, CO2, CH4, PPM
* Time(work): NOW, TIME, TIME, CURTIME, WORKTIME
* Signal(level): DBM, RSSI, WIFI, GSM, SIGNAL
* UV index: UV, UV*
* Battery charge: MB2BAT, BATCHARGE
* Dust(particles): PM, PM*, DUST, SDS_P*
* Dew point: DP, DP*, DEW
* Location: LAT, LON, ALT (latitude, longitude, altitude) location of sensors.
TCP/UDP:
#MAC
#T1#00.00
...
##
GET/POST:
ID=MAC&T1=00.00&...
Fields value1..valueN - sensors values to within a few hundredths of
It is not recommended to round the readings so as not to get false notifications of the sensor failure and the graph of the sensor readings was more readable, discreteness of DS18B20 = 0.0625C.
Decimal with sign. Fractional part separated by a period, though the comma is also allowed. Example: -13.54 or -13,54.
Atmospheric pressure can be transmitted in mmHg, hPa or Pa, in the latter case, the reading will be automatically converted to mmHg to display on the map.
Network traffic (SNMP) can be send in Mbit/sec (Mbps) or in cumulative total of bytes (octets) by selecting the type of sensor "traffic, Rx/Tx" will be automatically converted to Mbps.
TCP/UDP:
#MAC
#T1#00.00
...
##
GET/POST:
ID=MAC&T1=00.00&...
Fields time1..timeN - time relevance of sensors values
If the sensor readings are sent immediately, this option is not necessary to transmit.
It is optional parameter "time relevance" unsigned integer UnixTime or ISO 8601.
Example: 1438772570 or 2015-08-05T14:03:11+03:00 or in hex form 55C1ED5A (for economy).
When transmitting UnixTime DON'T need to add your timezone offset, because it is always in UTC+0.
Local time MUST NOT pass "as is" because the server time zone is Europe/Moscow.
Time relevance of sensor readings needs to transmit only when used caching before sending or when bulk loading.
TCP/UDP:
#MAC
#T1#00.00#1733920742
...
##
GET/POST:
ID=MAC&T1=00.00&TIME=1733920742&...
Fields name1..nameN - names of the sensors connected to the device
It is optional parameter "name of the sensor" in ANSI(CP1251) or UTF-8 encoding. Sent only in TCP/UDP after the sensor reading and timeN (if exists).
Recommended for devices with web-based configuration or with utility, in which you can specify the name of the sensor. If this parameter is not empty and is not the time, the sensor name on narodmon.com is changed to the obtained from device.
TCP/UDP:
#MAC
#T1#00.00#SensorName
...
##
Transmitting readings via TCP/UDP to narodmon.com:8283
If your device allows only entering an IP address or you have problems with DNS, then use any IP from the nslookup narodmon.com list to which you have the least ping, but remember that the IP address of the server can change, and the DNS-name is not. TCP can also be used for bulk loading of readings to the server "backdating" by transferring the sensor readings in one data packet with different times, but not more than 4KB per packet for TCP and 512 bytes for UDP. It is preferable to send readings of all sensors in the same data packet to minimize the costs of initializing the connection to the server and importing sensor readings.
The Server response when the successful transmission is OK (or text of the error or command execution), which is recommended to use it as a confirmation of the receipt of data, and if there is no response, repeat sending when the connection with the server is restored. If you receive error messages, DO NOT REPEAT!
The server response string ends with the special character \n code 10(0A). In order to quickly track the state of logical inputs and outputs, it is recommended in response to receiving a command from the server to return a new state of logical sensors to an already open socket, according to the protocol, but only in case of changes so as not to get an error of a small interval of readings.
If you use the UDP protocol, the server will not respond.
| Three sensors realtime: #B9-A8-B2-39-DC-6A #T1#0.96 #H1#64 #P1#713.68 ## | Format of the data packet: #MAC[#NAME][#LAT][#LON][#ALT]\n #mac1#value1[#time1][#name1]\n ... #macN#valueN[#timeN][#nameN]\n ## |
| Download the history of readings: #B9-A8-B2-39-DC-6A #T1#0.96#1733920742 #T1#10.64#1733920142 #T1#22.24#1733919542 ## | With name and location: #B9-A8-B2-39-DC-6A#Метео #OWNER#unknown #T1#0.96#Outdoor #T2#22.24#Indoor #P1#713.68#Barometer #LAT#39.962502 #LON#-83.006104 #ALT#997 ## |
\n - the special character end of line - code 10(0A).
## - a sign of the end of the data packet (after the disconnection), [..] enclosed an optional parameter.
Example of transferring readings over TCP in PHP
$fp = @fsockopen("tcp://narodmon.com", 8283, $errno, $errstr);
if(!$fp) exit("ERROR(".$errno."): ".$errstr);
fwrite($fp, "#B9-A8-B2-39-DC-6A\n#T1#0.96\n#H1#64\n#P1#713.68\n##");
fclose($fp);
An example of transferring readings over TCP in Bash
#!/bin/bash
# by Tuinov Andrey voytmar @ yandex.ru
SERVER="narodmon.com"
PORT="8283"
# MAC address of the device. Replace with your own!
DEVICE_MAC="A0B1C2D3E4F5"
# device ID is added for simplicity, 01 (02) to the MAC device
SENSOR_ID_1=$DEVICE_MAC"01"
SENSOR_ID_2=$DEVICE_MAC"02"
# sensor values
sensor_value_1=20
sensor_value_2=-20.25
# establish connection
exec 3<>/dev/tcp/$SERVER/$PORT
# send a single sensor value
printf "#%s\n#%s#%s\n##" "$DEVICE_MAC" "$SENSOR_ID_1" "$sensor_value_1" >&3
# send multiple sensor values
#printf "#%s\n#%s#%s\n#%s#%s\n##" "$DEVICE_MAC" "$SENSOR_ID_1" "$sensor_value_1" "$SENSOR_ID_2" "$sensor_value_2" >&3
# get an answer
read -r MSG_IN <&3
echo "$MSG_IN"
# close the connection
exec 3<&-
exec 3>&-
An example of transferring readings over TCP in Python2
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
# by Roman Vishnevsky aka.x0x01 @ gmail.com
import socket
# MAC address of the device. Replace with your own!
DEVICE_MAC = 'A0B1C2D3E4F5'
# device ID is added for simplicity, 01 (02) to the mac device
SENSOR_ID_1 = DEVICE_MAC + '01'
SENSOR_ID_2 = DEVICE_MAC + '02'
# sensor values, float/integer type
sensor_value_1 = 20
sensor_value_2 = -20.25
# create socket
sock = socket.socket()
# exception handler
try:
# connect to socket
sock.connect(('narodmon.com', 8283))
# write a single value of the sensor to the socket
sock.send("#{}\n#{}#{}\n##".format(DEVICE_MAC, SENSOR_ID_1, sensor_value_1))
# write to the socket multiple value sensors
# sock.send("#{}\n#{}#{}\n#{}#{}\n##".format(DEVICE_MAC, SENSOR_ID_1, sensor_value_1, SENSOR_ID_2, sensor_value_2))
# read the answer
data = sock.recv(1024)
sock.close()
print data
except socket.error, e:
print('ERROR! Exception {}'.format(e))
Example of TCP transmission in Python3 for Domotics
# Script using Python module request and JSON request requests
# data of the chosen sensor at Domoticz and sends part of them to
# service people monitoring (narodmon.com)
# By tudimon, bigmak, Maker39 @ 4PDA
# connect modules
import requests
import socket
ip = '127.0.0.1' # domoticz ip address
port = '433' # port
user = 'dz_user' # user Dz
password = 'dz_user_password' # the password of the user
idx = 66 # number of the sensor in Domoticz, which we will poll
# Query string if authorization is needed
#get_url = 'http://'+user+':'+password+'@'+ip+':'+port+'/json.htm?type=devices&rid={}'.format(idx)
# Query string if you don't need authorization
# if the script is executed on the same device as Dz and in
# Settings - Settings - System
# Local area networks (no username/password) IP address specified
get_url = 'https://'+ip+'/json.htm?type=devices&rid={}'.format(idx)
# uncomment if you want to output a line to the console for control
#print ('================================')
#print (get_url)
#print ('================================')
# request data of the chosen sensor
get_data = requests.get(get_url, verify=False).json()
# verify=False key had to be added because my Dz only works on port 433
# a self-signed SSL certificate, respectively request swore at the certificate error
# the answer will come in the form of JSON, where you need to select the field of interest,
# for example, temperature, humidity and battery level
humidity = get_data['result'][0]['Humidity']
temperature = get_data['result'][0]['Temp']
battle_level = get_data['result'][0]['BatteryLevel']
#Output data to the pi console
# when the script is debugged, the following three lines need to be commented out
print ("Humidity" + str(humidity))
print ("Temperature" + str(temperature))
print ("battery Charge" + str(battle_level))
# ============== data transfer to narodmon service==================
# MAC address of the device. Replace with your own!
DEVICE_MAC = 'ffffffffffffffffff' # MAC dz Raspberry Pi
# device ID
SENSOR_ID_1 = 'dz_t'
SENSOR_ID_2 = 'dz_h'
# sensor values, type float/integer
sensor_value_1 = temperature
sensor_value_2 = humidity
# create socket
socket = socket.socket()
# exception handler
try:
# connect to socket
sock.connect(('narodmon.com', 8283))
# form a string for the socket at a single value of the sensor
#s_sock = ("#{}\n#{}#{}\n##".format(DEVICE_MAC, SENSOR_ID_1, sensor_value_1))
# generated string to the socket when the value of multiple sensors
s_sock = ("#{}\n#{}#{}\n#{}#{}\n##".format(DEVICE_MAC, SENSOR_ID_1, sensor_value_1, SENSOR_ID_2, sensor_value_2))
# Write a line with the console to control
# comment out these three lines after debugging
print('======================================')
print(s_sock)
print('======================================')
# Write to socket
sock.send(s_sock.encode('utf8'))
# read the answer
data = sock.recv(1024)
sock.close()
except socket.error as e:
print('ERROR! Exception {}'.format(e))
Transmission via HTTP GET/POST to http(s)://narodmon.com/get (/post) and TLS encryption
It is recommended to use only if Internet access is via a proxy server, because of possible problems with caching web proxy above and the risk of interception / spoofing of data without encryption and also increases the processing time during "rush hours" due to the large number of visitors to the site and mobile clients that should have no effect on our TCP/UDP (described above).
The maximum length of the request 4КБайт (4096 characters).
It is preferable to send the readings of all sensors in 1 request to minimize the costs of initializing the connection and processing of evidence.
The Server response when the successful transmission is OK (or error text), which is recommended to use it as a confirmation of the receipt of data, and if there is no response, repeat sending when the connection with the server is restored. If you receive error messages, DO NOT REPEAT!
Encryption: if you suspect that the enemy wants to intercept / fake your sensor readings, then use the address bar https://narodmon.com/post and transmit data with TLS encryption (SSL is deprecated).
Sample request for transmitting readings using the HTTP GET
It should be known that this is the easiest way for beginners, but insecure and unreliable in terms of ease of interception/forgery of data without encryption and depending on the load on the Project website and REST API for apps. The maximum request length is 2 KB (2048 characters).
To enable TLS encryption use the url https://narodmon.com/get?...
http://narodmon.com/get?ID=MAC&mac1=value1&...&macN=valueN[&time=UnixTime][&name=device_name][&owner=username][&lat=latitude][&lon=longitude][&alt=altitude]
Sample request for transmitting readings using HTTP POST
You should know that the reliability of this method depends on the load on the project website and API for applications, unlike TCP, UDP and MQTT.
The maximum request length is 4 KB (4096 characters). To enable TLS encryption use the url https://narodmon.com/post
POST http://narodmon.com/post HTTP/1.0\r\n
Host: narodmon.com\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: NN(number of bytes in the data string below)\r\n
\r\n
ID=MAC&mac1=value1&...&macN=valueN[&time=UnixTime][&name=device_name][&owner=username][&lat=latitude][&lon=longitude][&alt=altitude]
An example of passing readings via HTTP POST in Python2
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
# by Roman Vishnevsky aka.x0x01 @ gmail.com
import urllib2
import urllib
# MAC address of the device. Replace with your own!
DEVICE_MAC = 'A0B1C2D3E4F5'
# device ID is added for simplicity, 01 (02) to the mac device
SENSOR_ID_1 = DEVICE_MAC + '01'
SENSOR_ID_2 = DEVICE_MAC + '02'
# sensor values, float/integer type
sensor_value_1 = 28
sensor_value_2 = -12.34
# formation of POST request for a single sensor
data = urllib.urlencode({
'ID': DEVICE_MAC,
SENSOR_ID_1: sensor_value_1
})
# formation of POST request for 2 sensors
# data = urllib.urlencode({
# 'ID': DEVICE_MAC,
# SENSOR_ID_1: sensor_value_1,
# SENSOR_ID_2: sensor_value_2
# })
# request header generation
headers = {
'Content-Length': str(len(data)),
'Content-Type': 'application/x-www-form-urlencoded',
'Host': 'narodmon.com'
}
# directly to a query
request = urllib2.Request('http://narodmon.com/post.php', data, headers)
response = urllib2.urlopen(request)
print response.headers
An example of passing readings via HTTP POST to PHP with cURL
$data = array('ID'=>'B9-A8-B2-39-DC-6A', 'T1'=>0.96, 'H1'=>64, 'P1'=>713.68);
$ch = curl_init("http://narodmon.com/post");
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
$reply = curl_exec($ch);
curl_close($ch);
An example of passing readings via HTTP POST in PHP without cURL
$data = array('ID'=>B9-A8-B2-39-DC-6A, 'T1'=>0.96, 'H1'=>64, 'P1'=>713.68);
$context = stream_context_create(array('http' => array('method'=>'POST','content' => http_build_query($data))));
$fp = @fopen("http://narodmon.com/post", 'r', false, $context);
if($fp) { fpassthru($fp); fclose($fp); }
Transfer of readings in JSON format using TCP/UDP narodmon.com:8283 or http(s)://narodmon.com/json
This type of protocol is the most functional and will be most useful for owners of several devices and for integration with an existing monitoring system at home or in an office. allows you to transfer data from several devices with all their attributes in one data packet at once, saving you from a lot of manual work of one-by-one registration and setting them up in the Project.
A data packet can be transmitted either via TCP or UDP to the narodmon.com:8283 port, or HTTP(S) POST with or without TLS encryption can be used at http(s)://narodmon.com/json. The packet size restrictions are similar to other transmission methods: 4KB (for UDP 512 bytes due to MTU).
The server response upon successful sending, error or receiving commands will also be in JSON format, which is recommended to be used as confirmation of data receipt, i.e. if there is no response from the server, repeat sending when the connection is restored. If error messages appear, DO NOT REPEAT!
Server Response Examples:
{"error":"OK","errno":200} - data received successfully, no errors;
{"error":"INTERVAL <1 min","errno":429} - sending data too often;
{"error":"JSON_ERROR_SYNTAX","errno":400} - the data was received, but there was an error in it.
Format of transmitted data JSON
Below is an example of the expanded structure of a JSON packet with all possible parameters when transmitting sensor readings (to save traffic, you can write everything in 1 line and remove extra spaces). Mandatory parameters are highlighted in bold, the rest are optional and we recommend sending them only when they are changed. After // there are comments to the parameters, of course you don't need to send them to the server.
{
"devices": [
{
"mac": "DEVICE_MAC", // device serial number, unique for the Project;
"name": "DEVICE NAME", // device name in UTF-8 encoding;
"owner": "USERNAME", // login or email or cell phone of the owner of the device for auto-registration;
"lat": 39.962502, // latitude of the installation site;
"lon": -83.006104, // longitude of the installation site of the device;
"alt": 919, // altitude above sea level of the installation site;
"sensors": [
{
"id": "T1", // sensor metric unique to the device;
"name": "SENSOR NAME", // name of the sensor in UTF-8 encoding;
"value": 00.00, // sensor reading;
"unit": "C", // unit of measure for the sensor in UTF-8;
"time": 1733920742 // time of relevance of sensor reading UnixTime (UTC+0);
},
{
// other sensors on the device
}
]
},
{
// other devices
}
]
}
Sample of transmitting readings in JSON using the HTTP POST
The maximum request length is 4 KB (4096 characters).
To enable TLS encryption, use the address https://narodmon.com/json
POST http://narodmon.com/json HTTP/1.0\r\n
Host: narodmon.com\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: NN(number of bytes in the data line below)\r\n
\r\n
{ "devices": [{ "mac": "MAC", "sensors": [{ "id": "..", "value": 00.00 }, {..} ]}, {..} ]}
Transfer of readings in InfluxDB format via HTTP POST protocol to http(s)://narodmon.com/post
This option for transmitting readings is an extension of the HTTP POST protocol for firmware devices with support for InfluxDB time series, for example luftdaten.info for measuring quality air (number of dust particles).
The value of the node should be used as the ID/MAC for registering the device in the Project.
Example format (set of sensor metrics may vary):
device,node=MAC SDS_P1=15.55,SDS_P2=6.57,BME280_temperature=6.37,BME280_pressure=99535.03,BME280_humidity=40.34,interval=300000,signal=-44
PS For a detailed description of the procedure for connecting devices with the luftdaten.info firmware to our project, see article by Alexey Nadezhin (ammo1) for that many thanks to him!
Transmission of readings via MQTT Protocol to narodmon.com:1883 (free with restrictions)
When used for free, the server will not support keep-alive connections, i.e. will continually reset the connection after receiving a data packet.
This method of transmitting data is quite difficult to implement and requires a higher level of technical training. Consultations and training on working with it are not carried out and if you encounter problems with its use, it is better to switch to the simpler protocols described above. Using this protocol justifies itself only with complex devices with feedback, where an immediate reaction to commands from the server is required.
MQTT (Message Queuing Telemetry Transport) is an open protocol developed by IBM specifically for the Internet of things is used to exchange data between devices. MQTT network includes MQTT broker that serves as intermediary in the interaction MQTT-agents – publishers and subscribers. Publishers publish information to subscribers. A detailed description of the protocol set out in the specifications MQTT Version 3.1.1.
MQTT is a binary protocol on top of TCP that greatly reduces the amount of data transmitted and extremely useful in the unstable low speed mobile networks. In addition, the connection broker(server) is initiated by the client device, allowing to work with "gray" IP addresses (provider NAT) while the server connection is generally not terminated (in stable channel), which allows you to quickly transmit sensor data and receive commands for execution from the server.
When setting up an MQTT connection to our broker (server), you should specify the host narodmon.com port 1883. The default interval for transmitting readings, as for other protocols, is 5 minutes. In this case, your device will be automatically linked to the account you specified in the Project, if in CONNECT you passed the login and password (or your code 0) in the Project. If you specified an incorrect login/password in your device settings, your IP will be blocked for 15 minutes, after which you can try again.
CONNECT (code 1)
Connection to the server, necessary parameters:
Client Identifier (ClientID) = MAC of your device
UserName = Your login in the Project (if auto-binding is required)
Password = Your password or your code 0 in the Project (if auto-binding is required)
In response, a CONNACK (code 2) is sent with the result:
0 - connection successful;
2 - invalid device MAC (ClientID);
3 - technical failure of the broker / unavailability of DBMS;
4 - incorrect login or password (if they are transmitted);
5 - access is denied (for example, due to non-payment).
PUBLISH (code 3)
Publication of the displayed sensors, necessary parameters:
Topic = login/device/sensor (example: username/devname/sensor1)
Value = sensor reading.
In response, PUBACK (code 4) is sent for QoS = 1 or PUBREC (code 5) for QoS = 2.
When using JSON format:
Topic = login/device/json (example: username/devname/json)
Value = readings of all sensors in one line (example: {"sensor1":1,"sensor2":2}).
PUBACK (code 4)
Confirmation of data receipt by the client with QoS = 1 after the PUBLISH command (code 3) from the server.
PUBREL (code 6)
Acknowledgment of data receipt by the client with QoS = 2, response to PUBREC (code 5).
The response is PUBCOMP (code 7).
SUBSCRIBE (code 8)
Subscription to topics, UI and REST API commands.
SUBACK (code 9) is sent in response.
If you need to work on subscribing to topics of other devices or other events, then to consider the possibility of its implementation, write to the project’s technical support with a detailed description of your information exchange via MQTT and the desired functionality of our broker.
UNSUBSCRIBE (code 10)
Unsubscribing from topics. No action.
UNSUBACK (code 11) is sent in response.
PINGREQ (code 12)
Checking client/server activity.
PINGRESP (code 13) is sent in response.
DISCONNECT (type 14)
End of the session with the server, no parameters are required.