OpenKNX-VirtualPresence release (VPM)

[Lexxs]

Masifi

Tut mir leid ich meinte den RealPresence Melder.
Die LEDs für Präsenz und Bewegung hatte ich aktiviert jedoch leuchtet keine LED. Sollten diese nur Leuchten wenn etwas detektiert wird, oder so lange wie die Nachlaufzeiten eingestellt sind?

Als Lötbrücke meinst du die "JP1", links unten neben dem DCDC Regler (grüne Platine), diese Brücke hatte ich noch nicht zusammen gelötet wenn du die meinst?

[Masifi]

Genau den JP1 schließen, dann müsste die LED darunter leuchten. Wenn nicht, dann müssen wir die Spannungen an den Reglern messen.

Ich weiß aber nicht, ob der Thread hier der richtige dafür ist, solche HW-Themen zu besprechen. Am Besten du schreibst mir weiter per PM und das Ergebnis teilen wir dann im Forum.

Und ja, dann müssten die zwei LEDs auch leuchten bei Bewegung.

[Marino]

Ich benutze den REG1-Controller2040 und habe die Big-Applikation drauf.

Nun hatte ich einen Fehler damit. Es schlich sich langsam ein, dass die Präsenzkanäle manchmal nicht anschalteten. Dazu muss ich sagen, dass ich 4 davon nutze, da ich ich 4 Steinel TP(M) habe.
Ich fand heraus, dass das Licht nicht eingeschaltet wurde, wenn ich den Raum kurz nach dem Ausschalten des Lichtes betrat. Die Nachlaufzeit lief also zu Ende und der VPM schaltete aus. Wenn ich dann direkt in den Raum betrat, blieb das Licht aus.

Nun war es erst einmal nicht so schlimm, aber ich hatte das Gefühl, es passiert häufiger und da wusste ich noch nicht, wie ich es provoziere.

Schaltung bei 2 von den 4en war wie folgt.
- Logik 1: Licht 1 ODER 2 an
- Logik 2: Ausgang Logik 1 ODER Licht 3 an
Diese sind für den Aktorstatus.

Logik 3: Presence oder TruePrecsence

So in etwa. Ich schreibe das zum verdeutlichen. Da ich mit Waldemar einmal geschaut hatte, wusste ich, dass es sein kann, dass weder Presence noch TruePresence an ist und das Signal verlängert werden muss. Daher dachte ich, es wird was an der Logik sein. Also mal die eine Logik überprüft, alles okay. Dann hatte ich keine Zeit mehr und es eilte nicht. Bis mich der Fehler wieder nervte. Dann habe ich die zweite Logik angeschaut und auch nichts gefunden...

Dann war ich auf Geschäftsreise und als ich wieder zurück war (während dessen funktionierte wohl alles), schaltete das Licht in 2 Räumen nicht mehr ein und in den anderen 2 nicht mehr aus. Also musst ich handeln. KNX-Stecker gezogen, gewartet, verbunden. Da fiel mir dann auch der Reset-Button auf.

Anschließend funktionierte alles, wie es sollte. Keine Probleme.

Der erste Fehler war also, dass das Licht kurz nach Ablauf der Nachlaufzeit und Ausschalten durch VPM nicht mehr angeschaltet wurde und der zweite dann, dass nichts mehr schaltete.

Das kurzzeitige Ziehen des Steckers half zwar, aber ich frage mich halt, wie ich rausbekommen könnte, wodurch dieser Fehler entstanden ist. Gibt es eine Möglichkeit, falls ein Fehler auftritt, dies zu debuggen? Die Logik war ja nicht das Problem, denn die lief ja und nach einem Neustart funktioniert alles, wie es soll. Ich würde halt nur gerne wissen, ob ich, falls es ein nächstes Mal gibt, etwas machen kann, wodurch wir wissen, was das Problem auslöste.



Viele Grüße
Nils

[willisurf]

Der erste Fehler war also, dass das Licht kurz nach Ablauf der Nachlaufzeit und Ausschalten durch VPM nicht mehr angeschaltet wurde und der zweite dann, dass nichts mehr schaltete

Ich kenne solch einen Fehler nicht. Welche Firmware verwendest Du genau?
Könntest Du bitte mal von einem Kanal, der sich so fehlerhaft verhält, Screenshots von allen Einstellungen und der GA Zuordnung posten?

Gibt es eine Möglichkeit, falls ein Fehler auftritt, dies zu debuggen?

Ja, es gibt ein Diagnoseobjekt, das Du in den Experteneinstellungen aktivieren kannst. An dieses Objekt kannst Du einen Text senen und damit interne Stati der Kanäle auslesen. Ich poste Morgen mal eine Beschreibung der Diagnosemöglichkeiten und der Interpretation der Ausgaben.

[Marino]

Ich nutze die "PresenceModule Big 1.7.6".
Besteht die Möglichkeit, dass beim aufspielen über USB ein Fehler passiert, der nicht angezeigt wird oder ist das ausgeschlossen, z.B. durch anschließende Prüfung oder so?

Bilder kann ich gerne machen, wenn Du meinst, dass es hilft. Ich bin da skeptisch, denn es funktioniert ja teilweises über Wochen und auf einmal nicht mehr. Seit dem Reset des Moduls (letztes Mal durch Stecker ziehen am Modul selber) läuft es wieder normal.
Dabei lasse ich mir Die Logiken in der Visu anzeigen. Nicht perfekt, ich weiß. Darin sehe ich aber, dass die Logik weiter schaltet und ein Signal geschickt wird und der Status der Aktorkanäle richtig ist.

Diagnose hört sich gut an, das würde ich auf jeden Fall aktivieren. Falls der Fehler wieder auftritt, hätte man dann wenigstens etwas, wo man suchen kann.


Viele Grüße
Nils

[willisurf]

Bilder kann ich gerne machen, wenn Du meinst, dass es hilft.

Es hilft manchmal, bzw. wird Deine Anwendung und Applikation dadurch erst klar. Wenn es zu viel Aufwand ist, kannst Du es selbst erstmal mit der Diagnose versuchen.

Wenn das Diagnoseobjekt in den Experteneinstellungen freigeschaltet ist, gibt es ein neues bidirektionales KO. Durch das Schreiben von kurzen Kommandos, alles klein, ohne Leerzeichen, zweistellige Nummern nur aus dem gültigen Bereich, wird ein Text mit den Infos zurückgegeben. Aktuell sind für den VPM folgende Kommandos implementiert (Beispiel für Kanal 02)
„p02t“ Ausgabe der Nachlaufzeit Kanal 02
„p02s“ Statusausgabe Kanal 02
“p02l“ Statusausgabe Leaving Room Kanal 02 (wahrscheinlich für Dich nicht relevant)

Die Interpretation der Ausgabe ist
Statusausgabe PM Kanal:
Kommando: p<nn>s

// "[NAM][01] A [1-4](1-4] [L-][H-][X-][R-][T-]"
// N=normal, A=auto, M=manual
// 0=off, 1=on
// D=day phase
// 1-4=current phase
// 1-4=next phase
// L=is lock, -=unlock
// H=in helligkeitsberechnung, -=normal
// X=disable brightness handling, -=normal
// R=leave Room is active, -=not active
// T=in totzeit, -=normal

Die Interpretation der Tagesphasen-Ausgabe: z.B.

D22 = Tagesphase ist 2 und soll auch 2 sein, Normalzustand.

D24 = ist 2 und soll beim nächsten AUS auf 4 wechseln. D20 = ist 2, soll-Szene wurde nicht gefunden. Intern bleibt er dann auf 2.


Leaving Room Status:
Kommando: p<nn>l

//L(OFF|TOT|T+R|B+T|BTR) T mm:ss

L sagt nur "LeaveRoom", die nächsten 3 Zeichen sind der Modus:

OFF - nicht aktiv, sollte eigentlich nicht erscheinen, da dann normalerweise "no leave room" kommt

• TOT - reine Totzeit
• T+R - Totzeit + Reset
• B+T - Bewegung + Totzeit
• BTR - Bewegung + Totzeit + Reset
• T kommt nur, wenn Totzeit gerade läuft mm:ss gibt die noch verbleibende Totzeit an.

Um eine bequeme Auslesemöglichkeit zu haben, habe ich für jede Ausgabe eine bool GA als Trigger und eine Logik (bei mir X1, Waldemar‘s Logik kann das auch) sendet beim Trigger den passenden Kommandostring auf die Diagnoseschnittstelle.
Man kann dazu die Visu benutzen, ich nehme EasyKNX. Das ist flexibler und man kann sich noch andere Statusinfos gleich mit anzeigen lassen, bzw. beeinflussen.

[Marino]

Moin Bernhard,

Danke für die ausführliche Beschreibung.

Heute morgen stand meine Frau in der Küche ohne Licht. Ich komme rein und frage, warum sie es mir nicht gesagt hat. Sie hatte es nicht gemerkt. Immer gut, direkt Bescheid zu wissen, wenn etwas nicht richtig funktioniert

Perfekter Zeitpunkt, das Diagnoseobjekt zu aktivieren, was immer noch darauf wartete. Erste Handlung von ETS (6.1.0) war ein kompletter Absturz, als ich ein Panel mit Gruppenadressen öffnen wollte. Ist wohl kein alltäglicher Task und schien zu überfordern. Also ETS neu gestartet, Diagnose mit GA verknüpft und programmieren geklickt, was nicht funktionierte. Tests mit "Geräteinfo auslesen" und "Geräteinfo (mit Gruppenkommunikation)" scheiterten ebenso.

Nach Betätigung des Reset-Knopfes am Gerät ging das Licht sofort wieder an, als ich aus dem Keller in die Küche kam.


Das ist natürlich ein Fehler, der sich deutlich schlechter nachverfolgen lässt. Wenn das Gerät nicht erreichbar ist, funktioniert die Diagnose nicht. Ich habe noch ein weiteres Modul da, auch das REG1-Controller2040 von Ing-Dom, allerdings noch nicht gelötet. Das sollte ich mal nachholen, zum Vergleich.

Ich habe auch seit ein paar Tagen einen RealPresence Melder von Mastifi hier liegen, der wird dann gleich mit vorbereitet. Bei diesem hatte ich gesehen, dass es eine Firmware 1.7.8 gibt. Daher stellt sich für mich ein paar Fragen. Kann ich 1.7.8er auch bei dem VPM-Modul (REG1-Controller2040) verwendet werden und wenn ja, ist das empfehlenswert?
Kann eine Firmware trotz augenscheinlich richtigem aufspielen fehlerhaft übertragen worden sein, so dass ein erneutes aufspielen Abhilfe schaffen würde oder wird die nach erfolgreichem Aufspielen geprüft, so dass das fast ausgeschlossen werden kann?
Es muss ja einen Grund geben, denn immerhin habe ich nun zum zweiten Mal Reset betätigen müssen, damit das Modul wieder erreichbar war und das hätte ich mit Diagnose nicht auslesen können.

Bilder der Applikation habe ich noch auf dem Zettel, bin bisher nur nicht dazu gekommen.


Viele Grüße
Nils

[willisurf]

Kann eine Firmware trotz augenscheinlich richtigem aufspielen fehlerhaft übertragen worden sein, so dass ein erneutes aufspielen Abhilfe schaffen würde

Nein, das glaube ich nicht. So wie es klingt, war es eher ein kompletter Absturz der Software, der nur durch Reset behoben werden konnte.

Solch ein Fehlerbild untersuchen mumpf und ich gerade. Es tritt sehr sporadisch und unter hohen kurzzeitigen Buslasten auf. Waldemar kann dazu im Detail mehr sagen.

Das Diagnoseobjekt könntest Du in jedem Fall aktivieren und verknüpfen, das kann dauernd aktiviert und verknüpft bleiben. Dann hast Du bei nicht direkt erklärbarem Verhalten jederzeit die Möglichkeit (falls nicht dieser seltene Absturz vorliegt) den internen Zustand anzuschauen. Parallel mache ich das auch gerne, um die manchmal komplexen Abläufe besser zu verstehen

[Marino]

Ich habe die Logik begonnen anzulegen. Das Ergebnis muss ich nur noch genauer betrachten und zerlegen, da die Ausgabe noch nicht passte und ich keine Zeit mehr hatte.

Falls ich irgendwie helfen kann, sag(t) Bescheid. Buslast zeigt meine Spannungsversorgung an und Grafana zeichnet auf. Momentan ist es auf Buslast in % gestellt, kann das aber auch auf Telegramme/s umstellen und versuchen so viele Datenpunkte, wie möglich zu generieren, falls das hilft. Beim programmieren heute morgen (Diagnose KO), ist die Buslast auf ca. 96% hoch gegangen. Gestern habe ich min. ein Gerät programmiert, wodurch also wirklich sehr hohe Buslasten erzeugt werden.
Falls ich also irgendwelche Daten beisteuern kann oder so, bitte Bescheid geben.


Viele Grüße
Nils

[willisurf]

Danke Nils, wir haben es geschafft den seltenen Fehler etwas reproduzierbarer zu machen. Falls wir Hilfe benötigen, melden wir uns.

[mumpf]

Hi Nils,

danke erstmal für die ganen Rückmeldungen. Die Versionen 1.7.6 und 1.7.8 unterscheiden sich nicht in der Funktionalität, die 1.7.8 hat nur eine Anpassung, die für die neue RealPresence-Hardware nötig ist. Die 1.7.8 sollte auch auf dem VPM laufen, ich hab es aber noch nie ausprobiert. Wird aber - wie schon gesagt - nicht bei Deinen Problemen helfen.

Buslast zeigt meine Spannungsversorgung an und Grafana zeichnet auf.

Die Buslast-Angabe der Spannungsversorgung reicht nicht, das ist immer ein längeres Mittel. Der Fehler, dem wir auf der Spur sind, passiert auch bei sehr kurzfristiger hoher Buslast (ich nenne das Burst). Dabei muss aber auch das Modul selbst auch gerade senden... und dann geht irgendwas schief . Da suchen wir noch...

willisurf und ich testen nächste Woche noch eine Situation, die wir gefunden haben. Danach werde ich eine neue - hoffentlich stabilere - Firmware rausbringen.
Mehr kann ich zur Zeit nicht versprechen. Konzeptionell bauen wir auch noch an einem Watchdog für den RP2040, das ist aber noch nicht fertig, sollte aber nicht mehr lange dauern. Und dann wird sich das Modul von selber komplett neu starten, wenn es sich so aufhängt, dass es keine KNX-Kommunikation mehrgibt.

Auch wenn das noch keine Soforthilfe ist, hoffe ich, dass Dich die Aussicht auf Besserung zufriedenstellt.

Gruß, Waldemar

[Marino]

Moin Waldemar,

das reicht mir vollkommen. Immerhin weiß ich so schon, dass ich nicht der einzige bin mit dem Fehler. So etwas zu finden, gestaltet sich mitunter schwierig, da man ja auch erst einmal herausfinden muss, wie man den Fehler überhaupt provozieren kann, um herauszufinden, warum das passiert.

Ich konnte in letzter Zeit ja bereits damit leben, also ist es nicht zu schlimm. Ich halte es dann erst einmal mit "es ist soweit, wenn es soweit ist". Immerhin seid ihr dem Fehler ja schon auf der Spur und müsst in Eurer Freizeit dafür die Zeit finden.

Und falls ich doch etwas machen kann oder testen soll, weißt Du ja, dass Du nur fragen brauchst.


Viele Grüße
Nils

[Amenophis]

Konzeptionell bauen wir auch noch an einem Watchdog für den RP2040, das ist aber noch nicht fertig, sollte aber nicht mehr lange dauern. Und dann wird sich das Modul von selber komplett neu starten, wenn es sich so aufhängt, dass es keine KNX-Kommunikation mehrgibt.

Auch wenn das noch keine Soforthilfe ist, hoffe ich, dass Dich die Aussicht auf Besserung zufriedenstellt.

Den solltet ihr dann teuer an Steinel verkaufen. Mein TP und TP Multi verliert immer noch unregelmäßig die Kommunikation mit dem BUS. Damit wäre vielleicht auch deren Fehler behoben

[willisurf]

Mein TP und TP Multi verliert immer noch unregelmäßig die Kommunikation mit dem BUS.

Wäre eine resetfähige SV eine Lösung? Der Trigger könnte problemlos über die VPM Logik o.ä. ausgelöst werden.

[Amenophis]

Das wäre eine Idee aber ich komme auch noch nicht dazu alle Logiken so anzupassen, dass sie nach einem SV reset wieder richtig laufen. Sind zu viele und zu wenig Zeit zum Test