Friday at 10:30 AM3 days The VUE plugin on my eisy has started to fail every few days. I can't download the log, the system says it can't be found. Pressing restart solves the problem and once it's running the log file is available. The file however only contains log info starting with the restart.Is this an eisy problem or a plugin problem?Thank you for any advice
Friday at 03:43 PM3 days The plug-in debug log files are only active for 24 hours. At midnight, the eisy backs up the current log and then clears the active log.Likely whatever happens, happens before midnight so no data is being collected in the log from that point on. The previous daily log files are saved but the only way to access them is via the command line.Chances are the plug-in fails to re-authenticate when the current token expires or the server stops responding and plug-in needs to re-open the connection to get it working again. The latest version, 1.0.27, was supposed to try and address the server not responding issue. If authentication fails, the plug-in gives up. The assumption is that something is either wrong on their end or the credentials are wrong and retrying to authenticate won't fix either of those issues.Emporia tolerates third party software, like the plug-in, querying their servers as long as it doesn't cause issues or cause a noticeable load.
Friday at 08:24 PM3 days Author Thanks Bob,I appreciate your explanation. I can look at the backed up log files. What is the path to them?
Saturday at 04:27 PM2 days The logs are in the plug-in's directory: /var/polygot/pg3/ns/<macaddress>_<slot#>/logsYou'll need to use sudo as admin doesn't have enough privilege to access the logs. Here's an example:[bpaauwe@polisy ~]$ sudo ls -lrt /var/polyglot/pg3/ns/000db94e3a44_7/logs total 16 -rw-r--r-- 1 000db94e3a44_7 polyglot 830 Feb 14 2024 debug.log.2023-09-11.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 734 Feb 24 2024 debug.log.2024-02-14.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 864 May 20 2024 debug.log.2024-02-24.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 863 Feb 10 2025 debug.log.2024-05-19.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 3591 Feb 10 2025 debug.log [bpaauwe@polisy ~]$ sudo gunzip /var/polyglot/pg3/ns/000db94e3a44_7/logs/debug.log.2024-05-19 [bpaauwe@polisy ~]$ sudo more /var/polyglot/pg3/ns/000db94e3a44_7/logs/debug.log.2024-05-19
Yesterday at 12:41 PM1 day Author Hi @bpwwer ,I'm able to list the files using "sudo ls -lrt /var/polyglot/pg3/ns/000xxxxxxxxx_5/logs" but for some reason I can't "cd" to the directory and actually look at the files. I figured out a workaround, attached are the final entries of June 5. The log seems to end without an error. But at 12:07am on June 6 Vue fails. There is no June 6 log as I haven't restarted the plugin yet. So, I can't see the error which occurs between6/5/26 23:59 and 6/6/26 00:07Does re-authentication occur at midnight?end of June 5.txt Edited yesterday at 12:47 PM1 day by tmorse305
Yesterday at 03:58 PM1 day Without any debug/errors shown for June 6, it's impossible to know what really happened.The last thing in the June 5 log shows the plugin executing a short poll event. When this event is executed, the plugin, via a third party library, makes a call to Emporia to get updated info for all devices. Unless there is some weird timing happening where the plugin tries to write to the log at the same time eisy is renaming the log file and that causes the plugin to crash.It might be interesting to see if the plugin was actually doing anything in the first few seconds of June 6 that would show up in the PG3x log or that may even have some details if the plugin crashed.Of course, since it's a new day, you'd have to do the same thing to look at the June 6 PG3x log. Those files are in /var/polygot/pg3/logs You may not need to use sudo to access these logs.
Yesterday at 09:10 PM1 day Author I looked through the first 7 minutes of the 6/6 PG3x log but did not see any errors. I've included the first 30 seconds or so of the 7/6/26 PG3x log. Vue is PG3x plugin slot 5.Thanks Bob. start of June 6 PG3x.txt
5 hours ago5 hr That's interesting. At least for the first 30 seconds, the plugin is sending data to IoX and appears to be working even though it's not writing anything to it's log.Is there a point in the PG3x log where the requests for slot 5 stop? The lines that look like this:IoX Request: [Try: 1] [00:21:b9:02:65:8a] :: - http://127.0.0.x/rest/ns/5/nodes/.....And are there any messages that would indicate why?Now I'm wondering if the daily log rotation is somehow causing the logging mechanism in the plugin to fail and after some amount of time, it finally hangs or blocks.You're polling every 10 seconds, right? It looks like in this case, that's happening at 0, 10, 20, 30, 40, 50 seconds and the daily log rotation happens at 0 seconds too. I believe the times it polls will depend on when the plugin is started so checking what times the poll is happening and see if the failure is only happening when the polling starts at 0 seconds.If there's a correlation there, this might be something UDI needs to look into.
Create an account or sign in to comment