[PROJECT] Driver for Neptune Systems Apex

If you get any new ones I do not have or if there is something I am missing now, let me know and I will try to get it in there as soon as I can.

I’m planning on picking up the new leak sensors and eventually the new MWM (not sure when that’ll be coming out). But that’s it. I’m not upgrading to a new A3 head unit as I have no reason too at this point.

Yeah, the new A3 sounds interesting but the reasons to upgrade from an existing Apex are not hugely compelling to me. If I was building a new (expensive) system, sure. I would probably go with an A3 Apex Pro.

I especially like the new level sensors although I am curious as to how long they will last before becoming inaccurate.

On a different point, Neptune Systems completely ignored my latest communication to discuss their API... not even a "no thank you, we will not be discussing or providing any information about it, it is not meant for customer use". Oh well.

I just hope they never close the hole to prevent us from being able to utilize it.

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.9
  • NSChild-Sicce.groovy = 0.1.1

Change(s):

  • GetCookie can now be run as a manual command from the parent device. Only matters for those people using ActiveControl and can help in odd scenarios where the automatic cookie has expired for some reason (and before the next one is retrieved).
  • Sicce child driver now has the ability to set the PumpMode command with either on/off/auto options. This allows a user to set it back to Auto control by the Apex after having performed something manually with it using the on/off commands.
1 Like

I sent you a status.json from my system. I do have the new A3 Pro.

1 Like

Thanks! I replied to confirm a bit of the data, but it looks like I should be able to make changes to spot it easily enough.

Updated Version(s):

  • NeptuneSystemsApex.groovy = 0.100.10
  • NSChild-ApexA3.groovy = NEW, added to links in original post
  • NSChild-ApexA3Pro.groovy = NEW, added to links in original post
  • NSChild-ApexA3Jr.groovy = NEW, added to links in original post

Change(s):

  • Added support for the data type that the new level sensors report "in". This requires no changes for the NSChild-FMM driver, the new value will report as one of it's switch inputs. However, if you had something checking that attribute already make sure it can handle a number now if you put one of the level sensors where there used to be just an open/close style sensor.
  • Added child drivers for the new A3 controllers. Based on data from @nicholb (THANKS!) I am pretty confident the A3 Pro will be recognized. I HOPE the A3 Jr will be recognized... and right now the "standard" A3 will NOT be recognized. They did not make the controller identification from the status file as easy as I could hope.
  • A3 controllers have FMM-style inputs on them (the number varies). These will be reported in the attributes as "FMM Input <#>". Since Apex controllers (except the A3 Jr) have switch inputs already I could not keep them the same naming as normal FMM inputs (which are Switch Input #) because that was already used for the Apex switches as well. Since these are new though, it should not cause anyone to have to rework anything. These new attributes will handle either the open/close or level sensors.

@snell Found a small "bug" if you will...

The EB4's are showing as EB8's on my new install that I did tonight when I wiped my entire setup and re-installed.

I will try to check into it tomorrow... I must have made the identification for the EB8 too lenient. Sorry about that.

One more thing... I'm seeing this in my logs.

dev:702022-10-03 02:20:35.204 pmerrorNeptune Systems - Not all modules accounted for, missing 2

Any idea what to look for to track this down?

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: