Die Änderung entschärft mein Problem. Der Fehler ist danach weg.

Leserechte sind per Default gesetzt (user / group / all).
Variante 1 funktioniert, während auf dem gleichen FHEM Device der direkte Weg über fhem.0.deinDevice.on-for-timer den Fehler provoziert.
Variante 2 läuft auch auf den Fehler: State "fhem.0.info.Commands.sendFHEM" does not exist in the ioBroker

@LausiD sagte in node-red State ... does not exist in ioBroker:

habe ich dich richtig verstanden....ein über den FHEM Adapter neu angelegtes Objekt mit der ID on-for-timer und Typ state erzeugt die Fehlermeldung?
Wurde der Wert für das Objekt einmalig manuell geändert ist die Fehlermeldung weg und Übertrag in FHEM funktioniert?

ja. Solange das Objekt nach dem Anlegen in fhem eine "leeren" state hat, erfolgt der Fehler in node-red. Sobald ich manuell über den iobroker admin einen Wert in den State einsetzte, ist der Fehler weg. Tritt übrigens auch bei den States "on" und "off" auf.
Node-red "sieht" ja anscheinend das kein state da, sonst würde kein Fehler im Logfile erscheinen, aber das Flag "Create states if not exist", bzw. autocreate ist hier ohne Funktion: der Fehler ist dann zwar nicht mehr im log file zu sehen, aber der State wird trotzdem nicht angelegt (obwohl ein Wert <> leer in msg.payload vorhanden ist) und es kommt kein Event in FHEM an.
Und warum reagiert node-red hier anders als der admin? Im admin kann ich on-for-timer auslösen, auch wenn kein Wert vorhanden ist (leerer String und per Maus mit ok bestätigen). Aus node-red heraus geht das nicht.

Bei neu erzeugten FHEM devices (FRM_OUT gpio FIRMATA) liefert node-red auf den on-xxx devices den Fehler 'State "fhem.0.HKMw.on-for-timer" does not exist in the ioBroker'.
Der State wird im Admin in der Objektliste angezeigt, ist also vorhanden, wenn auch mit einem leeren Wert.
Der Fehler tritt auf, bis man manuell im admin einen Wert ungleich leer für den state gesetzt hat.
Setzt man in node-red die option "Create states if not exist" kommt der Fehler zwar nicht mehr im Logfile vor, aber es erfolgt auch keine State Änderung und somit keine Meldung an FHEM etwas auszulösen.

Ein manueller Trigger auf den State über den iobroker admin ist aber auch mit leerem Wert möglich und kommt in FHEM an. Hier stimmt also etwas nicht bei der Abfrage in node-red ob der state vorhanden ist, bzw. in der zugrundeliegenden Funktion in iobroker.node-red/nodes/ioBroker.js

iobroker admin 3.6.0
iobroker node red: 1.7.1
iobroker fhem: 1.1.1

@jaghatei sagte in Floureon Wifi Raumthermostate:

Topic: WeBack/device_change/notify_from_device
{
"Notify_Reason": "timestamp_sync_req",
"Thing_Name": "<thermostat id>",
"Offset_Hours": 0,
"Offset_Minutes": 0
}

Auf diesen Request erwartet das Thermostat eine Response mit der aktuellen Uhrzeit:
topic: WeBack/device_change/notify/by-t03/<thermostat id>
{"Notify_Info": "timestamp_sync_rsp", "weekday": 4, "hour": 15, "min": 26, "year": 2019, "month": 3, "date": 7}

Allerdings funktioniert das Thermostat auch ohne Probleme im manuellen Modus, wenn das nicht gesendet wird. Das Setzen der Uhrzeit dürfte allerdings für die Wochenprogramme von Bedeutung sein.

Werte kann man über folgendes Topic ändern:
topic: $aws/things/<thermostat id>/shadow/update/delta
{"state":{"set_tem": 46}}

Das Beipiel setzt die Solltemperatur auf 23 °C.

@padrino
betrifft wohl die neueren Modelle mit WeBack App: https://www.amazon.de/gp/product/B07DQ8S82T
Die Anleitung der App verweist auf einen WeBack Alexa Skill. Der Funktionsumfang des Skills ist aber im Vergleich zur App ein Witz.

Ich habe die mit Broadlink Chip / room heat App / Beok App (https://www.amazon.de/gp/product/B077G6JKCX) auch im Einsatz (via FHEM mit BEOK Modul -> iobroker)

@frankjoke : in der /etc/dnsmasq.conf für jeden auszuschaltenden DNS Eintrag folgendes eintragen:
address=/facebook.com/127.0.0.1
und dnsmasq restarten / config neu laden.

@martin: kann ich verstehen, aber ich bin für ein zusammenfassendes Tutorial noch nicht weit genug .
Für die einzelnen Schritte kann ich aktuell nur auf viele Seiten verweisen:
opnsense.org als Firewall, DNS Server und vieles mehr.
www.openssl.org zur Erklärung und Generierung von Zertifikaten und CAs etz, aber auch zum debugen der Verbindung zum MQTT ("openssl s_client ...") oder dem Thermostat ("openssl s_server ...")
mosquitto.org zur SSL Konfig des MQTT brokers. (ich musste einen separat installieren, weil ich im iobroker keine zweite mqtt/server instanz mit SSL neben der ersten ohne SSL zum laufen bekommen habe. Einer von beiden ist immer eingefroren.
http://stefanfrings.de/esp8266/ enthält eine gute Übersicht zur PIN Belegung der ESP Module.
https://github.com/espressif/esptool für das esptool zum auslesen und schreiben der Firmware
https://github.com/arendst/Sonoff-Tasmota/wiki für ein paar gute Tutorials zum Flashen von ESP Bausteinen
https://mh-nexus.de/de/hxd/ ein für meine Zwecke mehr als ausreichender HEX Editor für Windows.

@martin sagte in Floureon Wifi Raumthermostate:

Das hier habe ich:

https://www.ebay.de/itm/Floureon-C17-GH … :rk:1:pf:0

Hat etwas Zeit in Anspruch genommen aber ich habe das C17-GH3 jetzt mit iobroker am laufen (via mqtt). Aber es ist Patching der Firmware erforderlich. Die Aussagen von frankjoke stimmen, das Thermostat redet nach der Initialconfig nur noch mit der Amazon IOT cloud. Das ist aber schlicht MQTT TLS.
Ausgangspunkt für mich war, das die Alexa App nur die Solltemperatur und nicht die aktuelle Raumtemperatur anzeigt, die WeBack APP aber beides.

Das Thermostat verwendet einen ESP-12S und die Firmware ist zumindest bei meinem nicht gegen auslesen geschützt.
Erforderlich sind die folgenden Schritte, openssl, ein Hex Editor und esptool.py und die (USB-)Adapter die man zum Flashen eines Arduinos braucht.

• Eigenen MQTT Broker mit SSL auf Port 8883 aufsetzen: eigenes Zertifikat mit cn= *.iot.eu-central-1.amazonaws.com , signiert durch eigenes self signed ca Zertifikat. Das * ist zwingend, ein Zertifikat auf den dedizierten Zielhost wird durch die SSL Validierung im ESP abgelehnt.
• Eigener lokaler DNS Server, mit dem der Zielhost a9vvblgf32b6o.iot.eu-central-1.amazonaws.com auf den eigenen MQTT Broker umgebogen wird. Bin nicht sicher ob der Hostname bei allen C17-GH3 identisch ist. Mag von der Firmwareversion und der Geräte Version abhängen, jedenfalls ist der konkrete Hostname im der Firmware als c-string enthalten.
• Firmware aus ESP auslesen und den enthaltene Public Key des Verisign CA Zertifkats durch den Public Key der eigenen CA ersetzen. Das Zertifikat ist ebenfalls als c-string in der Firmware enthalten und daher darf das eigene ca Zertifikat im PEM Form nicht länger sein als das Verisign Zertifikat, aber auch nicht kürzer. Eigenes Zertifikat daher mit Leerzeichen am Ende (nach "-----END CERTIFICATE-----") auf konkrete Länge des Verisign Zertifikates auffüllen. Wenn das eigene Zertifikat zu lang ist: Auf 1024 bit Schlüssel und SHA1 reduzieren. Anschließend gepatchte Firmware wieder in den ESP flashen.
• Da die Firmware ein OTA Update zuläßt hab ich dem Thermostat den Internetzugang in der Firewall verboten, sonst würde das nächste Firmwareupdate alles wirder zunichte machen.

Achtung: das Zertifikat ist wie nahezu alle anderen Abschnitte an zwei Stellen in der Firmware enthalten. Vermutlich wegen der OTA Funktion.

Seit dem sendet Das Thermostat sobald eine Wertänderung eintritt eine Nachricht an meine lokale MQTT Instanz in Form einer json Nachricht:
Topic: $aws/things/<thermostat id>/shadow/update
message:
{
"state":{
"desired":{
"connected":"true",
"working_status":null,
"safe_lock":null,
"set_tem":null,
"workmode":null,
"bgl":null,
"poweron_state":null,
"freeze_protect":null,
"tem_uint":null,
"control_mode":null,
"tem_cal":null,
"inter_sen_cal":null,
"outer_sen_cal":null,
"outer_sen_top":null
},
"reported":{
"connected":"true",
"offset_hours":0,
"offset_minutes":0,
"working_status":"on",
"workmode":"hand",
"air_tem":232,
"floor_tem":0,
"set_tem":46,
"safe_lock":"off",
"bgl":"auto",
"poweron_state":"keep",
"freeze_protect":"off",
"tem_uint":"C",
"control_mode":"inter",
"tem_cal":-20,
"inter_sen_cal":10,
"outer_sen_cal":30,
"outer_sen_top":55,
"Mon":"06:00_044C,08:00_030C,11:00_044C,12:30_030C,17:00_044C,22:00_030C",
"Tues":"06:00_044C,08:00_030C,11:00_044C,12:30_030C,17:00_044C,22:00_030C",
"Wed":"06:00_044C,08:00_030C,11:00_044C,12:30_030C,17:00_044C,22:00_030C",
"Thur":"06:00_044C,08:00_030C,11:00_044C,12:30_030C,17:00_044C,22:00_030C",
"Fri":"06:00_044C,08:00_030C,11:00_044C,12:30_030C,17:00_044C,22:00_030C",
"Sat":"06:00_044C,08:00_044C,11:00_044C,12:30_044C,17:00_044C,22:00_030C",
"Sun":"06:00_044C,08:00_044C,11:00_044C,12:30_044C,17:00_044C,22:00_030C"
}
}
}

air_tem ist die aktuelle Lufttemperatur *10
set_tem ist die Zieltemperatur * 2

Es spielen auch noch die folgenden Topics in der Kommunikation eine Rolle, Details dazu noch in Arbeit:

Gerät meldet sich beim nächsten Einschalten:
Topic: WeBack/LWT/device_change/device_offline (kommt nicht bei längerer Zeit stromlos)
{"Thing_Name":"<thermostat id>","connected":"false"}
Kommt bei jedem Einschalten:
Topic: $aws/things/<thermostat id>/shadow/update
{"state":{"desired":null, "reported":{"connected":"true","config_app":"WeBack","firmware_version":"3.1.2rel"}}}
Kommt bei jedem Einschalten:
Topic: WeBack/device_change/notify_from_device
{
"Notify_Reason": "timestamp_sync_req",
"Thing_Name": "<thermostat id>",
"Offset_Hours": 0,
"Offset_Minutes": 0
}

<thermostat id> entspricht "by-t03-aa-bb-cc-dd-ee-ff" mit aa-bb-cc-dd-ee-ff = MAC des ESP