Today on my Vera Plus (UI7, latest firmware), I wanted to get tricky and use my ecobee3 thermometer to control a switch. I figured this might be a great first shot at temp. control for the summer.
Sadly, the ecobee3 plugin has brought down the system. For the 1st 10 mins after loading the ecobee app, I tried to go to apps to remove it because everything was hanging. E.g. the apps page would not load. Now the /cmh/ page gives a 404 error which persists after power cycling several times.
It appears the ecobee3 app hosed the system upon loading. Does anybody ///please/// have any suggestions how I might be able to remove it from the command line? My usual google-fu didnât find any good examples of this, so I regrettably think my Vera is done for good unless we can somehow purge this app.
Thanks for the reply. And yep I am hoping I donât have to restore and was hoping there is a way to remove apps from the command line. I do enjoy the VeraPlus aside from its faults/quirks because it is based on Linux and is essentially independent of âthe cloudâ.
[NOTE: The presumption here is that the system starts up far enough to be reachable with SSH, but somehow Luup cannot start or is in a tight restart loop so the UI is unusable.]
Any plugin can be quickly disabled like this:
SSH into your Vera
Find the implementation file for the plugin, usually named I_Something1.xml.lzo (starts with I_ and has .xml.lzo suffix. If you find just I_Something1.xml (without .lzo) proceed directly to step 5.
Uncompress it: pluto-lzo d I_Something1.xml.lzo I_Something1.xml
Hide the LZO file: mv I_Something1.xml.lzo I_Something1.xml.lzo-saved (changing its name like this will make Luup not find it and use the uncompressed file).
Send the following command line exactly as shown except for changing the filename. Copy-paste strongly recommended, because it has to be spot on or it wonât work:
sed -i 's/<startup>\(.\+\)/<startup>X\1/' I_Something1.xml
Confirm step 3 worked: fgrep '<startup>' I_Something1.xml should display one line with an âXâ as the first character in the startup tag text.
Reload luup by typing Reload.sh at the Vera command line (or reboot if Luup canât run at all because of the plugin).
Your Vera should restart without the plugin running. You can then remove the plugin using the UI.
These steps modify the startup function of the plugin to a name that Vera canât find, causing its startup to abort with the rather quiet and anonymous message UPnPAction_Send::ParseState can't find name.
Restoring the pluginâs functionality, if you must, is simply a matter of removing the âXâ inserted in the startup tag, or copying/moving the âhiddenâ LZO back and removing the modified/uncompressed I_Something1.xml (e.g.
To add to @rigpapaâs answer which I hope has brought you back on track, I am not quite sure how you a plugin could bring back your system by attempting to watch one of its variable. Would you mind sharing the steps you followed to use the pluginâs thermometer to control a switch?
Good question, let me clarify. Simply loading the ecobee app hung the system so I never had a chance to try to read any variables from any associated devices. This hang also happened when I first got my ecobee3 a couple years ago, and back then I simply reloaded to fix. I forgot about this, and fortunately by disbling then re-installing the ecobee3 app fixed things up this time.
The most prominent hang was if I clicked on installed apps afterliadi g ecobee3, the web server would hang indefinitely and I had to power cycle. After reboot, /cmh/ gave a 404.
Back in ~2017 when I googled this the first time the concensus was that this was a problem and reload was necessary so I know it wasnât just me.
Happily, the VeraPlus is chugging along perfectly with lots of devices and tasks again.
Cheers
Best Home Automation shopping experience. Shop at Ezlo!
