Wie legt man Readings für virtuelle Teams fest ?

[joneu]

Hallo Leute,

mir ist unklar, wie ich bei meinen Rauchmelderteams an Readings wie "recentAlarm" rankomme ohne dass ich einen Rauchmelder des Teams auslösen muss.
Auch wenn ich "autoReadReg" auf readMissing setze kommen bei manchen Teams nur "peerList, state und teamCall. "GetConfig" geht ja bei einem virtuellen Team auch nicht.

Was mir bei meinem notify mit ReadingsVal jedesmal den Default bringt.

Team_Rauchmelder.OG {if ("Team_Rauchmelder.OG:state") {Message_Rauch(ReadingsVal("$NAME","recentAlarm","Scheiße1"),ReadingsVal("$NAME","state","Scheiße2"),'all');;}}

recentAlarm bringt mir nur bei dem Team den auslösenden Meldernamen, bei dem auch das Reading "recentAlarm" vorhanden ist.
Bei anderen Teams wo recentAlarm nicht als Reading drinsteht, bekomme ich beim Triggern jedesmal den  Defaultwert "Scheiße1 oder 2" geschickt.

Alle Teams sind von den Attributen exakt gleich eingestellt !
Kann man die Readings manuell vorgeben ?

Danke
Jo

[Puschel74]

Hallo,

jedesmal den  Defaultwert "Scheiße1 oder 2"

Das nenn ich mal aussagekräftige Defaultwerte 

Sorry aber ich musste grad schmunzeln.

Grüße

[joneu]

Hallo Puschel,

nachdem ich mich seit 30 Jahren mit Automatisierungssystemen und deren Problemen beschäftigt habe,
bleibt mir nichts anderes übrig als mich ab und zu selbst mit sprechenden Fehlermeldungen zu überraschen.
Nichts ist unlustiger und perfider als z.B. "unexpected Error" oder "uninitialized value $iconName in string eq at ./FHEM/01_FHEMWEB.pm line 2076".
Stimmts 

Im Ernst hast du eine Idee ?

Danke
Jo

[martinp876]

Hallo Jo,

bin nicht sicher, das ich durchsteige:

autoReadReg und getConfig gehören zur Konfiguration (peeren/Register). RecentAlarm ist keine konfiguration sondern ein Zustand. Damit kannst du also nichts erreichen.

wenn es das Reading recentAlarm nicht gibt, bekommst du den default geliefert - das sollte nach 30 Jahren Automatisierung klar sein.

Was erwartest du? Wenn kein recent alarm bekannt ist meldet das System eben Scheiße1, wie gewünscht.

Gruß
Martin

[joneu]

Hallo Martin,
danke für die Antwort, das mit den 30 Jahren Automatisierung lassen wir mal weg.

Wahrscheinlich hab ich mich etwas unklar ausgedrückt, obwohl alles drinsteht.
Der Punkt ist, dass "RecentAlarm" ein "Reading" ist, dass bei mir nur bei einem virtuellen Teammelder für die Rauchmelder im Obergeschoß auftaucht.
Teammelder im Erd- und Untergeschoß sind exakt gleich konfiguriert.
Ich nehme an, dass das Reading und auch andere (z.B. Smokedetect) im Obergeschoß nur drinsteht, weil ich da mal einen Rauchmelder ausgelöst habe.
Das mit autoReadReg und getConfig hast du mal jemand empfohlen, der auch unterschiedliche Readings in physikalischen Devices hatte.
Darum bin ich davon ausgegangen, dass man sich damit die verfügbaren Readings besorgen kann.

Man muss doch vorhandene Readings einrichten und abfragen können, auch wenn sie noch nicht "gefüllt" wurden.

Der Grund warum ich dieses Reading verwenden will, ist nur der, dass da und nur da der Name des auslösenden Rauchmelders drinsteht, den ich für meine Messages brauche.

Gruß
Jo

[martinp876]

Hallo Jo,

Ich nehme an, dass das Reading und auch andere (z.B. Smokedetect) im Obergeschoß nur drinsteht, weil ich da mal einen Rauchmelder ausgelöst habe.

sollte so sein.

Darum bin ich davon ausgegangen, dass man sich damit die verfügbaren Readings besorgen kann.

hm... wie soll ich sagen....
wenn etwas passiert, was CUL_HM "berechnen" und darstellen kann wird dies in Readings Kund getan. Mit getConfig werden z.B. register und peers gelesen . dann werden sie in Readings dargestellt (wo sonst). Also ja, mit getConfig kann man MANCHE readings füllen (ist genau definiert - konfigurations-readings!)

mit anderen Kommandos bekommt man andere Readings (statusRequest => battery-level, state,...)

Darum bin ich davon ausgegangen, dass man sich damit die verfügbaren Readings besorgen kann.

nein, nicht die verfügbaren Readings. verfügbare Readings ... ist ein schwieriger Begriff.

Man muss doch vorhandene Readings einrichten und abfragen können, auch wenn sie noch nicht "gefüllt" wurden.

ui.
ein vorhandenes Reading ist "vorhanden". Dann kannst du es auch sehen. Leer gibt es eigentlich (fast) nicht in der Informationstechnik.

Evtl sollten wir von "möglichen" Readings sprechen. Für eine Entity gibt es mögliche Readings - je nach Aktion/Event wird es angelegt/gefüllt - oder nicht. In Gegensatz zu Attributen verwaltet FHEM keine strikte Liste von Readings einer Entity. Du kannst jederzeit mit setReading einer beliebigen Entity ein beliebiges Reading setzen - aus der Kommandozeile.

Zum Abfragen eines Readings sollte man die von dir genutzte SystemFunktion ReadingVal nutzen. Wenn es das Reading gibt, bekommst du zurück  was immer drin steht. Wenn nicht, eben den Default.
In deinem Fall kennt dein sdTeam keinen recentAlarm - war nie einer da. Also gibt es das Reading schlicht nicht - Ende der Geschichte.

Der Grund warum ich dieses Reading verwenden will, ist nur der, dass da und nur da der Name des auslösenden Rauchmelders drinsteht, den ich für meine Messages brauche.

nicht ganz korrekt. Der Name sollte stehen in
sdTeam smoke_detect:<SDnameAlarm>
sdTeam recentAlarm:<SDnameAlarm>

und in JEDEM teammitglied:
<SDmember> smoke_detect:<SDnameAlarm>

mit dem Interschied dass in smoke_detect immer der aktuelle Alarm-geber angezeigt wird ("-" bei "kein Alarm") und in recent (wie der Name sagt) der Letzte - auch wenn kein Alarm mehr anliegt.

Was immer du erreichen willst. Ichwürde erwarten, dass man eine Email schicken will bei Alarm. Daher sollte man ein notify setzen auf sdTeam:smoke_detect:[a-Z0-9].*
- eben alles ausser "-". Und dann eine email schicken.
Noch einfacher - ein notify auf sdTeam:smoke_detect:.* - attr sdTeam event-on-change-reading .* nicht vergessen. Dann bekommt man eine email, immer wenn sich der Zustand ändert. Schadet nichts, wenn man eine email bekommt mit Alarm from '-' .
recent braucht man eigentlich nicht - nur wenn man nachträglich am web-interface sehen will, wers war, wenns vorbei ist. Für email ungeeignet.

Gruss Martin

[joneu]

Hallo Martin,

sicher hast du Recht das auch in "sdTeam smoke_detect:" der Name drinsteht.
Darauf gekommen "sdTeam state" abzufragen, bin ich eigentlich nur, weil ich dann damit auch sowas wie "battery low, off, MissingAcknoledge und IOErr mitkriegen kann.
Da steht ja dann in smoke_detect nichts drin !

Aber eigentlich reicht es, wenn ich den Alarm mitkriege.
Den Rest müsste mir ja eigentlich der ActionDetector im Status bringen, oder ?

Danke
Jo

[martinp876]

Hallo Jo,

Darauf gekommen "sdTeam state" abzufragen, bin ich eigentlich nur, weil ich dann damit auch sowas wie "battery low, off, MissingAcknoledge und IOErr mitkriegen kann.

der Logik kann ich nicht ganz folgen. Würde ich nicht so machen.

Für smoke-alarm würde ich ein alleinstehendes notify und eine Aktionskette machen. Ich würde versuchen, ein einzigen notify für alle SDTeams zu machen. In der Email dann das Team und des SD melden.

Action-Detector ist eine eigene Sache - hat mit sonstigen Readings nichts zu tun. Beim SD sind auch missing-ack nicht dabei....

Hier verweise ich gerne auf HMInfo. Die Idee ist, dass ich kein notify für jedes device mit Batterie brauche - auch nicht für ActionDetector und anderes mehr. Diese Parameter sind auch nicht sekundengenau relevant, es reichen (locker) Minuten (ganz im Gegensatz zum Rauchmelder!).
HMInfo prüft auf verschiedene Events und zeigt diese an (die Liste kann man ändern). Es werden infos, warnings und Errors ausgegeben. Errors bei dem Reading und NICHT diesem State. Also wenn es battery gibt und dieser nicht auf ok steht gibt es einen Event.
battery:ok,
sabotageError:off,
powerError:ok,
overload:off,
overheat:off,
reduced:off,
motorError:no,
error:none,
uncertain:yes,
smoke_detect:none,
cover:closed

Da kommen auch protokoll-errors an
man kann ein Notify auf
hm:ERR:.*
machen - das sollte die gängigen (allgemeinen) fehler abdecken

Gruss Martin

[joneu]

Hallo Martin,

hab das hm angelegt, sieht gut aus und deckt alles ab !

Allerdings weiß ich noch nicht so recht wie ich das im email verwenden kann,
da in
"ERR_names Rauchmelder_OG_Buegelz,Rauchmelder_OG_Buero,Rauchmelder_OG_Gaestez,Rauchmelder_OG_Gang,Rauchmelder_OG_Kniestock,Team_Rauchmelder.OG"

alle Namen stehen und in

ERR_battery low:1
ERR_smoke_detect -:6

Einen Batteriefehler hab ich aber nur beim Melder: Rauchmelder_OG_Buero erzeugt !?
Ist da jetzt das Team hinderlich ?

Nochwas:
Habe gerade bei einem Weiteren die Batterie rausgenommen, ein "statusRequest" gemacht und ein "MISSING ACK" erhalten.
Nach einem Update kommt dann die Meldung im hm an. Muss ich AutoUpdate auf "1" setzen ?
Das notify wird aber nicht ausgeführt.

Könntest du mir nicht 2 komplette Codezeilen hinschreiben, da ich im Wiki und auch im Forum nichts komplettes finde ?

Danke
Jo





Danke
Jo

[martinp876]

Hallo Jo,

HMInfo ist gedacht zur maintenance - nicht für konkrete Alarme. Will sagen: ein smoke-alarm wird (natürlich) angezeigt - bedarf aber sicher besonderer Aufmerksamkeit und gesonderter Aktionen. Infos, die wichtig, aber nicht zeitkritisch (in MinutenBereich) sind (batterie, actionDetect,...) kann man anders behandeln.

Die Idee von HMInfo ist, eine Übersicht zu erhalten und links zu den Fehlerquellen.

1) für smoke-detect würde ich ein notify erstellen - incl email usw. Das ist einfach zu kritisch.
HMInfo macht eine Aufnahme alle paar Minuten (einstellbar). Es könnte sein, dass an einen Alarm verpasst, wenn dieser innerhalb einer Abtastperiode kommt und wieder geht.
Wege, einen Alarm zu finden gibt es aber auch
{join(",",devspec2array("subType=smokeDetector:FILTER=state!=off"))}
das sind alle SmokeDetector, deren state nicht off ist. Ein teamlead ist hier nicht dabei (subType ist nicht smokeDetector)

2) für HMInfo gilt die Vorgabe, Alarme/warnings im web darzustellen, einen trigger erzeugen zu können (notify,wenn gewünscht). Und einen Link zu den Devices. Nachsehen muss man dann selbst. Ein weiteres Aufdröseln könnte ich einbauen... aber sind das dann zu viele Einträge?

Einen Batteriefehler hab ich aber nur beim Melder: Rauchmelder_OG_Buero erzeugt !?
Ist da jetzt das Team hinderlich ?

nein

Muss ich AutoUpdate auf "1" setzen ?

so ist es (fast). es ist ein timer - du legst die wiederholrate fest. alle 5min sollte reichen.
http://www.fhemwiki.de/wiki/Homematic_HMInfo#Attribute
autoUpdate startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.

beim HMInfo wetze ich folgende attribute
   autoArchive 1
   autoUpdate 0:05
   configDir  setup
   configFilename regConfig.cfg
   hmAutoReadScan 30
   sumERROR   battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
   sumStatus  battery,sabotageError,powerError,motor
   webCmd     update:protoEvents short:rssi:peerXref:configCheck:models:msgStat:clear Protocol


configDir und configFilename sind natürlich kür.

deinen smoke-alarm würde ich wie folgt einrichten
define nf_smokeAlarm notify .*smoke_detekt.* {....mail: smoke-status from $NAME}

(mail musst du selbst machen)

Alternativ - nur die Alarme aller teamleads - die namentlich sdTeam1 oder so heissen
define nf_smokeAlarm notify .*Team.*smoke_detekt.* {....mail: smoke-status from $NAME}
define nf_smokeAlarm notify sdTeam.*smoke_detekt.* {....mail: smoke-status from $NAME}

Gruss Martin

[joneu]

Hallo Martin,

danke für die ausführliche Antwort !
Das mit den hm Updates alle 5 Minuten ist schon in Ordnung, funktioniert auch.

Aber wann kommt eine Meldung durch ?
Ich habe seit einer halben Stunde die Batterie von einem Rauchmelder draußen.
Da passiert nichts. Nur wenn ich einen Status anfordere wird der Rauchmeldereintrag aktualisiert und dann mache bekomme ich das "Missing Ack" mit.
Wenn es da jetzt brennt geht gar nichts !
Da kann ich doch gleich einen statusRequest alle halbe Stunde machen und bei Veränderungen eine email schreiben.
Das war mein erster Beitrag im Forum und da habt Ihr mich augelacht.

Den ActionDetector habe ich jetzt auch auf minütlich gesetzt und der meldet auch nur gespeicherte Daten. Nichts aktuelles !

Die Rauchmelder melden sich alle 3 Tage, was nützt mir das wenn einer bevor er melden konnte abgebrannt oder verreckt ist.
Wenn es da keine wirklichen zyklischen Abfragen gibt, mache ich wieder mit "at" zyklische Abfragen !

Habe ich Recht oder mache ich was falsch ?

Danke
Jo

[martinp876]

Aber wann kommt eine Meldung durch ?
Ich habe seit einer halben Stunde die Batterie von einem Rauchmelder draußen.
Da passiert nichts. Nur wenn ich einen Status anfordere wird der Rauchmeldereintrag aktualisiert

nun ja - so schnell wird das wohl nicht erwartet. HM hat die rate auf 3 Tage (in Worten: Tage) gesetzt. Das spart Batterie.
Aus meiner Sicht ist dies auch ok (man kann gerne anderer Meinung sein, ich habe es eh nicht festgelegt). Ein batteri-low sollte so früh angezeigt werden, dann es noch min 1-2 Monate läuft. Was sind da schon 3 Tage.
Dein warten von 1h ist also unerheblich.
Mit einen statusRequest bekommt man auch den bat-level.

und dann mache bekomme ich das "Missing Ack" mit.
Wenn es da jetzt brennt geht gar nichts !

ein missing-ack solltest du nicht bekommen. da ist etwas faul.
ein rauchalarm wird von sd sofort gesendet.
Deine Bedenken verstehe ich nicht.

Da kann ich doch gleich einen statusRequest alle halbe Stunde machen und bei Veränderungen eine email schreiben.
Das war mein erster Beitrag im Forum und da habt Ihr mich augelacht.

warum solltest du? Und warum email?

Den ActionDetector habe ich jetzt auch auf minütlich gesetzt und der meldet auch nur gespeicherte Daten. Nichts aktuelles !

ja, was soll er den melden? Es sind nicht die gespeicherten Daten - die werden immer neu errechnet. Wenn dein SD sich alle 3 Tage melden muss und du alle Minute prüfst, ob die 3 Tage ohne Meldung um sind - ändert sich wohl lange nichts.

Die Rauchmelder melden sich alle 3 Tage, was nützt mir das wenn einer bevor er melden konnte abgebrannt oder verreckt ist.
Wenn es da keine wirklichen zyklischen Abfragen gibt, mache ich wieder mit "at" zyklische Abfragen !

du kannst gerne ein at einbauen und alle 10 min fragen, wie es dem SD geht. Dann das Attribut actCycle des SD entsprechend anpassen, damit der ActionDetector auf 10 Min prüft.
Die Wahrscheinlichkeit, dass der SD genau in den 3 Tagen verstirbt, in denen es brennt geht m.E. gegen Null. Mir taugt die Zeit. Deutlich Wichtiger wäre mir, wie gut der Sensor ist und ob der einen Defekt hat - wie gut dessen Prüfung ist.... das passiert  wohl nicht alle 3 Tage....

Habe ich Recht oder mache ich was falsch ?

mit 3 Tagen hast du recht. Bei deiner Einschätzung über die Tauglichkeit/Risiken/Auswirkungen bin ich deutlich anderer Meinung.

Gruss Martin

[joneu]

Hallo Martin,
dann bin ich wohl doch nicht auf dem Holzweg.

Bei den meisten Unfällen, Missgeschicken, Fehlern die passieren ist es immer so, dass mehrere Umstände zusammentreffen.
Bei allen Fehlern die ich bis jetzt erlebt habe waren es zu 90% mindestens 2 Dinge die unglücklich zusammen auftraten.
So frei nach Murphy: Wenn etwas schief gehen kann,gehts schief. Oder im Volksmund: Ein Unglück kommt selten allein.

Auf alle Fälle, Danke für die Auskünfte
Jo

[frank]

Da kann ich doch gleich einen statusRequest alle halbe Stunde machen

das hört sich ein bisschen so an wie:
meine autobatterie ist schon ziehmlich schlapp. also lasse ich mal das auto an, um zu testen, ob das auto noch anspringt. leider ist durch den test die batterie vollends geleert, so dass das auto dann nicht mehr anspringt, wenn es nötig ist.

ich hatte verstanden, dass die sd eine zertifizierung haben. das lässt mich vermuten, dass die 3-tägige alive-meldung ausreichend sein sollte. zumindestens bezüglich des batterie levels. selbst bei einem permanenten statusrequest gibt es keine garantie für ein sicheres auslösen bei feuer. siehe murphy. je öfter du die elektronik quälst, desto eher kann sie ausfallen.

ein echter monatlicher funktionstest mit einem geeigneten testspray und ein vorsorglicher batteriewechsel mit sehr guten batterien sollte vielleicht zielführender sein. einen brand verhindern können die rauchmelder sowieso nicht, höchstens ein hoffentlich frühzeitiges erkennen, wenn sie richtig platziert und regelmässig gewartet werden.

gruss frank