sendCmd to Contact doesnt work

Apps & Services HABPanel
1

I’m trying to build a widget for my Nuki locks, showing lock and battery status and also allowing to lock/unlock the doors. I had everything working already using a Switch item for the lock but then decided to change to a Contact item instead, and i cant get it to work.

this is my items file:

Number  EGFrontdoorLockStatus           { http="<[http://EGTec1NukiBridge:8080/list?token=xxx:30000:JSONPATH($[0].lastKnownState.state)]"}
Contact EGFrontdoorLock         <lock>  { http=">[CLOSE:GET:http://EGTec1NukiBridge:8080/lockaction?token=xxx&nukiid=yyy&action=2] >[OPEN:GET:http://EGTec1NukiBridge:8080/lockaction?token=xxx&nukiid=yyy&action=1]"}
String  EGFrontdoorLockBatteryCritical  { http="<[http://EGTec1NukiBridge:8080/list?token=xxx:30000:JSONPATH($[0].lastKnownState.batteryCritical)]"

and this is the rules file:

rule "Nuki EGFrontdoorLock"
 when
        Item EGFrontdoorLockStatus changed
 then
        if (EGFrontdoorLockStatus.state == 1) {
                EGFrontdoorLock.postUpdate(CLOSED)
        } else {
                EGFrontdoorLock.postUpdate(OPEN)
        }
end

This part is working fine - So when i lock/unlock the door using the Nuki app, the EGFrontdoorLockStatus is set to either 1 or 3, after a while the rule is triggered and the EGFrontdoorLock changes to CLOSED or OPEN.

this is the part of the widget which is supposed to build the button and trigger action:

  <div ng-if="itemValue(config.ITEM_ID) =='CLOSED'">
    <button class="btn btn-lg" style="background: transparent; color: white"
            ng-click="sendCmd(config.ITEM_ID, 'OPEN')">
      locked
    </button>
  </div>
  
  <div ng-if="itemValue(config.ITEM_ID) =='OPEN'">
    <button class="btn btn-lg" style="background: red; color: white"
            ng-click="sendCmd(config.ITEM_ID, 'CLOSE')">
      unlocked
    </button>
  </div>

it is shown nice & correct in my habpanel

but when I trigger the button I get the following messages in openhab.log:

16:31:42.681 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP POST request at 'items/EGFrontdoorLock' with an invalid status value 'CLOSE'.
16:32:24.273 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP POST request at 'items/EGFrontdoorLock' with an invalid status value 'OPEN'.

To me this seems as if Contacts are not supposed to receive commands ? Or am I doing something wrong here ? I’ve tried CLOSED, OPENCLOSE, several other things with slightly different behaviour, but at the end none of them works…

2

Contacts are indeed not supposed to receive commands. Switches are intended for this use. Contacts are to represent a binary sensor. Switches represent a binary actuator.

3

thx Rick - When i stumbled across this i thought so, however documentation was a bit misleading to me:

http://docs.openhab.org/concepts/items.html

Here it states OpenClose as CommandTypes for Contacts - shouldnt this table be changed somehow to reflect what exactly can be done with sendCmd and postUpdate for each item type ?

Correction - After thinking about it a bit, to me item types should not differentiate between sensors or actuators, there should be no such restriction. What is the rational behind this ?

4

I don’t know for sure but I think it comes down to the default behavior of the Item when it is put on the sitemap. If we only had one type for what amounts to a boolean, you would end up with a case where a Switch would by default show up without a toggle or a Contact would show up with a Toggle.

Unfortunately Switches and Contacts are not used consistently by the bindings so a lot of devices which are sensors (motion sensors, door/window sensors, etc) end up mapped to Switches.

Because of this inconsistent treatment by the bindings I’m a bit ambivalent about having the two. I see the value in having a read only boolean on the sitemap (Contact) as well as a binary actuator (Switch) which can be properly represented by default, yet I’m uncomfortable with making this sort user interface distinction in a part of the config where IMHO it doesn’t belong.