[PROJECT] Driver for Neptune Systems Apex

Are there any modules that did not have child devices created for them? There is also the State Variable "Module Map" that should give a map (array) of each device with the DID the Apex assigned it).

Edit:
For the EB4 issue... I am looking over the code and hitting a stumbling block. not sure HOW it could change an EB4 to an EB8 unless it detects an 8th outlet (that is the trigger for that conversion). If you could enable Trace logging, then delete the child device does it get recreated (on the next refresh) as an EB4 or an EB8? The log should show "EB4 module changed to EB8..." in the logging if it does get converted.

I’m going to look into this more this eve. Been busier then all get out lately between working on putting a deck on the house, solar panels on the roof and redoing my HE configuration plus nodered and influxdb. Crazy how much there is to do from scratch.

1 Like

No worries at all. I get being busy, I've been away from home for a few days anyways.

@snell I can't thank you enough for these drivers. I just wanted to show you a great use of them. I have a Dakboard (digital signage) in my home office showing my calendar, todo's, energy consumption, weather and NOW....... thanks your drivers... i can easily have the readings from the APEX. These are actually for my reef tank on the other wall not the planted tank below the dakboard, but i'll probably get more probes for this tank too.


Thanks again...

1 Like

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

Change(s):

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

Note(s):

  • 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

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"
}