When I use the ‘Outdoor Lights’ group to switch the respective lights on, they indeed switch on as expected. But then when I switch them off individually, and when they are all off, the group status is not updated, as can be seen here…
Having taken out my nested groups (e.g. front door lights), the functionality works as expected. So there is something wrong with my nesting of groups (trying to make two related lights function as one). I’ll need to try figure that out.
So right now group behavior is a little broken. It is better in the recent snapshots but there is a change in behavior that cloud be rippling to other expected behaviors.
I don’t have a good answer for you right now as I’m in the middle of trying to figure out why just basic rules are not triggering for me at the moment. And it’s hard to debug when I only have 15-20 minutes a day to work on it.
My advice would be to ensure all Groups have a type and avoid nested groups to drive your rules.
There is a wealth of info on the issues and work arounds on the thread titled something like “groups stopped working”.
Without the nesting it seems to be very reliable using proxy switches and rules to control the situation as I posted above. I’ve posted my working setup in the older thread Group status updating from top-down but not the other way. I’ve leaned a lot since that thread was started
You time spent advising is much appreciated.
As a side note, I spend months away from home at a time and I haven’t set up remote access to my Pi, so I just leave it there running OH2 minding it’s own business, In all those months it hasn’t missed a beat! So however much we throw questions around this OH2 machine, I can certainly say it’s robust!
I’m running a hue bridge, a Wemo bridge, a LIFX bulb and a Z-wave stick, all unsupervised. Credit to you guys who are creating something special here
If you are not already doing so, I highly recommend looking to move some or all the file systems off your Pi’s SD card and onto an external drive. There are lots of approaches but the easiest is to take advantage of the fact that you can now boot from an external USB drive on the Pi 3.
I suggest this because at some point your SD card will wear out. And when it does the behavior of the system will become erratic and non-deterministic. Particularly if you are controlling something system critical like irrigation, alarm, heating/cooling, you do not want the failed SD card to randomly turn things on and off because of a failing SD. That could be disastrous if it could be ongoing for weeks or months at a time.
Not really. Both are shown to be really reliable. You don’t need speed, USB 2 is going to be slower than the slowest drive anyway.
The only think I might consider is getting one that has external power. Drawing too much power through USB on the Pis is known to overwhelm the Pi sometimes. If the drive doesn’t have its own power, at least attach it to the Pi through a powered USB hub.
I’ll go SSD owing to no working parts and should last years according to the video SSD Life Expectancy. I wonder how much data an average home automation system writes in a day.
There is no such thing as an average home automation system.
Your big writers will be logs and persistence. And depending on how much you are persisting forever (i.e. not using rrd4j nor using a retentionpolicy on InfluxDB) you can probably expect around .5-2 MB per Item per year depending on the frequency of saving data and data type of the Item.
Given that your logs will probably dominate in the amount of writing done. But those usually will get rotated out so will remain a relatively consistent size once you fill all the rotation slots.
Assuming you don’t have errors and have the logging set to INFO your events.log will be the larger of the two default OH logs. So you can turn that logger off when you are not debugging to save a lot of writes and disk space.
None of this takes into account other services you might be running like Mosquitto.
I’ll probably pick up an Emtec 128Gb SSD for 60 Euro which I’m hoping will be enough for my purposes, at least for the foreseeable future. I’m only running rrd4j as persistence but I’m intending to get InfluxDB up and running too.
I’ll then move the root system to USB which is available in the OpenHABian config menu
Given that your logs will probably dominate in the amount of writing done. But those usually will get rotated out so will remain a relatively consistent size once you fill all the rotation slots.
Is this maintained by the system via the config file org.ops4j.pax.logging.cfg in /etc/userdate/etc? In that file I see both the openhab and event logs are set to 10mb:
log4j.appender.event.maxFileSize=10MB
So if that’s correct the SSD should see me though for a while.
Thanks for the headsup on me burning out my SD card
Yes. And you can change that and/or turn off the loggers as necessary there. It is particularly useful to edit that file to put the logs from one specific binding into its own file when debugging binding problems.
