Invalid characters in entity id are silently accepted, breaks service calls to that entity about architecture

[OttoWinter]

So when talking about setting the entity id in your new integration, you mean manually setting it with self.entity_id = ...?

If that's the case: Integrations are discouraged from manually setting entity IDs and so it's their responsibility to do it the right way. All integrations should preferably only set a name and the entity id will automatically be generated for you.

I mean there does exist a validator inside homeassistant.core called valid_entity_id which could be extended to check for lowercase characters. Then that check could be implemented in the entity base. Honestly though, I think especially when talking about python code (and not automations/templates) the developer should take care of validation themselves if they do decide to manually set entity IDs.

[BioSehnsucht]

I thought name was how we set friendly name now? friendly name is not going to be compatible with entity_id restrictions, at least not always ...

[balloob]

I think that we should just convert any given entity_id attribute to lowercase when adding it to hass.

[BioSehnsucht]

I think either casting it lowercase or raising an exception if it's invalid (not lowercase) are both fine. Doing neither leads to eventual confusion :)

[balloob]

We already validate it when it is added to Home Assistant: https://github.com/home-assistant/home-assistant/blob/c14e41f4310a010633bc0eaad22a2a07e05adbdb/homeassistant/helpers/entity_platform.py#L298-L299

If that check doesn't work properly, we should update the regex that valid_entity_id uses: https://github.com/home-assistant/home-assistant/blob/c14e41f4310a010633bc0eaad22a2a07e05adbdb/homeassistant/core.py#L51-L52

PR welcome.

[BioSehnsucht]

I'm pretty sure that \w will allow uppercase in addition to lowercase, etc, unless Python handles that differently. I'm guessing something along the lines of r"^([a-z0-9_]+)\.([a-z0-9_]+)$" (untested, just off the top of my head) would get the intended result?

[balloob]

yeah, and we should add some test to make sure that we don't allow uppercase.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[BioSehnsucht]

Looks like this hasn't been fixed yet (from looking at the current code on master and dev branches). If I can remember to find the time to double check my proposed fix and test it I'll submit a PR.

[BioSehnsucht]

I submitted a PR to fix this, which exposed a test that used uppercase in a mock service call, which should probably be also patched accordingly to be in lower case, but the PR was rejected without giving a clear reason why.

[pvizeli]

We should start a https://github.com/home-assistant/architecture

Anyway, that looks good, but that change a lot and break also a lot installation. It looks small but is a big thing. We are not robust anymore and the entry level grow up for new users.

I think better is to use vol.Lower() on the vololutpus schema and all based on that schema.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[frenck]

This is no longer an issue current day. 🎉