KNX Adapter überholt

chefkoch009

Hallo,

bei einer Projektaktualisierung werden lediglich neue Gruppenadressen hinzugefügt. Bestehende bleiben unverändert, also auch die Flags.
Du hast nun also 2 Möglichkeiten:

alle KNX-Objekte aus dem Objektbaum im ioBroker löschen und neu importieren
direkt die Objekte im Objektbaum ändern. (links mit dem Bleistiftsymbol)

Die Gruppenadressen findest du in den Objekteinstellungen unter dem Reiter RAW(nur Experten).

Nun zur Frage warum manchmal etwas augenscheinlich unvorhergesehenes passiert:

Wenn im ETS Projekt:
"KÜ" gesetzt ist: Dann darf dieses KO mit dem Bus reden (i.d.R. bei Änderungen (DimmwertStatus, o.ä)), es darf aber weder beschrieben noch gelesen werden.

"KSÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf etwas darauf schreiben (z.B. 0(true) oder 1(false) für DPT 1.xxx oder einen Dimmwert oder ....) UND das KO darf eine Änderung auf diesem KO senden was aber i.d.R keinen Sinn macht, denn dafür gibt es ja das Statusobjekt. Historisch gesehen gab es damals Aktoren bei denen war Schalt- und Statusobjekt das gleiche.

"KLÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf es abfragen (beim Adapter wird irgend ein Wert an diese GA gesendet und das KO antwortet dann....das ist die aktive Abfrage) UND das KO darf selbständig eigene Änderungen dem Bus mitteilen.

"KLSÜ" gesetzt ist: Rein logisch gesehen, wenn der Aktor getrennte Schalt- und Statusadressen hat, sinnfrei und sorgt aktiv für Verwirrung. Leider werden diese Flags pauschal in einigen Herstellerapplikationen gesetzt. Warum? Keine Ahnung.

Also: Bei SchaltKO's "KS" Flags setzen und bei StatusKO's "KLÜ".

ALLE GA's die ein "L" Flag tragen werden beim Adapterstart abgefragt.

VG
chefkoch009

loverz

@chefkoch009 Hi,

danke für die ausführliche Erklärung.

Ich werde es bei Gelegenheit mal ausprobieren und in der ETS Software etwas „aufräumen“

Melde mich dann nochmals.

loverz

@chefkoch009
So hab mich jetzt mal etwas eingearbeitet und stelle fest, dass die Flags eigentlich schon richtig gesetzt sind:

Hier zum Beispiel eine Gruppenadresse (K-S) zum bewegen, die ich aber nicht über ioBroker, sondern über die Glastaster an der Wand steuere (sollte ja kein Problem darstellen oder?)

Hier eine GA (K-S) die ich ausschließlich ioBroker ansteuere:

Und hier eine GA (K-L-Ü) die ich sowohl in ioBroker auswerte als auch an den Glastastern anzeigen lasse:

Mich interessieren ja jetzt erstmal nur die Flags von den Kommunikationsobjekten die direkt an die Aktoren bzw. von den Aktoren kommen oder?
Die KOs der Glastaster sind ja erstmal egal, auch wenn die KOs in gemeinsamen GAs sind oder?

Übrigens: Mir ist aufgefallen, dass diese Geisterfahrten vermehrt stattfinden, wenn ich meine Fenster offen habe (Fensterkontakte werden in den Scripts oft als Bedingung für die Rollofahrten abgefragt -> "Keine Rollofahrt, wenn Terrassentür offen")

Hier bin ich mir aber nicht sicher, ob ich das richtig programmiert habe:

Edit: Nach ewigem ausprobieren und einlesen etc. ist mir aufgefallen, dass diese „Geisterfahrten“ immer dann kamen, als ich mein Rollo im DG bewegt habe.

Nach dem Ausschlussverfahren habe ich den Fehler dann eingegrenzt.
Es stellte sich heraus, dass ich der Gruppenadresse für das DG Rollo ein Zentralobjekt des Aktors zugewiesen habe und nicht das einzelne Kommunikationsobjekt.
Somit haben sich alle Rollos bewegt, wenn ich diese GA angesteuert habe
Da der Rollo im DG nur an heißen Tagen bewegt wird (Hitzeschutz etc.) hat mich das Ganze in die Irre geführt und ich dachte es sei nur wenn meine Fenster offen sind, denn die sind logischerweise auch nur dann offen, wenn es heiß ist

Recht sporadischer Fehler und ich denke, dass ich ihn endgültig gefunden habe.

Der Adapter scheint wohl nicht Schuld zu sein

Danke für die Unterstützung!

chefkoch009

@loverz Vielen Dank für das Feedback. Schön das Du den Fehler gefunden hast.

Aber mal zur allgemeinen Info: Seit ETS Version 5.7.0 gibt es mal wieder Änderungen im Export. Dies kann zur Folge haben, das Projekte nicht mehr / nicht mehr richtig importiert werden können. Das äussert sich unter anderem darin das:

die Flags nicht richtig erkannt werden
die Aufzählung für die Räume nicht erzeugt wird
schalt und status nicht richtig erkannt werden

Kurzum....ne ganze Menge. Ich arbeite zur Zeit daran.

VG chefkoch009

JGDFly

Hallo,
habe kürzlich mit dem ioBroker und KNX gestartet. Bekomme auch das Schalten von Aktoren und Rolläden hin.
Nur beim Dimmen mit dem DPT3.007 stehe ich auf dem Schlauch. Habe folgende Definition:

{
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1562517593538,
  "common": {
    "name": "Deckl. Eßz. H/D",
    "type": "number",
    "role": "value",
    "min": 0,
    "max": 100,
    "read": false,
    "write": true
  },
  "native": {
    "dpt": "DPT3.007",
    "address": "9/1/1",
    "addressRefId": "P-0494-0_GA-212",
    "statusGARefId": "",
    "actGARefId": ""
  },
  "acl": {
    "object": 1638,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1638
  },
  "_id": "knx.0.EG.Bel__Innen.Deckl__Eßz__H_D",
  "type": "state"
}

Aber es zeigt sich keine Reaktion, egal was ich bei Wert in den Objekten setze. Was mache ich faslch?Danke

Garfonso

Irgendwie verschluckt sich hier der KNX Adapter jeden Tag an ein paar Statusmeldungen.
In der History sieht das so aus:

0 	true 	knx.0 	2019-07-09 10:03:28.300 	
1 	true 	knx.0 	2019-07-09 08:29:01.253 	
1 	true 	knx.0 	2019-07-09 08:29:01.243 	
1 	true 	knx.0 	2019-07-09 08:29:01.243 	
0 	true 	knx.0 	2019-07-09 08:29:00.254 	
1 	true 	knx.0 	2019-07-08 08:29:01.253 	
1 	true 	knx.0 	2019-07-08 08:29:01.246 	
0 	true 	knx.0 	2019-07-08 08:29:00.253

Mit ETS hab ich geguckt, was da über den Bus geht:

#	Zeit	Dienst	Flags 	Prio	Quelladresse	Quellname	Zieladresse	Zielname	Rout	Typ	DPT	Info
107070	09.07.2019 07:29:58,718	vom Bus		Niedrig	1.1.255	-	3/6/2	Heizpatrone DG Bad Ein/Aus	6	GroupValueWrite	  1.001 Schalten	$01 | Ein
107072	09.07.2019 07:29:58,789	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	3/7/2	Heizpatrone DG Bad Status	6	GroupValueWrite	  1.001 Schalten	$01 | Ein
107917	09.07.2019 08:28:58,678	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	3/7/2	Heizpatrone DG Bad Status	6	GroupValueWrite	  1.001 Schalten	$00 | Aus
107920	09.07.2019 08:28:59,683	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	3/7/2	Heizpatrone DG Bad Status	6	GroupValueWrite	  1.001 Schalten	$01 | Ein
107936	09.07.2019 08:29:58,712	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	3/7/2	Heizpatrone DG Bad Status	6	GroupValueWrite	  1.001 Schalten	$00 | Aus
109497	09.07.2019 10:03:26,666	zum Bus		Niedrig	1.1.242	-	3/7/2	Heizpatrone DG Bad Status	6	GroupValueRead		
109498	09.07.2019 10:03:26,700	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	3/7/2	Heizpatrone DG Bad Status	6	GroupValueResponse	  1.001 Schalten	$00 | Aus

Was sieht man hier? Um ca. 7:30 Uhr schalte ich aus ioBroker heraus am Schaltaktor einen Ausgang ein. Der setzt entsprechend den Status auf Ein. Er ist so eingestellt, dass dieser Ausgang nach 60 Minuten wieder abgestellt wird. Er macht da auch ein wenig Quatsch und sendet erstmal "Aus", dann eine Sekunde später wieder "Ein", dann aber eine Minute später wieder "Aus". Ich habe gerade in den Parametern gesehen, dass es sich hierbei vermutlich um die "Ausschaltvorwarnung" handelt, die auf 1 Minute eingestellt war (habe ich nun abgestellt).

Verwirrend ist aber, was der ioBroker daraus macht. Wie man in der History sieht, werden aus den 3 Telegrammen auf dem Bus insgesamt 7 Statusänderungen. Leider bleibt dabei der falsche Status "Ein" am Ende bestehen. Wie kann das passieren? Kommen die Telegramme einfach zu schnell? Es tritt jeden Tag auf. Sollte nicht 1 Minute genug Zeit sein, dass der ioBroker den dann richtigen "Aus" Status korrekt verarbeiten kann?

So sieht übrigens die history vom dazugehörigen Schaltobjekt aus:

0 	true 	knx.0 	2019-07-09 10:03:28.304 	
1 	true 	knx.0 	2019-07-09 08:29:01.250 	
true 	false 	javascript.0 	2019-07-09 07:30:00.065

Kann es daran liegen? Auf dem Bus wird allerdings nach 7:30 Uhr auf der Schalt GA nicht mehr gesendet (weder von ioBroker noch vom Schaltaktor).

Ich habe gerade auch in das Log geguckt. Der KNX Adapter verbindet sich anscheinend um 7:30 Uhr und 8:30 Uhr jeweils neu. Hm. Warum? Zufall? Es scheint aber nach dem Schalten zu sein? Warum könnte der KNX Adapter da denken, er wäre nicht verbunden?

2019-07-09 07:30:26.716  - info: knx.0  STATE_NOT_CONNECTED : Try to connect / reconnect :  STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2019-07-09 07:30:27.219  - info: knx.0  STATE_NOT_CONNECTED : Stop connection :  STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0).
2019-07-09 07:30:30.718  - info: knx.0 Using UDP with local IP: 192.168.0.2
2019-07-09 07:30:30.718  - info: knx.0 Event : UDP - listening
2019-07-09 07:30:30.718  - info: knx.0 Connected  - local UDP Server listening on 192.168.0.2:49317
...
2019-07-09 08:30:21.506  - info: knx.0  STATE_NOT_CONNECTED : Try to connect / reconnect :  STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2019-07-09 08:30:22.008  - info: knx.0  STATE_NOT_CONNECTED : Stop connection :  STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0).
2019-07-09 08:30:25.508  - info: knx.0 Using UDP with local IP: 192.168.0.2
2019-07-09 08:30:25.508  - info: knx.0 Event : UDP - listening
2019-07-09 08:30:25.508  - info: knx.0 Connected  - local UDP Server listening on 192.168.0.2:37997

Kann ich weitere Informationen liefern? Soll ich ein issue erstellen?

mpenno

@chefkoch009 Ich nutze den Adapter schon eine Weile. Er funktioniert soweit ganz gut, vielen Dank schon einmal für Deine Mühen und viel investierte Zeit!!!

Bei der Weiternutzung der Objektdaten habe ich nur ein Problem, dass z.B. die ioGO App einige Zustände nicht darstellen kann, da diese nicht zu den in State / Roles definierten passen. Besonders störend ist dies bei den Boolean Werten. Hier steht bei mir über alle "1" oder "0", wo hingegen der Wert "true" oder "false" sein müsste.

Es wäre toll, wenn Du Dir das hier mal kurz ansehen könntest: ioGo # Native Android App vom 16.07.2019.

Wie ich gelesen habe, hattest Du kurz eine Version 1.0.18, die korrekt true/false setzt aktiv, hattest Dich jedoch wieder umentschieden. Richtiger wäre true/false zu setzen, aber die Kompatibiliät zu bestehenden Usern und deren Scripte verstehe ich natürlich.

Liesse sich nicht im Adapter eine Art "kompatibility"-Häckchen für die Anwender setzen, die unbedingt die bestehenden 1/0 Werte benötigen?

Oder hast Du eine andere Idee, wie ich die Werte nach true/false wandeln kann?

Viele Grüße
Michael

loverz

@mpenno bin jetzt kein Experte und würde die „korrekte“ Schreibweise auch begrüßen, aber könntest du die Werte nicht mit einem eigens dafür gedachten Script anpassen?

Wenn Wert wurde geändert und ist 1, dann steuere Wert mit true oder so?

Garfonso

In Javascript Skripten lässt sich die Wandlung von 0/1 zu true/false am einfachsten durch voranstellen von !! erreichen, also z.B. let val = !!getState("knx.0....").val; Das habe ich mittlerweile in allen Skripten drinnen, die mit dem knx Adapter arbeiten.
Das sollte man am besten mal groß promoten, das alle Leute ihre Skripte langsam anpassen.

Wobei die meisten Skripte, die hier so geschrieben werden damit eigentlich wenig Probleme haben sollten. Zumindest sehe ich selten den === Vergleich, der auch den Typ prüft, sondern meistens ==, bei dem es egal ist ob da links und rechts der gleiche Typ ist, da ist für Javascript 0 = false und 1 = true (und noch ein paar andere Kuriositäten, weshalb der === Vergleich empfohlen wird).

Aber die Option fände ich auch gut, damit das true/false langsam mal kommen kann. Dann kann ja auch jeder selber sehen, wann er wie welche Skripte überarbeitet hat.

Wenn man irgendwie altinstallationen erkennen kann, kann man da die Option ja per default aktivieren und bei neuinstallationen dann deaktivieren. Oder man macht jetzt eine version, die die Option hat und per default aktiviert (und entsprechend speichert) und dann in einer Zeit X (z.B. 1 Monat oder so), nachdem man relativ sicher ist, dass alle Altbestände aktualisiert haben, eine neue Version, die das per default deaktiviert (was dann bei alten, wo es schon gesetzt ist, nichts mehr ändern sollte, richtig?). Dann hat man die Chance, dass man die 0/1 Situation irgendwann mal los wird...

ReRa

@chefkoch009

Schade, dass ich den Post erst heute gefunden habe...
Ich versuche schon seit Tagen verzweifelt die knxporj-Datei einzulesen, bisher immer ohne Erfolg.
Zum Glück liegt es nicht an mir.

Vielen Dank für die bisher investierte Arbeit!

VG

ReRa

chefkoch009

Hallo @all,

hier mal eine kurze Sachstandsmeldung: Die neue ETS5.7.x gestaltet sich als widerspenstiger als gedacht. Mechanismen, welche in den vorherigen Versionen funktioniert haben greifen hier nicht mehr. Kurzum eine Menge Arbeit, aber ich bin dran.

@JGDFly : Dimmen mit DPT3.007 ist das sogenannte Schritt-Dimmen. Dieser DPT ist ein 4-Bit Objekt bei dem das 4.Bit binär interpretiert wird und die Richtung angibt, also z.B. 0 für runter, 1 für rauf. Die Bits 1-3 geben dabei die Schrittweite an. Eigentlich müsste dein common-typ nicht "number" sondern leer sein, also "" oder "string". Dann sieht man im Objektbrowser Werte wie z.B. "0,1" oder "1,1". Möchtest du absolut Dimmen also mit einem Wert dann wäre das der DPT5.001.

@Garfonso : Ich verstehe das hier nicht:
D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status
ist das nun das Status oder das Schaltobjekt? Für den Fall das es das Schaltobjekt ist, dann ist passt das von dir beschriebene Verhalten.
Es hat sich gezeigt, das dieses von Dir beschriebene Wiederverbinden 2 Ursachen haben kann:

Das Gerät ist nicht erreichbar oder antwortet nicht ( starte bitte mal den Aktor neu und versuche das Verhalten erneut zu provozieren)
Es wird versucht in eine leere Gruppenadresse zu schreiben.

@mpenno : konsequenter Weise müsste true/false stehen. Wenn ich ein "compatibility" Häkchen machen würde, so würde ich das eigentliche Problem nur verschieben. Egal wie man es dreht und wendet, einen Weg von beiden muss ich gehen. Vorerst empfehle ich den Weg von Garfonso mit dem Script (verwende ich selbst auch).

VG
chefkoch009

mpenno

@Garfonso und @chefkoch009 :

Vielen Dank. Mit einem vorgeschalteten Script klappt es jetzt. Ich mache es so:

createState('Sensor.Fenster.Fenster_Bad',  false, {
   read: true,
   write: true,
   name: "Bad Fenster", 
   type: "boolean",
   def: false, role: "sensor.window" 
});
on({id: 'knx.0.Fenster_und_Türen.Fenster_Status.Fenster_Bad_Status'}, function (dp)
{
    setState('javascript.0.Sensor.Fenster.Fenster_Bad', toBoolean(dp.state.val));
});

Ist die von Dir beschriebene Variante kürzer? Ich verstehe gerade nicht, wie ich es umsetzen müsste:

let val = !!getState("knx.0....").val;

Das mit dem "compatibility" Häkchen wäre nicht nur ein Verschieben, sondern der erste Schritt in die Richtung, wo es hingehen soll. Ich hätte dann z.B. gleich mit den richtigen true/false Werten angefangen und viele User, die nach mir kommen auch.

Garfonso

@chefkoch009 said in KNX Adapter überholt:

D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status
ist das nun das Status oder das Schaltobjekt? Für den Fall das es das Schaltobjekt ist, dann ist passt das von dir beschriebene Verhalten.
Es hat sich gezeigt, das dieses von Dir beschriebene Wiederverbinden 2 Ursachen haben kann:

Das Gerät ist nicht erreichbar oder antwortet nicht ( starte bitte mal den Aktor neu und versuche das Verhalten erneut zu provozieren)
Es wird versucht in eine leere Gruppenadresse zu schreiben.

Hi, da ist das Status Objekt. "D3 Schaltausgang 10-fach, 16A C-Last" ist nur der Name des Gerätes. Was bedeutet das nun für das Verhalten?
Ich habe jedenfalls den Aktor mal neugestartet, was nichts ändert. Die Gruppenadressen sind auch alle nicht leer. Ich habe auch zwei Aktoren, die sich so verhalten (insgesamt 3 Schaltobjekte und 3 Statusobjekte) und es passiert bei beiden nur bei den Ausgängen, wo der Zeitschalter aktiv ist. Alle anderen Ausgänge lassen sich normal schalten und sind bis auf den Zeitschalter identisch konfiguriert.

Ich glaube, das es daran liegt:

#	Zeit	Dienst	Flags 	Prio	Quelladresse	Quellname	Zieladresse	Zielname	Rout	Typ	DPT	Info
885	25.07.2019 13:56:08,526	vom Bus		Niedrig	1.1.12	D3 Schaltausgang 10-fach, 16A C-Last	0/0/0	Broadcast	6	NetworkParameterResponse		C3 51 3C 00 00 01 00 80 00 00 00

Der Aktor ist auf Zeitschalten konfiguriert und wenn den Zeitschalter betätigt (also die GA 3/6/2 Hezpatrone DG Bad Ein/Aus), dann schickt er dieses Telegramm über den Bus. Warum ist mir bisher nicht klar. Wenn ich ihn nicht auf Zeitschalten konfiguriere, denn schickt er das komische Telegramm nicht und alles geht... ich würde nur gerne den Zeitschalter nutzen, weil die Elktroheizpatrone doch nicht ewig laufen sollte, nur weil z.B. der Server ausgefallen ist...

Jedenfalls steigt der KNX Adapter reproduzierbar mit einem Disconnect aus, wenn dieses Telegramm kommt.

Garfonso

@mpenno said in KNX Adapter überholt:
Hi, statt

toBoolean(dp.state.val)

kannst du schreiben

!!dp.state.val

Aber toBoolean ist theoretisch sauberer.

Das mit dem Kompability-Häckchen sehe ich genauso, wie du. Neue Nutzer können dann "richtig" anfangen.

chefkoch009

Hallo an alle,

endlich ist es soweit.....die neue Version 1.0.30 ist online. Hier ein grober Überblick :

import von ETS5.7.2 Projektdateien + loader und parser beschleunigt
Erweiterung der Datenpunkttypen
adapter Konfig menü überarbeitet und aufgeräumt
dem Wunsch nach dem Kompatibilitätshäkchen gefolgt und umgesetzt
dem Wunsch nach der Netzwerkkartenzuordnung für den ioBroker horst gefolgt und umgesetzt
einige Bugs im KNXStack behoben
die State-Act Zuordnung überarbeitet (nur ab 5.7.2) sodass der gesammte Name betrachtet wird, also HG+MG+GA plus zusätzliche Kriterien
das Status Objekt hat nun pauschal nur Lese-Flag, wenn man das Schreib-Flag mit aktiviert dann entspricht die Funktion dem Lesen-Button im Gruppenmonitor in der ETS
...
Müll raus gebracht und Staub gesaugt

Kurzum ne ganze Menge Änderungen. Ich würde mich wieder über reges Feedback freuen.

Mit Spannung erwarte ich das nächste ETS-Update

in diesen Sinne 42 und
VG
chefkoch009

sigi234

@chefkoch009 sagte in KNX Adapter überholt:

die neue Version 1.0.30 ist online

Ein Link wäre Super...........

chefkoch009

@sigi234 ich verstehe die Frage nicht? welcher link?
vllt meinst du das hier: https://www.npmjs.com/package/iobroker.knx

VG
chefkoch009

sigi234

@chefkoch009 sagte in KNX Adapter überholt:

@sigi234 ich verstehe die Frage nicht? welcher link?
vllt meinst du das hier: https://www.npmjs.com/package/iobroker.knx

VG
chefkoch009

Eigentlich meine ich das:

https://github.com/ioBroker/ioBroker.knx

Screenshot (3903).png

chefkoch009

Hallo,

Achso das.... Die Versionierung von iobroker läuft nachts irgendwann. Also solltest du es heute morgen sehen( falls ich das publishing nicht zu spät gemacht habe). Alternativ kannst du das auch über die Konsole erzwingen indem du im node_modules verzeichnis ein "npm i iobroker.knx@latest --production" ausführst.

Wenn er fertig ist mit installieren, machst du noch ein "iobroker u knx" und dann sollte die letzte Version installiert sein.

VG
chefkoch009

dQeLse

@chefkoch009 ich sollte mich hier melden
Ich habe die neue Version installiert und versuche ein Export von der ETS 5.7.1 zu importieren.
Ich bekomme keinerlei Ausgaben im Log und der Balken bewegt sich nicht

NEWS

KNX Adapter überholt

Support us

1.1k
Online

30.2k
Users

76.2k
Topics

1.2m
Posts

NEWS

KNX Adapter überholt

Support us

1.1kOnline

30.2kUsers

76.2kTopics

1.2mPosts

1.1k
Online

30.2k
Users

76.2k
Topics

1.2m
Posts