jens-maus
Service LED is blinking
Describe the issue you are experiencing
After Update to 20250326 my Service LED of the device is blinking yellow but there are no open "service messages". When I disable Info LED in config it turns out.
Describe the behavior you expected
LED should only blink when there are open service messages
Steps to reproduce the issue
...
What is the version this bug report is based on?
3.81.5.20250326
Which base platform are you running?
tinkerboard (ASUS Tinkerboard, ARM/armhf)
Which HomeMatic/homematicIP radio module are you using?
RPI-RF-MOD
Anything in the logs that might be useful for us?
n.a.
Additional information
No response
Die LED des RPI-RF-MOD kann auch abwechselnd blau+gelb blinken wenn andere Dinge als eine Service-Meldung anstehen. So z.B. wenn ein Gerätefirmware-Update ansteht oder der HMIPServer anderer Meinung ist dem hss_led daemon (der für das blinken zuständig ist) zu signalisieren das eine Service-Meldung via LED blinken notwendig ist.
Um das etwas genauer zu beschreiben hier noch einmal eine überarbeitung der Dokumentation die gerne weiter ergänzt werden kann in Zukunft:
https://github.com/jens-maus/RaspberryMatic/wiki/Administration#rpi-rf-mod
@garosp, the maintainer of this project has decided that the issue/idea you reported does not seem to be relevant for the projects' mission or that it is out of the scope or simply not explained in enough detail. This ticket will therefore be closed and you are advised to better discuss this issue in more detail in the discussion area of this project and then perhaps come back here and open a new issue in case consensus has been achieved within this discussion.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@jens-maus Vielen Dank für die Rückmeldung.
Über die Web-UI wird keine Servicemeldung angezeigt. Alles grün.
Und es stehen auch keine Firmware Updates an. Ich habe Blacks SDV auch mal durchlaufen lassen und auch dort ist nichts in der Richtung auffällig. Alles sauber.
Die LED fing direkt nach dem Update an gelb zu blinken, bis jetzt immer noch.
Im Log steht auch nichts auffälliges.
@Baxxy13 hast du eventuell noch eine Idee?
Wie gesagt, es gibt mehr als nur die Service-Meldungen der WebUI die das blau/gelbe blinken auslösen lassen kann, da sind die WebUI Servicemeldungen nur eine komponente. Beachten musst du auch: Wenn du versteckte Servicemeldungen in der WebUI hast (die kann man ja für geräte deaktivieren) kommen diese servicemeldungen aber trotzdem zum hss_led durch. Ist also ggf. nen Trugschluss zu denken du hast keine WebUI Servicemeldungen nur weil da nen grüner button ist. Schau in der Geräteliste nach ob du Geräte hast die mit NO_SERVICEMSG geflaggt sind, dann kommt das ggf. daher...
Ich hab immer Ideen, manchmal gute manchmal schlechte. 😉
In diesem Fall darf man vermutlich wieder mit dem Finger auf eQ-3 zeigen. Die haben da irgendwas verbockt. Scheint mit FALMOT's zu tun zu haben, siehe: Foren-Link
Die primäre Frage wäre also ob hier bei Euch FALMOT's im Einsatz sind.
Der andere Punkt wäre: [HMCCU-1078] Bei HmIP-WTH werden Fehler bei der Adaptionsfahrt jetzt auch als Service Mitteilung angezeigt. Die Änderung ist nur bei neu angelernten Geräten wirksam.*
Das macht ja grundsätzlich keinen Sinn weil WTH's nichts mit Adaptionsfahrten von eTRV's am Hut haben. Vielleicht wurde hier irgendwie Mist gebaut mit den Servicemeldungen.
Konkret helfen kann ich aber leider nicht, weil ich das (bisher) auf keinem meiner ca. 5 Testsysteme beobachten kann.
Ich hab immer Ideen, manchmal gute manchmal schlechte. 😉
In diesem Fall darf man vermutlich wieder mit dem Finger auf eQ-3 zeigen. Die haben da irgendwas verbockt. Scheint mit FALMOT's zu tun zu haben, siehe: Foren-Link
Die primäre Frage wäre also ob hier bei Euch FALMOT's im Einsatz sind.
Der andere Punkt wäre: [HMCCU-1078] Bei HmIP-WTH werden Fehler bei der Adaptionsfahrt jetzt auch als Service Mitteilung angezeigt. Die Änderung ist nur bei neu angelernten Geräten wirksam.*
Das macht ja grundsätzlich keinen Sinn weil WTH's nichts mit Adaptionsfahrten von eTRV's am Hut haben. Vielleicht wurde hier irgendwie Mist gebaut mit den Servicemeldungen.
Konkret helfen kann ich aber leider nicht, weil ich das (bisher) auf keinem meiner ca. 5 Testsysteme beobachten kann.
Vielen Dank für die Rückmeldung.
Genau, dort im Forum hatte ich auch schon etwas zu geschrieben.
Ich habe 2x FAL-MOT und 10x WTH-2. eTRVs habe ich keine.
Nur im Changelog lese ich nichts von den FAL-MOT wo es eine Adaptionsfahrt gibt.
Und bei den WTHs eine Adaptionsfahrt, gibt es doch nicht.
Super Idee Volltreffer. Ich habe mich gestern gewundert, dass sich die Thermostate, die Direktverknüpfungen mit den Falmots haben, komisch verhalten. Ich musste sie alle durchgehen und einmal die Temperatur verändern, also zum senden zwingen. Habe dem Ganzen aber weiter keine Beachtung geschenkt. Was mir auch aufgefallen ist, war die ersten 30 Minuten mit hohe Duty Cycle und Carrier Sense Werte, die ich sonst nicht kenne. Sorry ich wollte dem Raspberrymatic-Team nicht zu nahe treten - ich kannte das erwähnte Forum noch nicht. Danke für eure Super-Arbeit
Sicher versendet mit Proton Mail.
Baxxy13 @.***> schrieb am Freitag, 28. März 2025 um 15:29:
Ich hab immer Ideen, manchmal gute manchmal schlechte. 😉
In diesem Fall darf man vermutlich wieder mit dem Finger auf eQ-3 zeigen. Die haben da irgendwas verbockt. Scheit mit FALMOT's zu tun zu haben, siehe: Foren-Link
Die primäre Frage wäre also ob hier bei Euch FALMOT's im Einsatz sind.
Der andere Punkt wäre: [HMCCU-1078] Bei HmIP-WTH werden Fehler bei der Adaptionsfahrt jetzt auch als Service Mitteilung angezeigt. Die Änderung ist nur bei neu angelernten Geräten wirksam.*
Das macht ja grundsätzlich keinen Sinn weil WTH's nichts mit Adaptionsfahrten von eTRV's am Hut haben. Vielleicht wurde hier irgendwie Mist gebaut mit den Servicemeldungen.
Konkret helfen kann ich aber leider nicht, weil ich das (bisher) auf keinem meiner ca. 5 Testsysteme beobachten kann.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
[Baxxy13]Baxxy13 left a comment (jens-maus/RaspberryMatic#3069)
Ich hab immer Ideen, manchmal gute manchmal schlechte. 😉
In diesem Fall darf man vermutlich wieder mit dem Finger auf eQ-3 zeigen. Die haben da irgendwas verbockt. Scheit mit FALMOT's zu tun zu haben, siehe: Foren-Link
Die primäre Frage wäre also ob hier bei Euch FALMOT's im Einsatz sind.
Der andere Punkt wäre: [HMCCU-1078] Bei HmIP-WTH werden Fehler bei der Adaptionsfahrt jetzt auch als Service Mitteilung angezeigt. Die Änderung ist nur bei neu angelernten Geräten wirksam.*
Das macht ja grundsätzlich keinen Sinn weil WTH's nichts mit Adaptionsfahrten von eTRV's am Hut haben. Vielleicht wurde hier irgendwie Mist gebaut mit den Servicemeldungen.
Konkret helfen kann ich aber leider nicht, weil ich das (bisher) auf keinem meiner ca. 5 Testsysteme beobachten kann.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Wie gesagt, es gibt mehr als nur die Service-Meldungen der WebUI die das blau/gelbe blinken auslösen lassen kann, da sind die WebUI Servicemeldungen nur eine komponente. Beachten musst du auch: Wenn du versteckte Servicemeldungen in der WebUI hast (die kann man ja für geräte deaktivieren) kommen diese servicemeldungen aber trotzdem zum hss_led durch. Ist also ggf. nen Trugschluss zu denken du hast keine WebUI Servicemeldungen nur weil da nen grüner button ist. Schau in der Geräteliste nach ob du Geräte hast die mit NO_SERVICEMSG geflaggt sind, dann kommt das ggf. daher...
In 8 Jahren Homematic hatte ich dies noch nicht. Das keine Servicemeldung angezeigt wird, obwohl die LED gelb blinkt. Erst bei dieser Version. Auch habe ich im letzten halben Jahr keine Geräteeinstellungen verändert.
Auch in der Geräteliste gibt es keine FLAG.
@Baxxy13 Ich habe nun alle 10x WTH-2 Wandthermostate und meine 2x FAL-MOT Fußbodenheizungsaktoren auf Werkseinstellung zurückgesetzt. Die Geräte haben sich dann von der CCU ihre Config wieder geholt.
Keine Änderung, die gelbe LED blinkt fröhlich weiter. Auf der Web-UI alles grün.
Hast du eine Idee wie man das weiter debuggen kann und den Grund herausfinden kann?
P.s. Die WTH-2 sind automatisch wieder auf den letzten Modi (Auto) zurück gegangen. Das hat geklappt, war ja oft bemängelt worden mit der Firmware 3.0.2.
@jens-maus Scheint kein Einzelfall zu sein. Fällt jetzt auch immer mehr CCU Usern auf:
https://homematic-forum.de/forum/viewtopic.php?p=833226#p833226
https://homematic-forum.de/forum/viewtopic.php?p=832960#p832960
Können wir bitte das Ticket wieder öffnen?
Und was sollen wir dann hier machen? Das ist/wird ein Problem upstream (bei eQ3) sein und sehr gehört das da gemeldet, denn es wird sicher von gewissen Änderungen in HMIPServer kommen der aber closed source ist und auch den folglich nur eQ3 selbst Einfluss hat.
Vielen Dank für die Rückmeldung. Okay, ich habe gedacht wir können das weiter debuggen und eventuell kann dafür dann ein Patch erstellt werden. Dann warten wir mal ab...
Um den Verursacher der Servicemeldungen bzw. den Verursacher für etwaige LED nutzungen herauszufinden einfach mal folgendes in einem laufenden RaspberryMatic System auf der Kommandozeile eingeben:
# monit stop hss_led
# nc -l -u 8182
Danach sollten dann in gewissen Abständen ähnliche Ausgaben wie diese hier eintrudeln:
RFD
RX=true
RFD
SERVICE=10
Das ist dann jeweils der Name des Versachers eine Meldung auf UDP Port 8182 – in diesem Falle RFD gefolgt von der Meldung. Letztere SERVICE=10 bedeutet dann im Grunde das der hss_led (der daemon der für die LED Steuerung verantwortlich ist) da die Info über 10 Servicemeldungen vom RFD Daemon aus geliefert bekommt. So kann man das entsprechend dann debuggen.
Ich habe folgende Codes per SSH eingegeben:
root@Homematic-CCU: # monit stop hss_led root@Homematic-CCU: # nc -l -u 8182
Leider kommen aber keine Ausgaben...!?
Folgende Einträge im LOG:
Mar 30 14:48:09 Homematic-CCU auth.info sshd-session[20242]: Accepted password for root from 192.168.178.37 port 50376 ssh2 Mar 30 14:48:27 Homematic-CCU user.info monit[2156]: 'hss_led' stop on user request Mar 30 14:48:27 Homematic-CCU user.info monit[2156]: Monit daemon with PID 2156 awakened Mar 30 14:48:27 Homematic-CCU user.info monit[2156]: Awakened by User defined signal 1 Mar 30 14:48:27 Homematic-CCU user.info monit[2156]: 'hss_led' stop: '/sbin/start-stop-daemon -K -q -p /var/run/hss_led.pid' Mar 30 14:48:27 Homematic-CCU user.info monit[2156]: 'hss_led' stop action done
Unter DEVCONFIG / Service Messages steht HmIP-RF not running, alle Geräte funktionieren aber.
Ich habe folgende Codes per SSH eingegeben:
root@Homematic-CCU: # monit stop hss_led root@Homematic-CCU: # nc -l -u 8182
Leider kommen aber keine Ausgaben...!?
Na du musst schon abwarten und Tee trinken bzw. du kannst auch gerne rfd und/oder HMIPServer oder ReGaHss mit monit neustarten parallel, dann sollten da ausgaben irgendwann auftauchen.
Unter DEVCONFIG / Service Messages steht
HmIP-RF not running, alle Geräte funktionieren aber.
DevConfig ist devconfig und hat wenig bis nichts zu bedeuten was da steht. Und diese HmIP-RF not running meldung steht da schon immer soweit ich weiss.
Diese "Testmethode" funktioniert nicht bei HmIP. Und wenn es wirklich mit dem FALMOT samt HmIP-Server zusammenhängt sind wir doch eh raus.
Wie schon geschrieben, ich habe keinen FALMOT und alle Testsysteme die blinken könnten tun das nicht. Die mit HmIP-RFUSB sind ja eh raus. 😉
Nicht wirklich. Auch wenn da ein RFUSB werkelt sollte der HMIPserver oder RFD oder ReGaHss auf Port 8082 (UDP) an hss_led ja die Anzahl ihrer Service- oder Alarmmeldungen liefern die dann im Falle eines RPI-RF-MOD eben in das aktivieren dessen LEDs verwandelt wird. D.h. Wenn man statt hss_led einfach eben netcat auf port 8082 lauschen lässt sollten die interface Server (RFD, HMIPServer, etc.) ihre servicemeldungen usw dort wie hier gezeigt melden..
Hmm, hatte ich nach obiger Anleitung von Dir probiert.
Bei Servicemeldungen von HM-Geräten sieht man was, bei Servicemeldungen von IP-Geräten kommt nichts.
Interessant, ich konnte HMIPserver auch noch nicht dazu bewegen was via udp 8082 zu liefern. Aber ich hab ja auch kein betroffenes System bzw. Testsystem wo ich das von den Leuten beschriebenes Problem mit der dauerhaften blinkenden gelben led nachvollziehen konnte. Ich weiß nur das der hss_led Dämon der ist der für das Steuern der RPI-RF-MOD LEDs zuständig ist und neben eigenen internen Checks eben auch solche externen Infos über Service oder alarmmeldungen via Port 8082 udp erhalten kann. Und daher kann es eigentlich nur daher kommen das hier ein Blau/gelbes blinken da ist. Aber wie gesagt, ich bräuchte erstmal ein eigenes Testcase um das auch nachvollziehen zu können. Oder jemand anderes der das gelbe blinken trotz 0 servicemeldungen in der webui hat probiert das mal wie beschrieben zu debuggen...
Hallo, bei mir ist der Fehler ja aufgetreten, und ich habe auch 3 * Falmot-C12 im Einsatz. Ich habe mich gerade auf einem System angemeldet und folgendes wie beschrieben gemacht :
monit stop hss_led
nc -l -u 8182
DIe Meldungen die gekommen sind
RFD RX=true RFD RX=true RFD RX=true RFD RX=true RFD RX=true RFDRX=true
Ich glaube nicht sonderlich aussagekräftig. Kann ich sonst etwas ausprobieren ?
VG
Sicher versendet mit Proton Mail.
Jens Maus @.***> schrieb am Sonntag, 30. März 2025 um 20:13:
Interessant, ich konnte HMIPserver auch noch nicht dazu bewegen was via udp 8082 zu liefern. Aber ich hab ja auch kein betroffenes System bzw. Testsystem wo ich das von den Leuten beschriebenes Problem mit der dauerhaften blinkenden gelben led nachvollziehen konnte. Ich weiß nur das der hss_led Dämon der ist der für das Steuern der RPI-RF-MOD LEDs zuständig ist und neben eigenen internen Checks eben auch solche externen Infos über Service oder alarmmeldungen via Port 8082 udp erhalten kann. Und daher kann es eigentlich nur daher kommen das hier ein Blau/gelbes blinken da ist. Aber wie gesagt, ich bräuchte erstmal ein eigenes Testcase um das auch nachvollziehen zu können. Oder jemand anderes der das gelbe blinken trotz 0 servicemeldungen in der webui hat probiert das mal wie beschrieben zu debuggen...
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
[jens-maus]jens-maus left a comment (jens-maus/RaspberryMatic#3069)
Interessant, ich konnte HMIPserver auch noch nicht dazu bewegen was via udp 8082 zu liefern. Aber ich hab ja auch kein betroffenes System bzw. Testsystem wo ich das von den Leuten beschriebenes Problem mit der dauerhaften blinkenden gelben led nachvollziehen konnte. Ich weiß nur das der hss_led Dämon der ist der für das Steuern der RPI-RF-MOD LEDs zuständig ist und neben eigenen internen Checks eben auch solche externen Infos über Service oder alarmmeldungen via Port 8082 udp erhalten kann. Und daher kann es eigentlich nur daher kommen das hier ein Blau/gelbes blinken da ist. Aber wie gesagt, ich bräuchte erstmal ein eigenes Testcase um das auch nachvollziehen zu können. Oder jemand anderes der das gelbe blinken trotz 0 servicemeldungen in der webui hat probiert das mal wie beschrieben zu debuggen...
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Aber wie gesagt, ich bräuchte erstmal ein eigenes Testcase um das auch nachvollziehen zu können. Oder jemand anderes der das gelbe blinken trotz 0 servicemeldungen in der webui hat probiert das mal wie beschrieben zu debuggen...
Ich versuche morgen auch nochmal eine Ausgabe zu bekommen.
Wer kann und mag kann auch einfach in der /etc/monitrc den gesamten Abschnitt über hss_led auskommentieren und dann in der /etc/init.d/S06InitSystem den Abschnitt wo hss_led normal gestartet wird wie folgt abändern:
# start hss_led if it exists and we are not in HMLGW mode
if [[ "${HM_MODE}" != "HM-LGW" ]] && [[ -x /bin/hss_led ]]; then
/usr/bin/nc -lu 8182 >/tmp/nc.log &
#if [[ ! "${HM_HOST}" =~ oci\|lxc ]]; then
# start-stop-daemon -S -q -b -m -c hssled:hssled -p /var/run/hss_led.pid --exec /bin/hss_led -- -l 6
#else
# start-stop-daemon -S -q -b -m -p /var/run/hss_led.pid --exec /bin/hss_led -- -l 6
#fi
fi
D.h. das /usr/bin/nc .... hinschreiben und dann den rest dort auskommentieren damit der hss_led nicht mehr gestartet wird. Dann einfach die Zentrale neustarten und dann sollte nach dem Neustart in der Datei /tmp/nc.log alle Ausgaben landen die an Port 8082 (UDP) abgeliefert werden. Vielleicht sieht man ja dann dort etwas mehr bei denen die von dem Problem betroffen sind.
bei Servicemeldungen von IP-Geräten kommt nichts.
Nur zur Kontrolle: Legacy.SendUDPServiceMessages = true steht in der crRFD.conf ?
bei Servicemeldungen von IP-Geräten kommt nichts.
Nur zur Kontrolle:
Legacy.SendUDPServiceMessages = truesteht in dercrRFD.conf?
Also hier schon:
root@homematic-raspi:~# grep SendUDPServiceMessages /var/etc/crRFD.conf
Legacy.SendUDPServiceMessages=true
Ja hier auch. Und heute sehe ich auch was wenn ich eine echte IP-Servicemeldung generiere.
# monit stop hss_led
# nc -l -u 8182
HMIP
SERVICE=1
Wer weiß was da gestern geklemmt hat.
Nachdem ich die Servicemeldung "behoben" habe:
HMIP
SERVICE=0
Ja hier auch. Und heute sehe ich auch was wenn ich eine echte IP-Servicemeldung generiere.
# monit stop hss_led # nc -l -u 8182 HMIP SERVICE=1
Okay, mehr bekomme ich auch nicht als Ausgabe.
Ja hier auch. Und heute sehe ich auch was wenn ich eine echte IP-Servicemeldung generiere.
# monit stop hss_led # nc -l -u 8182 HMIP SERVICE=1Okay, mehr bekomme ich auch nicht als Ausgabe.
Na das ist doch schon was. Wenn da SERVICE=1 kommt bedeutet das das es da eine einzelne HmIPServer Servicemeldung gibt und folglich sollte dann hss_led die LED des RPI-RF-MOD blau/gelb blinken lassen. Erst bei SERVICE=0 und wenn kein anderer Schnittstellendienst oder ähnliches weitere Servicefälle melden sollte die LED wieder in konstantes blau wechseln. Soweit die Logik dahinter.
Hilft aber auch nicht so recht weiter.
D.h. jetzt also das eine HmIP-Servicemeldung an den hss_led übergeben wird und in der WebUI nichts zu sehen ist. Also nix neues und verwertbares. Da das auch auf CCU3 auftritt kann es auch kein Problem mit "unterdrückten Servicemeldungen" von RM sein.
Es "fehlt" also erstmal die Servicemeldung in der WebUI um überhaupt zu sagen was es ist. (der FALMOT steht weiterhin auf Platz 1 der Verdächtigen)
D.h. jetzt also das eine HmIP-Servicemeldung an den hss_led übergeben wird und in der WebUI nichts zu sehen ist.
Ist das so? Hast du das reproduzierbar so am laufen? Weil du hast doch kein FALMOT, dachte ich? Zumindest bei denen die betroffen sind (auch die CCU3 nutzer) sollte via UDP 8082 dann nie ein SERVICE=0 vom HmIPServer kommen und es immer mindestens ein SERVICE=1 oder höher geben. Und wer das hat sollte einfach mal das kontrollieren und dann vielleicht auch ein Downgrade auf die 3.79.6 machen und schauen ob da ein SERVICE=0 kommt?!? Dann würde vieles dafür sprechen das der HmIPServer hier in der 3.81.x irgendetwas anders macht und (wenn es am FALMOT liegt) hier ein SERVICE=1 meldet obwohl es keine WebUI Servicemeldungen gibt.
Abgesehen davon halt ich das konzept eigentlich eh für überholt, das jeder Schnittstellenprozess separat die anzahl seiner servicemeldungen meldet. IMHO sollte lediglich ReGaHss hier die Anzahl der WebUI Service- und Alarmmeldungen melden, da dort ohnehin alles zusammenläuft. Aber um das abzuändern müsste es dann eine neue hss_led Version geben die quasi die Meldungen von RFD und HMIPSERVER ignoriert und stattdessen lediglich die REGAHSS Meldungen (sofern sie denn eintrudeln) berücksichtigt.
Es "fehlt" also erstmal die Servicemeldung in der WebUI um überhaupt zu sagen was es ist. (der FALMOT steht weiterhin auf Platz 1 der Verdächtigen)
Kann gut sein das hier bzgl. des FALMOT irgendetwas geändert wurde was zwar das SERVICE=1 via Port 8082 meldet, aber die WebUI nicht triggern lässt.