Autor Thema: FHEM2FHEM extrem träge , wenn überhaupt ...  (Gelesen 6463 mal)

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
FHEM2FHEM extrem träge , wenn überhaupt ...
« am: 30 Mai 2013, 22:55:47 »
Moin

ich habe 2 FHEM laufen und per FHEM2FHEM verbunden.
das eine ist ein Synology mit nem CUL und das andere ist ein RPI mit nem CUL.

über beide kann ich mich mit dem Webif verbinden, also das funzt.

sobald ich mich allerdings mit beiden verbinde per FHEM2FHEM , wird mein Haupt FHEM extrem träge , wenn er dann überhaupt befehle annimmt.
ich sehe die befehle im Event Monitor , aber es passiert 99% nichts.

hier meine config im Haupt FHEM (Synology)

define CUL_0 CUL /dev/ttyUSB0@9600 1034

define CUL_RPi CUL none 0000
attr CUL_RPi dummy 1
define RPi_CUL FHEM2FHEM 192.168.1.91:7072 RAW:CUL_RPi

und hier mein RPi :

define CUL_RPi CUL /dev/ttyACM0@9600 1034
attr CUL_RPi rfmode SlowRF


Log File beim start :

2013.05.30 22:33:53.265 3: Opening CUL_0 device /dev/ttyUSB0
2013.05.30 22:33:53.408 3: Setting CUL_0 baudrate to 9600
2013.05.30 22:33:53.415 3: CUL_0 device opened
2013.05.30 22:33:53.561 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.05.30 22:33:53.609 1: CUL_RPi device is none, commands will be echoed only
2013.05.30 22:33:53.636 3: FHEM2FHEM opening RPi_CUL at 192.168.1.91:7072
2013.05.30 22:33:53.638 3: FHEM2FHEM device opened (RPi_CUL)

und hier log auf dem RPi :

2013.05.30 20:34:34 3: Opening CUL_RPi device /dev/ttyACM0
2013.05.30 20:34:35 3: Setting CUL_RPi baudrate to 9600
2013.05.30 20:34:35 3: CUL_RPi device opened
2013.05.30 20:34:35 3: CUL_RPi: Possible commands: BCFiAZEGMRTVWXefmltux


sobald ich  folgendes entferne aus der config , geht wieder alles normal :
define CUL_RPi CUL none 0000
attr CUL_RPi dummy 1
define RPi_CUL FHEM2FHEM 192.168.1.91:7072 RAW:CUL_RPi

hat da jemand ne ahnung wo ich ansetzen soll ?

Danke im voraus....

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #1 am: 31 Mai 2013, 11:48:40 »
niemand ne idee ?

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9838
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #2 am: 31 Mai 2013, 13:28:42 »
Hallo,

ich nutze auch FHEM2FHEM habe aber am zweiten FHEM-Server keinen CUL/CUNO.
Der zweite loggt die Daten bei mir einfach nur in die Datenbank.
Ich weiß, das könnte auch der erste machen aber wo bleibt dann der Spieltrieb ;-)

Allerdings habe ich am zweiten FHEM I2C-Sensoren dran die ich per at abfrage.
Egal mit welchem FHEM ich mich über das Webfrontend verbinde kann ich beide bedienen ohne das irgendwas träge wird.

Von daher kann ich dir leider nicht viel weiter helfen ausser ...
Mir ist aufgefallen das du beiden CUL die selbe Adresse gegeben hast:
Zitat
define CUL_0 CUL /dev/ttyUSB0@9600 1034

und
Zitat
define CUL_RPi CUL /dev/ttyACM0@9600 1034

Hast du schonmal versucht dem CUL_RPi eine andere zuzuweisen?
Was passiert dann?

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #3 am: 31 Mai 2013, 14:06:52 »
moin


habe gerade getestet und dem RPi die 2034 gegeben als adresse , neu gestartet, aber hat trotzdem nix genützt...

noch ne idee ?

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9838
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #4 am: 31 Mai 2013, 14:10:15 »
Hallo,

hmmm. Also ich hab keine Idee mehr, sorry.

Evtl. liegt es ja am RAW - ich benutze LOG.
Das ist jetzt von mir aber nur in der Luft rum geraten da ich davon nicht wirklich Ahnung habe.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21255
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #5 am: 31 Mai 2013, 14:22:53 »
Sendet das Haupt-FHEM Befehle an die Neben-FHEM Geraete?
Ist die TCP/IP Verbindung zw. den beiden Geraeten problemlos?
Welche FHEM Module haengen an diese CUL?

Hier wuerde ein log mit "attr global verbose 5" der beiden FHEMs helfen, insb. die Stellen, wo die Probleme auftreten.


Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #6 am: 31 Mai 2013, 18:34:28 »
Sendet das Haupt-FHEM Befehle an die Neben-FHEM Geraete?

Nein tut es nicht, obwohl er ja wie man im Log sieht sich mit Ihm verbindet.

Ist die TCP/IP Verbindung zw. den beiden Geraeten problemlos?

Ja , ping usw geht ohne probleme, Webif auch.

Welche FHEM Module haengen an diese CUL?

wo genau sehe ich das welche Module geladen werden ?

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #7 am: 31 Mai 2013, 18:50:11 »
ok


hier mal ein paar logs mit verbose 5 auf dem ersten fhem und  auf dem RPi.

Zitat
2013.05.31 18:46:32.660 5: CUL_0: F3E9E0311 -49.5
2013.05.31 18:46:32.661 5: CUL_0 dispatch 810b04xx0101a0013e9e030011
2013.05.31 18:46:32.668 4: FS20 Luucht_Living2 on
2013.05.31 18:46:32.669 5: Triggering Luucht_Living2 (1 changes)
2013.05.31 18:46:32.671 5: Notify loop for Luucht_Living2 on
2013.05.31 18:46:32.677 5: Triggering Luucht_Living2_on
2013.05.31 18:46:32.678 5: Cmd: >set LED6 on<
2013.05.31 18:46:32.679 3: FS20 set LED6 on
2013.05.31 18:46:32.680 5: Triggering LED6 (1 changes)
2013.05.31 18:46:32.683 5: Notify loop for LED6 on
2013.05.31 18:46:32.977 4: HTTP FHEMWEB:192.168.1.5:52943 GET /fhem/icons/FS20.on
2013.05.31 18:46:33.203 5: CUL/RAW: /F3E9E041130

2013.05.31 18:46:33.203 5: CUL_0: F3E9E0411 -50
2013.05.31 18:46:33.204 5: CUL_0 dispatch 810b04xx0101a0013e9e040011
2013.05.31 18:46:33.211 4: FS20 Luucht_Living3 on
2013.05.31 18:46:33.212 5: Triggering Luucht_Living3 (1 changes)
2013.05.31 18:46:33.214 5: Notify loop for Luucht_Living3 on
2013.05.31 18:46:33.221 5: Triggering Luucht_Living3_on
2013.05.31 18:46:33.222 5: Cmd: >set LED7 on<
2013.05.31 18:46:33.223 3: FS20 set LED7 on
2013.05.31 18:46:33.224 5: Triggering LED7 (1 changes)
2013.05.31 18:46:33.226 5: Notify loop for LED7 on
2013.05.31 18:46:33.491 4: HTTP FHEMWEB:192.168.1.5:52943 GET /fhem/icons/FS20.on
2013.05.31 18:46:33.860 5: CUL/RAW: /F3E9E061130

2013.05.31 18:46:33.860 5: CUL_0: F3E9E0611 -50
2013.05.31 18:46:33.861 5: CUL_0 dispatch 810b04xx0101a0013e9e060011
2013.05.31 18:46:33.868 4: FS20 Luucht_Living1 on
2013.05.31 18:46:33.869 5: Triggering Luucht_Living1 (1 changes)
2013.05.31 18:46:33.871 5: Notify loop for Luucht_Living1 on
2013.05.31 18:46:33.877 5: Triggering Luucht_Living1_on
2013.05.31 18:46:33.878 5: Cmd: >set LED5 on<
2013.05.31 18:46:33.879 3: FS20 set LED5 on
2013.05.31 18:46:33.880 5: Triggering LED5 (1 changes)
2013.05.31 18:46:33.882 5: Notify loop for LED5 on
2013.05.31 18:46:34.206 4: HTTP FHEMWEB:192.168.1.5:52943 GET /fhem/icons/FS20.on
2013.05.31 18:46:34.413 5: CUL/RAW: /F3E9E07112F

2013.05.31 18:46:34.414 5: CUL_0: F3E9E0711 -50.5
2013.05.31 18:46:34.415 5: CUL_0 dispatch 810b04xx0101a0013e9e070011
2013.05.31 18:46:34.423 4: FS20 Luucht_Living4 on
2013.05.31 18:46:34.424 5: Triggering Luucht_Living4 (1 changes)
2013.05.31 18:46:34.426 5: Notify loop for Luucht_Living4 on
2013.05.31 18:46:34.437 5: Triggering Luucht_Living4_on
2013.05.31 18:46:34.438 5: Cmd: >set LED4 on<
2013.05.31 18:46:34.439 3: FS20 set LED4 on
2013.05.31 18:46:34.440 5: Triggering LED4 (1 changes)
2013.05.31 18:46:34.443 5: Notify loop for LED4 on
2013.05.31 18:46:34.718 4: HTTP FHEMWEB:192.168.1.5:52943 GET /fhem/icons/FS20.on
2013.05.31 18:46:50.123 5: HMLAN_Send:  HMLAN1 I:K
2013.05.31 18:46:50.127 5: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0315823,1C6536,123ABC,0BB442B4,0000



und das gleiche auf dem RPi

Zitat
2013.05.31 18:47:24 5: Cmd: >iowrite CUL_RPi 04 01010111110011<
2013.05.31 18:47:24 5: CUL_RPi sending F11110011
2013.05.31 18:47:24 5: SW: F11110011
2013.05.31 18:47:24 5: Cmd: >iowrite CUL_RPi 04 01010111110111<
2013.05.31 18:47:24 5: CUL_RPi sending F11110111
2013.05.31 18:47:24 5: SW: F11110111
2013.05.31 18:47:25 5: Cmd: >iowrite CUL_RPi 04 01010111110211<
2013.05.31 18:47:25 5: CUL_RPi sending F11110211
2013.05.31 18:47:25 5: SW: F11110211
2013.05.31 18:47:25 5: Cmd: >iowrite CUL_RPi 04 01010111110511<
2013.05.31 18:47:25 5: CUL_RPi sending F11110511
2013.05.31 18:47:25 5: SW: F11110511
2013.05.31 18:47:26 5: Cmd: >iowrite CUL_RPi 04 01010111110611<
2013.05.31 18:47:26 5: CUL_RPi sending F11110611
2013.05.31 18:47:26 5: SW: F11110611
2013.05.31 18:47:27 5: Cmd: >iowrite CUL_RPi 04 01010111110411<
2013.05.31 18:47:27 5: CUL_RPi sending F11110411
2013.05.31 18:47:27 5: SW: F11110411
2013.05.31 18:47:27 5: Cmd: >iowrite CUL_RPi 04 01010111110311<
2013.05.31 18:47:27 5: CUL_RPi sending F11110311
2013.05.31 18:47:27 5: SW: F11110311



das heisst ja das was ankommt.....

was komisch ist , dass nichts schaltet ! das sind normale LED's On/Off befehle .... aber die Lampen gehen nicht an...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21255
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #8 am: 01 Juni 2013, 10:40:35 »
>  wo genau sehe ich das welche Module geladen werden ?

Es geht nicht um die geladenen Module, sondern um die, die ueber das FHEM2FHEM bedient werden.
D.h. mich interessieren die Geraete (bzw. nur deren Typ), bei dem IODev auf  RPi_CUL gesetzt ist.
Das kann man jeweils im Detail Ansicht sehen. Oder man fuehrt folgende Zeile in fhem aus:
{ join(",", map { $defs{$_}{TYPE} } grep { $defs{$_}{IODev} &&  $defs{$_}{IODev}{NAME} eq "RPI_CUL" } sort keys %defs ) }


>  hier mal ein paar logs mit verbose 5 auf dem ersten fhem und auf dem RPi.

ich sehe aber hier keine nennenswerten delays.


>  was komisch ist , dass nichts schaltet ! das sind normale LED's On/Off befehle .... aber die Lampen gehen nicht an...

Bitte nicht zwei voellig unterschiedliche Probleme in einem Thread.

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #9 am: 01 Juni 2013, 16:59:34 »
ok, wo sehe ich den output hiervon :

{ join(",", map { $defs{$_}{TYPE} } grep { $defs{$_}{IODev} &&  $defs{$_}{IODev}{NAME} eq "RPI_CUL" } sort keys %defs ) }


was ich jetzt getestet habe :

ich habe beide FHEM server nicht weit von einander aufgestellt , zirka 5m , funzt tadellos...

sobald ich jedoch den RPi ein stockwerk höher setze geht nichts mehr . so wie ich es halt beschrieben habe.


daher ein paar Hypothesen :

kann es sein dass ein Funk Kontakt zwischen den beiden sein muss oder langt die Netzwerkverbindung ?
kann es sein dass ich einfach etwas falsch konfiguriert habe ?

was die Lampen angeht, das ist kein zweites Problem. Dies passiert wenn der RPi nicht übernimmt, also der 2te FHEM Server.

sobald ich dann das FHEM2FHEM in dem ersten ausschalte, geht wieder alles wie es soll....

ich gehe davon aus das das problem davon kommt ,dass der RPi , welcher FHEM 2 sein soll , die aufgabe übernimmt und die an die Funkaktoren die befehle ausgibt. da diese jedoch indem moment zuweit enfernt sind , funktionieren die Lampen nicht richitg.

kann es sein dass ich mich da irre ?
im moment sieht es so aus , dass z.b.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21255
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #10 am: 01 Juni 2013, 19:06:11 »
>  ok, wo sehe ich den output hiervon :

Im telnet oder FHEMWEB Kommandozeile eingeben. Siehe auch http://fhem.de/commandref.html#perl


>  ich habe beide FHEM server nicht weit von einander aufgestellt , zirka 5m , funzt tadellos...

Dazu faellt mir nichts ein, auch die beiden Hypothesen halte ich fuer stark abwaegig.

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #11 am: 01 Juni 2013, 19:17:07 »
ja klar , wo ich das eingeben muss ,is ok ....


aber da kommt kein output dabei raus , das mein ich

http://d.pr/i/xZwK


kann das hier evtl noch weiterhelfen :
das ist auf dem "Haupt FHEM"


(siehe Anhang / see attachement)


(siehe Anhang / see attachement)


(siehe Anhang / see attachement)


das hier ist auf dem RPi, also dem "2ten FHEM"


(siehe Anhang / see attachement)



danke rudolf dass du dir die zeit nimmst zu helfen !!!

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9838
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #12 am: 01 Juni 2013, 19:20:43 »
Hallo,

Zitat
aber da kommt kein output dabei raus , das mein ich


Und wenn du die Zeile in die FHEM-Befehlszeile eingibst?

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21255
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #13 am: 01 Juni 2013, 19:22:53 »
>  aber da kommt kein output dabei raus , das mein ich

Das bedeutet, dass dem FHEM2FHEM nichts zugewiesen ist, und damit nutzlos ist.... Komisch.

Offline Jumbo

  • Full Member
  • ***
  • Beiträge: 409
Aw: FHEM2FHEM extrem träge , wenn überhaupt ...
« Antwort #14 am: 01 Juni 2013, 19:29:48 »
@puschel , genau das gleiche... kein output.


hier nochmal die config, evtl is ja da ein problem drinne :

attr global autoload_undefined_devices 1
attr global logfile /usr/local/FHEM/var/log/fhem-%Y-%m.log
attr global modpath /usr/local/FHEM/share/fhem
attr global motd none
attr global mseclog 1
attr global sendStatistics manually
attr global statefile /usr/local/FHEM/var/log/fhem.save
attr global uniqueID /usr/local/FHEM/share/fhem/FHEM/FhemUtils/uniqueID
attr global userattr devStateIcon fm_fav fm_groups fm_name fm_order fm_type fm_view fp_1._RDC fp_1stack fp_2._1ten_Stack fp_2stack fp_3._2ten_Stack fp_8._Plots fp_9._XBMC fp_Grundriss fp_Living fp_XBMC icon sortby webCmd
attr global verbose 5
#attr global verbose 3


define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global
attr WEB basicAuth d23mfdssdf23)=Ufafsd23fvg=
attr WEB basicAuthMsg Login an password please
attr WEB longpoll 1
attr WEB refresh 120
attr WEB stylesheetPrefix dark

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

define Logfile FileLog /usr/local/FHEM/var/log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog /usr/local/FHEM/var/log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
define initialUsbCheck notify global:INITIALIZED usb create


define CUL_0 CUL /dev/ttyUSB0@9600 1034
attr CUL_0 model CUL
attr CUL_0 rfmode SlowRF

define CUL_RPi CUL none 0000
define RPi_CUL FHEM2FHEM 192.168.1.91:7072 RAW:CUL_RPi
attr CUL_RPi dummy 1


define HMLAN1 HMLAN 192.168.1.56:1000
attr HMLAN1 hmId 345AFC



hund hier nochmal der Code vom RPi :


attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\\\
\\\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\\\
telnetPort has no password/globalpassword attribute.\\\
\\\
Restart fhem for a new check if the problem is fixed,\\\
or set the global attribute motd to none to supress this message.\\\

attr global statefile ./log/fhem.save
attr global userattr devStateIcon icon sortby webCmd
attr global verbose 5

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create


# If the above notify did not helped, then you probably have to enable some of
# the following lines.  Verify first that /dev/xxx ist correct.


define CUL_RPi CUL /dev/ttyACM0@9600 2034
attr CUL_RPi rfmode SlowRF




was ich allerdings nicht verstehe ist ,wieso geht es wenn die beiden auf ner distanz von 5m stehen  , und sobald ein Stockwerk dazwischen ist , dann kommen die komischen effekte hinzu....
Ich hab's mehrmals getestet und kanns jedesmal nachreproduzieren....