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.
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.
Snapshots: every day
Milestones: every month
Releases: every six months
OH 4 release should be sometime before July, most likely the first half of June.
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.
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.
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.