Expire binding not working for group switches

  • Platform information:

    • Hardware: RPi 3
    • OS: openHAB 2.4.0~S1443-1 (Build #1443)
    • Java Runtime Environment: openjdk version “1.8.0_152”
      OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
      OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
  • Issue of the topic:
    I have several cameras pointed to the exterior of my house, running motioneyeOS, when the camera detects motion, it sends a web hook to OpenHAB to turn on the switch gPres_Perimeter. This is a group switch as I have 4 cameras covering the exterior of my house. If any one of the cameras detects motion, gPres_Perimeter is turned on, with the expire binding to switch it off after 42 seconds so it will trigger a second alert if the motion continues, or if another camera detects motion. For some reason, the expire binding does not seem to be working, in fact, all of the group switch items get the same error in my log file.

  • Please post configurations (if applicable):

Group:Switch:AND(OFF,ON)        gPres_Perimeter  "Perimeter: [MAP(occupied.map):%s]" <motion>    (gPresHouse)       { expire="42s,command=OFF" }
Group:Switch:AND(OFF,ON)        gPres_Garage     "Garage: [MAP(occupied.map):%s]"    <motion>    (gPresHouse)       { expire="42s,command=OFF" }
Group:Switch:AND(OFF,ON)        gPres_Basement   "Basement: [MAP(occupied.map):%s]"  <motion>    (gPresHouse)       { expire="42s,command=OFF" }
Group:Switch:AND(OFF,ON)        gPres_1stFloor   "1st Floor: [MAP(occupied.map):%s]" <motion>    (gPresHouse)       { expire="42s,command=OFF" }
Group:Switch:AND(OFF,ON)        gPres_2ndFloor   "2nd Floor: [MAP(occupied.map):%s]" <motion>    (gPresHouse)       { expire="42s,command=OFF" }
  • Sitemap configuration related to the issue
			Frame label="Status of Presence Detection:"
			{
				Text item=gPres_Perimeter valuecolor=[ON="red", OFF="green"]
				Text item=PresPerimeterLastUpdate
				Text item=gPres_Garage valuecolor=[ON="red", OFF="green"]
				Text item=PresGarageLastUpdate
				Text item=gPres_Basement valuecolor=[ON="red", OFF="green"]
				Text item=PresBasementLastUpdate
				Text item=gPres_1stFloor valuecolor=[ON="red", OFF="green"]
				Text item=Pres1stFloorLastUpdate
				Text item=gPres_2ndFloor valuecolor=[ON="red", OFF="green"]
				Text item=Pres2ndFloorLastUpdate
			}
  • If logs where generated please post these here using code fences:
2019-01-01 08:22:47.601 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type 'expire' of item 'gPres_Perimeter' could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: The string 'OFF' does not represent a valid command for item gPres_Perimeter
Caused by: org.openhab.model.item.binding.BindingConfigParseException: The string 'OFF' does not represent a valid command for item gPres_Perimeter

I get the above error in the logs for all Group:Switch:AND(OFF,ON) Items. I tried Group:Switch:OR(OFF,ON) and get the same error. I thought it might be the transform causing the issue, but still get the same error after trying it without it in the item definition. Any help would be appreciated!

~John

You can’t have bingings on groups :frowning:

@jsable As mentioned you can’t have bindings on groups but you can use a rule to accomplish what your trying to do. See this example:

Yes you can.

Group Lights "All Lights" (House) { mqtt="<[mybroker:House/AllLights/command/default]" }

That works for me to switch all lights off, for example

Dang. I did not know that! Thanks :slight_smile:

That may work with mqtt, but it does not appear to work with the expire binding… I am attempting write a rule to accomplish what I’d like to get done. Thanks for all your input!

~John

It is legitimate to send commands (not updates) to a Group. It looks like it may go wrong because expire binding - or perhaps some deeper part of OH - is sending a string to a group, rather than looking to see the group subtype (Switch in this case) and sending a more appropriate ON.

I think this worth raising an issue, for a fix.

Done -