Issue of the topic: All things “offline” after backup, migrate, and restore
After stopping the service, a backup .zip from an old instance (RPi3B+) was restored to a new instance (RPi4). All things were recognized as offline. and upon updating ip the MQTT broker status became “online”. tried stopping, cleaning ache and restarting, also tried redoing defining Thing in new instance. both ways to new instance Things reported as “offline”
What logs are needed to diagnose? Any thought on cause?
What do you mean by “a backup .zip”? What OS version?
Running OpenJDK is not recommended. Did you do before ?
With that many open parameters it’s hard to tell. If I were you I’d start from scratch, using openHABian and openhab-cli backup/restore rather than take on debugging.
PS: beta image at beta Images holgerfriedrich/openhabian
I ran openhab-cli backup then copied the backup .zip to the new instance and ran openhab-cli restore on that backup from the new instance. I updated the mqtt broker ip to that of the new instance, and it shows as “online” but all the Things and Items that were restored are “offline”. I ran openhab-cli clean-cache to start the new image fresh after the restore, but that didn’t fix the offline issue.
This pi runs other services, so wiping it to run OpenHABian isn’t a viable solution. Where would I beggin debubbing the cause of restored Things being offline?
MQTT items are still offline. None of the MQTT device listed as offline work when controlled from the new instance. The old instance still works as intended. They’re all Generic MQTT Things with an MQTT Binding.
Could it be that the two instance of mosquitto are interfering? sudo lsof -i on the new instance returns only mosquitto 479 mosquitto 5u IPv4 14219 0t0 TCP *:1883 (LISTEN) mosquitto 479 mosquitto 6u IPv6 14220 0t0 TCP *:1883 (LISTEN) mosquitto 479 mosquitto 8u IPv4 97035 0t0 TCP picld.lan:1883->picld.lan:57538 (ESTABLISHED)
indicating the MQTT broker on the new instance is online and connected, but nothing else on the new instance. sudo lsof -i on the old instance additionally has entries for all my tasmota switch devices.
Does the old instance need to be offline before the new instance can connect to my MQTT devices? i.e. can a tasmota relay/switch only communicate with one mosquitto at a time?
As far as I can tell when using Paper UI to configure a switch MQTT item there are fields for “name”, “label”, and “catergory”. but nothing that would point the Item to a broker. Am I missing something? How would one update the broker an item is pointed at?
When configuring Things there’s an option to select the MQTT bridge, but even though I have the active MQTT Broker (which shows as “online”) selected, the newly configured Things remain “offline”
Stop the old instance and change the IP address of new instance to be what the old one was and see what happens. Else do as @Thedannymullen mentioned and change the IP address in each device to point to the new instance.
OK, stopping the old instance, changing the assigned Broker Host ip on the new instance, then restarting the new instance gave the new instance control of Things and Items. What does that mean?
It seems I have OpenHAB running on the new instance and MQTT on the old, with what was done. How do I get the MQTT Broker on the new instance to be in control?
I realize this may not be an OpenHAB issue, but rather a mosquitto issue and appreciate any guidance you can offer.
Did you remember to install Mosquitto on your Rpi4?
Mosquitto is an external service. It will not be part of openhab-cli backup. So you have to enter openhabian-config and install Mosquitto (or do it manually from command line).
If your Rpi do not have the same IP as your old Rpi, then you´ll need to change each MQTT client to the new IP as well. This is an “issue” I just rasied in another thread about openhab-cli, (not regarding MQTT but others. It will comply to MQTT as well though).
I had mosquitto installed and configured on the RPi4 prior to restoring the backup. The MQTT Broker Thing on the new instance was able to be recognized and online, but it doesn’t seem to have any communication with the restored Things/Items. I changed the MQTT Client on the new instance manually for each restored Thing/Item, but that didn’t bring them online.
Is the old MQTT Broker interfering with the new one?
It shouldnt… You can have several MQTT brokers running if you wanted to, (no reason to though) and they will work just fine as long as they are having individuals IP adresses or port numbers.
Thats good. Then you know your Broker is working.
But…
No, thats because you run a new Broker now. I assume you did not name the new Broker (on your Rpi4) the same as the old Broker?
If you use PaperUI for your MQTT setup, then you have to enter each thing (device) in PaperUI and change it to the new Broker (Bridge).
If you run a .thing file for your MQTT Bridge and devices the Brigde is easy to change.
(This is my setup)
A small note, which I think is kinda confusing when running MQTT on openhab and may be causing misunderstandings.
The actualy MQTT Broker thing in PaperUI is quite misleading. Its not The Broker. Its a Bridge connection between openhab´s MQTT devices and the actual MQTT Broker. In my opinion this perticular thing should be named MQTT Brigde and not MQTT Broker.
Here are some screenshots explaining.
First the Broker thing (which should be named Brigde in my opinion).
I think my difficulty is with mosquitto. When the old mqtt broker is used everything works fine, but I want mqtt and OpenHAB to both exist on the same pi, so that isn’t satisfactory.
When I enable and start mqtt on the new pi I’m able to subscribe to and publish message, so it seems I have the new mqtt set up and configured.
I can set the mqtt bridge on the new pi to the new pi’s ip, and that registers “online”. But the trouble is with getting the Things, which I’ve switched to the new bridge, “online”.
I’ve gotten as far as sudo lsof -i on each instance and it seems that is showing the discrepancy between the two mqtts. The old shows listening on port 1883 as well as connections to several tasmota devices. But the new only shows listening on port 1883, no device conections.
It seems OpenHAB subscribes the mqtt to those topics? so on the old pi OpenHAB set up subscriprions for the MQTT to each topic, thus all the device connections established. But on the new pi OpenHAB, even when set with a new bridge to a new broker, does not subscribe to any of the topics, thus all things “offline”.
Even when I try to create a new thing in the new pi with the new bridge to the new broker, it stays offline. Yet the same thing with the old bridge to the old broker works on the new pi.
I know all this “old” and “new” seems confusing, but that’s part of why it seems so difficult to debug where the setup is failing? any suggestions would be appreciated.
One more thought, the old pi, where everything works, is connected to both wifi and lan. The new is wifi-only. Does mqtt need a lan connection?
Thedannymullen that was it. I had overlooked reconfiguring the tasmota for the new server. I appreciate the help diagnosing what wasn’t even an OpenHAB issue.
For posterity: when you change device mqtt broker ips, make sure you change the firmware’s mqtt broker ip as well.
That goes for all external services you run, when changing IP´s.
Small tips for future restoring of backups!
To minimize the exstra work user have to do after restoring a backup like that, you´d be better off, if you use the same IP for the new setup as the old setup. This means, you have to unplug the old setup and use static IP for the new setup. (Unfortunalty there are no easy way to set static IP on the Rpi, as far as I know, (please correct me if I´m wrong). So static IP´s have to be setup through your router).
In general - its always a good idea to use static IP for a server. Even though its not common that a router (DHCP server) will change an IP for a DHCP client unless its mac adresse change, it can happen. If it happens to your openhabian system, things will screw up for sure, specially for those services which make use of direct IP adresses. Services which use hostnames or locally running services (127.0.0.1 = localhost) will not be affected by a change of IP.
