FHEM2FHEM Problem

[SVLoneStar]

Hallo,
ich habe - auf Grund von Reichweiten-Problemen - eine zweite FHEM-Instanz mit einem 868MHz-CUL installiert.
Damit überwache ich zwei MAX-Fensterkontakte, die den Zustand zweier Garagentore melden.
Nach Wiki-Anleitung habe ich die beiden MAX-Kontakte auf der Remote-Instanz via FHEM2FHEM auf die primäre FHEM-Instanz übertragen.

Remote:

Code Auswählen Erweitern

define Garage_Audi_Remote MAX ShutterContact 0fee4f

Primär:

Code Auswählen Erweitern

define FHEM_Remote FHEM2FHEM 192.168.42.40:7072 LOG:.*(battery|RSSI|onoff|state).* <password>
define Garage_Audi_Remote dummy


Die Readings übertrage ich auf die primäre Instanz via

Code Auswählen Erweitern

define Garage_Audi_Remote_notify notify Garage_Audi_Remote { $EVENT=~s/://;;;; fhem("setreading Garage_Audi_Remote $EVENT");;;; my $Garage_Audi_Remote_RSSI= ReadingsVal("Garage_Audi_Remote","RSSI",0);;;; my $Garage_Audi_Remote_Battery= ReadingsVal("Garage_Audi_Remote","battery",0);;;; my $Garage_Audi_Remote_onoff= ReadingsVal("Garage_Audi_Remote","onoff",0);;;; fhem("setreading Garage_Audi_Remote state RSSI: $Garage_Audi_Remote_RSSI battery: $Garage_Audi_Remote_Battery onoff: $Garage_Audi_Remote_onoff") }

Zudem habe ich einen Dummy (Garage_Audi_Remote_State), der den vorherigen Status der Garagen-Tore 'merkt'.

Das Notify auf der primären Instanz schaut so aus (mit reichlich Kommentaren zum Debuggen):

Code Auswählen Erweitern

define Garage_Audi_Remote_Change_Notify notify Garage_Audi_Remote:onoff:.* {\
  Log 3, "Garage Audi (Remote)... - ReadingsVal onoff is ".ReadingsVal("Garage_Audi_Remote","onoff","0");;\
  if (ReadingsVal("Garage_Audi_Remote","onoff","1") eq "1") {\
      Log 3, "   Garage ist offen";;\
      if (ReadingsVal("Garage_Audi_Remote_State","state","off") eq "off") {\
          Log 3, "   Garage war zuvor geschlossen";;\
          fhem("set MyPush message Garage Audi geöffnet | FHEM Info Garage Audi | Galaxy S4");;\
          Log 3, "   Garage Audi geöffnet: @ %";;\
          fhem("set Garage_Audi_Remote_State on");;\
      } else {\
          Log 3, "   Garage war zuvor bereits offen";;\
      }\
  } else {\
  if (ReadingsVal("Garage_Audi_Remote","onoff","0") eq "0") {\
          Log 3, "   Garage ist geschlossen";;\
          if (ReadingsVal("Garage_Audi_Remote_State","state","on") eq "on") {\
              Log 3, "   Garage war zuvor geöffnet";;\
          fhem("set MyPush message Garage Audi geschlossen | FHEM Info Garage Audi | Galaxy S4");;\
          Log 3, "   Garage Audi geschlossen: @ %";;\
              fhem("set Garage_Audi_Remote_State off");;\
          } else {\
              Log 3, "   Garage war zuvor bereits geschlossen";;\
          }\
      } else {\
          Log 3, "   Garage_Audi_Remote - onoff ist weder 1 noch 0";;\
      }\
  }\
}


Es kommen auf der primären Instanz auch Meldungen an - aber irgendwie 'falsch'.

Zum Test habe ich dann das identische Notify (und den Dummy) auch auf der Remote-Instanz eingerichtet.

Auf der Remote-Instanz klappt alles prima:
- Garage geht auf, Dummy wird korrekt versorgt, Pushbullet meldet 'Auf'. Im Log steht:

Code Auswählen Erweitern

2015.07.07 01:32:59 3: Garage Audi (Remote, on F2F)... - ReadingsVal onoff is 1
2015.07.07 01:32:59 3:    Garage Audi ist offen
2015.07.07 01:32:59 3:    Garage Audi war zuvor geschlossen
2015.07.07 01:32:59 3:    Garage Audi geöffnet: Garage_Audi_Remote onoff: 1
- Garage geht zu, Dummy wird korrekt versorgt, Pushbullet meldet 'Zu'. Im Log steht:

Code Auswählen Erweitern

2015.07.07 01:33:31 3: Garage Audi (Remote, on F2F)... - ReadingsVal onoff is 0
2015.07.07 01:33:31 3:    Garage Audi ist geschlossen
2015.07.07 01:33:31 3:    Garage Audi war zuvor geöffnet
2015.07.07 01:33:32 3:    Garage Audi geschlossen: Garage_Audi_Remote onoff: 0

Auf der primären Instanz jedoch passiert Folgendes:
- Garage geht auf, Pushbullet meldet nix. Im Log steht:

Code Auswählen Erweitern

2015.07.07 01:48:50 3: Garage Audi (Remote)... - ReadingsVal onoff is 0
2015.07.07 01:48:50 3:    Garage ist geschlossen
2015.07.07 01:48:50 3:    Garage war zuvor bereits geschlossen
Ist natürlich Quatsch, die Garage ist ja im Moment offen.
- Garage geht zu, Pushbullet meldet 'Auf' (!). Im Log steht:

Code Auswählen Erweitern

2015.07.07 01:52:08 3: Garage Audi (Remote)... - ReadingsVal onoff is 1
2015.07.07 01:52:08 3:    Garage ist offen
2015.07.07 01:52:08 3:    Garage war zuvor geschlossen
2015.07.07 01:52:09 3:    Garage Audi geöffnet: Garage_Audi_Remote onoff: 0
Ist auch Quatsch - Garage ist ja nun geschlossen und war zuvor offen.
Aber das 'Offen' kommt irgendwie nicht bei der primären Instanz an - bei der Remote-Instanz jedoch schon.

Für mich schaut's so aus, als würden die Meldungen der Remote-Instanz quasi in einen 'Puffer' laufen...?
Oder anders: Warum ergibt auf der primären Seite

Code Auswählen Erweitern

ReadingsVal("Garage_Audi_Remote","onoff","1")
einen anderen Wert als

Code Auswählen Erweitern

Log 3, "   Garage Audi geschlossen: @ %"
?

Besten Dank für jede Hilfe,
Stefan

[justme1968]

ohne genau geschaut zu haben woran es liegt: wenn du 'nur' remote auf einen cul zugreifen willst es ist einfacher das per ser2net zu machen als mit einem zweiten fhem und fhem2fhem.

gruß
  andre

[SVLoneStar]

Hallo Andre,
danke für Deine Antwort auf meinen (viel zu) langen Post.
Wenn ich das bisher Gelesene richtig verstanden habe, empfängt eine FHEM-Instanz alle gesendeten Pakete auf allen CULs, die das Protokoll verstehen. Das 'Problem' ist nun, daß mein primäres FHEM die Sender an den Garagentoren manchmal empfängt und manchmal nicht (RSSI zwischen -80 und -100). Dies würde dazu führen, daß eine einzelne FHEM-Instanz mit ser2net die Meldungen der Tür-Sensoren und aller anderer Sensoren, die bei beiden CULs ankommen, manchmal zweimal empfangen würde (jeweils einmal per CUL).
Da ich nicht mit duptimeout arbeiten wollte und durch den Mehfachempfang (und die autocreates?) mehr Probleme befürchtet hatte, hatte ich gedacht, eine zweite Instanz mit FHEM2FHEM im LOG-Modus wäre 'einfacher' (und außerdem wollte ich FHEM2FHEM einfach mal ausprobieren)...

Was mich eben einfach wundert: Die Notifies arbeiten wunderbar auf der Remote-Instanz, die identischen Notifies auf der primären Instanz lösen beim Senden der (Remote-)Sensoren auch aus, aber der Code 'macht das Falsche' (da 'geschlossen' statt 'geöffnet' ankommt).

Ich werde das mit ser2net natürlich trotzdem mal ausprobieren...mit duptimeout sollte es ja auch klappen.
Im Endeffekt ist das dann doch identisch zur Verwendung eines RFR CUL...oder?

Gruß,
Stefan

[justme1968]

dupTimeout ist etwas das in 99.9% aller fälle nicht durch den endanwender gesetzt werden muss sondern automatisch passt.

ganz im gegenteil. das automatische erkennen doppelter nachrichten (und das rausfiltern) kann nur dann richtig funktionieren wenn eine fhem instanz alle cul 'kennt'. wenn du mit fhem2fhem im log modus arbeitest gibt es keine duplikat erkennung mehr (im raw modus je nach protokoll schon noch). auch sendpool oder vccu gehen mit fhem2fhem nicht.

das 'ohne genau geschaut zu haben' bezog sich nicht auf die länge deines postings. im gegenteil. sondern darauf das die fhem2fhem anbindung in deinem fall deutlich komplexer ist als die anbindung mit ser2net. das sieht mann zwar indirekt an der länge des postings aber eine genaue beschreibung ist sehr viel besser als ein kurzes es geht nicht das man sonst schon mal findet.

es bezog sich eher darauf das deine installation früher oder später von ganz allein komplexer wird und es vieles vereinfacht wenn man versucht die installation selber so einfach zu halten. und ein direkt angebundener cul ist einfacher als ein über ser2net angebundener ist einfacher als ein mit fhem2fhem im raw mode angebundener ist einfacher als ein mit fhem2fhem im log modus angebundener. und es gibt von links nach rechts immer mehr punkte an denen es probleme geben kann.

der unterschied von ser2net zu rfr ist das der cul zwischenzeitlich durch das weiterleiten belegt ist bei dem potentiell nachrichten verloren gehen können. wenn du ein netzwerk kabel liegen hast versuch ser2net. es ist wirklich einfacher und zuverlässiger als alle anderen varianten. so lange das zweite fhem nicht wirkliche aufgaben übernehmen soll bringt es nur unnötig zusätzliche komplexität.

gruss
  andre

[SVLoneStar]

Hallo,
lange ist's her....Besten Dank für Deine Antwort! Sorry, daß ich das nicht schon früher gepostet habe.
Seit Juli beschäftige ich ich mich immer mal wieder mit diesem Problem mit FHEM2FHEM. Leider bisher ohne Lösung.
Ich habe ser2net ausprobiert, klappt wunderbar. Ist aber trotzdem keine (technische) Antwort darauf, warum FHEM2FHEM bei mir immer mit Verzögerung eines Events reagiert.

Daher - noch ein Beispiel zu dem oben beschriebenen Verhalten:
Ich habe einen MAX-Fensterkontakt in meinen Briefkasten verbaut. Wenn die Einwurf-Klappe des Briefkasten aufgeht, reagiert ein Notify und schickt mit eine Push-Nachricht auf's Handy (also reagierend auf den 'Offen'-Event).
Soweit, so gut. Klappt prima auf der FHEM-Instanz, die den MAX-Fensterkontakt direkt empfängt.
Parallel dazu greife ich diesen Event per FHEM2FHEM auf meiner Haupt-Instanz von FHEM ab. Code dazu:

Code Auswählen Erweitern

define Briefkasten_Remote_notify notify Briefkasten_Remote { $EVENT=~s/://;;;; fhem("setreading Briefkasten_Remote $EVENT");;;; my $Briefkasten_Remote_RSSI= ReadingsVal("Briefkasten_Remote","RSSI",0);;;; my $Briefkasten_Remote_Battery= ReadingsVal("Briefkasten_Remote","battery",0);;;; my $Briefkasten_Remote_onoff= ReadingsVal("Briefkasten_Remote","onoff",0);;;; fhem("setreading Briefkasten_Remote state RSSI: $Briefkasten_Remote_RSSI battery: $Briefkasten_Remote_Battery onoff: $Briefkasten_Remote_onoff") }

Es kommt hierbei auch was an. Sprich: Wenn die Klappe des Briefkastens auf- und zugeht, erhalte ich ein Event beider Instanzen, daß die Post da war.

Nun das (zumindest für mich) Verblüffende:
Wenn die Klappe des Briefkasten nach dem Öffnen geöffnet bleibt (z.B. durch Einwurf einer großen Sendung), erhalte ich nur durch die direkt lauschende Instanz eine Nachricht. Geht dann später (durch Entnahme der Sendung) die Klappe wieder zu, meldet auch die Haupt-Instanz (per FHEM2FHEM verbunden), daß Post da war.
Sprich: Die Meldung (das Event) kommt 'verschoben' an, es braucht erst ein 'nachfolgendes' Event, damit das 'vorausgegangene' Event per FHEM2FHEM ankommt (bzw. verarbeitet wird).

Ich vermute mal, daß ich mich mit diesem Problem direkt an Rudolf König wende...kann man dieses Verhalten evtl. nachvollziehen bzw. abstellen? Bei den im Wiki für FHEM2FHEM angegebenen Beispielen (Revolt, Spritpreismonitor, Thermometer) fällt diese verzögerte Reaktion evtl. nicht auf, bei Fensterkontakten sorgt dieses Verhalten jedoch dafür, daß FHEM2FHEM nahezu nutzlos wird.

Gerne liefere ich alle benötigten Informationen (Logs, Internals, ...) nach - bitte lasst mich wissen, welche Informationen zur Lösung des Problems beitragen könnten.

Besten Dank,
Stefan