If you want personal assistance, just ask.
I agree. As things are rolling forward, it does become less and less likely to have a step-by-step migration path, especially with how many integration components (bindings) there are and how flexable the system is (which permits multiple ways to deploy).
The key (in my mind) is supposed to be the forums. A place where, when your unique issues arise, a collective intelligence can help guide for a correction (whether that be from development experience on the platform, or end users who have been burned and found a creative work-around). In an ideal world, a consensus might even be reached and it marked as a âsolvedâ thread to help contribute to a form of searchable âFAQâ. Unfortunately, with that comes the risk of the occasional person who choose to lead off with belittling and showing their âsuperiorityâ with just a tiny snipit of useful data, rather than an actual collaboration, ultimately stretching the use of the word âcommunityâ.
I like the platform. So far, I love what was done in OH3, I like the progress itâs making, and Iâm willing to continue accepting some of the (time-consuming) quirks as long as I can continue to come here and âspeakâ with decent human beings who are actually helpful and collaborative.
Drama aside, I did finally get this working, but a huge âgotchaâ to mention in case you ever do this upgrade as well, which might affect your âprocedureâ.
In OH3, it seems that the Homekit connectivity no longer makes use of âTagsâ, but instead Homekit-specific Metadata. Itâs actually a logical jump because itâs not just Homekit that has Metadata, so you can build AddOn-specific Metadata to each Item and it doesnât all have to be âmatchedâ to some universal tag that doesnât really expose everything that may be needed for each AddOn. Itâs a very clean way to do it from what I can tell, so it was a good move. However, it means that in this particular case, what was exposed to Homekit ended up disappearing because that MetaData wasnât there, nor did it get auto-generated on migration. So, even though the Things were there, Homekit had no clue they were there. What I mean is, the Things were intact and had their Tags of âSwitchableâ, âLightingâ, âContactSensorâ, etc, but Homekit didnât seem to care about them any longer, nor did a migration of any kind occur over to the new way (like âI see you have this tag, and this binding, I should generate this Metadataâ). It would have been nice if it did, but I understand why that wasnât a priority and itâs easily fixed AS LONG AS you keep it in mind as part of your procedure (see below: PROCEDURE CHANGE FOR ME)âŠ
What this meant for me was, on each Item, I had to then âAdd Metadataâ, select âApple Homekitâ, then add the components for each. Thereâs quite a few new ones added to the mix, so I actually got to refine contacts that are fire sensors (actually building them as âSmokeSensor.SmokeDetectedStateâ, water sensors as âLeakSensorâ, and motion sensors as âMotionSensorâ. This was nice because it meant as it appeared back in HomeKit, it actually didnât need itâs type selected - it did so on itâs own. Unfortunately, I wasnât able to make use of the window or door ones (those had to remain contact sensors because the window/door ones arenât simply a state of open/closed), but that may be more of a HomeKit limitation (HKâs expectations of what that device type sends as a signal). Within the new Homekit AddOn, thereâs now provisions to reverse the âreadâ on a contact state (alarm shows open but you can make HK show it as closed). A LOT of progress on that front.
PROCEDURE CHANGE FOR ME:
So, what that looked like for me was, database restored, all things there, and itâs existing Homekit linkage also restored, when the OH3 box was put back on the homeâs network, it told Homekit âI donât have anything for youâ, and all the devices disappeared out of Homekit with now no way to bring back (it seems, and this makes sense, if Homekit sees a device is no longer being presented, it removes it from Homekit, which includes removing from the room, any scenes, and automation) - re-adding would make it a ânewâ device in the default room again, and youâd have to move it again to the proper room as well as re-add it to any automation you once had it part of.
So, lesson learned. Iâve got a couple more homes to do this upgrade for, so my procedure revision will now be to go through all the items post-upgrade and add the HK-specific Metadata to the database BEFORE plugging it back on the homeâs network. This will ensure that most of the original HK âaccessoriesâ remain completely intact, and Iâd only probably have to re-link those accessories where I decided to update the type (ContactSensor to Smoke or Leak, etc.).
My next element to tackle is how to add in the OmniPro (Leviton/HAI) so itâs Security framework is presented to Homekit (already have another post on that one because it kinda confuses me).
Hope this helps if you decide to upgrade.
Lots of people upgraded flawlessly, @rossko57 offered to help and even the OP made it with my support.
So is that sarcasm? Why ?
352 to be precise.
I donât think thatâs a fair statement. First of all its really important to be clear on what project you are talking about. Is it openHAB, the home automation software? Or is it openHABian?
Based on my personal experience on an admittedly small OH instance, apt upgrade did everything I expected it to do to upgrade from 2.5 to 3.0. There was still some things I had to change in my rules which were documented and published breaking changes. Worked like a champ. Do you think if the general experience were that upgrades were impossible that those of us who do contribute to the forum and the docs would not have tried to do something about it? It worked for us so when it doesnât work itâs unexpected and itâs going to get technical in order to figure out why it didnât work for you.
For my larger instance, I took the opportunity to rebuild but I have no doubt it would have worked pretty much the same. And it was pretty easy too. I had all my Things and Items recreated in about an hour and everything was configured as I wanted in the Model too. The only lengthy part was rewriting my rules because I decided to change languages and move from text based rules to UI rules.
All the known breaking changes between OH 2.5 and 3.0 core that end users have to deal with are in the rules. Would you really want some upgrade mechanism to blindly do a search and replace on your code? Thatâs a recipe for disaster. Bindings, however, had some of their own breaking changes but those can occur at any time, not just at a major version release.
And yes of course you are going to see nothing but posts from people who had problems. Those where it worked donât post anything. Why would they? They donât need help.
And for those who do post for help, we need a lot of information and details in order to help. Nothing is as angering and demoralizing as trying your best to help someone but you have to painstakingly extract each and every little vital detail we need to even understand what is going on as if it were an impacted wisdom tooth. I pretty much quit all together when Iâve asked a specific questions for details and my question isnât answered. We greatly value our time. We donât ask questions or request additional information for our amusement. We need it.
But thatâs not the topic of this thread. openHABian is the topic of this thread. As has been said, openHABian has a much harder job. And this specific thread had to do with openHABian. If just the possible combinations of add-ons in OH is 350!, the possible combinations for a whole OS is going to be many millions factorial.
Iâm not sure I saw that mentioned anywhere and your thread was the first mention that I saw of that. Adding a warning to the binding docs might be worth the effort (there is a link at the bottom of every documentation page where a suggested edit can be submitted, though you do need an GitHub account). I do see that there was in fact a warning that tags would be going away in the 2.5 version of the docs for the HomeKit add-on. Though how many people go back and read the docs for each of their bindings? (I wish they would, it would save them and us a whole lot of time and frustration.)
As it is right now we simply donât have a great mechanism to report such breaking changes. Users donât read the forum. They donât read the release notes. They donât re-read the binding docs. They donât read the output from apt upgrade. Itâs a tough nut to crack.
The challenge there is the developers who maintain the Homekit binding are not the same developers who maintain openHAB core are not the same developers who maintain the repo that packages everything up into a deb or rpm for install. Who is responsible for implementing that? It seems like the binding dev would be but the actual upgrade scripts are maintained in the package repo and the binding developers might not know how to code it. They canât do it in the binding I think because they can only see those Items that are already tagged with the right metadata so there is a chicken and egg problem.
Unfortunately there are lots of places where stuff like this falls through the cracks. But I think the Homekit binding devs missed the mark on this one. They should have anticipated this problem. At a minimum I would have like to see their warning about the tags going away in their docs even after the support was removed.
You could also add the metadata to the Items prior to the upgrade. Depending on how your Items are defined I could help with different ways to do that. Having examples from your currently successfully migrated system will help.