One IP is not reachable unless creating a dummy route

Question

One host can ping everything but one other host.

Let's say that I've 4 hosts in my network:

1. My Internet Box (Gateway) : 192.168.0.100
2. My Ubuntu machine : 192.168.0.1
3. My RPi machine : 192.168.0.2
4. My Tuya WiFi plug : 192.168.0.3

Ping from Ubuntu to any other hosts is working Ping from RPi to other hosts is working but to the Tuya plug.

Trying to ping is 100% packet loss

pi@hassbian:~ $ ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
^C
--- 192.168.0.3 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8339ms

But, when creating a useless route like so

sudo ip route add 192.168.0.3 via 192.168.0.100 dev wlan0

it is working, somehow

pi@hassbian:~ $ ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=255 time=80.2 ms
From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.3)
64 bytes from 192.168.0.3: icmp_seq=2 ttl=255 time=122 ms
64 bytes from 192.168.0.3: icmp_seq=3 ttl=255 time=144 ms
64 bytes from 192.168.0.3: icmp_seq=4 ttl=255 time=37.9 ms
64 bytes from 192.168.0.3: icmp_seq=6 ttl=255 time=61.1 ms
64 bytes from 192.168.0.3: icmp_seq=7 ttl=255 time=98.8 ms
64 bytes from 192.168.0.3: icmp_seq=8 ttl=255 time=119 ms
64 bytes from 192.168.0.3: icmp_seq=9 ttl=255 time=128 ms
^C
--- 192.168.0.3 ping statistics ---
9 packets transmitted, 8 received, +1 errors, 11.1111% packet loss, time 8040ms

After that I can remove the route and it is still working for a few minutes and fail again.

pi@hassbian:~ $ ip route del 192.168.0.3 via 192.168.0.100 dev wlan0
pi@hassbian:~ $ ping 192.168.0.3
PING 192.168.0.2 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=51.6 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=64 time=54.6 ms
64 bytes from 192.168.0.3: icmp_seq=3 ttl=64 time=8.64 ms
64 bytes from 192.168.0.3: icmp_seq=4 ttl=64 time=32.5 ms
^C
--- 192.168.0.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms

The RPi is running Pi-Hole but disabling or even removing it doesn't solve the issue.

pi@hassbian:~ $ nslookup 192.168.0.3
3.0.168.192.in-addr.arpa       name = bf3961a448a2979f55sean.lan.

Running tshark confirms that request is sent but no reply is received

pi@hassbian:~ $ sudo tshark -i wlan0 -f "host 192.168.0.3" -f "icmp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
    1 0.000000000 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=6/1536, ttl=64
    2 1.040043499 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=7/1792, ttl=64
    3 2.080053454 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=8/2048, ttl=64
    4 3.120040125 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=9/2304, ttl=64
    5 4.160030649 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=10/2560, ttl=64
    6 5.200063827 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=11/2816, ttl=64
    7 6.240062420 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=12/3072, ttl=64
    8 7.280055125 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=13/3328, ttl=64
    9 8.320066109 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=14/3584, ttl=64
   10 9.360099540 192.168.0.2 → 192.168.0.3 ICMP 98 Echo (ping) request  id=0x1a61, seq=15/3840, ttl=64

Of course, there is no firewall involved, everything is directly connected via WiFi to the Gateway that is also the DNS Server.

For completeness, some additional information:

Route table before adding the dummy route

pi@hassbian:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.100   0.0.0.0         UG    600    0        0 wlan0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

arp table

pi@hassbian:~ $ arp | grep fc:67:1f:cb:12:58
bf3961a448a2979f55sean.lan.                ether   fc:67:1f:cb:12:58   C                     wlan0

So I did a terribly awful workaround: I created a cron entry for root like so

* * * * * ip route add 192.168.0.3 via 192.168.0.100 dev wlan0 >/dev/null 2>&1;ping -c 5 192.168.0.3 >/dev/null 2>&1;ip route del 192.168.0.3 via 192.168.0.100 dev wlan0 >/dev/null 2>&1;ping -c 5 192.168.0.3 >/dev/null 2>&1

The Tuya plug is kept reachable and I can use some python to go read the power information.

Can someone please help me understand why this RPi host (192.168.0.2) is behaving like that when accessing the plug (192.168.0.3) while other hosts on the same network can ping the plug without any issue?

I'm hopeless, I'm running out of idea. I'd like to remove this cron entry and be on a stable network situation.