search

t1mb0 / airtouch4

0 stars 0 forks source link

Cant turn off Groups #1

Open noobydp opened 3 years ago

noobydp commented 3 years ago

Hi! I receive an error when trying to turn off a group using the power icon on the card. I pulled some log info, but I'm not sure if I missed something, please let me know and I'll get more.

As far as I can tell (but I'm a noob), it looks like using the power icon calls async_set_hvac_mode which doesn't have the off mode, instead of calling async_turn_off

Logger: homeassistant.components.websocket_api.http.connection Source: custom_components/airtouch4/climate.py:194 Integration: Home Assistant WebSocket API (documentation, issues) First occurred: 17:22:02 (15 occurrences) Last logged: 20:15:43

[23283343228304] HVAC mode not supported [23283331053456] HVAC mode not supported Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 136, in handle_call_service await hass.services.async_call( File "/usr/src/homeassistant/homeassistant/core.py", line 1455, in async_call task.result() File "/usr/src/homeassistant/homeassistant/core.py", line 1490, in _execute_service await handler.job.target(service_call) File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service await self.hass.helpers.service.entity_service_call( File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 595, in entity_service_call future.result() # pop exception if have File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call await coro File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 632, in _handle_entity_call await result File "/config/custom_components/airtouch4/climate.py", line 194, in async_set_hvac_mode raise ValueError("HVAC mode not supported") ValueError: HVAC mode not supported

image

t1mb0 commented 3 years ago

Hi Mate,

I have the exact same issue but haven't had a chance to sort out the bug as yet. I scraped the original code to put into its own repo, allowing it to play ball with HACS.

With a bit of luck I'll have some time this evening and will sort out the zone off bug.

I'm not a fan how the overall AC 'on / off' logic works. I prefer to keep a handful of zones in 'on' state, but still have the ability to turn the main unit on and off. A few ideas I've been throwing around:

Any other ideas?!

samsinnamon commented 3 years ago

Hi @t1mb0,

I'm not a big fan of having a separate repository with a copy of the code, if there is any other way we could do it - seems like you're just asking for the code to become divergent. Can custom components run a 'start up' script or anything similar? If you could instead write something that checks out the code and moves it into the shape required for the custom component, that might be a more maintainable idea moving forward. Would much prefer if bugs were fixed in one place!

In regards to the zone percentages, there's a bit involved in that in regards to a new entity type (covers) - otherwise I agree, would like to expose the option to people to configure zones by either or both. This is also required to add support for the AirTouch 2 Plus, which I think could be easy and help some more people out.

In regards to how the AC on/off works, as I mentioned on the main discussion, I agree that it could be differently configured. The python plugin should handle turning the AC on if a group is turned on, so there shouldn't need to be anything added to the HA side to do that. Basically the only changes required would be to expose a new entity for each AC with on/off, and remove the mode setting capability from the groups. I also mentioned there that I have been keen to not make any changes until the initial integration is accepted, as I don't want to impact that (already seemingly very slow!) process. Having said that, we could potentially start work on a branch, and then when the integration is accepted, we can merge in the new branch - if you are keen to dig into the bug or any of those improvements, you're more than welcome to make any branches/PRs you'd like on the original repo and we can keep it all in one place.

samsinnamon commented 3 years ago

Hey @t1mb0

Hopefully you haven't started trying to fix this - I think I have a fix I am gonna check in tonight - gonna copy this issue over to the other repository so I can tag it in the commit message. Will start working on a branch named airtouch4-integration-2, which is where we can keep new stuff until the integration (hopefully) gets accepted.

samsinnamon commented 3 years ago

@t1mb0 @noobydp in case you aren't watching the forum posts, I have also reworked the integration as discussed to separate out the groups and ACs - its on the airtouch4-integration-2 branch. I've also enabled issue reporting on the other repository (sorry about that!)

noobydp commented 3 years ago

Thanks @LonePurpleWolf I'm keeping an eye on them :)

Just not much time to respond at the moment.

(I did manage to get the Airtouch4 in HA - obviously!)

t1mb0 commented 3 years ago

@LonePurpleWolf completely understand having code duplicates is all bad... I'll pull down my repo as I only really wanted it set to public so I could install the plugin and learn how HACS clicked together versus having to manually copy the files over. HACS also handles updates fairly well, ie it monitors repos for new commits and allows you to do one-click updates (I'm being lazy).

Really kind of you to take the time to make all of these changes so quickly. Much appreciated!! I've moved across your recent changes to climate.py and looks like we're on the right path 👌 Can confirm I'm seeing the same issue as per the recent forum posts.

Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 124, in _handle_refresh_interval await self.async_refresh() File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 198, in async_refresh update_callback() File "/config/custom_components/airtouch4/climate.py", line 94, in _handle_coordinator_update self._unit = self._airtouch.GetAcs[self._ac_number] TypeError: 'method' object is not subscriptable


* Fan control doesn't seem to be available for AC0
* I like the idea you brought up re: using a cover for the damper %... guess the tricky part will be figuring out how to swap between the two modes in a sane way -- it's actually handy being able to see the damper % even when you are in temp control mode

@noobydp if you have the installer password (normally polyaire or Polyaire) there are a few options which change which 'sensor' is being used.  I don't use the return air temp, as like you my roof is an oven (mid-century house with a black roof!) but still not happy with any of the options.
Really want to know precisely what's going back/forth between my Panasonic AC and the AT4 -- since the AT4 doesn't have direct control over the compressor, my guess is it sends a dummy 'current temperature' to the AC in order to govern how the unit should be performing.
Does this conflict with the smarts and logic in my Panasonic AC? Maybe.  

Apologies for the dodge pic:
![image](https://user-images.githubusercontent.com/13829375/108160065-47f58980-7123-11eb-98c0-7787685ba54f.png)
samsinnamon commented 3 years ago

@t1mb0 I don't use HACS, but if this makes it easier for others to get it installed, then I am totally cool if you'd like to leave this public (at least until we get the integration pr finally merged) - it is just a bit unfortunate/frustrating that it requires someone to manually move the changes across from one repo to the other.

I am now even more confused why I am not getting the issue... its possible I accidentally fixed that line and didn't push it - I have added the missing brackets that should stop the exception you're having, when you get a second can you try it and see if it makes a difference?

t1mb0 commented 3 years ago

@LonePurpleWolf Yep that did the trick, cheers!

noobydp commented 3 years ago

@t1mb0 I've tried a bunch of those settings and they don't seem to make much difference. I feel like it's always using the return air temp, even if you've set it not to.

The AT4 connects to a "gateway" device that I assume converts the modbus commands to the standard resistance based control that goes to the outdoor unit.

Check out the wiring diagrams in the installer manual. https://www.airtouch.net.au/assets/Uploads/AirTouch-4-Installer-Manual-July2019.pdf