OH3 - Conbee II - wie ist so etwas möglich?

[Steinspiel]

Moin,

Mein ConbeeII USB Stick lief bisher zusammen mit OH2.x an einem Raspberry (192.168.178.106)...
Inzwischen ist ein weiterer Raspberry (192.168.178.76) hinzu gekommen auf dem ich nach und nach OH3 konfiguriert habe. Anschließend habe ich den ConbeeII am ersten Pi zurückgesetzt, an den neuen Pi angeschlossen, installiert, ein Firmware Update gemacht (!), alle Sensoren/Leuchten neu hinzugefügt und dann in OH3 eingebunden. Soweit alles bestens...

Ich kann nicht mehr sagen wann es das erste mal passiert ist (vor oder nach der OH3 Einbindung) aber rufe ich die Phoscon-Web App auf

Code: Alles auswählen

http://192.168.178.76:8081

, egal ob unter Win10, Raspbian oder Chrome OS, stimmt die IP zwar in der Adresszeile, aber die App zeigt manchmal die IP des "alten" Raspberry an! Natürlich passt auch dann das eingegebene PWD nicht...
Das passiert nicht bei jedem Aufruf, kommt aber vor.

pohoscon_login.jpg

Nun habe ich zufällig bemerkt das manchmal auch die ConbeeII Sensoren in OH3 OFFLINE waren und festgestellt das in der (funktionierenden) Config dort die alte IP Adresse sowie der HTTP Port eingetragen sind! Manchmal hilft ein drücken des Disable Buttons
und anschließende Neu-Initialisierung, manchmal muss ich im Terminal auch den Dienst neu starten

Code: Alles auswählen

sudo systemctl restart deconz.service

bevor alles wieder ONLINE ist.

oh3_config.jpg

Inzwischen weiß ich das dies unabhängig von einander ist:
wird mir die falsche IP in der Web GUI angezeigt, funktionieren die Sensoren in OH3 trotzdem noch, das scheint aufeinander keinen Einfluss zu haben.
ABER, mein Backup läuft jede Nacht mit "raspiBackup" und "irgendwie" scheint der ConbeeII nach dem Backup nicht mehr richtig zu starten. Ich habe mit der STOPP und START Reihenfolge von "raspiBackup" rumgespielt weiß aber nicht wirklich welche Reihenfolge Sinnvoll ist.

deconz_reihenfolge.JPG

Deshalb meine zwei Fragen,
ConbeeII User: was kann zur Anzeige der alten IP führen, bzw. wie bekomme ich das gelöst das der ConbeeII sich erinnert?
ConbeeII + raspiBackup User: wie wäre die richtige STOPP / START Reihenfolge?

Danke fürs lesen, schönen Samstag...

[KellerK1nd]

mmmhhh... Wieder zram... Ich mag es nicht. Man kann vieles vermuten, was ich mir vorstellen könnte:

Auf deinem physischen Speicher ist noch die alte Version von deCONZ. Ich weiß nicht genau wie zram arbeitet, wenn du den Dienst einfach beendest und er nicht fertig schreiben kann, bricht er ab und beim nächsten Start werden wieder die "alten" Daten in zram geladen.

Auch nicht zu vernachlässigen ist der Cache von deinem Browser. Auch in dem können noch alte Daten vorhanden sein, im Zweifel einfach mal mit einem Inkognito-Tab probieren.

Was ich an zram auch nicht mag, bei Servern nimmt man ECC-RAM, gerade essentiell für ZFS. Zram verstehe ich ja so ähnlich, nur nicht so komplex. Der Raspberry Pi hat keinen ECC-RAM, wenn du jetzt einen korrupten Adressbereich im RAM hast und zram die Daten aus dem RAM auf deinen Speicher schreibt, wird der korrupte Teil mit gespeichert.

ConbeeII + raspiBackup User: wie wäre die richtige STOPP / START Reihenfolge?

Ich würde openhab immer vor deCONZ stoppen und danach wieder starten, erst wenn deCONZ vollständig initialisiert ist, macht es Sinn openhab zu starten. Andersherum beim Stopppen. Stoppe erst openHAB um alle Daten noch von deCONZ schreiben können.

[udo1toni]

Nein, ZRAM hat nichts mit ZFS zu tun. Und die Sache mit dem ECC ist an dieser Stelle auch überbewertet...
Um das mal etwas runterzubrechen: ZFS arbeitet excessiv im RAM. Gleichzeitig ist ZFS für kritische Umgebungen zertifiziert. RAM-Fehler könnten also potenziell verheerende Folgen haben. Deshalb darf ZFS offiziell nur auf "professioneller" Hardware ausgeführt werden. In der Realität prüft ZFS alle Daten sowohl im RAM als auch auf den angebundenen Datenträger zigfach, ECC schützt auch nur vor 1-Bit und 2-Bit Fehlern. Ich habe hier einen Raspberry 4 mit zwei SSDs liegen, die gemeinsam ein RaidZ1 bereitstellen, also ein Mirror. Funktioniert super.

ZRAM hingegen ist im Grunde genommen nicht mehr als eine RAM-Disk, nur um eine Funktion erweitert, die die Daten auf einen Datenträger speichert, wenn ZRAM abgeschaltet wird.

[Steinspiel]

Auf deinem physischen Speicher ist noch die alte Version von deCONZ.

Naja, in die Richtung dachte ich auch schon, nur wie soll man die gelöscht bekommen? Formatieren und neu bespielen geht ja wohl nicht...

Ich weiß nicht genau wie zram arbeitet, wenn du den Dienst einfach beendest und er nicht fertig schreiben kann,

Das könnte mein zweites Problem mit dem nicht wieder richtig startenden deconz Dienst erklären...

Auch nicht zu vernachlässigen ist der Cache von deinem Browser.

das habe ich als erstes gemacht: Cache + History von Chrome gelöscht, dann Firefox und Edge probiert... Dann kamen die anderen Rechner ran: Apple, ChromeBook, Raspbian. Immer mit dem gleichen Ergebniss.

Was ich an zram auch nicht mag, bei Servern nimmt man ECC-RAM, gerade essentiell für ZFS.

Eigentlich weiß ich nicht viel von zram, nahm bisher an es hätte ne Wirkung wie RAM Disks die einem "früher" öfter untergelaufen sind.
Ich werde es ausschalten, was soll passieren?!

Stoppe erst openHAB um alle Daten noch von deCONZ schreiben können.

Ich habe es jetzt mal so eingestellt und werde dann berichten.

Ach ja, das hatte ich vergessen zu schreiben: egal wie ich die Reihenfolge konfiguriere, führe ich das Backup "von Hand" aus funktioniert danach alles wie gewohnt. Wird das Backup automatisch (vom Script aus" gestartet, gibt es diese Probleme. Soweit ich weiß startet der Handaufruf (was für ein Wort!) aber auch nur das Script...
Mysteriös...

Danke für Deine Hinweise.

[Steinspiel]

Moin,

[...]
Auch nicht zu vernachlässigen ist der Cache von deinem Browser.

Also, es war weder ZRAM, noch Cache, noch raspiBackup...
Und ich weiß auch nicht wer Schuld hatte...

Der "alte" Pi lief ja noch mit openHAB2.5x und in diesem war das "Dresden Elektronik deCONZ Binding" noch aktiv, genau wie auf dem "neuen" Pi das Binding unter openHAB3x aktiv ist...
Zwei Raspberry`s mit 2 x openHAB + deCONZ und nur einen Conbee II Stick im gleichen NW, scheint Problembehaftet...

Nach dem das Binding in openHAB2.5x entfernt war, waren ALLE oben beschreibenen Probleme gelöst!

Danke,

[udo1toni]

Ja, das darf nicht. Der Conbee Stick hat nur einen "Kanal". (Ich vergleiche mal mit meinem knx Tunnel Interface, dort gibt es fünf Kanäle bzw. Tunnel, die parallel betrieben werden können...