FHEM Forum

FHEM - Hardware => Einplatinencomputer => Thema gestartet von: Markus Hermann am 19 September 2014, 22:38:53

Titel: Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: Markus Hermann am 19 September 2014, 22:38:53
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
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Puschel74 am 20 September 2014, 08:08:44
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 (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
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Markus Hermann am 20 September 2014, 10:08:14
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   (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
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Puschel74 am 20 September 2014, 10:22:31
Hallo,

ZitatDachte 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
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Markus Hermann am 21 September 2014, 11:52:08
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:

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

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
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: betateilchen am 21 September 2014, 12:31:28
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.
Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Markus Hermann am 21 September 2014, 18:56:36
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.

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

Titel: Antw:Fhem friert für Minuten ein wenn CUL device geladen.
Beitrag von: Markus Hermann am 22 September 2014, 19:36:03
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?




Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: Markus Hermann am 28 September 2014, 18:38:05
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:



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



Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: betateilchen am 28 September 2014, 20:18:12
Zumindest Punkt 2 sollte sich einfach lösen lassen:


Du musst natürlich den User "fhem" in /etc/sudoers entsprechend eintragen (siehe manpage)
Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: Markus Hermann am 29 September 2014, 09:57:46
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.

Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: betateilchen am 29 September 2014, 10:01:42
Zitat von: Markus Hermann am 29 September 2014, 09:57:46
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.
Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: Markus Hermann am 29 September 2014, 11:06:21
Wer "genau" lese kann ist noch klarer im Vorteil  ;D, 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



Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: betateilchen am 29 September 2014, 11:29:11
Zitat von: Markus Hermann am 29 September 2014, 11:06:21
sudo: no tty present

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

Zitat von: Markus Hermann am 29 September 2014, 11:06:21
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)

Titel: Antw:Fhem friert für Minuten ein wenn CUL geladen. (Anmerk. liegt nicht am CUL)
Beitrag von: Markus Hermann am 01 Oktober 2014, 11:06:22
Super Danke Dir, jetzt lüppt es!