Just want to jump in and say thank you for your work on this integration. I’ve been wanting to integrate my fireplace since I got the wifi module last spring. Can’t wait for the PRs to make it so we can control it.
I was going to submit one last night but forgot I need full test coverage for the config flow so it’ll take me a little longer.
First will be the worst cause the city fig logic is shared against all control elements.
Initial Control (SWITCH) PR submitted…
2 Likes
These look good. Here’s to hoping these make it in the next release at minimum.
Custom component version that I have been rocking based on 0.9.6 has been as stable, and likely more stable than the Intellifire app. At this point, the intellifire4py libary is good to go - just curious on how the entities will ultimately manifest themselves within Home Assistant.
Flame Height may need to find itself a new service, but otherwise I’ll live with whatever these land on and just write my automation/UI logic with whats there.
The progress on this project has been super impressive. Nice work
So the PR process is going to be much slower since it really needs to be tiny change after tiny change.
- PR to bump lib to version
0.9.8was approved - Open PR right now for adding
Diagnostic Sensors - Next PR will be some config changes (but that may need a little re-rework to figure out how to use Options Flow)
- Following PR will probably be
Switchentities (Flame/Pilot on/off)
However something I wanted to discuss:
Flame Height Should it be 0-4 (as it is on the device) or 1-5. I’m assuming most people will have a preference here of 1-5 but I wanted to get some discussion going.
I’m thinking about investigating Auto Discovery - however I’d need a bunch of folks to do the following for me. These are the OSX Commands but in two terminals you would start a nc listener:
nc -l -u -k 55555
This will listen on port 55555 which is the auto-discovery response port for the fireplace.
Next you’d use socat (brew install socat) to fire off a discovery packet such as:
echo "IFT-search" | socat - UDP-DATAGRAM:255.255.255.255:3785,broadcast
And then your Netcat instance should give the following response:
{
"mac": "58:8E:81:92:52:7B",
"bssid": "B6:B9:8A:62:3C:E8",
"channel": 3,
"ip": "192.168.1.65",
"ssid": "<MY_SSID>",
"rssi": -40,
"remote_terminal_port": 2000,
"time": 1644953928251,
"version": "AAAAAA-SOMECODE-0.0.0.1, 2019-10-23T20:22:36Z, ZentriOS-W-3.6.3.0",
"uuid": "36413041000000004D0026001251373036363735"
}
What I’m curious about is if everybody’s IFT modules are reporting something like: ZentriOS…
For example I get:
in my router… and if we do have a similar DHCP registration across all the IFT modules might be able to do an auto-discovery in HA which would be pretty cool…
For flame height, I’d prefer 1-5 so it’s consistent with the ugly touch screen remote. 
My wifi module name is reported as “ZentriOS-AC8” according to my router’s app.
1 Like
@aesterling - Based on your info and My own system - and looking at the DHCP stream I think I can enable AutoDiscovery based on the hostname: ZentriOS-* which doesn’t seem to be used elsewhere in Home Assistant. Ugh … so many things to add on my todo list!
New DHCP Request
Host ZentriOS-27B (58:8e:81:92:52:7b) requested 192.168.1.65
---
New DHCP Ack
DHCP Server 192.168.1.1 (08:02:8e:a2:f7:5d) acked 192.168.1.65
DHCP Options: subnet_mask: 255.255.255.0, lease_time: 86400, router: 192.168.1.1, name_server: 192.168.1.1
I have no idea how often DHCP refreshes - may be every 1-2 days but still that will make this integration more widespread as people will see it just auto-enabled by default I think which is cool…
1 Like
Mine is reporting (i think this is the relevant bits):
“version”:“AAAAAA-SOMECODE-0.0.0.1, 2019-10-23T20:22:36Z, ZentriOS-W-3.6.3.0”,
“uuid”:“3641304100000000470064000651373036363939”}
ZENTRIOS-A6C
So in summary Matching DHCP discovery on: ZENTRIOS- seems like a pretty safe bet…
2 Likes
Agreed. Mine reports the same as others
Awesome → I’m in the process of setting up a new dev server to prototype out stuff perhaps better. I’ve been operating on a really wonky machine up until now…
I’m guessing there’ll be a small slowdown in the PRs as its going to take me a bit to get the config_flow updated - and through the PR process. I may drop in DHCP discovery first…
Config Flow Updates → Auto Discover IP of fireplace when you start config flow (I don’t know if this will pass muster with HA… but hopefully it will cause its cool)
Regarding your question about serial connections - its possible you can get some info here if you really want to hack into it? (which could be cool)
https://docs.zentri.com/zentrios/w/3.0/cmd/apps/remote-terminal
So if you get the discovery packet by:
Terminal 1 (listen)
nc -l -u 55555
Terminal 2 (send)
echo "IFT-search" | socat - UDP-DATAGRAM:255.255.255.255:3785,broadcast
it kind of implies the remote terminal is potentially running…
That looks like useful documentation, but once again, beyond my capabilities Thanks for the link, though!
On a separate note, my wifi module keeps showing “offline” in the intellifire app and displays the message, “Error - Your appliance is currently offline.” Then I have to reset it and go through the wifi setup process, it will work for about 24 hours, but the next day the intellifire app will say, “Error - Your appliance is currently offline.”
The customer support reps are very nice but seem to have limited technical knowledge. They sent me a warranty replacement wifi module and it has the same problem as the original. So then I assumed the issue was my wifi and I set up a different router so I could separate the 2.4GHz band, however, the problem is still occurring.
I’m so tired of sliding out the fireplace to press the reset/pilot button, I finally soldered two wires to the reset button’s contacts and installed a second switch on the front of the fireplace so I can press it without moving disassembling everything.
There IS some diagnostic info on one of the endpoints I think → including WIFI stuff… dont have time to look through it now but there is a way to hit the endpoint and see the WIFI strength and stuff … its part of the setup process.
I don’t think I put it in my lib because I assumed I dont need it… 
1 Like
Call them. Hearth and Home had a bad run of mobiles and actually contacted me via email since mine was registered and they replaced it free of charge.
1 Like
Wow … their APP Sucks today … can’t use Alexa or IntelliFire App…
(however - my local control seems to be working great)!!
I’ve completely abandoned the Intellifire app for local control in Home Assistant.
I haven’t set up Alexa yet for it; I’ll likely wait for the integration to be finalized into the release for that.
My automatons have already saved me from someone leaving the unit on over night on multiple occasions.
I’m very happy over here
EDIT: And just last that, I had to hard reboot the wifi module. It became totally unresponsive to control requests from HASS and the Intellifire app. Oddly enough the poll endpoint still works fine to get the current status. I think this is a failure in the module more than anything, not the integration. I need to look into powering via a smart outlet so I can power down/up the device when this happens.