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.
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.
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?
Yes, using a certificate for identification to possible yet.
I’d love to have a Map Picker for setting a Location Item though the UI.
In my example, I want to use it to create a widget for creating a list of pre-defined locations. I currently make it work by looking up google maps and typing the coordinates.
Can you please open a feature request issue on the openhab-webui repo?
Done
Someone just sent me this:
Would be cool to have this integrated somehow. Might make some of the notification features others have requested more possible
Yes, this is quite nice.
Apple finally decided to play along.
Web Push notifications were implemented in HABot Walkthrough (7/n): Push Notifications back in 2018 (!).
But now that they are universal it might be time to revisit them. For instance they allow your local instance to push notifications securely to your phone, tablet or desktop, without an intermediate service like openHAB Cloud involved. When visiting the main UI you would have an option to receive notifications (like many websites annoyingly try to offer) but if you accept you’ll be notified on your phone or desktop even if you don’t have the UI opened.
I wouldn’t mind having a “select all” button in the inbox for mass delete/ignore/approve. Select all by letter could be nice to have too. I have my ISY connected via MQTT to control my fanlincs and sometimes it fills my inbox with 100+ unnecessary things that I need to check one by one in “select” mode to then ignore because I don’t care about the keypadlincs in OH since there’s nothing really to control there.
in Main UI, in the page editor, when you add a list item to a list and you click to Configure Item and it says Move up or Move down, how about Move to top?
Use case: you have a list with a bunch of list items, when you add another list item it gets added at the bottom and if you want it all the way at the top it is a lot of clicking
Can you please open a feature request/enhancement issue at the openhab-webui repo? Thanks.
