Steht eigentlich alles auf der github Seite vom entwickler.
Siehe hier Option A: Lokaler Sensor, Option B: Fremder Sensor.
Jetzt würde ich das nur noch mal für die lokale abfrage einrichten wollen.
hat da mal einer einen Tip wie es richtig gemacht wird?
Ausgehend davon, dass die Sensor-Nummern stimmen, nimm mal die Config aus Deinem ersten Beitrag und lösche die „Public“-Zeilen. Dann sollte es gehen.
Wie hast Du das mit dem Firmware flushen gemacht?
Guckst du hier
Hallo Leute,
Nach längerer Abstinenz habe ich meine HB neu aufgesetzt und wollte heute Abend mein RaspBee Modul wieder in Betrieb nehmen und in die HB einbinden. allerdings bekomme ich nur die Meldung:
[30.11.2020, 22:37:10] [Phoscon] Phoscon-GW: RaspBee/ConBee not yet initialised - wait 1 minuteegal wie lange ich warte, da tut sich nichts. Ich habe DeCONZ über das Homebridge-Image installiert und kann auch die Weboberfläche aufrufen. Allerdings scheint das System nicht ganz zu laufen, denn es fehlen Angaben zum System:
Wenn ich den Gateway zurücksetzen will, erhalte ich eine Fehlermeldung („Fehlgeschlagen“). Mich wundert, dass in der Web-Oberfläche zur Firmware steht „nicht verbunden“. Da hatte ich sonst einen Eintrag so weit ich mich erinnern kann. Den Zigbee Kanal kann ich auch nicht ändern (muss ich abbrechen).
Den Raspi habe ich mehrfach neu gestartet.
ich möchte deCONZ ungern über die Standardanleitung drüberbügeln, da ich pihole auf Port 80 am laufen habe und ich befürchte, dass sich da sonst die Webseiten Indie Quere kommen. Oder kann man den Port PERI der Installation von phoscon angeben?
Hat irgendjemand eine Idee, was man noch machen könnte?
P.S.: Hat sich erledigt. Neue Firmware geflasht, jetzt läufts.
Lies Dir mal die GitHub Seite genau durch. Du musst Deine Daten nicht in das Script eingeben sondern in das Widget eintragen (als Parameter übergeben)
Hi,
Hab gerade bei mir das Plugin auf die Version 5.0.16 geupdated die FRITZ!Box 7490 ist auf den neuesten Stand, jedoch funktioniert bei mir weiterhin die Broadband-Anzeige nicht.
Zu den anderen Charakteristiken, werden die beim ersten Start nicht aktualisiert, ich kann zwar zb wlan oder die LEDs ausschalten, jedoch heißt es erstmalig bei mir das angeblich beide wlan-netze aus sind obwohl diese an sind.
da stoße ich mal ins gleiche Horn. Auch bei mir wird broadband nicht aktualisiert bzw. Bleibt bei 0.0.
ebenso werden die Characteristics wie z.B. LED usw. beim ersten Start nicht korrekt angezeigt. Heißt, wenn man zum ersten Mal schaut sind alle auf aus, obwohl sie an sind. Wenn man sie einschaltet bleiben alle an, wenn man sie dann das erste Mal ausschaltet, gehen sie auch aus. Von da an ist alles wie gewollt: an=an, aus=aus
das ganze auf FB 6660 cable mit FritzOS 7.22
P.S.: das war aber auch bei der Vorversion des Plugins so, siehe #1654
Hallo!
da empfehle ich Dir: https://github.com/homebridge/homebridge-raspbian-image
aber erst die Seite komplett durchlesen, dann loslegen. Sonst entgeht Dir das ganze Potential.
Alles anzeigenJa, was soll ich sagen:
Mac meines iPhone 12 im 5 GHZ-Netz: 8A:F4:EE:EA:81:01
Mac meines iPhone 12 im 2,4 GHZ-Netz: A0:FB:C5:1A:5D:9B
Das sind die tatsächlichen Macs, die mir meine 7590 anzeigt.
Marco Schmidt In einem etwas anderem Zusammenhang bin ich auch auf dieses Phänomen gestoßen. Ich gehe mal davon aus, dass Du für Dein 2,4 und 5GHz WLAN unterschiedliche Namen hast. Zumindest war das bei mir so. Jetzt gibt es seit IOS 14 (glaube ich) ein Feature, das sich Private WLAN-Adresse nennt. Dabei wird vom IPhone etc. eigens für jedes WLAN eine eigene MAC(!) Adresse vergeben, was dazu führt, dass man beim Wechsel des WLAN auch die MAC Adresse für das Gerät wechselt. Das kann man umgehen, in dem man:
A) beide WLANs gleich benennt und/oder
B) das Gerät mit der privaten WLAN MAC-Adresse (die sieht man, wenn man unter Systemeinstellungen auf das jeweilige WLAN geht und das Info-Symbol drückt in der FRITZ!Box zwangsanmeldet.
C) Das Feature (den bug? :-)) einfach ausschaltet
Dann hat der Spuk ein Ende.
Nur zur Info: bei mir läuft die Homebridge mit config-ui 4.34 und node 14.15.1, allerdings habe ich das hue-plugin nicht installiert. Vielleicht hilft das bei der Fehlversuche oder die HB wieder ans Laufen zu bekommen.
Daher brachte vermutlich im ersten Moment das zurücksetzen der Fritzbox nichts, weil das Pi danach wieder die selbe IP Adresse haben wollte. Erst das neu aufsetzten des RaspPi löste den Knoten in den IP Adressen. Irgendwie so.
Danke für den Hinweis! Ich habe bei der gestrigen Einrichtung des RasPi darauf geachtete, dass ich die selbe statische IP in der DHCPCD.conf angebe wie in der Fritzbox statisch vergeben wird. Aber auch das scheint nicht 100% zu funktionieren. Der DCHP-Server des PiHole ist natürlich ausgeschaltet.
Also habe ich gemäß dem Hinweis von sschuste in Deinem anderen Thread den Eintrag für die statische IP aus der DHCPCD.conf gelöscht. Bisher läuft alles rund. Doppelt hält wohl nicht immer besser. Mal gucken, wie lange es hält.
So Leute,
kleines Feedback , nachdem ich jetzt endlich den Fehler gefunden habe (hoffentlich):
Mein RaspberryPi und meine Fritz!Box hatten irgendwie ein IP-Zuweisungsproblem. Mir ist zwar schleierhaft warum, aber selbst die mehrfach auf Werkseinstellungen zurückgesetzte Fritz!Box bestand darauf, dem RasPi weiterhin ein und die selbe feste IP zuzuweisen. Das wollte der Raspi aber nicht so wirklich. Der hatte wiederum - so weit ich das checken konnte - keine (andere) feste IP vorgegeben, hat sich mit der IP von der Fritz!Box wohl aber auch nicht so richtig wohlgefühlt. Gemeckert hatte aber keiner von beiden, wie in einer alten Rechner-Ehe.
Aufgefallen bzw. mittelmäßig rekonstruiert habe ich das erst, als ich den Raspi komplett neu aufgesetzt hatte und jetzt eine feste IP im RasPi vorgeben wollte, Die ist aber nie bei der Fritz!Box angekommen und wurde von der Fritz!Box weiterhin ignoriert. Stattdessen wurde weiterhin die selbe IP wie bisher für den Raspi registriert. Wohlgemerkt: Die von der Fritz vergebene IP stammt weder aus dem reservierten statischen Bereich noch habe ich eine Regel definiert, diese statisch zu vergeben. Weiß der Teufel bzw. AVM, was da falsch gelaufen ist.
Jetzt bezieht der RasPi von der Fritz!Box eine statische IP (aus dem statischen Bereich) und alle sind happy. Insbesondere ich.
Euch nochmals vielen Dank für die schnelle und unterhaltsame Hilfe. Nebenbei habe ich auch mal wieder was gelernt, u.a. wie praktisch so ein kleiner "ping" sein kann...
Alles anzeigenHast 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.
Ja, die Box wurde von mir über die eigene Weboberfläche zurückgesetzt. Das RecoveryTool gibt es nicht für die 6660 und auch nicht für die 6490. Ich habe (eher zufällig) das letzte Mal per Telefon (wusste auch nicht, dass das geht) zurückgesetzt.
Nach meiner letzten Erfolgsmeldung von gestern Nacht habe ich heute Morgen leider feststellen müssen, dass es noch schlimmer geworden ist. Seit dem habe ich bis jetzt heute Morgen drei Mal die Box zurückgesetzt. Ich grenze die Anzahl der angeschlossenen Geräte immer weiter ein. Aktuell habe ich nur das MacBook per WLAN am Router hängen. Alle anderen Geräte sind abgeklemmt und/oder ausgesperrt.
Vielleicht war ich letzte Nach mal wieder etwas zu enthusiastisch und schnell bei der Einbindung der restlichen Geräte. Ich werde mir mal heute mehr Zeit lassen, bevor ich ein weiteres Gerät hinzunehme. In meiner engeren Auswahl für die Übeltäter sind aktuell einer meiner Repeater und mein RaspberryPi, auf dem Homebridge und Pihole laufen...
Ist nur immer komisch: Sobald der Fehler einmal da ist, bleibt er auch, d.h. wenn ich nach dem ersten Auftreten des Fehlers die Geräte wieder abklemme, ändert sich nichts zurück zum Guten.
------
Und während ich das hier schreibe und außer dem MacBook kein anderes Gerät im gesamten LAN/WLAN hängt, passiert es schon wieder:
- Ich sitze 4m vom Router weg (Sichtkontakt)
- Bin mit dem Macbook als einziges Gerät im gesamten LAN/WLAN mit dem Router verbunden
- schicke einen Ping an meine Fritzbox
und... -> bekomme sporadisch über 3-5 Sekunden "Request timeout for icmp_seq" wie gehabt.
Jetzt schmeiße ich mal das Macbook aus dem WLAN und probiere es mit einem anderen Rechner.
boehser enkel @Lucifer Morningstar Danke für die schnelle Aufklärung
sschuste Vielen Dank für die ausführliche und zugleich unterhaltsame Ausführung.
Dann kann ich das als Fehlerquelle in meinem immer noch instabil laufenden Netz ausschalten. Irgendetwas läuft da verkehrt bei der IP Vergabe. Aber das ist eine andere Geschichte und soll in einem anderen Thread erzählt werden...
Hi Leute, ich habe mal ne Frage zu den Settings in Phiole. Was genau bedeutet eigentlich der Eintrag unter ipv4:
Soll das heißen, dass der Phiole 2 ipv4 Adressen belegt? 192.168.178.23 und 192.168.178.24? Wenn ja, warum? und warum sehe ich das nicht in meinem Router?
Wenn es das nicht ist, was soll die 24 dann bedeuten?
LG
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?
Also, das jetzige Problem hat eigentlich schon vor einiger Zeit mit dem alten Router begonnen, aber bei der Einrichtung der neuen Fritzbox ist mir aufgefallen, dass manche Netzwerkgeräte den falschen Namen haben, so als wenn der Router mit einer alten Datenbank mit Netzwerkgerätenamen durcheinander kommen würde. Doppelt scheint aber nichts zu sein. Daraufhin hatte ich allen Geräten eine statische IP zugewiesen. Hat aber nichts geholfen. Komischerweise haben einige Geräte trotz statisch zugewiesener IP mehrere IPs (soll heißen, in der Liste der inaktiven Geräte tauchen sie trotzdem mit einer anderen IP auf und manchmal loggen sie sich trotzdem mit unterschiedlicher IP ein). Bei manchen Geräten habe ich bis zu 4 IPs. Es scheint so, als wenn die Geräte an jedem Repeater, mit dem sie sich verbinden eine neue IP bekämen. Kann ich aber nicht nachweisen.
Das hatte ich allerdings bisher als ursprüngliche Fehlerursache ausgeschlossen, da ich dieses Verhalten erst auf dem neuen Router beobachtet hatte.
Ich werde mal versuchen Deinem Ansatz nachzugehen. Danke für den Hinweis.
sschuste Wenn es die selben (falschen) Einstellungen sind, warum sollte das nicht auf zwei verschiedenen Routern zum selben Problem führen?
Letzter Post ist bei dem ganzen WLAN an- und ausgeschalte hängen geblieben, daher nicht mehr ganz up to date...
Inzwischen habe ich das WLAN-Netz nochmal komplett neu aufgesetzt. Dabei gab es trotz Zurücksetzen auf Werkseinstellungen immer wieder das Problem, dass die Fritzbox glaubte, die neu angemeldeten Geräte schon zu kennen. Ich musste trotz Laden der Werkeinstellung aller Fritz-Geräte nochmals einzelne Computer etc. aus der Liste der bekannten Geräte löschen, obwohl ich auch einen neuen WLAN Namen vergeben hatte und sich deshalb eigentlich gar kein Gerät hätte einloggen können. Warum auch immer die trotzdem noch drin waren...
Seit dem läuft das WLAN stabil. Ich habe zwar noch nicht alle Geräte wieder ins WLAN eingefügt, aber seit über einer Stunde habe ich einen durchgängigen Ping.
Nochmals Dank an Euch für die Hinweise und Tipps!
P.S.: Traceroute dauert jetzt übrigens nicht einmal mehr eine Sekunde 
Ja, die Fritzbox antwortet ein paar Sekunden nicht. Aber das muss nicht an der Fritzbox liegen, das kann auch am Mac liegen. Eine von den beiden Kisten schwächelt - auch wenn ich geneigt bin, es auf die Fritzbox zu schieben, nachdem was du weiter oben geschrieben hast: alle deine Computer haben Netzwerkprobleme.
Unabhängig von diesem Ergebnis wäre aber irgendeine WLAN-Komponente immer noch kaputt. Prinzipiell müsste man die Fritzbox austauschen und weiter testen - was meistens an der Anzahl vorhandener Testrouter scheitert.
Ich hatte bis vor 1 Woche einen anderen Router (damals FB6490, jetzt FB6660). Den Router hatte ich in der Hoffnung gewechselt, dass es an der HW liegen könnte. Scheint aber nicht der Fall zu sein, da es mit dem neuen Router nicht besser geworden ist. Vielleicht habe ich die selben falschen Einstellungen am Router übernommen?!?
Hast du das ganze mal bei lan Kabel angeschlossen getestet?
Am besten wäre es wenn du per lan Kabel und per wlan gleichzeitig messen kannst
Ich habe inzwischen alle Repeater vom Strom genommen, d.h. der Mac ist direkt über WLAN mit dem Router verbunden, und weiter gepingt: Das Ergebnis bleibt: Ab und zu "Request timeout" und sogar manchmal "ping: sendto: No route to host" im Log des Ping.
Nebenbei habe ich einen anderen Mac direkt per LAN am Router angeschlossen und ebenfalls gepingt. Dort sind die Fehler nicht aufgetreten. Scheint also definitiv ein WLAN Problem zu sein. Korrigiert mich bitte, wenn ich was übersehe.
Ich denke, ich werde in den sauren Apfel beißen müssen und die Fritzbox noch einmal auf Werkseinstellungen zurücksetzen und dann Stück für Stück meine Einstellungen wieder einpflegen. Ist zwar gefühlt das hundertste Mal, aber was soll's, man hat ja sonst nix zu tun...
Nein, ist ein Mac, von dem ich arbeite. Und es dauert schon eine Weile bis traceroute beendet ist (so ca. 5-10Sek)
Ich habe jetzt mal parallel meine Fritzbox und den ersten Provider Server angepingt. Und siehe da:
Provider:
64 bytes from 77.21.43.254: icmp_seq=844 ttl=63 time=15.453 ms
64 bytes from 77.21.43.254: icmp_seq=845 ttl=63 time=12.968 ms
64 bytes from 77.21.43.254: icmp_seq=846 ttl=63 time=11.701 ms
Request timeout for icmp_seq 847
Request timeout for icmp_seq 848
Request timeout for icmp_seq 849
Request timeout for icmp_seq 850
Request timeout for icmp_seq 851
Request timeout for icmp_seq 852
Request timeout for icmp_seq 853
64 bytes from 77.21.43.254: icmp_seq=854 ttl=63 time=29.288 ms
64 bytes from 77.21.43.254: icmp_seq=855 ttl=63 time=53.720 ms
64 bytes from 77.21.43.254: icmp_seq=856 ttl=63 time=11.391 msund quais gleichzeitig:
FritzBox:
64 bytes from 192.168.178.1: icmp_seq=846 ttl=64 time=2.916 ms
64 bytes from 192.168.178.1: icmp_seq=847 ttl=64 time=1.379 ms
64 bytes from 192.168.178.1: icmp_seq=848 ttl=64 time=2.680 ms
Request timeout for icmp_seq 849
Request timeout for icmp_seq 850
Request timeout for icmp_seq 851
Request timeout for icmp_seq 852
Request timeout for icmp_seq 853
Request timeout for icmp_seq 854
64 bytes from 192.168.178.1: icmp_seq=855 ttl=64 time=37.187 ms
64 bytes from 192.168.178.1: icmp_seq=856 ttl=64 time=110.404 ms
64 bytes from 192.168.178.1: icmp_seq=857 ttl=64 time=5.338 msBeide haben quasi zum gleichen Zeitpunkt einen Ausfall (Der Start von Ping ist um ca. 1-2 Sekunden versetzt). Und während ich das schreibe, bekomme ich noch genau so ein Verhalten geliefert. D.h. dann wohl, dass das Problem irgendwo innerhalb meines Netzes liegt, richtig?
Vielen Dank schon mal für die Unterstützung dahingehend, dass ich diese Einsicht erlangen durfte.
Ich werde jetzt mal wieder alle Repeater abklemmen und das Netz weiter per Ping beobachten und sollte es gut laufen, mal einen Repeater nach dem anderen wieder ins traute Heim aufnehmen. Ich höre jetzt schon das Geschrei meiner Kinder, weil die gleich im OG ohne Internet sein werden...
Falls Ihr noch weitere so zielführende Ideen habt, immer her damit! Schon mal Danke bis hier her!
Also, ich habe den selben Hub wie Du aktuell in Betrieb. Ist aber schon ewig her, dass ich den eingerichtet habe. Seither benutze ich ihn sporadisch in HomeKit. Eigentlich nur, um ein paar Feuchtigkeitswarner anzusprechen.
Ich habe parallel noch die Xiaomi- und die Aquara-Home-App laufen. Keine Ahnung mehr, über was ich die Bridge damals integriert habe. Aktuell ist es so, dass Xiaomi die Bridge auflistet, aber sagt, sie wäre nicht ansprechbar. In der Aquara-Home-App taucht sie ebenfalls auf mit der Firmware 3.0.0 und wenn ich auf Update gehe, bekomme ich die Meldung, dass die Firmware aktuell sei. Über HomeKit und Aquara kann ich die Bridge auch ansprechen.
Hast Du mal die Aquara Home app versucht?
servus,
wenn du von videokonferenzen sprichst, meinst du das dann beruflich, so dass du vielleicht mit vpn einen tunnel zur firma hast?
Bluesmoke Das ist zwar beruflich, aber läuft ohne VPN. Trotzdem vielen Dank!
Je nachdem, in was für einer Konferenz ich bin, arbeite ich mit BBB, Zoom oder WebEx. Aber alle ohne VPN. Zoom und WebEx kommen mit den Unterbrechungen einigermaßen zurecht. Hier bekomme ich nur Aussetzer, aber die Verbindung bleibt bestehen. BBB ist eine Katastrophe. Sobald eine Unterbrechung da ist, muss ich mich komplett aus BBB ausloggen und wieder neu einloggen. Da ich aufgrund gegebener Randbedingungen das System nutzen muss, ist das um so ärgerlicher.
Traceroute habe ich mal probiert, dann kommt sowas:
1 fritz.box (192.168.178.1) 2.552 ms 1.990 ms 2.637 ms
2 ip4d152bfe.dynamic.kabel-deutschland.de (77.21.43.254) 13.168 ms 13.846 ms 9.648 ms
3 ip53a99a56.static.kabel-deutschland.de (83.169.154.86) 10.172 ms 11.159 ms 9.633 ms
4 ip5886c21b.static.kabel-deutschland.de (88.134.194.27) 16.069 ms 12.425 ms 13.886 ms
5 145.254.3.122 (145.254.3.122) 16.013 ms 20.553 ms 31.071 ms
6 145.254.2.217 (145.254.2.217) 17.367 ms 15.877 ms 16.044 ms
7 72.14.194.138 (72.14.194.138) 25.638 ms 24.133 ms 25.375 ms
8 * * *
9 dns.google (8.8.8.8) 22.074 ms 20.771 ms 20.302 msSagt mir jetzt aber auch nicht viel mehr. Leider.
Und nochmal ping eine Weile laufen lassen:
--- 8.8.8.8 ping statistics ---
2700 packets transmitted, 2700 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.512/26.384/346.824/21.309 ms
MacBook-Pro-15:~ florianschmidt$ tracert 8.8.8.8Jetzt läufts wohl gerade mal wieder...
Ich werde hier noch irre!
Ich werde das mal testweise neben meiner nächsten Konferenz ping laufen lassen. Mal sehen, ob es da parallele Ereignisse und Erkenntnisse gibt.
sschuste Schön, dass Du nicht zu den Leidensgenossen gehörst! Ich würde gerne mit Dir tauschen...
Zum Thema Ping: Gleich beim ersten Versuch kam folgendes heraus:
ZitatAlles anzeigenRequest timeout for icmp_seq 270
Request timeout for icmp_seq 271
Request timeout for icmp_seq 272
Request timeout for icmp_seq 273
^C
--- 8.8.8.8 ping statistics ---
275 packets transmitted, 187 packets received, 32.0% packet loss
round-trip min/avg/max/stddev = 17.981/44.780/1085.414/95.838 ms
Obwohl mir das Fachwissen fehlt, um genau interpretieren zu können, was die Zusammenfassung letztendlich bedeutet und ob die Werte gut oder schlecht sind, sieht es für mich so aus, als wenn da was nicht in Ordnung läuft.
Parallel zum "ping" habe ich allerdings erfolgreich im Internet Seiten (nicht aus dem Cache, weil mir unbekannte Seiten) aufrufen können.
Zudem läuft das Ping-Experiment gerade parallel seit 15min. weiter und ich habe nicht einen einzigen Paket-Verlust.
Ich weiß zwar ansatzweise, was ping macht, kann aber aus den Rückmeldungen keinen Lösungsansätze ableiten. Will Google nur einfach nicht mit mir reden? Geht der Ping erst gar nicht aus dem Haus? Wenn nicht, wo bleibt der hängen? Im WLAN? Im Router? Beim Provider? Wie komme ich an diese Informationen bzw. wie kann ich daraus jetzt Fehler bzw. Lösungsmöglichkeiten ableiten?
Für weitere Hinweise wäre ich sehr dankbar.
HG