Modbus Mobile Control Works Best as a Lightweight HMI

The working pattern is a lightweight phone HMI that reads status and sends bounded Modbus commands over Ethernet to the controller, rather than mirroring the controller screen over VNC. Trace the request from phone to controller before selecting features: physical link, network route, Modbus service, then project variables. A reachable controller does not by itself prove that a command is mapped safely or that the app detects a lost controller promptly.

Which hops carry a phone command to the controller?

In the local case, the command travels from the phone over Wi-Fi to an access point or router, across the site LAN, through the controller’s Ethernet interface or Ethernet converter, and into the controller application. The reply follows the reverse path. In the remote case, the phone adds a mobile-data or external Wi-Fi path to the site router; routing, firewall policy, and any address translation then determine whether the request can reach the controller.

Hop	Reading to take	What the result means
Phone to access point	Confirm Wi-Fi association or mobile-data connectivity.	No link means troubleshoot the phone’s network path before checking Modbus.
Access point/router to controller	Check Ethernet link at the controller or converter and confirm the configured controller address.	No link points to cabling, power, interface, or converter setup. A link light proves only the physical link, not IP reachability.
Phone to controller network	From the same LAN, test reachability to the configured address and verify subnet and route settings.	If the address is unreachable, fix the network path before interpreting application errors.
App to Modbus service	Compare the app endpoint and service settings with the controller project and network configuration.	Reachability with no valid response directs the next check to the service, configured port, and register mapping. Read those values from the actual configuration; do not guess them.

A controller referred to as 2010 was described as usable when its Ethernet interface is exposed through a converter. Treat that as a path requirement, not a guarantee that every converter or project exposes the same Modbus data. If the physical path fails, resolve it first. If the path works but reads fail, inspect the protocol endpoint and project mapping next.

Which project variables should the phone be allowed to change?

Keep the phone interface at the operator layer: Start, Stop, operating setpoints, schedule controls, current measurements, and normal/alarm indication. Those functions match the requested lightweight-panel use case for heating, ventilation, and similar installations. Do not turn an operator screen into an unrestricted project-variable editor by default.

Before binding a screen, make a point list from the controller project. For every displayed value, record its meaning, engineering units, valid range, and what state should appear when the point is unavailable. For every writable value, record the permitted range, command behavior, and the controller state that confirms acceptance. Read-only status and measurements should remain distinct from write controls. Use controller-side limits and interlocks for machine protection; a phone command is an operator request, not a replacement for control logic.

The project is the authority for register addresses and variable types. Confirm whether each value is readable, writable, or derived, and test the displayed value against the controller’s own view. A button that sends a write is not proof that the machine accepted it; confirm the resulting controller state or feedback point. If the value or address is undocumented in the project, resolve that mapping before building the screen rather than entering a guessed address.

Choose the next check based on the point test: correct value and response allow interface testing to proceed; an incorrect value sends you back to the project mapping; a command that writes but does not produce the intended machine state requires a controller-logic and interlock check.

Does a lightweight Modbus HMI fit better than VNC?

Use the smallest data path that meets the operator’s task. A Modbus panel transfers values and commands; VNC transfers a remote screen and its visual updates. The latter can require more bandwidth and controller resources, and its compatibility is narrower in the described setup.

Approach	Data path and fit	Constraint to check
Lightweight Modbus phone panel	Reads selected values and writes selected operating commands; suited to Start/Stop, setpoints, measurements, and alarms.	Requires a valid Ethernet route and project-specific variable mapping.
VNC screen mirroring	Transmits a remote display; useful when the requirement is to view an existing configured screen.	The described VNC approach was limited to SMH4 and Trim5 and was not suitable for non-Linux controllers. It was also described as a poor fit for weak or expensive mobile connections.
Full SCADA or configurable client	Provides richer screens, multiple installation views, logs, and user-configured displays.	Requires engineering and maintenance of the visualization and its mappings; it is not just a simple phone remote.
Browser-based HMI	HTML/SVG with HTTP requests or sockets was proposed as a client option.	Use it only if the controller-side runtime and network path actually provide the required web interface; the proposal does not establish that every controller does.

The reported mobile-panel traffic figure was about 120 bytes per minute, while VNC was described as around a megabyte. The interval and measurement conditions for the VNC figure were not specified, so do not calculate a ratio from these two numbers. Measure traffic on the intended phone, network, and screen workload before setting a data budget. The figures still identify the design distinction: exchanging a few process values is not the same workload as moving a remote desktop.

If the requirement is only a few operator actions and essential status, select the data-oriented panel. If an operator must see a complete existing display, evaluate screen mirroring only against the exact controller family and link. If users need multi-unit overview, history, or freely configured displays, define that as a SCADA/configurable-client project rather than expanding a single-panel app until its scope is unclear.

How many installations must remain connected at once?

Separate the number of saved endpoints from the number of simultaneous connections. A proposed Lite design held up to five named installations but connected to only one installation at a time. A proposed Base design called for up to 20 simultaneous installations, an overview of Stop/Run/Alarm, detailed state, a log, background notifications, and configurable user screens. A Pro tier was described as SCADA-like. These are feature-tier proposals, not confirmed capacity guarantees for a deployed app.

Tier proposal	Scope	Decision to make
Lite	One active installation; up to five saved installations; Start/Stop, normal/alarm, setpoint, current readings, and schedule on one primary screen.	Use when one operator selects one unit at a time. Verify that saved connection switching is clear and does not leave an unintended active session.
Base	Proposed simultaneous monitoring of up to 20 installations, background status notifications, overview and detail screens, log, and configurable screens with buttons, icons, text, and variable values.	Use only after defining polling load, stale-data indication, user roles, and screen ownership for the full installation count.
Pro	Full SCADA-like scope.	Specify as a separate visualization system with its own design, testing, and maintenance plan.

For a site with several air-handling units, a one-unit-at-a-time panel may be operationally inconvenient even if it stores multiple addresses. Decide using the operator task: one household unit favors a single connection; several plant assets that must be supervised together need an overview and explicit concurrent-session behavior. Do not infer that a selector or list means the phone polls every listed controller. Verify connection count by observing requests at the controller or network during a test.

Editable custom screens introduce a second role beyond operation: someone can alter the control layout and point assignments. The proposed design included a password lock on changes to those screens. Apply that restriction to configuration changes, then separately define which users can issue operating commands. If there is no clear owner for point mapping and screen changes, use fixed screens instead of user-built layouts.

Can an external phone reach the controller securely?

First prove local-LAN operation. Only then add remote access. Dynamic DNS solves changing-address discovery: a client or router reports the current public address to a DNS service, which associates that address with a name. It does not create a route through the site router, configure a firewall, or authorize a controller command. The actual remote path still depends on site network rules and an approved secure access method.

A DDNS request in the described discussion depended on a specific provider and its request format. One cited provider policy required checks to be at least 10 minutes apart. That interval belongs to that policy, not to DDNS generally; read the selected provider’s current update rules and configure the updater accordingly. Do not build a provider-specific web request into an app until the provider, credentials, update mechanism, and service terms are known.

For remote operation, use a VPN or another approved secure gateway rather than exposing the controller’s control interface directly to the public network. Confirm that the phone can reach only the intended site and endpoint, that credentials are protected, and that the router path is restricted to the users and traffic required. A domain name resolving correctly is only a DNS check. If the name resolves but the app cannot connect, test the secured route and firewall path; if the route works on the LAN but not remotely, troubleshoot the gateway configuration rather than changing the Modbus point map.

For background monitoring, distinguish an app sent to the background from an app closed or force-stopped. A reported implementation continued polling in the background at one-tenth the foreground frequency. That can preserve status notifications but also keeps a connection active and consumes network and battery resources. Measure its actual poll rate and stale-data behavior. If the schedule must run without the phone, execute it in the controller; do not depend on a mobile process or a live network session.

What should the app show when controller power disappears?

A phone can retain a Connected label after the controller stops responding because connection state is not the same as fresh process data. The client may still hold a socket while waiting for a response, retrying, or waiting for its timeout. The screen must distinguish connected transport from current, successfully refreshed values; otherwise stale status can look valid.

In a reported test, after controller power was removed, the app stayed Connected for roughly a couple of minutes. It then showed Modbus-related errors or an Android “Program is not responding” message, and in some attempts exited after another roughly half-minute to a minute. The timing was not measured precisely. The behavior was seen during Android testing including versions 6.0.1 and 7.0, with CAT S60 and NOMU T18 handsets named in the reports. No app version or confirmed root cause was given, so treat this as a client disconnect and responsiveness issue to reproduce, not as proof of a controller fault.

Reproduce it with a controlled controller-power or network interruption while recording request and response timestamps, last-good-value time, socket or transport state, displayed connection status, and the Android crash/ANR log. If the screen remains Connected while no new responses arrive, correct the stale-state logic and timeout handling. If the interface freezes before a timeout appears, inspect whether network waits or retries block the UI thread. If the error appears promptly but the app still exits, investigate the client crash separately. Restore power and confirm that the app reconnects and refreshes values without requiring the operator to trust old data.

Does the project expose the sensors the screen expects?

Sensor availability depends on the controller project. A field installation may have a duct-temperature sensor but no room-temperature or humidity sensor; a fixed screen that assumes all three can display the wrong measurement or an empty field. In the described app testing, the screen showed room temperature, while the installation’s duct sensor was more consistently present. Automatic adaptation was described, but repeated sessions did not demonstrate it; the suggested test was to load a controller project containing only the duct sensor.

Test each supported project configuration explicitly: only duct temperature, room temperature present, humidity absent, and any combination the application claims to support. For each case, compare the displayed label and value with the actual project point. Confirm that a missing measurement is omitted or clearly marked unavailable rather than relabeled as another sensor. If the project uses a different set of points, update the mapping or provide a deliberate selection; do not rely on long sessions or repeated app launches to discover whether the interface adapts.

The diagnostic branch is simple: if the project point exists and the value is wrong, inspect its mapping and units; if the project point does not exist, change the screen behavior or project design; if a value appears under the wrong sensor label, stop using that display for operator decisions until the label-to-point mapping is corrected.

Will the screen fit Android display and font settings?

Test layout at the phone’s actual display size and system font setting, not only on the developer’s default device. Reported Android 7.0 testing on a 4.7-inch, 1280 × 720 display showed labels extending beyond their intended area when the system font was set large. An app update stopped some of the overlap, but the largest font setting still left a problem. A 4-inch, 480 × 854 Android 4.2.2 display also showed shifted content, and larger fonts wrapped “room temperature” onto two lines. These are observed compatibility conditions, not a general guarantee for every device on those operating systems.

Use a layout that tolerates font scaling and narrow screens: allow labels to wrap or grow, keep controls from overlapping status fields, and test portrait/landscape behavior if the app permits both. Check the smallest supported display and the largest supported system font setting. The app should preserve the distinction between label and value when text wraps; clipping a label can make a correct sensor reading operationally ambiguous.

Repeat this matrix for iOS as a separate target if iOS support is required. The described test cases are Android-specific and do not establish iOS layout, background, or connectivity behavior. If the screen fails at one combination, record OS version, resolution, font setting, and the exact control or label that overlaps before changing the layout.

How do you commission the phone path and verify the fix?

Commission the app from the controller outward. Keep the first test local, use a controlled project, and introduce remote access only after the local data path and command behavior pass.

1. Record the project and network endpoint. Write down the controller address, Ethernet/converter path, configured Modbus service settings, and the project points used for status, measurements, setpoints, and commands. Read addresses and service values from the live configuration.
2. Prove the physical and IP path. Check link at the controller or converter, connect the phone to the site LAN, and test network reachability to the configured endpoint. Resolve link, subnet, or route failures before interpreting application errors.
3. Prove read mapping first. Compare app values and sensor labels with the controller project. Test projects with optional sensors absent, especially duct-only temperature and absent humidity where those configurations apply.
4. Test one write at a time. Exercise Stop/Start and each allowed setpoint within the project’s defined range. Confirm both the app’s command result and the controller’s resulting state; confirm local interlocks still control machine behavior.
5. Test schedule ownership and background behavior. Send the app to the background and observe the actual polling and notification behavior. Disconnect the phone and confirm the controller’s schedule continues if the schedule is required to be autonomous.
6. Test loss and recovery. Interrupt controller power or the network in a controlled test. Verify that fresh data becomes stale or unavailable promptly, that the app remains responsive, and that it reconnects and refreshes after the path returns.
7. Add remote access only after local acceptance. Enable the approved secure route, verify the intended endpoint from the external phone network, and confirm that the same read/write and loss tests still behave correctly.

The resolving branch passes only when the operator sees current values, the intended sensor labels, bounded command behavior, a clear stale/disconnected indication, and successful recovery. Finish by disconnecting and reconnecting the phone once more, then verify the displayed values against the controller’s live project.

Frequently Asked Questions