Test Adapter KNX v1.0.x

Garfonso

@sourex said in Test Adapter KNX v1.0.x:

"id": "knx.0.Heizung.Heizung_absolut.Bad_absolut",

Da steht der Stellwert des Ventils drinnen? Oder was?

"role": "level.number",
"min": -273,
"max": 670670               <---- ist das richtig so ?? hatte es bei @samot13  auch schon gesehen

Da solltest du von Hand eintragen, was minimum und maximum sind. Das weiß der KNX Adapter im Zweifelsfall gar nicht.

},
"native": {
"dpt": "DPT9.001",
"address": "3/3/4",
"addressRefId": "P-01D1-0_GA-305",
"statusGARefId": "P-01D1-0_GA-296",
"actGARefId": ""

{
"_id": "knx.0.Heizung.Heizung_absolut_Status.Bad_absolut_Status",

Kommt hier jetzt der Status des Ventils oder die Temperatur?
Nachdem, was du schreibst, ist jetzt die Verknüpfung falsch, denn Ventil-Schalten und Temperatur sind ja zwei Dinge, die nicht miteinander verknüpft sein sollten (also nicht so direkt, wie der Adapter das macht). Als "quickfix" kannst du das "statusGARefId" bzw. actGARefId Feld in den States mal leer machen und dann gucken, ob es so ist, wie du das gerne hättest. Wenn es dann passt, würde ich empfehlen die GAs umzubenennen (sonst musst du das bei jedem Import machen) und zwar, dass die sich mehr unterscheiden (z.B. bei einem "Temperatur" mit dazu nehmen).

sourex

@Garfonso said in Test Adapter KNX v1.0.x:

Da steht der Stellwert des Ventils drinnen? Oder was?

Da wird der absolut Tempwert übermittel an den Heizungsaktor.
Bei mir werden alle DPT9.001 mit diesen Werten übernommen. Klar ändere die Werte, wollte aber auf das Problem hinweisen.

@Garfonso said in Test Adapter KNX v1.0.x:

Nachdem, was du schreibst, ist jetzt die Verknüpfung falsch, denn Ventil-Schalten und Temperatur sind ja zwei Dinge, die nicht miteinander verknüpft sein sollten

also im KNX ist das kein Problem :)
Ich weiß aber was du meinst und bin jetzt einfach für die VIS übergegangen in "+ Temp" bzw "-Temp" das war kein Problem.

Garfonso

@sourex
Vielleicht habe ich auch nicht verstanden, was du wie mit deinen GAs definiert hast... das macht es immer etwas schwer, weil es ja nicht nur einen Weg gibt etwas in KNX zu machen. :-)

Also bei mir gibt es z.B. einen Temperatur-Ist Wert mit einer GA. Dann gibt es einen GA für Temperatur-Ziel Wert. Wenn der knx-adapter die miteinander als "statusGA" und "actGA" verheiraten würde, wäre das m.E. Quatsch. Auch z.B. das HQWidget für die Temperatursteuerung akzeptiert ja eine Ist-Temperatur und eine Ziel-Temperatur die man getrennt von der Ist-Temperatur einstellen kann.
Dazu hab ich noch %-Stellwerte der Ventile z.B. -> die möchte ich auch nicht mit den Temperaturwerten direkt verknüpft haben (die Ventile-Aktoren unterstützen aber leider keine Rückmelde GA, daher gibt es die nicht).
Insofern sind bei meinen Heizungssachen nirgendwo die "actGARefId" und "statusGARefId" Felder ausgefüllt und die GAs heißen auch alle so, dass der knx-Adapter das nicht automatisch zuordnet und befüllt.

sourex

@Garfonso
verstehe was du meinst. Hast wohl auch recht das diese GAs eigentlich nicht zusammen passen.

Neues Problem, unter 1.20 konnte ich Homekit ganz normal nutzten.
Nun ist es so das jedes mal wenn ich über Homekit ein Befehl absetzte die Meldung kommt:

(8392) Unknown ID

demenstprechend wird der Befehlt nicht weitergeleitet :(

kann da jemand weiter helfen ???

chefkoch009

@sourex ich benutze kein HomeKit und kenne diese Meldung nicht. Könntest du ein bisschen mehr log zur Verfügung stellen?

VG
chefkoch009

sourex

klar kann ich. Allerdings ist es nur die eine Meldung die ich geschrieben habe vom KNX,
habe deswegen auch mal die vom Homekit dabei gemacht.

chefkoch009

@sourex entfern mal das / aus der mittelgruppe.

VG
chefkoch009

sourex

@chefkoch009
in der Tat, alle anderen ohne / gehen.
In der 1.20 war das noch kein Problem.
Ich werde Licht raus schmeißen, war eh nur zum testen.
Ich möchte nichts an dem Licht ändern seitdem du das so zum laufen bekommen hast das es in der VIS alles auch richtig angezeigt wird :)

frankthegreat

@chefkoch009
Hab gerade die 1.0.40 auf mein Testsystem geprügelt. Meine Projektdatei lässt sich jetzt ohne Probleme einlesen :ok_hand:
Ein Nachpflegen der Adressen scheint auf den ersten Blick auch nicht mehr nötig zu sein.
Super Arbeit, die du hier ablieferst. :+1:
Vielen Dank

Jörg D.

Guten Abend,

das Update von der 1.0.39 auf die 40 startet der Adapter nicht mehr. Fehler im Log:

startInstance knx.0: cannot find start file!

Nach Downgrade auf 1.0.39 läuft er wieder.

Jörg

chefkoch009 · Nach Downgrade auf 1.0.39 läuft er wieder.

@Jörg-D ein Upgrade via github funktioniert auch nicht. Installier es bitte mit npm.

VG
chefkoch009

Jörg D.

Danke! Einen schönen Sonntag :-)

mstrack

Ich habe ein Problem mit der aktuellen 1.0.41 und dem Senden von Temperaturwerten mit dem DPT 9.001. Beim aktualisieren eines Wertes in iobroker bekomme ich auf die besagte GA nur einen Read und die entsprechende Antwort vom KNX-Bus bzw des Gerätes in der Diagnose der ETS zu sehen. Das Objekt im iobroker bleibt auf dem von mir geänderten Wert.

Nach etlichem Probieren habe ich einen der weiter obe stehenden Tips mit dem zurückgehen auf Version 1.0.20 versucht. damit funktioniert die Kommunikation exakt wie gewünscht.

Grüße Martin

mstrack

@mstrack Hat sich geklärt, ich hatte noch falsche Flags in der ETS gesetzt gehabt und deshalb das komishe Verhalten. Jetzt wo ich alles angepasst habe funktioniert wieder alles wie gewollt.

tsero

Hallo zusammen!

Habe da ein Problem mit Bus Reads ... möchte eine GA auslesen, aber es wird kein GroupValueRead abgesetzt. Bin aktuell auf 1.0.41.
Der DP ist folgendermaßen definiert:

{
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1586887293841,
  "common": {
    "name": "Messen Wind max m/s",
    "type": "number",
    "role": "value",
    "unit": "m/s",
    "max": 670670,
    "min": 0,
    "read": true,
    "write": false,
    "update": true
  },
  "native": {
    "dpt": "DPT9.005",
    "address": "0/1/52",
    "addressRefId": "P-01ED-0_GA-55",
    "statusGARefId": "",
    "actGARefId": "",
    "objRef": "O-2_R-631",
    "devName": "M-0001_A-9101-01-0F6B-O00C9",
    "devInst": "P-01ED-0_DI-620",
    "objectSize": ""
  },
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s",
  "type": "state"
}

Damit versuche ich einen Wert von der Wetterstation auszulesen:

 log("max knx wind = "+getState('knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s').val);

Aber am Bus passiert gar nichts! Kein Read. Im log sehe ich auch keinen Bus-Request

2020-04-19 13:49:27.541 - info: javascript.0 (10521) Stop script script.js.Tests.JS_tests
2020-04-19 13:49:27.688 - info: javascript.0 (10521) Start javascript script.js.Tests.JS_tests
2020-04-19 13:49:27.703 - info: javascript.0 (10521) script.js.Tests.JS_tests: max knx wind = 0.9
2020-04-19 13:49:27.707 - info: javascript.0 (10521) script.js.Tests.JS_tests: licht EG SZ = true
2020-04-19 13:49:27.708 - info: javascript.0 (10521) script.js.Tests.JS_tests: registered 0 subscriptions and 0 schedules
2020-04-19 13:49:27.719 - silly: knx.0 (11641) States user redis pmessage knx.0.*/knx.0.Schalten.EG.EG_Schlafzimmer_Licht__E10_1:{"val":true,"ack":false,"ts":1587296967716,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1587296746683}
2020-04-19 13:49:38.654 - info: javascript.0 (10521) Stop script script.js.Tests.JS_tests
2020-04-19 13:49:38.791 - info: javascript.0 (10521) Start javascript script.js.Tests.JS_tests
2020-04-19 13:49:38.801 - info: javascript.0 (10521) script.js.Tests.JS_tests: max knx wind = 0.9
2020-04-19 13:49:38.801 - info: javascript.0 (10521) script.js.Tests.JS_tests: licht EG SZ = true
2020-04-19 13:49:38.804 - info: javascript.0 (10521) script.js.Tests.JS_tests: registered 0 subscriptions and 0 schedules
2020-04-19 13:49:38.815 - silly: knx.0 (11641) States user redis pmessage knx.0.*/knx.0.Schalten.EG.EG_Schlafzimmer_Licht__E10_1:{"val":true,"ack":false,"ts":1587296978810,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1587296746683}

Das einzige was auf den Bus raus geht, ist ein setState, aber sämtliche getStates gehen nicht raus.
Eigentlich sollte doch wenn L und U gesetzt sind ein GroupValueRead gemacht werden, oder? Funktioniert das bei euch?? Oder steh' ich wieder mal auf der Leitung ...

Garfonso

@tsero

getState kann keinen GetValueRead auf dem Bus auslösen. Das ist nur eine Abfrage der ioBroker Datenbank und es wird nicht beim Adapter nachgefragt (und so wie du es verwendest, wird sogar nichtmal die DB gefragt, sondern der Cache des Javascript Adapters). Von daher kann es so nicht gehen.

Was gehen könnte ist, wenn du den State schreibst. Da hatte @chefkoch009 mal etwas implementiert, das wenn read & write Flags im ioBroker beide true ein GetValueRead ausgeführt wird, wenn du darauf mit setState schreibst, siehe auch die Readme des Adapters ( https://github.com/iobroker/iobroker.knx ) (es haben auch die Flags der GA noch etwas zu sagen -> guck am besten nach).

Natürlich musst du dein Skript deutlich anders machen, und zwar eher so:

//log new measurement, ack: true -> only react to readings from bus!
on({ id: 'knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s', ack: true}, (e) => {
     log("max knx wind = "+e.state.val);
});

//trigger GroupValueRead
setState('knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s', 0);

Wichtig ist das ack: true beim "on" -> damit reagiert die Funktion nur auf Daten, die vom Bus kommen (sonst würde es auch die 0 ausgeben, die wir unten schreiben). Anstatt 0 schreiben, könnte man auch irgendeine andere Zahl, z.B. den aktuellen Wert oder was negatives. Das man den Wert selber schreibt, muss man bei anderen Skripten / Statistik / Sourceanalytics / History irgendwie im Kopf haben. Daher nutze ich die Funktion nicht so gerne, sondern lasse eigentlich alle meine KNX Geräte zyklisch senden (damit könnte man sich im Skript dann das "setState" sparen).

tsero

@Garfonso

Danke für die Erklärung! Hatte mir schon sowas gedacht. Allerdings bin ich von der Adapter-Doku ausgegangen, und aufgrund von
habe ich mir gedacht, ein getState wäre ein Trigger für das GroupValueRead. Bin gerade erst dabei mich in ioBroker einzuarbeiten und da gibt es natürlich noch ein paar Startschwierigkeiten ...

Das mit dem Caching von getStates ist mir auch neu und eine Beschreibung dazu konnte ich auch noch nicht finden. Die Funktionsbeschreibung erwähnt das nämlich nicht.

Wie du schon schreibst, schön ist die Variante nicht. Ich kann den Messwert auch über eine eigene GA anfordern. Denke mal das wird dann die bessere Variante sein. Das würde ich dann ungefähr so machen

    setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);
    setStateDelayed("javascript.0.scriptEnabled.Wetter.iMaxWind", getState("knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s").val*3.6,2000);

Kann ich davon ausgehen, dass ich mit einer Verzögerung von 2s dann schon den neuen Wert mit getState bekomme (am Bus sehe ich den Response nach <0,1s). Oder bekomme ich dann noch den Wert aus dem Cache? Bzw. wie kann man den Cache umgehen?

Garfonso

@tsero said in Test Adapter KNX v1.0.x:

@Garfonso

Danke für die Erklärung! Hatte mir schon sowas gedacht. Allerdings bin ich von der Adapter-Doku ausgegangen, und aufgrund von
habe ich mir gedacht, ein getState wäre ein Trigger für das GroupValueRead. Bin gerade erst dabei mich in ioBroker einzuarbeiten und da gibt es natürlich noch ein paar Startschwierigkeiten ...

Gerne.
Ja, das hab ich mir auch gedacht, "Trigger" ist da sicherlich nicht gut verständlich. Da ist man als ioBroker-Entwickler dann auch etwas betriebsblind, weil man weiß, dass ein getState beim Adapter nicht ankommt und es daher nur ein setState sein kann. :-) Also Trigger = setState

Das mit dem Caching von getStates ist mir auch neu und eine Beschreibung dazu konnte ich auch noch nicht finden. Die Funktionsbeschreibung erwähnt das nämlich nicht.

Das ist eine Vereinfachung, die der Javascript Adapter für die User macht, kann man in der Instanz einstellen. Sonst wäre getState immer asynchron, das heißt, du müsstest getState immer mit callbacks verarbeiten, also so z.B.:

getState(id, (state) => {
   log("State " + id + " is " + state.val);
});

// <- hier kann ich auf "state" NICHT zugreifen -> alles muss jetzt in den callback mit rein. Bei mehreren states, die ich abrufen will, wird das schnell sehr unübersichtlich.

Wie du schon schreibst, schön ist die Variante nicht. Ich kann den Messwert auch über eine eigene GA anfordern. Denke mal das wird dann die bessere Variante sein. Das würde ich dann ungefähr so machen
    setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);
    setStateDelayed("javascript.0.scriptEnabled.Wetter.iMaxWind", getState("knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s").val*3.6,2000);
Kann ich davon ausgehen, dass ich mit einer Verzögerung von 2s dann schon den neuen Wert mit getState bekomme (am Bus sehe ich den Response nach <0,1s). Oder bekomme ich dann noch den Wert aus dem Cache? Bzw. wie kann man den Cache umgehen?

Das setStateDelayed verwendest du da falsch...? das getState würde so immer noch sofort ausgeführt und nur der Wert später gesetzt. Für das, was du erreichen willst, brauchst du setTimeout (javascript funktion):

setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);

setTimeout(function () {
       const windGeschwindigkeit = getState("knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s").val*3.6; 
       setState("javascript.0.scriptEnabled.Wetter.iMaxWind", windGeschwindigkeit);
},2000);

Ich würde es so nicht machen, sondern tatsächlich den state abonieren, das heißt, die Funktion wird jedesmal aufgerufen, wenn sich der state ändert -> also sobald ioBroker das Update vom KNX Bus gelesen hat, wird deine Funktion auch aufgerufen. Oder willst du nur, das etwas passiert, wenn du vorher das setState machst?
(Warum hast du scriptEnabled in deiner id, die du setzen willst?)

Also:

//log new measurement, ack: true -> only react to readings from bus!
on({ id: 'knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s', ack: true}, (e) => {
    //diese Funktion wird jedesmal aufgerufen, wenn der State aktualisiert wird, also wenn was neues vom KNX Bus kommt
   log("max knx wind = "+e.state.val);
   setState("javascript.0.Wetter.scriptEnabled.iMaxWind", e.state.val * 3.6, true); //ich setze hier gerne ack=true, dann wird es in der Objektliste grün ;-)
});

//update erzeugen:
setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);

//ggf. auch auf Knopfdruck? -> state erstellen und darauf reagieren
on({ id: 'javascript.0.jetzt_mal_wind_auslesen', val: true, ack: false}, function (e) {
  setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);
  setStateDelayed('javascript.0.jetzt_mal_wind_auslesen', false, true, 500); //nach 500ms wieder auf false setzen, nicht notwendig aber hübscher ;-)
});

Grundsätzlich in Skripten würde ich das immer so machen:
wenn immer etwas passieren soll, wenn neue Information reinkommt, dann unbeding mit on() den state abonnieren.
Wenn du das ganze nur für eine einmalige Berechnung brauchst, dann ist getState ok. In deinem speziellen Fall würde ich aber da bei on bleiben, das du nur einmal was machen willst, könnte man auch so erreichen:

//update erzeugen:
setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);
let doSomething = true; //ok, funktion darf einmal ausgeführt werden.

//wird nur etwas tun, wenn doSomething = true
on({ id: 'knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s', ack: true}, (e) => {
    //diese Funktion wird jedesmal aufgerufen, wenn der State aktualisiert wird, also wenn was neues vom KNX Bus kommt
   if (doSomething) {
       log("max knx wind = "+e.state.val);
       setState("javascript.0.Wetter.scriptEnabled.iMaxWind", e.state.val * 3.6, true); //ich setze hier gerne ack=true, dann wird es in der Objektliste grün ;-)
      doSomething = false;
   }
});

(ok, besser wäre noch das schedule wieder zu entfernen, geht auch mit unsubscribe, meine ich, müsste ich aber nachgucken).

tsero

@Garfonso und nochmals danke ... habe wieder einiges gelernt. Ich denke jetzt passt es. Immer zur vollen Stunde frage ich den max-Windwert der letzten Stunde ab und setzte ihn danach zurück. Über die subscription lausche ich auf den neuen max-Werte und setzt ihn dann in meinen DP:

schedule("0 * * * *", function () {
    setState('knx.0.0_Zentral.0_1_Messwerte.Abfrage_Wind_max',true);
    setStateDelayed("knx.0.0_Zentral.0_1_Messwerte.Reset_Wind_max",true,500);
});

on({ id: 'knx.0.0_Zentral.0_1_Messwerte.Messen_Wind_max_m_s', ack: true}, (e) => {
    //diese Funktion wird jedesmal aufgerufen, wenn der State aktualisiert wird, also wenn was neues vom KNX Bus kommt
   setState("javascript.0.Wetter.iMaxWind", e.state.val * 3.6, true); 
});

Bei deiner Frage Warum hast du scriptEnabled in deiner id, die du setzen willst? bin ich dann gleich mal ins Schwitzen geraten ... und wie befürchtet, habe ich wiedermal ins Schwarze getroffen. Beim initialen Herumspielen habe ich den Ordner scriptEnabled gesehen. Dachte mir, aha, klingt gut, da kommt alles was zu den aktivierten Scripts gehört rein. Also habe ich ohne viel nachzudenken alle DPs da drinnen anlegt.
Nach deiner Frage, habe ich dann mal nach scriptEnabled gegooglt ... war wohl doch nicht so optimal.
Naja, das war jetzt meine Nachmittagsbeschäftigung. Habe alle DPs da raus geholt .. eine schöne Arbeit. Aber jetzt isses sauber.

Eine Verständnisfrage hätte ich dann doch noch zur zeitlichen Abfolge. Die Sinnhaftigkeit des Scripts bitte nicht beachten.
Verstehe ich das richtig, dass der zeitliche Ablauf wie folgt ist:

(2) wird sofort vom Cache gelesen, aber erst nach 2s in den DP (1) geschrieben.
Das log Kommand (3) wird erst nach Ablauf der 2s ausgeführt, und der DP (4) wird auch erst nach 2s ausgelesen.
Kommt das so hin?

Garfonso

@tsero said in Test Adapter KNX v1.0.x:

(2) wird sofort vom Cache gelesen, aber erst nach 2s in den DP (1) geschrieben.
Das log Kommand (3) wird erst nach Ablauf der 2s ausgeführt, und der DP (4) wird auch erst nach 2s ausgelesen.
Kommt das so hin?

Ja, alles korrekt. :-)

Wenn du jetzt nach }); noch etwas stehen hättest, das würde ebenfalls sofort ausgeführt. Das kann manchmal etwas kontraintuitiv sein.

Community Forum

NEWS

Test Adapter KNX v1.0.x

Support us

519

32.4k

81.4k

1.3m