[SOLVED] Switch-Items not switchable anymore

Recently (some of my) Switch-Items won’t switch anymore. I’m not aware interfering with any of these recently, i.e. I didn’t change any rules that affect these Items. So from my current perspective they just stopped doing what they used to do flawlessly in the past. Here’s an example.

Item Defintion

Switch  zBett  "Bettzeit [MAP(zustaende.map):%s]"  <scene_sleeping>  (gZustaende) ["Lighting"]

The example rule

rule "Test"
    Time cron "0/15 0/1 * 1/1 * ? *"
    logInfo("test.rules","1: " + zBett.state.toString)
    logInfo("test.rules","2: " + zBett.state.toString)


2019-03-05 09:45:15.021 [INFO ] [se.smarthome.model.script.test.rules] - 1: OFF
2019-03-05 09:45:15.032 [INFO ] [se.smarthome.model.script.test.rules] - 2: OFF

The switch stays OFF, apparently, beside the rule telling it to turn ON. In all my openHAB rules there’s just a single rule which could set the state of this particular Item back to OFF, but this rule is not triggered by a state change of zBett. I even commented the whole rule out. No change in behaviour.

I tried switching state via the openHAB-App manually and Echo devices by voice. Neither works. In the App I can see the switch turn back to OFF immediately.

The not-working Items are exposed to the myopenhabcloud. The states of some (but not all) Items have received an update the last time by the end of February, but they should have received several state changes since. I might have updated the openHAB-version from 2.3 to 2.4 around the time of the last updates (not sure).

The only difference between non-working and working (Cloud-)Items I can see is the additional [“Lighting”]-tag. Removing the tag on the Items doesn’t seem to have an effect on the described issue, though.

In the cloud I deleted all Items for a test. The Items (except those without the tag) don’t even get synched (which is not surprising since they have to receive a state change once to be visible in the cloud).

The problem persists after a re-start of the openHAB-service. I’m kinda lost on this one. Any ideas?

EDIT: It appears I can change the state using postUpdate() instead of sendCommand() in the above rule. A manual change still doesn’t work however and the updated Items don’t synch with the cloud.

Wild guess… Could it be related to my problems?

Mmmmh. Unsure. But don’t think so. My problem is not restricted to the use of my Voice-Assistant.

By now I don’t expose my Item to the cloud anymore and reduced the Item defintion to

Switch zBett

Nothing changes: After saving the .item file, the state will remain NULL. Very strange!

That will always tell you the .state before the command takes effect.
Commands take time to action, the rule does not stop and wait for that to happen.
Commands may or may not have any effect on Item.state at all.
In this case, you’d expect the default autoupdate feature to update the Item after a moment.

Look in events.log - what does that say?

This is, what the events.log says.

That will always tell you the .state before the command takes effect.

I tried to write a rule with a minimum example. It doesn’t change the fact, that the state doesn’t get updated. Also, after a couple of seconds it’s still the same. Rules that are supposed to trigger on ‘zBett changed’ don’t trigger at all.

Okeydoke, it’s a bad test and will never show us whether the command worked or not via the logInfo.

Okay, so you never see
[ome.event.ItemCommandEvent] - Item 'zBett' received command ON

That would mean something is fundamentally broken.
Make a new Item zBettTest or something like and try that.
Assuming that works, your original Item is somehow messed up. Assuming it doesn’t get fixed after an OH reboot, I think you’ll have to stop OH and remove the Item from JSONDB, then reboot to recreate it.

Sorry. My logging level was too low. Here’s what the log says concerning the above rule:

2019-03-05 15:31:30.022 [ome.event.ItemCommandEvent] - Item 'zBett' received command ON
2019-03-05 15:31:30.025 [nt.ItemStatePredictedEvent] - zBett predicted to become OFF

For the test item it is (as I would expect):

2019-03-05 15:34:39.936 [ome.event.ItemCommandEvent] - Item 'zBettTest' received command ON
2019-03-05 15:34:39.943 [vent.ItemStateChangedEvent] - zBettTest changed from NULL to ON

Now, that’s really curious.
First log comes from the command event on the bus, that’s good.
The prediction comes from autoupdate. Obviously that would be expected to be ON here.

Autoupdate is working in general - it is what updates your zBettTest Item as expected.

But messing up for zBett.
Autoupdate can be influenced by any bindings to the Item, a binding can overrule autoupdate’s ordinary guess at expected state with the bindings own guess.
I wonder if you somehow have a ghostly channel linked to this Item. Maybe it will show up in REST API, I think you have to list and search links for the Item name.

I also just read up briefly on autoupdate for the first time and find discussions around it in connection to bindings. However, zBett is a virtual Item not connected to any binding at all. So, I guess that’s what you mean by a “ghostly channel”.

That’s strange anyway since I’m not aware having used anything remotely connected to my Item. What I have done recently is thrown-out some Things and re-added them or configured them via a file rather than in PaperUI. Also I might have updated OH from 2.3 to 2.4. But from my perspective no interference with any virtual Items.

Never used the REST API before. Can you provide a pointer for what precisely you like me to do?

OK, found that in the REST API.

    "channelUID": "smarthome:VariableActuator:{NumberHere}:{AnotherNumberHere}:switch",
    "configuration": {},
    "itemName": "zBett"

Now that makes at least some sense. That reminds me that the Item used to be linked to a variable coming from a binding. However, I migrated all variables to openHAB long ago and never experienced problems. Now I at least I got an idea in which direction to look further…

All Functionality restored now! Here’s how:

Re-phrased problem description
OH Items which where previously linked to a virtual actuator (=variable stored in the Software from the SmartHome company) wouldn’t change state on using sendCommand().

Origin of the Problem
The virtual actuators were deleted long ago. They continued to live on as virtual variables inside OH only. Apparently, the links have not been revoked. After an addition in the OH 2.4 software the items tried to communicate with not existing actuators, and the autoupdate feature prevented the items from changing state.

Following up on @rossko57 suggestion (thanks so much!)

I installed the “REST documentation” via PaperUI -> Add-ons -> Misc. On the OH Welcome Screen one can access the Add-on. When clicking on ‘links’ one can ‘GET’ information over all items just by clicking the “Try it out!” button and then search for the itemName using one’s browser’s search functionality.

One should find information similar to the following

    "channelUID": "smarthome:VariableActuator:{NumberHere}:{AnotherNumberHere}:switch",
    "configuration": {},
    "itemName": "zBett"

Using the channelUID and itemName in the ‘DELETE’ part of the link-section of the Add-on one can unlink the undesired (ghostly) channels.

That’s what did the magic for me. Items change state again on sendCommand(), changed Items trigger rules and will show up in the openHAB-cloud. Maybe, @Kim_Andersen, after understanding my own problem better :wink: , this might help you after all(?).

OH 2.4 added the feature of autoupdate<>binding interaction.
Before that, autoupdate just blindly did its thing.

Now the binding can guide the behaviour - in this case, when trying (inadvertently) to send a command to an unavailable device, it gave an appropriate response - “nope, not gonna work, so no change”

1 Like

So after all my recent 2.3 -> 2.4 upgrade has likely caused the (in this case) unwanted behaviour.

Makes perfect sense, if the device is still available, and explains my problem description. In my case the “devices” (here: VirtualActuators) were deleted long ago and so (should) have the channel links - at least this is my naive take. However they obviously didn’t and I needed to get rid of the links manually.

Well I don’t know what you deleted of course. But some kind of “memory” is an intended feature of links as I understand it, in order to handle dynamic (re)discovery e.g a wandering iPhone turns up and ‘hotlinks’ to same Items as last time.

It’s a shame lurking links are not more obvious. I wonder if it might be sensible to have autoupdate generate an “overridden” info when it would usually generate one for a “prediction”?

Well…if I delete an Actuator both from a company’s own Smarthome-Software and from openHAB (say, via PaperUI) - that’s what I did - I would expect openHAB to forget links to that actuator. If the channel link is not hard-coded in an .item-file, that is.

The iPhone, in your example, is a different thing, as I understand it. When it is not available I expect the Thing to tell me exactly that. The iPhone-Thing is still there after all. But if I delete the iPhone-Thing I would expect the channel-link to the item to be removed as well.

The other way round I would expect an item to forget the link when I delete the item. When I then later add an item with the same name I would not expect the channel-link to be automatically active.

But maybe I just don’t fully get the concept behind all that. :slight_smile: