PLC 100 Smart Home: Control Is Local, Video Is Not

A PLC 100 can coordinate home sensors, counters, actuators, and tablet commands, but it should not transport camera streams or replace the servers built into multimedia devices. Use the controller for deterministic control, then let the tablet open each camera, multiroom, or appliance interface directly.

Architecture options

Before anything else, confirm which subsystem owns each function. The deciding factor is whether the data represents a control signal, a meter value, a user interface, or a high-bandwidth media stream.

Recommended control boundary

1. Assign smoke, temperature, leak, door-contact, motion, illuminance, and pushbutton signals to the PLC only after matching each sensor output to an available input type. Confirm every point changes state correctly in the PLC watch view before adding automatic logic.
2. Assign valves, lighting contactors, alarm outputs, and appliance-enable circuits to PLC outputs through switching hardware rated for the actual load. Confirm the output drives the interface device, not an appliance load beyond the PLC output rating.
3. Keep camera encoding, recording, authentication, and streaming inside the camera or video system. Place a camera icon on the tablet dashboard and configure it to open the camera's own web interface.
4. Keep multiroom playback and media browsing in the multiroom system. Send only supported commands or status values through its documented interface.
5. Treat the coffee maker as an external appliance. Confirm that it exposes a controllable interface or that an approved external circuit can initiate operation safely. A PLC output alone cannot make an appliance remotely operable when its internal controls require manual interaction.

Do not move on until every subsystem has a named owner and a defined interface. This separation prevents a camera or visualization failure from blocking leak detection, temperature control, or other local automation.

PLC I/O and expansion plan

The PLC 100 configuration described has a limited number of discrete sensor connections and no onboard analog inputs. Therefore, a mixed sensor installation requires I/O expansion whenever the point count exceeds the built-in channels or a sensor produces an analog signal.

Expansion modules also improve serviceability: field wiring can remain organized by function, and a failed channel group can be replaced without redesigning the whole controller panel. Build an I/O list before buying modules. Record signal type, normal state, required fail state, electrical load, cable destination, and the PLC variable used by the application.

Meter acquisition paths

Water and electricity readings can enter the PLC by pulse counting or by a device protocol. Choose one path per meter according to its physical interface and the values the application needs.

1. For a pulse output, read the pulses with a fast input when the expected pulse frequency can exceed the capability of an ordinary scanned input. Configure a retained totalizer if the reading must survive a restart. Confirm the meter's pulse weight from its documentation, then calculate engineering units as total pulses × units per pulse.
2. For a protocol connection, match the electrical interface and message format before writing application logic. A library is available for Mercury meters. A can also be read when its protocol is implemented or adapted in the PLC application.
3. Validate the result at two levels: first confirm that raw messages or pulses arrive without communication errors; then compare the converted total with the physical meter. Do not compensate for missing pulses by changing the scale factor.

Protocol polling can expose more than a pulse counter, but it adds framing, addressing, timeout, and data-conversion work. Pulse acquisition is simpler when only accumulated consumption is needed. If current, power, tariff, or diagnostic registers are required, read their definitions from the meter protocol documentation rather than inferring them from the display.

Tablet and web interface

A compact dynamic web server can be implemented with page scripts and PLC sockets, but connection capacity and application complexity set the practical boundary. One socket represents one connection; concurrent browsers, polling clients, and media sessions consume separate resources. Camera streaming must bypass this path.

1. Connect the PLC, tablet, cameras, and subsystem gateways on the selected network. The documented installation used Ethernet with telnet or IrDA interfaces, while the tablet visualization used iRidium.
2. Create the PLC-to-tablet tag list: commands, feedback states, alarms, measured values, communication health, and access permissions. Confirm read-only values before enabling write commands.
3. Build controls so every command has visible feedback from the controlled state. A button animation alone is not proof that a valve, light, or appliance changed state.
4. Add camera icons as direct links to the camera web interfaces. Do not proxy image or video data through the PLC.
5. Add multiroom and coffee-maker controls only after verifying their supported command interface. If no interface exists, present status or a navigation link instead of implying control.

Commissioning and recurring pitfalls

1. Test local PLC control with the tablet disconnected. Leak response, temperature regulation, alarms, and interlocks must continue without the visualization layer.
2. Force or operate each input individually and confirm its PLC state, alarm meaning, and normal-state convention. Correct inverted contacts before testing sequences.
3. Command each output under controlled conditions and verify physical feedback. Check the selected interface hardware against the load data rather than treating every output as interchangeable.
4. Generate meter pulses or observe a known consumption interval. Confirm raw counts, scaling, retained totals, and restart behavior.
5. Open several tablet views and device pages. Confirm that PLC status remains responsive while cameras stream directly from their own servers.
6. Interrupt communication to each external device. Confirm that the dashboard identifies stale data and that the PLC moves affected functions to their designed fallback state.

Common failures come from counting fast pulses in ordinary cyclic logic, connecting analog devices to discrete-only hardware, confusing a sent command with field confirmation, and routing media through a control processor. Another recurring error is making essential automation depend on the tablet session; the tablet should supervise and command, while the PLC retains local operating logic.

Frequently asked questions