If you look at the example code hopefully it will be useful.
Attempting to run example.py from the module repo, it hung up immediately on -
---- Find Fire Places - Sync Mode (waiting 3 seconds)-----
I commented out the auto discovery parts and set the ip manually in example.py and everything ran as intended.
What happens with auto discovery turned on? Does it crash or throw some bonkers exceptions? Also are you running sync or asynchrony version?
Ha uses the asynchrony code (I’m on my phone pardon the spelling)
I tried both but had to force quit the repl. I let each run about 5 minutes before quitting. I sent you a message with the errors that were generated when quitting.
I just let the async code run for an hour and it never moved past “----- Find Fire Places - Aync Mode (waiting 3 seconds)-----”
I’ll take a look tomorrow about trying to make sure the discovery can time out. Wehapa rhere is an easier way to solve this issue.
Thanks for your help and effort with this integration. It’s the one that really raises the wife acceptance factor for all my smart home stuff.
We’ll figure it out… and now I’m actually in front of a computer and will do some testing…
So what’s confusing me is in the example code:
print(finder.search_fireplace(timeout=3))
You’d think it would actually time out after 3 seconds… if that’s not happening then maybe I did something wrong. I’m thinking if I can get the timeout to work for you, and then push a patch, it will probably work for everybody 
Actually I already found some bugs … like ignoring the actual timeout_in_seconds value in the code.
Additionally → it sounds like might need to add some extra stuff…
And in good news I think I’ve duplicated the lack of timeout on my work system which doesn’t have UDP access…
Pretty sure I tracked down the error…
It’s waiting approximately only 5000 seconds to timeout the socket … 
I’ll try to get a patch soon.
In the mean time if you want to change from
s.settimeout(5000) to s.settimeout(timeout_in_seconds) you could test locally and verify stuff is working…
Btw I opened an issue here for tracking purposes:
I am really interested in having this functionality. I’ve seen reports that the ift-ecm needs to have a WiFi sticker for it to be compatible. I’ve heard that this started being included sometime in 2019. My unit was installed in 2019, and it has a port with a rubber cover labelled WiFi, but alas there is no magic sticker. I’m wondering if this sticker is really a requirement. Why would mine have a port for connecting a WiFi module if it wasn’t compatible? I’ll probably contact the manufacturer although I suspect they will punt me to a local dealer
You have to get the WiFi module and plug it into that port removing the rubber. It’s about 189 - 220 ish I think. A dealer ordered mine for me and I self installed it.
Next month flame height should be released. Just got merged into dev branch today.
Waiting on lights and fixing the udp bug
So the wifi sticker is not a requirement? I’m afraid that mine might have been manufactured when the case was WiFi ready but the electronics weren’t.
I have no idea I got mine in 2020
I got my module from
https://www.northcountryfire.com/ They were great. Call them and they will help you out.
We got our first snowfall here in Minneapolis this week so it’s fireplace season again!
I deleted my old Intellifire integration and tried to re-add it but get this behavior:
When I tried it a second time I got this error instead:
Are these the same issues you were discussing earlier this week? Is there a workaround?
Thanks!
Can I see the logs. Next point release should have an update for discovery.
My guess would be that your udp discovery isn’t. The patch that just got added allows a 12 second (more like 30 when running stuff) timeout and it will prompt for an ip. Hopefully fixes stuff.