Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Also die TP Melder machen mich fertig. Habe ich heute den neuen Melder gegen den alten getauscht und folgendes festgestellt:
Ich habe das KO69 („Präsenzausgang Präsenz“) in Nutzung, da ich den TP Multi an dieser Stelle als Slave nutze. Allerdings geht das KO auf den Status „Aus“, obwohl in der App noch ganz klar zu lesen ist, dass True Presence erkannt wird. Es wird sogar die korrekte Entfernung in der App angezeigt. Ich dachte erst, dass ich den reinen Präsenzausgang (KO82) gewählt hätte aber es war vorher ja auch immer so eingestellt und nach Prüfung konnte ich den Fehler ausschließen. Selbst bei großen Bewegungen hat er kein Signal an den Master gesendet. Ich habe dann auch mal den Gruppenmonitor bei mehreren Versuchen mitlaufen lassen und konnte immer wieder das gleiche Problem ausmachen. Dann habe ich zum Testen mal den Lichtausgang 1 an den Slave Ausgang mit Helligkeit->Tagbetrieb deaktiviert angeschlossen und hatte vorerst keine Probleme. Aber eigentlich sollte zwischen dem Lichtausgang und dem KO69 ja kein Unterschied sein, denn das KO69 ist ja genau für die Master/Slave Verbindung und es zeigt immer True an, wenn TruePresence oder reine Präsenz erkannt wurde. So zumindest lauf Anleitung.
Habe das Problem jetzt mal an Steinel gemeldet, mal sehen, was die dazu sagen.
Ich befürchte die ganze Logik innerhalb des Steinel True Presence ist nicht praxistauglich, insbesondere bei Master / Slave Betrieb und ggf. Halb-Automatik, usw.
willisurf nutzt den Steinel ja mittlerweile nur noch als Datenlieferant und hat die PM Logik in einem VPM abgebildet. Das ist auch das was ich derzeit plane. Die Sensorik ist toll / einzigartig, aber von Software-Entwicklung und KNX hat Steinel nicht den Hauch einer Ahnung ;-).
Weil das KO69 ja die Ausgabe für beide zusammen ist. Hier sollte im Standard ja die Oder-Logik schon verbaut sein. Natürlich könnte man jetzt diesen Fehler von Steinel damit auch noch umgehen aber es ist doch verrückt, dass das nun auch nicht richtig funktioniert
Finde ich gut, dass ihr euch an den Support wendet. Verstehe aber nicht wie Steinel es sich leisten kann die vielen Melder zu tauschen und keine Bestrebungen anstellt die Situation zu verbessern?
Es scheint ja kein triviales Problem zu sein, sonst hätte sich das bestimmt schon gelöst. Offensichtlich besteht es auf der Software Seite, zumindest aus meiner Sicht. Wenn man es wirklich lösen wollen würde, kann man das auch schaffen. Sage ich jetzt mal so, im jugendlichen Leichtsinn.
für den VPM kannst Du besser die KO 81 und 82 vom TP nehmen.
Ich habe auch noch den VPM vor mir als Aufgabe, habt ihr ein gut funktionierendes Szenario an Parametern und KO-Verknüpfung für mich, damit ich nicht wieder Stunden meines Lebens an den Steinel TP verliere
Weil das KO69 ja die Ausgabe für beide zusammen ist. Hier sollte im Standard ja die Oder-Logik schon verbaut sein.
Naja, der Präsenzausgang ist mehr als ein OR der beiden Rohwerte "Presence" und "TruePresence". Du hast das die typischen Kanaleigenschaften wie Nachlaufzeit, Sperre, zyklisch senden etc. mit drin. Und damit ein höheres Fehlerpotential, vor allem, wenn vor einem Release nicht wirklich auf breiter Front getestet wird.
Außerdem zur Info: Der VPM wertet durchaus die Signale "Bewegung" (beim TP Presence) und "Präsenz" (beim TP TruePresence) unterschiedlich aus. So wird z.B. bei Kurzzeitpräsenz nur Bewegung herangezogen und nicht Präsenz, da man in einem Szenario "Ich gehe nur kurz zum Kühlschrank" oder "Ich druchquere nur kurz den Raum" gerade die Information, ob da jemand still im Raum sitzt, nicht haben will. Der eigentliche Algorithmus ist komplizierter, ich wollte nur anmerken, dass auch im VPM zwischen "Bewegung" und "Präsenz" nicht nur ein OR programmiert ist. Mit Deinem Ansatz, nur den Präsenzkanal des VPM zu nutzen, verlierst Du in gewissen Bereichen die Möglichkeiten für weiteres "Finetuning" des VPM. Braucht man aber zugegebenermaßen nur, wenn man die komplizierteren VPM-Funktionen nutzen will.
crewo Wie Waldemar geschrieben hat und dann noch die Helligkeit an den VPM und Du kannst vernünftig arbeiten. Bei Fragen einfach kurz im VPM Thread schreiben.
Kurzes Update: Leider geht das Fehlverhalten (keine TP-Erkennung) auch mit dem Update der Firmware [0] 2.2 | 2 inzwischen weiter. Es war jetzt ca. 14 Tage Ruhe, aber inzwischen geht es wieder los. Das ist absolut ärgerlich. Steinel will mich im nächsten Schritt telefonisch kontaktieren. Hat da jemand Erfahrungswerte, auf was Steinel raus will?
Schade hatte gedacht das es mit dem Update erledigt ist. Da mein Austauschgerät nach ca 3 Wochen wieder die selben Probleme hat.
Also werde ich denen das Ding wohl wieder zurück schicken. Beim letzten Austausch hat man mir sogar Geld zurück angeboten, da keine Austauschgeräte vorhanden waren. Aber bringt mir ja auch nix, da es keine Alternative gibt.
Hast Du die Möglichkeit über gelb/weis 24V an die Dose zu bekommen, dann wäre der thePixa vielleicht eine alternative.
Klar völlig anderes Prinzip aber immerhin funktioniert hier wohl die Erkennung zuverlässig.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar