That is true. Generally in the case of clouds I sometimes need the lights more than an hour earlier than my timer. But I just tell Google to turn on some lights, so although it would be great to eventually automate it, it will still be useful for my openHab installation to know when it is officially night and day, to trigger various stuff and be able to react correctly.
I’ll probably still eventually get a better lumination sensor for future.
Great write-up. I also live in SA, love OH, Xiaomi and their sensors and Yeelights. That’s pretty much the staple of my Smarthouse too, although I have a couple of Sonoff switches too (for example, one on my borehole pump). I still have to load custom firmware so that I can control it from OH.
I’ve been thinking about your thought on the electric gate for quite a while. WE sometimes accidentally trigger our remotes and open the gate, so I really want a way to know if the gate is open or not.
Problem is the Xioami sensors’s reception is not good enough, so I’m actually looking at either another gateway in my garage to solve the reception, or hacking a Sonoff SV (12v) to run directly off the gate’s circuit board.
Second problem with the Xiaomi sensors are that they are not really suitable for out-doors, so you’d have to get a better reed switch and magnet and then break open a Xiaomi door sensor and solder the wires to the existing reed switch (there are youtube videos where they do this).
The latter actually also made me think that you could use the Xiaomi door sensors as wireless transmitters for other outside PIR sensors and beams, meaning you could link those weather/water/catproof sensors to your existing setup.
On that note, do your cats trigger the motion sensors in your house?
Greetings fellow countryman!
That’s one issue I’m still working on. I actually realized the other day that the Xiaomi open sensor won’t work effectively, because of the space between the gate and gate motor (which is where I was going to play my sensor to prevent weather damage).
Perhaps modifying the sensor could work, and I’m already investigating that avenue.
Coincidentally I had a similar issue with the distance to the gateway, but luckily the kitchen is very close to the front gate, so tests revealed that it can connect to the sensor on the gate via Zigbee at that distance by putting a third gateway in the kitchen.I still need some research and then choices to make about this, but sadly I’m out of extra money this month, so I’ll have to continue next month!
Well yes.
But, the sensors seem to lose motion detection ability rapidly after about 2-3 meters though, so creative positioning of my sensors have helped prevent false detection caused by cats.
I’m actually next week going to implement my alarm in a ‘test’ phase, by having it log and also notify me when any of my current motion sensors are triggered. Then I’ll run it for a week, and check how many false positives I get to determine if the ranges are effective in preventing cat-detections.
–
On that note, I’ve actually found weird stuff with my ‘toilet’ motion sensor. The toilet is a separate small room, and I have a sensor pointing 45 degrees downwards directly at the toilet. So when you enter through the door you walk right under it and it triggers. What is weird is that very often if I just walk by the toilet door, the sensors seems to detect motion and triggers the light.
Its weird, cause the only motion it might detect is the toilet door moving slightly because movement of air when I walk passed? (the door is slightly ajar usually).
I always thought these were IR motion sensors, but now I’m wondering…
Thanks for the comments guys, so far very helpful. I’ll post some photos this weekend if I get a chance.
You could combine the astro binding and the weather binding with the cloud cover value in a rule.
This could work, but the nearest weather station is about 15km distance, so many false alarms for me. Thank you for the enlightenment. I never thought of it before
Just for an example for those who do have a weather station close enough.
Switch vIsCloudy "Cloud Conditions" <iscloudy> (gChart)
iscloudy is a custom icon I downloaded. gChart makes this Item be persisted for charting. See Design Pattern: Group Based Persistence.
I’ll not show the Weather Items but you can find them all here: Comprehensive Wunderground using HTTP Binding Example
rule "Is it cloudy outside?"
when
Item vWeather_Conditions changed
then
logInfo(logName, "New weather conditions: " + vWeather_Conditions.state.toString)
val isCloudy = transform("MAP", "weather.map", vWeather_Conditions.state.toString)
val newState = if(isCloudy === null || isCloudy == "false") OFF else ON
if(newState != vIsCloudy.state) logInfo(logName, "Setting isCloudy to " + newState.toString)
vIsCloudy.postUpdate(newState)
end
weather.map has a mapping from all the conditions that Wunderground supports to true or false to indicate whether the condition indicates it is cloudy.
# Cloudy or not
Light\ Drizzle=true
Heavy\ Drizzle=true
Drizzle=true
Light\ Rain=true
Heavy\ Rain=true
Rain=true
Light\ Snow=true
Heavy\ Snow=true
Snow=true
Light\ Snow\ Grains=true
Heavy\ Snow\ Grains=true
Snow\ Grains=true
Light\ Ice\ Crystals=true
Heavy\ Ice\ Crystals=true
Ice\ Crystals=true
Light\ Ice\ Pellets=true
Heavy\ Ice\ Pellets=true
Ice\ Pellets=true
Light\ Hail=true
Heavy\ Hail=true
Hail=true
Light\ Mist=true
Heavy\ Mist=true
Mist=true
Light\ Fog=true
Heavy\ Fog=true
Fog=true
Light\ Fog\ Patches=true
Heavy\ Fog\ Patches=true
Fog\ Patches=true
Light\ Smoke=false
Heavy\ Smoke=true
Smoke=true
Light\ Volcanic\ Ash=false
Heavy\ Volcanic\ Ash=true
Volcanic\ Ash=true
Light\ Widespread\ Dust=false
Heavy\ Widespread\ Dust=true
Widespread\ Dust=true
Light\ Sand=false
Heavy\ Sand=true
Sand=true
Light\ Haze=false
Heavy\ Haze=true
Haze=false
Light\ Spray=false
Heavy\ Spray=false
Spray=false
Light\ Dust\ Whirls=false
Heavy\ Dust\ Whirls=true
Dust\ Whirls=false
Light\ Sandstorm=false
Heavy\ Sandstorm=true
Sandstorm=true
Light\ Low\ Drifting\ Snow=true
Heavy\ Low\ Drifting\ Snow=true
Low\ Drifting\ Snow= true
Light\ Low\ Drifting\ Widespread\ Dust=true
Heavy\ Low\ Drifting\ Widespread\ Dust=true
Low\ Drifting\ Widespread\ Dust=true
Light\ Low\ Drifting\ Sand=true
Heavy\ Low\ Drifting\ Sand=true
Low\ Drifting\ Sand=true
Light\ Blowing\ Snow=true
Heavy\ Blowing\ Snow=true
Blowing\ Snow=true
Light\ Blowing\ Widespread\ Dust=true
Heavy\ Blowing\ Widespread\ Dust=true
Blowing\ Widespread\ Dust=true
Light\ Blowing\ Sand=true
Heavy\ Blowing\ Sand=true
Blowing\ Sand=true
Light\ Rain\ Mist=true
Heavy\ Rain\ Mist=true
Rain\ Mist=true
Light\ Rain\ Showers=true
Heavy\ Rain\ Showers=true
Rain\ Showers=true
Light\ Snow\ Showers=true
Heavy\ Snow\ Showers=true
Snow\ Showers=true
Light\ Snow\ Blowing\ Snow\ Mist=true
Heavy\ Snow\ Blowing\ Snow\ Mist=true
Snow\ Blowing\ Snow\ Mist=true
Light\ Ice\ Pellet\ Showers=true
Heavy\ Ice\ Pellet\ Showers=true
Ice\ Pellet\ Showers=true
Light\ Hail\ Showers=true
Heavy\ Hail\ Showers=true
Hail\ Showers=true
Light\ Small\ Hail\ Showers=true
Heavy\ Small\ Hail\ Showers=true
Small\ Hail\ Showers=true
Light\ Thunderstorm=true
Heavy\ Thunderstorm=true
Thunderstorm=true
Light\ Thunderstorms\ and\ Rain=true
Heavy\ Thunderstorms\ and\ Rain=true
Thunderstorms\ and\ Rain=true
Light\ Thunderstorms\ and\ Snow=true
Heavy\ Thunderstorms\ and\ Snow=true
Thunderstorms\ and\ Snow=true
Light\ Thunderstorms\ and\ Ice\ Pellets=true
Heavy\ Thunderstorms\ and\ Ice\ Pellets=true
Thunderstorms\ and\ Ice\ Pellets=true
Light\ Thunderstorms\ with\ Hail=true
Heavy\ Thunderstorms\ with\ Hail=true
Thunderstorms\ with\ Hail=true
Light\ Thunderstorms\ with\ Small\ Hail=true
Heavy\ Thunderstorms\ with\ Small\ Hail=true
Thunderstorms\ with\ Small\ Hail=true
Light\ Freezing\ Drizzle=true
Heavy\ Freezing\ Drizzle=true
Freezing\ Drizzle=true
Light\ Freezing\ Rain=true
Heavy\ Freezing\ Rain=true
Freezing\ Rain=true
Light\ Freezing\ Fog=true
Heavy\ Freezing\ Fog=true
Freezing\ Fog=true
Patches\ of\ Fog=true
Shallow\ Fog=true
Partial\ Fog=true
Overcast=true
Clear=false
Partly\ Cloudy=true
Mostly\ Cloudy=true
Scattered\ Clouds=false
Small\ Hail=true
Squalls=true
Funnel\ Cloud=true
Unknown\ Precipitation=true
Unknown=false
Well, more a list for myself, but here is my near future todo:
And more to come.
I wanted to post pictures, but to be honest it wouldn’t look like much, its mostly small sensors and lights…
So this weekend I installed and configured both the Astro and the Weather (wunderground) plugins. Both work amazing.
Using the Astro Binding I can now effectively turn the lights on and off as needed. I think I’ll need to set an offset though, as it is somewhat dark already 5-10 minutes before sundown inside my house.
I also found that someone has a Weather Station ~3km from me, so I can get a somewhat accurate reading of the weather using that, and it works great.
I now need to still implement rules to turn on the lights earlier if it is close to sunset but cloudy.
I had an issue as well this weekend, where the astro binding didn’t want to initialize after a reboot. When I tried to uninstall it, my entire Openhab appeared to crash, and no rules would activate. Any installation gave me errors about the app list/manifest or such. (Can’t remember the error).
I used openhabian-config to update my Openhab which was still on 2.1, and through the process it appears I chose an option wrong somewhere, because my Taillog stopped logging anything.
A little bit of searching on the forums here showed me a file to replace which fixed that.
So my system is up and running again, and somehow the astro binding started working again.
So, small update.
I bought another Gateway, as well as 2 open sensors.
I also bought 2 Sonoff wireless switches to experiment with them.
I placed my open-close sensors on my garage door and my gate, and the gateway is close to them.
But, I ran into a problem here that I’m not yet able to solve. In the Xiaomi App, the gate and the garage door sensors work as intended, and registered open and closed statusses.
However, after adding the Gateway to Openhab (took me a while, Xiaomi moved the “about” menu of the gateways, so had to search to find it), and adding the sensors, I’ve found that they don’t send updates to Openhab. At all. And I can’t figure out why. I’ve restarted the openhab, the Gateway, open closed the sensors, nothing. They still register on the app, but Openhab doesn’t even show anything.
I then tried to change the logging to try and see what the issue is, but struggled to get the logging to send my Debug level messages, and eventually the whole logging just stopped working. I restored the files I changed, and my system is working again, however I still can’t get updates from those sensors…
I also installed the sonoff switches but I don’t have the right connector to flash them to use MQTT yet. So I tried using IFTTT, but its excruciatingly slow, so its pretty much useless without having direct control.
I’ll look for a connector locally, and then try and troubleshoot those sensors next weekend.
If maybe someone reads here.
I now found that the new Gateway I added doesn’t seem to have correct functionality with openhab. Unlike the other Gateways, I can’t send any commands to the new one, and I in fact get errors. This would also explain why I’m not receiving updates from my gate and garage door sensors.
I see someone else had similar issues on the Xioami Mihome binding thread, but there was never a solution to the issue.
I tried updating to the newest version of the Mihome snapshot. But someone it seems I broke my whole openHab installation.
I do have most of the config files stored separately, so I am close to just reinstalling everything from scratch, but it might turn out to be a lot of work.
After a few hours of reinstalling, apt-get updates, and a lot of googling, I switched to the snapshot version of openhab via the openhabian-config tool, got loads of errors, but overwrote all of the files it asks.
Then I switched back to the stable one, and FINALLY my system is running again at least, albeit with all kinds of errors in the log…
One in particular is weird. When I refresh the rules files, it appears to execute the rules as it should somewhat, but I don’t see my log messages that I run on the startup rule.
Instead I see this error:
2018-04-16 21:26:46.836 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'test.rules'
2018-04-16 21:27:01.796 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.lambda$1(RuleEngineImpl.java:315) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
I’m not sure what that error means. I can see there’s some kind of null pointer error somewhere, but I’m not familiar enough with openHab’s code to know what could be wrong.
:Sidenote: My rules do fire, so I can still control everything in my house.
Any ideas on what I can do?
If this persists, I might just format the SD card, and start over, though I don’t really want to do that…
Anyways, on to tinkering with this stupid gateway that’s not working.
Do you have any lambdas defined in that .rules file? This includes createTimer, forEach, etc.
Nope, don’t believe so.
PS I did figure out why I couldn’t control my gateway, so manage to fix it and the sensors connected to it! I’ll post a solution in the Mi home binding thread where others also had the issue.
So, I found what is giving me that “Scheduled runnable ended with an exception” error. It appears to be when I try to convert the astro binding Sunrise time to DateTimeType.
DateTime Sunset_Time "Sunset [%1$tH:%1$tM]" { channel="astro:sun:local:set#start" }
If I set a variable to the state, it works.
However, if I do this:
var test = Sunset_Time.state as DateTimeType
I get the error:
[WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.lambda$1(RuleEngineImpl.java:315) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at ava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
And I have no idea why.
Is that variable a global? I’m going to guess it is.
It might be the case that your Rule is running before the Astro binding has a chance to populate Sunset_Time. That means that Sunset_Time is NULL and NULL is not an instance of DateTimeType which is causing an exception to be thrown when the Rules engine tries to populate the global variables.
I suggest initializing test to null and then create a rule that triggers when Sunset_Time changes to set the state to test. Then add a check in your Rules that use test to check whether test is null before trying to use it.
var DateTimeType test = null
rule "Sunset time changed"
when
Item Sunset_Time changed
then
test = Sunset_Time.state as DateTimeType
end
Of course, this all begs the question, why don’t just use Sunset_Time.state in your rules that use test in the first place?
Well, it was rather just an example I used in my rules file to test the error’s occurance. I actually have this code on startup to determine whether my system should be in day or night ‘mode’ (which affects automatic lights, etc).
I apologise if it is a bit clunky, its not the cleanest solution most likely.
logInfo("System","Doing Astro check...")
var sunSet = new DateTime((Sunset_Time.state as DateTimeType).zonedDateTime.toInstant.toEpochMilli) - 600000
var sunRise = new DateTime((Sunrise_Time.state as DateTimeType).zonedDateTime.toInstant.toEpochMilli) + 600000
logInfo("System","Checking times: Sunset: " + sunSet + ", Sunrise: " + sunRise + " - Now: " + now)
if (now > sunRise && now < sunSet) DayMode = true
Both sunSet and sunRise are local to the Startup rule. I see the first log, then the error appears.
What I’m wondering about the most is that this code worked fine before my system started giving me errors (which happened after I uninstalled and reinstalled the Xiaomi Mi Home binding).
So I don’t know if its is a more core system that has perhaps become corrupted.
The only other notable change was upgrading to the lastest OH version, which I did in an attempt to resolve my previous issue where OpenHAB didn’t even want to start.
I think I broke my system. :<
Edit: (Not really, I thought of it before I submitted my reply…)
I suppose I could maybe rather do that check using this in a single line rather than 3.
if (now > Sunrise_Time.state && now < Sunset_Time.state) DayMode = true
I don’t think now supports < or >. You have to use the isAfter methods as demonstrated in Design Pattern: Time Of Day.
But your error is happening before that line.
I still think that it isn’t worked before because if a trick of timing and it is failing here because one of the Astro items had not yet been populated by the astro binding.
Check to see if this test items are NULL and log out of they are.
You can mitigate this by using restoreOnStartup on these Items or by triggering the role that checks on when either of those items receive an update.
Okay, awesome, thanks for the suggestions. I’ll take a look at that Astro binding timings as well as the time comparison functions.
Thank you very much @rlkoshak.
I decided to scrap my way entirely, and use method you illustrate in the link you provided.
I also then applied the rest of my changes that occurs in day or night times by checking for an update to a “Time” string.
It works 100%, and is in fact better than before. I still don’t really know what the error was, but doing it this way around doesn’t actually throw the error, so it seems very likely that timing might have been an issue. I put somewhat of a delay before loading the astro data, and haven’t seen the error since.
I tested with no delay, but even with that it still worked. I can’t seem to recreate the error now lol.
So an update!
Since the previous issues, I reinstalled my entire openHAB setup, and it works much better now.
The Astro binding works flawlessly so I think my SD Card might have been corrupted.
I have also now installed Motion on my Pi to record and act as a server for my IP cameras.
This works pretty well, and also allows me to stream the camera directly in Basic UI, even through cloud, so I don’t need to open up my home network to WAN anymore, which is great.
I have found that after a few days, the RAM on the Pi gets used up, and openHAB starts to fail with memory exceeded errors, forcing me to restart the Pi.
I think the culprit might be motion, so I am planning on buying another Rasberry Pi (3rd gen I think) and put openHAB on that, and run Motion on its own on my old Pi.
UI wise, I’m still contemplating using HabPanel. I see many people on here use it to great extend, with nice UI designs.
I might eventually create a habpanel for a control tablet, and then use Basic UI for my phones, etc.
Cool Stuff
Few cool things I am doing with my Basic UI (not very impressive, but cool nonetheless).
Alarm
Another thing I’m working on now is an alarm. I can arm the alarm using switches, and also have it trigger and play the “Alarm Sound” on my Xiaomi Gateways. Unfortunately, at the moment the ability to upload custom sound effects to the Gateways appears to be disabled. So I can’t upload a proper alarm sound effect, which is somewhat annoying.
I also tried to implement a Alarm Code entry using a bunch of switches that update a String field, and use this to disarm the alarm.
This, and the fact that I cannot upload an alarm sound right now to the Gateway, has paused this part of my project for now.
Sonoff MQTTT
I bought a Sonoff Basic, (preflashed with Tasmota firmware) and tried to get it to work with openHAB, and I’m still struggling.
I installed a MQTTT server on the Pi, and openHAB can connect to the broker. That part seems to work.
But getting the Sonoff to respond to commands or report its status is still not working, despite following several guides.
I’ll tackle it again later this week, maybe start over. I think my understanding of MQTT(T?) isn’t comprehensive enough yet, so I’ll read up on that first.
Next Up
UI Screenshots
Hi,
That looks really great,
One quick question, how did you arm the alarm via openhab?
Cheers,
Pim
