New Telegram Binding - Tester and Feedback welcome

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 :person_shrugging:

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 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…

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 :wink:

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
  - marketplace:131112
  parameters: []
  parameterGroups: []
timestamp: Apr 4, 2024, 1:19:14 PM
component: BlockLibrary
  name: Telegram with ChatID+TopicID
    - component: BlockType
          - 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
          - component: BlockCodeTemplate
              template: >
                {{utility:things}}.getActions('telegram', {{input:BOT}}).sendTelegram({{input:CHAT_ID}}_{{input:TOPIC_ID}}, {{input:MESSAGE}});
          - component: PresetInput
                TEXT: What's up?
              name: MESSAGE
              shadow: true
              type: text
          - component: PresetInput
              name: BOT
              shadow: true
              type: oh_thing
          - component: PresetInput
                NUM: 123
              name: CHAT_ID
              shadow: true
              type: math_number
          - component: PresetInput
                NUM: 45
              name: TOPIC_ID
              shadow: true
              type: math_number
    - component: UtilityJavaType
        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 ?