I realize it’s a lot to expect support for 50-year-old “technology” but I’ve been using it for almost that long. The CM15/Mochad binding been working fine with OH 4.3.3 and all of my X10 devices.
I have installed OH 5 on a test Raspberry Pi 4 using an initial.zip file. Almost everything is working as expected (some tweaking was required… SMB, regional settings, etc.) except for the X10 stuff.
It was quite involved getting X10 devices to work on the OH 4 (lots of compiler errors, etc.). What would I need to transfer from my OH4 box to the OH5 box to get the X10 stuff working? I do have a file called org.openhab.binding.x10-3.3.0-SNAPSHOT.jar in /srv/openhab-addons. Should this and the mochad executable be enough? I think I can handle making the mochad autorun.
I do see my X10 items at openhabian:8080/settings but I see no things (I do have an x10.things file as well as an x10.items file).
I’m reluctant upgrading the OH4 box to OH 5 (after updating Java) for fear that it will break X10. IF I do this and create a mirrored SD, is likely that I could plug the mirrored SD into the new test Raspberry Pi 4 box and expect it to boot and work properly?
It is extremely unlikely an add-on built for OH 3 will work in OH 5. It’s really unlikely an add-on for OH 4.2 to work in 4.3 frankly.
There have been a ton of changes in how add-ons communicate with core over that time.
The fact that a 3.3 add-on worked on 4.3 is frankly a miracle.
But I do note that there is an official x10 cm11a building that is still supported in OH 5. But if that binding won’t work, you will almost certainly need to modify your existing add-on and rebuild it to work with OH 5.
But I do note that there is an official x10 cm11a building that is still supported in OH 5
Thanks (as usual) for the helpful reply.
Unfortunately I need a binding for the cm15a which uses a USB connection. The cm11a used a serial port. Although I have the source code for Mochad which provides the bridge between OH and the CM15a (which I suspect won’t need modifying), I do not have the expertise nor desire to rewrite a binding.
My choice then seems to be to stick with OH4 (not desirable) or bite some bullets and replace a dozen dimmer outlets and switch outlets.
I’ve also been using TP-Link HS220s and KP405s but being 2.4 Ghz they have an annoying tendency of going off-line even though RSSI is strong and the microwave isn’t on. Sometimes they fix themselves. Sometimes a reboot suffices - annoying. Sometimes a reset - VERY annoying.
You can keep an instance of OH 4 around to run this add-on. Then set up OH 5 on another machine (or even on the same machine if you are careful with the ports) and use either the Remote openHAB add-on or the MQTT EventBus to link the two instance of OH together. These will expose the Items on the OH 4 instance as Channels you can link to Items on the OH 5 instance and keep them in sync (e.g. sending a command to the Item on the OH 5 instance will show up as a command to that same named Item on the OH 5 instance and updates work the same way, both directions).
I’m sure there are Python, Perl, or JS projects on GitHub that interface with this device and exposes it as MQTT.
Either of these will certainly be less work and cheaper than replacing everything.
You wouldn’t need to necessarily rewrite the binding, just look at the latest skeleton and developer docs to see what’s changed and update those parts. You are not starting from scratch even on the OH side of things. Just adjusting for the various breaking changes that have occurred over the years. This too is likely to be less work than replacing everything.
I’ll have to chew on this a bit… I have zero experience with the Remote openHAB add-on. Ditto for the MQTT EventBus. Even modifying the binding, for me, may be more than I care to tackle.
Each of the alternatives will be a lot of work (for me… maybe not for someone more knowledgeable).
The Remote openHAB biding couldn’t be simpler. If you can use any binding in openHAB, you can use the Remote openHAB binding. If you can’t handle that you probably shouldn’t be considering the upgrade. It is one of the easiest add-ons to configure to use in all of OH.
The steps would be as follows:
Install OH 5 on some other machine with your current config.
Install the Remote openHAB binding from the add-on store like any other binding on the OH 5 machine
Go to Settings → Things → + → Remote openHAB. It will scan the network for your other openHAB instance. It should find it and all you need to do is accept it. If not you can manually create the Thing. If you create it manually you really only need to set the IP address property to the IP address of your OH 4 instance.
Once the Thing is created you’ll see in the inbox a new Remote Thing was discovered. That has one Channel for each of the Items defined on your OH 4 instance. Simply link those Channels to the X10 Items in the OH 5 instance instead of linking those Items to the now non-existent X10 binding and Things.
Anything you do to the Item on OH 4 will be done to the linked Item on OH 5. Anything you do to the Item on OH 5 will be done to the Item on OH 4. It will be as if everything in OH 4 instance were there in the OH 5 instance. You can remove any rules, add-ons and Items that are not related to X10 from the OH 4 instance. It’s sole purpose is to give you access to X10 now.
This way you can continue to use the old X10 binding on OH 4 without changes but still access those devices from OH 5.
This sounds promising. Would it be wise for me to change the hostname for one of the systems, e.g. openhabian2 and change the IP address of the OH5 system to e.g. 192.168.1.120? I look at the docs for the Remote openHAB binding before asking any more questions.
Also, what is the recommended way to lock the OH4 box to prevent inadvertent upgrading?
I do still plan to try the old binding. Maybe we’ll be surprised.
Yes, these are still computers and each computer must be uniquely identifie on your network. The IP address is more important than the hostname.
sudo apt-mark hold openhab.
That will prevent openHAB from being upgraded beyond what’s currently installed but everything else on the system can upgrade.
I recommend against upgrading other stuff too though. At some point, maybe new year, maybe decades from now, something outside of openHAB will change that breaks openHAB 4. Minimizing the changes lowers the chances of that happening sooner rather than later.
So long as this machine is not on the Internet it’s reasonably safe. Obviously it’s better to have everything up to date but you need to balance the risk of attack against the risk of something changing that breaks your OH 4 install.
Thanks, Greg. I’ve looked at Heyu in the past and I think I’ll pursue the current path I’m on.
I’ve gotten the Remote openHAB binding working (sort of). The new OH5 box is crashing a lot, possibly due to several things I did as root. In the next few days I’ll re-flash a card with OH5 and start over.
I’ll try to avoid doing things outside of the OH GUI and openhabian-config. Maybe I’ll have better success.
I also think the day is not too far in the future that I finally toss all of the X10 stuff even though it all still works well with Active Home Pro on Windows 11… better/easier in some respects than OH. I use AHP for all the timers for the X10 stuff.
BTW, I got quite a deal on the most recent 4G Pi 4 from Vilros… a clear 3x3.25x2” box that contains a fan and power supply, a micro SD/USB-A adapter, an HDMI adapter cable and a 64GB SD card for USD 39.
I was making some progress but ran into issues so I started from scratch. I put an initial.zip from the OH4 system but nothing seemed to “take” (locales,things, model, etc.).
I then had the clever idea to import a backup config from my OH4 system (openhab-backup-25_08_12-07_44_56.zip). This was a big mistake. It made the OH5 box unusable.
Apparently it imported too much OH4-specific stuff.
I’m re-flashing now. What’s the proper way to import the OH4 data? I assume I’ll have to delete bindings, things and items relating to X10.
It looks as if \var\lib\openhab\jsondb contains most of the data I would need (things,items, model, rules). Should I just copy this directory from OH4 to OH5? Are there any file I should NOT transfer?
Thanks again for your patience.
<BTW, the old X10 binding did not work, as you predicted.)
Without details about the specific steps you took and logs it’s hard to say exactly where it went wrong. Therefore it’s hard to give concrete advice.
In general, the smoothest experience would be to initially install OH 4.3, restore the backup and then upgrade.
It is possible to restore a 4.3 backup to OH 5 but there are a few things you have to watch out for. The backup cannot be a full backup (i.e. it includes userdata/tmp and userdata/cache). If it is a full backup you need to clear the cache before you start OH 5 after the upgrade. (sudo openhab-cli clean-cache).
Failure to do this will cause OH 5 to try to run with 4.x bundles and that won’t work. It needs to download and install the 5.0 version of the bundles to run with.
It is not unusual for the first boot after an upgrade to generate a bunch of errors. Usually you should wait for OH to start up and settle down a bit and then restart it. That gives it a chance to finish downloading and installing all the bundles it needs. This second boot is usually clean.
Note there are a few minor breaking changes in OH 5 which might cause some new errors or warnings you’ll have to deal with. Pay attention to the logs and the release announcement breaking changes section.
I used Backup/Restore option Option 50 which doesn’t include tmp or cache files, but it did behave as if there were OH4 bundles on the OH5 nonetheless.
If I choose to install OH 4.3 first on the new box, do I upgrade to Java 21 before upgrading to OH5, or will the upgrade do this for me?
I’ve lost track of the number brick walls I’ve encountered trying to create a bootable SD for OH 4.3.
I was using Raspberry Pi Imager 1.9.6 but a Google search showed there were “issues” similar to what I encountered so, as was suggested, I installed 1.9.4. This at least allowed be to burn the SD with OH 4.3.6, but it won’t boot… solid green activity light for a short while, then 4 flashes, 4 flashes etc. indicating unbootable.
No activity on the Ethernet LEDs at all.
If I follow the instructions for OH 5.0.0 at ‘https://www.openhab.org/download’ I end up with a bootable OH5 (using one of the same SD cards that did not work for OH 4).
I am able to boot into OH 4 using a backup SD made on the OH 4 box but I think this is not a good approach for a lot of reasons.
I also tried Etcher but it seems to be needing a bootable ISO image which I haven’t been able to find.
