433mhz receiver issues

djmvt

been running pimatic for a while now, almost every piece of lighting is controlled by pimatic.
But there is a problem with receiving 433mhz signals.
atm I have 3 temp sensors all generic chinese unbranded, a doorbell (brand name Byron, works as pir3) and 2 klikaanklikuit wallswitches. for some reason pimatic (or the arduino running homeduino) doesn’t recognise the wall switches and doorbell every now and then. usualy pushing the button longer will result in action but that is not reliable.
At first I was thinking this was a reception issue so did all possible tune-ups to the rxb6 module (placing capacitors on the power inputs and tuning the antenna) but it didn’t help.

So finally I connected an amplified speaker to the data pin to “hear” the data as it is received.
Surprisingly every device is received as audio, no distortion, no “bad signal”, all packages of all devices are heared, loud and clear.

But still Pimatic misses a lot of them. Could this be a problem in pimatic or is there perhaps an issue with homeduino not understanding what it is receiving?

I am sure it is not a reception problem since all signals are hearable, even checked them with an osciloscope and you see clearly the data train coming in.

somebody having an idea?

sweetpi

There can be multiple reasons for missing signals:

Maybe tow device send at the same time and so the signals conflict with each other. This is a general problem with RF on the them frequency and not solvable without resend and acknowledgment.
To detect and decode an rf package, the pulse sequence must be repeated at least 3 times: First to find the header pulse, second to record and third to verify. So if on sequence gets noised, the detection will fail.
If the receive buffer of rfcontrol is full, it can’t receive new signals.

If you are able to capture a non detected pulse sequence, you can test why it is not detected by RFControl, by doing a simulation: https://github.com/pimatic/RFControl/blob/master/simulate/simulate.cpp

Maybe there is really a bug in RFControl. If you find a way of handling one of the issue above let me know. I’m happy about contribution.