openhabforum.de

Hallo zusammen,

ich habe mein einigen Gruppenadressen, die nicht mit einem Aktor Channel verbunden sind die folgende Fehlermeldung im KNX Binding:

2020-03-07 09:37:52.550 [WARN ] [calimero.link.192.168.XXX.XXX:3671 ] - negative confirmation of 6/1/1: 2e009de0110c3101010000

Die Items sind beispielsweise Anwesenheit, die von Openhab gesteuert werden und in der ETS keinem Aktor zugeordnet sind.

Jemand eine Idee wie ich den Fehler wegbekomme?

GA ohne Physik müssen über *-control Channel angelegt werden, damit openHAB als Aktor agiert.

Gesendet von meinem SM-G973F mit Tapatalk

Hallo,

ich gebe mal folgendes Beispiel:

Es handelt sich hierbei um eine GA ohne Aktor nur Anwesenheits Schaltung.

Thing: Item: Fehlermeldung: ändere ich das thing nun in switch-control dann ändert sich nichts.
Muss ich irgendwas noch ändern`? Cache leeren? Neustart=?

Ergänzung:

Ändere ich das Item auf switch-control und schalte es aus der Basic UI heraus, dann flitscht der Status in einer Endlosschleife hin und her und hört nicht mehr auf.

Die Log von Openhab ist das voll mit der oben genannten fehlermeldung.

Ah, dann hab ich Dich falsch verstanden.

Gesendet von meinem SM-G973F mit Tapatalk

EDIT:

Der Präsenzmelder ist natürlich auch ein Gerät im knx System, welches den Status hält. Dafür brauchst Du kein *.control.

Es handelt sich im Übrigen erstmal nicht um eine Fehlermeldung, sondern um eine Warnmeldung Wie ist knx an openHAB angebunden? Tunnel oder Router? Genaue Konfiguration der Bridge?

Nein es ist kein Gerät.

Ich erkenne per Skript im OpenHab per "Handy im WLAN" ob jemand zuhause ist oder nicht.

Openhab schaltet dann das ITEM "prae_anwesenheit" diese ist mit dem KNX Thing "th_prae_anwesenheit" verknüpft und hat im KNX auch eine GA, weil ich die GA in anderen KNX Geräten auch visualisieren will oder verwenden möchte.

Stelle ich das Thing auf Switch bekomme ich den Fehler "negative confirmation"

stelle ich das Thing auf Switch-control, wird beim ersten auslösen des Items, die ganze Log mit Endlos vielen Befehlen auf das Gerät vollgeschrieben und gleichzeitig der Fehler.

Wie bekomme ich den Fehler jetzt ganz weg? Oben ist ja meine bestehende Config.

Ich nochmal,
ich habe jetzt mal ReadIntervall von 3600 auf 0 gesetzt. Jetzt sind die Fehler weg. Ist das sinnvoll?

Was denn für einen readInterval? Wo keine Hardware, da kein readInterval

*.control Channel gehören per Definition zu keinem knx Device. Entsprechend dürfen sie auch nicht in einem Thing mit gesetztem address Parameter definiert werden.

*.control Channel senden den Status des Items an die hinterlegte GA und empfangen Befehle von der hinterlegten GA. Aus Rules heraus muss also Item.postUpdate(Status) zum Einsatz kommen, um Status an knx zu senden (ja, das ist sehr ungewöhnlich).

Hallo Udo1Toni,

Danke Dir.

Mit dem Readinterval meinte ich die Option im KNX Thing:
Du hattest irgendwo mal geschrieben, dass der Read Intervall immer auf 0 sein sollte, meine ich.Stimmt das?

Verstehe ich dich richtig, dass ich das Thing "th_prae_anwesenheit" (siehe oben) aus den Klammern von "Thing device generic" herausnehmen muss und in die Klammer von "Bridge knx:ip:bridge", da es mit keinem Gerät verknüpft ist.

Sollte das mit allen Things gemacht werden, die keine Aktor oder ähnliches haben?

Ich möchte ja wenn das Item in Openhab geschaltet wird. Diesen Status auch an die GA ins KNX übertragen, um es im Bus weiterzuverarbeiten.


Vielleicht könntest du mir ein Bespiel geben wie ich das korrekt realisiere anhand meinem Beispiel. Vielleicht verstehe ich es dann besser.

Danke schonmal.

Also, die Idee der Things ist ja, dass jedes Thing ein Stück Hardware ist, also z.B. ein knx REG im Schaltschrank.
Wenn man das Gerät als Hardware betrachtet, hat jedes Gerät eine physikalische Adresse. das ist der Thing Parameter address.
knx2 kann prüfen, ob ein solches Gerät über den Bus erreichbar ist. Das passiert über einen ping. Über den Thing Parameter pingInterval kann man angeben, wieviele Sekunden zwischen zwei Pings liegen sollen.
Weiterhin kann knx2 zusätzliche Informationen aus dem Gerät auslesen, beispielsweise den Hersteller. Aber nicht jedes Gerät unterstützt dies. Dafür gibt es den Thing Parameter fetch.
Daraus ergibt sich, dass pingInterval != 0 und fetch=true nur dann sinnvoll sein können, wenn der Parameter address gesetzt ist.

Als letzten Thing Parameter gibt es noch readInterval. Dieser ist dafür verantwortlich, dass openHAB die Status-GA zyklisch vom knx Bus ausliest.
Der Parameter ist der Hardware zugeordnet, nicht dem Channel. Der Grund dafür ist, dass es nur eine sinnvolle Anwendung für diesen Parameter gibt, nämlich, wenn das Gerät weder zyklisches Senden noch Senden bei Wertänderung unterstützt. Dies ist aber eine Geräteeigenschaft und betrifft somit immer alle Channel eines Gerätes.
Es sollte grundsätzlich unnötig sein, die Status zyklisch abzufragen, deshalb war das anfangs auch nicht im knx Binding vorgesehen. Entsprechend sollte grundsätzlich readInterval immer auf 0 gesetzt sein (das ist auch default), nur bei Geräten, wo dies der einzige Weg ist, sollte man davon abweichen.

readInterval sollte überhaupt nur bei Channels Auswirkungen haben, die bei einer der GA ein < vorangestellt haben. Weiterhin sollte knx2 weder readInterval noch < beachten, wenn ein Channel vom Typ *-control ist, da in diesem Fall per Definition openHAB die Quelle des Status ist, warum also sollte knx2 über den Bus den Status erfragen? (und so steht das auch in der Doku)

Wenn sich knx2 hier anders verhält, ist das ein Issue. Da ich noch nie irgendwo readInterval != 0 gesetzt habe, tritt dieser Fehler bei mir nicht auf.

Channel gehören immer zu einem Thing, man kann und darf sie nicht außerhalb eines Thing definieren. Wenn man Control Channel definiert, sollten diese natürlich in einem Thing liegen, in dem keine speziellen Parameter gesetzt sind (wie readInterval und fetch...)