IP Adresse per Mac Adresse auswerten und als Def übernehmen

Begonnen von accloginsell, 23 Januar 2019, 11:20:52

Vorheriges Thema - Nächstes Thema

accloginsell

Servus Zusammen,

ich habe seit ein paar Wochen den RoboRock und ein paar Xiami Lampen. Das Problem diese hier gibt es leider keine Möglichkeit die IP fest zu definieren. Aufgrund der Telekomleitung mit Vectoring müssen wir auch einen Speedport nehmen. Dieser kann keine Feste IP zuweisung.


Ein script der jede Stunde die IP Adressen abfragt und als Reading hinterlegt gibt es bereits.

Nun die Frage wie bekomme ich dieses Reading in das DEF eines Gerätes?

Danke für eure Infos!

Grüße
Nico

r00t2

#1
Sollte mit "userReadings" und/oder "setreading" funktionieren.
Mehr dazu findest Du in der Commandref (oder hier https://wiki.fhem.de/wiki/UserReadings).
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

accloginsell

Danke dir! Aber per setreading krieg ich ja nichts in die DEF oder?

rabehd

Auch funktionierende Lösungen kann man hinterfragen.

accloginsell

Naja ich glaube nicht. Ich möchte die DEF also vom device Vacuum die IP adresse im bereich DEF automatisch updaten lassen..

Wisst ihr was ich meine?

Beta-User

#5
a) Wo ist der codeschnipsel (=>falscher Forenbereich!)

b) Wie wäre es mit einem eigenen WLAN-Bereich für den HA-Teil? So ist das nicht nur WLAN (meine 2ct: das ist allg. kritisch zu sehen und sollte vermieden werden), sondern dann auch noch dynamisch und vermischt mit allen anderen Geräten. Selbst von Leuten, die hinsichtlich WLAN weniger kritisch eingestellt sind, wird so eine getrennte Architektur tendenziell empfohlen...

(getrennt ergänzt)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rabehd

Zitat von: accloginsell am 23 Januar 2019, 11:48:24
Naja ich glaube nicht. Ich möchte die DEF also vom device Vacuum die IP adresse im bereich DEF automatisch updaten lassen..

Wisst ihr was ich meine?

Glauben ist nicht wissen!

Zumindest ich weiss nicht was Du meinst. (siehe auch Beta-User)
Auch funktionierende Lösungen kann man hinterfragen.

r00t2

Zitat von: Beta-User am 23 Januar 2019, 11:52:40...b) Wie wäre es mit einem eigenen WLAN-Bereich für den HA-Teil? So ist das nicht nur WLAN (meine 2ct: das ist allg. kritisch zu sehen und sollte vermieden werden), sondern dann auch noch dynamisch und vermischt mit allen anderen Geräten. Selbst von Leuten, die hinsichtlich WLAN weniger kritisch eingestellt sind, wird so eine getrennte Architektur tendenziell empfohlen...

Guter Ansatz. Und wenn man sich da einen einfachen Router mit OpenWRT oder eine günstige FritzBox (z. B. 4020) hinstellt, dann kann man auch die IP Vergabe per MAC Adresse bequem einrichten. Und man hätte nicht nur den WLAN Bereich getrennt, sondern auch den verkabelten gleich mit.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Beta-User

Zitat von: r00t2 am 23 Januar 2019, 13:15:18
Guter Ansatz. Und wenn man sich da einen einfachen Router mit OpenWRT oder eine günstige FritzBox (z. B. 4020) hinstellt, dann kann man auch die IP Vergabe per MAC Adresse bequem einrichten. Und man hätte nicht nur den WLAN Bereich getrennt, sondern auch den verkabelten gleich mit.
Na ja, das hat halt auch wieder mehrere Haken:
- Es setzt u.a. voraus, dass alle WLAN-Geräte von der "günstigen" aus erreicht werden können. Dann kann man vielleicht überlegen, ob in so einem Umfeld der FHEM-Server nicht direkt als separater AP herhalten soll (läuft eh', und sowas unter Linux einzurichten, scheint nicht sooo schwer zu sein, jedenfalls wenn man den sonstigen Aufwand drumrum sieht).
- OpenWRT&Co ist ok, aber Fritte als AP ist generell nicht optimal (ich will das hier nicht vertiefen, es gibt dazu aber einige Threads...)

Die, die sich wirklich mit sowas auskennen, scheinen eher in Richtung vLAN zu tendieren und an allen relevanten Stellen "ordentliche" Hardware zu verwenden (wenn ich das richtig verstanden habe, ich bin kein Netzwerkexperte; u.A., weil ich mir das nicht auch noch antun will, verwende ich eben andere Transport-Layer als grade WLAN, womit wir wieder beim Thema wären...).

@TE: Warum sprichst du mit den Geräten eigentlich nicht mit dem hostname? Der sollte doch fest sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

accloginsell

Zitat von: Beta-User am 23 Januar 2019, 13:31:45
Na ja, das hat halt auch wieder mehrere Haken:
- Es setzt u.a. voraus, dass alle WLAN-Geräte von der "günstigen" aus erreicht werden können. Dann kann man vielleicht überlegen, ob in so einem Umfeld der FHEM-Server nicht direkt als separater AP herhalten soll (läuft eh', und sowas unter Linux einzurichten, scheint nicht sooo schwer zu sein, jedenfalls wenn man den sonstigen Aufwand drumrum sieht).
- OpenWRT&Co ist ok, aber Fritte als AP ist generell nicht optimal (ich will das hier nicht vertiefen, es gibt dazu aber einige Threads...)

Die, die sich wirklich mit sowas auskennen, scheinen eher in Richtung vLAN zu tendieren und an allen relevanten Stellen "ordentliche" Hardware zu verwenden (wenn ich das richtig verstanden habe, ich bin kein Netzwerkexperte; u.A., weil ich mir das nicht auch noch antun will, verwende ich eben andere Transport-Layer als grade WLAN, womit wir wieder beim Thema wären...).

@TE: Warum sprichst du mit den Geräten eigentlich nicht mit dem hostname? Der sollte doch fest sein...

Das mit dem WLAN habe ich mir schon länger überlegt. Evtl ist es jetzt noch mehr Anreiz dies zu tun..

Die Hostnamen haben mich aber jetzt schon einen Schritt weitergebracht. 2 von 3 geräten funktionieren nun. Das andere will keinen Hostnamen haben.

Grüße

Beta-User

Zitat von: accloginsell am 23 Januar 2019, 15:02:27
Das mit dem WLAN habe ich mir schon länger überlegt. Evtl ist es jetzt noch mehr Anreiz dies zu tun..
Nur zu ::) .

Zitat
Die Hostnamen haben mich aber jetzt schon einen Schritt weitergebracht. 2 von 3 geräten funktionieren nun. Das andere will keinen Hostnamen haben.
Wenigstens das sollte man konfigurieren können, ansonsten ist spätestens das ein Fall für's Zurücksenden oder _Wegwerfen_ (wenn man nicht schon die fehlende Option für eine feste IP als ausreichend ansieht...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files