Homematic Datenpunkte

Hallo

Seit IPS 2.5 :loveips: und Homematic-Firmware 1.504 sind ja ein paar schöne neue Datenpunkte hinzugekommen :).

Was mir fehlt, ist an zentraler Stelle eine eingängige Beschreibung der oft kryptischen Variablen (STICKY_UNREACH = Klebrige Unerreichbarkeit :eek:).

Was ich bis jetzt habe, ist folgendes:

:1 Devices


ERROR			Fehler (aber was bedeuten die Werte?)
INSTALL_TEST		?
INHIBIT			Gesperrt ?
WORKING			In Arbeit

Die selbsterklärenden Datenpunkte sind hier nicht aufgeführt.

:0 MAINTENANCE


CONFIG_PENDING		Konfigurationsdaten anstehend
DUTYCYCLE		Arbeitszyklus ?
LOWBAT			Schwache Batterie
RSSI_DEVICE		Signalstärke des Gerätes
RSSI_PEER		Signalstärke des Gleichrangigen ?
UNREACH			Unerreichbarkeit
STICKY_UNREACH		Klebrige Unerreichbarkeit ?

Ich hab die Übersetzung mal dahintergeschrieben, kann mir unter einigen jedoch nichts Vernünftiges vorstellen (INSTALL_TEST, INHIBIT, DUTYCYCLE) oder erkenne den Unterschied nicht (RSSI_DEVICE/RSSI_PEER oder UNREACH/STICKY_UNREACH).

Die Homematic-Dokumentation der Datenpunkte Teil 4 gibt hier nicht wirklich was her.

Vielleicht kann mal jemand von den Homematic-Spezies (z.B. chrisu) mein Dunkel etwas erhellen?! :confused:

Gruss, Andreas

Hi,

Dann versuch ichs mal :smiley:

:1 Devices


ERROR -> Hier steht im Fehlerfall eine Nummer drin. Die Bedeutet je nach Gerät was anderes. Und ist normal nicht Dokumentiert.
 
INSTALL_TEST -> Wird aktiv wenn der Install-Test gestartet ist. Der dient dazu um die Funktion eines Ein-/Ausgangs zu Testen.
z.B.:
Ausgang -> Wird geschaltet und gecheckt ob die Änderung zurück gemeldet wurde.
Eingang -> Wartet auf Betätigung des Eingangs. Ist ganz nützlich um rauszufinden welcher Wandtaster an welchen Eingang hängt...
 
INHIBIT -> Man kann bei HM Ein-/Ausgänge sperren. Also temporär deaktivieren. Das ist der Datenpunkt dazu.
 
WORKING -> geht so lange auf TRUE bis der Vorgang abgeschloßen wurde.
Geht bei Schalter recht schnell. Bei Dimmer z.B. so lange auf TRUE bis der Dimmvorgang abgeschloßen ist.

:0 MAINTENANCE


CONFIG_PENDING -> Konfigurationsdaten anstehend
 
DUTYCYCLE -> Gibt an ob das Sendekontingent überschritten wurde (bei 868Mhz darf ja nicht jeder ewig senden).
 
LOWBAT -> Schwache Batterie
 
RSSI_DEVICE -> Sende Signalstärke des Gerätes
 
RSSI_PEER -> Signalstärke des Gegenüber (also das Gerät mit dem kommuniziert wird)
 
UNREACH -> Unerreichbarkeit (also Device Antwortet aktuell nicht auf die Befehle). Das ist die Servicemeldung in der Zentrale die nicht bestätigt werden kann.
 
STICKY_UNREACH -> War mal Unerreichbar (also Device hat mal nicht geantwortet). Das ist die Servicemeldung in der Zentrale die bestätigt werden kann.

Zumindest sind das meine Interpretationen der Datenpunkte.
Wenn jemand fundiertere Theorien hat, her damit :stuck_out_tongue:

Paßt. War ja alles schon Thema und nicht wirklich neu. Die RSSI-Sachen hatten wir letztens erst.
Einiges findet sich sogar detailliert erläutert im passenden IPS-Beispiel-Skript.

Interpretation kommt auch aus meiner Sicht hin.

Dummerweise hat die Winmatic keinen WORKING-Datenpunkt. Wäre schon nicht schlecht, denn das Bewegen eines Flügels dauert ja schon eine Weile. Mit einem WORKING könnte man z.B. neue zwischenzeitlich anstehende Befehle abfangen und verzögern, z.B. gegen einen manuellen Öffnen-Befehl just danach vom Regensensor reinkommender ZU-Befehl o.ä.

Haben neuere Winmatics diesen Datenpunkt? Wenn ja, bei welcher Firmware?

STICKY_UNREACH: (Mnemonik: Da klebt noch ne alte „Unreach“-Info am Bildschirm…)
Gibt es eine Möglichkeit, ähnlich wie in der Konfigurationssoftware („Bestätigen“) aus IPS heraus diese Meldung ebenfalls zu bestätigen, damit die aus der Liste verschwindet? Vielleicht über die „Value“-Werte im Array der Meldung? Aber wie spreche ich diesen Wert aus IPS an?

Das ist ja ganz nützlich mit dem Script der Statusmeldungen, mir aber in der Praxis so noch nicht wirklich hilfreich, außer ich baue darum nochmal eine eigene Verwaltung auf, die Ändrungen dieser Werte beobachtet.

Mir fehlt vor allem der Zeitpunkt dieser Meldung, also deren Alter, um das sinnvoll zu interpretieren. Im Array sehe ich keine Daten dazu und auch nicht in der Ausgabe der HM-Konfig-Software. Wird das wirklich schion durch HM nicht geliefert, oder wäre das durch IPS nachsetzbar, ggf. auch als IPS-seitig generierter Zeitstempel? HM-IO-Instanz läuft ja ständig mit und müßte das doch mitbekommen, sozusagen unverbindlich als „durch IPS erstmals diese Meldung empfangener Zeitpunkt“?

Wollte lieber fragen, bevor ich mir das selber nochmal aufbaue und durch logischerweise dann enge Polling-Intervalle des Status-Scripts mir noch mehr und fast immer recht sinnlosen Traffic auf der IPS-Kiste generiere.

Gruß Gerd

@Boui:

Danke für den Link, das war mir entgangen. Es ging auch weniger um „neu“, sondern um eine zentrale Stelle, wo man mal nachschauen kann, was die Datenpunkte bedeuten.

@chrisu:

Vielen Dank für die ausführliche Zusammenstellung. Das hat mir schon mal weiter geholfen.

Eine Ergänzung noch zum ERROR:
0 => Kein Fehler
3 => Lastfehler (bei Dimmern)
7 => Sabotage (bei PIRs und Tür/Fenster-Meldern)

Falls jemand noch mehr Fehlercodes kennt, möchte er sie hier bitte nachtragen.

Ich stricke gerade an einem Script, das für die unprofilierten Variablen automatisch Profile erstellt.

@Paresy, Horst & Co:
Oder sind da in Bälde automatische Profile für neuangelegte Variablen geplant?
z.B.
UNREACH: statt FALSE => Erreichbar oder ok
ERROR: statt Fehlernummer die Kurz-Beschreibung (3 => Lastfehler)
usw.

Gruss, Andreas

Hallo Gerd

In der xmlapi sind die Timestamps zu den Meldungen vorhanden. Aufruf mit

[IP der CCU]/config/xmlapi/roomlist.cgi

Gruss, Andreas

na toll. Ich-Chaaabe-abba-garrkeine-CCU sondern nur mehrere LAN-Adapter. :eek:

Da gibt es auf dem BidCos-Server wohl kein Webinterface und auch keinen entsprechenden Verzeichnisbaum, sondern nur die tgl. Log-Dateien, wobei man wohl auch noch die Devices-Logs auswerten müßte, um mitzubekommen, wie lange der BidCos-Service schon hochgefahren ist und alle betroffenen Tages-Dateien einzulesen und ggf. auszuwerten. Zzgl. Erkennung, ob eine Meldung dann schon irgendwann zwischendurch (reboot BC-Service/erstes Auftreten bis jetzt) bestätigt wurde und aus Liste verschwinden darf.

Aber Danke für den Tipp. Vielleicht kaufe ich mir ja doch irgendwann mal eine CCU…

Ich habe es an anderer Stelle schon mal geschrieben. Ich habe z.B. die UNREACH und STICKY_UNREACH einige Zeit zuverlässig beobachtet. Als dann die ersten Fehler kamen, sah ich mir das Ergebnis genauer an und es ist bei mir so, dass die Sachen bei gleichen Aktoren mit gleichen Voraussetzungen (RSSI) teilweise gesetzt sind, obwohl Befehle nachvollziehbar zuverlässig emfangen werden.

Da auch Werksreset und was weiß ich nichts bewirkt haben und ich mich nicht wirklich auf die Meldung verlassen kann, habe ich diese Auswertung sein lassen.

Bei mir kommt das schon hin mit den Meldungen. Ist eben Funk und zumindest hier sehr wohl nachvollziehbar bzw. kann dann Basis sein für Alarmierung. Und dann möchte ich schon gerne wissen, wie lange der Zustand schon andauert, denn auch eine Alarm-SMS wird mitunter verzögert o.ä.

Einzige Dauer-Statusmeldung bei mir betrifft angeblich anstehende Konfig-Änderung für einen 10fach-Display-Wandtaster, aber das ist offenbar ein Firmwareproblem und hier schon öfter behandelt worden

Wie gesagt lief es bei mir ne Zeitlang wirklich zuverlässig bis es Probleme gab. Und wenn ich keine einzige Statusmeldung sehe, die eine Störung ausgibt, der Aktor Befehle einwandfrei umsetzt aber trotzdem auf UNREACH stehen beliebt, dann ist das keine Basis für eine Alarmanlage. :smiley:
Und irgendwann waren das einige, die so einen Müll anzeigten, obwohl die Funktion bei mir im Haus problemlos läuft.

Hatte kürzlich ähnlichen Effekt. Aktor schaltete (also Standheizung ging an), obwohl Schaltbefehl FALSE zurück gab. Ursache war eine Funkstörung im Rückkanal, die das Quittungssignal überlagerte, konkret eine direkt neben dem Aktor im Carportdach platzierte HMS100TF, die bei -26°C nur noch Dauerton sendete.

HM ist dank Bidi so sicher, das sagt uns sogar, wenn eine Quittung nicht erfolgte. Aber nicht, warum die nicht ankam. Und Funk bleibt durch Funk störbar, auf beiden Kanälen.

Gesendet von meinem GT-I9000 mit Tapatalk