Jodies phone isnt here. Its mine… kris. I used paperui to configure the thing. Which is online always…
Bindings should be stateless, therefore you really can’t / shouldn’t perform any type of “logic” in them. This keeps in the spirit of a binding just acting as a bridge between the Home Automation Bus and some vendor specific device.
There are exceptions, but this voucher system wouldn’t be one of them. I do think with the proper info (like # of guests connected, tagging a network as guest, etc…), one could implement this via rules.
Let’s put it on the whiteboard of pending feature requests for now 
1 Like
I think this is coming down to an invalid / improper considerHome config parameter. Can you delete and re-create your phone thing via the PaperUI.
Sure Matthew, ill report back!
Support for wired devices?
This has been mentioned many times in this thread…
Can you elaborate on exactly what you’re interested in from a wired device? Specifically wired clients.
There are definitely use cases for integrating UniFi hardware (mainly switches), but for wired clients, I can’t really think of any more than ONLINE vs OFFLINE (which can already be accomplished via pings).
It was manily ON/OFF. I wasn´t aware that this is possible via ping. I guess I have to read up on that.
1 Like
One of the things I currently appreciate is the ability to restrict the UBNT OH user to read only for this blinding. This requires a clear text password which is slightly distasteful but mitigated by the fact I can force it readonly and restricted to just the ability to read active devices.
Adding “write” features like POE and guest tokens and still maintaining a clear text password is broadening your attack surface of you network.
Just my tuppence.
I completely agree and never thought about these WRITE features from a security point of view.
I assume your concerned with storing the password in clear text in the OH configs?
Now you got me thinking how could this be done securely.
I’ve been digging around since writing that post. I messed something up - there is no granular control over what the user can and cannot do. Not sure where I saw that. So, a user is read-only, admin or super-admin.
I tested a while ago, a read-only user cannot see any passwords so that gave me some comfort and I used your binding (which is brilliant BTW! Don’t let this be seen as a negative)
How can you do it securely? I don’t know (willing to help look into it though) but putting a post up on the very active ubnt forum might get some response. I also use the android app and that just uses a fingerprint to open. Not sure if it does a login each time or a token.
The guys and girls over there are quite helpful and I am sure there will be a way it can be done. 
This is unfortunate and I’m afraid you would have to use an admin user to be able to toggle PoE on ports. Not sure about the hotspot vouchers (it’s been a while since I played with that part of the controller).
I might ask but I’m afraid the API isn’t officially supported so I think it’s a long shot.
I did grab the hashed password from the mongodb instance on the controller and tried submitting that in the UniFi form, but no dice 
While it would be nice to be able to securely store the credentials in OH, I believe this is will come down to a personal choice of whether or not you want to sacrifice security for convenience (funny how it always comes down to that).
My personal use case for PoE is to be able to toggle my ceiling mounted echo dots on / off as well as the security cameras overlooking the backyard (if we’re having a party and there’s a group of people in the backyard). My cameras are for security (when no one is there), not for surveillance
1 Like
Glad it’s working for you now!
Personally, I don’t worry so much about the security aspect of allowing the binding to write config parameters to the Unifi Controller (or the hashing of the admin password).
If the attacker will be able to gain access to my OH2 system (linux hosting the Unifi Controller software locally), I will have bigger problems with other stuff than the Unifi environment. Gaining control of OH2 is not easy if you have properly secured the access to it.
This PoE support would be an exception (that can be very useful in a lot of automation use cases) and I don’t think that you should “replicate” lots of the functionality that already exists in the Unifi software.
I agree 100%. And for the convenience of having automated PoE toggling, I’m willing to accept the risks.
Are you referring to the idea of hotspot vouchers? I do think it would be neat to have a “next” voucher code displayed in OH and to auto generate the next one anytime a new client join’s the guest network, but this might be out of the scope of the binding and I can think of a few potential issues with false positives.
Now with all that said, this could easily be scripted using $your_language_of_choice and OH’s built-in API. I’d have to setup the hotspot guest portal again and poke at it. IIRC, it keeps a list of unused / valid codes, so maybe you can just do a bulk pre-generation and the binding can fetch the “next” valid code every time someone joins / leaves the guest network. Just thinking out loud again…
Hi Guys…
Hope I haven’t started some controversy here 
Here’s a few links that got me thinking… and it was only an idea;
Now, my theory was. I don’t want to give everyone access to the Unifi Hotspot manager, nor does everyone even want another app on their phones, but letting a guest on the guest wifi doesn’t need me to authorise. Everyone in the house does however have the openHAB app, and I have a main touchscreen in the hall. Messing around with a printer and bits of paper is a bit old school, so why not make use of openHAB. If you can use a Pi to make it print then I’m sure one way or another you can make openHAB do the same. Maybe this is a separate topic / feature that belongs in another discussion if this binding isn’t needed…
Cheers.
Of course not… this is an interesting idea that even I may use in my house 
Like I said, I’ll have to setup the guest network hotspot portal again and play around with the vouchers to have better input on how we could go about doing this…
A lot of things can be integrated into OH using your preferred scripting language and OH’s REST API, so it doesn’t necessarily need to be a part of the binding, it’s just cleaner and more streamlined that way.
With OpenHAB 2.4 Milestone 4 the refresh service doesn’t seem to run long. It updates for a little bit and then just dies off and remembers whatever the previous phone state was. Any ideas on what I could do to fix it
I am on OpenHAB 2.4 snapshot, and Unifi binding 2.3.0.20180422.
The binding won’t connect to my Unifi server, due to the error:
javax.net.ssl.SSLException: Received fatal alert: handshake failure
I have not done anything with certificates (that is, I haven’t set it up properly)
Going to the unifi server in chrome, I have to go through some warnings, but I find that okay, and the Unifi binding has previously ignored it, with OpenHAB 2.3 and unifi binding 2.2.0).
Has the binding been updated so that it won’t work with Unifi servers where certificates are not in order?
(there are so much things to fix with my smarthome, and spending time getting certificates correctly configured for the Unifi server for my internal-only LAN is not high on the list). I would appreciate an option to ignore SSL errors for the Unifi binding.
I don’t think so. I’m running the latest 2.4 snapshot (build 1400) and Unifi binding 2.3.0.201804221805 without issue. I’m not sure what’s causing the error you’re seeing.
What version of the Unifi controller are you running? I’m on 5.9.29, but recently was on the 5.8 series.