[Erledigt] Umstieg CCU2 -> debmatic / States von Sensoren werden nicht erkannt

[soccer]

Hi zusammen.

Ich bin vor Kurzem umgestiegen von der Original CCU2 auf debmatic als Debian VM unter ESXi.
Installation und Einspielen des Backups der CCU hat soweit alles geklappt (nach anfänglichen Firewall Schwierigkeiten).

Jetzt ist mir allerdings aufgefallen, dass einige Sensoren (2x HM-WDS-2 und 2x HM-SCI-3-FM) nur noch ihren Batterie-Status melden, aber nicht mehr ihren STATE.

Habe bereits versucht (zumindest bei einem der HM-WDS-2) das Gerät abzulernen und neu anzulernen.
Ablernen schlägt fehl, weil die WebUI der Meinung ist, sie kann die Konfigurationsdaten nicht an das Gerät übertragen.
Lösche ich es so raus und setze das Teil auf Werkseinstellungen zurück, kann ich es wieder ohne Probleme an die debmatic neu anlernen. Sobald ich aber versuche, in den Geräte-Einstellungen einen Wert zu ändern, kommt wieder die Servicemeldung "Kommunikation ist gestört".

Selbes auch beim HM-SCI-3-FM.

Version der debmatic: 3.47.15.31
Als Funkmodul ist RPI-RF-MOD im Einsatz das mittels HB-RF-USB-TK am ESXi Host hängt und in die VM durchgeschliffen ist.

Alles "aktiv" steuerbaren Aktoren etc. funktionieren aber ohne Probleme.

Hat jemand eine Idee? Die Logfiles hab ich soweit schon mal durchgeschaut aber nicht wirklich was gefunden.

Vielen Dank schon mal im Voraus

VG
Jörg

[deimos]

Hi,

zumindest bei den HM-SCI-3-FM musst du nach dem Ändern der Geräteeinstellungen auf dem Knopf am Gerät drücken, damit sich der die Daten von der CCU holt. Sonst ist das absolut normal, dass der eine Komm.-Störung meldet, weil der weder dauerhauft auf Nachrichten horcht, noch hat er ein Wake-on-Radio. Bei den HM-WDS-2 weiß ich das nicht 100%, aber ich vermute, dass es dort ähnlich ist, weil das bei denen rein wg. der Batterielaufzeit ebenfalls Sinn machen würde.

Woran machst du fest, dass sie ihren State nicht mehr liefern? Und woran machst du es fest, dass der Batterie-Status gemeldet wird? Zumindest bei den HM-SCI-3-FM wüsste ich nicht mal mehr, an welcher Stelle man die Aktualität des Batterie-Status sehen könnte.

Viele Grüße
Alex

[soccer]

Hi Alex.

Hi,

zumindest bei den HM-SCI-3-FM musst du nach dem Ändern der Geräteeinstellungen auf dem Knopf am Gerät drücken, damit sich der die Daten von der CCU holt. Sonst ist das absolut normal, dass der eine Komm.-Störung meldet, weil der weder dauerhauft auf Nachrichten horcht, noch hat er ein Wake-on-Radio. Bei den HM-WDS-2 weiß ich das nicht 100%, aber ich vermute, dass es dort ähnlich ist, weil das bei denen rein wg. der Batterielaufzeit ebenfalls Sinn machen würde.

OK, das mit dem Button macht Sinn, aber spätestens, wenn sich sein STATE ändert, meldet er sich doch bei der debmatic?!

Woran machst du fest, dass sie ihren State nicht mehr liefern? Und woran machst du es fest, dass der Batterie-Status gemeldet wird? Zumindest bei den HM-SCI-3-FM wüsste ich nicht mal mehr, an welcher Stelle man die Aktualität des Batterie-Status sehen könnte.

Um der Sache auf den Grund zu gehen, aber ich im ersten Schritt mal die Protokollierung für den HM-SCI-3-FM in der WebUI eingeschalten um zu sehen, ob sich das Teil überhaupt meldet.

Der dient bei mir zur Überwachung des Garagentors. Wenn der angeschlossene Magnetschalter auslöst (also Tor auf oder zu) dann seh ich sowohl im Systemprotokoll der WebUI die Meldung "Batterie OK" als auch im ioBroker eine Aktualisierung des des LOWBAT Datenpunktes. Allerdings halt nicht, dass der STATE von true auf false bzw. umgekehrt wechselt.

VG
Jörg

[deimos]

Hi,

zumindest bei den HM-SCI-3-FM musst du nach dem Ändern der Geräteeinstellungen auf dem Knopf am Gerät drücken, damit sich der die Daten von der CCU holt. Sonst ist das absolut normal, dass der eine Komm.-Störung meldet, weil der weder dauerhauft auf Nachrichten horcht, noch hat er ein Wake-on-Radio. Bei den HM-WDS-2 weiß ich das nicht 100%, aber ich vermute, dass es dort ähnlich ist, weil das bei denen rein wg. der Batterielaufzeit ebenfalls Sinn machen würde.

OK, das mit dem Button macht Sinn, aber spätestens, wenn sich sein STATE ändert, meldet er sich doch bei der debmatic?!

Ja, er meldet sich. Aber er erwartet dabei keine Antwort mit Config-Daten und holt die daher nicht ab. Das macht er nur, wenn der Config-Button gedrückt wird. Bei manch anderen Geräten ist das anders aber bei den HM-SCI-3-FM und seinen Geschwistern in den Puk Gehäusen läuft das nunmal so.
Und bei den Wettersensoren ist es noch extremer, die Senden die Daten einfach nur raus ohne überhaupt auf jegliche Antwort zu warten und legen sich dann sofort wieder schlafen.

Woran machst du fest, dass sie ihren State nicht mehr liefern? Und woran machst du es fest, dass der Batterie-Status gemeldet wird? Zumindest bei den HM-SCI-3-FM wüsste ich nicht mal mehr, an welcher Stelle man die Aktualität des Batterie-Status sehen könnte.

Um der Sache auf den Grund zu gehen, aber ich im ersten Schritt mal die Protokollierung für den HM-SCI-3-FM in der WebUI eingeschalten um zu sehen, ob sich das Teil überhaupt meldet.

Der dient bei mir zur Überwachung des Garagentors. Wenn der angeschlossene Magnetschalter auslöst (also Tor auf oder zu) dann seh ich sowohl im Systemprotokoll der WebUI die Meldung "Batterie OK" als auch im ioBroker eine Aktualisierung des des LOWBAT Datenpunktes. Allerdings halt nicht, dass der STATE von true auf false bzw. umgekehrt wechselt.

Das ist sehr mysteriös, der Batteriestatus kommt in dem Fall nicht in einer eigenen Nachricht, sondern in der Statusmeldung des Kanals mit. Und diese Nachricht kommt ja offensichtlich an und wird dann aber nur partiell ausgewertet. Da das im Closed Source vom rfd ist, kann ich da leider nicht wirklich reinschauen, woran das liegen könnte. Ich kann nur sagen, dass ich hier einen HM-SCI-3-FM problemlos laufen habe.

Hast du vielleicht mal einen eigenen Systemschlüssel gesetzt gehabt?

Viele Grüße
Alex

[soccer]

Ja, er meldet sich. Aber er erwartet dabei keine Antwort mit Config-Daten und holt die daher nicht ab. Das macht er nur, wenn der Config-Button gedrückt wird. Bei manch anderen Geräten ist das anders aber bei den HM-SCI-3-FM und seinen Geschwistern in den Puk Gehäusen läuft das nunmal so.

OK, na das ist ja kein Problem. Dann drück ich den Button heute abend mal und schau, ob er sich die Config-Daten holt und die Servicemeldung weg is.

Hast du vielleicht mal einen eigenen Systemschlüssel gesetzt gehabt?

Ähem ... gute Frage ... hatte die CCU2 schon sehr lange laufen, ohne was dran gemacht zu haben, da ich die Logik ja im ioBroker laufen hab. Aber das könnte durchaus sein bzw. ist sogar sehr wahrscheinlich.

Reicht es in der debmatic den selben Schlüssel einzugeben? Dann werd ich das heute abend gleich mal testen, wenn ich daheim bin.

Gruß
Jörg

[soccer]

Hi nochmal.

Ich hab's gefunden und war ein typischer Fehler im OSI Layer 8 also: ICH war der Fehler.

Nach dem Umstieg auf die debmatic, hab ich natürlich meine alte CCU2 vom Netz genommen.
Und genau da lag mein Fehler, den ich überhaupt nicht auf dem Schirm hatte. Ich hab sie zwar vom LAN genommen, aber gelaufen ist sie die ganze Zeit noch . Da die Geräte dort ja alle noch angelernt waren, haben die dann scheinbar auch teilweise mit der CCU2 noch kommuniziert.
Das erklärt, warum bei der debmatic nur "Teilmeldungen" ankamen. Der Rest ist dann scheinbar in der CCU2 gelandet.

Nachdem ich die CCU2 jetzt endgültig elemiert hab (kommt in Zukunft als LAN-Gateway zum Einsatz), klappt es auch mit den States der Sensoren.

Sorry nochmal an @deimos, dass ich dich damit unnötigerweise belästigt habe.
Und nochmal Danke für deine Arbeit und den Support.

VG
Jörg

[deimos]

Hi,

freut mich, dass es jetzt klappt.

Und danke für die Rückmeldung, leider ist sowas ja nicht mehr selbstverständlich.

Viele Grüße
Alex