I am currently running (for some years now) a Raspberry Pi 3 with OH 2.5.11-1.
I have a medium size Zwave network, some graphana charts/influx db, a variety of bindings (Astro sun, mqtt, etc.), and most of the rules, scripts, things, items, and sitemap Are in files that I edit with vscode. Also, bindings for presence detection of cell phones…
I’d like to hear thoughts on how to plan and execute an upgrade to OH 3.
(the obvious first step would be a backup…)
I have another Pi and am willing to by another Zwave interface (it could end up being a backup device).
WHat about migrating all the bindings and scr
I’ve done searches here and read a couple of the upgrade threads (many are people who’ve had some issues getting 3 to run, not necessarily about upgrade a whole system).
I think the best suggestion may be to wait until next week when 3.1.0 is released. There are quite a few zwave devices that have been added since 3.0 was released last year and current snapshot bindings are incompatible with 3.0.x.
You have two approaches given you have a second RPi to work on.
You can try to do an “all at once” migration of everything which will be a good deal of work but it should work. You can leave the zwave controller plugged into the old RPi and leave the old RPi running until you’ve dealt with all the breaking changes introduced in OH 3.
Rebuild your config little by little on the new RPi. Move one binding at a time over to OH 3 and create the Items and rules and UI elements for that one binding. Spend some time exploring OH 3 as there are new ways to do some things which might make you want to change your overall approach. For example, the ease in creating a bunch of Items based on a Thing and building up the semantic model may make you consider managing your Items through the UI instead of .items files. Review the Getting Started tutorial for details.
I followed and recommend 2 but I know others have been successful using 1. Just migrate your bindings that require special hardware, like Zwave, last.
You can leverage the Remote openHAB binding to mirror the Items in your old OH 2 instance in OH 3 which can aide in the migration as well. For example, you could create all your Zwave Items and test out your UI and Rules but leave the controller connected to your old RPi. Once it all works as expected you can move the controller to the new RPi and relink the Items from the Remote openHAB Things to the Zwave Things.
So, if I put an image on the new Pi, do I just use the IP address it gets to do the setup described? (Create Admin, etc.) For example: http://<IP of new OH/Pi here>:8080
Is this going cause issues? Do I need to do something to the new OH/Pi to make it coexist with the old?
What happens when I start adding bindings that are now (at least until I turn them off on the old) duplicating actions. (not to mention duplicate Things and Items…)
Of course. It’s a different machine so it’ll necessarily have a different address.
No as long as you don’t try to set it up to have the same IP address as the old one.
They will duplicate the actions. If it’s a problem, turn them off on the old instance first before setting them up on the new instance.
The whole point of a gradual setup using the Remote openHAB binding is that you gradually move the config from the old to the new. You must disable/delete the old config and run it off of the new config.
So to provide a bit more step-by-step:
install OH 3
install the Remote OH binding
discover the old OH instance and create the Things
create the Items linked to the Remote OH Things; now your OH 3 has a mirror of your OH 2 instance and any commands issued on OH 3 will be forwarded to the OH 2 instance
pick a binding and install it on OH 3
discover the Things for that binding
change the links to the Items in OH 3 from the Remote OH binding to the actual binding’s Thing
remote the Things and Items and binding from the old OH instance
repeat 5-8 for all your bindings
stop the old OH instance once everything is migrated to the new OH
At any one of the steps between 5 and 8 you can bring over sitemaps and rules and persistence as needed.
Well, yeah, the IP is different. I meant since the new instance was attempting to use the same host name.
(The OS is going to start with a predefined configuration since this is going to be the OH image written to an SD card, it will have it’s hostname set to openhabianpi, right? Can I edit the hostname file before writing to the SD?)
The rest all sounds easy enough. Thanks.
But it always does sound easy until you start clicking.
When I did my migration it was preceeded by using a second RasPi to evaluate a couple of milestones before the official 3.0 release came out. Except for the ZWave part of my configuration I tested everything on the second RasPi (I only had one ZWave controller back then) and was familiar with the changes needed when the release of 3.0 took place. So basically I did what Rich suggested as the “all at once” aproach, but with a bit of “training” before it was done in a final step.
When 3.0 was released officially it took app. 3h to move everything from 2.x to 3.0, recreating all ZWave things with the same names as in 2.x. (23 ZWave things plus the controller).
Except for the thing definitions everything was in defined in files. (And still is as I have a job that does not leave enough time to evaluate all the new possibilities yet, but that will come some day )
Can someone tell me, if, I unplug the Zwave controller from my RPi 3 and plug it into the new RPi 4, will it remember the devices on the zwave network? (Cuz…running around the house with a little pokey thing, a ladder, and documents for all the different brands I have is going to be a real pain. )
Yes, the nodes and Zwave network is stored on the Zwave Controller. However, you may need to wake up battery powered devices a few times to give the binding a chance to interrogate the device enough to discover exactly what it is.
There are other entries as well with commandTopic=.
But in the UI, the bridge has a tab for Channels, but does not have a tab for Things
There is a generic mqtt Thing, but I don’t get what of the old definition maps to Availability Topic, Device Availability Payload, Device Availability Payload…yes, I see the defaults for the later two are ON/OFF…but that does not map to my old .thing file…
…and I don’t see how to define whether it is a state or command.
And, yes I’ve read what I could find in the docs (and I fully expect “But, did you read here”, retorts…as this is typical for me to read it (multiple times) and not see it).
That’s not how it works. The Bridge Things and the other Thing are listed separate. This is the case for all bindings and was also the case in PaperUI.
The red arrows point to my two broker Things. For various reasons I’ve two brokers in my setup. All the rest of the the Things work through one of those two Bridge Broker Things.
But if you want to manage your Things through text files, why are you looking in MainUI in the first place? As far as I’m aware a .things file for OH 2.5 defining MQTT Things should work in OH 3 unmodified.
Those are a way to use a LWT topic and message used by the device to mark the Thing as ONLINE/OFFLINE. You are not using this feature in your current text configs so of course you won’t see them mapped to your .things file.
If the “it” you are referring to is the availability properties you won’t see that because they have nothing to do with Item states or commands. They are for the Thing’s status. Click on the Channels tab for the Thing and you should see an entry for your “Motion in the garage” Channel. That’s where you would see state and command topics and such.
But you will not be able to change anything because you are using text files. And the text files should work exactly like they always have. I don’t even think any new parameters were added between 2.5 and 3.0. So what are you hoping to be able to see and do in MainUI?
If you want to use MainUI to manage your Things, which is what I recommend (I will not spend any more of my time helping people with .things files on this forum), then review the Getting Started Tutorial. The Adding Things - Advanced page is basically an MQTT Tutorial.
I have stated I have reviewed the Getting Started Tutorial", and I’ve done it several times. It apparently needs more than my addled old brain to read them and understand the ramifications of what is said the first, second, third time through and how to map it onto what I remember from years past.
So, I ask questions…until it sinks through my quicksand brain. Sorry.
Look, I’m am NOT trying to USE the .thing file with 3.x, I’m trying to figure out how to use what’s in my old one to figure out how to create the things in the new UI.
I’m trying to create them with same or similar names, so that, as you suggested, I can use the .rules file that is just fine. Or, did I misunderstand what you said?
The existing rules use names and such from Things and Items, so I figured using the same names when using the new UI would make my life simpler.
All I’m going to do here is regurgitate what I’ve already written there because it’s the only way I know how to express it.
As is presented there, you install the binding. Then you create the Broker Thing. If the Broker Thing shows as ONLINE then it’s successfully connected. Then you create the Generic MQTT Thing. As part of creating the Generic MQTT Thing you have to create one or more Channels. Each Channel publishes and/or subscribes to an MQTT Topic.
You won’t see a state topic or a command topic or transformation or anything else like that until you create the Channels.
It’s not receiving anything until you have a Channel created and configured to subscribe to a topic. You won’t see anything in the openHAB logs until you have an Item linked to that Channel. Just like it worked in OH 2.5.
I have a broker thing, it says online. (defined with same names addresses as in OH 2.5)
I have a generic thing, it says it’s online. (defined with same names addresses as in OH 2.5)
I have a channel subscribe to the topic. (defined with same names addresses as in OH 2.5)
BTW, the OH 2.5 system is stopped.
I trigger the device, I see the broker of the topic.
OH logs nothing.
As to:
It’s not your writing, it’s my perception of what’s written.
I read the words, over and over, I do the stuff they say, and it doesn’t do what I thought it said.
So, I read again.
It’s my ability to extrapolate or something…been that way my entire life. Things that I can pick and twist around in my hands are no problem, but, trying to take sentences and assemble them into the big picture takes me forever to get to the aha! moment.
I created a new Item and linked it to the channel.
And if I link it to an item from the old .items file it logs as well.
I don’t see anywhere that I’ve specified the payload…but the log shows that as well. It is just logging what ever the payload is?
But, if I link it to items from the old .items file the log shows errors in the rules file:
2021-06-24 21:40:01.366 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'driveway-2' failed: Could not cast NULL to java.lang.Number; line 114, column 11, length 28 in driveway
2021-06-24 21:40:01.367 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'driveway-1' failed: 'sendMail' is not a member of 'org.openhab.core.thing.binding.ThingActions'; line 75, column 2, length 56 in driveway
How do I tell what driveway-1 & 2 are…I have nothing by that name in the rules file…
What direction is this message going? Is OH subscribing or publishing? If OH is subscribing then the payload is what ever the message was that was published. If OH i publishing it’s what ever command was sent to the Item.
The first rule defined in the file driveway.rules is driveway-1. The second rule is driveway-2, and so on. You could also search based on the errors you are seeing. That first error is telling you exactly where the error occured: “line 114, column 11”. The second error is on line 75 column 2.
Other clues for where the error is:
the first error is complaining that it cannot cast NULL to a Number so the error is coming from a line that includes “as Number”
the second error is complaining that “sendMail” doesn’t exist so the error is coming from a line that includes “sendMail”
The first error is caused because what ever Item that line is trying to use has a state of NULL which means that Item has never received an update. NULL cannot be cast to a Number. The second error is because you’ve not installed the Mail binding and haven’t created a Thing yet.
Just to be clear here. OH 3 provides a new UI to manage Items and Things and Links and all that through the UI. But it doesn’t replace the old ways and there are no new concepts or anything drastically different from PaperUI.
All this work you’ve done was useful only if you want to use the new UI. But you don’t have to use the new UI. You don’t have to use any UI at all. You can still use the .things files. You can still use the .items files. Nothing requires you to change.
All OH 3 did was provide an improved UI for managing Things and Items and Links and such. That seems to be something a lot of people miss. There really isn’t all that much that’s new in OH 3. It’s mostly just improvements to what is already there. And almost everything that is new is optional. You don’t have to use it. You can continue to do things the same way you’ve done in 2.5.
But you have to get the Channel IDs right. If you have .items files with Items that have links to Channels define, the part between the " " needs to be a valid Channel ID.
)
)
