Open manuel-domke opened 8 years ago
You can have a look at https://github.com/sui77/rc-switch/wiki/List_KnownDevices to get some ideas of wait time. I think a sleep of 1-2 ms will work, the codes my FHT-7901 devices send are in the vicinity of 3,6-4,6 ms so by polling every second millisecond RFSniffer should be able to detect them.
Making RFSniffer interrupt based probably requires modifying the underlying rc-switch library.
Looks like there is one solution here: https://github.com/UrbaneChimp/433Utils/commit/3f2517efffd870d571302231380410f3ad431ff1 although as I suspected it requires changes to rc-switch which I (due to #17) would rather see implemented in https://github.com/sui77/rc-switch.
If you want a reliable way to receive/send radio without heavy cpu use, you should really look into pilight. www.pilight.org It supports more protocol than rcswitch and if you add an attiny85 , or an arduino nano, the cpu usage is low (everything is explained on their website) https://manual.pilight.org/en/electronics-wiring
It tried it with only the receiver/transmitter and it also works fine (but cpu usage is higher).
Once pilight is installed, you can send/receive code from a network socket. There are examples of client here : https://github.com/pilight/pilight/tree/master/clients
If you install pilight on a Raspberry Pi without receiver, it will ,without any configuration, become a client to any Raspberry Pi with pilight installed. This allow to use multiples Raspberry Pi to relay radio codes.
There is also a web interface to manage home automation with it, I didn't really try it.
In a nutshell it is pretty awesome.
Adding a usleep(10000) in the while loop drops CPU usage to 11% from 100% (on rpi3). it does adds up to 10ms delay, which imho is acceptable for majority of the cases. Also most 433 transmitters repeat signal, checking a repeated signal before printing makes it a lot better.
the rfsniffer uses 100% cpu when running. Adding a usleep definitely helps, but I need to test if it degrades the receiving accuracry.