Invalid Lennox E30 pairing flow via HomeKit controller #20885
Comments
jeromelaban
changed the title
|
Hi - thanks for raising this. Good work :-) You'll be pleased to know that I think most of this is known and being worked on but there isn't an ETA yet. The pairing bug is already tracked here. There is a branch with a very similar hack here and the upstream bug for async pairing is here. There is already a bug for C# (#17853). I haven't commented yet but my local branch should no longer choke on that. The main work right now is to port homekit_controller from Configurator to ConfigEntries. It's quite a large change so it's probably going to have to be split up and sent through the HA review process in stages. Are there any errors when setting the temperature etc? If you can send me the output of: That would be super helpful. |
|
My pleasure! Good work on this component! When setting the temperature from HA, there are no errors in the log, the thermostat value does not change, and the value in HA is reset to the actual thermostat value after a while. Which logger should I enable to see the errors, if any ? Here's the accessories result: [
{
"aid": 1,
"services": [
{
"characteristics": [
{
"format": "bool",
"iid": 2,
"perms": [
"pw"
],
"type": "14"
},
{
"format": "string",
"iid": 3,
"perms": [
"pr"
],
"type": "20",
"value": "Lennox"
},
{
"format": "string",
"iid": 4,
"perms": [
"pr"
],
"type": "21",
"value": "E30 2B"
},
{
"format": "string",
"iid": 5,
"perms": [
"pr"
],
"type": "23",
"value": "Lennox"
},
{
"format": "string",
"iid": 6,
"perms": [
"pr"
],
"type": "30",
"value": "XXXXXXXX"
},
{
"format": "string",
"iid": 7,
"perms": [
"pr"
],
"type": "52",
"value": "3.40.XX"
},
{
"format": "string",
"iid": 8,
"perms": [
"pr"
],
"type": "53",
"value": "3.0.XX"
}
],
"iid": 1,
"type": "3E"
},
{
"characteristics": [
{
"format": "uint8",
"iid": 101,
"maxValue": 2,
"minStep": 1,
"minValue": 0,
"perms": [
"pr",
"ev"
],
"type": "F",
"value": 1
},
{
"format": "uint8",
"iid": 102,
"maxValue": 3,
"minStep": 1,
"minValue": 0,
"perms": [
"pr",
"pw",
"ev"
],
"type": "33",
"value": 3
},
{
"format": "float",
"iid": 103,
"maxValue": 100,
"minStep": 0.1,
"minValue": 0,
"perms": [
"pr",
"ev"
],
"type": "11",
"unit": "celsius",
"value": 20.5
},
{
"format": "float",
"iid": 104,
"maxValue": 32,
"minStep": 0.5,
"minValue": 4.5,
"perms": [
"pr",
"pw",
"ev"
],
"type": "35",
"unit": "celsius",
"value": 21
},
{
"format": "uint8",
"iid": 105,
"maxValue": 1,
"minStep": 1,
"minValue": 0,
"perms": [
"pr",
"pw",
"ev"
],
"type": "36",
"value": 0
},
{
"format": "float",
"iid": 106,
"maxValue": 37,
"minStep": 0.5,
"minValue": 16,
"perms": [
"pr",
"pw",
"ev"
],
"type": "D",
"unit": "celsius",
"value": 29.5
},
{
"format": "float",
"iid": 107,
"maxValue": 100,
"minStep": 1,
"minValue": 0,
"perms": [
"pr",
"ev"
],
"type": "10",
"unit": "percentage",
"value": 34
},
{
"format": "float",
"iid": 108,
"maxValue": 32,
"minStep": 0.5,
"minValue": 4.5,
"perms": [
"pr",
"pw",
"ev"
],
"type": "12",
"unit": "celsius",
"value": 21
}
],
"iid": 100,
"primary": true,
"type": "4A"
}
]
}
]
|
|
My gut feeling is that if you don't see any tracebacks in the logs with the default config then its probably the accessory rejecting the change, and we aren't logging it. If you are comfortable editing the code then track down this line of code in your environment and print the output: |
|
I added this: which said this: Which could mean this, if I'm not mistaken: https://github.com/jlusiardi/homekit_python/blob/88b40a9a64a1a897f3751c07c48e117472b92d3a/homekit/controller.py#L458 I'll put some logs deeper to see what happens. |
|
Also interesting, if I do this: the temperature changes properly on the thermostat. |
|
Ok, gut feeling one disproved. Dang. You are correct, it looks like there are no errors. I guess we should also log the value of |
|
Have an Lennox iComfort S30 which currently lacks any HA integration, and am just commenting here to track progress with Homekit integration. Thanks very much for all the work done on this so far! |
|
I have two S30s, one controls four zones, the other just one. Wanted interested parties to know I'd be happy to test any Home Assistant / Homekit integration work involving these thermostats. |
|
I'm getting a similar error when I try to pair my Hunter Douglas PowerView Hub via HomeKit controller in |
|
@niemyjski - a |
|
I did not have an existing pairing but I'm going to go and reboot the hub
and try again.
… |
|
I meant the device thinks you were already trying to pair it, then started to pair it a second time. Which is subtly different to it already being paired. |
|
For those of you who have paired manually (like @jeromelaban), 0.93 should fix a bunch more issues that were mentioned on this ticket. This includes correctly populating (@jeromelaban i would appreciate an update on how this looks on your end). The main config flow work is now on There are some other changes pending:
|
|
I really appreciate you updating us on the progress! I've been following the PR, but have held off attempting a manual sync. Sure hope the Lennox S30 isn't one to have "device specific quirks" and will pair successfully with the .94 update. |
|
The first 0.94 beta has just been tagged while i was asleep (about 8 hours ago). This includes:
This is still beta so there is still time to fix any surprise gotchas. This is obviously quite a big set of changes so if anyone can run the beta and let me know how they get on please do. |
|
0.94 is out now - so would be great if you guys could let me know if you could now pair your Lennox E30's. |
|
I certainly plan to! My E-30 is installed at my lake house, so I hope to get up there soon. Area flooding/road access is a bit of mess right now. EDIT: I meant my S30. Same thing really from the interface perspective. |
|
Are S30's included? If so, I can test when I return home. |
|
@garyak It depends! I don't have a ticket about S30 in particular, so I don't know why its not already working. If its just that the S30 has random pairing codes which it shows on a display, then you should test it with 0.94 as the issues around that should be fixed now. |
|
Yep - the Lennox iComfort S30/E30/M30 all have displays that upon pairing, display a random code. There is another separate iComfort Wifi model with a different API that has its own component and doesn't require Homekit. |
|
OK. I'll test the S30's and report the results. |
|
@Jc2k thanks for the update! I tried the pairing (reset the E30 completely). it fails and this is what I'm getting: Each new pairing attempt shows the The E30 itself thinks it's paired, though, so the flow works properly from the devices standpoint. Keep up the good work! |
|
@jeromelaban can you take a copy of your .homekit directory, then delete it (or just move it to the side? Then reset the E30 and restart HA. What happens now? I suspect the old pairing.json is involved somehow. |
|
@Jc2k that's the first thing I tried, but it did not help, |
|
Yeah with config entries that folder is no more, woo. So I’m guessing you attempted to pair twice (or at least submitted twice) and that’s where the AlreadyPairedError comes from. But why the first call to /accessories is failing is a bit of a mystery right now. |
|
Excellent news, I'll poke somewhere else then. The error message happened on the first try, and the ID changed every time. Where can I find those new entries ? Also, I'll try to find out about that invalid document, will let you know. |
|
I finally made it up the the lakehouse and am now trying to pair the Lennox S30. I must be missing something since I never get a pairing code prompt in HA. All I've added to the configuration is zeroconf: (I had discovery/enable/homekit initially per the docs, but the log said it wasn't needed). I enter WAC mode on the S30 and then at some point I should expect to see a prompt for code in the HA notifications? I did try to manually add the Homekit Accessory Integration via the UI, but it said "aborted, no unpaired devices found" - and this was while the S30 was in WAC mode. The HASSIO/Raspi is Ethernet connected, and on the same subnet as the S30, not on wifi, but there shouldn't be any network isolation between the two. Does this WAC mode pairing require Hassio be on wifi too? |
|
@GaryOkie I can’t give specific instructions because every device is different - here I’m struggling a bit because I’ve never even heard of WAC mode before. Home Assistant is looking for an mdns record of type _hap._tcp.local. If it can’t see that it won’t work. My HA is a VM with the host connected by Ethernet, and it can see WiFi homekit devices just fine. The only gotcha is if you have seperate subnets then mdns records are not visible across subnets without a reflector. But as you say this shouldn’t be a problem for you. Can you run python3 -m homekit.discover on the machine or container where hass is? Do you have a iPhone and can that see your device? Is it definitely pingable from the hass machine? |
|
Ok @Jc2k - will do. As I had mentioned, the only code changes other than the logging was I kept the import time; time.sleep(10) delay in ip_implementation. I had already removed all the logging but I will remove the sleep as well and reset/repeat the pairing. back soon with an update... |
|
Good news @Jc2k - using production code, I was able to repeat the pairing process 3 times with no problems at all! |
|
That is wonderful news indeed :-) |
|
It is working for me as well, paired on the first try! Thank you very much :) |
|
Would someone with an iComfort S30/M30/E30 please temporarily enable the "wider temperature setpoints" (under settings/heat&cool)? This will change the allowed range from 60-90 to 40-99 (F). What is being reported to HA via the Homekit integration is an incorrect min_temp=60, instead of 40. The max_temp is correct at 99. I'm unable to set the temp lower than 60 via HA, but it works fine via the thermostat touchpad or iComfort app. Can this min_temp reporting problem be duplicated by anyone? Thanks! |
|
With wider set points set on the S30, HA reports min 40, max 90. Unfortunately these settings, when made from HA, don't reflect back to the S30. The lovelace card returns to 60 degrees, or 40 depending on your setting at the S30. |
|
Thanks @garyak for testing. Your reported wide min/max setpoint range is different I am seeing and I think that may be because my Tstat was in cool mode and yours was in Heat mode. The default range is 60-90 and the optional wider range is 40-99. I don't think it is correct to have either a 40-90 or 60-99 range reported, regardless of which mode the Tstat is in. @Jc2k - I have the original debug GET_Accessories output from when the S30 first paired and have compared it to the homekit_controller-entity-map pairing file, and both agree. There appear to be two relevant Homekit IID's pertaining to temperature range... I have since switched from Cool to Heat mode since the pairing was done, but the range has not changed for me - it is still 60-99. Problem is, I need to remotely lower the temp below 60 for an empty vacation cabin that is winterized and can't do it via HA/Homekit, only via the iComfort app which properly honors the wider setpoint range of 40-99. Formatted debug output follows: And a snip from the pairing file... And finally, HA climate.icomfort_s30 entity state:
|
|
After restarting HA while the S30 is in Heat mode, I am now getting a min/max range of 40-90, the same as @garyak. I'll just have to remember to restart HA any time the mode is changed to get the new range. Not sure why, but I can live with that. Evidently Lennox hardcoded their Homekit interface to use the 40-90F min/max range for Heat, and 60-99F for Cool. The option to enable a wider setpoint range regardless of mode is not honored by the Homekit interface and seems to be only relevant for the Tstat and iComfort app the best I can tell. LOL - I switched back to Cool mode, restarted, and the range is still 40-90. Oh well, that range is fine, even though it beats me how/when this Homekit component refreshes attributes. |
|
So what is supposed to happen is the thermostat bumps the c# attribute whenever the attribute database changes. This is broadcast by bonjour and HA should see it and pull the latest "entity map". Could be the comfort is always updating the attributes but not always updating c# in a timely fashion or we aren't noticing. You could use the CLI to see if c# is changing. If it's not, theres not much i can do their implementation is buggy. If it is, its my problem to sort out (:sob:). RE: The 2 UUID's you posted - they are the cooling and heating thresholds and are apparently only applicable to Auto mode. We don't support them yet, mostly because i don't have a way to test what happens. |
|
Thanks for the info! I have checked the timestamp of .storage/homekit_controller-entity-map and noticed that it doesn't change when I change heat/cool modes or temp values from either the HA UI or the iComfort app. It also doesn't change after an HA restart. So what is this CLI you mention and how do I use it to see if c# is changing? I know of C#, the programming language, but not the "c#" you are referring to. Do you have a documentation link that describes the UUID's? I've tried, but not found one yet. Still don't understand where HA is getting the temperature ranges from if 106/108 only apply to Auto mode that isn't supported by the component. And since it's not supported, why is "Heat_Cool" being reported as an available mode and show up as a button on the climate card? Isn't that Auto mode? EDIT: On second thought, by "CLI", you mean the SSH/Bash terminal into HA? |
|
The cli ships with the library we use to make the HA integration: https://github.com/jlusiardi/homekit_python/ It should be already installed in your HA install so it should be enough to do something like: python3 -m homekit.discoverAnd after about 30s you should see output like this: (This is the data that we use to detect the devices available to pair) |
|
bash-5.0# python3 -m homekit.discover EDIT: Ah, just now see the c# number! |
|
:-) As it is currently 2 it seems it does not change when you change between heat and cool. But you should be able to change settings on the thermostat and verify. As for the UUID documentation, you can download the official spec here: https://developer.apple.com/homekit/specification/ You'll need an Apple ID but i don't think you need to be in the paid for developer program or anything like that. For the 2 you called out it says: and There are 2 key things in these that have made me reluctant to press ahead with making arbritary changes:
Clearly in some cases we need to respect these characteristics and in others we need to respect the target temperature characteristic (like we do now). But IMO it is vague and it doesn't say it is OK to refer to these threshold characteristics when not using the "auto" ("heat_cool") mode. I would say it implied that you shouldn't But it doesn't explicitly ban that either. My hope is that if the characteristic is present we should just use it for all relevant modes over the "target temperature" one. Ultimately i'm going to have to build a mock thermostat accessory and verify which characteristics are surfaced in the iPhone UI in which circumstances - but thats a lot more work than i have time to do right now. |
|
@GaryOkie are you able to modify temperature settings from HA? All I can do is On/Off and change modes. HA Current temp and Humidity values accurately reflect thermostat readings. |
|
Hi @garyak - Yes, I'm able to modify temps from HA - at least according to the iComfort app which updates within several seconds of any HA change. I'm not at the remote S30 site to see it first hand, but the iComfort app must be showing the actual status. |
|
@Jc2k - thanks for providing the link to the Apple Homekit docs. I see in the official doc, that Current Temperature (IID 103) has an Apple-defined min/max range of 0-100 C, and this is exactly the characteristic that is being reported by the S30 and recorded in the pairing file.
Clearly Lennox hardcoded their min/max temp range to match the spec rather than pass the normal min/max ranges set on the thermostat. But why is the Homekit controller component ignoring the current temp range 0-100C and picking up the hardcoded trigger point ranges for the Auto Heat or sometimes Auto Cool instead? This wouldn't be an issue for me except when the component sometimes decides to set the minimum heat to 60F. EDIT - my apologies... I should have looked at TARGET Temperature (IID 104), not current temp. I see now the Apple-defined min/max range is 10-38C. The S30 originally passed a range of 15.5-37C (60-99F). However, I see that the S30 Heat state remains at min_temp: 40F and max_temp: 90F. (But that may be because I have changed from cool to heat mode).
|
|
Your edit is correct, we are currently using the target temperature min and max values. My next step is to make a mock thermostat with homekit_python which has the target temperature, heating threshold and cooling threshold characteristics. I will give each of the 3 different min and max values. Will then pair with an iOS device and see which of the 3 min/max ranges it uses in each of the 3 operating modes. Hopefully this will show that iOS prefers the heating and cooling thresholds if they are present, regardless of operating mode. This will mean that we have a way forward. If it shows my narrow interpration of the spec holds, and that the heating and cooling thresholds are only for heat_cool mode (i.e. auto mode) then we are somewhat stuck. I could potentially add a "force reload" service for the characteristics database. But I don't want to dwell on this until we have been able to verify the "nice fix" is a no go. In the mean time if you delete your homekit_controller-entity-map and restart HA it should fetch the latest one. You could verify this does cause the target temperature to update (without a change to c#). Worth taking a copy just in case it doesn't, i guess. |
|
That sounds great @Jc2k as a potential way forward! I am quite happy with the functionality I now have and greatly appreciate all the attention you have been giving to improve this component. @garyak - I don't use the Auto (Heat/Cool) mode, but I'll do some testing with it. EDIT: I see what you mean now - there isn't any way I've found to set the separate heat setpoint and the cool setpoint for heat/cool mode. I currently use the simple-thermostat lovelace card, but it has the same limitation as the official thermostat card. Even though both provide a heat/cool button, there is only a single setpoint. Now, there is a dual-thermostat card that has a nice dual setpoint capability, and it works just like the iComfort app round slider. I tried using it, but it seems to require two separate entities for heat and cool. Giving it the same S30 entity for both heat/cool didn't work. This has to be a common issue, but I haven't found a solution yet. |
|
I can also confirm successful pairings and retrieval of the accessory list after updating the homekit firmware on the S30 on HA release code. |
|
Shouldn't it be possible to set the hvac_action attribute as IDLE, instead of OFF, when the HVAC unit is not actually turned off? |
|
Another question. Are the Fan settings exposed by the API? |
|
Nope, looking through the Apple Homekit HAP R2 non-commercial spec, there are no references to Fan settings or status for the Thermostat accessory. |
|
Do without I guess. Thanks for checking. |
|
@Jc2k - The "Target Heating/Cooling State" of 0=OFF is what is used to turn off the unit (hvac_mode). I don't see any other setting that can indicate if the unit is actually off, but it would probably be best to set hvac_action to off based on this target 0 value. |
|
We should probably take any new issues to new tickets from now on guys, the pairing issue is resolved by the firmware (no one has said otherwise yet) and i'm going to lose track of what else is and isn't resolved. (Feel free to @ me directly for homekit stuff). I think you are probably right about this @GaryOkie. I don't have any spare cycles right now but if you were to submit a PR to update the mapping here i would be able to review it. I'm fine with simply replacing |
|
Thanks - I've only done a PR on documentation before, not yet for code, but will give it a shot if it's just a simple matter of remapping. The most important thing is to define hvac_action as idle (or heating, or cooling) when the unit is on, and off otherwise. The thermostat operation state is working properly and shows off, when the unit is off, and heat/cool/heat_cool when on. EDIT: Another thermostat component I tried returned Hvac_action to Idle (not off) when the system was turned off. So yeah, this simple remapping of 0=CURRENT_HVAC_IDLE should suffice. And I agree - this original E30 pairing issue should be closed, with the advice that the latest firmware needs to be installed. |
|
I'm going to close this because pairing now seems to be working. If you are waiting for support the temperature ranges in heat/cool mode, you can track this ticket. Cheers |
Home Assistant release with the issue:
0.87.0
Last working Home Assistant release (if known):
None
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
Homekit controller
Description of problem:
Here's the "normal" flow for pairing a Lennox E30 to home kit:
Pairing a Lennox E30 with home-assistant using the HomeKit Controler does not work properly, for two reasons:
homekit_pythonHA component does not handle properly the fact the thec#attribute is exposed asC#by the Lennox E30, making home-assistant fail for a case sensitive lookup here:https://github.com/home-assistant/home-assistant/blob/d16d14b648b00ffe97c10180472fd004a131c99c/homeassistant/components/homekit_controller/__init__.py#L353
Changing this line with an upper case
C#makes thehomekit_controllerdiscover the Lennox E30 properly, and show the pairing dialog in the HA UI. This is obviously not a proper fix, but maybehomekit_pythonshould sanitize this attribute?Tracking down the issue in homekit_python, I could create a manual pairing by adding:
at this line:
https://github.com/jlusiardi/homekit_python/blob/9604d76131a9955c8b4dbd9f10dc92394cc61ae3/homekit/protocol/__init__.py#L102
and run it as CLI:
Blocking the pairing procedure to input the pin at the precise moment (after step 3, the verify request) during the negotiation makes the pairing code appear and stay visible long enough on the Lennox E30 screen to be able to input it at the CLI.
I've yet to be able to reuse the pairing file in home-assistant, and I'm not sure either how to create such an asynchronous flow using the HA UI.
Update 2019-02-09: I was able to reuse in HA the pairing I made using my modified CLI of homekit_python. The name of the pairing has to be the device ID
XX:XX:XX:XX:XX:XX(AccessoryPairingID value in the pairing file). I'm only able to see the temperature, modes are not available and setting the temperature does not seem to have any actual effect.The text was updated successfully, but these errors were encountered: