Add support for messaging via mqtt

[normanmaurer]

At the moment there are various supported ways how to use messaging. It would be nice if you could add mqtt as well. This would allow to easy integrate with other software that could just subscribe to a topic.

[andig]

What kind of "messaging"?

[normanmaurer]

This one https://docs.evcc.io/docs/reference/configuration/messaging

So I think it is not really messaging but services that is used by messaging

[andig]

I see. That would mean adding a custom push device. Not a priority, but happy to take a PR. Doing so it would also be nice to remove the script push device- it can already be implemented using the script plugin.

/cc @GrimmiMeloni in case you're interested

[normanmaurer]

Yeah for now I just use the script stuff with mosquito_pub

[GrimmiMeloni]

Yeah, about time for me to contribute something again. ;)

@normanmaurer what would an MVP look like? Does simply configuring a broker + a topic to publish to suffice?

[normanmaurer]

@GrimmiMeloni yes 🎉

[andig]

Spannend ist noch wie wir mit title und msg umgehen. Vllt. Lassen wir bei den custom Integrationen einfach den title weg?

[normanmaurer]

Or we could also use json for the payload

[andig]

Like it. Could be an encoding option on the custom messenger.

[GrimmiMeloni]

I am wondering why we are talking custom here? I was planning to just add an mqtt flavor to the list of supported messaging services (shoutr, telegram, ....)

[andig]

I just thought we have custom everywhere and script already is a custom integration. Why not make it fully flexible before the next user wants http?

[GrimmiMeloni]

OK. But if we already have a custom solution via script, then what is actually missing here? Sorry for being "stupid", but I still don't understand the actual ask. Can you maybe show an example of the configuration you expect, or some other fragment that explains what the difference between script and custom would be?

[rhuss]

Sorry, just have seen this issue. By accident, I've implemented a type 'mqtt' in #17278 which is just reusing the existing MQTT client. This simple addition is also documented in evcc-io/docs#670

[rhuss]

Just read through this issue, my thoughts here:

• For MQTT the "title" can IMO be mostly ignored. For JSON payloads I just added the title with a field "title" within this payload.
• I wonder whether multiple MQTT endpoints are required or if the single MQTT endpoint that is also used by plugins is good enough. It shouldn't be hard to either add MQTT config to the service configuration or allow multiple MQTT Broker instances (that then would be configured in a list)

[rhuss]

Here is an example, how the title is treated in #17278 with JSON (otherwise its ignored):

# MQTT Broker Configuration
mqtt:
  broker: broker.mqtt:1883
  user: evcc
  password: s3cr3t

# Send lifecycle events via MQTT
messaging:
  events: 
    connect:
      # Title is added later to JSON. Just omit it if not needed
      title: "Car connected"
      # Use template to create JSON payload
      msg: '{"car": "${vehicleTitle}", "mode": "${mode}", "event": "connect"}'
  services:
  - type: mqtt
    topic: 'evcc/events'

This will result in payloads that look like

{
  "car": "Ioniq 6", 
  "mode": "PV",
  "title": "Car connected"
  "event": "connect"
}

[andig]

Is there anything in the suggested PR that prevents this pattern?