Napoleon eFIRE-enabled Fireplaces (Work in Progress)

meyer.mark.j · August 29, 2025, 12:09am

1.0.0 works great. LEDs work perfect too! Thanks for your work on this!

FelixKa · September 1, 2025, 4:53pm

Awesome! Thanks for your feedback and the thank you! For my open source work that is my currency

Glad that Version 1.0.0 turned out to be a working and feature complete release

feisley · September 10, 2025, 2:33am

@FelixKa I have one small quirk to report with the integration. Sometimes when I restart or upgrade Home Assistant, the eFire integration will create new entities such as light.fireplace_flame_2 and marks the original light.fireplace_flame as unavailable.

Usually restarting HA or reloading the integration will fix this and then I can cleanup the duplicate entities.

Not sure exactly what causes this or if there is any debug info I can provide to help narrow it down, but it is mildly annoying because I have automations tied to the normal entitiy names, and if it changes to the _2 ones then those automations break.

FelixKa · September 10, 2025, 3:42pm

Interesting. That clearly sounds like a bug. I will investigate.
Thanks for reporting!

feisley · September 11, 2025, 4:11pm

Sounds good, let me know if there is anything I can do to help in digging into it.

feisley · October 17, 2025, 7:42pm

I have a theory as to what is causing the duplicate entities.

I have a blueprint that allows for linking entities (ha-blueprints/ha-blueprint-linked-entities.yaml at 5d8a56b9fb8aef48e2ff2e5955c21b6341f8e7f7 · alexdelprete/ha-blueprints · GitHub), I did this so that the fireplace is treated as a switch rather than as a dimmable light when exposed to Google Home (otherwise saying turn on all the lights can trigger the fireplace)

When this situation occurs, I can disable this automation and then reload the integration and it goes back to using the original ones. My theory is that the automation is somehow making the integration think that the entity is ‘occupied’.

I will try disabling this for a while and see if the problem presents itself again. With that said, I would think that generally automations referencing the entities should not be a cause for duplicates under normal circumstances or it defeats the whole point of Home Assistant automating tasks

feisley · October 25, 2025, 2:22pm

Upon further investigation my previous theory was incorrect and the fact it resolved after disabling the automation was coincidence.

Upon inspection of the entity registry i found the two entries with two different unique IDs, one with the model name (this is when it becomes _2) and the original with the mac address.

light.fireplace_flame = unique id: AB:CD:EF:12:34:56_flame
light.fireplace_flame_2 = unique id: NAP_FPC_ABCD_flame

This appears to be set by:

self.attr_unique_id = f"{self.fireplace.name}{self.key}"

so somehow during initialization that can change back and forth to different values.

This difference can come from this function: bonaparte/src/bonaparte/device.py at 973e0b3ce0344d154044f28de957fcdaf79ded67 · kaechele/bonaparte · GitHub

Since the name is used as part of the unique ID it can change between those two possible values if self._ble_device.name is sometimes unavailable.

Update:

I fixed this locally by changing self.fireplace.name to self.fireplace.address so it always uses the MAC address for the unique ID (which is probably best because its considered unique by definition).

github.com/kaechele/napoleon-efire

custom_components/napoleon_efire/entity.py

236edff9f


      
              manufacturer="Napoleon",
              model="W190-0090",
              connections={(CONNECTION_BLUETOOTH, self.fireplace.address)},
              identifiers={(DOMAIN, self.fireplace.address)},
              sw_version=f"v{self.fireplace.state.ble_version}",
              hw_version=f"v{self.fireplace.state.mcu_version}",
          )
          
          if description:
              self.entity_description = description
              self._attr_unique_id = f"{self.fireplace.name}_{description.key}"
          elif self.key:
              self._attr_unique_id = f"{self.fireplace.name}_{self.key}"

Not sure the best way to fix this for others though since their setup might be using the name and arbitrarily changing to address could cause an issue for them.

FelixKa · October 25, 2025, 3:02pm

Great detective work! This will save me a ton of time, so I really appreciate it.

I’ll work out a fix and release a new version.

hydro_3 · December 4, 2025, 2:53pm

Felix,

I have been using your integration for a couple of years and it has worked well so thanks for pulling all together. I was working with it yesterday to try and get my voice assistant to interface with it.

Using the matterbridge integration I was able to expose the devices my voice assistant and now it can control the flame and blower both on and off along with height and fan speed.

This enabled me to get away from my timer setup and use the timer on the voice assistant also it helps.

Great job and thanks again for your work on this.

basten · April 6, 2026, 1:55pm

I was really happy to find this integration and appreciate the work that’s gone into it! I’m excited about tying the fireplace into my living room thermostat for automations.

~~That said, I’m running into a consistent issue where every time I send a command, the device becomes unavailable and then takes around 40 seconds to reconnect before I can send another command~~.

It turns out my HA Green was getting overloaded trying to manage the active Bluetooth connection through a direct USB dongle and dropping the connection. As suggested above, i got the M5 Atom and it completely eliminated the lag!