I have this problem as well, on OS X using python3.9. The issue is not a previously-installed version of click/asyncclick as I'm installing in a fresh venv and never had it installed anyway. I was able to get it to work by reverting commit 6ece506, e.g.
cd python-kasa
git revert 6ece506a3bf3b76e1c6f3a9a11b93f47ceb9a3e6
poetry install
poetry install creates a separate virtual environment so the command is installed inside that virtual environment. If you type poetry env info in the repository directory, it will show you the path inside of which the entry point is installed:
So in my case the script is in /home/tpr/.cache/pypoetry/virtualenvs/python-kasa-TK6VvBHa-py3.10/bin/kasa.
You can either use poetry shell to activate the environment which adjusts the path so that executing kasa works directly, or use poetry run as you did.
The discovery is indeed another problem, are you devices perhaps in a different network, or do you have multiple network interfaces? You can use --target to specify the network that is being used for discovery instead of the default broadcast address 255.255.255.255 like this:
You can either use poetry shell to activate the environment which adjusts the path so that executing kasa works directly, or use poetry run as you did.
Ah that's the missing piece for me. Thanks for your very helpful reply.
The discovery is indeed another problem, are you devices perhaps in a different network, or do you have multiple network interfaces? You can use --target to specify the network that is being used for discovery instead of the default broadcast address 255.255.255.255 like this:
Right that makes some sense. When I run:
kasa --target 192.168.0.255
My devices show up. It's annoying that 255.255.255.255 doesn't work on my windows. Is there a way of getting kasa to remember the interface to target? So I don't have to tell it via the cmd line every time.
FYI I also get a bunch of this after the list of devices:
Exception ignored in: <function _ProactorBasePipeTransport.del at 0x00000175E0EE6280>
Traceback (most recent call last):
File "c:\program files\python39\lib\asyncio\proactor_events.py", line 116, in del
self.close()
File "c:\program files\python39\lib\asyncio\proactor_events.py", line 108, in close
self._loop.call_soon(self._call_connection_lost, None)
File "c:\program files\python39\lib\asyncio\base_events.py", line 746, in call_soon
self._check_closed()
File "c:\program files\python39\lib\asyncio\base_events.py", line 510, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
@memecode You're welcome! :-) I created a PR to allow defining KASA_TARGET environment variable that you could use on windows. Please create a separate issue for the event loop issue.
Activity
chaseroden commented on Feb 13, 2022
I have this problem as well, on OS X using python3.9. The issue is not a previously-installed version of click/asyncclick as I'm installing in a fresh venv and never had it installed anyway. I was able to get it to work by reverting commit 6ece506, e.g.
rytilahti commented on Feb 13, 2022
Please update asyncclick to be version 8.0 or later, that will also fix it.
memecode commented on Feb 14, 2022
I tried that fix and now my "poetry install" command runs without error, but no kasa.exe is generated. I did have to "poetry update".
Why would there by no binary built?
This does actually run though:
poetry run kasa discover
However it doesn't discover anything... which I guess is another different bug.
rytilahti commented on Feb 14, 2022
poetry install creates a separate virtual environment so the command is installed inside that virtual environment. If you type poetry env info in the repository directory, it will show you the path inside of which the entry point is installed:
So in my case the script is in /home/tpr/.cache/pypoetry/virtualenvs/python-kasa-TK6VvBHa-py3.10/bin/kasa.
You can either use poetry shell to activate the environment which adjusts the path so that executing kasa works directly, or use poetry run as you did.
The discovery is indeed another problem, are you devices perhaps in a different network, or do you have multiple network interfaces? You can use --target to specify the network that is being used for discovery instead of the default broadcast address 255.255.255.255 like this:
memecode commented on Feb 14, 2022
Ah that's the missing piece for me. Thanks for your very helpful reply.
Right that makes some sense. When I run:
kasa --target 192.168.0.255
My devices show up. It's annoying that 255.255.255.255 doesn't work on my windows. Is there a way of getting kasa to remember the interface to target? So I don't have to tell it via the cmd line every time.
FYI I also get a bunch of this after the list of devices:
Exception ignored in: <function _ProactorBasePipeTransport.del at 0x00000175E0EE6280>
Traceback (most recent call last):
File "c:\program files\python39\lib\asyncio\proactor_events.py", line 116, in del
self.close()
File "c:\program files\python39\lib\asyncio\proactor_events.py", line 108, in close
self._loop.call_soon(self._call_connection_lost, None)
File "c:\program files\python39\lib\asyncio\base_events.py", line 746, in call_soon
self._check_closed()
File "c:\program files\python39\lib\asyncio\base_events.py", line 510, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
rytilahti commented on Feb 14, 2022
@memecode You're welcome! :-) I created a PR to allow defining KASA_TARGET environment variable that you could use on windows. Please create a separate issue for the event loop issue.
Release 0.4.2
Release 0.4.2 (#321)
Release 0.4.2 (python-kasa#321)