I saw that proposal, it sounds interesting but it will not work in my case. I have several timers grouped, expiring at different times, and I only want to take an action when the last one expires. So the coding of the expire 1.0 binding is ok for me, although I recognize that boc-tothefuture proposal is interesting, but as an add-on to existing functionality.
I have been using OH 2.x (currently 2.5.9) for about a year and a half with great success. A very stable install using Docker with 300 Items and about 150 Things. I am to a point that I very comfortable using and implementing OH 2.5.x, so with the release of OH 3.0M1 I thought I would take a closer look at the direction OH is heading given my significant investment in hardware (lighting,security,thermostat,garage, gate, etc). I mainly use Insteon products and ISY hub to create links. The ISY binding is v2.4 which I load manually using the addons folder. Unfornately it is not compatible with OH 3.0M1 but is very stable, capable and compatible with 2.5.9. So I thought I would use this opportunity to learn more about MQTT, which is something I have been wanting to explore, and my use case is to federate OH3.0M1 with OH2.5.9. I used @rlkoshak MQQT 2.5 Event Bus Tutorial as a guide and was able to create a successful implementation federating 3.0M1 and 2.5.9 in Docker using Mosquito as the broker (also Docker) In doing this I found that OH3.0M1 cannot effectively use any item whose name has an “”. For example, vLoad_Level will not work but vLoadLevel works fine. Likewise Group:String PubItems_UPD does not work but Group:String PubItemsUPD does work. I should also mention that I am using DSL Rules not python, and 2.5.9 doesn’t seem to have any issue with handling “”.
Is this a known “feature” or bug that will be corrected in future releases, or am I am missing something else pertaining to MQTT and parsing itemName. As I said I am new to MQTT.
If you need MQTT just for this, don‘t invest to many time into it.
There is another solution on the road to connect two openHAB instances.
@hmerk, thanks for the quick response. At this point using MQTT to federate 3.0 and 2.5.9 is my only use case, as well as using it as an opportunity to learn more about MQTT. However given that future development of 3.0 will include other approaches to linking OH installations, I will not spend any more time on this. I think I have met my objective. Thanks again and I look forward to future OH 3.0 updates.
The OpenHab Download webpage documentation should be updated for rPi (Openhabian). Nowhere does it say OH 3.0.0M1 is NOT supported for rPi. I followed the instructions and ended up with a OH 2.5.9 install.
I understand from reading an earlier post that there is no ETA for rPi support of OH3 M1 at this time. Is this still the case?
Thanks,
Randy
That’s a strange idea I do not follow. openHABian does not support e.g. Home Assistant or to run on a Cray either but you expect that be announced ?
Given OH3 is not released but a milestone it’s expectable to get the most current stable release version, isn’t it ? BTW it was explicitly mentioned here.
Yes. We are working on it.
I believe stating Stable release version would be easier to understand. Technically Milestones are releases too 
Indeed it was announced here. Thanks.
1 Like
You can call any release a release but that isn’t helpful so for sake of nit-picking I added that “stable” to my statement.
For people who had problems with types using the InfluxDB persistence addon I’ve submitted a PR that will solve the problem in the next milestone
There is an already build version in the PR if someone wants to use
Important consideration:
If you already used the previous addon version you can still have problems. You need to start with a new database or from a copy of OH 2 database where the 3.0 persistence addon was never used.
5 Likes
Some questions/suggestions regarding the new user/auth for UI:
- I didn’t see any option to create additional users/admins, is the plan to only have a single user or will there be other users in the future?
- HABPanel seems to require auth to load panels, I presume each user would have their own panels. I propose we allow the admin to create and assign panels to certain users and lock them to only those panels.
- See the draft documentation in post three of this thread it answers this. You have to use karaf console to create extra users currently, that part is not yet done in the UI.
The Current milestone is for early adopters that don’t mind features not fully done and docs not fully written. I find it better than openHAB 2 already but I don’t use habpanel.
Hello,
i would to ask/propose a change. Previously the ui was under /paperui/index.html, but now the new ui (which is great by the way) lives at the root (/) of the server. This makes it totally impossible to put openhab behind reverse proxy. a typical use case is : having grafana and openhab on one server, and exposing these services thru apache/nginx.
Could the ui be hosted under a folder of some kind ? for instance /oh/*
Cheers,
Henri
The proper place to propose that is as a GitHub issue. Since OH3 has reached Milestone 1, I doubt it would be changed before OH4.
I think this would be the proper place.
oh okay. i suppose it will make oh unusable for many users including me then… 
i submitted the issue nontheless.
I think there are some non-breaking ways this could be implemented which would make it suitable for OH 3 at some point. But I’m not convinced it’s impossible to set up the reverse proxy to support it as it is. I’m pretty sure back when I was using that sort of reverse proxying I had the root OH Dashboard as well as Grafana behind the same proxy with Grafana at the root.
Now that LetsEncrypt supports wildcard certs now I just pay a little bit for a custom domain that supports reverse DNS and put the services higher up in the url, for example https://openhab.my.domain and https://calibre.my.domain.
2 Likes
Could you please explain your concerns in detail? My OH3 instance successfully runs behind a Traefik reverse proxy (which is, in fact, running behind an Apache2 reverse proxy). Thus, I cannot confirm this issue.
Best,
C.
thanks Christian for getting back to me. the problem is when you have multiple services on the server.
ideally i would put each service under a subpath like
/grafana
/openhab
etc.
but openhab is both located at the root of the webserver, and uses absolute paths. so i cannot relocate it under a subpath and share the same http server for grafana and oh. but maybe i missed smth ? 
That right there sounds like the issue to me. I usually try to avoid absolute paths on internal URLs.