Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Push subscription seems to expire after a quantity of hrs #2

Open
t1mb0 opened this issue Dec 3, 2021 · 14 comments
Open

Push subscription seems to expire after a quantity of hrs #2

t1mb0 opened this issue Dec 3, 2021 · 14 comments

Comments

@t1mb0
Copy link

t1mb0 commented Dec 3, 2021

I haven't been able to calculate the exact duration, but if no command is sent from HA to AT4 and everything is idle, after 10-24hrs I stop receiving ITC temperature updates.
As soon as I touch/adjust any parameter in HA, everything comes back to life again for another 10 or so hours.

I've yet to check if during a time HA is not receiving updates, if I make a change within AT4 things come back to life again.

Maybe we need a 6-hourly poll just to ensure things stay active?
[edit]
If the master 'AC' is turned on/off in HA, this does not trigger an update to the ITC states.
A change to a zone is required for updates to start flowing in again.

Screenshot 2021-12-03 092627

@kcd83
Copy link

kcd83 commented May 21, 2022

@t1mb0 you might spot some of these errors in your logs, if I am reading the code correctly

async def _receive(self) -> None:

@t1mb0
Copy link
Author

t1mb0 commented Jun 17, 2022

Rarely see any AT4 errors to be honest, it fails silently - my wifi is rock solid, and it seems to only happen when the system is off (may be a red herring). I have to have an automation setup to change temp or make an adjustment every few mins. Bit of a pain!

I'm unsure how the push mechanism keeps track of an option connection....

@spry-salt
Copy link

I see something similar. I have a NodeRed automation that toggles a rarely used zone on and off every 15 mins. Doing that seems to keep the connection ‘alive’ and triggers updated temperature readings from the ITCs.

@mihailescu2m
Copy link
Owner

I will look into why this happens. The connection should not be idle, since the tablet periodically sends a status update command, so HASS should update automatically when the tablet itself updates its values.

@mcvicthor
Copy link

I am seeing the same issue when no zone is running or the system is OFF.
At that point if I switch the unit to OFF from the console, it is not reflected in HA.

@spry-salt
Copy link

spry-salt commented Jan 28, 2023

@mihailescu2m
I’m still getting it with the system running and with regular pings from the HA VM to the tablet, and using ModeRed to reload the AirTouch integration every half hour.

eg I just tried to switch a zone on and nothing happened on the first tap except ‘Connection error in receiver!’ Log entry.

Edit: After months of trying to work out the cause I think it might be that the AirTouch tablet kept switching between nodes on the router mesh. Every time it switched HA lost the connection. I’ve locked it to its own wifi network on the main router now. Fingers crossed.

@kcd83
Copy link

kcd83 commented Jan 28, 2023

Very curious to hear if that works. I have always suspected there is a gap in the connection dead detection/retry logic

This integration never lasts more than a day for me. I use the other Airtouch4 one in parallel which always stays connected. I tried diving into the by code but ran out of time

@spry-salt
Copy link

spry-salt commented Jan 28, 2023

Some evidence... if I interrupt the wifi network (eg to change a setting) even though the AT tablet reconnects when the network is back up the integration doesn't reconnect to the AT tablet and it gives the error message when you next try to change any setting on the AT from HA.

Edit: Same if I reboot the AT tablet. HA gives usual error message if you then try to change a zone, for example, but reloading the integration causes it to find the tablet again.

@MinimalMule
Copy link

I seem to be getting the same problem:

This error originated from a custom integration.

Logger: custom_components.polyaire.airtouch4
Source: custom_components/polyaire/airtouch4.py:180
Integration: AirTouch 4 (PUSH) (documentation, issues)
First occurred: April 11, 2023 at 6:30:00 AM (3 occurrences)
Last logged: 5:47:54 PM

Connection error in receiver!

@spry-salt
Copy link

spry-salt commented Dec 28, 2023

@mihailescu2m
This might be the reason behind the problem we’ve been seeing but I don’t know how to fix it.
https://forums.whirlpool.net.au/thread/3qqplnz3?p=16#r73690731

@MinimalMule
Copy link

@mihailescu2m

This might be the reason behind the problem we’ve been seeing but I don’t know how to fix it.

https://forums.whirlpool.net.au/thread/3qqplnz3?p=16#r73690731

Could probably check if that's the cause by implementing an automation that triggers every 5 seconds and just bumps the setpoint in one room up and down by one degree (if you have a room which rarely has aircon switched on) - just to narrow down if that's the real cause. I suspect it's not the root cause as the post says that the change was made in October 2023, and we've been having these issues since well before then

@spry-salt
Copy link

I've set that up now, starting with every 15 minutes.

@spry-salt
Copy link

Dropped it back to every 5 minutes as it was still a bit unreliable at 15 and 10 minute intervals, although I haven't yet ruled out some other variables.

There's some interesting information in this forum discussing AirTouch 5. It's relevant to me because the supplier replaced the original AirTouch 4 tablet with an AirTouch 5 one so I thought it might be useful to others:
https://community.home-assistant.io/t/airtouch-5-integration-aus/451465/261

@spry-salt
Copy link

OK even at 5 minute intervals it frequently drops the connection and gives "Connection error in receiver!" So that's 90 times in the last 19 hours. I give up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants