openhab-addons: [Telegram] Rule execution aborted after strange SocketTimeoutException after switch to OH3

I use the telegramAction.sendTelegram() in several of my rules. When I was running on OH2 everything worked fine. After I switched to OH3, I rarely get scripts not being fully executed and being aborted when the telegramAction is fired. I suspect the issue within the telegram binding, because I added loggings before and after the telegramAction and can see that the logging after it is not executed.

This is how the rule looks like:


   logInfo("Shadowing", "Start shadowing")
   val telegramAction = getActions("telegram","telegram:telegramBot:Telegram_Bot")
   telegramAction.sendTelegram(XXX, "Start shadowing")
   logInfo("Shadowing", "Telegram sent")

This produces the following log (as said in rare cases):

2021-08-11 08:37:25.807 [INFO ] [.openhab.core.model.script.Shadowing] Start shadowing
2021-08-11 08:38:40.367 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'shadowing-7' failed: java.net.SocketTimeoutException: timeout in shadowing

I don’t see any stack trace or anything more than that in the logs. Internet connectivity at that time was existing. OH is running on a server directly connected to the internet, so also no WIFI or something in between which might cause network issues.

Expected Behavior

rule not to be aborted, detailed error report

Current Behavior

rule being aborted after the error occurs. Telegram message not sent out.

Possible Solution

In some older posts I found there was someone providing a beta version of the binding with a changed connect timeout. I didn’t find a way to configure connect timeouts for recent versions of the binding. It might help to increase the timeout maybe.

Steps to Reproduce (for Bugs)

Hard to reproduce even for me. This happens one times out of one hundred calls of the rule I would guess.

Context

In the concrete case above I just want to send Telegram messages when I start shadowing my rooms and pulling down shutters. I have a light sensor running which is monitored by OH and this triggers the shadowing after some threshold is reached (brightness over some time). But I have a bunch of other rules running with different intent and the problem occurs randomly in all rules in very rare cases. But this makes rule execution unreliable.

Your Environment

openHAB 3.1.0 (stable) Telegram Binding 3.1.0 OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.18.04, mixed mode, sharing)

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 23 (8 by maintainers)

Most upvoted comments

Recently I noticed I didn’t get all of my Telegram messages. My logs and Google brought me here. I’ve also installed the jar. Will let you know how things turn out.

stefanheijnen on Sep 11, 2021

That jar will work fine on 3.1 stable, the advantage of openHAB is you can mix and match bindings with most cores if there is an issue and you don’t even need to reboot! Just uninstall the binding first, then unzip and place the jar into the addons folder. Everything should then just go back to how it was.

Skinah on Sep 7, 2021

Jar to try can be downloaded from http://pcmus.com/openhab/telegram/

Skinah on Sep 6, 2021

OK I have made 2 changes for you that will need to be tested since I can not reproduce this here. As per @J-N-K post I have done a try/catch block for Exception so this should work and also give a WARN with more details when it happens again. I say WHEN it happens again as the exception will occur if you have a network drop out or the telegram server has an issue after the binding successfully connects to the server. However the rule should continue and finish without getting terminated, and we should get more info. I also increased the timeout from 10 seconds to 75 seconds.

There is also an exception listener setup in the initlise() of the handler. This may be taking the thing OFFLINE, so when this happens do you see the thing go offline in the event.log? There may be a more detailed message in the event.log

localBot.setUpdatesListener(this::handleUpdates, this::handleExceptions,
                getGetUpdatesRequest(config.getLongPollingTime()));

As for your questions about queuing messages, lets fix the rule getting aborted first. The actions will return a FALSE if they fail, so the rule can be made to try again very easily with this returned boolean.

Skinah on Sep 6, 2021