New "Basic CC" entity

Configuration
6

I’m seeing the same thing. I have an Auto-Entities card that displays all of the lights that are currently on using a template and all of a sudden I see twice as may lights now. For now I’m going to get around it by adding an other “reject attribute” to the template. It would be nice if there were a way to disable these “basic” entities automatically at the integration level.

 {{ states.light 
  | selectattr('state', 'eq', 'on') 
  | rejectattr('attributes.entity_id', 'defined') 
  | rejectattr('entity_id', 'in', area_entities('outside')) 
  | rejectattr('entity_id', 'search', '_screen')
  **| rejectattr('entity_id', 'search', '_basic')**
  | map(attribute='entity_id') 
  | list }}
1 Like
7

The integration will not automatically disable these, the decision was made to enable them on purpose. You can disable them yourself manually.

It’s possible there’s a device configuration error and the entities should not be created in the first place. You’re going to have to provide more information for that to be determined.

8

@freshcoast - next time you talk to devs remind them that automatically enabling stuff on end user configs is never a good idea? :slight_smile:

(I get cert requirements, and for NEW installs totally support flipping them on. However, flipping bits on existing - eh. not so thrilled about that one. I’ve never had an auditor that I couldn’t convince that jacking with preexisting configs was not a good idea unless it was a security concern. Andrew’s case proves this is not a non-breaking change. It’s had breaking issues with people’s templates.)

1 Like
9

Just to be clear, these are new entities, they were not previously disabled and now are suddenly enabled. That will never happen.

1 Like
10

I get what you’re saying - and without mincing words - the end users don’t know the difference nor care. In that case the ‘auto enable these’ needed to be tested further before it got pushed through. I’ m getting all kinds of questions about what should otherwise be a non-issue everything from have I been hacked to why is my card broken?

As to - not new - I beg to differ - here’s my CURRENT Aeotec Multisensor 6:
image
Before the update the disabled basic entry was there by itself disabled. (the device supports BASIC_ROUTING_SLAVE - ok I get it.)

NOW I have two - one is disabled and unavailable while the other is enabled and a LIGHT? on a sensor? No. There needs to be a little more logic behind what BASIC presents as - and light isn’t always it.

2 Likes
11

That is mentioned in the breaking changes.

Basic Command Class values were previously exposed as number entities and were disabled by default. They are now exposed as light entities and are enabled by default.

If you have scripts or automations that use any of these number entities, they should be updated to use the new light entities instead. Any previously created number entities for this Command Class can safely be deleted once you have validated that your scripts and automations are up to date.

The number entity did not provide the correct implementation for this functionality. The light entity is currently the best choice. Basic Set commands only allow values 0-99 and 255. A number entity provides values outside of that range that are invalid. A light supports both, by brightness (0-99) and turn on (255). The light entity is basically a compromise given the current choices. Some documentation for this would probably help.

Perhaps a better strategy would have been to migrate the number entity to the light one, if that is even possible. But then someone would probably be upset if their number entity was removed.

I posted in another thread, the Multisensor one is (probably) a bug. Here’s an issue if you want to contribute your use case. I’d suggest performing a re-interview first (capturing the driver debug logs) to make sure there is nothing out of date, include the interview logs and also attach the device diagnostic file from HA (under the ... menu on device page).

I’m in the other camp for default enable/disable. I don’t think any entities should be disabled unless there are helper entities that replicate their functionality (e.g. raw notifications are hidden but targeted binary sensors are shown instead). Disabling entities by default is harmful as they are difficult for users to discover.

The choice to disable entities by default or not is not a simple choice, and it’s debated often. My argument is they are hard to discover. Arguments against are that they can pollute the state machine and you may have a lot of entities that aren’t needed. Both are correct. When it comes to disabling by default, it mostly comes down to opinion.

1 Like
12

Oh Geeez, I didn’t even think about my other dashboards (non-overview), since I didn’t have need to look in them until today.
But yep, I also have an auto-entity based dashboard for my lights, and loads of “Basic” stuff is now in it.

I also have an Aeotec Multisensor, and it also now has a “light” on it. (Toggling it does not have any efffect that I can see… certainly nothing I would call a “light”). I am curious what it does do… but it should not be in my light dashboard.

13

Is there any end-user-friendly description of what the “Basic” switch does, and what my thought process should be to determine if I want to leave it On or turn it Off for any given device? I get that it now is required… but what does it do?

14

I’d say, if you don’t know what it does, you don’t need it. :laughing:

It’s another way to control a device, usually things like lights or other actuators. Mostly used in associations.

1 Like
15

Oh I agree with you 100% on that - but in this particular case no matter HOW it happened to the users it’s a change we’re not talking about first discovery. I understand WHY it happened and dev will say - how are we supposed to know the difference between new and existing? and had I still been a dev support manager I would have said:
(and this is a direct quote from one such rejection on a different tech at an employer when I was in such a capacity)

“Denied, don’t care if you don’t know how to tell the difference if it was there before or not - go figure it out and resubmit the PR when you do because the service desk won’t put up with the support calls you generate.”

Yes, again, I know - not your fault and I appreciate the info you always provide. I’m just asking next time something like this comes up I know you have ears - remind them sometimes something that SEEMS a non-issue blows up BIG (HA Dashboard user colors.) This one has that potential. When you mess up someone’s dashboard it’s instantly visible and personal.

I now have to go update 70-something entities…

16

Settings → Devices & Services → Z-Wave → N entities → Search entities for “_basic”. Bulk select all light entities. Click “Disable selected”.

It’s so easy to do, which is why I don’t really get the controversy (I’m biased on other ways though).

It would be even easier if the entity search allowed globs or regex.

4 Likes
17

because you and I know the trick to do that, understand how Zwave communicates at a deep level, what the consequences of turning these things on and off are. Most people don’t. MOST people I work with on HA (most of the people I deal with regularly are former SmartThings users transitioned to HA) so flipping these things on and off willy nilly is scary. (Remember, we’re solidly entering an era where not every HA user is also a bona-fide Linux admin, and as more yellows, greens, and blues hit the market - and vendors like Smartthings keep tripping over themselves - we’ll get more of that.)

They didn’t consider it an issue because they never conceived the possibility that changing the entity type had any bearing on anything else in the system. That ZWave breaking change you mentioned - I saw it too and until you mentioned it earlier, I didn’t even consider net effect would be - turn it on n my setup or I would have stopped my install and made a stink. End user friendly version would have been:

Basic entity - OK we’re changing the type. Did the end user have the old entity enabled? IF yes create new enabled - if no - create new disabled. THATS what I expected. For first run discovery post join event - absolutely flip all entities on. (That would really help with something liek a ZEN32 with it’s billion entitles)

And yeah search globs would be really cool.

4 Likes
18

Also - THIS deserves its own FYI post… Just saying.

3 Likes
19

+1

This would have been useful information before I searched through my huge Overview dashboard and one by one disabled them all one at a time. I think there must have been around 50.

2 Likes
20

I was able to remove the majority of the _basic but ended up with one labeled “number.in.wall_paddle_switch_500s_basic” listed under a new room called “number”
Not sure how to get ride of this since the real light entity is working correctly in its correct room

image
image1236×1141 99.5 KB

1 Like
21

Try enabling it and then deleting it.

1 Like
22

Glad this thread is here.

2 Likes
23

Just another data point. I’m one of the more casual non-expert HA users.

I have an automation that looks for lights that are on and reports which ones are one via TTS.

Now it does this:

Condition: {{ states.light|selectattr('state','equalto','on')|list|length > 0 }}
Message: {{ states.light|selectattr('state','equalto','on')|map(attribute='name')|list|join(', ')  }}

Resulting in:

Condition: True
Message: Living room cans Basic, Cabinet lights Basic, Wall Splash Basic, Family Room cans Basic, 2nd Bath Fan Basic

None of those are on, of course.

I can disable the _basic entities, but I find it a bit confusing as it seems like I have duplicate light entities and they are reporting as being on when they are not.

Here’s two of those entities for comparison:

image
image1462×404 53.2 KB

Am I using the wrong approach to find if any lights are on and then displaying their names?

24

Just disable the _basic lights.

25
1 Like