Alternative methods to save to controller?


I was curious if there are any other documented means of reading/writing directly to the PAC. I am enjoying my time with both the Groov and PAC Control/Display. However, I keep thinking of one off cases where I might want to read/write directly. Any options?


Hello Bogaat,

Could you give us a bigger-picture idea of what you have in mind here? What are you saving to the controller, for example?

As you probably know, the “control engine” part of our PAC-S and PAC-R controllers (SoftPAC too) read/write to the I/O part of a PAC via the memory map. There are several options for accessing the memory map in other ways, if that’s what you mean. Our controllers also have a file system which can be accessed in a number of ways too.

Can you give us a few more details about the what/why of what you’re trying to do? Lots of options, just need to narrow down a little here…



Hi Mary,
I think you completely answered my question. Once you mentioned memory map, I found the document detailing the OPTOMMP protocol. It might be just what I want. The situation is that I am in the process of designing a new UI. I would like it be web based. If Groov had an API, I would be in heaven. However, the next best thing is for me to build a service using SOAP/REST…and then build my own web UI using javascript/html. A lot of work there, but it may be worth it for the benefits of cross platform/mobile/etc. I will likely start down that path to feels things out…unless there is a Groov API in the near future? :slight_smile: . I do love me some Groov…


FYI - the people who most appreciate [I]groov [/I]are those who have tried to roll their own, including a few of my coworkers, whose efforts were something of a “proof of concept” or early prototype of what became [I]groov[/I].

I’d still like to hear more about your big picture, but be sure you also check out this post which is something of an API using the mem map as glue. That post has all the pieces for Windows, and we already have many of the pieces for Linux. What platform(s) did you have in mind?



Designing your own UI… Wow, that’s a solid work load there, not just the developing, but the maintaining…
I know because I am one of those that Mary mentioned, we built our own…

I have to ask… what do you need your UI to do that groov can not?
groov is young, the only way we are going to help it grow up is to hear what its missing, so please, if you can, take a moment and show us what it can’t do such that you have to go to the effort of building your own…



I will take some time for a thorough response. Be in touch…


Ok, so I truly don’t want to build my own UI. I understand the work. That being said, I have some time to build something great and I want to do it right. As mentioned before, I am a greenhouse grower. The company who sold me the greenhouse controller is allowing me to do some dev work. This benefits me given I use his product and can steer enhancements to my favor. I also just enjoy coding. Over the course of my (previous) career as a software engineer for an enterprise CRM product, I became proficient at several technologies including javascript/EXTjs. What I want is a web based solution for my greenhouse and potentially others. When I say web based…I mean the entire Opto UI. PAC display works well, but lacks when it comes to modern IDE/UI, cross platform and code obfuscation. Groov is awesome as a dashboard. The timing of its release coincided with my greenhouse construction and I couldn’t be happier with the product. However, it is obviously not a replacement for PAC Display. It almost could be but needs at least a few things…

  1. Gadget integration – I need to be able to pull these gadgets into other web pages. This would allow me to build my own UI and integrate Opto set points. Them being tied only to Groov pages is a limitation to do anything beyond dashboards (no dialogs, etc). My own UI would allow integration with other functions (harvest data, client profiles, orders, report viewer, etc).
  2. Style sheets…I need to be able to style these gadgets to match branding.
  3. Gadgets – either I need the ability to create custom gadgets or the existing ones need the ability to interpret multiple tags or a piece of script. I mentioned this in another post. I may want to read two tags and display a status…or I may want to read an integer and display a string.
  4. Grid – I have a ton of setpoints in Opto display. I currently build a custom grid. Each cell has a range of values or one of six states (depending on the column). This would be a heavy gadget. If I could access tags directly and build my own in js it would be much simpler.

I think the key here is customization. If we could just scrape one layer off of Groov for development purposes, we would have a winner. That being said, I feel sure you have a plan for the next generation Display product and Groov. My needs are obviously not those of the average user. I want to build something that will give my controller guy a true advantage for sales and something so versatile that I have no limitations for years to come. All being said, I may wimp out and do my best with PAC Display until you guys come out with the next best thing at some point in the near or distant future! I will be using Opto products for many years…

If you ever need a guinea pig…don’t hesitate to contact. Thank you again for your excellent products. I have options with an Opto controller that I would never have had with the alternatives. Thank you :smiley: