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 QuantityTypeis 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.
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.
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.
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.1.0.0), 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).
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.
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.
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.
