MQTT Events

Hello,

I want to be able to read some data from some mqtt topics, and also send at will via appdaemon. Please any ideas on how to do this?

I thought about setting up some components, then trying to listen to them like sensors, but that doesn’t seem to work and so confused on what to do. My data is in json, so my hope is to read and parse the data myself and that’s basically why I installed appdaemon for the first time (so newbie).

Kind regards

1 Like

There was a time that MQTT messages came on the event bus, but that changed about 6 months ago.

That is what I ended up doing. It does work, but is a long way around.

It occurred to me recently that you could also have an (yaml) automation that triggers off the MQTT message and sends an event that appdaemon could listen for. Its still a long way around but doesn’t create unused sensors, so will probably be more efficient.

Or you could create a thread to subscribe to MQTT messages directly, but that’s something of an advanced topic.

You can use the mqtt publish service to send messages

            self.call_service("mqtt/publish", topic=self.args["tts_topic"],
                    payload=orig_text)
1 Like

Hello @gpbenton.

Thanks for your feedback.

I think the sensors will be great, but I couldn’t get the raw json data via it. Its as if it expects to be parsed as I need the raw data to use without inserting value_template. Is this what you did and can you kindly tell me what you did so I can cross check with mine?

I don’t mind this option, if I can be placed in the right direction.

Many thanks

This is all theoretical. I have never done it :open_mouth:

First of all read the appdaemon documentation regarding threads. It used to be at the start, but I’m not sure now.

In the init section of your app , you will need to create a thread that will be waiting for mqtt messages, as described in the paho-mqtt package. You should probably use the callback method and define callbacks with the appdaemon app. The callbacks will be called when messages are received.

You will also need to define a terminate(self): method in the appdaemon app to kill the thread when the app ends.

There are probably more gotchas. But that is the theory.

I am fairly sure I had this at one point, and then split it up in to individual sensors for each item in the json. From what I can remember, it was just a matter of defining the sensor and not setting value_template at all. You just get the state as the value of the json string.

I’ll have a look through my git logs and play around this evening to see if I can reproduce it.

@gpbenton Wow,

Splitting the json like that is sure a lot of sensors; now I get what you meant earlier :thinking:.

Will try again this evening and thanks for the time :facepunch:t5:.

Kind regards

Actually, I see now I didn’t take the sensor out. I have

sensor:
  - platform: mqtt
    state_topic: "/energenie/eTRV/Report/Diagnostics/329"
    name: "Lounge eTRV diagnostics"

And the json text is stored as the state of the sensor.

Thanks @gpbenton,

Done exactly same thing, but getting ‘unknown’ and the sensor isn’t generating any event meaning it’s state not changing.

Don’t know what else to do.

I have a pretty standard procedure.

FIrst you have to establish that the message is being published to the broker. I normally use mosquitto_sub to subscribe to the broker to see the messages being sent. This is normally where I see a spelling error so the different topics don’t match.

Then you have to make sure the HA is connected to the broker - the mosquitto logs normally show that.

If the message topic looks the same and HA is connected, but it still doesn’t work, its time to turn on the debug logging for mqtt in HA, to see what its doing with the message

logger:
  default: warning
  logs:
       homeassistant.components.mqtt: debug

Thanks @gpbenton,

I later figured out my json data was more than the sensor could handle, so had to break it down into 5 sensors :cry::pensive: to get the value out.

Its sad one can’t just directly subscribe to a topic in appdaemon but oh well, have to do with this for now. Just not learned enough to develop a component to handle this. Kind regards for all the help.

Did you try the approach of adding a yaml automation to send an event? That would be a far simpler approach, provided it didn’t run in to the same sort of size limitation.

Well I haven’t as I just figured this out now, but not sure how that will help as since it can’t collect all the data, don’t know how I will be able to retrieve it.

I could try using only one of the sensors to know there is a data (trigger), but since I don’t have the rest stored somewhere, not sure how it will be collected. Or is it possible to have the broker keep that data for retrieval until the next update? Like persistence or something?

Regards

The question is really if the limitation is in the state of the sensor or in the general handling of MQTT messages and events.

If the size limitation is only in the sensor, then you could bypass the sensor altogether by using the automation and sending the data in an event to appdaemon.

I have heard of people sending images via MQTT from HA, so I would be surprised if there is a significant limit on the size of data there, but the event bus I don’t know too much about.

Now I get your point, and yes you right about using an event. I will test that now and get back to you. Kind regards

@gpbenton,

Its me again. I have created the automation that triggers when a mqtt message is retrieved on my said topic, and my custom event is triggered. But no idea how to place the payload_json generated on the mqtt bus in my event; for I do understand that custom events don’t support templating yet.

So pls how do I transfer the data?

Thanks

I think that rather scuppers the whole idea. One of the reasons I hated all that yaml stuff in the first place.

Your stuck with your five different sensors I’m afraid.

:sob::sob::sob::sob::sob::sob::sob:

I implemented event_data_template to help with this so the data just gets handed directly to the event. I am unsure what limitation you are running into with sensors holding the data, is it just too many fields?

I have a pull request in. Hopefully get this merged at some point since I think it would be really useful to avoid the kludging of setting sensor states.

https://github.com/home-assistant/home-assistant/pull/11057/files#diff-271c3f410a76f769b10ff2dd3c7ec7d7

1 Like

@Odianosen25 @gpbenton so I just tested this config in my automations and it worked for me. This reads the topic off mqtt and passes the entire payload to appdaemon

- alias: intentNotParsed
  trigger:
    platform: mqtt
    topic: hermes/nlu/intentNotParsed
  action:
    event: APP_INTENT_NOT_PARSED
    event_data_template:
      payload: '{{ trigger.payload }}'

AppDaemon get this
LOG INFO myapp: myapp_nluIntentNotParsed: {‘payload’: “{‘intent’: ‘this_intent’}”}

@ReneTode @aimc figure you guys might like this as well since it will greatly simplify getting external data into an app. Now just need to get Paulus to accept it :slight_smile:

1 Like

@tschmidty,

Thanks for this, and I am also trying to use it to process snips data in AppDaemon :slight_smile:.

So is there something I need to do to activate the templating or is it a custom component or something? I went to your link, but I really don’t know how to pull stuffs in except via custom component.

Hope this will also work for the json payload too?

Kind regards