Alternative Firmware für das Raum-Sensormodul von Masifi

[ReinerDaniel]

Hallo Waldemar,

hier die Schritte:
1. ETS starten
2. Alte Sensormodule löschen
3. v2.3 importieren
4. Physikalische Adresse zuweisen (auf v2.1)
5. Applikationsprogramm aufspielen.
6. Parameter setzen und Applikation programmieren
7. Funktioniert, hat 80 Logik-Kanäle und zeigt die Programmversion 2.3
8. Nennt sich selbst aber 2.1

Ich hoffe das hilft Dir etwas.
Haben andere das nicht beobachtet?
Gruß Matthias

P.S.: Hauptsache es funktioniert.

[mumpf]

Hi Matthias et all,

danke für den Hinweis, ich weiß jetzt, was es ist: Der ETS-Katalog kann nur einen Namen für ein Produkt haben! Ich habe (auf eine Anregung hier aus dem Thread) versucht, verschiedene Namen für verschiedene Versionen zu vergeben, eben immer passend zur Kanalanzahl. Das kann der ETS-Katalog aber gar nicht. Welchen er dann genau nimmt, weiß ich nicht, wahrscheinlich den zuerst importierten.

Langer Rede kurzer Sinn: Der Versuch, verschiedene Texte für verschiedene Versionen zu nutzen, geht offensichtlich in der ETS nicht. Ich werde das beim nächsten Update der Applikation also wieder zurückbauen. Aber es ist ein reines Textproblem in ETS-Katalog bzw. die Frage, welchen Text die ETS dann in das Projekt übernimmt. Da man das in den Eigenschaften anpassen kann, tut das der Funktion keinen Abbruch.

Gruß, Waldemar

[mumpf]

Hi,

ich hab soeben ein ganz kleines Firmware-Update auf 2.1.1 hochgeladen. Ist nur eine Kleinigkeit in der Logik. Ich habe noch einen Fehler bei den Triggern gefunden.

Die interne Behandlung, wann ein Eingang, der eine Logikfunktion triggert, diese Triggereigenschaft verliert, war nicht korrekt. Das konnte dazu führen, dass auch
nicht-triggernde Eingänge die Logikauswertung getriggert haben.
Beispiel:

• E1 triggert ein UND, E2 nicht.
• E1 und E2 sind AUS.
• Wenn jetzt E1 auf AN geht, triggert er das UND, Ergebnis ist 0.
• Der Ausgang schaltet aber zeitverzögert, das Ergebnis wird also noch nicht gesendet.
• Wenn jetzt in der Zeit E2 auf AN geht, würde das AN von E2 auch triggern und das UND ein AN liefern.

Das war nicht korrekt und ist jetzt korrigiert.

Wahrscheinlich verwendet noch keiner Logiken, die so ins Detail gehen...

Für das Update muss man nur knx-sensor und knx-logic holen.

Gruß, Waldemar

[mumpf]

Hi allerseits,

falls es hier jemanden gibt, der mit den Logiken spielt, wollte ich noch eine Anmerkung loswerden: Das Logikmodul ist "superschnell", das ist auch so gewollt, aber könnte zu unerwarteten Ergebnissen führen. Ich mach mal ein Beispiel.

Ich möchte mit dem Logikmodul die Zustände meiner Fensterkontakte in einen Fensterstatus übersetzen: 0=geschlossen, 1=kipp, 2=offen. Die 2 Fensterkontakte liefern

1. FK1: 0=geschlossen, 1=offen
2. FK2: 0=offen, 1=gekippt

Es geht hier erstmal um Fensterflügel ohne Verschlussüberwachung, weil dadurch das Beispiel schöner darzustellen ist.

Als Wertetabelle ergibt sich relativ trivial:

FK1	FK2	Status
0	0	Kombination nicht möglich, trotzdem Status = 0
0	1	Status = 0 (geschlossen)
1	0	Status = 2 (offen)
1	1	Status = 1 (kipp)

Daraus ergeben sich 3 Logiken, abgebildet über 3 Logikkanäle:

1. NOT FK1 -> Sende 0
2. FK1 AND FK2 -> Sende 1
3. FK1 AND NOT FK2 -> Sende 2

An sich wäre jetzt die (statische) logische Betrachtung jetzt vorbei. Man hat einen Eingangs-Zustand und bekommt einen Ausgangs-Zustand.
Was passiert aber in Wirklichkeit, wenn man auf den Bus guckt? Nehmen wir mal an, ich mach das Fenster auf, ich erwarte also den Übergang von geschlossen=0 auf offen=2. Ich sehe aber beim öffnen:

• 1 (kipp)
• 2 (offen)

Manchmal (selten) passiert aber das "Richtige", es wird nur folgendes gesendet

• 2 (offen)

Wieso? Das sieht zufällig (zumindest nichtdeterministisch) aus. Der Grund ist natürlich die dynamische Komponente, genauer gesagt die Zeit! Wir haben ein telegrammbasiertes System, bei dem die Informationen nacheinander eintreffen, selbst bei Ereignissen, die von der Wahrnehmung und Erwartung gleichzeitig passieren. Wenn man auf den Gruppenmonitor schaut, wird im Fall kipp/offen folgendes gesendet:

• FK1 = 1 (der obere Kontakt hat zuerst ausgelöst)
• FK2 = 0 (dann erst der untere)

Da erstmal das FK1 = 1 Telegramm ankommt (zu dem Zeitpunkt ist FK2 ja noch 1) und das Logikmodul das superschnell auswertet, wird der Status 1 (kipp) gesendet. Dann kommt erst FK2 = 0 an, woraufhin dann der Status 2 (offen) gesendet wird.

Der andere Fall, dass nur 2 (offen) gesendet wird, passiert dadurch, dass manchmal - selten - die Telegramme "andersrum" auf dem Bus landen (ich vermute, weil wirklich der untere Reedkontakt zuerst aufgeht):

• FK2 = 0 (der untere Kontakt löst zuerst aus)
• FK1 = 1 (dann erst der obere)

Bei FK2 = 0 (FK1 ist hier auch noch 0) reagiert der Kanal 1 der Logik aber gar nicht, da dort FK2 keine Rolle spielt, somit sendet er keinen Status 0. Und Kanal 2 und 3 der Logik sind nicht erfüllt, senden also auch nichts.
Somit wird erst gesendet, wenn FK1 = 1 ist, und dann gleich Status = 2.

Warum erzähle ich das Ganze? Beim entwickeln von Logiken neigt man dazu, immer nur die statischen Zustände zu berücksichtigen und bedenkt die dynamischen Einflüsse (also die Telegrammreihenfolge) nicht genügend. Im Kopf hat man immer das Bild, dass ja BEIDE Kontakte was senden und bedenkt nicht, dass sie es trotzdem NACHEINANDER machen. Die dynamischen Einflüsse auf dem KNX-Bus machen es teilweise auch schwer, native KNX-Logiken ohne Seiteneffekte zum Laufen zu bekommen, vor allem, wenn es sehr einfache Logikfunktionen sind, die es bei einigen Geräten als "Beigabe" gibt.

Ich habe bei der Entwicklung des Logikmoduls versucht, auch auf dynamische Einflüsse reagieren zu können. Dies wollte ich auch hier mal zeigen. Um beim obigen Beispiel zu bleiben: Ziel ist es, eine deterministische Ausgabe zu bekommen, also immer "Status 2", ohne dem Zwischenschritt "Status 1".

Hier nutzt man die Tatsache aus, dass die Telegramme zeitlich kurz nacheinander kommen. Das ist auch vernünftig, denn solches quasi "nichtdeterministische" Verhalten kommt sowieso nur bei Telegrammen vor, die zeitlich kurz nacheinander und potentiell in vertauschter Reihenfolge kommen.

Jeder Logikkanal hat eine Ein- und Ausschaltverzögerungskomponente. Hier kann man nicht nur einstellen, wie lange der Kanal sein Ein- bzw. Ausschaltsignal verzögern soll, sondern auch, was passieren soll, wenn während der Ein- bzw. Ausschaltverzögerung ein weiteres Telegramm eingeht. Gehen wir das mal abstrakt durch: Ich schalte was ein, das Einschaltsignal wird um 1 Minute verzögert. Was kann jetzt in dieser einen Minute passieren:

• Es kann ein Ausschaltsignal kommen.
  • Das kann man ignorieren und weiter den Timer für die Einschaltverzögerung laufen lassen -> es wird noch immer nach einer Minute eingeschaltet
  • Es wird ausgeschaltet. Da der Ausgang zu dem Zeitpunkt noch aus ist, passiert einfach gar nichts, intern wird die Einschaltverzögerung logischerweise aber zurückgesetzt.
• Es kann ein weiteres Einschaltsignal kommen.
  • Das kann man ignorieren und weiter den Timer für die Einschaltverzögerung laufen lassen -> es wird immer noch nach einer Minute eingeschaltet.
  • Das kann man dazu nutzen, um den Timer zu verlängern, es wird also von den Zeitpunkt des neuen Einschaltsignals aus eine Minute gewartet, bis eingeschaltet wird.
  • Das kann man dazu nutzen, den Timer zu übersteuern und sofort einschalten.

Alle diese Möglichkeiten stehen für jeden Logikkanal sowohl für die Ein- wie auch für die Ausschaltverzögerung zur Verfügung. Aber wie hilft das bei dem obigen Beispiel?

Für den Fall, dass FK2 zuerst und dann FK1 auslöst, muss man nichts machen, es kommt sowieso Status = 2 raus. Ich habe beobachtet, dass die beiden Telegramme im Abstand von 50ms bis 80ms kommen. Also wird Logikkanal 2 folgendermaßen angepasst:

• FK1 UND FK2 -> Einschaltverzögerung 100ms, beim vorzeitigen AUS sofort ausschalten und nichts senden -> Sende 1

Jetzt kommt FK1 = 1 an (FK2 ist noch 1), die UND-Logik sendet eine 1 an die Einschaltverzögerung, die jetzt 100ms wartet.
Nun kommt FK2 = 0 an, die UND-Logik sendet jetzt eine 0 (also AUS) an die Einschaltverzögerung, dann sofort ausschaltet und nichts sendet.
Der Logikkanal 3 sendet unabhängig davon den Status 2.

Durch die kurze Verzögerung und passende Einstellungen, wie auf Telegramme während der Verzögerung reagiert werden soll, kann man unerwünschte Zwischentelegramme ausfiltern und so ein deterministisches Verhalten bekommen.

Summary:
Die Möglichkeit, in den Signalweg einer Logikausgabe einzugreifen, hört sich kompliziert an, bietet aber die Möglichkeit, das Verhalten zu erreichen, dass man haben will. So etwas bietet meiner Meinung nach derzeit kein anderes KNX-Natives Logikmodul. Bitte bedenkt die dynamischen Einflüsse bei der Entwicklung euer KNX-Logiken, das ist eigentlich unabhängig von diesem Logikmodul, da dies immer passiert, wenn Telegramme nacheinander ankommen. Bei meinem Modul macht es sich aber potentiell besonders bemerkbar, weil alle Telegramme sehr schnell verarbeitet werden. Da man aber die Möglichkeit hat, die Prozessierung bewusst zu verlangsamen, kann man gut solche Probleme lösen.

Gruß, Waldemar

[mumpf]

Hi allerseits,

ich habe soeben Version 2.4 freigegeben. Diesmal gibt es auch eine neue ETS Applikation - bzw. wieder vier. Es sind die Versionen 2.4 bis 2.7. Wie üblich mit jeweils 10, 20, 40 und 80 Logikkanälen. Ein Update funktioniert ohne Einschränkungen.

Was ist neu? Man kann den Buzzer und die RGB-LED über ein KO global sperren, so kann man z.B. verhindern, dass es nachts piept oder leuchtet. Einzelne Kanäle können als Alarmkanäle markiert werden, diese Kanäle können nicht gesperrt werden, die piepen bzw. leuchten dann trotz Sperre.

Ich habe die Version aber vor allem gemacht, weil es für mich eine Vorbereitung für die Version 3 ist. Es wird Ende des Monats ein Release von v3 geben, die dann auch 1-Wire enthalten wird. Der 1-Wire-Teil wird dann noch Beta sein, denn ich denke, dass es nötig sein wird, für 1-Wire ein Feedback von der Community zu bekommen.

Das Release heute enthält die interne Vorbereitung dafür, dass wirklich nur ein Teil der Firmware im Beta-Status sein kann. Ich habe die Teile so weit aufgeteilt, dass die neuen 1-Wire-Teile nicht aufgerufen werden, wenn 1-Wire nicht aktiviert ist. Damit wird verhindert, dass Entwicklungen am 1-Wire irgendwie das Sensormodul oder das Logikmodul stören. Somit können alle, die kein 1-Wire brauchen, trotzdem die zukünftige Firmware nutzen, ohne befürchten zu müssen, dass sie eine Beta-Version bekommen. Und mir erspart das, Firmware und ETS-Applikationen für mehrere Releases zu pflegen.

Bis zur Version 3.0 wird das das letzte Release sein.

Gruß, Waldemar

[ReinerDaniel]

Hallo Waldemar,

ich schreibe das mal hier, weiss aber nicht ob es eventuell auch ein Hardware-Thema ist.
Bei mir hat sich das Modul nach vier Tagen "aufgehangen".
Soll heißen über das keine Werte mehr gesendet wurden. Über die ETS nicht ansprechbar.
Über den Gruppenmonitor keine Reaktion. Applikationsprogramm nicht programmierbar (Abbruch, da nicht erreicht).
Nach Ziehen des Bus-Steckers lief es dann wieder (jetzt seit zwei Tagen).
Werde das mal beobachten.
Wenn es wieder auftritt: Welche Information würde helfen den Fehler einzugrenzen?
Was sollte ich ggf. tun?
Gruß Matthias

[Masifi]

Welche Sensoren hast du verwendet?

[mumpf]

Hi,

Bei mir hat sich das Modul nach vier Tagen "aufgehangen".

das soll natürlich nicht sein. Hier wäre es - wie Matthias schon schrieb - interessant die angeschlossene Hardware zu kennen. Und ob andere Besonderheiten vor dem Ausfall aufgetreten sind, z.B. der Buzzer lief längere Zeit, KNX-Bus hatte 100% Auslastung, Sensor hatte Wackelkontakt oder wurde nass, Blitzeinschlag beim Nachbarn, anderes Gerät gerade an den KNX-Bus angeschlossen etc, etc. Irgendwas, dass vielleicht ein Fehlverhalten auslösen könnte.

Ich hatte sporadische Ausfälle vom SCD30 mit ähnlichen Symptomen, allerdings war da auch noch ein BME680 mit an Bord, und die hatten ziemlich sicher zusammen zu wenig Strom. Da werde ich wieder dran arbeiten, wenn die 1-Wire-Sachen released sind. Derzeit rate ich eher vom SCD30 ab, da demnächst der SCD40 kommen wird, der günstiger ist - wobei noch nicht klar ist, ob der stromsparender ist...

Sag einfach Bescheid, was für Sensoren Du dran hast, dann sehen wir weiter.

Gruß, Waldemar

P.S.: Auch wenn es in der Anleitung steht, ich erwähne es nochmal: Die Hardwareauswahl in der Applikation muss unbedingt zu der vorhandenen Hardware passen, bitte das nochmal prüfen, das bei falscher Auswahl es auch zu sporadischen Hängern kommen kann!

[ReinerDaniel]

Hallo Waldemar und Matthias,
ist nach zwei Tagen wieder aufgetreten. Ich habe die Hardware-Version V3.1 mit der aktuellsten Firmware. Sensor ist der SCD30 (allein).
Buzzer und Logiken sind nicht aktiviert. Sind auch nur wenige GA verbunden. Ich habe Euch zur Eingrenzung mal ein paar Screenshots aus der ETS gemacht.
Außerdem logge ich einige Werte. Ich habe mal einen Screenshot vom "Einfrieren" gemacht. Buslast war was die Telegramm-Rate angeht minimal. mA auf dem Bus
auch völlig okay (logge ich auch). Die gelbe LED am SCD30 leuchtet.
Soweit erst mal. Ich lasse das ganze jetzt mal so, wie es ist. Dann könnt Ihr sagen, welche weiteren Informationen Euch weiter bei der Eingrenzung helfen könnten.
Gruß Matthias

P.S.: Sieht auf dem LOG so aus, als wäre das Modul exakt 0:00 ausgestiegen. Ist aber nicht so. Die letzten aktualisierten Werte wurden um 0:30 gesendet.

[mumpf]

Hallo Reiner,

ok, SCD30 alleine hat bei mir keine Probleme gemacht. Die Hänger, die ich hatte, waren nur in Verbindung mit dem BME680. Allerding muss ich gestehen, dass ich im letzten halben Jahr mich so sehr auf 1-Wire konzentriert habe, dass ich die Sensoren etwas aus dem Fokus verloren habe. Ich kann Dir eine kurzfristige Lösung anbieten, die langfristige wird - wie der Name schon sagt - länger dauern.

• kurzfristig: Ich werde einen Watchdog implementieren. Das ist eine Schaltung, die Prozessorintern feststellt, dass er sich aufgehängt hat und dann den Prozessor neu startet. Ich habe das schon mal ausprobiert, es funktioniert auch, nur kann man damit nicht debuggen. Außerdem bekommt man mit einem Watchdog genau solche Hänger nicht mehr mit, wodurch meine Tests ja nicht aussagekräftig wären. Deswegen ist der Watchdog nicht in der Firmware drin, aber für "Enduser" macht der durchaus Sinn.
• langfristig: Ich werde ein Testmodul wieder mit dem SCD30 konfigurieren und schauen, ob bzw. wann der Fehler bei mir auftaucht, muss mir aber vorher überlegen, wie ich solche sporadischen Fehler überhaupt analysieren kann, wenn sie nach 2 Tagen (oder 2 Wochen oder 2 Jahren) auftauchen. Denn wenn sich das Modul aufgehängt hat, komme ich ja auch nicht mehr dran. Ich habe da Ideen, die erfordern aber noch einige Programmierarbeit (Ringpufferspeicher im EEPROM und passendes Logging mit "möglichst selten in EEPROM schreiben").

Für den Watchdog werde ich noch ca. 1 Woche brauchen, ich muss das alte Coding nochmal ausgraben und an die aktuelle Firmware anpassen. Es wird eine neue Compiler-Option geben, um den Watchdog einzuschalten. In einer zukünftigen ETS-Applikation kann ich mir auch vorstellen, dass ich das von da aus schaltbar mache, aber auch die ETS-Applikationen machen viel Arbeit, ist somit nichts für kurzfristige Lösungen.

Nochmal eine allgemeine Anmerkung zum Watchdog: Für reine Sensoren sind Watchdogs eine gute Lösung, um Hänger zu vermeiden. Ein solcher Neutstart geht schnell und der Sensor liefert wieder seine Werte. Das Einzige, was auffällt: Nach dem Neustart kommt ein Messwert außer der Reihe, also z.B. schon nach 2 Minuten und erst dann wieder alle 5 Minuten. Halte ich gegenüber einem Hänger (also keine Werte) für vertretbar.

Wenn man Logiken nutzt, muss man diese so aufbauen, dass sie stabil gegenüber einem Neustart sind, der ja jederzeit vorkommen kann. Keiner will mitten in der Nacht vom Buzzer geweckt werden. Das Logikmodul erlaubt sehr viele "Startup-Einstellungen", um das möglichst feingranular steuern zu können. Allerdings muss man das auch machen! Wenn man also Logiken macht und den Watchdog benutzt, muss man die Logiken nicht nur auf Funktion, sondern auch auf Neustartverhalten testen. Der komfortabelste Weg hier ist in der ETS "Gerät zurücksetzen". Man kann diesen Befehl aber auch über eine Logik auslösen und z.B. auf eine Taste legen. So kann man in der Testphase jederzeit spontan das Gerät zurücksetzen und sehen, ob es Seiteneffekte bei Neustart gibt.

Das was der allgemeine Teil... für Dich, Reiner, heißt das:

• Ich muss Dich bitten, auf die Watchdog-Lösung zu warten. Ich rechne mit ca. 1 Woche (also grob Ostern).
• Du könntest als Workaround versuchen, das Modul per Zeitschaltuhr 1 mal nachts zurückzusetzen und so neu zu starten. Alles notwendige liefert das Modul selbst (Stichworte: Zeitschaltuhr, Ausgang sendet "Gerät zurücksetzen", PA vom Modul selbst). Falls Du nicht weißt wie, frag nochmal.
• Ich werde unabhängig davon (aber erst nach dem 1-Wire-Release) eine Analysemöglichkeit für sporadische Fehler schaffen, um solchen Hängern in Zukunft hoffentlich besser auf die Schliche kommen zu können.

Hoffe, dass ist soweit ok für Dich,

Gruß, Waldemar

P.S.: Das mit der gelben LED ist ein guter Tipp, die kontrolliere ich! Ich muss mal schauen, wann ich die überhaupt einschalte und wann aus, der Fehler muss ja dazwischen passiert sein!

[Masifi]

Die gelbe LED am SCD30 leuchtet.

mumpf ich denke er meint die gelbe LED die bei jedem Messvorgang am SCD30 leuchtet und nicht die LED auf dem Sensormodul.
ReinerDaniel Sehe ich das mit der LED richtig? leuchtet diese LED wirklich dauerhaft, oder blinkt sie alle 2sek?

[mumpf]

Oh,

das wäre ein Symptom, dass ich noch nie gesehen habe! Die Sensor-LED ist ja für den Messvorgang selbst vorgesehen, die kontrolliere ich natürlich nicht. Und ich kann mir auch nicht vorstellen, warum das passiert. Insofern wäre das eine wichtige Info!

Gruß, Waldemar

[ReinerDaniel]

Hallo Waldemar,
vielen Dank für Deine lange email. Ist natürlich völlig in Ordnung; keine Eile.
Ich habe noch mehr Module fertig und wollte das Modul auch einfach einmal tauschen; nicht das es eine kalte Lötstelle oder so ist.
Würde dann ein anderes Modul genauso parametrieren und mal abwarten, was passiert.

> Matthias: Ja, ich meine die gelbe LED am SCD30. Diese blinkt alle 2 sec. Heißt für mich, die Platine bekommt Strom und misst auch, oder?
Das langsame Aufblinken alle zwei sec. ist doch normal bei der SCD30, oder?
Gruß Matthias

[mumpf]

Hi Matthias (und nicht Reiner - sorry, Dein Username hat mich in die Irre geführt),

das Blinken alle 2 Sekunden ist normal. Ich hatte Dich erstmal so verstanden, dass diese LED dauerhaft an geblieben ist. Das wäre was neues gewesen.

Wie gesagt, ich mach mich an die Ursachensuche, aber das wird dauern. Bei Deinem Setup wird aber auch der Watchdog helfen. Und wie gesagt, Du kannst auch mal checken, ob ein tägliches Zurücksetzen des Moduls helfen würde. Das einzige, was bei Dir auffällig ist, ist die Häufigkeit der Ausfälle: Meine Hänger passierten eher nach Wochen, nicht nach Tagen.

Gruß, Waldemar

[st400]

hi mumpf,

wie funktioniert das denn eigentlich mit dem Neustart, wenn die Firmware im Deadlock festhängt? Geht das per Interrupt o.ä.? Ich habe leider von Mikrocontroller keine Ahnung, finde das Thema aber super spannend.

Was mich auch interessieren würde: wäre auch die Anbindung eines Ultraschallsensors wie z.B. der HC-SR04 denkbar?

PS: Super Arbeit die du da mit der Firmware umgesetzt hast.
VG Stefan