Implement a way to query a value (setter getter)

[nicola-lunghi]

I should be able to query a propertyvalue or at least have a message that causes that all the initial data is sended back

How I can query the value of the temperature?
And the other properties?

For example

homie/super-car/engine/temperature/$name → "Engine temperature"
homie/super-car/engine/temperature/$settable → "false"
homie/super-car/engine/temperature/$unit → "°C"
homie/super-car/engine/temperature/$datatype → "float"
homie/super-car/engine/temperature/$format → "-20:120"
homie/super-car/engine/temperature → "21.5"

Can I have something like
send

homie/super-car/engine/temperature/$settable/get → "true"

receive back from the device

homie/super-car/engine/temperature/$settable → "false"

send

homie/super-car/engine/temperature/get → "true"

receive back from the device

homie/super-car/engine/temperature → "false"

[fermuch]

How I can query the value of the temperature?

Well, you don't. The latest value is already in your MQTT server, since it's retained. Once you connect and subscribe to homie/super-car/engine/temperature, you'll automagically get the latest value setted by super-car.

[ingoogni]

MQTT is not about Queries it's push system (although you can implement a query protocol over mqtt). The art is to produce data in a high enough frequency.
Metadata and the last measurement values (dangerous) are retained by the broker.

[timpur]

Personally im not for this idea, i think as highlighted above, it goes again the core principle of mqtt and homie. That said if you really like the idea, there is nothing stopping you from implementing this your self in a custom node.

We have to remember that Homie has a purpose, and we can't support every idea and every feature possible. We need to also keep homie simple and un bloated, it is designed for embedded systems in mind. If there is a demand for this feature then maybe we'll look into it more.

@ThomDietrich thoughts?

[ThomDietrich]

From #76:

Be careful. MQTT does not follow the request-reply messaging pattern!

Retained messages and the configured reporting interval should suffice.

That said, of course it might be needed for your specific application to query a sensor at certain moments in time, e.g. to get the state of a light sensor this instance.

Remember that the Homie convention dictates a basic topic structure! You are free to implement your own ideas on top. That means that you can either simply define the get topic and it's logic in your implementation, or you can exploit the concept of Homie nodes and properties and work with something like homie/super-car/engine/temperature-request/set ← "true"

@marvinroger @timpur The idea is not far fetched and this is not the first time it was brought forth. How about an FAQ section at the end of the convention where we can also describe such design decisions shortly?

@davidgraeff out of interest: How are you going to implement the REFRESH action (in ESH)

[timpur]

Sure, you can add a FAQ.

I don't think this makes sense for homie and it's purpose. How would magority of homie users use this feature and does it benifits them? IMHO, I don't see everyone using this but a few. Could be wrong so please discuss :)

[ingoogni]

Is it possible that the retained data a client gets from the broker on connection are not representing the actual state of the device of interest? If so a "gimmy all" query could be use full.

[ThomDietrich]

@ingoogni the "Last Will and Testament" concept of MQTT, which is represented by the online topic in Homie, ensures the knowledge wether or not a device is active. If the device is operational, you can expect regular updates.

I'd suggest to add an FAQ entry and mark this issue as settled.

[davidgraeff]

Maybe a homie/mydevice/$brokerconnection/set <- "reconnect" topic would help. Because a device, (re)connecting to a broker needs to resend all its values as per spec.

[davidgraeff]

@ThomDietrich : For ESH it works this way:

1. The bridge (mqtt connection) comes online.
2. A device class with DeviceAttributes is populated and subscriptions to respective MQTT topics are performed.
3. The nodes and properties tree is populated and subscriptions to respective MQTT topics are performed. A property state is living in a cached but always in-sync value.
4. A callback to the handler makes it create a channel per property.

The Refresh command just looks up the respective property and returns the in-sync state value.

[timpur]

Sorry guys is it possible for you guys to talk about ESH stuff in a different ticket? (Make your own?) I love implementation talk but also don't want to confuse context here for this ticket.

[ThomDietrich]

Settled 👍