Using autoupdate=false

  • Platform information:
    • Hardware: CPUArchitecture/RAM/storage rpi
    • OS: _what OS is used and which version_raspian
      Openhab v 2.3

I’m trying to understand how the autoupdate=false. I read the wiki and several other posts including this one: Autoupdate = false

but not really understanding how to implement. my use case is that i have fans in the greenhouse that turn off/on based on temp rules (lots of great help with that one and works like a champ). But there are times I want to override the rules and run the fans. It looks like autoupdate=false allows me to do that.

My impression is that I setup an identical item that connects to my current fan/item and use this to create a new switch that can turn “on” and then it will not update the item, ie not turn the fan off when the temp falls? hmm, does that make sense?
In any case, this is my item:

Switch SingleSpeedFan "Left Fan" <switch> (persist,gAllFans)  [ "Switchable"]
    { mqtt=">[broker:cmnd/sonoff-00th161/POWER:command:*:default],
            <[broker:stat/sonoff-00th161/POWER:state:default]" } 

Through my reading you have to create a rule as well?


autoupdate = false was created to handle the case where you have a device that automatically report’s its state changes to OH. Imagine the following scenario.

  1. user clicks on sitemap to send ON command to an Item
  2. Item forwards the ON command to the binding
  3. If autoupdate=true, the Item changes state to ON. If autoupdate=false the Item remains OFF.
  4. There was an error and the device never turned OFF.

If you are using autoupdate=true (which is the default) then the Item will be set to ON and everything will assume that the device is ON. If you use autoupdate=false, the Item will remain OFF because we never received an update telling us that it actually turned OFF.

So it was created to give OH the ability to more closely represent the state of devices in the unfortunately rare case where the devices positively report back they state to OH when they change state.

Probably not. I think what you are looking for is Design Pattern: Manual Trigger Detection. What you need it a way to distinguish between an incoming update that was caused by your Rule versus one caused by flipping the switch some other way.

I do something similar with my lighting. When it is cloudy the light turns on during the day. However, is someone manually turns on/off the light during that time of day then the light will stay in that state and no long turn on or off as the cloud conditions change.

// Theory of operation: any change in the relevant lights that occur more than five seconds after
// the change to DAY or after a change caused by cloudy is an override
rule "Watch for overrides"
  Member of gLights_ON_DAY changed
  // wait a minute before reacting after vTimeOfDay changes, ignore all other times of day
  if(vTimeOfDay.state != "DAY" || vTimeOfDay.lastUpdate("mapdb").isAfter(now.minusMinutes(1).millis)) return;

  // Assume any change to a light that occurs more than n seconds after time of day or cloudy is a manual override
  val n = 5
  val causedByClouds = vIsCloudy.lastUpdate("mapdb").isAfter(now.minusSeconds(n).millis)
  val causedByTime = vTimeOfDay.lastUpdate("mapdb").isAfter(now.minusSeconds(n).millis)

  if(!causedByClouds && !causedByTime) {
    logInfo(logName, "Manual light trigger detected, overriding cloudy control for " +
    postUpdate("_Override", "ON")

// Theory of operation: If it is day time, turn on/off the weather lights when cloudy conditions
// change. Trigger the rule when it first becomes day so we can apply cloudy to lights then as well.
rule "Turn on lights when it is cloudy"
  Item vIsCloudy changed or
  Item vTimeOfDay changed to "DAY"
  // We only care about daytime and vIsCloudy isn't NULL
  if(vTimeOfDay.state != "DAY" || vIsCloudy.state == NULL) return;

  // give the side effects of time of day time to complete
  if( == "vTimeOfDay") Thread::sleep(500)

  logInfo(logName, "It is " + vTimeOfDay.state.toString + " and cloudy changed: " + vIsCloudy.state.toString +", adjusting lighting")

  // Apply the cloudy state to all the lights in the weather group
  gLights_ON_WEATHER.members.forEach[ SwitchItem l |

    val overrideName ="_Override"
    val override = gLights_WEATHER_OVERRIDE.members.findFirst[ o | == overrideName ]

    if(override.state != ON && l.state != vIsCloudy.state) l.sendCommand(vIsCloudy.state as OnOffType)

    if(override.state == ON) logInfo(logName, + " is overridden")

At a high level, any change to the light that takes place 5 seconds or more after a schedule/expected state change is treated as an override of the usual Rule behavior.


Thanks Rich, darn, thought I had found a simple answer! I like simple…

I will look through your rule example and see what I can figure out. I have feeling we will want to override our heater this winter too so this would be very helpful.