What are your top 3 automations

wow. I want that magic mirror! :slightly_smiling:
is there a way to have an English diy?

My inspiration for the magic mirror is this project (English): https://www.raspberrypi.org/blog/magic-mirror/

However, the openhab integration is not included there and I did not yet write anything about the software of my mirror. Maybe I’ll do that if I find some time, but there are so many things with higher priority at the moment… :wink:

Oh my… Well if you don’t, I’m going to try and replicate it. This is probably one of the coolest magic mirror’s I’ve seen to date… Thanks for posting.

What bluetooth sensors do you use?

Raspberry Pi 3, Raspberry Pi Zero W, and BT dongles plugged into older Raspberry Pis that don’t have BT on the board. These machines are already installed in these locations with other jobs so deploying the BT there is just because of opportunity. I’ve not deployed any specifically to get BT sensing capabilities.

I use sensorReporter or reelyActive to detect the presence of BT devices nearby. Unfortunately, reelyActive only sniffs for broadcast BTLE messages and most devices use a random MAC that cycles frequently so it isn’t much good for detecting specific devices (e.g. Rich’s iPhone is present). sensorReporter is fiddly and needs a lot of tuning to prevent false positives and false negatives.

For now, I’ve managed to get my network based phone detection reliable enough that I’ve actually turned off the BT sensors for now. I will probably go back to reelyActive at some point if I ever have the opportunity to deploy more Pis and what not around the house. I can then use them to keep track of what room, or even what floor our phones are on. I might be able to do something interesting with that information…

Thanks for the detailed reply. How does the network based phone detection identify which room you are in?

It doesn’t. Determining what room my phone is in is a future project that I may never get around to implementing. I just use the network to determine whether one of us is home for presence detection. iPhones are notoriously difficult to detect on the network using simple approaches because they go to sleep when not being used and stop responding to pings. The ne Network binding addresses this by adding in the ability to do an arping. I’ve implemented an older approach that uses hping3 to force the iPhone’s network to wake up and arp to see if it is online. There is also and iCloud integration thread that lets one query the location and other information about the iPhone from Apple’s iCloud.

But if you are interested in tracking a phone’s location on a room by room basis using WiFi and have Android based phones, check out FIND (search github and these forums) which uses the signal strength of all the WiFi APs your phone can see to triangulate its position in your house.

I have set a “fixed” offset on the Astro Sun Local set#event. I’m using this to turn on lights in the evening.

I want to predict the need to turn on a light based on how bright it is. OK, I could deploy light sensors. So, this is in search of a different (OK, cheapskate) approach… This falls into the “I’m sure it is possible, anything is possible” category. The question is how? And has anybody done it?

Use a local weather conditions to determine the cloud cover and use that to determine if I should turn the lights on earlier than the set#event.


P.S. My #1 is Nest control & my #2 is lighting control. #3 will come when I master these :wink:

This is essentially what I do. Honestly, I’d recommend investing the $6 in a NodeMCU with a photoresistor. I would say that the cloudy approach is maybe 50% useful. But since you ask, here it is. Note the following:

I’ll let you look at the DPs for the Time of Day stuff.

I’ve created two Groups for each time of day, one Group to contain those lights that should turn on at the start of that time period and another to contain those lights that should turn off at the start of the time period. I’m using Associated Items naming. I’ve also a Group for those lights that should turn on and off when it is cloudy as well as a Group to store the override flags (i.e. when a light is manually turned ON or OFF, do not change that light based on how cloudy it is, just leave it ON or OFF until the next time period).

Group:Switch:OR(ON, OFF) gLights_ON_MORNING    (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_MORNING   (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_DAY        (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_DAY       (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_AFTERNOON  (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_AFTERNOON (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_EVENING    (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_EVENING   (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_NIGHT      (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_NIGHT     (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_BED        (gLights_ON)
Group:Switch:OR(ON, OFF) gLights_OFF_BED       (gLights_OFF)
Group:Switch:OR(ON, OFF) gLights_ON_WEATHER

The following Rule turns on/off the light based on the time of day:

val logName = "lights"

// Theory of operation: Turn off the light that are members of gLights_OFF_<TOD> and
// then turn on the lights that are members of gLights_ON_<TOD>. Reset the overrides.
rule "Set lights based on Time of Day"
  Item vTimeOfDay changed
  // reset overrides

  val offGroupName = "gLights_OFF_"+vTimeOfDay.state.toString
  val onGroupName = "gLights_ON_"+vTimeOfDay.state.toString

  logInfo(logName, "Turning off lights for " + offGroupName)
  val GroupItem offItems = gLights_OFF.members.filter[ g | g.name == offGroupName ].head as GroupItem
  offItems.members.filter[ l | l.state != OFF ].forEach[ l | l.sendCommand(OFF) ]

  logInfo(logName, "Turning on lights for " + onGroupName)
  val GroupItem onItems = gLights_ON.members.filter[ g| g.name == onGroupName ].head as GroupItem
  onItems.members.filter[ l | l.state != ON].forEach[ l | l.sendCommand(ON) ]


Here is the Rule that runs when the isCloudy Item changes. I only adjust the lights based on coudy conditions during the DAY.

// Thoery 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
  // We only care about daytime
  if(vTimeOfDay.state != "DAY") return;

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

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

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

          val overrideName = l.name+"_Override"
          val override = gLights_WEATHER_OVERRIDE.members.findFirst[ o | o.name == overrideName ] as SwitchItem

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

          logInfo(logName, l.name + if(override.state == ON) " is overridden" else " is not overridden")

Notice how I only turn on/off the light if the associated override switch is OFF.

Next we have the rule that detects when there is a manual override on a light:

// 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_WEATHER
  // 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 " + triggeringItem.name)
    postUpdate(triggeringItem.name+"_Override", "ON")

This rule assumes that any change in state to a member of the weather controlled lights that occurs more than five seconds is a manual override and the override switch is set to ON.

Finally, how is vIsCloudy populated? Like I said before, I use Wunderground. There is a binding now but if you want to use HTTP directly there is a posting Comprehensive Wunderground using HTTP Binding Example that shows that.

Notice, with the above you can have any number of Lights and you can control their behaviors through Group membership alone. If you add or remove Lights or want to change a Light’s behavior all you have to do is change its membership. You never have to touch the Rules.

Finally, I just updated a lot of these rules to take advantage of changes to OH 2.3 (Member of Rule trigger) so there may be a bug that I’ve not seen yet in them. But it has been running for about a day and this part seems to work.



Unbelievably, I can pretty much follow this! Very comprehensive and thorough. I definitely have a lot to learn when it comes to rules. Your structured design ensures proper and consistent behavior. I had already begun to think of modularizing “common code”. For example, the rules that determine if we’re home or not based on location or the state of certain sensors in the house. Your Design Patterns formally codifies what I had in mind.

I do have one quick question… what is “mapdb” in this “.lastUpdate(“mapdb”).isAfter(now.minusMinutes(1).millis)” syntax?


That makes me happy. :smiley:


See Design Pattern: Group Based Persistence and https://docs.openhab.org/configuration/persistence.html#persistence-extensions-in-scripts-and-rules

tl;dr, I use MapDB for restoreOnStartup to restore all my Items to whatever state they were in when OH went down or the .items file was saved. And I do so for all of my Items. When you make calls to the persistence methods on an Item, you can specify which persistence engine you want to use to pull the result from. In this case I’m pulling the data from MapDB instead of InfluxDB because I know I store ALL of my Items in MapDB but only those Items I want to chart in InfluxDB. I could set MapDB as my default persistence engine and not pass in the name but I like to be explicit where I’m pulling the data from.


By any chance did you post your fan recirculation rule anywhere? I am trying to write a rule to turn on and off my AC fans for 3 minutes every 45 minutes or so and thought why reinvent the wheel if you already posted it somewhere. If not, what would you suggest the best approach might be, Timers? Expire binding? I do have a Recirculation dummy switch setup so that I can turn it off manually on my UI.


I’ve posted it before somewhere, maybe even above. But my rules work more like a thermostat than what you are describing.

When the main floor and/or the top floor gets warmer than the target temp and warmer than the basement I turn on the fan for 15 minutes (the runtime is controlled by the Nest).

For your use case create a rule with a Cron trigger every 45 minutes. Then create a Switch item linked to your fan and the expire binding set to send command off after three minutes. In the rule send the on command.

The rule will trigger, turn on the fan. Three minutes later the expire binding will turn off the fan. Then 42 minutes later the role will run again.

Thanks for the help. That seems clear enough.

  1. All Of in 15 Sec
    before i leave the house it gives me some time and then all is off

2.Morning , turn on TV and put news ch, Lights, a litle music , and when i leave for work all off again :slight_smile:

  1. Game on
    turn on game(cs), switch PC to headphones, turn off gameing room lights
  1. I use OH to monitor water detectors placed throughout my home to detect leaks in places not easily detected such as by the well pump, water heater, washing machine etc. We live in the country so we have a well pump and a sump pit adjacent to the well pressure tank. I installed a z-wave switch on the well pump and another beside the well pressure tank. I piped in a 120v solenoid valve to the pressure tank and routed the “blow down” pipe to the sump pit. If any water detectors sense water my well pump turns off and the switch at the pressure tank turns on, opening the solenoid valve which removes all water pressure in the house. OpenHab reports a text message to my phone to report the incident.

  2. I use a relay available by BRK wired smoke detectors to close a Aeotec z-wave contact, which in turn alerts me via text message if we’re not home.

  3. OpenWeatherMap turns our roof/rain gutter heaters on/off if >=15 or <=35 deg. f, using an outdoor z-wave switch.

  1. Sprinkler system based on weather, moisture level, sun, etc… Saves us tons of money!
  2. Camera system (BlueIris) and OH. Multiple rules based on camera triggers. Amazon packages, front door. Speakers throughout the house speaks if a package has arrived, someone is at the front door, etc.
  3. Security System. Kept most of ADT sensors, replaced brain with a Vista 20P, hooked up to AlarmDecoder and monitored by Eyez-ON. We don’t even use the pinpad any more, we do it with DIY keyfobs and fingerprint :slight_smile: Disarms the alarm, unlocks the door. I added a new cool thing too. If EVER i lost my keybob, lost ALL my fingers, I can still issue a command via voice using a super long secret phrase, and the DIY google assistant (Orange Assistant) behind the door will unlock the lock for me.

Can you elaborate more on 1 and 3.
Would love to hear more about the sprinkler system and the FYI finger print hardware.

For #1, I have moisture sensors attached to a pic (atmega328). I added 433mhz transmitter. I didn’t go with esp8266 due to battery consumption. This is solar powered so it has to conservative on power. Soil moisture level is transmitted to OH who then decides if the sprinkler needs to turn on. I have it set to 25% moisture. I kept the existing sprinkler “brain” but hooked up to the terminals that turn them on. This way I can control the sprinkler via the “regular” way as well as the OH way.

For #3, it’s esp8266 based. A fingerprint module is used to capture identity. It also has a 125khz rfid reader on it. The fingerprint reader is just there “just because I can” lol but we find out that we use the key fobs more often because it’s quicker. You just tap and that’s it. Once identity is known, the esp will send command to my alarm and not to OH. My alarm panel is driven by a Vista20P connected to an orange pi through the serial port. My OH is connect to the panel through the same orange pi via TCP running alarm decoder code.

The door is locked by a hacked August lock. August locks have no public API so I went ahead and hacked it. I might be publishing this since I have not seen this done before anywhere online. The August lock is simple. It’s driven by a STM32 chip, and simple motors to turn the knob. The hardest part for me was determining when to stop the motor. Well it uses a super tiny LIS3DH accelerometer to know the position of the knob. Its a simple thing but the hardest part is soldering wires on that thing. If the angle is 90 degrees then you know the bolt is in locked position. LIS3DH is smaller than the tip of a pencil eraser!

Thank you. Very interessting. Learned today there are more cracy people out there. We are not alone … . ,-)