Glad it was something pretty quick. It is easy to have little stuff like that so no worries. Glad @kanewolf gave you an answer so quick.
1 Like
I’m sorry to sound like a fool here but I need some more guidance, please. I’ve added the UDMPSE child device but cannot seem to get the states to populate. Any guidance would be tremendously appreciated!
Thank you @snell for the very useful driver! I'm wondering if any other users have problem with the command SetPoePortState for a USW-lite-8POE switch (docker Unifi controller 7.5.176) . Log shows this error : java.lang.IllegalArgumentException: params cannot be null on line 1243 (method SetPortState)
Strange because the PowerCyclePoePort works fine through the device page.
If i create a Rule in Rule Machine (as described further up), i also get the same error.
Thanks for the help.
Looking into it. It is most likely a typo I introduced at some point since it sounds like it is looking for parameters it is not getting passed...
Edit:
Few questions as nothing immediately stood out yet.
- Are you using the latest API driver (0.4.62)? When I am looking at the driver code 1243 comes up as a commented out line... so it could not be causing it.
- Is the child device using the latest USW8LPoE driver (0.1.9)?
- What port & state are you attempting to set?
@jvwilson101:
Sorry I did not see your post before now... did they eventually update? You should never add a child device manually (they will never get data). All child devices will be created automatically by the parent device when it receives information for them. From the second log image it looks like there are multiple things that are in here that have Unifi designations.
The only virtual device you ever need to create is the one for the parent.
thanks for taking the time to help!
- Are you using the latest API driver (0.4.62)? When I am looking at the driver code 1243 comes up as a commented out line... so it could not be causing it.
- Is the child device using the latest USW8LPoE driver (0.1.9)?
Latest version for both ( API : 0.4.62 / usw8lpoe : "0.1.9"
- What port & state are you attempting to set?
Tried all ports 1 to 4
I tried looking a the error line with my very limited understanding, but it seems to be a logging command line from your comment :
1242 //Logging( "Temp Overrides are: ${ TempOverrides }", 3 )
1243 asynchttpPut( "ReceiveData", GenerateNetworkSettingParams( "${ Attempt }", "${ ChildID }", "${ MAC }", "{"port_overrides":[${ TempOverrides }]}" ), [ Method: "SetPortState", DNI: "${ DNI }", ChildID: "${ ChildID }", Value: "${ Port } = ${ State }" ] )
*installed API driver via import url and also copy paste (C-5 Hub 2.3.8.139)
Ok, the versions are all good. I am comparing with my 16 Port Lite and making sure it appears totally matched up to the 8 port. I have not hit that specific issue yet unfortunately but I DID find a change Ubiquiti made in what data needs to come back to re-enable PoE... so I have to make changes no matter what. Hopefully in there I will find whatever difference there is between the two and get that cleaned up.
Updated Version(s):
- UnifiNetworkAPI.groovy = 0.4.63
Change(s):
- Change to SetPortState function (affects PoE port changes as well) to handle new data that is now required (at least when setting a port to auto). Tested on both my 48 Port and 16 Port Lite, no errors turning PoE off or back to Auto on either for multiple ports.
- "Promoted" port status data to be an Event. This means that the port status map will now be available to things such as Rules for checking status of what is connected to a port or how it is connecting. Please note that this data is still only being populated when the API is queried and returns data... so it does not automatically show any changes beyond that. For example, if you change port info in the Ubiquiti app or disconnect a device... the port map data would not show any change until the next time the child device was updated with data from the API.
@snell
Hi, I wanted to ask if it does already and if not could you add support for the Unifi Cloud Gateway Ultra? I used to have the USG3 but I am trying to set this up and I am not sure what ports I should use to connect to the Cloud Gateway Ultra.
Thank you
It does not have recognition for the Ultra yet if I recall (and a quick check of the driver code). I could add support shortly after being sent the State Variable "Model" information that would be shown on the child device's page.
Looking at the tech specs it reads as very similar to the UXG-Max which I have support for, so it would likely be able to use a similar mapping of ports and not require a whole new child driver (thankfully).
Running latest Hubitat platform version and driver from: https://www.drdsnell.com/projects/hubitat/drivers/UnifiNetworkAPI.groovy
Hi @snell
I am not even sure how to start getting it connected, I have added a virtual device and used the UnifinetworkAPI driver and filled in the fields, but I am not 100% sure what port it uses, I have tried 8443, 443, 8080, 80. It keeps saying no cookie, please login again???
@Busthead:
It looks like the first thing that happened was it choked on the data that got returned from something. Do you know what was scheduled that might have happened at ~2pm? Some of the rest appears to be the infamous Request Timeout for presence checks... but you also appear to have a lot where it did not list what it was checking, almost like it got a null in there.
@greglsh:
Try setting the type of controller as "Unifi Dream Machine (inc Pro)". All of the newer controllers are actually using this style.
1 Like
@Greglsh , just in case : only enter IP and not http: //ip.
@snell Updated to version 0.4.63 : still doesn't work and same error, so i commented out the error line (i think it's related to logging). Commenting out that error line only results in no error msg in Hubitat Log...obviously! 
Scheduled?
This is the list of MAC addrs to Presence Check:
f6:98:05:7F:90:33;76:7a:67:c8:84:48;90:e1:7b:18:c7:ff;;d6:df:a6:0f:53:ee;6c:72:e7:9b:f3:c6
Your MAC Address list has a "gap" in it (double ;; after the 3rd one) causing the null:
f6:98:05:7F:90:33;76:7a:67:c8:84:48;90:e1:7b:18:c7:ff;;d6:df:a6:0f:53:ee;6c:72:e7:9b:f3:c6
Should be:
f6:98:05:7F:90:33;76:7a:67:c8:84:48;90:e1:7b:18:c7:ff;d6:df:a6:0f:53:ee;6c:72:e7:9b:f3:c6
I guess I should build a check in to reject checking for ones without a full MAC address... thought I already had that but maybe I forgot to ignore a null entry.
As for the scheduled part, at the bottom of the parent device page there is a field with "Scheduled Tasks" that say when things should happen and when they last happened. Curious if there is anything (besides PresenceCheck) that might have happened so I can see what overloaded the ReceiveData.
You do not have THAT many Unifi devices and such do you?
This worked and I have it connected. Thank you the tip to use Unifi Dream Machine worked.
@Busthead:
The timing is close enough that your Unifi API could have been "busy" while processing and providing all the stuff for the DailyCheck to get those Request Timeouts. Not much can be done about that but it is STILL something I am trying ideas with.
The number of devices is not bad (I have 17 Ubiquiti devices) so I am not sure what might have pushed the limit on the returned data. Does that error happen every day (so it is being caused daily with the DailyCheck data dump) or was it just that time?
@snell you might try adding the singleThreaded:true option within your driver definition at the top. This feature was added in the 2.2.9 release. I have found this useful in many apps and drivers that I have created and maintain for the community. This will ensure that your multiple scheduled jobs run in order and don’t step on one another.
