Skip to content
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo
  1. ioBroker Community Home
  2. Deutsch
  3. Tester
  4. Test Adapter OpenKNX 0.6.x

NEWS

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    8.1k

  • Monatsrückblick – September 2025
    BluefoxB
    Bluefox
    13
    1
    1.8k

  • Neues Video "KI im Smart Home" - ioBroker plus n8n
    BluefoxB
    Bluefox
    15
    1
    2.1k

Test Adapter OpenKNX 0.6.x

Geplant Angeheftet Gesperrt Verschoben Tester
577 Beiträge 72 Kommentatoren 161.4k Aufrufe 71 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • K killroy2
    Aktuelle Testversion v0.7.3-alpha.1
    Stabile Version: 0.6.3
    Erstveröffentlichungsdatum 16.12.2021
    Github Link https://github.com/iobroker-community-adapters/ioBroker.openknx/
    NPM Link https://www.npmjs.com/package/iobroker.openknx
    Issues Board in GitHub https://github.com/iobroker-community-adapters/ioBroker.openknx/issues

    Installation der Testversion
    "Adapter", "Expertenmodus", "Octocat", "Benutzerdefiniert" und diesen Link:
    https://github.com/iobroker-community-adapters/ioBroker.openknx.git

    Adapter Beschreibung, Changelog etc.
    Hier ist die erste öffentliche Testversion des Open KNX Adapters. Der Adapter kommuniziert über ein IP Interface mit dem KNX Bus. Verschiedene KNX Telegrammtypen (GroupValue_Read, GroupValue_Write, GroupValue_Response) in Sende- und Empfangsrichtung werden in, dem IOB Anwender vertrauten Interaktionen mit IoBroker Objekten übersetzt.

    Motivation
    Ich habe den Adapter aus einer Not heraus erstellt, da der verfügbare Adapter nicht fehlerfrei lief und nicht kompatibel zu meinen IP Interfaces ist. Debuggen war aufgrund Closed Source nicht möglich. Da Adapter läuft so gut, dass ich ihn der Öffentlichkeit übergeben möchte.
    Der Adapter ist Quelloffen, Code kann gerne von Jedermann inspiziert und Pull Requests eingestellt werden.
    Eine Beschreibung des Adapters und dessen Verwendung ist auf den verlinkten Seiten zu finden.

    Ziel
    Der Adapter soll:

    • Stabil laufen und sich Standardkonform verhalten
    • möglich einfach und verständlich sein
    Thema umgesetzt ab Version Erwartung
    Release 0.1.x Release im stable repository
    Installation 0.1.6 Adapter lässt sich fehlerfrei über NPM installieren
    Installation 0.1.9 Adapter lässt sich über IOB Bordmittel installieren
    Betrieb 0.1.6 Adapter zeigt den Betriebszustand (rot,gelb,grün) korrekt an, bei Verbindungsabbrucht wird der Adapter gelb, keine Warnungen im Log die nicht zum Zustand passen
    Betrieb 0.1.8 keine Warnungen im Log die nicht zum Zustand passen
    Übersetzung 0.1.8 Admin Dialoge in alle Sprachen übersetzt, Logs nicht
    Alias 0.1.11 Generierung von Alias zur Zusammenbringen von Status und Ausgabe-GA zu einem Objekt eingebaut, noch nicht fehlerfrei

    Ich erhoffe mir Feedback zB zu

    • Bugs, Error Logs;
    • Verständlichkeit und Vollständigkeit der Doku
    • Verwendbarkeit des Adapters, sind die Features brauchbar, was fehlt essentielles
    • Code Reviews
    • Erfahrungen aus dem Betrieb
    • Ideen zur Geschäftslogik, zB werden aktuell Szenen DPTs von der Autoread Abfrage bei Start ausgeschlossen; gibt es bessere Filter?
    • Verbesserungsvorschläge am Interface, z.B. welche State roles eignen sich für welche DPTs, sind die Datentypen passend gewählt, ...

    Feature Anfragen, Fehlermeldungen dürfen gerne in GitHub erstellt werden. Umsetzung erfolgt immer nach Beschlusslage.

    B Offline
    B Offline
    Bachl
    schrieb am zuletzt editiert von
    #112

    @killroy2
    Vielen Dank für den Adapter.
    Habe diesen kurz getestet. Funktioniert bisher fehlerfrei.

    Viele Grüße!

    1 Antwort Letzte Antwort
    0
    • K killroy2

      @tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

      T Offline
      T Offline
      tdoc
      schrieb am zuletzt editiert von
      #113

      @killroy2 said in Test Adapter OpenKNX 0.1.x:

      @tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

      Hm, verstehe deine Antwort nicht ganz. "DAS" darf nicht funktionieren? Was darf nicht funktionieren?
      Natürlich funktioniert es prima, wenn ich manuell einen DPT 9.004 in das iobroker-Objekt eingebe. Jetzt weiß der Adapter ja, wie die 2 Byte zu interpretieren sind. Und alle Warnungen sind weg und ich bin glücklich und zufrieden. Hab die Wetterdaten halt früher nie verwendet und deshalb nie gesehen, dass im ioBroker Objekt nur Unsinn steht. Dank deiner Warnungen ist mir jetzt der Fehler aufgefallen.

      Noch ein paar Hintergrundinformationen: natürlich sind heute DPTs in KNX vorgeschrieben. Unsere Installation stammt aber noch aus EIB-Zeiten. D.h. es gab allenfalls EIS (EIS = EIB Interworking Standard), Vorläufer und ähnlich den DPTs von heute. Unser zertifizierter Elektriker hat jedenfalls entweder nie EIS benutzt (war damals explizit zulässig, damals wie heute wird bei fehlendem Datentyp lt. KNX ein definierter Standardwert für die gegebene Länge gesetzt)) und nur mit Länge gearbeitet, oder aber die Konvertierung (von EIS in DPTs) ist an dieser Stelle schiefgelaufen. Kann ich heute nicht mehr nachvollziehen. Die damalige Installation im Haus funktioniert natürlich, und die heute mir vorliegende ETS5 Datei muss eben eingelesen werden. Das hat mit dem anderen KNX-Adapter sogar leidlich geklappt, Gott sei Dank. Nur ein bisschen Handarbeit (auch noch beim Read und Write). Schalten und Status- Zuordnung hat dort aber gut geklappt.

      Hingegen klappt beim Einlesen mit deinem Adapter (über XML) gar nichts (bin also froh, dass ich den anderen Weg gegangen bin). Die Fehlermeldung hat auch nichts zu tun mit den fehlenden DPTs, sondern das Einlesen scheitert bei deinem Adapter durchgängig am Zuordnen der Schaltadressen zu den Statusadressen. Im Endergebnis werden genau 0 Objekte erzeugt.

      Wie gesagt, ich werde trotzdem deinen Adapter verwenden, er funktioniert ansonsten gut und ich halte ihn schon jetzt für die besere Alternative. Aber das Paaren von Schalten mit Status klappt nicht, Ergebnis war Null Objekte.

      Mein Rat an alle: Jeder, der neu anfängt, sollte natürlich den XML-Weg gehen. Jeder, der ein gut funktionierendes System hat und Angst hat, hier zu verschlimmbessern, sollte aber durchaus mal vergleichen, ob er mit dem iobroker-json Export der Objekte (und Import nach openknx nach vorherigem suchen-und-ersetzen der entsprechenden Einträge von "KNX" durch "openknx") nicht besser fährt.

      freundliche Grüße
      Thomas

      K T 2 Antworten Letzte Antwort
      0
      • T tdoc

        @killroy2 said in Test Adapter OpenKNX 0.1.x:

        @tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

        Hm, verstehe deine Antwort nicht ganz. "DAS" darf nicht funktionieren? Was darf nicht funktionieren?
        Natürlich funktioniert es prima, wenn ich manuell einen DPT 9.004 in das iobroker-Objekt eingebe. Jetzt weiß der Adapter ja, wie die 2 Byte zu interpretieren sind. Und alle Warnungen sind weg und ich bin glücklich und zufrieden. Hab die Wetterdaten halt früher nie verwendet und deshalb nie gesehen, dass im ioBroker Objekt nur Unsinn steht. Dank deiner Warnungen ist mir jetzt der Fehler aufgefallen.

        Noch ein paar Hintergrundinformationen: natürlich sind heute DPTs in KNX vorgeschrieben. Unsere Installation stammt aber noch aus EIB-Zeiten. D.h. es gab allenfalls EIS (EIS = EIB Interworking Standard), Vorläufer und ähnlich den DPTs von heute. Unser zertifizierter Elektriker hat jedenfalls entweder nie EIS benutzt (war damals explizit zulässig, damals wie heute wird bei fehlendem Datentyp lt. KNX ein definierter Standardwert für die gegebene Länge gesetzt)) und nur mit Länge gearbeitet, oder aber die Konvertierung (von EIS in DPTs) ist an dieser Stelle schiefgelaufen. Kann ich heute nicht mehr nachvollziehen. Die damalige Installation im Haus funktioniert natürlich, und die heute mir vorliegende ETS5 Datei muss eben eingelesen werden. Das hat mit dem anderen KNX-Adapter sogar leidlich geklappt, Gott sei Dank. Nur ein bisschen Handarbeit (auch noch beim Read und Write). Schalten und Status- Zuordnung hat dort aber gut geklappt.

        Hingegen klappt beim Einlesen mit deinem Adapter (über XML) gar nichts (bin also froh, dass ich den anderen Weg gegangen bin). Die Fehlermeldung hat auch nichts zu tun mit den fehlenden DPTs, sondern das Einlesen scheitert bei deinem Adapter durchgängig am Zuordnen der Schaltadressen zu den Statusadressen. Im Endergebnis werden genau 0 Objekte erzeugt.

        Wie gesagt, ich werde trotzdem deinen Adapter verwenden, er funktioniert ansonsten gut und ich halte ihn schon jetzt für die besere Alternative. Aber das Paaren von Schalten mit Status klappt nicht, Ergebnis war Null Objekte.

        Mein Rat an alle: Jeder, der neu anfängt, sollte natürlich den XML-Weg gehen. Jeder, der ein gut funktionierendes System hat und Angst hat, hier zu verschlimmbessern, sollte aber durchaus mal vergleichen, ob er mit dem iobroker-json Export der Objekte (und Import nach openknx nach vorherigem suchen-und-ersetzen der entsprechenden Einträge von "KNX" durch "openknx") nicht besser fährt.

        freundliche Grüße
        Thomas

        K Offline
        K Offline
        killroy2
        schrieb am zuletzt editiert von
        #114

        @tdoc Ich meinte es ist gut dass der Adapter die unterdefinierten GAs bemängelt.
        Was funktioniert denn beim Einlesen der XML nicht?
        Die Zuordnung zu Status GA wertet der Adapter nicht anhand der alten Konfiguration aus. Das geht jetzt seit v0.1.11 über Alias. Wenn du das meinst mit es werden 0 Objekte erzeugt dann kann das an deiner Benamung liegen und der nicht passend eingestellten Filterregel

        1 Antwort Letzte Antwort
        1
        • T tdoc

          @killroy2 said in Test Adapter OpenKNX 0.1.x:

          @tdoc Das darf nicht funktionieren, dem Adapter fehlen relevante Informationen wie die 2 Byte zu interpretieren sind. Du bekommst aber eine präsente Fehlermeldung.

          Hm, verstehe deine Antwort nicht ganz. "DAS" darf nicht funktionieren? Was darf nicht funktionieren?
          Natürlich funktioniert es prima, wenn ich manuell einen DPT 9.004 in das iobroker-Objekt eingebe. Jetzt weiß der Adapter ja, wie die 2 Byte zu interpretieren sind. Und alle Warnungen sind weg und ich bin glücklich und zufrieden. Hab die Wetterdaten halt früher nie verwendet und deshalb nie gesehen, dass im ioBroker Objekt nur Unsinn steht. Dank deiner Warnungen ist mir jetzt der Fehler aufgefallen.

          Noch ein paar Hintergrundinformationen: natürlich sind heute DPTs in KNX vorgeschrieben. Unsere Installation stammt aber noch aus EIB-Zeiten. D.h. es gab allenfalls EIS (EIS = EIB Interworking Standard), Vorläufer und ähnlich den DPTs von heute. Unser zertifizierter Elektriker hat jedenfalls entweder nie EIS benutzt (war damals explizit zulässig, damals wie heute wird bei fehlendem Datentyp lt. KNX ein definierter Standardwert für die gegebene Länge gesetzt)) und nur mit Länge gearbeitet, oder aber die Konvertierung (von EIS in DPTs) ist an dieser Stelle schiefgelaufen. Kann ich heute nicht mehr nachvollziehen. Die damalige Installation im Haus funktioniert natürlich, und die heute mir vorliegende ETS5 Datei muss eben eingelesen werden. Das hat mit dem anderen KNX-Adapter sogar leidlich geklappt, Gott sei Dank. Nur ein bisschen Handarbeit (auch noch beim Read und Write). Schalten und Status- Zuordnung hat dort aber gut geklappt.

          Hingegen klappt beim Einlesen mit deinem Adapter (über XML) gar nichts (bin also froh, dass ich den anderen Weg gegangen bin). Die Fehlermeldung hat auch nichts zu tun mit den fehlenden DPTs, sondern das Einlesen scheitert bei deinem Adapter durchgängig am Zuordnen der Schaltadressen zu den Statusadressen. Im Endergebnis werden genau 0 Objekte erzeugt.

          Wie gesagt, ich werde trotzdem deinen Adapter verwenden, er funktioniert ansonsten gut und ich halte ihn schon jetzt für die besere Alternative. Aber das Paaren von Schalten mit Status klappt nicht, Ergebnis war Null Objekte.

          Mein Rat an alle: Jeder, der neu anfängt, sollte natürlich den XML-Weg gehen. Jeder, der ein gut funktionierendes System hat und Angst hat, hier zu verschlimmbessern, sollte aber durchaus mal vergleichen, ob er mit dem iobroker-json Export der Objekte (und Import nach openknx nach vorherigem suchen-und-ersetzen der entsprechenden Einträge von "KNX" durch "openknx") nicht besser fährt.

          freundliche Grüße
          Thomas

          T Offline
          T Offline
          tombox
          schrieb am zuletzt editiert von
          #115

          @tdoc
          kannst du mir mal die XML schicken. Vielleicht können wir das problem beheben
          tombox2020@gmail.com

          T M 2 Antworten Letzte Antwort
          0
          • W Offline
            W Offline
            wizard2010
            schrieb am zuletzt editiert von
            #116

            Hi,

            I'm getting this error when importing:

            Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER because no DPT is assigned to 1339. The GA is not connected to a KO in ETS
            Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER_REACHED because no DPT is assigned to 1340. The GA is not connected to a KO in ETS
            Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_LOWER_HYSTERESIS because no DPT is assigned to 1342. The GA is not connected to a KO in ETS
            Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_UPPER_HYSTERESIS because no DPT is assigned to 1343. The GA is not connected to a KO in ETS
            Ignoring Corredor.Aquecimento.PRE_COR_OVERHEAT_TEMP because no DPT is assigned to 1344. The GA is not connected to a KO in ETS
            Ignoring Corredor.Aquecimento.PRE_COR_AVG_TEMP because no DPT is assigned to 1345. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Luzes.IN_COZ_LUZES_FAIL_STATUS because no DPT is assigned to 2054. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF because no DPT is assigned to 2361. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF_STATUS because no DPT is assigned to 2364. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER because no DPT is assigned to 2365. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER_REACHED because no DPT is assigned to 2366. The GA is not connected to a KO in ETS
            Ignoring Cozinha.Aquecimento.PRE_COZ_RIGHT_TEMP because no DPT is assigned to 2367. The GA is not connected to a KO in ETS
            

            Any idea what is wrong here?

            Thanks

            T 1 Antwort Letzte Antwort
            0
            • W wizard2010

              Hi,

              I'm getting this error when importing:

              Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER because no DPT is assigned to 1339. The GA is not connected to a KO in ETS
              Ignoring Corredor.Aquecimento.PRE_COR_SWITCH_COUNTER_REACHED because no DPT is assigned to 1340. The GA is not connected to a KO in ETS
              Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_LOWER_HYSTERESIS because no DPT is assigned to 1342. The GA is not connected to a KO in ETS
              Ignoring Corredor.Aquecimento.PRE_COR_SET_POINT_UPPER_HYSTERESIS because no DPT is assigned to 1343. The GA is not connected to a KO in ETS
              Ignoring Corredor.Aquecimento.PRE_COR_OVERHEAT_TEMP because no DPT is assigned to 1344. The GA is not connected to a KO in ETS
              Ignoring Corredor.Aquecimento.PRE_COR_AVG_TEMP because no DPT is assigned to 1345. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Luzes.IN_COZ_LUZES_FAIL_STATUS because no DPT is assigned to 2054. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF because no DPT is assigned to 2361. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Aquecimento.PRE_COZ_ON_OFF_STATUS because no DPT is assigned to 2364. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER because no DPT is assigned to 2365. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Aquecimento.PRE_COZ_SWITCH_COUNTER_REACHED because no DPT is assigned to 2366. The GA is not connected to a KO in ETS
              Ignoring Cozinha.Aquecimento.PRE_COZ_RIGHT_TEMP because no DPT is assigned to 2367. The GA is not connected to a KO in ETS
              

              Any idea what is wrong here?

              Thanks

              T Offline
              T Offline
              tombox
              schrieb am zuletzt editiert von
              #117

              @wizard2010 This is not an error only a information that this GA is not used in ETS

              W 1 Antwort Letzte Antwort
              0
              • T tombox

                @wizard2010 This is not an error only a information that this GA is not used in ETS

                W Offline
                W Offline
                wizard2010
                schrieb am zuletzt editiert von
                #118

                @tombox Thanks your are right 😉

                I'm also getting this warning...

                OpenKNX.png

                There is any way to see which datapoints? I'm using free datapoints instead of x/x/x.

                T 1 Antwort Letzte Antwort
                0
                • W wizard2010

                  @tombox Thanks your are right 😉

                  I'm also getting this warning...

                  OpenKNX.png

                  There is any way to see which datapoints? I'm using free datapoints instead of x/x/x.

                  T Offline
                  T Offline
                  tombox
                  schrieb am zuletzt editiert von
                  #119

                  @wizard2010 The adapter receive information on the bus for this address but it is not in the xml file. The Adapter cannot say the name of the datapoint

                  W 1 Antwort Letzte Antwort
                  0
                  • T tombox

                    @wizard2010 The adapter receive information on the bus for this address but it is not in the xml file. The Adapter cannot say the name of the datapoint

                    W Offline
                    W Offline
                    wizard2010
                    schrieb am zuletzt editiert von
                    #120

                    @tombox Maybe this datapoints are the ones that were not imported from the xml file due to that ignore error.

                    Do you know if it's possible to convert this "3/6/254" in openKNX in order to allow me to check if the number matches with the ones in XML file?

                    1 Antwort Letzte Antwort
                    0
                    • C Offline
                      C Offline
                      ChrisChros
                      schrieb am zuletzt editiert von
                      #121

                      Hallo,
                      ich bekomme folgende Fehlemeldung bei mir im Log angezeigt:

                      2021-12-29 12:07:47.280 - error: openknx.0 (10336) [error] "2021-12-29T11:07:47.279Z" 'DPT14: Must supply a number value'
                      

                      Leider kann ich die Meldung keiner speziellen GA zuordnen da ich mehrere mit DPT14 habe. Besteht die Möglichkeit das weiter einzugrenzen?

                      T K 2 Antworten Letzte Antwort
                      0
                      • C ChrisChros

                        Hallo,
                        ich bekomme folgende Fehlemeldung bei mir im Log angezeigt:

                        2021-12-29 12:07:47.280 - error: openknx.0 (10336) [error] "2021-12-29T11:07:47.279Z" 'DPT14: Must supply a number value'
                        

                        Leider kann ich die Meldung keiner speziellen GA zuordnen da ich mehrere mit DPT14 habe. Besteht die Möglichkeit das weiter einzugrenzen?

                        T Offline
                        T Offline
                        tombox
                        schrieb am zuletzt editiert von tombox
                        #122

                        @chrischros Du könntest den Adapter in Log Level Debug setzen. Einfach in Instanzen im Experten modus von info auf debug setzen. Ruhig dann auch hier posten vielleicht können wir die log information verbessern

                        C 2 Antworten Letzte Antwort
                        0
                        • T tombox

                          @chrischros Du könntest den Adapter in Log Level Debug setzen. Einfach in Instanzen im Experten modus von info auf debug setzen. Ruhig dann auch hier posten vielleicht können wir die log information verbessern

                          C Offline
                          C Offline
                          ChrisChros
                          schrieb am zuletzt editiert von
                          #123

                          @tombox
                          Danke für den Tipp, werde ich nachher oder heute Abend mal testen.

                          noch eine weitere Meldung die mir aufgefallen ist:

                          State value to set for "openknx.0.Dimmen.Dimmen.Außen_-_Terrasse_-_Spots_-_Dimmen" has to be stringified but received type "object"
                          

                          Die GA ist als DPT 3.007 Dimmer schritte in der ETS parametriert und in ioBroker sieht das Objekt wie folgt aus:

                          {
                            "_id": "openknx.0.Dimmen.Dimmen.Außen_-_Terrasse_-_Spots_-_Dimmen",
                            "type": "state",
                            "common": {
                              "desc": "Basetype: 4-bit relative dimming control",
                              "name": "Außen - Terrasse - Spots - Dimmen",
                              "read": true,
                              "role": "state",
                              "type": "object",
                              "write": true
                            },
                            "native": {
                              "address": "2/3/13",
                              "answer_groupValueResponse": false,
                              "autoread": true,
                              "bitlength": 4,
                              "dpt": "DPT3.007",
                              "valuetype": "composite"
                            },
                            "from": "system.adapter.openknx.0",
                            "user": "system.user.admin",
                            "ts": 1640778698317,
                            "acl": {
                              "object": 1636,
                              "state": 1636,
                              "owner": "system.user.admin",
                              "ownerGroup": "system.group.administrator"
                            }
                          }
                          

                          aktuell kann ich da keinen wirklichen fehler entdecken, so sind bei mir alle GAs parametriert die mit Dimmen zu tun haben.
                          Hat jemand ne Idee?

                          K 1 Antwort Letzte Antwort
                          0
                          • T tombox

                            @chrischros Du könntest den Adapter in Log Level Debug setzen. Einfach in Instanzen im Experten modus von info auf debug setzen. Ruhig dann auch hier posten vielleicht können wir die log information verbessern

                            C Offline
                            C Offline
                            ChrisChros
                            schrieb am zuletzt editiert von
                            #124

                            @tombox
                            Hier mal der Auszug aus dem Log von der Sekunde in der die Fehlermeldung kam:

                            2021-12-29 13:50:35.027  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.026 Inbound message: 0610042000150453ab002900bce011fe2450010080
                            2021-12-29 13:50:35.028  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.028 (idle):	 zzzz...
                            2021-12-29 13:50:35.029  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/80 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Heizung_Zündung
                            2021-12-29 13:50:35.114  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.113 Inbound message: 0610042000150453ac002900bce011fe2451010080
                            2021-12-29 13:50:35.115  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.115 (idle):	 zzzz...
                            2021-12-29 13:50:35.116  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/81 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Gebläse_Zündung
                            2021-12-29 13:50:35.219  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.218 Inbound message: 0610042000150453ad002900bce011fe2452010080
                            2021-12-29 13:50:35.220  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.219 (idle):	 zzzz...
                            2021-12-29 13:50:35.220  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/82 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Aschenaustragung_aktiv
                            2021-12-29 13:50:35.356  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.356 Inbound message: 0610042000150453ae002900bce011fe2453010080
                            2021-12-29 13:50:35.358  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.357 (idle):	 zzzz...
                            2021-12-29 13:50:35.358  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/83 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Richtung_Aschenaustragung
                            2021-12-29 13:50:35.429  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/0 value 471 from openknx.0.Heizung.Photovoltaik.Photovoltaik-Leistung
                            2021-12-29 13:50:35.431  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.431 (sendDatagram):	>>>>>>> successfully sent seqnum: 1349
                            2021-12-29 13:50:35.431  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.431 Inbound message: 06100421000a04534500
                            2021-12-29 13:50:35.432  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.432 ===== datagram 69 acknowledged by IP router
                            2021-12-29 13:50:35.432  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.432 (idle):	 zzzz...
                            2021-12-29 13:50:35.433  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/1 value 0 from openknx.0.Heizung.Photovoltaik.Batterie-Leistung
                            2021-12-29 13:50:35.434  - error: openknx.0 (11241) [error] "2021-12-29T12:50:35.434Z"  'DPT14: Must supply a number value'
                            2021-12-29 13:50:35.435  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/2 value 464 from openknx.0.Heizung.Photovoltaik.Hausverbrauchs-Leistung
                            2021-12-29 13:50:35.436  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/3 value -7 from openknx.0.Heizung.Photovoltaik.Leistung_am_Netzübergabepunkt
                            2021-12-29 13:50:35.437  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/18 value 402 from openknx.0.Heizung.Photovoltaik.DC-Spannung_an_String_1
                            2021-12-29 13:50:35.438  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/19 value 410 from openknx.0.Heizung.Photovoltaik.DC-Spannung_an_String_2
                            2021-12-29 13:50:35.439  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.439 Inbound message: 0610042000150453af002900bce011fe2454010080
                            2021-12-29 13:50:35.440  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.440 (idle):	 zzzz...
                            2021-12-29 13:50:35.440  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/84 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Einschubschnecke_aktiv
                            2021-12-29 13:50:35.466  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/22 value 237 from openknx.0.Heizung.Photovoltaik.DC-Leistung_an_String_1
                            2021-12-29 13:50:35.468  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/23 value 234 from openknx.0.Heizung.Photovoltaik.DC-Leistung_an_String_2
                            2021-12-29 13:50:35.480  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.480 (sendDatagram):	>>>>>>> successfully sent seqnum: 1350
                            2021-12-29 13:50:35.482  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.482 Inbound message: 06100421000a04534600
                            2021-12-29 13:50:35.482  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.482 ===== datagram 70 acknowledged by IP router
                            2021-12-29 13:50:35.483  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.483 (idle):	 zzzz...
                            2021-12-29 13:50:35.530  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.530 Inbound message: 0610042000150453b0002900bce011fe2455010080
                            2021-12-29 13:50:35.531  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.531 (idle):	 zzzz...
                            2021-12-29 13:50:35.531  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/85 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Richtung_Einschubschnecke
                            2021-12-29 13:50:35.533  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.533 (sendDatagram):	>>>>>>> successfully sent seqnum: 1351
                            2021-12-29 13:50:35.534  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.534 Inbound message: 06100421000a04534700
                            2021-12-29 13:50:35.535  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.535 ===== datagram 71 acknowledged by IP router
                            2021-12-29 13:50:35.535  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.535 (idle):	 zzzz...
                            2021-12-29 13:50:35.583  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.583 (sendDatagram):	>>>>>>> successfully sent seqnum: 1352
                            2021-12-29 13:50:35.584  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.584 Inbound message: 06100421000a04534800
                            2021-12-29 13:50:35.585  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.585 ===== datagram 72 acknowledged by IP router
                            2021-12-29 13:50:35.585  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.585 (idle):	 zzzz...
                            2021-12-29 13:50:35.599  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.599 Inbound message: 0610042000150453b1002900bce011fe2456010080
                            2021-12-29 13:50:35.600  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.600 (idle):	 zzzz...
                            2021-12-29 13:50:35.600  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/86 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Raumaustragung_Sauger_aktiv
                            2021-12-29 13:50:35.634  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.634 (sendDatagram):	>>>>>>> successfully sent seqnum: 1353
                            2021-12-29 13:50:35.635  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.635 Inbound message: 06100421000a04534900
                            2021-12-29 13:50:35.635  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.635 ===== datagram 73 acknowledged by IP router
                            2021-12-29 13:50:35.636  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.636 (idle):	 zzzz...
                            2021-12-29 13:50:35.685  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.685 (sendDatagram):	>>>>>>> successfully sent seqnum: 1354
                            2021-12-29 13:50:35.686  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.686 Inbound message: 06100421000a04534a00
                            2021-12-29 13:50:35.687  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.686 ===== datagram 74 acknowledged by IP router
                            2021-12-29 13:50:35.687  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.687 (idle):	 zzzz...
                            2021-12-29 13:50:35.698  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.698 Inbound message: 0610042000150453b2002900bce011fe2457010080
                            2021-12-29 13:50:35.699  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.699 (idle):	 zzzz...
                            2021-12-29 13:50:35.699  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/87 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Raumaustragung_aktiv
                            2021-12-29 13:50:35.736  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.736 (sendDatagram):	>>>>>>> successfully sent seqnum: 1355
                            2021-12-29 13:50:35.737  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.737 Inbound message: 06100421000a04534b00
                            2021-12-29 13:50:35.737  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.737 ===== datagram 75 acknowledged by IP router
                            2021-12-29 13:50:35.737  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.737 (idle):	 zzzz...
                            2021-12-29 13:50:35.785  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.785 Inbound message: 0610042000150453b3002900bce011fe2458010080
                            2021-12-29 13:50:35.786  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.786 (idle):	 zzzz...
                            2021-12-29 13:50:35.786  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/88 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Richtung_Raumaustragung
                            2021-12-29 13:50:35.788  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.788 (sendDatagram):	>>>>>>> successfully sent seqnum: 1356
                            2021-12-29 13:50:35.789  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.788 Inbound message: 06100421000a04534c00
                            2021-12-29 13:50:35.789  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.789 ===== datagram 76 acknowledged by IP router
                            2021-12-29 13:50:35.790  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.790 (idle):	 zzzz...
                            2021-12-29 13:50:35.848  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.848 Inbound message: 0610042000150453b4002900bce011fe245a010080
                            2021-12-29 13:50:35.849  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.849 (idle):	 zzzz...
                            2021-12-29 13:50:35.850  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/90 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Reinigung_aktiv
                            2021-12-29 13:50:35.947  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.947 Inbound message: 0610042000150453b5002900bce011fe245b010080
                            2021-12-29 13:50:35.949  - debug: openknx.0 (11241) [debug] 2021-12-29 12:50:35.949 (idle):	 zzzz...
                            2021-12-29 13:50:35.949  - debug: openknx.0 (11241) Inbound GroupValue_Write 4/4/91 val: false  dpt: DPT1 to Object: openknx.0.Heizung.Hargassner_Nano_PK.Mischer_Rücklauf_Auf
                            

                            Die Fehlermeldung lautet "DPT14: Must supply a number value" und wurde um 13:50:35.434 Uhr aufgezeichnet. Die Meldung vor der Fehler lautete wie folgt:

                            2021-12-29 13:50:35.433  - debug: openknx.0 (11241) Outbound GroupValue_Write to 4/6/1 value 0 from openknx.0.Heizung.Photovoltaik.Batterie-Leistung
                            

                            Das Objekt Batterie-Leistung wird per Modbus ausgelesen und per blockly auf den Bus gesendet.
                            Die Objektdaten von dem Modbus-Objekt lauten wie folgt:

                            {
                              "_id": "modbus.0.holdingRegisters.40070_Batterie_Leistung",
                              "type": "state",
                              "common": {
                                "name": "Batterie-Leistung in Watt",
                                "role": "value",
                                "type": "number",
                                "read": true,
                                "write": true,
                                "def": 0,
                                "unit": "W",
                                "custom": {
                                  "mqtt-client.0": {
                                    "enabled": true,
                                    "publish": true,
                                    "pubChangesOnly": false,
                                    "pubAsObject": false,
                                    "qos": false,
                                    "retain": false,
                                    "subscribe": false,
                                    "subChangesOnly": false,
                                    "subAsObject": false,
                                    "subQos": false,
                                    "setAck": false
                                  },
                                  "influxdb.0": {
                                    "enabled": true,
                                    "storageType": "",
                                    "aliasId": "",
                                    "changesOnly": true,
                                    "debounce": 1000,
                                    "changesRelogInterval": 60,
                                    "changesMinDelta": 0
                                  }
                                }
                              },
                              "native": {
                                "regType": "holdingRegs",
                                "address": 69,
                                "deviceId": 1,
                                "type": "int32sw",
                                "len": 2,
                                "offset": 0,
                                "factor": 1,
                                "poll": true
                              },
                              "acl": {
                                "object": 1636,
                                "state": 1636,
                                "file": 1636,
                                "owner": "system.user.admin",
                                "ownerGroup": "system.group.administrator"
                              },
                              "from": "system.adapter.modbus.0",
                              "user": "system.user.admin",
                              "ts": 1640759338188
                            }
                            

                            Die Objekt-Daten von dem KNX-Objekt sehen wie folgt aus:

                            {
                              "_id": "openknx.0.Heizung.Photovoltaik.Batterie-Leistung",
                              "type": "state",
                              "common": {
                                "desc": "Basetype: 32-bit floating point value",
                                "name": "Batterie-Leistung",
                                "read": true,
                                "role": "state",
                                "type": "number",
                                "unit": "W",
                                "write": true
                              },
                              "native": {
                                "address": "4/6/1",
                                "answer_groupValueResponse": false,
                                "autoread": true,
                                "bitlength": 32,
                                "dpt": "DPT14.056",
                                "valuetype": "basic"
                              },
                              "from": "system.adapter.openknx.0",
                              "user": "system.user.admin",
                              "ts": 1640778701203,
                              "acl": {
                                "object": 1636,
                                "state": 1636,
                                "owner": "system.user.admin",
                                "ownerGroup": "system.group.administrator"
                              }
                            }
                            

                            Wie sollte ich eurer Meinung nach der DPT für KNX Objekt aussehen?

                            1 Antwort Letzte Antwort
                            0
                            • T tombox

                              @tdoc
                              kannst du mir mal die XML schicken. Vielleicht können wir das problem beheben
                              tombox2020@gmail.com

                              T Offline
                              T Offline
                              tdoc
                              schrieb am zuletzt editiert von
                              #125

                              @tombox
                              Hat sich erledigt. Es kann nichts importiert werden, weil keine DPT definiert sind. Hab für dieses Problem ja eine Lösung gefunden (verwende die bisher erzeugten Objekte weiter). Ansonsten hätte ich mir halt die Arbeit machen müssen und extra für den Import die DPTs definieren müssen. Mach ich vielleicht auch mal. Wie gesagt, das war die Arbeit einer zertifizierten Elektrikerfirma, vor 22 Jahren.

                              Hier gab es mit dem anderen Adapter keine Probleme. Auch die ETS 5 meckert bei einem Prüflauf zwar einiges an, aber nicht die fehlenden DPTs.

                              1 Antwort Letzte Antwort
                              0
                              • C ChrisChros

                                Hallo,
                                ich bekomme folgende Fehlemeldung bei mir im Log angezeigt:

                                2021-12-29 12:07:47.280 - error: openknx.0 (10336) [error] "2021-12-29T11:07:47.279Z" 'DPT14: Must supply a number value'
                                

                                Leider kann ich die Meldung keiner speziellen GA zuordnen da ich mehrere mit DPT14 habe. Besteht die Möglichkeit das weiter einzugrenzen?

                                K Offline
                                K Offline
                                killroy2
                                schrieb am zuletzt editiert von killroy2
                                #126

                                @chrischros said in Test Adapter OpenKNX 0.1.x:

                                Leider kann ich die Meldung keiner speziellen GA zuordnen da ich mehrere mit DPT14 habe. Besteht die Möglichkeit das weiter einzugrenzen?

                                wie schreibst du den Wert mit blockly ? Es muss vom Typ number sein.

                                C 1 Antwort Letzte Antwort
                                1
                                • C ChrisChros

                                  @tombox
                                  Danke für den Tipp, werde ich nachher oder heute Abend mal testen.

                                  noch eine weitere Meldung die mir aufgefallen ist:

                                  State value to set for "openknx.0.Dimmen.Dimmen.Außen_-_Terrasse_-_Spots_-_Dimmen" has to be stringified but received type "object"
                                  

                                  Die GA ist als DPT 3.007 Dimmer schritte in der ETS parametriert und in ioBroker sieht das Objekt wie folgt aus:

                                  {
                                    "_id": "openknx.0.Dimmen.Dimmen.Außen_-_Terrasse_-_Spots_-_Dimmen",
                                    "type": "state",
                                    "common": {
                                      "desc": "Basetype: 4-bit relative dimming control",
                                      "name": "Außen - Terrasse - Spots - Dimmen",
                                      "read": true,
                                      "role": "state",
                                      "type": "object",
                                      "write": true
                                    },
                                    "native": {
                                      "address": "2/3/13",
                                      "answer_groupValueResponse": false,
                                      "autoread": true,
                                      "bitlength": 4,
                                      "dpt": "DPT3.007",
                                      "valuetype": "composite"
                                    },
                                    "from": "system.adapter.openknx.0",
                                    "user": "system.user.admin",
                                    "ts": 1640778698317,
                                    "acl": {
                                      "object": 1636,
                                      "state": 1636,
                                      "owner": "system.user.admin",
                                      "ownerGroup": "system.group.administrator"
                                    }
                                  }
                                  

                                  aktuell kann ich da keinen wirklichen fehler entdecken, so sind bei mir alle GAs parametriert die mit Dimmen zu tun haben.
                                  Hat jemand ne Idee?

                                  K Offline
                                  K Offline
                                  killroy2
                                  schrieb am zuletzt editiert von
                                  #127

                                  @chrischros said in Test Adapter OpenKNX 0.1.x:

                                  State value to set for "openknx.0.Dimmen.Dimmen.Außen_-Terrasse-Spots-_Dimmen" has to be stringified but received type "object"

                                  Das ist noch ein Problem vom Adapter, führt aber zu keiner Funktionsbeeinträchtigung.

                                  1 Antwort Letzte Antwort
                                  1
                                  • M Online
                                    M Online
                                    mane444
                                    schrieb am zuletzt editiert von
                                    #128

                                    @killroy2 sagte in Test Adapter OpenKNX 0.1.x:

                                    Die Zuordnung zu Status GA wertet der Adapter nicht anhand der alten Konfiguration aus. Das geht jetzt seit v0.1.11 über Alias

                                    Die Zuordnung der Status GA über Alias finde ich eine super Lösung. Ich hab das gleich mal getestet, leider findet die momentane Testversion nur 14 von meinen Status GA. Wenn dir das was bei der Entwicklung hilft kann ich dir gerne meine XML schicken.

                                    K 1 Antwort Letzte Antwort
                                    0
                                    • M mane444

                                      @killroy2 sagte in Test Adapter OpenKNX 0.1.x:

                                      Die Zuordnung zu Status GA wertet der Adapter nicht anhand der alten Konfiguration aus. Das geht jetzt seit v0.1.11 über Alias

                                      Die Zuordnung der Status GA über Alias finde ich eine super Lösung. Ich hab das gleich mal getestet, leider findet die momentane Testversion nur 14 von meinen Status GA. Wenn dir das was bei der Entwicklung hilft kann ich dir gerne meine XML schicken.

                                      K Offline
                                      K Offline
                                      killroy2
                                      schrieb am zuletzt editiert von
                                      #129

                                      @mane444 ja schick mal zu, wenn du es veröffentlichen kannst dann irgendwo hier einfügen: https://github.com/iobroker-community-adapters/ioBroker.openknx/issues

                                      1 Antwort Letzte Antwort
                                      1
                                      • T Offline
                                        T Offline
                                        tiego
                                        schrieb am zuletzt editiert von
                                        #130

                                        Hallo,

                                        hatt zufällig jemand eine Lösung gefunden für mein Problem mit

                                        State value to set for "openknx.0.OG.Licht.OG_-_Licht_O5_Zimmer_Eltern_O5_2_Decke_-_dimm" has to be stringified but received type "object"
                                        

                                        danke

                                        C 1 Antwort Letzte Antwort
                                        0
                                        • T tiego

                                          Hallo,

                                          hatt zufällig jemand eine Lösung gefunden für mein Problem mit

                                          State value to set for "openknx.0.OG.Licht.OG_-_Licht_O5_Zimmer_Eltern_O5_2_Decke_-_dimm" has to be stringified but received type "object"
                                          

                                          danke

                                          C Offline
                                          C Offline
                                          ChrisChros
                                          schrieb am zuletzt editiert von
                                          #131

                                          @tiego
                                          Das ist das gleich Problem wie bei mir weiter oben und von @killroy2 bereits beantwortet.

                                          @killroy2 said in Test Adapter OpenKNX 0.1.x:

                                          @chrischros said in Test Adapter OpenKNX 0.1.x:

                                          State value to set for "openknx.0.Dimmen.Dimmen.Außen_-Terrasse-Spots-_Dimmen" has to be stringified but received type "object"

                                          Das ist noch ein Problem vom Adapter, führt aber zu keiner Funktionsbeeinträchtigung.

                                          Ist noch ein Problem im Adapter, nichts schlimmes.

                                          1 Antwort Letzte Antwort
                                          0
                                          Antworten
                                          • In einem neuen Thema antworten
                                          Anmelden zum Antworten
                                          • Älteste zuerst
                                          • Neuste zuerst
                                          • Meiste Stimmen


                                          Support us

                                          ioBroker
                                          Community Adapters
                                          Donate

                                          557

                                          Online

                                          32.4k

                                          Benutzer

                                          81.4k

                                          Themen

                                          1.3m

                                          Beiträge
                                          Community
                                          Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                                          ioBroker Community 2014-2025
                                          logo
                                          • Anmelden

                                          • Du hast noch kein Konto? Registrieren

                                          • Anmelden oder registrieren, um zu suchen
                                          • Erster Beitrag
                                            Letzter Beitrag
                                          0
                                          • Aktuell
                                          • Tags
                                          • Ungelesen 0
                                          • Kategorien
                                          • Unreplied
                                          • Beliebt
                                          • GitHub
                                          • Docu
                                          • Hilfe