Hey I sure will! I saw there was a new version available today so I pulled it down and updated. Everything is functioning correctly at the moment. I’ll be sure to pull logs if/whennit happens again. Maybe I’m just crazy but does updating the app and rerunning the manager have anything to do with resolving it? I tried rerunning the manager previously and it didn’t fix it. But the last time this happened it started working again after pulling down a new update. Might just be coincidence. Also, just curious what changed in 1.1.2? Thanks!
Sorry for the delay. Life issues.
Yeah, I caught that recently too, finally. That means that you need to soft-reset your wifi module, either by resetting via the iftapi website or by toggling the power of the wifi module. Now that I have this info, I have some ideas on how to get it to try to automatically soft-reset in this situation. I'm planning on working on this over the Xmas break, so hopefully will have something soon.
Still not entirely sure why their remote server can still get a signal through while we can't send it locally. I need to capture the network packets and see if I can make sense of what they're doing, to see if I can keep this local. But not going to worry about that until I get the online soft-reset working first, since I know that will work...
Also, reinstalling the app or manager shouldn't have ANY effect. The issue is usually the fireplace WIFI module just stops talking. 
1.1.1 and 1.1.2 just had a few minor fixes, documented at the top of the files. Nothing that would affect these issues though.
11/29/2023 v1.1.2
- cycleSpeed and restoreFanSpeed were broken due to an int-conversion bug.
11/15/2023 v1.1.1
- Restored setOnOff. It's needed for the Google Home Community integration. Oops.
- Fixed the description text in events.
Yeah I know about life issues. I finally got a chance to power off the fireplace tonight and set it back up.
Much appreciated for your efforts. Was also curious if you’re still following the original developers updates?
Hopefully you’ll be able to get it to auto reset otherwise I may have to get my fireplace company to come out here and help me take the fireplace out so I can install a ZWave controlled outlet so I can power it on and off without killing my entire basement power and everything with it.
I've been following off and on. He's been adding cloud support, but it's not something I've really had much time to add just yet. TBH, was trying to avoid doing that, to keep everything local. He's been having the same lock up issues that we've seen, though he's been hitting it more, which I assumed was due to his hammering of the hardware.
The lockups have happened a bit more frequently this year though, as I only got a couple last year, so not entirely sure what's different. I'm using it a bit more this year, so I suspect there's some internal buffer or incrementer that eventually needs to be reset (since the official Intellifire software only polls while a human is actually looking at the controls).
I may add cloud support at some point, but I don't really have the time for that yet. I still feel like local control should be more reliable, so I really need to start looking more closely at the bits being transferred rather than trusting the APIs others are using. Since the fireplace is local, you should be able to control it fully that way...
Is he adding cloud support to combat the lockups? I agree local would be ideal and better. I’d prefer to not rely on the cloud.
I think he started to support it to be feature-complete (since both are supported). But more recently he's found it to be more reliable and seems to prefer cloud now.
I managed to get my fireplace in a broken local state again today. It looks like an automatic soft reset should work, though there may be a delay on the command when this happens. Trying to reissue the command again might be causing another issue.
Also interestingly, I think there might be a caching problem in Habitat's http system that I need to flush out when this happens. Had to reboot the hub to get it to correctly route to the fireplace again. That's probably going to be a lot of trial and error.
Interestingly, the web interface was completely operational while this was happening. So I'm starting to see the appeal...
Do you have your fireplace setup with a static IP assignment? I do. I’m down with whatever will make this stable and just work. Appreciate your support!
Yes, static IP is required with the current driver. It's not really feasible for the driver to find the fireplace again if the IP changes. Intellifire4py tries to query everything on the server to find it in this situation, but it's a bit noisy if the fireplace is actually offline and there are other devices that use a similar wifi module. I prefer to query the web interface to get the new IP address, but once again not a local solution...
1 Like
tl;dr - Self-healing of local failure state does not appear to be possible. I'm switching to implementing cloud control.
I found my fireplace in a broken ECM state again today and played a bit more with some self-healing strategies (like soft-reset via the cloud interface). Basically, none of them worked, whether it was from the hubitat or from Intellifire's online cloud. What appears to be happening is that the soft reset does clear out the error message, but the fireplace still ignores any commands that change state. The commands succeed (at least the fireplace returns successful HTTP results), but nothing happens. Refresh also still works, but doesn't show any change of state. Eventually, after a minute or less, the ECM OFFLINE error returns. So my original strategy to try to auto-self-reset when in this state isn't going to fix anything.
My logging also showed that the fireplace hit this error state in the middle of the night when not much was happening. Fireplace was polling for refresh updates every 15 minutes. Refreshes were successful, and then they started reflecting an ECM OFFLINE error. So I don't think this has anything to do with what my driver is doing. My guess is that either there's a race condition with a command from Intellifire's cloud that conflicts with my refresh command, or there's some sort of slowly-building garbage state that grows as local commands are executed until the ECM needs to be manually restarted. Either way, not something I can fix via the driver.
So, instead, I'm going to pivot to implementing the ability to send commands through their cloud (like what jeeftor has added). Local control isn't going to go away, but I don't think there's much more I can do with it atm. I already have a working interface for sending the commands to the cloud, but I need to rewrite my authentication code to be smarter (rather than signing in each time) since it'll be much more heavily used. Also, polling is a bit different via the cloud, so that'll take a bit of work too. My intent is that you'll be able to switch between online vs cloud control at any time via a settings switch, so you won't need different drivers.
After that, I want to see if I can figure out exactly how the fireplace is talking to their online servers and see if I can reverse engineer any of that. I doubt that will work, but it might help me understand better how to make local commands more stable. But due to risk, this is much lower priority.
I don't have any ETA on any of this though. Will post an update when I have something new.
Thanks. I appreciate your efforts on this: I too received the ECM offline about two days ago. I haven’t bothered to reset my fireplace power yet. Just using the remote for now.
Looking forward to the new changes and look forward to helping test them out.
1 Like
Quick update:
The good news is that I've got asynchronous long-polling via the cloud working in my test framework on the hub, so that's very promising. Remote commands via cloud are working too. One great thing about that is that status updates on the fireplace will be almost immediate with this change (rather than polling ever minute or so). The functionality has been dropped into the main driver and app (though untested there).
Currently focusing on handling the case when the credential cookies expire (need to log back in and retry the command). Then will need to go through a bug bash before I feel like it might be ready for some beta testing.
The bad news is that my vacation is over after today, so my velocity will slow for a bit. Still going to see how much I can get done in the evenings though. Making faster progress than I expected.
1 Like
Awesome! Thank you!
I have an initial beta version ready for some heavier testing. If you want to try it, read the release notes first, as there's been a bunch of things cleaned up in this version. I've removed and/or relocated some of the cruft that built up, and what's been moved has been documented.
To use Cloud control, first make sure you have your login credentials saved in the Manager app. (There's a new button you can use to add the credentials.) Then go to your fireplace device and change the preference setting. You can toggle back to local the same way.
Local control should still be fully stable (as much as it was before, anyways), so if you have issues with Cloud control, you should just go back to Local. If you do decide to downgrade back to 1.0, make sure you go back to Local BEFORE you try to downgrade your driver, or you may have a poll monitor process still running.
One area that's not great currently is the code that manages what happens when credentials are removed and re-added while the driver is in cloud mode. It's something I'm going to be iterating on, but I recommend not hammering adding and removing credentials too much just yet.
Overall, I really like how much more responsive the cloud control is to state updates. It's been stable for a couple nights now. So I'm interested if you encounter any issues with staying on Cloud and/or switching between Local and cloud. Having debug logs on would be useful.
1 Like
I’ll work on this later today after I get off work. Will keep you posted! Thanks!
One thing I noticed this morning is that some poll events are being received multiple times if multiple status changes occur near a long poll boundary. It will caused events to sometimes flutter (ie, the fan going 0->4->0->4 within about 10 seconds), though the fireplace isn't actually doing that. I can reliably detect it, so I have an idea how to prevent it.
Edit - Fixed in beta.1
FYI... I tried to uninstall the app/drive from HPM before manually installing the latest version...
So I'll manually remove it.
