First of all thanks a lot for all the ones that spend so much time in developing such a great solution. I switched to OH 3.0 yesterday and I still have some issues. It is difficult to google for solutions as a lot of documentation is still based on OH2. Nevertheless I hope that my experience give some feedback for other users to decide what might happen. And maybe someone has some useful hints which I appreciated a lot.
getHourOfDay seems to be deprecated - there is a post that gives some information but I have no idea how to convert. Actually I just want to have a rule running after 09.00 am
WOL and Fritzbox TR064 seem to be deprecated as they are still a OH1 development. I switched on Wifi and started devices with it, not very important but really convenient. Will all OH1 bindings be gone?
Some Z-Waves donât work anymore - in my case a Eurotronic Spirit Valve. Thanks to @rogierhofboer I was able to get 2/3 running - nevertheless one seems to be still not in the database as it is online but not identified correctly.
Samba needed to be re-adjusted to the new paths. For whatever reason I donât have write access to the addons folder anymore although the setting seems to be correct and doesnât differ from other shares in terms of permission
frontail was still pointing to OH2
Openhabian-config is still OH2
I needed to delete a lot of measurements from my influxdb as they have other types and reported errors in the log.
All linked items that were not created in the items file but created in Paper Ui were gone. A good motivation to fix that soon.
Errors because of missing PaperUi and HabminUi. I have no idea where this setting is still in my config so I could delete it.
Homebridge is only working partly. Switching items causes errors - this is a little annying as my presence detection was very accurate with iOS devices and homebridge back to openhab.
In the first place, you must differentiate openHAB vs openHABian. These are openHABian issues and the reason is probably your install method (that you donât even mention).
You likely did not use the openHABian master branch.
You are right. I did a sudo apt-get install openhab
on top of a openhabian installation running on a Raspberry taking the hassle free installation.
In terms of your additional remark: Sorry that was not my intention. I definitely did not expect a commercial support here. I thought that my introduction made that clear that I am thankful for any hints - nothing more.
Just switched back to the z-wave binding from latest snapshot (3.0.0-SNAPSHOT - Build #2005). It does not support my Eurotronics Spirit valves while the fixed binding from @rogierhofboer supports them.
Just switched back to the z-wave binding from latest snapshot (3.0.0-SNAPSHOT - Build #2005). It does not support my Eurotronics Spirit valves while the fixed binding from @rogierhofboer supports them.
OK I see the last snapshot was 4 days ago?? I thought the snapshots were produced nightly.
The definition of the spirit is not correct at the moment, but might work. The problems are : setting: limit to options is set for the whole device now, instead of per parameter. Min/max values are not exported correctly. And min/max cannot be put back to undefined.
3.0.0-SNAPSHOT - Build #2006 that was published later this afternoon CET seems to fix the zwave Eurotronics issues (cc: @rogierhofboer). #2005 definitely did not work for me.
Yes, but there is a new binding that allows federation of an OH 2.5 and OH 3 OH instance so the 2.5 instance can continue to run the 1.x bindings and send/receive commands/updates to the OH 3 instance. There is also a version in Rules using MQTT 2.5. Many of the old 1.x version bindings have been or are in the process of being migrated. But not all of them.
Which version of OH 3? A SNAPSHOT, M1 or M2? There was a problem with InfluxDB that I think was corrected after M2 so if you are not running a snapshot you might run into that problem. And if youâve ever connected to the database using a version of the add-on prior to the fix, you may need to start a new database or at least remove anything that the add-on added. I donât know the specifics but it has to do with a conflict between integer values and floating point values and the add-on choosing the wrong type sometimes.
Look at the files in /var/lib/openhab2/jsondb and /var/lib/openhab2/jsondb/backups. Are your Items in there?
Look at the files in /var/lib/openhab/jsondb and backups. Are your Items in there? Do you have any files with âeclipseâ in the name?
It is very important that we know exactly how you did the upgrade. Do you have backups? We very likely can get your Items back but we need more info.
The binding is fully usable, but unfortunately the database entry for the Eurotronic Spirit lost a lot of semantics for the configuration parameters.
Min/max value missing and/or not exported, all parameters can be limited to options or none at all.
@chris if you do find some time, please check whatâs going on with the database and/or export or point me to a repository so I can take a look. Thanks!
Sorry from my side. I see the shortcomings of my posting, and that is probably what @mstormi meant. After all, it generates a lot of feedback, hopefully one or the other takes something away and not just me.
Very helpful link - now.getHour() fixed my issue
That is very interesting. What is the name of the binding. I ran through the available ones and couldnât identify one. BTW: Searching for solutions is quite a challenge at the moment because most of the solutions still point to OH2. It will probably take some time before the knowledge is spreaded.
I was on the testing feed and installed with sudo apt-get install openhab
last weekend. To be honest I am not sure if I received M1 or M2. I am now on the snapshot release. In any case almost any items had issues with integer values and floating point - I could not identify a specific binding (manual items, Z-wave, mqtt, etc.). Switches and contacts seem to more involved them the temperatures from my valves and temp sensors.
Good to know that there is a solution. I had 98% of the items in my items file. So not a big deal for me. Will add them to my item file - that was the plan anyway.
Very nice, I have seen this binding, but I overlooked it as I was looking more for a wrapper that runs on the same server. So I have to maintain a second OH-Server, which only runs for a single binding. I should have known that before, it offers the possibility for a very smooth transition. I will let my buddies know who werenât that brave.
I am testing with OH2 & OH3 running in docker containers but they could both run on the same system since the folder paths are different (openhab2 vs openhab).
The OH2 Server appears as a bridge Thing in OH3. OH2 Items appear as channels on the bridge. you can then create OH3 Items linked to the channels. to make use of OH3 rules & UIs
