@paul53 @GregorS Hab gerade nachgesehen Wusste gar nicht, dass es für den Tinker da einen Adapter gibt. Habe den OPi Adapter genutzt, der hat das gleiche Problem. Dort habe ich ein Issue erstellt.

@arteck Ist da wirklich so ein großer Unterschied? (hab leider kein Leuchtmittel in zigbee2mqtt, sind mit dem Hue Adapter eingebunden) [image: 1642516915361-vis_bulb_onoff_03.png] EDIT: War ein schlechtes Beispiel, ein Schalter passt eventuell besser [image: 1642517041009-vis_bulb_onoff_04.png]

Nach einem Neustart des Adapters kam nun das ? fritzdect.0 2022-01-18 13:41:19.331 info State value to set for "fritzdect.0.DECT_099950276783.boostactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.297 info State value to set for "fritzdect.0.DECT_099950276783.windowopenactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.296 info State value to set for "fritzdect.0.DECT_099950696353.boostactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.295 info State value to set for "fritzdect.0.DECT_099950696353.windowopenactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.294 info State value to set for "fritzdect.0.DECT_133560170728.boostactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.289 info State value to set for "fritzdect.0.DECT_133560170728.windowopenactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.289 info State value to set for "fritzdect.0.DECT_133560175984.boostactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.288 info State value to set for "fritzdect.0.DECT_133560175984.windowopenactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.287 info State value to set for "fritzdect.0.DECT_133560155800.boostactivetime" has to be type "number" but received type "string" fritzdect.0 2022-01-18 13:41:19.286 info State value to set for "fritzdect.0.DECT_133560155800.windowopenactivetime" has to be type "number" but received type "string" aber warum das sollte doch eine Zahl sein [image: 1642509904081-fritzdect2.jpg]

@steve-1 sagte in Passwort ioBroker versemmelt: @thomas-braun Danke dafür, vielleicht werde ich das alles irgendwann mal verstehen... Du warst schon mal nicht selbst schuld!

@ofbeqnpolkkl6mby5e13 sagte in Buanet Docker Startzeit: @andre # find /opt/iobroker -type f | wc -l Gibt "180495" zurück und geht im laufenden Betrieb schnell. Komisch. Word count dauert leider meistens ~ 1 Minute. Ich habe die Prüfung rausgenommen.

Ich kann tun was ich will, bei mir funzt 2.0.8. nicht. Sollte sich das mit einem anderen Adapter beißen, habe ich zum Testen ausser admin, web und kodi alles gestoppt. Dort geht es weiter > https://forum.iobroker.net/topic/44594/kodi-app-läuft-nich-binkt-immer-wieder-gelb/20

@exmerci sagte in Source Analytix schreibt - Werte. Mein Fehler: oder kann man beim Einrichten Fehler machen kann man jede Menge https://github.com/DrozmotiX/ioBroker.sourceanalytix#troubleshooting @exmerci sagte in Source Analytix schreibt - Werte. Mein Fehler: Ich habe über die Suche zwar Threads mit über 1000 Beiträgen gefunden, aber die sind eigentlich veraltet. https://forum.iobroker.net/topic/40932/sourceanalytix-0-4-8-final-released

@decnet Oh ja!

@paul53 Danke, ist ein Fallback Szenario. Noch wer ne Idee ob mal den Fehler vom Modbus Adapter selbst abfangen kann, oder wenn Werte ausserhalb einer Range z.B. > 64.000 kommen diesen dann auf 0 zu setzen?

@peter213 ganz klar den normalen Adapter. Ich hatte erst den normalen und da der nicht mehr gepflegt wurde bin ich auf den extended umgestiegen. Dort ging das mit dem Bewegungsmelder auch (aktuell geht es mit den normalen auf jeden Fall). Aber irgendwann hatte der Entwickler keine Lust mehr dafür wurde ein neuer Entwickler gefunden für den normalen Adapter. Also wieder zurück. Die Struktur fand ich vom Extended teils besser teils schlechter. Spannend wird es wenn endlich auf die neue hue api umgestellt wird und die Daten per push aktualisiert wird (derzeit mit JavaScript möglich). Dann ist der Adapter unschlagbar.

@modjo sagte in [gelöst]Probleme mit mihome-vacuum adapter und canvas: Was ergeben sich denn jetzt genau für Nachteile, wenn ich auf der hohen Version bleibe? 'Komisches' Verhalten bei Adapter-Installationen und npm-Aktionen.

@jogge sagte in zigbee nach update gelb: Moin, hab gesehen das es eine Version 1.6.6 gibt. Hat einer der Betroffenen mal getestet, ob das Update damit funktioniert? Der Effekt mit den "wandernden" panID und ExtPanId beim Update von 1.4.x auf 1.6.x ist weiterhin vorhanden. Allerdings ist es üblicherweise kein Problem den Adapter auf das einzustellen was im Backup hinterlegt ist, damit wurde das bestehende Netz sowieso betrieben. Wie dieser Shift zustande gekommen ist kann ich mir bisher noch nicht sauber erklären - auch da ich kein System habe welches dieses Verhalten zeigt. Einzig Nutzer von einem bestimmten Koordinator mit einer bestimmten Firmware können nicht updaten - da sind aber nicht die vom OP genannten log einträge zu sehen. A.

@asgothian Vielen Dank für das Blockly! Ich habe inzwischen auch eine Lösung gebastelt und bin auf Anraten von @liv-in-sky und @BananaJoe auf JSON gegangen. Trotzdem ist es interessant Deine Lösung zu sehen.

@arteck Das weiß ich. Deshalb frage ich ja nach einer anderen Möglichkeit, ohne umständlich mit Screenshottools, FTP Tools und zusätzlichen Adaptern arbeiten zu müssen. Die gibt es offenbar nicht. Dann muss ich wohl tatsächlich den aufwändigen Weg gehen......

@pandara an dieser Stelle ist weniger die Bindung und mehr ein “configure reporting” erforderlich, welches das Gerät hoffentlich akzeptiert. Auch das ist ein Punkt auf meiner Liste. A.

@bananajoe Oh Ha Natürlich ! Über alle hatte ich Steuern, nur da Aktualisiere ! So etwas Dämliches ! Jetzt ist alles OK und die Meldung kommt Zeitnah an. Danke für die Hilfe !

@meinzisas sagte in Update Javascript Adapter: Wann wird sie dann wieder neu erzeugt? sollte beim nächsten Aufruf von npm passieren

@hipohop sagte in zigbee2mqtt setup: @hydrotec @mickym Hier ein kleine Zusammenfassung: Es funktioniert jetzt :-) Dankeschön für die Rückmeldung Schön das es jetzt wie gewünscht funktioniert. Ich habe ein wenig probieren müssen bis ich die richtige Syntax gefunden habe, aber bei mir funktioniert folgendes. setState("mqtt.0.zigbee2mqtt.OSRAM4.set","OFF"); Das kommt daher, das du bei dir in der zigbee2mqtt Konfiguration unter mqtt-payload-format : json eingetragen hast. Für die Zukunft, also wenn du komplett auf ioBroker umgezogen bist, würde ich dir, erst mal für den Übergang attribute_and_json empfehlen. Und später dann auf attribute zu wechseln. Dann wird dein payload gleich in einzelne Objekte zerlegt. Ist dann einfacher zigbee2mqtt zu steuern, bzw. mit scripts zu arbeiten. (zum Testen, kannst du den ganzen Objektbaum löschen, wird ja wieder angelegt) Vielen Dank euch allen für die tolle Hilfe! Immer wieder gerne ;-) PS: Kann ich den Thread hier irgendwie als closed/solved markieren? Da war @Thomas-Braun schneller. (bei mir ist ja noch früh am Morgen ;-) ) Gruß, Karsten

@arteck Danke für die Info