Telegram client soll reboot des raspberry auslösen

Begonnen von wowogiengen, 31 Mai 2022, 22:43:21

Vorheriges Thema - Nächstes Thema

wowogiengen

Hallo,
ich möchte durch Senden von "mach neu" an den Telegram Bot des raspberry einen reboot des Systems auslösen.
Dazu habe ich folgendes implementiert:

defmod teleBotRestartPi DOIF ([teleBot:msgText] eq "mach neu") (set teleBot _msg Mach ich;; {system("reboot")};;)
attr teleBotRestartPi .* 1
attr teleBotRestartPi room Büro,System

setstate teleBotRestartPi initialized
setstate teleBotRestartPi 2022-05-31 22:27:09 cmd 0
setstate teleBotRestartPi 2022-05-31 22:27:09 mode enabled
setstate teleBotRestartPi 2022-05-31 22:27:09 state initialized


leider funktioniert das nicht immer, obwohl die Nachricht im Reading drin steht.

Habe gerade gesehen, dass es dann nicht geht, wenn zweimal hintereinander das gleiche "mach neu" gesendet wurde.
Funktioniert das dann mit dem DoIf nicht, und ich sollte ein notify verwenden?

Damian

Im FHEM-Modus musst du für eine Wiederholung ohne Zustandsänderung das Attribut do always setzen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

wowogiengen

Zitat von: Damian am 31 Mai 2022, 22:45:25
Im FHEM-Modus musst du für eine Wiederholung ohne Zustandsänderung das Attribut do always setzen.

Hallo, das scheint es aber auch nicht zu sein. Hier nochmal die beiden devices als ganzes:
Hier habe ich die sensiblen Daten ausgesternt und die States gleich ganz weggelassen.
defmod teleBot TelegramBot
attr teleBot .* 1
attr teleBot allowChannels 1
attr teleBot allowUnknownContacts 1
attr teleBot cmdFavorites Short
attr teleBot cmdKeyword ok
attr teleBot cmdRestrictedPeer ********
attr teleBot defaultPeer ********
attr teleBot event-min-interval .*:900
attr teleBot event-on-change-reading .*
attr teleBot event-on-update-reading .*
attr teleBot favorites Set RolladenWohnzimmer pct 0 ;;Set RolladenWohnzimmer pct 60;;set HzgAktorBuero on;;set HzgAktorBuero off;;set HzgSetBad desired-temp 29;;set HzgSetBad desired-temp 22;;set AlleRolladen Zu;;set AlleRolladen Auf
attr teleBot pollingTimeout 60
attr teleBot pollingVerbose 1_Digest
attr teleBot room telebot,Büro,System
attr teleBot verbose 5



Und :

defmod teleBotRestartPi DOIF ([teleBot:msgText] eq "mach neu") (set teleBot _msg Mach ich;; {system("/sbin/reboot")};;)
attr teleBotRestartPi .* 1
attr teleBotRestartPi do always
attr teleBotRestartPi room Büro,System

setstate teleBotRestartPi cmd_1
setstate teleBotRestartPi 2022-05-31 23:10:26 Device teleBot
setstate teleBotRestartPi 2022-05-31 23:10:27 cmd 1
setstate teleBotRestartPi 2022-05-31 23:10:27 cmd_event teleBot
setstate teleBotRestartPi 2022-05-31 23:10:27 cmd_nr 1
setstate teleBotRestartPi 2022-05-31 23:10:26 e_teleBot_msgText mach neu
setstate teleBotRestartPi 2022-05-31 23:10:27 error set teleBot _msg Mach ich;; {system("/sbin/reboot")};;: -1
setstate teleBotRestartPi 2022-05-31 22:50:24 mode enabled
setstate teleBotRestartPi 2022-05-31 23:10:27 state cmd_1


Also, obwohl attr teleBotRestartPi do always gesetzt ist, brauche ich immer eine dummy-Message bevor ich den "mach neu" erkannt bekomme. Danach scheint der raspy dann aber auch neu zu starten

Damian

An den Lists kann ich kein Problem erkennen.

Was soll das für ein Attribut sein?

attr teleBotRestartPi .* 1
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Per

attr teleBot event-on-change-reading .*
attr teleBot event-on-update-reading .*

Damit kommt bei gleicher Message kein Event und weder DOIF noch notify lösen aus.

MadMax-FHEM

Ich würde auch auf jeden Fall allowUnknownContacts auf 0 setzen!!

Siehe Sicherheitshinweise im Wiki...

Und: ich würde prüfen, von wem die Reboot Message kommt! Ansonsgen kann ja jeder, der deinen Bot kennt deinen PI booten...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

wowogiengen

#6
Zitat von: Damian am 31 Mai 2022, 23:27:10
An den Lists kann ich kein Problem erkennen.

Was soll das für ein Attribut sein?

attr teleBotRestartPi .* 1
Ehrlich gesagt, weiß ich es auch nicht  ???. Das Attribut ist nur dann sichtbar, wenn ich Raw Definition anklicke...
Bei einem list kommt das hier:


Internals:
   DEF        ([teleBot:msgText] eq "mach neu") (set teleBot _msg Mach ich; {system("/sbin/reboot")};)
   FUUID      5ce84ec0-f33f-a625-3d24-5e9478ceab654dec
   MODEL      FHEM
   NAME       teleBotRestartPi
   NOTIFYDEV  teleBot,global
   NR         80
   NTFY_ORDER 50-teleBotRestartPi
   STATE      cmd_1
   TYPE       DOIF
   VERSION    24905 2021-09-01 18:35:54
   READINGS:
     2022-05-31 23:14:52   Device          teleBot
     2022-05-31 23:14:52   cmd             1
     2022-05-31 23:14:52   cmd_event       teleBot
     2022-05-31 23:14:52   cmd_nr          1
     2022-05-31 23:14:52   e_teleBot_msgText mach neu
     2022-05-31 23:14:52   error           set teleBot _msg Mach ich; {system("/sbin/reboot")};: -1
     2022-05-31 22:50:24   mode            enabled
     2022-05-31 23:14:52   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       teleBot:
         0:
           msgText    ^teleBot$:^msgText:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'teleBot','msgText') eq "mach neu"
   do:
     0:
       0          set teleBot _msg Mach ich; {system("/sbin/reboot")};
     1:
   helper:
     DEVFILTER  ^global$|^teleBot$
     NOTIFYDEV  global|teleBot
     event      msgId: 747,msgText: mach neu
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   teleBot
     timerevent msgId: 747,msgText: mach neu
     triggerDev teleBot
     timerevents:
       msgId: 747
       msgText: mach neu
     timereventsState:
       msgId: 747
       msgText: mach neu
     triggerEvents:
       msgId: 747
       msgText: mach neu
     triggerEventsState:
       msgId: 747
       msgText: mach neu
   internals:
   perlblock:
   readings:
     all         teleBot:msgText
   trigger:
   uiState:
   uiTable:
Attributes:
   do         always
   room       Büro,System


wowogiengen

Zitat von: Per am 31 Mai 2022, 23:30:09
attr teleBot event-on-change-reading .*
attr teleBot event-on-update-reading .*

Damit kommt bei gleicher Message kein Event und weder DOIF noch notify lösen aus.
Und wie löse ich das Dilemma? Beide Attribute entfernen?

MadMax-FHEM

#8
Zitat von: wowogiengen am 01 Juni 2022, 18:15:53
Und wie löse ich das Dilemma? Beide Attribute entfernen?

Ja.

Und/oder lesen was sie tun und dann nach Bedarf setzen.

Beide in genau dieser Definition ist als hättest du keines der beiden...

EDIT: wobei ich das hier https://forum.fhem.de/index.php/topic,127871.msg1223602.html#msg1223602 ja wichtiger finde...

EDIT: und verbose 5 ist hoffentl. auch zur zum Debuggen?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Damian

Ich würde mir die Eventabfolge im Event-Monitor anschauen.

Du löst mit set teleBot ein Event aus, auf das du reagierst, vielleicht ist da etwas im Argen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

wowogiengen

Hallo @MadMax-FHEM und @Damian,
das mit den erlaubten Kontakten habe ich bereits korrigiert, und auch das Verbose sitzt bei mir normalerweise auf 1 oder sogar 0...

Das mit dem Lesen der FHEM-Doku ist so eine Sache. Obwohl ich auch aus der Informatik-Ecke komme und selber programmiere, erschliessen sich mir manche Ausführungen nicht. Mir scheint, als ob da sehr viel vorausgesetzt wird, was für Anfänger, die mal schnell was machen wollen nicht immer leicht ist...

Vielleicht kannst du mir die beiden Attribute mal erklären?
Viel Grüße
und Danke im Vorraus
Wolfgang

MadMax-FHEM

#11
https://wiki.fhem.de/wiki/Event-on-change-reading
Events nur für die aufgeführten Readings und nur, wenn sich der Wert geändert hat...


https://wiki.fhem.de/wiki/Event-on-update-reading
Event auch wenn sich der Reading-Wert nicht geändert hat, "hebt" also event-on-change wieder auf...

Daher hattest du:

event-on-change-reading .*
Für alle Readings ( -> .* ) Events nur, wenn sich der Wert verändert hat.

event-on-update-reading .*
Für alle Readings ( -> .* ) auch Events, selbst wenn sich der Wert nicht geändert hat...

EDIT: sinnvolle Anwendung
event-on-change-reading .*

event-on-update-reading power

Also erst mal alle Readings nur bei Änderung aber das power Reading erzeugt auch Events, selbst wenn sich der Wert nicht geändert hat. Z.B. für Logging oder Automatisierungen, die öfter reagieren soll...

event-on-change-reading none -> blockt alle Events (außer es gibt ein Reading "none" ;)  )
event-on-update-reading power -> es gibt aber für power dennoch Events...

usw.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

wowogiengen

Hallo Joachim,
danke für die Info.
Für meine Anwendung hier brauch ich also beide nicht...
Danke