Used invalid characters

[MartiMan79]

Describe the bug Used invalid characters: hue.0.Lisa’s_room.allOn changed to hue.0.Lisa_s_room.allOn

Expected behavior Be able to use apostrophe in name.

Screenshots & Logfiles

hue.0 | 2024-06-14 15:08:14.009 | warn | Used invalid characters: hue.0.Lisa’s_room.allOn changed to hue.0.Lisa_s_room.allOn

CPU: 11,87 % RAM: 36 % Uptime: 1h Available: 6.0.4 Installed: 6.0.4 Events: ⇥28 / ↦13 Platform: linux operating system: linux Architecture: arm64 CPUs: 4 Speed: 1800 MHz Model: Cortex-A72 RAM: 7.6 GB System uptime: 4 d. 05:38:08 Node.js: v20.14.0 time: 1718367225648 timeOffset: -120 NPM: 10.7.0 adapters count: 624 Disk size: 234.2 GB Disk free: 207.9 GB Active instances: 28 Path: /opt/iobroker/ Uptime: 00:54:39 alive: true _nodeCurrent: 20.14.0 _nodeNewest: 20.14.0 _nodeNewestNext: 18.20.3 _npmCurrent: 10.7.0 _npmNewest: 10.7.0 _npmNewestNext: 10.7.0

[mcm1957]

Object Ids are limited to a restricted characterset. An ' is not allowed. Please use a-z A-Z 0-9 and _ only. Some more Charakters are tolerates but not recommended.

This is the intended behavior for all Adapters.

[mcm1957]

Reopen as Adapter should eventually do this cleanup to avoid warning

[MartiMan79]

Thanks for the clarification. The name comes from the Hue app, therefore my question. I’ll rename it to a “friendly” name. So this would be an ioBroker “issue” if I understand correctly?

[mcm1957]

Normally the adapter should filter illegal characters and replace them by ie. an _. In this case this did not work and the adpater code did the replacemnet and issued a warning. The result is - besides the warning - identical.

You may rename it at hue uapp or live with the slightly modified object id. Both should work.

[neo4a]

Object Ids are limited to a restricted characterset. An ' is not allowed. Please use a-z A-Z 0-9 and _ only. Some more Charakters are tolerates but not recommended.

This is the intended behavior for all Adapters.

I have been using the hue adapter since around 2017 and since that time it has been no problem using German umlauts ( think Küche, Gästezimmer etc). It took me a while to realize that recently the hue adapter is not able to handle this and instead completely ignores it.

The object names with umlauts can be assigned in the Hue app and are also correctly adopted and displayed in the IOBroker object tree. However, when I use them in scripts, for example, nothing happens (anymore).

When building the object tree, a consistent behavior in the use of names would be desirable, e.g. to mark ignored characters with a question mark. Even better, however, would be support for the complete local character set.

Thank you.

[mcm1957]

Geman Umlaute are allowed at state NAMES. Only state IDs are restricted to a Set of Charakters. Thats in effect since a long time but core now enforces this. Thats nothing thexadapter can Influence.

One reason for this decision long agobwas that stare ISs are meint as an internationalen Identifikation an must be usaable by other Software too, i.e. darabases.

For human readable infornarionbthe NAME attribute is available.

[neo4a]

For human readable infornarionbthe NAME attribute is available.

Okay. The reasons for older non unicode-capable connection systems are understandable. But if the object ID is derived identically from the HUE-app-naming, then 1. you have to remember in the Hue app that 2. IObroker script may not use the object ID because 3. an unknown connection system might have problems with it.

Sorry, but our lives could be a bit simpler at this point :)

And it's just as well that the Hue Alexa skill can - still - deal with the term "Schalte Kuechenspuele/Haustuer/Gaestezimmer ein".

Thank you for your support!

Translated with DeepL.com (free version)

[mcm1957]

But if the object ID is derived identically from the HUE-app-naming,

Thats a bug in the adapter - thats why this issue still exists. Ids should be dereived from stable information (like mac address) if available. If they are taken from external sources they must be convertsed by the adapter to local naming rules.

[neo4a]

But if the object ID is derived identically from the HUE-app-naming,

Thats a bug in the adapter - thats why this issue still exists. Ids should be dereived from stable information (like mac address) if available. If they are taken from external sources they must be convertsed by the adapter to local naming rules.

Sounds good in theory. In practice, for example, I currently manage 65 physical Hue devices (lamps, plugs, switches, motion detectors) and countless virtual devices (scenes, rooms, zones, etc.). If the IOBroker adapter introduces an additional layer of abstraction because of IT theory, then my management practice is made more difficult in favor of exactly what, what goal?

Searching for additional device information in the Hue app is almost impossible, especially when it comes to virtual devices such as scenes, rooms, etc. It only works with names and these can be pretty arbitrary (spaces, umlauts, special characters etc.).

The current adapter creates a new entry when a Hue device is renamed, for example, without removing the old one from the object tree. I can live with this “bug” much better than with the fact that devices cannot be switched if there are umlauts in the name. Funnily enough, retrieving device information and statuses also works with umlauts.

Translated with DeepL.com (free version)