Ich hoffe, ich bin im richtigen Topic. Mich nervt schon seit einiger Zeit ein Problem, das besonders bei Stromausfällen sichtbar wird. Ich beschreibe mal alles, dann sieht man, was los ist - ich weiß aber nicht recht, wo ich ansetzen soll.
- Ich habe einen RPi, auf dem FHEM läuft (jessie, fast neu - never change usw.)
- Allerdings hat der RPi zwei WLAN-Karten mit unterschiedlichen MAC-Adressen, nämlich einmal 5GHz und 2,4GHz. Letztere hat eine sehr große Antenne, falls der Empfang schlecht ist. Erstere habe ich wegen des Mesh-Fritzbox 7490-Dings drin, dann ist die Verbindung besser. Angeblich wechselt die FB zwischen den besseren Netzen hin und her.
- Nach einem Neustart weist die FB nun dem RPi eine IP-Adresse zu. Je nach dem, welches Netzwerk sie nimmt, ist das entweder *.7 (2,4GHz) oder *.14 (5GHz). Ich kann vorher nicht erkennen, welches Netzwerk zuerst da ist. Auf dem RPi ist DHCP eingestellt, die Auswahl der IP-Adressen übernimmt die FB.
- Mit avahi-daemon ist der RPi jederzeit über fhem.local erreichbar. Egal welche IP.
- Meine Sonoffs müssen nun über MQTT zugreifen. Dabei suchen sie den Host. Während ESPEasy sich mit einem Hostnamen wie fhem.local zufrieden gibt, schaffen das die Sonoffs nicht. Hier muss bei einem Wechsel der IP (etwa alle drei Monate) jedesmal die IP geändert werden.
Kann mir jemand sagen, an welcher Stelle ich was falsch mache?
<edit nach Lösung> Natürlich an der Stelle, an der es beim RPi immer hakt: Der Stromversorgung. Dann kann man sich das Lesen des Threads sparen...
Kann dir zwar mit Fritzbox Zeugs nicht helfen, aber grundsätzlich verstehe ich nicht, warum der Pi keine fixe ip Adresse hat.
Ich habe für alle Geräte die irgendeine Art von Service liefern, also NAS, CAM's, Mediaplayer usw. fixe Adressen definiert. Zusätzlich noch DNS dann kann ich sehr einfach Netzwerkdienste ändern ohne dass die Konfiguration in allen Clients geändert werden muss.
Dynamische Adressen bekommen nur Endgeräte also Telefone oder Laptop.
Sent from my iPad using Tapatalk
ZitatKann dir zwar mit Fritzbox Zeugs nicht helfen, aber grundsätzlich verstehe ich nicht, warum der Pi keine fixe ip Adresse hat.
In der FritzBox(Heimnetzwerk) lässt sich je device einstellen(anhaken), dass das device immer dieselbe IP per DHCP zugewiesen bekommt. Hat den Vorteil, dass man einerseits an den üblicherweise auf DHCP voreingestellten devices nichts ändern muss und trotzdem immer eine feste IP hat.
Ich hab das so für ALLE Geräte eingestellt. Sobald ein neues Gerät in den Haushalt kommt das Häkchen setzen und schon ist auf ewig Schluss mit IP-Adressen-Rate-/-fummelei.
Grüße Markus
Ich weiß, was Ihr meint (siehe Screenshot): Das Problem bei mir ist, dass der eine RPi wegen der beiden WLAN-Karten zweifach angezeigt wird. Ich kann also nur bei der WLAN-Karte, nicht aber dem RPi selbst die IP fixieren. (Oder ich übersehe was).
PS: Tasmota sagt "However the use of local mDNS hostnames (ex: mqtt_home.local) is not supported, if you want to use a broker on your local network you need to use its local IP or rely on a local DNS to resolve the hostnames."
Das ist anscheinend auch mein Problem.
Also, da gibt es anscheinend zwei mögliche Lösungen.
- Man fügt mDNS in den Tasmota Code ein, siehe https://github.com/madpilot/mDNSResolver/tree/master/examples (https://github.com/madpilot/mDNSResolver/tree/master/examples). Das kostet Speicherplatz und ich übersehe nicht, ob das mit anderen Sachen interferiert.
- Da der Unsinn nur auftaucht, wenn Stromausfall war und danach eine andere IP verwendet wird, kann man das wahrscheinlich händisch lösen. Wenn das Gerät offline, dann rufe ich (zB)
Zitathttp://192.168.2.31/cm?cmnd=MqttHost%20192.168.2.14
auf, wobei da rechts dann die IP des MQTT stehen muss. Jetzt muss ich nur herausbekommen, welche IP der RPi hat und dann läuft das eben so.
Das war mit meiner FB immer schon so und hat genervt. Nur wollte ich jetzt mal eine generelle Lösung...
PS Ich habe noch etwas gefunden. Im Programmcode von Tasmota scheint es in der Tat mDNS zu geben, denn my_user_config.h enthält ganz unten
// -- mDNS ----------------------------------------
#define USE_DISCOVERY // Enable mDNS for the following services (+8k code, +0.3k mem)
#define WEBSERVER_ADVERTISE // Provide access to webserver by name <Hostname>.local/
#define MQTT_HOST_DISCOVERY // Find MQTT host server (overrides MQTT_HOST if found)
Allerdings wird dann, wenn man die Basismodule flasht, diese Sache überschrieben. Denn in sonoff_post.h finde ich
/*******************************************************************************************/*********************************************************************************************\
* [sonoff-basic.bin]
* Provide an image without sensors
\*********************************************************************************************/
#ifdef USE_BASIC
...
#undef USE_DISCOVERY // Disable Discovery services for both MQTT and web server
und dann geht das natürlich nicht mehr. Ich werde die Geräte evtl mal neu flashen und vorher das herausnehmen.
MMoin,,
die beste Lösung: Steck ein Kabel in den Pi und die andere Seite in die Fritzbox!
Ich habe nicht verstanden wozu Du es dem Zufall überlässt, irgendeine Wlanverbindung zu nehmen.
Und ich habe nicht verstanden wieso der Pi nicht immer beide Netzwerkverbindungen hat. Ich habe auch einen Pi mit zwei Netzwerkverbindungen(LAN/Wlan). Verhindert das die Mesh Funktion der FB?
Eine Netzwerkverbindung definieren und fertig! Oder fliegt der Pi auf einer Drohne ständig umher?
Gruß Otto
Hi,
die Sache ist doch einfach!
Der RPi sollte immer beide Adressen von der Fritte bekommen (deswegen ja auch bei beiden in der FritzBox das Häckchen feste IP). Dabei ist dann such die Reihenfolge egal!
Anscheinend kannst Du aber nicht über beide IPs zugreifen, also hat Dein RPi eine falsche Konfiguration für das MQTT!
Zeig uns die mal, zeig uns auch Deine ifconfig Ausgaben (IPv6 aktiv?), zeig uns mal die Logs bei falschem Sonoff Aufruf (von Sonoff und von RPI), wie stehen die iotables (oder welche Firewall nutzt du?)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
die Sache ist doch einfach!
Solche Sätze liebe ich, nachdem ich stundenlang mir den Kopf zerbrochen habe ;-)
Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
Der RPi sollte immer beide Adressen von der Fritte bekommen
Ja, das wäre die beste Lösung.
Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
Anscheinend kannst Du aber nicht über beide IPs zugreifen, also hat Dein RPi eine falsche Konfiguration für das MQTT!
Zeig uns die mal, zeig uns auch Deine ifconfig Ausgaben (IPv6 aktiv?), zeig uns mal die Logs bei falschem Sonoff Aufruf (von Sonoff und von RPI)
Also ich habe
pi@FHEM:~ $ ifconfig
eth0 Link encap:Ethernet Hardware Adresse b8:27:eb:1b:8c:7b
inet6-Adresse: fe80::fffb:79dd:22c5:af80/64 Gültigkeitsbereich:Verbindung
UP BROADCAST MULTICAST MTU:1500 Metrik:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX packets:360951 errors:0 dropped:0 overruns:0 frame:0
TX packets:360951 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:249016604 (237.4 MiB) TX bytes:249016604 (237.4 MiB)
wlan0 Link encap:Ethernet Hardware Adresse b8:27:eb:4e:d9:2e
inet6-Adresse: fe80::7a41:4e51:ddb0:7808/64 Gültigkeitsbereich:Verbindung
UP BROADCAST MULTICAST MTU:1500 Metrik:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan1 Link encap:Ethernet Hardware Adresse a0:ab:1b:cc:98:fd
inet Adresse:192.168.2.14 Bcast:192.168.2.255 Maske:255.255.255.0
inet6-Adresse: fe80::a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fe80::8542:4ab5:81cc:834e/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: 2003:cf:5700:6600:a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:368406 errors:0 dropped:41029 overruns:0 frame:0
TX packets:205807 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:83704768 (79.8 MiB) TX bytes:100215499 (95.5 MiB)
sowie
pi@FHEM:~ $ iwconfig
wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
lo no wireless extensions.
eth0 no wireless extensions.
wlan1 IEEE 802.11bg ESSID:"WLAN-120954" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.462 GHz Access Point: 00:26:4D:60:D9:58
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=88/100 Signal level=57/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0Zitat von: RaspiLED am 26 Dezember 2018, 11:54:14
wie stehen die iotables (oder welche Firewall nutzt du?)
pi@FHEM:~ $ sudo iptables --table nat --list
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination Keine Firewall außer der FB, keine Ports offen etc.
Außerdem sehe ich im Logfile ellenlange Meldungen à la
Dec 26 12:01:45 FHEM kernel: [76854.408884] Voltage normalised (0x00000000)
Dec 26 12:01:47 FHEM kernel: [76856.488917] Under-voltage detected! (0x00050005)
Dec 26 12:02:07 FHEM kernel: [76877.289011] Voltage normalised (0x00000000)
Dec 26 12:02:10 FHEM kernel: [76879.369015] Under-voltage detected! (0x00050005)
Dec 26 12:02:22 FHEM kernel: [76891.849072] Voltage normalised (0x00000000)
Dec 26 12:02:24 FHEM kernel: [76893.929090] Under-voltage detected! (0x00050005)
Dec 26 12:02:30 FHEM kernel: [76900.169141] Voltage normalised (0x00000000)
Dec 26 12:02:32 FHEM kernel: [76902.249141] Under-voltage detected! (0x00050005)
Dec 26 12:03:31 FHEM kernel: [76960.489464] Voltage normalised (0x00000000)
und ich habe eine 2A-Versorgung da dran. Könnte es sein, dass ich da 3A nehmen muss? Ansonsten ging anscheinend der Zugriff und dann mal wieder nicht:
Dec 25 13:15:58 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:25:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:25:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:35:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:35:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:45:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:45:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 13:55:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 13:55:59 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
Dec 25 14:05:59 FHEM wpa_supplicant[601]: wlan0: WPA: Group rekeying completed with 38:10:d5:1c:d5:b8 [GTK=CCMP]
Dec 25 14:06:00 FHEM wpa_supplicant[560]: wlan1: WPA: Group rekeying completed with 38:10:d5:1c:d5:b9 [GTK=CCMP]
...
Dec 25 14:08:33 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:33 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:34 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:34 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:35 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:35 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Dec 25 14:08:37 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="WLAN-120954" auth_failures=1 duration=10 reason=CONN_FAILED
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-ASSOC-REJECT status_code=1
Dec 25 14:08:40 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-ASSOC-REJECT status_code=1
Dec 25 14:08:48 FHEM wpa_supplicant[598]: wlan0: Failed to initiate sched scan
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: Trying to associate with 00:26:4d:60:d9:58 (SSID='WLAN-120954' freq=2462 MHz)
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: Associated with 00:26:4d:60:d9:58
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: WPA: Key negotiation completed with 00:26:4d:60:d9:58 [PTK=CCMP GTK=TKIP]
Dec 25 14:08:48 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-CONNECTED - Connection to 00:26:4d:60:d9:58 completed [id=0 id_str=]
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: carrier acquired
Dec 25 14:08:48 FHEM dhcpcd[470]: DUID 00:01:00:01:1f:77:63:ca:b8:27:eb:1b:8c:7b
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: IAID 1b:cc:98:fd
Dec 25 14:08:48 FHEM dhcpcd[470]: wlan1: rebinding lease of 192.168.2.14
Dec 25 14:08:51 FHEM wpa_supplicant[598]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Dec 25 14:08:51 FHEM wpa_supplicant[583]: wlan1: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Dec 25 14:08:52 FHEM avahi-daemon[468]: Registering new address record for fe80::a2ab:1bff:fecc:98fd on wlan1.*.
Dec 25 14:08:53 FHEM dhcpcd[470]: wlan1: probing for an IPv4LL address
Dec 25 14:08:53 FHEM dhcpcd[470]: wlan1: DHCP lease expired
Dec 25 14:08:54 FHEM dhcpcd[470]: wlan1: soliciting a DHCP lease
Dec 25 14:08:58 FHEM dhcpcd[470]: timed out
Dec 25 14:08:58 FHEM dhcpcd[470]: forked to background, child pid 853
@Otto: Ein Kabel kann ich da nicht anschließen, ohne mehrere Meter Wand aufzuhacken.
Zitat@Otto: Ein Kabel kann ich da nicht anschließen, ohne mehrere Meter Wand aufzuhacken.
Das ist die Sache mit dem Berg und dem Propheten ;D
Ich würde halt die Zentrale nicht wackelig mit dem Netzwerk verbinden. Lieber würde ich dann die Funktionen auf abgesetzte Geräte aufteilen.
Aber der Ansatz von Arnd klingt gut und vernünftig :D
Gruß Otto
PS Also im Sonoff steht 192.168.2.7 und die findet er nicht, weil der dusslige RPi gerade entschieden hat 192.168.2.14 zu sein. Ich sehe dann nur, dass der Sonoff den Host nicht findet. Im RPi steht nichts, weil der ja formal nicht angesprochen wird.
Ich sehe gerade, Wlan 0 ist nicht verbunden und Wlan 1 ist verbunden. Lässt das die FB wegen Mesh nicht zu?
Dann deaktiviere doch Wlan 1.
Gruß Otto
Hi,
deswegen habe ich den ,,einfach" Spruch ja gepostet ;-)
Also meine aktuelle Vermutung ist, das IPv6 zuschlägt und Dein RPi auf einem WLAN die IPv6 erhält und auf WLAN1 eine IPv4.
Wie wäre es in der Fritte IPv6 zu deaktivieren? Oder als
add this to /boot/cmdline.txt
ipv6.disable=1
Und reboot ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Bevor ich das tue, noch eine Frage: Könnte das mit der Spannungsversorgung nicht die Ursache sein? Immerhin gingen vor einigen Tagen beide WLANs noch.
Doch, weil im Energiemanagement dann USB Ports deaktiviert werden ,,könnten" - Aber meine RPis zicken an meiner Fritte auch ständig w/ IPv6! Daher habe ich das ,,einfach" deaktiviert und seitdem keine Probleme mehr ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Gelöst. Ich habe eine neue Stromversorgung (diesmal mit Apple-2,1A und nicht China-2A), und auf einmal
wlan0 Link encap:Ethernet Hardware Adresse b8:27:eb:4e:d9:2e
inet Adresse:192.168.2.7 Bcast:192.168.2.255 Maske:255.255.255.0
inet6-Adresse: fe80::7a41:4e51:ddb0:7808/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fe80::ba27:ebff:fe4e:d92e/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: 2003:cf:5700:6600:ba27:ebff:fe4e:d92e/64 Gültigkeitsbereich:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:882 errors:0 dropped:1 overruns:0 frame:0
TX packets:823 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:239517 (233.9 KiB) TX bytes:104417 (101.9 KiB)
wlan1 Link encap:Ethernet Hardware Adresse a0:ab:1b:cc:98:fd
inet Adresse:192.168.2.14 Bcast:192.168.2.255 Maske:255.255.255.0
inet6-Adresse: fe80::a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fe80::8542:4ab5:81cc:834e/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: 2003:cf:5700:6600:a2ab:1bff:fecc:98fd/64 Gültigkeitsbereich:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:260 errors:0 dropped:4 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:41243 (40.2 KiB) TX bytes:14217 (13.8 KiB)
Danke, Ihr habt mir Weihnachten gerettet!
Ach wie einfach ;-) Frohe Weihnachten! Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich würde davon abraten Ladegeräte zur Stromversorgung zu nutzen.
Besorg dir für auf Dauer lieber ein vernünftiges Netzteil.
Gesendet von meinem Doogee S60 mit Tapatalk