FHEM Forum

Hallo,

ich habe vor langer zeit versucht meine it-1500 Steckdosen auf dem pi mit coc-modul über fhem2fhem vom cubietruck aus zu schalten.
dies geht nicht wie ich feststellen musste:

Zitat von: rudolfkoenig am 23 Februar 2014, 19:50:16
Das IT Modul ist nicht FHEM2FHEM:RAW faehig, da es einen direkten Zugriff auf das drunterliegende IODev benoetigt, um per get raw Kommandos abzusetzen. FHEM2FHEM:RAW faehige Module kommunizieren nur per IOWrite bzw. Dispatch mit dem IODev.

bei meiner Lösungssuche ist dies Modul (in Anlehnung an fhem2fhem) entstanden das von einer Instanz in die andere befehle über telnet sendet.
diese möchte ich hier bereitstellen falls auch andere eine einfache Möglichkeit suchen fhem mit fhem anzusteuern, die devices/module aber nicht von fhem2fhem unterstützt werden

define syntax:

define <name> RFHEM host[:port] [pw]
wir kein port angegeben wird 7072 genommen

ihr erhaltet ein device über das ihr per

set <name> cmd <befehl> fhem-befehle senden könnt.


Attribut RFHEMdevs : eine Komma getrennte Liste von Devices. Alle events dieser Devices werden autom. an die entfernte Instanz weitergeleitet (sprich wenn deviceX ein event wie temperature: 29.3 generiert, wird ein "set rfhem_device cmd setreading deviceX  temperature 29.3" angesetzt).



beispiel: IT-Steckdosen vom cubie der über kein Funkmodul verfügt schalten. das Modul sitzt auf dem pi

# pi remote
define RemotePI RFHEM christian-pi testpw1

den schalter habe ich als dummy realisiert
# remote steckdosen
define wz.LichtschlauchDummy dummy
attr wz.LichtschlauchDummy devStateIcon on:message_socket_on2 off:message_socket_off2
attr wz.LichtschlauchDummy setList on off


wird er betätigt greift ein notify welches den befehl, den man auf dem pi eingeben würde , vom cubi an den pi sendet:
define LichtschlauchNotify notify wz.LichtschlauchDummy { fhem "set RemotePI cmd set Wohnzimmer.Lichtschlauch $EVENT" }

einfache befehle funktionieren, richtige Syntax vorausgesetzt:
schalter schalten
set RemotePI cmd set wz.* on
readings eines dummys setzen
set RemotePI cmd setreading KS300Dummy 'T: 12.1 H: 72 W: 8.6 R: 1.8'
dummy definieren
set RemotePI cmd define dummy dummy
einfache notifys erstellen
set RemotePI cmd define b3lampV1 notify btn3 set lamp on
set RemotePI cmd define b3lampV1 notify btn3 {}
einfache ats definieren
set RemotePI cmd define a1 at 17:00:00 set lamp on 
set RemotePI cmd define a1 at 17:00:00 {}

komplexe Sachen mit Perl-code wie set RemotePI cmd define a1 at 17:00:00 {fhem("set xyz on");} gehen nicht da fhem("set xyz on"); von fhem gleich versucht wird auszuführen ...
ich habe heute bei mir ein telnet Passwort vergeben und das Modul darauf angepasst, funktioniert also auch. nur ssl-auth ist nicht gegeben wie fhem2fhem

da ich nicht alle befehle testen kann (und auch nicht kenne) wäre eine Rückmeldung gut was geht und was nicht.
Nutzung auf eigene Gefahr,  programmiere nur aus spass an der sache und als "fortgeschrittener leihe"  :-)

es läuft bei mir seit februar täglich und stabil auf 3 kisten die sich so unterhalten
Mittlerweile hat es das Modul ins FHEM update geschafft und steht somit per update zur Verfügung
gruß

christian

Hi,

gleich mal getestet, funktioniert prima, ich habe meine IT Devices, am Pi mit COC im Keller, bisher per absetzen der Befehle über die Web URL abgesetzt, deine Lösung finde ich aber vom Aufbau her angenehmer :)

Greetz
Eldrik

danke für die Rückmeldung.
noch ein hinweis:
in Verbindung mit fhem2fhem im log-modus kann man am Hauptsystem auch gleich die Meldungen des remote-systems sehen ;-) und ggf drauf reagieren ...
auch in vebindung mit clone dummy sind sicher noch so einige sachen möglich

Moin chris1284,
danke, dass Du es ansprichst, das wäre auch mein Gedankengang gewesen, dass man mit einem angepassten RFHEM aus der "nur Lesen" Funktion des cloneDummys eine "lesen und schreiben" Funktion bauen kann, also quasi einen "richtigen clone" eines entfernten Devices.
Ich werde mir das auch mal ansehen, wie man das eventuell kombiniert bekommt.

Gruß Joachim

ich hätte noch einen vorschlag...

wie wäre es wenn wir versuchen den cloneDummy, RFHEM und den readingsProxy zu einem modul zusammen zu fassen?

ist zustand:
cloneDummy: kopiert mehrere readings aus einem device in ein neues, remote oder lokal
RFHEM: sendet kommandos von lokal an remote, im prinzip die gegenrichtung zu cloneDummy
readingsProxy: splittet ein reading oder ein teil eines readings in ein neues device, kann senden und empfangen

es gibt zwischen allen drei modulen überschneidungen und bereiche die sehr ähnlich sind und ich kann mir einige szenarien vorstellen bei denen jeweils zwei der module zusammen sinnvoll sind bzw in denen die kombinierte funktionalität aus  zwei modulen gebraucht wird.

gruss
  andre

moin andre,

readingsProxy kenne und nutze ich nicht. muss ich mir mal ansehen.
aber ansonsten gute idee. bin gerne bereit an einer höheren kompatibilität  mit anderen modulen mitzuwirken / mein modul auch ganz in ein anderes zu packen wenn es weiter hilft

noch ein paar gedanken meiner seits:

für mich ist RFHEM eigentlich eine Komponente die in fhem2fhem gehört, leider hat  rudolfkoenig mir hier damals nicht mehr geantwortet http://forum.fhem.de/index.php/topic,20621.msg141658.html#msg141658 , also wurde ich selbst aktiv.

das thema fhem-instanzen zu verbinden kann noch viel weiter gehen, auch was redundanz, ausfallsicherheit usw angeht:
- fhem2fhem im log modus um logs event mitzubekommen / in andere instanzen zu übertragen
- fhem2fhem für raw, rfhem für normale befehle (wenn rfhem in fhem eingeht wäre es nur ein modul )
- clonedummy um devices zu spiegeln
- evtl. alle instanzen eine configdb in der man configs pro instanz unterscheiden kann + eine logdb für alle + redundanz dieser auf allen system (alle schlafen bis die main ausfällt) -> hier weis sich nicht ob dann noch fhem2fhem im log-modus benötigt wird
- warum in einem clonedummy nicht per devIO das rfhem-device setzen so das befehle je nach defIO direkt an die andere instanz gehen ohne den befehl in notifys rammen zu müssen

aber das ist alles wunschdenken / evtl nicht machbar und so umfangreich das sich erst mal einige entwickler zusammensetzen und auf einen weg einigen müssten

Ich muss mal ganz doof dazwischen Fragen. Ich hab zur Zeit nur CULs und möchte davon gerne einen irgendwie zum quasi CUN machen, an dem Bestimmungsort ist auch eine Fritzbox. Schön wäre, wenn man die Geräte von einer entfernten FHEM Installation in die eigenen einbinden kann. Ich weiß nicht ob sowas über IODev möglich ist?!
So ein bisschen wie das hier: http://www.fhemwiki.de/wiki/CUL_ueber_Netz nur das ich das mit allem möglichen machen kann. Ich kann den Aufwand dafür aber auch gar nicht einschätzen.
Wobei ich auch noch mal schauen wollte ob es socat auf der FB gibt.
Aber ich denke das würde die ganze Bastelei mit FHEM2FHEM, CloneDummy und jetzt RFHEM doch beseitigen oder? Also quasi eine Ebene tiefer anzusetzten?!

das ist normalerweise eine ebene tiefer.

schau dir mal ser2net an.

gruss
  andre

das ganze in richtung replikation und ausfall sicherheit weiter zu entwickeln wäre dann ein nächster schritt. und das mit dem IODev gefällt mir. um das aber richtig und für alle devices so transparent wie möglich zu machen ein ziemlicher aufwand. da wäre es interessant zu wissen wie groß der bedarf dafür ist. nicht das etwas sehr komplexes daraus wird das dann keiner benutzt.

unabhängig davon wäre es aber glaube ich ein erster schritt die drei module so nahe wie möglich zu bringen. ob das dann am ende ein oder zwei module werden oder drei bleiben wird sich zeigen. aber nachdenken und ansehen sollte man. die überschneidungen sind schon da und wenn nichts anderes dabei raus kommt das die dokumentation aufeinander verweist und sich gleiches auch gleich verhält und heißt.

gruss
  andre

Also wenn ich mir http://fhem.de/stats/statistics.html anschaue gibt es schon viele FHEM2FHEM Installationen. Ich selbst habe 3, zur Zeit auf dem raspbi noch die Hauptinstallation, dann in einer VM am Stromzähler und auf der Fritzbox für die ganzen Fritzboxfunktionen. Das wäre schon schön, wenn ich das alles direkt in der Hauptinstallation machen könnte. Wobei die FB vermutlich eher nicht geht.

Hi,

also ich setzte derzeit drei fhem2fhem Installationen ein, eine um meinen Pi mit COC und IT Geräten im Keller an meinen Mac Mini Server anzubinden und neben der Hauptinstanz auf dem Mac Mini Server zwei weitere FHEM Instanzen als fhem2fhem zur Anbindung der jeweils im OG und EG aufgestecken Pi 1Wire Adapter über OWServer, für alle 1Wire fhem2fhem Instanzen wird cloneDummy, readingsProxy und neuerding RFHEM eingesetzt.

Daher fände ich die Bestrebungen sehr interessant sämtliche Aktoren, über die Hauptinstanz steuern zu können, ohne hier eine weitere OWServer Verbindung zu einem der Pis herstellen zu müssen (die selten abgefragt aber für das jetzige Steuern der z.B. Rollladenaktoren über die Hauptinstanz zwingend benötigt wird).

Die Verbindung plane ich jetzt auch, neben der bereits mit RFHEM ersetzten alten Lösung zur Steuerung meiner IT Devices, auf RFHEM umzustellen.

Edit: Via RFHEM habe ich nun auch meine 1Wire Rollladenaktoren umgestellt und die Steuerung funktioniert nach den ersten Tests wie bei einem direkten define einer OWServer Instanz auf meiner Hauptinstanz

Greetz
Eldrik

Moin @ all,
Moin chris1284, Moin andre,

habe mal eben nur die commandref zu readingsProxy überflogen, und habe auch noch nicht mit RFHEM gespielt,
aber
ich glaube die Idee von Andre ist nicht schlecht. Komme mir vor, wie der Zauberlehrling (die Geister, die ich rief).

die Module cloneDummy und readingsProxy sind aus verschiedenen Beweggründen entstanden, machen aber fast das gleiche, und müssten sich eigentlich komplett zusammenführen lassen, einzig ihnen fehlt das richtige Backend um entfernte FHEM-Installationen zu bedienen.
die Module FHEM2FHEM und RFHEM wären die richtigen Backends dazu, die man eigentlich auch zusammenfassen kann.
Da wäre dann "nur" noch die Schnittstelle zu cloneDummy/readingsProxy nötig, um Daten an der Hauptschleife von FHEM vorbei an die Frontends zu übertragen. Sowie eine Schnittstelle, die die richtigen Daten (was kann das Modul auf dem lokalen/entfernten FHEM) an die Fronends überträgt.
So war damals eigentlich auch meine Grundidee, als cloneDummy entstanden ist.
Wenn daran Interese besteht, sollten wir dafür aber einen eigenen Thread aufmachen.

OT:
@ andre,
hattest Du Dir die gänderte cloneDummy version mal angesehen, kann die so eingecheckt werden?

Gruß Joachim

ich habe inzwischen im wiki mit ein paar beispielen zum readingsProxy angefangen.

der haupt interschied zwischen cloneDummy und readingsProxy ist glaube ich zur zeit das ersterer mit mehr als einem reading funktioniert, es immer 1:1 durch reicht und nur in eine richtung funktioniert, letzterer zur zeit nur mit einem reading oder einem teil aus einem reading und es die möglichkeit gibt es beim durchreichen in jede richtung zu manipulieren. intern ist da schon sehr viel ähnlich. ein rfhem (oder ein bidirektionales fhem2fhem) als iodev könnte ich mir gut vorstellen. sicher hat rudi auch eine meinung :).

die letzte version vom cloneDummy muss ich mir noch anschauen.

gruss
  andre

@ Andre,
die Meinung von Rudi glaube ich zu kennen.
"Wenn sich ein neuer Maintainer für FHEM2FHEM findet, könnt ihr das machen" ;D

warten wir mal auf die Rückmeldung von chris1284.

Gruß Joachim

:)

es gibt ja auch die option ein bidirektionales rfhem zu bauen und fhem2fhem ganz in ruhe zu lassen.

Das wäre Plan "B",
wobei ich aber der Meinung bin, dass FHEM mittlerweile unter einer "Modulitis" leidet, die schon fast behandlungspflichtig ist.

Gruß Joachim

ja. deswegen ja auch die idee die drei module zusammen zu fassen :)

gruss
  andre

Zitat von: Joachim am 16 Mai 2014, 15:02:10
@ Andre,
die Meinung von Rudi glaube ich zu kennen.
"Wenn sich ein neuer Maintainer für FHEM2FHEM findet, könnt ihr das machen" ;D

warten wir mal auf die Rückmeldung von chris1284.

Gruß Joachim

moin ihr zwei,

ich hätte nichts gegen eine zusammenführung rfhem/fhem, das wär denke ich sogar recht einfach da rfhem auf fhem2fhem basiert / davon abgeschaut wurde.
wenn es aber darauf hinaus läuft das ich dann fhem2fhem komplett allein machen müsste... puh, ich habe jetzt noch nicht alles von dem modul nachvollziehen können. wenn rudi sich mit einklinken würde wäre das sicher hilfreich um herauszufinden woran man ist (will er es? wenn ja wie weit supported er es? gibts kein support hilft er dann dem neuen maintainer trotzdem?).

rfhem als backend für clonedummy/readingsproxy: wenn die die benötigten anpassungen hin bekomme / sie machbar sind, gerne.

fakt, für das zusammenführen gleichartiger / fast identischer / sich seht gut ergänzender module wäre ich auch. ich habe auch lieber ein modul definiert als 10 die ich brauchen würde um die selbe aufgabe zu erledigen.

@ chris1284 und andre,
Da alle betroffenen Module (FHEM2FHEM, RFHEM, readingsProxy, cloneDummy) in den Bereich Automatisierung gehören, und chris1284 nach meinem Kenntnisstand noch keine Schreibberechtigung unter developers hat, würde ich vorschlagen:
a) einen neuern Tread zum zusammenführen der Module unter Automatisierung aufzumachen. Da liest Rudi auch eher mit.
b) chris1284 beantragt developerstatus, und die Diskussion geht dann im Developerbereich weiter.

Gruß Joachim

reicht es rudi darum zu bitten per pm?

wenn Du Lösung b) meinst, dann in Deinem Profil die passende Gruppenmitgliedschaft beantragen.


    FHEM Forum »
    Profil von chris1284 »
    Gruppen Mitgliedschaft

Gruß Joachim

Moin,
zum "fernbedienen" meines remote-fhem bin ich bisher ohne ein neues Modul ausgekommen:

#Master-fhem (bei mir Fritzbox):
define macfhem dummy

#Slave-fhem (bei mir mac):
define F2F FHEM2FHEM fritz.box:7072 LOG:macfhem.*
define n_macfhem notify macfhem.* {Log 3, "$NAME: $EVENT";fhem("$EVENT")}
Damit greift der mac (slave) alle Befehle zur Ausführung ab, die auf dem Master (FB) auf das dummy-device "macfhem" gesetzt werden.

Funktioniert tadellos, wenn ich auf der FB (Master) zB absetze
set macfhem set Licht on
Auch das remote-Aufrufen von perl-code tut.

Kann RFHEM mehr?

Gruß, Uli

das wäre eine möglichkeit kommandos ohne neues modul und mit fhem2fhem zu transportieren.

statt einem IODev wäre im clone modul nur ein trigger aufzurufen. z.b. über direkt die setFn im readingsProxy.

das sollte direkt schon so gehen.

gruss
  andre

Hallo UliM,

so jetzt noch mal ausführlich zum Nachmachen:
Wo muss dieses Script eingefügt werden?

Auf dem Master oder Slave oder beide?

Ziel: Ich möchte auf dem Slave eine Lampe aus- und einschalten
Wenn ich untenstehendes Script auf dem Master in die fhem mit der IP des Slaves eintrage, kommt zunächst eine Fehlermeldung.

define n_macfhem notify macfhem.* {Log 3, "$NAME: $EVENT";;fhem("$EVENT")}
Hier muss man wieder dran denken, das man im Editor ein doppeltes Semikolon setzen muss, s.o.

wenn man anschließend ein Befehl in fhem auf dem Master absetzt, z.b. diesen
set macfhem set LCD_Backlight off   
--> LCD_Backlight ist auf dem Slave ... , steht im Log (Verbose 3)

2014.05.17 10:11:24 3: set LCD_Backlight off : Please define LCD_Backlight first
2014.05.17 10:11:24 3: n_macfhem return value: Please define LCD_Backlight first

und es passiert nichts.

Nächste Frage, davon unabhängig: kann ich auch die Revolt-Energiespar-Logs von dem Slave davon abgreifen?

Robin

Zitat von: UliM am 17 Mai 2014, 08:37:12
Moin,
zum "fernbedienen" meines remote-fhem bin ich bisher ohne ein neues Modul ausgekommen:

Code Auswählen Erweitern

#Master-fhem (bei mir Fritzbox):
define macfhem dummy

#Slave-fhem (bei mir mac):
define F2F FHEM2FHEM fritz.box:7072 LOG:macfhem.*
define n_macfhem notify macfhem.* {Log 3, "$NAME: $EVENT";fhem("$EVENT")}
Damit greift der mac (slave) alle Befehle zur Ausführung ab, die auf dem Master (FB) auf das dummy-device "macfhem" gesetzt werden.

Funktioniert tadellos, wenn ich auf der FB (Master) zB absetze

Code Auswählen Erweitern

set macfhem set Licht on
Auch das remote-Aufrufen von perl-code tut.

Kann RFHEM mehr?

Gruß, Uli

der dummy kommt auf das system auf dem du das set ausführst.

das fhem2fhem und das notify kommen auf das system das deinen aktor steuert

mit einem/meherern readingsProxys auf den dummy und einem 'trigger...' in der setFn kannst du dann meherere devices definieren die du remote steuerst.

gruss
  andre

ps: normalerweise würdest du nicht auf dem slave loggen sondern auf dem master.

Zitat von: justme1968 am 17 Mai 2014, 10:18:38
der dummy kommt auf das system auf dem du das set ausführst.

das fhem2fhem und das notify kommen auf das system das deinen aktor steuert

mit einem/meherern readingsProxys auf den dummy und einem 'trigger...' in der setFn kannst du dann meherere devices definieren die du remote steuerst.

gruss
  andre

Danke, André funktioniert auf Anhieb.
Ich kann jetzt damit mein Hintergrund-LCD Licht (Slave) von meinem Add-On vom Master ein- und Ausschalten.

Den dritten Satz habe ich natürlich wieder nicht verstanden, gibts dazu ein Beispiel?
ich möchte meine Revolts-Energie-Meßdosen, die auf meinem Slave via 433 MHz perfekt werkeln, die Daten auf meinem Master weiterverarbeiten und dort IST-Zustände (aktueller Verbrauch) und Plots darzustellen.
Also muss ich irgendwie die Daten vom Slave "abholen" und NUR diese Daten, keine anderen, was sonst noch da rumfleucht.

du definierst einen readingsProxy etwa so:define remoteLCD readingsProxy macfhem:state
attr remoteLCD setList on off
attr remoteLCD setFn {fhem("trigger $DEVICE set LCD_Backlight $CMD") };
attr remoteLCD valueFn {$LASTCMD}

damit hast du dann auf master seite ein richtiges device das du im web frontend anzeigen und per klick bedienen kannst.

die setFn ist noch etwas unhandlich aber ich denke die machen wir noch praktischer und wenn wir den cloneDummy und radingsProxy zusammen fassen wird auch die valueFn durch den echten remote state ersetzt.

für das loggen legest du dir ein fhem2fhem device für die gegenrichtung an das genau nur die events durchreicht die du loggen willst. die werte werden also nicht abgeholt sondern vom slave gesendet.

gruss
  andre

klappt soweit, aber die "Statuslampe" reagiert den Status erst beim zweiten Mal auf "on" oder "off".

Zitat von: justme1968 am 17 Mai 2014, 10:59:50


für das loggen legest du dir ein fhem2fhem device für die gegenrichtung an das genau nur die events durchreicht die du loggen willst. die werte werden also nicht abgeholt sondern vom slave gesendet.

gruss
  andre

Knaller ! Klappt! Ungeahnte Erweiterungsmöglichkeiten, wenn man mehrere Fhems am Laufen hat.
Wie werden die einzelnen Devices, deren Werte übertragen werden sollen, beim Slave getrennt?

So kommen nur die Werte vom ersten Device an
#Slave-fhem (für revolt-devices):
define F2F2 FHEM2FHEM 192.168.178.29:7072 LOG:NASuFritz.* SamsungLC650.*

Zitat von: UliM am 17 Mai 2014, 08:37:12
Kann RFHEM mehr?
Gruß, Uli

hallo uli,

danke fürs moven und aufnahme in developers (falls du das auch warst :-)).
der weg über fhem2fhem geht meines wissens nur mit devices auf dem "slave" die raw können.
siehe zitat von rudi im ersten post:

Das IT Modul ist nicht FHEM2FHEM:RAW faehig, da es einen direkten Zugriff auf das drunterliegende IODev benoetigt, um per get raw Kommandos abzusetzen. FHEM2FHEM:RAW faehige Module kommunizieren nur per IOWrite bzw. Dispatch mit dem IODev.

das betrifft meinen it-1500 die über coc im slowrf bedient werden (ging über fhem2fhem nicht!). des weiteren kann fhem2fhem nur devieces bedienen die auch da sind, über rfhem kannst du neue definieren (zum beispiel dummys, notifys, at usw , du kannst halt alle fhem-befehle (mit einschrenkunge in verbindung mit perl-code im befehl) auf dem slave ausführen

die version von ulli benutz nicht den raw mode sondern den log mode um einfach klartext (also z.b ein komplettes "set <device> on' zu übertragen.

siehe setFn aus dem readingsProxy beispiel.

es gibt (im prinzip) keine einschränkungen dabei.

gruss
  andre

Zitat von: chris1284 am 17 Mai 2014, 13:32:28
der weg über fhem2fhem geht meines wissens nur mit devices auf dem "slave" die raw können.

Hab ich nicht getestet, aber auf dem slave-fhem wird ja der komplette Befehl lokal ausgeführt durch das notify. Das zu schaltende device  auf dem slave wird ja nicht direkt vom master aus angesprochen. Vielmehr wird auf dem slave der ganz normale Befehl abgesetzt.
Ich benutze das eigtl. nur für Automatisierungen, wenn ein at oder notify des master dann ein device auf dem slave schalten soll.

Neue devices auf dem slave definiere ich direkt auf dessen webfrontend.

Ich kann nur berichten dass es bei mir tut, sicher überblicke ich nicht alle Varianten und Anwendungsmöglichkeiten.

=8-)

habs gerade mal geteste, läuft auch ganz gut
(wenn fhem2fhem bei rechtschriebfehler im hostnamen nicht gefühlte 3 stunden das systemblockieren würde nur weil es den host nicht verbinden kann....)
hät ich das vorhe rgewusst (wie denke ich viel eandere auch, siehe die die per weblinks schalten) hät ich mit das modul spaen können :-)

und man fhem2fhem im log: nicht auf beiden instanzen haben ---> dicke endlosschleife

es klappt bei mir sogar ohne notify habe nur fhem2fhem im log:buero.LichtRegalDummy.* laufen auf dem pi
und auf dem master ein buero.LichtRegalDummy definiert. schalte ich den dummy geht auf dem pi das event ein

Zitat2014-05-17 14:32:50 IT buero.LichtRegal on

wie geht das denn?

das ist ja genau das was fhem2fhem im log modus macht. events übertragen.

aber ohne das notify schaltet das device nicht. höchstens das icon in fhemweb.

naja, real ging das licht ja an, nicht nur das icon. grund war nach einigem suchen ein verirrtes notify auf dem testsystem....

was noch negativ an der lösung auffällt: mein pi ist seit einrichtung fhem2fhem LOG:.* extrem langsam. mit fhem2fhem LOG:<device>:.* geht es aber ich lege doch nicht für jedes device welches ich "sehen" will ein fhem2fhem device an. gib es in der hinsicht eine idee die performance zu verbessern?

fhem2fhem auf beiden seiten im logmodus geht garnicht. beide instanzen müllen sich zu mit events und schieben sich jedes hin und her bis nichts mehr geht.
da ich es auf beiden benötige bleibt es wohl bei RFHEM

Zitat von: chris1284 am 17 Mai 2014, 15:48:35
ich lege doch nicht für jedes device welches ich "sehen" will ein fhem2fhem device an

define F2F FHEM2FHEM:7072 LOG:(macfhem.*|wz_Licht.*|wz_Video.*)

=8-)

das readingsProxy beispiel von oben müsste eigentlich auch bidirektional funktionieren wenn man eine fhem2fhem verbindung für den rückweg hat und den proxy nicht auf den dummy definiert sondern auf den namen des original device definiert.

die setFn müsste man anpassen weil sich ein paar namen ändern aber ansonsten sollte es tun...

Zitatich lege doch nicht für jedes device welches ich "sehen" will ein fhem2fhem device an

in die richtung die zum steuern verwendet wird brauchst du nur ein fhem2fhem pro remote system. das ist genau gleich wie bei rfhem.
in die richtung die empfängt brauchst du ein fhem2fhem das auf alle devices die du empfangen möchtest matched. das ist genau so wie bei cloneDummy.


wie sollen wir weiter machen?

ich würde den fhem2fhem weg mit notify vorschlagen. oder sieht jemand etwas das damit nicht geht?


wie ist es mit dem cloneDummy und readingsProxy?

ich könnte readingsProxy auf mehr als ein readings erweitern. das triggern an das remote system geht mit dem obigen setFn beispiel ja schon. sollte man das noch etwas eleganter machen und kapseln?

gruss
  andre

Moin andre,

zum Thema cloneDummy und readingsProxi:
Wollen wir dazu einen neuen Thread aufmachen?
Ich glaube das wäre in diesen Thread OT.
Es geht ja dann auch darum, wie sich die Module/das Modul weiterentwickeln soll.

zu den anderen Ergebnissen:
Hier tun sich ungeahnte Möglichkeiten auf, auch in Verbindung mit Deinem neuen clone-Modul.

Gruß Joachim

Hallo alle,
hab' gerade diesen Thread durchgeblättert, ohne jeden Schritt nachvollziehen zu können. Scheint mir aber irgendwie die Antwort auf meine Frage zu sein: FHTs und FS20-Schalter am FHEM auf dem Raspberry Pi mit SCC (stapelbarer CC1101 Transceiver für Raspberry Pi) vom FHEM auf dem Cubietruck aus zu steuern. FHEM2FHEM schaltet bei mir keine der beiden (FHT und FS20), sondern empfängt nur die FHT-Meldungen.

Bin ich hier richtig, und geht es hier weiter? Die letzte Meldung ist mittlerweile einige Tage alt.

im prinzip geht es noch weiter. ich habe schon eine version von readingsProxy die mit mehr als einem reading läuft. das senden an ein remote system geht mit der weiter oben beschriebenen methode. das empfangen ebenso.

ich weiss aber nicht ob ich das vor dem urlaub noch fertig bekomme.

gruss
  andre

Schließe ich daraus, dass readingsProxy das ist, wonach ich suche? Dann werde ich mich versuchen, da einzulesen.

wenn du dir readingsProxy angeschaut hast (z.b. im wiki) dann schau diese beiden posts an: http://forum.fhem.de/index.php/topic,23638.msg169337.html#msg169337 (http://forum.fhem.de/index.php/topic,23638.msg169337.html#msg169337), http://forum.fhem.de/index.php/topic,23638.msg169368.html#msg169368 (http://forum.fhem.de/index.php/topic,23638.msg169368.html#msg169368). da ist das prinzip der remote steuerung beschrieben.

gruss
  andre

Trotzdem - ich verstehe nicht, warum das bei mir nicht mit FHEM2FHEM funktioniert. Liegt das an den FHTs bzw den FS20?

Könnte man noch event-on-change einbauen?

Hab' die Sache jetzt mittlerweile mittels Zugriff auf die CULs an den Raspberry Pis über netcat realisiert. Somit werden diese CULs vom Cubie angesprochen, als ob sie direkt angeschlossen wären. Einziger Wehrmutstropfen: Im Falle eines Neustarts einer der Komponenten kann es schon mal dauern, bis alles korrekt läuft. Hab an anderer Stelle schon ausführlich berichtet.
http://forum.fhem.de/index.php/topic,21665.msg224495.html#msg224495 (http://forum.fhem.de/index.php/topic,21665.msg224495.html#msg224495)

Zitat von: fh168 am 17 Mai 2014, 11:30:06
klappt soweit, aber die "Statuslampe" reagiert den Status erst beim zweiten Mal auf "on" oder "off".

Hallo zusammen,
habe exakt das selbe Problem wenn ich meine Steckdosen schalten möchte.

Mein Setup in aller kürze:
Master fhem: Intel Nuc
Slave fhem: Banana Pi mit 433mhz TX

Das Schalten funktioniert wunderbar, nur schaltet das Icon erst nach dem zweiten Click auf "ON".
Laut Log scheint etwas mit dem readingsproxy auf dem Master nicht zu passen, beim ersten mal sendet er ein "OFF" statt "ON", beim zweiten mal kommt dann ein "ON".

Log Master:

Zitat2014-12-27 00:27:40 readingsProxy remote_WZ_LedBand off
2014-12-27 00:27:40 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand on
2014-12-27 00:27:41 readingsProxy remote_WZ_LedBand on
2014-12-27 00:27:41 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand on
2014-12-27 00:27:43 readingsProxy remote_WZ_LedBand on
2014-12-27 00:27:43 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand off
2014-12-27 00:27:44 readingsProxy remote_WZ_LedBand off
2014-12-27 00:27:44 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand off

Log Slave:

Zitat2014-12-27 00:27:40 dummy WZ_LedBand on
2014-12-27 00:27:40 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand on
2014-12-27 00:27:41 dummy WZ_LedBand on
2014-12-27 00:27:41 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand on
2014-12-27 00:27:43 dummy WZ_LedBand off
2014-12-27 00:27:43 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand off
2014-12-27 00:27:44 dummy WZ_LedBand off
2014-12-27 00:27:44 dummy RemoteServerBanana_WZ_LedBand set WZ_LedBand off

Config Master:
# - Funksteckdose 01 Wohnzimmer LED-Band Couch
define RemoteServerBanana_WZ_LedBand dummy
attr RemoteServerBanana_WZ_LedBand alias LED-Band
attr RemoteServerBanana_WZ_LedBand room FHEM-Remote

define remote_WZ_LedBand readingsProxy RemoteServerBanana_WZ_LedBand:state
attr remote_WZ_LedBand alias LED-Band
attr remote_WZ_LedBand comment LED Band unter der Couch
attr remote_WZ_LedBand fp_Grundriss 180,926,1,LED-Band
attr remote_WZ_LedBand group Licht
attr remote_WZ_LedBand icon li_wht_on
attr remote_WZ_LedBand room FHEM-Actors,Z-Wohnzimmer
attr remote_WZ_LedBand setFn {fhem("trigger $DEVICE set WZ_LedBand $CMD") }
attr remote_WZ_LedBand setList on off
attr remote_WZ_LedBand valueFn {$LASTCMD}

Config Slave:
# F2F
define RemoteServerNUC FHEM2FHEM 192.168.1.100:7072 LOG:RemoteServerBanana_.*

# LedBand Wohnzimmer Couch
define WZ_LedBand dummy
attr WZ_LedBand alias LED-Band
attr WZ_LedBand comment LED Band unter der Couch
attr WZ_LedBand group Switches
attr WZ_LedBand icon on
attr WZ_LedBand room FHEM-Switches,Z-Wohnzimmer
attr WZ_LedBand setList on off
define off_WZ_LedBand notify WZ_LedBand:off {system("sudo /usr/local/bin/rcsend 11111 1 0 &")}
attr off_WZ_LedBand room hidden
define on_WZ_LedBand notify WZ_LedBand:on {system("sudo /usr/local/bin/rcsend 11111 1 1 &")}
attr on_WZ_LedBand room hidden

#  LedBand remote
define n_RemoteServerBanana_WZ_LedBand notify RemoteServerBanana_WZ_LedBand.* {Log 3, "$NAME: $EVENT";;fhem("$EVENT")}
attr n_RemoteServerBanana_WZ_LedBand room FHEM-Remote

Auf dem Floorplan und in der GUI nutze ich dann "remote_WZ_LedBand" um zu schalten. Ist hier evtl. mein Denkfehler? Müsste ich den RemoteServerBanana_WZ_LedBand Dummy zum schalten nehmen?

Sitz jetzt seit zwei Tagen dran und bin am verzweifeln. Wäre über jede Hilfe dankbar :)

Gruß iro

Zitat von: justme1968 am 17 Mai 2014, 19:53:05
das readingsProxy beispiel von oben müsste eigentlich auch bidirektional funktionieren wenn man eine fhem2fhem verbindung für den rückweg hat und den proxy nicht auf den dummy definiert sondern auf den namen des original device definiert.

Ich stehe auch vor dem Problem, dass ich von einem Raspi lediglich Temperatur-Werte auf mein Master-FHEM übertragen möchte.
Hierfür würde ich auf dem Temperatur-Raspi einen FHEM-Master definieren und mein eigentliches Hauptsystem als Slave dranhängen --> alle Werte wandern in mein eigentliches Hauptsystem.

Nun kann es aber auch sein, dass der Temperatur-Raspi auch Befehle vom eigentlichen Master-FHEM bekommen soll.
Heißt das, dass ich einfach umgekehrt nochmal ein FHEM2FHEM einrichte?

Wie verhindere ich hier eine Art "Endlosschleife"?

Viele Grüße,
Heiko

Hi,

habe das ganze jetzt einfach mir rfhem von chris1284 realisiert und die proxys weggelassen, läuft wunderbar. Danke chris, einfacher hätte es nicht sein können! :D

@heikoh81: Endlosschleifen vermeidest du, indem du nur loggst, was du auch brauchst. Beispiel:

define F2F FHEM2FHEM 192.168.1.100:7072 LOG:RemoteServer_.*|WZ_.*|WasImmerDuMöchtest.*

Nur wenn du alles mit LOG:.* loggst entstehen Loops.

Gruß iro

Wie es der Zufall manchmal so will. Durch Zufall bin ich auf dieses Modul gestoßen, es macht so viele Sachen einfacher und vor allem so viel sparsamer als zB. Fhem2fhem. Vielen Dank für diesen super Modul. Aber eine Frage hätte ich noch, warum checkst du das Modul nicht ein?

als ich es damal genaut und genutzt habe gab es scheinbar nciht so den bedarf...
Ich fand fhem2fhem auch immer zu kompliziert für das wenige was es kann.

da ich jedoch seti langer zeit nur noch einen Server habe und keine verwendung mehr für das modul, wird es schwer es weiter zu supporten und einchecken ohne support(was seit dem hochladen nicht notwendig war  ;D ) wird nicht geduldet / ist nicht erwünscht (verständlicher weise).

Hi,
hab heute versucht via FHEM2FHEM eine 433 Mhz Funktsteckdose über einen zweiten FHEM Server zu schalten
(FHEM2FHEM kann das vermutlich nicht leisten, zumindest konnte ich aus der Wiki nicht erkennen wie das gehen soll).

Bin dann über dieses Forum hier gestolpert .
Hab mir dann das RFHEM Modul vom Anfang dieses Artikel geladen, und 2 Minuten später lief alles wie gewünscht.

Vielen Dank an den(die) Autor(en).

@chris1284:
Eine Anmerkung habe ich noch .
Ich habe verstanden dass du RFHEM nicht supporten kannst/willst.
Aber es wäre eine echte Hilfe wenn das Modul wenigstens auf dem Contrib Verzeichnis eingestellt wäre.

Also nochmal Danke für das Modul !! ;D

Gruß
RaspII

Hi
auch ich habe gestern in kurzer Zeit das RFHEM Modul zum laufen bekommen.

Ich bitte auch das Modul in Contrib bereit zu stellen.

lg
Stefan

offensichtlich wird es genutzt.. ich werde es zum we einchecken

Ich schließe mich mal an.
Derzeit habe ich ja die Raspberries mittel netcat angebunden, da mit FHEM2FHEM die FHTs nicht geschaltet werden können. Das ist zwar sehr angenehm, da die CULs angesprochen warden, als ob sie direct am Cubie (FHEM-Server) stecken würden, und damit auch ganz einfach mal ein Gerät bei Empfangsproblemen von einem zum anderen CU umgelegt warden kann. Allerdings mach ein CUL standing Schwierigkeiten, wenn am entsprechenden Raspie ein Reboot notwendig war. Keine Ahnung was da passiert.

Deshalb spiele ich mit dem Gedanken, dieses Modul doch mal als Ersatz zu verwenden - zumindest für den einen problematischen CUL.

Zitat von: duke-f am 06 Mai 2015, 17:37:10
Ich schließe mich mal an.
... da mit FHEM2FHEM die FHTs nicht geschaltet werden können. .....

Wie meinst Du das? Fht nicht schaltbar?
Ich kenne mich nicht besonders gut aus!
Doch bei mir laufen 5 FHT's über Fhem2fhem "raw!" an einem Raspi-mit-CUL. Hauptsystem ist ein Cubietrunk.
Und über dieses lese ich alle FHT und kann sie auch steuern.

Gruß blueklamo (mit tapatalk) 
geändert                 

Jetzt kann ich das nicht mehr genau nachvollziehen, ist schon eine Weile her. Aber als ich es vor einigen Monaten einrichten wollte, hat es irgendwie nicht funktioniert. Hab' damals lange erfolglos rumgesucht und nichts gefunden. Kannst Du auch die Sollwerte empfangen?

Also ich nutze das Modul seit fast einem Jahr. Es erleichtert die Steuerung über die Instanzen und macht das Ganze auch sehr übersichtlich. Läuft stabil und fehlerfrei. Ich nutze das, um aus der Haupt-Instanz manuell z.B. FS20 und Homematic zu schalten oder, um in der Alarmanlage das Internprogramm zu aktivieren. Kritischere und automatische Steuerungen belasse ich aber in der jeweiligen Instanz. Die Informationen kommen über FHEM2FHEM nach "Oben".

(http://bildschirmfoto%202015-04-18%20um%2019.46.39.png)

Vielen Dank dafür !

LG

Hallo - ich kann 93_RFHEM.pm auf meinem Installation nicht finden, nicht in /fhem/FHEM und nicht in /fhem/contrib. Wurde das Modul doch nicht eingecheckt, inzwischen wieder entfernt, oder bin ich einfach nur blind? ;)
FHEM ist auf dem Stand vom 14.09.2015.

Danke,
Stefan

Hallo,
steht im ersten Post als Anhang.
Gruß Doesel

Hallo Doesel,
danke - meine Frage (wenn's eine war) bezog sich auf den Inhalt/Umfang der FHEM-Installation. Den Anhang aus dem ersten Beitrag hatte ich installiert, klappt auch prima. Nur bekommt man so keine Updates des Moduls mit (falls es mal welche geben sollte).

Gruß,
Stefan

Muss jetzt mal fragen, weil ich Probleme mit einer Installation hatte/habe die ab und an aussetzt.
Arbeitet dieses Modul blockierend?
Was passiert, wenn die zweite fhem Instanz die angesprochen werden soll nicht erreichbar ist?

Grüße Christian

Danke Christian !

die pm hat über 300 Downloads !
ich habe einen Tag mit fhem2fhem rumgespielt, bis ich dass hier gefunden habe.

Gruss
koerly

gibt es die Möglichkeit einzubauen, dass man ein Attribut setzt, ob man jedes Mal im Log den Eintrag "Command executed" sehen möchte? Ich lasse mir sehr viele Daten übertragen, teilweise alle 2 Minuten und da brauche ich nicht jedes Mal die Bestätigung, solange alles läuft :)

Ansonst ein top Modul. Vielen Dank dafür.

ich habe nur eine fhem-instanz und würde es nur ohne test einbauen. einfacher ist es wenn du im modul die zeile Log3 $name, 3, "Command executed"; auskommentierst oder das log-lvl auf 5 setzt

Stimmt, hätte ich auch selbst drauf kommen können. :) Danke

Hallo ich versuche mit deinem Modul vom Haupt fhem einen Befehl auf den 2 Fhem zu senden an dem ich über Infrarot (lirc) meine RGBLED'S steuere.

Am Fhem mit lirc sieht der Befehl so aus
rgbled.* {system("irsend SEND_ONCE RGBLED $EVENT")}

Auf dem Haupt Fhem ohne lirc habe ich es so versucht
rgbled { fhem "set Server cmd set rgbled $EVENT" }

Allerdings wird dann auf dem fhem mit lirc ständig wie in einer schleife der Befehl gesendet. Er soll aber nur einmal gesendet werden.

Zur Erklärung das $EVENT nimmt den Befehl aus einem Dummy wo als attr webcmd die reihe an möglichen befehlen wie ON:OFF:ROT:GRÜN... steht

Wie bekomme ich das ganze jetzt hin one für jeden der 24 befehle ein eigenes notify anzulegen?

Das wird vermutlich schon daran scheitern, dass du keine Perl Befehle mit RFHEM senden kannst. Du willst ja nur die Farbe senden, oder? Dann könntest du es wie folgt machen. Du lässt in der Hauptinstanz, welche den Befehl, welcher über IR kommt in einen Dummy schreiben, alternativ nur die Farbe. Sobald sich das Reading in diesem Dummy ändert, lässt du das Reading per RFHEM an die zweite Instanz schicken. Hier empfängt es ein Dummy. Sobald sich bei diesem Dummy eine Reading ändert, schaltet auf ein Notify, welches den Befehl in Perl ausführt mit den Werten des Dummys.

Grafisch also:

Haupt Instanz: Empfange Farbe über IR -> Farbe in Dummy schreiben -> Notify wird ausgeführt, da sich Reading im Dummy ändert -> Farbe wird mittels RFHEM an zweite Instanz gesendet -> Dummy empfängt Farbe -> Notify wird geschaltet, da sich die Farbe ändert -> notify setzt nun den Perl Befehl ab, mit dem Wert des Dummys.

Verstehe nicht wie ich das umsetzen soll.
Ich schreibe ja im Dummy die farbe.
Ein notify bekommt die Farbe über das $Event aber wie übergebe ich das dann mit RFHEM an die 2. Instanz?

Wenn Screenshots helfen mache ich gerne welche

Die hauptinstanz also der eigentliche Thema Server hat kein Ir, da will ich nur über die grafische Oberfläche die Farbe anklichen. Dieses mache ich in einem Dummy das die Farben als webcmd attr hat. Screen shot 2

Von da soll es an den remote gesendet werden dieser besitzt ir und da klappt es mit dem Dummy und den webcmd attr die dann von einem notify ausgelesen werden und diese dann mit lirc senden screenshot1

Dann habe ich dich falsch verstanden. Ich dachte, dass du den Befehl mittels IR bekommst und dann an FHEM weiter senden willst. Wenn ich dich jetzt richtig verstehe ist was du willst das:

FHEM1 auf Button für Farbe rot klicken -> Rot an FHEM 2 senden -> FHEM2 gibt Befehl über IR an RGB Stripe -> Rot wird geschaltet.


Dann wäre es relativ einfach, wobei die Frage ist, welche Daten in welchem Reading stehen, die gesendet werden sollen. Steht zB nach klicken des Buttons im Reading "state" der Status "rot" und mit rot kann der IR Sender etwas anfangen, dann könnte es so aussehen:

define <name> notify <NameButton> set <Name RFHEM Device> cmd setreading <Name Dummy in FHEM2> $EVENT


damit würde der Name des Readings und der Status des Readings im Dummy auf der anderen Instanz gesetzt werden. Nun musst du bei dieser Instanz nur noch ein Notify auf den Dummy lauschen lassen, der dann den Befehl in Perl absetzt. Perl Befehle kannst du ja leider nicht senden.

---------------------------------
Ich war mal so frei und habe einen Wiki Eintrag für dieses Modul erstellt. Wäre nett, wenn es jemand auf Fehler, sowohl Rechtschreibfehler, als auch inhaltliche Fehler, quer lesen könnte und wenn möglich, gerne auch gleich korrigiert.

Hier geht es zum Wiki Eintrag: http://www.fhemwiki.de/wiki/RFHEM

Also im fhem2 ist ein Notify (n_rgbled)(screenshot1) das lauscht dem Dummy (rgbled)(screenshot2) welches die werte ON:OFF:RED:BLUE:GREEN:........ liefert und dann über Infrarot sendet.

Hoffe ich kann das verständlich erklären.

Jetzt bauste den gleichen Dummy in die andere Fhem Instanz und schickst die Werte, wie oben beschrieben mit RFHEM.

Habe die selben Dummy Bausteine in beiden Instanzen und in der Haupt Instanz von der aus der Befehl an die zweite gehen soll dieses notify (siehe screenshot) aber in der zweiten Instanz passiert nichts.

Syntax ist falsch
... set Server cmd set...

Habe es jetzt so
RGBbottom set Server cmd set setreading rgbled $EVENT

Und so
RGBbottom set Server cmd set reading rgbled $EVENT

Versucht aber bekomme es einfach nicht hin

RGBbottom set Server cmd setreading rgbled $EVENT

Edit:
Hast du den ersten Post dieses Thread mal gelesen, oder den Wiki Eintrag? Kann ich dir nur empfehlen, da müsste es auch klar werden :)

Hallo
Doch ich habe beides gelesen aber irgendwie Blicke ich trotzdem nicht durch weil wenn ich es so schreibe
rgbled set Server cmd set rgbled $EVENT
Dann wird der Befehl jede Sekunde auf dem remote ausgeführt.

Ich verzweifel noch an der Lösung es ist wahrscheinlich so einfach und ich sehe es nicht

Fangen wir mal ganz von vorne an.

FHEM Hauptinstanz:
- Hier ist der Dummy  mit Namen "RGBBottom". Dieser wechselt das Reading "status" durch klicken auf die verschiedenen webcmd. Beispiel hierfür ist "ON","OFF","RED",... Mittels dieses Buttons sollen Befehle an eine zweite FHEM Instanz (FHEM-Server) gesendet werden. Auf FHEM Server wird dann über den IR Sender der Befehl an die Lichterkette gesendet und geschaltet.
- Hier ist ein Notify mit dem Namen "RGBSchalten". Dieses hat folgende Definition:
RGBBottom set Server cmd setreading rgbled $EVENT
Das Notify sendet mittels des Moduls RFHEM den Befehl an die Zweite Instanz und verändert dor den Dummy rgbled.
- Hier ist NICHT der IR Sender angeschlossen

FHEM Serverinstanz:
- Hier ist der IR Sender angeschlossen
- Hier ist ein Dummy mit dem Namen "rgbled". Das Reading "status" wird jedes Mal durch RFHEM gesetzt, wenn auf der Hauptinstanz bei "RGBBottom" der Status gewechselt wird durch klicken.
- Hier ist ein Notify mit dem Namen "n_rgbled". Das Notify hat folgende Definition:
rgbled {system ("irsend SEND_ONCE RGBLED $EVENT")}
Dieses Notify sendet über den IR Sender den Befehl raus an die Lichterkette.

Frage 1:
Ist der Aufbau genau so, wie oben beschrieben?

Frage 2:
Wenn in der Hauptinstanz bei RGBBottom der Status durch klicken von "ON" auf ON gesetzt wird, wird dann auch der Status bei rgbled auf ON gesetzt?

Frage 3:
Passiert gleiches bei allen anderen Status angaben?

Frage 4:
Wenn 1 und 2 mit Ja beantwortet wurden, hat das Reading in "rgbled" nach dem Setzen durch RFHEM einen Doppelpunkt im Name. Dh heißt das Reading dann zB "state:"??

Frage 5:
Gibt es weitere Devices, die rgbled oder RGBBottom steuern?


Keine Angst, wir schaffen das noch ;)

1. Fast richtig auf beiden Instanzen ist der selbe Dummy "rgbled"
2. Ja aber als wiederholungsschleife alle 1 sek und wenn ich erst ON dann OFF sende wechselt er in einer Endlosschleife zwischen den befehlen
3.ja
4.Nein kein :
5. Nein es gibt Bis jetzt nur den Dummy in dem die befehle gegebenwerden kann.

Das Problem ist ja das der Befehl nicht nur 1 mal übergeben wird sondern immer wieder jede sekunde.
Und wenn ich jetzt in der hauptinstanz erst ON und dann ROT und dann BLAU drücke werden die drei befehle im Wechsel immerkt wieder im State beim Server gewechselt wenn ich dann noch am Server auf GRÜN drücke kommt der Befehl auch noch in die schleife.

Hoffe es hilft bei der Fehler suche

Blöde frage, aber hast du auf beiden Instanzen ein RFHEM Device, dass der Status immer rund gegeben wird?

Poste mal ein list der beiden Dummy und der beiden notify. Vorher nenne mal den dummy und das notify aufm Server oder Hauptinstanz um, dass sie nicht gleich heißen. Notifys auch anpassen. Und noch ein list des RFHEM Device auf der Hauptinstanz.

Nein nur auf der hauptinstanz läuft ein RFHEM.

Auf der hauptinstanz heißt der Dummy jetzt ledstrip

Was meinst du mit ein "list" Posten?

Hey super es hat geklappt!

Problem war wahrscheinlich das di Dummys auf beiden Instanzen den gleichen NAMEN hatten.

Danke dir für diesen super Support und deiner geduld!

Na ich bin begeistert, wenn es geklappt hat. Ich verstehe zwar nich nicht, dass es zu einem Loop kam, da bei mir auch die Dummys gleich heißen, aber egal. Hauptsache es klappt erst Mal :)

Hallo chris1284,

kannst du mir weiterhelfen bei der Übergabe eines Temperaturwertes?

Das Beispiel mit den Lichtschläuchen funktioniert wunderbar, nur die Werte übergabe nicht

Was haste denn bisher? Vielleicht können wir dir ja helfen :)

Also auf dem Server Pi habe ich ein dummy angelegt welches brav die Außentemperatur liest
#Außen-Temperatur auslesen#
define AktuelleTemp dummy
attr AktuelleTemp event-on-change-reading state
attr AktuelleTemp room Aussen
define TempUsageAnDummy at +*00:00:05 { my $d= ReadingsVal("KMS","ZT_T2_Ist",0);; fhem("set AktuelleTemp $d")}

Diese Temperatur soll sich nur der Remote Pi holen und damit arbeiten
Also habe ich auf dem Server Pi den Remote Pi angelegt
#RemotePi
define RemotePI RFHEM 192.168.0.55:7072
attr RemotePI room test

Und mit dem notify#Außen-Temperatur übergeben#
define KopieNotify notify AktuelleTemp { fhem "set RemotePI cmd set AktuelleTemp3 $EVENT" }


übegebe ich an das dummy auf dem Remote pi
#Außen-Temperatur auslesen#
define AktuelleTemp3 dummy
attr AktuelleTemp3 room Aussen

Edit: Funzt ::)

Wenn du den Fehler gefunden hast, dann poste ihn doch bitte noch, dass andere diesen vielleicht auch finden können, wenn sie das gleiche Problem haben. Ansonsten freut es mich, dass es geht :)

define KopieNotify notify AktuelleTemp { fhem "set RemotePI cmd set AktuelleTemp3 $EVENT" }

raus in Perl und dann wieder rein in FHEM?

sollte das nicht auch gehen?
define KopieNotify notify AktuelleTemp set RemotePI cmd set AktuelleTemp3 $EVENT

Hallo an den Ersteller des Moduls.

Ich habe mehrere Raspi mit Fhem laufen, unter anderem einen PiZero der momentan noch nur dafür Zuständig ist meine Lüftungsanlage über einen seriellen Adapter zu steuern. Die Befehle dort führe ich bisher per RFHEM aus.

Das Problem: Sobald der PiZero nicht im Netzt erreichbar ist, stürzt auch meine Hauptinstanz, die die Befehle sendet, komplett ab.
Entweder der Pi muss Erreichbar sein, oder ich nehme die .pm raus, erst dann läuft sie wieder.

Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
81 print $socket $msg;
82 Log3 $name, 3, "Command executed";
83 #$socket->close();
84 #Log3 $name, 3, "Connection closed";}

Wie kann ich das umgehen oder lösen?

lange her das ich das modul erstellt habe....

wenn du diese zeile 81 raus nimmst, wird das modul keine befehle mehr senden können.

da muss eine prüfung rein ob der host erreichbar ist, wenn ja -> setzte befehl ab, wenn nein dann mache schreibe fehler ins log (und setzte device auf absent)

quasi zeile 81-82 ersetzen durch


my @values =  RFHEM_GetNet($hash,$HOSTNAME);
if ( $values[1] eq "present") {
Log3 $name, 3, "Host present, executing command..."; }
syswrite($socket, $HOSTPW . "\n")if($hash->{PASSWORD});
print $socket $msg;
Log3 $name, 3, "Command executed."; }
else { Log3 $name, 3, "Error: host not present!"; }


anbei das modul . leider ungetestet da ich nicht zu hause bin und ich auch keine 2 instanzen mehr habe

Wow. Das nenne ich mal schnellen Support.
Ich werde es testen. Habe allerdings von Unterwegs aus ein paar Codezeilen von RFHEM auf Fhem2Fhem umgeschrieben um das kurzfristig zu lösen.

Er kann die geänderte .pm nicht laden wegen Syntaxfehler.
syntax error at ./FHEM/93_RFHEM.pm line 87, near "else"
Global symbol "$name" requires explicit package name at ./FHEM/93_RFHEM.pm line 87.
Unmatched right curly bracket at ./FHEM/93_RFHEM.pm line 90, at end of line
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 93, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/93_RFHEM.pm line 94.
syntax error at ./FHEM/93_RFHEM.pm line 104, near "}"
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 107, near "= @_"
syntax error at ./FHEM/93_RFHEM.pm line 139, near "}"

Ich versuche mal durchzusehen, aber meine Perlkenntnisse sind recht bescheiden,
Ich benenne mal die definierte Variable um

edit: das war es leider nicht, der Syntaxfehler bleibt bestehen

Habe gerade die neue Version installiert und aus mir unbekannten Gründen kommt nach einem Restart:

Messages collected while initializing FHEM:
configDB: Cannot load module RFHEM

Hier wohl die Fehler:
2016.11.03 20:58:21 1: PERL WARNING: "my" variable $hash masks earlier declaration in same scope at ./FHEM/93_RFHEM.pm line 107.
2016.11.03 20:58:21 1: PERL WARNING: "my" variable $hostname masks earlier declaration in same scope at ./FHEM/93_RFHEM.pm line 107.
2016.11.03 20:58:21 1: PERL WARNING: "state" variable @_ masks earlier declaration in same scope at ./FHEM/93_RFHEM.pm line 107.
2016.11.03 20:58:21 1: PERL WARNING: "my" variable $name masks earlier declaration in same scope at ./FHEM/93_RFHEM.pm line 108.
2016.11.03 20:58:21 1: reload: Error:Modul 93_RFHEM deactivated:
syntax error at ./FHEM/93_RFHEM.pm line 87, near "else"
Global symbol "$name" requires explicit package name at ./FHEM/93_RFHEM.pm line 87.
Unmatched right curly bracket at ./FHEM/93_RFHEM.pm line 90, at end of line
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 93, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/93_RFHEM.pm line 94.
syntax error at ./FHEM/93_RFHEM.pm line 104, near "}"
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 107, near "= @_"
syntax error at ./FHEM/93_RFHEM.pm line 139, near "}"

2016.11.03 20:58:21 0: syntax error at ./FHEM/93_RFHEM.pm line 87, near "else"
Global symbol "$name" requires explicit package name at ./FHEM/93_RFHEM.pm line 87.
Unmatched right curly bracket at ./FHEM/93_RFHEM.pm line 90, at end of line
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 93, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/93_RFHEM.pm line 94.
syntax error at ./FHEM/93_RFHEM.pm line 104, near "}"
Can't use global @_ in "my" at ./FHEM/93_RFHEM.pm line 107, near "= @_"
syntax error at ./FHEM/93_RFHEM.pm line 139, near "}"


EDIT:
Habe den Fehler gefunden:
In Zeile 83 muss am Ende die } entfernt werden. Die ist zuviel.

EDIT2:
Für alle, die es nicht selbst machen wollen, hier die korrigierte Version:

habs in post #1 auch angehängt

Hi,
ich versuche mit RFHEM meine IT Steckdosen zu schaltem mit einem Nano Cul.

Fhem Server RFHEM konfiguriert (erstmal ohne Passwort)

define FhemKeller RFHEM 192.xxx.xxx.xxx:7072

Dummy Server:

######################
# Test Garten Remote #
######################

define Lichterkette1_Dummy dummy
attr Lichterkette1_Dummy devStateIcon on:message_socket_on2 off:message_socket_off2
attr Lichterkette1_Dummy setList on off
attr Lichterkette1_Dummy room Test
define Lichterkette1_remote Notify notify Lichterkette1_Dummy { fhem "set FhemKeller cmd set Lichterkette_1 $EVENT" }


Remote Pi:

define Stecker_4 IT 0FFF0FF00F FF F0
attr Stecker_4 IODev CUL1
attr Stecker_4 alias Lichterkette_1
attr Stecker_4 room Garten


Cul ist initialisiert, wenn ich auf dem remote die Steckdosen per Hand schalte funktioniert es. Auf dem log der Haupt Fhem kommt beim ausführen auch command executed allerdings kommt nix am Remotepi an.
Wenn ich von Hand den Befehl set FhemKeller cmd set Lichterkette_1 on sende kommt auf dem Master auch command executed allerdings am Remote keine Reaktion. Hab ich irgendeinen Denkfehler ??

Verwende mal den Device Name auf dem Keller-Fhem, nicht den Alias-Namen


Sent from my iPhone using Tapatalk

Hallo,

erst mal Danke für das prima Modul, zwar ungepflegt, aber funktiionell und läuft...

Mein Problem ist, daß ich mittels RFHEM Steckdosen (IT) schalten will, das passt auch alles soweit, d.h. der Master-Pi (Schalter als Dummies) sendet mittels notify und RFHEM an den CUL-Pi die set-Befehle und der CUL-Pi schaltet auch brav.

Wenn ich nun aber auf dem CUL-Pi manuell schalte, würde ich gerne eine Rückmeldung an den Master-Pi bzw. dessen Dummies geben, daß sich der Status geändert hat. Mittels notify klappt das zwar auch, aber die beiden fangen dann an, PingPong zu spielen und schiessen sich gegenseitig das LOG voll, weil das jeweilige notify des einen das notify des anderen auslöst.

Hier meine notify-Def.:

define nt_Lampe_WoZi notify Lampe_WZ set Pine2CUL cmd set IT_0100101001100100001001111000000 $EVENT

Logischerweise auf dem anderen dann

define nt_Lampe_WoZi notify IT_0100101001100100001001111000000 set CUL2Pine cmd set Lampe_WZ $EVENT

Gips da was schlaueres oder ist das eher ne notify-Frage?  :-[

Gruß
Andreas

Zitat von: androsch am 24 November 2016, 19:26:41
zwar ungepflegt, aber funktiionell und läuft...

die letzte änderung am modul war am 4.11.2016 also so ungepflegt ist es nicht .....

den rückweg evtl nicht mit set gerät event machen sondern einfach dem dummy das state attribut ändern mit setreading <devspec> <reading> <value>

define nt_Lampe_WoZi notify IT_0100101001100100001001111000000 set CUL2Pine cmd setreading Lampe_WZ state $EVENT

Zitat von: chris1284 am 25 November 2016, 05:18:35
die letzte änderung am modul war am 4.11.2016 also so ungepflegt ist es nicht .....

den rückweg evtl nicht mit set gerät event machen sondern einfach dem dummy das state attribut ändern mit setreading <devspec> <reading> <value>

define nt_Lampe_WoZi notify IT_0100101001100100001001111000000 set CUL2Pine cmd setreading Lampe_WZ state $EVENT

Stimmt, zumindest aktuell  ;D

Werde das mit setreading versuchen, Danke für den Tipp.

Gesendet von meinem XT1032 mit Tapatalk

Hi,
ich bins nochmal  ;)

wenn ich den Device Namen nehme dann kommt auch Command Executed allerdings passiert auf dem Remote nix... langsam bin ich ratlos.....

evtl Groß/ Kleinschreibung falsch?
prüf doch mal im Remote das LOG.

Hier z.B. wie ich befehle absetze:
set PI_EG cmd set ALLE_LAMPEN_EG on

Stell mal Verbose auf 5 um und poste den zugehörigen Logauszug. Dann machste mal in List deines RFHEM Device, dass wir sehen können, ob er überhaupt richtig verbunden ist. Sind bissi wenig Informationen um etwas festzustellen :)

ich habs hoffentlich richtig gemacht:

Fhem Server:

2016.11.25 16:36:26 4: WEB_192.168.10.100_51155 POST /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338; BUFLEN:0
2016.11.25 16:36:26 5: Cmd: >set Lichterkette1_Dummy off<
2016.11.25 16:36:26 4: dummy set Lichterkette1_Dummy off
2016.11.25 16:36:26 5: Triggering Lichterkette1_Dummy (1 changes)
2016.11.25 16:36:26 5: Starting notify loop for Lichterkette1_Dummy, first event off
2016.11.25 16:36:26 4: name: /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.25 16:36:26 4: WEB_192.168.10.100_51155 POST /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20on&room=Test&XHR=1&fw_id=338; BUFLEN:0
2016.11.25 16:36:26 5: Cmd: >set Lichterkette1_Dummy on<
2016.11.25 16:36:26 4: dummy set Lichterkette1_Dummy on
2016.11.25 16:36:26 5: Triggering Lichterkette1_Dummy (1 changes)
2016.11.25 16:36:26 5: Starting notify loop for Lichterkette1_Dummy, first event on
2016.11.25 16:36:26 4: name: /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20on&room=Test&XHR=1&fw_id=338 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.25 16:36:27 4: WEB_192.168.10.100_51155 POST /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338; BUFLEN:0
2016.11.25 16:36:27 5: Cmd: >set Lichterkette1_Dummy off<
2016.11.25 16:36:27 4: dummy set Lichterkette1_Dummy off
2016.11.25 16:36:27 5: Triggering Lichterkette1_Dummy (1 changes)
2016.11.25 16:36:27 5: Starting notify loop for Lichterkette1_Dummy, first event off
2016.11.25 16:36:27 4: name: /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.25 16:36:28 4: WEB_192.168.10.100_51155 POST /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20on&room=Test&XHR=1&fw_id=338; BUFLEN:0
2016.11.25 16:36:28 5: Cmd: >set Lichterkette1_Dummy on<
2016.11.25 16:36:28 4: dummy set Lichterkette1_Dummy on
2016.11.25 16:36:28 5: Triggering Lichterkette1_Dummy (1 changes)
2016.11.25 16:36:28 5: Starting notify loop for Lichterkette1_Dummy, first event on
2016.11.25 16:36:28 4: name: /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20on&room=Test&XHR=1&fw_id=338 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.25 16:36:28 4: WEB_192.168.10.100_51155 POST /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338; BUFLEN:0
2016.11.25 16:36:28 5: Cmd: >set Lichterkette1_Dummy off<
2016.11.25 16:36:28 4: dummy set Lichterkette1_Dummy off
2016.11.25 16:36:28 5: Triggering Lichterkette1_Dummy (1 changes)
2016.11.25 16:36:28 5: Starting notify loop for Lichterkette1_Dummy, first event off
2016.11.25 16:36:28 4: name: /fhem?cmd.Lichterkette1_Dummy=set%20Lichterkette1_Dummy%20off&room=Test&XHR=1&fw_id=338 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip


FHEM Remote:


2016.11.25 16:50:59 5: Initializing Type Library:
2016.11.25 16:50:59 1: Including fhem.cfg
2016.11.25 16:50:59 5: Cmd: >attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride<
2016.11.25 16:50:59 5: Cmd: >attr global autoload_undefined_devices 1<
2016.11.25 16:50:59 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2016.11.25 16:50:59 5: Cmd: >attr global modpath .<
2016.11.25 16:50:59 5: Cmd: >attr global statefile ./log/fhem.save<
2016.11.25 16:50:59 5: Cmd: >attr global updateInBackground 1<
2016.11.25 16:50:59 5: Cmd: >attr global verbose 5<
2016.11.25 16:50:59 5: Cmd: >define telnetPort telnet 7072 global<
2016.11.25 16:50:59 5: Loading ./FHEM/98_telnet.pm
2016.11.25 16:50:59 3: telnetPort: port 7072 opened
2016.11.25 16:50:59 5: Cmd: >define allowed_telnetPort allowed<
2016.11.25 16:50:59 5: Loading ./FHEM/96_allowed.pm
2016.11.25 16:50:59 5: Cmd: >attr allowed_telnetPort validFor telnetPort<
2016.11.25 16:50:59 5: Cmd: >define WEB FHEMWEB 8083 global<
2016.11.25 16:50:59 5: Loading ./FHEM/01_FHEMWEB.pm
2016.11.25 16:51:00 3: WEB: port 8083 opened
2016.11.25 16:51:00 5: Cmd: >attr WEB editConfig 1<
2016.11.25 16:51:00 5: Cmd: >attr WEB stylesheetPrefix dark<
2016.11.25 16:51:00 5: Cmd: >define allowed_WEB allowed<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEB basicAuth cm9vdDp3YXJoYW1tZXI=<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEB validFor WEB<
2016.11.25 16:51:00 5: Cmd: >define WEBphone FHEMWEB 8084 global<
2016.11.25 16:51:00 3: WEBphone: port 8084 opened
2016.11.25 16:51:00 5: Cmd: >attr WEBphone stylesheetPrefix dark<
2016.11.25 16:51:00 5: Cmd: >define allowed_WEBphone allowed<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEBphone basicAuth cm9vdDp3YXJoYW1tZXI=<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEBphone validFor WEBphone<
2016.11.25 16:51:00 5: Cmd: >define WEBtablet FHEMWEB 8085 global<
2016.11.25 16:51:00 3: WEBtablet: port 8085 opened
2016.11.25 16:51:00 5: Cmd: >attr WEBtablet stylesheetPrefix touchpad<
2016.11.25 16:51:00 5: Cmd: >define allowed_WEBtablet allowed<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEBtablet basicAuth cm9vdDp3YXJoYW1tZXI=<
2016.11.25 16:51:00 5: Cmd: >attr allowed_WEBtablet validFor WEBtablet<
2016.11.25 16:51:00 5: Cmd: >define CUL2 CUL /dev/ttyUSB0@38400 0000<
2016.11.25 16:51:00 5: Loading ./FHEM/00_CUL.pm
2016.11.25 16:51:01 3: Opening CUL2 device /dev/ttyUSB0
2016.11.25 16:51:01 3: Setting CUL2 serial parameters to 38400,8,N,1
2016.11.25 16:51:01 5: SW: V
2016.11.25 16:51:04 5: SW: V
2016.11.25 16:51:04 5: CUL/RAW (ReadAnswer): V 1.62 nanoCUL433

2016.11.25 16:51:04 5: SW: ?
2016.11.25 16:51:04 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C
2016.11.25 16:51:04 5: CUL/RAW (ReadAnswer): F i A Z E k G M K U Y R T V W X
2016.11.25 16:51:04 5: CUL/RAW (ReadAnswer): e f l t x

2016.11.25 16:51:04 3: CUL2: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2016.11.25 16:51:04 5: SW: X21
2016.11.25 16:51:04 5: SW: T01
2016.11.25 16:51:04 5: CUL/RAW (ReadAnswer): 0000

2016.11.25 16:51:04 5: GOT CUL fhtid: 0000
2016.11.25 16:51:04 3: CUL2 device opened
2016.11.25 16:51:04 5: Cmd: >attr CUL2 room Allgemein<
2016.11.25 16:51:04 5: Cmd: >define Stecker_1 IT 0FFF00000F FF F0<
2016.11.25 16:51:04 5: Loading ./FHEM/10_IT.pm
2016.11.25 16:51:05 5: Cmd: >attr Stecker_1 IODev CUL2<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_1 alias LED_Baum<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_1 room Garten<
2016.11.25 16:51:05 5: Cmd: >define Stecker_2 IT 0FFFF0000F FF F0<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_2 IODev CUL2<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_2 alias Holzbackofen<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_2 room Garten<
2016.11.25 16:51:05 5: Cmd: >define Stecker_4 IT 0FFF0FF00F FF F0<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_4 IODev CUL2<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_4 alias Lichterkette_1<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_4 room Garten<
2016.11.25 16:51:05 5: Cmd: >define Stecker_5 IT 0FFF0FFF0F FF F0<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_5 IODev CUL2<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_5 alias Lichterkette_2<
2016.11.25 16:51:05 5: Cmd: >attr Stecker_5 room Garten<
2016.11.25 16:51:05 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2016.11.25 16:51:05 5: Loading ./FHEM/92_FileLog.pm
2016.11.25 16:51:05 5: Cmd: >define autocreate autocreate<
2016.11.25 16:51:05 5: Loading ./FHEM/98_autocreate.pm
2016.11.25 16:51:05 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2016.11.25 16:51:05 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2016.11.25 16:51:05 5: Loading ./FHEM/91_eventTypes.pm
2016.11.25 16:51:05 2: eventTypes: loaded 2 events from ./log/eventTypes.txt
2016.11.25 16:51:05 5: Cmd: >define initialUsbCheck notify global:INITIALIZED usb create<
2016.11.25 16:51:05 5: Loading ./FHEM/91_notify.pm
2016.11.25 16:51:06 1: Including ./log/fhem.save
2016.11.25 16:51:06 5: Cmd: >setstate CUL2 2016-11-25 16:48:44 cmds  B C F i A Z E k G M K U Y R T V W X e f l t x<
2016.11.25 16:51:06 5: Cmd: >setstate CUL2 2016-11-25 13:17:00 raw is0FFFF0000FF0<
2016.11.25 16:51:06 5: Cmd: >setstate CUL2 2016-11-25 16:48:44 state Initialized<
2016.11.25 16:51:06 5: Cmd: >setstate Logfile active<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_1 off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_1 2016-11-21 18:19:02 protocol V1<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_1 2016-11-24 10:02:39 state off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_2 off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_2 2016-11-21 18:20:27 protocol V1<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_2 2016-11-25 13:17:00 state off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_4 off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_4 2016-11-21 18:20:27 protocol V1<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_4 2016-11-24 10:10:04 state off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_5 off<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_5 2016-11-21 22:31:14 protocol V1<
2016.11.25 16:51:06 5: Cmd: >setstate Stecker_5 2016-11-21 22:44:10 state off<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEB active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEB 2016-11-25 16:48:38 state active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEBphone active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEBphone 2016-11-25 16:48:38 state active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEBtablet active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_WEBtablet 2016-11-25 16:48:39 state active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_telnetPort active<
2016.11.25 16:51:06 5: Cmd: >setstate allowed_telnetPort 2016-11-25 16:48:33 state active<
2016.11.25 16:51:06 5: Cmd: >setstate autocreate active<
2016.11.25 16:51:06 5: Cmd: >setstate eventTypes active<
2016.11.25 16:51:06 5: Cmd: >setstate global no definition<
2016.11.25 16:51:06 5: Cmd: >setstate initialUsbCheck 2016-11-25 16:48:55<
2016.11.25 16:51:06 5: Cmd: >setstate initialUsbCheck 2016-11-25 16:48:54 state active<
2016.11.25 16:51:06 5: Triggering global (1 changes)
2016.11.25 16:51:06 5: Starting notify loop for global, first event INITIALIZED
2016.11.25 16:51:06 5: Triggering initialUsbCheck
2016.11.25 16:51:06 4: initialUsbCheck exec usb create
2016.11.25 16:51:06 5: Cmd: >usb create<
2016.11.25 16:51:06 1: usb create starting
2016.11.25 16:51:08 4: ### ttyAMA0: checking if it is a CUL
2016.11.25 16:51:08 3: Probing CUL device /dev/ttyAMA0
2016.11.25 16:51:08 5: SW: 0a
2016.11.25 16:51:08 5: SW: 560a
2016.11.25 16:51:08 4: got wrong answer for a CUL
2016.11.25 16:51:08 4: ### ttyAMA0: checking if it is a TCM_ESP3
2016.11.25 16:51:08 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.11.25 16:51:08 5: SW: 5500010005700838
2016.11.25 16:51:08 4: got wrong answer for a TCM_ESP3
2016.11.25 16:51:08 4: ### ttyAMA0: checking if it is a FRM
2016.11.25 16:51:08 3: Probing FRM device /dev/ttyAMA0
2016.11.25 16:51:08 5: SW: f9
2016.11.25 16:51:13 5: SW: f079f7
2016.11.25 16:51:13 4: got wrong answer for a FRM
2016.11.25 16:51:13 4: ### ttyUSB0: checking if it is a TCM_ESP3
2016.11.25 16:51:13 4: ttyUSB0 is already used by the fhem device CUL2
2016.11.25 16:51:14 1: usb create end
2016.11.25 16:51:14 2: SecurityCheck:  telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.11.25 16:51:14 0: Featurelevel: 5.7
2016.11.25 16:51:14 0: Server started with 18 defined entities (fhem.pl:12596/2016-11-17 perl:5.020002 os:linux user:fhem pid:907)
2016.11.25 16:51:14 4: Connection accepted from WEB_192.168.10.100_51451
2016.11.25 16:51:14 4: Connection accepted from WEB_192.168.10.100_51452
2016.11.25 16:51:15 4: WEB_192.168.10.100_51451 GET /fhem?XHR=1&inform=type=status;filter=room=Allgemein;since=1480089044.138;fmt=JSON&fw_id=63×tamp=1480089056010; BUFLEN:0
2016.11.25 16:51:15 4: WEB_192.168.10.100_51452 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1480088947.1039999;fmt=JSON&fw_id=65×tamp=1480089056042; BUFLEN:0
2016.11.25 16:51:15 4: Connection accepted from WEB_192.168.10.100_51453
2016.11.25 16:51:15 4: Connection accepted from WEB_192.168.10.100_51454
2016.11.25 16:51:15 4: Connection closed for WEB_192.168.10.100_51453: EOF
2016.11.25 16:51:15 4: Connection closed for WEB_192.168.10.100_51454: EOF
2016.11.25 16:52:00 4: Connection closed for WEB_192.168.10.100_51452: EOF
2016.11.25 16:52:03 4: Connection closed for WEB_192.168.10.100_51451: EOF
2016.11.25 16:52:03 4: Connection accepted from WEB_192.168.10.100_51466
2016.11.25 16:52:03 4: WEB_192.168.10.100_51466 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=; BUFLEN:0
2016.11.25 16:52:03 4: name: /fhem/FileLog_logWrapper?dev=Logfile&type=text&file= / RL:1095 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.25 16:52:03 4: WEB_192.168.10.100_51466 GET /fhem/pgm2/style.css?v=1480089060; BUFLEN:0
2016.11.25 16:52:04 4: WEB_192.168.10.100_51466 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1480089122;fmt=JSON&fw_id=63×tamp=1480089120490; BUFLEN:0
2016.11.25 16:52:09 4: Connection closed for WEB_192.168.10.100_51466: EOF
2016.11.25 16:52:09 4: Connection accepted from WEB_192.168.10.100_51472
2016.11.25 16:52:09 4: WEB_192.168.10.100_51472 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-11.log; BUFLEN:0
2016.11.25 16:52:09 4: WEB_192.168.10.100_51472 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1480089128;fmt=JSON&fw_id=64×tamp=1480089125773; BUFLEN:0
2016.11.25 16:52:47 4: Connection closed for WEB_192.168.10.100_51472: EOF
2016.11.25 16:52:47 4: Connection accepted from WEB_192.168.10.100_51474
2016.11.25 16:52:47 4: WEB_192.168.10.100_51474 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1480089122;fmt=JSON&fw_id=63×tamp=1480089163994; BUFLEN:0
2016.11.25 16:52:50 4: Connection closed for WEB_192.168.10.100_51474: EOF
2016.11.25 16:52:50 4: Connection accepted from WEB_192.168.10.100_51476
2016.11.25 16:52:50 4: WEB_192.168.10.100_51476 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-11.log; BUFLEN:0

Fast. Wichtig ist, dass du diese Sachen in CodeTags (Schau mal die Dinger über den Smilies durch) setzt. Dann können wir es einfach lesen.

Und fangen wir mal mit einem reinen
list FhemKeller
an. Das Ergebnis postest du hier in Codetags. Dann sehen wir, ob überhaupt eine Verbindung aufgebaut werden konnte.

Zitat von: Amenophis86 am 25 November 2016, 17:47:25
Fast. Wichtig ist, dass du diese Sachen in CodeTags (Schau mal die Dinger über den Smilies durch) setzt. Dann können wir es einfach lesen.

Und fangen wir mal mit einem reinen

Code Auswählen Erweitern

list FhemKeller
an. Das Ergebnis postest du hier in Codetags. Dann sehen wir, ob überhaupt eine Verbindung aufgebaut werden konnte.

...und am Besten nochmal den aktuellen Code Deines Notify 'Lichterkette1_remote' auf der Hauptinstanz.
Bis zum 1. Advent kriegen wir das zum Laufen...;-)
Was ich meinte, was, dass Du in diesem Notify den Device-Namen des Geräts auf der Remote-Instanz verwendest und nicht den Alias-Namen dieses Geräts.


Sent from my iPhone using Tapatalk

Zitat von: chris1284 am 25 November 2016, 05:18:35
die letzte änderung am modul war am 4.11.2016 also so ungepflegt ist es nicht .....

den rückweg evtl nicht mit set gerät event machen sondern einfach dem dummy das state attribut ändern mit setreading <devspec> <reading> <value>

define nt_Lampe_WoZi notify IT_0100101001100100001001111000000 set CUL2Pine cmd setreading Lampe_WZ state $EVENT

Tja, leider nicht erfolgreich, auch nur das Reading state ändern beginnt das PingPong-Spiel. Ich werd mal noch in notify ein wenig stöbern und ev. ein userReading dafür generieren....

Sollte jemand was Schlaues einfallen, gerne Meldung hier dazu :-)

Dein Notigy reagiert auf den State des Device auf der Hauptinstanz...und solange Du den von der Remote-Instanz aus änderst, dürfte das Pingpong weitergehen. User Reading könnte klappen, wenn das Notify nur auf Änderungen des State reagiert.
Alternativ: Zeig den Status per Dummy an und nicht direkt auf dem Device. Was Besseres fällt mir grad nicht ein. Höchstens was 'Umständlicheres'...quasi ein 'Entprelllen' des Pingpong durch Setzen eines Dummy nach dem Betätigen des Device. Das Notify dürfte dann nur reagieren, wenn sich der State des Device ändert UND der Dummy gesetzt ist - und dabei sofort den Dummy zurücksetzen. Oder so. Umständlich halt...;-)


Sent from my iPhone using Tapatalk

Zitat von: SVLoneStar am 25 November 2016, 20:54:30
Dein Notigy reagiert auf den State des Device auf der Hauptinstanz...und solange Du den von der Remote-Instanz aus änderst, dürfte das Pingpong weitergehen. User Reading könnte klappen, wenn das Notify nur auf Änderungen des State reagiert.
Alternativ: Zeig den Status per Dummy an und nicht direkt auf dem Device. Was Besseres fällt mir grad nicht ein. Höchstens was 'Umständlicheres'...quasi ein 'Entprelllen' des Pingpong durch Setzen eines Dummy nach dem Betätigen des Device. Das Notify dürfte dann nur reagieren, wenn sich der State des Device ändert UND der Dummy gesetzt ist - und dabei sofort den Dummy zurücksetzen. Oder so. Umständlich halt...;-)


Sent from my iPhone using Tapatalk

Yep, das wird umständlich, das ist mir klar, ist ja auch ungewöhnlich, den Status von 2 FHEM-Instanzen aus ändern zu wollen...
Muss mal noch in mich gehen, wie ich das entkopple, danke fürs mitdenken  ;)

Gesendet von meinem XT1032 mit Tapatalk

Lenkt mich von meinen eigenen FHEM-Problemen ab... ;-)


Sent from my iPhone using Tapatalk

Zitat von: SVLoneStar am 25 November 2016, 21:53:55
Lenkt mich von meinen eigenen FHEM-Problemen ab... ;-)

Hab es jetzt mit nem Watchdog auf dem RFHEM-Empfänger gelöst, d.h. der Dummy schaltet übers Notify vom Haupt-FHEM aus sofort auf dem CUL-FHEM um.

Auf dem CUL-FHEM läuft dann ein watchdog, der nach einer Minute den Status des readings (setreading) auf dem Haupt-FHEM umstellt, wenn man am CUL-FHEM oder per Fernbedienung die Steckdose geschaltet hat. Hat zwar den Nachteil, daß der Status auf dem Haupt-FHEM nicht exakt zeitgleich ist, aber man schaltet ja nicht ausserhalb des Haupt-FHEM und rennt dann sofort dahin und schaut nach, wie dort der Status ist, deshalb kann ich damit leben und der Watchdog schaltet eben nur ein mal und reagiert nicht sofort auf jede Statusänderung wie es das notify tut.

define wd_Lampe_WoZi_on watchdog IT_0100101001100100001001111000000:on 00:01 IT_0100101001100100001001111000000:off set CUL2Pine cmd setreading Lampe_WZ state on

Nur für alle ev. Interessierten....

So habe nochmal alle Infos zusammengetragen:

List FHEM2 auf dem FHEM Server (Raspi2):

Auf dem Server laufen auch noch Hmlan, Sonos Geräte, Rademacher Stick, Netatmo, Fritz Box, und CUL (868Mhz), habe nicht die komplette Konfig hier reingepostet. Erstens isse lang und dann kann es passieren das ich vielleicht vergesse Passwöter rauszu XXXen ;)



Internals:
   DEF        192.168.10.82:7072
   HOSTNAME   192.168.10.82
   Interval   900
   NAME       FHEM2
   NR         26
   PORT       7072
   STATE      created
   TYPE       RFHEM
   Readings:
     2016-11-26 10:07:04   ipadress        192.168.10.82
     2016-11-26 10:07:04   statedev        present
Attributes:


FHEM-CFG Server:


# Fhem Keller

define FHEM2 RFHEM 192.168.10.82:7072

######################
# Test Garten Remote #
######################

define Lichterkette1_Dummy dummy
attr Lichterkette1_Dummy devStateIcon on:message_socket_on2 off:message_socket_off2
attr Lichterkette1_Dummy room Test
attr Lichterkette1_Dummy setList on off
define Lichterkette1_remote notify notify Lichterkette1_Dummy { fhem "set FHEM2 cmd set Stecker_4 $EVENT" }



FHEM CFG Remote (Raspi2):

Am Remote habe ich den CUL in CUL 2 umbenannt weil ich am Haupt FHEM auch einen CUL in Betrieb habe und ich dachte vielleicht stört die Bezeichnung wenn ich beide CUL1 nenne.


############
# Nano Cul #
############
define CUL2 CUL /dev/ttyUSB0@38400 0000
attr CUL2 room Allgemein


# Test

define Stecker_1 IT 0FFF00000F FF F0
attr Stecker_1 IODev CUL2
attr Stecker_1 alias LED_Baum
attr Stecker_1 room Garten

define Stecker_2 IT 0FFFF0000F FF F0
attr Stecker_2 IODev CUL2
attr Stecker_2 alias Holzbackofen
attr Stecker_2 room Garten

define Stecker_4 IT 0FFF0FF00F FF F0
attr Stecker_4 IODev CUL2
attr Stecker_4 alias Lichterkette_1
attr Stecker_4 room Garten

define Stecker_5 IT 0FFF0FFF0F FF F0
attr Stecker_5 IODev CUL2
attr Stecker_5 alias Lichterkette_2
attr Stecker_5 room Garten




Kommando ausgeführt auf FHEM Server:

2016.11.26 10:30:07 5: Cmd: >set FHEM2 cmd set Stecker_4 on<
2016.11.26 10:30:07 3: Host present, executing command...
2016.11.26 10:30:07 3: Command executed.


Log aufm Remote:

2016.11.26 10:28:03 4: WEB_192.168.10.100_52531 GET /fhem?XHR=1&inform=type=status;filter=;since=1480152481;fmt=JSON&fw_id=79×tamp=1480152478410; BUFLEN:0
2016.11.26 10:29:56 4: Connection closed for WEB_192.168.10.100_52534: EOF
2016.11.26 10:29:56 4: Connection closed for WEB_192.168.10.100_52532: EOF
2016.11.26 10:29:56 4: Connection closed for WEB_192.168.10.100_52530: EOF
2016.11.26 10:29:56 4: Connection closed for WEB_192.168.10.100_52533: EOF
2016.11.26 10:30:07 4: Connection accepted from telnetPort_192.168.10.164_39705
2016.11.26 10:30:07 5: Cmd: >set Stecker_4 on<
2016.11.26 10:30:07 2: CUL2 IT_set: Stecker_4 on
2016.11.26 10:30:07 5: Triggering Stecker_4 (1 changes)
2016.11.26 10:30:07 5: Starting notify loop for Stecker_4, first event on
2016.11.26 10:30:07 5: CUL2 IT_set: Type=CUL Protocol=V1
2016.11.26 10:30:07 5: SW: is0FFF0FF00FFF
2016.11.26 10:30:08 5: CUL/RAW (ReadAnswer): is0FFF0FF00FFF

2016.11.26 10:30:08 5: Triggering CUL2 (1 changes)
2016.11.26 10:30:08 5: Starting notify loop for CUL2, first event raw: is0FFF0FF00FFF
2016.11.26 10:30:08 5: IT_Set: GetFn(raw): message = is0FFF0FF00FFF Antwort =   raw => is0FFF0FF00FFF
2016.11.26 10:30:08 4: ITSet: Answer from CUL2:   raw => is0FFF0FF00FFF
2016.11.26 10:32:00 4: Connection accepted from WEB_192.168.10.100_52641
2016.11.26 10:32:00 4: WEB_192.168.10.100_52641 GET /fhem?cmd=style%20eventMonitor; BUFLEN:0
2016.11.26 10:32:00 4: name: /fhem?cmd=style%20eventMonitor / RL:1207 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.26 10:32:01 4: Connection closed for WEB_192.168.10.100_52531: EOF
2016.11.26 10:32:01 4: WEB_192.168.10.100_52641 GET /fhem?XHR=1&inform=type=status;filter=;since=1480152719;fmt=JSON&fw_id=83×tamp=1480152716399; BUFLEN:0
2016.11.26 10:32:01 4: Connection accepted from WEB_192.168.10.100_52642
2016.11.26 10:32:01 4: WEB_192.168.10.100_52642 GET /fhem?XHR=1&inform=type=raw;withLog=0;filter=.*×tamp=1480152717319; BUFLEN:0
2016.11.26 10:32:03 4: Connection closed for WEB_192.168.10.100_52642: EOF
2016.11.26 10:32:03 4: Connection closed for WEB_192.168.10.100_52641: EOF
2016.11.26 10:32:03 4: Connection accepted from WEB_192.168.10.100_52643
2016.11.26 10:32:03 4: WEB_192.168.10.100_52643 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-11.log; BUFLEN:0


und was soll ich sagen er schaltet....aber nur wenn ich den Befehl von Hand eingebe......das hatte ja gestern auch nicht funktioniert warum auch immer.....

mit diesem Notify funzt das schalten einwandfrei  ;D ;D ;D ;D ;D



define Lichterkette2_remote notify Lichterkette1_Dummy set FHEM2 cmd set Stecker_4 toggle
attr Lichterkette2_remote room Notify



Also nur nochmal zum Verstädnis:

1. Du klickst auf dem Server auf den Dummy Lichterkette1_Dummy auf on
2. mittels notify Lichterkett1_remote wird das "on" an RFHEM übergeben
3. RFHEM also das Device FHEM2 sendet "set Stecker_4 on" an den Remote
4. auf dem Remote ist Stecker_4 in IT device, welches den Befehl "on" bekommt und diesen auch kennt
5. Stecker_4 sollte jetzt auf on stehen.

Und wenn ich deine Daten richtig lese, dann kommt auch alles richtig an. Aber Stecker_4 wird nicht auf on gestellt. Lediglich, wenn du anstelle von "on" "toggle" sendest, dann funktioniert das Ganze? Oder was war jetzt das Problem?

Hallo,
@amenophis86 genau richtig erfasst  .....hauptsache für mich das es nu funzt

Na gut, wenn du zufrieden bist, dann ist doch gut. Solltest du doch noch schauen, wieso on nicht geht dann gib bescheid :)

Hallo zusammen,

ich benötige Hilfe aus der erfahrenen Community für dieses Modul. Ich versuche seit zwei Tagen eine funktionierende Verbindung zwischen einem ubuntu-Server mit FHEM (Master) und einer FHEM Instanz auf einem Raspberry Pi auf die Beine zu stellen. Folgendes Szenario ergibt sich:

Wenn ich vom Master direkt per telnet auf Port 7072 des Raspberry Pi's gehe, kann ich ohne Probleme Befehle direkt absetzen. Wenn ich aber über das Modul RFHEM gehen möchte, bekomme ich folgenden Fehler im Log-File des Slaves:

telnet SSL/HTTPS error:  SSL accept attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

SSL ist eigentlich deaktiviert für telnet - zumindest steht sowohl bei Master wie auch Slave folgender Eintrag im telnetPort:
Attributes
SSL 0

Kann mir ggfs. jemand einen kurzen Tipp geben, wo ich ansetzen muss? Ich stochere leider im Dunkeln...

Danke und viele Grüße
- schooney

Ich habe das Modul etwas erweitert weil ich keine Notifys schreiben wollte:

Attribut RFHEMdevs : eine Komma getrennte Liste von Devices. Alle events dieser Devices werden autom. an die entfernte Instanz weitergeleitet (sprich wenn deviceX ein event wie temperature: 29.3 generiert, wird ein "set rfhem_device cmd setreading deviceX  temperature 29.3" angesetzt). Das Device auf der entfernten Instanz (dummy zb) muss genau so heißen wie das device welches das event generiert (hier folgt noch eine prefix-attribut so das zb das event an [prefix]devicename weitergeleitet werdne kann)

Attribut RFHEMevents:  eine Komma getrennte Liste von events (readings). Nur diese Readings der devices in RFHEMdevs werden weitergeleitet - noch im test

wer interessa hat kanns testen

Zitat von: chris1284 am 29 August 2017, 15:17:02
Ich habe das Modul etwas erweitert weil ich keine Notifys schreiben wollte

Danke!
genau das erleichtert es mir auch. ;)

mal noch ne andere Frage dazu, der check ob die remote Instanz aktiv ist, hast die auch neu dazugebaut?

Zitat2017.09.11 13:59:58 3: Host present, executing command...
2017.09.11 13:59:58 3: Command executed.

eigentlich nicht, auch am logging habe nichts gemacht. es gab aber zwischendurch irgendwann mal ein update

Zitat von: chris1284 am 11 September 2017, 21:02:34
eigentlich nicht, auch am logging habe nichts gemacht. es gab aber zwischendurch irgendwann mal ein update

OK, hab ich dann nicht mitbekommen.
Und die Versionsinfo ist ja auch noch auf dem alten Stand.

Zitat93_RFHEM.pm          1000 2014-05-09 00:00:00Z chris1284

Hab jetzt aber überall deine neue Version am laufen.

Das modul ist nun eingechecked

In FHEM normal eingecheckt?

ja. ich habe die commandref noch angepast und dann eingecheked

Da freu ich mich aber, vielen Dank :)

@chris1284, dake für dsd Modul!!

habe auf zwei pi folgendes mit RFHEM realisiert:

pi1
define remoteFHEM RFHEM 192.168.0.35:7072 SiLiCon
attr remoteFHEM room TEST

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


pi2
define remoteFHEM RFHEM 192.168.0.42:7072 SiLiCon
attr remoteFHEM room TEST

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


pi1 & pi2
define telnetPort telnet 7072 global

define allowed_telnetPort allowed
attr allowed_telnetPort password SiLiCon
attr allowed_telnetPort validFor telnetPort


egal von welchem pi set remoteFHEM cmd set myTestDevice on/off dies gesendet wird, solte immer
auf dem anderem pi das Device auf on oder off gesetzt werden, aber es tuut sich nichts?

Woran liegt es, dass es keine Reaktion passiert??

Gerhard

P.S. update ist aktuell

Gibt es im Log einen Fehler? Verbose mal auf 5 gestellt?

Wofür steht das "SiLiCon" ?
Versuch es mal ohne Port Angabe, dann nimmt er automatisch den Port  7072


Tapatalk iPhone, daher kurz gehalten.

Zitat von: Ma_Bo am 15 September 2017, 18:26:35
Wofür steht das "SiLiCon" ?

Telnet Passwort

Aha, wieder was gelernt... ist schon ne Weile her, dass ich mein RFHEM Device erstellt habe, seit dem läuft es top..


Tapatalk iPhone, daher kurz gehalten.

SiLiCon steht für das passwort von telnet (bei beiden pi's gleich.

ich habe es mit :7072 ohne 7072 dann pi1 mit 7072 und pi2 mit 7073, aber keine Änderung!

keine Fehlermeldungen:
2017.09.15 15:51:18 3: Host present, executing command...
2017.09.15 15:51:18 3: Command executed.
2017.09.15 15:54:03 3: Host present, executing command...
2017.09.15 15:54:03 3: Command executed.


Zitat von: Gerhard am 15 September 2017, 18:19:45
@chris1284, dake für dsd Modul!!

habe auf zwei pi folgendes mit RFHEM realisiert:

pi1

Code Auswählen Erweitern

define remoteFHEM RFHEM 192.168.0.35:7072 SiLiCon
attr remoteFHEM room TEST

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


pi2

Code Auswählen Erweitern

define remoteFHEM RFHEM 192.168.0.42:7072 SiLiCon
attr remoteFHEM room TEST

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


pi1 & pi2

Code Auswählen Erweitern

define telnetPort telnet 7072 global

define allowed_telnetPort allowed
attr allowed_telnetPort password SiLiCon
attr allowed_telnetPort validFor telnetPort


egal von welchem pi set remoteFHEM cmd set myTestDevice on/off dies gesendet wird, solte immer
auf dem anderem pi das Device auf on oder off gesetzt werden, aber es tuut sich nichts?

Woran liegt es, dass es keine Reaktion passiert??

Gerhard

P.S. update ist aktuell

Versuch mal bitte:

set remoteFHEM cmd setreading myTestDevice state on


Tapatalk iPhone, daher kurz gehalten.

Nur ne Idee, evtl. was mit allowed Device...?


Tapatalk iPhone, daher kurz gehalten.

Stell mal bitte auf verbose 5 und führe nochmal den Befehl aus

danke Ma_Bo, immer noch nichts!

mit verbose 5

2017.09.15 16:57:28 3: Command executed.
2017.09.15 16:57:57 3: Host present, executing command...
2017.09.15 16:57:57 3: Command executed.
2017.09.15 17:00:59 3: Host present, executing command...
2017.09.15 17:00:59 3: Command executed.
2017.09.15 17:04:07 3: Host present, executing command...
2017.09.15 17:04:07 3: Command executed.


keine neue Erkenntnisse.

Und was sagt das log des anderen fhem...?


Tapatalk iPhone, daher kurz gehalten.

identisch...

eigentlich ist Alles wie in wiki und cmdref???

ich hatte während rumprobieren folgende Meldungen, aber jetzt ist Alles o.k?

2017.09.15 15:48:37 3: Command executed.
2017.09.15 15:50:56 3: Host present, executing command...
2017.09.15 15:50:56 3: Command executed.
2017.09.15 15:51:10 3: RFHEM remoteFHEM - triggered by Device:myTestDevice (all events) ...
2017.09.15 15:51:10 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_RFHEM.pm line 157.
2017.09.15 15:51:10 3: RFHEM remoteFHEM - event: on with value  ...
2017.09.15 15:51:10 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_RFHEM.pm line 158.
2017.09.15 15:51:10 3: Host present, executing command...
2017.09.15 15:51:10 3: Command executed.
2017.09.15 15:51:18 3: RFHEM remoteFHEM - triggered by Device:myTestDevice (all events) ...
2017.09.15 15:51:18 3: RFHEM remoteFHEM - event: off with value  ...
2017.09.15 15:51:18 3: Host present, executing command...
2017.09.15 15:51:18 3: Command executed.
2017.09.15 15:54:03 3: Host present, executing command...
2017.09.15 15:54:03 3: Command executed.
2017.09.15 16:57:28 3: Host present, executing command...

ist bei euch alles o.k. mit heutiger Version?

Gerhard

Wie genau gibst du die Befehle ein? Denke da stimmt evtl was an Namen oder Syntax nicht. Habe rfhem seit Anbeginn der Zeit laufen und keine Probleme.

Hier z. B. Ein Teil eines DOIF:

DOELSEIF ([{twilight("Sonnenstand","ss_astro","20:00","23:00")}]) (set PI_OG cmd set Rollos_OG geschlossen)



Gesendet von meinem S3_32 mit Tapatalk

Die Warnung einfach ignorieren. Das kommt wenn ein Event nur einen Namen hat, aber keinen Wert. Da bin ich noch am über legen wie man da die Meldung unterdrücken kann, was aber für mich nicht kritisch ist.


Die Warnung sollte nur beim der eventfunktion von rohem kommen, ehr nicht wenn man zB per Hand ein set ... cmd... auslöst

die Befehle gebe ich per Hand ein set remoteFHEM cmd set myTestDevice on oder off,
wobei ich auch auf dem Syntax aufpasse.

Die identische Namensgebung in den Instanzen soltte kein Problem darstellen, oder?

FHEM1 192.168.0.35 ------------------> FHEM2 192.168.0.42

FHEM2 192.168.0.42 ------------------> FHEM1 192.168.0.35

das Verhalten (kein on/off) und logs sind identisch?...

Hast den Befehl mal direkt remote getestet?

Die Namen spielen keine Rolle, geht ja über IP.
Vom log her würde ich denken dass da was mit dem Befehl nicht stimmt. Die Verbindung scheint er ja aufzubauen.

Gesendet von meinem S3_32 mit Tapatalk

Hallo Frank_Huber,

ZitatHast den Befehl mal direkt remote getestet?

was meinst du damit? wie mache ich das?

Du willst von fhem1 auf fhem2 einen Befehl ausführen.
Den Befehl dann erstmal auf fhem2 testen und dann über fhem1 / rfhem absetzen.

Gesendet von meinem S3_32 mit Tapatalk

ok, lokal lassen sich die dummys setzen, auch über telnet port 7072,
nur über RFHEM (remote) nicht.

müsste ich was mit den attributen RFEMdevice oder RFHEMevent anstellen?

du hast zwar die defines geliefert, aber mach doch mal bitte in list der beiden RFHEM Device. Vielleicht sieht man dort irgendetwas.

Nein, mit den Attributen hat saß nix zu tun. Die spiegeln Readings automatisch wenn gesetzt.

Poste mal ein list von den beiden rfhem und den dummys.

Gesendet von meinem S3_32 mit Tapatalk

fhem.cfg von 192.168.0.42:

define remoteFHEM RFHEM 192.168.0.35:7072 SiLiCon
attr remoteFHEM room TEST
attr remoteFHEM verbose 5

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


fhem.cfg von 192.168.0.35:

define remoteFHEM RFHEM 192.168.0.42:7072 SiLiCon
attr remoteFHEM room TEST
attr remoteFHEM verbose 5

define myTestDevice dummy
attr myTestDevice room TEST
attr myTestDevice setList on off


Gib mal oben in der fhem Kommandozeile folgendes ein:

list remoteFHEM

Und was dann angezeigt wird, hier posten...


Tapatalk iPhone, daher kurz gehalten.

Nach den defines (was btw kein list ist) müsste das so gehen: set remoteFHEM cmd set myTestDevice on
Groß/Klein Schreibung beachten!

Gesendet von meinem S3_32 mit Tapatalk

192.168.0.35:
Internals:
   DEF        192.168.0.42:7072 SiLiCon
   HOSTNAME   192.168.0.42
   Interval   900
   NAME       remoteFHEM
   NR         89
   NTFY_ORDER 50-remoteFHEM
   PASSWORD   SiLiCon
   PORT       7072
   STATE      created
   TYPE       RFHEM
   READINGS:
     2017-09-15 18:36:15   ipadress        192.168.0.42
     2017-09-15 18:36:15   statedev        present
Attributes:
   room       TEST
   verbose    5

192.168.0.42:
Internals:
   DEF        192.168.0.35:7072 SiLiCon
   HOSTNAME   192.168.0.35
   Interval   900
   NAME       remoteFHEM
   NR         40
   NTFY_ORDER 50-remoteFHEM
   PASSWORD   SiLiCon
   PORT       7072
   STATE      created
   TYPE       RFHEM
   READINGS:
     2017-09-15 20:35:48   ipadress        192.168.0.35
     2017-09-15 20:35:48   statedev        present
Attributes:
   room       TEST
   verbose    5

ZitatNach den defines (was btw kein list ist) müsste das so gehen:
Code: [Auswählen]

set remoteFHEM cmd set myTestDevice on

Groß/Klein Schreibung beachten!

schon hundert mal geprüft ob syntax und klein/groß ok ist.

Du hattest oben mit setreading getestet, das einfache Set von meinem Post getestet?

Gesendet von meinem S3_32 mit Tapatalk

ja, öfters. kein Unterschied?

eigentlich ist Alles einfach.

Eigenartig.
Mach mal beim sendenden fhem ein attr remoteFHEM RFHEMdevs myTestDevice rein.
Dann müsste sich der dummy automatisch von fhem 1 auf fhem 2 spiegeln.

Gesendet von meinem S3_32 mit Tapatalk

sendender FHEM 192.168.0.35:
define remoteFHEM RFHEM 192.168.0.42:7072 SiLiCon
attr remoteFHEM RFHEMdevs myTestDevice
attr remoteFHEM room TEST
attr remoteFHEM verbose 5


set remoteFHEM cmd myTestDevice on auf beiden Seiten ausgefürt, same procedure, nada!

hier noch der list:
Internals:
   DEF        192.168.0.42:7072 SiLiCon
   HOSTNAME   192.168.0.42
   Interval   900
   NAME       remoteFHEM
   NR         89
   NTFY_ORDER 50-remoteFHEM
   PASSWORD   SiLiCon
   PORT       7072
   STATE      created
   TYPE       RFHEM
   READINGS:
     2017-09-15 19:00:38   ipadress        192.168.0.42
     2017-09-15 19:00:38   statedev        present
Attributes:
   RFHEMdevs  myTestDevice
   room       TEST
   verbose    5

Hast du mal nen Neustart des RPi gemacht, glaube zwar nicht, dass es daran liegt, aber versuchen kann man es ja mal...


Tapatalk iPhone, daher kurz gehalten.

Hast mal im Ziel fhem den event monitor beobachtet beim Befehl absetzen? Vielleicht findet sich da ein Hinweis.

Gesendet von meinem S3_32 mit Tapatalk

habe beide pis neu gestartet, was ich schon mal versucht hate, aber immer noch nichts.

in eventMonitor von Empfenger ist keine Ausgabe, in Log auch nicht.

der Sender meldet in Log immer Befehl ausgefürt, aber am Empfenger rührt sich Nichts.

Schalt mal zum testen das Passwort ab, also komplett rausnehmen...


Tapatalk iPhone, daher kurz gehalten.

hatte früher auch das versucht, aber nochmal!

Oder auf einer Seite die device mal umbenennen. Sollte nix ändern, a been man weiß nie...

Gesendet von meinem S3_32 mit Tapatalk

also paswort raus an beide pis, nichts. port 7072 an beide pis raus, nichts!

jetzt werde ich tatsächlich mit verschiedenen Namen arbeiten, was eigentlich kein sinn macht,
aber wer weiss?

Zitat von: Gerhard am 15 September 2017, 21:48:31
also paswort raus an beide pis, nichts. port 7072 an beide pis raus, nichts!

jetzt werde ich tatsächlich mit verschiedenen Namen arbeiten, was eigentlich kein sinn macht,
aber wer weiss?

ansonsten schau mal mit Wireshark nach, was wirklich da passiert

also, verschiedene Namen hat auch nict geholfen.

wenn diese 93_RFHEM.pm          15058 2017-09-12 19:30:29Z chris1284 Version bei euch
problemlos funktioniert, konnte sein, das bei mir mit den pi`s was nicht stimmt? oder mit FHEM?

version:

Latest Revision: 15066

File                 Rev   Last Change

fhem.pl              15042 2017-09-10 13:59:16Z rudolfkoenig
96_allowed.pm        14888 2017-08-13 12:07:12Z rudolfkoenig
98_autocreate.pm     15038 2017-09-10 10:00:18Z rudolfkoenig
98_dummy.pm          12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm        15055 2017-09-12 15:41:02Z rudolfkoenig
92_FileLog.pm        14888 2017-08-13 12:07:12Z rudolfkoenig
# $Id: 01_fronthem.pm 21 2015-02-13 20:25:09Z. herrmannj $
# $Id: 31_fronthemDevice.pm 21 2015-02-13 20:25:09Z. herrmannj $
98_help.pm           14847 2017-08-04 13:52:39Z betateilchen
02_HTTPSRV.pm        13976 2017-04-12 13:35:44Z neubert
33_readingsGroup.pm  14044 2017-04-20 07:48:44Z justme1968
93_RFHEM.pm          15058 2017-09-12 19:30:29Z chris1284
99_SUNRISE_EL.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
98_telnet.pm         15006 2017-09-05 09:37:33Z rudolfkoenig
99_Utils.pm          13259 2017-01-28 17:39:39Z rudolfkoenig
98_Verkehrsinfo.pm   13112 2017-01-16 19:18:49Z martins
98_version.pm        14745 2017-07-18 20:56:01Z markusbloch
59_Weather.pm        12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm        14888 2017-08-13 12:07:12Z rudolfkoenig

# $Id: fhconverter.pm 21 2015-02-13 20:25:09Z. herrmannj $
# $Id: fhwebsocket.pm 20 2015-02-03 16:14:14Z. herrmannj $
HttpUtils.pm         15041 2017-09-10 13:52:34Z rudolfkoenig
RTypes.pm            10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm     12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm    14862 2017-08-07 15:16:03Z rudolfkoenig
YahooWeatherAPI.pm   12465 2016-10-29 09:01:31Z borisneubert

fhemweb.js                 14906 2017-08-15 20:06:05Z rudolfkoenig
fhemweb_colorpicker.js     13580 2017-03-02 13:03:29Z justme1968
fhemweb_fbcalllist.js      13629 2017-03-06 20:50:43Z markusbloch
fhemweb_readingsGroup.js   13580 2017-03-02 13:03:29Z justme1968
fhemweb_readingsHistory.js 13580 2017-03-02 13:03:29Z justme1968
fhemweb_sortable.js        13629 2017-03-06 20:50:43Z markusbloch
fhemweb_uzsu.js            13580 2017-03-02 13:03:29Z justme1968

Exakt die gleiche Version. Hast mal das telnet device auf verbose 5 gestellt und geschaut?

Gesendet von meinem S3_32 mit Tapatalk

Hi Frank_huber,

mit telvet verbose 5 bekome auf beide Seiten folgende Meldungen:

2017.09.15 20:52:29 4: Connection accepted from telnetPort_192.168.0.42_46606
2017.09.15 20:54:04 3: Host present, executing command...
2017.09.15 20:54:04 3: Command executed.

@chris1284

ich habe inden beiden Instanzen das Passwort für telnetPort entfernt, und siehe da es funktioniert.

define telnetPort telnet 7072 global
attr telnetPort icon rc_TV
attr telnetPort room System
attr telnetPort verbose 5

# define allowed_telnetPort allowed
# attr allowed_telnetPort password SiLiCon
# attr allowed_telnetPort validFor telnetPort


alerdings ich bekomme an andere Stellen ständig Meldungen, dass das Password für telnetPort nicht gesetzt ist.

Daher meine Fragen, benutzt ihr das Password für telnetPort und gleichzeitig RFHEM?, und wenn ja,
wie definiert ihr das pswd für telnetPort?

Chris ist es möglich, das der Fehler bei meinem telnetPort defines liegt?, oder ist die Auswirkung in RFHEM?

Gerhar

Zitat von: Gerhard am 16 September 2017, 13:45:59
@chris1284

ich habe inden beiden Instanzen das Passwort für telnetPort entfernt, und siehe da es funktioniert.

Code Auswählen Erweitern

define telnetPort telnet 7072 global
attr telnetPort icon rc_TV
attr telnetPort room System
attr telnetPort verbose 5

# define allowed_telnetPort allowed
# attr allowed_telnetPort password SiLiCon
# attr allowed_telnetPort validFor telnetPort


alerdings ich bekomme an andere Stellen ständig Meldungen, dass das Password für telnetPort nicht gesetzt ist.

Daher meine Fragen, benutzt ihr das Password für telnetPort und gleichzeitig RFHEM?, und wenn ja,
wie definiert ihr das pswd für telnetPort?

Chris ist es möglich, das der Fehler bei meinem telnetPort defines liegt?, oder ist die Auswirkung in RFHEM?

Gerhar

Telnet-Passwort:
defmod allowed_telnetPort allowed
attr allowed_telnetPort password myPassword
attr allowed_telnetPort validFor telnetPort


RFHEM definition:
defmod PI_DG RFHEM 192.168.12.54 myPassword
attr PI_DG stateFormat statedev


Hallo Frank, danke!

aber genau den allowed_telnetPort musste ich entfernen damit es funktioniert.
Ich hatte es bis jetzt genau so wie du es vorschlägst gehabt, aber so funktioniert es nicht!!!
nur ohne allowed_telnetPort funktioniert es, wenigstens bei mir?

Gerhard

Hallo chris1264,

wenn ich die Passworter der telnetPorts definiere (allowed_telnetPort)
defmod allowed_telnetPort allowed
attr allowed_telnetPort password myPassword
attr allowed_telnetPort validFor telnetPort


folgende Logeinträge
Sender:
2017.09.16 16:12:01 3: Host present, executing command...
2017.09.16 16:12:01 3: Command executed.
Empfenger:
2017.09.16 14:13:26 4: Connection accepted from telnetPort_192.168.0.42_38030


also, die Kommunikation zwischen Sender und Empfenger findet statt, aber der Empfenger führt den set Befehl nicht aus.
schalte ich das Passwort beim Empfenger aus, dann wird der set Befehl ausgeführt.

Meine Vermutung ist, dass RFHEM vllt. Password nicht richtig verarbeitet. Kannst du das nachfolziehen?,
oder mir Hinweise geben wie ich es weiter untersuchen soll.
Fazit: ohne Password funktioniert, mit Password funktioniert nicht!!

Danke, Gerhard

was hat denn dein passwort so für sonderzeichen?

gerade getestet. funktionier mit passwort einwandfrei. das automatische update sowie der st cmd befehl

keine sonderzeichen, einfach: SiLiCon

ich habe in Modul RFHEM ein paar Helperausgaben eingefügt, und festgestellt, das RFHEM alle richtig sendet!

die Befehle kommen in telnet beim Empfänger auch an, aber werden nicht ausgeführt?

da es nicht am Sender (RFHEM) liegt, wie kann ich im Empfenger (telnet hat schon verbose 5) weitersuchen?
wie gesagt ohne Paswort funktioniert der Empfenger, mit nicht!

ich habe keine Ideen mehr.

Im allowed device kann man als attr angeben, welche Befehle ausgeführt werden dürfen, weiß gerade den Namen dafür aber nicht, vielleicht hilft das ein wenig weiter...


Tapatalk iPhone, daher kurz gehalten.

Mir fiel vor einiger Zeit auf, dass bei mir RFHEM ebenfalls nicht mehr funktioniert hat. Habe eben damit rumgespielt, zwischendrin dachte ich, eine Lösung zu haben, aber mal geht es und mal geht es nicht. Jetzt habe ich das Passwort entfernt, da ich sowieso allowedfrom definiert habe. Ohne Passwort ist derweil alles OK!

Ja, ein komisches sporadisches Fehlverhalten ist mir auch aufgefallen.
Hängt evtl mit den Änderungen in Blocking.pm zusammen?

Hatte Anfangs mein Netzwerk im Verdacht. Es hat bei mir begonnen als ich meine IP-Adressen umstrukturiert habe.
Hat sich dann aber als falsche Vermutung herausgestellt.

Meine Lösung war dann für jedes RFHEM device auf der Gegenseite einen eigenen Telnet Port zu öffnen.
Also weiterhin mit Passwort, aber eben dedizierte Ports.
Seither läuft das wieder stabil.

Ein Verbesserungsvorschlag wenn es erlaubt ist:
Es gibt ja mittlerweile eine Prüfung ob die Gegenseite erreichtbar ist vor der Ausführung.
Wie wäre es denn mit einer "retry" Option?
könnte mit 2 Atributen geregelt werden. "retryCount" und "retryWait"

Ich hatte das gleiche Problem. Ohne das telnet Passwort gehts. der direkt eingegebene Befehl set LED1 on funktioniert auf dem entfernten pi nur, nachdem ich das telnet-pw entfernt hatte. Nun funktioniert es aber sicher und regelmäßig.
Die ausgelesenen Werte  (Temperatur) eines Umweltsensors wurden (mit telnet-pw) manchmal übertragen, manchmal nicht, manchmal mit großer Verzögerung. Ohne telnet-pw funktioniert es nun. Es sieht so aus, als ob die Verbindung zwar steht, aber die Kommunikation abbricht und irgendwelche timeouts die Sache verpfuschen.

Bitte gleich mal um Entschuldigung, wenn ich einen entsprechenden Post übersehen habe. Aber ich will mir hierbei kein Eigentor schießen und frage deshalb lieber erst mal.

Wenn ich auf zwei Instanzen RFHEM installiere für ein Gerät, das z.B. an Instanz B angebunden ist und an Instanz A als Dummy vorliegt und auf beiden Instanzen die Attribute RFHEMdevs und RFHEMevents anlege, schaffe ich dann eine Endlosschleife?

Hintergrund: Mein Chromecast ist an einem Raspberry angelegt mittels GOOGLECAST (Instanz B). Das Hauptsystem läuft auf dem Cubie (Instanz A). Jetzt sollen einerseits die Eingaben an der Hauptinstanz über RFHME an Instanz B und den Chromecast übertragen werden (so z. B. Pause bei Telefonanruf), andererseits aber die anderweitig am Chromecast und damit auf Instanz B vorgenommenen Einstellungen auch auf die Hauptinstanz (Instanz A) übertragen werden, damit das auch hier im UI erscheint.

Zitat von: duke-f am 23 März 2018, 17:10:05
Bitte gleich mal um Entschuldigung, wenn ich einen entsprechenden Post übersehen habe. Aber ich will mir hierbei kein Eigentor schießen und frage deshalb lieber erst mal.

Wenn ich auf zwei Instanzen RFHEM installiere für ein Gerät, das z.B. an Instanz B angebunden ist und an Instanz A als Dummy vorliegt und auf beiden Instanzen die Attribute RFHEMdevs und RFHEMevents anlege, schaffe ich dann eine Endlosschleife?

Hintergrund: Mein Chromecast ist an einem Raspberry angelegt mittels GOOGLECAST (Instanz B). Das Hauptsystem läuft auf dem Cubie (Instanz A). Jetzt sollen einerseits die Eingaben an der Hauptinstanz über RFHME an Instanz B und den Chromecast übertragen werden (so z. B. Pause bei Telefonanruf), andererseits aber die anderweitig am Chromecast und damit auf Instanz B vorgenommenen Einstellungen auch auf die Hauptinstanz (Instanz A) übertragen werden, damit das auch hier im UI erscheint.

Würde vermuten ja.
Du brauchst rfhem nur auf dem sendenden fhem.
Beim empfangenden reicht ein Telnet Port.
Am besten ohne password und mittels allowedfrom auf die IP des senders festzurren.

Kannst ja wenn du das gleiche Gerät in zwei Richtungen klonen musst auch die Readings einschränken.
Da kannst dann deinen loop auch vermeiden.

Mit dem Handy online, daher kurz gefasst...

Naja, es soll eben in beide Richtungen gesendet werden. Einmal vom UI am Hauptsystem an den Chromecast am Nebensystem, einmal vom Nebensystem die dort vorgenommenen Eingaben und Einstellungen ans Hauptsystem.

Als Alternative zu RFHEM kannst du auch MQTT einsetzen - ich habe bei mir umgestellt und bin sehr zufrieden damit...

Gesendet von meinem SM-G935F mit Tapatalk

Zitat von: duke-f am 23 März 2018, 18:34:28
Naja, es soll eben in beide Richtungen gesendet werden. Einmal vom UI am Hauptsystem an den Chromecast am Nebensystem, einmal vom Nebensystem die dort vorgenommenen Eingaben und Einstellungen ans Hauptsystem.

Jeweils mit allen readings?
Das würde ich sagen geht nicht.

Mit dem Handy online, daher kurz gefasst...

Mqtt nehmen, sinnvoll einstellen (sonst gibt es auch lustige Schleifen), dann geht es schnell, einfach und ressourcenschonend.  :)

@hexenmeister: Mqtt sehe ich mir an. Hatte ich anderweitig auch schon mal im Visier.
@nein, die readings müssen nur jeweils in eine Richtung, von der realen Device zum Dummy für die Darstellung. In die andere Richtung müssen nur die abzusetzenden Befehle wie play, pause usw. Wahrscheinlich mache ich das mittel notify, wie in der Doku angegeben.
Ich hatte mal was ähnliches mit GetHttpFile oder auch bei der Vernüpfung meiner IT-Steckdosen mit den zugehörigen ELRO-Fernbedienungen. In die eine Richtung muss per set übertragen werden, um wirklich zu schalten, in die Gegenrichtung ein setstate, so war das da.

Zitat von: duke-f am 23 März 2018, 20:38:29
@nein, die readings müssen nur jeweils in eine Richtung, von der realen Device zum Dummy für die Darstellung. In die andere Richtung müssen nur die abzusetzenden Befehle wie play, pause usw. Wahrscheinlich mache ich das mittel notify, wie in der Doku angegeben.

Attribut RFHEMdevs : eine Komma getrennte Liste von Devices. Alle events dieser Devices werden autom. an die entfernte Instanz weitergeleitet (sprich wenn deviceX ein event wie temperature: 29.3 generiert, wird ein "set rfhem_device cmd setreading deviceX  temperature 29.3" angesetzt). Das Device auf der entfernten Instanz (dummy zb) muss genau so heißen wie das device welches das event generiert (hier folgt noch eine prefix-attribut so das zb das event an [prefix]devicename weitergeleitet werdne kann)

Attribut RFHEMevents:  eine Komma getrennte Liste von events (readings). Nur diese Readings der devices in RFHEMdevs werden weitergeleitet - noch im test


Mit dem Handy online, daher kurz gefasst...

Besten Dank, probiere ich. war doch gar nicht so kurz;)

Zitat von: duke-f am 24 März 2018, 11:55:57
Besten Dank, probiere ich. war doch gar nicht so kurz;)

Copy & paste von weiter oben. Das geht. [emoji56]

Mit dem Handy online, daher kurz gefasst...

Hallo Leute,

ich habe ebenfalls wie Gerhard Probleme das Modul mit gesetztem telnet passwort (oder auch globalpasswort) zum laufen zu bekommen.

Ohne gesetztes telnet Passwort werden die Befehle einwandrei übertragen und ausgeführt. Sobald das Passwort gesetzt ist werden die Befehle zwar gesendet, aber mindestens nicht ausgeführt.

Chris, weißt du da Rat?

Danke.

Gruß
Christian

Leider nein, nutze das Modul schon lange nicht mehr und habe auch keine Möglichkeit es zu testen/ umzubauen dass es mit PW läuft

MQTT könnte ggf. eine Lösung sein. Darüber unterhalten sich bei mir auch mehrere Instanzen miteinander. Läuft zuverlässig und performant.

Oder separate Telnet ports. Diese ohne Passwort aber nur für die eine interne IP freigegeben.
So hab ich das dann umgesetzt.

defmod telnetPort_for_OG telnet 7777 global
attr telnetPort_for_OG allowfrom 192.168.xxx.xxx
attr telnetPort_for_OG group System
attr telnetPort_for_OG room SYSTEM


Gesendet von meinem Doogee S60 mit Tapatalk

Mal diesen alten Thread wieder hochholen. :-)

Hat denn mal jemand das Attribut RFHEMevents zum laufen bekommen?
Egal wie ich dort die Readings eintrage, es tut sich nichts.

Wenn ich mir als Nicht-Entwickler den Code des Moduls anschaue verstehe ich erstmal nichts.
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/93_RFHEM.pm
Es fällt mir aber auf dass evtl in den Zeilen 162 bis 169 das "my $setcmd" fehlt?
Kann da mal bitte ein wissender drüber schauen? danke!

Zitat von: Frank_Huber am 17 Dezember 2019, 09:37:43
Es fällt mir aber auf dass evtl in den Zeilen 162 bis 169 das "my $setcmd" fehlt?

der Block ist doch laut Kommentar nur für Logging da das Device aus Zeile 152 nicht passt

Zitat von: Wzut am 17 Dezember 2019, 10:13:47
der Block ist doch laut Kommentar nur für Logging da das Device aus Zeile 152 nicht passt

Wie gesagt, bin kein Entwickler. :-)

Das Modul hatte bei mir einige Abstürze, wenn der Partner nicht erreichbar ist. Ich habe folgenden Fix eingebaut

diff 93_RFHEM.pm 93_RFHEM.pm.orig
86,93c86,88
<                 if (!$socket) {
<                       Log 3, "RFHEM ERROR. Can't open socket to $HOSTNAME \n";
<                       return undef
<                 } else {
<                       print $socket $msg;
<                       Log3 $name, 3, "Command executed.";
<                 };
<         } else { Log3 $name, 3, "Error: host not present!"; }
---
>               print $socket $msg;
>               Log3 $name, 3, "Command executed."; }
>       else { Log3 $name, 3, "Error: host not present!"; }
242c237
< =cut
---
> =cut

Zitat von: plin am 20 Januar 2020, 21:23:07
Das Modul hatte bei mir einige Abstürze, wenn der Partner nicht erreichbar ist.

Wie äußerten sich die Abstürze?

Zitat von: chr2k am 21 Januar 2020, 10:33:21
Wie äußerten sich die Abstürze?

Moin,

in den Fällen, bei denen es bei mir in der Vergangenheit zu solchen Situationen kam, ist FHEM abgestürzt (kein Webzugriff mehr etc.), daher begrüße ich den Patch und werde ihn in Kürze implementieren.

Greetz
Eldrik

ist der RFHEM Maintainer darüber informiert?
wäre ja dann begrüßenswert den Patch offiziell einzuchecken.

Zitat von: plin am 20 Januar 2020, 21:23:07
Das Modul hatte bei mir einige Abstürze, wenn der Partner nicht erreichbar ist. Ich habe folgenden Fix eingebaut

Code Auswählen Erweitern

diff 93_RFHEM.pm 93_RFHEM.pm.orig
86,93c86,88
<                 if (!$socket) {
<                       Log 3, "RFHEM ERROR. Can't open socket to $HOSTNAME \n";
<                       return undef
<                 } else {
<                       print $socket $msg;
<                       Log3 $name, 3, "Command executed.";
<                 };
<         } else { Log3 $name, 3, "Error: host not present!"; }
---
>               print $socket $msg;
>               Log3 $name, 3, "Command executed."; }
>       else { Log3 $name, 3, "Error: host not present!"; }
242c237
< =cut
---
> =cut

Moin, zusammen!

Bei mir startet sich FHEM nicht mehr, sobald sich der entfernte Raspberry mal verabschiedet hat.

Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 86

Behebt dein Fix das zufällig?

Könntest du deine komplette 93_RFHEM.pm hochladen? Ich bekomme die DIFF Ausgabe da auf den ersten Blick nicht rein :-\

Danke für die Hilfe!

Gruß, Martin

Vieleicht etwas spät, aber bei mir hat folgende geholfen:
sudo cpan IO::Socket::INET

Moin zusammen!

Heute hat sich FHEM mal wieder mit dem Fehler

Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 86

aufgehängt, als ich das Remote-System neu gestartet habe.

Zitat von: Rossi am 17 März 2020, 18:25:25
Vieleicht etwas spät, aber bei mir hat folgende geholfen:

Code Auswählen Erweitern

sudo cpan IO::Socket::INET

IO::Socket::INET ist bei mir auf dem aktuellen Stand.

Zitat von: plin am 20 Januar 2020, 21:23:07
Das Modul hatte bei mir einige Abstürze, wenn der Partner nicht erreichbar ist. Ich habe folgenden Fix eingebaut

Code Auswählen Erweitern

diff 93_RFHEM.pm 93_RFHEM.pm.orig
86,93c86,88
<                 if (!$socket) {
<                       Log 3, "RFHEM ERROR. Can't open socket to $HOSTNAME \n";
<                       return undef
<                 } else {
<                       print $socket $msg;
<                       Log3 $name, 3, "Command executed.";
<                 };
<         } else { Log3 $name, 3, "Error: host not present!"; }
---
>               print $socket $msg;
>               Log3 $name, 3, "Command executed."; }
>       else { Log3 $name, 3, "Error: host not present!"; }
242c237
< =cut
---
> =cut

Hat jemand mal diesen Fix erfolgreich eingebaut und kann die komplette 93_RFHEM.pm zur Verfügung stellen?

Als Update ist eine gefixte Version leider nicht zu beziehen.


Beste Grüße,
Martin

Hallo wäre auch daran interessiert
Habe auch diese Fehlermeldung:
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 86.
aber bei mir startet das System danach neu!!!
Könnte sein das meine powerLan Verbindung zu diesem Zeitpunkt kurz weg ist und das System nichts an das andere senden kann

Wäre ja froh wenn ich den Neustart wegbekomme......
Gruß
Helmut

Dann ersetzt Du (mit einem vernünftigen Editor, der kein Windows Sonderzeichen hinzufügt) in RFHEM.pm die Zeilen 86-88
print $socket $msg;
Log3 $name, 3, "Command executed."; }
else { Log3 $name, 3, "Error: host not present!"; }


durch die von plin:
                 if (!$socket) {
                       Log3 $name, 3, "RFHEM ERROR. Can't open socket to $HOSTNAME ";
                       return undef
                 } else {
                       print $socket $msg;
                       Log3 $name, 3, "Command executed.";
                 };
         } else { Log3 $name, 3, "Error: host not present!"; }

und evtl. stezt Du noch attr global exclude_from_update

EDIT: Log zu Log3 geändert

Herzlichen Dank
Gestern Vormittag eingebaut und seit dem ist Ruhe
Many thanks
Helmut

Guten Abend,

hat gut funktioniert.
Habe leider vergessen exclude from update einzubauen.
Nur was nun komisch ist (für mich - keine Ahnung)
Habe nun am Mac mit BBEdit die 93_RFHEM.pm nochmals bearbeitet und hochgeladen.
Neustart und nun kann FHEM das Modul RFHEM  nicht mehr laden und meine Instanz von FHEMHaus ist auch nicht mehr im System vorhanden?
Was hab ich da wieder verhaut?
Gruß
Helmut

Was hat die Log beim Start gesagt?

Ich würde zuerst die Syntax genau prüfen.

Man braucht nicht unbedingt Fhem neu zu starten. Ein "reload 93_RFHEM" hätte dir schon die mögliche Fehler gezeigt.

Danke für den Hinweis mit reload
Diese sch... eindoof Produkte. Ich verwende für meine FHEM Dokumentation Onenote. Hier wird alles festgehalten.
Und da hat sich ein Copy Paste Fehler eingeschlichen.
Habe nun nochmals aus dem OriginalPost die Zeilen kopiert und nun funktioniert es

DANKE
Nice weekend
Helmut

Moin
Ich habe da auch mal ein Problem.
Nach durchlesen des Threads bin ich mir nur gar nicht mehr so sicher, dass ich mit RFHEM auf dem richtigen Weg bin.
Ich habe einen HM Sensor, den ich an ein anderes fhem uebertragen moechte. Das klappt auch ganz gut. Aber leider wird der "state" nicht im dummy device erzeugt.
Mit state wollte ich eigentlich etwas triggern, so dass es fuer mich wichtig waere.
So wie ich jetzt nach lesen des Threads verstanden habe, ist RFHEM eigentlich fuer das Schalten vom entfernten fhem aus ist.
Aber mit fhem2fhem hatte ich mich damals total schwer getan! Und die Diskussion ueber readingsproxy konnte ich nicht nachvollziehen, bzw. erkenne ich nicht den Weg wie mir das helfen koennte!?
Gruss Christoph

Moin
Ich beantworte mir das dann mal selbst.
RFHEM ist, wie der Threadtitel hier ja auch aussagt, fuer Befehle an ein entferntes fhem. Das das umgekehrt bei mir mit einem Device schon mal geklappt hat, lag daran, dass ich ein spezielles reading brauchte, welches auch zurueck kam.
Ich habe jetzt dann noch mal FHEM2FHEM probiert, und bin total zufrieden.
Gruss Christoph

Hallo,

wenn ich bei dem Remote FHEM ein Telnet Passwort setze kann ich mich nicht mehr darauf verbinden. Was kann da sein?
Vom FHEM-Master ein Telnet mit dem Passwort funktioniert, nur die FHEM Instanz am Master kann mit PW nicht mit dem Client reden.

Bringt ein Telnet Passwort überhaupt ein Sicherheitsplus?
Beide FHEM Instanzen im gleichen Netz hinter einer Firewall.



LG
KOAL

Zitat von: KOAL am 01 Januar 2021, 23:13:10
wenn ich bei dem Remote FHEM ein Telnet Passwort setze kann ich mich nicht mehr darauf verbinden. Was kann da sein?
Vom FHEM-Master ein Telnet mit dem Passwort funktioniert, nur die FHEM Instanz am Master kann mit PW nicht mit dem Client reden.

Ich meine mal irgendwo aufgeschnappt zu haben, dass RFHEM nur ohne Telnet-Passwort funktioniert.

@chr2k
Es steht im Wiki (https://wiki.fhem.de/wiki/RFHEM) aber anders:
Definieren des Device
Nun müssen wir uns ein Device anlegen. Dies machen wir klassisch in der Kommandozeile mittels

define Name RFHEM hostip [:port] [pw]

Für mich sieht pw wie Passwort des Telnet Port aus.

jedoch soll ssh nicht möglich sein:
SSL Auth
SSL Auth ist leider auch nicht möglich.

Ich habe aber auch zur Zeit das Problem, dass es nur ohne Passwort funktioniert...

Ich habe für rfhem ne eigene Telnet Instanz ohne Passwort, dafür aber nur eine interne IP erlaubt. Das ist mir da sicher genug.

chris1284 hatte auf Seite 12 in diesem Treat die Funktion getestet und als funktionierend bestätigt. Ich könnte mir vorstellen, dass das Kennwort auf seinem Port noch nicht richtig gesetzt war, denn das war bei mir auch einmal so - und funktionierte nur scheinbar. -> s. Check

Gemäß der Ausführung im Wiki fuktioniert RFEHM mit Port Kennwort leider NICHT. Ich habe mit verschiedensten Geräten 3 RPi und ein debian server erfolglos den ganzen Tag probiert: Absicherung des Port mit einfachsten Kennwort SiLiCon Meine diversen Tests mit globalpasswort, passwort usw. im allowed Modul funktionieren, bringen aber keine Änderung für RFHEM. Die telnet Verbindung wird zwar aufgebaut, jedoch führt das Modul die Befehle auf der Empfängerseite nicht aus. Es funktioniert aber immer über die Konsole nach Eingabe des Port Kennwort (s. unten Check). Ein Fehler wird auch mit Verbose 5 weder beim Sender noch auf der Empfänger Seite angezeigt:
Beim Sender:
Host present, executing command...
Command executed.
Beim Empfänger:
Connection accepted from telnetPortClient_10.10.10.10_34708

Absicherung mit
-allowfrom  ("Nur Zugriff auf einen eigenen Port über eine bestimmte IP Adresse")
und
-Port [PW]

Wichtig scheint jedoch zu sein, dass für jede Verbindung (z.B. zu jedem weiteren RPi) oder auch (Gegen-)Richtung ein (zusätzlicher) eigener Port verwendet werden muss.

Client / Empfänger Seite / FHEM Seite auf der die Befehle ausgeführt werden sollen:

Internals:
   DEF        7774 global
   FD         204
   FUUID      xxx
   FVERSION   98_telnet.pm:0.237270/2021-02-12
   NAME       telnetPortClient
   NR         734
   PORT       7774
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2021-04-05 11:25:13   state           Initialized
Attributes:
   allowfrom  10.10.10.10
   group      RFHEM
   room       System

RFHEM Seite / Seite von der die Befehle gesendet werden:
Internals:
   DEF        10.10.10.20:7774 SiLiCon
   FUUID      zzz
   FVERSION   93_RFHEM.pm:0.150580/2017-09-12
   HOSTNAME   10.10.10.20
   Interval   900
   NAME       RFHEM_Server
   NR         17
   NTFY_ORDER 50-RFHEM_Server
   PASSWORD   SiLiCon
   PORT       7774
   STATE      present
   TYPE       RFHEM
   READINGS:
     2021-04-05 11:21:17   ipadress        10.10.10.20
     2021-04-05 11:21:17   statedev        present
Attributes:
   group      RFHEM
   room       System
   stateFormat statedev

Check: Auf der Console z.B. über Putty auf dem Client RPi anmelden und dann über telnet 10.10.10.20 7774 testen, ob der Port das Passwort annimmt und nach der Anmeldung einfache Befehle wie set Lampe1 on ausgeführt werden.



Es wäre schön, wenn ein Entwickler hier die Absicherung über ein Kennwort ermöglichen könnte.

Ich kann leider nur bestätigen, dass es bei mir ebenfalls nur ohne Passort funktioniert, dann aber sehr gut.

Sehr, sehr schade, aber so leider nicht für mich geeignet.

Cheers
mi.ke

Hallo mi.ke,

schau Dir mal fhem2fhem an. Da kannst Du eine verschlüsselte ssh-Verbindung nutzen.

Viele Grüße
Jürgen.

Zitat von: juemuc am 08 April 2021, 20:59:42
schau Dir mal fhem2fhem an. Da kannst Du eine verschlüsselte ssh-Verbindung nutzen.

Hi Jürgen,

ja Danke, ich weiss.
Alle meine Instanzen sind über FHEM2FHEM an den Master verbunden.
RFHEM hat (hätte) aber seinen eigenen (ergänzenden) Charme.
Gerade wenn Du mehr als 2-3 Systeme verbunden hast.
cheers
mi.ke



edit: Konjunktiv eingefügt

Guten Morgen,

ich wollte gestern auch RFHEM auf einer neuen FHEM Instanz einrichten und habe mich ständig gewundert, warum es nicht geht. Bis ich irgendwann auf die Idee kam, dass RFHEM über Telnet versucht zu kommunizieren. Bei neuen Instanzen gibt es allerdings keine Telenetport, wenn man diese nicht selbst anlegt. Daher wäre es aus meiner Sicht sinnvoll einen entsprechenden Hinweis in der CommandRef hinzuzufügen, dass der empfangende Rechner eine Telnet Verbindung brauch ;)

Hallo,

Ich suche nach einer Lösung um ein Device bi-direktional über zwei FHEM Instanzen zu spiegeln.
Also soll auf Instanz 1 z.B. ein on/off Schalter (Relais) realisiert sein, welches diese Instanz auch selbst verwaltet (also z.B. über ein DOIF oder Webinterface ein/ausschaltet).
Auf Instanz 2 läuft jetzt z.B. TabletUI oder GoogleAssistant und der Schalter soll am Tablet korrekt angezeigt werden (an/aus) aber auch geschaltet werden können. Das kann jetzt ein Dummy sein, das aber auf Instanz 1 zurücksynchroniert werden muss.
(Warum verlagere ich nicht die Logik komplett nach Instanz 2? Weil das DOIF sehr viele Werte zur Entscheidungsfindung braucht und ich nicht alle nach Instanz 2 spiegeln möchte - ist außdem sauberer getrennt)

Mein Problem ist, da es mit FHEM2FHEM recht umständlich ist bzw. ohne das Risiko einer Loop gar nicht vollständig geht.
Ich habe jetzt RFHEM noch nicht probiert, aber zumindest vom Handling her scheint es einfacher zu sein (nicht so viele umständliche Notifies), aber ich vermute, dass bidirektional auch nicht gehen wird da es dann wieder zu eine Schleife kommt, oder?

Hat da jemand eine Idee/Lösung?

Ich hatte schon überlegt bei Gelegenheit selber ein Modul wie RFHEM zu bauen, allerdings so, dass die Befehle erstmal durch ein Modul in der Empfängerinstanz gehen (also statt "set dummydevice on" z.B. ein "set RFhem exec set dummydevice on"). Dieses checkt dann, ob ein update des Device überhaupt notwendig ist und durchbricht damit eine eventuelle Schleife. Zusätzlich könnte es gleich eine Autocreate Funktion (einfach Dummy anlegen) implemementieren.

Gruß,
Jörg

Hallo Jörg,

es gäbe viele Möglichkeiten. FHEM2FHEM ist nicht kompliziert - aber ich würde es nicht bidirektional einsetzen.
2 Geräte (wert und wetter) komplett übertragen
raspib -> F2F -> raspib3
defmod F2Fb FHEM2FHEM raspib:7072 LOG:wert.*|wetter
attr F2Fb addStateEvent 1
attr F2Fb room Status

defmod wert dummy
attr wert room Status

defmod wetter dummy
attr wetter room Outdoor

Mit rfehm Befehle im anderen FHEM auslösen:
raspib3 -> RFHEM -> raspib
defmod Rraspib RFHEM 192.168.56.80
Kann irgendein Befehl sein den das FHEM auf raspib versteht.
set Rraspib cmd set wert 25
Ist dann eigentlich völlig getrennt - aber eben auch "platt" nicht gespiegelt. ;)

Moderner wäre es: Brücken mit mqtt bauen.

Gruß Otto

Hallo Otto,

Ich probiere es jetzt mal mit Rfhem. Mit FHEM2FHEM hatte ich auch schon Probleme, dass beim forced restart einer Device (z.B. wenn mal eine Sicherung fliegt) die Verbindung brach lag bis hin zur Blockade. Ich hoffe mal da ist Rfhem robuster. Ausserdem gefällt mir der "push" Ansatz etwas besser (FHEM2FHEM pustet meines Wissens ja erstmal so ziemlich alle Events rüber und lässt die Remote Instanz wählen, während RFhem nur für gewählte Devices überhaupt etwas an die Remote Instanz schickt).

Mein Ansatz für birektional ist jetzt:

Device in RFhem eintragen, Remote Dummy erzeugen, Zweites Remote Dummy erzeugen (z.B. mit suffix _remote)
DOIF welches den Wert vom ursprünglichen Dummy auf das _remote überträgt (hier reicht ein DOIF für viele Werte). Da DOIF im Normalmodus nur einmal pro Zustandsänderung anspringt, wird automatisch eine Schleife verhindert (ein zweites "on" erzeugt kein Event mehr).

Dann das selbe in Retour, nur das _remote auf die Ursprungsinstanz übertragen wird und das dortige DOIF den Originalwert setzt.

Das klappt ganz gut, ist aber immer noch recht umständlich (braucht je ein zusätzliches Dummy und DOIF).
Wenn man die Befehle gleich durch die Remote RFhem Instanz "filtern" würde, wie in meinem vorigen Post beschrieben, könnte man sich das sparen.

Grundsätzlich geht was ich oben beschrieben habe auch mit FHEM2FHEM, aber da braucht man dann je ein Notify mit einer entsprechenden Logik - und das ist was ich mit "umständlich" meinte.

Jörg

Ich denke, Du liegst falsch mit deiner Meinung über FHEM2FHEM.
Mit meiner obigen Logik:

• braucht es kein notify, was Du siehts ist alles was man braucht. Der Dummy wird automatisch gefüllt. Alle anderen Informationen im Web (notify, clonedummy usw.) sind uralt!
• werden eben nicht alle Events gepustet - sondern exakt die abbonniert die ich im regExp eingetragen habe.

Wieder was gelernt.
Wobei ich noch nicht durch die Bedeutung des "defmod" gestiegen bin. Denn das scheint ja dafür verantwortlich zu sein, dass das Dummy befüllt wird, oder? Denn das "addStateEvent" verstehe ich nach Doku so, dass es lediglich auch das "state" reading mit berücksichtigt, oder?

Das wäre mal ein Doku Update fällig  :)

Jörg

Hallo Jörg,

defmod ist lediglich die übliche Raw Definition Schreibweise des define. define legt ein neues Device an, defmod würde ein Vorhandenes modifizieren oder wenn nicht vorhanden ein Neues anlegen.

Das oben ist lediglich eine Kopie meiner komplette Umgebung für die Übertragung von zwei Werten. Die Namensgleichheit des Dummy sorgt dafür das er befüllt wird.

der Readingname state fehlt normalerweise  bei FHEM im EVENT, addStateEvent fügt diesen Readingnamen wieder zum EVENT hinzu.

Gruß Otto

Ich habe jetzt noch ein wenig mit RFHEM rumgespielt und wieder geschafft eine Loop zu erzeugen. Bei Gelegenheit muss ich mir wirklich mal MQTT ansehen.
Habe es jetzt einfach so umgestellt, dass nur eine Seite Änderung triggert. Ist erstmal nicht ideal, aber wenigsten ohne Risiko.

Mir ist allerdings dabei aufgefallen, das RFHEM nicht ganz zuende programmiert ist. Der Zweig mit eingeschränkten events funktioniert nicht.
Da wird erstens die Variable "$exteventparts" falsch befüllt und dann fehlt der ganze Ausführungszweig für der das reading setzt.
Ich denke das müsste so aussehen:
foreach $extevent (@{$extDevHash->{CHANGED}}) { #für jedes event des externen device / dort geänderte readings
my @exteventparts = split (": ", $extevent);
foreach $event (@myevents) { # mit jedme event aus rhfme attribut
if ($event eq $exteventparts[0]) {
Log3 $name , 3,  "RFHEM $name - triggered by Device:$extDevName with event $event";
my @eventparts = split (": ", $extevent);
Log3 $name , 3,  "RFHEM $name - event: $eventparts[0] with value $eventparts[1] ...";
    my $setcmd = "set $name cmd setreading $extDevName $eventparts[0] $eventparts[1]";
    fhem( $setcmd );
}
}
}

Hab ich zumindest mal so bei mir gepatcht und jetzt funktionieren eingeschränkte events.
Ich glaube außerdem das normale "set device on" events nicht korrekt behandelt werden (da fehlt ja im event dann der reading name), hab das aber jetzt nicht weiter verfolgt.

Jörg

Hallo Jörg,

wenn Du eine Schleife bauen "willst" schaffst Du das mit jeder Technologie. Einfach "blind" jede Änderung von a nach b und von b nach a replizieren. Es sein denn man baut etwas ein, was erkennt das es eine Schleife ist. Meines Wissen ist weder RFHEM, FHEM2FHEM noch MQTT damit ausgestattet - also musst Du selbst dafür sorgen.

Die Übertragung von set device on über RFHEM funktioniert bei mir einwandfrei.

Gruß Otto

Hallo Otto,

die Schleife hatte ich eigentlich abgefangen. Manuell hat auch alles geklappt. Bei der automatischen Auslösung von mehreren Devices ist aber dann der Wurm reingekommen. Irgendwie hat Instanz 1 gleichzeitig "on" geschaltet während Instanz 2 "off" geschaltet hat - und das ging dann hin und her (mein "Schutz" hat nur Event Schleifen durchbrochen die versuchen den selben Zustand mehrfach zu setzen).

Also bei mir geht "set device on" nicht. Das da was schief läuft sieht man schon mal an der WARNING beim ersten Versuch (Zeilennummern sind wahrscheinlich verschoben,da meine Testversion):
2021.08.01 09:06:00 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_RFHEM.pm line 158.
2021.08.01 09:06:00 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_RFHEM.pm line 159.

Das kommt daher, das er versucht auf $eventparts[1] zuzugreifen - im Fall eine "set device on" ist dieses aber undefiniert.
Dann hab ich ein Logging eingebaut welcher Befehl abgesetzt wird und ein
set rtest on
triggert
setreading rtest on
Was natürlich nicht geht - da müsste er erkennen, das es um "state" geht und
setreading rtest state on
machen, oder was verstehe ich hier falsch (oder hab ich eine falsche Version - aber die kommt doch einfach über update?)

Und wie gesagt das Einschränken auf readings geht ohne meinen Patch gar nicht (und hier kann man "state" nicht als reading angeben, aber wenn man readings angibt, will man das wahrscheinlich auch nicht).

Hab mir überlegt, wie man rfhem einen simplen Schleifenschutz einbauen könnte:
Er merkt sich einfach in einer INTERNAL den Zeitstempel des letzten Triggers. Über ein Attribut setzt man einen Threshold fest (z.B. 2 Sekunden - wäre empirisch zu ermitteln wie schnell die Nachrichten hin und her flitzen). Wenn versucht wird das selbe reading innerhalb dieser Zeit nochmal zu setzen, dann ignoriert er es einfach. Das reicht dann auch auf einer "Seite" - ein "Echo" schadet ja meistens nicht solange es nicht wieder zurückgeworfen wird.

Ist der Author von Rfhem noch aktiv? Das Modul ist jetzt ja nicht wirklich komplex - vielleicht versuche ich mich mal an den Fixes/Verbesserungen...

Jörg

Moin Jörg,

chris1284  war Anfang Juli online. Das Modul hat seit 2017 keine Änderung erfahren.

In deinem System muss was verbogen sein. Bei mir funktionieren alle Befehle, auch setreading, völlig ohne Probleme.
Die Meldung im Log, der erste die Quittung eines set device wert und der zweite ein setreading device reading wert:
2021.08.01 10:12:52 3: Host present, executing command...
2021.08.01 10:12:52 3: Command executed.
2021.08.01 10:13:57 3: Host present, executing command...
2021.08.01 10:13:57 3: Command executed.


Aber ich hole einige wenige Werte aus einer anderen Instanz und schaffe eine Steuerinformationen dorthin. In keinem Fall führen meine geholten Werte zur Steuerung des gleichen Gerätes.

Gruß Otto

Hallo Otto,

ich hoffe wir reden nicht aneinander vorbei. Das "setreading" geht einwandfrei. Nur für den "state" einer device geht es nicht, da die Event message dann anders aussieht:
2021-08-01 11:09:16 dummy rtest off
2021-08-01 11:09:16 dummy rtest switch: off
Mit der "rtest switch: off" Syntax kommt rfhem zurecht und generiert ein "setreading rtest switch off. mit der "rtest off" syntax (für das "state" reading) klappt das nicht, da der Befehl "setreading rtest off" erzeugt wird, den FHEM mit dem Fehler
Usage: setreading <name> [YYYY-MM-DD HH:MM:SS] <reading> <value>
where <name> is a single device name, a list separated by comma (,) or a regexp. See the devspec section in the commandref.html for details.
quittiert.

Auch FHEM2FHEM hat für das "state" event eine Sonderbehandlung drin - das fehlt bei rfhem.
Da mir FHEM2FHEM doch etwas ausgereifter vorkommt, habe ich dafür einen Patch gegen Loops gemacht. Mal sehen was Rudi dazu meint: https://forum.fhem.de/index.php/topic,122300.0.html#new

Jörg

Du redest von der automatischen Erzeugung? Die verwende ich nicht. Alle meine Versuche verwenden die direkte Übergabe der Befehle: set rfhemdevice cmd set remotedevice on.

ZitatAttribute
RFHEMdevs
Eine durch Komma getrennte Liste von Geräten. Alle Events dieser Geräte werden autom. an die entfernte Installation gesendet. Auf der entfernten Seite muss es das Gerät mit selben Namen geben (zb ein Dummy).

RFHEMevents
Eine durch Komma getrennte Liste von Events. Alle diese Events ( der Geräte aus RFHEMdevs) werden autom. an die entfernte Installation gesendet

Hi Otto,

Alles klar. Ja ich meine das Hören auf Events um automatisiert Readings zu updaten. Da ist noch bisserl der Wurm im Modul.
Das ein direktes "cmd" funktioniert habe ich keine Zweifel.

Jörg

Hi Jörg,

dafür verwende ich ja FHEM2FHEM :)

Gruß Otto

Bitte um einen Hinweis wie ich weiterkomme.

Versuche via rfhem auf einem remote fhem ein "set Office on" auszuführen. Leider passiert nix.

Ich sehe auf dem Main FHEM die Meldung
Connection accepted from telnetPort_192.168.2.125_44264

und auf dem FHEM von dem ich das kommando ausführe nur die Erfolgsmeldung.
14:58:33 3: Host present, executing command...
2021.08.07 14:58:33 3: Command executed.

Wäre froh um einen HInweis.

Gruss&Dank
RS

Hallo rs,

Ich poste nochmal mein Beispiel aus #213 hast Du es so gemacht?

Mit rfehm Befehle im anderen FHEM auslösen:
raspib3 -> RFHEM -> raspib
defmod Rraspib RFHEM 192.168.56.80
Kann irgendein Befehl sein den das FHEM auf raspib versteht.
set Rraspib cmd set wert 25

Gibt es wirklich ein Gerät Office ?
Wo genau siehst Du die Meldung Connection ...?

Guten Morgen,

Ich würde gerne auf folgenden Fehler im Modul aufmerksam machen, welchen ich immer wieder habe:

https://forum.fhem.de/index.php/topic,122578.0.html

Vielleicht kann der gefixt werden? Ich selber kann nicht genau sagen woran es liegt bzw einen Patch erstellen, sorry

Hallo,

wie schon weiter oben im Thread beschrieben, scheinen mir Teile dieses Moduls noch unfertig zu sein und ich habe selber ein wenig dran rumgebastelt.
Bei der Gelegenheit hab ich das jetzt auch mal vom externen "ping" Befehl auf Net::Ping umgestellt, womit das Problem von Amenophis96 behoben sein sollte.

Changelog:
# Using Net::Ping for more stable detection of host
# Improved display of status/errors in reading
# added extra handling to sync "state" reading in case of plan "set xxx on" to be synced
# completed "events" case to actually issue a command if limited to certain events

Ohne Gewähr mal zum Ausprobieren - da ich nicht der Autor bin, werde ich Änderungen auch nicht einchecken.

Weitere Änderungsideen wären, die Logik der Device/Reading Auwahl auf die Methodik wie in FHEM2FHEM umzustellen.

Gruß,
Jörg

Dank dir, werde die Version die Tage mal testen und mich melden.

Kurzes Feedback, das Update scheint meinen RFHEM Problem behoben zu haben. Vielen Dank.

Wie ist denn hier der Stand des eigentlichen Inhaber des Moduls? Passiert da noch was oder wird es eigentlich nicht mehr offiziell gewartet?

Hatte einen kurzen Austausch mit Chris und er kann das Modul nicht weiter maintainen.
Ich spiele daher mit dem Gedanken es zu übernehmen, muss mir das aber erstmal noch genauer ansehen (und bin gerade ziemlich beschäftigt größere Updates an SignalBot vorzunehmen).

Vorab gleich die Frage:
Verwendet irgendjemand die Funktion Devices zu synchroniseren (ähnlich FHEM2FHEM nur push statt pull)?
Also letztendlich die Attribute RFHEMdevs und RFEHMevents?
Bei den Events bin ich mir fast sicher das dies keiner verwendet, da es gar nicht funktioniert.

Ich würde das nämlich wenn dann grundlegend ändern (nicht rückwärtskompatibel). Gibt es da Bedenken?

Jörg

Moin, ja, ich nutze das mit den Devices.
Damit spiegle ich zentrale Geräte auf alle Instanzen.
könnte man aber auch mit notify / doif machen wenn es rausfliegt.

Die Funktionalität wollte ich schon beibehalten, nur die Definition an FHEM2FHEM anpassen.
Ich finde das Prinzip von RFHEM grundsätzlich recht gut, da nur die notwendigen Daten übers Netz gehen, wogegen FHEM2FHEM m. E. erstmal alles übers Netz mithört und sich dann erst die relevanten Teile rauspickt.

Jörg

Nutze auch fhem device aber kein Problem, wenn du die Änderung vorher ankündigst und das der Preis dafür ist, dass du die Fehler behebst, dann vielen Dank und sehr gerne :)

Hallo Jörg,

ich habe Rudi anders verstanden. F2F sagt eventuell dem Sender, was es hören will.

Gruß Otto

ZitatF2F sagt eventuell dem Sender, was es hören will.

genau so!

Stimmt, ihr habt recht. Hab mir FHEM2FHEM nochmal genauer angeschaut und das Modul "abonniert" über das "inform" Kommando und eine Regexp nur das, was es auch sehen will.
Wieder was gelernt.

Also meine Fehlermeldungen bezüglich des Pings sind weg mit deiner letzten Version aber FHEMDevices scheint nicht mehr zu funktionieren. Also werden keine Daten mehr automatischen durch RFEHM an andere Instanzen übermittelt. Habe mich die letzten Tage gewundert warum ich ständig komisches Verhalten hatte und heute ist mir aufgefallen, dass seit dem Update keine Events mehr automatisch gepusht werden. Hast du da auch was dran geändert?

Kannst du mal ein "list" von deiner RFHEM Instanz machen?
Und auch mal den Loglevel auf 5 drehen und dann das entsprechende Device ändern, um zu sehen ob es logging Ausgaben dazu gibt?

Das einzige dass ich eigentlich geändert habe, ist das Handling vom "state" reading. Das wurde vorher nicht übertragen weil ein falscher Befehl abgesetzt wurde (setreading <device> <wert> geht nicht, man muss setreading <device> state <wert> machen - im state event fehlt aber eben das Schlüsselwort "state")

Jörg

Edit: und bei mir funktioniert es übrigens sowohl mit normalen readings als auch "state"

Da ich eine schnelle Lösung brauchte und man das Geräte nicht auf Disable setzen konnte, musste ich es heute Mittag löschen und habe es mit FHEM2FHEM überbrückt. Kann die Tage nochmal testen, wenn ich bissi mehr Zeit dazu habe. Sorry

Ich habe mir das Modul inzwischen noch etwas angesehen und ich sehe zu FHEM2FHEM eigentlich nur zwei funktionale Unterschiede:

1. RFHEM sychronisiert readings mit "push" (wird also auf der Quellinstanz eingerichtet), FHEM2FHEM macht "pull" muss also auf die Zielinstanz
2. RFHEM ermöglicht zusätzlich auch Befehle auf der Remote Instanz auszuführen

Der erste Punkt sollte grundsätzlich keine Rolle spielen - ist eher Geschmackssache
Den zweiten Punkt hat Rudi soeben in FHEM2FHEM eingebaut (war relativ leicht zu erweitern)

Damit denke ich das RFHEM obsolete ist und der Aufwand es auf den selben technischen Stand wie FHEM2FHEM zu bringen und zwei Module zu maintainen nicht gerechtfertigt ist, oder gibt es einen Anwendungsfall den ich übersehe?

Jörg

Sehe ich auch so und habe den Thread mit Rudi verfolgt. Daher denke ich, dass es Sinn machen würde RFHEM in deprecated zu verschieben.

Ich habe jetzt meine Version eingecheckt (wie gesagt kann ich bei mir nicht nachvollziehen warum es bei Amenophis86 Probleme gab) und mit einer "deprecated" Nachricht mit link auf dieses Forum versehen, damit wir hier Hilfestellung zum Umstieg auf FHEM2FHEM geben können.

In ein paar Wochen würde ich es dann nach contrib/deprecated verschieben.

Hi,

Habe kurz gesucht, aber keine Migrationshinweise RFHEM --> FHEM2FHEM gefunden, daher frage ich kurz nach.

Stand jetzt habe ich zentrale Funktionen auf einem meiner RasPis. (einer je Etage plus e)
dieser zentrale Raspi pusht z.B. eine Dummy auf alle Instanzen per RFHEMdevice Attribut.

Wenn ich das jetzt richtig verstanden habe müsste ich jetzt auf jeder Instanz eine FHEM2FHEM einrichten und per RAW diesen Dummy "abonieren" d.h. von remote nach lokal spiegeln.
Wäre dann quasi das gleiche nur per get anstatt push...?
um Befehle nach remote zu schicken müsste ich dann aber zeitgleich eine FHEM2FHEM am zentralen FHEM anlegen, richtig?
Wie ist das mit dem RAW im WIKI zu verstehen?

ZitatEinschränkungen: Nur Geräte, welche die "Dispatch-Funktion" unterstützen (CUL, FHZ, CM11, SISPM, RFXCOM, TCM, TRX, TUL), erzeugen raw messages.

bedeutet das ich kenn keinen Dummy spiegeln?

Danke & Grüße
Frank

Hallo Frank,

Du brauchst nicht mit "RAW zu arbeiten.
Du machst ein
define FHEM_xxxx FHEM2FHEM LOG:x.x.x.x:7072 (device1|device2|device3)
Hier kannst du auch mit regexp auf die readings gehen, also device1:reading oder device?:read.*

Wenn das state reading mit übertragen werden soll, musst du noch das Attribut "addStateEvent" setzen.

Sonst ist eben nur die umgedrehte Logik (pull) zu beachten. Du musst also FHEM2FHEM auf der Zielinstanz einrichten.

Gruß,Jörg

Danke Jörg, werde ich antesten.

Ich muss es aber auf beiden Seiten einrichten wenn ich Geräte spiegeln und Befehle absetzen will.
Das ist noch ein kleiner Nachteil zu RFHEM, aber nicht weiter tragisch.

übrigens ist deine Beispiel Syntax falsch.
define <name> FHEM2FHEM host[:port][:SSL] [LOG:regexp|RAW:device] {portpasswort}

Was mir auch dabei auffällt, wenn ich ein F2F anlegen will nur um Befehle zu senden, erwartet er dennoch das "LOG:" im define.
Habs mit LOG:none definiert, so ein Gerät gibts nicht.

werd jetzt mal mit rumspielen ob das soweit passt, dann kann ich RFHEM in Rente schicken.

Danke für deine Mühen!

Wenn du richtig bi-direktional spiegeln willst, gibt es da übrigens jetzt auch eine Option in FHEM2FHEM um Endlosschleifen zu verhindern:
Einfach mindestens auf einer Seite "loopThreshold" setzen - z.B. auf 5 (Sekunden).
Dann werden schnelle Änderungen (wie sie bei einer Schleife) ignoriert, normale Änderungen können aber dadurch gefahrlos in beide Richtungen repliziert werden.

Ich finde auch die neue Option mit dem "keepaliveinterval" sehr interessant, womit FHEM2FHEM schneller mitbekommt, wenn eine Instanz ausfällt und die Verbindung dann zuverlässiger wiederherstellt.

Sorry, ja hab das "LOG:" vergessen.

Jörg

ne, keine Zwei-Richtungs Spiegelung.

Richtung 1 --> Dummy spiegeln.
Richtung 2 --> Befehle absetzen.
geht momentan noch mit der einseitigen RFHEM Definition recht stabil, aber wenn RFHEM in Rente geht gehe ich über zu F2F.

/Frank

pull und get klingt nach: "ich hole es mir irgendwann" und zeitlichen Nachteil.
push klingt nach "sofort".
FHEM2FHEM wird zwar auf dem Ziel definiert, aber mW wird der abonnierte Event direkt von der Quell- in die Zielinstanz geleitet.  ;)

Richtig. Mit pull wollte ich hier nur die "Richtung" klarstellen. Es ist kein "polling" - Events werden sofort and FHEM2FHEM durchgereicht und bearbeitet.

Jörg

Moin,
Habe gestern auf F2F umgebaut und bis jetzt läuft alles wie es soll.
Keine Probleme. Eigentlich merkt man bis auf die mehr angelegten Geräte keinen Unterschied.

Aber mal aus Neugier, wie macht das FHEM2FHEM?
Es baut ja ne telnet Verbindung zum Partner auf, und dann?
Lauscht Es remote den Event Monitor mit?
Muss ja eigentlich, weil die Gegenseite ja nicht weiß welches Gerät interessiert.

Das wäre dann unterm Strich doch einiges mehr an Netzwerk Traffic im Vergleich, sollte aber keine Probleme bereiten.

Danke an alle Beteiligten!

Zitat von: Frank_Huber am 18 September 2021, 08:46:42
Lauscht Es remote den Event Monitor mit?
Muss ja eigentlich, weil die Gegenseite ja nicht weiß welches Gerät interessiert.

Das wäre dann unterm Strich doch einiges mehr an Netzwerk Traffic im Vergleich, sollte aber keine Probleme bereiten.

So weit ich weiß Nein! F2F sagt beim connect der Gegenstelle was gebraucht wird, nur das wird übertragen. Beide "kennen" sich ja, kommen ja aus der gleichen "Feder" ;)

FHEM2FHEM baut eine Telnet Verbindung auf und verwendet dann das "inform" Kommando mit dem entsprechenden Filter (der regexp in FHEM2FHEM) um der Remote Instanz zu sagen, welche Events geschickt werden sollen.
Das kann man auch selber mit einer Kommandozeilen Telnet Verbindung ausprobieren.
Die Verbindung wird dann aufrecht erhalten und per FHEM select() Schleife auf neue Daten gelauscht.

Wenn wenig Events über die Leitung gehen oder der gegenüber gerne mal ausfällt, wäre anzuraten das neue keepaliveinterval Attribut zu nutzen.
Dieses sorgt dafür dass
1. In regelmässigen Abständen eine leere Abfrage gesendet wird, um zu verhindern dass das Betriebssystem die Leitung wegen Inaktivität schliesst
2. Durch einen erneuten Test-Verbindungaufbau geprüft wird, ob der gegenüber noch da ist (was das Betriebssystem sonst leider erst nach sehr langer Zeit bemerkt) und entsprechend neu verbindet

Gruß,
Jörg

Gibt es eine Meldung, wenn das keepalive nicht anschlägt also die Verbindung weg ist?

Ja, zum einen wird das ins Log geschrieben, zum anderen geht der "STATE" auf "disconnected"
Man könnte also sogar darauf reagieren (und z.B. per msg eine Nachricht versenden).

Danke für die Aufklärung Otto und Jörg! 😊

Und weil ich selber erst ein bisschen rumprobieren musste, wie man eine Benachrichtigung mit FHEM2FHEM bei einem Ausfall hinbekommt, hier mein DOIF dazu
([FHEM_Heizung:?DISCONNECTED]) (set SignalBot send #Zuhause Heizungssteuerung ausgefallen)

Jörg

Da es bei mir mehrere F2F Geräte gibt die den gleichen Präfix im Namen haben habe ich das so gelöst: (ein DOIF das mir alle Instanzen überwacht:
defmod F2F_mon DOIF (["PI_:^CONNECTED$"]) (set TelegramBot msg [$SELF:Device] online)\
DOELSEIF (["PI_:^DISCONNECTED$"]) (set TelegramBot msg [$SELF:Device] offline)

Hallo.
finde das Modul nicht, neuste fhem Version. Wie komm ich dazu, bitte?

die Funktion würde nach FHEM2FHEM überführt:
https://forum.fhem.de/index.php?topic=122805.0

hmmm, und wie klappt das jetzt? muss man neu definieren? befehle werden nicht mehr ausgeführt  :-[

[ewdit] gefunden. passt. danke

Hi sorry ich habe es noch nicht ganz verstanden:

Bei mir im Logfile steht dass RFHEM deprecated wird und nun müsste ich wohl auch so langsam nach FHEM2FHEM umstellen.
Ich habe einige Devices mit RFEM und FHEM2FHEM die exemplarisch so aussehen:


define Plug_SHP6_003_F2F FHEM2FHEM 192.168.0.xy:7072 LOG:Plug_SHP6_003.*
attr Plug_SHP6_003_F2F DbLogExclude .*
attr Plug_SHP6_003_F2F group Grp-System-Fhem2Fhem
attr Plug_SHP6_003_F2F room 9.6_System

define Plug_SHP6_003_Rfhem RFHEM 192.168.0.xy
attr Plug_SHP6_003_Rfhem DbLogExclude .*
attr Plug_SHP6_003_Rfhem group Grp-System-Fhem2Fhem
attr Plug_SHP6_003_Rfhem room 3.1_UG_WaschKeller,9.6_System


Ein SET cmd sieht wie folgt aus:

    fhem("set Plug_SHP6_003_Rfhem cmd set SHP6_IoT_SonOff_220V_003 POWER OFF");;\


Was muss ich denn nun tun um nicht über RFHEM zu schalten und ggfs auch eine MSG zu verwenden wenn der link nicht funktioniert

Danke Andreas

Hallo Andreas,

versuch mal so?
set Plug_SHP6_003_F2F cmd set SHP6_IoT_SonOff_220V_003 POWER OFF
den Rest

Zitatund ggfs auch eine MSG zu verwenden wenn der link nicht funktioniert

hab ich nicht verstanden?

Gruß Otto