I gave up on this…
Couldn‘t get it working and switched to mails for non important messages.
Is there a place to submit bugs for the Telegram addon? Github or similar? Is this addon still maintained? I’m having an issue where this addon times out after extended periods of no activity (ie: 6+hrs). Messages cannot be received when it times out. Messages only start working again after the first message from OH->Bot takes place (which is always missed), and that seems to revive the connection for future messages.
The bandaid solution is a script that runs every hour between midnight-6am to disable/enable the addon. Is there no solution to fix the addon so that it “pings” telegram api every so often and keeps the connection alive?
I dont have this problem… Could it be that it is caused by something else in your environment? Internet disconnect by the provider, pihole, …?
Maybe once a week, I’ll lose internet for a few minutes during sleeping hours, but 99% of the time my connection is solid. I have monitoring for my connection so I know when it goes down.
My issue is very repeatable, in that this happens almost daily (my internet is absolutely not going out daily). The last telegram message might be sent from OH->TG around 7pm. The next message to go out should be when I wake and open the back door, around 6:30am next morning. I’l never receive this message. When I get back from morning walk, say 6:45am, and open the door, yes, I’ll get that message. I turned on DEBUG logging for the telegram binding and I can see a timeout message from the binding when i open the 6:30am door. Then a few seconds later there will be a telegram active message. So, the conclusion is that 11-12hrs of no data times the binding out.
Never saw this. I have sometimes 3 or 4 days OH not should send a telegram message and next message still works.
Please give some more information about your environment?
=> Kind of Internet-Connection?
=> Router?
=> Provider?
=> Openhab installed on what kinde of hardware? Hardware to Internet via cable? WiFi?
EDIT: Another possible reason: Maybe the message 6:30 is part of the problem.
Please show code of rule here.
=> Cable
=> Ubiquity Edge Lite
=> Comcast
=> Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz / 32GB RAM / Ubuntu 18.04 / Wired / Docker
The code that runs at 6:30am is the same code that runs at 6:45am. It is an “on state change” → “send telegram”.
I mean the telegram message. If I remember right, I had problems with some chars interpreted by telegram API in different way. But if I understand: It’s always exactly the same message in the telegram.
Interesting you have a timeout. Something to see in the Router protocoll that time? New IP?
I’ll try and grab the error message again tomorrow morning. It’s not precisely at 6:30am. Some mornings I open the door at 6:20, or 6:40, or 6:33, etc. It’s just always “the first message” after going overnight without any activity.
Your informations are confusing. Earlier you said you never received the message when you open the back door.
Now its always the first message of the new day you don’t receive, because of a timeout in the log.
I believe it’s your code and the message inside. But as you don’t want so show, because you are in meaning its a binding failure: Difficult to help.
Furthermore, the last nights log should be still there.
The first message of the new day is me opening the door to go outside for a walk. I said this, 6 posts above this one, so I don’t see how it is confusing. Please re-read that post. I thought I was very explicit in describing the timing.
I believe it’s your code and the message inside.
Here why it isn’t the code: It’s the same code! The code that runs at 6:30am, is the same code that runs at 6:45, which is the same code that runs every time someone opens any door throughout the day. 1 rule that says “on state change of any door, run script which sends TG message ‘Door Opened’”. Since I get that message at 6:45 when I open the door after returning from walk, I know it’s not the code. But if you insist:
var doorItem = items.getItem(event.itemName);
var prettyItemName = doorItem.label;
var prettyState = doorItem.state == "OPEN" ? "Opened" : "Closed";
console.log("DOOR: " + prettyItemName + " is " + prettyState);
actions.Things.getActions("telegram", "telegram:telegramBot:aaaaaaa").sendTelegram(prettyItemName + " " + prettyState);
To recap, after 11-12hrs of no TG activity, I’ll never receive “the first message” of the day. Whether that’s opening the back door, side door, garage door, whichever door, I’ll never receive it. Coming back inside, whether that’s 5m later, or 10m later, I always get that message and I continue to get ‘door opened’ messages all day long.
Hm, very interesting because I have a fully different syntax on sendTelegram.
Which version of openHAB you are using?
My sendTelegram needs (ChatId, Message)
OH 3.4.0
Documentation says you only need to send the message 
As expected, the issue happened again this morning. I turned on TRACE for telegram binding, but I didn’t see any additional messages:
06:57:45.503 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Backdoor_SensorBinary' updated to OPEN
06:57:45.504 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Backdoor_SensorBinary' changed from CLOSED to OPEN
06:57:47.262 [INFO ] [enhab.automation.script.ui.da88b1ba77] - DOOR: Back Door is Opened
06:57:53.287 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Backdoor_SensorBinary' updated to CLOSED
06:57:53.288 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Backdoor_SensorBinary' changed from OPEN to CLOSED
06:58:06.559 [INFO ] [openhab.event.ItemStateEvent ] - Item 'TrippLite_InputVoltage' updated to 120.1 V
06:58:06.560 [INFO ] [openhab.event.ItemStateEvent ] - Item 'TrippLite_UPSLoad' updated to 7 %
06:58:06.561 [INFO ] [openhab.event.ItemStateEvent ] - Item 'TrippLite_UPSStatus' updated to OL
06:58:06.562 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TrippLite_InputVoltage' changed from 119.6 V to 120.1 V
06:59:02.276 [WARN ] [egram.internal.action.TelegramActions] - Exception occured whilst sending message:java.net.SocketTimeoutException: timeout
06:59:06.607 [INFO ] [openhab.event.ItemStateEvent ] - Item 'TrippLite_InputVoltage' updated to 119.8 V
07:00:21.189 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Backdoor_SensorBinary' updated to OPEN
07:00:21.190 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Backdoor_SensorBinary' changed from CLOSED to OPEN
07:00:21.191 [INFO ] [enhab.automation.script.ui.da88b1ba77] - DOOR: Back Door is Opened
07:00:22.719 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Backdoor_SensorBinary' updated to CLOSED
07:00:22.719 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Backdoor_SensorBinary' changed from OPEN to CLOSED
You can see that at 6:57:45 the door opened (first action of the day) and the script fired off. At 6:59:02, you can see the Telegram timeout. At 7:00:21 the door opened again, script fired off, and I received this message. I never received the first message from 6:57 due to the timeout but I have received all subsequent events so far.
What’s about restarting the telegram binding at 6 o’clock in the morning?
I’m restarting mine every day after isp reconnect at 4:05 o’clock and I have no problems with timeouts…
Greets
Well, some lower in documentation is the way to adress a specific chat:
telegramAction.sendTelegram(1234567L, "Hello world!")
Because we are more then one user with telegram I only use it this way.
Maybe turn of debugging on telegram would be good choice. To find out when it loses connection.
I newer saw this, at me telegram works over month without timeout. So we need to search
As I said in my previous message this morning:
Just FYI:
I’m running 3.4.0 stable release with Telegram binding. All works fine without any modifications or workarounds. Sometimes I have messages in 15mins intervals. Sometimes its quiet between 18:15 last message and 10:30 next day first message.
So most likely something locally that your OH server cannot reach the telegram endpoints due to whatever reason.
I guess some of you have allready noticed that you sometimes get automatically transformed to a “supergroup” (no way back) which will provide you with additional features (activating one of them starting the convertion also 
The only usefull feature I guess for us is the ChatID+Topic stuff.
I simply tried to solve it the same way like here:
with some Blocky-Code
uid: telegram_with_chatID_topicID
tags:
- marketplace:131112
props:
parameters: []
parameterGroups: []
timestamp: Apr 4, 2024, 1:19:14 PM
component: BlockLibrary
config:
name: Telegram with ChatID+TopicID
slots:
blocks:
- component: BlockType
config:
args0:
- name: MESSAGE
type: input_value
- name: BOT
type: input_value
- name: CHAT_ID
type: input_value
- name: TOPIC_ID
type: input_value
colour: "#2ea5d8"
helpUrl: ""
inputsInline: true
lastDummyAlign0: right
message0: send on Telegram %1 from bot %2 with chat id %3 & topic %4
nextStatement: ""
previousStatement: ""
tooltip: ""
type: message
slots:
code:
- component: BlockCodeTemplate
config:
template: >
{{utility:things}}.getActions('telegram', {{input:BOT}}).sendTelegram({{input:CHAT_ID}}_{{input:TOPIC_ID}}, {{input:MESSAGE}});
toolbox:
- component: PresetInput
config:
fields:
TEXT: What's up?
name: MESSAGE
shadow: true
type: text
- component: PresetInput
config:
name: BOT
shadow: true
type: oh_thing
- component: PresetInput
config:
fields:
NUM: 123
name: CHAT_ID
shadow: true
type: math_number
- component: PresetInput
config:
fields:
NUM: 45
name: TOPIC_ID
shadow: true
type: math_number
utilities:
- component: UtilityJavaType
config:
javaClass: org.openhab.core.model.script.actions.Things
name: things
But it is not working. Could we Update the Binding to support such TOPIC_IDs ?