Feature Request: Handling of Attributes with Periods and Spaces on Device Page

This could be considered a feature request, it could be considered a bug. In any case some of my drivers have suffered from "duplicate attributes" being displayed on the device pages for some time and it just has seemed to be "a thing". However I did some more investigation and found at least one character that causes odd behavior. The period.

If a period is included IN (this is important) an attribute name that attribute will be duplicated each time it is refreshed on the device page. If you refresh the page itself (or close/reopen it) the duplicates will go away but new ones will appear. Here is a screenshot of this from the sample driver/device I made this morning to test it, you can see that the Particles4.5 was duplicated:
AttributeTestCurrentStates2

If an attribute ENDS with a period "Particles3." then it does not show it appear on the page or change the existing attribute value like most attributes do. You can see that in the above screenshot. When you reload the device page it WILL show the attribute in the Current States list. Screenshot below:
AttributeTestCurrentStates3

Throughout this, the events ARE getting posted to the device's event data and are available for use by Rules (or such). So the practical impact is minimal, it is a distraction on the device page (especially the missing ones). I did not do a "comprehensive" test of characters to see if others get this issue. Here is a screenshot of the Events table showing they appeared (even the Particles3.):

Here is the driver code if someone wants to peruse it a bit more:
AttributeTest.groovy

EDIT (2/16/2023)
Since I cannot reply to add additional information since this is now "closed" automatically... I am editing the main post:
I have now seen this happening with attributes that have a space in their name as well (them being duplicated when a new value comes in). That increases the number of times this can happen substantially.

So why not eliminate all periods in names? it becomes ambiguous in groovy....

One key example that brought it to my attention and made me look into it in more detail this time was PM2.5. That is a pretty common method of representing particulates. Having it anything else makes it tougher for people to recognize.

Most attributes I add are based on what another system is providing (most of my drivers access local or cloud APIs) so I try to represent the data comparable to the system since that is what the users expect.

Since these DO work just fine for most purposes, it is not a huge deal. But it is odd that they do not get displayed properly while a device page is open.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.