LUUP restarts

Good day ,

I think , since the last firmware update I get everyday now a LUUP restart , everyday at the same time at least. There is no scene or PLEG that runs specifically at that time.

I was able to capture the LUapnp logfile :
This is what triggers the LUUP restart, But I have no idea what the cause is:

03	03/06/17 11:48:05.929	JobHandler_LuaUPnP::Reload: dr_reload Critical 1 m_bCriticalOnly 0 dirty data 1 <0x6ec50520>

Attached a screenshot and 3 txt files with more data, anyone can see a cause there?

LUUP restart 3.txt is couple of minutes before untill it happened
LUUP restart 1.jpg is a screenshot when it happened

Thanks,
Cor

My first guess is the Ergy plugin is causing this. If you are using Ergy, then contact support. If you are not using Ergy, then uninstall it.

and uninstalled, I hop that was the problem.

Thanks,
Cor

By any Chance are you getting the “cannot write user data error” before?

@ Z-Waver: Unfortunalety I still get the error at exactly the same time.
@ tt55du: I do have these errors as well , but I haven’t changed anytging on my system the last 2 weeks, so no "“cannot write user data error” in combination with these LUUP restarts at 11:48

I have asked also customer support , and the have activated verbose logging yesterday.

Today at 11:48 LUUp restarted again. I tried to get the LUApnp.log file with this code: http://IP adress/cgi-bin/cmh/log.sh?Device=LuaUPnP

But it didn’t go far enough back in time. Anything I can do to look in the logs and see if I see something wrong? Or can only customer support look at these log files?

Thanks,
Cor

Sorry, I don’t know what’s up with your system. There are too many possibilities.

The Wiki , as well as countless forum posts, has information on accessing log files and interpretting log files.

Frankly, I wouldn’t bother. Without a good understanding of how Vera works and how the logs should look under normal circumstances, support is going to be your best option.

Just recieved word from Customer services:

As far as I can see in the logs, you have several PLEG conditions set up for most of your devices whenever an action is being performed on them. e.g. ?Alarm_switched_on?, ?A_switch_compressor_off? and so on. For testing purpose can you please edit each condition and remove the underscore from their name format?

That was a lot of work , I have 5 PLEG instances with ca 80-90 conditions :o Now it is all unreadable… Let’s see if it helps.

Cor

[quote=“Cor, post:7, topic:195741”]Just recieved word from Customer services:

As far as I can see in the logs, you have several PLEG conditions set up for most of your devices whenever an action is being performed on them. e.g. ?Alarm_switched_on?, ?A_switch_compressor_off? and so on. For testing purpose can you please edit each condition and remove the underscore from their name format?

That was a lot of work , I have 5 PLEG instances with ca 80-90 conditions :o Now it is all unreadable… Let’s see if it helps.

Cor[/quote]

suggestion for the future. backup / export your PLEGs and uninstall it. see if it helps… if it doesn’t, re-install and restore. instead of having to go through all that editing.

That was a lot of work , I have 5 PLEG instances with ca 80-90 conditions :o Now it is all unreadable..... Let's see if it helps.
Why did you remove all the "_" ? Those were legal names!

@ RichardTSchaefer: That was in the email from customer support, they activated verbose logging , today they came back to me with this email:

Hello Cornelis,

As far as I can see in the logs, you have several PLEG conditions set up for most of your devices whenever an action is being performed on them. e.g. ?Alarm_switched_on?, ?A_switch_compressor_off? and so on.
For testing purpose can you please edit each condition and remove the underscore from their name format?

Please let me know how it goes.

I look forward to hearing from you.

Regards,

All PLEG conditions were there allready before the LUUP restarts occured , so I doubt it has anything to do with the “_” , but they asked , so I can just act on it , in the hope they find the error.

@mvader: I have made a backup of the whole vera , so if the problem was not in the “_” I will just restore the backup from this morning.

About 17 hours for the next 11:48 LUUP restart … or not :-X

So I’ve been getting the “cannot write user data” error and any scenes with LUA code stops until I restart LUUP. I think it’s the same issue as yours, but I have not had a chance to set up logging.

This all appeared after the second Alexa Beta Email sent on Feb 1. Drove me batty. When the official Firmware came out that superseded that beta, I hoped that would fix the problem. Nope. I’ve been in touch with Vera support, and between the 72 hour turn around time and very little context in their suggestions beyond simple troubleshooting, I did a full back up and restore with no luck.

Then I started stripping all of my non essential plugins. What I discovered was that the problem seemed correlated to free memory and the more plugins I removed, the longer it took for the error to occur. I’m at abut 36 hours now. I have not removed all plugins. I have also contemplated getting a vera plus now that they are on special, but if it’s a memory leak, then it would just take longer for the error to resurface.

I have not removed PLEG, UPnP, or Alexs Plugin yet. I’m in the same boat as you, it worked before the FW update.

i had that error before i believe. i wiped my /tmp and backup dir’s to free up space (and possible another dir) and then did a re-install
i think it’s an out of space issue.
i did find out that i was using the energy plugin and even though i got ride off it, there is a file that holds that energy data and it gets huge from storing your energy info. i make sure to nuke that as well. have not had any issues since

@mvader,

Interesting, I have a bunch if crap in /tmp. Is it safe to delete all of that? At my job, /tmp doesn’t necessarily mean temp!
Actually, do you have any breadcrumbs to how-to on what is safe to delete. I saw one on the wiki a while back and made no sense.

yeah you’ll want to be careful. i’ll see if i can’t dig up any notes i made on the issue when i get home from work.

Not sure what to think about it.

Today 11:48 >> no LUUP restart.

BUT, i see there was no an error in my PLEG ( invalid token) , since I changes all the condition names , and some conditions relied on the state change of another condition.

windows doors (PLEG)[164] : Efirstmessagecold AND ! E_second__timer AND (( E_repeat_msg_bedroom_guest_cold ; E_Bedroom_guest_open ) or ( E_repeat_msg_bedroom_guest_cold ; now > 5:00)): Invalid Key token: E_REPEAT_MSG_BEDROOM_GUEST_COLD

Now I have changed all the conditions where there was a part in red in the condition , I think all PLEG should be OK now.
23,5 hours to wait untill it is 1148 AM again ???

@ RichardTschaeffer: any thougts? or is it to you obvious I didn’r recieve a LUUP restart because there was this error in my PLEG now.

Thanks,
Cor

To add to this, anyone notice that the luup engine reloads every time you change the house mode from the dashboard. I have a function that sends me a text message every time the engine reloads and while testing some code with house modes, i noticed this behavior.

That is not normal behaviour. Please contact support to investigate it.

2 days later , nu unexpected LUUP restarts , so it seems the underscores were an issue.

[quote=“RichardTSchaefer, post:9, topic:195741”]

That was a lot of work , I have 5 PLEG instances with ca 80-90 conditions :o Now it is all unreadable… Let’s see if it helps.

Why did you remove all the “_” ? Those were legal names![/quote]

Richard; can I do anything to help troubleshooting? since also I would like to habe my condition names readable again , it is now very unreadable without the underscores.

Can it be the names were too long? Removing the underscores took mostly 4-5 characters away from all names.

Thanks,
Cor

I know of no size limits.

@ RichardTSchaefer; do you have any idea how I can troubleshoot this? since it somehow had to do with removing the underscores from the names.

Thanks,
Cor