New "Basic CC" entity

Configuration
1

After updating HA Core to 2023.11.0, all of my z-wave light switches now have an extra “Basic” entity.
E.g., my “Hall Light” now also has a “Hall Light Basic”.
My lights are GE 14294 / ZW3005 (dimmers) and 14291 / ZW4005 (switches).

A few other zwave devices also got them. I.e., my ring door sensors (4SD2SZ-0EN0), and some motion sensors, etc… it might actually be all og my zwave devices? Not sure.

It is not clear to me what this “Basic” thing is, or what I might use it for.

For the lights, It initially showed up as being “on”, regardless of what the state of the light is.
When I turn it on/off, it does actually turn on the light switch, but the normal/non-basic entity does not update to show the new state. Likewise, changing the “normal” entity does not update the Basic one.

It feels like it is just a second way to turn on/off the light without the rest of my automations being aware that it turned on or off… like maybe some kind of override? The switch obeys whichever one I toggled most recently. The fact that the normal entity no longer reflects the actual state of the switch is troubling though…

Looking through the release notes for this version, I found this: Make Basic CC Z-Wave values a light by raman325 · Pull Request #101438 · home-assistant/core · GitHub by @raman325 but the discussion there is closed.

Which seems to have made the (deliberate?) change… but I still have no idea what it is supposed to be for or why it showed up.

Is this the intended behavior?

Should I just go through and disable every one of these basic entities?
(Should they be enabled by default like this?)

1 Like
2

Where are you seeing them? Basically, the way I read the PR is they have to for a certification thing, (read: usually not optional) and they anticipated there may be issues and tried to trap it in the driver. (I don’t know what that meant and how they planned to catch duplicates, etc.) But in any case, - If you weren’t using them and just want to declutter - you can safely turn them off.

I have some Zwave maintenance myself coming up and if mine are like that (I have no indication it wont be) I will turn the Basic entry off as well. That said - you can also leave it alone no harm, whatever you were using on your dashboard should still work - unless:

The only ‘breaking’ change is if you were using BASIC previously - the entity type changed and therefore may cause automation rewrites…

3

They’re showing up in my “Overview” dashboard. (Managed by HA).
I can certainly disable them all, I just wanted to mention it because it does not feel like this is “correct behavior” ™.

I was not using Basic before. (I dont even really understand what it is or why I would want it)

1 Like
4

Basic is just that - the most BASIC method of communicating to a Zwave device in absence of any other info. In most cases - in the past, you’re not using BASIC to communicate. I get why they had to do it for cert purposes though.

The overview dashboard - I get it, turned that thing off years ago. once I hit about 70 devices it started absolutely crawling.

Short version - lots of stuff gets turned on / off etc. as you install / remove. In most cases it’s benign. The reason you’re not seeing everyone sit up and scream - I’d bet 90% of all HA users don’t ever go to the auto overview dashboard so unless they come across one of the new entities they won’t even know. (And why I had to ask where you were seeing it.)

Just disable them and move on.

1 Like
5

It’s a requirement for Z-Wave certification. You can see the referenced certification issue from the PR you linked to.

The entities for the GE/Jasco switches are a bug, fixed in Z-Wave JS v12.3.0.

2 Likes
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