2024.3 affected on custom cards like stack-in-card & vertical-stack-in-card in part of a gap between cards in a stack.
Hope that these cards will be fixed/forked by someone.
Currently have to use card-mod to fixā¦
1 Like
I have a few scripts with selector mapping and they all seem fine. Are the attributes just not appearing for you?
I donāt know if it works with HA 2024.3, but did you already checked Canary?
Heard about Canary.
Not ready to jump to Canary yet.
I also recognized, that my netamto wetterstation doenāt show the date from the indoor device.Interesting is, that the outdorr device seem to work correctly.
Correct: Now it is working again. Looks like a cloud interuption
this might be a good time to do away with those custom cards. There is no reason anymore for those cards, as we can do everything with the core cards type: entities, xx-stack and grid, with a little help from card_mod.
Since the latter will probably be in everyones system, keeping the rest as core as possible will be more robust in the longer run.
As is demonstrated with this update apparently. (cant say myself, as Ive long done away with vertical-stack-in-card, which always had flaws, and the stack-in-card)
Itās great that new interfaces are being introduced into Lovelace. But I would like there to be a button to try to automatically assemble a new interface based on the rooms I specify. Yes, not everything will be transferred correctly, but I believe that most will be converted
With the new handy capability to populate script fields from the dashboard, is there a way to know inside the script which user ran it? I want to use this to automatically announce the sender on my TTS notification script.
Imho not since a script is running on a server.
(unless you pass a username via a variable)
Okā¦ this is truly the most baffling issueā¦ Itās only the one script thatās not working for me, my vacuum script (below) that is called script.vacuum, which is unfortunate because itās the one I was most looking forward to implementing.
sequence:
- service: vacuum.send_command
data:
command: start
params:
pmap_id: "{{ map }}"
regions: >
{% set ns = namespace(regions=[]) %} {% for item in rooms %} {% set
ns.regions = ns.regions + [{"region_id": item, "type": "rid"}] %} {%
endfor %} {% for item in zones %} {% set ns.regions = ns.regions +
[{"region_id": item, "type": "zid"}] %} {% endfor %} {{ ns.regions
}}
target:
entity_id: vacuum.roomba
mode: single
fields:
rooms:
selector:
select:
multiple: true
options:
- label: Living Room
value: "1"
- label: Office
value: "4"
- label: Hallway
value: "8"
- label: Dining Room
value: "10"
- label: Kitchen
value: "5"
default: []
name: Rooms
required: false
zones:
selector:
select:
multiple: true
options:
- label: Entryway
value: "11"
- label: Garage Door
value: "0"
- label: Front Door
value: "1"
- label: High Chair
value: "2"
- label: Kitchen Counter
value: "3"
- label: Island Counter
value: "4"
- label: Back Door
value: "6"
- label: Recliner
value: "5"
default: []
name: Zones
required: false
map:
selector:
select:
multiple: true
options:
- label: Main Floor
value: 0hVqO6_1RA-XDwpkLrv3Kw
default:
- 0hVqO6_1RA-XDwpkLrv3Kw
name: Map
required: true
icon: mdi:robot-vacuum
Hereās where it starts to get weird: I created a new script called script.clean and copied the exact yaml code above and voila, works just fine. As soon as I rename the new script entity id to include the word āvacuumā, (such as script.vacuum1, script.vacuum_command) it stops working. Switch it back to a different entity name and it starts working. The original script seems to be permanently corrupted however, no matter what I change it to it doesnāt work.
Truth be told, I can do most of it already with layout-card, and the features I canāt do are ones that I really have no interest in anyway. That may change as they continue improving the basic framework they released yesterday, but for now I donāt see any benefit for me personally.
But if the script is called by a user from a card, wouldnāt be possible to know which user was?
I could be wrong since do not know core good; imho it is not possible.
The ā{{user}}ā variable is only resolved on a client side.
Call a script & pass this value to a script. Ofc you need to use a (custom-)card which supports templated actions.
Yes but it requires templates and the context objects.
{{ states.person | selectattr('attributes.user_id', 'defined') | selectattr('attributes.user_id', 'eq', context.user_id) | map(attribute='name') | list | first }}
Edit: Iām on mobile, your mileage may vary with the template
1 Like
@petro
I just experienced the same issue. Think I know a cause.
Thereās a bug with scripts (Iāve noticed this bug going back several months now) that seems to be affecting this. When I created a script, it automatically assigned it a name script.1709853343256. I renamed this to script.message_control and that is reflected in the entitiesā settings screen, but when I go to the dev tools it still shows script.1709853343256 as the entity when I type message_control (even after clearing browser cache; I believe script.1709853343256 persists in the scripts.yaml even though the UI shows script.message_control).
When I open the more-info for script.message_control there are no fields showing (but they do show in the dev tools).
If I rename the script back to script.1709853343256 and open the more-info, now I can see the fields.
2 Likes
Hi all,
I have this python program that Iāve been running every day for over a year now.
It is called via shell script:
#!/bin/bash
python3 /config/solax/compute_pv_schedule.py $1 $2 $3 $4 $5 $6
Today for the first time the script returned an error, which appears in the log like this:
2024-03-07 22:59:48.982 DEBUG (MainThread) [homeassistant.components.shell_command] Stderr of command:
`/config/solax/compute_pv_schedule.sh {{ weather }} {{ bat_time }} {{ chg_cost }} {{ bev_time }} {{ exit_time }} {{ omie_discount }}`, return code: 1:b'Traceback (most recent call last):
File "/config/solax/compute_pv_schedule.py", line 331, in <module>
v_sunrise_hour = int(v_sun.get_sunrise_time().strftime(\'%H\'))
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/suntime/suntime.py", line 34, in get_sunrise_time
time_delta = self.get_sun_timedelta(at_date, time_zone=time_zone, is_rise_time=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/suntime/suntime.py", line 131, in get_sun_timedelta
UT += time_zone.utcoffset(at_date).total_seconds() / 3600
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: utcoffset(dt) argument must be a datetime instance or None, not datetime.date
'
The offending lines on the python program could not be simpler, and as previously said have been working without any issue for over a year till today:
from suntime import Sun, SunTimeException
(...)
v_sun = Sun(k_latitude, k_longitude)
v_sunrise_hour = int(v_sun.get_sunrise_time().strftime('%H')) ## <<<< offending line
v_sunset_hour = int(v_sun.get_sunset_time().strftime('%H'))
As anyone seen this behavior as well?
It seems like something is broken in the underlying python libs, does it not?
Can anyone help here, some suggestion on how to fix this?
Or maybe we need a bug to be open on github?
Any feedback would be greatly appreciated.
Cheers,
-jprates
This is my scripts.yaml:
'1709853343256':
alias: message_control
fields:
message:
selector:
text:
multiline: true
name: Message
description: The message to broadcast
required: true
sequence:
- service: tts.speak
data:
message: '{{ message }}'
(yes, Iām aware the service call would fail, itās just proof of concept)
The issue is that the 1709853343256 in scripts.yaml doesnāt change whether the entity is changed from script.1709853343256 or script.message_control in the UI entity info/settings dialog. And the fields donāt show up in the more-info if the UI entity ID doesnāt match the scripts.yaml entity
Interesting find. Iāve definitely experienced issues in the past with scripts that were secretly still named with a randomly assigned number. Iāll bet thatās whatās happening. Are you able to modify the scripts yaml file to fix it?
Changing the 1709853343256 in scripts.yaml to message_control (and reloading scripts configuration) if youāve previously renamed the entity ID in the UI resulted in script.message_control_2. The original script.message_control āis no longer being provided by the script integrationā, so delete it, then remove the _2 from the other active entity ID in the UI, flush browser cache and now the more-info fields should appear.
1 Like