Neueste Beiträge

#11

MQTT / Aw: MQTT2 userReadings wird me...

Letzter Beitrag von rudolfkoenig - 31 Januar 2026, 19:11:36

Das oben gezeigt readingList ist ineffizient, unter anderem weil das JSON parsen mehrfach durchgelaufen wird.
Ich empfehle stattdessen sowas:

Code Auswählen Erweitern

$DEVICETOPIC:signal/in:.* {
    my $r = json2nameValue($EVENT);
    return { in_message_sent => $r->{params_envelope_syncMessage_sentMessage_message},
            in_message_data => $r->{params_envelope_dataMessage_message},
            in_groupName    => $r->{params_envelope_syncMessage_sentMessage_groupInfo_groupName},
            ...
          } }Alternativ setzt man das jsonMap Attribut, was genau fuer dieses Problem implementiert wurde.

Um das Problem mit userReading zu untersuchen haette ich gerne eine komplette Nachricht.
Die Werte gerne anonymisiert, aber mit allen Schluesseln.

#12

MQTT / Aw: shelly1 mini readings

Letzter Beitrag von RalfRog - 31 Januar 2026, 18:46:15

Nachdem so langsam klar ist wie es laufen soll wird der Ursprungspost verständlich.
Wenn dein Shelly (vermutlich) über MQTT läuft kann dir ja vielleicht jemand bei der Anpassung der Definition helfen um das READING zu erhalten.

[alles]

#13

MQTT / Aw: shelly1 mini readings

Letzter Beitrag von passibe - 31 Januar 2026, 18:38:07

nein. wie deaktiviere ich den Motion wenn einschaltung per schalter erfolgt?

Ah, ok.

Indem du alles über FHEM laufen lässt. Motion sendet an FHEM, FHEM entscheidet, was passiert (z.B. über ein DOIF) und schaltet dann (oder eben nicht) den Shelly. Dazu muss FHEM natürlich wissen, ob der Schalter eingeschaltet wurde. Deshalb brauchst du das Schalter-Reading in FHEM, was eigentlich mit Detached auftauchen sollte?

Und genauso sendet der Shelly die Betätigung des Schalters an FHEM, dann entscheidet FHEM, was passieren soll (z.B. Shelly ein-/ausschalten, Motion-Notify (de)aktivieren).

#14

MQTT / Aw: shelly1 mini readings

Letzter Beitrag von TomLee - 31 Januar 2026, 18:36:32

Mit DevSpec den Motion nur schalten lassen wenn Licht aus?

Erster Gedanke, evtl. nicht ganz zu Ende gedacht.

[input on]

#15

MQTT / Aw: shelly1 mini readings

Letzter Beitrag von RalfRog - 31 Januar 2026, 18:26:26

War zu erwarten.
Die Sache ist, dass du vom Shelly zwei verschiedene Logiken erwartest.
Wenn du manuell (z.B. SW = L) einschaltest soll per HTTP (off) der Zustand nicht überschrieben werden im anderen Fall (SW offen) soll sehr wohl per HTTP (ON) überschrieben werden.

Hat dein Shelly kein READING für Input? Davon kannst du die Motion-Aktionen abhängig machen.

Edit:
Ob das dann deine alltäglichen Erwartungen erfüllt kannst nur du wissen.
Mein 1PM (ShellyModul) :

input    on
input_action    long_push
input_actionS    L
input_cnt    134
input_mode    detached straight

#16

MQTT / Aw: shelly1 mini readings

Letzter Beitrag von satprofi - 31 Januar 2026, 18:05:40

nein. wie deaktiviere ich den Motion wenn einschaltung per schalter erfolgt?

#17

MQTT / MQTT2 userReadings wird mehrfa...

Letzter Beitrag von ch.eick - 31 Januar 2026, 17:41:11

Hallo zusammen,
solch einen Effekt hatte ich bisher noch nie.
Was ich nicht verstehe ist, dass das userReadings bei nur einer empfangenen Nachricht mehrfach durchlaufen wird.
Bei anderen MQTT2 Devices konnte ich sowas nicht feststellen.
Bei meinem ersten Test, bei dem nur ich alleine in der Gruppe war lief noch alles wie gewünscht. Als der zweite Benutzer nun in die Gruppe kam und ich dann im userReadings nach der Uuid unterscheiden musste, da trat dann diese Mehrfach Reaktion auf.

EDIT: Ich denke ein Problem wird sein, dass die readings, die ich verarbeite nicht alle zur gleichen Zeit geschrieben werden und auch vom zweiten MQTT Topic erneut geschrieben werden.
  Um die readings aus einer Nachricht z.B. in in_date_* schreiben zu können müsste ich innerhalb eines redingList Eintrages alle readings analysieren und schreiben.

  Wenn dieses Topic kommt, stehen im json alle zusammengehörigen Informationen drin. Wie müsste ich das denn als Perl schreiben, damit alle readings genau aus diesem json gelesen werden.
  Die parms_envelope Pfade sind bei dataMessage und syncMessage gleich und somit nicht eindeutig.

  $DEVICETOPIC:signal/in:.* { {in_message_data=>json2nameValue($EVENT)->{params_envelope_dataMessage_message} } }


readingList

Code Auswählen Erweitern

$DEVICETOPIC:signal/in:.* { {in_message_sent=>json2nameValue($EVENT)->{params_envelope_syncMessage_sentMessage_message} } }
$DEVICETOPIC:signal/in:.* { {in_message_data=>json2nameValue($EVENT)->{params_envelope_dataMessage_message} } }
$DEVICETOPIC:signal/in:.* { {in_groupName=>json2nameValue($EVENT)->{params_envelope_syncMessage_sentMessage_groupInfo_groupName} } }
$DEVICETOPIC:signal/in:.* { {in_source=>json2nameValue($EVENT)->{params_envelope_source} } }
$DEVICETOPIC:signal/in:.* { {in_sourceNumber=>json2nameValue($EVENT)->{params_envelope_sourceNumber} } }
$DEVICETOPIC:signal/in:.* { {in_sourceUuid=>json2nameValue($EVENT)->{params_envelope_sourceUuid} } }
$DEVICETOPIC:signal/in:.* { {in_sourceName=>json2nameValue($EVENT)->{params_envelope_sourceName} } }
$DEVICETOPIC:signal/in:.* { {in_account=>json2nameValue($EVENT)->{params_account} } }

Der MQTT2_FHEM_Server empfängt auch nur eine Nachricht mit dem gewünschten Inhalt.
Warum jedes mal vom user2 noch eine delivery Nachricht hinterher kommt verstehe ich ebenfalls noch nicht.

Code Auswählen Erweitern

18:11:46.102 signal_receiver signal/in {"jsonrpc":"2.0","method":"receive","params":{"envelope":{"source < persönliche Daten user1> "}}
18:11:46.134 signal_receiver signal/in/method/receive/source_number/%2B49xxxxxx
18:11:46.899 signal_receiver signal/in {"jsonrpc":"2.0","method":"receive","params":{"envelope":{"source < persönliche Daten user2 delivery Information> "}}
18:11:46.930 signal_receiver signal/in/method/receive/delivered/true

Event log

Code Auswählen Erweitern

2026-01-31 18:00:56.368 MQTT2_DEVICE signal_receiver in_source: +49
2026-01-31 18:00:56.368 MQTT2_DEVICE signal_receiver in_message_sent: 3
2026-01-31 18:00:56.368 MQTT2_DEVICE signal_receiver in_sourceUuid: 925814d3-cxxx8bdd
2026-01-31 18:00:56.368 MQTT2_DEVICE signal_receiver in_sourceNumber: +49
2026-01-31 18:00:56.368 MQTT2_DEVICE signal_receiver in_sourceName: user1

2026-01-31 18:00:57.225 MQTT2_DEVICE signal_receiver in_source: 984fad9d-3yyy239
2026-01-31 18:00:57.225 MQTT2_DEVICE signal_receiver in_sourceUuid: 984fad9d-3yyy239
2026-01-31 18:00:57.225 MQTT2_DEVICE signal_receiver in_sourceName: user2

FHEM Log

Code Auswählen Erweitern

2026.01.31 18:00:56.349 3: signal_receiver      ur_02 : in_sourceUuid  : 984fad9d-3yyy239
2026.01.31 18:00:56.349 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.352 3: signal_receiver      ur_02 : in_sourceUuid  : 984fad9d-3yyy239
2026.01.31 18:00:56.352 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.355 3: signal_receiver      ur_02 : in_sourceUuid  : 925814d3-cxxx8bd
2026.01.31 18:00:56.355 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.356 3: signal_receiver      ur_02 : in_command      : null
2026.01.31 18:00:56.359 3: signal_receiver      ur_02 : in_sourceUuid  : 925814d3-cxxx8bd
2026.01.31 18:00:56.359 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.359 3: signal_receiver      ur_02 : in_command      : null
2026.01.31 18:00:56.362 3: signal_receiver      ur_02 : in_sourceUuid  : 925814d3-cxxx8bd
2026.01.31 18:00:56.362 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.362 3: signal_receiver      ur_02 : in_command      : null
2026.01.31 18:00:56.365 3: signal_receiver      ur_02 : in_sourceUuid  : 925814d3-cxxx8bd
2026.01.31 18:00:56.365 3: signal_receiver      ur_02 : in_message_sent: 3
2026.01.31 18:00:56.365 3: signal_receiver      ur_02 : in_command      : null

Attribute

Code Auswählen Erweitern

event-on-change-reading in_message.*
event-on-update-reading in_analyse,in_source.*

userreading

Code Auswählen Erweitern

in_analyse_mapping_sent:in_message_sent.* {
  my $in_source = ReadingsVal("$NAME","in_sourceUuid","null");
  Log3($name,3,sprintf("%-20s ur_02 : ", $name)."in_sourceUuid  : $in_source");
  my $in_analyse = lc(ReadingsVal("$NAME","in_message_sent","null"));
  Log3($name,3,sprintf("%-20s ur_02 : ", $name)."in_message_sent: $in_analyse ");
  if (   $in_source eq "925814d3-c417-4848-bfbf-aaf306b978bd" ) {
    my $in_command = "null";
    if ( $in_analyse ne "null") {
      my %h=eval "(".(AttrVal("$NAME","in_commands","n/a")).")";
      $in_command = $h{$in_analyse} if defined $h{$in_analyse};
#      fhem("$in_command");
     Log3($name,3,sprintf("%-20s ur_02 : ", $name)."in_command     : $in_command");
     return $in_command;
    }
  }
  return "null";
}

VG  Christian

#18

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von betateilchen - 31 Januar 2026, 17:31:27

ich habe gerade das Problem, dass meine Lautsprecher nicht mehr "online" in fhem gehen.
Im Log kommt folgende Meldung in Dauerschleife:

Was liefert eine manuelle Abfrage im Browser auf die URL

Code Auswählen Erweitern

http://<ipDerBox>:8090//listMediaServers

#19

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von Mad - 31 Januar 2026, 16:56:01

Danke für die Antwort. Ich hatte leider keine andere Möglichkeit, da ich noch auf Buster unterwegs war. Updateversuche sind gescheitert, daher dieser Weg.
Es müsste soweit alles vorhanden sein, da es ja bis gestern ging....

#20

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von Prof. Dr. Peter Henning - 31 Januar 2026, 16:28:25

Namen eines Lautsprechers in der App geändert. Könnte es damit zusammenhängen?

Eher nicht.

Ich vermute von den Symptomen her, dass eine der Voraussetzungen für BOSEST nicht erfüllt ist.

Tipp: Man aktualisert ein System nicht, indem man FHEM "neu aufsetzt".

LG

pah