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

[Amenophis86]

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.

[SVLoneStar]

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

[androsch]

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

[SVLoneStar]

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

[androsch]

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

[SVLoneStar]

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


Sent from my iPhone using Tapatalk

[androsch]

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....

[Rogni]

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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


# 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.

Code Auswählen Erweitern


############
# 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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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 

Code Auswählen Erweitern



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



[Amenophis86]

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?

[Rogni]

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

[Amenophis86]

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

[schooney]

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

[chris1284]

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

[Frank_Huber]

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?

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

[chris1284]

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