OpenMQTTGateway -> MQTT und RollingCode .... mal wieder

Begonnen von Dattel01, 15 September 2019, 21:13:13

Vorheriges Thema - Nächstes Thema

andre07

set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_gtag 7C2F80ADBC7D
Hätte ich auch selber drauf kommen können so ging es ja selber mal mit diesen Device "MQTT2_oMQTTgw_BT"
als ich versucht hatte es als gtag zuzuordnen... :-[

Beta-User

Zitat von: Michi1972 am 18 Februar 2020, 21:15:47
Wie kann man das mit dem PRESENCE Modul nutzen? Wir haben hier alle ein Mi Band Version 3 oder 4 .... ist doch im Prinzip das gleiche und könnte man auch für Anwesenheit nutzen.

Habe das mal angetestet, es gibt jetzt devices pro Mi Band. Aber wie verbinde ich das mit dem PRESENCE Modul, um in Roommate usw weiter darauf zu reagieren?
Das war der Gedanke, damit eine - im Optimalfall noch zonenorientierte - Anwesenheitserkennung zu realisieren.

Ich habe nur bisher nicht mit RESIDENTS & Co. gearbeitet... Zuerst bräuchte ich also "Nachhilfe", was denn unser Device am optimalerweise liefern sollte, damit PRESENCE damit was anfangen kann (bzw. welche Option man PRESENCE noch vorschlagen müßte, damit es auf beiden Enden einfach ist).

Man kann mit den Bausteinchen hier im Prinzip "alles mögliche" anfangen, im Moment denke ich an zwei Readings: Eines, in dem jeweils das letzte Gateway steht (ggf. mit Auswahloption via userAttr, welche GW's überhaupt nur ausgewertet werden sollen), und eines, in dem alle drin sind?
Das mit dem letzten Gateway wäre dann so ähnlich wie "last" im BT-Scanner, man könnte dann recht einfach ReadingsAge nehmen, um festzustellen, wann die jeweils letzte Aktualisierung von irgendwoher war.

Vermutlich würde es Sinn machen, den ganzen Code dazu in eine myUtils auszulagern, da kommt ggf. ganz schon was zusammen... Mal schauen.

Zitat von: andre07 am 18 Februar 2020, 23:17:48
set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_gtag 7C2F80ADBC7D
Hätte ich auch selber drauf kommen können
Nevermind, wir sind hier alle noch am lernen, und manchmal sieht man eben den Wald vor lauter Bäumen...

An sich sollte es durch den Hilfetext klar sein, aber wenn da Verbesserungsbedarf besteht: Das ist "auf die Schnelle" entstanden und kann und darf kritisiert werden - bitte dann nur auch einen Alternativvorschlag liefern..
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachtrag:
last_IO wird je bereits gesetzt. PRESENCE geht daher z.B. in einer einfachen Variante so:
defmod FFFFC424A123_presence PRESENCE function { my $maxage = AttrVal("OMG_FFFFC424A123","maxPresenceAge","300");;;; ReadingsAge("OMG_FFFFC424A123","Last_IO","100000") < $maxage ? 1 : 0 }

Damit kann man über ein userattr im gtag-Device auch noch einen Wert einstellen, wie alt das Reading sein darf; ohne diese Angabe wird 300 (=5 Minuten) verwendet...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andre07

Würde es nicht schon reichen den event-min-interval hoch zu setzen.
Ich tue mich immer schwer mit diesen userattr.... ??? :-[

Beta-User

Über den Einwand muß ich wohl erst nachdenken...

Soviel mal vorab:
1. Man muß kein userattr setzen, es geht auch ohne; dann sind eben 5 Min eingestellt; ob das zu der aktuellen Einstellung von event-min paßt, habe ich noch nicht im Detail angesehen, mir ging es erst mal darum zu checken, wie man ggf. ein update nach PRESENCE bringt (=> geht prinzipiell, und zwar sehr einfach). Vermutlich sollte der default der AttrVal-Abfrage etwas (oder deutlich, z.B. > Faktor 2?) höher sein als min-intervall, oder? (Man kann das auch direkt in der PRESENCE-Abfrage vercoden ohne Abfrage des Attributwerts, und ob man nicht Intervalle bei dem PRESENCE-Dingens setzen sollte, ist mir auch noch unklar, Tendenz wäre wohl ja, oder wie häufig wird die Funktion den aufgerufen?)
Kurz: Vorschläge (am besten mit Erläuterungen) sind willkommen!

(Irgendwann soll/kann das dann auch gerne ins Wiki, ich finde die OMG-Lösung nämlich cleverer, als überall Pi's zu verteilen, wenn die dann nur den Zweck haben, BT-Signale zu fangen).

2. Würde ich ggf. versuchen, das userattr gleich mit über das Template zu setzen, der User muß kann dann den Wert setzen oder anpassen, wie er lustig ist, muß aber nicht und braucht sich auch nicht mit userattr auseinenderzusetzen.
Wichtig kommt mir in dem Zusammenhang nur vor, dass ein User sich nicht intensiver mit dem Code auseinandersetzen muß, sondern einfach die Werte vorgeben _kann_, die er für sinnvoll hält, und das ganze erst mal so gesetzt wird, dass es funktioniert...

Allerdings werde ich den Verdacht nicht los, dass wir insgesamt noch komplexere Konfigurationsmöglichkeiten brauchen, jedenfalls dann, wenn es nicht nur dazu dienen soll festzustellen, DASS jemand da ist, sondern auch WO (jedenfalls ungefähr und bezogen auf den Standort der Gateways)...
Für ein einfaches "dass" braucht man nämlich auch die RSSI-Werte usw. nicht pro Gateway, da könnten wir auch alles auf dieselben Readings laufen lassen.

Wir können aber gerne auch ein "einfaches" und ein "komplexes" Template bauen...

(Sorry, meine Gedankengänge sind vielleicht manchmal schwer nachzuvollziehen, ich hoffe, es ist halbwegs verständlich).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Michi1972

Zitat von: Beta-User am 19 Februar 2020, 12:29:42
Nachtrag:
last_IO wird je bereits gesetzt. PRESENCE geht daher z.B. in einer einfachen Variante so:
defmod FFFFC424A123_presence PRESENCE function { my $maxage = AttrVal("OMG_FFFFC424A123","maxPresenceAge","300");;;; ReadingsAge("OMG_FFFFC424A123","Last_IO","100000") < $maxage ? 1 : 0 }

Damit kann man über ein userattr im gtag-Device auch noch einen Wert einstellen, wie alt das Reading sein darf; ohne diese Angabe wird 300 (=5 Minuten) verwendet...

Funktioniert spitze, vielen Dank! War nur ein kleiner Typo drin, statt "Last_IO" sollte es lieber "last_IO" sein. Danke!

Beta-User

Zitat von: Michi1972 am 19 Februar 2020, 17:08:51
Funktioniert spitze, vielen Dank! War nur ein kleiner Typo drin, statt "Last_IO" sollte es lieber "last_IO" sein. Danke!
Danke für die Rückmeldung und sorry wg. des Typos, hatte grade nur die Option gehabt, das abzutippen....

Trotzdem würde mich auch interessieren, ob es einer erheblichen Zahl der user egal ist, über welches GW die Info eigentlich kommt...?

Also: Wie wollt ihr das nutzen?
1. Reine Erkennung "es ist irgendwo im Haus ein bestimmtes Gadget vorhanden" (=einfaches, neues attrTemplate, das gar nicht so viele Readings "bastelt"), oder
2. interessiert sich eine gewisse Zahl (auch) für den Versuch, das so zu nutzen, dass man unterscheiden kann, wo sich jemand befindet?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Michi1972

Zitat von: Beta-User am 19 Februar 2020, 17:25:10
Danke für die Rückmeldung und sorry wg. des Typos, hatte grade nur die Option gehabt, das abzutippen....

Trotzdem würde mich auch interessieren, ob es einer erheblichen Zahl der user egal ist, über welches GW die Info eigentlich kommt...?

Also: Wie wollt ihr das nutzen?
1. Reine Erkennung "es ist irgendwo im Haus ein bestimmtes Gadget vorhanden" (=einfaches, neues attrTemplate, das gar nicht so viele Readings "bastelt"), oder
2. interessiert sich eine gewisse Zahl (auch) für den Versuch, das so zu nutzen, dass man unterscheiden kann, wo sich jemand befindet?

Ach ist nicht so schlimm mit dem Typo, wir können ja alle mitdenken. Ich finde es nur ziemlich klasse von dir, dass du gleich so eine tolle Lösung hattest!  8)

Zu deiner Frage: eher 2., folgende Szenarien sind denkbar:

  • Lichtszene im Raum angepasst für die Person, die den betritt
  • automatisch Licht ausmachen, wenn keiner mehr im Raum
  • Anzahl der Personen im Raum, darauf prophylaktisch reagieren, z.B. Raumtemperatur verändern oder Lüften oder oder
  • der Phantasie sind keine Grenzen gesetzt
Da immer mehr Leute diverse Gadgets am Arm haben wie z.B. das Mi Band von Xiaomi, kann man das prima auch für solche Zwecke nutzen.

Kurz: Nr. 2 bitte  ;)

andre07

Also ich würde es dazu nutzen um zu bestimmen wo sich jemand gerade  im  Haus befindet.
Dazu könnte man  z.B. meine fitness tracker hernehmen da man sie ständig bei sich trägt.
Ich hatte das bisher mit Motion Sensoren gemacht was aber nicht immer genau ist und sich
auch teilweise überschneidet.
Nötig wären da natürliche mehere opengateway's für jeden Raum oder Etage einen.
Das rssi im Reading des presence bräuchte man natürlich noch.
Wenn rssi bestimmter Wert unterschritten und present Aktion ausführen
Spielereien gibt es da genug die mir da einfallen zur Zeit war es halt noch
ziemlich ungenau in der Ausführung.
defmod miandre_presence PRESENCE function { my $maxage = AttrVal("OMG_7C2F80ADBC7D","maxPresenceAge","300");;;; ReadingsAge("OMG_7C2F80ADBC7D","last_IO","100000") < $maxage ? 1 : 0 }
attr mindre_presence DbLogExclude .*
attr miandre_presence devStateIcon present:dim75% absent:off@red
attr miandre_presence icon it_smartphone
attr miandre_presence room Status
attr miandre_presence userReadings rssi { ReadingsVal("OMG_7C2F80ADBC7D","OpenMQTTGateway_rssi",0)}\

schon mal ein Anfang

Andre

Beta-User

Danke schon mal für die Rückmeldungen,

Damit wollen wir also versuchen, das auch für genauere Analysen zu nutzen, ein "einfaches" attrTemplate würde ja trotzdem nicht schaden. Mal sehen...

Was die Positionsbestimmung angeht, wäre es m.E. besser, nicht erst die Daten auf andere Devices zu verteilen, sondern möglichst innerhalb des Devices eine Art "best_recent_IO" (als weiteres Reading) zu ermitteln. Das kann dann ja auch für die PRESENCE-Funktion genutzt werden. Der Spur nach könnte das so gehen: Es werden bei einer neu eingehenden Message alle RSSI-Werte durchgesehen. Gibt es einen "halbwegs aktuellen" besseren RSSI von einem anderen GW, bleibt das Reading, ist der neue RSSI besser oder der Wert veraltet, wechselt der Readingwert auf das neue, andere?

"veraltet" würde ich via userAttr konfigurierbar machen wollen, dafault auf 5 Min.?

(Vielleicht mag mal jemand coden, das ist im Prinzip normaler myUtils-Code...? Vermutlich macht es Sinn, den dann auch als myUtils mit zu verteilen; technisch ist das kein Problem, machen wir an anderer Stelle auch schon.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Doch noch etwas zum Spielen:

attr OMG_FFFFC424A123 userReadings bestRecentGW:.*_rssi.* {identifyMyBestGW($name)}
attr OMG_FFFFC424A123 userattr maxPresenceAge maxReadingsAge
attr OMG_FFFFC424A123 event-min-interval 300
attr OMG_FFFFC424A123 maxPresenceAge 1200
attr OMG_FFFFC424A123 maxReadingsAge 700

myUtils-Code für das userReading:
sub identifyMyBestGW($;$) {
  my ($name, $maxReadingsAge) = @_;
  my $hash = $defs{$name};
  $maxReadingsAge = $maxReadingsAge // AttrVal($name,"maxReadingsAge",600);
  my @rssis = grep { $_ =~ /.*_rssi/ } sort keys %{ $hash->{READINGS} };
  my $bestGW = "unknown";
  my $bestGWold = ReadingsVal($name,"bestRecentGW","unknownGW");
  my $bestRSSI = -1000;
  my $currentRSSI = 0;
  foreach (@rssis) {
    if (ReadingsAge($name,$_,100) < $maxReadingsAge) {
      $currentRSSI = ReadingsVal($name,$_,-1100);
      if ($currentRSSI > $bestRSSI) {
        $bestRSSI = $currentRSSI ;
        $bestGW = $_;
      }
    }
  }
  $bestGW =~ s/_.*//g;
  return $bestGW ne $bestGWold ? $bestGW : undef;
}


Vermutlich wird's noch mind. kleinere Änderungen geben, der Funktionsname muß auch irgendwie noch angepaßt werden, und ob das Codemäßig optimal ist, weiß ich auch noch nicht; aber immerhin spuckt es schon mal was plausibles aus...
Wer das besser findet, kann dem Funktionsaufruf auch direkt einen Wert für das max. Reading-Alter mitgeben.

Viel Spaß beim Testen!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andre07

Hab das mal bei mir mit übernommen Problem ist
das ich zur Zeit nur ein Gateway habe mehr ist unterwegs.
In China haben sie wohl aktuell Lieferschwierigkeiten.
  Internals:
   .FhemMetaInternals 1
   CID        CB80D6CC11DE
   DEF        CB80D6CC11DE
   DEVICETOPIC OMG_CB80D6CC11DE
   FUUID      5e4f1830-f33f-0b03-32cb-e547e591946e6dcf
   FVERSION   10_MQTT2_DEVICE.pm:0.211680/2020-02-10
   IODev      MQTTServer
   LASTInputDev MQTTServer
   MQTTServer_MSGCNT 35
   MQTTServer_TIME 2020-02-21 21:10:26
   MSGCNT     35
   NAME       OMG_CB80D6CC11DE
   NR         767
   STATE      Last IO: OpenMQTTGateway
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
     300
   .userReadings:
     HASH(0x559950418c98)
   READINGS:
     2020-02-21 21:10:26   OpenMQTTGateway_distance 27.75274
     2020-02-21 21:10:26   OpenMQTTGateway_id cb:80:d6:cc:11:de
     2020-02-21 21:10:26   OpenMQTTGateway_manufacturerdata W
     2020-02-21 21:10:26   OpenMQTTGateway_name MI Band 2
     2020-02-21 21:10:26   OpenMQTTGateway_rssi -92
     2020-02-21 18:41:01   bestRecentGW    OpenMQTTGateway
     2020-02-21 21:10:26   last_IO         OpenMQTTGateway
   helper:
     bm:
       MQTT2_DEVICE_Get:
         cnt        5
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        22.02. 00:44:31
         max        5.19752502441406e-05
         tot        0.000223875045776367
         mAr:
           HASH(0x559950987048)
           OMG_CB80D6CC11DE
           ?
       MQTT2_DEVICE_Set:
         cnt        52
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        21.02. 19:50:13
         max        0.0123229026794434
         tot        0.0153987407684326
         mAr:
           HASH(0x559950987048)
           OMG_CB80D6CC11DE
           ?
Attributes:
   DbLogExclude .*
   IODev      MQTTServer
   autocreate 0
   event-min-interval 300
   icon       temperature_humidity
   maxPresenceAge 1200
   maxReadingsAge 700
   model      OpenMQTTGateway_BT_gtag
   readingList home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/CB80D6CC11DE:.* { $TOPIC =~ m,home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,;; json2nameValue($EVENT, "${1}_") }
  home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/CB80D6CC11DE:.* { $TOPIC =~ m,home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,;; {"last_IO"=>"$1"}}
   room       MQTT2_DEVICE
   stateFormat Last IO: last_IO
   userReadings bestRecentGW:.*_rssi.* {identifyMyBestGW($name)}
   userattr   maxPresenceAge maxReadingsAge   

Was bewirkt dieses maxReadingsAge und maxPresensAge
oder soll bewirken.Ich dachte das wenn ich mich nicht
mehr in der Nähe eines devices befinde das reading bestRecentGW
auf unbekannt gesetzt wird wenn ich z.B. ausser Hauses bin.


Andre





Beta-User

Der Reihe nach:

Die Attribute bewirken nur, dass man bzgl. der "veraltet"-Zeiten nicht mehr mit defaults (Standardwerten) arbeitet, sondern von user-Seite her beeinflussen _kann_, wie
- das PRESENCE-Device (mit der geposteten "function") entscheidet, ob present oder absent "richtig" ist
- der userReadings-Code entscheidet, wann ein Interface nicht mehr "aktuell" ist, obwohl bessere RSSI-Werte gemeldet werden.
In letzterem Fall wird aber innerhalb des MQTT2-Devices nicht irgendein Timer gestartet, das muß weiter "außerhalb" erfolgen (ähnlich der function für PRESENCE); wer also z.B. feststellen will, ob ein Bewohner (noch) in einem bestimmten Raum ist, muß dafür dann erst noch was eigenes basteln, das "bestRecentGW" ist nur eine Hilfsinformation (wie das last_IO auch).

(Hoffe, das ist jetzt etwas klarer?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andre07

Dann lag ich wohl etwas daneben.
Man könnte ja das reading bestRecentGW
mit ins Precense Device übernehmen und
dann bei absent das reading überschreiben
mit abwesend oder sonst was.
Bastelei ich mir dann gleich mal und teste es aus

Andre

andre07

Ich habe nun versucht ein zweites Openmqttgateway hinzuzufügen.
Dabei habe ich den gateways die Namen "oben" und "unten" vergeben.
Als standard topic jeweils schlafzimmer und wohnzimmer  verwendet.
Die gateways werden erkannt und mit Namen "MQTT2_flur" "MQTT2_wohnzimmer" angelegt.
Auch ein Device MQTT2_oMQTTgw_BT wird erzeugt nur leider kann ich es mit attrTemplate nicht
OpenMQTTGateway_BT_scanner zuordnen die Auswahl existiert einfach  nicht mehr.
Wenn ich den Namen des Gateway auf OpenMQTTGateway  zurück setze funktioniert es wieder
nur ist es wohl dann nicht mehr möglich mehere gateway so zu betreiben.
Ich hoffe die infos reichen um das vieleicht zu bereinigen.

Andre