Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

indicator.error is not valid state role #23

Open
o0shojo0o opened this issue Sep 1, 2021 · 8 comments
Open

indicator.error is not valid state role #23

o0shojo0o opened this issue Sep 1, 2021 · 8 comments
Assignees

Comments

@o0shojo0o
Copy link

The role indicator.error is not valid.
This is used everywhere here!
https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/stateroles.md#indicators-boolean-read-only

@Garfonso
Copy link
Contributor

Garfonso commented Sep 2, 2021

Looking at indicator.maintenance - indicates system warnings/errors, alarms, service messages, battery empty or stuff like that ERROR seems to be a bit redundant with MAINTENANCE. So one possibility would be to scrap ERROR and only use MAINTENANCE and allow the regex to accept indicator.error.

If ERROR should still be a different thing, then my proposal would be that the role should change to indicator.maintenance.error and docs and code be updated accordingly.

@GermanBluefox what is your opinion?

@stale
Copy link

stale bot commented Apr 17, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

@stale stale bot added the wontfix This will not be worked on label Apr 17, 2022
@Apollon77 Apollon77 removed the wontfix This will not be worked on label Apr 17, 2022
@Apollon77
Copy link
Collaborator

@GermanBluefox ? What do you think?

@Garfonso
Copy link
Contributor

I can create a PR for it, if wanted.

@mcm1957
Copy link

mcm1957 commented Apr 14, 2023

I cannot see any error.xx roles here
https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/stateroles.md#indicators-boolean-read-only

Possibly this Issue is obolete?

@Garfonso
Copy link
Contributor

Yes, that is the problem. There are no indicator.error roles defined, but they are used in type-detector, for example here https://github.com/ioBroker/ioBroker.type-detector/blob/master/index.js#L80

@mcm1957
Copy link

mcm1957 commented Apr 14, 2023

OK, sorry - i read the issue the other way round. :-)

But I do not see if error.xxx is required. There are maintanance.xxx and alarm.xxx anyway.

@Garfonso
Copy link
Contributor

Garfonso commented Oct 5, 2023

Today I thought I'd create a PR, but I recognized that defaultType for ERROR is 'string'. So it seems to be meant for a error message or something?

But that would not fit well with the indicator.* prefix, which is meant to be boolean. So, if ERROR should be meant to contain some human-readable error description, which might be useful (I have some devices that report something like that in KNX) to have a generic field for all possible devices, we might keep it but change the role to text.error and add the role to our ever-growing list of allowed roles. :-)

Any thoughts on this?
I could not find an Adapter that really uses/interprets the ERROR field, tbh. (Apart from lovelace Adapter, but lovelace interprets ERROR as boolean, currently, which is, as said above, redundant with MAINTAIN, so I'd change it there, too or get rid of it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants