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?

[rhuss]

nope, the PR is great.

I just wanted to add some more color to the issue. +1 for selecting #17211 over #17278 if some documentation on how to concretely implement the MQTT use case with custom plugins for messaging can be achieved. Also, I've added some ideas on how to deal with title and msg in the payload (added it as comments to the PR), as I think it should be started small (just copying over the msg as payload, ignoring the title), and extended if more format variations would be needed (but I don't really see any concrete use case right now beside raw/JSON payloads)

[andig]

if some documentation on how to concretely implement the MQTT use case with custom plugins for messaging can be achieved.

Exactly identicial to any other custom evcc device.

[rhuss]

Exactly identicial to any other custom evcc device.

Yes, true, but for newcomers like me it would be very helpful to have (nearly) full examples how to implement certain use cases, like requested in this issue. I opened evcc-io/docs#665 which somewhat touches this. In the context of this issue, it would be super helpful to have a full example of how to use custom plugins in the messaging.service section, as this has already caused some confusion here on how to do it.

While the current documentation is good (thanks a lot for your efforts!), I still think it can be improved by more use-case-driven documentation, including fully working snippets (not only parts of the yaml schema where you have a hard time finding out where to put it into etc.yaml). Not all custom plugins need to be touched, but describing one concrete example (mqtt or HTTP) should be good enough for ppl being able to map it to other custom devices.