Giters

softypit / esp32_mqtt_eq3

esp32-based mqtt node to control EQ-3 BLE TRVs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

MQTT topic naming

hamamo opened this issue · comments

commented

After looking at some hints on MQTT topic naming and content conventions, it seems that it would probably be good to structure the MQTT data a bit differently:

  • Naming:
    Some sources (e.g. HiveMQ) recommend agains leading slashes, and I find simply appending 'radin' or 'radout' to the client id somewhat weird-looking, so I tried deleting the slash from the beginning and inserting it between id and radin/radout: bedroom/radin/trv instead of /bedroomradin/trv.
  • Content:
    Using "command" on the radin side and a json object on the radout status side seems a bit asymmetric. I was under the impression that MQTT is more state-oriented than command-oriented (although the latter needs to be done in some cases) so I would expect this topic structure:
    bedroom/trv/devices - list devices visible to this trv bridge (readonly)
    bedroom/trv/devices/01:02:03:04:06/settemp - attribute for the set temperature (read/write)
    bedroom/trv/devices/01:02:03:04:06/mode - attribute for manual/automatic mode (read/write)
    etc. For additional luxury, devices could have human-readable aliases such as left-window-radiator.
  • Persistency:
    When topics are published persistently, new subscribers are able to see the current settings, which might be useful when some components need to be restarted or have only intermittent connections.

Hope this doesn't sound critical, I'm just excited about and thankful for this software!

commented

Hi Hans,
Thanks for your comments - it's always good to hear other peoples thoughts on how I've done things.
esp32_mqtt_eq3 was purposely designed as a bridge for communicating with the ble valves via mqtt and deliberately has minimal intelligence built-in. I never really considered using public MQTT brokers (like HiveMQ) and the intended scenario was with an internal network broker like mosquitto running on an RPi or microserver.
Here is my feedback on the points you have raised:

  • Naming:
    The leading / was something I used when I was developing the code and never got around to changing (I do most of my work on Linux and dislike any kind of path that doesn't explicitly start with / or ./). It's not a problem using this with MQTT but convention means it is not often used. I agree it should probably look more like <devicename>/. The problem with changing this is that a software update could break existing deployments of the code as the topics would need to be changed on the controlling equipment. I'll take a look to see if it's feasible to make this modifiable in config to remain backward-compatible.
  • Content:
    MQTT is neither state nor command orientated - it is purely a message distribution mechanism. Convention dictates the way some of the public brokers prefer topics formatted. Formatting of topics and messages is a trade-off between readability and processing/filtering requirements. I very specifically made the topic short to allow messages to get to the relevant ESP32 device but left everything else in the message. This way the ESP uses a single non-wildcarded subscription on the broker and deals with the request using only the message.
    I don't understand your (read/write) definition - I assume you mean bi-directional messages i.e. the controller and ESP32 bridge use the same topic to indicate command/status. This is not advisable in MQTT as the ESP would send a response and then receive it again from the broker as it has an active subscription to that topic - this would be interpreted as a new command.
    The reason for the single json status output and the lack of naming of trvs is that the ESP does not hold state of available trvs to remove the associated risk and complexity of additional memory management. While a list of discovered TRVs is held this is dynamic and not stored in NV so it's impossible to associate 'friendly' names with valves. Also each commanded TRV is only held in any kind of context for the duration of the command/response. This means that after each command the entire status of the valve (all parameters) must be sent as it is not possible to determine what has changed from the last time the valve was read. While it would be possible to break each individual parameter down to a specific topic/message this would result in a number of messages being sent each time a command completes.
  • Persistency
    The problem with persistency in mqtt is that no timestamp is held of when the value was set. This means that a value could be minutes or days old. With EQ-3 TRVs the status parameters are continually changing due to the environment or user-intervention with the panel-buttons. For this reason it is much better to 'poll' the device when required to see the current status as anything persistent is almost-certainly stale.

I'm glad you like the software. Please feel free to share your usage scenario - I developed this for my own BMS system but am glad others find it useful. If I can get an understanding of how others use it perhaps there are changes that need to be made for it to be more useful.

commented
commented

I realise this is an old thread but would entering the name in the ID as /radiators or radiators solve the leading / problem?
A note in the readme informing about the change would normally be enough. I wasn't expecting the leading / but 30 seconds with MQTT fx soon resolved it - but it's the only device with a leading / so it appears out of sequence.
I'd also prefer a / between ID and radon and radout but that's me being picky.