[gelöst] MAX! Thermostate über aculfw (auf MAX!Cube) einbinden und mit iobroker (hm.rpc) steuern

Ich möchte gerne meine Max! Thermostate in iobroker integrieren.

Einen Max!Cube habe ich mit aculfw geflasht und der läuft jetzt als CUN. In homegear habe ich 4 Thermostate mit dem CUN gepaired. Die Verbindung zwischen homegear und iobroker läuft über den iobroker Adapter hm.rpc. Dort kann ich die Thermostate auch sehen. Allerdings erhalte ich weder Werte, noch kann ich irgendetwas steuern.

Nach ein wenig Lektüre hier im Forum habe ich mir jetzt mosquitto und node-red installiert in der Hoffnung, daß ich damit weiterkomme.

Unter node-red habe ich noch node-red-contrib-homegear-mqtt installiert, aber das kann wohl mit den Max! Thermostaten nicht umgehen.

Ich brauche wohl noch einen Stoß in die richtige Richtung…

Erstes Ziel wäre, mit meinen Xiaomi Fensterkontakten (Zigbee) die Heizkörper wegzuschalten.

Hier solltest du fündig werden: https://allgeek.de/2017/07/09/homematic-mit-node-red-ueber-homegear/

Schau dir auch mal node-blue an - das ist das homegear-node-red :wink:
node-red-contrib-homegear-mqtt wird glaube ich länger nicht mehr gepflegt. Da möge man mich aber korrigieren.

Homegear verhält sich nach Außen aber komplett wie eine echte CCU und bildet jedes ihm bekannte Gerät als Homematic-Gerät ab. Du solltest also alle Werte bekommen.
Deine Max-Thermostate senden nicht ständig - da soll ja soweit wie möglich Batterie gespart werden. Was passiert wenn du die Temperatur eines Thermostats änderst? Kommt dein ein Wert bei deiner jetzigen Config mit io.broker und dem hm.rpc-Adapter an?

Hmm, irgendwas passt da in meinem System noch nicht.

Ich habe iobroker mit hm.rpc am Laufen. Und unter homegear habe ich die Thermostaten angelernt. Irgendwie passt die Schnittstelle noch nicht. Der Adapter hm.rpc lässt sich manchmal auch nicht starten. Mir sind die Einstellungen für hm.rpc auch nicht so ganz klar und habe damit auch schon rumgespielt, aber viel schlauer bin ich da jetzt auch nicht geworden.

Vielleicht muß ich die Thermostaten auch nochmal aus dem iobroker entfernen und neu erkennen, damit das funzt.

Jedenfalls sehe ich die Thermostaten mit ihren 4 Channels, wobei nur die Channels 0 und 1 items enthalten - da passt mMn auch soweit. Aber ich kann z.B. die Temperatur eines Thermostaten weder lesen (es wird nichts angezeigt) noch schreiben. Auch nach Änderung der Temp an den Thermostaten, wird im iobroker kein Wert angezeigt.

Beim Versuch, die Comfort Temp. zu schreiben bekomme ich im log:

2019-06-16 13:29:46.933 - error: hm-rpc.0 binrpc -> setValue ["1","COMFORT_TEMPERATURE",9] FLOAT
2019-06-16 13:29:46.934 - error: hm-rpc.0 Error: response timeout

Node-blue scheint jawohl zu reichen, dann werden ich node-red mal wieder deinstallieren. Danke für den Tipp.

Nochmal eben das komplette log vom Start des Adapters hm.rpc - vielleicht kann damit jemand was anfangen!?

2019-06-16 13:29:02.016 - info: hm-rpc.0 starting. Version 1.9.12 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v8.16.0
2019-06-16 13:29:02.421 - info: hm-rpc.0 binrpc server is trying to listen on 192.168.7.10:4000
2019-06-16 13:29:02.422 - info: hm-rpc.0 binrpc client is trying to connect to 192.168.7.10:2001/ with ["xmlrpc_bin://192.168.7.10:4000","hm-rpc.0"]
2019-06-16 13:29:02.949 - info: hm-rpc.0 binrpc -> listDevices 20
2019-06-16 13:29:02.962 - info: hm-rpc.0 new CUxD devices/channels after filter: 0
2019-06-16 13:29:02.967 - info: hm-rpc.0 Connected
2019-06-16 13:29:03.115 - info: hm-rpc.0 binrpc <- system.listMethods []
2019-06-16 13:29:03.125 - info: hm-rpc.0 binrpc <- listDevices ["hm-rpc.0"]
2019-06-16 13:29:03.136 - info: hm-rpc.0 binrpc -> 20 devices
2019-06-16 13:29:41.923 - info: mqtt.0 send2Server hm-rpc.0.OEQ1205605.1.COMFORT_TEMPERATURE[hm-rpc/0/OEQ1205605/1/COMFORT_TEMPERATURE]
2019-06-16 13:29:46.933 - error: hm-rpc.0 binrpc -> setValue ["1","COMFORT_TEMPERATURE",9] FLOAT
2019-06-16 13:29:46.934 - error: hm-rpc.0 Error: response timeout

Leider bin ich absolute io.Broker noob und kann dir da nicht helfen. Leider verstehe ich auch den MQTT-Zusammehang nicht (Log) da du ja mit dem Adapter per RPC kommunizieren solltest.

Du könntest zumindest mal deinen Mosquitto installiert lassen und per mqtt-spy (o.ä.) mal schauen ob den Homegear per MQTT Wertänderungen mitbekommt. Dann kannst du ausschließen, dass es an homegear liegt und bei io.Broker weitersuchen.
Was steht in der mqtt.conf von Homegear?

//edit:
äähmm, die Temperatur wird auch nicht auf COMFORT_TEMPERATURE geschrieben sondern auf SET_TEMPERATURE

COMFORT_TEMPERATURE ist glaube für die Temperatur für AUTO_MODE
Die aktuelle Temperatur findest du unter ACTUAL_TEMPERATURE

Danke für deine Hilfe!

Den mqtt habe ich gestern noch zusätzlich installiert, weil du in deinen posts hier berichtet hast, daß du mit deinen Geräten komplett über mqtt kommunizierst…

mqtt.conf:

# mqtt.conf
#
# MQTT settings.
#

# Set this to "true" to enable MQTT.
# Default: false
##enabled = false
enabled = true

# Hostname or IP address of your MQTT message broker.
brokerHostname = localhost

# Port of your MQTT message broker.
brokerPort = 1883

# Name of this client.
clientName = Homegear

# The prefix to use. Every topic starts with this prefix.
# Default: homegear
prefix = homegear

# Unique ID of this Homegear instance. Change this, have you have multiple
# Homegear installations.
# This is not used for IBM Bluemix Watson IOT platform
homegearId = 1234-5678-9abc

# Tells the MQTT server to retain received MQTT messages. New clients will then
# receive the last value of a topic on connection.
# Variables of type "Action" are not retained.
retain = true

# When authentication by username and password is enabled, uncomment the following two lines and fill in your username
# and password.
#username = myUser
#password = myPassword

# The number of parallel processing threads.
processingThreadCount = 5

### Topic payload encodings ###

# Enable topic: homegear/HOMEGEAR_ID/plain/PEERID/CHANNEL/VARIABLE_NAME
# Contains the value as is. E. g.: 43.7.
plainTopic = true

# Enable topic: homegear/HOMEGEAR_ID/json/PEERID/CHANNEL/VARIABLE_NAME
# Puts the value in a JSON array to be JSON-compliant: [43.7].
jsonTopic = true

# Enable topic: homegear/HOMEGEAR_ID/jsonobj/PEERID/CHANNEL/VARIABLE_NAME
# Puts the value into a JSON object. The key is value: { "value": 43.7 }.
jsonobjTopic = true


### TLS options ###

# Set to "true" to enable SSL encryption for MQTT.
enableSSL = false

# The path to the certificate authority's certificate
#caFile = /path/to/ca-certficate

# verifyCertificate checks if the server certificate received by the
# MQTT broker is signed by one of the root CAs in /etc/ssl/certs. If you use
# a self signed certificate, please put your root certificate in that
# directory. Only disable the verification for testing purposes. Without
# verification any attacker can pose as your MQTT broker.
# Default: verifyCertificate = true
#verifyCertificate = true

# The path to the PEM encoded client certificate.
#certPath = /etc/homegear/mqtt.crt

# The path to the PEM encoded client keyfile.
#keyPath = /etc/homegear/mqtt.key


### IBM Bluemix Watson IOT platform settings ###

# Uses bmx*, retain, processingThreadCount and TLS settings, all others are skipped. Please note that it was tested without TLS encryption only.
# bmxTopix enables IBM Bluemix adapter and blocks all other topic types as IBM Bluemix Watson IOT Platform disconnects when unsupported packet types appear
#bmxTopic = false

# For IBM Bluemix Watson IOT Platform use messaging.internetofthings.ibmcloud.com, do not add the <orgId> at the beginning
#bmxHostname=messaging.internetofthings.ibmcloud.com

# Port for MQTT broker
#bmxPort = 1883

# Set this to your orgId created in Bluemix
#bmxOrgId = orgId

# Set this to your gateway typeId created in Bluemix. This has to be created as "gateway type", not "device type"
#bmxGwTypeId = gwTypeId

# This sets the device ID for devices created by MQTT adapter in Bluemix. Requested device type is created automatically by IOT platform.
#bmxDevTypeId = devTypeId

# Should be set to "iot-2/type"
#bmxPrefix = iot-2/type

# Set to use-token-auth if using token authentication
#bmxUsername = use-token-auth

# Set to token generated for this gateway
#bmxToken = myBluemixToken

Der hostname vom Raspberry ist übrigens “raspberrypi”.

Ok, ich werde dann mal SET_TEMPERATURE testen. Aber ACTUAL_TEMPERATURE ist halt auch leer (kein Wert).

//Edit: bringt auch nichts.

Ich denke, daß die hm Adapter von iobroker nur auf eine CCU zugreifen können. Ich hatte angenommen, daß die auch auf homegear (quasi als Ersatz für eine CCU) zugreifen können und ich keine CCU (piVCC) benötige…

Schau bitte mal was homegear per mqtt zur Verfügung stellt (mqtt-spy oder mqtt.fx und dann # subscriben).

Und du kannst mal über die Homegear Konsole gucken, was Homegear an Werten hat und was sich ändert, wenn du die Temperatur am Thermostat änderst:

sudo homegear -r
fs 4
ls
ps <device-id>
config print

Da sind die Werte allerdings Hex und müssen umgerechnet werden. Stand hier im Forum, hab ich grade nicht im Kopf.

Family 4 - peer 4> config print
MASTER
{
	Channel: 0
	{
		[TEMPERATURE_WEDNESDAY_9]: 22 
		[TEMPERATURE_WEDNESDAY_6]: 22 
		[TEMPERATURE_WEDNESDAY_5]: 22 
		[TEMPERATURE_WEDNESDAY_4]: 2a 
		[TEMPERATURE_WEDNESDAY_2]: 2a 
		[TEMPERATURE_WEDNESDAY_12]: 22 
		[TEMPERATURE_WEDNESDAY_1]: 22 
		[TEMPERATURE_TUESDAY_9]: 22 
		[TEMPERATURE_TUESDAY_8]: 22 
		[TEMPERATURE_TUESDAY_6]: 22 
		[TEMPERATURE_TUESDAY_4]: 2a 
		[TEMPERATURE_TUESDAY_12]: 22 
		[TEMPERATURE_TUESDAY_10]: 22 
		[TEMPERATURE_TUESDAY_1]: 22 
		[TEMPERATURE_THURSDAY_7]: 22 
		[TEMPERATURE_THURSDAY_6]: 22 
		[TEMPERATURE_THURSDAY_4]: 2a 
		[TEMPERATURE_THURSDAY_3]: 22 
		[TEMPERATURE_THURSDAY_2]: 2a 
		[TEMPERATURE_THURSDAY_13]: 22 
		[TEMPERATURE_TUESDAY_3]: 22 
		[TEMPERATURE_THURSDAY_10]: 22 
		[TEMPERATURE_THURSDAY_1]: 22 
		[TEMPERATURE_SUNDAY_9]: 22 
		[TEMPERATURE_THURSDAY_11]: 22 
		[TEMPERATURE_SUNDAY_8]: 22 
		[TEMPERATURE_WEDNESDAY_3]: 22 
		[TEMPERATURE_SUNDAY_5]: 22 
		[TEMPERATURE_SUNDAY_4]: 22 
		[TEMPERATURE_SUNDAY_13]: 22 
		[TEMPERATURE_SUNDAY_11]: 22 
		[TEMPERATURE_SUNDAY_10]: 22 
		[TEMPERATURE_SUNDAY_1]: 22 
		[TEMPERATURE_SATURDAY_9]: 22 
		[TEMPERATURE_THURSDAY_12]: 22 
		[TEMPERATURE_SATURDAY_6]: 22 
		[TEMPERATURE_TUESDAY_2]: 2a 
		[TEMPERATURE_SATURDAY_5]: 22 
		[TEMPERATURE_SATURDAY_3]: 22 
		[TEMPERATURE_SATURDAY_2]: 2a 
		[TEMPERATURE_SATURDAY_13]: 22 
		[TEMPERATURE_SATURDAY_10]: 22 
		[TEMPERATURE_WEDNESDAY_8]: 22 
		[TEMPERATURE_SATURDAY_1]: 22 
		[TEMPERATURE_SUNDAY_12]: 22 
		[TEMPERATURE_MONDAY_9]: 22 
		[TEMPERATURE_MONDAY_8]: 22 
		[TEMPERATURE_MONDAY_6]: 22 
		[TEMPERATURE_MONDAY_5]: 22 
		[TEMPERATURE_MONDAY_4]: 2a 
		[TEMPERATURE_MONDAY_12]: 22 
		[TEMPERATURE_WEDNESDAY_7]: 22 
		[TEMPERATURE_TUESDAY_5]: 22 
		[TEMPERATURE_SUNDAY_2]: 2a 
		[TEMPERATURE_MONDAY_11]: 22 
		[TEMPERATURE_MONDAY_10]: 22 
		[TEMPERATURE_MONDAY_1]: 22 
		[TEMPERATURE_FRIDAY_8]: 22 
		[TEMPERATURE_FRIDAY_7]: 22 
		[TEMPERATURE_FRIDAY_4]: 2a 
		[TEMPERATURE_SUNDAY_6]: 22 
		[TEMPERATURE_SATURDAY_8]: 22 
		[TEMPERATURE_FRIDAY_2]: 2a 
		[TEMPERATURE_TUESDAY_13]: 22 
		[ENDTIME_FRIDAY_1]: 48 
		[ENDTIME_FRIDAY_12]: 01 20 
		[ENDTIME_SUNDAY_1]: 48 
		[ENDTIME_SATURDAY_9]: 01 20 
		[TEMPERATURE_SATURDAY_11]: 22 
		[ENDTIME_SATURDAY_6]: 01 20 
		[ENDTIME_MONDAY_2]: 6c 
		[ENDTIME_SATURDAY_12]: 01 20 
		[ENDTIME_MONDAY_12]: 01 20 
		[ENDTIME_SATURDAY_8]: 01 20 
		[TEMPERATURE_FRIDAY_11]: 22 
		[ENDTIME_FRIDAY_7]: 01 20 
		[ENDTIME_SATURDAY_5]: 01 20 
		[TEMPERATURE_FRIDAY_13]: 22 
		[ENDTIME_MONDAY_1]: 48 
		[ENDTIME_WEDNESDAY_13]: 01 20 
		[TEMPERATURE_THURSDAY_9]: 22 
		[TEMPERATURE_MONDAY_3]: 22 
		[ENDTIME_SATURDAY_1]: 48 
		[ENDTIME_SATURDAY_4]: 01 20 
		[ENDTIME_MONDAY_9]: 01 20 
		[ENDTIME_SATURDAY_7]: 01 20 
		[ENDTIME_SUNDAY_6]: 01 20 
		[TEMPERATURE_WEDNESDAY_13]: 22 
		[ENDTIME_MONDAY_8]: 01 20 
		[ENDTIME_MONDAY_7]: 01 20 
		[ENDTIME_WEDNESDAY_4]: 01 14 
		[ENDTIME_FRIDAY_5]: 01 20 
		[ENDTIME_WEDNESDAY_5]: 01 20 
		[ENDTIME_SUNDAY_3]: 01 20 
		[ENDTIME_FRIDAY_2]: 6c 
		[ENDTIME_SUNDAY_10]: 01 20 
		[ENDTIME_SATURDAY_10]: 01 20 
		[ENDTIME_SATURDAY_11]: 01 20 
		[ENDTIME_FRIDAY_11]: 01 20 
		[ENDTIME_TUESDAY_3]: cc 
		[ENDTIME_FRIDAY_3]: cc 
		[ENDTIME_THURSDAY_8]: 01 20 
		[ENDTIME_TUESDAY_7]: 01 20 
		[ENDTIME_MONDAY_10]: 01 20 
		[TEMPERATURE_FRIDAY_3]: 22 
		[ENDTIME_THURSDAY_13]: 01 20 
		[TEMPERATURE_SUNDAY_3]: 22 
		[ENDTIME_WEDNESDAY_1]: 48 
		[ENDTIME_FRIDAY_10]: 01 20 
		[TEMPERATURE_FRIDAY_9]: 22 
		[ENDTIME_TUESDAY_1]: 48 
		[ENDTIME_THURSDAY_3]: cc 
		[TEMPERATURE_FRIDAY_6]: 22 
		[ENDTIME_FRIDAY_8]: 01 20 
		[TEMPERATURE_THURSDAY_5]: 22 
		[ENDTIME_SUNDAY_5]: 01 20 
		[ENDTIME_SUNDAY_13]: 01 20 
		[TEMPERATURE_WEDNESDAY_11]: 22 
		[TEMPERATURE_FRIDAY_5]: 22 
		[ENDTIME_THURSDAY_10]: 01 20 
		[ENDTIME_SUNDAY_2]: 01 08 
		[ENDTIME_FRIDAY_6]: 01 20 
		[ENDTIME_THURSDAY_12]: 01 20 
		[TEMPERATURE_SATURDAY_12]: 22 
		[ENDTIME_SUNDAY_11]: 01 20 
		[ENDTIME_MONDAY_13]: 01 20 
		[TEMPERATURE_TUESDAY_11]: 22 
		[ENDTIME_SATURDAY_3]: 01 20 
		[TEMPERATURE_TUESDAY_7]: 22 
		[ENDTIME_FRIDAY_9]: 01 20 
		[ENDTIME_MONDAY_4]: 01 14 
		[ENDTIME_THURSDAY_1]: 48 
		[TEMPERATURE_SUNDAY_7]: 22 
		[TEMPERATURE_MONDAY_7]: 22 
		[ENDTIME_MONDAY_11]: 01 20 
		[ENDTIME_SATURDAY_2]: 01 08 
		[ENDTIME_MONDAY_5]: 01 20 
		[ENDTIME_SUNDAY_4]: 01 20 
		[TEMPERATURE_MONDAY_2]: 2a 
		[ENDTIME_SUNDAY_7]: 01 20 
		[ENDTIME_TUESDAY_2]: 6c 
		[ENDTIME_FRIDAY_13]: 01 20 
		[ENDTIME_SUNDAY_8]: 01 20 
		[ENDTIME_SUNDAY_9]: 01 20 
		[ENDTIME_THURSDAY_11]: 01 20 
		[ENDTIME_THURSDAY_6]: 01 20 
		[ENDTIME_THURSDAY_2]: 6c 
		[ENDTIME_MONDAY_6]: 01 20 
		[ENDTIME_THURSDAY_4]: 01 14 
		[ENDTIME_THURSDAY_5]: 01 20 
		[ENDTIME_THURSDAY_7]: 01 20 
		[ENDTIME_THURSDAY_9]: 01 20 
		[ENDTIME_TUESDAY_8]: 01 20 
		[ENDTIME_FRIDAY_4]: 01 14 
		[ENDTIME_WEDNESDAY_10]: 01 20 
		[ENDTIME_WEDNESDAY_2]: 6c 
		[TEMPERATURE_WEDNESDAY_10]: 22 
		[ENDTIME_WEDNESDAY_6]: 01 20 
		[ENDTIME_TUESDAY_10]: 01 20 
		[ENDTIME_TUESDAY_11]: 01 20 
		[TEMPERATURE_MONDAY_13]: 22 
		[ENDTIME_SATURDAY_13]: 01 20 
		[ENDTIME_WEDNESDAY_3]: cc 
		[ENDTIME_TUESDAY_12]: 01 20 
		[ENDTIME_TUESDAY_13]: 01 20 
		[ENDTIME_TUESDAY_6]: 01 20 
		[ENDTIME_TUESDAY_4]: 01 14 
		[ENDTIME_TUESDAY_5]: 01 20 
		[ENDTIME_TUESDAY_9]: 01 20 
		[ENDTIME_WEDNESDAY_8]: 01 20 
		[TEMPERATURE_SATURDAY_4]: 22 
		[ENDTIME_WEDNESDAY_11]: 01 20 
		[ENDTIME_MONDAY_3]: cc 
		[ENDTIME_WEDNESDAY_12]: 01 20 
		[TEMPERATURE_THURSDAY_8]: 22 
		[TEMPERATURE_FRIDAY_12]: 22 
		[TEMPERATURE_SATURDAY_7]: 22 
		[ENDTIME_WEDNESDAY_7]: 01 20 
		[ENDTIME_WEDNESDAY_9]: 01 20 
		[TEMPERATURE_FRIDAY_1]: 22 
		[ENDTIME_SUNDAY_12]: 01 20 
		[TEMPERATURE_FRIDAY_10]: 22 
	}
}

VALUES
{
	Channel: 1
	{
		[TEMPERATURE_OFFSET]: 07 
		[PARTY_TEMPERATURE]: 28 
		[SET_TEMPERATURE]: 3d 
		[PARTY_STOP_YEAR]: 0c 
		[PARTY_STOP_MONTH]: 01 
		[PARTY_STOP_TIME]: 00 
		[PARTY_STOP_DAY]: 01 
		[MAX_TEMPERATURE]: 3d 
		[MANU_MODE]: 28 
		[LOCKED]: 00 
		[BOOST_POSITION]: 10 
		[VALVE_STATE]: 0c 
		[ECO_TEMPERATURE]: 21 
		[BOOST_MODE]: 01 
		[AUTO_MODE]: 01 
		[ACTUAL_TEMPERATURE]: 00 df 
		[WINDOW_OPEN_TEMPERATURE]: 18 
		[BOOST_TIME_PERIOD]: 01 
		[DECALCIFICATION_WEEKDAY]: 00 
		[CONTROL_MODE]: 01 
		[COMFORT_TEMPERATURE]: 12 
		[DECALCIFICATION_TIME]: 16 
	}
	Channel: 0
	{
		[UNREACH]: 00 
		[STICKY_UNREACH]: 01 
		[RSSI_DEVICE]: 00 
		[BOOT]: 00 
		[LAST_PACKET_RECEIVED]: 5d 05 25 ac 
		[LOWBAT]: 00 
		[RSSI_PEER]: 00 
		[CONFIG_PENDING]: 00 
	}
}

LINK
{
}

Ändert sich denn [ACTUAL_TEMPERATURE]: 00 df wenn du das Thermostat verstellst?

Nein, leider nicht.

Hmm… das dauert einen Moment. Wie gesagt, die Thermostate senden nicht direkt. Es gilt Energiesparen und die 1%-Regel. Warte mal ein paar Minuten.

Schau dir das Ganze auch mal per MQTT an und was sagt das Homegear-Log auf LogLevel 5? Wird da angezeigt, dass ein Max-Paket empfangen wird, wenn du die Temperatur am Thermostat änderst?

Das Loglevel kannst du im laufenden Betrieb umstellen in der homegear-Konsole mit dl 5. dl 3 oder homegear-restart schaltet wieder auf “Normalzustand”.

Ich habe mal an einem Thermostaten gedreht, nachdem ich das log auf dl 5 gestellt habe:

pi@raspberrypi:~ $ sudo tail -f /var/log/homegear/homegear.log
    06/16/19 15:27:33.495 MQTT Client Info: Publishing topic   homegear/1234-5678-9abc/jsonobj/0/-1
    06/16/19 15:27:38.291 HomeMatic BidCoS packet received (My-CUNX, RSSI: -74 dBm): 09012600000006000000
    06/16/19 15:27:38.537 MAX packet received (My-CUNX, RSSI: 0x4A): 0900060600000A00000F
    06/16/19 15:27:48.609 IPC Server: Info: Connection accepted. Client number: 537
    06/16/19 15:27:48.610 IPC Server: Info: Client 4 successfully registered RPC method "cliOutput" (this method is registered by 1 client(s)).
    06/16/19 15:27:48.611 IPC Server: Info: Client 4 successfully registered RPC method "cliOutput-4" (this method is registered by 1 client(s)).
    06/16/19 15:27:56.473 IPC Server: Response: 
    (String) Debug level set to 5.

06/16/19 15:27:59.593 IPC Server: Info: Connection to IPC server's client number 537 closed.
06/16/19 15:28:08.515 Debug (My-CUNX): Packet 09012600000006000000 enters raisePacketReceived.
06/16/19 15:28:08.515 Debug (My-CUNX): Packet 09012600000006000000 is now passed to the EventHandler.
06/16/19 15:28:08.514 HomeMatic BidCoS packet received (My-CUNX, RSSI: -74 dBm): 09012600000006000000
06/16/19 15:28:08.516 Debug (My-CUNX): Packet 0900060600000A00000F enters raisePacketReceived.
06/16/19 15:28:08.516 Debug (My-CUNX): Packet processing of packet 09012600000006000000 took 1 ms.
06/16/19 15:28:08.516 Debug (My-CUNX): Packet 0900060600000A00000F is now passed to the EventHandler.
06/16/19 15:28:08.514 MAX packet received (My-CUNX, RSSI: 0x4A): 0900060600000A00000F
06/16/19 15:28:08.517 Debug (My-CUNX): Packet processing of packet 0900060600000A00000F took 1 ms.
06/16/19 15:28:14.980 Debug: MQTT packet received: D000
06/16/19 15:28:14.980 MQTT Client: Debug: Packet received: D000
06/16/19 15:28:14.980 MQTT Client: Debug: Received ping response.
06/16/19 15:28:33.093 UPnP Server: Debug: Sending notify packets.
06/16/19 15:28:34.983 Debug: MQTT packet received: D000
06/16/19 15:28:34.983 MQTT Client: Debug: Packet received: D000
06/16/19 15:28:34.983 MQTT Client: Debug: Received ping response.
06/16/19 15:28:38.492 Debug (My-CUNX): Packet 09012600000006000000 enters raisePacketReceived.
06/16/19 15:28:38.493 Debug (My-CUNX): Packet 09012600000006000000 is now passed to the EventHandler.
06/16/19 15:28:38.491 HomeMatic BidCoS packet received (My-CUNX, RSSI: -74 dBm): 09012600000006000000
06/16/19 15:28:38.496 Debug (My-CUNX): Packet processing of packet 09012600000006000000 took 4 ms.
06/16/19 15:28:38.738 Debug (My-CUNX): Packet 0900060600000A00000F enters raisePacketReceived.
06/16/19 15:28:38.739 Debug (My-CUNX): Packet 0900060600000A00000F is now passed to the EventHandler.
06/16/19 15:28:38.738 MAX packet received (My-CUNX, RSSI: 0x4A): 0900060600000A00000F
06/16/19 15:28:38.739 Debug (My-CUNX): Packet processing of packet 0900060600000A00000F took 0 ms.
06/16/19 15:28:39.357 IPC Server: Info: IPC client 4 removed.
06/16/19 15:28:54.985 Debug: MQTT packet received: D000
06/16/19 15:28:54.985 MQTT Client: Debug: Packet received: D000
06/16/19 15:28:54.985 MQTT Client: Debug: Received ping response.
06/16/19 15:29:03.506 RPC Server (Port 2001): Debug: Packet received: 42696E000000001C0000000470696E67000000010000000300000008686D2D7270632E30
06/16/19 15:29:03.507 RPC Server (Port 2001): Info: Client number 447 is calling RPC method: ping (2) Parameters:
(String) hm-rpc.0
06/16/19 15:29:03.508 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=0, channel=-1, keys, values
06/16/19 15:29:03.508 MQTT Client: Debug: queueMessage (message) topic: json/0/-1/PONG message:["hm-rpc.0"]
06/16/19 15:29:03.508 MQTT Client Info: Publishing topic   homegear/1234-5678-9abc/json/0/-1/PONG
06/16/19 15:29:03.509 MQTT Client: Debug: Sending: 33360026686F6D65676561722F313233342D353637382D396162632F6A736F6E2F302F2D312F504F4E4701665B22686D2D7270632E30225D
06/16/19 15:29:03.509 MQTT Client: Debug: queueMessage (message) topic: plain/0/-1/PONG message:hm-rpc.0
06/16/19 15:29:03.509 MQTT Client: Debug: queueMessage (message) topic: jsonobj/0/-1 message:{"PONG":"hm-rpc.0"}
06/16/19 15:29:03.509 Debug: MQTT packet received: 40020166
06/16/19 15:29:03.510 MQTT Client: Debug: Packet received: 40020166
06/16/19 15:29:03.510 MQTT Client: Debug: Received PUBACK.
06/16/19 15:29:03.510 RPC client: Debug: Calling RPC method "system.multicall" on server 192.168.7.10.
06/16/19 15:29:03.510 RPC client: Parameters:
06/16/19 15:29:03.510 RPC Server (Port 2001): Response: 
(Boolean) 1
06/16/19 15:29:03.510 RPC Server (Port 2001): Response binary:
(Array length=1)
[
  (Struct length=2)
  {
    [methodName] (String) event
    [params] (Array length=4)
    [
      (String) hm-rpc.0
      (String) CENTRAL
      (String) PONG
      (String) hm-rpc.0
    ]
  }
]
42696E01000000050000000201
06/16/19 15:29:03.510 Debug: Calling getFileDescriptor...
06/16/19 15:29:03.510 Debug: Connecting to host 192.168.7.10 on port 4000...
06/16/19 15:29:03.511 Debug: Connected to host 192.168.7.10 on port 4000. Client number is: 538
06/16/19 15:29:03.512 RPC client: Debug: Sending packet: 42696E00000000900000001073797374656D2E6D756C746963616C6C00000001000001000000000100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D7300000100000000040000000300000008686D2D7270632E30000000030000000743454E5452414C0000000300000004504F4E470000000300000008686D2D7270632E30
06/16/19 15:29:03.513 MQTT Client Info: Publishing topic   homegear/1234-5678-9abc/plain/0/-1/PONG
06/16/19 15:29:03.513 MQTT Client: Debug: Sending: 33330027686F6D65676561722F313233342D353637382D396162632F706C61696E2F302F2D312F504F4E470167686D2D7270632E30
06/16/19 15:29:03.514 Debug: MQTT packet received: 40020167
06/16/19 15:29:03.514 MQTT Client: Debug: Packet received: 40020167
06/16/19 15:29:03.515 MQTT Client: Debug: Received PUBACK.
06/16/19 15:29:03.515 MQTT Client Info: Publishing topic   homegear/1234-5678-9abc/jsonobj/0/-1
06/16/19 15:29:03.515 MQTT Client: Debug: Sending: 333B0024686F6D65676561722F313233342D353637382D396162632F6A736F6E6F626A2F302F2D3101687B22504F4E47223A22686D2D7270632E30227D
06/16/19 15:29:03.516 Debug: MQTT packet received: 40020168
06/16/19 15:29:03.516 MQTT Client: Debug: Packet received: 40020168
06/16/19 15:29:03.516 MQTT Client: Debug: Received PUBACK.
06/16/19 15:29:03.522 RPC client: Debug: Packet received: 42696E010000001000000100000000010000000300000000
06/16/19 15:29:03.529 RPC client: Debug: Received packet from server 192.168.7.10: 42696E010000001000000100000000010000000300000000
06/16/19 15:29:03.530 RPC client: Response was:
(Array length=1)
[
  (String) 
]
06/16/19 15:29:08.715 Debug (My-CUNX): Packet 0900060600000A00000F enters raisePacketReceived.
06/16/19 15:29:08.716 Debug (My-CUNX): Packet 0900060600000A00000F is now passed to the EventHandler.
06/16/19 15:29:08.715 MAX packet received (My-CUNX, RSSI: 0x4A): 0900060600000A00000F
06/16/19 15:29:08.716 Debug (My-CUNX): Packet processing of packet 0900060600000A00000F took 0 ms.
06/16/19 15:29:08.716 Debug (My-CUNX): Packet 09012600000006000000 enters raisePacketReceived.
06/16/19 15:29:08.716 Debug (My-CUNX): Packet 09012600000006000000 is now passed to the EventHandler.
06/16/19 15:29:08.715 HomeMatic BidCoS packet received (My-CUNX, RSSI: -74 dBm): 09012600000006000000
06/16/19 15:29:08.717 Debug (My-CUNX): Packet processing of packet 09012600000006000000 took 1 ms.
06/16/19 15:29:14.987 Debug: MQTT packet received: D000
06/16/19 15:29:14.988 MQTT Client: Debug: Packet received: D000
06/16/19 15:29:14.992 MQTT Client: Debug: Received ping response.![Bildschirmfoto%20zu%202019-06-16%2015-52-30|625x500](upload://8HvFc8Skfuh10wVmHuEoGZUCCG4.png)

mqtt.txt (12,3 KB)

Das sieht doch gut aus, oder?

Wenn ja, würde ich sagen, dass mit dem Adapter von io.Broker irgendwas nicht richtig ist.

Ja, eigentlich schon. Aber egal was ich an Werten geschrieben habe, es kam nicht bei den Thermostaten an.

Also habe ich mal alle Thermostate gelöscht (man sollte auch nur mit einem anfangen, wenn man das das erste Mal macht…) und einen neu angelernt (vorher Werksreset). Und jetzt gehts - ohne MQTT, sondern mit dem Adapter hm.rpc.

Ich kann Werte schreiben und die kommen am Thermostat an.

Jetzt kämpfe ich nur noch mit dem Regelverhalten der Thermostaten.

Über iobroker kann ich (grafisch) SET_TEMPERATURE nur “On” bzw. “Off” schalten - also binär (im Kommentar steht da dann “Off - 4.5°”, “On - 30.5”). Über ein Skript kann ich nen Real (float) senden, also z.B. “25.5”. Wenn ich aber “30.5” sende, sollte nach meinem Verständnis dann “On” am Thermostat angezeigt werden. Stattdessen wird “30” angezeigt. Aber das werde ich wohl auch über probieren herausfinden, oder ich mache nen neuen thread auf.

Das eigentliche Problem ist erledigt.

Vielen Dank für deine Hilfe @pmayer

1 Like

Setzen von Werten sollte aber ohne Probleme auch über MQTT funktionieren. Muss aber in das entsprechende Topich geschrieben werden (Siehe Blogartikel).
Du kannst nicht auf die Werte schreiben, die du in plain liest.

Aber super, dass es funktioniert.

Damit hast du absolut recht!

On wird nicht am Thermostat angezeigt, nur Off. Durch das Senden von 31.5 wird einfach die zuvor eingestellte - oder durch den Zeitplan vorgesehene Temperatur - “wiederhergestellt”.

1 Like

On wird nicht am Thermostat angezeigt, nur Off . Durch das Senden von 31.5 wird einfach die zuvor eingestellte - oder durch den Zeitplan vorgesehene Temperatur - “wiederhergestellt”.

Wenn ich über iobroker SET_TEMPERATURE auf ‘On’ schalte, wird das schon am Thermostat angezeigt. Ebenso, wenn ich manuell aufdrehe und die 30 überschreite.

Ich werde mal die Suche bemühen. Die Programmierung der MAX!Thermostate ist ja bestimmt irgendwo beschrieben.

1 Like

Stimmt… das hatte ich völlig verdrängt… Dann drehen sie ganz auf.
Ok, ich mach dann mal hier zu.