I was successful in installing 2.0 to my Veraplus.
I noticed that my TuneIn Radio streams do not work anymore. I also tried playing other TuneIn Radio ID’s with no success.
This is what I have for the call for the TuneIn radio stream. I run it from a “SCENE” and it says it was successful but no radio stream is played.
luup.call_action(“urn:micasaverde-com:serviceId:Sonos1”, “PlayURI”,
{URIToPlay=“TR:142066”, Volume=10, GroupZones=“ALL”},39)
Try starting it from your phone app. It may have lost the service key, and it will pick it up again if the app starts it playing. After that, it should be OK.
@rigpapa - It plays a sirius radio station I had playing before but the Tune In radio Id station does not play. I rebooted the Vera and still the same results.
Is there a cache to clear by any chance?
Would it be possible to add a global TTS volume if its not there already. (if its there, where is it?)
Having a problem today with Plugin 2.0. I am getting a console error “SONOS: CHECK SYSTEM – LOW DISK SPACE”.
lOG file reports “luup_log:9: Sonos: WARNING! Free space on “/etc/cmh-ludl/” is critical (92%% full)”.
I do not see any large files in “/etc/cmh-ludl/”.
Where is the TTS cache stored and how do I clear it.
Plugin installed on VeraEdge.
Thanks, Tom
The TTS cache is normally stored in /www/sonos/ttscache. On firmware 7.30 and above, this is a different partition from /etc/cmh-ludl so clearing it will not make this message go away.
Basically, you have too many plugins. If you are comfortable with the tight space and know what you are doing, you can ignore the messages. Otherwise, you need to clear out some space from /etc/cmh-ludl. If you have uninstalled any plugins that you no longer use, the Vera does not remove the plugin files for those now-unused plugins, it just leaves them in that directory as orphans taking up space. So you can remove them yourself to recover space. Just be careful you don’t remove any files from live plugins (although in most cases, Vera will simply notice this and replace the missing file).
Not the case at all. I have 3 nonoptional plugins, vSwitch, uPnP and your Sonos 2.0.
I found the problem shortly after I posted the problem. It is the ttscache. After deleting all the folders in …/ttscache/AZURE/. and reboot to clear the “/overlay files”, fixed the problem.
Perhaps you may want to look at your “L_SonosSystem1.lua” starting on line 2783 “-- Check disk space” and check the “path” the error is reporting. Also, I see it reporting the problem, but doing nothing to fix it.
I’m not sure I see the need for ttscache on such a limited memory resource product like Vera. If an end user can’t wait 10 seconds for a message, consider an optional ttscache “check box option” for them to select. Also consider an option for ttscache files stored on an external network drive or usb.
Lastly, delete the ttscache at 60%. Don’t wait until 99% full, and just report the problem.
Otherwise, nice work. I have many more problems & fixes to report, but will keep this post on topic.
Thanks, Tom
That’s correct, and it won’t. Fixing things in /etc/cmh-ludl is not the plugin’s business. Partitioning on the newer firmware for Plus/Secure, the /etc/cmh-ludl/ directory and /www are on separate filesystems. Maybe that’s not true for Edge. I can’t tell/test at the moment, because my Edge is running the new eZLO Linux firmware. But in any case, there are parameters for cache management and pruning described elsewhere in this thread, as well as options for disabling the cache on individual actions or globally. It’s unusual for the cache to grow to any dangerous size, unless you speak a lot of dynamic phrases, in which case, well, I cover what you should be doing to manage the cache in this prior posts. The purpose of the cache is not just speed, but to make speech available when the Internet is not.
So I recently moved moved over to Azure TTS and everything going well. However when I set the TTS to repeat I only get voice once; no repeat. Trying to grab the logs as we speak but ever since support has had control of my VP its been difficult finding anything through the logs.
Make sure you’re on the latest code. If not, please update and try again.
Just updated and it didn’t help
Edit I think I got the logs
|10|05/14/20 16:24:14.180|JobHandler::Run ready to run job#114 : dev:726 (0x2ef4b30) P:50 S:0 Id: 114 status 0 <0x2ef4b30> priority 50 tNextRunAttempt 0 handler 0xa24e68 <0x77fbf320>|
|---|---|---|
|50|05/14/20 16:24:14.181|luup_log:723: Sonos: Say action on device 726 text "ALERT Babay/Papa Windows, Shed Doors Zones Have been opened" <0x77fbf320>|
|50|05/14/20 16:24:14.183|luup_log:723: Sonos: (tts debug) generate() engine Azure Speech Service text ALERT Babay/Papa Windows, Shed Doors Zones Have been opened file /www/sonos/Say.726.mp3 <0x77fbf320>|
|50|05/14/20 16:24:14.184|luup_log:723: Sonos: (tts debug) AzureTTSEngine:say() host "westus2.tts.speech.microsoft.com" payload "<speak version=\"1.0\" xml:lang=\"en-US\"><voice name=\"en-US-JessaNeural\">ALERT Babay/Papa Windows, Shed Doors Zones Have been opened</voice></speak>" <0x77fbf320>|
|50|05/14/20 16:24:14.185|luup_log:723: Sonos: (tts debug) AzureTTSEngine:say() LuaSec "0.8", using protocol "any" for request <0x77fbf320>|
|10|05/14/20 16:24:14.295|GlobalLog: mongoose put_socket: idle: 3 threads: 3 max: 100 s: d:25799 <0x71c3f520>|
|10|05/14/20 16:24:14.296|GlobalLog: mongoose get_socket2: 0x1021180 idle: 2 threads: 3 max: 100 head: 13 tail: 12 s: d:25799 <0x70583520>|
|10|05/14/20 16:24:14.296|GlobalLog: mongoose get_socket3: 0x1021180 idle: 2 threads: 3 max: 100 head: 13 tail: 13 s: d:25799 <0x70583520>|
|10|05/14/20 16:24:14.297|GlobalLog: mongoose ctx: 0x1021180 idle: 2 threads: 3 max: 100 pthread_self: 1884828960 s: d:25799 <0x70583520>|
|10|05/14/20 16:24:14.297|mg_callback from IP:192.168.1.34:53428 /data_request id=lu_sdata&full=0&output_format=json&dataversion=498162730&loadtime=1589498161 start id: 653 <0x70583520>|
|12|05/14/20 16:24:14.297|luvd_get_info_data_request starting /data_request?id=lu_sdata&full=0&output_format=json&dataversion=498162730&loadtime=1589498161 pMem 0x3b44000/62144512 diff: 51499008 <0x70583520>|
|10|05/14/20 16:24:14.298|JobHandler_LuaUPnP::HandleRequest id lu_sdata request pMem 0x3b44000/62144512 diff: 51499008 <0x70583520>|
|10|05/14/20 16:24:14.301|JobHandler_LuaUPnP::REQ_SData done load time changed load:1589498161 dv:498162750 <0x70583520>|
|10|05/14/20 16:24:14.303|luvd_get_info_data_request creating file buffer /data_request?id=lu_sdata&full=0&output_format=json&dataversion=498162730&loadtime=1589498161 pMem 0x3b44000/62144512 diff: 51499008 <0x70583520>|
|10|05/14/20 16:24:14.305|luvd_get_info_data_request done /data_request?id=lu_sdata&full=0&output_format=json&dataversion=498162730&loadtime=1589498161 ret 0 size 1685 pMem 0x3b44000/62144512 diff: 51499008 took 0 info (nil) <0x70583520>|
|10|05/14/20 16:24:14.305|mg_callback /data_request stop id: 653 <0x70583520>|
10 05/14/20 16:24:15.552 UserData::m_iDataVersion_Variables_incr zoneInfo user data 498161087 variables 498162754 <0x77fbf320>
10 05/14/20 16:24:15.553 UserData::DataIsDirty UpdateStateList was 1 incr 0 user data 498161087 variables 498162754 <0x77fbf320>
01 05/14/20 16:24:15.685 luup_log:723: Sonos: UPnP_request (Pause, urn:schemas-upnp-org:service:AVTransport:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>701</errorCode></UPnPError></detail></s:Fault></s:Body></s:Envelope>] <0x77fbf320>
02 05/14/20 16:24:15.686 luup_log:723: stack traceback:
[string "--[[..."]:265: in function 'error'
[string "--[[..."]:289: in function <[string "--[[..."]:169>
(tail call): ?
[string "--[[..."]:3378: in function 'sayOrAlert'
[string "--[[..."]:3440: in function 'queueAlert'
[string "--[[..."]:3758: in function <[string "--[[..."]:3726>
(tail call): ? <0x77fbf320>
01 05/14/20 16:24:15.695 luup_log:723: Sonos: UPnP_request (Pause, urn:schemas-upnp-org:service:AVTransport:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>701</errorCode></UPnPError></detail></s:Fault></s:Body></s:Envelope>] <0x77fbf320>
02 05/14/20 16:24:15.696 luup_log:723: stack traceback:
[string "--[[..."]:265: in function 'error'
[string "--[[..."]:289: in function <[string "--[[..."]:169>
(tail call): ?
[string "--[[..."]:3378: in function 'sayOrAlert'
[string "--[[..."]:3440: in function 'queueAlert'
[string "--[[..."]:3758: in function <[string "--[[..."]:3726>
(tail call): ? <0x77fbf320>
01 05/14/20 16:24:15.705 luup_log:723: Sonos: UPnP_request (Pause, urn:schemas-upnp-org:service:AVTransport:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>701</errorCode></UPnPError></detail></s:Fault></s:Body></s:Envelope>] <0x77fbf320>
02 05/14/20 16:24:15.706 luup_log:723: stack traceback:
[string "--[[..."]:265: in function 'error'
[string "--[[..."]:289: in function <[string "--[[..."]:169>
(tail call): ?
[string "--[[..."]:3378: in function 'sayOrAlert'
[string "--[[..."]:3440: in function 'queueAlert'
[string "--[[..."]:3758: in function <[string "--[[..."]:3726>
(tail call): ? <0x77fbf320>
01 05/14/20 16:24:15.721 luup_log:723: Sonos: UPnP_request (Pause, urn:schemas-upnp-org:service:AVTransport:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>701</errorCode></UPnPError></detail></s:Fault></s:Body></s:Envelope>] <0x77fbf320>
02 05/14/20 16:24:15.722 luup_log:723: stack traceback:
[string "--[[..."]:265: in function 'error'
[string "--[[..."]:289: in function <[string "--[[..."]:169>
(tail call): ?
[string "--[[..."]:3378: in function 'sayOrAlert'
[string "--[[..."]:3440: in function 'queueAlert'
[string "--[[..."]:3758: in function <[string "--[[..."]:3726>
(tail call): ? <0x77fbf320>
10 05/14/20 16:24:15.721 luup_set_failure 157 now 0 <0x75abd520> ```Logs unrelated, but I found it anyway. Update again, give it a shot.
Did the trick thanks!
Is there anything in this plugin 2.0 (current version) that writes to Sonos speakers that cannot be undone by speaker power shutdown?
Will the plugin ver 1.4 remain available from Vera Apps download in addition to the new 2.0? This new plugin totally hoses two years of my code writing time for 4 Vera Plus units currently controlling 16 Sonos speakers.
Tom
No.
Can you elaborate?
Please answer my second question.
Tom
I think everyone knows the answer to that question: the App Marketplace only offers the most recent published and approved version of the plugin. Prior releases are archived, and it is possible to install those prior releases, but when auto-update is on (or as recently suspected, there’s a bug in the handling of the auto-update flag), your Vera will make an effort to put you on the head release.
I don’t know how long you’ve been using 2.0; but it’s generally available for about three months. Your first post about it was just 3 days ago, and it wasn’t a bug report as much as a complaint about something not working the way you wanted it to, which I completely understand. If you’ve got other problems, I’m interested in hearing them, and possibly fixing them. I put a lot of time in here on a lot of plugins, and this one isn’t even mine, I just picked it up when it lost its maintainer. I do this because I want people in this community to be successful with Vera. It’s coming up on 5 years since the last version was released into the App Marketplace, and the problems with the old plugin were many, and many still continue today, but I’m hitting the worst and most troublesome first. The community has much more varied equipment and setups than I do, and I’ve already said elsewhere in this topic that because of the prohibitive cost of these devices, and the fact that I get no significant financial support from the community for this plugin, I cannot and will not buy every Sonos device to test with–in fact, the total retail price of all current Sonos products exceeds by several multiples the sum total of all donations I’ve ever received for all of my work here. The community is part of the process and always will be. If you have something substantive to add, please do. If I can get you happy on 2.0, or maybe a later version given the lateness of the hour in this case, I’ll do it. But don’t storm into the room at the 11th hour with vague missives about hosing your configuration or that you have “many more problems to report” and then don’t report them. That helps no one, and it certainly doesn’t predispose me to want to spend another minute trying to help.
If you really want to stay on 1.4, let me know and I’ll give you the necessary steps to decouple your installed plugin from the app marketplace so it never attempts to upgrade the plugin on your systems, and you’ll be good to go. Just know that I will not be supporting any version other than 2.0 or its progeny in future.
Edit: If you want to stay on 1.4, you have today and only today to let me know, because I’m posting the app for release tonight, and the changes to your system will need to be done before Vera approves the update.
For the time being, I will stay with 1.4. I do not keep auto Update checked. I’m not everybody, so I did not know the 2.0 Plugin would replace ver 1.4 with such a major upgrade. The ONLY reason I have stayed with Vera, at all, is for Sonos. I first tried updating the Sonos Plugin when you first released it because of the loss of RV (for me, RV went away March last year). I only wanted it to announce current music track, song, and number of tracks when starting a new play function. You know, “sombie” messages as you refer to them. This is what filled up the cache on my Vera Edge (the stand alone device I used to test the Plugin). I later tested it on one of my VeraPlus units 2 days ago, and that’s when I had the real problems. I have removed the 2.0 plugin using these steps {please let me know if I did something wrong:
1.) Removed uPnP and ran the removal code.
2.) Deleted the Sonos System device.
3.) Deleted all the Sonos files in /etc/cmh-ludl/ (about 28 of them)
4.) Deleted folder /www/sonos
5.) Reboot and Reinstalled 1.4 from “Install apps”
I downloaded the 1.4 files from My Vera to a folder as a backup (not lzo files).
Please let me know if I missed anything.
My problems that I had with 2.0 were as follows (only mentioning them as I encountered them). No need to try and resolve on my account.
1.) The first problem you know about. Fixed and understand how to prevent it. (Vera Edge)
2.) Group management. Can not control groups. Create one group, and 2.0 never forgets it to allow a newly defined group. Seems to get confused, like groups are cached somewhere.
3.) Erratic volume behavior when attempting to define groups for Music play, alerts play or TTS play. Just as a note, I used different volume for each speaker. Not sure if that is the reason I was having the problem.
4.) When playing TTS, volume recovery is slow, and music playing before TTS (say), will blast after the say command is complete, until settled seconds later. Voices for TTS are very soft in volume.
5.) Chime (I spent a day trying to get this one working). The chime is volume 10, and TTS is volume 5. Try to set volume for Chime in the app and it overrides the TTS volume. Finally turned if off.
6.) Last is erratic overall performance of my Sonos speakers with 2.0. It acts like it is sending the speakers action changes that can not be changed with my code. I’m sure I’m not saying that in a way that makes any sense.
Anyway, in conclusion, my panic is driven by the need for a functional Sonos system. It provides music listening enjoyment, and alerts me of numerous activities (about 237 to be exact). I am going blind, and will not have the ability to fix it later. This is the main reason why I have not read the previous 320 post on the 2.0 update.
I commend you on your herculean effort to upgrade the Sonos Plugin. I know it will be enjoyed by many. For me, it’s not just a cool thing to have, but a necessity. It’s too bad management at Vera has not taken a leadership role on this.
One question. One of the problems with Sonos on Vera is constant reboot. Does 2.0 help with that?
Again, Thank you for the time and effort.
Tom
OK. Thanks for these. I will look into them.
To complete the decoupling of your Sonos 1.4 plugin from the App Marketplace so you can stay on 1.4, you need to run the following in the Test Luup Code window:
changed = false
for k,v in pairs(luup.devices) do
local p = luup.attr_get("plugin", k) or 0
if tonumber(p) == 4226 then
luup.attr_set("plugin", "", k)
changed = true
end
end
if changed then
luup.reload()
end
This removes the association between the plugin and the device. After running this, you should be able to uninstall the plugin, which will not remove the plugin files or devices (now that you’ve decoupled them), but simply remove the registration of the plugin from the Vera (the key step to preventing upgrades).
When it’s all done, your devices should be left sitting there as they were, and the (1.4) plugin files will still be in /etc/cmh-ludl, and the system will run those devices from that code.
Is it possible to lower the chime volume! I’m finding it to be much louder than the voice.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules