Concept of a switch for e.g. "low battery level" - shouldn't it be a kind of a flag?

Add-ons Bindings
1

Hi,

Bear with me if this is a noob question, but I’m struggling with the way information like “low battery level” is represented in the UI : It appears as a switch that I can really switch, while it should be more like a flag and something that I can’t change from the UI.

Do I miss something obvious here?

Thanks,

2

Use Text instead of Switch to represent the Item on your sitemap or HABPanel. PaperUI is an admin UI and will not let you customize how an Item is represented to the user.

The binding should have use a Contact for that type of data but didn’t.

3

Ok, understood, thanks for the super fast answer.

Sorry, I did not mean Paper UI, but sitemap, so I’ll use what you suggest.

Would you know by chance in which location I can change the binding’s definition? I have looked at where the Xiaomi add-on is installed on my openhabian setup, but I’m not able to find it:frowning:

Thanks again!

4

What do you mean by “change the binding definition”?

5

I mean changing the source file of the binding where Switch has been used instead of Contact to put it back in the right way? Or is this a binary file?

Thanks

6

This is coded in the software. There is nothing you can do as a user except file an issue in GitHub to have the developers make changes in the code.

7

Just change type in paperUI under items to contact.

8

That won’t work with most bindings as they specify a specific Item type to go with specific Channels. If this binding supports sing a Contact or a Switch that’s great. If not…

9

To be clear, assuming that the binding is using standard channels, then this is defined by ESH -:

https://www.eclipse.org/smarthome/documentation/development/bindings/thing-definition.html#channels

It will be somewhat difficult to change it as it’s a system channel, and therefore used by many bindings…

1 Like
10

It did not work for me… I tried and did not get any change.

11

@chris thanks for the note. I’m not sure I understand the full extent of what you mentioned… Do you mean that “Low Battery” is mapped by the binding developper to a system channel “pre-defined” for low battery and that this system channel has been defined as a switch i.e. something that is settable by the user?

I have to say that I’m surprised that this has not been raised many times already by users of Xiaomi devices…

Thanks,

12

It’s defined as a switch - although it should (I think) be read-only so that the UI doesn’t actually provide a user settable UI.

I’ve not looked at what the Xiaomi binding does - maybe it does something non-standard. However, in general bindings should be using these system defined channels so that everyone implements common functions like this in a common way as defined by the framework.

13

I start having the feeling that either I’m not lucky (and the 2 devices families I use are suffering from this problem) or it could be a common mistake accross the board, no?

See this example in the Sonoff related page here : https://github.com/arendst/Sonoff-Tasmota/wiki/openHAB
where “switch” seems to be used for LWT status, which I think is the same semantic error than for Xiaomi devices…

Thanks,

14

It’s the same for the MAX! binding used for EQ3 devices.

15

As I mentioned above, it should be the same for every binding since it is defined by ESH and not individually at binding level.

16

I re-read your messages, @chris and now I understand. Yes, batteryLow concept is defined by ESH and it is defined as a switch… Bindings are not specifiying their stuff as a switch but as a ESH batteryLow which is itself a switch… hence the result, accross the board.

All this, while the ESH documentation insists on the importance of the semantic for a channel:slight_smile:
Also, it seems that the key contributors for openHab and ESH are the same, so there might be hope for adjustments. Do you know what would be the best way for me to suggest a change in ESH?

And last question : Is there really no way to “overload” this in openhab graphically so there is a different presentation?

Thanks and sorry for being slow :slight_smile:

17

You an raise an issue on the ESH issue list on Github.

Presentation is up to the UI at the end of the day, so anything is possible.

Personally, I don’t think the switch is the issue. In ESH a switch is simply a binary indicator, so it’s fine for a battery status (IMHO). The only thing that arguably needs to change is that this should be a read only switch (ie a status indicator) which then tells the UI to present it differently. This is normally how contacts (for example) are defined, and the UI can present it as a non-interactive component.

This isn’t currently defined (I checked yesterday) and the constructor being used didn’t seem to provide this parameter (I didn’t check other constructors or other ways to change it to read-only, so it might still be a simple change).

18

Yes, makes sense, I agree, switch itself is not the issue if there is an option to make it read-only when applicable. Thanks. I’ll try to submit an issue on ESH and we’ll see.