Thanks for this
Updated Version(s):
- NeptuneSystemsApex.groovy = 0.100.0
- NeptuneSystemsApexChild.groovy = 0.2.6
- TOO MANY NEW CHILD DEVICES - NSChild-[Module Name] = 0.1.0 (Initial Release)
Change(s):
- Child device naming convention HAS BEEN CHANGED. If you had Rules based on your previous child devices (if any) you will need to modify those to link up to the new child device that will be generated. Existing children WILL NOT be deleted automatically (unless you disable child devices as usual). The children should be easier to know what is what now. It also helps for the ActiveControl capability if used.
- Added support for specific child device drivers based on the module that a child device is. This requires enabling the ActiveControl feature in the parent device's preferences. When this is enabled (and the correct child device drivers have been loaded onto your Hubitat) then it should automatically set the child device to have the appropriate driver. If it does not you can always delete the device and let it be recreated (if you let it generate the child devices and then later enable ActiveControl) OR you can change the type manually in the child device's settings.
- There are many new child device drivers that have been added. All are optional (and in HPM) but it will give you errors if you enable ActiveControl and do not have the appropriate child drivers loaded for your system. In all there were 18 new ones created... so I am not going to list them all here, but links will be added in the original post for this project thread.
Note(s):
- At this time (despite the ActiveControl feature name) the children DO NOT have any active control capabilities yet. Still working on that. But they should be able to provide more specific read-only attributes than the generic NeptuneSystemsApexChild driver (which is still available, and they could all be set for without issue). However, going forward, active control capabilities that ARE added will be added specifically into the child driver as appropriate for that one.
3 Likes
Updated Version(s):
- NeptuneSystemsApex.groovy = 0.100.1
- NSChild-AFS.groovy = 0.1.1
- NSChild-Apex2016.groovy = 0.1.1
- NSChild-ApexClassic.groovy = 0.1.1
- NSChild-ApexEL.groovy = 0.1.1
- NSChild-ApexJr.groovy = 0.1.1
- NSChild-FMM.groovy = 0.1.1
- NSChild-EB4.groovy = 0.1.1
- NSChild-EB8.groovy = 0.1.1
- NSChild-EB832.groovy = 0.1.1
Change(s):
- ActiveControl capability now can actually DO things with the various modules above. In all cases the features are on the CHILD DEVICES not in the parent driver. The parent driver actually sends the command to the Apex, but only the children "know" what commands they should have. Besides having to have ChildrenEnabled AND ActiveControl enabled on the parent device, you also MUST have the Username & Password set in the Apex URL (ex: http://username:password@192.168.1.50).
- If ActiveControl is used a new scheduled command will run each day "GetCookie". This command is to refresh the cookie from the Apex itself that is needed for the functions to work. At this time I do not know how frequently it must be refreshed, but I have used cookies for more than 24 hours at a time so a 24 hour rate should be safe. It could be changed (or made configurable) in the future like some of my other drivers that need cookies.
- ActiveControl function: All controller children (2016, Classic, EL, and Jr) are able to set/cancel the feeding cycles. Only tested with my 2016 of course... but seems standard.
- ActiveControl function: ApexJr should be able to set the 4 outlets to on/off/auto. I do NOT have one of these though... so I am assuming it functions like the EBs.
- ActiveControl function: AFS can be set to run a feeding.
- ActiveControl function: FMM can set the 24v port to on/off/auto.
- ActiveControl function: All EBs (4, 8, and 832) are able to set their respective outlets to on/off/auto. Confirmed working with the 8 and 832 (I do not have a 4 but it should be similar).
- ActiveControl function: EB832's 24v ports (A & B) can be set for on/off/auto.
Note(s):
- As I have noted before AND in the enablement for this feature, using the ActiveControl functions acts like manually setting it from your dashboard. If you do not switch it back to auto, it will NOT be automatically controlled by the Apex anymore.
- At this time the outlets and such DO NOT show if they are set for "auto". This is because they are originally designed to be on/off so you knew what their current state was. I plan on adding to this in the near future to show when they are "Auto On" or "Auto Off". But I wanted to get these updates out since I have let them sit for a couple days to make sure there were no errors (I could spot at least).
1 Like
this is awesome! responds incredibly well from the hubitat app. thank you for the command feature!
quick suggestion for future iterations relative to the EBs...what if each outlet was a child device or there was a function for each outlet with switch capability? i'm currently unable to address each outlet from rule machine / webcore due to the enumeration fields.
In Rule Machine this definitely works: You can add multiple parameters to an actuator action. I just created a sample using the first string parameter to set the outlet (1 in my case) and then added an additional parameter string to set it for "OFF". It would be nice if it could ENUM such things just like the driver itself (since it HAS that information from the command) but it does not.
I am not familiar with webcore as I have never used it amazingly enough. I have always been able to do what I need using drivers and Rule Machine basically (with a couple other apps rarely used).
Outlets as child devices from the EBs would be a pain. Grandchildren ARE possible but become pretty messy to deal with. I have tried them out (and used them a bit) with my unpublished Unifi Access driver.
Right on and thank you for the reply. Let me see what I did wrong. Will try again this evening. Interestingly enough, I’m more familiar with WebCoRE and thus why I use it more. LOL
works great with rule machine! thank you for the driver, actions and help configuring!
are you using virtual outputs inside Apex to trigger actions and if so, can we get those added to the driver attributes for actions / triggering in rule machine as well? as a for instance, i have a virtual output that gets triggered by a temp above a threshold, but defers for 5 minutes to ensure it is not a false positive - then it triggers a warning. i'd like to also read that in rule machine and have it turn on the room fan and if it persists, drop the thermostat threshold.
It should be possible. They could be added under the Controller's child. I will add that on my list while I am getting the Trident tests added.
1 Like
Updated Version(s):
- NeptuneSystemsApex.groovy = 0.100.2
- NeptuneSystemsApexChild.groovy = 0.2.7
- NSChild-AFS.groovy = 0.1.2
- NSChild-ApexJr.groovy = 0.1.2
- NSChild-EB4.groovy = 0.1.2
- NSChild-EB8.groovy = 0.1.2
- NSChild-EB832.groovy = 0.1.2
- NSChild-Trident.groovy = 0.1.1
- NSChild-Virtual.groovy = NEW - Link added to main post
Change(s):
- AFS, ApexJr, EBs, and the generic Child driver had minor changes to how they handle the data for outlets. It is no longer on/off but will show On, Off, On - Auto, and Off - Auto to better represent what the controller actually is doing and coming back with.
- Trident should now be able to trigger a test for CA/MG and ALK, or both tests.
- Added a new child driver to support Virtual switches. Turns out (I had forgotten about this when I reset my Apex earlier in the year) that Virtual switches get identified as their own module in the system. When I tried to add support in for them on the controller child it caused a mess. So I gave them their own child. The events can only display up to an 8th virtual switch, but it can control (since you set which one you want to change manually) and display states for as many as you might have.
1 Like
Updated Version(s):
- NeptuneSystemsApex.groovy = 0.100.3
- NSChild-Sicce.groovy = NEW - Link added to main post
Change(s):
- Support for detecting a Sicce pump that is connected to the Apex. It may actually identify other pumps (and create child devices as if they are Sicce pumps) as there appear to be three varieties listed in the "type" that the Apex returns.
- Should create "Unknown" children using the generic driver if an unidentified module is detected. Please send me a status.json (and tell me what the module really is) if that happens so I can identify the module going forward and add support for it.
- Sicce child driver has been added. This driver MAY be able to control the pump level as a switchlevel capability based on the sample data I have seen so far, but I do not have one to test myself. Hopefully someone using it can confirm whether the setLevel command will work or not.
I do not know. I do not remember seeing any samples of the status.json that included a DOS and I do not have one (which is why it is on the questionable side for identifying).
Since I do not have one (I keep looking for a cheap used one) I do not know how it functions and how, or what, it reports back (even outside of the status).
I reached out to BRS about the REST API that Apex controllers have (since Neptune Systems never had replied) and they forwarded it to Neptune Systems... Where it is not getting a reply like normal again. Frustrating.
What can I help get you with the DOS? I haven’t upgraded to your latest code yet because I’m about to go out of town for a few weeks but will likely be upgrading my hub to separate out my ZWave and zigbee and cloud hubs so will upgrade at that time. Not looking forward to the mess this change is going to make. Lol
If you (or anyone else that has a DOS) can shoot me a snippet of the DOS section from the status.json and a screenshot of the DOS summary from the Apex pages.
I have one sample... But the values the DOS section showed did not seem to correlate to what the DOS showed elsewhere. So more samples might help figure that out.
For those that use Chrome and are willing to dig a bit deeper into their Apex, shoot me a PM and I can provide some instructions to try to get some more information out of it.
Updated Version(s):
- NeptuneSystemsApex.groovy = 0.100.4
Change(s):
- Added DOS detection back in. It used to work but had been removed when I went to the new module detection method. Samples provided have made it so I can add it back in although I am still working on trying to get more relevant data for those DOS (not necessarily what it provides in the status.json).
Glad I found this - I currently have 2 tanks today with 2 separate Apex EL's. I am wanting to simplify feedings -currently I have to manually trigger feed cycle on one Apex to shut off my pumps and I can tell alexa to "tell apex fusion to feed the fish" which shuts off the other tank
Is there a way I can automate this using Hubitat? I installed the Child device as well as the AFS but not sure how I could automate both.
Any help would be appreicated
Personally, I created a virtual switch and an Alexa routine to control that switch. When the virtual switch is turned on by Alexa, rule machine turns off the Neptune outputs I programmed. When I finish my activity, I tell Alexa to turn the virtual switch back off and she does so, triggering rule machine to set the outputs back to Auto and Neptune takes over from there. I use this for tank maintenance, but it could be applied to ad-hoc feedings or otherwise. Happy to share more details if desired!
Do you know how to get that to work for 2 apex units though? Trigger a feed mode on both of them at the same time? I can’t connect to both of them without telling Apex fusion to switch to another device
You could create parent devices for each of the Apex controllers. Then they will create all their respective child devices. Since they will be all on the same hub, you could control any/all of them.
