Observed Failure Pattern
A Do-more controller programmed with Do-more Designer 1.4 had sent rare shutdown and catastrophic-failure emails for years. It also performed periodic DNS lookups for a time server. After the site changed its firewall, switches, default gateway, and ISP email service during the same week, the controller reported SMTP Timed Out Error and the time-server DNS lookup failed.
Correcting the controller's default gateway restored the time-server DNS lookup, but email remained unavailable. This separates the incident into two faults: incorrect network routing affected DNS, while a distinct SMTP connection or compatibility problem remained.
Separate DNS, Routing, and SMTP Results
| Test or observation | Result | Engineering conclusion |
|---|---|---|
| Time-server DNS lookup before gateway correction | Failed every attempt | Investigate controller gateway and network routing. |
| Time-server DNS lookup after gateway correction | Worked | The corrected gateway restored this DNS path. |
| Email server name lookup | Returned an IP address | Name resolution alone did not prove that SMTP was reachable. |
| SMTP connection using the resolved IP | Failed | The remaining fault was beyond basic name resolution. |
| SMTP connection using an ISP-provided IP | Failed | Entering an address manually did not bypass the problem. |
| Do-more Designer 2.6 simulator using the same settings and server URL | Worked immediately | The later simulated email client handled the configuration differently or more successfully; hardware operation was not proven. |
Troubleshooting Procedure
- Record the controller's current IP configuration and the exact SMTP Timed Out Error before changing settings.
- Compare the configured default gateway with the gateway supplied for the revised network. Correct the gateway when it does not match the routed network.
- Repeat the time-server DNS lookup. If it succeeds after the gateway correction, treat routing and DNS as functional for that test rather than assuming SMTP is also functional.
- Run the email-server lookup and record the returned IP address. Test the email device with the server URL and with the explicitly supplied IP address when one is available.
- If both SMTP tests time out while other DNS lookups work, have the network and email-service administrators verify the SMTP path and current account requirements. The evidence does not identify whether the remaining rejection occurred at the firewall, email service, or client-protocol layer.
- Recreate the same email-device configuration in Do-more Designer 2.6 simulation and compare the result with the 1.4 project. Use this as a version-sensitive diagnostic, not as proof that the physical controller will send successfully.
- If the original email service remains incompatible, configure an alternate working mail service and perform a controlled delivery test before restoring alarm reliance.
Interpreting the Version Comparison
The same server URL and settings failed in the installation associated with Do-more Designer 1.4 but worked in the Do-more Designer 2.6 simulator. This is evidence of a version- or execution-environment-dependent difference, but it does not identify a specific defect, affected firmware, protocol change, or corrected component.
Do not conclude that a controller upgrade alone resolves the fault. The successful result occurred in simulation, while the failed result involved a physical controller on a changed production network. Confirm the intended controller model, supported software or firmware path, and email behavior on hardware before adopting an upgrade as the corrective action.
Verification and Operational Acceptance
Verify email independently of the real shutdown event. Trigger a controlled test message, confirm that the recipient receives it, and confirm that the controller no longer reports the SMTP timeout. Then repeat the test through the same logic path used by the shutdown or catastrophic-failure notification.
Verify the time-server lookup separately and confirm the clock update path still operates after the gateway correction. Acceptance requires both functions to pass because successful DNS resolution does not establish successful SMTP delivery. Preserve an independent alarm path until controlled email tests pass on the production controller and network.
FAQ
Why did correcting the Do-more default gateway fix DNS but not email?
The corrected gateway restored the time-server DNS lookup, proving that test could route successfully. SMTP still timed out, so email required separate investigation beyond the gateway correction.
Why does the Do-more email server URL resolve but SMTP still time out?
DNS resolution only returns an IP address; it does not confirm that an SMTP session can be established. In this case, both the resolved address and an ISP-provided address failed.
Does a successful Do-more Designer 2.6 simulator email test prove the controller will work?
No. The same settings and server URL worked in the 2.6 simulator, but the evidence contains no successful hardware test for that configuration. Validate delivery on the production controller before relying on it for shutdown notification.