TODO: Implement Application Update Request Handling of New ID Assigned (64)

Is this a Pi? Sounds like a failed SD card.

Yes sir, it is…

I am quite tired of the sd failures…what is a better option?

I personally moved to a Debian VM on my son’s server.

Some people have used a USB connected SSD with a Pi.

I did the ssd thing too, still had issues with pis going bad…been on the pi for years…

This install is at work, so the server sounds like the best option. Is install any different?

For OH2 I did install openHABian on Debian but for OH3 I am moving to Docker. The Docker container already contains Java and all dependencies from the OH developers. You need to set up the volumes & devices to have your data outside the Docker container. Upgrades are then quite easy.

The big thing if you use a VM instead of installing Linux on the server is bridging networking and devices. In my case, my son already had the server with the proper networking setup. We just needed to work through the device bridging for my Z-wave stick.

We have an IT company that handles our server, im sure they could help. What exactly is a docker? I’ve seen it mentioned, just never went past that.

Docker is similar to a virtual machine in allowing multiple systems on the same server. Here is some OH2 documentation. I am working, little by little, to try & simplify it for my use.

The system settled itself out and was back to running fine until sometime this morning.

There is obviously something going on…I will be away from my computer for most of the day, but am greatful for any suggestions…I will be migrating to a VM, but that will not happen soon, so I need to fix this install…

I struggled a bit with the same problem. Although I did a number of things to try fix over days, I believe the solution (for me anyway) was to turn >settings> API Security >basic authorization >ON.
Bob

Thank you for the suggestion, ill try it out.

This warning is not related to the web interface - it is a ZWave issue. It means that the binding received a command from a device that it was not expecting and does not proceess.

I did hedge my answer since I made a number of changes. In my struggles I did ID the source of the Warning message in the Zwave binding (ApplicationUpdateMessageClass file.

I had no Warn messages for a couple of weeks after upgrading to OH3 from 2.5.11 with the heal disabled. The message only appeared when I decided to try a network heal. Also it appeared related to the controller, since despite all the warnings, all the other node XML files were updated. What led me to try the API security switch I ran a Debug heal (see attached) and two things stood out eventually (a getConfigDescription) message and the message from your log viewer that the Node 1 neighbors were not updated., so I surmised there might be issues with Put/Get between 2.5 & 3.0 and did see from other postings that this security feature was added.

Anyway heals are working for me now, but it could be something else I did.

openhab.log (585.7 KB)

So then I should assume its from node 64? Should I remove and reinclude then?

No - I think this is a controller message.

I’m assuming the API security switch did not work for you and you still have the issue. You might want to take a look at the following to see if there are any similarities. Z-wave network heal issue on transitioned OH 2.5.10 to 3.0 installation - Add-ons / Bindings - openHAB Community

This was my starting analysis that narrowed it down for me to the controller and the network heal. The full story of what I did was to delete the OH2.5 controller, create a OH3 controller in the new UI with the same ID as the Home_ID. This meant I has to rediscover all 45 nodes and relink 91 items :unamused:. However, that alone was not enough. For some reason the OH3 UI controller creation did not include some of the 2.5 controller properties, specifically the Home_ID, so I used the UI Developer Tool of API “PUT” to add them. About the same time I changed the API security switch mentioned above thinking that was what was holding the properties update back. I had hoped that was an easier solution than the ID mismatch. If your problem is the same (can’t tell from the data you provided) compare the ID of the eight digit controller with the Home_ID of the nodes. I don’t know if these need to be the same, but that and the security switch worked for me to clear the WARN TODO.

Based on the activity of this thread and nothing on mine, I’d say this is not a common problem, but as more novices transition to OH3 over the next year, I thought I would document it here.

I did run a Debug 'Heal" with the above changes and the one message that no longer appears is (dest=1 is the controller and callback=64 is what is in the warn message)
`

> Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=1, callback=64, payload=40 01 10 02 02 01 5E 86 72 73 80 71 85 59 84 30 70 EF 20

Bob

`

Can you please elaborate on where this is at? I am getting a bunch of the errors now too.

2021-05-19 14:15:18.866 [WARN ] [essage.ApplicationUpdateMessageClass] - TODO: Implement Application Update Request Handling of New ID Assigned (64).

I do not understand “where this is at?”. I did solve the problem as described in the posts. Are you on OH2.5 or OH3? Do you mean where in the java code?

sorry i replied to your post it didnt show thepost. I am on OH2.5.11

when you said to turn >settings> API Security >basic authorization >ON.

ok. So my error appeared after transitioning to OH3. I did not have a problem on OH2.5x

settings> API Security >basic authorization >ON

is an OH 3 thing, not OH2.5.11 and was not likely the cure anyway. I think :wink:it was making sure the controller has the same ID as the xml files (at least for me).

Bob

oh ok, thanks!