- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
FHEM Development / Aw: Zugang zu Github Copilot a...
Letzter Beitrag von Volker Kettenbach - 25 April 2024, 13:44:07Hast Du was herausgefunden?
#2
Anfängerfragen / Sporadische Probleme mit FHEM
Letzter Beitrag von csb13 - 25 April 2024, 13:39:32Hallo Community,
ich habe seit einige Zeit Probleme mit meiner FHEM-Instanz.
Sie läuft auf einem Raspberry Pi4. Das Problem tritt fast täglich zu einer ähnlichen Uhrzeit (zwischen 12:00 und 15:00) auf.
Symptome, die mir aufgefallen sind:
- FHEM-Webinterface ist nicht mehr erreichbar
- Die MQTT-Devices verlieren die Verbindung zum MQTT-Server und die meisten verbinden sich anschließend nicht mehr -> Das sind auch jedes Mal die letzten Logeinträge.
Nach einem
Beispiel-Log:
Das Setzen von
Habt ihr vielleicht eine Idee, woran das liegen kann, bzw., wie ich das Problem analysieren kann?
ich habe seit einige Zeit Probleme mit meiner FHEM-Instanz.
Sie läuft auf einem Raspberry Pi4. Das Problem tritt fast täglich zu einer ähnlichen Uhrzeit (zwischen 12:00 und 15:00) auf.
Symptome, die mir aufgefallen sind:
- FHEM-Webinterface ist nicht mehr erreichbar
- Die MQTT-Devices verlieren die Verbindung zum MQTT-Server und die meisten verbinden sich anschließend nicht mehr -> Das sind auch jedes Mal die letzten Logeinträge.
Nach einem
Code Auswählen
sudo systemctl restart fhem funktioniert wieder alles.Beispiel-Log:
Code Auswählen
2024.04.25 13:09:27 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTTClient_WaWa)
2024.04.25 13:09:27 1: PERL WARNING: Use of uninitialized value $data in concatenation (.) or string at ./FHEM/73_GardenaSmartBridge.pm line 513.
2024.04.25 13:09:27 1: PERL WARNING: Use of uninitialized value $data in numeric gt (>) at ./FHEM/73_GardenaSmartBridge.pm line 515.
2024.04.25 13:09:27 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTTClient_Entfeuchter)
2024.04.25 13:09:27 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTTClient_Heizstab)
2024.04.25 13:09:27 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTTClient_ArduinoUnoNewResol)
2024.04.25 13:09:27 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTTClient_Gaszaehler)
2024.04.25 13:17:48 1: 127.0.0.1:1883 reappeared (MQTTClient_Entfeuchter)Das Setzen von
Code Auswählen
attr global verbose 5 hat mich nicht schlauer gemacht.Habt ihr vielleicht eine Idee, woran das liegen kann, bzw., wie ich das Problem analysieren kann?
#3
Sonstige Systeme / Shelly1 mini Gen3
Letzter Beitrag von Hallerschneider - 25 April 2024, 13:20:22Hallo, ich verfüge bereits über 3 Shelly3em und ein Shelly plus2pm. Das ganze über MQTT2.
Nun ist meine neuste Errungenschaft ein Shelly mini1 Gen3.
Wenn ich das Template für ihn auswähle, ist nichts dabei was ich brauchen kann. Er schaltet nicht, zeigt mir keine Verbindung obwohl die richtige IP erkannt wurde. Die Readings liest Fhem aus, aber steuern kann ich nichts.
Vielleicht ist ein freundlicher Helfer unter uns der es mit mir ernst meint, Danke.
MfG
Peter
Nun ist meine neuste Errungenschaft ein Shelly mini1 Gen3.
Wenn ich das Template für ihn auswähle, ist nichts dabei was ich brauchen kann. Er schaltet nicht, zeigt mir keine Verbindung obwohl die richtige IP erkannt wurde. Die Readings liest Fhem aus, aber steuern kann ich nichts.
Vielleicht ist ein freundlicher Helfer unter uns der es mit mir ernst meint, Danke.
MfG
Peter
#4
Sonstige Systeme / Maple SignalDuino macht kein D...
Letzter Beitrag von weini - 25 April 2024, 13:08:11Ich nutze einen Maple SignalDuino über LAN angeschlossen.
Nach einiger Zeit (wie lange, das habe ich noch nicht genau recherchiert) macht der SD kein DHCP Renewal mehr. Damit kann der Router (akutelles OpenWrt) den Namen nicht mehr auflösen. Für FHEM ist das im laufenden Betrieb normalerweise kein Problem, weil mein Raspi sich die Infos aus dem Cache holt und damit den Namen weiter aufgelöst bekommt.
Wenn jetzt aber FHEM bzw. der Raspi neu gestartet wird, dann findet er den SignalDuino nicht mehr. Der SignalDuino ist auf DHCP eingestellt.
Ist diese Problem schon mal aufgetreten?
Noch eine Zusatzfrage: Kennt der SignalDuino einen Befehl, mit dem man ihn neu starten kann? Ich habe hier https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921 und an ein paar anderen Stellen dazu lieder nichts gefunden. Mit dem Neustart würde er sich dann auch wieder per DHCP eine IP holen und damit würde die Namensauflösung wieder erfolgen.
Code Auswählen
V 4.2.2-dev220712 SIGNALduinoAdv LAN cc1101 (R: A1* B0) - compiled at Jul 13 2022
Nach einiger Zeit (wie lange, das habe ich noch nicht genau recherchiert) macht der SD kein DHCP Renewal mehr. Damit kann der Router (akutelles OpenWrt) den Namen nicht mehr auflösen. Für FHEM ist das im laufenden Betrieb normalerweise kein Problem, weil mein Raspi sich die Infos aus dem Cache holt und damit den Namen weiter aufgelöst bekommt.
Wenn jetzt aber FHEM bzw. der Raspi neu gestartet wird, dann findet er den SignalDuino nicht mehr. Der SignalDuino ist auf DHCP eingestellt.
Ist diese Problem schon mal aufgetreten?
Noch eine Zusatzfrage: Kennt der SignalDuino einen Befehl, mit dem man ihn neu starten kann? Ich habe hier https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921 und an ein paar anderen Stellen dazu lieder nichts gefunden. Mit dem Neustart würde er sich dann auch wieder per DHCP eine IP holen und damit würde die Namensauflösung wieder erfolgen.
#5
Anfängerfragen / Aw: Temperaturmittelwert aus D...
Letzter Beitrag von Kaspi - 25 April 2024, 13:01:32OK. Das leuchtet mir ein. 
Also Readings fest jede Stunde.
Wie kann ich dann mit Hilfe von FHEM einen Mittelwert zwischen zwei beliebigen Zeitpunkten aus der Datenbank generieren?
Also Readings fest jede Stunde.
Wie kann ich dann mit Hilfe von FHEM einen Mittelwert zwischen zwei beliebigen Zeitpunkten aus der Datenbank generieren?
#6
Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...
Letzter Beitrag von Starkstrombastler - 25 April 2024, 12:30:17Zitat von: carlos am 25 April 2024, 09:48:33Bei den readings bzgl. der rangeextender Funktion wäre mein Vorschlag es so zu machen wie im Bild...
So hat man die Readings separiert und kann sie entsprechend in den z.b. MQTT2 tasmota devices über userreadings direkt mit integrieren, hier vor allem den externen/internen Link.
Anregungen willkommen! Die Readings könnten dann so aussehen:
ap_clients_0_extlink http://123.345.123.178:9999
ap_clients_0_intlink http;//123.345.33.4
ap_clients_0_mac AA:BB:CC:DD:EE:FF
ap_clients_0_name myTestShelly
Die Links wären dann so wie bisher klickbar. Allerdings ist der Link dann nicht so einfach z.B. via ReadingsVal() extrahierbar.
Das Reading '..name' wird nur ausgewiesen, wenn eine Name ermittelt werden kann.
Das bisherige Reading (gemäß Beispiel 'ap_clients_0') würde entfallen, um Dopplungen zu vermeiden.
#7
Hard- und Firmware / Aw: ser2net Fehler nach mehrer...
Letzter Beitrag von frank - 25 April 2024, 12:23:17Zitatwenn mehrere Befehle hintereinander abgesetzt werdenwas für befehle meinst du genau?
ZitatRemote end closed connectionschon mal im syslog auf dem anderen pi geschaut?
edit:
dein zauberwort "NOBREAK" im yaml file finde ich immer nur kleingeschrieben zwischen baudrate und local. vielleicht macht es einen unterschied?
also so:
Code Auswählen
connector: serialdev,
/dev/serial/by-id/usb-busware.de_CUL868-if00,
9600n81,
nobreak,
local
#8
Multimedia / Aw: MPD-Device aktualisiert ni...
Letzter Beitrag von RigorM - 25 April 2024, 11:22:42So, habe das aktuelle Update eingespielt und getestet.
Die gute Nachricht: Kein socket_error mehr.
Die schlechte: Das Schema, nach dem sich jetzt die Readings aktualisieren, hat sich geändert, ist allerdings immer noch nicht korrekt.
Zwar wird 'file' nun bei jedem Track Change aktualisiert, nicht mehr nur bei jedem zweiten, dafür aktualisiert sich 'Title' nur noch sporadisch und 'Artist' gar nicht mehr. Zu den übrigen kann ich wenig sagen, da ich hauptsächlich die genannten im Auge behalten habe.
Und für mich persönlich ist das auch gar nicht so relevant, da ich im wesentlichen nur das Reading 'file' auswerte, das ja nun sauber reinkommt, aber richtig sieht es leider immer noch nicht aus, zumal im Device Overview nun regelmäßig Blödsinn angezeigt wird (unsinnige Kombinationen aus Artist und Title, bedingt durch das beschriebene Aktualisierungsverhalten der beiden Readings).
Im verbose 5 log tauchen jetzt die Parts mit MPD_EVENT : player und mpd_cmd[1] -> command_list_begin incl. aller auf dieses Kommando folgenden Ausgaben gar nicht mehr auf. Es wird immer nur noch der folgende Block wiederholt
wobei bei einem Track Change die Ausgabe idle PID xxx found zweimal erfolgt.
Mehr nicht.
Ich hoffe, diese Beobachtungen sind in irgendeiner Form hilfreich.
Die gute Nachricht: Kein socket_error mehr.
Die schlechte: Das Schema, nach dem sich jetzt die Readings aktualisieren, hat sich geändert, ist allerdings immer noch nicht korrekt.
Zwar wird 'file' nun bei jedem Track Change aktualisiert, nicht mehr nur bei jedem zweiten, dafür aktualisiert sich 'Title' nur noch sporadisch und 'Artist' gar nicht mehr. Zu den übrigen kann ich wenig sagen, da ich hauptsächlich die genannten im Auge behalten habe.
Und für mich persönlich ist das auch gar nicht so relevant, da ich im wesentlichen nur das Reading 'file' auswerte, das ja nun sauber reinkommt, aber richtig sieht es leider immer noch nicht aus, zumal im Device Overview nun regelmäßig Blödsinn angezeigt wird (unsinnige Kombinationen aus Artist und Title, bedingt durch das beschriebene Aktualisierungsverhalten der beiden Readings).
Im verbose 5 log tauchen jetzt die Parts mit MPD_EVENT : player und mpd_cmd[1] -> command_list_begin incl. aller auf dieses Kommando folgenden Ausgaben gar nicht mehr auf. Es wird immer nur noch der folgende Block wiederholt
Code Auswählen
2024.04.25 10:55:49 5: myMPD, idle PID 414 found
2024.04.25 10:55:49 5: myMPD, mpd_cmd[1] -> status
2024.04.25 10:55:49 5: myMPD, rec: repeat: 1
2024.04.25 10:55:49 5: myMPD, rec: random: 1
2024.04.25 10:55:49 5: myMPD, rec: single: 0
2024.04.25 10:55:49 5: myMPD, rec: consume: 0
2024.04.25 10:55:49 5: myMPD, rec: partition: default
2024.04.25 10:55:49 5: myMPD, rec: playlist: 2
2024.04.25 10:55:49 5: myMPD, rec: playlistlength: 9225
2024.04.25 10:55:49 5: myMPD, rec: mixrampdb: 0
2024.04.25 10:55:49 5: myMPD, rec: state: play
2024.04.25 10:55:49 5: myMPD, rec: song: 1418
2024.04.25 10:55:49 5: myMPD, rec: songid: 1419
2024.04.25 10:55:49 5: myMPD, rec: time: 246:261
2024.04.25 10:55:49 5: myMPD, rec: elapsed: 246.116
2024.04.25 10:55:49 5: myMPD, rec: bitrate: 128
2024.04.25 10:55:49 5: myMPD, rec: duration: 261.284
2024.04.25 10:55:49 5: myMPD, rec: audio: 44100:24:2
2024.04.25 10:55:49 5: myMPD, rec: nextsong: 3802
2024.04.25 10:55:49 5: myMPD, rec: nextsongid: 3803wobei bei einem Track Change die Ausgabe idle PID xxx found zweimal erfolgt.
Mehr nicht.
Ich hoffe, diese Beobachtungen sind in irgendeiner Form hilfreich.
#9
Sprachsteuerung / Aw: 39_gassistant.pm (Google A...
Letzter Beitrag von kriegerkl - 25 April 2024, 10:39:36Ich nutze den google assistant in FHEM schon einige Jahre.
Seit gestern sind einige Geräte in der Home-App, die sich in FHEM im Raum GoogleAssistant
befinden offline und sind sprachmäßig auch nicht mehr ansteuerbar.
Ich habe schon verschiedene:
set gassistant reload
set gassistant restart
durchgeführt.
Immer das gleiche Ergebnis.
Manche Geräte sind vorhanden, manche nicht.
Gibt es eine Obergrenze an Geräten?
Seit gestern sind einige Geräte in der Home-App, die sich in FHEM im Raum GoogleAssistant
befinden offline und sind sprachmäßig auch nicht mehr ansteuerbar.
Ich habe schon verschiedene:
set gassistant reload
set gassistant restart
durchgeführt.
Immer das gleiche Ergebnis.
Manche Geräte sind vorhanden, manche nicht.
Gibt es eine Obergrenze an Geräten?
#10
Hard- und Firmware / ser2net Fehler nach mehreren B...
Letzter Beitrag von Carsten K. - 25 April 2024, 10:27:52Hallo,
ich habe meinen CUL (Busware) remote konfiguriert.
Leider bekomme ich oft Fehler (letzte Zeile) auf dem CUL-RPI, wenn mehrere Befehle hintereinander abgesetzt werden:
Die ser2net-Config ist:
Ich finde nach vielen Versuchen und Suchen keinen weiteren Ansatz zur Lösung.
Würde mich freuen, wenn jemand mir einen Tipp geben könnte.
VG
Carsten
ich habe meinen CUL (Busware) remote konfiguriert.
Leider bekomme ich oft Fehler (letzte Zeile) auf dem CUL-RPI, wenn mehrere Befehle hintereinander abgesetzt werden:
Code Auswählen
root@rmt-cul01:~# service ser2net status
● ser2net.service - Serial port to network proxy
Loaded: loaded (/lib/systemd/system/ser2net.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2024-04-25 10:01:45 CEST; 10min ago
Docs: man:ser2net(8)
Process: 1328 ExecStartPre=/bin/sleep 60 (code=exited, status=0/SUCCESS)
Main PID: 1329 (ser2net)
Tasks: 1 (limit: 414)
CPU: 282ms
CGroup: /system.slice/ser2net.service
└─1329 /usr/sbin/ser2net -n -c /etc/ser2net.yaml -P /run/ser2net.pid
Apr 25 10:00:45 dien-cul01 systemd[1]: Starting Serial port to network proxy...
Apr 25 10:01:45 dien-cul01 systemd[1]: Started Serial port to network proxy.
Apr 25 10:03:14 dien-cul01 ser2net[1329]: dev read error for device on port busware: Remote end closed connectionDie ser2net-Config ist:
Code Auswählen
%YAML 1.1
---
connection: &busware
accepter: tcp,3099
enable: on
connector: serialdev,
/dev/serial/by-id/usb-busware.de_CUL868-if00,
9600n81,
local,
NOBREAK
options:
kickolduser: true
max-connections: 3Ich finde nach vielen Versuchen und Suchen keinen weiteren Ansatz zur Lösung.
Würde mich freuen, wenn jemand mir einen Tipp geben könnte.
VG
Carsten