FHEM Forum

Hallo fhem Gemeinde,

ich beiße mir im Verständnis um structs die Zähne aus. Irgendwie will das nicht so, wie mir das logisch erscheint.

Das Ziel:
Structure, die den Presence Status verschiedener anderer Geräte erfasst und selbst auf present oder absent geht.

Ich habe ein Bluetooth-Dongle das als presence Device die Zustände:
present | absent | maybe absent
annehmen kann. (bt_present)

Das presence Device bt_present soll present und absent an eine Struktur stMy_Devices weitergeben.

Bei bt_present Zustand absent und present funktioniert das einwandfrei.
Hat der Bluetoothdongle jedoch "maybe absent", geht meine Strucktur auf absent. Da nützt auch Threshold im bt_present nichts, da die Struktur sofort auf das maybe reagiert.

Strucktur stMy_Devices hat die Eigenschaften:

clientstate_behavior relative
clientstate_priority present absent
ATTR  st_type_presence


Ok.
Mein Ansatz das zu lösen ist dann auch mein Verständnisproblem.
Um "maybe absent" zu mappen, habe ich <struct>_map im bt_present verwandt :


st_type_presence_map  maybe.*:present


Wenn ich den Sinn des mappings richtig verstehe, sollte doch jetzt alles mit  "maybe..." auf present für die Strucktur gemappt werden. Sprich die Strucktur sollte jetzt auch present vom bt_present empfangen, wenn bt_present eigentlich auf "maybe.." steht.

Und genau das passiert nicht.
Im .memberHash des Structs und in den READINGS steht jeweils absent.

Anscheindend habe ich das nicht richtig verstanden. Wäre jemand so nett, das vlt richtig zu stellen?

Ich habe absichtlich das Device und das Struct nicht mit ausführlichem list angehangen, da dort noch mehr Devices drinstehen usw... ich wollte hier auf das wesentliche reduzieren. Wenn das nicht genügen sollte, reiche ich gerne nach.

Ey, irgendwann krieg ich nochmal ne Macke. Kaum habe ich das geschrieben, funktionierts.

Dann formuliere ich die Frage mal um.
Ich habe gestern den halben Tag damit verbracht, das alles richtig zu verstehen und zu anzupassen.
Nach Veränderungen habe ich fhem neu gestartet, mal mit, mal ohne die states vorher zu sichern, die Devices getriggert .. alles was mir so eingefallen ist.

Was hindert die Structs daran, sofort richtig zu reagieren ? Ist mir schon einige Male aufgefallen, das einiges sich erst später "justiert" . Mal ne Nacht drüber zu schlafen ist keine verkehrte Idee oftmals.
Nur woran liegt das ? Mehr als fhem neu zu starten geht doch fast gar nicht, um alles neu zu initialisieren. Vielleicht die gespeicherten states entfernen vorher? Hab ich noch nicht probiert.

ich habe jetzt statt mit <struct>_map mit eventMap weiter getestet.

Und stoße prompt auf das was ich meine.

Folgendes habe ich gemacht.
- das <struct>_map aus dem bt_present gelöscht (auch die Strucktur hat kein <struct>_map mehr)
- stattdessen im bt_present ein eventMap angelegt:
maybe.*:present

Der BT-Dongle zeigt jetzt korrekt bei "maybe" present an.

Schaue ich jetzt in die Structur, wird mir das bt_present  auch als "present" angezeigt.
Doch die Strucktur selbst bleibt auf absent.

Das sollte doch eigentlich nicht sein. Die Strucktur hat mehrere Devices. Ich habe alle auf absent, nur den Dongle wie beschrieben auf present gemappt.
Die Strucktur selbst ist wie oben schon gesagt

clientstate_behavior relative
clientstate_priority present absent

So sollte doch , weil ein Device present ist, die Strucktur auch auf present stehen, oder verchecke ich hier komplett etwas?

Schaue ich per list auf die Strucktur, wird mir das bt_present als "maybe absent" im    .memberHash angezeigt. Sollte da nicht auch durch das EventMapping im bt_present "present" drin stehen ? Ich checks nicht.  Wenn sich das Struct nach dem memberHash Wert richtet, ists klar warum es auf absent steht.

(Verständnisfrage. woher zieht der .memberHash eigentlich seinen Wert? Im bt_present gibt es kein Reading oder Attribut mit "maybe.." mehr. Ist alles auf present gemappt)

Zitatich beiße mir im Verständnis um structs die Zähne aus.

Du bist nicht alleine, mit der Rueckmeldung habe ich auch immer wieder meine Probleme, vmtl. weil es nicht von mir stammt, ich habe es nur als Patch uebernommen.

Wg. Struktur-Map: du redest von stMy_Devices, setzt aber st_type_presence_map: dieses Attribut hat keine Auswirkung auf stMy_Devices.

Wg. eventMap: kannst du bitte "attr global showInternalValues 1" setzen, und die Ausgabe von "list stMy_Devices" hier anhaengen?

Zitat von: rudolfkoenig am 29 Januar 2018, 14:57:38
Du bist nicht alleine, mit der Rueckmeldung habe ich auch immer wieder meine Probleme, vmtl. weil es nicht von mir stammt, ich habe es nur als Patch uebernommen.

Das finde ich beruhigend, dachte schon ich stell mich zu blöd an. Aber wenn selbst du damit deine Probleme hast...
Ich denke, die damalige Diskussion um den struct_map Patch habe ich gelesen. Der Patch wurde so übernommen, obwohl du(ich glaube das warst du, zu viel gelesen inzwischen) Einwände bei der Syntax hattest. Egal ....

Zitat von: rudolfkoenig am 29 Januar 2018, 14:57:38
Wg. Struktur-Map: du redest von stMy_Devices, setzt aber st_type_presence_map: dieses Attribut hat keine Auswirkung auf stMy_Devices.

Das ist schon korrekt, ich glaube ich habe mit den Bezeichnungen etwas verwirrt. Wollte eigentlich das Gegenteil erreichen.
Alle, ich sage jetzt mal umfassend Nodes, bekommen einen eindeutigen Bezeichner bei mir, damit ich am Namen schon sehe, was es für ein Typ ist.
So bekommen Struckture Devices immer ein stIrgendwas, ein Dummy dDummyName, Timer atIrgendwas, Presence pName uws.
Beim Struct dementsprechend der struct Type st_type_typename.
Daher das Device: stMy_Devices
der struct Type: st_type_presence

Zitat von: rudolfkoenig am 29 Januar 2018, 14:57:38
Wg. eventMap: kannst du bitte "attr global showInternalValues 1" setzen, und die Ausgabe von "list stMy_Devices" hier anhaengen?

Wie gesagt hatte ich hier vereinfachen wollen, um das Problem herauszustilisieren. Mein Device heißt stPresence_Daniel, mein BT Dongle: pHOME_BTag_Daniel

Hier das list vom Struct:

Internals:
   .cachedHelp Unknown argument ?, choose one of overrideInterval statusRequest
   ATTR       st_type_presence
   CFGFN      ./configs/structs.cfg
   CHANGED   
   CHANGEDCNT 7
   DEF        st_type_presence   pHOME_BTag_Daniel pHOME_BTag_Doro stSmartphone_S7_present
   NAME       stPresence_Daniel
   NR         1464
   NTFY_ORDER 50-stPresence_Daniel
   STATE      present
   TYPE       structure
   .asyncQueue:
   .memberHash:
     pHOME_BTag_Daniel present
     pHOME_BTag_Doro absent
     stSmartphone_S7_present absent
   .memberList:
     pHOME_BTag_Daniel
     pHOME_BTag_Doro
     stSmartphone_S7_present
   READINGS:
     2018-01-29 16   LastDevice      stSmartphone_S7_present
     2018-01-29 16   LastDevice_Abs  pS7_extern
     2018-01-29 16   state           present
Attributes:
   alias      Presence: Daniel
   clientstate_behavior relative
   clientstate_priority present absent
   devStateIcon present absent undefinied disabled
   disable    0
   event-on-change-reading state
   group      Home Status
   icon       audio_shuffle
   room       - Presence,- Struct,Home Status





Zur Sicherheit noch das vom BT Dongle:


Internals:
   ADDRESS    XX:XX:XX:XX:XX:XX:XX
   CFGFN      ./configs/presence_devices.cfg
   CHANGED   
   DEF        lan-bluetooth XX:XX:XX:XX:XX:XX:XX 127.0.0.1:5333 60
   DeviceName 127.0.0.1:5333
   FD         5
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       pHOME_BTag_Daniel
   NOTIFYDEV  global
   NR         562
   NTFY_ORDER 50-pHOME_BTag_Daniel
   PARTIAL   
   STATE      present
   TYPE       PRESENCE
   READINGS:
     2018-01-29 16:18:46   .absenceThresholdCounter 0
     2018-01-29 16:18:46   .presenceThresholdCounter 0
     2018-01-28 18:50:17   command_accepted yes
     2018-01-29 16:18:46   daemon          lepresenced V0.83
     2018-01-29 16:18:46   device_name     nut
     2018-01-29 16:18:46   model           lan-lepresenced
     2018-01-29 16:18:46   presence        present
     2018-01-29 16:18:46   rssi            -69
     2018-01-29 16:18:46   state           present
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     DISABLED   0
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 15
   alias      Daniel BTag
   devStateIcon present:message_ok absent:control_arrow_up_right disabled:control_on_off undefined:edit_collapse maybe.*:secur_alarm
   disable    0
   event-min-interval 3600
   event-on-change-reading presence
   group      HOME Presence Devices
   icon       control_arrow_downward
   presenceThreshold 1
   room       - Presence,Home Status
   sortby     1
   st_type_presence stPresence_Daniel
   st_type_presence_map maybe.*:present present:present absent:absent
   userattr   st_type_presence st_type_presence_map structexclude   
   




Kann ich nicht statt struct_map einfach im Struct eventMap benutzen ? Scheint mir einfacher und übersichtlicher. Die Events fürs Struct sind doch die Statusänderungen der Members .. So sollten sich doch diese Events umschreiben lassen. (Was mir auch nicht so richtig geglückt ist, aber Einstellungen kommen ja auch nciht immer direkt an )

ZitatHier das list vom Struct:

Schaut fuer mich richtig aus:
   pHOME_BTag_Daniel present
   pHOME_BTag_Doro absent
   stSmartphone_S7_present absent
...
   2018-01-29 16   state           present
...
   clientstate_behavior relative
   clientstate_priority present absent

ZitatKann ich nicht statt struct_map einfach im Struct eventMap benutzen ?

Nein, und einfach schon gar nicht :/
XXX_map aendert den Zustand der einzelnen Geraete (und muss auch da gesetzt werden, nicht in der Struktur) fuer die Berechnung des Strukturstatus.
Man kann bei diesen Geraeten statt XXX_map auch eventMap setzen, dann ist die Aenderung aber fuer "alle" sichtbar, nicht nur fuer die Struktur.

Richtig, eventmap schreibt die readings um...ist nicht gut.
(Mit handy getippt, deswegen nur kurz)

Sollte es bei eventMap nicht reichen erst in der Struktur selbst zu mappen?
Events wie "maybe.." kommen doch vom Member im struct an, und könnten auch dort erst umgescgrieben werden. Oder denke ich falsch?

Je nach Konfiguration und Anwendung mag das reichen.
Unterschied: im "empfohlenen" Fall aenderst du die Input-Werte, in "deinem" Fall den berechneten Output.

Zitat von: rudolfkoenig am 29 Januar 2018, 17:22:50
Unterschied: im "empfohlenen" Fall aenderst du die Input-Werte, in "deinem" Fall den berechneten Output.

Ich bin nicht sicher, ob ich das richtig verstehe.  Du meinst das aus Sicht des Structs ?
Empfohlen hieße dann per XXX_map den Input, den das Struct sieht, zu ändern.
EventMap im Struct wäre dann der (quasi im Nachhinein) berechnete Outputwert. Meinst du das so ?

EventMap drückt (in meinem Fall leider) die umgeschriebenen Readings auch auf die Members durch. So ist dann ein im Struct per eventMap umgeschriebenes Reading "maybe.*" zu "present" auch ein "present" im Member. "Maybe" würde ich gar nicht mehr mitbekommen, nur noch über die .tresholds. Ist für meine Zwecke nicht gut.

XXX_map hatte ich so verstanden, das jedes Member sein eigenes mapping macht, wie ich es im Member definiere und im struct_type wie ein Filter speichert. Wenn das so läuft, stelle ich mir das wie einen allgemeinen Filter vor, der zwar in jedem Member einzeln definiert werden kann, aber den Vorteil hat, das ein nächstes Member durch den struct_type_map schon seine Definitionen hat, wenn es die gleichen Readings umbiegen muß.
Also struct_type als Filter-Queue.
Kann man das so sagen, oder hab ich es noch nicht richtig verstanden ?



Vielleicht nochmal die wichtigste Frage: Wodurch kann ich erreichen, das Einstellungen auch gleich im Struct (oder anderen Nodes) übernommen werden ? (Wie oben schon erwähnt)
Ein Neustart, selbst vom Raspi, speichern oder löschen von stats, triggern der Member und ähnliches hat nie verlässlich funktioniert.
Gibt es einen Workaround dafür?


kurzes, nachvollziehbares Beispiel:    << KORRIGIERT; SIEHE NÄCHSTER BEITRAG
Gegeben:
- 1 Strucktur mit 2 Presences Devices
- Struktur steht auf client_behavior relativ
- Presence Devs geben present oder absent durch
- 1. Presence steht auf absent, das 2. auf present

Gebe ich im Struct jetzt an:
clientstate_priority: absent present
.. sollte das Struct auf: absent stehen.


Drehe ich das ganze um:
clientstate_priority: present absent
.. sollte das Struct auf: present stehen.


Nur wechselt das Struct nicht den Status, wenn ich die Reihenfolge umkehre. Probierts aus. Hier sind keine mappings im Spiel, nur die nackten Devices. Funktioniert genauso mit on / off
Wie stoße ich das an?




Sorry für die viele Fragerei

Hab mein Beispiel noch einmal getestet. Hier reicht dann doch das Triggern der Members, oder eines entscheidenen Members.
Das war dann wohl kein gutes Beispiel .. ich markiere das oben auch nochmal.
Ich vergesse gern, das EVENTS hier die entscheidene Rolle spielen, und nicht die gespeicherten Readings.

ZitatVielleicht nochmal die wichtigste Frage: Wodurch kann ich erreichen, das Einstellungen auch gleich im Struct (oder anderen Nodes) übernommen werden ? (Wie oben schon erwähnt)

struct rechnet sein Status neu, wenn einer der Mitglieder sein status aendert.

ich habe "EventMap" zur Hilfe genommen: /maybe absent:sleeping/
Dann konnte ich beim Attribut "devStateIcon"=....sleeping:remotecontrol/black_btn_SLEEP
angeben. Somit wird jetzt das Symbol angezeigt, welches ich wollte.
Das Problem ist das Leerzeichen im Status "maybe absent" ???

Grüße Peter

Das Problem ist lösbar mit aus
maybe absent
mach
maybe.absent