HM-Sec-SCo sendet endlos

[raptor]

Auch ich habe auf meinen Support Case hin nichts weiter erfahren. Ich habe erstmal gelernt, mit dem Fehler zu leben und ihn durch mein Verhalten zu vermeiden. Nicht die wünschenswerteste Lösung, ich hoffe ebenfalls weiter

[stan23]

Nach x-Minuten laufen sie aber in den eigenen DutyCycle, und sind dann ruhig. Spätestens da ist dann Ruhe.

Habe ich gerade mit der neuen DC-Berechnung im AnalyzerXS getestet:
der Fensterkontakt hört schon bei rund 36% DC auf zu senden, warum auch immer.

[jp112sdl]

Vielleicht stimmt bei der Berechnung noch irgendwas nicht.

[stan23]

Vielleicht stimmt bei der Berechnung noch irgendwas nicht.

Glaube ich nicht

In der Zwischenzeit habe ich mir ein kleines Überwachungsskript für ioBroker gebastelt:

Code: Alles auswählen

// all HM-Sec-SCo and HmIP-SWDO need to be supervised
var enumFenstersensoren = [
    'hm-rpc.2.LEQ0406029.1.STATE',      /*Fenster Toilette:1 STATE*/
    'hm-rpc.2.NEQ1479777.1.STATE',      /*Fenster Bad:1 STATE*/
    'hm-rpc.2.OEQ0224604.1.STATE',      /*Fenster Waschkeller.1 STATE*/
    'hm-rpc.2.OEQ0225395.1.STATE',      /*Fenster Vorratskeller.1 STATE*/
];

const updateCounterWarnTreshold = 10;   // notify after this number of status updates

let updateCounter:number;
updateCounter = 0;

// trigger on 'equal' status updates
on({id: enumFenstersensoren, change: 'eq'}, function (obj) {
    log(`Window contact ${obj.name} status update`, 'debug');
    if ((obj.state.ts - obj.oldState.ts) > 5000) {
        log(`Window contact ${obj.name} status timeout, no flood`, 'debug');
        updateCounter = 0;
    } else {
        updateCounter++;
        if (updateCounter == updateCounterWarnTreshold) {
            log(`Window contact ${obj.name} is flodding!`, 'debug');
            sendTo('pushover.0', 'send',  {
                title: 'Meldungsflut',
                message: `Fensterkontakt ${obj.name} flutet durch Statusupdates!`,
                priority: 0,
            });
        }
    }
});

[dldavid]

Nach x-Minuten laufen sie aber in den eigenen DutyCycle, und sind dann ruhig. Spätestens da ist dann Ruhe.

Habe ich gerade mit der neuen DC-Berechnung im AnalyzerXS getestet:
der Fensterkontakt hört schon bei rund 36% DC auf zu senden, warum auch immer.
Analyzer_DC_Fenster_Bug.png

Hallo Stan23, frage wie hast du die Grafik gemacht?
ich habe aktuell Probleme mit meinem DutyCycle und für mich wäre es interessant wie du die einzelnen DutyCycle s ermittelt hast

LG
dldavid

[jp112sdl]

wie hast du die Grafik gemacht?

Das ist der AskSinAnalyzer: viewtopic.php?f=76&t=51161
Bzw. sein kleiner Bruder, der AskSinAnalyzer XS: viewtopic.php?f=76&t=56395

[ihno]

Moin,

das ist ja ein Ding !
Auf diesen Eintrag bin ich durch Zufall gekommen !
Auch ich habe mich, in meinem Fall, über meine Terrassentür gewundert/geärgert und schon den 2 Sensor eingebaut. Dieser hat aber auch ab- und zu genau das beschriebene Verhalten !
Bisher hatte ich noch nicht herausgefunden, woran dies liegt. Wenn ich das richtig verstehe, kann ich den Fehler umgehen, wenn ich einfach auf "sofort senden" umstelle ?
An dieser Tür habe ich allerdings auch noch einen Türgriffkontakt der eingentlich "vorlaufen" sollte, da meine Sensoren als Abfallprodukt auch eine Alarmfunktion beinhalten und der Alarm nicht ausgelöst wird, wenn der Griffkontakt ( zuerst ) auf offen bzw. gekippt steht. Somit würde nach der Änderung beim öffnen sofort ein Alarm ausgelöst werden. --> Dies könnte ich aber mit einem Programm lösen, welches mir eine entsprechende Variable verzögert "schaltet"...
EDIT : Bisher scheint es so zu funktionieren Die Variable sorgt dafür, dass Meldungen des optischen Melders erst nach 5 Sekunden eine Statusänderung für z.B. die Alarmanlage erzeugt...