Article
Don’t get sidetracked: Connecting the residential IoE | The Beacon (Wi-Fi.org)
My Comments
Appliances like this coffee machine are now working with dedicated mobile platform apps.
As the “Internet Of Things” or “Internet Of Everything” becomes ubiquitous in one’s lifestyle, there will always be some key issues with implementing this concept. It doesn’t matter whether it is for our health, wellbeing, convenient living or security that these issues will come in to play.
The core issue around the initial complexities will be due to use of network transports that don’t work on Internet-Protocol methodologies that have been established well before the Internet came to fruition in the mid-1990s. Rather, some of these implement an industry-specific data transport that requires the use of a so-called “bridge” between the non-IP transport and the IP transport.
Current implementation issues
Filling your computing devices with apps for each device and cloud service
The Internet Of Things should be about allowing these smart locks to work with other home-automation devices
At the moment, a lot of devices that offer control by smartphone require the use of vendor-developed apps and as you add more devices with this capability to your network, you end up filling your mobile device with many different apps. This leads to user confusion because you end up with having to work out which app you use to work with which device.
The same issue also affects cloud-based services where each vendor impresses on users to use the vendor’s supplied apps to benefit from these services. Again this leads to operator confusion which typically we would have noticed when we use social-media, over-the-top messaging or cloud-storage front-ends on our computing devices for each social-media, messaging or cloud-storage service.
This kind of situation makes it harder for one to develop software that makes best use of a device’s functions because they have to engineer a device to work specifically with a particular vendor’s devices. It brings us back to the days of DOS-based software where games vendors had to write the driver software to allow their software to interface with the computer system’s peripherals. This made it harder for customers to determine if that program they are after was to be compatible with their computer hardware.
Home-control systems and the home network
One issue that was highlighted was linking devices that use non-IP networks like Zigbee, Z-Wave or Bluetooth to the IP-based home network which works on Cat5 Ethernet, Wi-Fi and/or HomePlug. Typically this requires the use of a network-bridge device or module that connects to one of the Ethernet ports on the home-network router to link these devices to your home network, the Internet and your mobile devices.
Multiple bridge devices being needed
… such as this room thermostat
The main question that was raised was whether we would end up with multiple bridge devices because each non-IP sensor or controller system was working in a proprietary manner, typically bound to a particular vendor’s devices or, in some cases, a subset of the devices offered by that vendor.
The worst-case scenario is a vendor who implements a Zigbee-based distributed heating control system for a UK-style hydronic central heating system that has thermostatic radiator valves for each radiator. In this scenario this system’s components will only link to the Internet and home network using the network bridge supplied by that vendor even though it works on the Zigbee network. But if you introduce a lighting system provided by another vendor that uses Zigbee technology, this system may require the use of another bridge that is supplied by that vendor for network-based lighting control.
Support for gradual system evolution
Also there is the issue of installation woes creeping up when you install or evolve your home-automation system. Some of us like the idea of “starting small” with local control of a few devices, then as funds and needs change, will change towards a larger more-capable system with Internet and mobile-device connectivity. The issue that is raised here is that a vendor could impress upon us to buy and install the network bridge before we start out installing the home-automation devices rather than enrolling the network bridge in to an established control system at a later date. In some cases, you may have to perform a reset operation upon all of the existing components and re-configure you system when you install that network bridge.
This also underscores the situation where a vendor may allow in-place upgrading and integration of a device known to have a long service life like most major appliances, HVAC or building-security devices. This is typically achieved through the use of an expansion module that the user or a technician installs in the device and this device gains the extra functionality. Here, it should be required for the device to be integrated in to the “Internet Of Things” network without you having to reset your network or do other difficult tasks.
To the same extent, one could easily start a system around one or more older devices, yet install newer devices in to the system. For example, you have a UK-style central heating system that is based around an existing boiler that has support for an advanced heating-control system if you choose to have a control module retrofitted to that unit and this module has an LCD touchscreen as its user interface.
You purchase this module and ask the central-heating technician to install it in your boiler so you can save money on your fuel bills. Here, this system uses a room thermostat which you start out with but also can work with thermostatic radiator valves and you buy and attach these valves to the radiators around the house to improve the heating efficiency and these devices work together properly, showing the results on the module’s LCD touchscreen.
Subsequently the boiler reaches the end of its useful life and you replace it with a newer more efficient model that has integrated support for the heating-control system that you implemented but in a newer form. Here, you don’t want to lose the functionality that the room thermostat or the thermostatic radiator valves offered, but want to fully benefit from what the new unit offers such as its inherent support for modulated output.
Needs
Task-focused application-level standards
The needs highlighted here are to implement task-focused application-level standards that work for the purpose of the device and support a simplified installation routine. As well, the role of any bridge device implemented in an “Internet Of Things” setup is to provide a proper application-level bridge between different medium types independent of device vendor.
But what are these task-focused application-level standards? These are IT standards that are focused on what the device does for that class of device rather than the device as being a particular model from a particular vendor. An “Internet Of Things” example would be a smart thermostat that is known to the other devices as a “HVAC thermostat” with attributes like current temperature, setpoint (desired-comfort-level) temperature, setpoint schedules and other comfort-control factors. This makes it easier for other devices to interact with these devices to, for example set up a situation-specific “preferred” room temperature for your heating when you use a particular user-code with your building alarm system or have a weather-forecast service cause the temperature to be adjusted in a manner to suit an upcoming situation.
Some good examples of the application-level standards are the UPnP Device Control Protocols for IP networks, or the Bluetooth application profiles. In one case, the Bluetooth Human Interface Device profile used for the Bluetooth keyboards, mice and remote controls was based on the USB Human Interface Device standards used for these similar devices. This simplified the design of host operating systems to design interoperability with Bluetooth and USB input devices using code that shared the same function.
Ability for a fail-safe network
An issue that is starting to crop up regarding the Internet Of Everything is being sure of a fail-safe network. This is in the form of each device in the network always discovering each other, control devices controlling their targets every time and sensor devices consistently providing up-to-date accurate data to their target devices.As well, a device that has a “standalone” function must be able to perform that function without being dependent on other devices.
Some devices such as smart locks have to he able to perform their essential functionality in a standalone manner if they lose connectivity with the rest of the network. This can easily happen due to a power cut or a network bridge or the Internet router breaking down.
Network bridges that work with multiple non-IP standards
As well, manufacturers could be challenged to design network bridges that work with more than two connection types such as a bridge that links Zigbee and Z-Wave home-automation devices to the one IP network using the one Ethernet connection.
This would include the ability to translate between the different non-IP standards on a task-based level so that each network isn’t its own silo. Rather, each device could expose what it can do to or the data it provides to other devices in the same logical network.
This may come to the fore with the concept of “meshing” which some standards like Zigbee and Z-Wave support. Here, a network can be created with each node being part of a logical mesh so that the nodes carry the signals further or provide a fail-safe transmission path for the signals. The “bridges” could work in a way to create a logical mesh with IP networks and networks that work on other media to use these other paths to create a totally fail-safe path.
Conclusion
It will take a long time for the “Internet Of Everything” to mature to a level playing field as it has taken for desktop and mobile computing to evolve towards to that goal. This will involve a lot of steps and place pressure on device manufacturers to implement these upgrades through the long working life of these devices.
