Thanks @4u2fast, By now, althought not 100% confirmed, it seems that this can be the origin of the problem, you can follow the Github issue that was previously mentioned in that thread.
Is the next milestone release planned for early next month @Kai? It would be nice to know for everyone working on fixes or waiting for them to be part of a milestone release. 
1 Like
No date set yet. Just tell me once you think enough fixes have piled up .
What might make sense is to do the 2.5.10 patch release this weekend (Oct 25) and the 3.0.0.M2 the week after (Nov 1) - that will keep me busy. Wdyt?
1 Like
Sounds good to me because I think a lot will be fixed by that time!
Heads up for everyone having trouble with rrd4j error messages when restoring values, we should soon have a fix in place with https://github.com/openhab/openhab-addons/pull/8815.
1 Like
What’s the approved successor of expire binding? Just noticed my countdown timers were no longer working and finally figured out it was because of expire being 1.0.
It will be replaced with equivalent functionality in openhab-core:
2 Likes
Thank you. I will avoid recoding everything and move back to OH2.5 for the moment first in that case.
I do support a better implementation of timers raised by boc-tothefuture though. Perhaps the OH1 way of creating a dummy timer item and separate rule for a simple functionality of countdown timer is a little bit outdated.
He didn’t. What you linked to is a statement from him before I asked the question. My question requires only a yes/no answer and I would assume that is possible even when being busy with other projects, if there is any will in resolving the situation.
Do you happen to have a link to that proposal? Thanks 
It’s right at the end of the github issue for the expire binding. Since the expire binding is used as a middleman anyway, might as well move it into the rules engine entirely while it’s being refactored.
I would kindly ask in advance:
What´s the best way to upgrade from 2.5 to 3?
Actually I would like to have a fresh restart and rebuild everything from scratch (I saw some new things like “Equipment”, “Location”, “Points” and stuff).
My problem is: I originally used a OH 2.5 Image which I installed on my RasPi. After that and after some time I set up a homematic CCU Server, MQTT broker and a Phoscon Zigbee Gateway on the same RasPi. I really don´t want to do all those steps again…
So, is there a way to uninstall OH (remember, it´s all beased on the OH 2.5 image!) and then do a fresh and clean installation of OH3 on my system without touching my running servers/processes?
Thank you!
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 