Connected Devices/Projects/Project Link

This experiment has concluded. We have retained the content on this page so others can take advantage of these learnings. For the latest on what Mozilla is doing, visit www.mozilla.org.

Project Link
Author(s)
Mozilla
Released
2016.01.11 (Initial Pitch)
2016.01.11 (Pitch Update)
Innovation Status
No longer an approved project
Website
N/A

After the successful completion of a Project Link prototype and further study by team members, the team closed Project Link and pivoted to a project called Cue, that is focused on making the lives of busy families easier by using voice and a smart screen to manage reminders, lists, and schedule coordination. Please visit the Project Cue wiki for information about the learning taken from Project Link that has resulted in the studies and experiments being conducted for Project Cue.

If interested in learning more about what Project Link was and what experiments were conducted, please read further.

Project Link had a goal of being your own, personal user agent for the smart home, creating a web of things that is completely yours. Instead of entrusting your data to a third party, a goal of the Link agent was to understand your preferences for how you wanted to interact with the world of devices in your home, and to automate your connected world for you. All of this still was to be done conveniently and securely, but completely under your control.

Project Overview

Project Link (formerly Foxlink) was a short-term experiment to build software building blocks that can interact with various "things". Most code was done in Rust.

We used the "Design Thinking" innovation approach by IDEO, where the philosophy of Product Innovation is at the center of technology (feasibility), person (desirability) & business (viability).

Validation Stage

In the Validation stage, the Link team conducted investigations and studies to answer the questions:

• Does it fit the Mozilla mission?
• Is there a problem worth solving?
• What is the MVP?
• Is it something customers want?
• Can it be solved?

Early in the Validation stage, the team experimented with consumer smart devices available today, as described in Phase 1 in the Archive section below, and developed a prototype that enabled device discovery, rule configuration for how the devices should automatically interact, and the push of notifications to the user.

Team Participants

• Aleh Zasypkin
• Andrew Osmond
• Christiane Ruetten
• Dave Hylands
• David Rajchenbach-Teller
• Fabrice Desré
• Fernando Jiménez Moreno
• Francisco Jordano
• Guillaume Marty
• Hema Koka
• Johan Lorenzo
• Julie McCracken
• Julien Wajsberg
• No-Jun Park
• Preeti Sanketh
• Sam Giles

Development

Proposals

• Home Automation Hub
• Intelligent Calendar for Busy Mums
• The Home User Agent
• Voice browser

Technical documentation

• Straw-man PoC description on etherpad
• Google Drive folder
• Box-Client networking (draft)
• Authentication
• Taxonomy
• Philips Hub API
• OpenZWave Library
• Registration Server and Tunneling
• TLS

Presentations

The following were presentations made during the 2016/03 workweek.

• Overall Architecture Diagram
• Pilot Scenes
• UI (Theme View v0.75)
• UI (Home View v1.0)
• Web App Implementation
• UPnP and SSDP
• WebPush
• Networking Overview
• Authentication and Tunneling
• Market Research

Repositories

All code was open source and hosted on https://github.com/fxbox. Please file bugs on Github issues for these repositories.

• foxbox: foxbox daemon
• openzwave-adapter: the foxbox adapter for openzwave
• openzwave-rust: Rust wrapper for the open-zwave library
• app for Project Link
• thinkerbell: scripting engine for the Foxbox
• openzwave-stateful-rust
• taxonomy: shared implementation of the taxonomy data structures
• registration-server: to help with foxbox discovery
• users: project Link user management and authentication lib
• multicast dns utils: basic command line utils that demonstate multicast-dns lib capabilities
• multicast dns: experimental mDNS Rust wrapper around Avahi C libraries
• RFC: discussion about design decisions
• dns server: server that helps the Box to announce its local IP address without relying on mDNS, and to register its LetsEncrypt cert for use on its local IP address
• open zwave: a C++ and DotNet library to control Z-Wave Networks via a Z-Wave Controller
• iron cors: helping to add CORS to an Iron server
• [https://github.com/fxbox/adapters adapters: API for defining and registering adapters for the Foxbox
• standalone ipcam: standalone IP camera (uses USB camera or RPi camera) and also IP camera simulator
• libxbee-rust: A wrapper for libxbee

Complex and/or breaking changes are discussed as Requests For Comments.

Participation

The core of Project Link was developed in Rust. The front-end is developed in HTML5/JS using REST/WebSocket.

Help Wanted

We also maintained a full, unclassified, list of ongoing issues, but they may not have been as easy or as detailed:

• Other issues

And all our source code could be found on GitHub repositories.

Getting In Touch

mailing-list.

We established Project Link on Discourse

Otherwise, the best way to get in touch with us was to come and chat through irc. We could be found on channel #foxlink of irc.mozilla.org.

Issues were filed at GitHub repositories.

Discussions about design, improvements or radical new directions could be joined at Requests For Comments.

IRC

You could find us on irc.mozilla.org, channel #foxlink. Team members are still using this channel for Project Cue.

Team Meetings

We used agile practices:

• "Stand-up" meetings were held on on etherpad and on IRC every weekday between 5pm and 5:15pm UTC.
• Weekly meetings were held in Vidyo and on etherpad every monday between 5pm and 6pm UTC.

QA

Project Link Test Plan
Project Link Test Cases
Integration Test Environment Design Document

ARCHIVE

Phase 1

As the first step, we worked toward delivering a prototype that allows a user to -

1. Setup "Link"
2. Have their devices that use Z-wave/WiFi protocols be discovered by Link
3. Interact & control their devices whether they are home or remote via a web-app.
4. Configure rules around how these devices should automatically interact with each other for specific scenarios
5. Receive notifications

Devices Supported in Phase 1

For more details, see Pilot Scenes

Phase 1 Status - Completed