-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: door controls from the UI #28
Comments
Hi, Can you perhaps provide a concrete use case? I thought about it but couldn't imagine why anybody at all would want to leave a server running just so that they could occasionally login to uhppoted-httpd to open a door - it seemed a whole lot simpler to just e.g. walk downstairs and say "Hi". |
I manage a building where I have this controller installed. Currently I use the stock web interface (which isn't great) to remotely let people in such as an exterminator. The point of having the server running would definitely be to have a user interface for the tenants to manage access themselves - adding / removing cards as needed - but it would be nice to have a button in the admin panel to "buzz" open the door for someone remotely. additionally, I am starting to think about how I could expose this to the tenants themselves. I like that the API for opening a door (from |
Ok, that makes sense - although I'm going to have to think about it a bit because uhppoted-httpd was mostly intended to be an administrative tool to manage access lists. The open-door functionality did exist briefly at one stage in a development version but was ripped out because of the enormously increased the security risk unless it was configured exactly correctly. Plus web browsers are just such a big attack surface. One or two other people with a similar requirement have gone with QR codes - the visitor gets a temporary access card in the form of a QR code sent to his/her/their phone. But yeah, that does need an additional reader and QR codes have their own security problems. re. tenant access. The uhppoted-rest gateway was originally intended for exactly this scenario, and at least one person is using uhppoted-mqtt to do something similar (a QR code or an URL that sends an MQTT message). It does make sense to run both concurrently because they are functionally separate - one serves an API and the other provides a user interface (httpd doesn't expose an API as such). Although if both are being used to manage cards you're obviously going to end up with some conflicts (which is why there is a Synchronize ACL under the admin menu). FWIW, the uhppoted-tunnel HTTP connector provides a very basic (and unsecured) web API which is a lightweight alternative to uhppoted-rest. Not sure I would recommend this in a tenant-facing system but it's there if you want to play :-). |
thanks, I appreciate the insight interesting you mention the security risk of having the door unlock in the portal because I could just as easily go into the settings and adjust the door mode to "normally open" and that would just open the door indefinitely in the case of the exterminator example: I don't find out they're there until they get there and call me so it might be hard to go down the QR code route. Additionally, I'm not sure what kind of reader I would even use for that. We just have the RFID / keypad readers - speaking of which.. I was only ever able to figure out how to use the door pin for that keypad but it would be cool if it could be linked to card. Alright that sounds good. I would only expect to use the rest API for unlocking the door in this context so I don't think it should clash with the ACLs of the httpd service if we only use that for management |
Enabling card PINs is straightforward - there's a setting in the uhppoted.conf file (which is sadly incorrect in the current Docker files):
If you change that to:
and restart there should be a PIN field for every card. Oh - and you do have to enable keypads (using either the OEM interface or the CLI activate-keypads command). I'll give the open-door functionality some more thought - but if you're ok with using the REST API that actually is probably the way to go. |
Thanks. Does this pin need to be entered WITH the key card scan? Or is it an alternative to the key card? Ideally I would be looking for a way for tenants who have forgotten their card to still be able to enter the house. this is the scanner I have. I think I am okay with going down the api route so there might be no rush on adding that. However, a related feature that I'd thought about previously is setting up a period where the door is NO and unlocked. For example: a party where you want the door to stay open but only until say 8pm |
Yup, the controller expects the key code immediately after the card swipe (or at least within a reasonable time). You may be able to program your reader to allow card numbers to be entered on the keypad (e.g. something like Your reader has a 4 digit PIN option - no idea what that does but presumably it has an relay output to unlock a door which you may be able to use. re. party. That's quite possible using e.g. add-task - it's not currently supported by the UI but almost everything else does i.e. CLI, REST, mqtt ... |
we were able to set up a 4 digit pin in the web config at the top level. but this isnt' associated with any cards it's basically just an admin code per door. not exactly the desired behavior as you can't track / limit it
thanks, I'll look into that |
The codes you're using are the supervisor door override codes and they really aren't intended to be handed out to all and sundry. The passcodes field on the Doors tab/page allows you to enter them if you want to manage them via uhppoted-httpd. |
I'd like to be able to open doors from inside the web interface like is possible with the OEM web interface.
Would it be possible to add this feature in?
The text was updated successfully, but these errors were encountered: