MQTT commands not received

I managed to set up homegear and the MQTT publishing, however the commands sent to homegear in MQTT are not working
with the command mosquitto_pub -t homegear/climate/set/1/1/SET_TEMPERATURE -m 22 nothing happens on my radiator vane (peer 1)
but docker exec -it homegear homegear -e rc '$hg->setValue("OKF0003066:1", "SET_TEMPERATURE", 22.0);'works, so the link with the vane is working
on the topic homegear/climate/plain/1/1 I can see all the published values
for information, the list of peers in homegear:

      ID │ Name                      │ Address │ Serial Number │ Type │ Type String               │ Firmware │ Unreach
         │                           │         │               │      │                           │          │        
       1 │                           │  1B8F6F │    OKF0003066 │ 01A1 │ BC-RT-TRX-CyN             │      1.1 │      No

also here is the output of the homegear.log when I send a command in MQTT:

04/11/19 20:28:18.026 Info: REST RPC call received. Method: getValue
04/11/19 20:28:18.027 RPC Server (Port 2001): Debug: Connection to client number 169 closed.
04/11/19 20:28:18.028 RPC Server (Port 2001): Debug: Connection to client number 169 closed (1).
04/11/19 20:28:18.053 RPC Server (Port 2001): Info: Connection from ::ffff: accepted. Client number: 170
04/11/19 20:28:18.054 RPC Server (Port 2001): Info: RPC server client id for client number 170 is: 84
04/11/19 20:28:18.057 RPC Server (Port 2001): Listening for incoming packets from client number 170.
04/11/19 20:28:18.058 RPC Server (Port 2001): Debug: Packet received: 474554202F6170692F76312F7661726961626C652F312F312F434F4D464F52545F54454D504552415455524520485454502F312E310D0A486F73743A203139322E3136382E312E3130303A323030310D0A4163636570742D456E636F64696E673A206964656E746974790D0A0D0A
04/11/19 20:28:18.058 Info: REST RPC call received. Method: getValue
04/11/19 20:28:18.060 RPC Server (Port 2001): Debug: Connection to client number 170 closed.
04/11/19 20:28:18.060 RPC Server (Port 2001): Debug: Connection to client number 170 closed (1).
04/11/19 20:28:25.031 Debug (max-cube): Packet 0900060400000000000D enters raisePacketReceived.
04/11/19 20:28:25.032 Debug (max-cube): Packet 0900060400000000000D is now passed to the EventHandler.
04/11/19 20:28:25.031 MAX packet received (max-cube, RSSI: 0x50): 0900060400000000000D
04/11/19 20:28:25.032 Debug (max-cube): Packet processing of packet 0900060400000000000D took 0 ms.
04/11/19 20:28:27.187 Debug: MQTT packet received: D000
04/11/19 20:28:27.187 MQTT Client: Debug: Packet received: D000
04/11/19 20:28:27.188 MQTT Client: Debug: Received ping response.
04/11/19 20:28:28.632 Debug: MQTT packet received: 302C0028686F6D65676561722F636C696D6174652F7365742F312F312F5345545F54454D50455241545552453230
04/11/19 20:28:28.632 MQTT Client: Debug: Packet received: 302C0028686F6D65676561722F636C696D6174652F7365742F312F312F5345545F54454D50455241545552453230
04/11/19 20:28:28.633 Info: MQTT RPC call received. Method: setValue
04/11/19 20:28:31.211 RPC Server (Port 2001): Info: Connection from ::ffff: accepted. Client number: 171
04/11/19 20:28:31.212 RPC Server (Port 2001): Info: RPC server client id for client number 171 is: 85
04/11/19 20:28:31.213 RPC Server (Port 2001): Listening for incoming packets from client number 171.
04/11/19 20:28:31.214 RPC Server (Port 2001): Debug: Packet received: 504F5354202F20485454502F312E310D0A557365722D4167656E743A204E6F64654A5320584D4C2D52504320436C69656E740D0A436F6E74656E742D547970653A20746578742F786D6C0D0A4163636570743A20746578742F786D6C0D0A4163636570742D436861727365743A20555446380D0A436F6E6E656374696F6E3A204B6565702D416C6976650D0A436F6E74656E742D4C656E6774683A203134320D0A486F73743A203139322E3136382E312E3130303A323030310D0A0D0A3C3F786D6C2076657273696F6E3D22312E30223F3E3C6D6574686F6443616C6C3E3C6D6574686F644E616D653E70696E673C2F6D6574686F644E616D653E3C706172616D733E3C706172616D3E3C76616C75653E3C737472696E673E686D6D3C2F737472696E673E3C2F76616C75653E3C2F706172616D3E3C2F706172616D733E3C2F6D6574686F6443616C6C3E
04/11/19 20:28:31.214 RPC Server (Port 2001): Info: Client number 171 is calling RPC method: ping (1) Parameters:
(String) hmm
04/11/19 20:28:31.216 MQTT Client: Debug: queueMessage(peerId, channel, keys, values) -> peerId=0, channel=-1, keys, values
04/11/19 20:28:31.217 MQTT Client: Debug: queueMessage (message) topic: plain/0/-1/PONG message:hmm
04/11/19 20:28:31.217 MQTT Client Info: Publishing topic   homegear/climate/plain/0/-1/PONG
04/11/19 20:28:31.218 MQTT Client: Debug: Sending: 33270020686F6D65676561722F636C696D6174652F706C61696E2F302F2D312F504F4E470035686D6D
04/11/19 20:28:31.218 RPC Server (Port 2001): Response: 
(Boolean) 1
04/11/19 20:28:31.218 RPC Server (Port 2001): Response packet: HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Type: text/xml
Content-Length: 123

<?xml version="1.0"?><methodResponse><params><param><value><boolean>1</boolean></value></param></params></methodResponse>

04/11/19 20:28:31.219 Debug: MQTT packet received: 40020035
04/11/19 20:28:31.220 MQTT Client: Debug: Packet received: 40020035
04/11/19 20:28:31.220 MQTT Client: Debug: Received PUBACK.
04/11/19 20:28:31.220 RPC client: Debug: Calling RPC method "system.multicall" on server
04/11/19 20:28:31.221 RPC client: Parameters:
(Array length=1)
  (Struct length=2)
      (String) event
      (Array length=4)
        (String) hmm_BidCos-RF
        (String) CENTRAL
        (String) PONG
        (String) hmm
04/11/19 20:28:31.221 Debug: Calling getFileDescriptor...
04/11/19 20:28:31.221 Debug: Connecting to host on port 2000...
04/11/19 20:28:31.224 Debug: Connected to host on port 2000. Client number is: 172
04/11/19 20:28:31.224 RPC client: Debug: Sending packet: POST /RPC2 HTTP/1.1
User-Agent: Homegear 0.7.37-2722
Content-Type: text/xml
Content-Length: 424
Connection: close

any idea of what is happening?

Hey @Ganfoud,

could you confirm that the value is actualy received on the broker? Either with mosquitto_sub or with a tool like mqtt-spy or mqtt.fx…

Could you post your mqtt.conf?

Also, please use the formating options of the forum accordingly.


thanks for your answer
yes, when I confirm that when I suscribe to the homegear/climate/set/1/1/ topic, I see the message
here is the mqtt.conf:

# mqtt.conf
# MQTT settings.

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

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

# 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 = climate

# 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 ###

# Contains the value as is. E. g.: 43.7.
plainTopic = true

# Puts the value in a JSON array to be JSON-compliant: [43.7].
jsonTopic = false

# 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 = false

### 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, do not add the <orgId> at the beginning

# 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

and I tried to edit my message for the formatting and I have an error message saying that the body is too similar to my previous message :neutral_face:

I definitely can’t edit my messages :unamused:

Hmm… everything looks good. I have the same MAX! valves and they work over mqtt.

homegear/<homgearId>/set/20/1/SET_TEMPERATURE is the topic I’m using.

Could you disable the rpcserver (clutters the log) and set the debuglevel to 5 (dl 5 in homegear console). Then please post the log when you try to set via mqtt again.

PS: The formating options for block in the forum have to be in a separate line…

hmmm I tried to disable the rpcserver by setting familyServer = false in the rpcserver.conf file, I’m not sure if that was the way to do it, but in any case the outcome is that now the MQTT commands work!
It’s a bit unexpected, and I’m not sure if I’m losing a feature if I leave it like this, but I can live with it!


I don’t think that disabling the rpcserver solved your mqtt issue… try reenabling it again to counter check.

I was also doubting, so I did reenable it before posting yesterday, and MQTT stops working… disabled again, MQTT works… I have no rationale explanation so far!

just to let you know, the first time I set up homegear it worked fine from the beginning with no issues, but I started having trouble after a reboot: Homegear stopped working
with a docker install on a different Raspberry Pi I finally managed to have it working again, but with the kind of issues I’m reporting now…

@sathya, could you say something about this?

A post was split to a new topic: Homegear Crashing at night

Hi @Ganfoud,

probably the first RPC server is not started (for what reason ever). I would need the log from starting Homegear to see issue. But: I changed the source so that external calls (like setValue() from MQTT) should always work now. So in the next nightly it should work.