[SOLVED] Switch rendering when mapping in Sitemap

Although this is purely aesthetic: Is it possible to have a mapping in a sitemap for a switch and render it in a classical way in the Basic UI, i.e. not with buttons, but with the “little on off slider”, instead? I could do this with another rule, I guess, but I would avoid it if I can.
My sitemap entry is:

Switch item=coffeemaker_command label="Kaffeemaschine []" icon="poweroutlet" mappings=[switch1_on=ON, switch1_off=OFF]

The coffeemaker_command item is of type String. When ON is pressed, ‘switch1_on’ is sent to this string item. So in principle it works fine. I have tried things like putting “ON”/“OFF” in quotes, specifying OnOffType::ON (which does not work) etc.

You mean like this?

I am interested in how the BasicUI determines switches. Here is the binary switch on my motion sensor.

image

Yes, this is what I mean. My “Switch” however looks like your “Papillon Motion” instead.

1 Like

Thats because you use the mapping.

First of all, your item type define the “switch”. If you´re item type dont have a on/off, you´ll probably not get the same trigger as the one Bruce is showing.
When using String as an item type, openhab have no idea what kind of type it is. But I wonder why do you need to use string at all… If it´s a power outlet, I would assume it should be a switch type ??

I have no mapping on any of those switches. I just looked at items in the REST API and found a difference. It appears that sometimes there is a default mapping. This item was created in the PaperUI with no mapping. I did not set that options section

{
  "link": "https://...",
  "state": "OFF",
  "stateDescription": {
    "readOnly": true,
    "options": [
      {
        "value": "OFF",
        "label": "OK"
      },
      {
        "value": "ON",
        "label": "Alarm"
      }
    ]
  },
  "editable": true,
  "type": "Switch",
  "name": "papillon_motion",
  "label": "Papillon Motion",
  "category": "motion",
  "tags": [],
  "groupNames": [
    "papillon_yard"
  ]
}

I know., but Mathias (OP), is using mapping in his sitemap. His switches (triggers) looks like your Papillion Motion sensor. Thats because he use mapping in his sitemap for the coffeemaker_command item.

1 Like

My question now is what caused my rendering? It must be some logic in the PaperUI? That item is in the Sitemap as part of a Group but I get the same effect placing it in its own Frame on a sitemap.

EDIT: Also notice the mapping is not editable (?)

The reason I am using a string is the physical connection to the plugs.
I have a homeeasy set of plugs that use an ‘ook’ communication and the openhab is running on a RPi like system having access to an RF transmitter to control those plugs. There is no TCP/IP or other type of internet connection to the plugs.
Basically, the string is translated to some ‘hardware timing’ turning the RF transmitter on and off to mimic the remote control.
Anyway. The obvious solution is to define an additional “Switch Item” and have it trigger the String item when it receives a command. But I was wondering if I could eliminate that step and have one item and a rule less.

Bindings can supply formatting ‘clues’ via their channels for Items. The most obvious case would be units of measurement, but it does extend to other Item properties.
A known ‘battery alarm’ channel might suggest “OK” and “Fault” instead of on/off, for example.
You can’t edit those because that would require feeding back into the binding, and eventually the target device in some cases.
Not many binding authors have implemented this, and it’s not a lot of use without some fairly detailed discovery - such as is available in zwave.

But I’m sure you can override these in your Item and sitemap definitions, where you don’t like these defaults the binding is suggesting.

The Switch/pushbutton thing is worth poking at though - how do you “force” a default slide-switch in the UI when the system is ‘helping’ by giving you a hidden mapping effect?

1 Like

I think thats the only way, unfortunatly.

I could try a manual item. I want to move to that anyway.