Well I dropped your code into a a C# playground and looks like its correct (matches what I’m seeing when I capture the traffic…) …
I need to figure out how to get python now to do the same thing! Thanks this is awesome
(you should also post your C# on GitHub and we can link the two projects to each other )
I’ll get it up as soon as I can. I was trying to sort out how the API key is generated to try to remove any cloud communication from needing to happen at all before I shelved it a few months ago. Glad your integration surfaced, it’s renewed my interest!
Any chance those three pins in the bottom right are TTL? I’d be curious if you can connect to it and go through a pairing process to see if anything interesting logs on the console. I think the only real remaining piece to complete the integration is being able to figure out how the device authenticates the api key.
I’m unsure about those three pins. I’m afraid that’s beyond my abilities. 
It is interesting that there’s a cutout in the plastic case to access them, though.
I also noticed that 10-pin connector on the front of the board (left of the processor) doesn’t connect to anything when the module is plugged in. It is hidden inside the plastic case.
Anyway, thank you both for your work on this!
Wow - been tracking the git repo over the last few weeks, and there has been tons of progress.
What HA release are you looking to get the control functionality in @jeeftor?
@gibber9583 - probably the next one. Things have been coming along smoothly.
Given how the PR process works I may only be adding one feature per-PR
The main issue I’m currently running into is I haven’t yet figured out how to get the states updated after sending a command… aka:
Also the thermostat option is a little confusing because you can turn “off” the thermostat - but the flame will stay on in “dumb” mode still which is fine - but could be confusing from a GUI point of view … maybe I’ll have turning the thermostat off also turn off the flame…
Perhaps some user feedback could help me figure out if thats the correct path 
… or an option in the GUI maybe
Yeah, totally understand the drawbacks of what you’ve outlined. With the workflow you described - this is exactly how Z-wave switches used to work. Is it ideal? No, but would certainly accept it as a v1 / MVP type solution.
Regarding the thermostat/flame switch - this may simply be a quirk with the module and fireplace set up. I think those who own the module will understand these are independent, but from an outside observer I can see why this would be confusing! If you’ve used the Intellifire app, this is exactly the same. Alternative solution would be to accept the integration as-is, and just build an automation to turn off the flame if it is on when you turn off the thermostat. Again, this is kind of ugly, but working within the way the module works.
The other idea I have which is really hacky - is to try to implement “Flame Height” as a fan controller and then we could probably expose that to Alexa and I could maybe say:
Which would be great because the alternative is writing a custom Alexa skill …
As far as timeline goes I think I need to have this pr merged:
And then I need to make an additional 6 PR’s
switch.py + switch_docs
climate.py + climate_docs
fan.py + fan_docs
So… maybe it will take a little time to get all this stuff through
I highly doubt hacking the device class would make it into HA core but I could be wrong.
For that use case I’d probably just make a script or scene that’s exposed to Alexa. I probably don’t need super granularity for each height / fan speed so 2 or 3 scene/scripts would have me covered.
I didn’t realize you can expose scenes to Alexa… that would definitely solve the issue
Yeah this is one of the use cases I have. Another one being an automation for shutting off thermostat/flame every night - cause some people in my house forget to shut it off before going to bed…
I was thinking of turning off the pilot light between like midnight-4am every day
Also you can string together a huge series of beeps if you want to annoy your spouse 
Cool. Another thing I can add to the list of things that annoy my wife!
I implemented it but I think the default name might have to be changed before it gets merged in…
If anybody is interested I’ll see if there is a way I can publish what I’ve done so far to a custom_component so ya’ll can beta test it. I suspect it will take some time and MANY PRs to get into HA core…
I’m for sure interested, and would happily test.
@gibber9583 - how technical are you?
You think you could just clone my branch and symlink my homeassistant/components/intellifire/ directory into your custom_components (which I think will work).
Or do you need more specific directions?
I need to publish a new version of the python lib before you can do this because I’ve been running the changes locally … but thats extremely easy from my end… just need to actually do it…
I can do that.
However, if I’m not currently using the native integration bundled with core - can I just overwrite what’s currently there with your code?
Ok so the code is “probably” in a good to go state at the moment (aka I’m sure you’ll find lots of bugs!)…
On the downside → I’m not sure how this will work if there is an existing integration for intellifire already… maybe custom will override it - if not you might need to figure that one out.
Repo: https://github.com/jeeftor/core
Branch: intellifire_control
You can probably use these commands to do a sparse checkout which will just extract the code that matters.
FILTER="homeassistant/components/intellifire/"
REPO_DIR="custom_component"
URL="https://github.com/jeeftor/core"
BRANCH="intellifire_control"
# Remove repo dir
rm -rf "$REPO_DIR"
# Init Repo Dir
git init "$REPO_DIR"
cd "$REPO_DIR"
# Add remote
git remote add origin $URL
# Configure sparse checkout logic
git config core.sparsecheckout true
# Pass in filter
echo "$FILTER" >> .git/info/sparse-checkout
# Pull the code
git pull --depth=1 origin intellifire_control
On this page HA says:
To load this, add
hello_state:to yourconfiguration.yamlfile and create a file<config_dir>/custom_components/hello_state/__init__.pywith one of the two codeblocks above to test it locally.
So I think you can probably do the same with my codebase…
Also if you want to turn on debugging add this to your configuration.yaml:
logger:
default: info
logs:
homeassistant.components.intellifire: debug
intellifire4py: debug
Just made a few more updates and things seem to be working much better. Apparently the cloud api and the local api use different keys for some stuff…
so if somebody wants to try stuff out go for it!