Even in a house which is fully automatic, (will never happen though, as human impact always screw up things), you´ll need some kind of monitor and therefore a GUI. (or GMI, Graphic Monitor Interface).
As for all those “smart” media controls etc, I agree they are not automations. They´re controles and not really usefull in a GUI/GMI interface, in my opinion.
It´s the same discussion, wether an smartphone app is a better option rather than a psycical switch/button… I have yet to understand the differences between, getting from my sofa to reach my mobilephone, or getting from my sofa to reach the button, (which is closer than my mobilephone btw), just to turn on the light. In my situation is a very bad idea with an smartphone app.
People tend to put up motion sensors to turn light on/off automatic But there are many situations where solutions like that isn´t optimal…What if I sit very still for long enough… Motion sensor will turn off the light.
A solution for this could be, that the automatic system only turn on the light, but I have to turn it off manually, when I leave the room… But what if - I forget to turn it off.
Well, easy the next room will tell, when I left the first room because it has motion sensors as well. Yeah, could be working, if the motion sensor doesn´t get confused because my wife was the one entering that room, or she passed me the very same second. Etc etc…
This is what I mean by, human impact always screw up things. It´s almost impossible to make 100% fully automatic.
With a fully 100% woking Face ID and Voice control system, a house can get very close to fully automatic.
Then we´ll just need to monitor these “things” as well.
Untill then, human impact is required in some way, no matter if it´s through habpanel, smartphones, sensors or even psycical buttons. But human impact will screew things up
GUI are needed as well in case of problems with the automatic systems.
I agree. I didn’t say they are not needed. As a monitoring tool they are very useful indeed.
I enjoy my little HABpanel setups. But I don’t tinker with them as much as they are what they are, a monitoring tool. If something goes wrong I’ll find out what went wrong, What was the edge case I missed and fix it in the bindings or the rules before adding another “control” on a GUI.
I wish I had your self-control and dicipline. I tend to throw in all kinds of stuff, dealing with several bindings and controle, all at the same time… I have no patient
I have established tabs for server state, sonoffs monitoring and the like
I have a nice looking onr for the weather
One for presence which I almost never look at because I know who’s home
One for the heating which I look at in the winter
And a basic control one for the few appliances that can only be switched on/off via OH
Oh, and I forgot, I have a testing tab where I throw stuff in to monitor thing temporarily or adding control to things I am experimenting on. Once setup it’s quicker than to play with the REST API.
This is my general use of BasicUI. I find it easyer to use, because I havn´t got a decent working design for Habpanel. BasicUI have ALL my items and stuff, all put´d together in several sitemaps, which make at least some sense. My biggest problem is, I love to test stuff. Last night I installed a Zigbee controller, just because… I still struggle with other stuff, where I got stuck, so I tend to leave it for a while and try something new.
I wonder if I´ll ever reach the end where I can lean back and enjoy all the hours I´ve spend on this, with a GMI I´m pleased with… I know where I want to go, but not how to, yet
The problem you will face is that a battery is just represented as a Number. How do you tell the difference between a Number representing a battery value and one representing a temperature, for example? Thing online/offline status is probably something more readily discovered since all Things already report their online/offline status. That could be just a REST call away and you can trigger Rules when a Thing goes offline.
The next problem is send a notification how? Lots of users use myopenhab.org but not all, and not all myopenhab.org users use it for notifications. Some use email, some use Telegram, some use different alerting services based on criteria like whether someone is home or time of day. How would your binding handle that?
This is why such cross cutting concerns are usually implemented in Rules, not bindings. That is what Rules are for.
If you want to be able to use these battery values in OH pretty much anywhere (sitemaps, habpanel, persistence, rules, etc) you have to create Items anyway. And you only need one Group for this.
It’s not built in because of what I mention above. There is no way to tell what Items (which is how something like this should properly work) or what Channels represent a battery’s value. There might be some things that can be done using tags on Items but that is no better than using Groups based on your prior statements.
And for a binding like this to be useful, it would need to support what ever notification mechanism the user would want to use. And the proper place for that to be implemented is Rules. That is sort of the point of Rules.
Through the REST API. That is how PaperUI and Habmin gets them.
But you still have to write a Rule to send the notification. So all you’ve bought yourself is not needing to create a Group. By using a Group you can achieve exactly this with a single Rule for your battery.
This approach would make it easier to handle the offline status of Things though as in Rules you would have to list each Thing as a separate trigger to the Rule that sends the notification.
Lots of people are working on lots of different UIs and there is a well established API for building such a UI. There is a third party UI (I think it costs) called Dashing which might be worth a look. But for now, if you want relatively easy but not the most flexible or attractive you need to use one of the sitemap UIs. If you want fill control and to have more of a dashboard look, you have HABPanel.
That is my position as well. But I recognize that for a lot of people, the UI is the point of the home automation. To each their own I guess.
But what Kim states isn’t false. HABPanel takes a lot of learning and knowledge to build a usable dashboard.
That is really the crux of Vincent’s argument. In an ideal world, you shouldn’t have to use ANY UI. The house just knows what to do. That isn’t always possible so my rule of thumb is doing the action must be as simple or simpler to achieve than the “dumb” solution would be. To me, that pretty much excludes the phone app UIs entirely. So in that case, yes, a wall switch is a better solution. That’s why I use controllable switches over smart bulbs.
These are the hard parts of home automation. Maybe you need a room occupancy sensor. Maybe you make sure to set the timer long enough to keep the light on long enough that you will move. Maybe you use events that take place in other parts of the house to tell the system you are no longer in the room. Maybe you just turn off the light at a certain time at night.
I don’t really think anyone is arguing that everything needs to be always 100% fully automatic. But it should be automated in such a way that using one of OH’s UIs is the exception, not the rule for how you interact with things.
As an example, There are two things in my home automation needs manual controls like that. Opening the garage and turning on the lights after 11:00 pm.
For the Garage I still have:
the original remote in the car
integration with Tasker and autovoice on my phone
integration with IFTTT on my wife’s phone (single button on her home screen)
I only ever use the OH UI when I need to debug something.
Similarly with the lights I have all these external non-OH UI ways to interact with the system.
So maybe saying “no UIs” is not the right way to say it. Maybe a better way is to say the UIs must be as easy or easier to use than controlling these things in the old “dumb” way and opening an app on your phone is pretty much never going to meet that. That that is what “GUI” means: Graphical User Interface. When you say GUI you are necessarily constraining the discussion to an interface on a computer/tablet/phone screen.
And one needs to take into consideration the usability of the home for guests. I’m sure many of us have had the experience of teaching the visiting family or baby sitter how to turn on the TV. First you press this button on this remote, then that button on that remote, wait a seconds, … I want to avoid that at all costs. My five year old needs to be able to work the home automation and that means no screen based UIs. He’s really into talking to Google though. My relatives and other guests just use the physical switches.
I mainly use mine for debug. I have OH send alerts and notifications and reports for monitoring.
I like Vincent’s idea of a “In Test” sitemap. Put your WIPs there and it doesn’t really matter if it is a WIP.
For completeness here are a couple screen shots of my BasicUI, which, again only I use for debug and sometimes monitoring.
I can drill down into pretty much any of the sub categories and get details. But the only controllable things are the six entries at the top, and none of these are ever controlled from this UI.
I don’t want to argue about the group solution, and whether that is a good solution or not. I don’t like it, and I’m just looking for pointers to make something that I believe is a better solution. You don’t have to agree with me here, I’m just asking for some help.
That does not matter right now. I just want to be able to fire a rule when a battery is low or a device goes offline. That’s what I meant by “notification”, but that’s probably not the right terminology. Wether the rule uses push notifications, lights up a warning LED or makes all the lights flash in the house is not prudent.
As a starting point, I was just going to look for the keyword “battery”. It seems like most items follow a certain convention when it comes to the channel ids, and that would probably catch most of them. The Z-wave plugin does seem to have some sort of knowledge what the channels are for, and maybe it’s possible to hook into that:
I realize there are challenges with doing this, but I believe I can overcome them and make something that’s better than the manual approach (in my opinion). My question remains. Does anyone know if there is a way to iterate all the items in the system?
Using the REST API. Outside of that I think individual bindings can only access those Items it is linked to/bound to.
I’m not going to convince you that the Group solution is a good one. But I am going to ask how this will be a better solution.
So you are going to trigger a Rule to send the notification. So that means you are linking your binding to an Item that you will send a command to when an event occurs. So from the notification perspective, your solution and the standard Group solution are the same.
Now we need some way to identify Items that represent a Battery. This will rely on the users to name their Items appropriately or somehow mark the Item in some other way to identify it as representing a battery. You cannot get the Channels or Bindings that an Item is linked to through the Items REST API but you can get the Items linked to a Channel from the Things REST API. So right off the bat we are limited to only supporting OH 2.x version bindings. So if you want this to be generally useful, you already can’t get there.
But if you are willing to do all this work and have it only work with OH 2.x version bindings then you can probably make this work assuming that all bindings that connect to battery powered devices have a Channel that includes “battery” in the Channel ID. That is likely the case but in no way guaranteed.
Another approach is you can use the Category (i.e. the icon) as the tag and if the icon used is battery then you can assume it is a battery Item. But now we are back in the case where we have to do something with each of the battery Items. If you are going to require that then there is nothing different, from the user’s perspective, between what you propose and using a Group.
Another approach is to use Item tags and add the battery tag to the Items that represent a battery. But again, this is no different from using a Group and in some ways is worse because it would break Alexa and Google Assistant integration and there is no way through PaperUI to add a tag to an Item right now.
Another approach would be to bind/link each Item to your binding. The binding will definitely have access to all the Items bound to it. But again, this requires one to add something to every Item and once I have to do that it is the same, from the user’s perspective, as using a Group.
Another approach is to use the LogReader binding and troll the logs for log entries that seem to talk about batteries, as you mentioned. This takes us out of the binding territory and back into Rules. Now instead of just one Rule and tagging each relevant Item with a Group one has to have two Rules with lots of regular expressions to identify just those lines that are related to battery updated for each of the relevant bindings. An in the example log line you have above, you have to add the logic to go from Node 40 to Thing to Channel to Item. IMHO this is definitely not an improvement on just tagging the Item with a Group.
tl;dr: I’m not trying to convince you not to go down this path. I’m asking you to convince me that once you do go down this path it is substantially easier on the user than just tagging Items with a Group.
The user experience that I’m looking for is that I can monitor the health all things, without having to do extra steps like creating items for them. I want to be able to write a rule that fires whenever any thing in the system has low battery. The thing may or may not have items bound to it. It should not matter.
If I can do this for at least z-wave devices, I would be happy. All my battery powered devices are z-wave anyway.
It may be the case that the architecture of openhab may prevent me making this user experience, but this is my goal. In my opinion, and you are free to have your own, this is a better user experience than having to do the additional steps of adding items for each battery level channel and adding these items to groups.
I don’t know how close I can get to this experience, and I’m not trying to defend any particular solution to this problem that does not fully achieve that user experience.
We don’t have to agree on the best solution. I’m not going to come to your house and force to to change the way you are monitoring the health of your network . All I’m trying to do is to figure out if it’s possible to do what I want.
Is the information that’s available trough the REST API also available trough a programatic API? It seems odd to use a REST API if I’m in the same process.
The best that you can do as far as I know is use the REST API to query for the list of Things, process the JSON to identify the battery Items, then ??? Post a command to an Item? Trigger a Channel? Something has to cause an event to trigger the Rule.
If you use a Channel trigger then your only options are ONLINE/OFFLINE, which you can do now, or a momentary switch like event. But neither of these will pass information to the Rule to tell you what device has the low battery.
You could use a String Item with the name of the Channel that is low, but that will largely be not very meaningful information to most users. Even I don’t know what Node 12 is in my zwave network without looking it up.
All things are possible. My argument is I don’t see how this approach is anything but less capable and much more work than using Groups.
I believe, but don’t know for sure, that this would be the only way. I’m pretty sure the bindings only have access to their Things and their Items, not to everything in the registries. Honestly, I hope this is the case because bindings should not be mucking around with another binding’s Things. If there is some sort of synchronization that is to take place it takes place either in Rules or by linking them to the same Item.
No, but I’m one of the top people on this forum and I focus on helping users, particularly new users. So when I see a proposal like this my main focus is on:
is this easier than what we have now
will this help a new user
what sort of questions will I have to answer over and over and over again if this became a part of OH.
So far this proposal fails on all three fronts. Of course if you have no intent to submit this to OH as a new feature, then it doesn’t matter what anyone has to say. But I’m always optimistic and anything someone is going to try to build would be submitted to the project.
I’m just trying to improve my experience. It this point I’m just weighing my options, and I think whether the solution I end up going with should be contributed back to the project is an entirely different discussion. I think it’s premature to have that discussion now, when I’m just enquiring what my options are.
On that topic, I have made a binding for sony bravia TVs that I’m looking to contribute back. It’s lacking documentation, but other than that it’s in good shape. I’ve been using it for almost a year now.
Lately I discovered that Habpanel can work with svg´s, and svg´s can be build in layers as well as send/receive data in OpenHab. Like this: Design your SVG floorplan or dashboard for HABPanel with Inkscape
That is my idea of a GUI specially for monitoring a whole house nice and clear. It doesn´t really need any human impact like switches etc… It´s a graphical monitor, showing every important information from the house.
This is the path I´m going, as it´s the only thing that really makes any sense to my understanding of a smart home. You cant have a smart house without somekind of monitoring. Cause sooner or later, something will mess up, and you´ll have the monitor as a tool to what to do.
How you´ll interact with alle the devices in the house depends on other interfaces, (like psycical swicthes, mobilephones, remotes motion sensors, voice, camera etc.).
Even in a ideal world, you still need a monitor, in my opinion. But it depends on for what use.
Think of it like a car. If the car didn´t have a fuel indicator (which is the same principle as an monitor), you´ll not know when to refuel. The car can and will tell you, no bet. But when it does, it´s too late without this monitor.
A smart home monitor…
You have a light indikation from a room. The light is turned up, the monitors shows.
Now next day, you turn on the light on the switch like you use to, but the light does not turn on in the room. Now what. Is it the bulb or something else? Turn to your monitor and if it´s effectivly coded, it´ll show you the answer, or at least indicate what might be the problem.
In the case with the light problem, I dont have to start my computer first and dig deeper into OpenHab (or whatever system), only to find that the bulb is defect. I can just look at the monitor, and most often find the cause. Without a monitor I could take the chance and exchange the bulb, but if the bulb is not the problem, I have spend time on nothing. I think you get the picture.
They´re not just hard, they´re close to impossible, cause it all depends on the human factor. One day I move alot, other days I move less. Changing time is therefore not an good option. Using events do really depend alot of the human factor and specially human habbits. It´s only a very few people how can live in a 100% schedule enviroment like that.
But a solution could be a combination of all the options as well as other options. But it will never get 100% automatic and bullet proof system.
Exactly! And this is where the monitoring comes in hand. Used for exceptions, (or for curiosity) it makes sense.
This is basicly what I´m using BasicUI for, as well as testing new stuff, since it´s easyer and quicker to do a sitemap rather than to create a dashboard in habpanel. Each time i connect a new device, I create a sitemap as well, add all things and items form the device, and start to monitor them, to see how they are acting. When the device has run for some time (may be weeks), I decide wether to keep it or not, and maybe just some of the things/items from the device.
Beside OH, I´m also in another situation as our house is build with the smart home system called IHC. (Intelligent House Control). This system is very smart as well, though it has some limits. In short, it´s 128 digital and analouge in/outputs all wired up with push buttons everwhere, with lots of programming and intelligence, like timers, rules etc. Today the IHC controller takes care of basicly everything, lights, heating, alarm and ventilation.
My plan is to combine openhab with the IHC controller, and let OpenHab cover for the limits of the IHC controller. But I have to take into consideration, what if…I loose interest in Openhab or something more serious happen. It got to be made so I (or someone else) can switch off OpenHab, and the original installation is still running. Maybe some day I´ll be ready to skip this part, and let OpenHab overtake much more intelligence.
Because of the IHC installation, I have tons of items from the controller. But only a very few switch buttons. I can still interact with basicly everything in the installation due to the structure of the IHC, but I don´t need the push buttons at all.
Well long story… But it may explain why I think, that having a monitor is important, at least to me it is.
Now I just need to figure out, how to
I think we are taking about to very different things.
You are taking about a monitor, something to look at when things go wrong. I think if you read closely what both Vincent and I have said you will see that we both have quite extensive monitoring UIs.
The screenshot above use of my monitoring UI.
Or point is we do not build our home automation such that it requires using the monitoring UI to activate or interact with the house. Either it just does it, or some other interface, in my case a physical interface for the most part, is provided.
Yes, absolutely, you can and should build an adminstration/monitoring UI for yourself for all the reasons you outline. We are not saying you shouldn’t.
But for me, given the limitations I’ve placed on my own home automation design, I’m there only one who will every care about this ui. I’m they only one who will every use it. And we’re I to die tomorrow and my OH system be restored in the process, my home automation would stop working but my home would still be completely functional.
To borrow Mitch Hedwig’s joke. "You will never see an escalator out if order sign. Instead you’d see "escalator temporarily stairs. Sorry for the convenience.’
Your Rule is cool. Do you can help me for two things?
I have switches for LowBat all my Devices switch ON if the battery is low. But i’m too stupid to change the rule against switches.
The second rule i need is to check the status of things. I want an email if a thing goes offline. I searched and testet a lot, but i dont get an working rule for my problem.
Sorry. I mean things. I want a message if a thing goes offline. I created the things via paperUI and the items via *.items file. I add a group to one item per thing for the online status.
Also I add a other group to every lowBattery Switch item. If the lowBattery switch goes ON I wanted a message too.
It’s just a normal items file. I created an item per channel. The first item of a thing i added a group named „gOnline“.
My first idea was to iterate all items with the group „gOnline“ and check the state, but I don’t know how I can get the thing of an item. Tomorrow I can show you the files. Actually I havent access to my pc.
rule "Zwave Node5 status"
when
Thing "zwave:device:512:node5" changed
then
var thingStatusInfo = getThingStatusInfo("zwave:device:512:node5")
if ((thingStatusInfo !== null) && (thingStatusInfo.getStatus().toString() == "ONLINE")) {
logInfo("ThingStatus", "ZwaveNode5 is online.")
ZWaveNode5_status.postUpdate(ON)
} else {
logError("ThingStatus", "ZwaveNode5 is offline or doesn't exist.")
ZWaveNode5_status.postUpdate(OFF)
}
end
It requires a proxy item “ZwaveNode5_status”.
As Rich says, your cant group things, and you cant link an item directly to the thing status. So this is the only way I have got it to work. And you´ll have to make a simular rule as well as a simular proxy item for each thing.
Unfortunatly it´s a rule which means, when restarting openhab, and the thing is offline when the rule run, the rule will see the device as offline, and it will never change, for some reason I still havnt figured
. All I’m trying to do is to figure out if it’s possible to do what I want.
