Closed jschroeter closed 7 months ago
Hi :-)
I have two working solutions, but they are still comparable complicated and need at least some knowledge about electronics.
The easiest thing is just listening to the bus. This can be done with little hardware. Controlling the bus is more complicated.
And the most complex situation is reading/writing bus and beeing supplied by it (as it is "hard" to not disturb it).
I have a custom build PCB by JLCPCB which can do all of that, but bus supply is working only "border line" according to my measurements. I know what roocky mistake I made but never corrected it, this is why I did not publish it.
So there are two ways:
I would be happy to build a solution together with someone, document it for the public - but sadly there is some electronics knowledge required - as I fear it wouldn't work first try.
Is there anything where you would feel comfortable with? if you bring in the time, effort and willingness I can support it. But this is no easy solution. Sorry :-/
Hi, thanks a lot for your quick answer and sorry for my late reply.
Before I continue, another question: is the protocol somehow encrypted? Or can I "simply" listen what command is sent when I open the door via the indoor device and re-send this command later again to open the door? Or how would I find out the dst? I was reading regarding possible alternatives and found the NUKI Opener which sounds promising, but it's not officially compatible with Gira. Also they claim Gira uses an encrypted bus. With some additional device from Gira it seems to be working.
Sry I forgot your message, was on vacation.
The bus is not encrypted at all. From an electrical standpoint it is just a bit complicated and Nuki is too simple for that. Cheap excuse from whoever 😅
The addresses can be sniffe with the same hardware d and values just copied to your own commands. You could even brute force it but the bus speed is a natural barrier, it would take weeks and why wait 😄
Of course you can just salvage an indoor station. There are different revisions but I think the Nuki thread should give a good start.
Ah what you would be able to also do: replace the pic microcontroller on a original indoor station with an esp.
The existing microcontroller just receives and sends out PWM signals, each on a dedicated pin. The pwm is just the digital version of the signals I show in this repo.
But I have no turn-key solution so that would be maybe even more complicated. And more costly.
Hey @DaSchaef , really nice work! May I ask which HW you used to generate the signals with an ESP32 and what's the difference compared to the STM32 solution? Also how you powered the controller using the power from the bus line would be interesting.
I have STM32 and ESP32 available and would like to give it a try after listening to the bus with an oscilloscope. Powering with external 3,3/5V is not a problem, better have cables in front of the front door than having to walk to the door each time :)
Just want to say that I'm still very interested in this and following, but unfortunately lacking the electronics knowledge to continue. I would be willing to help on the software side (e.g. Home Assistant integration), though.
You said fine-tuning the voltage levels with an oscilloscope is probably needed. Is this because they vary a bit across buildings/installations? Would it be possible to find a generic solution which works everywhere? I'd also be willing to pay someone to build the hardware for me.
External power would also be fine for me - of course, powering via the bus would be super convenient but no problem for me if it doesn't work.
Hi :)
I never beautified my project because:
This is why I search people who are able to proceed where I finished, and I'm fully willing to support it, but time and money I don't want to finish it myself :) I just uploaded my internal, ugly stm32 design.
Bus powering: Do not do it, without really knowing electronics ;-) If you really understand my shitty schematic, we can discuss it in more details. But believe me, there are audio and EMC related issues.
RX is most easiest: You can use something like, AC coupling the signal to a GPIO. But limit the voltage with low-forward-voltage diodes (e.g. Schottky), to not damage the GPIO in the rare case that a large voltage transient is coupled to the GPIO. After that you can use EXT Interrupts and Timers to decode the signals. Logic should be simple, I should be able to help you: In principle: Use EXT INT to count the pulses inside a pulse train, Use a TIMER/ALARM to see if a pulse train is finished (xx ms no EXT INT means pulses are over). Add the pulse counts to an array.
If your timer fired and there are no counts (which means the timer fired twice in a row), you know that the whole transmission is over. Think of the timer similar to a watchdog, where the EXT INT resets it.
Now you have an array with pulse counts, see the image on the GDOOR main repo. You can then process this further to bits (>50 counts = start bit, >25 counts = Bitvalue is 0, <20 counts = Bitvalue is 1), and then you have a 01010010 bitstream, which you can pack into 9 bit words, check or ignore parity bit, remove it, and now you have 8 bit value (aka chars).
TX is complicated, I successfully breadboarded two possibilities: 3.1 First options was a Wien-Oscillator which I was able to turn on and off by a GPIO. 3.2. I think more easier is a bandpass: Just output the needed signals as a PWM, the bandpass will "make it a somehow nice sine trains", like shown in the top README.md. A bandpass example with added output buffer is shown in the stm32-ugly.
Uploades STM32 design: You should be able to procure the hardware pre-assembled from JLCPCB, all assembly info are inside the schematic. You need KiCAD with the "Fabrication Toolkit" PlugIn, this combo will create you production files, which you can upload to the JLCPCB webpage and they will produce, assemble and ship the PCBs.
At least, that is what I did a year ago. Be aware of the two bugs I documented! They are still included!
Crystal Osc. Pinout is wrong, this should be corrected, otherwise you have a hard time to manually correct this error (which means fine soldering needed!). From my memory I swapped the meaning of the pins.
Remove R15, best is to set it to DNP (Do not populate) for JLCPCB, this will disable self-powering from the gira bus, but leaves you with the options to power via the USB-C connector. (The whole board only needs ~ 10mA, at 5V this would be 0.05W)
Be also aware of the strange form factor: You can break-out the two circled PCBs, so that the finished assembly fits into an "Unterputzdose" (German).
One thing I forgot: The STM32 version is rock solid in RX and TX, only with the bugs (which I fixed manually) and the "strange" form factor.
And I used STM32 instead of an ESP only because of power consumption and JLCPCB (at that time this was the only low power microcontroller which they could assemble).
I just uploaded a ESP32 version.
It can be produced by JLCPCB, 5 parts costs approx. 30€ (shipping and taxing increases price). I currently have no firmware for this. If we have enough interest, I can order it. (Everyone can order these as well, you can use the production subfolder in esp32).
Additionally needed are:
If someone else (or I) would order a batch, I can offer to write a simple firmware for it. No full guarantee that there is no hardware bug in the design, but as I copied it from the working STM32 PCB, risk is low.
Unfortunately I didn't have the time yet to check your latest commits, but they look quite very interesting!
I'm totally interested in ordering such sample, feel free to contact me via mail for further details :)
Same, I'm also interested. Let's sync via mail.
I created a private repo, due to missing mails and no DM capability on Github :-)
Hello, Thanks a lot for your efforts on documenting!
I’m looking for a (self-made) solution to open our house door via Home Assistant. I know there are commercial solutions like Gira TKS-IP-Gateway. But it’s too pricy.
I’m wondering if you could give me some guidance on how to build the hardware to connect to the bus? I’m a software guy, don’t know much about hardware. But e.g. I’m a bit familiar with ESPHome.
Thanks and have a nice day!