My thoughts since I switched from HA control to control via Hubitat are since activating via Hubitat I have not had one issue, now I do have the newest ECM module but was having issues with it when using HA. The Hubitat code does not query the module as often as the HA code which I think has made the difference.
Automatic polling is active.
5 seconds after ever Hubitat command.
Every 5 minutes while the fireplace is on. Every 15 minutes when fireplace is off.
I have tried this integration dozens of times, hoping core updates would change functionality. I can register fine with my account but none of the controls ever work. If I try to turn the flame on, it just sits for a while and then the slider turns to off. No beep or indication that the module is responding. I’ve rebooted the device as well with no help (that fixes problems between the Intellifire app and the fireplace not working). Hoping someone has some ideas or thoughts what I am doing wrong. I am able to use the web tool to control the fireplace.
Edit: In case anyone else is following this I’ll try to update additional datapoints that might help others troubleshooting. I have just used auto discovery and default configuration settings. The integration is able to see and report sensor data but controls do not work. The HA log reports:
get_challenge returned TimeoutError
I assume this may be an SSL or ApiKey error but don’t see any info on this in the readme. Thanks to Garrett for helping me out so far!
If you use the web tools then when I push the cloud update you can switch to cloud mode. I’ve had lots of trouble with local control and I wrote the thing
I’m waiting on a bunch of parts to get my fireplace back up and running.
Cloud mode needs more tests before it can get merged in and I need more time but functionally when testing before my fireplace blew up it worked well
I’d be happy to help look into this with you. That is very strange that the web tool works but the App does not. Feel free to reach out to me directly, my email is above in a previous post.
I wouldn’t think so, but we are also not routinely testing or working on that functionality at the moment. If you have specific errors you’re seeing and some more context, we could have a look. Please feel free to email me whatever you’re seeing!
Do you know what is causing my get_challenge returned TimeoutError problems with control? All the sensors are working appropriately so it seems I’m erroring out with API key or authentication errors.
I’ve seen this issue many times with my old wifi module. I’m about 2 weeks out for a replacement for a broken fireplace… so hopefully in time I can help out more.
Something I’ve personally seen is the module seems to prioritize cloud traffic over local traffic. I currently have a pull request to get cloud read/control into the next version - but depending when it’s reviewed it could be 2 versions out.
Cloud instance is fairly flaky for more but recently better.
Yes the app works almost every time when the HA integration control does not (please note that the HA integration sensors seem to work fine.
Polling does give all the sensor data.
Awesome! Do you think that will fix my get_challenge returned TimeoutErrors? I’ve always had great sensor data with your excellent integration but have never been able to use controls (ie I can’t turn on the flame or lights or control flame height).
Edit: Sorry brain not engaged. Yes of course cloud control should work fine as that is what the app is using. Looking forward to the next revision to try cloud control!
I have separate code that I had written using C# going against mine before this integration existed and saw the same behavior as the integration. The local API is completely unpredictable. After a period of time the device just completely stops responding. Everything is going along fine and then boom, every request you send will timeout to every API on the device. I suspect it’s a deadlock scenario with whatever webserver is running on the device that triggers pretty easily when it’s connected to the cloud and being polled locally. If there was a local long polling API that would be ideal. Also, if there was a way to obtain the API key locally from the device that would also be fantastic or at least some documentation around when the keys get rotated. I had seen that at least once on my device where the key rotated on me and I had no way of knowing.
I started checking out the UART interface on the device and found the output on the 3 pins on the board appear to be a stream of bytes so it’s unintelligible. That said, probing on the AMW136 directly, putting the RX on pin 19 and 20 yield output. 19 is the RX pin so I assume those are the commands the program is running and pin 20 is the TX pin so I assume that is the result of those commands. I have not found another place on the board to get at those pins yet where I can actually solder in place and go further with investigating yet. It looks like I also need to connect both CTS and RTS to actually get the device to command mode, but so far haven’t been able to send anything to it manually. If anyone else has poked at this I’d be interested in what you’ve found with it.
Have we all really been waiting over 3 weeks for ONE reviewer to sign off on the changes to enable cloud polling? Disappointing if so. Thanks for all your work!