Closed mlamoure closed 5 years ago
This definitely looks like it could be a bug. I'll be sure to look into it as I add in support for forward/reverse, etc.
I'm not at all familiar with the the HomeKit Buddy so I can't say specifically what's happening with it, but I've found that the behavior of the fans themselves have changed slightly with newer firmware updates. When I first started writing this plugin you could simply listen in on your network's broadcast IP since the fan would broadcast all state changes. But more recently (I don't recall the specific firmware update) the fans no longer blindly broadcast state changes.
Now you have to explicitly open up a TCP connection to the fan and listen on it. If that TCP connection is dropped for any reason and you don't catch it then you need to reestablish that connection to start receiving the state change events again. This can be an issue if the state of the fan has changed between the time the connection was lost and the time you re-establish it as you wouldn't have received notification of any of those state changes.
My plugin attempts to deal with this through the optional timeout setting. If you set the timeout to a non-zero value then if that number of minutes elapses with no event changes received from the fan then the plug-in will close the existing TCP connection and immediately attempt to reconnect. Once it reconnects it explicitly sends a 'DEVICE;ID;GET' command to the fan, and the fan responds with a comprehensive list of its current settings. The plug-in simply updates its own state table with the results of that request.
I wouldn't mind taking a look at your python script. Do you have it here on GitHub?
Thanks for the info.
About my script - I'll comment and clean out the personal details and post it.
Script posted here: https://github.com/mlamoure/indigo-auto-comfort
Thanks for the pointer to your script. I'll take a look at it shortly. In the meantime, this issue with the "state" display should be resolved with this new release.
I've made some adjustments to my script for the improvements you've made. Seems to be working well so far.
Sorry to be a bother lately!
I was wondering if you could advise on this confusing point for me. See my screenshot where a fan is marked "on / on" in the "State" column of Indigo. Also, the speed custom state is set to 1 in the state window below. However, the "fan" state is set to "off". I was assuming that the "fan" state was the equivalent of the Indigo onOffState, is that correct?
I've also seen where the fan is off, but the speed is set to something other than zero.
I have written a fairly extensive python script that takes over the "Auto comfort" feature of the Haiku. I know, I know, why buy such an expensive fan if I'm not going to use the smart features. However, I've found that, because I have access to more sensors and information in Indigo, I can actually do a better job at the auto comfort myself. Happy to share my script if you are interested.
Anyway, I digress... The script attempts to understand if a change to the fan speed has occurred from outside of Indigo (and then goes into a lock period). This way, my script doesn't "fight" the manual changes that we make using the remote or HomeKit. To do this, I compare the previous value that the script executed to the current value of the fan. This gets tripped up when the speed or the fan on/off state is incorrect, which is where I'm having this problem.
I'm also noticing that the HomeKit Buddy plugin is showing incorrect status in the Home app. The fan will be on, but the Home app will show it as off.
Any ideas?