Rule to postUpdate an Item works but Item falls back after some seconds

Setup, Configuration and Use Scripts & Rules
,
1

Hello community,
reading through this community helped me a lot. Thanks to all btw.

For the following issue I did not find a solution over the last weeks.
An Item has autoupdate=false because it should receive the updates only via postUpdate from a rule. This works fine, but after around 15 to 40 seconds the Item state jumps back.
The details:
The item which is of interest to show the state

Switch Licht_EG_Flur_Decke 	"Flur Decke" (EG_Flur)	{tinkerforge="uid=rFs, subid=out2", autoupdate="false"}

The item which is receiving the state:

Contact Sensor_Licht_EG_Flur_Decke	{tinkerforge="uid=wj6, subid=ina4"}

The rule which posts the updates to the Switch item:

rule "Status Licht EG Flur Decke AN"
when 
Item Sensor_Licht_EG_Flur_Decke changed from OPEN to CLOSED
then 
postUpdate(Licht_EG_Flur_Decke, ON)
end

rule "Status Licht EG Flur Decke Aus"
when 
Item Sensor_Licht_EG_Flur_Decke changed from CLOSED to OPEN
then 
postUpdate(Licht_EG_Flur_Decke, OFF)
end

Not sure if this is of interest but there is another rule that is needed to make the switch working properly in our home:

rule "Automatisches Tasterloslassen"
when
	Item Licht_EG_Flur_Decke received command ON
then
		Licht_EG_Flur_Decke.sendCommand(OFF)
end

The background of this rule is that the house has installed relays for each light. These relays are switched on and off by push buttons that are installed in this house. And to create real push buttons in Openhab this rule was necessary. With this rule only, OH does not know if the light is on or off.
These hardware relays have two outputs. One is used for the light, the other one is used to detect the status of the light. That is what triggers the above mentioned Contact item.

I tested a lot, but it looks that I don’t fully understand what happens…
Some tests:

  • The postUpdate rule was deactivated. Then the UI very quickly shows the light flashing on and then off. So the postUpdate rule is working properly. But it somehow is loosing the status.
  • When the hardware pushbuttons are used OH correctly detects it and updates the Contact and the Switch Item, but the Switch Item falls back also when triggerd with the hardware buttons.
  • I added to the sitemap the Contact item to see if OH really has the status from the relay. This also is showing the correct state.

Using OH 1.8 on a RED Brick from Tinkerforge
Thanks for reading!

2

That’s not what autoupdate does.
Example: autoupdate=false will stop (say) a rule-generated myswitch.sendCommand(ON) from setting the Item state to ON automatically by Openhab.
If the binding of the switch receives an update from the hardware that the switch is really now on, the Item still gets updated by the binding.

So autoupdate=false allows you to monitor the actual state of device, while autoupdate=true allows more faster display of the expected state in a sitemap.
In your case the tinkerforge binding will tell you the real state of the contact at next refresh.

I don’t fully understand what problem you have here, but it sounds a bit like something I had to do with my hardware. That is Modbus, but similar idea.

  • A Switch Item simulates a push on - push off button controlling a light.
  • A Contact Item monitors the actual state of the light.
  • Users can use real buttons to turn on/off independently of OH.
  • The real buttons are not monitored by OH.
    I wanted motion-activated lights with timers, but overridden by users pressing buttons.

I set up three Items -
A Switch bound to the “pushbutton” output
A Contact bound to the “light monitor” input
A Switch bound to nothing, “proxy”, representing OH’s expected light state. (this is the one to put on your sitemap)

Then some rules -

** Triggered by a command to “proxy”, either ON or OFF, compare the command with the current “light monitor” - if they don’t match, turn ON the “pushbutton” output, simulating a press. If they do already match, obviously we do nothing.

** Triggered by a change in “light monitor” input, check the state of “pushbutton”
If “pushbutton” is ON, this was a OH triggered change in the light, so we can now release (command OFF) the pushbutton.
Else if “pushbutton” is OFF, this was a user button press change. We just update (not command) the proxy to reflect the new light state.

Motion detection rules and timers do not operate the real switch, they send commands to the “proxy” instead.

My rules are more complicated, with another non-bound Item representing “Manual override” which gets set in the second rule, and uses a timer to unset itself after an hour or so. While “Manual” is set, the motion detections and any timers they start etc. do not activate the light (a simple check in the first rule).

2 Likes
3

Thats it. I misunderstood the autoupdate function. Thanks for your detailed answer. That helped me solving it:
The setup in the house is:

  • Hardware push buttons
  • Tinkerforge (Industrial Digital Out)
    -> both are connected to a relay and work on the same voltage level. The relay has two potential-free outputs. One for the light itself and one connected to tinkerforge to monitor the state (IO-16)

The OH setup is now very similar to yours:
Items:

  • Proxy_light_switch with no binding (on sitemap to provide light state and ON-OFF-function)
  • Light_switch with binding to tinkerforge (Industrial Digital Out) switch which itself switches the hardware relay/light on. (Due to the hardware relay which expects a push (on-off) a rule sends command off when on was received.)
  • Contact bound to IO-16 tinkerforge module that monitors the state of the relay.

Rules:

  • Contact switch checks for change from open to closed and vice versa and posts the update to the proxy_light_switch. This brings the Proxy_light_switch always to the correct status, independent if the hardware push button was used or the OH push button. No command, just update.

  • The proxy switch is monitored by a rule. The rule checks first the status of the light, if its different from the received command, the light_switch (with push button rule) is triggered with a real command.
    In case OH is used to switch the light on or off the proxy is “double updated”. Because the contact switch posts the update of the relay to the Proxy_light_switch as well.

-> Solved!