Same thing this morning, NodeRed showed all nodes had fired but the HA log showed ‘Connection error in receiver.’ When I manually fired that flow half an hour later everything worked fine.
What I had done was turn on NodeRed’s ping function that tries to keep the connection to the HA server more alive and disable my hourly tweaking of an AC zone to try to keep the AirTouch responding.
Tonight I’ll try something different and include a couple of extra nodes at the start of the flow to tell the AirTouch to start heating mode and put a bit of a delay between them. Hopefully that gives the AirTouch time to wake up.
If it’s useful, the ac was running all day but the same error occurred when NodeRed tried to talk to AirTouch after a period of maybe a couple of hours of not talking to it. Does that make sense?
I’ve gone back to an hourly tweak of a zone to see if that keeps the connection alive.
Fantastic, thank you. I still get the ‘Connection error in receiver’ error messages despite trying to keep the AirTouch connection alive every 10 minutes so it must be something else. The only way I can see it is to look in the log.
Is it possible please to return an error code/message from your integration so that NodeRed can see that an error occurred?
I’ve just upgraded to release 1.4.4. I can see that each zone now has a binary_sensor for zone turbo, but I don’t seem to have any spill sensors. Should they have been created automatically?
The code was indeed already available to add the spill sensors to the integration but there was a small bug. I’ve submitted a pull request a few days ago to fix this bug. You could already manually change this in the following file: custom_components/polyaire/binary_sensor.py.
OLD LINE spill_sensor = AirTouchGroupBattery(airtouch, group)
NEW LINE spill_sensor = AirTouchGroupSpill(airtouch, group)
Seems to me this is the benefit of the integration being part of HACS rather than HA, things get fixed much quicker. It’d be a bit like 3rd party apps needing to wait for Apple to release a new version of iOS otherwise.
@mihailescu2m Hi Marian, would it be possible to build in a sense-check of the temperature readings from the ITC sensors please? Every one of the sensors in my system spiked to 154.7 C in the early hours of this morning. I don’t remember it being qquite that warm in reality! But it sure messes with the graphs.
@spry-salt I had a similar thing. Using the Apex Charts card here’s how I solved it - the transform below. It’s not a perfect solution but it prevents spikes in the graphs.
Guys, Life got in the way - but got back to this yesterday
Installed 1.4.4
Running HassOS 8.4
HA 2022.7.5
Installed 1.4.4 yesterday and it was running fine all night - i have an automation that sends (through MQTT) the ITC temps every minute to my Node Red instance (on another machine entirely) so i can act on them
I have a Daikin 3 phase unit
I have the Daikin standard controller installed
And i have Airtouch 4 with 5 zones with dampers and 5 x ITCs
I have a Programme setup on the Airtouch console to turn the unit on at 6am and run for an hour until 7AM every day - that ran fine.
at about 9am this morning i tried to use the Thermostat card to turn the unit on - it indicated it was running - but went to the main part of the house that this AC services about 20 minutes later and the unit was not running - Green light on the Airtouch console, so turned it off and then back on at the console - these events show up in the logbook so it appears to be communicating OK
Checked 10 minutes later and the unit still was not running - so went to Daikin console and turned it on there - left it for 10 minutes and still the unit had not started up
Had to once again go to the circuit breaker and turn it off for 30 seconds and then back on to reset everything and get the main console responding again.
Unlike last time the Airtouch app on my phone (android) and Tablet (IPAD) were still responsive - but did nothing.
Its almost like something in the integration is blocking at the console.
I note that i never had this with the original integration from the start of this thread
Should i just assume i am some weird edge use case and revert back to the old integration (non push) and live with it or is there some more troubleshooting i can do with this ?
I suspect you’re a weird edge case. Works fine for me on the latest version. The worst I get is sometimes HA doesn’t get updates, but I’ve never once had to touch the breaker for my head pump. In your place I’d disconnect HA from your air con entirely for a month or two and see if that happens without HA.
I’m running the PUSH version on HA 2022.8.2 and am no longer (touch wood) having problems with it responding.
I don’t use the AirTouch app and I don’t have any programs set up on the AirTouch tablet itself. All my AC automations run from NodeRed running on the same VM as HA.
Earlier I had problems with AirTouch ‘waking up’ when the first automation kicked off each morning. I added a couple of NodeRed calls that set one zone to Damper mode, wait a few secs, then set it back to ITC mode about 10 minutes before the first automation starts. That seems to be fine now.
Maybe a point of difference is that my AirTouch stays on all night, set to a low temperature so the AC doesn’t kick in unless the temp gets super cold.
thanks for that - i have noted this post and will then factor that in once i go back to this integration.
In the meantime so i can get a baseline i am going to go back to the non-push integration (which i previously used successfully) and run it for a couple of weeks in the same manner as i did with the Push version