If you do have an idea how it can be improved then please do raise a ticket with the suggestion. I am going through the tickets for this binding and making changes to the binding at the moment. Two extra things to comment are.
Be aware that using Thread::sleep(1000) in a rule is very bad, search this forum for why as it can block or delay all rules running.
Be aware of the bug/issue I linked above that I plan on making the changes soon to have that fixed.
Since your logs miss the extra lines due to the null causing the rule to stop in its tracks, this is an issue that should be looked at to see if it can be handled automatically. Actions should not throw exceptions and should catch and handle them all, since that appears to not be the case this is an issue. I will look at it as there is also another complaint about the binding throwing exceptions, see here.
@rossko57: Thank you for providing the link, I didn’t find this during my search The answer is included there, at least for my problem. sendTelegramAnswer accepts a ChatID, this solves my problem. This isn’t covered in the docs, I’ll try to add this info there.
My solution is now: getActions("telegram","telegram:telegramBot:BOT").sendTelegramAnswer(12345678L,TelegramBot_ReplyId.state.toString, "Test Yes")
Notice the additional ChatID in the sendTelegramAnswer part.
@matt1 Thanks about the info with the sleep command. This was just a testing rule, I do not use it in production.
Currently I’m not able to produce the stop in my rule again. If I revert all back to the beginning, the rule throws a WARN but continues. Before my testing, the rule stopped. There was nothing in the DEBUG log.
It is in the docs but it is easy to overlook it if your not a programmer used to seeing what’s called overloaded functions. This is where it can be very useful for a non programmer to explain it in clear and easy terms. See here I find this pretty clear and there is more mention at the top of the action list.
All the actions can have the chat id’s added as the first arguement, or left out as you did to be sent to the bots group.
OK I found and fixed a problem in the binding since your debug level logs helped narrow it right down so thank you for reporting this…
Also the only reason you found that it worked was that you had the chatId that worked FIRST in your bot, if you had the second one first, it would not have worked as when it reaches the chatId that fails, it stops trying on the remaining chatId’s.
In the future the logs will get a WARN and the rule will not halt like it was for you. However it will not continue processing the groups ChatIds when one fails and the BOOLEAN result that the action returns will be false when any of them fails. For it to return true all chatIds must work.
If anyone notices an action that halts the rule dead, then please raise a github ticket when your sure that it is not another line in your rule causing it.
The answer is included there, at least for my problem.