[SOLVED]Set default item state to OFF instead of NULL

From my own experience - some times its better to check if the value is “not ON” (!ON) ) instead of OFF. Just my 2c :wink:

5 Likes

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 :wink:
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 :wink:

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.

3 Likes

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 :smile:).

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.

2 Likes

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.
  • A first rule triggered by Door_Sensor turns Ceiling_Light on for 3 minutes (Timer), then off
  • A press on the wall switch should switch to that state but a second rule should also delete the timer, leaving the light in one state indefintely
  • (Maybe I’m confused right now) How do I hinder the first rule from triggering the second rule? Is there a trigger to act on updates received from binding only?

Minimal 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
3 Likes

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.

How are you “doing” that?

A review of openHAB philosophy may be in order around Items.
An Item is an abstract approximation, a model, of some simple device.
Dimmer is a good example. It has a state, just one state, a numeric 0 to 100 percentage.
You can send that Item commands such as ON or INCREASE from UI or rules. Note, those are not related to the state directly.

In the idealized world, those commands get passed via a binding to some real real device. It’s the binding’s business how to manage that,probably using parameters you’ve set in the channel and Things you’ve defined for it. Maybe it sends “dim up”, maybe it sends “127”.

In this generalized model, the device responds with a new status at some time later - “power level G” or “55%” or whatever. The binding’s job is to unravel and translate into a suitable state update for the abstract dimmer Item that we started with - a simple 0-100 number.

In real life it’s never that simple, but understanding the ‘why’ of the core operation is really helpful. For example, clearly a command to an Item is different to updating its state, and causes different follow on effects.

Questions are helpful too, though it would probably be best to post them on a new thread.

OK, so first of all, a more appropriate way to implement this is using a Group:Dimmer. Put both Dimmers into that Group and then send your INCREASE/DECREASE commands to the Group Item. The command will be passed down to the members.

See https://www.openhab.org/docs/configuration/items.html#group-type-and-state for where this is documented:

Groups do not only aggregate information from individual member Items, they can also accept commands. Sending a command to a Group causes the command to be sent to all Group members. An example of this is shown by the second group above; sending a single ON or OFF command to that group turns all lights in the group on or off.

As for why your virtual Item didn’t do anything may be a gap in the docs but I’m not sure where that gap can be filled.

NULL is it’s own state type and any Item can have a NULL state.

What I suspect is happening here is that the behavior that occurs when a State is NULL and you issue an INCREASE/DECREASE command is defined by the binding. Some bindings may choose to ignore the command because there is no base number to increase/decrease from, the Item is NULL. Others may treat the command as an ON command. Others might have still different behaviors. If this is the case, the documentation for that will be in the README for the binding, or if it’s not there that is where it belongs.

If that isn’t the case, this indeed should be added to the docs. Though, as evidenced with your first example, there are a lot of docs full of tiny little details that you have to remember and get right. In my experience, adding more to the docs mostly just means that those of us with experience can link the the docs to show you what you missed.

There is no documentation for it because you can’t. I don’t want to be flippant, but it’s unreasonable to expect to document everything that isn’t possible.The only thing you can access in Rules are:

If it’s not there it’s probably not supported. And as should have been made clear in the Concepts section of the docs (if not suggestions are welcome), everything you use in the UIs and your automations (i.e. Rules) mostly deal with Items. So there shouldn’t be an expectation that you could access attributes of a Channel from a Rule.

Thanks that was a valuable hint. I will change my setup and use a Group:Dimmer.
Regarding the Min/Max attributes: How can the PaperUI then work with these? It accepts only values within the boundaries.

PaperUI doesn’t work with these. PaperUI just shows the Thing as you defined in your .things file. If you define the Things using PaperUI, than it lets you actually set these attributes but that is all.

It’s the binding, in this case the MQTT binding, that implements the logic that handles the min/max attributes. How it does so should be in the binding’s docs.