Strange behavior of Items and their representation on UIs and REST API

Tags: #<Tag:0x00007f61732b4a40> #<Tag:0x00007f61732b4900>

I’m running version 2.5.6 (OpenHabian) on a Raspberrry Pi 4 - by and large, my system works smoothly.

Today I added the Zigbee binding and included 2 simple switches as things and created to switch items all through Paper UI.

I made a number of observations which I don’t understand - I’m not even sure they are related:

  • When I change the state of one of the items through a rule, this state change is neither reflected in the Control are of Paper UI nor in the linked item representation in Basic UI. I can control the behavior of the switch through both of them, but the representations don’t get updated. It works with all the other items I have in my system
  • Setting and retrieving the state of the item through rules and the console works fine
  • I tried to set the state through the REST API UI - this doesn’t work either. I found out that I actually can’t manipulate the state of any Switch item (Test items get changed, though)
  • When I try to set the state of a switch item through the REST API and then retrieve it, I get the changed value, but the just on the level of the representation - e.g. if I change a switch from ON to OFF the switch shows OFF in the UIs, but the ‘real’ switches state doesn’t get changed

Does anybody have an idea, how I can fix this issue?

Thank you!

I’m guessing that first you should review what command and state represent with openHAB Items. Issuing a command to an Item has different consequences to sending a state update, and it’s not at all clear which you are doing when.
Understanding the difference might clarify some of your difficulties, then we can review what’s outstanding.

1 Like

Thank you for your reply.

When I’m talking about setting the state through rules (i.e. switching a Switch item ON or OFF) in this case, I mean that I’m sending commands. This an example of the console output:

22:01:07.644 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘PoofHeat_Switch’ received command OFF

This command is - in the case of the switches in question - not reflected in the UIs.
As for the REST API, I just assumed, that sending a state to an item would basically do the same. If sending a command string to an item equals a postUpdate, that would explain the REST API part.

To add some details:
I made the Switch item in Paper UI - the body of the REST API description looks like this:

{
“link”: “http://openhab:8080/rest/items/PoofHeat_Switch”,
“state”: “OFF”,
“editable”: true,
“type”: “Switch”,
“name”: “PoofHeat_Switch”,
“label”: “Switch”,
“category”: “Light”,
“tags”: [],
“groupNames”: []
}

In my sitemap I have a corresponding Switch element:

Switch item=PoofHeat_Switch label=“Heating”

A in a rule, the switch gets switches on or off depending on certain conditions, e.g

PoofHeat_Switch.sendCommand(OFF)

This all works like a charm - just that the representation on the UIs (here: Paper UI and Basic UI) don’t reflect the states. However, if I click the switch representation, the item gets the command and switches the ‘real world’ switch.

:

It does not. Sending a command or a state postUpdate produce completely different effects.

In a UI, this issues a command

Good, this is how it is supposed to work - a command gets passed to a binding and so to your real device.
(postUpdates do not)

So two things would normally happen next. Your real device would normally respond in some way to being commanded, and send an update with its newstatus. The binding will process that into a new state to be postUpdated to your Item.
Does that happen? Look in your events.log
If it doesn’t happen, there is nothing for your UI to show.

Thanks again for your reply.

22:01:07.644 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘PoofHeat_Switch’ received command OFF

This an example of the console output caused by a sendCommand in a rule - and that’s exactly the issue: This leads to the expected action of my ‘real world’ but it does not change my UI representation of the switch item (in this case from ON to OFF).

I’m well aware of the differences between sending a command and posting an update - what should sending the request

curl -X PUT --header “Content-Type: text/plain” --header “Accept: application/json” -d “ON” “http://openhab:8080/rest/items/PoofHeat_Switch/state

do - sending a command or posting an update?

Okay, so what you would need to know is if the state of your Item changes. The UI shows you the state. You will find state changes logged for Items in your events.log. If the state does not change, then there is nothing for the UI to show, and we can forget about the UIs part in all this. If the Item state does not change but your real device does. something has gone wrong in the chain from your real device, via binding, to your Item state.

This PUT is a state update, the equivalent of postUpdate.

The equivalent of a command is a POST to a different url.

You might find the interactive REST API (“REST API docs”) to be useful to install.

could this be the problem maybe Rossko?
quoted from your post

What is the filename of your sitemap?
This is relevant, because the result of not following the docs -

sitemapname shall always be equal to the Sitemaps file name, e.g. the sitemapname in a sitemap file named demo.sitemap must be “demo”

is that the UI does not refresh.

from this post

Thank you for the hint - in the UI I found the API command I wanted.

Yes, there must be an issue with along the way the information is passed. I suspect that there is something wrong with the binding - but that’s just a gut feeling. When I detected the switches, they were shown in the Inbox with an non-generic name of things representing light bulbs that I once had in my system but deleted a while ago. I will keep on trying to find out what causes the strange behavior.

Thank you for pointing that out. But the file name is default.sitemap, the sitemap name is default.

It’s unclear to me what your problem is here, but have you tried looking at the debug logs to see what is happening. It is more likely to help than just guessing :wink:

1 Like