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 
1 Like
oh. and because I’m struggling with that again :
- implement a search over UI-based entities like
** rules
** scripts
** items
** things
This must not be one search over all, but within each type.
Use cases:
- Searching for the rule(s) in which an item gets updated
- Searching for the metadata of items to perform mass updates on those
…
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.
4 Likes
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.
4 Likes
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…)
3 Likes
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.
1 Like
But as I wrote that was the intention of the OP:
Meta data for rules(validation, execution monitoring etc…)
1 Like
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
- compiler(interpreter) error messages for a rule, including line numbers
- timestamp and trigger why a rule was started for the last time
- the code line where it terminated (!) * this is the most important one *
and why (Java or DSL/JS interpreter/… error message)
This isn’t apparent from the logs in many cases and even if so, hard to find. - eventually another nice addition would be the ability to define a set of items on a rule that makes OH record their states when the rule is being executed
Ideally we would even have a full history record of rule runs with the data above. Many rules errors go unnoticed.
6 Likes
Record where/how? How would this be used?
Depending on the use case, this might be supportable through a Rule template.
In addition to mstormis suggestions: it’s about getting the (existing) information into the main UI, easy accessible with more Ux than searching in log files
1 Like
Neither did the OP mention SSD nor was he referring to HDD or other generic HW support.
If you refer to posts you should at least be reading them first.
And leave it to any OP to explain their intention.
I would love to see some Widget tutorials by @ JustinG . Either on the openHAB Youtube channel (which would be awesome because you could show something there step by step) or as pages in the openHAB documentation based on the ones that @rlkoshak did.
Justin, it is just amazing what you do with widgets and I would love to see some tutorials, so more people eventually are able to write custom widgets like you.
… which doesn’t mean that there aren’t also others here in the community who do amazing widgets stuff - so if anyone feels you could do that, please do.
10 Likes
Thanks for your summary in the beginning but you may mark this one as 
(see my comment regarding that)