add "get" next to "set"

[bertmelis]

What do you think of a "get" topic extension?

For interacting devices it's not really an issue, but for sensors it would make sense to request a measurement externally.
In the Arduino/ESP8266 framework, the sensor examples are all working on a fixed hardcoded time base. A workaround could be to put the interval into the config json and update this via MQTT. But imho it would be simpeler if a property state can be requested by a ".../topic/property/get"-command (void payload).

[marvinroger]

Given the retained flag can be used... What's the point? RPC is not well-suited for MQTT (we did that for the OTA because we did not really have any other choice, but in this case I don't see the benefits).

[jamesmyatt]

I don't think this makes sense for MQTT since you have to expect multiple consumers. With multiple consumers, it will "reply" to all of them when ever any one of them sends the "get" command.

If you need request/response, then try COAP or HTTP.

[bertmelis]

Let's say a temperature sensor is publishing every 5 minutes. For troubleshooting reasons I want to have it every minute. My possibilities are:

• reprogram the node
• use a custom property in the json and change it OTA
• implement a #/get topic to trigger the node to publish

I was looking at my KNX installation and saw that a sensor was programmed to publish a value every 60s. But in addition I also could read the value on request, if allowed to do so. Hence the idea.
(you can also have multiple consumers in KNX)

[gorootde]

What about changing @bertmelis requirement a little bit, while achieving the same:
Introduce /topic/property/update command, which signals the node to update /topic/property.
Given your "5 minutes" example, the node would still update /topic/property every five minutes on its own, but every client has the possibility to explicitly request an update.
This would also not interfere with other clients listening to this topic, as they have no influence on the update frequency anyway.

[jamesmyatt]

@bertmelis , I would say that the "correct" solution is

use a custom property in the json and change it OTA

on the grounds that hard-coded numbers are bad.

You could even make it a node, like $stats/interval, and allow it to be updated without rebooting.

[bertmelis]

As for the homie-esp8266: I don't like implementing it in a custom property as it requires my server to speak JSON which it doesn't for the moment and I don't like rebooting (however it's the no 1 solution from my former IT helpdesk 😆).

I'll figure something out with configuration-nodes.

But I do find that this limits the framework to create active IoT devices but not interactive.
Furthermore: something like is discussed in the MQTT OASIS standard also: https://issues.oasis-open.org/browse/MQTT-197

[marvinroger]

I don't feel like "hacking" how MQTT works is a good idea. You said so, your use-case would be debugging. As @nzbuu said, you can create a debug node on which you can do pretty much whatever you want (homie/device/debug/command/set -> update). Same goes for interactive devices, you have the same flexibility with nodes.

If a newer version of MQTT comes with RPC, I'd be happy to reconsider. 😃

[bertmelis]

OK, no hard feelings 😃 It will work with an extra configuration-node.

For the MQTT standard: it's only for ver.5 As we're only on V3x it could take a while.