Autor Thema: FHEM Abstürze mit MQTT Perl Version 5.24.1 - Debian Stretch Patchlevel 20181226  (Gelesen 1266 mal)

Online sbiermann

  • Full Member
  • ***
  • Beiträge: 433
Ja die einzelnen Readingnamen funktionieren. Habs jetzt mal so umgesetzt. Das andere wäre natürlich viel sexier als jetzt, aber nuja es geht.

Das mit den {$1} wird zwar akzeptiert, es passiert aber rein gar nichts wenn eine Message kommt.

Warum ich value in dem Topic Namen verwende? Die Idee dahinter ist, so weiß ich genau die Nachricht in dem Channel ist nur der reine Wert, sprich bei temperature/value steht dann z.B. 20.1. Weiterhin verwendet ich für Geräte wo es möglich ist set im als letztes im Topic Namen, also z.B. temperature/set, so habe ich die Unterscheidung zwischen den Topics für das auslesen und setzen. Klar man könnte natürlich auch umdrehen und .../value/temperature machen und .../set/temperature aber das finde ich nicht so schön.

Ich habe jetzt mal alle MQTT_DEVICEs die regelmäßig Daten empfangen auf MQTT2_DEVICEs. Die schaltenden Devices sind noch auf das alte MQTT_DEVICE, da ich diese als Fehlerquelle für die Abstürze ausschließen kann. Weil um die Uhrzeiten, als die Abstürze waren, niemand auf den Schaltern gedrückt haben kann. Jetzt heißt es warten ob es weitere Abstürze gibt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11601
  • eigentlich eher "user" wie "developer"
Nu ja...

Anmerkungen noch: Dass das mit den set-Anweisungen "woanders" sein sollte, leuchtet ein, aber je nachdem brauchst du eh' eine Brücke zwischen set und value (wenn value die "Quittung" sein soll). Das ginge aber genauso, wenn der Wert einfach eine Ebene weiter oben erschiene im Topic-Pfad, oder? (Nur) für das Setzen wäre dann noch die Verlängerung mit .*/reading/set erforderlich.

Eventuell reicht MQTT2_DEVICE nicht nur $EVENT weiter, sondern auch $DEVICETOPIC. Wenn ja, könnte man auch eine allg. Verarbeitungslogik mit Regex basteln, die sich den Readingnamen als $1 extrahiert... (Ich habe dazu aber kein Eigeninteresse und würde das eher lösen wie oben skizziert, und für die GenericBridge gelten wieder andere Regeln, was die set-Auswertung anginge).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Online sbiermann

  • Full Member
  • ***
  • Beiträge: 433
Nach dem ich erst dachte es reicht nur die Devices umzuziehen die regelmäßig Daten empfangen kam dann trotzdem ein Absturz. Also habe ich auch die restlichen Devices (Schalter) umgezogen auf MQTT2 und seit dem (mehr als 1 Woche) gibt es keinen Absturz mehr. Es muss also wirklich am MQTT bzw. ich vermute an der Perl Implementierung des MQTT Protokolls gelegen haben. Schon sehr seltsam, aber die neuen MQTT2 Devices funktionieren gut und sind auch gefühlt viel schneller als die alten MQTT Devices in der Reaktion.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22800
Zitat
Schon sehr seltsam, aber die neuen MQTT2 Devices funktionieren gut
Was ist daran bitte seltsam, dass mein Code funktioniert? :)

Online sbiermann

  • Full Member
  • ***
  • Beiträge: 433
Das sehr seltsam bezieht sich auf die alten Devices, das es da mit der Perl Implementierung anscheinend in meiner Konstellation so viel Probleme gibt.

 

decade-submarginal