Telegram instant messaging TelegramBot - Empfangen und Senden per FHEM

[RomanticBoy83]

Hallo an alle TelegramBenutzer
Ich habe festgestellt, dass das Modul leider immer an den "Peer" antwortet.

Problem: Wir(ganze Familie) sprechen den Bot in einer TelegramGruppe an. Somit kann ich alle Aktivitäten direkt nachvollziehen. Leider schickt er die Liste von Favoriten und auch die Bestätigung,trotz gesetztem defaultPeer, immer an den persönlichen Chat. Über defaultPeerCopy=1 erhält man als Mitglied der Gruppe die Nachricht selber zweimal, was schon unschön ist, und muss den Chat wechseln, was furchtbar unschön ist.
Ein anderer Ansatz nur über die Attribute kommt mir momentan nicht in den Sinn um das Problem zu lösen.

Ansatz: Eine Abfrage im Modul-Code würde Gruppen bevorzugen. (Vermutlich Code-Zeile 2079)

Code Auswählen Erweitern

if(msgChat != null){
  antwort an msgChat
}else{
  antwort an msgPeerId
}

Frage: Wäre eine solche Änderung möglich? Und zweitens, auch sinnig - also direkt in den Chat zu antworten wo auch die Nachricht herkommt - oder sollte man das konfigurierbar machen über ein weiteres Attribut - z.B. PreferResponseToChat=[01]?

Bei mir schaut das jetzt so aus - ich sende grundsätzlich immer an die Gruppe wenn es diese gibt:

Code Auswählen Erweitern


# COMMAND Handling (only if no fileid found
    $mpeernorm = TelegramBot_GetFullnameForChat( $hash, $chatId ) if ($chatId);
    Telegram_HandleCommandInMessages( $hash, $mpeernorm, $mtext, $mid ) if ( ! defined( $mfileid ) );


[viegener]

Hallo an alle TelegramBenutzer
Ich habe festgestellt, dass das Modul leider immer an den "Peer" antwortet.

Problem: Wir(ganze Familie) sprechen den Bot in einer TelegramGruppe an. Somit kann ich alle Aktivitäten direkt nachvollziehen. Leider schickt er die Liste von Favoriten und auch die Bestätigung,trotz gesetztem defaultPeer, immer an den persönlichen Chat. Über defaultPeerCopy=1 erhält man als Mitglied der Gruppe die Nachricht selber zweimal, was schon unschön ist, und muss den Chat wechseln, was furchtbar unschön ist.
Ein anderer Ansatz nur über die Attribute kommt mir momentan nicht in den Sinn um das Problem zu lösen.

Ansatz: Eine Abfrage im Modul-Code würde Gruppen bevorzugen. (Vermutlich Code-Zeile 2079)

Code Auswählen Erweitern

if(msgChat != null){
  antwort an msgChat
}else{
  antwort an msgPeerId
}

Frage: Wäre eine solche Änderung möglich? Und zweitens, auch sinnig - also direkt in den Chat zu antworten wo auch die Nachricht herkommt - oder sollte man das konfigurierbar machen über ein weiteres Attribut - z.B. PreferResponseToChat=[01]?

Bei mir schaut das jetzt so aus - ich sende grundsätzlich immer an die Gruppe wenn es diese gibt:

Code Auswählen Erweitern


# COMMAND Handling (only if no fileid found
    $mpeernorm = TelegramBot_GetFullnameForChat( $hash, $chatId ) if ($chatId);
    Telegram_HandleCommandInMessages( $hash, $mpeernorm, $mtext, $mid ) if ( ! defined( $mfileid ) );


Ich verstehe Dein Problem und ja es gibt momentan dazu keine Möglichkeit. Eigentlich ist es sogar bewusst so, dass die Antwort an den Benutzer geht, denn
- Bei mir will nicht jeder alle Nachrichten wegclicken, wenn irgendjemand anders mit dem telegrambot spricht, also passiert das im privaten chat
- Aus Sicherheitsgründen würde ich immer die persönliche ID des Benutzers überprüfen für Kommandos und nicht die Gruppe/ den Chat

Ergo, um das umzusetzen müsste man wohl etwas mehr ändern als nur rund um Zeile 2079 
Es müsste sowohl chatId als auch PeerID für die Prüfung und weitere Bearbeitung aufgehoben werden und beides geprüft werden

Ich werde mal schauen wie sich das realisieren liesse, würdest Du den Test übernehmen?

[DeeSPe]

Ich werde mal schauen wie sich das realisieren liesse, würdest Du den Test übernehmen?

Ich bin begeistert was Du in letzter Zeit so alles erweitert hast an diesem Modul. Und Du auch auf Wünsche eingehst!!!
Selbst nutze ich das Modul schon seit ca. einem halben Jahr und würde um nichts in der Welt wieder yowsup benutzen wollen!
Das mit den Keyboards finde ich ja mal megageil! Mal schauen wann ich mal Zeit finde das bei mir umzusetzen! Mich hält gerade die Programmierung eines neuen Moduls davon ab!

Drum hiermit einfach nur mal mein persönlicher Dank an Dich und Deine Entwicklung an dem Modul!
Einfach Klasse! Weiter so!

Gruß
Dan

[viegener]

Ergo, um das umzusetzen müsste man wohl etwas mehr ändern als nur rund um Zeile 2079 
Es müsste sowohl chatId als auch PeerID für die Prüfung und weitere Bearbeitung aufgehoben werden und beides geprüft werden

Ich werde mal schauen wie sich das realisieren liesse, würdest Du den Test übernehmen?

Angespornt durch das Lob habe ich das mal in einer ersten Version eingebaut - findet sich in github

Es gibt ein Attribut cmdRespondChat wenn das gesetzt ist sollten Antworten im chat erfolgen

Vielleicht kann das jemand ausprobieren, erste Tests bei mir waren soweit erfolgreich

[RomanticBoy83]

Ich habe noch einmal den code angeschaut!
Fazit - Der Abgleich mit cmdRestrictedPeer ist natürlich wünschenswert und sollte so bestehen bleiben. Ich habe mir deine Lösung noch nicht angeschaut - aber hier ist mein Ansatz aufgrund deiner Anmerkungen.

Lösungsansatz: ab Zeile 1131 ist die Abfrage nach dem Peer bereits gelaufen. Jedoch ist hier die $chatID nicht vorhanden (oder aus dem Reading holen) und müsste bis hier hin durchgereicht werden. Eine zusätzliche Variable in der sub Telegram_HandleCommandInMessages($$$$) könnte hier helfen und in den entsprechenden Methoden ersetzt werden.

Code Auswählen Erweitern


my destinyPeer = AttrVal($name,'cmdRespondChat',undef) ? $chatID : $mpeernorm


...würdest Du den Test übernehmen?

Natürlich würde ich mir mal ein paar Testroutinen dafür überlegen und diese durchspielen! (Hatte ich zwar noch nie vorher hier gemacht, aber dazulernen möchte ich natürlich immer)

[RomanticBoy83]

OhOh - ich glaube ich werde noch gehängt! Ich wollte hier keine Unannehmlichkeiten bereiten!
Wir haben ein wenig aneinander vorbei geredet. Ich habe mich schon gewundert weshalb du so viele Änderungen getätigt hast.

Code Auswählen Erweitern

+  return ( undef, 1 )  if ( ( $mchatnorm ) && ( ! TelegramBot_checkAllowedPeer( $hash, $mchatnorm, $mtext ) ) );
in Zeile 857 wird jetzt jedem Peer des Chats erlaubt Befehle zu senden - dass steht auf meinem ersten Testzettel als nicht erlaubt!

1)	Der Bot Antwortet persönlich wenn ich ihn persönlich kontaktiere und ich erlaubt bin(cmdRestrictedPeers).
2)	Der Bot sendet die Meldung des Versuches an defaultPeer wenn ich ihn persönlich kontaktiere und ich nicht erlaubt bin(cmdRestrictedPeers)
3)	Der Bot Antwortet in der Gruppe wenn ich ihn in der Gruppe kontaktiere und ich erlaubt bin.
4)	Der Bot sendet die Meldung des Versuches an defaultPeer wenn ich ihn in der Gruppe kontaktiere und ich nicht erlaubt bin.

5)	Der Bot Antwortet nicht im Chat wenn cmdRespondChat=0

Zum besseren Verständnis:
Ich gehen davon aus, dass wenn ich jemanden Anschreibe er mir auf dem selben Weg antwortet. Er soll aber natürlich dennoch prüfen, ob er mir antworten darf. Meine Wunsch der Änderung beschränkte sich ausschließlich darauf wohin die Antwort gesendet wird. Aus diesem logischen Grunde müsste das neu Attribut theoretisch auch default=1 sein - ist aber nur eine Feinheit wie ich es aus Logiksicht machen würde.

[viegener]

OhOh - ich glaube ich werde noch gehängt! Ich wollte hier keine Unannehmlichkeiten bereiten!
Wir haben ein wenig aneinander vorbei geredet. Ich habe mich schon gewundert weshalb du so viele Änderungen getätigt hast.

Code Auswählen Erweitern

+  return ( undef, 1 )  if ( ( $mchatnorm ) && ( ! TelegramBot_checkAllowedPeer( $hash, $mchatnorm, $mtext ) ) );
in Zeile 857 wird jetzt jedem Peer des Chats erlaubt Befehle zu senden - dass steht auf meinem ersten Testzettel als nicht erlaubt!

Nein, das heisst im Chat wird nur ein Kommando erlaubt, wenn sowohl der peer als auch der chat zugelassen ist.
Die Rückgabe undef heisst in diesem Fall, dass keine Ausführung erlaubt ist.

1)	Der Bot Antwortet persönlich wenn ich ihn persönlich kontaktiere und ich erlaubt bin(cmdRestrictedPeers).
2)	Der Bot sendet die Meldung des Versuches an defaultPeer wenn ich ihn persönlich kontaktiere und ich nicht erlaubt bin(cmdRestrictedPeers)
3)	Der Bot Antwortet in der Gruppe wenn ich ihn in der Gruppe kontaktiere und ich erlaubt bin.
4)	Der Bot sendet die Meldung des Versuches an defaultPeer wenn ich ihn in der Gruppe kontaktiere und ich nicht erlaubt bin.

5)	Der Bot Antwortet nicht im Chat wenn cmdRespondChat=0

Zum besseren Verständnis:
Ich gehen davon aus, dass wenn ich jemanden Anschreibe er mir auf dem selben Weg antwortet. Er soll aber natürlich dennoch prüfen, ob er mir antworten darf. Meine Wunsch der Änderung beschränkte sich ausschließlich darauf wohin die Antwort gesendet wird. Aus diesem logischen Grunde müsste das neu Attribut theoretisch auch default=1 sein - ist aber nur eine Feinheit wie ich es aus Logiksicht machen würde.

Die Liste ist im wesentlichen dass was ich implementieren wollte. Es gibt nur kleine Abweichungen bei 3 und 4

3) Antwort in der Gruppe nur wenn sowohl Gruppe als auch peer erlaubt ist
4) dito - aber umgekehrt wie oben

Also keine Sorge, die Änderungen waren aber nötig, weil ich beide Informationen peer und chat an allen Stellen brauche (zusätzlich wurde noch ein weiteres Reading gebraucht, weil ich mit einem meiner notifies nicht mehr arbeiten konnte)

Hast Du es denn mal ausprobiert?

[oli82]

Hi.

Jetzt hab ich doch eine Frage zu den Inline Keyboards.
Ist es eigentlich möglich, dass mir der Bot bei einem Event eine Nachricht mit Inline-Keyboard schickt? Also z.b.

Code Auswählen Erweitern

Alarm ausgelöst
<STOP><KAMERA>

So wie ich das verstanden habe, reagiert der Bot ja nur auf Befehle, die er empfängt und bietet dann zu diesem Befehl das Keyboard an.
Danke für die Hilfe.

[Prof. Dr. Peter Henning]

Natürlich geht das - einfach mit queryInline und korrekter Syntax.

LG

pah

[oli82]

Danke. Mit der Info kann ich was anfangen. Hab es nun auch in der commandref gefunden und wohl mehrfach überlesen!

[bjoernbo]

Hallo, ich habe mal eine Frag im Zusammenhang mit TelegramBot & DOIF.

Ich habe mir für jeden Raum ein DOIF erstellt. Immer wenn die Luftfeuchtigkeit >60% ist bekomme ich und meine Frau eine Nachricht, dass es Zeit ist zum lüften. Das Problem ist nun allerdings, das wir diese Nachricht jede Minuten bekommen. Entweder weil die Luftfeuchte jetzt auf 62% oder weiterhin bei 61%. Das hat nun dazugeführt, dass ich die Benachrichtigung im Bezug auf die Leuftfeuchte deakiviert habe, da meine Frau einen "föhn" bekommen hat, verständlicherweise.

Hat jem. von euch selbiges Problem gehabt? und wenn ja, wie wurde es gelöst!

Es reicht mir, wenn er die Nachricht nur einmal schickt, dass ich Lüften soll.

Danke.

[DeeSPe]

Hallo, ich habe mal eine Frag im Zusammenhang mit TelegramBot & DOIF.

Ich habe mir für jeden Raum ein DOIF erstellt. Immer wenn die Luftfeuchtigkeit >60% ist bekomme ich und meine Frau eine Nachricht, dass es Zeit ist zum lüften. Das Problem ist nun allerdings, das wir diese Nachricht jede Minuten bekommen. Entweder weil die Luftfeuchte jetzt auf 62% oder weiterhin bei 61%. Das hat nun dazugeführt, dass ich die Benachrichtigung im Bezug auf die Leuftfeuchte deakiviert habe, da meine Frau einen "föhn" bekommen hat, verständlicherweise.

Hat jem. von euch selbiges Problem gehabt? und wenn ja, wie wurde es gelöst!

Es reicht mir, wenn er die Nachricht nur einmal schickt, dass ich Lüften soll.

Danke.

Ganz einfach ein userReading erstellen und dieses im DOIF triggern.

Code Auswählen Erweitern

attr <HUMIDITY-SENSOR> userReadings lueften:humidity.* {ReadingsNum($name,"humidity",0)>=60?1:0}
Das DOIF dann auf lueften:1.

Gruß
Dan

EDIT: Beim erneuten lesen war mir aufgefallen dass ich <= statt >= verwendet hatte. Habe es geändert!

[MadMax-FHEM]

Hallo, ich habe mal eine Frag im Zusammenhang mit TelegramBot & DOIF.

Ich habe mir für jeden Raum ein DOIF erstellt. Immer wenn die Luftfeuchtigkeit >60% ist bekomme ich und meine Frau eine Nachricht, dass es Zeit ist zum lüften. Das Problem ist nun allerdings, das wir diese Nachricht jede Minuten bekommen. Entweder weil die Luftfeuchte jetzt auf 62% oder weiterhin bei 61%. Das hat nun dazugeführt, dass ich die Benachrichtigung im Bezug auf die Leuftfeuchte deakiviert habe, da meine Frau einen "föhn" bekommen hat, verständlicherweise.

Hat jem. von euch selbiges Problem gehabt? und wenn ja, wie wurde es gelöst!

Es reicht mir, wenn er die Nachricht nur einmal schickt, dass ich Lüften soll.

Danke.

@DeeSPe: hmm, sehr elegante Lösung. Wieder was gelernt und eine neue/weitere Möglichkeit solche Dinge zu lösen gefunden!

Aktuell merke ich mir in einem Dummy für alle Geräte/Nachrichten (für die ich was schicken will) ob bereits eine verschickt wurde:

Z.B. ist dann ReadingsName der Geräte-/Kanalname für den geschickt werden kann/soll und der Wert dann ob schon verschickt wurde.

Code Auswählen Erweitern


Internals:
   CHANGED
   NAME       dmSignalMessageStatusTelegramBot
   NR         147
   STATE      ???
   TYPE       dummy
   Readings:
     2017-01-06 13:33:13   Aussenthermometer_BatState none
     2017-01-06 04:30:39   Fenster_EssZi_BatState none
     2017-01-06 04:30:13   Fenster_FabiZi_BatState none
     2017-01-06 01:00:28   Fenster_Kueche_BatState none
     2016-11-14 16:45:27   Fenster_SchlaZi_BatState low
     2017-01-06 04:31:01   Fenster_WoZi_BatState none
     2016-12-12 08:02:58   Hauptdisplay_BatState none
     2017-01-06 13:34:08   Heizkoerperthermostat_EssZi_BatState none
     2017-01-06 13:35:14   Heizkoerperthermostat_FabiZi_BatState none
     2017-01-06 13:35:04   Heizkoerperthermostat_Kueche_BatState none
     2016-12-22 10:14:33   Heizkoerperthermostat_SchlaZi_BatState none
     2016-12-27 11:58:02   Heizkoerperthermostat_SchlaZi_State none
     2017-01-06 13:34:22   Heizkoerperthermostat_WoZi_BatState none
     2017-01-04 16:40:37   Steckdose_FabiZi_SchreibTisch none
     2017-01-06 12:00:48   Wandthermostat_Bad_BatState none
     2017-01-06 11:02:52   Wandthermostat_EssZi2_BatState none
     2017-01-06 11:50:26   Wandthermostat_EssZi_BatState none
     2017-01-06 13:34:44   Wandthermostat_FabiZi2_BatState none
     2016-12-15 07:57:34   Wandthermostat_FabiZi2_State none
     2017-01-06 13:30:17   Wandthermostat_FabiZi_BatState none
     2017-01-06 09:47:57   Wandthermostat_Kueche_BatState none
     2017-01-06 13:15:38   Wandthermostat_SchlaZi_BatState none
     2016-12-15 07:27:34   Wandthermostat_SchlaZi_State none
     2017-01-02 06:18:35   Wandthermostat_WC_BatState none
     2017-01-06 12:47:42   Wandthermostat_WoZi_BatState none


So kann ich auch prüfen, wann zuletzt verschickt wurde ReadingsAge des Wertes für das jeweilige Gerät und auch verschiedene Level, also es wurde ein Hinweis verschickt bzw. es wurde bereits eine Warnung verschickt (Wert: information / warning etc.).

In einer Sub die dann beispielsweise von den Luftfeuchtewerten getriggert wird kann dann auch zusätzlich geprüft werden, ob zwar eine Nachricht verschickt wurde aber das Fenster immer noch zu ist -> dann schicke eine Warnung, wenn ReadingsAge größer 15min oder so...

Also so mache ich das bei meiner Waschmaschine: fertig Meldung einmalig und Erinnerung(en), dass noch geleert werden muss alle 15min

Bzw. verschicke ich so mehrstufige Nachrichten (Information/Warnung) bei meinen Batteriemeldungen.

Für manche Geräte (Homematic) berechne ich die "Prozent voll" und bei Unterschreitung eines bestimmten Wertes schicke ich eine Information (damit ich schon mal Batterien kaufen kann   ) und dann bei sehr gering oder der eigenen "low" oder gar bei Ausfall eine Warnung, dass jetzt echt gewechselt werden muss...

Wie so oft:

viele Wege führen ans Ziel...
...jeder muss seinen eigenen finden

Gruß, Joachim

[DeeSPe]

@DeeSPe: hmm, sehr elegante Lösung. Wieder was gelernt und eine neue/weitere Möglichkeit solche Dinge zu lösen gefunden!

Schön, so soll es ja sein hier im Forum!

Aktuell merke ich mir in einem Dummy für alle Geräte/Nachrichten (für die ich was schicken will) ob bereits eine verschickt wurde:

Z.B. ist dann ReadingsName der Geräte-/Kanalname für den geschickt werden kann/soll und der Wert dann ob schon verschickt wurde.

Wozu immer diese ganzen dummy(s) gebraucht werden verstehe ich nicht.
Readings kann ich doch mit setreading beliebig in jedem Device setzen!
Also könntest Du Dir die Information ob und wann gesendet wurde auch direkt in das jeweilige ROOMMATE/GUEST Device schreiben.

Meine Devise ist immer: So viele Devices wie nötig, aber so wenige wie möglich!

Gruß
Dan

Gruß
Dan

[MadMax-FHEM]

Wozu immer diese ganzen dummy(s) gebraucht werden verstehe ich nicht.
Readings kann ich doch mit setreading beliebig in jedem Device setzen!
Also könntest Du Dir die Information ob und wann gesendet wurde auch direkt in das jeweilige ROOMMATE/GUEST Device schreiben.

Meine Devise ist immer: So viele Devices wie nötig, aber so wenige wie möglich!

Gruß
Dan

Ich habe halt kein zentrales "Gerät" für sowas also kein ROOMMATE/GUEST etc.
Direkt in den Bot wollte ich es nicht schreiben...
...aber hier der Vorteil (für mich) ich habe ein "Gerät"/Device wo ich einen Überblick über die "Nachrichtenlage" habe

Aber auch das mit den Readings werde ich mir merken (Danke!)...
...allerdings eher für zukünftige Umsetzungen oder bei der nächsten "Renovierung"

Denn: never change a running system (without good reasons)...

Gruß, Joachim