Could you please explain your usecase.
Rendering a more fancy/appealing “Thing” list in main UI. Bindings are associated to a picture, channels also. This could also be used in documentation generation. Just a 2ct idea.
Thinking of it a bit further, that would mean that the binding should deliver appropriate icon ressources also. Then I’m wondering if it would not be interesting to package appropriate resource icons along with the binding (for the things and channels when not available in the standard icon sets). This could save sooo much time for end-user chasing the internet for appropriate icons.
Still 2cts
5 Likes
Hello,
It would be great if there was a UI way to create Aggregation Functions for groups with BaseType different than switch.
Examples for this are a groups with a type of string and an aggregate function that performs a logical AND or OR to see if items have the same value or not, or that performs a Count of items.
I would use this for example, to have a main control that controls several fans. Fans sometimes have more than 2 states, and thus aggregating them with a switch type does not work very well. But if I declare them as string, and I use an aggregation function like AND(“0”, “1”) , I could have a group with a value of 0 when all fans are 0, and a value of 1 when all fans are not zero. That way, i can turn them all on(to one of the specific ON values, can be 1, 2, 3, etc) or all off with one switch. With the Count function, I could also count how many fans are on or off.
I tried to define this through text, but it fails. And i do not see a way to define it in the GUI.
IF aggregation functions could also be very powerful here.
Thanks
This is already possible and has been for a very long time. But not every aggregation function makes sense for all base types.
AND and OR is only ever going to work with the boolean type Items: Switch and Contact. But you can use COUNT with String Items. If the UI doesn’t let one use that with String Items, than please open an issue as that should be supported right now.
No you really can’t, at least not in a way that makes sense given what AND and OR actually mean from a mathematical sense.
These operations only work for boolean data types. In a case like this, if you used Numbers you could use a MIN/MAX type aggregation function to achieve the same result I think.
Like I said, COUNT should already be working. If not please file an issue on the openhab-webuis repo because this has always worked even as far back as OH 1 so if it’s not working now, it’s because the UI isn’t showing the option.
Please open another issue to explore this. COUNT on a String Group has worked in the past.
That needs way more description and explanation.
@rlkoshak , thanks for the clarification.
How can i know which aggregations are available for each type?
Thanks
The docs for the aggregation functions are documented at Items | openHAB.
If it says “Boolean” in the description it only applies to boolean states (i.e. Switch, Contact, I’m not sure if Color and Dimmer are included, maybe also Player).
If it says “Arithmatic” it works for Items with a number as the state including Number and Dimmer.
LATEST and EARLIEST only makes sense for DateTime Items.
Because COUNT works with a regular expression, it can work with any of the Item types.
My wish:
Change the UoM behaviour such that changing an existing item to a quantity type would not break any rules.
That means that if I use item.state it would just return the state. That would make the transition to UoM much less painful. Tried several times but always discarded my changes as these UoM just break things in so many places.
That’s not going to be feasible. Number and QuantityType are just not compatible in that way.
But it does. “Just the state” for a QuantityType is the QuantityType, the number with the units.
However, there are some things you can do. In JS Scripting, the latest openhab-js library implements a numericState and a quantityState so you can choose whether you want the plain number or the Quantity (note state returns a String and rawState returns the Java State Object). In the other languages, it might work to use getStateAs(DecimalType). I don’t know for sure whether that works but if it doesn’t it would be a nice addition. That would strip off the units.
And as discussed above, the application of units looks like it’s going to be more of an opt-in rather than an opt-out choice, meaning you can change your Items one at a time to use units and not have to change everything all at once. Though even now, you are not required to use units. If you link a Channel with units to a Number, the units will be thrown away.
Hi Rich,
I checked in the GUI and COUNT is still not there. The request is still open.
I don’t know if it is possible in the standard rules DSL, but I need to code methods for my rules. I want to prevent redundant code blocks.
Maybe this is possible and I did it wrong the whole time, but for example to check if someone is at home I need a method to call and get a return value true/false in this case.
I don’t want to create more and more helper items just to save some temp values for my rules.
Is this already possible?
See Reusable Functions: A simple lambda example with copious notes. If that’s not enough, you’ll have to move to a different rules language.
1 Like
My wishlist:
I would appreciate to get the actual thing status like ONLINE, OFFLINE; DISABLED, … in a string item by declaration, without writing a rule, e.g. by providing the thing uid as channel.
Comparable, as extension: Map a thing to a switch item in order to enable or disable the thing (ON/OFF)…
I would appreciate to have a readCommand() in parallel to sendCommand(), in order to read the current value of the regarding item, e.g. from KNX or MQTT. Then the binding developers could add regarding functionality, e.g. a readTopic in the MQTT Things and Channel binding.
Please explain a little bit more about the use case for this.
In the mean time, see Thing Status Reporting [4.0.0.0;4.9.9.9]. That would require minimal rules coding to handle most use cases.
There is already a REFRESH command supported by some bindings for this purpose (I know Zwve and Zigbee to, I suspect KNX does). Unfortunately I don’t think it’s well documented. When you send this command to an Item, the binding will attempt to go read the current state of the device and update the Item. Not all technologies can support this and not all binding authors have implemented this.
Given the nature of MQTT, REFRESH isn’t supported and I’m not sure how it could ever be supported and what the point would be. MQTT messages are either retained or not. MQTT is a push technology, not a pull technology. It’s the end device that decides when and how to publish any message. Clients can’t force them to publish.
Given that, there’s nothing to refresh.
As long as the connection to the broker is up, your Item will always reflect the latest message received.
If messages are sent while OH is not connected that are not retained, those messages are gone and not recoverable.
If messages are sent while OH is not connected that are retained, the latest retained message will be delivered to OH as soon as it connects.
Some channels are regularly updated via calls to the API of regarding device, even if I am not interested in the acutal data. In such cases I disable the device.
In my instances Python code is in place in order to disable or enable the things, but I thought that it might be of intrest for all users to have a barrier-free access to the things via items.
I was not aware of the refresh command and give it a try for KNX.
This is very special to the ebusd acting as MQTT client. Obviously some values are not sent to the ebus by the device, even if changed.
To deal with this the ebusd offers a speical topic <topic>/Get in order to request the value and publish it as <topic>.
So it would be great to have the possibility to configure a readTopic=“<topic>/Get” in the channel, comparable to the writeTopic=“<topic>/Set” configuration, which is publish by the MQTT binding in order to read the regarding topic / channel / item.
As a whole it would make sense to have readCommand() / refreshCommand() comparable to sendCommand(), for the same reasons like the things status item: To make life a little bit easier.
But in rules you already have barrier free access to Things in the rule through the ThingRegistry. In the UI they already have access to the Things status in the Things menu of MainUI. To trigger rules, at least in the UI and JSR223 and GraalVM rules languages you can use a GenericEventTrigger to get something akin to a “Member of Group changed” type trigger for Thing status (see the link in my previous reply for an example).
I’m still not seeing what reflecting the Thing’s status in an Item really buys you. I can be convinced, I just don’t see it right now.
If you are talking about MQTT Event Bus [4.0.0.0;4.9.9.9], let’s move the discussion over to that thread to further explore what can be done. The OH MQTT binding itself doesn’t natively provide an event bus implementation.
But if that’s the case then no, it’s not obvious that some values are not sent even if changed. As I’ve implemented it every update gets published to the state topic as a retained message, whether or not the update reflects a change.
If you are talking about something else, well it’s going to be up to what ever that something else is to implement some sort of messaging protocol to republish a device’s state, in which case that would be reflected in a Channel on the MQTT Thing and the standard Item interface.
In a sitemap an item can be used to apply a color to a widget. If thing status is in an item this could be used to set a color to give feedback if the thing is offline.
1 Like
For me a thing itself it is as interesting as any needed channel. If one cannot reach a thing, all item values are more or less invalid.
E.g. sometimes we cannot use the remote that is connected to the Harmony Hub, because the hub has crashed. Then the regarding thing becomes offline. Nice information to be shown in the openHAB UI, also mentioned by @hilbrand
I use shelly plugs. A view of them are switched externally, that means, they are not reachable then. The thing is not reachable then. Nice to know and easy to evaluate as item, because the device powered via the plug is switched off if the shelly is switched off (channel switch item) or not reachable (thing status item).
No, I am talking about the eBUS (serial buses) - Wikipedia and the ebusd. The path in my home is:
heat pump --ebus-- ebusd --MQTT-- mosquitto --MQTT-- openhab/binding
Some values of the heat pump are not sent via the ebus, even if changed. The values have to be requested. For this the ebusd implements special topics on MQTT side, as described above.
That means, in order to read a certain topic’s value into an item, I need to send a value/command to another item, that is linked to the special read topic implemented by the ebusd.
openHAB assumes that it actively receives any change from the devices at runtime. But this is not true, for me in case of my heat pump or the power and energy values of a a few of my KNX smart meter. Therefore some data has to be requested.
Although if I implemented some code for this, I would appreciate if openHAB could handle this via the thing and item configuration, and to trigger a read by a new function like readValue(), so that one can avoid boring code.
I can see this use case. But the requirement doesn’t necessarily require Things states to be represented as Items, though that would be the most expedient way to achieve it. In the mean time, there’s the Thing Status Reporter rule template which can call a rule that maps the Thing to an Item. With careful naming it’ll only take a few lines of code.
For now, this is super easy to implement now using the Network binding since Shelly is WiFi and the devices respond to pings.
I would say the way ebusd implements this is an MQTT antipattern. One of the guiding philosophies of MQTT is you should not impose work on your clients, meaning the publisher should not force the subscribers to do extra work.
And this behavior is unique to ebusd. The MQTT binding is a generic binding. The generic part of the MQTT binding is never going to support this back and forth automatically. Someone might come along and build an ebusd add-on or add a new ebusd flavor to the MQTT binding. I could see that maybe being supported. But I simply cannot see how this weird implementation of MQTT by one third party service justifies the huge changes to core and impacts across multiple repos to directly support. Especially when there already is a REFRESH command and supporting this weird case is not difficult using Rules.
My wish would be possible to configure mqtt TLS with certificate as security feature.
Do you mean using a certificate for authentication in addition to/in place of username and password?