Mitteilung an alle nach vorheriger Anfrage (telegram, msgDialog, ROOMMATES)

Begonnen von Frieder, 21 September 2021, 20:49:53

Vorheriges Thema - Nächstes Thema

Frieder

Hallo allerseits,
Ich versuche seit ein paar Tagen ein kleines Projekt umzusetzen, komme aber nicht mehr weiter.

Problem: es gibt hier einen Boiler, der eingeschaltet werden muss, um warmes Wasser zu bekommen. Nach dem Einschalten dauert es eine Weile, bis er wirklich warm ist..

Idee: Boiler kommt an eine Funksteckdose, die per Telegram eingeschaltet wird. An dem Boiler ist ein Temperatur sensor per 1wire und sobald das Wasser warm ist bekommen alle die wollen eine entsprechende Nachricht per Telegram.

Bisher habe ich folgendes gemacht:
Funksteckdose funktioniert
Temperatursensor funktioniert
Einschalten der Steckdose per telegram über msgDialog funktioniert.
Jetzt fehlt nur noch die Benachrichtigung, sobald das Wasser warm ist. Es soll jeder, der die Dose geschaltet hat um warmes Wasser zu machen informiert werden. Aber woher weiß fhem 20 min später noch wer das war? Vielleicht ein attribut in roommate (zB. Mood). Wäre dann aber schwer zu erweitern falls noch mehr Dialoge kommen. Außerdem weiß ich nicht, wie ich jedem roommate mit bestimmter mood eine Nachricht schicken könnte...

Bin offen für Ideen 😄

rabehd

Kennst Du den Absender der Telegramnachricht nicht?
Auch funktionierende Lösungen kann man hinterfragen.

Frieder

Doch, kenne ich. Aber ich möchte ja erst nach einer Weile antworten. Bis dahin können ja auch andere Nachrichten beim Bot eingegangen sein, und der Absender kann auch schon wieder andere Nachrichten geschickt haben!

MadMax-FHEM

#3
Zusammen mit dem Einschalten der Steckdose:


setreading TelegramBotDevice willwarmwassernachricht absender


Soll heißen in dem Reading willwarmwassernachricht des TelegramBotDevice steht dann der, der die Nachricht will, wenn das Wasser warm ist.

Notify auf "Wasser ist warm" -> send msg an ReadingsVal("TelegramBotDevice", "willwarmwassernachricht", "defaultPeer") Wasser ist warm

Wenn mehrere die Anforderung stellen können, dann eben mehrere Peers im Reading speichern z.B. Komma-separiert o.ä.

Readingname willwarmwassernachricht ist nat. nur ein Beispiel... ;)

EDIT: alternativ kannst du die "Anfragenden" auch mittels setreading im notify-Device (oder wenn es unbedingt sein muss in einem dummy) "speichern"...

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)

yersinia

Im Grunde wirst du wahrscheinlich über etwas perl-code in der myUtils nicht hinwegkommen - oder via notify, weil
- du bekommst die Teilnehmer und die Nachricht via TelegramBot (readings msgText und msgPeerId) - und zwar unabhängig vom Boilerstatus bzw. weisst du zu diesem Zeitpunkt noch nicht, welcher Status der Boiler hat
- diese übergibst du einer Funktion, welche 1. den Boiler einschaltet (bzw prüft ob dieser schon eingeschaltet ist oder eingeschaltet werden muss) und 2. die peers sammelt und irgendwo abspeichert
- wenn Boiler fertig meldet, muss die Funktion wieder (oder eine andere) aufgerufen werden und die fertig-Meldung an alle sich gemeldeten peers zurückmelden
- danach müssen die gesammelten peers gelöscht werden

Was passiert wenn, der Boiler gerade fertig ist und jmd Warmwasser verlangt?

Du kannst eine Nachricht auch über den TelegramBot an mehrere peers gleichzeitg schicken, zB
set TelegramBotDevice message \@12345678 \@23456789 \@34567890 hier text den du senden willst
Dafür müssen die peers aber dem Bot bekannt sein - sprich: die peers müssen den Bot angesprochen haben bzw beigetreten sein (ist ein Spam-Schutz bei Telegram)
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Wernieman

Mal was anderes ...meinst Du, der Titel des Threades ist passend?

Siehe auch https://forum.fhem.de/index.php/topic,71806.0.html
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Frieder

#6
Hi,
Dank schon mal für alle Antworten!
Ein besserer Titel ist mir tatsächlich nicht eingefallen!

Es ist (glaube ich) sogar noch ein bisschen komplizierter, weil die Nachrichten über msgDialog reinkommen. Damit bekomme ich nur den Namen der ROOMMATES, die nach Warmwasser gefragt haben.
Der Weg von MadMax-FHEM klingt gut, funktioniert bisher auch bis zu dem Punkt, an dem ich das reading willwarmwassernachricht speichern will. Über
defmod Test_dialog msgDialog {\
  "test":{\
   "commands": \
   "{fhem('setreading teleBot willwarmwassernachricht $recipient')} " ,\
\
   "message": [ \
      "(%me%) " ,\
      "Dialog beendet."\
       ]\
  }\
}
attr Test_dialog allowed everyone


Wird im reading nur rr_bewohner gespeichert.
Könnte ich dort string mit den entsprechenden peers speichern, der sich mit jeder Anfrage verlängert (@bewohner1 @bewohner2), wäre das abschicken der Nachricht an alle nur noch ein kleines doif. Und natürlich das zurücksetzen des strings.
Bei den ROOMMATES ist der peer ja gespeichert unter dem Attribut msgContactPush (z. B. teleBot:@123459789). Das heißt, ich müsste darauf zugreifen und es stückeln... M

it den myutilis habe ich noch gar nichts gemacht...

MadMax-FHEM

#7
Hmm, ich nutze msgDialog nicht (oder selber "nachgebaut"?).

Einziges was mir einfällt wäre in dem Moment den peer aus dem TelegramDevice auslesen (ist halt mit einem möglichen Fehler behaftet, wenn 2 [oder mehr] Nachrichten gleichzeitig kommen):

statt $receipient:

my $Peer = ReadingsVal("teleBot", "msgPeer", "n.a.");


Weil im TelebotDevice sollte ja (trotzdem) der Peer stehen, der gesendet hat.

Abspeichern mehrerer in einem Reading, hmmm, evtl. so:


my $Peers = ReadingsVal("teleBot", "willwarmwassernachricht", "n.a.") . "," . $Peer;


oder


my $Peers = ReadingsVal("teleBot", "willwarmwassernachricht", "n.a.") . "," . ReadingsVal("teleBot", "msgPeer", "n.a.");


(evtl. das Reading "willwarmwassernachricht" in "wollenwarmwassernachricht" umbenennen ;)  )

Also auslesen der aktuellen Einträge und dann dranhängen (mit Komma getrennt) eines weiteren.
Abfangen müsste man noch, das erste Mal, weil ja dann noch nichts im Reading steht und n.a. zurück kommt und somit als erster "Peer" wieder hinterlegt würde...

Allerdings würde ich das ja in eine myUtils auslagern...
Vielleicht mal anschauen: https://wiki.fhem.de/wiki/99_myUtils_anlegen

EDIT: nutze auch ROOMMATES etc. nicht. Aber wenn es da eine Zuordnung zwischen rr_bewohner und dem jeweiligen Peer gibt, dann kann man das sicher auch dort auslesen. Wenn es ein Attribut ist: AttrVal("Devicename", "Attributname", "Ersatzwert")

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)

Beta-User

Zitat von: MadMax-FHEM am 22 September 2021, 23:04:58
Hmm, ich nutze msgDialog nicht (oder selber "nachgebaut"?).
[...]
nutze auch ROOMMATES etc. nicht.
Wenn man es im Einsatz hat, sieht man die Zusammenhänge...

Statt also umständlich erst mal alles irgendwo zentral zu sammeln, ist es m.E, einfacher, ein/das "Reading" beim jeweiligen ROOMMATE zu setzen, und dann hinterher (via myUtils) im passenden Event-Fall zu sehen, ob devspec2array (auf ROOMMATE, gefiltert mit "ist das Reading belegt") was zurückliefert, und dann wieder den msg-Befehl zu verwenden, um den einzelnen Bewohner "adäquat" zu informieren.

(Das folgende  nutze nun wieder ich nicht, aber afaik kann man das so einstellen, dass man die Nachricht dann nicht via Telegram bekommt, wenn man anwesend ist und ein "speaker" läuft...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Frieder

#9
Moin,
Also das abfangen der ersten Person klappt ja dann simpel über den Namen des readings: willwarmwassernachricht oder wollenwarmwassernachrichr 😁

Ich werde mir wohl mal myutilis anschauen und die anderen Ideen probieren.


Was haltet ihr alternativ davon im jeweiligen ROOMMATE ein wert willwarmwassernachricht ja oder nein zu hinterlegen, um dann am Ende, wenn das Wasser warm ist ein doif. Sowas wie
For each roommate - > wenn willwarmwassernachricht = ja - > split Attribut msgContactPush (für peer) - > sende Nachricht

Übersteigt allerdings auch meine Kenntnisse 😄

Edit: Beta-User danke für die Antwort auf den noch nicht abgeschickten Post 😁

Beta-User

Dann mal viel Spaß beim Tüfteln...

Der Thread-Titel ist immer noch ..., vielleicht haust du noch sowas wie "..., die einen Ablauf ausgelöst hatten" dazu?

Als Auslöser für die Rückmeldeprozedur würde ich vorschlagen, das Ausschalten des Aktors zu verwenden, dann kann man über die Temperaturabfrage z.B. auch sicherstellen, dass jeder "Initiator" die Meldung bekommt, dass jemand dagegen ist, dass es um diese Zeit schon Warmwasser gibt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Frieder

Dann mal danke an alle, ich werde mal ein bisschen basteln. Denke mit euren Ideen wird es klappen!
Grüße