Separaten 1-Wire RPI koppeln mit 2 FHEM-Instanzen

Begonnen von Omega, 07 November 2017, 15:58:27

Vorheriges Thema - Nächstes Thema

Omega

Aktuelle Installation:
Ein 1-Wire-Busmaster (DS9490R) läuft auf einem externen (alten) RPI, auf dem OWFS installiert ist.
Mein FHEM selber läuft in einer VM auf anderer Hardware. Der Zugriff von FHEM (1. Instanz) über OWServer (Def: 192.168.0.20:4304 ) auf den 1-Wire-RPI  funktioniert problemlos.

Mein Ziel ist es, die 1-Wire-Daten auch auf einer 2. FHEM-Instanz zur Verfügung zu haben.
Gibt es dafür eine Lösung? Wobei die Daten nicht über eine Kopplung (z.B. FHEM2FHEM) weitergeben werden sollen.

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

Prof. Dr. Peter Henning

Was soll das denn bewirken ? Dass die beiden OWFS-Abfragen sich gegenseitig in die Quere kommen ?

LG

pah

eldrik

Zitat von: Omega am 07 November 2017, 15:58:27
Mein Ziel ist es, die 1-Wire-Daten auch auf einer 2. FHEM-Instanz zur Verfügung zu haben.
Gibt es dafür eine Lösung? Wobei die Daten nicht über eine Kopplung (z.B. FHEM2FHEM) weitergeben werden sollen.

LG
Holger

Hi,

ein mögliches Vorgehen wäre jetzt auf der zweiten Instanz eine weitere OWServer Definition zu erstellen, die per autocreate erneut OWDevice Geräte erzeugt und selbständig eigene Abfragen startet.

Die berechtigte Frage ist jedoch, was damit verfolgt werden soll und warum hier ein fhem2fhem zur reinen Duplizierung der Daten nicht ausreicht?

Soll hier eine Fhem Redundanz geschaffen werden, um z.B. ein kontinuierliches Logging, in eine Datenbank, beim Wegfall der ersten Fhem Instanz zu ermöglichen? Dann müsste, im Umkehrschluss, auch die eigentliche 1Wire Anbindung, an den Bus, redundant ausgelegt werden.

Da die Anfragen beider Instanzen an den owserver auf dem RPI gerichtet werden, würde ich davon ausgehen, dass dieser die Anfragen nach Eingang selber queued und abarbeitet, so dass die Abfragen sich nicht direkt, in die Quere kommen würden, die Abfragelast auf den Bus würde dadurch jedoch zunehmen, welches sich ggfs. in gestiegenen Antwortzeiten äußern könnte.

Greetz
Eldrik

Omega

Momentan betreibe ich nur Gedankenspiele. Die reine HW möchte ich etwas von FHEM abkoppeln. Z.B. ist es bei ESPEasy problemlos möglich, 2 FHEM-Instanzen parallel zu versorgen. MySensors kann das auch.
Wenn ich 1-Wire per OWServer benutze, kann ich parallel per http auch auf die Daten zugreifen - und nichts geht kaputt. Bei meinen 13 Sensoren wird sich die Bus-Belastung wohl auch in überschaubaren Grenzen bewegen.
Zumindest früher gab es Programme, die die serielle Schnittstelle virtualisiert haben und sie mehreren Anwendungen parallel zur Verfügung gestellt haben. So konnte ich meine empfangenen GPS-Daten gleichzeitig an unterschiedliche Anwendungen weiterreichen.
FHEM2FHEM möchte ich nicht benutzen, da ich - soweit möglich - keine Abhängigkeiten untereinander haben möchte.

Wenn es nicht funktioniert - auch gut. Aber evtl. gibt es ja Lösungen. Die würde ich mir dann gerne mal anschauen.

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

eisman

Hi,

alternative MQTT


ich habe 2 FHEM installationen auf VM (+1 MQTT)

2x RPI für Umweltdaten und andere Sensoren die an MQTT geliefert werden
(Anzeigen,Bedienung usw...)
so muss ich nicht alle Daten 2x erfassen

gruss
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S