Wert an einen anderen iobroker senden?
-
Hallo,
ich wollte euch fragen wie ich am besten einen Wert vom DP xyz (iobroker 2) an einen anderen iobroker 1 der sich im selben Netzwerk befindet senden kann bzw. der iobroker 1 holt sich alle x Sekunden den Wert vom DP xyz vom iobroker 2.
Ich will bewusst kein multihost in diesem Fall.
-
Hallo,
ich wollte euch fragen wie ich am besten einen Wert vom DP xyz (iobroker 2) an einen anderen iobroker 1 der sich im selben Netzwerk befindet senden kann bzw. der iobroker 1 holt sich alle x Sekunden den Wert vom DP xyz vom iobroker 2.
Ich will bewusst kein multihost in diesem Fall.
@saeft_2003
Wenn es nur wenige Datenpunktwerte sind: ioBroker.simple-api -
Hallo,
ich wollte euch fragen wie ich am besten einen Wert vom DP xyz (iobroker 2) an einen anderen iobroker 1 der sich im selben Netzwerk befindet senden kann bzw. der iobroker 1 holt sich alle x Sekunden den Wert vom DP xyz vom iobroker 2.
Ich will bewusst kein multihost in diesem Fall.
-
@saeft_2003
Wenn es nur wenige Datenpunktwerte sind: ioBroker.simple-apiDanke an den simple-api adapter hab ich auch schon gedacht. was genau bedeutet wenige? Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will. Bei manchen langen alle 5 min oder noch mehr, bei anderen sollten es zwischen 10 und 30 Sekunden sein.
Meinst du das wäre ok?
-
Danke an den simple-api adapter hab ich auch schon gedacht. was genau bedeutet wenige? Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will. Bei manchen langen alle 5 min oder noch mehr, bei anderen sollten es zwischen 10 und 30 Sekunden sein.
Meinst du das wäre ok?
@saeft_2003 sagte: Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will.
Polling? Man kann bei Wertänderung senden: Skript beim Sender; Simple-API beim Empfänger.
Gehen alle Werte nur in eine Richtung? -
@saeft_2003 ,
bei vielen Datenpunkte am Besten mit einem MQTT-Server(Mosquitto), da kann dir @mickym weiterhelfen.Ok danke, stimmt per MQTT wäre auch noch eine Lösung. Ich frag mich nur wie kompliziert das ist, weil bis auf die Standardgeschichten bin ich mit MQTT nie richtig warm geworden...
-
@saeft_2003 sagte: Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will.
Polling? Man kann bei Wertänderung senden: Skript beim Sender; Simple-API beim Empfänger.
Gehen alle Werte nur in eine Richtung?@paul53 sagte in Wert an einen anderen iobroker senden?:
@saeft_2003 sagte: Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will.
Polling? Man kann bei Wertänderung senden: Skript beim Sender; Simple-API beim Empfänger.
Gehen alle Werte nur in eine Richtung?Das wäre natürlich perfekt wenn nur bei Wertänderung gesendet wird. Und ja die Werte gehen nur in eine Richtung. Da hört sich für mich dein Plan schon echt gut an
das muss ich in Ruhe Abends mal ausprobieren. -
@paul53 sagte in Wert an einen anderen iobroker senden?:
@saeft_2003 sagte: Ich bräuchte so ca. 20-30 DP die ich unterschiedlich oft abfragen will.
Polling? Man kann bei Wertänderung senden: Skript beim Sender; Simple-API beim Empfänger.
Gehen alle Werte nur in eine Richtung?Das wäre natürlich perfekt wenn nur bei Wertänderung gesendet wird. Und ja die Werte gehen nur in eine Richtung. Da hört sich für mich dein Plan schon echt gut an
das muss ich in Ruhe Abends mal ausprobieren. -
Also Polling würde ich auf keinen Fall machen - bei dem zu sendenden Teil würde ich dann den mqtt-client nehmen, dort kann man dann über das Zahnrad quer über den ganzen iobroker einzelne Datenpunkte (bei 20-30 DP ist das easy) auswählen, während man bei dem anderen Adapter eher ganze Namensräume verwendet.
Bei dem Client kann man dann auch angeben, ob man nur Änderungen übertragen will oder auch Aktualisierungen (ist ja für das Triggern manchmal durchaus sinnvoll):
Man published also nur und sagt nur Änderungen:
Der Client hat auch den Vorteil, dass Du völlig frei bist unter welchem topic der Wert gepublished werden soll. DU MUSST ABER andere topic Namen verwenden - also nicht die, die Dir vorgegeben werden, wenn diese von einem mqtt-Adapter wieder importiert werden sollen. Das kann man ggf. auch mit einem Prefix erreichen, der automatisch vorne dran gehängt wird. Der mqtt-Empfänger akzeptiert in der Regel keine topics, die den Namensräumen von Adaptern entsprechen. (ggf. Ausprobieren).
Auf der Empfängerseite betreibt man den anderen mqtt- Adapter als Broker. Oder falls man mqtt vermehrt verwenden will und auch auf der Empfängerseite mal mqtt publishen will als Client zu einem mosquitto Broker.
Pollen würde ich aber in keinem Fall, deswegen finde ich den Vorschlag von @Wal, hier mqtt zu verwenden, schon am sinnvollsten.
Aufpassen musst Du halt nur wieder mit den Pseudo Adaptern, die mqtt-Broker simulieren - also shelly Adapter, sonoff etc. dann halt aufpassen, dass keine Portkonflikte auftreten und halt freien Port anstelle des Standards 1883 verwenden.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
Also Polling würde ich auf keinen Fall machen - bei dem zu sendenden Teil würde ich dann den mqtt-client nehmen, dort kann man dann über das Zahnrad quer über den ganzen iobroker einzelne Datenpunkte (bei 20-30 DP ist das easy) auswählen, während man bei dem anderen Adapter eher ganze Namensräume verwendet.
Bei dem Client kann man dann auch angeben, ob man nur Änderungen übertragen will oder auch Aktualisierungen (ist ja für das Triggern manchmal durchaus sinnvoll):
Man published also nur und sagt nur Änderungen:
Der Client hat auch den Vorteil, dass Du völlig frei bist unter welchem topic der Wert gepublished werden soll. DU MUSST ABER andere topic Namen verwenden - also nicht die, die Dir vorgegeben werden, wenn diese von einem mqtt-Adapter wieder importiert werden sollen. Das kann man ggf. auch mit einem Prefix erreichen, der automatisch vorne dran gehängt wird. Der mqtt-Empfänger akzeptiert in der Regel keine topics, die den Namensräumen von Adaptern entsprechen. (ggf. Ausprobieren).
Auf der Empfängerseite betreibt man den anderen mqtt- Adapter als Broker. Oder falls man mqtt vermehrt verwenden will und auch auf der Empfängerseite mal mqtt publishen will als Client zu einem mosquitto Broker.
Pollen würde ich aber in keinem Fall, deswegen finde ich den Vorschlag von @Wal, hier mqtt zu verwenden, schon am sinnvollsten.
Aufpassen musst Du halt nur wieder mit den Pseudo Adaptern, die mqtt-Broker simulieren - also shelly Adapter, sonoff etc. dann halt aufpassen, dass keine Portkonflikte auftreten und halt freien Port anstelle des Standards 1883 verwenden.
@mickym sagte: bei dem zu sendenden Teil würde ich dann den mqtt-client nehmen
Man benötigt dafür den Adapter ioBroker.mqtt-client, der Ressourcen verbraucht, was sich bei vielen zu sendenden Werten lohnt. Bei nur einigen zu sendenden Werten genügt Javascript, das ohnehin meist installiert ist.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB -
@mickym sagte: bei dem zu sendenden Teil würde ich dann den mqtt-client nehmen
Man benötigt dafür den Adapter ioBroker.mqtt-client, der Ressourcen verbraucht, was sich bei vielen zu sendenden Werten lohnt. Bei nur einigen zu sendenden Werten genügt Javascript, das ohnehin meist installiert ist.
@paul53 Na ja - aber das Pollen kostet auch Ressourcen, aber indem Fall hast Du ja Recht, da ja nur in eine Richtung gesendet wird (wäre kein Pollen erforderlich, weil die Datenpunkte auf der Senderseite ja triggern würden).
Allerdings wenn auf der zu sendenden Seite gar kein Javascript Adapter benötigt wird, dann hebt sich das mit dem mqtt--client Adapter auch wieder auf. Insofern ist das nicht zwingend der Fall. Man erspart sich halt jegliches Codieren.
Gibt auch Leute, die den JS Adapter nicht brauchen sollten. ;) - Außerdem kann er das ja auf der Empfängerseite verarbeiten. Allerdings dort muss dann ein Broker oder Client verfügbar sein. Nur manche - so wie ich nutzen - mqtt auch zur Kommunikation mit anderen Geräten.
Im Übrigen finde ich den Resourcenverbrauch nicht sonderlich hoch. Aber egal-
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@paul53 Na ja - aber das Pollen kostet auch Ressourcen, aber indem Fall hast Du ja Recht, da ja nur in eine Richtung gesendet wird (wäre kein Pollen erforderlich, weil die Datenpunkte auf der Senderseite ja triggern würden).
Allerdings wenn auf der zu sendenden Seite gar kein Javascript Adapter benötigt wird, dann hebt sich das mit dem mqtt--client Adapter auch wieder auf. Insofern ist das nicht zwingend der Fall. Man erspart sich halt jegliches Codieren.
Gibt auch Leute, die den JS Adapter nicht brauchen sollten. ;) - Außerdem kann er das ja auf der Empfängerseite verarbeiten. Allerdings dort muss dann ein Broker oder Client verfügbar sein. Nur manche - so wie ich nutzen - mqtt auch zur Kommunikation mit anderen Geräten.
Im Übrigen finde ich den Resourcenverbrauch nicht sonderlich hoch. Aber egal-
-
Danke für den vielen Input. Ich setzt mich in den nächsten Tagen (im Moment leider wenig Zeit) und probiere das ganze mot try and error aus…
Ich denke dass dann nochmal die ein oder andere Rückfrage von mir kommen wird.
Aber soweit schon mal vielen Dank 😊👍
-
Das ganze läuft jetzt per simple api und js. Bin selber überrascht von mir das ich das auf anhieb hinbekommen habe 😂 trotzdem natürlich vielen dank 😊👍
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden569
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge