- Indoor motion detectors trigger lights dimmed after sunset and before sunrise
- A switch to suppress motion detectors for a short period (2min) - to pass hallways in darkness
- If last smartphone disappears from WiFi and window/door contacts are open, that smartphone is notified
-
Magic mirror in entrance hall that shows a floor plan of all open windows/doors and all lights that are switched on
wow. I want that magic mirror! 
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…
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.
Mike
P.S. My #1 is Nest control & my #2 is lighting control. #3 will come when I master these 
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:
- it makes heavy use of a lot of the Design Patterns including [Deprecated] Design Pattern: Time Of Day, Design Pattern: Associated Items, Design Pattern: Separation of Behaviors, Design Pattern: Manual Trigger Detection, Design Pattern: Human Readable Names in Messages (how I map the current conditions to whether or not it is cloudy), and Design Pattern: Working with Groups in Rules. These Rules probably use the biggest combination of DPs per line of code in all my Rules
- it uses Wunderground for the conditions
- I made a best guess in mapping the reported weather conditions to whether or not is should be cloudy or not
- It might work better for people who live in a place that doesn’t have such localized weather. Where I live I can see it pouring rain a few miles away while it is sunny where I stand.
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
Group:Switch:OR(ON, OFF) gLights_WEATHER_OVERRIDE
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"
when
Item vTimeOfDay changed
then
// reset overrides
gLights_WEATHER_OVERRIDE.postUpdate(OFF)
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) ]
end
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"
when
Item vIsCloudy changed or
Item vTimeOfDay changed
then
// 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")
]
end
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"
when
Member of gLights_ON_WEATHER
then
// 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")
}
end
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.
6 Likes
Thanks!
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?
Mike
That makes me happy. 
https://docs.openhab.org/addons/persistence/mapdb/readme.html
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.
Rich,
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.
Thanks,
Mike
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.
- 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 
- Game on
turn on game(cs), switch PC to headphones, turn off gameing room lights
-
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.
-
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.
-
OpenWeatherMap turns our roof/rain gutter heaters on/off if >=15 or <=35 deg. f, using an outdoor z-wave switch.
- Sprinkler system based on weather, moisture level, sun, etc… Saves us tons of money!
- 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.
- 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
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!