How to connect standard wired doorbell into BigClown ecosystem?



I would like to keep the standard wired doorbell doing its job and at the same time to publish the MQTT message about the ring event.

I am definitely not a hardware guy, but I still like to play with it. It is only that my playground, in fact, starts with a simple interface like mqtt or database. Of course I can connect two wires but not really much more :slight_smile:

Are there any options how to cope with such task using the existing BigClown components?



I have exactly the same “problem” and I’ve been thinking about it recently… Unfortunately my knowledge of electronics is really basic but so far I think about a solution which could be quite easy. We could use GPIO/ADC of Core module and simple voltage divider to measure the presence of voltage. There is probably also needed a capacitor to “convert” AC to DC.

Is there some experienced electrician who would be willing to help us design a circuit for it? I think it could be great use-case.


Depends on type of doorbell you have. Mechanical or pure electrical. If it is mechanical bell, you can try magnetic reed, optical sensor or you can try to catch vibrations using accelerometer on core module.


Hello, we’ve been discussing internally at Bigclown this use case. I have also plan to connect doorbell to MQTT a year ago, but nothing done so far.

There’s no one simple answer. Every home and every coutnry has different solutions to doorbel. You can have battery operated, AC operated, AC with isolation transformer (my case) you can have mechanical ringing doorbell image or electrical “gong”.

@lubakam can you post a picture of your doorbell ring in your house and for example doorbell button (some AC types has glowing light inside) ? From some indicies we could be able to figure out what kind of device you have.

The simpliest and most generic option would be connect that same wires that are going to the doorbell ring to the Core Module. This would need some potection circuit on the input. The best would be use the optoisolator. On the input there would be limiting resistor which can be computed to work on 100/240AC and the output can be connected between GND and some GPIO pin.

Another solution could be try the reed relay, but I’m not sure that the electromagnet of the bell will be strong enought


few photos, there is a bell transformer for the doorbell circuit, button on this circuit and finally the outside and inside picture of the doorbell:

I guess the doorbell is like this one:


Thanks for the pictures. To me it seems like to the “gong” device with speaker goes 24 volts at maximum. The gong itself seems like it is powered by the AA batteries and the 24 V signal is just to trigger the gong. Does this doorbel do the ding sound when you press the button, and dong when you release the button?

However in any case we cannot be sure that there isn’t the lethal 230 V. You have to check first with some multimeter that the two wires going to the gong are really 24 V max. With this decision we can suggest the optocoupler and the resistor which will set the maximal current going through the LED inside the optocoupler.

It would be also possible to wire to some signal on the PCB of the gong, but since we don’t have any schematics and we would like the most generic solution, the optocoupler seems like good idea.

Not important thoughts:
The voltage to the gong could be AC. In case you will use the bc_button functions this can be a issue, because button functions have software debouncing and signal which is positive for some amount of time and then negative fot the same amount of time could be ignored by the debouncing. This can be solved by custom code or by optocoupler which has two diodes connected back-to-back. But you can ignore this paragraph, I’m just thinking out lout :slight_smile:

It would be interesting to use the 24 V to power the core module by some voltage regulator. My guess is that during 100-200 milliseconds the Core Module could boot and send the firmware packet which is send in every firmware. There would be needed just small fix of removing startup delay which adds few hundreds milliseconds and it is there to let ATSHA properly boot up and read out the serial number.


The button is just triggering the start of melody and it starts with the button press, the release has no impact at all. Also if I press again within the melody duration there is no impact.

I used some cheap tester showing just two values 12V for low voltage and 250V for high voltage and it showed 12V both on the two thick wires coming to the gong and directly in the button.

What surprised me a bit is that it showed 12V in two thick wires whether the button was pressed or not…
But as I said, in the beginning, my knowledge of hardware related things is very limited so not sure whether it means anything at all.


I like the mentioned idea to just wake up the core by the doorbell triggering current, I love such simplicity. Averything grows to complexity in our universe so the simple beginning is essential :slight_smile:

Btw, when talking about simplicity, I miss the basic BigCLown kit consisting just of core module powered by some button size battery and utilizing just the integrated temperature and accelerometer sensors. That would be a perfect thing. And use for instance to monitor door, window opening or many other things I can imagine :slight_smile:


It is common that you can measure some voltage on house wiring even when the circuit is disconnected. The voltage is generated by induction when there are other live wires nearby. This voltage is very low current and it’s hard to say if it’s live or not.

You have to find someone who will measure it properly and give you some schematics which you can share with us later.

The Cloony can be equiped with coin cell battery holder. We’ve been discussing internally that from the bottom side could be optional footprint for battery holder but it is not implemented yet. And cloony does not have accelerometer unfortunatelly. Only crypto and temperature sensor and LED.

Take a look at Cloony with a coin cell battery:


I consulted the guy doing the installation in our house and then double checked the wiring coming out of the bell transformer. 8V from the transformer is coming to the button so when pressing the button the 8V is triggering the gong. So the brown thick wire is live 8V and the blue one is neutral.


Perhaps the best option for me would be to combine this new sensor with a standard mini-battery motion detector which I can place close to the gong. So probably somehow extend it as suggested with an optocoupler and a resistor placed inside the gong.
Unfortunately this already sounds quite like a challenge for me so much appreciating your lego-like hardware and generic node firmware setup.


Unfortunatelly we don’t have currently any module you could use out of the box :frowning:
I’ve searched for arduino modules, there must be solution but I could not find it.

so you would need to solder or breadboard a simple 2 components resistor-optocoupler circuit:

From the datasheet I searched for Vf (voltage on the diode) and If (current on the diode) and set them to the ohms-law formula (1,2V and 10mA = 0,01A). because the LED can have in average 1,2 Volts, we need to get rid that remaining 6,8 volts on the resistor.

New photo by Martin Hubáček

I’m sure that I forget to add something to my computation, but it would not a make difference in the computed resistance, but please educate me :slight_smile:

Here are some schematics and explanations, if you google for arduino optocoupler you’ll find more:

Other solution would be 12V relay but you’ll need relay for AC because generic relay can do the 50 Hz buzzng sound. Even some basci cheap relays can work with 100Hz so it will be not just buzzing, but also making loud sounds.


ok, sounds like something for me to investigate regarding this hardware part.

What about the software part. I guess it requires to make new fork of mini battery generic node firmware which I use, to process new inputs, then probably some addition to USB Gateway firmware and also mqtt gate and finally just small conf update for influxdb gate taking care about something like node/xxxx/doorbell/-/event/count x

I am positive I can manage the last part :slight_smile: perhaps look into the python mqtt gate but I am not sure about the low level programing of firmware in C. That’s something I would like to avoid.


Software should be easy. You can reuse the Button kit hardware (core + mini battery) and firmware and wire the BOOT pin to the optocoupler.
See the schematics of button module which you’ll replace by the optocoupler

Gateway firmware in the dongle stays the same even in case you would like to send some special data. There is an API to send custom buffer from remote to the MQTT.

Even if you would like new topic, you just edit the remote and use these functions:

They are something like C to Radio to MQTT and you choose the topic and values to send.


You can also use Solid State Relay (SSR) which has wide input voltage range 3-32V so you dont need to bother with resistor, they are actually pretty cheap.

like this
or this with lovely terminators

search querry sorted by price (and the low current SSRs)

You just need to check that the minimal input voltage is under 8V and minimum output voltage is 3V or less - SSRs are usually for bigger output voltages and current, but we can also use them to simplify our circuit.


By coincidence, I managed to gain some unused Arduino starter kit and after few hours the simulation of doorbell integration works!

I used Arduino 5V and GND pins instead of 8V doorbell circuit, there was optocoupler 4N35 and resistor 1k ohm in the set so I used them. The second circuit of the optocoupler is following the button schema as suggested. Also added a small button to the first circuit to test the ring event. And then it worked as you can see in the second photo, there are push button events on the ulmus node.

Definitely beginner’s luck! :smile:

Thanks, Martin! I have learned a lot today and another integration ideas are popping up in my head :slight_smile:
Of course, first I need to productionize this. I will drop the final pictures here when I am done.

New photo by Lubomír Kamenský


Wow! Congratulations, that’s awesome that you have it working.
Since you have this nice setup, I would suggest a small test to see, if the AC signal which will go into the optocoupler will work on the button input - because of that debouncing.

Try to create a loop liek this to emulate 50Hz signal (this is pseudocode from my head)

digitalWrite(2, HIGH); //some gpio pin
digitalWrite(2, LOW);

This will generate 50 Hz signal. In case this would not reliably work, you’ll have to make a small change in the remote node firmware. But maybe you’ll need to do some changes anyway so for example only first doorbell press in 10 seconds window will be send to save batteries. On the other hand, you can have secret doorbell morse code which can be decoded on Raspberry Pi and trigger special features.



well, I decided to experiment directly with real conditions :slight_smile: Below is how the semi-production environment looks like now. The first doorbell press was promising. The event was there but after that nothing at all.
I switched back to my original testing env to test whether everything is okay and there was no problem at all. So I went back to semi-prod and started more thorough testing.

The problem is with the standard short press (just click). That generates event only very rarely. But with a long press, it always generated a couple of events with the count depending on the press duration.

Any ideas how to fix this? And please keep in mind that perhaps I have some talent for experiments but my understanding of things I do is still very limited :slight_smile:

New photo by Lubomír Kamenský
New photo by Lubomír Kamenský
New photo by Lubomír Kamenský


The issue that short doorbell press may not generate event and long press generate multiple is because the code that is reading button does software debouncing.

Pushbuttons often generate spurious open/close transitions when pressed, due to mechanical and physical issues: these transitions may be read as multiple presses in a very short time fooling the program.

This is also nice article with image, you dont need to read or undrestand the code becuase everyone’s debounce code is different

Here’s the image of signal in time that you can see on oscilloscope when you use the mechanical button

The issue is that since the optocoupler is getting 50 Hz AC signal because the doorbell transformer is not rectified to DC. This gives us imaginary 25 presses of button per second (50Hz / 2) and thats why sometimes its not recognized as button press and sometimes the single long doorbell press is recognized as multiple button presses.

We have to ways to solve it:

  • Hardware
  • Software

Hardware solution

This is my preffered way because you and everyone else could use the stock firmware without any change. You would need to add two more electronic parts to your circuit - diode and capacitor.

So between the transformer and resistor-optocoupler you put this Diode an Smoothing capacitor (ignore the RL resistor in the image below)

The type of diode dont care so much. You can theoretically use also LED as a diode. The capacitor can be ceramic or electrolytic with values somewhere un uF (microfarads). Just be careful because electrolytics have polarity and the MINUS pin is marked with ‘-’ on the package.

By this “half wave rectifier” the optocoupler will be on all the time and the Core Module will see one single long press of the button. This way you would recognize how many someone pressed the doorbell.

Software solution

This would need basicaly replace the bc_button with simple few lines of code. So the pseudocode could look like

#include <application.h>

void application_init(void)
    bc_gpio_set_mode(BC_GPIO_BUTTON, BC_GPIO_MODE_INPUT);
    // The Core Module has hardware pull-down on BUTTON BOOT PIN so next call is commented
    //bc_gpio_set_pull(BC_GPIO_BUTTON, BC_GPIO_PULL_DOWN);

  ... init of radio and other stuff .....

void application_task()
    uint8_t button_state = bc_gpio_get_input(BC_GPIO_BUTTON);
    bc_radio_pub_push_button(0);  // send parameter zero
    bc_scheduler_plan_current_relative(5000);   // sleep the task for 5 seconds - change this to your taste
} else {
    // The button is not pressed
    // Repeat this task again after 50 ms - higher is better for battery but you can miss the ring signal
    // so 50-100 ms seems reasonable to me


Take a look at the “How to: GPIO” in the docs, its basicaly what I’ve copied above.

Also you can start and edit the wireless button kit project which is the skeleton you’ll need

Final thoughts

I would be interested if you’ll be able to fix it by that half wave rectifier. Let me know if you would like to try that way. In case you’ll decide for software solution, I’ll try to do the same setup as you and test the code if you run in some issues.

You’ve written that your understanding is limited, but I’ve tried my best to find basic articles and explain it all as simple as I could. I feel that this is the right way because I feel that you’re happy that you have it working so I thought you could learn more. It’s not that complicated if you don’t put math to it :wink:

Let me know what you think. Martin


I definitely go the hardware way :slight_smile: First, it is exciting and fun to build something, and as long you are willing to guide me I am happy :slight_smile: Secondly it is better to avoid maintenance of any addtional software.

I will inspect what other parts can be found in that Arduino starter kit and follow your instructions.