Differences

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

--- mosh:protocol_overview [2025/06/27 15:26] – 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 16: / Line 16: @@
 The Element Manager also maintains a list of element properties to be the used by the Virtual Wire Manager.
-===== Message Framer =====
+The Element Manager ensures that elements:
+  * Are initialized and updated in the main loop
+  * Can emit and receive messages via virtual wires or direct commands
+  * Report state changes through a unified property interface
+The Element Manager enables modular, plug-and-play integration of inputs, outputs, and logic into the MOSH runtime.
+=====🔌 Virtual Wire Manager=====
+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.
+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.
+Virtual wires form the backbone of decentralized automation in MOSH.
+=====📡 Transport Manager=====
+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.
+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.
-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.