Proces omówiony w poniższym materiale:
Pamiętajcie, że “podproces powiadomień.json” musi być dodany jako podproces aby to działało zgodnie z powyższym filmem.
podproces powiadomień - wywołanie.json (15,9 KB)podproces powiadomień.json (5,4 KB)
1 polubienie
Dzięki za ten proces Artur. Zależało mi na nim i sporo mi podpowiedział.
Widzę w nim jednak dwa ograniczenia:
- Regulacja poziomu głośności TTS nie przywraca wartości z przed odtworzenia powiadomienia. Głośnik zostaje na takim poziomie, jaki ustawił proces.
- Jeżeli na głośniku jest coś odtwarzane, to aktywność zostanie przerwana na odczytanie powiadomienia ale po jego zakończeniu głośnik nie wróci do poprzedniej aktywności.
Też się z tym borykam i nie nie wpadłem jeszcze na to, jak obejść te dwa limity. Jakby ktoś miał na to pomysł, to byłoby super. Może coś, co przed odtworzeniem powiadomienia przechwyciłoby stan odtwarzacza, zapisało jako jakąś zmienną i odczytało po odtworzeniu powiadomienia?
Te limity to u mnie świadoma decyzja. Wynika to z tego jak korzystam z głośników i u mnie to nie ma znaczenia.
Jak chcesz to w piątek dorobię jak możesz poradzić sobie z tymi limitami. W brew pozorom to nie jest takie trudne. Szczególnie głośność.
Jeżeli mógłbyś, to bardzo chętnie.
@jolly.roger jeśli chodzi o powrót do właściwej głośności to poniżej masz mój przykład (zrobiony przez @artur-a):
Dziękuję. Faktycznie, nie takie trudne. 
Prawie to, o co chodziło ale widzę, że ostatni nod ustawia głośność na sztywno na 50% a nie na przechwyconą wcześniej wartość.
W piątek zrobię wersję z przechwyconą. Wcześniej nie dam rady. Ale jak chcesz sam popróbować do tego czasu to mała podpowiedź. Przed ustawieniem powiadomienia pobierz aktualną głośność. Zapisz ja do nowej właściwości w obiekcie msg np msg.glosnosc_starowa i po wysłaniu powiadomienia ustaw głośność używając zapisanej wartości.
Podjąłem wyzwanie i prawie mi się udało. Pobiera głośność, zmienia a potem przywraca. Rozłożyła mnie tylko jedna rzecz. Nie mogę zmusić go, żeby zaczekał z przywróceniem głośności do końca odczytania powiadomienia. Zmiany dokonują się natychmiast, zanim wiadomość zostanie w ogóle odczytana. W rezultacie czytana jest na już przywróconym poziomie głośności. Nod “Delay” po wysłaniu wiadomości i przed zmniejszeniem głośności robi robotę ale nie chcę go używać, ponieważ jest mało elastyczny w użyciu. Z kolei nod “Wait until” nie działa, jak bym się tego spodziewał. Nie wiem dlaczego, ale nie przechwytuje stanu “playing” Chromecasta lub robi to nie dość szybko.
Proces zamieszczam poniżej. Wszelkie sugestie bardzo mile widziane.glosnosc_z_przechwyceniem.json (689 bajtów)
Nie mam teraz jak sprawdzić Twojego procesu więc zapytam. Podłączyłeś przywrócenie głośności na wyjście noda, który ją odczytuje jak rozumiem?
Nie. Przywrócenie podłączone jest pod do noda odtwarzającego powiadomienie. Logika jest następująca: przechwyć stan, ustaw głośność, wyślij wiadomość na Chromecast, zaczekaj aż się odtworzy, przywróć głośność. Wszystko idzie liniowo.
ok ogarnę w piątek u siebie i wrócę do Ciebie
Jeszcze tak na szybko jeżeli idzie tylko o przywrócenie głośności to możesz sprawdzić dodatkowo przed przywróceniem w jakim statusie jest player. Jeżeli w playing to czekasz na idle/stop/itp i wtedy przywracasz głośność:) ale to taki hack trochę niż porządne rozwiązanie
@jolly.roger
Cześć powalczyłem z tematem przez ostatnią godzinę i faktycznie jest jeden problem. Brak statusu playing od razu na wyjściu z callservice i nie do końca wygodne działanie wait until.
Dlatego rozwiązanie jakie ja widzę jest mało eleganckie ale powinno zadziałać (u mnie zadziałało). Załączam do wglądu.
Oczywiście możesz też użyć delay/stop timer i wtedy też będzie działać ale pisałeś, że delay nie chcesz dlatego te moje kombinacje.
Jak by coś było niejasne dlaczego tak to pisz.
przywrócenie głośności.json (4,9 KB)
Dziękuję. Cała logika jest dla mnie jasna. Czy aby przechwycić i przywrócić aktualnie odtwarzane medium/stream można posłużyć się tą samą logiką, przechwytując dodatkowo parametr data.attributes.media_content_id?
@jolly.roger Dokładnie tak.
@jolly.roger jak skończysz swój proces to pochwal się nim na forum
Walka trwa i znowu zagwozdka. Kiedy proces startuje z pozycji odtwarzacza “idle”, to ładnie czyta wiadomość ale siłą rzeczy nie przywraca odtwarzania, bo nic na starcie nie było odtwarzane. Jeżeli startuje z pozycji “playing”, to przywraca odtwarzanie ale nie czyta wiadomości. Nie rozumiem, co tam się dzieje. Wygląda to podobnie, jak wcześniej problem z “Wait until”.
@rafkan - Jasne, jak coś uda się z tego wyrzeźbić, to oczywiście wrzucę.
@jolly.roger Popatrzę na to jutro i spróbuje ogarnąć bo dzisiaj już nie mam siły
1 polubienie
A wyskakuje jakiś api error czy coś takiego, ja np miałem taki problem ze po odczytaniu komunikatu media Player zaczynał odtwarzać muzykę choć wcześniej nie grała i zrobiłem to sobie tak że po komunikacie ma powrócić poprzedni stan ale przy pierwszych próbach miałem api error w momencie kiedy po odtworzeniu komunikatu chciałem powrócić do poprzedniego stanu media.player ale gdzieś znalazlem aby dodać nod change przed nodem z przywróceniem stanu i pomogło i teraz dziala super, z tego co zozumialem nod change “oczyszcza czy jakoś tak” wiadomość
@on6222 To jakieś takie magiczne trochę Pamiętaj że obiekt msg to żadna magia zawsze możesz go sprawdzić i tak zrobić aby był taki jak potrzebujesz. Nie musisz nic oczyszczać.