Charmed Quark Systems, Ltd. - Support Forums and Community

So I am trying to get MQTT set up in CQC and I'm not having any luck.

I have the MQTT server set up and a couple of plugs that I flashed to Tasmota and they are connecting to the MQTT server.  I can control those plugs via the console command line in Tasmota.  I have also set up the CQC MQTT driver and it is connecting to the MQTT server correctly (the driver is connected).  I can see MQTT PINGRESP commands being sent to the CQC driver in the MQTT console.

The issue that I am having is setting up the devices/fields in the CQC driver. I am trying to get one plug connected and I am failing miserably.

Here is the MQTT CQC config file.


This creates a field in the MQTT driver, but it is in error state and won't connect to the plug.
Here is the MQTT server console log when I try to reload the CQC MQTT Driver
Here is the MQTT server console logs when I try to reload the CQC MQTT driver:


New connection from 192.168.72.60 on port 1883.
New client connected from 192.168.72.60 as CQCMQTTS_MQTT (p2, c1, k60).
No will message specified.
Sending CONNACK to CQCMQTTS_MQTT (0, 0)
Received SUBSCRIBE from CQCMQTTS_MQTT
  XMasTree (QoS 1)
CQCMQTTS_MQTT 1 XMasTree
Sending SUBACK to CQCMQTTS_MQTT

It's not clear why it is failing, but I'm assuming it is sending back a message that CQC doesn't expect/understand.  


This MQTT command line will turn the switch on:  cmnd/XMasTree/Power On
This MQTT command line will turn the switch off: cmnd/XMasTree/Power Off

Based on that, I assume the "Topic" in the CQC config file should be XMasTree, but I don't know why it won't work. 

Any suggestions would be helpful.

Thanks,

I awoke today realizing that while I use these plugs for "lights", they are off course not light switches. They are relays. Therefore I am using the wrong code in my file.

This didn't mean I understand exactly how to fix my issues, but at least I have a direction to head in.

If anyone else already has code to control these types of plugs, I'd love to see it as I'm sure that would make my journey much shorter.

Thanks!

Here's a how-to that was posted previously, does this help?

https://www.charmedquark.com/vb_forums/s...?tid=10822

<Generic Topic="stat/Relay183/POWER" BaseName="Relay183" Access="R" FldType="Boolean">
<PLFmt Type="BinText"/>
<BoolTextMap FalseOut="OFF" TrueOut="ON">
<BoolTextVal TarVal="False" MQTTVal="OFF"/>
<BoolTextVal TarVal="True" MQTTVal="ON"/>
</BoolTextMap>
</Generic>

<Generic Topic="cmnd/Relay183/POWER" BaseName="Relay183_Cmd" FldType="String" OnConnect=" " Retain="No"
Limits="Enum: On, Off, Toggle" Access="W">
<PLFmt Type="BinText"/>
<EnumMap>
<EnumVal FldVal="Off" MQTTVal="OFF"/>
<EnumVal FldVal="On" MQTTVal="ON"/>
<EnumVal FldVal="Toggle" MQTTVal="TOGGLE"/>
</EnumMap>
</Generic>

Thats basically whats in the how to for a relay using tasmota. Should be enough to get you going. Get yourself an MQTT Clinet for testing as well. I use MQTT.fx. That way you can connect to the broker and watch everything being published and you can even publish from the client. Definitely a tool that you need when setting up or troubleshooting

Thanks Mykel!  That is exactly what I needed to get things working.

The CQC documentation is confusing because it never shows/talks about the fact that the "topic" in the CQC config file needs to include the MQTT preface and MQTT command as part of the "topic".  In fact, in all the examples it shows that you only need to include the base topic (not even the full topic).  This is where I was getting stumped.  I thought I might need to include the command and tried that without success, but I never thought to add both the preface and command in the topic.

My plugs actually have one regular plug (power1) and one USB plug (power2) so I had to include the "1" or "2" on the end of my topic in the config file, but this was easy to determine.

Now I have to figure out how to get the plugs working again with Alexa.  I compiled and flashed a custom firmware that includes the Alexa emulation, but I cannot get Alexa to actually discover any of the Tasmota devices. I've read that this is very common and virtually no one has actually gotten Alexa integration without using something like NodeRed to do this.  I guess I have to learn NodeRed now. I have to have Alexa support before I flash the rest of my plugs to Tasmota or it's not going to go over well in my house!

There's no standardization of how topics are defined, so every device my be somewhat different in what they expect. That's a big lacking in the MQTT standard, that it doesn't standardize something that important. If you can indicate where in the docs this extra info could be pointed out and what should be pointed out, I can update the docs.

(12-05-2020, 09:08 AM)Dean Roddey Wrote: [ -> ]There's no standardization of how topics are defined, so every device my be somewhat different in what they expect. That's a big lacking in the MQTT standard, that it doesn't standardize something that important. If you can indicate where in the docs this extra info could be pointed out and what should be pointed out, I can update the docs.

I'd say it at least need to be address in the "Field Definitions" section of the docs (/Reference/MQTTCfg/FieldDefs).  Under Common Attributes, you talk about the "Topic" and say that it is the most important piece of information, but you give no help in indicating what needs to be included. What is confusing is that "topic" in the MQTT world is effectively just the device name.  For example you use the MQTT topic "Home/Kitchen/Fan" in the BoolSwitch element, "Home/Siren" in the ContactClosure element, "Home/Porch/Heater" in the Generic element, etc, etc, etc.  Those are all valid MQTT topics, but in CQC world the "Topic" you need to include in the config file is the full console command (except for the payload - the last part after the ":") needed to activate the desired command.  Every code example that I have seen in the documentation would actually fail in real life because the "topic" in the code example is only the MQTT topic and not the full command that CQC is looking for.

Using my example, I have a plug (relay) that has a MQTT topic of "home/light/den/xmastree" and the full MQTT command to turn the relay on is "cmnd/home/light/den/xmastree/POWER1:ON"  Looking at the docs and all the provided examples, it looks like the "topic" that CQC needs is "home/light/den/xmastree" but in reality the CQC "topic" needs to be "cmnd/home/light/den/xmastree/POWER1".

To get the status of a device, the MQTT console command would be "stat/home/light/den/xmastree/POWER1".  That full command is what CQC needs in the "topic" of the config file to work.  Because it is looking for status, there is no payload element to the MQTT console command which is why the actual console command is what is needed in the CQC "topic" portion of the code.

This would be a breaking change, so I'm not sure it would be wise to implement, but I think the use of the word "topic" in the config file/software is wrong.  It really needs to be something like "console command".  That would more closely represent the information that CQC needs to work.  The MQTT topic is part of the console command, but only 1/3 of the needed information.  The MQTT prefix and command are also needed. 

Long story short, the CQC "Topic" really needs to include these items:  The MQTT prefix + MQTT topic + MQTT command (without the actual payload element).  So "cmnd" + "home/light/den/xmastree" + "POWER1" in my case ("cmnd/home/light/den/xmastree/POWER1"). CQC then takes this command, appends the payload element to the string, and then sends it to the MQTT broker.

Hopefully that makes sense.

It would probably help to update the "Field Definitions" section of the documentation and include Mykel's code example - perhaps in the Light Switch section. You also need to explain that due to how CQC sends out the commands, a person needs to create a field (R only) to get the status of the device (using the CQC "topic" line that is in the format "stat/MQTT topic/command") and a separate field to actually change the status of the device. This second field will likely have the CQC topic line in the format of "cmnd/MQTT topic/command".

If other people would give you a code example for other devices they have set up, it would be helpful to have those code examples in this section as well.

Other devices may not have topics anything like that though. That's sort of why it's a bad thing it wasn't standardized. It can literally be anything. Any device vendor can create any sort of scheme they want. So I didn't want to get too specific. I could put in some verbiage about how it can be basically anything and that you need to consult the device documentation or something like that.

(12-05-2020, 08:15 AM)sic0048 Wrote: [ -> ]Now I have to figure out how to get the plugs working again with Alexa.  I compiled and flashed a custom firmware that includes the Alexa emulation, but I cannot get Alexa to actually discover any of the Tasmota devices.

I have mine working with Alexa.  Make sure under configure -> Configure Other that you set it to be a Belkin Wemo for a single device and the Hugh Bridge for multiple switched devices.  The Friendly name is what Alexa is looking for.  Ask her to scan for new devices and she should find them.

I have lights, amps, air compressor and more all controlled via voice and CQC