Skip to content
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

Open
iKrushYou opened this issue Apr 23, 2024 · 9 comments
Open

feature request: door controls from the UI #28

iKrushYou opened this issue Apr 23, 2024 · 9 comments

Comments

@iKrushYou
Copy link

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?

@uhppoted
Copy link
Owner

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".

@iKrushYou
Copy link
Author

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 uhppoted-rest) requires the badge number. I was thinking I could create an iOS shortcut (maybe some android equivalent) and they just have to configure it with their card number. All that being said, I wanted to ask if it makes sense logically that I run both uhppoted-httpd and uhppoted-rest concurrently. Or does httpd actually contain the APIs itself that would be callable.

@uhppoted
Copy link
Owner

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 :-).

@iKrushYou
Copy link
Author

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

@uhppoted
Copy link
Owner

uhppoted commented Apr 23, 2024

Enabling card PINs is straightforward - there's a setting in the uhppoted.conf file (which is sadly incorrect in the current Docker files):

; httpd.PIN.enabled = false

If you change that to:

httpd.PIN.enabled = true

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.

@iKrushYou
Copy link
Author

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

@uhppoted
Copy link
Owner

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 NNNNNNN*KKKKK#) but it would depend on the capabilities of the reader.

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 ...

@iKrushYou
Copy link
Author

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.

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

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 ...

thanks, I'll look into that

@iKrushYou iKrushYou reopened this Apr 26, 2024
@uhppoted
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants