UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[dachauan]

@netfriend
Bei mir gehts jetzt.
Probiers mal aus, ist jetzt nur hard coded drin, muss man mal konfigurierbar machen.
Vielleicht hab ich nächste Woche mal Zeit.
https://github.com/dachauan/ioBroker.openknx

[netfriend]

@dachauan Super, probier ich gerne aus. Wo ist das drin, wie komme ich dazu?

[dachauan]

@netfriend Im iobroker den Expertenmodus aktivieren, dann im Tab Adapters auf das Github Symbol klicken, Benutzerdefiniert auswählen und die Url aus meinem Post verwenden.

[netfriend]

@dachauan Alles klar, Installation hat geklappt, danke Dir - wieder was gelernt.
Der erste Versuch hat schon mal geklappt, der Aktor schaltet. Danke für Deine Bemühungen!
Werde später noch weiter testen...

[andreaskos]

Hi zusammen,

ich hab mittlerweile schon viele Anlagen mit ioBroker und KNX in Betrieb genommen und muss sagen:
Herzliche Gratulation @killroy2 !
Ich hab hier schon eine Weile mitgelesen und seit letzter Woche den Adapter erstmals im Test. Das Ergebnis ist sehr erfreulich. Das Importieren geht zügig und die Kommunikation läuft problemlos. Seit dem ersten Einschalten des Adapters.

Ich verwende übrigens (meistens, aber nicht immer) den IP-Router von INTERRA: https://www.smarthomekos.at/shop/interra/systemgeräte/#cc-m-product-16999766496

Ich hab zwar eigene Scripte, die die Action- und Status-Datenpunkte zusammenführen zu einem Kombi-Datenpunkt, aber grundsätzlich finde ich die Lösung mit den Aliases sehr elegant!

Liebe Grüße
Andreas

[killroy2]

@netfriend said in Test Adapter OpenKNX 0.1.x:

Vermutlich setzen Sie dieses Bit (acknowledge request) fälschlicherweise irgenwo in Ihrem RaspberryPi4
mit IoBroker und dem openKNX-Adapter.

Ich verstehe nicht auf welche Anforderung der Weinzierl Support mit dieser Aussage abziehlt.
Laut Spec gibt es keinen unterschied ob das ACK Flag gesetzt ist oder nicht.

https://github.com/Supergiovane/node-red-contrib-knx-ultimate/issues/78 erweckt den Eindruck, dass manche Empfänger das Telegramm deswegen verwerfen, warum auch immer.
Hersteller scheinen das Verhalten zu kennen und aktiv herauszufiltern. Mein MDT und Weinzierl 730 machen das.

Ich werde jetzt den Adapter einfach so umbauen, dass er immer mit ACK = 0 sendet. Ich sehe keine Notwendigkeit eine 1 schicken zu können.

[netfriend]

@killroy2 Irgendwie ist es schon komisch. Der Weinzierl Support schreibt ja selber dass das (alte) 730 das prüft und ggf. ersetzt, das neuere 732 macht das aber nicht.
Ich hatte auch gestern nochmal nachgefragt, ob es zwischenzeitlich ein Firmwareupdate für das 732 gibt, wo dieses Verhalten behoben ist. War ja in dem oben verlinkten Beitrag so angedeutet. Klare Antwort: nein, gibt es nicht.
Ich empfinde das eigentlich als Verschlimmbesserung.
Umso mehr freue ich mich, dass es in openknx angepasst wurde und es nun funktioniert!

[killroy2]

0.1.21 ist jetzt herausen

Changelog

0.1.21 (2022-02-25)

• feature: dont sent ack request in ldata.ind, this is disturbing clients if not filtered out by gateway
• bugfix: reinit if event received before connection established to avoid deadlock
• dependency:adapter core must be 2.6.0 or higher

[ChrisChros]

@killroy2
Hast du irgendetwas am logging bei der neuen Version geändert?
Aktuell bekomme ich mit der neuen Version viele Meldungen über falsche Datentypen:

2022-02-26 09:22:48.798 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Strom_Lambdasonde" has to be type "number" but received type "string"
2022-02-26 09:22:48.899 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Anforderung_HK_Regler_1" has to be type "number" but received type "string"
2022-02-26 09:22:48.982 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Anforderung_HK_Regler_2" has to be type "number" but received type "string"
2022-02-26 09:22:49.285 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Spreizung_Rücklauf" has to be type "number" but received type "string"
2022-02-26 09:22:49.867 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Pumpe_HK1" has to be type "boolean" but received type "string"
2022-02-26 09:18:01.486 - info: openknx.0 (13974) State value to set for "openknx.0.Zentral.Wetter___Zeit___Datum.Luftfeuchte" has to be type "number" but received type "string"

Diese Meldungen hatte ich mit den alten Versionen nicht erhalten.

Zusätzlich bekomme ich seit dem Adapter-Update auch noch Log-Einträge von dem InfluxDB-Adapter der bestimmte KNX-Datenpunkte aufzeichnen soll

2022-02-26 09:18:02.496 - warn: influxdb.0 (10853) Error on writePoint("{"value":"null","time":"2022-02-26T08:18:01.488Z","from":"system.adapter.openknx.0","q":0,"ack":true}): Error: {"error":"partial write: field type conflict: input field \"value\" on measurement \"openknx.0.Zentral.Wetter___Zeit___Datum.Luftfeuchte\" is type string, already exists as type float dropped=1"}

Wie kann ich die alte Version 0.1.20 wiederherstellen?

cd /opt/iobroker
npm install iobroker.openknx@0.1.20 --production

damit sollte es doch klappen oder?

[killroy2]

@chrischros sorry, da war ein grober Fehler drin, nimm die 0.1.22; muss meine Tests anpassen sowas besser zu erkennen

[ChrisChros]

@killroy2
Danke für das schnelle Update, sieht bisher sehr gut aus.

Rein aus Interesse, worin bestand der Fehler in der vorherigen Version?

[netfriend]

@killroy2 Hat sich denn in der 0.1.22 etwas geändert bzgl. DPT? Also z.B. das Thema mit dem DPT 12.1200, ist das inzwischen enthalten oder kommt das später?

[beetlejules]

Moin zusammen,

Danke erst mal für den Adapter, funktioniert bestens soweit.
Steige gerade vom anderen "alten" Adapter um und jetzt ist mir aber noch ein Problemchen mit dem DPT 3 aufgefallen. Es liegt vermutlich nicht am Adapter, eher am Datentyp oder sonst ein Verständnisproblem meinerseits.

Ich steuere eine HUE Leuchte mit dem KNX Schalter aktuell wie folgt und es funktioniert

// Dimmen
// 1,1=dimUp, 0=stop, 0,1=dimDown
on({id: 'knx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ', change: "ne"}, async function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  // Dimmen hoch
  if (getState("0_userdata.0.dimUp").val == getState("knx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ").val) {
    setState("hue-extended.0.lights.005-küche_deckenleuchte.action._commands"/*Küche Deckenleuchte - Apply multiple commands on the device*/, ('' + (['{"bri_inc":254,"transitiontime":10,"ct":',getState("0_userdata.0.FarbtemperaturSoll").val,'}'].join(''))));
  }

Passe ich alles auf OpenKNX an, scheitert es am Vergleich der Userdata Variable mit der KNX Variable.
Userdata Variable ist natürlich angepasst.

Alt:
KNX

Userdata

Neu:
KNX

Userdata

Hat jemand eine Idee?
Vielen Dank

[killroy2]

@beetlejules said in Test Adapter OpenKNX 0.1.x:

DPT 3
unittest ist läuft durch mit 0.1.22 und ich habs im life system positiv getestet:
{"decr_incr":1,"data":2}
Welche Fehlermeldung bekommst du in der Console?
Welche Version vom Adapter?

[killroy2]

@netfriend ja ist drin

[hias-grandl]

Hallo,
ich mach gerade meine ersten Versuche, mittels iobroker (und dann mal mit HABPanel) mit KNX zu interagieren. Ich bitte jetzt schon um Entschuldigung, ich bin noch ziemlicher Anfänger in dieser Welt.
Die Installation des Adapters hat geklappt und der Imprts der GA's auch.
ABER: Ich habe anscheinend das gleiche Problem wie früher schon einmal geschildert. Wenn ich einen Wert schreibe (im HABPanel oder im iobroker), dann wird er im Gruppenmonitor angezeigt, aber es passiert real nichts. Unterschied: In der Spalte "Dienst" im Gruppenmonitor steht bei der entsprechenden Zeile nicht "vom Bus" wie wenn ich z.B. einen realen Taster drücke, sondern "zum Bus".
Ich habe in der Diskussion keine Lösung gefunden, was mache ich falsch.
Bzw. welche Infos braucht es von mir?
Danke schon mal

[netfriend]

@hias-grandl Ich hatte das Problem, dass ich keinen Aktor schalten konnte, obwohl es im Gruppenmonitor richtig angezeigt wurde. Ob da "vom Bus" oder "zum Bus" stand, weiß ich allerdings nicht mehr.
Ursache waren zwei Umstände, die zusammen getroffen sind: die Openknx-Version und das IP-Interface.

Mit der Openknx-Version 0.1.20 hat es funktioniert. Die 0.1.22 habe ich noch nicht probiert.

Vielleicht hilft Dir das weiter. Viel Erfolg!

[hias-grandl]

@netfriend
Danke! Mit der aktuellsten Version funktioniert es, die Befehle zeigen Wirkung!
Jetzt werde ich mal probieren und hoffe, dass ich nicht so schnell wieder Hilfe brauche...
Schönen Sonntag allen!

[beetlejules]

@killroy2 Der Wert {"decr_incr":1,"data":1} kommt vom Adapter, kein Problem, bekomme auch keine Fehlermeldung.
Allerdings wenn ich ihn jetzt vergleiche in der if Abfrage, passiert nichts.
Der debug in der trigger Funktion spuckt mir 'trigger' aus wenn ich schalte. Die if Anweisung spuckt aber kein 'dimup' aus.
Wert vom Adapter wird also nicht mit dem hier mal direkt in den Code geschriebenen {"decr_incr":1,"data":1} als gleich angesehen.

Adapterversion ist die 0.1.22

on({id: 'openknx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ', change: "ne"}, async function (obj) {
  var value = obj.oldState.val;
  var oldValue = obj.oldState.val;
  console.warn('trigger');
  // Dimmen hoch
  if ({"decr_incr":1,"data":1} == getState("openknx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ").val) {
    setState("hue.0.Küche_Deckenleuchte.command", ('' + (['{"bri_inc":254,"transitiontime":10,"ct":',getState("0_userdata.0.Beleuchtung.adaptiveCtSolar").val,'}'].join(''))));
    console.warn('dimup');
  }
});

[killroy2]

@beetlejules Wenn du auf Objekte schreibst, wird kein ACK Flag generiert. Deswegen wird deine Funktion nicht aufgerufen. Wenn du Werte empfängst, wird das ACK Flag generiert. So ist das Konzept vom Adapter. Ich vermute deshalb, wenn du mit ETS von aussen sendest, wie es denke ich dein Anwendungsfall ist, wird es gehen.