New to bond and trying to integrate a fireplace with a home automation system. The fireplace is a ridiculous system where the state is held in the remote, not the fireplace board. But that’s not important for my question
For my integration I need to scan a bunch of signals from the fireplace remote. But what I notice is if I scan the same command multiple times it gets captured as different hex data each time. Is this because the hex encoding isn’t deterministic/produces different values each time? Or is the signal from the remote really changing in some way every time.
The scanned signal does the right thing when retransmitted by Bond. It would just be nice to be able to compare the hex-encoded signals and know whether it was the same as one I’ve already scanned.
Related, I am using the API to scan and it doesn’t look like the API supports setting hex vs. cq encoding. Is this an API limitation or is the encoding specified by the signal that’s recorded?
Welcome! I love API questions in the morning (Not joking)
Indeed. We call these “state remotes” and indeed they become extra ridiculous when you add in another control point like the Bond Bridge, and they fight for state…
It is possible that the signals are essentially the same, just appear different because of bit offset or sampling. For example of bit offset, the following four signals are indistinguishable on the air: 00 F0, 01 E0, 00 78, 00 3C. Or, consider sampling error: 0F FF FF FF and 07 FF FF FF are both very similar pulses just with lengths 300 versus 275 microseconds. The Bridge records by sampling every 25 uS (40 kHz).
The receiver cannot know about bit offset, and the sampling errors usually don’t matter (25 uS is small compared to the symbol rate of most remotes).
Indeed. You could graph them. We don’t have a public-facing tool for this, but it is pretty easy to do in matplotlib especially if you ask o1 for help :).
For scanning, you are correct. The cq encoding is more of a language that expands into the raw hex. On recording, we get a raw sampling and the CQ encoding would be complex (due to sampling errors). Some algorithm would be needed to clean up the signal, but at the cost of not faithfully reproducing the recorded signal.
I hope that sheds some light. And please be careful with automating your fireplace.
Understood. My plan is to completely replace the remote. That thing will have the batteries removed, never to see the light again. That’s the plan anyway… We’ll see if I’m still sane at the end.
Clearly there’s the benefit of graphing to see if two signals recorded are in fact more or less the same as I think they should be. But beyond that, would I potentially gain any efficiencies by looking at a command for say (very oversimplified) flame 1 and flame 2 and be able to derive flame 3? Are signals for devices like fireplaces typically some sort of sequential signal? Otherwise I should probably just knuckle down and record the several hundred signals
This is what we do in our lab when new remotes arrive. Sometimes it is easy. Sometimes there is a checksum to figure out. Sometimes there is a CRC and we need to hunt for the algorithm. Sometimes there’s a CRC and they use a non-standard polynomial, or the entire packet is scrambled (possibly whitened) and we are unable to figure out any structure. In the latter cases you basically have to just record on/off as a user. — You as a scriptor have the option of creating something more complex with all the recorded signals.
Good luck! (And, do share a photo of the front/back of the remote. I could check what the support status of it is.)
It’s a Proflame 2 remote. Pretty sure FCC ID: T99058402300. Unfortunately the ID on my remote is already rubbed off. I’ve seen some questions about it on the forum and it appears to be “unsupported”. It’s probably because there are some like 600 different states that have unique commands.
(Not joking)
