Neues Modul - 74_Unifi - Für den Ubiquiti Networks (UBNT) - Unifi Controller

[Maui]

Es ist zwar keine schöne Dauer Lösung aber als Test könntest du mal versuchen in der /etc/init.d/UniFi in Zeile 69 den openjdk Pfad gegen Oracle zu tauchen.
Wenn das klappt kann man ja gucken warum er nicht in den anderen Zweigen landet.
Gruß

[andies]

Ja, die Stelle kenne ich; die ist berüchtigt. Vorher wird der Pfad ausgerechnet um dann direkt eingegeben zu werden (geniale Programmierung). Ich habe da alles, was möglich ist, probiert: Mit direkter Eingabe, ausrechnen, verschiedene Einträge...

Ohne Erfolg. Siehe Foto.

[Maui]

Aber hattest es auch mal einkommentiert?
Das jre/bin müsste am Ende noch weg

[andies]

Das jre/bin müsste am Ende noch weg

Ja, hatte ich auch schon. Siehe vorigen Post

und auch dafür gesorgt, dass diese berüchtige Environment-Variable gesetzt ist

Code Auswählen Erweitern


echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle


[Maui]

Aber auch im init. Skript? Da wird es überschrieben denke ich

[andies]

im skript wird es komischerweise überschrieben. Ich habe dann mehrere Sachen probiert: Im Skript setzen, im Skript ausblenden und per terminal setzen - keine Änderung.


Gesendet von iPad mit Tapatalk Pro

[Wuehler]

Wie hast du es denn im Script überschrieben?

Vorher wird der Pfad ausgerechnet um dann direkt eingegeben zu werden (geniale Programmierung).

Der Pfad zur JVM wird nicht im Script am Ende überschrieben. In den Schleifen gibt es ein return beim ersten Treffer. Ganz am Ende ist ein Default, falls vorher nichts gefunden wurde.
Wenn du das im Script anpasst, dann zumindest die beiden returns auskommentieren (oder alles was vor der letzten Zeile kommt).
Ich hatte damit damals auch Probleme. Kann mich aber nicht mehr dran erinnern, wie genau ich sie gelöst habe. Das init-Script ist bei mir aber Original von Unifi. Ich habe aber anscheinend alle alten Java deinstalliert und die Oracle-Java-Installation war auch erst nach zwei oder drei Anläufen funktionsfähig mit Unifi. Kommt wohl sehr darauf an, wie dein System sonst so aussieht. War bei mir auch viel googlei.

Viel Erfolg,
Dirk

[andies]

Ja, das hatte ich mir dann auch klar gemacht. Ärgerlich ist, dass die Dokumentationen im Netz alle sehr spärlich sind und man enorm viel Zeit versenkt. Da ich derzeit nur ein unifi habe, will ich jetzt nicht mehr so viel in das Modul investieren; der Zugang geht momentan auch so. Vielleicht probiere ich das später einmal aus.

Und dann würde ich auch im Wiki etwas aufschreiben. An sich ist das ja eine Katastrophe mit diesem controller auf dem RPi. Anscheinend is Java das Problem, aber so sicher war ich mir nicht.

[Gisbert]

An sich ist das ja eine Katastrophe mit diesem controller auf dem RPi.

Ich hatte versuchsweise den Unifi-Controller auf einem RPi3B installiert, ohne ihn jedoch produktiv zu nutzen. Ich hatte dabei 2 Beobachtungen gemacht, bevor ich ihn deinstalliert hatte:

• signifikant höhere Temperatur im RPi3B
• Vollschreiben des Speichers durch Unifi

Jetzt laufen Fhem und Unifi auf einem HP ThinClient T610 zur vollsten Zufriedenheit.

Viele​ Grüße​ Gisbert​

[Maui]

Also ich habe den Controller seit 1 Jahr problemlos auf einem Pi3.
Weder erhöhte Last noch RAM voll

Gruß
Maui

[Gisbert]

Weder erhöhte Last noch RAM voll

Hallo Maui,
kann sein, dass es auch an mir lag, dass es zu einem Problem kam. Es wurde aber nicht der RAM vollgeschrieben, sondern die SD-Karte, so dass letztendlich für Fhem kein Platz übrig blieb.
Viele​ Grüße​ Gisbert​

[Maui]

Moin Gisbert, ist vielleicht auch eine Frage mit welcher Controller Version du getestet hast und wie groß deine SD war. Meine mit 64 GB wird mein UniFi (hoffentlich) nie vollschreiben.

[Maui]

@andies: Versuch doch mal UniFi im docker Container.

[Maui]

Moin Wuehler,

Hast du auch eine Idee, warum nach 9 Tagen und 12 Std. Kein Update mehr kommt bei disconnected devices?

Gruß
Maui

[Wuehler]

Moin,

Hast du ein fhem-Update gemacht? Der Fix ist noch nicht im Repository.