[PROJECT] Driver for Neptune Systems Apex

Glad to hear they are useful. Do you have a thread about your digital signage? I keep meaning to get SOMETHING running to act as a dashboard/central control but I start and never finish the process...

I use this and I love it! https://dakboard.com/ . You can get basic board free and run on a rasp pie.
But i bought their "Wall Display" and have a paid account which lets me fetch external data,
combine that with the Hubitat MakerAPI and you can easily put any device on the dashboard.

Here is a good thread about it

1 Like

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.11


  • Apex A3 should now be identified automatically. The model reported in the data was a bit different than what I expected based on the previous models. Thanks to @lparks for providing the sample.
  • Apex A3 (A3 Pro, A3, and A3 Jr) controllers SHOULD now have their FMM inputs properly populated. They were likely getting put as an "Unknown" module in DID # 1 (because that is how Neptune Systems treats them for some reason). HOPEFULLY the code should now recognize that it is an A3 and if there is a #1 module to put those sensors with the controller instead and NOT create an "Unknown". If you already have a child device like that you can delete it. If it comes back... that means it is still having data sent to it from somewhere in the driver (I messed up).


  • Since I do NOT have an A3 controller I cannot directly check any of these changes. They did not break anything I noticed on my Apex 2016 at least.

moving this post to a new thread...

I would recommend starting a separate thread for your driver so that any feedback and such can be kept distinct from this one. that way people do not start mixing the capabilities.

On a different note I am sending you a message with some things you might want to look at. :slight_smile:

yes @snell agree...

here is a link to a new thread... with a link back to this one too

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.12


  • Correction to module type checking being performed in the module map generation. Basically, if you were trying to install this new, it was failing to generate the module map State Variable because it was trying to CHECK the map while it was generating it. This was code added to try to handle the weird way Neptune Systems implemented the FMM-type inputs on the new A3 controllers. The code is now changed to check the temporary map that is in progress.

Hi there, thanks so much for the effort here on this driver. I've skimmed through all 222 posts and cannot figure out if it's actually possible to turn one of the outlets on/off in a rule. I have Active Control enabled and can change the Outlet Mode on the desired outlet on my EB832 manually in the child device commands but can't seem to figure out how to expose this capability elsewhere in Hubitat. Thanks in advance for the help!

In general what you need to do (in Rule machine) is use a Custom Action. It is unfortunately not as easy as a normal switch (because of the multiple outlets and other factors) but it is pretty easy once you are used to it.

For example, when adding an action you:

  1. Select the "Set Variable, Mode or File, Run Custom Action" category.
  2. Select the "Run Custom Action" action.
  3. Select the "Actuator" as the device Capability to work with.
  4. Pick the child device.
  5. Select the Custom Command (in this case you would likely want "Outlet Mode").
  6. Outlet Mode requires 2 parameters. You add the first as a number and enter the number of the outlet.
  7. Add a second parameter as a string and you want to tell the outlet what you are doing with it (AUTO, ON, or OFF).

Here is a screenshot of a sample I made just now, for an EB832 that would turn outlet 1 ON.

That's great, thank you. Pretty easy to setup as you say, unfortunately nothing is actually happening on the Apex when I initiate the action. To be clear, I've created a virtual switch and tied the Rule to the switch like a toggle button. See below.


Try selecting the GetCookie command in the parent device, then trying the Rule again. Sometimes the cookie expires and it does not get renewed before the commands run. I just saw this on my own while checking real quick. I will have to see if there is anything better I can do about the cookies tonight (have to get to work for now).

Sorry had to get to work as well... came back to this, ran the GetCookie command but still nothing happening. Seeing this error on the EB832 log:

dev:12442023-02-04 10:41:57.971 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_Snell_NSChild_EB832_1141.OutletMode() is applicable for argument types: (java.lang.Integer, java.lang.String) values: [7, AUTO]
Possible solutions: OutletMode(java.lang.String, java.lang.String) on line 6245 (method OutletMode)

dev:12442023-02-04 10:41:54.889 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_Snell_NSChild_EB832_1141.OutletMode() is applicable for argument types: (java.lang.Integer, java.lang.String) values: [7, OFF]
Possible solutions: OutletMode(java.lang.String, java.lang.String) on line 6245 (method OutletMode)

I was also trying to search the logs for what happens when I control the outlet from within the EB832 device page, since that is working. Maybe I'm missing something, but I can't get any feedback on what's happening when I send those ON/OFF/AUTO commands.

Looking at the error I think I have it figured out. The outlet number is being sent as an integer, but the function is looking for it as a string.

If you set the rule to send the first parameter as a string, does it work?

That did the trick. Thanks for all your help!

I am glad that it was solved... I am trying to think of a better way to handle it in the first place. Most people will think of the outlet as a number. It cannot get treated that way in the final code though (it has to be sent as a string because it has non-numeric characters). I will see if I can make it handle receiving both types just in case.

Could just overload the method, i.e.

def stringInteger(Integer var) {
    log.debug "Integer"

def stringInteger(String var) {
    log.debug "String"

Yeah, I know... I dislike overloads though. It just strikes me as a messy thing, something that was ingrained in me MANY decades ago as a programming "no no" (because those languages could not handle it well).

1 Like

So a little update here. I have a filter pump on the Apex which I aimed to turn off if water sensors at the aquarium detect a leak. I tested the sensors today and the message didn't get sent to the Apex to turn the pump outlet off.
Playing around, I was able to get the comms working again by running the Get Cookie and Refresh commands on the Apex. This kind of manual intervention isn't going to work for the water leak rule. Is there any way to solve this?

Understandable. The cookie problem is an odd duck... It must have expired, but I do not know the interval. I will try some things out.

In the meantime, the workaround could be to trigger a GetCookie and such before the command... Just to make sure the cookie is valid.

Either way I will try to work out a way to make it better tonight.

Testing it with a cookie check every hour instead of once per day (what it currently is set for). Unfortunately this process takes a bit...

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.13


  • GetCookie is now set to a 1 hour schedule. This will only happen if you have children enabled AND active control enabled (it only matters for those anyways). If either is disabled it will be unscheduled. Previously this was set for once a day. At this time 1 hour seems to make it "under" the threshold before the cookie expires so none of my command attempts failed on my Apex.
  • refresh() is now run when an active command gets the response of "AUTO". Turns out that the response from the API does not actually say what the AUTO value would have been (normal status information says if it is AON "Auto On" or AOF "Auto Off"). But the response for an active command was only "AUTO"... so what is it? Since there was no way to tell (since it is the controller deciding in that case) it will now trigger a refresh so it can get the status.
  • A module update apparently added the "alert" type to (at least) the FMM. Data handling has been added to post that as a state variable to the respective device.
  • Minor change to the ProcessEvent command to bring it more in line with my current methods (it can now have an event "forced" to put the isStateChanged).

Download the Hubitat app