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
when
Item Licht_Esszimmer changed or // 1. light changed external
Item FF_ESS received command // 2. light changed internal
then
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
LS_ESS.sendCommand(ON)
Thread::sleep(500)
LS_ESS.sendCommand(OFF)
}
}
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
}
}
end
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.
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
Ok , i started investigation and wait for the effect 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”
when
Member of gL_LOGO changed or
Member of gL_OH received command
then
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
lightswitch_net.sendCommand(ON)
logInfo(“licht.rules”, “Mark 4” )
Thread::sleep(800)
lightswitch_net.sendCommand(OFF)
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
}
}
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.
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.
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)
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"
when
Item Output_state received command
then
if (recievedCommand == ON && Output_state.state !=ON) {
pulse.sendCommand(ON)
} else if (recievedCommand == OFF && Output_state.state !=OFF) {
pulse.sendCommand(ON)
} // else no action needed
end
rule "state change"
when
Item Output_state changed from ON to OFF or
Item Output_state changed from OFF to ON // ignore NULL,UNDEF changes
then
if (pulse.state == ON) {
pulse.sendCommand(OFF) // release pulse
} else {
// detected an unexpected, external change
}
end
For added safety,it is smart to add an expire="3s,command=OFF" to the pulse Item in case of faults.
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.
but i want wo shrink a similar rule with groups