[shelly] Log "spam" after upgrade to openHAB 3.4.1 (see #14032)

[aromedia1]

In my case issue #14032 is not solved.
I've deinstalled all shelly devices, remove shelly add-on, clean-cache and reboot.

After that:
"systemctl stop openhab.service",
"systemctl daemon-reload",
"openhab-cli clean-cache"
update packages per openhabian-config "Upgrade System"
reboot
install shelly add-on again
scan for things
add shelly 3em

Now again, every 15 seconds this log message occurs (as described in #14032 no such log entries with OH3.3)
[WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.

Version: openHab 3.4.1 Release Build

[stefan-hoehn]

Isn't this a duplicate of #14032?

[aromedia1]

Yes, it is, as mentioned above.
But i should open a new issue.

[unf]

Meanwhile I found again time to test 3.4.x packages, problem remains the same. Log spam disappears after starting openhab instance w/o shelly add-on and re-appears with ...

@aromedia1 Do you use/run homekit integration?

install shelly add-on again

Just for my understanding what have you done here?

[aromedia1]

@unf
No i don't run homekit integration

Due the spam log entries after updating to 3.4 i've deleted all shelly devices an deinstalled shelly add-on.
After closing the issue i give it a try, update to 3.4.1 and installed shelly add-on again

[unf]

@aromedia1 Ok, thanks for reply, no homekit, so that can be taken out of the equotion ...

So, you are controlling everything from PaperUI, ok, understand. I control everything from the ASCII files, e.g. addons.cfg for bindings. If I delete "shelly" from the list of bindings in that file, openhab starts then w/o shelly binding and it is not even around. That way I can keep my things/item files, they are just ignored.

Going back to 3.3.x was a solution for me, but my properly working homekit installation does not work anymore for now. Looks like its related to the latest iOS 16.3 updates ... I still can control openhab using openhab app, but not homekit app.

3.4.x does bring to much stress to the little Raspberry Pi, due to the log spam ... a kind of a bad joke, looking to the complaints about 64-bit installation by the openhabian team.

[markus7017]

Is this a Gen1 device? Try to set CoIOT in the device UI to the specific OH IP address (or use Shelly Manager). Is currently under investigation here: https://community.openhab.org/t/shelly-binding/56862/3117?u=markus7017
Post a TRACE log there

[unf]

Is this a Gen1 device?

@markus7017 Can you please specify Gen1 device? In my case I have a bunch of "Shelly 1", "Shelly 2.5" & "Shelly Plug S" in my setup.

(or use Shelly Manager)

So, just for clarity, OH Shelly Manager?

[aromedia1]

@markus7017 I've different shelly devices like shelly 2,5pm, shelly 3em, shelly 1 (with specific ip-adress)
Works all perfect with oh3.3

[unf]

@markus7017 Ok, defined CoIoT using peer mode, updated packages again to OH 3.4.2 and now I see those messages just while OH service is starting up

2023-02-27 10:52:35.625 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
2023-02-27 10:52:38.398 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.

So, basically until getting that startup message

2023-02-27 11:10:23.659 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel

From that point on logs are showing just the normal stuff they should do. Cool 👍

Easy solution and maybe already available back in Dec. 2022 on my first thread about it.

It raises just one question, why was CoIoT "mcast" working till OH 3.3.0 and OH 3.4.0 does now need peer mode?

[aromedia1]

@markus7017
I've changed ColoT of all shelly device to peer mode.
No more 'spam' entries in log
Thanks for your support

[markus7017]

Try latest DEV build, I added an additional check on thing state, maybe that helps

[markus7017]

I found a bug when matching the icoming Coat packet to the corresponding thing. It might solve the issue here as a side effect if device B is trying to update device A, not sure.

[BasvanH]

@markus7017
I've changed ColoT of all shelly device to peer mode.

Same goes for me to.

[wosch87]

Hi guys, this topic is closed as it seems that changing CoIoT to peer mode solved the issue for others. But unfortunately I still get those log entries and high RAM usage. I need to restart my PC on a regular basis as the system gets super slow...

2023-04-28 12:30:59.532 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed. 2023-04-28 12:30:59.782 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed. 2023-04-28 12:30:59.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed. 2023-04-28 12:31:00.001 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.

I've updated from 3.3 to 3.4.3 a few days ago (Windows 10). No issues on 3.3 - starting immediately with 3.4.3.

Any ideas what to do?

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/shelly-beta-with-plus-pro-support/139554/41