firmware icon indicating copy to clipboard operation
firmware copied to clipboard

[Feature Request]: Retire native JSON MQTT functionality

Open thebentern opened this issue 1 year ago • 11 comments

Platform

Cross-Platform

Description

This has been a problematic feature for several reasons:

  1. It takes up precious space on NRF52 based devices which are approaching the limits of flash utilization
  2. It has created potential security concerns in the past and there are likely undiscovered ones existing now.
  3. It should be an application layer concern where the implementation can be less prescriptive and tailored to the use case.

Tagging @ianmcorvidae because he has some migration strategies to externalize the support while keeping things in the format they exist in currently for the firmware so that automations in Home Assistant or otherwise can continue working with a bit of extra sauce.

thebentern avatar Dec 04 '24 18:12 thebentern

I like this idea. It's definitely something that needs to be addressed and @ianmcorvidae has some great ideas around this. Looking forward to seeing the solution.

rcarteraz avatar Dec 04 '24 18:12 rcarteraz

Agree on this, although indeed with the "requirement" that it would need to be able to easily integrate with popular home automation systems like Home Assistant and OpenHAB. Ideally it would be a native integration/binding such that the end-user doesn't have to handle this glue code and run it in an additional daemon.

GUVWAF avatar Dec 04 '24 18:12 GUVWAF

It case it's useful, I've roughed out a python script for this purpose. Maybe it's possible to use something like this as a custom addon to HA? https://github.com/pdxlocations/mqtt-protobuf-to-json

pdxlocations avatar Dec 04 '24 20:12 pdxlocations

From what I can tell having a quick look at this @pdxlocations it only seems to cope with decoding mesh packets and outputting them to JSON, which indeed is something I still need, but much more important for me, given I use Home Assistant to broadcast weather updates on both a dedicated channel more frequently, and longfast less frequently, is the ability to SEND a mqtt message to be broadcast. So code would need to be able to figure out which portnum to use, and what channel.

asjmcguire avatar Dec 10 '24 12:12 asjmcguire

@garthvh Why are we planning to retain the JSON functionality for the RAK Ethernet gateway? https://github.com/meshtastic/firmware/issues/5498#issuecomment-2549023963

Then someone would still need to maintain this (add new fields and fix bugs like the one linked), and it can only be tested on one specific hardware combo. Besides, once we have a suitable alternative it will likely be slightly different than the manually crafted JSON, so you can't use the same system with different hardware. In my opinion if we remove it from the firmware, we have to nuke it altogether.

GUVWAF avatar Dec 17 '24 18:12 GUVWAF

@garthvh Why are we planning to retain the JSON functionality for the RAK Ethernet gateway? #5498 (comment)

Then someone would still need to maintain this (add new fields and fix bugs like the one linked), and it can only be tested on one specific hardware combo. Besides, once we have a suitable alternative it will likely be slightly different than the manually crafted JSON, so you can't use the same system with different hardware. In my opinion if we remove it from the firmware, we have to nuke it altogether.

I don't anticipate it being something that the project maintains, that device is managed by @beegee-tokyo and RAK so my thought was that he could continue to maintain it if necessary, but I am not opposed to nuking it.

garthvh avatar Dec 17 '24 21:12 garthvh

@garthvh I am ok, if you replace it with something else that works. MQTT with JSON might not be important for "messaging", but when using Meshtastic in other applications like sensor networks, control functions, it is essential, specially because you don't offer a working raw payload decoder at this point. I can maintain MQTT until you come up with something else.

beegee-tokyo avatar Dec 18 '24 01:12 beegee-tokyo

It case it's useful, I've roughed out a python script for this purpose. Maybe it's possible to use something like this as a custom addon to HA? https://github.com/pdxlocations/mqtt-protobuf-to-json

I've started a similar project based on node.js a month ago https://github.com/leshniak/meshtastic-protobuf-decoder (for private use at the time). @pdxlocations but yours suits better for HA.

leshniak avatar Dec 19 '24 15:12 leshniak

@leshniak Any plans to add your project to NodeRED official packages? I am struggling to add your meshtastic-protobuf-decoder to my NodeRED installation.

beegee-tokyo avatar Dec 20 '24 06:12 beegee-tokyo

@broglep is working on a home assistant integration at https://github.com/broglep/homeassistant-meshtastic that looks like it won't need json+mqtt

fifieldt avatar Dec 22 '24 10:12 fifieldt

An HA integration using protos and MQTT: https://github.com/kvj/hass_Mtastic_MQTT

pdxlocations avatar Dec 28 '24 18:12 pdxlocations