Hallo zusammen,
seit einiger Zeit löst mein Yamaha_AVR Device in unregelmäßigen Minuten Abständen "on" oder "off" Events aus.
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
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"?
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
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:
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.
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!)
Ich habe aktuell:
71_YAMAHA_AVR.pm 26846 2022-12-12 20:58:51Z Beta-User
Gibt's denn eine andere Version?
Gruß Roland
Über das svn kann man auch "historische" Versionen bekommen....
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
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
Bot-Alarm
bot gebannt, Beitrag gelöscht