Comments for Homie V2

[cecilios]

I'm trying to adapt my device to the Homie convention, and I find difficulties. For dealing with very simple actuators/sensors Homie seems to work perfectly, but with more complex devices, I'm not sure if it fits well. As you are considering a revision of Homie convention for v2, I would like to share my thoughts just in case could be of help.

My device is an irrigation controller with a customizable number of actuators. Each actuators can be assigned to one or more irrigations programs (number also customizable). Actuators can also be open/close on demand. My MQTT messages have the following structure:

    {prefix}/{action}/{node}/{property} {payload}

In Homie there is only one action (set), and goes at the end:

    {prefix}/{node}/{property}{action} {payload}

This order change is irrelevant and I'm not questioning it. The point is that my device uses 5 types of actions:

STATE
Informative messages sent by the device for reporting information. These messages do not imply problems.

ALERT
Informative messages sent by the device when problems or special conditions are detected.

GET
Messages sent to the device for requesting information.

SET
Messages sent to the device for changing the value of a property (i.e. for modifying an irrigation program).

DO
Messages sent to the device for immediate action (i.e. closing an electro-valve, starting an irrigation program, immediately saving into flash memory the device state, etc.)

Examples:

device_456/STATE/clock/time → 18:55:37
INFORMATIVE: Device clock current time is 18h:55m:37s

device_456/GET/clock/battery
REQUEST: Device is asked to inform about clock battery voltage. It will respond with
device_456/STATE/clock/battery → 3.048

device_456/ALERT/actuator/3/state → lost
ALERT: Device informs that connectivity with wireless actuator #3 is lost.

device_456/DO/actuator/6/running → on
ACTION: Device is asked to open actuator #6 and start irrigation.

device_456/SET/program/3/actuator/7/start-time → 19:00:00
CHANGE: Device is asked to set start time 19h:00m:00s for actuator #7 in program #3.

My SET and STATE messages naturally maps the Homie convention for changing values or reporting values. But for the other three types I can not find a clean mapping:

1. No difference between 'normal' information and 'exceptional' information. For instance, no possibility to distinguish between a periodic normal message reporting battery voltage, form an exceptional message reporting battery low:

   device_456/STATE/clock/battery → 3.024
   device_456/ALERT/clock/battery → 2.487

2. There is no way for requesting for the value of a property. For instance, I can not interrogate the device for the battery voltage:

   device_456/GET/clock/battery

Instead, I have to trust on MTTQ retention and assume that last send value is valid.

3. As a consequence of previous issue, the device will be forced to periodically having to send a message for reporting battery state. My device doesn't send periodic information, only when the value changes (i.e actuator is opened because an irrigation program has started). Other values (i.e battery voltage) are only send on request or when exceptional conditions. So I fully supports cranphin comment (issue Comments after using #4) that it would be nice to have a policy for 'on demand' values.

4. No differentiation between setting the value of a node's property (my CHANGE messages) from requesting the device to perform some action (my DO messages). This problem is not important as both types (CHANGE and DO) can be mapped to Homie 'set' messages but, semantically, are different.

Hope this can be of any help for Homie V2.

[euphi]

Regarding your proposed new "actions":

• STATE (device -> broker): In homie this is the implicit action when a device reports a property.

• ALERT (device -> broker): This is just a attribute. You could just use a special "alert" property for a node - or even a "alert" node. I don't see the need for an extra action.

• GET (broker -> device): Thats what retained messages are for.

• SET (broker -> device): ´-no need for comment-

• DO (broker -> device): I don't see the technical difference to SET.
  You could created a "Mode"-Property (e.g. in a "ControllerNode") that you can set, e.g. to trigger a state machine that controls the actuators.

[cecilios]

@euphi : thank you for your comments. You are right that with current Homie convention a solution can be found to bypass the limitations. But as this is about improving Homie for 2.0, let me explain may proposal in a different way. Sorry for this long post.

GET action

In Homie there is no way for requesting the current value of a property. Thus, Homie bypasses this limitation by sending all MQTT messages as retained

Drawbacks and limitations:

• Your monitoring application can not check a property value on demand
• Overhead on MQTT broker (see issue Does it scale? MQTT is NOT a database... #18)
• Overhead on the device and not possible/feasible to implement in certain scenarios

Example 1: assume an autonomous device that must continue doing its job when LAN connectivity is lost. The device, autonomously, changes the state of nodes/properties and when the connectivity is restored, there is a need to update the monitoring application with new device state. Two solutions:

• Either the MQTT messages must be sent with QoS > 0 and this will imply that the client MQTT on the device must store all messages to be sent when connectivity restored (probably not feasible due to memory constrictions), or
  -the device must send messages with the new state value for all properties when the connectivity is restored ==> More overhead on the device with something not required by the device functionality.

Example 2: a clock device that provides time services to other devices. Instead of allowing the other devices to request current time when needed, the clock is now forced to flood the network with periodical messages for informing about current time. The interval need to be fixed by the minimum interval required by the possible clients for the clock, thus making the clock device settings dependent on the needs of its clients. If the time precision required by a client is small (i.e. 1 second) the clock is forced to send messages every second, even if the client only needs to get the time once a day!

Solution:
Allow a property to be defined as 'getteable' and implement a get action. Allow to define if a property value message must be send retained or not. I fully supports cranphin comment (issue #4) that it would be nice to have a policy for 'on demand' values. The cost of this modification is minimal and it is backwards compatible.

STATE action

In Homie some message types ('actions') are implicit (i.e. if 'set' is not present in mqtt prefix, it must be assumed that it is a message for reporting current value ('state' action).

Drawbacks and limitations:
A monitoring application can not just subscribe to 'state' messages. Instead it will have to receive all messages (set and state, worse if more types introduced) and will have to filter out the 'set' messages' ==> Complicates the logic in monitoring applications.

Solution:
Suppress implicit actions: all mqtt messages must state their type. i.e.: <node>/<property>/set for setting the value, and <node>/<property>/state for reporting its value. The cost of this solution is minimal but it is backwards incompatible.

ALERT action:

In Homie convention there is no a standard way for differentiating between normal messages and diagnosis/alert messages.

Drawbacks and limitations:

• Each device will implement its own convention for reporting diagnostics and operational problems.
• A monitoring application can not just subscribe to messages for monitoring that all the devices are operating correctly ('alert' messages). Instead it will have to receive all messages, and must anayize if the reported values are within normal operation limits. This, in turn, transfers to the monitoring application the knowledge about safe operational limits for each monitored device.

Alternatively, the devices implements fake nodes/properties for reporting alerts. But as each device chooses a different way of doing this, you cannot simply subscribe to all ALERT messages in the network.

Whatever the solution, it complicates the monitoring applications and places knowledge in wrong places.

Solution:
Define in Homie a standard way for sending diagnosis/alert messages, such as introducing the 'alert' action.

DO action

In some cases, action and state are equivalent. For instance, switching a light on is equivalent to setting the light state to on. This is the case for devices that have stable states, because in these cases the action to move to an state can be mapped to the new state.

But, what if the action is not oriented to produce a change of state? For instance, resetting a device doesn't move the device to a 'reset' state but to a default initial state, such as 'on' or 'off' in the case of a light.

What I try to remark is that there could be actions for a device or for a node that have nothing to do with setting the value of a property. It is always possible to create a fake node or fake property to deal with these actions, but having create fake things is a signal of a limitation. What I'm proposing is to remove the limitation and to allow to define commands on a device or a node of the device without having to create fake properties.

For instance, for resetting a 'Homie for esp82266' device, marvinroger did not create a fake node with a fake property, for sending a message such as
homie/<device-id>/device/reset/set on

instead he realized that it is a different kind of command and did:
homie/<device-id>/$implementation/reset

Solution: acknowledge that there can be commands for a device or a node in the device that have nothing to do with setting the value of a property. And thus, enable a clean standard way of implementing these commands. As I write this I realize that probably using homie/<device-id>/$implementation is the expected way for doing this as $implementation is equivalent to my propesed DO action for device actions, but not for node actions.

[davidgraeff]

Closing as the convention moved to a different layout with V3.