KNX Adapter überholt
-
Vielen Dank für die Ratschläge,
letztlich habe die den Adapter deinstalliert und die "stabile" Version installiert. Zuvor hatte die Automatik mit die aktuelle Version vorgeschlagen, die ich auch gerne genommen habe. Mit der "alten" Version kann ich alle Angaben machen, Die GA werden importiert. Nun werde ich mich als Nächstes darum kümmern, wie es damit weitergeht in Richtung Visu. Da kommen bestimmt noch Fragen auf Euch zu.
Gruß Matthias -
Hallo,
ich habe eben den KNX Adapter 1.0.20 installiert.Ich nutzte die ETS 5.7.1 und habe auch daher den KNXPROJ Datei exportiert.
Beim einlesen der Datei in den Adapter bekomme ich folgenden Fehler:
knx.0 2019-04-26 19:29:00.852 error at Socket.<anonymous> (/opt/iobroker/node_modules/redis/index.js:274:27) knx.0 2019-04-26 19:29:00.852 error at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:553:10) knx.0 2019-04-26 19:29:00.852 error at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18) knx.0 2019-04-26 19:29:00.852 error at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:833:9) knx.0 2019-04-26 19:29:00.852 error at return_pub_sub (/opt/iobroker/node_modules/redis/index.js:794:18) knx.0 2019-04-26 19:29:00.852 error at RedisClient.emit (events.js:189:13) knx.0 2019-04-26 19:29:00.852 error at RedisClient.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:605:25) knx.0 2019-04-26 19:29:00.852 error at change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:3680:34) knx.0 2019-04-26 19:29:00.852 error at Adapter.emit (events.js:189:13) knx.0 2019-04-26 19:29:00.852 error at Adapter.<anonymous> (/opt/iobroker/node_modules/iobroker.knx/knx.js:79:5730) knx.0 2019-04-26 19:29:00.852 error TypeError: Cannot read property 'replace' of undefinedIch weiss das auf umstieg zur 5.7 der Export von ETS seiten geändert worden ist.
Kann es sein das es hier dran liegt?
Danke und Liebe Grüße
-
Hi,
ist die Farbtemperatur mit Datenpunkt 7.600 mittlerweile unterstützt? Es gibt dazu ein github issue, in dem steht, dass es in der nächsten Version unterstützt würde. Es ist auch schon lange geschlossen. Leider ist das schon länger her, es gab mehrere neue Versionen und bei mir geht es immer noch nicht. Im Moment kommt folgendes im Log (knx adapter version 1.0.20):
knx.0 2019-04-28 10:53:57.830 error at Socket.onpacket (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:228:12) knx.0 2019-04-28 10:53:57.830 error at Socket.onevent (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/lib/socket.js:270:10) knx.0 2019-04-28 10:53:57.830 error at Socket.Emitter.emit (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20) knx.0 2019-04-28 10:53:57.830 error at Socket.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInMemClient.js:52:30) knx.0 2019-04-28 10:53:57.830 error at Object.change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:3705:37) knx.0 2019-04-28 10:53:57.830 error at Object.stateChange (/opt/iobroker/node_modules/iobroker.knx/knx.js:79:2726) knx.0 2019-04-28 10:53:57.830 error at _0x336508.write (/opt/iobroker/node_modules/iobroker.knx/knx.js:43:798) knx.0 2019-04-28 10:53:57.830 error at _0x4ad005.(anonymous function) [as groupValueWrite] (/opt/iobroker/node_modules/iobroker.knx/knx.js:17:49991) knx.0 2019-04-28 10:53:57.830 error at Object._0x331276.(anonymous function) [as valueBitLength] (/opt/iobroker/node_modules/iobroker.knx/knx.js:31:25481) knx.0 2019-04-28 10:53:57.830 error at _0x5868fb (/opt/iobroker/node_modules/iobroker.knx/knx.js:31:19803) knx.0 2019-04-28 10:53:57.830 error TypeError: Cannot read property 'hasOwnProperty' of null knx.0 2019-04-28 10:53:57.827 error message knx.0.Beleuchtung.Farbe.Deckenleuchte_DG_Bad_Farbe [object Object] Cannot read property 'hasOwnProperty' of nullGibt es da etwas neues? Wäre ganz nett, wenn ich die Farbtemperatur mal ansprechen könnte.
-
@MatthiasB sagte in KNX Adapter überholt:
Hallo Schmid_no1,
das habe ich ja versucht, aber ih bekomme die Fehlermeldung ("File index_m.html not found") so dass ich überhaupt keine ip, etc. eingeben kann.
Werde mal iobroker Install knx, Biobroker upload knx sudo erbot versuchen, aber eigentlich hatte ich das schon versucht.
Knxd oder eibd brauche ich nicht, oder???
Gruß MatthiasHab das gleiche Problem und hab dann übers Terminal die genannten Befehle ausgeführt:
iobroker install knx
iobroker upload knx
sudo rebootwas mich wundert:
-Dadurch wurde Version 1.0.20 installiert.
-Wenn über über die grafische Oberfläche->Eigene URL->Github KNX installiere kommt 1.0.19 (Diese Version machte die Probleme)
-Wenn ich über die grafische Oberfläche mit dem "+-Symbol" installiere kommt immer Version 0,8.6 -
Seit einigen Tagen habe ich übrigens noch das Problem, dass sich meine Rollläden morgens um 6 Uhr (das ist aktuell vermutlich die Zeit des Sonnenaufganges) einfach öffnen!
Ich weiß nicht woran es liegt, weil ich für jede automatische Rollladenfahrt eine Nachricht an mein Telegram schicke.
Das funktioniert auch bei den Bewegungen, die ich geplant nachvollziehen kann. Komischerweise wird aber immer genau bei diesem Phänomen nichts versendet.Ich habe in den letzten Wochen meine Scripts und meine KNX Programmierung stetig erweitert, sodass auch Gruppenadressen verschoben und umbenannt wurden.
Natürlich habe ich die Scripts hinterher korrigiert, überprüft und kann dort keine Fehler mehr feststellen.
Auch das KNX-Projekt habe ich mehrfach neu eingelesen und auch zuvor schon die Objekte händisch, oder den ganzen KNX-Adapter gelöscht.Aktuell bin ich stark verzweifelt, weil ich jeden Tag um 6 von den blöden Rollläden geweckt werde
Weiß eigentlich jemand wie es sich verhält, wenn ich eine Gruppenadresse in ETS verschiebe, aber den Namen gleich lasse?
Was steuert denn der Adapter beim KNX an? Gruppenadresse, oder Name?Edit:
ich konnte im Log-File dieses hier finden:
2019-05-02 06:04:09.808 - warn: javascript.0 getState "knx.0.Zentral.Tag_Nacht.Nachtmodus_DG_manuell" not found (3) states[id]=null
2019-05-02 06:04:09.812 - warn: javascript.0 at Object. (script.js.Jalousie.DG.Sonnenaufgang:2:7)
...Nachdem ich dieses Script heute Nacht deaktiviert hatte, sind die anderen Rollläden wieder so gefahren wie gewollt.
Kann es sein, dass ein Fehler in EINEM Script (DG) sich auf ANDERE Scripts (OG+EG) auswirkt?
-
@loverz : Hast Du diese willkürlichen Fahrten auch, wenn Du den KNX-Adapter bzw. den ganzen ioBroker neustartest?
Viele Grüße
Michael -
@mpenno ja, das waren meine ersten Behebungsversuche.
-
Im Prinzip geht es nur um diese Frage:
Kann es sein, dass ein Fehler in EINEM Script (DG) sich auf ANDERE Scripts (OG+EG) auswirkt?Und wenn ja, wie kann man sowas verhindern?
-
@loverz : Ich hatte auch diese Geisterfahrten. Um das zu lösen, musste ich in der ETS bei den Flags ganz schon aufräumen. In meiner Installation hatte ich ein Gerät von Busch-Jäger (Pri-ON) und dort waren standardmäßig alle Flags gesetzt.
Grob gesagt, ist ein "L" Flag nicht gut bei einer Gruppenadresse, die den Rolladen steuert. "L" Flags nur bei Objekten, die einen Status ausgeben sollen. -
@mpenno guter Hinweis.
Ich habe an den flags nichts verstellt. Diese sind alle so wie sie werkseitig eingestellt waren.Ich frage mich auch, wie sich falsche flags derartig auswirken können.
Wieso steuert ioBroker im Falle eines Scriptfehler die falschen Gruppenadressen an. Normalerweise sollte dann gar nichts angesteuert werden.
-
Hi, mich plagen noch immer gelegentliche Geisterfahrten.
Nun ist es sogar soweit, dass ich im Log nicht mal mitbekomme, was genau passiert geschweigenden eine Fehlermeldung.
Ich habe z.B. die einfache Aufgabe an ein Script übergeben an meinem MDT Glastaster die Status LED rot blinken zu lassen, wenn die Jalousie sich bewegt. Das funktioniert soweit auch, aber komischerweise blinkt die LED auch, wenn ich das Fenster öffne, obwohl ich in ioBroker und in ETS keinerlei assoziation zwischen der LED und dem Fensterkontakt habe.
Wie kann ich denn sicher sein, dass ich auch die richtigen Gruppenadressen ansteuere? Leider sehe ich in ioBroker nur den Namen der Gruppenadressen, aber nicht die Adressennummer selbst. z.B. 5.2.1
Mache ich vielleicht etwas bei dem Upload bzw. der Aktualisierung der KNXProj-Datei falsch?
Wie geht ihr denn vor, wenn ich in der KNX Programmierung etwas geändert/hinzugefügt/umbenannt habt.
Bei mir kam es z.B. auch schon vor, dass ich Gruppenadressen in ioBroker hatte, die ich zuvor schon in ETS gelöscht hatte.
Wie sollte man zur Aktualisierung vorgehen?
Edit: Habe jetzt mal den Adapter gestoppt, alle Objekte von KNX gelöscht und anschließend wollte ich die neue KNXProj-Datei uploaden. Geht leider nicht, wenn die Instanz nicht läuft.
Ich habe also die Instanz gestartet und schnell die Datei uploaded und siehe da: Die LED blinkt nicht mehr, wenn ich das Fenster öffne (so wie es sein soll)Der Fehler konnte also eindeutig auf den Adapter/den KNXProj-Datei Upload eingegrenzt werden.
Wie sollte man in Zukunft damit umgehen? Vielleicht kann man diese Fehler sogar programmatisch unterbinden?! -
Hallo,
bei einer Projektaktualisierung werden lediglich neue Gruppenadressen hinzugefügt. Bestehende bleiben unverändert, also auch die Flags.
Du hast nun also 2 Möglichkeiten:- alle KNX-Objekte aus dem Objektbaum im ioBroker löschen und neu importieren
- direkt die Objekte im Objektbaum ändern. (links mit dem Bleistiftsymbol)
Die Gruppenadressen findest du in den Objekteinstellungen unter dem Reiter RAW(nur Experten).
Nun zur Frage warum manchmal etwas augenscheinlich unvorhergesehenes passiert:
Wenn im ETS Projekt:
"KÜ" gesetzt ist: Dann darf dieses KO mit dem Bus reden (i.d.R. bei Änderungen (DimmwertStatus, o.ä)), es darf aber weder beschrieben noch gelesen werden."KSÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf etwas darauf schreiben (z.B. 0(true) oder 1(false) für DPT 1.xxx oder einen Dimmwert oder ....) UND das KO darf eine Änderung auf diesem KO senden was aber i.d.R keinen Sinn macht, denn dafür gibt es ja das Statusobjekt. Historisch gesehen gab es damals Aktoren bei denen war Schalt- und Statusobjekt das gleiche.
"KLÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf es abfragen (beim Adapter wird irgend ein Wert an diese GA gesendet und das KO antwortet dann....das ist die aktive Abfrage) UND das KO darf selbständig eigene Änderungen dem Bus mitteilen.
"KLSÜ" gesetzt ist: Rein logisch gesehen, wenn der Aktor getrennte Schalt- und Statusadressen hat, sinnfrei und sorgt aktiv für Verwirrung. Leider werden diese Flags pauschal in einigen Herstellerapplikationen gesetzt. Warum? Keine Ahnung.
Also: Bei SchaltKO's "KS" Flags setzen und bei StatusKO's "KLÜ".
ALLE GA's die ein "L" Flag tragen werden beim Adapterstart abgefragt.
VG
chefkoch009 -
@chefkoch009 Hi,
danke für die ausführliche Erklärung.
Ich werde es bei Gelegenheit mal ausprobieren und in der ETS Software etwas „aufräumen“
Melde mich dann nochmals.
-
@chefkoch009
So hab mich jetzt mal etwas eingearbeitet und stelle fest, dass die Flags eigentlich schon richtig gesetzt sind:Hier zum Beispiel eine Gruppenadresse (K-S) zum bewegen, die ich aber nicht über ioBroker, sondern über die Glastaster an der Wand steuere (sollte ja kein Problem darstellen oder?)
Hier eine GA (K-S) die ich ausschließlich ioBroker ansteuere:
Und hier eine GA (K-L-Ü) die ich sowohl in ioBroker auswerte als auch an den Glastastern anzeigen lasse:
Mich interessieren ja jetzt erstmal nur die Flags von den Kommunikationsobjekten die direkt an die Aktoren bzw. von den Aktoren kommen oder?
Die KOs der Glastaster sind ja erstmal egal, auch wenn die KOs in gemeinsamen GAs sind oder?Übrigens: Mir ist aufgefallen, dass diese Geisterfahrten vermehrt stattfinden, wenn ich meine Fenster offen habe (Fensterkontakte werden in den Scripts oft als Bedingung für die Rollofahrten abgefragt -> "Keine Rollofahrt, wenn Terrassentür offen")
Hier bin ich mir aber nicht sicher, ob ich das richtig programmiert habe:
Edit: Nach ewigem ausprobieren und einlesen etc. ist mir aufgefallen, dass diese „Geisterfahrten“ immer dann kamen, als ich mein Rollo im DG bewegt habe.
Nach dem Ausschlussverfahren habe ich den Fehler dann eingegrenzt.
Es stellte sich heraus, dass ich der Gruppenadresse für das DG Rollo ein Zentralobjekt des Aktors zugewiesen habe und nicht das einzelne Kommunikationsobjekt.
Somit haben sich alle Rollos bewegt, wenn ich diese GA angesteuert habe
Da der Rollo im DG nur an heißen Tagen bewegt wird (Hitzeschutz etc.) hat mich das Ganze in die Irre geführt und ich dachte es sei nur wenn meine Fenster offen sind, denn die sind logischerweise auch nur dann offen, wenn es heiß ist
Recht sporadischer Fehler und ich denke, dass ich ihn endgültig gefunden habe.
Der Adapter scheint wohl nicht Schuld zu sein
Danke für die Unterstützung!
-
@loverz Vielen Dank für das Feedback. Schön das Du den Fehler gefunden hast.
Aber mal zur allgemeinen Info: Seit ETS Version 5.7.0 gibt es mal wieder Änderungen im Export. Dies kann zur Folge haben, das Projekte nicht mehr / nicht mehr richtig importiert werden können. Das äussert sich unter anderem darin das:
- die Flags nicht richtig erkannt werden
- die Aufzählung für die Räume nicht erzeugt wird
- schalt und status nicht richtig erkannt werden
Kurzum....ne ganze Menge. Ich arbeite zur Zeit daran.
VG chefkoch009
-
Hallo,
habe kürzlich mit dem ioBroker und KNX gestartet. Bekomme auch das Schalten von Aktoren und Rolläden hin.
Nur beim Dimmen mit dem DPT3.007 stehe ich auf dem Schlauch. Habe folgende Definition:{ "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1562517593538, "common": { "name": "Deckl. Eßz. H/D", "type": "number", "role": "value", "min": 0, "max": 100, "read": false, "write": true }, "native": { "dpt": "DPT3.007", "address": "9/1/1", "addressRefId": "P-0494-0_GA-212", "statusGARefId": "", "actGARefId": "" }, "acl": { "object": 1638, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1638 }, "_id": "knx.0.EG.Bel__Innen.Deckl__Eßz__H_D", "type": "state" }Aber es zeigt sich keine Reaktion, egal was ich bei Wert in den Objekten setze. Was mache ich faslch?Danke
-
Irgendwie verschluckt sich hier der KNX Adapter jeden Tag an ein paar Statusmeldungen.
In der History sieht das so aus:0 true knx.0 2019-07-09 10:03:28.300 1 true knx.0 2019-07-09 08:29:01.253 1 true knx.0 2019-07-09 08:29:01.243 1 true knx.0 2019-07-09 08:29:01.243 0 true knx.0 2019-07-09 08:29:00.254 1 true knx.0 2019-07-08 08:29:01.253 1 true knx.0 2019-07-08 08:29:01.246 0 true knx.0 2019-07-08 08:29:00.253Mit ETS hab ich geguckt, was da über den Bus geht:
# Zeit Dienst Flags Prio Quelladresse Quellname Zieladresse Zielname Rout Typ DPT Info 107070 09.07.2019 07:29:58,718 vom Bus Niedrig 1.1.255 - 3/6/2 Heizpatrone DG Bad Ein/Aus 6 GroupValueWrite 1.001 Schalten $01 | Ein 107072 09.07.2019 07:29:58,789 vom Bus Niedrig 1.1.12 D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status 6 GroupValueWrite 1.001 Schalten $01 | Ein 107917 09.07.2019 08:28:58,678 vom Bus Niedrig 1.1.12 D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status 6 GroupValueWrite 1.001 Schalten $00 | Aus 107920 09.07.2019 08:28:59,683 vom Bus Niedrig 1.1.12 D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status 6 GroupValueWrite 1.001 Schalten $01 | Ein 107936 09.07.2019 08:29:58,712 vom Bus Niedrig 1.1.12 D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status 6 GroupValueWrite 1.001 Schalten $00 | Aus 109497 09.07.2019 10:03:26,666 zum Bus Niedrig 1.1.242 - 3/7/2 Heizpatrone DG Bad Status 6 GroupValueRead 109498 09.07.2019 10:03:26,700 vom Bus Niedrig 1.1.12 D3 Schaltausgang 10-fach, 16A C-Last 3/7/2 Heizpatrone DG Bad Status 6 GroupValueResponse 1.001 Schalten $00 | AusWas sieht man hier? Um ca. 7:30 Uhr schalte ich aus ioBroker heraus am Schaltaktor einen Ausgang ein. Der setzt entsprechend den Status auf Ein. Er ist so eingestellt, dass dieser Ausgang nach 60 Minuten wieder abgestellt wird. Er macht da auch ein wenig Quatsch und sendet erstmal "Aus", dann eine Sekunde später wieder "Ein", dann aber eine Minute später wieder "Aus". Ich habe gerade in den Parametern gesehen, dass es sich hierbei vermutlich um die "Ausschaltvorwarnung" handelt, die auf 1 Minute eingestellt war (habe ich nun abgestellt).
Verwirrend ist aber, was der ioBroker daraus macht. Wie man in der History sieht, werden aus den 3 Telegrammen auf dem Bus insgesamt 7 Statusänderungen. Leider bleibt dabei der falsche Status "Ein" am Ende bestehen. Wie kann das passieren? Kommen die Telegramme einfach zu schnell? Es tritt jeden Tag auf. Sollte nicht 1 Minute genug Zeit sein, dass der ioBroker den dann richtigen "Aus" Status korrekt verarbeiten kann?
So sieht übrigens die history vom dazugehörigen Schaltobjekt aus:
0 true knx.0 2019-07-09 10:03:28.304 1 true knx.0 2019-07-09 08:29:01.250 true false javascript.0 2019-07-09 07:30:00.065Kann es daran liegen? Auf dem Bus wird allerdings nach 7:30 Uhr auf der Schalt GA nicht mehr gesendet (weder von ioBroker noch vom Schaltaktor).
Ich habe gerade auch in das Log geguckt. Der KNX Adapter verbindet sich anscheinend um 7:30 Uhr und 8:30 Uhr jeweils neu. Hm. Warum? Zufall? Es scheint aber nach dem Schalten zu sein? Warum könnte der KNX Adapter da denken, er wäre nicht verbunden?
2019-07-09 07:30:26.716 - info: knx.0 STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0). 2019-07-09 07:30:27.219 - info: knx.0 STATE_NOT_CONNECTED : Stop connection : STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0). 2019-07-09 07:30:30.718 - info: knx.0 Using UDP with local IP: 192.168.0.2 2019-07-09 07:30:30.718 - info: knx.0 Event : UDP - listening 2019-07-09 07:30:30.718 - info: knx.0 Connected - local UDP Server listening on 192.168.0.2:49317 ... 2019-07-09 08:30:21.506 - info: knx.0 STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0). 2019-07-09 08:30:22.008 - info: knx.0 STATE_NOT_CONNECTED : Stop connection : STATE_NOT_CONNECTED(0) to STATE_NOT_CONNECTED(0). 2019-07-09 08:30:25.508 - info: knx.0 Using UDP with local IP: 192.168.0.2 2019-07-09 08:30:25.508 - info: knx.0 Event : UDP - listening 2019-07-09 08:30:25.508 - info: knx.0 Connected - local UDP Server listening on 192.168.0.2:37997Kann ich weitere Informationen liefern? Soll ich ein issue erstellen?
-
@chefkoch009 Ich nutze den Adapter schon eine Weile. Er funktioniert soweit ganz gut, vielen Dank schon einmal für Deine Mühen und viel investierte Zeit!!!
Bei der Weiternutzung der Objektdaten habe ich nur ein Problem, dass z.B. die ioGO App einige Zustände nicht darstellen kann, da diese nicht zu den in State / Roles definierten passen. Besonders störend ist dies bei den Boolean Werten. Hier steht bei mir über alle "1" oder "0", wo hingegen der Wert "true" oder "false" sein müsste.
Es wäre toll, wenn Du Dir das hier mal kurz ansehen könntest: ioGo # Native Android App vom 16.07.2019.
Wie ich gelesen habe, hattest Du kurz eine Version 1.0.18, die korrekt true/false setzt aktiv, hattest Dich jedoch wieder umentschieden. Richtiger wäre true/false zu setzen, aber die Kompatibiliät zu bestehenden Usern und deren Scripte verstehe ich natürlich.
Liesse sich nicht im Adapter eine Art "kompatibility"-Häckchen für die Anwender setzen, die unbedingt die bestehenden 1/0 Werte benötigen?
Oder hast Du eine andere Idee, wie ich die Werte nach true/false wandeln kann?
Viele Grüße
Michael -
@mpenno bin jetzt kein Experte und würde die „korrekte“ Schreibweise auch begrüßen, aber könntest du die Werte nicht mit einem eigens dafür gedachten Script anpassen?
Wenn Wert wurde geändert und ist 1, dann steuere Wert mit true oder so?
-
In Javascript Skripten lässt sich die Wandlung von 0/1 zu true/false am einfachsten durch voranstellen von !! erreichen, also z.B. let val = !!getState("knx.0....").val; Das habe ich mittlerweile in allen Skripten drinnen, die mit dem knx Adapter arbeiten.
Das sollte man am besten mal groß promoten, das alle Leute ihre Skripte langsam anpassen.
Wobei die meisten Skripte, die hier so geschrieben werden damit eigentlich wenig Probleme haben sollten. Zumindest sehe ich selten den === Vergleich, der auch den Typ prüft, sondern meistens ==, bei dem es egal ist ob da links und rechts der gleiche Typ ist, da ist für Javascript 0 = false und 1 = true (und noch ein paar andere Kuriositäten, weshalb der === Vergleich empfohlen wird).
Aber die Option fände ich auch gut, damit das true/false langsam mal kommen kann. Dann kann ja auch jeder selber sehen, wann er wie welche Skripte überarbeitet hat.
Wenn man irgendwie altinstallationen erkennen kann, kann man da die Option ja per default aktivieren und bei neuinstallationen dann deaktivieren. Oder man macht jetzt eine version, die die Option hat und per default aktiviert (und entsprechend speichert) und dann in einer Zeit X (z.B. 1 Monat oder so), nachdem man relativ sicher ist, dass alle Altbestände aktualisiert haben, eine neue Version, die das per default deaktiviert (was dann bei alten, wo es schon gesetzt ist, nichts mehr ändern sollte, richtig?). Dann hat man die Chance, dass man die 0/1 Situation irgendwann mal los wird...
