MQTT and CoAP are being promoted as standard protocols that allow connecting constrained devices to the Internet.
I'm interested in a list of sensors and actuators that support these two protocols either in a native way or through a mesh/gateway.
For CoAP:
Every 6LowPAN sensor mote have a CoAP client,
for example the one running contiki: http://www.contiki-os.org/hardware.html
or OpenWSN, RIOTOS
Also you can use any Arduino: https://github.com/1248/microcoap
One that is worth checking in addition to Julien's List is mBed from ARM
https://mbed.org/
it supports both CoAP and MQTT
CoAP/MQTT and sensors/actuators are two different entities. You can implement any sensors or resources with CoAP and MQTT.
CoAP and MQTT are application layer protocol that uses TCP/UDP to transfer data (for example, sensor readings) over network.
For example in CoAP, all sensors on your hardware are treated as 'resource'. CoAP provides GET, PUT, POST, DELETE interface to manipulate with resource.
It is developers responsibility to attach its custom handlers to above interface. For example, attach read_temperature_sensor_data() to 'GET' interface, attach set_clock_time() to 'PUT' interface etc.
Related
I am quite confused about MQTT clustering, it doesn't seem to be part of the MQTT protocol and I was wondering if each MQTT broker implementation has its own way to implement it. Also, do you know which kind of information are shared between cluster nodes? It seems like it retains information related to the session related to pub/sub but not the messages, is that correct? Thanks!
No, there is nothing in the MQTT protocol about clustering brokers. There is support for bridging topics between 2 brokers, but this is purely at the message level, it carries no information about clients or sessions.
Any clustering is implemented independently by a given broker, what information shared would also be dependent on the that implementation. But would need to include the following:
Client Session information, including subscriptions
Message
Information about which messages have been delivered to what clients
I would like to create a point-to-point connection between a LoRa temperature sensor and a M5 Stack (ESP32) with LoRa module. However, I am a beginner with LoRa, so I have a few questions:
Are all packets send with LoRa (not LoRaWAN) encrypted? Or does it depend on the producer of the LoRa sensor?
Can the content of the packet received by the M5 Stack be viewed? (If I understand correctly, with the LoRaWAN the content can only be viewed after it is on the server).
Can I send measured temperatures from multiple LoRa sensors to one M5 Stack? If yes, how could I distinguish from which sensor the packet has been sent?
Any help would be appreciated!
LoRa means only the RF modulation. All crypto happens in higher layers, i.e. the protocol stack – one possible option for this is LoRaWAN. LoRaWAN uses AES-128 encryption in two layers, Network and Application. You gave no information about the kind of "LoRa temperature sensor" you have, so it is not possible to make a statement about that, other than that it is not LoRaWAN. So this fully depends on the sensor's firmware. There are alternative protocol stacks to LoRaWAN, DASH7 for example. You also might want to have a look at this Stack Overflow article
This too depends on the used protocol stack. With LoRaWAN, you need a gateway to receive the node's LoRa telegrams which are then forwarded to the LoRaWAN cloud (TTN/TTS, for example). Your application can get them from there via Internet. If there's already a TTN gateway in reach, your nodes would automatically use that.
You can actually use the M5 with its WLAN capability to act as a message consumer for multiple nodes by subscribing to the cloud via MQTT, for example – using LoRaWAN. Using LoRa without LoRaWAN, this again depends on the alternative protocol stack you are using here. Of course this requires a working WLAN in reach.
If you are trying to use plain LoRa, which is possible, it is purely your task to implement all the requirements for managing the communication between all involved nodes; it is also your responsibility to ensure that the legal obligations are met.
I would strongly recommend using LoRaWAN and TTN/TTS as it is the de-facto standard for LoRa communications and offers a complete ecosystem that can be used readily without great effort/cost.
I have a doubt about the IoT Protocol Stack .
Searching between papers on google scholar or IEEE about IoT , i find the actual "IoT Protocol Stack" :
IoT Stack
I think it is uncorrect .
The doubt is about the transport layer and application layer.
1) why there is only CoAP on the application layer if there are many others Application Layer Protocol for the IoT , such as : MQTT, XMPP ,AMQP , WebSockets and so on?
2) Why they provide only UDP at the Transport layer if in the upper layer ( Application) there are some important protocol in the environment of the IoT , for example MQTT, that run over TCP ?
The term "IoT" is used with various meanings by different interest groups; so is therefore the term "IoT stack".
What the linked image depicts is the IETF IoT Stack, which is the IETF's idea of what IoT devices should use to deserve that name. CoAP is the application protocol specified by IETF (and used by various others like OMA LwM2M, OCF or Thread), and is in my experience the best suited protocol as it allows full operation on tiny devices (technically: Class 0 according to RFC 7228 – good luck implementing XMPP, WebSockets or similar on those) while still being powerful enough to express all the concepts from the HTTP web.
The image depicting only UDP is probably due to the focus on IoT devices: While CoAP can be transmitted over several transport layers (including TCP and WebSockets, but also SMS in a draft version), those transports are rather used indirectly (eg. by a browser application that uses a gateway to talk to UDP connected devices), the expected scenario for the devices themselves is using CoAP over UDP on a 6LoWPAN network. That doesn't rule out other deployment scenarios (eg. LwM2M uses CoAP over cellular networks a lot, in UDP and TCP transports), but is better seen as typical example for the smallest of devices.
I have a question about my CAR's ODB function.
I have a USB dongle with AT90CAN128 uE , the uE has CAN driver and i can use this to read the data traffic on the bus.
I have a BMW 116i but this car uses KWP-fast protocol for the obd2.
I want to ask if can i use the CAN bus to send queries to the ECU for the obd2 available variables.
I am not sure because at work we use the KWP2000 protocol via CAN bus, but i don't have the specification, we use a ready tool on CANoe.
KWP2000 is not CAN, they are completly different. OBD2 includes CAN and KWP2000 (also J1850, among others). They use a different physical layer and you won't be able to use CAN to listen/talk KWP2000.
If MQTT is already a lightweight protocol and it uses small amount of power and bandwidth, then why do we have MQTT-SN? When is it appropriate to use MQTT and when MQTT-SN?
There are few advantages in MQTT-SN (SN for Sensors Network) over MQTT, especially for embedded devices.
Advantages
MQTT-SN uses topic ID instead of topic name. First client sends a registration request with topic name and topic ID (2 octets) to a broker. After the registration is accepted, client uses topic ID to refer the topic name. This saves media bandwidth and device memory - it is quite expensive to keep and send topic name e.g: home/livingroom/socket2/meter in memory for each publish message.
Topic name to topic ID can be configured in MQTT-SN gateway, so that topic registration message can be skipped before publish.
MQTT-SN does not require TCP/IP stack. It can be used over a serial link (preferred way), where with simple link protocol (to distinguish different devices on the line) overhead is really small. Alternatively it can be used over UDP, which is less hungry than TCP.
Disadvantages
You need some sort of gateway, which is nothing else than a TCP or UDP stack moved to a different device. This can also be a simple device (e.g.: Arduino Uno) just serving multiple MQTT-SN devices without doing other job.
MQTT-SN is not well supported.
If you are running out of resources, or you do not have Ethernet/Wifi in your device, use MQTT-SN.
MQTT-SN (wher SN means Sensors Network) is different from MQTT.
MQTT goes over TCP/IP and it can used for LAN communication or over Internet and the Cloud (if you have a client inside your network but the broker is outside on Internet).
MQTT-SN can be used on more protocols suited for sensors network like ZigBee, Z-Wave and so on.
The specification is different from MQTT ... so it isn't MQTT not over TCP/IP.
It's more lightweight and needs a bridge to translate MQTT-SN messages into MQTT messages.
Paolo.