Stats4Lox - Das Statistik-Plugin

[Grestorn]

Ich habe ein Problem, das Plugin auf einem neu installierten Raspi5 mit Trixie und Loxberry 4.0.11 zu installieren.

Das Logfile bei der Installation deutet auf ein Problem mit einem InfluxDB-Package hin.

Wollte nur nachfragen, ob das ein bekanntes Problem ist oder ein spezielles Problem, von dem nur ich betroffen bin und von `deswegen auch nur von mir behoben werden kann?

[Prof.Mobilux]

Ja das ist bekannt. Werden wir in der nächsten Version fixen.

[Eimerkind]

Eine grobe Idee, wann der FIX mit der nächsten Version kommen wird? =)

[Danimal]

Stats4Lox importiert keine Loxone-Objekte (vermutlich wegen Loxone 17)?
Hallo zusammen. Hab gerade heute das aktuelle plugin installiert und bekomme keine Daten. Kann das wegen der Lox17 version sein? Das Import Fenster bleibt auch hängen und in den grabber logs finde ich nichts. Danke für einen Tip.

[Grestorn]

Eigentlich nicht, bei mir funktioniert Sats4Lox auch mit Version 17 der Miniserver-Firmware einwandfrei. Es muss eine andere Ursache haben. Stell nochmal sicher, dass der User, den Du in Loxberry nutzt, die vollen Rechte auf dem Miniserver hat.

[Danimal]

Danke. Das mit dem User Rechten stimmt, ich habs geprüft.

Aber nach einiger Recherchen kann ich folgendes berichten:

LoxBerry 3.0.1.3
Stats4Lox 0.9.10.2
Loxone 17.0.3.31

LoxAPP3.json kann geladen werden.
Admin-Benutzer mit Vollzugriff.
stats.json bleibt leer ({})
Statistic Selection hängt bei:
"Fetching Loxone Config from Miniservers..."
grabber_loxone.cgi liefert HTTP 200 aber keinen Inhalt.

Hast Du vielleicht dazu noch eine Idee?

[Grestorn]

Melde Dich mal ab und neu an am Miniserver. Das klingt nach einem kaputten Access Token.

[Danimal]

Einmal Passwort neu eingeben und saven müsste reichen, oder?

[Danimal]

Das mit dem Re-Auth hat scheinbar doch geholfen, ich finde jetzt endlich Einträge im Log.
Leider hängts noch, aber hier etwas mehr Info, Vielleicht hast Du dazu ja auch eine Idee?


INFO: LoxBerry Version 3.0.1.3 ( is_arch_x86_64.cfg is_x64.cfg is_hwmodel_x86_64_vm.cfg )

INFO: Stats4Lox Version 0.9.10.2

INFO: Loglevel: 7

INFO: Checking MS1

OK: MS1: Aquired serial from MS: 504F94D0EF63

CRITICAL: Loxone::GetLoxplan::checkLoxplanUpdate--> Could not fetch local version info

INFO: Loxplan file not up-to-date. Fetching from Miniserver
.....
....
weiter unten aber:

INFO: Loxone::GetLoxplan::getFile--> Uripart: /dev/fsget/prog/sps_0267_20260620112550.zip Localfile: /dev/shm/s4ltmp/s4l_loxplan_ms1.zip

OK: Loxone::GetLoxplan::getFile--> File successfully downloaded to /dev/shm/s4ltmp/s4l_loxplan_ms1.zip

INFO: Loxone::GetLoxplan::getLoxplan--> Local file: /dev/shm/s4ltmp/s4l_loxplan_ms1.zip

INFO: Cleaning up old files

INFO: Loxone::GetLoxplan::getLoxplan--> Unzipping zip

INFO: Loxone::GetLoxplan::getLoxplan--> Calling unpack_loxcc.py

OK: Loxone::GetLoxplan::getLoxplan--> Finished

OK: Loxplan for MS1 found, parsing now...


INFO: loxplan2json started

INFO: Reading local Loxplan json

[Danimal]

Hier hätte ich mal die Analyse, wieso es bei mir nicht weitergeht. Vielleicht hilft das? Stats4Lox 0.9.10.2 – Import hängt bei "Fetching Loxone Config"

Umgebung

• LoxBerry: 3.0.1.3
• Stats4Lox: 0.9.10.2
• Loxone Miniserver: 17.0.3.31
• Grafana läuft auf Port 3000
• Telegraf / InfluxDB installiert und aktiv
• Miniserver in LoxBerry korrekt angelegt
• Benutzer: Admin mit Full Access

Ursprüngliches Problem


Beim Öffnen von Statistics Selection bleibt die GUI dauerhaft bei:

Fetching Loxone Config from Miniservers...

stehen.

Dadurch erscheint keine Statistik-Auswahl und stats.json wird nicht aufgebaut.

---

Bereits geprüft

Miniserver erreichbar

curl -I http://<MS-IP>/data/LoxAPP3.json


liefert erwartungsgemäß HTTP 401.

Mit Benutzer/Passwort:
curl -u admin:<passwort> http://<MS-IP>/data/LoxAPP3.json | head


wird die komplette LoxAPP3.json erfolgreich geladen. Authentifizierung erneuert


Nach dem Neu-Anlegen der Miniserver-Authentifizierung im Plugin wurden erstmals sinnvolle Logeinträge erzeugt.

---

Aktuelle Logs


grabber_loxone.log enthält keine Fehler:
grep -i "error\|critical\|warning\|failed" \
/opt/loxberry/log/plugins/stats4lox/grabber_loxone.log


liefert keine Treffer.

---

Loxplan wird erfolgreich geladen


Im AJAX-Log erscheint:
INFO: Checking MS1
OK: MS1: Aquired serial from MS: 504F94D0EF63

CRITICAL: Loxone::GetLoxplan::checkLoxplanUpdate--> Could not fetch local version info

INFO: Loxplan file not up-to-date. Fetching from Miniserver
...
OK: Loxone::GetLoxplan::getFile--> File successfully downloaded
INFO: Loxone::GetLoxplan::getLoxplan--> Calling unpack_loxcc.py
OK: Loxone::GetLoxplan::getLoxplan--> Finished
OK: Loxplan for MS1 found, parsing now...

INFO: loxplan2json started
INFO: Reading local Loxplan json


Danach endet das Log.

---

Auffälligkeit


In ParseXML.pm ist die nächste Logzeile innerhalb von readloxplan():
$log->INF("Reading LoxBerry Miniserver list");


Diese Zeile erscheint niemals im Log.

Der Import scheint also vor oder direkt beim Aufruf von readloxplan() stehenzubleiben.

---

stats.json bleibt leer


Datei:
/opt/loxberry/config/plugins/stats4lox/stats.json


Inhalt:
{}


Größe:
wc -c /opt/loxberry/config/plugins/stats4lox/stats.json


Ergebnis:
3

---

LoxAPP3.json enthält Statistikobjekte


Beispiel:
{
"name":"Außentemperatur",
"type":"InfoOnlyAnalog",
"statistic":{
"frequency":5
}
}


Weitere Typen:
InfoOnlyAnalog
InfoOnlyDigital
LightControllerV2
Dimmer
Pushbutton
Switch
Tracker
...


Die Statistikdefinitionen sind also grundsätzlich vorhanden.

---

Beobachtung im Code


ParseXML.pm erzeugt in readloxplan() ein Hash %lox_statsobject und übernimmt dort alle Controls.

Am Ende:
$combined_data{controls} = \%lox_statsobject;
return \%combined_data;


Daher wäre zu erwarten, dass stats.json nach erfolgreichem Lauf viele Einträge enthält.

Tatsächlich bleibt die Datei jedoch dauerhaft:
{}

---

Frage


Ist dieses Verhalten bekannt mit:

• Stats4Lox 0.9.10.2
• Loxone 17.0.3.31

oder gibt es einen bekannten Bug, bei dem stats.json leer bleibt und der Dialog "Fetching Loxone Config..." dauerhaft hängen bleibt?

Danke vielmals für die Hilfe. Gruss DM

[Steini]

Ich hatte mal ein ähnliches Phänomen und damals habe ich als Ursache die Loxone-eigene Husqvarna-Integration (https://www.loxone.com/dede/kb/husqvarna/) ausgemacht. Als ich diese aus meinem Loxone-Projekt entfernt hatte klappte es wieder und auch mit der V17. Gut möglich, dass es bei dir an einem ähnlichen Problem liegt.

Leider weiß ich nicht mehr was genau das Problem damals bei mir war und wie ich darauf gekommen bin, dass es die Husqvarna-Integration war, aber Schlussendlich war das Entfernen der Husqvarna-Integration die Lösung.
Da ich sowieso das Loxberry Husqvarna Automower Connect Plugin nutze war, das für mich auch kein Problem.

Vielleicht hilft es dir ja.

[Danimal]

Danke für Deine Antwort und den Hinweis. Ich hab zwar keine exotischen Dinge da drin, ausser SONOS.... Aber ich könnte mal mit einer ganz frischen Umgebung nochmals probieren...... Sonst muss ich dann den MQTT Weg nehmen.

[mouzzz]

Danimal : Bei mir besteht dein oben beschriebenes Problem bereits seit über einem Jahr. Im Winter hatte ich am Prox-Server parallel eine Neuinstallation gemacht welche ohne Fehler lief. Bin aber wieder auf die alte (fehlerhafte) zurück weil ich es nicht schaffte meine Daten mitzunehmen