Most of the modules display their version number in the log at the start of a reload.
However, this isn’t satisfactory, and I’m currently working on using the Plugins page of AltUI to display the current version of known plugins and also to install / update / remove them with one click. See attached screen shot.
Not yet in the latest version, though!
ah… very good…
Would really have an option to sync “room” from Vera too!
Latest version in development branch has a CloneRooms variable which should be set to true to force all bridged devices to be in the same rooms as on the remote Vera. Devices which are in “No Room” remotely, are placed in the appropriately named “MiOS…” room which corresponds to the remote machine name.
To install this version of VeraBridge, simply enter development into the Update box against VeraBridge on the Plugins page, and press Update.
I am getting (may be wrongly) concerned that openLuup’s logging activity to the SD card on the Raspberries Pi that I am using might result in premature wear of the cards… Could you consider allowing the user (say as an openLuup device variable) to specifiy a ram drive for openLuup’s logging activity (i.e. what is currently written in /etc/cmh-ludl/ or whatever is the openLuup running folder) ?
Edit: I appreciate the logging in /var/cmh is not versioned and can become quite big for a ram drive, so as a trade off its maximum file size could be reduced also at the user’s option ?
Obviously the user would have to create the ram drive based on the specific of the system openLuup runs on. For instance I already pointed /var/log/cmh to a ram drive for the variable logging.
Two separate issues here…
/var/cmh/LuaUPnP.log
I appreciate the logging in /var/cmh is not versioned and can become quite big for a ram drive, so as a trade off its maximum file size could be reduced also at the user's option ?
… indeed, I didn’t version it because it’s not important and I didn’t want to use up too much space. IIRC it’s currently set at 5000 lines, which might be about half a Mbyte. I have no control over where it is written or what it is called because it is only there for the convenience of AltUI, which uses it to retrieve variable, scene, and workflow history (as used in the variable display pages.) For this reason, openLuup doean’t write a full log here, only those relevant events. openLuup tries to be as similar as possible as Vera (but better) which uses this same name / location. However, AFAIK, /var is generally mapped to /tmp so should be in RAM anyway?
/etc/cmh-ludl/LuaUPnP.log.*
This is easy to change and make user configurable, because AltUI makes no use of this. It currently is versioned (last 5 rotations, needed for debugging across restarts) and is about 2000 lines for each. It’s really an historical accident that it writes the log here… I just want as simple a directory structure as possible, in the old days. I’ll make the change to the development version before I make it the latest master release. I’m likely to put the configuration into Startup Lua, rather than openLuup device variable(s).
Yes, I realized that after posting and was probably editing my initial post when you wrote your answer… I indeed already have the /var/cmh/LuaUPnP.log pointing to a tmps ram mount. Was easy to do and indeed the 5000 lines limit is very reasonable (I figured that limit from reading the code in the logs.lua module, that I should have dissected earlier… my bad).
[quote=“akbooer, post:86, topic:189405”]/etc/cmh-ludl/LuaUPnP.log.*
This is easy to change and make user configurable, because AltUI makes no use of this. It currently is versioned (last 5 rotations, needed for debugging across restarts) and is about 2000 lines for each. It’s really an historical accident that it writes the log here… I just want as simple a directory structure as possible, in the old days. I’ll make the change to the development version before I make it the latest master release. I’m likely to put the configuration into Startup Lua, rather than openLuup device variable(s).[/quote]
That would be great. Indeed a startup lua option is most probably best !
Many thanks
Would it be possible to be able to adjust the number of versions kept, I’ve had a couple of instances where DataYours have stopped watching (without losing the config) variables but looking back through the logs it happened many hours before the last available log so It would be useful to temporarily increase the logged time period whilst I try and work out whats going on.
Yes. I’m just testing the mods described below which will give configurable file name, location, length, and number of versions.
This turns out to be harder than I first thought for the simple reason that loggign begins both before Lua Startup runs and, indeed, before user_data.json is read.
This may have to be in a separate openLuup configuration file… something which I have been trying to avoid.
maybe a special log option?
A third parameter to the luup.log call maybe that does write to a configurable log location. Useful for these type of scenarios where you want to keep logging separate from anything else?
I now often use the sylog option (using your code ;)) for that, but I do find it cumbersome to browse through that on my NAS GUI. On the other hand, that bit of code can also be adapted to write to a specific file too.
Cheers Rene
[quote=“reneboer, post:91, topic:189405”]maybe a special log option?
A third parameter to the luup.log call maybe that does write to a configurable log location. Useful for these type of scenarios where you want to keep logging separate from anything else?[/quote]
That’s a slightly different issue, and one that I’m addressing (for developers) in a different way… through an additional console interface to peruse some of the inner workings of openLuup.
@logread has made a great suggestion for the general log file issue, which I’ll be prototyping soon.
I now often use the sylog option (using your code ;)) for that, but I do find it cumbersome to browse through that on my NAS GUI. On the other hand, that bit of code can also be adapted to write to a specific file too.
Yes, in fact until last week the syslog code was in there, but not enabled, in the logging module. I’ve taken it out now since I don’t believe it would be widely used even if enabled.
I believe I’ve settled on a solution for the log file location (thanks @logread and others) and some other things which might be written too often to the home location.
Log files
openLuup now generates an extra log file LuaUPnP_startup.log, which is written to /etc/cmh-ludl/ and is versioned to save the previous five reloads. This actually is a very convenient way to check the last reload times of a system. Typically very short, this log finishes after Lua Startup code has been run, and then…
…logging continues with a file in a location of your choice, limited to a number of lines you specify, and versioned to a set number. Could be anywhere in the mounted file system.
user_data.json
This is generally written to /etc/cmh-ludl/ and, to mimic Vera, is checkpointed there every 6 minutes. These files can be quite large, for one of my systems bridged to three Veras, it’s nearly a megabyte. There is now a user-defined parameter to set the number of minutes between checkpoints. Since openLuup is so stable, there are very few changes over large periods of time (unless you are adding devices or scenes) and the file is always written before a reload (or exit) anyway. I’m now using 60 minutes as my standard, but you could easily make it 24 hours.
[hr]
All the above parameters may be set in the Lua Startup code, thus:
-- openLuup configuration options:
luup.attr_set ("openLuup.Logfile.Name", "logs/LuaUPnP.log") -- full path to log file
luup.attr_set ("openLuup.Logfile.Lines", 2000)
luup.attr_set ("openLuup.Logfile.Versions", 5)
luup.attr_set ("openLuup.UserData.Checkpoint", 60) -- checkpoint every 60 minutesA new console interface [b]http://openLuupIP:3480/console[/b] allows easy perusal of these (and other) system parameters.
I’m about to unleash these changes on the development branch, but just wanted to hear any opinions (or better ideas) before doing so.
This is a great solution (as usual coming from you…) and I actually did miss the user_data.json in my list of frequently written files… looking forward to testing it 
looks great ;D
In the spirit of keeping writes to the SD card on the RPI to a minimum is it possible to specifiy the location of “LuaUPnP_startup.log” as with the main log files Please
thanks
Nik
Given that this only happens when you do a reload, this seems hardly worthwhile? I last reloaded two of my openLuup systems over 55 days ago (others I use for development.)
unfortunately I have an Onkyo plugin which loses connection with the reciever if the reciever is powered off and nothing but a reload will resestablish connection so I have to reload several times a day so I am reloading fairly often 
Fair enough, but there’s a technical issue too,which is why there is a separate startup log in the first place… the startup parameters are not read until nearly the end of the startup process, there’s lots to do like creating devices, etc., before there’s even environment sufficient for it to run. So unless a separate file with the desired location is kept - something I really don’t want to do - then I don’t see an easy way to do this. There could be an environment variable perhaps, but, again, I’d like to keep all the configuration in just one place.
I really don’t think that once or twice in a few hours is an issue. Perhaps, also we should look at the plugin and see how to fix that? Is this the same behaviour as on a real Vera?
I agree that its not an issue and I just assumed it would have been just another attribute (location of startup.log) if its not easy then dont worry - I used a snippet of code in startup to copy the startup.log (via delayed callback - to make sure its finished starting up) to the same location of the other logs (on synology server via a mount point in cmh_ludl directory) so they are in the same place.
I did originally have the plugin running on the vera for a while and dont remember if it showed the same issue but the vera was getting unstable which is why I am moving as much as possible to the Rpi with openLuup
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules