Stateless properties

[mosseb]

Hi, I'm starting to play with homie (and in particular the esp8266 implementation) and I have a very simple use case which i'm not sure how to do. My garage door motor is a simple one, where I have a simple contact. I wired a relay on my motor, which is in turned driven by the ESP8266 I/Os. Was the relay is closed, the garage door starts to move. So my program currently just receives an MQTT message, and put the relay "on" for some seconds. I'm not able to choose if it will go up, go down, unable to send any smarter command. So far so good. I wish to convert my simple but not satisfactory LUA code to C++ using homie and platformio. How should I configure this node to have a simple "rising edge" button with no state, but just an isolated order ? Seems like a node with a switch property is not correct, because it would have an "on" and "off" state but mine is stateless. Thanks for your opinion. Regards.

[euphi]

A simple way would be to use only the state of the relay .

So you switch ("set") it to "ON", then the relay switches on (and publishes its status as "ON" on MQTT, so you get your feedback) and when it is switched off again after some seconds, just publish it as "OFF".

[ThomDietrich]

Hey @mosseb, you should have started with the last line :) You are asking for the best practice for a stateless property. Homie so far doesn't offer such a feature, however that shouldn't bother you. After setting up and configuring your µC with homie-esp8266 the device will listen for commands and publish a state. Example:

homie/garagedoor/motor/power/set ← "on"
homie/garagedoor/motor/power → "true"

For your use case you can simply ignore the second topic and you are ready.

@euphi @marvinroger @timpur is a stateless property something we should support in the convention, to be discovered as such?

[timpur]

@ThomDietrich we could, but as you said, you dont have to listen to feedback. Do we need to add a special spec that just deals with this, i dont think so. i see no difference to fire and dont listen to feedback and fire and no feedback is sent. If there are reasons that im missing, that not sending feedback from the homie device has huge benefits, sure, but i dont see them? If your not interested in feedback then dont wait for it.....

I think your examples solves this. its all about the naming of nodes and props to get the desired outcome. Seems this is about motor power not garage door open or close.

[ThomDietrich]

@timpur the most important goal of the homie convention is to support automatic discovery of devices. Everything below that is just telling humans how they can set up and work with their devices but it's always subject to interpretation. For a controller (like openHAB or HA) a discovery is needed that maps a property to a fitting representation in your controller (e.g. an Item in openHAB). Those representations are then used to build UIs or define automation rules. In that context an Item that doesn't have a state is very much different to an Item that also offers the state of the device.

[euphi]

From openhab's (ESH) point of view:

• An outgoing MQTT (incoming to Homie) message should always be trtiggered by a COMMAND, so usually the command ist to "set" a state.
• A incoming MQTT (outgoing from Homie) message is used to update the state.

For a stateless property, you don't need the state. However, I strongly recommend to read back an Acknowledge that the command has been received.

In my opinion, the current way to also use a normal set message for this, is sufficient, so there is no need to add an extra topic.

Unfortunately it seems that there is no easy way in openhab to check the feedback. In my opinion this is a very important core feature of any automation system, so I will file a feature request against openhab - or Eclipse Smart Home.

[euphi]

Regarding feedback of commands: I filed a feature request for ESH: https://github.com/eclipse/smarthome/issues/5309

[mosseb]

Thanks for the answers. I'll try to apply those advices :)

[davidgraeff]

There is the property attribute "settable" that I'm using in my implementation for deciding if a channel is stateless. What else is necessary?

[ThomDietrich]

settable is not related to wether or not a property is stateless. Not sure if you meant something else.

[davidgraeff]

True. It was late. Actually I had exactly this problem when implementing the ESH binding. An ESH channel can be of kind STATE and TRIGGER and the later one is meant to be for stateless channels. Because homie does not convey this information, the channels are always of kind STATE at the moment.

[ThomDietrich]

Sounds correct to me 👍 I guess the interesting question is: How do we feel about stateless properties. Would a support in Homie be meaningful? I did not spend much time on the idea yet but I feel like it would be an interesting feature... also if it is implemented as a new attribute, it would be compatible.

Wdyt?

[timpur]

What would a starless prop look like ?

[davidgraeff]

$stateless? ^^

[timpur]

I mean the layout of topics for a stateless prop an example ?

[ThomDietrich]

@davidgraeff actually the affirmative rule for booleans would root for $stateful 😄

@timpur

• $stateful with default true, or
• $stateless with default false

That's it.

Now we need to discuss details behind that. Is the topic retained? Is it still meaningful to make it settable?

[ingoogni]

In a similar situation, a reset for a steppermotor I came to the conclusion that it isn't really stateless but that the change of state is very fast and that the state is changed by the client reset/pulse <- true (high) and then by the 'motor' reset/pulse -> false (low)

[timpur]

@ThomDietrich I'm more wondering what the whole messages sequence from device to device would look like to you and the topics involved and how this is different from what it currently look like ? How do you send a state change? Through the same settable interface as we have now?

[ThomDietrich]

In technical terms we are talking about the difference between states and events.

• state: time-dependent and valid till next update, e.g. the lamp power state or (in limits) the reading of a temperature sensor
• event: timeless event only valid/meaningful when sent, e.g. door bell pressed signal or a command to my coffee machine "please brew one cup"

The handling of events is probably different to the handling of state changes, on both the controller and node side. An example for the controller side was given by @davidgraeff

Now that I thought about it for a while I come to the following conclusion regarding Homie: Besides adding the $stateless/$stateful topic we need to add the exception, that stateless properties are not published as retained messages.

Did I miss something? What do the others think?

[davidgraeff]

Exactly. Stateless means:

• Not retained
• Settable must not be set
• The device must not echo back ("confirm") a value because of mqtt QoS 1

[ThomDietrich]

• Not retained 🤝
• $settable defines of a controller can send a command (event) to the property. This should be irrespective of the stateful/stateless nature of the property.
• Not sure if I understood. You are proposing to lower the QoS level for events? Why?

[davidgraeff]

Should read: at least QoS 1.

[davidgraeff]

How can a stateless topic be not settable? Those are contradicting attributes aren't they?

[ThomDietrich]

I have the slight feeling we have different understandings of "stateless". Especially as I know that you are googling towards ESH triggers...

• stateful + non-settable: The node publishes a property state (temperature sensor)
• stateful + settable: The node publishes a property state, and can receive commands for the property (by controller or other party) (lamp power)
• stateless + non-settable: The node publishes momentary events (door bell pressed)
• stateless + settable: The node publishes momentary events, and can receive commands for the property (by controller or other party) (brew coffee)

[ThomDietrich]

@mosseb @euphi @timpur @marvinroger what do you guys think?

[timpur]

Yeah thanks for clarifying. On the same page now :), yeah I think it does make sense. Just confirming is the on node or property level ? Assuming property?

You can propose a PR, but honestly id like to enforce some sort of sign off on PRs. Like review and approval before merge. I think everyone should have a chance to discuss before it's pushed. We're defining a convention and we should make sure things are well thought out... Maybe @marvinroger you can enable branch protection feature of github ?

[bodiroga]

Personally I'm interested in the "stateless + non-settable" combination, because I would like to create (DIY, of course) some multimedia remote controls based on Homie. Something similar to this, but with a ESP8266. The remote control doesn't need to store anything or know nothing about the controller side (openHAB in my case, but it doesn't mind), that's why the property should be stateless. I could use a standard property and model the button presses with the "/set" topic, ignoring the state topic, but modelling it natively in Homie would be ideal.

But I don't know what is the best implementation :thinking:

[ThomDietrich]

I also think this combination could be quite interesting for many. However it feels like your example doesn't quite fit. The implementation on the client side would actually not at all be affected by the stateful/stateless attribute! The attribute will, on the other side, yield an interesting effect on the controller side. The property will be auto-discovered as a stateless event thingy (openHAB: trigger) rather than a stateful thingy (openHAB: Item) whose state in between is effectively misleading.

Regarding your implementation: I'd suggest to open a new issue and I'm sure someone will jump in and give you an idea.

[mosseb]

Hi. I'm not really sure I understood all the conversation about the convention things you're considering, and so I'm not sure if this is the same topic, but I'm using Homie on my sonoff dual devices, to pilot a non-smart blind, and had a problem. I have implemented some command to mimic the button, and trigger it by publishing a message to a topic like : /homie/mydevice/shutters/downCommand/set 1 So far so good, but then I realised after after lost wifi or rebooting stuff, that the blind was closing itself automatically, which is really bad behaviour :) In fact, the retained flag was set on those message, which caused the problem. Knowing that, it seems logical : whether my device or mosquitto was restarted, the message was processed again. After reading (quickly I must about) again the convention, I thought it might be a good idea to insist about not retaining such messages : the defect was only found after several weeks of stable usage.

Have a good day !

[mosseb]

Well I reread the thread and this seems to be the exact same conclusion for @davidgraeff and @ThomDietrich right ? :)

[davidgraeff]

Yup. The convention should contain the "stateful" attribute. I'm accepting this property in the new mqtt openHAB binding, to be released with 2.4.

[davidgraeff]

Because I'm diverging from the convention already to cover all use-cases I have created a PR to cover the stateful attribute. #108

[davidgraeff]

@ThomDietrich, @timpur Please have a look. This is kind of urgent. Another user mentioned in the PR that this flag should just be called "retained", which also absolutely makes sense.

[lorenwest]

After re-reading the thread, it seems like @ThomDietrich made the clearest distinction of this functionality by differentiating state from event.

The settable attribute is already in the specification, so if you don't want it settable, then make it so. The only thing left is to advertise this as an event, which I feel MQTT has already addressed using the retained terminology.

As the maintainer of a NodeJS implementation of Homie, I have an interest in Homie not being confusing. I feel that declaring an attribute as Retained as well as Settable solves all use cases in this thread, and doesn't introduce new terminology.

[bodiroga]

Stateful and stateless are more meaningful from a non-mqtt perspective and it can be helpful for library users (@lorenwest's NodeJS, homie-python...), because they don't need to be MQTT experts to understand and use the library. What do you think?

Anyway, I'm fine with the retained option, it feels a straightforward word, even if it sounds too mqtt-centrict.

Many thanks for your opinions and keep up with the good job!