vielen Dank für die schnelle Hilfe

Ich habe das Problem jetzt anderweitig gelöst: Ich habe an nicht verwendeten Universaleingängen an der UVR16x2 ein Shelly Pro 3 mit 3 potentialfreien Kontakten angeschlossen. Der Heizungsfachman hat diese Kontakte nun in seiner Konfiguration entsprechend eingebunden, so kann ich "Kesselsperre" auch aktivieren beim Einsatz der Elektroheizung um die produzierte Energie zu verbrauchen.

Bei mir läuft eine Javascript Instanz. Aktuell sind 66 Skripte aktiv.

Danke für die Info.

Bei mir war die Lösung von der Adresse http://iobroker.local:8082/vis... auf http://192.168.2.198:8082/vis... umzustellen. Damit tritt der Fehler nicht mehr auf

@Bluefox Vielen vielen Dank für die Antwort und die Mühen. Dann "versteife" ich mich nicht mehr zu sehr auf den Geräte-Adapter. Dann nehme ich den Adapter am besten nur her, wenn ich eine 1:1 Abbildung des Gerätes mit dem Geräte-Adapter Alias erstellen kann. Dann muss man eben damit leben, dass jene "manuell" im Objektbaum erzeugten Alias-DPs -> im Geräte-Adapter TAB nicht ersichtlich sind. EDIT: Jetzt ist mir noch ein Licht aufgegangen... Manuell im Objektbaum anstatt eines "Verzeichnis" ein "Channel" als Ordnerstruktur anlegen. Unter dem "Channel" (Kanal) dann manuell die DPs erzeugen, die man möchte. Der Device-Adapter wandelt bzw. zeigt die DPs dann im Device-Adapter an oder lässt sie "verschwinden", je nachdem, ob man die ROLLE entsprechend erkennbarer Struktur einer "Vorlage" angewählt hat oder nicht bei den Alias-DPs. Wenn man z.B. die Alias-DPs komplett unter einer "Information" Type im Geräte-Adapter ersichtlich haben möchte, muss man entweder ROLLE value.state wählen (bei einer Zahl) oder bei anderen Formaten die ROLLE gänzlich löschen (sodass die Rolle leer bleibt). (andernfalls sieht man im Device-Adapter TAB nur den Ordner mit dem Namen (erstellter "Channel"), aber beim Editieren keine der manuell erstellten Alias-DPs, die tatsächlich im Objektbaum eigentlich vorhanden sind) EDIT #2: Und hier noch zwei Bilder, wie ich nun im Objektbaum manuell die "Channel" (später ersichtlich als Geräte im Device-TAB) und Datenpunkte angelegt habe inkl. dort eigene Symbol-Bilder eingefügt. Spoiler [image: 1767127412088-bild-objektbaum.png] Und vom Device-TAB. Womit bei richtig gewählten ROLLEN, die volle Zahl an Datenpunkten ersichtlich bleibt (rechts - Zustände). Und zzgl. das manuell hinzugefügte Bild links hier auch erscheint (abseits des DEFAULT Bildes, das angezogen werden würde). Spoiler [image: 1767127423332-bild-device-adapter.png] Bonus beim manuellen Hinzufügen im Objektbaum ist auch, dass man den Namen des Objekt-Pfades gänzlich selbst bestimmen kann. Beim Erstellen eines Alias über den Device-TAB, ist man hingegen bei den Vorlage-DPs gezwungen die vorgegebenen Pfad-Namen, wie z.B. SET / ACTUAL / ON / UNREACH ect. zu verwenden. (inkl. gezwungener Großschreibung) -> Im Objektbaum in der Spalte "Name" kann man individuelle Namen vergeben, unabhängig vom Objektpfad-Namen. -> Aufpassen muss man aber, wenn man im Device-TAB per DRAG & DROP einen Alias-DP im Objektbaum verschiebt. -> Die Endung des Objekt-Pfades wird dann geändert auf den zuvor vergebenen individuellen "Name". -> Das muss man unbedingt im Hinterkopf haben ! ! ! Memo an mich selbst: Querverweis auf eine im Mai gestellte Frage - https://forum.iobroker.net/post/1269538

MEMO an mich selbst: Nicht zu sehr auf Geräte-Adapter "versteifen" -> Wenn Geräte nicht 1:1 per Adapter-Vorlage möglich -> gerne auch auf manuelle Erstellung im Objektbaum zurückgreifen siehe -> https://forum.iobroker.net/post/1316331

@Homoran vielen Dank, Lösung gefunden. Ja, ich habe die Betatester Version drauf, habe mir aber schon gedacht, dass es sicher eine einfache Frage ist. Hatte das leider nicht gefunden ohne deinen Link. Dankeschön

@Stefan-Berlin1 sagte in Steuerung Gecko in Touch 2 per iob möglich? (Wellis): Schön zu hören das es jetzt doch geht. Ich habe schon etwas drüber geknobelt und die Fehlerbehandlung noch weiter verbessert, aber lass das jetzt von den eingesetzten Scriptständen mal so wie es ist. Ich denke dein: /set/javascript.0.Datenpunkte.SwimSpa.0.Zieltemperatur?value=#V aus Loxone ist falsch. Ich vermute Loxone sendet wirklich den Wert "#V" und nicht die von dir erwartete Zahl "35". In der Folge schmiert auch spa_updateBulk.py ab, weil es jede Minute den Wert holt und an der Stelle eine Dezimalzahl und nicht "#V" erwartet... Wechsle mal in die Objektansicht und stelle bei der Zieltemperatur manuell eine Zahl ein, sagen "33", dann: 1 Minute warten, spa_updateBulk.py sollte sauber laufen und ggf. die im SpaController eingestellte Zieltemperatur zurückschreiben. Jetzt mit Loxone deinen neuen Zielwert eintragen Wenn in der Objektansicht jetzt "#V" steht, dann liegts an dem was Loxone sendet. Wenn ich die Loxone Doku so lese müsste es "\v" sein um den Wert zu senden. Ich habe aber kein Beispiel zur Hand, da ich die Temperatur im Sommer komplett automatisch nachziehen lasse.

ich hab mal einen raspi 4 bestellt. auf den installier ich das neu und dann werd ich sehen abs dann da ist. aktuell hab ich das auf nem raspi 3 zum probieren

@Stefan-Falt sagte in ioBroker auf RaspberryPI 4 Stabilität: Nachtrag: Inzwischen geht alles wieder. Ich habe den Zigbee Stick ausgesteckt, neu gebootet, eingesteckt und alles neu vernbunden. nerv Danke für Statusrückmeldung.

@Thomas-Braun Ok Dann muss ich das wohl tun wenn ich zeit habe. Ich Danke Dir für deine mühe.

Super, dankeschön

Hallo zusammen, habe die Lösung gefunden und zwar in einem Update des "GoodWe Modbus Protocol" vom April.2024. Wenn mir jetzt einer sagt wie ich diese Unterlage hier hochladen kann, werde ich es hier reinstellen. MfG Wastl

Wenn du wirklich noch 0.0.27 installiert hats, dann schau dir bitte mal den Changelog des Adapters an: https://github.com/TA2k/ioBroker.parcel/tree/master#changelog Da könnte was für dich dabei sein. Ich hab aber keine Ahnung ob die neueren Versionen ev. andere Probleme haben. Der Maintainer hat diese nicht mehr als stabil eingestuft daher ist der Adapter auch nur als BETA Release verfügbar. Warum er dies nicht getan hat ist mir nicht bekannt.