For me what is really missing is the possibility to connect to different OH installations in one dashboard. I have installed OH on my parents, my sisters, sister in law etc. and everytime I need to connect one by one to understand if there are some issue o give them same help.
Today the only way is to connect to OH one by one changing account and password
One tab for each installation, or one browser for each installation, so Mine = Chrome. Parents = Firefox, Sister’s = Edge, SIL = Opera. Or use browser’s workspace, or tab group or so many other ways to deal with this.
You can stay logged in for all of those simultaneously. No need to log out / log in all the time.
Or set up the Remote openHAB add-on to federate all the instances to one main instance. Remote openHAB - Bindings | openHAB
MQTT could be use too.
Essentially you replecate the Items from the remote OH instance in the local instance and you can then build a unified dashboard to see everything.
I use the MQTT EvenBus to do this for the instance at my dad’s house which I integrate with my main OH. I keep them separated in the semantic model:
And can get at erverything I need in the Overview tabs.
and I have widgets on my default page from both.
(No, that pin is not my location).
That’s one option.
I know the options but all all them has cons:
if I use the Remote Openhab I have to duplicate hundreds of items for each remote OH and the “hub” Openhab needs to be always available and working.
To have multiple browsers is quite confusing especially on the phone
For me it could be nice to have a single dashboard with all the OHs in the same page or create a page with items from different OH (i.e. one page with all webcam) if possible otherwise of course I remain as today…
Regards
lorenzo
Multiple tabs. There’s a PR that will set the browser’s (tab) title to the page name you’re looking at, so at least when displaying pages you can hopefully tell them apart if you named your pages differently, eg. Lorenzo's Openhab, Dad's OpenHAB, Sarah's openhab, etc.
Would like to add some of my wishes:
- Harmonize the user experience configuring Things and Items with text files and UI. Today most bindings support configuration via UI, however I’m more found of text files (for version control) and it’s not always possible to configure everything in text files, for example Things added by auto-discovery etc. I wish that there is an easy way to export all defined Things/Items to text configuration.
- Support legacy Homekit devices. I have several old Homekit compatible devices which use proprietary protocol and will never be supported by OH. Wish that those devices can be bound to OH and than exposed as HomeKit accessories to get support for both platforms.
- More bindings: Dreame Vacuum Robot for example
This is coming.
I am guessing that this should be possible too (but not currently). I can do it today with jruby. It will be made possible with .things file too. The main problem AFAIK is when you have representationproperty in thing property. Currently there’s no way to set it from .things file, which you can set when creating the thing using jruby for example. I think there’s another challenge with discovery automatically updating Thing’s configurations.
This should be fixed in the bindings. For which bindings have you experienced this?
As I also experienced problems here, my two cents:
danfoss binding (formerly known as devireg binding, it’s an inofficial binding, has to be installed manually, but there is a long thread for this binding)
and also the viessman binding (both marketplace and smarthome/j versions).
As far as I understood, both rely on secret keys which are stored in $OPENHAB_USERDATA/config/*, and as these keys are created while auto discovery, it’s maybe not so easy to implement those to *.things files.
I have a legacy Wavin binding for controlling floor heating system, it’s not official but works well for me in the past few years, discussion here:
I would love to see:
- dreame vacuum robot binding
- mammotion mower binding
2 Likes
Create and maintain reusable functions (JS) inside MainUI (instead of having them to store it in automation/js folder).
I lost track but at least I didn’t mention it explicitly, so one point is user management.
It’s already implemented (sort of), but can’t be configured other than by karaf, so
- add Users (and of course update and delete them as well)
- define roles (would be nice to have more than admin and users)
- set user ↔ role
- maybe even consider to implement support to change pam (ldap, os, database, internal) on the long run.
There is no way to do this. It’s a fundamental technical limitation of GraalVM JS. Unless and until that gets addressed upstream, this is impossible.
Hi,
long time ago I asked if there is a way to use a secret manager instead of hardcoded credentials in (thing) files. Maybe this could be done somehow, making it easier to share configuration files (via GitHub, for example) without having them to edit.
3 Likes
A PR was started but never finished. I’m not sure why.
Ok - understood.
How about being able to simply EDIT automation/js files in MainUI so that users still have the support of the helper library?
Furthermore, this is from the docs:
Creating Your Own Library
Follow these steps to create your own library (it’s called a CommonJS module):
- Create a separate folder for your library outside of
automation/js, you may also initialize a Git repository.- Run
npm initfrom your newly created folder; at least provide responses for thename,versionandmain(e.g.index.js) fields.- Create the main file of your library (
index.js) and add some exports:- Tar it up by running
npm packfrom your library’s folder.- Install it by running
npm install <path-to-library-folder>/<name>-<version>.tgzfrom theautomation/jsfolder.- After you’ve installed it with
npm, you can continue development of the library insidenode_modules.
Would be cool if this gets done automatically by user interaction (like checking a tick box in the settings „initialise reusable functions“). The name of the script file in automation/js could be predefined or could also come from a settings menu.
That isn’t impossible but there are complications that make it challenging because of the way that npm works. The next time you run an update your changes will get wiped out.
That’s why you need to create the module in the first place instead of just creating a bunch of files in a folder. Node does not make this easy.
Hmm. That’s what I proposed in the second part of my post:
Language barrier😁 My fault
Hey, in case you did miss it, there’s a GitHub issue being worked on for this:
P.S. Sorry if you already saw this mentioned above and meant something different 
2 Likes