Fehlersuche SV/SHNG

[jonsson]

Hallo zusammen,

ich habe SmartVISU mit SmarthomeNG vor ca. 2 Wochen neu installiert (image von onkelandy).
Da ich es leid war, 1x pro Jahr alles neu aufsetzen zu müssen weil SD card im Raspberry defekt, bin ich nun den Weg über einen USB stick gegangen.
Leider etwas langsam beim booten, ich musste ein paar timeouts anpassen, aber okay.

SmarthomeNG war ich der Meinung läuft einwandfrei, zumindest im backend sind korrekte Werte im Itembaum vorhanden.
Im log nichts außergewöhnliches, da kämpfe ich noch mit dem database plugin (jede Minute "dump" nicht möglich) und tabelle "item" exisitert, "log" aber nicht.

dann, nach einiger Zeit (einigen Stunden), geht folgendes nicht mehr
- smartVISU zeigt keine Werte mehr an
- CLI startet nicht mehr (das prompt "CLI >" kommt einfach nicht)

restart von SHNG über das backend bringt nur insofern Besserung, als die CLI wieder funktioniert, lediglich ein reboot funktioniert damit auch in der SV etwas angezeigt wird.

Ich habe es einmal hier eingestellt, weil ich nicht weiß, ob das eher in SHNG oder in der SV zu suchen ist.

Meine Frage ganz allgemein wäre, wie kann ich hier bei der Fehlersuche vorgehen.

Besten Dank
Johannes

[bmx]

Prinzipiell wird es wohl eher ein Thema für SHNG sein. Die Frage stellt sich ob die logs was hergeben und wie die Systemauslastung bei Dir überhaupt aussieht. Das Admin Interface ist dazu Dein Freund (Erbe des Backends und bessere Alternative zum CLI)

[psilo]

wieso machst du jede minute einen dump? ein dump bei meiner 5gb DB dauert inzwischen mehrere stunden!!!!

wenn die DB beschäftigt ist, lädt er natürlich keine Werte mehr, ergo kommt auch nix via websocket.. vermute das ist es.
ich habe bspw charts mit sehr vielen temperaturwerten. diese lade ich über das letzte jahr.. so lange er diese lädt, ist die smartvisu blockiert, selbst wenn ich sie auf anderen geräten aufrufe. grund: das visu_websocket ist nicht multiclientfähig im sinne parallelbetrieb. auch wäre die frage, wie sich die db verhalten würde...

"restart von SHNG über das backend" gibt es zu dem nicht, ich vermute, du meinst das neue admin interface

[jonsson]

Hallo,

danke für die rasche Rückmeldung! Verwende natürlich das admin interface, "backend" habe ich noch so abgespeichert.

Da hats wohl was mit den DB dumps, noch ist die DB leer, mal sehen woher der scheduler kommt.

Systemauslastung ganz unauffällig unter 10%


2019-08-05 20_36_54-Shngadmin.png
ich werde einmal Richtung database plugin weitersehen, vor allem läuft dies ja nicht einmal.

Im log finde ich folgende Fehler:

2019-08-05  00:52:23 ERROR    cherrypy.error.1945590992 [05/Aug/2019:00:52:23] HTTP 
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cprequest.py", line 628, in respond
>     self._do_respond(path_info)
>   File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cprequest.py", line 687, in _do_respond
>     response.body = self.handler()
>   File "/usr/local/lib/python3.5/dist-packages/cherrypy/lib/encoding.py", line 219, in __call__
>     self.body = self.oldhandler(*args, **kwargs)
>   File "/usr/local/lib/python3.5/dist-packages/cherrypy/_cpdispatch.py", line 54, in __call__
>     return self.callable(*self.args, **self.kwargs)
>   File "/usr/local/smarthome/modules/admin/itemdata.py", line 242, in item_change_value_html
>     item = self.items.return_item(item_path)
> AttributeError: 'NoneType' object has no attribute 'return_item'

Direkt nach dem init

2019-08-05  01:25:16 ERROR    root                Can not execute query: CREATE TABLE log (time BIGINT, item_id INTEGER, duration BIGINT, val_str TEXT, val_num REAL, val_bool BOOLEAN, changed BIGINT); (args OrderedDict()): (1050, "Table 'log' already exists")
2019-08-05  01:25:16 ERROR    plugins.database    Database: Initialization failed: (1050, "Table 'log' already exists")

und auch das direkt nach dem init, wobei ich das alexa plugin bis jetzt nur über das admin interface aktiviert habe, aber mich noch nicht mit der Konfiguration befasst habe

2019-08-05  01:25:16 ERROR    lib.plugin          Plugin 'alexa4p3' exception during execution of plugin: module 'plugins.alexa4p3' has no attribute 'alexap3'
> Traceback (most recent call last):
>   File "/usr/local/smarthome/lib/plugin.py", line 553, in __init__
>     exec("self.plugin = {0}.{1}.__new__({0}.{1})".format(classpath, classname))
>   File "<string>", line 1, in <module>
> AttributeError: module 'plugins.alexa4p3' has no attribute 'alexap3'
2019-08-05  01:25:16 ERROR    lib.plugin          Plugin 'alexa4p3' from section 'alexa4p3' exception: 'PluginWrapper' object has no attribute 'plugin'
> Traceback (most recent call last):
>   File "/usr/local/smarthome/lib/plugin.py", line 145, in __init__
>     plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance, self.meta, self._gtrans)
>   File "/usr/local/smarthome/lib/plugin.py", line 571, in __init__
>     if isinstance(self.get_implementation(), SmartPlugin):
>   File "/usr/local/smarthome/lib/plugin.py", line 715, in get_implementation
>     return self.plugin
> AttributeError: 'PluginWrapper' object has no attribute 'plugin'

[bmx]

Vermutlich hast Du es mit einer korrupten Datenbank zu tun. Database SQLite oder MySQL? Wenn SQLite, dann setze den dump alle 60 Sekunden höher (belastet auch den Stick nicht so sehr) und lösche mal die Datenbank.
Prüfe ob die Abhängigkeiten (PYPI) erfüllt sind oder ob etwas veraltet ist.

Und auch ein USB Stick ist von der Lebensdauer IMHO nicht wirklich besser als eine SD-Karte.

[psilo]

ich sehe gerade, dass dieser dump scheduler normal ist... das ist ein anderer dump als der volle db dump. ich glaube aber auch, dass sich was auf der DB aufhaengt.

[Msinn]

Dieser Dump Scheduler steuert, dass Daten, die in die Datenbank geschrieben werden alle 60 Sek. aus dem Arbeitsspeicher auf die „Platte“ geschrieben werden. Das hat nichts mit einem „Datenbank Dump“ zum Backup zu tun.

[jonsson]

Habe die DB gelöscht, jetzt sieht es besser aus, der Dump fehler ist jetzt im Schnitt nur mehr 1x/Stunde aufgetreten. Gestern noch bemerkt, dass auch der Speicher 100% voll war, leider funktionieren bei mir im backend die Ressourcengraphen noch nicht. Habe jetzt 300MB mysql temp files gelöscht, aktuell frei 132MB. Das erweitern der Partition hat nicht funktioniert, da der USB stick als "non-SD" quasi abgelehnt wurde. Darum bin ich aktuell noch mit 3,6GB begrenzt.

Wegen Haltbarkeit und USB vs. SD, danke für den Input. Was wäre denn "die" nachhaltige Variante? USB HDD 2,5" z.B.?

Besten Dank!

[bmx]

Für den Raspi kann ich Dir das nicht sagen, ich habe keinen im Einsatz. In meinem Intel NUC ist eine 120 GB SSD drin. Es ist immer gut, wenn eine Karte / USB Stick / SSD wesentlich mehr Kapazität hat als notwendig (Wear Leveling hat dann viel Platz zur Verfügung)

[Msinn]

leider funktionieren bei mir im backend die Ressourcengraphen noch nicht

Das backend Plugin hat keine Ressourcen Graphen. Meinst die die Kurven aus dem Admin Interface? (Das sind übrigens die gleichen Daten, die Dir smartVISU auch anzeigt). Voraussetzung ist (wie bei der Nutzunug von smartVISU), dass das visu_websocket Plugin geladen ist.

Ich habe im einen NUC eine 40 GB Intel SSD. Im neueren NUC habe ich eine 120GB SSD (sind ja inzwischen günstig). Mit keiner der SSDs hatte ich Probleme.

[jonsson]

Problem dürfte wohl wirklich die volle root partition gewesen sein.
2019-08-08 22_34_10-Shngadmin.png
Da ich lange gesucht habe, so funktioniert das expand auch eines USB sticks mit raspi-config:

> sudo bash
> sed -E 's/mmcblk0p?/sda/' /usr/bin/raspi-config | bash

Ich habe im einen NUC eine 40 GB Intel SSD. Im neueren NUC habe ich eine 120GB SSD (sind ja inzwischen günstig). Mit keiner der SSDs hatte ich Probleme.

Hast du eine Empfehlung für einen günstigen NUC? Bei Am*** für 189€ - wo wäre der Vorteil gegenüber einem RaspberryPi 4 mit einer USB3.0 SSD?

[Msinn]

Ich habe die kleinsten NUCs (mit Atom CPU).

Vorteile für mich waren damals deutlicher (da gabs noch keinen Pi4). Für mich nach wie vor gültig:

• Alles in einem Gehäuse
• Mehr RAM (Aktuell 8 GByte)
• x86 CPU (wg. anderer Software)