What's New in V1.2.5

Konkrete Version: 1.2.5.5 (RELEASE)

LoxBerry Update Fehler/Failure

Bei Problemen mit LoxBerry Update von LoxBerry vor V1.2.4 → LoxBerry Update Fehler ("Try 5: Checking file size of download...")

On problems with LoxBerry Update from below V1.2.4 → LoxBerry Update Failure ("Try 5: Checking file size of download...")

Alexa4Lox

Alexa4Lox Users - please update to alexa4lox 0.10b - see here

Without the update, you will get "/etc/cron.hourly/logrotate: error: skipping "/var/log/apt/term.log" because parent directory has insecure permissions" emails because alexa4lox changes system permissions.

Wichtig

Dieses Update wird allen Benutzern dringend empfohlen, die Probleme mit einer voller RAM-Disk haben oder hatten. Bei allen Symptomen wie: Daemons arbeiten nicht mehr, Webabfragen gehen nicht mehr, Disk Full Meldungen → Dieses Update installieren. Kein Support zu den genannten Fehlern bei einer LoxBerry-Version unter 1.2.5.

This update is urgently recommended for users with problems of a full ramdisk. Symptoms are: Daemons don't work anymore, web requests do not work, disk full messages → Install this update. No support for the mentioned errors with LoxBerry versions below 1.2.5.

DATA LOSS issue in V1.2.5 - Update to this version!

Aufgrund eines Timing-Problems, welches erst mit LoxBerry 1.2.5.0 bis 1.2.5.4 in Zusammenhang mit DHCP eingeführt wurde, besteht die Gefahr, dass USB-Datenträger während des Hochfahrens gelöscht werden! Bei Verwendung von USB-Datenträgern dringend das Update auf V1.2.5.5 installieren. Details und wie du einen Vorfall verhinderst, siehe https://www.loxforum.com/forum/projektforen/loxberry/allgemeines-aa/177362-attention-usb-storage-data-loss-issue

Because of a timing issue in versions between LoxBerry 1.2.5.0 and 1.2.5.4 together with DHCP it may occur that connected usb storage devices are deleted on startup! This is an urgent update to version 1.2.5.5 if you use usb storage devices. For details, and how to stay safe, see https://www.loxforum.com/forum/projektforen/loxberry/allgemeines-aa/177362-attention-usb-storage-data-loss-issue

Wie oben bereits beschrieben, wird das im Forum genannte Datenverlust-Problem behoben. Es finden in V1.2.5.5 auf externen Datenträgern beim Hochfahren keine Löschaktionen mehr statt. Wie beschrieben, hat das mit 1.2.5 implementierte Warten auf die IP-Adresse bei DHCP dazu geführt, dass das Vorbereitungsscript, das eigentlich die Mountpoints vor dem Einhängen aufräumt, erst nach dem Mount gelaufen ist. Es findet jetzt keine Löschaktion mehr statt, wenn es sich um externe Datenträger handelt.

Like mentioned above, the data loss issue we warned in Loxforum about, is fixed. In V1.2.5.5 no deleting actions are taken on external storage devices anymore. In V1.2.5, a delay was implemented to wait for the ip address from dhcp. This caused that the cleaning up to prepare the folders to mount has taken place after the actual mount. Now, no cleanup is done anymore, if external storage is already mounted.

Wir haben uns intensiv mit den immer wieder auftretenden Problemen mit voller RAM-Disks beschäftigt. Das Problem bis 1.2.4 ist: Plugins loggen mehr, als im Zyklus des Cleanups aufgeräumt werden konnte. Es sind bis 1.2.4 mehrere, unterschiedlich große RAM-Disks im Einsatz, die voll werden konnten. Das konnte die Funktion von Plugins zum Erliegen bringen.

Mit 1.2.5 wurden folgende Punkte durchgeführt:

• Die verschiedenen, unterschiedlich großen RAM-Disks sind aufgelöst, und es wird eine große RAM-Disk gemeinsam verwendet. Das Maximum wird auf 50% des Speichers festgesetzt (Pi2/3: ~486MB). Es wird in Ausnahmefällen Swapping auf der SD verwendet, wenn sonst nicht genügend Systemspeicher vorhanden ist (jedoch in geringerem Ausmaß, als es in Raspbian Standard ist). 
• Der Linux-Systemdienst logrotate wurde durch eine eigene, auf die Plugin-Logs und die Logging-SDK abgestimmte Cleanup-Routine ersetzt.
• Das Cleanup von Logfiles, die in LoxBerry 1.x ja alle in der RAM-Disk liegen, wird jetzt jede Stunde (statt jede Woche) durchgeführt. Aufgeräumt werden ALLE Logfiles ALLER Plugins, nicht nur jene des Logging-SDK's von LoxBerry, regelmäßig in einem gemäßigtem Modus, sowie in einem schärferen Modus, wenn unter 25% Speicher in der RAM-Disk vorhanden ist.
• Plugin-Entwickler: Die Verzeichnisstruktur der Logfiles ändert sich dadurch nicht - alle bisher genutzten Log-Verzeichnisse bleiben erhalten wie bisher. (Wir ändern in Loxberry 1.x niemals bestehende SDK-Funktionen oder das LoxBerry-Core System, die eine Anpassung eines Plugins erforderlich machen würde)

We have intensively engaged to the reoccuring issues with full ramdisks. The problem up to and including 1.2.4 is: Plugins do more logging as the cleanup cycle could remove. Up to 1.2.4, multiple different sized ramdisks are used that could get full. This could stop plugins from running.

With 1.2.5 we did the following enhancements:

• All the different ramdisks are liquidated, and one big, common ramdisk is used. The maximum is set to 50% of the main memory (Pi 2/3: ~486MB). For corner cases, the swap file is used on memory pressure (but with less priority then in the Raspian default setting).
• The Linux system daemon logrotate was replaced by an own implementation, that better fits the needs of our ramdisk, the plugin logfiles and the Logging SDK.
• The cleanup of logfiles, that are located on ramdisk in LoxBerry 1.x, is now scheduled hourly (instead of weekly). The cleanup clears ALL old logfiles, not only the logs created with LoxBerry's logging feature. The cleanup is executed in a soft mode regularly, and an aggressive mode, when ramdisk has less than 25% free space. 
• Plugin developers: The directory structure for logfiles does not change - All directories for logfiles stay as they are. (We never change published SDK functions or Loxberry-Core basics in LoxBerry 1.x, that would require an adoption of your plugins.) 

In den Systemeinstellungen findet ihr das neue Widget Log Manager - Euer Werkzeug, um System- und Plugin-Logfiles ausfindig zu machen, den Status zu kontrollieren und die Logs zu öffnen.

Es gibt den Tab Logfiles, in dem alle Logfiles, die per LoxBerry-Logging-Funktionen erstellt wurden, mit vielen Infos aufgelistet werden. Bei unterstützten Plugins könnt ihr dort auch gleich den Loglevel ändern. Im Tab Mehr Logfiles findet ihr zudem jene Logdateien, die von den Plugins ohne LoxBerry-Logging-Funktionen erstellt wurden. Zuletzt gibt es einen Tab Apache Log, der direkt das Apache Logfile öffnet, in dem zusätzliche Systemmeldungen - insbesondere bei Fehlermeldungen wie z.B. Error 500 - ausgegeben werden.

Bitte übermittelt bei jedem Problem das (ganze) Logfile mit - stellt vorher den Loglevel auf DEBUG, damit der Entwickler mehr Informationen erhält. Vergesst nicht, den Loglevel danach wieder zurückzusetzen (z.B. auf Fehler). 

Die Logdateien - sowohl in Logfiles als auch in Mehr Logfiles, werden von der Aufräumfunktion von LoxBerry überwacht und nach Anzahl, Alter und Größe automatisch entfernt. 

In the System Settings page, you'll find the new widget Log Manager - Your tool to find system and plugin logfiles, check the status and open logfiles.

On the tab Logfiles all logfiles created by LoxBerry's logging capabilities, with infos about the status and the run-time. With supporting plugins, you also can directly change the logging level of the plugin. On the tab More logfiles, you'll find logfiles created by plugins using their own logging functions. The last tab, Apache Log, directly opens the Apache logfile, that shows further system messages - especially errors like Error 500 when opening a page.

Please, for every issue you open, add the (full) logfile - for debugging change the logging level to DEBUG to give the developer more information. Don't forget to switch back to a normal logging level like "Errors" after debugging.

All logfiles - both Logfiles and More logfiles - are managed by LoxBerry's cleanup mechanism, that clears logfiles automatically by count, age and size.

Wir haben durch eine verbesserte Implementierung des Lesens der Sprachen die Performance der Weboberfläche erhöht. Dies betrifft sowohl die System-Webseiten als auch Plugins, und sowohl Implementierungen in Perl als auch in PHP. So reduzieren wir das Laden der Webseite - je nach Rasberry-Modell - um etwa 200 ms bei LoxBerry Widgets, und evt. noch etwas mehr bei Plugins.

We have improved the webinterface performance by a better implementation for reading the languages. This concerns the system widgets and the plugins, and both Perl and PHP. The improvement reduces the webpage loading time - dependent on your Raspberry model - around 200ms for system widgets, and possibly a bit more for plugins.

Wir stellten fest, dass LoxBerrys, die Miniserver über Cloud DNS angebunden haben, im Webinterface sehr langsam waren. Ursache war ein zu häufiges Abrufen der Cloud DNS IP-Adresse in Situationen, wo das gar nicht benötigt wurde. Das passiert jetzt nicht mehr.

We determinded, that LoxBerrys using Miniservers via Cloud DNS, are very slow in the webinterface. Reason were to many recalls of the Cloud DNS IP in situations the ip was not needed. This behaviour was fixed.

Im Widget "Plugin-Verwaltung" wurde die Loglevel-Einstellung "Aus" nicht gespeichert. Beim Reload der Seite war der Loglevel auf dem alten Wert. Ein komplettes Abschalten des Loggings eines Plugins war deswegen nicht möglich. 

Plugins, die die LoxBerry-Logging-Funktionen benutzen, zeigen im Log Manager - unabhängig von der Logging-Einstellung! - immer den Status an. Auch wenn kein Logfile vorhanden ist, sind dadurch Fehler bei der Ausführung sichtbar. Wenn ein Plugin einen kritischen Abbruch initiiert, wird zudem trotzdem ein Logfile ab dem Abbruch erstellt, um die "letzten Worte" vor dem bevorstehenden Tod zu speichern.

In the "Plugin management" widget, the loglevel setting "Off" was not saved. After a refresh of the page, the loglevel stayed on the old value. Therefore, completely disabling of the logging of a plugin was not possible. 

Plugins using LoxBerry's logging functionality always show the status in Log Manager - independent of the logging setting! Also without a logfile, the status of the run-time is visible. Furthermore, if a plugin initiates a critical termination, also a logfile is created to store it's "last words" before it's untimely death.

In some of our plugins we already used the V1.2.4-introduced functions from Perl-LoxBerry::IO and we did not understand why we hadn't implemented that before. It is essential to have this in PHP too.

The new PHP library loxberry_io.php simplifies communication to the configured Miniservers.

It provides functions to get and send single and multiple values via http rest webservice (mshttp_get, mshttp_send), and single or multiple values via udp (msudp_send).

We are proud to care about Miniservers life with our special http and udp functions mshttp_send_mem and msudp_send_mem that only sends values if they really have changed. In your plugin you can "statically" send all the attributes you want to send, and the library handles to only send the new values, and skips values that are equal from the last transmission. That keeps the Miniserver interface (and for udp: command recognition engine) free of traffic.  

The "raw" feature mshttp_call allows you to send the "raw" Loxone webservice paths (e.g. /dev/sps/io…) using the LoxBerry-configured Miniservers. Besides http code and value, it returns the xml datastructure of the response.

All the http functions implement special error handling as Loxone always returns http status code of 200 OK - ignoring that an object may not exist

We will add further functions in the future to improve network communication to the Miniserver and in general.

The function loglist_html (Perl: LoxBerry::Web::loglist_html, PHP: LBWeb::loglist_html) is now also available in PHP (V1.2.4: Perl) and returns a HTML with a list of your logfiles to integrate directly in your plugin. 

This function now uses the layout of the new Log Manager to provide the same look and feel for the user. 

A code example in Perl is here, in PHP the call is the same.

So, to get the full view of the first picture, you need the code-snippet and - in Perl - that HTML::Template code.

You might have noticed, that the example code does not implement an own loglevel selection - the loglevel selection directly is done by loglist_html (e.g. Log Manager) automatically.

Using the function loglevel_select_html() you can provide LoxBerry's loglevel selection directly in your plugin. See LoxBerry::Web::loglevel_select_html (Perl) and LBWeb::loglevel_select_html (PHP).

Starting with V1.2.4, the log title sent with LOGSTART, is saved and listed in the loglist, visible for the user.

In many situations at the beginning of the logging you don't have all the information to give the log a meaningful title. Therefore, on every log object, you now can change the log title during runtime.

For the object method, use $obj->logtitle("New title"), or you also can use the shortcut LOGTITLE("New title"). 

Examples are located in the constructor documentation of the logging object LoxBerry::Log::new (logging constructor) (Perl) and LBLog::newLog (logging constructor PHP) (PHP).

See a living Perl example in LoxBerry Backup. 

• LogBerry::Log and loxberry_log.php will never die - in no circumstances - when there is a problem with the logging database. It implements a check to recover the database, and if that fails, it simply continues to log, but without the database. All errors are send as warnings to STDERR, but don't stop the script.
• The cleanup of logfiles was implicitely called during logging, if ramdisk diskspace was below 25%. This reduced runtime performance and now is not needed anymore and removed, as the cleanup is triggered by cron hourly.
• An error on accessing the logfile (e.g. disk full), and several other possible errors, do not kill the calling script anymore.
• The loading time of the LoxBerry::Log module was improved by optimizing the loading of prerequisited modules only on demand of the called function (Pi2: ~100-200ms).
• The logfile cleanup procedures code was removed from LoxBerry::Log, and moved to the maintenance scripts, for better clearance and improved loading time of the lib. 

With V1.2.5 we have easified the handover of a logging session from script to script. This enables you to continue a logging session in another script.

In the caller script - before calling the second script - request the logging session id with $log→dbkey(). Provide this key to the called script.

In the called script, create a new logging session, but only provide the dbkey as parameter (nothing else). Don't call LOGSTART in the called script, but simply continue to log. All the logging settings are restored from the initial constructor in script 1.

This works also for handover's from Perl to PHP and vice versa!

Just to say it: Also the Bash Logging SDK was enhanced to support Log Managers capabilities, e.g. collecting start and end time of the script, and show the status of the log. We also more than doubled the speed of the Bash Logging SDK by switching from Perl to PHP for the interface calls. See LoxBerry Logging in Bash.

From the experience of plugin developers and ourselfs, we have summerized some tips and tricks for the Logging SDK: LoxBerry Logging: Tips and tricks

Dependent to the parameter, the currtime function returns a human-readable timestamp (default), an ISO 8601-compliant timestamp (parameter 'iso') or a filename-optimized version (parameter 'file').

We added a new format with the 'filehires' parameter, that outputs a filename-optimized timestamp including milliseconds (e.g. 20181007_104543_598) for better uniqueness of filenames. This new format is used by the filename-creation of the Logging SDK in Perl and PHP starting with V1.2.5.

LoxBerry::System::currtime (Perl), LBSystem::currtime (PHP)

• All the system templates used in plugins (headers, footers) are now fully HTML5-compliant to make it more easy to find HTML5 violations in your plugin templates.
• Also most of the system widgets are now HTML5-compliant.
• For your information (possibly you want to make your plugin HTML5-compliant too), main HTML5-violations we had in our code:
  • <center> tags → <div style="text-align:center;">
  • <p> tags that included no text but only subordinated <div>'s
  • <table>, <tr>, <td> tags that included border=, width=, valign= attributes → must be done in style attributes
  • Every <img> tag need an alt= attribute
  • On form input fields, only autocomplete="off" or "on" is allowed
  • Own attributes in tags, storing information e.g. for JavaScript, are only allowed with the data- prefix (e.g. <input data-plugin="anyplugin">
  • <font size="-1"> is not allowed → Use e.g. style="font-size:80%;">
  • We had some duplicate element id's because of looping for the form generation 

The LoxBerry-Core team agreed that this release, 1.2.5.x, will be the last feature/enhancement release of the 1.2 series.

We will further publish hotfix releases, but will concentrate to support plugin developers to use the current SDK features, and finish own plugin projects that were delayed due to LoxBerry 1.x development. (We thought to get holidays for 100 days, but reconsidered to have better things to do ) 

Developers, or upcoming developers, please contact us for backing you on your work. Use the PM function in LoxForum to exchange contact infos for the WhatsApp Plugin Developer group.

• Alle LoxBerrys betrieben mit dem VMware-Image loxberry-image-vmware-1.0.2-gandalf.zip von orli haben die gleiche ID, da diese im Image enthalten ist. Beim Update auf 1.2.5 wird für diese VMs eine neue, eindeutige ID generiert, um die Statistik zu korrigieren.
• Updated language file for Dutch (language NL), including new Log Manager (thanks to gmkey!)
• Aus der /etc/hosts wird der Hostname entfernt. Der Eintrag stammt aus einem Debian-Workaround, der bereits 2013 gefixt wurde, jedoch hat Debian den Workaround nie entfernt. Der Eintrag 127.0.1.1 loxberry hat dazu geführt, dass bei Betrieb von dnsmasq (z.B. mit dem Wetter-Emulator von Weather4Lox) der Hostname des LoxBerrys am Miniserver falsch mit 127.0.1.1 statt seiner richtigen IP-Adresse aufgelöst wurde.
• LoxBerry Update zeigt nun an, ob es sich beim letzten gefundenen Stand um einen Release oder Pre-Release handelt.
• LoxBerry Update verwendet für die Ansicht der Logfiles nun die Log Manager-Ansicht
• LoxBerry-Core: Ein System-Loglevel für LoxBerry-eigene Funktionen wurde eingeführt. Dieser ist derzeit nicht über das UI zu ändern, sondern nur in der general.cfg unter BASE.SYSTEMLOGLEVEL. Standard ist Loglevel 6.
• Rückwirkende Verbesserungen an den Update-Scripts auf 1.2.3 und 1.2.4 (wirksam nur für LoxBerry's unter 1.2.3/1.2.4 bzw. Neuinstallationen)
• LoxBerry Update wird automatisch nach dem ersten Start ausgeführt (wirksam nur für LoxBerry-Neuinstallationen)
• LoxBerry Update wird standardmäßig auf automatisches Update auf Release eingestellt (wirksam nur für LoxBerry-Neuinstallationen)
• Wird beim Logging-SDK addtime => 1 verwendet, wird jetzt die Zeit inkl. Millisekunden protokolliert (Perl, PHP) - das vereinfacht die Performance-Analyse
• Am Pi1 benötigt das Hauptmenü des LoxBerry nun weniger Systemressourcen
• Fix: "Database is locked" Fehlermeldung bei gleichzeitigem Zugriff auf die Logfile-Datenbank wird verhindert
• Fix: mshttp_send_mem/msudp_send_mem: Korrektur der Berechtigung, wenn das File gleichzeitig von einem Plugin als Benutzer root angelegt und später von Benutzer loxberry genutzt wird (permission denied Fehlermeldung)
• Verbesserung: Aussagekräftige Fehlermeldungen wenn die Plugin-Version nicht zur LoxBerry-Version passt (nur deutsch)
• FIX: Aufgrund eines Timing-Problems, welches erst in LoxBerry 1.2.5 in Zusammenhang mit DHCP entstanden ist, besteht die Gefahr, dass USB-Datenträger unter LB 1.2.5 während des Hochfahrens gelöscht werden! Bei Verwendung von USB-Datenträgern dringend das Update auf V1.2.5.5 installieren. Details und wie du einen Vorfall verhinderst, siehe https://www.loxforum.com/forum/projektforen/loxberry/allgemeines-aa/177362-attention-usb-storage-data-loss-issue

Commit Log: https://github.com/mschlenstedt/Loxberry/compare/1.2.4.6...1.2.5