Stechuhr client is python3 service that runs on a client box on the entrance. If somebody swipes their mifare card onto the reader, stechuhr-client reads the input, verifies it and then sends a request to the server. If the response is 200 OK a LED lights up green, if the card is rejected, the server isn't reached or the server denies the card the LED will light red.
The stechuhr system is a contract tracing solution created at HFBK-Hamburg. The students use their Mifare RFID cards to check in at one station when they enter a area and out once they leave. The checkin/checkouts are transfered to a server and stored in a SQLite database. The stations store no data at all.
One stechuhr should be placed at the entrance, one at the exit to check in and check out.
The software _stechuhr-client_ is a python3 service that runs one those stations at the entrances. If somebody puts their mifare card onto the reader, stechuhr-client reads the input, verifies it and then sends a request to the server. If the server verifies the and logs the card a LED lights up green, if the card is rejected, the server isn't reached or the server denies the card the LED will light red.
One station should be placed at the entrance, one at the exit to check in and check out.
The application is completely multithreaded, that means requests, reading, led blinking etc all run on their own threads and don't block each other.
...
...
@@ -21,6 +23,7 @@ A stechuhr client consists of:
- 1x M301 Mifare Card Reader with USB _mini_ B
- 1x USB mini B to USB A cable
- 1x short RJ-45 patch cable
-**TODO:** Add Speaker/Buzzer to additionally allow for acoustic feedback as demanded by security personal, maybe make this switchable via config/toggle switch to avoid annoying people?
| without raspi + reader |
| ---- |
...
...
@@ -91,16 +94,20 @@ Check the output of the daemon:
journalctl -fu stechuhr
```
## Todo
- [ ] Blink red forever if server cannot be reached
- [ ] Add acoustic feedback
# Configuration
## Configuration
## Debugging
### Debugging
If you don't have a server connected you can test the basic (scanning and LED) functionality of the stechuhr-client by setting `dryrun = true` in the `config.toml`. Make sure to set `loglevel = "Debug"` as well so you can see what is going on later.
Check the output of `journalctl -fu stechuhr` to see the output messages.
## Location, Entrance & Direction
### Location, Entrance & Direction
in `config.toml` there are three keys that identify a stechuhr.:
| key | example values | comment |
...
...
@@ -109,7 +116,7 @@ in `config.toml` there are three keys that identify a stechuhr.:
| `direction` | `in` or `out` | is the location entered or exited? |
| `entrance` | `main door`, `back door`, `ceiling hatch` | purely informational to help logging and debugging |
## ID verification
### ID verification
in `config.toml` you can add a list of regex patterns that stechuhr (*both on server and on client!*) uses to verify the Card IDs. These two patterns for example allow upper/lowercase hex strings with lengths either between 6 and 16 characters OR exactly 24 characters:
...
...
@@ -122,7 +129,7 @@ id_patterns = [
If in doubt consider [testing your regexes here](https://regexplained.com/)
## LED blinking patterns
### LED blinking patterns
LED blinking patterns can be defined with a list of RGB-tuples. If any of the lists (`success_color`, `success_off_time`, `success_on_time`) is shorter than the number of repitions it is just looped over again.
...
...
@@ -133,6 +140,6 @@ success_off_time = "[0.05]"
success_on_time="[0.05]"
```
## Server
### Server
Pretty much self explainatory
\ No newline at end of file
Pretty much self explainatory. This is the adress and port of the server. If the port is 80 http is used, otherwise https is asumed.