I also have wondered why the colors aren’t always the same. It sometimes confuses me.
I’ve created an issue to remind me to implement that:
Edit: this had nothing to do with the OH upgrade.
Just an unfortunate Aeotech Z-Wave stick power loss leaving just 31 of 74 nodes in its NVM memory.
I just updated from 5.2.1 to 5.3.0M3 and now half of my Z-Wave nodes are Offline.
They send data, but are rejected:
2026-10-13 23:59:52.507 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - NODE 57: Node not found in getConfigDescription
2026-10-14 00:03:05.265 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 57: Message payload = 00 39 07 60 0D 02 01 25 03 FF
2026-10-14 00:03:05.267 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 57: Not initialized (ie node unknown), ignoring message.
2026-10-14 00:03:05.396 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 57: Message payload = 00 39 05 5B 03 91 00 02
2026-10-14 00:03:05.398 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 57: Not initialized (ie node unknown), ignoring message.
2026-10-14 00:03:07.875 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 57: Message payload = 00 39 0C 60 0D 02 01 32 02 21 32 00 00 00 00
2026-10-14 00:03:07.877 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 57: Not initialized (ie node unknown), ignoring message.
Will try the latest snapshot …
I would have suggested to simply restart OH. There have been no ZW changes, except DB updates for some time.
Thanks for chiming in.
Have tried several restart.
Latest snapshot is the same.
Will try a downgrade to 5.2 again …
Do the restarts involve clearing the cache? Don’t do that if same version. I’ll try M3 on M2 now
I did clear the cache once after z-wave nodes listed as Offline after the first M3 boot.
Back on 5.2.3 and half of the nodes are still gone …
Have ordered a heal at 01:00, but did that on 00:00 as well …
Don’t know if waiting will fix it …
you need to do one restart without clearing the cache after an upgrade/downgrade. General process upgrade, let it settle (for me huge error log), then restart. OH has gotten so big that it takes a while for everything to get updated, but things start when bundles are missing.
Anyway, I’m on 5.3M3 now with a ZW binding. It is a small test environment (9 nodes)
Try deactivating the controller and reactivating it. (Heal won’t work)
I will do a full power cycle now …
Data is received when I press a scene controller, but is rejected …
That generally means an issue with the controller. The network is on the controller? You could try the silabs tool or reload an nvm backup tomorrow. I also have to go for now.
Yes, my thought exactly, because when I removed the thing, it did not reappear in the Inbox.
Update: plugged in my backup stick and things sprung to live again …
So, something happened on the stick itself.
Luckily I do have a NVM backup 
Wasn’t there an added possibility to hide the Chat from the side menu? I only see the option to hide elements within ‘Settings’…?
Updated from 5.2.0 release to 5.3.0.M3 (without bricking my Z-Wave dongle this time).
I discovered a small breaking change in DSL.
Looks like start and stop are now reserved words.
An ancient rule would no longer load:
2026-10-27 16:00:21.945 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'motion.rules' has errors, therefore ignoring it: [597,23]: mismatched character '=' expecting 'l'
Fix was to not use start or stop as variable names:
Had 2 of these in my file …
That is little strange because I don’t see start and stop as reserved words in the DSL rule syntax.
I will check if I can reproduce that.
I see no problem with variable named “stop” but I see it with variable named “start”.
Renaming it into “Start” or “start0” removes the problem.
Of course, using “^start” is also OK and avoid the conflict.
We have these keywords in the syntax that may explain the conflict: “start level is at least” and “reached start level”. I assume the first one is generating the conflict with your variable.
Interesting because “reached” is also not accepted.
I can see the problem is the same with “received” while we have keywords “received command” and “received update”. Variable named “command” or “update” are accepted while “received” is not.
Will check if I can add “start”, “reached”, “received”, … as valid ID.
I assumed this perhaps had something to do with timers. Hence the stop suspicion.
Thanks for looking into this, but no biggie.
@Kai what is the release plan for oh5.3???
We can expect a release for Christmas, as every year.