curiousjames / diyac Goto Github PK

short or long closure for the contact closure pin

When some sort of API is setup to notify about the doorbell (#4) also give the option to notify that someone entered (be it via a code or a card) and give the option to also announce who entered.

This first debug print line is white, not green, might be something strange with it being the first line printed?

Create a watchdog script to ensure even if the main program fails and leaves the door unlocked, this script will close the door if left open for longer than the settings allow, and attempt to re-run main program.

Changes for next PCB:

• label pins on breakout terminals (reader, 3v3, doorbell 12v)
• mark polarity for DC jack

Work out card formula for 26 bit readers.

Two examples (13.56MHz):
HEX: 9B:AD:35:B1
Wiegand (one way): 7035703
Wiegand (wires reversed): 60073160

HEX: 8B:11:B5:D3
Wiegand (one way): 23733014
Wiegand (wires reversed): 43375849

Desired effect: Pi Active LED turns on for 3s, then off for 3s.

Currently the system will go into lockout mode if three tokens are entered, no matter whether they are allowed tokens or disallowed tokens.

There is a case that only continued dis-allowed tokens attempts should trigger a lockout, I believe this should always be the case so it will be hard-coded that only bad tokens will trigger lockout.

Basically: when exiting the program, close the door

My editor is warning that this variable is defined but not used, is it there for future use or is it an orphan of a previous function/use?

On a fresh install of Raspbian/Raspberry Pi OS the pullups set do not take effect until the pi is rebooted.

There is likely a way to fix this - investigate and resolve if possible :-)

Work out the script path and use that as the root

SystemCTL seems to always send SIGTERM at least twice - handle this in systemHandler

Make it so that you can setup your desired doorbell (12v) ring pattern so 0.6,0.4,0.2,0.5 would ring for 0.6s wait 0.4s, then ring again for 0.2s and wait for 0.5s to then stop the doorbell thread.

lockout for when keypad inputs are being entered too fast (ie. a computer is "typing")

Catch initialization exception of Pi GPIO.

Currently it dumps it's own message on screen, but this should be handled by our program and logged accordingly (then the program shutdown).

This is normally because the PiGPIO daemon is not running - so mention that in the logging.

I've been unable to work out how to catch the error at the initialization time (try does not catch it!) so we MAY have to do it on the next request to pi, but that is not ideal.

like google home or alexa or etc

Logging redacting only catches string values, and string keys, regex capture needs to be changed to resolve this.

an example is 'code' does not catch {"code": 1234}

Settings have a lot in them now, let's put the handling of them into a separate module, which the watchdog can then also use.

Remove the 'u' before even key/value (it's there to indicate it's Unicode - but isn't great for human readability).

Info and DBUG both appear to be white on black in putty after @tame-lx-tech update of logging colourfulness.

Using the example settings file pinDef complains that 'There was an issue setting output pins'

When the doorbell GPIO goes high it's indented by one space, unlike all other logs:
" 2020-06-12T17:35:02 - [DBUG] - GPIO Change - {'gpio': 5, 'name': 'doorbellButton', 'level': 1}"

Only happened once, may be nothing but could be a threading issue that happens sometimes

It recurses infinite times currently, major bug, is possible to log to itself, but needs looking at, and possibly can't log to it self and all points.

System currently broken! Will fix when I come back to PC

Make some kind of indication on the reader/keypad that lockout is in affect.

I think the best way to do this is to blink the LED a couple times after a code has been entered, or a card read. This should happen if the code or card are valid or not.

The problem:
You only have one card reader - the wiegand reader itself. So you don't know the HEX value of the card as read by an NFC Phone, or any other non-wiegand reader.

The desired solution:
A script or function of the main program to resolve the wiegand read token and output the card HEX, so that the card HEX can be put into the allowedTokens file.

Known limitations:
For some card types the HEX is truncated, in these cicumstances we are not able to resolve the full card HEX value, but the code will output a VALID HEX value that can be added into the allowed tokens file.

It could be a security risk to log token values to the log file, or even to the console output.

Definitely remove token values from log file output, consider removing them from console output, potentially with a special flag, consider masking user's names too.

Create a scrip that 'installs' DIYAC onto the Pi - i.e. setups up the perpetual running of reader.py and cron job of watchdog.py.

Assume all folder and file contents are present through git clone.

Some readers/keypads may want HIGH (5v) rather than LOW (0v) to activate the beep/LED.

This should be evaluated at init stage, NOT at an if statement stage when required (i.e. change the value written to the pin at init stage, and do this by variable)

If the settings file has bad JSON or can't be found nothing is written to the log file as it doesn't know where the log file exists, in this instance (lack of knowing where to log) it should assume the log file location is 'logFile' in 'log' folder in order to convey the issue to the user.

It's possible to have PiGPIO handle bouncy GPIs in software, so apply that to all appropriate input switches:

• Doorbell Button
• Door sensor
• Exit Button

Move pullups, glitch filter and gpi callbacks to inputhandling.py init

Black background, but foreground for the full line to be:

• DEBUG - White
• Info - Green
• WARN - Orange
• ERRR - Red

Door opens for only a couple miliseconds, likely bad implementation of threading, (or no threading implemented) will investigate asap.