Message from Sonos

lakewoodjazz · June 24, 2020, 4:27pm

I am seeing a notifacation from Sonos:
CHECK SYSTEM - LOW DISK SPACE
I cant imagine that is good.

slelieveld · June 24, 2020, 7:19pm

Everything is lowered…

Mayker · June 24, 2020, 7:46pm

Hi, I apologize for this question, but I am not sure to understand this.
What does that mean for us using the plugin?.

slelieveld · June 24, 2020, 7:58pm

Nothing atm but will do in the future. Sonos half’s the offices and fires 12 percent. That does do something with a product and the support (software).

lakewoodjazz · June 24, 2020, 8:47pm

Rigpapa can you help?

Pabla · June 24, 2020, 9:56pm

Your Vera is running out of space. Are you able to SSH into the unit?

lakewoodjazz · June 25, 2020, 2:17am

No problem accessing Vera normally.
Memory is cleared monthly by the below lua code scene implemented by Vera support.

os.execute(“rm /etc/cmh-firmware/mios*”)
os.execute(“rm -rf /overlay/etc/cmh/ergy_cache_paired_devices.conf”)
os.execute(“rm -r /overlay/dataMine”)
os.execute(“rm -rf /overlay/etc/cmh/ergy*”)
os.execute(“rm -r /overlay/etc/mios_backup.info.old”)
os.execute(“rm -r /overlay/etc/cmh/alerts.json”)
os.execute(“rm -rf /www/dm/”)
os.execute(" rm -r /etc/cmh-zwfw/*")
os.execute(“reboot”)

Runs on the 21st of each month at 4am.

I have no idea why the message is displaying.

Pabla · June 25, 2020, 4:30am

see: Installing Sonos Plugin 2.0 (development/pre-release) for Azure TTS access - #316 by rigpapa - Sonos - Ezlo Community

lakewoodjazz · June 25, 2020, 12:08pm

Will running this code from the Edit Start Up Lua page in Develope Apps fix my TTS cache issue?
"
os.execute( “rm -rf /www/sonos/ttscache /etc/cmh-ludl/ttscache” )
"
Running version Sonos App
2.0-hotfix20149; JSUI 2.0-20136

rigpapa · June 25, 2020, 2:30pm

If you are using a lot of dynamic TTS phrases, those being phrases that include date/time, weather, lists of devices created on the fly, etc., then your Say actions for those phrases should include UseCache=0. This will prevent the plugin from trying to cache them.

The plugin prunes the cache, but in the attempt to ensure that phrases can be spoken when Internet access is not available, the default pruning settings are very conservative (from the plugin’s perspective). You can set TTSCacheMaxAge lower than its default 90 (units are days). I recommend starting with 30. Going lower will only place a higher demand on the Azure service. That may or not be an issue; it’s individual, but keep in mind that any pruned phrase cannot be spoken when Internet access is not available, and will be delayed by the time needed to fetch the response from the cloud service. That is why you have the UseCache parameter on the Say action, so you can change the behavior on a per-phrase basis.

You can disable the cache entirely by setting UseTTSCache to 0. This forces every request to use the cloud service, though, with the appurtenant performance and reliability consequences.

lakewoodjazz · June 25, 2020, 9:50pm

Hello Patrick
thanks for your help. Hope all is well. I have reread your post #153 and have some questions.

Currently the setting on my Variables page of my Sonos System Controller is “blank” for both"UseTTSCache" or “TTSCacheMaxAge” So I assume I need to input a setting?
Am I on the most current version of your Plugin?
Running version Sonos App
2.0-hotfix20149; JSUI 2.0-20136
I don’t think I have many TTS calls.
Perhaps 6 scenes written that say Door Open…_(appropriate)__ Door Open., plus Dark Sky weather at 10am each day, a Driveway Alert Scene saying “we have a visitor.” and A Welcome home TTS after we disarm the security system.
Probably all together 8 TTS speak events per day… Does that meet your criteria of “A limited # of fixed phrases?”
I use 9 APPS… Is that alot?
Do you suggest I set TTSCacheMaxAge to 0?
Does the cache some how recognize my repeated “Door Open” TTS and only cashe it the one time for each room to be called upon later? or does it cashe everytime the "Door Open TTS scene runs?
Could you show me where to place the UseCache=0 code is added to this lua TTS scene.
luup.call_action(“urn:micasaverde-com:serviceId:Sonos1”, “Say”,
{Text=“Door Open. Apartment Front Door Open”, GroupZones=“646, 642, 660”,
Volume=60},
298)
Lastly …do I run
"
os.execute( “rm -rf /www/sonos/ttscache /etc/cmh-ludl/ttscache” )
"
from the Edit Start Up Lua page in Develope Apps?
Will it remove the CHECK LOW DISK SPACE notification once it runs?
Thanks for your time and patience!

rigpapa · June 25, 2020, 11:19pm

No. Default values will be used when the variables are empty.

No. The current hotfix release is 20167

Your weather is going to change every day, probably, so different speech audio is generated for every day, and if cached, there’s little chance the cached file will be reused. This action is where you need to add UseCache=0 on the action. Basically, if you are using variables to build up the text from parts, you need UseCache=0 on the Say action.

Maybe. Some are larger than others. It’s also a bigger load on an Edge than it is on a Plus. I don’t think you’ve said which you are running.

No. I suggest not touching it at all, and using UseCache=0 on your dynamic Say actions. Setting TTSCacheMaxAge to 0 will cause the plugin to not prune the cache at all ever. That’s probably furthest away from what you want.

The purpose of caching is that if you say “Front door open” often, you do not need Azure to generate it again every time–it will be the same every time. So when you speak a phrase for the first time, TTS saves the speech audio in its cache, and when you speak the same phrase later on, it uses the speech audio file it already has rather than reaching out the service to generate a new one. This not only speeds up TTS (a lot), but also makes TTS available when the Internet is not. In my house, I announce when Internet access is lost; this is only possible because of caching.

The catch, though, is that announcements like the current weather run a high likelihood of never being repeated exactly. The temperature is different, the forecast is different, the day of the week is different–whatever parts are assembled to make up your announcement, any of them can and likely do change from day to day. That means you are unlikely to make the same weather announcement twice, so the cached file is then just taking up space until it ages out (remember, 90-day default). So you use UseCache=0 to tell it not to cache those announcements.

luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say",
  {Text="Door Open. Apartment Front Door Open", GroupZones="646, 642, 660",
   Volume=60, UseCache=0}, 298)

But you don’t need it for this one, because the text string is fixed, it’s not dynamically-generated. If this is typical of your door announcements, the only example you’ve given that’s dynamic is the weather announcement (so you need to set UseCache=0 on that one).

No. Never. That will only slow down TTS and make it unreliable when Internet access is sketchy.

Do this:

Fix your weather announcement (UseCache=0), and any other TTS where you build the text using variables.

Run this in your Test Luup Code window:

-- Put the Sonos System master device number in where indicated.
luup.call_action("urn:toggledbits-com:serviceId:SonosSystem1", "ResetTTS", {}, sonos_master_dev_num)

Reload your Vera. See if the message goes away.

If the message goes away, your dynamic weather announcements were likely responsible for generating the warning (by filling the cache with unrepeatable speech). If the warning is still there, something else has consumed space, not the TTS cache.

lakewoodjazz · June 26, 2020, 4:21am

Thanks for your clarity to my questions above.

Code to clear TTS cache ran after I realized my parent device is called SonosSysytem not SonosSystem1… below is rthe code that was excepted.

>  luup.call_action("urn:toggledbits-com:serviceId:SonosSystem", 
>  "ResetTTS", {}, 
>                           639)

Reloaded system but after reload and refreshed browser the
CHECK LOW DISK SPACE notification returned.

Good News is I was succesful at updating the Weather TTS code to include the UseCache=0 as suggested.

You stated:
“If the warning is still there, something else has consumed space, not the TTS cache.”

If TTS is not responcible for the Alert shouldn’t the Vera Support Memory Clearing Scene that runs monthly on the 21st have cleared any memory issues?

I have not installed anything new nor am I experiencing any degridation of my Vera Edge performance …yet…

Next task?

rigpapa · June 26, 2020, 2:22pm

Actually, that’s not correct, so whatever you were attempting there didn’t do anything. Here’s the code again. Copy-paste, please:

luup.call_action( "urn:toggledbits-com:serviceId:SonosSystem1", "ResetTTS", {}, 639 )

Please try again.

lakewoodjazz · June 26, 2020, 4:16pm

Viola!
To review:
I added
UseCache=0
to the Dark Sky Scene because it is dynamically-generated. (changing variables)
All other scenes created that are fixed TTS (Door Open or Driveway Visitor or ANY TTS scene that does not look for 'updating variables" will respond quicker and not use up Veras memory by leaving
“UseTTSCache” and “TTSCacheMaxAge” settings blank.

One other question…
Once in a while my TTS scene for the Garage Door Open.
Repeats itself… Door Open Garage Door Open…Door Open Garage Door Open…
None of my other Door Open TTS scenes have done that.
I did delete the Garage Door Open scene and replace it but about once a week it doubles up!
Any thoughts?
Thanks again.
Cheers!

rigpapa · June 26, 2020, 4:28pm

Garage door sensors, particularly the “tilt” variety, are notorious for “bouncing”… as the door opens and shakes, the sensor sends several open/close/open/close pulse trains until the door gets far enough out of position that the tilt sensor is definitively tripped. You can debounce by adding a “sustained for” delay in Reactor. In a scene trigger, it’s a big can of worms… put your Say action in a Lua function in the scene Lua, use call_delay() to trigger a callback to that function after some number of seconds (2-5 is probably a good range), and then the Lua function should check the state of the sensor itself again (luup.variable_get()) before invoking the Say action (that’s the debounce part).

lakewoodjazz · June 27, 2020, 4:18am

Not a garage bay door tilt sensor problem.They work fine but I have no TTS scenes for it.
It’s my Garage Exterior Door with an Elk Door Sensor. I asked my wife if she was perhaps closing the door partially …enough for the magnet to make connection again with the sensor when she let’s the dog out… She answered …a very committed “Maybe…”

Thanks for your help.
Next to download the hotfix I’m missing.

tunnus · December 12, 2020, 7:45pm

Getting strange bounce myself with one of my Say actions for Sonos TTS (plugin is the latest 2.0 release). Using “Run Lua” activity with Reactor 3.8 (hotfix 20320). There shouldn’t be any tilt sensor problem here.

What happens is that “msg” is not played and “msg2” is repeated twice, but if I comment out luup.call_action with msg2, then “msg” is played normally. @rigpapa, any ideas what I could try out?

local d_plug = 126
local watts = luup.variable_get("urn:micasaverde-com:serviceId:EnergyMetering1", "Watts", d_plug)
watts = tonumber(watts)
local d_outtemp = 422
local temp_out=luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", d_outtemp)
temp_out = tonumber(string.format("%.0f", temp_out))
local msg = ""
if (temp_out ~= nil) then
  if (temp_out > 5) then
    msg = "message one here " .. temp_out
  elseif (temp_out > 0 and temp_out <= 5) then
    msg = "message two here " .. temp_out .. " additional message."
  else
    msg = "message three here " .. temp_out .. " another message."
  end
else
  msg = "temperature not available."
end
if (watts ~= nil) then
  if (watts > 500) then
    msg = msg .. " additional message"
  elseif (watts <= 500 and temp_out < 4) then
    msg = msg .. " something else here"
  end
end

luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text=msg, Volume=35, UseCache=0}, 473)

local d_RS = 274
local arm_failed = luup.variable_get("urn:toggledbits-com:serviceId:ReactorValues", "AutoArmFailed", d_RS)
local arm_home = luup.variable_get("urn:toggledbits-com:serviceId:ReactorValues", "ArmedHome", d_RS)
arm_failed = tonumber(arm_failed)
arm_home = tonumber(arm_home)
local msg2 = ""
if (arm_failed ~= nil and arm_home ~= nil) then
  if (arm_failed == 0 and arm_home == 0) then
    msg2 = "something here as well"
  elseif (arm_failed == 1 and arm_home == 0) then
    msg2 = "another variation"
  elseif (arm_home == 1) then
    msg2 = "also something here"
  end
  luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say", {Text=msg2, Volume=35, UseCache=0, Chime=0}, 473)
end

rigpapa · December 13, 2020, 1:24am

The plugin doesn’t sequence multiple Say calls, and the asynchronous nature of the process basically makes it a race condition. You need to send the message as one string, one action.

tunnus · December 13, 2020, 9:12pm

I’m trying to combine a “static” TTS message (from cache) and a more dynamic/changing message, as if there was an internet outage or Azure TTS service malfunction, Sonos would at least say something.

So should something like below work, or is it really a must to use totally separated “Run Lua” actions?