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
Because the by the time the Rules are loaded, the Thing is already offline so there is no change to trigger the Rule to run. Put another way, the Rule missed the offline event.
You would need a System started Rule to somehow query all your Things to see which ones are already offline and manage them appropriately. Though I suspect adding a System started trigger to your already existing Rule might be sufficient.
I knew it somehow had to do with the rule running while the thing beeing offline at startup… I have thought about this, I just havn´t figured how to. I dont want to change the proxy item state to online, unless the thing is actually online. Thats the part I´m seem to get stucked on.
When you add a System started trigger to that Rule, at System startup is will look at that thing and only set the related Item to ON only if it is actually marked as ONLINE. In all other cases it sets the related Item to OFF.
Like I said, just adding a System started trigger to your existing Rules will be sufficient.
. All I’m trying to do is to figure out if it’s possible to do what I want.
