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, 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 defines 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 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).