It looks like it is not recognizing the Jr as a controller... and looking at the code, I do not have a way to identify the Jr as an individual module. I should be able to pick it out though because it has the outlets, unlike all other controllers.
Could you shoot me a copy of your status.json, or a portion of it where it says it was stuff from the base unit? I should be able to update the code pretty readily...
Sorry about that. Did not realize I did not have recognition of the Jr in there.
Sorry for the delay on getting the over to you, but here is my entire status.json. Hope this helps.
{"istat":{"hostname":"apex","software":"4.53J_4D19","hardware":"1.0","serial":"AC4J:13571","extra":{},"timezone":"-4.00","date":1654691190,
"feed":{"name":0,"active":0}
,
"power":{"failed":1654690897,"restored":1654690945}
,
"inputs":[{"did":"base_Temp","type":"Temp","name":"Tmp","value":74.0 }
],
"outputs":[{"status":["AON","","OK",""],"name":"OaseFilter","gid":"","type":"outlet","ID":0,"did":"base_Out1"}
,{"status":["AOF","","OK",""],"name":"OaseHeater","gid":"","type":"outlet","ID":1,"did":"base_Out2"}
,{"status":["AOF","","OK",""],"name":"CO2Sonenoid","gid":"","type":"outlet","ID":2,"did":"base_Out3"}
,{"status":["OFF","","OK",""],"name":"Unused","gid":"","type":"outlet","ID":3,"did":"base_Out4"}
,{"status":["AOF","","OK",""],"name":"SndAlm_I6","gid":"","type":"alert","ID":4,"did":"base_Alarm"}
,{"status":["AOF","","OK",""],"name":"SndWrn_I7","gid":"","type":"alert","ID":5,"did":"base_Warn"}
,{"status":["AOF","","OK",""],"name":"EmailAlm_I5","gid":"","type":"alert","ID":6,"did":"base_email"}
,{"status":["TBL","","OK","1000","-620"],"name":"Macros","gid":"doser_2","type":"dos","ID":7,"did":"2_1"}
,{"status":["TBL","","OK","1000","-586"],"name":"Micro","gid":"doser_2","type":"dos","ID":8,"did":"2_2"}
],"link":{"linkState":3,"linkKey":"G9qXY7","link":false}}}
Awesome! Should be easy enough to identify it as it could be spotted by the serial# (the AC4J portion) or the base outlets.
I will get to work on this tonight and it should be quick.
Thanks!
Updated Version(s):
Change(s):
Note(s):
Can you tell me what / who was using this feature? I know I renamed my child devices to better match what they actually are. I guess I’m trying to understand what if anything we will be losing?
That was the thing... As I understand it most people were no longer using custom names if they used child devices because they just referenced the sensor from the child devices. When everything was on the parent, it was easy to have duplicates of temperature, pH, or other stuff... but with the child devices that does not seem to happen. The overall SYSTEM may have 2 temperatures, but one is on the Apex Controller child, and one is on a PM child, etc...
For example: You would still have access to both temperatures (as you do now) if you use them on the children. The children are where all the data would end up in the new driver except for some few "overall" values that the parent device would still retain.
If there is really a good use for the custom naming at that point... I supposed I could build it in. I was just looking at cleaning out some of the messier parts of the code and things I did not see much use of. Oddly, I used to use it myself because I have two temperature, two pH... until child devices became a thing.
With the size of my apex setup and the amount of modules I have connected, not being able to rename them would make it more messy for me and harder to understand as I would need to continuously need to refer back to my apex setup to determine which module I was looking at. Here’s my current setup.
As you can see I have multiple modules of the same running on different tanks in different areas of my house. It makes for easier identification when looking at devices. I vote to keep it if possible 
Thanks for your consideration.
Wait... are you talking about renaming child devices or using the custom name to see multiple attributes?
Custom naming of devices will NOT go away at all. If you rename them like you show in your pictures, that is completely unaffected AFTER the children are initially generated. In fact, I plan on having the child device's label generated with the name they have on the system.
For example: I have an EB8 that is named Picos on my Apex. The drivers presently do not KNOW it is Picos (it is not exposed in the status for modules). The new driver WILL be able to see it. So the module will get a label of Picos. You could (of course) change that after the fact.
The part I was thinking of going away from is "custom" attributes. Using your system example, you have multiple PM1 modules. Each has a temperature. Right now, the Parent device could show that in two ways (that you can control):
My plan is/was to get rid of this from the parent entirely. The parent device would not show any of these. Instead, you would just select the temperature children: from PM1 (Frag Tank) or the temperature from PM1 (Mixing Station)... That is possible now and would not change. I do not think the parent device is a good "dumping ground" to duplicate the data when all that data is better represented on the children.
Plans change and I do not want to make the driver LESS functional for users. So if the parent keeps some custom stuff in. Maybe that will happen. But that is why I mentioned it (to get feedback). Plus, no matter what, I will NOT just replace the existing driver as if this was a version update. So people could run both until they are sure of the new one as well as be able to provide feedback while comparing the two.
Sorry, got a little long-winded here.
The only thing I have set now in the parent is this:
The names of my temp and other ph probes are coming from the names that I have them in the apex yes?
The names it gets from the Apex would not change, those would still be reported in the child devices.
The ones from the image are the ones I was thinking of removing. Since the parent would not have the data posted to it anymore. BUT... if there is the demand for the parent to have that (and not check the respective child devices for it)... maybe I can make alterations to still have them.
Gotcha…. I’d vote to not lose that functionality unless it’ll pull the names from the base itself.
It will pull the names but the attributes themselves cannot be those names. Hubitat does not allow dynamically generated attributes. That is why the existing custom ones have the... less than optimal... naming. I wish I could just take all the data and pass events with the user-set names from the Apex, but I cannot. I CAN do it for state variables (and do) but it cannot be done for attributes and thus events. If you try to pass an event to something that does not have named attribute in the driver, you cannot use it.
So it sounds like I have a vote for keeping some of the custom stuff. Well, this is why I mentioned it. If there had been no pushback I would not bother.
Updated Version(s):
Change(s):
If you could send me a status.json I can look into it for the WAV, it might be doable although it would likely just focus on the 1-Link module (because of it being a kit). I thought you sent me one in the past but could not find it in messages (a few people have sent them recently so I might be confused).
As for the ATK... It is not going to be detected as an ATK. The ATK uses the FMM module (which is detected) and some sensors and pump... It is also just a kit. So your system should have the FMM identified. How do I know this (and think the WAV will be similar)? I bought an ATK myself years back for my big system. The FMM could be detected and (now) you can control the 24v port on it with the new Active Control.
Just you the json for the wav. I don’t have 1link module wav is plugged directly into eb832 1link ports
Updated Version(s):
Change(s):
Updated Version(s):
Change(s):*
Went to leverage automation to turn on a virtual device and recieved this error: "Office Reef Controller - OutletMode Unauthorized, probably cookie failure. Use GetCookie command then try again." Unfortunately, I can't seem to find the GetCookie command in the parent or child drivers, so I assume it is a back-end function? Any way I can trigger the getcookie command or can you suggest a method to fix this error?
I just realized I did not publicly answer this, but just so people do not think this was ignored, I have been working with @g8rzfn via private messages.
On a totally different topic, Neptune Systems has announced the new A3 series of Apex controllers (A3 Apex, A3 Apex Pro, and A3 Apex Jr). If/when anyone gets them I would love to see the results from a status.json in order to make sure I start supporting them as soon as possible.
Further topic... any requests from anyone or feature enhancements? I know I am probably "asking for it" here... but it has been a while since I have performed any major changes to this and I am wondering if there are features people are lacking. It has been quiet (which can be a good thing) but I just wanted to make sure that is because it is doing what people need/want.
I’m good for now… looking forward to new devices to integrate.
Download the Hubitat app
