Retrieving Ignition REST API Data with httpGet and jsonDecode

Ignition reads a web API such as OpenWeatherMap through two scripting calls. system.net.httpGet returns the response body as a string, and system.util.jsonDecode turns a JSON body into nested dictionaries and lists that you index like any Python structure. Run the request in a gateway-scoped timer script, write the values you need to memory tags, and bind window components to those tags. Displaying the provider's HTML page in a browser component also works, but it gives you pixels rather than data.

Symptom and Error Signatures

Most failures on this class of integration fall into a small set of patterns. The term scope here means the process a script runs in: gateway, client, or designer. Each scope has its own network path, its own thread model, and its own log destination.

Request Execution Model

system.net.httpGet is synchronous. The calling thread waits until the remote server answers or the connection times out. On a Vision client, component event handlers and the timer component execute on the GUI thread, so a slow API response stalls every repaint and mouse event in that client. A gateway timer script runs on a gateway thread, so the same delay has no effect on operators.

Scope also decides how many requests reach the provider. A client-side timer component fires once per open client, so ten clients poll the API ten times as often as one gateway script. Commercial weather APIs enforce per-key call limits, and a per-client design is the fastest way to exhaust them. A single gateway poll writing to tags serves every client, feeds history and alarming, and keeps the API key off client machines.

system.util.jsonDecode maps JSON objects to dictionaries and JSON arrays to lists. For the OpenWeatherMap group endpoint, the decoded structure is: top-level list array, each element holding name, a main object containing temp, and a weather array whose first element carries description. The units=metric query parameter makes temp read in degrees Celsius. system.net.httpPost exists for APIs that require a request body; a read-only weather query uses GET.

Gateway Polling Procedure

1. Register with the API provider and obtain a key. Read the provider's documentation for the exact query parameter name that carries the key and for the refresh interval and call limit of your plan.
2. Find the numeric city IDs you need from the provider's city list. The group endpoint accepts a comma-separated id list, which fetches several locations in one call.
3. Prototype in the Designer Script Console. Paste the URL, decode, and print a few fields before building anything else.
4. Create memory tags for each value you plan to display, for example a folder per city with temperature and description tags.
5. Create a gateway timer script at a fixed rate no faster than the provider's refresh interval allows.
6. Write the decoded values to the memory tags using the tag-write function documented for your Ignition version; the function name differs between major releases.
7. Bind labels or other display components in the window to the memory tags.

# Gateway timer script
import java.lang.Exception

URL = 'http://api.openweathermap.org/data/2.5/group?id=5002495,2643743,1850147&units=metric'
# Append the API key using the query parameter named in the provider documentation

try:
    response = system.net.httpGet(URL)
    data = system.util.jsonDecode(response)
    readings = {}
    for city in data.get('list', []):
        readings[city['name']] = (
            city['main']['temp'],
            city['weather'][0]['description'])
    # Write readings to memory tags here with the
    # tag-write function for your Ignition version
except java.lang.Exception, e:
    print 'Weather poll failed (Java):', e
except Exception, e:
    print 'Weather poll failed (Python):', e

Two exception clauses are deliberate. Network and HTTP failures inside httpGet surface as Java exceptions, which a bare Python except Exception does not catch in Jython. Parsing and key errors are Python exceptions. Catching both keeps one bad poll from spamming the gateway log with stack traces.

Display Path Selection

Use the browser path only for a purely informational corner panel on networks where clients already reach the internet. Anything that drives control logic, such as scheduling lighting from a published sunset time, belongs in tags.

Recurring Pitfalls

• Testing from the wrong machine. A URL that opens on an engineering laptop proves nothing about the gateway server, which often sits behind a stricter firewall or proxy. Test from the gateway host.
• Polling faster than the data changes. Weather providers refresh on their own schedule. A faster poll burns the call quota and returns identical values.
• Hard-coding list positions. Index cities by name or ID, not by their order in list; response order is not a contract.
• Printing from gateway scope and looking in the Designer. Gateway print output goes to the gateway's log files, not the Script Console.
• HTTPS and certificate errors. When moving to an HTTPS endpoint, handshake failures come from the Java runtime's trust store on the gateway, not from the script. Check the gateway's Java certificate configuration before rewriting code.
• Sharing projects across versions. A project exported from a newer Designer does not restore on an older gateway. Match versions or upgrade before importing.

Verification Checks

1. Check 1: raw endpoint. Open the full URL, including key, in a browser on the gateway host. Expect a JSON body whose top level contains a list array with one entry per requested city ID.
2. Check 2: Script Console decode. Run the loop below. Expect one line per city in the form Name: temperature description, with temperatures in Celsius.

   response = system.net.httpGet(URL)
   json = system.util.jsonDecode(response)
   for city in json['list']:
       print city['name'] + ': ', str(city['main']['temp']), city['weather'][0]['description']
   

3. Check 3: tag update. Watch the memory tags in the Tag Browser across two timer periods. Expect values to refresh on schedule with good quality.
4. Check 4: client load. Open two clients and confirm the provider's usage counter, where the account dashboard exposes one, rises at the gateway poll rate only, not per client.
5. Check 5: failure handling. Temporarily break the URL or block outbound access from the gateway. Expect one logged failure line per poll, tags holding their last values, and no client freeze.

FAQ