NEWS
SONOFF NSPanel mit Lovelace UI
-
Frohes neues Jahr.
Es handelt sich hierbei um einen Push-Button, der nur eine einzige Aktion durchführen kann. Daher gibt es auch nicht mehrere Zustände (nur true) für den Garagentor "PRESS".
Ein optionaler Zustand für einen weiteren Sensor ist nicht vorgesehen...
Du könntest allerdings in der gleichen cardEntities z.B. die Garage von der Farbe neutral (z.B. weiß) machen und über einen optionalen Info Alias darunter dann den Open/Close-Sensor den Zustand visualisieren
-
Hallo, bekomme seit dem ich Proxmox neu aufgesetzt habe und das IOBroker Backup zurückspielete folgende Fehlermeldung. Woran liegt dies?
2.1.2026, 12:28:25.857 [info ]: javascript.0 (29439) script.js.NSPanels.NSPanel_1: Compiling TypeScript source 2.1.2026, 12:28:28.832 [error]: javascript.0 (29439) script.js.NSPanels.NSPanel_1: TypeScript compilation failed: let name = page.heading !== undefined ? page.heading : o.common.name.de; ^ ERROR: Property 'de' does not exist on type 'StringOrTranslated'. Property 'de' does not exist on type 'string'. let heading = page.heading !== undefined ? page.heading : o.common.name.de; ^ ERROR: Property 'de' does not exist on type 'StringOrTranslated'. Property 'de' does not exist on type 'string'. heading = page.heading !== undefined ? page.heading : o.common.name.de; ^ ERROR: Property 'de' does not exist on type 'StringOrTranslated'. Property 'de' does not exist on type 'string'. unsubscribe(value); ^ ERROR: Argument of type 'unknown' is not assignable to parameter of type 'string | RegExp | string[]'. -
zu altes Skript - nicht kompatibel mit aktuellem JS-Adapter - vermute ich.
-
Nachdem ich Proxmox und IOB-Container auf Trixie hochgehoben habe, wollte ich auch IOB selbst auf den neuesten Stand bringen.
Auch ich bin mit meinem alten TS-Skript ebenfalls auf diesen Fehler gestoßen.Ja, es ist sehr alt:
Skript-Version V3.4.2.1 vom 16.09.2022.
Dementsprechend sind auch die Berry-Teiber und Tasmota nie angepasst worden.
Und ich habe es nie angepasst, weil es funktioniert hat und ich alle diese Neuerungen nie gebraucht habe. Und weil ich selbst was hingebaut habe, weil es nicht funktioniert hat wie ich es wollte (in einem Punkt).Die Frage ist jetzt, lässt sich in dem alten Skript noch etwas anpassen (auf die schnelle), also Fallback rausnehmen oder im .common.name noch schnell ein 'de' dazubasteln und den unsubscribe-Fehler durch eine Abfrage umgehen.
Wenn nicht, dann muss ich abschätzen, ob ich auf mein TS-Panel verzichten soll oder weiter auf dem passenden Javaskript bleiben soll.
Wobei zweiteres wahrscheinlich auch nicht auf Dauer gehen wird. -
Nachdem ich Proxmox und IOB-Container auf Trixie hochgehoben habe, wollte ich auch IOB selbst auf den neuesten Stand bringen.
Auch ich bin mit meinem alten TS-Skript ebenfalls auf diesen Fehler gestoßen.Ja, es ist sehr alt:
Skript-Version V3.4.2.1 vom 16.09.2022.
Dementsprechend sind auch die Berry-Teiber und Tasmota nie angepasst worden.
Und ich habe es nie angepasst, weil es funktioniert hat und ich alle diese Neuerungen nie gebraucht habe. Und weil ich selbst was hingebaut habe, weil es nicht funktioniert hat wie ich es wollte (in einem Punkt).Die Frage ist jetzt, lässt sich in dem alten Skript noch etwas anpassen (auf die schnelle), also Fallback rausnehmen oder im .common.name noch schnell ein 'de' dazubasteln und den unsubscribe-Fehler durch eine Abfrage umgehen.
Wenn nicht, dann muss ich abschätzen, ob ich auf mein TS-Panel verzichten soll oder weiter auf dem passenden Javaskript bleiben soll.
Wobei zweiteres wahrscheinlich auch nicht auf Dauer gehen wird.Nachdem ich Proxmox und IOB-Container auf Trixie hochgehoben habe, wollte ich auch IOB selbst auf den neuesten Stand bringen.
Auch ich bin mit meinem alten TS-Skript ebenfalls auf diesen Fehler gestoßen.Ja, es ist sehr alt:
Skript-Version V3.4.2.1 vom 16.09.2022.
Dementsprechend sind auch die Berry-Teiber und Tasmota nie angepasst worden.
Und ich habe es nie angepasst, weil es funktioniert hat und ich alle diese Neuerungen nie gebraucht habe. Und weil ich selbst was hingebaut habe, weil es nicht funktioniert hat wie ich es wollte (in einem Punkt).- Es muss nicht bedeuten, dass es mit dem alten Berry-Treiber und einem alten Tasmota nicht funktioniert.
- Wenn etwas funktioniert und nicht verändert werden soll, kann man es auch beibehalten. Dein Problem kommt aber mit dem neuen IOB-Container (Dazu mehr weiter unten)
Die Frage ist jetzt, lässt sich in dem alten Skript noch etwas anpassen (auf die schnelle), also Fallback rausnehmen oder im .common.name noch schnell ein 'de' dazubasteln und den unsubscribe-Fehler durch eine Abfrage umgehen.
Die Frage ist, wird das überhaupt erforderlich sein? Auch das Skript wurde an diesen Stellen mehrfach angefasst und angepasst... Evtl. existiert dein Issue gar nicht mehr?
Wenn nicht, dann muss ich abschätzen, ob ich auf mein TS-Panel verzichten soll oder weiter auf dem passenden Javaskript bleiben soll.
Warum verzichten? Wir haben 2 funktionale Lösungen:
- NSPanel-Skript in der aktuellen Version
- NSPanel-Adapter (jetzt auch im stable-Repository)
Die Probleme mit dem "NEVER touch a running System" kommen zwangsläufig. Ich würde eher sagen, dass es aus einer sich langsam entwickelnden Welt (früher) stammt und in der heutigen Zeit absolut keinen Sinn macht...
Daher meine Empfehlung:
- Betriebssysteme immer aktuell halten (ich denke man kann einen ioBroker nicht wirklich isoliert betreiben, da er sich immer irgendwie Daten (Wetter, PV, sonstige Devices) besorgt)
- ioBroker immer aktuell halten (NodeJS wird permanent weiterentwickelt. Ebenso TypeScript, mit dem nicht nur unser Skript geschrieben ist, sondern auch der ioBroker selbst und viele iob Adapter (TS wird immer restriktiver). Trixie mit neuem NodeJS und altem JS-Controller / JS-Adapter (oder auch anderen alten Adaptern) wird sicher nicht zur Stabilität beitragen.
Wobei zweiteres wahrscheinlich auch nicht auf Dauer gehen wird.
Stimmt. Nach der langen Zeit der funktionalen Freude, kommt früher oder später bei dieser Vorgehensweise "immer" das Tal der Tränen...
Wenn ich jeden Tag lese, wie viele User täglich ihre Systemprobleme berichten, die alle auf "Never Touch" basieren, dann muss ich schon ab und an schmunzeln. Das ist mir seitdem ich den ioBroker nutze noch nie passiert, dass ich etwas komplett neu aufsetzen musste. Auch meine Ubuntu VM ließ sich immer wieder in die aktuelle Neuzeit anheben... und wird es auch künftig...
-
Nachdem ich Proxmox und IOB-Container auf Trixie hochgehoben habe, wollte ich auch IOB selbst auf den neuesten Stand bringen.
Auch ich bin mit meinem alten TS-Skript ebenfalls auf diesen Fehler gestoßen.Ja, es ist sehr alt:
Skript-Version V3.4.2.1 vom 16.09.2022.
Dementsprechend sind auch die Berry-Teiber und Tasmota nie angepasst worden.
Und ich habe es nie angepasst, weil es funktioniert hat und ich alle diese Neuerungen nie gebraucht habe. Und weil ich selbst was hingebaut habe, weil es nicht funktioniert hat wie ich es wollte (in einem Punkt).- Es muss nicht bedeuten, dass es mit dem alten Berry-Treiber und einem alten Tasmota nicht funktioniert.
- Wenn etwas funktioniert und nicht verändert werden soll, kann man es auch beibehalten. Dein Problem kommt aber mit dem neuen IOB-Container (Dazu mehr weiter unten)
Die Frage ist jetzt, lässt sich in dem alten Skript noch etwas anpassen (auf die schnelle), also Fallback rausnehmen oder im .common.name noch schnell ein 'de' dazubasteln und den unsubscribe-Fehler durch eine Abfrage umgehen.
Die Frage ist, wird das überhaupt erforderlich sein? Auch das Skript wurde an diesen Stellen mehrfach angefasst und angepasst... Evtl. existiert dein Issue gar nicht mehr?
Wenn nicht, dann muss ich abschätzen, ob ich auf mein TS-Panel verzichten soll oder weiter auf dem passenden Javaskript bleiben soll.
Warum verzichten? Wir haben 2 funktionale Lösungen:
- NSPanel-Skript in der aktuellen Version
- NSPanel-Adapter (jetzt auch im stable-Repository)
Die Probleme mit dem "NEVER touch a running System" kommen zwangsläufig. Ich würde eher sagen, dass es aus einer sich langsam entwickelnden Welt (früher) stammt und in der heutigen Zeit absolut keinen Sinn macht...
Daher meine Empfehlung:
- Betriebssysteme immer aktuell halten (ich denke man kann einen ioBroker nicht wirklich isoliert betreiben, da er sich immer irgendwie Daten (Wetter, PV, sonstige Devices) besorgt)
- ioBroker immer aktuell halten (NodeJS wird permanent weiterentwickelt. Ebenso TypeScript, mit dem nicht nur unser Skript geschrieben ist, sondern auch der ioBroker selbst und viele iob Adapter (TS wird immer restriktiver). Trixie mit neuem NodeJS und altem JS-Controller / JS-Adapter (oder auch anderen alten Adaptern) wird sicher nicht zur Stabilität beitragen.
Wobei zweiteres wahrscheinlich auch nicht auf Dauer gehen wird.
Stimmt. Nach der langen Zeit der funktionalen Freude, kommt früher oder später bei dieser Vorgehensweise "immer" das Tal der Tränen...
Wenn ich jeden Tag lese, wie viele User täglich ihre Systemprobleme berichten, die alle auf "Never Touch" basieren, dann muss ich schon ab und an schmunzeln. Das ist mir seitdem ich den ioBroker nutze noch nie passiert, dass ich etwas komplett neu aufsetzen musste. Auch meine Ubuntu VM ließ sich immer wieder in die aktuelle Neuzeit anheben... und wird es auch künftig...
@Armilar sagte in SONOFF NSPanel mit Lovelace UI:
Wenn ich jeden Tag lese, wie viele User täglich ihre Systemprobleme berichten, die alle auf "Never Touch" basieren, dann muss ich schon ab und an schmunzeln. Das ist mir seitdem ich den ioBroker nutze noch nie passiert, dass ich etwas komplett neu aufsetzen musste. Auch meine Ubuntu VM ließ sich immer wieder in die aktuelle Neuzeit anheben... und wird es auch künftig...
Danke für die Antwort.
Es ist nicht so, dass ich alles schleifen lasse. Ich habe den Container auch nicht neu aufgesetzt sondern ein Upgrade gemacht.
Und ich update auch die Adapterversionen regelmäßig. Nur bei Major-Updates bin ich etwas vorsichtig.
Und ich habe schon vorher versucht auf Javascript V9 zu heben, es aber wieder zurückgezogen weil eben NSPanel nicht kompilierbar war.Zu den beiden NSPanel-Möglichkeiten kann ich nur sagen, dass ich beide im Auge habe, wobei mir der Adapter-Lösung wahrscheinlich besser gefällt. Ich habe ihn noch nicht angeschaut, aber ich hoffe, dass Code und Konfiguration dort besser getrennt sind. Das war es, was mich immer beim Skript gestört hat und es deswegen nicht weiter gepflegt hatte.
Und beide Versionen sind nicht von jetzt auf gleich einsetzbar. Deswegen habe ich auf einen Tip gehofft, diese vier Compilermeldungen zu umgehen, damit ich eine neue Version auf meinem Testsystem vorbereiten kann
-
@Armilar sagte in SONOFF NSPanel mit Lovelace UI:
Wenn ich jeden Tag lese, wie viele User täglich ihre Systemprobleme berichten, die alle auf "Never Touch" basieren, dann muss ich schon ab und an schmunzeln. Das ist mir seitdem ich den ioBroker nutze noch nie passiert, dass ich etwas komplett neu aufsetzen musste. Auch meine Ubuntu VM ließ sich immer wieder in die aktuelle Neuzeit anheben... und wird es auch künftig...
Danke für die Antwort.
Es ist nicht so, dass ich alles schleifen lasse. Ich habe den Container auch nicht neu aufgesetzt sondern ein Upgrade gemacht.
Und ich update auch die Adapterversionen regelmäßig. Nur bei Major-Updates bin ich etwas vorsichtig.
Und ich habe schon vorher versucht auf Javascript V9 zu heben, es aber wieder zurückgezogen weil eben NSPanel nicht kompilierbar war.Zu den beiden NSPanel-Möglichkeiten kann ich nur sagen, dass ich beide im Auge habe, wobei mir der Adapter-Lösung wahrscheinlich besser gefällt. Ich habe ihn noch nicht angeschaut, aber ich hoffe, dass Code und Konfiguration dort besser getrennt sind. Das war es, was mich immer beim Skript gestört hat und es deswegen nicht weiter gepflegt hatte.
Und beide Versionen sind nicht von jetzt auf gleich einsetzbar. Deswegen habe ich auf einen Tip gehofft, diese vier Compilermeldungen zu umgehen, damit ich eine neue Version auf meinem Testsystem vorbereiten kann
Deswegen habe ich auf einen Tip gehofft, diese vier Compilermeldungen zu umgehen, damit ich eine neue Version auf meinem Testsystem vorbereiten kann
Leider ist das nicht ohne weiteres möglich, da sich inzwischen eine Menge am JS-Adapter geändert hat.
Im Prinzip ist eine Migration in das neueste Skript ebenfalls mit wenig Aufwand möglich. Danach (oder auch gleich) könnte man auf den Adapter migrieren.