I would love to get some feedback on the new python_script component. It’s still early and we’re still running into some issues that we will improve over time.
Starting 0.47.1 we will support iteration so that we can have for loops. This will allow scripts like this:
Besides iteration, what other things do people want to do with python_script that are not possible right now?
Perhaps not possible in the sandbox, but importing would be useful as per About the Scripts category Would be happy enough if imports were limited to those already in requirements of HASS
I don’t think these script should be a replacement for custom components, since we have… custom components for that. More like an alternative to templating. But, it would be useful to have some basic transformation functions (like json) and some sort of re-use pattern for local data. The main example I’m thinking of is for instance a database of random responses to Alexa. We do that in jinja today already, would be useful if similar things could be done in python scripts so we don’t have to duplicate data all over the place.
Custom components are more challenging for less experienced coders/developers. The rapid code-test cycle of python_script is its most appealing factor for myself
Imports are indeed out of scope. Use a custom component for that.
Json and reg ex are a good idea to make available.
Sorry about the comments in the PR, @balloob, I’ll post them here:
I’m playing with this new component (in 0.47.1) and I have noticed certain lacks:
NameError: name 'hass' is not defined)# Not working:
local_data = {k: hass.states.get(k) for k in local_data.keys()}
# Working:
for k in local_data.keys():
local_data[k] = hass.states.get(k)
NameError: name '_getitem_' is not defined):close_house = local_data['input_boolean.close_house']
# This is working:
close_house = local_data.get('input_boolean.close_house')
No getattr (NameError: name 'getattr' is not defined):
Can’t use max/min and so on: NameError: name 'max' is not defined
Can’t import anything.
The truth is that, for now, I can not see or find enough reason to use this system to replace the AppDaemon system, which I use a lot. I guess this new component is not for me… I hope others do take advantage of it.
I use python scripts to do stuff that is a little bit complex to do with hass, then I use a cmd component (e.g. Command line sensor) to run the script.
I’ve been looking at appdaemon to use for python scripting.
Can you elaborate what the main difference is between my way of using python script, appdaemon and python_script component?
_getitem_, getattr, min and max should be easy to add. As commented above, imports are out of scope.
The goal of Python Script is not to compete with AppDaemon. It’s for simple Python scripts, for more advanced functionality use AppDaemon or a custom component.
I think if you are doing anything a little complex, the optimal tool to use is AppDaemon (I love it).
I suppose the new python_script component will be a useful tool to people who are short on the current yaml system and need to do a little more not too complicated.
Anything you’re doing with a command_line sensor, switch, shell script or similar, you can do it with AppDaemon. Firing a script from a yaml automation can be replaced by firing a custom event which the app is listening to. I encourage you to try it. If you need more (or more complex) examples than the included in docs, here it is my personal collection.
Great, just the kind of answer I needed. Thanks!
Maybe I’m doing something wrong, but it would be nice if HA recognized new script files placed in the directory without a restart. I just wrote one and it’s not showing up in the services list to select.
I think the python scripts need to be registered first, so, if is a new script, you’ll need to restart HA. But after that, you can change the script content and trigger it with the last changes. I’m rsyncing it and re-triggering from the dev panel without problems.
Unpacking tuples and iterate dicts will be sweet, also.
I’m trying again for something simpler, but useful. I’m updating some automations and ‘normal’ scripts to one python_script to be triggered at HA start.
The ability to ask for states and make logics with them in order to update states is very nice, and makes sense as a level just over the yaml system to define automations.
Just one silly question, how can I make a delay inside a script?, like in the yaml syntax
I understand that’s the way it works today. But if we are asking for things, It seems it’s something that is auto discovered, it should be fairly easy for HA to watch for changes to that directory. If it’s a change to a file it knows about, it ignores it, if it’s a new file, it registers the file. Having to restart HA every time a change is made is getting a bit old. I would like to see a little bit of time placed to making HA a little more dynamic in the configuration arena. We can reload groups now and that’s a huge step in the right direction. customizations, automations, etc would be additional good steps. Every time I restart it’s several minutes while HA figures out all my zwave devices before I get anywhere near realtime control over them.
What are you talking about? You can reload customize, groups, scripts and automations without restarting.
Watching a directory for changes is out of scope for the component
Groups I know, How do you reload customizations and automations without restarting HA? Is that what reload core is supposed to do. If so, I’ve never seen it work.
To reload automations you can use the automation.reload service, and yes, the customizations are reloaded through the core. At first it looks like it doesn’t work though, because the changes aren’t visible in the UI until the state of the entity has changed. As soon as that happens, the customization will be visible.
Would it be possible to have some sort of delay/sleep functionality? Or possibly access to datetime functions so we can have access to do checks against the date/time?
I understand that python_scripts are run in a sandbox so they don’t impact the HA threads. Are all python scripts run in the same sandbox, or does each script have it’s own sandbox?
datetime is a good idea. Sleep is not, as it takes up a thread and the number of workers in our threadpool are limited.