Hi All
And first a huge thanks tol Snell for this great work
I have just installed you drivers to my hubitat C5 and thinks this will give me so many functions that I have looked for in my Unifi setup.
I do have one isue, my 48 port pro switch, is not accepting changes to setPoePortState, and that is one of the big things I like to be able to do.
My UDMP SE is accepting this so thinks I have setup everything as requrered.
No errors in logs or any other info to point me in the right direction so hopfuly someone can help me.
And a second thing that do not matter to much right now is that my accespoint are identified as generic, and they are U6-Enterprise, so perhaps so new that they are not included in code yet
So the easiest answer first, yes, the U6-Enterprise is not recognized by the drivers yet as I have not seen any data yet on them. The most important part is the "Model" name, you should find it located in the "State Variables" list for the device(s) it did create. If you want to shoot me that I can get a specific driver created and then you can switch it's type over once the new one is posted. Then focus on any specific cases for it that I do not get to include.
As for the setPoEPortState... I have a 48 Pro also and it is working... so we will need to investigate a bit further if you are willing. Some questions to begin with:
To confirm the device, can you provide the Model (same as for the above U6-Enterprise)?
What version of Network are you running on your UDMP-SE? Thanks for mentioning that by the way, it would have been another question.
What version of Hubitat are you running? I see you mentioned it is a C5. Not that this really matters if it is anywhere close to current though.
Are you just selecting it from the commands in the device page or attempting to use it through a Rule? The Rule method can be a bit unintuitive due to needing two parameters (to match the two the command needs).
Hi Snell
Thanks for the quick answer I will post here as others can benefit
Model info for devices
Model : US48PRO
Model : U6ENT
and actualy I also has a U6 in wall as well
Model : U6IW
Network version:
Network 7.4.145
Sorry for the hub thing, actualy it is a C-7 and it is running 2.3.5.113
And then the answer about how I have tried !
I have tried both throug device page and via rule. For the UDMP it works both places, but for the switch I see nothing trying from device page but via a rule it gives "Command called: SetPoePortState" in events for switch device.
My programming skills is not great, nbut not affraid of trying, and I think I understand basics anyway, Have managed to tweak other driver code for fetching wetherdata to be used for other api calls and so. Just hit me and I will have a go
The Unifi and Network app versions are well beyond mine so I am worried Ubiquiti might have broken something for that command (like the PowerCyclePoEPort is broken for mine at the moment). But we can try some stuff out.
Please enable Trace logging for the parent device (all commands are routed through the parent).
Run the command from the child device's page.
Run the command from the Rule(s) you made to run it.
Send me a copy of the logging that results as a message because it can get to be a lot. Feel free to "redact" information if you want.
For the devices... I should have an updated parent driver that will now properly set them to the current in-wall driver (UHDIW). Right now that does not allow controlling the PoE state of their port 1 because on my model at least, that is a PoE Passthrough (which CAN be dangerous for non-PoE network devices because it will send the power regardless, Ubiquiti even pops a warning before you enable it). It was not super clear to me from the website whether the U6IW or U6ENT were regular PoE or Passthrough on port 1.
Device recognition for U6IW and U6ENT forms of In Wall Access Points added. They will both be recognized (going forward for new devices) and will use the existing UHDIW child driver. If you already have these devices as Generic or something, you can switch them to the UHDIW driver type and not have to worry about removing/readding them (which would not hurt anything anyways).
Minor changes to some logging in the hopes of solving the PowerCyclePort (for those impacted)... but it still seems to be on Ubiquiti's end. I have received confirmation from other groups that use the API that it is "broken" for them as well. Obviously this does not affect all versions of the Unifi/Network software so if it works for you, GREAT!
When it sends the command to the API it needs to send a whole bunch of ports usually. Not just the port it is changing, but ANYTHING in the port overrides (including other fields for the same port). Otherwise the API says "oh, you only want to change that one thing, everything else should be reset to the default value". Man, that was SUCH a pain when I was trying to figure out why other ports were changing back. Of course my initial testing was only using one port, so it looked fine then...
So... looking at the log snippet you included, I assume port 48 is the one you are setting and you are turning the poe_mode off? If you check the Network app after sending the command from the Hubitat, does that port show as auto or off in the app?
The response you got is usually what happens when the port is already set the way you are requesting. So the port may actually be set. Related to this...
I just got updated to 7.3.83 for my UDMP's Network... and the response data has been changed.
Now, it APPEARS the command is working. The port changes (I even tried port 48) and is showed as changed in the Unifi Network app on my controller (I switched between off and auto a few times). The information is NOT getting to my driver though. It appears that Ubiquiti decided to no longer pass back the poe_mode field in the response, which I used to populate the PoE_Status (you are probably seeing "null" there). In fact, there is NO field in the response data that could tell me if the port was set or not (other than the fact that I did not get an error response).
This is going to cause a lot of trouble... It also looks like the refresh data structure has been altered a bit so things are not getting handled there either.
I will have to do a lot more work to make sure the general data is good, but the response lacking data would require some massive workarounds (like just assuming it worked if it was not an error response). That is something I really am not keen on doing and could impact people that do not have this version (and above it appears).
So it IS missing in some versions of the Network controller. It was missing in mine (I do not have 7.4.x yet). Mine, plus I have been in touch with some other developers that make use of the API and they are also in a similar situation.
But, I am NOT removing the feature by any means. The fact that it is working for some now (with no changes on my part) means if should "come back". I am wondering about the SetPortState problem as well... @Bullfrog, is that still working fine for you also?
Apologies, I didn't mean to imply that you were wrong about it disappearing, though I know why it sounded that way - I should have worded it better. I'm just chiming in that all seems well on my end. The SetPortState is also working for me. I only use it for 1 rule at this point, which is to do a hard-er reboot on my C-8 if I ever need to reset the Z-Wave radio:
This is my rule (screen shot was grabbed while it was running, thus the "Offlines"):
This... This is awesome and annoying news at the same time. Awesome because it is working (and the setportstate also). Annoying because of the variability in the API.
I did not take it as complaining. I responded in general because right now we have two very different experiences going with the same driver... I want to make sure that anyone having a problem can find that there IS a solution coming. Just not from my side unfortunately.
@snell we had some thunderstorms roll through over night and we lost our fiber internet which is a very rare occurrence. I logged into my UDM SE and noticed it had an alert that my internet was down. Curious if your driver can trap this situation and update a state attribute so I can then automate the restart of my fiber ONT and modem. I have this ONT automation already in place but I would need an update from my UDM to invoke this automatically.
Hmm... There is the wan-Health attribute. It should show the current state of your ISP connection. I am not sure what all the possible values are but I know at least there is the normal "ok" state. Other health areas (such as vpn or wlan) have shown "warning" and "unknown" (I saw that when vpn was not enabled).
I would have a very upset family if I unplugged the ONT to test it myself at this time... but I will try tonight or tomorrow when nobody else should be needing internet access.
I see that attribute and I have no event history on it so don't think it changed at all during the outage. The outage started around 1 AM and I didn't restart my ONT until 630 so the polling should have picked it up.
I know what you mean! I am happy to help test too if you need me to debug anything.
@ritchierich How often is your system set to refresh data? The other field to look for would be the www-Health. Your wan-Health might have been "ok" because it was talking to the ONT just fine (which is the next step). Maybe the www-Health would be more useful if the ONT is fine, but the outside connection is down.
The other thing to look at would be the Alarms. If you happen to have the notice that your Unifi raised, maybe I can set up some parsing if Alarms checking is enabled?
