Implement explicitly named "none" entity for portability?

Feature Requests
5

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:

6

Can you provide a few examples?

7

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:

8

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

9

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
10

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?

11

Why is that even in the sequence?

What do you expect it to do?

It does nothing.

12

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.

13

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.

14

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?

15

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.

16

What you have described is fulfilled by the Demo integration.

17

Cool, gonna try that!

18

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.

19

Disabling an action

20

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.

21

Thanks Taras,

Yey! That’s the missing piece in my puzzle! Awesome! I was looking in the wrong direction entirely. I wasn’t expecting a meta-tag idea :rofl:

Regards,
Hammy

1 Like
22

Hi tom,

I appreciate that! It’s probably fair to say it was a real life rather than a real world example. It wasn’t a case of programmatically disabling something, just editing something so it didn’t fire off and break UI/syntax parsing. I just didn’t know how and went the programmer head way.

Would you like the funny story now? :slight_smile:

Regards,

Hammy

23

Well, I’ve just came up with a situation that made me wanna try it. Kinda disappointed.

Reason

I’ve just moved into a new apartment. There’s a lot to be removed/changed, but there are parts of the setup I used to have that I still wanna keep.

At this particular moment, I do not have motion sensors in my kitchen (yet). I’ve got a group kitchen_motion_sensors that I still wanna keep (it’s used in automations and presented in Lovelace widgets). But… I can not remove all the entities it contains. I have to either remove the whole group config or… (badum tsss) provide a dummy entity.

The Demo Integration

It actually provides a lot of entities. Including binary_sensor.movement_backyard which I could put into my kitchen_motion_sensors group, so that the group config is still valid, even though – temporarily – I don’t really have any motion sensors in the kitchen.

Problems

Mind that these are not problems with Demo integration per se, but just failed expectation for a proposed solution to my particular needs (as being the “dummy entities provider”).

  • Naming: as I’ve mentioned before, I’d like to explicitly see that the dummy is a dummy. Therefore, I’d like to have naming like Demo: Binary Sensor (binary_sensor.demo_entity) – doesn’t have to be exactly like that, but it should be obvious. For example, the binary_sensor.movement_backyard looks like a “real entity”, so I can’t see with a quick glance that this is just temporary patch (to be replaced ASAP).
  • Configurability: The aforementioned binary_sensor.movement_backyard is always ON. I’d like to be able to turn it ON/OFF easily for testing purposes. I know that I can override the state using Developer Tools -> States panel, but it would be much easier if the “device” included an input boolean to controlling the binary_sensor value.

Solution for now

I’m removing the Demo integration and just creating my own dummy entities manually. At least the naming scheme will be obvious (like binary_sensor.virtual_binary_sensor or binary_sensor.dummy_binary_sensor).

24

I agree the entity names should clearly indicate they’re part of the Demo integration.