For those that are interested, I am making this driver support child devices AND refining how it identifies and displays inputs/outputs. Putting them into child devices should make it much easier for people that need different temperatures or such with multiple probes.
However, one stumbling block so far is to best identify all the TYPES of devices out there. The base is easy, it reports as such. Auto Feeders are also fairly easy. I think I can figure out EB4, EB8, and EB832s as well. But the PM modules, ATK, etc... not as sure yet on how to figure them out, let alone stuff I do not have like DOS or Trident.
If anyone is willing, I would love it if you could shoot me a sample "status.json" file from your Apex and a list of what modules (from your Apex's webpage at /apex/config/modules). If you do want to send it to me, please send it as a PM so we do not clutter up the topic here.
Thanks for any help you folks provide! I hope you will like the upcoming changes. Even if I do not get all the modules identified, it will still make it easier for people to let Hubitat "know" what their Apex is doing.
I don’t have all my stuff hooked up yet and probably won’t for awhile. I’m not using a DOS or Trident. My ATK will get hooked up once my sump is hooked up which will be in a few weeks. I have PM1 and PM2 modules but the PM1 is just used to connect my BoB and the PM2 will be used just for connecting a 2nd temp probe on my frag tank. I’ll try and provide what I can. I’m not sure I’m understanding what you’re trying to do and hope it doesn’t mess up what I have although I’m pretty sure it probably will lol! But what I’ve done so far is create multiple virtual devices and pointed them each at the Apex and called different inputs and outputs in each one based on the device i am monitoring. So I have a leak detector, a fresh water barrel, salt water barrel, and break out box. My additional FMM for the LDK that I plan to add I was just going to add the solenoids to a new virtual device and a leak sensor connected to that FMM at my sump to the already existing Leak detector virtual device. Does that make sense?
None of the existing functions should break. Child devices are an option you will be able to turn on, but are not on by default. In addition, they do not remove any data from the main device. The goal is to have them represent the data in the same way the setup is, per module. So if you had a second temp/pH on a PM module instead of just the base you could select the temperature attribute from that child device instead of using a custom one.
So it might make things easier if you do not already have workarounds in place, but it should not break the workaround and you do not even need to see them if you don't want to.
Ok, here is the big revision (the basis for it at least)!
Version 0.98.0 of the NeptuneSystemsApex driver is now posted. This is a major overhaul of data handling, but the biggest addition is the OPTION to create child devices. One child device will be created for each module that your Apex reports, if you enable the option in Preferences. In order to actually USE child devices (even if you enable them) you must also have the NeptuneSystemsApexChild.groovy driver loaded. If you do not want to use child devices, no problem AND you do not need to load the child driver. If you enable Child devices without it, it will give you and error about it.
All the modules that provide data will have that data posted as a state or event for the child device representing them, whether I have identified the module or not. If I cannot identify it, it just will not have a Type attribute.
If you have a module on my "I THINK" or "DO NOT" lists below... I would love if you could send me a sample of your status.json file from your Apex so I can attempt to build them in properly going forward.
The modules I have identified for child devices so far are:
base, EB4, EB8, EB832, PM1, PM2, AFS, FMM, & VDM
Modules I THINK are identified are:
PM3, & ASM
Modules I DO NOT have identified:
LSM, WXM, Trident, COR-15, COR-20, & DOS
New versions posted! Thanks to a volunteer over in the Neptune Systems Forum that sent me a sample of their json, a couple more modules are identified, including ones I did not know existed. However, this also taught me that Neptune Systems does not support the json (then why does it exist...) and actually BLOCKS discussion about it because they deleted my posting and told me not to ask there about it anymore. Fun times.
Anyways:
Version 0.98.1 for the main driver, and version 0.1.1 for the child driver are now posted.
These added support for DOS, AI, and Vortech modules.
Updated to version 0.99.0 for the main driver and 0.2.0 for the child driver. Reworked the way the data is processed and provided a lot more state variables (NOT EVENTS) to go through data. Plus new attributes for some things to better account for what they are and what the names for that variable is on your actual Apex.
@snell I’m having an issue where my physical outlets on my eb8 (haven’t hooked up an eb832 yet) are not showing up in the device listing... virtual outlets show just fine. I’m not using the child driver but your latest release and child driver are installed. I know they were seen before and worked but something happened and now I can’t see them. Do I need to use the child driver?
I think I see what’s up... my eb8 is child ID4 which shows all 8 outlets (not named however like they used to be), but in the Json most are in an OFF state with only certain ones ON. In hubitat, it’s showing them all listed as “ON”. Why is it not registering correctly?
I would recommend using the child devices... but I can try to take a look and see if I can figure something out with it. It has been a bit since I have tried things with just the main (no children) so maybe I broke something?
I can see from the screenshots you are using the latest driver, so at least that is all good.
There is definitely something "fishy" going on with the state variables in the parent. Checking mine and they should not all be on. (DOH). Annoyingly, the CHILD device for those same ones seems to be working fine from both the Events AND the state variables...
Now you've got me curious what I broke. I was JUST about to call it an evening on drivers, but now I am checking this real quick.
UPDATE - FIXED
Updated Version(s):
NeptuneSystemsApex.groovy = 0.99.1
Change(s):
A couple of the state variables were being set to "on" when they should have been displaying "off". This did not affect the child devices, only the parent device's state variables representing the outlets and for a dos.
Help me
Understand how the child works? Is this designed to be a single parent (per head unit) with children under it? I’m not seeing the state variables in my rules even when selecting the child?
It will be a single parent with the child devices (it should create one per module you have connected to your Apex) below it. Each child should have State Variables but then they should also have Events (Current States) for their specific features. The children get their values from the parent when it does the refresh. The only command I gave children was one to clear out their State Variables.
Here are a couple screenshots of mine. First is the overall device view showing the parent and children, second is a compressed view of from Child Device #3 (an EB8).
Hey @snell question... what happens when new modules are added to an already existing setup? Will they auto show up as child devices in hubitat after being connected to Apex?
