Differences

This shows you the differences between two versions of the page.

--- mosh:protocol_overview [2025/06/27 15:19] – [Concept] mosh
+++ mosh:protocol_overview [2026/06/10 13:54] (current) – mosh
@@ Line 1: / Line 1: @@
+<WRAP important>
+This page is retained for historical reference and may not reflect the current MOSH/IMC/MTRP architecture.
+See [[guide:architecture_map]] for the current model.
+</WRAP>
 ====== Architectural Overview ======
-The following diagram illustrates the overall architecture of the MOSH library.
+===== 🧩 Element Manager =====
-{{:mosh:mosh_architecture.png?1024|}}
+The Element Manager is the hardware-to-MOSH interface, and is the subsystem responsible for managing all active elements on a MOSH node. It reads raw hardware data, and separates it into properties used by other MOSH elements. This separation allows an elements properties to reflect their intended use more clearly, and enables different properties from the same device to be routed independently.
-===== Element Manager =====
-The Element Manager is the hardware-to-MOSH interface. It reads raw hardware data, and separates it into properties used by other MOSH elements. This separation allows an elements properties to reflect their intended use more clearly, and enables different properties from the same device to be routed independently.
 For example:
@@ Line 15: / Line 15: @@
 The Element Manager also maintains a list of element properties to be the used by the Virtual Wire Manager.
-===== Virtual Wire Manager =====
-Before an element can communicate with other elements, it must be placed on a Virtual Wire. A **Virtual Wire** in MOSH is a logical connection between two or more elements—similar to a physical wire that connects a switch to a light, but defined entirely in software. Virtual wires allow input elements (like buttons or sensors) to send signals to output elements (like LEDs or relays), regardless of where those elements reside on the network.
-Virtual wires are transport-agnostic, meaning they can connect elements across different nodes, transports (e.g., ESP-NOW, Serial), or even across bridges.
+The Element Manager ensures that elements:
-==== Concept ====
+  * Are initialized and updated in the main loop
-Virtual wires are declared in element configuration using the `virtual_wire` parameter. When an input element triggers a status message (e.g., `PRESS`, `STATE_ON`), the virtual wire automatically forwards that message to all connected outputs.
+  * Can emit and receive messages via virtual wires or direct commands
+  * Report state changes through a unified property interface
-This allows you to create automation logic without hard-coding behavior into individual element classes.
+The Element Manager enables modular, plug-and-play integration of inputs, outputs, and logic into the MOSH runtime.
+=====🔌 Virtual Wire Manager=====
-==== Runtime Behavior ====
+The [[mosh:virtual_wire_manager|Virtual Wire Manager]] is responsible for routing messages between elements based on their assigned virtual wire IDs. It acts as a logical patch panel, allowing input elements (like buttons, sensors, or timers) to trigger actions on output elements (like LEDs, relays, or motors) without direct coupling.
-Virtual wires transmit:
+By abstracting the connection layer, the Virtual Wire Manager enables modular, transport-agnostic automation across distributed nodes. It ensures that status or property change messages are delivered in real time to all elements subscribed to a given wire, regardless of their physical location or transport layer.
-    Property change messages (e.g., state, event)
+Virtual wires form the backbone of decentralized automation in MOSH.
-    Status messages (e.g., PRESS, LONG_PRESS)
+=====📡 Transport Manager=====
-    User-defined messages (e.g., USER_DEF1, etc.)
+The Transport Manager oversees all communication interfaces used by a MOSH node. It handles registration, configuration, and routing for multiple simultaneous transports—including ESP-NOW, Serial, Wi-Fi, and others.
-The Element Manager handles virtual wire delivery internally, ensuring messages are routed to all subscribed elements—locally or remotely.
+Each transport is wrapped in a standardized MOSH class, allowing MOSH Core to send and receive messages without needing to know the specifics of the underlying radio or link.
-===== Message Framer =====
-The Message Framer is responsible for a variety of MOSH functions. Some of these functions include:
+The Transport Manager:
-  * The final construction of MOSH Messages
+  * Maintains active transport instances
-  * Accepting message requests from the Virtual-Wire Manager
+  * Assigns network and node IDs per transport
-  * Accepting/Sending messages to/from the Transport Manager
+  * Manages message framing, delivery constraints, and acknowledgments
+  * Supports both point-to-point and broadcast-capable transports
-===== Transport Manager =====
+The Transport Manager makes MOSH hardware-agnostic, enabling seamless communication across diverse networks and physical layers.