How do I get this widget to show in the semantic cards? It’s showing in the items settings:
But not in the card:
But not in the card:
You don’t. This is a stand alone widget. It can’t be used inside of cards. For that you need to set the default list item widget to an appropriate type of widget: DateTime List Item.
Bummer, thanks.
I worked around it by adding hours with stepper card and displaying the resulting DateTime. Two widgets though.
EDIT: Oh, is that what the difference is between ListItem and standalone? I have been scratching my head on that for some months.
Yes, standalone widgets “stand alone” on a page. List item widgets are a row inside a card (e.g. the Location card). By changing the default list item widget Item metadata, you can change how the Item appears in the Location, Equipment, and Properties cards. But you have to use a list item widget, not a standalone widget.
Hi all. It seems to no longer be possible to clear the value using the “clear” button. When I click the checkmark then the cleared value is not sent to the item. Did anything break in an OH update maybe?
I didn’t think anything had changed.
Have you tried on different browsers?
The best I can offer is to find an issue. Be sure to verify it fails the same way in FF and a Chromian based browser. Collect the logs from OH and the browser console.
All this widget does is set some standard settings. It doesn’t really implement anything itself.
I suspect this is one of those “feature, not a bug” situations. The oh-input has had better input validation added recently and this includes not sending invalid date-time values. A blank value would pretty clearly fall into the invalid date-time category if not the invalid data of all types category.
I’m not sure why you would ever need to send a blank value to a DateTime item, but if you’ve got a system that requires it, then you will either need some additional widget or rule that clears out that value or rework the system so that a blank value is no longer required.
2 Likes
Yes, unfortunately it’s the same behavior with Firefox and Chrome.
The use case I have is that - sometimes - I am setting a certain date until our heating should be disabled (when going on vacation). Once that time his passed, or if I wish to cancel this heating pause, the DateTime should be cleared. So you would suggest to e.g. use a second item instead to toggle this?
There’s no one right way around the empty DateTime item situation. In the simplest case, it sounds like you could keep what you have and just have some way of setting your DateTime item to some point in the past, which is a little easier to do than clearing it out. Depending on exactly how your rule works (and how much time you have/want to put into working on this), maybe it is even easier to have a separate rule, which you can trigger from a widget component, that does just post NULL to the DateTime item.
Another possibility is to take advantage of rule conditions. I have (probably dozens) of switch items in my setup that are pure “house settings”. They are not linked to any channel, they simply act (based on using them in rule conditions) to guide which rules run and which don’t. For example, when I go to sleep every night any basement lights left on are turned off. However, my guest room is in our basement and I don’t want to plunge any guests suddenly into darkness just because I’m going to sleep, so I have:
in my house settings. Several different rules are deactivated (include the basement lights rule) because this item is in their rule conditions.
However, based on this simple description, I would say that if I had this situation I would probably break this up into several smaller pieces. The two fundamental pieces would be scripts (triggerless rules) one to enable the heating and one to disable the heating. Then I would have several triggering rules that would cause one of these two scripts to run when needed. That way I could have as many different scenarios to control the heating state as I need, For example, 1 rule (which could be entirely configured in the UI as now code lines are required) that calls the enable heating script based on the state of a DateTime item, and a second rule calls the enable heating script based on the temperature forecast…etc.
There is a strong tendency (I have it to) to treat rules a monolithic code blocks that must encompass all circumstances, but the ease with which rules can call other rules really means that treating a rule as a smaller specific use function and linking these functions together is just as viable (if not preferable) in certain circumstances.
1 Like
You could even use scenes for a lot of what you describe.