Publishing/Subscribing from different client ID to cayenne MQTT

Hi, I’m trying to make a project in which I could control a light switch connected to an ESP8266 either from cayenne dashboard or Siri homekit. Because to interact with Homekit we need to use HAP-Node which connects to MQTT server, I though I could use Cayenne MQTT server.

So far I’ve managed to connect the ESP8266 to Cayenne MQTT server and switch on/off.
The problem that I’m facing with this scenario is that HAP-Node has a clientID and the ESP8266 has another clientID, and cannot find a way to subscribe/publish on a topic of different clientID in MQTT.

Is there a way to do this?


Hi @ricardo.garcia.flore,

Our MQTT API example code is designed around singularly connecting to our Cayenne server and publishing/receiving values to/from your Cayenne dashboard. Perhaps it could be judiciously combined with a more generic Arduino MQTT client that you could use to communicate with HAP-Node while at the same time maintaining Cayenne connectivity?


I have a related question. I have an MQTT device (Arduino using CayenneMQTT API, call it device0) that successfully publishes data. I can also trigger an LED on the device using the dashboard. Everything works as expected with device0 using the dashboard.

I have another device (MQTT client application, MQTT.fx app for example, call it device1). I can publish and subscribe using the app (following the example at cayenne-docs/ at master · myDevicesIoT/cayenne-docs · GitHub). Data shows up in the dashboard for this device and everything works as expected with device1.

The problem arises when I want to subscribe from device1 to topics on device0 using
v1/username/things/clientID/data/channel, where I substitute:
username=my username
clientID= client ID of device0
channel=0 (the channel exists in the dashboard).

I never receive any data on device1. Interestingly enough, MQTT.fx won’t even let me subscribe to the topic. It gives an error (Error subscribing to topic: de.jensd.mqttfx.entities.Topic@73662b1a
org.eclipse.paho.client.mqttv3.MqttException: MqttException … with lots of additional lines of debug info)

Any assistance as to whether this type of connection is possible would be greatly appreciated. Thanks.

Hi @acsmith,

This is essentially how I tested for the original question in this thread a month ago (including using MQTT.FX as the “different” client). What I found is that unfortunately this isn’t possible with our current configuration as it seemed to cause a conflict when both the initial client and the MQTT.FX duplication were both connecting to our server at once. I’m tagging @asanchezdelc1 here to confirm my finding and in case he has any alternate idea for how this could be accomplished – I’d hate to be turning you away due to my misunderstanding of the system.

Thanks @rsiegel. If I’m understanding it correctly, this means that no two devices have access to the other’s data. Which means, all we’re able to do is connect a single (fundamentally) device to the dashboard and interact with it there. That’s cool for confirming that a device works and the data is correct. However, to do anything practical in the IoT space, we need to be able to share this data. I thought that was the whole idea with using MQTT was that it makes it very easy to pass data around. If we’re not passing data around, what’s the point in using MQTT?

I guess I’m a little surprised this hasn’t been addressed earlier. How are other users using MQTT with Cayenne? What kind of applications are they building?

Thanks again.

I’d definitely like @asanchezdelc1’s input here to make sure I’m not sending you down the wrong path, but my understanding is that the interactivity between the devices should take place within Cayenne’s dashboard using things like our Alerts & Triggers and scheduling engines, rather than device A pulling device B’s data off of the MQTT broker.

If that is possible, he’ll have the best sense of how to accomplish it.


I also would like to try this approach as mentioned by @rsiegel. But it seems like the Cayenne triggers have issues currently. Triggers aren’t fired actually. That was my first approach when I thought of sending data from one device to the other via Triggers.