Nabend,
ich versuche gerade das Presence-modul erstmalig in Betrieb zu nehmen.
Zuerst habe ich es im Modus "fritzbox", danach als "lan-ping" probiert.
Jedesmal nach Eingabe von z.B. "define testname PRESENCE lan-ping 192.168.0.23" stellt sich FHEM von einer Sekunde auf die andere tot.
Im Log erscheint nichts, auf einer parallel geöffneten TELNET-Konsole jedoch ein "perl: can't resolve symbol 'getspnam'".
Es verhält sich sogar dann noch genau so wenn ich "define testname PRESENCE" eingebe, also ohne die erforderlichen weiteren Parameter.
Nur möglicherweise damit verbundene Vorgeschichte:
-2014.03.06 17:21 wie gewohnt ein automatisches Update gemacht, alles i.O. vorher und nachher.
-2014.03.06 22:53 noch ein Update gefahren, wonach die FS20-Geräte nicht mehr erkannt wurden und auch kein Update mehr möglich war.
-2014.03.06 23:57 laut SVNlog hat rudi dann noch ein Bugfix "fhem.pl: AssignIoPort bugfix" eingecheckt.
-2014.03.07 00:51 Die neue fhem.pl per telnet und wget heruntergeladen, danach lief FHEM erstmal wieder komplett.
-2014.03.08 01:28 noch ein Update probiert, keine Reaktion im Eventmonitor. Auf der Konsole Ausgabe: "Undefined subroutine &main::DevIo_CloseDev called at FHEM/Blocking.pm line 86."
EDIT: Update funktioniert wieder, nachdem ich InitialUsbCheck wieder aktiviert bzw. das disable-attribut entfernt habe. Das ganze auch reproduzierbar, mit deaktiviertem InitalUsbCheck kommt wieder "Undefined subroutine &main::DevIo_CloseDev called at FHEM/Blocking.pm line 86."EDIT ENDE
Gegebenheiten:
-FritzBox 7570 mit Firmware 75.04.92
-FHEM 5.5 aus dem FB7270-Paket von fhem.de und 32 Mb Swap auf USB-Stick
-FHZ 1000 PC
-1 FHT80B mit FHT80TF
-9 FS20-Geräte, davon 3x FS20ST, 3x FS20DI, 1x FS20SIG, 1x FS20PIRI, 1x FS20S4
-An Zusatzmodulen nur das Dashboard eingebunden
Im Moment würde ich nur gerne mit dem Presence-Modul "spielen", kann es sein dass die Perl-Version dafür fehlerhaft kompiliert ist?
Oder hakt es nur in Verbindung mit dieser Fritzbox-Firmware?
Oder ist das ein Folgefehler, weil es mit der DevIO-Geschichte noch an anderen Stellen hakt?
Davon abgesehen erstmal einen riesigen Dank an die Entwickler dass FHEM überhaupt existiert, "Chapeau"!
- getspnam holt verschluesselte Passwort Daten aus /etc/shadow, diese Datei wird auf dem FB nicht benutzt/gepflegt.
- da getspnam nicht auf jedem System verfuegbar ist, pruft perl das beim Uebersetzen, und protokolliert es auch in perl/arch/Config_heavy.pl.
- in der 7270-er perl Version ist gespnam als vorhanden definiert, in der 7390-er als nicht vorhanden.
- ich vermute, dass in einem der FB-Updates seit Uebersetzen der 7270-er perl vor mehreren Jahren diese Funktion entfernt wurde.
Fragen:
- wozu benoetigt FHEM bzw. ping getspnam?
- reicht es Config_heavy.pl zu aendern, um das Problem zu vermeiden?
Hallo Rudolf, danke dass du dich meinem Problem so schnell angenommen hast!
F: reicht es Config_heavy.pl zu aendern, um das Problem zu vermeiden?
A: Nein, leider nicht. Ich habe in Config_heavy.pl Zeile 398 von "d_getspnam='define'" auf "d_getspnam='undef'" geändert, ohne Effekt.
F: wozu benoetigt FHEM bzw. ping getspnam?
A: Offenbar erfolgt der Aufruf durch "(getpwuid($<))" in den Zeilen 97 und 111 von 73_PRESENCE.pm. Ich habe, in Anlehnung an die Zeile 447 von fhem.pl diese Ausschnitte durch "(getlogin || getpwuid($<) || "unknown")" ersetzt, nun funktioniert das Presence-Modul einwandfrei.
Ich habe aber keine Ahnung ob das ein geeigneter Bugfix oder nur ein schmutziger Workaround ist. Perl ist mir noch sehr fremd.
Momentan ist mir damit sehr gut geholfen.
P.S.: Soll ich für den merkwürdigen Zusammenhang zwischen dem "InitialUsbCheck" und der Update-Funktion ein weiteres Topic öffnen?
Hallo zusammen,
klingt für mich schlüssig. Ist in http://perldoc.perl.org/functions/getlogin.html auch so festgehalten.
@rudi: Wenn das aus deiner Sicht ebenfalls passt, würde ich das in PRESENCE ändern. In fhem.pl ist dieser Aufruf meines Wissens nach ebenfalls enthalten für die Started-Message.
Gruß
Markus
Ich muss hier nochmal einhaken, nachdem ich nun etwas getestet habe.
Ich habe:
-2 Geräte mit lan-ping definiert
-2 (andere) Geräte mit fritzbox definiert
-für alle Geräte das Attribut "event-on-change-reading state" gesetzt
Die lan-ping-Geräte geben zuverlässig und schnell ihren Status aus, wenn ich manuell den StatusRequest auslöse. Von selbst passiert aber auch nach mehreren Minuten nichts.
Die fritzbox-Geräte dagegen bleiben konstant auf "active" stehen. M.E. bleibt also die Statusabfrage mittendrin hängen?!
Muss ich für die automatische Abfrage der lan-ping-Geräte den Watchdog implementieren wie im Wiki-Beispiel? Bisher erscheinen mir die Events davon komplett unabhängig zu sein, kommen aber erst nach manuellem StatusRequest.
Für sachdienliche Hinweise bin ich sehr dankbar! :)
EDIT:
Nach einem "Save Config" und "Shutdown restart" funktionieren die lan-pings nun einwandfrei, geben innerhalb von 30s selbsttätig die entsprechenden Events.
Die fritzbox-Geräte hatte ichzwischenzeitlich disabled, nach löschen vom disable bleiben sie nun auf "defined" stehen statt dem vorherigen "active". Daran ändert auch ein StatusRequest nichts.
EDIT ENDE
Zitat von: Wichtel am 08 März 2014, 15:03:56
Die fritzbox-Geräte hatte ichzwischenzeitlich disabled, nach löschen vom disable bleiben sie nun auf "defined" stehen statt dem vorherigen "active". Daran ändert auch ein StatusRequest nichts.
Das kann ich nicht bestätigen. Nutzt du die aktuellste FHEM Version? Gib mal bitte den Befehl "version" im Webinterface oben ein und drück Enter.
Danke Gruß
Markus
"version" gibt:# $Id: fhem.pl 5156 2014-03-06 22:57:44Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 5144 2014-03-06 10:05:53Z rudolfkoenig $
# $Id: 11_FHT.pm 5070 2014-02-28 07:48:55Z rudolfkoenig $
# $Id: 00_FHZ.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 10_FS20.pm 5002 2014-02-20 19:24:18Z rudolfkoenig $
# $Id: 92_FileLog.pm 5068 2014-02-28 07:15:18Z rudolfkoenig $
# $Id: 98_JsonList.pm 4128 2013-10-29 06:51:24Z rudolfkoenig $
# $Id: 73_PRESENCE.pm 3831 2013-09-01 09:43:08Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 5076 2014-03-01 06:30:23Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 90_at.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_autocreate.pm 5015 2014-02-21 20:38:59Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 4933 2014-02-15 08:22:35Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_update.pm 4070 2013-10-19 11:22:17Z rudolfkoenig $
# $Id: 98_weblink.pm 3770 2013-08-23 13:29:58Z rudolfkoenig $
"update check" ergibt allerdings nur:
List of new / modified files since last update:
UPD ./CHANGED
UPD ./configDB.pm
UPD ./fhem.pl
UPD FHEM/00_THZ.pm
UPD FHEM/10_EnOcean.pm
UPD FHEM/70_PHTV.pm
UPD FHEM/93_DbLog.pm
UPD FHEM/98_Text2Speech.pm
UPD FHEM/98_backup.pm
UPD FHEM/98_configDBwrap.pm
UPD FHEM/98_update.pm
UPD docs/commandref.html
UPD docs/commandref_DE.html
Demnach scheine ich wirklich eine sehr alte Version von 73_PRESENCE.pm zu haben, da im SVNLOG seitdem einige Updates stehen.
Aus welchem Grund wurde es von den Updates nicht erfasst?
Das kann ich dir leider nicht sagen.
Mach daher bitte einmal ein update. Sollte PRESENCE dann nicht die Version 5031 vom 23.02.2014 sein, dann mach bitte ein "update 73_PRESENCE.pm".
Anschließend einen Neustart.
Gruß
Markus
@rudi: wie schauts bei dem getlogin/getpwuid?
So, aktuelle Situation:
Habe ein "update force" gefahren.
"version" ist nun:# $Id: fhem.pl 5175 2014-03-09 12:31:07Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 5144 2014-03-06 10:05:53Z rudolfkoenig $
# $Id: 11_FHT.pm 5070 2014-02-28 07:48:55Z rudolfkoenig $
# $Id: 00_FHZ.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 10_FS20.pm 5002 2014-02-20 19:24:18Z rudolfkoenig $
# $Id: 92_FileLog.pm 5068 2014-02-28 07:15:18Z rudolfkoenig $
# $Id: 73_PRESENCE.pm 5031 2014-02-23 21:41:47Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 5076 2014-03-01 06:30:23Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 90_at.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_autocreate.pm 5015 2014-02-21 20:38:59Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 4933 2014-02-15 08:22:35Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_weblink.pm 3770 2013-08-23 13:29:58Z rudolfkoenig $
Allerdings ist die Situation unverändert. fritzbox-presences bleiben auf "defined" oder "active" einfach stehen.
Zusätzlich habe ich jetzt aber bemerkt: Sobald eine der fritzbox-presence-defines in fhem.cfg steht (auch wenn disabled) ist kein Update mehr möglich und auf der Konsole erscheint beim fhem-start und auch beim update-Versuch:
perl: can't resolve symbol '__floatunsidf'
Ich stehe nun, ähnlich wie beim getspnam-Ding ziemlich auf dem Schlauch auf welchem Wege dieser Aufruf erfolgt.
Gibt es einen Weg dem Perl-Interpreter hilfreichere Ausgaben zu entlocken, sowas wie eine verbose-Option?
am besten bei FHEM im Global das verbose auf 5 stellen und dann neustarten. Mal schauhen wo Perl dann aussteigt.
Zitat von: Markus Bloch am 09 März 2014, 21:20:02
am besten bei FHEM im Global das verbose auf 5 stellen und dann neustarten. Mal schauhen wo Perl dann aussteigt.
Leider scheint es keine Hinweise zu geben:
2014.03.09 21:55:25 0: Server started with 41 defined entities (version $Id: fhem.pl 5175 2014-03-09 12:31:07Z rudolfkoenig $, os linux, user root, pid 4797)
2014.03.09 21:55:25 5: PRESENCE (PC1) - resetting Timer
2014.03.09 21:55:25 5: PRESENCE (PC1) - starting Blocking call for mode lan-ping
2014.03.09 21:55:25 5: PRESENCE (PC2) - resetting Timer
2014.03.09 21:55:25 5: PRESENCE (PC2) - starting Blocking call for mode lan-ping
2014.03.09 21:55:25 5: PRESENCE_DoLocalPingScan: PC2|192.168.0.20|0|4
2014.03.09 21:55:25 5: PRESENCE (iPhone) - resetting Timer
2014.03.09 21:55:25 5: PRESENCE (iPhone) - starting Blocking call for mode fritzbox
2014.03.09 21:55:26 5: PRESENCE_DoLocalPingScan: PC1|192.168.0.23|0|4
2014.03.09 21:55:26 5: PRESENCE_DoLocalFritzBoxScan: iPhone|Testnames-iPhone|0|0
2014.03.09 21:55:26 4: Connection accepted from FHEMWEB:192.168.0.23:56045
2014.03.09 21:55:26 5: Cmd: >attr dasDASH_weblink room DashboardRoom<
2014.03.09 21:55:26 4: Connection accepted from FHEMWEB:192.168.0.23:56046
2014.03.09 21:55:26 5: PRESENCE (iPhone) - ctlmgr_ctl (getting device count) returned: 15
2014.03.09 21:55:26 5: PRESENCE (iPhone) - checking with device number 0 the speed state (Blueray-Player)
2014.03.09 21:55:28 4: HTTP FHEMWEB:192.168.0.23:56045 GET /fhem?XHR=1&inform=type=status;filter=×tamp=1394398519233
2014.03.09 21:55:28 4: HTTP FHEMWEB:192.168.0.23:56046 GET /fhem
2014.03.09 21:55:28 4: /fhem / RL:884 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.03.09 21:55:28 4: Connection accepted from FHEMWEB:192.168.0.23:56047
2014.03.09 21:55:28 4: Connection closed for FHEMWEB:192.168.0.23:56046
2014.03.09 21:55:28 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem
2014.03.09 21:55:29 4: /fhem / RL:884 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.03.09 21:55:29 5: PRESENCE (PC1) - ping command returned with output:
PING 192.168.0.23 (192.168.0.23): 56 data bytes
64 bytes from 192.168.0.23: seq=0 ttl=64 time=170.102 ms
64 bytes from 192.168.0.23: seq=1 ttl=64 time=0.545 ms
64 bytes from 192.168.0.23: seq=2 ttl=64 time=1.046 ms
64 bytes from 192.168.0.23: seq=3 ttl=64 time=0.999 ms
--- 192.168.0.23 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.545/43.173/170.102 ms
2014.03.09 21:55:29 4: Connection accepted from telnet:127.0.0.1:3143
2014.03.09 21:55:29 5: Cmd: >{PRESENCE_ProcessLocalScan('PC1|0|present')}<
2014.03.09 21:55:29 5: PRESENCE_ProcessLocalScan: PC1|0|present
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/pgm2/style.css
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/pgm2/dashboard.js
2014.03.09 21:55:29 4: Connection accepted from FHEMWEB:192.168.0.23:56050
2014.03.09 21:55:29 5: PRESENCE (PC2) - ping command returned with output:
PING 192.168.0.20 (192.168.0.20): 56 data bytes
64 bytes from 192.168.0.20: seq=0 ttl=128 time=94.346 ms
64 bytes from 192.168.0.20: seq=1 ttl=128 time=0.982 ms
64 bytes from 192.168.0.20: seq=2 ttl=128 time=1.254 ms
64 bytes from 192.168.0.20: seq=3 ttl=128 time=0.977 ms
--- 192.168.0.20 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.977/24.389/94.346 ms
2014.03.09 21:55:29 4: Connection accepted from FHEMWEB:192.168.0.23:56051
2014.03.09 21:55:29 4: Connection accepted from telnet:127.0.0.1:3144
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56050 GET /fhem/pgm2/jquery.min.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.03.09 21:55:29 4: Connection accepted from FHEMWEB:192.168.0.23:56052
2014.03.09 21:55:29 5: Cmd: >{PRESENCE_ProcessLocalScan('PC2|0|present')}<
2014.03.09 21:55:29 5: PRESENCE_ProcessLocalScan: PC2|0|present
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56051 GET /fhem/pgm2/jquery-ui.min.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56050 GET /fhem/pgm2/fhemweb_multiple.js
2014.03.09 21:55:29 4: Connection accepted from FHEMWEB:192.168.0.23:56053
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56051 GET /fhem/pgm2/fhemweb_slider.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56052 GET /fhem/pgm2/svg.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/pgm2/fhemweb_noArg.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56051 GET /fhem/pgm2/fhemweb_textField.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56053 GET /fhem/pgm2/fhemweb.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56052 GET /fhem/pgm2/fhemweb_time.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56050 GET /fhem/pgm2/fhemweb_svg.js
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/pgm2/dashboard_darkstyle.css
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem/images/default/fhemicon_dark.png
2014.03.09 21:55:29 4: HTTP FHEMWEB:192.168.0.23:56050 GET /fhem/images/default/icoEverything.png
2014.03.09 21:55:30 4: HTTP FHEMWEB:192.168.0.23:56047 GET /fhem?XHR=1&inform=type=status;filter=×tamp=1394398531429
2014.03.09 21:55:36 4: Connection closed for FHEMWEB:192.168.0.23:56047
2014.03.09 21:55:36 4: HTTP FHEMWEB:192.168.0.23:56050 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-03.log
Bin wieder ein Stück weiter:
Da die letzte Meldung aus einer Schleife in PRESENCE_DoLocalFritzBoxScan($) stammt habe ich mich da mal ausgetobt.
Die Schleife lief nicht durch, es scheint an der sleep-anweisung zu liegen. Wenn ich den sleep in Zeile 671 auskommentiere läuft die Schleife.
Die Presence zeigt er jetzt auch korrekt an, allerdings nur im repeater-Mode. Auf der Konsole erhalte ich:
# /usr/bin/ctlmgr_ctl r landevice settings/landevice0/speed
er
In der beim repeater-mode verwendeten "active"-Variante klappt es:# /usr/bin/ctlmgr_ctl r landevice settings/landevice0/active
0
Die Fritzbox war zwar mal als WDS-Basisstation eingerichtet, das ist seit längerem aber wieder deaktiviert.
Bei den meisten Geräten taucht im Webinterface der FB auch die Geschwindigkeitsangabe auf, aber das speed-Kommando meldet auch bei denen nur "er".
M.E. ist also einerseits eine Prüfung des Rückgabewerts von ctlmgr_ctl nötig, andererseits scheint meine Fritzbox generell keinen "speed" liefern zu wollen.
Und warum die sleep-anweisung nicht will vermag ich grad nur zu rätseln.
Was hier noch nicht funktioniert:
-Es lässt sich aktuell (mit auskommentiertem Sleep) nur ein fritzbox-Gerät überwachen. Das jeweils zuletzt aktivierte wird korrekt abgefragt, andere werden nicht mehr aktualisiert, im log taucht dabei einmal "ctlmgr_ctl is locked. waiting 5 seconds..." auf.
-Die Updatefunktion stellt sich immer noch tot.