Hallo,
ich habe folgendes PRESENCE auf meinen zweiten Raspberry PI laufen:
define PR_LAN_DB2 PRESENCE lan-ping 192.168.188.42 2 2
attr PR_LAN_DB2 ping_count 1
attr PR_LAN_DB2 room Presence
attr PR_LAN_DB2 verbose 3
Auf dem PI läuft nichts anderes, keine weiteren FHEM Geräte etc, er ist ausschliesslich dazu da, dieses eine PRESENCE durchzuführen. (In Zukunft sollten es bis zu 5 sein).
Er sollte alle 2 Sekunden die Prüfung durchführen, macht das aber nur alle 10-12 Sekunden. Hier der Monitor Auszug:
2016-10-18 16:37:42 PRESENCE PR_LAN_DB2 absent
2016-10-18 16:37:42 PRESENCE PR_LAN_DB2 presence: absent
2016-10-18 16:37:54 PRESENCE PR_LAN_DB2 absent
2016-10-18 16:37:54 PRESENCE PR_LAN_DB2 presence: absent
2016-10-18 16:38:06 PRESENCE PR_LAN_DB2 absent
2016-10-18 16:38:06 PRESENCE PR_LAN_DB2 presence: absent
2016-10-18 16:38:18 PRESENCE PR_LAN_DB2 absent
2016-10-18 16:38:18 PRESENCE PR_LAN_DB2 presence: absent
2016-10-18 16:38:30 PRESENCE PR_LAN_DB2 absent
2016-10-18 16:38:30 PRESENCE PR_LAN_DB2 presence: absent
Hat jemad eine Idee warum er das nicht jede Sekunde macht? Ich Thread "Amazon Dashbutton" lassen einige das LAN mit einem PI jede Sekunde prüfen und es funktioniert. An der Leistung des PIs liegt es also nicht?!
Danke!
Setz mal bitte das Attribut verbose auf 5 und poste mal die entsprechenden Logmeldungen nach zwei Durchgängen.
Danke
Gruß
Markus
gerne, hier der Log:
From 192.168.188.37 icmp_seq=1 Destination Host Unreachable
PING 192.168.188.42 (192.168.188.42) 56(84) bytes of data.
2016.10.18 17:13:06 5: PRESENCE (PR_LAN_DB2) - ping command returned with output:
2016.10.18 17:13:03 5: PRESENCE (PR_LAN_DB2) - starting ping scan: PR_LAN_DB2|192.168.188.42|0|1
2016.10.18 17:13:03 5: PRESENCE (PR_LAN_DB2) - starting blocking call for mode lan-ping
2016.10.18 17:13:03 5: PRESENCE (PR_LAN_DB2) - stopping timer
2016.10.18 17:13:01 4: PRESENCE (PR_LAN_DB2) - rescheduling next check in 2 seconds
2016.10.18 17:13:01 5: PRESENCE (PR_LAN_DB2) - blocking scan result: PR_LAN_DB2|0|absent
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
--- 192.168.188.42 ping statistics ---
From 192.168.188.37 icmp_seq=1 Destination Host Unreachable
PING 192.168.188.42 (192.168.188.42) 56(84) bytes of data.
2016.10.18 17:13:01 5: PRESENCE (PR_LAN_DB2) - ping command returned with output:
2016.10.18 17:12:58 5: PRESENCE (PR_LAN_DB2) - starting ping scan: PR_LAN_DB2|192.168.188.42|0|1
2016.10.18 17:12:58 5: PRESENCE (PR_LAN_DB2) - starting blocking call for mode lan-ping
2016.10.18 17:12:58 5: PRESENCE (PR_LAN_DB2) - stopping timer
2016.10.18 17:12:56 4: PRESENCE (PR_LAN_DB2) - rescheduling next check in 2 seconds
2016.10.18 17:12:56 5: PRESENCE (PR_LAN_DB2) - blocking scan result: PR_LAN_DB2|0|absent
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
--- 192.168.188.42 ping statistics ---
From 192.168.188.37 icmp_seq=1 Destination Host Unreachable
PING 192.168.188.42 (192.168.188.42) 56(84) bytes of data.
2016.10.18 17:12:56 5: PRESENCE (PR_LAN_DB2) - ping command returned with output:
2016.10.18 17:12:53 5: PRESENCE (PR_LAN_DB2) - starting ping scan: PR_LAN_DB2|192.168.188.42|0|1
2016.10.18 17:12:53 5: PRESENCE (PR_LAN_DB2) - starting blocking call for mode lan-ping
2016.10.18 17:12:53 5: PRESENCE (PR_LAN_DB2) - stopping timer
2016.10.18 17:12:51 4: PRESENCE (PR_LAN_DB2) - rescheduling next check in 2 seconds
2016.10.18 17:12:51 5: PRESENCE (PR_LAN_DB2) - blocking scan result: PR_LAN_DB2|0|absent
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
--- 192.168.188.42 ping statistics ---
From 192.168.188.37 icmp_seq=1 Destination Host Unreachable
PING 192.168.188.42 (192.168.188.42) 56(84) bytes of data.
2016.10.18 17:12:46 5: PRESENCE (PR_LAN_DB2) - ping command returned with output:
2016.10.18 17:12:43 5: PRESENCE (PR_LAN_DB2) - starting ping scan: PR_LAN_DB2|192.168.188.42|0|1
2016.10.18 17:12:43 5: PRESENCE (PR_LAN_DB2) - starting blocking call for mode lan-ping
2016.10.18 17:12:43 5: PRESENCE (PR_LAN_DB2) - stopping timer
2016.10.18 17:12:41 4: PRESENCE (PR_LAN_DB2) - rescheduling next check in 2 seconds
2016.10.18 17:12:41 5: PRESENCE (PR_LAN_DB2) - blocking scan result: PR_LAN_DB2|0|absent
Hi,
generell ist zu sagen, dass das Interval "2 Sekunden" nicht bedeutet, dass aller 2 Sekunden ein Ping-Check startet, sondern, dass nach einem abgeschlossenen Ping 2 Sekunden gewartet wird, bis der nächste Check gestartet wird. Das kann man auch in den Logs erkennen, dass nach dem eingetroffenen Ergebnis der nächste Check in 2 Sekunden gestartet wird.
Man kann aus dem Log erkennen, dass irgendwo anders in deiner FHEM Installation Verzögerungen entstehen und dadurch das ganze sich in die Länge zieht.
Führe bitte mal in der FHEM Oberfläche das Kommando "apptime" aus. Nun wird in FHEM jeder Funktionsaufruf geloggt mit seiner Dauer. Dann warte mal ein paar Minuten und gib es anschließend nochmal apptime erneut ein um das Ergebnis zu sehen. Das bitte hier mal posten.
Vielen Dank
Gruß
Markus
Hallo,
hier der apptime:
name function max count total average maxDly
tmr-PRESENCE_StartLocalScan HASH(0x233db98) 70 1551 38686 24.94 9 HASH(PR_LAN_DB2)
WEB_192.168.188.41_50732 FW_Read 61 5 79 15.80 0 HASH(WEB_192.168.188.41_50732)
DB2 DOIF_Notify 37 1551 11351 7.32 0 HASH(DB2); HASH(PR_LAN_DB2)
CUL_0 CUL_Ready 35 7923 22125 2.79 0 HASH(CUL_0)
telnetPort telnet_Read 14 1551 6354 4.10 0 HASH(telnetPort)
WEB_192.168.188.41_50733 FW_Read 11 6 41 6.83 0 HASH(WEB_192.168.188.41_50733)
WEB_192.168.188.41_50734 FW_Read 6 2 11 5.50 0 HASH(WEB_192.168.188.41_50734)
WEB_192.168.188.41_50735 FW_Read 6 2 12 6.00 0 HASH(WEB_192.168.188.41_50735)
WEB_192.168.188.41_50736 FW_Read 6 4 24 6.00 0 HASH(WEB_192.168.188.41_50736)
WEB_192.168.188.41_50737 FW_Read 6 2 11 5.50 0 HASH(WEB_192.168.188.41_50737)
WEB FW_Read 5 11 40 3.64 0 HASH(WEB)
Logfile FileLog_Log 4 1551 381 0.25 0 HASH(Logfile); HASH(PR_LAN_DB2)
WEBtablet FW_Notify 4 1551 5 0.00 0 HASH(WEBtablet); HASH(PR_LAN_DB2)
WEB FW_Notify 2 1551 2 0.00 0 HASH(WEB); HASH(PR_LAN_DB2)
eventTypes eventTypes_Notify 2 1551 309 0.20 0 HASH(eventTypes); HASH(PR_LAN_DB2)
WEBphone FW_Notify 1 1551 1 0.00 0 HASH(WEBphone); HASH(PR_LAN_DB2)
tmr-FW_closeInactiveClients 1 133 26 0.20 20
DB4 dash_dhcp_Notify 0 1551 0 0.00 0
WEB_192.168.188.41_50733 FW_Notify 0 2 0 0.00 0
tmr-BlockingKill HASH(0x201f868) 0 1 0 0.00 4
tmr-BlockingKill HASH(0x2189b80) 0 1 0 0.00 4
Zuletzt stolperten wir darüber das fhem unter Debian Jessie keine rechte hat zu pingen.
Dem Presence Modul sah man das nicht an - ausser das die zustände nicht auf present gingen.
ZitatZuletzt stolperten wir darüber das fhem unter Debian Jessie keine rechte hat zu pingen.
Dem Presence Modul sah man das nicht an - ausser das die zustände nicht auf present gingen.
das ist es leider in meinem Fall nicht, Der PRESENCE geht auf present. Manchmal.
Ich möchte den DASH Button erkennen mittels dem LAN-PING. Da dieser jedoch nur ca. 3 Sekunden im WLAN erscheint, wird er oft/meistens nicht erkannt, wenn der PRESENCE nur alle 10+ Sekunden die Anwesenheit überprüft.
Die Dash Buttons laufen besser mit dem neuen dash_dhcp Modul.
Habe auch umgestellt, nicht schwer.
Ok, also lag ich da wohl falsch...
Es gibt meines Wissens nach noch keine komplette Anleitung /Wiki
Deswegen hatte ich meine Installation hier dokumentiert.
https://forum.fhem.de/index.php/topic,57248.msg504642.html#msg504642
Gruß Helmut
Ich habe zwei Varianten zusammengetragen und in ein Tutorial verfasst.
Versuch es mit der dash_dhcp Variant. Einfach und mit FHEM Boardmitteln.
Variante 1 mit dem FHEM Modul dash_dhcp https://maker-tutorials.com/fhem-geraete-mit-amazon-dash-button-schaltensteuern-raspberry-pi-home-automation/#variante-1-fhem-modul-dash_dhcp (https://maker-tutorials.com/fhem-geraete-mit-amazon-dash-button-schaltensteuern-raspberry-pi-home-automation/#variante-1-fhem-modul-dash_dhcp)