Hallo,
ich habe mal ein Problem :-)
FHEM läuft auf einer Pi3 seit Jahren stabil und zuverlässig.
Nun wollte ich meine HA mit Bewegungsmeldern erweitern.
Equipment für die Bewegungsmeldung: Sonoff PIR2 Sensor, Sonoff Bridge mit Tasmota (die 2.)
Auf der Bridge erscheint nach einer Bewegung ziemlich schnell das Tele:
MQT: tele/Wlan-Bridge-02/RESULT = {"RfReceived":{"Sync":12490,"Low":430,"High":1200,"Data":"E7D74E","RfKey":1}}
Bis das Ganze aber in FHEM als Event erscheint kann das schonmal 10 Sekunden dauern.
2019-08-21 17:39:11 MQTT_DEVICE RF_Bridge transmission-state: incoming publish received
2019-08-21 17:39:13 MQTT_DEVICE RF_Bridge RESULT: {"RfReceived":{"Sync":12540,"Low":450,"High":1190,"Data":"E7D74E","RfKey":"None"}}
2019-08-21 17:39:15 MQTT_DEVICE RF_Bridge RfReceived_High: 1190
2019-08-21 17:39:15 MQTT_DEVICE RF_Bridge RfReceived_RfKey: None
2019-08-21 17:39:15 MQTT_DEVICE RF_Bridge RfReceived_Sync: 12540
2019-08-21 17:39:15 MQTT_DEVICE RF_Bridge RfReceived_Data: E7D74E
2019-08-21 17:39:15 MQTT_DEVICE RF_Bridge RfReceived_Low: 450
2019-08-21 17:39:17 MQTT_DEVICE RF_Bridge_2 transmission-state: incoming publish received
2019-08-21 17:39:18 MQTT_DEVICE RF_Bridge_2 RESULT: {"RfReceived":{"Sync":12460,"Low":420,"High":1210,"Data":"E7D74E","RfKey":1}}
2019-08-21 17:39:19 MQTT_DEVICE RF_Bridge_2 RfReceived_High: 1210
2019-08-21 17:39:19 MQTT_DEVICE RF_Bridge_2 RfReceived_RfKey: 1
2019-08-21 17:39:19 MQTT_DEVICE RF_Bridge_2 RfReceived_Low: 420
2019-08-21 17:39:19 MQTT_DEVICE RF_Bridge_2 RfReceived_Data: E7D74E
2019-08-21 17:39:19 MQTT_DEVICE RF_Bridge_2 RfReceived_Sync: 12460
Also bekommt die 1. Bridge das mit, kann aber nix damit anfangen. Die 2. Bridge ist an den Melder angelernt und meldet das auch.
Wo kommt die Latenz her?
Nebenfrage:
define Funkschalter_2_1 DOIF ([RF_Bridge_2:RfReceived_Data] eq "E7D74E") (set Motion_Detect_1 ON)
funktioniert manchmal, aber nicht immer. Warum?
Versuch bitte das Ganze mit MQTT2_SERVER/MQTT2_DEVICE neu einzurichten (im fhemwiki gibt es auch Beitraege dazu).
MQTT2* ist einfacher als das "alte" MQTT*, speziell fuer Sonoff Anbindung, und wird auch aktiver betreut.
Danke dir.
Ich werde den MQTT2 erstmal auf Port 1884 parallel betreiben.
Ich müsste dann 16 Steckdosen (teilweise mit Sensoren) , einen Schalter und 2 RF-Bridges umbauen.
Ich hänge die 2. Bridge mal an MQTT2 und schau mal, was es bringt.
Hmmm, eigentlich kann ich mir kaum vorstellen, dass die Latenzen aus dem Umfeld von MQTT_DEVICE iVm. expandJSON kommen, da ist vermutlich noch was anderes faul, und zu DOIF kann ich zwar nicht wirklich was beitragen, es klingt für mich aber nach einem fehlenden "do always" kein Zustandswechsel, wenn mehrfach dasselbe Event kommt).
Da sowohl MQTT2_DEVICE wie obige Kombi aber im Ergebnis dasselbe (Readingname und -inhalt sind mWn. identisch...) liefern, dürfte der "Umbau" recht einfach gehen.
Soso :-) Ich kommt dir gleich mal da rüber :-)
Das waren 16 Sonoffs mit unterschiedlichen Softwareständen. Einige Basics, einige POWs, einige S20, 2 Bridges und eine 4fach. Den Schalter habe ich mir noch aufgehoben.
Zu den Softwareständen: Eigentlich habe ich überall 5.9.1 aufgespielt, hatte aber angefangen 6.6.0 zu verwenden. Der Nachteil: Die WLan-Config geht verloren.
Da ich aber an einige Dosen schwer rankomme (unter der Decke...) kann ich sie nicht mal eben neuflashen, bzw den Taster 4x drücken.
Die Latenz ist nur unwesentlich verbessert worden. :-(
Na ja, unabhängig von den firmware-Versionen: Die Latenzen scheinen innerhalb von FHEM zu bestehen, jedenfalls deutet das mit ca. 4 Sekunden zwischen dem Nachrichteneingang und dem Auspacken in Readings auf einen Verzug innerhalb FHEM hin. Da kann man z.B. mit apptime&Co rausfinden, was da stattfindet.
Das hat eher nichts mit dem Netzwerk zu tun (wobei di ehöhere Zahl von 18 IoT-WLAN-Geräte zzgl. dem, was "man" "üblicherweise" so in einem normalen Haushalt an WLAN-"Gedöns" rumschwirren hat, auch - v.a. gerne iVm. einer Fritzbox - zu Problemen führen _kann_).
Kann es sein, dass der MQTT2-Server bei 16 Dosen mit vielen Teles an seine Grenzen stößt?
Nach dem Umbau von Mosquito nach MQTT2 habe ich folgendes Problem:
30 Mins vor Sonnenuntergang sollen 6 Dosen geschaltet werden. 4 davon gehen, aber dann klemmt das komplette MQTT. Erst ein Neustart des FHEMs behebt dann, bis zum nächsten Abend, das Problem.
Ähmmm, also...
Das _glaube_ ich nicht.
Denn: Dein Problem bestand schon vorher (Ausgangsbeitrag war noch MQTT_DEVICE). Vom _Gefühl_ her sagt meine Glaskugel, dass das Problem nicht aus der MQTT(2)-Welt kommt, sondern irgendwas ganz anderes "faul" ist. Würde auf einen Eventhandler mit generös gesetztem Regex tippen. Wie bereits geschrieben: Dafür gibt es Tools, um das zu analysieren, und es würde mich überraschen, wenn wir ohne die was rausfinden.
Ich würde mal mit apptime loslegen (es gibt da auch ein komfortableres Modul, aber damit habe ich 0 Erfahrung)...
ZitatKann es sein, dass der MQTT2-Server bei 16 Dosen mit vielen Teles an seine Grenzen stößt?
Das wuerde mich zwar wundern, ausschliessen kann ich es aber nicht.
Allerdings kann ich ohne ein aussagefaehiges Log nichts unternehmen.
@Beta-User : Ich habe keinen Regex in der Config. Im Moment verwaltet der MQTT2 Server 18 Clients. Ich habe mal die überflüssigen Teles rausgenommen.
Ich versuche aber mal was mit apptime.
@rudolfkoenig:
Was für Logs brauchst du?
In den Devicelogs steht nur, wann sie Offline waren.
Zitat von: eisi am 30 August 2019, 16:19:39
@Beta-User : Ich habe keinen Regex in der Config. Im Moment verwaltet der MQTT2 Server 18 Clients. Ich habe mal die überflüssigen Teles rausgenommen.
Ich versuche aber mal was mit apptime.
Du hast ganz sicher irgendeinen Eventhandler in deiner config (ein DOIF kenne ich mindestens ;) ) - das hat NICHTS mit den MQTT(2)-Devices zu tun, sondern ich beziehe das ausdrücklich auf alles, was in der config steht... Und selbst wenn der "trigger" eng gesetzt ist, ist es ein Regex ;) .
Also zähl' mal die notify, DOIF, THRESHOLD, watchdog, dewpoint, ... - Devices, dann wirst du sehen, wie viele Regexe das doch sind, die da zusammenkommen.
Nochmal: ich _glaube_ nicht, dass die beobachteten Verzögerungen irgendwas (direkt) mit den MQTT-Themen zu tun haben. Es sind eher die Events allgemein, die da generiert werden und dann (durch alles andere) ausgewertet werden müssen. Deswegen ist es auch egal, ob da MQTT_DEVICE iVm. expandJSON zur Anwendung kommt oder MQTT2_DEVICE mit der internen Funktion...
Okay :-) Also ich habe ein paar Doifs, die aber präzise gesetzt sind:
define Funkschalter_10 DOIF ([RF_Bridge:RfReceived_RfKey:d]==10) (set Licht_Flur_oben off)
2 von denen hier:
define Nebler_oben_auto_on DOIF ( [6:30-22:30] and [Schlafzimmer_Luft:Luftfeuchtigkeit:d]<43 and [Nebler_oben_dummy]==1 ) (set Nebler_Schlaf on) DOELSE (set Nebler_Schlaf off , set Nebler_oben_dummy 0)
define Nebler_oben_auto_pause DOIF ([6:30-22:30] and [Schlafzimmer_Luft:Luftfeuchtigkeit:d]<41) (set Nebler_oben_dummy 1)
Was ich mir vor ein paar Jahren mal gebaut habe:
define Heizung_eco_mynot1 notify Heizung_eco.* {Log( 1, "Heizung eco");;\
fhem "set MAX_10d72d desiredTemperature eco";;\
fhem "set MAX_10dbcb desiredTemperature eco";;\
fhem "set MAX_10cfc8 desiredTemperature eco";;\
fhem "set MAX_10d14c desiredTemperature eco";;\
fhem "set MAX_10cfd8 desiredTemperature eco";;\
fhem "set MAX_10e762 desiredTemperature eco";;\
fhem "set MAX_10e702 desiredTemperature eco";;\
fhem "set MAX_10d6be desiredTemperature eco";;\
fhem "set MAX_10d55c desiredTemperature eco";;\
fhem "setstate Heizung_auto OFF";;\
fhem "setstate Heizung_unten_aus OFF";;}
watchdog, dewpoint habe ich keine mehr.
Könnte das ein Problem darstellen?
...in der Regel stellen Dinge, die man nicht mehr hat, eher nicht das Problem dar...
Hier ist wieder einiges auf mehrere Devices verteilt, was eigentlich in eines reingehört (z.B. die 2 Nebler-DOIF...); für mich ist das eigentlich ein THRESHOLD, aber lassen wir das...
Was sagt apptime, nachdem es jetzt einige Zeit läuft?!?
ZitatWas für Logs brauchst du?
"attr global verbose 5" Logs beim ausfuehren eines FHEM Kommandos (oder externen MQTT Events), was zeigt, dass MQTT2_SERVER klemmt.
Apptime total:
name function max count total average maxDly avgDly TS Max call param Max call
myDbLog DbLog_Log 1152 55 23419.96 425.82 0.00 0.00 31.08. 11:19:59 HASH(myDbLog); HASH(MQTT2_Wlan_Steckdose_8)
m2s_192.168.0.55_25115 MQTT2_SERVER_Read 659 31 6199.00 199.97 0.00 0.00 31.08. 11:19:30 HASH(m2s_192.168.0.55_25115)
m2s_192.168.0.58_20190 MQTT2_SERVER_Read 1220 12 1750.44 145.87 0.00 0.00 31.08. 11:19:59 HASH(m2s_192.168.0.58_20190)
m2s_192.168.0.53_1493 MQTT2_SERVER_Read 908 12 1718.29 143.19 0.00 0.00 31.08. 11:20:29 HASH(m2s_192.168.0.53_1493)
m2s_192.168.0.56_17559 MQTT2_SERVER_Read 662 23 1293.92 56.26 0.00 0.00 31.08. 11:18:15 HASH(m2s_192.168.0.56_17559)
m2s_192.168.0.60_22737 MQTT2_SERVER_Read 1255 11 1261.38 114.67 0.00 0.00 31.08. 11:20:15 HASH(m2s_192.168.0.60_22737)
cul_oben CUL_Read 509 11 1012.21 92.02 0.00 0.00 31.08. 11:21:22 HASH(cul_oben)
m2s_192.168.0.66_1375 MQTT2_SERVER_Read 868 13 899.88 69.22 0.00 0.00 31.08. 11:17:53 HASH(m2s_192.168.0.66_1375)
m2s_192.168.0.57_13769 MQTT2_SERVER_Read 836 12 846.41 70.53 0.00 0.00 31.08. 11:19:52 HASH(m2s_192.168.0.57_13769)
m2s_192.168.0.64_22468 MQTT2_SERVER_Read 831 22 845.18 38.42 0.00 0.00 31.08. 11:20:06 HASH(m2s_192.168.0.64_22468)
m2s_192.168.0.70_1627 MQTT2_SERVER_Read 804 12 811.13 67.59 0.00 0.00 31.08. 11:19:14 HASH(m2s_192.168.0.70_1627)
m2s_192.168.0.80_49153 MQTT2_SERVER_Read 624 22 638.26 29.01 0.00 0.00 31.08. 11:18:24 HASH(m2s_192.168.0.80_49153)
m2s_192.168.0.63_18027 MQTT2_SERVER_Read 614 22 627.59 28.53 0.00 0.00 31.08. 11:17:20 HASH(m2s_192.168.0.63_18027)
m2s_192.168.0.52_10073 MQTT2_SERVER_Read 611 22 621.75 28.26 0.00 0.00 31.08. 11:17:56 HASH(m2s_192.168.0.52_10073)
m2s_192.168.0.59_10712 MQTT2_SERVER_Read 602 23 619.25 26.92 0.00 0.00 31.08. 11:19:12 HASH(m2s_192.168.0.59_10712)
m2s_192.168.0.61_31594 MQTT2_SERVER_Read 598 22 610.58 27.75 0.00 0.00 31.08. 11:19:01 HASH(m2s_192.168.0.61_31594)
m2s_192.168.0.62_32121 MQTT2_SERVER_Read 596 21 606.15 28.86 0.00 0.00 31.08. 11:18:16 HASH(m2s_192.168.0.62_32121)
m2s_192.168.0.51_28615 MQTT2_SERVER_Read 586 22 596.56 27.12 0.00 0.00 31.08. 11:19:03 HASH(m2s_192.168.0.51_28615)
m2s_192.168.0.65_8696 MQTT2_SERVER_Read 579 22 590.35 26.83 0.00 0.00 31.08. 11:19:30 HASH(m2s_192.168.0.65_8696)
m2s_192.168.0.71_3053 MQTT2_SERVER_Read 474 12 483.03 40.25 0.00 0.00 31.08. 11:21:11 HASH(m2s_192.168.0.71_3053)
telnetPort telnet_Read 5 96 430.43 4.48 0.00 0.00 31.08. 11:19:05 HASH(telnetPort)
Kodi.WoZi XBMC_Read 109 11 348.55 31.69 0.00 0.00 31.08. 11:16:56 HASH(Kodi.WoZi)
Da es jetzt schneller ist, gehe ich mal davon aus, dass das "delete myDbLog" geholfen hat.
m2s_192.168.0.70_1627 MQTT2_SERVER_Read 143 19 962.23 50.64 0.00 0.00 31.08. 11:35:41 HASH(m2s_192.168.0.70_1627)
m2s_192.168.0.52_10073 MQTT2_SERVER_Read 57 47 557.00 11.85 0.00 0.00 31.08. 11:32:56 HASH(m2s_192.168.0.52_10073)
m2s_192.168.0.55_25115 MQTT2_SERVER_Read 64 30 501.73 16.72 0.00 0.00 31.08. 11:35:30 HASH(m2s_192.168.0.55_25115)
WEB_192.168.0.1_61566 FW_Read 333 7 465.25 66.46 0.00 0.00 31.08. 11:35:32 HASH(WEB_192.168.0.1_61566)
m2s_192.168.0.71_3053 MQTT2_SERVER_Read 114 19 435.56 22.92 0.00 0.00 31.08. 11:32:10 HASH(m2s_192.168.0.71_3053)
telnetPort telnet_Read 7 83 401.87 4.84 0.00 0.00 31.08. 11:32:38 HASH(telnetPort)
nice-__ANON__ 19 32 352.62 11.02 1.72 0.45 31.08. 11:32:52 (undef)
MQTT2_Wlan_Bridge_01_notify_1 notify_Exec 62 9 340.77 37.86 0.00 0.00 31.08. 11:33:14 HASH(MQTT2_Wlan_Bridge_01_notify_1); HASH(MQTT2_Wlan_Bridge_01)
Motion_Detect_1 dummy_Set 58 10 313.76 31.38 0.00 0.00 31.08. 11:33:14 HASH(Motion_Detect_1); Motion_Detect_1; motion
tmr-CUL_MAX_SendQueueHandler HASH(0x38db598) 36 65 259.91 4.00 68.00 4.07 31.08. 11:33:29 HASH(CULMAX0)
cul_oben CUL_Get 80 10 250.42 25.04 0.00 0.00 31.08. 11:32:47 HASH(cul_oben); cul_oben; credit10ms
Motion_light dummy_Set 108 7 243.25 34.75 0.00 0.00 31.08. 11:33:11 HASH(Motion_light); Motion_light; off
Motion_Detect_1_notify_1 notify_Exec 42 8 204.33 25.54 0.00 0.00 31.08. 11:33:14 HASH(Motion_Detect_1_notify_1); HASH(Motion_Detect_1)
Kodi.WoZi XBMC_Read 47 7 171.93 24.56 0.00 0.00 31.08. 11:32:56 HASH(Kodi.WoZi)
m2s_192.168.0.53_1493 MQTT2_SERVER_Read 69 11 127.59 11.60 0.00 0.00 31.08. 11:35:27 HASH(m2s_192.168.0.53_1493)
m2s_192.168.0.63_18027 MQTT2_SERVER_Read 113 21 123.16 5.86 0.00 0.00 31.08. 11:32:21 HASH(m2s_192.168.0.63_18027)
Für die Verzögerung dürfte das Löschen des DBLog-Eventhandlers (.... ;) ) wohl geholfen haben, aber hast du dann noch die erforderlichen Infos für Plots?
Wenn du das je wieder in Betrieb nehmen solltest: Nicht alles loggen (die Zahl der verarbeiteten Events klingt danach), und v.a. auf dem Pi darauf achten, dass mehr gepuffert wird, die für die Hardware passende DB-Lösung gewählt ist usw.. Sonst hast du schnell noch weitere Probleme (kaputte SD-Karte, um mal was "willkürliches" zu wählen...).
Was sagt apptime eigentlich jetzt, nachdem es eine gewisse Zeit gelaufen ist? (Vielleicht finden sich noch weitere "Klopper").
(Wenn du die Infos nicht mehr brauchst/laufend weiter aufzeichnen willst, kannst du apptime auf pause setzen oder mußt FHEM neu starten).
name function max count total average maxDly avgDly TS Max call param Max call
m2s_192.168.0.55_25115 MQTT2_SERVER_Read 92 969 15566.52 16.06 0.00 0.00 31.08. 13:12:33 HASH(m2s_192.168.0.55_25115)
telnetPort telnet_Read 10 2756 12806.65 4.65 0.00 0.00 31.08. 14:00:00 HASH(telnetPort)
m2s_192.168.0.71_3053 MQTT2_SERVER_Read 125 413 7943.68 19.23 0.00 0.00 31.08. 13:41:10 HASH(m2s_192.168.0.71_3053)
Kodi.WoZi XBMC_Read 96 422 6946.76 16.46 0.00 0.00 31.08. 11:36:56 HASH(Kodi.WoZi)
m2s_192.168.0.70_1627 MQTT2_SERVER_Read 143 425 6767.19 15.92 0.00 0.00 31.08. 11:35:41 HASH(m2s_192.168.0.70_1627)
m2s_192.168.0.53_1493 MQTT2_SERVER_Read 136 387 3880.94 10.03 0.00 0.00 31.08. 11:55:27 HASH(m2s_192.168.0.53_1493)
tmr-Spotify_poll HASH(0x3a1b3d0) 681 33 3566.33 108.07 3.25 2.32 31.08. 12:57:33 HASH(Spotify1)
m2s_192.168.0.60_22737 MQTT2_SERVER_Read 93 387 3557.38 9.19 0.00 0.00 31.08. 14:10:15 HASH(m2s_192.168.0.60_22737)
m2s_192.168.0.56_17559 MQTT2_SERVER_Read 68 714 3557.10 4.98 0.00 0.00 31.08. 13:33:26 HASH(m2s_192.168.0.56_17559)
m2s_192.168.0.52_10073 MQTT2_SERVER_Read 72 733 3320.99 4.53 0.00 0.00 31.08. 14:03:08 HASH(m2s_192.168.0.52_10073)
m2s_192.168.0.58_20190 MQTT2_SERVER_Read 75 387 3314.79 8.57 0.00 0.00 31.08. 13:19:58 HASH(m2s_192.168.0.58_20190)
tmr-PRESENCE_StartLocalScan HASH(0x38e3a00) 27 153 3306.90 21.61 21.17 3.45 31.08. 13:16:53 HASH(Cam_r)
Da ist nichts mehr großes drin :-)
Danke dir!
Setzt du den Thread dann bitte noch auf [gelöst]?
(1. Beitrag editieren)