MQTT output as JSON

[kvj]

Hi @technyon
first of all I appreciate all the work you've done so far, the code quality is very high!

I'm creator/maintainer of https://github.com/kvj/hass_nuki_ng custom Nuki component for HASS and I've been also hacking Bluetooth API recently.

How much are you open discussing changes in MQTT ouput format?
I see that you purposely decided to expose each field of status, config, last auth, etc entry as a topic instead of JSON object. e.g.

Topic: xxx/yyy/config and payload: {"auto_lock": true, "led_enabled": false}
Then you can push multiple updates via single mqtt payload (anyway you get all the config updates via one BLE payload), but more importantly, you can greatly simplify MQTT discovery and expose all the attributes as state properties instead of making single entity for each field.

Tell me WDYT and I can contribute to the project

[technyon]

Please keep in mind that home assistant isn't the only home automation system. For other systems it's more convenient to expose single states, however it's easily doable to just do both, HA can just ignore the single states. I'm not using HA, so I'm not too familiar with how HA handles updates via MQTT - the HA part wasn't added by me but by @rodriguezst.

That being sad, I'm open to making changes to improve things. Maybe you can explain a bit more, and point me to some documentation.

[leo-b]

I'd also vote for a JSON object as an alternative output format for representing lock states.

A lock state change has several attributes like binaryState, trigger, authorizationId, authorizationName that should be published together in one entity in order for subscribers to be able to react on a combination of those attributes.

Currently those attributes are published sequentially starting with binaryState. In my application I need to react to a lock-open event but only if the lock had been opened by nuki and not manually (trigger != "manual"). Unfortunately currently a subscriber most likely will receive the lock state change first and at the time of processing it is not defined if the trigger field corresponds to the current or to the previous lock event. The only way to guarantee a consistent set of attibutes is to transfer them together in one topic. (Triggering based on a lock state change by a specific user is another example.)

It looks like homeassistant supports JSON topics:
https://www.home-assistant.io/integrations/sensor.mqtt/#json-attributes-template-configuration

[alexdelprete]

That being sad, I'm open to making changes to improve things. Maybe you can explain a bit more, and point me to some documentation.

Jen, if you think we could support both methods (with a user option maybe), I think @kvj would be willing to contribute to the JSON object implementation.

@kvj: we're discussing about this in https://discord.gg/mPHyWF55Gv, would be awesome if you joined the project. :)

[technyon]

@kvj We can support both I think, I just need to know how. @kvj Please join us on discord.

[dhorak1]

I would as well vote for a JSON output of composite data. For the client, such a JSON object is much easier to parse and less error-prone than assembling the same object from various values of different topics.

The keypad code list has the additional challenge of being of variable length. The client does not know in advance when to stop reading/waiting ("Is keypad/code_$n/... the last item or do I need to wait for more data?"). A JSON array of keypad objects would be very helpful here.

[leo-b]

I'd also vote for a JSON object as an alternative output format for representing lock states.
@kvj We can support both I think, I just need to know how. @kvj Please join us on discord.

Having the information who locked or unlocked the door available as an attribute of the lock state would still be very useful!
I am currently struggeling to work around the limitation of not having a consistent set of attributes by trying to rebuild the information using a template sensor.
But it is not possible to reliably know if all data needed for emulating an atomic state change has already arrived or how long we have to wait for attribute changes belonging to the same lock event that might still follow.

E.g. if the last two lock actions have been done manually, the trigger state will simply stay at manual, so we don't know how long we have to wait before updating the state of the template entity.