Missing Features/ Feature request

Setup, Configuration and Use Runtime
1

Hi all, I love Openhab, however there are a few features I find that are missing and I will be happy to help out implementing them. What features are you missing, below is my list.

  • Autoupdate-Well only a handfull would like to go into putty and use sudo update…, my GF and I would like to get notifications if a binding got updates, system etc and then have link where we can update and see the release notes)

  • Chromecast - binding does not support youtube videos…

  • item.lastUpdated - It would be nice to not manually create rules and proxy items to be able to display in a sitemap when last motion occured etc…

  • Parisng value to label - Be able to send a value to an item label

  • item.persitance - Set that the item should be persisted easily instead of adding it to groups (@rlkoshak method), easier for beginners

  • Language support - item definitions in several languages, auto translations of labels…

  • Alexa(Voice) - several spoken commands allowed for the same item. Today we need to make proxy items if both Hallway, entrance, entre, flur… are allowed commands

  • item.map - Items can be mapped in sitemap, however the icons will not follow if you map items(battery icons requires value between 0-100 so if you map a battery items from 0-5 to 0-100 icons will not follow…)

  • Sitemap textitem input - For instance you wanna be able to change labels of plant sensor, give email adresses in etc…

  • Change items in Sitemap - Right click on item in sitemap and you will be able to alter label, refresh interval etc…

  • Timers - There is not possible to change cron timers from sitemap

  • synchronization between paperui and text files - Things etc does not show up in text files on the disk

  • Backup to Git or other solutions - It would be nice if openhabian @ThomDietrich could have an easy flow to backup files from the vs editor to your own hardrive or git account

  • Sitemap timer picker - not possible to select time in sitemaps

  • Sitemap date picker - not possible to select date in sitemaps

  • Myopenhab multiple users - not possible to have multiple user or multiple user with different access level to myopenhab

  • My openhab accsessing several devices - I have openhab at home and at the boat, would like them to show up as two sitemaps, not possible today.

  • Notifications by default if there are errors or items are not responding - Many users does not realize if there are errors, if a sensor goes out of battery(item not reachable longer) etc, some basic notification could be provided.

@rlkoshak Missing features:

  • The ability to set OH 1.x binding configs through PaperUI. This is a major hurdle for some users who do everything in PaperUI and then run into the need to use Expire or MQTT and suddenly they have a whole new thing to learn.

  • Persistence setup (i.e. which Items are saved to which persistence with which strategies) through PaperUI

  • Sitemap builder in PaperUI, though I can accept if the answer for that is HABPanel

  • HABPanel app on the phones so I can get myopenhab.org notifications and use HABPanel for the UI, though the mitigation of using the OH app for notifications and HABPanel for UI is not overly onerous.

  • Once PaperUI supports everything that can be done in .items files, a migration script or import function to take a .items file and import it into the JSONDB (using the REST API?)

@Udo_Hartmann Missing features

  • I would love to have back a list item type, e.g. to store the last x calls. Naturally we would need a list widget as well (maaany options possible, e.g. columns, sort, filter, scrolling, fixed height, headings…) Maybe this could be done as XML, CSV or JSON? I’m no software engineer…

  • Timestamp of last update could be a second parameter (or a third, when it comes to a call item - by the way, where is the call item OH2? Just realized, it’s not in the items article). Then it should be possible to set the label like “My item (updated %2t) [%1s]”

@kubawolanin missing features

  • One thing I’m really missing is relative time for DateTime items.
    If implemented on UI level, it’s simple to do with libs like moment.js. I’m aware you can technically use JavaScript transform for each item, but that’s a bit overkill.

@Mihai_Badea missing features

  • Webview element to display url stored on String item.

@davez34

  • Editable datetime on the sitemap.
  • Built-in delayed rules startup. If my rules start before my bindings, I sometimes get a lot of errors.

Thats all that I feel is missing at the moment, maybe @Kai can explain if some of these issues already are in the OpenHab Pipe line.

2 Likes
2

Are you referring to having OH update itself versus the more typical (on Linux at least) and allowing the package manager to manage upgrades. I can definitely see adding something to the dashboard to indicate there is a new release available. I’m a little uncomfortable about adding upgrading of OH to OH itself. I worry that OH will get out of sync with the package manager and all sorts of problems could occur.

From a practical perspective, I also worry that users will ignore upgrades to their base operating system and miss out on important security related updates.

I don’t understand. How is this different from using a transform in an Item’s label?

The current options are to use the Group Based Persistence DP or adding each Item to the .persist file individually. What do you propose to make this easier?

Here I’m uncomfortable with adding yet another element to the Items definition. IMHO the Item already has too many parameters. On the other hand, this could be an approach to bringing persistence configuration into PaperUI.

But I do not see any changes along these lines as making it easier for beginners. All it does is change where one defines Items to be persisted.

Definitely

I really do not like this. The sitemap is the home automation User’s Interface. Do you want every user of your home automation to have the ability to change your Items through a right click? Unless and until there is support for user authentication and authorization and the ability to assign user’s roles so only an admin user can do this on the sitemap I’m very much not in favor of it. And even then, I am uncomfortable with it.

There is already work ongoing to add a scheduler engine to ESH core I beleive. There was talk about it at least at some point. Once that gets released I think all we will need is a date/time picker.

I’m pretty sure this will never happen. What may happen is the text config files will probably become deprecated (far far into the future). All of the PaperUI configured stuff is in text files though, they are just in the userdata/jsondb folder.

Yes, though there will probably only be one element with options. It gets complicated though because there are lots of use cases:

  • at a certain time and date
  • every day at a certain time
  • every x days/weeks/months at a certain time
  • at a certain time only on certain dates
  • at a certain time only on certain days of the week
  • at a certain time only on certain days of the month

This is not a simple widget. Add to that the need to change not just BasicUI but also the phone apps and it turns into a whole lot of work. I suspect that is why no one has taken it up yet.

There is an issue open for this that has been open since before 2.0 release. No one appears to want to work on it.

It’s absolutely possible, just not easy. You would set up MQTT Event Bus and dedicate one as the “master” OH and create a sitemap on the “master” to represent the other site.

My missing features:

  • The ability to set OH 1.x binding configs through PaperUI. This is a major hurdle for some users who do everything in PaperUI and then run into the need to use Expire or MQTT and suddenly they have a whole new thing to learn.

  • Persistence setup (i.e. which Items are saved to which persistence with which strategies) through PaperUI

  • Sitemap builder in PaperUI, though I can accept if the answer for that is HABPanel

  • HABPanel app on the phones so I can get myopenhab.org notifications and use HABPanel for the UI, though the mitigation of using the OH app for notifications and HABPanel for UI is not overly onerous.

  • Once PaperUI supports everything that can be done in .items files, a migration script or import function to take a .items file and import it into the JSONDB (using the REST API?)

I’m sure I’ll think of more. I would put the text input and date/time picker as my top two priorities. Not that that counts for much.

1 Like
3

Well it would be nice to write

Switch Presence_home label=“Somebody is at home (last updated: 15:44)”

where 15:44 is another item for when the update happened last time…

2 Likes
4

I seriously hope this will not happen before PaperUI is able to perform some multi-object editing. Or another scriptable solution exists

PaperUI is nice for maintaining a few devices, installing, removing and similar stuff. But if you are running many identical devices, or even just many devices, the clicking and editing gets ugly quite quickly.

I put everything in *.things and *.items files and my system is up and running after the first start, without manual interference (except for copying the files in).

2 Likes
5

It would happen long long long after PaperUI becomes fully capable in almost every way. And even then, the .items files will probably hang around for awhile. But the writing is on the wall.

There is nothing preventing you from editing the JSONDB files yourself. Or writing a script to quickly do stuff like this through the REST API. .items files and .things files are not the only way to get this sort of experience.

I have all of my Things managed by PaperUI and I just copy some files and am up and running without manual interference as well. Everything created and managed by PaperUI is stored in the text JSONDB files. I even use git to config control and keep track of the history of my Things in JSONDB.

There is pretty much nothing I can’t do with jsondb that I can with .things files.

6

When it comes to feature requests… :slight_smile:

I would love to have back a list item type, e.g. to store the last x calls. Naturally we would need a list widget as well (maaany options possible, e.g. columns, sort, filter, scrolling, fixed height, headings…) Maybe this could be done as XML, CSV or JSON? I’m no software engineer…

Timestamp of last update could be a second parameter (or a third, when it comes to a call item - by the way, where is the call item OH2? Just realized, it’s not in the items article). Then it should be possible to set the label like "My item (updated %2t) [%1s]"

Text input would be very nice, I would use it to send text messages to the vdr via openHAB UI :slight_smile: (for now I have to login via ssh to send a message manually) Even would be nice to set values directly instead of sliders or setpoint widgets.

7

I had my jsondb cleared automagically several times, maybe you remember. Even clicking in the inbox and adding a location is ugly when you are running 120 devices. (Adding the location is neccessary to even open up the control view with that number of devices). Sure, i could add more horsepower than a pi3, but if it’s running it performs well enough.

If you are familiar with editors, nothing comes close to the usability of the powerful search & replace functions of an editor like VS Code. Sure, i can do it with jsondb as well, but json is not that easy to read as the current csv style.

I will add two new devices (of already existing type) the next days. With the current structure it is mark, copy, edit one line for the things file and mark, copy, search and replace for the name and channel.

With PaperUI it’s a bit more complicated, not impossible, but more complicated.

If a thing is changed, the thing needs to be deleted and re-discovered, if this thing is a bridge all dependent devices are deleted as well (if i recall correctly).
With things files, the line/s is/are commented out and after one or two restarts back in. Done.

Don’t get me wrong, i am not argueing against PaperUI/jsondb, it is great for starters and opens up openHAB for many people who dislike file editing. But don’t kill the current files without a reason, just because it’s not hip and trendy to edit csv type of files.

8

No one need worry that the .items and .things files will go away anytime soon. They will be around for years to come I bet. However:

  • even now not all bindings support the creation of Things through .things files

  • as time goes on eventually there will be more and more features added to Items and Things that will become difficult if not impossible to support in the standard .items and .things file formats. At some point, it will become more trouble than it is worth to maintain the old .items file format as the format of the .items file continues to become more and more complex needing a structure that more and more closely approximates the JSON anyway at which point it stops making sense to maintain them both

  • no one is going to eliminate .items and .things files until PaperUI has a complete set of features to support both newcomers and advanced users

Before VSCode came around there was on the roadmap a replacement for Designer that was web-based and one of the UIs built into OH. I still think that is the plan though VSCode has taken the pressure off a bit, though the main focus for it will be the Experimental Rules Engine which, at some point will become the default rules engine, and sometime after that point .rules files will start to become deprecated as well.

But remember, ALL of this is well into the future. No one would expect any users, let alone advanced users, to get by with just PaperUI.

9

Thanks for the info.

Is such a roadmap accessible, or is this cluttered inside some forum posts?

That’s another point i do not understand. I checked the current state of the experimental engine. If that’s the direction, i do not understand why this rule engine need to replace anything. A simple template engine on top of the existing engine would be sufficient. Again, a roadmap or a document about the directions would be great, but i did not find something yet.

I am not against change, if we could change the current rule engine for something else i’ll be the first in line to support it. If that “something else” is better or more common.
The largest problems of the current rule engine is lack of documentation, no line numbers when errors happen and uncommon syntax, maybe uncommon aproach.

But on the pro side, you can do everything and it works.

10

One thing I’m really missing is relative time for DateTime items.
If implemented on UI level, it’s simple to do with libs like moment.js.

I’m aware you can technically use JavaScript transform for each item, but that’s a bit overkill.

Anyway, just my 2 cents :slight_smile:

11

Apart from some specialized widgets, the sitemaps are missing an “include” mechanism. From an outside view, this doesn’t look too complicated.

Include file="<filename>.sitemapinclude"

And just replace the include stuff with the file contents. Sure, some syntaxparser would be neccessary, but this almost the same as for sitemaps, just don’t enforce the Sitemap object.

According to my opinion a large number of the requests for user management could be handled with this. (I assume, many people just want to provide a simplified view to some users. May be wrong, may be right. )

12

I was hoping that it would be like on apps on android, so that my GF easily can see when she launches openhab app/ sitemap in the browser that she then gets a notification that updates are available and get asked if she want to install them or not. If she then clicks yes then it starts the package manger on the OH server.

13

This is a feature of the package manager/os not an application feature. I’m quite sure, similar stuff exists for apt.

14

Well it needs to be programmed in the various GUI for OH (android app, sitemap in browser) so that when it starts it check the local server version vs Openhab server version for bindings updates and system updates.

I am not talking about finding out if the app has come in a new version or not, but my GF never goes into to putty and type in sudo apt-update to find out if something should be updated or not…

15

Just go to the tutorials section, there is some example to exactly do that.

In order to perform the upgrade you may need to elevate the user permissions.

But i wouldn’t suggest something like that, i never saw a maintenance upgrade for openHAB, usually it’s a feature upgrade which needs manual interference most of the time.

openHAB is just the Framework, the real App is your Sitemap/HABpanel.

16

It doesn’t say anything in the tutorial how to do it, as I can see!

update
update.png999×219 11.7 KB

What my GF would like, and I also kinda is to get a push notification when 01,02,10 in the image above should be done, then just press OK, confirm with the openhabuser and password and a command is sent to OH server which then execute the above commands. Will this be hard to implement @ThomDietrich ?

Without having to find a pc, log into putty and then do it… OH is moving towards a non geeky Home system, where you can go online buy a HUB(rpi, with openhabian installed on it), plug in power, download openhab app on ur phone, then setup basic info as sitemap name, wifi credentials, usernames etc… then it autodiscover your things through Paper UI, and you create your rules like strigify and your gui with habpanel inside the app on your phone…

17

Currently it’s partially doable, but the request for user/password is impossible, no widget exist for that.

openHABian doesn’t provide a web interface, it’s console only. I wasn’t talking about openHABian, i was talking about this:

18

Nice tutorial, then we simply need a button to press to confirm to update… could use exec binding…

However it does not check if a binding is in a new version or?

19

However it does not check if a binding is in a new version or?

With openHAB you always get a full release. I have no idea about marketplace bindings.

But as i wrote before, you usually get no benefit from upgrading openHAB. The benefit comes when you use the new features somewhere in your sitemap or rules.

20

Look at the open Issues and comments on Issues. This particular discussion was on an Issue on Designer.

The current Rules Engine does not support:

  • reusable libraries that can be distributed through the IoT Marketplace
  • the ability to use other more popular programming languages (e.g. JavaScript) for the logic versus a custom DSL
  • there were other things kai mentioned that I can’t remember at the moment.

The current Rules DSL will not support this.

Are you running 2.2? Since 2.2 you get line and column numbers in openhab.log for syntax errors. Sadly, it does not support (nor can it support if I understand correctly) line numbers for runtime errors. Yet another good reason why the Experimental Rules Engine is needed.

I don’t know your GF, but i shudder at the thought of my wife blindly applying updates to OH. If one is running the SNAPSHOTS they necessarily need to be prepared for stuff to break since the snapshots are Alpha level maturity. If running the release version, then there is a high likelihood that there might be breaking changes when going from one release to another release. So again, one needs to be prepared for stuff to break.

Given the high likelihood of something breaking I strongly believe that any upgrade needs to be done in a controlled manner with fallback options. Personally, I don’t think it is wise to allow any user of OH to blindly upgrade it.

With the start of 2.2, there is now the infrastructure in place for maintenance releases. There is no guarantee there will be one, but it is not theoretically possible.

10 shouldn’t really need to be done more than once unless openHABian makes some major changes/additions.

01 pulls down updates of openHABian itself and 02 is an apt-get update; apt-get upgrade.

If you are OK with blind updates/upgrades, which having a button to press on the sitemap would necessarily be given the lack of feedback, why not just set a cron job and have it run in the background once a week or once a day or something?

Drop the following into /etc/cron.daily and it will implement 02 once a day:

#!/bin/bash

apt-get update 
apt-get -y dist-upgrade

Again I can’t say I would recommend this because there may be changes to config files that the package may make (remember the switch to log4j2 in OH? other packages will do the same) and I think -y will just blindly reject those changes and keep the old version.

In short, until we have OH running on something approaching firmware instead of a general purpose OS and there is a mechanism to upgrade the whole thing in one go (i.e. replace the whole firmware, not just upgrade each individual package one at a time) I cannot recommend performing any upgrades without finding a pc, and logging in to putty to do it.

All that being said, there are web based admin apps that will let you do 02 and will provide a web based command prompt to do 01 and 10.

I wouldn’t say that. The core is moving forward as well with new features and bug fixes. Case in point triggeringItem and Member of MyGroup.