Closed kiwijunglist closed 4 years ago
Hi kiwijunglist
HA version 0.96 and later implements a new version of the Climate component (Climate 1.0). So Nik's component won't work without an update. That's why you get a Importerror - the component can't import ATTR_OPERATION_MODE as that constant does not exist in Climate 1.0
I have my own fork (version 1.0) of Nik's project (based on his version 0.01, not his latest 0.03) which I made my own modifications to, which essentially made the same required operational updates as he later did in his updated version 0.03.
My Goldair component stopped working when I upgraded HA, so I have updated my code (version 2.0) for the changes to the Climate component so that it works with HA 0.96+
While you wait for Nik to update his, you could try mine here:
https://github.com/SmbKiwi/homeassistant-goldair-heater/tree/v2.0
Hope that helps you out.
SmbKiwi
That's great. i'll switch over to yours and see how I go. Might try it now. Thanks! I'll need to change back over to goldair app because I also tried to get it going unsuccessfully with the tuya app.
On Sun, Sep 22, 2019 at 5:05 PM Shane notifications@github.com wrote:
Hi kiwijunglist
HA version 0.96 and later implements a new version of the Climate component (Climate 1.0). So Nik's component won't work without an update.
I have my own fork (version 1.0) of Nik's project (based on his version 0.01, not his latest 0.03) which I made my own modifications to, which essentially made the same required operational updates as he later did in his updated version 0.03.
My Goldair component stopped working when I upgraded HA, so I have updated my fork for the changes to the Climate component so that it works with HA 0.96+
While you wait for Nik to update his, you could try mind here:
https://github.com/SmbKiwi/homeassistant-goldair-heater/tree/v2.0
Hope that helps you out.
SmbKiwi
ā You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nikrolls/homeassistant-goldair-climate/issues/20?email_source=notifications&email_token=AAOFVF3OM4XTTYKGMOFLVFTQK34KHA5CNFSM4IR6IT3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7I6R7I#issuecomment-533850365, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOFVF3SUKK5JJRJSZRC4CDQK34KHANCNFSM4IR6IT3A .
Hi
I still am unable to use your version, it gets me closer, but I get the following problems / errors:
climate.alex (goldair heater) is listed as in the states page, but it is "unavailable".
2019-09-22 17:35:04 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for goldair_heater which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-09-22 17:36:08 ERROR (SyncWorker_24) [custom_components.goldair_heater] Failed to refresh device state.
2019-09-22 17:37:19 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.alex is taking over 10 seconds
The heater works fine in the app. I'm running the latest firmware on the heater (1.0.2) When I check device information in goldair app it states the IP address is external IP address, however for the configuration I am using the local IP address of the heater.
goldair_heater:
- name: alex
host: 192.168.1.94
device_id: xxxxxxx
local_key: xxxxxxxx
# sensor: true
# display_light: true
I wonder if it is a firmware problem?
Hi
You must not be running the Goldair app when using HA as only one can connect to the heater at a time.
I have not updated my firmware. So if you have then you will need to use a different version of the Tuya api. If you have installed newer firmware, then try the following instructions at the link below but update the code in both the goldair_heater.py file as well as the init.py file:
https://www.geekzone.co.nz/forums.asp?forumid=141&topicid=214631&page_no=3#2272645
I don't think you need to install the code from belzedaar as pytuya has been updated see here: https://github.com/clach04/python-tuya
I'll add a note to my instructions about this.
Thanks, unfortunately editing intit.py does not solve the problem
Line 29: REQUIREMENTS = ['pytuya==7.0.4']
Line 140-142
import pytuya
self._name = name
self._api = pytuya.Device(dev_id, address, local_key, 'device')
self._api.set_version(3.3)
Homeassistant error log:
ERROR: No matching distribution found for pytuya==7.0.4,
(SyncWorker_21) [homeassistant.util.package] Attempting install of pytuya==7.0.4,
(MainThread) [homeassistant.loader] Loaded goldair_heater from custom_components.goldair_heater,
(SyncWorker_21) [homeassistant.util.package] Unable to install package pytuya==7.0.4: ERROR: Could not find a version that satisfies the requirement pytuya==7.0.4 (from versions: 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 7.0.1, 7.0.2),
(MainThread) [homeassistant.config] Package goldair setup failed. Integration goldair_heater Requirements for goldair_heater not found: ['pytuya==7.0.4']. (See /config/packages/goldair.yaml:0). ,
(MainThread) [homeassistant.loader] You are using a custom integration for goldair_heater which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
Hi
It looks like you need to install the latest version of pytuya from https://github.com/clach04/python-tuya (using pip3). Version 7.0.2 is the latest version that your docker image contains.
Try these methods:
Not sure if installing first on Ubuntu will work - maybe HASSIO can get it from linux python environment? Not sure, but you could try in Ubuntu: pip3 install 'path to the pytuya folder that you have copied from github'/pytuya==7.0.4
You can also try putting the pytuya folder that you have copied from github into the deps subfolder in the HA Config folder.
Install in your python environment in docker image. I think you can do this when installing the dockerfile as follows: RUN pip3 install --no-cache-dir -r requirements_all.txt && \ pip3 install --no-cache-dir 'path to the pytuya folder that you have copied from github'/pytuya==7.0.4
I use docker compose.
Hopefully I can try #2 because #1/#3 might be too hard / take me a long time. I'm a bit time poor BC had a baby.
I got it sort of working.
custom_components/goldair_heater/init.py
29: REQUIREMENTS = ['pytuya==7.0.2']
custom_components/goldair_heater/goldair_heater.py
25: REQUIREMENTS = ['pytuya==7.0.2']
136: import custom_components.pytuya as pytuya
137: self._name = name
138: self._api = pytuya.Device(dev_id, address, local_key, 'device')
139: self._api.set_version(3.3)
custom_components\pytuya__init__.py Downloaded the file from here: https://github.com/clach04/python-tuya/blob/master/pytuya/__init__.py
It still has some issues though:
I can turn it on and off. It correctly shows the current temperature and target temperature and 'swing level'.
The problem is that when I try to change the temperature I am getting this error:
Failed to call service climate/set_temperature. None
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 130, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1234, in async_call
await asyncio.shield(self._execute_service(handler, service_call))
File "/usr/src/homeassistant/homeassistant/core.py", line 1259, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
self._platforms.values(), func, call, service_name, required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 349, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 373, in _handle_service_platform_call
await func(entity, data)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 529, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 390, in async_set_temperature
ft.partial(self.set_temperature, **kwargs)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/goldair_heater/climate.py", line 116, in set_temperature
self._device.set_target_temperature(kwargs.get(ATTR_TEMPERATURE))
File "/config/custom_components/goldair_heater/__init__.py", line 239, in set_target_temperature
limits = self._TEMPERATURE_LIMITS[preset_mode]
KeyError: None
I also got this log error:
Failed to call service climate/set_temperature. None
The other weird thing is there is no 7.0.4 ???
I can put 7.0.2 and it works, if i put 7.0.4 in requirements then the component will not load.
2019-09-23 16:53:19 ERROR (SyncWorker_13) [homeassistant.util.package] Unable to install package pytuya==7.0.4: ERROR: Could not find a version that satisfies the requirement pytuya==7.0.4 (from versions: 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 7.0.1, 7.0.2)
ERROR: No matching distribution found for pytuya==7.0.4
I've also tried this version of pytuya: https://github.com/belzedaar/python-tuya/blob/master/pytuya/__init__.py ( instead of this version: https://github.com/clach04/python-tuya )
It seems a bit more stable, but if I issue multiple commands I will get errors, such as:
4:56 PM components/websocket_api/http.py (WARNING)
Disconnected: Did not receive auth message within 10 seconds
4:58 PM custom_components/goldair_heater/init.py (ERROR) - message first occured at 4:57 PM and shows up 7 times
Failed to refresh device state.
4:59 PM custom_components/goldair_heater/init.py (ERROR) - message first occured at 4:57 PM and shows up 3 times
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 130, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1234, in async_call
await asyncio.shield(self._execute_service(handler, service_call))
File "/usr/src/homeassistant/homeassistant/core.py", line 1259, in _execute_service
await handler.func(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
self._platforms.values(), func, call, service_name, required_features
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 349, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 373, in _handle_service_platform_call
await func(entity, data)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 529, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 390, in async_set_temperature
ft.partial(self.set_temperature, **kwargs)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/goldair_heater/climate.py", line 116, in set_temperature
self._device.set_target_temperature(kwargs.get(ATTR_TEMPERATURE))
File "/config/custom_components/goldair_heater/__init__.py", line 239, in set_target_temperature
limits = self._TEMPERATURE_LIMITS[preset_mode]
KeyError: None
Hi
REQUIREMENTS = ['pytuya==7.0.2'] is a check that the python component is available and installs it in the python environment if it is not already installed. Since version 7.0.2 is already available the check passes. Since version 7.0.4 is not officially available (see https://pypi.org/project/pytuya/) it can't find it.
Good idea to import it from the custom components folder. Best practice using this method is to put the updated pytuya folder from Github into HA as "/custom_components/pytuya/" and that will work with "import custom components.pytuya as pytuya" line.
Since you have it as custom_components\pytuyainit.py maybe it is still using version 7.0.2 since that is in the requirements in the init file (your errors relate to init.py file)? So for BOTH init.py and goldair_heater.py using REQUIREMENTS = ['pytuya==7.0.4'], putting the updated file in /custom_components/pytuya/init.py and then using import custom components.pytuya as pytuya and self._api.set_version(3.3) may make it work better. You could try this as a first step to see if this improves it.
KeyError: None means that when the set_temperature method attempts to run line 239 [specifically _TEMPERATURE_LIMITS[preset_mode] function)] it can't find a match for the preset_mode value in the _TEMPERATURE_LIMITS function. Have you got Preset drop down in the GUI? (see pic below). That function is checking the temperature limits where preset is set to either Comfort or Eco. So it is saying that whatever is stored in preset_mode (the currently set preset as long as it's not Anti-freeze) is not either Comfort or Eco because it can't find a match in the dictionary in the _TEMPERATURE_LIMITS function. I don't get that error using my custom component with older API. The error seems to relate to preset value being something other than Comfort, Eco, or Anti-freeze, or it's getting no preset value from preset_mode attribute.
Of course it could be that the updated firmware doesn't use C, ECO, and AF any longer to indicate those modes. If you change the preset mode in the GUI do you get an error? If something has changed on the heater firmware, you would get a 'Failed to update device state' error when you try to change preset value. And when the preset_value updates from the heater properties it would get no valid result, if the heater doesn't use C, ECO, and AF value for those modes. That may explain why you get the KeyError as well - because the attribute preset_mode has nothing it it when it updates from the heater, as the heater is not returning a valid mode text. Again that's based on my basic understanding of what the python codes does.
I'm not great at python just learning as I try to understand the code and adapt it, but that's my understanding of what the KeyError or Failed to update device state indicates when you try to change it in the GUI (but I could be wrong).
Thanks. It felt more like it was an intermittent error, but maybe with that additional information I'll be able to pin it down to specific situations.
I'll try out v3.1 and do some more testing!
On Tue, 24 Sep 2019, 11:02 Shane, notifications@github.com wrote:
Hi
REQUIREMENTS = ['pytuya==7.0.2'] is just a check that the python component is available and installs it in the python environment if it is not already installed. Since version 7.0.2 is already available the check passes. Since version 7.0.4 is not officially available (see https://pypi.org/project/pytuya/) it can't find it. But that doesn't matter since you are importing the updated one, so leaving the requirements set to 7.0.2 works. You could take that line out and it should still work.
Good idea to import it from the custom components folder. Best practice using this method is to put the updated pytuya folder from Github into HA as /custom_components/pytuya/init.py and that will work with "import custom components.pytuya as pytuya" line.
KeyError: None means that when the set_temperature method attempts to run line 239 [specifically _TEMPERATURE_LIMITS[preset_mode] function)] it can't find a match for the preset_mode value in the _TEMPERATURE_LIMITS function. Have you got Preset drop down in the GUI? (see pic below). That function is checking the temperature limits where preset is set to either Comfort or Eco. So it is saying that whatever is stored in preset_mode (the currently set preset as long as it's not Anti-freeze) is not either Comfort or Eco because it can't find a match in the dictionary in the _TEMPERATURE_LIMITS function. I don't get that error using my custom component with older API. But the error doesn't seem to relate to that - it seems to relate to preset value being something other than Comfort, Eco, or Anti-freeze, or it's getting no preset value from preset_mode attribute.
[image: image] https://user-images.githubusercontent.com/47836318/65468441-37060180-deb8-11e9-8881-7879aa198ecb.png
I'm not great at python just learning as I try to understand the code and adapt it, but that's my understanding of what the KeyError indicates.
Of course it could be that the updated firmware doesn't use C, ECO, and AF any longer to indicate those modes. If you change the preset mode in the GUI do you get an error? If something has changed on the heater firmware, you would get a 'Failed to update device state" error when you try to change preset value. And when the preset_value updates from the heater properties it would get no valid result, if the heater doesn't use C, ECO, and AF value for those modes. Again that's based on my basic understanding of what the codes does.
You could also try "self._api.set_version(3.1)" and see if that works better. Unsure what version of API firmware 1.0.2 uses.
ā You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nikrolls/homeassistant-goldair-climate/issues/20?email_source=notifications&email_token=AAOFVF4YS7Q2UVH2QP2DICDQLFDITA5CNFSM4IR6IT3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7MQWQQ#issuecomment-534317890, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOFVF6PMZCMFXY52T6XPMLQLFDITANCNFSM4IR6IT3A .
So, I tried v3.1 and it is similar, intermittently unavailable heater.
All the functions work on the heater when I set them from the HA GUI. Operation: Heat / off Preset: Comfort / Eco / Antifreeze Swing mode: 1,2,3,4,5,Auto Target Temperature: X
When I change values on the heater directly it sometimes updates the heater/gui and it sometimes becomes unavailable. I think if I send a couple of commands in a row this is when it fails. After a failure the heater becomes unavailbale and any manual changes or temperature changes on the heater don't come back into the GUI. After a while it becomes available again.
I am not currently using the goldair app.
I use Unifi AC Lite AP. Signal strength = 69% (-63dB). Wife Experience = 78%. It has a green leaf which means it is using wifi power save mode. I don't think it is a wifi reception issue.
My theory is that the heater becomes unavailable because it can't handle multiple commands in quick session in a row. This is triggered when you drag the temperature slider in the app as it sends multiple commands and spams the device. If I send 1 or 2 commands it is ok. It seems to fail if I send around 3-5 commands within 5 seconds or something like that.
Maybe the component needs a rate limiter / delay function??
I've also think I've been able to trigger the heater to become unavailable by changing the settings on the heater multiple times in a row. I notice that HA doesn't always update with changes in the settings. Then i did multiple changes on the heater and it became unavailable for 2 minutes. After that I did one change on the heater and it became available and updated itself to the correct state. I think it's possible to spam in the other direction as well with multiple changes on the heater, but I'm not 100% sure, as I've also had the heater go from available to unavailable without changing any settings on the heater or the app, just happening out of the blue.
If the heater is unavailable I can usually trigger it to become available again straight away by hitting the 'heater on' button, however if i wait it usually becomes available again as well, but this will make it available instantly and update all the current states straight away.
[quote]Since you have it as custom_components\pytuyainit.py maybe it is still using version 7.0.2 since that is in the requirements in the init file (your errors relate to init.py file)? So for BOTH init.py and goldair_heater.py using REQUIREMENTS = ['pytuya==7.0.4'], putting the updated file in /custom_components/pytuya/init.py and then using import custom components.pytuya as pytuya and self._api.set_version(3.3) may make it work better. You could try this as a first step to see if this improves it.[/quote]
I can't get the component to load with requirements = 7.0.4 in both goldair/init.py and goldair/goldair.py when i use the custom init.py from either version of pytua (https://github.com/clach04/python-tuya or https://github.com/belzedaar/python-tuya/blob/master/pytuya/__init__.py)
I've got a bit further.
goldair/init.py ; requirements = 7.0.2 goldair/goldair.py ; requirements = 7.0.4
that works... will see if it's fixed.
sill having issues, intermittent unavailable, intermittent command not seen, all functions work intermittently.
So what I've tried is:
importing both versions of pytuya 7.0.4 (clach04 and belzedaar as a custom_component
I'm using requirements = 7.0.4 inside the goldair.py file and I'm using requirements = 7.0.2 inside the init.py
I've tried self._api.set_version(3.3) and self._api.set_version(3.1)
Everytime I've made changes I've deleted both of the pycache folders before restarting home assistant.
The heater does have a limitation; you should only send one call at a time because it takes a few seconds to action it. Also is is asynchronous and non-blocking. So making more than one change quickly is not a good idea while its still processing the last call, and HA needs to wait before requesting an update that the change has occurred because the old state will be retrieved until the heater has finishing processing the call. This wait for an update after you make a single change is already built into the code - the status info is based on what was changed (is faked) until an update can be requested from the heater. So as long as you wait a few seconds between making a change of single setting in HA that will keep the intermittent unavailability to a minimum. It is strange that I don't experience any intermittent issues, given that the update to the firmware and API should be aimed at improving the experience.
When writing automations you can add a delay between each service request.
In practice the heater will still have the same settings as last time when you turn it on, so generally all you need to do is turn it on and don't often need to change the other settings. When you do need to change a setting after turning it on, just wait a little between each change.
So go with whichever settings for version and api seems to be the most stable and don't make changes too close together.
The weird thing is that it goes unavailable when I'm not sending any commands.
Sorry to hear you get these problems. Sounds like you are just a bit unlucky and have a heater that's got minor operating issues.
perhaps you are right. I'll try return/exchange it at mitre10 for a different one. the different one will be on older firmware, which i won't be changing. the only way to know would be to update the firmware on the exchanged heater, but I don't want to do that.
Hi all, I didn't notice there was all this activity going on here.
I've just released a decent update and everything is working with my heaters at home. Would you mind trying again and seeing if the latest version works for you? I'm back on board ready to debug and make fixes.
With regards to the limitation of the API - this integration does queue up and persist changes to work around that issue, so you should be able to do multiple things at once including automations without issue. Happy to look at improving that though.
Thanks. Where does hacs.json go? is that needed?
I tried your new version and it just makes the heater show as unavailable in home assistant.
hacs.json
is just for the Community Store. You don't need it if you're installing manually.
What model of heater do you have, and what firmware version is it running?
@kiwijunglist I just updated the firmware on one of my heaters and realised I hadn't implemented the new protocol properly. I needed to explicitly enable it, as it's not automatic. However the new version doesn't support devices that haven't been updated š
So I've updated this integration to automatically detect the protocol version - if it can't communicate using the newest, it switches to the older version.
Can you please let me know if the latest update works for you?
Failed to refresh device state for {self.name}.
9:33 AM custom_components/goldair_climate/__init__.py (ERROR)
Update of climate.alex is taking over 10 seconds
9:29 AM __main__.py (WARNING)```
@kiwijunglist That's the same model I have, and the same firmware running on it.
Are you comfortable with using NodeJS and the command-line? If so there's some debugging you could do that would help:
npm i -g @tuyapi/cli
tuya-cli get --ip your_heater_host --id your_device_id --key your_local_key --all --protocol-version 3.3
Note that the Goldair/Tuya app must be closed otherwise it takes over the connection and Home Assistant / Tuya CLI can't connect.
{
devId: '25700720cc50e3148f84',
dps: {
'1': true,
'2': 19,
'3': 19,
'4': 'C',
'6': false,
'12': 0,
'101': '1',
'102': 0,
'103': false,
'104': true,
'105': 'user',
'106': 16
}
}
@kiwijunglist Hmm, I'm at a bit of a loss at the moment. Is this still in your docker situation? Does it work with another kind of install such as HassOS or pyenv? Are there any references to set_version
or Setting protocol version
in your logs?(You may need to switch to debug
logging level: custom_components.goldair_climate: debug
)
I run home assistant latest version in docker using the default home assistant docker.
What version of the goldair heater firmware are you running on your heater?
2020-01-20 19:54:51 INFO (SyncWorker_5) [custom_components.goldair_climate] Setting protocol version for alex to 3.3
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
2020-01-20 19:54:54 DEBUG (MainThread) [custom_components.goldair_climate] pending updates: {}
Failed to refresh device state for {self.name}.
7:57 PM custom_components/goldair_climate/__init__.py (ERROR) - message first occurred at 7:56 PM and shows up 2 times
^ that's everything in the log.
This was working intermittently for me previously using this attached code, done by someone else.
anyone got this working on v0.109.5, I can't even add the custom repo to HASS?
20-05-09 09:36:48 INFO (MainThread) [supervisor.store] Load add-ons from store: 66 all - 0 new - 0 remove 20-05-09 09:36:51 INFO (MainThread) [supervisor.store.git] Remove custom add-on repository https://github.com/nikrolls/homeassistant-goldair-climate.git 20-05-09 09:36:51 ERROR (MainThread) [supervisor.utils.json] Can't read json from /data/addons/git/d1047675/repository.json: [Errno 2] No such file or directory: '/data/addons/git/d1047675/repository.json' 20-05-09 09:36:51 WARNING (MainThread) [supervisor.store.data] Can't read repository information from /data/addons/git/d1047675/repository.json
This is an Integration, not an AddOn. It's confusing, but HomeAssistant has a number of ways to extend it:
AddOns: completely separate apps for HomeAssistant OS which can run alongside HomeAssistant Core. HomeAssistant OS comes with an "AddOn Store" for these out of the box.
Integrations (custom components): Enable HomeAssistant Core to talk to various devices. Out of the box there is no way to add new integrations from the UI. But you can install HACS and use that to manage Integrations and Plugins from the community, as well as Python scripts for the AppDaemon AddOn.
Plugins (custom cards): Extend the UI.
Currently the main repository here is being actively maintained, so the advice above to use other repositories and zipfiles is outdated.
Thanks @make-all.
There is one small issue with HACS and the latest beta, because HACS doesn't support symlinks. Future releases (including the one going up shortly) will remove symlinks until they're supported by HACS.
Cool I might jump in and retry this using hacs after you do that update.
This is an Integration, not an AddOn. It's confusing, but HomeAssistant has a number of ways to extend it:
AddOns: completely separate apps for HomeAssistant OS which can run alongside HomeAssistant Core. HomeAssistant OS comes with an "AddOn Store" for these out of the box.
Integrations (custom components): Enable HomeAssistant Core to talk to various devices. Out of the box there is no way to add new integrations from the UI. But you can install HACS and use that to manage Integrations and Plugins from the community, as well as Python scripts for the AppDaemon AddOn.
Plugins (custom cards): Extend the UI.
Currently the main repository here is being actively maintained, so the advice above to use other repositories and zipfiles is outdated.
Appreciate it, I've got HACS installed now!
I think this particular problem can be closed now.
Thanks @kiwijunglist! It all seems to be working from my end as well so I'll make the new release public.
also this issue:
https://user-images.githubusercontent.com/7436784/81162183-dcea2480-8fe0-11ea-95b6-d178e70486dc.png
has been solved for me too with latest HACS install from this afternoon.
Ubuntu 18.04.2 LTS Docker image: homeassistant/home-assistant Home Assistant version 0.97.2
I have tried the following "fix"
I download pytuya-7.0.2.zip I extracted the file called
pytuya-7.0.2.zip\pytuya-7.0.2\pytuya__init__.py
then copied it to\custom_components\pytuya\__init__.py
then i edited\custom_components\goldair_climate\__init__.py
and changed line 139 from importpytuya
toimport custom_components.pytuya as pytuya
This did not work.