code includes? yeah, sure, but -which- ones, why?

I'm building an electronic deadbolt door lock. this will be a "fail secure" or type setup, using one-way 'pull' solenoid, return-to-latched spring, & obscure mechanical override. I'll be using the following components:

= arduino uno R3
= TTP229 capacitive keypad module (i2C device). known i2C address & known working. this will be used in 16-key mode, hopefully on same i2C bus as 'next device down' ...

= 20x4 LCD (has an i2C backpack). known i2C address & known working.

= solid state relay (will use just one, but have 5, of which 4 are rated 10 amp and one rated 25 amp/continuous duty. (not included here is my 'probable fake' fotek). to switch the 120 VAC to 'next item down'...

= 120 VAC laminated solenoid, dormeyer, unknown model number, unknown amp draw, closeup pic shows # of the solenoid COIL, not a typical dormeyer solenoid number.

I have 'minimal or less' coding background, but for days I've read numerous articles on and "looked closely at the code" for all the lock projects I could find. I tried finding a site, or 'outline', or 'overview' of -which- specific code 'includes' MY project 'should' include, or not include. i've found that 'most' door lock project codes include these includes:
= keypad.h
= liquidcrystal.h, OR newliquidcrystal.h, both of which I've managed to convince myself should be replaced, in my situation, with
= hd44780.h

but other lock projects sometimes use these includes:
eeprom.h
wire.h
atomic.h
password.h
softwareserial.h

problem is I can't find ANY info ANYWHERE as to -which- particular include (or includes, plural) a guys project "might best benefit from using and why" or, really, any 'real world type' descriptive overview of what any particular include 'will or won't do for your project' or of 'if you use include A be sure to also use its prerequisite, include B' or 'don't ever use -this- include if your project contains item C', or 'this incude is primarily used for purpose XXX, when situation YYY happens', or any similarly-worded descriptive info-bits that pertain to using one include vs another vs neither of the two, or possibly using something else entirely' type info ... anywhere ...

clarity is always nice, AND I have no =clue= what I'm doing, so, code-includes-wise, confusion reigns here ... :-/

thanks for any light you guys shed :slight_smile:

What I usually do in a situation like this, is Google the sensor IC,
"arduino TTP229 library"

I think you are looking at this from the wrong end, you seem to be asking which files to include for a lock project, which is the wrong question. You need to ask which files to include to provide some particular functionality.

eeprom.h: are you going to use an EEPROM? No? Then you don't need this.
wire.h: wire is for I2C, are you using I2C?
atomic.h: no idea what this does, what does the documentation say it does?
password.h: do you need passwords?
softwareserial.h: do you need more serial ports than the hardware provides?

If in doubt comment them out 1 at a time, if that doesn't produce an error when you compile then you don't need it.

Honestly, the best place to start a project like this is code structure. How to do all the things you want to do and reading robin's tutorial on doing several things at once really could help you.
I wouldn't get all the includes up front. progress through each component of your system, make the relays work with a button before adding the capacitive touch etc.
Try to work from spec sheets and original source documentation before going to libraries and tertiary documentation.
Pull in a library if you think it's going to do something you couldn't do a more easy way yourself. I will use the EEPROM library since it was mentioned... It was written as stated in the source comments, "This object references an EEPROM cell. Its purpose is to mimic a typical byte of RAM, however its storage is the EEPROM. This class has an overhead of two bytes, similar to storing a pointer to an EEPROM cell."
On my first EEPROM project, I didn't fathom that there might be an easier way to store a value in EEPROM and read it back into RAM, and I tried hard to work with this library because it was the first one I knew about. It ended up not working for what I wanted to do and I eventually stumbled upon the avr-libc library and found I could do what I wanted working with that library easier.

Perehama,
How about Editing that response and putting in some paragraph breaks? That is a lot of thoughts in one paragraph.

i_m_wrong:
problem is I can't find ANY info ANYWHERE as to -which- particular include (or includes, plural) a guys project "might best benefit from using and why" or, really, any 'real world type' descriptive overview of what any particular include 'will or won't do for your project'

As already mentioned, that is starting at the wrong end.

The first thing to do, which really does not require any programming knowledge, is to describe in as much detail as possible how you want the project to work. For example

  • it will have a keypad and a 2 line display screen
  • the user will start activity by pressing button X (I don't know what buttons will be on the keypad)
  • the display will the show "Enter the access code"
  • the user will press the keys for the access code followed by the Y key
  • if the access code is correct ---
  • if the access code is incorrect ---
  • etc
  • etc

This may seem very tedious but, be assured, you will need to make all these decisions before the program is complete and it will be much easier to create the program if you start with a detailed description.

These links may help
Several Things at a Time
Planning and Implementing a Program

...R

Perehama:
... Try to work from spec sheets and original source documentation before going to libraries and tertiary documentation.
Pull in a library if you think it's going to do something you couldn't do a more easy way yourself.
...

Honestly, I think this advice is not good for a complete beginner. We see here time and time again, problems with a simple interface like a pushbutton switch or LED. Now you want them to plow through the data sheet of a capacitive sensor IC, understand the operation and the interface, and then implement driver code. It's not impossible, but it's not a good learning approach. Even in "the old days" the first steps were mediated by some hobby book authors, perhaps magazine articles and builds etc. They refer to, but do not depend on the data sheets and original documentation, which the wise teacher will point out and the wise student will seek out. But that is lesson 2.

Secondly, many people expect Arduino to just perform some function, right now. They might become interested in exactly how everything works, but that may or may not come later.

aarg:
Honestly, I think this advice is not good for a complete beginner. We see here time and time again, problems with a simple interface like a pushbutton switch or LED. Now you want them to plow through the data sheet of a capacitive sensor IC, understand the operation and the interface, and then implement driver code. It's not impossible, but it's not a good learning approach. Even in "the old days" the first steps were mediated by some hobby book authors, perhaps magazine articles and builds etc. They refer to, but do not depend on the data sheets and original documentation, which the wise teacher will point out and the wise student will seek out. But that is lesson 2.

I can agree with this as long as it's a well thought out textbook and not random creepy pasta code from the internet, rife with pitfalls and no documentation on the code. "grab this library" delay(); int x>>y; etc. That just leads people back to the forum going "how do I get this code to work with that code?"