How to change a Channel to Read-Only dynamically?

In the binding which I am working on, a device has two channels – namely 1) Auto/Manual and 2) On/Off. When it is switched to Auto then the user cannot Manually switch it On or Off. But if the user switches it to Manual, then the user can switch it to On or Off. In other words I need to change the Read/Write property of the On/Off channel dynamically in the binding depending on the state of the Auto/Manual channel. => Is there some way to do that?

I doubt this is possible. For binary Items like this whether or not the Item is read only or can be commanded is controlled by the Item Type, Switches can be commanded and Contacts cannot. You can’t change the Item type dynamically at runtime.

What I would do is add logic to ignore and/or set the controller Item is switched to Auto.

Rich, I am sorry but I don’t think that what you say is true. The Read-Only state of a Channel (at least that of a Switch channel) is determined by the XML in the thing-types.xml file – see excerpt below. It the state:readOnly attribute is true then in PaperUI the switch appears as grayed; whereby you can see the status but not change it. On the other hand if the state:readOnly attribute is false, or missing, then the Switch is not grayed out, and you can move it with the mouse.

	<channel-type id="state">
		<description>State of the device (Read-Only)</description>
   		<state readOnly="true"/>

My question is if/how you can override the effect of the state:readOnly attribute programmatically?

I don’t know anything about Channels specifically, but I know with Items, which is the primary thing that all the parts of OH interact with (Rules, Sitemaps, Persistence, other UIs, etc) you have:

  • Switches: which can be commanded
  • Contacts: which cannot be commanded

There is no way to change a Switch to a Contact. If you convert a Channel linked to a Switch to make it read only, it will not prevent one from sending a command to that Item from a Rule (for example). It will not “gray out” that Item’s toggle control in the Sitemap.

What you see in PaperUI is for administration purposes and does not necessarily represent how these things are actually used.

So my question then becomes: is it possible to change programmatically how a thing is “administered” in PaperUI? :slight_smile:

Maybe, but my point is even if you can, it won’t change how that Channel can actually be used. If you have a Switch Channel linked to a Switch Item, there will be no indication or feedback to the user to tell them that the Channel is read only or not at any given time. It also beaks the expected behavior for how these Items should work based on how they work for every other binding. Finally, assuming setting the Channel to read only doesn’t make it incompatible with the Switch Item it’s linked to, it will make your users annoyed when “My Switch to turn on the Heat stopped working and I can’t see why”.

What I mean is shown in the picture below.

  1. the thermostat turns on the heating when the room temperature is below the set temperature; its state is determined solely by the functionality inside the thermostat, and it cannot (shall not) be changed by OpenHAB; it is marked in the XML as Read-Only, and so it appears in PaperUI grayed out, and its position cannot be moved by the mouse; but the position of the switch moves left to right depending on the thermostat’s actual state.

  2. by contrast the Away switch is used to inform the thermostat that the user is leaving the house, so that the thermostat can switch to an energy saving mode; therefore this switch must be adjustable by the user; it is marked in the XML as NOT Read-Only, and so it appears in PaperUI not grayed, and it is possible for the user to move the switch with the mouse; also if the user switches to Away mode by touching the physical thermostat, the Switch will also move to reflect the actual status…


My question relates to another device from the same supplier (a smart plug) – see second image. In this device there are basically two Switches. One switch (Manual Mode) determines if the plug is being controlled automatically by its own internal program (Auto mode) or can be controlled manually by external user commands (Manual mode). If the plug is in Manual mode, then the other switch (Switch State) allows the OpenHAB user to turn the plug on or off. The Switch State cannot be manually adjusted if the device is in Auto mode, so the Switch State switch must be grayed out, if the Manual Mode switch is not turned on.


Pretty sure what you want is the DynamicStateDescriptionProvider where you can change the readonly attribute on an existing channel. Works fine but be aware that the paperui only sees the change on a reload (will not see the change dynamically as you make it)

Right, but what is shown there is not how OH users actually use Channels.

The way a user will actually use this is by linking the Switch State and Switch Manual Mode to Switch Items. Switch Items can always receive a command. And if you make it so that when Switch Manual Mode is ON that the ON commands sent to Switch State are silently ignored then users are going to not be happy.

It may look nicer in PaperUI’s Control tab, but it will cause this binding to break the way Items like these are supposed to work, from the Item perspective. It violates expectations which is not a user friendly move to make.

I do not agree with you. I have been working in building control for 40 years, and I know what I am talking about. Sorry…

Ah. That sounds interesting Tim. Can you kindly advise what module it is located in?

There are plenty of addons that use it - just search the addons repository for it

EDIT: just realize the paperui will only see it on a reload

That’s a bug. The changed channel description state is propagated to Paper UI but apparently is not used.

Well, I’ve only been supporting users with openHAB for five years. You may have lots of experience with building control but you clearly think you know more about how openHAB users use this software with your two months with openHAB than I do.

I’ve over 16,000 posts written, over 5,000 likes, 490 posts marked as the solution. I kind of think I may know a thing or two about how openHAB works and how the users of openHAB expect stuff like this to work.

Feel free to ignore my advice but don’t dismiss me. I’m not just some random dude on the forum. I do have some idea of what I’m talking about.

What I describe is how openHAB works. Perhaps it works differently from what your 40 years of experience tells you it should work. But you are writing a binding for openHAB. It should work the way users of openHAB expect it to, or you are headed for trouble.

Ok @rlkoshak – let’s agree to differ…


Channel read only states are also propagated to items. I’m not sure about the sitemap interface, but it should show read only items different than non read only ones. And it should also update the representation when a binding updates the linked channel. If not that’s a bug in sitemaps.

I have been looking at those other bindings, and yes it does indeed seem to be what I want. I will give it a try, and get back to you. Many thanks for the helpful tip.

Hang on a minute … this is all a bit concerning from a user viewpoint.

What you all seem to be describing is that a channel could change from r/w to r/o and fail silently. If that’s the nature of the device “at the other end”, then that’s the way it is. Failing silently is not good, but more on that in a mo.

I cannot imagine any way in which an openHAB Item is going to be changing its appearance or function on a sitemap based UI. The Item is never going to become read-only. Any Item may be linked to multiple channels, the change of property of one channel cannot be allowed to change an Item property for the others

Any Item can be sent commands (well, barring the oddball Contact type) and it is up to any configured bindings whether to action them or not. But those configured bindings/channels should not be influencing the Item or other bindings/channels in this respect.

It’s interesting to think about how to deal with this practically in the current framework. It seems essential to bring that manual/auto property out via a channel that can be linked to a separate binary Item.
Users rules can find out if Item X is available to be written to by examining this companion Item.

Users sitemap can use visibility techniques to change the UI. I already do this with a ‘virtual’ manual condition.

Switch item=gangway visibility=[gangway_manual!=ON]
Text item=gangway label="gangway [manually %s]" visibility=[gangway_manual==ON]

I guess HABpanel like UIs should be capable of similar.

As for the silent failure of a command, it is possible to construct rules with timers that check to see if the command got actioned properly. It’s all a bit clumsy.

May I suggest a technique from the modbus binding - provide a “last write error” channel (a timestamp in reality) that may be linked to an Item. Any update to this Item signals an error just occured. It’s a lot easier to manage from a user viewpoint.

The problem is that we are trying to map a complex – but very common – functionality using rather primitive objects in OpenHAB…

Think of an old fashioned electro- mechanical switchboard where, for each device being controlled, you have two things on the front of the switchboard – namely

a) a manual switch with three positions (On/Off/Auto); this acts as both a user INPUT (allowing the user to select (On/Off/Auto) mode), plus also a STATUS display device (showing what mode is currently active (On/Off/Auto)). Typically this is a rotary switch where the left position commands & indicates On, the centre/up position commands & indicates Off, and the right position commands & indicates Auto.

b) a lamp that shows the actual (On/Off) status of the device

If the switch is in the On or Off position then the lamp is expected to follow (after some initialization period) the same status as the switch (unless a fault has occurred). But if the switch is in the Auto position then the lamp should follow whatever status is determined by the automation hidden inside the control panel “black box”.

Therefore there are four (non fault) states…

  1. Switch=Off => Lamp=Off
  2. Switch=On => Lamp=On
  3. Switch=Auto => Lamp=Off
  4. Switch=Auto => Lamp=On

So the challenge is how to model a three state switch and a two state lamp into OpenHAB by using a pair of two state switch/lamps widgets. It is not ideal, but my proposal is as follows…

  1. Switch/Indicator = Auto/Manual
  2. Switch/Indicator = On/Off

Where in the case that the first Switch is in Manual, the second switch indicates status and can also command the state (read-write). And in the case that the first Switch is in Auto, the second switch indicates, but CANNOT command the state (read-only).

@rossko57 and @rlkoshak – if you have ideas how to model such a physical reality in a better way into OpenHAB then I would be delighted to hear them.

As far as I’ve ever seen that had never been there case. All the docs and all the behaviors I’ve seen indicates otherwise. After all, the Switch element in the sitemap is separate from the Item Type. You can even use a Contract or a String or a Number with the Switch element. And there is no change in how it behaves. As far as I can tell, the signal element is completely oblivious of the Item Type, let alone any read only settings on the Channel.

I don’t know HABPanel as well so can’t speak to how it behaves, but given that all the interactions are with Items, mediated through the REST API, and last time I looked whether or not the Item is linked to a read only Channel, I don’t see how it could work any differently.

I’d be happy to be shown I’m wrong. Do you have a test I can set up to explore the behavior? As it is now, I just don’t see how it can work.

@rossko57, you said it even better then I did. Thank you.

Given my understanding of how Items, Things, and Sitemaps work I just don’t see how a read only seeing on the Channel would ever propagate to the Items. And if they don’t propagate to the Items, we are in a fail silently case. The ability to link multiple Channels and determining which ones read only setting takes precedence is a problem I hadn’t even thought of.

Is this perhaps something you’ve done in your custom version of OH or are working on that hasn’t made it to a snapshot or release?