Seit einiger Zeit unmotivierte on/off Events von Yamaha_AVR

[hauwech]

Hallo zusammen,
seit einiger Zeit löst mein Yamaha_AVR Device in unregelmäßigen Minuten Abständen "on" oder "off" Events aus.

Code Auswählen Erweitern

Internals:
   ACTIVE_ZONE mainzone
   CMDs_pending 109
   DEF        192.168.x.x mainzone 60 10
   FIRMWARE   1.93/2.13
   FUUID      5c4ad610-f33f-af18-4d3d-0f3fa8e8ecb446ec
   MODEL      RX-V775
   NAME       AV_Receiver
   NR         453
   STATE      on
   SYSTEM_ID  xxxxxxxxxx
   TYPE       YAMAHA_AVR
   ZONES_AVAILABLE mainzone,zone2
   eventCount 58
   READINGS:
     2023-07-03 15:22:55   3dCinemaDsp     auto
     2023-07-03 15:22:55   adaptiveDrc     auto
     2023-07-03 15:22:38   bass            6
     2019-12-03 21:03:28   currentStationFrequency
     2023-07-03 15:22:55   direct          off
     2023-07-03 15:21:56   displayBrightness -2
     2023-07-03 15:22:55   dsp             7chstereo
     2023-07-03 15:22:55   enhancer        off
     2023-07-03 15:22:46   hdmiOut1        on
     2023-07-03 15:22:51   hdmiOut2        on
     2023-07-03 15:22:55   input           audio1
     2023-07-03 15:22:55   inputName       AUDIO1
     2023-07-03 15:22:55   mute            off
     2023-07-03 15:23:00   partyMode       off
     2019-12-03 21:03:28   playStatus      stopped
     2023-07-03 15:22:55   power           on
     2023-07-03 15:18:30   presence        present
     2023-07-03 15:22:55   sleep           off
     2023-07-03 15:22:55   state           on
     2023-07-03 15:22:55   straight        off
     2023-07-03 15:22:26   surroundDecoder dtsneo:6music
     2023-07-03 15:22:43   treble          6
     2019-12-03 21:03:18   tunerFrequency  107.60
     2019-12-03 21:03:18   tunerFrequencyBand FM
     2023-07-03 15:22:55   volume          46
     2023-07-03 15:22:55   volumeStraight  -35
   helper:
     ADDRESS    192.168.x.x
     AVAILABLE  1
     DIRECT_TAG Pure_Direct
     DSP_MODES  Hall in Munich|Hall in Vienna|Chamber|Cellar Club|The Roxy Theatre|The Bottom Line|Sports|Action Game|Roleplaying Game|Music Video|Standard|Spectacle|Sci-Fi|Adventure|Drama|Mono Movie|Surround Decoder|2ch Stereo|7ch Stereo
     INPUTS     AUDIO1|AUDIO2|AV1|AV2|AV3|AV4|AV5|AV6|AirPlay|HDMI1|HDMI2|HDMI3|HDMI4|HDMI5|NET RADIO|Napster|PHONO|SERVER|Spotify|TUNER|USB|V-AUX|iPod (USB)
     OFF_INTERVAL 30
     ON_INTERVAL 30
     RUNNING_REQUEST 1
     SCENES     Scene 1|Scene 2|Scene 3|Scene 4
     SELECTED_ZONE mainzone
     SUPPORT_DAB 0
     SUPPORT_DISPLAY_BRIGHTNESS 1
     SUPPORT_EXTRA_BASS 0
     SUPPORT_HDMI_OUT 1
     SUPPORT_PARTY_MODE 1
     SUPPORT_SHUFFLE_REPEAT 0
     SUPPORT_SURROUND_DECODER 1
     SUPPORT_TONE_STATUS 1
     SUPPORT_YPAO_VOLUME 0
     SURROUND_DECODERS
     XML        /YamahaRemoteControl/desc.xml
     ZONES      Main_Zone|Zone_2
     CMD_QUEUE:
       HASH(0x71c6f2a0)
       HASH(0x71f13cb8)
       HASH(0x6d27c698)
       HASH(0xde4cdbc0)
       HASH(0xc67c8918)
       HASH(0x3c9a9020)
       HASH(0xde7e39f0)
       HASH(0xde7e3ab0)
       HASH(0xde725f20)
       HASH(0xde7e4110)
       HASH(0xde7e4158)
       HASH(0xde7e4308)
       HASH(0xde7e4458)
       HASH(0xde1c2e88)
       HASH(0x1139b9e0)
       HASH(0x3a1f5778)
       HASH(0xdd053c48)
       HASH(0xde9ec1d8)
       HASH(0x3c957018)
       HASH(0xdde64810)
       HASH(0xde0bb350)
       HASH(0xdd7a8f80)
       HASH(0x3b879cb8)
       HASH(0x3dc41cb8)
       HASH(0xde0494f8)
       HASH(0x39883bf8)
       HASH(0x71b6cdb0)
       HASH(0xde9a2630)
       HASH(0xdbc94e78)
       HASH(0xdeb278f8)
       HASH(0xde5c13e0)
       HASH(0xdeb28c70)
       HASH(0xde455690)
       HASH(0xddfb92c0)
       HASH(0x71f69c18)
       HASH(0x71f3a1c8)
       HASH(0x71b55a58)
       HASH(0xded36680)
       HASH(0xded37578)
       HASH(0xdda172b0)
       HASH(0xded2ca58)
       HASH(0xd45feb68)
       HASH(0x38e39028)
       HASH(0xdebcd0e8)
       HASH(0xdb4caca0)
       HASH(0xde9a3c78)
       HASH(0xde4a9530)
       HASH(0xde1e03e0)
       HASH(0x6f74fb68)
       HASH(0x7082b9b8)
       HASH(0xda9349e8)
       HASH(0x3dcdce68)
       HASH(0xde563b08)
       HASH(0x71f2b618)
       HASH(0xd697b250)
       HASH(0xdef71fe0)
       HASH(0xdd84ef28)
       HASH(0xca862408)
       HASH(0xd77344f8)
       HASH(0xde504ed0)
       HASH(0xdeb8bf00)
       HASH(0xdd7a9868)
       HASH(0x720ad4e8)
       HASH(0x716e9a48)
       HASH(0x3d80ddf8)
       HASH(0x71f566a0)
       HASH(0x71fd6fb8)
       HASH(0x3df57ca8)
       HASH(0x72102220)
       HASH(0xdf441a88)
       HASH(0xde479808)
       HASH(0x2911f2b8)
       HASH(0xdf1a0bb0)
       HASH(0xdf442710)
       HASH(0xdf3ba2e0)
       HASH(0xdf20b8b8)
       HASH(0x71f68260)
       HASH(0x3a392bb8)
       HASH(0x71ea7c20)
       HASH(0x703d6dc8)
       HASH(0x71c886e0)
       HASH(0x3df28f70)
       HASH(0x6cd34fc0)
       HASH(0x717b0be0)
       HASH(0x71728080)
       HASH(0x721c0d20)
       HASH(0x29110ab8)
       HASH(0x1714e610)
       HASH(0x71f9e428)
       HASH(0x72250850)
       HASH(0x218f5710)
       HASH(0x3dc5bae0)
       HASH(0x71fc9330)
       HASH(0x3e046ba0)
       HASH(0xdf2cbb38)
       HASH(0x3df054f0)
       HASH(0x3dfe4800)
       HASH(0x3dc29d88)
       HASH(0xdf639368)
       HASH(0xdf895b38)
       HASH(0xdf4f2d80)
       HASH(0xdf7a14f8)
       HASH(0xdf952398)
       HASH(0xdf9524e8)
       HASH(0x29369918)
       HASH(0xd9a280b0)
       HASH(0xde5ba520)
       HASH(0xdf1dc448)
       HASH(0x71c58240)
   hmccu:
Attributes:
   alias      AV_Receiver
   event-on-change-reading state
   group      Unterhaltung
   icon       rc_AV
   isHardware 1
   model      RX-V775
   room       Wohnhaus,Wohnzimmer
   volumeSmoothChange 1
Mit dieser Konfiguration hat es mehrere Jahre ohne Probleme funktioniert.
Das Problem dahinter:
Wenn AV_Receiver in einer bestimmten Zeitspanne auf "off" geht, löst das eine Reihe von Aktionen aus. Es werden Rollos runtergefahren, evtl. noch offene Markisen eingefahren, Lichter geschaltet, Durchsagen von noch offenen Fenstern und Türen gemacht und letztendlich die Alarmanlage scharf geschaltet.
Ich kann das neuartige Verhalten leider nicht an einem bestimmten Update festmachen und auch nicht an ein Datum knüpfen.
Mich macht die lange CMD_QUEUE stutzig, keine Ahnung, wo das herkommt.
Momentan z.B. ist er eingeschaltet ("on"). Es kommen im Minutentakt "on" Events, obwohl definitv kein change-reading stattfindet.

Hat vielleicht jemand etwas ähnliches beobachtet und kann mir einen Tip geben?

Danke und Gruß
Roland

[Beta-User]

Meine Queue ist grade 3 cmd's lang, kann aber grade sich nicht intensiv im Quellcode nachsehen, wo das herkommen könnte.

So wie ich das verstanden habe, gehst du nicht davon aus, dass das mit meinen Änderungen in den letzten Monaten zusammen hängt?
Vielleicht "Netzwerk-Hänger"?

[hauwech]

Ich muß da mal weiter beobachten, hab' nur momentan nicht genug Zeit. Ich hatte letztens einen kurzen Stromausfall. Früher war mir schon mal ein Switch nach einem Stromausfall nicht komplett ausgestiegen aber hat auf einigen Ports Aussetzer gehabt. Ich hatte heute mal den Pingplotter auf den AV Receiver laufen lassen, da habe ich keine Ausfälle gesehen. Er hat aber trotzdem im Minutentakt Events generiert. Ich habe heute noch mein CheckMK auf den Receiver angesetzt, aber bei den Check Intervallen sieht man kurze Aussetzer sicher nicht. CMDs_pending steht momentan auf 714, sicher nicht normal. Ich denke, das Netz ist es eher nicht.
Ein Verdächtiger wäre noch fhem selbst. Meine fhem Instanz ist die letzten Jahre massiv gewachsen, der Webserver hat zunehmend Mühe, die fhem Seite zu aktualisieren. FreezeMon liefert immer wieder zu lange Laufzeiten.
Ich habe jetzt einen neuen NUC bestellt mit i5, PCIe M2 und 32Gb RAM. Mein fhem läuft derzeit noch auf einem Celeron NUC auf Ubuntu 16.04 und SATA SSD. Das ist eh' schon fällig für eine Migration. Auf dem Neuen sollten die Flaschenhälse dann erstmal mittelfristig beseitigt sein.

Gruß Roland

[hauwech]

Ich habe heute mal den AV Receiver wieder ans LAN genommen und den Event Monitor (gefiltert auf AV_R.*) laufen lassen. Es werden in unregelmäßigen Intervallen Events generiert:

Code Auswählen Erweitern

2023-07-06 21:31:28.821 YAMAHA_AVR AV_Receiver off
2023-07-06 21:33:29.843 YAMAHA_AVR AV_Receiver off
2023-07-06 21:34:36.461 YAMAHA_AVR AV_Receiver off
2023-07-06 21:36:34.600 YAMAHA_AVR AV_Receiver off
2023-07-06 21:37:37.193 YAMAHA_AVR AV_Receiver off
2023-07-06 21:39:03.519 YAMAHA_AVR AV_Receiver off
2023-07-06 21:40:44.051 YAMAHA_AVR AV_Receiver off
2023-07-06 21:41:46.888 YAMAHA_AVR AV_Receiver off
2023-07-06 21:43:45.210 YAMAHA_AVR AV_Receiver off
2023-07-06 21:44:47.100 YAMAHA_AVR AV_Receiver off
2023-07-06 21:46:49.077 YAMAHA_AVR AV_Receiver off
2023-07-06 21:48:50.620 YAMAHA_AVR AV_Receiver off
2023-07-06 21:49:52.265 YAMAHA_AVR AV_Receiver off
2023-07-06 21:51:00.470 YAMAHA_AVR AV_Receiver off
2023-07-06 21:52:01.001 YAMAHA_AVR AV_Receiver off
2023-07-06 21:53:57.877 YAMAHA_AVR AV_Receiver off
2023-07-06 21:54:59.549 YAMAHA_AVR AV_Receiver off
Nach meinem Verständnis sollte das mit "event-on-change reading state" nicht passieren, wenn sich der state nicht ändert. Der Receiver ist während des Test nicht ein- oder ausgeschaltet worden. State ist immer "off" gewesen.
Nach einem Systemneustart ist CMDs_pending derzeit auf 5.
Die mit dem AV Receiver verknüpften Aktionen haben ein paar Jahre super funktioniert. Es wäre gut für den WAF, wenn das wieder laufen würde.
Ich kann mir das Verhalten momentan nicht erklären. Könnte es helfen, das Device zu löschen und neu anzulegen?

Gruß Roland

Ergänzung:
Wenn er "on" ist und bleibt, kommen in ähnlichen Abständen auch "on" Events, obwohl sich der state auch in diesem Fall nicht ändert.

[Beta-User]

Löschen bringt nichts. Die Frage war: passiert das auch mit einer "vor-Beta-User"-Version? (Die pm kannst du " isoliert " tauschen, danach FHEM unbedingt neu starten!)

[hauwech]

Ich habe aktuell:
71_YAMAHA_AVR.pm            26846 2022-12-12 20:58:51Z Beta-User

Gibt's denn eine andere Version?

Gruß Roland

[Beta-User]

Über das svn kann man auch "historische" Versionen bekommen....

[hauwech]

Die Version 26846 ist ja vom 2022-12-12. Das ungewöhnliche Verhalten ist erst seit etwa zwei Wochen. Ich die Versionen bei den fhem Updates nicht protokolliert, aber ich gehe fest davon aus, daß die 26846 schon länger drauf ist und auch funktioniert hat.
Ich bin aber gerade dabei, meinen neuen NUC aufzusetzen. Da wird das System neu installiert, aber die fhem.cfg werde ich natürlich mitnehmen, bzw. ein fhem Backup einspielen. Mal sehen, ob das Problem mitwandert, dann kann ich immer noch eine Vorgängerversion testen. Aber die Zeitabstände legen eher nahe, daß das Problem beim Yamaha Modul wahrscheinlich eher nicht zu finden ist.

Gruß Roland

[hauwech]

Update:
Ich hatte am Samstag mal genügend Zeit, um mein fhem ohne Streß auf den zwischendurch erwähnten neuen NUC umzuziehen. Ich bin von einem NUC8 Celeron mit 8GB RAM und SATA SSd auf NUC11 i5 32GB + M2 NVMe SSD umgestiegen. Der alte NUC hat viele Jahre treu gedient, ist aber nun ans Limit gekommen.
Die Performance hat sehr deutlich zugelegt.
Gestern habe ich meine an den AVR gekoppelten Aktionen wieder aktiviert. Es funktioniert wieder. Es ist exakt die gleiche fhem-Konfiguration, nur mit schnellerem Unterbau. So richtig erklären kann ich mir das nicht. Vielleicht hat ein interner Timer einen Timeout und damit on/off Events ausgelöst, wenn das ganze System am Limit läuft? Das ist aber Spekulation, weil ich mir das Verhalten momentan nicht anders erklären kann.

Gruß Roland