@armilar Wenn man zu sehr von der Problematik aus Sicht von ioBroker abweicht, besteht für den Thread die Gefahr, dass er nach "offtopic" geschoben wird. Ob man nun WIRKLICH für die konkrete aber unbekannte Aufgabe ein stromschluckendes Relais braucht, oder auch mit einem deutlich sparsameren Schalttransistor auskäme (was den Akku-Betrieb erleichtern würde) ist nicht einmal im weiteren Sinne ein ioBroker Problem. In der Regel ist es unter dem Aspekt der Problemlösung sicherlich sinnvoll, eine Aufgabe unter allen Aspekten zu betrachten, aber auf der anderen Seite würde das womöglich den Rahmen des Forums sprengen. An einer Stelle sollte man aber sicherlich auf jeden Fall intervenieren: Wenn die empfohlene Lösung ggfs. zu einer Gefahr für den Fragesteller werden könnte...

@paul53 Volltreffer :+1: Vielen Dank für deine Hilfe. Nicht nur dass das jetzt so funktioniert wie gewünscht, sondern auch noch richtig was gelernt. 😀

@uwe2020 sagte in Tipp für eine neue Gasheizung: frage ich lieber euch. Moin, ich würde ja so vorgehen, mir die infrage kommenden Heizungen, unter dem Gesichtspunkt, Hausautomatisierung, beim Hersteller anzuschauen, dann schauen ob es einen Adapter gibt oder ob die Methode z.B. CanBUS, mqtt, ModBUS, IoBroker, eigene Schnittstellen Hardware unterstützt wird. Wenn Du ein Heizungsbauer hast, kenn es ja auch sein, dass er das, was Du hier vorgeschlagen bekommst nicht verbaut, da keine Verträge oder so, Du brauchst, aber später jemanden, der das Zeug wartet. Ich habe mir vor 2 Jahren eine Wolf Therme einbauen lassen und das Modul ISM7 mit eingebaut, ich kann somit über die Wolf-Cloud oder in ioBroker die Therme steuern, obwohl mir ein, zwei Dinge in ioBroker fehlen, kann ich aber mit leben. Die fallen mir abrupt ein, ob die alles das können, was Du suchst, kann ich nicht sagen. Wolf Vailland Weishaupt

@dp20eic [image: 1697896076857-15f31779-4160-4de4-af56-a4b0439fee0b-image.png] Ja, steht im Doku dazu drinnen: 1.1.42022-06-17 Apollon77Prevent crash case reported by sentry 1.1.32022-04-27 Apollon77Prevent crash case reported by sentry 1.1.22022-04-19 Apollon77Prevent crashes when states are controlled with null as value 1.1.12022-04-17 Apollon77Prevent error logs with js-controller 3+* (Apollon77) Added sentry for error reporting 1.1.02020-04-09

So, Rückinfo von mir. Tasmota nochmal drauf gemacht. ohne Netzteil, Widerstand oder Kondensator. nur 29 LED an. Dann g und Befehl "pixels 300" gefunden. Eingegeben und alle LED funktionieren. Dann wled nochmal drauf geflasht, Pin D4 genommen. ohne Netzteil, Widerstand oder Kondensator. Funktioniert nachdem man per PC in Wled die Anzahl der LED hoch gesetzt hat. Dann mit Netzteil (rot und weiß ans Netzteil) und grün vom Wemos zum stripe. Nur komische Farben. Dann weiß (also gnd) ebenfalls an Wemos. Und funktioniert einwandfrei. Habe jetzt auch mal Widerstand und Kondensator bestellt (bevor jetzt alles funktioniert hat). Na ja, schade kann es ja nicht. Fazit: läuft mit Tasmota und wled Und natürlich auch mit dem wled Adapter. jetzt muss ich mir nur noch ne vis bauen. mfg Dieter

@dieter_p sagte in Aeotec MultiSensor 7 Konfiguration unter Z-Wave 2 v3.0.x: Beim Intervall ist mir eine häufigere Messung lieber da ich so nach meinen Vorstellungen mir im IOBroker Filter bauen kann. Dein Sensor läuft auf Akku/Batterie da wäre das schon ein Punkt. Genau deswegen will ich keinen Akku/Batterie-Betrieb bei den Sensoren, weil eine häufigere Messung und entsprechende Übermittlung einen häufigeren Wechsel/Ladezyklus nach sich zieht.

@dieter_p hat perfekt funktioniert. danke

@ralla66 Danke für die Antwort, aber die erste Zahl gibt den Key an, die zweite die Option. In deinem Beispiel bringst du ein wenig etwas durcheinander 21:32:52 CMD: RfCode2 16 21:32:52 MQT: stat/Bridge/RESULT = {"RfCode":16} Beim Aufruf von "RFCode" übergibst du der Bridge einen Code den sie ausführen soll. Da braucht es gar keine erste Zahl, weil gar kein RFKey verwendet wird. Du übergibst im Beispiel nur den RFCode 16, den die Bridge auch sendet, ohne auf die 2 einzugehen, weil sie für das ausführen des Codes keinen spezifischen Key verwendet. Nur so kann man ja auch RFCodes ausführen die gar nicht in der Bridge gespeichert sind. Für die Optionen (1-6) muss der Befehl RFKey anstatt RFCode verwendet werden. Bei mir macht die Bridge das ja auch korrekt und führt gewünschten Code oder gespeicherten Key aus, allerdings eben nicht 6stellig wie von mir übergeben, sondern nur 5stellig (anstatt Code 56550C nur Code 56550. Deshalb reagiert der angesteuerte Switch auch nicht, da er sich gar nicht angesprochen fühlt. Deswegen vermute ich ja auch einen Formatfehler durch eine falsche Einstellung in der Bridge. Nur das ich eben nicht weiß, welche Einstellung dort relevant ist.

@homoran @SmartHomer-0 Ich möchte gar nicht an die "Hintere Schnittstelle". Es geht mir darum, ob der Netzbetreiber über diese Schnittstelle den herstellerspezifischen Datensatz für die INFO Schnittstelle aktivieren kann. Laut Handbuch sollte das wohl möglich sein. Beim Stöbern im Forum hatte ich den Eindruck, dass einige diesen Datensatz auch über die INFO Schnittstelle des DTZ541 bekommen. Mal sehen was der Netzbetreiber zu meinem Anliegen sagt.

Ups, sorry, ich dachte, ich hätte auf den Thread "SONOFF NSPanel mit Lovelace UI" geantwortet. Ich werde es dort weiter fragen. Danke mit dem Hinweis auf die Button Rules.

Hallo, das hört sich interessant an. Kannst du uns/mich hier auf dem Laufenden halten wie sich dein Projekt entwickelt und wie du es umsetzt ?

Hi, Hat das jemand hinbekommen das der Growatt MIC die Werte des Smartmeters vom iobroker Modbus abholt? Ich habe dabei das Problem das der Growatt die iobroker Modbus Instanz al 1 Phasiges Smartmeter nur erkennt. Ist aber ein 3 Phasisges. Hier hab ich das Problem beschrieben https://forum.iobroker.net/topic/69284/growatt-mic-smartmeter-sdm630-iobroker-modbus-rs485

@thoml Danke für den Hinweis, ich habe zwar Busch Jäger, aber da gibt es bestimmt auch so einen Taster.

@a200 Ich bin auch bekennender Anti-Cloud Fan-Boy ;) Bei meinem war ein TYWE3S drin: https://tasmota.github.io/docs/devices/TYWE3S/ Der ist Pinkompatibel zum ESP-12. Habe ich hier noch liegen aber nicht ausprobiert. Flashen ließ sich der Originale nur durch auslöten, da sie den Chip_Enable nutzen, um das WLAN auszuschalten. Also auf 3.3V gezogen, trotzdem kein flashen möglich. Ok, GPIO0 ist auch nicht gegen GND zum flashen... Letztendlich war es dann TX/RX, da hier der eigentliche Chip des Thermostats dran hängt und das flashen verhindert. An dem Punkt angekommen war es einfacher den Chip auszulöten als noch mehr Brücken einzulöten bzw. Leiterbahnen zu unterbrechen, wobei sich das Problem bei RX/TX gar nicht stellte, denn die verschwanden direkt unter dem TYWE-Chip.

@franzda sagte in zigBee Stecker können nach Update nicht bedient werden: Wie schon geschrieben: Buster ist tot und Desktops werden auf Servern nicht verwendet. Installier das Bookworm-Relese in 64bit in der Lite-Version.

@lessthanmore ja stimmt schon, aber die (funktionierende) Kombi habe ich nicht gefunden. Entweder nur Homekit-Steuerung oder nur Status. Selbst das habe ich in 4 Posts bis zum Ende durch gehabt, der Status war trotzdem nicht korrekt in Homekit. Die Infos habe ich dann aus diesen 4 Posts kombinieren müssen bis es gepasst hatte. Bei dem einen war in Yahka etwas falsch, beim anderen das script nicht fertig .... So kann man es ohne Aufwand und sehr günstig realisieren und hat alle Infos zusammen. Wollte nur etwas zurückgeben :)

Ich hatte mit den Datenpunkte auch Probleme. Für mich war das der Anreiz mal Zigbee2MQTT auszuprobieren. Nach dem umstieg kann ich sagen das es dort ohne Probleme geht.