Hallo,
auf der Suche nach einer Option meine LAN devices zu überwachen bin ich (natürlich) auf PRESENCE gestossen. Ein nettes Modul, schlank und einfach. Allerdings ist es mir etwas zu einfach. Ich bin auf 3 Details gestossen mit mehr oder weniger weitreichenden Auswirkungen.
Erst einmal vielen Danke an den Entwickler, meine Anmerkungen seid meine Befürfnisse und müssen nicht allgemeingültig sein.
Für mich taugt das Modul in der aktuellen Form leider nicht - so habe ich einmal angefangen, es anzupassen.
Vorneweg:
- Die Änderungen sind nicht umfassend. Es lan-ping funktioniert prima - alles andere habe ich nicht. Das würde ich nur bei Bedarf implementieren, wenn es jemand braucht, der Entwickler es nicht machen will und/oder ich es einmal selbst benötige
- die Dokumentation ist nicht komplett - für mich hinreichend. Sollte es Fans geben werden ich es vervollständigen.
Nun erst einmal mein Usecase: Ziel ist, einige LAN devices auf vorhanden sein zu überwachen. Das sind dann so 20+ devices.
BT werde ich nicht machen.
Event werde ich sicher nicht mit dieser Implementierung machen - aus verschiedenen Gründen. Es gibt hier aus meiner Sicht deutlich bessere Optionen. Das ist ein anderes Thema.
Warum glaube ich, ändern zu müssen:
A) Attribute und Definition
B) Zu Verfügung gestellte Informationen (readings)
C) Performance!!!
A) für mich geht es schlicht nicht, dass das Ping-Interval bei der Entity Definition angegeben wird und dann mit einem Kommando geändert werden kann. Das Ping-Interval ist ein Attribut und so zu erstellen
B) Nur present/absent zu sehen ist mir klar zu wenig. Ich will sehen, wann das Gerät das letzte mal present war und wann absent. Das ist das minimum. Weiter werde ich ein Reading einbauen, welches eine Aussage über die Stabilität des Devices gibt, also die Anzahl der "maybe" Änderungen.
C) Ein definitives no-go ist die Nutzung von Blocking. Natürlich ist es notwendig blocking zu nutzen. Aber es ist indiskutabel für jede Entity bei jedem Ping einmal FHEM zu forken. Bei 20 Devices, 30s ist das eine Kopie des gesamten Prozesses fast jede Sekunde zu erstellen. Meine Himbeere hat dies sowieso schon abgelehnt - wegen memory-problemen.
Die(meine) Lösung ändert das Verhalten von Presence. Der Ablauf ist, dass eine übergeordnete Entity, ein PRESENCE-deamon, instanziiert wird welcher alleinig das forken übernimmt.
Will sagen, der deamon (default name: PsnceDeamon) wird alle 30 sec oder über intervalNormal gesteuert aufgerufen und prüft, ob jemand pingen möchte. Es werden alle pings zusammengefasst und los gehts - einmal forken.
Damit sind die Pings der normalen entites auf das Raster des Deamons begrenzt.
Bislang ist es für lan-ping implementiert, was mir reicht.
Weiter habe ich die anzahl der Pings auf 1 festgesetzt. alles andere dauert zu lange, macht keinen Sinn. Die Dauer wird um potenzen reduziert, da bereits count2 min 1s dauert, count 1 aber nur ms.
Beim Aufräumen haben ich schon einmal aus meiner Sicht ungeeignete Attribute entfernt. So ist ein thresholdPresent aus meiner Sicht sinnlos. Wenn ich ein Device einmal sehe ist es da. Umgekehrt ist es sinnvoll. Man muss nicht alles implementieren, was technsich möglich ist, wenn es inhaltlich keinen Sinn macht.
Es lässt sich auch der Rest umstellen, bei Bedarf.
Da scheinbar alle mit der aktuellen Anwendunf zufrieden scheinen (was mich eigentlich wundert) werde ich hier wohl einfach meinen eigenen Weg gehen. Ein paralleles PRESENCE plane ich nicht veröffentlichen.
Hallo,
auch ich bin Anwender vom Presence-Modul und setze es öfters ein um zu sehen, ob Geräte via LAN oder WLAN erreichbar sind.
Über die Probleme, die Du angesprochen hast, bin ich noch nicht gestolpert - obwohl ich auch 20 Geräte überwache.
Das liegt natürlich an meinem "Nichtwissen" ;)
Prinzipiell fehlen mir am aktuellen Presence die gleichen Dinge wie Dir (z.B. Stabilität der Verbindung).
Daher probiere ich Deine Version gerne aus.
Einfach die Datei im Anhang über die in FHEM kopieren und neu starten?
lg, Gerhard
Hallo Gerhard,
wenn du nur "lan-ping" nutzt sollte es kein Problem sein.
Also austauschen und neu booten.
Es wird dann am Ende ein "PsnceDeamon" deamon angelegt.
Ich würde sagen, dass es funktionieren sollte. ".cfg" sichern schadet nicht. schlimstenfalls einfach das alte File wieder einspielen und booten - mehr kann nicht passieren.
Ich habe noch kleinigkeiten geändert. Vorschläge gerne.
Was du schlecht sehen kannst sind Fehler und Systemauslastung durch das viele forken.
Ich benutze PRESENCE mit lan-ping relativ exzessiv, um den (möglichen) Ausfall diverser Geräte und Anwesenheiten zu erkennen.
Ich habe - ohne es jemals näher untersucht zu haben - auch das Gefühl, dass es wegen PRESENCE gelegentlich zu Freezes bei mir kommt.
Ist Deine Version kompatibel? Teilweise nutzte ich PRESENCE noch mit local-bluetooth und function.
Vielleicht sollte man das Module PRESENCE2 (oder so ähnlich) nennen.
Zitat von: martinp876 am 23 Dezember 2020, 14:38:45
C) Ein definitives no-go ist die Nutzung von Blocking. Natürlich ist es notwendig blocking zu nutzen. Aber es ist indiskutabel für jede Entity bei jedem Ping einmal FHEM zu forken. Bei 20 Devices, 30s ist das eine Kopie des gesamten Prozesses fast jede Sekunde zu erstellen.
Ah! Das erklärt, warum mein FHEM in letzter Zeit immer mal wieder, den einen oder anderen Schaltvorgang etwas verzögert ausführt, bzw. Hänger zu haben scheint! :)
Seit ich kürzlich mein Netzwerk umgebaut habe, habe ich zur einfachen Überwachung einige (>20) PRESENCE-Instanzen eingerichtet. Und hatte gleich so ein Bauchgefühl, dass das evtl. mit Nebenwirkungen verbunden sein könnte, ohne dem weiter nach zu gehen.
Habe eben mal kurz nachgeschaut und ich verwende PRESENCE aktuell ebenfalls ausschließlich mit lan-ping, von daher werde ich mir deine "Cover-Version" die nächsten Tage auf jeden Fall mal anschauen.
Danke!
gb#
Hallo,
Danke. Das probiere ich mal.
Ich nutze halt nicht nur das LAN-ping, sondern auch lan-bluetooth und function/shellscript.
Da bin ich mal neugierig ;)
lg, Gerhard
nun, ich bastle mittlerweiel weiter, es in die Form zu bingen, wie es mir gefällt / sinnvoll erscheint.
Achtung: in der letzten Version dauert das Ping zu lange, falls das Device fehlt. Ist nun sinnvoll verkürzt.
===> was ist Sinnvoll
- ===> was ist Sinnvoll
neue Version im Anhang - ich beschäfftige mich wie gesagt mit lan-ping. Das andere sollte noch gehen - aber definitiv ohne gewähr.
Einbringen könnte ich bei gelegenheit noch "event" auf die weise, wie ich es für sinnvoll halte. Beispiel hierzu wäre CUL_HM ActionDetector. Genaueres auf Anfrage.
- ===> Einschränkungen - kompatibilität
nun, das ist schwer zu sagen. Kömmt darauf an, was ihr macht.
1) die Definitionen und Attribute sollten ohne Probleme übernommen werden. Man erhält nach Reboot ein lauffähiges system welches ähnlich wie vorher aggiert
2) readings "state" und "presence" waren identisch - was schon einmal keinen Sinn macht. "state" liefert nun "absent" oder "present" während "presence" auch "maybe" hinzufügt. Internals "STATE" kann man wie gewohnt über das einschlägige Attribut unschalten.
3) nachdem es nun mehr Readings gibt müssen notifies ggf. angepasst werden, wenn sie nicht "sauber" und explizit erstellt wurden
- ===> Alarming
Ich werde noch ein "grouping" implementieren. Use-case ist, dass ich erkennen will, welche Devices present sind. Dabei muss ich klassifizieren, "was" es ist. So habe ich network-devices (router, IOs,...) welche vorhanden sein "müssen". fehlen soll einen Alarm generieren (könnnen). Weiter gibt es "smartphones" - also "wer ist zu hause". Das führt natürlich nicht zu einem Alarm aber ggf zu anderen aktionen.
Damit ich nicht alles individuell erstellen muss ist ein grouping m.E. hilfreich - und einfach ist es sowieso
- ===>updates
wenn ich dazu komme gibt es heute noch eine Version mit grouping feature
Blocking - was ist dasZur Info - falls jemand glaubt, keine Probleme erkannt zu haben:
Blocking ist eine überaus sinnvolle funktion welche zwingend notwendig ist, halbwegs Echtzeit arbeiten zu können. Für presence unabdingbar.
Was macht es: der FHEM-Prozess wird ge-forked. Bedeuted der KOMPLETTE FHEM Prozess wird auf OS Ebene dupliziert. Das kostet erst einmal Performance und natürlich Speicher (RAM). Auch wenn der Mutter-Prozess erst einmal fast ohne es zu bemerken weiter läuft so ist das doch ein erheblicher Aufwand auf OS Ebene.
Je größer das GeramtSystem desto mehr Aufwand ist es - auch wenn die Aufgabe im geforkten Prozess nur minimal ist. => die Skalierbarkeit und die Auswirkungen sind nicht wirklich absehbar.
###> Blocking sollte man sparsam und dediziert nutzen
a) ich nutze Blocking für User initiierte Aufrufe (kommandos) und seltene Ereignisse
b) Presence MUSS blocking nutzen - aber man MUSS es gruppieren. Die offizielle Version lässt nur ein Blocking zu - je Entity. Das geht nicht! Es darf nur ein Blocking für Presence overall geben. Ein blocking je mode - möglich, ok. Mehr definitiv nicht.
Wenn ich so genauer darüber nachdenke, dann scheinst Du die gleichen Problem zu haben wie viele von uns.
Nur wäre ich nie draufgekommen ;)
Da Du ja wirklich einen großen Umbau im Modul machst, warum wirfst Du den Ballast der anderen Funktionalität nicht über Board und nennst Dein Modul z.B. PRESENCE2?
Es hat sich zwar schon länger nichts mehr im Presence-Modul getan (glaube ich), aber wenn mal ein Fehler in den anderen Funktionen entdeckt wird, dann muss man den selbst nachziehen.
Was spricht eigentlich dagegen, Deine tolle Arbeit in ein eigenes Modul auszulagern?
lg, Gerhard
p.s.: Das mit dem CUL_HM ActionDetector würde mich z.B. auch schon mal sehr interessieren ;)
das forken zu reduzieren, ist eine sehr gute idee!
da kann ich das presence modul ja wieder in meinen fhem werkzeugkasten packen. :)
mit einem zusätzlichen attr alignTime, wie zb bei httpmod oder at, könnte man auch den forks anderer module aus dem weg gehen.
das sollte eigentlich jedes periodisch forkende modul können, finde ich.
nun, ich muss mir überlegen, die Pflege eines neuen Module "allgemein" zu übernehmen.
ein PRESENCE2 gefällt mir nicht so recht. Das ist einfach - aber irgendwie vermüllt es fhem.
Grundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
lan-ping - klar
fritzbox - outdated?
local-bluetooth - unklar
lan-bluetooth - unklar
function - unklar
shellscript - unklar
event - hier werden etliche timer aufgezogen. Event überwacht vorhandene Devices, welche schon eine Entitys haben. Ich möchte also keine weitere "Presence- entity welche die "phys-entits" überwacht. Anzustreben ist m.e. ein "Deamon" in welchen die zu überwachenden physEntites eingehängt werden.
Bei CUL_HM ist das der "ActionDetector" - hier könnte es über den "ping-deamon" geschehen. Dann braucht man keine neue entität.
Beim Überwachen kommt es nicht auf hohe Geschwindigkeit an. Es reicht, periodisch (bspw mit der deamon zeit) die phys-entits abzuklappern.
Den Status kann man dann gesammelt im deamon und einzeln als reading in der Phys-Entity abfragen - und hierzu notifies zuordnen wie gewohnt.
Das sollte schnell zusammencodiert sein, kein großer Stress. Die erwartete Meldezeit wird als Attribut in der (phys) entity eingegeben. Weiter braucht man noch das Reading, aus welchem der Zeitstempel kontrolliert werden muss (noch ein Attribut) - fertig.
Zum Kommentar, dass Module gewisse Aktionen bündeln sollten - unbedingt. Schon seit beginn vermisse ich eine "modul-entität". Eigentlich sollte diese den Deamon beinhalten, modul-status darstellen,... Vielleicht ist es mir bisher entgangen, aber ich meine FHEM unterstützt dies (aktuell) nicht. Schade.
oh das ist schön, bei mir läuft seit Jahren schon eine umgebaute PRESENCE Version weil mir damals auch das ein oder andere nicht gefallen hat.
Den Ping 1 habe ich auch so , ebenfalls die fehlenden Readings zum Teil, aber das mit dem Deamon gefällt mir richtig gut.
BTW ich nutze auch nur lan-ping.
Guten Morgen und frohe Weihnachten euch allen,
Zitat von: martinp876 am 24 Dezember 2020, 16:28:35
Grundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
lan-ping - klar
fritzbox - outdated?
local-bluetooth - unklar
lan-bluetooth - unklar
function - unklar
shellscript - unklar
In der Vergangenheit habe ich lan-ping und lan-bluetooth verwendet. Insbesondere lan-bluetooth mit der Verwendung von presenced und collectord fand ich sehr interessant.
Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.
Ich finde den Ansatz hervorragend und werde das hier weiter verfolgen.
Da es WLan-Geräten immer wieder Probleme gegeben hatta, bin ich dann auf G-Tags`s umgestiegen - also lan-bluetooth - und das funktioniert hervorragend.
Insofern wäre ich natürlich an einer weiteren Berücksichtigung von lan-bluetooth oder was vergleichbaren interessiert:-)
Gruß und frohe Festtage
eurofinder
Zitat von: Wolle02 am 25 Dezember 2020, 07:18:33
Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.
Moregähn.
Das löse ich mit einem Userreading im UnifiClient Gerät.
Ganz ohne Presence
Zitat von: Frank_Huber am 25 Dezember 2020, 08:51:44
Das löse ich mit einem Userreading im UnifiClient Gerät.
Ganz ohne Presence
Ja klar geht das. Viele Wege und so ........
Aber die Frage war ja, wie das Modul aktuell genutzt wird. Und da stand bei function -> unklar ..... ;)
Zitat von: Wolle02 am 25 Dezember 2020, 07:18:33
Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.
dito
Hallo Martin,
ZitatGrundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
weil Du gefragt hast, wer was verwendet:
- function: Ich verwende seit einem Jahr 'function' anstelle von lan-ping für etwa 20 devices, mit der FritzBox sub "check(W)LANMacPresent", aus dem Wiki, nachdem ich festgestellt hatte das lan-ping blocking ist, und dass das immer zu freezes führte. Hatte danach komplett umgestellt und von lan-ping auf function umgestellt.
- lan-bluetooth für die Presence erkennung mit presenced/lepresenced (Handy BT + GTAGS)
- local-bluetooth hatte ich benutzt bevor ich auf lan-bluetooth umgestellt habe
- Event halte ich auch für ueberflüssig.
Gruss, Jamo
Hallo Martin,
ich habe dein PRESENCE-Modul nun bei mir auch am Laufen.
Der Umstieg hat problemlos funktioniert. Wie sich das mit den "Freezes" werde ich die nächsten Tage beobachten.
Ein paar Fragen habe ich noch:
- Die Intervall-Angaben im DEF der devices werden nach Umsetzung auf die entsprechenden Attribute (btw.: gute Entscheidung) nicht mehr ausgewertet, sondern nur noch die neuen Attribute, korrekt?
- Die Intervall-Angaben in der Entity-DEF können also weg?
- Fehlen die Intervall-Angaben im DEF UND in den Attributen wird automatisch das am Daemon eingestellete Intervall verwendet.
- Die Intervallangaben bei den einzelnen Entitäten müssen (sinnvollerweise) entsprechend Ein- oder Vielfache der am Daemon eingestellten Intervall-Angaben sein?
Noch eine Idee zu einer möglichen, zukünftigen Umsetzung des PRESENCE-Moduls: Vielleicht lässt sich hier eine ähnliche Geschichte Umsetzen, wie es seinerzeit von Boris und CoolTux beim WEATHER-Modul gemacht wurde. Das heißt, die einzelnen Umsetzungen für lan-ping, bluetooth, .... werden in separaten Modulen, quasi als API-PlugIns bereitgestellt.
gb#
Hallo Martin,
das klingt vielversprechend. Ich nutze presence nur mit lan-ping für eine Handvoll Geräte.
Sagt Dir fping etwas? Damit lassen sich gleich mehrere Geräte im round robin verfahren abfragen. Gibt es wohl sogar als perl Modul.
Viele Grüße
Torsten
ZitatDie Intervall-Angaben im DEF der devices werden nach Umsetzung auf die entsprechenden Attribute (btw.: gute Entscheidung) nicht mehr ausgewertet, sondern nur noch die neuen Attribute, korrekt?
korrekt
ZitatDie Intervall-Angaben in der Entity-DEF können also weg?
korrekt. Sie werden in das Attribut übernommen (kompatibilität) und dann ggf durch eine explizizes Attribut überschrieben. Nach dem ersten Reboot/save ist es also Geschichte
ZitatFehlen die Intervall-Angaben im DEF UND in den Attributen wird automatisch das am Daemon eingestellete Intervall verwendet.
genau. Präzise: Der Deamon läuft stoisch in seinem Interval. Die Intervalle der entites werden von Deamon auf Ablauf geprüft und alle Abgelaufenen ausgeführt.
Bsp: Deamon: 30s
Entity : 1s => es wird alle 30 s geprüft
Entity : 40s => es wird alle 60 s geprüft, da nach dem prüfen die 40s addiert werden. Der Deamon kommt nach 30s,a lso zu früh. Dann nach 60s: Ausführen
Zitat- Die Intervallangaben bei den einzelnen Entitäten müssen (sinnvollerweise) entsprechend Ein- oder Vielfache der am Daemon eingestellten Intervall-Angaben sein?
Korrekt. Das könnte ich prüfen... ist aber viel Code frü wenig Brot. Wird das Interval des Deamons angepasst müssten alle Attribute der Entities überarbeitet werden.
=> siehe/teste "get PsnceDeamon statusInfo definition"
Modi:Die erste Version des "event" ist eingebaut. Die Idee
- attr global userAttr um "presentCycle" und "presentReading" erweitern.
- attr <entities> presentCycle <cycle> jeder Entity zuweisen, welche man überwachen will. "cycle" ist die Zeit in Sekunden, in welcher ein Update eines Readings erwartet wird
- attr <entities> presentReadinge <name> kann jeder Entity zuweisen um das zu überwachende Reading zu selektieren. Wird das attr nicht gsetzt wird "state" abgefragt.
Die Überwachnung käuft über den deamon - also wird auch wieder das Raster genutzt.
In der überwachten Entity wird ein Reading "presentStatus" gesetzt, welche den Zustand definiert
=> die Definition der Entity ist nicht notwendig, der Deamon findet alle entities mit Attribt presentCycle
=> maybe gibt es hier nicht (ich sehe den Sinn nicht)
function/shellscriptkann ich beides umplementieren - aktuel nicht enthalten. Allerdings auf die gleiche Weise, wie Ping (intern):
define sc PRESENCE shellscript <OS-command> <passString>
Das OS-command wird ausgeführt und der Rückgabewert verglichen mit <passString>. Ist der String enthalten ist alles gut, wenn nicht eben nicht.
Faktisch kann dann der User auch so(selbst) den Ping erstellen.
Hier schon einmal der Update zwischendurch.
Sollten noch sinnvolle Auswertungen fehlen, bitte info
fping kenne ich nicht Wäre cool - aber der aktuelle Ping nutzt schlicht OS funktionen für
=> die Erklärung sollte reichen.
Hallo,
danke für die neue Version.
Habe sie gleich ausprobiert.
- Es wird ein ein Device names presenceGateway angelegt.
- Das "lan-ping" scheint mal stabil zu funktionieren.
- "function" pendelt zwischen present/absent/error
Ich verwende dort {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30
- Das "lan-bluetooth" (mit collectord, lepresenced) pendelt zwischen present/absent
Code für CheckPresenceSMB:
sub CheckPresenceSMB($$) {
my ($ip,$wg) = @_;
my $ret = "";
$ret = qx(nmblookup $wg | grep -o $ip);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
if ($ret eq $ip) {
return 1;
}
lg, Gerhard
p.s.: Vor dem Einspielen des neuen Codes hat das stabil funktioniert. Vor allem das "lan-bluetooth"
So, update:
Die Version im Anhang kann nun
- lan-ping
- function (define <entity> PRESENCE function "{<function>}" '<testString>'
- shellscript (define <entity> PRESENCE shellscript "<command>" '<testString>'
- event durch die Nutzung der beschriebenen Attribute - kein "Define", keine Entity
Beispiel
defmod prfunct PRESENCE function "{PRESENCE_getDeamonName()}" 'PsnceDeamon'
defmod prScript PRESENCE shellscript "ping -c 1 -w 1 192.168.178.1 2>&1" '(ttl|TTL)=\d+'
Dokumentation ist noch nicht berichtigt.
Das eineoder andere wird sicher noch korrigiert -aber im gr0ßenund ganzen ist es erledigt.
Entfernt: Bluetooth und PowerCmd
- Es wird ein ein Device names presenceGateway angelegt.
=> sollte nun nicht mehr vorkommen - sicher ein Rest von BT
- "function" pendelt zwischen present/absent/error
Ich verwende dort {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30
=> das ist auch erst jetzt drin. Die Definition hat sich geändert. Die Funktion muss nocht 0/1 zurückgeben sondern nur einen beleibigen string. Du gibst weiter einen "vergleich" an. Wird der Vergleich im reply gefuden ist alles ok, "present"
- Das "lan-bluetooth" (mit collectord, lepresenced) pendelt zwischen present/absent
=> das habe ich auch nicht implementiert. Brauchst du das?
Probiere ich gleich. Danke!
Bei Deiner kurzen Umfrage haben ein paar Leute "ja" für "lan-bluetooth" (mit collectord, lepresenced) zurückgemeldet.
Ich denke, dass das einige Leute gerne hätten.
Und ja, ich würde es gerne haben.
Immerhin funktioniert die Abfrage der Gtags meiner Familie damit bisher ohne Probleme.
Bei den iPhones klappt es leider nicht mir lan-ping etc.
Anfangs melden die sich als "present", aber nach einiger Zeit sind die immer "absent" :(
lg, Gerhard
Habe gerade die neue Version eingespielt und fhem neu gestartet.
Beim Löschen des PsnceDeamon kommt die Meldung:
deletion of deamon not possible unless objects still present
lg, Gerhard
Noch eine Frage bitte:
Wie muss ich nun mein Presence-Device definieren?
Bisher hatte ich:
defmod presenceSynologySMB PRESENCE function {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30
Egal was ich eingebe, es kommt immer die Fehlermeldung: "The function call must be encapsulated by brackets ( {...} )."
Danke für die Hilfe.
lg, Gerhard
@martinp876:
Wie gestein bereits geschrieben hat:
ZitatImmerhin funktioniert die Abfrage der Gtags meiner Familie damit bisher ohne Probleme.
Bei den iPhones klappt es leider nicht mir lan-ping etc.
Genau aus diesem Grund setzte ich auch G-Tags ein. Wäre also super, wenn du lan-bluetooth wieder berücksichtigst.
Gruß
eurofinder
Hallo,
ich habe mir gerade ein neues PRESENCE-Device angelegt.
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30
attr Presence_Shelly_50 room 0_Testing
Aber es werden keine Readings angelegt, der Status bleibt auf "???".
Die raw-Definition lautet:
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30
attr Presence_Shelly_50 intervalNormal 30
attr Presence_Shelly_50 intervalPresent 30
attr Presence_Shelly_50 room 0_Testing
attr Presence_Shelly_50 verbose 5
setstate Presence_Shelly_50 2020-12-26 21:04:18 .associatedWith PsnceDeamon
setstate Presence_Shelly_50 2020-12-26 21:04:18 model lan-ping
Wieso gibt es keinen ping auf das Gerät?
Im PsnceDeamon gibt es auch kein Reading für den "Presence_Shelly_50".
lg, Gerhard
Zitat von: gestein am 26 Dezember 2020, 21:09:02
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30
Moin Gerhard,
hast du mal ohne die 30 probiert?
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50Gruss
Enno
Moin Enno,
ja, habe ich. Aber das gleiche Ergebnis.
Auch ein zweites Device mit der Adresse xxx.49 wird angelegt, aber im Device PsnceDeamon tauchen die beiden nicht in den Readings auf - nur die, die es zum Zeitpunkt des Anlegens des Deamon-Devices schon gab.
Im Reading pGrp_default steht "ab:8 pres:13", obwohl es eigentlich nun 23 PRESENCE-Devices gibt, von denen 21 zum Zeitpunkt des Anelgens da waren.
Die beiden neuen tauchen nicht auf.
Und eigentlich sind 8 present und 13 abwesend.
lg, Gerhard
Nach mehrmaligem Reboot passt nun alles.
Die neuen Devices funktionieren und werden im Deamon angezeigt.
lg, Gerhard
Reboot tut immer gut. 😂🤪
Ne, denke eher da hat was mit dem reload nicht gepasst.
Ich freue mich auch schon auf nen Test der neuen Version.
Hab presence nur per ping laufen. Zwar keine Probleme bemerkt, denke aber dass sie da sind die Probleme, nur eben unbemerkt....
Zitat von: martinp876 am 26 Dezember 2020, 15:16:19
korrekt. Sie werden in das Attribut übernommen (kompatibilität) und dann ggf durch eine explizizes Attribut überschrieben. <...> Nach dem ersten Reboot/save ist es also Geschichte
Das hat bei mir letztendlich nicht funktioniert (neueste Version), die Attribute waren nach save und restart trotzdem alle auf 30 Sekunden.
Habe dann die Attribute nochmal explizit von Hand gesetzt und gespeichert, dann hat's gepasst.
Ist aber kein Beinbruch und der Aufwand zu vernachlässigen. :)
Zitat von: martinp876 am 26 Dezember 2020, 15:16:19
Das könnte ich prüfen... ist aber viel Code frü wenig Brot.
Allerdings! Das ist keinen Aufwand wert!
gb#
dumme zwischenfrage:
würde ich dieses presence-modul verwenden, bliebe das auch für module kompatibel, die presence verwenden? z.b. das lg-tv modul? oder hab ich da eh nur was mißverstanden und das "alte" presence modul hat nix mit presence in anderen modulen gemein?
und noch ne dumme idee: warum nennt man das gute stück nicht einfach "ping" oder ähnlich? dann könnts nebenher existieren.
Zitat von: the ratman am 27 Dezember 2020, 11:04:45
dumme zwischenfrage:
würde ich dieses presence-modul verwenden, bliebe das auch für module kompatibel, die presence verwenden? z.b. das lg-tv modul? oder hab ich da eh nur was mißverstanden und das "alte" presence modul hat nix mit presence in anderen modulen gemein?
Interessante Frage: "Wird das Modul von anderen Modulen verwendet?"
Ein schneller grep hat mir keine Verwendung von 73_PRESENCE.pm in irgendeinem weiteren Modul gefunden.
Ich habe mir mal dann noch kurz in der commandref für beide existierenden lg-tv Module die entsprechenden Einträge durchgelesen. Da steht nix, dass die PRESENCE verwenden würden.
Im Wiki habe ich gesehen, dass lg-tv WebOS zumindest ein Reading "presence" bereitstellt. Das hat aber sicherlich nichts mit dem PRESENCE-Modul zu tun.
Ich gehe mal davon aus, dass das vom lg-tv-Modul internt geprüft wird. Darauf deutet auch der entsprechende Satz in der Commandref hin:
"Bei der Definition eines LGTV_WebOS-Moduls wird eine interne Routine in Gang gesetzt, welche regelmäßig alle 15s den Status des TV abfragt und entsprechende Notify-/FileLog-Definitionen triggert."Von daher sollte deine Sorge unbegründet sein :)
gb#
Hallo,
Habe mir zum Testen ca. 50 neue Presence-Devices für alle Geräte in meinem Netz angelegt.
Die zeigen auch absent/present und im Deamon angezeigt.
Allerdings stimmt der Status eigenartigerweise nicht bei allen Geräten.
Manche Geräte werden als absent gezeigt, obwohl es definitiv im Netz erreichbar ist.
Ping unter Windows liefert ,,erreichbar" und über Webinterface sind die auch ansprechbar.
Ein Neustart hat etwas geholfen, die allermeisten sind auf present.
Aber nicht alle.
Also habe ich im Deamon ,,verbose 5" gesetzt.
Im log erscheint nun alle 30sec. ,,PRESENCE (PsnceDeamon) - skip Scan due to running job".
Und das Reading ,,skipDeamonCnt" wird periodisch alle 30sec. auf 1 gesetzt.
Ich nehme an, dass die 50 pings zu viel für 30sec. sind.
Allerdings meldet der Deamon auch nach 30min nichts anderes.
Ist es möglich im Deamon ein Reading einzubauen, in dem man die letzte Meldung sieht?
Also z.B. ,,ok" Oder eben diese Meldung?
Lg, Gerhard
Moin Zusammen,
lese hier schon von Anfang mit und habe jetzt auf meinem Testsystem das neue PRESENCE losgelassen.
Erstmal vielen DANK @martinp876 für die tolle Arbeit! :)
Habe zum Test einmal lan-ping (Fritte) und einmal function (PREDeamon) angelegt.
Beide habe ich in die static Group gepackt. Beide sind present aber in den Readings vom PsnceDaemon sind trotzdem beide absent:
Internals:
ADDRESS deamon
DEF deamon deamon
FUUID 5fe85f4e-f33f-fe74-270d-a9e899ede42a0dfb
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE deamon
NAME PREDeamon
NOTIFYDEV global
NR 85
NTFY_ORDER 50-PREDeamon
STATE active
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 17
FW_ID 91
LASTACCESS 1609065949
NAME WEB_10.3.3.30_52534
NR 153
PEER 10.3.3.30
PORT 52534
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2020-12-27 11:45:29 state Connected
READINGS:
2020-12-27 11:40:58 model deamon
2020-12-27 11:45:36 pGrp_default ab:0 pres:0
2020-12-27 11:45:36 pGrp_dynamic ab:0 pres:0
2020-12-27 11:45:36 pGrp_static ab:2 pres:0
2020-12-27 11:45:36 pr_prfunct present
2020-12-27 11:45:36 pr_prping present
2020-12-27 11:45:36 state active
helper:
curState init
maybe 0
cnt:
maybe 0
state 0
th 0
evnt:
interval:
absent 30
init 30
present 30
prGroups:
dynamic
static
Attributes:
intervalNormal 30
Wäre es auch nicht "schöner" wenn die Groupreadings getrennt nach absence und presence wären?
=> Nur so ein Vorschlag... ;)
Ansonsten wünsche ich mir noch wie ein paar andere Mitleser lan-bluetooth für meine gtags :)
VG Sebastian
thx @Benni
Kurze antwort auf einen Teil der Fragen:
A) es gibt einen bug beim Attribut um die Zeit einzustellen. Daher 30sec. Morgen update
B) die attribute für event werden im nächsten update global vergügbar sein
C) löschen des deamons habe ich noch nicht probiert. Möglich, dass es nicht funktioniert. Es muss in jedem fall die letzte presenz entity sein
D) bt Anwendungen werde ich mir ansehen. Wird etwas mehr Aufwand da ich dies komplett nicht nutze.
E) die zähler der Gruppen werde ich prüfen.
Den rest lese ich noch
doch noch ein update:
dreher bei der Statistic present/absent behoben
Das Format für function und shellscript ist wegen möglicher und notwendiger hochkomman nicht ganz einfach. Daher nutze ich die enkapsulierung in eigene Trennzeichen - 2er kette. #><commando><#>suchstring<#
somit im Beispiel weiter oben
defmod presenceSynologySMB PRESENCE function #>{CheckPresenceSMB(\"192.168.0.152\", \"WORKGROUP\")}<#>30<#
Selbiges für Shellfunction
defmod prScript PRESENCE shellscript #>ping -c 1 -w 1 192.168.178.1 2>&1<#>(ttl|TTL)=\d+<#
Das Modul ist noch nicht fertig - klar, oder? Testergebnisse gerne einbringen - hilft sehr
Du hattest ja gefragt, ob presence in Modulen benutzt wird. Roommate Kannur Anwesenheitserkennung mit einem presence device verknüpft werden.
Hallo,
habe gerade die letzte Version eingespielt und neu gestartet.
Nun kommt der Deamon anscheinend mit den 50+ pings gut zurecht.
Auch die Anzeige vom pGrp_default passt nun.
Die Aufrufe von function/shellscript habe ich so kopiert, wie Du es machst.
Das klappt auch.
Darauf wäre im Leben nicht gekommen.
Vielen Dank!
Wenn mir Fehler auffallen, melde ich mich gerne.
Auch beim Bluetooth melde ich mich gerne als Tester.
Bzgl. Löschen des Deamon-Devices: das scheint ein Missverständnis zu sein.
Nach Deiner ersten Antwort dachte ich, ich muss es löschen. Da kam dann die Fehlermeldung.
Aber die dürfte ja richtig sein, weil es ja noch benutzt wird.
lg, Gerhard
Im Post:
a) Umstellungen
b) generelle Infos / Performance / Risk
a) Umstellungen
- reading maxScanTime renamed deamonMaxScanTime
reading skipDeamonCnt renamed deamonSkipCnt
Grund: Die "Deamon Internen" readings gehen unsortiert in den Status-readings unter. Daher muss der Reading name mit einem einheitlichen Wort beginnen
- Function/Shellscript delimiter
Die Spezifikation des "commands cmd" und des "scan" strings sind nicht ganz so einfach zu parsen. In beiden könnten beliebige Zeichen vorkommen. in der getrigen Version hatte ich daher einen mehr-Zeiche-String als delimiter vorgesehen. Der ist allerdings noch hässlich. Ich stelle das um auf
" cmd:<cmd> scan:<scan>"
Das ist schon einmal schöner. Der Parser prüft auf
$def =~ /[ \t]+cmd:(.*?)[ \t]+scan:(.*)[ \t]*$/s
- spaces am Ende den Commands oder Scan werden ignoriert
- beliebige Sonderzeichen sollten kein Problem sein
- "scan" ist ein regex
Das Beispiel von gestern muss also geändert werden
defmod presenceSynologySMB PRESENCE function cmd:{CheckPresenceSMB(\"192.168.0.152\", \"WORKGROUP\")} scan:30
b) generelle Infos / Performance / Risk
- Klar sollte mittlerweile der Kern des neuen Presence sein: Der Deamon.
ALLE Auswertungen werden vom Deamon erledigt. Daher werden ALLE timings in das Deamon Raster gezwungen. Es wird IMMER aufgerundet. Ist der deamon auf 30s eingestellt und eine Entity soll alle 35s geprüft werden wird bei "Itteration 0" gescannt. Bei "Itt 1" (30s) ist die Zeit noch nicht abgelaufen, entity wird nicht geprüft. Bei Itt2 ist dann entity wieder dran, bei Itt 3 nicht
- Deamon präzision
der Deamon wird alle 30s +x ausgeführt. Das X kommt vom Delay des FHEM Prozesses und kann nicht umgangen werden (single-process). Der Delay wird explizit für die nächste Ausführung nicht ausgeglichen. Will sagen stellt man 60s itteration ein und startet um 11:00:00 ist zu erwarten, dass nach einem Tag der Test nicht um 11:00:00 sondern bspw um 11:00:05 stattfindet. Die Größe des Delays hängt von den aktiven Modulen ab.
- Entity scan default
der Entity Scan default wird auf 1 gesetzt. Damit wird die entity mit jedem Aufruf des Deamon gescannt. Halte ich für sinnvoller
- Es wird immer nur EIN scan des deamon durchgeführt.
Sollte der Scan (sub-prozess) noch am Laufen sein, wenn der Deamon Timer abläuft wird der Scan ausgesetzt und erst nach dem nächsten Timerablauf wieder geprüft.
Der Anwender kann dies anhand der Readings deamonSkipCnt (wie oft wurde ein Scan ausgesetzt) prüfen.
Mit "attr PsnceDeamon intervalNormal 1" kann man die ScanSpeed hochsetzen und wird wohl denSkip-counter zählen sehen. Auf Dauer ist die Einstellung nicht zu empfehlen!!!!
- Scan duration
Pings werden je nach OS unterschiedlich angesteuert. Genereller Ansatz ist, die Zeit zu minimieren. Es wird daher auf EINE Antwort gewartet, einmal probiert und max 1s gewartet. Daraus folgt:
- Sind entites nicht erreichbar braucht der Ping 1s. Sind enties erreichbar geht es deutlich schneller
=> die Scandauer ist also dynamisch.
Die Ausführungdauer von function und shellscript liegt komplett in der Verantwortung des Anwenders. Es muss klar sein, dass hier alles blockiert werden kann.
Blocking ist per default auf max 60s eingestellt. Könnte man noch einstellbar machen. Worst case ist also, dass 60 pings von nicht erreichbaren Devices zu einem Timeout führen.
=> Der Deamon schützt das Gesamtsystem, aber auch hier ist die Performace endlich. Allerdingswäre bei der alten Implementierung 60 Prozesse an Laufen, was fatal wäre und auch von Blocking unterdrückt würde
- nicht startende Pings
in einer der Versionen hatte ich den Abbruch des Pings nicht auf 1s begrenzt - somit war dieser 10s. Möglich, dass dies zun Abbruch des Scans wegen Zeitüberschreitung geführt hat.
- deamonMaxScanTime
das ist ein zentrales reading. Ist diese Zeit länger also das Interval kommt es gelegentlich zu skip (siehe counter).
ROOMMATE kannte ich nicht, habe einmal reingesehen. Das nutzt eigentlich "RESIDENTS".
Sollte kein Problem sein, da hier das Reading "state" nur auch "absent"/"present" geprüft wird. Das ändert sich nicht und ich sehe keine Probleme.
Ich hoffe allerdings, hier kennt sich jemand aus - auch in der Anwendung. HMan braucht RESIDENT/GUEST/PET/ROOMMATE - 4 Module es zum Laufen zu bekommen.
Performance spielt in FHEM sicher keine Rolle nach dem ersten Blick auf den Code. Das Reading "state" wird sage und schreibe 3 mal per Funktion angefragt um es auf den Inhalt zu prüfen.
Prima allerding die namensgebung "lastArrival" und "lastDeparture" werde ich wohl auch übernehmen - das ist deutlich besser als mein Vorschlag
Für die Anwendung der Bewohner-Anwesenheitserkennung reicht eigentlich die Anwendung von RESIDENTS und ROOMMATE, die anderen beiden (GUEST/PET) sollten optional sein. Die einzelnen Bewohner (ROOMMATES) werden über eine übergeordnete Bewohner-Instanz (RESIDENTS) gebündelt wird (wobei auch das m.E. optional sein dürfte).
Man kann für die einzelnen ROOMMATES ein oder mehrere PRESENCE-Devices, bzw. beliebige Devices, die einen Anwesenheitsstatus zurückliefern, angeben (Attribut rr_presenceDevice). Über die wird der Anwesenhenheitsstatus dann automatisiert gesetzt (ich mache das bei mir aber selbst über entsprechende notify)
Es lässt sich im Attribut auch zusätzlich explizit das zu verwendende Reading des Presence-Device angeben.
Zulässige Werte für den zurückzuliefernden Presence-Status sind dabei (case insensitiv)
Für Abwesend: 0|false|absent|disappeared|unavailable|unreachable|disconnected
Für Anwesend: 1|true|present|appeared|available|reachable|connected
Beim Presence-Verhalten, werden sich GUEST und PET schätzungsweise gleich/ähnlich wie ROOMMATE verhalten. Allerdings verwende ich diese beiden derzeit nicht.
TL;DR: Die Änderungen sollten kein Problem in Verbindung mit RESIDENTS & Co. bereiten. Anpassungen wären, wenn überhaupt erforderlich, nur minimal.
gb#
@Benni
ich sehe auch keine Probleme - indbesondere bei der "state" implementierung. "presence" hat könnte und kann auch "maybe" enthalten - was ich bei state abgeschaltet habe.
Um den Sinn von Residence wirklich zu verstehen, welche features ich bekommen und warum diese nicht gleich in Presenz zu implementieren wären ist mir nicht klar.
Residence bezieht sich auf Personen und es sind Gruppen vorgegeben.
In Presence habe ich ein frei definierbares grouping vorgesehen (kostet ein einziges Attribut) und man kann beliebig groupieren und demnach änderungen in Gruppen erkennen indem man die Summen auswertet. Man könnte es noch auf die Namen erweitern und einen last-change angeben.
Aber RESDENCE bearbeite ich nicht.
News zu Bluetooth: ich habe meine Himbeere etwas untersucht
- bluetooth local kann ich einbauen fast wie es war. Man kann das schon jetzt über shellscript (logisch)
Mein test:
defmod prBTscan PRESENCE shellscript cmd:hcitool -i hci0 name 74:EB:80:91:59:45 scan:Galaxy
geht man von einem OS aus, welches sich nicht im laufenden Betrieb verändert, also BT installiert oder verändert wird, kann man den Namen des HCI device einmal (und nicht immer) suchen. Rückgabewert ist der Name -welcher auf nicht-blank untersucht wird.
Somit ist BTlocal verfügbar und funktioniert auf meiner Himbeere
defmod prBTgalaxy PRESENCE bluetooth 74:EB:80:91:59:45
Anhang vergessen.
LAN-BT ist nicht implementiert. braucht das auch jemand - wirklich? oder ist dies das eigentliche BT-scan?
Zitat von: martinp876 am 28 Dezember 2020, 11:45:55
Anhang vergessen.
LAN-BT ist nicht implementiert. braucht das auch jemand - wirklich? oder ist dies das eigentliche BT-scan?
Hallo Martin,
ich nutze das für ,,auf welcher Etage befindet sich ein Device" und hatte auch nur ,,LAN-BT" bis heute aus dem PRESENCE-Modul genutzt.
Bin bis jetzt zufrieden damit, verfolge aber gespannt den aktuell thread hier.
Danke und Gruß...
Zitat von: martinp876 am 28 Dezember 2020, 11:45:55
LAN-BT ist nicht implementiert. braucht das auch jemand - wirklich? oder ist dies das eigentliche BT-scan?
Ja haben mehrere - inklusive mir - hier gepostet. Lan-Bluetooth arbeitet mit presenced und collectord zusammen
und dient dem auffinden von BLE-Geräten wie den weit verbreiteten gtags.
Ist halt praktisch wenn fhem zB. im Container läuft und man keinen Bluetooth-Stick für local-bloutooth anschließen kann/will.
VG Sebastian
VG Sebastian
Zitat von: martinp876 am 28 Dezember 2020, 11:45:55
Anhang vergessen.
LAN-BT ist nicht implementiert. braucht das auch jemand - wirklich? oder ist dies das eigentliche BT-scan?
Mit der angehängten Version kommt für dieses PRESENCE Gerät
Internals:
DEF function cmd:{checkAllFritzMACpresent('B8:F1:2A:31:A0:55')} scan:30
FUUID 5fe9c90e-f33f-fe74-3f0e-ee36eeacfe933dbf
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE function
NAME sebastian_iphone.pre
NOTIFYDEV global
NR 88
NTFY_ORDER 50-sebastian_iphone.pre
STATE absent
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 17
FW_ID 151
LASTACCESS 1609159087
NAME WEB_10.3.3.31_52931
NR 150
PEER 10.3.3.31
PORT 52931
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2020-12-28 13:35:03 state Connected
READINGS:
2020-12-28 13:31:40 lastDeparture 2020-12-28 13:31:40
2020-12-28 13:31:00 model function
2020-12-28 13:37:40 presence absent
2020-12-28 13:37:40 state absent
helper:
curState absent
maybe 0
nextScan 1609159090.65303
cnt:
exec 13
maybe 0
state 0
th 0
interval:
absent 1
init 30
present 1
os:
Cmd {checkAllFritzMACpresent('B8:F1:2A:31:A0:55')}
search 30
timestamp:
absent 2020-12-28 13:31:40
Attributes:
event-on-change-reading .*
intervalNormal 1
intervalPresent 1
prGroup dynamic
verbose 5
OK
folgende Meldung im Log:
2020.12.28 13:36:40.681 5: PRESENCE (sebastian_iphone.pre) - ping command "{checkAllFritzMACpresent('B8:F1:2A:31:A0:55')}" returned with output:#> absent
VG Sebastian
Verbose 5 muss ja auch nicht sein, oder? 😉
Zitat von: Frank_Huber am 28 Dezember 2020, 13:58:17
Verbose 5 muss ja auch nicht sein, oder? 😉
Sonst steht halt nix im Log... :P
Bei function kannst du das kommando auch in der eingabezeile abschicken und die antwort prüfen.
Da ich dein modul nicht nutze kann ich auch nicht prüfen ob das korrekte zurück kommt
Hallo,
habe gerade den neuen Code eingespielt und die Definitionen wieder angepasst.
function cmd:{CheckPresenceSMB(\"192.168.0.109\", \"workgroup\")} scan:1
Leider bekomme ich folgende Fehlermeldung bei "verbose 5" und das Device ist immer "present".
2020.12.28 19:23:27.334 5: PRESENCE (presenceDNS323SMB) - ping command "{CheckPresenceSMB(\"192.168.0.109\", \"workgroup\")}" returned with output:#> present
########Can't find string terminator '"' anywhere before EOF at (eval 65688) line 1.
Vielleicht habe ich etwas übersehen?
lg, Gerhard
Edit:
Wenn ich den String direkt in der eingabezeile eingebe, kommt auch der Fehler. Wenn ich die "\"" durch ein einfaches ersetze, dann klappt es.
wenn du es ohne \ eingibst kommt ein anderer Fehler.
"Funktion" führt ein FHEM Kommando aus - alltäglich also. So wie du es an vielen andere Stellen auch eingeben kannst. PRESENZ macht erstmal nix damit.
=> du kannst das Kommando schlicht in die Kommandizeile pasten und es MUSS funktionieren.
In deinem Fall ganz einfach, da keine Variablen verwendet werden (das wäre auch schwierig und ist nicht unterstützt)
die {} braucht man (wie allgemein an diversen stellen zumindest indirekt beschrieben) um beliebige Subroutinen beliebiger Module aufzurufen.
Du setzt also voraus, dass eine Funktion "CheckPresenceSMB" in deiner FHEM installation zu Verfügung steht - was offensichtlich nicht der Fall ist.
Dazu 3 Anmerkungen
1) teste indem zu in die Kommandozeile pastest und abschickst
{CheckPresenceSMB("192.168.0.109","workgroup")}
{gettimeofday()}
{ReadingsVal("global","state","warnix")}
du bekommst einen string zurück welcher geparst wird
2) CheckPresenceSMB
kenne ich nicht - habe es auch nicht im "alten" Presence gefunden. Keine Ahnung, wo die Funktion einst war und was sie machen sollte
3) Nutzung von Funktionen
FHEM ist skript-basierend - alles ist offen. Du kannst jede Funktion jedes Moduls nutzen. Sinnvoll ist das nicht. Ich nehme mir das Recht heraus, Subroutinen meiner Module nach meinem Gusto ungefragt zu ändern. Das gleiche gilt für die Daten. Alle öffentlichen Funktionen und Daten muss ich hingegen beibehalten oder nur vorsichtig ändern. Öffentlich sind alle Attribute und Readings, auch Internals. Nicht hingegen Helper Variablen und Daten. Öffentliche Funktionen stelle ich eigentlich keine zu verfügung - nur was ein get oder set bereit stellt.
=> Wer auch immer die Funktion geschrieben hat muss dir sagen, wo sie nun hin ist.
PS:
Habe gesucht: auch checkAllFritzMACpresent kann ich in den FHEM files sowie den alten Code nicht finden.
Es wäre auch eine Unart, die Subroutine nicht mit dem Modulnamen zu beginnen.
Hattet ihr Subs in eigenen Module definiert? myUtils o.ä.?
Hallo Martin,
Wenn ich die Funktion in der Eingabezeile eingebe, dann klappt es:
function cmd:{CheckPresenceSMB("192.168.0.109", "workgroup")} scan:1
Und wenn ich die Zeile in der Definition ohne "\" eingebe, klappt es.
CheckPresenceSMB ist einfach eine perl-Funktion von mir, die "1" zurückliefert, wenn der Server über SMB erreichbar ist und "0" wenn nicht.
Das klappt auch so.
Ich denke, dass war in Deinem Mail von 08:04:19 einfach ein Copy&Paste-Fehler.
Der richtige Aufruf lautet also ohne "\".
Damit funktioniert es auch - kein Problem mehr.
Super, vielen Dank!
lg, Gerhard
Zitat von: martinp876 am 28 Dezember 2020, 19:29:09
Bei function kannst du das kommando auch in der eingabezeile abschicken und die antwort prüfen.
Da ich dein modul nicht nutze kann ich auch nicht prüfen ob das korrekte zurück kommt
Wenn ich die sub
{checkAllFritzMACpresent("B8:F1:2A:31:A0:55")}in die Adresszeile eingebe kommt korrekterweise eine 1 (weil present) zurück :o
- Das alte PRESENCE liefert present. Das neue absent mit obiger Fehlermeldung im Log.
- Die Fehlermeldung passt ja auch nicht zum MODE function
Die sub {checkAllFritzMACpresent(MAC)} gibts im Wiki und ist auch schon was älter aber bewährt:
sub checkAllFritzMACpresent($) {
# Benötigt: nur die zu suchende MAC ($MAC),
# Es werden alle Instanzen vom Type FRITZBOX abgefragt
#
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($MAC) = @_;
# Wird in keiner Instanz die MAC Adresse gefunden bleibt der Status 0
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my @FBS = devspec2array("TYPE=FRITZBOX");
foreach( @FBS ) {
my $StatusFritz = ReadingsVal($_, $MAC, "weg");
if ($StatusFritz eq "weg") {
}
elsif ($StatusFritz eq "inactive") {
}
else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät am Netzwerk angemeldet.
$Status = 1;
}
}
return $Status
}VG Sebatsian
Das ist kein Fehler.
Du fragst nach 30 ab, es kommt 1 zurück, also absent.
Pässe Deine config an auf scan 1 dann sollte es gehen.
Zitat von: Frank_Huber am 28 Dezember 2020, 21:40:49
Das ist kein Fehler.
Du fragst nach 30 ab, es kommt 1 zurück, also absent.
Pässe Deine config an auf scan 1 dann sollte es gehen.
Zitat2er kette. #><commando><#>suchstring<#
Danke, jetzt hab ich es kapiert ;)
der Morgen Update - nach den Infos von Gestern
- 1) function
die Prüfung auf "{}" entfällt. Das gleicht es etwas an sonstige Kommandos an und erlaubt auch ein
mydevice get status
und sonstige Kommandos. Function liegt immer in der Verantwortung des Anwenders - 2) Variablen in Kommandos
$NAME und $ADDRESS werden als Variablen in den Kommandos unterstützt und gegen deren Wert ersetzt - 3) die angesprochene Subroutine
hatte ich also oneliner erstellt
defmod prfunct PRESENCE function cmd:{scalar(grep !/inactive/,devspec2array("TYPE=FRITZBOX:FILTER=mac_3C_A9_F4_A3_16_80=..*"))} scan:1
macht das gleiche. Nun, fast. Es wird die Anzahl der gefundenen Devices rückgemeldet - aber das ist voraussichtlich nur eine Fritzbox - oder eben keine
Allerdings meine ich, dass die Implementierung der FRITZBOX nicht passt. Ich habe hier eine eigenen Version - welche nicht komplett ist. Die offizielle Version ist für mich wieder einmal am Ziel vorbei.
- 4) lan-bluetooth
hatte ich befürchtet. das scheint das komplizierteste - ich werden es prüfen und ggf einbauen
Es besteht also Hoffnung
Im Update die Version ohne Prüfung der {} und mit unterstützung von $NAME/$ADDRESS. ADDRESS ist bei Function noch nicht vorhanden...
Hallo,
habe nun die letzte Version eingespielt.
An der Konfiguration habe ich nix geändert.
Es gibt
Der Deamon ändert keine Werte mehr, dafür kommt im log wieder:
PRESENCE (PsnceDeamon) - skip scan due to running job
Es gibt 50+ Devices mit "lan-ping" und den Werten:
intervalNormal 30
intervalPresent 30
Im Deamon gibt es die folgenden Readings:
deamonMaxScanTime 41
deamonSkipCnt 1
sowie das Attribut:
intervalNormal 60
Das hatte ich gestern selbst gesetzt, weil ja die MaxScanTime 41 ist.
Stimmt das so mit den Einstellungen?
Warum beendet der Deamon das Scannen dann nicht?
Danke im Voraus
lg, Gerhard
Updates
- 1) Namenskorrektur:
Deamon ist natürlich falsch - habe ich in Daemon geändert - auf allen Ebenen. Achtung beim Einspielen - ich haben keinen Konverter eingebaut (wir sind in der Speilversion) - 2) lan-bluetooth
habe ich eingebaut und getestet. Zumindest einige Fälle. Ich habe nur einen presenced in Betrieb und getestet.
Ich bin aktuell nicht sicher, alle restart und stop events korrekt zu handeln. Testen sollte man schon können. Auch den collector-daemon ist nicht getestet. - 3) bugfix
disable wurde nicht immer korrekt ausgewertet
[li]4) Gerhards Kommentar
ist mir unklar, warum es nicht läuft. geskippt wird, wenn der Daemon noch einen Eintrag hat und "glaubt" ein Blocking Prozess sein noch aktiv. Unschön, wenn ich übersehen habe, den Eintrag in einem fall zu löschen.
[/li][/list]
get PsnceDaemon childInfozeigt alle Kinder-Prozesse. Wird hier keiner angezeigt läuft auch keiner.
Mit
set PsnceDaemon killChilds
kann man den Prozesse schlachten, dann sollte es wieder anlaufen
Grundsätzlich sollte blocking einen default timeout von 60s haben, so die doku.
=> sollte es zu weiterenHängern kommen bitte um Info damit ich es prüfenund automatisch behandeln kann.
[/li]
- 5) lan-bluetooth verhalten
Im Gegensatz zu den übrigen Scans ist lan-bluetooth deutlich schonender eingebaut. Der Daemon läuft im Hintergrund - es wird über socket kommuniziert. So etwas ist zwar aufwändiger aber doch performanter als das blocking. Will sagen eigentlich sollte man auch die Pings über einen externen Prozess laufen lassen. Das ist deutlich performanter, da schon erst einmal der Prozess viel kleiner ist. Das zu implementieren ist aber erst einmal in initialaufwand. Konzeptionell würde ich dann dennoch in FHEM einen Deamon vorsehen und alle Devices auf einmal abfragen. Macht den externen Prozess etwas aufwändiger, verringert die IPC (Sockets)
also: schon besser, es gibt Luft nach oben.
Erweiterungen: Bislang scheinen alle mit den Möglichkeiten und Readings zufrieden zu sein. Es gibt keine Wünsche.
Hallo,
Super, vielen Dank.
Das ,, get PsnceDaemon childInfo" liefert einen Dialog, in dem steht nur ,,blockingcalls:" - sonst nichts.
Auch das ,,killChilds" ändert nichts daran
Aber zuerst spiele ich mal die neue Version ein.
Vielleicht ist trotz Neustart was hängen geblieben.
Das mit lan-bluetooth werde ich auch gleich mal testen.
Lg, Gerhard
Zitat von: martinp876 am 30 Dezember 2020, 11:39:05
Updates
- 1) Namenskorrektur:
Deamon ist natürlich falsch - habe ich in Daemon geändert - auf allen Ebenen. Achtung beim Einspielen - ich haben keinen Konverter eingebaut (wir sind in der Speilversion) - 2) lan-bluetooth
habe ich eingebaut und getestet. Zumindest einige Fälle. Ich habe nur einen presenced in Betrieb und getestet.
Ich bin aktuell nicht sicher, alle restart und stop events korrekt zu handeln. Testen sollte man schon können. Auch den collector-daemon ist nicht getestet. - 3) bugfix
disable wurde nicht immer korrekt ausgewertet
[li]4) Gerhards Kommentar
ist mir unklar, warum es nicht läuft. geskippt wird, wenn der Daemon noch einen Eintrag hat und "glaubt" ein Blocking Prozess sein noch aktiv. Unschön, wenn ich übersehen habe, den Eintrag in einem fall zu löschen.
[/li][/list]get PsnceDaemon childInfo
zeigt alle Kinder-Prozesse. Wird hier keiner angezeigt läuft auch keiner.
Mit
set PsnceDaemon killChilds
kann man den Prozesse schlachten, dann sollte es wieder anlaufen
Grundsätzlich sollte blocking einen default timeout von 60s haben, so die doku.
=> sollte es zu weiterenHängern kommen bitte um Info damit ich es prüfenund automatisch behandeln kann.
[/li]
- 5) lan-bluetooth verhalten
Im Gegensatz zu den übrigen Scans ist lan-bluetooth deutlich schonender eingebaut. Der Daemon läuft im Hintergrund - es wird über socket kommuniziert. So etwas ist zwar aufwändiger aber doch performanter als das blocking. Will sagen eigentlich sollte man auch die Pings über einen externen Prozess laufen lassen. Das ist deutlich performanter, da schon erst einmal der Prozess viel kleiner ist. Das zu implementieren ist aber erst einmal in initialaufwand. Konzeptionell würde ich dann dennoch in FHEM einen Deamon vorsehen und alle Devices auf einmal abfragen. Macht den externen Prozess etwas aufwändiger, verringert die IPC (Sockets)
also: schon besser, es gibt Luft nach oben.
Erweiterungen: Bislang scheinen alle mit den Möglichkeiten und Readings zufrieden zu sein. Es gibt keine Wünsche.
Vielen Dank für die lan-bluetooth Integration! :)
Ich hab die neue Version eingespielt. Presence springt sekündlich von present auf absent:
Present:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
CFGFN
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333 scan:1
DeviceName 10.3.3.9:5333
FD 19
FUUID 5fec5c6b-f33f-fe74-4b0d-da59b4fcfe4569d2
MODE lan-bluetooth
NAME sebastian_gtag.pre
NOTIFYDEV global
NR 133
NTFY_ORDER 50-sebastian_gtag.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 21
FW_ID 129
LASTACCESS 1609326154
NAME WEB_10.3.3.31_63221
NR 347
PEER 10.3.3.31
PORT 63221
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2020-12-30 11:57:34 state Connected
READINGS:
2020-12-30 12:02:23 ArrivalCnt 28
2020-12-30 12:02:25 battery_level 19
2020-12-30 12:02:25 battery_level_age 4
2020-12-30 12:02:23 command_accepted yes
2020-12-30 12:02:25 daemon lepresenced V0.93dev20
2020-12-30 12:02:25 device_name device_name=Gigaset G-tag;rssi=-59;battery_level=19;battery_level_age=4;model=lan-lepresenced
2020-12-30 12:02:23 lastArrival 2020-12-30 12:02:23
2020-12-30 12:02:22 lastDeparture 2020-12-30 12:02:22
2020-12-30 12:02:25 model lan-lepresenced
2020-12-30 12:02:25 presence present
2020-12-30 12:02:25 room daemon=lepresenced V0.93dev20
2020-12-30 12:02:25 rssi -59
2020-12-30 12:02:25 state present
helper:
DISABLED 1
curState present
maybe 0
nextScan 0
cnt:
exec 178
maybe 0
state 28
th 0
interval:
absent 1
init 30
present 1
timestamp:
absent 2020-12-30 12:02:22
present 2020-12-30 12:02:23
Attributes:
disable 1
event-on-change-reading .*
icon gtag
intervalNormal 30
intervalPresent 30
verbose 5Absent:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
CFGFN
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333 scan:1
DeviceName 10.3.3.9:5333
FD 19
FUUID 5fec5c6b-f33f-fe74-4b0d-da59b4fcfe4569d2
MODE lan-bluetooth
NAME sebastian_gtag.pre
NOTIFYDEV global
NR 133
NTFY_ORDER 50-sebastian_gtag.pre
PARTIAL
STATE absent
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 21
FW_ID 129
LASTACCESS 1609326348
NAME WEB_10.3.3.31_63221
NR 347
PEER 10.3.3.31
PORT 63221
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2020-12-30 11:57:34 state Connected
READINGS:
2020-12-30 12:05:42 ArrivalCnt 2
2020-12-30 12:05:44 battery_level 19
2020-12-30 12:05:44 battery_level_age 4
2020-12-30 12:05:45 command_accepted yes
2020-12-30 12:05:45 daemon lepresenced V0.93dev20
2020-12-30 12:05:44 device_name device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced
2020-12-30 12:05:42 lastArrival 2020-12-30 12:05:42
2020-12-30 12:05:45 lastDeparture 2020-12-30 12:05:45
2020-12-30 12:05:45 model lan-lepresenced
2020-12-30 12:05:45 presence absent
2020-12-30 12:05:44 room daemon=lepresenced V0.93dev20
2020-12-30 12:05:45 rssi unreachable
2020-12-30 12:05:45 state absent
helper:
DISABLED 1
curState absent
maybe 0
nextScan 0
cnt:
exec 13
maybe 0
state 2
th 0
interval:
absent 1
init 30
present 1
timestamp:
absent 2020-12-30 12:05:45
present 2020-12-30 12:05:42
Attributes:
disable 1
event-on-change-reading .*
icon gtag
intervalNormal 30
intervalPresent 30
verbose 5
Nach dem Wechsel von Disable 0/1 musste ich nochmal die DEF speichern um das Device wieder zum Leben
zu erwecken.
Im Log steht:
2020.12.30 12:05:46.241 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:47.244 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:48.248 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:49.251 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:50.255 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:51.007 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:52.011 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:53.016 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:54.020 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:55.023 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:56.026 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:57.030 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:58.034 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:05:59.038 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:00.043 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:01.051 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:02.050 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:03.056 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:04.060 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:05.063 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:06.067 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:07.071 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:08.076 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:09.081 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:10.085 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:11.091 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:12.094 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:13.098 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:14.101 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:15.110 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:16.113 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:17.116 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:18.119 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-57;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:19.124 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:20.128 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:21.133 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:22.147 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:23.150 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:24.155 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:25.153 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:26.153 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:27.156 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:28.159 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:29.163 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:30.168 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:31.177 5: PRESENCE (sebastian_gtag.pre) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:32.178 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:33.182 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:34.179 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:35.190 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:36.186 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:37.189 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:38.221 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:39.210 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:40.198 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:41.201 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:42.204 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:43.207 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:44.210 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:45.215 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:46.219 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:47.222 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:48.256 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:49.254 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:50.258 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
2020.12.30 12:06:51.262 5: PRESENCE (sebastian_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-58;battery_level=19;battery_level_age=4;model=lan-lepresenced;daemon=lepresenced V0.93dev20
- Ist meine DEF korrekt?
- FHEM läuft bei mir in einem Docker-Container und der lepresenced auf dem Docker-Host
VG Sebastian
ZitatErweiterungen: Bislang scheinen alle mit den Möglichkeiten und Readings zufrieden zu sein. Es gibt keine Wünsche.
Ich hatte noch den Vorschlag gemacht, die Group-Readings für ab und pres als einzelne Readings für ab und pres zu gestalten...
Ich lese ja schon eine Weile interessiert mit.
(daher "pinne" ich mich jetzt [endlich] mal an :) )
Evtl. habe ich auch mal Zeit das auf ein Testsystem zu spielen...
Auf meinem Hauptsystem würde ich es aber nur nutzen, wenn es "abgekoppelt" vom jetzigen PRESENCE wäre (also anderer Modulname) und auch über das fhem Update käme...
...sorry! ;)
Aber danke für die Mühen schon mal!
Gruß, Joachim
- killChild
mein fehler: ist korrigiert - nach Kill wird blocking nun definitiv gestartet.
Evtl baue ich noch einen Automatischen Check ein, der wirklich nach den Jobs sucht.
- @MADMax
ein paralleles Modul will ich nicht einführen. Das führt m.E. zum Chaos. Mich nervt es immer ungemein, wenn ich eine Auswahl von 2 oder mehr Modulen habe und mich in der Tiefe um die Unterschiede kümmern muss. Ich werde das Modul für mich erstellen und es jedem anderen zu Verfügung stellen. Sollte die Entscheidung getroffen werden, das aktuelle Modul zu ersetzen ist das ok. Allerdings hat FHEM hier keinen mir bekannten Prozess - also wird es wohl nix
Ersetzen kann ich es nicht, da ich nicht der Owner bin.
Wenn du es nicht nutzen willst trifft mich das nicht wirklich.
Das aktuelle Modul kann aus meiner Sicht genutzt werden für lan-bluetooth (gut)und Event(nicht mein Stil). Für andere Modies ist es m.E. wegen des Blocking nur für sehr wenige Devices nutzbar. Alles andere ist ein Tanz auf dem Vulkan. - lan-bluetooth
die Definition ist
defmod prBtTablet PRESENCE lan-bluetooth 48:88:CA:DD:67:88 127.0.0.1:5111
scan: wird nur gebrauche, wenn ich den scan-string nicht kenne - also bei function und shellscript.
In der aktuellen Version sollte das Timer auf 30s für lan-bt stehen. 1s ist es für alle anderen unddamit der Timer des Daemon
- lan-bluetooth funktion
nun, bei mir toggelt es nicht. Wenn ich BT am Smartphone einschalte ist es present. wenn ich ausschalte ist es off
lan-BT läuft nicht über den Daemon - der Timer läuft extern im "presenced". Es macht also keinen Sinn, dies künstlich dem daemon unterzuordnen
- Gruppen Zähler
sicher Geschmackssache, ob man eine komprimierte List oder doppelt so viele einzelne Readings haben will. Ich möchte es typisch komprimiert - was aber schlecht auszu werden ist. Bei Zählern reicht mir typisch, das sich etwas geändert hat. Bearbeite ich es automatisch (notify/alarming,...) reicht es typisch, zu wissen, dass sich die Gruppe verändert hat. Intersanter ist m.E. zu wissen, wer nun gekommen ist. Das könnte man in einem notify nutzen... ist aber schon recht speziell.
Ich überlege noch einmal...
- Disable bei lan-bt
dummer logikfehler meinerseits. Schlecht getestet obendrein
Vielen Dank fü rdas rege Testen und die Gedult
Zitat von: martinp876 am 30 Dezember 2020, 19:32:16
Sollte die Entscheidung getroffen werden, das aktuelle Modul zu ersetzen ist das ok. Allerdings hat FHEM hier keinen mir bekannten Prozess - also wird es wohl nix
Ersetzen kann ich es nicht, da ich nicht der Owner bin.
Hmm ... grundsätzlich würde ich es auch begrüßen, wenn die Änderungen in den "offiziellen" Zweig übernommen würden. Hast du schon mal versucht, diesbezüglich mit Markus Bloch, dem eigentlichen Modulautor in Kontakt zu treten? Vielleicht hätte er ja gar nichts dagegen, wenn ihm jemand Arbeit abnimmt ;)
gb#
Zitatlan-bluetooth
die Definition ist
defmod prBtTablet PRESENCE lan-bluetooth 48:88:CA:DD:67:88 127.0.0.1:5111
scan: wird nur gebrauche, wenn ich den scan-string nicht kenne - also bei function und shellscript.
In der aktuellen Version sollte das Timer auf 30s für lan-bt stehen. 1s ist es für alle anderen unddamit der Timer des Daemon
lan-bluetooth funktion
nun, bei mir toggelt es nicht. Wenn ich BT am Smartphone einschalte ist es present. wenn ich ausschalte ist es off
lan-BT läuft nicht über den Daemon - der Timer läuft extern im "presenced". Es macht also keinen Sinn, dies künstlich dem daemon unterzuordnen
Hab die aktuellste Version eingespielt:
- Ok, scan: jetzt final verstanden...
- Mit dem externen lepresenced toggelt es nach wie vor nahezu sekündlich.
- Vermutlich ist der externe Timer von lepresenced das "Problem". Wie macht das das alte PRESENCE?
- Ein gesetztes disable 1 wird beim Speichern der DEF immer noch ignoriert.
Ich scheine der einzige zu sein, der mit lepresenced und lan-bluetooth testet. Wäre ja schön, wenn
die anderen "Wünscher" es auch mal testen würden... ;)
VG Sebastian
Hallo,
das Testen ist nicht immer so einfach ;)
Man muss sich dazu Zeit nehmen ...
Habe aber nun die neue Version eingespielt.
1) lan-ping scheint zu funktionieren
2) lan-bluetooth klappt mit der Definition:
lan-bluetooth 7C:2F:80:99:XX:YY 127.0.0.1:5222
Allerdings liefert es diese Readings:
ArrivalCnt 1
command_accepted yes
daemon lepresenced V0.93dev21
device_name rooms='Vorzimmer';room='Vorzimmer';rssi_Vorzimmer='-80';device_name=Gigaset G-tag;rssi=-80;model=lan-lepresenced
lastArrival 2020-12-30 23:20:40
lastDeparture 2020-12-30 22:08:51
model lan-lepresenced
presence present
room daemon=lepresenced V0.93dev21
rooms Vorzimmer
rssi -80
rssi_Vorzimmer -80
state present
Da scheint das Parsen noch nicht ganz hinzuhauen.
3) das lepresenced erzeugt noch Batterie-Readings, die in den collectord und dann in das Presence-Device durchgereicht wurden.
Das klappt zumindest bei mir noch nicht.
lg, Gerhard
noch etwas:
alle meine Presence-Devices mit "function" haben nun die folgenden Attribute:
disable 1
intervalNormal 1
intervalPresent 1
Ich denke nicht, dass ich das war ;)
Hier das define:
function cmd:{CheckPresence("192.168.0.xxx", "38:53:9c:8e:xx:yy", "hci0")} scan:1
Wenn ich das Attribut disable lösche, bleibt der state trotzdem auf "disabled.
Das hatte schon mal funktioniert.
CheckPresence ist eine eigene Perl-Funktion.
lg, Gerhards
Moin Zusammen,
die Beobachtung von Gerhard kann ich bestätigen: Alle Function-DEFs haben intervalNormal 1 und intervalPresent 1 erhalten.
Ich habe dann vorhin noch lepresenced-0.93-1.deb vom 04.10.2020 eingespielt und siehe da: Kein toggeln mehr! :)
Internals:
ADDRESS 7C:2F:80:98:AC:0F
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 25
FUUID 5fec614d-f33f-fe74-fd31-9eeb6ab851b7850c
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE lan-bluetooth
NAME sebastian.gtag.pre
NOTIFYDEV global
NR 93
NTFY_ORDER 50-sebastian.gtag.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 16
FW_ID 16776
LASTACCESS 1609397702
NAME WEB_10.3.3.30_51573
NR 16840
PEER 10.3.3.30
PORT 51573
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2020-12-31 07:55:02 state Connected
READINGS:
2020-12-31 07:50:06 ArrivalCnt 1
2020-12-31 07:54:43 batteryPercent 17
2020-12-31 07:54:43 batteryPercentAge 0
2020-12-30 13:52:15 battery_level 17
2020-12-30 13:52:15 battery_level_age 0
2020-12-31 07:51:59 command_accepted yes
2020-12-31 07:54:43 daemon lepresenced V0.93
2020-12-31 07:54:43 device_name device_name=Gigaset G-tag;rssi=-69;batteryPercent=17;batteryPercentAge=0;model=lan-lepresenced
2020-12-31 07:50:06 lastArrival 2020-12-31 07:50:06
2020-12-30 20:54:30 lastDeparture 2020-12-30 20:54:30
2020-12-31 07:54:43 model lan-lepresenced
2020-12-31 07:54:43 presence present
2020-12-31 07:54:43 room daemon=lepresenced V0.93
2020-12-31 07:54:43 rssi -69
2020-12-31 07:54:43 state present
helper:
DISABLED 0
curState present
maybe 0
nextScan 1609397523.75877
cnt:
exec 11
maybe 0
state 1
th 0
interval:
absent 40
init 30
present 40
timestamp:
present 2020-12-31 07:50:06
Attributes:
intervalNormal 40
intervalPresent 40
Batterie-Readings werden ebenfalls aktualisiert.
@Gerhard: Hats du die neusten collectord und lepresenced debs installiert?
VG Sebastian
Beim Einstellen vom Attribut pGroup kommt die Meldung
ARRAY(0x55a242a4be98)
Guten Morgen,
Ich habe die Version lepresenced V0.93dev21 installiert.
Wusste nicht, dass es eine neue gibt.
Daher werde ich mal aktualisieren.
Danke für den Hinweis.
Stimmen bei Dir die Readings bzgl. Räume etc.?
Lg, Gerhard
Edit: sehe gerade in Deinem List, dass alles zu passen scheint.
Zitat von: gestein am 31 Dezember 2020, 09:23:36
Stimmen bei Dir die Readings bzgl. Räume etc.?
Lg, Gerhard
Edit: sehe gerade in Deinem List, dass alles zu passen scheint.
Da ich keinen collectord einsetze werden auch keine Räume ausgewertet.
Auf das Update bin ich durch deine Version V0.93dev21 aufmerksam geworden. Ich hatte ja vorher V0.93dev20
im Einsatz.
- um den Umgang mit der/einer offiziellen Verison kümmere ich später... mal sehen
- lepresenced toggelt es nach wie vor nahezu sekündlich
muss ich einmal ansehen. Ich habe es nur mit presenced getestet - ist es hier auch der Fall?
Grundsätzlich mache ich es wie da alte Modul (denke ich :) )
Du kannst einmal verbose 5 setzen und das Log hierzu posten
- Ein gesetztes disable 1 wird beim Speichern der DEF immer noch ignoriert.
verstehe ich noch nicht. Ich habe aber noch etwas korrigiert. Disable ist ein Attribut und wird faktisch nach DEF ausgeführt. Def Default von Def setzt enable!
- lan-bluetooth readings
presenced liefert bei mir meine addon daten, daher sehe ich das nicht. Nutzt du den collector?
Schalte auch einmal verbose 5 und schicke das Log von einer itteration
- intervalNormal 1
Ich denke nicht, dass ich das war
=> korrekt - das ist der Default.
- ARRAY(0x55a242a4be98)
gelöst in der aktuellen Version - Beschreibung
habe ich im File info.html angehängt. Das ist mein aktueller Stand
Hallo,
habe die Datei nun in allen Instanzen ausgetauscht. Bis jetzt keine Fehler festgestellt. Lass es jetzt einfach laufen und melde mich wieder.
Auf diesem Wege wünsche ich einen guten Rutsch
Danke für den Umbau und die ergänzten Readings......
Grüße
Hallo,
habe nun auch auf lepresenced 0.93 upgedatet - klappt, aber noch nicht ganz.
Die Felder werden immer noch nicht ganz richtig zugeordnet.
Aber: die Readings für die Batterien sind da ;)
ArrivalCnt 1 2020-12-31 15:40:03
batteryPercent 28 2020-12-31 12:55:33
batteryPercentAge 0 2020-12-31 12:55:33
command_accepted yes 2020-12-31 15:40:05
daemon lepresenced V0.93 2020-12-31 15:40:03
device_name rooms='Vorzimmer';room='Vorzimmer';rssi_Vorzimmer='-81';device_name=Gigaset G-tag;rssi=-81;model=lan-lepresenced 2020-12-31 15:40:03
lastArrival 2020-12-31 15:40:03 2020-12-31 15:40:03
lastDeparture 2020-12-30 22:08:51 2020-12-30 22:08:51
model lan-lepresenced 2020-12-31 15:40:03
presence present 2020-12-31 15:40:03
room daemon=lepresenced V0.93 2020-12-31 15:40:03
rooms Vorzimmer 2020-12-31 15:40:03
rssi -81 2020-12-31 15:40:03
rssi_Vorzimmer -81 2020-12-31 15:40:03
state present 2020-12-31 15:40:03
Aber es schaut schon mal gut aus.
Den Rest schaue ich mir morgen an.
Guten Rutsch aus 2020 in ein (hoffentlich) besseres 2021!
lg, Gerhard
Einmal verbose 5 logging damit ich den raw string sehen kann ist hilfreich
Zitat von: martinp876 am 31 Dezember 2020, 17:55:15
Einmal verbose 5 logging damit ich den raw string sehen kann ist hilfreich
2020.12.31 21:50:33.214 5: PRESENCE (christine_gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-68;batteryPercent=19;batteryPercentAge=1;model=lan-lepresenced;daemon=lepresenced V0.93Bei Gerhard mit collectord steht nur noch rooms='Vorzimmer';room='Vorzimmer' davor.
Für was ist denn das Attribut prGroupDisp condense verbose?
Guten Rutsch und
#VGS
danke für das Logging. Im Anhang nun ein update für die entsprechenden Readings
ZitatFür was ist denn das Attribut prGroupDisp condense verbose?
Readings für prGroup werden nach User-geschmack angepasst. Schon mein "commandref" hierzu angesehen? War im letzten Post
Hallo,
Habe die neue Version eingespielt - passt fast.
Die Readings sind richtig zugeordnet.
Nur eine Kleinigkeit passt noch nicht.
Manche Felder haben Hochkomma vorne und hinten.
room 'Vorzimmer'
rooms 'Vorzimmer,Zuhause'
rssi -76
rssi_Vorzimmer '-76'
rssi_Zuhause '-90'
Meine Devices mit "function" springen einfach nicht an - die sind immer disabled (auch wenn ich das Attribut lösche).
Werde die heute Abend mal weglöschen und neu anlegen.
Vielleicht passt es dann.
Danke auf alle Fälle!!
lg, Gerhard
Zitat von: martinp876 am 01 Januar 2021, 12:49:15
Schon mein "commandref" hierzu angesehen? War im letzten Post
Ja hab ich. Aber es erschließt sich nicht auf den ersten Blick...
Bei room ohne collectord steht noch was falsches drin:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 16
FUUID 5fec614d-f33f-fe74-fd31-9eeb6ab851b7850c
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE lan-bluetooth
NAME sebastian.gtag.pre
NOTIFYDEV global
NR 70
NTFY_ORDER 50-sebastian.gtag.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 13
FW_ID 1715
LASTACCESS 1609505155
NAME WEB_10.3.3.30_50757
NR 1715
PEER 10.3.3.30
PORT 50757
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-01 13:44:08 state Connected
READINGS:
2021-01-01 13:18:59 ArrivalCnt 2
2021-01-01 13:44:59 batteryPercent 19
2021-01-01 13:44:59 batteryPercentAge 5
2021-01-01 13:18:59 command_accepted yes
2021-01-01 13:44:59 daemon lepresenced V0.93
2021-01-01 13:44:59 device_name Gigaset G-tag
2021-01-01 13:18:59 lastArrival 2021-01-01 13:18:59
2021-01-01 11:53:59 lastDeparture 2021-01-01 11:53:59
2021-01-01 13:44:59 model lan-lepresenced
2021-01-01 13:44:59 presence present
2021-01-01 13:43:59 room daemon=lepresenced V0.93
2021-01-01 13:44:59 rssi -72
2021-01-01 13:44:59 state present
helper:
DISABLED 0
curState present
maybe 0
nextScan 1609495068.2461
cnt:
exec 171
maybe 0
state 2
th 0
disp:
condense 0
verbose 1
interval:
absent 60
init 30
present 60
timestamp:
absent 2021-01-01 11:53:59
present 2021-01-01 13:18:59
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK
event-on-change-reading .*
intervalNormal 60
intervalPresent 60
prGroup dynamic
prGroupDisp verbose
Das Reading room macht auch ohne collectord wenig Sinn.
EDIT: Das Reading ist noch aus der alten Version. Habs rausgelöscht.
Zitat von: gestein am 01 Januar 2021, 13:41:15
Manche Felder haben Hochkomma vorne und hinten.
room 'Vorzimmer'
rooms 'Vorzimmer,Zuhause'
rssi -76
rssi_Vorzimmer '-76'
rssi_Zuhause '-90'
Bei mir - ohne collectord - nicht. :o
Hab mit der neuesten Version folgendes festgestellt:
defmod christine_watch.pre PRESENCE function cmd:{checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9")} scan:1
Internals:
CFGFN
DEF function cmd:{checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9")} scan:1
FUUID 5fef3c5b-f33f-fe74-0bf8-4b8e5cd2bc79885c
MODE function
NAME christine_watch.pre
NOTIFYDEV global
NR 3318
NTFY_ORDER 50-christine_watch.pre
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 18
FW_ID 3263
LASTACCESS 1609514084
NAME WEB_10.3.3.30_50404
NR 3263
PEER 10.3.3.30
PORT 50404
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-01 16:10:33 state Connected
READINGS:
2021-01-01 16:14:42 ArrivalCnt 1
2021-01-01 16:14:42 lastArrival 2021-01-01 16:14:42
2021-01-01 16:14:35 model function
2021-01-01 16:14:42 presence present
2021-01-01 16:14:42 state present
helper:
DISABLED 0
curState present
maybe 0
nextScan 0
cnt:
exec 1
maybe 0
state 1
th 0
disp:
condense 1
verbose 0
interval:
absent 1
init 30
present 1
os:
Cmd {checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9")}
search 1
timestamp:
present 2021-01-01 16:14:42
Attributes:
intervalNormal 1
intervalPresent 1
funktioniert und wird present da das Reading im Fritzbox Device existiert.
defmod christine_watch.pre PRESENCE function cmd:checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9") scan:1
Internals:
CFGFN
DEF function cmd:checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9") scan:1
FUUID 5fef3bc6-f33f-fe74-841c-f753dba34b52016a
MODE function
NAME christine_watch.pre
NOTIFYDEV global
NR 3285
NTFY_ORDER 50-christine_watch.pre
STATE absent
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 18
FW_ID 3263
LASTACCESS 1609514042
NAME WEB_10.3.3.30_50404
NR 3263
PEER 10.3.3.30
PORT 50404
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-01 16:10:33 state Connected
READINGS:
2021-01-01 16:12:14 lastDeparture 2021-01-01 16:12:14
2021-01-01 16:12:06 model function
2021-01-01 16:13:07 presence absent
2021-01-01 16:13:07 state absent
helper:
DISABLED 0
curState absent
maybe 0
nextScan 1609513987.99707
cnt:
exec 2
maybe 0
state 0
th 0
disp:
condense 1
verbose 0
interval:
absent 1
init 30
present 1
os:
Cmd checkAllFritzMACpresent("CA:8C:AD:C8:F6:B9")
search 1
timestamp:
absent 2021-01-01 16:12:14
Attributes:
intervalNormal 1
intervalPresent 1
Funktioniert auch aber das Device bleibt ewig auf absent.
Ich dachte die {} kann man jetzt weglassen?
Die "alten" Function models funktionieren ja auch weiterhin OHNE {} :o
Internals:
DEF function cmd:checkAllFritzMACpresent("F0:78:07:14:4A:86") scan:1
FUUID 5fee37f9-f33f-fe74-53ef-6b44e0b6763369b4
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE function
NAME christine_iphone.pre
NOTIFYDEV global
NR 73
NTFY_ORDER 50-christine_iphone.pre
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 20
FW_ID 3342
LASTACCESS 1609514267
NAME WEB_10.3.3.30_50517
NR 3343
PEER 10.3.3.30
PORT 50517
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-01 16:16:21 state Connected
READINGS:
2021-01-01 13:44:16 ArrivalCnt 0
2021-01-01 10:58:58 lastArrival 2021-01-01 10:58:58
2021-01-01 10:57:48 model function
2021-01-01 16:17:36 presence present
2021-01-01 16:17:36 state present
helper:
DISABLED 0
curState present
maybe 0
nextScan 1609514315.87775
cnt:
exec 317
maybe 0
state 1
th 0
disp:
condense 1
verbose 0
interval:
absent 60
init 30
present 60
os:
Cmd checkAllFritzMACpresent("F0:78:07:14:4A:86")
search 1
timestamp:
present 2021-01-01 10:58:58
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK
event-on-change-reading .*
intervalNormal 60
intervalPresent 60
prGroup dynamic
#VGS
- Hochkommas in den "additional Readings" kann ich eliminieren - so kommen die Datn bis jetzt.
- prGroupDisp
nun, dann habe ich es nicht hinreichend beschrieben. Neuer Versuch im Anhang - function
{} wird benötigt, wenn man eine perl-funktion ausführt.
{} muss weggelassen werden wenn man eine FHEM Funktion ausführt.
Siehe u.a. "FHEM command types" im commandref
und weitere viele Beispiele dort.
Kurz:
alle Kommandos welce mit "?" angezeigt werden muss man ohne {} ausführen oder packt sie so ein
set lamp off
{fhem("set lamp off")}
Alles andere mit {}
Beispiele aus Commandref
attr store eventMap on:open off:closed
attr store eventMap /on-for-timer 10:open/off:closed/
set store open
The explicit variant of this attribute has the following syntax:
attr store eventMap { dev=>{'on'=>'open'}, usr=>{'open'=>'on'} }
attr store eventMap { dev=>{'^on(-for-timer)?(.*)'=>'open$2'}, usr=>{'^open(.*)'=>'on$1'}, fw=>{'^open(.*)'=>'open'} }
Zugriff auf eigenen Subroutinen nur mit {}
Ich habe das Parsen auf {} ausgeschaltet so dass du auch ein "get entity statusRequest" als Kommando absetzen kannst
Zitat von: martinp876 am 01 Januar 2021, 17:01:35
- Hochkommas in den "additional Readings" kann ich eliminieren - so kommen die Datn bis jetzt.
- prGroupDisp
nun, dann habe ich es nicht hinreichend beschrieben. Neuer Versuch im Anhang - function
{} wird benötigt, wenn man eine perl-funktion ausführt.
{} muss weggelassen werden wenn man eine FHEM Funktion ausführt.
Siehe u.a. "FHEM command types" im commandref
und weitere viele Beispiele dort.
Kurz:
alle Kommandos welce mit "?" angezeigt werden muss man ohne {} ausführen oder packt sie so ein
set lamp off
{fhem("set lamp off")}
Alles andere mit {}
Beispiele aus Commandref
attr store eventMap on:open off:closed
attr store eventMap /on-for-timer 10:open/off:closed/
set store open
The explicit variant of this attribute has the following syntax:
attr store eventMap { dev=>{'on'=>'open'}, usr=>{'open'=>'on'} }
attr store eventMap { dev=>{'^on(-for-timer)?(.*)'=>'open$2'}, usr=>{'^open(.*)'=>'on$1'}, fw=>{'^open(.*)'=>'open'} }
Zugriff auf eigenen Subroutinen nur mit {}
Ich habe das Parsen auf {} ausgeschaltet so dass du auch ein "get entity statusRequest" als Kommando absetzen kannst
Ja ich weiß das alles. Ging auch eher darum, dass die function entities ohne {} hinter cmd: einfach weiter den alten Zustand gemeldet haben anstatt einen Fehler.
Noch ein Vorschlag:
Die Readings lastArrival und lastDeparture ändern in lastAppearance und lastDisappearance.
Arrival und Departure sind doch eher Personenbezogen und hier gehts ja eigentlich um Geräte ;)
#VGS
Zitat von: binford6000 am 02 Januar 2021, 08:29:42
Noch ein Vorschlag:
Die Readings lastArrival und lastDeparture ändern in lastAppearance und lastDisappearance.
Arrival und Departure sind doch eher Personenbezogen und hier gehts ja eigentlich um Geräte ;)
da hat binford6000 schon recht, Arrival und Departure übersetzen sich in etwa eher personenbezogen als "Ankunft" und "Abfahrt". Ich würde aber lieber beim ursprünglichen "wording" bleiben und von lastPresent und lastAbsent (wg. mir auch lastPresence und lastAbsence) sprechen. Schließlich heißt das Modul ja (immer noch) "PRESENCE" und auch der state liefert "present" und "absent".
Letztendlich ist das aber eigentlich nur "Kosmetik"
gb#
ZitatLetztendlich ist das aber eigentlich nur "Kosmetik"
ja,... nun ja,... ich würde es nicht unterbewerten. Schlechte Begriffe sind einfach schlecht, irreführend und missverständlich.
Meine Kriterien sind a) Semantik b) Wiederverwendung gleicher Namen über Module hinweg (FHEM-übliche Begriffe) c) Änderung eingeführter Begriffe. d) nutzbarkeit
- Semantik
Present/Absent sowie presence/absence sind Zustände, keine Zeitpunkte
Arrival/appearence... sind klar definiert Zeitpunkte.
Somit ist lastArrival und lastAppearence möglich. lastPresent/lastPresence hingegen nicht - das wäre eine andere Zeit, nämlich das letzte mal gesehen. Auch schwieriger hier das maybe einzubeziehen...
- Wiederverwendung
Ich haben mich hier an RESIDENCE gehalten, was m.E. die identische Bedeutung hat. Das Modul ist auch "verwandt" und somit wäre es gut, die gleichen Begriffe zu nutzen. Daher die aktuellen Begriffe.
- Umstellung aktueller Nutzen
nun, das sollte aktuell noch einfach möglich sein, kein großes Problem
- Nutzbarkeit
war mich auch schon in den ersten Überlegungen von Apperence abgehalten hat ist die häßliche Länge des Begriffe "lastDisappearence". Die Abkürzung lastAppeare/lastDisappear ist schon viel besser - aus meiner Sicht. Das ist nun aber schwer Geschmackssache
Somit werden also die Begriffe überarbeitet
lastAppeare/lastDisappear (ich hoffe mit der Abkürzung kann man leben)
appearenceCnt (gleich lang wie disappear)
Presence/state : unverändert
Die Attribute sollten passen, auch wenn man bei thresholdAbsence dies nicht 100% aus dem Begriff ablesen lässt.
intervalNormal gefällt mir nicht, da "normal" immer nur ein Notnagel ist. "interval" oder "intervalAbsent" oder "intervalDefault" sind alternativen. Ich ändere es aber nicht.
Im Anhang die entsprechende Version.
Tip:
deletereading TYPE=PRESENCE .*räumt alle Readings auf.
Moin,
wünsche ein gesundes Neues Jahr.
Sodele, nach nun 4 Tagen und einem Umzug des FHEM auf ein neues Major Release von Ubuntu hier nun eine Auffälligkeit.
2021.01.03 08:35:59 1: PERL WARNING: Use of uninitialized value within %stateH in hash element at ./FHEM/73_PRESENCE.pm line 833.
2021.01.03 08:36:16 1: PERL WARNING: Argument "device_name='iPhone A'" isn't numeric in split at ./FHEM/73_PRESENCE.pm line 651.
2021.01.03 08:36:22 1: PERL WARNING: Argument "device_name='iPhone B'" isn't numeric in split at ./FHEM/73_PRESENCE.pm line 651.
2021.01.03 08:36:29 1: PERL WARNING: Argument "device_name='iPhone C'" isn't numeric in split at ./FHEM/73_PRESENCE.pm line 651.
2021.01.03 08:36:35 1: PERL WARNING: Argument "device_name='iPhone D'" isn't numeric in split at ./FHEM/73_PRESENCE.pm line 651.
Funktionieren tut es trotz der Perl Warnungen. Diese sollten aber eher nicht sein, oder? :o
So wie es aussieht geschieht dies nur nach neustart von FHEM.....
Grüße
Hier auch ein paar Perl-Warnungen beim Neustart:
2021.01.03 11:26:21.033 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 554, <$fh> line 1523.
2021.01.03 11:26:21.034 1: PERL WARNING: Argument "condense" isn't numeric in numeric ne (!=) at ./FHEM/73_PRESENCE.pm line 554, <$fh> line 1523.
2021.01.03 11:26:21.039 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/73_PRESENCE.pm line 554, <$fh> line 1531.
2021.01.03 11:26:21.040 1: PERL WARNING: Argument "verbose" isn't numeric in numeric ne (!=) at ./FHEM/73_PRESENCE.pm line 554, <$fh> line 1531.
#VGS
Mir ist noch was aufgefallen:
- Die beiden lan-bluetooth entities liefen problemlos
- Hab mich nur gewundert dass ein notify PREDaemon:.*pre:.absent {
fhem("set fhembot msg Abwesend: $EVTPART0")} nicht absence gemeldet hat - Die Readings im Daemon waren gar nicht vorhanden!
- Ich habe daraufhin die beiden gtags gelöscht und via RAW neu angelegt
- Jetzt sind zwar die Readings im Daemon da aber die beiden gtags auf error
Das steht dazu im Log:
2021.01.03 18:08:18.762 3: Opening christine_gtag.pre device 10.3.3.9:5333
2021.01.03 18:08:18.765 3: christine_gtag.pre device opened
2021.01.03 18:08:31.547 1: PERL WARNING: Use of uninitialized value within %stateH in hash element at ./FHEM/73_PRESENCE.pm line 833.
2021.01.03 18:08:31.548 3: eval: {PRESENCE_daemonScanReply('PREDaemon0#christine_gtag.pre|error')}
2021.01.03 18:09:28.979 3: Opening sebastian.gtag.pre device 10.3.3.9:5333
2021.01.03 18:09:28.983 3: sebastian.gtag.pre device opened
2021.01.03 18:11:58.781 5: PRESENCE (christine_gtag.pre) - starting local scanBei verbose 5 kommt nicht mehr...
Hier noch einer der beiden gtags:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
CFGFN
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 13
FUUID 5ff1fa48-f33f-fe74-d910-f61b8d2bcd7b5195
MODE lan-bluetooth
NAME sebastian.gtag.pre
NOTIFYDEV global
NR 4574
NTFY_ORDER 50-sebastian.gtag.pre
PARTIAL
STATE error
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 15
FW_ID 4764
LASTACCESS 1609694662
NAME WEB_10.3.3.31_59460
NR 4769
PEER 10.3.3.31
PORT 59460
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-03 18:24:18 state Connected
READINGS:
2021-01-03 18:09:28 model lan-bluetooth
2021-01-03 18:12:41 state error
helper:
DISABLED 0
curState init
maybe 0
nextScan 1609693769.08337
cnt:
exec 0
maybe 0
state 0
th 0
disp:
condense 1
verbose 0
interval:
absent 60
init 30
present 60
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK
event-on-change-reading .*
intervalNormal 60
intervalPresent 60
prGroup dynamic
thresholdAbsence 3
Ansonsten auch noch was kosmetisches:
In der cref steht bei lan-bluetooth die DEF für shellscript:
ZitatMode: lan-bluetooth
define <name> PRESENCE shellscript cmd:<address> scan:<ip-address>
Checks for a bluetooth device with the help of presenced or collectord...
VG Sebastian
Update:
Nach einem Neustart sind die gtags zwar kurz auf error aber dann present:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 16
FUUID 5ff1fa48-f33f-fe74-d910-f61b8d2bcd7b5195
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE lan-bluetooth
NAME sebastian.gtag.pre
NOTIFYDEV global
NR 75
NTFY_ORDER 50-sebastian.gtag.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 21
FW_ID 157
LASTACCESS 1609695300
NAME WEB_10.3.3.31_59558
NR 158
PEER 10.3.3.31
PORT 59558
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-03 18:31:25 state Connected
READINGS:
2021-01-03 18:27:51 appearCnt 1
2021-01-03 18:34:52 batteryPercent 17
2021-01-03 18:34:52 batteryPercentAge 16
2021-01-03 18:27:52 command_accepted yes
2021-01-03 18:34:52 daemon lepresenced V0.93
2021-01-03 18:34:52 device_name Gigaset G-tag
2021-01-03 18:27:51 lastAppear 2021-01-03 18:27:51
2021-01-03 18:34:52 maybeCnt 3
2021-01-03 18:34:52 model lan-lepresenced
2021-01-03 18:34:52 presence present
2021-01-03 18:34:52 rssi -68
2021-01-03 18:33:52 state present
2021-01-03 18:34:52 thresHldCnt 1
helper:
DISABLED 0
curState present
maybe 1
nextScan 1609694862.01776
cnt:
exec 9
maybe 3
state 1
th 1
disp:
condense 1
verbose 0
interval:
absent 60
init 30
present 60
timestamp:
present 2021-01-03 18:27:51
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK
event-on-change-reading .*
intervalNormal 60
intervalPresent 60
prGroup dynamic
thresholdAbsence 3
Im Daemon werden die Readings aber wieterhin nicht aktualisiert:
Internals:
ADDRESS daemon
DEF daemon daemon
FUUID 5fec5c44-f33f-fe74-1dd9-78931a3d4d61378b
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE daemon
NAME PREDaemon
NOTIFYDEV global
NR 67
NTFY_ORDER 50-PREDaemon
STATE active
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 19
FW_ID 158
LASTACCESS 1609695339
NAME WEB_10.3.3.31_59527
NR 126
PEER 10.3.3.31
PORT 59527
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-03 18:29:55 state Connected
READINGS:
2021-01-03 13:30:43 daemonMaxScanTime 11
2021-01-03 18:27:41 model daemon
2021-01-03 18:35:21 pGrp__total dis:0 ab:2 pres:8
2021-01-03 18:35:21 pGrp_default dis:0 ab:0 pres:0
2021-01-03 18:35:21 pGrp_dynamic dis:0 ab:2 pres:5
2021-01-03 18:35:21 pGrp_static dis:0 ab:0 pres:3
2021-01-03 18:34:51 pr_antonia_iphone.pre absent
2021-01-03 18:30:23 pr_christine_gtag.pre error
2021-01-03 18:35:21 pr_christine_iphone.pre present
2021-01-03 18:34:51 pr_christine_watch.pre present
2021-01-03 18:34:51 pr_deconz.pre present
2021-01-03 18:34:51 pr_fritte.pre present
2021-01-03 18:34:51 pr_nas.pre absent
2021-01-03 18:34:51 pr_proxmox.pre present
2021-01-03 18:30:12 pr_sebastian.gtag.pre error
2021-01-03 18:34:51 pr_sebastian_iphone.pre present
2021-01-03 18:35:21 state active
helper:
DISABLED 0
curState init
maybe 0
nextScan 1609694891.47595
cnt:
exec 0
maybe 0
state 0
th 0
disp:
condense 1
verbose 0
evnt:
interval:
absent 30
init 30
present 30
prGroups:
static
dynamic
Attributes:
devStateIcon active:ios-on-green .*:ios-NACK
event-on-change-reading .*
intervalNormal 30
prGroupDisp condense
VG Sebastian
Hier ein paar Bugfixes.
Zitat von: martinp876 am 04 Januar 2021, 18:18:42
Hier ein paar Bugfixes.
Wolltest du evtl. noch eine neue Version anhängen? ;)
gb#
ja
Moin,
nach einem kurzen Test, Perl Warnungen haben sich bei mir bis auf folgende reduziert. Wie zuvor auch, taucht diese nur bei Neustart auf.
2021.01.06 10:21:26 1: PERL WARNING: Use of uninitialized value within %stateH in hash element at ./FHEM/73_PRESENCE.pm line 837.
Danke und Grüße
Mit der letzten Version sehe ich folgendes Verhalten bei lan-bluetooth und einem gtag:
- device ist zwar present, wechselt aber zwischen maybe present und present
- Die Meldungen im Log lauten aber alle present - kein einer absent dabei
2021.01.06 10:22:30.775 5: PRESENCE (sebastian.gtag.pre) - write : 7C:2F:80:98:AC:0F|300
2021.01.06 10:22:30.775 5: SW: 7C:2F:80:98:AC:0F|300
2021.01.06 10:22:30.893 5: PRESENCE (sebastian.gtag.pre) - received data: command accepted
2021.01.06 10:22:30.896 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:22:30.896 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:22:30.898 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:22:35.364 5: PRESENCE (sebastian.gtag.pre) - write : 7C:2F:80:98:AC:0F|60
2021.01.06 10:22:35.365 5: SW: 7C:2F:80:98:AC:0F|60
2021.01.06 10:22:35.405 5: PRESENCE (sebastian.gtag.pre) - received data: command accepted
2021.01.06 10:22:35.426 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:22:35.426 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:22:35.426 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:23:35.096 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:23:35.096 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:24:35.042 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-60;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:24:35.042 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:24:35.043 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:25:35.248 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:25:35.248 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:25:35.248 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:26:35.186 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:26:35.186 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:27:35.100 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:27:35.100 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:27:35.101 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:28:35.031 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:28:35.031 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:28:35.031 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:29:35.222 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:29:35.222 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:30:35.161 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:30:35.161 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:30:35.161 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:31:35.102 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:31:35.103 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:31:35.103 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:32:35.041 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:32:35.041 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:33:35.237 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:33:35.237 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:33:35.237 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:34:35.179 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:34:35.179 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:34:35.179 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:35:35.134 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:35:35.134 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:36:35.074 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:36:35.074 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:36:35.074 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:37:35.033 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:37:35.034 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:37:35.034 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:38:35.235 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:38:35.235 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:39:35.189 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:39:35.190 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:39:35.190 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:40:35.152 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:40:35.152 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:40:35.152 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:41:35.082 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=2;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:41:35.082 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:42:35.006 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:42:35.006 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:42:35.006 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:43:35.185 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:43:35.185 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:43:35.185 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:44:35.104 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:44:35.104 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:45:35.043 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:45:35.043 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:45:35.043 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:46:35.240 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:46:35.240 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:46:35.240 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:47:35.169 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:47:35.169 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:48:35.108 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:48:35.109 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:48:35.109 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:49:35.054 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:49:35.054 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:49:35.055 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:50:35.024 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:50:35.024 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:51:35.215 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:51:35.215 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:51:35.215 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:52:35.164 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:52:35.164 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:52:35.165 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:53:35.117 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:53:35.117 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:54:35.078 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:54:35.078 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:54:35.078 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:55:35.020 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:55:35.021 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:55:35.021 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:56:35.229 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:56:35.229 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:57:35.184 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:57:35.184 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:57:35.185 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 10:58:35.131 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:58:35.132 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 10:58:35.132 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 10:59:35.091 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 10:59:35.091 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:00:35.040 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:00:35.040 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:00:35.040 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 11:01:35.239 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-63;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:01:35.239 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:01:35.239 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 11:02:35.191 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:02:35.191 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:03:35.141 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:03:35.141 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:03:35.142 4: PRESENCE (sebastian.gtag.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.06 11:04:35.081 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-61;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:04:35.082 4: PRESENCE (sebastian.gtag.pre) - status info:present
2021.01.06 11:04:35.082 4: PRESENCE (sebastian.gtag.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.06 11:05:35.035 5: PRESENCE (sebastian.gtag.pre) - received data: present;device_name=Gigaset G-tag;rssi=-62;batteryPercent=19;batteryPercentAge=3;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.06 11:05:35.036 4: PRESENCE (sebastian.gtag.pre) - status info:presentHier das device:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 15
FUUID 5ff1fa48-f33f-fe74-d910-f61b8d2bcd7b5195
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE lan-bluetooth
NAME sebastian.gtag.pre
NOTIFYDEV global
NR 75
NTFY_ORDER 50-sebastian.gtag.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 23
FW_ID 9946
LASTACCESS 1609927611
NAME WEB_10.3.3.32_56082
NR 9948
PEER 10.3.3.32
PORT 56082
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-06 11:03:40 state Connected
READINGS:
2021-01-05 22:15:35 appearCnt 0
2021-01-06 11:06:35 batteryPercent 19
2021-01-06 11:06:35 batteryPercentAge 3
2021-01-06 10:22:35 command_accepted yes
2021-01-06 11:06:35 daemon lepresenced V0.93
2021-01-06 11:06:35 device_name Gigaset G-tag
2021-01-05 19:40:28 lastAppear 2021-01-05 19:40:28
2021-01-04 22:10:29 lastDisappear 2021-01-04 22:10:29
2021-01-06 11:06:35 maybeCnt 16
2021-01-06 11:06:35 model lan-lepresenced
2021-01-06 11:06:35 presence maybe present
2021-01-06 11:06:35 rssi -64
2021-01-06 11:05:35 state present
2021-01-06 11:06:35 thresHldCnt 1
helper:
DISABLED 0
curState present
maybe 1
nextScan 1609924955.36492
cnt:
exec 196
maybe 16
state 0
th 1
disp:
condense 1
verbose 0
interval:
absent 60
init 30
present 60
timestamp:
present 2021-01-05 19:40:28
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK
event-on-change-reading .*
intervalNormal 60
intervalPresent 60
prGroup dynamic
thresholdAbsence 3
verbose 5In der cref ist bei lan-bluetooth auch noch cmd: und scan: zuviel. Im Bsp weiter unten dann korrekt:
ZitatMode: lan-bluetooth
define <name> PRESENCE lan-bluetooth cmd:<address> scan:<ip-address>
Beim Mode lan-bluetooth würde ich der Vollständigkeit halber auch noch
Alternatly you can use port 5222 (collectord) or port 5333 (lepresenced)hinzufügen
ZitatMode: lan-bluetooth
define <name> PRESENCE lan-bluetooth cmd:<address> scan:<ip-address>
Checks for a bluetooth device with the help of presenced or collectord. They can be installed where-ever you like, however accessible via network. The given device will be checked for presence status.
The default port is 5111 (presenced). Alternatly you can use port 5222 (collectord)
VG Sebastian
Hallo,
bei mir kommt es nun wieder vor, dass die Gtags, die über lan-bluetooth eingebunden sind, nicht mehr upgedatet werden.
Collectord und lepresenced melden die Gtags korrekt als an- und abwesend.
Wenn ich fhem neu mit PRESENCE-daemon "verbose 5" starte, kommen folgende log-Einträge:
2021.01.07 20:55:06.760 5: PRESENCE (Gtag_rot) - do init
2021.01.07 20:55:06.760 5: PRESENCE (Gtag_rot) - write : 7C:2F:80:99:D8:9B|30
2021.01.07 20:55:06.861 5: PRESENCE (Gtag_weiss) - do init
2021.01.07 20:55:06.862 5: PRESENCE (Gtag_weiss) - write : 7C:2F:80:99:D9:99|30
2021.01.07 20:55:15.496 5: PRESENCE (Gtag_weiss) - received data: command accepted
2021.01.07 20:55:15.496 5: PRESENCE (Gtag_weiss) - received data: socket_closed;room=Wohnzimmer
2021.01.07 20:55:15.496 3: PRESENCE (Gtag_weiss) - collectord lost connection to room Wohnzimmer
2021.01.07 20:55:15.554 5: PRESENCE (Gtag_rot) - received data: command accepted
2021.01.07 20:55:15.554 5: PRESENCE (Gtag_rot) - received data: socket_closed;room=Wohnzimmer
2021.01.07 20:55:15.554 3: PRESENCE (Gtag_rot) - collectord lost connection to room Wohnzimmer
2021.01.07 20:55:18.354 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:21.196 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:23.321 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:26.623 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:32.585 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:32.994 5: PRESENCE (Gtag_rot) - received data: absence;room=;rooms=;rssi=;
2021.01.07 20:55:32.995 4: PRESENCE (Gtag_rot) - status info:absence
2021.01.07 20:55:32.995 5: PRESENCE (Gtag_rot) - write : 7C:2F:80:99:D8:9B|30
2021.01.07 20:55:33.716 5: PRESENCE (Gtag_rot) - received data: command accepted
2021.01.07 20:55:34.043 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:36.691 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:40.222 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:41.757 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:43.004 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:43.483 5: PRESENCE (Gtag_weiss) - received data: present;rooms='Vorzimmer,Zuhause';room='Vorzimmer';rssi_Zuhause='-80';rssi_Vorzimmer='-65';device_name=Gigaset G-tag;rssi=-65;batteryPercent=28;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.07 20:55:43.484 4: PRESENCE (Gtag_weiss) - status info:present
2021.01.07 20:55:43.484 5: PRESENCE (Gtag_weiss) - write : 7C:2F:80:99:D9:99|30
2021.01.07 20:55:49.072 5: PRESENCE (PsnceDaemon) - , duration:12 reply:
2021.01.07 20:55:49.109 5: PRESENCE (Gtag_weiss) - received data: command accepted
2021.01.07 20:55:51.592 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:53.679 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:55.472 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:57.183 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:55:59.096 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:01.352 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:03.176 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:09.197 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:13.687 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:20.285 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:31.870 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:36.365 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:38.808 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:40.436 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:44.716 5: PRESENCE (PsnceDaemon) - , duration:14 reply:
2021.01.07 20:56:46.943 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:47.978 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:48.983 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:50.009 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:51.069 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:52.114 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:53.119 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:54.121 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.01.07 20:56:55.163 3: PRESENCE (PsnceDaemon) - skip scan due to running job
Was kann ich noch tun, um den Fehler zu finden?
Danke, lg, Gerhard
p.s.: Die folgenden Readings sind noch unter Hochkomma:
room 'Vorzimmer'
rooms 'Vorzimmer'
rssi_Vorzimmer '-78'
rssi_Zuhause '-92'
Mit der letzten Version werden
- im Daemon keine Group-Readings mehr aktualisiert (condense und verbose)
- lan-bluetooth devices nicht aufgeführt (1 disabled, 1 present)
Internals:
ADDRESS daemon
DEF daemon daemon
FUUID 5fec5c44-f33f-fe74-1dd9-78931a3d4d61378b
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE daemon
NAME PREDaemon
NOTIFYDEV global
NR 67
NTFY_ORDER 50-PREDaemon
STATE active
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 16
FW_ID 154
LASTACCESS 1610090640
NAME WEB_10.3.3.31_51037
NR 151
PEER 10.3.3.31
PORT 51037
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-08 08:23:51 state Connected
READINGS:
2021-01-07 23:14:49 daemonMaxScanTime 11
2021-01-08 08:18:44 model daemon
2021-01-08 08:23:57 pGrp__total dis:0 ab:0 pres:0
2021-01-08 08:23:57 pGrp_default dis:0 ab:0 pres:0
2021-01-08 08:23:57 pGrp_dynamic dis:0 ab:0 pres:0
2021-01-08 08:23:57 pGrp_static dis:0 ab:0 pres:0
2021-01-08 08:23:57 pr_antonia_iphone.fn.pre absent
2021-01-08 08:23:57 pr_christine_iphone.fn.pre absent
2021-01-08 08:23:57 pr_deconz.fn.pre present
2021-01-08 08:23:57 pr_deconz.lp.pre present
2021-01-08 08:23:57 pr_fritzbox.lp.pre present
2021-01-08 08:23:57 pr_nas.lp.pre absent
2021-01-08 08:19:58 pr_nextcloud.sh.pre present
2021-01-08 08:23:57 pr_pihole.lp.pre present
2021-01-08 08:23:57 pr_proxmox.lp.pre present
2021-01-08 08:23:57 pr_sebastian_iphone.fn.pre present
2021-01-08 08:23:57 state active
helper:
DISABLED 0
curState init
maybe 0
nextScan 1610090354.67547
cnt:
exec 0
maybe 0
state 0
th 0
disp:
condense 1
verbose 0
evnt:
interval:
absent 30
init 30
present 30
prGroups:
static
dynamic
Attributes:
devStateIcon active:ios-on-green .*:ios-NACK
event-on-change-reading .*
intervalNormal 30
prGroupDisp condense
Hier ein Verbose 5 Log vom Daemon:
2021.01.08 09:06:57.994 5: PRESENCE (PREDaemon) - , duration:1 reply:
antonia_iphone.fn.pre|absent
christine_iphone.fn.pre|absent
deconz.fn.pre|present
deconz.lp.pre|present
fritzbox.lp.pre|present
nas.lp.pre|absent
pihole.lp.pre|present
proxmox.lp.pre|present
sebastian_iphone.fn.pre|presentVG Sebastian
Groups counter sind reariert
Fehlendes Log zu "state change" implementiert
bei gestein wird nicht geforked weil schon en Job läuft. Das sollte nicht so lange sein...
1) killChilds ausführen
2) nachsehen, was da noch läuft. Es sollte nicht sein, dass einer hängen bleibt. Wäre gut zu wissen, wer es war/ist um das Problem zu identifizieren
@martinp876, wenn du doch jetzt eh schon soviel command.ref schreiben musst wäre es doch schön bei dieser Gelegenheit das HTML Format gleich so anzupassen das FHEMWEB bei jedem Auswahl eines Attibutes den jeweiligen command.ref Text als mini Hilfe unter der Eingabe anzeigt.
So wie das heute schon viele Module machen.
Groups Counter sind wieder OK.
Nur die maybe present Geschichte der gtags mit lan-bluetooth noch nicht:
2021.01.17 07:46:41.147 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-67;batteryPercent=16;batteryPercentAge=4;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 07:46:41.147 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 07:56:41.201 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-68;batteryPercent=16;batteryPercentAge=4;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 07:56:41.201 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 07:56:41.202 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 08:06:41.029 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=4;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:06:41.030 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:06:41.030 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.17 08:16:41.144 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=4;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:16:41.144 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:26:41.215 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=4;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:26:41.215 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:26:41.215 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 08:36:41.247 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:36:41.248 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:36:41.249 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.17 08:46:41.074 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:46:41.074 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:56:41.096 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 08:56:41.096 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 08:56:41.096 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 09:06:41.169 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 09:06:41.170 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 09:06:41.170 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.17 09:16:41.155 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 09:16:41.155 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 09:26:41.028 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=5;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 09:26:41.028 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 09:26:41.028 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 09:44:55.065 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 09:44:55.066 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 09:44:55.066 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.17 09:54:55.009 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 09:54:55.010 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:04:55.029 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-71;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 10:04:55.030 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:04:55.030 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 10:14:55.135 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-69;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 10:14:55.136 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:14:55.136 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
2021.01.17 10:24:55.130 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-70;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 10:24:55.131 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:31:21.688 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-75;batteryPercent=16;batteryPercentAge=0;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 10:31:21.688 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:31:21.689 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 1 check. 2 attempts left before going absent
2021.01.17 10:41:21.056 5: PRESENCE (sebastian.gtag.lbt.pre) - received data: present;device_name=Gigaset G-tag;rssi=-71;batteryPercent=16;batteryPercentAge=1;model=lan-lepresenced;daemon=lepresenced V0.93
2021.01.17 10:41:21.056 4: PRESENCE (sebastian.gtag.lbt.pre) - status info:present
2021.01.17 10:41:21.056 4: PRESENCE (sebastian.gtag.lbt.pre) - device is present after 2 check. 1 attempts left before going absent
Der presence reading des gtags steht 90% auf maybe present obwohl im Log present gemeldet wird:
Internals:
ADDRESS 7C:2F:80:98:AC:0F
DEF lan-bluetooth 7C:2F:80:98:AC:0F 10.3.3.9:5333
DeviceName 10.3.3.9:5333
FD 20
FUUID 5ff1fa48-f33f-fe74-d910-f61b8d2bcd7b5195
FVERSION 73_PRESENCE.pm:0.183140/2019-01-18
MODE lan-bluetooth
NAME sebastian.gtag.lbt.pre
NOTIFYDEV global
NR 74
NTFY_ORDER 50-sebastian.gtag.lbt.pre
PARTIAL
STATE present
TYPE PRESENCE
CL:
Authenticated 0
BUF
FD 16
FW_ID 22834
LASTACCESS 1610876873
NAME WEB_10.3.3.31_49963
NR 22834
PEER 10.3.3.31
PORT 49963
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-01-17 10:47:31 state Connected
READINGS:
2021-01-16 23:02:30 appearCnt 1
2021-01-17 10:41:21 batteryPercent 16
2021-01-17 10:41:21 batteryPercentAge 1
2021-01-09 17:45:49 command_accepted yes
2021-01-17 10:41:21 daemon lepresenced V0.93
2021-01-17 10:41:21 device_name Gigaset G-tag
2021-01-16 23:02:30 lastAppear 2021-01-16 23:02:30
2021-01-09 14:21:28 lastDisappear 2021-01-09 14:21:28
2021-01-17 10:31:21 maybeCnt 24
2021-01-17 10:41:21 model lan-lepresenced
2021-01-17 10:41:21 presence maybe present
2021-01-17 10:41:21 rssi -71
2021-01-17 10:24:55 state present
2021-01-17 10:41:21 thresHldCnt 2
helper:
DISABLED 0
curState present
maybe 1
nextScan 1610734358.91068
cnt:
exec 72
maybe 24
state 1
th 2
disp:
condense 1
verbose 0
interval:
absent 300
init 30
present 600
timestamp:
present 2021-01-16 23:02:30
Attributes:
devStateIcon present:ios-on-blue absent:ios-off disabled:ios-NACK maybe.*:ios-set_off-blue
event-on-change-reading .*
intervalNormal 300
intervalPresent 600
prGroup dynamic
thresholdAbsence 3
verbose 5
Noch ein Vorschlag:
Wie aus dem originalen PRESENCE das set active/inactive übernehmen anstatt dem Attribut disable 0/1.
VG Sebastian
Zitat von: binford6000 am 17 Januar 2021, 10:50:23
Wie aus dem originalen PRESENCE das set active/inactive übernehmen anstatt dem Attribut disable 0/1.
Ist zwar nirgendwo mit Blut geschrieben, aber einige Module nutzen sowohl set active/inaktive als vorübergehende Abschaltung (ist bei Neustart wieder weg, d.h. aktiv) und zusätzlich noch das Attribut disable 0/1 für permanente Deaktivierung.
Hallo Martin,
Danke für die neue Version, habe ich gerade installiert.
Anscheinend war es bei mir wieder mal ein Problem mit den zu kurzem "intervalNormal".
Irgendwie scheint aber auch die Liste der Readings noch nicht ganz zu stimmen.
Ich habe 3 Arten von PRESENCE-Devices:
1) lan-ping
2) function
3) lan-bluetooth
Für die Devices für (1) und (2) werden werden Readings mit "pr_<Name>" angelegt, für die (3) aber nicht.
Unter "Probably associated with" werden alle Devices also (1)-(3) aufgelistet.
Die folgenden Readings gibt es außerdem in meinem Daemon-Device:
daemonMaxScanTime 1296 2021-01-07 15:01:12
daemonSkipCnt 1 2021-01-14 20:48:39
model daemon 2021-01-17 16:11:26
pGrp__total dis:8 ab:11 pres:57 2021-01-17 20:31:10
pGrp_default dis:8 ab:11 pres:57 2021-01-17 20:31:10
Die Readings "daemonMaxScanTime" und "daemonSkipCnt" werden bei mir leider nicht mehr aktualisiert, obwohl sie sehr hilfreich wären.
Alles andere muss ich mir erst noch genauer anschauen.
lg, Gerhard
p.s.: Ein kurzes "clearCounts daemon" löst das Problem mit den beiden Readings.
Klar, wenn die 1296 der bisherige Rekord waren ;-)
Zitat von: Wzut am 17 Januar 2021, 14:33:20
Ist zwar nirgendwo mit Blut geschrieben, aber einige Module nutzen sowohl set active/inaktive als vorübergehende Abschaltung (ist bei Neustart wieder weg, d.h. aktiv) und zusätzlich noch das Attribut disable 0/1 für permanente Deaktivierung.
Wieso sollte das beim Neustart weg sein? Das ist natürlich Quatsch. Richtig implementiert ist das ein state reading und nicht weg.
Zitat von: Wzut am 17 Januar 2021, 14:33:20
Ist zwar nirgendwo mit Blut geschrieben, aber einige Module nutzen sowohl set active/inaktive als vorübergehende Abschaltung (ist bei Neustart wieder weg, d.h. aktiv) und zusätzlich noch das Attribut disable 0/1 für permanente Deaktivierung.
Das ist so pauschal nicht richtig! Bspw. at und notify können damit dauerhaft deaktiviert werden. Nur wird das nicht in der Config gespeichert, sondern im statefile und überlebt daher natürlich auch einen Neustart.
Das ist schätzungsweise das, was marvin78 mit "richtiger Implementierung" meint ;)
Ich persönlich bin ein Fan von set active/inactive, eben weil die Config nicht geändert wird.
gb#
Hi und danke für den Beitrag!
Würde dieses Modul das Problem mit folgender Situation (https://forum.fhem.de/index.php/topic,117967.msg1123909.html#msg1123909) lösen?
Hi,
leider klappt bei mir die Installation von PRESENCE define OWServerPRES PRESENCE lan-ping 192.168.2.213 nicht.
Wenn ich das Device so anlege geht FHEM sofort auf 100% Prozessorlast und lässt sich nicht mehr bedienen.
Nur ein systemctl restart fhem startet FHEM wieder.
Dann ist natürlich auch die PRESENCE-Definition weg.
Im Log befindet sich nur bis dahin nur folgendes:
2021.01.25 12:44:02.656 1: PERL WARNING: Subroutine PRESENCE_Initialize redefined at ./FHEM/73_PRESENCE.pm line 39.
2021.01.25 12:44:02.657 1: PERL WARNING: Subroutine PRESENCE_Rename redefined at ./FHEM/73_PRESENCE.pm line 65.
2021.01.25 12:44:02.664 1: PERL WARNING: Subroutine PRESENCE_Define redefined at ./FHEM/73_PRESENCE.pm line 71.
2021.01.25 12:44:02.668 1: PERL WARNING: Subroutine PRESENCE_Undef redefined at ./FHEM/73_PRESENCE.pm line 181.
2021.01.25 12:44:02.671 1: PERL WARNING: Subroutine PRESENCE_updateConfig redefined at ./FHEM/73_PRESENCE.pm line 192.
2021.01.25 12:44:02.673 1: PERL WARNING: Subroutine PRESENCE_Notify redefined at ./FHEM/73_PRESENCE.pm line 232.
2021.01.25 12:44:02.677 1: PERL WARNING: Subroutine PRESENCE_Set redefined at ./FHEM/73_PRESENCE.pm line 247.
2021.01.25 12:44:02.686 1: PERL WARNING: Subroutine PRESENCE_Get redefined at ./FHEM/73_PRESENCE.pm line 302.
2021.01.25 12:44:02.695 1: PERL WARNING: Subroutine PRESENCE_Attr redefined at ./FHEM/73_PRESENCE.pm line 462.
2021.01.25 12:44:02.699 1: PERL WARNING: Subroutine PRESENCE_setNotfiyDev redefined at ./FHEM/73_PRESENCE.pm line 588.
2021.01.25 12:44:02.700 1: PERL WARNING: Subroutine PRESENCE_getBlockingEntites redefined at ./FHEM/73_PRESENCE.pm line 594.
2021.01.25 12:44:02.701 1: PERL WARNING: Subroutine PRESENCE_getAllEntites redefined at ./FHEM/73_PRESENCE.pm line 597.
2021.01.25 12:44:02.702 1: PERL WARNING: Subroutine PRESENCE_getDaemonName redefined at ./FHEM/73_PRESENCE.pm line 600.
2021.01.25 12:44:02.703 1: PERL WARNING: Subroutine PRESENCE_lanBtWrite redefined at ./FHEM/73_PRESENCE.pm line 605.
2021.01.25 12:44:02.705 1: PERL WARNING: Subroutine PRESENCE_lanBtDoInit redefined at ./FHEM/73_PRESENCE.pm line 615.
2021.01.25 12:44:02.709 1: PERL WARNING: Subroutine PRESENCE_lanBtRead redefined at ./FHEM/73_PRESENCE.pm line 627.
2021.01.25 12:44:02.711 1: PERL WARNING: Subroutine PRESENCE_lanBtUpdtTiming redefined at ./FHEM/73_PRESENCE.pm line 688.
2021.01.25 12:44:02.713 1: PERL WARNING: Subroutine PRESENCE_lanBtReady redefined at ./FHEM/73_PRESENCE.pm line 695.
2021.01.25 12:44:02.714 1: PERL WARNING: Subroutine PRESENCE_lanBtProcessAddonData redefined at ./FHEM/73_PRESENCE.pm line 702.
2021.01.25 12:44:02.717 1: PERL WARNING: Subroutine PRESENCE_ProcessState redefined at ./FHEM/73_PRESENCE.pm line 708.
2021.01.25 12:44:02.721 1: PERL WARNING: Subroutine PRESENCE_daemonScanScheduler redefined at ./FHEM/73_PRESENCE.pm line 748.
2021.01.25 12:44:02.723 1: PERL WARNING: Subroutine PRESENCE_doDaemonUnBlocking redefined at ./FHEM/73_PRESENCE.pm line 787.
2021.01.25 12:44:02.727 1: PERL WARNING: Subroutine PRESENCE_daemonScanReply redefined at ./FHEM/73_PRESENCE.pm line 801.
2021.01.25 12:44:02.730 1: PERL WARNING: Subroutine PRESENCE_daemonAbortedScan redefined at ./FHEM/73_PRESENCE.pm line 856.
2021.01.25 12:44:02.733 1: PERL WARNING: Subroutine PRESENCE_doDaemonEntityScan redefined at ./FHEM/73_PRESENCE.pm line 864.
2021.01.25 12:44:02.736 1: PERL WARNING: Subroutine PRESENCE_doDaemonCleanup redefined at ./FHEM/73_PRESENCE.pm line 895.
2021.01.25 12:44:02.740 1: PERL WARNING: Subroutine PRESENCE_doEvtSetup redefined at ./FHEM/73_PRESENCE.pm line 921.
2021.01.25 12:44:02.743 1: PERL WARNING: Subroutine PRESENCE_doEvtCheck redefined at ./FHEM/73_PRESENCE.pm line 955.
2021.01.25 12:44:02.745 1: PERL WARNING: Subroutine PRESENCE_doEvtCheckReply redefined at ./FHEM/73_PRESENCE.pm line 973.
2021.01.25 12:44:13.662 1: PERL WARNING: Deep recursion on subroutine "main::CommandDefine" at ./FHEM/73_PRESENCE.pm line 208.
2021.01.25 12:44:13.663 1: PERL WARNING: Deep recursion on subroutine "main::LoadModule" at fhem.pl line 2075.
2021.01.25 12:44:13.663 1: PERL WARNING: Deep recursion on subroutine "main::CommandReload" at fhem.pl line 2018.
Woran scheiterts?
Hallo punker,
das ist eigenartig. Bei mir laufen die lan-pings seit Wochen ohne Probleme (und ich habe testweise mehr als 50).
Ich nehme an, Du hast:
- Die Datei aus dem Betrag #101 genommen? [url]https://forum.fhem.de/index.php/topic,117007.msg1122351.html#msg1122351[url]
- Die vorhandene Datei im Verzeichnis FHEM damit überschrieben
- Die Rechte richtig gesetzt und
- fhem neu gestartet
Sinnvoll ist es dann auch, die Datei 73_PRESENCE.pm aus dem update-Prozess zu nehmen.
Und trotzdem kommen die Fehlermeldungen?
lg, Gerhard
Genau, habe es auch mit älteren Versionen aus dem Thread probiert - mit dem selben Ergebnis!
Eigenartig. Bist Du sicher, dass fhem nur die eine richtige 73_PRESENCE.pm lädt?
Die Warnings sollten nicht kommen.
Welche Version verwendest Du gerade? Die aus #101?
Wie viele Zeilen hat die bei Dir? Bei mir sind es 1264 Zeilen.
lg, Gerhard
Auch eigenartig - meine Version hat 1262 Zeilen.
$Id: 73_PRESENCE.pm 18314 2019-01-18 13:49:05Z markusbloch
Das ist dann die aus #96 und nicht die aus #101 ;-)
Nach der $Id kannst Du nicht gehen, da diese eine Entwicklerversion ist und Martin das sicherlich noch nicht angepasst hat.
Edit: Mein Fehler: stimmt eh.
Das mit 100% load ist klar und unklar.
Offensichtlich wird das Modul neu geladen. Und entweder dies oder etwas anderes ist recursiv, startet sich also immer selbst.
Unklar ist, warum das Modul beim define neu geladen wird und warum recursiv. Das scheint bei dir einzigartig, bis jetzt.
Ist dies das erste presents device?
Hallo,
muss den alten Thread nochmal aktivieren, da ich gerade erst das modifizierte Modul entdeckt habe.
System: Mehrere Handys (iPhone + Android), die ich über das PRESENCE-Modul erkenne. iPhone durch Abfrage der MAC-Adresse an einer Fritzbox über (Beispiel)
defmod Handy_Andreas PRESENCE function cmd:{checkAllFritzMACpresent("XX:XX:XX:XX:XX:XX")} scan:1 sowie Android über eine structure, die aus lan-ping und der genannten Funktion zusammengesetzt wird. Hatte das vor Jahren so aufgesetzt, bin mir aber nicht klar ob das aktuell auch noch die geeignetste Lösung zur Erkennung der Handys ist.
"Installation" und Anpassung hat geklappt, allerdings habe ich folgende Meldungen im Log:
2021.11.15 11:31:00.895 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.11.15 11:31:01.896 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.11.15 11:31:06.758 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.11.15 11:31:07.760 3: PRESENCE (PsnceDaemon) - skip scan due to running job
2021.11.15 11:31:10.450 3: PRESENCE (PsnceDaemon) - skip scan due to running job
ein get childinfo all bringt:
BlockingCalls:
Pid:17923
Fn:PRESENCE_doDaemonUnBlocking
Arg:PsnceDaemon#Handy_Andreas,Handy_Andreas_LP,Handy_Natasja,Handy_Petra,Handy_Petra_LP,Handy_Tanja
Timeout:60
ConnectedVia:telnetForBlockingFn_1636969611_127.0.0.1_52974
Wie kann ich weitersuchen, woher diese Log-Einträge stammen und was noch nciht korrekt läuft?
Grüße Jürgen
Edit:
Glaube den Fehler gefunden zu haben.
IntervalNormal und IntervalPresence bei den Device waren im Standard mit 1 belegt. Habe beides auf 30 gestellt.
IntervalNormal im PsnceDaemon war auf 1 gestellt. Habe jetzt 60 eingetragen.
Mal sehen, ob das Problem beseitigt ist.
Hallo martinp876,
macht es nicht Sinn deine Version nun doch offiziell zu verteilen? Ich nutze deine Version schon seit Jahren ohne Probleme.
https://forum.fhem.de/index.php/topic,129846.msg1241099.html#msg1241099
Gruss
Enno
Hallo Martin,
Hallo alle Interessierten,
ich hab das Modul runtergeladen, werde es nutzen und ggf. berichten, wenn mir was auffällt.
Falls das Modul offiziell wird, wäre das super.
Viele Grüße Gisbert
PS: Kann man einen Thread eigentlich abonnieren, ohne einen eigenen Beitrag zu schreiben?
Zitat von: Gisbert am 16 Januar 2024, 08:03:49Hallo Martin,
Hallo alle Interessierten,
ich hab das Modul runtergeladen, werde es nutzen und ggf. berichten, wenn mir was auffällt.
Falls das Modul offiziell wird, wäre das super.
Das Standard-Modul im SVN: FHEM/73_PRESENCE.pm JoWiemann Unterstützende Dienste
Das "überarbeitete" Modul muss ich mir einmal ansehen, oder es gibt einen neuen Maintainer.
Zitat von: Gisbert am 16 Januar 2024, 08:03:49PS: Kann man einen Thread eigentlich abonnieren, ohne einen eigenen Beitrag zu schreiben?
Oben in der Buttonleiste: "ANTWORTEN" "ALS UNGELESEN MARKIEREN" "DRUCKEN"
"KEINE ALARME ODER E-MAILS" klicken.
Grüße Jörg
Hallo Jörg,
da Martin das Modul überarbeitet hat, wäre er aus meiner Sicht der ideale Maintainer 8)
Es wäre gut, wenn ihr beide euch abstimmen könntet.
Viele Grüße
Jürgen
Zitat von: juemuc am 16 Januar 2024, 11:18:50Es wäre gut, wenn ihr beide euch abstimmen könntet.
Hallo Jürgen,
habe das Modul auch nur geerbt und hänge definitiv nicht dran.
@Martin, bitte gerne übernehmen.
Grüße Jörg
Hallo Martin,
nach der Umstellung auf Dein Modul werden die beiden readings
pGrp__total dis:0 ab:0 pres:0 2024-01-16 16:06:43
pGrp_default dis:0 ab:0 pres:0 2024-01-16 16:06:43 nicht akzuallisiert. Im log steht folgende Info:
2024.01.16 15:54:39 1: Timeout for PRESENCE_doDaemonUnBlocking reached, terminated process 45198
2024.01.16 15:54:39 2: PRESENCE (HASH(0x559cf3c1a8)) - scan aboart
2024.01.16 15:54:39 1: ERROR: empty name in readingsBeginUpdate
2024.01.16 15:54:39 1: stacktrace:
2024.01.16 15:54:39 1: main::readingsBeginUpdate called by fhem.pl (5191)
2024.01.16 15:54:39 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (859)
2024.01.16 15:54:39 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 15:54:39 1: main::BlockingKill called by fhem.pl (3508)
2024.01.16 15:54:39 1: main::HandleTimeout called by fhem.pl (707)
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 5045.
2024.01.16 15:54:39 1: readingsUpdate(,daemonAboartCnt,1) missed to call readingsBeginUpdate first.
2024.01.16 15:54:39 1: stacktrace:
2024.01.16 15:54:39 1: main::readingsBulkUpdate called by fhem.pl (5192)
2024.01.16 15:54:39 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (859)
2024.01.16 15:54:39 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 15:54:39 1: main::BlockingKill called by fhem.pl (3508)
2024.01.16 15:54:39 1: main::HandleTimeout called by fhem.pl (707)
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4778.
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3848.
Wie kann ich das Problem beheben?
Viele Grüße
Jürgen
Zitat von: juemuc am 16 Januar 2024, 16:09:00Hallo Martin,
nach der Umstellung auf Dein Modul werden die beiden readings
pGrp__total dis:0 ab:0 pres:0 2024-01-16 16:06:43
pGrp_default dis:0 ab:0 pres:0 2024-01-16 16:06:43 nicht akzuallisiert. Im log steht folgende Info:
2024.01.16 15:54:39 1: Timeout for PRESENCE_doDaemonUnBlocking reached, terminated process 45198
2024.01.16 15:54:39 2: PRESENCE (HASH(0x559cf3c1a8)) - scan aboart
2024.01.16 15:54:39 1: ERROR: empty name in readingsBeginUpdate
2024.01.16 15:54:39 1: stacktrace:
2024.01.16 15:54:39 1: main::readingsBeginUpdate called by fhem.pl (5191)
2024.01.16 15:54:39 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (859)
2024.01.16 15:54:39 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 15:54:39 1: main::BlockingKill called by fhem.pl (3508)
2024.01.16 15:54:39 1: main::HandleTimeout called by fhem.pl (707)
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 5045.
2024.01.16 15:54:39 1: readingsUpdate(,daemonAboartCnt,1) missed to call readingsBeginUpdate first.
2024.01.16 15:54:39 1: stacktrace:
2024.01.16 15:54:39 1: main::readingsBulkUpdate called by fhem.pl (5192)
2024.01.16 15:54:39 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (859)
2024.01.16 15:54:39 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 15:54:39 1: main::BlockingKill called by fhem.pl (3508)
2024.01.16 15:54:39 1: main::HandleTimeout called by fhem.pl (707)
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4778.
2024.01.16 15:54:39 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3848.
Wie kann ich das Problem beheben?
Viele Grüße
Jürgen
Hallo Jürgen,
die Zeilennummern passen nicht zur Version von hier: https://forum.fhem.de/index.php?msg=1122351
Grüße Jörg
Hallo Jörg,
vielen Dank. Das ist genau der Grund, warum ich Module, die nicht über das FHEM-Update verteilt werden, nicht mag. Ich erwische meistens die falsche Version :-[
Aber es passt noch immer nicht :o
2024.01.16 18:37:15 1: Timeout for PRESENCE_doDaemonUnBlocking reached, terminated process 984
2024.01.16 18:37:15 2: PRESENCE (HASH(0x55cb3ffd30)) - scan aboart
2024.01.16 18:37:15 1: ERROR: empty name in readingsBeginUpdate
2024.01.16 18:37:15 1: stacktrace:
2024.01.16 18:37:15 1: main::readingsBeginUpdate called by fhem.pl (5191)
2024.01.16 18:37:15 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (861)
2024.01.16 18:37:15 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 18:37:15 1: main::BlockingKill called by ./FHEM/73_PRESENCE.pm (290)
2024.01.16 18:37:15 1: main::PRESENCE_Set called by fhem.pl (3980)
2024.01.16 18:37:15 1: main::CallFn called by fhem.pl (1970)
2024.01.16 18:37:15 1: main::DoSet called by fhem.pl (2002)
2024.01.16 18:37:15 1: main::CommandSet called by fhem.pl (1282)
2024.01.16 18:37:15 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2861)
2024.01.16 18:37:15 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (1025)
2024.01.16 18:37:15 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (609)
2024.01.16 18:37:15 1: main::FW_Read called by fhem.pl (3985)
2024.01.16 18:37:15 1: main::CallFn called by fhem.pl (786)
2024.01.16 18:37:15 1: readingsUpdate(,daemonAboartCnt,1) missed to call readingsBeginUpdate first.
2024.01.16 18:37:15 1: stacktrace:
2024.01.16 18:37:15 1: main::readingsBulkUpdate called by fhem.pl (5192)
2024.01.16 18:37:15 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (861)
2024.01.16 18:37:15 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.16 18:37:15 1: main::BlockingKill called by ./FHEM/73_PRESENCE.pm (290)
2024.01.16 18:37:15 1: main::PRESENCE_Set called by fhem.pl (3980)
2024.01.16 18:37:15 1: main::CallFn called by fhem.pl (1970)
2024.01.16 18:37:15 1: main::DoSet called by fhem.pl (2002)
2024.01.16 18:37:15 1: main::CommandSet called by fhem.pl (1282)
2024.01.16 18:37:15 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2861)
2024.01.16 18:37:15 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (1025)
2024.01.16 18:37:15 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (609)
2024.01.16 18:37:15 1: main::FW_Read called by fhem.pl (3985)
2024.01.16 18:37:15 1: main::CallFn called by fhem.pl (786)
2024.01.16 18:37:15 1: Error: >HASH(0x55cb3ffd30)< has no TYPE, but following keys: >READINGS,helper<
Die readings sind aber jetzt korrekt.
Hoffentlich hat Martin ein "Erbarmen" O:-)
Viele Grüße
Jürgen
Zitat von: juemuc am 16 Januar 2024, 18:41:43Die readings sind aber jetzt korrekt.
Hoffentlich hat Martin ein "Erbarmen" O:-)
Viele Grüße
Jürgen
Hallo Jürgen,
ich habe etwas eingebaut, dass den Fehler handhaben soll. Bitte einmal testen.
Grüße Jörg
Hallo Jörg,
vielen Dank.
Der Test verlief ohne Fehlermeldungen oder sonstige Probleme. ;D
Viele Grüße
Jürgen
Hallo,
sollten weitere positive Rückmeldungen kommen, würde ich es auch ins SVN einchecken. Allerdings überlege ich den Namen anzupassen, da es nicht rückwärts Kompatible ist.
Grüße Jörg
Hallöchen,
ich habe jetzt auch aktuell seit einigen Tagen die Version die bis heute gültig war im Betrieb gehabt und wäre natürlich schon dafür es auch wieder mit dem Update zu bekommen.
Zitat von: JoWiemann am 17 Januar 2024, 15:48:56sollten weitere positive Rückmeldungen kommen, würde ich es auch ins SVN einchecken. Allerdings überlege ich den Namen anzupassen, da es nicht rückwärts Kompatible ist.
Die Frage ist welche Vor / Nachteile gibt es für die jeweiligen Nutzer der Alten als auch "neuen" Version.
Welche Probleme ergäben sich durch eine Namensänderung für aktive Nutzer, der "inoffiziellen" Version?
VG
Andreas
Hallo Jörg,
aus meiner Sicht wäre es wichtig darüber zu informieren, dass die Devices, die mit der Funktion "event" definiert sind (im aktuellen SVN-Modul), gelöscht werden. Mir war das bewusst und ich habe diese über ein notify + dummy vorher neu definiert.
Einen neuen Namen würde ich nicht definieren. Wer es nicht nutzen will, kann es ja vom update ausschließen. Eventuell im Forum entspechende Hinweise posten und nach x-Tagen dann ersetzen.
Viele Grüße
Jürgen
Zitat von: juemuc am 17 Januar 2024, 19:14:35Einen neuen Namen würde ich nicht definieren. Wer es nicht nutzen will, kann es ja vom update ausschließen. Eventuell im Forum entspechende Hinweise posten und nach x-Tagen dann ersetzen.
Hallo Jürgen,
mit Benutzer über das Forum hinweisen, entsprechende Hinweise über das Modul selber geben, da habe ich schon so meine Erfahrungen gemacht. Das funktioniert einfach nicht. Das Modul ist einfach zu weit weg vom aktuellen Modul. Da ist es meiner Meinung nach einfacher die bewussten Nutzer der Cover Version zu informieren, dass sie ihre Devices neu definieren müssen, als die zu erreichen, die alle Monate mal updaten und sich dann wundern, dass Presence nicht mehr funktioniert.
Grüße Jörg
PS: Und ich habe gesehen das die CommandRef noch erheblichen Handlungsbedarf hat.
Zitat von: juemuc am 17 Januar 2024, 19:14:35Einen neuen Namen würde ich nicht definieren. Wer es nicht nutzen will, kann es ja vom update ausschließen. Eventuell im Forum entsprechende Hinweise posten und nach x-Tagen dann ersetzen.
Nur Mut, ich würde es genauso sehen. Update unter gleichen Namen und die "Einschläge" abwarten. Hatte z.B. beim HM-Modul auch letztlich geklappt, sogar ohne Vorwarnung ;) Viele haben damals gelernt wie ein Backup funktioniert und wo man den Eintrag macht um vom Update auszuschließen.
Gruss
Enno
Hallo,
ich werde jetzt erst einmal im aktuellen Modul eine Warnung einbauen und dann etwas später das eigentliche Update auf den Weg bringen.
Grüße Jörg
Hi Jörg,
ich bin dagegen das Modul unter dem gleichen Namen zu veröffentlichen, aus folgenden Gründen:
- Das cover Modul ist, soweit ich hier im Thread gelesen habe, NICHT mehr kompatibel oder funktioniert nicht mehr für lan-bluetooth und/oder andere operational modes. Als Beispiel diene lan-bluetooth, das viele wie im WIKI beschrieben mit collectord einsetzen.
- Attribute sind geändert odder weggefallen (z.B. absenceThreshold, das meiner Meinung für Bluetooth auch Sinn macht.)
- Das cover Modul verbessert / verändert nur den lan-ping mode. Die Funktionsweise und attribute der anderen Modi hat Martinp876 gar nicht mehr geprüft da er diese gar nicht benutzt.
Es gibt Nutzer die diese anderen Modi und Attribute nutzen oder sogar mehrere Modi gleichzeitig nutzen (lan-ping und lan-bluetooth gleichzeitig). Ein update unter gleichem Namen zerschiesst die Installation. "Nur Mut, ...ein Update unter gleichen Namen und die "Einschläge" abwarten", ist einfach zu sagen für die User hier im Thread, die nur lan-ping benutzen und sowieso schon auf das cover modul geändert haben. Aber es gibt User, die haben seit Jahren eine unveränderte Installation auch mit lan-bluetooth, und die lesen hier nicht mit.
Was sollen die mit lan-bluetooth machen, die das neue lan-ping gar nicht benutzen wollen? Oder die, die lan-bluetooth UND das neue cover lan-ping benutzen wollen? Dann das alte bisherige Modul unter einem anderen Namen kopieren, damit die bisherige lan-bluetooth Funktion weiterhin benutzt werden kann?
Ein Update unter gleichem Namen würde ich nur machen, falls das Modul kompatibel zu den anderen Modi ist und die Attribute beibehält.
My 2 cents.
Hallo Jamo,
ein "exclude_from_update" für dieses Modul unter "global" und schon ändert sich für die User nichts. Ich weiß nur, dass die Funktion "event" entfällt.
Letztendlich bin ich aber nur Anwender.
Viele Grüße
Jürgen
Hallo Jürgen,
und was ist mit denen, die lan-bluetooth UND eventuell dann das neue bessere cover lan-ping benutzen wollen? Was ist mit denen, die das dann nicht mitbekommen und wo Presence auf einmal nicht funktioniert? Ja, exclude vom Update kann man machen. Aber neue User die dann Presence benutzen, finden dann einen Wiki Eintrag der evtl nicht zum neuen cover Presence passt, weil lan-bluetooth nicht mehr funktioniert. Das zieht einen Rattenschwanz an Änderungen hinter sich her.
Was spricht degegen, das cover modul unter neuem Namen zu veröffentlichen, für die User hier aus diesem Thread? Warum nicht z.B 73_LanPing_nb.pm? Es geht ja nur darum, das neue lan-ping non-blocking zur Verfügung zu stellen.
Wie gesagt, ein Update unter gleichem Namen meiner Meinung nach nur, falls alle andere Modi weiterhin wie vorher funktionieren und die Attribute beibehalten werden.
Beste Grüsse.
Hallo Jamo,
wenn ich die Beiträge richtig verstanden habe funktioniert doch lan-bluetooth. Ich kann es aber selbst nicht testen. Bezüglich neuem Namen bin ich hin und her gerissen. Im Endeffekt muss der Maintainer entscheiden.
Viele Grüße
Jürgen
Hallo,
im Modul sind ein paar Ungereimtheiten. Lan Bluetooth ist implementiert. Local Bluetooth auch, wird aber im Define auf lokale Fhem Instanz auf einer FritzBox geprüft. Was ich hier für unsinnig halte. Ich kann das loakle Bluetooth nicht testen, habe aber die Prüfung im Define in der angehängten Version einmal auskommentiert. Falls also jemand Lust und Zeit hat, dann bitte einmal testen.
In beiden Modulen befindet sich noch Code für eine lokale Fhem Instanz auf einer FritzBox. Wird das überhaupt noch benötigt. Ich kann das jedenfalls nicht testen und habe auch nicht die Zeit und Muße eine FritzBox entsprechende zu präparieren. Sorry dafür.
Alles in allem zwei schwierige Module.
Grüße Jörg
Zitat von: Jamo am 17 Januar 2024, 21:45:29Hallo Jürgen,
und was ist mit denen, die lan-bluetooth UND eventuell dann das neue bessere cover lan-ping benutzen wollen? Was ist mit denen, die das dann nicht mitbekommen und wo Presence auf einmal nicht funktioniert? Ja, exclude vom Update kann man machen. Aber neue User die dann Presence benutzen, finden dann einen Wiki Eintrag der evtl nicht zum neuen cover Presence passt, weil lan-bluetooth nicht mehr funktioniert. Das zieht einen Rattenschwanz an Änderungen hinter sich her.
Was spricht degegen, das cover modul unter neuem Namen zu veröffentlichen, für die User hier aus diesem Thread? Warum nicht z.B 73_LanPing_nb.pm? Es geht ja nur darum, das neue lan-ping non-blocking zur Verfügung zu stellen.
Wie gesagt, ein Update unter gleichem Namen meiner Meinung nach nur, falls alle andere Modi weiterhin wie vorher funktionieren und die Attribute beibehalten werden.
Beste Grüsse.
Ein neues Presence-Modul unter dem alten Namen könnte viel User verärgern, wenn es bestehende Instanzen nicht 100% kompatibel bedient, also Readings sich gleich verhalten.
Schön wäre es, wenn das neue Modul gleich als eigenes Package erstellt würde.
An Hand der angehängten Statistik kann man Anzahl abschätzen.
Ich bin für einen neuen Namen.
Hallo,
eine Frage in die Runde. Ich kenne /usr/bin/ctlmgr_ctl nur bei einer FritzBox. Googeln hat auch nur FritzBox zurück gemeldet. Von daher macht für mich das Prüfen auf /usr/bin/ctlmgr_ctl hier überhaupt keinen Sinn. Oder übersehe ich etwas. Danke für Eure Rückmeldung.
if ($a[2] eq "lan-ping") {
if(-X "/usr/bin/ctlmgr_ctl" and not $username eq "root") {
my $msg = "FHEM is not running under root (currently $username) This check can only performed with root access";
Log 2, "PRESENCE ($name) - ".$msg;
return $msg;
}
$hash->{helper}{os}{Cmd} = ($^O =~ m/(Win|cygwin)/) ? "ping -n 1 -4 $hash->{ADDRESS}"
:($^O =~ m/solaris/) ? "ping $hash->{ADDRESS} 4"
: "ping -c 1 -w 1 $hash->{ADDRESS} 2>&1"
;
$hash->{helper}{os}{search} = $^O =~ m/solaris/? 'is alive'
: '(ttl|TTL)=\d+'
;
}
Grüße Jörg
Hallo Jörg,
ich vermute aufgrund der aktuellen Infos, dass es fü dich besser ist, wenn Du nur das "neue Modul" optimierst und das "alte" PRESENCE wird quasi eingefroren wird. Dann suchen wir noch einen schönen neuen Namen und gut ist.
Du könntest dann die "Altlasten" entfernen. Beim Testen und bei der Erstellung der Doku bin ich gerne mit dabei (sofern ich die Möglichkeiten habe).
Viele Grüße
Jürgen
PS: Eventuell kann Martin ja helfen
Als weiteren Vorteil einer Version unter neuem Namen würde ich noch folgendes sehen: Man könnte die vorhanden Geräte (und bei Notwendigkeit auch nutzende Notifies) dann eins nach dem anderen anpassen.
Zitat von: tomcat.x am 18 Januar 2024, 11:50:02Als weiteren Vorteil einer Version unter neuem Namen würde ich noch folgendes sehen: Man könnte die vorhanden Geräte (und bei Notwendigkeit auch nutzende Notifies) dann eins nach dem anderen anpassen.
Wenn es 2 Module gibt und das neue Modul auch die alten Modelle in optimierter Form enthält, kann das alte Modul als deprecated erklärt werden und nach erfolgreicher Migration entfernt werden, wie z.B. beim Modul XMBC geschehen
Zitat von: Ellert am 18 Januar 2024, 14:22:34Wenn es 2 Module gibt und das neue Modul auch die alten Modelle in optimierter Form enthält, kann das alte Modul als deprecated erklärt werden und nach erfolgreicher Migration entfernt werden, wie z.B. beim Modul XMBC geschehen
ja aber auch nur dann!
Ich bin mit dem "alten" Modul bisher gut gefahren und plädiere dafür, dass das neue Modul einen neuen Namen bekommt. Dann kann man schrittweise migrieren und wird nicht von einem auf den anderen Tag vor einen Scherbenhaufen gestellt (ich weiß, ich könnte es vom Update ausschließen...)
VG
Torsten
Text2Speech nutzt PRESENCE, um die Performance bei der Verwendung von Remoteinstanzen zu verbessern, siehe https://forum.fhem.de/index.php?msg=540420
Hallo Jörg,
falls Du noch nicht die Lust verloren hast, habe ich in deiner letzten Version nach einem Systemneustart diese Einträge im Logfile:
024.01.19 13:34:28 1: Timeout for PRESENCE_doDaemonUnBlocking reached, terminated process 3930
2024.01.19 13:34:28 2: PRESENCE (HASH(0x55e65db44e20)) - scan aboart
2024.01.19 13:34:28 1: ERROR: empty name in readingsBeginUpdate
2024.01.19 13:34:28 1: stacktrace:
2024.01.19 13:34:28 1: main::readingsBeginUpdate called by fhem.pl (5191)
2024.01.19 13:34:28 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (861)
2024.01.19 13:34:28 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.19 13:34:28 1: main::BlockingKill called by fhem.pl (3508)
2024.01.19 13:34:28 1: main::HandleTimeout called by fhem.pl (707)
2024.01.19 13:34:28 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 5045.
2024.01.19 13:34:28 1: readingsUpdate(,daemonAboartCnt,1) missed to call readingsBeginUpdate first.
2024.01.19 13:34:28 1: stacktrace:
2024.01.19 13:34:28 1: main::readingsBulkUpdate called by fhem.pl (5192)
2024.01.19 13:34:28 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE.pm (861)
2024.01.19 13:34:28 1: main::PRESENCE_daemonAbortedScan called by FHEM/Blocking.pm (285)
2024.01.19 13:34:28 1: main::BlockingKill called by fhem.pl (3508)
2024.01.19 13:34:28 1: main::HandleTimeout called by fhem.pl (707)
Ich kann aber keine Einschränkung feststellen.
Viele Grüße
Jürgen
Zitat von: juemuc am 19 Januar 2024, 14:48:10Hallo Jörg,
falls Du noch nicht die Lust verloren hast, habe ich in deiner letzten Version nach einem Systemneustart diese Einträge im Logfile:
Ich kann aber keine Einschränkung feststellen.
Viele Grüße
Jürgen
Hallo Jürgen,
ich habe mal ein zusätzliches Logging eingebaut. Ich kann den Fehler nicht nachstellen.
Grüße Jörg
Hallo Jörg,
der "Fehler" scheint nicht immer aufzutreten (Timing-Problem?)
Beim aktuellen Restart habe ich folgende Meldungen erhalten:
2024.01.19 20:21:57 2: PRESENCE (PsnceDaemon) - scan aborted
2024.01.19 20:22:50 1: PRESENCE_doDaemonUnBlocking:
PsnceDaemon#DELL_PC_check,DS415_check,DS920_check,Drucker_check,FB_Internet_check,pi_check,raspberrypi3b_check
2024.01.19 20:22:55 1: PRESENCE_daemonScanReply:
PsnceDaemon<n>0#DELL_PC_check|present<n>DS415_check|present<n>DS920_check|present<n>Drucker_check|present<n>FB_Internet_check|present<n>pi_check|present<n>raspberrypi3b_check|present
2024.01.19 20:23:20 1: PRESENCE_doDaemonUnBlocking:
PsnceDaemon#DELL_PC_check,DS415_check,DS920_check,Drucker_check,FB_Internet_check,pi_check,raspberrypi3b_check
2024.01.19 20:23:20 1: PRESENCE_daemonScanReply:
PsnceDaemon<n>0#DELL_PC_check|present<n>DS415_check|present<n>DS920_check|present<n>Drucker_check|present<n>FB_Internet_check|present<n>pi_check|present<n>raspberrypi3b_check|present
2024.01.19 20:23:50 1: PRESENCE_doDaemonUnBlocking:
PsnceDaemon#DELL_PC_check,DS415_check,DS920_check,Drucker_check,FB_Internet_check,pi_check,raspberrypi3b_check
2024.01.19 20:23:50 1: PRESENCE_daemonScanReply:
PsnceDaemon<n>0#DELL_PC_check|present<n>DS415_check|present<n>DS920_check|present<n>Drucker_check|present<n>FB_Internet_check|present<n>pi_check|present<n>raspberrypi3b_check|present
2024.01.19 20:24:20 1: PRESENCE_doDaemonUnBlocking:
PsnceDaemon#DELL_PC_check,DS415_check,DS920_check,Drucker_check,FB_Internet_check,pi_check,raspberrypi3b_check
2024.01.19 20:24:20 1: PRESENCE_daemonScanReply:
PsnceDaemon<n>0#DELL_PC_check|present<n>DS415_check|present<n>DS920_check|present<n>Drucker_check|present<n>FB_Internet_check|present<n>pi_check|present<n>raspberrypi3b_check|present
Viele Grüße
Jürgen
Hallo Jürgen,
der Fehler kann eigentlich nur entstehen, wenn der Rückgabe-String nicht korrekt ist.
2024.01.19 20:23:50 1: PRESENCE_daemonScanReply:
PsnceDaemon<n>0#DELL_PC_check|present<n>DS415_check|present<n>DS920_check|present<n>Drucker_check|present<n>FB_Internet_check|present<n>pi_check|present<n>raspberrypi3b_check|present
ist korrekt. Wichtig ist der Anfang: PsnceDaemon<n>0#
Kommt es da zu einem Fehler wird der Name des Device nicht richtig ermittelt und damit kann dann auch die hash-Referenz nicht ermittelt werden.
Grüße Jörg
Ich habe den thread zufällig gefunden, da ich auch den Eindruck habe, dass PRESENCE mein System hier und da mal ausbremst (19 entities). Für einen problemlosen Übergang würde ich auch eher für eine parallele Version mit anderem Namen plädieren ::)
schöne Grüße
Jo
Hallo,
mein Vorschlag 73_atHome.pm
Grüße Jörg
Hm. Ein solches Modul kann für weitaus mehr genutzt werden, als nur einen "zu Hause" Status zu ermitteln.
beide presence module sollten seite an seite in der cref zu finden sein, meine ich.
"PRESENCE2"?
Zitat von: marvin78 am 14 Februar 2024, 20:46:08Hm. Ein solches Modul kann für weitaus mehr genutzt werden, als nur einen "zu Hause" Status zu ermitteln.
Was wäre Deine Idee?
Würde 73_REACHABLE.pm besser passen.
Grüße Jörg
Ich habe keine. "presence" ist perfekt ;) Ich habe nix dagegen, an sowas dann einfach eine 2 dranzuhängen.
Hallo,
ich würde dann 73_PRESENCE2.pm die Tage ins SVN einchecken.
Grüße Jörg
Hallo Jörg,
meine Mobiltelefone nutzen sowohl das 2Ghz als auch das 5Ghz wlan. Die fritzbox vergibt dabei unterschiedliche ip-Adressen.
Wäre es möglich diese beim Anlegen/define des Gerätes zu berücksichtigen:
define <gerät> PRESENCE lan-ping <lan-ip1> | <lan-ip2>
o.ä. ?
beste Grüße gho
Stell' das doch einfach in deiner Fritzbox richtig ein...!?
Einfach eine feste IP für dein Telefon in der FB vergeben und schon ist Ruhe. Ansonsten kann DHCP immer eine neue IP vergeben.
Viele Grüße
Jürgen
Das liegt nicht an der FB sondern vermutlich am SmartPhone. Bei meinem Smartphone (Android) wird für das 5 Ghz eine randomisierte MAC Adresse standardmäßig verwendet und nicht die des Gerätes. Das kann ich im SmartPhone umstellen das für beide Netze die Geräte MAC genutzt wird und dann wird dein Problem gelöst sein.
Ok, danke für die schnellen Antworten.
Ich teste das mal.
Ich habe auch schon mit Alternativen über die PGruppen gespielt.
@xerion: randomisierte mac's ist das Problem! Danke für den Hinweis.
Mit fester Geräte Mac funktioniert es: feste ip-Adresse von der FritzBox.
Bleibt die Frage nach der verlorenen Sichertheit ;) O:-)
Man kann das doch für jedes Netz separat angeben.
Also in deinem Netz/deinen Netzen Geräte-MAC und sonst kannst du ja random lassen...
Habe ich so eingestellt...
Gruß, Joachim
Na toll, da hätte ich auch selbst draufkommen können. :-[
Hallo,
ich habe 73_PRESENCE2.pm jetzt ins SVN hoch geladen.
Mögliche vorgehensweise:
- Fhem update und KEIN restart
- reload 73_PRESENCE2.pm
- jedes PRESENCE Device aufrufen
- RAW definition aufrufen
- alles bis setstate in die Zwischenablage
- delete <device>
- neues RAW Fenster aufmachen
- Zwischenablage hinein kopieren
- PRESENCE in der ersten Zeile in PRESENCE2 umbenennen
- Execute commands ausführen
- Bitte vergesst hier auch nicht den PsnceDaemon!
- Save config
- 73_PRESENCE.pm aus dem global Attribut exclude_from_update herausnehmen
- nochmals ein update
Und dann Fhem neu starten. Hat bei mir einwandfrei funktioniert.
Grüße Jörg
Guten Morgen Jörg,
ich wollte gerade Deinem Vorschlag folgend den Wechsel auf das neue Modul durchführen.
Dabei bekomme ich wg. des gesetzten Attributs absenceThreshold 3 die Meldung
<device>: unknown attribut absenceThreshold. Type ....
Zitat von: Nobbynews am 16 Februar 2024, 07:52:35Guten Morgen Jörg,
ich wollte gerade Deinem Vorschlag folgend den Wechsel auf das neue Modul durchführen.
Dabei bekomme ich wg. des gesetzten Attributs absenceThreshold 3 die Meldung
<device>: unknown attribut absenceThreshold. Type ....
Guten Morgen,
die Beschreibung war nur für diejenigen, die bereits das neue Modul einsetzen und jetzt auf den neuen Namen wechseln müssen. Der Wechsel vom originalen Presence auf das neu Presence2 geht nur mittels Neudefinition.
Bitte hierzu auch die commandRef von Presence2 beachten.
Grüße Jörg
Hmm, nach einem kompletten FHEM-Update und anschließendem Neustart des Docker-Containers schmiert mir FHEM bei einem
defmod pres_Router2 PRESENCE2 lan-ping 192.168.1.2
mit folgendem Log komplett ab:
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Initialize redefined at ./FHEM/73_PRESENCE2.pm line 39.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Rename redefined at ./FHEM/73_PRESENCE2.pm line 65.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Define redefined at ./FHEM/73_PRESENCE2.pm line 71.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Undef redefined at ./FHEM/73_PRESENCE2.pm line 189.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_updateConfig redefined at ./FHEM/73_PRESENCE2.pm line 200.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Notify redefined at ./FHEM/73_PRESENCE2.pm line 240.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Set redefined at ./FHEM/73_PRESENCE2.pm line 255.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Get redefined at ./FHEM/73_PRESENCE2.pm line 310.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Attr redefined at ./FHEM/73_PRESENCE2.pm line 470.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_setNotfiyDev redefined at ./FHEM/73_PRESENCE2.pm line 596.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getBlockingEntites redefined at ./FHEM/73_PRESENCE2.pm line 602.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getAllEntites redefined at ./FHEM/73_PRESENCE2.pm line 605.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getDaemonName redefined at ./FHEM/73_PRESENCE2.pm line 608.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtWrite redefined at ./FHEM/73_PRESENCE2.pm line 613.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtDoInit redefined at ./FHEM/73_PRESENCE2.pm line 623.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtRead redefined at ./FHEM/73_PRESENCE2.pm line 635.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtUpdtTiming redefined at ./FHEM/73_PRESENCE2.pm line 696.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtReady redefined at ./FHEM/73_PRESENCE2.pm line 703.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtProcessAddonData redefined at ./FHEM/73_PRESENCE2.pm line 710.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_ProcessState redefined at ./FHEM/73_PRESENCE2.pm line 716.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonScanScheduler redefined at ./FHEM/73_PRESENCE2.pm line 756.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonUnBlocking redefined at ./FHEM/73_PRESENCE2.pm line 799.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonScanReply redefined at ./FHEM/73_PRESENCE2.pm line 813.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonAbortedScan redefined at ./FHEM/73_PRESENCE2.pm line 874.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonEntityScan redefined at ./FHEM/73_PRESENCE2.pm line 886.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonCleanup redefined at ./FHEM/73_PRESENCE2.pm line 917.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtSetup redefined at ./FHEM/73_PRESENCE2.pm line 943.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheck redefined at ./FHEM/73_PRESENCE2.pm line 977.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheckReply redefined at ./FHEM/73_PRESENCE2.pm line 995.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::CommandDefine" at ./FHEM/73_PRESENCE2.pm line 216.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::LoadModule" at fhem.pl line 2134.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::CommandReload" at fhem.pl line 2069.
lg, Stefan
PS:
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
fhem
List of new / modified files since last update:
UPD FHEM/45_Plugwise.pm (excluded from update)
UPD FHEM/47_OBIS.pm (excluded from update)
Downloading https://raw.githubusercontent.com/nagel86/fhem-flex/master/controls_fhem-flex.txt
fhem-flex
nothing to do...
Downloading https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
pythonbinding
nothing to do...
Die Namenswahl für das neue Modul finde ich äußerst unglücklich.
Hallo Jörg,
in "FHEM Code Changes" steht Presence anstatt Presence2.
Viele Grüße
Jürgen
Zitat von: betateilchen am 16 Februar 2024, 09:16:13Die Namenswahl für das neue Modul finde ich äußerst unglücklich.
Hallo betateilchen,
dass wird jetzt schon einige Zeit diskutiert. Wie lange soll man da warten?
Grüße Jörg
hi,
Zitat von: Icinger am 16 Februar 2024, 08:49:33Hmm, nach einem kompletten FHEM-Update und anschließendem Neustart des Docker-Containers schmiert mir FHEM bei einem
defmod pres_Router2 PRESENCE2 lan-ping 192.168.1.2
mit folgendem Log komplett ab:
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Initialize redefined at ./FHEM/73_PRESENCE2.pm line 39.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Rename redefined at ./FHEM/73_PRESENCE2.pm line 65.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Define redefined at ./FHEM/73_PRESENCE2.pm line 71.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Undef redefined at ./FHEM/73_PRESENCE2.pm line 189.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_updateConfig redefined at ./FHEM/73_PRESENCE2.pm line 200.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Notify redefined at ./FHEM/73_PRESENCE2.pm line 240.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Set redefined at ./FHEM/73_PRESENCE2.pm line 255.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Get redefined at ./FHEM/73_PRESENCE2.pm line 310.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_Attr redefined at ./FHEM/73_PRESENCE2.pm line 470.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_setNotfiyDev redefined at ./FHEM/73_PRESENCE2.pm line 596.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getBlockingEntites redefined at ./FHEM/73_PRESENCE2.pm line 602.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getAllEntites redefined at ./FHEM/73_PRESENCE2.pm line 605.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_getDaemonName redefined at ./FHEM/73_PRESENCE2.pm line 608.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtWrite redefined at ./FHEM/73_PRESENCE2.pm line 613.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtDoInit redefined at ./FHEM/73_PRESENCE2.pm line 623.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtRead redefined at ./FHEM/73_PRESENCE2.pm line 635.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtUpdtTiming redefined at ./FHEM/73_PRESENCE2.pm line 696.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtReady redefined at ./FHEM/73_PRESENCE2.pm line 703.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_lanBtProcessAddonData redefined at ./FHEM/73_PRESENCE2.pm line 710.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_ProcessState redefined at ./FHEM/73_PRESENCE2.pm line 716.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonScanScheduler redefined at ./FHEM/73_PRESENCE2.pm line 756.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonUnBlocking redefined at ./FHEM/73_PRESENCE2.pm line 799.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonScanReply redefined at ./FHEM/73_PRESENCE2.pm line 813.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_daemonAbortedScan redefined at ./FHEM/73_PRESENCE2.pm line 874.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonEntityScan redefined at ./FHEM/73_PRESENCE2.pm line 886.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doDaemonCleanup redefined at ./FHEM/73_PRESENCE2.pm line 917.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtSetup redefined at ./FHEM/73_PRESENCE2.pm line 943.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheck redefined at ./FHEM/73_PRESENCE2.pm line 977.
2024.02.16 08:46:17 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheckReply redefined at ./FHEM/73_PRESENCE2.pm line 995.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::CommandDefine" at ./FHEM/73_PRESENCE2.pm line 216.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::LoadModule" at fhem.pl line 2134.
2024.02.16 08:46:19 1: PERL WARNING: Deep recursion on subroutine "main::CommandReload" at fhem.pl line 2069.
lg, Stefan
PS:
Downloading https://fhem.de/fhemupdate/controls_fhem.txt
fhem
List of new / modified files since last update:
UPD FHEM/45_Plugwise.pm (excluded from update)
UPD FHEM/47_OBIS.pm (excluded from update)
Downloading https://raw.githubusercontent.com/nagel86/fhem-flex/master/controls_fhem-flex.txt
fhem-flex
nothing to do...
Downloading https://raw.githubusercontent.com/dominikkarall/fhempy/master/controls_pythonbinding.txt
pythonbinding
nothing to do...
selbe Problem gleiche Meldungen
gruss
Hallo,
defmod pres_Router2 PRESENCE2 lan-ping 192.168.1.2
lan-ping hat bisher keiner getestet.
Grüße Jörg
Zitat von: JoWiemann am 16 Februar 2024, 11:09:45Hallo,
defmod pres_Router2 PRESENCE2 lan-ping 192.168.1.2
lan-ping hat bisher keiner getestet.
Grüße Jörg
Da muss ich widersprechen. Ich nutze lan-ping auch schon sehr lange mit dem Modul. Habe heute Morgen auch auf PRESENCE2 umgebaut und auch keine Probleme mit lan-ping
Zitat von: xerion am 16 Februar 2024, 11:11:37Da muss ich widersprechen. Ich nutze lan-ping auch schon sehr lange mit dem Modul. Habe heute Morgen auch auf PRESENCE2 umgebaut und auch keine Probleme mit lan-ping
Hallo Xerion,
läuft bei mir jetzt auch gegen die Pumpe.
Grüße Jörg
Zitat von: JoWiemann am 16 Februar 2024, 11:03:51dass wird jetzt schon einige Zeit diskutiert. Wie lange soll man da warten?
Es geht doch nicht um warten, sondern um die Namenswahl an sich. Den neuen Namen habe ich heute zum ersten Mal gesehen, als die neue Datei in meinem update-Prozess auftauchte.
Generell gibt es in FHEM immer wieder an verschiedenen Stellen Probleme, wenn ein bestehender Modulname einfach wiederverwendet und z.B. nur durch eine Ziffer ergänzt wird, solange dann zwei Module existieren. Die Probleme sind seit JsonList/JsonList2 bekannt, man sollte daran einfach bei der Entwicklung denken.
Zitat von: betateilchen am 16 Februar 2024, 11:26:07Generell gibt es in FHEM immer wieder an verschiedenen Stellen Probleme, wenn ein bestehender Modulname einfach wiederverwendet und z.B. nur durch eine Ziffer ergänzt wird, solange dann zwei Module existieren. Die Probleme sind seit JsonList/JsonList2 bekannt, man sollte daran einfach bei der Entwicklung denken.
Hast Du recht. Die Verwechslung ist gegeben.
Zitat von: JoWiemann am 16 Februar 2024, 11:09:45lan-ping hat bisher keiner getestet.
Auf meinem Testsystem gibt es mit lan-ping bisher keine erkennbaren Probleme.
Einzig der Eintrag in der Log-Datei mit Log-Level 3
PRESENCE2_doDaemonUnBlocking: PsnceDaemon#<device1,device2,...>ist ein wenig nerivg, lässt sich aber durch
verbose 2 eliminieren.
Edit:
Etwas anderes ist mir noch aufgefallen.
Ich habe jeweils das Attribut
thresholdAbsence 3 gesetzt.
Das Reading
state wird immer direkt auf
present gesetzt, während das Reading
PRESENCE2 noch
maybe present anzeigt.
Erst nach den 3 angegebenen Versuchen stimmen die readings überein.
Edit 2:
Wer lesen kann, ist im Vorteil.
Das Verhalten ist so beschrieben.
It´s a feature.
Hallo,
ich habe nach einem Neustart von Fhem ein reload 73_PRESENCE2.pm gemacht.
Und danach funktionierte ein Define mit lan-ping.
Würdet ihr das mal prüfen.
Danke Euch
Hallo,
ich habe das gleiche Problem. Das Fhem läuft im offiziellen Docker.
Leider hat ein Neustart von fhem und anschließendes reload, fhem mit der gleichen Meldungen zum Absturz gebracht.
Viele Grüße
Alex
Es scheint mit dem Docker zu tun zu haben. In einem Zuarbeiter-FHEM im Docker habe ich das Problem auch, in der Hauptinstallation auf Ubuntu habe ich das Problem nicht. Ich habe jedoch leider gerade keine Zeit, das näher zu analysieren.
hi,
bei mir ist es kein Docker,
VM mit Debian GNU/Linux 11 (bullseye)
gruss
Hallo Jörg,
bei mir läuft Fhem in einer VM in Proxmox.
Nach der Definition eines PRESENCE2-Devices ist Fhem blockiert und ich erhalte folgende log-Einträge:
2024.02.17 11:23:44.838 1: PERL WARNING: Subroutine PRESENCE2_Initialize redefined at .//FHEM/73_PRESENCE2.pm line 39.
2024.02.17 11:23:44.838 1: PERL WARNING: Subroutine PRESENCE2_Rename redefined at .//FHEM/73_PRESENCE2.pm line 65.
2024.02.17 11:23:44.839 1: PERL WARNING: Subroutine PRESENCE2_Define redefined at .//FHEM/73_PRESENCE2.pm line 71.
2024.02.17 11:23:44.840 1: PERL WARNING: Subroutine PRESENCE2_Undef redefined at .//FHEM/73_PRESENCE2.pm line 189.
2024.02.17 11:23:44.841 1: PERL WARNING: Subroutine PRESENCE2_updateConfig redefined at .//FHEM/73_PRESENCE2.pm line 200.
2024.02.17 11:23:44.841 1: PERL WARNING: Subroutine PRESENCE2_Notify redefined at .//FHEM/73_PRESENCE2.pm line 240.
2024.02.17 11:23:44.842 1: PERL WARNING: Subroutine PRESENCE2_Set redefined at .//FHEM/73_PRESENCE2.pm line 255.
2024.02.17 11:23:44.843 1: PERL WARNING: Subroutine PRESENCE2_Get redefined at .//FHEM/73_PRESENCE2.pm line 310.
2024.02.17 11:23:44.845 1: PERL WARNING: Subroutine PRESENCE2_Attr redefined at .//FHEM/73_PRESENCE2.pm line 470.
2024.02.17 11:23:44.846 1: PERL WARNING: Subroutine PRESENCE2_setNotfiyDev redefined at .//FHEM/73_PRESENCE2.pm line 596.
2024.02.17 11:23:44.846 1: PERL WARNING: Subroutine PRESENCE2_getBlockingEntites redefined at .//FHEM/73_PRESENCE2.pm line 602.
2024.02.17 11:23:44.846 1: PERL WARNING: Subroutine PRESENCE2_getAllEntites redefined at .//FHEM/73_PRESENCE2.pm line 605.
2024.02.17 11:23:44.846 1: PERL WARNING: Subroutine PRESENCE2_getDaemonName redefined at .//FHEM/73_PRESENCE2.pm line 608.
2024.02.17 11:23:44.846 1: PERL WARNING: Subroutine PRESENCE2_lanBtWrite redefined at .//FHEM/73_PRESENCE2.pm line 613.
2024.02.17 11:23:44.847 1: PERL WARNING: Subroutine PRESENCE2_lanBtDoInit redefined at .//FHEM/73_PRESENCE2.pm line 623.
2024.02.17 11:23:44.847 1: PERL WARNING: Subroutine PRESENCE2_lanBtRead redefined at .//FHEM/73_PRESENCE2.pm line 635.
2024.02.17 11:23:44.848 1: PERL WARNING: Subroutine PRESENCE2_lanBtUpdtTiming redefined at .//FHEM/73_PRESENCE2.pm line 696.
2024.02.17 11:23:44.848 1: PERL WARNING: Subroutine PRESENCE2_lanBtReady redefined at .//FHEM/73_PRESENCE2.pm line 703.
2024.02.17 11:23:44.848 1: PERL WARNING: Subroutine PRESENCE2_lanBtProcessAddonData redefined at .//FHEM/73_PRESENCE2.pm line 710.
2024.02.17 11:23:44.849 1: PERL WARNING: Subroutine PRESENCE2_ProcessState redefined at .//FHEM/73_PRESENCE2.pm line 716.
2024.02.17 11:23:44.849 1: PERL WARNING: Subroutine PRESENCE2_daemonScanScheduler redefined at .//FHEM/73_PRESENCE2.pm line 756.
2024.02.17 11:23:44.850 1: PERL WARNING: Subroutine PRESENCE2_doDaemonUnBlocking redefined at .//FHEM/73_PRESENCE2.pm line 799.
2024.02.17 11:23:44.850 1: PERL WARNING: Subroutine PRESENCE2_daemonScanReply redefined at .//FHEM/73_PRESENCE2.pm line 813.
2024.02.17 11:23:44.851 1: PERL WARNING: Subroutine PRESENCE2_daemonAbortedScan redefined at .//FHEM/73_PRESENCE2.pm line 874.
2024.02.17 11:23:44.851 1: PERL WARNING: Subroutine PRESENCE2_doDaemonEntityScan redefined at .//FHEM/73_PRESENCE2.pm line 886.
2024.02.17 11:23:44.852 1: PERL WARNING: Subroutine PRESENCE2_doDaemonCleanup redefined at .//FHEM/73_PRESENCE2.pm line 917.
2024.02.17 11:23:44.852 1: PERL WARNING: Subroutine PRESENCE2_doEvtSetup redefined at .//FHEM/73_PRESENCE2.pm line 943.
2024.02.17 11:23:44.853 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheck redefined at .//FHEM/73_PRESENCE2.pm line 977.
2024.02.17 11:23:44.853 1: PERL WARNING: Subroutine PRESENCE2_doEvtCheckReply redefined at .//FHEM/73_PRESENCE2.pm line 995.
2024.02.17 11:23:46.983 1: PERL WARNING: Deep recursion on subroutine "main::CommandDefine" at .//FHEM/73_PRESENCE2.pm line 216.
2024.02.17 11:23:46.983 1: PERL WARNING: Deep recursion on subroutine "main::LoadModule" at fhem.pl line 2134.
2024.02.17 11:23:46.983 1: PERL WARNING: Deep recursion on subroutine "main::CommandReload" at fhem.pl line 2069.Auf Linux-Ebene konnte ich Fhem kurzfristig neu starten, allerdings ist die VM zu 100% mit Fhem ausgelastet.
Viele Grüße Gisbert
Edit: Nach einem Neustart der VM läuft Fhem wieder normal.
Die gesamte Funktion PRESENCE2_updateConfig() sollte man nochmal einem gründlichen Code-Review unterziehen. Da stecken für mein Empfinden eine ganze Reihe Dinge drin, die man vielleicht anders (und einfacher/logischer) lösen könnte.
Zitat von: betateilchen am 17 Februar 2024, 12:06:37Die gesamte Funktion PRESENCE2_updateConfig() sollte man nochmal einem gründlichen Code-Review unterziehen. Da stecken für mein Empfinden eine ganze Reihe Dinge drin, die man vielleicht anders (und einfacher/logischer) lösen könnte.
Hallo betateilchen, gebe ich Dir recht. Im Moment fehlt aber die Zeit.
@alle, Vorschläge kann ich aber einbauen.
Grüße Jörg
Die Funktion PRESENCE2_updateConfig() wird zu oft aufgerufen. Sie steht sowohl im _Initialize() als auch im _Define(). Da aber das _Define() beim ersten device ohnehin dafür sorgt, dass die Funktion _Initialize() nach dem Laden des Moduls ausgeführt wird, passiert der Aufruf zweimal hintereinander und durch die Art und Weise, wie die Prüfung auf $init_done umgesetzt ist, werden permanent Timer gelöscht und wieder neue gesetzt.
Ein paar weitere Anmerkungen habe ich mal mit ??? eingetragen.
sub PRESENCE2_updateConfig(){
# this routine is called after the last define of a restart
# this gives FHEM sufficient time to fill in attributes
# it will also be called after each manual definition
# Purpose is to parse attributes and read config
??? Die Prüfung auf $init_done kann man getrost der Funktion InternalTimer() überlassen, indem man den letzten Parameter auf 1 setzt. Diesen Timer sollte man m.E. nur im _Define() setzen.
if (!$init_done){
RemoveInternalTimer("PRESENCE2_updateConfig");
InternalTimer(2,"PRESENCE2_updateConfig", "PRESENCE2_updateConfig", 0);
return;
}
??? Um sicherzustellen, dass es nur einen Daemon gibt, könnte man diesen per defmod in Initialize() anlegen. Dann kann man sich die gesamte Prüfung und das Löschen überzähliger daemons ersparen.
??? Warum steht der kommende Code-Teil separat in geschweiften Klammern? Das macht für mich keinen Sinn.
{# ensure only one daemon
my @daemons = devspec2array("TYPE=PRESENCE2:FILTER=MODE=daemon");
my $daemonName = shift @daemons;# leave the first alive
CommandDelete(undef,$_)foreach (@daemons);
if (!defined $daemonName){ # daemon not available
CommandDefine(undef,'PsnceDaemon PRESENCE2 daemon daemon');
}
??? wenn man den daemon ohnehin automatisiert anlegt, ist der Name doch bekannt und die Funktion getDaemonName() entbehrlich
my $dN = PRESENCE2_getDaemonName();
PRESENCE2_doDaemonCleanup();
RemoveInternalTimer(undef,"PRESENCE2_daemonScanScheduler");
InternalTimer(gettimeofday() + $attr{$dN}{intervalNormal}, "PRESENCE2_daemonScanScheduler", $defs{$dN}, 0);
}
PRESENCE2_doEvtSetup("init");
foreach (devspec2array("TYPE=PRESENCE2:FILTER=MODE=lan-bluetooth")){
my $hash = $defs{$_};
next if ($hash->{helper}{DISABLED} == 1);
next if (defined $hash->{FD});
DevIo_OpenDev($hash, 0, "PRESENCE2_lanBtDoInit");
}
??? Warum werden die userAttr global angelegt? Die sind doch nur für PRESENCE2 devices relevant? Dann reicht es doch, diese auf Instanzebene anzulegen.
my $gua = AttrVal("global","userattr","");
$gua .= ($gua =~ m/presentCycle/ ? "" : " presentCycle" )
.($gua =~ m/presentReading/ ? "" : " presentReading")
;
CommandAttr(undef, "global userattr $gua") if(AttrVal("global","userattr","") ne $gua);
}
Ich habe heute mit dem Update von FHEM das neue Presence-Modul geladen und wollte mal probieren.
Leider hängt sich FHEM beim Versuch der Definition auf. Das Log enthält massenweise Fehler.
Def:
define Handy_H PRESENCE2 bluetooth bc:7a:bf:08:22:e9
Auszug der Fehlerliste:
[pre]2024.02.23 07:00:14.435 1: PERL WARNING: Subroutine PRESENCE2_Initialize redefined at ./FHEM/73_PRESENCE2.pm line 39.
2024.02.23 07:00:14.436 1: PERL WARNING: Subroutine PRESENCE2_Rename redefined at ./FHEM/73_PRESENCE2.pm line 65.
2024.02.23 07:00:14.440 1: PERL WARNING: Subroutine PRESENCE2_Define redefined at ./FHEM/73_PRESENCE2.pm line 71.
2024.02.23 07:00:14.442 1: PERL WARNING: Subroutine PRESENCE2_Undef redefined at ./FHEM/73_PRESENCE2.pm line 189.
2024.02.23 07:00:14.444 1: PERL WARNING: Subroutine PRESENCE2_updateConfig redefined at ./FHEM/73_PRESENCE2.pm line 200.
2024.02.23 07:00:14.446 1: PERL WARNING: Subroutine PRESENCE2_Notify redefined at ./FHEM/73_PRESENCE2.pm line 240.
2024.02.23 07:00:14.448 1: PERL WARNING: Subroutine PRESENCE2_Set redefined at ./FHEM/73_PRESENCE2.pm line 255.
2024.02.23 07:00:14.452 1: PERL WARNING: Subroutine PRESENCE2_Get redefined at ./FHEM/73_PRESENCE2.pm line 310.
2024.02.23 07:00:14.457 1: PERL WARNING: Subroutine PRESENCE2_Attr redefined at ./FHEM/73_PRESENCE2.pm line 470.
2024.02.23 07:00:14.460 1: PERL WARNING: Subroutine PRESENCE2_setNotfiyDev redefined at ./FHEM/73_PRESENCE2.pm line 596.
2024.02.23 07:00:14.461 1: PERL WARNING: Subroutine PRESENCE2_getBlockingEntites redefined at ./FHEM/73_PRESENCE2.pm line 602.
2024.02.23 07:00:14.461 1: PERL WARNING: Subroutine PRESENCE2_getAllEntites redefined at ./FHEM/73_PRESENCE2.pm line 605.
2024.02.23 07:00:14.462 1: PERL WARNING: Subroutine PRESENCE2_getDaemonName redefined at ./FHEM/73_PRESENCE2.pm line 608.
2024.02.23 07:00:14.463 1: PERL WARNING: Subroutine PRESENCE2_lanBtWrite redefined at ./FHEM/73_PRESENCE2.pm line 613.
2024.02.23 07:00:14.464 1: PERL WARNING: Subroutine PRESENCE2_lanBtDoInit redefined at ./FHEM/73_PRESENCE2.pm line 623.
2024.02.23 07:00:14.466 1: PERL WARNING: Subroutine PRESENCE2_lanBtRead redefined at ./FHEM/73_PRESENCE2.pm line 635.
2024.02.23 07:00:14.467 1: PERL WARNING: Subroutine PRESENCE2_lanBtUpdtTiming redefined at ./FHEM/73_PRESENCE2.pm line 696.
2024.02.23 07:00:14.468 1: PERL WARNING: Subroutine PRESENCE2_lanBtReady redefined at ./FHEM/73_PRESENCE2.pm line 703.
2024.02.23 07:00:14.469 1: PERL WARNING: Subroutine PRESENCE2_lanBtProcessAddonData redefined at ./FHEM/73_PRESENCE2.pm line 710.
2024.02.23 07:00:14.471 1: PERL WARNING: Subroutine PRESENCE2_ProcessState redefined at ./FHEM/73_PRESENCE2.pm line 716.
2024.02.23 07:00:14.473 1: PERL WARNING: Subroutine PRESENCE2_daemonScanScheduler redefined at ./FHEM/73_PRESENCE2.pm line 756.[/pre]
Das alte Presence-Modul läuft noch. Können die Module vielleicht nicht nebeneinander laufen?
Ich wollte für den Test nicht gleich alles löschen, da ich nicht weiss, ob ich alles zum Laufen bekomme.
Zitat von: Invers am 23 Februar 2024, 07:31:19Ich habe heute mit dem Update von FHEM das neue Presence-Modul geladen und wollte mal probieren.
Leider hängt sich FHEM beim Versuch der Definition auf. Das Log enthält massenweise Fehler.
Hallo,
nichts für ungut, aber etwas weiter unten findest Du den Hinweis, dass dieses Problem bekannt ist und ich im Moment keine Zeit habe mich um eine Lösung zu kümmern.
Manchmal funktioniert ein reload 73_PRESENCE2.pm in der Fhem Kommandozeile. Also Device wieder löschen, Fhem neu starten und das reload durchführen.
Ein Hinweis in welche Umgebung Dein Fhem läuft wäre auch sehr hilfreich.
Grüße Jörg
Vielen Dank für die Antwort.
Oh! Sorry, hab ich nicht gesehen, dass weiter unten etwas darüber steht.
Ich sehe seit einiger Zeit leider immer schlechter.
Auch meine späte Antwort bitte ich zu entschuldigen. Ich habe keine Mail zur Nachricht erhalten. Das passiert neuerdings häufiger. Vielleicht habe ich etwas falsch eingestellt.
Mein System ist ein Pi 3b+ mit Bullseye.
Das Device löschen geht leider nicht, da ich fhem nicht mehr erreichen kann. Auch fhem Dienst stoppen funktioniert nicht. Ich muss den Pi neu starten. Dann ist das Device sowieso weg, da ich nicht speichern konnte.
reload 73_PRESENCE2.pm funktioniert leider nicht. Der Pi hängt damit dann auch fest und müllt das Log zu.
Ich warte dann mal ab, bis das Problem beseitigt ist. Es brennt ja nicht.
Zitat von: JoWiemann am 23 Februar 2024, 07:39:34nichts für ungut, aber etwas weiter unten findest Du den Hinweis, dass dieses Problem bekannt ist und ich im Moment keine Zeit habe mich um eine Lösung zu kümmern.
Nichts für ungut, aber ich finde es
zum Kotzen verantwortungslos, eine Moduldatei, von der man WEISS, dass sie reihenweise die FHEM Installationen bei Anwendern lahmlegt, einfach achselzuckend in der Distribution zu lassen "weil man keine Zeit hat".
Nimm die Datei einfach schnellstmöglich aus SVN raus, bis das Problem gelöst ist, dann zerschießt Du wenigstens nicht noch weitere FHEM-Installationen.
Zitat von: betateilchen am 26 Februar 2024, 08:05:03Nichts für ungut, aber ich finde es zum Kotzen verantwortungslos, eine Moduldatei, von der man WEISS, dass sie reihenweise die FHEM Installationen bei Anwendern lahmlegt, einfach achselzuckend in der Distribution zu lassen "weil man keine Zeit hat".
Nimm die Datei einfach schnellstmöglich aus SVN raus, bis das Problem gelöst ist, dann zerschießt Du wenigstens nicht noch weitere FHEM-Installationen.
Hallo betateilchen,
ich habe drei RPi (bullseye) mit Fhem laufen. Auf keinem kann ich den Fehler nachstellen. Und "reihenweise" ist wohl echt übertrieben. Ich kann die Benutzer verstehen. Hilfreich wäre vor der Definition eines PRESENCE2 Devices verbose im global auf 5 zu stellen. Vielleicht zeigt ja das Log dann etwas hilfreiches. So komme ich jedenfalls erste einmal nicht weiter.
Ich habe Deine Anmerkungen zum Code aufgenommen und teilweise umgesetzt. Vielleicht findest sich ja jemand, bei dem es bisher nicht funktioniert hat, fürs Testen.
Grüße Jörg
Hallo,
würde bitte jemand, bei dem 73_PRESENCE2.pm zu diesen reload Fehlern führt, die angehängte Version testen. Bitte vorher im Device global verbose auf 5 stellen.
Vielen Dank.
Zitat von: JoWiemann am 26 Februar 2024, 12:45:59ich habe drei RPi (bullseye) mit Fhem laufen. Auf keinem kann ich den Fehler nachstellen. Und "reihenweise" ist wohl echt übertrieben
Selbst wenn es nur ein einziger Benutzer wäre, bei dem ein FHEM-Problem nachweislich auf einen Fehler in einem meiner Module zurückzuführen ist, würde ich mein Modul entweder auf die vorherige Version zurückdrehen oder so lange rausnehmen, bis ich das Problem gelöst habe. Auch wenn ich es selbst nicht nachstellen, würde ich das Thema ernstnehmen.
Den Fehler in Deinem Modul kann ich aktuell auch nicht nachstellten, sonst hätte ich vermutlich schon einen Lösungsvorschlag gemacht. Trotzdem lässt sich nicht abstreiten, dass es offenbar unter - bisher noch nicht ganz geklärten Bedingungen - ein Problem gibt.
Danke für die Änderung. Mit dieser Version (reinkopiert und reload gemacht) funktioniert anscheinend alles.
Die folgenden Meldungen zeigen nur, dass alles ok ist. Eine Fehlermeldung am Ende des Auszuges kam allerdings. Danach ging es aber normal weiter.
Ich entferne die Def wieder, um mein Log zu schonen.
NACHTRAG 28.02.
Mir ist aufgefallen, dass statt present und absent leider present und error angezeigt wird. Absent fehlt bei mir.
[pre]2024.02.27 05:39:46.248 3: PRESENCE2 (PsnceDaemon) - remove event track for global
2024.02.27 05:40:19.117 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:20.118 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:22.121 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:26.184 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:29.231 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:33.348 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:36.351 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:37.352 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:40.453 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:43.456 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:44.458 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:46.460 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:49.547 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:54.301 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:56.303 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:40:59.305 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:03.061 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:06.138 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:09.140 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:11.143 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:15.146 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:18.150 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:19.180 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:20.188 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:22.195 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:23.196 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:24.198 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:27.292 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:30.525 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:33.528 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:34.531 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:36.551 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:40.295 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:42.318 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:43.319 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:45.321 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:49.327 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:51.456 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:53.457 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:54.730 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:56.732 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:41:59.736 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:02.739 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:03.740 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:04.742 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:06.744 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:10.843 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:13.881 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:16.702 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:17.703 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:20.724 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:23.740 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:26.745 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:27.747 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:31.278 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:33.831 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:35.834 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:37.835 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:38.836 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:39.837 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:40.839 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:42.867 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:45.871 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:46.873 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:47.874 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:49.974 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:51.188 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:52.189 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:54.550 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:55.551 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:57.581 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:42:58.583 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:01.775 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:03.779 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:05.855 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:10.865 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:12.867 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:13.887 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:14.888 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:17.892 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:21.913 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:25.082 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:26.084 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:29.102 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:32.105 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:35.317 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:36.319 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:39.322 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:42.325 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:46.703 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:49.705 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:50.706 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:53.831 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:54.914 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:55.916 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:43:57.918 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:01.962 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:02.962 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:05.063 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:06.068 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:09.164 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:11.111 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:12.555 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:13.808 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:13.965 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:15.568 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:16.812 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:16.946 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:18.588 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:19.928 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:19.970 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:21.405 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:22.850 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:24.100 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:25.101 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:25.737 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:27.103 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:27.183 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:28.823 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:30.109 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:31.110 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:31.492 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:33.004 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:34.126 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:34.512 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:35.990 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:37.129 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:38.130 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:38.637 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:40.132 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:40.246 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:41.680 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:43.105 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:44.229 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:44.488 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:45.951 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:47.231 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:47.383 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:48.826 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:50.232 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:50.235 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:51.653 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:53.082 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:54.459 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:54.837 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:56.840 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:44:57.170 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:58.787 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:44:59.997 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:00.220 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:01.952 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:03.955 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:04.117 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:05.958 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:06.883 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:07.319 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:08.850 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:10.002 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:10.228 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:11.669 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:13.005 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:14.007 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:14.295 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:15.895 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:17.034 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:17.385 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:18.806 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:20.041 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:21.042 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:21.480 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:22.491 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:23.878 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:25.045 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:25.370 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:26.803 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:28.095 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:29.097 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:29.480 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:30.862 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:32.099 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:32.365 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:33.858 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:35.102 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:36.322 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:36.639 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:38.028 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:39.326 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:40.328 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:40.896 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:42.330 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:42.341 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:43.838 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:45.333 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:46.582 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:46.585 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:48.011 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:49.467 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:49.992 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:51.451 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:52.681 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:52.839 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:54.791 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:55.542 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:56.959 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:45:57.161 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:58.853 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:45:59.972 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:00.990 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:01.484 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:02.881 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:03.326 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:04.790 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:06.002 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:06.167 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:07.650 5: PRESENCE2 (Handy_H) - result:present
########command>hcitool -i hci0 name bc:7a:bf:08:22:e9
########reply >Galaxy-A51-von-Heinz
2024.02.27 05:46:09.205 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:10.206 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:11.207 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:12.208 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:13.209 3: PRESENCE2 (PsnceDaemon) - skip scan due to running job
2024.02.27 05:46:13.474 5: PRESENCE2 (Handy_H) - result:error|Could not execute command: "hcitool -i hci0 name bc:7a:bf:08:22:e9"[/pre]
Ich habe heute die Änderungen per Update übernommen.
Mir ist aufgefallen, dass noch immer statt present und absent leider nur present und error angezeigt wird. Absent fehlt bei mir.
Somit ist das Modul leider für mich noch immer nicht nutzbar, obwohl fhem nicht mehr hängt.
Falls weitere Infos benötigt werden, bitte mitteilen.
define Handy_H PRESENCE2 bluetooth bc:7a:bf:08:22:e9
attr Handy_H intervalNormal 1
attr Handy_H intervalPresent 1
# ADDRESS bc:7a:bf:08:22:e9
# DEBUGLOG OFF
# DEF bluetooth bc:7a:bf:08:22:e9
# FUUID 65e2ce62-f33f-8098-600d-3194ecb64949cb66
# MODE bluetooth
# NAME Handy_H
# NOTIFYDEV global
# NR 617
# NTFY_ORDER 50-Handy_H
# STATE error
# TYPE PRESENCE2
# VERSION 01.00
# eventCount 581
# READINGS:
# 2024-03-02 07:59:51 appearCnt 1
# 2024-03-02 07:59:51 lastAppear 2024-03-02 07:59:51
# 2024-03-02 07:59:46 model bluetooth
# 2024-03-02 08:18:26 presence present
# 2024-03-02 08:19:28 state error
# helper:
# DISABLED 0
# FhemLog3Std 0
# curState present
# debugLog Handy_H_debugLog
# logDebug
# maybe 0
# nextScan 1709363970.08767
# cnt:
# exec 557
# maybe 0
# state 1
# th 0
# disp:
# condense 1
# verbose 0
# interval:
# absent 1
# init 30
# present 1
# os:
# Cmd hcitool -i hci0 name bc:7a:bf:08:22:e9
# search [A-Za-z0-9]+
# timestamp:
# present 2024-03-02 07:59:51
#
setstate Handy_H error
setstate Handy_H 2024-03-02 07:59:48 .associatedWith PsnceDaemon
setstate Handy_H 2024-03-02 07:59:51 appearCnt 1
setstate Handy_H 2024-03-02 07:59:51 lastAppear 2024-03-02 07:59:51
setstate Handy_H 2024-03-02 07:59:46 model bluetooth
setstate Handy_H 2024-03-02 08:18:26 presence present
setstate Handy_H 2024-03-02 08:19:28 state error
[pre]Internals:
ADDRESS bc:7a:bf:08:22:e9
DEBUGLOG OFF
DEF bluetooth bc:7a:bf:08:22:e9
FUUID 65e2ce62-f33f-8098-600d-3194ecb64949cb66
MODE bluetooth
NAME [url=http://fhem3:8083/fhem?detail=Handy_H]Handy_H[/url]
NOTIFYDEV [url=http://fhem3:8083/fhem?detail=global]global[/url]
NR 617
NTFY_ORDER 50-[url=http://fhem3:8083/fhem?detail=Handy_H]Handy_H[/url]
STATE error
TYPE PRESENCE2
VERSION 01.00
eventCount 587
.attraggr:
.attrminint:
CL:
Authenticated 0
BUF
FD 93
FW_ID 1709363934.0377
LASTACCESS 1709364027.51497
NAME [url=http://fhem3:8083/fhem?detail=WEB_192.168.178.67_51107]WEB_192.168.178.67_51107[/url]
NR 10001950
PEER 192.168.178.67
PORT 51107
SNAME [url=http://fhem3:8083/fhem?detail=WEB]WEB[/url]
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
encoding UTF-8
.attraggr:
.attrminint:
READINGS:
2024-03-02 08:17:30 state Connected
READINGS:
2024-03-02 07:59:48 .associatedWith [url=http://fhem3:8083/fhem?detail=PsnceDaemon]PsnceDaemon[/url]
2024-03-02 07:59:51 appearCnt 1
2024-03-02 07:59:51 lastAppear 2024-03-02 07:59:51
2024-03-02 07:59:46 model bluetooth
2024-03-02 08:18:26 presence present
2024-03-02 08:20:23 state error
helper:
DISABLED 0
FhemLog3Std 0
curState present
debugLog Handy_H_debugLog
logDebug
maybe 0
nextScan 1709364025.14119
cnt:
exec 557
maybe 0
state 1
th 0
disp:
condense 1
verbose 0
interval:
absent 1
init 30
present 1
os:
Cmd hcitool -i hci0 name bc:7a:bf:08:22:e9
search [A-Za-z0-9]+
timestamp:
present 2024-03-02 07:59:51
Attributes:
intervalNormal 1
intervalPresent 1[/pre]
Zitat von: Invers am 27 Februar 2024, 05:55:09Danke für die Änderung. Mit dieser Version (reinkopiert und reload gemacht) funktioniert anscheinend alles.
Ohne jetzt zu wissen, ob es daran liegen kann: Kann es sein, dass du dort sekundlich die Abfrage machst?
(Kurzform, weil mobiles Mäusekino)
VG
Andreas
Zitat von: flummy1978 am 02 März 2024, 09:38:20Ohne jetzt zu wissen, ob es daran liegen kann: Kann es sein, dass du dort sekundlich die Abfrage machst?
(Kurzform, weil mobiles Mäusekino)
VG
Andreas
Vom originären Modul Ersteller ist die sekündliche Abfrage als Default vorgesehen. Ich habe das erst einmal nicht geändert. Man kann ja durch set <name> intervalNormal <Sekunden> das Intervall verlängern.
Grüße Jörg
Gestern Abend wurde keines meiner Handys mehr erkannt. Der Status blieb auf abwesend.
Das Log ist voll mit Meldungen wie:
[pre]Timeout: process terminated
2024.03.02 09:10:49.848 2: PRESENCE (a51H) - check returned a valid result after 2 unsuccesful retries
2024.03.02 09:21:46.284 1: Timeout for PRESENCE_DoLocalBluetoothScan reached, terminated process 17723
2024.03.02 09:21:46.287 2: PRESENCE (a51H) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.03.02 09:22:53.551 2: PRESENCE (a51H) - check returned a valid result after 1 unsuccesful retry
2024.03.02 09:41:53.647 1: Timeout for PRESENCE_DoLocalBluetoothScan reached, terminated process 19212
2024.03.02 09:41:53.650 2: PRESENCE (a51K) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.03.02 09:43:03.674 1: Timeout for PRESENCE_DoLocalBluetoothScan reached, terminated process 19326
2024.03.02 09:43:03.677 2: PRESENCE (a51K) - device could not be checked after 1 retry (retrying in 10 seconds): Timeout: process terminated
2024.03.02 09:43:56.640 2: PRESENCE (a51K) - check returned a valid result after 2 unsuccesful retries
2024.03.02 09:44:35.398 1: Timeout for PRESENCE_DoLocalBluetoothScan reached, terminated process 19480
2024.03.02 09:44:35.401 2: PRESENCE (a51H) - device could not be checked (retrying in 10 seconds): Timeout: process terminated[/pre]
und dann :
[pre]Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Device is not available.
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down
Invalid device: Network is down[/pre]
Ich musste das Update rückgängig machen und den Pi neu starten. Erst danach läuft wieder alles, allerdings nun wieder ohne presence2.
Ich wollte das Modul nutzen, da ich mit dem 73_PRESENCE auch Freeze Probleme habe.
Jedoch bringt mir das 73_PRESENCE2 da fhem auf dem PI3 direkt zum stehen:
define PRES2_TV4 PRESENCE2 lan-ping 192.168.10.55
Can't call method "CDCOpenData_DebugLog" on unblessed reference at ./FHEM/73_PRESENCE2.pm line 77.
Zitat von: GunterB am 04 März 2024, 09:38:30Ich wollte das Modul nutzen, da ich mit dem 73_PRESENCE auch Freeze Probleme habe.
Jedoch bringt mir das 73_PRESENCE2 da fhem auf dem PI3 direkt zum stehen:
define PRES2_TV4 PRESENCE2 lan-ping 192.168.10.55
Can't call method "CDCOpenData_DebugLog" on unblessed reference at ./FHEM/73_PRESENCE2.pm line 77.
Ups, da ist mir etwas durchgegangen. Kommt morgen mit dem Update oder jetzt schon im Anhang.
Grüße Jörg
Hallo Jörg,
bei mir läuft es problemlos.
Viele Grüße
Jürgen
Update eingespielt.
Habe hier noch was:
2024.03.05 08:15:59 1: ERROR: empty name in readingsBeginUpdate
2024.03.05 08:15:59 1: stacktrace:
2024.03.05 08:15:59 1: main::readingsBeginUpdate called by ./FHEM/73_PRESENCE2.pm (1031)
2024.03.05 08:15:59 1: main::PRESENCE2_daemonScanReply called by (eval 27781) (1)
2024.03.05 08:15:59 1: (eval) called by fhem.pl (1177)
2024.03.05 08:15:59 1: main::AnalyzePerlCommand called by fhem.pl (1206)
2024.03.05 08:15:59 1: main::AnalyzeCommand called by fhem.pl (1133)
2024.03.05 08:15:59 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2024.03.05 08:15:59 1: main::telnet_Read called by fhem.pl (3985)
2024.03.05 08:15:59 1: main::CallFn called by fhem.pl (786)
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4706.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/73_PRESENCE2.pm line 934.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 935.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 935.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $hash in hash element at ./FHEM/73_PRESENCE2.pm line 58.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $instName in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 74.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 5043.
2024.03.05 08:15:59 1: readingsUpdate(,lastDisappear,2024-03-05 08:15:59) missed to call readingsBeginUpdate first.
2024.03.05 08:15:59 1: stacktrace:
2024.03.05 08:15:59 1: main::readingsBulkUpdate called by ./FHEM/73_PRESENCE2.pm (937)
2024.03.05 08:15:59 1: main::PRESENCE2_ProcessState called by ./FHEM/73_PRESENCE2.pm (1032)
2024.03.05 08:15:59 1: main::PRESENCE2_daemonScanReply called by (eval 27781) (1)
2024.03.05 08:15:59 1: (eval) called by fhem.pl (1177)
2024.03.05 08:15:59 1: main::AnalyzePerlCommand called by fhem.pl (1206)
2024.03.05 08:15:59 1: main::AnalyzeCommand called by fhem.pl (1133)
2024.03.05 08:15:59 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2024.03.05 08:15:59 1: main::telnet_Read called by fhem.pl (3985)
2024.03.05 08:15:59 1: main::CallFn called by fhem.pl (786)
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/73_PRESENCE2.pm line 901.
2024.03.05 08:15:59 1: readingsUpdate(,state,absent) missed to call readingsBeginUpdate first.
2024.03.05 08:15:59 1: stacktrace:
2024.03.05 08:15:59 1: main::readingsBulkUpdate called by ./FHEM/73_PRESENCE2.pm (942)
2024.03.05 08:15:59 1: main::PRESENCE2_ProcessState called by ./FHEM/73_PRESENCE2.pm (1032)
2024.03.05 08:15:59 1: main::PRESENCE2_daemonScanReply called by (eval 27781) (1)
2024.03.05 08:15:59 1: (eval) called by fhem.pl (1177)
2024.03.05 08:15:59 1: main::AnalyzePerlCommand called by fhem.pl (1206)
2024.03.05 08:15:59 1: main::AnalyzeCommand called by fhem.pl (1133)
2024.03.05 08:15:59 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2024.03.05 08:15:59 1: main::telnet_Read called by fhem.pl (3985)
2024.03.05 08:15:59 1: main::CallFn called by fhem.pl (786)
2024.03.05 08:15:59 1: readingsUpdate(,presence,absent) missed to call readingsBeginUpdate first.
2024.03.05 08:15:59 1: stacktrace:
2024.03.05 08:15:59 1: main::readingsBulkUpdate called by ./FHEM/73_PRESENCE2.pm (956)
2024.03.05 08:15:59 1: main::PRESENCE2_ProcessState called by ./FHEM/73_PRESENCE2.pm (1032)
2024.03.05 08:15:59 1: main::PRESENCE2_daemonScanReply called by (eval 27781) (1)
2024.03.05 08:15:59 1: (eval) called by fhem.pl (1177)
2024.03.05 08:15:59 1: main::AnalyzePerlCommand called by fhem.pl (1206)
2024.03.05 08:15:59 1: main::AnalyzeCommand called by fhem.pl (1133)
2024.03.05 08:15:59 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2024.03.05 08:15:59 1: main::telnet_Read called by fhem.pl (3985)
2024.03.05 08:15:59 1: main::CallFn called by fhem.pl (786)
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4776.
2024.03.05 08:15:59 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3848.
Hallo Jörg,
ich habe nach dem Umstieg nun doch Probleme. Habe zuerst alle pressence-Devices inkl Daemon gelöscht und dann neu mit Presence2 über defmod angelegt. Jetzt erhalte ich bei jedem Neustart
2024.03.05 12:06:49 1: Messages collected while initializing FHEM:configfile: Drucker_check: unknown attribute intervalPresent. Type 'attr Drucker_check ?' for a detailed list.
PsnceDaemon already defined, delete it first
DS415_check: unknown attribute intervalPresent. Type 'attr DS415_check ?' for a detailed list.
DS920_check: unknown attribute intervalPresent. Type 'attr DS920_check ?' for a detailed list.
DELL_PC_check: unknown attribute intervalPresent. Type 'attr DELL_PC_check ?' for a detailed list.
ThinkPad_check: unknown attribute intervalPresent. Type 'attr ThinkPad_check ?' for a detailed list.
pi_check: unknown attribute intervalPresent. Type 'attr pi_check ?' for a detailed list.
raspberrypi3b_check: unknown attribute intervalPresent. Type 'attr raspberrypi3b_check ?' for a detailed list.
FB_Internet_check: unknown attribute intervalPresent. Type 'attr FB_Internet_check ?' for a detailed list.
Autosave deactivated
Das Attribut "intervalPresent" wird aber automatisch bei jedem Device hinzugefügt. Löschen hilft hier leider nicht.
Viele Grüße
Jürgen
Zitat von: juemuc am 05 März 2024, 12:20:56Hallo Jörg,
ich habe nach dem Umstieg nun doch Probleme. Habe zuerst alle pressence-Devices inkl Daemon gelöscht und dann neu mit Presence2 über defmod angelegt. Jetzt erhalte ich bei jedem Neustart
2024.03.05 12:06:49 1: Messages collected while initializing FHEM:configfile: Drucker_check: unknown attribute intervalPresent. Type 'attr Drucker_check ?' for a detailed list.
PsnceDaemon already defined, delete it first
DS415_check: unknown attribute intervalPresent. Type 'attr DS415_check ?' for a detailed list.
DS920_check: unknown attribute intervalPresent. Type 'attr DS920_check ?' for a detailed list.
DELL_PC_check: unknown attribute intervalPresent. Type 'attr DELL_PC_check ?' for a detailed list.
ThinkPad_check: unknown attribute intervalPresent. Type 'attr ThinkPad_check ?' for a detailed list.
pi_check: unknown attribute intervalPresent. Type 'attr pi_check ?' for a detailed list.
raspberrypi3b_check: unknown attribute intervalPresent. Type 'attr raspberrypi3b_check ?' for a detailed list.
FB_Internet_check: unknown attribute intervalPresent. Type 'attr FB_Internet_check ?' for a detailed list.
Autosave deactivated
Das Attribut "intervalPresent" wird aber automatisch bei jedem Device hinzugefügt. Löschen hilft hier leider nicht.
Viele Grüße
Jürgen
Hallo Jürgen,
ich habe das einmal beim Testen gehabt und konnte es danach nie wieder reproduzieren. Ich habe alles, was mit Presence2 zu tun hat gelöscht, Fhem runter gefahren und dann den RPi neu gestartet, um das Verhalten mit verbose 5 im global Device nochmal nachzustellen. Tja, RPi fährt hoch, Fhem steht zur Verfügung, defieren des ersten Presence2 Device und alles läuft. Danach habe ich es noch ein paar mal versucht den Fehler nachzustellen. Erfolglos.
Grüße Jörg
Hallo Jörg,
ich habe das gleiche Problem auch auf meinem Testsystem (Ubuntu als VM). Haben bei Dir die Devices bzw. der Daemon auch das Attribut "intervalPresent". Ich teste noch einmal. Wie kann ich prüfen, ob die Daemon-Task nicht mehr existiert?
Viele Grüße
Jürgen
Zitat von: juemuc am 05 März 2024, 12:31:10Hallo Jörg,
ich habe das gleiche Problem auch auf meinem Testsystem (Ubuntu als VM). Haben bei Dir die Devices bzw. der Daemon auch das Attribut "intervalPresent". Ich teste noch einmal. Wie kann ich prüfen, ob die Daemon-Task nicht mehr existiert?
Viele Grüße
Jürgen
Hallo Jürgen,
ich habe in meiner 99_myUtils folgende Sub hinterlegt:
###############################################################################
sub listInternalTimer(;$) {
my ($p) = @_;
$p ||= "";
my %cop;
foreach my $e (@intAtA)
{
my $name = "";
if (ref($e->{ARG}) eq "HASH")
{
if (exists($e->{ARG}{NAME}))
{
$name = $e->{ARG}{NAME};
}
elsif (exists($e->{ARG}{arg}))
{
$name = $e->{ARG}{arg};
}
}
elsif ((ref($e->{ARG}) eq "REF") && exists(${$e->{ARG}}->{hash}))
{
$name = ${$e->{ARG}}->{hash}{NAME};
}
elsif (ref($e->{ARG}) ne "REF")
{
$name = $e->{ARG};
}
my $time = strftime('%d.%m.%Y %H:%M:%S', localtime($e->{TRIGGERTIME}));
my $function = sprintf("%-25s %-25s", $name, $e->{FN});
my $line = "<td>".$e->{atNr}."</td><td>".$time."</td><td>".$function."</td>";
if ('f' eq $p)
{
$cop{$function} = $line;
}
elsif ('t' eq $p)
{
$cop{$time} = $line;
}
else
{
$cop{$name." ".$e->{atNr}} = $line;
}
}
my $ret = '<html><table width=50%>';
$ret .= "<td><b>InternalTimer List</b></td>";
$ret .= '</tr></tr>';
$ret .= "<td><b>Number</b></td>";
$ret .= "<td><b>Date/Time</b></td>";
$ret .= "<td><b>Function</b></td>";
$ret .= '</tr>';
foreach my $k (sort keys %cop) {
$ret .= "$cop{$k}";
$ret .= '</tr>';
}
$ret .= '</table></html>';
return $ret;
}
und folgenden WebLink definiert:
defmod TimerList weblink cmdList ge_blk_watch:Timer-Anzeigen:InternalTimer
attr TimerList room System
Für mich ist das dann oft hilfreich.
Grüße Jörg
Ich teste später damit.
Viele Grüße
Jürgen
wenn ihr das modul HMinfo nutzt, kann man dort auch alle timer mit dem cmd "get showTimer" sehen.
Hallo Frank,
danke für den Tipp. Aktuell habe ich das Modul noch nicht im Einsatz. Ich kann es aber im Testsystem einfach mal nutzen.
Viele Grüße
Jürgen
Hallo Jörg,
bei Deinem Hilfsmodul scheint noch etwas zu fehlen. Ich erhalte diese Meldung beim Aufruf des Weblinks:
Unknown command InternalTimer, try help. Die Definition lautet aber
sub listInternalTimer(;$) Muss ich das nur umbenennen?
Viele Grüße
Jürgen
Das HMInfo funktioniert wohl nur mit einem CUL, den ich nicht habe.
Zitat von: juemuc am 05 März 2024, 14:04:24Hallo Jörg,
bei Deinem Hilfsmodul scheint noch etwas zu fehlen. Ich erhalte diese Meldung beim Aufruf des Weblinks:
Unknown command InternalTimer, try help. Die Definition lautet aber
sub listInternalTimer(;$) Muss ich das nur umbenennen?
Viele Grüße
Jürgen
Das HMInfo funktioniert wohl nur mit einem CUL, den ich nicht habe.
Sorry, vergessen:
defmod InternalTimer cmdalias InternalTimer .* AS {{listInternalTimer()}}
attr InternalTimer alias InternalTimer
attr InternalTimer room System
Grüße Jörg
Hallo Jörg,
ich komme leider nicht weiter. Ich habe wieder alles gelöscht und das System komplett neu gestartet. Es waren keine Timer für den Daemon aktiv. Dann habe ich ein Device mit define neu angelegt. Hierbei werden sofort die beiden Attribute
attr DS415_check intervalNormal 1
attr DS415_check intervalPresent 1
angelegt. Eine Änderung über defmod ist nicht möglich. Es kommt die Fehlermeldung:
DS415_check: unknown attribute intervalPresent. Type 'attr DS415_check ?' for a detailed list.
Wenn ich das Attribut lösche, ist die Änderung temporär möglich.
Im log erhalte ich dadurch folgende Meldungen:
2024.03.05 15:02:49 1: Messages collected while initializing FHEM:configfile: DS415_check: unknown attribute intervalPresent. Type 'attr DS415_check ?' for a detailed list.
PsnceDaemon already defined, delete it first
Drucker_check: unknown attribute intervalPresent. Type 'attr Drucker_check ?' for a detailed list.
Autosave deactivated
und
2024.03.05 15:04:40 1: Timeout for PRESENCE2_doDaemonUnBlocking reached, terminated process 4134
2024.03.05 15:04:40 2: [PsnceDaemon | daemonAbortedScan.1083] - SIGNIFICANT:PRESENCE2 (PsnceDaemon) - scan aborted
Viele Grüße
Jürgen
Zitat von: juemuc am 05 März 2024, 15:08:01Hallo Jörg,
ich komme leider nicht weiter. Ich habe wieder alles gelöscht und das System komplett neu gestartet. Es waren keine Timer für den Daemon aktiv. Dann habe ich ein Device mit define neu angelegt. Hierbei werden sofort die beiden Attribute
Viele Grüße
Jürgen
Hallo Jürgen,
nimm bitte einmal die angehängte Version.
Grüße Jörg
Hallo Jörg,
danke für diese Version. Damit tritt der Fehler nicht mehr auf.
Viele Grüße
Jürgen
Zitat von: juemuc am 05 März 2024, 16:49:01Hallo Jörg,
danke für diese Version. Damit tritt der Fehler nicht mehr auf.
Viele Grüße
Jürgen
Hallo Jürgen,
danke für die Rückmeldung. Kommt dann auch morgen mit dem Update.
Grüße Jörg
Nach wie vor bekomme ich noch immer nur present oder error angezeigt, absent wird nicht angezeigt. Meldungen im Log gibt es nicht dazu.
Obwohl ich bereits mehrfach hier mit Code gepostet habe, bekam ich leider bisher keinerlei Antwort. Woran liegt das?
Zitat von: Invers am 06 März 2024, 14:28:55Nach wie vor bekomme ich noch immer nur present oder error angezeigt, absent wird nicht angezeigt. Meldungen im Log gibt es nicht dazu.
Obwohl ich bereits mehrfach hier mit Code gepostet habe, bekam ich leider bisher keinerlei Antwort. Woran liegt das?
Hallo,
nun ganz einfach. Ich bin berufstätig, habe eine Familie und Fhem ist mein Hobby. Und Deine Umgebung mit Bluetooth usw. habe ich nicht im Einsatz und muss die Zeit finden das entsprechend im Testsystem aufzubauen. Und, ich entscheide auch, woran ich Lust habe zu arbeiten.
Es ist jedem offen gestellt am Modul zu arbeiten. Es gibt aus meiner Sicht keine Exklusivrechte und auch keine Auftragsarbeit.
Grüße Jörg
Ich habe keinerlei Auftragsarbeit oder Exklusivrechte beansprucht.
Ich wollte lediglich auf meine vielen höflichen Hinweise eine kurze und höfliche Antwort erhalten, statt einfach ignoriert zu werden. "Keine Zeit" hätte da völlig ausgereicht.
Ich fühle mich etwas von dir angegriffen.
Wenn ein Modul veröffentlicht wurde und somit zur Nutzung für alle freigegeben ist, gehe ich davon aus, dass es das Betastadium verlassen hat.
Es kann immer mal vorkommen, dass etwas nicht funktioniert. Das melde ich dann als Fehler dem Modulautor, jedoch ohne jegliche Kritik an der Person. Bisher bin ich dafür noch von niemandem angegangen worden.
Du hast entschieden, das Modul zu entwickeln und somit auch die Verantwortung dafür übernommen. Ich erkenne hier kein Fehlverhalten meinerseits.
Da ich schon 70 bin, ist auch meine Zeit bemessen. Wieso ist also deine Zeit wertvoller, als meine?
Aber lassen wir das, es führt zu nichts.
Zitat von: Invers am 07 März 2024, 06:34:24Da ich schon 70 bin, ist auch meine Zeit bemessen. Wieso ist also deine Zeit wertvoller, als meine?
Hallo Invers,
werde ich als Opa nicht kommentieren.
Zitat von: Invers am 07 März 2024, 06:34:24Du hast entschieden, das Modul zu entwickeln und somit auch die Verantwortung dafür übernommen. Ich erkenne hier kein Fehlverhalten meinerseits.
Ich habe freundlicherweise das Modul in meine Obhut genommen und vorher lange genug in diesem Thread darum gebeten dieses verwaiste Modul zu testen.
Aber zurück zum Thema. Du schreibst, dass Du im Log nichts findest. Hast Du verbose sowohl im Dämon, als auch im Device auf verbose 5 gesetzt? Ein Log mit verbose 5 ist zwingende Voraussetzung für eine Fehlersuche.
PS: Bei verbose 5 erhältst Du in den Internals:
DEBUGLOG DEBUG Log kann hier eingesehen werden
Das habe ich jetzt in fast allen Modulen von mir eingebaut. Somit wird ein DebugLog in ein eigenes Log-File geschrieben und kann leichter für Fehlersuche bereit gestellt werden.
PS2:
Hast Du, wie in der commandRef beschrieben, das hcitool installiert? Habe gerade gesehen, dass es Bestandteil von Raspbian ist.
Grüße Jörg
Hallo,
ich habe jetzt bluetooth hinbekommen. Hat mich einen Tag gekostet.
hcitool wurde mit hcitool -i hci0 name $hash->{ADDRESS} aufgerufen. Bei abwesendem BT-Gerät brauchte der Aufruf zwischen 70 und 200 Sekunden. Hat etwas gedauewrt das rauszufinden
Ich rufe jetzt hcitool mit hcitool -i hci0 info $hash->{ADDRESS} auf. Das geht normalerweise ganz fix.
Aber. Ich hatte auch die Situation, wo es unendlich lange gedauert hat. Keine Ahnung warum, aber ich musste das BT_Device neu pairen und ein paar mal den RPi neu starten.
Ich habe jetzt zusätzlich das Attribut nonblockingTimeOut eingebaut. Damit kann man die Zeit verlängern, bis ein PRESENCE2 Dämon Prozess abgebrochen wird.
Angehängt findet ihr eine Version zum Testen.
Grüße Jörg
Zitat von: JoWiemann am 07 März 2024, 16:32:30Hallo,
ich habe jetzt bluetooth hinbekommen. Hat mich einen Tag gekostet.
hcitool wurde mit hcitool -i hci0 name $hash->{ADDRESS} aufgerufen. Bei abwesendem BT-Gerät brauchte der Aufruf zwischen 70 und 200 Sekunden. Hat etwas gedauewrt das rauszufinden
Ich rufe jetzt hcitool mit hcitool -i hci0 info $hash->{ADDRESS} auf. Das geht normalerweise ganz fix.
Aber. Ich hatte auch die Situation, wo es unendlich lange gedauert hat. Keine Ahnung warum, aber ich musste das BT_Device neu pairen und ein paar mal den RPi neu starten.
Ich habe jetzt zusätzlich das Attribut nonblockingTimeOut eingebaut. Damit kann man die Zeit verlängern, bis ein PRESENCE2 Device Prozess abgebrochen wird. Steht in jedem PRESENCE2 Device zur Verfügung.
Angehängt findet ihr eine Version zum Testen.
Grüße Jörg
Hallo Jörg,
Danke das Du das Modul in deine Obhut genommen hast.
Ich nutze die cover Version schon etwas länger und somit hat auch der Transfer auf PRESENCE2 funktioniert.
Was mir aber aufgefallen ist, der Speicher des PI den ich als Slave nutze wird auf Dauer gefüllt durch den presenced process. Also er nimmt immer mehr Hauptspeicher ein. Ich vermute das war schon vorher so. Ist jetzt nicht kritisch. Gebe das aber gerne mal hier an.
Sollte das irgendwann auf die Liste (also falls noch jemand davon betroffen wäre) springen kann ich auch gerne zusätzliche Infos bereistellen.
Freundliche Grüße
Mark
Zitat von: Newbee am 07 März 2024, 17:26:19Was mir aber aufgefallen ist, der Speicher des PI den ich als Slave nutze wird auf Dauer gefüllt durch den presenced process. Also er nimmt immer mehr Hauptspeicher ein. Ich vermute das war schon vorher so. Ist jetzt nicht kritisch. Gebe das aber gerne mal hier an.
Sollte das irgendwann auf die Liste (also falls noch jemand davon betroffen wäre) springen kann ich auch gerne zusätzliche Infos bereistellen.
Freundliche Grüße
Mark
Hallo Mark,
hm, habe ich bisher nicht beobachten können.
Grüße Jörg
Hallo Jörg,
ich habe zwar kein BT im Einsatz, aber trotzdem diese Version getestet. Ich könnte keine Auffälligkeiten feststellen. Lediglich in meinem Testsystem (Ubuntu-VM) kommt die Meldung
2024.03.07 19:40:55 1: Messages collected while initializing FHEM:configfile: PsnceDaemon already defined, delete it first
Autosave deactivated
Auf dem Produktiven System (PI3B) habe ich das Problem nicht. Du kannst das erst einmal ignorieren.
Viele Grüße
Jürgen
Danke für die Mühe.
Schade, leider funktioniert das so trotz der Änderungen noch nicht. Ich bekomme nun ausschließlich absent und laufende Logeinträge.
[pre]Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
Can't create connection: Operation not permitted
2024.03.08 06:54:10.717 3: [Handy_H | dbgLogInit.167] - BASIC:redirection debugLog: ./log/Handy_H_debugLog-%Y-%m.dlog started
2024.03.08 06:54:10.871 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:11.917 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:12.946 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:13.904 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:14.935 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:16.172 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:17.185 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:18.350 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:19.182 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:20.171 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:21.170 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:22.186 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:23.192 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:24.182 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:25.184 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:26.482 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:27.491 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:28.494 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:29.533 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:30.524 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:31.546 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:32.506 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:33.537 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:34.534 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:36.210 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:36.677 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:37.671 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:38.708 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:39.702 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:40.706 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:41.678 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:42.706 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:43.715 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:44.713 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:45.724 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:46.925 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:47.913 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:48.921 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:49.912 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:50.918 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:51.934 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:53.920 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:54.828 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:55.780 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:57.166 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:58.421 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.08 06:54:59.937 3: [PsnceDaemon | dbgLogInit.167] - BASIC:redirection debugLog: ./log/PsnceDaemon_debugLog-%Y-%m.dlog started
2024.03.08 06:55:00.096 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9[/pre]
Debuglog zeigt massig diese Meldungen:
[pre]2024.03.08 06:54:59.938 3:[PsnceDaemon | dbgLogInit.171] - BASIC:redirection debugLog: ./log/PsnceDaemon_debugLog-%Y-%m.dlog started
2024.03.08 06:55:00.027 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:01.102 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent
2024.03.08 06:55:01.125 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:01.354 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent
2024.03.08 06:55:02.340 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:02.528 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent
2024.03.08 06:55:03.356 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:03.544 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent
2024.03.08 06:55:04.360 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:04.566 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent
2024.03.08 06:55:05.375 4:[PsnceDaemon | daemonScanScheduler.1007] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.08 06:55:05.564 5:[PsnceDaemon | daemonScanReply.1095] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absent[/pre]
Verbose 5 war eingeschaltet.
Ich deaktiviere das Modul vorerst noch einmal, um meinLog zu schonen.
EDIT:
Ich nutze HCI Tool ver 5.55
Zitat von: Invers am 08 März 2024, 07:04:54Can't create connection: Operation not permitted
Hallo,
nun, die Rückmeldung kommt, wenn das Handy nicht korrekt am Bluetooth des RPi (oder was auch immer Du nutzt um Fhem zu betreiben) angemeldet ist. Das ist kein Problem des Moduls, sondern des RPi. Im Netz gibt es Empfehlungen nicht das Bluetooth Modul des RPi zu nutzen, da dies nicht sehr stabil läuft. Also besser ein USB Bluetooth Device.
Grüße Jörg
Ich nutze einen USB-Stick am Pi. Schon immer und das funktioniert bisher auch ausgezeichnet.
Mein Handy wird auch von alten Presence-Modul erkannt. Auch die Meldungen present und absent kommen dort normal. Presence funktioniert also, aber Presense2 nicht. Auch während Presence2 lief, funktiopnierte Presence perfekt (lief also parallel).Selbes Handy, selber Pi, selber Stick.
Vielleicht klappt aber parallel einfach nicht.
Obwohl deine Argumente logisch erscheinen, treffen sie hier wahrscheinlich nicht den Kern der Sache. Es sei denn, dass, wie ich bereits einige Beiträge zuvor erwähnte, ein Parallelbetrieb nicht funktioniert. Allerdings habe ich auch keine Idee, woran das liegen könnte.
Könnte es helfen, wenn ich mal mein normales Presence Modul und alle zugehörigen Definitionen löschen würde, oder bin ich da total auf dem Holzweg?
Ich werde morgen mein System kopieren und dort dann mal versuchsweise alles zu den Handys löschen. Ich berichte dann, ob es Auswirkungen hatte.
Bis dahin besten Dank für die Hilfe.
Zitat von: Invers am 08 März 2024, 18:40:42Ich nutze einen USB-Stick am Pi. Schon immer und das funktioniert bisher auch ausgezeichnet.
Mein Handy wird auch von alten Presence-Modul erkannt. Auch die Meldungen present und absent kommen dort normal. Presence funktioniert also, aber Presense2 nicht. Auch während Presence2 lief, funktiopnierte Presence perfekt (lief also parallel).Selbes Handy, selber Pi, selber Stick.
Hallo,
danke für die Info. Dann werde ich mal durch 73_PRESENCE.pm gehen und nachsehen, wie Bluetooth dort abgebildet ist.
Grüße Jörg
Zitat von: Invers am 08 März 2024, 18:40:42Mein Handy wird auch von alten Presence-Modul erkannt. Auch die Meldungen present und absent kommen dort normal.
Hallo,
hast Du im Presence-Modul das Attribut bluetoothHciDevice gesetzt? Das gibt es nämlich nicht in Presence2. Muss ich also nachrüsten.
Grüße Jörg
Hallo,
ich habe mal das Attribut bluetoothHciDevice eingebaut. Bei der Definition eines Present2 bluetooth Device werden alle bluetooth Schnittstellen ermittelt und als Auswahlliste im Attribut bluetoothHciDevice hinterlegt. Default ist hci0.
Grüße Jörg
Bewusst habe ich das nicht gesetzt. Kann erst morgen probieren.
define a51H PRESENCE local-bluetooth bc:7a:bf:08:22:e9 60 60
attr a51H userattr s_structure s_structure_map structexclude
attr a51H devStateIcon .*present:it_smartphone_7@gold .*:it_smartphone_7
attr a51H event-on-change-reading state
attr a51H group Anwesend
attr a51H room Anwesenheit
attr a51H s_structure Bewohnt
# ADDRESS bc:7a:bf:08:22:e9
# DEF local-bluetooth bc:7a:bf:08:22:e9 60 60
# FUUID 5f40d7c8-f33f-8098-1b21-eb5a3512dcdeab48
# INTERVAL_NORMAL 60
# INTERVAL_PRESENT 60
# MODE local-bluetooth
# NAME a51H
# NOTIFYDEV global
# NR 335
# NTFY_ORDER 50-a51H
# STATE present
# TYPE PRESENCE
# eventCount 58
# READINGS:
# 2024-02-27 07:42:49 PRESENCE2 present
# 2024-02-27 06:24:42 appearCnt 1
# 2024-03-08 22:10:20 device_name Galaxy-A51-von-Heinz
# 2024-02-27 06:24:42 lastAppear 2024-02-27 06:24:42
# 2024-03-08 06:52:27 model local-bluetooth
# 2024-03-08 22:10:20 presence present
# 2024-03-08 22:10:20 state present
# helper:
# CURRENT_STATE present
#
setstate a51H present
setstate a51H 2024-03-08 22:10:20 .absenceThresholdCounter 0
setstate a51H 2024-02-27 07:18:36 .associatedWith PsnceDaemon
setstate a51H 2024-03-08 22:10:20 .presenceThresholdCounter 0
setstate a51H 2024-02-27 07:42:49 PRESENCE2 present
setstate a51H 2024-02-27 06:24:42 appearCnt 1
setstate a51H 2024-03-08 22:10:20 device_name Galaxy-A51-von-Heinz
setstate a51H 2024-02-27 06:24:42 lastAppear 2024-02-27 06:24:42
setstate a51H 2024-03-08 06:52:27 model local-bluetooth
setstate a51H 2024-03-08 22:10:20 presence present
setstate a51H 2024-03-08 22:10:20 state present
Danke, hab nun getestet, aber ohne greifbaren Erfolg. Das Attribut lässt sich weder eingeben, noch auswählen. Es erfolgt immer eine Meldung:
Befehl - set PsnceDaemon bluetoothHciDevice hci0
Antwort - Unknown (http://fhem3:8083/fhem?detail=Unknown) argument bluetoothHciDevice, choose one of clearCounts killChilds
Auswahl über Menü - kam immer, dass dieses Attr. nur für Bluetooth ist. Nun ist das Attribut auch aus der Auswahlliste verschwunden. Vielleicht wäre es nach dem Neustart des Pi wieder da, hab ich aber nicht gemacht.
In einem anderen Modul (btlesense) für meinen Pflanzendetektor funktioniert es.
[pre]2024.03.09 05:39:15.276 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted[/pre]DEBUG:
[pre]2024.03.09 05:53:55.529 4:[PsnceDaemon | daemonScanScheduler.1092] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.09 05:53:55.715 5:[PsnceDaemon | daemonScanReply.1180] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absen[/pre]
Zitat von: Invers am 09 März 2024, 05:58:47Danke, hab nun getestet, aber ohne greifbaren Erfolg. Das Attribut lässt sich weder eingeben, noch auswählen. Es erfolgt immer eine Meldung:
Befehl - set PsnceDaemon bluetoothHciDevice hci0
Antwort - Unknown (http://fhem3:8083/fhem?detail=Unknown) argument bluetoothHciDevice, choose one of clearCounts killChilds
Auswahl über Menü - kam immer, dass dieses Attr. nur für Bluetooth ist. Nun ist das Attribut auch aus der Auswahlliste verschwunden. Vielleicht wäre es nach dem Neustart des Pi wieder da, hab ich aber nicht gemacht.
In einem anderen Modul (btlesense) für meinen Pflanzendetektor funktioniert es.
[pre]2024.03.09 05:39:15.276 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted[/pre]DEBUG:
[pre]2024.03.09 05:53:55.529 4:[PsnceDaemon | daemonScanScheduler.1092] - EXPANDED:PRESENCE2_doDaemonUnBlocking:
PsnceDaemon#Handy_H
2024.03.09 05:53:55.715 5:[PsnceDaemon | daemonScanReply.1180] - DEBUG:PRESENCE2 (PsnceDaemon) - , duration:0 reply:
Handy_H|absen[/pre]
Hallo,
der Daemon verwaltet die Devices, deswegen macht der Befehl - set PsnceDaemon bluetoothHciDevice hci0 - keinen Sinn. Steht aber auch in der Commander, dass das Attribut nur für Devices vom Typ bluetooth funktioniert.
Grüße Jörg
PS: könntest Du mir ein Log mit verbose 5 für ein funktionierendes Presence Device generieren. Dass würde weiter helfen.
Sorry, ist wohl nicht mein Tag.
Antwort erst jetzt, weil ich mir heute das linke Handgelenk gebrochen habe. OP ist noch fällig, also böse gebrochen.
Fehler bleibt. absent.
2024.03.09 13:42:18.382 5:[Handy_H | doDaemonEntityScan.1237] - DEBUG:PRESENCE2 (Handy_H) - result:absent
########command>hcitool -i hci0 info bc:7a:bf:08:22:e9
########reply >Requesting information ...
2024.03.09 13:42:38.376 5:[Handy_H | doDaemonEntityScan.1237] - DEBUG:PRESENCE2 (Handy_H) - result:absent
########command>hcitool -i hci0 info bc:7a:bf:08:22:e9
########reply >Requesting information ...
2024.03.09 13:41:58.310 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:42:18.321 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:42:38.322 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:42:58.366 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:43:18.467 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:43:38.498 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:43:58.484 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
2024.03.09 13:44:18.454 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9
Can't create connection: Operation not permitted
Zitat von: Invers am 09 März 2024, 13:53:47Sorry, ist wohl nicht mein Tag.
Antwort erst jetzt, weil ich mir heute das linke Handgelenk gebrochen habe. OP ist noch fällig, also böse gebrochen.
Ach du Schei...
Ich wünsche Dir eine erfolgreiche OP und gute Besserung.
Grüße Jörg
Hallo,
ich nutze bisher das Modul PREESENCE und wollte heute wegen der genannten Vorteile (hatte immer wieder den Eindruck, dass FHEM stehen bleibt oder sehr langsam ist) auf das Modul PRESENCE2 wechseln. Habe für ein Handy die Definitionen angelegt
Da Android eine Funktion mit der FritzBox
Internals:
DEBUGLOG OFF
DEF function cmd:{checkAllFritzMACpresent("XX:XX:XX:XX:XX:XX")} scan:1
FUUID 65edc4da-f33f-d125-9fdc-9b1997bcd33f523b
MODE function
NAME Handy_Petra2
NOTIFYDEV global
NR 399
NTFY_ORDER 50-Handy_Petra2
STATE present
TYPE PRESENCE2
VERSION 01.01a
eventCount 1
READINGS:
2024-03-10 15:34:02 PRESENCE2 present
2024-03-10 15:34:02 appearCnt 1
2024-03-10 15:34:02 lastAppear 2024-03-10 15:34:02
2024-03-10 15:54:12 maybeCnt 1
2024-03-10 15:54:08 model function
2024-03-10 15:54:12 presence maybe present
2024-03-10 15:34:02 state present
2024-03-10 15:54:12 thresHldCnt 1
helper:
DISABLED 0
FhemLog3Std 0
curState init
debugLog Handy_Petra2_debugLog
logDebug
maybe 1
nextScan 1710082482.6372
cnt:
exec 1
maybe 1
state 0
th 1
disp:
condense 1
verbose 0
interval:
absent 1
init 30
present 1
os:
Cmd {checkAllFritzMACpresent("XX:XX:XX:XX:XX:XX")}
search 1
Attributes:
intervalNormal 1
intervalPresent 1
room 9.5_Anwesenheit
thresholdAbsence 2
userattr Petra_Device Petra_Device_map structexclude
und ein lan-ping:
Internals:
ADDRESS 192.168.178.95
DEBUGLOG OFF
DEF lan-ping 192.168.178.95
FUUID 65edc2c3-f33f-d125-e98d-822c7d14f24f5f9f
MODE lan-ping
NAME Handy_Petra2_LP
NOTIFYDEV global
NR 398
NTFY_ORDER 50-Handy_Petra2_LP
STATE present
TYPE PRESENCE2
VERSION 01.01a
READINGS:
2024-03-10 15:34:02 PRESENCE2 maybe present
2024-03-10 15:25:07 appearCnt 1
2024-03-10 15:25:07 lastAppear 2024-03-10 15:25:07
2024-03-10 15:54:12 maybeCnt 1
2024-03-10 15:54:08 model lan-ping
2024-03-10 15:54:12 presence maybe present
2024-03-10 15:25:07 state present
2024-03-10 15:54:12 thresHldCnt 1
helper:
DISABLED 0
FhemLog3Std 0
curState init
debugLog Handy_Petra2_LP_debugLog
logDebug
maybe 1
nextScan 1710082482.6372
cnt:
exec 1
maybe 1
state 0
th 1
disp:
condense 1
verbose 0
interval:
absent 1
init 30
present 1
os:
Cmd ping -c 1 -w 1 192.168.178.95 2>&1
search (ttl|TTL)=\d+
Attributes:
event-on-change-reading state
intervalNormal 1
intervalPresent 1
room 9.5_Anwesenheit
thresholdAbsence 2
userattr Petra_Anwesend Petra_Anwesend_map Petra_Device Petra_Device_map structexclude
Die entsprechenden define (Handy_Petra, Handy_Petra_LP) mit dem Modul PRESENCE habe ich disabled. Die Rückmeldung aus Function und lan-ping fasse ich in einer Struktur zusammen, mit der ich dann in weiteren Modulen (RESIDENTS) arbeite.
Beim Neustart (habe gleichzeitig ein Update von FHEM gemacht) erhalte ich folgende Meldungen im Log und die Stati des Handys werden nicht aktualisiert:
2024.03.10 15:54:12.642 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/73_PRESENCE2.pm line 1201.
2024.03.10 15:54:12.642 1: ERROR: empty name in readingsBeginUpdate
2024.03.10 15:54:12.642 1: stacktrace:
2024.03.10 15:54:12.642 1: main::readingsBeginUpdate called by ./FHEM/73_PRESENCE2.pm (1203)
2024.03.10 15:54:12.643 1: main::PRESENCE2_doEvtCheckReply called by ./FHEM/73_PRESENCE2.pm (1195)
2024.03.10 15:54:12.643 1: main::PRESENCE2_doEvtCheck called by ./FHEM/73_PRESENCE2.pm (984)
2024.03.10 15:54:12.643 1: main::PRESENCE2_daemonScanScheduler called by fhem.pl (3508)
2024.03.10 15:54:12.643 1: main::HandleTimeout called by fhem.pl (707)
2024.03.10 15:54:12.643 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 988.
2024.03.10 15:54:12.643 1: PERL WARNING: Use of uninitialized value $hash in hash element at ./FHEM/73_PRESENCE2.pm line 58.
2024.03.10 15:54:12.643 1: PERL WARNING: Use of uninitialized value $instName in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 74.
2024.03.10 15:54:12.643 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/73_PRESENCE2.pm line 990.
Wiederholende Meldungen:
2024.03.10 15:54:12.793 1: ERROR: empty name in readingsBeginUpdate
2024.03.10 15:54:12.793 1: stacktrace:
2024.03.10 15:54:12.793 1: main::readingsBeginUpdate called by ./FHEM/73_PRESENCE2.pm (1036)
2024.03.10 15:54:12.793 1: main::PRESENCE2_daemonScanReply called by (eval 855) (1)
2024.03.10 15:54:12.793 1: (eval) called by fhem.pl (1177)
2024.03.10 15:54:12.793 1: main::AnalyzePerlCommand called by fhem.pl (1206)
2024.03.10 15:54:12.793 1: main::AnalyzeCommand called by fhem.pl (1133)
2024.03.10 15:54:12.793 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (263)
2024.03.10 15:54:12.793 1: main::telnet_Read called by fhem.pl (3985)
2024.03.10 15:54:12.793 1: main::CallFn called by fhem.pl (786)
Regelmäßig werden dann diese Meldungen ins Log geschrieben:
2024.03.10 16:01:12.651 1: ERROR: empty name in readingsBeginUpdate
2024.03.10 16:01:12.652 1: stacktrace:
2024.03.10 16:01:12.652 1: main::readingsBeginUpdate called by fhem.pl (5189)
2024.03.10 16:01:12.652 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE2.pm (968)
2024.03.10 16:01:12.652 1: main::PRESENCE2_daemonScanScheduler called by fhem.pl (3508)
2024.03.10 16:01:12.652 1: main::HandleTimeout called by fhem.pl (707)
2024.03.10 16:01:12.652 1: readingsUpdate(,daemonSkipCnt,1) missed to call readingsBeginUpdate first.
2024.03.10 16:01:12.652 1: stacktrace:
2024.03.10 16:01:12.652 1: main::readingsBulkUpdate called by fhem.pl (5190)
2024.03.10 16:01:12.652 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE2.pm (968)
2024.03.10 16:01:12.652 1: main::PRESENCE2_daemonScanScheduler called by fhem.pl (3508)
2024.03.10 16:01:12.652 1: main::HandleTimeout called by fhem.pl (707)
2024.03.10 16:01:42.652 1: ERROR: empty name in readingsBeginUpdate
2024.03.10 16:01:42.652 1: stacktrace:
2024.03.10 16:01:42.652 1: main::readingsBeginUpdate called by fhem.pl (5189)
2024.03.10 16:01:42.652 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE2.pm (968)
2024.03.10 16:01:42.652 1: main::PRESENCE2_daemonScanScheduler called by fhem.pl (3508)
2024.03.10 16:01:42.652 1: main::HandleTimeout called by fhem.pl (707)
2024.03.10 16:01:42.652 1: readingsUpdate(,daemonSkipCnt,1) missed to call readingsBeginUpdate first.
2024.03.10 16:01:42.652 1: stacktrace:
2024.03.10 16:01:42.652 1: main::readingsBulkUpdate called by fhem.pl (5190)
2024.03.10 16:01:42.652 1: main::readingsSingleUpdate called by ./FHEM/73_PRESENCE2.pm (968)
2024.03.10 16:01:42.653 1: main::PRESENCE2_daemonScanScheduler called by fhem.pl (3508)
2024.03.10 16:01:42.653 1: main::HandleTimeout called by fhem.pl (707)
Zusatzinfo: Ich hatte es auch so verstanden, dass ein Daemon on PRESENCE2 angelegt werden würde. Ich habe zwar den Daemon von PRESENCE, aber in dem erscheinen die 2 neu angelegten Device Handy_Petra2 und Handy_Petra2_LP nicht und ein neuer Daemon wurde nicht angelegt.
Zusatzinfo2: Nachdem trotz Disable die Meldungen immer noch ins Log geschrieben wurden, habe ich beide Device gelöscht. Leider werden die Meldungen immer noch ins Log geschrieben.
Erst nach einem Neustart von FHEM blieben die Meldungen im Log aus.
Wie löse ich das Problem?
Grüße Jürgen
Zitat von: bmwfan am 10 März 2024, 16:19:53Zusatzinfo: Ich hatte es auch so verstanden, dass ein Daemon on PRESENCE2 angelegt werden würde. Ich habe zwar den Daemon von PRESENCE, aber in dem erscheinen die 2 neu angelegten Device Handy_Petra2 und Handy_Petra2_LP nicht und ein neuer Daemon wurde nicht angelegt.
Zusatzinfo2: Nachdem trotz Disable die Meldungen immer noch ins Log geschrieben wurden, habe ich beide Device gelöscht. Leider werden die Meldungen immer noch ins Log geschrieben.
Erst nach einem Neustart von FHEM blieben die Meldungen im Log aus.
Wie löse ich das Problem?
Grüße Jürgen
Hallo Jürgen,
ich habe bisher nicht herausgefunden, wieso es, ab und zu, zu diesem Verhalten kommt. Auch konnte ich selber dieses Verhalten bisher nicht nach stellen.
Meistens hilft es alle PRESENCE2 Devices, auch das Device PsnceDaemon, zu löschen. Danach dann einen Neustart von Fhem durchführen.
Grüße Jörg
Hallo Jo,
habe alle PRESENCE-Device löschen müssen, damit ich den Daemon löschen konnte. Dann Neustart und alle Device wieder als PRESENCE2 angelegt. Jetzt kommen die Fehlermeldungen nicht mehr.
Danke für die Unterstützung.
Bin gespannt, ob das Verhalten jetzt besser wird.
P.S.: Eine Anmerkung zur Doku: Als ich zufällig auf PRESENCE2 gestossen bin, habe ich nur anhand der Beiträge im Thread "erahnen" können, was die Unterschiede sind. Auch in der commandref (so weit ich das beurteilen kann) sind die Module gleich beschrieben. Das ist schon etwas verwirrend für User wie mich, die sich nur rudimentär mit FHEM auskennen und nur bestehende Codes oder Beispiele nutzen / verändern. Ich vermute (und hoffe), dass die Verzögerungen in FHEM, die ich immer wieder beobachte aber deren Ursache ich nie bestimmen konnte, jetzt besser werden. Vielleicht wäre es möglich, im PRESENCE-Wiki eine Erklärung einzubringen oder ein PRESENCE1-Wiki, nur mit einer Beschreibung der Unterschiede, zu verfassen?
Hallo Jörg,
ich glaube, ich habe die Ursache für die Fehlermeldung
2024.03.07 19:40:55 1: Messages collected while initializing FHEM:configfile: PsnceDaemon already defined, delete it first
Autosave deactivatedgefunden.
In diesem Fall steht in der fhem.cfg das Device PsnceDaemon nach dem ersten Presence2-Device.
define Drucker_check PRESENCE2 lan-ping HL-2370DN
setuuid Drucker_check 65ee1f40-f33f-4c73-f42e-fd6f2b87dd616e03
attr Drucker_check alias HL-2370DN
attr Drucker_check devStateIcon present:remotecontrol/black_btn_GREEN absent:remotecontrol/black_btn_RED
attr Drucker_check devStateStyle style="text-align:right"
attr Drucker_check event-on-change-reading .*
attr Drucker_check group Drucker
attr Drucker_check icon it_printer@black
attr Drucker_check intervalNormal 1
attr Drucker_check intervalPresent 1
attr Drucker_check room Büro,Statuszentrale
define PsnceDaemon PRESENCE2 daemon daemon
setuuid PsnceDaemon 65ee1f40-f33f-4c73-4654-1a1a257de2a619a7
attr PsnceDaemon intervalNormal 1
Eventuell kannst Du das Problem nun mit dieser Info lösen.
Ich habe nun die fhem.cfg manuell korrigiert und die Fehlemeldung ist weg ;D
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 11:31:19Hallo Jörg,
ich glaube, ich habe die Ursache für die Fehlermeldung
2024.03.07 19:40:55 1: Messages collected while initializing FHEM:configfile: PsnceDaemon already defined, delete it first
Autosave deactivatedgefunden.
In diesem Fall steht in der fhem.cfg das Device PsnceDaemon nach dem ersten Presence2-Device.
define Drucker_check PRESENCE2 lan-ping HL-2370DN
setuuid Drucker_check 65ee1f40-f33f-4c73-f42e-fd6f2b87dd616e03
attr Drucker_check alias HL-2370DN
attr Drucker_check devStateIcon present:remotecontrol/black_btn_GREEN absent:remotecontrol/black_btn_RED
attr Drucker_check devStateStyle style="text-align:right"
attr Drucker_check event-on-change-reading .*
attr Drucker_check group Drucker
attr Drucker_check icon it_printer@black
attr Drucker_check intervalNormal 1
attr Drucker_check intervalPresent 1
attr Drucker_check room Büro,Statuszentrale
define PsnceDaemon PRESENCE2 daemon daemon
setuuid PsnceDaemon 65ee1f40-f33f-4c73-4654-1a1a257de2a619a7
attr PsnceDaemon intervalNormal 1
Eventuell kannst Du das Problem nun mit dieser Info lösen.
Ich habe nun die fhem.cfg manuell korrigiert und die Fehlemeldung ist weg ;D
Viele Grüße
Jürgen
Hallo Jürgen,
vielen Dank für die Information. Da muss man erst einmal drauf kommen. Ich werde mir also etwas überlegen.
Grüße Jörg
Zitat von: juemuc am 11 März 2024, 11:31:19Hallo Jörg,
ich glaube, ich habe die Ursache für die Fehlermeldung
2024.03.07 19:40:55 1: Messages collected while initializing FHEM:configfile: PsnceDaemon already defined, delete it first
Autosave deactivatedgefunden.
In diesem Fall steht in der fhem.cfg das Device PsnceDaemon nach dem ersten Presence2-Device.
define Drucker_check PRESENCE2 lan-ping HL-2370DN
setuuid Drucker_check 65ee1f40-f33f-4c73-f42e-fd6f2b87dd616e03
attr Drucker_check alias HL-2370DN
attr Drucker_check devStateIcon present:remotecontrol/black_btn_GREEN absent:remotecontrol/black_btn_RED
attr Drucker_check devStateStyle style="text-align:right"
attr Drucker_check event-on-change-reading .*
attr Drucker_check group Drucker
attr Drucker_check icon it_printer@black
attr Drucker_check intervalNormal 1
attr Drucker_check intervalPresent 1
attr Drucker_check room Büro,Statuszentrale
define PsnceDaemon PRESENCE2 daemon daemon
setuuid PsnceDaemon 65ee1f40-f33f-4c73-4654-1a1a257de2a619a7
attr PsnceDaemon intervalNormal 1
Eventuell kannst Du das Problem nun mit dieser Info lösen.
Ich habe nun die fhem.cfg manuell korrigiert und die Fehlemeldung ist weg ;D
Viele Grüße
Jürgen
Hallo Jürgen,
ich habe jetzt einiges im Modul im Bereich define und Neustart Fhem geändert.
Wenn Du einmal testen mags findest Du eine neue Version im Anhang.
Grüße Jörg
Hallo Jörg,
wenn Du den Anhang noch anhängst, teste ich gerne O:-)
Viele Grüße
Jürgen
Zitat von: juemuc am 15 März 2024, 17:05:44Hallo Jörg,
wenn Du den Anhang noch anhängst, teste ich gerne O:-)
Viele Grüße
Jürgen
Hallo Jürgen,
vergessen den Hochladen Button zu drücken :(
Grüße Jörg
Hallo Jörg,
ich habe nun folgende Meldungen im logfile:
2024.03.15 21:50:56 2: [PsnceDaemon | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [Drucker_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DS415_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DS920_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DELL_PC_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [ThinkPad_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [pi_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [raspberrypi3b_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [FB_Internet_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial dbgLogInit
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial updateConfig PsnceDaemon.Initialize
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: one daemon found: PsnceDaemon
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: using daemon: PsnceDaemon
und
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
Es funktioniert bei mir alles.
Ich habe FHEM gestopt, die Datei kopiert und FHEM wieder gestartet.
Viele Grüße
Jürgen
Zitat von: juemuc am 15 März 2024, 21:56:03Hallo Jörg,
ich habe nun folgende Meldungen im logfile:
2024.03.15 21:50:56 2: [PsnceDaemon | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [Drucker_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DS415_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DS920_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [DELL_PC_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [ThinkPad_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [pi_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [raspberrypi3b_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: [FB_Internet_check | Define.412] - SIGNIFICANT:define gaceful done
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial dbgLogInit
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: starting initial updateConfig PsnceDaemon.Initialize
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: one daemon found: PsnceDaemon
2024.03.15 21:50:56 2: PRESENCE2 - PsnceDaemon: using daemon: PsnceDaemon
und
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
2024.03.15 21:53:11 2: PRESENCE2 - PsnceDaemon: starting initial Config
Es funktioniert bei mir alles.
Ich habe FHEM gestopt, die Datei kopiert und FHEM wieder gestartet.
Viele Grüße
Jürgen
Hallo Jürgen,
die Log-Einträge sehen gut aus. Wenn ich die neue Version bereit stelle, dann setze ich das Verbose noch hoch.
Grüße Jörg
Hallo,
ich habe jetzt für das lokale Bluetooth die Logik von 73_PRESENCE.pm übernommen. Anbei eine neue Version zum Testen. Schön wäre auch lokales Bluetooth mit Bluetooth USB Stick.
Grüße Jörg
Danke.Kann leider nicht testen. Bin immernoch im Krankenhaus. OP wird laufend verschoben. Werde wohl noch 3 Tage brauchen.
Zitat von: Invers am 16 März 2024, 13:03:36Danke.Kann leider nicht testen. Bin immernoch im Krankenhaus. OP wird laufend verschoben. Werde wohl noch 3 Tage brauchen.
Hallo,
liest sich nicht so schön. Ich wünsche Dir weiterhin gute Genesung.
Liebe Grüße
Jörg
Man kanns kaum glauben, ich bin wieder zu Hause.
Hab getestet.
Handy unter presence korrekt, aber unter presence2 leider noch immer nur absent.
Log:
[pre]2024.03.18 19:21:40.485 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9 2>/dev/null
2024.03.18 19:21:40.596 5: PRESENCE2 (Handy_H) - result:absent
########command>hcitool -i hci0 info bc:7a:bf:08:22:e9 2>/dev/null
########reply >Requesting information ...
2024.03.18 19:22:00.490 5: Handy_H calling - hcitool -i hci0 info bc:7a:bf:08:22:e9 2>/dev/null
2024.03.18 19:22:00.606 5: PRESENCE2 (Handy_H) - result:absent
########command>hcitool -i hci0 info bc:7a:bf:08:22:e9 2>/dev/null
########reply >Requesting information ...[/pre]debuglog
[pre]2024.03.10 06:08:14.001 5:[Handy_H | lanBtWrite.917] - DEBUG:PRESENCE2 (Handy_H) - write ignored - no FD: stop
2024.03.11 08:02:01.694 3:[Handy_H | dbgLogInit.171] - BASIC:redirection debugLog: ./log/Handy_H_debugLog-%Y-%m.dlog started
2024.03.11 13:46:21.734 3:[Handy_H | dbgLogInit.171] - BASIC:redirection debugLog: ./log/Handy_H_debugLog-%Y-%m.dlog started
2024.03.18 19:16:53.235 4:[Handy_H | ProcessState.1082] - EXPANDED:PRESENCE2 (Handy_H) - chang from init to absent
2024.03.18 19:18:02.747 5:[Handy_H | Set.555] - DEBUG:PRESENCE2 (Handy_H) - starting local scan
2024.03.18 19:20:33.698 3:[Handy_H | dbgLogInit.171] - BASIC:redirection debugLog: ./log/Handy_H_debugLog-%Y-%m.dlog started
2024.03.18 19:21:06.344 4:[Handy_H | ProcessState.1082] - EXPANDED:PRESENCE2 (Handy_H) - chang from init to absent[/pre]
Pi Neustart ist vorher erfolgt.
Sorry, bisschen kurz, aber bin vorläufig behindert wegen OP 7 mal über 2 Tage verschoben LOL).
Zitat von: Invers am 18 März 2024, 19:28:41Man kanns kaum glauben, ich bin wieder zu Hause.
Sorry, bisschen kurz, aber bin vorläufig behindert wegen OP 7 mal über 2 Tage verschoben LOL).
Das ist ja super. Freut mich für Dich.
Mir würde echt ein Log mit verbose 5 von einem PRESENCE, ich nenn es mal 1, Device weiter helfen.
Danke und Grüße Jörg
einmal bt aus und dann wieder eingeschaltet.
[pre]2024.03.18 20:21:32.925 5: PRESENCE (a51H) - stopping timer
2024.03.18 20:21:32.929 5: PRESENCE (a51H) - starting blocking call for mode local-bluetooth
2024.03.18 20:21:33.010 5: PRESENCE (a51H) - starting bluetooth scan: a51H|bc:7a:bf:08:22:e9|0|
2024.03.18 20:21:33.069 5: PRESENCE (a51H) - found standard variant of ps command, using "ax" as parameter
2024.03.18 20:21:33.071 4: PRESENCE (a51H) - executing: which hcitool
2024.03.18 20:21:33.119 4: PRESENCE (a51H) - 'which hcitool' returns: /usr/bin/hcitool
2024.03.18 20:21:33.187 5: PRESENCE (a51H) - executing: hcitool name bc:7a:bf:08:22:e9
2024.03.18 20:21:38.399 4: PRESENCE (a51H) - hcitool returned:
2024.03.18 20:21:38.410 5: PRESENCE (a51H) - blocking scan result: a51H|0|absent
2024.03.18 20:21:38.471 4: PRESENCE (a51H) - rescheduling next check in 60 seconds
2024.03.18 20:22:38.474 5: PRESENCE (a51H) - stopping timer
2024.03.18 20:22:38.477 5: PRESENCE (a51H) - starting blocking call for mode local-bluetooth
2024.03.18 20:22:38.545 5: PRESENCE (a51H) - starting bluetooth scan: a51H|bc:7a:bf:08:22:e9|0|
2024.03.18 20:22:38.608 5: PRESENCE (a51H) - found standard variant of ps command, using "ax" as parameter
2024.03.18 20:22:38.609 4: PRESENCE (a51H) - executing: which hcitool
2024.03.18 20:22:38.662 4: PRESENCE (a51H) - 'which hcitool' returns: /usr/bin/hcitool
2024.03.18 20:22:38.744 5: PRESENCE (a51H) - executing: hcitool name bc:7a:bf:08:22:e9
2024.03.18 20:22:39.534 4: PRESENCE (a51H) - hcitool returned: Galaxy-A51-von-Heinz
2024.03.18 20:22:39.550 5: PRESENCE (a51H) - blocking scan result: a51H|0|present|Galaxy-A51-von-Heinz
2024.03.18 20:22:39.598 4: PRESENCE (a51H) - rescheduling next check in 60 seconds[/pre]
Zitat von: Invers am 18 März 2024, 20:23:40einmal bt aus und dann wieder eingeschaltet.
Danke, dass hilft mir weiter.
Würdest Du bei PRESENCE2 das Attribut bluetoothHciDevice bitte löschen, sofern gesetzt. Wenn Du das Attribut nicht gesetzt hast, dann hast Du leider nicht letzte Version von hier: https://forum.fhem.de/index.php?msg=1307399 installiert.
Danke und Grüße Jörg
Ich habe das Attr. nun gelöscht. Die richtige Version hatte ich bereits gestern installiert.
Handy bleibt absent.
[pre]2024.03.19 08:59:58.364 5: Handy_H calling - hcitool info bc:7a:bf:08:22:e9 2>/dev/null
2024.03.19 08:59:58.476 5: PRESENCE2 (Handy_H) - result:absent
########command>hcitool info bc:7a:bf:08:22:e9 2>/dev/null
########reply >Requesting information ...[/pre]
Zitat von: Invers am 19 März 2024, 09:06:06Ich habe das Attr. nun gelöscht. Die richtige Version hatte ich bereits gestern installiert.
Handy bleibt absent.
[pre]2024.03.19 08:59:58.364 5: Handy_H calling - hcitool info bc:7a:bf:08:22:e9 2>/dev/null
2024.03.19 08:59:58.476 5: PRESENCE2 (Handy_H) - result:absent
########command>hcitool info bc:7a:bf:08:22:e9 2>/dev/null
########reply >Requesting information ...[/pre]
Hallo,
würdest Du bitte einmal in der Linux Kommandozeile
hcitool info bc:7a:bf:08:22:e9 und
hcitool name bc:7a:bf:08:22:e9 aufrufen und mir das Ergebnis posten. Bitte jeweils einmal mit eingelogtem und ausgelogtem Handy. Danke Dir
Grüße Jörg
Hallo,
ok, ich habe noch einen Fehler bei bluetooth gefunden.
Außerdem gibt es noch das neue Attribut: hcitoolParam
(Nur im Modus "bluetooth" anwendbar, nicht für das Daemon Device)
set <name> hcitoolParam <name|info>
Auswahl über welchen Paramter das hcitool ein verbundenes BlueTooth-Device erkennen soll
Grüße Jörg
Zitat von: JoWiemann am 21 März 2024, 11:37:52Hallo,
ok, ich habe noch einen Fehler bei bluetooth gefunden.
Außerdem gibt es noch das neue Attribut: hcitoolParam
(Nur im Modus "bluetooth" anwendbar, nicht für das Daemon Device)
set <name> hcitoolParam <name|info>
Auswahl über welchen Paramter das hcitool ein verbundenes BlueTooth-Device erkennen soll
Grüße Jörg
Super!!!! Danke !!!!
Funktioniert nun offenbar. Attribut mit name funktioniert, mit info funktioniert nicht.
pi@fhem3:/opt/fhem $ hcitool info bc:7a:bf:08:22:e9
Requesting information ...
Can't create connection: Operation not permitted
pi@fhem3:/opt/fhem $ hcitool name bc:7a:bf:08:22:e9
Galaxy-A51-von-HeinzSorry, kann nicht viel schreiben. Hoffe, war nicht mein Fehler.
Nochmals vielen Dank.
Zitat von: Invers am 21 März 2024, 18:00:52Sorry, kann nicht viel schreiben. Hoffe, war nicht mein Fehler.
Nochmals vielen Dank.
Hallo,
danke für die positive Rückmeldung. Dann geht die Version morgen ins SVN.
Grüße Jörg
Hallo Jörg,
ich habe nachdem ich einen Rechner neu aufgesetzt habe diese Meldung im Logfile:
2024.04.10 19:43:16.677 1: PERL WARNING: Can't exec "hcitool": Datei oder Verzeichnis nicht gefunden at ./FHEM/73_PRESENCE2.pm line 290, <$fh> line 3985.
2024.04.10 19:43:16.681 2: [FB_Internet_check | Define.433] - SIGNIFICANT:define gaceful done
Welches Modul muss ich noch installieren?
Viele Grüße
Jürgen
Hallo Jürgen,
welchen PC und welches Betriebssystem?
Grüße Jörg
Hallo Jörg,
ich nutze aktuell einen Lenovo ThinkCenter mit Debian 12.
Viele Grüße
Jürgen
Hallo Jürgen,
Du musst hcitool nach installieren. Das ist wohl in Debian 12 nicht vorhanden. In der cammandRef im Modul ist ein Link hinterlegt. Ich kann gerade nicht nach sehen.
Grüße Jörg
Hallo Jörg,
habe es gefunden. Ich musste nur mit sudo apt install bluez das hcitool installieren.
Viele Grüße
Jürgen
Hallo Leute,
wahrscheinlich lacht ihr mich jetzt aus, aber was bedeutet bitte der Log-Eintrag
define gaceful done
Gruß Robert
Zitat von: bertl am 08 Mai 2024, 19:16:08Hallo Leute,
wahrscheinlich lacht ihr mich jetzt aus, aber was bedeutet bitte der Log-Eintrag
define gaceful done
Gruß Robert
Hallo Robert, soll wohl gracefully sein. Die Definition wurde würdig durchgeführt. Hat doch was.
Grüße Jörg
Zitat von: JoWiemann am 08 Mai 2024, 19:47:52soll wohl gracefully sein
Dacht ich mir schon :)
Beim nächsten Update bitte einfach das 'r' ergänzen ;)
Gruß Robert