Alternative Firmware für das Raum-Sensormodul von Masifi

[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]

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!

[Masifi]

Welche Sensoren hast du verwendet?

[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

[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

[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,

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 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

[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]

Hallo Matthias,

keine Rückmeldung ist überflüssig. Nur das, was gemeldet wird, kann ich auch berücksichtigen bzw. kommentieren. Insofern bitte immer was sagen, wenn was auffällt. Ich versuch schon, die Sachen sorgfältig zu machen, aber es rutscht eben manchmal was durch.

Bei der Firmware ist mir aufgefallen, dass default jetzt V3 ist nicht V31. Macht nichts, wenn man es weiß, widerspricht aber der Doku.

Das ist einfach erklärt: Meine Platinen sind fast alle v3.0, ich hab auch noch eine V2.0 da. Deswegen ist bei mir immer V3 eingestellt, und wenn ich ausliefere und nicht daran denke, das auf V31 zu ändern, steht da V3. Da werde ich wahrscheinlich die Doku ändern. Ich habe auch schon überlegt, für mich eine andere platformio.ini zu machen als die, die ich ausliefere, aber dann besteht die Gefahr, dass meine Entwicklungsumgebung immer mehr von der abweicht, die ihr habt. Das finde ich auch nicht so toll. Grundsätzlich bleibt für die Zukunft wichtig, dass jeder beim Update schaut, dass die eigene Version der Platine da eingetragen ist. Ich werde das nochmal deutlicher in der Anleitung hervorheben.

In der ETS wird mit das Sensormodul-v2.1-20 angezeigt, obwohl ich die -80 importiert habe und auch die 80 Logikkanäle habe ( oder zu haben scheine).

Hier gibt es mehrere Punkte, die ich nicht verstehe... aber erstmal die Fakten:

• Wenn die ETS die Applikationsversion 2.3 anzeigt, dann hast Du auch die 2.3, das ist die mit 80 Kanälen. Das siehst Du auch auf dem ersten Parameter-Bild "Allgemeine Parameter" beim Eintrag "Anzahl verfügbarer Kanäle", da sollte 80 stehen.
• Die Firmware hat IMMER 80 Kanäle, die kleineren Produktdatenbanken habe ich nur dazu gemacht, damit das Programmieren mit der ETS nicht so lange dauert. Du kannst also getrost die 80 Kanäle nutzen.

Jetzt zu dem, was ich nicht verstehe:

• Du hast die v2.3 importiert, auch die v2.3 bekommen, nur der Text des Moduls ist v2.1? Das wäre zwar nicht schlimm, aber ich kann nicht sagen, warum das so ist. Ich kann den Import der ETS nicht beeinflussen. Steht der falsche Text im Katalog? Kannst Du ein screenshot machen?
• Hattest Du vorher schon eine andere Version, z.B. die v2.1 importiert? Vielleicht ist da noch irgendwo ein Bug in der ETS, wenn die Versionen so ähnlich sind?
• Ich werde mal schauen, ob ich ähnliches hier sehe, aber ich hab jetzt so oft importiert (wirklich hunderte Testversionen) und so was bisher noch nicht beobachten können...
• Ist das Problem nachvollziehbar? Sprich: Kannst Du mir Schritte benennen wie
  • ETS starten
  • x importieren
  • y importieren
  • dann x löschen
  • z importieren -> hier ist was falsch? Dann könnte ich selber eher was finden (vielleicht)

Wenn es nur der Text ist, den kannst Du natürlich in den Eigenschaften anpassen. Ausschlaggebend ist immer die Applikationsversion.

Gruß, Waldemar

[ReinerDaniel]

Hallo Waldemar,

ich traume es fast mich es zu schreiben, aber vielleicht schaust Du Dir Folgendes noch mal an. Ich habe die Firmware neu konstruiert und auch knxprod.

Bei der Firmware ist mir aufgefallen, dass default jetzt V3 ist nicht V31. Macht nichts, wenn man es weiß, widerspricht aber der Doku.

In der ETS wird mit das Sensormodul-v2.1-20 angezeigt, obwohl ich die -80 importiert habe und auch die 80 Logikkanäle habe ( oder zu haben scheine).
Bei Applikationsversion zeigt die ETS die Version 2.3 an.
Ist das so gewünscht??

Liebe Grüße
Matthias

P.S.: Absolut tolle Arbeit. Macht Spaß

[mumpf]

Hi,

So kann man es nun in der Plattform.ini setzen wie man es braucht.

ja, auch das ist ein "Abfallprodukt" der Vereinheitlichung meiner 2.0 und 3.0 Entwicklungsschiene. Ich werde versuchen, zu 3.0 über passende PlatformIO-Environments direkt release/debug/deploy usw. zu unterstützen und so (hoffentlich) nicht mehr im Coding "rumpfuschen" müssen. Sonst ist das vor einem Release zu viel Arbeit und zu Fehleranfällig.

Gruß, Waldemar

[jeff25]

Hallo Waldemar,

danke schön. läuft ohne Probleme. Cool dass du den DDEBUG_DELAY Parameter eingeführt hattest da mein USB zu langsam war und debug nie ging ausser ich habe die "100" erhöht. So kann man es nun in der Plattform.ini setzen wie man es braucht.

Gruß
Robert

[mumpf]

Danke fürs Feedback!

Gruß, Waldemar

[murloc]

Hallo Waldemar,

der *.knxprod Build läuft nun einwandfrei durch.
Besten Dank!

Grüße