Status von Aktoren stimmt nicht immer

Allgemeines zur HomeMatic Haussteuerung

Moderator: Co-Administratoren

Tobias78
Beiträge: 1464
Registriert: 27.06.2010, 01:01
Wohnort: Braunschweig
Hat sich bedankt: 4 Mal

Re: Status von Aktoren stimmt nicht immer

Beitrag von Tobias78 » 14.07.2017, 19:14

Hallo Creator,

bin grad unterwegs, daher kann ich darauf nicht zugreifen zum Posten des Skriptes.
War aber auch kein Hexenwerk. Alle 5 Minuten werden die üblichen Verdächtigen abgefragt. Wenn mich nicht alles täuscht hatte ich es mit Homeputer realisiert. Geht aber auch per WenUi.

Hatte auch mal eine Kombination aus getvalue und setvalue am Start. Da war der Status dann Richtig, dafür ging oft das Licht unvermittelt an oder aus, wenn korrigiert wurde.
Der Weg über Programme ist nichts für mich da die Latenz zumindest bei der CCU2 zu lang war und da ich auch beim Absturz des RPI Licht haben möchte. Ob die Latenz bei RPI genauso lang ist, hab ich noch nicht getestet.

Gruß, Tobias.
--------------------------------------------
Im Einsatz und empfehlenswert:
RaspberryMatic,IO.Broker, Homeputer Studio; CuXD; PocketControl, HomeStatus, Robonect, Alexa, io.Broker
------------------------------------------

Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Re: Status von Aktoren stimmt nicht immer

Beitrag von Familienvater » 03.09.2017, 16:14

Hi,

ich hole das alte Thema mal hoch, nach dem ich heute ein bisschen getestet habe, und dabei interessanterweise Ergebnisse erzielt habe, dich ich so nicht erwartet hätte:

Ich habe eine kleine wired-Testinstallation mit 2x 12/7er Modul (S/N ...855 und ...879), 2x IO4 (...172 und ...111), 1x 12/14er Modul (...969), 1x Sw2-DR (...445), Busabschluss und LAN-Gateway, alles ziemlich fliegend mit kurzen Drähten verdrahtet.

Test 1:
Ein Kanal vom IO4 mit jeweils einem Kanal vom Sw2, und den beiden 12/7er direktverknüpft, alle Module stehen auf 0,1sec Meldeverzögerung, die DVs sind als Treppenhauslicht mit unterschiedlichen Einschaltdauern von wenigen Sekunden definiert.

Erwartung:
Untergehende Einschaltmeldungen, weil 3 Module gleichzeitig ihren Status loswerden wollen.

Ergebnis:
Jedes Modul schickt bis zu 3 Einschaltmeldungen (AN und die Zeit in Sekunden nach dem Tastendruck, wo das Event erfasst wurde), die Einschaltmeldungen kommen schneller, als die konfigurierten 0,1s Meldeverzögerung. Ich habe mehrere Versuche gemacht, das Sw2-DR ist immer das letzte Meldende gewesen, die 7/12er melden deutlich schneller, mal kommen nur 2 AN-Meldungen von einem Modul, mal kommen 3 Meldungen von einem Modul, es sind alle Modultypen, die mal 2 oder 3 Meldungen senden.

Jedes Modul schickt eine Ausschaltmeldung (AUS und die Zeit in Sekunden nach dem Tastendruck, wo das Event erfasst wurde), die vorgegebene Einschaltdauer der Direktverknüpfung wird sehr exakt eingehalten.
WiredEvents1.png
WiredEvents1.png (11.11 KiB) 1528 mal betrachtet

Test 2:
Ein Kanal vom IO4 mit 3 Kanälen vom einem 12/7er direktverknüpft, Modul steht auf 0,1sec Meldeverzögerung, die DVs sind als Treppenhauslicht mit unterschiedlichen Einschaltdauern von wenigen Sekunden definiert.

Erwartung:
Keine untergehenden Einschaltmeldungen, weil nur eine CPU im 12/7er die Events handlen sollte, und diese sauber nacheinander auf den Bus bringen kann.

Ergebnis:
Untergehende Meldungen, mal kommt nur die Meldung von einem Kanal, mal eine von 2 Kanälen, aber auch 2 vom gleichen Kanal. Es ist nicht vorhersagbar, welcher Kanal meldet, und welche Meldung untergeht.

Jeder Kanal schickt eine Ausschaltmeldung (AUS und die Zeit in Sekunden nach dem Tastendruck, wo das Event erfasst wurde), die vorgegebene Einschaltdauer der Direktverknüpfung wird sehr exakt eingehalten.
WiredEvents2.png
WiredEvents2.png (7.77 KiB) 1528 mal betrachtet
Test 3:
Ein Kanal vom IO4 mit 3 Kanälen vom einem 12/7er direktverknüpft, Modul steht auf 0,1sec Meldeverzögerung, die DVs sind als Treppenhauslicht mit unterschiedlichen Einschaltverzögerungen und unterschiedlichen Einschaltdauern von wenigen Sekunden definiert.

Erwartung:
Keine untergehenden Einschaltmeldungen, nur ein Modul, und die Events treten nicht gleichzeitig sondern nur verzögert auf, und diese sollten sich sauber nacheinander auf den Bus bringen lassen.

Ergebnis:
nicht erwartete Meldungen. Das Modul meldet als Antowrt auf den Tastendruck seinen aktuellen Zustand zurück, dies aber teilweise untergehend, mal kommt nur die "Quittungs-Aus" Meldung von einem Kanal, mal eine von 2 Kanälen, aber auch 2 vom gleichen Kanal.
Die eigentlichen Ein- und Ausschaltmeldungen kommen immer sauber durch, die Einschaltverzögerung wird sauber eingehalten.
Man muss also wenn man mit Einschaltverzögerungen arbeitet mit "ungewöhnlichen" Events rechnen (AUS vor AN, dann AN, dann AUS).

Jeder Kanal schickt eine Ausschaltmeldung (AUS und die Zeit in Sekunden nach dem Tastendruck, wo das Event erfasst wurde), die vorgegebene Einschaltdauer der Direktverknüpfung wird sehr exakt eingehalten
WiredEvents3.png
WiredEvents3.png (10.43 KiB) 1528 mal betrachtet
Was mich wirklich erstaunt/verägert ist, das die Firmware der Module nicht in der Lage ist, innerhalb Ihres Hoheitsbereich sauber zu melden, sondern es anscheinend innerhalb des Moduls zu Race-Conditions kommen kann, und dann einfach nichts gemeldet wird, es fehlt soetwas wie eine Message-Queue innerhalb des Moduls, und die zu versendenden Nachrichten von einem Consumer-Prozess abgearbeitet werden.


Das war es erstmal, vielleicht habe ich irgendwann nochmal Lust auf Tests mit "gestaffeltem" Einschalten, aber so gewählten Einschaltdauern, das gleichzeitig alle Kanäle ausschalten, und mehrere Schließerkontakte "gleichzeitig" schalten, ob dann auch innerhalb eines Moduls die Meldungen untergehen. Ich habe nur leider nur einen begrenzten Fundus an Modulen zum Testen, und in der Life-Anlage mache ich solche Spielereien nicht, da hätte ich zur Not noch mehr Schließerkontakte sowohl 12er als auch 12/14er zum Testen.

Der Familienvater

Edit:
richtige Grafik bei Test 3 anzeigen
Zuletzt geändert von Familienvater am 03.09.2017, 18:38, insgesamt 1-mal geändert.

creator
Beiträge: 242
Registriert: 03.01.2016, 12:16
Danksagung erhalten: 1 Mal

Re: Status von Aktoren stimmt nicht immer

Beitrag von creator » 03.09.2017, 18:26

Danke für deine Tests.

So was ist schon echt ärgerlich. Ich bin ja noch neu bei HM und hätte erwartet, dass solche "Kinderkrankheiten" nicht existieren.
Müssen wir wohl mit leben.
Ich wetten da drauf, dass es keine Updates / Firmewareupdates mehr geben wird. Auch wenn ich das für ein sehr fetten Fehler halte.
Vielleicht ist es durch Anpassung der Firmeware auch gar nicht behebbar.

Bei mir stimmt der Status in der CCU was den Keller angeht immer. Aber nur mit 0.2sec. Verzögerung mit 0,1, habe ich die selben Probleme.
Leider habe ich dennoch zwischendurch den falschen Status von anderen Kanälen. Aktuell fehlt mir aber die Zeit das zu beobachten.

Das trübt doch sehr stark die Lust auf weitere HM Module.

-Markus-
Beiträge: 109
Registriert: 10.10.2017, 17:41

Re: Status von Aktoren stimmt nicht immer

Beitrag von -Markus- » 20.05.2018, 09:20

Danke an alle für ihre bisherigen Tests.

Gibt es was Neues an dieser Front oder "lebt" ihr damit?

Hoffe ich stolpere nicht auch noch darüber - habe aktuell (inkl. Heizungssteuerung) 13 x 12/7er geplant (inkl. Reserve für Schaltbare Steckdosen usw.). Programmierung steht noch aus...

Wenn mir was auffällt werde ich berichten.

Gruß
Markus

Antworten

Zurück zu „HomeMatic allgemein“