Okay, 1882/TCP eingerichtet und es scheint zu funktionieren. War der Meinung, das es UDP sein muss.

@vandura Spannend, ich hatte auch jahrelang den km200 Adapter und musste notgedrungen auf den EMS-ESP umsteigen. Bis neulich funktionierte das super, vor allem ohne Umbauten. Icxh hab e eine Fussbodenheitung nachgerüstet, die ich über iobroker steuere udn die sich an der Zieltemperatur meiner Heizujg orientiert. Dafür brauche ich immer die aktuelle Solltemperatur. Jetzt ist bereist das zweite mal der EMs eingeschlafen. Der Adapter tut so als sei alles in Ordnung aber er holt keine aktuellen werte von der Heizung mehr. Das war bis vor zwei Wochen nie vorgekommen... Man merkt das daran, dass der Timestamp ems-esp.0.gateway.DateTime stehen bleibt. Über den werde ich mir jetzt auch ein Alarmscript schreiben mit dem ich in einen Notfallmodus gehe Das hat nun dazu geführt dass das ganze Haus im EG auf gemütlichen 17°C war. Ich werde die FB Heizung vorsorglich anders steuern, so gehts ja leider nicht mehr. Wenn ich versuche Werte zu schreiben: ems-esp.0 2023-12-03 11:32:33.162 warn KM200 http write error undefined:heatingCircuits.hc1.activeSwitchProgram ems-esp.0 2023-12-03 11:32:33.161 error axios put: heatingCircuits.hc1.activeSwitchProgram AxiosError: Request failed with status code 404 ems-esp.0 2023-12-03 11:32:29.757 info KM200 write change: ems-esp.0.heatingCircuits.hc1.activeSwitchProgram: 1 ems-esp.0 2023-12-03 11:32:28.086 warn KM200 http write error undefined:heatingCircuits.hc1.activeSwitchProgram ems-esp.0 2023-12-03 11:32:28.085 error axios put: heatingCircuits.hc1.activeSwitchProgram AxiosError: Request failed with status code 404 ems-esp.0 2023-12-03 11:32:27.822 info KM200 write change: ems-esp.0.heatingCircuits.hc1.activeSwitchProgram: 0 ems-esp.0 2023-12-03 11:32:14.542 warn KM200 http write error undefined:dhwCircuits.dhw1.singleChargeSetpoint ems-esp.0 2023-12-03 11:32:14.541 error axios put: dhwCircuits.dhw1.singleChargeSetpoint AxiosError: Request failed with status code 404 ems-esp.0 2023-12-03 11:32:14.418 info KM200 write change: ems-esp.0.dhwCircuits.dhw1.singleChargeSetpoint: 55 Der Zeitstempel der empfangenen Werte ist immer aktuell nur der Lastchange ist uralt. Die Instanz ist grün, nach Neustart auch. Aber das Problem bleibt. Nils

@se232 sagte in IOT Alexa Geräte in Alexa App refreshen: Was mache ich falsch? Du solltest auch mal Deiner Alexa sagen Alexa, suche Geräte

@hardl Hallo, kannst Du das bitte mal genauer ausführen? Ich stehe vor demselben Problem. Wenn ich den Code in der Form 1234-5678 eingebe passiert gar nichts. Ich lande nur wieder im Menü "Gerät hinzufügen". Am Rande: Ich habe eine andere Yahka-Bridge am laufen, die auch funktioniert.

@mic905 Habe gerade mal einen Test mit einem HM Taster gebaut: [image: 1700752560525-bildschirmfoto-2023-11-23-um-16.15.17.png] Taster gedrückt und funktioniert: javascript.0 2023-11-23 16:14:10.462 info script.js.Tests.Taste: mach was Test

@djmarc75 Ich verschiebe meine Frage...

@drsnuggles1982 Wollte nur noch mal kurz eine Rückmeldung geben. Ich war mir schlicht nicht darüber bewusst wie wichtig das Timing bei diesen Aktoren ist. In der Dokumentation gab es kein Zeitverlaufsdiagramm weshalb ich darüber auch nicht länger nachgedacht hatte. Das hat natürlich auch sofort das beobachtete Verhalten erklärt. Getestet habe ich nur SPS(0), aufgrund der Einschränkung in der Einflussnahme auf die Auswirkung des LO. Die einstellbaren Intervalle werde ich die Tage noch ergänzen, denn diese möchte ich in jedem Fall in der Nacht nutzen können (120min).

@arteck sagte in [zWave] ausgefallenes Gerät entfernen: @troya sicher bin ich mir nicht.. aber der wird intern am Stick verbelieben.. wird halt nur als dead intern markiert Ja ich meine auch so in der Art ist das. Die Node bleibt vergeben, und wenn man das Gerät zurücksetzt und neu anlernt gibt's ne neue Nummer. ich komm aber nochmal zurück auf die message... das ist doch nur bei adapter start oder nicht. Ja richtig. Trotzdem schaue ich beim Neustart gerne in das Protokoll ob es irgendwelche Probleme gibt und da nerven die mich. Ist vielleicht auch nur ein Tick von mir:blush: ich würde die beiden drin lassen.. so brauchst du dann nix ändern im scripten.. Ich arbeite mit Alias, da stört das nicht und die ausgefallenen sind ja eh im "Lager", daher haben die aktuell auch keine Scripte.

@docsnyder7 Muß ich beobachten. Hatte ich mal aus und mal eingeschaltet.

@walter-white musst du nicht... https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/blob/main/docs/wiki.md

@hans_999 sagte in [gelöst] HM Classic: Keine Verbindung zum RPC: eine große Umbenennungsorgie des HM-RPC-Adapters sicher? @hans_999 sagte in [gelöst] HM Classic: Keine Verbindung zum RPC: Logeinträge der Form und was steht davor?

@funcarv3r sagte: Ist im Raspberrymatic Kanal 5 Der Kanal 5 enthält nur Konfigurationsparameter, die keine Datenpunkte sind (auch nicht in der CCU). [image: 1699807349515-hmip-wth-b_ch5.jpg] @funcarv3r sagte in Frage zum HmIP-WTH-B-2: bei welcher Temperatur der interne Schaltaktor schalten soll. Das steuert man über den Sollwert (SET_POINT_TEMPERATURE).

@john sagte in Tasmota-Steckdosen produzieren laufend Warnmeldungen: Nun die Frage, welche (Tasmota)Steckdosen funktionieren jetzt noch im ioBroker bzw. sind jetzt noch flashbar? Moin, die Sucher bei mir ergibt -> https://www.amazon.de/s?k=tasmota+steckdose&crid=3CUNOY5RBJIGZ&sprefix=tasmota%2Caps%2C82&ref=nb_sb_ss_ts-doa-p_1_7 Von den Nous gibt es wohl schon fertig geflaschte. VG Bernd

@arteck Danke Dir. :-) Das htte ich auch gerade gefunden als ich mir die Info zum Adapter angeschaut habe

@bloop guten Morgen danke für deine ausführliche Antwort :-) Habe einen AP in Betrieb und keine CCU.. muss mal schauen, ob ich das irgendwie auf den AP angepasst bekomme. Hast du eine Idee ? Liebe Grüße und vielen Dank!!!