- √ - RTR Betriebsmodus umschalten mit 1 Byte Objekt

[kakaiser]

Hallo Martin

Okt, danke, das probier ich nachher aus.

Gruss Karsten

Gesendet von meinem cm_tenderloin mit Tapatalk

[kakaiser]

ok, super das hat soweit funktioniert für die Gruppenadresse.

Wenn ich nun die einzelnen RTRs ändern will - und das gemäss der o.g. Doku muss ich dann für jeden Status eine einzelne adresse anlegen oder gibt es eine andere möglichkeit?

Das KNX programmieren macht leider mein Elektriker - und dann müsste ich den nochmal kommen lassen.

[udo1toni]

Naja, die RTR müssen schon jeder einzeln ansprechbar sein. Wenn die alle auf der gleichen Gruppenadresse hören, kannst Du sie nicht einzeln adressieren.
Die Gruppierung kannst Du bequem in openHAB erledigen, allerdings gibt es dann auch eine erhöhte Buslast, weil ja jeder RTR einzeln angesprochen werden muss, falls es keine Zentraladresse gibt.
Aber Du änderst ja die Betriebsart nicht alle paar Sekunden ;-), die Buslasterhöhung dürfte sich also in Grenzen halten.

[kakaiser]

ok, dann muss der Elektriker nochmal kommen.

Aber einen habe ich noch - ich habe o.g. Skript im Betrieb - aber leider kommen die RTR in eine art Endlosschleife wenn ich über OH die Betriebsart umstelle. Und so kann ich die Betriebsart nur einmal umstellen und dann läuft gefühlt die Rule forever -weil das Item ja ein uppdate bekommt. Ich kann das nur mit einem killen des OH Servers beenden.

Irgendeine Idee?

danke
karsten

[udo1toni]

Nimm statt update changed. Das troggert nur, wenn sich der Wert geändert hat.

Gesendet von meinem Nexus 4 mit Tapatalk

[udo1toni]

Vertippt... Nicht troggert... triggert, wollte ich schreiben...

Gesendet von meinem Nexus 4 mit Tapatalk

[mitchgehtab]

Hallo,

ich weiß, der Beitrag hier ist etwas älter aber vllt. kann mir noch jemand einen Tipp geben.
Ich hab mehr oder weniger die gleiche Rule für OH2 und KNX Binding 1.11 wie udo1toni aber sobald ich beim Heizungsaktor die Frostschutz GA (durch ETS manuell oder durch einen Fensterkontakt betätige) springt der Betriebsmodus von Frost nicht zurück auf Komfort (der Status vor Frost) sondern in den Standby.

Weiß einer von euch warum?

Hier meine Items:

Number R05_Heizung_Betriebsmodus "Modus" (gR05, gHeizung) { autoupdate="false", knx="5.005:4/2/4" }
Number R05_Heizung_Betriebsmodus_HVAC (gR05, gHeizung) { autoupdate="true", knx="<5.005:4/2/2" }

und hier die Rule:

rule "r05hvac"
when
Item R05_Heizung_Betriebsmodus_HVAC changed
then

logInfo("hkl-rule", "triggered")
var set = 0
if (R05_Heizung_Betriebsmodus_HVAC.state instanceof DecimalType) {
var value = R05_Heizung_Betriebsmodus_HVAC.state as DecimalType
if ((value.intValue().bitwiseAnd(0x08)) == 0x08) {
// R05_Heizung_Betriebsmodus.postUpdate(4)
set = 4
}
else if ((value.intValue().bitwiseAnd(0x04)) == 0x04) {
// R05_Heizung_Betriebsmodus.postUpdate(3)
set = 3
}
else if ((value.intValue().bitwiseAnd(0x02)) == 0x02) {
// R05_Heizung_Betriebsmodus.postUpdate(2)
set = 2
}
else if ((value.intValue().bitwiseAnd(0x01)) == 0x01) {
// R05_Heizung_Betriebsmodus.postUpdate(1)
set = 1
}
logInfo("hkl-rule", "set:" + set + " , recv:" + value)
}
end

Wie ihr sehen könnt, update ich R05_Heizung_Betriebsmodus nicht mal, sondern gee nur eine Info in die Logs.

2017-12-25 14:21:45.743 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 34 to 33
2017-12-25 14:21:45.764 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 2 to 1
>>> jetzt ist er im Komfort Modus
2017-12-25 14:21:53.739 [ome.event.ItemCommandEvent] - Item 'R05_Heizung_Betriebsmodus_HVAC' received command 40
2017-12-25 14:21:53.745 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 33 to 40
2017-12-25 14:21:53.762 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 1 to 4
>>> jetzt ist er im Frostmodus, weil ich ein Fenster auf habe
2017-12-25 14:22:01.736 [ome.event.ItemCommandEvent] - Item 'R05_Heizung_Betriebsmodus_HVAC' received command 34
2017-12-25 14:22:01.747 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 40 to 34
2017-12-25 14:22:01.771 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 4 to 2
>>> jetzt hab ich es Fenster zu und er geht in Standby. Sollte aber in den Komfort gehen.

Wenn ich die Rule deaktiviere passiert nichts.

[udo1toni]

In openHAB2 gibt es immer noch den Fehler, dass ein postUpdate auf den Bus geschickt wird (lustigerweise nur bei knx) Es gab schon diverse Korrekturversuche dazu, aber bisher hat niemand eine Lösung. Es gibt auch mindestens ein Update für knx1, welches seit Monaten darauf wartet, gemerged zu werden. Ich bin deshalb bisher mit meinem Produktivsystem nicht umgestiegen (ich bin auf 1.8.0, da gab es noch echte Slider in der Classic UI (war nur kurze Zeit verfügbar, weil die auch einen Fehler haben).
Egal, mein System läuft, und solange kein sauberes knx binding da ist, bleibe ich auf 1.8.

Leider tritt dieser Fehler offensichtlich nicht bei jedem auf. Außerdem hat wohl nicht jeder der wichtigen Entwickler ein knx System, so dass es halt auch nicht genug nervt, oder soll ich sagen: die richtigen Leute genug nervt?

[mitchgehtab]

Ja das ist mir auch schon direkt aufgefallen, dass alles nochmal auf den Bus geschickt wird.
Die Begründung, das OH ja als Bridge zwischen 2 Bindings dienen soll, ist ja auch nachvollziehbar aber dann muss das vom KNX Binding erkannt werden, was vom OH Bus kommt und was vom Binding und dass darf dann nicht nochmal gesendet werden.

Ist in der Tat ärgerlich.

Aber unabhängig davon, was mich wundert ist, wo kommt die 2 her? Wieso schickt OH2 eine 2? Sollte ja eigentlich eine 1 sein, weil vorher Komfort aktiv war. Bzw. der Aktor sollte ja 0x21 (HVAC) schicken und durch die Rule eine 1 (Betriebsmodus) gesetzt (und durch das komische Verhalten) auf den KNX Bus geschickt werden. Wird ja aber nicht. Es wird eine 2 geschickt. Ich verstehe nicht warum oder wo die her kommt.

[udo1toni]

Naja, zu 2 wechselt er, weil das 2. Bit gesetzt ist (34 -> 0010 0010)

Der Witz (leider in dem Fall ein schlechter) ist, dass die Kopplung zwischen Bindings unter OH1.8 sehr wohl funktioniert, und zwar ohne dass wahllos alles auf den knx Bus geschickt wird, egal wo es her kam. Dieses Fehlverhalten tritt ausschließlich unter OH2 auf. postUpdate darf per Definition gar nicht auf Bindings wirken, tut es aber. Daten dürfen nur über die jeweils 1. GA gesendet werden, diese Trennung funktioniert wohl nicht sauber. Daten die von einem Binding empfangen werden, dürfen keinesfalls an das selbe Binding zurück geschickt werden, auch das klappt nicht.

[mitchgehtab]

Naja, zu 2 wechselt er, weil das 2. Bit gesetzt ist (34 -> 0010 0010)

Das ist korrekt. Aber er sollte ja 33 empfangen! Das ist ja der Witz. Wenn ich die Rule deaktiviere funktioniert es ja richtig.
Komfort (33)
Fenster auf
Wechselt zu Frost (40)
Fenster zu
Wechselt zu Standby (34)

Ohne Rule sendet er nach der 40 die 34. Das hab ich in der ETS mitgelesen.

[udo1toni]

Was nun? Ohne Rule 34?

[mitchgehtab]

Nein, ohne Rule:
33 > 40 > 33
Mit Rule
33 > 40 > 34

siehe Logs von oben mit Rule:

2017-12-25 14:21:45.743 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 34 to 33
2017-12-25 14:21:45.764 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 2 to 1
>>> jetzt ist er im Komfort Modus
2017-12-25 14:21:53.739 [ome.event.ItemCommandEvent] - Item 'R05_Heizung_Betriebsmodus_HVAC' received command 40
2017-12-25 14:21:53.745 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 33 to 40
2017-12-25 14:21:53.762 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 1 to 4
>>> jetzt ist er im Frostmodus, weil ich ein Fenster auf habe
2017-12-25 14:22:01.736 [ome.event.ItemCommandEvent] - Item 'R05_Heizung_Betriebsmodus_HVAC' received command 34
2017-12-25 14:22:01.747 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus_HVAC changed from 40 to 34
2017-12-25 14:22:01.771 [vent.ItemStateChangedEvent] - R05_Heizung_Betriebsmodus changed from 4 to 2
>>> jetzt hab ich es Fenster zu und er geht in Standby. Sollte aber in den Komfort gehen.

Kann auch gerne nochmal Logs ohne die Rule posten aber da ist es wie beschrieben, das alles wie erwartet funktioniert (also wieder mit 33 in Komfort wechselt).

[udo1toni]

Leider fällt mir dazu nichts Sinnvolles ein.
autoupdate="true" für R05_Heizung_Betriebsmodus_HVAC sollte eigentlich eher false sein (wobei Du dieses Item ja eh nur als Input verwendest.)

Wenn Du im ETS Gruppenmonitor guckst, wirst Du vermutlich sehen, dass openHAB in dem Moment, wo Du ein postUpdate() für R05_Heiung_Betriebsmodus absetzt den entsprechenden Befehl schickt. Das ist das Fehlverhalten.
Der RTR wird das als Umschaltbefehl erkennen, aber anschließend auf Komfort wechseln (quasi die Annahme, dass der Nutzer eigentlich nicht auf Frostschutz wechseln wollte). Nun kann man sicher darüber streiten, ob dieses Verhalten vom RTR richtig ist - eigentlich sollte er nach dem Schließen des Fensters weiterhin im Frostschutz bleiben, wenn diese Betriebsart ausgewählt wurde, oder eben alle Steuerbefehle ignorieren, die während der Zwangsstellung rein kommen, aber das eigentliche Fehlverhalten liegt sicher bei openHAB, welches einfach kein postUpdate() auf den Bus schicken darf.
Ich kann mit momentan auch kein sinnvolles Szenario vorstellen, wie man das umgehen kann. Wenn Du feststellen kannst, ob das Fenster geöffnet wurde (na sicher, ist schließlich auch nur eine GA), könntest Du in der Rule verhindern, dass der Betriebsmodus auch nur per postUpdate() gesetzt wird. Damit stimmt dann aber die Anzeige in openHAB nicht mehr, das ist also keine zufriedenstellende Lösung.