Regarding the Say callback, I found two problems (in addition to the repeat you already knew):
[quote=“lolodomo, post:341, topic:169644”]Regarding the Say callback, I found two problems (in addition to the repeat you already knew):
For this sentence: La température extérieure est de 18 degrés.
here is the URL you build
x-rincon-mp3radio://translate.google.com/translate_tts?tl=fr&q=La%20temp%c3%a9rature%20ext%c3%a9rieure%20est%20de%2018%20degr%c3%a9s%2eThe URL ://translate.google.com/translate_tts?tl=fr&q=La%20temp%c3%a9rature%20ext%c3%a9rieure%20est%20de%2018%20degr%c3%a9s%2e in a WEB browser delivers a normal sound file.
So it looks like this URL is then not correctly handled by the Sonos ???
Other little bug: I think SkipDown and SkipUp are reversed. SkipUp = Previous while it should be Next ?
This
x = a, bjust assigns the value of a to x, and throws away the value of b.
The change I made was more like
x = f(a, x)where I chained the prior value through the next execution, and internally used it as the “default value” when no change was made.
[quote=“lolodomo, post:339, topic:169644”]x = a, b
What’s the result of such a line code ?
Is it different from
x = a or b[quote=“guessed, post:344, topic:169644”]The change I made was more like
x = f(a, x)where I chained the prior value through the next execution, and internally used it as the “default value” when no change was made.[/quote]
Sorry, I read the code too quickly !
Added. Now defaults to 50 if it’s not specified, or if it’s been specified as “” (blank). The latter comes from the MiOS Scene runtime.
NOTE: This will only show up in the scene editor for newly created scenes. It looks like they keep a track of the parameters/values for existing ones, and ignore the new service definition.
[quote=“lolodomo, post:340, topic:169644”]In the Say action, I think you forgot to define the Volume parameter.
Then, in the code of the action, you are using lul_settings.Volume which is I think always nil.[/quote]
Yeah, I can’t change that without impacting anyone already using it. To be honest, I’ve seen this implemented both ways, so [to me] there’s no clear winner on wither “Up” is “previous” or “next”.
… even the apple guys reversed their mouse scrolling in 10.7 (“natural” scrolling 
[quote=“guessed, post:347, topic:169644”]Yeah, I can’t change that without impacting anyone already using it. To be honest, I’ve seen this implemented both ways, so [to me] there’s no clear winner on wither “Up” is “previous” or “next”.
… even the apple guys reversed their mouse scrolling in 10.7 (“natural” scrolling
In this case, I will use AvTransport rather than MediaNavigation for these two buttons.
Hi Guessed.
Here are what I plan to change to add a simple interface:
define 5 new variables in complement to CurrentStatus: CurrentTrackTitle, CurrentTrackArtist, CurrentTrackAlbum, CurrentStreamTitle and CurrentStreamInfo. It is data you already manipulate to set CurrentStatus.
I would need to refresh data immediately after each user action. I am not sure what is the best way to do it. Either I add a new callback PlayAndRefresh that would call Play and then Refressh, or I add a parameter to Play callback, a boolean to invoke or not refresh. There is even another solution that would be that we refresh systematically data in all actions. The last one might be the best solution.
CurrentTransportActions variable is interesting but it looks like the content of the variable is always unchanged. Could it be a bug of the plugin or is it something not correctly handled by Sonos ?
in flash UI, is there a way to disable a button based on a variable value ?
- define 5 new variables in complement to CurrentStatus: CurrentTrackTitle, CurrentTrackArtist, CurrentTrackAlbum, CurrentStreamTitle and CurrentStreamInfo. It is data you already manipulate to set CurrentStatus.Seems reasonable. When I added [tt]CurrentStatus[/tt], I wasn't sure if I should poke it into the existing [tt]:serviceId:[/tt] or into the [tt]Sonos1[/tt] variant. I ended up poking it into the standard one as UPnP seemed to permit vendor "extensions" (as Sonos has made liberal use of).
These will be handy for the Dialog display, where there is Real-estate to show them, but the Dashboard will likely need to use CurrentStatus… esp if you’re going to add buttons, due to the limited display space for UI4 & UI5.
- I would need to refresh data immediately after each user action. I am not sure what is the best way to do it. Either I add a new callback PlayAndRefresh that would call Play and then Refressh, or I add a parameter to Play callback, a boolean to invoke or not refresh. There is even another solution that would be that we refresh systematically data in all actions. The last one might be the best solution.If refresh is going to have a few different consumers, I'd change it a little in order to avoid an internal IF test. You'd end up with something like:
[code]local function refreshNow()
… most of current impl, minus the call_timer/call_delay
end
function refresh(period)
call_delay(refresh, period)
refreshNow()
end[/code]
Then we can just call [tt]refreshNow()[/tt] after all of the actions. Note that most of these will need to change to use [tt][/tt] instead of [tt][/tt] as they currently do. I should have done this a while back, but it’ll avoid hanging the control point(s) when they’re called.
- CurrentTransportActions variable is interesting but it looks like the content of the variable is always unchanged. Could it be a bug of the plugin or is it something not correctly handled by Sonos ?Some of these variables specify the domain-values for parameters to others. This is one of those. In reality, it will never change so I can move it out of the refresh code, and into startup code.
- in flash UI, is there a way to disable a button based on a variable value ?The UI functionality is very limited, this isn't possible.
[quote=“guessed, post:350, topic:169644”]If refresh is going to have a few different consumers, I’d change it a little in order to avoid an internal IF test. You’d end up with something like:
[code]local function refreshNow()
… most of current impl, minus the call_timer/call_delay
end
function refresh(period)
call_delay(refresh, period)
refreshNow()
end[/code]
Then we can just call [tt]refreshNow()[/tt] after all of the actions. Note that most of these will need to change to use [tt][/tt] instead of [tt][/tt] as they currently do. I should have done this a while back, but it’ll avoid hanging the control point(s) when they’re called.[/quote]
Finally, I think we don’t need a full refresh. We can do like for the mute callback, that is a very partial update.
When Play/Pause/Stop buttons are pushed, what I need is just updating the playback state variable to get an immediate update on UI.
So I will just update the callbacks Play, Pause and Stop (MediaNavigation).
PS: I discovered that you have made several little errors in the Mute callback. First, you have to use (1-isMuted) as calling parameter. Second, you have done mismatch with the variable names (Mute vs CurrentMute).
[quote=“lolodomo, post:351, topic:169644”]Finally, I think we don’t need a full refresh. We can do like for the mute callback, that is a very partial update.
When Play/Pause/Stop buttons are pushed, what I need is just updating the playback state variable to get an immediate update on UI.
So I will just update the callbacks Play, Pause and Stop (MediaNavigation).[/quote]
There might be several items that are impacted when you perform an action. If we know the names of all the impacted variables, we can use partial refresh. Given the lack of overall documentation for this stuff, it might just be safer to refresh all.
For example, “Next/Previous” might impact several different properties within the overall service.
PS: I discovered that you have made several little errors in the Mute callback. First, you have to use (1-isMuted) as calling parameter. Second, you have done mismatch with the variable names (Mute vs CurrentMute).It should have been [tt]Mute[/tt], but I was setting it incorrectly (against the service, instead of the serviceId... along with a bad computation for it). This has been corrected in trunk.
I was intending to use the standard UPnP AV stateVariable [tt]Mute[/tt]:
S_SonosRenderingControl1.xml in trunk – Sonos Wireless HiFi Music Systems
even though the out variable of the [tt]GetMute[/tt] action is called [tt]CurrentMute[/tt]:
S_SonosRenderingControl1.xml in trunk – Sonos Wireless HiFi Music Systems
The pre-existing, [tt]urn:schemas-micasaverde-com:device:avmisc:1[/tt] stuff is left as [tt]CurrentMute[/tt], for compatibility with any older scenes. Over time, I’d like to obsolete those, for their UPnP Standard equivalents.
I also made a few other changes to the way I calc default values, since I had stuff incorrect there also. Diffs via SVN.
[quote=“guessed, post:352, topic:169644”][quote=“lolodomo, post:351, topic:169644”]Finally, I think we don’t need a full refresh. We can do like for the mute callback, that is a very partial update.
When Play/Pause/Stop buttons are pushed, what I need is just updating the playback state variable to get an immediate update on UI.
So I will just update the callbacks Play, Pause and Stop (MediaNavigation).[/quote]
There might be several items that are impacted when you perform an action. If we know the names of all the impacted variables, we can use partial refresh. Given the lack of overall documentation for this stuff, it might just be safer to refresh all.
For example, “Next/Previous” might impact several different properties within the overall service.[/quote]
I agree with you for “Next/Previous”.
For “Play/Pause/Stop”, we need mainly an immediate update of the variable “TransportState”.
For “Mute/Unmute”, we need mainly an immediate update of the variable “Mute”.
That being said, we have three choices:
1 - forcing the value of the variable like it is done currently for “Mute”
2 - refreshing the variable by requesting updated UPnP data
3 - requesting a full refresh of data whatever the action.
What solution do you prefer ?
Do you know how the controller can decide whether to disable or enable buttons (prev, next, pause, … etc) ? Do you think we can retrieve this info from UPnP or do you think that it is hardcoded in Sonos software depending on the kind of music being played (Internet radio, music file, … etc) ? For example, you cannot pause a stream, you can only stop it. If you send a “Pause” command, the stream is stopped.
As I cannot disable buttons, I could at least run controls before really doing the actions.
By the way, you can already add the refreshNow function and a callback (Sonos1 service ?) because I will add a “refresh” button on the UI to let the user refresh the data.
Might as well use HaDevice1 Poll for this one, since there’s already a standard/convention.
http://wiki.micasaverde.com/index.php/Luup_UPNP_Files#Actions_2
[quote=“lolodomo, post:353, topic:169644”]I agree with you for “Next/Previous”.
For “Play/Pause/Stop”, we need mainly an immediate update of the variable “TransportState”.
For “Mute/Unmute”, we need mainly an immediate update of the variable “Mute”.
That being said, we have three choices:
1 - forcing the value of the variable like it is done currently for “Mute”
2 - refreshing the variable by requesting updated UPnP data
3 - requesting a full refresh of data whatever the action.
What solution do you prefer ?[/quote]
If there are special cases like Play/Pause where you’ve measured the changes that occur with the standard client (Using DeviceSpy etc) so you know exactly what changes then go ahead and just refresh the known subset.
Since that’ll be painful to complete manually for all of the actions, then I’d shoot for option 3 for all actions where we haven’t manually validated otherwise. Then, as we see fit, each can be tuned from that ‘all’ stance. Somewhere in this mix NOTIFY really needs to be fixed.
Do you know how the controller can decide whether to disable or enable buttons (prev, next, pause, ... etc) ? Do you think we can retrieve this info from UPnP or do you think that it is hardcoded in Sonos software depending on the kind of music being played (Internet radio, music file, ... etc) ? For example, you cannot pause a stream, you can only stop it. If you send a "Pause" command, the stream is stopped. As I cannot disable buttons, I could at least run controls before really doing the actions.no idea. I'd assume that if I watched the native client that I'd see one or more variable changes that'd indicate it. Worst case, you may be able to trigger off the DIDL-Lite data, but I'd assume its one of the other state vars changing.
I’d guess that you could just initiate the bad action, and let it silently error out behind the scenes. That’ll save the custom logic.
BTW: if you’re building a Dialog, then you can use JavaScript to build the display. Then you’d have more control, it’s just that this option isn’t available for building the dashboard UI.
[quote=“guessed, post:355, topic:169644”]Might as well use HaDevice1 Poll for this one, since there’s already a standard/convention.
http://wiki.micasaverde.com/index.php/Luup_UPNP_Files#Actions_2
Good idea.
[quote=“guessed, post:356, topic:169644”]If there are special cases like Play/Pause where you’ve measured the changes that occur with the standard client (Using DeviceSpy etc) so you know exactly what changes then go ahead and just refresh the known subset.
Since that’ll be painful to complete manually for all of the actions, then I’d shoot for option 3 for all actions where we haven’t manually validated otherwise.[/quote]
Ok, let’s go for option 3, except for volume management.
I hope data refresh is fast, I will check that this evening.
I try to commit something today, controls added in the Control tab but with a temporaru and unfinalized presentation.
We could add the SwitchPower service.
On would correspond to a Play command.
Off would correspond to a Stop command.
Hi guessed.
Please find attached my changes.
I finally already tried to deal with dashboard. It is ok on UI5, please tell me how it looks like on UI4, I was forced to move up a little the label. On UI4, you should not see others changes. On UI5, we have now basic controls. If it is not satisfying on UI4 like that, I can suppress “Prev” and “Next” buttons on UI5 and restore the previous position for the text.
In the control tab, there are few more controls. Unfortunately, the SetVolume is not working. The callback is called when you move the slider (you can see the temporary traces I added in the code of the SetVolume callback). First strange thing, lul_settings.Channel is equal to the volume value instead of “Master” ! I don’t understand why. I hope it is not a new firmware bug… But unfortunately, that’s not all, even if I force the channel parameter to “Master” in the call, the volume is not changed. It looks like Rendering.SetVolume is not working.
The way I manage refresh is not fully satisfying as there is a delay to retrieve data. A better solution could be to change the variable on which the UI is based and then start a refresh.
As soon as volume management is fixed, next steps for me would be:
1 - enhance media information
2 - add an input field + a button “Say” (an input field for the language will be required too - or checkboxes)
3 - add an input field + a button “Play”
Best Home Automation shopping experience. Shop at Ezlo!
© 2026 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules