Mochad (X10/CM15) Binding for OH 5

Setup, Configuration and Use Migration
21

This gives me


E: Invalid operation uninstall

I then did

openhabian@openhabian:~ $ sudo systemctl stop openhab.service
openhabian@openhabian:~ $ sudo apt remove openhab
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  openhab openhab-addons
0 upgraded, 0 newly installed, 2 to remove and 93 not upgraded.
After this operation, 712 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
openhabian@openhabian:~ $

This seemed wrong since only 2 items would be removed.

So I tried:

sudo apt autoremove openhab

and it should identical results so I said yes and got

openhabian@openhabian:~ $ sudo apt autoremove openhab
[sudo] password for openhabian:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  openhab openhab-addons
0 upgraded, 0 newly installed, 2 to remove and 93 not upgraded.
After this operation, 712 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 98926 files and directories currently installed.)
Removing openhab-addons (5.0.0-1) ...
Removing ...
dpkg: warning: while removing openhab, unable to remove directory '/var/lib/openhab/persistence': Device or resource busy - directory may be a mount point?
Updating FireMotD available updates count ...
openhabian@openhabian:~ $

The dpkg: warning didn’t concern me. I probably should have stopped OH.

Before proceeding I decided to do a raw copy backup. This was disaster. i got hundreds of lines similar to:

JBD2: Invalid checksum recovering data block 548603 in log
JBD2: Invalid checksum recovering data block 1572865 in log
JBD2: Invalid checksum recovering data block 524667 in log
JBD2: Invalid checksum recovering data block 1 in log

At the end of the backup it said everything was clean so I proceeded with upgrade (via sudo openhabian-config > 02 | Upgrade System). This didn’t work as I wasn’t able to access the new system at the IP address I assigned to it nor the via hostname I assigned. ifconfig looks OK.

openhabian-config runs and appears to act normally and reports correct IP and terminal shows the following:

##        Ip = 192.168.1.120
##   Release = Debian GNU/Linux 12 (bookworm)
##    Kernel = Linux 6.12.25+rpt-rpi-v8
##  Platform = BCM43455 37.4MHz Raspberry Pi 3+-0190
##    Uptime = 0 day(s). 00:04:22
## CPU Usage = 2.15% avg over 4 cpu(s) ( core(s) x - socket(s))
##  CPU Load = 1m: 0.00, 5m: 0.01, 15m: 0.00
##    Memory = Free: 3.39GB (90%), Used: 0.41GB (10%), Total: 3.75GB
##      Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
##      Root = Free: 22.19GB (81%), Used: 5.03GB (19%), Total: 28.70GB
##   Updates = 0 apt updates available.
##  Sessions = 1 session(s)
## Processes = 160 running processes of 4194304 maximum processes

This has been a muilt-day project and I’ve had enough for today. I’ve got some new SC cards arriving tomorrow (probably late). Next I’ll try a fresh install as you outlined on 10 August.

You said “The backup cannot be a full backup”. I plan to use a configuration backup but will be sure sudo systemctl stop openhab.service before restoring and clear the cache before restarting.

I’ll also need to remember to remove the CM15(X10) binding from the new system if it’s still there as well as the X10 things and items and disable the non-X10 rules from the old system. I wouldn’t want the same rules running on both machines.

22

Should be sudo apt remove openhab, not uninstall.

I was going from memory and remembered wrong.

That’s right, one for openHAB itself and one for the add-ons package.

Yes, that’s why there was the error. But that does mean that apt didn’t finish clearing everything out. Hopefully it cleared out enough.

I can’t guess as to what went wrong except to say that that option is the same as running sudo apt upgrade on the command line which will update all the installed packages. OH wasn’t installed anymore at that point so that wasn’t what caused a problem. Something messed with the networking I guess during the upgrade. Usually that’s a pretty safe operation though. Without more info it will remain a mystery.

23

This is really becoming a pain.

I installed OH5 on the new machine, went through the initial setup then tried to import the OH4 config file. Failed with:

 ───────────────────────────┤ Import configuration ├───────────────────────────┐
│ Enter the full filename or URL to retrieve the configuration file from.      │
│
│
│ /home/openhab-backup-25_08_12-07_44_56______________________________________│
                     <Ok>                         <Cancel>                    │
_______________________________________________________________________________

 ┌──────────────────────────────┤ Restore failed ├──────────────────────────────┐
 │                                                                              │
 │ Restoration of selected openHAB configuration failed.                        │
 │                                                                              │
 │                                    <Ok>                                      │
 │                                                                              │
 └──────────────────────────────────────────────────────────────────────────────┘

I then made a config backup on NEW OH5 and looked at the directory containing it:

openhabian@openhabian2:/var/lib/openhab/backups $ ls -lt 
 
-rw-r--r-- 1 root openhab 583575124 Aug 15 13:29 openhab-backup-25_08_15-13_29_01.zip 
-rw-r--r-- 1 root openhab    476432 Aug 15 13:23 openhab-backup-25_08_12-07_44_56.zip

583,575,124 vs 476,432. Seems there is something seriously wrong with my understanding.This shouldn’t be so difficult.

Looks like I’ll have to manually re-create everything unless the are some files I could copy from OH4 /srv/openhab-userdata/jsondb (which ones, the unstarred ones, or would this cause problems):

*  4096 Aug 15 04:58 backup
* 20835 Aug 15 04:58 users.json
 175088 Aug 14 23:08 org.openhab.core.thing.Thing.json
  12743 Aug 14 17:24 org.openhab.core.config.discovery.DiscoveryResult.json
    302 Aug  4 17:35 automation_rules_disabled.json
  15239 Aug  4 17:35 automation_rules.json
   9534 Aug  4 17:35 org.openhab.core.items.Item.json
*     2 Aug  4 17:35 org.openhab.core.items.Metadata.json
  11374 Aug  4 17:35 org.openhab.core.thing.link.ItemChannelLink.json
*   620 Aug  4 17:35 org.openhab.core.tools.UpgradeTool
*     2 Aug  4 17:35 org.openhab.jsonaddonservice.json
*     2 Aug  4 17:35 org.openhab.marketplace.json
*   267 Aug  4 17:35 thing_status_storage.json
  14337 Aug  4 17:35 uicomponents_ui_page.json
24

I doubt that was the correct path to the backup file.

Maybe /home/openhabian/openhab-backup-25_08_12-07_44_56 .zip? The backup failed because you didn’t give it the full path to the file. There was not file for it to load therefore.

I don’t really know if that’s the correct path because I don’t know where/how you copied the backup to the machine. So I can’t help with that.

Indeed, by default it will backup to /var/lib/openhab/backups but you did that on the OH 4 machine. Then you copied that file from the OH 4 machine to this new what will become OH 5 machine. And you put that backup file somewhere. You need to tell the restore where you put that file.

25

I first put the OH4 backup .zip in /home and specified the path when I tried to restore:

/home/openhab-backup-25_08_12-07_44_56.zip

When this didn’t work, I did a backup from the OH5 box to see where it went. It went to

 /var/lib/openhab/backups/

That’s when I noticed to be HUGE filesize difference (0.5 GB vs 0.00047 GB for the OH4 backup). OH5 seems to have created a full backup as opposed to a config backup. I’m assuming it it likewise assuming to restore a full backup as opposed to a config backup which is why it failed to import.

Since /var/lib/openhab/backups/ is where OH5 put its own “config” backup, that’s where I put the OH4 backup and specified the complete path when trying to import it.

Since the config backup/restore seems to be broken in OH5 I asked at the end of my previous message the odds of copying individual .json files from OH4 to OH5. I doubt that would work so I’m going re-try your earlier suggestion… install OH4 on new machine, import config then upgrade.

I’ll let you know how it goes.

26

I’ve decided to abandon hopes of importing my OH4 setup into OH5. I’m starting with a fresh OH5 and will re-create everything, copying and pasting where possible (rules, charts etc textual definitions)

Shortly after I began the process I tried to make a raw copy backup and setup mirroring. I could not successfully create a backup after trying several SD cards and SD adapters.

This morning I took the backup SD card from the OH4 machine, put it in the OH5 machine and successfully made a backup. Then put the OH5 card back in and successfully made a backup!

No idea what’s going on here. I was starting to suspect the new Pi until i got these results.

BTW, the Remote binding is working for the X10 stuff.

27

It turned out that many of my problems were caused by a defective Raspberry Pi in the new OH5 box. After being on for a while it seemed to act flaky. Frontail continued to function but other pages would freeze or behave strangely.

The enclosure has a fan but there were no heat sinks. I bought a new Pi 4, followed the path of OH4, import then upgrade and things are working fairly well (so far).

I’m not sure yet, but it seems I might want to set up a second cloud account to avoid collisions and or conflicts between the boxes.

28

It turned out that many of my problems were caused by a defective Raspberry Pi in the new OH5 box. After being on for a while it seemed to act flaky. Frontail continued to function but other pages would freeze or behave strangely.

The enclosure has a fan but there were no heat sinks. I bought a new Pi 4, followed the path of OH4, import then upgrade and things are working fairly well.

Do you recommend I create a separate cloud account for the OH5 box to avoid conflicts/collisions or would this break the remote functionality needed to support the OH4-OH5 connection?

29

If these two instances are on the same LAN, just keep the one account. OH 5 will connect to OH 4 using the Remote openHAB binding and OH 4 will only really be accessed through OH 5. It’s only job will be to expose the X10 stuff to OH 5. All the rules, UI pages and everything else exists on OH 5.