QH-832AC Door-bell modding

In a search for a cheap 433 MHz wireless doorbell I came upon the Quhwa QH-832AC aka QH-C-CE-3V, aka SelectPlus, aka. 1 by One in a local thrift shop (“Action”). It exists in Black and in White.
I wanted my Arduino to be able to receive the signal from the push-button so it could undertake any action necessary when someone would ring the bell (such as switch on a light, release the hounds or whatever).
My usual approach with a new 433 MHz RF device is that I use some kind of sniffer program in my Arduino and try to gather raw data from the transmitter. My standard programs didn’t really work and another program I found gave me some data that I couldn’t really work with, so i was at a loss there.
Searching internet brought me to much interesting info about the SelectPlus, but one site gave me some useful information: Voyager describes a plug-in he wrote for the Nodo and also this site gives valuable information..
I now knew it was a 36 pulse code, possibly with a pre-amble and probably repeated a couple of time. A friend with an analyzer helped me out.
The version I have is the White one with a datecode of 914. If I consider a  short puls (250-275u sec) as a ‘1’ and a long pulse (950-1000 u sec) as a ‘0’, then the pulse train is:
10101100101011001011001101010101010. That is the ‘RAW’ code. As I only had 35 pulses with the first one  actually a bit longer than a ‘short’ and a bit shorter than a ‘long’, that might have been just a preamble.
Converting the code to bits went as follows:

1	01	01	10	01	01	01	10	01	01	10	01	10	10	10	10	10	10
?	1	1	0	1	1	1	0	1	1	0	1	0	0	0	0	0	0

I presumed the first ‘1’ to be a preamble of some sort, or it could in fact be a ’01’.
Anyway the binary code converted to hex is as follows 11011101101000000  => 1BB40. However, if I presume that first preamble to be a ’01’ the address is 3BB40
When I did the same exercise for the black button that gave 11100001100110000  => 1C330 or 111100001100110000=3C330
It seems that the first 13 (14) bits are a unique bell identifier and the last 4 bytes have no specific meaning.

As I find making a send program a little bit easier than a receive program, I  first  focussed on that. These send programs are in fact not so difficult: they  go through the  specific code bit by bit and then send that with the specific pulse width.
When I would use the code 1BB40 and use that to program the doorbell (“Program” meaning unplug the chime and replug it an then send the code), I could get it to work from my Arduino, but it would not respond to the bell button. If I would programit with the bell button it would only sometimes respond to the arduino code.
If I used the 3BB40 code, it would work both ways

const byte rfPin=7;

void setup()
{
SelectPlus(0x3BB40);// White
//SelectPlus(0x3C330);// Black
}

void loop()
{
//SelectPlus_Send(0x3BB40);// 11 1011 1011 0100 0000
}
    
void SelectPlus(uint32_t address) {
    int pulseWidth= 325;// Pulse width in uS
    byte repeat = 16;   //  repeat send   
    uint32_t databit;
    uint32_t mask = 0x10000; //0x20000;
    uint32_t sendbuff;


    for (byte j = 0; j <= repeat; j++) {
        sendbuff=address;  
        // send 3 HIGH pulses for syncing
        digitalWrite(rfPin, HIGH);
        delayMicroseconds(pulseWidth * 3);
        
        // Send command
        for (int i = 0; i < 18;i++) {  // 18bits

        databit = sendbuff & mask;
// databit=11 1011 1011 0100 0000 & 0x20000
// databit=11 1011 1011 0100 0000 & 10 0000 0000 0000 0000 
// databit=10 0000 0000 0000 0000
sendbuff = (sendbuff << 1);// Shift left 
// sendbuff=   11 1011 1011 0100 0000 <<1
// sendbuff=(1)11 0111 0110 1000 0000
if (databit != mask) // it is at the 4th cycle of the loop
{ // Write 0 
digitalWrite(rfPin, LOW); 
delayMicroseconds(pulseWidth); 
digitalWrite(rfPin, HIGH); 
delayMicroseconds(pulseWidth * 3); 
} 
else 
{ // Write 1 
digitalWrite(rfPin, LOW); 
delayMicroseconds(pulseWidth * 3); 
digitalWrite(rfPin, HIGH); 
delayMicroseconds(pulseWidth); 
} 
} 
digitalWrite(rfPin, LOW); 
delayMicroseconds(pulseWidth * 16); 
} 
} 
/*
           ___
'0':     _|   |   (T,3T)
             _ 
'1':     ___| |    (3T,T) 
*/

Normally this chime will reset itself if unplugged from the mains. After replugging it just waits for the first bel signal to tune into that. I discovered however that if I had the chime programmed for the White code, but I would send the black code some 3-4 times without  replugging it, it would react to the black code and not to the white code, though strangely it still would react to the white button. If I then would send the white code a couple if times it would pick up on that code again and not seldom it would stick, meaning it would react to both the black AND the white code. Obviously this chime still holds a couple of mysteries in its code that I haven’t discovered yet
As I didn’t feel like figuring out yet how my Arduino could receive the code from the wireless button, I decided to do some hardware modification for fun:
On the PCB there are two LEDs printed on the silkscreen. These LEDs seem to be in parallel, so it is sufficient to solder in only one. A small hole in the  cover for it to stick through and voila, an optical signal added. Handy for deaf people