I was writing a quick script to add a button the other day and re-discovered the joy of needing to provide a target device for syntax only purposes. Thanks for the save sun.sun!
Is there an official ānothingā generic object available to the UI yet? If not, could/should one be created?
When writing scripts and automations etc, many of them will require a target to be specified.
e.g.
Although many services will need that, some donāt and there are occaisions where you have to supply an arbitrary item only so syntax and runtime requirements are met. Historically, people have used sun.sun as a fill-in because itās handy. Ideally, there should be standard named keyword or entity to ensure code is clear to understand and consistent for portability reasons.
Although I found I could use ānoneā as a keyword in my script if I wrote directly in YAML, thereās no obvious guarantees that this will work for other use cases nor is it of any use to UI users because the picker only show (or accepts) real entity-like items.
I guess the questions is; should ānoneā just be tagged onto UI pick lists to plaster over the gap,should there be an appropriately named generic device/entity/area/thingummyjig to use or should syntax be loosened up for non-targetting items?
Cheers!
Hammy
Edited: Original was totally misleading. Hopefully this is clearer and a bit more pointed. Coffee finished now
I think ānullā might have been the wrong word to use :-). Iāll go back and edit it a bit lot.
Tilde obviously does indeed work in YAML itself for creating a null character but thatās not exactly what I was looking for. I was looking for a nice neatly named ādevice.noneā or āentity.nullā or just a ānothingā keyword.
The crux of the matter is that automations and scripts still requires you to supply a known device to meet syntax requirements so leaving a blank (or reall null character) wonāt do so most people just use sun.sun as an arbitrary stand-in.
Iāll re-write it shortly. Itās probably best I add the script to paint the picture better.
PS: I forgot to say thanks for your response. Sorry! Thank you for your help!
Iāve not seen that one myself yet but Iām pretty sure that would indeed work nicely. I think though, that in the long haul, the devs should probably āfixā (and Iām using that in the most liberal of ways) it directly.
Regards,
Hammy
PS: Iām still going to have a look anyway. It sounds interesting
This sounds a lot more like a flaw in your script logic. You should be testing for the service needed and then supply only valid options for it. There are many ways to do this now:
I was putting together a simple button script to use in a dashboard that calls the wake-on-lan service when pressed and wakes up a PC. Hereās the code;
alias: Wake PC
description: Wake PC
icon: mdi:alpha-w-circle
sequence:
- service: button.press
metadata: {}
data: {}
target:
entity_id: none #<--- an entity-like thing or "none" *must* be here
- service: wake_on_lan.send_magic_packet
metadata: {}
data:
broadcast_port: 9
mac: aa:aa:aa:aa:aa:aa
In this scenario, "service: button.press"requires a "target" by definition.
If the whole "target:" structure is omitted, you get a runtime error;
Error: must contain at least one of entity_id, device_id, area_id, floor_id, label_id.
If you just omit the "entity_id:" part, you get a syntax error
Message malformed: expected a dictionary for dictionary value @ data[āsequenceā][0][ātargetā]
If you just leave the entity_id: without a value, you get a runtime error
Error in describing action: n is null
(because the visual editor fails to parse the blank space and replaces it with "entity_id: null" - bug-worthy)
If you use a real entity or the string ānoneā, the script works.
As the UI uses the new entity pickers, it doesnāt allow you to specify ānoneā so UI users are still stuck.
Maybe using the string ānoneā is the proper way to do this and just needs adding to UI dialogs?
Yes, thatās exactly the most versatile way as far as Iām thinking. Inevitably though (and as youāve probably seen in the earlier example given) YAML parsing and UI bugs might also be part of it as is my incorrect usage apparently. Ho hum.
A blank/dummy/null/none device does seem useful in other circumstances. I can imagine it also being useful for testing automations bit-by-bit.
You have not yet give an example of why this is required. You have just provided an example sequence that contains invalid and unneeded services. So this functionality is highly unlikely to be added.
Well, I still think it is just the NullObjectPattern, so Iām not sure if it needs any examples or explanations (as at least programmers should be aware of its usefulness [?]).
Letās try anywayā¦
You want to write your script, but NOT use it with a real entity (yet) (as the real entity shall have real world consequences) ā so you provide a dummy/null entity (temporarily). You can now test your script, its syntax, other aspects ā without the real entity. Make sure syntax call for the action is correct (instead of skipping the action call because it requires an entity and you still donāt have it). You can put the real entity in the end, of course.
You want to disable part of the script ā you could comment it out, OR you could provide a dummy entity, that will just do nothing.
If the dummy/null entities were OOTB, you could share snipptes on forums, where uād be using the dummy entities, and it should be obvious for the readers that they need to replace dummy entities into real ones.
It would be even better if one could tell those virtual entities how to actually behaveā¦ Weād be moving from null objects to mocks
Required is a strong word ā Iād just use useful.
Sorry for the slow response. It took a while to write that example up and jobs/kids etc. :-/
Iām sorry that wasnāt a good example for you. It was what I was editing at time and illustrated where I was at.
Iām very aware that the button.press service call is redundant. The exercise was exactly that. It was a working example initially (pressing a button elsewhere, fun story to follow if youād wished) but I wanted to quickly disable it in a YAML+UI friendly way. I was deliberately looking for a way to make it do nothingā¦
Just as DvdNwk mentioned it was an attempt at skipping real world effects without losing code but the syntax issues and UI vs YAML incompatibilities didnāt allow for it. In the UI, you can disable a script step. In YAML you canāt.
Hey hoā¦ now closed
@DvdNwk - Thanks for holding the fort and defending in such an elegant and succinct way. Iām sorry I didnāt get back into it fast enough to clarify things.
I was hoping you could actually come up with a real world example so I could show you how to fix it using conditional statements.
I used to have a sequence that selected either a script or a scene and I needed to supply an entity for the script but not the scene. This was easily done with an if then. Unfortunately I got rid of all my scenes and only use scripts now so that particular sequence is long gone.
as is my incorrect usage apparently. Ho hum.