233 lines
7.8 KiB
Markdown
233 lines
7.8 KiB
Markdown
The dachtür is a device to restrict access to the dachboden.
|
|
|
|
project
|
|
=======
|
|
|
|
summary
|
|
-------
|
|
|
|
Previously a button allowed to open the building's entrance door and granted access to the dachboden.
|
|
Since the dachboden got popular, it is now flooded.
|
|
The idea behind the dachtür it to disable this button and replace it with a secret sequence of button presses during certain periods (e.g. when parties are taking place in the dachboden).
|
|
It must be installed in the door panel, as described under `connections`.
|
|
|
|
configure
|
|
---------
|
|
|
|
To program the days, times, and button sequence, connect to the dachtür.
|
|
It should appear as "dachtuer" Bluetooth (classic) device.
|
|
A PIN is required to connect to it.
|
|
Once connected, you can use a terminal (such as the "Bluetooth terminal" android application).
|
|
Interact with it by entering commands.
|
|
- from time to time, update the date (it does not take into account summer and winter time):
|
|
~~~
|
|
date YYYY-MM-DD HH:MM
|
|
~~~
|
|
- enter the days on which the access should be restricted (starting with Monday, here only Thursday is active):
|
|
~~~
|
|
days 0001000
|
|
~~~
|
|
- enter at which time the restriction should start:
|
|
~~~
|
|
start 20:00
|
|
~~~
|
|
- enter at which time the restriction should stop:
|
|
~~~
|
|
stop 06:00
|
|
~~~
|
|
- enter the secret button sequence to open the door (here press button 1 then 2):
|
|
~~~
|
|
password 12
|
|
~~~
|
|
|
|
WARNING: If the internal backup battery gets empty and the device looses power, the configuration and date get lost (since there are stored in SRAM).
|
|
In this case, replace the battery and reconfigure the device.
|
|
|
|
connections
|
|
===========
|
|
|
|
On one side there are three XH-2.54 connectors.
|
|
|
|
2-pin connector: 6-25 AC/DC power input
|
|
|
|
3-pin connector: opening button (the one already wired)
|
|
- 1 (left-most): common side of button (leave the bus bar connected)
|
|
- 2 (center): other side of the button (remove the cable)
|
|
- 3 (right-most): the cable which was connected to the button
|
|
|
|
4-pin connector: ring buttons (yet unused)
|
|
- 2 left-most pins: to button 1 of door panel
|
|
- 2 right-most pins: to button 2 of door panel
|
|
|
|
On the other side is a USB connector.
|
|
This is used to flash and configure the micro-controller.
|
|
|
|
peripherals
|
|
===========
|
|
|
|
The XH-2.54 2P connector is for the 15V AC power input.
|
|
A full bridge rectifier and smoothing capacitor make a DC power supply out of it.
|
|
A buck converter module steps it down to 5V.
|
|
Under 50 mA of power consumption it is very inefficient.
|
|
With no load it has a quiescent current of 37 mA.
|
|
The 5V rail provides power to the blue pill, Bluetooth module, and boost converter.
|
|
|
|
The MT3608-based boost converter steps the voltage up to 9V for the omrom G6E-134P relays.
|
|
It is more efficient to re-use the existing 5V than stepping down the 15V because the buck converters drawn a large current under no load.
|
|
|
|
The XH-2.54 3P is to be connected to door opening button (the installer will know what I mean).
|
|
Two omrom G6E-134P relays will take control over the button.
|
|
This allows the door button to be used.
|
|
At the specified time intervals, this is disconnected.
|
|
When the right code is entered, the second relay simulates the button press and opens the door.
|
|
The relays are controlled by the board using two 2N7000 n-channel MOSFETs.
|
|
|
|
The XH-2.54 4P is to be connected with the two buttons.
|
|
They are used to enter the secret sequence to open the door.
|
|
|
|
The [blue pill](https://wiki.cuvoodoo.info/doku.php?id=stm32f1xx#blue_pill), based on a STM32F103C8T6 micro-controller, will handle the logic.
|
|
|
|
A CR2032 battery is connected through a diode to VBAT.
|
|
This keeps the real time clock (RTC) running when there is no power from the panel.
|
|
A 3.3V pin is also connected through a diode to VBAT.
|
|
This powered the RTC when the board is powered, saving the battery.
|
|
|
|
The HC-05 Bluetooth module allows to remotely connect to the UART port.
|
|
It has been configured (using `hc-05_porg.rb`) to appear as "dachtuer", and requires a PIN to pair.
|
|
It offers the Serial Port Profile (SPP) from Bluetooth classic (Bluetooth Low Energy makes little sense).
|
|
This allows to communicate with the board without having to remove the panel.
|
|
It can be used to configure the opening time slots, days, and button sequence.
|
|
It is also possible to update the firmware through it.
|
|
|
|
A WS2812B LED strip is also connected to the board.
|
|
The LEDs should be placed behind the button name shield.
|
|
An animation with be shown when pressing the button (only during opening hours).
|
|
|
|
wiring
|
|
======
|
|
|
|
HC-05 Bluetooth module:
|
|
- STATE: no connect
|
|
- TXD: PA10/USART1_RX
|
|
- RXD: PA9/USART1_TX
|
|
- GND: ground
|
|
- VCC: 5V
|
|
- EN: no connect
|
|
|
|
CR2032 coin cell battery:
|
|
- +: VBAT, though diode (VBAT should also be connected to 3.3V through diode)
|
|
- -: ground
|
|
|
|
LED (because the on-board LED screws the LSE):
|
|
- anode: 3.3V, though resistor (1K)
|
|
- cathode: PB11
|
|
|
|
omrom G6E-134P relay (bottom, for button):
|
|
- 1 +: 9V
|
|
- 6 -: 2N7000 drain
|
|
- 7 COM: door button bar
|
|
- 10 NC: no connect
|
|
- 12 NO: other relay NO
|
|
|
|
2N7000 p-channel MOSFET (for bottom relay):
|
|
- 1 source: ground
|
|
- 2 gate: PB6 (pulled low)
|
|
- 3 drain: relay -
|
|
|
|
omrom G6E-134P relay (top, for panel):
|
|
- 1 +: 9V
|
|
- 6 -: 2N7000 drain
|
|
- 7 COM: wire to panel
|
|
- 10 NC: door button (where the wire was)
|
|
- 12 NO: other relay NO
|
|
|
|
2N7000 p-channel MOSFET (for top relay):
|
|
- 1 source: ground
|
|
- 2 gate: PB7 (pulled low)
|
|
- 3 drain: relay -
|
|
|
|
WS2812B RGB LED strip:
|
|
- VCC: 5V
|
|
- DIN: PB15
|
|
- GND: ground
|
|
|
|
XH-4P:
|
|
- 1: ground (for button 1)
|
|
- 2: PB8 (for button 1)
|
|
- 3: ground (for button 2)
|
|
- 4: PB9 (for button 2)
|
|
|
|
All pins are configured using `define`s in the corresponding source code.
|
|
|
|
The prototype uses a SZOMK AK-N-01 enclosures salvaged from a J-Link clone.
|
|
|
|
code
|
|
====
|
|
|
|
dependencies
|
|
------------
|
|
|
|
The source code uses the [libopencm3](http://libopencm3.org/) library.
|
|
The projects is already a git submodules.
|
|
It will be initialized when compiling the firmware.
|
|
Alternatively you can run once: `git submodule init` and `git submodule update`.
|
|
|
|
firmware
|
|
--------
|
|
|
|
To compile the firmware run `rake`.
|
|
|
|
documentation
|
|
-------------
|
|
|
|
To generate doxygen documentation run `rake doc`.
|
|
|
|
flash
|
|
-----
|
|
|
|
There are two firmware images: `bootloader` and `application`.
|
|
The `bootloader` image allows to flash the `application` over USB using the DFU protocol.
|
|
The `bootloader` is started first and immediately jumps to the `application` if it is valid and the DFU mode is not forced (i.e. by pressing the user button on the board or requesting a DFU detach in the `application`).
|
|
The `application` image is the main application and is implemented in `application.c`.
|
|
It is up to the application to advertise USB DFU support (i.e. as does the provided USB CDC ACM example).
|
|
|
|
The `bootlaoder` image will be flashed using SWD (Serial Wire Debug).
|
|
For that you need an SWD adapter.
|
|
The `Makefile` uses a ST-Link V2 along OpenOCD software.
|
|
To flash the `booltoader` using SWD run `rake flash_booloader`.
|
|
|
|
Once the `bootloader` is flashed it is possible to flash the `application` over USB using the DFU protocol by running `rake flash`.
|
|
To force the bootloader to start the DFU mode press the user button or short a pin, depending on the board.
|
|
It is also possible to flash the `application` image using SWD by running `rake flash_application`.
|
|
|
|
It is also possible to flash the application over Bluetooth as follows:
|
|
~~~
|
|
# start bluetooth
|
|
sudo systemctl restart bluetooth
|
|
# pair device (you only need to do it once, and you need the PIN)
|
|
bluetoothctl
|
|
power on
|
|
pair 20:15:02:02:16:28
|
|
quit
|
|
# connect to device
|
|
sudo rfcomm bind rfcomm0 20:15:02:02:16:28
|
|
# switch to bootloader
|
|
echo "embedded" > /dev/rfcomm0
|
|
# flash firmware (it always fails the first time)
|
|
stm32flash /dev/rfcomm0
|
|
stm32flash /dev/rfcomm0 -b 115200 -S 0x08002000 -w application.bin -R
|
|
# disconnect from device
|
|
sudo rfcomm release rfcomm0
|
|
~~~
|
|
|
|
debug
|
|
-----
|
|
|
|
SWD also allows to debug the code running on the micro-controller using GDB.
|
|
To start the debugging session run `rake debug`.
|
|
|
|
USB
|
|
---
|
|
|
|
The firmware offers serial communication over USART1 (where the Bluetooth module is connected) and USB (using the CDC ACM device class).
|