I study about IoT protocol CoAP, MQTT, LwM2M.
I was able to know a little about CoAP and MQTT.
But I do not know what LwM2M is.
I do not know what's different from CoAP.
I just thought that LwM2M is not a protocol with some format but a system structure using CoAP.
Is that correct?
What is LwM2M and How Can I know more information about LwM2M?
Please someone teach me.
LwM2M (specified by OMA) is a is a protocol group largely built on top of CoAP (specified by the IETF).
LwM2M uses a subset of CoAP's capabilities that fit into an architecture of many small devices registering at a large LwM2M server that manages the devices. It prescribes particular path structures (that numbers are used in paths, and what they mean) that represent the LwM2M object model to allow that unified management.
Compared to "plain CoAP", this limits the scope of what devices can do. Devices can still provide other CoAP functionality on the same server that is not covered by LwM2M. Those limitations allow different vendors to build devices that can interoperate with a different management servers, and LwM2M provides additional specifications for easy deployment (e.g. based on smart cards) that are out of scope for CoAP.
The direct answer can be obtained from the official sites:
CoAP "is a specialized web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation."
LwM2M "is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. With LwM2M, OMA SpecWorks has responded to demand in the market for a common standard for managing lightweight and low power devices on a variety of networks necessary to realize the potential of IoT."
Basically, we can simplify saying that CoAP was designed to communications between constrained IoT devices and it is very similar to HTTP protocol, which facilitates the developers work, while the LwM2M was designed mainly to manage constrained devices remotely, providing service enablement, for instance. Both protocols are commonly used together.
More information you can find in the following links:
- What is LwM2M? A device management solution for low power M2M
- CoAP functionality expected in a LwM2M system
Related
Hi according to this the API is deprecated and considered legacy. It is not specific about when it will be removed. They recommend using Network, though it doesn't have a low-level API for alternative transports/physical layers.
I plan on using it for securing Bluetooth communications (like a BLE Uart thing), which means the API should not be dependent on network transports. Secure Transport fits this bill.
Is it okay to use this for future-safe developments?
Is there an alternative that will support something with an obscure transport layer (like BLE)?
I've looked at Swift-nio and its children, and it looks like it may work when overriding Channel etc, though it is more geared toward network transports.
As far as I understand, LoRaWAN is intentionally designed as a Non-IP Stack.
Based on all requirements on LoRaWAN, I can understand the design decisions behind the standard.
But IMHO, there are many other use cases for LoRa (just the physical protocol) which, for example, do
not need to be able to communicate to many gateways at the same time or
don't have low energy consumption requirements.
For these use cases, it would be nice to have other MAC implementations, where one could either have
IP-based stack on top of LoRa or
a lightweight protocol between LoRa-based Sensor and ONE gateway, which handles message transport & security
Sigfox has a similar architecture to LoRaWAN where the device/sensor sends messages directly to a backend-network to which the application needs to connect.
To me, this kind of architecture seems pretty odd, since I loose many advantages of the internet and I am tightly coupled to a backend-network provider (imagine using LTE, you would need to explicitly add your application to the mobile providers backend).
I would like to have a local network (would be okay if it is not IP based) but the devices are connected to a gateway and there I have all flexibility what to do with the sensor data. Using LoRaWAN, this could be achieved by running a network server on the gateway but this would be rather a workaround than a solution I am looking for.
The only reason that I can see now, which makes this network architecture really necessary are that a device can connect to multiple gateways and therefore use cases as, e.g., asset tracking can easily be realized.
Are there any LoRa based solutions where I do not have to deal with setting up network servers? If not, why is that the case?
Edit:
For Linux, I found this project here:
https://de.slideshare.net/chienhungpan/lets-have-an-ieee-802154-over-lora-linux-device-driver-for-iot
And also the LoRa Mesh Project:
https://github.com/meshtastic/Meshtastic-device
LoRaWAN is a Low Power Wide Area Network (LPWAN). This means that the technology allows us building a scaleable wireless IoT network where all devices (things) can be connected even if their transmission power is limited. A LoRaWAN network can easily scale at a size of a country and the low power communication makes it possible to operate the network in an ISM band where both transmission power and bandwidth are limited anyway. Low transmission power also ensures long battery life time for battery powered devices.
Beyond supporting geo-localisation, gateway diversity (meaning that the same radio frame can be received by multiple gateways) significantly increases the resiliency of the network, improves the link budget and lowers the packet error rate.
Traditional IP based based protocols would require much higher average data rate than what LoRa was designed for.
Although you are not obliged to use LoRWAN's MAC layer with the LoRa modulation and you may develop your own proprietary protocols, if low transmission power, long range and long battery life is not important for your use case, it is probably better to use another technology.
The Reticulum Network Stack supports many different physical mediums, including raw LoRa. Mediums like LoRa can be used exclusively, or mixed with any number of other mediums to build as simple or as complex networks as you need, from two devices to billions.
Reticulum is purposefully designed to handle very low data rates and very high latency, while still supporting transport accross much faster network segments, and is very efficient in terms of per-packet and overall protocol overhead.
The source code for the reference implementation, and releases can be found here: https://github.com/markqvist/reticulum
This is a basic questions. I want to apply to an entry level java developer position with the following requirement:
Familiarity with the Sailpoint Identity IQ standard adapters/connectors
By standard connectors do they basically mean how Sailpoint exchanges data with third party tools? And by adapter do they mean that the adapter pattern would be used? Thanks
This is going to probably appear well after your interview - but to answer the question:
1) Standard adapters/connectors:
SailPoint ships with a "standard" set of connectors which are part of the purchase price there are those ie EPIC which do not ship as part of the standard product and must be enabled. To give you a deeper view into connectors..
Connectivity Methods:
Direct Connectivity - This is where a connector communicates directly to a system using APIs or data-sources. Some advantages of using direct connect are that you don't have to generate or transmit files, and you can be more efficient in processing only things that have changed. Some disadvantages are the they are subject to availability and downtime concerns like any connected system. They are also typically subject to advantages and disadvantages that APIs might impose as well.
Some people also refer to this as an 'online' method of connectivity.
File-Based Connectivity - This is where a connector reads from a snapshot of data presented in a file, rather than connecting directly to the system. Some advantages of using a file, are that files are portable, easily inspected for data issues, and not typically subject to availability. Some disadvantages are that files are usually processed in their entirety, and may require processing or transformation in order to work effectively.
Some people also refer to this as a 'decoupled' or 'offline' method of connectivity.
Connector Implementations
Source-Specific Implementation - These are connectors built with a specific target-system in mind. These typically use specific APIs targeted to the system they are integrated with. Because the systems and APIs are known, these typically require less configurations to get working.
Examples of these are Active Directory, Workday, Salesforce, SAP, etc.
General Implementation - These are general-purpose connectors which can be used to connect to a variety of sources or systems. These tend to be more flexible in general, but typically do require a bit more setup and configuration to meet needs.
Examples of these are Web Services, SCIM, JDBC, Delimited Files, etc.
Custom Implementation - These are completely custom connectors and tailored to the system and API of your choice. This approach offers the most flexibility of all connector options, however making custom connectors is definitely a development-level activity, and is not to be taken lightly. The code written for custom connectors is maintained and supported by the customer who owns the connector.
Examples of these are custom in-house applications, etc.
Understanding these connector implementations is important, because if a source-specific implementation isn't available, another general or custom connector implementation may be used instead.
MEAN stack and IOT are the current trending hot topics. Can these two be used together? If yes then in what way?
How can these technologies be used together?
Sweta.
By saying MEAN.js you are including things that are not strictly in the IoT terrain. Angular for example has little to do with anything.
On the web front end you need to implement a javascript library like Paho.js that will use the MQTT protocol to connect to a broker and start aggregating messages from connected devices.
Express has little to do as well as you are not exposing a Restful interface but connecting low level through a broker. A good solution in Node.js is Mosca.
Mongo is good for dumping data from devices.
I have written a tutorial using Node.js and iOS so have a look and you might find it interesting.
Mean stack is the combination of the frontent web frameworks like angularjs,emberjs,knockoutjs,backbonejs , javascript's backend server called nodejs and using the mongodb at top. so using these frameworks and library will make a mean stack developer.
IoT pronounced as Internet of things. iot is recently used for connected electronics devices .basically it is a form of running your program inside the electronic chip and mostly trying to connect the devices.making control on devices using the programmed chip. there are separate IDE's are avaialble for developing and testing the programme on embeded chip.
you can use angularjs as a frontend(making your GUI) for your IoT'S application.
Yes, you can.
As a fact is has been done before. And in other frontend frameworks too. Here there is an example for home automation.
You can find even a yeoman generator for such projects here.
[Disclaimer: I work here] Netbeast started managing devices and creating a system of plugins on top
of a MEAN app and RESTful communications. (Now we use a MERN
stack, with react and MQTT over websockets to control networks and
update values in real time.)
To mention other places where you can find examples of current projects using MEAN to run IoT networks I encourage you to join angular, arduino and raspberry communities, as well as taking a tour over producthunt.com, hackster.io and other maker sites such as the previously mentioned Netbeast forum.
Yes you can make an IoT platform with the MEAN stack. Typically the sensors are low cost sensors and are constantly transmitting small amounts of data in MQTT or TCP protocols. With Node.js you can write, servers for such applications very easily.
Mongo is useful if you have unstructured data, which could happen if you work with multiple sensors. If you don't need unstructured data structures, SQL is sufficient.
All the data that you get from devices, finally needs to be consumed via applications. Express and Angular are great platforms to manage web applications.
You can read a little more about IoT platforms in MEAN at http://blog.yatis.io/scalable-iot-platform-mean-stack/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Is there any decent alternative to OPC-UA as a solution for accessing process data of a system composed of various PLCs? Something that is platform independent and can "speak" with products of different brands ?
I've heard of MQTT but it seems to be much more like a transport protocol, and only that. It does not have all the higher level stuff like the information modeling, etc.
Thanks for your help!
OPC is the only standard way for communicating with PLCs. OPC DA is the old alternative. OPC UA is the new one and recommended, nowadays. Before OPC there was just proprietary protocols and shared protocols like Modbus, but they are just lower level transport protocols as you've mentioned.
OPC UA is pretty unique with the Information Modeling, especially. With that feature it is enabling new communication possibilities for higher level systems and applications as well, in addition to plain PLC communication.
Note that some PLCs can also talk OPC UA natively, which makes it a standard in that way.
And OPC UA is really standardised as IEC 62541, ensuring that it's independent.
Update 17/07/19: OPC UA is now defined also as the Industry 4.0 Communication as I wrote in my recent article.
Update 20/05/05: OPC UA version 1.04 defines Pub/Sub alternatives, using UDP for secure data multicast in local networks and AMQP/MQTT for secure broker based data & event delivery to cloud systems. Version 1.04 also defines a WebSocket/JSON protocol alternative, which enable easier usage in web applications. None of these are broadly available, yet, but hopefully will become popular in 2020-21 time frame.
OPC-UA has some very interesting parts, especially concerning information modelling, interoperability and the publish/subscribe pattern.
However, even though it's a standard in the strictest of senses, I've found that to use it in a webapp you need to code a gateway server. Because it uses raw sockets and a binary (although fast) serialization protocol.
This is why we created an alternative protocol called Woopsa at my university. We decided to base it on HTTP + JSON. We tried to make a protocol that's similar to OPC-UA: it has Information Modelling, publish/subscribe, and even multi-requests. It's all completely open-source.
We've just released version 1.0 here: http://www.woopsa.org/
You can get the source code directly on our GitHub: https://github.com/woopsa-protocol/Woopsa
Basically, our protocol is just a standardized RESTful API using HTTP+JSON. For example, you can read a value by making a GET /woopsa/read/Temperature and it will reply you in JSON:
{"Value":24.2,"Type":"Real"}
You can also get the object tree by using the meta word, for example: GET /woopsa/meta/ which will give you something like that:
{
"Name":"WeatherStation",
"Properties": [
{"Name":"Temperature","Type":"Real"},
...
],
"Methods": { ... }
"Items": [
"Thermostat",
...
]
}
In a practical industrial application, MQTT is not an alternative to OPC-UA. The original goal of OPC, back in the '90s, was to provide a standard communication mechanism and data model that would provide interoperability among clients and servers that implemented the specification. OPC-UA expands and generalizes the data model and the communication without giving up on that core goal. In order to do this, the standard must specify things like the format of a time stamp, the encoding of data types, historical values, alarms, etc.
MQTT is a message transport layer that does not provide interoperability by design. It does not stipulate the format of the payload, does not specify how one transmits a particular data type, timestamp, value, hierarchy, or anything else that would allow an application to understand the data being transmitted. You can create a valid MQTT server that emits XML, JSON, or custom formatted data that is plain-text, encrypted, base-64 encoded, or anything else you like. The only way a client application can interact with your server is by knowing in advance what data format the server will produce and accept.
OPC-UA has recently introduced a publish/subscribe mechanism to improve bandwidth utilization, reducing a communication bandwidth advantage that MQTT currently offers. At the same time, the MQTT specification will need to grow to specify data formats in order to promote interoperability. Expect to see a convergence of functionality between MQTT and OPC-UA, mostly MQTT growing to meet OPC-UA.
MQTT is a much simpler implementation at the moment, which holds advantages for embedded and resource-constrained systems. The addition of a data modeling specification would act to reduce this advantage.
The bottom line is that OPC-UA is for interoperability and MQTT is for simple custom communication. MQTT needs to grow before it can be an alternative to OPC-UA.
MQTT is growing in popularity as the protocol of choice for I.o.T. It does have its short comings - however its simplicity is often seen as a strength whereas OPCUA carries the overhead of design by committee.
If you need to combine the two, you may like to consider trying our simple gateway mqtt2opcua
Unserver is a product designed to solve the exact problem described in this question.
It is capable of talking to different field devices and provide a unified HTTP API on
top of them.
It integrates with devices via Modbus RTU, but other common protocols will be added in the future.
In short, first you configure a data 'tag' like this:
{
"name": "tank1",
"device": "plc1",
"properties": [
{
"name": "level",
"address": "HR0",
"type": "numeric",
"raw": "int16"
}
]
}
Then you can work with the tag using an API endpoint created automatically:
GET http://localhost:9000/tags/tank1
{
data:{
level: 1
}
}
Check out the documentation for more info.
The product is free for evaluation and non-commercial use.
Disclaimer: I'm part of the team. Hope this is useful.
I just released another approach to this challenge. The project is called ELTRA IoT.
It's cloud service as mediator and end-user components that act as device representation or operator interface (https://www.eltra.ch/)
Primarily, it was created to simplify integration of CANopen devices with smartphone applications, but I quickly realized, that it can be used for any IoT project.
This project is inspired mainly by CANopen and FDT architecture.
The first idea was to deliver the solution, that allows bringing your device into internet using web standards like REST/JSON (avoid binary protocols, gateways, firewall, proxies issues and all this staff, that makes this whole process more complicated) within short time.
Web standard like HTTP/REST/JSON/WebSocket plays well with all operating systems and architectures and allows also easy end-user app integration in any modern language.
Main features:
Same API both sides (device and operator)
CANopen CiA-311 data model representation
Nodes, object dictionary, index, subindex, strong data typing, ranges etc. You know CANopen = you are at home
History data
RPC support - custom commands execution
Simple cloud service API https://eltra.ch/docs
Standard authentication scheme
SSL encryption
Cross-platform solution for Windows, Linux, Android, IPhone, Raspberry PI
SDK is available as open source on Github:
https://github.com/eltra-ch/eltra-sdk
At the moment, the library is implemented in .NET Standard and tested with Windows, Linux (x64 and ARM32), Android, IPhone.
Nuget package is available under:
https://www.nuget.org/packages/Eltra.Connector/
If the complexity of OPC UA is an overkill and Woopsa doesn't fit your design, then ELTRA could be an alternative.
disclaimer: This project is part of my masterthesis and eltra.ch service is my privately held website