Hallo!
Da sich meine Probleme wohl doch nicht ganz aufgelöst haben habe ich eine Frage die viellleicht auch mal andere helfen könnte...
Ausgangslage:
ca 3 Jahre altes Fhem mit Alexa, Echo, piVccu, Telegram, GAssistant und vielen weiteren Modulen... Alles bis jetzt auf einer damals festen IP: 192.168.1.xxx und DNS: 192.168.1.1.
Wenn ich nun auf eine andere IP umsteigen will/muss (wegen VPN): 192.168.192.xxx und DNS: 192.168.192.10...
Was sind die wichtigsten Einstellungen die ich machen müsste um grundsätzlich keine Probleme zu bekommen?
- unter global soll ja die dns stehen, was wenn da keine steht? Zieht er sich die selbst?
- in der ipVccu muss ich die IP manuell anpassen...
- die fest vergebene IP im System (raspberry) im dhcpcd oder interfaces.d
Wo muss ich unbedingt noch Hand anlegen?
Warum arbeitest du nicht einfach mit Adressvergabe per DHCP?
Auch da gehen "fixe" IPs...
Und auch DNS kann damit gesetzt werden...
(mache ich bei mir: DNS ist mein piHole)
Dann brauchst du schon mal nicht in dhcpcd/interfaces rumtun...
piVccu: kann die nicht per DHCP?
Die Module/Devices in fhem, die Geräte per IP erreichen musst du dann nat. (trotzdem) manuell anpassen...
Ebenso "Dienste" die dein fhem per IP ansprechen (z.B. mqtt)...
EDIT: nicht nötig, wenn Zugriff per Name und ein lokaler DNS vorhanden ;)
dnsServer in global: wenn gesetzt, dann Namensauflösung mit fhem-Implementierung (nicht blockierend), ansonsten mit Systemaufrufen (blockierend)...
Gruß, Joachim
Mit DHCP habe ich irgendwie immer Probleme was piVccu angeht... Fhem findet die Pivcu nicht und dann gibt es stress auf ganzer Linie.
Zudem muss die zuerst gestartet sein damit fhem beim starten er auf die pivccu zugreifen kann sonstwird die d_ccu nicht erkannt.
Den DNS Server... kann man da irgenwie einen zweiten eintragen? Also falls der (AdGuard) DNS ausfällt, warumauch immer, er automatisch einen anderen wählt?
Wenn der DNS rumspinnt spinnt bei mir so ziemlich alls wie gassistant, echos, alexa, es ist eine katastrophe....
???
Mann könnte allerdings den Fhemstart solange verzögern bis pivccu komplett gestartet ist... Nur wie...?
Dann könnte ich ja der PiVccu per dhcp über die Fritzbox eine "feste IP" vergeben lassen und dem Raspberry natürlich auch.... ???
Zitat von: misux am 30 Januar 2023, 08:23:22
Mit DHCP habe ich irgendwie immer Probleme was piVccu angeht... Fhem findet die Pivcu nicht und dann gibt es stress auf ganzer Linie.
Zudem muss die zuerst gestartet sein damit fhem beim starten er auf die pivccu zugreifen kann sonstwird die d_ccu nicht erkannt.
Klingt aber nach schlechter Konfiguration/Implementierung, weil eine Verbindungsunterbrechung kann immer sein (was anderes ist ja ein "Erstverbindungsfehlschlag" auch nicht) und daher muss reconnect implementiert sein...
Meine Meinung.
Zitat von: misux am 30 Januar 2023, 08:23:22
Den DNS Server... kann man da irgenwie einen zweiten eintragen? Also falls der (AdGuard) DNS ausfällt, warumauch immer, er automatisch einen anderen wählt?
Wenn der DNS rumspinnt spinnt bei mir so ziemlich alls wie gassistant, echos, alexa, es ist eine katastrophe....
Kommt drauf an wie/was dein DHCP Server ist/kann...
Gruß, Joachim
Zitat von: misux am 30 Januar 2023, 10:09:22
???
Mann könnte allerdings den Fhemstart solange verzögern bis pivccu komplett gestartet ist... Nur wie...?
Dann könnte ich ja der PiVccu per dhcp über die Fritzbox eine "feste IP" vergeben lassen und dem Raspberry natürlich auch.... ???
Kommt drauf an wo/wie piVCCU läuft.
Im systemd-/Unit-Script von fhem eine Abhängigkeit einbauen.
Z.B. ein weiteres Unit-Script für piVCCU (falls es noch keines gibt oder "woanders" läuft): warten auf piVCCU (wie immer man das festellen kann: ping, Port offen/erreichbar, ...)
Und fhem dann davon abhängig machen...
Besser: reconnect in der Verbindung fhem -> piVCCU
Gruß, Joachim
eigentlich off topic
aber ich habe da die Erinnerung an docker raspberrymatic und fhem. Ich habe damals einfach den fhem container von raspberrymatic abhängig gemacht.
alles alte Erinnerungen: Ich meine im laufenden Betrieb bekommt HMCCU den reconnect hin, beim Start ist eine konfigurierbare Verzögerung eingebaut, aber wenn die überschritten wird dann klappt ein connect nicht mehr.
Kann man die Abhängigkeit nicht in FHEM bauen?
* HMCCU beim start kein auto rpc server start
* presence Device auf piVCCU (wirklich auf Port nicht auf ping)
* dann start HMCCU rpc server
Da muss der User nicht neue systemd scripte bauen.
@Otto:
Bei mir mit einer CCU2 habe ich auch das Problem und bisher (Stromausfall war selten), per Hand gelöst. Eine Idee mit Present ist eigentlich super. Nur wüste ich (aktuell*) nicht, wie man dem HMCCU-Modul sagen kann, das es jetzt "scharf" ist.
*) Bin aktuell etwas erkältet, könnte also durchaus daran liegen, das ich es "verpeile" .. sorry
@Dem Threadersteller:
Lokaler DNS-Server macht bei so etwas es wirklich einfacher. DHCP hat seine Vor/Nachteile ... auf jedem Falle bitte nicht auf DHCP/DNS eines Routers verlassen!
Dann eben in FHEM anstatt von IPs (abgesehen von DNS-Server) eben den DNS-Namen eintragen.
Und um sicherzugehen, ob Du alle IPs gefunden hast (und Du eine Standard Config-File hast), könntest Du doch in der Config-Datei nach der IP Greppen, wie z.B. "grep 192.168.1 /opt/fhem/fhem.cfg"
WAS mich aber wundert: Durch DSL-Änderung ändert Sich Deine Lokale IP-Range????????
Ich kann verstehen, wenn man eine "Nicht-Standard" IP-Range fährt um Angreifer zu Verwirren (Standard z.B. 192.168.178.1/24 Fritzbox). Und eben auch nicht den Router auf die 1 (Verwirrt schon mal ziemlich viele Standard-Angriffstools). Aber das der DSL-Anbieter mir vorschreibt, welche IPv4-Range ich fahre ... das hatte ich (und nachgefragte Freunde) auch noch nie ......
Zitat von: Wernieman am 30 Januar 2023, 13:37:42
@Otto:
Bei mir mit einer CCU2 habe ich auch das Problem und bisher (Stromausfall war selten), per Hand gelöst. Eine Idee mit Present ist eigentlich super. Nur wüste ich (aktuell*) nicht, wie man dem HMCCU-Modul sagen kann, das es jetzt "scharf" ist.
Du meinst das Modul?
Zitatattr rpcserver {on | off}
Specify if RPC server is automatically started on FHEM startup.
und
Zitatset <name> on
Start RPC server(s). This command will fork a RPC server process for each RPC interface defined in attribute 'rpcinterfaces'. Until operation is completed only a few set/get commands are available and you may get the error message 'CCU busy'.
Hmm... okay, dann mal Butter bei die Fische...
Hätte nicht gedacht das es vielleicht doch gut lösbar das problem ist...
Meine Config ist: Alles auf einem RasPi4 fhem und pivccu und alles nach den geläufigen Anleitungen eingerichtet. Rennt an sich seit Jahren nur jetzt habe ich bei mir dinge Umgestellt...
Bin von Kabel auf Glasfaser umgestiegen. Damit dachte ich mir von den Standard IP der Fritzbox auf etwas seltenes umzusteigen (aus vielen Gründen...vpn, "Sicherheit" usw...) also ist jetzt meine IP Range 192.168.192.xxx Es war also nicht der Internetanbieter. Was ja an sich keine Probleme MAcht.
Der DNS Server war ja standardmäßig die Fritzbox ist/soll aber eine SynologyDS werden wo dann AdGuard und co im Docker laufen.
UNd mein Plan ist es die Raspberry mit den ganzen Dingen drauf vernünftig dafür vorzubereiten... Nur so genau weiß ich noch nicht wie... Aber die Tips hier regen mich positiv das es dafür eine gute Lösung gibt.
Sicher ist: egal was passiert, vor allem die Synology mit dem DNS server, wenn die ausfällt, wäre es klasse wenn Fhem auf einen anderen ausweichen könnte ohne das hier alles (alexa, echomodule, gassistant) zusammenbricht...
Was wäre denn wen ich ich unter interfaces.d einfach beide Nameserver eingebe? DNS1 vom Synology wo AdGuard drauf ist und DNS2 von der Fritzbox? Oder ist das so nicht gedacht als Backupdns? Also wenn 1 nicht geht dann nehme 2..?
Erstes Problemchen wäre doch hiermit gelöst:
Definition I/O Device
Im ersten Schritt wird ein I/O Device angelegt, das für die Kommunikation zwischen FHEM und der CCU verantwortlich ist. Im folgenden Beispiel wird davon ausgegangen, dass die CCU unter der IP-Adresse 192.168.1.10 erreichbar ist. Das FHEM Device bekommt den Namen ,,d_ccu".
define d_ccu HMCCU 192.168.1.10
Falls die CCU als Software Service auf dem gleichen Rechner läuft wie FHEM, sollte bei der Definition der Parameter ccudelay angegeben werden. Die CCU Services brauchen beim Starten länger als FHEM (bis zu 2 Minuten). Durch ccudelay wird das neu angelegte I/O Device verzögert um die angegebene Anzahl Sekunden initialisiert. Die Vorgabe sind 180 Sekunden. Je nach Installation kann auch ein höherer Wert notwendig sein:
define d_ccu HMCCU 192.168.1.10 ccudelay=180
Der Start von FHEM wird dadurch nicht verzögert. Lediglich HMCCU wird verzögert initialisiert. Die verzögerte Initialisierung kann mit dem Parameter delayedinit erzwungen werden, greift dann also auch, wenn die CCU beim Start von FHEM erreichbar ist
Die verzögerte Initialisierung kann mit dem Parameter delayedinit erzwungen werden, greift dann also auch, wenn die CCU beim Start von FHEM erreichbar ist
Damit wäre doch sichergestelt das HMccu geladen wird wenn die ccu fertig ist oder? Dann dürfte ich ja keine Probleme bekommen...
Versuch es bitte, vielleicht funktioniert es mittlerweile wie man es da rausliest.
Ich habe wie gesagt in Erinnerung: wenn beim Start von FHEM die CCU nicht erreichbar ist, dann bleibt das für den RPC Server so. Deswegen meine Idee oben...
BTW: die interfaces.d ist bei mir leer. Es kommt alles per DHCP ...
Ich kann leider (immer noch) nicht sagen, bei welchem Stand Linux, welche DNS Konfigschraube die richtige ist. Ich habe jetzt mal irgendwie gelernt: beim Raspberry OS liefert mir resolvconf -l eine vernünftige und verständliche Ausgabe welche DNS Server gefragt werden. Bei debian und armbian funktioniert das nicht. Da kann man etwas erfahren mittels cat /etc/resolv.conf - ob da die ganze Wahrheit steht weiß ich leider nicht. Bei Raspberry OS liefern beide Befehle unterschiedliche Ergebnisse, wenn auch nicht völlig unterschiedlich :)
okay, ich teste es mal aus... Hoffentlich wird aus ne kurzen Test nicht die naht zum Tag...
eine Frage:
ZitatDann eben in FHEM anstatt von IPs (abgesehen von DNS-Server) eben den DNS-Namen eintragen.
Also kann ich anstatt der Fritzbox IP auch einfach dort "fritz.box" eintragen? Das bringt welchen Vorteil? Hab ich nicht ganz verstanden...
Zitat von: misux am 30 Januar 2023, 18:50:07
Also kann ich anstatt der Fritzbox IP auch einfach dort "fritz.box" eintragen? Das bringt welchen Vorteil? Hab ich nicht ganz verstanden...
Naja, den Nutzen den ein DNS generell bringt: Erreichbarkeit per Name und nicht per IP... ;)
IP: musst du bei Änderung überall dort anpassen, wo du sie verwendest
DNS/Name: du passt das einmal zentral (DNS) an und gut...
Gruß, Joachim
Mist... Hat vielleicht einer mal eben den inhalt von interfaces.d und vielleicht auch die dhcpd ?
Habe es jetzt mal wieder geschafft... Habe INterfaces angepasst und nun habe ich keinen zugrif mehr auf der Raspi... Kann man die Datei auch irgendwie am PC bearbeiten? Denn ssh geht auch nicht...
Zitat von: misux am 30 Januar 2023, 20:07:25
Mist... Hat vielleicht einer mal eben den inhalt von interfaces.d und vielleicht auch die dhcpd ?
Welches OS?
Version?
EDIT: hier mal für Raspbian OS Bullseye
:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
:~ $ ll /etc/network/interfaces.d/
total 8
drwxr-xr-x 2 root root 4096 4. Nov 2020 .
drwxr-xr-x 7 root root 4096 27. Mai 2022 ..
:~ $ cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
Zitat von: misux am 30 Januar 2023, 20:07:25
Kann man die Datei auch irgendwie am PC bearbeiten? Denn ssh geht auch nicht...
Ja, wenn du Ext4 (vermute ich) lesen/schreiben kannst...
...oder mit einer Linux-Live booten.
Gruß, Joachim
raspbian lite bullseye oder die vorherige... sollte sehr ähnlich sein... ext4 kann ich am win lesen...
OK, habs hinbekommen...
Bis jetzt scheint alles zu funktionieren... Bin gespannt... werde morgen ein paar neustarts durchführen.