Intellifire (Wifi Fireplace Module) - Hearth and Home

Well, i have modified and uploaded the files into custom_components/intellifire_beta, and I can see Intellifire Beta in integrations, but I am stuck with an erroring config_flow. I’ll try to install the right version of intellifire4py, is it 0.9.6 or 0.9.7?

Steps I did to get it running:

  1. Copied components/intellifire directory as custom_components/intellifire_beta
  2. Updated manifest.json (changed domain and name)
  3. Update const.py (changed domain)
  4. ssh’d into my homeassistant docker container and installed intellifire4py version 0.9.6
  5. Restarted HASS
1 Like

Thanks. step 4 errored out for me, unfortunately. I guess I will wait this out.

Building wheels for collected packages: aiohttp, frozenlist, multidict, yarl
  Building wheel for aiohttp (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /usr/bin/python3 /usr/lib/python3.9/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /tmp/tmpbd9_7lgd
       cwd: /tmp/pip-install-hegxbioc/aiohttp_bb275201478244239c3dfe18dbafb84c
  Complete output (27 lines):
  *********************
  * Accelerated build *
  *********************
  running bdist_wheel
  running build
  running build_py
  running egg_info
  writing aiohttp.egg-info/PKG-INFO
  writing dependency_links to aiohttp.egg-info/dependency_links.txt
  writing requirements to aiohttp.egg-info/requires.txt
  writing top-level names to aiohttp.egg-info/top_level.txt
  reading manifest file 'aiohttp.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  warning: no files found matching 'aiohttp' anywhere in distribution
  warning: no previously-included files matching '*.pyc' found anywhere in distribution
  warning: no previously-included files matching '*.pyd' found anywhere in distribution
  warning: no previously-included files matching '*.so' found anywhere in distribution
  warning: no previously-included files matching '*.lib' found anywhere in distribution
  warning: no previously-included files matching '*.dll' found anywhere in distribution
  warning: no previously-included files matching '*.a' found anywhere in distribution
  warning: no previously-included files matching '*.obj' found anywhere in distribution
  warning: no previously-included files found matching 'aiohttp/*.html'
  no previously-included directories found matching 'docs/_build'
  adding license file 'LICENSE.txt'
  running build_ext
  building 'aiohttp._websocket' extension
  error: command 'gcc' failed: No such file or directory
  ----------------------------------------
  ERROR: Failed building wheel for aiohttp

Another option I see is really fleshing out the Climate entity.

You could use a bunch of Presents, Fan Modes - both of these allow for custom values.

Just not sure how this works in practice as they’re not entirely independent from each other

Got it. Had to uninstall then reinstall intellifire4py then restart. Thanks for the guidance. Thanks jeef for pushing this forward!

Just pushed a select option to the repo

Neat. I think eventually some way to just have it as a slider, or a dial that goes 1-5 (ie duplicating the remote) is the way to go, but i’m grateful for what we have here.

Cool - I’ll take a look at this in a bit.

Testing with what’s there now - I’m pretty happy overall. Really just boils down to polishing up the entities that ultimately are exposed.

The underlying library is good - It is already an improvement over the Intellifire app itself.

2 Likes

Pushed another update → added selects for fan/lights which probably fall into the shouldn’t be category … oh well

1 Like

Heh - those have logical entity types!

Yes - the app truly sucks

I loaded the beta version into my build of HA (been developing in a different container).

I’m still seeing some unavailable states coming along but overall it mostly works.

One thing I really haven’t made sense of is sometimes it seems like the local API gets “stuck” or locked up:

So I’ve managed to use the web client: HHT Web Wifi Module Interface - user page

To send a Soft Reset

And things seem to move along more smoothly then.

I’m also wondering if perhaps cloud-commands get “buffered” in a different way… more to explore - but I’m going to either add an option for

  • Cloud Sending
  • Local Sending

Or maybe have a fall-back mode where if a local command send times out it will go to the cloud… :man_shrugging:

I know people are “sensitive” about keeping everything local if possible… and I’d be happy to support that if there was a way to get the API out of the local interface w/out having to hit the cloud.

1 Like

Nice on that Soft Reset find. Using the Intellifire app I’ve had to hard reboot my fireplace to get connectivity back before so it’s nice to know you can recognize this state and issue a reboot.

Ideally all commands are issued locally to remove the cloud hop/latency. But either is fine for me - I just care about stability.

Using Intellifire app I frequently need to force quit or back out to the locations screen and go back into fireplace for commands to work again. I assume that flow must reauthenticate. Your library and integration seems to have solved that.

Agreed that the beta is already more reliable than the app itself. Thanks again for the work here.

Part of me wonders if cloud control might actually be more stable. It seems sometimes the local interface “locks up” but since soft reset seems to be cloud only makes me wonder if the cloud interface is oddly more stable.

App control happens locally after getting tokens from the cloud. So it’s instability should in theory be exactly the same as this integration.

Looks like my last pr went through so I’ll slowly be adding components to the core integration.

Still at a loss for flame height. Probably a selector is the way to go. But I also like the buttons.

1 Like

And Alexa can control works after exposing the entity so that’s pretty cool.

One suggestion: the flame height sensor seems off by 1 unit compared to the Intellifire remote (at least for mine). In other words, the remote has levels 1 through 5, whereas the sensor reports 0-4. I suppose i could always create a pseudo sensor that just takes the sensor values and adds 1…

So currently I’m reporting the actual value but I don’t see why I can’t change it ….

There is an argument to be made for matching the IntelliFire app

Just want to jump in and say thank you for your work on this integration. I’ve been wanting to integrate my fireplace since I got the wifi module last spring. Can’t wait for the PRs to make it so we can control it.