OK. Done. While it’s rebooting, there is one bit of your installation instructions I was a bit fuzzy on…you state to only install the unzipped files, not the FOLDER. But in the unzip, there is a folder called “Services” and I have been opening that folder and installing the 10 or so files in there. Should I not have done that?
Not needed, but also probably not harmful.
OK, it rebooted, but it’s behaving the same. zwave and zigbee lights constantly flashing on for a few seconds, then off for a few (together).
OK. Try pulling power. Let it sit for 60 seconds, then power up.
Will do…
Powered back up - behaving the same.
OK. Let them look at it.
As a rule, powering down a running Vera is my tool of last resort. Don’t run for the power plug every time you get the spinning wheel of busy-ness. There are lot of things that can keep the Vera from responding quickly, and since 7.30 I’ve noticed that the web server does hang occasionally and will usually recover itself within a few minutes. Whenever you power it down, you run the risk that it was writing user_data or doing something else that should not be interrupted. The only time I will power down my Veras is when I can’t ssh into them (Terminal for you). If you can, then /sbin/reboot is often the better choice for a restart. If you must power down and you can ssh in, then /sbin/poweroff is the way to go to do an orderly shutdown and make it assuredly safe to pull power. Despite its appliance-like nature, it is still a Linux system running a corruptible file system.
For now, I recommend leaving it alone. The other thing that’s quirky about these systems is that they have a funny way of righting themselves when left alone. It costs you nothing to leave it be until support gets to you, and you may get lucky beforehand.
1 Like
Understood & appreciated. Thank you for taking so much time out of our Sunday to try and help me out - really awesome of you. I’ll wait for Support - they’ve pulled me out of a few jams like this in my many years of fumbling around with Vera. Enjoy the rest of your weekend.
@LibraSun, not sure if it was you that started the rigpapa beer/cocktail fund, but if it was, point me to it. This is clearly deserving of a few on me.
Cheers.
1 Like
UPDATE: So, Vera Support was able to help me get my system back up and running. It’s still a mystery as to exactly what caused the problem, but there was apparently some code floating around in there causing the LUUP Engine reload continuously. I’m now back to fully operational…almost.
@rigpapa, I installed your latest build of the Sonos Plug-in. It works, of course, flawlessly. However, I still cannot get my simple series of Sonos commands to execute correctly through a Vera Scene - I’ve been futzing around with it for hours, adding delays, changing sequence, etc. - the results are consistently inconsistent. As a reminder, this is all I’m doing…
Of course, when I run the commands as actvities in Reactor, they execute perfectly, every time. I don’t know what Vera is doing differently, but I just cannot get it work. So, I will use Reactor, which is a really awesome tool, but far more power than I need in this situation, and adds a couple additional layers of “maintenance” which I had hoped to avoid (Reactor Sensors, virtual switches, scenes to toggle virtual switches).
I’ve gone through the documentation on Reactor, watched a few of your videos and cannot seem to find a way to simply have a Vera Scene directly/manually trip a Reactor Sensor. Well, correction, I found a way, but it doesn’t seem to work as I would expect. I created a Scene which “trips” the Reactor sensor, but the activities do not execute. Again, I realize I’m using a power-tool for a task that only requires a screwdriver, but the screwdriver isn’t working.
If virtual switch/reactor sensor/scene is the only method to get what I want, I can make that work. If I’ve missed something obvious, guidance would be appreciated.
With the new updates to reactor you cannot manually trigger a reactor sensor. The best way for you is to use a virtual switch and have the scene turn the VS on.
What I suspect - thank you.
What are your triggers for the old scene? Maybe you could input those triggers into reactor and defeat the requirement of a virtual switch.
Multiple manual triggers - Google Home/Alexa voice commands, buttons on Leviton Scene Controllers, buttons on Evolve LCD scene controllers.
Ah, yes then you’re better off keeping the old scene as a basic trigger for reactor action. I have a few of these it works very well.
OK. But before you do anything else, can you please log back in to your Vera, do an ls -l /etc/cmh-ludl/*_Sonos* again, and post the output. I want to check the file set you are now running.
If you just need to run the action, then put this in your scene Lua:
luup.call_action( "urn:toggledbits-com:serviceId:ReactorSensor", "RunScene",
{ SceneNum="activity-id" }, nnn )
Where I have nnn, you need to put the device number of the ReactorSensor. Where I have activity-id you need to put the activity ID. That’s the group ID with “.true” or “.false” appended. I suspect you probably have your actions in the root group “is TRUE” activity of your ReactorSensor, so the activity ID would be “root.true”.
Thanks @rigpapa. What I came up with, just to minimize virtual devices, was to use a virtual dimmer, and then setting different dim target levels by my various Vera scenes based on what zone groupings/music selections I want to set. That gives me 100 possibilities (although I’d obviously never do that) with a single virtual switch (and a separate Reactor sensor for each. Then I’m not worrying about any lua code, and using your plug-in the way it was intended. That seems to be working well.
As for current Sonos plug-in files, here you go…
root@MiOS_50002490:~# ls -l /etc/cmh-ludl/_Sonos
-rw-r–r-- 1 root root 2416 Apr 20 09:09 /etc/cmh-ludl/D_Sonos1.json.lzo
-rw-r–r-- 1 root root 685 Apr 20 09:09 /etc/cmh-ludl/D_Sonos1.xml.lzo
-rw-r–r-- 1 root root 10439 Apr 18 16:16 /etc/cmh-ludl/D_Sonos1_S16.json
-rw-r–r-- 1 root root 10439 Apr 18 16:16 /etc/cmh-ludl/D_Sonos1_S23.json
-rw-r–r-- 1 root root 10440 Apr 18 16:16 /etc/cmh-ludl/D_Sonos1_ZP80.json
-rw-r–r-- 1 root root 915 Apr 20 09:09 /etc/cmh-ludl/D_SonosSystem1.json.lzo
-rw-r–r-- 1 root root 558 Apr 20 09:09 /etc/cmh-ludl/D_SonosSystem1.xml.lzo
-rw-r–r-- 1 root root 793 Apr 20 09:09 /etc/cmh-ludl/I_Sonos1.xml.lzo
-rw-r–r-- 1 root root 3134 Apr 20 09:09 /etc/cmh-ludl/I_SonosSystem1.xml.lzo
-rw-r–r-- 1 root root 13029 Apr 20 09:09 /etc/cmh-ludl/J_Sonos1.js.lzo
-rw-r–r-- 1 root root 9730 Apr 20 09:09 /etc/cmh-ludl/J_SonosSystem1.js.lzo
-rw-r–r-- 1 root root 66555 Apr 20 09:09 /etc/cmh-ludl/L_SonosSystem1.lua.lzo
-rw-r–r-- 1 root root 10071 Apr 20 09:09 /etc/cmh-ludl/L_SonosTTS.lua.lzo
-rw-r–r-- 1 root root 17920 Apr 20 09:09 /etc/cmh-ludl/L_SonosUPnP.lua.lzo
-rw-r–r-- 1 root root 1707 Apr 20 09:09 /etc/cmh-ludl/S_Sonos1.xml.lzo
-rw-r–r-- 1 root root 5942 Apr 20 09:09 /etc/cmh-ludl/S_SonosAVTransport1.xml.lzo
-rw-r–r-- 1 root root 1805 Apr 18 16:08 /etc/cmh-ludl/S_SonosAlarmClock1.xml.lzo
-rw-r–r-- 1 root root 884 Apr 18 16:08 /etc/cmh-ludl/S_SonosAudioIn1.xml.lzo
-rw-r–r-- 1 root root 909 Apr 18 16:08 /etc/cmh-ludl/S_SonosConnectionManager1.xml.lzo
-rw-r–r-- 1 root root 1933 Apr 18 16:08 /etc/cmh-ludl/S_SonosContentDirectory1.xml.lzo
-rw-r–r-- 1 root root 1577 Apr 18 16:08 /etc/cmh-ludl/S_SonosDeviceProperties1.xml.lzo
-rw-r–r-- 1 root root 715 Apr 18 16:08 /etc/cmh-ludl/S_SonosGroupManagement1.xml.lzo
-rw-r–r-- 1 root root 900 Apr 20 09:09 /etc/cmh-ludl/S_SonosGroupRenderingControl1.xml.lzo
-rw-r–r-- 1 root root 735 Apr 18 16:08 /etc/cmh-ludl/S_SonosMusicServices1.xml.lzo
-rw-r–r-- 1 root root 3327 Apr 20 09:09 /etc/cmh-ludl/S_SonosRenderingControl1.xml.lzo
-rw-r–r-- 1 root root 1031 Apr 20 09:09 /etc/cmh-ludl/S_SonosSystem1.xml.lzo
-rw-r–r-- 1 root root 1055 Apr 18 16:08 /etc/cmh-ludl/S_SonosSystemProperties1.xml.lzo
-rw-r–r-- 1 root root 1309 Apr 18 16:08 /etc/cmh-ludl/S_SonosZoneGroupTopology1.xml.lzo
OK. Looks good.
@rigpapa, for what it’s worth, I thought I’d share a discovery about the behavior of the Sonos commands. Turns out that one command I’m using - BecomeCoordinatorOfStandaloneGroup - seems to be a culprit when it comes to timing. I had to insert a 2-second delay after that command to keep it from gumming up the rest of the commands when setting up a new zone group, even in Reactor. I can only guess it takes Sonos longer to process/respond to that one.
In any event, I’ve got all my music scenes setup and working again well with Reactor + Switchboard + Vera Scenes. And setting different levels on a single virtual dimmer to trigger the Reactor sensors means I didn’t end up with a virtual switch for every one of my scenes, so all good.
Thanks again for your help.
1 Like
EEK, I think i broke my sonos plugin.
Stupidly, I was reading the 1.5 thread and read the first note and thought that was a new update.
Now have 3 new devices and one saying pending version 2.0 upgrade.
The exsiting version 2.0 ‘sonos system’ device is stuck on starting with the red hazard line accross. and all devices associated to version 2.0 say can’t detect device.
If I redo all the steps in top of this thread will it clean everything up or make it worse?
I have backups of vera also but not exactly sure what gets backed up. Can that help restore to previous version?
Just repeat steps 4-10 of the install in the head post of this topic, and then do step 14 (the hard refresh of the browser). You may need an additional Luup restart/reload and hard-refresh after, but it all should be fine.
Edit/note: If you end up with an extra device, don’t worry. Just delete the extra device(s), which theoretically would be the highest-numbered (highest device number) if it’s otherwise not clear.