[YAMAHA_AVR] - support Thread ab 2022

Begonnen von Beta-User, 27 Oktober 2022, 11:09:41

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

kommissarisch habe ich die Pflege von YAMAHA_AVR übernommen und hoffe, dass sich bald jemand findet, der das ggf. mittelfristig übernehmen möchte (opimalerweise zusammen mit YAMAHA_BD, siehe zum ganzen auch https://forum.fhem.de/index.php/topic,129846.0.html).

Mit dem heutigen update kommt zunächst einfach eine (funktional) auf den "id"-Standard umgebogene Commandref, so dass man jetzt in der Device-Ansicht jeweils eine kurze Erläuterung zu den set-Kommandos und Attributen angezeigt bekommt.

Irgendwelche Kenntnisse im Modul-Code dürft ihr (noch) nicht erwarten, ich bin bisher einfach auch User gewesen...

Wer Fragen oder Anregungen hat, möge diese bitte hier platzieren und/oder für "spezielle Themen" auf separate Threads ausweichen. Wer die Pflege stattdessen lieber selbst (statt meiner oder ergänzend) übernehmen möchte, darf sich BITTE (!) melden.

Weitere Pläne und Gedanken:
Falls ich dann dazu komme, wird es ggf. auf PBP-Konformität hin überarbeitet und vielleicht gepackaged (in dem Zuge werde ich auch den Code mal intensiver ansehen).
(Sehr) vielleicht schaue ich bei Gelegenheit auch mal, ob sich da noch was in Richtung MusicCast ergänzen läßt (mein Receiver unterstützt das; es gibt dazu auch das Modul 71_YAMAHA_MC.pm).

Soviel erst mal für's erste,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, mit dem morgigen update kommt dann eine Version ohne Prototypen als erster Schritt in Richtung PBP-Konformität.

Bis dahin dürfte es "unkritisch" sein, es bringt aber funktional nichts neues.

Wer also sicher sein will, kann das Modul gerne vom update ausnehmen, die alte Version funktioniert ja. Allerdings sind manche Sachen im Code (für mich) nicht so einfach zu durchschauen und damit schwer wartbar. Sowas wie
unless((exists($options->{not_before}) and $options->{not_before} > gettimeofday()) or (defined($next_item)))
ist ein "Gehirnverdreher", der m.E. in eine lesbarere Form überführt werden sollte...

Weiß noch nicht genau, wie es dann weitergeht, vermutlich wird es entweder Testversionen vor weiteren updates geben, die dann hier gepostet werden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#2
Da war leider doch was merkwürdiges drin - state etc. wurde nicht mehr (immer?) triggernd aktualisiert, wenn man z.B. angeschaltet hat. Daher kommt mit dem update doch wieder der alte Stand.

Etwas merkwürdig, dass "SetFn()" bei einem "on"-Kommando effektiv 5 Mal aufgerufen wird, neben "on" dann noch mehrfach mit "?" als Parameter. Kommt wohl aus FHEMWEB, weil nicht die erwartete Antwort zurückkommt (?).

Den Teil zu beheben, indem auf die ?-Anfrage die gültigen setter kommen hilft leider nicht so recht.

Anbei daher mal ein aktueller Zwischenstand, falls jemand Lust zum mittüfteln hat...
EDIT: sehr merkwürdig - es klappt manchmal (nur? in der mainzone?), und manchmal nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Holla,

ich war neugierig ob es für das alte Schätzchen dass ich hier habe so etwas wie ein FHEM Modul gibt, habs es einfach eingebunden und bin dadurch hier gelandet.

Wir nutzen zu 99% die NetRadio Funktion von dem Gerät. Hat zufälligerweise jemand eine Idee, wie man eine entpsrechende Funktion einsetzen könnte?
Man kann ja die FB Simulieren (das wäre eine Möglichkeit) aber vielleicht kann man auch "NetRadio" -> Sender -> Wunschlautstärke -> direkt in einem Befehl setzen?

@Beta-User bin durch diesen auf den Ursprung der Verwaiste Module: naechste Runde gekommen. Dort ist mir Dein Satz im Bezug auf Ottos Antwort ins Auge gefallen:
Zitat
Falls sich jemand (gerne auch ein interessierter "normaler User") ähnlich fühlt wie Otto (sehr guter Ansatz übrigens!), darf er sich gerne bei mir melden!
Falls ich da also (Testtechnisch) etwas beitragen kann - Nur zu. Ich bin die nächsten 4 Wochen Strohwitwer, also wahrscheinlich öfter am PC als mir lieb ist. Mein nicht über (Anfänger)Grundlagen ausreichenendes Perlwissen kann sicher kaum zum Modul etwas beitragen, aber vielleicht kann ich ja anders behilflich sein. Wir haben hier übrigens einen RX-V575 stehen, falls das von Bedeutung ist ;)

VG
Andreas

Beta-User

Hi Andreas,

leider kann ich deine Frage zur Verwendung auch (noch) nicht beantworten, aber ich freue mich auf alle Fälle auch über konstruktive Tester!

Im Moment möchte ich zunächst den Übergang in den eigenen namespace vollziehen und rausfinden, warum das Triggern nicht mehr sauber funktioniert. Für letzteres muss irgendein implizites Verhalten verantwortlich sein, das vom Gefühl her vermutlich gar nicht als solches bekannt war, es hat halt so funktioniert...

Wenn man nach package geht, besteht immer die Gefahr, dass man irgendeine Funktion beim importieren übersieht, was dann direkt zum Absturz führt, wenn die betreffende Funktion aufgerufen wird. Von daher wäre mir schon viel geholfen, wenn du einfach die hier gepostete Fassung mal auf verbose 5 stellst und den Verstärker eifrig hin- und herschaltest (v.a. über FHEM). Wenn dann  kein crash passiert, bin ich an der Stelle schon viel weiter!
Das mit dem trigger kann nicht das große Problem sein, ich brauche aber mal eine stille Stunde, um mir das anzusehen.

Was mir bei der ersten Durchsicht aufgefallen war, ist der sehr repetitive Code. Würde annehmen, dass man das auch anders lösen könnte und das ganze dann deutlich übersichtlicher werden würde. Mal sehen. Wäre dann aber zu einem guten Teil auch eine Fleißaufgabe, das umzustellen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Hai,

Zitat von: Beta-User am 04 Dezember 2022, 13:34:41
Wenn man nach package geht, besteht immer die Gefahr, dass man irgendeine Funktion beim importieren übersieht, was dann direkt zum Absturz führt, wenn die betreffende Funktion aufgerufen wird. Von daher wäre mir schon viel geholfen, wenn du einfach die hier gepostete Fassung mal auf verbose 5 stellst und den Verstärker eifrig hin- und herschaltest (v.a. über FHEM).

Damit meinst Du die Version die man über das normale Update erhält?

Den Test kann ich heute Abend auf jeden fall einmal in Ruhe machen. Da muss ich nur meine Testumgebung wieder auf den aktuellen Stand bringen, den Receiver einbinden und dann mal sehen ob ich FHEM zum Absturz bringen kann  ;D

Ich würde dann berichten....

VG
Andreas

Beta-User

Zitat von: flummy1978 am 04 Dezember 2022, 13:59:17
Damit meinst Du die Version die man über das normale Update erhält?
Nein. Gemeint war die, die ich gestern abend an den Post hier in diesem Thread angehängt habe.

(In der Regel versuche ich es zu vermeiden, derart kritische Übergänge direkt per update zu verteilen, sondern biete in der Regel Testversionen vorab an, damit nicht (unangekündigt und vorab chancenlos) sowas passiert wie jüngst den km200-Usern).

Du musst dann halt die Detailansicht manuell refreshen, die Readings werden nämlich aktualisiert, nur eben nicht triggernd.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Guten Morgen,

OK, das hab ich gemacht. Hab n blankes Testsystem angelegt und nur das Gerät dort angelegt - Allerdings bin ich grad irgendwie zu blöde verbose 5 zu loggen.

Hab das Device angelegt, extra dafür eigenes Log angelegt. Verbose 5 in global eingestellt. Trotzdem finden sich in der .log nur die Logs bis Stufe 3  :o

define WZ_Yamaha_ACV YAMAHA_AVR 192.168.0.63 mainzone 60 10
attr WZ_Yamaha_ACV event-on-change-reading .*
attr WZ_Yamaha_ACV group Geräte
attr WZ_Yamaha_ACV model RX-V575
attr WZ_Yamaha_ACV room Wohnzimmer
attr WZ_Yamaha_ACV verbose 5
attr WZ_Yamaha_ACV webCmd :
#   ACTIVE_ZONE mainzone
#   CFGFN     
#   DEF        192.168.0.63 mainzone 60 10
#   FIRMWARE   1.34/2.06
#   FUUID      638d41be-f33f-224d-f5e2-550502fd9b6ac623
#   MODEL      RX-V575
#   NAME       WZ_Yamaha_ACV
#   NR         138
#   STATE      on
#   SYSTEM_ID  0B438A43
#   TYPE       YAMAHA_AVR
#   ZONES_AVAILABLE mainzone,mainzone
#   eventCount 1411
#   READINGS:
#     2022-12-05 10:12:43   3dCinemaDsp     auto
#     2022-12-05 10:12:43   adaptiveDrc     auto
#     2022-12-05 10:12:43   bass            2
#     2022-12-05 10:12:43   direct          off
#     2022-12-05 10:12:43   dsp             7chstereo
#     2022-12-05 10:12:43   enhancer        on
#     2022-12-05 10:12:43   input           usb
#     2022-12-05 10:12:43   inputName       USB
#     2022-12-05 10:12:43   mute            off
#     2022-12-05 10:12:43   playStatus      stopped
#     2022-12-05 10:12:43   power           on
#     2022-12-05 07:28:11   presence        present
#     2022-12-05 10:12:43   repeat          off
#     2022-12-05 10:12:43   shuffle         off
#     2022-12-05 10:12:43   sleep           off
#     2022-12-05 10:12:43   state           on
#     2022-12-05 10:12:43   straight        off
#     2022-12-05 10:12:43   treble          -0.5
#     2022-12-05 10:12:43   volume          47
#     2022-12-05 10:12:43   volumeStraight  -34
#   helper:
#     ADDRESS    192.168.0.63
#     AVAILABLE  1
#     CURRENT_INPUT_TAG USB
#     DIRECT_TAG 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     AUDIO|AV1|AV2|AV3|AV4|AV5|AV6|AirPlay|HDMI1|HDMI2|HDMI3|HDMI4|HDMI5|NET RADIO|SERVER|Spotify|TUNER|USB|V-AUX|iPod (USB)
#     LAST_INPUT_TAG USB
#     OFF_INTERVAL 60
#     ON_INTERVAL 10
#     RUNNING_REQUEST 0
#     SCENES     Scene 1|Scene 2|Scene 3|Scene 4
#     SELECTED_ZONE mainzone
#     SUPPORT_DAB 0
#     SUPPORT_DISPLAY_BRIGHTNESS 0
#     SUPPORT_EXTRA_BASS 0
#     SUPPORT_HDMI_OUT 0
#     SUPPORT_PARTY_MODE 0
#     SUPPORT_SHUFFLE_REPEAT 1
#     SUPPORT_SURROUND_DECODER 0
#     SUPPORT_TONE_STATUS 1
#     SUPPORT_YPAO_VOLUME 0
#     XML        /YamahaRemoteControl/desc.xml
#     ZONES      Main_Zone|Main_Zone
#     CMD_QUEUE:
#
setstate WZ_Yamaha_ACV on
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 3dCinemaDsp auto
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 adaptiveDrc auto
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 bass 2
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 direct off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 dsp 7chstereo
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 enhancer on
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 input usb
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 inputName USB
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 mute off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 playStatus stopped
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 power on
setstate WZ_Yamaha_ACV 2022-12-05 07:28:11 presence present
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 repeat off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 shuffle off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 sleep off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 state on
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 straight off
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 treble -0.5
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 volume 47
setstate WZ_Yamaha_ACV 2022-12-05 10:12:43 volumeStraight -34



define WZ_Yamaha_ACV_FileLog_1 FileLog ./log/WZ_Yamaha_ACV_FileLog_1.log WZ_Yamaha_ACV:.*
attr WZ_Yamaha_ACV_FileLog_1 verbose 5
#   CFGFN     
#   DEF        ./log/WZ_Yamaha_ACV_FileLog_1.log WZ_Yamaha_ACV:.*
#   FD         14
#   FUUID      638d427d-f33f-224d-f5fd-2f6735b584bc4a9b
#   NAME       WZ_Yamaha_ACV_FileLog_1
#   NOTIFYDEV  WZ_Yamaha_ACV
#   NR         194
#   NTFY_ORDER 50-WZ_Yamaha_ACV_FileLog_1
#   REGEXP     WZ_Yamaha_ACV:.*
#   STATE      active
#   TYPE       FileLog
#   currentlogfile ./log/WZ_Yamaha_ACV_FileLog_1.log
#   eventCount 1
#   logfile    ./log/WZ_Yamaha_ACV_FileLog_1.log
#   READINGS:
#     2022-12-05 10:07:48   linesInTheFile  6940
#
setstate WZ_Yamaha_ACV_FileLog_1 active
setstate WZ_Yamaha_ACV_FileLog_1 2022-12-05 10:07:48 linesInTheFile 6940




Hast Du eine Idee, warum das so ist ?

So sieht das Logfile aus: (Global Log ist leer)


2022-12-05_10:14:29.904 WZ_Yamaha_ACV on
2022-12-05_10:14:30.043 WZ_Yamaha_ACV power: on
2022-12-05_10:14:30.043 WZ_Yamaha_ACV on
2022-12-05_10:14:31.352 WZ_Yamaha_ACV off
2022-12-05_10:14:32.666 WZ_Yamaha_ACV power: off
2022-12-05_10:14:32.666 WZ_Yamaha_ACV off

und so die entsprechende Eventlog Ansicht

2022.12.05 10:14:24.574 5 : GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3DWZ_Yamaha_ACV_FileLog_1%3Bsince%3D1670231663.34299%3Bfmt%3DJSON&fw_id=4552&timestamp=1670231664697 HTTP/1.1
Host: 192.168.0.20:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.20:8083/fhem?detail=WZ_Yamaha_ACV_FileLog_1&fw_id=4552
2022.12.05 10:14:24.574 4 : WEB_192.168.0.3_55537 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3DWZ_Yamaha_ACV_FileLog_1%3Bsince%3D1670231663.34299%3Bfmt%3DJSON&fw_id=4552&timestamp=1670231664697; BUFLEN:0
2022.12.05 10:14:29.686 4 : Connection closed for WEB_192.168.0.3_55546: EOF
2022.12.05 10:14:29.901 5 : POST /fhem?cmd.WZ_Yamaha_ACV=set%20WZ_Yamaha_ACV%20on&XHR=1&fwcsrf=csrf_117060430164075&fw_id=4517 HTTP/1.1
Host: 192.168.0.20:8083
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/plain, */*; q=0.01
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
cache-control: no-cache
X-Requested-With: XMLHttpRequest
Origin: http://192.168.0.20:8083
Connection: keep-alive
Referer: http://192.168.0.20:8083/fhem?detail=WZ_Yamaha_ACV
Content-Length: 0
2022.12.05 10:14:29.902 4 : WEB_192.168.0.3_55536 POST /fhem?cmd.WZ_Yamaha_ACV=set%20WZ_Yamaha_ACV%20on&XHR=1&fwcsrf=csrf_117060430164075&fw_id=4517; BUFLEN:0
2022.12.05 10:14:29.902 5 : Cmd: >set WZ_Yamaha_ACV on<
2022.12.05 10:14:29.902 5 : YAMAHA_AVR (WZ_Yamaha_ACV) - set WZ_Yamaha_ACV on
2022.12.05 10:14:29.902 4 : YAMAHA_AVR (WZ_Yamaha_ACV) - append to queue of device WZ_Yamaha_ACV "on": <?xml version="1.0" encoding="utf-8"?><YAMAHA_AV cmd="PUT"><Main_Zone><Power_Control><Power>On</Power></Power_Control></Main_Zone></YAMAHA_AV>
2022.12.05 10:14:29.902 5 : YAMAHA_AVR (WZ_Yamaha_ACV) - no commands currently running, but queue has pending commands. preparing new request
2022.12.05 10:14:29.903 5 : YAMAHA_AVR (WZ_Yamaha_ACV) - checking cmd queue item: 0 (cmd: on, arg: , data: 1, priority: -, at_first: 0, not_before: 0)
2022.12.05 10:14:29.903 5 : YAMAHA_AVR (WZ_Yamaha_ACV) - choosed item 0 as next command
2022.12.05 10:14:29.903 4 : YAMAHA_AVR (WZ_Yamaha_ACV) - send command "on": <?xml version="1.0" encoding="utf-8"?><YAMAHA_AV cmd="PUT"><Main_Zone><Power_Control><Power>On</Power></Power_Control></Main_Zone></YAMAHA_AV>
2022.12.05 10:14:29.903 5 : HttpUtils url=http://192.168.0.63/YamahaRemoteControl/ctrl NonBlocking via http
2022.12.05 10:14:29.903 4 : IP: 192.168.0.63 -> 192.168.0.63
2022.12.05 10:14:29.904 5 : Starting notify loop for WZ_Yamaha_ACV, 1 event(s), first is on
2022.12.05 10:14:29.904 5 : createNotifyHash
2022.12.05 10:14:29.905 5 : YAMAHA_AVR (WZ_Yamaha_ACV) - set WZ_Yamaha_ACV ?
2022.12.05 10:14:29.906 5 : End notify loop for WZ_Yamaha_ACV
2022.12.05 10:14:29.907 4 : WEB: /fhem?cmd.WZ_Yamaha_ACV=set%20WZ_Yamaha_ACV%20on&XHR=1&fwcsrf=csrf_117060430164075&fw_id=4517 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate
2022.12.05 10:14:29.907 5 : HttpUtils request header:
POST /YamahaRemoteControl/ctrl HTTP/1.1
Host: 192.168.0.63
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Content-Length: 142
Content-Type: application/x-www-form-urlencoded
2022-12-05 10:14:29.906 YAMAHA_AVR WZ_Yamaha_ACV on


Wahrscheinlich isses nur eine Kleinigkeit - Allerdings hab ich bisher verbose 5 nie loggen wollen - Eventmonitor reichte bisher immer aus, wenn ich was gesucht habe  :-\

VG
Andreas

Beta-User

Moin.

(Die Events sehen eigentlich gut aus, werden denn die Readings auf der Detailansicht auch rot?)

Für "verbose 5" wäre eigentlich meine Idee gewesen, das nur am AVR einzustellen. Geloggt wir das dann im allgemeinen Log-File, nicht in dem von dem einzelnen Gerät.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Zitat von: Beta-User am 05 Dezember 2022, 10:24:26
Moin.

(Die Events sehen eigentlich gut aus, werden denn die Readings auf der Detailansicht auch rot?)

Für "verbose 5" wäre eigentlich meine Idee gewesen, das nur am AVR einzustellen. Geloggt wir das dann im allgemeinen Log-File, nicht in dem von dem einzelnen Gerät.

Japp die die Readings werden aktualisiert und entsprechend auch eingefärbt

Ja im Logfile hatte ich es nur eingestellt, weil ich keine Idee hatte, warum es nicht geloggt wird. Das Standard Logfile ist leer im zusätzlichen sind immerhin die Events drin



Beta-User

Zitat von: flummy1978 am 05 Dezember 2022, 10:37:15
Japp die die Readings werden aktualisiert und entsprechend auch eingefärbt
:)
Dann brauche ich den vermeintlichen Fehler wohl nicht zu suchen, das scheint dann ein lokales Problem in meinem Browser zu sein, muss ich mal etwas intensiver beleuchten.

Zitat
Ja im Logfile hatte ich es nur eingestellt, weil ich keine Idee hatte, warum es nicht geloggt wird. Das Standard Logfile ist leer im zusätzlichen sind immerhin die Events drin

Hmm, wenn gar nichts geloggt wird, ist FHEM vermutlich im Debug-Modus gestartet und wirft die Infos dann an der Konsole aus. Ist das Testsystem mit der Minimal-cfg bzw. was ist im globalen Logfile eingestellt? "fakelog"?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Zitat von: Beta-User am 05 Dezember 2022, 11:02:28
Dann brauche ich den vermeintlichen Fehler wohl nicht zu suchen, das scheint dann ein lokales Problem in meinem Browser zu sein, muss ich mal etwas intensiver beleuchten.
Hast Du denn ein Beispiel, was ggf NICHT funktioniert hat? Vielleicht kann ich das irgendwie reproduzieren. Ansonsten, wenn es um gelegentliche / seltene Fehler geht, muss ich vielleicht mal etwas intensiver damit rumspielen. Vielleicht hatte ich jetztn einfach nur Glück?

Zitat von: Beta-User am 05 Dezember 2022, 11:02:28
Hmm, wenn gar nichts geloggt wird, ist FHEM vermutlich im Debug-Modus gestartet und wirft die Infos dann an der Konsole aus. Ist das Testsystem mit der Minimal-cfg bzw. was ist im globalen Logfile eingestellt? "fakelog"?
Japp fakelog war drin, aber ähm, es läuft im Docker - KONSOLE war das Stichwort. Hab dort geschaut - warum auch immer wurde dort ein Logfile fhem-%Y-%m-%d.log angelegt,  obowhl in der DEF fhem-%Y-%m.log steht. Nach m Neustart wurde es korrekt angelegt, kann es aber aus FHEM heraus nicht einsehen. Jedoch direkt im Docker Ordner -> JETZT könnte ich Dir jede Zeile liefern, wenn ein bestimmter Abschnitt benötigt wird  ;)

Wenn ich also noch was tun kann - nur zu :)

VG
Andreas

Beta-User

Zitat von: flummy1978 am 05 Dezember 2022, 11:20:37
Hast Du denn ein Beispiel, was ggf NICHT funktioniert hat? Vielleicht kann ich das irgendwie reproduzieren. Ansonsten, wenn es um gelegentliche / seltene Fehler geht, muss ich vielleicht mal etwas intensiver damit rumspielen. Vielleicht hatte ich jetztn einfach nur Glück?
Bei meinen Tests hatte ich den Verstärker (bzw. die beiden Zonen) einfach nur ein- und ausgeschaltet. Es wurde bei diesem einfachen Test dann schlicht die Detailansicht nicht triggernd aktualisiert, also insbesondere "state" wurde nicht rot, und dementsprechend wurde auch das falsche Icon angezeigt. Refresh der Seite und alles war aktuell...


Zitat
JETZT könnte ich Dir jede Zeile liefern, wenn ein bestimmter Abschnitt benötigt wird  ;)
Paßt schon! Das "Problem" hätte sein können, dass irgendwo Code-Teile aufgerufen werden, die ich bei meinem Kurztest übersehen hatte zu importieren. Wenn bei dir aber alles "rund durchläuft" und insbesondere auch keine warnings im Log zu finden sind, ist der Test eigentlich schon beendet und ich werde den Code dann bei Gelegenheit einchecken, wenn mir selbst auch nichts weiter auffällt.

Falls du "lustig" bist, kannst du das gerne dann auch im Echtsystem einfach nutzen, nicht, dass wir doch irgendwas übersehen haben... (Bei mir ist der auch im Echtsystem am laufen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

#13
Zitat von: Beta-User am 05 Dezember 2022, 11:46:41
Falls du "lustig" bist, kannst du das gerne dann auch im Echtsystem einfach nutzen, nicht, dass wir doch irgendwas übersehen haben... (Bei mir ist der auch im Echtsystem am laufen).

Ich wollte ja mein oberes Vorhaben umsetzen und dafür würde das Ding dann live laufen ... Aber irgendwie ist da n Wurm drin (in beiden Versionen):

Gehe ich in den Receiver und wähle dort eine Funktion aus - egal was. Funktioniert es einwandfrei.

2022-12-05 13:05:23.878 YAMAHA_AVR WZ_Yamaha_ACV displayBrightness -3
2022-12-05 13:05:29.650 YAMAHA_AVR WZ_Yamaha_ACV volume 28
2022-12-05 13:05:29.807 YAMAHA_AVR WZ_Yamaha_ACV volume: 30
2022-12-05 13:05:30.118 YAMAHA_AVR WZ_Yamaha_ACV volume: 29
2022-12-05 13:05:30.473 YAMAHA_AVR WZ_Yamaha_ACV volume: 28
2022-12-05 13:05:32.795 YAMAHA_AVR WZ_Yamaha_ACV off
2022-12-05 13:05:32.952 YAMAHA_AVR WZ_Yamaha_ACV off


Gehe ich aber den weg über die eingabezeile und gebe dort ein:  set WZ_Yamaha_ACV volume 35 kommt das (un)geliebte:
Please define WZ_Yamaha_ACV volume 35 first  ???

Edith ergänzt noch: Das dick unterstrichene kann ich anklicken und lande dann im device "WZ_Yamaha_ACV"

Irgendwie sehr merkwürdig das Ganze....

VG
Andreas

Beta-User

...das ist in der Tat sehr seltsam...

Muss ich mir ansehen, aber eine Idee für eine Erklärung habe ich dafür im Moment jedenfalls nicht. Klingt irgendwie eher so, als wäre da was mit der Art und Weise kaputt, wie dein FHEMWEB Befehle interpretiert. Sicherheitshalber: Browser-Cache mal geleert und die FEHEM-Seite komplett neu geladen (ff: strg+f5)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files