Funny … thats what mine seems to be doing right now 
I wish I had the time but I wonder if somebody could tap into the remote calls with an ESP. I guess they run like ~918 MHz I think
That ultimately might be a better solution… but assuming my unit gets replaced I’ll continue to support the wifi module
Please let me know if you obtain a replacement, the contact I had seems to be an undeliverable email now.
I was hoping my Broadlink RM Pro would work but it only seems to do 433MHz RF, not the 918 MHz like the fireplace remote.
Do you think there would be a way to get fireplace status over RF as the remote does? Or would it only be to “blindly” send commands?
The email address I used for the wifi module warranty replacement is [email protected], however, I had to go through a lot of annoying troubleshooting steps with the agent before they processed my replacement. I’m on my 3rd wifi module now.
Did you buy from a dealer or directly from them?
I bought my Heat’n’Glo fireplace from Fireside Hearth & Home. I think both brands are owned by parent company Hearth & Home Technologies.
For those of you on Homebridge, I’ve taken the fantastic work that @jeeftor has done and ported the basics to a plugin for that. It’s basic now and only really works with the cloud APIs for now, but it works.
Funny → because the cloud APIs is my current WIP … and part of me got the stupid idea it would be fun to rewrite the entire library in RUST as a learning experience … luckily I think i’ll stick to python for now
What I learned from my service call:
Hey all → I’m likely going to introduce some breaking changes soon to the entity naming. For example:
This is a REALLY STUPID NAME:
It says fireplace twice which annoys me.
They sent me the new ECM back in Oct and it definitely improved things. Here are the details on my wifi module. Let me know if your new one is a different PN: thanks
Hearth & Home Technologies
Contains FCC ID: 2ABPY-B5BD9
Contains IC: 11685A-61F8D
DO NOT DISCARD - PLACE ON MANUAL
PN: 2326-137
Wi-Fi: 2.4GHz IEEE 802.11b/g/n
Made in China
Sweet … so I’m submitting the new PR → may “break” a few things if you are using automations.
I’ve now ported everything over to the new naming scheme for Home assistant.
“Uppercase lowercase lower case”
Question for ya’ll … I’m working on getting the cloud code working (which apparently was like 75% written already … so go me).
Unfortunately (in my case) it seems like cloud control/status seems to be slightly more reliable than local control.
I was thinking of having a toggle in the integration options to let you toggle between cloud/local → does that seem like a reasonable way to proceed? The fancy was would of course be to use local control and if it timed out after like 15 seconds jump to cloud … but thats down the line…
FYI, I switched to the Hubitat version based on your code a couple weeks ago to control the unit ( I eliminated HA from my configuration). It’s all local and does not poll the unit that often. So far it’s working perfect, not one hang.
I’d obviously prefer local, but if cloud is more reliable I’d choose that instead. 
It will be switchable … which could be useful in some cases maybe if you have your fireplace on a separate network or VLAN? 
I also added a PR to set the sleep timer which was missing…
Hi all,
I wanted to reach back out here to update everyone on the current status of IntelliFire.
Server
We just finished a project to reduce latency on cloud requests. We previously upgraded to a containerized solution in November of 2022, which was an improvement on stability but unfortunately that stability came at the cost of responsiveness. This is now resolved. Our average cloud response times are less than 500ms at this point. They were previously up to 8 seconds during peak usage of the 2022 holiday season.
ECM (“Electronic Control Module”)
If you get frequent “ECM Offline” error messages, represented by error code “3269” (frequent being considered once or more per week) please get in touch with me at [email protected], we’d like to help. While this is technically a hardware interaction fault, it certainly is associated negatively (and understandably so) to the App itself. The most current production version of the ECM is 2.1.8. Versions 2.1.2 and 2.0.5 are also out there and common. If it has a sticker on it that says “Wi-Fi,” it supports a connection to the WiFi Module and therefore the App.
WFM (“WiFi Module”)
The most current version of the WFM is 0.3.2. The second most current version is 0.3.1. Either of those will work well, the only difference being 0.3.2 resolves an issue occurring during the setup process if the WFM detects more than 30 SSIDs during its scan (uncommon in most cases). We update WFMs during the App onboarding process that are below 0.3.1 (Ex: 0.2.9) to 0.3.1. 0.3.2 is what all new modules leaving our factories are running.
"Appliance Offline" error
This indicates (via error code “642”) that either the WFM received a bad response from the server (Example: a 502) or that the module has actually lost internet connection and is unreachable. The LED status light on the WFM can help decipher the difference (Solid = Connected, Flashing = Not connected). Between 2/1 and 2/22, while doing server deployments associated with the project mentioned above, these may have occurred once to twice a week for you. They clear on their own, but not as quickly as we would like. We hope to address this in a future WFM software version.
Other questions or feedback
I’d like to hear from you. Please get in touch with me using the email above, I check this thread but it is infrequently. Thanks @jackflem1 for the feedback that I should post the above info here.
Garrett, thanks for following up here and providing more details!
@GarrettKranz thanks for the helpful info. Frequency of the Ecm offline error for me has fallen recently to about 2x/week from effectively daily. Don’t know whether that is a result of your good efforts but glad to see ongoing dev here. I’ll follow up with you directly and thanks again.
This is super helpful!!!
My fireplace issues continue … I have my new modules on - order and last night “KABOOM” the arc fault went off and now the fan is broken 
I currently have beta code where I can toggle between cloud and local for both control/read … It seems like sometimes the cloud is more reliable (probably due to the long/poll functionality) - The eventual next release will let you toggle between the two in the configuration menu.
@GarrettKranz - Should I expect better performance for the cloud vs hitting the local /poll /post endpoints?
I know HA people love the local calls … but I’d also like to update the docs to suggest one connection method over the other once I get both released.
