Rf simple filter

[josephperry]

Description:

Implement a RF Simple Filter

Restrict reporting of RF data by RF Protocol and/or RF Bitlength. This is an attempt to prevent RF noise from creating so many false RF switches. This does not filter by RF value.

For example when LOG_LEVEL=LOG_LEVEL_NOTICE then the filtered out RF data is reported as: N: ZgatewayRF ignoring RF Value 131071, RF Protocol 29, RF Bitlength 16 N: ZgatewayRF ignoring RF Value 3894, RF Protocol 10, RF Bitlength 13 N: ZgatewayRF ignoring RF Value 1, RF Protocol 26, RF Bitlength 12 N: ZgatewayRF ignoring RF Value 6381, RF Protocol 26, RF Bitlength 13

Checklist:

• [x] The pull request is done against the latest development branch
• [x] Only one feature/fix was added per PR and the code change compiles without warnings
• [x] I accept the DCO.

[1technophile]

Thanks for the idea. Let me think about it, I may have others approaches to propose.

[josephperry]

I have door sensors, PIR sensors and remote control switches that all apparently use a EV1527 IC or some variation of it. They all produce unique values that are decoded by RF protocol 1 with bit length 24. Each device transmits one or more unique values, e.g. for door open, door closed, low battery, tamper, particular button pressed, motion, etc. There are many values I expect to receive with the devices I have, this could be a long whitelist if OMG choose that route.

RF noise can be decoded as RF switches as I've shown in the description. I'm now using a CC1101 but with a cheap RF receiver the noise problem was even worse. It is not likely that noise is decoded with both the expected protocol and bit length, but this can happen. However fewer false RF switches are created by OMG after my RF simple filter. I use Home Assistant and node-red to detect the switch value and react to each signal. An unexpected value is just ignored in node-red.

I chose four sets of Protocols and Bit lengths to allow receiving from multiple types of RF devices but I currently need only one for the EV1527 produced values.

[1technophile]

I'm thinking that we could have a way to reduce the list of protocols at build time directly at the library level: https://github.com/1technophile/rc-switch/blob/development/src/RCSwitch.cpp

The other library like RTL_433 have a similar approach.

[josephperry]

I'm thinking that we could have a way to reduce the list of protocols at build time directly at the library level: https://github.com/1technophile/rc-switch/blob/development/src/RCSwitch.cpp The other library like RTL_433 have a similar approach.

If as you suggest protocol selection be done at the library level at build time would one advantage be a smaller executable? That could be a plus.

Another possibility is to initially enable all RF protocols as they are currently but allow the selection of one or more RF protocols by MQTT. If some protocols are selected then all others would be disabled.

mosquitto_pub -t home/OpenMQTTGateway_MEGA/commands/MQTTtoRF -m '{"add_protocol":1}' and mosquitto_pub -t home/OpenMQTTGateway_MEGA/commands/MQTTtoRF -m '{"add_protocol":25}'

Would cause OMG to respond to only RF protocols 1 and 25, all others would be ignored.

An advantage of this alternative is the selection of RF protocols wouldn't have to be done at build time so they could be changed at will.

[1technophile]

Another possibility is to initially enable all RF protocols as they are currently but allow the selection of one or more RF protocols by MQTT. If some protocols are selected then all others would be disabled.

Good idea, like a white list of protocol: home/OpenMQTTGateway/commands/MQTTto433/config -m '{"white-list-prt":[1,2,21]}'

[josephperry]

Yes, a whitelist of RF 433 protocols would be ideal. We'd also want a way to

• remove RF 433 protocols from the whitelist or
• replace one whitelist with another or
• completely clear the whitelist to again accept all RF 433 protocols.

We'd also want a LOG_LEVEL=LOG_LEVEL_NOTICE to report when a RF 433 signal is ignored, for example: N: ZgatewayRF ignoring RF Value 131071, RF Protocol 29, RF Bitlength 16

[1technophile]

Yes, a whitelist of RF 433 protocols would be ideal. We'd also want a way to remove RF 433 protocols from the whitelist or replace one whitelist with another or completely clear the whitelist to again accept all RF 433 protocols.

The ble white list principle is to publish with the retain flag and replace the entire white list if you want to modify it. If you want to remove it, you just delete the message from the broker.

This enables to keept white list persistence accross ESP reboots.

[josephperry]

I agree with the RF 433 white list. After looking at the BLE white list it appears to be more complicated to implement than I'm prepared to attempt right now.