Short answer yes - long answer → I don’t really have much time to work on stuff as-is. Additionally I dont want my local dev code to diverge too far from the HA baseline because of the PR structure only little chunks can get added at a time … and I’ve already had to refactor working code into something half-useful to get it into HA.
Once I get the config flow updated I’ll probably do everything else and push it maybe to HACS because at that point the PR’s are really easy to put together.
What I’m really looking forward to is getting the DHCP auto discovery in because then random people who aren’t following this thread will suddenly find their fireplace can be used
I’m not using the official integration, and I imagine a few people here aren’t either! So you can probably bump that by at least 50% (percentages sound far more impressive in this case )
Note there is an issue where the module becomes totally unresponsive to control requests, But still provides the current status. This seems to happen on mine about every 5~10 days or so. I have a smart switch controlling the power so will automate to solve this issue. I have worked with them on this but no resolution yet.
I just reset mine at the wall tonight - very annoying - however - in some cases when the app stops working it appears that the local control commands still work - which is VERY interesting.
My Error handling PR just got approved today so I look forward to tracking error status with the official integration which I’m oddly enough running…
Upcoming PR Flow:
UDP Autodiscovery (nearly finished)
DHCP Discovery (waiting on previous one)
API Configuration - this is the big one that I have to do before the following can happen:
Thanks for sticking with the HA process to get control working. Their requirements for PRs are a high bar and probably keeps some developers away. I’m waiting for this integration with control more than a full release of HA. Unfortunate that cold season will probably be over by the time it is all included in a release. A HACS release would be awesome but I just want ti say again I appreciate the work you’re doing.
This is the error I get in the Intellifire iOS app nearly every day, but I’m still able to ping the device when it shows this. If I load the IP address in my web browser it displays, “ok.”
I have to hold down the “pilot” button to reset the wifi module on the fireplace and then go through the wifi setup again to get it working in the Intellifire app. It usually works for about a day, then shows offline.
@jackflem1 and @jeeftor is this the behavior you’re seeing? The manufacturer says they only have reports of it from iOS users but not Android users.
I’ve been calling and emailing Hearth & Home Technologies since January about this. I received this reply by email from them this morning:
Good morning,
Thank you for your message. Currently, we do not have a fix for this error. We are aware of the issue, specific to iOS phones being ‘offline’. It is something our engineers are working on and we hope to have a resolution in the future.
Kind regards, Tami P.
@jeeftor did you ever get an email from the dev team? Do you think it’s worth continuing to request some kind of local network control? The phone reps don’t seem very interested in anything beyond their troubleshooting checklists.
I don’t get that error in the App when mine hangs, the App just not turn the fireplace on. I have a power switch on my fireplace so I just power off and then on. That resets the unit and everything is ok. No module reconfiguration required. I reset mine last on Sunday morning and it worked until this morning. It usually is ok for several days before it hangs again. When it’s hung it will respond to ping with OK.
I NEVER GOT an email from the dev team → I’m going to call back at some point - and maybe give them my work email → I feel like gmail is just filtering random stuff out.
I also get that error about once to twice a week - and when it happens Alexa also doesn’t work … HOWEVER … I hit the /poll endpoint and I can see an error status which translates to ECM OFFLINE (3xxx) (forgot the error code off hand).
I think local control, however, still (sometimes) works → if somebody who DOES have dev team email wants to point them to this thread and/or have them email me I have some ideas.
Otherwise when I get a chance I’ll call back and give them my work email.
So the next release of HA should have the error code stuff in there… I’d really like to see a graph of uptime and error codes over a week or so in HA to see if there is a pattern or something.
In some cases when things have “stopped” working - but the fireplace can still be seen by iftapi.net I’ve issued a soft reset and it seems to have helped out.
Local control is in the pipeline. I’ve released a beta version (which you can find directions up above in the code). Unfortunately I don’t have enough time to roll stuff into HACS mostly because I’m really trying to get this integration into HomeAssistant Core - and I don’t want to diverge too much for the HACS version. My fear is that control might not be ready until next years FIRE PLACE season - however since I’m in Colorado I have at least a few more worthy months of fireplace season
The main hold up at this point honestly is that the PR process is VERY involved - which is why HA is great software. The current feature I’m working on is an auto-discovery mechanism so when you add the integration it will auto-discover fireplaces. This adds to a lot of edge cases I need to deal with.
After that I’ll be adding DHCP auto-discovery - so a bunch of people who have fireplaces and don’t realize its part of HA will suddenly see it show up as an option.
After that I’ll be adding in the configuration data to support Local/Cloud control - and once that gets merged in control will finally be added.
Control options that have been implemented thus far:
Fan Speed
Flame Height
Thermostat Mode
ToDo:
Light Settings
Countdown Timer
And if you are so inclined - here is my page:
Additionally - some of us seem to have made some inroads with the tech team writing the IntelliFire module - so I’m hoping they can help out with any remaining questions.
I can guarantee by next Winter (unless you are in the souther hemisphere) this will be a Kick-Ass integration!
That’s great! Are you referring to HTT dev Justin?
With their cooperation, do you think we’ll be able to get full local control and communication as we hoped? Does it simplify any of the work you’ve done so far?
Are the Intellifire app problems we’ve been seeing due to IFT server communication issues, or is there still a reliability issue with the local wifi module? (requiring a hard reboot?)
My Intellifire app was again reporting the appliance “offline” this morning. I held the pilot button and went through the wifi pairing process to get it working. Now, a few hours later, the Intellifire app is reporting the appliance offline again.
Regarding Local Control - The only issue stopping local control is the speed at which I can get PRs accepted to Home Assistant. Like I’ve said → I have had local control working - however because I’m making this a core integration it is going to be a slow process. Some folks here are running a custom build of my integration where local control IS WORKING - so at this point we really don’t need any interactions between us and HTT to get that functionality built out.
Something I’m interested in is whether the fireplace can be used entirely w/out any cloud access whatsoever. Currently you need to retrieve an APIKEY and maybe a user_id from the cloud - but that is it. After that you can do everything locally.
What I’m debating for my integration is whether I should cache those values locally in HA - or whether to retrieve them from the cloud at startup (which is what I’m doing now) - and then only again at a reboot or reinitialization of the API. I don’t know if these keys change or expire or anything so in many ways its easier to pull it remotely.
Debugging IFT Issues/Errors
And regarding what happened today with the server - I was in communications with Justin when I saw the server was down. I emailed him and he rebooted it which caused something interesting.
My iOS app reported the fireplace offline
The IFTAPI WebPage reported my fireplace offline
IFT Module was NOT reporting any error codes
Local control (via intellifire4Py) was working fine
He asked if I was able to check the LED status which I could not on the IFT module - but it looks like on their end there is a bigger bug than they expected. They were under the impression a server-restart wouldn’t impact the IFT modules - but it appears this isn’t the case. Apparently there is a 24 hr reset on the module which may have cleared the error up but I couldn’t wait that long so I hard-rebooted (at the plug) and everything went back to normal.
While this is helpful - the fact that there is a bigger server side bug and Intellifire4py was still working may cause them concern. I’m worried they may push some update that kills our fun
I can’t imagine local control going away - they’d have to rewrite both their iOS and Android Apps as I’m basically copying what they are doing. Also from my interactions with Justin at HHT they seemed pretty upbeat on what I’ve done thus far → especially if it offers them some debugging info.
I guess the potential problem is when the business folks and the computer folks don’t disagree… but on the other hand → most business folks understand the impact a user community can have on a product.
Their CEO is on vacation or something at the moment but I’m pretty sure we’ll get some attention once he’s back. I asked if they wanted to help make this an official capability of IntelliFire → because if its minimal effort on their part - it might lead to some sales or something like free advertising from HUGE NERDS like ya’ll…
Honestly a factor in picking my fireplace was them having a wifi module available…
May have closed out another PR tonight - but we’ll see if it finally gets through
Upcoming additions will be:
DHCP Auto Discovery (easy PR)
API Authenticaiton/Configuration (more complex and hopefully won’t take 20 some odd days like the current PR I have in the pipeline)