HB-UNI-SenAct-8-8 nur kurzen Impuls am Relaisausgang

[HeikoGr]

Ich könnte ja nicht 0 an writeWire übergeben, sondern vorher den Buffer auf Null setzen:

Code: Alles auswählen

inline static void setHigh     (uint8_t pin) {
          getBuffer().data |= bit(pin);
          writeWire((getBuffer().data & getBuffer().mode));
	  delay(5);														
	  getBuffer().data = 0x00;		                                         // .mode bleibt gleich								
          writeWire((getBuffer().data & getBuffer().mode));             
      }

Damit wird der PCF-Port zumindest nach dem delay wieder ausgeschaltet.
Trotzdem bleibt er in der GUI auf "EIN" stehen und der Status in der CCU stimmt scheinbar auch noch nicht.
Wenn ich in der GUI nochmal auf "Ein" drücke, ändert das am Port gar nichts mehr. Ich muß ihn in der GUI erst richtig "ausschalten" und dann kommt beim nächsten Einschalten der Impuls wieder.


Noch eine andere Frage zum Aktor:

Genau wie beim HM-MOD-EM-8 werden die Eingangsports scheinbar erst nach dem ersten Schalten korrekt übertragen.
D.h. nach dem Anlernen stehen die Ports auf "Verschlossen", obwohl sie ggf. offen sind.

Das war beim HM-MOD-EM-8 schon nicht so optimal, da ich nach dem Anlernen bzw. nach einem Reboot der CCU alle Fenster kurz öffnen/schließen musste (werden per Reedkontakt abgefragt), um den aktuellen Zustand richtig zu erkennen.

Lässt sich das ggf. implementieren, dass direkt nach dem Anlernen und dann später, um ein CCU Reboot abzufangen, zyklisch die Ports übertragen werden?

VG Heiko

[jp112sdl]

Der EM-8 ist aber kein Aktor sondern ein Sender
Das mit dem Reboot bei Sendern ist ein bekanntes "Problem" bei der CCU, ist aber der Tatsache geschuldet, dass Sender nicht geweckt werden können, um den aktuellen Status abzufragen.

Im Gegensatz zu einem Sender wird ein Aktor beim Reboot der CCU jedoch aktiv nach seinem Status gefragt, so dass der angezeigte Status dann stimmt.

[HeikoGr]

Der EM-8 ist aber kein Aktor sondern ein Sender

Ja, das ist klar. Ich meinte in Analogie zu den 8 Sensorkanälen des HB-UNI-SenAct-8-8 .

Man könnte aber doch trotzdem die Sensorkanäle alle paar Minuten übertragen, egal, ob sich was geändert hat oder nicht.
Das natürlich in Abhängigkeit davon, ob er mit Batterie versorgt wird oder per Netzteil.

Die Zustände der Ausgänge werden doch auch zyklisch übertragen - zumindest nehme ich das anhand der CYCLETIME an.
Dort unterscheidest Du auch, ob Batteriebetrieb oder nicht.

VG Heiko

[jp112sdl]

Man könnte aber doch trotzdem die Sensorkanäle alle paar Minuten übertragen, egal, ob sich was geändert hat oder nicht.

Ok, um Missverständnisse auszuschließen - du sprichst von der -SC Variante? Ich war bisher beim -RC.

Die Zustände der Ausgänge werden doch auch zyklisch übertragen - zumindest nehme ich das anhand der CYCLETIME an.

Nein, da werden nur die Zustände der Schließerkontakte übertragen.

Dort unterscheidest Du auch, ob Batteriebetrieb oder nicht.

Lediglich die Abstände sind unterschiedlich. Zyklisch gesendet wird in jedem Fall, bei Batterie- und Netz-Variante.

Ich wollte so wenig wie möglich an der CCU-WebUI verbiegen.
SC-Geräte haben alle einen cyclic timeout, deshalb so auch hier.

[HeikoGr]

Ok, um Missverständnisse auszuschließen - du sprichst von der -SC Variante? Ich war bisher beim -RC.

Ja, genau.

Ich wollte so wenig wie möglich an der CCU-WebUI verbiegen.

Durch die Asksin Kommunikation bin ich leider noch nicht wirklich gestiegen. Aber was hat das Senden von Zuständen an den Eingängen mit der Webgui zu tun? Es geht doch nur darum, wann und ggf. wie oft die Eingangszustände übertragen werden. Auslöser für das Senden ist doch der Sensor (Änderung am Eingang). Kann man nicht programmgesteuert nach dem Anlernen oder nach einer bestimmten Zeit (cycletime) die Arduino Eingänge abfragen und deren Zustände an die CCU senden?

[jp112sdl]

Nehmen wir als Beispiel ein beliebiges HM Device mit ShutterContact.
https://asksinpp.de/rftypes/rf_sc.xml

Man muss unterscheiden zwischen zyklischen Telegrammen (INFO_LEVEL) und den Telegrammen bei Änderungen eines Zustands (EVENT).
Letzteres führt dazu, dass die ReGa Programme getriggert werden.

- Angenommen du nimmst die zyklischen Telegramme und erhöhst die Häufigkeit der Aussendung:
Zustand in der CCU stimmt zeitnah. Ändert sich der Eingang, wird kein CCU Programm getriggert.

- Angenommen du sendest in Intervallen immer wieder den Ist-Zustand der Eingänge:
Zustand in der CCU stimmt zeitnah. Auch wenn sich der Eingang nicht ändert, werden jedes Mal die CCU Programme getriggert.

Kann man nicht programmgesteuert nach dem Anlernen

Ich versteh noch nicht ganz.
Warum nach dem Anlernen? Das Anlernen macht man 1x... Wenns dann nicht gleich stimmt, ist doch nicht so schlimm?

oder nach einer bestimmten Zeit (cycletime)

Das passiert ja bereits.


Du könntest natürlich einen neuen Gerätetyp bauen, der z.B. eine ActionCommandMsg entgegennimmt.
Beim Starten der CCU schickst du durch ein Programm getriggert einen Befehl an dein Device (sofern es wach ist), das darauf hin eine außerplanmäßige zyklische Mitteilung sendet.

So ähnliche mache ich es beim RFID Leser... die in der WebUI angezeigten Chip-IDs sind nach einem Reboot auch immer leer.
Um diese wieder zu befüllen, schickt der RFID-Leser die IDs nach einem Reboot der CCU.

[HeikoGr]

Warum nach dem Anlernen? Das Anlernen macht man 1x... Wenns dann nicht gleich stimmt, ist doch nicht so schlimm?

Bei 8 Fenstern ist das nicht so elegant. KLar, es kommen auch nicht jede Woche wieder welche dazu...

HeikoGr hat geschrieben: ↑
01.12.2019, 17:16
oder nach einer bestimmten Zeit (cycletime)

Das passiert ja bereits.

Aber doch nur für die Relaisausgänge oder wo wird das für die Sensoreingänge erledigt?

Hier sehe ich nur den switch.Channel:

Code: Alles auswählen

void trigger (AlarmClock& clock)  {
          set(CYCLETIME);
          clock.add(*this);
          dev.switchChannel(1).changed(true);
        }

VG Heiko

[jp112sdl]

Ja stimmt. Es reicht wenn sich das Gerät irgendwie mal meldet. Hatte dann wohl den Switch Channel genommen. Ist auf jeden Fall nicht best practice.