I’m using this really well made software to implement a homeassistant based security system.
Tried both esphome (with problems when sensors are more than 10/15) and tasmota (that has lower sensitivity on diy gateways).
I’ve built two RF gateways with wemos d1mini + fs1000a (TX gpio5) + rxb12 (RX gpio4).
All is working fine and I’m using this demultiplexer strategy for easy and fast manage rf codes for homeassistant.
Long story short to make this system “jammer proof” i use this method:
- every 3 seconds I send a code from GW1 to GW2 and if GW2 does not receive a code for 15 seconds (4 misses) and automation is triggered.
The problem is that with the useful feature to avoid duplicate codes from different gateways, GW2 never receive the code because it is received from the same GW1 that is transmitting the signal and and not transmitted again
This feature is described here: Multiple GW.
So, the question is:
There is another method to force that this command is transmitted to the other gw and not received locally? The alternative that I have is to break multiple gateway deduplication functionality.
Thanks and regards.
Great job for this little piece of software.
You can use different base topics for the gateways (so duplicates management won’t occur at gateway level) and further use HA automations.
If worried about jamming then it is probably better to switch to an encrypted RF technology (Zigbee, Z-wave) and you can see when the end devices are no longer communicating with gateway.
But what if an attacker jams the 2.4 Ghz band (wifi) so it affects the gateways instead of the 433 Mhz?
Ok thanks, i could use different gw topics and avoid duplicates management.
Have you an example of HA automation to avoid duplicates?
I choose 433 mhz because is really cheap and simple technology eg. 2.5$ for gsw07 door sensors and 5$ for smoke sensors.
If 2.4Ghz gets jammed and a gw goes offline i’ll be warned with LWT offline.
I don’t think you would need to (just forward the payloads from the second gateway to the topic of the first), except if the payloads are arriving with significant delays so they’re interleaved (ie: “on” from one gateway, then “off” from the second, “on” again from the first). However, if the payload from the second gateway is an exact copy of the first one, then there’s no problem with HA. Example for door status (set an automation that triggers with the change of the sensor from off to on):
i) initial state off (door closed)
gw1 sends on (door open)
gw2 sends on
automation triggers on gw1 payload;
ii) initial state on
gw1 sends off
gw2 sends off
automation doesn’t trigger
iii) initial state off
gw1 sends no signal (jammed or offline due to wifi issues)
gw2 sends on
automation triggers on gw2
it seems a good solution but:
in config_RF.h I see #define subjectMultiGTWRF “+/+/433toMQTT”
so, even if i change base topic name + wildcard match all topics.
To avoid this i could change the code this way:
#define subjectMultiGTWRF “+/+/dummy”
So it will never matches.
Could this is a solution?
I think so, because the topic is made of base (defaults to “home”), gateway name and “433toMQTT” and either commenting the line or changing it to something like “dummy” should work as there won’t be any matching topic.