Expanded MQTT

[tibmeister]

Event Server version 6.1.14

Hooks version (if you are using Object Detection) app:6.1.14, pyzm:0.3.36

The version of ZoneMinder you are using: 1.34.23

What is the nature of your issue

Enhancement

Details

Currently the MQTT sends a single JSON string as the topic message. The request is to enable a switch to instead have a topic hierarchy created with some messages. For example, take the following JSON

{"monitor":"1","state":"alarm","eventid":"97269","eventtype":"event_start","detection":[],"hookvalue":"1","name":"Front Yard:(97269) Linked"

Enable this to be published to MQTT as follows

zoneminder/{monitorid}
zoneminder/{monitorid}/{state}
zoneminder/{monitorid}/{state}/eventtype : "event_start"
zoneminder/{monitorid}/{state}/detected/{objecttype} : ""
zoneminder/{monitorid}/{state}/hookvalue : "1"
zoneminder/{monitorid}/{state}/name : "Front Yard"

This would allow for subscribing to the specific topic, such as zoneminder/1/alarm/eventtype and get the simple message "event_start" to trigger on without having to create glue code to parse the json string and possible variants. For instances where object detection is used, the zoneminder/{monitorid}/{state}/detected/{objecttype} would be able to cover that, for example for a car with a 40% match it could look like this:

zoneminder/1/alarm/detected/car : "40%"

This also appears to be more inline with all documentation and references I've seen to using MQTT.

[tbowmo]

There are multiple approaches to how mqtt is used.. I publish json objects for some of my stuff (like chromecast media etc.). So I do not see a benefit of splitting it accross multiple mqtt topics.

One thing that would be nice though, is that the Name would be more static, and consistent. Perhaps splitting it into multiple properties in the mqtt JSON message: (how it is currently):

Front yard:(97269) Linked
Front yard:(97269) Motion Driveway, Barn, House
Ended: Front yard:(97269) Motion: Driveway, Barn, House
Front yard:(97269) [s] detected:car:100% Motion Driveway

All of above is various ways of populating the name property in the current JSON format that is published.

I'm interested in motion, so I have to parse the name to get motion start / end sequences that I republish.

[pliablepixels]

Umm so I don't use MQTT - not sure if this is the right approach. Either way, if MQTT folks think this is appropriate, will request a PR (tagging our resident experts @darknicht66 @vajonam )

[vajonam]

Yes, I have seen systems work like this as well. But to keep backward compat maybe a flag to have "deep" topics to break out the messages into very specific topics. Agreed that usually there is some switch/case after the JSON is parsed on the receiving side, so this might make it easier. @darknicht66 thoughts?

[darknicht66]

There really is no 'RFC' in the MQTT specification for what MQTT topics are supposed to look like so it's really up to the vendor applications for how they want to present/consume their data. I have no issue with someone extending the MQTT topics as long as the original (json style) remains available for backwards compatibility. You don't even have to make it a config option, just add new topics and the consumers can subscribe to the topics they need.

[wb666greene]

That is the real beauty of MQTT. The publisher can do whatever and add new topics as needed. If nobody subscribes to the new topics the broker never does anything with them. Only subscribers to the new topics get the new messages, users of the "old messages" never know anything has changed. Its almost too simple to describe, if you are new to MQTT this is a good place to start: http://www.steves-internet-guide.com/understanding-mqtt-topics/

No "flags" are required, just publish extra info as needed as new topics and the old users are none the wiser, users of the new info subscribe to the new topics and then get the extra info. Backward compatibility is built-in unless you modify the preexisting topic hierarchy.

You can see what a broker is doing if you download the "MQTT Explorer" app https://mqtt-explorer.com/
The main site is here: https://github.com/thomasnordquist/MQTT-Explorer

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.