Input Module — API
Overview
The Input Module (MS-I012) has no relay or dimmer output — it exposes 12 digital inputs and 4 analog inputs (each independently set to 0‑10V or 4‑20mA) for reading sensors and dry contacts. It runs the same core firmware platform as the Relay Board family, so its Integrations/Ports page offers the same transports: TCP, UDP, HTTP and MQTT.
The vendor API document available for this reference ('Relay board API v1.9.8') covers the shared digital‑input TCP/HTTP surface in detail (it is the same document used for the Relay Boards page) but was written from the relay board's point of view — it does not include a dedicated section for this module's 4 analog channels. Endpoints below that come directly from that shared document are marked accordingly; the analog‑input gap is called out in §4.4.
Status String
Open a plain TCP connection (default port 502) and send the query command 00 as raw text, same as the Relay Board family:
[relay1]...[relayN] : [input1]...[input12] : channel_count : … : [relay1]...[relayN] : [input1]...[input12]
On a module with zero relay outputs, the shared string protocol's leading '[relay1]…[relayN]' block behaviour (omitted vs. reported as all zeros) is not spelled out for the Input Module specifically in the source document — it was only worked through with relay‑bearing boards. The [input1]…[input12] segment is expected to report the 12 digital inputs the same way it does on Relay Boards.
This shared TCP status string reports the 12 digital inputs only. It does not carry the 4 analog channel readings — see §4.4.
Load Digital Input Status
Same endpoint and response shape as the Relay Board family's input‑status CGI (see the Relay Boards API for the full field table):
/input.cgihttp://192.168.1.100/input.cgi
&0&0&12&1&0&1&0&1&0&1&0&1&0&1&0&
The worked request/response pair above for a 12‑input module is illustrative, built from the documented field layout (§ Relay Boards — Load Input Status) rather than captured from a live MS‑I012. Confirm the exact byte‑for‑byte response on a real unit before relying on it.
Analog Input Readings (open item)
No endpoint for reading the 4 analog channels' raw V/mA values is documented in the vendor material reviewed for this reference. The module's web interface has a dedicated AI page (Index / Type / Raw Value per channel — see this product's User Manual) confirming the data exists and is readable locally, but no HTTP CGI, TCP string field or MQTT topic for it was included in the source documents used here. Likely candidates worth testing against a live unit: an analog‑specific CGI (e.g. ai.cgi, unconfirmed name) or an extra field appended to the shared status string beyond the digital‑input block.
Topics & Payloads (open item)
No topic list specific to the Input Module was included in the source material. The Integrations/Ports page exposes the standard MQTT block (broker, QoS, Retain, HA Discover) plus a Keep Alive Second heartbeat that pushes the full input status (digital + analog, per the product's User Manual) at a configurable interval — but the topic names and payload shape of that heartbeat were not documented in the API material reviewed. By analogy with the Dimmer family's /molsmart/<device><serial>/in/… pattern, something similar is plausible but unconfirmed.
Notes & Open Items
| Open item | Detail |
|---|---|
| Analog channel API (4× 0-10V/4-20mA) | Not documented in the source reviewed — see §4.4. |
| MQTT topics | Not documented for this module specifically — see §4.5. |
| UDP1/UDP2 frame format | Same open item as the Relay Board family — binary protocol, byte layout not covered by the source document. |
| Relay-block behaviour on a 0-relay module | Not spelled out for this module — see §4.2. |
For the full field reference of this module's web interface (Integrations/Ports, AI, Test Input, Input Link URL, etc.), see this product's User Manual.