Antworten zu Rudolfs "Ende von FHEM@FritzBOX"

Begonnen von Ich79, 03 Juli 2014, 17:24:02

Vorheriges Thema - Nächstes Thema

rudolfkoenig

@PeterPawn: vermutlich bin ich der richtige Ansprechpartner, weil ich die FritzBox-FHEM Pakete fuer fhem.de erstellt habe.

Zum Verstaendnis:
- http://fhem.de/fhem-5.5-fb7390.image fuer die FB7390/FB7490 von fhem.de packt zunaechst ca 60MB nach /var/InternerSpeicher/fhem
- das Verzeichnis kann man auch Umbenennen, die default-Konfiguration verwendet relative Pfade.
- FHEM schreibt seine logs hier in das log Unterverzeichnis, und das kann pro Jahr je nach Installation mehrere 10MB sein, ich wuerde deswegen von der Installation ins root FS abraten.
- zum Starten muss ein in diesem Verzeichnis befindliche Shell-Skript (startfhem oder startfhemAsRoot) als root aufgerufen werden. Dieser Aufruf wurde bisher aus /var/flash/debug erledigt.

Waere es moeglich, deine Modifikation in das fhem.image install-Skript zu integrieren?
Wie einfach kann AVM die von dir gefunden Moeglichkeit entfernen?

Ich habe gelesen, dass 7362SL Besitzer FHEM gestartet haben. Ich habe FHEM selbst auf einem 7360SL getestet.

Frank

Zitat von: PeterPawn am 24 September 2014, 21:46:45
Ich habe zwar von dem Image von Frank für die 7390/7490 gelesen, aber er wird sicherlich nicht jeden einzelnen per PN mit einem neuen Image versorgen wollen...

Bisher habe ich noch jede Anfrage schnellstmöglich beantwortet (und es waren schon einige), aber wie sich hier teilweise die Leute bei mir melden ist schon oft eine Frechheit. Die meisten Anfragen sind zwar nett und höflich und es gab sogar schon zwei kleine Spenden (Danke an BonnBonn und Matthias!), aber es gibt immer wieder User, denen es nicht schnell genug geht. Leider habe ich nicht immer die Möglichkeit, innhalb von Minuten zu antworten, aber das scheinen hier einige nicht zu verstehen.
Das ganze ist schliesslich in meiner Freizeit (freiwillig) entwickelt worden und da kann man auch vielleicht auch mal einen Tag warten bis ich ich per PM melde...

(Sorry, aber das musste mal raus!)

Frank.

hexenmeister

Zitat von: Frank am 25 September 2014, 08:07:07
aber das scheinen hier einige nicht zu verstehen.
Hm... kenne ich irgendwie. Es sind immer ganz wenige, aber die schaffen es, die Stimmung zu verderben. Lass Dich  nicht stressen! ;)

Grüße,

Alexander

Xguide

@ Frank und alle Entwickler von FHEM: Ihr macht einen super Job und habt durch eure Innovation ein echt tolles System geschaffen.
Das einem nun Steine durch HW-Lieferanten in den Weg gelegt werden ist sicherlich ärgerlich, aber meiner Meinung nach normal und auch egal. Es findet sich bestimmt eine Lösung für das Problem und das darf auch dauern. Ich sehe da kein so großes Problem, da ich meine FritzBox nur alle paar Monate neustarten muss.
Was ich nur sagen wollte, lass dich nicht von irgendwelchen Dränglern nerven und sei dir gewiss, der Großteil der FHEM-Gemeinde hat Ausdauer und Verständnis für die etwaigen Wartezeiten. Ignoriere einfach die schwarzen Schafe  :)
FHEM bleibt für mich eins der flexibelsten Systeme!

Weiter so....

FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

Fritzi

#214
Zitat von: PeterPawn am 24 September 2014, 21:46:45Dabei gehe ich davon aus, daß nach wie vor bei den Besitzern einer 7490 noch das Interesse an der Nutzung des FHEM auch direkt auf der Box besteht und nicht alle sofort auf einen RasPi oder BananaPi ausweichen wollen.
Gott sei Dank. Endlich wieder ein guter Beitrag zum eigentlichen Thema. Ich hatte schon schon nicht mehr zu hoffen gewagt, nach all dem FB-Shitstorm und der RasPi-Promotion.
FHEM 5.6 auf RaspberryPi2 mit Busware CUL culfw V1.61
CUL_HM     : HM-CC-RT-DN,HM-LC-SW1-FM,HM-LC-Sw1PBU-FM,HM-SEC-SC,HM-Sen-MDIR-O-2,HM-TC-IT-WM-W-EU
FBDECT      : Dect200
HUEDevice  : LCT001,LCT003

PeterPawn

#215
Zitat von: rudolfkoenig am 24 September 2014, 23:24:03
Waere es moeglich, deine Modifikation in das fhem.image install-Skript zu integrieren?
Wie einfach kann AVM die von dir gefunden Moeglichkeit entfernen?
Sorry für die späte Antwort, die E-Mail-Benachrichtigung ging wohl irgendwo unter (und dann mußte ich auch noch Kopfrechnen, das überfordert mich).

Da die Modifikationen direkt auf einer 7490 ausgeführt werden, indem das root-Dateisystem ausgepackt, modifiziert und wieder eingepackt wird, kann AVM - meiner Meinung nach - nur mit einer Sperrung des Telnet-Zugangs an sich etwas dagegen tun. Das werden sie sich sicherlich nicht trauen, dann gibt es aber auch noch genug andere Wege. Die einzige realistische Möglichkeit wäre m.E. ein verifizierender Urlader (EVA), der auch keinen Start eines unsignierten Systems per FTP-Zugriff mehr zuläßt. Da sehe ich aber eher keine Gefahr bei den derzeit verfügbaren Modellen ... künftige Geräte werden wohl noch weiter abgeriegelt sein.

Eine Integration in das FHEM-Image setzt meiner Ansicht nach eine Abarbeitung ohne Interaktion mit dem Benutzer voraus (wenn das über den Firmware-Update-Prozess des AVM-GUI läuft), das habe ich ja gerade erst ins komplette Gegenteil geändert. Eine Integration halte ich also nicht für sinnvoll, aber die Reihenfolge dürfte keine Rolle spielen, solange noch genug freier Speicher zum Entpacken und Packen nach der FHEM-Installation zur Verfügung steht.

Im Moment funktioniert das Prinzip leider auch nur für die 7490/7362SL, da in den anderen Modellen nur wenig Platz im Flash-Speicher vorhanden ist, daher eine andere Kompressionsmethode für das SquashFS-Image mit dem Root-Dateisystem verwendet wird (LZMA) und das Tool zum Erzeugen eines Images (mksquashfs) arbeitet in der derzeit vorliegenden Form direkt auf einer 7390 nicht richtig (vermutlich wegen der anderen Reihenfolge der Datenspeicherung - little vs. big endian). Da gerade in einer 7390 es auch im originalen AVM-Image wirklich eng zugeht, braucht man auf der Box auch eine hohe Kompression beim Packen (nur zlib-compress2 reicht nicht aus), ansonsten geht einem der Platz aus.

Zum FHEM:
Ich wußte nicht, daß der Platzbedarf derart groß ist, damit entfällt natürlich jede Überlegung zur Integration irgendwelcher Binaries in das root-Dateisystems.

Bleibt also nur noch der Start des FHEM an einer geeigneten Stelle (wenn das betreffende Start-Skript die Existenz der Software an sich festgestellt hat).

Da meines Wissens aber für die Unterstützung der 7490 mit Firmware ab 06.20 wegen der geänderten OpenSSL-Library von AVM (1.0.1i inzwischen, wenn ich mich richtig erinnere) ohnehin eine abgewandelte Version der Perl-Library benötigt würde (den hier irgendwo beschriebenen Workaround mit der Verwendung einer alten OpenSSL-Implementierung kann ja niemand mit gutem Gewissen empfehlen), bietet es sich meines Erachtens eher an, den FHEM gleich an der passenden Stelle zu starten und dabei nicht unbedingt zwangsläufig auf die debug.cfg/rc.user zurückzugreifen ... wenn man ohnehin schon eine "gesonderte" Version ab 06.20 wg. der SSL-Unterstützung bauen muß.

Unter Beachtung der Rahmenbedingungen (Binaries müssen verfügbar sein - d.h. Flash-Speicher muß gemountet sein - ist aber die einzige Voraussetzung, die mir ins Auge springt) ließe sich vielleicht ein anderer passender Punkt für den Start finden ? Bei einer Box ohne internen NAND-Flash wäre das sicherlich nach dem Mounten eines USB-Speichers, das spielt aber bei der 7490 keine Rolle (der Flash wird wesentlich früher gemountet als jeder USB-Stick).

Oder ist die debug.cfg - in der etwas abgewandelten Form, daß sie nicht per "source" in den Init-Prozess eingebunden wird, sondern an dessen Ende (quasi als letzte Aktion) gleich asynchron gestartet wird - schon der beste denkbare Ort für den Start des FHEM ?

Muß eigentlich beim Stoppen/Restarten der Box irgendetwas zusätzlich abgearbeitet werden ? Logs archivieren o.ä. ?

Benutzt der FHEM selbst irgendwelche bind-Mounts, um Änderungen des originalen Root-Dateisystems auszuführen zur Laufzeit ?

EDIT:
Ich habe mir jetzt mal die Installation des FHEM aus Deinem Link angesehen und das Prinzip damit verstanden ... mit einer Ausnahme:
Wo kommt denn bitte der "boxusr80" her ? Den gibt es zumindest in aktueller AVM-Firmware (ohne AVM-FHEM) nicht, damit schlägt das chown fehl. Solange das nicht stört (weil beim untar der richtige User gesetzt wird), ist es auch egal ... aber es sieht halt merkwürdig aus. Stammt das aus der AVM-Version mit chroot für den FHEM ?

Das ist ja im Moment alles auf die Installation über das AVM-GUI ausgelegt. Da die "Reaktivierung" der rc.user meinerseits wahrscheinlich nicht "batch-fähig" umgesetzt wird (und damit den Telnet-Zugang und ein Shell-Login darüber zwingend voraussetzt), könnte man trotzdem hingehen und für die 06.20 aus dem Zweizüger (FHEM + modfs) einen einzelnen Aufruf machen. Dazu müßte man (neben einem passenden FHEM-Paket für 06.20 - das SSL-Problem trifft die 7390 ja genauso) nur ein zusätzliches Skript in 'modfs' mit hineinpacken, das bei der Bestätigung des Nutzers, daß er den FHEM installieren will, dieses Paket (Internet vorausgesetzt) lädt, an die richtige Stelle auspackt und die Konvertierung der "alten" Konfiguration vornimmt, wenn diese vorhanden ist. Im Endeffekt ist das das install-Skript aus dem 5.5-Paket mit einem Download des Pakets davor. Das einzige, was in meinen Augen dann fehlt, ist ein passendes FHEM-Paket, das auch mit 06.20 und SSL funktioniert (daß es im Moment nicht der Fall sein soll, habe ich auch nur aus dritter Hand, es gibt dazu aber auch hier einen Thread zu den Problemen mit der SSLeay-Lib von Perl im Zusammenspiel mit der neuen 1.0.1-OpenSSL-Lib von AVM).

Ok, jetzt habe ich den Teil mit dem fhem-User auch verstanden ... allerdings erst im Rahmen des Startscripts und den Schritt im install-Skript verstehe ich immer noch nicht, denn ooB muß er fehlschlagen und das fällt nur nicht auf. Wenn die Dateien mit UID/GID 501/20 ausgepackt wurden, funktioniert der Start des FHEM nur dank der Tatsache, daß auch bei "FHEM als User fhem" erst einmal root als Benutzer für den Start von startfhem verwendet wird (und der ignoriert eben die ACL-Flags einfach). Wenn man dann noch startfhemAsRoot verwendet (da werden die Dateien ja gar nicht mehr angefaßt), bleibt die FHEM-Installation wohl permanent bei UID=501 und GID=20 stehen ... wobei der Sinn und Zweck des Wechsels auf "fhem" in fhem.pl (auf einer FRITZ!Box, ansonsten natürlich nicht) in meinen Augen ohnehin fraglich ist. Solange das FRITZ!OS selbst sich um die Rechte nicht schert (es sind praktisch alle Files im root-Dateisystem 777 und nur das r/o-Dateisystem verhindert das Schreiben für 'jeden') und der fhem-User auch immer mit GID=root läuft, bringt das "Droppen" der Rechte eigentlich nichts (außer potentiellen Problemen). Wenn dann auch noch AVM den chroot-Modus nicht mehr anbietet, kann man auch gleich generell mit root-Rechten herangehen und hat eine potentielle Fehlerquelle (immer nur meine Meinung) auf der FRITZ!Box damit "abgeschafft". Eine zusätzliche Sicherheit aus dem Umschalten auf den fhem-User, wenn er denn vorhanden ist, kann ich persönlich jedenfalls nicht erkennen, die GID in 'startfhem' wird ja auf '0' gesetzt.

Die benötigten Module "cdc_acm" und "ftdi_sio" für die Ansteuerung der CULs hat AVM offenbar trotz der Aufkündigung der FHEM-Unterstützung noch mit in das originale Firmware-Image gepackt, hier wäre aber wieder eine Sollbruchstelle für künftige Versionen. Wenn AVM die Module nicht mehr selbst bereitstellt, müßte man die ja nachliefern (passend zum Kernel und da wäre dann ohnehin Schluß mit "IMAGE_7390" == "IMAGE_7490").

Einige im FHEM referenzierte Kommandos hat AVM auch "abgeschafft" (ich habe 'socat' in irgendeinem Skript gesehen, das ist genauso wie 'nc' nicht mehr dabei in der AVM-Firmware), da stellt sich dann vielleicht doch wieder die Frage der Integration solcher "missing commands" in das root-Dateisystem, da das ja nicht nur für den FHEM selbst interessant wäre und das Ablegen von 'socat' unterhalb des FHEM-Verzeichnisses sicherlich nicht sonderlich sinnvoll ist.

sTaN

Hallo liebe Community,

da auch ich mein FHEM seit Jahren auf einer FritzBox 7390 betreibe, mich aus Zeitgründen aber relativ selten im Forum bewege (da derzeit einfach alles läuft), blieb mir kurz der Atem beim Lesen dieses Threads stehen.

Nötige Schritte seitens AVM bzgl. Sicherheit einleiten ist vollkommen in Ordnung. Was aus meiner Sicht gar nicht gehen würde ist komplett gegen solche Communitys und Möglichkeiten (auch Freetz) zu schießen ohne jegliche Kompromisse. Das scheint zunächst und wird hoffentlich auch nie passieren! Wenn es sich lediglich um keinen möglichen Autostart handeln würde, ok. Aber sollte FHEM generell auf einer FritzBox nicht mehr möglich sein und die Entwicklung eingestellt werden, würde ich mich wahrscheinlich von AVM trennen. Ich betreibe ebenfalls Freetz auf der Box und das soll auch so weiter gehen. Allein für SSH und Wake On LAN über den Callmonitor kann und möchte ich nicht mehr missen.
Mir fliegen allerdings auch noch weitere Fragen und Ängste durch den Kopf. Aktivieren des Gäste WLAN's läuft nur mit FHEM ausgeführt als root. Ist dies damit auch hinfällig?
Ich hoffe sehr das die Entwicklung von FHEM für die FritzBox weitergeht, denn ich möchte einfach nicht noch mehr Geräte administrieren und betreiben, um die aktuellen Möglichkeiten zu nutzen. Meiner Meinung gehört FHEM auf die FritzBox, allein um deren Möglichkeiten zu verdeutlichen, sowie auch Freetz. AVM steht und fällt mit FHEM und Freetz. Auch wenn hier nicht jeder der Meinung sein wird.

In diesem Sinne einen schönen Feiertag!


Sent from my iPad using Tapatalk
Raspberry Pi 3
2 x CUL CC1101-USB-Lite 868MHz
FS20 Komponenten, Philips HUE, Alexa-Fhem, MAX! Geräte, homebridge, harmony, Unifi, FirtzBox, MQTT, Aurora, Denon, Sonos, TabletUI, CALENDAR, EGPM2LAN, Pushover

Damu

ZitatAVM steht und fällt mit FHEM und Freetz

Das sehe ich auch so.

PeterPawn

#218
Zitat von: Noname am 04 Oktober 2014, 10:13:54
gibt es eine Möglichkeit die Befehle in der fhem.cg einzutragen?
Mal als ganz blöde Frage ... warum läßt Du das nicht "außen herum" im Skript zum Aufruf des FHEM machen ?

EDIT: Sorry, machst Du ja, hatte ich glatt überlesen ...

rudolfkoenig

@Noname, PeterPawn: bitte neues Thread oeffnen, wird werden komplett off-topic
@Noname: FHEM verteilt global:SHUTDOWN und global:INITIALIZED Events, daran kann man auch notifies haengen.

Noname

#220
@rudolfkoenig, PeterPawn

http://forum.fhem.de/index.php/topic,27615.0.html

neues Thema zur Modifikation

tuniberger

Da ich gerade dran gehe das Komplette FHEM neu aufzusetzen ( bisher auf Fritz 7490 ) Nach Update 6.20 jetzt manueller Start per Telnet mal ein grundsätzliche Frage.

1. Ich gehe davon aus dass Fritzboxcall etc ( Alarmierung per Tel ) oder Anrufmonitor etc nicht funktionieren wenn ich den FHEM auf einen ( vorhandenen) Raspbery auslagere.

2. Die vorhandenen DECT 200 scheine ich aber weiterverwenden zu können wenn ich das richtig herausgelesen habe.

3. Lösung : Mod der AVM Firmware... ( von Frank ? ) , nur was passiert wenn die von AVM eingebauten automatischen Updates aktiv sind ?

Könnte mir folgender Ansatz helfen : Normale AVM Firmware + FHEM + Telnet Aktiv ,  2. FHEM auf Raspbery der den Fritz-FHEM checkt und bei Bedarf ( Watchdog ) per Telnet startet ?
( Rasp läuft sowieso für einen Squeezeplug dauernd neben der FB7490  mit..... )




marvin78

Anrufmonitor funktioniert auch auf einem externen Gerät (siehe Wiki und commandred). Das einzige, was nicht direkt funktioniert, ist das Adressbuch. Das kannst du jedoch einfach von der Box exportieren und auf den Raspi packen. Wie genau das funktioniert, steht auch in der commandref zum FB_CALLMONITOR.

Mopedpaul

#223
Hallo,
habe schon seit längerem von der Fritzbox auf einen Intel NUC (der kleinste lüfterlose reicht locker, ca 200 € mit Ram und SSD) gewechselt und bin damit sehr zu frieden. Denn ich gebe alle Fritzbox Usern zu bedenken - wehe wenn die Fritzbox kein DSL Sync Signal mehr bekommt. Ist mir persönlich so passiert. Keine DSL Verbindung mehr. Fritzbox neu gestartet - weiterhin keine DSL Sync  (wie sich später heraus stellte ein  Problem beim Provider) Aber dann - Da die Fritzbox kein DSL Signal bekommt, ist auch der Zeitserver nicht erreichbar und die Fritze setzt sich auf den 1.1.1980 12:00 zurück. Was das bedeutet kann sich jeder ausrechnen.
Alle Logs werden neu angelegt mit 1980, da die Uhrzeit nicht stimmt, werden alle davon abhängigen Schaltvorgänge zur falschen Zeit ausgelöst. Nein Danke ,so was möchte ich nicht mehr erleben. Hat 2 Tage gedauert, bis das DSL Sync wieder da war.

Auf der Fritzbox hatte ich dann nur noch ein einfaches FHEM laufen und über FHEM2FHEM mit dem NUC verbunden, um die Fritze speziefischen Funktionen zu nutzen. Aber ich hoffe, da wird es auch bald Lösungen für geben. Auch den Raspberry hatte ich zwischenzeitlich genutzt. Wenn aber der Umfang von FHEM sehr zunimmt, werden die Response Zeiten beim FHEM Web Interface sehr nervig. Beim NUC merkt mann so gut wei keine Verzögerung - kann ich für stark genutzte FHEM Systeme (FS20,Heizungssteuerung,Solaranlage,HMLan,Max,Net/io) nur empfehlen.
Auch die direkte Anbindung einer SSD Platte und ein vollwertiges Ubuntu Linux gibt einem schon viele Möglichkeiten (Iscsi Anbindung zum NAS, Backup auf das NAS).

Gruß Mopedpaulchen
System:FHEM 5.7 auf Intel NUC  mit 1xCUL(433) ,1xCUNO V2 (868)mit Onewire,2xNetIO mit Onewire , HMLAN
,Max Cube , Philips Hue, webViewControll, MiLight
Devices:FS20,Onewire (Cuno+NetIO),Intertechno ,Homematic (Keymatic & TC & SD) Max ,Solaranlage 7,3kWP mit Solarlog 200

sTaN

Interessant. Kann ich so gar nicht bestätigen Hatte vor kurzem auch DSL Ausfall bei o2/Alice DSL und das für ca. 8-9h. Logfiles haben aber noch den aktuellen Zeitstempel. Wie oft synced denn die Box mit dem NTP Server?!

Gruss
Raspberry Pi 3
2 x CUL CC1101-USB-Lite 868MHz
FS20 Komponenten, Philips HUE, Alexa-Fhem, MAX! Geräte, homebridge, harmony, Unifi, FirtzBox, MQTT, Aurora, Denon, Sonos, TabletUI, CALENDAR, EGPM2LAN, Pushover