Fireplace turning off after a few minutes (American Flame)

Devices Fireplaces
22

Thanks for your thoughts @residualimages

I bought the Bond Bridge purely to control my fireplace, and as this is one of the last hurdles I have in my smart home automation journey I am hesitant to swap everything else over into a new platform when I have everything else working perfectly as-is.

Regarding the dangerous aspect of controlling a fireplace, I would not suggest deviating from what the manufacturer has implemented. Instead, what I have suggested simply mirrors what the original design from the manufacturer was, which is to send an “on” command every 1min IF the fireplace has been placed in an “on” state. If the fireplace is in an “off” state, or any other command is pressed randomly (such as “up”, “down”, “low”, “high”, etc.), then this should not cause the “on” command to repeat, as the “on” state should be explicitly triggered for this keep alive function to work.

Speaking of safety measures as well, no one should be using automated controls with fireplaces that don’t at least have remote control support natively featured. It is clear that there are additional safety measures in place for remote control operated fireplaces that help mitigate risks that deviate from standard operations, which is why I have encountered things like the automatic shut-off feature that occurs after no command has been received for 30mins (which would include the “on” command it expects to receive every 1min). These are safety measures baked into the fireplace itself, and act separately from the remote control.

On the flipside, if the remote control can send this command indefinitely as long as it has battery charge, then I see absolutely zero difference in the Bond Bridge mirroring this functionality, as the internal safety features on the fireplace itself will remain active regardless and as far as the fireplace is concerned nothing has changed at all.

However, to play it safe, I would probably recommend that a 24-hour restriction be enabled on this “keep alive” feature, which would greatly eliminate this concern as it would be an improvement over any manufacturer implementation to begin with. So, in this case, after 24 hours have passed for a fireplace being in the “on” state, cease the repeated “on” commands from being sent and send an “off” command to turn it off. If the user wishes to restart a fireplace after 24-hours of continuous use, they can safely and easily do so by using the Bond Bridge app as usual.

If Bond would rather, they could add an app reminder “Are you still there?” after 23 hours that checks whether the fireplace needs to be on any longer, but I’m just focused on getting the basics right so I can get this up and running sooner while it’s still cold and relevant for me. :grin:

23

To be clear, I wasn’t suggesting doing away with the Bond Bridge but rather augmenting it by integrating into a full smart home platform.
That’s one of the strengths of the Bond Bridge, offering a full local network API for their technology (Bridge, Bridge Pro, Sidekicks, Smart by Bond, etc) which can then make the Bond Bridge, and other things, even more powerful.

Thanks for replying with your clarifications and additional thoughts. Dialogue is great!

1 Like
24

Apologies, I understand what you mean better now. While I know that is always technically an option, I just find it hard to justify the effort when the capability technically already exists within the product I have (Bond Bridge), and it’s just one setting away from being enabled as an automated feature. Sadly, repeatedly asking Bond Bridge to turn on the fireplace every 29mins gets old fast.

I would also always prefer to work natively within the products I own rather than augment them via another product, as this poses compatibility issues down the track as things change (particularly with APIs).

So, my best bet right now is to articulate this issue and fix as best I can, and hope that Bond agree with my reasoning and find it worthy of a quick implementation into their tech stack natively. :slight_smile:

Thanks for your feedback and support as well. The more the merrier.

1 Like
25

Hi Jacob, indeed you have very clearly articulated the situation and made a clear argument as to why it would be technically possible for us to implement these keep-alive transmissions for your fireplace.

However, the reason we have not implemented the keep-alives is not a technical one, but rather a regulatory reason. The FCC rule which permits Bond Bridge to do what it does specifically forbids such keep-alives, and specifically for fireplace remotes there is a clear precedent establishing this. As a US-based company, we take our compliance obligations seriously, so we cannot implement fireplace keep-alives inside the product.

Thanks for your understanding.

26

Hi @merck,

I appreciate the response and explanation, however, if such a feature can exist within an RF remote that is mass produced (for whichever application it may have), how can that remote have different rules and regulations applied beyond what Bond is supposedly governed by (which the same rules apply to)?

As far as I understand things, remote frequencies have regulations applied in relation to the frequencies they operate within, not the protocol or commands themselves, and so there is no specific clash in this case?

If you could point me to the FCC rules you’re referring to, it would be greatly appreciated, as with all due respect I have seen you mention the “keep alive” feature in the past as not being supported as it was not well understood in the past, and this answer differs dramatically from what is now being stated?

If the majority of fireplaces require this “keep alive” feature to be in place, particularly anything that is remotely modern by design (and released well before Bond Bridge was even designed), then I don’t understand how Bond as business can advertise support for fireplaces and then not provide said support?

If it is indeed regulation based, then why has Bond as a business not sought approval for these regulations before proceeding to advertise support for fireplaces as a device?

Many thanks in advance again for any information you can provide.

27

The regulations apply also to the purpose, content, and timing of transmissions, not only their frequency, power, and modulation.

You can look up the FCC IDs for the products you are interested in, and read the public submissions. Fireplace remotes that have keep-alives are treated differently, and those different rules are incompatible with how the Bridge works.

There are plenty of fireplaces that do not have any keep-alives.

But yes, fireplace support is the most spotty compared to shade or ceiling fans, mainly for this reason.

Sorry that’s really as deep as I can go into this one.

28

Hi @merck

Again, without sounding rude, you have not called out a specific reason for not supporting this feature, but instead provided a general statement?

In many cases, there are no FCC IDs that apply to a remote, as many users of your product don’t live within the US, such as myself and others that have posted on your forum.

If you blame the FCC for this lack of feature (which again, is a sudden change in response compared with previous replies), you could easily place this feature behind a geolocation that is dictated by a user’s account location? This would enable the feature for those who aren’t in the US if that is the reason for not including the feature to begin with.