Hello,
i have some rules with the condition “changed from OFF to ON”. unfourtanately everytime i restart my openhab the default item state is NULL so i need to write a second condition with NULL to ON.
is it possible to set the default state to OFF?
OH2 from yesterday on rpi2 (openhabian)
thank you for help.
regards
Could you change your condition simply to changed to ON? Then you’re not concerned with what the prior state was.
Exactly what @watou said.
Additionally in other constellations you may need to set items after startup to a specific state. Add such a rule (examples given):
rule "Init"
when
System started
then
// let openHAB settle and give other rules the chance to fire
createTimer(now.plusSeconds(180)) [|
if (TimerActive.state == NULL) TimerActive.postUpdate(OFF)
DefaultHeatingTemp.postUpdate(21.0)
if (KodiSummary.state == NULL || KodiSummary.state == "") KodiSummary.postUpdate("(unknown)")
]
end
Hey guys,
thank your for your replies. that was exactly what i was looking for.
when i read in the documentation “Item changed [from ] [to ]” i thought i need to tell him both states. i did not think of simply give him just one state. Thanks!
to use the system started trigger would solve my problem too. Perfect! =)
Regards
From my own experience - some times its better to check if the value is “not ON” (!ON) ) instead of OFF. Just my 2c 
good point, thanks!
i want to show you my rule for a harmony hub and maybe you have ideas how to optimize that.
I want to say “Alexa, start SKY TV” and it turns everything on as defined with my harmony hub. I need to change the state of everything else to OFF then, because i may want to say “start kodi” but if kodi was started before, it will not start again, because it is already in the state of started.
if there is a better solution for that, then i am grateful for any ideas how to optimize the construct
to switch everything off i made an extra rule called “alle Media Geräte aus” which is alway on if a acitvity was started. so i am able to say “alex, switch all devices off”.
the last small problem is, that if i am now saying “alexa, turn on sky tv” alexa asks me which device (because i have “sky tv” and “sky beamer” and i need to repeat what i was saying. very annoying. siri dont ask me that, she simply does her job
items:
//Harmony
String Harmony_Activity "Current Activity [%s]" (Wohnzimmer) { channel="harmonyhub:hub:HarmonyHub:currentActivity" }
Switch Harmony_skytv "Sky Fernseher" (Wohnzimmer) [ "Switchable" ]
Switch Harmony_skybeamer "Sky Beamer" (Wohnzimmer) [ "Switchable" ]
Switch Harmony_koditv "Kodi Fernseher" (Wohnzimmer) [ "Switchable" ]
Switch Harmony_kodibeamer "Kodi Beamer" (Wohnzimmer) [ "Switchable" ]
Switch Harmony_alles "alle Media Geräte" (Wohnzimmer) [ "Switchable" ]
rules
rule "Sky TV schauen"
when
Item Harmony_skytv changed to ON
then
Harmony_Activity.sendCommand("24360745")
postUpdate(Harmony_koditv, OFF)
postUpdate(Harmony_skybeamer, OFF)
postUpdate(Harmony_kodibeamer, OFF)
postUpdate(Harmony_alles, ON)
end
rule "Sky Beamer schauen"
when
Item Harmony_skybeamer changed to ON
then
Harmony_Activity.sendCommand("24360747")
postUpdate(Harmony_koditv, OFF)
postUpdate(Harmony_kodibeamer, OFF)
postUpdate(Harmony_skytv, OFF)
postUpdate(Harmony_alles, ON)
end
rule "Kodi TV schauen"
when
Item Harmony_koditv changed to ON
then
Harmony_Activity.sendCommand("24361209")
postUpdate(Harmony_skybeamer, OFF)
postUpdate(Harmony_kodibeamer, OFF)
postUpdate(Harmony_skytv, OFF)
postUpdate(Harmony_alles, ON)
end
rule "Kodi Beamer schauen"
when
Item Harmony_kodibeamer changed to ON
then
Harmony_Activity.sendCommand("24360748")
postUpdate(Harmony_koditv, OFF)
postUpdate(Harmony_skybeamer, OFF)
postUpdate(Harmony_skytv, OFF)
postUpdate(Harmony_alles, ON)
end
rule "Alle Media Geräte aus" //Switch everything off and update the activities
when
Item Harmony_alles changed from ON to OFF
then
Harmony_Activity.sendCommand("PowerOff")
postUpdate(Harmony_koditv, OFF)
postUpdate(Harmony_skybeamer, OFF)
postUpdate(Harmony_kodibeamer, OFF)
postUpdate(Harmony_skytv, OFF)
postUpdate(Harmony_alles, ON)
end
Note the difference in meaning between
Item X changed to ON
and
Item X received command ON
both are valid and both have their purpose, but the first reacts to the state of the item having changed to ON, while the second reacts to some source having commanded the item to turn ON. changed to ON might actually work in practice in both situations, but only as a side effect of the item automatically adopting the command as its new state when the state of the item was not previously ON. received command ON will trigger every time the ON command is sent to the item, regardless of the of the item’s state.
ah okay, so i could save all the postupdates by simply changing the trigger from changed to received command. because then it does not matter if an activity is in the state “on” although it is not really switched on and therefore it would not turn on if i use the trigger changed to on, but it should if i use the trigger received command ON, right?
thanks, very good point!
Or use persistence with restoreOnStartup. I don’t think (could be wrong) that the changed to ON rule will trigger when restoreOnStartup initialized the Item with whatever it was when the .items are initialized.
The docs use the standard convention of putting optional parameters in [ ]. However that convention may not be widely understood so perhaps a note saying as such is needed. Were you looking at the wiki or the OH 2 docs?
I always recommend using the sendCommand/postUpdate Item methods rather than the actions:
Harmony_koditv.postUpdate(OFF)
Note: postUpdate changes OH’s internal state for an Item. It does not forward that new state to the binding and on to the device. I don’t know how all this Alexa/Harmony stuff interacts but suspect sendCommand is the more correct choice. Could be wrong. I didn’t spend too much time trying to figure out your exact use case.
This is almost—but not quite—universally true. When you want your script to cause a change to a system bound to openHAB, sending a command to an item is the way to go.
I hate how often this statement applies in OH right now.
I know what you mean, but it’s for a good reason! (one of the most ominous phrases in the history of technology 
).
It’s really elegant and concise to have a construct like:
Number RoomTemp "[%.1f]" {
ecobee="<[your_therm_id#runtime.actualTemperature]",
mqtt=">[mybroker:/myhouse/room/temp:state:*:default]"
}
With a single item, you have a gateway between a proprietary technology and an MQTT broker. The < and > could be reversed (and the binding config strings changed) to have a gateway operate in the other direction as well. This is all possible because updating item states can in fact cause the binding to react. Some bindings react to state updates, others don’t. Making the list of bindings that do something when their bound items’ states are updated is a big job that I won’t bring upon myself.
I wish more bindings allowed this, so this capability could be more universally used without having to need rules to trigger on changed and then call sendCommand in the rule body.
Shouldn’t the above have a comma between the two binding configs? I’ve never had a need to bridge in this way. Of course, I don’t think OH 2 supports this sort of thing does it? I’ve not seen channels that do this. In particular I’ve seen several threads with the Exec binding where people used to do things like this and no longer can in the 2.0 version.
Shouldn’t this be the responsibility of binding authors to document this sort of thing?
Agreed. Do you know if there is thought on letting this sort of thing work with channels?
Good catch; fixed!
I think binding authors ought to document all features and functionality, yes.
It would be a pity if this were no longer possible with new bindings. I don’t know the answer.
Hey guys, i didnt really get what you were talkin about. ^^ is the constellation i used for my rules ok or should i change something?
rule "Sky Beamer schauen"
when
Item Harmony_skybeamer changed to ON
then
Harmony_Activity.sendCommand("24360747")
postUpdate(Harmony_koditv, OFF)
postUpdate(Harmony_kodibeamer, OFF)
postUpdate(Harmony_skytv, OFF)
postUpdate(Harmony_alles, ON)
end
@watou @rlkoshak we should try to arrange all these relations in docs!
I have a related question actually. Imagine the following scenario:
Ceiling_Light can be either turned on/off by openHAB command or by pressing the integrated wall switch.Door_Sensor turns Ceiling_Light on for 3 minutes (Timer), then offMinimal example (reduced/incomplete but you’ll get the idea):
rule "rule 1"
when
Item Door_Sensor changed from CLOSED to OPEN
then
//... logic...
Ceiling_Light.sendCommand(ON)
//...
timer = createTimer(deadline) [|
//... the normal timer logic
Ceiling_Light.sendCommand(OFF)
]
end
rule "rule 2"
when
Item Ceiling_Light received update
then
if (timer != null) {
timer.cancel
}
end
As a general rule, if you are asking a device to do something you should use sendCommand.
If you are updating the state of something based on something (e.g. a sensor is telling you a light is on so update the light switch’s state to ON) use postUpdate.
No, there isn’t. This is a complicated one that I ended up solving by creating the Dead Man’s Switch Design Pattern.
The tl;dr is create a state that defaults to “MANUAL”. Whenever the device is controlled by a Rule this state gets set to “RULE” (you can use multiple states if you need to distinguish between startup, timers, etc) while the rule is running and then goes back to MANUAL. Have a rule that triggers any time the device receives an update. If the state is “MANUAL” you know this is a command that was triggered from the device or from the sitemap. If not you know it came from a Rule. With this information you can check in the second rule where the command came from and behave accordingly.
I haven’t moved this design pattern into its own thread yet because it is complicate, a little brittle (because the timing needs to be managed) and this use case doesn’t come up very often.
I use it to set an override flag on my lights. During the day if the weather says its cloudy the lights turn on. If one of us manually turns the light on or off we want it to stay that way, overriding the weather behavior.
It turns out to be less useful than it could be in my case because the physical switches don’t report their current state and the refresh is too long.
To expand your minimal example:
var String whoCalled = "MANUAL"
rule "rule 1"
when
Item Door_Sensor changed from CLOSED to OPEN
then
whoCalled = "RULE"
//... logic...
Ceiling_Light.sendCommand(ON)
//...
timer = createTimer(deadline) [|
//... the normal timer logic
Ceiling_Light.sendCommand(OFF)
]
Thread::sleep(100) // give the commands a chance to hit the bus and the rule below to trigger
whoCalled = "MANUAL"
end
rule "rule 2"
when
Item Ceiling_Light received update
then
if(whoCalled != "RULE") {
if (timer != null) {
timer.cancel
}
}
end
I know this is a rather old discussion. But there is something about it I really often face, when I’m trying to solve issues in my OH setup.
There are really good functions in OH, but they are so poorly documented! The official site describes things so superficially, I always miss the details like the explanation of the syntax, the complete description of features, special cases and so on. It’s really a pain!
For me as a developer this would not be acceptable for my own work.
Without the threads in the forums, many issues would not be solvable. Thanks!
We welcome any issues or PRs you might submit to improve anything in the docs you find to be superficial or poorly documented. It’s a volunteer effort. If the current volunteers are not producing docs to your standards there’s only one way to fix it and become a volunteer yourself.
Though it is important to realize that the above nearly three year old discussion and explanation isn’t applicable any more so that’s probably why you might not find it in the docs.
Also, as John said, it used to depend on the individual bindings supporting it so you would have to go to the individual binding docs to read about it.
Today, there is a generic way to do it and it is in the docs. It’s the follow Profile.
Hi rlkoshak,
sorry I didn’t want to offend anybody. I’m open for helping to improve things. But currently I don’t feel in the position to do that for the documentation, as I have more questions than answers. This will change hopefully and then I will be happy to contribute.
Maybe I just didn’t look at the right places.
I want to give you two examples of what I mean.
The Dimmer item accepts the commands INCREASE and DECREASE. I like features like that because they help to minimize the code inside rules. I don’t have to query the current state value to increase it by one and set it. Also I don’t have to check for the boundaries of 0 and 100.
Now I have two lamps I want to drive synchronously by the same remote control. So I created a virtual Dimmer item, which is not bound to a channel, to increase or decrease and populate the new value to both lamps by a rule. Unfortunately the virtual Dimmer item does not react in any way, when I do an INCREASE or DECREASE on it. This is unexpected to me and it’s not documented anywhere.
Then we have the min and max attributes I can define for a Number channel:
...
Type number : WhiteTemperature
[
stateTopic = "stat/LAMP2/RESULT", transformationPattern = "JSONPATH:$.CT",
commandTopic = "cmnd/LAMP2/CT",
min = 153, max = 500
]
...
I can define them and they are respected by PaperUI. But how can I do anything with these attributes in a rule? So far I didn’t find anything in the documentation.