[Vorlage] Servicemeldungen Volume2
-
@looxer01
Das classic wired läuft in einer separaten Instanz nach dem hs485d Protokoll, das neue ist IP-wired läuft in der HMIP Instanz zusammen mit anderen HMIP Geräten wie z.B. Thermostaten o.ä. nach dem HM IP Protokoll -
@zahnheinrich
Danke für den Hinweis.
Es ist also auch nicht möglich Wired separariert von der HMIP Instanz als eigene Instanz zu konfigurieren ?vG Looer
-
@looxer01
Richtig -
@looxer01
Ich habe folgende Konstellation:
hm-rpc.0 -> CuxD
hm-rpc.1 -> rfd (HM classic)
hm-rpc.2 -> HMIP einschl. wiredScript Vers. 1.12
Problem: Bei Auslösen eines Sabotagealarms eines Fensterkontaktes (HMIP) kommt fehlermeldung in der CCU sofort, jedoch keine Veränderung der Datenpunkte im Script, es wird nicht getriggert.Folgende Scripteinstellungen:
// CuxD Instanzen duerfen nicht eingetragen werden
const HMClassicInstanz = 1; // HM-Classic Instanz eintragen // 9 = falls nicht relevant
const HMIPInstanz = 2; // Homematic IP Instanz eintragen // 9 = falls nicht relevant
const WiredInstanz = 9; // Wired Instanz // 9 = falls nicht relevant
const GruppenInstanz = 9; // 9 = nicht relevant - Die Gruppen werden i.d.R. nicht gebrauchtSollte es nicht eine Einstellung geben, mit der eine (evtl) vorhandene CuxD-Instanz auf "9" gesetzt werden müsste, bei mir also die Instanz 0?
Edit: Script nochmal neu gestartet, jetzt geht´s, beobachte weiter...
-
@zahnheinrich
Hi,
ich habe für die nächste Version erhebliche Änderungen eingebaut.
Lohnt sich daher nicht in die alte Version zu schauen.
Die kommt dann heute oder morgen, falls ich nicht erhebliche Probleme finde.vG Looxer
-
Hi,
Version 1.20 ist online.
Ein größerer Sprung- Code optimiert und stellenweise umgeschrieben
- Einstellungsbereich strukturiert
- Funktional: Es ist nun möglich, für jeden Nachrichtenservice (z. B. E-Mail, WhatsApp usw.) individuell festzulegen, ob eine kurze oder lange Meldung versendet werden soll.
Bitte beachten und das galt auch schon für die alten Versionen
- Die Instanzen müssen stimmen.
- Eine 9 eingeben, wenn eine Instanz nicht benötigt wird
- Die Instanz für CuxD bitte nirgendwo eingeben
- Ansonsten sind die Instanznummern natürlich mit den Instanzen HMRPC des ioBrokers abzugleichen
vG Looxer
-
Version 1.30 ist online
Funktional ist meine Liste nun abgearbeitet. Die Funktionen, die ich einarbeiten wollte sind enthalten.
Falls Fehler auftauchen werde ich diese gerne fixen. Um dies zu supporten gibt es nun auch eine neue wichtige Funktion.- Kommentare hinzugefuegt
- Alarmtypes koennen fuer jede Instanz getrennt ausgeschlossen werden
- Ausschlussliste geht jetzt auch bei REGA subscription
- 3 Alarmtypes entfernt (error_reduced / U_Source_Fail / USBH_POWERFAIL)
- LOW_BAT_ALARM -Log angepasst
- System Log kann extern gespeichert werden
Der letzte Punkt ist mir sehr wichtig
Falls ihr Ungereimtheiten habt, dann stellt bitte in den Einstellungen folgendes ein: const SystemLog = true
Bitte damit bitte auch den DebugLevel auf mindestens 2 stellen.
Damit wird das externe logging aktiviert und alle log-Nachrichten werden in das externe log aber nicht auf der im ioBroker log ausgegeben (aufgrund der Menge der log-Nachrichten würde das auch eher stören)
Anmerkung: die grundlegenden logs (Level 0) werden AUCH im iobroker weiter ausgegeben.
Das Log könnt ihr dann mit der Beschreibung des Fehlers posten. Somit sollte es wesentlich einfacher sein festzustellen wo das Problem liegt.Ansonsten ist es hier im Thread sehr ruhig, was hoffentlich bedeutet, dass alles läuft:
vG Looxer
-
Ich habe in den ersten Beitrag noch ein Tool online gestellt mit dem ihr eure Subscriptions listen könnt.
Das geht mit oder Auswahl eines Scriptenames. So könnt ihr gezielt die System-Subscriptions einsehen.
Diese müssen mit dem Reporting der Servicemeldungen übereinstimmen. Dort werden die Subscriptions ja gezählt und mit debugLevel = 3 werden auch die einzelnen IDs, die subscribed wurden gelistet.
Trotzdem hilft die Transparenz ja zu verstehen wie das ganze aufgesetzt ist.vG Looxer
-
Hi,
Version 1.32 ist online.- Funktion SubscriptionID - (Es gab sporadisch nicht gemeldete Servicemeldungen - nur innerhalb eines alarmtypes parallel auftretenden Servicemeldungen)
- Funktion SubscriptionID - umgestellt auf klassische For-Schleife
- Funktion SubscriptionID - Schwellwert fuer Ausführungsverzögerung von 50 auf 25 reduziert // Pause reduziert von 5 auf 3 Minuten
- Log Messages hinzugefügt
vG Looxer
-
Hi,
ich habe zwischenzeitlich noch ein wenig geschraubt.
Ich teste gerade eine Version, die es erlaubt auch mit HM-REGA subscription (also nur mit einer einzigen Subscription anstatt hunderter Subscriptions) auch eine Historie zu führen. Die ist zwar weniger präzise aber für die meisten wohl ausreichend.Da es hier so ruhig ist bin ich nicht so sicher, ob das überhaupt interessant ist.
Rückmeldung wäre schön.vG Looxer
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
Rückmeldung wäre schön.
kommt morgen.
war länger etwas ausgenockt. -
-
Hi,
ich schmeiße heute die Version 2.00 in den Ring mit vielen Anpassungen- weiteres Logging hinzugefuegt
- AccessPoint /HCU integration hinzugefuegt. Allerdings fehlen mir informationen- Wer also einen AP hat und gerne untersützt wäre das super - insbesondere die Objektdefinition der betroffenen IDs ist unklar
- historische Servicemeldungen fuer GeraeteID trigger nach Datum aufsteigend in JSON und Tex
- Achtung : Umbenennung von DP TestVergangeneSM in TextVergangeneSM. Das Script legt den neuen DP automatisch an. Den alten/falschen koennt ihr loeschen
- Historische Servicemeldungen auch bei REGA Subscription
- reichlich Umstrukturierungen und Performance Verbesserungen. Ein Durchlauf braucht nur noch 4 MS vorher 11 (in meiner Systemumgebung)
- für historische Meldungen werden jetzt auch immer "keine Servicemeldungen" festgehalten
- Voreingestellt ist jetzt die subscription für REGA (1 subscription) Ich persönlich bevorzuge aber immer noch die Geraete-ID subscription (mehr Informationen)
Für die REGA Subscriptions bezüglich der historischen Meldungen ist es so, dass bei Änderungen immer alle aktuelle Meldungen geloggt werden. (Liegt in der Natur der Sache). Dafür habe ich habe eine rel. klare Darstellung implementiert (siehe Grafik)
vG Looxer
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
AccessPoint /HCU integration hinzugefuegt. Allerdings fehlen mir informationen- Wer also einen AP hat und gerne untersützt wäre das super - insbesondere die Objektdefinition der betroffenen IDs ist unklar
ich hab einen
HmIP-HAPals AP-Gateway an der CCU3 -
@negalein
Hi,
ich nehme mal an, dass du den AP als Reichenweitenverlängerung nutzt. In dem Fall werden ja keine Geräte Datenpunkte angelegt.
Wenn aber der AP mit der dem Adapter "Homematic IP Cloud Zugriffspunkt" installiert wird, dann werden auch die datenstrukturen übernommen. Ein HMIP Geräte kann immer nur genau 1 x von einer Steuerzentrale verwaltet werden. Also, entweder CCU3 oder AP oder auch HCU.Es kann sein, dass die Implementierung sogar schon funktioniert (für "lowBat" und "unreach"). Es kann aber auch sein, dass die objekt definition abweichend ist für
- Common Object Native
- common object name
- common object id
dazu bräuchte ich die Datenpunkt definition der Objekte wie sie im AP angelegt werden
vG Looxer
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
ich nehme mal an, dass du den AP als Reichenweitenverlängerung nutzt
stimmt, da bin ich dann leider raus
-
Hi,
Version 2.10 ist jetzt online.
- HMIP Accesspoint / HCU-cloud vollstaendig implementiert (Tests ausstehend). In diesem Zuge wurde mehr generalisiert. Also einstellbar gemacht ueber das Tabellenwerk. Die Routinen duerften damit auch stabiler geworden sein.
- Overheat und Undervoltage Alarm hinzugefuegt
- Performance Verbesserung Faktor 4- Urspruenglich lag der Zeitverbrauch fuer die Hauptroutine bei 11 ms. Nach dem letzten Update dann bei 4 ms und nun nur noch bei maximal 1 ms. (in meiner Systemumgebung)
edit: noch schnell die Version 2.11 nachgeschoben. Ich konnte HMIP AcessPoint/HCU teilweise testen. z.B. funktionieren die subscriptions etc.
vG Looxer
-
Hi,
Version 2.12 ist online- Folgender Fehler wurde korrigiert:
in bestimmten Konstellation wurde eine falsche Konfiguration der Messageservices gezogen.
Das konnte dazu führen, dass messages nicht gesendet wurden oder gesendet wurden auch wenn nicht gewünscht.
zusätzlicher Hinweis
Es ist übrigens möglich, Situationen zu überwachen, die in der CCU keine Servicemeldungen darstellen.
Es lassen sich Felder dazunehmen wie z.B. Duty-Cycle der Geräte und genau wie eine Servicemeldung überwachen.
Im prinzip geht dies auch bei nicht CCU/Access Point Adaptern, also beliebigen Adaptern.
Voraussetzung ist die Konfiguration des Tabellenwerkes und die Einstellung GeraeteTriggerId = true.vG Looxer
- Folgender Fehler wurde korrigiert:
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
Es lassen sich Felder dazunehmen wie z.B. Duty-Cycle der Geräte und genau wie eine Servicemeldung überwachen.
Cool, wo stell ich die Schwelle ein?
Edit:
Habe es verwechselt mit Carrier Sense CCU3
-
@sigi234 sagte in [Vorlage] Servicemeldungen Volume2:
Habe es verwechselt mit Carrier Sense CCU3
ja, genau. der Duty Cycle Wert steht ja zur Verfügung als HM-REGA Datenpunkt
Der DC, den ich erwähnt ist der, der als Datenpunkt bei den Geräten zur Verfügung steht
z.B. hm-rpc.1.00021D89xxxB2C.0.DUTY_CYCLEdort gibt es true und false. Wenn also ein Gerät ein DC Problem hat, dann steht das auf true.
vG Looxer
