We are using the Raspberry Pi with an xBee module for the hub hardware. The App runs locally on the hub and connects directly via local WiFi to a smart phone or other device. No internet connection needed, but an internet connection can be used as an option for remote control, and for Alexa, etc.

For the more technically minded, we have written the hub software in a .Net language in its entirety, from device frame / cluster / end point level up to and including the App / UI.

This is part of a larger project to be able to handle many manufacturers’ in the same way, including both ZigBee and Z-Wave. To date, we have been able to handle over 40 different devices from more than 20 different manufacturers.

How many people might be interested in breathing life back into their AlertMe system in this way?

Sounds very interesting to me! A unified way to control multiple home automation systems from an open source Hub would be a very worthwhile project, as so many of these platforms are abandoned by their original manufacturers, leaving users either with totally useless hardware, or with gear that can no longer be remote controlled.

You’re summary is correct. I would also emphasise that the hub software includes a web server, on which we run a local Web App. The user just needs a smart phone, or any other device with a web browser, which connects by WiFi to the hub, so there’s no need for an internet connection.

As well as catering for legacy devices, such as AlertMe, we’re aiming to exploit the increasing abundance of smaller, cheaper, and better devices that are becoming available. To give you some measure of the ease with which it can be extended to more devices, someone kindly lent us their AlertMe devices on March 3rd, last week, and the system already handles all of them.

We don’t really view it as a home automation system, but rather a fully programmable control system, which happens to use these low power RF devices. Its application should then be limited only by people’s ingenuity in designing their systems, rather than trying to impose any preconceived concept of how it should be used.

We’re not at that stage of being able to release anything more yet, but our thinking is to release it in stages, with the first being a Beta version for AlertMe devices within the next month or so.

I was planning to include the following as an attachment, but the forum doesn't support PDFs.

Its intended mainly to explain the thinking behind our approach.

Smart Home Technology Trends

Founded in 2006, and acquired by British Gas in 2015, AlertMe was one of the main pioneers in the use of smart systems within the home. AlertMe also developed the first generation of the Lowes Iris systems used in the USA.

Many more companies across the world are now supplying products to this sector. An increasing number of cheaper and higher performance devices can be purchased online by anyone. Most of these devices are manufactured in China, as are those sold under the more popular brand names.

The same applies to the hub, with the ready availability of low cost single card computers, which are far more powerful than most of the current branded hubs. Manufacturers have also responded to the need for plug-in USB modules to control the ZigBee and Z-Wave mesh protocols.

Off-The-Shelf Hubs

Anyone can now have a hub capable of running their smart home for less than £50.00, simply by plugging a few off-the-shelf components together.
The latest hub technology is typified by the Raspberry Pi, some 15 million of which have been sold worldwide. Plug-in USB adapters are available from XBee for ZigBee and Aeotec for Z-Wave, amongst others.

Many other single card computers can be purchased for embedded applications, some of which include on-card ZigBee and Z-Wave components.

The data is stored on a micro SD card, which is identical to those used in most smart phones and tablets. The adapters plug into USB ports, which have become a universal standard. These single card computers are powered through a micro USB connector, which has also become the standard for many devices.

Being manufactured in very large volumes, these standard off-the-shelf components are collectively cheaper and have a higher performance and reliability than the current branded hubs.

The cost and availability of hardware upgrades during the life of the equipment is an important consideration for the user, especially as technology continues to advance at a high rate. Replacing an off-the-shelf single card computer with a higher performance version is much cheaper than replacing an entire custom designed hub. The user merely unplugs the ZigBee and / or Z-Wave adapters and the micro SD card, none of which need to be replaced, and plugs them into the replacement card.

The single card computers probably include peripheral connections that are not needed for smart home applications, such as an HDMI output, but, even with these included, they are still much cheaper and more reliable than any bespoke equivalent.

The enclosures that are available for the single card computers may not be as aesthetically pleasing as some of the customised hubs on offer, but the design and manufacture of simple plastic enclosures is not exactly rocket science.

There are those who would try to belittle the use of this off-the-shelf technology, as being hobbyist and amateurish, but why pay more, and why keep re-inventing the wheel?

Hubs built from standard off-the-shelf devices will inevitably be at the heart of future smart home systems.

History Repeating Itself

Prior to the advent of the IBM personal computer in the 1980s, the computers and their peripherals were as diverse as the number of companies manufacturing them. There was no standardisation across manufacturers, and they were costly to buy, setup and maintain, and well beyond the reach of SMEs, let alone individuals.

With the able assistance of Intel and Microsoft, IBM established a hardware standard that still dominates the design of personal computers, laptops and tablets today. It also brought the price of the technology within the reach of most people.

The availability of off-the-shelf hub components, and the multitude of devices from which to choose, will inevitably lead to smart systems for the home following a similar path.

Clouding Over

Most people spend the majority of their time at home, even when they are employed or educated outside of the home. Why should they not be able to control their smart home within their home, and without an internet connection? Why do most smart home systems require an internet connection for their control and operation?

The limitations of the processing and memory capability of the current branded hubs is one reason for this reliance on the cloud.

Modern single card computers are capable of supporting a range of operating systems, as well as running both web services and mobile Apps. For this reason, these limitations no longer exist when a single card computer is used as the basis for the hub. This approach also enables the Apps to be accessed directly on the hub via the WiFi in the home, so there’s no need for an internet connection.

Transferring this processing from the cloud to the local hub also distributes the processing load and reduces costs. Any processing and memory usage in the cloud incurs an ongoing cost, normally in the form of a monthly subscription charged by the service provider. When this processing is transferred to a hub, there is no ongoing cost, because it has been paid for already within the price of the hub. Coupled with the lower cost of the off-the-shelf hub components, this represents a significant overall cost saving over the cloud based alternative.

Very importantly, the dedicated local processing on the hub provides an immediate response to any user command, whereas the delays in the cloud based systems are all too evident. These delays are due to the time taken for data to be sent to the cloud for processing, and then returned from the cloud, and the relatively slow shared processing in the cloud.

Isolating the smart home system from the internet also assures its security, and the user’s privacy, which are major concerns for the majority of users, as well as removing the internet connection as a potential source of unreliability.

The cloud is still used for the initial user / hub / software registration, and for remote access, when needed, but the load placed on cloud services is a small fraction of that imposed by existing smart home systems.

There are other obvious benefits to having an internet connection, such as being able to access local weather conditions, and local sunrise and sunset times, as well as enabling the use of Alexa or Google Assistant. Again, these should be optional facilities, and not mandatory for controlling the smart home.

Having the software running locally on the hub also improves the level of support and maintenance that can be provided to the user. Subject to the user’s permission, this enables the hub to be accessed remotely by a support team. The precise circumstances being seen by the user can then be replicated under remote control, and immediate action taken to correct the operation of the system, including the settings on the hub.

Software

There is one missing link, which is the software that controls the smart home.

Our hub software communicates fully with a wide range of ZigBee and Z-Wave devices. To date, several different devices from each of the following brands have been tested successfully:

This testing is being extended to other protocols, but the focus has been on ZigBee and Z-wave, because they cover the majority of the lower power mesh based devices in use today.

It is also our intention to cater for some of the earlier devices, which either cannot be used or have restricted use, due to the loss of their cloud based server support. The software has been tested successfully with Hive V1 receiver and thermostat, and most of the older AlertMe devices, all of which were kindly loaned to us by James Saunders. A range of 1st generation Lowes Iris devices has been purchased from the USA for testing, which we expect to be delivered within the next two to three weeks.

Every device tested to date has also been profiled, which enables them to present a standardised generic interface to the rest of the software. For example, a standardised door / window sensor interface has been provided for all of the following devices:

Having standardised these device interfaces, neither the control programs, nor the mobile App, depend on the specific characteristics of the individual devices being used.

The hub programs are only part of the complete software suite, which also includes the supporting cloud software for user / hub / software registration, and for remote access.

The entirety of the software is written by us, and without reliance on any third party software or firmware. It is written in Microsoft C#, which is the most commonly used Microsoft .Net language, and which we have been using to develop applications for over 15 years. The software suite draws on an extensive C# library, which we have also developed over the years.

Being written in a Microsoft .Net language, the underlying classes can be exposed for use by other .Net programs.

We will be adding more videos over the new few days and weeks. They will have separate pages within the same domain.

If you have any feedback, or comments, then please use this forum.

There is also an enquiry form on the video page for anyone interested in using the software, and helping with the Beta testing. The software will be supplied on a micro SD card for use with a Raspberry Pi 3B.

We have uploaded another video. This one describes the range of devices that we have tested successfully with the new hub software.

Our approach has been to start with the ZigBee HA standard, and then investigate the characteristics of individual ZigBee HA devices. We then repeated this process for Z-wave devices.

On investigating the older AlertMe devices, we discovered that they were compliant with an earlier non-HA standard. We then discovered that the first generation Iris devices, which were developed by AlertMe, were also compliant with this earlier standard.

We have also investigated the characteristics of these earlier ZigBee devices.

A video describing each of the 50 plus devices from 30 plus manufacturers that we have tested can be viewed at this URL:

We have profiled each of these devices such that when they join the network, all of their clusters / endpoints / attributes are made accessible to the system.

The events that each device generates, and the associated data, is brought up to a common level for use within the rest of the system. This, for example, enables a door / window sensor to be handled as generic type, rather than a specific manufacturer’s sensor, and regardless of the network protocol being used.

Some of the narration is rather repetitive on this aspect, but our approach is fairly unique, and it makes a big difference to the rest of the system design.

We will be expanding on the use of this data, such as for actions, for system health monitoring, fault diagnostics, etc. in future videos.