Purpose

This roadmap documents the planned direction of FreeMo while preserving the principles defined in MISSION.md.

FreeMo exists to restore useful local control to legacy Belkin WeMo hardware. Future development should expand what hardware FreeMo can rescue and how that hardware can participate in modern smart-home ecosystems without turning FreeMo itself into a full home-automation platform.

FreeMo should enable automation platforms, not become one.

Core Design Requirements

Future development must preserve the following requirements:

• Direct local control remains the foundation of FreeMo.

• FreeMo must continue to function without Belkin cloud services.

• Native FreeMo controls must remain available through the command-line interface, local web interface, Progressive Web App, and Python API.

• Third-party smart-home integrations must be optional.

• Configuring Google Home, Amazon Alexa, or another external ecosystem must never replace or disable FreeMo's native controls.

• Multiple control methods must be able to coexist. A user may configure Google Home or Alexa and still choose to control the same devices directly through FreeMo.

• FreeMo should expose rescued devices to automation platforms rather than duplicating scheduling, routines, scenes, and other automation features already provided by those platforms.

• Local-first and standards-based integration should be preferred whenever practical.

• New integrations should avoid unnecessary ecosystem lock-in and should not prevent future support for additional platforms.

Current Foundation

FreeMo currently provides the foundation required for future integration work:

• SSDP discovery of compatible WeMo devices

• Dynamic device and UPnP service discovery

• Multi-device support

• Friendly-name based device selection

• Local relay state detection and ON/OFF control

• Device metadata retrieval

• Device-reported signal strength

• Command-line control

• Local HTTPS web interface

• Installable Progressive Web App

• Per-device UPnP event subscriptions

• Independent event-driven state tracking

• Persistent operation through systemd

• Automated testing of discovery, device communication, CLI, events, and web behavior

• Stable device identity independent of IP address

• Persistent user-defined device naming

• Working Matter bridge prototype

• Google Home control of bridged WeMo devices

• Bidirectional state synchronization between FreeMo, physical WeMo controls, and Google Home

This foundation allows FreeMo to communicate directly with legacy WeMo hardware while presenting a modern local interface to the user.

Milestone 1 — Modern Smart-Home Integration

Goal

Allow legacy WeMo devices rescued by FreeMo to participate in modern smart-home ecosystems while preserving FreeMo's independent local controls.

Primary Integration Targets

Initial development will focus on:

• Google Home / Gemini

• Amazon Alexa

Apple Home and other ecosystems are not current development priorities, but the architecture should avoid unnecessarily preventing future support or community contributions.

Matter Bridge Investigation

FreeMo now has a working Matter bridge prototype that exposes legacy non-Matter WeMo devices as modern smart-home devices while preserving FreeMo's independent local controls.

The working prototype has established the basic architecture. Continued development and testing should address:

• Continue validating long-term reliability of the Matter bridge running alongside FreeMo on the existing Linux host

• Generalize Matter endpoint creation so discovered FreeMo devices can be represented dynamically rather than through development-specific mappings

• Continue refining how persistent FreeMo device names and stable device identities are exposed through Matter

• Continue validating synchronization of ON/OFF state across physical WeMo controls, FreeMo, Matter, and external smart-home ecosystems

• Use FreeMo's existing UPnP event subscriptions to provide timely state updates to the Matter integration layer

• Continue testing Google Home behavior, including commissioning, device naming, state synchronization, and recovery

• Investigate and test Amazon Alexa with the working Matter bridge

• Determine whether the same standards-based bridge implementation can reliably serve multiple supported ecosystems

• Investigate commissioning, certification, security, and interoperability requirements for eventual public use

• Evaluate Matter bridge dependencies and deployment requirements while preserving FreeMo's zero-runtime-dependency Python core

Matter has proven viable as FreeMo's primary standards-based smart-home integration path. The current bridge remains a development prototype and should continue to be refined and validated before it is considered ready for general use.

Required Behavior

Smart-home integration must be additive.

After Google Home and/or Alexa integration is configured:

• The FreeMo PWA must continue to work.

• The FreeMo local web interface must continue to work.

• The FreeMo CLI must continue to work.

• Direct Python control must continue to work.

• Users must be free to choose any control method at any time.

• Changes made through one control path should be reflected accurately by the others.

• Failure or unavailability of an external ecosystem must not prevent direct FreeMo control of the WeMo devices.

Automation Responsibility

FreeMo will not attempt to become a general-purpose home-automation platform.

Schedules, routines, scenes, voice commands, sunrise/sunset rules, grouped actions, and similar automation should be handled by platforms such as Google Home or Amazon Alexa.

FreeMo's responsibility is to discover, control, monitor, and expose the legacy hardware reliably.

Milestone 2 — Broader WeMo Hardware Compatibility

Goal

Expand the range of legacy Belkin WeMo hardware that FreeMo can discover, understand, control, and monitor locally.

FreeMo should prefer capability-based support over assumptions tied to one specific model or firmware generation.

Current Hardware Baseline

FreeMo has been successfully tested with:

• Christmas Tree — Belkin WeMo LNKF7C063

• Closet — Belkin WeMo F7C027fc

These devices represent different hardware and firmware generations and currently operate simultaneously through FreeMo.

Future Compatibility Work

As additional legacy WeMo hardware becomes available for testing:

• Verify SSDP discovery

• Verify device-description parsing

• Identify advertised UPnP services and control endpoints

• Verify friendly-name retrieval

• Verify relay or device state reporting

• Verify supported control actions

• Verify metadata retrieval

• Record device-reported signal-strength behavior where supported

• Verify UPnP event subscription behavior

• Test simultaneous operation with other supported devices

• Add automated regression tests for newly discovered protocol differences

• Document confirmed models and known limitations

Compatibility Principles

FreeMo should dynamically use the capabilities and service endpoints advertised by each device whenever practical.

Model-specific exceptions should be introduced only when actual hardware behavior demonstrates that they are necessary.

Support for additional device types should not compromise reliable operation of already-supported hardware.

Milestone 3 — Public Release Readiness

Goal

Prepare FreeMo for public release so other owners of legacy WeMo hardware can install, understand, test, and use the project safely and reliably.

FreeMo should not be considered ready for public release solely because it works on the original development network.

Remove Development-Specific Assumptions

Before public release:

• Remove hard-coded development-network addresses

• Make the UPnP event callback address configurable or determine it dynamically

• Review port assumptions for the HTTPS web interface and event listener

• Ensure filesystem paths are portable

• Ensure TLS certificate configuration is documented and portable

• Ensure systemd deployment examples do not depend on a specific username or home directory

• Verify operation after a clean installation on a second system

Installation and Configuration

Provide clear documentation for:

• Supported Python versions

• Creating and using a virtual environment

• Installing FreeMo

• Discovering devices

• Using the CLI

• Starting the local web interface

• Configuring HTTPS

• Installing the Progressive Web App

• Running FreeMo persistently as a service

• Network requirements for SSDP, SOAP, and UPnP event notifications

• Troubleshooting common discovery and connectivity problems

Reliability and Testing

Before public release:

• Maintain automated regression tests for all major modules

• Test multiple devices simultaneously

• Test devices from different hardware and firmware generations

• Verify clean startup and shutdown

• Verify recovery after network or device interruptions

• Verify event-subscription renewal and cleanup

• Verify behavior when devices disappear or become unreachable

• Verify malformed or unrelated UPnP event notifications do not disrupt the server

• Run tests and static analysis before release commits

Documentation

Maintain:

• README.md as the current description and usage guide

• MISSION.md as the project's philosophy and design principles

• ROADMAP.md as the development direction and milestone plan

• LICENSE as the project's licensing terms

Document supported hardware and known limitations clearly so users can distinguish confirmed compatibility from untested hardware.

Public Repository

When FreeMo is ready for public release:

• Create the public Git repository

• Review repository contents for development-only files or private information

• Add an appropriate .gitignore

• Establish an initial public version

• Publish installation and usage instructions

• Provide a clear method for users to report bugs and hardware compatibility results

• Encourage contributions that preserve FreeMo's local-first mission and design principles

Longer-Term Direction

FreeMo's longer-term development should be guided by real hardware, real user needs, and the project's mission rather than by adding features simply because they are possible.

Potential future work may include:

• Support for additional legacy WeMo device types

• Improvements discovered through testing on additional hardware and firmware versions

• Additional standards-based smart-home integrations where they can coexist with FreeMo's local controls

• Contributions from users who own WeMo hardware not available to the original development environment

• Improvements to installation, configuration, diagnostics, and portability

• Better documentation of the native protocols used by legacy WeMo hardware

Future priorities may change as FreeMo is tested outside its original development environment.

What FreeMo Is Not

FreeMo is not intended to become a replacement for full home-automation platforms.

FreeMo does not need to duplicate features such as:

• Complex automation engines

• Routine and scene management

• Sunrise and sunset scheduling

• General-purpose home-automation dashboards

• Cloud account management

• Vendor-specific cloud services

Those capabilities are better handled by dedicated automation ecosystems.

FreeMo's role is narrower and deliberate:

Discover the hardware. Understand it. Control it locally. Keep it useful. Expose it to modern systems without surrendering local ownership.

Roadmap Philosophy

This roadmap is a direction, not a promise that every possible feature must be implemented.

Priorities should be adjusted when testing, newly acquired hardware, protocol discoveries, security requirements, or user experience reveal a better path.

Any future feature should be evaluated against three questions:

1. Does it help preserve or restore the usefulness of legacy WeMo hardware?

2. Can it coexist with FreeMo's independent local-control model?

3. Does it respect the owner's control of hardware they already purchased?

If the answer to those questions is yes, the feature belongs in the FreeMo conversation.

Ownership is ours. . . Take it back!