PRESENCE mit LAN-PING auf Raspberry PI

Begonnen von abraxas678, 18 Oktober 2016, 16:40:27

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1
Benutzer-Aktionen

abraxas678

18 Oktober 2016, 16:40:27
Hallo,

ich habe folgendes PRESENCE auf meinen zweiten Raspberry PI laufen:

Code Auswählen
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:

Code Auswählen
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!

Markus Bloch

#1
18 Oktober 2016, 17:07:12
Setz mal bitte das Attribut verbose auf 5 und poste mal die entsprechenden Logmeldungen nach zwei Durchgängen.

Danke

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

abraxas678

#2
18 Oktober 2016, 17:14:51
gerne, hier der Log:

Code Auswählen
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

Markus Bloch

#3
18 Oktober 2016, 23:02:10
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

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

abraxas678

#4
19 Oktober 2016, 02:22:27
Hallo,

hier der apptime:

Code Auswählen
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

der-Lolo

#5
19 Oktober 2016, 06:37:49
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.

abraxas678

#6
19 Oktober 2016, 12:40:32
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.

isy

#7
19 Oktober 2016, 20:07:02
Die Dash Buttons laufen besser mit dem neuen dash_dhcp Modul.
Habe auch umgestellt, nicht schwer.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

der-Lolo

#8
19 Oktober 2016, 22:26:59
Ok, also lag ich da wohl falsch...

isy

#9
19 Oktober 2016, 22:45:31
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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

bendim

#10
15 November 2016, 17:54:52
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




Drucken
Nach oben Seiten1
Benutzer-Aktionen