Just pushed a select option to the repo
Neat. I think eventually some way to just have it as a slider, or a dial that goes 1-5 (ie duplicating the remote) is the way to go, but i’m grateful for what we have here.
Cool - I’ll take a look at this in a bit.
Testing with what’s there now - I’m pretty happy overall. Really just boils down to polishing up the entities that ultimately are exposed.
The underlying library is good - It is already an improvement over the Intellifire app itself.
2 Likes
Pushed another update → added selects for fan/lights which probably fall into the shouldn’t be category … oh well
1 Like
Heh - those have logical entity types!
Yes - the app truly sucks
I loaded the beta version into my build of HA (been developing in a different container).
I’m still seeing some unavailable states coming along but overall it mostly works.
One thing I really haven’t made sense of is sometimes it seems like the local API gets “stuck” or locked up:
So I’ve managed to use the web client: HHT Web Wifi Module Interface - user page
To send a Soft Reset
And things seem to move along more smoothly then.
I’m also wondering if perhaps cloud-commands get “buffered” in a different way… more to explore - but I’m going to either add an option for
- Cloud Sending
- Local Sending
Or maybe have a fall-back mode where if a local command send times out it will go to the cloud… 
I know people are “sensitive” about keeping everything local if possible… and I’d be happy to support that if there was a way to get the API out of the local interface w/out having to hit the cloud.
1 Like
Nice on that Soft Reset find. Using the Intellifire app I’ve had to hard reboot my fireplace to get connectivity back before so it’s nice to know you can recognize this state and issue a reboot.
Ideally all commands are issued locally to remove the cloud hop/latency. But either is fine for me - I just care about stability.
Using Intellifire app I frequently need to force quit or back out to the locations screen and go back into fireplace for commands to work again. I assume that flow must reauthenticate. Your library and integration seems to have solved that.
Agreed that the beta is already more reliable than the app itself. Thanks again for the work here.
Part of me wonders if cloud control might actually be more stable. It seems sometimes the local interface “locks up” but since soft reset seems to be cloud only makes me wonder if the cloud interface is oddly more stable.
App control happens locally after getting tokens from the cloud. So it’s instability should in theory be exactly the same as this integration.
Looks like my last pr went through so I’ll slowly be adding components to the core integration.
Still at a loss for flame height. Probably a selector is the way to go. But I also like the buttons.
1 Like
And Alexa can control works after exposing the entity so that’s pretty cool.
One suggestion: the flame height sensor seems off by 1 unit compared to the Intellifire remote (at least for mine). In other words, the remote has levels 1 through 5, whereas the sensor reports 0-4. I suppose i could always create a pseudo sensor that just takes the sensor values and adds 1…
So currently I’m reporting the actual value but I don’t see why I can’t change it ….
There is an argument to be made for matching the IntelliFire app
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…