Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)

[Markus Hermann]

Moin Forum.

Nachdem ich nun von der FB 7390 auf Cubietruck gewechselt bin, habe ich zuerst meine HM-LAN Konfiguration aktiviert. Alle Geräte funktionieren problemlos und FHEMWEB läuft super flüssig.

Nun wollte ich mein ersten CUL installieren und habe ihn wie in der FB 7390 definiert. Nach ein paar Minuten friert FHEM ein und man kann keine Befehle über das Frontend eingeben. Nach einigen Minuten läuft es dann wieder, aber auch nur bis irgendwelche Signale über den CUL laufen. Dann gehts wieder von vorne los.

Jemand eine Idee?

Gruß
Markus

[Puschel74]

Hallo,

Ideen ohne Ende - aber keine wird dir helfen können.

Da deine Infos auch recht dürftig sind hier mal was zum lesen:
http://forum.fhem.de/index.php/topic,16311.0.html
So ganz ohne Logfile (evtl. mit verbose 5) sind unsere Glaskugeln leider recht trüb.

Grüße

[Markus Hermann]

Sorry, hast ja recht. Dachte nur, dass das eventuell ein bekanntes Problem mit dem Cubietruck ist.

Ich habe den CUL V3 aktuell mit 1.161 geflasht. Heute morgen ein update force gemacht und nach lesen dieses Threads:

"FHEMWEB sehr langsam..."  http://forum.fhem.de/index.php/topic,20294.60.html 

ein attr TYPE=FHEMWEB closeConn 1

eingefügt. Bringt aber keine Verbesserung.

Wenn ich ein paar FS20 Signale mit der Fernbedienung sende (FS20S8), dann werden mir die auch im Event Monitor angezeigt.
Aber nach 3 bis 4 Signalen regiert das Frontend nicht mehr. Egal ob Firefox, Internetexplorer oder IOS7 (jetzt IOS8) auf dem IPAD.

2014-09-20 09:04:50.141 FS20 Kugelleuchte_1 on
2014-09-20 09:04:53.695 FS20 Kugelleuchte_1 off
2014-09-20 09:04:56.030 FS20 Aussenlicht1 off
2014-09-20 09:04:59.652 CUL_HM CFM CMDs_pending
2014-09-20 09:04:59.660 CUL_HM mp3_play set_playTone 019,004
2014-09-20 09:04:59.669 FS20 Heizung off

Auch über Telnet Port 7072 reagiert.

Während ich hier schreibe und teste, bin ich auf ein eventuelles Problem mit einem notify gestoßen.

define Alarm_scharf notify Alarm_sw { system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") }

Hiermit gebe ich eine Info an den VDR, vielleicht hängt es damit zusammen.

Ich such jetzt mal weiter und werden berichten.

Gruß
Markus

[Puschel74]

Hallo,

Dachte nur, dass das eventuell ein bekanntes Problem mit dem Cubietruck ist.

Ein generelles Problem mit dem cubietruck kann ich zumindest mal nicht bestätigen.
Meiner rennt wie ein wildes Pferd und hat keine Hänger.

Schau dir mal apptime und perfmon an.
Damit siehst du schön wann und vor allem was FHEM "warten" lässt.

Grüße

[Markus Hermann]

So, ich habe den Übeltäter ausgemacht, aber noch keine Lösung.

Ich schalte mit der FS20S8 u. a. einen Dummy "Alarm_sw" auf on bzw. off.

Dieser Dummy löst ein notify aus, der dann eine Meldung auf den VDR ( IP: 192.168.2.30) ausgeben soll und zusätlich ein MP3 File auf dem CFM ausgibt:

Code Auswählen Erweitern

define Alarm_scharf notify Alarm_sw { system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") }
define Alarm_scharf_ton_ein notify Alarm_sw:on { fhem("set mp3_play playTone 019,001")}
define Alarm_scharf_ton_aus notify Alarm_sw:off set mp3_play playTone 255,019,002


Wenn aber der VDR nicht eingeschaltet ist, dann wird der Befehl system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419")
nicht verarbeitet, bzw. die Meldung kann nicht an den VDR gesendet werden.
Das Timeout ist irgend wie zu hoch. Siehe Zeitmarke: 11:37:38:

2014.09.21 11:37:38.271 5: Cmd: >{ system("echo MESG Alarm wurde auf off geschaltet | nc 192.168.2.30 6419") }<

es dauert fast 1 Minute bis der nächste Logbucheintrag erfolgt.

Kann man das Timeout einstellen?   Auf der Fritzbox gab es da keine Probleme.

Gruß
Markus

Code Auswählen Erweitern

2014.09.21 11:37:36.119 4: CUL_Parse: CUL F50AF000063 -24.5
2014.09.21 11:37:36.120 5: CUL dispatch 810b04xx0101a00150af000000
2014.09.21 11:37:36.122 4: FS20 Kugelleuchte_1 off
2014.09.21 11:37:36.124 5: Triggering Kugelleuchte_1 (1 changes)
2014.09.21 11:37:36.124 5: Notify loop for Kugelleuchte_1 off
2014.09.21 11:37:37.146 5: CUL/RAW: /F50AF050063

2014.09.21 11:37:37.147 4: CUL_Parse: CUL F50AF050063 -24.5
2014.09.21 11:37:38.263 5: CUL dispatch 810b04xx0101a00150af050000
2014.09.21 11:37:38.265 4: FS20 Alarm_sw off
2014.09.21 11:37:38.266 5: Triggering Alarm_sw (1 changes)
2014.09.21 11:37:38.267 5: Notify loop for Alarm_sw off
2014.09.21 11:37:38.269 5: Triggering Alarm_scharf
2014.09.21 11:37:38.270 4: Alarm_scharf exec { system("echo MESG Alarm wurde auf off geschaltet | nc 192.168.2.30 6419") }
2014.09.21 11:37:38.271 5: Cmd: >{ system("echo MESG Alarm wurde auf off geschaltet | nc 192.168.2.30 6419") }<
2014.09.21 11:38:41.487 3: Alarm_scharf return value: -1
2014.09.21 11:38:41.489 5: Triggering Alarm_scharf_ton_aus
2014.09.21 11:38:41.490 4: Alarm_scharf_ton_aus exec set mp3_play playTone 255,019,002
2014.09.21 11:38:41.491 5: Cmd: >set mp3_play playTone 255,019,002<
2014.09.21 11:38:41.496 5: Triggering CFM (1 changes)
2014.09.21 11:38:41.496 5: Notify loop for CFM CMDs_pending
2014.09.21 11:38:41.507 5: CUL_HM CFM protEvent:CMDs_pending pending:1
2014.09.21 11:38:41.509 5: Triggering mp3_play (1 changes)
2014.09.21 11:38:41.509 5: Notify loop for mp3_play set_playTone 255,019,002
2014.09.21 11:38:41.515 3: CUL_HM set mp3_play playTone 255,019,002
2014.09.21 11:38:41.519 5: CUL_HM CFM protEvent:CMDs_processing... pending:0

[betateilchen]

Leg doch ein presence für den VDR an und schicke die Nachricht nur dann, wenn das Gerät auch verfügbar ist. Das ist doch m.E. viel sinnvoller als ein Timeout.

[Markus Hermann]

Leider habe ich mich zu früh gefreut, denn auch wenn der VDR eingeschaltet ist und ich mit:

{ system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") } eine Nachricht an ihn sende, macht FHEM eine laaaaange Pause.

Code Auswählen Erweitern

2014.09.21 18:36:44.462 4: HTTP FHEMWEB:192.168.2.32:51242 GET /fhem&cmd=%7B+system%28%22echo+MESG+Alarm+wurde+auf+%25+geschaltet+%7C+nc+192.168.2.30+6419%22%29+%7D
2014.09.21 18:36:44.464 5: Cmd: >{ system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") }<
2014.09.21 18:41:45.981 4: /fhem&cmd=%7B+system%28%22echo+MESG+Alarm+wurde+auf+%25+geschaltet+%7C+nc+192.168.2.30+6419%22%29+%7D / RL:998 / text/html; charset=UTF-8 / Content-Encoding: gzip
/

Da es ja auf der Fritzbox funktionierte, muss es doch ein Problem mit dem Cubie sein. Auf beiden lief die Fhem V5.5.

Gruß
Markus

[Markus Hermann]

Nachtrag:

Kann es sein, dass sich der Befehl: {system("....")}
auf dem Cubietruck anders verhält als auf der FB?

Wenn ich {system("/usr/sbin/etherwake 00:26:18:05:9E:FA")} im Fhem Frontend eingebe oder auch per Telnet Port 7072, erhalte ich nur ein -1 und es passiert nichts.

Der selbe Befehl per Putty-SSH-Sitzung: /usr/sbin/etherwake 00:26:18:05:9E:FA funtioniert und der angesprochene PC wacht auf.

Ist das eveltuell ein Rechte-Problem? Kann deswegen auch der { system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") } die Zwangspause verursachen?

[Markus Hermann]

Ich pusch den Thread noch mal hoch, vielleicht hat ja noch jemand eine Idee:

In zwischen ist die FB7390 in den Ruhestand geschickt, bzw. frisst ihr Gnadenbrot bei meiner Tochter.
Als Nachfolger hängt jetzt eine FB 6360 am Kabeldeutschland-Netz, die eigentlicht für den Endanwender "tabu" ist, wenn es um offene Ports geht.

Daher habe ich jetzt noch 3 Baustellen auf dem Cubietruck mit Fhem:

• Das oben im 1. Posting genannte Problem, dass ich mein VDR nicht per: { system("echo MESG Alarm wurde auf % geschaltet | nc 192.168.2.30 6419") } mit Nachrichten versorgen kann. Hat nichts mit der FB zu tun, klappt aber leider nicht mehr auf dem CT.
  

• 2. Problem: {system("/usr/sbin/etherwake 00:26:18:05:9E:FA")} lässt sich auch nicht mehr ausführen, da fhem keine root-Rechte besitzt.

• 3. Problem, ich kann nicht mehr FHEM telefonieren lassen. D. h. ich habe mich per Alarmauslösung mit einem dial-script.sh mit Inhalt: echo "ATDT*129#017xxxxxxx1" | nc 192.168.2.1 1011 auf
  mein Handy anrufen lassen. Das klappt nun nicht mehr, der Port 1011 ist nicht mehr auf der FB 6360 offen. Vielleicht kann man ja FHEM als SIP-Client laufen lassen? Jemand eine Idee dazu?

Ansonsten bin ich mir dem Umzug auf den CT mehr als zufrieden, die Antwortzeiten sind insgesamt sehr schnell, besonders Floorplan reagiert auf meine Eingaben prompt und auch die Schaltvorgänge per FS2 oder HMLAN sind unmittelbar ausgeführt.

Wenn die 3 Problemchen auch noch gelöst werden, bin ich glücklich

Kann mir jemand helfen?

Gruß
Markus

[betateilchen]

Zumindest Punkt 2 sollte sich einfach lösen lassen:

• 2. Problem: {system("sudo /usr/sbin/etherwake 00:26:18:05:9E:FA")} lässt sich auch nicht mehr ausführen, da fhem keine root-Rechte besitzt.

Du musst natürlich den User "fhem" in /etc/sudoers entsprechend eintragen (siehe manpage)

[Markus Hermann]

Danke für den Tipp, will aber noch nicht so richtig:

In der /etc/sudoers steht jetzt:

root   ALL=(ALL:ALL) ALL
fhem  ALL=(ALL:ALL) ALL

In FHEM dann das eigeben: {system("/usr/sbin/etherwake 00:26:18:05:9E:FA")}

ergibt ein -1 und im Log steht etherwake: This program must be run as root.

[betateilchen]

In FHEM dann das eigeben: {system("/usr/sbin/etherwake 00:26:18:05:9E:FA")}

da fehlt das sudo - schau Dir meinen vorigen Beitrag nochmal genau an.

[Markus Hermann]

Wer "genau" lese kann ist noch klarer im Vorteil  , das sudo habe ich glatt über lesen.
Aber jetzt erhalte ich die Meldung:

sudo: no tty present and no askpass program specified


BTW: mein 3. Problem lässt sich wohl mit linphone lösen, dank dieser Idee von Samsi: http://forum.fhem.de/index.php/topic,26136.0.html

[betateilchen]

sudo: no tty present

Du musst in /etc/passwd den fhem-Eintrag ändern: Von /bin/false auf /bin/bash

and no askpass program specified

Du musst in der /etc/sudoers den fhem-Eintrag auf NOPASSWD ändern. Ausserdem solltest Du dort nicht ALL verwenden, sondern die Programmnamen, die fhem ohne Passwort ausführen darf, explizit angeben (siehe manpage zu sudo / sudoers)

[Markus Hermann]

Super Danke Dir, jetzt lüppt es!