Charmed Quark Systems, Ltd. - Support Forums and Community
Additional MQTT Support - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: CQC Support (
+--- Thread: Additional MQTT Support (/showthread.php?tid=11116)

Additional MQTT Support - znelbok - 05-12-2020

I am looking into Fauxmo to give Echo support to CQC and there is a couple of ways to use it..

One is to use the MQTT plugin, which to me is the most flexible that I can see at the moment. (HTTP is also supported, but I don't know about two way support)

To use it with CQC is kind of cumbersome though.

MQTT driver (Sub) -> Triggered Event -> write to associated CQC Driver.
Change in device status -> Triggered Event -> MQTT Driver (Pub).

Basically, when you ask for Alexa to turn on the kitchen light, Fauxmo publishes a MQTT message and because CQC is subscribed it updates the field.  This in turn then uses a triggered event to get CQC to turn the kitchen light on via the lighting driver.

A little cumbersome, but not too bad.

Fauxmo also can get the status of the device, if it were a pure MQTT device it would just publish its change of status (and that's how we work with MQTT in CQC currently), but for this setup, if you say, turn the light on you would again need a triggered event to publish a MQTT message so that Fauxmo is updated.

Would it be possible to have a MQTT driver/utility for CQC that wraps all that up nicely.  Something that would publish any [data configured] from CQC to any topic desired.  It would allow CQC to integrate with all other MQTT enabled products a little easier (e.g. another MQTT based server

RE: Additional MQTT Support - Dean Roddey - 05-13-2020

Can't you basically sort of do that now? If you set up a faux slot in the MQTT driver that was outgoing only, you could set it up with a list of things you want to to send out in response to a field write. Of course it would only go to a specific target topic.

If you just want to generally send any sort of msg there are probably little command line tools out there already as good as any I could write, which you could just invoke. Presumably they would take command line parameters for the topic and data.

RE: Additional MQTT Support - znelbok - 05-14-2020

Not that I am aware of. There is no mechanism that will cause a pub from a field change other than a triggered event - not unless you added something I was not aware of in the driver

Even using a command line tool would require a triggered event.

Think of something like the logic server. Assign a field(s) to a MQTT publish message. Similar logic - but slightly different in ways as well. If you have say a single field assigned to a pub message it would be designed to publish on field change. There may be an say three on off fields that will publish an on message when all are on and off when any are off.

RE: Additional MQTT Support - Dean Roddey - 05-14-2020

I'm still not fully understanding the scenario. I could of course add a 'passthrough' field to the MQTT driver where you send it a topic path and a text string to send or something like that and it just blindly sends it out. But it could get tricky because the driver wouldn't know if that's valid or what to expect back in return or anything.

RE: Additional MQTT Support - znelbok - 05-14-2020

OK, how do I send a MQTT message when any of the following happens

Kitchen light turns on/off (CQC/Light/Kitchen - "On")
Ceiling fan turns on to low (CQC/Fan/LivingFan - "Low"
TV turns on/off (CQC/TV/Bed1TV - "Off" )
A/C turns on (CQC/HVAC/SystemPower - "On"
Garage door is opened (CQC/Alarm/GarageDoor - "Open"
Alarm is armed. (CQC/Alarm/SystemState - "Armed")

Six different drivers in the list (with example topics and data) above so using a triggered event is really cumbersome.

RE: Additional MQTT Support - Dean Roddey - 05-14-2020

Oh, OK, no, that's not likely to happen. That really would require something like the logic server which is a huge undertaking.

I guess one option would be to derive a class from EventHandler:

Set up a single triggered event that just roughly filters for the kinds of events you want. The action would be an invocation of your derived class. When that happens, the event server knows it's an event handler. In your Start() method you can call the Get method to get the raw event info and do whatever you want, which could be return some info to the action that tells it to invoke some command line tool to send that info.

Another would be to create an 'event monitor' which I created a long time ago and I don't think anyone has ever used. You derive from EvMonBase:

In your Start() you tell it a list of fields you are interested in. You will be called back the FIeldChanged() method any time one of them changes. But, in this case, you'd have to build up the MQTT buffer to send yourself. You wouldn't have any way of invoking some external tool.