NEWS
Test Adapter KNX v1.0.x
-
@loverz den Umweg über die alte Version möchte ich endlich loswerden, das Problem ist ja auch das dann neuere Datentypen nicht importiert werden. Die 1.20 hatte afaik nicht die true/false Darstellung für bool, das hat Auswirkungen auf Scripte.
Ich hatte gestern auch noch mit den Flags gespielt, aber die haben doch keine Auswirkung auf die Pärchenbildung?Ich war gestern auch nicht mehr sicher ob die Pärchen noch gebraucht werden: wenn ich Licht am Schalter ein/ausschalte, dann ändert sich der Status in der Vis trotzdem. Das war doch vorher das Problem? Ich probiere es gleich nochmal.
-
@jojos das mit der vis weiß ich nicht, nutze die nicht.
1/0 statt true/false ist tatsächlich ein Nachteil der alten Version, aber meine Scripte kommen damit klar. Weiß nicht was da nicht passen soll. -
Hurra, wenn ich den Mittelgruppen auch ein 'Status' anhäge, dann klappt es!
Dafür funktioniert jetzt die Vis nicht mehr
ok, geht wieder. Der KNX Adapter hatte das Netzwerkinterface vergessen, das Feld war leer, warum auch immer. -
@jojos sehr, sehr komisch wie der Adapter auf die „Pärchensuche“ geht
Freut mich aber, dass es bei dir mit geringem Aufwand funzt
@loverz Es steht hier schwarz auf weiß: https://github.com/ioBroker/ioBroker.knx#wie-werden-die-datenpunkte-generiert-deutsch
Sogar auf deutsch. Was daran komisch sein soll weißt wohl nur du.
-
@loverz Es steht hier schwarz auf weiß: https://github.com/ioBroker/ioBroker.knx#wie-werden-die-datenpunkte-generiert-deutsch
Sogar auf deutsch. Was daran komisch sein soll weißt wohl nur du.
@lessthanmore es ist komisch, dass der Adapter @JojoS Objekte unterscheiden kann, obwohl sich diese in den Mitteladressen unterscheiden.
In deiner verlinkten Anleitung steht:
-
- Herausfinden der Schalt- und Statusaddressen
In dem ETS-Export sind die Schalt- und Statusadressen nicht hinterlegt. Somit führe ich eine Ähnlichkeitsprüfung aller Gruppenadressnamen durch mit der Auswertung auf status und state. Wird ein Pärchen gefunden, dessen
Ähnlichkeit mehr als 90% beträgt, dann wird angenommen, dass die GA1 die Schaltadresse und GA2 die Statusadresse ist. Dabei erhält GA1 das write=true und read=false und GA2 das write=false und read=true. Außerdem werden die DPT abgeglichen aus der jeweilig korrespondierenden GA. Aus diesem Grund ist es schwierig, Pärchen zu finden, wenn die Gruppenadressbeschriftungen nicht konsistent sind.
- Herausfinden der Schalt- und Statusaddressen
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Statushab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.
Würden die Pärchen wie folgt heißen:
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_schalten
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_Statuswäre eine korrekte Zuweisung wahrscheinlicher.
Das finde ich persönlich mehr als komisch, da sollte aus meiner Sicht nachgebessert werden.Klar kann der Entwickler den Adapter programmieren wie er will, letztlich bin ich auch froh, dass er überhaupt einen entwickelt hat, aber ich bleibe dabei: Die Voraussetzungen könnten besser sein
-
-
@lessthanmore es ist komisch, dass der Adapter @JojoS Objekte unterscheiden kann, obwohl sich diese in den Mitteladressen unterscheiden.
In deiner verlinkten Anleitung steht:
-
- Herausfinden der Schalt- und Statusaddressen
In dem ETS-Export sind die Schalt- und Statusadressen nicht hinterlegt. Somit führe ich eine Ähnlichkeitsprüfung aller Gruppenadressnamen durch mit der Auswertung auf status und state. Wird ein Pärchen gefunden, dessen
Ähnlichkeit mehr als 90% beträgt, dann wird angenommen, dass die GA1 die Schaltadresse und GA2 die Statusadresse ist. Dabei erhält GA1 das write=true und read=false und GA2 das write=false und read=true. Außerdem werden die DPT abgeglichen aus der jeweilig korrespondierenden GA. Aus diesem Grund ist es schwierig, Pärchen zu finden, wenn die Gruppenadressbeschriftungen nicht konsistent sind.
- Herausfinden der Schalt- und Statusaddressen
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Statushab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.
Würden die Pärchen wie folgt heißen:
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_schalten
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_Statuswäre eine korrekte Zuweisung wahrscheinlicher.
Das finde ich persönlich mehr als komisch, da sollte aus meiner Sicht nachgebessert werden.Klar kann der Entwickler den Adapter programmieren wie er will, letztlich bin ich auch froh, dass er überhaupt einen entwickelt hat, aber ich bleibe dabei: Die Voraussetzungen könnten besser sein
@loverz Nicht nur der Name der GA ist entscheidend, sondern u. a. auch deren DPT und die Flags.
Da ich momentan nicht von einer Weiterentwicklung ausgehe ist es eh egal. -
-
@loverz Nicht nur der Name der GA ist entscheidend, sondern u. a. auch deren DPT und die Flags.
Da ich momentan nicht von einer Weiterentwicklung ausgehe ist es eh egal.@lessthanmore doch der Adapter wird wohl weiterentwickelt, habe Infos aus guter Quelle
-
@Bluefox Kannst du bitte hier etwas zu sagen, du hast doch Zugriff auf den Code.
Danke vorab. -
@lessthanmore es ist komisch, dass der Adapter @JojoS Objekte unterscheiden kann, obwohl sich diese in den Mitteladressen unterscheiden.
In deiner verlinkten Anleitung steht:
-
- Herausfinden der Schalt- und Statusaddressen
In dem ETS-Export sind die Schalt- und Statusadressen nicht hinterlegt. Somit führe ich eine Ähnlichkeitsprüfung aller Gruppenadressnamen durch mit der Auswertung auf status und state. Wird ein Pärchen gefunden, dessen
Ähnlichkeit mehr als 90% beträgt, dann wird angenommen, dass die GA1 die Schaltadresse und GA2 die Statusadresse ist. Dabei erhält GA1 das write=true und read=false und GA2 das write=false und read=true. Außerdem werden die DPT abgeglichen aus der jeweilig korrespondierenden GA. Aus diesem Grund ist es schwierig, Pärchen zu finden, wenn die Gruppenadressbeschriftungen nicht konsistent sind.
- Herausfinden der Schalt- und Statusaddressen
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Statushab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.
Würden die Pärchen wie folgt heißen:
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_schalten
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_Statuswäre eine korrekte Zuweisung wahrscheinlicher.
Das finde ich persönlich mehr als komisch, da sollte aus meiner Sicht nachgebessert werden.Klar kann der Entwickler den Adapter programmieren wie er will, letztlich bin ich auch froh, dass er überhaupt einen entwickelt hat, aber ich bleibe dabei: Die Voraussetzungen könnten besser sein
@loverz said in Test Adapter KNX v1.0.x:
obwohl sich diese in den Mitteladressen unterscheiden.
ich habe 'Status' ja zweimal angehängt, in der Mittelgruppe und nochmal in der GA. Die Namen in einer Gruppe hatte ich auch schonmal probiert, ca. 10 Versionen vor dieser aktuellen.
Finde ich auch komisch, aber insgesamt funktioniert der Adapter sehr gut und stabil.
Weitere Versuche würde ich später an einem Testsystem machen, -
-
@lessthanmore es ist komisch, dass der Adapter @JojoS Objekte unterscheiden kann, obwohl sich diese in den Mitteladressen unterscheiden.
In deiner verlinkten Anleitung steht:
-
- Herausfinden der Schalt- und Statusaddressen
In dem ETS-Export sind die Schalt- und Statusadressen nicht hinterlegt. Somit führe ich eine Ähnlichkeitsprüfung aller Gruppenadressnamen durch mit der Auswertung auf status und state. Wird ein Pärchen gefunden, dessen
Ähnlichkeit mehr als 90% beträgt, dann wird angenommen, dass die GA1 die Schaltadresse und GA2 die Statusadresse ist. Dabei erhält GA1 das write=true und read=false und GA2 das write=false und read=true. Außerdem werden die DPT abgeglichen aus der jeweilig korrespondierenden GA. Aus diesem Grund ist es schwierig, Pärchen zu finden, wenn die Gruppenadressbeschriftungen nicht konsistent sind.
- Herausfinden der Schalt- und Statusaddressen
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Statushab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.
Würden die Pärchen wie folgt heißen:
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_schalten
Wohnzimmer_Spots_Südseite_Hallowiegehtsdennso?_Statuswäre eine korrekte Zuweisung wahrscheinlicher.
Das finde ich persönlich mehr als komisch, da sollte aus meiner Sicht nachgebessert werden.Klar kann der Entwickler den Adapter programmieren wie er will, letztlich bin ich auch froh, dass er überhaupt einen entwickelt hat, aber ich bleibe dabei: Die Voraussetzungen könnten besser sein
@loverz said in Test Adapter KNX v1.0.x:
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Status
hab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.Empfehlung: nimm das "_schalten" weg. Das "_Status" "versteht" der Adapter und dann ist es für ihn quasi 100% Übereinstimmung (- Mittelgruppen, die werden auch Berücksichtigt) und du hast die Verknüpfung recht sicher.
-
-
@loverz said in Test Adapter KNX v1.0.x:
Bei mir jedoch wird nicht korrekt erkannt:
Wohnzimmer_Spots_Südseite_schalten
Wohnzimmer_Spots_Südseite_Status
hab gerade gerechnet und es sind tatsächlich nur 81,25% Übereinstimmung.Empfehlung: nimm das "_schalten" weg. Das "_Status" "versteht" der Adapter und dann ist es für ihn quasi 100% Übereinstimmung (- Mittelgruppen, die werden auch Berücksichtigt) und du hast die Verknüpfung recht sicher.
@garfonso ja, das hat mir @lessthanmore auch schon empfohlen.
Das Problem
Ist halt immernoch, dass ich unzählige Javascripts habe, die ich dann anpassen müsste.Mittlerweile kenne ich mich aber schon etwas besser aus:
Ich könnte ja die Scripts exportieren, die json-Datei mit einem Editor durchforsten und „search and replace“ anwenden.
Anschließend das ganze wieder importieren.Spricht da was dagegen?
-
@garfonso ja, das hat mir @lessthanmore auch schon empfohlen.
Das Problem
Ist halt immernoch, dass ich unzählige Javascripts habe, die ich dann anpassen müsste.Mittlerweile kenne ich mich aber schon etwas besser aus:
Ich könnte ja die Scripts exportieren, die json-Datei mit einem Editor durchforsten und „search and replace“ anwenden.
Anschließend das ganze wieder importieren.Spricht da was dagegen?
@loverz gute Idee, hatte ich auch schon, aber mein Javascript ist zu schlecht. Dann kann man zur Kontrolle auch die DP ohne StatusRef ausgeben. Wie der KNX Baum erzeugt wird sollte ja egal sein, der KNX Adapter baut den ja auch nur auf Anforderung mit Import der knxproj Datei.
-
@loverz gute Idee, hatte ich auch schon, aber mein Javascript ist zu schlecht. Dann kann man zur Kontrolle auch die DP ohne StatusRef ausgeben. Wie der KNX Baum erzeugt wird sollte ja egal sein, der KNX Adapter baut den ja auch nur auf Anforderung mit Import der knxproj Datei.
-
@garfonso ja, das hat mir @lessthanmore auch schon empfohlen.
Das Problem
Ist halt immernoch, dass ich unzählige Javascripts habe, die ich dann anpassen müsste.Mittlerweile kenne ich mich aber schon etwas besser aus:
Ich könnte ja die Scripts exportieren, die json-Datei mit einem Editor durchforsten und „search and replace“ anwenden.
Anschließend das ganze wieder importieren.Spricht da was dagegen?
@loverz said in Test Adapter KNX v1.0.x:
Ist halt immernoch, dass ich unzählige Javascripts habe, die ich dann anpassen müsste
Mit KNX kann ich nur empfehlen immer mit Alias zu arbeiten. Anders wirst du auch das ganze Devices-Zeug nicht hinbekommen. Guck dir mal den aktuellen Devices Adapter an und klick aus deinen KNX-Objekten Geräte zusammen. Dann nimmst du in Skripten und Visualisierungen nur noch die alias.0.* IDs und kannst die dann, falls sich nochmal was ändert, an einer Stelle umbiegen.
Grundsätzlich spricht nichts dagegen die Scripte außerhalb von ioBroker zu verändern. Es gibt sogar einen Filesystem Mirror dafür, dann müsstest du dich nichtmal selbst um ex-/import kümmern.
-
@jojos dafür braucht man doch gar keine Javascript Kenntnisse.
Bei mir sind auch alles nur Blocklys.Was meinst du mir StatusRef?
Ist das einer dieser Attribute in der RAW Anzeige eines Objektes?@loverz said in Test Adapter KNX v1.0.x:
Was meinst du mir StatusRef?
Ist das einer dieser Attribute in der RAW Anzeige eines Objektes?ja, da waren wir aneinander vorbei, du meinst vermutlich die Anwendungsscripte.
Ich war beim Pärchenproblem, da könnte man durch nachträgliches bearbeiten des KNX Baumes was machen.
"addressRefId": "P-0AC9-0_GA-350",
"statusGARefId": "P-0AC9-0_GA-355",
das ist aus den KNX Datenpunkten aus der raw Anzeige, das ist ja das Problem das die statusGARefId leer ist wenn die Zuordnung nicht gefunden wurde. -
@loverz said in Test Adapter KNX v1.0.x:
Ist halt immernoch, dass ich unzählige Javascripts habe, die ich dann anpassen müsste
Mit KNX kann ich nur empfehlen immer mit Alias zu arbeiten. Anders wirst du auch das ganze Devices-Zeug nicht hinbekommen. Guck dir mal den aktuellen Devices Adapter an und klick aus deinen KNX-Objekten Geräte zusammen. Dann nimmst du in Skripten und Visualisierungen nur noch die alias.0.* IDs und kannst die dann, falls sich nochmal was ändert, an einer Stelle umbiegen.
Grundsätzlich spricht nichts dagegen die Scripte außerhalb von ioBroker zu verändern. Es gibt sogar einen Filesystem Mirror dafür, dann müsstest du dich nichtmal selbst um ex-/import kümmern.
-
@garfonso meinst du diesen Adapter?
Edit:
Wohl eher den hier:
gibts aber nur auf Github bzw. hatte wohl den Stern oben an.
@loverz
Ne, Gerätesuche nicht. "Geräteverwaltung" oder sowas heißt der auf Deutsch. Der ist das: https://github.com/ioBroker/ioBroker.devicesDer erzeugt den Tab "Geräte" und da siehst du unter "Native Geräte" zum einen, was ioBroker so automatisch bei dir erkennt in der Struktur der Adapter usw. (bei knx dürfte nur Quatsch drin sein). Und drum herum kannst du eine eigene Struktur (ich hab da nochmal Ordner für Licht, Rolladen, usw. gemacht) und da Alias-Geräte anlegen, die dann in alias.0.* angelegt werden (also ggf. Ordner und darinen pro Gerät ein Ordner mit den States, die dazu passen). Das ist alles noch etwas roh und der "Hauptstate" heißt meist "SET" (und Status ist "ACTUAL", wenn nicht da irgendwas im KNX Adapter AFAIK kaputt ist, könnte man damit die Zuordnung von act/status auch machen).
-
@loverz
Ne, Gerätesuche nicht. "Geräteverwaltung" oder sowas heißt der auf Deutsch. Der ist das: https://github.com/ioBroker/ioBroker.devicesDer erzeugt den Tab "Geräte" und da siehst du unter "Native Geräte" zum einen, was ioBroker so automatisch bei dir erkennt in der Struktur der Adapter usw. (bei knx dürfte nur Quatsch drin sein). Und drum herum kannst du eine eigene Struktur (ich hab da nochmal Ordner für Licht, Rolladen, usw. gemacht) und da Alias-Geräte anlegen, die dann in alias.0.* angelegt werden (also ggf. Ordner und darinen pro Gerät ein Ordner mit den States, die dazu passen). Das ist alles noch etwas roh und der "Hauptstate" heißt meist "SET" (und Status ist "ACTUAL", wenn nicht da irgendwas im KNX Adapter AFAIK kaputt ist, könnte man damit die Zuordnung von act/status auch machen).
@garfonso danke für den Tipp, sieht echt nach ner guten Lösung aus.
Dennoch: Es ist in meinem Fall sehr viel Arbeit, die ich aber echt mal machen sollte, dann bin ich hinterher flexibler.Kann ich mich auf den Adapter verlassen? Also ich meine: Ist es unwahrscheinlich, dass er mit dem nächsten Update nicht mehr supportet wird o.Ä.?
-
@garfonso danke für den Tipp, sieht echt nach ner guten Lösung aus.
Dennoch: Es ist in meinem Fall sehr viel Arbeit, die ich aber echt mal machen sollte, dann bin ich hinterher flexibler.Kann ich mich auf den Adapter verlassen? Also ich meine: Ist es unwahrscheinlich, dass er mit dem nächsten Update nicht mehr supportet wird o.Ä.?
@loverz
das alias-Feature ist ein Feature vom js-controller. Also selbst wenn der Adapter selber nicht mehr weiter entwickelt werden sollte (er ist allerdings auch "im Kern" von ioBroker und wird von bluefox selber entwickelt) oder sich stark verändern sollte, werden die aliase weiter funktionieren (aliase kann man auch von Hand oder per Skript anlegen ).Ja, das ist am Anfang viel Arbeit. Aber bisher hab ich es bei mir nicht bereut, im Gegenteil.
-
@loverz
das alias-Feature ist ein Feature vom js-controller. Also selbst wenn der Adapter selber nicht mehr weiter entwickelt werden sollte (er ist allerdings auch "im Kern" von ioBroker und wird von bluefox selber entwickelt) oder sich stark verändern sollte, werden die aliase weiter funktionieren (aliase kann man auch von Hand oder per Skript anlegen ).Ja, das ist am Anfang viel Arbeit. Aber bisher hab ich es bei mir nicht bereut, im Gegenteil.
Support us
531
Online32.4k
Users81.4k
Topics1.3m
Posts