How to replace a broken device in openHAB?

Add-ons Bindings
1

I had to replace one of my Shelly 2.5 with a new Shelly Plus 2PM. How do I replace the old thing with the new thing in OH3 without having to setup all derived items and equipment from scratch?

I tried the following:

  1. Add the new device as a thing
  2. Copy the code from the new device:
  3. Paste the code into the old item

Unfortunately, when I tried to save the new code, I got an error: Changing the thing UID is not supported

Arc-2023-02-17 at 16.03.55@2x
Arc-2023-02-17 at 16.03.55@2x760Ă—480 23.2 KB

Is there any way of achieving what I want to do?

2
  1. Take note of the old Thing’s UID. Delete the old Thing. Do not unlink the Items. Do not remove the Items.
  2. Discover the new Thing. Before accepting it from the Inbox, change the Thing’s ID to match the old one’s ID. This is the only time you can change the Thing’s ID.

If the new Thing has the same UID, the old Links and Items will just work.

Since you already added the new device as a Thing, you probably should, as step 0, remove the new Thing first.

2 Likes
3

Okay, thanks. I’m glad that this is possible.

I did the following:

  1. I removed the new device thing (that I previously created)
  2. I noted the device uid of the old device thing
  3. I deleted the old device thing
  4. I rediscovered the new device and added it as thing with custom ID, using the old device ID as custom ID.
  5. It then asked me to provide a label and I accepted whatever it suggested as default.

This gave me an error and the new thing was not created. The error message in the bottom left corner disappeared before I could read it but I found this in the openhab.log file:

2023-02-17 16:23:53.418 [ERROR] [ore.internal.discovery.InboxResource] - Thing shelly:shellyplus2pm-relay:c049ef883550 unable to be approved: New Thing ID shelly:shelly25-relay:c4d7a1 must not contain multiple segments

If I understand this correctly, something has changed regarding the requirements for a valid UID so that I am not able to create a new thing with the old thing uid. Is that correct? Any way to work around this?

4

That Thing ID doesn’t look wrong to me. But it might be that you only should copy over the last part of the ID from the old to the new, not the whole thing.

I don’t have any things to experiment with and it’s been a long time since I’ve done this.

5

You mean what comes after the last colon?

Edit: I tried that and that will get the thing approved, but it will not have the same uid and hence it will not inherit the exisiting items from the old thing…

Edit2: I found the code that produces the error message here

According to this, a thingID may not contain an AbstractUID.SEPARATOR.

I found that the separator is defined as a colon here (that is for OH4.0 while I am on 3.4, but I assume that this has not changed).

So, it looks like it is not possible to specify the entire UID as a custom UID, only the last part, while whatever comes before the colon cannot be changed. If this is correct, it looks like we cannot create a thing with the exact UID of a previous thing.

6

Is there any way of reverting this deletion?

Before I deleted the thing, the rules operating it still worked (even with the new device, because I gave the new device the same IP), but when I now try to recreate the thing in order to get those rules working again, it doesn’t work.

I manually created a thing in the shelly binding, same UID, same everything, but it does not inherit its previous items (except for signal strength). So the rules still don’t work.

How do I revert the deletion so that the rules work again?

Edit: It looks like the problem is that when I manually recreate the thing, the channels are not recreated because the device is no longer online (for some reason, it picks up the signal strength channel from the new device, probably because it is associated to the IP).

Is there any way of restoring the other channels?

7

Oh, there are ways.

  1. Stop OH.
  2. Navigate to /var/lib/openhab/jsondb
  3. Open org.openhab.core.thing.Thing.json
  4. Find the entry for your new Thing
  5. Replace the UID with your old Thing’s UID; notice that the ID will be a part of the ID for all the Channels as well as the Thing itself
  6. Start OH and watch for errors.

Assuming there haven’t been too many changes/restarts since you deleted the Thing, look in /var/lib/openhab/jsondb/backup. Every time you make a change a backup is saved from before the change. Restore the org.openhab.core.thing.Thing.json to the latest backup version there and work backwards until you are back to where you started or run out of backups.

Again, you’ll need to stop OH prior to restoring the backup.

If it’s autodiscovered, it’s the job of the binding to detect and create the Channels.

1 Like
8

That path doesn’t exist on my instance:

Arc-2023-02-17 at 18.42.10@2x
Arc-2023-02-17 at 18.42.10@2x1272Ă—848 54.3 KB

Is it because I’m running OH in a docker container?

Edit: I found the file in /openhab/userdata/jsondb/and replaced the new uid string with the old uid string everywhere it occurred and it seems to work now.

Thank you for your assistance!

9

Yes. Inside the container it’s /openhab/userdata/jsondb.

Outside the container it’s what ever folder you have mounted to /openhab/userdata.

10

Thanks!

I had to revisit this topic because another shelly device died and had to be replaced.

I tried to follow the same procedure as last time but this time, the resulting thing (i.e. after I changed the uid of the new thing back to the old uid in org.openhab.core.thing.Thing.json) is somehow locked:

Arc-2023-07-20 at 19.42.06@2x
Arc-2023-07-20 at 19.42.06@2x1458Ă—108 11.2 KB

This didn’t happen the last time. How can I fix this?

11

It is a bad idea to change the uid of the shelly devices, as their mac address is part of it and used for discovery. What I would do, let openHAB discover the new shelly, add it with default uid and after this, change the links of the items refering to the old thing. Doing this by unlinking all items from old thing without deleting them and then going to channels of new thing linking them to existing items.
This does not take very long in the UI.

1 Like
12

That’s quite a number of links to change (I think about 20) but given the trouble that the shortcut entailed, I guess it’s the best way.

So, just to summarize what the different options are when a broken device needs to be replaced:

  1. Discover the new device and create all items from scratch. Then replace the old items with the new items in all rules and wherever else they show up. This is clearly a very laborious and error-prone way of doing it (and what I wanted to avoid when starting this topic.)
  2. Take note of the device uid of the old thing and delete it (but not the items linked to it), then discover the new device thing, then edit the org.openhab.core.thing.Thing.json according to the above instructions to give the old uid to the new device.
  3. Let OH discover the new device and then change the old device’s items so that they are linked to the new item. Since the items remain “the same”, nothing else needs to be changed. This is a kind of compromise between #1 and #2 in that there is still quite some manual work involved, but not as much as in #1.

So it is #3 that we want and for anyone (including my future self) who might be wondering what exactly needs to be done in #3: You go to the Channel tab of the new thing and link all relevant channels to the corresponding item (which are currently also linked to the old thing). Then switch to the old thing and unlink all channels. Then delete (or disable) the thing. (Maybe it can be deleted without unlinking, but just to be safe.)

With all that more or less solved, I would still like to understand why the item became locked. After all, the first time I did it some months ago, it didn’t get locked. In fact, I am still unable to delete the old item mentioned above, even after I moved all the items to the new thing, so I just disabled it. But how do I delete it?

13

1 isn’t a big deal if you delete the old items first and create the new items with the same names. Then you don’t need to update anything else. It’s pretty fast to create them all at once using add equipment from thing.

For 2, when you create/discover the Thing, you can override the randomly generated UID right then and there to make it match the old one. There’s no need to edit the JSONDB files. This is probably the last amount of work over all as the Items and Links remain unchanged.

3 is probably the most work over all.

14

Been there tried that (it did not work):

So the item name is the only thing that counts in rules etc?

15

It’s exceptionally rare that the first part of the Thing UID changes. This is the first time I’ve seen that happen.

correct. The item name is the uuid of the item.