RFHEM - Modul für Befehle an andere FHEM-Instanzen

Begonnen von chris1284, 15 Mai 2014, 20:07:57

Vorheriges Thema - Nächstes Thema

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Otto123

Hi Jörg,

dafür verwende ich ja FHEM2FHEM :)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rs

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
rpi3+ & RaspBee | Phillips, Osram, IKEA, SIlvercrest Devices | FHEM 6.2 | Echo Show 15 | Yamaha YAS| LG TV | Ubuntu 22.04 - NextCloud 27 - OpemVPN - Wordpress - NAS - ...

Otto123

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 ...?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Amenophis86

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
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Amenophis86

Dank dir, werde die Version die Tage mal testen und mich melden.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Amenophis86

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?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Frank_Huber

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.

Adimarantis

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)