KNX-Busausfall erkennen

[ivande]

gibt es in Konnekting ein Flag (z.B. isActive() ) oder an der BCU um den Ausfall des KNX-Busses zu erkennen? Mir fällt dazu nur ein, die BCU-Spannung zu überwachen oder Telegramm-Aktivität zu Überwachen, wenn eine bestimmte Zeit keine Telegramme mehr erkannt werden.

Wozu dienen an der BCU der Saveb und Resetb Anschluss?

Gruß Ivan

[Masifi]

Dafür ist das SafeB signal. Du musst aber genug C haben um auf das Event zu reagieren.

Die SW wäre viel zu langsam das zu erkennen.

PS.: OH meine Aussage bezieht sich zumindest für einen Busspannungsausfall, vielleicht hast du es anders gemeint ;-)

[ivande]

Dafür ist das SafeB signal. Du musst aber genug C haben um auf das Event zu reagieren.

ich denke du meinst genug C haben, um den µController noch ein paar Sekunden zu versorgen. - Den Versorge ich nicht vom Bus - sondern aus getrenntem Akku. Bei Busspannungsausfall soll der µC auf eine Art "Notprogramm" umschalten. Für SafeB bräuchte ich aber noch einen Optokoppler, da ich den NCN mit adum1201 vom Bus isoliert habe. Deswegen meine Frage, da ich vermute, dass es in Konnekting vielleicht schon ein Flag für Businaktivität/Ausfall gibt?

Gruß Ivan

RESETB− and SAVEB−pin
The RESETB signal can be used to keep the host controller in a reset state. When RESETB is low this indicates that the bus voltage is too low for normal operation and that the fixed DC−DC converter has not started up. It could also indicate a Thermal Shutdown (TSD). The RESETB signal also indicates if communication between host and NCN5120 is possible. The SAVEB signal indicates correct operation. When SAVEB goes low, this indicates a possible issue (loss of bus power or too high temperature) which could trigger the host controller to save critical data or go to a save state. SAVEB goes low immediately when VFILT goes below 14 V (due to sudden large current usage) or after 2 ms when VBUS goes below 20 V. RESETB goes low when VFILT goes below 12 V. RESETB− and SAVEB−pin are open−drain pins with an internal pull−up resistor to VDDD.

[Ing-Dom]

Deswegen meine Frage, da ich vermute, dass es in Konnekting vielleicht schon ein Flag für Businaktivität/Ausfall gibt?

Sobald die Verbindung zum NCN gestört ist, macht Konnekting einen µC-Reset und hofft auf das Beste.
Dieses Verhalten könnte man optimieren, es auf jeden Fall parametrierbar machen.

[ivande]

Sobald die Verbindung zum NCN gestört ist, macht Konnekting einen µC-Reset und hofft auf das Beste.

µC-Reset wird doch nur beim "Konnekting.init" gemacht, fällt der KNX-Bus erst im laufenden Betrieb (loop) aus, startet der µC bei mir nicht neu.

[Eugenius]

Ich glaube hier werden viele Sachen vermischt:
- Normallerweise wird "Hauptprozessor" in einem KNX-Gerät aus BUS-Spannung gespeist. D.h. Wenn KNX BUS weg ist (z.B. KNX Netzteil ist abgeraucht), dann ist auch Hauptprozessor stromlos. Man kann zwar mit ein paar Kondensatoren paar Sekunden weiterlafen (und auf SAVE-Signal reagieren). Aber was macht man damit? Über KNX Bus etwas noch mal senden wird nicht mehr gehen. Aktuelle Daten im eigenem Flash/EEPROM speichern schon.
- Wenn man wirklich z.B. eMail wenden möchte, wenn BUS weg ist, dann braucht man etwas mit Internetanbindung (z.B. ESP8266), extra Spannungsversorgung usw.

Wie man sieht, hängt es vom Use-Case ab...

[Ing-Dom]

hm ja das kann sein.

Insofern wäre eine SW-Lösung nicht verkehrt für Fälle wo man die schnelle Reaktion per Save nicht braucht.
Und bei genau diesen Fällen (sep. Versorgung) hat/braucht man auch die galv. Trennung, heißt Einlesen des SavePins wird aufwändiger wegen zusätzlichem Optokoppler.

Ich könnte mir ein Callback Vorstellen das aus dem knx.task heraus eine Behandlung des "Verbindungsaubbruchs zum Transceiver" in der Applikation möglich macht.
Müsste man sich knx.task mal genau anschauen was da eigentlich genau passiert wenn der nicht antwortet bzw. wie das überhaupt genau abläuft.

[Ing-Dom]

- Wenn man wirklich z.B. eMail wenden möchte, wenn BUS weg ist, dann braucht man etwas mit Internetanbindung (z.B. ESP8266), extra Spannungsversorgung usw.

Wie man sieht, hängt es vom Use-Case ab...

Ja, ich könnte mir aber schon vorstellen dass es Anwendungsfälle gibt wo man bei Busspannungsausfall auf ein Notprogramm schaltet auch ohne Ersatzverbindung.
z.B. man nimmt den "sicheren" Zustand ein, als was man auch immer das definiert.

Vielleicht sagt ivande was zu seinem konkreten Anwendungsfall.

[ivande]

Anwendungsfall1:
Eingenbau ( Konnekting:-) ) KNX - DMX Interface:

Das DMX-Interface "verwaltet" 15 Räume mit max 8 PWM-Kanäle je Raum, und bis zu 10 verschiedenen Szenen je Raum
Die Licht-Szenen für jeden Raum können mit je zwei Knx Taster ausgewählt werden. Ein Taster für Ein/Aus (für Besuch (Oma)) und der zweite Taster für Szene++;
Langklick auf jeden der Taster springt direkt zu einer vorausgewählten Szene. (doppelklick und 2 Taster gleichzeitig sind geplant, jedoch noch nicht realisiert/benötigt)
PM schaltetet ebenfalls eine vorausgewählte Szene. Szene 0 = Schlafen PM aus;
Einstellen der Lichtszenen funktioniert leider noch nicht ganz optimal, läuft mit yaml-File über SmartHome und über Smart-Visu einstellbar.

DMX-Gateway läuft schon ein paar Jahre (mit ein paar Macken und offenen Software-Baustellen. Beim Experimentieren freut sich dann meine Frau, wenn nichts mehr geht)

Die 24V LED Beluchtung unserer beschiedenen Behausung (mit DMX-PWM-Aktoren) hab ich kürzlich auf Akkuversorgung umgerüstet.
Derzeit über 1x 12V Blei-Akku mit Step-UP-Wandler auf 24V, welcher kontinuierlich vom 230V-Netz nachgeladen wird.

Bei Stromausfall ist dann auch der Knx- Bus stromlos. das DMX-Interface soll die Beleuchtung auf Minimum reduzieren(eigenen Szene),damit der Akku ein paar Stunden hält. Am Verteilerschrank/Büro und evtl. im Flur soll automatisch ein schwaches Dauerlicht(Notlicht aktiviert werden.

noch zu Realisieren:
Die Lampengruppen können dann über 2xTaster und mini lcd Display am µC per Menü im Notbetrieb ein-Ausgeschalten werden , (Not-Steuerung).
Da ich mit dem SAMD21 Timing und Ram Probleme bekommen habe, bin ich, anstatt den Code zu optimieren, derzeit dabei alles auf SAMD51 (ItsyBitsy M4 / platformIO) umzugestalten.

Gruß Ivan

[Ing-Dom]

Die Lampengruppen können dann über 2xTaster und mini lcd Display am µC per Menü im Notbetrieb ein-Ausgeschalten werden , (Not-Steuerung).
Da ich mit dem SAMD21 Timing und Ram Probleme bekommen habe, bin ich, anstatt den Code zu optimieren, derzeit dabei alles auf SAMD51 (ItsyBitsy M4 / platformIO) umzugestalten.

Falls deine Hardware noch in der Steckbrett-Phase ist schau dir mal mein KRS-XL an. Dass passt nicht ideal weil 9TE doch etwas groß sind und den den Platz unten gar nicht brauchst, aber es wäre soweit fertig und hat alles was du brauchst:
ItsyBitsy M0 oder M4, BCU (wahlweise galv. getrennt), Display, 4 Taster
Bei ernsthaftem Interesse schicke ich dir ein Controller Board gegen Porto.

[Eugenius]

ivande du beschreibst Anwendnungsfall für SAVE-Signal von BCU
Das Ding wird LOW sobald Bus-Spannung unter xx Volt fällt -> z.B. Stromausfall.

[Ing-Dom]

du beschreibst Anwendnungsfall für SAVE-Signal von BCU

stimmt schon, man KANN das mit dem SAVE-Signal lösen, braucht dazu aber nen Opto, Eingang etc...

Wenn man es auch in SW lösen könnte, für die Fälle wo das Timing nicht kritisch ist weil der µC extern versorgt wird, reduziert das den HW-Aufwand. Hat auch seinen Charme.

[Eugenius]

Wie willst du es denn in SW lösen?
Du weißt schon, dass es auch auf BUS stundenlang still sein kann -> keine "ping"-Telegramme.
Das Einzige was mir so im Kopfschwebt: NCN noch ansprechbar oder nicht...
Aber ehrlich? Opto und gut ist es.

[Ing-Dom]

Das Einzige was mir so im Kopfschwebt: NCN noch ansprechbar oder nicht...

genau das.

[Eugenius]

Na dann viel Erfolg
An dem Punkt war ich auch schon mal... damals habe ich aufgegeben. Evtl. hast du mehr nerven dazu