I haven’t touched my, albeit basic, sitemap in a while and was starting to think about ways to get the info I wanted more efficiently, while still retaining the ability to control/view everything. As it is now I only have one sitemap, and it shows frames and subframes for every room, all the hardware states, and configuration/setings and so on.
I’m beginning to wonder if perhaps I really want separate sitemaps for the house, and then the hardware. Mostly so one sitemap isn’t overloaded with everything possible.
So how does everyone else views the layers of information OpenHAB makes available?
I have a set of rooms up the top then some control pages under that - i.e. for setting thermostats, lighting scenes, irrigation config, and then finally some (mostly) readonly monitoring stuff - checking sensor activity, energy readings, weather etc.
For each room in the house, are you only showing reporting parameters (temps etc), or do you also give control for lights etc? You have the control frame on the main page separate which I like, but inside the Lighting sub frame, do you then have each room defined again to give finer grained control over the lights?
But then in the main lighting page I have all lighting controls in one place, regardless of time-of-day (including scene selection and individual lights);
I group mine by location, and then by “type of thing”.
So if I’m in the master bedroom and want to do something, hit the master bedroom.
If I want to see what temperatures are across The Korn Manor, I pound temperatures and see all of them in one shot. Similarly for locks, humidity, light levels, door contacts, etc.
@TheKorn That’s a decent method, too. Nice and straight forward so there’s no ambiguity.
Thanks @ben_jones12 Your setup is much more advanced than mine ever will be, and hence the need for a sitemap with the visibility settings although It does make a lot of sense to help minimise the clutter that having everything together creates. Even if I only added my security cameras and sensors info to the main sitemap screen when I am ‘away’ it adds a lot of usability.
@ben_jones12 I saw your heating control (on/off/Auto/temperature etc.) and I am interested how you did this?! Is this “self developed” or is there any kind of tutorial anywhere around the web?
self-developed…my rule is triggered whenever the mode is manually changed, the setpoint is adjusted or the temp sensor changes. Logic should hopefully be pretty self explanatory.
Just need a temp sensor and a switch to turn on/off the heating source. I use this pattern for a couple heaters in our place.
rule "Nursery heating"
when
Item VT_Heating_Mode_Nursery changed or
Item VT_Heating_Setpoint_Nursery changed or
Item FF_Nursery_Temp changed
then
// 0="Off", 1="On", 2="Auto"
if (VT_Heating_Mode_Nursery.state == 0) {
// heater off
if (FF_Nursery_Heater.state != OFF)
FF_Nursery_Heater.sendCommand(OFF)
} else if (VT_Heating_Mode_Nursery.state == 1) {
// heater on
if (FF_Nursery_Heater.state != ON)
FF_Nursery_Heater.sendCommand(ON)
} else if (VT_Heating_Mode_Nursery.state == 2) {
// get the current setpoint for the nursery
var Number setpoint = VT_Heating_Setpoint_Nursery.state as DecimalType
// calculate the turn on/off temperatures
var Number turnOnTemp = setpoint - 0.5
var Number turnOffTemp = setpoint + 0.5
// get the current temperature in the nursery
var Number temp = FF_Nursery_Temp.state as DecimalType
// determine whether we need to turn on/off the heater
if (temp <= turnOnTemp) {
// turn on temp has been reached so switch on the heater
if (FF_Nursery_Heater.state != ON)
FF_Nursery_Heater.sendCommand(ON)
} else if (temp >= turnOffTemp) {
// turn off temp has been reached so switch off the heater
if (FF_Nursery_Heater.state != OFF)
FF_Nursery_Heater.sendCommand(OFF)
}
}
end
Thanks @ben_jones12. Oh Lord, this seems to be much more “intense” than I thought it would be.
Sorry for beeing off-Topic:
I’d like to have a scheduler, operated through an UI. There I’d like to define time frames (monday 0-8, 8-22, 22-24 // tuesday … and so on) and for every timeframe there’s a defined set temperature, which then will be automatically “transferred” to the desired thermostats.
And as a topping, a manual intervention for this automatic schedule would be nice (“I am sick, today I stay at home and I want two degrees more than usual”). And as soon as the next scheduler event comes, the manual temperature is overwritten again by the scheduler temperature.
Until now, I have hoped to arrange this through an “scheduler UI” with HABmin, OH Designer or whatsoever tool can handle this. Am I right that this tool does not exist and I have to do it the hard way (=coding rules)?
There is nothing like you mention built-in to openHAB. There is nothing except the framework for adding and configuring bindings and getting updates and commands appearing on the event bus. From there it is up to you to write your rules around these events.
I know @chris has some grand plans for a rule library which users can contribute to and others can leverage off, without having to figure everything out for themselves, but I think that is only going to work for relatively simple rules.
As soon as you end up wanting something a bit different you are going to have to end up coding it yourself. This is great if you like the flexibility (as I do) but not so great if you don’t have the skills and just want it to work out-of-the-box.
FYI - I have some other rules which are triggered when people arrive/leave the house, that automatically adjust the various temperature setpoints around the house. So when the wife is home it is set to 22, if only I am home it is 20 (don’t mind it being a bit cooler) and if no one is home, or we are in bed then it drops to 18. My rule above is just the actuator part of the system - deciding when to heat or not. There are other rules which decide what temp it should heat to.
I mainly use my sitemap for debugging rather than control so I really haven’t spent much time working on it so my thoughts may not be applicable to those who do use it for control, but I tend to organize everything by function instead of location in the house. I too use frames to structure my sitemap.
I put my entry stuff at the top (garage door controllers and status of the doors) followed by lighting controls and my Nest information. Then I have a big section of debug stuff like whether or not someone is home, weather, switches to reset my remove devices, etc.
I’m pretty much the only one who uses the sitemap as my wife interacts with it using a Minimote remote or IFTTT Do app on her phone. And day to day I only use the sitemap for deugging.
But I do think that the functional layout is equally as valid as a location based layout as it makes an equal amount of sense to say “what do I want to do” first as it does to say “where do I want to do it” first. But it will largely depend on what you have automated where and how often you need to manually control it.
@rlkoshak Agreed, there definitely seems to be merits in both approaches to how you use the sitemap. I’m going for maximum WAF so will give her the option of choosing the general approach to use of the sitemap and then go from there I think.
Now I need to decide how much I want to customise the default sitemap before I realise the Project Rotini tablet UI is just too good to not use!
I have shared my config a few times now, if you search the forums (and perhaps the old Google Groups) you should be able to dig them up. They are ever evolving of course, but there is quite a bit in there.
In my experience the maximum WAF comes when you automate things in such a way that there is no need for an interface at all. I’ve actually avoided some automations for that very reason, it was impossible to do without using the phone to control it. If you MUST have an interface, make it as simple and intuitive as possible and if you can’t make the interface as easy or easier than the non-automated way you had better retain the non-automated interface.
This is largely why I only use the sitemap for my own debugging benefit. Everything I have automated:
just happen with no need for any interface
require an interface but I use something else to generate the events, e.g. a physical remote or IFTTT Do recipe
I retain the original physical interfaces and make sure OH is aware of these, particularly important for overriding the automated behaviour when desired (e.g. don’t want the lights to turn off when the clouds clear, just flip the physical switch and that rule gets overridden for the rest of the day)
I’m a strong proponent to push for automation over computer controlled. By this I mean that the behaviour just happens. If you need an interface it is a home automation failure (an admittedly hyperbolic statement mainly meant to make you ask the question “should I automate this?” verses the question “can I automate this?”).
This is the one I personally find to be key. My philosophy is that you should never have to fight your home automation system – if you do then you’re doing something very wrong.
For example I have what I call courtesy lights… lights that turn on for a certain duration if some condition is met. (e.g. garage door go up? Turn on the garage inside, garage outside, patio, side door, front door, all for five minutes, then shut them all off.) But it’d kind of suck if someone was sitting on the patio with the lights on, someone else opened the garage, then the person on the patio found themselves in darkness five minutes later due to no action of their own. Point is the rule checks to see if each light is already on before it turns them on and if it is don’t touch it at all and don’t schedule an off timer either. It’s slightly more of a pain to code rules that way but it’s one of those little touches that avoids a death by a thousand cuts type scenario.
I’m still pretty new to openhab and writing code in general so expect this to be a lot of trial and error but due to having no lights to worry about right now it shouldn’t be too much for me to figure out.
You’re right though, home automation is extremely dumb, when it’s not smart.
