[PROJECT] Driver for Neptune Systems Apex

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

Change(s):

  • 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.

image

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"
    stringInteger(var.toString())
}

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.

EDIT:
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

Change(s):

  • 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).

any mxm support planned? have a module and happy to share logs as needed!

If you can send me the logging information when you perform a refresh, or send me a copy of the Apex's status.json file (please send either as text in a separate message, not in the main thread) then I can try to incorporate support.

I am always willing to add in new modules and features... but I do not have any specific plans. :slight_smile:

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.15
  • NSChild-AI.groovy = 0.1.1
  • NSChild-Vortech.groovy = 0.1.1
  • NSChild-Radion.groovy = NEW, added to links in original post
  • NSChild-Vectra.groovy = NEW, added to links in original post

Change(s):

  • Initial support for the MXM module added. There is no child for the module itself because it apparently does not have any specific data for itself. It does provide data on the lights and pumps connected through it though, so these are provided (if possible). At this time that includes Vortech pumps, Vectra pumps (assuming I got the type identification correct), and a bunch of Radion lights (a couple I had identification for, the rest are a big assumption at this time).
  • New child drivers have been added for the Vectra pumps and Radion lights. They have basic active control capabilities (set the mode and level) in each (assuming they can do it based on the data so far and feature set).
  • AI and Vortech drivers have been updated to provide basic active control (mode and level).

NOTE(s):

  • Despite the MXM supporting AquaIllumination lights, no attempt at support was included yet because I have no samples of what they might be provided as and there are just too many types to guess without a sample.

Thanks for this update!

Hi There!

I'm trying to get this running with my apex, but I'm getting an error in the Logs:

java.lang.NullPointerException: Cannot get property 'Type' on null object on line 667 (method ReceiveJSONData)

2023-09-30 04:20:56.152 PM[info] ChezGallant - Unknown Apex controller type AC5L, please let developer know

Looking at the code, there is no detection of AC5L-- not sure what hardware that corresponds to?

Thanks,
Jason