In general, is the current OH4 snapshot fairly stable? As in - will it run the Zigbee Binding, Wiz Light binding, and… maybe Alexa/Echo binding?
If so, I can simply switch to 4.0 for my current usage and then I CAN test the Reolink IP Camera stuff.
As you can see, I’m not using a TON of bindings. YET!
Snapshots are in general unstable. The current snapshot is literally everything that has been changed in the main branch of OH nine hours ago and before (as of this writing). A new snapshot is created daily. On a day to day basis you never know what will break, if anything. This is always generally true but event more so during the transition between major versions (e.g. 3.4 to 4.0).
Unless you are willing to spend some time debugging problems as they arise I do not recommend the snapshots. Instead use the milestones. These are released monthly and only released when there are no known major regressions. But even here there can be major breaking changes between milestones. for example, between the last and the current milestone, the way to configure a SCRIPT transform changed.
Since they won’t break each other (other than JAVA version)…
I’m going to jump to 4.x and see what happens. So…
Download and “install” 4.x, update to JAVA 17, and simply copy my user folder from 3.4.2 to 4.0?
It’s not that simple. There are lots and lots of breaking changes in 4 and if you simply copy your config non of the upgrade steps will occur. And even then there are breaking changes that require manual intervention. You can try it and when stuff breaks review the 4.0 snapshot and milestone discussion threads for how to fix them one by one.
Also, when you install Java 17 it’s going to set itself as the default Java over Java 11 so you’ll have to figure out how to switch those back and forth too.
At the moment, I am only using Sonoff Zigbee door switches, temp/humidity sensors, switched power outlets along with a handful of Wiz WiFi LED bulbs. (And the “scheduler”). Essentially, just watching doors and temp/humidity, and switching the plugs/LED bulbs on schedule. Nothing more.
So if those basic functions work (for now) I’m gold.
How long does it normally take for a new version such as 4 to actually be released? Weeks now? Months? Years? (Ha ha).
It usually not the bindings and it’s usually not what you are doing with them that cause breaking changes. For one example, if you installed anything from the marketplace at any time, there’s a file you need to delete to cause it to be regenerated. There are changes that need to be made in rules and widgets. Configuring SCRIPT transformations have changed, particularly on profiles.
OH 4 release should be sometime before July, most likely the first half of June.
Actually, nothing keeping me from moving 3.4.2 to the home where OH will be running anyway and then do development with 4 on my laptop. Then they are isolated and what 4 breaks doesn’t matter. 
4.0 M2 running.
3.4.2 still usable.
All I have to do to swap is change my Java_Home variable.
I can’t “move” my current running items (well, zigbee) since that will rellink them elsewhere, but that’s ok. I can run 3.4.2 with my current stuff and when I want to work on camera stuff, I can swap over to 4.0 and then I’ll be ready when 4.0 releases.
Don’t know what device you use for your server, but using a VM, you could use both at the same time, just have zigbee on your 3.4.2 and do the camera stuff on 4.0.
Or use different servers completely, that’s what I do.
I run openHAB 3.4.x productive on my Intel NUC i3 and have a near productive 4.0 [latest SNAPSHOT] on another Intel NUC i5 plus some 4.0 on independent VM’s on my big server, basically for widget and binding development.
While having my zwave stuff and other minor limited hardwar bound only to my 3.4.x server, most of the rest is configured on serveral installations simultanously.
Once I completely move over to 4.0 productive, I have just to move my zwave stick to the new NUC and discover the new things. Then I am going to import my predefined items from a textfile into MainUI.
Up and running in under an hour I guess…
On my iPhone/iPad, I have configured my 3.4.x server [same in myopenHAB] and use weblinks for the other installations.
Just my 2cents how to use different installations/versions at the same time to prepare a smooth upgrade.
Only limitation would be loosing persisted data, as I am also redefining Item names for openHAB 4.0 following a strict naming scheme.
The snapshots are usable. If you can easily switch back and forth (e.g. if you’re using docker), then I’d say go for snapshot. Yes there may be things you’d need to fix here and there right after the upgrade, but once you’re up and running, I find snapshots perfectly fine to use. I keep an eye on new commits and if anything seems interesting or a serious bug fix, I’d update my snapshot. Updating with docker is super duper easy.
I am currently still using the smarthome/j amazon echo binding. I don’t think the official binding supports things like TTS or some others, I haven’t paid too much attention to the difference, but last I know, the official version is still lagging behind on features.
I use zigbee2mqtt so my zigbee stuff is totally unaffected.
Windows 10.
I’m actually going to move my 3.4.2 to a more permanent home while I do the other work.
I was going to import, but I’m cleaning up naming and other structure now that I understand things better when I move to 4.
Ok, ever thought of using the „Windows Subsystem for Linux“
You can use it for exactly what I described.
Or use the VMWare Player to have virtual machines on your Windows host…
Just to name some options….
I’m getting so old…
VM’s. The person who manages our local VM farm and used to manage the global vm farm network didn’t think about that.
Sigh…
One approach you could use if on separate machines/virtual machines like @hmerk recommends is leaving the hardware plugged into the old OH and use the Remote OH binding to mirror those Items in the new OH. Then you can migrate your rules and everything else over to OH 4 and only move the hardware over as the last step, safe in the knowledge that all the Items and widgets and rules will work.
The official Amazon Echo Control binding does support TTS.
You’d still have to put one instance on different ports though, right? And can you do hardware passthrough on WSL yet? Last time I messed with it I couldn’t, but that was a long time ago.
I like the idea of WSL as an option because it gives a more typical install (which helps us help you) while still running on Windows.
VirtualBox is free for personal use and quite capable. There’s also VMWare Workstation and Hyper-V (or what ever Microsoft calls their type 2 hypervisor these days). I think there’s even a version of qemu that runs on Windows but I recommend sticking with either of the first two.
You don’t need a type one hypervisor with fail over, migration, and all that jazz (the kind of stuff you’d find in a VM farm). You just need to define a slice of your machine to run some other OS and have access to it’s console.
One thing I did without thinking… Now I have to fix 3.4.2.
I wanted to see what worked. So, while running 4.0.0 M2, I… used the Zigbee binding and grabbed my coordinator. Oh, crap. Zigbee can’t be multi-homed. 3.4.2, of course, lost it.
So, back to 3.4.2. Re-bind the coordinator to 3.4.2. The coordinator is happy. Everything that WAS bound to it isn’t any more. Sigh…
Whether two hardware boxes, or a VM, I am going to go that way so I don’t interfere. And make SURE I don’t try to grab the same hardware in both instances.
I’m surprised you were even allowed to do that. On Linux at least a lock is created so that the first instance gets exclusive access to the hardware and the second instance is locked out.
Way ta go, Bill Gates!
I had shut down Karaf though before I did it. So there may not have been a lock in existence. But I no more than clicked the button to add the coordinator and my brain instantly told me that was NOT a very bright thing to do. 50ms too late.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.