I have to develop an electronic lock for laptop with a notification system if anyone tried to open it and a remote access granting option. I am starting from scratch, any ideas welcome.

 

Since it's homework, the idea is for YOU to be the primary mover on things. So describe what your thoughts and evaluations of options are and we can offer critiques and point out things you might (or should) consider.

Aside from that, your problem description is extremely vague. What do you mean by someone trying to open the laptop? Physically lift the cover? Boot it? Access particular files on it? Launch an application? Access hardware with it?

What kind of notification? SMS? E-mail? Is this on a LAN? Wired/wireless?

Since it's locked and you are being notified only that someone had tried to open it, how are you going to get the information you need in order to decide whether or not to grant access? How are you going to convey that information back to them? How are you going to control revoking the access when they are done so that the person next to them can't just hop on and use it?

 

Hi, thank you for the message. The laptop is connected to wireless network. My plan is to bypass the power switch with a RFID or biometric lock. The purpose of the lock is to deny access to strangers as the laptop is kept in a laboratory. The soul purpose is, no one should be able to switch on the device without my knowledge unless they have given access through RFID keys or biometric access. As I am the tool owner, only me and some of my trusted colleagues will be given access. In some cases if I need to give access to someone else, I should be able to give access remotely. So they can operate it and I would get a notification when they switch off the device. The notification system I am planning is through telegram push notifications or email. As I am not from electronics background. My knowledge is limited. I want to take it as a challenge and learn as I advance through the project.

 

Hi, thank you for the message. The laptop is connected to wireless network. My plan is to bypass the power switch with a RFID or biometric lock. The purpose of the lock is to deny access to strangers as the laptop is kept in a laboratory. The soul purpose is, no one should be able to switch on the device without my knowledge unless they have given access through RFID keys or biometric access. As I am the tool owner, only me and some of my trusted colleagues will be given access. In some cases if I need to give access to someone else, I should be able to give access remotely. So they can operate it and I would get a notification when they switch off the device. The notification system I am planning is through telegram push notifications or email. As I am not from electronics background. My knowledge is limited. I want to take it as a challenge and learn as I advance through the project.

Welcome to AAC.

Your problem statement is clear, what isn’t clear is how you plan to approach the problem to solve it. The remit of member-helpers in the Homework Help forum is guidance only. We can help you with your work but you have to show us what that is.

If you are genuinely clueless about any design direction, this would be a case for your faculty to guide you. If you have some ideas, you can lay them out and we can direct you in a fruitful vector. What we can‘t do is act as consulting engineers designing to a specification. But then you aren’t even as the specification stage yet.

You have fallen into the trap of putting implementation details in the category of constraints. You don’t have a high level design, or a budget, or enough knowledge to make assumptions—but you are already creating inflexible pivot points in the project.

Why have to already decided you are going to “bypass the power switch”?
How will you decide if the system will use biometric or token (RFID) based access? Why?
Why have you already decided on Telegram?

You need to stop, step back, and craft a much higher level version of your vision. This can in the form of user stories, which can be a very powerful tool to spot mistakes in assumptions and eliminate “features” that aren’t needed. It works like this:

For each task you expect a user to do with the system, write a narrative of what it would be like to be that user. What would they do. Avoid implementation details, for example rather then:

The user would press a red button to cancel the operation,

use;

The user would signal to the system the desire to cancel the operation.

This is a random example but in the first: “red”, ”button”, and “cancel the operation” are implementation details. They lock you into things that might not be necessary or possible, and as they propagate through your design they drag baggage with them. Eventually they may well represent things that require kludgy workarounds because they were naïve requirements.

In the second: the user is doing the fundamental thing, signaling the system and the signal doesn’t cancel anything, it signals the desire to cancel something. That thing might require interaction to cancel, it may represent a hazard if the cancellation is allowed, or something else. The signal of desire is what is happening, what else will happen is going to be specified as you iterate through design layers and versions.

Once you have a set of these things, you will have set of questions that can be answered in the context with a much greater scope than… guessing. For example:

How does the user signal the system?

Could have a variety of answers once you know when the signals will be sent and what they will do. In the cancel of our “cancel” operation, an e-stop (emergency stop) is much different from a simple “cancel print” signal.

While this sort of rigor might seem more than needed for your project, the unfortunate truth is that small projects have all the same fundamental requirements of large ones—without the luxury of economy of scale. This is exacerbated by your naïveté a concerning electronics.

You are going to have to make choices about implementation details without the benefit of experience that would help the expert make choices based on experience even if not guided by the (proper) process.

In any case, you can get a lot of good help here, but for that to happen you have to start the process and offer a proposal for a solution and its parts. Then, interfacing them, troubleshooting them, or even replacing what turn out to be bad initial decisions.

None of this is mean to discourage you. In fact, I am hoping to prevent you from discouraging yourself by starting out in a way that sets you up to fail, or very likely, produce a marginally operational, poorly documented system that almost does what you want.

Good luck no matter how you go about it. I look forward to seeing your progress.