Missed Events With Polling /api/v1/io

#1

We are using the new IO nodes for Node-Red, and are concerned about polling performance with a loaded EPIC controller.

The concern is with input nodes. Each channel starts a 1 second poll using /api/v1/io, which feels sluggish in HMIs, and it can miss logging events if they happen within the polling window.

We’re considering changing the polling delay to 100ms which reduces (but doesn’t eliminate) the problem, and am concerned about it flooding the controller and Node-Red with activity with a significant number of input channels.

Would it be possible for the IO API to support websockets (or long polling)? We see the input module lights on the EPIC controller appear in near realtime, and are concerned about missing those events.

#2

I think what we are talking about is the difference between using PAC Control to do control and using Node-RED to do control.
PAC Control is a lot more closely tied to the hardware, but struggles somewhat with doing things like API calls. Node-RED is abstracted from the hardware, but excels in doing API calls… Different tools for different jobs. Both can do the same job, but each has its strengths and weaknesses in doing that job.

While I would recommend using PAC Control for control and using Node-RED for information exchange, I understand that you have deep knowledge of Node-RED, so lets take a quick look at some possible optimizations.

Use sensible scan rates. Not all signals need to be scanned at 100msec, analog for example can be a lot slower. Use the inject node wisely to only poll at the rate that makes sense for the signal.
Speaking of inject nodes, as you know, you can put in fractions of a second, so consider using prime numbers to spread the load.
Use On/Off latches to catch events. Don’t forget to reset them once read.
Use the digital counter feature to track events over time.
Use the MMP addresses to get other channel specific feature values.

At the moment, engineering resources are committed to other projects, so changing the API is not something we can give any time to.

1 Like
#3

Thank you for that quick and thoughtful feedback. For our purposes, tuned polling of specific channels will work until a push-based API rises to the top of the engineering schedule.

The likeliness of missing a sub-second event is low, whereas the likeliness of our customers thinking our solution is sluggish is higher.

I’m on a crusade to eliminate polling from all technologies between our customer pushing a button on their mobile device, and them getting verification of that action.

With all the gateways, routers, proxies, firewalls, tls, servers and devices along the way, it’s amazing that one polling interface can be the difference between snappy and sluggish.

Totally an IT problem - not an OT problem.

#4

Have you looked into using MQTT?

#5

I have not. Is there an MQTT interface with groovEPIC module/channels, where I could subscribe to a topic and be notified when a digital input changes state?

If so, could you provide a link?

#6
3 Likes
#7

Its well worth taking a look at MQTT.
https://www.opto22.com/support/resources-tools/documents/2267-groov-epic-user-s-guide
Chapter 8 is all about MQTT on the EPIC.
Using the built in publisher you can do exactly as you asked… Interface with the EPIC Modules to channel level and have them publish their values only on change.

2 Likes