There are many tutorials on these on the web that are going to be better and more thorough than anything we could write here. They are standard web page technologies.
This could be done in a rule and it sounds like a good rule to be a rule template on the marketplace. In one approach, the rule could iterate through all the Items with a given metadata and create a Timer to command the Item at the given time.
We are slowly rebuilding the docs, but without a replacement ready I don’t see how we could archive what’s there now. So we are slowly just replacing what’s there with new.
These are the sorts of things I was hoping to answer with my suggestion of a full text search. in my wish list. Perhaps I was jumping to a solution rather than outlining the actual problem which you did well here.
The REST API endpoint already exists. Others have pointed to the PR for the UI changes.
What’s missing beyond Items (which is in my wish list)? What can be done to make it better? Given that most users who are posting to the forum for help are using MainUI exclusively, improvements in this area are important. They should be added to the list of wishes.
Absolutely yes, but maybe not installed be default. ECMA 5.1 is already moved to an add-on and there is an issue open to move Rules DSL to an add-on as well, though that will be a big job so it’s not clear if it will get done before a 4.0 release. I think there is a desire to get it moved though so expect it to happen eventually.
These are also good examples for having a csv export functionality so that these kind of work can be done in e.g. in Excel and then upload the file for updating changes.
Keep the textual configuration (for things, items, sitemap, settings, …) and keep the current syntax (which is more readable and easier to manage than a JSON file at least for any normal human.
Keep the DSL rules (as JS Scripting is apparently (what I read) not yet reliably usable on a very small machine like a Raspberry PI)
the integration of Sauter radiators (Cozytouch through SomfyTahoma binding) => in my own TODO list
the integration of new hue API which means apparently faster feedback without the need to poll data and which will also mean in my case to buy a new hue bridge => a big PR exists but has to be tested and reviewed & merged
I wish for a smoother transition from 3.x to 4.0 than 2.5 to 3.0. It took me weeks (no full-time obviously) to get openhab working again. On the bright side I learned how to work with docker as that was the only way I could think of to easily switch from a working 2.5 to a partially working 3.0. Unfortunately that meant moving away from openhabian.
Keep the textual configuration. They are much more easy to maintain in a Docker environment.
Add a possibility to have a direct URL for the Location tab in the Main UI. I would really like to have it as the main entry point on my smartphone which is not possible at the moment.
The change in the first number of OH versions means there will be many breaking changes. Stuff you may have used will go away (e.g. 1.x add-ons) or change. That’s the nature of breaking changes. Obviously the developers do what they can to help but ultimately it’s going to take some work. It’s never going to be as smooth or pain free as a second point level upgrade (e.g. 3.3 to 3.4).
Things I can point out which might be a problem so far (it’s been only a couple of weeks):
there might be problems if you are on an end of life operating system (e.g. Debian buster, unsupported versions of OSX) as Java 17 is unavailable and/or some of the system level libraries are too old
some things that just come with OH might require installation as an add-on (e.g. Nashorn JS), it remains to be see if it will be possible to detect that you were using it and install it automatically.
I’m not sure what running in a Docker environment has to do with anything. If you are doing a standard configuration as outlined in the docs, you have volumes mapped for both conf and userdata. All the UI configured stuff is in userdata (and it’s all text too).
I’m not saying you should change, but if Docker is the only reason, it’s not a valid one. There is nothing about UI configs that are harder or easier in Docker compared to text configs.
I understand and don’t get me wrong, I am very happy with all the hard work of the developers. Just consider it an item on the wish list. For now your list is reassuring. It already helps if people make these lists, that way others (users and developers) can think about how to mitigate the impact.
Let me elaborate a little bit:
For me, Docker is mostly about having the possibility to move from one environment/host/node/whatever somewhere else, start it and have the same result as you had before.
The textual configuration in the /conf folder can easily be moved over (for me I’m having those in a git repository).
However there are lots of files in the /userdata folder that are not specific to my configuration, but just general stuff that OH needs to run. Logs go into that folder too and you would not want to move those to a clean install, would you?
In addition OH won’t perform its first-start-logic if there is something present in the /userdata folder.
In the end it is not about the format of the files (.things, .items, … vs .json), but about their location.
Non-interactive batch import/selective export for things & items ? I have no clear picture yet, just thinking out loud.
It would not be exactly textual configuration but almost, bringing text config’s benefits such as scripted generation by provisioning tools and external editability to MainUI, ideally obsoleting today’s still existing need for OH1/2 Xtext based config files.
Yes I would, many of them anyway. If I’ve made any configuration changes to add-ons, my locale, default units of measurement, etc. I need the contents of userdata/config. If you don’t include that you’r backup of the OH config is incomplete. If you’ve changed your users, logging, want to preserve your uuid and secret for the cloud connector, those are all in userdata too.
If you are truly trying to preserve your configuration than you don’t want the first start logic to run, except in the case where the userdata folder is for a different version of OH than what is in the container, in which case it will back up what’s there and do the initialization/upgrade steps necessary.
You can force it by changing the version number in userdata/etc/versions.properties to be different from the version of OH in the image if you really wanted to force it to run.
Were I to try and approach that today with OH right now I’d use JSON and the REST API to push such configs. That should hit much of the requirement. Of course, as I said before, working in JSON directly is pretty miserable but if you built it up initially how ever you choose to, export the JSON from the API and then it wouldn’t take much, could even be a shell script or a small Python script, to mix and match the JSON and push it back into OH. It probably wouldn’t be too hard to figure something out in MainUI itself for this as well given there’s no new REST API endpoints required.
But I think this idea has additional use cases. One of the biggest complaints a lot of people have is how hard it is to bulk edit in MainUI. And while it’s true that this is a relatively rare activity most end users will face, it would still be a nice feature to have.There might be more.
I have worked on this in the past week, and according to some user feedback, there are some improvements, e.g. JS Scripting performance problems compared to Nashhorn - #17 by MikeJMajor.
Unfortunately, I am not really able to test myself, because I am running openHAB on a more powerful machine with a decent amount of RAM.
I would be happy to get some feedback how the current SNAPSHOT performs on smaller machines like Raspberries.
The language, region, etc. can be set in /conf/services/runtime.cfg
##################### LOCALE ####################
# The default language that should be used. If not specified, the system default locale is used.
# The ISO 639 alpha-2 or alpha-3 language code (if there is no alpha-2 one).
# Example: "en" (English), "de" (German), "ja" (Japanese), "kok" (Konkani)
#
org.openhab.i18n:language=en
# The region that should be used.
# ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code.
# Example: "US" (United States), "DE" (Germany), "FR" (France), "029" (Caribbean)
#
org.openhab.i18n:region=DE
org.openhab.i18n:location=123,123
org.openhab.i18n:timezone=Europe/Berlin
I have a script in /etc/cont.init.d to read the UUID and secret from an environment variable which I set in docker-compose.yml
#!/bin/sh -ex
if [ ! -z ${OHC_UUID} ]
then
mkdir -p /openhab/userdata
echo ${OHC_UUID} > /openhab/userdata/uuid
fi
if [ ! -z ${OHC_SECRET} ]
then
mkdir -p /openhab/userdata/openhabcloud
echo ${OHC_SECRET} > /openhab/userdata/openhabcloud/secret
fi
I’ve set up all addon installations, user logins, settings, etc. so that everything is set up automatically just how I need it. If I need something changed, I can just change the files in /conf and /etc to restart/recreate the container.
I would like to improve the usability of the UI a bit.
I personally do not like to change between mouse and keyboard so often and prefer to work with the keyboad only as much as possible.
So these features would be nice
WebUI:
when I am in a selection list (e.g. category for an item) and only a single element is left after entering the filter text, it is selected automatically when I press
when I press in any window popup, the popup is closed
what about key shortcuts
when I’m in some page that allows editing - pressing “e” goes to the
when I’m in some page that allows “back” - pressing “backspace” goes
when I’m able to “save” changes +S will save the changes
… to be extended
when I press “reload” in the model page I’m still seeing my currently selected item and not the root
widget develpment:
currently the list of properties available with items[<itemname>] in custom widgets is limited to (display)State. I would like to also have
** Name
** Tags
** metadata
and then counting those that would be solved by a solution for that PR, I conclude: It’s a lot. I know it’s like wishing for socks, but both developers and users would benefit from this. Users would experience fewer breaking changes, and developers would be more free to get rid of technical debt without having to implements all sorts of work-arounds/backwards compatibility tricks and provide distro PR’s announcing yet another breaking change.
I’ve already updated my post where I have all of my wishes, but here’s a couple more basic ideas around the UI and context awareness. Mostly useful new new people, but still useful
A simpler way of using the state description pattern through the Main UI to pick, choose and display units, that do not require using special characters. E.g.: if I want to display my units in watts, let me choose through a list menu, drop-down menu or similar, and have the unit automagically appear in the item/dashboard/mainUI etc.
Linked to previous topic:
Add a link to the relevant documentation to help those who might not be familiar with it.
E.g.:
1.) metadata / state description : link to UoM documentation
Like so:
Which relevant rules page? There’s more than one already and there’s going to be more. The rules controls page? Parts of the Getting Started Tutorial? The readme for the automation add-on?
Fair point. So I’d expect each one of those rule pages will have (or already have) a relevant page in the documentation website. What I’m asking is for these pages (relevant for each rule menu you just pointed out) to be linked (somewhere, maybe a ui icon in that same page? Something a “help” icon.) in the main UI menu itself.
that way the relevant documentation is linked in the main ui itself.
Hi Rich,
thanks for your answer, but for me it’s not clear what are you referring to. I know “createtimer” + “expire”. Createtimer is lost after a reboot, expire (as far as i learned from several threads) is recreated after a reboot, but it starts completely new and not only the remaining time. May I ask you to give me additional hints?
I’m not sure how to make it clearer. Maybe step-by-step.
Create a DateTime Item which stores when the timer needs to go off.
Create a rule that has the code to execute when the timer goes off.
Add a trigger to the rule to trigger it based on the state of the DateTime Item created in 1.
If you have a customized persistence config, make sure the DateTime Item created in step 1 gets restored on startup.
The rule will run at the DateTime stoked in the Item. Persistence will restore the state of the DateTime so that the rule will run at the scheduled time even after a reboot.
This: