Implement explicitly named "none" entity for portability?

Hi,

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! :slight_smile:

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.

    target:
      entity_id: media_player.that_alexa_downstairs

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 :slight_smile:

try tilde? ~

Hi,

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!

Don’t know if it can be used here, but I stumbled on a Virtual components integration in HACS the other day.

Thanks Wally,

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 :slight_smile:

Can you provide a few examples?

ah, I think I now understand you…

You want to excercise the Null object pattern - Wikipedia

So, having an entity that you can put in your scripts that would “just be” and “do nothing” (temporarily or as a “turn off”).

I haven’t seen such, good idea though! Voted :slight_smile:

If you need “dummy” entities, this might interest you (it creates over 40 entities; light, switch, lock, cover, climate, etc).

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:

  • service templates
  • choose
  • if-then

Hi Taras,

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.

  1. 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.

  1. 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’]

  1. 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)

  1. 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?

Why is that even in the sequence?

What do you expect it to do?

It does nothing.

Hi again :slight_smile: ,

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 :roll_eyes: 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.

Respectfully, if that example represents the best justification for the FR, then I agree with tom_l that it doesn’t make a compelling case.

Do you have a better example?

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…

  1. 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.
  2. 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.
  3. 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 :wink:

Required is a strong word → I’d just use useful.

What you have described is fulfilled by the Demo integration.

Cool, gonna try that!

Hi Folks,

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.

Disabling an action

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.