Background: Busy with checking, learning in order to migrate towards MQTTv2 and found that my MQTT v1 does not operate/come active in the latest openHAB versions ?
When I run version 2.5.7, MQTT2.x comes active but the MQTT1.x does not though the “bundles” go active. It seems to me that this might be openHAB version related as my 220 and (stripped) 230 version, runs happily both simultaneously.
Note: I prefer to migrate using (one of) latest versions as I also develop a few things of my own that need to re-engineered (here) as Eclipse has left the Smarthome building.
Ok, Thx… this save me further investigation. I was already pulling my teeth out.
This brings me to a new adventurous approach.
(try to) Update my Qnap/nas OH220 to version 2.3.x (in order to run MQTTv1**+v2**), migrate my MQTTv1 and then move-on to 2.5.x.
New challenge is where to get a proper distribution that I can use to update my Qnap … ?
I can (re)construct things but I prefer to have a clean update version.
In case someone know where I can download a (full) OH2.3.x zip thart can be installed offline openHAB offline… I would appreciate it very much.
TIA
To answer myself… old/releases can be found: JFrog
Update 21jul22: bintray/jfrog only support/keep the latest openHAB 2.5.x active. Luckily one can find specific artifacts/build for earlier releases on the maven repo.
FWIW, I’ve installed 2.4.0 on my QNAP as pre-step to migrate my MQTT1.x items to MQTT2.x. In the end “this” version upgrade turned out to be fairly easy operation which consists primarily of replacing the …/distribution/runtime contents and clearing the (old/version) tmp & cache. Next step is inventory my mqtt and migrate these one-by-one to the mqtt-bridged channels.
In addition I needed to fixemy environment in order (re)continue my MaVeN based development. For this, I installed the archived “smarthome” repo’s on my local webserver.
Aside, I was also forced to fix & dimension my “avmfritz items” as in this release, IUoM (in Incorporated Unit of Measurement) went active by which collected “measurement units” such as “Energy” are standardized.
The constant removal of backward compatibilty is going to be the end of this project.
MQTT upgrade from m1 to 2 is unnecesarily conmplex and poorly documented.
LightwaveRF support simply does not exist in OH3
and so on.
Seems every time I get things working nicely, a new change trolls in that breaks something that worked before & the migration to the replacement is some sort of dark art.
yeah, indeed things become complex when they are running forward.
This is one of the reasons, I want to compile things myself to prevent unintended collisions.
(I still can compile versions before 2.5 in offline mode, as I’ve kept and snapshotted my .m2 MaVeN repositories).
However, as moon meet the sun, I just completed my openHAB native release 2.4.0 to install on my 32-bit QNAP. For this I modified the original QNAP/qpkg install (originally 2.2.0) to the 2.4.0-qpkg which allows me to install this as openHAB240 in parallel to the existing openHAB one (that’s running).
Note: normally one will use containers or docker which is unfortunately not possible on my 32bit/qnap.
havin two openHAB system on the same file/sysem is practixal to migrate mqtt on the same machine without being bugged due to (incompatability) failures. My next step is to run a second (of 3rd) instance of openHAB 2.5.12 to migrate my 2.4.0 instances.
The biggest challenge, remains to migrate mqtt on item-types to channel-type on things.
Ik still feel the item’ized approach for mqtt.v1 was way more transparent then the channel on things approach.
