Beiträge von buzz-dee

Hab ich gemacht, die Warnung kommt trotzdem wieder. 🤷🏻‍♂️

Moinsen,

Ich bekomme im Log folgenden Warnung:

[21.6.2021, 14:27:07] [FritzPlatform] WARNING: There is no master router configured! Please check if "master" is enabled in config.
[21.6.2021, 14:27:07] Loading 1 accessories..

Meine config sieht so aus:

"name": "FritzPlatform",
"debug": false,
"devices": [
{
"name": "FB6951",
"host": "192.168.178.1",
"username": "xx",
"password": "xx",
"ssl": true,
"tr064": true,
"igd": false,
"model": "6951",
"master": true,
"connection": "cable",
"options": {
"wifi_2ghz": "switch",
"wifi_5ghz": "switch",
"wifi_guest": "switch",
"wps": "switch",
"led": "switch"
}
},
{
"name": "Repeater",
"host": "192.168.178.2",
"password": "xx",
"ssl": true,
"tr064": true,
"igd": false,
"model": "Repeater 2400",
"master": false,
"connection": "repeater",
"options": {
"led": "switch",
"wifi_5ghz": "switch",
"wifi_2ghz": "switch"
}
}

Das Masterattribut ist also für die FritzBox gesetzt und für den repeater nicht, von daher verstehe ich die Warnung nicht. Kann mir jemand bitte auf die Sprünge helfen?

Zitat von Foxy

Von meinen 6 Hompods (5mal mini und einmal OG) sind 4 auf 14.5 und bei 2 (minis) steht seit mehreren Stunden "laden" und das Rädchen dreht. Es scheint, als ob da nicht mehr wirklich was geht...

Will ja nicht neustarten/zurücksetzen, wenn die minis das Softwareupdate am laden sind... Auf der anderen Seite haben sich die zwei vielleicht aufgehängt?

Jemand dasselbe Problem? Was wird empfohlen?

Das gleiche hatte ich bei einem meiner Minis auch, nach zwei Tagen hab ich die Geduld verloren und ihn zurückgesetzt. Jetzt ist alles wieder normal. Der Mini ist auf 14.5 geupdated und funktioniert tadellos.

Zitat von ices

1. Es geht aber nicht um die HK Firmware. Die kann beim PM nämlich nicht die Leistung übermitteln.
2. Und Neustarten soll auch nichts. Ich will lediglich im HK mitbekommen wenn der Shelly offline ist.

Aber Hauptsache was geschrieben, oder was... ?

Ich stell meine Frage nochmal anders, vielleicht kannst du sie beantworten und man bekommt eine bessere Idee was du vor hast:

WIE geht denn dein Shelly offline? Also was führt denn dazu dass dein Shelly stromlos wird?

Der Shelly ist ja gerade dafür konzipiert dauerhaft eingeschaltet zu sein um dann eben über WLAN Befehle zum an und ausschalten des daran abgeschlossenen Geräts zu empfangenen und umzusetzen?

Zu welchem Zweck willst du ihn vom Netz nehmen? Meine shellys sind immer am Netz damit ich sie schalten kann bei Bedarf!

Schau mal hier: Klick!

Einfach die node Befehle weglassen wenn’s nur npm sein soll.

Eine schnelle Google Suche hat das hier zu Tage gefördert:

Anleitung ML500

Kann es sein dass der Shelly an dem seitlichen orangefarbenen Klemmblock angeschlossen werden muss?

Sieht laut Anleitung jedenfalls so aus.

Zitat von Schaebse

Hi:

Im VNC muss maneinfach das Wort "deCONZ" in dieser Schreibweise eingeben. Dann startet es.

Ich habe zwischenzeitlich einen Tip bekommen und bin nun Live drin. Puuuhh

VBielen Dank an Alle !

Und magst du den geheimnisvollen Tipp auch mit dem Forum teilen, damit Andere die auf der Suche nach Hilfe sind auch etwas davon haben? 🤓

Zitat von sschuste

Sorry fürs OffTopic aber sschuste ich muss deinen Port mal lobend erwähnen

Ich denke zwar dass du mit KZ ein Kinderzimmer meinst, aber die Abkürzung ist schon ziemlich „vorbelastet“ wenn ich das mal sagen darf

Zitat von Marco Schmidt

Und dann den Lanbon neustarten. Bei mir hat tatsächlich geholfen, den aus irgendwelchen Restriktionen zu nehmen und freien Zugang zu allem zu gewähren. Aber trotzdem ist gelegentlich das Symbol gelb. Wie auch immer, die Zeit synchronisiert er nach wie vor nicht. Und das ist doof, wenn man das Ding fürs KZ geplant hat, dort aber keinen Nachtmodus schalten lassen kann.

Hatte das Problem in letzter Zeit auch schon 2 mal. Ich konnte noch keinen Zusammenhang herstellen warum das passiert ist.

Nach meinem Verständnis funktioniert das folgendermaßen:

Alle Clients in meinem Netz nutzen für ihre DNS-Anfragen den Pihole Server, weil sie das per DHCP so beigebracht bekommen haben.

Wenn Pihole eine Anfrage NICHT selbst beantworten kann (z.b. mit seiner Gravity-Liste der geblockten Domains), leitet er die Anfrage an die UPstream DNS Server zur Beantwortung weiter. Da die FRITZ!Box hier auch als Upstream eingetragen ist UND die Fritz.Box-Adressen auflösen kann, kommt von der FRITZ!Box die Antwort an den Client zurück und die Namensauflösung klappt.

Wenn die FRITZ!Box dort nicht drinstehen würde, müssten die OPenDNS Server die Anfrage beantworten und das können sie nicht. Also würde es dann bei mir nicht mehr klappen.

Bei dir funktioniert es weil du unter DNS die local Domain Fritz.Box eingetragen hast und deinen ip Adressbereich. Wenn du meine Einstellungen ausprobierst müsstest du Domain wieder rausnehmen UND den Haken bei „Never forward reverse lookups for private ip Ranges“ ebenfalls entfernen. Nach der Beschreibung die darunter steht verhindert dieses option genau die Art der Namensauflösung über den Upstream Server wie ich sie oben beschrieben habe.

Vielleicht äußert sich ja noch einer der Netzwerkprofis hier zu dem Thema...von meiner Seite ist das auch mehr „educated guess work“ 😎

Bei mir läuft es mit folgender Konfiguration und die fritz.box Adressen klappen auch alle:

• Die Fritzbox bekommt per DHCP vom Internetprovider DNS-Serveradressen bereitgestellt.

• Im Lokalen Netzwerk übernimmt die Fritzbox die Funktion des DHCP-Servers und liefert an alle meine Clients die IP des RaspberryPi als DNS-Server aus .

• PiHole selbst nutzt unter "Settings" -> "DNS" -> "Upstream DNS Servers": "OpenDNS" und unter "Custom 1" die IP der Fritzbox
  

Die Antwort hast du am 3. Dezember von Smooph eigentlich schon mal bekommen.

Ohne PC/Mac wird es schwierig bis unmöglich sein einen Raspi von null aufzusetzen. Zumindest wenn du mit  Geräten arbeitest. Ob es auf Android-Devices geht eine SD Karte mit einem Image zu flashen entzieht sich, mangels Erfahrung, meiner Kenntnis.

Eine Möglichkeit wäre eventuell den einen deiner Beiden Raspis dazu zu benutzen. Wenn du die zu beschreibende SD-Karte in einen USB-Adapter steckst kannst du sie am noch laufenden Raspi anstecken und neu beschreiben.

Ich benutze das Plugin Cmdtrigger.

Mit folgender Konfiguration bekommst du einen Schalter in Deinem zuhause angezeigt. Beim betätigen wird der Befehl der hinter “command” steht auf dem Raspi ausgeführt. Auch einen reboot des Raspberry kann man damit z.B. auslösen

{
      "accessory": "CmdTrigger",
      "name": "HB Neustart",
      "command": "sudo systemctl restart homebridge”,
     "execAfterDelay": false
}

Hast du die Fritzbox über ihre eigene Weboberfläche zurückgesetzt?

Ich würde dir das Recoverytool für deine Fritzbox empfehlen. Das findest du auf dem AVM FTP Server und ist Modellspezifisch. Geht leider nur unter Windows und auch nicht für alle Boxen (6591 ist z.B. ausgenommen).

Das Programm spielt dir ein ganz frisches Firmwareimage auf und überschreibt dabei alle möglichen internen Speicher in der Box. Danach ist sie wie aus dem Laden. ABER:

Ich hab schon mehrmals im Netz gelesen dass EIN Werksreset bei den Fritzboxen manchmal nicht reicht und erst nach mehrmaligem zurücksetzten auf Werkseinstellungen auch dieser Zustand erreicht wird.

Kann es sein dass du einen IP-Adressen Konflikt hast, also ein und die selbe IP von mehr als einem Gerät verwendet wird? Werden alle Adressen per dhcp verteilt oder hast du irgendwo im Netzt feste Adressen vergeben?

ich würde das wlan in der FRITZ!Box einmal komplett deaktivieren und per Kabel an die FRITZ!Box mit einem einzigen PC/MAC rangehen. Alles andere abklemmen und dann sicherstellen dass der Rechner eine Adresse per dhcp bezieht. Dann den Test wiederholen. Wenn der Ping auf die Fritzbox selbst so schlecht bleibt, stimmt mit dem Ding irgendwas nicht.

Hatte ein Kollege von mir auch so. Er hat auch alles versucht. Am Ende hat er auf ios13 gedowngraded, dort liess sich das Tor problemlos einbinden. Vielleicht mag ios14 keinen neuen Geräte?

Zitat von SeydX

Ist nicht weiter schlimm, Pfad anpassen da wo es bei dir installiert ist und es sollte funktionieren

schon erledigt

Zitat von sschuste

Ich hatte keine Probleme mit den Updates.

Was heißt nicht aufrufbar? Also:

• das Webinterface antwortet auch nach stundenlanger Warterei nicht
• der Browser meldet was Komisches
• irgendwas anderes Furcht erregendes passiert

Sorry, die Fehlerbeschreibung war etwas dünn.

ich habe das Update über das Webinterface angestossen und den anschließend erforderlichen Neustart durchgeführt.

Das Webinterface ist ab da aber nicht mehr erreichbar, die Homebridge selbst läuft munter weiter. Auch nach reboot und systemctl restart ändert sich an der Situation nichts. Sobald ich per:

sudo npm i -g [email protected]

auf die vorhergehende Version wechsele, läuft alles wieder wie am Schnürchen.

Habe mir jetzt mal meine logs angeschaut und folgenden Fehler gefunden:

Aug 13 21:22:46 raspberrypi homebridge[19712]: [8/13/2020, 9:22:46 PM] [Config] Error: Missing `pino-pretty` module: `pino-pretty` must be installed 

Aug 13 21:22:46 raspberrypi homebridge[19712]: [8/13/2020, 9:22:46 PM] [Config] Caught Unhandled Rejection Error :: Details Below

Aug 13 21:22:46 raspberrypi homebridge[19712]: Error: Missing `pino-pretty` module: `pino-pretty` must be installed separately

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at getPrettyStream (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/pino/lib/tools

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at normalizeArgs (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/pino/lib/tools.j

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at pino (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/pino/pino.js:65:28)

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at createPinoLogger (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/fastify/lib/l

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at createLogger (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/fastify/lib/logge

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at build (/usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/fastify/fastify.js:96:33

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at /usr/local/lib/node_modules/homebridge-config-ui-x/dist/main.js:37631:24

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at Generator.next (<anonymous>)

Aug 13 21:22:46 raspberrypi homebridge[19712]:     at fulfilled (/usr/local/lib/node_modules/homebridge-config-ui-x/dist/main.js:37605:58)

Auf GitHub gibt es dazu wohl auch schon einen Problembericht:

Klick

der Fix dazu ist:

cd /usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/

sudo npm i pino-pretty@latest

sudo systemctl restart homebridge

eigentlich sollte der Pfad zum Modul sein:

/usr/lib/node_modules/homebridge-config-ui-x/node_modules/

bei mir ist es aber

/usr/local/lib.......

keine Ahnung warum.