[wiregate] Linknx: Persist auf /tmp/linknx/persist

[lobo]

Hallo,

heute hat eines meiner Kinder ein Glas umgeschmissen, was sich dann in die darunter befindliche Steckdosenleiste und den Drehdimmer mit Stecker ergoss. Bitte fragt nicht, warum da eine Steckdosenleiste und ein Drehdimmer ist ... das hat schon so seinen Sinn im Altbau

Ich weiss jetzt auch, dass nicht nur der Eli die Prüfung richtig gemacht hat, sondern, dass der FI tatsächlich fliegt ... und damit ging leider auch mein Wiregate vom Netz (hängt halt noch im Arbeitszimmer an einem "Wimmelswitch" - und nicht in der schönen Netzwerkverteilung im Keller - einfach weil's die bei mir im Altbau auch nicht gibt )

Mein Problem:
Nach dem Neustart des Wiregate will Linknx nicht mehr starten. Im Log steht:

2012-08-19 21:30:21,943 DEBUG > main  - Logging configured
2012-08-19 21:30:21,943  INFO > XmlInetServer  - Starting on port 1028
2012-08-19 21:30:21,950 ERROR > main  - Error in config: FilePersistentStorage: error opening path: '/tmp/linknx/persist/'

OK - das Verzeichnis gibt es auch nicht ...

... nach manuellem Erstellen des Verzeichnisses will auch Linknx wieder, aber:

1. warum ist das Verzeichnis weg gewesen (wird das standardmäßig bei Neustart gelöscht)?
2. Warum ist der Pfad beim Wiregate überhaupt auf /tmp/? Ich hatte den Pfad bisher eher so auf /etc/linknx/persist ...
3. Sollte ich den Pfad ändern, damit mir sowas nicht mehr passiert?

Wäre schön, wenn sich da jemand zu äußern könnte ... bisher habe ich wenig an den Konfigs rumgespielt, weil das schon gut gemacht ist.

Viele Grüße,

Stefan

p.s.: wie stelle ich bei Linknx denn ein, dass die Logfiles größer (bzw mehrere als 3) werden? Weil beim Level "debug" macht er alle 3 Logfiles voll, allein mit dem Nachholen der Persistances.

[Bodo]

Hoi Stefan

Ja persist hat auf /tmp nix zu suchen.
Ist bei mir auch auf /etc/linknx/persist
Da würde ich die Zeile im linknx.xml

[B]    <services>[/B]
        <persistence type="file" path="/etc/linknx/persist/" />
    </services>

dementsprechend ändern und dann linknx neu starten.
Das mit den Logs bessert sich dann auch nach dem zweiten mal...

[lobo]

Danke - schon 'mal eine Bestätigung. Ich hatte es so gelassen, weil die im Wiregate vorhandene XML da hin gezeigt hatte.

Das mit den Logs bessert sich dann auch nach dem zweiten mal...

Wie meinen? Das habe ich leider nicht verstanden ... klar schreibt er nicht mehr so viel in die Logs, wenn die Stati nicht mehr einzeln abgefragt werden müssen, aber trotzdem ist das Volumen der Logs mit 3x 100 kB offensichtlich zu klein. Daher die Frage, ob man das erhöhen kann.

Viele Grüße,

Stefan

[JuMi2006]

Vielleicht spuckt das wiki von linknx was dazu aus: https://sourceforge.net/apps/mediawi...itle=Main_Page

[Bodo]

Hoi

Ja genau:

<logging output="/var/log/linknx.log" format="%d{%Y%m%d %H:%M:%S,%l} %5p %c %x: %m%n" level="INFO"/> The allowed parameters are:

• output: the log file to write. Default=stdout
• format: the logging format value can be "simple", "basic" or a pattern like in the example above.
• level: the minimum level of logging. The valid values are "DEBUG", "INFO", "NOTICE", "WARN" and "ERROR". Default=INFO
• maxfilesize: maximum size of a log file (in kb). When the size is reached, the logs are rotated
• maxfileindex: maximum index of log files kept. Default=10

[lobo]

Das kommt davon, wenn man einfach eine vorgegebene Konfiguration nimmt - bei meinen bisherigen XMLs hatte ich diese Option nicht aktiviert - und daher hatte ich nicht gesehen, dass die auch in der Konfiguration eingestellt wird.

Ich dachte immer, das wäre so ein Makki'scher Zaubertrick

Danke,

Stefan

[makki]

Ist es auch
linknx ist installiert aber nicht konfiguriert/eingerichtet/voll einsatzbereit.. Um zu vermeiden das es wegen irgendeinem ungetesteten Feature bei hunderten die Platte/CF voll-lullt o.ä. liegts in der Ramdisk, da kann nix passieren..

In "Echt" sollte das natürlich ausserhalb /tmp (Ramdisk) aber dann muss man eben auch schauen ob das das Flash totschreibt usw.. ungetestet..

Makki

[johnnychicago]

In "Echt" sollte das natürlich ausserhalb /tmp (Ramdisk) aber dann muss man eben auch schauen ob das das Flash totschreibt usw.. ungetestet..

Ah, ich teste das gerade. Je nach Aktivität auf der GA läuft da einiges, der Stromzähler z.B. wird alle paar Sekunden upgedated.

Interpretiere ich da jetzt richtig, dass ich das persist da herausnehmen sollte?

[Bodo]

Hoi

Also Daten in den Persist zu nehmen ist ja nur sinnvoll, wenn sie sich nicht oft ändern...
Stati der Jalus auf / zu,
Szene Beschattung an / aus,
Anwesend ja / nein
usw.

[lobo]

Echt? Bei mir ist der Standard, dass alles auf "Persist" steht. Einige Sachen sind da echt blöd - wie z.B. die GAs für das Aktivieren von Szenen (ich mache z.B. auch Umsetzung von 1bit auf 8bit damit), aber wie mache ich das jetzt in Richtig mit diesen Dingen? Wenn ich "Persist" weglasse, entspricht das ja einem "Request" - und das macht bei den meisten GAs noch viel, viel weniger Sinn ...

Was ist mit solchen GAs, die nicht abgefragt werden (z.B. die Szenen-GAs)? Gut - die könnte ich mit einem Standard-Wert belegen.

Was ist mit Sicherheits- bzw. Wetter-GAs? - die würde man abfragen (Request)

Aber was ist mit Datum und Uhrzeit?

Wie handhabt Ihr das mit den unterschiedlichen GAs in Linknx, um einerseits beim Start den Traffic zu reduzieren - und andererseits die Belastung auf dem Speicher klein zu halten?

Bisher hatte ich mir darüber keine Gedanken gemacht ... einfach halt alles Persist - passt schon

Viele Grüße,

Stefan

[makki]

Das ablegen auf dem FS ausserhalb /tmp sollte nach einem kurzen Blick in den Source - kein Problem sein, zumindest aufm WG (woanders sollte man halt dann wissen was man tut, so ein Flash ist schnell totgeschrieben, ich erwarte schon den Vorwurf von FUD.. ist aber halt so, das das Leben kein Ponyhof ist..)

Jetzt aber grundsätzlich zum persistenten ablegen von Werten im remanenten speichern, bitte "Systemübergreifend", egal ob linknx, WG-Plugin, HS, ...:
NUR sofern lokal gespeichert/bekannt sinnvoll, das ist in den meisten Fällen nicht so!
Den Schaltstatus eines Aktors oder die Uhrzeit brauche ich nicht speichern, denn sie stimmt nicht mehr, wenn sie ausm lokalen Speicher ausgelesen werden! die muss ich mir per Lesetelegramm oder aus der RTC/NTP holen. Da gibts nix zu speichern.. (hoffentlich verständlich..)

Makki

[Bodo]

Hoi

Sag' ich doch...

[lobo]

oder die Uhrzeit brauche ich nicht speichern, denn sie stimmt nicht mehr, wenn sie ausm lokalen Speicher ausgelesen werden! die muss ich mir per Lesetelegramm oder aus der RTC/NTP holen. Da gibts nix zu speichern.. (hoffentlich verständlich..)

Nö - leider nicht Ich hatte das regelmäßige Senden der Uhrzeit aus Linknx heraus mal 'ne Zeit lang als Überwachungsfunktion genutzt, um zu überprüfen, ob Linknx noch läuft. Jetzt gibt es beim Initialisieren von GAs nur 3 Möglichkeiten:

1. Request: geht nicht - es sendet ja sonst keiner auf der Adresse.
2. Festen Wert vorgeben: Überschreibe ich damit die Systemzeit? Wenn ja, dann wäre ...
3. Persist - ist in diesem Fall noch die beste Lösung. In der Regel läuft das Kästchen ja 24/7 und die Initialisierung läuft nur dann ab, wenn ich (z.B. bei einer neuen Linknx XML) den neustart manuell anwerfe.

Eine Möglichkeit des Auslesens der Uhrzeit via NTP habe ich für die Initialisierung nicht gefunden. Ich habe jetzt nicht in den Cron geschaut, aber nach 5 min hat sich das Problem wahrscheinlich eh' erledigt ... ich wollte nur vermeiden, dass verschiedene Dienste, die auf die Uhrzeit angewiesen sind (z.B. Cron oder andere davon angetriggerte Dienste) aus'm Takt kommen.

Also da kenne ich die beste Lösung noch nicht ...

Viele Grüße und vielen Dank bisher,

Stefan

[Bodo]

Hoi

Ich versteh' das irgendwie nicht.
Ich dachte immer wenn links neu startet, dann entscheidet es, wo es nachschaut welcher Wert wie initialisiert werden soll.
Persist heisst, aus dem Speicher den dort als letztes vor dem Neustart gespeicherten Wert lesen.
Werte die sich sehr oft ändern müssen natürlich auch sehr oft neu in den Persist gespeichert werden.

Die Uhrzeit ist da (im Persist) natürlich bereits völlig veraltet und sollte lieber vom Bus aktuell gelesen werden. Oder das WG holt sich die Zeit vom NTP.

Bei einer geschlossenen Jalusie macht es hingegen Sinn, den Wert "Zu" aus dem Persist zu lesen, damit die Dinger nicht wie wild losfahren. Und der Status wird auch nur 4 bis 8 mal am Tag in den Persist neu reingeschrieben.
Viel öfter ändert sich pro Tag mein Jalustatus auch mit Beschattung nicht.

[lobo]

Die Uhrzeit ist da (im Persist) natürlich bereits völlig veraltet und sollte lieber vom Bus aktuell gelesen werden. Oder das WG holt sich die Zeit vom NTP.

Ich kann leider den Quellcode nicht lesen , aber es gibt IMHO keine Möglichkeit, Linknx anzuweisen, die Systemuhr oder die Uhrzeit vom NTP zu lesen...

- Entweder ich gebe eine Uhrzeit vor, die wird dann völlig falsch ist (z.B. 30.09.2000). Solange bis die Systemuhr aktualisiert wird, werden alle Logs dann mit einem solchen Datum geschrieben
- Oder ich lasse die Zeit vom Bus lesen (in der Hoffnung, dass nicht Stromausfall war - und meine Suntracer auch noch kein Signal hat)
- Oder ich nehme "Persist" - und liege maximal ein paar Minuten falsch (bei einem linknx restart sogar nur ein paar Sekunden).

Viele Grüße,

Stefan