Alternative Firmware für das Raum-Sensormodul von Masifi

[marhal]

mumpf alles Klar ich wollte auch kein Stress machen Es ist ja schließlich ein Hobby. Und die Ampel ist halt auch nicht lebensnotwendig, aber halt eine nette Beigabe. Also mach in ruhe nur ein feedback wäre nett dann...

Gruß
Marco

[Amenophis]

Hallo Waldemar,
ich habe heute erfolgreich ein V3.1 Modul mit BME680 in Betrieb genommen. Werde die Tage mal damit rum spielen. Sieht auf jeden Fall schon mal sehr cool aus.

Dann habe ich noch eine Frage. Ich habe von Mat noch ein altes V3.0 Board bekommen. Eine entsprechende Firmeware habe ich erstellt und geflashed. Muss ich dafür auch eine eigene knxprod Datei erstellen oder kann ich die vom V3.1 dafür nehmen?

[mumpf]

Die knxprod ist Hardwareunabhängig. Die passt für alle Module!

Die Hardware-Versionen von Mat unterscheiden sich primär in der Pinbelegung (wo hängt der PROG-Button, die PROG-LED, der SAVE-Eingang usw.). Das kommt durch unterschiedliches Platinen-Layout. Darauf muss ich in der Firmware reagieren. V3.0 ist nicht "alt", es macht wirklich keinen Unterschied... Ich habe fast ausschließlich v3.0 bei mir im Haus.

Gruß, Waldemar

[Amenophis]

Alt war in dem Zusammenhang darauf bezogen, dass es schon 3.1 gibt und ich so eins habe. Keine Abwertung, dass es schlechter ist

Alles klar, dann nutze ich da die gleiche prod und erstelle keine separat. Danke für die schnelle Rückmeldung.

[Amenophis]

Habe mich heute mal wieder mit den Logiken beschäftigt und dazu eine Frage. Die Zeitschaltuhr Funktion hat keinen eigenen Eingang für eine Sperre und lässt sich auch nicht aktivieren, hierzu muss man vermutlich eine zweite Logik dahinter setzen, oder habe ich etwas übersehen?

[mumpf]

Genau. Nimm ein TOR, das ist eine negierte Sperre.

Gruß, Waldemar

[Amenophis]

Bei Tor muss ich noch durchsteigen. Dank dir

[mumpf]

Das ist sehr einfach:
Ein TOR ist wie ein Tor :

• Ist das Tor auf, geht alles vom Eingang auf den Ausgang durch.
• Ist das Tor zu, dann geht nichts vom Eingang auf den Ausgang durch

Interessant ist dann noch, was in dem Augenblick passieren soll, wenn die Tür aufgeht (öffnen) oder wenn sie zugeht (schließen):

• am einfachsten ist es, wenn gar nichts passiert
• oder es wird fest ein EIN gesendet
• oder es wird fest ein AUS gesendet
• oder es wird der Wert gesendet, der am Eingang anliegt

Einfaches Beispiel: Ich will eine Zeit lang ein Licht gegen das Einschalten vom PM sperren (wohlgemerkt, nicht den PM sperren). Wenn die Sperre aktiv ist, dann soll das Licht aus sein. Wenn die Sperre inaktiv ist, dann will ich natürlich das Licht durch den PM steuern. Und wenn die Sperre aufgehoben wird, dann will ich, dass das Licht angeht, falls der PM es schon angemacht hätt.

Das wäre dann ein TOR mit invertiertem Tor-Eingang (bei mir sind das Eingang 2 und Y), beim schließen ein AUS senden und beim öffnen den Wert vom Eingang senden.

Würde man beim öffnen nicht den Wert vom Eingang senden, würde das Licht erst angehen, wenn der PM es das nächste mal einschalten möchte und nicht schon beim Aufheben der Sperre.

Gruß, Waldemar

[Amenophis]

Danke für deine immer wieder verständlichen Ausführungen zu Logiken. Das und die Anleitung zu den Logikkanälen hat mir wieder sehr geholfen weiter zu kommen

[Amenophis]

Ich bräuchte nochmal deine Hilfe mumpf Habe mir jetzt mal das Tor angesehen aber zur Ausgangs Einstellung habe ich noch eine Frage. Ich will ja, dass die Daten einfach weitergeleitet und nicht verändert werden. Also wähle ich aus DPT für Ausgang (DPT 17.001 Szene), weil Szenennummern rein kommen. Dann wähle ich am Ausgang bei EIN "Ja - Wert von Eingang 1", damit der Wert durchgereicht wird, wenn das Tor auf ist. Welche Auswirkungen hat das Feld AUS? Würde hier eine Meldung ergehen, wenn das TOR zu ist (das stelle ich ja eigentlich schon vorher ein) oder in welchem Fall wäre diese Einstellung bei einem TOR relevant? Wurde aus deiner Anleitung zur Logik dazu leider auch nicht ganz schlau. Sorry.

Noch ein zweiter Punkt, wenn ich Rechtschreibfehler in der Anleitung oder in der ETS finde, magst du die wissen? Ansonsten sehr umfangreiche Anleitung, die mir schon oft geholfen hat. Vielen Dank dafür

[mumpf]

Hi Etienne,

ich versuch das noch auf eine andere Art zu beschreiben und Szenen mit einzubeziehen:

1. Ich habe kein TOR für Szenen (hab ich bisher bei keiner KNX-Logik gesehen), man kann Szenen mit dem TOR verwenden. Das ist ein feiner Unterschied, der hoffentlich nach dieser Erklärung klarer wird.
2. Wie schon in der Anleitung beschrieben, funktionieren alle Logiken (also auch das TOR) rein binär, also nur mit 0 und 1. Man kann bei den Eingängen bestimmen, wie der Eingangs-DPT in eine 1 bzw. 0 gewandelt wird und am Ausgang, was bei einer 1 bzw. 0 gesendet werden soll.
3. Will man ein TOR mit einem anderen DPT als DPT1 verwenden, muss man quasi 2-Gleisig denken: Wie ist der Datenfluss der Logik (nur aus 0 und 1 bestehend) und wie ist der Datenfluss meines Ziel-DPT (in dem Fall Szene, DPT 17.001)

Betrachten wir den binären Datenfluss:

• Beim offenen TOR werden sowohl 1 wie auch 0 durchgelassen. Die Frage ist, ob Du bei Szenen überhaupt zwischen 1 und 0 unterscheiden willst. Ich gehe mal von NEIN aus. Du listest einfach jede Szene, die es auf dieser GA gibt, im Eingangskonverter auf, so dass jede Szene eine 1 ergibt.
• Jetzt kannst Du am Ausgang nur bei 1 senden, Wert ist gleich Eingang 1, bei 0 sendest Du nichts. Ist das TOR offen, werden alle Szenen weiter geleitet, ist es zu, wird nichts gesendet.
• In so einem Fall hast Du die 0 noch frei. Du könntest also sagen, dass das TOR beim schließen eine 0 senden soll und für die 0 sendest Du z.B. eine Szene "alles aus".
• Oder Du zählst nicht alle Szenen im Eingangskonverter auf, dann senden einige Szene eine 1 und alle anderen eine 0. Dann hast Du die Freiheit, bei 1 den Wert vom Eingang 1 zu senden und bei 0 nichts -> das ist ein Szenenfilter. Oder Du sendest bei 0 wieder eine Szene "alles aus", dann machst Du aus einer Szene eine andere.

Ich will damit sagen, dass das Senden bei AUS genau das selbe macht was das senden bei EIN macht: Das was Du einstellst .

Falls das jetzt nicht klarer wurde, musst Du Dein Szenario beschreiben, dann finden wir eine konkrete Lösung für Dein Problem.

Gruß, Waldemar

P.S.: Rechtschreibfehler immer gern, korrigiere ich dann. Keiner ist perfekt...

[Amenophis]

Deine Erklärung konnte ich nachvollziehen hat aber ein Problem mit dem Eingang. Hier mal die Erklärung was ich machen will:

Ich will um 17 Uhr Szene 3 starten und um 4 Uhr Szene 4. Das soll aber nur im Winter (0) passieren. Was habe ich gemacht:

Logik1:
Zeitschaltuhr bei jedem Eingangstelegram
Schaltzeiten: Tagesschaltuhr 17 Uhr EIN | 04 Uhr AUS
Ausgang: Alle Optionen nein, DPT für Ausgang DPT1, EIN = Wert vorgeben EIN | AUS = Wert vorgeben AUS

Logik2:
Tor Funktion
Eingang 1 (Macht das Tor auf oder zu) = invertiert aktiv
Kanalausgang X (Dateneingang vom Tor) = normal aktiv
Eingang 2: DPT1
Kanalausgänge verbinden = 1 (Ausgang von Logik1)
Ausgang: Alle Optionen nein, DPT17 EIN = Szene 3 | AUS = Szene 4

Damit müsste es ja eigentlich klappen, werde es mal testen. Bei meinem ersten Versuch hatte ich in Logik1 schon die Szene als Ergebnis ausgegeben. Das habe ich jetzt geändert. Dabei ist mir übrigens aufgefallen, dass man, wenn man Kanäle verbindet, keine Werte für eine Szene vorgeben kann, wie von dir oben vorgeschlagen. Das nur so am Rande.


Rechtschreibfehler:
In der Doku auf Github:
- "Physilalische Adresse"

Edit:
Habe es jetzt ein paar mal geteste, das scheint zu funktionieren.

Jetzt habe ich eine weitere Logik angelegt da ist mir aber ein neues Problem aufgefallen. Kann es sein, dass die Zeitschaltuhr Sonnenuntergang minus Zeitversatz nicht ausgelöst wird? Ich habe das jetzt ein paar mal versucht und bei plus Zeitversatz klappt es aber bei minus wird nie ein EIN gesendet.

Hier mal die Konfig:
Operation: Zeitschaltuhr, bei jedem Eingangstelegram
Schaltzeiten: Tagesschaltuhr, Feiertage nicht beachten, Nachholen nein, Sonnenuntergang minus Zeitversatz (Std. + min variert eingestelt)
Ausgang: Alle Optionen nein, DPT Ausgang DPT1, EIN Wert vorgeben EIN, AUS Wert vorgeben AUS

[mumpf]

Hi Etienne,

Zum Zeitversatz:
ich hab mal im Coding nachgeschaut, das ist soweit symmetrisch (gleiche Routine für plus und minus Zeitversatz). Aber ich werde es mal die nächsten Tage ausprobieren und im Zweifelsfall debuggen.

Zum Rest kann ich nur sagen: Schön dass es funktioniert.

Eingang 1 (Macht das Tor auf oder zu) = invertiert aktiv

Hier meinst Du Eingang 2.

Dabei ist mir übrigens aufgefallen, dass man, wenn man Kanäle verbindet, keine Werte für eine Szene vorgeben kann, wie von dir oben vorgeschlagen. Das nur so am Rande.

Das habe ich nicht vorgeschlagen . Du hast es vielleicht so verstanden. Ich kann immer nur wiederholen, was in der Anleitung steht und was konsequent durchgezogen ist: Intern arbeitet das Logikmodul NUR mit 0 und 1 (also ein Bit für einen Wert). Insofern geht es gar nicht, dass eine Szene in irgendeiner Form beim verbinden von Kanälen vorgegeben wird, da es eine interne Verbindung ist. Eine Szene geht nur extern über GA. Man könnte aber den Ausgang der Zeitschaltuhr auch mit der Logik über GA (sprich: extern statt intern) verbinden. Allerdings ist Deine Lösung gut wie sie ist, das hier war nur zur Erklärung.

Und vergiss nicht, beim schließen vom Tor noch ein AUS zu senden, sonst wird beim Umschalten von Winter auf Sommer womöglich Szene 4 nicht "beendet", je nachdem, wann die Umschaltung passiert. Und der Vollständigkeit halber würde ich beim öffnen vom Tor den Eingangswert senden. Aber das muss nicht sein, man bekommt ja den Wert in der darauffolgenden Nacht...

Gruß, Waldemar

[Amenophis]

Hallo Waldemar,

also meine Variante aus #492 klappt, vielen Dank für die Hilfe.

Heute ist mir eine neue Idee gekommen, was sehr cool wäre. Ich hatte die Idee, dass die Weihnachtsbeleuchtung in der Zeit vom 2. Advent bis zum 06.01 leuchtet und danach automatisch ausgeschaltet wird. Aktuell behelfe ich mir dabei noch mit FHEM. Natürlich wäre es cooler, wenn das Ganze nativ abgebildet werden kann, getreu dem Motto so viel in KNX, wie möglich. Die nächste Idee war dann, dass es super wäre, wenn die Zeitschaltuhr auf Feiertage reagieren könnte. Soll heißen, dass ein Signal bei bestimmten Feiertagen anstelle von Uhrzeiten / Tagen gesendet wird. Ich weiß, dass du viel um die Ohren hast und das ein absolutes Freizeitprojekt ist aber vielleicht magst du die Idee ja in dein Backlog aufnehmen

[mumpf]

Ich weiß, dass du viel um die Ohren hast und das ein absolutes Freizeitprojekt ist aber vielleicht magst du die Idee ja in dein Backlog aufnehmen

Jetzt muss ich gemein sein und Dich etwas "frei" zitieren:

... vielleicht magst Du die Anleitung nochmal genau lesen und die Applikation studieren, dann siehst Du, dass es schon geht

Sorry, das musste jetzt sein...

Zitat aus meiner Applikationsbeschreibung https://github.com/mumpf/knx-logic/b...ibung-Logik.md:

Ferner können Feiertage und Urlaubstage bei den Zeitpunkten berücksichtigt werden. Dabei kann bestimmt werden, ob die Schaltzeitpunkte:

• Urlaub/Feiertage nicht beachten sollen
• Bei Urlaub/Feiertag nicht schalten sollen
• Nur bei Urlaub/Feiertag schalten sollen
• Einen Urlaub/Feiertag wie Sonntag behandeln sollen

Dies erlaubt sehr flexible Zeitschaltuhren für Urlaub/Feiertage.

Ein Feiertagskalender für Deutschland incl. Osterberechnung und Adventsberechnung ist integriert.

Viel Spaß damit und wie immer: Bitte Fehler melden...
Gruß, Waldemar

P.S.: Auch wenn ich glaube, dass es funktioniert - lege keinen Schaltzeitpunkt zwischen 2 und 3 Uhr Nachts, nur um mir bei der Sommer-/Winterzeitumstellung einen Fehler zu melden. Ich vertraue hier auf die EU und denke, dass sich solche Fehler "von alleine" lösen werden

P.P.S.: Sommer-/Winterzeitumschaltung sollte derzeit von außen (also über den Bus) kommen, intern funktioniert noch nicht richtig.