Groov Manage API Question

[varland]

On a previous post about reading a R-1 scratchpad value from Node-RED, @Beno said the following:

@Beno

you might be able to use the api/v1/io/{device} to specify the R1 device

I’m investigating this route this morning and using the Swagger API reference as a guide. Unfortunately I’m not able to get any device other than local to work. I have the R-1 defined in the strategy running on my EPIC as pac202, but my request times out when I use that as the device. I suspect that’s because the manage API doesn’t really deal with strategy variables, but thought I’d ask here before giving up.

Any suggestions?

[Beno]

I’m a bit confused by whats happening here - ie, what you are trying to do, so hopefully as you break it down for me, all will become clear…

So the swagger doc is your browser talking to the device that is in your browser URL bar.
There was no swagger doc embed in the R1, so I am assuming you are trying to use swagger from an EPIC/RIO with the API key from the R1 and somehow making calls to the IP address of the R1 (since the R1 can not support host names).
Hope that helps explain how I am confused.

To make API calls to the R1…
https://developer.opto22.com/rest/pac/

Then in Node-RED or PAC Control set up the API keys and make the call to your other IP address.
Be sure and not use https on the R1.
Most of all don’t try and use swagger, the PAC API is different from the swagger EPIC/RIO API.

[gerhardK]

And do not forget to make the Strategy Variables you want to access public in PAC Control.

[varland]

My hope was to be able to use the Groov manage API in order to read a value from the scratchpad area of an R1 controller on the same network. The R1 controller is defined as an I/O device in the strategy running on the EPIC-PR1 I’m connecting to.

I would love to find a way to make it work, though I’ve worked around the issue for now.

[Beno]

Still confused, but will read between the lines…
groov Manage cant make API calls, its not a client, its a server, you can have, for one example, Node-RED make API calls on groov Manage. You cant use use groov Manage to make API calls on anything.

As I said, the groov Manage API URLs are different from the PAC R1 API, so the commands are different.

Node-RED → EPIC (groov Manage API)
Node-RED → R1 (PAC API)

They are going to be different URL endpoints.

We have customers doing just this:

Authenticating Opto API calls with HTTP request

Here are some tips to using Opto API’s like groov Manage, groov View, and PAC Control with the standard HTTP request core node. In this post I’ll go over how to set the apiKey header object and how to enable SSL/TLS in the request node. Note that this doesn’t and shouldn’t replace the groov IO nodes, groov View,or the PAC Control nodes – it just provides a way to use API endpoints that are not exposed through those nodes. For example there is no way to use a node to unmount an installed USB dri…

PAC REST API available?

The key to getting it going is to have /pac/ in the URL like https://epic-hostname/pac/device/... If you need more specifics there’s a PAC API reference on the developer site as well as the info on the forums.

Rest API: Manipulating IO Points

Check out http://developer.opto22.com/ and if you have any questions after going over that site, come back and just ask.

Let’s know what you want to use to make the SNAP PAC R1 API calls with (Node-RED, Python, PAC Control etc) and we can see if we can help.

But in short, yes, what you are trying to do is pretty easy and a lot of people have built applications around the PAC RESTful API.

[varland]

As far as I know, there is no REST API for reading values directly from the scratchpad of a R1/S1 generation controller. I’m very familiar with the SNAP PAC API, but my hope was to be able to read values from the scratchpad area of an R1 controller that does not have a strategy running on it (thereby making the SNAP PAC API a moot point).

In my case, I’m using a LCM4 controller to write values to the scratchpad area of an R1 controller. I certainly know that there is no REST API for the LCM4 controller. Also, as far as I know, a LCM4 controller cannot write directly to the scratchpad of an EPIC PR1.

In the post I originally quoted here, here is what you said:

Sort of…

There is no RESTful interface to the scratchpad area on the R1, so Node-RED can not read/write to it directly. What you need to do is set up a chart that reads and writes the required scratchpad area in and out of variables. You then use Node-RED to read and write to those variables.

If you have an EPIC in the mix could you might be able to use the api/v1/io/{device} to specify the R1 device… But I suspect the looping chart moving data in and out of the scratchpad would be the most straight forward way.

It’s that last paragraph that piqued my interest. I was looking for documentation on how to specify a PAC R1 controller as the device for this API endpoint. Perhaps I misunderstood your intent from that quoted thread, but that was my take: that it may be possible to accomplish what I want through the Groov Manage API. If it’s not possible, that’s okay. If it’s possible to write to a Groov EPIC PR-1 scratchpad directly from an LCM4 controller (adding the PR1 as a B3000 SNAP Mixed I/O (SNAP-B3000-ENET like I do for an R1 controller), then this whole discussion would be academic.

I appreciate your help (as always) even when I’m not necessarily explaining myself well.

[philip]

It is possible to use the OptoMMP protocol in Node-Red, I use it to quickly read a couple IO points on RIOs, as it is faster and uses less CPU than using the REST API. It is a roll your own sort of affair though.

I’ll see if I can dig up a sample for you if you’re interested.

[varland]

No need. I’ve figured out what I need. I’m not sure why I thought that you couldn’t write to an EPIC scratchpad from an LCM4 controller, but I’ve verified that I can do that, which eliminates my problem.

[matthew.whale]

Hi all, I have three questions:
Q1, I have several APIs working fine in a python script except that they are slow, at a minimum of 90 milliseconds per read/write. It appears that that is the time from the request packet being sent until the response is received from my groov EPIC, I probably can’t do much to change that. I need to be-able to do all of my read/write operations in less than 500 milliseconds, so this only works if I only have 5 maybe 6 tag to update or read. My first though is to do all write operations in a group payload using the ‘api/v1/io/local/mmp/address’ PUT API but I can’t find anything that explains how to structure more than one mmp address to update. For whatever reason in the swagger ui setting up the payload like this works:

{
“values”: [
{
“address”: “0xF0D81038”,
“stringValue”: “0”,
“numberValue”: 7,
“type”: “int32”
}
],
“encoding”: “ascii”
}

and doing this works:

{
“values”: [
{
“address”: “0xF0D81000”,
“stringValue”: “0”,
“numberValue”: 7,
“type”: “int32”
}
],
“encoding”: “ascii”
}

but doing this does not:

{
“values”: [
{
“address”: “0xF0D81000”,
“stringValue”: “0”,
“numberValue”: 7,
“type”: “int32”
}
{
“address”: “0xF0D81038”,
“stringValue”: “0”,
“numberValue”: 7,
“type”: “int32”
}
],
“encoding”: “ascii”
}

What is the proper way to format the ‘api/v1/io/local/mmp/address’ PUT API?

Q2: I don’t see an equivalent API for reading the memory map address in a block request is there one?

Q3: Is the OptoMMP for Python faster?

[philip]

Q1 You’re missing a comma on your group PUT request between the two objects in the array.

Q2 You should be able to read a continuous block of values using the length parameter of the API. You should also be able to do a similar array of request values on a GET request if they are not contiguous - but I’ve never tried this. You can look into the custom configuration area if you want to read noncontiguous values contiguously.

Q3. Yes, MMP is faster - Getting and setting values over MMP protocol is the fastest way to move data other than using MMP UDP streaming. Way less overhead than the REST API.

[torchard]

@philip is spot on with all points. I strongly recommend switching to MMP for anything faster than 1s, you should notice an immediate increase in performance without much extra overhead. Just make sure you do have some kind of sleep in the script so that it doesn’t completely overtake the CPU and cause other software to slow down.

Also, using the OptoMMP Python module you can ReadRawOffset(offset, size, data_type) to grab blocks of data and unpack it manually if needed. It’s a bit of extra work but it could help you squeeze out some extra performance if you really need it.

[matthew.whale]

Wow… let me catch my breath…

1. Thanks a lot for the quick and helpful responses!
2. I am stunned how easy it was to get the OptoMMP Python module running. yes, change “import O22SIOUT” to “from optommp import O22SIOUT” in the package ‘init.py’ for python3 users. -Easy. Using SetDigitalPointState and GetDigitalPointState was super easy.
3. and talk about fast I can now set and get to the same point in less than a millisecond.

Thanks again!

• PS
  I have not seen any videos on using this route. The module should be talked up more. I wasted a lot of time developing for the rest api when I should have started with the OptoMMP Python module. I glad it is so much better.

[torchard]

Thanks for posting this follow-up, I’m glad it’s working for you!
I just shot a video that shows the module and some basic Python and it will be up very soon

EDIT: @matthew.whale you can check out the video on our website before it gets uploaded to YouTube – Opto22 - Video: Getting Started with Repositories and Python on groov EPIC & RIO