- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
FHEMapp / Aw: FHEMApp4 - Beta Version
Letzter Beitrag von binford6000 - 23 April 2024, 18:34:49Hi Benni,
und den fhemapp4 Ordner in www und ganz von vorne angefangen. Weiter wie oben zu sehen bin ich nie gekommen.
In der Haupt-FHEM-Instanz hatt ich nie Probleme dieser Art...
VG Sebastian
ZitatVerstehe ich es richtig, dass eine Erstinstallation irgendwann mal über das Modul funktioniert hat?Genau. Ein Update von .37 auf .38 ist mit dem gleichen Fehler fehlgeschlagen. Daraufhin hab ich das gesamte device gelöscht
und den fhemapp4 Ordner in www und ganz von vorne angefangen. Weiter wie oben zu sehen bin ich nie gekommen.
ZitatAnsonsten, hast du das ZIP-File "manuell" auf dem Rechner direkt heruntergeladen? Falls ja, wie und unter welchem User?Ja das hab ich mit dem User seb wie oben zu sehen. Das hat dann anstandslos geklappt.
ZitatMehr fällt mir im Moment leider nicht ein!Wer weiß was das war. Bin mal gespannt wie es dann von beta auf master ausieht.
In der Haupt-FHEM-Instanz hatt ich nie Probleme dieser Art...
VG Sebastian
#2
FHEM Code changes / Revision 28818: 50_Signalbot: ...
Letzter Beitrag von System - 23 April 2024, 18:30:19Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
50_Signalbot: Installer update to signal-cli 0.13.3
Source: Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
50_Signalbot: Installer update to signal-cli 0.13.3
Source: Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
#3
MQTT / zigbee bridge log message even...
Letzter Beitrag von Motivierte linke Hände - 23 April 2024, 18:27:48Hi - Ich habe hier einiges an MQTT Geräten in fhem - viele direkt (Tasmota, Shelly), andere über zigbee2mqtt. zigbee2mqtt habe ich eingebunden, wie im Wiki vorgeschlagen. Das läuft auch gut.
Nur eine Detailfrage habe ich: Ich sehe, dass die MQTT Bridge viele Events (teilweise mehrere pro Sekunde) mit Log-Einträgen produziert, die zu konfigurierten Systemen gehören, wie z.B. (aus dem Event-Monitor kopiert):
Ich weiß, dass ich durch die event-Attribute diese log_message Events abstellen könnte. Ich weiß allerdings nicht, und habe auch in der Commandref nicht gefunden, ob diese Events für die Funktionalität gebraucht werden (z.B. indem das dann umgesetzt wird in Readings für die Devices oder weil es für autocreate benötigt wird oder, oder, oder...).
Ergo: Mache ich was kaputt, wenn ich das Erzeugen von Events für diese log_message Einträge (oder die Bridge insgesamt) abstelle? Ich selbst brauche keine Events von der Bridge, die von den konfigurierten Geräten reichen.
Danke!
Nur eine Detailfrage habe ich: Ich sehe, dass die MQTT Bridge viele Events (teilweise mehrere pro Sekunde) mit Log-Einträgen produziert, die zu konfigurierten Systemen gehören, wie z.B. (aus dem Event-Monitor kopiert):
Code Auswählen
MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lt_Vorratskeller', payload '{"brightness_relay":254,"linkquality":10,"state":"OFF","state_relay":"OFF"}'Ich weiß, dass ich durch die event-Attribute diese log_message Events abstellen könnte. Ich weiß allerdings nicht, und habe auch in der Commandref nicht gefunden, ob diese Events für die Funktionalität gebraucht werden (z.B. indem das dann umgesetzt wird in Readings für die Devices oder weil es für autocreate benötigt wird oder, oder, oder...).
Ergo: Mache ich was kaputt, wenn ich das Erzeugen von Events für diese log_message Einträge (oder die Bridge insgesamt) abstelle? Ich selbst brauche keine Events von der Bridge, die von den konfigurierten Geräten reichen.
Danke!
#4
Unterstützende Dienste / Aw: Telegram instant messaging...
Letzter Beitrag von fhem_olsi - 23 April 2024, 18:08:391) Portfreigabe (auf Router) für den FHEM-Rechner
2) Termius-App (Smartphone) installieren
3) Port Forwarding in Termius einrichten
4) Mit Browser (Smartphone) auf 127.0.0.1:8083 zugreifen
Gruß
Wolfgang
2) Termius-App (Smartphone) installieren
3) Port Forwarding in Termius einrichten
4) Mit Browser (Smartphone) auf 127.0.0.1:8083 zugreifen
Gruß
Wolfgang
#5
FHEMapp / Aw: FHEMApp4 - Beta Version
Letzter Beitrag von Benni - 23 April 2024, 17:46:53Zitat von: binford6000 am 22 April 2024, 08:11:19ich habe auf einem weiteren FHEM (OS: Raspbian GNU/Linux 11 (bullseye) armv6l) versucht, FHEMApp auf die letzte Version zu aktualisieren.
Das hat nicht funktioniert:
Daraufhin habe ich ALLES (Device+conf und FHEMApp-Verzeichnis in www) gelöscht und von vorne angefangen.
Das Ergebnis ist leider das Gleiche mit obigen Fehlern. Auf einem Docker-FHEM läuft der Vorgang mit Löschen + Neuanlegen dagegen problemlos durch.
Was läuft denn da schief?
Update: Mit Verbose 4/5 kommt noch das hier:Code Auswählen2024.04.22 08:15:58.347 5: [myapp]: http-header:
2024.04.22 08:15:58.362 4: [myapp]: error while requesting https://codeload.github.com/jemu75/fhemApp/legacy.tar.gz/refs/tags/v4.0.38-beta - read from https://codeload.github.com:443 timed out
github ist aber erreichbar:Code Auswählenseb@pi0:/ $ ping codeload.github.com
PING codeload.github.com (140.82.121.10) 56(84) bytes of data.
64 bytes from lb-140-82-121-10-fra.github.com (140.82.121.10): icmp_seq=1 ttl=57 time=16.4 ms
64 bytes from lb-140-82-121-10-fra.github.com (140.82.121.10): icmp_seq=2 ttl=57 time=19.2 ms
Wenn ich das .zip-File manuell herunterlade/entpacke funktioniert FHEMApp ganz normal.
Verstehe ich es richtig, dass eine Erstinstallation irgendwann mal über das Modul funktioniert hat?
Ansonsten, hast du das ZIP-File "manuell" auf dem Rechner direkt heruntergeladen?
Falls ja, wie und unter welchem User?
Ansonsten mal per wget, auf dem Rechne den Download versuchen unter dem User, unter dem auch FHEM läuft. Am besten mit Option -v Verbose
Code Auswählen
wget -v https://api.github.com/repos/jemu75/fhemApp/tarball/v4.0.38-beta
Mehr fällt mir im Moment leider nicht ein!
gb#
#6
Homematic / Aw: HM-LC-Ja1PBU-FM Verbindung...
Letzter Beitrag von frank - 23 April 2024, 17:15:58nach der bauanleitung müsste es hier c27 sein.
https://files2.elv.com/public/15/1500/150093/Internet/150093_homematic_jalousiesteuerung.pdf
https://files2.elv.com/public/15/1500/150093/Internet/150093_homematic_jalousiesteuerung.pdf
Zitat von: NewMatic am 23 April 2024, 16:45:13Teils funktioniert es ohne Probleme. dann reagiert er manchmal verzögert (im Sekunden Bereich), und reagiert "teils" gar nicht mehr.möglich, dass beim hochfahren plus senden das netzteil am meisten belastet wird und dadurch das funkmodul ausfällt. nach entsprechender pause erholt es sich?
ZitatWas genau ist mit der 1% regel bei #3 gemeint?jeder sender darf pro stunde nur 1% der zeit senden (overload).
#7
Homematic / Aw: HM-LC-Ja1PBU-FM Verbindung...
Letzter Beitrag von NewMatic - 23 April 2024, 16:45:13Moin,
erstmal danke für deine Hilfe!
da alle anderen aktoren mit dem gleichen hmuart sauber funktioniere/kommunizieren, tippe ich stark auf #2 oder #3.
Was genau ist mit der 1% regel bei #3 gemeint?
Der Aktor zeigt ein ganz komisches Verhalten.
Teils funktioniert es ohne Probleme. dann reagiert er manchmal verzögert (im Sekunden Bereich), und reagiert "teils" gar nicht mehr.
Wie finde ich den kaputten Kondensator?oder ist das immer der "selbe" bei dem Aktormodell?
Danke nochmal!
erstmal danke für deine Hilfe!
Zitat von: frank am 23 April 2024, 14:20:49es gibt viele möglichkeiten, warum keine antworten zu sehen sind.
1. hmuart hat die cmd nicht gesendet
2. device hat die cmd nicht gehört
3. device konnte keine antworten senden, wegen 1% regel
4. hmuart hat die antworten nicht gehört
da alle anderen aktoren mit dem gleichen hmuart sauber funktioniere/kommunizieren, tippe ich stark auf #2 oder #3.
Was genau ist mit der 1% regel bei #3 gemeint?
Der Aktor zeigt ein ganz komisches Verhalten.
Teils funktioniert es ohne Probleme. dann reagiert er manchmal verzögert (im Sekunden Bereich), und reagiert "teils" gar nicht mehr.
Wie finde ich den kaputten Kondensator?oder ist das immer der "selbe" bei dem Aktormodell?
Danke nochmal!
#8
Multimedia / MPD-Device aktualisiert nicht ...
Letzter Beitrag von RigorM - 23 April 2024, 16:29:56Hallo zusammen,
dies ist mein erster Beitrag im Forum, und ich bin entsprechend nervös, also seid bitte nachsichtig mit mir. falls ich einiges nicht sofort richtig mache. Ich verspreche zu lernen.
Seit sechs Jahren betreibe ich einen FHEM-Server in meinem Häuschen und habe mich bislang mithilfe dieses Forums (großes Dankeschön!) und anderer Quellen eingentlich immer gut durchgewurschtelt und alles umsetzen können, was ich wollte. Jetzt aber bin ich auf ein Problem gestoßen, das meinen Horizont überfordert und zu dem ich auch nach intensiven Recherchen keine Lösung gefunden habe, so dass ich es nunmehr einmal an die Experten heranzutragen versuche.
Folgende Situation:
FHEM läuft auf einem Raspi 2 unter Debian Raspi Linux 4.14.34-v7+.
Auf der gleichen Maschine läuft ein mpd, ein weiterer auf einem anderen Raspi im LAN (Raspi 4 unter Debian Raspi4 Linux 6.6.20+rpt-rpi-v8).
Beide mpds überwache ich in FHEM mit je einem MPD-Device.
Das MPD-Device für den lokalen mpd aktualisiert alle seine Readings zufriedenstellend.
Das für den mpd auf dem Remote-Raspi allerdings aktualisiert gewisse Readings (z. B. file & Title) nur für jedes zweite Lied.
Das Problem ist reproduzierbar in einem anderen FHEM mit frisch definiertem MPD-Device.
Eine Neuinstallation von mpd auf dem Remote-Raspi hat das Problem nicht behoben.
Ein verbose = 5 auf dem problematischen MPD-Device ergibt u. a. Folgendes (auffällige Einträge hervorgehoben):
Auffällig ist hier der Fehler socket_error, der aber auch bei dem anderen, unproblematischen MPD-Device regelmäßig auftritt, so dass das eigentlich kein Hinweis auf die Ursache sein kann.
Allerdings ist genau dieses Lied, bei dem der Fehler auftritt, dasjenige, dessen Readings komplett aktualisiert werden.
Beim nächsten Lied kommt dann jedoch kein MPD_EVENT : player mehr, und die Readings 'file', 'Title' und 'rawTitle' werden nicht aktualisiert.
Beim übernächsten Lied kommt es wieder - zusammen mit dem socket_error. Und nun werden auch wieder alle Readings aktualisiert.
Beim unproblematischen MPD hingegen kommt vor jedem neuen Lied ein MPD_EVENT : player.
Hier ein Auszug aus den Internals für das problematische MPD-Device:
Und hier für das unproblematische:
Und hier noch einige Versionsinformationen:
mpd (lokal): 0.19.21
mpd (remote, der problematische): 0.23.12
FHEM rev.: 28809
fhem.pl rev.: 28666
73_MPD.pm rev.: 27027
Hat irgendwer 'ne Ahnung, was hier vor sich gehen könnte?
Da ich persönlich eher mittelmäßig in der Materie verwurzelt bin, wäre ich für jeden Hinweis, in welche Richtung ich weitergehen sollte, dankbar.
LG
Rigor
dies ist mein erster Beitrag im Forum, und ich bin entsprechend nervös, also seid bitte nachsichtig mit mir. falls ich einiges nicht sofort richtig mache. Ich verspreche zu lernen.
Seit sechs Jahren betreibe ich einen FHEM-Server in meinem Häuschen und habe mich bislang mithilfe dieses Forums (großes Dankeschön!) und anderer Quellen eingentlich immer gut durchgewurschtelt und alles umsetzen können, was ich wollte. Jetzt aber bin ich auf ein Problem gestoßen, das meinen Horizont überfordert und zu dem ich auch nach intensiven Recherchen keine Lösung gefunden habe, so dass ich es nunmehr einmal an die Experten heranzutragen versuche.
Folgende Situation:
FHEM läuft auf einem Raspi 2 unter Debian Raspi Linux 4.14.34-v7+.
Auf der gleichen Maschine läuft ein mpd, ein weiterer auf einem anderen Raspi im LAN (Raspi 4 unter Debian Raspi4 Linux 6.6.20+rpt-rpi-v8).
Beide mpds überwache ich in FHEM mit je einem MPD-Device.
Das MPD-Device für den lokalen mpd aktualisiert alle seine Readings zufriedenstellend.
Das für den mpd auf dem Remote-Raspi allerdings aktualisiert gewisse Readings (z. B. file & Title) nur für jedes zweite Lied.
Das Problem ist reproduzierbar in einem anderen FHEM mit frisch definiertem MPD-Device.
Eine Neuinstallation von mpd auf dem Remote-Raspi hat das Problem nicht behoben.
Ein verbose = 5 auf dem problematischen MPD-Device ergibt u. a. Folgendes (auffällige Einträge hervorgehoben):
Code Auswählen
2024.04.22 22:12:12 5: myMPD, idle PID 16142 found
2024.04.22 22:12:12 5: myMPD, mpd_cmd[1] -> status
2024.04.22 22:12:12 5: myMPD, rec: repeat: 1
2024.04.22 22:12:12 5: myMPD, rec: random: 1
2024.04.22 22:12:12 5: myMPD, rec: single: 0
2024.04.22 22:12:12 5: myMPD, rec: consume: 0
2024.04.22 22:12:12 5: myMPD, rec: partition: default
2024.04.22 22:12:12 5: myMPD, rec: playlist: 2
2024.04.22 22:12:12 5: myMPD, rec: playlistlength: 9225
2024.04.22 22:12:12 5: myMPD, rec: mixrampdb: 0
2024.04.22 22:12:12 5: myMPD, rec: state: play
2024.04.22 22:12:12 5: myMPD, rec: song: 8766
2024.04.22 22:12:12 5: myMPD, rec: songid: 8767
2024.04.22 22:12:12 5: myMPD, rec: time: 142:152
2024.04.22 22:12:12 5: myMPD, rec: elapsed: 142.254
2024.04.22 22:12:12 5: myMPD, rec: bitrate: 0
2024.04.22 22:12:12 5: myMPD, rec: duration: 152.000
2024.04.22 22:12:12 5: myMPD, rec: audio: 44100:f:2
2024.04.22 22:12:12 5: myMPD, rec: nextsong: 7925
2024.04.22 22:12:12 5: myMPD, rec: nextsongid: 7926
!--------------------------------------------------------------
2024.04.22 22:12:22 5: myMPD, MPD_EVENT : player
2024.04.22 22:12:22 4: myMPD, MPD_EVENT : player
!--------------------------------------------------------------
2024.04.22 22:12:22 5: myMPD, mpd_cmd[1] -> command_list_begin
status
stats
currentsong
command_list_end
2024.04.22 22:12:22 5: myMPD, rec: repeat: 1
2024.04.22 22:12:22 5: myMPD, rec: random: 1
2024.04.22 22:12:22 5: myMPD, rec: single: 0
2024.04.22 22:12:22 5: myMPD, rec: consume: 0
2024.04.22 22:12:22 5: myMPD, rec: partition: default
2024.04.22 22:12:22 5: myMPD, rec: playlist: 2
2024.04.22 22:12:22 5: myMPD, rec: playlistlength: 9225
2024.04.22 22:12:22 5: myMPD, rec: mixrampdb: 0
2024.04.22 22:12:22 5: myMPD, rec: state: play
2024.04.22 22:12:22 5: myMPD, rec: song: 7925
2024.04.22 22:12:22 5: myMPD, rec: songid: 7926
2024.04.22 22:12:22 5: myMPD, rec: time: 0:409
2024.04.22 22:12:22 5: myMPD, rec: elapsed: 0.000
2024.04.22 22:12:22 5: myMPD, rec: bitrate: 128
2024.04.22 22:12:22 5: myMPD, rec: duration: 408.829
2024.04.22 22:12:22 5: myMPD, rec: audio: 44100:24:2
2024.04.22 22:12:22 5: myMPD, rec: nextsong: 7288
2024.04.22 22:12:22 5: myMPD, rec: nextsongid: 7289
2024.04.22 22:12:22 5: myMPD, rec: uptime: 10734
2024.04.22 22:12:22 5: myMPD, rec: playtime: 10735
2024.04.22 22:12:22 5: myMPD, rec: artists: 2508
2024.04.22 22:12:22 5: myMPD, rec: albums: 1260
2024.04.22 22:12:22 5: myMPD, rec: songs: 9225
2024.04.22 22:12:22 5: myMPD, rec: db_playtime: 2105031
2024.04.22 22:12:22 5: myMPD, rec: db_update: 1713802306
2024.04.22 22:12:22 5: myMPD, rec: file: International/T/Type O Negative/October Rust/Type O Negative - Red Water (Christmas Mourning).mp3
2024.04.22 22:12:22 5: myMPD, rec: Last-Modified: 2020-10-29T14:51:32Z
2024.04.22 22:12:22 5: myMPD, rec: Format: 44100:24:2
2024.04.22 22:12:22 5: myMPD, rec: Artist: Type O Negative
2024.04.22 22:12:22 5: myMPD, rec: Title: Red Water (Christmas Mourning)
2024.04.22 22:12:22 5: myMPD, rec: Album: October Rust
2024.04.22 22:12:22 5: myMPD, rec: Date: 1996
2024.04.22 22:12:22 5: myMPD, rec: Genre: Rock
2024.04.22 22:12:22 5: myMPD, rec: Time: 409
2024.04.22 22:12:22 5: myMPD, rec: duration: 408.829
2024.04.22 22:12:22 5: myMPD, rec: Pos: 7925
2024.04.22 22:12:22 5: myMPD, rec: Id: 7926
!--------------------------------------------------------------
2024.04.22 22:12:22 5: myMPD, new Playlist in ->
2024.04.22 22:12:22 5: myMPD, IdleDone -> myMPD|socket error
2024.04.22 22:12:22 4: myMPD, idle error -> socket error
2024.04.22 22:12:37 4: myMPD, Idle new PID : 16558
!--------------------------------------------------------------
2024.04.22 22:12:37 5: myMPD, mpd_cmd[1] -> command_list_begin
status
stats
currentsong
command_list_end
2024.04.22 22:12:37 5: myMPD, rec: repeat: 1
2024.04.22 22:12:37 5: myMPD, rec: random: 1
2024.04.22 22:12:37 5: myMPD, rec: single: 0
2024.04.22 22:12:37 5: myMPD, rec: consume: 0
2024.04.22 22:12:37 5: myMPD, rec: partition: default
2024.04.22 22:12:37 5: myMPD, rec: playlist: 2
2024.04.22 22:12:37 5: myMPD, rec: playlistlength: 9225
2024.04.22 22:12:37 5: myMPD, rec: mixrampdb: 0
2024.04.22 22:12:37 5: myMPD, rec: state: play
2024.04.22 22:12:37 5: myMPD, rec: song: 7925
2024.04.22 22:12:37 5: myMPD, rec: songid: 7926
2024.04.22 22:12:37 5: myMPD, rec: time: 15:409
2024.04.22 22:12:37 5: myMPD, rec: elapsed: 15.124
2024.04.22 22:12:37 5: myMPD, rec: bitrate: 128
2024.04.22 22:12:37 5: myMPD, rec: duration: 408.829
2024.04.22 22:12:37 5: myMPD, rec: audio: 44100:24:2
2024.04.22 22:12:37 5: myMPD, rec: nextsong: 7288
2024.04.22 22:12:37 5: myMPD, rec: nextsongid: 7289
2024.04.22 22:12:37 5: myMPD, rec: uptime: 10749
2024.04.22 22:12:37 5: myMPD, rec: playtime: 10750
2024.04.22 22:12:37 5: myMPD, rec: artists: 2508
2024.04.22 22:12:37 5: myMPD, rec: albums: 1260
2024.04.22 22:12:37 5: myMPD, rec: songs: 9225
2024.04.22 22:12:37 5: myMPD, rec: db_playtime: 2105031
2024.04.22 22:12:37 5: myMPD, rec: db_update: 1713802306
2024.04.22 22:12:37 5: myMPD, rec: file: International/T/Type O Negative/October Rust/Type O Negative - Red Water (Christmas Mourning).mp3
2024.04.22 22:12:37 5: myMPD, rec: Last-Modified: 2020-10-29T14:51:32Z
2024.04.22 22:12:37 5: myMPD, rec: Format: 44100:24:2
2024.04.22 22:12:37 5: myMPD, rec: Artist: Type O Negative
2024.04.22 22:12:37 5: myMPD, rec: Title: Red Water (Christmas Mourning)
2024.04.22 22:12:37 5: myMPD, rec: Album: October Rust
2024.04.22 22:12:37 5: myMPD, rec: Date: 1996
2024.04.22 22:12:37 5: myMPD, rec: Genre: Rock
2024.04.22 22:12:37 5: myMPD, rec: Time: 409
2024.04.22 22:12:37 5: myMPD, rec: duration: 408.829
2024.04.22 22:12:37 5: myMPD, rec: Pos: 7925
2024.04.22 22:12:37 5: myMPD, rec: Id: 7926
2024.04.22 22:12:37 5: myMPD, mpd_cmd[2] -> command_list_begin
status
stats
currentsong
command_list_end
2024.04.22 22:12:52 5: myMPD, idle PID 16558 found
2024.04.22 22:12:52 5: myMPD, mpd_cmd[1] -> status
2024.04.22 22:12:52 5: myMPD, rec: repeat: 1
2024.04.22 22:12:52 5: myMPD, rec: random: 1
2024.04.22 22:12:52 5: myMPD, rec: single: 0
2024.04.22 22:12:52 5: myMPD, rec: consume: 0
2024.04.22 22:12:52 5: myMPD, rec: partition: default
2024.04.22 22:12:52 5: myMPD, rec: playlist: 2
2024.04.22 22:12:52 5: myMPD, rec: playlistlength: 9225
2024.04.22 22:12:52 5: myMPD, rec: mixrampdb: 0
2024.04.22 22:12:52 5: myMPD, rec: state: play
2024.04.22 22:12:52 5: myMPD, rec: song: 7925
2024.04.22 22:12:52 5: myMPD, rec: songid: 7926
2024.04.22 22:12:52 5: myMPD, rec: time: 30:409
2024.04.22 22:12:52 5: myMPD, rec: elapsed: 30.088
2024.04.22 22:12:52 5: myMPD, rec: bitrate: 128
2024.04.22 22:12:52 5: myMPD, rec: duration: 408.829
2024.04.22 22:12:52 5: myMPD, rec: audio: 44100:24:2
2024.04.22 22:12:52 5: myMPD, rec: nextsong: 7288
2024.04.22 22:12:52 5: myMPD, rec: nextsongid: 7289Auffällig ist hier der Fehler socket_error, der aber auch bei dem anderen, unproblematischen MPD-Device regelmäßig auftritt, so dass das eigentlich kein Hinweis auf die Ursache sein kann.
Allerdings ist genau dieses Lied, bei dem der Fehler auftritt, dasjenige, dessen Readings komplett aktualisiert werden.
Beim nächsten Lied kommt dann jedoch kein MPD_EVENT : player mehr, und die Readings 'file', 'Title' und 'rawTitle' werden nicht aktualisiert.
Beim übernächsten Lied kommt es wieder - zusammen mit dem socket_error. Und nun werden auch wieder alle Readings aktualisiert.
Beim unproblematischen MPD hingegen kommt vor jedem neuen Lied ein MPD_EVENT : player.
Hier ein Auszug aus den Internals für das problematische MPD-Device:
Code Auswählen
define MPD_local MPD 192.168.178.40 6600
attr MPD_local devStateIcon play:rc_PLAY:stop stop:rc_STOP:play pause:rc_PAUSE:pause error:icoBlitz
attr MPD_local icon it_radio
attr MPD_local loadMusic 0
attr MPD_local loadPlaylists 0
attr MPD_local no_playlistcollection 1
attr MPD_local player mpd
attr MPD_local titleSplit 1
attr MPD_local unknown_artist_image /fhem/icons/1px-spacer
attr MPD_local verbose 5
attr MPD_local waits 15
# DEF 192.168.178.40 6600
# DeviceName 192.168.178.40:6600
# FUUID 659c465f-f33f-3b1b-687c-9d8d598910939ba3
# HOST 192.168.178.40
# IPID 13129
# NAME MPD_local
# NR 269
# PORT 6600
# PRESENCE present
# STATE play
# SUBVERSION 23
# TIMEOUT 0.7
# TYPE MPD
# VERSION 0.23.5
# eventCount 9325
# mute -1
# helper:
# RUNNING_PID:
# abortArg
# abortFn
# arg MPD_local
# bc_pid 44845
# finishFn MPD_IdleDone
# fn MPD_IdleStart
# pid 13129
# timeout
# playlistcollection:
# val -1
Und hier für das unproblematische:
Code Auswählen
define MPD_remote MPD
attr MPD_remote devStateIcon play:rc_PLAY:stop stop:rc_STOP:play pause:rc_PAUSE:pause error:icoBlitz
attr MPD_remote icon it_radio
attr MPD_remote loadMusic 0
attr MPD_remote loadPlaylists 0
attr MPD_remote no_playlistcollection 1
attr MPD_remote player mpd
attr MPD_remote titleSplit 1
attr MPD_remote unknown_artist_image /fhem/icons/1px-spacer
attr MPD_remote verbose 5
attr MPD_remote waits 15
# DeviceName 127.0.0.1:6600
# FUUID 61444f90-f33f-3b1b-5541-f87ec1b1ec77cb43
# HOST 127.0.0.1
# IPID 14481
# NAME MPD_remote
# NR 208
# PORT 6600
# PRESENCE present
# STATE play
# SUBVERSION 19
# TIMEOUT 0.7
# TYPE MPD
# VERSION 0.19.0
# eventCount 13063
# mute -1
# helper:
# RUNNING_PID:
# abortArg
# abortFn
# arg MPD_remote
# bc_pid 45199
# finishFn MPD_IdleDone
# fn MPD_IdleStart
# pid 14481
# timeout
# playlistcollection:
# val -1
Und hier noch einige Versionsinformationen:
mpd (lokal): 0.19.21
mpd (remote, der problematische): 0.23.12
FHEM rev.: 28809
fhem.pl rev.: 28666
73_MPD.pm rev.: 27027
Hat irgendwer 'ne Ahnung, was hier vor sich gehen könnte?
Da ich persönlich eher mittelmäßig in der Materie verwurzelt bin, wäre ich für jeden Hinweis, in welche Richtung ich weitergehen sollte, dankbar.
LG
Rigor
#9
Unterstützende Dienste / Aw: Telegram instant messaging...
Letzter Beitrag von Gisbert - 23 April 2024, 16:08:04Hallo,
gibt es eine Möglichkeit per https eine Nachricht vom Handy aus zu Fhem zu schicken?
Den umgekehrten Weg bzw. vom Browser zur Telegram-App kenne ich, den findet man rasch, wenn man googelt. Da kann man etwas zur Telegram-App schicken.
Ich kenne natürlich auch den Weg, von der Telegram-App etwas zu Fhem zu schicken und auch über den gleichen Weg Befehle in Fhem auszuführen.
Was mir fehlt ist ein Weg im Browser auf dem Handy zu Fhem. Falls es etwas derartiges gibt, dann bitte ich eine Info, wie es geht.
Viele Grüße Gisbert
gibt es eine Möglichkeit per https eine Nachricht vom Handy aus zu Fhem zu schicken?
Den umgekehrten Weg bzw. vom Browser zur Telegram-App kenne ich, den findet man rasch, wenn man googelt. Da kann man etwas zur Telegram-App schicken.
Ich kenne natürlich auch den Weg, von der Telegram-App etwas zu Fhem zu schicken und auch über den gleichen Weg Befehle in Fhem auszuführen.
Was mir fehlt ist ein Weg im Browser auf dem Handy zu Fhem. Falls es etwas derartiges gibt, dann bitte ich eine Info, wie es geht.
Viele Grüße Gisbert
#10
Zigbee / Aw: tradfri-fhem tester gesuch...
Letzter Beitrag von tomcat.x - 23 April 2024, 15:19:12Mir ist gerade beim Herumspielen und Vergleichen von Tradfri Bewegungsmeldern, die ich entweder per Tradffri Gateway oder DeCONZ angebunden habe, folgendes aufgefallen: Bei allen per tradfri angebundenen bekomme ich Readings und Events für battery, batteryPercent und reachable mit falschen Zeitstempeln. Ich dachte immer, diese Readings werden nur alle paar Stunden oder einmal am Tag aktualisiert. Jetzt stelle ich aber fest, dass die mit jeder Bewegungserkennung kommen, aber mit falscher Zeit. Für einige habe ich Logs. Da sehe ich, dass über den ganzen Tag der Zeitstempel der gleiche ist. Manchmal (selten) ändert sich auch das Datum nicht mit dem Tageswechsel, es gibt einzelne Tage ohne Einträge und beispielsweise bekomme ich heute noch Einträge mit Datum von gestern.
Sehen kann ich das Ganze im Event-Monitor, da kommen zwischen Events mit richtiger Zeit dann die der Bewegungsmelder mit falscher. Oder im Gerät selbst, da werden die Zeitstempel der drei Readings bei einer Bewegungserkennung auf einmal rot, aber Datum und Uhrzeit ändern sich nicht.
Ist das ein Problem in meiner Installation oder ein generelles? Hat jemand eine Idee, woran das dann liegen könnte?
Viele Grüße
Thomas
Sehen kann ich das Ganze im Event-Monitor, da kommen zwischen Events mit richtiger Zeit dann die der Bewegungsmelder mit falscher. Oder im Gerät selbst, da werden die Zeitstempel der drei Readings bei einer Bewegungserkennung auf einmal rot, aber Datum und Uhrzeit ändern sich nicht.
Ist das ein Problem in meiner Installation oder ein generelles? Hat jemand eine Idee, woran das dann liegen könnte?
Viele Grüße
Thomas