Upgrade to OH 3 => some mystic effects

Hi !

After upgrade to OH 3 i have a mystic effect in 1 rule which worked with OH 2 like charm…
To the point:
I switch my Light through a siemens Logo with real wired switches AND i can switch it with a bit written by OH to the PLC memory…

The effect is e.g. when light is ON and i switch it OFF via hardware the light goes back on…
(and when its OFF and i switch it on it goes back off)
Without OH its no problem.
And its diffucult to investigate w/o events.log because output in GUI is too fast…
The rule for it is
where Licht_Esszimmer is the logo output , FF_ESS is the item of OH switching and showing state and LS_ESS is the memory bit of the logo which switches the Output also.

rule “Switch Light Eating through Logo”
// Esszimmer
Item Licht_Esszimmer changed or // 1. light changed external
Item FF_ESS received command // 2. light changed internal
if(receivedCommand==ON || receivedCommand==OFF) { // ensure there was a received command, so second item triggered rule
if (Licht_Esszimmer.state != receivedCommand) { // only if state changed
else { // no trigger from proxy switch, so state changed externally
if (Licht_Esszimmer.state != FF_ESS.state) { // if state changed really
FF_ESS.postUpdate(Licht_Esszimmer.state) // update the state without triggering the rule

I’m a bit suspicious about all this.
There was a bug in OH3 where the info supplied with trigger events was not cleared between triggers.
i.e. with an Item change trigger you might find that receivedCommand still held an old value.
I don’t knowwhen that was fixed,but I suspect after OH3.0

In any case, if you think this rule is what is going wrong, add some logInfo() to see where it goes and what values it is using.

1 Like

Hi !

I tried with another rule (similar) and when i use

logInfo(“licht2.rules”, light_oh.state )

I get

2021-01-31 21:56:25.685 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘licht-1’ failed: An error occurred during the script execution: Could not invoke method: org.openhab.core.model.script.actions.Log.logInfo(java.lang.String,java.lang.String,java.lang.Object[]) on instance: null in licht

You have to give logInfo() two strings to work with. Try
logInfo(“licht2.rules”, light_oh.state.toString)

Ok , i started investigation and wait for the effect :slight_smile: but i want wo shrink a similar rule with groups
it seems that 1 part is never reached but its similar
When i set via app a member of group gL_OH to ON or OFF the part with Mark 3 4 and 5 is not executed

import org.openhab.core.model.script.ScriptServiceUtil
rule “Switch Light through Logo”
Member of gL_LOGO changed or
Member of gL_OH received command
val setitem = triggeringItem
val lightitem_logo = ScriptServiceUtil.getItemRegistry.getItem(setitem.name.split("").get(0) + "" + “LOGO”)
val lightswitch_net = ScriptServiceUtil.getItemRegistry.getItem(setitem.name.split("").get(0) + "" + “LSV”)
val light_oh = ScriptServiceUtil.getItemRegistry.getItem(setitem.name.split("").get(0) + "" + “LICHT”)
logInfo(“licht.rules”, “Mark 1” )
logInfo(“licht.rules”, “Mark 2” )
logInfo(“licht.rules”, light_oh.state.toString )
if(receivedCommand==ON || receivedCommand==OFF) { // ensure there was a received command, so second item triggered rule
if (light_oh.state != receivedCommand) { // only if state changed
logInfo(“licht.rules”, “Mark 4” )
logInfo(“licht.rules”, “Mark 5” )
else { // no trigger from proxy switch, so state changed externally

if (lightitem_logo.state != light_oh.state) { // if state changed really
      logInfo("licht.rules", "Mark 6" )
        light_oh.postUpdate(lightitem_logo.state) // update the state without triggering the rule


Hi !

Ok it seems that i got it… at least at my last rule…
Regarding loginfo i figured out that the item which received the command, has during execution meanwhile the state to which command it was triggered.
2021-02-01 20:32:19.329 [INFO ] [penhab.core.model.script.licht.rules] - Mark 1
2021-02-01 20:32:19.331 [INFO ] [penhab.core.model.script.licht.rules] - Mark 2
2021-02-01 20:32:19.333 [INFO ] [penhab.core.model.script.licht.rules] - ON

so the line

if (light_oh.state != receivedCommand) { // only if state changed

will never be fullfill the if request.
Was there a change between OH 2.5 and OH 3.0 ?
I guess my first problem is also based to this, and the rule switch it back to “old” state on its own, when i change the state via the hardware switch.

Ciao Gerd

A command may never affect an Item’s state at all.
If it does, it is always with a delay, even if it is only a few mS.
So if you trigger a rule from a command, the state may or may not have changed by the time it gets to any particular line.

None of that is new in OH3 (but exact timings may differ on any platform).

I’m not sure exactly what you are trying to do, but if you are trying to workout if a state change was due to some recent openHAB command, or due to an external event, then you will need some way to “remember” when a command has recently been issued.

hi !

1st i want to switch an external item when i received a command (external is a flip-flop)
my actual solution is that when i received the command ON and the external Flip-Flop is OFF is set the trigger Bit for 500ms.
then if the command is OFF i do the same , so if the external is ON i also set the trigger bit.
last stepp is… if the external flip-flop state does not match the internal item state the internal item is updatet to the external state (needed if i switch with external HW Switch)

Ciao Gerd

Ah, like a pulse relay. I don’t use timing with mine, just listen for the change.

Switch Item Output_state - set autoupdate false for this one.
Switch Item pulse

rule "command to pulse"
   Item Output_state received command
   if (recievedCommand == ON && Output_state.state !=ON) {
   } else if (recievedCommand == OFF && Output_state.state !=OFF) {
   } // else no action needed

rule "state change"
   Item Output_state changed from ON to OFF or
   Item Output_state changed from OFF to ON  // ignore NULL,UNDEF changes
   if (pulse.state == ON) {
      pulse.sendCommand(OFF)   // release pulse
   } else {
      // detected an unexpected, external change

For added safety,it is smart to add an expire="3s,command=OFF" to the pulse Item in case of faults.

Ok actual i have to separate rules…
i try to migrate yours but with groups… therefor i need only one rule instead of 25 :slight_smile:
Ciao Gerd

Where i have to put it ?

Ciao Gerd

It was just a suggestion,in case of trouble. With no timer ,if the light never changes because of an error, the pulse will not get turned off.
Using expire on each of your pulse Items will make sure they eventually do switch off. During normal operation, it won’t do anything.

Exactly how you configure expire depends on how you configure your Items.