Can I remotely reboot EPIC without manage?

It’s far away and I get this when I try to load groov manage:


The control engine is up and running. Shell access is not configured.

Anything I can do?

Can you get to Node-RED?
Can you remote into a PC thats on the same network (in case its a WAN issue vs a LAN)?

The node-red link gives the same error. I’m on the customers VPN, so I am essentially local.

Is there an OptoMMP command that will reboot the whole enchilada?

I was just going there. I think there is, its in the forums… Just doing a search now… So Im thinking you can just add it to a strategy and fire it off one time.

EDIT: Found it: Reset controller from software?

I gave it a try and I got error code -56 - Invalid Address

The OptoMMP manual shows it as not being supported too:


I may have to wait until someone is on site to power cycle it.

Uh, yeah, I do remember that now…
I am not in front of a unit, but Im thinking if there is something in the API… I don’t think there is, but we are grasping for reboot straws after all…

If your nginx server is down or corrupted, this will probably not work. But maybe useful for other situations. Although maybe not so obvious, everything in the groov MANAGE menu options are really just REST GET or POST calls. So with a bit of fiddling, any menu option can be turned into a post or get command. You obviously need to know the hostname or IP, and then use a administrator user account already configured on the device, but the following is basically what you are looking for.

post https:///manage/api/v1/system/restart

Here is some scriptcode that you can import into Postman and then modify for your own specific controller to see the concept.

	"info": {
		"_postman_id": "ce05aa90-006a-44ee-a912-52eb193a821c",
		"name": "groovEPIC",
		"schema": ""
	"item": [
			"name": "Restart EPIC",
			"request": {
				"method": "POST",
				"header": [
						"key": "apiKey",
						"value": "sVEJ2bQq77nNqnNReZLGSBdwnWFjHZnv",
						"type": "default"
				"url": {
					"raw": "",
					"protocol": "https",
					"host": [
					"path": [
			"response": []

Correct. Terry and I have been using these unofficial API calls for odd jobs for a good long while.
It does not need saying, so that’s why I am here to say it…

These unsupported/undocumented API calls should never be relied on in production or continuous use.
Opto reserves the right to remove or change them without notice.

But until then, have fun!


I am new to the groov architecture. Is there any way to replicate this with Node-Red on a RIO?

Hi Karl, welcome to the Opto 22 forums.

In short yes. You can do the API call in Node-RED and thus reboot your RIO… Of course, I gota ask why?
What problem are you finding that needs a remote reboot?

I have a non-critical process running that is slowly driving the PLC up to 100%cpu then we start getting errors. Originally it was not an issue as the PLC was powered in tandem to the equipment, but then change…lol another flow in Node-red was added and all was good until day 12 and the CPU hit 100%. I have many azure data calls and timing calculations going on. This would be the simplest way to verify a full restart. I know of the MMP write. Just need values to activate the reboot correctly while unattended and on schedule.

Hi @kyeager! When you refer to “the PLC” are you referring to the groov RIO in question? Rather than remote reboots, perhaps we can solve the 100% CPU issue in question.

@Dan_Opto I’m game. What do you need from me?

Do you have shell installed?
If so, run htop and take a screenshot when its just started up and another at say day 6 or 8, ie before day 12 ‘crash’.
Lets see if we can identify the process that is leaking.

If you don’t have shell installed, could you add this flow?

And this flow:

We are interested in the same data as htop, that is CPU over time and memory over time from the first flow.
The second flow should show us what process are leaking.

Requesting a shell lic now…

"Don’t shoot the piano player"

I’m not sure that when hitting problems with connections to Azure through Node-RED code, the correct response is to reboot the opto22 device. Its a bit like the old joke of the software engineer whose car breaks down and he wonders if he can fix the problem by getting out of the car and then getting back in again.

Most Azure connection problems in Node-RED are usually due to poorly written flows, bad use of the node plus the fact that most free 3rd party nodes for Node-RED have little or zero recovery code for comms problems errors. Its easy to write a program to do something, but not so easy to write a program to react and recuperate when the results are not as expected.

Just for starters, when your device can’t communicate with your DNS Servers as configured, this will end up driving your Node-RED Azure node code into oblivian, as the node now can’t even find the Azure servers. If you think about the other 99 things that can also go wrong , its maybe a miracle that the cloud connection works.

Sometimes its better forget the use of free nodes with no support, and just buy the software tool prewritten. Did you know you can add a fully supported Azure injector module for Ignition EDGE for $200 (list price) written by Cirrus Link? I have not used it in RIO2 yet, (hope there is enough memory) but it works like a dream out of the box with groov-EPIC

1 Like