KNX - Enocean - Gateway: 5 Prototypen suchen 5 Tester

[willisurf]

Ist schnell erklärt. Mir ist gerade eingefallen, wo mein Fehler liegt.

Ich benutze EasyKNX und habe auch die EnOcean Ausgänge damit bisher beobachtet. EasyKNX sendet ein ReadRequest und damit kommt natürlich die Botschaft.
Ich werde einfach die Rohbits nicht mehr in EasyKNX einlesen und die Logik entsprechend konfigurieren, dann kann ich bis zu den ersten EnOcean Botschaften jeweils Fenster Zu auswerten.

Also alles gut, kann so bleiben. Sorry für die Konfusion.

[Masifi]

Ich weiß nicht on es so bleiben sollte. Ich muss das selber mal ausprobieren, wenn man zyklisch senden aktiviert hat, welcher Wert dann geschickt wird, solange nach einem Reset noch keine gültige Enocean Botschaft mit dem Zustand empfangen wurde.

Was wäre hier am Besten:

• wenn solange keine KNX Botschaft geschickt wird, bis die Enocean Nachricht mit dem aktuellen Zustand kommt ?
• immer ein Wert für Fenster zu gesendet wird?

ich denke wohl ersteres.

[willisurf]

Ja, das denke auch. Nichts senden ist wohl am sinnvollsten, wenn noch keine EnOcean Botschaft empfangen wurde.
Ich habe aber überhaupt kein Problem, da ich nicht zyklisch senden benutze.

[mumpf]

Hi Mat und Bernhard,

ihr habt da einen spannenden Fall, der mir auch als Argumentationshilfe für thesing hilft! Wenn man mal diesen Gateway-Fall betrachtet, dann haben wir eine Situation, bei der ein KO so lange keinen sinnvollen Wert liefern kann, wie die ENO-Seite keinen Wert liefert. Und da man die ENO-Seite nicht aktiv fragen kann, kann das auch längere Zeit andauern.

Ich hab nämlich im KNX-Stack eine Modifikation gemacht, bei der ein KO auf einen ReadRequest nicht antwortet, solange es nicht initialisiert ist. Sobald es initialisiert wird, sei es von innen (also über die Firmware) oder von außen (über einen WriteRequest), ist alles gut. Aber solange es nicht initialisiert ist, sendet es auch keinen "unsinn". Ich brauch das auch für die Logik. Warum soll eine Logik ein AUS senden, solange sie noch nicht einmal gelaufen ist?

Warum schreibe ich das? Mat, in diesem Falle könntest Du das auch gebrauchen. Solange nach einem Neustart ein ENO-Gerät noch nichts gesendet hat, weißt Du eigentlich nicht, welchen Wert das KO annehmen soll. Und eigentlich ist es auch falsch, wenn das KO dann auf einen ReadRequest antwortet, denn bis zu diesem Zeitpunkt hat es noch gar keinen Wert!

Konsequenterweise sollte das KO auch nichts senden, wenn es auf zyklisch senden steht, also solltest Du die erste Option für zyklisch implementieren.

Das ist ein schönes Beispiel außerhalb von Logiken (ist ja mein "Steckenpferd"), das zeigt, dass ein KO auch mal einen undefinierten Wert haben kann.

willisurf: Du kannst Dein Problem aber auch mit der Logik elegant lösen. Führe den ENO-Ausgang auf einen Logikeingang und sage dort

Eingangswert speichern und beim nächsten Neustart als Vorbelegung nutzen: JA

Ausgang soll bei jeder Änderung senden (oder bei jedem Telegramm, was immer Du brauchst) und das nimmst Du dann als eigentlichen Wert für alles andere.

Damit bekommst Du nach einem Neustart immer den letzten gespeicherten Wert. Ist prima geeignet für kurze Aussetzer, wie eben neues programmieren. Falsch wird es, wenn es einen längeren Stromausfall gibt und sich zwischendurch der Fensterzustand ändert (werden geschlossen/geöffnet). Dann bekommst Du beim Wiederanlaufen erstmal falsche Werte... aber einen Tod muss man sterben, ich schaue immer bei solchen Sachen, welcher Fall häufiger passiert.

Gruß, Waldemar

[willisurf]

Eingangswert speichern und beim nächsten Neustart als Vorbelegung nutzen: JA

Hallo Waldemar,
sehr gut. Danke für den Tipp!

Das ist natürlich noch viel besser, wenn der Zustand gespeichert wird. Der Anwendungsfall ist ja im Moment genau das regelmäßige Programmieren, da ich die Logiken nach und nach in viele Dinge mit einbaue.

[vogelsang]

Ich sehe das genau so. Einerseits sollte man den letzten Wert speichern können. Andererseits sollte es eine Möglichkeit geben, einen undefinierten Zustand sinnvoll (sicher) vorzubelegen.

[Masifi]

Eingangswert speichern und beim nächsten Neustart als Vorbelegung nutzen: JA

ich weiß jetzt nicht ob das so einfach mögllich ist. Ich habe in der HW nie das Logikmodul vorgesehen, daher ist kein externes EEPROM verbaut.

mumpf: kann man sowas auch im internen Flash als EEPROM Ersatz nutzen?

Andererseits sollte es eine Möglichkeit geben, einen undefinierten Zustand sinnvoll (sicher) vorzubelegen.

wie meinst du das genau?

[vogelsang]

wie meinst du das genau?

Ein Beispiel: Das Gateway kennt den Zustand eines Fensters nicht und er konnte auch nicht gespeichert werden. Wenn ich jetzt die Meldung bekomme "Fenster ist offen", dann kann ich hin gehen und nachschauen. Dann evtl. den Zustand nachführen.
Bei einem Fenster, das beim verlassen des Hauses geschlossen sein soll, ist es mir lieber nachzuschauen, als es ungewollt offen stehen zu lassen. Die Vorbelegung sollte möglich sein, da einige offen = 1 und andere offen = 0 nutzen.

[Masifi]

Ab

Wenn ich jetzt die Meldung bekomme "Fenster ist offen", dann kann ich hin gehen und nachschauen. Dann evtl. den Zustand nachführen.

Wenn du dann schon an dem Fenster stehst, dann machst du das doch am Besten indem du das Fenster kurz auf und wieder zu machst, dann wird der aktuelle Zustand an das Gateway gesendet.

Du hast immer das Problem wenn der letzte Wert nicht gespeichert wurde, das du nach einem neu programmieren nicht weißt, was das Fenster für einen Zustand hatte.

Erster Workaround dafür: bevor ihr das nächste mal neu parametrisiert, schließt alle Fenster

[Masifi]

larsrosen dein Paket kam an und der Teachin funktioniert auch direkt. Auch die Display Orientierung kann ich drehen per Parameter (wer es braucht) Sieht soweit also gut aus. Weitere Infos folgen

[larsrosen]

Noch schlimmer ist es bei ABB.

Wenn hier das GW Programmiert wird müssen alles Stellantriebe erstmal von Hand betätigt werden. Warum auch immer.

Die Hoffnung stecke ich deshalb jetzt in Masifi. Das es damit besser läuft.

Die Fenster bzw. alle ENO Geräte die nicht zyklisch senden verhalten sich so. Das finde ich auch gut. Ein Zustand speichern mag ich gar nicht an der Stelle.


edit

perfekt. Sag ja vieles ging schon. Da bei mir zwei Eno GW noch im Betrieb sind was das testen sehr schwierig bei mir.

[willisurf]

Spannend ist die Frage, ob der Vorschlag von Waldemar mumpf mit der Hardware des EnOcean Gateway funktioniert. Aber wahrscheinlich wird es ohne EEProm nicht möglich sein.

[Masifi]

Wenn hier das GW Programmiert wird müssen alles Stellantriebe erstmal von Hand betätigt werden.

da der Stellantrieb nicht weiß das mein Gateway neu parametrisiert wurde, sehe ich keinen Grund warum ich die Taste noch einmal drücken müsste.

[willisurf]

Ein Zustand speichern mag ich gar nicht an der Stelle.

Naja, über einen Programmiervorgang zu Zustand -wahlweise- speichern zu können, fände ich schon elegant. Wer es nicht haben möchte, könnte es dann ja ausschalten.

[mumpf]

Ich habe in der HW nie das Logikmodul vorgesehen, daher ist kein externes EEPROM verbaut.

Hi,

da hat Mat natürlich vollkommen Recht!!! Ohne EEPROM geht GA speichern gar nicht. Ich erinnere mich, dass ich sogar diese Option beim Logikmodul auf dem ENO-GW gar nicht anbiete! Insofern ginge diese Option nur, wenn man auch noch ein Sensormodul hat.

Aber die von vogelsang gewünschte Vorbelegung kann so gelöst werden.

kann man sowas auch im internen Flash als EEPROM Ersatz nutzen?

Sobald wir den Flash komplett unter Kontrolle haben (ich bin dran) kann man dann GA ohne EEPROM speichern. Das dauert aber noch...

Das gute daran: Es geht dann mehr, einfach per Firmware-Update

Gruß, Waldemar