Constant Reboots After Update

Hey Folks -

Full Disclosure: I’m not certain my issue is VeraAlerts related and plan on contacting MCV on Monday but thought I’d get a head start here.

I have a fairly large implementation with dozens of PLEG conditions as well as related alerts (and of course devices behind them).

I finally took the plunge and update from UI5 to UI7. I’m finding that if I do anything related to alerts or notifications, Lua/Vera wants to reboot - usually multiple times.

If I go in to VeraAlerts, I see “26 Device Notifications were updated” in the notifications area no matter how many times I go in there. I did try to uploade the “J_VeraAlerts” file as the pinned post suggested but it didn’t change anything.

The reboots also happen when selecting notification recipients in a PLEG Action (or even a device notification).

I’m afraid that MCV may not be much of a help so thought I’d throw a line out here.

Thanks!

Here’s an example log entry at the start of a reboot…

08 12/17/16 23:12:57.519 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: ModifyUserData <0x32225680>
08 12/17/16 23:12:57.520 JobHandler_LuaUPnP::HandleActionRequest argument id=lu_action <0x32225680>
08 12/17/16 23:12:57.520 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x32225680>
08 12/17/16 23:12:57.521 JobHandler_LuaUPnP::HandleActionRequest argument action=ModifyUserData <0x32225680>
08 12/17/16 23:12:57.521 JobHandler_LuaUPnP::HandleActionRequest argument DataFormat=json <0x32225680>
08 12/17/16 23:12:57.521 JobHandler_LuaUPnP::HandleActionRequest argument inUserData={“devices”:{},“scenes”:{“scenes_61”:{“name”:“Front Door Low Battery”,“notification_only”:152,“triggers”:[{“device”:152,“name”:“Front Door Low Battery”,“enabled”:1,“arguments”:[],“template”:“8”,“lua”:"–[[StartVeraAlerts]]luup.call_action(‘urn:richardgreen:serviceId:VeraAlert1’,‘DeviceNotification’, {Msg <0x32225680>
08 12/17/16 23:12:57.522 JobHandler_LuaUPnP::HandleActionRequest argument Reload=0

2016-12-17 23:12:57 - LuaUPnP Terminated with Exit Code: 138

If you are on 7.19 you MUST use the patched version J_VeraAlerts.js
NOTE: you must remove the .txt extension from the posted files.

Hello Richard -

Good to talk to you again. Happy to finally be up to UI7 (albeit a few issues) so I can get your updates again!

It appears I’m on the latest published version - VeraAlerts 7.15 (UI 1.7.902)

Is there anything I can provide (logs, screenshots, reports, etc) to help? I’m also opening a case with MCV but I assume they’re going to tell me to uninstall VeraAlerts.

EDIT:
I’m running debug and seeing the following during initialization. Not sure if it is relevant:
01 12/18/16 9:46:21.319 ^[[31;1mluup_require can’t find veraUserTemplateDefinitions^[[0m <0x2bb49680>

Verbose logging. In "Notifications"on a given device, clicking on my username to send notifications on a given event.

10 12/18/16 14:33:10.277 GlobalLog: mongoose put_socket: idle: 1 threads: 3 max: 100 s: d:26927 <0x30f94680>
10 12/18/16 14:33:10.278 GlobalLog: mongoose get_socket2: 0xef81a0 idle: 0 threads: 3 max: 100 head: 10 tail: 9 s: d:26927 <0x313ae680>
10 12/18/16 14:33:10.279 GlobalLog: mongoose get_socket3: 0xef81a0 idle: 0 threads: 3 max: 100 head: 10 tail: 10 s: d:26927 <0x313ae680>
10 12/18/16 14:33:10.279 GlobalLog: mongoose ctx: 0xef81a0 idle: 0 threads: 3 max: 100 pthread_self: 825943680 s: d:26927 <0x313ae680>
10 12/18/16 14:33:10.282 mg_callback from IP:127.0.0.1:36098 /port_3480/data_request (null) start id: 70 <0x313ae680>
12 12/18/16 14:33:10.283 luvd_get_info_data_request starting /data_request pMem 0x1db0000/31129600 diff: 23289856 <0x313ae680>
35 12/18/16 14:33:10.285 parse_post_data parameter id = lu_action <0x313ae680>
35 12/18/16 14:33:10.286 parse_post_data parameter serviceId = urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x313ae680>
35 12/18/16 14:33:10.287 parse_post_data parameter action = ModifyUserData <0x313ae680>
35 12/18/16 14:33:10.287 parse_post_data parameter DataFormat = json <0x313ae680>
35 12/18/16 14:33:10.288 parse_post_data parameter inUserData = {“devices”:{},“scenes”:{“scenes_61”:{“name”:“Front Door Low Battery”,“notification_only”:152,“triggers”:[{“device”:152,“name”:“Front Door Low Battery”,“enabled”:1,“arguments”:[],“template”:“8”,“lua”:“–[[StartVeraAlerts]]luup.call_action(‘urn:richardgreen:serviceId:VeraAlert1’,‘DeviceNotification’, {Msg <0x313ae680>
35 12/18/16 14:33:10.289 parse_post_data parameter Reload = 0 <0x313ae680>
10 12/18/16 14:33:10.290 JobHandler_LuaUPnP::HandleRequest id lu_action request pMem 0x1db0000/31129600 diff: 23289856 <0x313ae680>
10 12/18/16 14:33:10.291 sbrk JobHandler_LuaUPnP::HandleActionRequest from IP:0.0.0.0 pMem 0x1db0000/31129600 diff: 23289856 <0x313ae680>
08 12/18/16 14:33:10.292 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: ModifyUserData <0x313ae680>
08 12/18/16 14:33:10.292 JobHandler_LuaUPnP::HandleActionRequest argument id=lu_action <0x313ae680>
08 12/18/16 14:33:10.293 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x313ae680>
08 12/18/16 14:33:10.293 JobHandler_LuaUPnP::HandleActionRequest argument action=ModifyUserData <0x313ae680>
08 12/18/16 14:33:10.294 JobHandler_LuaUPnP::HandleActionRequest argument DataFormat=json <0x313ae680>
08 12/18/16 14:33:10.295 JobHandler_LuaUPnP::HandleActionRequest argument inUserData={“devices”:{},“scenes”:{“scenes_61”:{“name”:“Front Door Low Battery”,“notification_only”:152,“triggers”:[{“device”:152,“name”:“Front Door Low Battery”,“enabled”:1,“arguments”:[],“template”:“8”,“lua”:”–[[StartVeraAlerts]]luup.call_action(‘urn:richardgreen:serviceId:VeraAlert1’,‘DeviceNotification’, {Msg <0x313ae680>
08 12/18/16 14:33:10.295 JobHandler_LuaUPnP::HandleActionRequest argument Reload=0 <0x313ae680>
10 12/18/16 14:33:10.296 FileUtils::DelFile /etc/cmh/heal.in.progress <0x313ae680>
10 12/18/16 14:33:10.297 UserData::MergeUpdates STARTED with {“devices”:{},“scenes”:{“scenes_61”:{“name”:“Front Door Low Battery”,“notification_only”:152,“triggers”:[{“device”:152,“name”:“Front Door Low Battery”,“enabled”:1,“arguments”:[],“template”:“8”,“lua”:"–[[StartVeraAlerts]]luup.call_action(‘urn:richardgreen:serviceId:VeraAlert1’,‘DeviceNotification’, {Msg <0x313ae680>

2016-12-18 14:33:10 - LuaUPnP Terminated with Exit Code: 138

If you are on the latest Vera Firmware (7.19) see:

http://forum.micasaverde.com/index.php/topic,40474.0.html#new

I did try that as briefly mentioned in my original message. However, I accidentally dropped the .js . I tried again but it still restarts Lua SEVERAL times and then finally says “Failed to save configuration” in the browser after I try exiting the Veralerts Editor.

Another worrying item: It constantly says I have “26 Device Notifications updated.” However, they’re all missing. I just see two scenes at the bottom. Even more interesting is if I go to the advance tab of the VeraAlerts App/Device, I do see all of my alerts in the MsgOverride variable.

Sounds like you did not get the right file installed.
Down load the file from your Vera and verify it contains the string:

   encoded_lua

I see encoded_lua called out a few times in the file. This file is not readable by the browser if I use the “view” feature in the Luup Files area. (see attached) Is that expected or did a stray character/encoding get in there to keep it from rendering?

Also, it looks like I got the .txt version in there at some point. (attached) Can you remind me where in the file-system these files are stored?

Thanks for your time, Richard.

EDIT: As you’re aware, files are located in /etc/cmh-ludl

I removed the old .txt.lzo file but didn’t change anything (not unexpected). I also took the time to decompress the J_VeraAlerts.js.lzo file and have a look from the the file system’s perspective. The file includes the encoded_lua as expected. However, I did note ^m (control M’s) throughout the document. Likely coming from an encoding change from a windows environment. I’m unfamiliar if that causes problems for Vera or not. Some applications are OK and some need a dos2unix ran against them. Thoughts?

The files are stored at:

/etc/cmd-ludl/

You should only have a
J_VeraAlerts.js.lzo file

The .lzo indicates that is compressed … The Vera UI uncompresses the file before displaying it to the UI.

:slight_smile: Correct. Did you see the edit to my post?

[quote=“RichardTSchaefer, post:10, topic:194782”]The files are stored at:

/etc/cmd-ludl/

You should only have a
J_VeraAlerts.js.lzo file

The .lzo indicates that is compressed … The Vera UI uncompresses the file before displaying it to the UI.[/quote]

The trailing lines terminators are not a problem.
When you open the Vera Alerts Editor … Does it state “XXX Device Notifications where updated” at the top ?
When you exit the editor … it should restart LUA
Refresh your browser and open the Vera Alerts Editor again.
You should NOT see the “XXX Device Notifications where updated”
If you do there was a problem saving the data. You might need to check the Vera Log file.

Yep. It always says “26” (I think all of them) need updating. I did put VeraAlerts in debug and grabbed a could of log snips above.

That’s a Vera saving problem … you need to look at Vera’s errors not the Vera Alerts log file.

Sent from my SAMSUNG-SM-G935A using Tapatalk

R - Thanks. Vera has been granted access so let’s see what they say.

Dropping in to say that I’m still struggling with this issue. MCV responds about once per day on average so they haven’t been terribly helpful.

Uninstalling VeraAlerts (and losing HOURS of work) has helped somewhat. However, when I reinstall it, I back to the “26 notifications need updating” message. I close out of the editor, endure 4-6 reloads, get the “Failed to Save Configuration” alert, and then go back in to find nothing has changed.

Since I’ve already committed to destroying my alert work, is there a better way to remove this application and “start fresh”? I get the feeling that removing the app isn’t truly deleting it and its remnants from the system.

You can delete all of your notifications and start again.

I did the following:

  1. Remove VeraAlert
  2. Removed all notifications - or at least all of the ones I could find. (Is there a way to see all notifications globally without going in to each device?)
  3. This seemed to stabilize the platform. Vera’s own alerts seemed to work.
  4. Reinstalled VeraAlerts and added the J_VeraAlerts.js file

See attached. It shows “2 devices” need updating but then doesn’t actually list anything. Closing the editor or forcing a reload from the editor then causes several Lua reloads.

Why is this plugin destabilizing Vera? There must be a notification or something still hanging out there.

OK. I stumbled across something. Those two scenes in the above snapshot also had notifications. When I went to the scene, I saw this strange code in the “Also execute the following LuuP code…” section:

–[[StartVeraAlerts]]luup.call_action(‘urn:richardgreen:serviceId:VeraAlert1’,‘DeviceNotification’, {Msg=‘Running%20scene%3A%20Panic%20Off’, Name=‘Panic%20Off’, Description=‘Running%20scene%3A%20Panic%20Off’, DeviceID=0, HouseModeMask=undefined, Service=‘’, Variables=‘’, Recipients =‘tbully%20jkodrik’}, 216)–[[EndVeraAlerts]??? <<–actual question marks in the field not the emoticon.

I couldn’t get the code removed so I deleted both scenes. This stabilized things…HOWEVER…

Now I’m not seeing any notifications “Configure Notifications” area. I’ve tried to delete and reinstall VeraAlerts (and applied the new js file) but still nothing. Because this is a new failure-mode, I’ll read the forums a bit. But hoping for a little help with this one.

“Process Notifications” was unchecked. I think this is behind me now. Thanks for your help.

Now to figure out why 1/2 of my device icons are the default “Z-Wave” icon. This “upgrade” has been tough!