HomeDaemon MCP

HomeDaemon-MCP - The Future of Home Control

HomeDaemon-MCP is the answer to home control, security and monitoring. Designed from the ground up to address privacy, security and performance it embodies a feature set and collection of capabilities unique in the marketplace leveraging international standards, industry-leading encryption and performance second-to-none on inexpensive, reliable commodity hardware.

The package is available now to the entrepreneurial-minded home builder, contractor or technology firm interested in entering or greatly-bolstering a presence in the rapidly-growing "Internet of Things" space.

Key points:

The package is able to be controlled and interacted with from anywhere via either a web browser or Android app interface, both of which are included. The server interface is internal to the HomeDaemon-MCP code and does not rely on external software (such as Apache, ngnix, etc) thus greatly reducing the potential attack surface for an intruder.
A master/slave(s) relationship is supported, allowing multiple controllers to be seen as one in a given home; this is particularly useful where a secondary control point would be most-conveniently located near irrigration or pool control equipment, for example, or where a secondary building (e.g. a guest house, etc) is part of the installation. Any number of slaves are supported and slave unit integration is controlled through machine certificates, insuring that potential intruders are unable to penetrate into the controlled environment even if the slave units are linked over WiFi (or even an Internet connection.)
There is no "fixed" set of conditions for an event to take place; rather, there is an english-like language supported for event tests which, when satisfied, result in the desired action(s) being taken. Both "and" and "or" conditions are supported along with immediately-recognized triggered events (e.g. on a contact closure, on a button press, on the garage door being opened, etc) which may be combined in any way you desire. Unlike many competing systems this allows near-infinite flexibility in terms of what the system responds to, and how.
The code is written entirely in "C" for efficiency and performance. Unlike other products this means the system is both much faster and consumes far less memory and CPU, resulting in better performance on much less-expensive -- and near-zero power consuming (average ~5 watts!) -- hardware.
Inexpensive 12 and 16-bit analog ($10/4 channels) and digital relay (~$20/8 channel) input and output capability is internally supported, making pool controller applications, irrigration (with moisture sense and/or rainfall) and similar easily setup and configured. Multi-zone HVAC can also be handled using the same paradigm.
Z-Wave support is fully available including AES-encrypted unit handling for those devices that are capable of functioning in encrypted mode. The latter includes but is not limited to locks,garage door controllers and various forms of sensors.
Complete integration with many IP-based cameras, including the entire Amcrest line, is fully supported including both video and audio, secure tunnelling of traffic, secure off-site copy-stream-on-event (e.g. to a personal cloud service or your office), lookback (e.g. "store to disk the last 4 minutes before the alarm condition occurred along with all footage until the alarm condition ceases plus next 5 minutes"), full-time "security-style" archiving to a local or remote disk and complete, real-time control. In addition the camera sensors, if available (e.g. motion, sound, etc) are available as event triggers for the software itself. Camera capacity is limited only by available network bandwidth, system CPU, storage and RAM; even a Pi3 can handle 8 or more cameras, all with real-time logging in operation, given appropriate camera settings.
For those with legacy X10 devices in their home X-10 is supported via the CM11a serial interface using an inexpensive USB serial dongle. Note that X-10 is considered a "legacy" option and should not be used for new installations, as it is slow, does not offer any sort of security or supervision of devices and in fact doesn't even allow polling to determine status. Z-Wave suffers from none of these infirmities and, for those devices supporting it, also offers near-impenetrable AES-encrypted transport of messages.

Existing "Home Control" and "Security" appliances have shortcomings that are annoying, limiting, potentially insecure or worse. HomeDaemon-MCP has been designed to mitigate these issues and many more; click each of the icons below for a full explanation in a new window.

Problem: Cameras are great. The let you see inside your home when you're not there, along with the periphery. Modern IP-based cameras are inexpensive and available in many configurations, such as indoor "tilt and swivel" models along with units in weather-resistant housings intended for mounting outdoors. The problem is that they are inherently insecure; they have low-powered CPUs in them for cost reasons, they all try to insist on various "cloud" connections never mind being made and designed in China with who-knows-what sort of back doors in them that could give unwanted visitors access to images and video from inside your house.

Problem: Locks and other access control devices (e.g. garage door openers) have AES-encrypted (highly secure) options for control, but the "pairing" process is fraught with risk. Existing controllers poorly handle this, having intentionally sacrificed security on the altar of "convenience", making possible theft of the network security key after which any and all "encrypted" traffic could be intercepted or modified from more than 100' away -- more than enough to tamper with your house from next door or in the street. This, theoretically at least, could allow a thief to command your door or garage to open for him!

Problem: Existing systems all rely on the "cloud" in some fashion or form. But "cloud" computing is inherently insecure due to computer design priorities that put performance before security, never mind being fraught with the risk that if a server goes down hundreds of thousands or even millions of consumers lose monitoring and control access at once!

Problem: "Skills" loaded to a device from some third party inherently rely on trust you place in someone else to not misuse your data or worse, spy on you intentionally. The incentives to violate your trust or spy on you are great and the penalties for firms caught misusing your data have never resulted in a single criminal prosecution of anyone, ever, in the history of these devices and companies. There is no incentive for a firm not to do this sort of thing because any "penalty" is always limited to a fine (and then only rarely), which is simply passed on to you in the form of higher prices.

Problem: Storing passwords on a mobile device is fraught with risk for all the obvious reasons, yet most apps do exactly that, again for alleged convenience.

Please see the Release Notes included in the distribution file along with the system manual for more information including important limitations that are present in the Freeware distribution; both are provided in PDF format. Note that the Freeware version does not include many features that are reliant on security, including Amcrest camera integration, slaved devices or any other form of secure access (such as AES-encrypted Z-wave communication), and implements neither scripting protection nor does it hash passwords. For a complete, up-to-date manual please make contact for both the "full version" manual and release notes.

The freeware distribution is available as a NanoBSD 12-STABLE image in "xz" format which 7-Zip can decompress on Windows; Win32DiskImager is capable of writing the resulting image file to an SD card. The image file is quite large (200-300MB) as it contains a full operating system along with support packages for functions such as machine-generated speech; please be patient!

A Raspberry Pi2 NanoBSD image is here: Raspberry Pi2 NanoBSD
A Raspberry Pi3 NanoBSD image is here: Raspberry Pi3 NanoBSD

Note for NanoBSD images: These images are pre-built and power-failure safe since they run with the SD card mounted read-only except when modifications are being explicitly saved. This means you can play with the configuration, not execute an explicit save, and pull the plug to revert to the last-saved (or delivered, if not yet saved) configuration at any time. There is a script called "cfgsync" in the ~root/bin that will synchronize the running configuration with the saved configuration and it must be used by a logged-in root user any time the system configuration is changed, including password changes. The NanoBSD versions and are not configured to sync time because there is no guarantee that a network interface, which is required to get time sync, will be available. Note that "ntimed" is included should you wish to use a lightweight time sync solution. By default the NanoBSD builds will start a web server for HomeDaemon-MCP on the unit's DHCP-acquired address off the internal Ethernet port, running on port "8080"; the administrative password to sign in to the web server has the account "admin" and the password "password", and both the Release notes and Documentation files (in PDF format) are accessible from it without logging on.

NanoBSD builds are COMPLETELY unsecured "as delivered"; if you intend to use them on a network visible from the outside world you must immediately secure it, specifically by signing into the "freebsd" user account (the password is "freebsd") and changing it, along with using "su" to set a root passwordand then using the above-documented "cfgsync" program to save the password changes. This NanoBSD build is configured with both the Pi standard serial console and the HDMI console enabled; connecting the Pi to an HDMI-enabled display and USB keyboard is a suitable means to access it for configuration purposes if you do not have a Pi-style TTL serial cable. You should set the time before using these builds on each boot as the system does compute sunrise and sunset, among other things, from the current date and of course time-dependent events require that the time be properly set -- thus either setting up "ntimed" or manually setting the date is strongly recommended.

Please contact Karl by email at info@cudasystems.net if you are interested in potentially acquiring all rights, including source and redistribution, for this package or have questions about these distributions. At this time single licenses of the full code for individual users are not available.

As an example this is the web interface presented for my house; it is an actual real-time screen grab with two units slaved, the second controlling the pool and hottub equipment transparently. All state is updated in real time. The fans in the below screen grab rotate on your screen when they're "on". The percentages on motion detectors are the remaining battery power; the time shown is when motion was last detected at that location. Everything else is pretty self-explanatory (the embedded camera images are intentionally blurred out for obvious reasons :-)).