I am having a weird situation and have already made a similar post on Hubitat’s community. I am having trouble controlling one of my fans with Bond hub. I have a Lutron Pico remote attached to a blank face plate that has the switch wiring for fan behind it. When I move the remote away from switch plate, it works fine. One of the thoughts on the Hubitat forum is that there is a frequency interference. The Lutron operates at 434 Mhz evidently.
Also, is there a way to see logs for the Bond hub? When I push the button on the app or the Pico away from face plate, the lights on Bond hub flash 4 times and the physical light comes on. If, i then push the Pico while mounted to faceplate, the Bond hub lights only flash twice and physical light does not turn off. The app shows that the light has come on. It’s like the entire message isn’t making it into or out of the Bond Hub. The Hubitat logs show similar for both the Bond & Lutron with no hint of a difference on where Pico was/is.
At this point, I have no idea so I am looking at any and all possibilities. Thank you.
Is the Bond Bridge also transmitting at or near 434 MHz?
If so, I bet that Hubitat is triggering off the first successfully decoded packet from the Pico.
But know that to improve reliability of the one-way protocol, the Picos transmit a large number of repetitions of the same packet.
So, Bond Bridge may start transmitting, but the Pico is still transmitting repetitions. This can confuse the ceiling fan receivers which typically use the very sensitive “super regeneration” technique.)
A possible solution is to add a delay in your Hubitat rule. 300ms should be plenty, but maybe you can do less.
As for why the Pico works differently when against the faceplate, could be subtle differences in resulting interfering signal level at the cf receiver?
YOU ARE A GD GENIUS!!! That did it. I added a 300ms delay and it works like a champ attached to the faceplate. You don’t know how much I appreciate you solving this mystery.
Perhaps we could add listen-before-transmit logic in the firmware, so that this sort of interference could be mitigated in general. But that is likely to be quite limited in effectiveness because the Bridge may not be able to hear the Pico due to different modulation (Pico uses GFSK AFAIK), amplitude (Pico closer to the CF receiver), frequency (CF super regen receivers are much wider than the Bond Bridge’s super heterodyne receiver.)
I tested the limits of the delay. At 100ms, it worked sometime and sometime did not. I settled on 200ms and it worked every time that I turned the light off & on testing to make sure I wasn’t dreaming and it really was working. Also, I removed the delay and got the PICO and the Bond Hub so that I could see both at the same time. I pushed the PICO button and it’s green LED was still flashing when the Bond Hub started to flash; more evidence of the problem.
I originally noticed this issue 10 days ago and it has been bugging me ever since.
The only real mystery left is why having the PICO mounted to or close to the original switch’s location would cause the problem but if I had the PICO in my hand, it would not. Thank you again.
Now on to ya’lls biggest & most important challenge… Figuring out how your app can know when a fan (or it’s associated light) has been turned on by the original remote.
Can we “just” get BOND remotes as an optional accessory which are programmable / configurable via the BOND app to either emit the original remote frequencies and/or link to the BOND bridge via BLE (or RF / other protocol)?
Sometimes there is no replacing a physical remote for some household members or guests; I can sort of fake it with my particular setup of switches and remotes and controllers, but it’s not straightforward or easily replicable for most consumers.
That did it. I added a 300ms delay and it works like a champ attached to the faceplate. You don’t know how much I appreciate you solving this mystery.
