That should have been fixed a bit ago… I’ll take a look again today. (May have got removed when I pulled in the new code 
)
I must be doing something wrong. I completely uninstalled Intellifire HACS and re-downloaded and installed. HA logs still state “The custom integration ‘intellifire_hacs’ does not have a version key in the manifest file and was blocked from loading.”
Edit: I also noticed on the GitHub for following progress with core they’ve closed it off for collaborators only. Does that mean the project is dead?
Its not you its me…
I’m juggling a lot of things and noticed my integration isnt working either. I will see if I can fix it now
I see you’ve updated the HACS. I am able to install and see the Intellifire HACS auto discovery. However, I still can’t control the fireplace with cloud control selected. The IP address is still parsed incorrectly and the errors in log are attached.
Edit: The “Visit” link does properly poll the correct IP address and returns correct info.
Okay we have some success!! So the Integration for some reason is not parsing the IP addresses properly and recognizes all 3 of my fireplaces as a single IP address. Only one fireplace has that IP address. But if I configure JUST that fireplace, all the controls work! So it’s very close if you can just figure out to correctly identify and use the IP address for each individual fireplace this integration should be fixed! Let me know if I can help troubleshoot in any way. Thanks!
Check again today… I got my local instance working so hopefully yours will to
What do you mean only 1 fireplace has an IP?
Does that mean only 1 fireplace has the intellifire module?
You should be able to manually enter an IP Address - for fireplaces. (This worked on my dev box which doesn’t have UDP)
I have 3 wireless modules, each with its own separate IP. HA automatic discovery recognizes 3 separate entities, as it should.
Regardless of which module I add/configure, it reads it as the same IP. So if I add the module that actually has that ip it works. But for the other 2 modules that has separate individual ips it incorrectly reads their ip as the only one that works. Doesn’t matter which order I add them.
To be specific, the three modules have IPs of 10.0.1.89, 10.0.1.170 and 10.0.1.248. It doesn’t matter which one I configure, it always reads the IP as 10.0.1.89. That’s what I mean by saying there is a parsing error. And when I am referring to the IP, it’s the value listed under Sensor in the configured entity. Does this all make sense?
Doesn’t matter. If I manually enter any of the 3 IPs it still reports under the Sensor panel that it’s 10.0.1.89. Error in log below.
This error originated from a custom integration.
Logger: intellifire4py.local_api
Source: custom_components/intellifire_hacs/config_flow.py:56
Integration: IntelliFireHacs
First occurred: 7:46:48 AM (2 occurrences)
Last logged: 7:46:48 AM
Instantiating IntelliFireAPILocal without ‘user_id’ parameter will inhibit the ability to control the device.
Instantiating IntelliFireAPILocal without ‘api_key’ parameter will inhibit the ability to control the device.
Update: for the single fireplace (10.0.1.89), HACS integration is working perfectly. Is there something I can do manually to get the other 2 working the same? I hate to bother you but it’s so close to working perfectly. Thanks!
Update 2: If I cut the power to 2 of the fireplaces and only leave on the 1 I really would like to control, deleting and reinstalling the HACS instance correctly recognizes the fireplace. But if I turn ON cloud control, the sensor reads the IP address as 127.0.0.1 and it doesn’t work. If I turn OFF cloud control, it correctly reads the IP address (10.0.1.170) but it doesn’t work. Not sure if that helps troubleshoot. If you don’t want me to bother let me know and I’ll quit being annoying.
Any fix for being unable to change flame height? Seeing an error:
Failed to call service number/set_value. ‘IntelliFireFlameControlEntity’ object has no attribute ‘_attr_name’
Hi Jay,
Are you using the core Intellifire integration or the HACS integration? You might uninstall your fireplace integration and install the HACS integration (much newer). My HACS integration works fine for flame height whereas I could never get the core integration to work for anything! Let us know how you get on!
B
Hey thanks for the reply. I am using the HACS integration. I couldn’t get this to work with core integration either. No worries, will keep investigating!
Flame height I think is still broken in hacs… Basically once I get hacs in a really good state I’ll make a PR into core to move the stuff back there…
@homeontherocks
If you look through
/config/.storage/config.entries - do you see multiple “host” entries for your fireplaces? Or rather do you see 3 separate entires with different host settings? There could be a bug but I only have one fire place so I’m not super sure how to find it.
As for the API Endpoints on the cloud … we could probably diagnose it I think… I’d have to dig up the spec but I think when you interact with the cloud you are going to like fireplace/serial_id/command or something…
Also its totally possible cloud-wise I"m only polling for a single fireplace…
1 Like
I’ve got lots of screenshots for you. Since I power cycled the wireless modules, now I can’t get any of them to work. It reads each fireplace IP as 127.0.0.1 if I have Cloud Control and Cloud Read toggled ON. If I toggle Cloud Control and Cloud Read OFF, it reads the IP of every fireplace as 10.0.1.248, which is the correct IP address for a single fireplace. See attachments and let me know if you want something else. I also could give you remote access to my HA instance if that would make troubleshooting easier. I redacted my username/password.
Edit: Now I’ve also lost Light control - all 3 fireplaces have lights.
Off the top of my head my 1st guess is the way I setup the background polling its maybe only grabbing 1 fireplace. And each time it configures a new one … it overwrites the last one.
Basically I wrote a Cloud and a Local API and I’m going to guess I tied them to a single fireplace. Although the problem might only exist on either the Cloud or the Local.
Looks like this is probably in the HA code - not in the Backing library I’m guessing. If I can swing it I"ll try to get more debugging info into a build and then we can see exactly what its “polling”.
If we see it making 3 separate calls its good… if its just making one call its probably bad 
Also IP Address of Local host sure seems … odd…
If you are using only cloud data It doesn’t actually return the IP Address, however, but I thought it was stored in the integration and should be pulled from there. This could be a left-over bug from me making that change and not propagating it all the way up to the sensor.
It might be easier at some point of us to connect on Discord…
The IP currently only comes from the local API so I’m not overly concerned on that portion. But What I’m more concerned about is whether its actually sending the right Cloud Control messages and Cloud Read Messages
Cloud Read calls the poll() endpoint in intellifire4py library.
I just added two debug statements:
So if you turn on (in HA) debugging for intellifire4py we should at least see that every single Fireplace endpoint (by serial) is being hit.
For the control Messages I think that info is already in there
Actually it looks like some of the stuff is in there twice which is dumb.
However it looks like I actually did cool logging and it is possible it will print out the exact curl command you can run directly from the CLI to issue the same command.
So I guess my suggestion is (assuming this all got pushed to hacs).
- Can we verify its making 3 separate cloud API calls to each of your serial numbers (I think it probably is).
- When we are in Cloud Control and you issue a command can you see in logging what it was trying to do
This might help us out a bit better. If you want to send me your logs you can do so/however … it’s probably safer if you just look over them.
Also if you want to hit me on the HA Discord: jeef.0
The down side is I’m going into a very busy schedule work-wise but I do want to work through this with you.
So hopefully we can get a little more useful information.
Okay I deleted Intellifire HACS, redownloaded and installed. I added each fireplace, first with the 10.0.1.89 that had worked previously. It works! However, when I add the 2 additional fireplaces they successively are added and authenticate but the sensor reading for each is also 10.0.1.89. In addition, the Integration Entries only show 2 entities for one and none for the other (the functioning fireplace has 30 entities). System log for intellifire hacs attached. I apologize for not being very good at this troubleshooting as I’m sure it’s frustrating for you. Thanks!
It looks like unique IDs aren’t being created for each fireplace. If I turn the light on and off every fireplace is able to control the light on the one fireplace that works (10.0.1.89).
Edit: Here is the curl command for one of the 2 non-working fireplaces to toggle the light.
Generated curl command: curl -X POST -H ‘host: iftapi.net’ -H ‘accept: /’ -H ‘accept-encoding: gzip, deflate, br’ -H ‘connection: keep-alive’ -H ‘user-agent: python-httpx/0.25.0’ -H ‘cookie: user=54BEB1CB0C80FFD2E0AD09EC22C686E112589C3FCC2F858B595D59886ACC633A; auth_cookie=7C9F63AB5882B0C99F5E5259405CABF2; web_client_id=656AF2CC75E0213BA3BD666D3E49FBB3’ -H ‘content-length: 7’ --data ‘light=0’ https://iftapi.net/a/49DF2E900CED0A19732F808DBBF8B7A9//apppost
This is the EXACT same command (user, id, auth) as is sent by the fireplace that works (10.0.1.89), as expected since it is controlling the same entity.
