SONOS - SubProzess mit set Befehl neustarten anstatt disable (1/0)

webdandy · 23 August 2019, 08:31:58

Hallo Reinerlein,

leider kommt es bei meiner FHEM Installation auch ab und zu vor, dass der SubProzess unerwartet beendet wird.
Sehr selten, aber es kommt vor...

Code Auswählen

2019.08.23 02:34:58 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...

Wäre es möglich, dass Du ein "set Befehl" integrierst, der einen restart des Prozesses durchführt?
Dann könnte man mit einem notify oder DOIF monitoren, ob der Prozess läuft und dann mit einem "set..." notfalls wieder restarten.
Dies wäre wesentlich komfortabler als ein attr Sonos disable 1 und deleteattr Sonos disable.

Oder gibt es schon was ähnliches, was ich übersehen habe?

Grüße Fabian

webdandy · 28 August 2019, 13:15:22

Gibt es niemanden, bei dem der Prozess auch ständig beendet wird?

Code Auswählen

2019.08.28 12:53:54 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...

DeeSPe · 28 August 2019, 13:40:19

Ich wäre auch dafür einen entsprechenden Setter im SONOS Device zu integrieren.
Bei mir steigt der Prozess auch (un)regelmäßig aus.
Dazu habe ich ein stündliches at definiert, welches prüft ob SONOS disabled ist, falls ja wird dass attr disable gesetzt und nach 30 Sekunden wieder gelöscht. Nachteil ist aber eben die Änderung der cfg.

Gruß
Dan

webdandy · 28 August 2019, 13:43:25

Zitat von: DeeSPe am 28 August 2019, 13:40:19
Ich wäre auch dafür einen entsprechenden Setter im SONOS Device zu integrieren.
Bei mir steigt der Prozess auch (un)regelmäßig aus.
Dazu habe ich ein stündliches at definiert, welches prüft ob SONOS disabled ist, falls ja wird dass attr disable gesetzt und nach 30 Sekunden wieder gelöscht. Nachteil ist aber eben die Änderung der cfg.

Gruß
Dan

Hallo Dan,
könntest Du mir mal bitte schicken, wie Du es realisiert hast?
Bei mir hatte das irgendwie nicht geklappt.
Bekomme nur eine Telegram Nachricht, sobald der Subprozess stoppt und muss dann händisch setzen. Blöd...

Gruß Fabian

DeeSPe · 28 August 2019, 13:49:18

Das ist kein Hexenwerk Fabian!

Mein at sieht so aus:

Code (RAW DEF) Auswählen

defmod at_SONOS at +*01:00 {fhem "attr Sonos disable 1;; sleep 30;; deleteattr Sonos disable" if (Value("Sonos") eq "disabled")}

Gruß
Dan

P.S. Man könnte es auch mit einem entsprechenden notify umsetzen.

Code (RAW DEF) Auswählen

defmod n_SONOS notify Sonos:.disabled {fhem "attr Sonos disable 1;; sleep 30;; deleteattr Sonos disable"}

webdandy · 28 August 2019, 13:56:18

Ah, okay danke! Damit hatte ich auch schon mal experimentiert und festgestellt, dass man ein"save" mittlerweile nicht mehr mit einem notify ausführen kann.
Deshalb sagtest du auch die Änderung in der cfg.... Werde es aber auch erstmal so konfigurieren, bis es vielleicht in Zukunft ein set Befehlt für einen Neustart gibt.
Kann es durch das "sleep 30" Freezes geben?
Gruß Fabian

DeeSPe · 28 August 2019, 14:09:34

Zitat von: webdandy am 28 August 2019, 13:56:18
Kann es durch das "sleep 30" Freezes geben?

Nein, denn es ist ein FHEM sleep und kein Perl sleep.

Gruß
Dan

Otto123 · 28 August 2019, 16:55:23

Hi,

ich habe das so gemacht.

Code Auswählen

defmod di_SonosCheck DOIF ([05:00] and [?Sonos] ne "opened" )(attr Sonos disable 1)(attr Sonos disable 0)
attr di_SonosCheck room Bad,Status
attr di_SonosCheck wait 0,10

Damit früh das automatische Radio sichergestellt ist

Ich glaub ich hatte bei Sonos im Fehlerfall schon den Status der nicht "disabled" war - bin aber nicht ganz sicher.

BTW: Das mit den automatischen save ist nicht ganz ohne, da hat sich manch einer die Konfig "gelöscht". Es gibt Zustände, da werden bei Neustart in der aktiven Konfig (also der im Speicher) Geräte wieder entfernt weil sie nicht definierbar sind. Das würde dann bei einem save "ohne hinschauen" festgeschrieben.

Gruß Otto

webdandy · 28 August 2019, 18:40:45

Hi Otto,
verstehe, der Ansatz mit dem automatischen save, kann gefährlich sein

Ich habe nur mal kurz gesucht, aber gibt es die Möglichkeit eines "Diffs" zwischen der running und der cfg Datei?
Gruß Fabian

webdandy · 24 September 2019, 11:41:35

Hallo Reinerlein,

hast Du vielleicht schon geplant, den SONOS SubProzess mit einem "set Befehl" neustarten zu können?

Gruß Fabian

Mitch · 30 Oktober 2020, 12:46:30

Alt, aber immer noch aktuell.

Gibt es mittlerweile Überlegungen in diese Richtung?

Bei mir stirbt der Subprozess immer wieder, wird aber in fhem als open angezeigt, somit geht notify/DOIF und Co. nicht wirklich.

Kurt77 · 20 September 2021, 14:14:57

Hallo,
bei mir genauso: Subprocess wird auch nach dem Sterben als "opened" angezeigt.
Gibt es eine andere Möglichkeit, festzustellen, dass sich der Subprocess verabschiedet hat?

Danke und Gruß,
Kurt

Kurt77 · 24 September 2021, 19:29:40

Hallo,
dann will ich mir mal selbst antworten. Vielleicht hilft es ja jemandem.
Ich ermittle stündlich die Differenz zwischen der aktuellen Zeit und der Zeit, die im reading LastProcessAnswer abgelegt wird. Bei einer Differenz > 60 Sekunden starte ich den Prozess neu.

Gruß Kurt

Benni · 17 Dezember 2022, 09:30:51

Nachdem es leider bis heute keine set-Methode zum Restart des SONOS SubProcess gibt, habe ich mir im SONOS-Modul mal angeschaut, was da beim deaktivieren/re-aktivieren mittels disable Attribut gemacht wird und mir das in eine (bzw. zwei) eigene Funktion(en) in meiner 99_myUtils.pm extrahiert.

Letztendlich auch nur deswegen, weil mich stört, dass nach restart mittels disable-Attribut, die FHEM-Konfiguration als geändert markiert wird (rotes Fragezeichen).

Wenn man den untern stehenden Code in seine 99_myUtils.pm übernommen hat, kann man den SONOS-SupProcess beispielsweise ganz einfach durch Eingabe von

Code Auswählen


{mySONOS_RestartSubProcess}

in der FHEM-Kommanndoziele neu starten.
Besser ist natürlich der Aufruf aus einer, wie auch immer gearteten Übewachung!

Vorab noch ein Hinweis:

Es ist keine gute Praxis, einfach so irgendwelche modulinternen Mehtoden aufzurufen. Die können sich jederzeit im Namen oder der Signatur ändern. Es kann also jederzeit zu unerwünschten Nebenwirkungen kommen; bis hin zum Komplettabsturz des FHEM-Prozesses!

Die Verwendung der folgenden Funktion(en) erfolgt grundsätzlich auf eigenes Risiko !
Ich leiste auch keinen weiteren Support dazu!
(Stand heute funktioniert das bei mir und fertig!)

Code Auswählen


sub mySONOS_RestartSubProcess
{
	#This was grabbed from SONOS disable-Attribute handling and is relying on the internal
	#naming of methods in the SONOS module. -> Use at your own risk!

	#get hash of the SONOS main device
	my $hash = SONOS_getSonosPlayerByName();

	#Initiating Stop-Process if not already disabled...
	InternalTimer(gettimeofday() + 1, 'SONOS_StopSubProcess', $hash, 0) if($hash->{STATE} ne 'disabled');

	#Wait before trying to start the process again
	InternalTimer(gettimeofday() + 10, 'mySonos_StartSubProcess', 'noArg', 0);
}

sub mySonos_StartSubProcess
{
	#This was grabbed from SONOS disable-Attribute handling and is relying on the internal
	#naming of methods in the SONOS module. -> Use at your own risk!

	#get hash of the SONOS main device
	my $hash = SONOS_getSonosPlayerByName();

	InternalTimer(gettimeofday() + 1, 'SONOS_DelayStart', $hash, 0) if($hash->{STATE} eq 'disabled');
}

Noch kurz zur Implementierung:

Die Internal-Timer vor den SONOS-internen Funktionsaufrufen habe ich so übernommen. Ich bin mir nicht sicher, ob die hier überhaupt notwendig sind. Im Modul selbst dienen die wahrscheinlich lediglich zum Entkoppeln.
Die zweite sub für das Starten des SubProcess war notwendig, da diese mit 10 Sekunden Verzögerung aufgerufen wird um sicherzustellen, dass der SubProcess auch genug Zeit hatte, zu beenden.
Leider kann man hier nicht direkt die modulinterne Methode direkt mit entsprechender Verzögerung aufrufen, da SONOS anscheinend beim beenden des SubProcess alle "eigenen" internen Timer löscht. Somit wird der SubProcess nie neu Starten.

Mögliche Fallstricke:

Sollten die 10 Sekunden Wartezeit zu kurz sein, und der SubProcess länger brauchen, bis er beendet ist, einfach die Wartezeit so lange Schrittweise erhöhen, bis es korrekt funktioniert. Länger als 60 Sekunden sollten das aber eigentlich nie sein!
Sollte der Restart mal fehlschlagen, kann die sub mySONOS_StartSupProcess natürlich ebenfalls direkt aufgerufen werden

Viel Spaß damit!
gb#

cbl · 17 Dezember 2022, 16:09:06

Hallo Benni,

Vielen Dank. Ich probiere das mal aus. Den Setter vermisse ich auch schon länger, da mein Subprozess alle paar Tage (mal auch zwei Wochen) hängt.

Seitdem ich FHEM+KNX+Sonos verwende, um die Türklingel zusätzlich im Haus zu verbreiten, da ich im Homeoffice sonst den Postboten nicht immer höre, fällt der ausfallende Subprozess häufiger auf.

@Reinerlein, die saubere Integration ins Modul wäre stabiler und besser als dieser Workaround. Aber der hilft schon mal weiter.
Danke, Benni.

Gruß
Christian