After the fix, the OV20i continues running its camera workload while its built-in Node-RED environment exchanges data with a separate Ignition instance. The recommended path uses the preinstalled Ignition palettes; it does not add Ignition Edge to the camera.
What is the OV20i-to-Ignition data path?
Follow the packet. A Node-RED flow on the OV20i generates or receives a value, an Ignition palette node sends the transaction, the camera network interface carries it through the intervening network, and the Ignition instance accepts it. A return acknowledgement, response, or error follows the reverse path according to the palette node's protocol.
| Path element | Address or setting | Diagnostic question |
|---|---|---|
| Engineering workstation | Address valid for the camera network | Can it reach the OV20i and open its device-management environment? |
| OV20i | Camera address from the deployment configuration | Does the interface show link and pass traffic beyond its local subnet? |
| Node-RED Ignition node | Ignition destination configured in the node | Does its status change when the flow sends a known value? |
| Network hops | Switching, routing, and filtering rules | Does the required path permit traffic in both directions? |
| Ignition instance | Host name or address, port, and security settings used by the selected palette node | Is the matching service listening and accepting the camera connection? |
The exact transport, port, authentication fields, and connection timing depend on the preinstalled palette node. Read those values from the node configuration and its embedded help rather than substituting settings from an unrelated Ignition integration method.
Which integration approach fits the camera?
| Criterion | Built-in Node-RED path | Local Ignition Edge installation |
|---|---|---|
| Software already present | Node-RED and Ignition palettes are preinstalled | Requires another runtime and application installation |
| Camera workload impact | Adds only the configured flow workload | Adds gateway memory, storage, processor, and service-management demand |
| Compatibility work | Uses the supplied integration components | Depends on processor architecture, Java compatibility, packaged runtime support, and available resources |
| Operating-system constraint | Works inside the existing camera software environment | Must fit Ubuntu 18.04 and the camera's system architecture |
| Maintenance boundary | Camera runs the flow; Ignition remains on its existing host | Camera also becomes an Ignition host that must be patched, backed up, and monitored |
Use the built-in Node-RED route. The OV20i already contains the components needed to connect to an Ignition instance, while a local Edge installation introduces compatibility and capacity questions without removing the network dependency.
Ubuntu 18.04 LTS reached the end of its standard five-year support in May 2023. That fact matters if custom packages are added to the camera: package availability, runtime compatibility, vulnerability handling, and long-term maintenance become part of the machine design. It does not prevent the supplied Node-RED integration from being configured.
Where does a failed connection stop?
Layer one first. Confirm camera power, link indication, cable condition, switch-port state, and the expected network connection before changing Node-RED or Ignition. A disconnected interface and a rejected application session can produce similar user-facing symptoms, but they require different fixes.
| Observed condition | Likely boundary | Next check |
|---|---|---|
| No camera management access | Physical link, address assignment, switching, or routing | Verify link, camera address, workstation subnet, gateway, and route |
| Camera accessible but destination unreachable | Route, name resolution, or firewall | Test the destination by its configured address and trace each network hop |
| Destination reachable but node remains disconnected | Port, listener, security, or protocol settings | Compare the node fields with the active Ignition-side service |
| Node connects but values do not change | Flow wiring, item mapping, permissions, or payload type | Inject a known value and inspect status at every flow boundary |
| Updates are intermittent | Link errors, resource pressure, reconnect behavior, or excessive flow rate | Correlate interface counters, node status, camera load, and Ignition logs |
Do not diagnose the undisclosed application transport by assuming it is OPC, MQTT, or another familiar protocol. The installed node type identifies the actual data path. Confirm that type first, then examine the corresponding listener and security configuration.
How should the Node-RED connection be configured?
- Connect the OV20i to the same routed network path as the target Ignition instance. Record the camera address, Ignition destination, intervening gateways, and filtering boundaries.
- Open the camera's supplied Node-RED environment through the documented OV20i management method. Confirm that the Ignition palettes appear before installing or replacing any packages.
- Open the help and configuration panel for the intended Ignition node. Identify its required destination, port, security, authentication, item-mapping, and reconnect fields. Match them to the corresponding configuration on the Ignition instance.
- Create a minimal diagnostic flow that produces one known, changing test value and passes it directly to the Ignition node. Keep image processing, production logic, transformations, and multiple tags out of this first test.
- Configure the Ignition-side receiving resource required by that node type. Give the connection only the permissions required for the test item and confirm that the referenced destination exists.
- Deploy the flow and observe both the Node-RED node status and the Ignition diagnostic or application log. Treat authentication failures, unavailable listeners, rejected item names, and transport timeouts as separate fault classes.
- After the test value transfers reliably, add the camera data source and transformations one stage at a time. Recheck camera processor, memory, and storage behavior after each material increase in workload.
How is the integration verified end to end?
A green or connected node proves only that a session exists. Functional verification requires a controlled value to cross the entire path and arrive at the correct Ignition destination with the expected type and update behavior.
- Set the diagnostic flow to generate an unmistakable sequence, such as a monotonically increasing counter.
- Observe the value immediately before the Ignition node to prove that Node-RED is producing it.
- Confirm that the Ignition instance records the same sequence at the intended destination without mapping or type errors.
- Interrupt the network path briefly using an approved maintenance method, then restore it. Confirm that the node reports the interruption, reconnects, and resumes current-value transfer without requiring a camera restart.
- Run the production flow under representative camera load. Check for dropped updates, growing queues, repeated reconnects, camera-service degradation, or resource exhaustion.
Which pitfalls recur on embedded camera integrations?
Installing a second platform on an embedded device is not equivalent to installing it on a general-purpose server. Before considering local Ignition Edge, read the OV20i system information for processor architecture, available memory, persistent storage, and free capacity. Then compare those measurements with the exact Ignition distribution and Java runtime requirements. Compatibility cannot be inferred from the Ubuntu name alone.
Avoid upgrading Node-RED, replacing the preinstalled palettes, or altering system runtimes merely because the first connection fails. Those changes add variables below the actual fault. First prove physical connectivity, addressing, routing, port access, matching security settings, and correct item mapping.
Keep the diagnostic flow smaller than the production flow. Large payloads, high update rates, retained queues, and verbose logging can consume the limited headroom of an embedded camera. Establish the working transaction first, measure load, and increase scope incrementally.
FAQ
What happens if I install Ignition Edge directly on an OV20i?
Installation depends on the camera's processor architecture, Java compatibility, storage, memory, and available processing headroom. The lower-risk design keeps Ignition on a separate host and uses the OV20i's preinstalled Node-RED Ignition palettes.
What happens if Node-RED can reach the network but not Ignition?
Compare the destination address, configured port, routing, firewall rules, security mode, and credentials with the active Ignition-side service. The selected palette node's help identifies the required transport and fields.
What happens if the Ignition node connects but no values update?
Send one changing test value directly into the node, then verify item mapping, data type, destination existence, and write permissions. Inspect the value before transmission and at the Ignition destination to locate the stopping point.
How do I verify the OV20i Ignition connection is fixed?
Send a known counter through the complete flow, confirm the identical sequence in Ignition, restore the connection after a controlled network interruption, and perform the final verification under representative camera load.