All cards are widgets but not all widgets are cards. There are also Cell widgets and List Item widgets. Each are used in different ways/contexts.
Many widgets cannot be placed on a page on their own. They have to be included as part of another widget. All the List Item widgets fit this category. I believe this list also are widgets that cannot be placed on a page on their own. This is why they are not listed.
Thanks @rlkoshak!
Playing with e.g. oh-button in the “code” lets me place it as a component in a oh-grid-item in exactly the same was as e.g. oh-toggle-card. It works, but the aesthetics look out of place.
grid:
- component: oh-grid-item
config:
h: 1
w: 3
x: 0
y: 2
slots:
default:
- component: oh-button
config:
text: Middag
icon-f7: exclamationmark_circle
action: rule
actionRule: 27afc0a3-b898-46ad-acc9-e4a7541dcc22
large: true
class:
- display-flex
Example of a coded button (on top) vs a proper card on the bottom:
I believe adding for example an “oh-button-card” widget which had a design which aligned with the other system widgets would make it easier for normal users to design pretty pages.
Ha ha. I wouldn’t have bothered to ask if I knew in advance what your answer would be. 
You always have a good perspective which is why I ask your opinion.
I see your point about consistency, but DateTimeType is not a Java class; it’s an openHAB class. So I would argue that adding a toMillis method would not be inconsistent.
Yes, exactly, the first one is kind of nasty. That’s my point. But if you add a toMillis method to `DateTimeType, it becomes (3rd line below), which is shorter, and just as easy, if not easier, to understand.
var deltaMillis = now.toInstant().toEpochMillis() - (MyDateTime.state as DateTimeType).getZonedDateTime().toInstant().toEpochMillis()
var deltaMillis = Duration.between(now, (MyDateTime.state as DateTimeType).getZonedDateTime()).toMillis()
var deltaMillis = now.toInstant().toEpochMillis() - (MyDateTime.state as DateTimeType).toMillis()
Note, I’m not arguing against adding a toMillis() to DateTimeType. I’m arguing that, at least IMO, if you are using epoch in your rules, you are doing it wrong. (That’s probably more strongly stated than I really feel, but it is irksome when I see it on the forum. It’s like seeing someone try to code in a Fortran style in Python, anachronistic).
The inconsistency would be in use. When I have a DateTimeType I can just call toMillis() but when I have a ZonedDateTime I have to get the Instant first which means I have to remember two different ways to get to epoch and have to keep track of which to use in which context.
As it is now, there’s only one way which is to get a ZonedDateTime and get the instant and then epoch, so only there’s only one way to remember.
Until you need seconds, minutes, or even HH:MM:SS.mmm, care about the absolute value of the duration, etc. The raw millis are almost never all that useful to humans who might be seeing these values so they are either going to need to be converted anyway (or converted back to a ZonedDateTime) or they are only used in a calculation. And even in cases where it’s only used in a calculation, Duration.parse('PT5M15s') (or `Duration.ofMinutes(5).plusSeconds(15) if you prefer) is a lot easier for the human to read in the code than 315000 (5 minutes 15 seconds).
The human already has to hold a lot of stuff in memory to understand code. Why make them do math they don’t need to? The mere fact that the human has to mentally divide by 1000 (and perhaps again by 60) to know what the millis represents (whether it’s the result of a calculation or reading and understanding the code itself) makes working with epoch and millis directly inherently more difficult to understand, even if toMillis() were added to DateTimeType.
Auto suggestion of bindings to install
(for example in inbox and/or during first startup wizard)
I found this a good idea to simplify beginners setup (the issue is 1y old):
I would whish some kind of Energy Management in Openhab.
Therefore I could image one Energy Management Page which contains following information
Solar, Grid, Home Distribution Widget
see also Energy Dashboard - #11 by JamesC
Energy Consumption Charts whichs shows how much energy from solar or grid (stacked charts)
see also OH3 charts - how to stack values? - #3 by bastian
Solar Production Charts with solar forecast
This Energy Management Page shall have a today/day/week/month/year button.
(At the moment this is also not possible for chart pages, only one of day/week/month/year possible)
Improved internal handling of energy values in OpenHab.
At the moment you need several rules and items, e.g. calculate meter readings to consumption
rrd4j persistence service can actually not be used as it is persisting on every state change and at least once a minute (consumption values not correctly summed up on chart pages)
Overall most of it is already possible, but only with a lot of effort. A more straight forward approach for energy management would just be great.
On the top of my list would be a binding for Ngenic Tune (Ngenic Tune - smart termostat hjälper dig spara el & pengar – Ngenic) which would let me read and control the temperature in my house. They seem to have a really nice API (https://developer.ngenic.se/). I guess I really ought to do the coding here myself but I simply haven’t got the time 
oh. and because I’m struggling with that again :
This must not be one search over all, but within each type.
Use cases:
With file-based configuration, this can be done on OS-level, but I’d like to search for that within “rules” on UI-level also - as there’s no other (feasible) way to search in rules/items/… definitions in UI.
Well. There’s also talk behind the scenes among developers and maintainers and I’m sure they will also have a peek at threads like this one.
But for now, yours is a kinda off target request because it is about an application (or range of apps). Today openHAB isn’t providing applications - it is only a framework that lets you create yours.
For now, you as openHAB users are expected to implement applications.
You shouldn’t be expecting that to happen on sort of a schedule or roadmap from the core developers.
Energy Management is a huge field that comprises hundreds or more of devices and many many functions you may want to have implemented, from monitoring to reporting to overall and to specific control to maintenance and more. It’s much more than the charting aspect you have your focus on.
And most of what is not available so far is specific to the functionality you are looking for, let alone the devices and their environment (your household or even enterprise).
In the EM domain, we’re very far away from one-size-fits-all solutions or even a single “straight forward approach for energy management”, that’s not an openHAB thing in itself.
(I know well, I myself am selling a commercial EM system based on openHAB).
I believe we will be seeing more components to contribute to and to ease building EM applications,
but simply asking for a common approach is not really a productive request anyone of the OH community could effectively act upon.
As a final note: any user can already contribute to this on his own by sharing his solutions on the marketplace and forum tutorial section. I’d like to encourage anybody to work on his solution to spend some thoughts if they can also make it work in a (more) generic fashion so that if published on the marketplace, there’s more users that can also benefit from it.
This issue might be relevant to mention here:
Plan it to change DateTimeType to use Instant internally. We could add getInstant() - we could even do this independently - so would this suffice? So the example would be:
(MyDateTime.state as DateTimeType).getInstant().toEpochMillis()
I’m not sure exposing something like toMillis() is right, since you could then argue for exposing lots of other methods from ZoneDateTime and Instant, which you might as well use directly without propagation.
Agreed.
Yes, that would be an improvement.
as Markus already pointed out: openHAB is merely a framework, in which you can dive into without much programming skills - scripting for rules is a plus - for most simple use cases, blockly should suffice.
But apart from that you already linked to marketplace widgets, and for the summarized consumptions you can easily put together some proxy items, which you fill up with rules for daily/weekly/monthly/yearly consumption - if your inverter does not spit out those number already like most of them do.
What do you mean with your last bullet point “internal handling of energy values”? Like above? create summarized values? That’s nothing for the core - more for yourself as using a rule. Perhaps this rule template helps you with that:
another one for the section Setup/installation of the OP:
Support of SDD
(mstorm, I know that this is against your conviction, and I know you are never ever going to support this (which is ok). But this is a wish list, even for unattainable wishes…)
But openHAB is not the OS, so this is definitely nothing for the openHAB 4.0 wishlist.
The biggest issue at the moment is that diff_first aggregation of charts is not working. So the mentioned meter reading rule template does not really help if you want to create charts. This topic is also mentioned in following issue. Will there be a solution for this?
At the moment I’m creating consumption values within a cron job at every xx:59.
But as I wrote that was the intention of the OP:
Meta data for rules(validation, execution monitoring etc…)
Describe more what you mean about this. Rules already have a life cycle similar to Things. They even generate events as they are loaded, enabled, disabled, running, idle, etc. If the rule is not valid there is an error state the Rule can be in.
So there is already validation and execution monitoring which can be seen in MainUI on the rules page, in the developer sidebar event stream, or in events.log if you change the logging level of rule events so they get logged along with Item change events and commands.
I’d think something we would all benefit from is to have access in UI to “metadata” on rules such as
Ideally we would even have a full history record of rule runs with the data above. Many rules errors go unnoticed.