Digital transformation has been one the main strategy topics on company board meeting agendas for the last few years. The opportunity to develop digital services from cloud-based applications requires Internet protocol (IPv6) based network connections to edge devices that become the customer interface. Business of all shapes and sizes in commercial building automation have been asking for wireless IoT solutions to make this happen, KNX responded to this challenge by releasing KNX IoT Point API (KNX IoT).

The basics

To ensure backwards compatibility with the other KNX media, the KNX IoT specification in the KNX system specifications group (3_10_5 KNX IoT Point API) describes:

• A new transport layer based on IPv6, e.g. WiFi, Ethernet and Thread-based networks.

• A new communication/message protocol that allows:

• The configuration of device is talking to which device.
• The support of S-mode message
• Capable of the following communication modes
  • Point-to-Multipoint, Connectionless (Multicast)
  • Point-to-all-Points Connectionless (Broadcast)
  • Point-to-all-Points Connectionless (System Broadcast)
  • Point-to-Point, Connectionless
  • Point-to-Point, Connection-Oriented

• Using the same functional blocks as the other KNX transport layers (volume 7).

Note that the KNX devices without configuration are servers. E.g. the configuration of the devices will cause that the xxx will send 

The Technology stack

IPV6, the IPV6 means that the devices can be communicated with IPv6, regardless of the used physical layer. Hence it means that Ethernet (including PoE), WiFi and Thread is supported. Note that Thread is IPV6 based.

Discovery

To communicate over IP, one needs to know the IP address and port of the KNX device. To obtain this data, 2 different discovery mechanisms are used. 

mDNS discovery is a protocol that uses multicast DNS (mDNS) to find devices and services on the local network without knowing their IP address. It is also known as zero-configuration, Bonjour, or Avahi. It is widely implemented for smart home devices, wireless Arduino devices, printers, speakers, network storage devices, etc. It works by sending packets to every node on the network to resolve host names and query for services. It can be used with DNS Service Discovery (DNS-SD) to browse and resolve services based on either the host name or the service. It only works for the .local top-level domain (TLD).

mDNS discover allows discovery by:

• Serial number
• Individual address
• Programming mode

The CoAP discovery is a special CoAP request, to discover the resources of a known host. To discover the host, a multicast request may be used, but must be supported by the server. “localhost” is the address of the device itself.

CoAP discover allows discovery by:

• Serial number
• Individual address
• Programming mode
• Discovery of a device contains a specific data point
• Discovery of a device that contains a specific functional block

Telegram transports

The next level up is communicating over IPV6 using Constrained Application Protocol (CoAP). This is the layer that transports the KNX telegrams from the sender to the destination. This is achieved by using URLs. The easiest way to look at CoAP is that it is equivalent to HTTP, implementing sending messages in with the request and response paradigm, between a Client (initiator) and Server (responder). The main difference between HTTP and CoAP is that the CoAP headers are in binary format and that CoAP works over UDP.

The verbs for issuing the messages are the same:

• GET, for retrieval of data
• POST, for partial update of data
• PUT, for full update of data
• DELETE, for deleting a resource

And OBSERVE, a new function that is similar as HTTP long poll. The Observe can be used to obtain multiple responses. For example; when the data changes a new response is send to the observe request. To have the same reliability as HTTP over TCP, the CoAP protocol implemented confirmed transfers. Hence the resending of the packets when not acknowledged is part of CoAP and therefore CoAP confirmed request are as reliable as HTTP over TCP.

The payload of a message is determined by the content type, e.g. different formats can be supported, similar as HTTP.

Payload types

The KNX IoT specification is using 2 content formats, each for a different function.

The listing of the URLs (data points/functional blocks) to interact with and the interaction with the URLs.

The Application-Link format 

This content format allows to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. A well-known URI is defined as a default entry point for requesting the links hosted by a server.

Typical response example:

<auth/at>;rt=“urn:knx:fb.at“;ct=40,

<dev>;rt=“urn:knx:fb.0“;ct=40,

<swu>;rt=“urn:knx:fb.swu“;ct=40,

<f/rts>;rt=“urn:knx:fb.321“;ct=40

Each line contains 

• The hosted URL (between <>)
• The resource type (rt), designating what it is.
• The content type, e.g. 60 for CBOR and 40 for Application-Link Format

This allows the client to interact with the device on URL basis.

Interacting with a device

The URL can be seen as a data point that can be interacted with via key value pairs. The Key value pairs are described with Concise Binary Object Representation (CBOR). CBOR is a binary data serialization format loosely based on JSON. Like JSON it allows the transmission of data objects that contain name–value pairs, but in a more concise manner. This increases processing and transfer speeds at the cost of human readability. However this opens up the documentation: define the payloads in JSON to increase human readability of the specification and have the binary format on the wire. 

The data for an S-mode message it can be defined in JSON:

{ “s”: { “st”: “the st value” , “ga”: “the ga value”, “value”: “the value” } }

The JSON keys can be replaced with integer values to shrink the message even further in size:

{ 5: { 6: “the st value” , 7: “the ga value”, 1: “the value” } }

Security

OSCORE (RFC 8613) encrypts the application layer request/response messages between endpoints: not only the payload containing the value associated with a resource is encrypted, but also the request method, the identifier of the resource, and the content format of the payload. In this way, the application relevant data and semantics of the request/response can be protected in a way which is decoupled from the transport of the messages, while being lightweight in terms of overhead.

In addition to CoAP, OSCORE also uses the Concise Binary Object Representation (CBOR) for compact encoding and the CBOR Object Signature and Encryption (COSE) for encryption and key derivation structures – both designed for constrained device operations – and further compressed with OSCORE by omitting redundant information. OSCORE has built-in identifiers enabling end-to-end operations over multiple different paths with or without IP.

The message overhead is minimal since OSCORE protects only the relevant application layer information and the amount of data added to the size of the original CoAP message can be as low as 11-13 bytes with built-in identifiers. OSCORE has been instrumental in defining the level of overhead for lightweight communication security and outperforms state-of-the-art transport layer security.

Bringing everything together

Now all communication mechanisms are explained. KNX IoT device has a set of URLS to List which functional blocks and data points are implemented and have URLS to configure the device.

For example, there are resources (datapoints) for configuring the device. Existing concepts as Load State Machine (LSM), programming mode (PM), individual address (IA) and Group Object Table are modelled with the above-described mechanisms.

As a result, the following IETF specifications are referenced in KNX IoT Point API specification:

Summary

The advantages of KNX IoT are that the new technology is IP-based and can therefore be used over IT networks. It has been developed with guaranteed interoperability with existing KNX technology, and it uses latest underlying internet-based technologies in its specification, thereby making KNX IoT secure by design.

The specification has been designed with embedded devices in mind, and the open source stack implementing KNX IoT has been shown to be quite small, running with as little as 512kB of storage memory and 96kB of memory. 

Bruno Johnson and Wouter van der Beek are the CEO and COO respectively of Cascoda Limited. Cascoda is a communications company that manufactures secure IoT semiconductor radios and modules, and leads the development of secure IoT communications standards for smart building and smart city. Its products solve range, reliability, security, power and scalability issues for industrial and commercial IoT through patented innovations and the latest most secure standards, all integrated into inexpensive ultra-low power IoT modules.Smart City,Io

Click here to read full February issue – https://www.smarthomeworld.in/magazine-february2024/

The post Unlocking Smart Building KNX IoT Connectivity appeared first on Smart Home World Magazine.

D-Link Corporation is thrilled to unveil its latest addition to the AQUILA PRO AI family – the M60 AX6000 Smart Mesh Wi-Fi 6 system. Striving to provide a worry-free and superior connectivity experience, this MIT (made in Taiwan) Smart Mesh system has passed rigorous engineering and verification processes to ensure exceptional and reliable performance. With the capacity to connect more than 30 devices simultaneously, the AQUILA PRO AI M60 empowers users to stream multiple 4K/8K movies, engage in online gaming, and enjoy uninterrupted video calls, all without a hint of delay.

The M60’s elegant appearance is inspired by the concept of the Aquila constellation and the majestic eagle, making it a tasteful addition to any modern home environment. Whether horizontally or wall-mounted, it showcases technological beauty without compromising your home’s aesthetics.

Smart Connectivity Through AI
The AQUILA PRO AI M60’s smart connectivity leverages an AI algorithm, including AI Wi-Fi Optimizer, AI Mesh Optimizer, and AI Traffic Optimizer. These capabilities enable optimal channel selection to minimize interference, auto path selection and self-healing for dynamic traffic routing, and AI-based QoS technology that prioritizes real-time applications for a seamless experience.

Unparalleled Wi-Fi Coverage
The AQUILA PRO AI M60 Smart Mesh system boasts a unique 8-internal antenna array design that strengthens Wi-Fi signals, providing spherical coverage and eliminating dead spots. A 3-pack Smart Mesh system that covers up to 8,000 square feet ensures uninterrupted Wi-Fi connectivity from the backyard to the front door.  

Ultra-Fast Speed
Through Wi-Fi 6 technology, the AQUILA PRO AI M60 delivers lightning-fast wireless speeds of up to 6 Gbps. With a 160 MHz channel bandwidth, Wi-Fi 6 provides significantly faster speeds than Wi-Fi 5 (80 MHz bandwidth), even with multiple connected devices. The M60 features a 2.5-gigabit Internet WAN port and four Gigabit LAN ports for wired devices such as smart TVs and gaming consoles, making it ideal for bandwidth-intensive applications.

Enhanced Security
The AQUILA PRO AI M60 complies with the latest WPA3 encryption, IEC 62443-4-1, and ETSI EN 303 645 cybersecurity standards, making it a safer and more secure router to safeguard the network against unauthorized access and protect smart home IoT devices. Advanced parental controls and guest Wi-Fi help keep the whole family safe without compromising network security.

Easy Setup and Management
The intuitive AQUILA PRO AI app makes setup a breeze with just a few taps. The AI Assistant monitors network performance and provides weekly reports, even when you are away from home. The M60 is compatible with Amazon Alexa and Google Assistant for convenient voice-controlled management of smart home devices.

Eco-Friendly Design
The AQUILA PRO AI M60 adheres to the “D-Link Green” program by using post-consumer recycled (PCR) materials for the product chassis, a 99% natural plant-based Mineral Oil Free (MOF) ink for packaging and minimizing components to reduce carbon footprint. Health mode automatically turns off the router during bedtime hours to conserve energy and help improve rest, while the Target Wake Time (TWT) feature helps to ensure energy efficiency and extends device battery life.

Product Availability
The AQUILA PRO AI M60 Smart Mesh system will be available initially in Taiwan at the end of December. Global availability will be Q1, 2024.

For more information https://www.dlink.com/en/products/m60-ax6000-wi-fi-6-smart-mesh-router

The post D-Link’s AQUILA PRO AI Series Introduces New M60 AX6000 Wi-Fi 6 Smart Mesh System appeared first on Smart Home World Magazine.

Later this year, Samsung’s SmartThings app will receive a significant update. The next software update will include support for Philips Hue Sync on Samsung smart televisions.

Samsung is already working on the next SmartThings update. It is a significant update because it will contain various modifications to app functionality as well as expanded compatibility for IoT/smart home devices. More information on the latter is scheduled to be released by the company in September.

Aside from the enhanced UI, the upgrade will allow Philips Hue Sync to effectively synchronise colours and settings on compatible Samsung smart TVs and monitors based on the show or music.

Govee and Nanoleaf will both feature similar rhythm capabilities on their smart devices. Govee smart lights would be able to sync with the Razer Chrome RGB when playing games.

The post Philips Hue Sync comes to Samsung TVs via a major SmartThings update. appeared first on Smart Home World Magazine.