laursen
September 27, 2023, 12:13pm
38
Whoops, I should probably consolidate as either VAT or Value-Added Tax. Thanks for noticing.
Yes, this part I cannot “fix” without removing the Danish translation. It happens because translations are not available until the add-on has been installed. It’s a bit unfortunate. The unavailability of such metadata before installation is also related to other issues:
opened 10:06AM - 02 Sep 23 UTC
enhancement
main ui
Seeing the nice results of #1997 I thought I'd finally suggest to use the new [a… dd-on metadata](https://www.openhab.org/docs/developer/addons/addon.html#xml-structure-for-add-on-definitions) introduced in 4.0 to provide either filtering or additional search options.
I don't know if this is technically feasible, i.e. if the UI has access to these metadata when bindings are not yet installed. If not, please feel free to close this issue.
## The problem
There is currently more than 350 bindings available which are shown in a long list per default:
It's possible to search by name, so it's not hard to find a specific binding.
## Your suggestion
I'm not UI expert so I'm not sure exactly what would be the best suggestion here. But I will throw a few ideas anyway. 🙂
I'm wondering if the metadata **connection** and **country** could be taken into consideration. Per default we could exclude bindings having **countries** declared where none of those countries match the country configured in regional settings. So for example, when in Denmark:
I would not see any of these:
```shell
$ grep -R "<countries>" | grep -v "dk"
bundles/org.openhab.binding.dsmr/src/main/resources/OH-INF/addon/addon.xml: <countries>nl,be,lu,at</countries>
bundles/org.openhab.binding.hccrubbishcollection/src/main/resources/OH-INF/addon/addon.xml: <countries>nz</countries>
bundles/org.openhab.binding.kvv/src/main/resources/OH-INF/addon/addon.xml: <countries>de</countries>
bundles/org.openhab.binding.linky/src/main/resources/OH-INF/addon/addon.xml: <countries>fr</countries>
bundles/org.openhab.binding.meteoalerte/src/main/resources/OH-INF/addon/addon.xml: <countries>fr</countries>
bundles/org.openhab.binding.nzwateralerts/src/main/resources/OH-INF/addon/addon.xml: <countries>nz</countries>
bundles/org.openhab.binding.sncf/src/main/resources/OH-INF/addon/addon.xml: <countries>fr</countries>
bundles/org.openhab.binding.vigicrues/src/main/resources/OH-INF/addon/addon.xml: <countries>fr</countries>
bundles/org.openhab.binding.windcentrale/src/main/resources/OH-INF/addon/addon.xml: <countries>nl</countries>
bundles/org.openhab.binding.ecowatt/src/main/resources/OH-INF/addon/addon.xml: <countries>fr</countries>
bundles/org.openhab.binding.freeboxos/src/main/resources/OH-INF/addon/addon.xml: <countries>fr,it</countries>
```
However, maybe there could be a checkbox to see all when the UI knows something has been excluded. Certainly it should be possible to install any binding (I'm not suggesting geo-restriction 🙂 at all), so there should be some simple way to bypass and see all.
Another small idea would be to allow filtering based on **connection**. I'm not sure how to consistently provide such an option in the UI, but I'm thinking if it could work the same way as GitHub issue/PR search (and to some extent Google) where you could add something like "connection:local" or "-connection:cloud" to exclude cloud. For example:
I realize this would be a quite hidden feature, so hopefully someone would have a better idea.
opened 12:24AM - 26 Dec 21 UTC
closed 04:32PM - 07 Dec 23 UTC
I'm creating this issue as [I mentioned an idea](https://github.com/openhab/open… hab-addons/pull/11834#issuecomment-1000441090) over in another discussion. I haven't detailed it out in any way, but we could use this issue to discuss whether it makes any sense to pursue it at all.
The rough outline is: Many "Things" can be discovered nowadays through mDNS+UPnP. openHAB currently only adds them to the Inbox, if the user has already installed the according add-on(s). Especially for new users, it would be very nice if this wouldn't be possible: openHAB could identify supported devices and suggest the user to install certain add-ons instead (e.g. as a step in the setup wizard that @ghys created with the main UI).
There might be different ways to realize this:
1. The bindings currently implement a `DiscoveryParticipant` service. These are usually in a separate package and pretty independent of the other binding code. We could create a single new bundle in openhab-core that contains all these `DiscoveryParticipant`s and which is part of the default installation. The problem with this approach would be that add-on specific code would have to be added to openhab-core as well. This is imho neither from an architectural point of view nor from a contribution process a desired setup.
2. We could come up with some new concept, like additional metadata within the openhab-addons repo, which only contains the discriminators that are required to identify a supported device from a mDNS/UPnP info object. This metadata could be made available as a file (or files in a folder) to the distro and some generic core feature, which evaluates this data and that is capable to provide a list of add-ons to the UI that the user might want to install. While this approach won't be able to directly add Things to the Inbox, it might be a suitable way to also bridge the gap between discovery and still requiring the user to install the add-on before a discovery result can anyhow be accepted.
Let me know what you think!
A PoC for the discovery issue is currently in progress. It will be interesting to see the final outcome and if this will pave the way for resolving some other issues as well.
laursen:
So you can simply create another item for this fee for your electricity supplier and include it in the TotalPrice group.
I may have overlooked that.
Using a manual updated item could be used. And then use a rule to set the value for the item dependng of the hour of the day, due to my subscription to Modstrøm. I think thats the easiest way.
Exactly. However, it’s new to me that some electricity suppliers have dynamic rates during the day. I thought that only applied to spot prices (obviously) and net tariffs. Be aware that internal calculations in the binding will not consider such externally supplied rates. So far this wasn’t a problem, since you really just want to get the cheapest price, and with fixed rates, the fee of the electricity supplier would not make any difference.
This is probably good to have in mind for:
opened 08:56PM - 07 Jan 23 UTC
enhancement
I'm creating this issue to start brainstorming ideas which may or may not grow i… nto something. For starters, I will share some unstructured thoughts, which could grow into something structured and potentially into something that could be designed and implemented.
Let me start out by sharing some links which can shed some light into where I'm coming from with this:
- https://github.com/openhab/openhab-addons/pull/13416#discussion_r980432359
- [Dishwasher price calculation automation](https://community.openhab.org/t/dishwasher-price-calculation-automation/139207)
- [Meter readings from Kamstrup Omnimeter with Pow-K+](https://techblog.vindvejr.dk/?p=523)
My initial need is integration to services providing future energy prices. After that, having these prices, I would like to be able to perform calculations. These calculations should be implemented once with a common interface, no matter from which service the prices were obtained. I wonder, from an architectural point of view, if this already means something is needed within openhab-core, since addons cannot depend on other addons? For example, core could provide some interfaces and calculations, while addons could integrate various API's implementing such interface.
Now really brainstorming/dreaming. For the dishwasher example, I logged energy consumption during our most frequently used program and manually mapped that into a timetable in a rule. Considering being able to select the last run specific program on some device (having an energy consumption channel which can be persisted) and map that into another timeslot to calculate the price of that, or having the ideal timeslot calculated automatically within some boundaries. I guess this is just a use-case for the price integrations and calculations and an application which should be built outside of openHAB itself, but just wanted to mention this, so that the parts needed for this could emerge.
I now also have almost real-time logging of the power consumption in my house (see third link above) provided a current power (W) as well as accumulated energy consumed (kWh). The accumulated value is updated once per hour, and current power is updated every 10 seconds. With this data I would like to be able to create a graph like this (screenshot from [AMS reader](https://github.com/gskjold/AmsToMqttBridge)):
For this some post-processing is needed, since I receive the kWh data like this:
```
2023-01-07 21:00:07.940 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Omnipower_Accumulated' changed from 14609.85 kWh to 14610.24 kWh
```
i.e. as totals, not hourly contributions. So (14610.24-14609.85) kWh = 0.39 kWh from this log example, which is shown as last bar on the graph above. I'm not sure what is the best approach for doing this, but again it would be nice with something consistent and reusable.
I will update this issue with additional thoughts and knowledge from all of you.
I'm currently considering providing a small binding fetching data from EnergiDataService which is a Danish service providing prices. Yesterday I was also able to receive the same prices from ENTSO-E, but in EUR. So this could reach a broader audience, but would additionally require integration to online currency exchange rates to have conversion to local currencies. Currency question: Do we have any kind of currency handling in openHAB?
